Wie Clustron Zaris in Ihre Infrastruktur passt
Eine sich selbst koordinierende, replizierte In-Memory-Datenebene, die Sie einbetten und selbst betreiben — mit integrierter Konsole und Manager und ohne externen Koordinator. Auf Kubernetes, Docker, Windows oder in jeder Cloud.
Eine Datenebene, die sich selbst koordiniert
Clients sprechen die Nodes direkt über einen einzigen Connection String an. Die Nodes bilden ein Cluster, replizieren Partitionen und heilen sich selbst — während Konsole und Manager von der Seite aus beobachten.
Vier kombinierbare Kerne, ein Store
Zaris entsteht, wenn die Bausteine von Clustron zu einem verteilten Store zusammengesetzt werden — jeder löst einen schwierigen Teil des Softwarebetriebs über mehr als eine Maschine hinweg.
Clustron Zaris
Partitionierter, replizierter In-Memory-Key/Value-Store. Er besitzt den Datenpfad: Puts, Gets, Transaktionen, Watches, Leases, Zähler und TTL — bedient direkt von dem Node, dem die jeweilige Partition gehört.
Clustron Nodus
Peer-to-Peer-Mitgliedschaft, Leader-Election und typisiertes Messaging. Deshalb müssen Sie weder ZooKeeper noch etcd oder Consul betreiben — das Cluster koordiniert sich selbst.
Clustron Security
Mutual TLS mit vier CA-/Vertrauensmodellen, offline verifizierten Bearer-Tokens und Deny-by-Default-RBAC — dasselbe Vertrauensgeflecht über Datenebene und Konsole hinweg.
Clustron Observability
Allokationsarme, rollierende Metriken im Hot Path — Raten, Gauges und Laufzeitstatistiken — an den Manager übertragen und per OTLP exportierbar.
Verfügbar von Grund auf, nicht nachträglich angeflanscht
- Kein Single Point of FailureJede Partition wird (RF-fach) über mehrere Nodes repliziert. Fällt ein Node aus, bedient ein überlebendes Replikat weiter; die Map wird erst neu erzeugt, wenn sämtliche Kopien einer Partition verloren sind.
- Horizontal skalierbarFügen Sie Pods hinzu, und die Partition-Map wächst auf sie hinein — ein einfaches kubectl scale mit Kubernetes-Discovery. Der Client lernt die neue Topologie automatisch.
- Selbstheilende KonvergenzEin Live-Peer-Reconciler bringt ein kalt gestartetes oder nur teilweise beigetretenes Cluster auf die tatsächliche Mitgliedschaft und repliziert unterversorgte Partitionen wieder auf den vollen RF.
Selbst gehostet, auf Ihrer Infrastruktur
Clustron Zaris läuft vollständig in Ihrer Umgebung — Ihre Daten verlassen sie nie. Dasselbe Cluster, derselbe Connection String, auf allem, was Sie bereits betreiben.
Kubernetes
Offizielles Helm-Chart: StatefulSet + Headless Service, heißes kubectl scale, Services pro Pod für externen Zugriff sowie TLS per gemountetem Secret oder Enrollment.
Docker & Compose
Fertige Compose-Dateien für ein Multi-Node-Cluster und einen gesicherten (Token + TLS) Demostore — ein Befehl bis zum laufenden Cluster.
Windows & Cloud-VMs
Läuft als einfacher Prozess aus einer Konfigurationsdatei unter Windows oder auf jeder VM. Derselbe Connection String erreicht es von überall.
Vertrauen, das das gesamte Cluster umspannt
- Mutual TLS, vier CA-ModelleAuto/co-located, eigene CA (Bring-your-own), Intermediate-CA oder vorab ausgestellte Leaf-Zertifikate. Node↔Node ist gegenseitig; die Client-Datenebene nutzt Server-Authentifizierung mit Token-Identität.
- Token-AuthentifizierungOffline verifizierte Bearer-Tokens — kein Round-Trip zu einem Auth-Server im Hot Path. Übergeben Sie sie sicher über env:- oder file:-Referenzen im Connection String.
- Deny-by-Default-RBACRollenbasierte Zugriffskontrolle über Stores und Administrationsvorgänge hinweg, am Node durchgesetzt und in der Konsole sichtbar.
Jede Operation, in Echtzeit
Durchsatz, Replikation, Latenz, Speicher und Eviction — live in der Konsole und per OTLP in den Stack exportierbar, den Sie bereits betreiben.
Häufig gestellte Fragen
Braucht Clustron Zaris einen externen Koordinator?
Nein. Clustering, Leader-Election und Messaging sind über Nodus eingebaut. Sie müssen weder ZooKeeper noch etcd oder Consul aufsetzen, absichern und betreiben.
Wie verbinden sich Clients?
Mit einem einzigen Connection String — zaris://host1,host2/store (bzw. zariss:// für TLS). Die Hosts sind eine Seed-Liste mit Failover; anschließend lernt der Client die vollständige Topologie vom Cluster. Der Store-Name im Pfad ist die Cluster-ID.
Wie skaliert es, und geschieht das verlustfrei?
Das Hochskalieren ist ein heißes kubectl scale mit Kubernetes-Discovery — neue Pods treten bei und die Partition-Map wächst auf sie hinein, ohne Neustart und ohne Datenverlust. Skalieren Sie schrittweise herunter, damit die Replikation zwischen den Schritten den RF wiederherstellen kann.
Können sich Clients außerhalb des Clusters verbinden?
Ja. Aktivieren Sie den externen Zugriff, und jeder Node meldet über einen zweiten Listener eine von außen erreichbare Adresse (Advertised Addresses im Kafka-Stil), mit einem Service pro Pod. Sichern Sie ihn mit TLS ab, dessen Zertifikats-SAN den externen Hostnamen enthält.
In-Process oder geclustert?
Beides, mit demselben Code. Betreiben Sie für Entwicklung und Tests einen eingebetteten In-Process-Store und richten Sie in der Produktion denselben Client auf ein echtes Multi-Node-Cluster.
Wie wird es überwacht?
Jedes Cluster wird mit der Web-Konsole ausgeliefert (Echtzeit-Durchsatz, Partitionen, Node-Zustand, Daten und Sicherheit), und die Nodes exportieren Metriken per OTLP in Ihren bestehenden Stack.
Entwerfen Sie Ihr Cluster gemeinsam mit uns
Vom einzelnen eingebetteten Store bis zum gesicherten Multi-Node-Kubernetes-Deployment — die Dokumentation und das Team sind für Sie da.