次の方法で共有


ハイブリッド移行の場合のパフォーマンス要因とベスト プラクティス

オンプレミスの電子メール 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 Serverの正常性とパフォーマンス

Exchange のパフォーマンスについて

複数のメールボックス サーバーおよび複数のデータベースが存在する社内 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 以降のサーバー (通常はハイブリッド サーバー) にメールボックスを移行します。 最初のホップはオフラインの移動ですが、通常は、ローカル ネットワークを経由した非常に高速な移行です。
  • 2 番目のホップ: 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 ハイブリッド展開の移行を使用した移行に影響します。 詳細については、上記の 「Factor 3: Migration engine 」セクションを参照してください。