演習: 移行とモダン化
このユニットでは、Azure Migrate と、それを使用して特定のワークロードを Azure に移行する方法について確認します。
仮想マシンのレプリケーション
移行とモダン化を Azure Migrate ダッシュボードに追加できます。これは、クラウド導入フレームワークの計画モジュール中に完了した評価からマシンと分析情報を引き継ぎます。 ツール ウィンドウの [レプリケート] を選択すると、レプリケーションを開始できます。
Azure Migrate により、最大 500 台の仮想マシン (VM) の同時レプリケーションが実行され、最大 200 の同時移行を管理できます。 さらに必要な場合は、複数のバッチを作成することをお勧めします。 レプリケーションの時間は、VM の数とサイズに加えて、データセンターと Azure の間の接続速度によって異なります。
レプリケーション セットアップ フェーズでは、Azure Migrate の評価で Azure Virtual Machines のサイズについて提案された移行設定を使うことができます。 または、自分で設定を指定することができます。 このステップでは、移行するワークロードに適していると思われる VM サイズとストレージ ディスクの設定を構成できます。
さらに、このステージでは、サブスクリプション、リソース グループ、移行後に VM を配置する仮想ネットワークの指定を求められます。 また、データ センターの停止やメンテナンス イベントからアプリケーションとデータを保護するために、Availability Zones や可用性セットなどの可用性オプションを構成することもできます。
レプリケーションを開始した後、各 VM のレプリケーションを追跡および監視できるようになります。
図 1: Azure 管理センターの [Azure Migrate - サーバー] ページ。
移行済みの仮想マシンのテスト
対象となるすべての仮想マシンがレプリケートされ、Azure に移行されたら、それらを運用環境に移行する前に、すべてが確実に機能するようにテストを行うことができます。 このプロセスでは、前提条件の確認を実行し、テストの準備を行い、新しいテスト用 VM を作成して、テストを開始します。 このプロセスには数分かかります。
Azure Migrate のテスト移行機能は、オンプレミスのマシンに影響を与えることなく実行されます。 これにより、移行プロセスをテストし、アプリのテストを実行し、すべての問題に対処してから、完全な移行を行うことができます。
移行のテストは、移行プロセスに慣れるためにお勧めの機能です。 また、移行後に発生するタスクを理解するのにも役立ちます。 このテスト移行を必要なだけ何回でも実行して、プロセスを調整し、手順を確認することができます。
重要
テスト移行後、追加コストが発生しないようにテスト リソースを確実にクリーンアップする必要があります。
仮想マシンを運用環境に移行する
運用環境への移行の準備ができたら、Azure 管理センターの [マシンのレプリケート] ページで [移行] を選択します。
プロセスにより、移行の前にマシンをシャットダウンするように求めるメッセージが表示されます。これは、省略可能なステージです。 マシンをシャットダウンした場合、Azure Migrate により、計画した移行がデータ損失なしで実行されます (マシンにエージェント ベースのレプリケーションを使う場合は、最小限のデータ損失が発生します)。 マシンをシャットダウンしない場合は、移行前に最終的な同期が実行されますが、最終的な同期の開始後にマシンで発生した変更はレプリケートされません。
ソース マシンの終了は重要な手順ですが、どのオプションが各ワークロードに最適かを評価する必要があります。
このステップは運用システムに影響する場合があるので、業務の中断を最小限に抑えるために、ピーク時間外に移行を完了する必要があります。
これで、Azure Migrate は運用の移行プロセスを通じて実行されます。 前提条件の検証、移行の準備、Azure VM の作成、Azure VM の起動が行われると、その状態を確認できます。
リリース タスク
移行後、VM へのネットワーク トラフィックを再ルーティングすることによって、VM に運用トラフィックをリリースできます。 トラフィックを再ルーティングする前に、ワークロードを評価して、それぞれのビジネス変更計画、技術的な検証、ビジネス検証が完了していることを確認する必要があります。
ビジネス変更計画: ビジネスの中断を回避するため、ビジネス変更計画の次の側面が適切に伝達されていることを確認します。
- ユーザーのトレーニングが完了している (または少なくとも予定されている)。
- 停止期間が伝達され、承認されている。
- 運用データが同期され、ユーザーによって検証されている。
- 昇格と導入のタイミングが検証されている。 タイムラインと変更がエンドユーザーに伝達されていることを確認します。
技術的な検証: ビジネス変更計画に加えて、ワークロードに対する技術的な準備の検証を検討します。 実施することが推奨されるいくつかのテストを次に示します。
- ネットワーク分離テスト。 ネットワーク トラフィックをテストし、監視して、適切な分離と、予期しないネットワークの脆弱性がないことを確認します。 切り替え時に切断されるネットワーク ルーティングで予期しないトラフィックが発生していないことを検証します。
- 依存関係テスト。 すべてのワークロード アプリケーションの依存関係が移行され、移行済みの資産からアクセス可能であることを確認します。
- 事業継続とディザスター リカバリー (BCDR) のテスト。 バックアップと復旧のサービス レベル アグリーメント (SLA) が確立されていることを確認します。 可能であれば、BCDR ソリューションから資産の完全な回復を実行します。 少なくとも、Azure Backup を使ってバックアップ スケジュールを追加する必要があります。 より高度な SLA の場合は、Azure Site Recovery を使用した 2 番目のリージョンへのレプリケーションを検討することもできます。
- ユーザー ルートのテスト。 ユーザー トラフィックのトラフィック パターンとルーティングを検証します。 ネットワーク パフォーマンスが期待と合致していることを確認します。
- 最終パフォーマンス チェック。 ユーザーによってパフォーマンス テストが完了され、承認されていることを確認します。 自動パフォーマンス テストを実行します。
- その他の技術的な準備。 ネットワーク セキュリティ グループを使用して、未使用のサービスに対するネットワーク アクセスを制限します。 Azure Disk Encryption をデプロイして、データの盗難や不正アクセスからディスクをセキュリティ保護します。
最終的なビジネス検証: ビジネス変更計画および技術的な準備の検証後、次の最終タスクで、ビジネス検証を行うことができます。
- コストの検証 (プランと現実)。 テストによって、サイズとアーキテクチャの変更が発生する可能性があります。 デプロイの費用が当初のプランと合致していることを確認します。
- 切り替えプランを伝えて実行する。 切り替えの前に、切り替えについて伝え、それに従って実行します。
残りのオンプレミス サーバーに対するクリーンアップ タスクを完了します。 このようなタスクとしては、ローカル バックアップからのサーバーの削除や、領域を解放するためのストレージ エリア ネットワーク (SAN) ストレージからの生ディスク ファイルの削除などがあります。 移行されたサーバーに関連するドキュメントを更新し、Azure での新しい IP アドレスと場所を反映します。
上記の一覧の最後のタスクが完了すると、VM とサポートされるワークロードはリリースされたものと見なされます。 以上で、そのワークロードの移行の最終フェーズまたは作業分野が完了しました。