El pasado domingo 30 de agosto Second Life sufrió problemas generalizados de conectividad, lo cual hizo que muchos usuarios alrededor del globo (o el plano, para los terrraplanistas) no pudieran iniciar sesión en la plataforma.
Este incidente tuvo una duración de, alrededor, unas 4 horas e hizo que mas de uno se tirara de los pelos y pensara en las profesías mayas acerca del fin del mundo (al menos el virtual).
Ayer, en el foro oficial de Second Life, April Linden, como ya es habitual, informó a los usuarios sobre el tema y, a continuación, transcribo la traducción de comunicado:
¡Hola, residentes!
Mucha gente tuvo problemas para conectarse a Second Life ayer (30 de agosto de 2020), y quiero explicar un poco lo que sucedió y por qué no publicamos en la página Estado de Second Life de inmediato.
A primera hora de la mañana de ayer (hora de EE. UU.), uno de los principales proveedores de Internet tuvo un problema que afectó a gran parte de Internet en su conjunto, incluida Second Life. Varias otras empresas de Internet han escrito sus propias entradas de blog realmente buenas sobre lo sucedido. Nos vimos atrapados en lo mismo.
La razón por la que tardamos en publicar en la página Estado de Second Life es, porque, desde el punto de vista de nuestros sistemas de supervisión, Second Life y todos nuestros sistemas funcionaban con normalidad. Eso significa que no se alertó a nuestro equipo de operaciones. Por supuesto, desde el punto de vista de los residentes, Second Life estaba efectivamente caído en algunas partes del mundo, y eso es realmente lo que importa.
Para ayudarnos a reaccionar más rápido en el futuro, hemos realizado algunos cambios.
Ayer por la noche, agregamos un nuevo servicio de monitoreo que verifica algunos de los sistemas centrales de Second Life en todo el mundo. Es un servicio que también utilizan muchas otras empresas, por lo que recibiremos mejores alertas en el futuro. Cuando ocurren eventos a escala de Internet como ayer, no hay mucho que podamos hacer al respecto, pero podemos publicar en la página de estado más rápidamente para que nuestros residentes sepan que somos conscientes de que las cosas no están bien.
Lamentamos la falta de comunicación de ayer. Sabemos lo importante que es Second Life para nuestros residentes y estamos tomando medidas para aumentar nuestra visibilidad de los problemas fuera de nuestros servidores. Esperamos que estos pasos nos permitan comunicarnos mejor con todos ustedes en el futuro.
¡Nos vemos en el mundo!
April Linden
Gerente de operaciones de Second Life
Ahora bien, para el neófito en la materia, intentaré describir de manera resumida y sencilla (que lo logre es otro cantar) cual ha sido el problema aquí, y porqué, en este caso, Linden Lab fue totalmente ajeno al problema y la solución del mismo no estaba en sus manos.
Según lo explica Matthew Prince en el blog de cloudflare, lo que podemos llamar «un pequeño» error de configuración en algún equipo (que tampoco se conoce de que proveedor) terminó escalando en la caída del servicio de internet afectando a gran parte del mundo . Esto es, desde el punto de la seguridad de las conexiones, los sistemas de trasmisión (routers, servidores, etc.) tienen automatizada la vigilancia y control de tráfico para evitar ataques DOS/DDOS, etc. que afecten los servicios. Este servicio de seguridad, automatizado, se replica a través de la red a distintos equipos con el objeto de, digamos, armar una lista negra de atacantes y que, cada sistema de la red, lo conozca y pueda bloquearlo.
Ahora bien, esto se hace a nivel carriers (principales distribuidores del servicio de internet) pero, también puede ser utilizado por otros ISPs (proveedores de internet). En algún punto, alguien (que debe estar escondido en su casa con cara de «yo no fui») modificó o creo alguna regla, la cual tenía errores, esta regla errónea, comenzó a replicarse a través de la red provocando el bloqueo de los propios sistemas de los proveedores (en la jerga de SL, fue baneando a sus propios propietarios).
Paralelamente, como la carga de de actualización era grande, el sistema, al trasmitir esta actualización y llegar a la regla inválida, cancelaba la actualización y la volvía a comenzar, provocando un exceso de flujo de datos entre los distintos hosts de la red. Resultado: Se vino abajo la conectividad.
Ahora bien, el otro punto importante aquí es que, por norma, todo proveedor de servicios de internet, por seguridad, debe tener, al menos dos proveedores de internet (Linden Lab, los tiene) para, en caso de suceder la caída de uno, cambiar al otro para asegurar la continuidad del servicio.
Lo que ha sucedido aquí es que muchos proveedores no tienen este «backup» de conectividad, con lo cual, al caerse la conectividad en CenturyLink/Level(3) (Principal distribuidor y conector de internet en el mundo), muchos no tenían un segundo proveedor al que recurrir. En otros casos, si bien tenían dos proveedores de internet, éstos, cuentan con Level3 como único proveedor (el caso de Linden Lab), con lo cual, aunque se tuviera un ISP de backup, el problema persiste.
Por último, encontrar el problema a ese nivel, resolverlo y distribuir la solución por toda la red (hablamos de red a nivel mundial) toma su tiempo y es por esto que la resolución del problema que se vivió el domingo pasado ha tomado tanto tiempo en resolverse.
En definitiva, para los bichos de sistemas y redes, una lección mas de como, un hecho insignificante puede escalar a proporciones globales y afectar a millones y, por otro lado, es la prueba real del famoso backup «por la dudas», del que muchos prescinden por costos y por «no creo que vaya a pasar», pero, en algún momento pasa.
SaludOS/2