Bare Metal, bereitgestellt wie in der Cloud

Was ein Bare-Metal-Server tatsächlich ist

Ein Bare-Metal-Server ist eine einzelne physische Maschine, die Ihnen allein gehört, mit Ihrem Betriebssystem direkt auf der Hardware installiert. Zwischen Ihrem Kernel und der CPU sitzt kein Hypervisor, und kein anderer Kunde teilt sich die Maschine mit Ihnen. Wenn Sie eine Core-Zahl lesen, ist das die Core-Zahl, die Sie bekommen, jede Stunde des Monats, egal ob jemand anderes im selben Rack gerade einen Build laufen lässt.

Der Unterschied, der als Erstes auffällt, ist nicht die reine Geschwindigkeit, sondern die Vorhersehbarkeit. Eine virtuelle Instanz ist ein Scheduling-Versprechen: Der Hypervisor entscheidet, wann Ihre vCPU läuft, wie viel von der Host-NIC Sie sehen und wie tief die Storage-Warteschlange reicht. Auf Bare Metal sind das physische Tatsachen, die Sie einmal messen und auf die Sie sich verlassen können. Das zählt am meisten bei Workloads, die eher auf das 99. Perzentil reagieren als auf den Durchschnitt: Datenbanken, latenzempfindliche Game-Server, Echtzeit-Medien und alles, bei dem ein Scheduler-Stall sich als Beschwerde eines Nutzers bemerkbar macht.

Wo sich die beiden Modelle wirklich unterscheiden

Cloud-Instanzen sind das richtige Werkzeug für sprunghafte, kurzlebige, horizontal skalierte Arbeit. Dies ist die ehrliche Liste dessen, was sich ändert, sobald der Workload keins von beidem mehr ist.

Der Kompromiss ist in beide Richtungen real: Sie können eine physische Maschine nicht um 3 Uhr morgens in der Größe ändern, und Sie sollten keine für einen Workload wählen, der die meiste Woche bei null Auslastung stillsteht. Was Sie dafür bekommen, ist eine Maschine, deren Leistung Sie einmal charakterisieren können, und eine Rechnung, die sich nicht mit Ihrem Traffic bewegt.

Was jeder Server mitbringt

Sie zahlen für den Server, für zusätzliche IP-Blöcke und für Bandbreite über das Kontingent Ihres Plans hinaus. Jede andere Funktion in dieser Tabelle ist ohne Aufpreis im Server enthalten.

Workloads, die sich die ganze Maschine verdienen

Vier Muster tauchen immer wieder bei Kunden auf, die von virtuellen Instanzen wegziehen.

• Kubernetes auf Metal. Wenn das Kubelet direkt auf dem Host läuft, entfällt eine Scheduling-Schicht für jeden Pod, und die CNI bekommt eine echte NIC zum Arbeiten. Sie zahlen außerdem nicht mehr doppelt für Isolation, die Sie bereits vom Cluster bekommen.
• Datenbanken und alles, was an Storage-Latenz hängt. Physische Festplatten im Chassis, kein Netzwerkspeicher-Hop und ein Page-Cache, der nicht mit dem eines anderen Mieters konkurriert.
• Game- und Echtzeit-Server. Tick-Raten stehen und fallen mit dem Ausläufer der Latenzverteilung, und genau das macht ein geteilter Host-Scheduler unvorhersehbar.
• Konstante, immer aktive Compute-Last. CI-Flotten, Encoder, Indexer und Batch-Worker, die den ganzen Monat gleichmäßig laufen. Elastizität, die Sie nie nutzen, ist Elastizität, für die Sie aufhören sollten zu zahlen.

Wenn Ihr Workload sprunghaft ist, nachts im Leerlauf steht oder mehrmals am Tag hoch- und wieder herunterskaliert, ist eine Cloud-Instanz tatsächlich die bessere Antwort. Die verkaufen wir auch.

Vom Claim zur Root-Shell

Der Sinn davon, Bare Metal nach Cloud-Art zu betreiben, ist, dass eine physische Maschine aufhört, ein Projekt zu sein. Dies ist der gesamte Lebenszyklus, in der Konsole oder über die API.

1. 1Beanspruchen Sie eine Maschine. Wählen Sie eine Konfiguration aus dem Live-Katalog und einen Abrechnungszyklus: stündlich zum Testen, länger, wenn Sie bleiben. Derselbe Vorgang ist ein einziger Aufruf mit einem API-Key, den Sie selbst ausstellen.
2. 2Die Installation läuft von selbst. Ein Cloud-Init-Image landet auf der Hardware und meldet den Fortschritt live in der Konsole. Kein Ticket, kein geplantes Zeitfenster. Brauchen Sie etwas außerhalb des Katalogs? Binden Sie Ihr eigenes ISO über Virtual Media ein oder booten Sie es mit iPXE.
3. 3Legen Sie los. SSH wie gewohnt, oder öffnen Sie die Browser-KVM, um den Boot zu beobachten und zu beheben, was kaputtgeht: Out-of-Band, in Sekunden. Die DDoS-Mitigation liegt bereits inline vor der Maschine, auch während der Installation.
4. 4Erfassen, verschieben oder zurückgeben. Nehmen Sie ein Image des laufenden Servers auf und stellen Sie es auf einer anderen Maschine erneut bereit, oder geben Sie die Maschine zurück, wenn die Arbeit erledigt ist. Ein stündlicher Server ist eine Ressource, kein Vertrag.

Jeder Schritt oben ist ebenso ein API-Aufruf wie ein Klick in der Konsole. Die Cloud-Konsole ist ein Client der API, keine Schicht darüber. Stellen Sie einen Key aus und skripten Sie die Teile, die Sie öfter als einmal erledigen.