VMware VMFS Volume Management – Resignaturing

Das VMware Virtual Machine File System (VMFS), das uns in ESX(i) eigentlich schon seit Version 1.0 begleitet, ist bei der Verwendung von Block-based Storage das Fundament für den Betrieb von virtuellen Maschinen.

Anfangs noch als Single-Host-Filesystem, ist es heute in ESXi 6.0 nun bis zur Version 5.61 gereift. Inzwischen ist es absolut selbstverständlich, das mehrere ESXi-Hosts parallel auf ein VMFS-Volume zugreifen und dadurch auch Features wie vMotion, HA, DRS etc. problemlos funktionieren.

Auch das störende 2 TB Limit ist mit vSphere 5.5 (VMFS 5.60) gefallen und macht es seitdem möglich, VMFS-Datastores mit einer Größe von bis zu 64 TB zu erstellen.

Was ich persönlich jedoch festgestellt habe, ist das immer wieder etwas Verunsicherung hinsichtlich VMFS herrscht. Und zwar immer spätestens dann, wenn es beispielsweise im Rahmen eines Restores auf Basis eines Array-Based LUN-Clones um das Thema VMFS-Resignaturing geht.

Aus diesem Grund möchte ich hier versuchen, etwas Licht ins Dunkle zu bringen und zu erklären, wie ein ESXi-Host überhaupt eine VMFS-Signatur erzeugt und welche Kriterien dabei eine Rolle spielen.

Ich taufe dich auf den biblischen Namen…4fbfff40-d0358207-e61a-d067e5face92

Um  innerhalb eines Clusters ein VMFS-Volume eindeutig kennzeichnen, erzeugt der ESXi-Host (über den die Formatierung mit VMFS angestoßen wird), eine Signatur nach folgendem Schema:

VMFS volume signature = LUN-ID + LUN-Seriennummer

VMFS_Volume_Signature_create

Das bedeutet, auf Basis der LUN-ID und der Disk-Serial Number (die beide vom Storage-Array präsentiert werden) bildet der ESX-Host die Signatur und schreibt diese in den Header des VMFS-Volumes. Dieser Header wird auch “Superblock” genannt.

Eine solche Signatur (UUID) kann z.B. wie folgt aussehen: 4fbfff40-d0358207-e61a-d067e5face92

Insgesamt besteht die UUID wiederum aus 4 einzelnen Komponenten:

  •  Systemzeit (4fbfff40) – Uhrzeit zu der die Signatur des VMFS-Volumes erfolgt ist
  • CPU Timestamp – TSC Stempel (d0358207)
  • Zufallsnummer (e61a)
  • MAC Addresse – MAC des Uplinkadapter des ESXi-Hosts, der die initiale Signatur des VMFS-Volumes vorgenommen oder als letztes verändert hat (d067e5face92)

Sobald das Volume signiert wurde, mounten automatisch alle anderen ESXi-Host im Cluster den Datastore und “merken” sich die Signatur.

Auf der CLI kann die UUID eines VMFS-Datastores z.B. über das Kommando:

esxcli storage core path list

ermittelt werden.

Neben dem Superblock, gibt es auch noch in jedem Datastore eine versteckte Datei mit dem Namen “.vh.sf”.

Ohne es eindeutig zu wissen, geht die Gerüchteküche davon aus, das “vh” für Volume-Header steht und ebenfalls die UUID sowie weitere VMFS-Metdaten enthält.

Über einen Hexdhmp der ersten 256 Bytes der vh.sf sehen wir folgendes Ergebnis (VMFS-UUID in gelb markiert).

Hexdump_VMFS

LUN-Clones und das UUID-Desaster

Soweit so gut. Interessant wird es jedoch, wenn wir z.B. Storage-seitig einen LUN-Clone auf Basis eines Snapshots erzeugen und diesen an einen ESXi-Host verbinden wollen.

Hier ensteht aus Sicht des ESXi-Servers nun eine Problemsituation:

Der LUN-Clone zeigt dem ESXi-Host VMFS-UUID, jedoch stimmen sowohl die LUN-ID als auch die Disk-Seriennummer nicht mit den im Superblock gespeicherten Werten überein.

Da es nie zwei aktive VMFS-Volumes mit der gleichen UUID geben darf, ist hier das Ergebnis: Der ESXi-Host wird diese LUN nicht mounten, da er die LUN als Snapshot interpretiert.

In der vmkernel.log des jeweiligen Host sind daher z.B. folgende Einträge zu finden:

LVM: 8445: Device naa.0012345012345678:1 detected to be a snapshot:

LVM: 8445: Device eui.0017380012020364:1 detected to be a snapshot:
LVM: 8452: queried disk ID: <type 1, len 17, lun 36, devType 0, scsi 0, h(id) 7683208289187576905>
LVM: 8459: on-disk disk ID: <type 1, len 17, lun 17, devType 0, scsi 0, h(id) 7683208289187576905>

Einzige (sinnvolle) Möglichkeit um den Snapshot trotzdem mounten zu können, ist ein sog. VMFS Resignature. Hierbei erhält das Volume eine neue Signatur und wird dadurch wieder “eindeutig” gegenüber dem Original-Datastore.

resigGUI-1024x300

Genau das ist übrigens auch die Vorgehensweise von nahezu allen Backup-Produkten für vSphere, die im Restore-Prozess mit LUN-Clones arbeiten:

  1. LUN-Clone erzeugen
  2. LUN-Clone an ESXi-Hosts mappen
  3. VMFS-Resignature ausführen
  4. Datastore mounten
  5. Restore durchführen

Klingt logisch, oder ;-)?!

It's only fair to share...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on RedditPrint this page

Howto copy files from/to a VM without network access with vSphere PowerCLI

Heute möchte ich kurz auf ein Werkzeug bzw. CMDlet der vSphere PowerCLI hinweisen, das absolut nicht bahnbrechend neu ist, aber bei Kunden immer wieder für Verblüffung sorgt.

Am Anfang war die isolierte Testumgebung…

Was tut man in vSphere normalerweise wenn man einfach und unkompliziert eine abgeschottete Testumgebung aufbauen will? Richtig: Alle für den Test benötigten VMs, werden auf einem gemeinsamen vSwitch konfiguriert, der jedoch über keinerlei Uplink-Adpater verfügt.

Die Kehrseite der Medaille: Um zum Beispiel Dateien in oder aus der VM heraus zu bekommen, steht man ohne Uplink ins Netzwerk vor einer kleinen Hürde.

Natürlich kann man nun über eine Vielzahl von Möglichkeiten nachdenken, wie man Files trotz Isolierung in solche abgeschotteten VMs transportieren kann.

Das beginnt oft bei der selbstgebauten “Transfer-ISO” bis zum Re-Mount der VMDK an eine andere VM mit Netzwerkzugriff. Eine Möglichkeit die aber manchmal übersehen wird, ist das Schweizer-Taschenmesser für vSphere: Die vSphere PowerCLI.

PowerCLI to the rescue! – Copy-VMGuestFile

“Gibt’s für das oben genannte Problem denn nicht auch was von PowerShell?”

Die vSphere PowerCLI verfügt in der aktuellen Version 6.0 R3 über 400 CMDlets, darunter eben auch ein Werkzeug das uns bei der oben beschriebenen Thematik extrem gute Dienste leistet.

Der Name ist hier Programm: Copy-VMGuestFile

Ich möchte die Verwendung einfach kurz auf Basis eines kleinen Beispiels zeigen.

Ausgangslage: Ein Windows Server (base-w12-01b) ist komplett vom Netzwerk isoliert und die Datei C:\Transfer\properties.conf soll über das CMDlet Copy-VMGuestFile auf den lokalen Client kopiert werden.

Zum Test: Das Default-GW ist nicht erreichbar und auch die vNIC der VM ist nicht verbunden:

2016-03-20 09_24_48-HOL-SDC-1602 vSphere with Operations Management 6_ Advanced Topics - Lab Console
2016-03-20 09_25_48-HOL-SDC-1602 vSphere with Operations Management 6_ Advanced Topics - Lab Console

Um nun die Datei “properties.conf” auf meinen lokalen Client zu kopieren, reicht der Aufruf der PowerCLI und die Verwendung von Copy-VMGuestFile:

2016-03-20 09_22_20-HOL-SDC-1602 vSphere with Operations Management 6_ Advanced Topics - Lab Console

Copy-VMGuestFile -Source C:\Transfer\properties.conf -Destination C:\temp -VM base-w12-01b -GuestToLocal -GuestUser holuser 
-GuestPassword VMware1!

Die zu übergebenen Parameter sind sehr sprechend, hier jedoch trotzdem ein kurzer Überblick:

Source = Pfad der zu kopierenden Datei innerhalb der VM

Destination = Zielpfad des lokalen Clients in der die Quelldatei kopiert wird

VM = Name der VM im vCenter-Inventory

GuestToLocal = Richtung in die kopiert werden soll (VM –> Lokaler Client)

GuestUser = Name eines lokalen Users innerhalb der VM

GuestPassword = Passwort des verwendeten Benutzers im Guest-OS

Natürlich kann man die Parameter GuestUser bzw. GuestPassword über ein Credential-Objekt abfragen um das Ganze nicht im Klartext eingeben zu müsen, aber ich denke am Beispiel ist recht schon ersichtlich, wie genial einfach Copy-VMGuest-File zu verwenden ist.

Das Ergebnis ist (ohne große Überraschung), das am lokalen Client im Pfad “C:\temp” nun die aus der VM kopierte Datei abgelegt wurde:

2016-03-20 09_29_21-HOL-SDC-1602 vSphere with Operations Management 6_ Advanced Topics - Lab Console

Fazit

Copy-VMGuest File ist ein super Werkzeug wenn es darum geht, Dateien aus oder in eine VM ohne Netzwerkkonnektivität zu bewegen (-GuestToLocal oder -LocalToGuest).

In Kombination mit Wildcards bzw. der in PowerShell üblichen Pipes, lassen sich ohne Mühe einfach und schnell Dateien hin- und herkopieren.

Wer bis jetzt noch keinerlei Berührung mit der vSphere PowerCLI hatte, dem möchte ich die folgenden 2 Links noch wärmstens empfehlen:

Das passende Hands-On Lab von VMware mit Beispielen und Übungen die aufzeigen, warum die PowerCLI ein so mächtiges Werkzeug darstellt.

Für alle die direkt praktische Scripting-Beispiele suchen oder “die Tiefen der PowerCLI” ergründen wollen, kann ich nur den Blog von Alan Renouf ans Herz legen.

Dieser Mann ist für mich persönlich einer der genialsten Köpfe auf diesem Planeten, wenn es um Automatisierung und generell das Thema APIs in vSphere geht und ich kann mich seinem persönlichen Motto abschließend einfach nur vollends anschließen: Virtually everything is POSHable ;-)!

It's only fair to share...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on RedditPrint this page

vSphere Peformance Troubleshooting Part2: Latency Sensitivity

In diesem zweiten Teil der Serie möchte ich über das vSphere-Feature “Latency Sensitivity” schreiben. Mit diesem Feature lassen sich ggf. nun endlich auch Systeme virtualisieren, die bisher als “nicht virtualisierbar” galten. Das betrifft insbesondere Applikationen, die eine extrem geringe Latenz voraussetzen.

Zum Ersten Teil der vSphere-Troubleshooting-Serie: vSphere Peformance Troubleshooting Part1: CPU Basics

Über das Feature Latency Sensitivity
Latency Sensitivity hilft dabei zusätzliche Latentz, welche durch die Virtualisierung entsteht, zu zu minimieren indem Hardware-Ressourcen direkt an die VM durchgereicht werden. Dadurch ist natürlich das Überprovisionieren dieser Ressourcen auch nicht mehr möglich.

Beispiel: Wenn zwei VMs mit nur einer vCPU und Latency Sensitivity “high” auf einem ESXi-Host mit DualCore CPU laufen, sollten keine weiteren VMs mehr auf diesem Host laufen. Bei einem QuadCore können die beiden anderen Kerne – wie gewohnt genutzt werden.

Dennoch ist es möglich latenzsensitive und “normale” VMs in einer vSphere-Umgebung laufen zu lassen.

Da das Überprovisionieren eines der Haupt-Benefits der Virtualisierung ist,  sollte Latency Sensitivity wirklich nur für extrem latenzkritische Applikationen (Anforderung: Antwortzeiten im zehntel Millisekunden-Bereich) aktiviert werden. Im Trading-Business ist dies beispielsweise erforderlich (Server werden hier normalerweise noch auf “Blech” installiert). Um weiter zu optimieren, sollte zusätzlich auch über die Konfiguration von single-root I/O virtualization (SR-IOV) nachgedacht werden. Weitere Best Practices  sind im Guide Best Practices for Performance Tuning of Latency-Sensitive Workloads in vSphere VMs zu finden.

Virtual NIC Coalescing
Virtual NIC Coalescing ist ein per default aktiviertes vSphere-Feature, welches die Kommunikation zwischen dem Host (VMKernel) und der virtuellen Maschine (über die virtuelle Netzwerkkarte = vNIC) einschränkt. Ohne Virtualisierung werden Pakete direkt/sofort über die Netzwerkkarte, gesendet. Das Feature vNIC Coalescing sorgt dafür, dass die Pakete kurz gecached werden und erst dann gebündelt über den VMKernel zum Netzwerk-Interface gesendet werden. Dadurch werden zusätzliche (normalerweise unkritische) Latenzen (und Jitter) erzeugt. Wird aber die Latency Sensitivity auf “Hoch” gestellt, wird Virtual NIC Coalescing beim Einsatz der VMXNET3-vNIC (paravirtualisiert) deaktiviert. Hierdurch ensteht höherer CPU-Overhead.

Zusammenfassung: Weniger Überprovisionierung, höhere CPU- und RAM-Belegung und mehr Stromverbrauch im Tausch gegen geringere Netzwerk-Latenz (und reduzierten Jitter) der VM. Man sollte sich also gut überlegen, ob das Feature wirklich benötigt wird.

Wo Latency Sensitivity nicht hilft
Es wird wirklich nur die Netzwerk-Latenz optimiert. Wenn beispielsweise die Applikation aufgrund hoher Storage-Latenz zu langsam ist, wird das Aktivieren des Features keine Änderung herbeiführen.

Voraussetzungen:
– 
Geringe CPU-Auslastung in der Umgebung (Jede VM bekommt idealerweise exklusiv einen pCPU-Core pro konfigurierten vCPU)
– Die VM sollte nicht mehr vCPUs bekommen, als der ESXi-Host Cores zur Verfügung hat (so wird nur ein NUMA-Node verwendet)

Einrichten von Latency Sensitivity
Zu allererst muss 100% RAM und sollte 100% CPU für die VM reserviert werden.

Der MHz-Wert sollte dem der pCPU des ESXi-Hosts entsprechen (es müssen wenige MHz weniger angegeben werden, damit der Wert akzeptiert wird).cpu_reservation

ram_resevation
Bei nicht reservierten Memory startet die VM nicht:error_invalid_memsizeNun Kann die Latency Sensitivity auf “High” gesetzt werden. Das geht unter VM Settings -> VM Options -> Advanced ->  Latency Sensitivity = “High”
enable_latency_sensitivityDie Warnung, dass die CPU-Reservierungen überprüft werden soll erscheint immer, auch wenn die CPU-Reservierung schon gesetzt ist.

Was nun als erstes auffällt, ist der hohe CPU- und Memory-Verbrauch von 100%, obwohl die VM gerade im Idle-Zustand ist. Das sollte aber mit aktuellen Intel-Prozessoren nicht passieren und liegt vermutlich an der VMware-Lab-Umgebung:

cpu_ram_consumption

Im esxtop sieht man nun (anhand der CPU-Ready-Time), dass sich die beiden anderen VMs auf dem Host den zweiten Core teilen, obwohl sie beide zu 100% ausgelastet sind:

esxtop_rdy_time

Hinweis: Ist die Umgebung überprovisioniert, kann es passieren, dass trotzdem andere VMs ohne konfigurierte Latency Sensitivity auf den selben pCPUs laufen. Dadurch wird natürlich die Leistung der kritischen VMs eingeschränkt. Trotzdem werden sie aber vom CPU bevorzugt behandelt und weisen geringere RDY-Times und Antwortzeiten auf. Die “unwichtigeren” VMs werden dann sofort CPU-Technisch beeinflusst, auch wenn die kritische VM keine CPU-Zeit benötigt.

Der Latenz-Test
Für den Test habe ich auf dem ESXi-Host CPU-Affinities für zwei VMs wie folgt konfiguriert:

esx-02a:
– perf-worker-05a (100% CPU-Last) -> CPU 0
– perf-worker-06a (100% CPU-Last) -> CPU 1
– perf-worker-04a (Latency Sensitivity “High”) -> keine CPU-Affinitie

esx-01a:
– perf-worker-03a (Linux Host zum Ping-Test)

Dadurch werden vom esx02-a beide physikalischen Cores zu 100% ausgelastet. Wird nun zusätzlich die VM perf-worker-04a eingeschaltet, muss sie sich entweder mit perf-worker-05a oder mit perf-worker-06a den pCPU teilen, da aufgrund der CPU-Affinities-Einstellungen der pCPU nicht komplett “frei gemacht” werden kann. In diesem Fall teilen sich perf-worker-04a und perf-worker-06a auf dem selben Core. Obwohl perf-worker-04a keine Last verursacht, hat die VM eine deutlich geringere Ready-Time:

esxtop_new

Ping-Test von perf-worker-04a zu perf-worker-03a
Auch wenn viele Netzwerker mir hier vielleicht nicht zustimmen werden, finde ich, dass ein Ping ein idealer Test ist, um die Round Trip Time (Paketumlaufzeit, hin + zurück) zu messen. In diesem Fall habe ich es mit folgendem Befehl gemacht (sendet innerhalb einer Sekunde so viele Pings wie möglich und gibt Statistiken aus):

ping -f -w 1 192.168.100.153

Als Vergleichswert habe ich mich für die maximum deviation (mdev) (= Standardabweichung) entschieden. In einer “echten” Umgebung sollten alle Werte in etwa gleich (min/max/avg) und natürlich auch unter 1 ms sein.

Latency Sensitivity “Normal”

ping_before

 

Latency Sensitivity “High”

ping_after

 

Fazit

Auch wenn im VMware-HandOn-Labs starke Schwankungen zu messen sind, was die Latenz angeht, sind Latency Sensitivity “normal” und “High” bei ausgelasteten CPUs deutliche Unterschiede zu messen. Dennoch würde ich nicht hergehen und jedem Kunden diese Konfiguration empfehlen, um kritischen Anwendungen zu beschleunigen. Ist also wirklich der “Need” da , sollte ein POC in der Kunden-Umgebung aufgebaut und dort gemessen werden.  Erst dann lassen sich die Werte mit denen eines Bare-Metal-Servers valide vergleichen.

Wer sich noch tiefer mit dem Thema befassen will: http://www.vmware.com/files/pdf/techpaper/latency-sensitive-perf-vsphere55.pdf

Gibt es schon andere Erfahrungen oder Einwände? Wir freuen uns auf – wie immer – Kommentare.

It's only fair to share...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on RedditPrint this page

Tech Nugget: Volume Recovery Queue in Clustered Data ONTAP 8.3

Hi zusammen,

im heutigen Post möchte ein Feature in Clustered Data ONTAP 8.3 vorstellen, das bis heute von den meisten noch gar nicht wirklich wahrgenommen wurde.

Die Rede ist von der Volume Recovery Queue.

Auftrag ausgeführt: Volume gelöscht….OMG!!!

Ich denke jeder hat sich schon mal in der unangenehmen Situation wiedergefunden, das versehentlich ein falsches Volumes gelöscht wurde. Sei es aufgrund eines zwischenmenschlichem Kommunikationsfehlers oder auch schlicht einer Verwechslung des Volumenamens.

Hier ist steigt dann meistens recht schnell der Stresspegel, da man in solch einer Situation nur noch einen Restore von der SnapVault-Secondary oder einer anderen Quelle anstoßen kann.

Nichtsdestotrotz: Da wir hier nicht mehr mit einem Snapshot-basierten Recovery-Ansatz wie z.B. FlexClone oder SnapRestore arbeiten können, ist die Dauer des Restores nun effektiv von der zu wiederherstellenden Datenmenge abhängig.

Gelöscht ist gelöscht….oder etwa nicht?

Im 7-Mode gab es nach einem ausgeführten “vol destroy” eigentlich keinen praktikablen Weg mehr zurück: ONTAP hat im Hintergrund damit begonnen, die nicht mehr verwendeten Blöcke freizugeben und damit die Existenz des Volumes komplett zu eliminieren.

Genau an dieser Stelle hat NetApp jedoch ab Data ONTAP 8.3 die sog. Volume Recovery Queue implementiert.

Das bedeutet ganz konkret: Wird ein Volume gelöscht, wird es im ersten Moment von ONTAP ausschließlich umbenannt sowie im Filesystem ausgeblendet. Es verbleibt aber standardmäßig die nächsten 12 Stunden noch für ein Recovery erhalten.

Gleichzeitig bedeutet dieser Umstand aber auch, das der theoretisch durch das Löschen freiwerdende Platz erst nach dem Ablauf von 12 Stunden nutzbar bzw. im Aggregat sichtbar wird.

Um es etwas kurz und übertrieben darzustellen: Clustered ONTAP verfügt nun also über eine Art “FlexVol Papierkorb” ;-).

Schöne Geschichte! Und wie kann ich das jetzt in der Praxis einsetzen?

Ich möchte das Ganze in einem kurzen CLI-Beispiel darstellen.

Wichtig vorab: Die Volume-Recovery Optionen/Möglichkeiten sind ausschließlich im Diag-Modus verfügbar (set diag).

cluster1::*> vserver show -vserver SV1 -fields volume-delete-retention-hours
vserver volume-delete-retention-hours
------- -----------------------------
SV1     12

Über diesen Weg kann pro SVM kontrolliert bzw. konfiguriert werden, wie lange Volumes nach einem Löschvorgang in der Volume Recovery Queue aufbewahrt werden sollen (Default: 12 Stunden).

Innerhalb diesen 12 Stunden kann dann das Volume mit einem einzigen Kommando wiederhergestellt werden.

Schauen wir uns als nächstes das zu löschende Volumes etwas genauer an:

cluster1::*> vol show datavol -fields dsid
vserver volume  dsid

------- ------- ----
SV1     datavol 1026

Das Volume trägt den Namen “datavol” und hat innerhalb ONTAP die Dataset-ID 1026. Diese ID wird uns im übernächsten Schritt nochmal begegnen.

Nun löschen wir  das Volume über “volume destroy”:

cluster1::*> vol offline -volume datavol
Volume "SV1:datavol" is now offline.

cluster1::*> vol destroy datavol

Warning: Are you sure you want to delete volume "datavol" in Vserver "SV1" ? {y|n}: y
Volume "SV1:datavol" destroyed.

Und jetzt kommt die eigentliche “Magie” der Recovery Queue zum Einsatz. Über das Kommando: volume recovery-queue show sehen wir folgendes Ergebnis:

cluster1::*> volume recovery-queue show
Vserver   Volume      Deletion Request Time     Retention Hours
--------- ----------- ------------------------  ---------------
SV1       datavol_1026
                      Sun Mar 13 08:25:55 2016               12

Das Volume existiert also noch! Es ist nur im aktiven Dateisystem nicht mehr sichtbar und wurde umbenannt. Nämlich auf “datavol_1026“.

Soll das Volume nun wiederhergestellt werden genügt eine einzige Zeile:

cluster1::*> volume recovery-queue recover -volume datavol_1026 -vserver SV1

Notice: When you bring a recovered volume online, there may be a temporary drop in performance for all volumes in the same aggregate.

Volume recovery successful for volume "datavol_1026" in Vserver "SV1".

Nun ist das Volume wieder im aktiven Dateisystem sichtbar und muss nur noch auf den Originalnamen umbenannt sowie wieder online gebracht werden:

cluster1::*> vol rename -volume datavol_1026 -newname datavol
[Job 78] Job succeeded: Successful

cluster1::*> vol online -volume datavol
Volume "SV1:datavol" is now online.

And that’s it! Für dieses Feature hätte ich im 7-Mode an manchen Tagen wirklich mein letztes Hemd gegeben :-)…

Und wie kann ich im Zweifelsfall ein Volume aus der Recovery-Queue komplett löschen? 

Oft möchte man verständlicherweise nicht erst 12 Stunden warten, bis man den Platz des gelöschten FlexVols im Aggregat zurückbekommt.

Wenn man sich also wirklich 100%ig sicher ist das passende Volume gelöscht zu haben und es komplett loswerden will, wäre:

“volume recovery-queue purge” das Mittel der Wahl.

cluster1::*> vol recovery-queue purge -volume datavol_1026
Initializing

Fazit

Die Volume-Recovery Queue ist zwar aktuell noch ein Feature das nicht wirklich bekannt ist, aber in der Praxis beim Kunden als auch für mich im Feld ein wichtiges Werkzeug für den Notfall sein wird.

Da kann ich nur sagen: Kudos to NetApp!!

Weitere Infos zur Volume Recovery Queue gibt’s natürlich auch in der NetApp KB:

https://kb.netapp.com/support/index?page=content&id=1014958

https://kb.netapp.com/support/index?page=content&id=1015626

 

It's only fair to share...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on RedditPrint this page

vSphere Peformance Troubleshooting Part1: CPU Basics

Hallo lieber Leser,

heute möchte ich mich mit den Basis-CPU-Konzepten von vSphere und einem Troubleshooting-Ansatz beschäftigen. Dazu habe ich mir in VMware HandsonLabs eine passende Testumgebung erstellen lassen. Falls wer Interesse hat: http://labs.hol.vmware.com/

Zu allererst sollte man wissen, welche die Haupt-CPU-Perfomanceprobleme sind:

Hohe Ready Time
Die CPU Ready Time bezeichnet die Zeit in der eine virtuelle Maschine bereit ist CPU-Ressourcen zu bekommen (zu rechnen), aber diese nicht vom ESXi-Host bekommt. Der Grund dafür ist normalerweise, dass der vSphere Scheduler keinen “freien” physikalischen CPU finden kann. Das ist im Rahmen einer virtualisierten Umgebung ganz normal, da sich die vCPUs (virtuelle CPUs) vieler virtuellen Maschinen den physikalischen CPU (pCPU) teilen müssen. Ab einer CPU Ready Time ab ca. 10% ist von trägen VMs auszugehen.

Hohe Costop Time
Eine hohe CPU Costop Time bedeutet normalerweise, dass die VM mehr vCPUs als erforderlich hat, welche die Performance der gesamten VM bremsen. Beispiel: Eine VM hat 4 vCPUs von denen nur zwei richtige belastet werden. Wenn der Host nun relativ ausgelastet ist, ist es für den vSphere Scheduler schwieriger, 4 freie pCPUs zur selben Zeit zu finden (alle 4 vCPUS müssen natürlich gleichzeitig “Rechenzeit” bekommen). Auch hier ist ab einem Wert von ca. über 10% von einer negativen Beeinflussung auf die VM-Performance auszugehen.

CPU Limits
In vSphere lassen sich CPU-Limits vergeben. Durch diese werden einer VM weniger Ressourcen gegeben, als aus der Gast-Sicht verfügbar sind. Das sollte bei einem Performance-Problem als erstes überprüft werden. CPU Limits sollten nur mit einem guten Grund vergeben werden.

Host CPU Saturation
Laut VMware ist es bei einer hohen Sättigung der Host CPUs (über 85%) für den Scheduler zunehmend schwerer freie CPU-Ressourcen für die VMs (gerade bei multi vCPU VMs) zu finden. Klare Empehlung: Die CPU-Auslastung der ESXi-Hosts sollte nicht mehr als 85% betragen (auch um HA-Fälle abdecken zu können)!

Guest CPU Saturation
Das Gleiche gilt natürlich auch für die Auslastung der vCPUs in der Guest-VM. Ist die Auslastung innerhalb der VM dauerhaft über 90%, ist dies ein guter Indikator, eine weitere vCPU hinzuzufügen, sofern das OS oder die Applikation Multithreading-Fähig ist.

Incorrect SMP Usage
Virtual SMP bezeichnet die VMware-Technologie, welche für die Multiprozessor-Technologie verantwortlich ist, sprich: Eine VM kann 8 vCPUs haben, auch wenn der ESXi-Host nur zwei CPUs mit jeweils 4 Cores hat. Weitere Infos über virtual SMP.

Es gibt Anwendungen, die können beispielsweise kein multithreading über mehr als 4 Cores. Hat die entsprechende VM aber nun 8 Cores werden von der Applikation trotzdem nicht mehr als 4 genutzt. In diesem Fall ist die VM fehlerhaft konfiguriert.

Low Guest Usage
Melden Anwender Performance-Probleme, obwohl die vCPUs der VM nicht ausgelastet sind und oben genanntes (Costop time, ready time, …) trifft auch nicht zu, ist davon auszugehen, dass entweder die Anwendung nicht richtig konfiguriert ist oder andere Ressourcen braucht (mehr RAM, schnelleren Storage, mehr Netzwerk-Performance, etc.).

Die CPU-Zeitscheibe einer virtuellen Maschine
Aus vSphere-Sicht gibt es für die VM nur die Wait-, Ready- (RDY), Costop- (CSTP) und Run-Time, wobei nur die Ready- und Costop-Time die VM von Ausführen der Rechenoperation abhält:

cpu_sched_time

Eine hohe Wait-Time entsteht entweder aufgrund eines Idle-Zustands im Guest oder aufgrund von sogenannten VMwait-Operationen (z.b beim Swapping). Eine hohe RDY-Time entsteht auch, wenn ein CPU-Limit eingerichtet ist (MLMTD).

 

Beispiel: Basis-Troubleshooting mit dem vSphere WebClient
Szenario: In der virtuellen Umgebung laufen zwei VMs mit jeweils einem vCPU. Es gibt zwei ESXi-Hosts im Cluster mit 4 logischen Prozessoren. Beide VMs laufen auf dem selben Host, da jede VM aber nur einen vCPU hat, sollte es keine Performance-Probleme geben (der ESXi-Host verteilt die vCPUs auf freie pCPUs). Trotzdem beklagen Anwender CPU-Probleme. Auf jeder der beiden VMs läuft eine Software, welche alle verfügbaren vCPUs zu 100% auslastet.

uebersicht_vcenter

cpu_config_vm

esxi_host_vcenter

 

Vorgehensweise zum Troubleshooting

Überprüfung der CPU-Auslastung im Performance-Graph:
Das geht im vSphere WebClient unter der VM, dann Überwachung -> Leistung -> Erweitert:
performance_graph

Dort lassen sich unter Diagrammoptionen die verschiedenen Counter auswählen. In diesem Fall habe ich mich für Ready (CPU Ready Time), Demand (wieviel Mhz braucht die VM) und Usage in Mhz (wieviel Mhz bekommt die VM) entschieden. Hier sieht man nun deutlich, dass die VM ca. 2800 Mhz benötigt (demand), aber nur ca. 1400 Mhz bekommt (Usage in Mhz) und das bei einer Ready Time von ca. 10.000/20.000ms = 50%. In diesem Fall haben wir also ein deutlich erkennbares Performance-Problem:
performance_demand_graph performance_cpu_rdy_and_usageDie VM bekommt also genau die Hälfte der benötigten Ressourcen und muss darauf auch noch 50% der Zeit warten. Eine hohe Ready Time weißt immer auf schlechte Performance hin. In diesem Fall lag es daran, dass beide VMs auf den selben CPU “gepinnt” waren. Das lässt sich in den Einstellungen der VM festlegen:

cpu_affinityBeide virtuellen Maschinen liefen also auf “CPU 1”. Nachdem die “1” rausgelöscht wurde, fiel die CPU Ready Time direkt auf Null und “Demand” und “Usage” nähern sich an:

low_cou_ready_timeNun ist zwar das durch falsche Konfiguration erzeugte Problem weg, doch trotzdem hat die VM eine Auslastung von über 90%. Deshalb füge ich eine weitere vCPU hinzu. Da das CPU HotAdd-Feature aktiviert ist, geht das im laufenden Betrieb.

Auch wenn in diesem Fall die VMs nicht genug CPU-Ressourcen bekommen können, beschreibt dieses Vorgehen ganz gut die Schritte, welche ich auch mit einem Kunden mit CPU-Performance-Problemen durchgehen würde.

 

Grobe Regeln

  • Die Anzahl der VCPUs möglichst gering halten (nicht mehr als benötigt)
  • Laut VMware: 1-4 vCPUs bei einem Dual Socket Host
    • 8 und mehr vCPUs bei einem quad Socket Host
  • Eine VM sollte nicht mehr vCPUs haben also ein physikalischer CPU Cores hat (mehr Infos später im vNUMA-Part)
  • Die pCPUs sollten dauerhaft nicht mehr als 85% ausgelastet sein

Demnächst geht es mit der Performance-Troubleshooting-Serie weiter. Wir freuen uns über Fragen und Anmerkungen in den Kommentaren.

It's only fair to share...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on RedditPrint this page

VSAN CTO & Sizing Calculator – Ein erster Blick

In Ergänzung zum ganzen VSAN-Content der momentan so durch’s Netz geht, möchte ich in diesem Beitrag recht kurz und knapp auf ein Tool von VMware aufmerksam machen, das bei der Planung und Sizing für VSAN unterstützt.

Die Rede ist vom „Virtual SAN CTO and Sizing Calculator“. Dieser Web-Based Calculator führt in 2 bzw. 3 einfachen Schritten zur Empfehlung eines VSAN Ready Nodes bzw. einer passenden HW-Konfiguration.

Das Tool ist zu finden unter: https://vsantco.vmware.com/vsan/SI/SIEV

Schritt 1 – Wie viel darf’s denn sein?

Der erste Schritt ist die Defintion eines VM-Profiles, also der Definition wie die später auf VSAN laufenden VMs „aussehen“ werden (Anzahl vCPUs, Anzahl VMDKs, Größe der VMDKs etc.) als auch wie viele VMs in Summe betrieben werden sollen.

Ebenfalls entscheidend für das Sizing ist der Parameter FTT (Failures to Tolerate), also die Anzahl an Ausfällen von z.B. ESXi-Hosts die toleriert werden können.

VSAN Calculator - Step 1

Im unteren Bereich der Calculators werden auf Basis der oben eingegebenen Werte automatisiert bereits ermittelt, wieviel Speicherkapazität mind. nutzbar zur Verfügung stehen muss, um die Anforderungen umsetzen zu können.  Gleichzeitig besteht hier die Möglichkeit, auch zusätzliche Parameter wie beispielsweise Puffer für zukünftiges Wachstum direkt mit in das Sizing einzurechnen.

VSAN_Env_Req_(2)

 

Schritt 2 – Ready Node oder Do-it-Yourself

Schritt 2 zeigt dann auch schon eine erste Übersicht, welche Ready-Node Konfiguration für die eingegebenen Rahmenparameter am besten geeignet ist. Zusätzlich ist es jedoch auch möglich in der Spalte „Build Your Own“ eine eigene Konfiguration zu definieren, um auf Basis des Ready-Nodes selbst eine Plattform für VSAN zu definieren.

Schritt 3 – Das Ergebnis

Im letzten Schritt erhält man abschließend eine optisch sehr anschauliche Übersicht, wie der VSAN-Cluster auf Basis der angegebenen Werte aussehen wird bzw. welche technischen Eckdaten die Konfiguration mit sich bringt:

VSAN_Calc_Result

Fazit

Ich persönlich finde dieses Tool für ein erstes Sizing für eine VSAN-Installation wirklich sehr interessant, da es einem schnell und unkompliziert einen ersten Überblick über Möglichkeiten und die technischen Anforderungen gibt. Natürlich hat auch der Calculator seine Grenzen und es schadet nie im Zweifelsfall nochmal „klassisch mit Kopf“ nachzuvollziehen ob die ermittele Konfiguration auch wirklich nicht zu viel und nicht zu wenig geplant hat ;-).

 

It's only fair to share...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on RedditPrint this page

NetApp hat neue Schienen namens SwiftRail Kit

Hallo lieber vDont-Leser,

nachdem ich jetzt schon wieder fast eine Woche keine nichts geschrieben habe, wollte ich heute eigentlich einen kleinen Beitrag zur Ransomware  “Locky” schreiben und was man gegen ihn in einer NetApp- und Windows-Umgebung tun könnte um das Schlimmste zu verhindern. Doch heute ist mir aufgefallen, das NetApp neue Rail-Kits hat. Unglaublich! Ein Hersteller, welcher schon immer die gleichen Schienen verwendet hat, hat was neues gemacht! Sollte trotzdem jemand an dem Locky-Artikel interessiert sein, gerne in dem Kommentaren vermerken und ich schreibe ihn. Versprochen!

Das habe ich mir dann auch gedacht: Wen interessiert das? “There ist nothing sexy about hardware” heißt es doch bei NetApp. Und dann auch noch Schienen? Egal. Ich mache es es jetzt trotzdem!

Heute bei einer Installation ist mir aufgefallen, dass es jetzt zwei Typen von Schienen zu geben scheint: Das neue SwiftRail Kit und die “verbesserten” alten.

Die “verbesserten alten” Schienen

Sie sehen in etwa so aus wie die alten, scheinen aber etwa vertärtkt zu sein. Von der Funktion sind sie genau wie vorher. Es gibt zwei verschiedene Ausführungen für rechts und links und es können beliebige Rackmuttern und Schrauben verwenet werden.

IMG_20160222_140042

IMG_20160222_140115

 

Die neuen Schienen “NetApp SwiftRail Kit”

Komisch oder auch “normal” ist, das nicht in jedem Shelf-Karton die neuen Schienen drin sind. Es musste heute also leider gemischt verbaut werden, aber ansonsten sind die neuen Schienen super. Nur zwei kurze Schrauben müssen reingedreht werden und die Schiene hakt sich in das Rack ein. Es geht also alles viel schneller und es bleibt mehr Zeit für die (nebenbei viel interessantere) Software DataOntap. Außerdem gibt es nur noch eine Ausführung, die für die andere Seite des Racks einfach gedreht werden kann und so keine “rechts-links-Verwirrung” mehr gestiftet wird. Als kleiner Nachteil ist mir aufgefallen, dass nun nur noch 10x32er Schrauben (Zoll-Maße) zum befestigen der Shelfs verwendet werden können. Für Kunden, die nur M5 oder M6 in ihrem RZ haben wollen: Schlecht! Aber macht euch selber ein Bild:

NetApp SwiftRail 1 NetApp SwiftRail 2 NetApp SwiftRail Schrauben

Desweiteren habe ich auch noch ein Foto des Installation Guides gemacht (der ist sogar nocheinmal extra in einer Plastiktüte verpackt):

SwiftRail Kit Installation Instructions Page 1

SwiftRail Kit Installation Instructions Page 2

Wenn es noch fragen zu diesem (und anderen Artikeln) gibt, beantworten wir diese gerne in den Kommentaren!

It's only fair to share...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on RedditPrint this page

NetApp MetroCluster 8.3 – Quick Reference Card

Mit dem Release von Data ONTAP 8.3, hat NetApp erstmalig auch die MetroCluster Funktionalität in cDOT eingeführt.

Das Basiskonzept sowie die Grundidee des MetroClusters ist zwar immer noch exakt analog zum 7-Mode, jedoch hat sich an der unterliegenden Architektur doch so einiges getan.

Schon die Tatsache das Konfiguration der SVMs zwischen den Clustern auf Basis von SVM-DR repliziert wird, erfordert im ersten Moment ein Umdenken.

Für mich persönlich war es daher bei meinem ersten Kundenprojekt auf Basis eines cDOT MetroClusters anfangs noch recht zeitaufwendig, auf der Clustershell die entscheidenden Kommandos und Befehle zu finden.

Aber auch hier hat NetApp von Anfang an mitgedacht und eine sog. MetroCluster Quick Reference Card (QRC) erstellt. Diese wird z.B. im Rahmen der offiziellen MCC Installationsfreigabe ausgegeben.

Da ich das Ganze für die ersten Installationen als extrem nützlich und hilfreich empfand, möchte ich dieses kleine “Cheat sheet” hier gerne für alle Interessierten zur Verfügung stellen.

Leider bin ich bis heute an keine digitale Version gekommen, daher habe ich meine QRC einfach kurz eingescannt.

Wer das Ganze als PDF möchte, kann sich die Reference Card auch schnell und einfach hier herunterladen.

Viel Spaß bei den Installs und falls euch mal ein Kommando aus dem Gedächtnis entfallen sein sollte: Ihr wisst ja wo ihr fündig werdet ;-).

NetApp_QRC

 

 

It's only fair to share...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on RedditPrint this page

Neue Interessante KB-Artikel 2016 und die Snapshot-Misere 2015

Mir kam gerade spontan der Gedanke einmal die  für mich interessanten aktuell neuen vSphere KB-Artikel kurz auszuzählen und aus meiner Sicht ein wenig zu bewerten.

Zum Hintergrund:

Um immer auf dem neusten Stand der aktuellen VMware-Bug und Patches zu bleiben und mein Kunden stabilste vSphere-Version empfehlen zu können lese ich eigentlich recht regelmäßig dem “KB-Digest” von VMware unter http://blogs.vmware.com/kbdigest/ .

Da ich dazu in diesem Jahr noch nicht richtig dazu gekommen bin hole ich das hiermit nach :-)

Über die VMware Snapshot-Misere in vSphere 5.5 und 6.0

Ich hole hier noch ein wenig weiter aus und beschreibe ein Beispiel-Bug, welchen ich in der Vergangenheit sehr verfolgt habe und was bis vSphere 5.5U3a und 6.0U1a nicht behoben wurde. Das war “ziemlich schade” und ich konnte (mit gutem Gewissen) fast das ganze Jahr 2015 kein auf VMware-Snapshots basierendes Backup  empfehlen.Die Lösung kam dann endlich mit ESXi 5.5 Update 3a. Mittlerweile ist aber zum Glück alles behoben und 5.5 Update 3b läuft sehr stabil.

Hauptauslöser war für mich der Bug, der im KB-Artikel 2115997 beschrieben ist: “Quiescing operations cause a Windows virtual machine to panic with a Stop 24 error on ntfs.sy”. Wie ich beim Troubleshooten bemerkt habe, wurde die VM in diesem Fall aber nicht nur gestoppt, sondern auch ihr Filesystem war nach dem Reboot korrupt, sodass sie aus dem Backup zurückgeholt werden musste. Deshalb habe ich fast bis zum Ende 2015 nur Crash-Konsistente Backups fahren können.

Mit diesem Beispiel wollte ich nur aufzeigen, dass es durchaus sinnvoll ist die “KB-Digest” zu lesen. Für mich gilt die Devise: Taucht nach ca. 2 Wochen nach einem neuen vSphere Release oder Update kein “schlimmer” neuer KB-Artikel alà “ESXi 6.0 loses network connectivity” auf, kann ein Update der Testumgebung erfolgen.

 

Interessante KB-Artikel aus diesem Jahr

Ich möchte dazu sagen, dass ich mich in diesem Artikel auf ESXi und vCenter beschränke:

 

Mein Fazit

Für mich ist das Fazit dieser kurzen Analyse: vSphere 5.5U3b wird von mir auch weiterhin als stabilste Plattform empfohlen. Ich freue mich dass die letzten 3-4 Monate keine gravierenden Bugs mehr aufgetreten sind. Auch die Bugs über 6.0U1b werden langsam weniger, sodass ich nun auch langsam mit gutem Gewissen diese Version empfehlen kann.

Ich hoffe mit dem Aufzeigen der aktuellen KB-Artikeln konnte ich zumindest einen kleinen Denkanstoß geben und vielleicht ja sogar weiterhelfen…

It's only fair to share...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on RedditPrint this page

Alles neu macht der Februar!?! – Neuigkeiten Rund um den SDCC und EUC Launch von VMware

Da mein Kollege Wiesel03 ja bereits mit dem ersten technischen Post gestartet ist, möchte ich heute mit einem mehr rein informativen Beitrag nachlegen.

Ganz konkret geht es um die Neuerungen und Veränderungen bei VMware, die letzte Woche im Rahmen des großen Online-Events angekündigt wurden.

Da die meisten von euch sich vermutlich schon einen Überblick über die technischen Neuerungen in Horizon View, VSAN 6.2 etc. verschafft haben, gehe ich jetzt nochmal bewusst einen Schritt zurück.

Denn: Was kommt vor der Installation? – Richtig, der eigentliche Kauf und damit die Entscheidung für ein Bundle und die passende Edition.

Daher schauen wir uns an dieser Stelle die Veränderungen im Portfolio hinsichtlich der jeweiligen Produkte und Produktfamilien bei VMware an:

vSphere und vSOM Editions

Hier wird es ab dem 30. Juni 2016 nur noch die folgenden 3 Editionen geben:

  • vSphere Standard
  • vSphere Enterprise PLUS
  • vSphere with Operations Manager Enterprise PLUS

Im Umkehrschluss bedeutet das, das ab Ende Juni 2016 folgende Editionen nicht mehr zur Verfügung stehen werden:

  • vSphere with Operations Management Standard
  • vSphere with Operations Management Enterprise
  • vSphere Enterprise

Für den Umstieg hält VMware jedoch eine schöne Promo-Aktion bereit:

  • vSphere Enterprise Kunden, mit aktivem SnS haben die Möglichkeit im Rahmen einer 50%-PROMO ein Upgrade auf vSphere Enterprise PLUS durchzuführen
  • vSphere with Operations Management Enterprise (vSOM Ent.) Kunden mit aktivem SnS haben die Möglichkeit im Rahmen einer 50%-PROMO ein Upgrade auf vSphere with Operations Management Enterprise PLUS (vSOM Ent. Plus) durchzuführen

Bei Erweiterung einer vSOM Standard Bestandsumgebung muss ab dem 1. Juli 2016 neben der vSphere Standard Lizenz auch die vRealize Operations Komponente  erworben werden.

  • Das “End of Support” Datum für vSphere Enterprise und vSOM Enterprise ist März 2020
  • All genannten Änderungen betreffen ebenfalls die VMware Acceleration-Kits

vCenter Server Standard

Ab dem 1. April 2016 enthält vCenter Server Standard zusätzlich eine 25 OSI Log Insight Komponente.

Diese ist auf Log-Analysen für den vCenter Server und die vSphere Umgebung beschränkt.

Neue vRealize Suiten

Ab dem 1. März 2016 stehen neue vRealize Suiten zur Erweiterung bestehender vSphere Umgebungen zur Verfügung.

Die neuen vRealize Suiten orientieren sich ab sofort an Kundenanforderungen bzw. Use Cases und sind entsprechend ausgestattet.

  • vRealize Suite steht in 3 Editionen ab dem 1. März zur Verfügung, Standard, Advanced und Enterprise
  • Jede vRealize Suite Lizenz beinhaltet das Recht, diese auch im Rahmen des neuen „Portable License Unit (PLU)“ Modells einzusetzen.

Dieses berechtigt den End User, 1 CPU vRealize Suite Lizenzen auch zum Management von 15 OSIs in „Non-vSphere“ oder Cloud Umgebungen (z.B. Citrix, Microsoft Hyper-V, KVM, Amazon Web Services) einzusetzen.

Ein paralleler Einsatz zur gleichen Zeit ist nicht gestattet.

Neue Virtual SAN Editionen

Hier stehen demnächst 3 Editionen zu Auswahl: Standard, Advanced und Enterprise

  • WICHTIG – Das Feature „Streched Cluster“ kann ab dem GA Datum nur noch mit einer vSAN Enterprise Lizenz verwendet werden

Neu – Workspace ONE

Workspace ONE steht ab dem GA Datum in den Editionen

  • Standard – für BYOD Szenarien
  • Advanced – zusätzlich zu BYOD Szenarien auch für managed und unmanaged Devices
  • Enterprise – zusätzlich zu BYOD Szenarien und managed/ unmanaged Devices für Virtual Apps & Desktops

Neue Horizon Editionen

  • Horizon steht ab dem GA Datum in den Editionen
    • Horizon Standard – Simple Powerful VDI with great user experience (CCU Lizenzmodell)
    • Horizon Advanced – Low-cost, high performance desktops and applications for physical and virtual machines (CCU und Named User Lizenzmodell)
  • Horizon Enterprise – Highest level of automation and management for private cloud delivery (CCU und Named User Lizenzmodell)
  • Horizon Air Hybrid – Cloud Management of BYO Horizon 7 desktops and infrastructure (CCU und Named User Lizenzmodell)

Fazit:

Neben den ganzen technischen Neuerungen, ist VMware auch gerade was das Produktportfolio an sich angeht dabei, sich selbst neu zu erfinden. Ich persönlich tue ich mich aktuell noch recht schwer, die ganzen Veränderungen und Anpassungen zu bewerten.

Wovon ich definitiv sehr begeistert bin, ist die Tatsache das bei jeder vCenter Standard Lizenz in Zukunft ein 25 OSI-Pack für Log Insight enthalten sein wird.

Log Insight ist wirklich ein absolut unterschätztes Produkt und ich freue mich das VMware hier den Leuten nun eine Möglichkeit gibt, sich von den absolut genialen Funktionen zu überzeugen.

Ich bin wirklich sehr auf die Reaktionen und das Feedback bei Endkunden gespannt. Insgesamt gibt es sehr viele interessante neue Bundles und Promo-Aktionen und der Kunde hat nun einmal mehr die Qual der Wahl.

It's only fair to share...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on RedditPrint this page