Swift: La replicación de datos

Continuando con la serie de capítulos relacionados con el almacenamiento de información, en este se tratará uno de los temas más importantes: cómo se replica la información.

Debemos partir de una realidad que a muchos financieros de las empresas no les gusta o simplemente desconocen: los discos duros pueden fallar y en general cualquier equipo informático. Y generalmente se preguntan: ¿Porqué tienes que poner tantos discos?, ¿Porqué pones esta cabina de discos que cuesta 3 veces más que esta otra?, ¿Porqué quieres instalar en el otro edificio un sistema idéntico; con uno no basta?

Por suerte o desgracia, siempre dependiendo del punto de vista, los equipos informáticos pueden fallar, especialmente cuando hay centenares de personas que dependen de los sistemas informáticos para desarrollar su trabajo es completamente inasumible que estos fallen.

Analicemos un poco los costes para una empresa en caso de caída de los sistemas. Supongamos que la empresa tiene 200 trabajadores que dependen directamente de los sistemas. El salario de estos trabajadores es de 2000€ brutos. Por lo tanto, el coste para la empresa por hora de cada empleado es 12,5€. En total, cada hora de caída de los sistemas cuesta 2500€. Esto sin contar lo que podrían dejar de facturar. Si facturan a 30€/h, nos vamos a unas pérdidas de 6000€/h por la indisponibilidad.  Si existe pérdida de información por culpa de un fallo, el valor puede ser de decenas de miles de horas de trabajo o incluso mayor. Siempre dependiendo del tamaño de la empresa y el tipo de datos con los que trata.

Desde hace décadas los ingenieros han buscado todas las formas posibles para crear sistemas distribuidos dónde no haya ningún nodo crítico en una red o sistema de forma que se pueda asumir el fallo de cualquier nodo.

Con el lanzamiento del sistema de storage Swift, perteneciente a la solución Cloud Open Source OpenStack, los ingenieros y desarrolladores tuvieron que pensar en una forma de conseguir la máxima disponibilidad del sistema y los datos. A continuación analizamos su solución:

La replicación en OpenStack Swift

OpenStack Swift tiene un sistema de replicación de información muy simple pero eficaz para garantizar la máxima disponibilidad. Swift está pensado para escalar a centenares y miles de nodos, por lo tanto no nos debería sorprender su sistema de replicación. Otro dato importante es la consistencia de la información. Swift está pensado para ofrecer rendimiento y por lo tanto, la consistencia de la información es eventual. Esto significa que si justo acabamos de escribir información en un nodo y este falla, podemos perder la información o que si leemos de otro nodo donde se replica, este no contenga la última versión.

Primero se definen tres conceptos importantes: zona, región y anillo (ring). Un anillo es un conjunto de nodos que formarán un clúster. Podemos suponer que todo el storage de una empresa forma parte de un único anillo. O cada departamento, si la empresa es muy grande, tiene un anillo dedicado. La replicación de datos ocurre dentro del anillo. Nunca se puede replicar de un anillo a otro.

Dentro de cada anillo se definen las zonas y las regiones. Una zona es un conjunto de equipos que se considera que pueden fallar a la vez. Podrían fallar todos porque dependen únicamente de un switch o comparten alimentación. Normalmente se considera que una zona es un rack en una topología Top of the Rack (ToR). Éste es el motivo por el cual Swift nunca replica dentro de la misma zona pues, ¿qué sentido tiene guardarte una copia de la información en un equipo que puede fallar a la vez que el principal?

Luego, se define el concepto de región. Una región es un conjunto de zonas generalmente ubicadas en regiones geográficas distintas. Por ejemplo podemos imaginar un datacenter en Barcelona y otro en Dublín. Cada región es distinta y es muy improbable que fallen las dos a la vez. Cada región puede contener múltiples zonas dentro.

Por defecto, Swift intenta replicar siempre dentro de una misma zona porque los requisitos de ancho de banda suelen ser mucho mejores que entre regiones. Dentro de una misma zona, swift intenta replicar utilizando el algoritmo 'as far as posible' (Tan lejos como sea posible). Es por esto que si la zona tiene 3 equipos con 3 discos, si el factor de replicación es 3 se guardará una copia en cada equipo. Si solamente hubiera un equipo con 3 discos, se guardaría una copia en cada disco del equipo. Si existen 3 zonas, una copia en cada zona.

Cuando existen múltiples regiones el algoritmo cambia. Ya no se trata de sincronizar por defecto tan lejos como se pueda sino que eso aplica únicamente a una región. La configuración por defecto indica que cuando se sube un objeto a Swift, este creará 3 réplicas locales de forma síncrona y luego de forma asíncrona se moverá una réplica local hacia otra región.

Este método es el idóneo si por ejemplo la información de Barcelona se lee y escribe des de España y Francia  y la información de Dublín se lee y escribe des de Irlanda e Inglaterra.

Este funcionamiento puede no ser ideal en muchas empresas e interesa que una de las réplicas vaya directamente hacia la región remota. En este caso se puede configurar que una de las 3 réplicas vaya síncronamente a la región remota. El problema de esta solución es la latencia añadida.

Por último, y no menos importante, destacar que en Swift existen dos tipos de nodos: los proxy y los nodos de storage. El usuario final siempre se comunica con el proxy y este, con los nodos de storage. Los proxy pertenecen al anillo y, por lo tanto a todas las regiones. Se puede configurar cada proxy con unos parámetros que se llaman 'read affinity' y 'write affinity' que indican la prioridad con la cual deben leer y escribir datos en cada región. Es decir, si se quiere leer un dato, primero se buscará en la región prioritaria y si no existe, se buscará en otras regiones. A la hora de escribir, si hay espacio, se escribirá en la región prioritaria y si por algún motivo no se puede escribir se hará en regiones remotas.

Disponibilidad de Swift

Sobre la disponibilidad de Swift existen pocas métricas en el mercado, pero hay un despliegue de un sistema muy parecido a Swift (incluso basado en él) que es Simple Storage Service (S3) de Amazon. Las métricas que consigue Amazon de disponibilidad y permanencia de datos son muy muy buenas. La disponibilidad del clúster es del 99,999% anual o unos 5,26 minutos de caída del servicio anual. En cuanto a la permanencia de información la cifra sube a 99.999999999% indicando la probabilidad de no perder un objeto. Si suponemos el tamaño de objeto de los objetos igual a un byte y tenemos un TeraByte (10^12) de información, podríamos perder 10 bytes u objetos al año.

Dependiendo del tipo de información a guardar, es un valor asumible o no, pero la dependencia actual de la sociedad en las infraestructuras TIC hace de la alta disponibilidad una características clave. Si el cliente es facebook y pierde una foto de un cliente, ‘no pasa nada’. Si se trata de un banco y pierde los datos o el saldo de un cliente, el banco tendrá un serio problema.