IKO Plus: Stretched Cross Cloud, Cross Regional IrisCluster with Tailscale

In the previous post, we stretched an InterSystems IrisCluster across Google Cloud regions. Today, we’re taking it a step further: Cross-Cloud. We are going to stretch our cluster between Google Cloud (US/UK) and Amazon Web Services (AWS).

The Multi-Cloud Objective

Why go cross-cloud?

1. Vendor Agnostic DR: True disaster recovery shouldn’t just survive a regional outage, but a provider-wide catastrophic event.
2. Regulatory Compliance: Many industries require data to be hosted by alternate vendors for business continuity.
3. Regional Locality: Using the best region regardless of the provider.

The Strategy

We’ll add a third node to our Tailnet, this time hosted in AWS (Oregon). This node will serve as our Async DR member.

Step 1: Prepare the AWS Node

First, we need to label our new AWS node so the IKO knows where to place our DR instance.

kubectl label node ip-10-129-0-182.ec2.internal topology.kubernetes.io/zone=us-aws -n ikoplus

Step 2: Update IrisCluster Topology

We need to update our IrisCluster definition to include the new Async DR member and map it to the new zone.

# Snippet of the mirrorMap and topology update
mirrorMap:
  - name: data
    members:
      - role: master
        zone: us-east1-a
      - role: slave
        zone: europe-west2-a
      - role: asyncdr
        zone: us-aws

Step 3: Deployment & Attestation

Applying the changes… Bam!

The IKO successfully provisions the Async DR member in AWS. We can verify the location of our pods across the different cloud providers.

And checking the mirror status within IRIS confirms everything is in sync across the Atlantic and the US mainland.

Lessons Learned & “Foot Guns”

Going cross-cloud introduced a few challenges that weren’t present in the single-cloud setup:

AWS Specifics

• DNS: Disabled DNS hostnames in the VPC and used host entries with Tailscale IPs.
• Time Sync: Tightened up polling for chronyd to ensure all members were on the same page.
• Networking: Used an Internet Gateway (IGW) without a NAT gateway for simplicity in this lab.

Instance Configuration

• Enabled IP forwarding for Tailscale to route traffic correctly.

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

Tailnet Configuration

Subnet advertising and route acceptance were required on all boxes, followed by approval in the Tailscale admin console.

Business Continuity Checklist

Let’s see if we met our goals:

• ✅ High Availability: Implemented via IKO Mirror.
• ✅ Disaster Recovery Distance: Our DR instance is over 2500 miles from the nearest HA member.
• ✅ Alternate Vendor: We are running on both Google Cloud and AWS.

Onward and Upward! Multi-cloud IRIS clusters are now a reality.