Zu viel Stress und anscheinend zu wenig Kapazität?

By | 6. Januar 2016

Heute hat mich mal wieder eine Anfrage zum Thema Capacity Remaining und Stress erreicht. Eine VM hat Capacity Remaining von 0 und man weiss nicht warum. Beim genaueren Hinsehen habe ich gesehen, dass diese VM vor einiger Zeit (im Zeitraum von 30 Tagen) relativen hohen Demand und damit Stress hatte.

Sie hatte also mehr RAM angefordert als sie überhaupt konfiguriert hatte. Definitiv erstmal nichts schlimmes, schon gar nicht auf dieser gezeigten Kurve, denn das kam nur einmal vor. Dennoch, bei der Kapazitätsplanung will man eigentlich für Peaks und Stress planen. Stress bedeutet, dass sich der Demand über einem bestimmten Threshold befindet. Standardmässig sprechen wir hier über 70% Workload. Ich habe Kunden, die diesen Wert auf 80% raufschrauben, denn es ist schon OK wenn sich der Demand der VM über 70% befindet.

Der Grund für diesen Alarm bzw. den schlechten Score von 0 ist die Policy. In der Policy definieren wir, wie wir Kapazitätsplanung für Objekte (in meinem Fall für VMs) machen wollen. Ihr könnt selber nachsehen, was bei Euch eingestellt ist. Dazu öffnet Eure aktive Policy mit dem Editor. Unter Analysis Settings (1) könnt ihr Euch die verschiedenen Einstellungen anzeigen lassen. Ladet die Settings von VMs (2) und fügt sie zur Liste (3) hinzu, falls sie noch nicht in der Liste der Object Types erscheint. Im Abschnitt Capacity Remaining (4) findet ihr die aktiven Settings. Ganz unten in dem Abschnitt ist der “Übeltäter”. Unter Peak Consideration (5) ist standardmässig der Haken gesetzt, dass man Stress und Peaks beachten möchte bei der Kapazitätsplanung.

Wenn ihr den Haken rausgenommen habt, werdet ihr (nach mind. 5 Minuten) feststellen, dass sich der Score erheblich verbessert hat und wir wieder genug Capacity Remaining haben.

Überlegt Euch bitte trotzdem, ob das Sinn macht was ihr da einstellt. Denkt daran, dass ihr selbstverständlich (dynamische) Gruppen für bestimmte Payloads (z.B. für Exchange, SAP oder ähnliches) erstellen könnt und denen andere, angepasste Policies zuweisen könnt. Ihr müsst das nicht unbedingt global machen.

Alternativ:

Wir könnten das Problem oder vielmehr die Challenge auch anders angehen, in dem wir uns um die Settings von Stress kümmern, ohne die Settings von Capacity Remaining zu bearbeiten. Wie schon oben erwähnt, gibt es einen so genannten Stress Threshold, den wir anpassen können. Sprich, erst bei höheren Demand kommen wir in den Stress Bereich. Des Weiteren gibt es noch die Möglichkeit, die Time Range anzupassen. Standard mässig steht das Analyse Fenster auf jede Stunde im Zeitraum der letzten 30 Tage. Wir könnten  das Fenster auf N-Stunden erweitern (z.B 240 Minuten (4 Stunden)), damit hätten wir einen größeren Zeitraum und ein etwas geglättetes Ergebnis des Stress Score.

Eine weitere Methode, die ich hier ausprobiert habe, ist, das Fenster auf die ganzen 30 Tage einzustellen (Entire Range). Damit erreiche ich einen Durchschnitt auf die gesamten 30 Tage. Bitte beachtet auch die Erklärungen rechts im Bild.

Das Ergebnis zeigt, dass der Stress Wert nun gar nicht mehr so hoch ist, und demnach unser Capacity Remaining Score auch wieder völlig OK ist. Jedoch ist er nicht ganz so hoch, wie im ersten Beispiel, ABER wir haben immernoch Peaks und Stress mit in der Berechnung für Capacity Remaining und haben das nicht völlig ausgeschlossen.

 

Matthias Diekert

Technical Account Manager bei VMware Global, Inc
Matthias kommt aus Hamburg und arbeitet seit 2011 bei VMware Global, Inc in der Abteilung Professional Services (Post Sales). Bis 2014 war er als Senior Consultant im Bereich SDDC und als Subject Matter Expert im Bereich Enterprise Management für die ganze D-A-CH Region zuständig. Während dieser Zeit hat er viele große Projekte begleitet und durchgeführt.
Seit 2014 ist er nun als Technical Account Manager (TAM) tätig. In dieser Position betreut er Großkunden mit dem Focus auf strategische Ausrichtung und Weiterentwicklung der IT und ist weiterhin an wichtigen Enterprise Management Projekten beteiligt.
print

Category: _vR Ops 6 Schlagwörter: , , , ,

About Matthias Diekert

Matthias kommt aus Hamburg und arbeitet seit 2011 bei VMware Global, Inc in der Abteilung Professional Services (Post Sales). Bis 2014 war er als Senior Consultant im Bereich SDDC und als Subject Matter Expert im Bereich Enterprise Management für die ganze D-A-CH Region zuständig. Während dieser Zeit hat er viele große Projekte begleitet und durchgeführt. Seit 2014 ist er nun als Technical Account Manager (TAM) tätig. In dieser Position betreut er Großkunden mit dem Focus auf strategische Ausrichtung und Weiterentwicklung der IT und ist weiterhin an wichtigen Enterprise Management Projekten beteiligt.