Verificación de conocimientos - Cómputo y elasticidad
Un arquitecto espera que VM Auto Scaling gestione una carga de trabajo de una sola VM en crecimiento, agregando CPU y RAM a las réplicas en ejecución a medida que aumenta la carga. ¿Por qué este es el modelo mental equivocado del servicio?
VM Auto Scaling es horizontal: inicia y termina réplicas completas para ajustarse a una política de métrica, y los cambios en la configuración de la réplica solo afectan a las réplicas nuevas, nunca a la flota en ejecución. Aumentar la CPU y la RAM de una sola VM es Live Vertical Scaling, un mecanismo separado con sus propios límites (el límite de hotplug de RAM de 240 GB, y el redimensionamiento hacia abajo de CPU/RAM que requiere reinicio). Las opciones incorrectas inventan comportamientos de redimensionamiento parcial que el servicio no posee.
Un arquitecto está eligiendo una clase de cómputo para una carga de trabajo que encaja perfectamente en un paquete fijo de vCPU, RAM y NVMe, pero cuyos datos de negocio persistentes deben sobrevivir a las reconstrucciones de instancias. Un compañero de equipo argumenta que un Cube no es adecuado porque "los Cubes no pueden usar Block Storage". ¿Cómo debería responder el arquitecto?
Un Cube se entrega con una plantilla NVMe obligatoria e inmutable, pero también puede adjuntar dispositivos adicionales de Block Storage HDD/SSD. Por lo tanto, los datos persistentes deben ubicarse en esos volúmenes y no en el disco NVMe, que se elimina junto con la instancia. La restricción real es que la plantilla (vCPU, RAM, NVMe) es fija después de la aprovisionamiento, no que el Cube no pueda usar Block Storage. Por lo tanto, el diseño correcto utiliza volúmenes adicionales para los datos que deben sobrevivir.
FinCorp necesita colocar un disco de arranque y datos de una base de datos de una sola VM en Block Storage y desea que el volumen entregue todo su rendimiento nominal de SSD. ¿Qué decisión de diseño determina de manera más directa si el SSD funcionará como se espera?
El rendimiento de SSD en IONOS CLOUD Block Storage escala con el tamaño del volumen, e IONOS CLOUD recomienda al menos 100 GB para alcanzar el rendimiento completo, que es exactamente la razón por la cual se desaconsejan los SSD de menos de 100 GB para cargas de trabajo de base de datos. Las opciones incorrectas invierten la relación de tamaño entre HDD/SSD (HDD es independiente del tamaño), malinterpretan las zonas de disponibilidad e invocan una replicación entre regiones administrada que no existe para Block Storage.
Un arquitecto está ajustando un grupo de VM Auto Scaling cuyas réplicas tardan varios minutos en iniciarse y calentarse. En las pruebas, el grupo aumenta repetidamente su capacidad y, a continuación, la reduce de inmediato, oscilando bajo una carga constante. ¿Qué elección de configuración estabiliza mejor el grupo?
La oscilación se previene mediante los dos controles anti-oscilación: un tiempo de espera lo suficientemente largo para que las nuevas réplicas se calienten y asuman la carga, y una separación obligatoria entre los umbrales de reducción y aumento de capacidad que crea una banda muerta. Un tiempo de espera más corto empeora el exceso de escalado, un grupo puede tener solo una política de métricas, y no existe escalado a cero porque el límite inferior es de una réplica.
FinCorp debe ejecutar su gran parque existente de VMware bajo una estricta soberanía de la UE, al tiempo que transfiere el ciclo de vida de la plataforma fuera de sus propios equipos, y también desea nuevas cargas de trabajo elásticas en el edge. ¿Qué enfoque se ajusta mejor a estas restricciones?
Un Private Cloud de VMware dedicado permite a FinCorp mantener su modelo operativo de VMware, mientras que IONOS CLOUD asume la responsabilidad del ciclo de vida de la plataforma. Además, dado que el plano de control es operado en la UE, se preserva la soberanía, a diferencia de un servicio de VMware operado en Estados Unidos en una región de la UE, que seguiría presentando exposición a la CLOUD Act, independientemente de la ubicación de los datos. El patrón híbrido coloca el parque regulado en VMware dedicado y las nuevas cargas de trabajo elásticas en la computación estándar, en lugar de forzar un replataformado completo y costoso o permanecer completamente en las instalaciones.