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).

Ez naiz hasi ahal izango lehenik aipatu gabe mota honetako errepikazioa egiteko lizentzia berezia behar dela (zure EVA-ren zehaztapenak kontuan hartuta…), hau da, CV lizentzia bat badugu 4Tb-rako eta errepikatu nahi baditugu, Continuous Access lizentzia bat erosi beharko dugu 4Tb-rako.

nire kasuan: (lizentzia mugagabea bai CV-n bai CA-n 🙂 )

Hori esan ondoren, konfiguratu beharreko ingurunea aurkezten dizuet: bi CPD eraikin berean (A, B) bi fibreko switch bi bakoitzean (11 eta 12, 21 eta 22). CPD bakoitzean, bi HP EVA 4400 disko talde bakarrekin (12HD 300Gb fibra); gainera, Command View gisa jardungo duen zerbitzari bat CPD bakoitzean (CV_A eta CV_B) eta bukatzeko, birtualizazio azpiegitura bat bi CPDen artean banatuta (4 ESX CPD A-n eta 2 ESX CPD B-n, vCenter bakarra CV_A zerbitzarian. Todas las fibras van por doble camino a excepción de los dos servidores ‘CVque 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’xcon 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’xcon 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’xcon 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 sobreData Replication” eta “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 replicarcomo 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 “aurreradas”:

  • Idazketa modua: Escritura modua, sincrono o asincrono:
    • Sinkrono. Modu honek datuen babes onena eskaintzen du. Sinkronizatutako idazketa moduan, Arrayak I/O osatzea onartzen du iturburu eta helmuga arrayetan cacheatu ondoren. Prozesu honek datu berdinak mantentzen ditu iturri eta helmuga DR taldean une oro.
    • Asinkronoak. Modu honek host I/O errendimendu onena eskaintzen du. Asinkrono idazketa moduan, iturburu arrayak host idazketak onartzen ditu datuak helmugako arrayan erreplikatu aurretik. Prozesu honek host I/O azkarragoa ahalbidetzen du sinkrono modua baino. Datuen babesaren ikuspegitik, batzuetan datuak ez dira berdinak iturri eta helmuga DR taldeetan. Asinkrono idazketa modua izan daiteke basic edo hobetu, kontroladorearen software bertsioaren arabera.
  • Helmugako Disko Taldea: Helmugako disko talde. nire kasuan, EVA bakarreko disko bandeja bakarra daukadalako, Disko Talde bakarra daukat.
  • Helmugako redundantzia: Helmugako RAID maila aldatu dezakegu edo jatorrian utzi…
  • Helmugako host sarbidea: LUNek izango duen sarbidea ezarri dezakegu…
  • Log Tamaina: LOGaren tamaina. ADI!! Defektuzko log tamaina firmatik aurrera 9.0.0 da 102,40Gb. Logak RAID1 redundantziarekin gordetzen dira eta bi kabinatan daude, beraz adi egon espazioarekin… Ni 10240Mb-ean ezarri dut… nahikoa dela iruditzen zait.
  • Jatorrizko Log Disko Taldea: LOGak gordeko diren jatorrizko disko taldea. Hau erabilgarria izan daiteke bi disko talde ditugunean eta konekzio desberdinak badituzte. FIBRA frente a FATA por ejemplo.
  • Destination Log Disk Group: LOGak gordeko diren jatorrizko disko taldea.
  • 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 ‘enablela replicacion remota se suspende cuando se lanza una ‘full copy’.
  • comments: No comments

una vez elegidas las opciones, arriba le pulsaremos sobre “Egin” 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 question 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 propietateak de la LUN sobre la pestaña de DataReplication, Gehitu kidea.

  • DR Group: Nos permite indicar algun de los DRG ya creados
  • Destination disk group: el grupo de discos de destino
  • Destination redundancy level: El niveau de RAID en el destino.

Podriamos tambien desde hemen, saltar a crear un DRG nuevo, con el boton “DR taldea sortu”…

Así es como se muestra la pestañana Members de un DRGroup con 3 LUNs replicando.


Izenburuko mezuak

Egilea

nheobug@bujarra.com
Autor del blog Bujarra.com Cualquier necesidad que tengas, ez zalantzarik izan nirekin harremanetan jartzeko, ahal duzun guztietan laguntzen saiatuko naiz, partekatu ahal dudan guztietan ;) . Dokumentuez gozatu!!!

DAG Exchange-n ezartzea 2010

26 uztailaren 2010