Visión general de despliegue

Ejecutar Zaris se reduce a dos elecciones: qué modelo de despliegue posee los procesos de nodo, y en qué entorno lo ejecutas. Esta página explica los modelos, compara los entornos, y enlaza a una guía paso a paso para cada uno.

nota

Zaris comienza con una prueba automática de 30 días en cada máquina. El uso en producción requiere licencia (por máquina — una máquina, un asiento). Cuando termina la prueba la Consola Web se bloquea primero; tras un periodo de gracia el producto deja de servir hasta que se activa una licencia, y nunca se elimina nada. Consulta Soporte y licencias y la guía de licencias y activación.

Los dos modelos de despliegue

Cada clúster de Zaris tiene un Servicio de Gestión (el plano de control, con la Consola Web) y uno o más nodos (el plano de datos que almacena tus datos). Los modelos difieren solo en quién posee los procesos de nodo.

El manager resuelve su modelo una vez en el arranque a partir de la variable de entorno ZARIS_MGMT_MODE. El valor predeterminado es supervisor.

Modelo supervisor

En el modelo supervisor, el Servicio de Gestión crea y posee los nodos — los bifurca, arranca, detiene, reinicia y escala. Aprovisionas almacenes con los cmdlets de AdminShell o la Consola Web, y el manager genera los procesos de nodo localmente. Este es el modelo para hosts que gestionas directamente, como servicios de Windows y VMs. Es también el hogar natural de los modos de CA 0–2 firmados por Clustron, porque los nodos se inscriben para obtener sus certificados a través del manager.

Este es el predeterminado; establécelo explícitamente con ZARIS_MGMT_MODE=supervisor.

Modelo attach

En el modelo attach, un orquestador externo — Docker, Docker Compose o Kubernetes — ejecuta los procesos de nodo, y el Servicio de Gestión solo los observa mientras sirve el plano de control y la Consola. El manager nunca bifurca un nodo; registras con él el almacén ejecutado externamente (Register-ZrStore, o la API de registro). Como un manager observa todo el clúster, la Consola y la CLI muestran una vista de pertenencia única y coherente. Este es el modelo para despliegues en contenedores y orquestados, y el hogar del modo de CA 3 (hojas pre-emitidas), donde el orquestador monta el certificado de cada nodo.

Selecciónalo con ZARIS_MGMT_MODE=attach. En modo attach el manager se niega a crear o bifurcar almacenes — el orquestador es dueño del ciclo de vida de los nodos.

Los dos modelos se emparejan de forma natural con un entorno y un modo de confianza, pero el modelo es solo un ajuste — no quedas bloqueado.

	Supervisor	Attach
Quién ejecuta los nodos	El Servicio de Gestión	Tu orquestador
Arranque / parada / escalado mediante	Cmdlets de Zaris o la Consola	Tu orquestador
Certificados	Inscritos (Clustron firma)	Montados (tú los emites)
Mejor para	Hosts Windows y VM que gestionas	Docker, Compose y Kubernetes

Los entornos

Elige el entorno que encaje con dónde ejecutas, luego sigue su guía. Los entornos basados en contenedores usan todos la misma imagen de nodo y el modelo attach.

Entorno	Modelo	Qué obtienes	Cuándo usarlo
Instalación en Windows	Supervisor	El Servicio de Gestión y la Consola Web como servicios de Windows, módulos de PowerShell, y el runtime de nodo — desde un solo paquete	Hosts y VMs que gestionas directamente; la ruta más rápida a un clúster en funcionamiento con una Consola
Contenedor Docker	Attach	Un clúster plano, no asegurado, de solo nodos a partir de una imagen y una configuración compartida	Desarrollo local y evaluación; un clúster ligero y reproducible en un solo host Docker
Docker Compose (asegurado)	Attach	Un clúster multinodo asegurado con un manager, TLS mutuo, y autenticación por token	Un clúster asegurado en un host; probar el flujo de certificados montados del modo 3 antes de Kubernetes
Kubernetes	Attach	Un chart de Helm oficial: un StatefulSet con identidad estable, descubrimiento headless, escalado en caliente con kubectl, actualizaciones rolling condicionadas por readiness, un PodDisruptionBudget, clientes fuera del clúster, y TLS mediante Secrets	Orquestar un clúster autorreparable con escalado elástico y actualizaciones rolling seguras a través de un clúster de máquinas

Una nota sobre los puertos

Un almacén en ejecución expone un conjunto pequeño y predecible de puertos, documentado en la página Guía de administración → Puertos:

• API de gestión y Consola Web — el plano de control (predeterminado 7801 y 7810).
• Puerto de cliente de nodo — donde se conectan los clientes del plano de datos (7861 en las imágenes de contenedor).
• Puerto de clúster de nodo — tráfico intra-clúster entre nodos (7811 en las imágenes de contenedor).

Sea cual sea el modelo y el entorno que elijas, los clientes siempre se conectan a los puertos de cliente de nodo, y los administradores usan la API de gestión y la Consola.

Próximos pasos

• Ejecutar en un host Windows → Instalación en Windows.
• Ejecutar un clúster plano en contenedores → Contenedor Docker.
• Ejecutar un clúster asegurado con Compose → Docker Compose (asegurado).
• Orquestar en Kubernetes → Kubernetes.