オンプレミスのメール organizationから Microsoft 365 または Office 365 にデータを移行するには、さまざまな方法があります。 移行を計画する場合、よくある質問は、データ移行のパフォーマンスを向上させ、移行速度を最適化する方法です。 この記事では、Exchange ハイブリッド展開の移行パフォーマンスについて説明します。 その他の移行方法のパフォーマンス情報については、「Microsoft 365 と Office 365 の移行パフォーマンスとベスト プラクティス」を参照してください。
ハイブリッド展開の移行では、オンプレミスの Exchange サーバーと Microsoft 365 または Office 365 の Exchange Online との間のスムーズな移行がサポートされます。
ハイブリッド展開の移行は、メールボックス データを Microsoft 365 または Office 365 に移行するための最も速い移行方法です。 実際のお客様のデプロイでは、最大 100 GB/時間のスループットが得られました。 次の表は、ネイティブの Microsoft 365 および Office 365 ハイブリッド移行シナリオに適用される要因の一覧を示しています。
地理的に分散された複数のサイトがオンプレミス環境に含まれている場合は、地理的に近くにある移行エンドポイントを作成することで移行のパフォーマンスを向上できます。 これは、オンプレミスのネットワークを使用する一元的な移行エンドポイントを使用する場合に匹敵する、Microsoft のネットワークを使用する移行などのシナリオがあるからです。
要因 1:データ ソース (Exchange Server)
| チェックリスト | 説明 | ベスト プラクティス |
|---|---|---|
| システムのパフォーマンス | データ抽出は、リソースを集中的に使用するタスクです。 移行パフォーマンスを向上させるには、ソース システムに CPU 時間やメモリーなどの十分なリソースが必要です。 移行の時点で、ソース システムは通常、通常のエンド ユーザーのワークロードを処理するためにフル容量に近い状態です。 追加の移行ワークロードにより、システム リソースが不足してエンド ユーザーにアクセスできなくなることがあります。 | パイロット移行テスト時に、システムのパフォーマンスを監視します。 システムがビジー状態の場合は、移行の速度が遅くなったり、サービスの利用に問題が発生したりする可能性があるため、特定のシステムに集中した移行をスケジュールしないことをお勧めします。 可能であれば、ハードウェア リソースを追加し、タスクやユーザーを移行に関係のない他のサーバーに移動することでシステムの負荷を軽減して、移行元システムのパフォーマンスを高めます。 詳細については、次のトピックを参照してください。 パフォーマンス チームに聞く:Exchange 2016 展開環境のサイジング 複数のメールボックス サーバーおよび複数のデータベースが存在する社内 Exchange 組織から移行する場合は、それら複数のメールボックス サーバーおよびデータベースに均等に分散された移行ユーザーの一覧を作成することをお勧めします。 個別のサーバーのパフォーマンスに基づいて、この一覧をさらに微調整し、スループットを最大化できます。 たとえば、サーバー A のリソースの利用可能時間がサーバー B よりも 50% 長い場合は、同じ移行バッチにおいてサーバー A からのユーザー数を 50% 多くするのが適切です。 他の移行元システムに対しても、同様のプラクティスを適用できます。 勤務時間後、週末、祝日など、サーバー リソースの利用可能時間が最大になるときに移行を実行します。 |
| バックエンド タスク | 移行時に実行されている他のバックエンド タスク。 移行は勤務時間後に実行するのがベスト プラクティスなので、社内のサーバーで実行中の他の保守タスク (データのバックアップなど) と競合することがよくあります。 | 移行中に実行される可能性がある他のシステム タスクを確認します。 データの移行は、リソースを大量に消費する他のタスクが実行されていないときに実施することをお勧めします。 注: オンプレミスの Microsoft Exchange を使用しているお客様の場合、一般的なバックエンド タスクは、バックアップ ソリューションと Exchange ストア のメンテナンスです。 |
要因 2:移行サーバー
ハイブリッド展開の移行は、クラウドから開始されるデータのプル/プッシュ型の移行であり、Exchange ハイブリッド サーバーが移行サーバーとして動作します。 この点が見落とされて、ハイブリッド サーバーとして性能の低い仮想マシンが使用されることがよくあります。 これにより移行のパフォーマンスが低下します。
移行サーバーのベスト プラクティス
前述のベスト プラクティスを適用することに加えて、次のベスト プラクティスを試した結果、実際のお客様の移行において移行のパフォーマンスが向上しました。
- Exchange ハイブリッド サーバーには、仮想マシンではなく、強力なサーバークラスの物理コンピューターを使用します。
- お客様のネットワーク ロード バランサーの背後に配置された複数のハイブリッド サーバーを使用します。
例えば、実際のお客様の移行では、次の構成を使用することによって、一貫して 30 GB/時のスループットを達成しました。
- ネットワーク: インターネットへの 500 MB 送信パイプ。10 GB のファイバー バックボーンを備えた 1 GB の内部ネットワーク。
-
ハードウェア: 2 つのクライアント アクセス/ハブ (物理) サーバーの仕様は次のとおりです。
- CPU: Intel® Xeon® CPU E5520 @ 2.27 GHz 2.26 GHz (2 つのプロセッサ)。
- RAM: 24 GB
- ディスク: 146 GB のディスク 8 台。 RAID 5 構成、合計で 960 GB の使用可能領域。
- MRSProxy: コンカレンシー 100 のコンカレンシーで構成されます。
要因 3:移行エンジン
ハイブリッド展開の移行では、ネイティブの Microsoft 365 および Office 365 ツールを使用します。 これは、Microsoft 365 および Office 365 移行サービスの調整の対象になります。
Exchange 2003 および Exchange の最新のバージョン
Exchange 2003 から移行する場合、エンドユーザー エクスペリエンスには重要な違いがあります。 Exchange の新しいバージョンとは異なり、Exchange 2003 のエンド ユーザーは、データが移行されているときにメールボックスにアクセスできません。 そのため、Exchange 2003 のお客様は通常、特にメールボックスのサイズが大きいかネットワークが遅いために移行パフォーマンスが低い場合、移行のスケジュールを設定するタイミングと移行に必要な時間についてより懸念します。
Exchange 2003 の移行も、中断に対して非常に敏感です。 たとえば、実際の顧客の移行では、10 GB のメールボックスの移行中に、メールボックスの移行が 50% 完了したときにサービス インシデントが発生しました。 この問題を解決するには、データ移行を処理していた Office 365 クライアント アクセス サーバーを再起動する必要がありました。 この場合、そのメールボックスの移行を再開する必要がありました。つまり、お客様は 10 GB のデータをすべて再度移行する必要がありました。 移行は停止した時点から再開できませんでした。 ただし、Exchange 2010 以降のバージョンの Exchange は、中断後に移行を再開できます。
移行エンジンのベスト プラクティス
大規模で重要な Exchange 2003 メールボックスの場合は、2 ホップの移行を選択するお客様もいます。
- ファースト ホップ: Exchange 2003 から Exchange 2010 以降のサーバー (通常はハイブリッド サーバー) にメールボックスを移行します。 最初のホップはオフラインの移動ですが、通常は、ローカル ネットワークを経由した非常に高速な移行です。
- セカンド ホップ: Exchange 2010 以降から Microsoft 365 または Office 365 にメールボックスを移行します。
2 番目のホップは、オンライン移動で、より優れたユーザー エクスペリエンスとフォールト トレランスを提供します。 この 2 ホップのアプローチを使用する場合は、一時的なオンプレミスのユーザー メールボックス用に Exchange ライセンスが必要です。
Mailbox Replication サービス プロキシ (MRSProxy)
MRS プロキシは、Microsoft 365 および Office 365 側で実行されているメールボックス レプリケーション サービスと連携するオンプレミスの移行機能です。 詳細については、「移動要求について」をご覧ください。
MRSProxy のベスト プラクティス
オンプレミスの Exchange ハイブリッド サーバーに対して、MRSProxy 接続の最大数を構成できます。 次の Windows PowerShell コマンドを実行します。
Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -MRSMaxConnections <number between 0 and unlimited; default is 100>
注:
ほとんどのお客様の移行では、既定の MRSMaxConnections 値を変更する必要はありません。 移行元サーバーが移行の負荷によって過負荷状態になることを防止する必要がある場合は、接続数を減らすことができます。 この設定は、MRSProxy サーバーごとの設定です。 お客様が 2 台の MRSProxy サーバーを使用しており、それぞれに 10 の接続を設定した場合、MRSProxy 接続の合計数は 20 (2 x 10) となります。 社内 Exchange 2010 組織における MRSProxy サービスの構成の詳細については、「リモート クライアント アクセス サーバーで MRSProxy サービスを開始する」をご覧ください。
要因 4:ネットワーク
検証テスト
Exchange 2010 以降を使用しているお客様は、複数のテスト メールボックスの移行を実行することによって、ハイブリッド移行のネットワーク パフォーマンスをテストできます。 または、-SuspendWhenReadyToComplete オプションを指定して実際のユーザー メールボックスを移行し、移行のパフォーマンスについての情報を表示できます。 テストが完了したら、エンド ユーザーへの影響がないように移動要求を削除します。
移動要求の詳細については、「New-MoveRequest」を参照してください。
要因 5:Office 365 サービス
Microsoft 365 および Office 365 のリソース正常性ベースの調整は、Microsoft 365 または Office 365 ハイブリッド展開の移行を使用した移行に影響します。 詳細については、上記の 「要因 3: 移行エンジン」 セクションを参照してください。