Logotipo de Zephyrnet

Garantía de alta disponibilidad para aplicaciones bancarias basadas en la nube

Fecha:

Es tentador pensar que un proveedor de servicios en la nube garantizará la alta disponibilidad de sus aplicaciones bancarias críticas basadas en la nube. El problema es que realmente no lo hacen.

Todd Doane, arquitecto de soluciones, tecnología SIOS

Es posible que su proveedor de nube lo haya ayudado a configurar un grupo de máquinas virtuales (VM) que se ejecutan en varios centros de datos o zonas de disponibilidad (AZ). Es posible que haya implementado un sistema de conmutación por error automatizado para garantizar que una VM en espera en la configuración pueda tomar el control de inmediato si la VM principal se desconecta repentinamente. Parece que debería ofrecer alta disponibilidad, ¿verdad?

Pero fíjese bien en el acuerdo de nivel de servicio (SLA) que describe la alta disponibilidad: el SLA garantiza que al menos una de las máquinas virtuales de su sistema estará accesible al menos el 99.9 % o incluso el 99.99 % del tiempo. Pero eso no es una garantía de disponibilidad de aplicaciones o datos. Si la VM restante no puede acceder a la infraestructura de almacenamiento donde residen sus aplicaciones y datos bancarios, sus aplicaciones críticas están efectivamente fuera de línea.

Garantizar la accesibilidad a la nube

¿Cómo puede asegurarse de que sus datos y aplicaciones bancarias críticas permanezcan altamente accesibles en la nube o en una configuración híbrida local/en la nube, si la configuración de la tecnología subyacente para la conmutación por error automatizada en múltiples AZ no es suficiente?

Comencemos diciendo que tener máquinas virtuales en clúster repartidas entre varias zonas de disponibilidad es fundamental para garantizar la alta disponibilidad (HA) de sus aplicaciones y datos clave. Sin embargo, lo que necesita además es una estrategia para garantizar que cada una de esas máquinas virtuales tenga acceso a las aplicaciones y los datos críticos que desea seguir ejecutando. Ahí es donde los enfoques tradicionales de HA divergen cuando se trata de la nube.

En una configuración HA tradicional, es decir, en las instalaciones, puede crear un clúster de conmutación por error que consta de varios servidores o máquinas virtuales y una red de área de almacenamiento (SAN), donde residen sus aplicaciones y datos. Cualquier servidor o VM en el clúster podría interactuar con las aplicaciones y los datos en la SAN, por lo que si la VM que ejecuta activamente una aplicación clave se desconecta repentinamente, el clúster conmutará automáticamente a otra VM que podría interactuar con la SAN y comenzar a ejecutar la aplicación y actualizando la misma base de datos que la máquina anterior había estado usando.

Configuración para la nube

Sin embargo, en la nube no existe una opción real para crear una SAN compartida. Hay algunas opciones de almacenamiento compartido, pero no están diseñadas para proporcionar el rendimiento o los niveles de alta disponibilidad que requieren sus aplicaciones bancarias críticas. En cambio, las configuraciones de alta disponibilidad basadas en la nube dependen del almacenamiento de alto rendimiento conectado a cada una de las máquinas virtuales del clúster. Cuando una máquina virtual determinada ejecuta una aplicación, interactúa con los datos almacenados en una base de datos que reside en el almacenamiento adjunto a esa máquina virtual.

Entonces, la clave de HA para las aplicaciones bancarias basadas en la nube es garantizar que cada máquina virtual en su clúster siempre tenga las mismas aplicaciones y los mismos datos. De esa manera, si la VM principal en el clúster se apaga repentinamente, el clúster puede conmutar por error automáticamente a una VM en espera, cualquiera de las cuales puede comenzar a ejecutar la aplicación e interactuar con los datos de inmediato porque una copia de la aplicación y los datos residen en su propio almacenamiento adjunto.

Su proveedor de nube puede configurar fácilmente las máquinas virtuales que proporcionarán los niveles de rendimiento y disponibilidad que demandan sus aplicaciones críticas. También puede conectar sistemas de almacenamiento de alto rendimiento a esas máquinas virtuales y puede configurar su clúster para la conmutación por error automática en varias zonas de disponibilidad. Luego, debe implementar un mecanismo que automatice la replicación síncrona de datos entre todos los sistemas de almacenamiento conectados a las máquinas virtuales en su clúster de conmutación por error.

Soluciones de replicación de datos

Tiene varias opciones cuando se trata de soluciones de replicación de datos.

Si su clúster se basa en Windows y está utilizando Microsoft SQL Server, puede usar la función de grupos de disponibilidad (AG) integrada de SQL Server, que replicará automáticamente las bases de datos SQL con nombre de usuario en cada uno de los nodos de su clúster. La desventaja de este enfoque es que solo replica bases de datos SQL, en lugar de cada bloque de datos almacenado. La replicación de varias bases de datos de SQL Server en varias máquinas virtuales en espera puede resultar muy costosa, ya que tendrá que usar SQL Server Enterprise Edition para replicar más de una base de datos o para replicar bases de datos en varias máquinas virtuales, incluso si sus aplicaciones funcionan perfectamente con SQL Server Standard Edition. .

Como alternativa, podría usar una solución de agrupación en clústeres sin SAN, que proporciona replicación automatizada a nivel de bloque de datos desde la máquina virtual principal activa a cada una de las máquinas virtuales secundarias en un clúster. La ventaja de usar una solución SANless Clustering es que es independiente de la aplicación y la base de datos; simplemente replica bloques de datos de un sistema de almacenamiento a otro, lo que garantiza que todos los datos de su sistema de almacenamiento principal se repliquen en cada una de las demás máquinas virtuales. La desventaja de un enfoque de agrupación en clústeres sin SAN es que hay otra pieza de software para que su equipo de TI obtenga la licencia y aprenda, lo que puede parecer oneroso si puede usar la funcionalidad AG de SQL Server sin costo adicional.

La replicación de datos es la clave para garantizar HA para los sistemas bancarios basados ​​en la nube, ya sea que utilice la funcionalidad integrada en una solución como SQL Server o la funcionalidad proporcionada por una solución de clúster independiente SANless.

Su proveedor de nube puede proporcionar la infraestructura de alto rendimiento que exigen sus aplicaciones, pero debe asegurarse de que los datos y las aplicaciones disponibles para cada una de las máquinas virtuales en ese clúster estén actualizados si su solución HA funcionará como se espera cuando la necesite. para hacerlo.

Todd Doane es arquitecto de soluciones en SIOS Technology. Ha pasado más de 20 años, principalmente en el mundo de los servicios financieros, creando arquitecturas de referencia de alta disponibilidad y patrones y principios de diseño específicos de la aplicación.

punto_img

Información más reciente

punto_img