Verificación de conocimientos - Operaciones, resiliencia y rendimiento
Un arquitecto debe proporcionar al servicio adyacente a pagos de FinCorp un conmutación por error automatizada entre dos zonas de disponibilidad. El equipo pregunta qué producto gestionado de IONOS CLOUD orquesta la conmutación por error mediante la supervisión del nodo primario, la declaración de su caída y la promoción del nodo secundario en toda la pila. ¿Cuál es la respuesta correcta y cuál es el mecanismo real de conmutación por error automatizado de la plataforma?
IONOS CLOUD no vende un producto de conmutación por error gestionado que orqueste la promoción en toda la pila. El mecanismo automatizado nativo combina las comprobaciones de estado del plano del Load Balancer, que deciden el estado de los puntos finales dentro de una zona, con un registro de Cloud DNS con TTL bajo que se reorienta para mover el tráfico manipulando la resolución de nombres. Cloud DNS en sí mismo no es consciente del estado. No existe un asistente empaquetado de "registro de conmutación por error mediante comprobación de estado" en la consola de Cloud DNS; cuando la conmutación debe ser automática en la capa de DNS, se gestiona a través de la API de Cloud DNS. El Load Balancer solo reenvía a destinos sanos, pero no promueve una pila en espera, y Auto Scaling reemplaza instancias dentro de un nivel en lugar de orquestar la conmutación por error entre zonas.
Un equipo coloca un nodo principal de base de datos y su nodo de reserva en el mismo VDC y deja que la plataforma asigne las zonas de disponibilidad automáticamente, asumiendo que una zona asignada automáticamente les proporciona redundencia multi-zona. El arquitecto señala esto como la trampa de la zona automática. ¿Por qué es incorrecta la suposición y cuál es la disciplina correcta?
La asignación automática de zonas no es una garantía multi-AZ. Puede colocar a ambos miembros de un par redundante en la misma zona, lo que significa que una falla de una sola zona elimina a ambos y la redundencia es ilusoria. La disciplina consiste en asignar zonas explícitas y distintas a cada miembro de un par redundante: el nodo de reserva de la base de datos se ubica en una zona nombrada diferente a la del nodo principal, y la computación de tipo pilot-light se aprovisiona en una zona nombrada distinta a la capa de producción. Esto tiene un costo bajo en el momento del diseño y no puede integrarse de manera limpia después de que una interrupción demuestre que el par estaba co-ubicado.
FinCorp distribuye las cargas de trabajo de producción, no producción y de cumplimiento aislado en contratos separados, y también ejecuta clústeres de Managed Kubernetes. El equipo de operaciones espera un panel administrado único que unifique 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 canalizaciones de monitorización y registros son por contrato y por región, y el Activity Log es por contrato sin un punto de agregación, por lo que no existe un panel nativo que unifique la telemetría entre contratos separados; la agregación se construye enviando la señal de cada contrato a un colector externo. Por otro lado, la fuente "Kubernetes" en el Logging Service se refiere a los registros de las cargas de trabajo y de los nodos dentro del clúster que usted envía, no al plano de control administrado; los eventos del plano de control nunca se emiten en la canalización del Logging Service. La opción separada "Logging to S3" del clúster escribe los datos de registros del clúster en un bucket y no constituye la visibilidad del plano de control en su panel de monitorización.
La base de datos de transacciones reguladas de FinCorp solo contiene unas pocas decenas de gigabytes de datos activos, y un ingeniero propone aprovisionarla en un volumen SSD de 40 GB para que coincida con la pequeña huella de datos. El arquitecto rechaza esta propuesta. ¿Cuál es el razonamiento correcto para dimensionar el volumen?
El rendimiento de SSD escala con el tamaño del volumen hasta un límite, acumulándose por gigabyte, por lo que un volumen SSD pequeño deja sin recursos una carga de trabajo exigente. La plataforma recomienda reservar volúmenes SSD de al menos 100 GB para obtener el beneficio completo, y para las cargas de trabajo de base de datos, este umbral aproximado de 100 GB es fundamental: un volumen SSD por debajo de él degrada un nivel de base de datos incluso cuando el conjunto de datos es pequeño. Por lo tanto, el volumen se dimensiona primero para el rendimiento y segundo para la capacidad. Es HDD, no SSD, cuyo rendimiento es constante e independiente del tamaño del volumen, y Data Center Designer deriva el rendimiento previsto a partir del tamaño del volumen en lugar de garantizar el límite superior en cualquier tamaño.
FinCorp debe migrar un gran entorno VMware a IONOS CLOUD. El plan del proyecto asume un asistente nativo de importación OVF/OVA para las VM y un conmutado basado en replicación para las bases de datos que se trasladan a IONOS CLOUD Managed PostgreSQL. El arquitecto rechaza ambas suposiciones. ¿Cuál de las siguientes descripciones del enfoque de ingeniería correcto es precisa?
IONOS CLOUD no tiene un asistente nativo de importación OVF/OVA, por lo que la migración se diseña, no se importa, y el arquitecto elige una de tres vías honestas por carga de trabajo: conversión y carga de imágenes a la superficie de Public Cloud KVM, replicación nativa de VMware y conmutación por error en vivo hacia un Private Cloud dedicado, o copia de seguridad y restauración. En la vía de Private Cloud, una VPN de capa 2 extiende un segmento entre sitios para que las oleadas escalonadas conserven sus direcciones IP, mientras que la movilidad en vivo entre hosts es solo intraclúster y nunca es un traslado en vivo entre sitios. La oleada de bases de datos es un conmutado duro mediante volcado y restauración con una ventana real de tiempo de inactividad, porque no existe un conmutado nativo basado en replicación hacia las bases de datos gestionadas; la fuente permanece como autoridad hasta que el destino restaurado se valida.