Azure Site Recovery: Mobility Service en GNU/Linux

Quizá no hemos tenido todavía ocasión de hablar en este blog de Azure Site Recovery, la solución de recuperación de desastres ofrecida como servicio desde Microsoft Azure. Este servicio mantiene una sincronización de nuestra infraestructura on-premises, ya sean máquinas físicas, Amazon Web Services, Hyper-V o VMWare con Azure; y puede realizar una operación de failover y levantar todo el entorno en caso de desastre para seguir dando continuidad a nuestro negocio. La doble vertiente de lo que os acabo de contar, es que si estamos sincronizando nuestra infraestructura con Azure, podemos deducir fácilmente que este escenario es muy válido para realizar una migración a Azure de nuestra plataforma actual, beneficiándonos de RTOs y RPOs realmente bajos.

El tema que me ocupa hoy sobre Azure Disaster Recovery es hablaros de una casuística concreta, pero muy común en los entornos de protección o migración de VMWare, AWS o máquinas físicas a Azure: el soporte del Mobility Service en GNU/Linux. El Mobility Service es un agente que se instala en las máquinas a proteger o migrar desde Windows y GNU/Linux. Este agente se integra con el kernel de la máquina en cuestión e intercepta las llamadas de E/S de disco, enviándolas al Process Server para que sean comprimidas, cifradas y enviadas al Master Target Server en Azure.

Si miramos las distribuciones de GNU/Linux actualmente soportadas, veremos que las opciones no son especialmente amplias. Tenemos las siguientes:

  • CentOS 6.4, 6.5, 6.6 (amd64)
  • Oracle Enterprise Linux 6.4, 6.5 (amd64)
  • SUSE Linux Enterprise Server SP3 (amd64)

Hay distribuciones muy comunes en entornos productivos empresariales que quedan fuera de esta lista, como Redhat Enterprise Linux, o Debian y las basadas en la misma, como Ubuntu. Lo primero que se le viene a un sysadmin a la cabeza, es que, si conocemos bien la distribución en la que queremos implementar el servicio, basta con adaptar el paquete de instalación, sistema de paquetes y sus scripts para que se instale en nuestro sistema. Así podríamos usar alien para convertir los RPM en DEB y editar los scripts para adaptar el sistema de arranque y las rutas… Craso error…

Como he comentado al principio de este artículo, este agente se integra con el kernel de Linux, que como los más técnicos sabréis se trata de un kernel monolítico, con la estructura que podéis ver en la siguiente imagen, cortesía de Wikipedia:

image

Como se puede ver, la totalidad del sistema operativo opera en modo kernel. Como todo en la vida, los kernels monolíticos tienen ventajas e inconvenientes sobre otras arquitecturas de núcleos de sistemas operativos, como los microkernel y los kernel híbridos. En cualquier caso, una de las consecuencias de este modelo es que si vamos a desarrollar algún software que requeire trabajar a bajo nivel con el sistema, probablemente debamos implementarlo dentro del kernel, seguramente como un módulo del mismo. Si desarrollamos un módulo para el kernel de Linux y realizamos una compilación para una versión determinada del kernel, este binario sólo se puede incorporar en la versión exacta del kernel para el que ha sido compilado. Por ejemplo, imaginad que desarrollamos un módulo para la versión 3.2.0; esta sólo se podrá ejecutar en esta versión concreta del kernel y en ninguna otra.

Cuando examiné el contenido del paquete de instalación del Mobility Service pude ver lo siguiente:

image

Y si examinamos el script install_vx podemos ver lo siguiente:

image

Esto empieza a pintar a versiones muy concretas del kernel en distintas distribuciones… Me temo que como nos salgamos de esto no vamos a lograr que el servicio funcione. Si vamos un poco más allá y examinamos los contenidos del paquete InMageVx-8.4.0.0-1.x86_x64.rpm descubrimos los siguientes archivos:

image
Y aquí definitivamente nos encontramos con los módulos del kernel y la versión concreta para la que están preparados. Llegados este punto, la única forma de la que podríamos hacer funcionar el Mobility Service sería instalando en nuestra distribución la versión concreta del kernel para la que está soportado. Tened en cuenta que aunque llevásemos a cabo esta acción, estaríamos totalmente fuera del soporte que Microsoft da a la solución, por no mencionar que es toda una temeridad cambiarle el kernel a un sistema del cual pretendemos hacer un plan de Disaster Recovery o una migración con RPOs y RTOs cercanos a cero.

Así pues terminamos con las siguientes conclusiones:

  • El Mobility Service de Azure Disaster Recovery sólo puede instalarse en las versiones de GNU/Linux concretamente soportadas: CentOS, Oracle Linux y SUSE Enterprise Linux en sus versiones y arquitecturas concretas.
  • Puesto que la intercepción de la E/S de disco de la máquina se realiza a bajo nivel desde el mismo kernel, el driver del agente está implementado como módulo del mismo. No podemos adaptarlo a otras versiones del kernel porque sólo tenemos los binarios.
  • Las alternativas que Microsoft podría implementar para dar un soporte a más distribuciones sería:
    • Distribuir el código fuente del agente de forma que se compile durante la instalación. Esto haría el agente mucho más universal y no dependiente de versiones concretas del kernel.
    • Proveer de un buen número de binarios que soporte las versiones del kernel más comunes que se pueden encontrar a día de hoy.

De una forma u otra, esperamos que Microsoft de soporte a un rango más amplio de distribuciones de GNU/Linux para que este servicio tan potente se haga muy flexible. ¿Quieres aportar tu sugerencia? ¡Déjasela caer en el User Voice de Azure Site Recovery!

Happy migration!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *