Cómo montar un cluster de nodos IRIS en sharding en 1 minuto

Os voy a mostrar cómo podéis montaros en vuestra máquina, muy rápidamente, un cluster de nodos InterSystems IRIS en sharding. En este artículo no es mi objetivo hablar del sharding en detalle, ni definir una arquitectura de despliegue para un caso real, sino enseñaros como podéis montar de forma rápida, en vuestro equipo, un cluster de instancias de IRIS en sharding con el que poder jugar y hacer pruebas. Si estáis interesados en indagar más sobre el sharding en IRIS, podéis echar un vistazo a la documentación pinchando aquí.  

Vaya por delante que la tecnología sharding de IRIS nos va a permitir 2 cosas de inicio:

• Definir, cargar y consultar tablas fragmentadas o shards, cuyos datos serán distribuidos transparentemente entre los nodos del cluster
• Definir tablas federadas, que ofrecen una vista global y compuesta de datos pertenecientes a tablas distintas y que, fisicamente, están almacenadas en distintos nodos distribuidos.

Así que , lo dicho, dejamos para otros artículos el tema de jugar con shards o con tablas federadas, y nos centramos ahora en el paso previo, esto es, en montar el cluster de nodos en sharding.

Bien, pues para nuestro ejemplo vamos a utilizar Docker Desktop (para Windows o Mac) y nos vamos a apoyar en la funcionalidad de IRIS: CPF Merge o fusionado del fichero de configuración;  que nos permite utilizar un fichero de texto plano en el que incluiremos secciones y propiedades de configuración de IRIS que queremos aplicar para modificar la configuración actual de la instancia de IRIS. Basicamente este fichero se sobrepone al iris.cpf que define la configuración por defecto de la instancia.

Este fusionado lo "activamos" automáticamente al añadir la variable de entorno: ISC_CPF_MERGE_FILEa la que deberemos haberle asignado una ruta válida a un fichero que contenga esas secciones del fichero cpf que queremos cambiar. Cuando IRIS arranca, comprueba si se le ha indicado que haga un merge (basicamente, si existe esa variable de entorno y apunta a un fichero válido). Si es así, hace el fusionado y arranca.

No me enrollo más y os incluyo el fichero docker-compose.yml que hará la magia:

services:
  # iris container
  irisnode1:
    init: true 
    hostname: irishost1
    image: shardnode:latest 
    container_name: irisnode1
    build: 
      context: ./cluster
      dockerfile: Dockerfile
    ports:
    - "9991:1972"
    environment: 
    - ISC_DATA_DIRECTORY=/durable/irishost1
    - ISC_CPF_MERGE_FILE=/iris-shared/merge_first_data-node.cpf
    command: 
       --check-caps false --ISCAgent false --key /iris-shared/iris.key -a /iris-shared/configure_first_data-node.sh
    volumes:
    - ./cluster/iris-instance:/iris-shared:delegated
    - ./DDBBs:/durable:delegated

  irisnode2:
    init: true 
    hostname: irishost2
    image: shardnode:latest 
    container_name: irisnode2
    build: 
      context: ./cluster
      dockerfile: Dockerfile
    ports:
    - "9992:1972"
    environment: 
    - ISC_DATA_DIRECTORY=/durable/irishost2
    - ISC_CPF_MERGE_FILE=/iris-shared/merge_data-node.cpf
    command: 
       --check-caps false --ISCAgent false --key /iris-shared/iris.key -a /iris-shared/configure_data-node.sh
    volumes:
    - ./cluster/iris-instance:/iris-shared
    - ./DDBBs:/durable
    depends_on:
      irisnode1:
        condition: service_healthy
    
  # web gateway container
  webgateway:
    image: containers.intersystems.com/intersystems/webgateway:latest-em
    init: true
    container_name: webgateway
    hostname: webgateway
    ports:
    - 7772:80
    - 7773:443
    environment:
    - ISC_CSP_CONF_FILE=/webgateway-shared/CSP.conf
    - ISC_CSP_INI_FILE=/webgateway-shared/CSP.ini
    volumes:
    - ./webgateway/CSP.conf:/webgateway-shared/CSP.conf
    - ./webgateway/CSP.ini:/webgateway-shared/CSP.ini

En este caso, estamos creando 3 servicios:

• irisnode1 - Primer nodo del cluster, que tiene un rol especial, y de ahí que le denominemos específicamente como node1
• irisnode2 - Nodo de datos adicional del cluster, cuyo rol es data (de estos podemos tener tantos como queramos)
• webgateway - Servidor Web preconfigurado para acceder a las instancias de IRIS (Apache + Webgateway)

Para crear la imagen shardnode:latest, hemos utilizado el siguiente dockerfile:

FROM containers.intersystems.com/intersystems/irishealth:2024.3
#FROM containers.intersystems.com/intersystems/iris-community:latest-em
#FROM containers.intersystems.com/intersystems/irishealth-arm64:2024.3
USER root
WORKDIR /opt/irisapp
RUN chown -R irisowner:irisowner /opt/irisapp
USER irisowner
WORKDIR /opt/irisapp
COPY --chown=irisowner:irisowner src src
COPY --chown=irisowner:irisowner iris.script iris.script
RUN iris start IRIS \
    && iris session IRIS < iris.script \
    && iris stop IRIS quietly

Los ficheros utilizados para hacer el merge para el nodo1 y los nodos de data del cluster de IRIS son:

# Primer nodo del cluster
# 2 GB 8k / 204 MB gmpheap / 64 nodos max
[config]
globals=0,0,2048,0,0,0
gmheap=204800
MaxServerConn=64
MaxServers=64
# Define el primer nodo del sharding cluster. Crea un endpoint REST de prueba
[Actions]
ConfigShardedCluster:ClusterURL=IRIS://irishost1:1972/IRISCLUSTER,Role=node1
CreateApplication:Name=/rest/testapp,MatchRoles=:%ALL,NameSpace=USER,DispatchClass=Test.RESTserver,AutheEnabled=64

# Nodo de dato adicional
# 2 GB 8k / 204 MB gmpheap / 64 nodos max
[config]
globals=0,0,2048,0,0,0
gmheap=204800
MaxServerConn=64
MaxServers=64
# Define un nodo de datos y lo añade al cluster. Crea un endpoint REST de prueba(opcional)
[Actions]
ConfigShardedCluster:ClusterURL=IRIS://irishost1:1972/IRISCLUSTER,Role=data
# CreateApplication:Name=/rest/testapp,MatchRoles=:%ALL,NameSpace=USER,DispatchClass=Test.RESTserver,AutheEnabled=64

Podríamos tener más nodos de tipo data en el cluster con tan sólo añadir más servicios con la misma definición que el irisnode2 (cambiando el nombre claro)

Por otro lado, para que nos funcione correctamente el direccionamiento en nuestro servidor web, y podamos acceder a los Portales de Administración de cada una de las instancias, hemos de cambiar en cada una de ellas el parámetro CSPConfigName, y eso lo hacemos con los ficheros: configure_first_data-node.sh y configure_data-node.sh; que en este ejemplo son iguales, pero que he dejado diferentes porque, en un momento dado, podríamos querer hacer acciones distintas en el arranque de cada instancia de IRIS, según se trade del nodo1 o un nodo de tipo data del cluster.

cat << EOF | iris session iris
do ##class(%SYSTEM.CSP).SetConfig("CSPConfigName","$HOSTNAME")
halt
EOF

Y básicamente ya estaría.

Se podrían definir los nodos utilizando la API disponible en la clase %SYSTEM.Cluster, pero la verdad es que la posibilidad de introducir acciones conjuntamente con la funcionalidad de CPF Merge nos simplifica la tarea muchísimo. Os recomiendo que miréis aquí, en concreto en el apartado que se refiere a la sección [Actions].

Para construir las imágenes y desplegar el cluster, podríamos construir nuestra imagen sharnode:latest y lanzar el docker-compose desde VS Code o, desde nuestra shell, desde el directorio en que se encuentre el fichero, docker-compose.yml, podríamos ejecutar estos comandos:

docker compose build
docker compose up

Tardará un poco la primera vez porque ha de instanciarse la instancia marcada como node1 antes de que se inicien por primera vez cualesquiera otros nodos de tipo data del cluster. Pero todo debería estar funcionando y listo en un minuto o menos.

Si todo ha ido bien, deberías poder entrar a los portales de gestión de cada una de las instancias:

Y, ¡listo! A partir de aquí, el límite en cuanto a volumen de almacenamiento de BBDD y tamaño de tablas, ya lo pone vuestro hardware.Tendrías un cluster de nodos de IRIS listo para definir tablas en sharding o tablas federadas.

¡¡Espero que os sirva!! Nos vemos por aquí...