ワークロードをレプリケートまたはステージングし、サポート サービスが使用可能であることを確認したら、移行テストを開始できます。 移行テストでは、主に次の 2 つの領域に重点を置いています。
- アーキテクチャ: アーキテクチャをテストして、レプリケートされたリソースまたはステージングされたリソースで動作することを確認します。
- 管理ルーチン: 移行されたリソースの管理計画をテストして、それが機能していることを確認します。
ビジネス テストとは異なり、移行テストは IT アクティビティに重点を置いています。
問題を特定する際に、 修復計画に問題を追加できます。 すべての問題に対処したら、ワークロードのリリースに進むことができます。
テスト移行の実行
リソースをレプリケートした後、分離された環境でテスト移行を実行して、運用環境のワークロードに影響を与えないようにすることができます。
テスト移行はツールによって異なりますが、通常は、ライブ システムと並列に実行されるソース システムのレプリカを作成します。 これらのセカンダリ システムでテストを実行します。 テストを完了すると、永続的な変更を加えることなく、レプリケートされたリソースをクリーンアップできます。
テストを実行するには、次のものが必要です。
フェールオーバーをテストする分離されたネットワーク。 ネットワーク構成を、可能な限り目的の移行ネットワーク構成と一致させます。
ポイント対サイト VPN、ジャンプ ボックス、Azure Bastion など、ソースからの分離されたネットワーク アクセス。
テスト環境に対して認証を行う認証メカニズム。 テスト環境は分離されているため、ランディング ゾーンの ID プロバイダーを使用することはできません。
テスト移行リソースと共にテスト環境にデプロイするテスト移行ドメイン コントローラーを使用できます。 テスト後、リソースを使用してドメイン コントローラーをクリーンアップします。
または、分離されたネットワークにテスト ドメイン コントローラーが含まれる場合もあります。 ネットワークをピアリングして、Active Directory トラフィックのレプリケーションを許可します。 Azure でドメイン コントローラーのスナップショットを取得し、テスト目的でピアを削除してネットワークを分離できます。 必要なロールを押収し、テストを完了したときに状態を復元して、ライブ ID プロバイダーに変更を加えないようにすることができます。
移行ツールは、テスト移行を実行し、テスト資料をクリーンアップできる必要があります。 Azure Migrate で動作するこのようなテスト移行プロセスの例については、 VMware エージェントレス移行のテスト移行に関するページを参照してください。 これにより、ツールが移行のテストにどのように役立つかを理解するための開始点が得られます。
ヒント
このテスト環境を ビジネス テストに使用することもできます。
テストの問題を修復する
テストを行った後、次のことを確認します。
- 検出された問題を修復計画に記録します。
- 重大度に基づいて問題をトリアージし、トリアージの一部として回避策を特定します。
- 回避策を文書化します。 移行の一環として回避策を組み込むことができる場合は、問題を修復する必要がない可能性があります。
- 回避策以外の項目から始めます。 最初に回避策なしで項目を修復することを検討してください。
テスト計画の例
移行プロジェクトのテスト 計画出力の基本的な例を次に示します。
| テスト | 成功/失敗 | 注 |
|---|---|---|
| 仮想マシンのデプロイ | ✅ | |
| 管理者は仮想マシンにサインインできます | ✅ | |
| インターネット インフォメーション サービス (IIS) Web サービスの開始 | ✅ | |
| サービス 1 開始 | ✅ | |
| サービス 2 が 開始する | ❌ | サービスを手動で開始する必要がありました |
| Web サイト アクセス | ✅ | |
| SQL サービスの開始 | ✅ | |
| データベース アクセス | ✅ | |
| Web サイト間の負荷分散が機能する | ✅ | |
| Azure Application Gateway からのイングレスが機能する | ❌ | Application Gateway に証明書の問題がある |
| テスト トランザクションの合計時間が 5 ミリ秒未満でした | ✅ |