> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/learn-the-platform/es/modulo-1-fundamentos-de-arquitectura/05-clusters-nodes.md). # Clústeres y tipos de nodo ## ¿Qué es un clúster? Un **clúster** En VergeOS, un clúster es una agrupación lógica de nodos con las mismas características de hardware, que forma un grupo de recursos presentado como activos utilizables en la interfaz de usuario de VergeOS. Los clústeres permiten una gestión eficiente, escalado y alta disponibilidad para cargas de trabajo virtualizadas. Todo sistema VergeOS comienza con al menos un clúster: los dos nodos controladores iniciales forman el primer clúster durante la instalación. A partir de ahí, puedes añadir nodos al clúster existente o crear clústeres adicionales con distintos roles y perfiles de hardware. ### Por qué importan los clústeres Los clústeres cumplen varios propósitos: * **Aislamiento de cómputo** — Las cargas de trabajo de CPU, memoria y VM están vinculadas a un clúster específico. Las VM solo se ejecutan en nodos dentro de su clúster asignado (con conmutación por error opcional a otro clúster). * **Grupo de almacenamiento compartido** — Los niveles de vSAN abarcan varios clústeres en un único grupo lógico de almacenamiento. Una unidad de almacenamiento en el Clúster 1 y una unidad de almacenamiento en el Clúster 2 pueden contribuir ambas al mismo nivel. Los nodos solo de cómputo acceden a este almacenamiento compartido a través del tejido principal. * **Optimización de hardware** — Diferentes clústeres pueden tener distintos perfiles de hardware: nodos con mucha memoria para bases de datos, nodos equipados con GPU para renderizado, nodos con gran densidad de NVMe para cargas de trabajo intensivas en almacenamiento * **Escalado independiente** — Añade capacidad de cómputo a un clúster sin afectar a los demás; el almacenamiento escala en todo el sistema ## Tipos de clúster VergeOS admite tres tipos de clúster distintos que pueden combinarse dentro de un mismo sistema: | Tipo de clúster | Proporciona | Participación en vSAN | Caso de uso típico | | ----------------------- | ------------------------ | --------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | **Combinado (HCI)** | Cómputo + almacenamiento | Sí — los nodos aportan discos de almacenamiento a los niveles de vSAN | Cargas de trabajo de propósito general, implementaciones pequeñas y medianas | | **Solo almacenamiento** | Solo almacenamiento | Sí — los nodos solo aportan almacenamiento | Expansión de almacenamiento dedicada en arquitecturas UCI | | **Solo cómputo** | Solo cómputo | No — solo arranque o arranque PXE | Cargas de trabajo de alto cómputo (ML, renderizado, análisis de datos) | **Ejemplos comunes de implementación:** ```mermaid graph TB subgraph hci["HCI (Clúster único)"] N1["Controlador 1
Cómputo + almacenamiento"] N2["Controlador 2
Cómputo + almacenamiento"] N3["Escalado horizontal
Cómputo + almacenamiento"] end subgraph hybrid["Híbrido (2 clústeres)"] H1["Controlador 1
Almacenamiento + administración"] H2["Controlador 2
Almacenamiento + administración"] HC1["Nodo de cómputo 1"] HC2["Nodo de cómputo 2"] end subgraph uci["UCI (3 clústeres)"] U1["Controlador 1
Administración"] U2["Controlador 2
Administración"] US1["Nodo de almacenamiento 1"] US2["Nodo de almacenamiento 2"] UC1["Nodo de cómputo 1"] UC2["Nodo de cómputo 2"] end style N1 fill:#e3f2fd,stroke:#1565c0 style N2 fill:#e3f2fd,stroke:#1565c0 style N3 fill:#e3f2fd,stroke:#1565c0 style H1 fill:#e3f2fd,stroke:#1565c0 style H2 fill:#e3f2fd,stroke:#1565c0 style HC1 fill:#fff3e0,stroke:#e65100 style HC2 fill:#fff3e0,stroke:#e65100 style U1 fill:#e3f2fd,stroke:#1565c0 style U2 fill:#e3f2fd,stroke:#1565c0 style US1 fill:#e8f5e9,stroke:#2e7d32 style US2 fill:#e8f5e9,stroke:#2e7d32 style UC1 fill:#fff3e0,stroke:#e65100 style UC2 fill:#fff3e0,stroke:#e65100 ``` ## Tipos de nodo Todo servidor físico en un sistema VergeOS es un **nodo**Los nodos difieren en cómo se unen al sistema, qué función desempeñan y a qué clúster pertenecen. VergeOS define cuatro tipos de nodo: ### Nodos controladores Todo sistema VergeOS comienza con al menos dos **nodos controladores**. Se requiere un tercer nodo controlador para la redundancia N+2. Son especiales porque: * **Nodo 1** crea un sistema VergeOS nuevo desde cero. Inicializa vSAN, crea el primer clúster y ejecuta la configuración posterior a la instalación (configuración de red, creación de clústeres para tipos de nodo adicionales, etc.) * **Nodo 2** se une al sistema creado por el Nodo 1 como segundo controlador, proporcionando redundancia para todas las funciones de administración del sistema (N+1) * **Nodo 3 (opcional)** — se puede añadir un tercer nodo controlador para la redundancia N+2, lo que permite que el sistema tolere dos fallos simultáneos de nodo Los nodos controladores siempre pertenecen a **Clúster 1**. En una topología HCI, proporcionan tanto cómputo como almacenamiento. En una topología híbrida, normalmente proporcionan **solo almacenamiento y administración** — sin VM de producción — mientras que un clúster de cómputo separado se encarga de todas las cargas de trabajo. En una topología UCI completa, administran el sistema pero delegan el almacenamiento y el cómputo a clústeres dedicados. El primer clúster debe incluir al menos dos nodos con **almacenamiento de Tier 0** (unidades de metadatos) — este es un requisito estricto porque Tier 0 contiene el índice del sistema de archivos de vSAN y debe ser redundante. ### Nodos de escalado horizontal Los nodos de escalado horizontal amplían un clúster HCI existente añadiendo más capacidad de cómputo y almacenamiento. Características clave: * **Hardware idéntico** al de los nodos controladores del clúster al que se unen (misma generación de CPU, diseño de almacenamiento similar, configuración de NIC coincidente) * Instálalo mediante USB y selecciona el tipo de nodo de escalado horizontal. El instalador detecta automáticamente el tejido principal y, después, el operador se autentica con credenciales de administrador. Si existen varios clústeres, el operador también selecciona el clúster de destino y un nodo de referencia contra el que comparar el hardware * Los discos se incorporan automáticamente a los niveles de vSAN existentes * Aportan tanto cómputo (ejecutan VM) como almacenamiento (participación en vSAN) Los nodos de escalado horizontal son la forma más sencilla de hacer crecer una implementación HCI — añade un nodo y la capacidad de cómputo y almacenamiento del clúster aumenta proporcionalmente. ### Nodos solo de almacenamiento Los nodos solo de almacenamiento se dedican exclusivamente a ampliar la capacidad de vSAN. Ellos: * Aportan discos a los niveles de vSAN pero no **no** ejecutan cargas de trabajo de VM * Pertenecen a un **clúster solo de almacenamiento** (p. ej., Clúster 2) * Requieren crear el clúster de almacenamiento en la interfaz de usuario de VergeOS antes de añadir el primer nodo de almacenamiento * Se usan en arquitecturas UCI donde el almacenamiento y el cómputo escalan de forma independiente ### Nodos solo de cómputo Los nodos solo de cómputo proporcionan capacidad de procesamiento sin participar en el almacenamiento vSAN. Ellos: * Ejecutan cargas de trabajo de VM pero no tienen **almacenamiento local de vSAN** (disco solo de arranque o arranque PXE) * Pertenecen a un **clúster solo de cómputo** (p. ej., Clúster 3) * Requieren crear el clúster de cómputo en la interfaz de usuario de VergeOS antes de añadir el primer nodo de cómputo * Acceden al almacenamiento a través del tejido principal desde nodos en clústeres HCI o solo de almacenamiento Los nodos solo de cómputo son ideales para cargas de trabajo que necesitan alta densidad de CPU/RAM/GPU sin un crecimiento proporcional del almacenamiento: aprendizaje automático, renderizado, análisis de datos o VDI. ### Resumen de tipos de nodo | Tipo de nodo | Rol | Clúster | vSAN | Ejecuta VM | Método de unión | | ------------------------ | ------------------------------------ | ---------- | ----------------------------------------- | ------------------- | --------------------------------------------- | | **Controlador (Nodo 1)** | Crea un sistema nuevo | Clúster 1 | Sí (Tier 0 + niveles de carga de trabajo) | Sí (HCI) o No (UCI) | Creación de nuevo sistema | | **Controlador (Nodo 2)** | Se une como controlador redundante | Clúster 1 | Sí (Tier 0 + niveles de carga de trabajo) | Sí (HCI) o No (UCI) | Se une al Clúster 1 | | **Escalado horizontal** | Añade capacidad HCI | Clúster 1 | Sí (niveles de carga de trabajo) | Sí | Detección automática en el tejido principal | | **Solo almacenamiento** | Expansión de almacenamiento dedicada | Clúster 2+ | Sí (niveles de carga de trabajo) | No | Se une al clúster de almacenamiento designado | | **Solo cómputo** | Expansión de cómputo dedicada | Clúster 2+ | No (solo arranque / PXE) | Sí | Se une al clúster de cómputo designado | {% hint style="info" %} **¿Vienes de VMware o Nutanix?** Ninguna de las dos plataformas tiene un concepto nativo de miembros solo de almacenamiento o solo de cómputo dentro de un único clúster. VergeOS sí lo tiene, y te permite clasificar los clústeres para un escalado independiente. Los clústeres de VMware y Nutanix son uniformes; los clústeres de VergeOS pueden ser HCI, solo de almacenamiento o solo de cómputo, y un sistema puede mezclar varios clústeres tipificados. {% endhint %} | Rol de nodo de VergeOS | Análogo más cercano en VMware vSphere | Análogo más cercano en Nutanix | | ---------------------- | ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | Controlador | Host ESXi + servicios de vCenter (sin dispositivo separado) | Primer nodo de un clúster; los controladores de VergeOS se ejecutan sobre metal desnudo, no en una CVM | | Escalado horizontal | Host ESXi adicional que se une a un clúster vSAN | Nodo adicional que se une a un clúster Nutanix | | Solo almacenamiento | Sin equivalente nativo (el witness de vSAN es lo más cercano) | Sin equivalente — cada nodo de Nutanix ejecuta una CVM y participa en el cómputo | | Solo cómputo | Host ESXi sin vSAN local, que monta almacenamiento externo (aquí, vSAN sobre el tejido principal) | Sin equivalente directo | ## Cómo se unen los nodos a un sistema El proceso de unión de nodos sigue una secuencia estricta para evitar condiciones de carrera: ```mermaid flowchart TD A["Nodo 1 (Controlador)
Crea un nuevo sistema VergeOS
Inicializa vSAN, crea el Clúster 1"] --> B["Nodo 2 (Controlador)
Se une al Clúster 1
Establece un par de alta disponibilidad"] B --> C{"¿Nodos adicionales?"} C -->|"Escalado horizontal"| D["Nodos de escalado horizontal
Detectan automáticamente el sistema en el tejido principal
Se unen secuencialmente al Clúster 1"] C -->|"Solo almacenamiento"| E["Crear clúster de almacenamiento
(Clúster 2 en la interfaz de usuario)"] C -->|"Solo cómputo"| F["Crear clúster de cómputo
(Clúster 2 o 3 en la interfaz de usuario)"] E --> G["Nodos de almacenamiento
Se unen secuencialmente al clúster de almacenamiento"] F --> H["Nodos de cómputo
Se unen secuencialmente al clúster de cómputo"] G --> F style A fill:#e3f2fd,stroke:#1565c0 style B fill:#e3f2fd,stroke:#1565c0 style D fill:#e3f2fd,stroke:#1565c0 style G fill:#e8f5e9,stroke:#2e7d32 style H fill:#fff3e0,stroke:#e65100 ``` Reglas clave para la unión de nodos: 1. **El Nodo 1 debe completar la instalación** antes de que el Nodo 2 pueda unirse — el Nodo 2 necesita un sistema existente al que conectarse 2. **Los nodos se unen secuencialmente** dentro de un clúster — el Nodo 3 después del Nodo 2, el Nodo 4 después del Nodo 3, etc. — para evitar condiciones de carrera durante los cambios de pertenencia al clúster 3. **Los clústeres de almacenamiento deben existir** antes de que los nodos de almacenamiento puedan unirse — crea primero el clúster en la interfaz de usuario de VergeOS 4. **Los clústeres de cómputo deben existir** antes de que los nodos de cómputo puedan unirse — mismo requisito previo 5. **Si se implementan tanto clústeres de almacenamiento como de cómputo**, los nodos de almacenamiento deben añadirse primero para que los nodos de cómputo puedan acceder inmediatamente al almacenamiento vSAN ## Numeración y nomenclatura de clústeres Los clústeres se numeran comenzando desde 1, pero el **nombre es libre** — puedes llamar a un clúster como quieras y renombrarlo en cualquier momento en la interfaz de usuario de VergeOS. Los nombres de abajo son solo convenciones comunes, no valores obligatorios: | Número de clúster | Rol predeterminado | Nombre típico | | ----------------- | -------------------------------------------------------- | ----------------------------------------- | | Clúster 1 | HCI (controladores + escalado horizontal opcional) | "HCI", "Predeterminado" o "Controladores" | | Clúster 2 | Solo almacenamiento (si UCI) o solo cómputo (si híbrido) | "Almacenamiento" o "Cómputo" | | Clúster 3 | Solo cómputo (en UCI completa con 3 clústeres) | "Cómputo" | En una implementación UCI completa con 3 clústeres: * **Clúster 1**: Controladores (administración del sistema, metadatos de Tier 0) * **Clúster 2**: Nodos de almacenamiento (todo el almacenamiento de carga de trabajo vSAN) * **Clúster 3**: Nodos de cómputo (toda la ejecución de VM) ## Requisitos mínimos y alta disponibilidad | Requisito | Detalle | | ----------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Nodos mínimos por sistema** | 2 (un par de controladores) | | **Nodos mínimos por clúster** | 2 (para redundancia durante mantenimiento o fallo) | | **Nodos controladores** | Mínimo 2 por sistema (N+1 por defecto); se requieren 3 para redundancia N+2 — deben tener almacenamiento Tier 0 para los metadatos de vSAN | | **Comportamiento de alta disponibilidad** | Si un nodo falla, sus cargas de trabajo migran al o los nodos supervivientes en el mismo clúster | | **Modo de mantenimiento** | Los nodos pueden ponerse en modo de mantenimiento; las cargas de trabajo se migran en vivo a otros nodos del clúster antes de que comience el mantenimiento | ## Escalado Los sistemas VergeOS escalan desde un clúster HCI mínimo de 2 nodos hasta implementaciones de varios clústeres. Todos los nodos deben compartir el **mismo tejido de conmutación** con **cero saltos de switch** entre ellos (objetivo de latencia inferior a 0,05 ms). Un solo rack es la forma más sencilla de cumplir este requisito. Las implementaciones de varios racks son posibles, pero cada tejido principal debe seguir terminando en un único switch: usa cables más largos de vuelta al mismo par de switches del tejido en lugar de extender el tejido entre switches (MLAG/stacking es para la red externa, no para el tejido principal). La estrategia de escalado depende de tu arquitectura: ### Escalado HCI (simple) Añade nodos de escalado horizontal al Clúster 1. Cada nodo añade proporcionalmente cómputo y almacenamiento. ```mermaid graph LR subgraph "Inicio: HCI de 2 nodos" A1["Nodo 1"] --- A2["Nodo 2"] end subgraph "Crecimiento: HCI de 4 nodos" B1["Nodo 1"] --- B2["Nodo 2"] B3["Nodo 3"] --- B4["Nodo 4"] B1 --- B3 B2 --- B4 end subgraph "Escalado: HCI de 8+ nodos" C1["Nodo 1-2
(Controladores)"] C2["Nodo 3-8
(Escalado horizontal)"] end ``` **Ideal para**: Crecimiento equilibrado en el que las necesidades de cómputo y almacenamiento aumentan juntas. ### Escalado UCI (independiente) Añade nodos a clústeres específicos según qué recurso sea el cuello de botella: * **¿Necesitas más almacenamiento?** Añade nodos al clúster de almacenamiento * **¿Necesitas más cómputo?** Añade nodos al clúster de cómputo * **¿Necesitas más de ambos?** Añade a ambos clústeres de forma independiente **Ideal para**: Cargas de trabajo con demandas de recursos desequilibradas (p. ej., mucho almacenamiento con poco cómputo, o cómputo denso en GPU con almacenamiento modesto). ### Buenas prácticas para el escalado * **Consistencia de hardware dentro de los clústeres** — Usa las mismas especificaciones de hardware para todos los nodos de un clúster. Mezclar hardware diferente dentro de un clúster puede causar problemas de rendimiento y fiabilidad. * **Planifica la redundancia N+1** — Dimensiona cada clúster para que, al perder un nodo, siga habiendo capacidad suficiente para todas las cargas de trabajo * **Supervisa antes de escalar** — Usa las métricas del panel de VergeOS (utilización de CPU, uso de RAM, capacidad de vSAN) para identificar qué recurso necesita expansión * **Escala sin tiempo de inactividad** — Se pueden añadir nodos a un sistema en ejecución sin interrumpir las cargas de trabajo existentes ## Ejemplos de topologías de implementación Topologías comunes que se ajustan a patrones de implementación del mundo real: | Topología | Nodos | Clústeres | Cuándo usar | | ----------------------------- | --------------------------------------------------------------- | ------------------------------------------------ | ------------------------------------------------------------------------- | | **HCI de 2 nodos** | 2 controladores | 1 (HCI) | Sitios pequeños, edge, PoC, evaluación básica | | **HCI + escalado horizontal** | 2 controladores + N de escalado horizontal | 1 (HCI) | Implementaciones HCI en crecimiento que necesitan un escalado equilibrado | | **Híbrido (2 clústeres)** | 2 controladores + N de cómputo | 2 (Almacenamiento + Cómputo) | Cargas de trabajo intensivas en cómputo con almacenamiento modesto | | **UCI (3 clústeres)** | 2 controladores + N de almacenamiento + M de cómputo | 3 (Controlador + Almacenamiento + Cómputo) | Escalado independiente de cómputo y almacenamiento | | **UCI + GPU (4 clústeres)** | 2 controladores + N de almacenamiento + M de cómputo + G de GPU | 4 (Controlador + Almacenamiento + Cómputo + GPU) | IA/ML, renderizado o VDI con nodos GPU dedicados | ```mermaid graph TB subgraph "HCI de 2 nodos" direction LR H1["Controlador 1
HCI"] --- H2["Controlador 2
HCI"] end subgraph "HCI + escalado horizontal" direction LR S1["Controlador 1"] --- S2["Controlador 2"] S3["Escalado horizontal 1"] --- S4["Escalado horizontal 2"] end subgraph "Híbrido (2 clústeres)" direction LR subgraph "Clúster 1 (Almacenamiento)" Y1["Controlador 1"] Y2["Controlador 2"] end subgraph "Clúster 2 (Cómputo)" Y3["Cómputo 1"] Y4["Cómputo 2"] end end subgraph "UCI + GPU (4 clústeres)" direction LR subgraph "Clúster 1 (Ctrl)" U1["Ctrl 1"] U2["Ctrl 2"] end subgraph "Clúster 2 (Almacenamiento)" U3["Almacenamiento 1"] U4["Almacenamiento 2"] end subgraph "Clúster 3 (Cómputo)" U5["Cómputo 1"] U6["Cómputo 2"] end subgraph "Clúster 4 (GPU)" G1["Nodo GPU 1"] G2["Nodo GPU 2"] end end ``` ## Puntos clave | Concepto | Resumen | | ---------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | **Clúster** | Agrupación lógica de nodos con el mismo hardware, formando un grupo de recursos | | **Tres tipos de clúster** | HCI (cómputo + almacenamiento), solo almacenamiento, solo cómputo — combinables dentro de un mismo sistema | | **Cuatro tipos de nodos** | Controlador, escalado horizontal, solo almacenamiento, solo cómputo — cada uno con un rol y un método de unión específicos | | **Mínimo 2 nodos** | Por clúster para redundancia; los controladores requieren almacenamiento de nivel 0 | | **Unión secuencial** | Los nodos se unen uno a la vez para evitar condiciones de carrera | | **Consistencia de hardware** | Todos los nodos de un clúster deben tener especificaciones de hardware coincidentes | | **Escalado independiente** | La arquitectura UCI permite agregar capacidad de cómputo o almacenamiento de forma independiente | | **Escalado** | Los sistemas escalan desde HCI de 2 nodos hasta implementaciones multiclúster dentro de un único plano de conmutación | ## Siguientes pasos Ahora entiendes cómo VergeOS organiza los nodos en clústeres y cómo los distintos tipos de nodos cumplen funciones diferentes. En el laboratorio práctico, explorarás estos conceptos usando el entorno de prueba de Terraform: [**Laboratorio: Exploración de la arquitectura →**](/learn-the-platform/es/modulo-1-fundamentos-de-arquitectura/lab.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.verge.io/learn-the-platform/es/modulo-1-fundamentos-de-arquitectura/05-clusters-nodes.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.