Qué es vStack Center

vStack Center es el plano de administración de un clúster de infraestructura hiperconvergente vStack (en adelante, vStack HCP). Los administradores lo usan para crear centros de datos virtuales (VDC), redes y máquinas virtuales (VM), asignar roles y consultar el registro de eventos de seguridad y las métricas. Las VM se ejecutan en el hipervisor de los nodos del clúster. vStack Center mantiene el estado de referencia del clúster y decide qué debe ejecutarse y dónde.

vStack HCP es un producto global con dos partes: vStack Center se encarga de la administración, y vStack OS proporciona el sistema operativo de los nodos, incluidos el hipervisor y la capa de almacenamiento. vStack Center no interactúa directamente con los nodos. Envía una tarea a Cluster Manager, que la entrega a los nodos. Esta separación se refleja en el comportamiento de la API: una operación sobre una VM implica un intercambio entre vStack Center y los agentes de los nodos, y no una única escritura en la base de datos. Los nodos, su instalación, los requisitos de hardware y la CLI de los nodos se describen en la documentación de vStack OS.

Un clúster administrado por vStack Center funciona de forma independiente. Otro producto, GI, agrupa varios clústeres en una federación y les reenvía las solicitudes, pero el clúster no lo percibe: el conjunto de métodos y las reglas de acceso no cambian.

Dos componentes

vStack Center consta de dos servicios. Uno acepta las solicitudes externas; el otro las ejecuta.

Componente	Qué hace	Con qué trabaja
cluster-endpoint	El endpoint HTTPS del clúster. Acepta solicitudes HTTP POST con un cuerpo JSON-RPC 2.0, pone cada solicitud en cola, espera la respuesta y la devuelve al cliente. Mantiene sesiones basadas en cookies. Reenvía las conexiones WebSocket a la consola de la VM	RabbitMQ, el navegador del cliente
dispatcher-cluster	El núcleo de vStack Center. Lee las solicitudes de la cola, comprueba los permisos, lleva el seguimiento de las entidades y de las operaciones asíncronas, y distribuye el trabajo entre los agentes	PostgreSQL, SQLite, InfluxDB, Cluster Manager mediante ZMQ

El cliente solo ve el primer componente: una única dirección HTTPS y un único formato de cuerpo. Todo lo demás queda oculto detrás de la cola.

Recorrido de una solicitud

Cliente → cluster-endpoint (HTTPS) → RabbitMQ → dispatcher-cluster → PostgreSQL / SQLite / InfluxDB
                                                        │ ZMQ
                                                        └→ Cluster Manager → nodos del clúster (AMQP)

Cliente → cluster-endpoint (WSS) → servidor VNC de la VM

El diagrama tiene dos consecuencias prácticas. En primer lugar, cluster-endpoint no almacena el estado de las operaciones de la aplicación, por lo que puede reiniciarse y escalarse por separado del núcleo. En segundo lugar, el tráfico de la consola de la VM no pasa por la cola: viaja por WebSocket, directamente a través del endpoint hasta el servidor VNC de la máquina.

Un único protocolo para todo

vStack Center utiliza únicamente JSON-RPC 2.0: cada operación tiene un nombre, su propio conjunto de argumentos y un formato de respuesta uniforme. La interfaz web sigue el mismo camino que un cliente propio; vStack Center no tiene una interfaz aparte para la interfaz web. Por ello, todo lo que un administrador hace con el ratón también puede hacerse mediante programación. Por este motivo, las páginas de procedimientos de esta documentación enumeran al final los métodos de la API para esas mismas operaciones.

La estructura de la respuesta es la misma para todos los métodos. Una respuesta correcta contiene los datos de la operación concreta: un objeto, un array o un valor único. Una respuesta de error contiene un código numérico. Los códigos se agrupan por método, de modo que el número indica dónde se detuvo la solicitud. Los formatos de solicitud y respuesta se describen en la referencia Descripción general de la API.

Sesión

El dispatcher no obtiene la identidad del llamante a partir del transporte. Identifica al llamante mediante un token de sesión: la interfaz web recibe un token al iniciar sesión y lo presenta en cada operación, y un cliente propio debe hacer lo mismo. El dispatcher rechaza las solicitudes sin token antes de ejecutar la lógica de la aplicación, con el código -9494 ("No session token").

El cambio obligatorio de contraseña sigue un camino distinto. Un usuario con este indicador recibe, en lugar de una sesión normal, un acceso de un solo uso válido durante 5 minutos. Hasta que cambie la contraseña, solo están disponibles el propio cambio de contraseña y la lectura de la política de contraseñas. Por eso la interfaz web muestra de inmediato el formulario de nueva contraseña, y las demás secciones quedan disponibles después del cambio. Los formatos de token y los campos de la respuesta se describen en la referencia Autenticación.

Quién puede ver qué

Los permisos en vStack Center se definen mediante un rol y su ámbito: el clúster o un VDC concreto. Las secciones de los métodos describen el acceso en los mismos términos: "Cluster master: cualquier VM del clúster" y "usuario normal: solo las VM de los VDC en los que tiene roles asignados".

id	Rol	Ámbito
1	Cluster Master	Acceso completo a todo el clúster
2	vDC Admin	Administrador del VDC
3	vDC User	Usuario del VDC
4	vDC Viewer	Observador del VDC
5	Resource Viewer	Consulta de los recursos del clúster
6	Security Admin	Nivel de clúster: registro de seguridad y auditoría
7	VM Developer	Nivel de VDC: creación y configuración de máquinas virtuales

Las operaciones de administración de VDC, es decir, la creación, la modificación y la eliminación, solo están disponibles para Cluster Master. El trabajo dentro de un VDC se delega mediante los roles 2–4 y 7. Los roles 6 y 7 se introdujeron en la versión 3.0.3.

Métodos síncronos y asíncronos

Algunos métodos responden de inmediato porque solo leen o escriben en la base de datos. Por ejemplo, vm-console devuelve los datos de conexión sin contactar con ningún nodo. Otros métodos responden después de que un agente confirme que el trabajo ha finalizado.

vms-create sigue una secuencia larga: validación de parámetros, selección del pool, escritura en la base de datos, traspaso al agente Storage para crear los zvols y, a continuación, traspaso al agente VM para el registro. El cliente recibe la respuesta tras el procesamiento de callbacks en dos fases, y la respuesta contiene una descripción completa de la VM creada. vms-start funciona del mismo modo: el método envía un comando al agente, y la respuesta final llega a través de un callback y contiene data.node_id, el nodo en el que se inició la VM.

La consecuencia práctica es que el cliente debe ser capaz de esperar. Establezca el tiempo de espera de la solicitud en función de la duración de la operación real en el nodo, y no de la velocidad de la base de datos.

Qué debe saber antes de empezar

Una solicitud sin token de sesión no se procesará. Motivo: el dispatcher identifica al llamante únicamente por el token de sesión; las cabeceras del transporte no se usan para ello. Solución: presente el token en cada llamada de la aplicación; de lo contrario, la respuesta contendrá el código -9494.

Algunas operaciones finalizan después de que se devuelve la respuesta. Motivo: el trabajo lo realizan los agentes de los nodos, y el dispatcher solo espera sus callbacks. Solución: tenga en cuenta la respuesta final del método y no la primera, y deje un margen adicional en el tiempo de espera del cliente.

Una imagen de SO que no es visible devuelve "not found" en lugar de "access denied". Motivo: no se revela la existencia de una imagen privada que pertenece a otro VDC. Si intenta seleccionarla, vms-create devuelve -256. Solución: use una imagen compartida en el clúster (is_cluster_shared) o solicite que se conceda visibilidad de la imagen necesaria a su VDC.

Próximos pasos

El recorrido completo desde el inicio de sesión hasta una VM en ejecución se describe en el inicio rápido: creación de un VDC, asignación de una red, creación e inicio de una máquina y conexión a su consola.