Deployment-Überblick
Der Betrieb von Zaris läuft auf zwei Entscheidungen hinaus: Welches Deployment-Modell die Node-Prozesse besitzt und in welcher Umgebung Sie sie betreiben. Diese Seite erklärt die Modelle, vergleicht die Umgebungen und verweist auf eine Schritt-für-Schritt-Anleitung für jede davon.
Zaris startet auf jedem Rechner mit einer automatischen 30-Tage-Testphase. Der Produktiveinsatz ist lizenzpflichtig (pro Rechner — ein Rechner, ein Seat). Nach Ablauf der Testphase wird zuerst die Web Console gesperrt; nach einer Karenzzeit stellt das Produkt den Betrieb ein, bis eine Lizenz aktiviert wird. Es wird dabei nie etwas gelöscht. Siehe Support und Lizenzierung und die Anleitung zu Lizenzierung und Aktivierung.
Die beiden Deployment-Modelle
Jeder Zaris-Cluster besteht aus einem Management Service (der Steuerungsebene mit der Web Console) und einem oder mehreren Nodes (der Datenebene, die Ihre Daten speichert). Die Modelle unterscheiden sich nur darin, wer die Node-Prozesse besitzt.
Der Manager legt sein Modell beim Start einmalig anhand der Umgebungsvariable ZARIS_MGMT_MODE fest. Der Default ist supervisor.
Supervisor-Modell
Im Supervisor-Modell erstellt und besitzt der Management Service die Nodes — er forkt, startet, stoppt, startet neu und skaliert sie. Sie richten Stores mit den AdminShell-Cmdlets oder der Web Console ein, und der Manager startet die Node-Prozesse lokal. Dies ist das Modell für Hosts, die Sie direkt verwalten, etwa Windows-Dienste und VMs. Es ist zudem die natürliche Heimat der von Clustron signierten CA-Modi 0–2, da sich Nodes ihre Zertifikate über den Manager ausstellen lassen.
Dies ist der Default; legen Sie ihn explizit mit ZARIS_MGMT_MODE=supervisor fest.
Attach-Modell
Im Attach-Modell betreibt ein externer Orchestrator — Docker, Docker Compose oder Kubernetes — die Node-Prozesse, und der Management Service beobachtet sie lediglich, während er die Steuerungsebene und die Console bereitstellt. Der Manager forkt nie einen Node; Sie registrieren den extern betriebenen Store bei ihm (Register-ZrStore oder die Registrierungs-API). Da ein Manager den gesamten Cluster beobachtet, zeigen Console und CLI eine einzige, konsistente Mitgliedschaftsansicht. Dies ist das Modell für containerisierte und orchestrierte Deployments und die Heimat von CA-Modus 3 (vorab ausgestellte Leaf-Zertifikate), bei dem der Orchestrator das Zertifikat jedes Nodes einbindet.
Wählen Sie es mit ZARIS_MGMT_MODE=attach. Im Attach-Modus weigert sich der Manager, Stores zu erstellen oder zu forken — der Orchestrator besitzt den Node-Lebenszyklus.
Die beiden Modelle passen von Natur aus zu je einer Umgebung und einem Trust-Modus, aber das Modell ist nur eine Einstellung — Sie sind nicht festgelegt.
| Supervisor | Attach | |
|---|---|---|
| Wer die Nodes betreibt | Management Service | Ihr Orchestrator |
| Start / Stopp / Skalierung über | Zaris-Cmdlets oder Console | Ihren Orchestrator |
| Zertifikate | Per Enrollment (Clustron signiert) | Eingebunden (Sie stellen sie aus) |
| Am besten geeignet für | Windows- und VM-Hosts, die Sie verwalten | Docker, Compose und Kubernetes |
Die Umgebungen
Wählen Sie die Umgebung, die Ihrem Betriebsort entspricht, und folgen Sie der zugehörigen Anleitung. Alle containerbasierten Umgebungen verwenden dasselbe Node-Image und das Attach-Modell.
| Umgebung | Modell | Sie erhalten | Einsatzzweck |
|---|---|---|---|
| Windows-Installation | Supervisor | Management Service und Web Console als Windows-Dienste, PowerShell-Module und die Node-Runtime — aus einem Paket | Hosts und VMs, die Sie direkt verwalten; der schnellste Weg zu einem funktionierenden Cluster mit Console |
| Docker-Container | Attach | Ein einfacher, nicht abgesicherter Cluster nur aus Nodes, aus einem Image und einer gemeinsamen Konfiguration | Lokale Entwicklung und Evaluierung; ein schlanker, reproduzierbarer Cluster auf einem einzelnen Docker-Host |
| Docker Compose (abgesichert) | Attach | Ein abgesicherter Multi-Node-Cluster mit Manager, Mutual TLS und Token-Authentifizierung | Ein abgesicherter Cluster auf einem Host; Test des Mode-3-Workflows mit eingebundenen Zertifikaten vor Kubernetes |
| Kubernetes | Attach | Ein offizielles Helm-Chart: ein StatefulSet mit stabiler Identität, Headless Discovery, Hot-kubectl-Scale-out, Readiness-gesteuerte Rolling Updates, ein PodDisruptionBudget, Clients außerhalb des Clusters und TLS über Secrets | Orchestrierung eines selbstheilenden Clusters mit elastischem Scale-out und sicheren Rolling Updates über mehrere Rechner hinweg |
Ein Hinweis zu Ports
Ein laufender Store stellt einen kleinen, vorhersehbaren Satz an Ports bereit, der auf der Seite Admin-Leitfaden → Ports dokumentiert ist:
- Management-API und Web Console — die Steuerungsebene (Default
7801und7810). - Node-Client-Port — dort verbinden sich Clients der Datenebene (
7861in den Container-Images). - Node-Cluster-Port — Datenverkehr zwischen den Nodes innerhalb des Clusters (
7811in den Container-Images).
Unabhängig von Modell und Umgebung verbinden sich Clients stets mit den Node-Client-Ports, und Administratoren nutzen die Management-API und die Console.
Nächste Schritte
- Betrieb auf einem Windows-Host → Windows-Installation.
- Einen einfachen Cluster in Containern betreiben → Docker-Container.
- Einen abgesicherten Cluster mit Compose betreiben → Docker Compose (abgesichert).
- Orchestrierung auf Kubernetes → Kubernetes.