> 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/knowledge-base/es/system-administration/cpu-overprovisioning-guide.md).

# Sobreaprovisionamiento de CPU y planificación de recursos

## Resumen

La sobreasignación de CPU (también llamada overcommit) le permite asignar más núcleos virtuales de CPU a las cargas de trabajo de los que tiene núcleos físicos disponibles. Esta guía explica cómo VergeOS gestiona los recursos de CPU, las implicaciones de la sobreasignación y las mejores prácticas para la planificación de capacidad.

## Cómo funciona la asignación de CPU en VergeOS

### Núcleos virtuales frente a físicos

Cuando asigna vCPUs a una VM, está asignando **núcleos virtuales** que se programan en núcleos físicos de CPU. VergeOS no reserva núcleos físicos exclusivamente para las VMs; en su lugar, utiliza reparto de tiempo para compartir los recursos físicos.

**Puntos clave:**

* Las vCPUs no se fijan a núcleos físicos de forma predeterminada
* Varias vCPUs de diferentes VMs pueden compartir el mismo núcleo físico
* El planificador del hipervisor gestiona la asignación del tiempo de CPU

### La configuración "Máx. núcleos por máquina"

Esta configuración del clúster controla el número máximo de núcleos de CPU que pueden asignarse a una sola carga de trabajo (VM, nodo de inquilino o servicio NAS).

**Ubicación:** Infraestructura > Clústeres > \[Nombre del clúster] > Editar

{% hint style="warning" %}
**Restricciones críticas**

* Este valor debería **nunca exceder** el total de núcleos físicos de su nodo más pequeño
* En la mayoría de los casos, manténgalo **dentro de un solo socket de CPU** para un rendimiento NUMA óptimo
* Las VMs que superen este límite después de un cambio **no pueden migrar** hasta que se reduzcan los núcleos
  {% endhint %}

## Ratios de sobreasignación de CPU

### ¿Qué es un ratio de sobreasignación?

La relación entre las vCPUs totales asignadas y los núcleos físicos totales:

```
Ratio de sobreasignación = vCPUs totales asignadas / núcleos físicos totales
```

**Ejemplo:** Un clúster de 2 nodos con 32 núcleos cada uno (64 en total) ejecutando VMs con 96 vCPUs totales tiene un ratio de sobreasignación de 1.5:1.

### Ratios recomendados por tipo de carga de trabajo

| Tipo de carga de trabajo                 | Ratio       | Notas                                     |
| ---------------------------------------- | ----------- | ----------------------------------------- |
| Cargas ligeras/de oficina                | 4:1 a 6:1   | VMs de escritorio, servidores de archivos |
| Propósito general mixto                  | 2:1 a 4:1   | Mezcla empresarial típica                 |
| Servidores de base de datos/aplicaciones | 1:1 a 2:1   | Sensibles al rendimiento                  |
| Computación de alto rendimiento          | 1:1 o menos | Cargas limitadas por CPU                  |

{% hint style="success" %}
**Comience de forma conservadora**

Empiece con ratios más bajos y aumente según la supervisión. Es más fácil añadir capacidad que recuperarse de un rendimiento deficiente.
{% endhint %}

## Implicaciones en el rendimiento

### Cuándo funciona bien la sobreasignación

* **Cargas con picos:** VMs que tienen picos ocasionales de CPU pero están mayormente inactivas
* **Sincronización diversa:** Cargas de trabajo que alcanzan su pico en distintos momentos
* **Aplicaciones limitadas por E/S:** VMs que esperan más por disco o red que por CPU

### Cuándo la sobreasignación causa problemas

* **Cargas limitadas por CPU:** Aplicaciones que usan constantemente el 100% de CPU
* **Aplicaciones sensibles a la latencia:** Sistemas en tiempo real, VoIP, trading
* **Demanda simultánea:** Todas las VMs necesitan CPU al mismo tiempo

### Señales de sobreasignación excesiva

1. **Alto tiempo de espera de CPU:** VMs esperando disponibilidad de CPU física
2. **Rendimiento inconsistente:** Las aplicaciones funcionan bien a veces y mal en otras
3. **El sistema operativo invitado muestra alta CPU:** Pero el hipervisor muestra una utilización menor

## Planificación de capacidad

### Cálculo de la capacidad de CPU disponible

Para un clúster con redundancia N+1:

```
Núcleos disponibles = (Nodos - 1) × Núcleos por nodo
vCPUs utilizables = Núcleos disponibles × Ratio objetivo de sobreasignación
```

**Ejemplo:** Clúster de 4 nodos, 32 núcleos cada uno, ratio objetivo 2:1

* Disponibles: (4-1) × 32 = 96 núcleos
* vCPUs utilizables: 96 × 2 = 192 vCPUs

### Consideraciones de migración

Cuando un nodo falla o entra en mantenimiento:

* Todas las VMs deben caber en los nodos restantes
* Cada VM debe caber dentro de la configuración "Máx. núcleos por máquina"
* Las VMs con muchas vCPUs pueden quedar aisladas si ningún nodo individual puede alojarlas

{% hint style="warning" %}
**Preparación para la migración**

Si una VM tiene 64 vCPUs pero sus nodos solo tienen 32 núcleos, esa VM **no pueden migrar** durante eventos de mantenimiento o fallo. Mantenga el recuento de núcleos de las VMs dentro de la capacidad de un solo nodo.
{% endhint %}

## Mejores prácticas

### Directrices generales

1. **Supervise antes de asignar:** Comprenda los patrones reales de uso de CPU antes de añadir capacidad
2. **Dimensione las VMs adecuadamente:** Empiece con menos vCPUs y aumente según sea necesario
3. **Reserve margen:** Mantenga disponible un 20-30% de capacidad para picos y conmutación por error
4. **Use los límites de CPU con moderación:** Evitan que las VMs utilicen recursos ociosos disponibles

### Diseño del clúster

1. **Tamaño consistente de los nodos:** Hace que la planificación de capacidad sea más sencilla
2. **Planifique para N+1:** Suponga siempre que un nodo no estará disponible
3. **Documente los supuestos:** Registre sus objetivos de sobreasignación y los motivos

### Configuración de la VM

1. **Ajuste las vCPUs a la carga de trabajo:** Más vCPUs no siempre significa mejor rendimiento
2. **Considere NUMA:** Para VMs grandes, mantenga las vCPUs dentro de los límites del nodo NUMA
3. **Pruebe el rendimiento:** Haga pruebas de referencia con cargas de trabajo realistas

## Monitorización de la salud de la CPU

### Métricas clave a vigilar

| Métrica                        | Rango saludable                 | Acción si se supera                  |
| ------------------------------ | ------------------------------- | ------------------------------------ |
| Utilización de CPU del clúster | < 70% de media                  | Añada nodos o reduzca VMs            |
| Utilización de CPU del nodo    | < 80% sostenido                 | Compruebe la distribución de las VMs |
| CPU de VM individual           | Varía según la carga de trabajo | Ajuste el tamaño o investigue        |

### Uso del panel de VergeOS

1. Vaya a **Infraestructura** > **Clústeres**
2. Ver gráficos de utilización de CPU
3. Haga clic en nodos individuales para ver las métricas por nodo
4. Consulte las estadísticas de CPU de la VM en el panel de cada VM

Para más detalles sobre la monitorización del clúster, consulte [Resumen de clústeres](/run-the-platform/system-administration/clusters-overview.md).

## Preguntas frecuentes

### ¿Puedo asignar a una sola VM más vCPUs que núcleos físicos?

Sí, pero rara vez es beneficioso. Una VM con más vCPUs que núcleos físicos en un nodo puede experimentar retrasos de programación mientras el hipervisor espera a que haya suficientes núcleos disponibles simultáneamente.

### ¿VergeOS admite el fijado de CPU?

VergeOS no admite el fijado de CPU (afinidad). Internamente, VergeOS utiliza el Completely Fair Scheduler (CFS) de Linux para la programación de CPU. Cada vCPU se asigna a un proceso/hilo de Linux, y todos los hilos de vCPU comparten la misma cola de ejecución del CFS. El planificador utiliza lógica de equidad global para determinar qué proceso obtiene tiempo de CPU y en qué orden.

Este diseño garantiza un uso óptimo de los recursos y mantiene la movilidad de las VMs para migración en vivo y conmutación por error. Cuando sobreasigna recursos de CPU, está compartiendo ese conjunto de núcleos físicos con otras VMs e inquilinos.

### ¿Cómo afecta esto al licenciamiento de software?

Algunos programas (Oracle, SQL Server) se licencian por núcleo físico o por socket. La programación dinámica de VergeOS significa que no puede "particionar de forma rígida" los recursos de CPU. Consulte las políticas de licenciamiento de virtualización de su proveedor de software; muchos ofrecen modelos de licencia por vCPU o por VM que funcionan mejor con hipervisores modernos.

### ¿Y qué pasa con NUMA?

Para VMs con muchas vCPUs, VergeOS intenta mantener las asignaciones de memoria y CPU dentro del mismo nodo NUMA cuando es posible. Para un mejor rendimiento NUMA, mantenga el número de vCPUs de la VM igual o inferior al número de núcleos de un solo socket.

## Temas relacionados

* [Resumen de clústeres](/run-the-platform/system-administration/clusters-overview.md) - Entender la arquitectura del clúster
* [Opciones de configuración del clúster](/run-the-platform/system-administration/cluster-settings.md) - Todas las configuraciones del clúster explicadas
* [Mejores prácticas para VMs](/run-the-platform/virtual-machines/vm-best-practices.md) - Recomendaciones para la configuración de VMs
* [Creación de máquinas virtuales](/run-the-platform/virtual-machines/creating-vms.md) - Guía de creación de VMs
* [Migraciones en vivo](/run-the-platform/virtual-machines/live-migrations.md) - Mover VMs entre nodos


---

# 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/knowledge-base/es/system-administration/cpu-overprovisioning-guide.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.
