評估工作負載整備程度Evaluate workload readiness

此活動著重於評估遷移至雲端的工作負載整備程度。This activity focuses on evaluating readiness of a workload to migrate to the cloud. 在此活動期間,雲端採用小組會驗證所有資產和相關聯的相依性是否與所選的部署模型和雲端提供者相容。During this activity, the cloud adoption team validates that all assets and associated dependencies are compatible with the chosen deployment model and cloud provider. 在此過程中,小組會記載補救相容性問題所需的任何付出。During the process, the team documents any efforts required to remediate compatibility issues.

評估假設Evaluation assumptions

在雲端採用架構中討論原則的大部分內容都是雲端中立的。Most of the content discussing principles in the Cloud Adoption Framework is cloud agnostic. 不過,整備評估程序必須主要專屬於每個特定的雲端平台。However, the readiness evaluation process must be largely specific to each specific cloud platform. 下列指引假設有遷移至 Azure 的意圖。The following guidance assumes an intention to migrate to Azure. 它也會假設對複寫活動使用 Azure Migrate (也稱為 Azure Site Recovery)。It also assumes use of Azure Migrate (also known as Azure Site Recovery) for replication activities. 如需替代工具,請參閱複寫 選項For alternative tools, see Replication options.

本文不會捕捉所有可能的評估活動。This article doesn't capture all possible evaluation activities. 假設每個環境和業務結果都將規定特定的需求。It is assumed that each environment and business outcome will dictate specific requirements. 為了協助加速建立這些需求,本文的其餘部分會分享一些與基礎結構資料庫網路評估相關的常見評估活動。To help accelerate the creation of those requirements, the remainder of this article shares a few common evaluation activities related to infrastructure, database, and network evaluation.

一般基礎結構評估活動Common infrastructure evaluation activities

務必記載主機組態、複寫的 VM 組態、儲存體需求或網路組態中的任何差異。Be sure to document any discrepancies in host configuration, replicated VM configuration, storage requirements, or network configuration.

一般資料庫評估活動Common database evaluation activities

注意

任何資產的同步處理都會在複寫期間耗用頻寬。Synchronization of any asset consumes bandwidth during the replication processes. 有個非常常見的缺陷,那就是忽略在複寫點和發行之間保持資產同步所需的頻寬耗用量。A very common pitfall is to overlook the bandwidth consumption required to keep assets synchronized between the point of replication and release. 在發行週期內,資料庫是頻寬的常見取用者,而具有大型儲存體磁碟使用量或高變動率的資料庫則特別有關。Databases are common consumers of bandwidth during release cycles, and databases with large storage footprints or a high rate of change are especially concerning. 在使用者接受度測試 (UAT) 和發行之前,請考慮使用受控制的更新來複寫資料結構的方法。Consider an approach of replicating the data structure, with controlled updates before user acceptance testing (UAT) and release. 在此種情況下,Azure Site Recovery 的替代項目可能更適合。In such scenarios, alternatives to Azure Site Recovery may be more appropriate. 如需詳細資訊,請參閱 Azure 資料庫移轉指南中的指引。For more information, see guidance from the Azure Database Migration Guide.

一般網路評估活動Common network evaluation activities

  • 計算在導致發行的反覆運算期間所有要複寫 VM 的總儲存體。Calculate the total storage for all VMs to be replicated during the iterations leading up to a release.
  • 計算在導致發行的反覆運算期間所有要複寫 VM 的漂移或變動率。Calculate the drift or change rate of storage for all VMs to be replicated during the iterations leading up to a release.
  • 將總儲存體和漂移加總,以計算每次反覆運算所需的頻寬需求。Calculate the bandwidth requirements needed for each iteration by summing total storage and drift.
  • 計算目前網路上可用的未使用頻寬,以依照反覆運算對齊方式進行驗證。Calculate unused bandwidth available on the current network to validate per iteration alignment.
  • 記載要達到預期移轉速度所需的頻寬。Document bandwidth needed to reach anticipated migration velocity. 如果需要任何補救措施,以提供所需的頻寬,請通知負責補救活動的小組。If any remediation is required to provide necessary bandwidth, notify the team responsible for remediation activities.

注意

總儲存體會在初始複寫期間直接影響頻寬需求。Total storage directly affects bandwidth requirements during initial replication. 不過,儲存體漂移會從複寫點繼續到發行為止。However, storage drift continues from the point of replication until release. 這表示漂移對可用的頻寬有累積的影響。This means that drift has a cumulative effect on available bandwidth.

下一步Next steps

完成系統評估之後,輸出會饋送新雲端架構的開發。After the evaluation of a system is complete, the outputs feed the development of a new cloud architecture.