Unidad 7.1: Resiliencia y continuidad del negocio

Introducción

La resiliencia no es un producto que se compra en IONOS CLOUD; es una propiedad que se compone. La plataforma le ofrece zonas de disponibilidad, una capa de equilibrador de carga con verificación de estado, un servicio de DNS anycast, recuperación de bases de datos en un punto en el tiempo y un servicio de copia de seguridad, pero no vende un único botón de "failover" que orqueste todos estos elementos. Esa ausencia es el hecho de diseño central de esta unidad. Su labor como arquitecto consiste en traducir un requisito de continuidad del negocio en una disposición de estos elementos básicos y, a continuación, demostrar que funciona.

Esta unidad concluye construyendo la mitad de dirección de dicha disposición en Data Center Designer: un par de registros de Cloud DNS con TTL bajo, orquestados por el cliente, en dos zonas, junto con la etapa de validación que confirma que un failover realmente desplaza el tráfico. Cloud DNS no realiza verificaciones de estado por sí mismo, por lo que la verificación de estado que impulsa dicho cambio es una que usted debe proporcionar. La construcción refuerza lo que provisionó en las unidades 3.6 y 3.7 (conectividad híbrida y DNS), ahora visto a través de una lente de recuperación ante desastres. FinCorp, nuestra empresa alemana de servicios financieros sujeta a las obligaciones del RGPD y del BSI, ancla cada decisión: se trata de un servicio adyacente a pagos cuyos objetivos de continuidad están dictados por un regulador, no por una preferencia de ingeniería.

1. RTO, RPO y las tres estrategias de recuperación

Dos números rigen todo diseño de continuidad, y la empresa es la propietaria de ambos. El objetivo de tiempo de recuperación (RTO) es el tiempo máximo que el servicio puede estar caído antes de que la interrupción cause daños materiales. El objetivo de punto de recuperación (RPO) es la cantidad de datos, medida en tiempo, que se puede permitir perder. Un arquitecto que elige estos números ha tomado una decisión de negocio sin autoridad. La función de riesgos y cumplimiento de FinCorp los establece; usted diseña para cumplirlos y declara con honestidad cuánto cuesta cada objetivo.

Estos dos puntos de referencia seleccionan una estrategia de recuperación. Tres estrategias abarcan el espectro de costo frente a velocidad, y cada una se ajusta claramente a las primitivas de IONOS CLOUD.

La estrategia es tanto una decisión de presupuesto como una decisión de disponibilidad. Activo-activo duplica la huella en ejecución y exige la replicación de datos más estricta; copia de seguridad y restauración es económica pero lenta para recuperar y pierde más datos. El servicio de pagos adyacente de FinCorp no puede tolerar un RTO de varias horas, por lo que copia de seguridad y restauración queda descalificada como estrategia principal para esa capa, aunque sigue siendo la respuesta correcta para las cargas de trabajo de informes y archivo de la empresa. El diseño realista de FinCorp es piloto encendido para el núcleo regulado: un clúster de base de datos siempre activo con un nodo en espera, cómputo preplantillado que escala hacia arriba en conmutación por error, y DNS para redirigir.

Una verdad crítica de la plataforma atraviesa las tres estrategias. El Backup Service (Acronis) cubre VMs y Block Storage; no realiza copias de seguridad de bases de datos administradas, y no proporciona copias de seguridad inmutables. La continuidad de bases de datos es, por lo tanto, un mecanismo separado: recuperación en punto en el tiempo dentro de la ventana de retención del clúster, más volcado y restauración para todo lo que exceda dicha ventana. Tratar el Backup Service como su plan de recuperación ante desastres para bases de datos es el error más costoso en este ámbito, porque descubre la brecha solo durante una recuperación real. Las Snapshots agravan la confusión: una Snapshot de Block Storage es una reversión a nivel de VM, local a la región y no incremental, no una copia de seguridad coherente con la base de datos. Planifique el plano de continuidad de datos alrededor de PITR y volcado/restauración para las capas de datos, y alrededor del Backup Service solo para las VMs y volúmenes que realmente cubre.

2. Colocación multi-zona y la trampa de Auto-Zona

La resiliencia comienza con la ubicación física de los recursos. IONOS CLOUD expone las zonas de disponibilidad como la primitiva de colocación, y la redundancia que se obtiene depende por completo de colocar recursos emparejados en zonas diferentes. La plataforma no inferirá su intención.

Observe una asimetría que sorprende a los arquitectos. Las zonas de disponibilidad de cómputo son Zona 1, Zona 2 y Auto. Las zonas de disponibilidad de Block Storage son Zona 1, Zona 2, Zona 3 y Auto. No existe una Zona 3 de cómputo, por lo que un volumen colocado en la Zona 3 no tiene un servidor en la misma zona al que pueda adjuntarse. Para un par redundante de cómputo y almacenamiento, diseñe dentro de las zonas que ambos planos comparten.

La trampa reside en la palabra "Auto". Seleccionar la zona de disponibilidad Auto es una indicación de colocación en una sola zona de disponibilidad que permite a IONOS CLOUD elegir una zona por usted; no es una instrucción de multi-zona ni de "distribuir entre zonas". Si crea dos servidores destinados a formar un par de alta disponibilidad y deja ambos en Auto, no hay garantía de que se coloquen en zonas diferentes, y es posible que compartan una misma zona. Un dominio de fallo compartido es exactamente lo que un par de alta disponibilidad debe eliminar. La regla es inequívoca: para cualquier par que deba sobrevivir a un fallo de zona, establezca zonas explícitas y diferentes. Auto es aceptable para un recurso único, no emparejado, donde no tiene preferencia de zona; es incorrecto para la redundancia.

Para FinCorp, esto significa que el nodo de base de datos en espera se ubica en una zona explícitamente diferente de la primaria, y la plantilla de cómputo de tipo piloto se aprovisiona en una zona nombrada distinta de la capa de producción. La disciplina de zonas explícitas es de aplicación sencilla en la fase de diseño y resulta imposible de implementar de manera limpia después de que una interrupción demuestre que el par estaba colocalizado.

3. Enrutamiento basado en el estado de salud: comprobaciones de salud de Load Balancer, conmutación por error de IP y DNS orquestado por el cliente

IONOS CLOUD no vende un producto de conmutación por error gestionado. No existe un orquestador que supervise un nodo primario, declare que ha fallado y promueva un nodo secundario en toda la pila, ni un servicio gestionado de conmutación por error entre zonas o entre sitios. Es importante ser preciso sobre qué primitiva realiza el enrutamiento consciente del estado de salud, porque no es Cloud DNS.

Las primitivas automatizadas de enrutamiento basado en el estado de salud de la plataforma son dos. En primer lugar, comprobaciones de salud del Load Balancer: el Managed Application Load Balancer realiza activamente comprobaciones de salud de sus destinos de backend mediante TCP o HTTP, mientras que el Managed Network Load Balancer realiza comprobaciones de salud de sus destinos solo mediante TCP (las comprobaciones de salud conscientes de HTTP son una capacidad exclusiva del ALB); ambos admiten intervalos y reintentos configurables y desvían el tráfico de los destinos no saludables dentro de la propia piscina de backend del Load Balancer. Esta es una conmutación por error automatizada real, pero tiene un alcance limitado a la región y a la LAN: mueve el tráfico entre destinos dentro de una sola piscina, no entre zonas o sitios. En segundo lugar, grupos de conmutación por error de IP: una IP reservada compartida entre VM en una LAN, destinada a la conmutación por error a nivel de aplicación construida por el cliente; esta también es local a la LAN. La colocación multizona (sección 2) es la tercera pata, pero se trata de colocación, no de enrutamiento.

La conmutación por error entre zonas y entre sitios se sitúa por encima de todas estas primitivas, y aquí no existe ningún mecanismo nativo consciente del estado de salud. Cloud DNS no es consciente del estado de salud: no monitoriza el estado de los puntos finales y no modifica un registro por sí mismo. Por lo tanto, la conmutación por error entre zonas la orquesta el cliente: su propia comprobación de salud (un monitor externo o una señal derivada del estado de salud del Load Balancer) detecta que el punto final de una zona ha fallado y llama a la API de Cloud DNS para redirigir un registro con TTL bajo hacia la zona saludable. La contribución de Cloud DNS es que el registro es anycast, está respaldado por un SLA y puede tener un TTL muy bajo; la automatización de detección y redirección es responsabilidad del cliente. Esta es la sustitución de conmutación por error introducida en la Unidad 1.3, realizada de forma honesta: combine una primitiva consciente del estado de salud (el Load Balancer dentro de una zona) con una redirección DNS de TTL bajo entre zonas impulsada por el cliente.

Cloud DNS es adecuado para la mitad DNS de esa composición. Funciona en una red anycast a través de 14 puntos de presencia, tiene un SLA de disponibilidad por servicio del 99,995 por ciento y admite un TTL tan bajo como 60 segundos. Ese límite inferior de TTL es la palanca dominante de RTO para cualquier conmutación por error basada en DNS, porque un resolver seguirá utilizando una respuesta en caché hasta que expire el TTL. Si su registro tiene un TTL de una hora, su recuperación impulsada por DNS no podrá ser más rápida de una hora, sin importar lo rápido que detecte el fallo. Reduzca el TTL de los registros que participan en la conmutación por error y acepte el modesto aumento del volumen de consultas como el precio de una conmutación más rápida.

Dos restricciones honestas determinan cómo construye esto. En primer lugar, DNS solo dirige nuevas conexiones. Un cliente que ya mantiene una conexión con el punto final fallido no se ve afectado por un cambio de DNS; debe reconectar, momento en el que resuelve la nueva dirección. Por esta razón, las capas de aplicación detrás de una conmutación por error DNS deben ser sin estado, con el estado de sesión y el estado compartido externalizados a la capa de memoria en lugar de mantenerse en la instancia. En segundo lugar, la capacidad de comprobación de salud reside en el plano del Load Balancer (o en su propio monitor externo), nunca en Cloud DNS: no existe un tipo de registro de conmutación por error basado en comprobaciones de salud, porque Cloud DNS no realiza comprobaciones de salud en absoluto. En la práctica, compone los planos: un Load Balancer determina el estado de salud dentro de una zona, y una llamada a la API impulsada por el cliente redirige el registro DNS entre puntos finales a nivel de zona. Dado que esa conmutación entre zonas debe ser impulsada por sus herramientas de monitorización u orquestación y no por Cloud DNS, trate la actualización del registro como un diseño a nivel de API, no como un asistente de consola de clics; la ruta de la consola es la gestión de zonas y registros, y Cloud DNS nunca desencadena el cambio por sí mismo.

4. Dos planos: direccionamiento y continuidad de datos

Un diseño de resiliencia duradero mantiene separadas dos preocupaciones, porque fallan y se recuperan en escalas de tiempo diferentes y mediante mecanismos distintos.

El plano de direccionamiento de tráfico decide a dónde van las solicitudes. Está compuesto por registros de Cloud DNS, configuraciones de TTL y las comprobaciones de estado del balanceador de carga que determinan la salud de los puntos finales. Su función es desviar rápidamente las nuevas conexiones de una ubicación fallida. Su velocidad de recuperación está limitada por el valor mínimo de TTL y por los intervalos de comprobación de estado, no por la velocidad a la que se pueden copiar los datos.

El plano de continuidad de datos decide si los datos en el destino están actualizados y son correctos. Está compuesto por el modo de replicación de bases de datos y PITR, el Backup Service para VM y Block Storage, la descarga/restauración para bases de datos y Object Storage como cola de archivo. Sus características de recuperación son el RPO que realmente puede cumplir y cuánto tiempo tarda una restauración.

Confundir ambos planos es un fallo clásico. Direccionar el tráfico hacia un nodo en espera en segundos no logra nada si los datos de ese nodo están desactualizados por horas, y un réplica perfectamente actual es inútil si no hay ningún mecanismo que redirija a los clientes hacia ella. Diseñe cada plano según su propio objetivo: el plano de direccionamiento para el RTO y el plano de continuidad para el RPO. El diseño de piloto de FinCorp hace que esta separación sea concreta: las comprobaciones de estado del balanceador de carga más un registro de Cloud DNS con TTL bajo que una comprobación externa redirige forman el plano de direccionamiento que cumple el RTO, mientras que el nodo de base de datos en espera siempre activo y su ventana de PITR forman el plano de continuidad que cumple el RPO. Ambos están conectados únicamente en el momento del cambio.

5. Conciliación de VMware HA dedicado con Multi-Zona de la plataforma

FinCorp opera un gran entorno VMware, y una parte de él se despliega en IONOS CLOUD Private Cloud, el SDDC VMware gestionado dedicado. Por lo tanto, los entornos híbridos llevan dos modelos de resiliencia diferentes al mismo tiempo, y un arquitecto debe saber dónde se aplica cada uno.

Dentro de un clúster de Private Cloud, la tolerancia a fallos es una propiedad de VMware, no una propiedad de zona de disponibilidad de la plataforma. vSAN (versión 8.0, edición Enterprise según la documentación de Private Cloud, en vSphere 8.0 Enterprise Plus) protege contra fallos de host y de disco mediante codificación por borrado y espejado. La matriz enumera tres métodos de tolerancia a fallos: espejado RAID-1 (mínimo 3 hosts), codificación por borrado RAID-5 (mínimo 4 hosts) y codificación por borrado RAID-6 (mínimo 6 hosts). vSAN requiere un mínimo de 3 hosts para mantener la protección RAID1 (dos copias completas de los datos), que es el tamaño mínimo del clúster. vSphere HA reinicia las VMs en los hosts supervivientes cuando un host falla. Esta es la resiliencia intraclúster: mantiene el SDDC en funcionamiento ante fallos de hardware dentro de un clúster, y es el modelo operativo nativo de VMware que el entorno ya conoce.

Lo que vSAN y vSphere HA no proporcionan es resiliencia entre sitios. Protegen una carga de trabajo contra la pérdida de un host dentro del clúster; no hacen que una carga de trabajo sobreviva a la pérdida de todo el sitio o clúster. La continuidad entre sitios para el entorno VMware es una cuestión de replicación, gestionada por VMware Cloud Director Availability (VCDA, versión 4.7.x), que realiza replicación asíncrona y conmutación por error entre sitios a un coste aproximado de 50 EUR por VM protegida al mes. El límite honesto, declarado en la Unidad 4.4 y llevado adelante a la 7.4, es que la única herramienta de VMware que IONOS CLOUD enumera para esto es VCDA, VPN NSX-T L2 para extensión de capa 2 y vMotion intraclúster. No hay capacidad de movilidad en vivo entre sitios ni ningún otro complemento de VMware que asumir.

Para un diseño híbrido de FinCorp, los dos modelos se componen en lugar de competir. Dentro del núcleo VMware dedicado, apoye en vSAN y vSphere HA para la tolerancia a fallos intraclúster. Para la capa nativa de la plataforma (cómputo estándar, bases de datos gestionadas, contenedores), apoye en la colocación multi-zona explícita, las comprobaciones de estado del equilibrador de carga dentro de una zona más la reorientación de DNS con TTL bajo orquestada por el cliente entre zonas, y la recuperación a punto en el tiempo (PITR) de bases de datos. La continuidad entre sitios para el entorno VMware es la replicación de VCDA; la continuidad entre zonas para el entorno nativo es la composición de plano de datos más DNS de las secciones 3 y 4. El punto de conciliación es reconocer que "HA" significa cosas diferentes en cada lado, y que el mecanismo de un lado no sustituye al del otro.

Recorrido de implementación de DCD

Conectará un conmutado por fallo de DNS de dos zonas para un punto de acceso de FinCorp y validará que desvía el tráfico. El objetivo de la arquitectura es el plano de desvío de la sección 4: un nombre que se resuelve en un punto de acceso primario en una zona y que puede moverse a un punto de acceso en espera en una zona diferente. Esto combina el trabajo de Cloud DNS de la Unidad 3.7 con la disciplina de zonas explícitas de la sección 2. Requisitos previos: dos puntos de acceso de backend (por ejemplo, dos direcciones de equilibrador de carga o de servidor) desplegados en zonas de disponibilidad explícitas y diferentes, y el privilegio de administrador de contrato o "Access and manage DNS" necesario para gestionar zonas y registros.

Objetivo de construcción: Conectar un registro de conmutación por fallo de DNS con TTL bajo, orquestado por el cliente, en un par de dos zonas y validarlo, teniendo en cuenta que Cloud DNS no realiza comprobaciones de estado por sí mismo.

Pasos (en el Data Center Designer):

1. Confirme que los dos puntos de acceso están en zonas diferentes. Antes de tocar el DNS, verifique en el DCD que los recursos primario y en espera tengan zonas de disponibilidad explícitas y diferentes (no Auto). Si alguno está en Auto, corrija la colocación primero; un registro de conmutación por fallo frente a un par colocalizado es teatro.
2. Abra el DNS Manager y seleccione Create primary DNS zone. Introduzca el nombre de la zona (el dominio o subdominio de FinCorp que dará servicio al servicio). La zona es el contenedor para los registros de conmutación por fallo.
3. Después de que la zona se aprovisione, ábrela desde la lista Primary Zones usando Details & Records.
4. Cree el registro primario. Añada un registro (por ejemplo, un registro A) cuyo nombre sea el nombre de host del servicio y cuyo contenido sea la dirección del punto de acceso primario en la zona 1. Establezca el TTL bajo (en o cerca del límite de 60 segundos) para que un conmutación posterior se propague rápidamente; este TTL es su palanca dominante de RTO.
5. Anote la dirección del punto de acceso en espera en la zona 2. Apuntará el mismo nombre de registro a esta dirección durante una conmutación por fallo. Mantenga los detalles del punto de acceso en espera registrados para que la conmutación sea una única edición sin ambigüedad.
6. Defina la fuente de estado en el plano del equilibrador de carga. Dado que Cloud DNS no expone un registro de conmutación por fallo con comprobación de estado empaquetada, adjunte la comprobación de estado donde reside: en el grupo de destino del Managed ALB o NLB que da servicio a cada punto de acceso, configure la comprobación de estado periódica para que el equilibrador solo atienda destinos sanos. Esta es la señal de detección a la que reaccionará su conmutación por fallo.
7. Conecte la conmutación automatizada a nivel de API. Para hacer que la conmutación por fallo sea automática en lugar de activada por el operador, impulse la actualización del registro desde la monitorización o la orquestación: ante una señal de estado no saludable sostenida para la zona 1, llame a la API de Cloud DNS para actualizar el contenido del registro a la dirección de la zona 2. La ruta de la consola es la gestión de zonas y registros; la automatización es la edición de la API, por lo que mantenga este subpaso a nivel de diseño y API en lugar de inventar un asistente de consola.
8. Valide simulando un fallo. Saque el punto de acceso primario (zona 1) de servicio o haga que falle su comprobación de estado, y luego active o realice la actualización del registro a la dirección en espera. Desde un cliente externo, después de que transcurra el TTL, confirme que el nombre ahora se resuelve a la dirección de la zona 2 y que las nuevas conexiones llegan al punto de acceso en espera. Confirme que una conexión ya abierta no se mueve hasta que se reconecta, lo cual demuestra el requisito de capa sin estado.

Errores comunes:

• Dejar los puntos de acceso emparejados en la zona de disponibilidad Auto. Auto es una sugerencia de una sola zona, no una instrucción de distribuir entre zonas; establezca zonas explícitas y diferentes para ambos miembros del par antes de construir la conmutación por fallo.
• Establecer un TTL largo en el registro de conmutación por fallo. Un TTL alto limita su RTO alcanzable al valor del TTL porque los resolvers mantienen la respuesta en caché; bájelo a cerca del límite de 60 segundos en los registros que participan en la conmutación por fallo.
• Suponer que Cloud DNS tiene una conmutación por fallo gestionada o un registro nativo de comprobación de estado. No la tiene; la detección reside en las comprobaciones de estado del equilibrador de carga y la conmutación automática es una actualización de registro impulsada por la API. No espere un botón de consola que no existe.
• Esperar que el DNS mueva conexiones activas. El DNS solo desvía nuevas conexiones; si la capa de aplicación mantiene el estado de la sesión en la instancia, esas sesiones se rompen. Exterorice el estado a la capa de memoria para que la capa sea genuinamente sin estado.
• Tratar el Backup Service como el plan de DR de la base de datos. Cubre VMs y Block Storage, no bases de datos gestionadas; la continuidad de la base de datos es PITR más volcado/restauración. Valide el plano de continuidad de datos por separado del plano de desvío.

Una ilustración breve a nivel de API de la edición de conmutación (el punto arquitectónico es que la mitad de DNS de la conmutación por fallo es una actualización del contenido del registro impulsada por el cliente, no una política gestionada y no algo que Cloud DNS active por sí mismo):

# On a sustained zone-1 unhealthy signal, repoint the record to the zone-2 standby.
ionosctl dns record update --zone-id "$ZONE_ID" --record-id "$RECORD_ID" \
  --content "$STANDBY_ZONE2_ADDRESS"

Resumen

La resiliencia en IONOS CLOUD se compone, no se compra. Se parte de los RTO y RPO definidos por el negocio, se elige una de tres estrategias de recuperación, se colocan pares redundantes en zonas explícitamente distintas y se separa el plano de direccionamiento de tráfico (comprobaciones de estado del equilibrador de carga dentro de una zona, más una reasignación de registros de Cloud DNS con TTL bajo orquestada por el cliente entre zonas) del plano de continuidad de datos (PITR de bases de datos y volcado/restauración, el Backup Service para VMs y Block Storage, archivo de Object Storage). No existe un producto de conmutación por error administrada ni un orquestador de conmutación por error entre zonas administrado. El direccionamiento consciente del estado de la plataforma lo constituyen el equilibrador de carga (dentro de su grupo) y los grupos de conmutación por error de IP (dentro de una LAN); la conmutación por error entre zonas es una actualización de registro de API impulsada por el cliente que Cloud DNS sirve pero no desencadena, porque Cloud DNS no es consciente del estado. Para entornos híbridos, VMware vSAN y vSphere HA dedicados cubren la tolerancia a fallos dentro del clúster, mientras que la multi-zona de la plataforma, la composición de equilibrador de carga más DNS y VCDA cubren la continuidad entre zonas y entre sitios, respectivamente.

Puntos clave:

• RTO y RPO son decisiones de negocio; el arquitecto diseña en función de ellos y especifica el coste de cada uno. Las tres estrategias (copia de seguridad y restauración, piloto ligero, activo-activo) equilibran el coste con la velocidad de recuperación.
• La colocación en zona de disponibilidad debe ser explícita para cualquier par redundante. Auto es una sugerencia de colocación en una sola zona de disponibilidad, y Block Storage tiene una zona 3 que la computación no tiene.
• Las primitivas de direccionamiento consciente del estado de la plataforma son las comprobaciones de estado del equilibrador de carga (dentro del grupo de backends del LB) y los grupos de conmutación por error de IP (dentro de una LAN); no existe un orquestador de conmutación por error entre zonas administrado.
• Cloud DNS (anycast, 14 PoPs, SLA del 99,995 por ciento, TTL mínimo de 60 segundos) no es consciente del estado y no realiza conmutación por error automatizada. La conmutación por error entre zonas es una reasignación de registro con TTL bajo orquestada por el cliente que Cloud DNS sirve pero no desencadena; el TTL mínimo es el principal factor de RTO y DNS solo dirige nuevas conexiones.
• Mantener separados el plano de direccionamiento y el plano de continuidad de datos; el Backup Service no cubre las bases de datos administradas, cuya continuidad es PITR más volcado/restauración.
• Dentro de Private Cloud, vSAN (RAID-1/5/6, mínimo 3 hosts para RAID1) y vSphere HA proporcionan tolerancia a fallos dentro del clúster; la continuidad entre sitios es VCDA, y no existe movilidad en vivo entre sitios.

Terminología importante:

• RTO (Recovery Time Objective): la duración máxima tolerable de una interrupción; el plano de direccionamiento se diseña para cumplirlo.
• RPO (Recovery Point Objective): la pérdida máxima de datos tolerable medida en tiempo; el plano de continuidad de datos se diseña para cumplirlo.
• Zona de disponibilidad Auto: una sugerencia de colocación en una sola zona de disponibilidad que permite a IONOS CLOUD elegir una zona, no una instrucción de redundancia multi-zona.
• TTL mínimo: el tiempo de vida mínimo de un registro (60 segundos en Cloud DNS); limita el RTO impulsado por DNS mejor alcanzable.
• VCDA (VMware Cloud Director Availability): la herramienta nativa de VMware para replicación asíncrona y conmutación por error para la continuidad entre sitios del entorno VMware dedicado.

Lectura adicional

• Unidad 3.7: DNS y enrutamiento de conmutación por error (la zona y el registro que esta unidad reutiliza)
• Unidad 3.6: Conectividad híbrida (las pasarelas que vinculan los sitios durante la conmutación por error)
• Unidad 5.7: Protección de datos y ciclo de vida (el plano de continuidad de datos en detalle)
• Unidad 4.4: Private Cloud (VMware dedicado) y Unidad 7.4: Migración y conmutación híbrida (VCDA y el entorno de VMware)