Un centro de datos es una aplicación suya, sobre hardware que Xuda opera.
La plataforma ya no alquila el panel de control de otra empresa. proxmox.farm_enabled es true en la configuración publicada, 12 tipos de aplicación son elegibles para la granja, y 'datacenter' es el primero de esa lista. Desplegar uno es un único método declarado, deploy_datacenter, y su declaración decide quién puede invocarlo: clearance 'admin', min_plan 'pro', private: true. Esa combinación significa una sesión del panel en un plan Pro o superior, y significa que ninguna clave de API de ningún modo llega hasta él, porque private es el muro. Es uno de solo 19 métodos, de los 1010 de la configuración del repositorio, que llevan algún piso de plan. Usted elige entre 14 códigos de metrópolis y 16 tamaños de servidor, desde shared_hosting_1 hasta large_hosting_32, y lo que recibe es un documento de aplicación con app_type 'datacenter' y una contraseña de administrador de CouchDB de 20 caracteres recién generada, almacenada en el documento como couchdb_admin_password. En la granja, esa VM es un clon completo de su propia plantilla dorada de Proxmox, vmid 9101; cualquier otro tipo elegible para la granja que no sea VPS clona en cambio la imagen de despliegue compartida. Una arruga que conviene decir en voz alta antes del resto de la página: la descripción de catálogo de deploy_datacenter todavía dice que crea un droplet de DigitalOcean, y la función que invoca sigue llamándose create_digitalocean_droplet, aunque esa función entrega la creación a Proxmox antes de siquiera considerar DO. El nombre es más antiguo que el hardware.
Lo que imprime realmente una publicación.
Una publicación es un despliegue progresivo, no una copia de archivos. Selecciona los documentos de xuda_servers con docType 'regional_server', application_server true y stat 1, y luego los recorre de uno en uno, escribiendo stat 2 publicando, 3 hecho o 4 fallido con un stat_ts en cada uno. Cada región se drena antes de tocarla y se niega a drenarse si es la última sana. La parte destructiva se ejecuta separada bajo setsid desde /tmp en el destino, así que termina aunque el orquestador, el broker o la conexión SSH mueran a mitad de camino, y el despliegue consulta entonces un marcador de estado durante hasta 25 minutos mientras sigue el registro remoto de instalación por desplazamiento de bytes. Estas son sus líneas.
Procesos pm2 que una región arranca desde un solo archivo
Estados de publicación por los que pasa el documento de una región
Capacidad libre que un nodo necesita por encima de lo que usted pide
Tope por máquina antes de que un despliegue lo declare agotado por tiempo
Xuda se ejecuta en esta granja igual que lo hace su centro de datos.
Una región de Xuda y un centro de datos de cliente son dos invitados en los mismos hosts de Proxmox, y la forma honesta de describir el producto es ponerlos lado a lado en lugar de describir uno e insinuar el otro. Lea las cuatro filas de un lado a otro: qué llega a la máquina, qué se ejecuta una vez arranca, quién la reconstruye y cómo sale de rotación. Tres de las cuatro filas difieren por completo, y la cuarta es donde la diferencia deja de ser un detalle.
La replicación son cuatro campos y dos documentos, y nada de ello es conmutación por error.
configure_datacenter_replication recibe cuatro cosas: replicate_type, puntual o continua; replicate_from, master o datacenter; replicate_direction, one_way o two_way; y apply, que cuando es false guarda la configuración sin ejecutarla, de modo que reabrir una siembra terminada no copia los datos dos veces. Todo lo que hay más abajo es CouchDB corriente. La plataforma añade la fontanería: crea la base de datos _replicator si el endpoint no tiene ninguna, escribe un documento por dirección, desmonta primero el par anterior y acota lo que cruza mediante un selector. Los puntos dicen qué estado existe después de que usted pulse guardar, porque para uno de los dos modos la respuesta es ninguno.
- Una elección continua se convierte en un documento. replicate_datacenter construye replicate_opt con create_target: false, añade continuous: true y lo guarda en la base de datos _replicator del endpoint elegido, creando antes esa base de datos si falta. Una elección puntual no es un documento en absoluto: invoca replicate_couch_start una vez, la copia se ejecuta y no queda nada en el clúster que la describa. El mismo cuadro de diálogo, dos cantidades muy distintas de estado duradero, en cpi/deploy_module/index.mjs línea 7302.
- La replicación bidireccional son dos trabajos unidireccionales apuntándose el uno al otro. El primer documento lleva el nombre del identificador de la aplicación con _1 añadido, siendo source y target las dos URL más sus bases de datos. El indicador two_way escribe un segundo documento, _2, idéntico salvo que source y target están intercambiados. El desmontaje asume esa forma: delete_prev_replications elimina _1 y _2 de ambos endpoints y limpia replication_stat antes de escribir nada nuevo.
- El selector decide qué cruza, y es tosco a propósito. Replicar desde master fija replicate_opt.selector a un $or sobre docType workspace_drive y docType database, de modo que los metadatos del drive y las filas de las tablas se mueven y el resto del proyecto no. Scope setup y scope custom acotan solo la rama database, añadiendo udfData.udffileid $in una lista de identificadores de tabla leídos de los documentos de tabla del studio.
- Lo que no hace. Nada promueve una réplica, nada redirige el tráfico y nada reconcilia un cerebro dividido más allá de que CouchDB elija una revisión ganadora determinista y conserve la perdedora como conflicto. Y CouchDB replica los DOCUMENTOS del drive, no los archivos: la carpeta workspace_drive en disco se sincroniza por separado con rsync, a través de /tmp para que las dos VM nunca se conecten por SSH entre sí, como una siembra de una sola vez. El temporizador que haría continua esa sincronización de carpeta sigue siendo un TODO en el código fuente.
- Guardar los cuatro camposclearance admin, private, propiedad de app_module. apply: false se detiene aquí y no escribe nada en CouchDB.
- Eliminar el par anterior_1 y _2 eliminados de ambos endpoints, replication_stat limpiado. Un nuevo guardado reemplaza, nunca fusiona.
- Construir replicate_optcreate_target: false siempre, continuous: true solo para la continua, el selector $or solo desde master.
- Escribir, o ejecutar una vezLa continua escribe un documento por dirección. La puntual publica una sola replicación y luego añade un comprobante.
Se ofrecen cinco macrorregiones. Tres de ellas se resuelven en una máquina.
El campo de región contiene 14 códigos de metrópolis, y el selector los agrupa en cinco macrorregiones definidas en MACRO_REGIONS, en cpi/deploy_module/index.mjs línea 9515. Cada entrada contiene dos listas: farm_locations, los sitios de la granja xuda que la región posee, y do_slugs, los prefijos de slug de DigitalOcean que posee. Elegir una región no elige ni un proveedor ni una máquina. Acota el conjunto de candidatos a esas dos listas, y el resto es ubicación.
Regional, Global, o uno que usted ya opera.
La misma llamada a deploy_datacenter produce dos máquinas distintas según un solo campo, app_hosting_preference, y una tercera opción no produce máquina alguna. Estas son rutas de código, no niveles de servicio, y responden de forma distinta a las cuatro preguntas que importan cuando algo sale mal.
Regional (DigitalOcean) | Global (granja xuda) | Uno que usted ya opera | |
|---|---|---|---|
| Origen de la imagen | Una imagen precocinada de DigitalOcean: create_digitalocean_droplet se invoca con image_id fijado a digitalocean.datacenter_image_id, 198689047 en la configuración del repositorio. | Un clon completo de una plantilla dorada de Proxmox, vmid 9101, declarada como proxmox.templates.datacenter_vmid. Cualquier otro tipo elegible para la granja que no sea VPS clona la plantilla de despliegue compartida. Los hosts son máquinas independientes sin almacenamiento compartido, así que a un host al que le falte la 9101 se le traslada con vzdump hacia PBS y luego qmrestore, por la API REST. | Ninguna. No arranca nada. Al despliegue se le escribe un config.json con datacenter_id y un DSN del centro de datos, y eso es todo el enlace. |
| Ruta de copia de seguridad | Una instantánea del droplet. El identificador que se conserva en el documento de la aplicación es snapshot_image_id, y una restauración entrega ese identificador de imagen a un droplet nuevo. | A nivel de hipervisor. vzdump escribe en el almacén de datos de PBS y la tarea se resuelve en un identificador de volumen de PBS, el identificador tanto para restaurar como para eliminar. Una restauración reemplaza el mismo vmid en el sitio o construye una VM nueva a partir del archivo. | Lo que ya cubra esa máquina. El despliegue asociado mantiene sus datos en db_<datacenter_id> en el centro de datos, así que está protegido exactamente cuando lo está el centro de datos y no de otro modo. |
| Origen del precio | El slug. Cada uno de los 16 tipos de servidor es una entrada de PRICE_OBJ.server_slugs con cpu, ram y disco fijos y un precio mensual fijo, empezando en shared_hosting_1 con 1 vCPU, 2 GB y 50 GB. | compute_farm_price: los núcleos por la tarifa de cpu del nivel, más la RAM por la tarifa de ram, más el disco por la tarifa de disco. Cada entrada se limita al máximo del nivel, el total se acota por abajo al mínimo del nivel y el resultado se redondea a los 10 centavos más cercanos. | No se calcula nada nuevo. La asociación no crea servidor alguno, así que no produce ni un precio de slug ni una tarifa de granja. |
| Rechazo por capacidad | No es cosa suya verlo. Aquí no se ejecuta ninguna aritmética de margen, y una creación que el proveedor no vaya a satisfacer vuelve como el error del proveedor y no como un código de la granja. | get_farm_server multiplica sus núcleos, RAM y disco por 1 más proxmox.headroom_pct dividido entre 100, actualmente un 20 por ciento, antes de compararlos con la capacidad libre de cada nodo. Si nada lo supera y proxmox.do_failover es false, la creación se rechaza con -462 y no se pone en cola. Una región con listas vacías rechaza antes, con -463. | No hay comprobación alguna. La ubicación nunca se ejecuta en una asociación, así que nada verifica que la máquina tenga sitio para una base de datos más antes de escribir el DSN. |
Tres movimientos desde cero hasta un centro de datos con despliegues encima.
Esto no es una acción de API de autoservicio. deploy_datacenter se declara con clearance admin, min_plan pro y private: true, así que es una sesión del panel en un plan Pro o superior y ninguna clave de API de ningún modo llega hasta él. Es uno de solo 19 métodos de la configuración del repositorio que llevan un piso Pro, de los 1010 declarados.
- 01
Declararlo
Un nombre, una región de entre los 14 códigos de metrópolis y un tipo de servidor de entre los 16 tamaños, que van de shared_hosting_1 a large_hosting_32. Eso escribe un documento de aplicación con app_type datacenter y, en ese mismo documento, una contraseña de administrador de CouchDB de 20 caracteres recién generada bajo couchdb_admin_password. Aquí se crea una única credencial y todo lo posterior la comparte. La entrada del catálogo todavía describe esto como la creación de un droplet de DigitalOcean, y la función sigue llamándose create_digitalocean_droplet, aunque entrega antes la creación a Proxmox. El nombre está obsoleto, el comportamiento no.
- 02
La máquina arranca y devuelve la llamada
Nada consulta la máquina. El servicio xuda-firstboot.service de la VM invoca con curl el método digitalocean_webhook con su propio identificador unos diez segundos después de que la red esté disponible, y el webhook ejecuta la instalación: 10 pasos con nombre, desde conectar con el servidor pasando por el certificado autofirmado y los archivos ini hasta crear la base de datos. Antes de crear nada, consulta el endpoint _users de CouchDB de la máquina 10 veces, con 5 segundos de separación, y se rinde si nunca responde. Después crea db_<app_id>, ejecuta la replicación que usted configuró, escribe los documentos de diseño y los índices, y solo entonces marca el servidor como activo.
- 03
Asociar despliegues por identificador
A un despliegue ubicado en un centro de datos se le escribe un config.json con datacenter_id y un DSN del centro de datos que apunta a db_<datacenter_id> en la dirección privada del centro de datos, con la misma credencial de administrador emitida en el paso uno. Ese es todo el vínculo: sin agente, sin protocolo de registro. Ambos comparten una contraseña, y un centro de datos de la granja queda detrás de un cortafuegos de denegación por defecto con ipfilter activado: el 443 restringido a los rangos de Cloudflare cuando la aplicación está tras él, CouchDB en el 5984 solo desde el IPSet propio del proyecto, y SSH solo desde el conjunto xuda_control.
Nueve cosas que un centro de datos no hace, empezando por la que todo el mundo da por hecha.
- Aquí nada se escala solo. Un nodo que supera proxmox.capacity_alert_pct, que es 80, genera una alerta cuya acción recomendada es que una persona encargue otra máquina, y solo se retira de la ubicación al 95 por ciento. Con proxmox.do_failover en false, un despliegue que no encuentra un nodo con encaje se rechaza con el código -462. No se pone en cola, y nada crece para acomodarlo.
- Dos de las cinco macrorregiones son etiquetas sin nada detrás. MACRO_REGIONS da a africa y a latam una lista farm_locations vacía y una lista do_slugs vacía, así que la ubicación no devuelve ningún nodo allí y la ruta de creación responde -463, esta región no está disponible para despliegue, elija otra.
- No hay conmutación por error entre regiones para su proyecto. Un proyecto queda anclado a una región de origen, y cuando esa región es inalcanzable una llamada sensible a la ubicación vuelve con un mensaje claro que dice que el trabajo no se inició. No se ejecuta en silencio en otro sitio.
- La replicación no es conmutación por error. Usted elige puntual o continua, master o centro de datos, unidireccional o bidireccional, y eso es toda la función. Nada promueve una réplica, redirige el tráfico ni reconcilia un cerebro dividido por usted.
- El despliegue es estrictamente secuencial, una región cada vez, con un tope de 25 minutos por máquina, y una máquina que falla queda deliberadamente fuera de rotación. Vuelve a entrar cuando el indicador de drenaje caduca a los 15 minutos, por temporizador, no por ningún veredicto sobre si se arregló.
- La protección de publicación es una comprobación de shell dentro de los scripts de compilación, no un bloqueo de la plataforma. Solo busca stat 1 o 2 en un documento regional_server, y XUDA_SKIP_PUBLISH_GUARD=1 la desactiva, que es exactamente como un despliegue a medias acaba siendo adelantado.
- La reconciliación de capacidad y el sondeo de salud de los nodos se ejecutan en una única máquina controladora a propósito, porque dos barredores competirían entre sí. Es decir, un solo proceso decide, cada cinco minutos, en qué nodos puede ubicar toda la granja.
- La ruta regional de autorreparación de disco, limpiar tmp, luego ampliar el volumen y luego declarar la región llena, está publicada y desactivada: server_capacity_monitor.enabled es false en la configuración del repositorio, y su paso de ampliación es de todos modos una llamada de volumen de DigitalOcean.
- Todas las cifras de esta página se leyeron de la copia de config.json del repositorio y de las fuentes de cpi. Se sabe que la configuración del master en vivo se desvía de esa copia y no se consultó, así que tómelas como la forma de la cosa y no como los totales exactos de hoy.
Las seis preguntas que esta página existe para responder
Respondido contra el código publicado, indicando el archivo o la clave de configuración que decide cada caso.
El panel desde el que arranca el despliegue.
Todavía no hay una grabación específica de centros de datos, así que este es el recorrido general de la plataforma. Muestra la superficie desde la que se pulsa el botón, no la ruta de ubicación e instalación que describe esta página.
Elija la región con las reglas de capacidad delante.
Un centro de datos es un despliegue de plan Pro con dos decisiones reales dentro: la región, 14 códigos de metrópolis, y el tipo de servidor, 16 tamaños desde shared_hosting_1 hasta large_hosting_32. Decida primero la región, porque la ubicación nunca cruza de una a otra y nada crece para acomodarle. africa y latam no tienen ningún nodo y responden -463, y una región cuyos nodos quedan dentro del 20 por ciento de margen de su solicitud responde -462 en lugar de ponerle en cola. Una vez que aterriza, la instalación ejecuta sus 10 pasos y termina creando db_<app_id> en la máquina, y cada despliegue que usted ubique allí comparte esa credencial.