Replicación de datos asíncrona
La tecnología de replicación asíncrona es la más reciente alternativa para proporcionar tolerancia a fallos en servidores y almacenamiento en red. A diferencia de las tecnologías de replicación anteriores, trabaja capturando los cambios en los ficheros en el nivel del sistema operativo.
Las tecnologías de replicación convencionales –de las que la replicación de transacciones SQL es un ejemplo– actúan en el nivel de las aplicaciones o en el del hardware. Y de ahí, algunos de sus inconvenientes. En el primer caso, el grado de protección está limitado a un único motor de aplicación y típicamente genera sobrecargas en la red; en el segundo, a menudo provoca latencias en el disco de producción, así como un nivel de utilización WAN significativo y, al mismo tiempo, desaconsejable debido a sus costes.
Byte a byte
En lugar de replicar transacciones en una aplicación o bloques de discos, la tecnología de replicación asíncrona captura los cambios que se producen en cualquier fichero gestionado por el sistema operativo del servidor a nivel de byte. Esto se logra mediante la instalación de un driver de filtrado, cuya función consiste en discriminar todas las transacciones enviadas a un determinado sistema de ficheros. Utilizando un pequeño número de reglas, el driver captura una copia de cada transacción y la envía a un servicio de sistema o daemon, el cual entonces la transmite vía TCP/IP al servidor determinado previamente.
Con independencia de la aplicación que esté creando el cambio de los datos (SQL, Exchange, servicios Web o compartición de ficheros), la escritura de disco tiene la misma apariencia mientras la detecta el sistema operativo. Se trata, en concreto, de una instrucción para modificar los bytes lógicos de un disco determinado.
Desde el punto de vista del sistema operativo, no existe diferencia entre una actualización a Exchange y una actualización a un fichero de texto de NotePad.exe. De esta forma, esta propuesta asegura la completa independencia de la replicación de datos de la aplicación concreta desde la que se hayan producido las modificaciones. Además, también es independiente del hardware: da igual que un sistema operativo Windows 2000 esté almacenando datos sobre una red de área de almacenamiento o sobre sus propios drivers.
Un malentendido común sobre la replicación asíncrona es la idea de que el ritmo de la replicación de datos no puede seguir al de su producción, por lo que la réplica estaría siempre, en mayor o menor medida, desactualizada. Pero esto sólo ocurre en los casos en que existe un flujo constante de escrituras a los discos de producción y la cantidad bytes modificados es mayor que el ancho de banda. Sin embargo, en muchos entornos –especialmente en grandes bases de datos– las demandas de E/S sobre los discos de producción son significativamente más altas en lecturas que en escrituras. Por tanto, el pequeño porcentaje de escrituras E/S se replica con una latencia insignificante.
En lo que se refiere a la entrega de los datos, casi todas las tecnologías de replicación utilizan protocolos de red estándar. Un factor diferenciador es si emplean un cable de paso (crossover) dedicado o IP estándar. Las conexiones crossover requieren que los servidores estén relativamente próximos, lo cual impide la viabilidad de esta alternativa cuando lo que se busca es una solución de recuperación ante desastres. Por el contrario, una combinación de networking IP estándar con un sistema de replicación asíncrona, basada en el despliegue de los servidores objeto de la recuperación a través de Internet o una WAN corporativa, proporciona una propuesta de recuperación ante desastres muy económica.
Todo en orden
En cuanto a la integridad de los datos, es importante asegurar la transmisión secuencial de la replicación asíncrona. Debido a que en entornos de área amplia es más probable que se produzcan pérdidas de paquetes, y teniendo además en cuenta que es posible un determinado nivel de latencia, cuando se implementa un sistema de recuperación de datos resulta crítico tomar las medidas oportunas para garantizar que los paquetes llegan a su destino en el mismo orden en que fueron emitidos.
Es precisamente en el momento en que el sistema operativo recibe los cambios lógicos desde las aplicaciones y los convierte en instrucciones de escritura de fichero, cuando las tecnologías de replicación asíncrona capturan esos comandos de cambio de ficheros y los envían a otro servidor vía IP. El segundo servidor simplemente aplica el mismo comando de cambio de fichero.
Cómo funciona
---------------------
Este nuevo enfoque de replicación para servidores y almacenamiento en red captura los cambios de los ficheros al nivel del sistema operativo, proporcionando una mayor tolerancia a fallos.
1- El usuario cambia un fichero, ejecuta una transacción o introduce nueva información en una base de datos.
2- Los datos fluyen desde el usuario hasta el nivel de aplicación, sistema operativo y sistema de ficheros del servidor casi en tiempo real.
3- Después, los datos van al hardware de almacenamiento.
4- El driver de filtrado del sistema de ficheros captura una copia de los datos y la envía al servidor B cuando el ancho de banda esté disponible.
5- El servidor B envía la copia backup de los datos al hardware de almacenamiento.
Las tecnologías de replicación convencionales –de las que la replicación de transacciones SQL es un ejemplo– actúan en el nivel de las aplicaciones o en el del hardware. Y de ahí, algunos de sus inconvenientes. En el primer caso, el grado de protección está limitado a un único motor de aplicación y típicamente genera sobrecargas en la red; en el segundo, a menudo provoca latencias en el disco de producción, así como un nivel de utilización WAN significativo y, al mismo tiempo, desaconsejable debido a sus costes.
Byte a byte
En lugar de replicar transacciones en una aplicación o bloques de discos, la tecnología de replicación asíncrona captura los cambios que se producen en cualquier fichero gestionado por el sistema operativo del servidor a nivel de byte. Esto se logra mediante la instalación de un driver de filtrado, cuya función consiste en discriminar todas las transacciones enviadas a un determinado sistema de ficheros. Utilizando un pequeño número de reglas, el driver captura una copia de cada transacción y la envía a un servicio de sistema o daemon, el cual entonces la transmite vía TCP/IP al servidor determinado previamente.
Con independencia de la aplicación que esté creando el cambio de los datos (SQL, Exchange, servicios Web o compartición de ficheros), la escritura de disco tiene la misma apariencia mientras la detecta el sistema operativo. Se trata, en concreto, de una instrucción para modificar los bytes lógicos de un disco determinado.
Desde el punto de vista del sistema operativo, no existe diferencia entre una actualización a Exchange y una actualización a un fichero de texto de NotePad.exe. De esta forma, esta propuesta asegura la completa independencia de la replicación de datos de la aplicación concreta desde la que se hayan producido las modificaciones. Además, también es independiente del hardware: da igual que un sistema operativo Windows 2000 esté almacenando datos sobre una red de área de almacenamiento o sobre sus propios drivers.
Un malentendido común sobre la replicación asíncrona es la idea de que el ritmo de la replicación de datos no puede seguir al de su producción, por lo que la réplica estaría siempre, en mayor o menor medida, desactualizada. Pero esto sólo ocurre en los casos en que existe un flujo constante de escrituras a los discos de producción y la cantidad bytes modificados es mayor que el ancho de banda. Sin embargo, en muchos entornos –especialmente en grandes bases de datos– las demandas de E/S sobre los discos de producción son significativamente más altas en lecturas que en escrituras. Por tanto, el pequeño porcentaje de escrituras E/S se replica con una latencia insignificante.
En lo que se refiere a la entrega de los datos, casi todas las tecnologías de replicación utilizan protocolos de red estándar. Un factor diferenciador es si emplean un cable de paso (crossover) dedicado o IP estándar. Las conexiones crossover requieren que los servidores estén relativamente próximos, lo cual impide la viabilidad de esta alternativa cuando lo que se busca es una solución de recuperación ante desastres. Por el contrario, una combinación de networking IP estándar con un sistema de replicación asíncrona, basada en el despliegue de los servidores objeto de la recuperación a través de Internet o una WAN corporativa, proporciona una propuesta de recuperación ante desastres muy económica.
Todo en orden
En cuanto a la integridad de los datos, es importante asegurar la transmisión secuencial de la replicación asíncrona. Debido a que en entornos de área amplia es más probable que se produzcan pérdidas de paquetes, y teniendo además en cuenta que es posible un determinado nivel de latencia, cuando se implementa un sistema de recuperación de datos resulta crítico tomar las medidas oportunas para garantizar que los paquetes llegan a su destino en el mismo orden en que fueron emitidos.
Es precisamente en el momento en que el sistema operativo recibe los cambios lógicos desde las aplicaciones y los convierte en instrucciones de escritura de fichero, cuando las tecnologías de replicación asíncrona capturan esos comandos de cambio de ficheros y los envían a otro servidor vía IP. El segundo servidor simplemente aplica el mismo comando de cambio de fichero.
Cómo funciona
---------------------
Este nuevo enfoque de replicación para servidores y almacenamiento en red captura los cambios de los ficheros al nivel del sistema operativo, proporcionando una mayor tolerancia a fallos.
1- El usuario cambia un fichero, ejecuta una transacción o introduce nueva información en una base de datos.
2- Los datos fluyen desde el usuario hasta el nivel de aplicación, sistema operativo y sistema de ficheros del servidor casi en tiempo real.
3- Después, los datos van al hardware de almacenamiento.
4- El driver de filtrado del sistema de ficheros captura una copia de los datos y la envía al servidor B cuando el ancho de banda esté disponible.
5- El servidor B envía la copia backup de los datos al hardware de almacenamiento.
