Wissensprüfung - Compute und Elastizität
Ein Architekt erwartet, dass VM Auto Scaling eine wachsende Single-VM-Workload verarbeitet, indem es CPU und RAM zu den laufenden Replikaten hinzufügt, wenn die Last steigt. Warum ist dies das falsche mentale Modell des Dienstes?
VM Auto Scaling ist horizontal: Es startet und beendet ganze Replikate, um einer einzelnen Metrikrichtlinie zu entsprechen. Änderungen an der Replikatkonfiguration betreffen nur neue Replikate, niemals die laufende Flotte. Das Vergrößern von CPU und RAM einer einzelnen VM ist Live Vertical Scaling, ein separater Mechanismus mit eigenen Obergrenzen (das 240-GB-RAM-Hotplug-Limit, die CPU/RAM-Verkleinerung mit Neustart). Die Ablenkungsoptionen erfinden Teilvergrößerungsverhalten, das der Dienst nicht besitzt.
Ein Architekt wählt eine Compute-Klasse für eine Workload, die exakt in ein festes Bündel aus vCPU, RAM und NVMe passt, deren persistente Geschäftsdaten jedoch Instanz-Neuaufbauten überstehen müssen. Ein Kollege behauptet, ein Cube sei ungeeignet, weil „Cubes können Block Storage nicht verwenden“. Wie sollte der Architekt antworten?
Ein Cube wird mit einem verpflichtenden, unveränderlichen NVMe-Template ausgeliefert, kann jedoch auch zusätzliche HDD/SSD Block Storage-Geräte anbinden. Persistente Daten gehören daher auf diese Volumen und nicht auf die NVMe-Platte, die zusammen mit der Instanz gelöscht wird. Die eigentliche Einschränkung besteht darin, dass das Template (vCPU, RAM, NVMe) nach der Bereitstellung festgelegt ist, nicht darin, dass der Cube Block Storage nicht verwenden kann. Das korrekte Design nutzt daher zusätzliche Volumen für Daten, die überdauern müssen.
FinCorp muss eine Boot- und Datendisk für eine einzelne VM auf Block Storage platzieren und möchte, dass das Volume die volle nominale SSD-Leistung erbringt. Welche Designentscheidung bestimmt am direktesten, ob die SSD wie erwartet performt?
Die SSD-Leistung auf IONOS CLOUD Block Storage skaliert mit der Volumengröße, und IONOS CLOUD empfiehlt mindestens 100 GB, um die volle Leistung zu erreichen. Genau deshalb werden SSDs unter 100 GB für Datenbank-Workloads nicht empfohlen. Die Ablenkungsoptionen verkehren das Größenverhältnis zwischen HDD und SSD (HDD ist größenunabhängig), missbrauchen Verfügbarkeitszonen und berufen sich auf eine verwaltete Replikation über Regionen hinweg, die für Block Storage nicht existiert.
Ein Architekt optimiert eine VM Auto Scaling-Gruppe, deren Replikate mehrere Minuten zum Starten und Aufwärmen benötigen. In Tests skaliert die Gruppe wiederholt hoch und skaliert dann sofort wieder ab, wobei sie unter konstanter Last oszilliert. Welche Konfigurationsentscheidung stabilisiert die Gruppe am besten?
Oszillation wird durch zwei Anti-Flapping-Steuerungen verhindert: eine Abklingzeit, die lang genug ist, damit neue Replikate aufwärmen und Last übernehmen können, sowie eine zwingende Trennung zwischen den Schwellenwerten für Hochskalierung und Abskalierung, die einen Totbereich erzeugt. Eine kürzere Abklingzeit verschlimmert das Übermaß an Skalierung, eine Gruppe kann nur eine Metrikrichtlinie haben, und es gibt keine Skalierung auf null, da der Mindestwert ein Replikat beträgt.
FinCorp muss seinen großen, bestehenden VMware-Bestand unter strenger EU-Souveränität betreiben und gleichzeitig den Plattformlebenszyklus von seinen eigenen Teams abnehmen. Darüber hinaus möchte das Unternehmen neue elastische Workloads am Edge bereitstellen. Welcher Ansatz passt am besten zu diesen Rahmenbedingungen?
Eine dedizierte VMware Private Cloud ermöglicht es FinCorp, sein VMware-Betriebsmodell beizubehalten, während IONOS CLOUD den Plattformlebenszyklus übernimmt. Da die Steuerungsebene in der EU betrieben wird, bleibt die Souveränität gewahrt, während ein in den USA betriebener VMware-Dienst in einer EU-Region trotz des Datenstandorts weiterhin einer CLOUD Act-Exposition unterliegt. Das Hybrid-Muster platziert den regulierten Bestand auf dedizierter VMware und die neuen elastischen Workloads auf Standard-Compute, anstatt eine kostspielige vollständige Replatformierung zu erzwingen oder vollständig on-premises zu bleiben.