Mirroring es una tecnología de InterSystems para soluciones de alta disponibilidad, recuperación de desastres y respaldo de bases de datos y OLAP solutions.
Por una variedad de razones, los usuarios pueden desear montar un volumen persistente en dos o más pods que abarquen varias zonas de disponibilidad. Un caso de uso de este tipo es poner a disposición de ambos miembros del espejo los datos almacenados fuera de IRIS en caso de una conmutación por error.
Desafortunadamente, las clases de almacenamiento integradas en la mayoría de las implementaciones de Kubernetes (ya sea en la nube o en las instalaciones) no ofrecen esta capacidad:
InterSystems se complace en anunciar la disponibilidad general (GA) de la versión 2025.2 de la plataforma de datos InterSystems IRIS®. Esta es una versión de Entrega Continua (CD). Tened en cuenta que las versiones GA de InterSystems IRIS for Health™ y HealthShare® Health Connect™ 2025.2 se han retenido temporalmente debido a limitaciones en la replicación introducidas por actualizaciones de seguridad (más detalles a continuación).
Si estás ejecutando IRIS en una configuración en mirror para alta disponibilidad (HA) en Azure, la cuestión de proporcionar una Mirror VIP (Virtual IP) es relevante. La Virtual IP ofrece una forma para que los sistemas interactuen con IRIS utilizando una dirección IP. Incluso cuando ocurre un failover, los otros sistemas pueden reconectarse a la misma dirección IP y continuar trabajando.
El problema principal, cuando se despliega en Azure, es que una IRIS VIP tiene el requerimiento de que IRIS sea esencialmente un admin de red, según se indica en la documentación.
Para tener HA, los miembros en mirror de IRIS deben ser desplegados en diferentes zonas de disponibilidad (availability zones o AZ) en una subred (lo que es posible en Azure ya que las subredes pueden abarcar varias zonas). Una de las soluciones puede ser utilizar balanceadores de carga pero, por supuesto, suponen un coste extra, y también necesitarás administrarlos.
En este artículo, quiero proporcionar un modo de configurar una Mirror VIP sin la utilización de balanceadores de carga que se sugiere en la mayoría de las propouestas de arquitectruas de referencia para Azure.
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)..png)
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.
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
Antecedentes
| Versión | Fecha | Cambios |
|---|---|---|
| V1 | 08/02/2022 | Lanzamiento Inicial |
| V1.1 | 06/04/2022 | Generación de certificados con un archivo sh en vez de un pki-script Uso de variables de entorno en los archivos de configuración |
¡Hola Comunidad!
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.
Hasta hace no mucho, todos los entornos con los que trabajábamos eran Ensemble 2017.2. Pero recientemente hemos migrado todos los entornos a la versión 2021.1 de IRIS for Health. Ha sido un camino complicado, pero tras analizarlo detenidamente, encontramos la forma de conseguirlo.
Esta publicación es la traducción de un artículo que publicó mi compañero Murray hace un tiempo. Durante mi trabajo en soporte la he recomendado muchas veces, pues lo que aquí se explica es bastante común y los ejemplos que se dan pueden ayudar a muchos de vosotros.
¡Hola desarrolladores!
Os traemos el quinto episodio de Data Points, el podcast de InterSystems en inglés. En esta ocasión, charlamos con Bob Binstock sobre bases de datos en mirroring para alta disponibilidad en productos InterSystems. La mayor parte de la conversación comenta este proceso en InterSystems IRIS, con alguna mención sobre las diferencias con HealthShare. ¡Dadle al play!
++ 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.
Si quieres probar mirroring de una manera simple y sencilla puedes hacerlo con estos simples scripts (ver link)