Hoy, luego de haber pasado la tormenta del fuera de línea de ogrid y, poco mas de una semana después, voy a aburrirlos con algunos detalles técnicos sobre el trabajo realizado por los Administradores de Osgrid, tanto en lo que hace a la recuperación de la información como a la reestructuración del diseño de los servidores de assets del grid.
Ya bien sabemos que, como explicara originalmente en este mismo blog, la caída de osgrid fue consecuencia del fallo de hardware de RAID del servidor de Assets. Se habló mucho al respecto, para bien y para no tan bien, pero lo importante es que, a pesar de haber transcurrido mucho tiempo (6 meses) el grid volvió a estar en línea y, hasta donde pude ver, con todo su contenido intacto.
Ahora bien, sabemos cual fue la causa del problema, pero no sabemos como se va a evitar que vuelva a ocurrir, hasta ahora.
Como explicara anteriormente en los artículos citados, el servidor de assets de osgrida, al momento de la caída, estaba compuesto por un servidor físico con 4 Discos en RAID 10, esto es, un mix de RAID 0 y RAID 1, ¿qué significa esto?, bien, resumido y simple: RAID 0 implica usar un par de Discos para distribuir la información y simular un Disco de tamaño mayor, producto de la suma del tamaño de ambos discos, es decir, dos discos de 1TB cada uno, conformarían una unidad lógica de 2TB. Además de esto, al repartir la información entre ambas unidades físicas, esto permite mejorar el rendimiento final de la unidad lógica. Por otro lado, RAID 1 implica usar también un par de Discos pero, en este caso, para espejar el contenido de los mismos, es decir para duplicar la información almacenada. Esto es, todo lo que se graba en uno de los discos, se graba también en el otro, entonces, en caso de falla de una de las unidades, el sistema recurre al otro disco de array.
Como podrán imaginar, cada sistema tiene sus pro y sus contras (voy a obviar aquí que existen varias implementaciones RAID, pueden consultar aquí si están interesados, y me voy a concentrar solamente en lo que utilizaba osgrid para este análisis). En el caso del RAID 0, la gran contra es que, en caso de perderse uno de los discos del array, nos quedamos con el otro con la mitad de información y, tristemente, con información que termina siendo inconsistente, ya que el sistema graba aleatoreamente los datos de un mismos archivo en distintos lugares de ambos discos, con lo cual, al perder un disco, perdemos la parte correspondiente de los archivos que necesitamos. Por el lado del RAID 1, la contra es que al tener el sistema que grabar toda la información por duplicado, se pierde velocidad de rendimiento y se nota mucho más cuando se trabaja con grandes volúmenes de información (como es el caso de osgrid, con una base de datos de assets de unos 3,5TB).
Por ende, una de las soluciones más comunes es utilizar un mix de ambas soluciones, denominada RAID 10, la cual consiste en utilizar 4 discos en dos pares, el primer par es para armar un RAID 1 y, el RAID 0 se arma con el segundo par. Veamos esto gráficamente:
RAID 0 | RAID 1 | RAID 10 |
En el gráfico mostrado, A1, A2, etc. son partes del mismo archivo, como se puede ver, en el RAID 0, el archivo se va grabando partes en un disco, partes en el otro. En el caso del RAID 1, se graba el archivo completo en un disco y se graba una copia exacta en el otro disco. Y, finalmente, en el RAID 10, se hace un RAID 1 con el primer par, espejando ambos discos, se repite lo mismo en el segundo par, dos discos espejados y, ambos pares se unen para formar un RAID 0.
Vale aclarar que esta solución no implica que debemos olvidarnos de hacer backup de la misma información, como bien lo ha demostrado la experiencia de osgrid. El objetivo de armar RAIDs es simplemente para enfrentar situaciones de, digamos, tiempo real, donde es necesario mantener en línea y operativo un servicio. Por ejemplo, como dije anteriormente, el RAID 0 nos permite obtener un mejor rendimiento en las operaciones de grabación y lectura y el RAD 1, nos permite seguir operativos en el caso que uno de los discos falle. Es decir, si uno de los discos falla, el sistema continúa trabajando con el otro disco y nos da tiempo a cambiar el disco dañado por uno nuevo y, en caliente, reconstruir el RAID, haciendo que todo esto sea transparente al usuarios final que, a lo sumo, solo notará una merma en el rendimiento del sistema mientras duren las tareas de reconstrucción del RAID.
Ahora bien, todo esto, parece lindo pero no lo es tanto, hay muchas consideraciones a tener en cuenta y la experiencia ha mostrado que la solidez de un RAID 1, 0 o 10 no es tan buena como podría esperarse, por ejemplo, ante un fallo de la controladora del RAID, si no la tenemos espejada, para poner nuevamente el RAID en línea, tendremos que recurrir a una nueva controladora idéntica a la dañada, tanto en marca, como en modelo (esto fue uno de los problemas que tuvo osgrid). Como experiencia personal puedo decir que he tenido la mala experiencia de ver como un RAID 1, en este caso, terminó dejándome con 2 discos con información inservible ya que, el sistema, por la falla de uno de los discos, comenzó a duplicar el grabado de basura en ambos discos, el dañado y el sano.
Entonces, sabiendo todo esto, ¿cómo encaró la gente de osgrid la reestructuración del servidor de assets para evitar que algo así pudiera volver a pasar?
Bien, primero hubo que evaluar como encarar el almacenamiento de la información del Asset, en este caso, todos los assets están almacenados en una única base de datos de Mysql, la cual, ya supera tranquilamente los 3,5TB (físicamente, mysql almacena cada tabla en un archivo separado y/o en un gran archivo -o varios- si configuramos tablas innodb).
Llegados a este punto, la solución (y gran ayuda) vino de la mano de Melanie Thielker, miembro del equipo de desarrollo de opensim y propietaria del grid Avination.
Debido a que en su propio grid, Melanie se enfrentó con situaciones similares a las que tuvo que enfrentar osgrid en esta situación, previo seguir por el mismo camino que seguía osgrid, llegó un punto en el cual, el tamaño de los assets del grid se tornaba de dificil manejo y propenso a pérdidas graves en caso de fallos, Melanie tomó el otro por las astas y se sentó a diseñar su propio código para el servidor de Assets.
Pues bien, no hay mucho secreto en esto, pero básicamente la idea es utilizar y adaptar sistemas de redundancia y alta disponibilidad al código de opensim para crear un servidor de assets robusto y confiable. Entonces, podemos decir que hoy, la base de datos de assets está compuesta por pequeños archivos, uno por cada asset (a diferencia de una gran y gigante base de datos mysql) y, al menos, dos servidores físicos duplicados, cada cual con sus propios RAIDs. Cómo bien lo explica Melanie, la idea es que cuando un servidor se va llenando de información, se divide en dos servidores distintos y cuando éstos, a su vez, se llenan, se divien en 4 y así sucesivamente.
Entonces, sintetizando, hoy, osgrid cuenta un servidor de assets en lo que se ha denominado FSAssets, con dos servidores replicados, cada uno de ellos con 4 discos en RAID 10 y el nuevo sistema de almacenado de la información de un archivo por asset (ítem de inventario, avatar, etc.). Este sistema es similar al que usan muchos sitios corporativos, bancos, redes sociales, etc. que buscan estar en línea 24/7 y no quedar off line ante cualquier fallo. Entonces, tenemos una estructura en la cual, desde el exterior, se «visualiza» un solo servidor y una sola IP para dicho servidor, pero luego, detrás de esta puerta de entrada, nos encontramos con dos servidores físicos espejados los cuales, responden a todas las peticiones provenientes del exterior, utilizando la tecnología denominada Alta Disponiblidad (o balanceo de carga), la cual permite decidir que servidor va a responder la petición en función de la carga recibida y, en caso de fallo en uno de los servidores (o del servidor completo) el o los servidores restantes, continuan atendiendo las peticiones recibidas permitiendo al personal técnico reponer el servidor dañado sin que se note el problema desde el exterior.
Por último, según lo dicho por Melanie, utilizar esta metodología en opensim implica un cambio de 10 líneas de código, por lo tanto no es problemático hacerlo y, por ende, se prevee que dicha modificación estará disponible en el código fuente de opensim en una próxima versión.
SaludOS/2