IPアドレスを変更せずにEC2からNC2への移行とAWSの2つのリージョン間でのDRフェイルオーバーを実現

一部のお客様は、AWSでリージョンをまたいだディザスタリカバリ(DR)を必要としていますが、別のリージョンにフェイルオーバーする際にIPアドレスが変更されるという課題に直面することがよくあります。この変更により、DRポリシーで保護されているインスタンス上で実行されているサービスへの外部アクセスが中断される可能性があります。

Nutanix Cloud Clusters (NC2) は、この課題に対応するためのDR機能をビルトインしており、リージョン間でフェイルオーバーする際にもIPアドレスを一貫して維持することができます。さらに、NC2ではCPUのオーバープロビジョニングが可能であるため、NC2への移行後にコンピュートコストを削減できる可能性もあります。ただし、DR中にIPアドレスを保持できるのは、すでにNutanixクラスター上に存在しているワークロードのみであるため、EC2インスタンスは先に移行しておく必要があります。

無料の移行ツールであるNutanix Moveを使用すれば、Amazon EC2からNutanix Cloud Clustersにワークロードを移行することができます。ただし、現時点ではIP保持をサポートしていません。このブログでは、移行中に一貫したIPアドレスを維持するための工夫を紹介しますが、MACアドレスが変更されることには注意してください。その後、NC2はNutanix DRソリューションの一部としてリージョン間フェイルオーバー中にIPアドレスを保持します。それでは始めましょう!

ソリューションアーキテクチャ

この例では、オンプレミスのデータセンター(DC)、DRポリシーでカバーするAWS VPC(別のリージョンにフェイルオーバーしてもIPアドレスが変更されないようにする)にあるEC2インスタンス、そして2つのNC2クラスター(東京リージョンと大阪リージョン)を使用します。この例では、AWSの東京リージョン(ap-northeast-1)をプライマリリージョン、大阪リージョン(ap-northeast-3)をディザスタリカバリの場所として使用します。

オンプレミス環境との接続をDirect Connectで示していますが、このソリューションのテストはすべて各リージョンのTGWに接続されたS2S VPNで行われています。DR間の接続は、クロスリージョンVPCピアリングまたは2つのTransit Gateway (TGW) のピアリングを使用して行うことができます。

ネットワーキング

移行されたEC2インスタンスのIPアドレスを保持するために、Flow Virtual Networking (FVN) を使用して、NC2上にオーバーレイのNATなしオーバーレイネットワークを作成します。このネットワークのCIDR範囲は、EC2インスタンスが接続されている元のサブネットの範囲と一致させます。このオーバーレイネットワークは、東京および大阪のNC2クラスターの両方に作成されます。これにより、VMがフェイルオーバーされても同じCIDR範囲を持つネットワークに接続できます。

オンプレミスDCがこれらのVMにアクセスできるようにするために、プロセス全体でルートテーブルを変更します。これにより、移行されたEC2インスタンスの場所に関係なく、それらを指すルートを維持できます。

Terraform / Open Tofu を使用したVPCとTGWの自動作成

このソリューションを試してみたい場合、VPCやTGW、ルーティングをデプロイするためのTerraform / Open Tofuテンプレートを以下で入手できます:

https://github.com/jonas-werner/aws-dual-region-peered-tgw-with-vpcs-for-nc2-dr

リージョン間接続のためのピアリングタイプの選択

一般的に、以下のように考えられます:

  • VPCピアリング: データ転送コストがやや高いものの、直接的な接続のシンプルさが求められる低トラフィックのシナリオに最適です。
  • TGWピアリング: 高トラフィック環境や複雑なアーキテクチャに適しています。集中管理や低いデータ転送料金が、TGWアタッチメントの追加コストを上回ります。なお、トラフィックは2つのTGWを通過しますが、ピアリングインターフェイスではデータ転送料金は発生しないため、データは1回だけ課金されます(東京リージョンではおおよそ0.02セント/GiB)。

IP保持のための回避策

冒頭で述べたように、Nutanix Move仮想アプライアンスはEC2からNC2への移行に非常に優れていますが、現時点では移行されたワークロードのIPアドレスを保持する機能はありません。この課題を回避するために、以下の手順を実施します:

  1. 移行前
    AWS Systems Manager (SSM) を使用して、移行対象のインスタンス上でPowerShellまたはBashスクリプトを実行します。このスクリプトは、EC2インスタンスのID、ホスト名、およびローカルIPアドレスを取得し、その情報をDynamoDBテーブルに保存します。
  2. 移行中
    Nutanix Moveを使用して、EC2からNC2にインスタンスを移行します。この間にIPアドレスは変更されますが、移行先はEC2インスタンスが接続されていた元のネットワークのCIDR範囲と一致するFVNオーバーレイネットワークです。
  3. 移行後
    DynamoDBに保存した情報をテンプレートとして使用するPythonスクリプトを実行します。このスクリプトは、Nutanix Prism Central APIに接続し、既存のネットワークインターフェイスを削除し、正しい(元の)IPアドレスを持つ新しいインターフェイスを各インスタンスに追加します。

これらの手順を経て、インスタンスがNC2に移行された後は、東京と大阪のリージョン間でのDR設定が簡単に行えるようになります。

このブログに使われているスクリプトは以下の GitHubページからダウンロードできます:

https://github.com/jonas-werner/EC2-to-NC2-with-IP-preservation/tree/main

ステップ1: EC2インスタンスのIPアドレスを取得

このステップでは、EC2からNC2への移行の準備を行います。ネットワーク、ワークロード、および172.30.1.0/24ネットワークへのルートの初期状態は、以下の図の赤い線で示されています。

最初に、EC2インスタンスに関する情報を収集し、その情報をDynamoDBに保存します。効率を重視して、SSM Run Commandを使用してPowerShellスクリプトを実行します。これにより、WindowsおよびLinuxワークロードの両方を1回または2回の操作で簡単に処理できます。この例では、単一のWindows Server 2019 EC2インスタンスをテスト対象として使用します。

まず、この情報を保持するためのDynamoDBテーブルを作成します。このテーブルには特別な要件はなく、SSMがスクリプトを実行する際にアクセスできれば十分です。もちろん、SSMコマンドを実行する際に使用するIAMロールにDynamoDBへのアクセス権を付与する必要があります。そのため、以下のような権限を標準のSSMロールに追加します:

{
    "Sid": "AllowDynamoDBAccess",
    "Effect": "Allow",
    "Action": [
        "dynamodb:PutItem"
    ],
    "Resource": "arn:aws:dynamodb:<your-aws-region>:<your-aws-account>:table/<dynamodb-table-name>"
},

インスタンス名をメタデータから収集するために、EC2コンソールで「インスタンスメタデータにタグを許可」設定を有効化します。この設定は、移行後にNC2でインスタンスを検索する際に「Name」タグをキーとして使用するために重要です。他の方法(たとえばインスタンス名自体を使用する)も可能ですが、このケースではEC2の「Name」タグを使用します。これは、移行後も同じタグがNC2に表示されるためです。

SSM Run Commandを使用して、インスタンス上でスクリプトを実行します。以下のコマンド例を参照してください:

スクリプトの実行後、Windows EC2インスタンスのエントリがDynamoDBに表示されます。これには、インスタンスID、ホスト名、およびIPアドレス(例: 172.30.1.34)が含まれます。このIPアドレスは保持したいアドレスです。

次に、EC2 から NC2 への移行を実行します。

ステップ2: EC2からNC2への移行

次に、EC2からNC2への移行を実施します。この移行では、Nutanix MoveをNC2クラスター上に展開済みである必要があります。また、FVNオーバーレイネットワークを作成しており、そのCIDRはEC2インスタンスが接続されていた元のサブネットと一致していますが、DHCPの範囲は現在そのサブネットで使用されているIPアドレスを避けるよう設定されています。

Moveには、NC2クラスターとAWS環境が移行元および移行先として設定されています。

「Missing Permissions」という警告が表示される場合がありますが、これはAWS IAMポリシーで、EC2への移行を許可していないためです。しかし、EC2からの移行のみを行う場合、この警告は無視して構いません。必要なIAMポリシーの詳細は、Moveのマニュアルをご確認ください。

移行後、VMは異なるIPアドレスを持つようになります(移行先のFVNサブネットのDHCP範囲から取得されます)。

次のステップで、Pythonスクリプトを使用して元のIPアドレスに戻す処理を行います。

ステップ3: EC2インスタンスが元々持っていたIPアドレスに戻す

次に、Pythonスクリプトを実行して、DynamoDBに保存されたインスタンス名を参照し、それをNC2のVM名と照合します。その後、Prism Central APIを使用して既存のネットワークインターフェイスを削除し、新しいネットワークインターフェイスを追加します。この新しいインターフェイスには、元の静的IPアドレスが設定されます。

このスクリプトはGitHubからダウンロードできます。スクリプトを実行するには、Prism Centralのユーザー名とパスワードを環境変数としてエクスポートしてください。また、Prism CentralのIPアドレス、使用するサブネット名、AWSリージョン、DynamoDBテーブル名をお使いの環境に合わせて更新してください。

スクリプトを実行すると、VMが元のIPアドレスを取得したことを確認できます。ただし、このプロセスではNICが置き換えられるため、IPアドレスは同じですが、MACアドレスは変更されています。

EC2からNC2への移行後の東京リージョンでのルーティング

VMがNC2上に存在するようになったため、トラフィックが元のEC2インスタンスではなく、このVMに向かうようルーティングを更新する必要があります。これは、EC2 VPCをTGWから切断し、NC2 VPCを指すようにTGWに静的ルートを追加することで実現します。このサブネットはすでにDXGWの「許可されたプレフィックス」として存在するはずなので、この部分は変更する必要はありません。

赤で強調されたアタッチメントは、172.30.1.0/24サブネットへのアクティブルートを示しており、現在はNC2 VPCを指すように変更されています。このサブネットはFVNのNo-NATサブネットであるため、NC2 VPCのルートテーブルに表示されます。

移行作業のまとめ

これでEC2インスタンスはNC2に移行されました。IPアドレスは保持されており、AWSとオンプレミスDC間のルーティングが更新されたため、オンプレミスのユーザーは、通常通り移行されたインスタンスにアクセスできます。実際、移行のメンテナンスウィンドウ、NC2でのVMの電源オン、およびルーティングの切り替えを除けば、これらのユーザーは元のEC2インスタンスが別のプラットフォームで動作するようになったことに気付くことはほとんどありません

東京と大阪のNC2クラスター間でのDR構成

ここまでで、東京リージョンのNC2クラスターにEC2インスタンスを移行し、IPアドレスを保持した状態でオンプレミス環境と通信できるようになりました。次に行うのは、東京と大阪の2つのNutanixクラスター間で災害復旧(DR)構成を設定することです。DRはNutanixの標準機能として組み込まれているため、この設定は非常に簡単です。Prism Centralインスタンスをリンクし、大阪側でもFVNオーバーレイネットワークを作成して、フェイルオーバー後も同じCIDR範囲を使用できるようにします。

災害復旧機能を有効にした後、Prism Centralを使用してDRプランを簡単に作成できます。

DRプランを作成する際、東京ネットワーク上のVMが大阪DRサイト上の対応するネットワークにフェイルオーバーするように設定します。

最後に、東京のNC2クラスターから大阪のNC2クラスターにVMをフェイルオーバーします。

フェイルオーバー後、VMが大阪で正常に起動していることを確認できるだけでなく、期待通りにIPアドレスが保持されていることも確認できます。

東京から大阪へのルーティング更新

東京から大阪へのフェイルオーバーが完了したら、172.30.1.0/24ネットワークを指すルートを更新し、大阪を指すようにTGWの設定を変更します。これにより、以下のようなネットワーク構成になります。

大阪TGWでは、172.30.0.0/16ネットワークを大阪のNC2 VPCに向けた静的ルートを作成します。

また、東京TGWの静的ルートも更新し、ローカルのNC2 VPCを指すルートを大阪へのピアリング接続に変更します。

結果とまとめ

これらのルーティング変更が適用されることで、オンプレミスのデータセンターからのユーザーは、同じIPアドレスを使用して同じVMにアクセスし続けることが可能になります。この一貫性は、EC2からNC2への移行、および東京リージョンから大阪リージョンへの災害復旧計画に基づいたフェイルオーバー後も維持されます。

このソリューションにより、AWS上で動作していたワークロードがNC2上で動作するようになり、その後もIPアドレスを変更することなく運用を継続できます。これにより、ユーザーにとっての影響を最小限に抑えつつ、DR計画を実現できます。

ぜひこのソリューションを試してみてください。また、この種のソリューションに興味がある場合は、Nutanixの担当者にお問い合わせください。お読みいただきありがとうございました!

リンク

Migrate from EC2 to NC2 and perform DR failover between two AWS regions without changing IP addresses

Some customers require cross-region disaster recovery (DR) in AWS but often face the challenge of changing IP addresses during a failover to another region. This change can disrupt external access to services running on instances covered by the DR policy.

Nutanix Cloud Clusters (NC2) address this challenge with built-in DR functionality that ensures IP addresses remain consistent during failovers between regions. Bonus: It is possible to over-provision CPU on NC2, so it may actually be possible to save on compute costs after the migration to NC2. However it can only retain IP addresses during DR for workloads which are already residing on a Nutanix cluster, so we have to migrate the EC2 instances first.

The free Nutanix Move migration tool can migrate workloads from Amazon EC2 to Nutanix Cloud Clusters, though it currently lacks support for IP retention. In this blog we use some creative workarounds to maintain consistent IPs throughout the migration, although note that MAC addresses will change. NC2 then retains the IPs during regional failovers as part of the Nutanix DR solution. Let’s dive in!

Solution architecture

In this case we have an on-premises datacenter (DC), an AWS VPC with EC2 instances which we want to have covered by a DR policy (so they can fail over to another region without changing IP addresses) and finally two NC2 clusters – one in the primary region and one in a separate region for DR purposes. We use Tokyo (ap-northeast-1) as the primary AWS region and Osaka (ap-northeast-3) as the disaster recovery location in this example.

Overview of solution architecture. Click to embiggen.

We illustrate connectivity to the on-premises environment by using Direct Connect. Note that all the testing of this solution has been done with S2S VPN attached to the TGW’s in each region. Peering between the two DR locations can be done by using cross-region VPC peering or peering of two Transit Gateways (TGW).

Networking

To retain the IP addresses of the migrated EC2 instances we use Flow Virtual Networking (FVN) to create overlay no-NAT overlay networks on NC2 with a CIDR range which matches that of the original subnet the EC2 instances are connected to. We create this overlay network in both Tokyo and Osaka NC2 clusters so that we can later fail over the VMs and have them attach to a network with the same CIDR range.

To ensure the on-premises DC is able to access the VMs we modify the route tables throughout the process. That way we maintain routes which point to the migrated EC2 instances, regardless of where they are located.

Automating the VPC and TGW creation with Terraform / Open Tofu

In the case you’d like to try this out yourself, the Terraform / Open Tofu templates for deploying the VPC’s, TGW’s and the routing for these can be found on GitHub here:

https://github.com/jonas-werner/aws-dual-region-peered-tgw-with-vpcs-for-nc2-dr

When to use which peering type for inter-region connectivity

Generally it can be said that VPC Peering is better for lower traffic scenarios or when the simplicity of direct peering is desirable, despite slightly higher data transfer costs incurred for VPC peering.

TGW Peering is more cost-efficient for high-traffic environments or complex architectures, where the centralized management and lower data transfer rates outweigh the additional costs per TGW attachment. Note that although traffic passes through two TGW’s, the peering interface doesn’t incur data transfer charges so the data is only charged once (roughly 0.02 cents / GiB in the Tokyo region).

The workaround for IP retention

As mentioned in the introduction, while the Nutanix Move virtual appliance is very capable at migrating from EC2 to NC2, it is at time of writing unable to retain the IP addresses of the workloads it migrates. To work around this we do the following:

  1. Prior to the migration we use AWS Systems Manager (SSM) to run a PowerShell or Bash script on the instances to be migrated. The script captures the EC2 instances ID, hostname and local IP address and stores that information into a DynamoDB table for use later
  2. We perform the migration from EC2 to NC2 using Nutanix Move. The IP address will change although we migrate the instance to a Flow Virtual Networking (FVN) overlay network with the same CIDR range as the original network the EC2 instances are connected to.
  3. We run a Python script which uses the DymamoDB information as a template and then connects to the Nutanix Prism Central API. It then removes the existing network interface and adds a new one with the correct (original) IP address to each of the migrated instances.

Once the instances are migrated to NC2 the process of configuring DR between Tokyo and Osaka regions is trivial.

You can download the PowerShell and Python scripts used in this blog on GitHub:

https://github.com/jonas-werner/EC2-to-NC2-with-IP-preservation/tree/main

Step 1: Capture IP addresses of the EC2 instances

In this step we prepare for the migration from EC2 to NC2. The initial state of the network, the workloads and the route to the 172.30.1.0/24 network is as illustrated by the red line in the below diagram.

To start with we gather information about the EC2 instances and store that info in DynamoDB. In the name of efficiency we use the SSM Run command to execute the PowerShell script. This makes it easy to get this done in a single go (or two “goes” if we do both Windows and Linux workloads). We test with a single Windows 2019 Server EC2 instance in this example.

First create a DynamoDB table to hold this information. Nothing special is required for this table as long as it is accessible to SSM as it runs the script. We need to give the IAM role used when running SSM commands access to DynamoDB of course, so we add the following permissions to the standard SSM role:

        {
            "Sid": "AllowDynamoDBAccess",
            "Effect": "Allow",
            "Action": [
                "dynamodb:PutItem"
            ],
            "Resource": "arn:aws:dynamodb:<your-aws-region>:<your-aws-account>:table/<dynamodb-table-name>"
        },

In order to collect the instance name from meta data we enable the “Allow tags in instance metadata” setting in the EC2 console. This is important as we will use the “Name” tag in EC2 as the Key to look up the instance in NC2 post-migration. Of course other methods could be used – most obviously the name of the instance itself. However in this case we use the EC2 name tag, as this is also how the VM will show up in NC2 post migration.

The we execute the script on our instances through the SSM Run command as follows

After execution we can see an entry for our Windows EC2 instance showing its instance ID, hostname and IP address: 172.30.1.34. This is the IP we want to retain.

That’s all for this section. Next we perform the migration from EC2 to NC2.

Step 2: Migrating from EC2 to NC2

For the migration we have deployed Nutanix Move on the NC2 cluster. We have also created an FVN overlay no-NAT network with the same CIDR as the subnet the EC2 instance is connected to, although the DHCP range is set to avoid any of the IPs currently used by instances on that subnet.

Move has the NC2 cluster and the AWS environment added in as migration sources / targets.

It complains about “missing permissions” but this is because we have only given it permission to migrate FROM EC2, not TO EC2. Since that is all we want to do, this is fine. Please refer to the Move manual for details on the AWS IAM policy required depending on your use case.

Post migration the VM will have a different IP address (taken from the DHCP range on the FVN subnet it is connected to).

We use a Python script in the next section to revert the IP address to what it was while running as an EC2 instance.

Step 3: Revert the IP address to match what the EC2 instance had originally

Now we execute a Python script which will look up the instance name in DynamoDB, match it with the VM name in NC2 and then remove and re-create the network interface using the Prism Central API. The new interface will have the original IP configured as a static address.

The script can be downloaded from GitHub here. Please export the Prism Central username and password as environment variables to run the script. Also update the Prism Central IP and the subnet name to match the one used in your environment as well as the AWS region and the DynamoDB table name.

After running the script we can now verify that the VM has received its original IP address. Note that since we have replaced the NIC in this process, the IP is the same as before, but the MAC address will have changed.

Routing after migration from EC2 to NC2 in Tokyo

Now that the VM exists on NC2 we need to update our routing to ensure that traffic is directed to this VM and not the original EC2 instance (which has now been shut down by Move after the migration).

To do this we disconnect the EC2 VPC from the TGW and add the subnet as a static route in the TGW, this time pointing to the NC2 VPC rather than the EC2 VPC. The subnet should already exist as an “Allowed prefix” on the DXGW, so that part can be left as-is.

The attachments highlighted in red shows the active route to the 172.30.1.0/24 subnet, which has now been changed to point to the NC2 VPC. Since the subnet is a FVN no-NAT subnet it will show up in the NC2 VPC route table.

Wrapping up the migration part

Now our EC2 instance has been migrated to NC2. Its IP address is intact and since we have updated the routing between AWS and the on-premises DC, the on-prem users can access the migrated instances just like they normally would. In fact, apart from the maintenance window for the migration, VM power-up on NC2 and the routing switch, they are unlikely to notice that their former EC2 instance is now running on another platform.

Configuring DR between the Tokyo and Osaka NC2 clusters

At this point all we have left to do is set up the DR configuration between the two Nutanix clusters in Tokyo and Osaka. Since DR is a built-in component, this is very straight forward. We link the two Prism Central instances and of course create the FVN overlay network on the Osaka side as well to ensure we can keep the same CIDR range also after failover.

After enabling Disaster Recovery we can easily create the DR plan through Prism Central

When we create the DR plan we set the VMs on the Tokyo network to fail over to its equivalent on the Osaka DR site

Finally we proceed to fail over our VM from NC2 in Tokyo to NC2 in Osaka

After failing over we can confirm that the VM is not only powered up in Osaka, but that it has also retained the IP address, as expected.

Updating the routing to point to Osaka rather than Tokyo

After failing over from Tokyo to Osaka we need to also update the routes pointing to the 172.30.1.0/24 network by modifying the TGW in Osaka. From a diagram perspective it will look like follows.

On the Osaka TGW we create a static route to the 172.30.0.0/16 network pointing to the Osaka NC2 VPC

We also update the static route on the Tokyo TGW which points to the local NC2 VPC and instead set it to point to the peering connection to Osaka

Results and wrap-up

With these routing changes implemented it is now possible for users on the on-premises DC to continue to access the very same VMs with the very same IP addresses. This possible is even after those workloads have been migrated from EC2 to NC2 in Tokyo and then further having been failed over with a DR plan from Tokyo region to Osaka region.

Hope that was helpful! Please reach out to your local Nutanix representative for discussions if this type of solution is of interest. Thank you for reading!

Links

Using ChatGPT as a translation service

This is a quick note to show a concept of using the ChatGPT API for translation. In this case for English to Japanese, but it could be changed into any language. Since we want to talk to it we use Amazon Transcribe to turn speech into text. That text is sent to ChatGPT for translation. When the translated text comes back we feed it into Amazon Polly to turn it into speech again.

This is all running on a Raspberry Pi 3b+

Source code

Source code can be found on GitHub:

https://github.com/jonas-werner/chatBot

Quick demo video

Snakeinator case and final touches

The environmental control system for Mr. Snuggles the ball python is now nearly finished. Throughout the last couple of weeks I’ve worked on learning Fusion 360 in order to create a new case. The previous one was done with Tinkercad and the one before that in FreeCAD. The first iteration was a Tupperware case, lol

Work in progress while designing the case

The electronics didn’t end up as clean as I was hoping it would be but it works and that’s always been rule number one for this project. There will likely be a version after this and for that it would be great to etch a proper circuit board rather than using universal PCB boards as I have done up to now.

An old Wii U gave up its case fan for this project. It’s very quiet and perfect for case cooling

Currently I’m tuning the settings to dial in the right temperatures and humidity in the different parts of the enclosure. Grafana is a lifesaver as always 🙂

Work in progress on dialing in correct temperatures and humidity

The next step may be to add a humidifier of some sort and hook it up to the humidity values. The biggest challenge in controlling the environment has been the humidity. This seems to be a common gripe among those who use glass terrariums and I can certainly see why. Right now a couple of towels on top of the mesh screen in the lid help keep things under control but it’s not an ideal solution as it also limits air flow.

Mr. Snuggles loves his tubes

Re-written Python code for snake environment control system

As part of revising the entire environmental control system for the ball python “Mr. Snuggles” I’ve re-done the code for getting sensor telemetry and control of relays for heat mats and the heat lamp from scratch.

Last weekend I finished the updated wiring diagram and soldering. This weekend was the coding update, which will still require some work until it’s done. However, the main modules for DS18b20 sensor telemetry, DHT22 humidity and temperature as well as the actual relay control are done. These files can now be accessed from GitHub as per the below

Next step is to integrate Grafana with buttons for controlling the temperature. This previously required re-building the docker images and was rather inconvenient. Soon it will be as simple as tapping a touch panel. That part will require creating an API which Grafana can interact with and will likely be done next weekend if time allows.