Autor: Michael Schroeder

Veröffentlicht am

vSphere5: Lizenzmodell aktualisiert

In meinem letzten Artikel zum Thema vSphere5 Lizenzierung setzte ich mich mit dem neuen Preismodell und der Auswirkung auf Bestandskunden auseinander. Nach dem kräftigen Gegenwind aus Richtung der Anwendergemeinschaft hat VMware sein urprüngliches Lizenzmodell für vSphere5 nun nochmals überarbeitet. Insbesondere die vRAM Menge pro Sockel-Lizenz wurde deutlich erhöht.

Quelle: VMware

Mein Rechenbeispiel des ursprünglichen Posts sieht nun etwas verändert aus:

Ich ging aus von 3 ESX Hosts mit je 2 CPU und je 96GB RAM (Gesamt RAM: 288GB)

  • vSphere4 Standard: 6 Lizenzen (nutzbarer Gesamt RAM 288GB)
  • vSphere5 Standard: 6 Lizenzen mit je 32GB vRAM. Nutzbarer Gesamt RAM: 192GB (vorher 144GB)
  • vSphere5 Enterprise: 6 Lizenzen mit je 64GB vRAM. Nutzbarer Gesamt RAM: 384GB (vorher 192GB)
  • vSphere5 EnterprisePlus: 6 Lizenzen mit je 96GB vRAM. Nutzbarer Gesamt RAM: 576GB (vorher 288GB)

Damit sieht die Rechnung schon bedeutend besser aus. Selbst im Standard Modell muß der Kunde keine Lizenzen nachkaufen. Er hat zwar nicht genügend vRAM Lizenzen für seine physischen 288GB, jedoch darf man bei einem ESX Cluster nicht mit Vollauslastung rechnen. Es sollte grundsätzlich ein n-1 Modell gefahren werden. D.h. ein Knoten kann ausfallen und die restlichen übernehmen die Last. Für drei Knoten bedeutet das man darf jeden Knoten im Schnitt nur zu zwei Dritteln auslasten um nicht die Hochverfügbarkeit zu gefährden. Eine 2/3 Auslastung in Bezug auf RAM bedeutet die Anlage hat einen maximalbedarf von 192GB vRAM – und genau das ist durch die neue Lizenz abgedeckt. Im Fehlerfall wird das vRAM des ausgefallenen Hosts den verbleibenden Servern zur Verfügung gestellt. D.h. sie haben weiterhin 192GB vRAM, was ihrer physischen Kapazität entspricht.

Wer nicht mit Papier und Bleistift rechnen möchte, kann mit Hilfe eines Powershellskripts von Hugo Peeters den Lizenzbedarf einer bestehenden Anlage prüfen. Dieses Skript wurde bereits auf das neue Modell angepasst.

VMware hat ebenfalls reagiert und bietet Informationen und ein Berechnungstool (vSphere Licensing Advisor) an. Diese wichtige Info stammt von Yellow-Bricks.

Veröffentlicht am

Toten Pfad zum Target entfernen

Nach einem Infrastruktur Änderung änderten sich Pfade zu LUNs. Zuvor wurde ein Fibrechannel Point-to-point Verkabelung auf Fabric umgestellt. Der ESX Host sah dann sein Target auf einem neuen Pfad und markierte den alten als tot (rot). Ein Adapter rescan brachte zunächst keinen Erfolg. Man muß den HBA zwingen, tote Pfade zu entfernen. Das funktioniert mit einem Befehl der vSphereCLI.

esxcfg-rescan --server <VC> --username --vihost <ESX> -d vmhba1

Der Parameter -d bedeutet laut Manpage “Scan removing dead devices”.

Veröffentlicht am

VM mit falscher Changed Block Tracking Information

Im Protokoll einer Veeam Sicherung trat neulich folgende Meldung auf:

Verifying changed block tracking…
Disk “Festplatte 2” has incorrect changed block tracking configuration.

Den Lösungsansatz lieferte das Protokoll selbst.

One or more VM disks have incorrect changed block tracking configuration. To resolve this, open VMware vSphere Client, right-click the VM, choose Edit Settings, Options tab, select General, click Configuration Parameters, and set all entries with ‘ctkEnabled’ substring to false. Veeam Backup will then automatically re-enable changed block tracking with the correct settings during the next job run.

Um dies zu korrigieren verfährt man folgendermaßen:

vSphere Client Offnen und die VM markieren. [Einstellungen bearbeiten] > Tab [Optionen] > [Allgemein] > [Konfigurationsparameter]. Sollte das Feld [Konfigurationsparameter] grau sein, so liegt es daran, daß die VM noch läuft. Für Modifikationen muß diese zuvor herunter gefahren werden.

Dort alle SCSI-Nodes suchen und den Wert bei ctkEnabeled auf “false” setzen. CTK wird beim nächsten Backup automatisch wieder auf “true” gesetzt.

 

Die VM darf zu diesem Zeitpunkt keine Snapshots haben. Vgl. hierzu KB Artikel 1020128.