Archiv der Kategorie: Microsoft

Server 2012 R2 – DHCP Failover und IPAM

DHCP Failover ist ja nichts neues (seit Server 2012 „eingebettet“ und oftmals genutzt), jedoch gab es einen kleinen Haken an der ganzen Sache: Die Reservierungen. Kaum jemand kommt ohne DHCP-Reservierungen aus (seien es Drucker oder spezielle Geräte die mittels IP-Freischaltung weitergehend konfiguriert sind). Seit Server 2012 R2 hat IPAM die automatische Reservierungs-Erstellung auf allen beteiligten Servern integriert. Somit sind keinerlei Powershell-Scripte mehr notwendig.

Folgende IST-Situation: Ein Unternehmen mit einer Niederlassung die über eine langsame WAN-Verbindung an das Hauptrechenzentrum angebunden ist. Es werden nur Server 2012 R2 verwendet. Am Aussenstandort gibt es lediglich einen physischen Server der DHCP-Server ist.

Aus Hochverfügbarkeitsgründen sollte nun DHCP redundant ausgeführt werden um bei einem Ausfall des Aussenstandortservers den DHCP-Service nach wie vor aufrecht zu erhalten.

Server Site1 (RZ):

  • vmsrv17 (2012 R2, IPAM-Server)
  • vmsrv18 (2012 R2, DHCP-Server)

Server Site2 (Aussenstandort):

  • vmsrv19 (2012 R2, DHCP-Server)

Die Basis-Konfiguation der DHCP-Server ist nicht nennenswert (Add Roles -> DHCP)

IPAM möchte ich jedoch nochmals kurz zeigen:

Die Installation erfolgt genau so über „Add Roles and Features“. Nach der Installation und Aufruf der IPAM-Overview muss man sich im Punkt 1) mit dem IPAM-Server Verbindungen und bei Punkt 2) eine Datenbank auswählen. Der Einfachheit halber wurde eine Windows InternalDatabase verwendet (kann jederzeit zu einer SQL-DB migriert werden)

Provision IPAM

Danach wird die Provisionierung gewählt. Hier wird die Provisionierung über GPOs gewählt. Die GPOs enthalten die notwendigen Freischaltungen und Einstellungen und werden mithilfe des SecurityFilterings über IPAM mit den entsprechenden Server befüllt.

Provision IPAM_2

Nach dem Erstellen muss noch über Powershell das Provisionieren angestoßen werden (ansonsten wird es die GPOs nie geben 😉 )invoke-IPAMGpoProvisioning

Nun muss noch das ServerDiscovery durchgeführt werden. Danach können bereits die Server zum IPAM Inventory hinzugefügt werden. Mittels „Tasks -> Add Server“ können Server hinzugefügt werden und mittels „Edit Server“ und dem ändern auf „Managed“ können die Server (nach einem Reboot) von IPAM gemanaged werden.

IPAM_Add_Server

Mittels „Add Scope“ kann nun am ersten DHCP-Server der erste Scope angelegt werden. IPAM_CreateScope

Nach dem Anlegen kann das Failover konfiguriert werden („Configure DHCP Failover“) wie hier zu sehen ist.IPAM_DHCP_Failover

Nun kann ein Failover-Relationship-Name vergeben werden und die üblichen Failover-Settings:IPAM_DHCP_Failover_Settings

Wenn dies konfiguriert ist kann der Test erfolgen (IP Addressreservierung einrichten). Beim Speichern müsste gleich auffallen, dass auf beiden Servern die Reservierungen eingetragen werden. Somit ist ein manuelles Replizieren nicht mehr notwendig.IPAM_Reservation_DHCP-Servers

Kurz noch ein Checkout mittels der DHCP-MMC und fertig 🙂DHCP_Reservations_PIR

 

Hyper-V (Windows 8.1) vs. VMware Workstation 11 – Disk Benchmark

Wie bei einem vorigen Artikel bereits erwähnt wurden einige VMs von VMware Workstation auf Hyper-V migriert. Da die Maschinen sich schneller „anfühlten“ wurde ein kurzer Belastungstest durchgeführt. Es wurde jeweils dieselbe VM (Server 2008 R2) verwendet. Als Benchmark-Tool wurde CrystalDiskMark in den Standardeinstellungen verwendet. Die VM ist zu 100% ident da eine V2V-Konvertierung stattfand (Treiber, etc. wurden natürlich geändert 😉 )

Der Host ist ein Windows 8.1 – PC mit AMD FX6300, 16GB RAM und 1x3TB SATA HDD (7,2k)

Der Test wurde jeweils 2x hintereinander ausgeführt (da die Disken als „Thin Provisioned“ angelegt wurden und somit die Datenblöcke sich füllen können)

VMware Workstation VM:

vmware_vmsrv06

Hyper-V VM:

hyper-v_vmsrv06

Das Ergebnis nun in Zahlen:

Read: Write
Seq: +37,99% +24,80%
512k +54,68% +28,94%
4k +61,16% +33,96%
4k QD32 +19,70% +18,22%

Fazit: Ein Umstieg auf Hyper-V lohnt sich und ist spürbar schneller.

VMDK to VHD Converter: Microsoft Virtual Machine Converter HowTo

Aufgrund von Windows 8 und Hyper-V ist es nun an der Zeit, die VMware Workstation abzulösen (der Host ist ein gewöhnlicher Windows 8-PC mit 16GB RAM und SSD). Um dies durchführen zu können hat Microsoft ein Tool zur Verfügung gestellt: Den Microsoft Virtual Machine Converter. Dieses Tool bittet eine grafische Oberfläche um beispielsweise von vSphere, ESX und ESXi direkt in die AzureCloud oder einen Hyper-V Host migrieren zu können. Leider geht dies nicht ganz so einfach für eine VMware Workstation. Hier eine kleine Anleitung:

1. Download des Microsoft Virtual Machine Converter (derzeit V3): http://www.microsoft.com/en-us/download/details.aspx?id=42497

2. Um die Powershell-Features nutzen zu können muss das Modul zuerst registriert werden:

import-module Installationspfad\MvmcCmdlet.psd1

Bsp: import-module import-module ‚C:\Program Files\Microsoft Virtual Machine Converter\MvmcCmdlet.psd1‘

Als nächstes hat man Zugriff auf die Powershell-Befehle. Um beispielsweise eine VMDK konvertieren zu können geschieht dies folgendermaßen:

ConvertTo-MvmcVhd M:\VMware\VMSRV06\VMSRV06-1.vmdk M:\Hyper-V\vmsrv06

ps_vmdk_to_vhd

kleine Randnotiz: Standardmäßig ist dies (wenn bei einem Win7 bzw. Server 2008 R2 ausgeführt) ein VHD-File; bei Win8 und Server 2012 ein VHDX-File. Dynamisch ist ebenso Standard (fixed wäre ebenso möglich)

Über den Hyper-V Manager ist es nun an der Zeit, die VHDX zu importieren. Als Erstes muss eine neue VM angelegt werden (bitte als Gen1)

hyper-v_gen1

Danach die konvertierte Disk angeben:

hyper-v_vhd

Nun sollte sich bereits die VM starten lassen. Zum Abschluss noch die VMware Tools deinstallieren und schon geht’s unter Hyper-V weiter.

StorageSpaces 2012 R2 und SSD Tiering auf Demo-Umgebung mit VMware Workstation

Da ich mir eine neue SSD angeschafft habe für den PC und noch mehrere „normale“ HDDs habe, möchte ich diese beiden Vorzüge (SSD=Schnell, HDD=viel Speicherplatz) vereinen.

Auf dem PC ist die VMware Workstation installiert. Einen DemoServer der unter Windows Server 2012 R2 läuft, ist ebenso vorhanden. Um die beiden Disken zu vereinen werden jeweils virtuelle Disken dem Server bereitgestellt:

1. Disk: 60GB SSD Storage

2. Disk: 200GB HDD Storage

Nun geht es in den ServerManager unter den Punkt „File and Storage Services“. Rechts unten sind die beiden nicht zugeordneten Disken zu sehen.

storagespaces_physicaldisks

Nun muss ein neuer StoragePool angelegt werden. Hier werden alle Disken definiert, die enthalten werden sollten.

Actions -> New Storage Pool. Namen eingeben (in diesem Fall „StoragePool1“) und los geht’s:

StoragePoolAnlage

Damit StorageSpaces den Cache eindeutig zuordnen kann, werden die Parameter „MediaType“ abgefragt. Diese sind (da ja virtuelle Disken) nicht sauber übergeben, was mit dem Powershell-Befehl „Get-PhysicalDisk | Select-Object FriendlyName, MediaType, Size“ rausgefunden werden kann:

powershell-Get-PhysicalDisk

Um den MediaType in „HDD“ umwandeln zu können, wird lediglich dieser PS Befehl benötigt:

Set-PhysicalDisk -FriendlyName PhysicalDisk2 -MediaType HDD

Danach erscheint bei den Disken der richtig/falsche MediaType:

MediaType_HDD

Nun kann eine virtuelle Disk erstellt werden. Hierfür kann nun das Häckchen „Create Storage Tier“ verwendet werden:

create_storage_tiers

Meine Einstellungen seht ihr wiefolgt:

VirtualDiskSettings

Und nach dem virtuellen Disk folgt noch das Volume:

new_volume_wizard_confirmation

Das Volume ist nun als ganz normaler Laufwerksbuchstabe zu sehen.

Um nun die Performance testen zu können, habe ich noch eine weitere Disk dem Server eingehängt (normale HDD ohne SSD-Cache). Nun der Performancevergleich mittels CrystalDiskMark:

SSD-Performance auf Workstation:

crystaldiskmark_nativ_ssd

native SSD, bereitgestellt durch VMware Workstation:

crystaldiskmark_ssd

StorageTiering (mit SSD-Cache):

crystaldiskmark_ssd_cache

ohne SSD-Cache (native HDD), bereitgestellt durch VMware Workstation:

crystaldiskmark_hdd

Vielleicht ist euch aufgefallen, dass die native SSD langsamer ist als das SSD-Tiering. Ich bin mir nicht sicher, aber ich tippe mal eher dass es von der VMware Workstation kommt bzw. vom CrystalDiskMark oder von meiner Herangehensweise des Performancetests. Nichtsdestotrotz hat der Test gezeigt, dass das SSD-Tiering sicherlich ein interessantes Feature ist und sicherlich das ein- oder andere Storagesystem nun durch einen Windows FileServer-Cluster ersetzt wird. Dadurch wird auch sicherlich der Hyper-V geforced, da dieser ja nun auf VHDs auf SMB3.0-Speicherorte unterstützt. Ebenfalls kann die Hyper-V Rolle dazu installiert werden und hätte somit einen sogenannten „Cluster-in-a-Box“.

PS: Der SSD-Cache sollte bei ca. 20-30% liegen, je nach Anwendungsfall.