Un datacenter est une application que vous possédez, sur du matériel exploité par Xuda.
La plateforme ne loue plus le panneau de contrôle de quelqu'un d'autre. proxmox.farm_enabled est à true dans la configuration livrée, 12 types d'applications sont éligibles à la farm, et 'datacenter' est le premier de cette liste. En déployer un correspond à une seule méthode déclarée, deploy_datacenter, et sa déclaration décide qui peut l'appeler : clearance 'admin', min_plan 'pro', private: true. Cette combinaison signifie une session dashboard sur un plan Pro ou supérieur, et signifie qu'aucune clé API, quel que soit son mode, n'y accède, car private est le mur. C'est l'une des 19 méthodes seulement, sur les 1010 de la configuration du dépôt, à imposer un plancher de plan. Vous choisissez parmi 14 codes de métropoles et 16 tailles de serveur, de shared_hosting_1 jusqu'à large_hosting_32, et le résultat est un document app avec app_type 'datacenter' et un mot de passe admin CouchDB de 20 caractères généré à la volée, stocké sur le document sous couchdb_admin_password. Sur la farm, cette VM est un clone complet de son propre modèle Proxmox de référence, vmid 9101 ; tous les autres types éligibles à la farm hors VPS clonent l'image de déploiement partagée. Une précision à donner avant la suite de la page : la description du catalogue pour deploy_datacenter indique encore qu'elle crée un droplet DigitalOcean, et la fonction qu'elle appelle s'appelle toujours create_digitalocean_droplet, même si cette fonction confie la création à Proxmox avant que DO ne soit jamais considéré. Le nom est plus ancien que le matériel.
Ce qu'une publication affiche réellement.
Une publication est un déploiement progressif, pas une simple copie de fichiers. Elle sélectionne les documents xuda_servers avec docType 'regional_server', application_server à true et stat à 1, puis les parcourt un par un, en écrivant stat 2 publishing, 3 done ou 4 failed avec un stat_ts à chaque étape. Chaque région est vidée avant d'être touchée, et refuse d'être vidée s'il s'agit de la dernière région saine. La partie destructrice s'exécute détachée sous setsid depuis /tmp sur la cible, elle se termine donc même si l'orchestrateur, le broker ou la connexion SSH meurt en cours de route, et le déploiement interroge ensuite un marqueur de statut pendant jusqu'à 25 minutes tout en suivant le journal d'installation distant par décalage d'octets. Voici ses lignes.
Processus pm2 démarrés par une région depuis un seul fichier
États de publication que traverse un document de région
Capacité libre qu'un noeud doit garder au-delà de votre demande
Plafond par machine avant qu'un déploiement ne soit déclaré expiré
Xuda s'exécute sur cette farm de la même façon que votre datacenter.
Une région de Xuda et un datacenter client sont deux locataires sur les mêmes hôtes Proxmox, et la façon honnête de décrire le produit est de les mettre côte à côte plutôt que de décrire l'un en laissant entendre l'autre. Lisez les quatre lignes horizontalement : ce qui arrive sur la machine, ce qui s'exécute une fois qu'elle démarre, qui la reconstruit, et comment elle sort de rotation. Trois des quatre lignes diffèrent totalement, et la quatrième est celle où la différence cesse d'être un détail.
La réplication tient en quatre champs et deux documents, et rien de tout cela n'est du failover.
configure_datacenter_replication prend quatre paramètres : replicate_type, one-time ou continuous ; replicate_from, master ou datacenter ; replicate_direction, one_way ou two_way ; et apply, qui, à false, enregistre la configuration sans l'exécuter, si bien que rouvrir une amorce déjà terminée ne copie pas les données deux fois. Tout ce qui suit relève du CouchDB standard. La plateforme ajoute la plomberie : elle crée la base _replicator si le point de terminaison n'en a aucune, écrit un document par direction, démonte d'abord la paire précédente, et restreint ce qui traverse via un sélecteur. Les puces indiquent l'état existant après avoir cliqué sur enregistrer, car pour l'un des deux modes, la réponse est aucun.
- Un choix continu devient un document. replicate_datacenter construit replicate_opt avec create_target: false, ajoute continuous: true, et l'enregistre dans la base _replicator du point de terminaison choisi, en créant d'abord cette base si elle manque. Un choix ponctuel n'est pas du tout un document : il appelle replicate_couch_start une fois, la copie s'exécute, et rien ne reste sur le cluster pour la décrire. Même boîte de dialogue, deux quantités d'état durable très différentes, à cpi/deploy_module/index.mjs ligne 7302.
- Le mode bidirectionnel correspond à deux tâches unidirectionnelles pointées l'une vers l'autre. Le premier document porte le nom de l'id de l'app suivi de _1, source et target étant les deux URL plus leurs bases de données. Le flag two_way écrit un second document, _2, identique sauf que source et target sont inversés. La suppression suppose cette structure : delete_prev_replications retire _1 et _2 des deux points de terminaison et efface replication_stat avant que rien de nouveau ne soit écrit.
- Le sélecteur décide ce qui traverse, et il est volontairement grossier. Répliquer depuis master fixe replicate_opt.selector sur un $or portant sur docType workspace_drive et docType database, si bien que les métadonnées de drive et les lignes de table se déplacent et le reste du projet non. Scope setup et scope custom ne restreignent que la branche database, en ajoutant udfData.udffileid $in une liste d'identifiants de table lus depuis les documents de table du studio.
- Ce que cela ne fait pas. Rien ne promeut une réplique, rien ne redirige le trafic, et rien ne réconcilie un split brain au-delà du choix par CouchDB d'une révision gagnante déterministe, la perdante étant conservée comme conflit. Et CouchDB réplique les DOCUMENTS de drive, pas les fichiers : le dossier workspace_drive sur disque est synchronisé séparément par rsync, via /tmp pour que les deux VM ne se connectent jamais en SSH l'une à l'autre, comme amorce ponctuelle. La minuterie qui rendrait cette synchronisation de dossier continue reste un TODO dans le code source.
- Enregistrer les quatre champsclearance admin, private, détenu par app_module. apply: false s'arrête ici et n'écrit rien dans CouchDB.
- Supprimer la paire précédente_1 et _2 retirés des deux points de terminaison, replication_stat effacé. Un nouvel enregistrement remplace, il ne fusionne jamais.
- Construire replicate_optcreate_target: false toujours, continuous: true uniquement pour continuous, le sélecteur $or uniquement depuis master.
- Écrire, ou exécuter une seule foisContinuous écrit un document par direction. One-time publie une seule réplication, puis ajoute un reçu.
Cinq macro-régions sont proposées. Trois d'entre elles aboutissent à une machine.
Le champ région porte 14 codes de métropoles, et le sélecteur les regroupe en cinq macro-régions définies dans MACRO_REGIONS à cpi/deploy_module/index.mjs ligne 9515. Chaque entrée contient deux listes : farm_locations, les sites xuda Farm que possède la région, et do_slugs, les préfixes de slugs DigitalOcean qu'elle possède. Choisir une région ne choisit ni un fournisseur ni une machine. Cela restreint l'ensemble de candidats à ces deux listes, et le reste relève du placement.
Regional, Global, ou un que vous exploitez déjà.
Le même appel deploy_datacenter produit deux machines différentes selon un seul champ, app_hosting_preference, et une troisième option ne produit aucune machine du tout. Ce sont des chemins de code, pas des paliers, et ils répondent différemment aux quatre questions qui comptent quand quelque chose tourne mal.
Regional (DigitalOcean) | Global (xuda Farm) | Un que vous exploitez déjà | |
|---|---|---|---|
| Source de l'image | Une image DigitalOcean préconstruite : create_digitalocean_droplet est appelée avec image_id fixé à digitalocean.datacenter_image_id, 198689047 dans la configuration du dépôt. | Un clone complet d'un modèle Proxmox de référence, vmid 9101, déclaré comme proxmox.templates.datacenter_vmid. Tout autre type éligible à la farm hors VPS clone le modèle de déploiement partagé. Les hôtes sont des machines autonomes sans stockage partagé, si bien qu'un hôte auquel il manque 9101 se le voit transférer par vzdump vers PBS puis qmrestore, via l'API REST. | Aucune. Rien ne démarre. Le déploiement reçoit un config.json portant datacenter_id et un DSN de datacenter, et c'est tout l'attachement. |
| Chemin de sauvegarde | Un instantané de droplet. Le handle conservé sur le document d'app est snapshot_image_id, et une restauration transmet cet id d'image à un nouveau droplet. | Au niveau de l'hyperviseur. vzdump écrit dans le datastore PBS et la tâche aboutit à un identifiant de volume PBS, le handle pour la restauration comme pour la suppression. Une restauration remplace soit le même vmid en place, soit construit une nouvelle VM depuis l'archive. | Ce qui couvre déjà cette machine. Le déploiement attaché conserve ses données dans db_<datacenter_id> sur le datacenter, il est donc protégé exactement dans la même mesure que le datacenter, et pas autrement. |
| Source du prix | Le slug. Chacun des 16 types de serveur est une entrée dans PRICE_OBJ.server_slugs avec cpu, ram, disque fixes et un prix mensuel fixe, à partir de shared_hosting_1 avec 1 vCPU, 2 Go et 50 Go. | compute_farm_price : coeurs multipliés par le tarif cpu du palier, plus la RAM multipliée par le tarif ram, plus le disque multiplié par le tarif disque. Chaque valeur est plafonnée au maximum du palier, le total plancher au minimum du palier, le résultat arrondi aux 10 centimes les plus proches. | Rien de nouveau n'est calculé. L'attachement ne crée aucun serveur, donc ni un prix de slug ni un tarif farm n'en résulte. |
| Refus par manque de capacité | Pas visible pour vous. Aucun calcul de marge ne s'exécute ici, et une création que le fournisseur ne pourra pas satisfaire revient sous forme d'erreur fournisseur plutôt que de code farm. | get_farm_server multiplie vos coeurs, RAM et disque demandés par 1 plus proxmox.headroom_pct sur 100, actuellement 20 pour cent, avant de les comparer à la capacité libre de chaque noeud. Si rien ne passe le test et que proxmox.do_failover est false, la création est refusée avec -462 et n'est pas mise en file d'attente. Une région aux listes vides refuse plus tôt, avec -463. | Il n'y a aucune vérification du tout. Le placement ne s'exécute jamais sur un attachement, donc rien ne vérifie que la machine a de la place pour une base de données supplémentaire avant que le DSN ne soit écrit. |
Trois étapes pour passer de rien à un datacenter avec des déploiements dessus.
Ce n'est pas une action API en libre-service. deploy_datacenter est déclarée avec clearance admin, min_plan pro et private: true, il s'agit donc d'une session dashboard sur un plan Pro ou supérieur, et aucune clé API, quel que soit son mode, n'y accède. C'est l'une des 19 méthodes seulement de la configuration du dépôt à imposer un plancher pro, sur 1010 déclarées.
- 01
Le déclarer
Un nom, une région parmi les 14 codes de métropoles, et un type de serveur parmi les 16 tailles allant de shared_hosting_1 à large_hosting_32. Cela écrit un document d'app avec app_type datacenter et, sur le même document, un mot de passe admin CouchDB de 20 caractères généré à la volée sous couchdb_admin_password. Un seul identifiant est créé ici et tout ce qui suit le partage. L'entrée du catalogue décrit encore cela comme la création d'un droplet DigitalOcean, et la fonction s'appelle toujours create_digitalocean_droplet, même si elle confie d'abord la création à Proxmox. Le nom est obsolète, le comportement ne l'est pas.
- 02
La machine démarre et rappelle
Rien n'interroge la machine. Le service xuda-firstboot.service de la VM appelle la méthode digitalocean_webhook avec son propre id environ dix secondes après la disponibilité du réseau, et le webhook exécute l'installation : 10 étapes nommées, de la connexion au serveur jusqu'au certificat auto-signé et aux fichiers ini, en passant par la création de la base. Avant de rien créer, il interroge le point de terminaison _users de la machine CouchDB 10 fois, à 5 secondes d'intervalle, et abandonne s'il n'obtient jamais de réponse. Il crée ensuite db_<app_id>, exécute la réplication que vous avez configurée, écrit les design docs et les index, et marque enfin le serveur actif.
- 03
Attacher des déploiements par id
Un déploiement placé sur un datacenter reçoit un config.json portant datacenter_id et un DSN de datacenter pointant vers db_<datacenter_id> sur l'adresse privée du datacenter, avec le même identifiant admin généré à l'étape un. C'est là tout le lien : ni agent, ni poignée de main d'enregistrement. Les deux partagent un mot de passe, et un datacenter farm se tient derrière un pare-feu par défaut restrictif avec ipfilter activé : le 443 limité aux plages Cloudflare quand l'app est exposée via Cloudflare, CouchDB sur le 5984 uniquement depuis l'IPSet propre au projet, SSH uniquement depuis l'ensemble xuda_control.
Neuf choses qu'un datacenter ne fait pas, en commençant par celle que tout le monde suppose.
- Rien ici ne monte en charge tout seul. Un noeud qui dépasse proxmox.capacity_alert_pct, fixé à 80, déclenche une alerte dont l'action recommandée est qu'une personne commande une nouvelle machine, et il n'est retiré du placement qu'à 95 pour cent. Avec proxmox.do_failover à false, un déploiement qui ne trouve aucun noeud adapté est refusé avec le code -462. Il n'est pas mis en file d'attente, et rien ne grandit pour l'accueillir.
- Deux des cinq macro-régions sont des libellés sans rien derrière. MACRO_REGIONS attribue à africa et latam une liste farm_locations vide et une liste do_slugs vide, si bien que le placement n'y renvoie aucun noeud et que le chemin de création répond -463, cette région n'est pas disponible pour le déploiement, choisissez-en une autre.
- Il n'existe pas de bascule inter-régions pour votre projet. Un projet est ancré à une région d'origine, et quand cette région est injoignable, un appel sensible à la localisation répond par un simple message indiquant que le travail n'a pas démarré. Il ne s'exécute pas silencieusement ailleurs.
- La réplication n'est pas du failover. Vous choisissez ponctuel ou continu, master ou datacenter, unidirectionnel ou bidirectionnel, et c'est l'intégralité de la fonctionnalité. Rien ne promeut une réplique, ne redirige le trafic, ni ne réconcilie un split brain pour vous.
- Le déploiement est strictement séquentiel, une région à la fois, plafonné à 25 minutes par machine, et une machine en échec est délibérément laissée hors rotation. Elle réintègre la rotation quand le flag de vidage expire après 15 minutes, sur une minuterie, et non selon un verdict indiquant qu'elle a été corrigée.
- La protection de publication est une vérification shell dans les scripts de build, pas un verrou de plateforme. Elle ne fait que rechercher stat 1 ou 2 sur un document regional_server, et XUDA_SKIP_PUBLISH_GUARD=1 la désactive, ce qui est exactement la façon dont un déploiement à moitié terminé se fait dépasser.
- La réconciliation de capacité et le sondage de santé des noeuds s'exécutent volontairement sur une seule machine contrôleuse, car deux balayeurs se feraient concurrence. C'est un seul processus qui décide, toutes les cinq minutes, sur quels noeuds l'ensemble de la farm peut placer.
- Le chemin d'auto-réparation du disque régional, nettoyer tmp puis agrandir le volume puis déclarer la région pleine, est livré mais désactivé : server_capacity_monitor.enabled est à false dans la configuration du dépôt, et son étape d'agrandissement reste de toute façon un appel de volume DigitalOcean.
- Chaque chiffre de cette page a été lu depuis la copie du dépôt de config.json et les sources cpi. La configuration master en production est connue pour diverger de cette copie et n'a pas été lue, considérez donc ces chiffres comme la forme générale du système plutôt que comme les totaux exacts d'aujourd'hui.
Les six questions auxquelles cette page existe pour répondre
Réponses fondées sur le code livré, avec le fichier ou la clé de configuration qui tranche chaque question.
Le dashboard depuis lequel le déploiement démarre.
Il n'existe pas encore d'enregistrement spécifique aux datacenters, il s'agit donc de la présentation générale de la plateforme. Elle montre la surface sur laquelle vous cliquez pour lancer le bouton, pas le chemin de placement et d'installation que décrit cette page.
Choisissez la région en connaissant les règles de capacité.
Un datacenter est un déploiement de plan Pro avec deux décisions réelles : la région, 14 codes de métropoles, et le type de serveur, 16 tailles allant de shared_hosting_1 à large_hosting_32. Décidez d'abord la région, car le placement ne franchit jamais une frontière régionale et rien ne grandit pour s'adapter à vous. africa et latam ne contiennent aucun noeud et répondent -463, et une région dont les noeuds se trouvent dans la marge de 20 pour cent de votre demande répond -462 plutôt que de vous mettre en file d'attente. Une fois le placement effectué, l'installation exécute ses 10 étapes et se termine par la création de db_<app_id> sur la machine, et chaque déploiement que vous y placez partage cet identifiant.