Speicherprobleme in der VMware Cloud on AWS?!

Speicherprobleme in einer Cloud? Mit unendlichen Ressource? „Wie kann das sein?“ wird sich der Eine oder Andere fragen. Hierbei geht es weniger darum, dass ein Ressourcenengpass in der VMware Cloud on AWS vorliegt, sondern mehr darum, dass Speicherplatz häufig DER limitierende Faktor beim Downscaling ist.

Dazu hier eine kleine Vorgeschichte

Die VMware Cloud on AWS funktioniert anders als Clouds mit nativen Workload wie etwa AWS selbst, wo EC2 Instanzen oder Services betrieben werden können. Vielmehr ist es ein von VMware auf AWS gehostetes vCenter samt ESXi, vSAN und NSX, welches als Service genutzt werden kann. Diese Architektur bietet den Vorteil, dass virtuelle Maschinen wie gewohnt verwaltet, gemonitored und zwischen On-Premise vCenter und Cloud hin und her migriert werden können. Der Nutzer selbst bestimmt die Density an virtuellen Maschinen pro Host. Ein Aufbau/Anbindung eines VMware Cloud on AWS Standorts kann erfahrungsgemäß (DirectConnect/VPN als Basis vorausgesetzt) binnen weniger Tage erschlossen werden.

Elastic DRS

Einer der wohl größten Vorteile nach Erschließung der VMware Cloud on AWS ist das Elastic DRS (kurz: EDRS). Mit Hilfe von EDRS kann die Anzahl der ESXi-Nodes in der Cloud skaliert werden. Je nach Bedarf werden Hosts hinzugefügt oder eben auch wieder aus dem Cluster entfernt. So wird sichergestellt, dass auch nur die Ressourcen bezahlt werden müssen, die man auch tatsächlich benötigt. Das Minimum der zu nutzenden Hosts in einem Cluster liegt dabei bei 3 Hosts. 2-Node Cluster können nur einmalig hoch skaliert werden, ein runter skalieren auf weniger als 3 Hosts ist anschließend nicht möglich.

4 Policies für EDRS

Für die Skalierung gibt es aktuell 4 Policies, mit denen EDRS pro Cluster in einem Software Defined Datacenter (kurz: SDDC) konfiguriert werden kann:

Diese EDRS Policies beinhalten folgenden Threshold:

Best Performance und Lowest Cost Policies

Die nach unserer Erfahrung hilfreichsten Policies sind Best Performance und Lowest Cost. Sie fügen bei hoher Auslastung des Clusters Hosts hinzu und entfernen Sie wieder, sobald die Last unter Alle Low-Thresholds der jeweiligen Policy fällt. Der einzige Unterschied der beiden Policies Best Performance und Lowest Cost liegt in der Skalierung nach unten. Dieser unterscheidet sich um jeweils 10% bei Memory und CPU. In der Regel ist der Workload so dynamisch, dass bei einem absinken auf unter 60% CPU und Memory Last ohne weiteres ein Host entfernt werden kann und trotzdem ausreichende Ressourcen zur Verfügung stehen, um Spitzen abzufangen. So landen wir in den allermeisten Fällen bei der Policy Lowest Cost.

Das Problem der Skalierung in der Praxis

In der Theorie soweit so gut. In der Praxis mussten wir leider oft die Erfahrung machen, dass bei einer Skalierung nach unten, nicht etwa der Threshold für CPU oder Memory, sondern Storage DER limitierende Faktor ist. Das absolute Maximum an Low-Threshold für ein herunter skalieren liegt bei 20% Auslastung des vorhandenen Speichers. Dies bedeutet, selbst wenn sowohl CPU als auch Memory bei einstelligen Werten vor sich hin idlen, erfolgt keine Skalierung nach unten, solange die Speicherplatzauslastung nicht unter die magische Grenze von 20% fällt. Erfahrungsgemäß ist eine Auslastung von bis zu 70% für vSAN ein absolut zumutbarer Wert, bei dem es zu wenigen, bis keinen Einschränkungen kommt. 20% sind also weit unter dem, was Problemlos betreibbar wäre.

Drei Möglichkeiten mit dem Threshold-Problem umzugehen:

Eine Möglichkeit ist die Nutzung von vSAN TRIM/UNMAP. Sie ändert die Thresholds zwar nicht, kann unter Umständen aber durchaus bei der Erreichung der magischen Grenze von unter 20% helfen. Was genau TRIM/UNMAP ist und wie Sie es aktivieren, erfahren Sie im Blogbeitrag Speicherplatz in der VMware Cloud on AWS durch TRIM/UNMAP gewinnen?

Die zweite Möglichkeit wäre die Thresholds der jeweiligen Policy manuell zu überschreiben. Die ist aber leider nicht ohne weiteres möglich. Die Thresholds sind fest in den Policies verankert und können somit einzig und allein von VMware geändert werden.

So bleibt aktuell nur die Methode eines Workarounds. Der Cluster muss entweder von Hand verkleinert werden oder man nutzt Möglichkeit der Automatisierung per Powershell. Die VMware PowerCLI enthält in der Version 12.0 im Modul VMware.VimAutomation.Vmc diverse Cmdlets welche die Kommunikation und Steuerung mit der VMC on AWS ermöglichen.

Mithilfe dieser Cmdlets können die Cluster ohne weiteres geschrumpft werden. Bleibt einzig die Abfrage der Auslastung des Clusters. An dieser Stelle ist es sehr individuell. Eine Abfrage dieser Daten kann beispielsweise gegen den vRealize Operations Manager oder ähnliche Tools erfolgen.

Bei der Automation sind allerdings einige Fallstricke zu beachten:

1. Derzeit ist es bei der Verwendung des Cmdlets Remove-VmcSddcHost nicht möglich einen Cluster anzugeben. Es ist somit nicht möglich es gegen SDDCs zu verwenden, welche mehrere Cluster beherbergen.

2. Bei der Prüfung, ob ein Host aus dem Cluster entfernt wird, können wir derzeit leider nur auf Leistungsdaten zurückgreifen. Der Status des Cluster kann über die Powershell also nicht erfragt werden. Sollte also ein Host aus anderen Gründen als Leistungsengpässen hinzugefügt werden (beispielsweise aufgrund des proaktiven Tauschs eines defekten Hosts), so kann dieser Status bei der Abfrage nicht berücksichtigt werden. In der Praxis bedeutete das für uns in der Vergangenheit, dass wir aufgrund des Scripts in seltenen Ausnahmefällen einen Host entfernt haben, die VMware Automatik aber aufgrund der gewählten Policy wieder einen Host hinzugefügt hat.