Script – VMware vSphere Sizing

Um mir und meinen Kollegen die wiederkehrende Aufgabe der Datensammlung zwecks eines VMware vSphere Sizing zu erleichtern habe ich hierzu ein PowerCLI Skript geschrieben. Dieses sammelt in einer bereits bestehenden VMware vSphere Umgebung einige Informationen als Grundlage für ein neues Hardware Sizing.

Top vBlog 2018 Voting

Nehmen Sie an der Umfrage teil, um Ihre Stimme abzugeben und belohnen Sie die besten Blogger für ihre harte Arbeit und ihr Engagement, indem Sie sie wissen lassen, dass Sie sie schätzen.

Fokus der gesammelten Daten ist das Server Sizing. In der aktuellen Version sind aber auch auch bereits einige Storage Daten enthalten.

Selbstverständlich sind diese Daten alleine nicht ausreichend um ein Sizing zu erstellen. Für mich bedeutet ein qualifiziertes Sizing eine ganzheitliche Betrachtung der Anforderungen und Prozesse des Kunden.

Ausgabe des VMware vSphere Sizing Skripts

VMware vSphere Sizing Script v1.2

Volle Ausgabe der aktuellen Version 1.2

VMware vSphere Sizing Script without Stats v1.2

Ausgabe ohne Stats

VMware vSphere Sizing Script verbose v1.2

Auch eine ausführliche Ausgabe der Erfassung ist möglich

Aufruf des VMware vSphere Sizing Skripts

Ich habe das Skript mit dem Ziel der möglicht einfachen Handhabung als PowerShell Modul angelegt.

Zur weiteren Verarbeitung können die Daten natürlich auch exportiert werden:

Beispiel aus der Praxis:

Recommend-Sizing_Example.xls Google Docs

 

 

Bei einer großen Anzahl von vSphere Clustern kann der Aufruf auch so aussehen:

Werte des VMware vSphere Sizing Resultats

Name Beschreibung
Cluster Cluster Name
HAEnabled Cluster HA Status
DrsEnabled Cluster DRS Status
Hosts Anzahl der Hosts im Cluster
HostsAverageMemoryUsageGB Durchschnittlich genutzter RAM in GB der Hosts im Cluster
HostsAverageMemoryUsage Durchschnittlich genutzter RAM in % der Hosts im Cluster
HostsAverageCpuUsageMhz Durchschnittlich genutzter CPU in MHz der Hosts im Cluster
HostsAverageCpuUsage Durchschnittlich genutzter CPU in % der Hosts im Cluster
PhysicalCPUCores Anzahl der physikalischen CPUI Cores der Hosts im Cluster
LogicalCPUThreads Anzahl der logischen CPU Threads der Hosts im Cluster
VMs Anzahl der VMs im Cluster
ActiveVMs Anzahl der eingeschalteten VMs im Cluster
VMvCPUs Anzahl der vCPUs aller VMs im Cluster
vCPUpCPUratio Verhältnis vCPUs zu der logischen CPU Threads
PhysicalMemoryGB Physikalischer RAM in GB im Cluster
AllocatedVMMemoryGB Allokierter RAM in GB im Cluster
ClusterMemoryUsage Allokierter RAM in % im Cluster
SumVMDiskSpaceGB Summer der vDisk Größen aller VMs im Cluster
SumDatastoreSpaceGB Summer aller Datastore Kapazitäten im Cluster
SumDatastoreUsedSpaceGB Summer aller genutzter Datastore Kapazitäten im Cluster
AverageVMIOPSWriteAvg Durchschnittliche Write IOPS aller VMs im Cluster
AverageVMIOPSReadAvg Durchschnittliche Read IOPS aller VMs im Cluster
AverageVMCPUUsageAvg Durchschnittliche CPU Nutzung in % aller VMs im Cluster
AverageVMMEMUsageAvg Durchschnittliche RAM Nutzung in % aller VMs im Cluster

VMware vSphere Sizing Skript

 

Das Modul ist auch in meinem vSphere Modules GitHub Projekt zu finden:

My VMware vSphere Modules

 

 

Geplante Features

Die aktuelle Version ist für mich noch nicht das finale Ergebnis, dafür gibt es zu viele Faktoren in einem Sizingprozess.

Geplant sind aktuell folgende zusätzliche Werte:

  • VM Active Memory
  • VM Min / Max / Average vCPU Konfiguration
  • VM Min / Max / Average Memory Konfiguration
  • VM Min / Max / Average CPU Ready %
  • VM Min / Max / Average CPU MHz
  • Datstore Min / Max / Average Latency
  • Datstore Min / Max / Average IOPS

Bei den aktuellen Werten stehen folgende Änderungen aus:

  • HostsAverage*: Berechnung aus Stats statt Momentaufnahme

Geplante Verbesserungen

  • Bessere Ausgabe der Stats bzw. wenn keine Stats gefordert wurden diese weglassen

Wie arbeite ich mit den gesammelten Informationen

Auch wenn man mit dem Kunden „nur“ über das Sizing der Compute Ressourcen spricht kommt es sehr genau darauf an, welches Verfügbarkeits -, Disaster Recovery – und Backup – Konzept angestrebt wird. Natürlich darf auch nicht der Typ des Workloads außer Acht gelassen werden. Eine VDI oder Terminal Server Umgebung zum Beispiel agieren völlig anders als gewöhnliche Server Applikationen. Von den speziellen Anforderungen eines In Memory Datenbank Systems wie SAP HANA mal ganz abgesehen.

Dazu kommen dann noch Aspekte wie Lizenzierung oder Sicherheitszonen zum tragen. Beides kann erfordern, zusätzliche vSphere Cluster zu designen.

Zu guter letzt ist für mich immer noch sehr wichtig, welche Projekte über den geplanten Einsatzraum der neuen Hardware anstehen. Ein geplantes ERP Projekt z.B. kann einen enormen zuwachs an VMs bedeuten! Ebenso würde der geplante Einsatz von VMware vRealize Automation ganz andere Anforderungen an Skalierung, Agilität und Überwachung aufwerfen!

Am Ende können sehr viele Faktoren das Sizing beeinflussen:

  • Angestrebte Konsolidierungsrate
  • Angestrebte Überbuchung
  • Anforderungen der Anwendungen
  • Bereitstellungskonzept
  • Disaster Recovery Konzept
  • Backup Konzept
  • Anforderungen an die Verfügbarkeit
  • Netzwerkkonzept
  • Storagekonzept
  • Sicherheitsanforderungen
  • OS und Anwendungslizenzierung

Alles läuft also auf eines hinaus: Es muss unbedingt genau mit dem Kunden gesprochen werden und alle Faktoren beleuchtet werden!

Nichts desto trotz geben die gesammelten Daten aus dem Skript einen Anhaltspunkt an die minimalen Anforderungen an die Hardware.

Euer Input würde mir sehr helfen

Um das Skript noch hilfreicher zu machen, würde ich mir sehr freuen wenn ihr mir Rückmeldung geht. Mich würde interessieren welche Werte ihr für euer Sizing zu Rate zieht und wie Ihr das Skript verwendet, bzw. warum ihr es nicht verwenden könnt.

2 Comments

  1. Robert 20. Januar 2017
    • Markus Kraus 20. Januar 2017

Leave a Reply