> 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-2-dimensionamiento-y-diseno/02-reference-architectures.md).

# Arquitecturas de referencia

VergeOS admite tres arquitecturas de implementación a partir de la misma instalación de software. Elegir la adecuada depende del número de nodos, el patrón de crecimiento y los requisitos de especialización de la carga de trabajo. Esta página recorre cada modelo, proporciona un marco de decisión y cubre dos escenarios comunes del mundo real: implementaciones en el borde y entornos multiinquilino de proveedores de servicios en la nube (CSP).

## Árbol de decisión de arquitectura

Utilice el siguiente marco para orientar su recomendación. Los rangos de conteo de nodos a continuación son reglas generales aproximadas: HCI encaja en implementaciones más pequeñas (normalmente de 2 a 12 nodos) y UCI aplica cuando el crecimiento de cómputo y almacenamiento diverge o se necesita hardware especializado.

```mermaid
flowchart TD
    A["¿Cuántos nodos<br/>tendrá la implementación?"] --> B{"2 -- 6 nodos"}
    A --> C{"6 -- 10 nodos"}
    A --> D{"10+ nodos"}

    B --> E{"¿El cómputo y el almacenamiento<br/>crecerán proporcionalmente?"}
    E -->|"Sí"| F["HCI"]
    E -->|"No -- el cómputo crece más rápido"| G["HCI + Cómputo Dedicado<br/>(UCI híbrido de 2 clústeres)"]
    E -->|"Incierto"| H{"¿Se necesita hardware<br/>especializado? (GPU, alta memoria)"}

    C --> H
    D --> I["UCI (Canonical de 3 clústeres)"]

    H -->|"Sí"| I
    H -->|"No"| G
    H -->|"Quizá en el futuro"| G

    style F fill:#e8f5e9,stroke:#2e7d32
    style G fill:#fff3e0,stroke:#e65100
    style I fill:#f0f4ff,stroke:#336
```

**Reglas rápidas de referencia:**

1. **Empiece con HCI** a menos que tenga una razón específica para no hacerlo.
2. **Considere HCI + Cómputo** cuando la demanda de cómputo supere el crecimiento del almacenamiento (6--10 nodos).
3. **Elija UCI** para entornos de 10+ nodos, hardware especializado o máxima aislamiento del rendimiento.
4. Puede **evolucionar** de HCI a HCI + Cómputo a UCI a medida que el entorno crece: la misma instalación de VergeOS admite los tres.

***

## Modelo 1: HCI (infraestructura hiperconvergente)

**Rango de nodos:** 2--6 nodos | **Clústeres:** 1

En una implementación HCI cada nodo aporta **tanto** cómputo como almacenamiento. Los dos nodos controladores llevan almacenamiento de Nivel 0 (metadatos de vSAN) y de Nivel 1 (carga de trabajo), y ejecutan VMs. Los nodos de expansión añaden almacenamiento de Nivel 1 y capacidad de cómputo al mismo clúster.

```mermaid
graph TB
    subgraph cluster1["Clúster 1 -- HCI"]
        N1["Nodo 1 -- Controlador<br/>Nivel 0 + Nivel 1<br/>Almacenamiento + Cómputo"]
        N2["Nodo 2 -- Controlador<br/>Nivel 0 + Nivel 1<br/>Almacenamiento + Cómputo"]
        S1["Nodo 3 -- Expansión<br/>Nivel 1<br/>Almacenamiento + Cómputo"]
        S2["Nodo 4 -- Expansión<br/>Nivel 1<br/>Almacenamiento + Cómputo"]
    end
    subgraph fabric["Red troncal"]
        CF["Núcleo 1 + Núcleo 2"]
    end
    N1 --- CF
    N2 --- CF
    S1 --- CF
    S2 --- CF

    style cluster1 fill:#e8f5e9,stroke:#2e7d32
    style fabric fill:#f0f4ff,stroke:#336
```

### Ventajas

* **Simplicidad operativa** -- un solo clúster, una sola especificación de hardware, gestión unificada.
* **Escalado predecible** -- cada nodo añade tanto almacenamiento como cómputo de forma proporcional.
* **Punto de entrada más bajo** -- un clúster de 2 nodos es la implementación más pequeña posible de VergeOS.
* **Una sola especificación de hardware** simplifica las compras y el inventario de repuestos.

### Limitaciones

* No puede escalar cómputo de forma independiente del almacenamiento (o viceversa).
* Especialización de hardware limitada: todos los nodos comparten la misma función.
* Máximo recomendado de aproximadamente 6 nodos antes de considerar un segundo clúster.
* Posible contención de recursos en los nodos controladores que ejecutan tanto operaciones de metadatos como cargas de trabajo de VM.

### Casos de uso ideales

| Escenario                                       | Por qué HCI funciona                                                    |
| ----------------------------------------------- | ----------------------------------------------------------------------- |
| Implementaciones pequeñas/medianas (2--6 nodos) | Complejidad mínima, cada nodo cumple una doble función                  |
| Cargas de trabajo equilibradas                  | El almacenamiento y el cómputo crecen aproximadamente al mismo ritmo    |
| Sitios perimetrales/remotos                     | Clústeres de 2 nodos con alta disponibilidad completa y huella reducida |
| Evaluación y pruebas                            | El camino más rápido hacia un sistema VergeOS operativo                 |

***

## Modelo 2: HCI + Cómputo Dedicado (UCI híbrido de 2 clústeres)

**Rango de nodos:** 6--10 nodos | **Clústeres:** 2

Esta es la variante híbrida de 2 clústeres de UCI: los roles de controlador y almacenamiento permanecen fusionados en un clúster HCI, mientras que el cómputo se separa en su propio clúster. El clúster HCI (Clúster 1) proporciona todo el almacenamiento a través de sus controladores y nodos opcionales de expansión. El clúster de cómputo (Clúster 2) ejecuta cargas de trabajo de VM sin aportar discos.

```mermaid
graph TB
    subgraph cluster1["Clúster 1 -- HCI (Almacenamiento + Cómputo)"]
        N1["Nodo 1 -- Controlador<br/>Nivel 0 + Nivel 1"]
        N2["Nodo 2 -- Controlador<br/>Nivel 0 + Nivel 1"]
        S1["Nodo 3 -- HCI<br/>Nivel 1 (opcional)"]
    end
    subgraph cluster2["Clúster 2 -- Solo Cómputo"]
        C1["Nodo 4 -- Cómputo"]
        C2["Nodo 5 -- Cómputo"]
        C3["Nodo 6 -- Cómputo"]
        C4["Nodo 7+ -- Escala"]
    end
    subgraph fabric["Red troncal"]
        CF["Núcleo 1 + Núcleo 2"]
    end
    N1 --- CF
    N2 --- CF
    S1 --- CF
    C1 --- CF
    C2 --- CF
    C3 --- CF
    C4 --- CF

    style cluster1 fill:#fff3e0,stroke:#e65100
    style cluster2 fill:#e3f2fd,stroke:#1565c0
    style fabric fill:#f0f4ff,stroke:#336
```

### Principios clave de diseño

### Clúster 1 -- HCI (combinado)

* Siempre incluye los Nodos 1 y 2 con almacenamiento de Nivel 0 (controladores). - Puede incluir nodos adicionales de expansión HCI para más almacenamiento y cómputo. - Un conmutador a nivel de clúster controla si este clúster también ejecuta cargas de trabajo de VM. - Todos los niveles de almacenamiento existen en este clúster.

### Clúster 2 -- Solo Cómputo

* Cómputo puro: máximo CPU y RAM disponibles para las VMs. - Escala de forma independiente en función de la demanda de cómputo. - Admite hardware flexible y optimizado para la carga de trabajo (nodos GPU, nodos de gran memoria). - La E/S de almacenamiento desde los nodos de cómputo atraviesa la red troncal hacia el Clúster 1.

### Ventajas

* Escalado de cómputo independiente sin comprar almacenamiento no deseado.
* Mantiene la simplicidad operativa de HCI para la capa de almacenamiento.
* Rentable: escale solo el nivel de recursos que está creciendo.
* Camino claro de crecimiento hacia la UCI canónica de 3 clústeres si las necesidades evolucionan más.

### Limitaciones

* La E/S de almacenamiento desde los nodos de cómputo cruza la red (es esencial un ancho de banda adecuado de la red troncal).
* Más complejo que el HCI puro (dos clústeres que gestionar en lugar de uno).
* Requiere decidir si el clúster HCI también debe ejecutar cargas de trabajo.

### Casos de uso ideales

| Escenario                                               | Por qué funciona HCI + Cómputo                       |
| ------------------------------------------------------- | ---------------------------------------------------- |
| Implementaciones de 6--10 nodos                         | Punto ideal para el modelo de dos clústeres          |
| El crecimiento del cómputo supera al del almacenamiento | Añada CPU/RAM sin ampliar los discos                 |
| GPU o cómputo especializado                             | Clúster de cómputo dedicado con hardware passthrough |
| Optimización de costes                                  | Escale solo lo que necesita                          |

***

## Modelo 3: UCI (infraestructura ultra convergente) -- Canonical de 3 clústeres

**Rango de nodos:** 10+ nodos | **Clústeres:** 3+

La UCI canónica de 3 clústeres separa por completo controladores, almacenamiento y cómputo en clústeres dedicados. Cada nivel de recursos escala de forma independiente y usa hardware optimizado para su función. (UCI es un término paraguas para cualquier implementación con escalado independiente; el Modelo 2 anterior es su variante híbrida de 2 clústeres.)

```mermaid
graph TB
    subgraph cluster1["Clúster 1 -- Controladores Dedicados"]
        N1["Nodo 1 -- Controlador<br/>Solo Nivel 0 | Alta Memoria"]
        N2["Nodo 2 -- Controlador<br/>Solo Nivel 0 | Alta Memoria"]
    end
    subgraph cluster2["Clúster 2 -- Almacenamiento Dedicado"]
        ST1["Nodo 3 -- Almacenamiento<br/>NVMe Denso | Nivel 1"]
        ST2["Nodo 4 -- Almacenamiento<br/>NVMe Denso | Nivel 1"]
        ST3["Nodo 5 -- Almacenamiento<br/>NVMe Denso | Nivel 1"]
    end
    subgraph cluster3["Clústeres 3+ -- Cómputo Especializado"]
        C1["Cómputo Estándar"]
        C2["Cómputo GPU"]
        C3["Alta Memoria"]
    end
    subgraph fabric["Red troncal"]
        CF["Núcleo 1 + Núcleo 2"]
    end
    N1 --- CF
    N2 --- CF
    ST1 --- CF
    ST2 --- CF
    ST3 --- CF
    C1 --- CF
    C2 --- CF
    C3 --- CF

    style cluster1 fill:#f3e5f5,stroke:#6a1b9a
    style cluster2 fill:#e8f5e9,stroke:#2e7d32
    style cluster3 fill:#e3f2fd,stroke:#1565c0
    style fabric fill:#f0f4ff,stroke:#336
```

### Especialización de clústeres

| Clúster                         | Función                                                | Optimizado para                                                                               |
| ------------------------------- | ------------------------------------------------------ | --------------------------------------------------------------------------------------------- |
| **Clúster 1 -- Controladores**  | Metadatos de Nivel 0, gestión del clúster              | Alta memoria (p. ej., 768 GB en el RA de Data-Science), NVMe de alta resistencia para Nivel 0 |
| **Clúster 2 -- Almacenamiento** | Todo el almacenamiento de cargas de trabajo (Nivel 1+) | Máxima densidad de discos, SSD NVMe o SAS/SATA                                                |
| **Clústeres 3+ -- Cómputo**     | Cargas de trabajo de VM, hardware especializado        | Tipos de nodos estándar, GPU, alta memoria o personalizados                                   |

### Ventajas

* **Máximo rendimiento** -- no hay contención de recursos entre almacenamiento y cómputo.
* **Escalado independiente completo** -- añada almacenamiento sin cómputo (o viceversa).
* **Especialización de hardware** -- ajuste el hardware según la función (NVMe denso para almacenamiento, GPU para cómputo).
* **Aislamiento de cargas de trabajo** -- diferentes clústeres de cómputo para distintos tipos de carga de trabajo.
* **Óptimo para entornos a gran escala y multiinquilino.**

### Limitaciones

* La mayor complejidad operativa de las tres arquitecturas.
* Mínimo de 6 nodos (derivado del mínimo de 2 nodos por clúster × 3 clústeres: 2 controladores + 2 almacenamiento + 2 cómputo).
* Planificación de capacidad más compleja entre tres tipos de clúster.
* Mayores requisitos de ancho de banda de la red troncal entre clústeres.
* Se recomiendan servicios profesionales para la implementación inicial.

### Casos de uso ideales

| Escenario                                         | Por qué funciona UCI                                                |
| ------------------------------------------------- | ------------------------------------------------------------------- |
| Implementaciones empresariales de 10+ nodos       | El escalado independiente evita el sobreaprovisionamiento           |
| Cargas de trabajo de IA / HPC / GPU               | Clústeres de cómputo GPU dedicados, separados del almacenamiento    |
| Proveedores de servicios en la nube               | Optimice el gasto en hardware por nivel de recurso entre inquilinos |
| Crecimiento intensivo en almacenamiento o cómputo | Escale solo lo que está creciendo                                   |

***

## Comparación de arquitecturas

| Aspecto                      | HCI                  | HCI + Cómputo (UCI híbrido de 2 clústeres) | UCI (Canonical de 3 clústeres)                  |
| ---------------------------- | -------------------- | ------------------------------------------ | ----------------------------------------------- |
| **Nodos mínimos**            | 2                    | 4 (2 HCI + 2 de cómputo)                   | 6 (2+2+2)                                       |
| **Cantidad de clústeres**    | 1                    | 2                                          | 3+                                              |
| **Rendimiento**              | Bueno                | Mejor                                      | Óptimo                                          |
| **Flexibilidad de hardware** | Baja                 | Media                                      | Máxima                                          |
| **Escalado independiente**   | No                   | Parcial (solo cómputo)                     | Completo                                        |
| **Especialización**          | Ninguna              | Solo cómputo                               | Completa (controlador, almacenamiento, cómputo) |
| **Complejidad**              | Baja                 | Media                                      | Alta                                            |
| **Eficiencia de recursos**   | Variable             | Bueno                                      | Máxima                                          |
| **Mejor ajuste**             | Pequeño, equilibrado | Mediano, intensivo en cómputo              | Grande, especializado                           |

***

## Escenarios de implementación en el borde

Los clústeres de borde son implementaciones compactas de VergeOS de 2 nodos diseñadas para ubicaciones remotas o sucursales. Utilizan hardware de bajo consumo y formato pequeño, y están conectados directamente (no se requieren switches para la red troncal).

### Configuración típica de borde

* **2 nodos** conectados directamente mediante NICs duales (red troncal).
* Hardware de formato pequeño (Intel NUC, PCs SFF 1L o similares).
* 2 TB NVMe para cargas de trabajo + 4 TB SSD para almacenamiento masivo por nodo.
* Alta disponibilidad y redundancia completas a pesar de la huella mínima.

```mermaid
graph LR
    N1["Nodo 1<br/>Controlador + Almacenamiento + Cómputo"] <-->|"Red troncal<br/>(Conexión directa)"| N2["Nodo 2<br/>Controlador + Almacenamiento + Cómputo"]
    N1 --- EXT["Red externa<br/>(Uplink)"]
    N2 --- EXT

    style N1 fill:#e8f5e9,stroke:#2e7d32
    style N2 fill:#e8f5e9,stroke:#2e7d32
```

### Modelos de gestión de borde

VergeOS admite tres escenarios de gestión de borde de complejidad creciente:

1. **Autónomo con gestión central** -- clústeres de 2 nodos en cada sitio, gestionados de forma centralizada mediante el **Sitios** panel. Los repositorios de catálogo distribuyen recetas de VM desde el clúster de gestión a todos los sitios de borde.
2. **Copia de seguridad y DR centralizados** -- igual que el anterior, más un sistema central en el centro de datos principal que proporciona **Site Sync** replicación, **ioGuardian** servidores de reparación y almacenamiento centralizado de instantáneas para todas las sucursales.
3. **Multinivel con archivo** -- añade un clúster de archivo secundario en un sitio de DR para retención a largo plazo mediante discos HDD de alta capacidad, proporcionando una estrategia completa de copia de seguridad 3-2-1.

### Cuándo recomendar el borde

* Restricciones de espacio o energía en sitios remotos.
* Aplicaciones que almacenan datos de forma centralizada pero necesitan cómputo local.
* Organizaciones que gestionan 5--100+ ubicaciones distribuidas.
* Implementaciones de sucursales sensibles al coste.

***

## Escenarios CSP / multiinquilino

Los proveedores de servicios en la nube aprovechan la multi-tenencia de VergeOS para ofrecer IaaS desde infraestructura compartida. Cada inquilino funciona como un Centro de Datos Virtual (VDC) aislado, con su propia interfaz, redes, almacenamiento y controles de acceso.

### Configuración típica de CSP

* **Clústeres HCI de 6 nodos** en centros de datos principales (servidores de alta densidad, 768 GB+ de RAM por nodo).
* **Site Sync** entre centros de datos para DR.
* **ioGuardian** servidores de reparación para la recuperación automática de bloques desde sitios remotos.
* **Deduplicación global en línea** reduce el consumo de almacenamiento en instantáneas replicadas.
* **Recetas de inquilino** automatizan el aprovisionamiento de entornos completos de clientes (inquilino, redes, reglas de firewall, VMs, almacenamiento).

### Ruta de crecimiento de CSP

| Fase       | Implementación                                                                                                 | Nodos                                |
| ---------- | -------------------------------------------------------------------------------------------------------------- | ------------------------------------ |
| **Fase 1** | 2 sitios principales con DR mediante Site Sync                                                                 | 6 por sitio                          |
| **Fase 2** | Añadir clústeres de borde de 2 nodos en nuevas regiones                                                        | 2 por región                         |
| **Fase 3** | Escalar los sitios de borde añadiendo clústeres (ilustrativo)                                                  | varía según el sitio                 |
| **Fase 4** | Añadir clústeres de almacenamiento dedicados para inquilinos intensivos en almacenamiento y niveles de archivo | 2+ nodos de almacenamiento por sitio |

### Funciones clave de VergeOS para CSPs

* **Multi-tenencia** con aislamiento completo entre los entornos de los clientes.
* **Gestión de autoservicio** mediante interfaz web y API para los administradores de inquilinos.
* **Repositorios de catálogo** para la gestión centralizada de recetas de VM.
* **Autenticación OpenID** integración con proveedores de identidad existentes.
* **Recetas de inquilino** para una incorporación de clientes automatizada y repetible.

***

## Resumen de modelos de diseño de red

La arquitectura de implementación que elija influye en el diseño de su red. VergeOS admite varias topologías de red, que se tratan en detalle en [Módulo 4: Redes](/learn-the-platform/es/modulo-4-redes/04-networking.md). Aquí tiene un breve resumen para orientar su decisión de arquitectura:

| Modelo                            | NICs por nodo | Red troncal                          | Red externa                                    | Mejor para                                    |
| --------------------------------- | ------------- | ------------------------------------ | ---------------------------------------------- | --------------------------------------------- |
| **L2 estática + núcleo dedicado** | 4             | 2 L2 dedicadas                       | L2 en enlace agregado (LACP)                   | Entornos de producción, migraciones de VMware |
| **L3 dinámica + núcleo dedicado** | 4             | 2 L2 dedicadas                       | Anunciado por BGP / OSPF / EIGRP               | Gran escala, segmentación avanzada            |
| **L3 estática + núcleo dedicado** | 4             | 2 L2 dedicadas                       | L3 en enlace agregado (rutas estáticas)        | Gran escala, conmutación de Capa 3            |
| **L2 estática (2 NICs)**          | 2             | 2 compartidas (etiquetadas con VLAN) | Compartida con el núcleo (etiquetada con VLAN) | Borde, PoC, implementaciones pequeñas         |

**Requisitos clave en todos los modelos:**

* Las redes de la red troncal deben estar en **segmentos dedicados de Capa 2** (aislados entre sí).
* Tramas jumbo (**MTU 9216+**) en todos los puertos de los switches de la red troncal.
* **Cero saltos de switch** entre nodos en la red troncal -- todos los nodos deben conectarse a la misma infraestructura de conmutación.
* STP deshabilitado en los puertos de la red troncal.

***

{% hint style="info" %}
**Puente VMware**

¿Vienes de VMware? VergeOS te permite escalar almacenamiento y cómputo de forma independiente dentro de un solo sistema — los clústeres solo de cómputo consumen el vSAN compartido a través de la red troncal, sin SAN/NAS externa ni un producto de almacenamiento aparte que licenciar.
{% endhint %}

{% hint style="info" %}
**Puente Nutanix**

¿Vienes de Nutanix? VergeOS crea clústeres de almacenamiento puro y clústeres de cómputo puro en un solo sistema — el almacenamiento funciona como un servicio integrado del SO, por lo que no hay una CVM consumiendo RAM/CPU en ningún tipo de nodo.
{% endhint %}

## Resumen

| Concepto          | Idea clave                                                                                             |
| ----------------- | ------------------------------------------------------------------------------------------------------ |
| **HCI**           | Cada nodo hace de todo. Simple, rentable a pequeña escala. Empieza aquí.                               |
| **HCI + Cómputo** | UCI híbrida de 2 clústeres: controlador+almacenamiento fusionados, escalado independiente del cómputo. |
| **UCI**           | Clásica de 3 clústeres: controlador, almacenamiento y cómputo dedicados. Máxima flexibilidad.          |
| **Edge**          | Clústeres de conexión directa de 2 nodos para sitios remotos, administrados de forma centralizada.     |
| **CSP**           | Implementaciones HCI multiarrendatario con DR de Site Sync y automatización de recetas de inquilino.   |
| **Evolución**     | La misma instalación de VergeOS admite los tres modelos -- crece de HCI a UCI con el tiempo.           |

## Próximos pasos

* [**Definición del alcance del cliente**](/learn-the-platform/es/modulo-2-dimensionamiento-y-diseno/03-customer-scoping.md) -- Aprenda la metodología de recopilación de requisitos para traducir las necesidades del cliente en una recomendación de arquitectura específica.
* [**Redes**](/learn-the-platform/es/modulo-4-redes/04-networking.md) -- Profundice en los modelos de diseño de red mencionados arriba.


---

# 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-2-dimensionamiento-y-diseno/02-reference-architectures.md?ask=<question>&goal=<endgoal>
```

`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.