A finales del 2007 se hizo preciso mejorar la plataforma del Core Bancario, hasta ese momento residía en un servidor Sun V440 con 6GBytes de memoria RAM, 4 discos internos de 36GBytes y un arreglo de discos externos de 5 discos cada uno de 72Gbytes que, en RAID-5, dejaban disponibles unos 250GBytes. Se decidió entonces pasar a un esquema de Cluster del tipo Activo –Pasivo (ya que el licenciamiento de Oracle hacía prohibitivo tener dos servidores en modalidad Activo – Activo) y se optó la solución de HP con Service Guard.
Para resolver el problema del almacenamiento, se decidió adquirir un EVA 4100 de HP con 8 discos de 300GBytes c/u que finalmente dejaban libres unos 2240Gbytes… ya el administrador podría decidir como dividir los volúmenes de este dispositivo y con que tipo de redundancia (RAID-0, 1 o 5).
Al EVA 4100 se conectaron los dos servidores HP rx3600 con HPUX (que integrarían el Cluster Activo – Pasivo) y un servidor DL380 G5 que haría funcionas de NAS para Windows (teóricamente ese servidor debería estar encargado únicamente de tener la interfaz al EVA, pero hubiese sido un gran desperdicio hacerlo de esa manera).
Para lograr el efecto del Cluster Activo – Pasivo con Service Guard (sobre el cual escribiré posteriormente), se hicieron varios volúmenes de datos:
1) El de Bases de Datos Oracle para el Core Bancario con 500GBytes en RAID-1
2) El del Oracle Application Server para el Core Bancario con 45GBytes en RAID-1
3) El de la Base de Datos de Fideicomisos con 100GBytes en RAID-1
4) El de la Base de Datos de Cheques Digitalizados con 100GBytes en RAID-1
5) El de los Home Folders y Carpetas compartidas para los usuarios Windows con 500GBytes en RAID-5
6) El de Respaldos especiales de 200Gbytes en RAID-0
7) El de uso interno del Cluster propiamente con 10Gbytes en RAID-1
Todo esto suma prácticamente la capacidad total del EVA.
Lo interesante del enfoque del software del EVA, es que el administrador realmente no sabe en que disco(s) reside un volumen dado, simplemente pide cierto espacio con cierta redundancia (RAID-1, RAID-5 o sin redundancia) y el EVA decide como repartirlo.
Por tres años todo funcionó a la perfección… hasta que llegó la falla!
Un mal día una alarma sonora avisó que había un desperfecto en la SAN, ingresé al utilitario que la maneja y pude ver que efectivamente todos los volúmenes menos los dos relacionados con el Core Bancario y el interno del Cluster, tenían un triángulo amarillo… dos de los discos duros físicos presentaban un error con un icono en rojo. En efectos los usuarios reportaron haber perdido sus carpetas de “Mis Documentos” así como las carpetas compartidas… pánico total!
Ejecuté los comandos necesarios para tratar de recuperar los volúmenes pero no tuve éxito. Finalmente me resigné a perder las particiones marcadas, así que recree la de Windows y bajé los datos del respaldo, ahora los volúmenes quedaron configurados de la siguiente manera:
1) El de Bases de Datos Oracle para el Core Bancario con 500GBytes en RAID-1 (no quedó afectado)
2) El del Oracle Application Server para el Core Bancario con 45GBytes en RAID-1 (no quedó afectado)
3) El de los Home Folders y Carpetas compartidas para los usuarios Windows con 400GBytes en RAID-5
4) El de uso interno del Cluster propiamente con 10Gbytes en RAID-1 (no quedó afectado)
Dado que se perdieron 2 discos, la capacidad de la SAN bajó a 1680GBytes. Por otro lado la suma teórica de la nueva configuración es de 1610Gbytes, así que estábamos bastante recuperados. Esto duró una semana… ya que falló un tercer disco!
Esta vez la falla fue menos severa ya que en ningún momento se perdió el acceso a algún volumen, lo curioso del asunto es que, a pesar que a la SAN no le quedaba prácticamente espacio disponible (creo que reportaba 8GBytes libres) y a pesar de que fallara un disco, lo cual disminuía la capacidad teórica a 1400GBytes (sensiblemente menos de lo reservado por los volúmenes), la SAN continuó funcionando sin pérdida de datos y ni siquiera reportó que removiese algún tipo de redundancia para tener más espacio. Eso si, se sumergió en un estado de “leveling” desde el primer día (un martes) y el tiempo de respuesta del Core bancario aumentó sensiblemente (el cierre del Core Bancario diario tardaba el cuádruple).
Dado que, evidentemente, la situación no era estable más el temor que fallara un cuarto disco, comenzamos una actividad febril de sacar a los Home Folders y las Carpetas compartidas de la SAN: la idea era la de eliminar el volumen para Windows devolviéndole todo el espacio a la SAN para que el Core bancario pudiese funcionar como lo hacía antes de la falla. Este procedimiento se culminó el jueves por la noche, los volúmenes quedaron así:
1) El de Bases de Datos Oracle para el Core Bancario con 500GBytes en RAID-1 (no quedó afectado)
2) El del Oracle Application Server para el Core Bancario con 45GBytes en RAID-1 (no quedó afectado)
3) El de uso interno del Cluster propiamente con 10Gbytes en RAID-1 (no quedó afectado)
El total teórico es de 1110Gbytes de los 1400 disponibles… a los pocos minutos de haber liberado el volumen de Windows, la SAN culminó su proceso de “leveling” e indicó que el espacio disponible ahora es de 30Gbytes (aun cuando dice que lo ocupado son 1100, debe ser que hay áreas adicionales dañadas). Los tiempos volvieron a los niveles normales anteriores a la falla… se acabó la crisis!
Anécdota: Al producirse la primera falla llamé al servicio técnico de HP para que me atendieran, en ese momento me informaron que el contrato de mantenimiento se había vencido dos días antes. Yo estoy seguro que HP no “planea” sus fallas para justo después de que venzan los contratos de mantenimiento… pero de que vuelan vuelan!
