Storage DRS default affinity

Mit Einführung von vSphere5 kam Storage-DRS als eine neue Funktionalität hinzu. Ähnlich dem herkömmlichen DRS, welches die VM Lastverteilung bezüglich Arbeitsspeicher und CPU zwischen den ESXi Knoten regelt, ermöglicht Storage-DRS eine automatische Lastverteilung in Bezug auf Speicherplatz und I/O.

In der Praxis beobachtet man jedoch häufiger, daß VMs oder einzelne ihrer vDisks nicht migriert werden, obwohl erhöhte Last über einen längeren Zeitraum auftritt. Die Ursache, warum Storage-DRS beispielsweise nicht die vDisk einer VM verschiebt, welche die stark beanspruchte Datenbank enthält, fand ich durch einen Blogartikel von Duncan Epping auf Yellow-Bricks.

Die Standard Einstellung eines jeden Storage Clusters ist “VMDKs zusammenhalten” bzw. “keep VMDK’s together”. Eine Default Einstellung, die sicherlich dem Admin entgegenkommen soll, damit er nicht alle Disks seiner VM auf mehrere LUNs verteilt suchen muß. Der Preis für diese “Ordnung” ist allerdings, daß die Dateien einer VM nur komplett oder gar nicht verschoben werden. In der Praxis bedeutet dies, daß z.B. eine VM mit 5 vDisks von je über 100 GB nur unter extremsten Bedingungen auf eine andere LUN wandern würde. Wünschenswert wäre jedoch, daß beispielsweise nur eine einzelne VMDK Datei verschoben wird, da diese gerade unter erhöhten I/O Druck geraten ist.

Die nett gemeinte, aber etwas unflexible Standardeinstellung dieses Verhaltens läßt sich leicht ändern:

  •  Ansicht Datenspeicher und Datenspeicher Cluster
  • Kontextmenü von Datenspeicher-Cluster öffnen und “Einstellungen bearbeiten” wählen
  • Einstellungen der VM
  • Haken bei “VMDKs zusammenhalten” entfernen. Entweder für einzelne VMs oder global für den gesamten Storage-Cluster.

Weiterführende Literatur

Frank Denneman zum Thema impact of intra vm affinity rules on storage drs.

Bug: svMotion benennt vmdk Dateien nicht um

Normalerweise wird die Benennung von VM Dateien und Diskfiles bei einer Storage vMotion Aktion dem VM Namen angepasst, so daß alle Dateien den Namen der VM tragen. Genau das trat aber heute nicht ein. Der Ordner wurde zwar umbenannt, die VMX Datei und die VMDK Container behielten aber ihre ursprüngliche Bezeichnung. Warum? Eine kurze Suche brachte Licht ins Dunkel. Offensichtlich hat vSphere 5.0.0 in dieser Hinsicht noch einen Bug, der unter KB 2008877 beschrieben wird.

Derzeit bleibt also nur zwei mögliche Methoden:

  • Die (mühsame) Methode der manuellen Umbenennung mittels vSphereCLI (vgl. Renaming a virtual machine and its files)
  • Die VM “kalt” migrieren. d.h. im ausgeschalteten Zustand migrieren. Dabei werden die Namen der Files an den VM-Namen angepasst.

Warten wir auf den nächsten Patch. 🙂

DHCP Server migrieren

Die Migration eines DHCP Servers zwischen zwei Servern mit Windows Server 2003 R2 funktioniert recht einfach mit Bordmitteln.

  • Anmeldung am aktiven DHCP Server der migriert werden soll (fortan als Quellserver bezeichnet). Man benötigt dazu Administrator-Rechte (lokale Adminitratorgruppe, Domainadminstratoren oder DHCP Administratoren).
  • Start > ausführen > cmd
  • netsh dhcp server export C:\temp\dhcpdatabase.dat all
  • Datei dhcpdatabase.dat auf künftigen DHCP Server (Zielserver) kopieren (z.B. nach c:\temp\)
  • DHCP Server auf Quellserver beenden
  • Auf Zielserver die DHCP Rolle installieren, den Server aber noch nicht autorisieren. Serververwaltung > Funktion hinzufügen > DHCP Server
  • Prüfen, ob DHCP Serverdienst auf Zielserver ausgeführt wird
  • auf Zielserver Start > ausführen > cmd
  • netsh dhcp server import c:\temp\dhcpdatabase.dat all
  • Auf Zielserver die DHCP Verwaltung öffnen. Serververwaltung > “Diesen DHCP Server verwalten”. Der Server ist mit einem roten Pfeil markiert. Rechtsklick auf den DHCP Server und “autorisieren” wählen.
  • Test der DHCP Funktionalität im LAN an geeignetem Client.

 

Hilfreiche Links:

DHCP Team Blog:
Migration of DHCP Server from Windows Server 2003 to Windows Server 2008
Microsoft TechNet:
Handbuch zur DHCP-Servermigration

 

Veeam: Patch3 für Backup and Replication 6.0.0.153

Für Veeam Backup and Replication v6.0.0.153 ist Patch3 offiziell verfügbar. Die vorausgegangenen Hotfixes HF1 und HF2 waren nur über den Support erhältlich. Patch 3 hat den Status Release mit der Versionsnummer 6.0.0.181

Eine genaue Beschreibung inklusive Download Link findet man unter:
http://www.veeam.com/kb_articles.html/KB1442

Auszug aus der Beschreibung:

This patch is cumulative and compatible with version 6.0.0.153, 6.0.0.158, and 6.0.0.164

 Install Patch following these instructions:

 Make sure that you are running aforementioned versions. You can verify this by going to Help -> About. From here, make sure that you have no jobs running currently before running the executable.

  1.  Run the executable provided in the FTP link.
  2. Open the Backup and Replication console and allow it to update all components.
  3. Right click on the Backup Infrastructure node and choose Rescan Storage.
  4. Go to the History>System tab, and confirm the latest Storage Discovery task has completed successfully.
  5. Go to Help|About and confirm that build 6.0.0.181 is showing