Omitir navegación

MSC Mediterranean Shipping Company en Azure Site Recovery

Publicado el 22 enero, 2020

Senior Program Manager, Azure Site Recovery

La entrada de blog de preguntas y respuestas de hoy ofrece una entrevista que Siddharth Deekshit, administrador de programas en el equipo de ingeniería de Microsoft Azure Site Recovery, le hace a Quentin Drion, director de TI para infraestructura y operaciones en MSC. MSC es una empresa internacional que opera en el sector del transporte marítimo y la logística. Nuestra conversación se centra en el proceso que ha seguido la organización con Azure Site Recovery (ASR). Para obtener más información sobre cómo lograr resistencia en Azure, consulte este documento.

Me gustaría comenzar por conocer el proceso de transformación que está experimentando MSC, incluida la consolidación en Azure. ¿Puede decirnos de qué forma les está ayudando Azure a dirigir su negocio actualmente?

Nosotros somos una naviera; por tanto, trasladamos contenedores por todo el mundo. A lo largo de los años, hemos desarrollado nuestro propio software para administrar el negocio principal. Tenemos diferentes programas de software para entidades pequeñas, medianas y grandes que antes se ejecutaban en el entorno local. Esto suponía tener que mantener muchos recursos locales para sustentar todas estas aplicaciones empresariales. Hace unos años se tomó la decisión de consolidar todas estas cargas de trabajo empresariales en Azure, independientemente del tamaño de la entidad. Cuando llevamos a cabo la migración, desactivamos lo que tenemos en el entorno local y comenzamos a usar el software hospedado en Azure, que lo proporcionamos como un servicio para nuestras subsidiarias. Este nuevo diseño se administra de forma centralizada, de lo que se ocupa un equipo de TI interno.

Es fantástico. La consolidación es una gran ventaja de usar Azure. Aparte de eso, ¿qué otras ventajas ve en la migración a Azure?

Para nosotros, la automatización es una gran ventaja que supone una gran mejora. La funcionalidad en términos de API para la integración y la automatización que podemos obtener con Azure nos permite implementar entornos en cuestión de horas, mientras que antes tardábamos muchísimo más porque teníamos que pedir el hardware, instalarlo y, después, configurarlo. Ahora ya no nos tenemos que preocupar por la instalación ni por el soporte técnico ni las garantías del hardware. El entorno está totalmente virtualizado y, por supuesto, podemos proporcionar el mismo objetivo de punto de recuperación (RPO), el mismo objetivo de tiempo de recuperación (RTO) y la misma seguridad a todas las entidades que tenemos en todo el mundo.

Ya que menciona el RTO y el RPO, hablemos un poco de Site Recovery. ¿Puede decirme cómo eran las cosas antes de usar Site Recovery?

En realidad, cuando comenzamos a migrar las cargas de trabajo, seguíamos un enfoque mucho más tradicional, en el sentido de que poníamos las cargas de trabajo de producción principales en una región de Azure y configurábamos y administrábamos una infraestructura de recuperación ante desastres completa en otra región. Por tanto, en Azure comenzamos realmente con un enfoque tradicional de centro de datos local para la recuperación ante desastres (DR), pero entonces nos paramos a analizar qué nos podía ofrecer Site Recovery. En función de los resultados y de las pruebas que realizamos, decidimos cambiar la implementación que habíamos utilizado durante dos o tres años por Site Recovery, en última instancia, para reducir considerablemente los costos, puesto que ya no tenemos que mantener la ejecución de las instancias de Azure Virtual Machines para recuperación ante desastres en otra región. En cuanto a la administración, también es más fácil ahora. En el caso de las cargas de trabajo tradicionales, tenemos un RPO y un RTO mejores que con nuestra estrategia anterior. Por tanto, hemos notado grandes ventajas en general.

Eso es estupendo. En cuanto al uso de Site Recovery, ¿en qué era más escéptico? Ha mencionado que su equipo realizó algunas pruebas, entonces ¿qué les convenció de que Site Recovery era la mejor opción?

En realidad, nos basamos en las pruebas que realizamos. Antes, hacíamos una gran cantidad de trabajo manual para cambiar a la región de recuperación ante desastres, con el fin de asegurarnos de que la configuración del Sistema de nombres de dominio (DNS) y otras opciones de red fueran adecuadas, así que había muchas limitaciones. Cuando lo probamos en comparación con esta forma manual de hacer las cosas, Site Recovery funcionó como algo mágico. El hecho de que, si se produjera un error en la región primaria, no nos supondría tanto trabajo fue maravilloso. Nuestras aplicaciones podían comenzar de nuevo en la región de recuperación ante desastres y solo teníamos que administrar la capa superior de la aplicación para asegurarnos de que se iniciaba correctamente. Estábamos pendientes de este reinicio de la aplicación, no por las máquinas virtuales, porque estábamos seguros de que Site Recovery funcionaría, sino por nuestro motor de base de datos. El buen funcionamiento de Site Recovery nos impresionó. Todos nuestros equipos estaban muy contentos con la solución y se están dando cuenta del valor agregado que ha supuesto el cambio a este tipo de tecnología para ellos como equipos de operaciones, pero también para el equipo de dirección, ya que nos permite ahorrar dinero al haber reducido el número de máquinas virtuales que teníamos y que, en realidad, no se usaban.

¿Puede hablarme un poco sobre su experiencia de incorporación con Site Recovery?

En ese momento, creo que teníamos en Azure seis o siete aplicaciones principales que habíamos desarrollado nosotros. Elegimos una de esas aplicaciones como candidata para probar. La prueba fue bien, así que lo ampliamos a otras aplicaciones que estaban en producción. De nuevo, no hubo ningún problema importante. El único inconveniente que tuvimos fue con algunos discos de gran tamaño. Al principio, no se admitían algunos de nuestros discos de mayor tamaño. Esto se resolvió rápidamente y, desde entonces, yo diría que todo ha transcurrido sin problemas. Tras el éxito de las pruebas, cambiamos todas las aplicaciones que tenemos en la plataforma para usar Site Recovery como sistema de recuperación ante desastres.

¿Qué cargas de trabajo ejecutan actualmente en Azure Virtual Machines? ¿Cuántas personas utilizan las aplicaciones que se ejecutan en esas máquinas virtuales para su trabajo diario?

Bueno, son realmente aplicaciones empresariales principales. Por supuesto, está la infraestructura principal subyacente, pero lo que ofrecemos son aplicaciones empresariales que hemos escrito internamente y que se presentan en un front-end de Citrix en Azure. Con estas aplicaciones se realizan reservas de contenedores, registros de clientes, etc. Quiero decir que hay diferentes cargas de trabajo asociadas al proceso de transporte completo. En términos de usuarios, tenemos algunas aplicaciones que las usan más de 5000 personas, y cada vez es más frecuente que se conviertan en la aplicación principal de su trabajo diario.

Vaya, ese sí que es un gran volumen de uso y estoy encantado de que confíen en Site Recovery para sus necesidades de recuperación ante desastres. ¿Puede hablarme un poco de la arquitectura de esas cargas de trabajo?

La mayoría de ellas son cargas de trabajo basadas en Windows. El software más utilizado en todo el mundo es una aplicación de 3 niveles. Tenemos una base de datos en SQL, un servidor de nivel intermedio, un servidor de aplicaciones y también algunos servidores de front-end web. Pero la nueva aplicación que hemos desarrollado ahora está basada en microservicios. Hay también algunos servidores Linux con un uso específico.

Háblenos de su experiencia con Linux.

Site Recovery funciona a las mil maravillas con las cargas de trabajo de Linux. Solo hubo algunos errores al principio por nuestra parte. Queríamos usar un producto de Red Hat denominado Satellite para las actualizaciones, pero no nos dimos cuenta de que no podíamos cambiar la manera en la que se administran las máquinas virtuales para usar Satellite. Debe definirse al principio; si no, es demasiado tarde. Pero, además de esto, la opción de “traiga su propia licencia” funciona muy bien, especialmente con Site Recovery.

Me alegra saber que ha sido una experiencia sin problemas para ustedes. ¿Hubo algún otro aspecto de Site Recovery que le impresionó o que cree que otras organizaciones deben conocer?

Para mí, la capacidad de poder realizar pruebas tan fácilmente. Con el enfoque más tradicional, cada vez que queríamos hacer una prueba de recuperación ante desastres completa, suponía mucho tiempo y recursos para prepararla. Con Site Recovery, realizamos una prueba hace varias semanas en el entorno completo y fue realmente fácil de preparar. Fue muy rápido hacer el cambio a la región de recuperación y, luego, fue igual de sencillo volver a traer la carga de trabajo a la región primaria. Por eso, quiero destacar la facilidad de uso de Site Recovery.

Si tuviera que repetirlo todo otra vez, ¿qué cambiaría en su proceso de adopción de Site Recovery?

Empezaría a usarlo antes. Si no hubiésemos adoptado el método tradicional activo-pasivo, creo que le habríamos ahorrado tiempo y dinero a la empresa. Por otro lado, confiábamos en el proceso de transición en este sentido. Aparte de eso, no creo que hubiésemos cambiado mucho más. Pero lo que queremos hacer ahora es empezar a considerar los servicios de Azure Site Recovery para replicar cargas de trabajo que se ejecutan en máquinas virtuales del entorno local en Hyper-V. Para las aplicaciones que todavía no hemos migrado a Azure, queremos asegurar al menos una recuperación ante desastres adecuada. También queremos replicar algunas máquinas virtuales VMware que seguimos teniendo como parte de nuestro proceso de migración a Hyper-V. Esto es lo que estamos considerando ahora.

¿Tiene algún consejo para el personal de otros clientes posibles o actuales de Site Recovery?

Yo aconsejaría comenzar antes y, si es necesario, a pequeña escala. Empezar a usar Site Recovery incluso para una sola aplicación de tamaño reducido. Ayudará a ver el valor agregado y eso ayudará a convencer a los equipos de operaciones del gran valor que pueden obtener y de que pueden confiar en los servicios que proporciona Site Recovery, en lugar de intentar hacerlo todo por ellos mismos.

Ese es un consejo excelente. Con esto he acabado las preguntas, Quentin. Muchas gracias por compartir su experiencia.

Más información sobre la resistencia en Azure.