Die richtige Größe für eine VM in der Cloud finden
Unternehmen zahlen oft zu viel für virtuelle Maschinen (VMs) in der Cloud, da sie deren Größe nicht richtig abschätzen. Hier sind Tipps, wie man die richtige Größe definiert.
Selbst wenn die meisten IT- und Business-Manager es nicht hören wollen, aber wahrscheinlich zahlen ihre Unternehmen zu viel für virtuelle Maschinen (VMs) in der Cloud.
Einer der wichtigsten Faktoren, die die Kosten für eine Cloud unnötig in die Höhe treiben, ist, dass die VMs nicht richtig dimensioniert sind. Doch es gibt auch Positives zu berichten: Es gibt konkrete Möglichkeiten für ein Unternehmen, um die richtige Größe für eine VM in der Cloud zu finden.
Die Provider von Public Clouds verlangen für ihre Ressourcen Preise, die sich auf die Reservierung bestimmter Angebote und Größen beziehen. Ein Kunde bezahlt mehr für fest reservierte Ressourcen als für solche auf On-Demand-Basis und mehr für größere virtuelle Maschinen als für kleinere – oder mehr für solche mit mehr Ressourcen bei Compute, Memory und Storage. Während diese teuren Angebote mit hoher Performance auftreten, sollte das Ziel für Unternehmen dennoch darin bestehen, den besten Ausgleich zwischen Performance und Kosten zu finden.
Schritte zur richtigen VM-Größe
Der erste Schritt, um die richtige Größe für eine Cloud-VM zu finden, besteht in der Bestimmung der adäquaten Server-Images. Unternehmen tendieren eher dazu, den einfachsten Weg zu wählen und von einer einzigen Standardausstattung bei Betriebssystem und Middleware-Komponenten auszugehen. Das führt oft dazu, dass solche Images bis zu 40 Prozent größer sind als eigentlich notwendig. Um den Optimierungsprozess zu beginnen, muss man zunächst festlegen, welche Middleware- oder Betriebssystem-Features für eine bestimmte Anwendung benötigt werden, überflüssiges kann dagegen vernachlässigt werden. Und man kann noch Puffer-Zwischenräume oder ansonsten unbenutzten VM-Platz festlegen, um die Performance zu verbessern oder auf jeden Fall die VM-Größe reduzieren.
Man sollte diesen Prozess bereits in der Entwicklungsphase beginnen. Die Softwareteams sollten ausdrücklich die Tool-Anforderungen für jede Anwendung festlegen, anstatt nur von einer bequemen Standardkonfiguration auszugehen. Und während die Veränderungen und Verbesserungen erfolgen, sollte man jedes Mal die Auswirkungen auf die Middleware beobachten, um die Image-Größe nicht zu beeinträchtigen.
Der zweite Schritt besteht darin, die Konfigurationsparameter und die Memory-Größe der VM auf der Basis von Tests entsprechend einzustellen. Linux-Betriebssysteme tendieren dazu, jede nur mögliche Memory-Größe an sich zu ziehen, oftmals in der Absicht, genügend Puffer für verbesserte Performance zur Verfügung zu haben. Das ist einer der Gründe, warum Anwender oft zu einer übermäßigen Ausstattung der Memory-Ressourcen neigen. In vielen Fällen wird die Memory-Vergrößerung nur zu einer nicht-linearen Performance-Verbesserung führen – und ab einem bestimmten Punkt wird dieser Prozess sogar abnehmen oder ganz aufhören. Es ist nicht gerade einfach, diesen Punkt genau im Vorhinein zu bestimmen, so dass man Applikationen bei unterschiedlichen Cloud-VM-Größen testen sollte, um die jeweilige Kosten-Performance-Kurve herauszufinden.
Diese Art von Tests erfordern ein automatisiertes Test-Tool, das produktive Volumes untersuchen kann, wie zum Beispiel Load- oder Performance-Prozesse. Doch die besten Tools hängen von der Beschaffenheit einer Anwendung ab – einige erfordern verteilte, webgestützte und andere dagegen mehr spezifische Transaktionstests. Man sollte außerdem untersuchen, wie weit die VM den Memory-Einsatz nutzt – zum Beispiel mit dem Linux-Befehl free command – und wie groß die Memory-Schwankungen sind. Kommt es zu hohen Schwankungen, dann hat eine Anwendung zu wenig Memory zur Verfügung.
Arbeiten Sie mit der voraussichtlichen Größe Ihrer Cloud-VM und kontrollieren Sie die Memory-Belastung. Das Größenverhältnis zwischen VM und Memory sollte etwa 1,2 betragen – in den meisten Fällen eine sichere Annahme. Man sollte außerdem Performance-Tests mit einer VM-Größe durchführen, die einen Grad niedriger und einen Grad größer ausfällt.
Einer der wichtigsten Faktoren, die die Kosten für eine Cloud unnötig in die Höhe treiben, ist, dass die VMs nicht richtig dimensioniert sind.
Ferner sollte man berücksichtigen, wie die Cloud-VM mit mehreren Anwendungen zurechtkommt. Wenn man plant, nur eine einzige Applikation pro VM zu nutzen, kann man diesen Punkt überspringen. Doch wenn man Ressourcen zusammenfassen will, sollte man eine Tabelle mit allen VM-Größen seiner Anwendungen erstellen und dann über die Anzahl der Applikationen pro VM entscheiden. Wenn man bei der typischen VM-Größe nur ein paar Sonderfälle hat, sollte man auf die am meisten genutzte Größe setzen anstatt einen zweiten Ressourcen-Pool einzurichten. Dies wird die gesamte Auslastung verbessern, da größere Pools effizienter als kleinere sind.
Cloud-VMs: reserviert, on-demand oder präventiv
Ein anderer Faktor, den man bei der Betrachtung der richtigen Cloud-VM-Größe berücksichtigen muss, besteht in der Auswahl eines Cloud-VM-Typs: reserviert, on-demand oder präventiv.
Reservierte Systeme – wie zum Beispiel AWS Reserved Instances, Azure Reserved VM Instances oder VMs, wie sie Google mit Benutzungsrabatten anbietet – stehen immer zur Verfügung, so dass die Anwender keine Zeit bei ihrer Einrichtung und Nutzung verlieren. Dies ist besonders sinnvoll bei Anwendungen, die in einem 24-Stunden-Rhythmus laufen müssen. Der Einsatz von VM-Pools für mehrere Anwendungen – wie oben beschrieben – ist ein anderer Rechtfertigungsgrund für reservierte Systeme. Wenn man in der Tat einen VM-Ressourcen-Pool plant, wird man wahrscheinlich solche Reserved Instances verwenden müssen, da mindestens eine der Applikationen immer eine VM brauchen wird.
Die meisten Anwendungen sind wahrscheinlich ein Fall für On-Demand-VMs, die weniger kosten und die das Risiko reduzieren, dass Unternehmen in einen langfristigen reservierten Vertrag hineingezwungen werden. Man muss jedoch berücksichtigen, dass On-Demand- und präventive Systeme weniger als reservierte kosten, aber größere Risiken mit sich bringen: Dazu gehören zeitlich verzögerte Image-Loads oder bei präventiven Systemen wie zum Beispiel Googles „pre-emptible VMs“ oder AWS Spot Instances das Verschwinden einiger Workloads. Deshalb sollte man bei diesen Angeboten besonders vorsichtig sein, gerade wenn es um geschäftskritische Anwendungen und Workloads geht.
Den Unternehmen und künftigen Kunden bleibt nichts anderes übrig, als solche Angebote gründlich zu testen. Nur so können sie einigermaßen sicher sein, die richtige Entscheidung getroffen zu haben.
Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!
