Replicación entre dos HP EVA 4400 con Continuous Access

Continuous Access, es la replicación nativa de las cabinas HP StorageWorks Enterprise Virtual Array Family (EVA). Veremos la configuración necesaria tanto a nivel de Switch de SAN como a nivel de Command View (CV) para realizar replicación sincrona o asincrona (dependiento de las ubicaciones por ejemplo).

No puedo empezar sin antes mencionar que para realizar este tipo de replicación es necesario disponer de licenciamiento específico (segun las especificaciones de tu EVA…), es decir, si tenemos una licencia de CV para 4Tb y deseamos replicarlos, deberemos adquirir una licencia de Continuous Access de 4Tb.

En mi caso: (licencia ilimitada tanto en CV como en CA 🙂 )

Dicho esto, os presento el entorno a configurar: dos CPDs en un mismo edificio (A, B) con dos switches de fibra en cada uno (11 y 12, 21 y 22). En cada CPD, dos HP EVA’s 4400 con un solo grupo de discos (12HD 300Gb de fibra); además, un servidor que ejercerá de Command View en cada CPD (CV_A y CV_B) y para terminar, una infraestructura de virtualización dividida entre los dos CPDs (4 ESX en CPD A y 2 ESX en CPD B, con un solo vCenter en el servidor CV_A. Todas las fibras van por doble camino a excepción de los dos servidores ‘CV’ que disponen de una sola HBA.

Con la infraestructura presentada, lo primero que debemos hacer es configurar correctamente el zoning de los switches de fibra para que los dos CV sean capaces de ver la cabina del CPD contrario. Esto es un requisito para realizar la replicación; así que al finalizar, dispondremos de dos CV desde donde podemos administrar nuestras dos EVAs.

En el Switch 11 (el primero del CPD A), tengo configuradas las siguientes zonas:

ZONA_CA_Port1: Es la zona que contiene los puertos 1 de ambas controladoras de ambas EVAs.
ZONA_CPDA_ESX’x’_Port1_EVAA: Es la zona que contiene la primera HBA del ESX1 con acceso a los puertos 1 de ambas controladoras de la EVA del CPD A.
ZONA_CPDB_CV2_EVA: Es la zona donde doy permisos al CV2 a los puertos 1 de ambas controladoras de ambas EVAs.

En el Switch 12 (el segundo del CPD A), tengo configuradas las siguientes zonas: (Este switch es el que tiene conectado el CV1)

ZONA_CA_Port2: Es la zona que contiene los puertos 2 de ambas controladoras de ambas EVAs.
ZONA_CPDA_ESX’x’_Port2_EVAA: Es la zona que contiene la segunda HBA del ESX’x’ con acceso a los puertos 2 de ambas controladoras de la EVA del CPD A.
ZONA_CPDB_CV1_EVA: Es la zona donde doy permisos al CV1 a los puertos 2 de ambas controladoras de ambas EVAs.

En el Switch 21 (el primero del CPD B), tengo configuradas las siguientes zonas: (Este switch es el que tiene conectado el CV2)

ZONA_CA_Port1: Es la zona que contiene los puertos 2 de ambas controladoras de ambas EVAs.
ZONA_CPDA_ESX’x’_Port1_EVAA: Es la zona que contiene la primera HBA del ESX’x’ con acceso a los puertos 1 de ambas controladoras de la EVA del CPD A.
ZONA_CPDB_CV2_EVA: Es la zona donde doy permisos al CV2 a los puertos 2 de ambas controladoras de ambas EVAs.

En el Switch 22 (el segundo del CPD B), tengo configuradas las siguientes zonas:

ZONA_CA_Port2: Es la zona que contiene los puertos 2 de ambas controladoras de ambas EVAs.
ZONA_CPDA_ESX’x’_Port2_EVAA: Es la zona que contiene la primera HBA del ESX’x’ con acceso a los puertos 2 de ambas controladoras de la EVA del CPD A.
ZONA_CPDB_CV1_EVA: Es la zona donde doy permisos al CV1 a los puertos 2 de ambas controladoras de ambas EVAs.

Hay que mencionar, que lo ideal, es permitir a las zonas de los ESX el acceso a los puertos de la EVA del CPD B, así si tuvieramos que pasar la infraestructura a trabajar contra la EVA del CPD B, tendriamos la mitad del trabajo hecho.

Con la configuración de zoning anterior, conseguimos que los CV de ambos CPDs sean capaces de administrar las dos EVAs como se muestra en la imagen.

Lo primero que tendremos que configurar para empezar a replicar, es un DR Group o Data Replication Group. En estos, deberemos agrupar aquellas LUNs del mismo tipo; en mi caso, tengo varias LUN que sirven como DataStores en VMware por lo que crearé un único DRGroup para dichas LUNs.

Para ello, pincharemos sobre “Data Replication” y “Create Data Replication Group”.

En la primera parte, tenemos el nombre del DRG, el origen que toma por defecto es la EVA desde donde estas creando el grupo de replicación. El destino, marcaremos la EVA a la que queremos replicar… como en mi caso solo tengo dos, no tengo posibilidad a fallo… El Source Vdisk, es la LUN que deseamos replicar. (cada LUN solo puede estar en un DRGroup)

En la segunda parte, digamos que tenemos las opciones “avanzadas”:

Write mode: Mode de escritura, sincrono o asincrono:
- Synchronous. This mode provides the best data protection. In synchronous write mode, the array acknowledges I/O completion after the data is cached on the source and destination arrays. This process maintains identical data on a source DR group and its destination DR group at all times.
- Asynchronous. This mode provides the best host I/O performance. In asynchronous write mode, the source array acknowledges host writes before the data is replicated on the destination array. This process allows faster host I/O than synchronous mode. From a data protection standpoint, there can be brief instances in which the data is not identical in the source and destination DR group. Asynchronous write mode can be basic or enhanced, depending on the controller software version.

Destination Disk Group: Grupo de discos de destino. En mi caso, como solo tengo una bandeja de discos por EVA, solamente tengo un Disk Group.
Destination redundancy: Podemos modificar el nivel de RAID del destino o dejar como en el origen…
Destination host access: podemos establecer el nivel de acceso que tendra la LUN…
Log Size: Tamaño de LOG. ¡¡OJO!! El tamaño de log por defecto a partir del firm 9.0.0 es de 102,40Gb. Los logs se guardan con una redundancia RAID1 y en las dos cabinas asi que ojito con el espacio que teneis disponible… yo lo he establecido en 10240Mb… que me parece más que suficiente.
Source Log Disk Group: El grupo de disco donde se guarden los LOGs en el origen. Esto podria ser util si tenemos dos grups de discos con diferentes coenxiones. FIBRA frente a FATA por ejemplo.
Destination Log Disk Group: El grupo de disco donde se guarden los LOGs en el origen.
Failsafe on unavail member: Failsafe data protection is a feature which blocks host I/O to all of the virtual disks in a DR group when components fail or become unavailable. This feature protects data by maintaining write ordering in the source and destination DR groups. (no hya mejor explicación)…
Suspend on links down: Suspende la replica si algun link se encuentra en estado Down.
Suspend on full copy: Si esta ‘enable’ la replicacion remota se suspende cuando se lanza una ‘full copy’.
comments: No comments…

una vez elegidas las opciones, arriba le pulsaremos sobre “Create” y empezará la primera ‘full copy’. Cuidado cuando lo lanzais puesto que puede repercutir en el rendimiento del sistema…

Una vez creado y terminada la primera replica, si hemos seleccionado el modo de escritura sincrono estará en continuo cambio “origen-destino”. No obstante, seleccionando el DRGroup en cuestion y navengando por las pestañas que aparecen en la imagen, podemos volver a cambiar todas las opciones que se dan en el momento de su creación. Ademas de ver el estado de la replica…

Si quiesieramos añadir una LUN a un DRGroup ya creado, lo tendremos que hacer desde las propiedades de la LUN sobre la pestaña de DataReplication, Add member.