#Alta disponibilidad

++ Update: August 1, 2018

El uso de la dirección IP virtual (VIP) de InterSystems incorporada en Mirroring de la base de datos de Caché tiene ciertas limitaciones. En particular, solo puede utilizarse cuando los miembros Mirror se encuentran en la misma subred. Cuando se utilizan varios centros de datos, las subredes normalmente no se “extienden” más allá del centro de datos físico debido a la complejidad añadida de la red (puede obtener más información aquí). Por las mismas razones, la IP virtual con frecuencia no puede utilizarse cuando la base de datos se aloja en la nube.

En este artículo, crearemos una configuración de IRIS con alta disponibilidad utilizando implementaciones en Kubernetes con almacenamiento persistente distribuido en vez del "tradicional" par de mirror de IRIS. Esta implementación sería capaz de tolerar fallos relacionados con la infraestructura, por ejemplo, fallos en los nodos, en el almacenamiento y en la Zona de Disponibilidad. El enfoque descrito reduce en gran medida la complejidad de la implementación, a costa de un Tiempo Objetivo de Recuperación (RTO, Recovery Time Objective) ligeramente mayor.

Una necesidad habitual en nuestros clientes es la configuración tanto de HealthShare HealthConnect como de IRIS en modo de alta disponibilidad.

Es común en otros motores de integración del mercado que se promocionen con configuraciones de "alta disponibilidad", pero realmente no suele ser del todo cierto. Por lo general dichas soluciones trabajan con bases de datos externas y por lo tanto, si estas no están a su vez configuradas en alta disponibilidad, al producirse una caída de la base de datos o la pérdida de conexión a la misma toda la herramienta de integración queda inutilizable.

En el caso de las soluciones de InterSystems este problema no existe, al ser la base de datos parte y nucleo de las propias herramientas. ¿Y cómo ha solucionado InterSystems el problema de la alta disponibilidad? ¿Con abstrusas configuraciones que podrían arrastrarnos a una espiral de enajenamiento y locura? ¡NO! Desde InterSystems hemos escuchado y atendido vuestras quejas (como siempre intentamos hacer ;) ) y hemos puesto a disposición de todos nuestros usuarios y desarrolladores la función de mirroring.

Todo el código fuente del artículo está disponible en: https://github.com/antonum/ha-iris-k8s 

En el artículo anterior, comentamos cómo configurar IRIS en el clúster k8s con alta disponibilidad, basado en el almacenamiento distribuido, en vez del mirroring tradicional. Como ejemplo, ese artículo utilizaba el clúster Azure AKS. En esta ocasión, seguiremos explorando las configuraciones de alta disponibilidad en los k8s.

Para aquellos a los que, en un momento dado, necesitan probar cómo va eso del ECP para escalabilidad horizontal (cómputo y/o concurrencia de usuarios y procesos), pero les da pereza o no tienen tiempo de montar el entorno, configurar los nodos, etc..., acabo de publicar en Open Exchange la aplicación/ejemplo OPNEx-ECP Deployment .

Es posible que hayáis notado que, para configurar un mirror en InterSystems IRIS for Health™ y HealthShare® Health Connect, hay un requisito especial. En este artículo, quiero guiaros paso a paso por el proceso.

Esto supone que ya habéis configurado el segundo miembro de conmutación por error y habéis confirmado un estado exitoso de dicho miembro en el monitor del mirror:

Paso 1: Activad el usuario HS_Services (en el servidor de respaldo y en el principal).

Paso 2: Cambiad al espacio de nombres HSSYS y dirigíos a Interoperabilidad > Configurar > Credenciales.

Introducción

Entre las diversas soluciones que desarrollamos en Innovatium, un desafío habitual es la necesidad de acceder al tamaño de las bases de datos. Entonces me di cuenta de que eso no es algo tan trivial en IRIS. Ese tipo de información es importante para mantener un control del flujo de datos y del coste en gigabytes de un sistema para implementar. Sin embargo, lo que realmente me llamó la atención fue la necesidad de eso para algo muy importante: la migración a la nube. Al final, ¿quién no quiere migrar sus sistemas a la nube hoy en día? 

Todos los pods reciben una asignación de Calidad de Servicio (QoS). Existen tres niveles de prioridad dentro de un nodo:

1. Guaranteed: Alta prioridad
2. Burstable: Prioridad media
3. BestEffort: Baja prioridad

Es una forma de indicar al kubelet cuáles son vuestras prioridades en un nodo si es necesario recuperar recursos. Este fantástico GIF de Anvesh Muppeda lo explica.

Si es necesario liberar recursos, primero se expulsarán los pods con QoS BestEffort, luego los Burstable y, por último, los Guaranteed.

Hola!

Aquí les dejo un video que hice para mostrar cómo se configura la alta disponibilidad (mirroring) en IRIS en un ambiente docker, el video esta completamente en español y los archivos necesarios estarán en mi Github.

El video en YouTube en https://youtu.be/rBdiTxavWmU

https://github.com/I-am-seven/iris-mirroring-video

Espero les sea de Utilidad!

Joel

Hace ya un tiempo hice un pequeño ejemplo para poder desplegar rápidamente utilizando Docker instancias de InterSystems IRIS conectadas vía ECP. Ha pasado el tiempo y, como todo, necesitaba algo de chapa y pintura...