En ocasiones en el trabajo te encuentras con bombas de relojería de explosión retardada. Eso es lo que nos ha pasado con el sistema de almacenamiento del backup que hemos heredado por la integración de sistemas de un proyecto a otro que llevamos nosotros.
La solución de almacenamiento que tienen se basa en una NAS que tiene un servidor que corre sobre FreeBSD 9.0, al que se le han enganchado a una controladoras HP StorageWorks de 70 discos. Estos discos se han ofrecido un mega volumen (110 TB) que a su vez tiene ZFS para gestionarlo.
Como solución de bajo coste para una NAS no esta nada mal pero el problema nos ha venido dado porque no se ha entregado documentación ni información sobre la gestión del ZFS para problemas tan 'nímios' como la sustitución de un disco averiado, además el ZFS ya venía en modo degradado con dos discos estropeados, que luego han pasado a ser cuatro al lanzar un chequeo de integridad (scrub) del almacenamiento ZFS.
Así que hemos tenido que hacer ingeniería de documentación de internet para entender las particularidades del FreeBSD (administrar un FreeBSD no se hace todos los días) y la gestión propiamente del ZFS y sus procedimientos de trabajo. Aún estamos en la parte de identificación de un disco averiado, pero al menos si que hemos podido hacer la sustitución por un disco de Spare, que nos ha permitido poner el estado del ZFS en modo Online y sin errores. Camcontrol nos va a servir para lo identificación, pero aún no hemos llegado a esa parte.
Pero he dicho que habíamos encontrado una bomba cuando en realidad eran dos. La segunda viene en forma de una NAS adicional (con una capacidad de 55 TB, la mitad que la otra, siendo su función respaldar a la primera por si hay algún desastre ¿?) utilizada para el respaldo de las copias de la primera NAS pero que en lugar de tener un sistema idéntico, corre bajo un sistema operativo diferente. En concreto funciona bajo un Nexenta Core 3 (una especie de Debian con núcleo OpenSolaris) y que tiene un tipo de cabina de discos DELL PowerVault.
Otra diferencia sobre la primera NAS es que en la cabina del segundo sistema se ha creado un mega volumen de datos que se le ofrece al servidor como un único disco (en la anterior, el ZFS gestiona todos los discos), con lo que el ZFS tiene enganchado ese único disco, no teniendo que hacer operativas de sustitución de discos a nivel de ZFS. Los problemas de reemplazo/detección de discos fallidos se gestionan desde la cabina de disco. Para ellos disponemos del software MegaRaid de LSI que nos ofrece los servicios necesarios para detectar e identificar los discos problemáticos.
Con lo que otra vez tenemos que empezar con el proceso de documentarse y probar. Menos mal que al estar basada en Debian, la cosa se hace más familiar y el disponer del conjunto de herramientas megaraid nos ha solucionado la vida en un 110%. La pega es que como en esta cabina nada fallaba, pues no podemos probar los métodos de sustitución. Siempre podemos provocar un fallo, pero es tentar la suerte. Con el inconveniente adicional de que nada de lo que hagamos en una, podemos aplicarlo en la otra y viceversa.
En todo caso, ahora estamos mejor que hace un par de semanas, cuando se nos trasmitió que la localización de un disco averiado se realizaba mediante técnica rebeca al uso, es decir, extrayendo disco a disco y comprobando simultáneamente los mensajes de error en los logs. Un
colega diría que quien haya hecho eso se habría ganado el premio Rebeco del año.
Por último, entrar en valoraciones sobre las soluciones elegidas para el almacenamiento del respaldo de los volúmenes de cintas (que en lugar de escribirse físicamente, se vuelcan en cintas virtuales dentro la NAS principal) no nos lleva a ninguna parte. Los primero es familiarizarse con los sistemas, luego ya habrá tiempo de valorar si es bueno o malo.
De todas formas me voy a mojar. La solución me gusta teniendo en cuenta la relación coste/características, pero me parece que no se valoraron los riesgos que implicaban poner en funcionamiento unos sistemas que son poco conocidos y que hasta para los anteriores administradores que lidiaron con ellos les resultaban bastante oscuros en su gestión.
Creo que este riesgo no se tiene que solventar una vez puesto en producción los sistemas, se deben solventar antes porque pudiera pasar que se encontrase un problema para que el que no existiera solución y al ya haberse hecho la inversión en tiempo y dinero, se tuviera que tirar a la basura por culpa del problema que no se tuvo en cuenta a su debido momento.
Además, el haber inventado de nuevo la rueda para la segunda NAS, existiendo una primera que medianamente controlabas, no hace más que incrementar el riesgo. Puedo entender los motivos por el que se hizo esto, que no era más que buscar protección ante la aparición de un bug que se diera en una de las NAS e invalidara también la otra, pero no los comparto.
Con un ejemplo exagerado, es como si a google se le ocurriera hacer un nuevo servidor o un servicio de cluster, diferente por completo a los demás que tiene para cada uno de sus nodos/cpds, a fin de protegerse de los bugs similares que pudieran aparecer. Uno de los éxitos de google se basa en la replicación de sus soluciones.
