NC2 on AWS Pilot Lightクラスタ + Amazon S3を用いた災害復旧

オンプレミスからNutanix Cloud Clusters (NC2) on AWSへの災害復旧 (Disaster Recovery, DR) の設定は簡単で、事業継続性を確保する責任を負う方々に大きなメリットを提供します。Pilot Lightクラスタを利用することで、リカバリー時間目標 (RTO) が異なる2つのレベルのワークロードに対応しつつ、通常運用時のNC2クラスタサイズを最小化することでコストを削減できます。このDR設定は、Nutanix MST(Multicloud Snapshot Technology)を活用しています。

Pilot Lightクラスタを使用する理由

災害発生時にはすべてのワークロードが重要で回復が必要ですが、それぞれが異なる回復時間要件を持つ場合があります。短い回復時間を必要とするアプリケーションやサービスについては、Nutanixの組み込みDRツールを使用してオンプレミスから小規模なNC2 on AWSクラスタへのレプリケーションを設定してください。

一方、少し長めのRTOで問題ないワークロードの場合、Amazon S3にレプリケートすることで運用コストを削減できます。災害時には、これらのワークロードをS3からNC2 on AWSクラスタにリカバリーします。この方法は、通常運用時に小規模かつコスト効率の高いNC2 on AWSクラスタを維持し、S3からワークロードを回復する必要がある場合にクラスタをスケールアウトする柔軟性を提供します。

ゼロコンピュートオプション

さらに、NC2 on AWSを使用したゼロコンピュートDR戦略を構成することも可能です。この場合、NC2クラスタは存在せず、オンプレミス環境がAmazon S3にデータを直接レプリケートします。ただし、このトピックは別のブログ投稿で取り上げます。

ゼロコンピュートDRは、Pilot Lightよりも運用コストをさらに削減できます。NC2クラスタを展開する必要がないためです。しかし、災害発生時にNC2インフラストラクチャをプロビジョニングする必要があるため、RTOは長くなります。したがって、ゼロコンピュートは運用コストの観点では安価ですが、災害時の復旧クラスタの展開と構成に時間がかかるため、事業への影響コストが高くなる可能性があります。

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

以下の図は、Amazon S3とNC2 on AWSクラスタの両方にレプリケートできる方法を示しています。それぞれ異なるRPO時間を持っています。

展開手順

Pilot Lightクラスタの構成は数時間で完了できます。本ブログ投稿では、以下のステップを通じて設定を進めました:

ステップ1: NC2 on AWSクラスタを展開し、DRを有効化

NC2ポータルで数回クリックするだけで、このプロセスを実行できます。既存のAWS VPCに展開するか、クラスタ展開中に新しいリソースを作成することが可能です。オンプレミスとの接続性がある既存のVPCを使用する場合、ルーティングがすでに構成されているため、セットアップがさらに迅速に進みます。

Prism Centralの設定メニューに移動し、以下のようにDisaster Recoveryを有効化してください:

ステップ2: オンプレミスとAWS間の接続性を追加(未設定の場合)

Direct ConnectまたはS2S VPNを構成し、オンプレミスのNutanixクラスタ環境とNC2 on AWSを保持するAWS VPCをリンクします。

ステップ3: レプリケートデータを保存するS3バケットを作成

NC2 on AWS環境からアクセス可能なS3バケットを作成します。「nutanix-clusters」で始まる名前を付けることを推奨します。他のバケットと区別するために追加の名前を加えてください。この例では「nutanix-clusters-pilotlight-jwr」という名前を使用します。

作成されていない場合、このバケットへのフルアクセス権限を持つユーザーを作成し、アクセスキーとシークレットアクセスキーを記録してください。以下は、バケットへのフルアクセス権限を付与するポリシーの例です:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "FullAccessForMstToSpecificS3Bucket",
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::nutanix-clusters-pilotlight-jwr",
                "arn:aws:s3:::nutanix-clusters-pilotlight-jwr/*"
            ]
        }
    ]
}

ステップ4: NC2 on AWSのPrism CentralでMSTを構成

MSTは複数の仮想マシンをデプロイします。このデプロイには、AWSネイティブVPCのCIDR範囲内で3つのIPアドレスを指定する必要があります。

NC2がAWSネイティブネットワーキングで展開された場合、既存ネットワークのDHCP範囲外のIPアドレスを指定するか、Prism Centralコンソールを使用して新しいAWSネイティブサブネットを追加します。

Flow Virtual Networking (FVN) を使用して展開された場合、「PC-Net」のDHCP範囲を縮小してMST用のスペースを確保するのが最も簡単です。ここでは、最後のIPアドレスを”10.110.33.253”から”10.110.33.200”に変更しています。確保するIPアドレスを使用している仮想マシンが存在しないことを確認してください。

Prism Centralで「nutanix」ユーザーを使用してSSHまたはコンソールウィンドウを開き、以下のコマンドを入力してデプロイを開始します:

clustermgmt-cli mst deploy \
-b <BUCKET NAME> \
-r <AWS REGION> \
-i <IP#1>,1<IP#2>,<IP#3> \
-s <NC2 NETWORK NAME> \
-t <BUCKET TYPE (aws or ntx_oss)>

例:

clustermgmt-cli mst deploy \
-b nutanix-clusters-pilotlight-jwr \
-r ap-northeast-1 \
-i 10.110.33.201,10.110.33.202,10.110.33.203 \
-s PC-Net \
-t aws

デプロイが開始され、以下のように進行状況が表示されます。プロンプトが表示されたら、S3バケットにアクセスする権限を持つユーザーのAWSアクセスキーとシークレットアクセスキーを入力してください。

ステップ5: オンプレミスのPrism CentralとNC2のPrism Centralをリンク

オンプレミスまたはNC2のPrism Centralで、「Administration」 > 「Availability Zones」に移動し、別のPrism Centralインスタンスをリモート物理サイトとして追加します。

ステップ6: 保護ポリシーとDRプランを作成

Prism Centralコンソールで「データ保護」 > 「保護ポリシー」に移動します。ここから、新しい保護ポリシーを作成します。オンプレミスのクラスタをソースに、Amazon S3バケットをターゲットとして指定します。

レプリケーションスケジュールを設定し、最大36個のスナップショットを保持するリニアスナップショット、または最大1か月のデータ保持が可能なロールアップを選択できます。

次に、リカバリプランを作成します。オプションとして、Amazon S3に送られるVMとNC2クラスタに直接レプリケートされるVMをグループ化するために、2つのカテゴリを作成します。以下は、S3にレプリケートされるVMグループのカテゴリ例です。

その後、「データ保護」 > 「リカバリプラン」に移動し、カテゴリを参照して、正しいVMが正しい場所にレプリケートされるよう設定します:

S3へのデータレプリケートを確認 + フェイルオーバー

これでレプリケーションスケジュールが設定され、カテゴリを通じてターゲットVMが強調表示され、レプリケートされることが保証されます。S3バケットを確認することで、オンプレミスのクラスタからS3にスナップショットが送信されたことを確認できます。

この時点でフェイルオーバー、またはテストを行い、レプリケートされたデータからの復旧が可能であることを確認できます。これを行う際、S3のデータからフェイルオーバーするため、VMを復旧するターゲットクラスタを選択する必要があります。「+ Add Target Clusters」をクリックし、以下のようにNC2 on AWSクラスタを選択します:

警告が表示され、S3から復元されるVMの流入を処理するためにNC2 on AWSクラスタに追加ノードを必要とする場合があることを強調されます。必要に応じて、NC2管理コンソールを使用してノードを追加することでクラスタを拡張します。

フェイルオーバー後、VMがNC2 on AWSで問題なく稼働していることを確認できます。

まとめ

この記事では、NC2 on AWSのPilot Lightクラスタを使用した災害復旧の設定方法についてガイドとデモンストレーションを行いました。詳細については、以下のドキュメントリンクを参照してください。この内容が分かりやすかったことを願っています。具体的な使用事例や環境についてさらに情報が必要な場合は、お近くのNutanix担当者にお問い合わせください。

リンクと参考資料

Nutanix Cloud Clusters (NC2) on Azure: Solution architecture and Azure network configuration

This guide covers NC2 concepts and demonstrates how to configure an Azure network environment for deploying Nutanix Cloud Clusters (NC2) on Azure. While NC2 can be deployed quickly and easily through the NC2 portal inclusive of the creation of required VNets, subnets, and other Azure resources—this method may impose limitations on post-deployment modifications.

For instance, if the VNets are created via the NC2 portal, it may not be possible to transition a non-redundant configuration into a redundant or scale-out configuration. To address this, this guide provides step-by-step instructions for manually creating the necessary Azure network resources. Additionally, it highlights key considerations to ensure a smooth and successful deployment process.

Single vs. Scale-out Flow Gateway (FGW)

North-South traffic flow for workloads / User VMs (UVMs) on NC2 on Azure goes via one or several Flow Gateway (FGW) VMs. Since all outbound UVM traffic goes through these VMs, please select the number required based on the throughput you need for the workloads on your NC2 cluster. There are two types of FGW which support 10Gbps and 16Gbps of throughput each respectively.

These FGW VMs are not deployed on NC2 on Azure. Instead they are deployed as Azure native VM instances. Each FGW connects to an External and Internal Azure subnet. The NC2 cluster is set to send all external-facing traffic over Equal-cost Multipath (ECMP) with these FGW VMs as the next hop.

These FGW’s can be deployed in single or scale-out mode. As would be expected, single implies the FGW is a single point of failure. However, the health of the FGW is continuously monitored by the NC2 portal and it will be re-provisioned in case it malfunctions.

For scale-out, or redundant mode, two, three or a max of four FGW VMs are deployed in an active/active formation where traffic can flow through any and all of the VMs.

The above screenshot is from the NC2 portal where from the “Settings” menu we have highlighted the “Flow Gateway” tab to allow us to view and update FGW and other network related settings.

BGP speaker VMs

When scale-out FGW is selected, routing shifts from using static routes (UDR) to Border Gateway Protocol (BGP). Two BGP VMs will be automatically deployed if the FGW configuration changes from single to scale-out and those BGP VMs will need an Azure Route Server (ARS) to talk to.

Each FGW uses two BGP sessions on the ARS which the BGP VMs are paired with. Since the soft BGP session limit for ARS is 8, please ensure your ARS have sufficient sessions available when scaling out your FGW configuration.

Azure quotas

Prior to deploying it is good practice to verify that Azure subscription isn’t running out of the type of resources which will be required for the NC2 on Azure deployment. This includes the ARS BGP sessions mentioned in the section above as well as the FGW VM types, vCPU, memory and storage.

The small FGW VMs are of type Standard_D4v_4, the large FGW VMs are Standard_D32_v4 and the two BGP VMs are of type “Standard_D4_v4 type” (4 vCPUs and 16 GiB mem).

Quotas can be checked in the Azure console here: https://portal.azure.com/#view/Microsoft_Azure_Capacity/QuotaMenuBlade/~/myQuotas

VNets and subnets

The bare minimum amount of VNet’s required to deploy NC2 on Azure is two, but you likely need more. For example, having a Hub VNet for routing traffic between on-prem and Azure as well as between VNet’s. We will look at two configurations in this post: ExpressRoute and S2S VPN. Note that all VNet’s need to be peered in a mesh fashion.

The VNet’s which are always required are the Cluster VNet for the bare metal cluster nodes on which NC2 is deployed as well as the Prism Central VNet which is used by the Prism Central management VM(s).

Both the bare-metal cluster nodes and the Prism Central management VM(s) require subnets delegated to the MS bare.metal service to function. Azure restricts the number of bare.metal subnets in a VNet to one. That forces us to create two VNet’s with a bare.metal delegated subnet each.

The FGW VMs need two subnets: One Internal for connecting to the NC2 network controller and one External for connecting to the outside world. Additionally, the BGP speaker VMs need a subnet for themselves too. That brings the number of subnets up to three. In an ExpressRoute environment these subnets can be co-hosted in the Prism Central VNet. However, in a S2S VPN environment we need to create a third VNet to host these resources. Let’s refer to the third VNet as the FGW VNet.

Please see the below CIDR ranges as guidance only. Always refer to the official documentation for the latest updates.

The NC2 portal will complain if required subnets aren’t available for deployment. In this example the VNet lacks a subnet delegated to the bare.metal service.

NAT Gateways

The NC2 cluster, FGW VMs and other resources need to be able to communicate with the NC2 portal as well as various other endpoints outside the NC2 environment. These are detailed in the prerequisites part of the user guide. NAT Gateways are required to provide that internet-facing access and the NC2 portal will check that these are present during deployment. Deploying NC2 without NAT Gateways is possible but necessitates reaching out to Nutanix support to disable the NC2 portal check prior to deploying. In that case internet access would need to be provided through a Network Virtual Appliance (NVA) and vWAN. Please refer to the NC2 on Azure networking best practices guide for more detail.

“fastpathenabled”: Note that at the time of writing (December 19th 2024) the NC2 portal requires every NAT Gateway used with NC2 to have the “fastpathenabled” tag set to “true” for deployment to proceed. The tag can be added to existing NAT Gateways and doesn’t have to be present at time of NAT GW creation.

Below is an example of an error where one of the NAT Gateways used doesn’t have this tag configured.

Custom DNS server settings

Prior to deploying, please update the DNS server settings on each VNet to be used with NC2 to replace the Default (Azure-provided) DNS with a custom DNS server. In this example we use the Google 8.8.8.8 and 8.8.4.4 servers, but other DNS resolvers can be used too, including private DNS servers – provided they can also resolve all required public endpoints. Note that deployments to VNets with the Default DNS server configured will fail.

Solution architecture diagrams

The Azure VNets are prefixed with “Azure” and on the bottom right there are two Flow Virtual Networking (FVN) VPCs prefixed with “FVN”. The FVN components are all created on top of the NC2 cluster and aren’t directly visible in the Azure management console. There are many more ways of configuring NC2 on Azure, but those are out of scope for this blog post. Please refer to the documentation for more detail.

ExpressRoute

As discussed above, the ExpressRoute option we have the benefit of co-hosting the FGW and BGP subnets in the Prism Central VNet.

Site-to-Site VPN

For the S2S VPN option we add the FGW VNet which will be used to host the FGW internal, external and the BGP subnets.

VNet peerings

When peering your VNets, please ensure to do a full mesh, as is show in the diagrams. In other words – Every VNet need to be peered with every other VNet.

When peering from the Hub VNet, please use the following settings:

When peering from one of the other VNets (Cluster, Prism Central, FGW) to the Hub VNet, please use the following settings:

Summary and conclusion

In this blog post, we explored the foundational concepts of NC2 on Azure networking and presented solution architectures for two key use cases: ExpressRoute and Site-to-Site (S2S) VPN. We highlighted the required configurations, potential challenges, and important considerations.

By combining this guide with the official documentation, we aim to provide a clear path for manually creating Azure network infrastructure in preparation for an NC2 deployment.

We hope you found this information helpful. In our next post, we will dive deeper into the BGP component and demonstrate how to route traffic for overlay no-NAT networks. Stay tuned!

Links and references

Disaster Recovery with NC2 on AWS Pilot Light cluster + Amazon S3

Configuring a Disaster Recovery (DR) from on-premises to Nutanix Cloud Clusters (NC2) on AWS is straight-forward and can provide significant benefits for those responsible for ensuring Business Continuity. With a Pilot Light cluster this can even be done for workloads with two different levels of Recovery Time Objective (RTO) while saving on costs by minimizing NC2 cluster size during normal operations.

This type of DR configuration leverages Nutanix MST, or Multicloud Snapshot Technology.

Why use a Pilot Light cluster?

Workloads can all be important and vital to recover in case disaster strikes, but may have different requirements when it comes to how quickly they must be back online again. For applications and services with short recovery time windows, simply configure replication from on-premises to a small NC2 on AWS cluster using the Nutanix built-in DR tools.

For workloads which are fine with a slightly longer RTO, save on running costs by replicating them to Amazon S3. In case of disaster those workloads can be recovered from S3 to the NC2 on AWS cluster. This brings benefits in the ability to keep the NC2 on AWS cluster at a small and cost-efficient size during normal conditions, with the ability to scale out the cluster if there is need to recover workloads from S3.

Zero-compute option

There is additionally possible to configure a Zero-compute DR strategy with NC2 on AWS in which there is no NC2 cluster and the on-premises environment replicate data directly into Amazon S3, however that will be covered in a separate blog post.

Zero-compute DR offers even lower costs than Pilot Light since there is no need to deploy an NC2 cluster unless there is a disaster. However, it will increase RTO because the NC2 infrastructure need to be provisioned. Therefore, Zero-compute is cheaper from a running-costs perspective, but may incur higher costs to the business during a DR event due to the longer time required to deploy and configure the recovery cluster.

Solution architecture

The below diagram shows how it is possible to replicate both to Amazon S3 as well as to the NC2 on AWS cluster. Both with different RPO times.

Versions used

For this deployment we use the following versions:

EntityVersion
NC2 on AWS Prism Centralpc.2024.3
NC2 on AWS AOS7.0
On-premises Prism Centralpc.2024.2
On-premises AOS6.8.1 (CE 2.1)

Deployment steps

Configuring a Pilot Light cluster can be done in just a few hours. For the purpose of this blog post we have gone through the following steps:

Step 1: Deploy an NC2 on AWS cluster and enable DR

This can be done with a few clicks in the NC2 portal. Either deploy into an existing AWS VPC or create new resources during cluster deployment. If an existing VPC with connectivity to on-prem is used it will make setting things up even faster since routing is already configured.

Navigate to the Prism Central settings menu and enable Disaster Recovery as shown:

Step 2: Add connectivity between on-prem and AWS (if not already configured)

Configure Direct Connect or a S2S VPN to link the on-premises Nutanix cluster environment with the AWS VPC holding NC2 on AWS.

Step 3: Create an S3 bucket to store replicated data

Create an S3 bucket which can be accessed from the NC2 on AWS environment. Make sure to give it a name starting with “nutanix-clusters”. You can add on something in addition to keep buckets separate. In this example we use “nutanix-clusters-pilotlight-jwr” as the bucket name.

If not already created, create a user with full access to this bucket and make note of the Access and Secret Access keys as they are used in the next step. An example of a policy which gives full access to our bucket can be found below:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "FullAccessForMstToSpecificS3Bucket",
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::nutanix-clusters-pilotlight-jwr",
                "arn:aws:s3:::nutanix-clusters-pilotlight-jwr/*"
            ]
        }
    ]
}

Step 4: Configure MST on Prism Central in NC2 on AWS

MST will deploy a number of Virtual Machines and this deployment requires us to provide three IP addresses on the AWS native VPC CIDR range.

If NC2 was deployed with AWS native networking, simply provide IP addresses outside of the DHCP range on one of the existing networks, or alternatively add a new AWS native subnet through the Prism Central console.

If NC2 was deployed with Prism Central and Flow Virtual Networking (FVN), the easiest way to do this is to shrink the automatically created “PC-Net” DHCP range to make some space for MST. We shrink ours from ending at “10.110.33.253” to end at “10.110.33.200”. Make sure the no VMs are using addresses in the space you are creating.

SSH or open a console window to Prism Central using the “nutanix” user and enter the below command to start the deployment:

clustermgmt-cli mst deploy \
-b <BUCKET NAME> \
-r <AWS REGION> \
-i <IP#1>,1<IP#2>,<IP#3> \
-s <NC2 NETWORK NAME> \
-t <BUCKET TYPE (aws or ntx_oss)>

For our example we use:

clustermgmt-cli mst deploy \
-b nutanix-clusters-pilotlight-jwr \
-r ap-northeast-1 \
-i 10.110.33.201,10.110.33.202,10.110.33.203 \
-s PC-Net \
-t aws

The MST deployment begins as shown. Enter the AWS access key and secret access key for the user with rights to the S3 bucket when prompted.

Step 5: Link the on-premises Prism Central with the NC2 Prism Central

In Prism Central (on-premises or NC2), navigate to “Administration” and “Availability Zones” and add the other Prism Central instance as a remote physical site.

Step 6: Create a Protection Policy and DR Plan

Through the Prism Central console, navigate to Data Protection and Protection Policies. From here, create a new Protection Policy with the on-premises cluster as source and the Amazon S3 bucket as target.

A replication schedule can be set and allows Linear snapshots for maximum of 36 snapshots or Roll-up where data can be retained for up to one month.

Next we create a Recovery Plan. Optionally, to facilitate grouping of those VMs which are destined for Amazon S3 and those destined to be replicated directly to the NC2 cluster, we create two categories to place them in. Below is the category for the VM group which is to be replicated to S3.

When we then go to Data Protection and Recovery Plans we reference our category to get the correct VMs replicated to the correct location, as follows:

Verifying that data is replicated to S3 + Failing over

Now the replication schedule is set and the target VMs are highlighted through categories to ensure they are replicated. By checking our S3 bucket we can verify that snapshots have been sent to S3 from the on-premises cluster.

We can now do a failover or just a test to see that it is possible to recover from the replicated data. When you do this, since we are failing over from data in S3, make sure to select the target cluster to which we want to recover the VMs. This is done by clicking “+ Add Target Clusters” and selecting the NC2 on AWS cluster as per the below:

You will get a warning highlighting that there may be a need to expand the NC2 on AWS cluster with extra nodes to handle the influx of VMs being restored from S3. If required, simply expand the cluster by adding nodes through the NC2 management console.

After failing over we can verify that our VMs are up and running in NC2 on AWS without issues.

Wrap-up

This has been a guide and demonstration of how easy it is to configure Disaster Recovery using a Pilot Light cluster with NC2 on AWS. Please refer to the links below for more detail in the documentation. Hopefully this has been easy to follow. Please feel free to reach out to your nearest Nutanix representative for more information and guidance for your specific use case and environment.

Links and references

Elastic VMware Service on AWS: A new chapter of VMware for Amazon Web Services

Amazon Web Services (AWS) has introduced the Elastic VMware Service, an exciting new option for organizations seeking seamless hybrid cloud solutions. This service aims to bring the power of VMware’s virtualization suite into AWS’s extensive cloud ecosystem, offering businesses a pathway to modernize their IT infrastructure while leveraging existing VMware investments.

Key Features and Benefits

The Elastic VMware Service is designed to deliver a managed VMware environment natively integrated with AWS. This enables enterprises to run, manage, and scale VMware workloads directly within AWS, simplifying operations for businesses already using VMware tools like vSphere, NSX, and vSAN. Some key benefits include:

  • Native AWS Integration: Organizations can connect VMware workloads with native AWS services like S3, RDS, or AI/ML tools, unlocking new possibilities for innovation.
  • Operational Consistency: By using familiar VMware tools, IT teams can extend their on-premises environments to the cloud without extensive retraining.
  • Elasticity and Scalability: The service offers scalable resources that adapt to workload demands, optimizing performance and cost efficiency.
  • Simplified Migration: Workloads can be migrated with minimal downtime, enabling smoother transitions to a hybrid cloud model.

Challenges and Opportunities

While the Elastic VMware Service holds promise, it’s essential to recognize that it’s an early-stage offering. Here are some key points to consider:

Parity with Established Services

Compared to mature competitors like Nutanix Cloud Clusters (NC2) on AWS, the Elastic VMware Service is still in its infancy. Features such as advanced disaster recovery, multi-cloud connectivity, or deep integrations may take time to achieve parity. Enterprises evaluating the service should weigh their immediate needs against the current capabilities of Elastic VMware Service and factor in its growth trajectory.

Global Availability

Another critical factor is the service’s geographic availability. Initially, AWS is likely to roll out Elastic VMware Service in select regions, with global expansion following over time. For organizations in regions like Japan, this could mean a delay in adoption until the service becomes widely available. Businesses planning global deployments should account for these regional limitations and monitor AWS’s roadmap for updates.

A Positive Step Forward

Despite these challenges, the introduction of Elastic VMware Service is a testament to AWS’s commitment to hybrid cloud innovation. By addressing enterprise needs for flexibility, scalability, and operational consistency, the service positions itself as a compelling choice for VMware-centric organizations exploring the cloud.

As the service matures, it’s expected to add more features, expand regional availability, and strengthen its competitive position. Enterprises interested in early adoption should engage with AWS to understand the roadmap and ensure alignment with their strategic goals.

Conclusion

The Elastic VMware Service on AWS marks an exciting development in the hybrid cloud space. While it’s a promising start, enterprises should remain mindful of its evolving nature and regional rollout timeline. With time and continued investment, Elastic VMware Service has the potential to become a cornerstone for VMware workloads in the cloud—offering both innovation and operational efficiency.

Links and references

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アドレスを保持します。それでは始めましょう!

テストで使われていたソフトウエアバージョン

AOS6.10
Prism Centralpc.2024.2

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

この例では、オンプレミスのデータセンター(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の担当者にお問い合わせください。お読みいただきありがとうございました!

リンク