Unidad 4.1: Selección de clase de cómputo

Introducción

La clase de cómputo no es una decisión de dimensionamiento; es una decisión arquitectónica, y en IONOS CLOUD se toma por nivel y no por conjunto de recursos. La clase que elija fija cuatro aspectos a la vez: si la carga de trabajo obtiene un núcleo físico exclusivo o lo comparte, si puede fijar la familia de CPU, si puede adjuntar Block Storage de red y quién asume el modelo operativo. Una de esas decisiones es prácticamente permanente (la plantilla de un Cube es inmutable después del aprovisionamiento), por lo que acertar con la clase en el momento del diseño resulta más económico que cualquier solución alternativa posterior. Esta unidad hace explícita esa decisión a través de las tres clases de cómputo de IONOS CLOUD y concluye con el aprovisionamiento de la estructura de Dedicated Core que las unidades 4.2 y 4.3 amplían con almacenamiento, cloud-init y autoescalado.

1. La decisión de cómputo de cuatro vías

Cada clase de cómputo de IONOS CLOUD responde de manera diferente a las mismas cuatro preguntas. Si tiene en cuenta estos cuatro ejes, la clase casi se selecciona por sí sola.

Aislamiento de núcleos. Un servidor Dedicated Core se asigna con un núcleo físico dedicado, que se expone al sistema operativo invitado como dos núcleos lógicos (un núcleo físico con Hyper-Threading se presenta como dos hilos). Un servidor vCPU comparte núcleos físicos con otros inquilinos. El aislamiento proporciona un rendimiento predecible bajo contención; el compartido ofrece un precio más bajo. Este es el modelo de contención que la Unidad 2.4 planteó como la primera palanca de costos, ahora visto desde el lado del cómputo.

Control de la familia de CPU. Solo Dedicated Core permite seleccionar y cambiar posteriormente la familia de CPU (por ejemplo, fijar AMD EPYC para una carga de trabajo que se beneficia de ello, o estandarizar un nivel en Intel Xeon). En un servidor vCPU, la familia no es seleccionable. Esto es importante cuando una carga de trabajo es sensible a las diferencias del conjunto de instrucciones o de la frecuencia por núcleo, o cuando una licencia está vinculada a una familia de CPU.

Adjunción de Block Storage. Los servidores Dedicated Core y vCPU adjuntan volúmenes de Block Storage de red (el disco de arranque y cualquier disco de datos residen en la trama de bloques iSCSI, cubierta en la Unidad 4.2). Un Cube se entrega con un volumen NVMe adjunto directamente de carácter obligatorio que forma parte de su plantilla fija. El modelo de adjunción determina cómo se gestiona el ciclo de vida del almacenamiento, las instantáneas y el redimensionamiento.

Modelo operativo y SLA. Un servidor Dedicated Core o vCPU es una VM administrada con escalado vertical en vivo y un SLA de disponibilidad del 99,95 % por servicio. Un Cube es una instancia de plantilla fija con un SLA del 99,9 %.

La siguiente tabla compara las tres clases en función de los ejes que determinan la decisión.

Un servidor Dedicated Core puede configurarse con hasta 62 núcleos y 230 GB de RAM. La RAM se asigna en incrementos de 0,25 GB. Estos límites rara vez restringen un solo nivel, pero son importantes cuando se dimensiona un monolito grande antes de decidir si dividirlo.

1.1 Dedicated Core: la opción predeterminada para niveles que requieren una garantía

Elija Dedicated Core cuando el nivel necesite un rendimiento predecible bajo carga o cuando necesite fijar o cambiar la familia de CPU. El núcleo físico exclusivo es lo que garantiza el rendimiento bajo contención, y el control de la familia de CPU es exclusivo de esta clase. Si un nivel también se escala horizontalmente, su configuración de cómputo de réplica (arquitectura de CPU, núcleos y RAM) se define en el momento del diseño en la plantilla de réplica de VM Auto Scaling (Unidad 4.3), por lo que definir la forma de cómputo del nivel de forma temprana sigue siendo beneficioso. El costo del núcleo exclusivo es el precio que se paga por la garantía de rendimiento.

La selección de la familia de CPU en Dedicated Core es real, pero no gratuita: cambiar la familia en un servidor existente requiere un reinicio. Considere un cambio de familia como una operación de mantenimiento planificada con una ventana de tiempo, no como un ajuste en vivo.

1.2 vCPU: rentable donde la contención es aceptable

Un servidor vCPU se aprovisiona y se comporta como cualquier otra VM, pero comparte núcleos físicos, por lo que es la opción predeterminada rentable para entornos de desarrollo y pruebas, servicios internos de software esenciales y niveles donde la contención ocasional es aceptable. Soporta el escalado vertical en vivo como Dedicated Core, pero no puede seleccionar una familia de CPU. La regla de decisión es simple: si el nivel no necesita una garantía de rendimiento ni control de la familia de CPU, un servidor vCPU es la opción correcta más económica.

1.3 Cubes: la instancia de plantilla fija, no un callejón sin salida de almacenamiento

Un Cube es una instancia de configuración fija: vCPU, RAM y un volumen NVMe adjunto directamente se entregan como una plantilla empaquetada, y no puede cambiar esas propiedades de la plantilla después del aprovisionamiento. El volumen NVMe se conecta a través de PCI Express en el servidor físico y es redundante simple mediante RAID de software; ocupa uno de los slots de dispositivos de la instancia y no puede desmontarse ni eliminarse mientras el Cube exista. Las plantillas básicas van desde Basic-Cube-XS (1 vCPU, 2 GB de RAM, 60 GB de NVMe) hasta Basic-Cube-XL (16 vCPU, 32 GB de RAM, 960 GB de NVMe); las plantillas de memoria intercambian núcleos por RAM (por ejemplo, Memory-Cube-XL con 16 vCPU y 64 GB de RAM).

Aquí está la trampa, y funciona en dirección opuesta a un supuesto común. A menudo se descarta a un Cube por no poder usar Block Storage. Eso es incorrecto: un Cube soporta hasta 23 dispositivos adicionales de Block Storage HDD o SSD (Standard o Premium) además de su volumen NVMe obligatorio, y esos dispositivos adicionales pueden desmontarse y eliminarse en cualquier momento después del aprovisionamiento. La restricción real es diferente y más específica: la propia plantilla (vCPU, RAM y tamaño de NVMe) es inmutable, y el volumen NVMe no puede desvincularse. Eliminar un Cube elimina su volumen NVMe, por lo que tome una instantánea primero si los datos deben sobrevivir. Por lo tanto, la regla de diseño honesta es: elija un Cube cuando su paquete fijo coincida con la carga de trabajo y desee un concepto de cargo único y predecible, y planifique los datos persistentes en volúmenes de Block Storage adicionales que sobrevivan a la plantilla, no en el disco NVMe inmutable.

2. Clase por nivel como patrón

La unidad de la decisión de clase de cómputo es el nivel, no la aplicación. Un diseño empresarial por capas (la forma pública-L7-hacia-cómputo-sin-estado-hacia-privado-L4-hacia-datos-privados de la Unidad 1.2) combina clases de manera rutinaria: Dedicated Core para el nivel que debe escalar y mantener una garantía de rendimiento, vCPU para niveles internos o no críticos, y un Cube cuando un paquete fijo es una opción adecuada. Cuando una carga de trabajo requiere una plataforma administrada de inquilino único (por ejemplo, un entorno VMware regulado), se trata del VMware Private Cloud dedicado tratado en la Unidad 4.4, no de una clase de cómputo de Public Cloud. La combinación de clases por nivel es la norma, no un compromiso.

De esto se derivan dos reglas de diseño que vale la pena enunciar con claridad, porque ambas son fáciles de cometer errores bajo presión de tiempo:

• La configuración de cómputo de réplicas de un nivel de autoescalado se establece en el momento del diseño. VM Auto Scaling crea nuevas réplicas a partir de una plantilla de réplica (arquitectura de CPU, núcleos, RAM), y un cambio en la plantilla solo se aplica a las réplicas creadas después, por lo que la forma de la réplica es una decisión en el momento del diseño, no un ajuste en vivo (Unidad 4.3).
• Un cambio de familia de CPU es una operación planificada. Está disponible en Dedicated Core, pero requiere un reinicio, por lo que debe realizarse en una ventana de mantenimiento, no en un libro de procedimientos de ajuste en vivo.

Para FinCorp, la empresa regulada de servicios financieros alemana que se analiza a lo largo de este curso, el nivel de aplicación orientado al cliente es el más propenso a enfrentar carga variable y el más expuesto al equilibrador público de capa 7. Ese nivel se aprovisiona como Dedicated Core para una garantía de rendimiento predecible bajo carga, y por lo tanto su familia de CPU puede estandarizarse para un rendimiento consistente, y es el nivel que más adelante escala horizontalmente bajo una política de métricas (Unidad 4.3). En cambio, el nivel de informes por lotes internos de FinCorp tolera la contención y se aprovisiona como vCPU para ahorrar costos. El aspecto de cumplimiento refuerza esto: BSI C5 (la atestación de Tipo 1 del 7 de noviembre de 2023) e IT-Grundschutz (el certificado ISO 27001 del 14 de septiembre de 2022) abarcan ambos Compute Engine, por lo que las clases estándar de VM se encuentran dentro del alcance de atestación de FinCorp. El entorno VMware regulado es una decisión separada, tratada por el VMware Private Cloud dedicado en la Unidad 4.4.

Consideraciones de diseño

• Costo. El núcleo exclusivo de Dedicated Core es el sobrecoste que se paga por una garantía de rendimiento y la elegibilidad para el escalado automático. Cuando no se requiere ninguna de las dos, vCPU es la respuesta correcta y más económica; no se debe comprar un aislamiento que un nivel no necesite.
• Operaciones. La decisión permanente (la plantilla inmutable de un Cube) conlleva el mayor costo operativo cuando es incorrecta, porque corregirla implica reconstruirlo en lugar de reconfigurarlo. Se debe dedicar el mayor cuidado de diseño aquí.
• Escalabilidad. El escalado vertical (aumento en vivo de CPU y RAM) está disponible en Dedicated Core y vCPU dentro de los límites descritos en la Unidad 4.3; el escalado horizontal gestionado agrega y elimina réplicas completas bajo una política de métricas, con la configuración de cómputo de la réplica fija en la plantilla de la réplica en el momento del diseño. Se debe decidir en qué eje se escalará un nivel antes de seleccionar su clase.

Recorrido de implementación de DCD

Este recorrido aprovisiona la carcasa del servidor Dedicated Core que el resto del Módulo 4 amplía. Materializa la decisión de diseño anterior para la capa orientada al cliente de FinCorp: una clase Dedicated Core para garantizar un rendimiento predecible y para que su familia de CPU esté bajo nuestro control. El requisito previo es el Centro de Datos Virtual de FinCorp creado en la Unidad 3.1, en el que se coloca este servidor. Los detalles de almacenamiento e imagen se posponen deliberadamente hasta la Unidad 4.2, por lo que aquí solo se crea el servidor y se configuran su núcleo, RAM, familia de CPU y credenciales.

Objetivo de construcción: Aprovisionar una carcasa de servidor Dedicated Core (clase, núcleos/RAM, credenciales).

Pasos (en Data Center Designer):

1. Abra el VDC de FinCorp de la Unidad 3.1 en el Workspace. El procedimiento siguiente se aplica al modo Canvas; si aún no existe un centro de datos, créelo primero.
2. Desde la Palette, arrastre un elemento de servidor Dedicated Core al Canvas para añadirlo al VDC.
3. Seleccione el nuevo servidor para abrir el panel Inspector a la derecha, y asígnale un nombre único dentro del VDC (esta es su identidad para el resto del módulo).
4. Configure la arquitectura / familia de CPU. En Dedicated Core, esta es seleccionable; fije la familia en la que la capa está estandarizada. Tenga en cuenta que cambiar la familia más adelante requiere un reinicio, por lo que elija con deliberación.
5. Configure Núcleos y RAM. Manténgase dentro de los límites de Dedicated Core (hasta 62 núcleos, hasta 230 GB de RAM; la RAM se asigna en incrementos de 0.25 GB). Dimensione para la línea base de la capa, no para su pico, porque la escalabilidad horizontal gestionará los picos en la Unidad 4.3.
6. Bajo Autenticación, establezca la contraseña de root/administrador y/o adjunte una clave SSH (seleccione una desde SSH Key Manager, o pegue una clave pública ad hoc). Esta es la forma en que accederá al servidor una vez que se inicie.
7. Deje el almacenamiento y la imagen para la Unidad 4.2; no inicie aún desde una imagen. Haga clic en Provision Changes para aplicar, lo cual confirma la carcasa del servidor.

Errores comunes:

• Tratar la forma de la réplica de autoescalado como un ajuste en tiempo de ejecución. La configuración de cómputo de la plantilla de réplica (arquitectura de CPU, núcleos, RAM) se establece en tiempo de diseño y se aplica solo a nuevas réplicas, por lo que dimensione y defina la forma de la réplica deliberadamente antes de que el grupo se ejecute (Unidad 4.3).
• Tratar la familia de CPU como un ajuste en vivo. Cambiarla en Dedicated Core requiere un reinicio; prográmelo como mantenimiento planificado.
• Dimensionar la carcasa para su pico. Dimensione la línea base de Dedicated Core para la carga en estado estable y deje que la escalabilidad horizontal (Unidad 4.3) absorba los picos, en lugar de pagar por una única VM permanentemente grande.
• Olvidar que un servidor recién aprovisionado con más de 8 GB de RAM puede no iniciarse correctamente en el primer arranque hasta que se procese la memoria de trabajo; este es un comportamiento esperado, no una falla.

El punto arquitectónico que un atributo inmutable porta es visible incluso en una creación de CLI de una línea: la familia de CPU y la clase se establecen en la creación, y el cambio de familia más adelante es una operación con reinicio, no una edición gratuita.

ionosctl server create --datacenter-id "$FINCORP_VDC" \
  --name fincorp-app-01 --cpu-family INTEL_SKYLAKE --cores 4 --ram 8192

Resumen

La clase de cómputo en IONOS CLOUD es una decisión arquitectónica por nivel, impulsada por cuatro ejes: aislamiento de núcleos, control de familia de CPU, conexión de Block Storage y modelo operativo. Dedicated Core es la opción predeterminada cuando un nivel requiere una garantía de rendimiento, control de familia de CPU o elegibilidad para el autoescalado administrado; vCPU es la opción más económica cuando la contención es aceptable; y un Cube es una instancia de plantilla fija cuyo conjunto de vCPU/RAM/NVMe es inmutable, pero que aún puede conectar dispositivos adicionales de Block Storage. Decida la clase antes de dimensionar, porque las restricciones más importantes son las permanentes, y provisione la carcasa de Dedicated Core como la base sobre la que el resto del Módulo 4 se construye.

Puntos clave:

• Realice la decisión de cuatro vías (aislamiento, familia de CPU, conexión de almacenamiento en bloques, modelo operativo) por nivel, no por conjunto de recursos.
• VM Auto Scaling es solo horizontal: agrega y elimina réplicas completas bajo una política de métricas, y la configuración de cómputo de la réplica se fija en la plantilla de la réplica en el momento del diseño.
• La plantilla de un Cube (vCPU, RAM, NVMe) es inmutable y su NVMe no puede desconectarse, pero un Cube aún puede conectar hasta 23 dispositivos adicionales de Block Storage; la restricción es la plantilla fija, no la incapacidad de usar Block Storage.
• Un cambio de familia de CPU en Dedicated Core requiere un reinicio; trátelo como mantenimiento planificado.

Terminología importante:

• Servidor Dedicated Core: una VM asignada a un núcleo físico exclusivo (dos núcleos lógicos), con familia de CPU seleccionable.
• Servidor vCPU: una VM que comparte núcleos físicos; rentable, sin control de familia de CPU.
• Cube: una instancia de plantilla fija con un volumen NVMe conectado directamente de forma obligatoria; las propiedades de la plantilla son inmutables después del aprovisionamiento.
• Live Vertical Scaling (LVS): aumento o reducción de los recursos de una VM en ejecución, cubierto en detalle en la Unidad 4.3.

Lectura adicional

• Unidad 4.2: Imágenes, discos y Cloud-Init (amplía esta shell de servidor).
• Unidad 4.3: Elasticidad y VM Auto Scaling (cómo esta capa escala horizontalmente).
• Unidad 2.4: Arquitectura de costos y FinOps (el modelo de contención como la primera palanca de costos).