Article
· Aug 4, 2021 3m read

IRIS Mirror in the cloud (AWS)

I have been working on redesigning a Health Connect production which runs on a mirrored instance of Healthshare 2019. We were told to take advantage of containers. We got to work on IRIS 2020.1 and split the database part from the Interoperability part. We had the IRIS mirror running on EC2 instances and used containers to run IRIS interoperability application. Eventually we decided to run the data tier in containers as well. Later we switched from using EC2 instances to Fargate “server-less” compute. A challenge was that each time AWS Elastic Container Service started a new container, it assigned it a new IP address. IRIS mirror does not like changing IP addresses. 

 

When I began to set up IRIS mirror in the cloud I found iris-mirror-with-docker application on Open Exchange: https://openexchange.intersystems.com/package/iris-mirror-with-docker

 

 

I prepare two persistent volumes – in my case on Elastic File System – for my two dataserver containers to use. I encountered permission errors, when I tried to create new directories on Elastic File System for container volumes unless the container runs as root. I want to look at file permissions so that I can avoid having containers run as root.

 

 

InterSystems told me I did not need to use a load balancer for my data tier. It would cost more for a load balancer. Mirrored database traffic is automatically routed to the primary.

 

When I start two containers, I use a startup script to choose which volume to use for each container. In this process I write two files to EFS which shows the container’s ip address for each volume. In IRIS I use ZSTU routine to read these files and update Mirror member ip addresses to enable communication between mirror members.

 

I like to organize my volumes as follows. I refer to the top-level directory as “voldata”. I create two subdirectories inside “voldata”, “iconfig” and “irisdb”. “iconfig” is the ISC_DATA_DIRECTORY, which contains the “mgr” folder. “irisdb” contains a subfolder for each database that contains IRIS.DAT.

 

For IRISMIRROR I created two volumes, “failover1” and “failover2”. Inside “failover1” and “failover2” I have “voldata” with subfolders described above.

 

For my data server image I have database to be mirrored defined as /voldata/irisdb/DATANAME. When a container starts and it claimed “failover1” or “failover2” volume, I need to update the database using CPF_MERGE.

 

I created a copy of iris-mirror-with-docker and cloned the repo:

 

Git clone https://github.com/oliverwilms/iris-mirror.git

 

I tried docker-compose up -d

 

I got an error trying to pull arbiter image. I updated the images references. I also did chmod 755 session.sh and init_mirror.sh as well as chmod 644 Installer.cls.

 

Still getting more errors. Going to try something different next …

I loaded ZSTU.mac, ZMIRROR.int and ZMIRRORHLPR.int, and I still got the same error. I realized that I got errors because I did not have license key file in the right place where it was declared in docker-compose file. Mirroring does not work without a proper license. After I copied my license key, it works better. More updates to come ...

 

My next project is to mirror my Message Bank.

 

To be continued ...

In your opinion, does it make sense to mirror the Message Bank database?
Discussion (14)2
Log in or sign up to continue

Thanks Oliver - Could you speak to the workload of your Health Connect production? i.e., is it for traditional HL7-based integration between EMRs/clinical apps/etc for a healthcare org?

And if so, what are your thoughts/experiences with the egress/ingress traffic costs? Does most of your traffic exist in the same cloud to mitigate that or are you living in the hybrid cloud world where a lot of traffic is still going to an onprem data center?

Appreciate your thoughts (and anyone else's) on this as we've been exploring it as well.

Appreciate the info - we do supply chain stuff as well for our org so I can relate to the message sizes there tend to be a lot smaller and infrequent than say an ADT and/or base64 PDF ORU result feed.

It's certainly not that cloud can't scale to support it - definitely can - but if our clinical document imaging is on-prem and we're bouncing those PDF ORUs between on-prem and cloud, bandwidth usage/cost becomes a significant factor especially given that's just a couple integrations and we have around 400.

It'll be interesting to see how much this factors in long term to cloud plans.

I encountered another challenge this week. I utilized AWS Elastic Container Service (ECS) to deploy two Fargate tasks running IRIS MessageBank Mirror. The first task started on ip-10-xxx-xxx-146. It used failover1 volume which had previously been used by ip-10-xxx-xxx-168. The second task started on ip-10-xxx-xxx-168. The second task ran on failover2 volume. It started MessageBank production and it became Primary. Mirror Service did not start on the first task. In messages.log I saw:

 

Mirroring not started, this instance appears to have been copied. See ^MIRROR

 

I suspect this happened because the randomly assigned IP address for the second task matched the prior IP address of the first task. I opened a support ticket with InterSystems WRC on Tuesday morning and I still wait for their response.

I need to correct my last response. I did receive WRC response on Friday with this:

After discussing this issue with co-workers:

The message is due to the reassignment of the IP address:

  Yes – the basically the IP address changing underneath the mirror node “changed it’s identity”. This is expected behavior for mirroring.

Possible to setup virtual IP address/or DNS name for each member then in script assign new IP to the member's DNS name

Also not to use ECS but something long these lines found in this link, look it over and see if it applies:

https://medium.com/galvanize/static-ip-applications-on-aws-ecs-c7d411421d4f