日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

Amazon FSx for ONTAPを使用したAmazon EC2へのVMの移行：導入ガイド

02/03/2025 共同作成者

この資料では、この移行ソリューションの導入手順について説明します。

移行処理向けにFSx ONTAPとCirrusデータを設定

https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/getting-started-step1.html["ステップバイステップ形式の導入ガイド"]VPCにFSx ONTAPボリュームを追加する方法を示します。これらの手順は本質的に連続しているため、順序どおりに説明してください。

このデモでは、「DRaaSDemo」は作成されたファイルシステムの名前です。

デモ用ファイルシステムのユーザインターフェイスの画像

AWS VPCを設定し、パフォーマンス要件に基づいてFSx ONTAPをプロビジョニングしたら、 "新しいプロジェクトを作成する"既存のプロジェクトにログインするか、既存のプロジェクトに"cloud.cirrusdata.com"アクセスします。

Cirrus Dataプロジェクトのユーザーインターフェイスの画像

MigrationOpsのレシピを作成する前に、AWS Cloudを統合として追加する必要があります。CMCは、FSx ONTAPおよびAWSとの組み込み統合を提供します。FSx ONTAPとの統合により、以下の自動化機能が提供されます。

FSx ONTAPファイルシステムの準備：*
ソースボリュームと一致する新しいボリュームとLUNを作成する

注：FSx ONTAP FSモデルのデスティネーションディスクは、LUNを格納するのに十分な容量と、スナップショットおよびメタデータを容易にするための合理的な量のオーバーヘッドを持つ「ボリューム」上に作成される「LUN」です。CMCの自動化では、これらすべての詳細が処理され、オプションのユーザー定義パラメータを使用して適切なボリュームとLUNが作成されます。

ホストイニシエータIQNを使用してホストエンティティ（FSxではigroup）を作成する
マッピングを使用して、新しく作成したボリュームを適切なホストエンティティにマッピング
その他すべての必要な構成の作成
iSCSI接続用の本番ホストの準備：*
必要に応じて、iSCSI機能をインストールして設定し、イニシエータを設定します。
必要に応じて、適切なベンダー識別子を使用してマルチパス（WindowsのMPIO）をインストールして設定します。
Linuxのudev設定など、ベンダーのベストプラクティスに従って、必要に応じてシステム設定を調整します。
Windowsで、永続的/お気に入りのiSCSIターゲットなどのiSCSI接続を作成および管理します。

FSx ONTAPおよびAWS向けCMC統合を設定するには、次の手順を実行します。

Cirrus Data Cloudポータルにログインします。
統合を有効にするプロジェクトに移動します。
[Integrations]→[Goodies]に移動します。
スクロールしてFSx ONTAPを見つけ、[Add integration]をクリックします。
わかりやすい名前（表示用のみ）を指定し、適切なクレデンシャルを追加します。
統合が作成されたら、新しい移行セッションの作成時に、[Auto Allocate Destination Volumes]を選択して、FSx ONTAPに新しいボリュームを自動的に割り当てます。

注：「小さいボリュームへの移行」が有効になっていないかぎり、新しいLUNはソースボリュームと同じサイズで作成されます。

注：ホストエンティティ（igroup）がまだ存在しない場合は、新しいホストエンティティ（igroup）が作成されます。すべてのホストiSCSIイニシエータIQNがその新しいホストエンティティに追加されます。

注：いずれかのiSCSIイニシエータを持つ既存のホストエンティティがすでに存在する場合は、そのホストエンティティが再利用されます。
完了したら、画面の手順に従ってAWS用の統合を追加します。

注：この統合は、FSx ONTAP統合とともに、オンプレミスストレージからAWSに仮想マシンを移行する際に使用します。

注：移行する本番インスタンスの直接のアウトバウンド接続がない場合は、管理リレーを使用してCirrus Data Cloudと通信します。

インテグレーションが追加されたら、プロジェクトにホストを登録します。ここでは、シナリオの例を挙げて説明します。

ホスト登録のシナリオ

オンプレミスのデータセンターのvCenter上にあるゲストVMware VM：

Windows 2016でSQL Serverを実行し、3つのVMDK（OSとデータディスクを含む）を実行します。アクティブデータベースを実行しています。データベースは、2つのVMDKによってバックアップされるデータボリュームに配置されています。

注：ソースはVMware環境であり、VMDKが使用されているため、このゲストVMにはWindows iSCSIイニシエータソフトウェアは現在設定されていません。iSCSI経由でデスティネーションストレージに接続するには、iSCSIとMPIOの両方をインストールして構成する必要があります。Cirrus Data Cloudの統合は、プロセス中にこのインストールを自動的に実行します。

注：前のセクションで設定した統合により、新しいディスクの作成、ホストエンティティとそのIQNのセットアップ、さらにはiSCSIおよびマルチパス構成用のアプリケーションVM（ホスト）の修復において、新しいデスティネーションストレージの設定が自動化されます。

移行するVMware仮想マシンのイメージ

このデモでは、各VMのアプリケーションVMDKを、FSx ONTAPから自動でプロビジョニングおよびマッピングされたiSCSIボリュームに移行します。この場合、Amazon EC2インスタンスはブートディスクとしてのみこのAmazon EBSをサポートするため、OS VMDKはAmazon EBSボリュームに移行されます。

注：この移行アプローチの拡張要因は、ネットワーク帯域幅と、オンプレミスとAWS VPCを接続するパイプです。各VMには1対1のホストセッションが構成されているため、移行の全体的なパフォーマンスは次の2つの要因に左右されます。

ネットワーク帯域幅
ターゲットインスタンスタイプとENI帯域幅

移行手順は次のとおりです。

マイグレーションウェーブ用に指定された各ホスト（WindowsおよびLinux）にCMCエージェントをインストールします。これは、1行のインストールコマンドを実行することで実行できます。

これを行うには、[Data Migration]>[Migration Hosts]にアクセスし、[Deploy Cirrus Migrate Cloud]をクリックして[Windows]を選択します。

次に、ホストにコマンドをコピーし iex、PowerShellを使用して実行します。エージェントの導入が正常に完了すると、そのホストがプロジェクトの[Migration hosts]に追加されます。

各仮想マシンのYAMLを準備します。

注：移行タスクに必要なレシピまたは青写真を指定するYAMLをVMごとに設定することは重要なステップです。

YAMLは、オペレーション名、メモ（説明）、レシピ名AS、ホスト名(system_name、統合名(integration_name）、およびソースとデスティネーションの構成を提供します MIGRATEOPS_AWS_COMPUTE。カットオーバー処理の前後にカスタムスクリプトを指定できます。

operations:
    -   name: Win2016 SQL server to AWS
        notes: Migrate OS to AWS with EBS and Data to FSx ONTAP
        recipe: MIGRATEOPS_AWS_COMPUTE
        config:
            system_name: Win2016-123
            integration_name: NimAWShybrid
            migrateops_aws_compute:
                region: us-west-2
                compute:
                    instance_type: t3.medium
                    availability_zone: us-west-2b
                network:
                    vpc_id: vpc-05596abe79cb653b7
                    subnet_id: subnet-070aeb9d6b1b804dd
                    security_group_names:
                        - default
                destination:
                    default_volume_params:
                        volume_type: GP2
                    iscsi_data_storage:
                        integration_name: DemoDRaaS
                        default_volume_params:
                            netapp:
                                qos_policy_name: ""
                migration:
                    session_description: Migrate OS to AWS with EBS and Data to FSx ONTAP
                    qos_level: MODERATE
                cutover:
                    stop_applications:
                        - os_shell:
                              script:
                                  - stop-service -name 'MSSQLSERVER' -Force
                                  - Start-Sleep -Seconds 5
                                  - Set-Service -Name 'MSSQLSERVER' -StartupType Disabled
                                  - write-output "SQL service stopped and disabled"

                        - storage_unmount:
                              mountpoint: e
                        - storage_unmount:
                              mountpoint: f
                    after_cutover:
                        - os_shell:
                              script:
                                  - stop-service -name 'MSSQLSERVER' -Force
                                  - write-output "Waiting 90 seconds to mount disks..." > log.txt
                                  - Start-Sleep -Seconds 90
                                  - write-output "Now re-mounting disks E and F for SQL..." >>log.txt
                        - storage_unmount:
                              mountpoint: e
                        - storage_unmount:
                              mountpoint: f
                        - storage_mount_all: {}
                        - os_shell:
                              script:
                                  - write-output "Waiting 60 seconds to restart SQL Services..." >>log.txt
                                  - Start-Sleep -Seconds 60
                                  - stop-service -name 'MSSQLSERVER' -Force
                                  - Start-Sleep -Seconds 3
                                  - write-output "Start SQL Services..." >>log.txt
                                  - Set-Service -Name 'MSSQLSERVER' -StartupType Automatic
                                  - start-service -name 'MSSQLSERVER'
                                  - write-output "SQL started" >>log.txt

YAMLが設定されたら、MigrateOps構成を作成します。これを行うには、[Data Migration]>[MigrateOps]に移動し、[Start New Operation]をクリックして有効なYAML形式で構成を入力します。
[Create operation]をクリックします。

注：並列処理を実現するには、各ホストでYAMLファイルを指定して構成する必要があります。
設定でフィールドが指定されていない場合 scheduled_start_time、処理はすぐに開始されます。
処理が実行され、処理が続行されます。Cirrus Data Cloud UIから、進捗状況を詳細なメッセージで監視できます。これらの手順には、自動割り当ての実行や移行セッションの作成など、通常は手動で実行されるタスクが自動的に含まれます。

注：ホスト間の移行中に、受信4996ポートを許可するルールを持つ追加のセキュリティグループが作成されます。これにより、通信に必要なポートが許可され、同期が完了すると自動的に削除されます。
この移行セッションの同期中は、フェーズ3（カットオーバー）のあとの手順で「Approval Required」というラベルが付けられます。MigrateOpsレシピでは、重要なタスク（移行のカットオーバーなど）を実行するにはユーザの承認が必要です。プロジェクトオペレータまたは管理者は、UIからこれらのタスクを承認できます。将来の承認ウィンドウを作成することもできます。
承認されると、MigrateOps処理はカットオーバーを続行します。
しばらくすると、操作が完了します。

注: Cirrus Data cMotion™テクノロジにより、デスティネーションストレージは最新の変更をすべて反映して最新の状態に保たれています。そのため、承認後、この最終的なカットオーバープロセス全体が完了するまでに非常に短時間（1分未満）かかります。