Diario migración VNX5500

[tonin]

Para ir anotando todas las incidencias relativas a la migración del VNX5500

[emcbull]

Prueba de que emcbull puede postear

[tonin]

ACTIVAR REPLICATOR V2 EN CS_UCO

nas_license -remove replicator
/nas/sbin/deploy_replication -v2 -upgrade_mode
nas_license -create replicatorV2

Nota: No recuerdo si el segundo y tercer paso van así o cambiados de orden

[tonin]

Hay que upgradear cs_uco a la versión 6 para poder replicar contra el VNX.

[tonin]

ESTABLECER SESIONES DE SAN COPY MANUALMENTE

Mientras que averiguamos la forma de hacerlo correctamente, es posible copiar con san copy poniendo directamente el WWN de la LUN destino al definir la sesión.

Se copia la LUN del ibmblade13. Una vez terminada se apaga ibmblade13, se crea el zoning para que vea el VNX, se crea el storage group para esta maquina en VNX y se retira la LUN original del storage group del CX.

Al rebotar se comprueba entrando en la BIOS de la QLogic escaneando el bus de fibra que aparecen los caminos al CX con LUNZ, mientras que al nuevo aparecen como VRAID. Reconoce el disco y arranca correctamente.

La versión de powerpath instalada no ve la cabina nueva. Se actualiza a powerpath 5.5, pero aparecen múltiples problemas, de hecho una vez desinstalada la 4 y con el servicio de la 5.5 arrancado, no aparece ninguna cabina, y reinstalando PP el equipo se cuelga.

Se sigue esto en el ticket #14

[emcbull]

Martes 03/05/2011
Primera toma de contacto con el VNX5500 para verificar funcionamiento y plantear junto a la informática de la UCO el planteamiento a seguir durante la migración.

Se plantea usar Replicator V2 para la migración de los File Systems del Celerra y SAN Copy para la migración de la parte de bloques del Clariion.

Lo primero, se conectan los nuevos SP's a los switches de fibra y se crean los ALIAS necesarios. En resumen, se mapean cuatro puertos por SP: los puertos 2 y 3 que el VNX tiene integrados y los puertos 0 y 1 del módulo de expansión de puertos de fibra. Se conectan los puertos pares del SPA al switch con IP 192.168.110.210 y los impares al switch con IP 192.168.110.211, mientras que los puertos del SPB se conectan a la inversa (usando la actual topolgía que tienen en la Universidad), es decir, se conectan los puertos pares al switch 211, y los impares al switch 210.
Antes de salvar la nueva configuración, creamos una copia de la actual por si surgiera algún problema.

Se intenta establecer la conexión entre las dos cabinas para la migración del Celerra tal como se indica en los manuales de configuración del Replicator, pero encontramos problemas para establecerla. Nos indica que las versiones de Celerra no son compatibles, por lo que quedamos en investigar una posible solución al problema.

Se realizan las zonas necesarias para poder usar SAN Copy entre las dos cabinas de discos. Se crean 8 nuevas zonas:

• CX3_SPA_00-VNX55_SPA_00
• CX3_SPA_00-VNX55_SPB_00
• CX3_SPB_00-VNX55_SPA_00
• CX3_SPB_00-VNX55_SPB_00
• CX3_SPA_01-VNX55_SPA_01
• CX3_SPA_01-VNX55_SPB_01
• CX3_SPB_01-VNX55_SPA_01
• CX3_SPB_01-VNX55_SPB_01

De esta manera establecemos dos posibles caminos para la migración, usando los puertos 00 de los SP's y los puertos 01.

[emcbull]

Miercoles 04/05/2011

Según documentación de EMC, es necesario actualizar el NS40 a la versión 6 del DART para que sea compatible con la versión instalada en el VNX. Debido a que la migración requiere un corte del servicio (de aproximadamente 10 minutos), se plantear lanzar la actualización a media mañana para que el corte se realice al medio día.

Se realizan las comprobación del sistema para asegurar que la actualización se realizará sin incidentes.

Según las comprobaciones, el filesystem /nas/dos no dispone del espacio libre necesario para realizar la migración, por lo que se libera espacio moviendo el archivo "nas_old.exe" a la ubicación /home/nasadmin. Se mueve este archivo ya que no es una dependencia de ningún servicio de la nas.

También nos avisa que el export del filesystem NEWMAIL tiene alguna opción incorrecta, por lo que es necesario desmontarlo y volverlo a montar para solucionar el problema.

Una vez pasados correctamente todos los test, se lanza el proceso de migración usando el Unisphere Service Manager, tal como indica el procedimiento de migración de EMC.

Cuando volvemos de comer, el proceso a avanzado y está a la espera de realizar los reboots necesarios de los datamovers, lo que provocará el corte previsto. Se realiza el reboot y poco después finaliza la actualización satisfactoriamente.

Se activan las licencias del Replicator V2 en el NS40:

nas_license -remove replicator
/nas/sbin/deploy_replication -v2 -upgrade_mode
nas_license -create replicatorV2

Establecemos las conexiones necesarias para el correcto funcionamiento del Replicator V2.

• Primero establecemos la comunicación entre las Control Stations:

Ejecutamos el siguiente comando en cs_uco

nas_cel -create vnxcs -ip 192.168.110.219 -passphrase nasadmin

Ejecutamos el siguiente comando en vnxcs

nas_cel -create cs_uco -ip 192.168.110.209 -passphrase nasadmin

-El siguiente paso es establecer la comunicación entre los datamovers que participarán en el proceso de réplica. En nuestro caso se trata de los datamovers "server_2" de ambas cabinas:

Ejecutamos el siguiente comando en cs_uco

nas_cel -interconnect -create cs_uco_vnxcs_nfs -source_server server_2 -destination_system vnx_cs -destination_server server_2 -source_interfaces ip=150.214.110.67 -destination_interfaces ip=150.214.110.204

Ejecutamos el siguiente comando en vnxcs

nas_cel -interconnect -create vnxcs_cs_uco_nfs -source_server server_2 -destination_system cs_uco -destination_server server_2 -source_interfaces ip=150.214.110.204 -destination_interfaces ip=150.214.110.67

Una vez establecida la comunicación, procedemos a realizar una prueba realizando una replica incremental del filesystem NEWMAIL. Para ello, procedemos primero a crear un Storage Pool con 20 discos de 300GB SAS distribuidos en la cabina de la siguiente forma:

Bus 0 Enclosure 2 Disk 0 Bus 1 Enclosure 0 Disk 0
Bus 0 Enclosure 2 Disk 1 Bus 1 Enclosure 0 Disk 1
Bus 0 Enclosure 2 Disk 2 Bus 1 Enclosure 0 Disk 2
Bus 0 Enclosure 2 Disk 3 Bus 1 Enclosure 0 Disk 3
Bus 0 Enclosure 2 Disk 4 Bus 1 Enclosure 0 Disk 4
Bus 0 Enclosure 2 Disk 5 Bus 1 Enclosure 0 Disk 5
Bus 0 Enclosure 2 Disk 6 Bus 1 Enclosure 0 Disk 6
Bus 0 Enclosure 2 Disk 7 Bus 1 Enclosure 0 Disk 7
Bus 0 Enclosure 2 Disk 8 Bus 1 Enclosure 0 Disk 8
Bus 0 Enclosure 2 Disk 9 Bus 1 Enclosure 0 Disk 9

En este Storage Pool, llamado "Pool Correo", creamos una única LUN usando todo el espacio disponible y la asignamos al Storage Group "~filestorage", que es el que contiene el espacio asignado a los servidores de ficheros, y realizamos un rescan del almacenamiento desde la parte File del VNX para que lo reconozca.

Lo siguiente es crear una nueva sesión de réplica incremental desde la máquina cs_uco, seleccionando como destino la máquina vnxcs, usando la conexión cs_uco_vnxcs_nfs creada anteriormente y le indicamos que usé el pool "Pool Correo" para que cree el filesytem destino automaticamente.

Se deja lanzada la sesión, la cual nos indica que acabará sobre las 6:00 am del día 5.

---

En cuanto a la migración de la parte de la SAN, se crea un Storage Group especifico para alojar las LUN's que serán migradas mediante SAN Copy, y se le asignan los puertos que el día anterior mapeamos. Este Storage Group se crea tanto en la máquina cs_uco como en vnxcs.

Se intenta realizar una nueva sesión de SAN Copy de pruebas usando como orígen la LUN asignada actualmente a la máquina BLADE13. Para ello, lo primero es crear una LUN con identicas caracteristicas en el sistema destino y asignarla al Storage Group destinado a SAN Copy.

El siguiente paso es crear una nueva sesión de SAN Copy. Esto se realiza mediante el Wizard incluido en Unisphere, en el cual nos pide seleccionar el sistema origen desde el que se desea copiar la LUN. A continuación nos pide escoger la LUN a migrar. El siguiente paso es seleccionar el sistema destino y la LUN donde se copiará la de origen.

En este paso surge un problema ya que no se detecta el sistema destino, por lo que no podemos seleccionar donde vamos a realizar la migración. El sistema nos da la opción de añadir la LUN destino usando su WWN, pero al introducirlo nos aparece una LUN que la muestra como desconocida, por lo que decidimos no proseguir con el proceso hasta informarnos mejor.

[emcbull]

Jueves 05/05/2011

Comprobamos que la sesion de replica lanzada el día anterior ha acabado correctamente y exportamos en modo solo lectura el file system creado para verificar que la migración ha sido correcta.

Después de las pruebas realizadas por parte de la Universidad, procedemos a crear nuevas sesiones de réplica para terminar de migrar los file systems correspondientes al sistema de correo, esto es: NEWMAIL1 y NEWMAIL2.

---

Habrimos un caso en EMC para tratar de solucionar el problema con SAN Copy: SR=40725488. Me indican que me llamarán a lo largo de la mañana para tratar de solucionar el problema.

Como indica Toni en un comentario anterior, se realiza una sesión de SAN Copy introduciendo el WWN de la LUN destino a mano. Cuando acaba, se mapea el servidor en el VNX y se le asigna la lun migrada.

La máquina arranca correctamente pero da problemas de PowerPath?. Se decide actualizar la version de PowerPath? a la versión 5.5, pero da problemas, por lo que actualizamos a la versión 5.3 SP1. Esta versión se instala correctamente, pero no llega a ver los dispositivos instalados ni a configurar los paths.

Toni, en cuanto puedas, prueba a ejecutar desde el cmd de windows del Blade13 el comando:

powermt config

[emcbull]

Viernes 06/05/2011

Me llaman de EMC respecto a la incidencia abierta ayer y me confirman lo siguiente (corto y pego el correo que me han mandad):

Features not supported in Unisphere v 1.1
 
The following items are not supported in this release:
◆ Adding/removing systems - This release supports management of a single
VNX.
◆ Managing multi-domain configurations
◆ Managing a legacy CLARiiON or Celerra
◆ Login in to just the Block or the File portion of a unified system using
Unisphere. If either the Block or the File portion of the system is down, you
cannot log in.
◆ Local scope login to Unisphere is not supported; only Global scope login is
supported.
◆ Unisphere over ESRS is not supported for File/Unified VNX systems.
◆ Static NAT (Network Address Translation) is not supported via the Unisphere
Client for Unified or File only systems.

Me comentan que la única opción disponible de momento es utilizar el WWN de la LUN. Dicen que desconocen si en versiones sucesivas de unisphere se podrán añadir CX3 al dominio, ya que son cabinas que en poco tiempo estarán como EOL.

[tonin]

Efectivamente, tal como dice el documento ​http://www.emc.com/collateral/hardware/white-papers/h8173-migrating-clariion-vnx-san-copy-wp.pdf la única manera de migrar con sancopy entre sistemas clariion y vnx es usando WWN directamente.

Aunque en principio nos daba un poco de miedo dada la posibilidad de cometer errores al teclear el WWN, he visto que con la opción de informes de unisphere podemos sacar un informe de luns en el navegador sobre el que cortar/pegar el WWN correspondiente reduciendo el riesgo de error. Adoptaremos este método.

[tonin]

Movemos la información sobre los problemas de powerpath al hilo correspondiente que es #14

[tonin]

Se crea el hito SANUCO 1.1 con tickets específicos para las migraciones. Paso este propio ticket a 1.1

[tonin]

Migración Bladecenter1: #32