本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 遷移 Windows 容錯移轉叢集
[Microsoft 容錯移轉叢集](https://learn.microsoft.com/en-us/windows-server/failover-clustering/failover-clustering-overview)是一種伺服器群組，伺服器之間的儲存體大部分均共用。您可以使用容錯移轉叢集來促進應用程式和服務的高可用性。您也可以將容錯移轉叢集遷移至 AWS 雲端 ，以受益於其可靠性、效能和更低的 TCO。
Windows 容錯移轉叢集在雲端和內部部署環境中的運作方式不同。請務必注意，只有多重子網路叢集可以在雲端中部署。與內部部署環境不同之處，在於 Windows 容錯移轉叢集中的 IP 地址會指派給彈性網路介面卡 (ENA)，而非作業系統層級。在內部部署環境中，作業系統會處理 IP 地址指派，但雲端提供者 (AWS) 會處理雲端中的 IP 地址指派。由於容錯移轉叢集是一種作業系統層級的功能，所以無法控制 IP 容錯移轉。因此，相同的 IP 不能在節點之間進行容錯移轉。若要解決此問題，您可以使用叢集容錯移轉至次要 IP 的多重子網路叢集。次要 IP 會指派給其他子網路中的 ENA，並且可以上線。如需詳細資訊，請參閱 Microsoft 文件中的[容錯移轉叢集聯網基本概念和基礎知識](techcommunity.microsoft.com/blog/failoverclustering/failover-clustering-networking-basics-and-fundamentals/1706005)。
將 Windows 容錯移轉叢集遷移至 AWS 可能是一個複雜的程序，但透過仔細的規劃和實作，可以在對業務操作的最小干擾下完成。例如，每個應用程式在容錯移轉叢集中的設定皆不同，因此您必須了解其需求，然後再事先找出在雲端中滿足該需求的方法。此程序涉及下列步驟：
+ 確保所有叢集節點皆執行相同版本的 Windows 和所有必要的更新
+ 設定叢集仲裁
+ 確保所有應用程式和資料均已備份，且可在遷移期間還原
## 評估
評估階段是將容錯移轉叢集遷移至 的過程中的關鍵步驟 AWS。在此階段，您會收集目前環境的相關資訊、判斷遷移至 的可行性 AWS，以及識別任何潛在的挑戰或風險。建議您在評估階段遵循以下步驟：
+ **評估應用程式的準備**程度 – 判斷您的應用程式是否可以遷移至 ， AWS 而無需修改，或者是否需要更新或重寫以利用雲端原生服務。
+ **評估您的聯網和安全性需求** – 判斷您的網路和安全性需求，包括防火牆、負載平衡器和 VPNs的組態。
+ **評估您的資料遷移需求** – 判斷您的資料如何遷移至其中 AWS，包括資料的大小和位置、遷移所需的時間，以及任何資料傳輸成本。在內部部署環境中，您可能會使用不同的儲存技術 (例如，JBOD、NAS 及 SAN)。每項技術皆可透過不同的存取方法 (例如，SAN 光纖通道、iSCSI、SAS 或 SMB/NFS 共用) 向應用程式呈現資料。
+ **識別潛在風險和挑戰** – 識別可能影響遷移程序的任何潛在風險或挑戰，例如停機時間、相容性問題或資料遺失。
+ **估算成本** – 估算遷移至 的成本 AWS，包括 Amazon EC2 執行個體、儲存、資料傳輸和任何其他 AWS 服務 必要項目的成本。
+ **建立遷移計畫** – 根據評估階段期間收集的資訊，建立詳細的遷移計畫，其中包含時間表、所需資源，以及遷移至其中涉及的步驟 AWS。
### 評估目前的環境
評估您目前的環境，包括硬體和軟體組態，以判斷需要遷移到哪些項目 AWS。識別應用程式、伺服器及資料庫之間的任何相依性。
### 決定遷移策略
考慮您遷移到 的選項 AWS，包括lift-and-shift方法或重新架構您的環境，以利用雲端原生服務。
+ **傳統容錯移轉叢集遷移** – 如果您是從頭開始手動設定 Microsoft 容錯移轉叢集，您可以遵循在 [Amazon EC2 上部署 SQL Server ](https://docs.aws.amazon.com/sql-server-ec2/latest/userguide/create-sql-server-on-ec2-instance.html)中的指示。共用儲存體為容錯移轉叢集遷移的最重要考量之一。Amazon EBS 多連接不支援 SCSI-3 持久性保留，但 [Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) 和 [Amazon FSx for NetApp ONTAP](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/what-is-fsx-ontap.html) 都適用於共用儲存選項。其中一個最常見的使用案例為透過 Amazon FSx for Windows File Server 使用適用於 SQL Server 叢集的 Always On 容錯移轉叢集執行個體。如需詳細資訊，請參閱 AWS Storage Blog 中的[使用 Amazon FSx for Windows File Server 簡化 Microsoft SQL Server 高可用性部署](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/)文章。下一個步驟為將節點引入雲端。這可以透過使用 來實現 AWS Application Migration Service。如需詳細資訊，請參閱 AWS 儲存部落格中的[AWS 使用 CloudEndure Migration 將 Microsoft Windows 叢集遷移至](https://aws.amazon.com/blogs/storage/migrating-your-microsoft-windows-clusters-to-aws-using-cloudendure-migration/) 。接著，您可以針對應用程式設定叢集角色，以提供高可用性。
+ **使用彈性叢集幾乎沒有停機時間進行遷移** -** **如果您有業務關鍵型應用程式可遷移至雲端，且無法負擔停機時間，則彈性叢集可能非常適合。如果使用 [Microsoft 延伸叢集](https://learn.microsoft.com/en-us/windows-server/storage/storage-replica/stretch-cluster-replication-using-shared-storage)，則網站 A 和網站 B 必須透過網路彼此通訊，但兩者皆可使用其本身的個別共用儲存體。在遷移案例中，您可以充分利用此方法。例如，您的來源 (無論位於內部部署或其他供應商的雲端中) 可能是網站 A，該網站與您在其中部署網站 B 的 Amazon VPC 具有網路連線。當網站 B 啟動並執行後，您就可以切換至網站 B。由於您的來源儲存技術在可運用的複寫方法方面可能具有限制因素，因此資料複寫機制在該方法中相當重要。
+ **將部署在 VMware 內部部署的容錯移轉叢集遷移至 VMware Cloud on AWS** – VMware Cloud on AWS 原生支援 SCSI-3 持久性保留。這可讓您在 VMware Cloud on 的虛擬機器磁碟 (VMDK) 上託管容錯移轉叢集 AWS。如需詳細資訊，請參閱 [ VMware 文件中的使用共用磁碟將 SQL Server FCI 叢集遷移至 VMware Cloud on AWS](https://docs.vmware.com/en/VMware-Cloud-on-AWS/solutions/VMware-Cloud-on-AWS.919a954a9b6ca17cdc719ec42cda1401/GUID-E1F09B84241F7DD1DC702613CB717B2C.html)。 VMware
**注意**
自 2024 年 4 月 30 日起，VMware Cloud on AWS 不再由 AWS 或其通路合作夥伴轉售。此服務將繼續透過 Broadcom 提供。我們建議您聯絡 AWS 代表以取得詳細資訊。
+ **使用 Amazon EBS Multi-Attach 磁碟區遷移 SQL Server FCI** – 您可以使用 Amazon EBS Multi-Attach 和 NVMe 保留來建立 SQL Server 容錯移轉叢集執行個體 (FCIs)，並將 Amazon EBS 磁碟`io2`區做為 Windows Server 容錯移轉叢集上的共用儲存體。這些磁碟區只能連接到位於相同可用區域的執行個體。使用 Amazon EBS `io2`磁碟區部署 Windows Server 容錯移轉叢集需要將 SCSI 保留命令轉譯為 NVMe 保留命令的最新 Windows 驅動程式。 如需使用此方法 AWS 將內部部署 SQL Server FCI 遷移至單一可用區域中的詳細資訊，請參閱 AWS 部落格文章[如何在 Windows Server 上使用 Amazon EBS Multi-Attach 部署 SQL Server 容錯移轉叢集](https://aws.amazon.com/blogs/modernizing-with-aws/how-to-deploy-a-sql-server-failover-cluster-with-amazon-ebs-multi-attach-on-windows-server/)。
評估階段對於確保成功遷移容錯移轉叢集至 至關重要 AWS。如果您花時間收集資訊並識別潛在挑戰，您可以制定全面的遷移計畫，將停機時間降至最低、降低風險，並確保順利轉換至 AWS。
## 調動
在容錯移轉叢集遷移至 期間 AWS，調動階段需要準備叢集以遷移至 AWS 並進行測試，以確保其正常運作。調動階段包括下列步驟：
1. **準備目標環境** – 在此步驟中，您會建立託管容錯移轉叢集所需的 AWS 資源。這包括設定 VPC、子網路、安全群組和其他必要的資源。
1. **準備來源環境** – 在此步驟中，您會準備現有的容錯移轉叢集以進行遷移。其中可能涉及變更網路組態、設定複寫或安裝必要軟體。
1. **驗證叢集**：準備好來源和目標環境之後，您可以執行驗證測試以確保叢集正常運作。其中涉及執行一系列測試，確保叢集可成功容錯移轉至目標環境。
1. **建立複寫連結**：在驗證測試之後，您可以在來源環境和目標環境之間建立複寫連結。如此可確保針對來源環境所進行的任何變更都會複寫至目標環境。
1. **監控複寫** – 建立複寫連結之後，請監控複寫程序，以確保正確複寫所有變更。
1. **容錯移轉叢集**：確認複寫是否正確運作之後，請執行目標環境的最後容錯移轉。此步驟涉及停止來源環境中的叢集服務，並在目標環境中啟動。
1. **測試容錯移轉** – 容錯移轉完成後，執行測試以確保叢集上執行的應用程式和服務在新環境中正常運作
## 遷移
遷移 Microsoft 容錯移轉叢集可能是一個複雜程序，需要謹慎規劃和實作才能確保實現成功的結果。在針對生產環境進行任何變更之前，徹底評估現有環境、識別潛在問題，以及研擬全方位的遷移計畫 (包括測試和驗證) 至關重要。在遷移階段期間，請務必密切監控程序，並迅速解決任何問題或未預期的行為。所有利害關係人之間的溝通與協作 (包括 IT 團隊、企業使用者及廠商) 對於順利遷移程序而言至關重要。
此外，請務必考量遷移對容錯移轉叢集中執行之任何第三方應用程式或服務的影響。識別任何相依性，並徹底測試此類應用程式，以確保其在遷移後繼續如預期運作。另一個遷移階段的重要層面為建立復原計畫，以避免遷移程序期間發生任何未預期的問題或失敗。在理想情況下，此計畫包括回復遷移和還原原始環境的步驟，同時將對生產環境的任何影響降至最低。
最後，當遷移完成且容錯移轉叢集在新環境中順利執行之後，請務必執行遷移後驗證和測試，以確認所有項目皆如預期運作。此步驟包括監控效能、驗證容錯移轉功能，以及確保所有應用程式和服務皆能正常運作。