Verificación de conocimientos - Operaciones, Resiliencia y Rendimiento
Un arquitecto debe dar a FinCorp un servicio de pago automatizado con conmutación por error entre dos zonas de disponibilidad. El equipo pregunta qué producto gestionado de IONOS orquesta la conmutación por error observando el primario, declarándolo muerto y promoviendo el secundario en toda la pila. ¿Cuál es la respuesta correcta y cuál es el mecanismo de conmutación por error automatizado real de la plataforma?
IONOS no vende un producto de conmutación por error gestionado que orqueste la promoción en toda la pila. El mecanismo automatizado nativo compone las comprobaciones de salud del plano de equilibrio de carga, que deciden la salud del punto de conexión dentro de una zona, con un registro Cloud DNS de baja TTL que se reorienta para mover el tráfico manipulando la resolución de nombres. El propio Cloud DNS no es consciente de la salud. No hay un asistente de "registro de conmutación por error de comprobación de salud" empaquetado en la consola de Cloud DNS; donde el corte debe ser automático en la capa de DNS, se realiza a través del Cloud DNS API. El Load Balancer solo reenvía a objetivos saludables, pero no promueve una pila de espera, y Auto Scaling reemplaza instancias dentro de un nivel en lugar de orquestar la conmutación por error entre zonas.
Un equipo coloca una base de datos principal Node y su base de datos de respaldo en el mismo VDC y deja que la plataforma asigne zonas de disponibilidad automáticamente, asumiendo que una zona asignada automáticamente les da redundancia multi-zona. El arquitecto señala esto como la trampa de la zona automática. ¿Por qué es incorrecta esta suposición y cuál es la disciplina correcta?
La asignación automática de zona no es una garantía de multi-AZ. Puede colocar a ambos miembros de una pareja redundante en la misma zona, lo que significa que una falla de zona única puede eliminar ambos y la redundancia es ilusoria. La disciplina es asignar zonas explícitas y distintas a cada miembro de una pareja redundante: la base de datos de respaldo Node se encuentra en una zona con nombre diferente a la principal, y la computadora de pilotaje se provisiona en una zona con nombre distinto de la capa de producción. Esto es barato en el momento del diseño y no se puede retroajustar limpiamente después de que una interrupción demuestre que la pareja estaba ubicada en el mismo lugar.
FinCorp divide la producción, no producción y un Workload aislado por cumplimiento en contratos separados, y también ejecuta clusters de Managed Kubernetes. El equipo de operaciones espera un panel administrado único que una toda la telemetría y espera que los eventos del plano de control de Kubernetes lleguen al Logging Service junto con los registros de la aplicación. ¿Cuál de las siguientes afirmaciones describe correctamente los límites de observabilidad que deben diseñar?
Las tuberías de monitoreo y registro son por contrato y por región, y el Registro de actividad es por contrato sin un punto de agregación, por lo que no hay un panel nativo que una la telemetría en contratos separados; la agregación se construye canalizando la señal de cada contrato en un colector externo. Por separado, la fuente "Kubernetes" en el Logging Service significa que los registros de Workload y Node dentro de Cluster los envía usted mismo, no el plano de control administrado; los eventos del plano de control nunca se emiten en la tubería de Logging Service. El toggle "Registro en S3" separado del Cluster escribe los datos de registro de Cluster en un bucket y no es visibilidad del plano de control en su panel de monitoreo.
La base de datos de transacciones reguladas de FinCorp contiene solo unos pocos decenas de gigabytes de datos en vivo, y un ingeniero propone aprovisionarla en un SSD Volume de 40 GB para coincidir con la pequeña huella de datos. El arquitecto anula esta decisión. ¿Cuál es el razonamiento correcto para dimensionar el Volume?
El rendimiento de SSD se escala con el tamaño de Volume hasta un límite, acumulándose por gigabyte, por lo que un SSD Volume pequeño priva a una base de datos exigente Workload. La plataforma recomienda reservar volúmenes de SSD de al menos 100 GB para obtener el beneficio completo, y para cargas de trabajo de base de datos este piso de aproximadamente 100 GB es fundamental: un SSD Volume por debajo de él degrada un nivel de base de datos incluso cuando el conjunto de datos es pequeño. El Volume, por lo tanto, se dimensiona para el rendimiento primero y la capacidad en segundo lugar. Es HDD, y no SSD, cuyo rendimiento es plano y es independiente del tamaño de Volume, y el Data Center Designer deriva el rendimiento predicho del tamaño de Volume en lugar de garantizar el techo en cualquier tamaño.
FinCorp debe migrar una gran VMware a IONOS. El plan del proyecto supone un asistente de importación nativo OVF/OVA para las máquinas virtuales y un corte por replicación para las bases de datos que se trasladan a IONOS Managed PostgreSQL. El arquitecto rechaza ambas suposiciones. ¿Cuál es la descripción del enfoque de ingeniería correcto?
IONOS no tiene un asistente de importación nativo OVF/OVA, por lo que la migración se ingeniera, no se importa, y el arquitecto elige uno de los tres caminos honestos según Workload: conversión de imagen y carga en la superficie KVM Public Cloud, replicación y conmutación por error nativa de VMware en Private Cloud dedicado, o copia de seguridad y restauración. En el camino de Private Cloud, una capa 2 VPN extiende un segmento entre sitios para que las olas faseadas mantengan sus direcciones IP, mientras que la movilidad en vivo entre hosts es solo dentro de Cluster y nunca es un movimiento en vivo entre sitios. La ola de bases de datos es un corte duro de volcado y restauración con una ventana de tiempo de inactividad real, porque no hay un corte por replicación nativo en las bases de datos gestionadas; la fuente permanece autoritativa hasta que el objetivo restaurado valida.