Los switches Nexus del centro local proporcionan la conectividad del almacenamiento a los FIS y los servidores blade locales UCS. A través de la conectividad del switch Nexus entre sitios, los servidores blade UCS remotos también pueden acceder al almacenamiento. La siguiente figura y tabla muestran el diagrama de conectividad de almacenamiento y una lista de conexiones de las controladoras de almacenamiento en cada sitio.

Para obtener esta validación, se conectan dos puertos físicos por controladora de almacenamiento a cada switch Nexus para añadir ancho de banda y redundancia. Estas cuatro conexiones participan en una configuración de grupo de interfaz en el almacenamiento. Los puertos correspondientes de los switches Nexus participan en un VPC para la agregación y la resiliencia de los enlaces.

Los protocolos de almacenamiento de datos de gestión en banda, entre clústeres y NFS/iSCSI utilizan VLAN. Los puertos VLAN se crean en el grupo de interfaces para segregar los diferentes tipos de tráfico. Las interfaces lógicas (LIF) para las funciones respectivas se crean en la parte superior de los puertos VLAN correspondientes. En la siguiente figura, se muestra la relación entre las conexiones físicas, los grupos de interfaces, los puertos VLAN y las interfaces lógicas.

NetApp recomienda implementar el arranque SAN para los servidores Cisco UCS en la solución FlexPod. La implementación de arranque SAN permite proteger de forma segura el sistema operativo dentro del sistema de almacenamiento de NetApp, lo que ofrece un mejor rendimiento y flexibilidad. Para esta solución, se validó el arranque SAN de iSCSI.

La figura siguiente muestra la conectividad para arranque SAN iSCSI de Cisco UCS Server desde almacenamiento NetApp. En el arranque SAN iSCSI, a cada servidor Cisco UCS se le asignan dos NIC iSCSI (una para cada estructura SAN) que proporcionan conectividad redundante desde el servidor hasta el almacenamiento. Los puertos de almacenamiento Ethernet 10/25-G conectados a los switches Nexus (en este ejemplo, e1a, e1b, e1c y e1d) se agrupan para formar un grupo de interfaces (ifgrp) (en este ejemplo, a0a). Los puertos VLAN iSCSI se crean en ifgrp y los LIF iSCSI se crean en los puertos VLAN iSCSI.

Cada LUN de arranque iSCSI se asigna al servidor que arranca a través de las LIF iSCSI asociando la LUN de arranque con los nombres completos de iSCSI (IQN) del servidor en su igroup de arranque. el igroup de arranque del servidor contiene dos IQN, uno para cada estructura VNIC / SAN. Esta función solo permite que el servidor autorizado tenga acceso a la LUN de arranque creada específicamente para ese servidor.

Los clústeres pares de ONTAP se comunican a través de las LIF entre clústeres. Mediante el uso de System Manager de ONTAP para los dos clústeres, puede crear las LIF de interconexión de clústeres necesarias en el panel Protection > Overview.

Para conectar los dos clústeres en relación de paridad, complete los siguientes pasos:

El Mediador ONTAP establece un quórum para los clústeres de ONTAP en una relación de SM-BC. Coordina la conmutación automática al nodo de respaldo cuando se detecta un fallo y ayuda a evitar situaciones de cerebro dividido cuando cada clúster intenta establecer el control simultáneamente como el clúster principal.

Antes de instalar el Mediador ONTAP, consulte "Instale o actualice el servicio Mediator de ONTAP" Página para requisitos previos, versiones compatibles de Linux y procedimientos para instalarlos en los distintos sistemas operativos Linux admitidos.

Una vez instalado el Mediador ONTAP, puede agregar el certificado de seguridad del Mediador ONTAP a los clústeres ONTAP y, a continuación, configurar el Mediador ONTAP en el panel Protección > Descripción general del Administrador del sistema. La siguiente captura de pantalla muestra la GUI de configuración del Mediador ONTAP.

Una vez que proporcione la información necesaria, el Mediador ONTAP configurado aparecerá en el panel Protección de System Manager > Descripción general.

Un grupo de coherencia ofrece una garantía de coherencia de orden de escritura para una carga de trabajo de aplicación que abarca una colección de volúmenes especificados. Para ONTAP 9.10.1, estas son algunas de las restricciones y limitaciones importantes.

Para obtener más detalles, consulte la documentación de ONTAP SM-BC en "restricciones y limitaciones".

Para la configuración de validación, se utilizó System Manager de ONTAP para crear los grupos de consistencia a fin de proteger los LUN de arranque de ESXi y los LUN de almacenes de datos compartidos en ambos sitios. Para acceder al cuadro de diálogo de creación de grupos de consistencia, vaya a Protection > Overview > Protect for Business Continuity > Protect Consistency Group. Para crear un grupo de consistencia, proporcione la información de la máquina virtual de almacenamiento de destino, clúster de origen y volumen de destino necesarios para la creación.

En la siguiente tabla, se enumeran los cuatro grupos de coherencia que se crean y los volúmenes que se incluyen en cada grupo de coherencia para la prueba de validación.

Después de crear los grupos de consistencia, se muestran bajo las respectivas relaciones de protección en el sitio A y en el sitio B.

Esta captura de pantalla muestra las relaciones de los grupos de consistencia en la instalación A.

Esta captura de pantalla muestra las relaciones de los grupos de consistencia en la instalación B.

Esta captura de pantalla muestra los detalles de las relaciones del grupo de coherencia para el grupo cg_infra_datastore_b.

Una vez que se han creado los grupos de coherencia, SnapMirror sincroniza los volúmenes de origen y de destino para que los datos siempre puedan estar sincronizados. Los volúmenes de destino en el sitio remoto transportan los nombres de los volúmenes con el fin _dest. Por ejemplo, para el volumen esxi_a en el sitio a un clúster, hay un volumen de protección de datos (DP) esxi_a_dest correspondiente en el sitio B.

Esta captura de pantalla muestra la información de volumen del sitio A.

Esta captura de pantalla muestra la información de volumen del sitio B.

Para facilitar una conmutación por error transparente de aplicaciones, los LUN reflejados de SM-BC también deben asignarse a los hosts del clúster de destino. Esto permite que los hosts vean correctamente las rutas a las LUN desde los clústeres de origen y de destino. La igroup show y.. lun show Las salidas para el sitio A y el sitio B se capturan en las dos capturas de pantalla siguientes. Con las asignaciones creadas, cada host ESXi del clúster ve su propio LUN de arranque SAN como ID 0 y los cuatro LUN de almacén de datos iSCSI compartidos.

Esta captura de pantalla muestra los iGroups del host y la asignación de LUN para el sitio A un clúster.

Esta captura de pantalla muestra los iGroups del host y la asignación de LUN para el clúster del sitio B.

"Siguiente: Validación de la solución - virtualización."