> 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/lab.md). # Laboratorio: Explore la arquitectura ## Resumen del laboratorio En este laboratorio, explorarás el **VergeOS Terraform Playground** — un proyecto de código abierto que despliega sistemas virtuales VergeOS usando Terraform. Al leer el código y la documentación, reforzarás los conceptos de arquitectura cubiertos en este módulo: redes del tejido central, niveles de almacenamiento vSAN, organización del clúster y topologías HCI frente a UCI. ### Lo que harás * **Parte 1** — Lee la documentación de arquitectura del playground y el código de Terraform para identificar cómo los conceptos de VergeOS se mapean a infraestructura como código * **Parte 2** — Dado un escenario de cliente, recomienda y dibuja un diagrama de una topología de despliegue * **Parte 3** — Compara las cuatro configuraciones de despliegue de ejemplo y analiza sus diferencias ### Requisitos previos * Una cuenta de GitHub (para clonar el repositorio) * Git instalado en tu estación de trabajo * Un editor de texto o IDE (se recomienda VS Code) * No se requiere acceso a ningún sistema VergeOS; este laboratorio es un ejercicio de lectura y diseño ### Tiempo estimado **30 minutos** *** ## Parte 1: Explora la arquitectura En esta sección, clonarás el repositorio del playground de Terraform y seguirás cómo se expresan los conceptos de arquitectura de VergeOS en infraestructura como código. 1. **Clona el repositorio** ```bash git clone https://github.com/verge-io/vergeos-terraform-playground.git cd vergeos-terraform-playground ``` 2. **Lee la documentación de arquitectura** Abre `docs/architecture.md` y lee todo el documento. A medida que lo leas, identifica las respuestas a estas preguntas: * ¿Cuáles son los **cuatro escenarios de despliegue** compatibles con el playground? * ¿Qué es un **archivo seed de instalación** y cómo permite una instalación desatendida? * ¿Cuál es el **despliegue mínimo** ? > **Pista:** Los cuatro escenarios se enumeran en `docs/deployment-scenarios.md` con diagramas de topología. El despliegue mínimo son dos nodos controladores que forman un único clúster HCI. 3. **Examina los diagramas de escenarios de despliegue** Abre `docs/deployment-scenarios.md` y estudia los diagramas de topología en Mermaid para cada escenario. Para cada uno, anota: * Cuántos **nodos** están involucrados * Cuántos **clústeres** se crean * Cuáles **tipos de nodos** aparecen (controlador, escalado horizontal, almacenamiento, cómputo) * Cómo se conectan todos los nodos al **tejido central** y **red externa** 4. **Rastrea el tejido central en Terraform** Abre `main.tf` (el módulo raíz) y encuentra los dos recursos de red del tejido central. Responde a estas preguntas: * ¿Cómo se llaman los`core_fabric_1` y `core_fabric_2`) * ¿Qué **MTU** está configurado? (9142 — marcos jumbo para la replicación de vSAN) * ¿Está DHCP habilitado en estas redes? (No — `dhcp_enabled = false`) * ¿Qué `ipaddress_type` está configurado? (`none` — estos son transportes de capa 2) ```hcl # Debes encontrar recursos como este en main.tf: resource "vergeio_network" "core_fabric_1" { name = "${var.system_name}-core-fabric-1" enabled = true dhcp_enabled = false on_power_loss = "power_on" mtu = 9142 ipaddress_type = "none" } ``` 5. **Examina en qué se diferencia el Nodo 1 del Nodo 2** Abre `modules/controllers/main.tf` y compara `verge_node_1` y `verge_node_2`. Diferencias clave que identificar: * **Plantilla de cloud-init** — El Nodo 1 usa `user-data-node1.yaml` (crea un nuevo sistema con `YC_VSAN_NEW=1`). El Nodo 2 usa `user-data-node2.yaml` (se une al sistema existente con `YC_VSAN_NEW=0`). * **Configuración de API posterior a la instalación** — El cloud-init del Nodo 1 incluye un script que configura las fuentes de actualización, habilita SSH y, opcionalmente, crea clústeres de almacenamiento/cómputo mediante la API de VergeOS. El Nodo 2 no tiene script posterior a la instalación. * **Cadena de dependencias** — El Nodo 2 tiene una `depends_on` referencia al Nodo 1, lo que garantiza que el sistema esté completamente inicializado antes de que el segundo controlador intente unirse. Ambos nodos comparten la misma estructura de VM: familia de SO Linux, virtualización anidada habilitada, tres NIC virtio (externa, tejido central 1, tejido central 2), CD-ROM con la ISO de VergeOS y un datasource cloud-init nocloud. 6. **Responde a las preguntas de comprensión** Escribe tus respuestas a lo siguiente (o comenta con tu compañero de formación): | # | Pregunta | Respuesta esperada | | - | ----------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | ¿Por qué el tejido central usa dos switches separados? | Redundancia: si falla un switch o una ruta, el otro mantiene la conectividad entre nodos | | 2 | ¿Por qué está DHCP deshabilitado en las redes del tejido central? | El tejido central usa direccionamiento IP estático; el instalador de VergeOS configura las direcciones mediante el archivo seed de instalación | | 3 | ¿Por qué el Nodo 2 debe esperar a que el Nodo 1 termine antes de iniciar? | El Nodo 1 crea el sistema VergeOS; el Nodo 2 necesita un sistema existente al que unirse | | 4 | ¿Qué tipos de tráfico circulan por el tejido central? | replicación de vSAN, coordinación del clúster, migración en vivo de VMs, comunicación del plano de control | | 5 | ¿Por qué `quantity_tier_1_disks` está establecido en 0 para los controladores cuando los nodos de almacenamiento están habilitados? | En modo UCI, los nodos de almacenamiento dedicados proporcionan toda la capacidad de tier-1; los controladores solo necesitan tier-0 para metadatos | *** ## Parte 2: Ejercicio de diseño Ahora aplica lo que has aprendido. Dado un escenario de cliente, recomienda una topología de despliegue y justifica tu decisión. ### Escenario del cliente > **Midwest Manufacturing Co.** está migrando desde un entorno VMware vSphere con 3 hosts ESXi. Actualmente ejecutan 50 VMs (mezcla de Windows y Linux), tienen \~10 TB de almacenamiento utilizable y esperan un crecimiento moderado durante los próximos 2 años. Tienen un pequeño equipo de TI (2 personas) y quieren minimizar la complejidad operativa. El presupuesto es limitado. 1. **Elige HCI o UCI** Según el perfil del cliente, ¿qué modelo de despliegue recomiendas? Considera: * **Tamaño del equipo** — Un equipo de TI de 2 personas favorece la simplicidad * **Patrón de crecimiento** — «Crecimiento moderado» sugiere un escalado equilibrado de cómputo/almacenamiento * **Presupuesto** — HCI requiere menos nodos totales que UCI para la misma capacidad * **Entorno actual** — 3 hosts ESXi encajan bien en un pequeño clúster HCI > **Respuesta recomendada:** **HCI** HCI es la mejor opción. El equipo pequeño se beneficia de la arquitectura más simple (un solo tipo de clúster), el escalado equilibrado coincide con su crecimiento moderado, menos nodos reducen el costo y HCI refleja de cerca su modelo de clúster VMware existente. 2. **Determina el número de nodos y la distribución** Dibuja o describe tu topología propuesta: * Cuántos **nodos controladores**¿? (Mínimo 2 para HA) * ¿Necesitas **nodos de escalado horizontal**? (Piensa: 50 VMs en 2 nodos puede ser ajustado; 2 nodos de escalado horizontal dan margen) * Cuántos **clústeres**? (1 para HCI) * ¿Y qué hay de **la capacidad de almacenamiento**? (10 TB utilizables significan \~20 TB sin procesar con replicación entre nodos) Un diseño razonable: ```mermaid graph TB subgraph "Clúster 1 (HCI)" N1["Nodo 1 — Controlador
Almacenamiento + Cómputo"] N2["Nodo 2 — Controlador
Almacenamiento + Cómputo"] N3["Nodo 3 — Escalado horizontal
Almacenamiento + Cómputo"] N4["Nodo 4 — Escalado horizontal
Almacenamiento + Cómputo"] end CF["Tejido central (doble switch)"] EXT["Red externa"] N1 --- CF N2 --- CF N3 --- CF N4 --- CF N1 --- EXT N2 --- EXT N3 --- EXT N4 --- EXT ``` 3. **Relaciónalo con un ejemplo del playground** ¿Qué archivo de ejemplo del playground de Terraform coincide más con tu diseño? > **Respuesta:** **`examples/4-node-hci.tfvars`** — 2 controladores + 2 nodos de escalado horizontal en un único clúster HCI. Esto coincide con el diseño HCI de 4 nodos recomendado para un escalado equilibrado de cómputo y almacenamiento. *** ## Parte 3: Comparación de topologías Compara los cuatro `.tfvars` archivos de la `examples/` directorio. Completa la tabla de comparación a continuación. ### Instrucciones Abre cada archivo e identifica los valores de configuración. Usa la tabla para registrar tus hallazgos. {% tabs %} {% tab title="2-node-hci.tfvars" %} **Archivo:** `examples/2-node-hci.tfvars` * **Escenario:** HCI de 2 nodos (clúster único) * **Número total de nodos:** 2 * **Clústeres:** 1 * **Tipos de nodos:** 2 controladores (almacenamiento + cómputo) * **Variables de alternancia:** Ninguna (todos los valores predeterminados) * **¿Discos de tier-1 en los controladores?:** Sí (2 × 1000 GB cada uno) * **Ideal para:** Pruebas básicas, evaluación, el despliegue más pequeño posible {% endtab %} {% tab title="4-node-hci.tfvars" %} **Archivo:** `examples/4-node-hci.tfvars` * **Escenario:** HCI + Escalado horizontal (clúster único) * **Número total de nodos:** 4 * **Clústeres:** 1 * **Tipos de nodos:** 2 controladores + 2 de escalado horizontal * **Variables de alternancia:** `create_scale_out_nodes = true` * **¿Discos de tier-1 en los controladores?:** Sí (2 × 1000 GB cada uno) * **Ideal para:** Clústeres HCI más grandes, pruebas del comportamiento de escalado horizontal, crecimiento equilibrado {% endtab %} {% tab title="4-node-hybrid.tfvars" %} **Archivo:** `examples/4-node-hybrid-hci-2-cluster.tfvars` * **Escenario:** HCI híbrido (2 clústeres) * **Número total de nodos:** 4 * **Clústeres:** 2 * **Tipos de nodos:** 2 controladores (almacenamiento + cómputo) + 2 solo cómputo * **Variables de alternancia:** `create_compute_nodes = true` * **¿Discos de tier-1 en los controladores?:** Sí (los controladores proporcionan todo el almacenamiento) * **Ideal para:** Separar el escalado de cómputo del almacenamiento, agregar capacidad de ráfaga de cómputo {% endtab %} {% tab title="6-node-uci.tfvars" %} **Archivo:** `examples/6-node-uci-3-cluster.tfvars` * **Escenario:** UCI (3 clústeres) * **Número total de nodos:** 6 * **Clústeres:** 3 * **Tipos de nodos:** 2 controladores + 2 solo almacenamiento + 2 solo cómputo * **Variables de alternancia:** `create_storage_nodes = true`, `create_compute_nodes = true` * **¿Discos de tier-1 en los controladores?:** No (los nodos de almacenamiento proporcionan toda la capacidad de tier-1) * **Ideal para:** UCI similar a producción, escalado independiente de almacenamiento y cómputo, entornos más grandes {% endtab %} {% endtabs %} ### Tabla resumen de comparación Completa esta tabla mientras revisas cada archivo: | Atributo | HCI de 2 nodos | HCI de 4 nodos | Híbrido de 2 clústeres | UCI de 3 clústeres | | ----------------------------------------------- | -------------------- | --------------------- | ----------------------- | ------------------------------- | | **Número total de nodos** | 2 | 4 | 4 | 6 | | **Clústeres** | 1 | 1 | 2 | 3 | | **Nodos controladores** | 2 | 2 | 2 | 2 | | **Nodos de escalado horizontal** | 0 | 2 | 0 | 0 | | **Nodos solo de almacenamiento** | 0 | 0 | 0 | 2 | | **Nodos solo de cómputo** | 0 | 0 | 2 | 2 | | **¿Los controladores tienen discos de tier-1?** | Sí | Sí | Sí | No | | **Escalado de almacenamiento** | Añadir nodos HCI | Añadir nodos HCI | Añadir controladores | Añadir nodos de almacenamiento | | **Escalado de cómputo** | Añadir nodos HCI | Añadir nodos HCI | Añadir nodos de cómputo | Añadir nodos de cómputo | | **Complejidad** | Baja | Baja | Media | Alta | | **Caso de uso ideal** | Pequeño / evaluación | Mediano y equilibrado | Ráfaga de cómputo | Grande / escalado independiente | ### Preguntas de análisis Después de completar la tabla, considera estas preguntas: 1. **¿Por qué los controladores en el escenario UCI tienen cero discos de tier-1?** > En UCI, los nodos de almacenamiento dedicados proporcionan todo el almacenamiento de las cargas de trabajo. Los controladores solo necesitan discos de tier-0 para los metadatos de vSAN. Esto es visible en `main.tf` donde `quantity_tier_1_disks` se establece condicionalmente en 0 cuando `create_storage_nodes = true`. 2. **¿Cuál es la cadena de dependencias cuando están habilitados tanto los nodos de almacenamiento como los de cómputo?** > Controladores → nodos de almacenamiento → nodos de cómputo. El módulo de cómputo tiene una `depends_on` referencia explícita al módulo de almacenamiento, lo que garantiza que el clúster de almacenamiento exista antes de que los nodos de cómputo intenten unirse. Esto refleja cómo funciona la creación de clústeres en VergeOS: el almacenamiento debe estar disponible antes de que puedan ejecutarse las cargas de trabajo de cómputo. 3. **¿Cómo modificarías el ejemplo HCI de 4 nodos para admitir 6 nodos HCI?** > Cambia `quantity_scale_out_nodes` de `2` a `4`. El módulo de Terraform crea nodos adicionales de escalado horizontal de forma secuencial, y cada uno se une al mismo clúster HCI. No se necesitan variables de alternancia adicionales. *** ## Puntos clave Después de completar este laboratorio, deberías poder: * ✅ Navegar por el playground de Terraform de VergeOS y entender su estructura * ✅ Identificar cómo se expresan en Terraform las redes del tejido central, los niveles de almacenamiento vSAN y los tipos de nodos * ✅ Explicar las diferencias entre los cuatro escenarios de despliegue (HCI de 2 nodos, HCI de 4 nodos, híbrido de 2 clústeres, UCI de 3 clústeres) * ✅ Recomendar una topología VergeOS adecuada para un escenario de cliente dado * ✅ Rastrear la cadena de dependencias desde los controladores hasta los tipos de nodos opcionales ## Siguientes pasos Continúa a [**Módulo 2: Dimensionamiento y diseño**](/learn-the-platform/es/modulo-2-dimensionamiento-y-diseno/02-sizing-design.md) para aprender a traducir los requisitos del cliente en configuraciones de hardware y planes de despliegue específicos. --- # 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/lab.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.