本繁體中文版使用機器翻譯，譯文僅供參考，若與英文版本牴觸，應以英文版本為準。

使用Amazon FSx for ONTAP將虛擬機器移轉到 Amazon EC2

08/18/2025 貢獻者

部署Amazon FSx for NetApp ONTAP以將虛擬機器移轉到 Amazon EC2。此過程包括設定 FSx ONTAP環境、配置 iSCSI 連接以及使用 Cirrus Data 的 MigrateOps 進行無縫資料傳輸。

配置 FSx ONTAP和 Cirrus Data 進行遷移操作

這 "逐步部署指南"展示如何將 FSx ONTAP磁碟區新增至 VPC。由於這些步驟本質上是連續的，因此請確保按順序涵蓋它們。

為了演示的目的，「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 中稱為 iGroups）
使用映射將新建立的磁碟區對應到適當的主機實體
建立所有其他必要的配置

準備生產主機以進行 iSCSI 連線：

如果需要，請安裝並設定 iSCSI 功能並設定啟動器。
如有必要，請使用適當的供應商識別碼安裝和設定多路徑（Windows 的 MPIO）。
如有必要，請根據供應商的最佳實務調整系統設置，例如使用 Linux 上的 udev 設定。
建立和管理 iSCSI 連接，例如 Windows 上的持久/收藏 iSCSI 目標。

若要為 FSx ONTAP和 AWS 設定 CMC 集成，請執行下列步驟：

登入 Cirrus Data Cloud 入口網站。
轉到您想要啟用整合的項目。
導航至整合 → 好東西。
捲動找到 FSx ONTAP並點擊新增整合。
提供描述性名稱（嚴格用於顯示目的）並新增適當的憑證。
建立整合後，在建立新的遷移工作階段期間，選擇「自動指派目標磁碟區」以在 FSx ONTAP上自動指派新磁碟區。

注意：除非為遷移啟用了“遷移到較小的磁碟區”，否則將建立與來源磁碟區大小相同的新 LUN。

注意：如果主機實體（iGroup）尚不存在，則將建立一個新的。所有主機 iSCSI 啟動器 IQN 都會新增至該新主機實體。

注意：如果具有任何 iSCSI 啟動器的現有主機實體已經存在，則它將重複使用。
完成後，請依照螢幕上的步驟新增 AWS 的整合。

注意：在將虛擬機器從本機儲存遷移到 AWS 時使用此整合以及 FSx ONTAP整合。

注意：如果要遷移的生產實例沒有直接出站連接，請使用管理中繼與 Cirrus Data Cloud 進行通訊。

新增整合後，就可以向專案註冊主機了。讓我們透過一個範例場景來討論這一點。

主機註冊場景

駐留在本機資料中心 vCenter 上的來賓 VMware VM：

Windows 2016 執行 SQL Server，其中包含三個 VMDK（包括作業系統和資料磁碟）。它正在運行一個活動資料庫。資料庫位於由兩個 VMDK 支援的資料卷上。

注意：由於來源為 VMware 環境並使用 VMDK，因此此來賓 VM 上目前未配置 Windows iSCSI Initiator 軟體。要透過 iSCSI 連接到我們的目標存儲，必須安裝和設定 iSCSI 和 MPIO。 Cirrus Data Cloud 整合將在此過程中自動執行此安裝。

注意：上一節中配置的整合會自動配置新的目標存儲，以建立新磁碟、設定主機實體及其 IQN，甚至修復應用程式 VM（主機）的 iSCSI 和多路徑配置。

將要遷移的 VMware 虛擬機器的映像

此示範將把應用程式 VMDK 從每個 VM 遷移到 FSx ONTAP自動配置和映射的 iSCSI 磁碟區。在這種情況下，OS VMDK 將會移轉到 Amazon EBS 卷，因為 Amazon EC2 執行個體僅支援將此 Amazon EBS 作為啟動磁碟。

注意：此遷移方法的比例因素是網路頻寬和連接本地到 AWS VPC 的管道。由於每個虛擬機器都配置了 1:1 主機會話，因此整體遷移效能取決於兩個因素：

網路頻寬
目標實例類型和 ENI 頻寬

遷移步驟如下：

在指定用於遷移波次的每台主機（Windows 和 Linux）上安裝 CMC 代理程式。這可以透過執行一行安裝命令來實現。

為此，請存取資料遷移 > 遷移主機 > 按一下“部署 Cirrus Migrate Cloud”，然後按一下以選擇“Windows”。

然後，複製 `iex`命令到主機並使用 PowerShell 運行它。一旦代理部署成功，主機將被加入到「遷移主機」下的專案中。

為每個虛擬機器準備 YAML。

注意：為每個 VM 建立一個 YAML 來指定遷移任務所需的配方或藍圖是至關重要的步驟。

YAML 提供操作名稱、註解（說明）以及配方名稱 MIGRATEOPS_AWS_COMPUTE，主機名(system_name) 和整合名稱(integration_name）以及來源和目標配置。可以將自訂腳本指定為切換操作之前和之後的操作。

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 設定。為此，請前往資料遷移> MigrateOps，按一下「開始新操作」並以有效的 YAML 格式輸入配置。
按一下“建立操作”。

注意：為了實現並行，每個主機都需要指定和配置一個 YAML 檔案。
除非 `scheduled_start_time`欄位在配置中指定，操作將立即開始。
該操作現在將執行並繼續。您可以從 Cirrus Data Cloud UI 中透過詳細訊息監控進度。這些步驟自動包括通常手動完成的任務，例如執行自動分配和建立遷移會話。

注意：在主機到主機遷移期間，將建立一個額外的安全群組，其規則允許入站 4996 端口，該安全組將允許所需的端口進行通信，並且在同步完成後將自動刪除。
當此遷移會話正在同步時，第 3 階段（切換）中有一個帶有標籤「需要批准」的未來步驟。在 MigrateOps 配方中，關鍵任務（例如遷移切換）需要使用者批准才能執行。專案操作員或管理員可以從 UI 批准這些任務。還可以創建未來的批准視窗。
一旦獲得批准，MigrateOps 操作將繼續進行切換。
片刻之後，操作就會完成。

注意：借助 Cirrus Data cMotion 技術，目標儲存已保持所有最新變更的更新。因此，在獲得批准後，整個最終切換過程將花費很短的時間（不到一分鐘）即可完成。