Wissensprüfung - Rechenressourcen und Elastizität
Ein Architekt erwartet, dass VM Auto Scaling eine wachsende einzelne VM Workload durch Hinzufügen von CPU und RAM zu den laufenden Replikaten bei zunehmender Last handhabt. Warum ist dies das falsche mentale Modell des Dienstes?
VM Auto Scaling ist horizontal: es startet und beendet ganze Replikate, um einer einzelnen Metrik-Richtlinie zu entsprechen, und Änderungen an der Replikat-Konfiguration betreffen nur neue Replikate, nie die laufende Flotte. Das Wachsen eines VM-CPU und RAM ist Live-Vertikale-Skalierung, ein separates Mechanismus mit eigenen Obergrenzen (die 240 GB RAM-Hotplug-Grenze, die restart-tragende CPU/RAM-Downscale). Die Ablenker erfinden teilweise-Vergrößerungsverhaltensweisen, die der Dienst nicht hat.
Ein Architekt wählt eine Rechenklasse für ein Workload, das sich nahtlos in ein festes Bündel aus vCPU, RAM und NVMe einfügt, dessen persistente Geschäftsdaten jedoch Instance-Neuerstellungen überstehen müssen. Ein Teammitglied argumentiert, dass ein Cube ungeeignet ist, weil "Cubes Block Storage nicht verwenden kann." Wie sollte der Architekt antworten?
Ein Cube wird mit einem obligatorischen, unveränderlichen NVMe-Template ausgeliefert, kann aber auch Add-on-HDD/SSD-Block Storage-Geräte anhängen, sodass persistente Daten auf diesen Volumen und nicht auf der NVMe-Festplatte, die mit der Instanz gelöscht wird, platziert werden sollten. Die eigentliche Einschränkung besteht darin, dass das Template (vCPU, RAM, NVMe) nach der Bereitstellung festgelegt ist und nicht, dass der Cube Block Storage nicht verwenden kann, sodass das korrekte Design Add-on-Volumen für Daten verwendet, die überleben müssen.
FinCorp muss eine einzelne VM-Datenbank-Boot- und Datenspeicher-Disk auf Block Storage platzieren und möchte, dass die Volume ihre volle Nenn-SSD-Leistung liefert. Welche Entwurfsentscheidung bestimmt am direktesten, ob die SSD-Leistung wie erwartet funktioniert?
Die SSD-Leistung auf IONOS Block Storage skaliert mit der Größe der Volume, und IONOS empfiehlt mindestens 100 GB, um die volle Leistung zu erreichen, was genau der Grund ist, warum Sub-100-GB-SSDs für Datenbank-Workloads nicht empfohlen werden. Die Ablenker verkehren das Verhältnis zwischen HDD- und SSD-Größe (HDD ist größenunabhängig), missbrauchen Verfügbarkeitszonen und rufen eine gemanagte Cross-Region-Replikation auf, die für Block Storage nicht existiert.
Ein Architekt optimiert eine VM Auto Scaling-Gruppe, deren Replikate mehrere Minuten benötigen, um zu starten und sich aufzuwärmen. Bei Tests skaliert die Gruppe wiederholt aus und dann sofort wieder ein, wobei sie unter konstanter Last oszilliert. Welche Konfigurationswahl stabilisiert die Gruppe am besten?
Die Oszillation wird durch die zwei Anti-Flapping-Steuerungen verhindert: eine Abkühlzeit, die lang genug ist, damit neue Replikate sich aufwärmen und die Last übernehmen können, und eine obligatorische Trennung zwischen den Schwellenwerten für Skalierung und Reduzierung, die eine tote Zone erstellt. Eine kürzere Abkühlzeit verschlimmert die Über-Skalierung, eine Gruppe kann nur eine Metrik-Richtlinie haben, und es gibt keine Skalierung auf Null, da die Untergrenze ein Replikat ist.
FinCorp muss seine große bestehende VMware-Landschaft unter strenger EU-Souveränität betreiben und gleichzeitig den Plattformlebenszyklus von seinen eigenen Teams übertragen, und es möchte auch neue elastische Workloads am Rand. Welcher Ansatz passt am besten zu diesen Einschränkungen?
Ein dediziertes VMware-Private Cloud ermöglicht es FinCorp, sein VMware-Betriebsmodell beizubehalten, während IONOS den Plattformlebenszyklus besitzt, und da die Steuerungsebene EU-betrieben ist, wird die Souveränität erhalten, wo ein US-betriebener VMware-Service in einer EU-Region immer noch eine CLOUD-Act-Exposition aufweisen würde, unabhängig vom Datenstandort. Das Hybrid-Muster platziert die regulierte Landschaft auf dediziertem VMware und die neuen elastischen Workloads auf Standard-Compute, anstatt eine teure vollständige Neuplatzierung zu erzwingen oder vollständig vor Ort zu bleiben.