Questo post è anche disponibile in italiano
Discutamos en este post una de las actividades que presenta más desafíos en un data center; CDM. Dicho en modo muy simple, CDM (Copy Data Management), se refiere al conjunto de tareas que deben realizarse para crear copias de datos. Proporcionar copias de los datos de producción es importante por muchas razones: la protección de datos, copias de seguridad, copias de análisis, copias para test y desarrollo, etc.
La posibilidad de proporcionar en un modo eficiente copias de los datos en un data center aumenta el TCO y la capacidad de realizar más actividades.
Debido a que XtremIO es completamente diferente a cualquier otra tecnología vista antes, para comprender mejor los beneficios de XtremIO iCDM vamos a discutir primero lo que se podría llamar “aprender” y “desaprender”.
Aprender y desaprender
Cuando consideramos los mecanismos de copia de datos que conocemos, hacemos una serie de suposiciones, pero con XtremIO tenemos que pensar de manera diferente. Veamos lo que necesitaríamos desaprender y aprender con XtremIO.
Desaprender: Emplear largo tiempo para las operaciones de copia
Aprender: Copias instantáneas
Desaprender: Mucho consumo de espacio
Aprender: Eficiencia
Desamprender: impactos en el rendimiento
Aprender: ningún impacto de performance
Desaprender: número limitado de copias
Aprender: gran número de copias
Desamprender: operaciones manuales
Aprender: «Orchestration»
Desamprender: clones, snaps
Aprender: XtremIO Virtual Copies (XVC)
Copias de datos en un ambiente aplicativo
Pensemos a una aplicación típica de un cliente para ilustrar los desafíos que un entorno como éste tiene. Podemos imaginar un entorno como Oracle o SAP, aunque si cualquier otro ambiente presenta problemáticas similares.
En un entorno de bases de datos existen diversas aplicaciones que se ejecutan contemporáneamente. Por ejemplo, en el caso de SAP, para cada una de estas aplicaciones el cliente necesita un “landscape” de Producción y un “landscape” de Proyecto, o sea 2 niveles. El landscape de Producción consiste típicamente en una serie de volúmenes; uno para el desarrollo, al menos uno para usar como prueba, otro volumen para el control de calidad y, por supuesto, el sistema de producción. Así tenemos una serie de objetos en el sistema que se “transportan” entre los landscapes y terminan finalmente en la producción. Este “transporte” se refiere a operaciones como “refresh” o actualización y es aquí donde XtremIO ofrece grandes ventajas. La producción está normalmente sobre dimensionada (overprovisioned) porque los clientes no quieren quedarse sin espacio justo en este ambiente. Luego hay varias copias y ahí es donde una gran cantidad de almacenamiento entra en juego; test1, test2, QA1, Q2, etc. El resultado es que, de esta manera, el presupuesto de almacenamiento es muy alto. Al final, empezando con una producción de 10 TB se acaba con más de 100 TB. Muy costoso y poco eficiente.
En las implementaciones de este tipo, con frecuencia el ambiente de desarrollo no es una copia reciente, los datos en el sistema son completamente obsoletos y esto significa que se necesita realizar una gran cantidad de transportes hacia el ambiente de QA para verificar cada vez el impacto del desarrollo efectuado antes de que los datos puedan terminar en Producción. Esto quiere decir que si tuviéramos la posibilidad de trabajar en el ambiente de desarrollo con una copia más reciente de los datos, esto podría aumentar la calidad del desarrollo y reducir el número de transportes. Pensemos también acerca de la complejidad de los distintos volúmenes (copias) que a veces viven en diferentes niveles de almacenamiento para mitigar los costos. Con diferentes niveles de almacenamiento me refiero a diferentes tecnologías de discos. Es una práctica común tener el ambiente de Producción en discos con alto rendimiento (FC 15K, Raid-1) mientras los ambientes de test por ejemplo en discos con menor rendimiento (SAS 10K, Raid-5). Muchas veces inclusive, se utilizan plataformas (arrays) diferentes, (también de diferentes proveedores). Gestionar el crecimiento de esta manera es realmente muy complejo. Por otro lado, se prueba la aplicación sobre un ambiente que no tiene las mismas características de rendimiento del que será el ambiente de Producción desconociendo como exactamente este se comportará.
Mecanismos tradicionales de copia de datos
Veamos brevemente los mecanismos de copia de datos hasta ahora conocidos.
Clones: Nada nuevo aquí. Los clones son copias físicas, byte por byte de un volumen. A veces los clones también se conocen como un mecanismo de copia de fuerza bruta.Muchas veces nos vemos obligados a utilizarlos. Por ejemplo cuando no es posible o no se desea tener impactos de rendimiento en los volúmenes de Producción. En estos casos se necesita efectuar copias completamente separadas como las que ofrecen los clones. ¿Pero cuáles son los inconvenientes aquí? Muchos: se consume un espacio igual al volumen original, los clones necesitan tiempo para completarse, se limita la frecuencia de copia y la agilidad de todo el ambiente. Como efectuar copias de este modo es muy costoso, se recurre frecuentemente a usar discos de menor costo (y rendimiento). Desgraciadamente el efecto final es que el rendimiento de todo el array disminuye porque éste debe utilizar más recursos para realizar la copia y no menos importante, el ciclo de desarrollo es mayor no pudiendo contar con un medio veloz donde efectuar las pruebas.
Snaps: Fundamentalmente existen dos técnicas para realizar snaps; COW (Copy On first Write) y ROW (Redirect on Write).
COW: En este tipo de implementación, la creación de un snapshot determina la definición de un storage pool adicional dentro del array. Este storage pool tiene como objetivo poder almacenar las nuevas escrituras que se ejecutan sobre el volumen de producción. En práctica, cada vez que una nueva escritura es dirigida hacia el volumen de producción, suceden dos cosas, 1- el “viejo” dato es copiado en el pool del snapshot y luego 2- el nuevo dato es copiado en el volumen de producción. Se podría pensar que cuando estas operaciones son ejecutadas sobre un disco flash, por el rendimiento que éstos tienen, no sería un problema. En realidad no es así.
Este mecanismos da como resultado una sobrecarga del sistema (cada actividad de escritura implica la ejecución de 2 operaciones de I/O adicionales) afectando tanto el consumo de los discos flash (disminuyendo la duración) como el rendimiento del array en su totalidad (necesidad de hacer más I/O).
ROW: El siguiente paso en la evolución de la tecnología de snaps ha resuelto algunos problemas de rendimiento a través de la gestión de los metadatos. En este tipo de implementación, cuando se ejecuta un snapshot, los metadatos (punteros) del volumen de producción crean una segunda copia en un área de memoria diferente en el array. El array mantiene de esta forma 2 áreas de metadatos, un área para el volumen de producción y un área para el volumen snap. De ahí en más, cada vez que hay que un nuevo dato necesita ser escrito sobre el volumen de producción, el sistema modifica los metadatos para que punten a la ubicación exacta de los datos sin necesidad de mover bloques de datos del volumen de producción como sucede con el mecanismo de COW.
Este tipo de implementación es eficiente pero presenta todavía algunos problemas: muchas veces cuando se cancelan datos en el volumen de producción, actividad que se hace eliminando los punteros, pueden quedar todavía los bloques de datos en los discos y esto necesita un trabajo adicional de “space-reclamation” que no siempre es efectivo. Además de esto, en el caso de creación de muchos snapshots o snapshots de snapshots, el acceso a los datos originales, la gestión de las modificaciones de los metadatos en esta compleja estructura y la reconciliación de los metadatos después de haber cancelado los snaphsots producen una notable disminución de rendimiento.
XtremIO no usa ninguna de estas técnicas para ejecutar los snapshots. XtremIO usa un mecanismo diferente y nuevo respecto a lo que hemos conocido hasta ahora y por este motivo usaremos el término XVC (XtremIO Virtual Copies) para referirnos a la modalidad de efectuar snaps en XtremIO.
XtremIO XVC: XtremIO usa un mecanismo de «containers» o áreas de memoria y no necesita copiar datos o metadatos durante la creación de un snapshot. El efecto principal es que la creación de un snapshot en XtremIO es una operación instantánea, porque es efectuada solo en la memoria y ocupa cero espacio en el array.
Veamos por partes su funcionamiento. En el siguiente diseño podemos notar los metadatos (in-memory metadata) que representan al volumen de producción. Estos metadatos “puntan” a los bloques de datos en los discos del array.
Cuando se crea un snap, XtremIO hace lo siguiente: 1- «congela» el área de los metadatos que hace referencia al volumen de producción, 2-crea dos nuevos containers (áreas de memoria) vacíos (Production MD, Snapshot MD) que puntan al área que referenciaba al volumen de producción. El área de metadatos del volumen de producción al momento de la creación del shapshot es ahora compartida (shared) por los dos nuevos containers apena creados. Uno de los nuevos containers será de ahora en más el container usado para referenciar al volumen de producción mientras que el otro será el container del volumen snapshot.
Si es necesario escribir un nuevo dato sobre el volumen de producción, esta actividad el array la hará usando el nuevo container de producción. Si en vez es necesario escribir un nuevo dato sobre el volumen snap, XtremIo lo hará usando el «container» del snap. Lógicamente, en los dos casos, XtremIO aplicará para cada nuevo dato que llega desde el host, los algoritmos de deduplicación y compresión antes de escribir el dato. El efecto final es que en muchos casos no es necesario escribir nada sobre los discos flash.
En este tipo de implementación es importante notar algunas grandes ventajas: La operación de creación de snaps en XtremIO es instantánea y sin consumo de espacio disco o copia de metadatos. Los snaps son, desde el punto de vista del rendimiento, iguales al volumen de producción. Los snaps consumen espacio solamente cuando se escriben datos nuevos que no pueden ser deduplicados. Con el mismo procedimiento es posible crear snapshots de snapshots sin perder el mínimo rendimiento y sin necesidad de copiar datos o metadatos. Es posible cancelar cualquiera de estos snaps en cualquier orden.
Business impacts y ventajas para las aplicaciones
A la luz de estas informaciones, veamos nuevamente el hipotético ambiente di copia de datos analizado al principio del post y apliquemos estos conocimientos para entender las ventajas que los snaps de XtremIO aportan.
Eficiencia de espacio: Decíamos que el entorno de producción es normalmente sobre dimensionado para evitar de quedarse sin espacio. Si consideramos un volumen de producción de unos 10TB, por efecto de la deduplicación y compresión nativa de XtremIO, digamos un valor conservativo de 2:1, producción ocupará unos 5TB. Agreguemos a esto que, como hemos visto, las copias en XtremIO consumen 0 (cero) espacio al momento de la creación. Muchos de los otros entornos, test, desarrollo, QA parten como copias del volumen de producción. Con XtremIO estas copias, además de poder ser creadas instantáneamente, ocuparán un espacio mínimo. El espacio ocupado dependerá de cuantos nuevos datos globalmente no deduplicados será necesario escribir en las varias copias.
Excelente rendimiento de las copias: todos los entornos (copias) tendrán el mismo rendimiento del volumen de producción permitiéndonos así de reducir notablemente los tiempos de desarrollo y test necesarios. Teniendo el ambiente de test el mismo rendimiento del ambiente de producción, quien escribe la aplicación podrá saber exactamente como esta se comportará cuando será en producción.
Inmediato «transporte» de datos: el transporte (pasaje) de datos desde los entornos de desarrollo a test, de test a QA y de QA a producción es enormemente facilitado gracias a una novedosa funcionalidad del mecanismo XVC de XtremIO. Esta funcionalidad se llama “refresh” y permite, como el nombre lo indica, refrescar un volumen a partir de otro. Imaginemos que hemos trabajado un tiempo sobre el ambiente de desarrollo y deseamos pasar o transportar los datos al ambiente de test. En un sistema tradicional sería necesario hacer por ejemplo un back-up del volumen de desarrollo y después ejecutar un restore sobre el volumen de test o, crear un nuevo snap o clone del volumen de desarrollo y montarlo como nuevo volumen de test. Lógicamente esta nueva actividad implicaría un nuevo mapping al servidor que debe ver este nuevo volumen. XtremIO en vez es suficientemente inteligente como para memorizar las datos de mapping de un volumen (iSCSI ID) y reusarlo durante el refresh. En práctica, la única cosa que hay que hacer es decir que se quiere refrescar el volumen de test con los datos del volumen de desarrollo y XtremIO ejecutará esta operación instantáneamente y sin necesidad que el servidor haga otra operación de scan para ver el volumen con los nuevos datos. Bastará solo suspender (unmount) por un instante las operaciones sobre el volumen en el momento en el que se ejecuta el refresh. De este modo, el transporte entre los varios elementos del entorno puede hacerse ahora gracias a esta técnica en un modo sumamente veloz, simple y sobre todo, sin el riesgo de errores. Por supuesto el refresh puede ser hecho en cualquier dirección, del volumen de producción al volumen de desarrollo, del volumen de producción al volumen de test y viceversa.
Ahora que hemos hecho esta introducción a los varios mecanismos de copia, estamos en condiciones de entender mejor el concepto de iCDM (Integrated Copy Data Management). Hagamos una analogía con la teoría de los 4 elementos que cuando combinados entre ellos podían crear “algo” completamente nuevo. En nuestro caso los 4 elementos son: XVC, arquitectura de XtremIO, orquestación y APIs.
Arquitectura XtremIO de tipo scale-out: XVC hace uso de la arquitectura de tipo scale-out de XtremIO la cual permite que las operaciones de copia puedan hacerse en memoria y sin impactos de rendimiento.
Orquestación: imaginemos que queremos crear copias de nuestras aplicaciones que sean consistentes del punto de vista aplicativo. Por ejemplo copias de bases de datos (Oracle, SQL Server) que no sean simples copias (crash copies), sino copias donde es posible recuperar transacciones a un punto deseado. Este tipo de copias requiere una precisa interacción entre el array y la base de datos, lo que viene llamado “application awareness”. En el caso de XtremIO esto puede ser hecho gracias a la presencia en XtremIO de un software llamado AppSync que es parte integrante de XtremIO y de la estrategia de iCDM.
Self-service provisioning: el último elemento en la estrategia de iCDM es el “self service provisioning”. Gracias a las APIs de XtremIO, es posible integrar cualquier tipo de software de management del data center con el proceso de iCDM. Dicho de otro modo, imaginemos de utilizar aplicaciones no soportadas directamente por AppSync y deseamos hacer que el mecanismo de copias sea automático. Ningún problema; gracias a las APIs de XtremIO y gracias a los varios “plug-in” (Oracle, VMware), podemos integrar en iCDM nuestras aplicaciones.
Resumiendo
iCDM es una solución única que combina 4 elementos exclusivos de XtremIO para crear un nuevo paradigma en la gestión de las copias locales que permite de automatizar, simplificar y evitar errores en el proceso de copia de datos.
Para mayor información:
XtremIO Integrated Copy Data Management (pdf)
XtremIO Integrated Copy Data Management (video)
#IWork4Dell
