Unidad 4.1: Selección de clase de computación

Introducción

La clase de proceso no es una decisión de tamaño, es una decisión arquitectónica, y en IONOS Cloud se toma por nivel en lugar de por finca. La clase que elija fija cuatro cosas al mismo tiempo: si el Workload obtiene un núcleo físico exclusivo o lo comparte, si puede fijar la familia CPU, si puede adjuntar redes Block Storage, y quién lleva el modelo operativo. Una de esas decisiones es efectivamente permanente (la plantilla de un Cube es inmutable después de la provisión), por lo que obtener la clase correcta en el momento del diseño es más barato que cualquier solución alternativa posterior. Esta unidad hace que esa decisión sea explícita en las tres clases de proceso de IONOS Cloud, y finaliza con la provisión de la cáscara de Dedicated Core que las Unidades 4.2 y 4.3 extienden con almacenamiento, cloud-init y auto-escalado.

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

Cada clase de cómputo de IONOS responde las mismas cuatro preguntas de manera diferente. Mantenga estos cuatro ejes en mente y la clase casi se selecciona sola.

Aislamiento de núcleo. Un Dedicated Core Server se le asigna un núcleo físico dedicado, expuesto al sistema operativo invitado como dos núcleos lógicos (un núcleo físico con Hyper-Threading se presenta como dos hilos). Un vCPU Server comparte núcleos físicos con otros inquilinos. El aislamiento compra un rendimiento predecible bajo contienda; el intercambio de recursos compra un precio más bajo. Este es el modelo de contienda que la Unidad 2.4 enmarcó como el primer control de costos, ahora visto desde el lado del cómputo.

Control de la familia CPU. Solo Dedicated Core le permite seleccionar y cambiar más tarde la familia CPU (por ejemplo, fijar AMD EPYC para un Workload que se beneficia de ello, o estandarizar un nivel en Intel Xeon). En un vCPU Server, la familia no es seleccionable. Esto importa cuando un Workload es sensible a diferencias de conjunto de instrucciones o de reloj por núcleo, o cuando una licencia está vinculada a una familia CPU.

Conexión de almacenamiento en bloque. Dedicated Core y servidores vCPU conectan volúmenes de almacenamiento en bloque de red Block Storage (el disco de arranque y cualquier disco de datos viven en la trama de bloque iSCSI, cubierta en la Unidad 4.2). Un Cube se envía con un NVMe Volume de conexión directa obligatorio que forma parte de su plantilla fija. El modelo de conexión decide cómo realiza el ciclo de vida del almacenamiento, las instantáneas y el cambio de tamaño.

Modelo operativo y SLA. Un Dedicated Core o vCPU Server es una instancia de 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 establece las tres clases frente a los ejes que impulsan la decisión.

Un Dedicated Core Server se puede configurar hasta 62 núcleos y 230 GB RAM. El RAM se asigna en incrementos de 0,25 GB. Estos techos rara vez limitan un solo nivel, pero importan cuando se está dimensionando un monolito grande antes de decidir si dividirlo.

1.1 Dedicated Core: el valor predeterminado para los niveles que necesitan una garantía

Elija Dedicated Core cuando el nivel necesita un rendimiento predecible bajo carga o cuando necesita fijar o cambiar la familia CPU. El núcleo físico exclusivo es lo que compra la garantía de rendimiento bajo contienda, y el control de la familia CPU es único en esta clase. Cuando un nivel también se escalará horizontalmente, su configuración de cómputo de réplica (arquitectura CPU, núcleos y RAM) se establece en el momento del diseño en la plantilla de réplica VM Auto Scaling (Unidad 4.3), por lo que establecer la forma de cómputo del nivel temprano todavía produce dividendos. El costo del núcleo exclusivo es el precio que se paga por la garantía de rendimiento.

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

1.2 vCPU: rentable donde se acepta la contienda

Un vCPU Server se provisiona y se comporta como cualquier otro VM, pero comparte núcleos físicos, lo que lo hace el valor predeterminado rentable para entornos de desarrollo y prueba, servicios de software internos esenciales y niveles donde se acepta la contienda ocasional. Admite escalado vertical en vivo como Dedicated Core, pero no puede seleccionar una familia CPU. La regla de decisión es simple: si el nivel no necesita una garantía de rendimiento ni control de la familia CPU, un vCPU Server es la elección correcta más barata.

1.3 Cubes: la instancia de plantilla fija, no un punto muerto de almacenamiento

Un Cube es una instancia de configuración fija: vCPU, RAM y un NVMe Volume de conexión directa vienen como una plantilla empaquetada, y no puede cambiar esas propiedades de la plantilla después de la provisión. El NVMe Volume está conectado a través de PCI Express en el servidor físico y es de software-RAID de una sola redundancia; ocupa uno de los slots de dispositivos de la instancia y no se puede desmontar ni eliminar mientras exista el Cube. Las plantillas básicas van desde Basic-Cube-XS (1 vCPU, 2 GB RAM, 60 GB NVMe) hasta Basic-Cube-XL (16 vCPU, 32 GB RAM, 960 GB NVMe); las plantillas de memoria intercambian núcleos por RAM (por ejemplo, Memory-Cube-XL con 16 vCPU y 64 GB RAM).

Aquí está la trampa, y funciona en la dirección opuesta a una suposición común. Un Cube a menudo se descarta como incapaz de utilizar Block Storage. Eso es incorrecto: un Cube admite hasta 23 dispositivos HDD o SSD (Estándar o Premium) Block Storage adicionales, además de su NVMe Volume obligatorio, y esos dispositivos adicionales se pueden desmontar y eliminar en cualquier momento después de la provisión. La verdadera restricción es diferente y más específica: la plantilla en sí (vCPU, RAM y tamaño NVMe) es inmutable, y el NVMe Volume no se puede desconectar. Eliminar un Cube elimina su NVMe Volume, así que realice una Snapshot primero si los datos deben sobrevivir. Entonces, la regla de diseño honesta es: elija un Cube cuando su paquete fijo coincide con el Workload y desea un artículo predecible único, y planifique los datos persistentes en volúmenes Block Storage adicionales que sobreviven a la plantilla, no en el disco NVMe inmutable.

2. Clase por nivel como patrón

La unidad de la decisión de la clase de cómputo es el nivel, no la aplicación. Un diseño empresarial en capas (la forma pública-L7-hasta-cómputo-estadístico-hasta-privado-L4-hasta-privado-datos desde la Unidad 1.2) mezcla rutinariamente clases: Dedicated Core para el nivel que debe escalarse y mantener una garantía de rendimiento, vCPU para niveles internos o no críticos, y un Cube donde un paquete fijo es una buena opción. Donde un Workload necesita una plataforma gestionada de un solo inquilino (por ejemplo, un patrimonio VMware regulado), eso es el Dedicated VMware Private Cloud tratado en la Unidad 4.4, no una clase de cómputo Public Cloud. Mezclar clases por nivel es la norma, no un compromiso.

Dos reglas de diseño se derivan de esto y vale la pena expresarlas claramente, porque ambas son fáciles de equivocar bajo presión de tiempo:

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

Para FinCorp, la empresa de servicios financieros regulada alemana que se utiliza en este curso, el nivel de aplicación orientado al cliente es el que más probablemente enfrentará una carga variable y el que está más expuesto al equilibrador de carga de capa 7 público. Ese nivel se provisiona como Dedicated Core para una garantía de rendimiento predecible bajo carga y, por lo tanto, su familia CPU se puede estandarizar para un rendimiento coherente, y es el nivel que más tarde se escalona horizontalmente bajo una política métrica (Unidad 4.3). El nivel de informes por lotes interno de FinCorp, por otro lado, tolera la contienda y se provisiona como vCPU para ahorrar costos. El ángulo de cumplimiento refuerza esto: BSI C5 (la acreditación de tipo 1 del 7 de noviembre de 2023) y IT-Grundschutz (el certificado ISO 27001 del 14 de septiembre de 2022) ambos abarcan Compute Engine, por lo que las clases estándar VM se encuentran dentro del sobre de acreditación de FinCorp. El patrimonio VMware regulado es una decisión separada tratada por el Dedicated VMware Private Cloud en la Unidad 4.4.

Consideraciones de diseño

• Costo. El núcleo exclusivo de Dedicated Core es el premio que paga por una garantía de rendimiento y elegibilidad para el auto-escalado. Donde ninguna de estas características es necesaria, vCPU es la respuesta correcta más barata; no compre aislamiento que una capa no necesite.
• Operaciones. La decisión permanente (una plantilla inmutable de Cube) conlleva el mayor costo operativo cuando es incorrecta, porque corregirla significa reconstruir en lugar de reconfigurar. Dedique el mayor cuidado de diseño aquí.
• Escalabilidad. La escalada vertical (crecer en vivo CPU y RAM) está disponible en Dedicated Core y vCPU dentro de los límites cubiertos en la Unidad 4.3; la escalada horizontal gestionada agrega y elimina réplicas completas bajo una política métrica, con la configuración de cómputo de réplica fija en la plantilla de réplica en el momento del diseño. Decida sobre qué eje una capa escalará antes de elegir su clase.

DCD Implementación paso a paso

Esta implementación proporciona la cáscara de Dedicated Core Server que la REST del Módulo 4 extiende. Se realiza la decisión de diseño anterior para el nivel de enfrentamiento al cliente de FinCorp: una clase de núcleo dedicado para una garantía de rendimiento predecible y, por lo tanto, su familia 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 y imagen se han pospuesto deliberadamente hasta la Unidad 4.2, por lo que aquí creamos el servidor y establecemos solo su núcleo, RAM, familia CPU y credenciales.

Objetivo de creación: Proporcionar una cáscara de Dedicated Core Server (clase, núcleos/RAM, credenciales).

Pasos (en el Data Center Designer):

1. Abra el centro de datos virtual de FinCorp de la Unidad 3.1 en el Área de trabajo. El procedimiento a continuación se aplica al modo Canvas; si no existe un centro de datos, créelo primero.
2. Desde la Paleta, arrastre un elemento de servidor de Núcleo Dedicado al Canvas para agregarlo al centro de datos virtual.
3. Seleccione el nuevo servidor para abrir el panel Inspector en la derecha y asígnale un nombre único dentro del centro de datos virtual (esta es su identidad para la REST del módulo).
4. Establezca la arquitectura/familia CPU. En Núcleo Dedicado, esta es seleccionable; fije la familia que se ha estandarizado para el nivel.
5. Establezca Núcleos y RAM. Manténgase dentro de los límites de Núcleo Dedicado (hasta 62 núcleos, hasta 230 GB de RAM; el RAM se asigna en incrementos de 0,25 GB). Tamaño para la línea de base del nivel, no para su pico, porque la escalabilidad horizontal manejará los picos en la Unidad 4.3.
6. En Autenticación, establezca la contraseña de root/administrador y/o adjunte una clave SSH (seleccione una de la 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 desde una imagen todavía. Haga clic en Provisionar cambios para aplicar, lo que compromete la cáscara del servidor.

Errores comunes:

• Tratar la forma de réplica de escalado automático como un control de tiempo de ejecución. La configuración de cómputo de la plantilla de réplica (arquitectura CPU, núcleos, RAM) se establece en el momento del diseño y solo se aplica a nuevas réplicas, así que tamaño y forma de la réplica deliberadamente antes de que el grupo se ejecute (Unidad 4.3).
• Tratar la familia CPU como un control en vivo. Cambiarla en Núcleo Dedicado requiere un reinicio; prográmelo como mantenimiento planificado.
• Sobredimensionar la cáscara hasta su pico. Tamaño la línea de base de Núcleo Dedicado para la carga de estado estable y deje que la escalabilidad horizontal (Unidad 4.3) absorba los picos, en lugar de pagar por un solo VM permanentemente grande.
• Olvidar que un servidor recién aprovisionado con más de 8 GB de RAM puede no iniciarse limpiamente en el primer arranque hasta que la memoria de trabajo se procese; este es un comportamiento esperado, no una falla.

El punto arquitectónico de que un atributo inmutable lleva es visible incluso en una línea de CLI de creación: la familia CPU y la clase se establecen en la creación, y el cambio de familia posterior es una operación que requiere un 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 computación en IONOS Cloud es una decisión arquitectónica por nivel, impulsada por cuatro ejes: aislamiento de núcleo, control de la familia CPU, conexión de Block Storage y modelo operativo. Dedicated Core es el valor predeterminado cuando un nivel requiere una garantía de rendimiento, control de la familia CPU o elegibilidad para el escalado automático gestionado; vCPU es la opción más asequible cuando se acepta la contención; y un Cube es una instancia de plantilla fija cuyo paquete vCPU/RAM/NVMe es inmutable, pero que aún así puede conectar dispositivos Block Storage adicionales. Decida la clase antes de dimensionar, porque las restricciones más consecuentes son las permanentes, y proporcione la shell de Dedicated Core como base sobre la que se construye el REST del Módulo 4.

Puntos clave:

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

Terminología importante:

• Dedicated Core Server: un VM que se le da un núcleo físico exclusivo (dos núcleos lógicos), con familia CPU seleccionable.
• vCPU Server: un VM que comparte núcleos físicos; rentable, sin control de la familia CPU.
• Cube: una instancia de plantilla fija con un NVMe Volume de conexión directa obligatoria; las propiedades de la plantilla son inmutables después de la provisión.
• Escalado Vertical en Vivo (LVS): crecer o disminuir los recursos de un VM en ejecución, cubierto en profundidad 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 este nivel se escala horizontalmente).
• Unidad 2.4: Arquitectura de costes y FinOps (el modelo de contención como el primer elemento de control de costes).