#InterSystems IRIS

No sé a vosotros, pero a mi me ha pasado varias veces que creo un contenedor Docker (me gusta hacerlo con un docker-compose.yml, me resulta más ordenado 😊) con una versión de IRIS, voy haciendo mis pruebas y llega un día en el que la licencia de ese contenedor ya no es válida, y no funciona...

Si os ha pasado, puede que alguno de vosotros, igual que yo, haya pensado "pues con subir la versión de IRIS en el docker-compose/Dockerfile, suficiente". Pues... no 😅 Al hacerlo, da problemas y no arranca bien el contenedor.

Hace trece años, obtuve una doble titulación de grado en ingeniería eléctrica y matemáticas, y enseguida empecé a trabajar a tiempo completo en InterSystems sin utilizar ninguna de las dos. Una de mis experiencias académicas más memorables —y que más me revolvió el estómago— fue en Estadística II. En un examen, estaba resolviendo un problema de intervalo de confianza de dificultad moderada.

A veces, los clientes necesitan una instancia pequeña de IRIS para hacer algo en la nube y luego apagarla, o necesitan cientos de contenedores (es decir, uno por usuario final o uno por interfaz) con cargas de trabajo pequeñas. Este ejercicio surgió para ver cuán pequeña podría ser una instancia de IRIS. Para este ejercicio, nos centramos en cuál es la menor cantidad de memoria que podemos configurar para una instancia de IRIS. ¿Conocéis todos los parámetros que afectan la memoria asignada por IRIS?

Estoy seguro de que la mayoría de vosotros estáis familiarizados con la utilidad %SYS.MONLBL, que es crucial cuando se analizan los cuellos de botella de rendimiento del código. Permite seleccionar un número de rutinas que queréis monitorizar en tiempo de ejecución y también especificar qué proceso(s) queréis observar. PERO, ¿qué pasa si no sabéis exactamente qué proceso ejecutará vuestro código? Esto es común en muchas aplicaciones basadas en la web (CSP/REST) hoy en día. Queréis minimizar la utilización de recursos en vuestro sistema de producción que necesita análisis.

Perfilando Documentos CCD con la Herramienta CCD Data Profiler de LEAD North
¿Alguna vez has abierto un CCD y te has encontrado con una pared de XML enredada? No estás solo. Aunque los CCD son un formato central para el intercambio de datos clínicos, son notoriamente densos, prolijos y poco amigables para la vista humana. Para los desarrolladores y analistas que intentan validar su estructura o extraer información significativa, navegar estos documentos puede sentirse más como arqueología que como ingeniería.

Pregunta:

¿Cómo podéis crear, modificar, etc., configuraciones de seguridad como Usuarios y Roles programáticamente?

Respuesta:

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.