> 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/03-customer-scoping.md).
# Definición del alcance del cliente
Una implementación de VergeOS bien dimensionada comienza mucho antes de que se monte el primer nodo en el rack. Esta página proporciona una metodología estructurada para recopilar los requisitos del cliente, traducir las cargas de trabajo en estimaciones de recursos de VergeOS, planificar las configuraciones de nodos del inquilino y seleccionar la topología de implementación adecuada. Al final de este proceso, deberías tener un conjunto completo de entregables de documentación que cualquier ingeniero de VergeOS pueda usar para ejecutar la instalación.
## Lista de verificación para la recopilación de requisitos
Toda evaluación de dimensionamiento debe comenzar recopilando la siguiente información del cliente. Usa esta lista como guía de conversación durante las reuniones de descubrimiento.
### Inventario actual de cargas de trabajo
| Punto de datos | Por qué importa |
| --------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| **Número total de VMs** | Establece la escala de la implementación e influye en la selección de la arquitectura |
| **Núcleos de CPU por VM** | Impulsa el dimensionamiento del clúster de cómputo e identifica valores atípicos intensivos en CPU |
| **Asignación de RAM por VM** | La RAM suele ser el recurso limitante; determina la cantidad de nodos |
| **Almacenamiento por VM (aprovisionado y usado)** | Diferencia entre la capacidad aprovisionada de forma delgada y el consumo real |
| **Requisitos de IOPS / latencia de almacenamiento** | Identifica las cargas de trabajo que exigen NVMe frente a las que toleran SSD SAS/SATA |
| **Necesidades de GPU o hardware especializado** | Determina si los clústeres de cómputo necesitan dispositivos de paso directo |
| **Mezcla de sistemas operativos** | Windows, Linux, BSD — afecta la planificación de controladores e integración |
### Proyecciones de crecimiento
* **Pronósticos a 6, 12 y 24 meses** para la cantidad de VMs, CPU, RAM y almacenamiento.
* **Patrón de crecimiento:** ¿Crece el cómputo más rápido que el almacenamiento, o de forma proporcional? Esto influye directamente en la decisión entre HCI, HCI + Compute y UCI.
* **Patrones estacionales o de ráfagas** — las cargas de trabajo con períodos pico pueden necesitar margen que las métricas de estado estable no revelan.
### Requisitos de rendimiento
* **Objetivos de IOPS** por nivel de carga de trabajo (base de datos, aplicación, servicios de archivos).
* **Requisitos de latencia** — submilisegundo para bases de datos frente a uso general para servidores de archivos.
* **Rendimiento** — ancho de banda secuencial de lectura/escritura para cargas de trabajo de copia de seguridad, medios o análisis.
### Requisitos de disponibilidad y DR
* **RPO (objetivo de punto de recuperación):** ¿Cuánta pérdida de datos es aceptable? Impulsa la frecuencia de instantáneas y el programa de sincronización entre sitios.
* **RTO (objetivo de tiempo de recuperación):** ¿Con qué rapidez deben restaurarse los servicios? Influye en si los inquilinos necesitan HA multinodo o un solo nodo con conmutación por error automática.
* **Expectativas de N+1:** ¿Puede el clúster sobrevivir a la falla completa de un nodo con todas las cargas de trabajo en ejecución? Esto está directamente relacionado con la [decisión de reserva de RAM](#ram-reservation-decision) tratada más adelante en esta página.
* **Requisitos del sitio de DR:** ¿El cliente necesita replicación de sincronización entre sitios a una ubicación secundaria?
### Topología y restricciones de red
* **Infraestructura de conmutación existente:** Marca, modelo, capacidades (MLAG, LACP, BGP).
* **NIC disponibles por nodo:** 2 frente a 4+ determina el modelo de diseño de red.
* **Requisitos de VLAN:** ¿Cuántas redes aisladas se necesitan? ¿Los inquilinos están en VLAN compartidas o dedicadas?
* **Restricciones físicas:** ¿Todo el hardware está en un solo rack? ¿Varios racks? ¿Varios sitios?
* **Latencia de la infraestructura central:** Todos los nodos deben estar en la misma infraestructura de conmutación, sin saltos de switch.
### Presupuesto y cronograma
* **Presupuesto de hardware:** Influye en la selección del proveedor de servidores y en la cantidad de nodos.
* **Modelo de licenciamiento:** Basado en nodos — afecta la estrategia de optimización de costos.
* **Cronograma de instalación:** Implementación estándar vs. por fases.
***
## Traducción de cargas de trabajo a recursos
Una vez que tengas el inventario de cargas de trabajo del cliente, tradúcelo a los requisitos de recursos de VergeOS. VergeOS tiene significativamente **menos sobrecarga** que las plataformas tradicionales: no hay una máquina virtual controladora (CVM), no hay un appliance de vCenter ni una capa de administración separada consumiendo recursos.
### Paso 1: Agregar los totales de las cargas de trabajo
Suma los requisitos de carga de trabajo del cliente:
```
Núcleos vCPU totales = Σ (núcleos por VM)
RAM total (GB) = Σ (RAM por VM)
Almacenamiento total (TB) = Σ (almacenamiento aprovisionado por VM)
```
### Paso 2: Añadir la sobrecarga del sistema VergeOS
La sobrecarga de VergeOS es mínima, pero debe tenerse en cuenta:
| Recurso | Sobrecarga |
| ----------------------------------- | ------------------------------------------------------------------------------------ |
| **RAM por nodo vSAN** | 16 GB para VergeOS + 1 GB por cada 1 TB de almacenamiento bruto en ese nodo (mínimo) |
| **RAM por nodo vSAN (recomendada)** | 16 GB + 1,5 GB por cada 1 TB de almacenamiento bruto |
| **CPU por nodo de almacenamiento** | 1 núcleo por disco (recomendado) |
| **almacenamiento de Tier 0** | 5–10 GB por cada 1 TB de capacidad utilizable (solo nodos controladores) |
| **Nodos solo de cómputo** | Solo 16 GB para VergeOS; sin sobrecarga de almacenamiento |
{% hint style="success" %}
**RAM del nodo del inquilino: sin sobrecarga adicional de la capa del host**
Cuando asignas RAM a un nodo del inquilino, ese **monto completo** es lo que el host reserva — no **no** añades una sobrecarga separada de la capa del host para el inquilino. Sin embargo, dentro del inquilino, su propia instancia anidada de VergeOS consume la sobrecarga estándar (16 GB + 1 GB por 1 TB de almacenamiento) de esa asignación antes de que las VMs invitadas del inquilino reciban memoria.
Así que hay dos capas distintas: en el **host**, dimensiona el nodo del inquilino = la RAM que quieres que tenga el inquilino. Dentro del **inquilino**, planifica sus cargas de trabajo invitadas frente a (RAM asignada − 16 GB − 1 GB/TB).
{% endhint %}
### Paso 3: Tener en cuenta el margen para HA
Si el cliente requiere disponibilidad N+1 (el clúster puede sobrevivir a la falla de un nodo con todas las VMs en ejecución), debes asegurarte de que los **nodos restantes** tengan suficiente CPU y RAM agregadas para absorber las cargas de trabajo del nodo fallido.
**Regla general:** Para un clúster de N nodos, cada nodo debe aprovisionarse para usar no más de `(N-1)/N` de sus recursos totales. Por ejemplo, en un clúster de 4 nodos, apunta a una utilización del 75% por nodo.
### Paso 4: Calcular la cantidad de nodos
Divide los requisitos de recursos totales (incluida la sobrecarga y el margen de HA) entre la capacidad por nodo para determinar el número mínimo de nodos. Siempre redondea hacia arriba y valida el resultado contra las arquitecturas de referencia. Los rangos de cantidad de nodos a continuación son reglas generales aproximadas: HCI se adapta a implementaciones más pequeñas (normalmente de 2--12 nodos), y UCI aplica cuando el crecimiento de cómputo y almacenamiento diverge o se necesita hardware especializado:
* **2–6 nodos → HCI**
* **6–10 nodos → HCI + cómputo dedicado**
* **10+ nodos → UCI**
```mermaid
flowchart TD
A["Carga de trabajo agregada
CPU + RAM + almacenamiento"] --> B["Agregar sobrecarga de VergeOS
16 GB + 1 GB/TB por nodo"]
B --> C["Aplicar margen para HA
objetivo de utilización (N-1)/N"]
C --> D["Dividir por la capacidad por nodo"]
D --> E{"¿Cantidad de nodos?"}
E -->|"2-6"| HCI["Recomendar HCI"]
E -->|"6-10"| HCC["Recomendar HCI + cómputo"]
E -->|"10+"| UCI["Recomendar UCI"]
style HCI fill:#d1fae5,stroke:#059669
style HCC fill:#fef3c7,stroke:#d97706
style UCI fill:#e0e7ff,stroke:#4f46e5
```
***
## Planificación de nodos del inquilino
Para implementaciones multiinquilino (CSP, MSP o aislamiento interno por departamentos), cada inquilino se ejecuta dentro de un Centro de Datos Virtual (VDC) respaldado por uno o más **nodos de inquilino**. Los nodos del inquilino son máquinas virtuales que actúan como los nodos de cómputo de la instancia anidada de VergeOS del inquilino; el almacenamiento se aprovisiona a partir de las cuotas del nivel de almacenamiento del host y la red a través de las redes virtuales del inquilino.
### Inquilinos de un solo nodo frente a multinodo
**Los inquilinos de un solo nodo** son el punto de partida predeterminado y preferido:
* Proporcionan redundancia mediante conmutación por error automática — si falla el host físico, el nodo del inquilino se reinicia automáticamente en otro host.
* Son más sencillos de administrar y dimensionar correctamente.
* Pueden escalarse verticalmente (añadir núcleos/RAM) sin interrupción.
* Se pueden añadir nodos adicionales más adelante, sin interrupción, a medida que crece el inquilino.
**Los inquilinos multinodo** son necesarios cuando:
1. **Los requisitos de recursos superan los máximos del clúster** — los `RAM máxima por máquina` y `Núcleos máximos por máquina` ajustes del clúster limitan el tamaño de un solo nodo del inquilino.
2. **Aplicaciones en clúster** requieren cargas de trabajo en distintos hosts físicos (p. ej., base de datos primaria/réplica en nodos separados para HA).
3. **Capacidades de hardware mixtas** — el inquilino necesita tanto cómputo estándar como nodos equipados con GPU, que residen en clústeres físicos diferentes.
4. **Requisitos regulatorios** exigen separación de hardware entre tipos de cargas de trabajo.
### Estrategia de dimensionamiento adecuado
Los inquilinos de VergeOS admiten **escalado sin interrupciones** — puedes añadir recursos a los nodos existentes o agregar nodos completamente nuevos sin interrumpir las cargas de trabajo en ejecución. El enfoque recomendado:
1. **Aprovisiona para las necesidades actuales o a corto plazo** — no sobreasignes para un crecimiento futuro especulativo.
2. **Escalar orgánicamente** — aumenta los recursos del nodo del inquilino a medida que se materialice la demanda.
3. **Exhausta los nodos existentes antes de añadir nuevos** — es más eficiente aumentar un nodo de 32 GB a 64 GB que añadir un segundo nodo de 32 GB, salvo que la HA de la aplicación requiera separación física.
### Configuraciones de ejemplo
### Pequeño de un solo nodo
**Escenario:** 3 VMs, sin requisitos especiales, el clúster permite un máximo de 64 GB / 16 núcleos.
**Configuración:** 1 nodo del inquilino — 16 GB de RAM, 8 núcleos.
**Ruta de escalado:** Añade RAM/núcleos al nodo existente (hasta 64 GB / 16 núcleos) y luego añade un segundo nodo si es necesario.
### HA de tamaño medio
**Escenario:** Granja web con 4 servidores web + 2 servidores de base de datos que requieren separación física por host.
**Configuración:** 2 nodos del inquilino — 64 GB de RAM, 12 núcleos cada uno. Los grupos de HA aplican antiafinidad para que las instancias web/de base de datos se ejecuten en distintos hosts físicos.
**Ruta de escalado:** Aumenta los recursos del nodo o añade un tercer nodo para una mayor distribución de la carga de trabajo.
### Carga de trabajo mixta con GPU
**Escenario:** VMs estándar + renderizado de video acelerado por GPU en distintos clústeres de hardware.
**Configuración:** 4 nodos del inquilino — 2 en el clúster estándar (64 GB cada uno), 1 en el clúster vGPU (64 GB), 1 en el clúster de alto rendimiento (48 GB).
**Ruta de escalado:** Escala cada nodo de forma independiente según las capacidades de su clúster y la demanda de la carga de trabajo.
### Distribuido empresarial
**Escenario:** Plataforma de análisis distribuido que requiere 3 servidores de aplicaciones en hosts físicos separados + nodos de procesamiento de datos.
**Configuración:** 4 nodos del inquilino — 3 × 64 GB / 12 núcleos (aplicación + base de datos por nodo con antiafinidad del grupo HA) + 1 × 32 GB / 8 núcleos (procesamiento de datos).
**Ruta de escalado:** Añade recursos a los nodos existentes o añade nodos para una mayor separación física.
***
## Marco de decisión para la selección de topología
Con los requisitos de carga de trabajo recopilados y la traducción de recursos completada, usa los siguientes criterios para hacer tu recomendación de arquitectura:
| Criterios de decisión | HCI | HCI + Cómputo | UCI |
| ------------------------------- | --------------------------------------- | ------------------------------------------- | -------------------------------------------------- |
| **Cantidad de nodos** | 2–6 | 6–10 | 10+ |
| **Patrón de crecimiento** | Proporcional (cómputo ≈ almacenamiento) | Cómputo > almacenamiento | Cualquiera de las dos (totalmente independiente) |
| **Especialización** | No se necesita ninguna | Algunas (GPU en el clúster de cómputo) | Completa (GPU, alta memoria, almacenamiento denso) |
| **Tolerancia a la complejidad** | Personal de TI mínimo | Moderada | Equipo de infraestructura dedicado |
| **Presupuesto** | La más rentable | Moderada | La más alta (pero la más eficiente a escala) |
| **Aislamiento del rendimiento** | Contención aceptable | Cómputo aislado de la E/S de almacenamiento | Máximo — cada función en hardware dedicado |
### Lista de verificación para la decisión
1. **¿La cantidad de nodos es menor de 6?** → Comienza con HCI, salvo que haya un motivo específico para separar el cómputo.
2. **¿El cómputo crece más rápido que el almacenamiento?** → HCI + Compute te permite añadir nodos económicos solo de cómputo.
3. **¿Hay necesidades de GPU, alta memoria u otro hardware especializado?** → UCI permite clústeres de cómputo dedicados por tipo de hardware.
4. **¿El cliente necesita escalar el almacenamiento de forma independiente?** → UCI es el único modelo con un clúster de almacenamiento dedicado.
5. **¿La simplicidad operativa es la máxima prioridad?** → HCI tiene la menor sobrecarga de administración.
6. **¿Puede el entorno evolucionar con el tiempo?** → Siempre. VergeOS permite pasar de HCI → HCI + Compute → UCI añadiendo clústeres a un sistema existente.
***
## Decisión de reserva de RAM
Durante la instalación, el ingeniero debe decidir la preferencia de reserva de RAM. Se trata de un equilibrio entre **memoria utilizable** y **aplicación de HA N+1**:
| Opción | Comportamiento | Mejor para |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Más memoria utilizable** | El sistema permite que las VMs consuman más de la RAM disponible, reduciendo la reserva automática para margen de conmutación por error | Entornos en los que maximizar la densidad de cargas de trabajo por nodo es más importante que garantizar la capacidad de conmutación por error N+1 |
| **Mayor aplicación de HA N+1** | El sistema reserva más RAM para garantizar que, si falla un nodo, los nodos restantes tengan capacidad garantizada para absorber todas las cargas de trabajo desplazadas | Entornos de producción con SLAs de disponibilidad estrictos en los que la conmutación por error garantizada no es negociable |
{% hint style="warning" %}
Esta decisión debe tomarse **antes de** el día de la instalación. Analiza el equilibrio con el cliente durante el dimensionamiento y documenta la preferencia elegida en el plan de instalación.
{% endhint %}
***
## Entregables de documentación
Una evaluación completa de dimensionamiento debe producir el siguiente paquete de documentación, listo para el ingeniero de instalación:
### 1. Documentación de diseño de red
* **Dibujo de diseño de capa 2** — switches físicos, VLAN, asignaciones de puertos, configuración MLAG/apilamiento.
* **Dibujo de diseño de capa 3** — subredes, puertas de enlace, enrutamiento (BGP/OSPF si aplica), servidores DNS.
* **Mapa de cableado A-B** — cada cable de cada nodo a cada switch, etiquetado con identificadores de puerto.
* **Configuración de la infraestructura central** — VLAN dedicadas para Core 1 y Core 2, confirmación de MTU 9216+, verificación de cero saltos de switch.
### 2. Elevación del rack
* Ubicación física de cada nodo, switch, PDU y gestión de cables.
* Asignación de circuitos de energía y mapeo de redundancia.
### 3. Plan de asignación de IP
| Red | Dirección | Propósito |
| ------------------ | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Gestión/UI | `10.x.x.2/24` | Interfaz web y API de VergeOS |
| Puerta de enlace | `10.x.x.1` | Puerta de enlace predeterminada para tráfico externo |
| Tejido central 1 | VLAN 900 | VLAN de acceso sin etiquetas creada en el switch; las IP de los nodos se asignan automáticamente por VergeOS. Tráfico de almacenamiento y control entre nodos |
| Tejido central 2 | VLAN 901 | VLAN de acceso sin etiquetas creada en el switch; las IP de los nodos se asignan automáticamente por VergeOS. Tráfico redundante entre nodos |
| IPMI | `192.168.x.0/24` | Gestión fuera de banda |
| Redes de inquilino | Asignación por inquilino | Subredes específicas del cliente |
### 4. Lista de materiales de hardware
* Modelo de servidor, CPU, RAM, configuración de discos por nodo.
* Tipos y velocidades de NIC.
* Modelos de switch y cantidad de puertos.
* Especificaciones NVMe de nivel 0 (DWPD, capacidad por TB de almacenamiento utilizable).
### 5. Plan de instalación
* Arquitectura de referencia elegida (HCI, HCI + Compute o UCI).
* Asignaciones de nivel de disco por nodo.
* Preferencia de reserva de RAM (memoria utilizable vs. aplicación de N+1).
* Decisión de cifrado (cifrado en reposo sí/no, plan de almacenamiento de claves).
* Configuración del servidor NTP.
* Plan de credenciales de administrador (referencia al repositorio de contraseñas).
***
{% hint style="info" %}
**¿Vienes de VMware o Nutanix?**
El dimensionamiento de VergeOS es una sola pasada: una sobrecarga fija de 16 GB del sistema por nodo más 1 GB por TB de almacenamiento bruto. No hay CVM, no hay un appliance de administración separado y no hay un ejercicio de licenciamiento por función: cómputo, almacenamiento, redes y multitenencia se dimensionan juntos como una sola plataforma.
{% endhint %}
***
## Resumen
| Fase | Resultado |
| ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Recopilación de requisitos** | Lista de verificación completada con inventario de cargas de trabajo, proyecciones de crecimiento, objetivos de rendimiento y restricciones de red |
| **Traducción de recursos** | CPU, RAM y almacenamiento totales con la sobrecarga de VergeOS y el margen de HA aplicados |
| **Planificación de inquilinos** | Decisiones de nodo único frente a multinodo por inquilino con configuraciones de ejemplo |
| **Selección de topología** | Recomendación de HCI, HCI + Compute o UCI con justificación |
| **Reserva de RAM** | Preferencia documentada — memoria utilizable vs. aplicación de N+1 |
| **Paquete de documentación** | Planos de red, elevación del rack, plan de IP, BOM y plan de instalación |
## Siguientes pasos
* [**Requisitos de hardware**](/learn-the-platform/es/modulo-2-dimensionamiento-y-diseno/01-hardware-requirements.md) — Verifica las especificaciones de tus nodos frente a los requisitos mínimos y recomendados.
* [**Arquitecturas de referencia**](/learn-the-platform/es/modulo-2-dimensionamiento-y-diseno/02-reference-architectures.md) — Revisa los diagramas detallados de topología para la arquitectura seleccionada.
* [**Módulo 3: Instalación**](/learn-the-platform/es/modulo-3-instalacion/03-installation.md) — Continúa con la preparación y ejecución de la instalación.
---
# 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/03-customer-scoping.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.