La replicación de datos en XtremIO X2, mecanismos evolucionados de copia remota (es)

Questo post è anche disponibile in Italiano

Uno de los motivos principales por los cuales nos orientamos a la compra de un array de tipo AFA es el rendimiento. Sin embargo, el business tiene también otras exigencias, entre ellas de particular importancia es la protección del dato.

Como protección del dato me refiero a la posibilidad de realizar copias remotas del sitio de producción en un segundo array. Una vez que implementamos un mecanismo de copia remota, el rendimiento de un array AFA disminuye.

Con una replicación síncrona, agregamos el tiempo de latencia de la distancia. En el caso de una replicación asíncrona debemos considerar cuidadosamente el «bandwidth» del link para permitir al array de producción de no «estar demasiado atrás» con las escrituras, caso contrario, el array de producción deberá realizar un trabajo adicional para mantener el RPO.

En este post examinaremos como XtremIO X2, gracias a una implementación única y particular del mecanismo de copia asíncrona, es en grado de mantener un bajísimo RPO disminuyendo al mismo tiempo el bandwidth necesario para realizar las copias.

Un RPO=0 es realmente siempre posible?

Un RPO=0 significa ninguna pérdida de datos. Consideremos una aplicación como un DB. Las escrituras al interno de una transacción son copiadas primero en el file de log y solo sucesivamente en el file de datos.

Nuestra deseada no pérdida de datos (RPO=0) puede ser obtenida solo si al momento del fallo del sistema las dos estructuras (log y file de datos) han sido escritas. Si en el medio de una transacción se produce un fallo del sistema, todos los datos escritos que todavía no han alcanzado el «commit» se pierden

xtremio-x2-native-replication-datacenter-issues
xtremio-x2-native-replication-datacenter-issues

De la misma manera, todos los datos que han alcanzado el commit pero no el file de datos también se pierden. Agreguemos ahora a la ecuación que una aplicación normalmente escribe numerosos datos antes de realizar el commit y que al momento del fallo muchas escrituras pueden encontrarse todavía en la cache del servidor o del sistema de almacenamiento. Es claro que un RPO=0 o cero pérdida de datos no es una meta fácil de obtener. Cuando se hace referencia a un RPO=0 es más correcto una expresión como tratar de lograr una replicación con consistencia aplicativa dentro del menor tiempo posible.

Una replicación síncrona, como hemos visto al principio del post, agrega un tiempo de latencia a la aplicación lo que hace desaprovechar en parte las ventajas de rendimiento que se obtienen con un array AFA.

Quizás el punto más importante sobre el cual debemos reflexionar es porqué queremos realizar una replicación síncrona. La respuesta probablemente es perder la menor cantidad de datos posible si se produce un fallo del sistema de producción y además, protegernos de una posible no disponibilidad de los datos.

Ahora bien, cuál es el evento más común que produce un tiempo de baja? La pérdida de un entero array, la pérdida del entero datacenter o una corrupción de los datos? Mientras los dos primeros eventos, de tipo físico, son menos frecuentes, la corrupción de los datos debido a un error humano o evento lógico (cancelación accidental de un dato, actualización del software aplicativo, etc.), es mucho más frecuente. En este último caso, una réplica síncrona “corromperá” el dato en el sitio remoto en un tiempo igual al tiempo de latencia entre los dos sitios.

No estoy afirmando que no deberíamos realizar copias síncronas de los datos, muchas veces según lo requisitos del business esto es necesario. La idea es reflexionar sobre la validez de una metodología de protección remota de los datos, asíncrona en este caso, que permita de obtener un bajísimo RPO, en grado de proteger el entorno de eventuales corrupciones lógicas, que no limite mínimamente el rendimiento aplicativo y que, al mismo tiempo, sea capaz de disminuir el bandwidth necesario para efectuar la copia remota.

XtremIO X2, un mecanismo de copia asíncrono eficiente

En un mecanismo de copia tradicional entre dos array, producción y DR, las escrituras de datos que se efectuan sobre el array de producción son enviadas al array de DR aun si estos datos existen ya en el sitio de DR.

xtremio-x2-native-replication-others-replication
xtremio-x2-native-replication-others-replication

En el caso de XtremIO X2, el mecanismo de copia es de tipo “metadata aware” y con “global data reduction”. En otras palabras, en X2 cuando se escribe un dato sobre el array de producción y el dato existe ya el sito de DR, este dato no será copiado remotamente. Este mecanismo es sumamente eficiente ya que implica el pasaje a través de la WAN de solo datos únicos (solo los que no pueden ser deduplicados), datos que, de todos modos, son transmitidos a través del link ya comprimidos lo que se traduce en una disminución de la banda necesaria.

Veamos brevemente cómo funciona la replicación nativa de X2

La replicación nativa de X2 utiliza un mecanismo de “snapshot shipping”. El array crea snapshot a la frecuencia determinada del RPO deseado.  (Técnicamente la frecuencia de snapshot es igual al RPO/2).

xtremio-x2-native-replication-characteristics
xtremio-x2-native-replication-characteristics

X2 no trasmite el entero contenido del snapshot, solo los bloques de datos que han cambiado entre un snapshot y el siguiente (snapshot delta) son enviados a través de link. Podemos imaginar la solución de replicación remota de X2 como un mecanismo en dos fases.

 

Fase 1: el array de producción (source) transfiere al array de destinación (target) solo los metadatos (XtremIO fingerprints) de los bloques que han cambiado entre los dos snapshots (snapshot delta). Esta prima fase sirve para hacer un “check” si en el array de DR (target) esos metadatos ya existen. En XtremIO los metadatos están siempre contenidos en la RAM, motivo por el cual el check es inmediato.

Fase 2: Si los metadatos ya existen en el array de destino significa que no hay necesidad de mandar los correspondientes bloques de datos, es suficiente actualizar el contador y los puntadores de los metadatos. De este modo se obtiene la “global deduplication”. Si los metadatos no existen, el array (source) envía los bloques de datos faltantes junto  con los metadatos al target. Los bloques de datos, como siempre en XtremIO, son enviados ya deduplicados y comprimidos..

Consideraciones sobre la eficiencia del bandwidth en X2

Hagamos ahora algunas consideraciones en lo que se refiere a la eficiencia sobre el link. En la fase inicial de sincronización entre el array de producción y el array de DR, o sea con el envío del primer snapshot, la cantidad de datos transmitidos a través del link será muy parecida a la DRR (data reduction) observada en el array de producción.

Por ejemplo, si en el array de producción observamos una compresión de 2:1 y una deduplicación de 2:1, o sea una eficiencia del 4:1, esto significa que sobre el link enviaremos solo el 25% de los datos. Dicho de otro modo, con una deduplicación del 2:1 mitad de los datos no serán enviados, aplicando ahora una compresión del 2:1 a los datos restantes, el resultado final será una ulterior reducción del 50% con un total de eficiencia del 75% sobre el link.

De ahí en más, para los nuevos datos que se escribirán sobre el array de producción, la cantidad de información transmitida a través de la WAN dependerá de la DRR para estos nuevos datos. Podríamos pensar que si el tipo carga de trabajo (workload) es del mismo tipo del ya presente en el array, continuaremos a obtener un 75% de eficiencia. En realidad el valor de eficiencia para los nuevos datos puede ser todavía mayor. Veamos el porqué con un ejemplo numérico real.

Supongamos que un servidor escribe en un determinado lapso de tiempo 1000 páginas de 16KB (16MB). Digamos que el 20% de estos datos son escrituras repetidas, o sea escrituras que se realizan sobre la misma dirección lógica dentro del ciclo de copia (RPO).

En este caso XtremIO envía únicamente la última escritura, la más reciente, el resultado es que, de las 1000 páginas tendremos que copiar remotamente 800. Asumiendo que de estas 800 páginas, 400 ya existan en el array de DR (debido a una modesta deduplicación del 2:1), resultan ahora 400 páginas por transmitir. Estas restantes 400 páginas se enviarán comprimidas, digamos con una media de compresión del 2:1. De este modo, 400 * 8 KB = 3,2MB.  En el ejemplo precedente, que no es extremo, 16MB de escrituras sobre el sitio de producción se traducen en 3,2MB sobre el link, lo que equivale a una reducción del 80%.del ancho de banda necesario.

Resumiendo: X2 utiliza al mismo tiempo 3 diferentes técnicas para obtener una gran eficiencia al replicar datos remotamente:

1) solamente la última versión del bloque de datos es enviado a través del link

2) gracias a la deduplicación global se envían sólo datos únicos

3) X2 transmite los datos ya comprimidos y al mismo tiempo el X2 de destinación lee y memoriza los datos comprimidos sin consumir recursos de CPU adicionales.

X2, protección contra errores “lógicos”

Vale la pena notar que el mecanismo de copia remota de X2 es en grado de proteger el entorno de eventuales errores lógicos (cancelación accidental de un dato, problemas causados durante un upgrade aplicativo, etc). Hemos ya mencionado que este tipo de evento es más probable que el evento de una completa pérdida del sitio de producción.

xtremio-x2-native-replication-logical-protection
xtremio-x2-native-replication-logical-protection

Como parte integrante de su mecanismo de copia remota, X2 crea automáticamente y mantiene en el sitio de DR una serie di snapshot dentro una estructura lógica que viene llamada “protection window”. El número, frecuencia y duración temporal de estos snapshot puede ser fácilmente definido gracias a la GUI de X2. Imaginemos que durante el normal proceso de copia remota, a un cierto punto se produce un error lógico sobre los datos de producción. En este caso será posible seleccionar dentro la “protection window” una copia precedente (Point in Time Copy) al error y utilizarla para volver inmediatamente al estado antecedente al evento causante la corrupción de los datos.

xtremio-x2-native-replication-benefits
xtremio-x2-native-replication-benefits
Para concluir

La elección del tipo de copia remota de los datos pone una serie di desafíos a la operatividad de las aplicaciones.

Los mecanismos de copia remota tradicional necesitan de un atento balance entre el RPO y el uso de la banda.

La búsqueda de un RPO=0 comporta una pérdida de rendimiento equivalente al tempo de latencia entre el array source y el target impactando negativamente los beneficios prestacionales de un storage AFA. 

La replicación nativa de XtremIO X2 permite de obtener un bajísimo RPO con el beneficio adicional de un mínimo consumo de bandwidth.

La replicación remota de XtremIO X2 no impacta el rendimiento del array di producción o del target y soporta, al mismo tiempo, numerosos PiT (Point in Time Copy) in grado de proteger el entorno de eventuales corrupciones lógicas.

xtremio-x2-native-replication-big-picture
xtremio-x2-native-replication-big-picture

Para mayor información:

Sistemas de Almacenamiento Dell EMC XtremIO

#IWork4Dell


Este post también está disponible en: Italiano