Microsoft Azure es un servicio de acceso y almacenamiento de datos en la nube, creado por Microsoft, para crear, probar, implementar y administrar aplicaciones y servicios a través de sus centros de datos.
¡Hola!
En mi último artículo, hice una guía paso a paso sobre cómo podéis probar a desplegar InterSystems IRIS Community Edition, o IRIS for Health Community Edition, gratis en AWS. En este seguimiento, os mostraré lo mismo para el siguiente mayor proveedor de nube, Microsoft Azure.
Al igual que con AWS, Azure también ofrece una opción gratuita al registraros, aunque es un poco menos generosa: recibís 200 $ de crédito gratis para gastar en el primer mes.
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:
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.
No estoy seguro de que haya muchos que se conecten a MS SQL para ejecutar consultas, procedimientos almacenados, etc., pero nuestro sistema de salud tiene muchas bases de datos diferentes basadas en MS SQL que usamos en el entorno de interoperabilidad por diversas razones.
Con el impulso de movernos de on-premises a la nube, nos encontramos con algunas dificultades con nuestras conexiones SQL Gateway y cómo configurarlas para usar Microsoft Entra para la autenticación de Active Directory.
Hay muchos artículos en la web, pero ninguno nos dio la respuesta completa sobre lo que necesitábamos
Acceder a un almacenamiento en la nube de Azure para cargar/descargar blobs es bastante fácil usando los métodos API designados de la clase %Net.Cloud.Storage.Client, o usando los adaptadores de entrada/salida EnsLib.CloudStorage.*
Tened en cuenta que necesitaréis tener el Servidor de Lenguaje Externo %JavaServer en funcionamiento para usar tanto la API de almacenamiento en la nube como los adaptadores, ya que ambos usan el marco PEX usando el Servidor Java.
.png)
He aquí un breve resumen:
El acceso a Azure Blob Storage se realiza mediante una cadena de conexión similar a esta:
DefaultEndpointsProtocol=Empezamos a usar Azure Service Bus (ASB) como solución de mensajería empresarial hace tres años. La hemos usado para publicar y consumir datos entre muchas aplicaciones de la organización. Como el flujo de datos es complejo, y normalmente se necesitan los datos de una aplicación en muchas otras aplicaciones, el modelo publicador -> múltiples subscriptores resultó muy adecuado. El uso de ASB en la organización es de docenas de millones de mensajes por día, mientras que la plataforma IRIS tiene unos 2-3 millones de mensajes/día.
Cuando empezamos con la integración de ASB, encontramos que el protocolo AMQP no tiene la configuración predeterminada para la implementación de IRIS, por lo que estuvimos buscando una solución alternativa para poder comunicar con ASB.
Al igual que los servidores hardware, los servidores virtuales en nubes públicas y privadas pueden generar cuellos de botella en los recursos, según aumentan las cargas de trabajo. Si utilizas y administras instancias de InterSystems IRIS implementadas en nubes públicas o privadas, es posible que te hayas encontrado la situación en la que para solucionar problemas de rendimiento o de otro tipo se requiere aumentar la capacidad del servidor de una instancia (es decir, escalar verticalmente).
Un motivo frecuente es la memoria insuficiente. Como se describe en la Administración de la memoria y
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.
Los sistemas de bases de datos tienen requisitos muy específicos para las copias de seguridad ("backups") que, en entornos empresariales, necesitan una previsión y planificación. En el caso de los sistemas de bases de datos, el objetivo de una copia de seguridad es crear una copia de los datos en un estado equivalente a cuando la aplicación se apaga de forma correcta. Las copias de seguridad consistentes con las aplicaciones cumplen estos requisitos, y Caché ofrece un conjunto de APIs que facilitan la integración con soluciones externas para lograr este nivel de consistencia en las copias de seguridad.