Alta disponibilidad en ENSEMBLE v.1.0

Alta disponibilidad
en ENSEMBLE
Experiencias - Casos prácticos reales
Documentación de casos prácticos reales en instalaciones de clientes con ENSEMBLE que
ofrecen alta disponibilidad
Versión 1.0
Alta disponibilidad en ENSEMBLE
Alta disponibilidad en
ENSEMBLE
Uso del
documento
•••
Este documento recoge
algunas de las
Experiencias - Casos prácticos reales
arquitecturas
implementadas en
Introducción
diferentes clientes que,
ENSEMBLE es siempre un punto crítico para nuestros clientes, ya
según nuestra
que las comunicaciones entre los diferentes componentes software
experiencia, han
utilizan el EAI (Enterprise Application Integration) como elemento
demostrado ser estables
principal de comunicación.
a la hora de ofrecer alta
Por ello resulta de vital importancia asegurar que cuando haya
alguna parada planificada o no, se establezcan mecanismos seguros
disponibilidad en
entornos muy exigentes.
de alta disponibilidad que garanticen al máximo la disponibilidad
La información aquí
del servicio.
contenida no reemplaza
InterSystems ha desarrollado la tecnología mirroring con miembros
síncronos que permiten un failover automático dentro de un mismo
data center, en un tiempo mínimo, así como miembros asíncronos,
que permiten tener copias en línea en CPDs remotos. Esta
tecnología ha sido diseñada para proporcionar una solución
económica para un rápido, fiable y robusto intercambio de
servidores entre dos instancias de ENSEMBLE, resultando una
solución de alta disponibilidad empresarial efectiva.
total ni parcialmente la
documentación de
InterSystems, asimismo
tampoco pretende ser
una guía configuración
única, dado que existen
diferentes formas
válidas de configurar los
productos de
InterSystems, cada una
de ellas con
características.
Versión 1.0
1
Alta disponibilidad en ENSEMBLE
Referencias
La documentación referida a continuación ha sido utilizada como base de este documento y puede
utilizarse también para ampliar la información aquí facilitada.
•
Plataformas de Servidor soportadas por ENSEMBLE
http://docs.intersystems.com/ens20151/csp/docbook/DocBook.UI.Page.cls?KEY=ISP_technologies#
ISP_platforms_server
•
Documentación oficial ENSEMBLE sobre configuración del Mirroring
http://docs.intersystems.com/ens20151/csp/docbook/DocBook.UI.Page.cls?KEY=GHA_mirror
La tecnología mirroring proporciona opciones de desarrollo que van más allá de las plasmadas en este
documento. Para más detalles, por favor, consulte la documentación oficial.
Glosario
• Árbitro es un sistema independiente que contiene un agente ISCAgent con el que los miembros de
conmutación por error pueden mantener un contacto continuo, proporcionándoles el contexto
necesario para tomar decisiones con seguridad de conmutación por error cuando no pueden
comunicarse directamente.
• CPD o Centro de datos es una instalación utilizada por los sistemas informáticos y componentes
asociados, como las telecomunicaciones y los sistemas de almacenamiento. Por lo general, incluye
fuentes de alimentación redundantes o de respaldo, conexiones de comunicaciones de datos
redundantes, controles ambientales (por ejemplo, aire acondicionado, extinción de incendios) y
varios dispositivos de seguridad.
• La recuperación de desastres (DR) implica un conjunto de políticas y procedimientos que
permiten la recuperación o el mantenimiento de una infraestructura y sistemas de tecnología
después de un desastre natural o provocado por el hombre. La recuperación de desastres se centra
en los sistemas informáticos o tecnológicos que apoyan las funciones críticas del negocio, a
diferencia de la continuidad del negocio, que implica el mantenimiento de todos los aspectos
esenciales de un negocio en funcionamiento a pesar de acontecimientos extraordinarios. Por lo
tanto, la recuperación de desastres es un subconjunto de la continuidad del negocio.
• Enterprise application integration (EAI) o integración de aplicaciones empresariales es el uso
de principios de arquitectura software y sistemas informáticos para integrar un conjunto de
aplicaciones informáticas empresariales.
• Failover. Cambio a un servidor, sistema, componente de hardware o de red redundantes ante un
fallo o una parada anormal en una aplicación activa, servidor, componente o red.
• Mirror es una agrupación lógica de instancias de Ensemble físicamente independientes que
mantienen simultáneamente copias exactas de las bases de datos de producción, de modo que si la
instancia que proporciona acceso a las bases de datos no está disponible, la otra puede tomar el
Versión 1.0
2
Alta disponibilidad en ENSEMBLE
relevo. Un mirror proporciona alta disponibilidad mediante conmutación automática cuando hay un
fallo en una instancia de Ensemble (o un fallo en el sistema que ls aloja) se provoca que la otra
instancia se haga cargo de forma automática e inmediata.
Versión 1.0
3
Alta disponibilidad en ENSEMBLE
Caso Práctico
Resumen
Cliente que tiene dos CPDs para soportar a una gran red de hospitales y centros de atención
primaria:
•
•
•
Los hospitales están repartidos geográficamente y tienen uno de los dos CPDs disponibles asignados
(el que geográficamente está más cerca).
En cada uno de los CPDs hay un mirror síncrono para garantizar la disponibilidad del servicio en ese
CPD.
Adicionalmente cada CPD tiene configurado como Recuperación ante Desastres (Disaster Recovery)
al otro CPD.
Esquema general
Versión 1.0
4
Alta disponibilidad en ENSEMBLE
Configuración
Instancias
En cada CPD se instalarán tres instancias Ensemble:
•
•
EnsA, EnsB – dedicadas a failover.
EnsDR – dedicado a servir de disaster recovery del otro CPD.
También es posible utilizar un árbitro para tomar las decisiones en caso de fallo que impida a las
instancias comunicarse entre si. Esta funcionalidad está disponible en la versión 2015.1 y posteriores.
Distribución de una instancia
Cada instancia se organizará lógicamente de la siguiente forma:
•
•
Un namespace por hospital – contendrá una producción con las integraciones del hospital.
Un namespace con elementos comunes – elementos reutilizables (e.g. componentes de producciones,
esquemas HL7, utilidades, etc).
Del mismo modo, cada instancia se organizará físicamente así:
•
•
Una base de datos por namespace de hospital – contendrá los mensajes de un hospital en concreto así
como el código específico para sus producciones.
Una base de datos para namespace con elementos comunes – contendrá el código y los datos (e.g.
estadísticas) que pueden ser compartidos por varios hospitales.
Pasos de instalación
Failover
•
•
•
•
•
•
•
•
•
Instalar instancia EnsA.
Crear namespaces y bases de datos.
Configurar producciones para arrancar automáticamente.
Crear mirror con Virtual IP.
Hacer backup de bases de datos.
Instalar instancia EnsB.
Unirse al mirror creado anteriormente como miembro failover.
Recuperar backup de bases de datos de EnsA en EnsB.
Copiar namespaces, mapeos y usuarios de EnsA en EnsB.
Versión 1.0
5
Alta disponibilidad en ENSEMBLE
Disaster Recovery
•
•
•
•
•
Para poder instalar el Disaster Recovery se debe tener previamente configurado el mirror del otro
CPD al que se va a conectar.
Instalar instancia EnsDR.
Unirse al mirror del otro CPD como miembro disaster recovery.
Recuperar backup de bases de datos del mirror del otro CPD.
Copiar namespaces, mapeos y usuarios del mirror del otro CPD en EnsDR.
Pruebas
Pruebas de balanceo entre nodos failover
•
•
•
•
Parar la instancia que tenga el rol primario en el failover.
Comprobar que la otra instancia pasa a ser primaria.
Comprobar que el servicio se sigue ofreciendo a través de la Virtual IP que se había configurado en
el mirror.
Comprobar que las producciones se han iniciado automáticamente y comienzan a pasar mensajes.
Promoción del Disaster Recovery a miembro failover
•
•
•
En la instancia EnsDR utilizar la rutina ^MIRROR para promocionar la instancia de disaster recovery a
miembro de failover.
Comprobar que la instancia es ahora parte del failover.
Parar la otra instancia de failover para forzar que la instancia pasa a tener el rol primario.
Versión 1.0
6