NebulaCB : une gestion Couchbase de niveau entreprise qui sauve la situation

Pourquoi les équipes Couchbase d'entreprise ont besoin d'un contrôle de mission

Couchbase alimente les charges de travail transactionnelles et analytiques critiques. Les mises à niveau progressives, la réplication entre centres de données (XDCR), les opérateurs Kubernetes et les événements de basculement sont toutes des opérations à enjeux élevés. Lorsque les outils sont fragmentés, les équipes s'appuient sur des scripts ad hoc, des salles de crise lentes et une visibilité incomplète, exactement au moment où la perte de données et les temps d'arrêt prolongés sont les plus préjudiciables.

NebulaCBest une plate-forme de gestion Couchbase open source et native Kubernetes positionnée comme contrôle de mission : orchestrer les mises à niveau, valider l'intégrité XDCR, surveiller la santé multicluster et utiliser l'analyse des causes profondes assistée par l'IA à partir d'un tableau de bord de style cockpit.

Ce que NebulaCB offre (en un coup d'œil)

Selon le récit du produit surnebulacb.org, NebulaCB met l'accent sur trois résultats majeurs pour les opérateurs :met à niveau sans crainte,valide toutetne perd rien. Sous cette égide, il combine l'automatisation opérationnelle, la preuve continue de l'intégrité des données et l'IA locale en option afin que la télémétrie sensible puisse rester sur votre réseau.

• Open source et compatible Kubernetes :s'adapte aux pratiques d'ingénierie de GitOps et de plate-forme ; s'intègre aux flux de travail basés sur l'opérateur autonome Couchbase et Helm.
• Esprit zéro perte de données : calendriers de comptage des documents, échantillonnage de hachage, détection des écarts de séquence et flux de travail d'audit pour prouver que les répliques sont restées cohérentes malgré les changements.
• XDCR à l'honneur : surveillance de la réplication bidirectionnelle, contrôles du pipeline, visibilité du décalage et de la topologie, et détection des retards GOXDCR – des problèmes courants lors des mises à niveau et des événements régionaux.
• AI sans clés cloud obligatoires :localOllamaintégration pour des diagnostics de type chat et une analyse structurée des causes profondes, avec des fournisseurs de cloud en option lorsque la politique le permet.

Ce quecmd/nebulacbconnecte ensemble

Le point d'entrée Go (github.com/balinderwalia/nebulacb/cmd/nebulacb) charge--config(config.jsonpar défaut), revient aux valeurs par défaut saines si le fichier est manquant, crée un collecteur de métriques, démarre éventuellement la gestionkubectl de redirection de portlorsqu'un kubeconfig est présent (y compris un contrôle de santé périodique pour reconnecter les transferts morts) et connecte chaque cluster enregistré via unCouchbase ClientPool. Il instancie ensuite Storm, l'orchestrateur de mise à niveau, le moteur XDCR, le validateur, le moteur de reporting, un moniteur multicluster (interrogation toutes les deux secondes), ainsi que les gestionnaires facultatifs d'IA, de sauvegarde, de basculement, de migration, de région et Docker. Tout est servi via un hub WebSocketpartagéet HTTP API, la même surface que l'interface utilisateur React etnebulacb-cliconsomment.

Espaces de travail du tableau de bord React

L'interface utilisateur livrée sousweb/nebulacb-uiexpose plusieurs onglets d'espace de travail :Cockpit(grille de contrôle de mission par défaut de style NASA), ancien tableau de bord,Ask AI,RCA,Knowledge,Insights,Pod Logs,Events,Operator(CouchbaseCluster CR health) etRunbooks— tous soutenus par des mises à jour WebSocket en direct.

Topologie de référence (local + k3s)

Pour une image concrète de la façon dont le serveur, l'interface utilisateur de développement facultative, la CLI, les clusters Couchbase et les tests de charge XDCR s'alignent, consultez le diagramme ci-dessous.

Mises à niveau progressives qui correspondent au fonctionnement réel des équipes SRE

NebulaCB décrit les mises à niveau progressives basées sur Helm avecpause, reprise, abandon et restauration, y compris l'application de correctifs à l'image de ressource personnalisée CouchbaseCluster, la surveillance du roulement du pod et le suivi de l'achèvement du rééquilibrage. La progression nœud par nœud et les chemins de rétrogradation explicites réduisent le risque « nous avons commencé une mise à niveau et ne pouvons pas l'annuler » qui maintient de nombreuses entreprises sur les anciennes versions de Couchbase.

XDCR et intégrité de la réplication

Pour les modèles multirégionaux et actifs-actifs, NebulaCB met en évidence la surveillance XDCR en temps réel : décalage de réplication, redémarrages de pipelines, modifications de topologie lors des mises à niveau et outils pour suspendre, reprendre, redémarrer ou arrêter les pipelines. Cette profondeur opérationnelle est importante lorsqu'un seul pipeline bloqué masque une synchronisation partielle qui n'apparaît que sous charge.

Validation de l'intégrité des données (prouver, ne pas présumer)

Au-delà des graphiques de décalage, NebulaCB annonce l'échantillonnage de hachageSHA-256, la détection des écarts de séquence, la surveillance continue du nombre de documents et les audits complets à la demande. Ces fonctionnalités soutiennent les équipes soucieuses de la conformité qui doivent prouver (et non des anecdotes) que les mises à niveau et les exercices de basculement n'ont pas divergé silencieusement les données.

Générateur de charge de tempête et exercices de type production

La plate-forme comprend un générateur de charge configurable (écritures, lectures, suppressions, rafales, touches de raccourci) avec percentiles de latence, ainsi qu'un chemin de test de charge autonome à double cluster. Associées à des panels d'intégrité, les équipes peuvent répéter les mises à niveau dans un trafic réaliste au lieu de découvrir les problèmes uniquement lors du week-end de mise en service.

HA, basculement, sauvegarde et migration

NebulaCB présente également la configuration du basculement automatique, le basculement manuel et gracieux, les chronologies des événements, les sauvegardes planifiées avec options de rétention et de chiffrement, ainsi que la migration avec des travailleurs parallèles et une validation post-exécution. Ensemble, ils transforment le tableau de bord en une console de cycle de vie plutôt qu'en une page de métriques en lecture seule.

Analyse basée sur l'IA avec Ollama

Les fonctionnalités répertoriées sur le site incluentAsk AIsur le contexte du cluster, des rapportsRCAstructurés avec des étapes de correction, une base de connaissancesintégréesur les problèmes Couchbase courants et l'intégration avecOllamaafin que les modèles tels que Llama 3 puissent fonctionner entièrement sur site. Le serveur prend également en charge d'autres fournisseurs (par exemple Anthropic ou OpenAI) via des variables de configuration et d'environnement lorsque la politique le permet. Cette conception prend en charge les industries réglementées dans lesquelles l’envoi de journaux à un API public n’est pas une solution.

CLI et API surface

bin/nebulacb-cliest un client HTTP pour le serveur en cours d'exécution : définissezNEBULACB_URL,NEBULACB_USERetNEBULACB_PASS(ou utilisez les valeurs par défaut des raccourcis Makefile). Les commandes fréquemment utilisées incluentstatus,start-load/pause-load/resume-load/stop-load,start-upgrade/abort-upgrade,restart-xdcr,run-audit,inject-failure,alerts,health,configetreport. Les points de terminaison REST

sont placés dans un espace de noms sous/api/v1(instantanés du tableau de bord, exécution de commandes, alertes, configuration, clusters, sauvegarde, migration, basculement, analyse IA – reportez-vous au README en amont pour la matrice complète). Les contrôles d'activité appellent généralementGET /api/v1/health, tandis que les tableaux de bord s'abonnent àws://<host>:<port>/wspour la télémétrie en streaming.

Répétition de mise à niveau typique

1. Lancezbin/nebulacb --config config.jsonet ouvrez le tableau de bord sur votre port configuré (8899 est la valeur par défaut courante).
2. Réchauffez le cluster avec Storm ounebulacb-cli start-load; exécutez éventuellementgo run ./cmd/xdcr-loadtest/pour le trafic à double cluster pendant que vous modifiez la topologie.
3. Exécutez la mise à niveau continue depuis le cockpit ou viastart-upgrade, en surveillant le décalage XDCR, les vignettes d'intégrité et les événements Kubernetes en parallèle.
4. Après le rééquilibrage des nœuds, exécutezrun-auditpour prouver que les hachages, le nombre de documents et les séquences s'alignent.
5. Capturez des preuves avecreportpour les tableaux consultatifs en matière de changement.

Comment cela sauve la situation pour les entreprises

• Mises à niveau plus rapides et plus sûres : l'orchestrationet la restauration raccourcissent les fenêtres de maintenance et réduisent le risque Sev-1.
• Détection plus précoce de la dérive de réplication : les signaux d'intégrité continue dudétectent les problèmes XDCR avant qu'ils ne se transforment en bugs de données visibles par le client.
• Temps moyen de résolution réduit : les tableaux de bordbasés sur WebSocket, RCA et les playbooks organisés compressent les cycles d'incidents.
• Alignement avec la réalité Kubernetes : les flux sensibles aux opérateurs ducorrespondent au nombre d'entreprises qui utilisent déjà Couchbase.
• Coût et souveraineté : le noyau open sourceet l'IA locale en option évitent la dépendance vis-à-vis d'un fournisseur pour chaque information.

Où aller ensuite

Explorez le site du projet surhttps://nebulacb.org/pour les chemins d'installation (source, Docker Compose, Helm), les diagrammes d'architecture et les liens GitHub. Si vous avez besoin d'aide pour concevoir Couchbase sur Kubernetes, XDCR multirégional ou pour intégrer l'observabilité et l'automatisation dans votre plate-forme, contactez Workstation àinfo@workstation.co.uk: nous concevons et expédions des plates-formes de données de production dans le cloud et en périphérie.