Die Steuerungsebene in Ihrer Shell: Einen Zaris-Cluster mit PowerShell betreiben
Das meiste, was man über einen Datenspeicher liest, handelt vom Datenpfad — Lese- und Schreibvorgänge, das Wire-Protokoll, wie schnell es ist. Doch bevor das alles zählt, muss jemand das Ding aufsetzen: entscheiden, wie viele Partitionen es hat, wie viele Kopien jeder davon, wo die Ports liegen, es starten, bestätigen, dass es gesund hochgekommen ist, und es im Betrieb beobachten. Das ist die Steuerungsebene, und in Zaris lebt sie in PowerShell.
Dies ist eine Day-one-Anleitung für Operatoren. Wir legen einen Workspace an, stellen einen Store bereit, starten ihn und lesen dann seinen Live-Zustand zurück — alles aus dem Modul AdminShell. Keine Web-Konsole nötig, nichts von Hand bearbeitet. Und weil bei einer Operator-Geschichte Vertrauen der ganze Punkt ist, benennen wir klar die Entscheidungen, die New-ZrStore Ihnen vorlegt, und was jede tatsächlich kostet.
Zwei Shells, zwei Ebenen
Zaris liefert seine Kommandozeilenoberfläche als zwei getrennte PowerShell-Module, und die Trennung ist nicht kosmetisch — sie spiegelt die beiden Ebenen des Systems:
- AdminShell ist die Steuerungsebene. Ihre Cmdlets stellen Stores bereit, starten, stoppen, inspizieren und skalieren sie. Sie sprechen mit dem Zaris-Management Service (dem „Manager"), nicht direkt mit den Datenknoten. Das sind die Verben
New-ZrStore,Get-ZrNode,Watch-ZrStoreMetrics. - ClientShell ist die Datenebene. Ihre Cmdlets —
Connect-ZrStore,Get-ZrItem,Set-ZrItem— öffnen eine Verbindung direkt zu den Nodes des Stores und bewegen Key/Value-Daten. Das ist die Oberfläche, die eine Anwendung nutzt, und das Thema des Beitrags zu Connection-Strings.
Ein Operator, der einen Cluster aufsetzt, lebt fast ausschließlich in AdminShell. Der Manager, mit dem sie spricht, ist die Komponente, die die gewünschte Form jedes Stores kennt und die realen Prozesse darauf zutreibt. Das Erste ist also, Ihrer Shell zu sagen, mit welchen Managern sie sprechen soll.
Schritt 0 — ein Workspace als Ziel
Ein Workspace ist eine benannte Menge von Managern, auf die Admin-Cmdlets zielen, und wird unter ~/.clustron persistiert, sodass er Sitzungen überdauert. Sie legen ihn einmal an und wechseln in ihn, wann immer Sie eine Shell öffnen:
# Create a workspace pointing at the cluster's managers (does not activate it)
New-ZrWorkspace -Name "prod" -Managers "10.0.0.10:7801","10.0.0.11:7801"
# Make it the active target for this and future sessions
Use-ZrWorkspace prod
Jeder Manager-Endpunkt ist ein Beobachter eines Clusters — listen Sie alle auf, und die Admin-Cmdlets aggregieren den Zustand über den gesamten Cluster, statt über das, was eine einzelne Maschine zufällig weiß. Ist in Ihrem Cluster Security aktiviert, hinterlegen Sie ein Admin-Token im Workspace (-Token) oder authentifizieren die Sitzung mit Connect-ZrManager -Credential (Get-Credential) -Force, das Benutzername und Passwort gegen ein Sitzungs-Token tauscht. (Connect-ZrManager ist das ältere Ad-hoc-Connect und funktioniert weiterhin, aber die Workspace-Cmdlets sind der aktuelle Weg — auf sie bilden sich die gespeicherten Workspaces der Web-Konsole ab.)
Eine ehrliche Weggabelung: Die folgende Anleitung folgt dem Supervisor-Modell, bei dem jeder Manager seine lokalen Zaris-Prozesse forkt und besitzt — das native Windows-Deployment. Laufen Ihre Nodes stattdessen unter einem Orchestrator wie Kubernetes (das Attach-Modell), erstellt der Manager keine Prozesse; Sie definieren den Store mit Ihrem Orchestrator und übernehmen ihn mit Register-ZrStore statt New-ZrStore. New-ZrStore erkennt einen Manager im Attach-Modus und sagt es Ihnen, statt tief im Stack zu scheitern.
Schritt 1 — den Store bereitstellen
Dies ist das Cmdlet mit den echten Entscheidungen. Die minimale Produktionsform ist kurz:
New-ZrStore -Name "orders" `
-ReplicationFactor 2 `
-BaseClusterPort 7811 `
-BaseClientPort 7861
Das erstellt einen Store namens orders über alle Maschinen im Workspace, mit zwei Kopien jeder Partition. Vier Parameter tragen das Gewicht, also seien wir bei jedem präzise.
-ReplicationFactor ist die Gesamtzahl der Kopien jeder Partition — Primary plus Replikate. In der Produktion darf er höchstens der Anzahl der Maschinen entsprechen, damit jede Kopie auf einer anderen Maschine liegt; das macht aus ihm Fehlertoleranz statt Dekoration. Auf einer einzelnen Dev-Box wird die Einschränkung mit einer Warnung gelockert — Replikate teilen sich eine Maschine, was zum Testen in Ordnung ist und bei einem echten Ausfall nichts bringt. Das Cmdlet sagt das laut, statt Sie etwas anderes glauben zu lassen.
-PartitionsPerNode ist standardmäßig 1, die Produktionstopologie. Die Gesamtzahl der Partitionen wird aus der aktuellen Cluster-Mitgliedschaft abgeleitet — PartitionsPerNode × live nodes — und bei jeder Mitgliedschaftsänderung neu berechnet, ist also keine Zahl, die Sie bei der Erstellung einfrieren. Sie erhöhen sie über 1 hauptsächlich für lokale Tests, wenn Sie partitionsbewusstes Verhalten (Segment-Routing, Rebalance beim Scale-out) auf einer einzelnen Maschine beobachten wollen, ohne ein Rack aufzubauen.
-BaseClusterPort / -BaseClientPort sind die ersten Ports zweier Bereiche: der interne Gossip-/Cluster-Port und der clientseitige Port, pro Prozess auf jeder Maschine um eins erhöht. Das Cmdlet prüft, dass sich die beiden Bereiche nicht überschneiden, und weigert sich, einen Store zu erstellen, der mit sich selbst kollidieren würde — ein kleiner Schutz, der einen verwirrenden Fehlstart erspart.
Drei weitere sind erwähnenswert, weil sie einen echten Zielkonflikt bei der Dauerhaftigkeit abbilden:
New-ZrStore -Name "orders" -ReplicationFactor 3 `
-BaseClusterPort 7811 -BaseClientPort 7861 `
-ReplicationMode Sync `
-WriteQuorumPolicy Majority `
-AllowReplicaReads
-ReplicationModeist standardmäßigAsync: Der Primary schreibt lokal und kehrt sofort zurück, die Replikation läuft im Hintergrund. Das ist die schnellste Option und der richtige Default für einen Cache — aber machen Sie sich klar, dass ein unterAsyncbestätigter Schreibvorgang noch nicht garantiert auf einem Replikat liegt. Wählen SieSync, wartet der Primary auf die Bestätigung der Replikate, bevor erOkliefert, und tauscht Latenz gegen Dauerhaftigkeit.-WriteQuorumPolicygreift nur unterSync:All(jedes Replikat muss bestätigen),Majority(floor(RF/2)+1müssen bestätigen) oderBestEffort(Fehler werden protokolliert, lassen den Schreibvorgang aber nicht scheitern).-AllowReplicaReadserlaubt Clients, von Replikat-Nodes zu lesen, um die Leselast zu verteilen — mit dem ehrlichen Vorbehalt, dass ein Replikat-Lesevorgang leicht veraltete Daten liefern kann, weil ein Replikat dem Primary hinterherhinken kann. Lassen Sie es aus, wenn Sie Read-your-writes brauchen; schalten Sie es ein, wenn Sie lieber den Durchsatz hätten und den Lag tolerieren.
Beachten Sie, was die Defaults über Zaris' Haltung sagen: Async + Lesen vom Primary ist ein schneller, standardmäßig korrekter Cache. Die Dauerhaftigkeits-Regler sind da, wenn Sie sie brauchen, klar benannt, jeweils mit sichtbaren Kosten.
Schritt 2 — starten und bestätigen, dass er hochgekommen ist
Das Erstellen eines Stores definiert seine Form; es führt die Prozesse nicht aus. Start-ZrStore zählt die Instanzen des Stores auf jedem Manager auf und startet sie, wobei Erfolg oder Misserfolg pro Instanz gemeldet wird:
Start-ZrStore -Name "orders"
Nun der Teil, der einen Operator von jemandem unterscheidet, der einen Befehl ausführte und hoffte. Get-ZrStore liest den Live-Zustand des Stores von den Managern zurück — Gesamtstatus, Uptime und den Laufzustand jedes Nodes:
Get-ZrStore orders
Store : orders
Status : Running
Uptime : 2h 14m (since 2026-10-03 09:41:12)
Nodes (4)
───────────────────────────────────────────
● 10.0.0.10-n0 10.0.0.10:7861 Running up 2h 14m
● 10.0.0.10-n1 10.0.0.10:7862 Running up 2h 14m
● 10.0.0.11-n0 10.0.0.11:7861 Running up 2h 14m
● 10.0.0.11-n1 10.0.0.11:7862 Running up 2h 14m
───────────────────────────────────────────
Running: 4 Stopped: 0
Der Store-Status ist eine Zusammenfassung: Running, wenn jeder Node läuft, Stopped, wenn alle ausgefallen sind, und Partial, wenn manche laufen und manche nicht — genau der Zustand, den Sie laut angezeigt haben wollen, denn ein Partial-Store ist einer, der ungleichmäßig gestartet ist. Die Uptime ist bewusst die vom Kern gemeldete Cluster-Bildungszeit — der früheste Node-Start, der den Churn überlebt hat —, nicht der älteste aktuell laufende Prozess, damit ein Store, der seit Stunden bedient, nicht „ein paar Minuten" meldet, nur weil ein Node neu gestartet wurde.
Für die nächste Ebene darunter zeigt Get-ZrNode Rollen und die Partition-Map:
Get-ZrNode orders
Nodes (4)
─────────────────────────────────────────────────────────────────────────
● 10.0.0.10-n0 10.0.0.10:7861 Running Primary v7
● 10.0.0.10-n1 10.0.0.10:7862 Running Replica v7
● 10.0.0.11-n0 10.0.0.11:7861 Running Primary v7
● 10.0.0.11-n1 10.0.0.11:7862 Running Replica v7
Die Spalte Primary/Replica zeigt, wer gerade jede Partition besitzt, und v7 ist die Version der Partition-Map — die Generationsnummer der Ownership-Map. Stimmen alle Nodes in derselben Map-Version überein, ist der Besitz konvergiert; ein Node, der auf einer älteren Version festhängt, hat die jüngste Umverteilung noch nicht eingeholt. Fragen Sie einen einzelnen Node nach Details (Get-ZrNode orders 10.0.0.10-n0), erweitert sich das auf die exakten Primary- und Replikat-Partitions-IDs, die er hält, und wann sich seine Rolle zuletzt änderte — die Ansicht, zu der Sie greifen, wenn gerade ein Failover stattgefunden hat und Sie wissen wollen, wo der Besitz gelandet ist.
Schritt 3 — im Betrieb beobachten
Ein Snapshot sagt Ihnen, dass der Store läuft. Eine Live-Ansicht sagt Ihnen, was er tut. Watch-ZrStoreMetrics fragt die Manager ab und zeichnet in einem Intervall eine Tabelle pro Node neu, bis Sie abbrechen:
Watch-ZrStoreMetrics -StoreName orders -RefreshSec 2
Sie legt zuerst die alltäglichen Zähler aus — Request-Rate, Gets, Puts, Deletes, Item-Anzahl, Speicherverbrauch — und schiebt die erweiterten Replikations- und Sync-Diagnosen nach unten, sodass die Zahlen, die Sie auf einen Blick prüfen, oben stehen. Fehlerzähler werden rot, sobald ihre Rate über null steigt; der Durchsatz färbt sich grüner, je höher er steigt. Sie hebt auch Rollenwechsel inline hervor: Kippt ein Failover einen Primary zu einem Replikat, während Sie zusehen, wird eine Zeile [ROLE CHANGE] mit Zeitstempel ausgegeben — das Live-Signal, dass eine Partition gerade den Besitzer gewechselt hat.
Ein bewusstes Detail, das es wert ist, genannt zu werden, weil es ein Werkzeug um 2 Uhr nachts benutzbar macht: Die Ansicht holt den nächsten Frame, bevor sie den Bildschirm löscht, und ein vorübergehend leerer Poll behält den letzten guten Frame, statt zu leeren. Sie erhalten eine ruhige Tabelle statt einer flackernden, egal wie langsam ein Manager antwortet.
Zur Abrundung der Nur-Lese-Befehle meldet Get-ZrInfo die installierte Version, die Installations- und Datenverzeichnisse, beide Modulpfade, die Host-Runtime — und prüft jeden Manager auf Erreichbarkeit. Ein abgesicherter Manager, der mit 401 antwortet, wird als erreichbar, aber Authentifizierung nötig gemeldet, nicht als „down", sodass Sie ein Netzwerkproblem auf einen Blick von einem fehlenden Token unterscheiden können.
Schritt 4 — stoppen, und die Form darunter
Einen Store herunterzufahren ist das Lebenszyklus-Gegenstück zum Starten:
# Fast whole-store stop (default: a hard kill, since every node goes down together)
Stop-ZrStore -Name orders
# Per-node drain and clean cluster-leave
Stop-ZrStore -Name orders -Graceful
Der Default ist ein schneller harter Kill, das richtige Verhalten, wenn der gesamte Store auf einmal herunterfährt — es gibt keinen überlebenden Cluster, an den ein scheidender Node übergeben könnte, ein Drain bringt also nichts. Verwenden Sie -Graceful, wenn jeder Node sauber drainen und den Cluster verlassen soll, was wichtig ist, wenn Sie nur eine Teilmenge statt des Ganzen stoppen.
Unter jedem Cmdlet in diesem Beitrag liegt eine Idee: Ein Zaris-Store hat eine gewünschte Form — eine kanonische Definition der Server und Partitionen, die er haben soll —, und der Manager läuft unter einem Supervisor-Modell, das die Live-Prozesse kontinuierlich darauf zutreibt. New-ZrStore schreibt diese Form; Start-ZrStore realisiert sie; Get-ZrStore und Get-ZrNode melden, wie nah die Realität ihr ist. Dasselbe Modell macht elastisches Resizing zu einem Einzeiler statt zu einem Runbook — die gewünschte Form mit Add-ZrServer / Remove-ZrServer ändern und den Supervisor abgleichen lassen, was eine eigene Geschichte über elastische Skalierung ist.
Die ehrliche Zusammenfassung
Der vollständige Day-one-Lebenszyklus besteht aus fünf Befehlen und zwei Lesevorgängen:
New-ZrWorkspace -Name prod -Managers "10.0.0.10:7801","10.0.0.11:7801"
Use-ZrWorkspace prod
New-ZrStore -Name orders -ReplicationFactor 2 -BaseClusterPort 7811 -BaseClientPort 7861
Start-ZrStore -Name orders
Get-ZrStore orders # is it Running, and are all nodes up?
Get-ZrNode orders # who owns what, and did the map converge?
Watch-ZrStoreMetrics -StoreName orders -RefreshSec 2 # what's it doing now?
Was dies zu einer Steuerungsebene macht und nicht nur zu einem Haufen Skripte, ist, dass die Cmdlets live aggregierte Wahrheit melden — nicht, was Sie angefordert haben, sondern was der Cluster tatsächlich ist — und dass die Entscheidungen mit echten Konsequenzen offen benannt sind: Replikationsfaktor gegenüber Maschinenanzahl, Async gegenüber Sync, Replikat-Lesevorgänge gegenüber Veralterung. Einen Store aufsetzen, die Konvergenz bestätigen und ihn im Auge behalten — alles, ohne die Shell zu verlassen.