Zusammenfassung

  • Eine Kapazitätsreservierung bei Oracle wird innerhalb einer Availability Domain einer Tenancy und je Shape definiert; eine Reservierung kann mehrere Kapazitätskonfigurationen enthalten und optional eine Fault Domain nennen.
  • Eine Instanz wird nur dann auf eine Reservierung angerechnet, wenn sie in derselben Availability Domain liegt, und die Kapazitätstypen schließen einander aus; preemptible Kapazität garantiert keine Mindesthaltedauer und kündigt die Beendigung zwei Minuten vorher mit einem Ereignis an.

Auf der Seite zu Kapazitätsreservierungen schreibt Oracle, beim Anlegen einer Reservierung müsse die Availability Domain innerhalb der Tenancy angegeben werden, in der Kapazität reserviert werden soll; anschließend lässt sich eine Kapazitätskonfiguration hinzufügen, die festlegt, wie viel Platz reserviert wird und welcher Shape beim Anlegen von Instanzen gegen diese Konfiguration verwendet wird; optional kann die Fault Domain angegeben werden; eine Reservierung kann mehrere Kapazitätskonfigurationen umfassen. Der Originaltext ist englisch, die Zitate hier sind eine Übersetzung ins Deutsche. Das technische Gewicht liegt auf drei Koordinaten: Tenancy, Availability Domain und Shape. Eine Reservierung ist weder ein Kontingent des gesamten Kontos noch ein Pool der gesamten Region.

Die Zusammenfassung derselben Seite — eine Seitenparaphrase, kein wörtliches Zitat — ergänzt, dass die Reservierung an diese Availability Domain und diese Tenancy gebunden ist, nicht über Regionen reicht und nicht zwischen Availability Domains oder Tenancies verschoben werden kann. Deshalb läuft die Anpassung einer Reservierung meist auf ein Neuanlegen hinaus, nicht auf ein Verschieben.

Die Seite zum Starten einer Instanz formuliert die Regel direkter: Damit eine Instanz auf eine Kapazitätsreservierung angerechnet wird, muss die Reservierung in derselben Availability Domain liegen wie die Instanz; um eine Instanz auf einem dedizierten virtuellen Maschinenhost zu platzieren, muss der dedizierte Host in derselben Availability Domain und derselben Fault Domain liegen wie die Instanz; die Kapazitätstypen schließen einander aus. Dass im Konto eine Reservierung existiert und dass genau diese Instanz sie nutzen kann, sind also zwei verschiedene Fragen.

Die Seite zu Regionen und Availability Domains beschreibt Fehlergrenzen, keine Mengengrenzen: Availability Domains sind voneinander isoliert, fehlertolerant und fallen sehr unwahrscheinlich gleichzeitig aus; eine Fault Domain ist eine Gruppierung von Hardware und Infrastruktur innerhalb einer Availability Domain; jede Availability Domain enthält drei Fault Domains; Fault Domains bieten Antiaffinität, sodass Instanzen nicht auf derselben physischen Hardware innerhalb einer Availability Domain liegen. Isolation beschreibt die Struktur von „fällt gemeinsam aus oder nicht“, nicht die Frage „wie viel ist zu bekommen“. Beides zu verwechseln ist die häufigste Fehllektüre eines Katalogs.

Die Seite zu preemptible Instanzen behandelt preemptible Kapazität als eine Frage des Lebenszyklus: Das Verhalten entspricht dem einer regulären Compute-Instanz, aber die Kapazität wird zurückgeholt, wenn sie anderswo gebraucht wird, und die Instanzen werden beendet; die Kapazität ist für keine Mindestdauer garantiert, Instanzen können also jederzeit zurückgeholt werden; ein instancepreemptionaction-Ereignis wird zwei Minuten vor Beginn der Beendigung ausgelöst. Die Seite sagt nicht, dass preemptible Kapazität günstiger ist, und verspricht weder Ersatzkapazität noch Wiederholung oder Migration. Die zwei Minuten sind ein dokumentiertes Signal, keine Verfügbarkeitsgarantie; das Signal als Garantie zu lesen, unterschätzt den Aufwand für die Behandlung von Unterbrechungen.

Die Seite zur Compute-Übersicht lieferte in dieser Lesung keinen wörtlichen Auszug. Deshalb lässt sich die Liste der Kapazitätstypen, die On-Demand, preemptible, reservierte und dedizierte Kapazität unterscheidet, nur als Seitenbeschreibung festhalten und nicht als Zitat aus der Seite. Das ist eine ausdrückliche Grenze dieser Prüfung, kein Urteil über den Inhalt der Seite.

Setzt man die Seiten nebeneinander, wird die Stelle des Mangels klar: nicht bei der Bestellung, sondern beim Skalieren. Ein Trainings- oder Inferenzplan, der am Katalog von Regionen und Shapes bemessen wird, nutzt eine Karte als Nenner; der tatsächliche Nenner ist ein Shape innerhalb einer Availability Domain. Zwischen beidem gibt es keine automatische Umrechnung, und keine veröffentlichte Zahl ändert sich, um den Planenden zu warnen.

Dieser Text urteilt nicht über Preis und nicht über Angebot. Die gelesenen Seiten nennen für keinen Shape eine Reservierungsdauer, eine Verlängerungsregel, einen Preis oder eine Kapazitätszusage; sie halten auch nicht fest, dass beschleunigte oder GPU-Shape-Familien von preemptible oder reservierter Kapazität ausgeschlossen sind — Schweigen ist kein Beleg für Einschluss. In dieser Lesung lagen keine Aufzeichnungen über Bestand, Zuteilung oder beobachtete Rückholung vor, daher wird nichts über Knappheit oder Auslastung behauptet. Zusammen mit dem Eintrag zu Oracle Cloud im Verzeichnis lassen sich diese Seiten gegen eine andere Darstellung desselben Gegenstands halten: Oracle Cloud im BTW-Verzeichnis.