Diario instalación VNX5500

[tonin]

Para ir recogiendo los procesos de la instalación.

[tonin]

5/4/2011: Llega el cacharro. Viene como ultimamente pasa montado y cableado de fábrica. Se comprueba que incluye los componentes adquiridos.

[tonin]

6/4/2011: Reorganizo el cableado de fibra al objeto de liberar 4 puertos en nuestros switches EMC 4100 según ticket #7.

[tonin]

7/4/2011: Vienen los técnicos de BULL para proceder a la instalación. Tras comprobar el checklist y la configuración del cableado proceden a encenderlo. Detectan que las luces de alerta de las fuentes de alimentación de los DPE se quedan en fallo, aunque aparentemente todo funciona correcto. Abren un caso para solicitar nuevas fuentes por si acaso.

Yo no estoy presente durante todo el rato, aunque como sigo con la reorganización del cableado entro y salgo bastante, y veo que algo no va bien. Pasadas las 3 paramos y ellos continuan por la tarde.

[tonin]

8/4/2011: Me comunica Luis que Rafael Garrido de BULL le dice por teléfono que es posible que el equipo esté roto (por el problema de las alimentaciones) y que sea esto lo que les impide configurarlo bien. Yo por mi parte le pido por correo a Rafael que me informe sobre el estado de la instalación y los problemas que han surgido, así como que me indique los puertos que se dedican a la conectividad de la cabina a la LAN del cliente para el management, al efecto de poder conectar y ver el estado.

[tonin]

11/4/2011: Me llama Rafael para decirme los mismo que le dijo a Luis. Me comenta que el proceso de configuración les permite cambiar la IP a uno de los SP pero no al otro, y que después ya no autodetecta la MAC de los equipos por lo que se han quedado bloqueados en ese punto. El sospecha que es debido al problema con las alimentaciones.

Me dice de esperar a que lleguen las alimentaciones antes de continuar. Yo le digo que no, porque esas fuentes, caso de estar defectuosas ambas (cosa muy extraña), no deberían tener influencia en la visibilidad de los equipos desde la red en un momento si y en otro no. Así que quedamos en que se lleguen al dia siguiente.

Por la tarde reviso la documentación de powerlink al respecto de la instalación para hacerme una composición de lugar para el día siguiente.

[tonin]

12/4/2011: Acuden por la mañana. Les enseño como configurar el arranque de la control station conectando un monitor y un teclado y variando las opciones del kernel para que no redirija la consola al puerto serie. De esa forma vi que en el arranque de la CS llega un momento que se queda esperando a que se ejecute el procedimiento CSA (celerra stastup assistant).

Ellos habían ejecutado este procedimiento pero después de conectarse individualmente a los SP para cambiarles las IP públicas mediante el método ​http://<direccion ip del sp>/setup. Les comento que sospecho que dicho procedimiento no es aplicable a la nueva serie VNX que incluye switches ethernet internos que interconectan todos los componentes. En los modelos anteriores (CX4, CX3, etc) si se hacía así porque había que suministrar un concentrador para interconectarlos a todos, mientras que ahora los equipos mantienen direcciones de subredes privadas para el manejo, que nunca se alteran. Sospecho que con el procedimiento /setup han cambiado las IPs internas de los SPs, haciendo que la CS pierda la conectividad con ellos dando el problema que vieron el otro día de pérdida de conectividad.

Aún así, entrando a la CS por ssh, consigo llegar a conectar con los SP y consigo ver que el equipo se ha quedado en un estado "unconfigured" mientras que el proceso CSA aparentemente ha terminado. Decidimos que lo mejor es volver al estado de preconfiguración CSA y repetir el proceso usando solo el "VNX installation assistant" y no los métodos anteriores que parece que no aplican a estas cabinas.

Encuentro el documento primus emc166265

​http://knowledgebase.emc.com/emcice/documentDisplay.do?docType=1006&clusterName=DefaultCluster&resultType=5002&groupId=1&page=&docProp=$solution_id&docPropValue=emc166265&passedTitle=null

donde se explican los pasos a seguir. Nos encontramos con el problema de que el script S95cable_check que se borra tras la instalación y hay que restaurar hay que cogerlo de los CDs de instalación que no vienen con la máquina. Los ponemos a descargar y nos vamos a comer.

[tonin]

12/4/2011 (tarde): Una vez con el script (que salvo en /home/nasadmin por si acaso), aplico los pasos del primus anterior y reiniciamos la instalación, esta vez si va todo correcto y se meten los datos que va pidiendo el procedimiento.

Como último paso de la instalación, previo a la configuración, el procedimiento realiza un chequeo de los cables y la conectividad de los distintos elementos. Llega al 90% y da un fallo al comprobar la conectividad del SPA al SPS A (unidad de baterias). Cambiamos el cable que los comunica por el del SPB y reiniciamos el proceso, dando el mismo error. Hacemos un power cycle de los SPs (a veces esto arregla estos fallos), obteniendo el mismo error. Se intercambian las fuentes de alimentación e incluso se cruzan totalmente las conexiones a los SPS, pero siempre se para en el mismo sitio (cada prueba de estas aparte del tiempo de arranque implica restaurar el equipo al estado pre-CSA como indico antes).

[tonin]

12/4/2011 (bastante tarde ...): Los técnicos de BULL concluyen que o bien el SPS está defectuoso, o bien el problema debe estar relacionado con las alertas de las fuentes de los SPs ...

Yo les comento que independientemente de que pueda haber algún problema con ello, me extraña bastante pues los SPS no muestran ninguna luz de alarma. Les comento que la única forma que el procedimiento de instalación (que solo está conectado a la CS) tiene de detectar un fallo de comunicaciones con el SPS, es diciéndole al SP que pruebe dicha comunicación. Por tanto un fallo de comunicación entre la CS y el SP puede reportarse de esa manera. Aunque la prueba de conectividad pasa el punto de conexión al SP, la verdad es que a nivel de ping si la tiene. Pero para ejecutar comandos en el SP que interroguen por determinadas cosas usando navicli.

Pruebo la conexión de navicli desde la CS al SPA de la siguiente forma, obteniendo:

[nasadmin@vnxcs ~]$ /nas/sbin/navicli -h SPA getagent
/nas/sbin/classic_navicli -np -h 128.221.252.200 getagent 2>&1
Error returned from Agent
Agent denied request -- Caller not privileged.


Error returned from Agent
Agent denied request -- Caller not privileged.

Aparte compruebo que en el /tmp de la CS, el fichero factory_check.log contiene el mismo error, por lo que parece que los tiros pueden ir por ahí.

A última hora descubro el primus emc213226

​http://knowledgebase.emc.com/emcice/documentDisplay.do?docType=1006&clusterName=DefaultCluster&resultType=5002&groupId=1&page=&docProp=$solution_id&docPropValue=emc213226&passedTitle=null

donde ya desde su propio título ("How to correct SPS A test failure during CSA for the NX4")se deduce que es exactamente lo que nos está pasando. Efectivamente hace referencia a que no puede chequear la conectividad al SPS mediante el comando getcrus de navicli, porque lo que falla es el propio navicli al no estar el usuario autorizado para ello.

En este punto se marchan con esta información y quedamos a la espera de noticias.

[tonin]

13/4/2011: Realizo un power-cycle de los SPs que se quedaron con la luz de fallo, y rearrancan sin luces de fallo, pero una de las luces de link entre el SPA y el DM2 no se queda en azul sino en verde.

[tonin]

14/4/2011: Llamo a Rafael Garrido de Bull para preguntarle como va el asunto. Me comenta que por la mañana llegan las alimentaciones y que vendrán a cambiarlas en cuanto lleguen, hoy mismo.

Le pregunto sobre el plan en caso de que aun cambiando las alimentaciones sigan con la luz de fallo y si el procedimiento de instalación aborta en el mismo lugar del otro dia. Me comenta que en ese caso descartarían que ese fuera el problema y tendría que venir un especialista en este sistema o bien habilitarle la forma de que pueda conectarse remotamente a los puertos de mantenimiento de los cacharros.

Quedamos en que les dejo en el armario las instrucciones de poner la CS en estado pre-CSA (ya que el otro día lo hacía yo) para que puedan hacerlo ellos, y les doy mi movil por si necesitan algo más.

La luz de link que se quedó en verde el otro día ya está correctamente en azul. No se en que momento ha cambiado.

[tonin]

14/4/2011: Los técnicos de BULL cambian las fuentes de alimentación y ya no se quedan en fallo cuando arranca el vnx. Las nuevas son de la misma versión pero revisión A09, las antiguas son pone en una pegatina sobrepuesta revisión A09, pero la pegatina original es A08.

Aún así, como estaba más o menos previsto, el procedimiento CSA se queda en el mismo punto que el otro día. Quedo en llamarlos cuando acaben de comer para si han localizado un ingeniero de EMC que nos asista llegarme allí con ellos. Si no, no tiene mucho sentido.

[tonin]

14/4/2011: Me comentan que les han comunicado un comando pata intentar arreglar este problema, pero les da fallo al ejecutarlo. Me presento en el trabajo. El comando es naviseccli y el primer problema es que no estaban poniendo la ruta donde está (/nas/sbin), pero al final los argumentos también eran incorrectos (usa a la vez argumentos que el comando dice que son incompatibles).

Intentamos imaginarnos como iría más o menos la sintaxis correcta, pero no hay manera. Al igual que todos los comandos navicli dan error de acceso no autorizado al agente, todos los naviseccli dan error de que la seguridad no ha sido establecida.

Sospecho que el certificado, fichero de seguridad o lo que sea de la CS es incorrecto. Posiblemente si se trata de un certificado, se genero contras las IPs públicas de los SPs cuando estas se configuraron antes de tiempo por otro método antiguo. Si es así, es imposible acceder a los SPs con las ips privadas por ese medio.

Concluimos que hay que escalar el caso a un ingeniero de EMC, y no un ingeniero de BULL que trabaje con sistemas EMC. Quedan en iniciar las gestiones y les informo del horario del edificio la semana que viene, aunque en última instancia tienen mi móvil por si necesitan que llame a seguridad para que puedan acceder fuera del horario de mañana.

[tonin]

15/4/2011: Me llama Rafael Garrido y me dice que se ha puesto en contacto con la comercial de EMC, le ha pedido información para abrir un caso y ver como lo tratan ya que la instalación no ha sido contratada con ellos, aunque EMC se ha ofrecido a BULL a ayudarles en todo lo que puedan.

[tonin]

15/4/2011: Yo por si las moscas sigo leyéndome documentos de powerlink a ver si encuentro algo, aunque la mayoría de los relacionados ya me los se casi de memoria y he probado casi todo.

Pero como Dios existe, en la n-sima prueba de ver si el comando "/nas/sbin/navicli -h SPA getagent" me devuelve algo distinto a "caller not privileged", me confundo y tecleo naviseccli en lugar de navicli (naviseccli lo había probado con otros parámetros para algunas pruebas a las que me remitían los primus de powerlink).

Curiosamente "/nas/sbin/naviseccli -h SPA getagent" si me devuelve la información correcta. Investigando leo que navicli, que ahora invoca a un comando que se llama classic-navicli, es obsoleto y naviseccli es su alternativa mas segura. Los SPs se pueden configurar para que funcionen en modo clasico según dice el documento emc173093 de título "User sees 'Caller not privileged' error when running classic_navicli or navicli commands from the Celerra Control Station for arrays running Flare 26 or later."

Por supuesto nuestro flare es el 26 o posterior, pero es más, la opción "-enable classiccli" que referencia el documento no está implementada en el agente del VNX, seguramente han decidido dejar de soportarla.

Por otra parte el procedimiento CSA invoca constantemente navicli y no naviseccli, por lo que decido renombrar (nas/sbin/navicli como navicli.ORIG y enlazar navicli a naviseccli. De esa forma puedo invocar el comando getcrus de los SP que es el que en el fondo fallaba y ocasionaba que el CSA se detuviera testeando la conexión con el SPS A.

Llamo a Rafael y se lo comento. Yo no dispongo de la utilidad CSA, le digo que si me la pasa intento ejecutarla tras llevar a la CS al estado pre-CSA y ver si pasa del punto donde nos atrancamos el otro dia, y así no los hago venir si no va bien. Me dice que si.

[tonin]

15/4/2011 (tarde): Sobre las 18 horas que me quedo libre, lo llamo y me dice que ya la ha metido en la consigna (intentó mandarla por mail pero pesa 109Mb). Me voy para el trabajo.

Conecto el portatil al HUB, reboto la CS y ejecuto el procedimiento CSA (ya había puesto la CS en estado pre-CSA). Introduzco los datos de IPs públicas de los SPs, DNS, gateway, NTP, etc; marco las licencias NFS y CIFS y comienza el chequeo pasando con éxito la prueba de conexión con el SPS A y SPS B y pasa a la siguiente pantalla, donde permite revisar los datos antes de aplicar la configuración.

Llamo a Rafael para decírselo y le pregunto si continuo para ver si se atranca más adelante. El me confirma que más adelante no pedirá ningún dato que yo no sepa, por lo que avanzo.

Tras unos minutos, la pantalla de la utilidad CSA se queda en blanco y no responde. Conectando paralelamente a la CS veo que en el fichero /etc/hosts ha configurado ya la dirección pública del SPA, pero que este no está accesible por ping ....

Como esto me parece haberlo leido antes, me voy a powerlink y encuentro el documento emc261729 con título "VNX Installation Assistant stalls and screen display goes blank during File/Unified? VNX system initialization".

El párrafo del "root cause" dice:

The VIA application hang issue will be fixed in the next release of the VNX OE for File software.  As a User, it is important to know that you should not "kill" the VIA application immediately, but let it run for a minimum of 15 minutes.  Despite the VIA screen display symptoms, the underlying work for the pre-configuration steps are being executed and will generally complete successfully if undisturbed. The main "residual" effect of the application hang is that the Control Station IP address may not be properly "fused" to the storage domain, which in this release, is required for the File and Block components to be managed by Unisphere. If a system is not properly "fused" together, the User will be unable to log into Unisphere.

y hace referencia a la versión 7.0.12.0 del CSA, que es precisamente el que me han pasado. Como inicialmente recomienda esperar unos 15 o 20 minutos, espero monitorizando que es lo que hace en la CS y compruebo como tras un tiempo da marcha atrás y vuelve a colocar en el /etc/hosts la dirección IP interna del SPA. Seguramente el CSA ha fallado y deshace los cambios.

Las recomendaciones de la opción 2 de resolución no funcionan. Decido dejarlo e informar a BULL para que tengan más info.

[tonin]

Tengo un problema .... soy muy cabezota. Cuando me estoy montando en el coche me vuelvo para probar lo mismo pero con la cabina desenchufada de nuestra red y conectado a la CS por un cable cruzado. En principio esto no es lo que dice el procedimiento CSA, pero como el procedimiento de las narices está lleno de agujeros, decido llevarle la contraria.

Me parto de risa cuando llegado al punto donde se quedaba la pantalla en blanco ahora no se queda, y al menos puedo ver que está haciendo. Salen mensajes de configurando el tomcat, configurando varios servicios, etc y en un momento, al 23% llega al punto peliagudo donde intenta cambiar la IP del SPA. Ahí se detiene un buen rato, falla y dice que lo reintentará. Tras otros pocos minutos el procedimiento da un fallo y ya no continua.

En realidad esto ya me lo imaginaba sin verlo. Como me deja un botón de retry en la pantalla, me digo que ya que el no ha podido cambiar la IP de los SPs, pues yo le hecho una manita, y ya por supuesto paso de mirar el powerlink y prefiero confiar en mi intuición.

Desde la CS, con el comando navicli (naviseccli en realidad porque lo tengo "hackeado" :) ) ejecuto:

/nas/sbin/navicli -h SPA networkadmin -set -ipv4 -address 192.168.110.217 -subnetmask 255.255.255.0 -gateway 192.168.110.1

(lo pongo de memoria, pero creo que es así). Hago lo mismo para el SPB. Compruebo que tengo conectividad con los SPs y no la tengo, por lo que vuelvo a conectar los cables de los SPs a nuestra red junto a la CS dejando de usar el cable cruzado. Modifico a mano el fichero /etc/hosts con las nuevas direcciones y el fichero /nas/site/sp_info que también tiene estas direcciones (esto si lo saco del documento emc261729). En realidad estoy intentando a mano llegar a que las comprobaciones que me dice dicho documento que aseguran que el sistema está funcionando correctamente sean lo más fieles posibles a él.

Me funcionan todas las comprobaciones que dice, salvo la de "/nas/sbin/clariion_mgmt -info" que me sigue dando "Error 12: System unconfigured". Teoricamente, cuando este comando devuelva la salida correcta, todo estaría bien. La salida correcta sería algo así como:

# /nasmcd/sbin/clariion_mgmt -info
Public IP address for SPA: 10.241.155.200
Public IP address for SPB: 10.241.155.201
Start on boot            : yes
Current implementation   : Proxy-ARP
Status                   : Started

pero con las direcciones IP nuestras. Previamente ejecuto el comando "nas_storage -list", y con lo que me devuelve que es el nombre del sistema, ejecuto "nas_storage -modify EL_NOMBRE_QUE ME DEVOLVIO -network -spa 192.168.110.217 -spb 192.168.110.218", que termina satisfactoriamente.

Como "clariion_mgmt -info" devuelve unconfigured, y yo he puesto ya manualmente las IPs de los SPs y he editado los ficheros de hosts, pruebo a ver si dándole al botón RETRY del programa CSA canta la rana.

Y la rana canta. Pasa rápido donde se quedaba antes poniendo las direcciones de los SPs (al encontrárselas ya cambiadas) y salen un montón de pasos de aplicar licencias, configurar servicios, etc. todos con éxito.

[tonin]

Llegado aquí el CSA vuelve a una pantalla donde ya se puede desde provisionar discos, configurar FS o bien lanzar la consola Unisphere. Decido lanzar la consola.

A diferencia del otro día donde la consola se intentó lanzar contra las IPs de los SPs, ahora la consola se lanza contra la IP de la CS. Llego a la ventana de logon, pongo las credenciales nasadmin y tras un rato me salta una ventana de advertencia sobre el certificado del SPA. Me dice que no es válido.

En los detalles del certificado veo que el muy cachondo ha generado los certificados con fecha de validez desde las 23:15 del 15 de Abril de 2011, osea, dentro de unas cuantas horas.

Me supongo que dentro de la amistad que el cacharro este y yo estamos entablando, ha decidido decirme subliminalmente que lo deje por unas horas y que me vaya a descansar :). Así que esta vez si, a las 20:15 mas o menos, me monto en el coche y me voy a casa, esta vez casi con la completa seguridad de que cuando pruebe después de las 23:15 (o mañana si consigo contenerme) podré conectar por fin a Unisphere y comenzar a manejar el cacharro.

[tonin]

Por supuesto se me ha olvidado comentar que el comando "clariion_mgmt -info" ejecutado desde la CS devuelve la salida correcta en este punto.

[tonin]

16/4/2011: Hubo suerte. La consola unisphere funciona aparentemente bien. Habrá que revisar el resto de la configuración ya desde la propia consola. Solo veo unas alertas importantes respecto al servidor NTP.

[tonin]

EMC ha revisado la instalación y dice que está correcta. Solo 2 detalles de NTP y DNS que no van en los DM pues aun no tienen conectividad de red, y que aun no se ha definido ningún spare.

[tonin]

He tenido problemas para acceder a las IPs de los antiguos elementos del almacenamiento (SPs, CS y switches). El Hub presentaba muchas colisiones. He dejado solo conectado al hub los elementos antiguos y el puerto de MGMT de la CS del VNX. De esta forma se ha solucionado el problema.

Parece que los switches internos del VNX podrían estar haciendo algún bucle que al no tener un switch con spanning tree no era capaz de resolver. Ahora todo es accesible.

No se si la configuración de cableado requerirá enchufar líneas de los SPs del VNX a la red de cliente directamente, o si todo ha de pasar por la CS. Cuando venga el ingeniero de BULL que nos ayudará con la migración lo aclararemos, caso de hacer falta tendriamos que colocar un switch en lugar del router.

[tonin]

Como hoy es fiesta en Valencia y el ingeniero de BULL viene de allí, no me ha llamado. Para adelantar trabajo estoy instalando las licencias de los productos que hemos comprado para el VNX (Fast, thin provisioning, compression enabler, San copy, Local protection, etc).

La instalación se hace con USM (unisphere service manager) y es lenta pues al ser NDU rebota los SPs seriadamente, así que con esto nos ahorramos media mañana de trabajo).

[tonin]

CONFIGURACION DE CACHE

Tras la instalación de los enablers, la memoria usada por el sistema se ha incrementado mucho, hasta 7GB. Ya advirtió al instalar las licencias de que desactivaría la caché de lectura. Así fue y se quedó con toda la memoria cache configurada para escritura. He reactivado la cache de lectura de los SPs usando un 40% para escritura, 60% para lectura.

Así mismo he configurado los dos discos SSD para Fast Cache, con solo esos 2 tenemos poco margen para hacer auto-tiering con ellos, y EMC recomienda usarlos para FASTCache.

[tonin]

CONFIGURACION DE RED

He definido los puertos de los DM con la misma configuración que en la cabina anterior, los 4 agreagados con LACP. Sobre ellos he montado dos interfaces virtuales con las direcciones 150.214.110.204 y 150.214.110.205 correspondientes a nfs_alt y cifs_alt. He definido la ruta 0.0.0.0 a través del primero de estos interfaces hacia 150.214.110.1, y he añadido el DNS de windows también.

Ya accede correctamente al NTP, aunque da un warning intentando acceder al segundo que le he configurado del CICA (150.214.5.120), lo cambio por otro nuestro (150.214.110.252).

[tonin]

Las labores de instalación básicas están terminadas. La configuración continua con la ayuda de Bull.