viernes, 29 de abril de 2011

Tormenta en la nube


    Durante gran parte de la semana pasada, un fallo en los servidores del sistema EC2 (acrónimo de Elastic Computing Cloud) de Amazon ha hecho que una parte significativa de La Nube haya estado inoperativa. Esta caída de los servidores ha afectado a servicios como Quora, Foursquare, HotSuite, ReddIt, Sony Network o CoTweet por citar sólo los más conocidos aunque los perjudicados han sido varios millares de sitios y cientos de miles de usuarios. El fallo ocurrió por una causa banal el jueves 21 en la madrugada (hora local) pero se fue extendiendo en cascada hasta generar un problema importante que ayer domingo, 24 de abril, aún no estaba plenamente solucionado. En concreto, el fallo se inició en el centro de servidores de Virginia cuando varios sistemas comenzaron a realizar copias de seguridad automáticas de los datos. Hasta ahí, nada anormal. Pero, por motivos desconocidos, los algoritmos no detectaron la finalización correcta de los back-ups y las copias continuaron haciéndose y haciéndose, una sobre otra, saturando rápidamente los servidores. El sistema intentó almacenar los datos en otros servidores dando lugar a una explosión de problemas de saturación y conectividad que acabaron por hacer caer el sistema. Un asunto que los ingenieros no han podido resolver rápidamente y que ha tenido a la Nube caída por muchas horas. Aunque el mismo jueves a la noche (ya el viernes en España), se había restablecido el funcionamiento básico, muchos de los problemas de conexión continúan permaneciendo.

    La informática en Red, en La Nube, está de moda. Permite, para el usuario final, almacenar datos y aplicaciones en un ente aparentemente virtual que no es su ordenador, llamándolos sólo cuando le son necesarios. Así, no tiene problemas de espacio ni de gestión de los datos. “Algo” almacena todo, “algo” hace copias de seguridad para asegurar que los datos no se pierden, “algo” se preocupa de que todo funcione correctamente. Esta sensación de (falsa) seguridad y de comodidad ha hecho que la Cloud Computing sea un concepto que haya pasado de ser una locura hace apenas cinco años a ser un elemento indispensable de la Red y la Web 2.0. Hoy, en día, a casi nadie se le ocurriría mantener sus propios servidores, gastar en electricidad, asegurar que funcionen las 24 horas del día, 7 días a la semana, invertir en discos duros de mucha capacidad. Es mucho más sencillo y conveniente delegar todo ello en “algo” que lo hace por nosotros por un pequeño precio: La nube. A nivel más particular, son millones los usuarios que, en vez de comprar un disco duro y dedicar horas a hacer copias de seguridad, confían sus datos a servidores de correo (Hotmail, Yahoo, Gmail,…) o a discos duros virtuales en la nube (Dropbox, etc). Todo esto es posible, obviamente, si el servicio está disponible. Si no lo está, ni hay web, ni hay sitios, ni podemos almacenar datos ni podemos llamarlos, nuestras aplicaciones están inoperativas, etc.

    El problema es que ese “algo” no es magia ni virtualidad pura. Por el contrario, son ordenadores y software que pertenecen a unas pocas empresas con la capacidad y el poder empresarial suficientes para invertir en todos esos medios y recursos y ponerlos a nuestra disposición. De hecho, EC2 es uno de los mayores servicios de alojamiento en la nube. La Nube es cómoda y permite el acceso a la Red a casi cualquiera, pero presenta una serie de problemas de gran calado:

    1.- Fiabilidad: La seguridad de funcionamiento está concentrada en los servidores de unas pocas empresas de alojamiento. Si estos fallan, falla todo. En cierta medida, la Nube es un concepto antagónico con el de Internet. La creación de la red fue un invento militar precisamente para evitar que la caída de un centro de datos dejara sin información al mando del ejército. Así, se creó la red de redes, donde una malla de conexiones múltiples aseguraban que si fallaba una, habría otra disponible. La redundancia masiva permitía asegurar que siempre podría encontrarse un camino entre dos puntos para transmitir los datos. 
    La realidad es, sin embargo, distinta. Si bien, a pequeña y local escala el principio de redundancia de caminos sigue existiendo, esto ya no es cierto a escala planetaria por la simple razón de que hacerlo así requeriría unas inversiones inalcanzables hasta para los gobiernos. El cableado de Internet mundial se concentra en unos pocos cables transatlánticos, unos pocos satélites orbitales y unos muy pocos nodos de concentración del flujo de información. Además, muchos de los millones de ordenadores que componen las subredes usan La Nube confiando los datos a ese grupo de servidores de alquiler pertenecientes a unas pocas empresas.
    ¿Qué tenemos entonces? Que la red se basa en unos pocos conductos de comunicación controlados por unas pocas empresas de telefonía poderosas y en unos pocos centros de datos (grandes, pero pocos) que dependen de unas poderosas empresas de gestión de datos. Si estos pocos elementos (bien sean cables o bien sean servidores) fallan, todo el tinglado se cae. Algo así ocurrió no hace mucho cuando un barco cortó accidentalmente un cable submarino en el océano dejando a media Asia sin Internet o ha ocurrido ahora con la caída del servicio de Amazon.
    Hay que ser consciente que la Ley de Murphy se aplica también a la Nube. Si algo puede ir mal, irá mal.

    2.- Complicación de restauración. Los servidores en nube facilitan la vida y el acceso a red pero son complicados de manejar y mantener. Si fallan, como ha sido el caso, su restauración es lenta y trabajosa. El usuario quiere rapidez de descarga y de subida de datos y eso se logra manteniendo en memoria viva la mayor parte de datos. Cuando el sistema cae hay que restaurarlo todo desde lentos discos duros de respaldo. Y son muchos petabytes a restaurar lo que obliga a hacer la restauración lentamente para no sobrecargar las transmisiones.
 
    3- Imposibilidad de prever fallos en cadena. Hay una única manera, hoy por hoy, de evitar fallos catastróficos de la nube. Y esta es – nuevamente- la redundancia. La redundancia puede conseguirse de varias maneras (desde la física como pueden ser las duplicaciones de ordenadores, de discos, de cables, etc. hasta la redundancia virtual que se basa en duplicar los ficheros en sistemas distintos y aislados). Así, por ejemplo, Amazon dispone de centros de datos en varios lugares del mundo, separados de manera que la caída de un grupo de servidores no afecte a otro. Normalmente nuestros datos están en una determinada zona (denominada AZ) con el back-up de esos datos en esa misma AZ. ¿Pero qué ocurre si falla esa zona como ha sido el caso? No tendremos acceso ni a los datos ni a su copia de seguridad porque toda la zona está caída. En este escenario podemos pensar en duplicar nuestros datos en varios grupos de servicio geográficos. Si uno falla, podemos recurrir al otro. Pero, si como también ha sido el caso, los problemas de conectividad se extienden tampoco puede asegurarse el servicio. Si algo puede ir mal, irá. Un fallo en cadena de una red tras otra es improbable, pero no imposible.

    Otra posibilidad es que sea la propia aplicación- y no el servicio- el que se haga cargo de crear dinámicamente la redundancia necesaria de modo que, pase lo que pase con la nube, podrá seguir funcionando. Esto sea lograría buscando servidores aislados que no puedan interferirse y almacenando duplicados de los datos en ellos, con algoritmos que no dependan de un único canal de almacenamiento (por así decirlo, no valdría que mi programa sólo supiera descargar datos de Dropbox por poner un ejemplo, que siempre fuera a buscarlos allá), con programas que sean capaces de reconfigurarse automáticamente en función de los acontecimientos, con bases de datos relacionles y autosoportadas. Claro, esto no está al alcance de un usuario medio. Buscando la simplicidad de la nube nos estamos complicando la vida y si tuviésemos que hacer todo eso, ¿Para qué necesitamos la nube?.

    Y, siempre hay que tenerlo en cuenta, lo que nadie puede evitar es que las empresas proveedores de servicio (Nube o telefonía) quiebren y desaparezcan llevándose la nube con su bancarrota.

    4.- Confidencialidad de los datos. Dado que todo el flujo de información se almacena en manos de muy pocas empresas y circula por conexiones controladas por otras pocas, es obvio que es sencillo controlar nuestros datos. Basta situar unos pocos controladores de datos (sniffers) en ciertos nodos o en ciertos cables para poder conocer todo de nosotros. Este “Big Brother” es, sin duda alguna, uno de los problemas filosóficos más importantes de la Nube y ya ha sido tratado anteriormente aquí, aquí y aquí .
 
Entrada publicada por Félix Remírez en Biblumliteraria

Share/Save/Bookmark

No hay comentarios:

Publicar un comentario

Related Posts Plugin for WordPress, Blogger...