Comment Clustron Zaris s'intègre à votre infrastructure
Un plan de données en mémoire, auto-coordonné et répliqué, que vous embarquez et exploitez vous-même — avec une console et un manager intégrés, et aucun coordinateur externe à exploiter. Sur Kubernetes, Docker, Windows ou n'importe quel cloud.
Un plan de données, coordonné par lui-même
Les clients parlent directement aux nœuds avec une seule chaîne de connexion. Les nœuds forment un cluster, répliquent les partitions et se réparent eux-mêmes — pendant que la console et le manager observent depuis le côté.
Quatre cœurs composables, un seul store
Zaris est ce que vous obtenez lorsque les blocs de construction de Clustron sont composés en un seul store distribué — chacun résolvant une partie difficile de l'exécution de logiciels sur plus d'une machine.
Clustron Zaris
Store clé-valeur en mémoire, partitionné et répliqué. Il possède le chemin de données : puts, gets, transactions, watches, baux, compteurs et TTL — servis directement depuis le nœud qui possède chaque partition.
Clustron Nodus
Appartenance pair-à-pair, élection de leader et messagerie typée. C'est pourquoi il n'y a ni ZooKeeper, ni etcd, ni Consul à exploiter — le cluster se coordonne lui-même.
Clustron Security
TLS mutuel avec quatre modèles de CA/confiance, jetons porteurs vérifiés hors ligne et RBAC refusant par défaut — le même tissu de confiance sur le plan de données et la console.
Clustron Observability
Métriques glissantes à faible allocation sur le chemin critique — taux, jauges et statistiques d'exécution — poussées vers le manager et exportables via OTLP.
Disponible par conception, pas en option ajoutée
- Aucun point de défaillance uniqueChaque partition est répliquée (RF copies) sur plusieurs nœuds. Perdez un nœud et une réplica survivante continue de servir ; la carte ne se régénère que lorsque chaque copie d'une partition a disparu.
- Mise à l'échelle horizontaleAjoutez des pods et la carte des partitions s'étend sur eux — un simple kubectl scale avec la découverte Kubernetes. Le client apprend automatiquement la nouvelle topologie.
- Convergence auto-réparatriceUn réconciliateur de pairs actifs fait converger un cluster démarré à froid ou partiellement rejoint vers l'appartenance réelle, et re-réplique les partitions sous-couvertes jusqu'au RF complet.
Auto-hébergé, sur votre infrastructure
Clustron Zaris s'exécute entièrement dans votre environnement — vos données ne le quittent jamais. Le même cluster, la même chaîne de connexion, sur tout ce que vous exécutez déjà.
Kubernetes
Chart Helm officiel : StatefulSet + Service headless, kubectl scale à chaud, Services externes par pod, et TLS par secret monté ou par enrôlement.
Docker et Compose
Fichiers compose prêts à l'emploi pour un cluster multi-nœuds et un demostore sécurisé (jeton + TLS) — une seule commande vers un cluster en fonctionnement.
Windows et VM cloud
S'exécute comme un simple processus à partir d'un fichier de configuration sous Windows ou sur n'importe quelle VM. La même chaîne de connexion l'atteint depuis n'importe où.
Une confiance qui s'étend à tout le cluster
- TLS mutuel, quatre modèles de CACA auto/co-localisée, votre propre CA, CA intermédiaire ou feuilles pré-émises. Nœud↔nœud est mutuel ; le plan de données client est en authentification serveur avec identité par jeton.
- Authentification par jetonJetons porteurs vérifiés hors ligne — aucun aller-retour vers un serveur d'authentification sur le chemin critique. Transmettez-les en toute sécurité via des références env: ou file: dans la chaîne de connexion.
- RBAC refusant par défautContrôle d'accès basé sur les rôles pour les stores et les opérations d'administration, appliqué au niveau du nœud et exposé dans la console.
Chaque opération, en temps réel
Débit, réplication, latence, mémoire et éviction — en direct dans la console et exportables via OTLP vers la stack que vous exécutez déjà.
Questions fréquentes
Clustron Zaris a-t-il besoin d'un coordinateur externe ?
Non. Le clustering, l'élection de leader et la messagerie sont intégrés via Nodus. Il n'y a ni ZooKeeper, ni etcd, ni Consul à déployer, sécuriser et exploiter.
Comment les clients se connectent-ils ?
Avec une seule chaîne de connexion — zaris://host1,host2/store (ou zariss:// pour TLS). Les hôtes forment une liste d'amorçage avec basculement ; le client apprend ensuite la topologie complète depuis le cluster. Le nom du store dans le chemin est l'identifiant du cluster.
Comment se met-il à l'échelle, et est-ce sans perte ?
La montée en charge est un kubectl scale à chaud avec la découverte Kubernetes — de nouveaux pods rejoignent et la carte des partitions s'étend sur eux sans redémarrage ni perte de données. Réduisez une étape à la fois pour que la réplication puisse rétablir le RF entre les étapes.
Les clients hors du cluster peuvent-ils se connecter ?
Oui. Activez l'accès externe et chaque nœud annonce une adresse joignable de l'extérieur (adresses annoncées façon Kafka) via un second listener, avec un Service par pod. Sécurisez-le avec TLS dont le SAN du certificat porte le nom d'hôte externe.
In-process ou en cluster ?
Les deux, avec le même code. Exécutez un store in-process embarqué pour le développement et les tests, puis pointez le même client vers un vrai cluster multi-nœuds en production.
Comment l'observe-t-on ?
Chaque cluster est livré avec la console web (débit en temps réel, partitions, santé des nœuds, données et sécurité) et les nœuds exportent des métriques via OTLP vers votre stack existante.
Concevez votre cluster avec nous
D'un simple store embarqué à un déploiement Kubernetes multi-nœuds sécurisé — la documentation et l'équipe sont là.