Unidad 7.1: Resiliencia y Continuidad Empresarial

Introducción

La resistencia no es un producto que se compra en IONOS; es una propiedad que se compone. La plataforma le ofrece zonas de disponibilidad, un nivel de equilibrio de carga con comprobación de estado, un servicio DNS anycast, recuperación de base de datos en un momento determinado y un Backup Service, pero no vende un solo botón de "conmutación por error" que los orqueste. Esa ausencia es el hecho de diseño central de esta unidad. Su trabajo como arquitecto es traducir un requisito de continuidad empresarial en una disposición de estos elementos primitivos, y luego demostrar que funciona.

Esta unidad cierra construyendo la mitad de dirección de esa disposición en el Data Center Designer: un par de registros Cloud DNS de bajo TTL orquestado por el cliente a través de dos zonas, más el paso de validación que confirma que una conmutación por error realmente mueve el tráfico. Cloud DNS no realiza comprobaciones de estado por sí solo, por lo que la comprobación de estado que impulsa esa conmutación es una que usted suministra. 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 de servicios financieros alemana bajo GDPR y obligaciones BSI, ancla cada decisión: un servicio adyacente a los 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 gobiernan cada diseño de continuidad, y el negocio es propietario de ambos. El Objetivo de Tiempo de Recuperación (RTO) es el tiempo que el servicio puede estar inactivo antes de que la interrupción se convierta en dañina de manera material. 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 comercial sin autoridad. La función de riesgo y cumplimiento de FinCorp los establece; usted diseña para cumplir con ellos y declara honestamente cuánto cuesta cada objetivo.

Estos dos puntos de referencia seleccionan una estrategia de recuperación. Tres estrategias abarcan el espectro de costo versus velocidad, y cada una se asigna limpiamente a los primitivos de IONOS.

La estrategia es una decisión de presupuesto tanto como una decisión de disponibilidad. Active-active duplica la huella en ejecución y exige la replicación de datos más ajustada; backup-restore es barato pero lento para recuperar y pierde la mayoría de los datos. El servicio de pagos de FinCorp no puede tolerar un RTO de varias horas, por lo que backup-restore es descartado como la 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 pilot-light para el núcleo regulado: una base de datos Cluster siempre activa con un Node de espera, cómputo preestablecido que se escala en caso de conmutación por error, y DNS para redirigir.

Una verdad crítica de la plataforma se extiende por las tres estrategias. El Backup Service (Acronis) cubre máquinas virtuales y Block Storage; no respalda bases de datos gestionadas, y no proporciona copias de seguridad inmutables. La continuidad de la base de datos es, por lo tanto, un mecanismo separado: recuperación en un momento dado dentro de la ventana de retención de Cluster, más volcado y restaurado para cualquier cosa más allá de ella. Tratar el Backup Service como su plan de recuperación de desastres de la base de datos es el error más costoso en este espacio, porque solo descubre la brecha durante una recuperación real. Las instantáneas complican la confusión: una instantánea Block Storage Snapshot es un retroceso de nivel VM, no incremental, regional, no una copia de seguridad coherente con la base de datos. Planifique el plano de continuidad de datos alrededor de la recuperación en un momento dado y el volcado/restaurado para las capas de datos, y alrededor del Backup Service solo para las máquinas virtuales y volúmenes que realmente cubre.

2. Colocación en varias zonas y la trampa de la zona automática

La resistencia comienza con la ubicación física de los elementos. IONOS expone las zonas de disponibilidad como el primitivo de colocación, y la redundancia que se obtiene depende enteramente de colocar recursos emparejados en diferentes zonas. La plataforma no inferirá su intención.

Tenga en cuenta una asimetría que atrapa a los arquitectos. Las zonas de disponibilidad de Compute son Zona 1, Zona 2 y Auto. Las zonas de disponibilidad de Block Storage son Zona 1, Zona 2, Zona 3 y Auto. No hay Zona 3 de Compute, por lo que un Volume colocado en la Zona 3 no tiene un servidor co-zonificado al que pueda conectarse en la misma zona. Para un par de Compute y almacenamiento redundante, diseñe dentro de las zonas que comparten ambos planos.

La trampa se encuentra en la palabra "Auto". Seleccionar la zona de disponibilidad Auto es una pista de colocación de una zona que permite a IONOS elegir una zona para usted; no es una instrucción de "multi-zona" o "distribuir en varias zonas". Si crea dos servidores destinados a ser un par de alta disponibilidad y los deja ambos en Auto, no hay garantía de que aterricen en zonas diferentes, y pueden compartir una. Un dominio de falla compartido es exactamente lo que un par de alta disponibilidad está diseñado para eliminar. La regla es inequívoca: para cualquier par que deba sobrevivir a una falla de zona, establezca zonas explícitas y diferentes. Auto es aceptable para un recurso único y no emparejado donde no tiene preferencia de zona; es incorrecto para la redundancia.

Para FinCorp, esto significa que la base de datos de respaldo Node se encuentra en una zona explícitamente diferente a la del primario, y la plantilla de Compute de pilotaje se proporciona en una zona con nombre distinta de la del nivel de producción. La disciplina de zona explícita es barata de aplicar en el momento del diseño y es imposible de implementar limpiamente después de que una interrupción demuestre que el par estaba ubicado en la misma zona.

3. Dirección basada en la salud: comprobaciones de salud de LB, conmutación por error de IP y orquestación por el cliente de DNS

IONOS no vende un producto de conmutación por error gestionado. No hay un orquestador que supervise un primario, lo declare muerto y promueva un secundario en toda la pila, y no hay un servicio de conmutación por error gestionado entre zonas o sitios. Es importante ser preciso sobre qué primitivo realiza la dirección consciente de la salud, porque no es Cloud DNS.

Los primitivos de dirección automatizados y basados en la salud de la plataforma son dos. Primero, comprobaciones de salud del equilibrador de carga: el Managed Application Load Balancer realiza comprobaciones de salud activas de sus objetivos de backend a través de TCP o HTTP, mientras que el Managed Network Load Balancer realiza comprobaciones de salud de sus objetivos a través de TCP solo (las comprobaciones de salud conscientes de HTTP son una capacidad exclusiva de ALB); ambos admiten intervalos y reintentos configurables y dirigen el tráfico alejándolo de los objetivos no saludables dentro del grupo de backend del Load Balancer, esto es un failover automatizado real, pero está limitado a la región y LAN: mueve el tráfico entre objetivos dentro de un grupo, no entre zonas o sitios. Segundo, grupos de conmutación por error de IP: un IP reservado compartido entre máquinas virtuales en un LAN, para la conmutación por error de nivel de aplicación construida por el cliente; también es local de LAN. La colocación multi-zona (sección 2) es la tercera parte, pero es colocación, no dirección.

La conmutación por error entre zonas y sitios se encuentra por encima de todos estos, y aquí no hay un mecanismo nativo consciente de la salud. Cloud DNS no es consciente de la salud: no supervisa la salud del punto de conexión y no cambia un registro por sí solo. La conmutación por error entre zonas es, por lo tanto, orquestada por el cliente: su propia comprobación de salud (un monitor externo o una señal derivada del estado de salud del equilibrador de carga) detecta que el punto de conexión de una zona está abajo y llama al API de Cloud DNS para reenviar un registro de baja TTL a la zona saludable. La contribución de Cloud DNS es que el registro es anycast, tiene un SLA respaldado y puede llevar una TTL muy baja; la automatización de detección y reenvío es suya. Esto es el reemplazo de conmutación por error introducido en la Unidad 1.3, realizado honestamente: componga un primitivo consciente de la salud (el Load Balancer dentro de una zona) con un reenvío de DNS impulsado por el cliente a través de zonas.

Cloud DNS es adecuado para la mitad de DNS de esa composición. Funciona en una red anycast en 14 puntos de presencia, lleva un SLA de tiempo de actividad por servicio del 99,995 por ciento y admite una TTL tan baja como 60 segundos. Ese piso de TTL es el principal controlador de RTO para cualquier conmutación por error basada en DNS, porque un resolutor seguirá utilizando una respuesta en caché hasta que expire el TTL. Si su registro lleva una TTL de una hora, su recuperación impulsada por DNS no puede superar una hora, no importa cuán rápido detecte el fallo. Baje la TTL en los registros que participan en la conmutación por error y acepte el modesto aumento en la consulta de Volume como el precio de una conmutación más rápida.

Dos limitaciones honestas dan forma a cómo construye esto. Primero, DNS solo dirige nuevas conexiones. Un cliente que ya mantiene una conexión con el punto de conexión fallido no se mueve con un cambio de DNS; debe volver a conectarse, en cuyo punto resuelve la nueva dirección. Esta es la razón por la cual los niveles de aplicación detrás de una conmutación por error de DNS deben ser sin estado, con la sesión y el estado compartido externalizados al nivel de memoria en lugar de mantenerse en la instancia. Segundo, la capacidad de comprobación de salud vive en el plano del equilibrador de carga (o en su propio monitor externo), nunca en Cloud DNS: no hay un tipo de registro de conmutación por error de comprobación de salud, porque Cloud DNS no comprueba la salud en absoluto. En la práctica, se componen los planos: un Load Balancer determina la salud dentro de una zona, y una llamada de API impulsada por el cliente reenvía el registro de DNS entre los puntos de conexión de nivel de zona. Debido a que ese corte de zona debe estar impulsado por su herramienta de monitoreo u orquestación en lugar de por Cloud DNS, trate la actualización del registro como un diseño de nivel de API, no como un asistente de consola de punto y clic; el camino de la consola es la gestión de zonas y registros, y Cloud DNS nunca desencadena el cambio por sí mismo.

4. Dos planos: control de dirección y continuidad de datos

Un diseño de resiliencia duradera mantiene separadas dos preocupaciones, porque fallan y se recuperan en diferentes escalas de tiempo y a través de diferentes mecanismos.

El plano de control de dirección decide hacia dónde van las solicitudes. Está construido a partir de registros Cloud DNS, configuraciones de TTL y comprobaciones de salud de equilibrio de carga que determinan la salud del punto de conexión. Su trabajo es mover nuevas conexiones lejos de una ubicación fallida rápidamente. Su velocidad de recuperación está limitada por el piso de TTL y por los intervalos de comprobación de salud, 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 son actuales y correctos. Está construido a partir del modo de replicación de base de datos y PITR, el Backup Service para máquinas virtuales y Block Storage, volcado/restauración para bases de datos, y Object Storage como cola de archivo. Sus características de recuperación son el RPO que realmente se puede cumplir y cuánto tiempo lleva una restauración.

Confundir los dos es un error clásico. Dirigir el tráfico a un sistema de respaldo en segundos no logra nada si los datos del sistema de respaldo tienen horas de retraso, y una réplica perfectamente actualizada es inútil si no hay mecanismo que redirija a los clientes hacia ella. Diseñe cada plano para su propio objetivo: el plano de control de dirección para el RTO, el plano de continuidad para el RPO. El diseño de pilotaje de FinCorp hace que la separación sea concreta: las comprobaciones de salud de equilibrio de carga más un registro Cloud DNS de baja TTL que una comprobación externa reorienta forman el plano de control de dirección que cumple el RTO, mientras que la base de datos de respaldo siempre activa Node y su ventana PITR forman el plano de continuidad que cumple el RPO. Los dos están conectados solo en el momento del corte.

5. Reconciliación de alta disponibilidad de VMware dedicado con plataforma multi-zona

FinCorp ejecuta una gran propiedad de VMware, y parte de ella se encuentra en IONOS Private Cloud, el centro de datos virtual (SDDC) de VMware gestionado de forma dedicada. Por lo tanto, las propiedades híbridas llevan dos modelos de resistencia diferentes al mismo tiempo, y un arquitecto debe saber dónde se aplica cada uno.

Dentro de un Private Cloud Cluster, la tolerancia a fallos es una propiedad de VMware, no una propiedad de disponibilidad de la zona 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 disco a través de codificación de borrado y reflejo. La matriz enumera tres métodos de tolerancia a fallos: reflejo RAID-1 (mínimo 3 hosts), codificación de borrado RAID-5 (mínimo 4 hosts) y codificación de 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 de Cluster. vSphere HA reinicia las máquinas virtuales en hosts supervivientes cuando un host falla. Esta es la resistencia intra-Cluster: mantiene el SDDC en funcionamiento a través de fallos de hardware dentro de un Cluster, y es el modelo de operación nativo de VMware que la propiedad ya entiende.

Lo que vSAN y vSphere HA no proporcionan es la resistencia entre sitios. Protegen un Workload contra la pérdida de host dentro del Cluster; no hacen que un Workload sobreviva a la pérdida del sitio completo o Cluster. La continuidad entre sitios para la propiedad de VMware es una preocupación de replicación, manejada por VMware Cloud Director Availability (VCDA, versión 4.7.x), que realiza replicación y conmutación por error asíncrona entre sitios a un costo de aproximadamente 50 EUR por VM protegido al mes. El límite honesto, establecido en la Unidad 4.4 y llevado adelante a 7.4, es que la única herramienta de VMware que IONOS enumera para esto es VCDA, NSX-T L2 VPN para extensión de Capa 2, y vMotion intra-Cluster. No hay capacidad de movilidad en vivo entre sitios y no hay otro complemento de VMware que asuma.

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

En resumen, la reconciliación de la alta disponibilidad de VMware dedicado con la plataforma multi-zona requiere una comprensión clara de los modelos de resistencia y la replicación entre sitios. Al combinar vSAN, vSphere HA y VCDA, los arquitectos pueden diseñar una propiedad híbrida que proporcione alta disponibilidad y escalabilidad para las cargas de trabajo de VMware y la plataforma nativa.

DCD Implementación paso a paso

Usted configurará un conmutador de falla de dos zonas para un punto de conexión de FinCorp y validará que dirige el tráfico. El objetivo arquitectónico es el plano de dirección de la sección 4: un nombre que se resuelve en un punto de conexión principal en una zona y que se puede mover a un punto de conexión de respaldo en una zona diferente. Esto compone el trabajo de Cloud DNS de la Unidad 3.7 con la disciplina de zona explícita de la sección 2. Requisitos previos: dos puntos de conexión de backend (por ejemplo, dos direcciones de equilibrio de carga o servidor) implementados en zonas de disponibilidad explícitamente diferentes, y el privilegio de contrato-administrador o "Acceso y administración de DNS" requerido para administrar zonas y registros.

Objetivo de construcción: Configurar un registro de conmutador de falla de DNS con bajo TTL para un par de dos zonas y validar, teniendo en cuenta que Cloud DNS no realiza comprobaciones de salud por sí solo.

Pasos (en el Data Center Designer):

1. Confirme que los dos puntos de conexión estén en diferentes zonas. Antes de tocar DNS, verifique en el DCD que los recursos principales y de respaldo tengan zonas de disponibilidad explícitas y diferentes (no Auto). Si alguno de ellos está en Auto, corrija la ubicación primero; un registro de conmutador de falla frente a un par co-localizado es inútil.
2. Abra el Administrador de DNS y seleccione Crear zona principal de DNS. Introduzca el nombre de la zona (el dominio o subdominio de FinCorp que frente al servicio). La zona es el contenedor para los registros de conmutador de falla.
3. Después de que la zona se proporcione, ábrala desde la lista de zonas principales utilizando Detalles y registros.
4. Cree el registro principal. Agregue un registro (por ejemplo, un registro A) cuyo nombre es el hostname del servicio y cuyo contenido es la dirección del punto de conexión principal en la zona 1. Establezca el TTL bajo (en o cerca del piso de 60 segundos) para que una posterior conmutación se propague rápidamente; este TTL es su principal palanca de RTO.
5. Tenga en cuenta la dirección del punto de conexión de respaldo en la zona 2. Usted apuntará el mismo nombre de registro a esta dirección durante una conmutación de falla. Mantenga los detalles del punto de conexión de respaldo registrados para que la conmutación sea una sola edición sin ambigüedad.
6. Defina la fuente de salud en el plano de equilibrio de carga. Dado que Cloud DNS no expone un registro de conmutador de falla de comprobación de salud empaquetado, adjunte la comprobación de salud donde vive: en el grupo de destino de Managed ALB o NLB que frente a cada punto de conexión, configure la comprobación de salud periódica para que el equilibrador solo sirva objetivos saludables. Esto es la señal de detección que su conmutador de falla reaccionará.
7. Configure la conmutación automática a nivel de API. Para hacer que la conmutación de falla sea automática en lugar de desencadenada por el operador, impulse la actualización del registro desde la monitorización o la orquestación: en una señal de salud insaludable sostenida para la zona 1, llame a la Cloud DNS API para actualizar el contenido del registro a la dirección de la zona 2. La ruta de la consola es la administración de zona y registro; la automatización es la edición de API, así que mantenga este sub-paso de diseño y nivel de API en lugar de inventar un asistente de consola.
8. Valide simulando una falla. Saque el punto de conexión principal (zona 1) del servicio o haga que falle su comprobación de salud, luego desencadene o realice la actualización del registro a la dirección de respaldo. Desde un cliente externo, después de que transcurra el TTL, confirme que el nombre ahora se resuelve en la dirección de la zona 2 y que las nuevas conexiones alcanzan el punto de conexión de respaldo. Confirme que una conexión ya abierta no se mueve hasta que se vuelva a conectar, lo que demuestra el requisito de capa sin estado.

Errores comunes:

• Dejar puntos de conexión emparejados en la zona de disponibilidad Auto. Auto es una pista de zona única, no una instrucción para distribuirse en zonas; establezca zonas explícitas y diferentes para ambos miembros de la pareja antes de construir la conmutación de falla.
• Establecer un TTL largo en el registro de conmutador de falla. Un TTL alto limita su RTO alcanzable en el valor de TTL porque los resolutores mantienen la respuesta en caché; reduzca a cerca del piso de 60 segundos en registros que participan en la conmutación de falla.
• Suponer que Cloud DNS tiene un conmutador de falla administrado o un registro de comprobación de salud nativo. No lo hace; la detección vive en las comprobaciones de salud de equilibrio de carga y la conmutación automática es una actualización de registro impulsada por API. No espere un botón de consola que no existe.
• Esperar que DNS mueva conexiones en vivo. DNS solo dirige nuevas conexiones; si la capa de aplicación mantiene el estado de la sesión en la instancia, esas sesiones se rompen. Externalice el estado a la capa de memoria para que la capa sea genuinamente sin estado.
• Tratar el Backup Service como el plan de recuperación de desastres de la base de datos. Cubre máquinas virtuales y Block Storage, no bases de datos administradas; la continuidad de la base de datos es PITR más volcado/restaurado. Valide el plano de continuidad de datos por separado del plano de dirección.

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

# 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 resistencia en IONOS se compone, no se compra. Usted comienza desde los objetivos de recuperación de la empresa (RTO y RPO), elige una de las tres estrategias de recuperación, coloca pares redundantes en zonas explícitamente diferentes, y separa el plano de dirección del tráfico (comprobaciones de salud del equilibrio de carga dentro de una zona, más una reasignación de bajo TTL Cloud DNS orquestada por el cliente a través de zonas) del plano de continuidad de datos (PITR de base de datos y volcado/restauración, el Backup Service para máquinas virtuales y Block Storage, Object Storage de archivo). No hay un producto de conmutación por error gestionado ni un orquestador de zona cruzada gestionado. La dirección de salud consciente de la plataforma es el Load Balancer (dentro de su grupo) y los grupos de conmutación por error IP (dentro de un LAN); la conmutación por error entre zonas es una actualización de registro API impulsada por el cliente que Cloud DNS sirve pero no dispara, porque Cloud DNS no es consciente de la salud. Para los patrimonios híbridos, los vSAN y vSphere HA dedicados VMware cubren la tolerancia a fallos dentro de Cluster, mientras que la plataforma de varias zonas, la composición de LB más DNS y VCDA cubren la continuidad entre zonas y entre sitios, respectivamente.

Puntos clave:

• Los RTO y RPO son decisiones comerciales; el arquitecto diseña según ellos y establece qué cuesta cada uno. Las tres estrategias (restauración de copia de seguridad, piloto de luz, activo-activo) intercambian el costo con la velocidad de recuperación.
• La colocación de la zona de disponibilidad debe ser explícita para cualquier par redundante. Auto es una pista de zona única, y Block Storage tiene una Zona 3 que no tiene el cálculo.
• Los primitivos de dirección de salud consciente de la plataforma son las comprobaciones de salud del equilibrio de carga (dentro del grupo de backend del equilibrio de carga) y los grupos de conmutación por error IP (dentro de un LAN); no hay un orquestador de zona cruzada gestionado.
• Cloud DNS (anycast, 14 PoPs, 99,995 por ciento de SLA, piso de TTL de 60 segundos) no es consciente de la salud y no realiza ninguna conmutación por error automática. La conmutación por error entre zonas es una reasignación de registro de bajo TTL orquestada por el cliente que Cloud DNS sirve pero no dispara; el piso de TTL es el principal controlador de RTO y DNS dirige solo nuevas conexiones.
• Mantenga separados el plano de dirección y el plano de continuidad de datos; Backup Service no cubre las bases de datos gestionadas, 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 dan tolerancia a fallos dentro de Cluster; la continuidad entre sitios es VCDA, y no hay movilidad en vivo entre sitios.

Terminología importante:

• RTO (Objetivo de tiempo de recuperación): la duración máxima tolerable de una interrupción; el plano de dirección está diseñado para cumplir con él.
• RPO (Objetivo de punto de recuperación): la pérdida de datos máxima tolerable medida en tiempo; el plano de continuidad de datos está diseñado para cumplir con él.
• Zona de disponibilidad automática: una pista de colocación de zona única que permite a IONOS elegir una zona, no una instrucción de redundancia de varias zonas.
• Piso de TTL: el tiempo de vida mínimo del registro (60 segundos en Cloud DNS); limita el mejor RTO alcanzable impulsado por DNS.
• VCDA (Herramienta de disponibilidad del director de nube VMware): la herramienta de replicación y conmutación por error asíncrona nativa de VMware para la continuidad entre sitios del patrimonio dedicado VMware.

Lectura adicional

• Unidad 3.7: DNS y enrutamiento de conmutación por error (la zona y el registro que se reutilizan en esta unidad)
• Unidad 3.6: Conectividad híbrida (las puertas de enlace que enlazan 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 profundidad)
• Unidad 4.4: Private Cloud (VMware dedicado) y Unidad 7.4: Migración y corte híbrido (VCDA y el patrimonio de VMware)