Enterprise Vault con almacenamiento en EMC Centera va muy lento

Esta entrada, más que un articulo técnico es una demostración de por qué todos tenemos que ponernos de acuerdo en un departamento de TI. Operaciones, comunicaciones, helpdesk, todos tenemos que ser parte de un uno o de lo contrario pueden pasar cosas como estas.

Trabajar con entornos heredados es muy complicado, por lo general son entornos con tecnolgías muy antiguas, mal diseñadas, sin soporte y, peor aun, sin documentacion.

Nuestro entorno de Enterprise Vault iba muy bien hasta que un día, sin razón aparente, empezó a ir muy lento. Cuando digo lento me refiero a que la restauración de un elemento archivado tardaba entre un minuto y cinco minutos (y a veces daba timeout). Antes de esto la restauración tardaba unos 15 segundos, que no es muy rápido, pero parecía razonable.

Procedimos a la rutina de resolver problemas:

  • Revisar los logs de Enterprise Vault: no hay errores.
  • Revisar los logs de Windows: no hay errores
  • Revisar los logs de Centera: no hay errores. La tasa de I/O está casi en 0, por lo que no puede ser un problema de sobrecarga.
  • Llamar a soporte de Symantec: “Nosotros vemos todo OK, debe ser problema de EMC”.
  • Llamar a soporte de EMC: “Nosotros vemos todo OK, debe ser problema de Symantec”.

Llegados a este punto, solo quedaba irse a un rincón a llorar. ¿A quién llamamos? Por lo visto nadie sabe nada de estos sistemas.

Nos secamos las lagrimas y entramos en modo “por mis cojones que resuelvo esto”. No tiene sentido que todo vaya mal de un día al otro sin motivo alguno.

Afortunadamente, tengo algunos conocimientos de programación y sabía que en alguna parte se podía activar el debug log de la API de Centera.

Revisando el log vi que cuando el Enterprise Vault se conectaba a la Centera esta le entregaba un rango de direcciones IP diferente al que yo creía que tenía configurado en la Centera.

Revisamos la configuración de la Centera, aparece algo llamado NAT Externo con las direcciones en cuestión. Llamamos a EMC nuevamente “¿Pero esto que eeeesss? (En voz Mauricio Colmenero)”. Nos dicen que es algo que se configura cuando hay replicación entre dos Centera. Preguntamos a los dinosaurios del departamento “¿En algún momento se replicaba esto con otro site?” “Ahhh siiii, en el año 2010 esto se replicaba con el site de Mordor”.

Muy bien, ahora sabíamos mas o menos por donde iban los tiros. Sin embargo, si esto ya estaba configurado así ¿Por qué dejó de funcionar de repente?.

Hablamos con comunicaciones.

  • “Oye, ¿te suena este rango?”
  • “Si, lo configuramos la semana pasada para la wifi de los bosses”
  • “Pero… ¿No sabías que ya se estaba usando para otra cosa?”
  • “No, aquí en el inventario no estaba”

Maravilloso, maravilloso. El sistema ha estado fallando desde hace años, lo que pasaba es que el rango que se estaba utilizando para el fulano NAT no era enrutable. Ahora que era enrutable el Enterprise Vault tardaba mas en fallar, solo que lo hacía de forma silenciosa.

Llamamos nuevamente al técnico de EMC “¿Si no tenemos replicacion hace falta que el NAT esté configurado?” “Pues no, no hace falta”. Desactivamos, guardamos y ¡voila! Ahora el Enterprise Vault va como un cohete y los elementos se restauran en un par de segundos (más rapido que antes de la incidencia).

En conclusión, todo mal:

  • Un sistema heredado sin documentación, que falla desde hace años, pero nadie dice nada porque va “razonablemente bien”
  • Una aplicación que no muestra errores cuando los hay
  • Se elimina una replicación entre sistemas y no se borran las configuraciones necesarias
  • Un rango de IP en produccion que no estaba inventariado
  • Una parte del departamento hace un cambio y el resto no se entera
  • Los técnicos de los fabricantes no hace un troubleshooting completo

Así que ya sabéis, hay que comunicarse bien entre los demas miembros del departamento de TI. No podemos ser islas porque esto no da mas que problemas.