Elastische Skalierung: Zaris-Server ohne Downtime hinzufügen und entfernen

Die Kapazität stimmt nie lange. Der Traffic wächst, ein Launch steht an, eine Saison endet — und der Store, den Sie im letzten Quartal dimensioniert haben, ist entweder überlastet oder halb leer. Ob das eine lästige Pflicht oder eine Krise ist, entscheidet eine einfache Frage: Können Sie die Größe eines laufenden Stores ändern, ohne ihn herunterzufahren?

Bei Zaris lautet die Antwort ja, mit einer wichtigen Asymmetrie, die man gleich zu Beginn ehrlich benennen sollte. Das Hochskalieren — das Hinzufügen von Servern — ist die einfache, sichere, verlustfreie Richtung und geschieht live, während der Store weiter bedient. Das Herunterskalieren — das Entfernen von Servern — wird ebenfalls unterstützt, ist aber ein bewusster, überwachter Vorgang, weil die Daten eines ausscheidenden Servers zuerst irgendwohin müssen.

Dieser Beitrag behandelt beide Richtungen: einen Store mit Add-ZrServer vergrößern, ihn mit Remove-ZrServer verkleinern, warum das Herunterskalieren einen Drain braucht und welche Rolle die Web-Konsole spielt.

Der Store hat eine Soll-Gestalt

Hinter der elastischen Skalierung steht eine Idee: Die Gestalt eines Zaris-Stores wird durch eine kanonische StoreDefinition beschrieben — die Soll-Menge an Servern und Partitionen, die der Store haben soll. Sie ist die maßgebliche Quelle dafür, wie der Cluster aussehen soll, und keine laufende Bilanz dessen, wie er gerade zufällig aussieht.

Zaris läuft unter einem Supervisor-Modell: Der Supervisor besitzt diese kanonische Definition und steuert die laufenden Instanzen kontinuierlich darauf zu. Skalierung ist also kein Haufen manueller Schritte, die Sie von Hand ordnen — Sie ändern die Soll-Gestalt, und der Supervisor gleicht den laufenden Cluster daran an. Add-ZrServer und Remove-ZrServer sind die Mittel, mit denen ein Operator diese Soll-Gestalt bearbeitet, und der Supervisor leistet die Arbeit, dorthin zu gelangen.

Hochskalieren: live und verlustfrei

Kapazität hinzuzufügen ist ein einzelnes Cmdlet. Sie zeigen auf den Store und nennen den neuen Server:

# Grow the store by adding a server to its definition
Add-ZrServer -Store orders -Server zaris-c.example.com:7861

# Check the resulting set
Get-ZrServer -Store orders

Dabei partitioniert der Store live neu. Die Partitionen werden so umverteilt, dass der neue Server seinen Anteil übernimmt, die Daten wandern zu ihren neuen Eigentümern, und der Store bedient die ganze Zeit Lese- und Schreibzugriffe — es gibt kein Stop-the-World-Fenster. In Tests haben wir auf diese Weise einen Store von 6 auf 8 Partitionen vergrößert, während er online blieb.

Die entscheidende Garantie: Das Hochskalieren ist verlustfrei. Während der Migration geht kein bestätigter Schreibvorgang verloren. Daten wandern zu den neuen Eigentümern, die Zuständigkeit wird umgeschaltet, und ein Schreibvorgang, den der Store einem Client als committet gemeldet hat, ist auch nach der Neupartitionierung noch da. Das macht das Hinzufügen von Kapazität zu einer Routineoperation — Sie können auf Last reagieren, indem Sie den Store während des Traffics vergrößern, nicht erst in einem Wartungsfenster.

Herunterskalieren: erst Drain, dann Entfernen

Beim Entfernen eines Servers zeigt sich die Asymmetrie, und sie ist Physik, keine Einschränkung, die man per Flag umgehen könnte. Ein ausscheidender Server hält Daten — seinen Anteil der Partitionen. Verschwände er einfach, verschwänden die Daten mit ihm.

Deshalb ist das Herunterskalieren eine Drain-dann-Entfernen-Operation und kein sofortiges Beenden. Bevor ein ausscheidender Server geht, müssen seine Partitionen ihre Daten auf die verbleibenden Server migrieren. Erst wenn dieser Drain der Datenebene abgeschlossen ist, hat der ausscheidende Server wirklich alles übergeben, wofür er zuständig war, und erst dann kann er gefahrlos gehen.

# Remove a server from the store's definition — this initiates the drain
Remove-ZrServer -Store orders -Server zaris-c.example.com:7861

Remove-ZrServer bearbeitet die Soll-Gestalt so, dass dieser Server ausgeschlossen wird, und der Supervisor führt den Store auf die neue Definition zu, indem er die Partitionen des ausscheidenden Servers auf die verbleibenden verschiebt, bevor dieser herausfällt. Das Denkmodell dazu lautet: Kapazität hinzufügen ist sofort und sicher; Kapazität verringern ist eine kontrollierte Migration. Behandeln Sie das Herunterskalieren als bewussten, überwachten Vorgang — starten Sie ihn, beobachten Sie den Fortschritt des Drains und vergewissern Sie sich, dass die Daten auf den verbleibenden Servern angekommen sind, bevor Sie den Server als weg betrachten. Einen Server herauszureißen, ohne ihn leerlaufen zu lassen, ist der Weg, die von ihm gehaltenen Daten zu verlieren.

Von der Konsole aus beobachten

Sie müssen nichts davon blind tun. Die Web-Konsole hat eine Servers-Ansicht, die die aktuelle Menge der Server hinter einem Store zeigt und deren Verwaltung ermöglicht. Sie ist der natürliche Ort, um:

• die aktuelle Menge zu sehen — welche Server sich gerade im Store befinden, im Vergleich zur Soll-Definition, auf die der Supervisor zusteuert.
• ein Hochskalieren zu verfolgen — zu bestätigen, dass ein neu hinzugefügter Server seine Partitionen übernommen hat und bedient.
• einen Drain beim Herunterskalieren zu überwachen — zu verfolgen, wie die Partitionen eines ausscheidenden Servers abwandern, bevor er geht, damit Sie wissen, dass der Drain abgeschlossen ist, statt zu raten.

Gerade beim Herunterskalieren ist diese Sichtbarkeit der Punkt. Ein Drain ist eine echte Datenbewegung mit Anfang und Ende, und die Servers-Ansicht zeigt Ihnen den Unterschied.

Die ehrliche Zusammenfassung

Elastische Skalierung in Zaris läuft darauf hinaus, eine Soll-Gestalt zu bearbeiten und den Supervisor den laufenden Store daran angleichen zu lassen:

• Hochskalieren (Add-ZrServer) ist die einfache, sichere Richtung — live, mit Neupartitionierung an Ort und Stelle und verlustfrei. Wachsen Sie in die Last hinein, wann immer nötig.
• Herunterskalieren (Remove-ZrServer) wird unterstützt und ist sicher, wenn Sie den Drain laufen lassen — die Daten des ausscheidenden Servers wandern zuerst zu den verbleibenden, planen Sie das Verringern der Kapazität also als bewussten, überwachten Vorgang statt als sofortiges Beenden.

Dimensionieren Sie für den Traffic, den Sie haben, nicht für den, den Sie befürchtet haben, und ändern Sie Ihre Meinung später — nach oben ohne Zeremonie, nach unten mit Sorgfalt.