El sistema de almacenamiento es un punto de error compartido. Proxmox VE HA protege las VM de los inquilinos de un fallo del host, pero no de un fallo del sistema de almacenamiento que aloja sus discos. Una interrupción del almacenamiento afecta a todos los inquilinos de ese sistema.

No hay forma de ofrecer una mayor disponibilidad. Sin replicación síncrona ni conmutación automática por error del almacenamiento, un proveedor no puede ofrecer un nivel prémium de disponibilidad con cero pérdida de datos y compromisos de tiempo de actividad más sólidos.

Aislamiento de los inquilinos durante la recuperación. Las pruebas de recuperación, mantenimiento y recuperación ante desastres deben afectar únicamente a los inquilinos implicados y no a toda la plataforma.

El QDevice aún necesita una tercera ubicación. ONTAP Cloud Mediator elimina el host mediador, no el host QDevice de corosync. El QDevice necesita un pequeño host Linux al que todos los nodos de Proxmox VE puedan acceder por el puerto TCP 5403, y no tiene el requisito de baja latencia de corosync.

Ambos clústeres necesitan acceso a la NetApp Console. Si los clústeres utilizan un proxy, instala el certificado de la CA raíz del proxy en ambos clústeres. NetApp recomienda utilizar un servidor proxy diferente para cada clúster.

Planifica el mismo comportamiento ante fallos con cualquiera de las dos opciones. Cuando el mediador no está disponible, la replicación continúa sin pérdida de datos, pero no es posible realizar conmutaciones automáticas ni planificadas hasta que el mediador vuelva a estar disponible. Con ONTAP Cloud Mediator, esto incluye una pérdida de conectividad de los clústeres a NetApp Console.

Disponibilidad de las VM más allá de la HA del host. Las VM de tenant siguen funcionando cuando falla el sistema de almacenamiento que aloja sus discos. ONTAP conmuta al segundo clúster AFF, y las VM reanudan la E/S en el mismo almacenamiento compartido sin reiniciarse.

Un nivel de disponibilidad premium. Puedes ofrecer un servicio de máquinas virtuales con RPO cero y resiliencia del almacenamiento como complemento, junto con los niveles estándar en almacenamiento no protegido dentro de los mismos clústeres.

Protección y conmutación por error por tenant. Con almacenamiento protegido independiente para cada tenant o nivel de servicio, puedes proteger, realizar la conmutación por error y probar la recuperación ante desastres de cada tenant de forma independiente, sin afectar a los demás tenants.

Mejor aprovechamiento de ambos sitios. Puedes configurar algunas cargas de trabajo como primarias en el sitio A y otras como primarias en el sitio B, de modo que ambos centros de datos sirvan cargas de trabajo activas.

Cero pérdida de datos para VMs críticas para la empresa durante un fallo del almacenamiento o del sitio.

Recuperación automática sin scripts, sin volver a montar el almacenamiento ni realizar cambios en /etc/pve/storage.cfg.

Integrado en ONTAP, sin ninguna capa de software adicional en los nodos de Proxmox VE.

Operaciones del día a día desde una sola interfaz. Storage Manager para Proxmox aprovisiona el almacenamiento compartido protegido y realiza copias de seguridad, restaura y clona máquinas virtuales con instantáneas de ONTAP y la tecnología FlexClone.

Elige MetroCluster cuando todas o casi todas las cargas de trabajo del almacenamiento necesiten un RPO igual a cero, por ejemplo, cuando una empresa ejecute solo máquinas virtuales de misión crítica en el clúster o un proveedor de servicios ofrezca el mismo nivel de disponibilidad a cada inquilino. Obtienes un dominio de protección sin configuración por carga de trabajo.

Elige la sincronización activa de SnapMirror cuando solo un subconjunto de cargas de trabajo necesite un RPO nulo, por ejemplo, un nivel Premium para algunos inquilinos, o cuando necesites realizar una conmutación por error o probar la recuperación ante desastres de un inquilino o una aplicación cada vez.

SnapMirror active sync para NAS no es compatible con una configuración de MetroCluster. Utiliza una solución para cada par de clústeres.

Las directrices sobre corosync, QDevice y HA de esta solución se aplican a ambos. Con MetroCluster, alinea el interruptor de QDevice con el sitio que sigue sirviendo datos cuando falla el enlace entre sitios, y usa las reglas de afinidad de nodos de HA para mantener las VMs en el mismo sitio que su SVM activa.

MetroCluster IP también es compatible con VIP LIFs con BGP para redes de capa 3 entre sitios.

SnapMirror active sync requiere un tiempo de ida y vuelta (RTT) entre clústeres inferior a 10 ms. Proxmox recomienda una latencia de corosync inferior a 5 ms entre todos los nodos, por lo que el requisito de corosync establece el límite de distancia para la solución.

Corosync necesita una latencia baja y constante, más que un ancho de banda elevado. Utiliza una red dedicada para corosync, independiente del tráfico de almacenamiento y de migración en vivo, para que los picos de tráfico del almacenamiento no provoquen tiempos de espera en corosync.

Configura al menos dos enlaces de corosync (por ejemplo, el enlace 0 y el enlace 1) en rutas físicas independientes entre los sitios. Corosync utiliza Kronosnet para cambiar de enlace automáticamente si falla una ruta.

Proxmox VE HA suele detectar un nodo que ha fallado y recuperar sus VMs en unos dos minutos, incluido un tiempo de espera de aislamiento watchdog de 60 segundos. Durante un fallo del sitio, la conmutación por error de sincronización activa de SnapMirror y la recuperación de Proxmox VE HA se ejecutan en paralelo.

Utiliza las reglas de afinidad de nodos HA con prioridades de nodo para colocar las VM en los nodos del mismo sitio que su almacenamiento primario y permitir que conmuten por error al otro sitio.

Tras una conmutación por error del sitio, configura la propiedad HA failback en 0 para las máquinas virtuales afectadas hasta que devuelvas el almacenamiento a su sitio original. De lo contrario, HA volverá a migrar las máquinas virtuales a los nodos del sitio A en cuanto vuelvan, mientras el almacenamiento activo siga en el sitio B.

Asegúrate de que los tiempos de espera del disco del sistema operativo invitado sean más largos que el tiempo previsto para la conmutación por error, de modo que los sistemas invitados no notifiquen errores de E/S durante una conmutación por error del almacenamiento.

Utiliza grupos de recursos y políticas de backup para aplicar la misma programación y la misma retención a las máquinas virtuales de un inquilino o de una aplicación.

Utiliza copias de seguridad con coherencia de archivos para las máquinas virtuales que ejecutan el agente invitado de QEMU, para que los sistemas de archivos invitados queden en inactividad antes de que ONTAP cree la instantánea.

SMP gestiona el almacenamiento que está activo. Tras una conmutación por error de active sync de SnapMirror, ejecuta una detección en SMP para que asigne el almacenamiento al clúster B antes de realizar operaciones de copia de seguridad o restauración.

Si necesitas una tercera copia fuera de esos dos sitios o si quieres un periodo de retención más largo, añade una relación de distribución asíncrona de SnapMirror desde los volúmenes protegidos o usa Proxmox Backup Server.

Las instantáneas a prueba de manipulaciones no son compatibles con la sincronización activa de SnapMirror, por lo que no debes activar el bloqueo de instantáneas en SMP para los volúmenes protegidos.

Ejecuta la máquina virtual SMP como recurso de alta disponibilidad (HA) en un almacenamiento compartido protegido por sincronización activa de SnapMirror, de modo que SMP siga estando disponible tras un fallo del almacenamiento o del sitio.

Registra el clúster de Proxmox VE y los dos clústeres de ONTAP en SMP, de modo que SMP pueda acceder al almacenamiento activo en cualquiera de los dos sitios.

SnapMirror active sync para NAS protege toda una máquina virtual de almacenamiento (SVM). Puedes proteger todos los volúmenes de la SVM o excluir los volúmenes seleccionados. Solo se admiten volúmenes FlexVol, y la SVM no puede contener LUN.

La SVM secundaria permanece inactiva, con sus LIF desactivadas, hasta que se produce una conmutación por error. ONTAP replica la configuración de la SVM, incluidas las direcciones IP de las LIF, las políticas de exportación y la configuración de NFS, de modo que la SVM secundaria presenta el mismo punto final de NFS tras una conmutación por error.

La conmutación por error no provoca interrupciones en NFSv3 y versiones posteriores.

SnapMirror active sync para NAS es activo/pasivo, por lo que las VMs en los nodos del sitio B leen y escriben a través de la red entre sitios en la SVM principal. Para cargas de trabajo activas en ambos sitios, utiliza dos SVM con direcciones de replicación opuestas, una principal en cada sitio, y alinea la regla de afinidad de nodo de cada VM con el sitio de su SVM principal.

SnapMirror active sync para NAS es compatible con clústeres de dos nodos AFF A-Series y C-Series.

nConnect. Abre varias conexiones TCP a una sola dirección de LIF de NFS, por ejemplo nconnect=4. nConnect funciona con NFSv3 y NFSv4.1 y con una sola dirección de LIF de VIP, por lo que es la opción recomendada para SnapMirror active sync para NAS, incluidas las redes de capa 3.

Agrupación de sesiones. Agrupa varias LIF de datos en una sola sesión NFSv4.1, por ejemplo vers=4.1,trunkdiscovery,max_connect=16. La agrupación de sesiones requiere NFSv4.1 o una versión posterior. Úsala solo cuando la SVM protegida tenga varias LIF de datos a las que los clientes puedan acceder desde ambos sitios, como en una red de capa 2 extendida. Para obtener más información, consulta "Trunking de NFS".

Aprovisiona el volumen en la SVM principal y selecciona la LIF de NFS, o la LIF VIP en una red de capa 3, como LIF preferida. La SVM secundaria usa la misma dirección después de una conmutación por error, por lo que la definición de almacenamiento sigue siendo válida.

Monta el almacenamiento en todos los nodos de Proxmox VE de ambas ubicaciones, de modo que la alta disponibilidad (HA) pueda reiniciar las máquinas virtuales en cualquier nodo.

Asegúrate de que la política de exportación permita el acceso a los nodos de Proxmox VE en ambas ubicaciones. ONTAP replica la política de exportación a la SVM secundaria.

Tras el aprovisionamiento, comprueba que el volumen esté incluido en la protección de SnapMirror active sync.

Los LIF de BGP no se someten a conmutación por error. La redundancia proviene de dos LIF de BGP por nodo, cada uno emparejado con un router diferente. Si un nodo pierde todas sus sesiones de BGP para una SVM, ONTAP mueve el LIF VIP a otro nodo que tenga una sesión de BGP activa para esa SVM.

Utiliza BGP externo (eBGP) con un número de sistema autónomo (ASN) privado único para cada nodo ONTAP y cada router.

Utiliza una subred /31 (máscara de red 255.255.255.254) para cada LIF de BGP y su enrutador. Asigna la dirección impar al LIF de BGP y la dirección par al enrutador.

ONTAP no procesa las rutas procedentes de los routers. Configura los routers para que acepten rutas de host /32 procedentes de ONTAP y no envíen actualizaciones de rutas al clúster.

Los nodos de Proxmox VE no deben compartir una subred con la dirección VIP. Debe haber un router redundante de capa 3, por ejemplo con VRRP o HSRP, en la ruta entre los nodos y el almacenamiento.

Configura los grupos de pares BGP con -use-peer-as-next-hop true para que cada clúster aprenda su ruta predeterminada de sus routers locales. Las rutas que apuntan a una puerta de enlace del sitio A no son válidas en el sitio B tras una conmutación por error.

Activa el enrutamiento multivía para que el tráfico VIP saliente utilice todos los puertos LIF de BGP disponibles.

Reduce el tiempo de retención de BGP respecto al valor predeterminado de 180 segundos. TR-4949 recomienda un tiempo de retención de 3 segundos. Un router retira la ruta de un clúster que ha fallado únicamente cuando expira el temporizador de retención y, durante un fallo del sistema de almacenamiento, el router del sitio A permanece en línea.