Exchange Online 移行のパフォーマンスとベスト プラクティス

 

適用先:Exchange Online, Exchange Server, Exchange Server 2013

トピックの最終更新日:2017-04-09

オンプレミスの電子メール組織から Office 365 の Exchange Online へデータを移行するには、多くの方法があります。Exchange Online への移行を計画する場合に共通の課題となるのは、データ移行のパフォーマンスをいかに向上させ、かつ移行速度を最適にするかということです。

メモメモ:
このトピックに記載されているパフォーマンス情報は、専用サブスクリプション プラン用の Microsoft Office 365 サービスには適用されません。専用プランの詳細については、「Office 365 専用プラン サービスの概要」を参照してください。

Exchange Online は Office 365 の一部として、組織に Microsoft Exchange Server に基づくクラウド ベースのメッセージング ソリューションを提供します。Exchange Online では、電子メール、予定表、連絡先のデータを既存のメッセージング環境から Office 365 に移行する、いくつかの方法をサポートしています。

Office 365 のネットワークとパフォーマンスについて詳しくは、「Office 365 のネットワーク計画とパフォーマンスのチューニング」を参照してください。

よく使用される移行方法

移行方法 説明 リソース

IMAP 移行

Exchange 管理センター (EAC) または Exchange 管理シェルを使用して、ユーザーのメールボックスの内容を IMAP メッセージング システムからユーザーの Exchange Online メールボックスに移行できます。これには、Gmail や Yahoo Mail などの他のホストされた電子メール サービスからのメールボックスの移行も含まれます。

詳細については、「IMAP 移行」を参照してください。

一括移行

一括移行を使用すると、すべての社内メールボックスが数日で Exchange Online に移行されます。メール組織全体を Office 365 に移動して、Office 365 でユーザー アカウントを管理することを計画している場合は、このタイプの移行を使用します。1 回の一括移行を使用することにより、最大 2,000 個のメールボックスをオンプレミスの Exchange 組織から Exchange Online に移行することができます。社内 Exchange 組織のメール連絡先および配布グループも移行されます。

詳細については、「Exchange の一括移行」を参照してください。

段階的な移行

最終的に組織のメールボックスのすべてを Exchange Online に移行することを計画している場合は、段階的な移行を使用します。段階的な移行を使用すると、数週間から数カ月をかけ、社内メールボックスを何回かに分けて Exchange Online に移行していくことができます。最終的な目標は、Office 365 にメール組織を完全に移行することです。

詳細については、「Exchange の段階的移行」を参照してください。

ハイブリッド展開

ハイブリッド展開によって、充実した機能の利用、および既存の社内 Microsoft Exchange 組織に対する管理制御をクラウドにまで拡張することができます。ハイブリッド展開は、社内 Exchange Server 2013 または 2010 組織と Microsoft Office 365 の Exchange Online 間で、統一された Exchange 組織のルック アンド フィールを実現します。さらに、ハイブリッド展開を Exchange Online 組織に完全に移行するための中間ステップとして使用することもできます。

詳細については、「Exchange Server のハイブリッド展開」を参照してください。

サード パーティを利用した移行

サード パーティから入手できるツールは数多くあります。これらのツールでは、独自のプロトコルやアプローチを使用して、IBM Lotus Notes や Novell GroupWise などの電子メール プラットフォームから電子メールを移行します。

サード パーティ プラットフォームから Exchange に移行する場合に利用できるサード パーティの移行ツールとパートナーを以下に示します。

  • Binary Tree   プラットフォームに依存しないメッセージング移行/共存ソフトウェアのプロバイダーです。IBM の Lotus Notes および Domino と Microsoft Exchange および Microsoft SharePoint をベースとするオンプレミスおよびオンラインのエンタープライズ メッセージング/コラボレーション環境の分析、共存、移行を実現する製品を提供しています。

  • BitTitan   Exchange Online への移行ソリューションのプロバイダーです。

  • Dell   移行前の分析やユーザーおよびアプリケーションの完全な共存を含む、オンプレミスおよびホスト型の移行/共存ソフトウェアのプロバイダーです。社内の Microsoft Exchange、IBM Domino、Novell GroupWise、Zimbra、その他の環境から、Microsoft Office 365、Exchange Online、および SharePoint Online に移行するためのすべての機能が用意されています。

  • Metalogix   Exchange Online および SharePoint Online への移行ソリューションのプロバイダーです。

  • SkyKick オンプレミスの Exchange、Gmail、POP3、IMAP、Lotus Notes を Microsoft Office 365 に移行するための、自動移行ソリューションのプロバイダーです。エンドツーエンドの移行ツールにより、移行プロジェクトの販売、計画、移行、管理、およびオンサイトの各フェーズでパートナーを支援します。

  • TransVault   Exchange Online への移行ソリューションのプロバイダーです。

以下の表では、メールボックスとメールボックス データを Office 365 の Exchange Online に移行する場合のさまざまな移行方法ごとに観測されたパフォーマンス結果を比較しています。これらの結果は、内部テストおよび、お客様が行った実際の Office 365 への移行に基づいたものです。

重要重要:
移行の実施方法や時期には違いがあるため、実際の移行速度はこれより遅い場合もあれば、速い場合もあります。

 

移行方法 Office 365 ユーザー調整 Office 365 の移行サービス調整 Office 365 のリソース正常性ベースの調整 1 時間あたりのクライアントごと (該当する場合) の実際の平均スループット

IMAP 移行

不可

はい

10 ~ 14 GB (同時実行数: 20)

一括移行

不可

はい

10 ~ 14 GB (同時実行数: 20)

段階的な移行

不可

はい

10 ~ 14 GB (同時実行数: 20)

ハイブリッド移行

不可

はい

10 から 14 GB (同時移動数 20 でオンプレミスの Exchange 2013 または 2010 CAS (MRS プロキシ) ごと) 1

サード パーティ製 MAPI による移行

いいえ

はい

4 から 12 GB (同時実行数: 20) 3

サード パーティ製 EWS による移行

不可

はい

はい

5 から 10 GB (同時実行数: 20) 2

クライアント アップロード (Outlook PST から)

いいえ

はい

0.5 GB

11 つのメールボックスを移動した場合の実際のスループットは、0.3 から 1.0 GB/時の範囲です。一時エラー発生時の停止時間を 2% 未満、ネットワーク待ち時間を 100 ミリ秒未満に保持できるネットワークでは、1000 MB/h を超えるメールボックスあたりのスループット速度を実現できます。さらに多くのメールボックスを同時に移行することで、より高いデータ移行速度を実現できます。オンプレミスの CAS (MRSProxy) サーバーがハードウェアの容量限度に達している場合、ネットワークの帯域幅は不十分な場合、またはネットワークの遅延が大きすぎる場合には、1 つのメールボックスの移動のスループットが遅くなります。サーバーを追加するか、またはネットワーク接続性を一時的に向上させて、移行の速度を上げることを検討してください。

21 つの EWS を移動した場合の実際のスループットは、0.2 から 0.5 GB/時の範囲です。より多くの移行を同時に実行することで、より高いデータ移行速度を実現できます。たとえば、100 20 件の移行を同時に実行すると、全体のスループットは 20–5010-14 GB/時の範囲になります。社内サーバーまたはネットワークが容量限度に達しているときには、1 つの EWS の移行のスループットは遅くなります。

31 つの MAPI による移行のスループットは、0.1 から 0.5 GB/時の範囲です。より多くの移行を同時に実行することで、より高いデータ移行速度を実現できます。社内サーバーまたはネットワークが容量限度に達しているときには、1 つの MAPI の移行のスループットは遅くなります。

電子メールの移行には、移行のパフォーマンスに影響する共通の要因がいくつかあります。

下の表は、移行パフォーマンスに影響を与える一般的な要因の一覧を示しています。詳細については、個別の移行方法に関するセクションで説明します。

 

要因 説明

データ ソース

移行するデータをホストするデバイスまたはサービス。ハードウェア仕様、エンド ユーザー ワークロード、バックエンド保守作業に伴うさまざまな制限がデータ ソースに適用されます。

Google メールでは一定時間に抽出可能なデータ量が制限されています。

データの種類および密度

お客様のビジネスはそれぞれユニークなため、メールボックス内のメール アイテムの種類および各種類の割合は大きく異なります。

それぞれに 10 MB の添付ファイルが付属する 400 アイテムが保存された 1 つの 4 GB メールボックスは、アイテム数が 100,000 未満の 1 つの 4 GB メールボックスよりも移行に時間がかかりません。

移行サーバー

多くの移行ソリューションでは、中継機能を担う移行サーバーまたはワークステーションを使用して移行を実行します。

お客様が、ハイブリッド展開用の MRSProxy やクライアント PC の非ハイブリッド移行をホストするために、低パフォーマンスの仮想マシンを使用していることはよくあります。

移行エンジン

移行元サーバーからデータを取得し、必要に応じてデータを変換し、ネットワーク経由でデータを転送して、Exchange Online メールボックスにデータを挿入するデータ移行エンジン。

Microsoft Exchange の Mailbox Replication サービス (MRS) には、固有の機能および制限があります。

社内ネットワーク アプライアンス

エンド ツー エンド (データ ソースから Exchange Online クライアント アクセス サーバーまで) のネットワーク パフォーマンスが移行のパフォーマンスに影響します。

社内組織でのファイアウォールの構成および仕様。

Office 365 サービス

Office 365 には、移行の負荷を管理するためのビルトイン サポートおよび機能が備わっています。

ユーザー調整ポリシーには既定の設定があり、全体的な最大データ転送レートを制限します。

ここでは、移行中のネットワーク パフォーマンスを向上するためのベスト プラクティスについて説明します。移行中のネットワーク パフォーマンスに対する影響のうち最も大きいものは、サード パーティのハードウェアおよびインターネット サービス プロバイダー (ISP) に関連するため、ここでは一般的な説明にとどめます。

Office 365 ネットワーク分析ツールを展開すると、Office 365 サービスを展開する前にネットワーク関連の問題を分析できます。これらの各インスタンスは、Office 365 のテスト用エンドポイントを使用して特定の地域をテストするように設計されています。

ネットワーク上のクライアント コンピューターから Office 365 サービスへのさらに直接的で綿密なテストを実行するために、Microsoft Exchange Client Performance Analyzer を複数のワークステーションにインストールして、サイレント モードで定期的に実行することができます。

ローカル コンピューター上での Outlook 365 の問題を診断し修正するために役立つ、Microsoft Office 365 用サポート/回復アシスタントをダウンロードできます。

 

要因 説明 ベスト プラクティス

ネットワーク キャパシティ

メールボックスを Exchange Online に移行するのにかかる時間は、ネットワークの利用可能キャパシティおよび最大キャパシティによって決まります。

  • ネットワークの利用可能キャパシティを特定して、最大アップロード キャパシティを判断します。

  • ISP に問い合わせて、割り当て済みの帯域幅を確認し、一定時間に転送可能な合計データ量などの制限の詳細について把握します。

  • ツールを使用して実際のネットワーク キャパシティを評価します。社内データ ソースから Microsoft のデータ センター ゲートウェイ サーバーまでのエンド ツー エンドのデータ フローを必ずテストしてください。

  • ネットワーク キャパシティに影響する可能性があるその他のネットワークに対する負荷 (バックアップ ユーティリティや定期保守など) を特定します。

ネットワークの安定性

ネットワークが高速であれば常に移行が高速になるとは限りません。ネットワークが安定していない場合は、エラー修正が発生するためデータ転送に時間がかかります。移行の種類によっては、エラー修正が移行のパフォーマンスに大きく影響する場合があります。

多くの場合、ネットワークのハードウェアおよびドライバーに関する問題がネットワークの安定性に関する問題を引き起こします。ハードウェア ベンダーと協力してネットワーク デバイスを理解し、ベンダーが提供する最新の推奨ドライバーおよびソフトウェア更新プログラムを適用してください。

ネットワークの遅延

ネットワーク ファイアウォールに構成された侵入検出機能は、大幅なネットワークの遅延を引き起こすことが多く、移行のパフォーマンスに影響します。

Exchange Online メールボックスへのデータの移行は、インターネット接続に依存します。インターネットの遅延は、移行全体のパフォーマンスに影響します。

また、同じ会社内のユーザーが、地理的に離れた場所にあるデータ センターにクラウド メールボックスを所有している場合もあります。お客様の ISP によって、移行のパフォーマンスが異なる可能性があります。

  • 使用する可能性があるすべての Microsoft データ センターとの間のネットワーク遅延を評価して結果が一定であることを確認します (これによりエンド ユーザーに対する安定したパフォーマンスを保証しやすくなります)。ISP と協力して、インターネット関連の問題に対処してください。

  • Microsoft データ センター サーバーの IP アドレスを許可一覧に追加するか、ネットワーク ファイアウォールからのすべての移行関連トラフィックをバイパスします。Office 365 の IP 範囲の詳細については、「Office 365 URL および IP アドレス範囲」をご覧ください。

環境内での移行について詳しく分析するには、移動要求の分析に役立つスクリプトが含まれている、移動分析のブログ投稿 を参照してください。

Office 365 では、セキュリティおよびサービスの利用可能時間を保証するのに役立つ、さまざまな調整メカニズムが使用されます。次の 3 種類の調整が移行のパフォーマンスに影響する可能性があります。

  • ユーザー調整

  • 移行サービス調整

  • リソース正常性ベースの調整

メモメモ:
Office 365 のこれら 3 種類の調整は、すべての移行方法に影響を与えるわけではありません。

ユーザー調整は、ほとんどのサード パーティ製移行ツールおよびクライアントのアップロードによる移行方法に影響を与えます。これらの移行方法では、RPC over HTTP などのクライアント アクセス プロトコルを使用して、メールボックス データを Exchange Online メールボックスに移行します。これらのツールは、通常、IBM Lotus Domino や Novell GroupWise などのプラットフォームからデータを移行する場合に使用されます。

ユーザー調整は、Office 365 における最も制限の厳しい調整方法です。ユーザー調整は個別のエンド ユーザーに対して動作するようにセットアップされるため、アプリケーションレベルでリソースを使用すると調整ポリシーを超過しやすく、データ移行の速度が遅くなります。

移行サービス調整は、すべての Office 365 移行ツールに影響を与えます。移行サービス調整では、Office 365 移行ソリューションにおける移行の同時実行およびサービス リソースの割り当てが管理されます。

移行サービス調整は、次の移行方法を使用して実行される移行に影響を与えます。

  • IMAP 移行

  • Exchange の一括移行

  • 段階的な Exchange の移行

  • ハイブリッド移行 (ハイブリッド環境における MRSProxy ベースの移動)

移行サービス調整の例として、単純な Exchange の移行および IMAP 移行中に同時に移行されるメールボックス数の制御があります。既定値は 10 です。つまり、移行中のどの時点においても移行されるメールボックスの数は最大で 3 つです。移行バッチで同時に移行するメールボックスの数は、Exchange コントロール パネルまたは Windows PowerShell で増やすことができます。この設定を最適化する方法の詳細については、「Exchange Online での移行バッチの管理」を参照してください。

すべての移行方法は利用可能時間の調整により管理されますが、前のセクションで説明した他の種類の調整と比べれば、この Office 365 サービスのための調整が Office 365 の移行に与える影響は限定的です。

リソースのヘルスベースの調整は、最も消極的な調整方法です。サービスが低下してエンド ユーザーおよび重要なサービス操作に影響を与えるような問題が発生した場合にのみ実行されます。

例えば、ハイブリッド移行中にサービス インシデントが発生し、エンド ユーザーのパフォーマンスが低下するレベルまでサービスが低下した場合は、パフォーマンスが回復してサービスが調整のしきい値未満のレベルに戻るまでの間、ハイブリッド移行がキューに登録されます。

次に、サービス調整しきい値を超過したときの Exchange 移行統計レポートのエントリの例を示します。

  • 2012/01/25 12:56:01 AM [BL2PRD0410CA012] コピーの進行状況:723/1456 メッセージ、225.8 MB (236,732,045 バイト)/416.5 MB (436,712,733 バイト)。

  • 2012/1/25 12:57:53 AM [BL2PRD0410CA012] データベース 'NAMPRD04DG031-db081' (エージェント MailboxDatabaseReplication) の DataMoveReplicationConstraint が満たされないため、メールボックス '/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx' の移動が停止しています。失敗の理由:データベース edbf0766-1f2a-4552-9115-bb3a53a8380b は、制約 SecondDatacenter を満たしていません。利用可能な正常なデータベースのコピーがありません。2012/1/25 1:27:53 AM まで待機します。

  • 2012/1/25 12:58:24 AM [BL2PRD0410CA012] 要求は再開し、続行します。

ソリューションとプラクティス

同様の状況が発生した場合は、Office 365 サービスが回復するまで待機します。詳細については、Office 365 ポータル のサービス正常性に関するセクションを参照してください。

ここでは、IMAP による移行、一括移行、段階的な移行方法に影響する要因と、移行のパフォーマンスを向上させるためのベスト プラクティスについて説明します。

次の表では、現在の電子メール組織の移行元サーバーによる移行への影響、および移行への影響を軽減するためのベスト プラクティスについて説明します。

 

チェックリスト 説明 ベスト プラクティス

システムのパフォーマンス

データ抽出は、リソースを集中的に使用するタスクです。移行のパフォーマンスを最善にするには、移行元システムに十分なリソース (CPU 時間やメモリなど) が必要です。多くの場合、移行時の移行元システムは、通常のエンド ユーザーの負荷で限界近くまでキャパシティを利用しています。システム リソースが不足している場合には、移行によって追加の負荷がかかると、エンド ユーザーに影響を与える可能性があります。

パイロット移行テスト時に、システムのパフォーマンスを監視します。システムがビジー状態の場合は、移行の速度が遅くなったり、サービスの利用に問題が発生したりする可能性があるため、特定のシステムに集中した移行をスケジュールしないことをお勧めします。可能であれば、ハードウェア リソースを追加し、タスクやユーザーを移行に関係のない他のサーバーに移動することでシステムの負荷を軽減して、移行元システムのパフォーマンスを高めます。

詳細については、次のトピックを参照してください。

複数のメールボックス サーバーが存在する社内の Exchange 組織から移行する場合は、それら複数のメールボックス サーバーに均等に分散された移行ユーザーの一覧を作成することをお勧めします。個別のサーバーのパフォーマンスに基づいて、この一覧をさらに微調整し、スループットを最大化できます。

例えば、サーバー A のリソースの利用可能時間がサーバー B よりも 50% 長い場合は、同じ移行バッチにおいてサーバー A からのユーザー数を 50% 多くするのが適切です。他の移行元システムに対しても、同様のプラクティスを適用できます。勤務時間後、週末、祝日など、サーバー リソースの利用可能時間が最大になるときに移行を実行します。

バックエンド タスク

移行時に実行されている他のバックエンド タスク。移行は勤務時間後に実行するのがベスト プラクティスなので、社内のサーバーで実行中の他の保守タスク (データのバックアップなど) と競合することがよくあります。

移行中に実行される可能性がある他のシステム タスクを確認します。データの移行は、リソースを大量に消費する他のタスクが実行されていないときに実施することをお勧めします。

注意 社内で Microsoft Exchange を使用しているお客様にとって一般的なバックエンド タスクには、バックアップ ソリューションや 「Exchange ストアの保守」があります。

調整ポリシー

一定時間にシステムから抽出可能なデータ量および抽出速度に対して特定の制限を設定する調整ポリシーを使用して、電子メール システムを保護するのが一般的です。

電子メール システムで展開されている調整ポリシーを確認します。例えば、Google メールでは、一定時間に抽出できるデータの量が制限されています。

Microsoft Exchange のバージョンによっては、(IMAP 移行で使用される) オンプレミスのメール サーバーへの IMAP アクセスや、(Exchange の一括移行や段階的な移行で使用される) RPC over HTTP アクセスを制限するポリシーが存在します。

Exchange 2013 組織の調整設定を確認するには、Get-ThrottlingPolicy コマンドレットを実行します。詳細については、「Exchange ワークロード管理」を参照してください。

IMAP 調整の詳細については、「電子メールを IMAP サーバーから Exchange Online メールボックスに移行する」を参照してください。

RPC over HTTP 調整の詳細については、以下をご覧ください。

IMAP 移行、一括移行、段階的な移行は、クラウドから開始されるデータプル型の移行方法なので、専用の移行サーバーは必要ありません。ただし、インターネットに接続するプロトコル ホスト (IMAP や RPC over HTTP) は、メールボックスおよびメールボックス データを Office 365 に移行するための移行サーバーとして機能します。したがって、前のセクションで現在の電子メール組織のデータ移行元サーバーについて説明した移行のパフォーマンス要因とベスト プラクティスは、インターネット エッジ サーバーにも適用されます。Exchange 2013、2010、2007 組織では、クライアント アクセス サーバーが移行サーバーとして機能します。

詳細については、次のトピックをご覧ください。

  1. Exchange ワークロード管理

  2. Exchange 2010:クライアント アクセス サーバーのカウンター

  3. Exchange 2007:クライアント アクセス サーバーの監視

ソリューションとプラクティス

移行のパフォーマンスを向上させるには、前述したのと同じベスト プラクティスを適用します。

Exchange の IMAP 移行、一括移行、段階的な移行を実行するには、Exchange 管理センター (EAC) Exchange Online の移行ダッシュボードを使用します。このツールは、Office 365 移行サービス調整の対象となります。

ソリューションとプラクティス

お客様は、Windows PowerShell を使用して移行の同時実行数 (同時に移行するメールボックスの数など) を指定できるようになりました。既定値は 20 です。移行バッチを作成した後は、次の Windows PowerShell コマンドを使用してこの数を最大で 100 まで増やすことができます。

Set-MigrationEndPoint <Identity> -MaxConcurrentMigrations <value between 1 and 100>

詳細については、「Exchange Online での移行バッチの管理」を参照してください。

メモメモ:
すべての接続を処理するのに十分なリソースがデータ ソースにない場合は、同時実行数を大きくしないでください。最初は 10 程度の小さい数から始め、エンド ユーザーのアクセスに問題が発生しないようにデータ ソースのパフォーマンスを監視しながらこの数を徐々に増やします。

検証テスト

移行方法に応じて、次の検証テストを実行できます。

  • IMAP 移行 移行元メールボックスに事前にサンプル データを設定します。次に、インターネット (社内ネットワークの外部) から Microsoft Outlook などの標準的な IMAP 電子メール クライアントを使用して移行元メールボックスに接続し、移行元メールボックスからすべてのデータをダウンロードするのにかかる時間を確認して、ネットワークのパフォーマンスを測定します。他に制約がない場合、このスループットは、Office 365 の IMAP 移行ツールを使用した場合のスループットと同様の数値になります。

  • Exchange の一括移行および段階的な移行 移行元メールボックスに事前にサンプル データを設定します。次に、インターネット (社内ネットワークの外部) から RPC over HTTP を使用して Microsoft Outlook で移行元メールボックスに接続します。キャッシュ モードを使用して接続していることを確認してください。移行元メールボックスからすべてのデータを同期するのにかかる時間を確認して、ネットワークのパフォーマンスを測定します。他に制約がない場合、このスループットは、Office 365 の簡易 Exchange 移行ツールを使用した場合のスループットと同様の数値になるはずです。

メモメモ:
実際の IMAP 移行、Exchange の一括移行または段階的な移行時には若干のオーバーヘッドが発生しますが、実際のスループットはこれらの検証テストの結果に近似した数値になるはずです。

Office 365 のリソース正常性ベースの調整は、ネイティブ Office 365 の簡易移行ツールを使用した移行に影響します。「Office 365 のリソース正常性ベースの調整」のセクションを参照してください。

ハイブリッド展開の移行では、社内の Exchange 2003、Exchange 2007、Exchange 2010、Exchange 2013 サーバーと、Office 365 の Exchange Online との間での円滑な移行がサポートされます。

ハイブリッド展開での移行は、メールボックス データを Office 365 に移行する方法の中で間違いなく最速の方法です。 実際のお客様の展開では、最大 100 GB/時間のスループットを確認しています。以下の表に、ネイティブ Office 365 ハイブリッド移行シナリオに適用される要因をリストします。

 

チェックリスト 説明 ベスト プラクティス

システムのパフォーマンス

データ抽出は、リソースを集中的に使用するタスクです。移行のパフォーマンスを向上させるには、移行元システムに十分なリソース (CPU 時間やメモリなど) が必要です。多くの場合、移行時の移行元システムは、通常のエンド ユーザーの負荷で限界近くまでキャパシティを利用しています。移行によって追加の負荷がかかると、システム リソースの不足により、エンド ユーザーのアクセス速度がさらに低下することがあります。

パイロット移行テスト時に、システムのパフォーマンスを監視します。システムがビジー状態の場合は、移行の速度が遅くなったり、サービスの利用に問題が発生したりする可能性があるため、特定のシステムに集中した移行をスケジュールしないことをお勧めします。可能であれば、ハードウェア リソースを追加し、タスクやユーザーを移行に関係のない他のサーバーに移動することでシステムの負荷を軽減して、移行元システムのパフォーマンスを高めます。

詳細については、次のトピックを参照してください。

複数のメールボックス サーバーおよび複数のデータベースが存在する社内 Exchange 組織から移行する場合は、それら複数のメールボックス サーバーおよびデータベースに均等に分散された移行ユーザーの一覧を作成することをお勧めします。個別のサーバーのパフォーマンスに基づいて、この一覧をさらに微調整し、スループットを最大化できます。

例えば、サーバー A のリソースの利用可能時間がサーバー B よりも 50% 長い場合は、同じ移行バッチにおいてサーバー A からのユーザー数を 50% 多くするのが適切です。他の移行元システムに対しても、同様のプラクティスを適用できます。

勤務時間後、週末、祝日など、サーバー リソースの利用可能時間が最大になるときに移行を実行します。

バックエンド タスク

移行時に実行されている他のバックエンド タスク。移行は勤務時間後に実行するのがベスト プラクティスなので、社内のサーバーで実行中の他の保守タスク (データのバックアップなど) と競合することがよくあります。

移行中に実行される可能性がある他のシステム タスクを確認します。データの移行は、リソースを大量に消費する他のタスクが実行されていないときに実施することをお勧めします。

注意 社内で Microsoft Exchange を使用しているお客様にとって一般的なバックエンド タスクには、バックアップ ソリューションや 「Exchange ストアの保守」があります。

ハイブリッド展開の移行は、クラウドから開始されるデータのプル/プッシュ型の移行であり、Exchange 2013 または Exchange 2010 SP3 ハイブリッド サーバーが移行サーバーとして動作します。この点が見落とされて、ハイブリッド サーバーとして性能の低い仮想マシンが使用されることがよくあります。これにより移行のパフォーマンスが低下します。

ベスト プラクティス

前述のベスト プラクティスを適用することに加えて、次のベスト プラクティスを試した結果、実際のお客様の移行において移行のパフォーマンスが向上しました。

  • Exchange 2013 および Exchange 2010 ハイブリッド サーバーには、仮想マシンではなく、強力なサーバークラスの物理コンピューターを使用します。

  • お客様のネットワーク ロード バランサーの背後に配置された複数のハイブリッド サーバーを使用します。

例えば、実際のお客様の移行では、次の構成を使用することによって、一貫して 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 で構成されます。

ハイブリッド展開の移行では、ネイティブ Office 365 ツールを使用します。これは、Office 365 移行サービスの調整の対象になります。

Exchange 2003 と Exchange 2007 SP2、Exchange 2010 SP3、Exchange 2013 SP1 との比較

Exchange 2003 からの移行時のエンド ユーザー エクスペリエンスには、重要な相違点があります。Exchange 2007 SP2、Exchange 2010 SP3、および Exchange 2013 SP1 とは異なり、Exchange 2003 のエンド ユーザーは、メールボックス データの移行中はメールボックスにアクセスできません。したがって、Exchange 2003 を使用しているお客様は、通常、移行をスケジュールする時刻および移行に必要な時間について注意を払う必要があります。特に、メールボックスのサイズが大きい、またはネットワーク速度が遅いなどの理由で移行のパフォーマンスが低い場合には注意が必要です。

また、Exchange 2003 の移行は、中断による影響を大きく受けます。例えば、実際のお客様が 10 GB のメールボックスを移行中に、メールボックスの移行が 50% 完了したところでサービス インシデントが発生しました。この問題を解決するには、データの移行を処理していた Office 365 クライアント アクセス サーバーを再起動する必要がありました。この場合、このメールボックスの移行を最初からやり直す必要がありました。つまり、お客様は 10 GB のデータすべてを再度移行する必要がありました。停止したポイントから移行を再開することはできませんでした。一方、Exchange 2007 SP2、Exchange 2010 SP3、Exchange 2013 SP1 では、中断後に移行を再開できます。

ベスト プラクティス

大規模で重要な Exchange 2003 メールボックスの場合は、2 ホップの移行を選択するお客様もいます。

  • 最初のホップ Exchange 2003 から Exchange 2010 SP3 サーバー (通常は、ハイブリッド サーバー) にメールボックスを移行します。最初のホップはオフラインの移動ですが、通常は、ローカル ネットワークを経由した非常に高速な移行です。

  • 2 番目のホップ Exchange 2010 SP3 から Office 365 にメールボックスを移行します。

2 番目のホップは、オンライン移動で、より優れたユーザー エクスペリエンスとフォールト トレランスを提供します。この 2 ホップのアプローチを使用する場合は、一時的な社内 Exchange 2010 ユーザー メールボックス用に Exchange 2010 ライセンスが必要です。

Mailbox Replication サービス プロキシ (MRSProxy)

MRS プロキシは社内の移行機能であり、Office 365 側で実行される Mailbox Replication サービスと連携して動作します。詳細については、「移動要求について」をご覧ください。

ベスト プラクティス

社内の Exchange 2010 SP3 に対して、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 サービスを開始する」をご覧ください。

メモメモ:
ほとんどのお客様の移行では、既定の MRSMaxConnections 値を変更する必要はありません。移行元サーバーが移行の負荷によって過負荷状態になることを防止する必要がある場合は、接続数を減らすことができます。この設定は、MRSProxy サーバーごとの設定です。お客様が 2 台の MRSProxy サーバーを使用しており、それぞれに 10 の接続を設定した場合、MRSProxy 接続の合計数は 20 (2 x 10) となります。社内 Exchange 2010 組織における MRSProxy サービスの構成の詳細については、「リモート クライアント アクセス サーバーで MRSProxy サービスを開始する」をご覧ください。

検証テスト

Exchange 2013 および 2010 を使用しているお客様は、複数のテスト メールボックスの移行を実行することによって、ハイブリッド移行のネットワーク パフォーマンスをテストできます。または、-SuspendWhenReadyToComplete オプションを指定して実際のユーザー メールボックスを移行し、移行のパフォーマンスについての情報を表示できます。テストが完了したら、エンド ユーザーへの影響がないように移動要求を削除します。

Exchange 2013 の移動要求の詳細については、「New-MoveRequest」を参照してください。

Exchange 2010 の移動要求の詳細については、「New-MoveRequest」をご覧ください。

Office 365 のリソース正常性ベースの調整は、Office 365 ハイブリッド展開の移行を使用した場合の移行に影響します。詳細については、上記 Office 365 のリソース正常性ベースの調整セクションを参照してください。

移動要求の状態情報の取得の概要については、「移動要求のプロパティの表示」を参照してください。

Office 365 サービスでは、移動要求を実行する場合に、通常の社内の Exchange 2010 組織とは重要な違いがあります。Office 365 では、移行キューおよび移行に割り当てられたサービス リソースがテナント間で共有されます。これは、移動プロセスの各段階での移動要求の処理方法に影響します。

Office 365 には、2 種類の移動要求があります。

  • 追加移動要求   お客様の新規の移行は、追加移動要求とみなされます。これらの要求には通常の優先度が設定されます。

  • データ センター内部移動要求   これらはデータ センターの運用チームによるメールボックス移動要求です。これらの移動要求には遅延が発生してもエンド ユーザー エクスペリエンスには影響しないため、低い優先度が設定されます。

  • キューに登録済みの移動要求 この状態は、移動がキューに登録されており、Microsoft Exchange Mailbox Replication サービスによって処理されるのを待機していることを示します。Exchange 2003 の移動要求の場合、この段階ではユーザーは引き続きメールボックスにアクセスできます。

    次の 2 つの要因によって、Mailbox Replication サービスによって処理される要求が決定されます。

    • 優先度   キューに登録済みの移動要求では、高い優先度の移動要求が低い優先度の移動要求よりも前に処理されます。これにより、必ず、データ センターの内部要求の前に、顧客移行移動要求が処理されるようになります。

    • キュー内の位置   移動要求の優先度が同じ場合は、早くキューに登録された要求が優先的に Mailbox Replication サービスによって処理されます。同時に複数のお客様がメールボックスの移行を実行する可能性があるため、新規の移動要求が処理される前にキューにとどまる場合があります。

      多くの場合、メールボックス要求が処理前にキュー内で待機する時間は、移行計画時に考慮されません。このことは、計画したすべての移行が完了するのに十分な時間が割り当てられない原因となります。

  • 処理中の移動要求   この状態は、移動がまだ実行中であることを示します。これがオンライン メールボックス移動である場合、ユーザーはメールボックスにまだアクセスできます。オフラインでメールボックスを移動する場合、ユーザーのメールボックスは使用できません。

    メールボックス移動要求の状態が "処理中" になると、優先度は関係なくなります。新しい移動要求は、高い優先度が設定されている場合でも、既存の処理中の移動要求が完了するまでは処理されません。

計画   前述のように、Exchange 2003 ユーザーはハイブリッド移行中にメールボックスにアクセスできなくなるため、Exchange 2003 を使用しているお客様は、通常、移行をスケジュールする時刻および移行に必要な時間に注意を払う必要があります。

一定時間に移行するメールボックス数を計画する場合は、次の点を考慮します。

  • 移動要求がキュー内で待機する時間を含めます。次の式を使用してこの計算を行います。

    (移行するメールボックスの合計数) = ((合計時間) - (平均待ち時間)) * (移行スループット)

    ここで、移行スループットは 1 時間に移行できるメールボックスの合計数です。

    たとえば、メールボックスを移行するために 6 時間の時間枠があるとします。平均待ち時間が 1 時間で、移行スループットが 1 時間あたり 100 メールボックスの場合、6 時間で 500 のメールボックスを移行できます。式は、500 = (6 - 1) * 100 となります。500 = (6 – 1) * 100.

  • キュー内にとどまる時間の影響を最小限に抑えるために、当初計画した時刻よりも早めに移行を開始します。メールボックスがキューに登録されている場合でも、Exchange 2003 ユーザーは引き続きメールボックスにアクセスできます。

待ち時間の特定   Microsoft はお客様の移行スケジュールを管理していないため、待ち時間は常に変化します。

発生する可能性がある待ち時間を特定するために、実際の移行を開始する数時間前にテストの移動をスケジュールできます。その後、実際に要求がキュー内にとどまった時間に基づいて、移行を開始すべき時刻および一定時間内に移動できるメールボックス数をより正確に推定できます。

たとえば、計画した移行を開始する 4 時間前にテストの移行が完了したとします。テストの移行の待ち時間は約 1 時間だったことを確認します。この場合、すべての移行が時間内に終了するように、最初に計画した時刻よりも 1 時間早く移行を開始することを検討する必要があります。

サード パーティ製ツールは、そのほとんどが、Google Mail、IBM Lotus Domino、Novell GroupWise などの Exchange が関与しない移行シナリオで使用されます。ここでは、実際の製品や移行ツールではなく、サード パーティ製の移行ツールで使用される移行プロトコルに重点を置いて説明します。以下の表に、Office 365 移行シナリオでサード パーティ製ツールに適用される要因をリストします。

 

チェックリスト 説明 ベスト プラクティス

システムのパフォーマンス

データ抽出は、リソースを集中的に使用するタスクです。最適な移行のパフォーマンスを実現するには、移行元システムに十分なリソース (CPU 時間やメモリなど) が必要です。多くの場合、移行時の移行元システムは、通常のエンド ユーザーの負荷で限界近くまでキャパシティを利用しています。システム リソースが不足している場合には、移行によって追加の負荷がかかると、エンド ユーザーに影響を与える可能性があります。

パイロット移行テスト時に、システムのパフォーマンスを監視します。システムがビジー状態の場合は、移行の速度が遅くなったり、サービスの利用に問題が発生したりする可能性があるため、特定のシステムに集中した移行をスケジュールしないことをお勧めします。可能であれば、ハードウェア リソースを追加し、タスクやユーザーを移行に関係のない他のサーバーに移動することでシステムの負荷を軽減して、移行元システムのパフォーマンスを高めます。

詳細については、次のトピックを参照してください。

複数のメールボックス サーバーが存在する社内 Exchange 組織から移行する場合は、それら複数のメールボックス サーバーに均等に分散された移行ユーザーの一覧を作成することをお勧めします。個別のサーバーのパフォーマンスに基づいて、この一覧をさらに微調整し、スループットを最大化できます。

例えば、サーバー A のリソースの利用可能時間がサーバー B よりも 50% 長い場合は、同じ移行バッチにおいてサーバー A からのユーザー数を 50% 多くするのが適切です。他の移行元システムに対しても、同様のプラクティスを適用できます。

勤務時間後、週末、祝日など、システム リソースの利用可能時間が最大になるときに移行を実行します。

バックエンド タスク

通常は、その他のバックエンド タスクが移行中に実行されます。移行は勤務時間後に実行するのがベスト プラクティスなので、社内のサーバーで実行中の他の保守タスク (データのバックアップなど) と競合することがよくあります。

移行中に実行される他のシステム タスクを確認します。リソースを大量に消費する他のタスクが実行されない、データ移行専用のクリーンな時間枠を設けることをお勧めします。

社内で Microsoft Exchange を使用しているお客様にとって一般的なタスクは、バックアップ ソリューションです。詳細については、「Exchange ストアの保守」を参照してください。

調整ポリシー

一定時間内に特定の移行方法を使用してシステムから抽出できるデータ量および抽出速度に対して特定の制限を設定する調整ポリシーを使用して、電子メール システムを保護するのが一般的です。

電子メール システムで展開されている調整ポリシーを確認します。例えば、Google メールでは、一定時間に抽出できるデータの量が制限されています。

Microsoft Exchange のバージョンによっては、(IMAP 移行で使用される) オンプレミスのメール サーバーへの IMAP アクセスや、(Exchange の一括移行や段階的な移行で使用される) RPC over HTTP アクセスを制限するポリシーが存在します。

IMAP 調整の詳細については、「電子メールを IMAP サーバーから Exchange Online メールボックスに移行する」を参照してください。

RPC over HTTP 調整の詳細については、以下をご覧ください。

EWS 調整の構成方法の詳細については、「Exchange 2010: クライアント調整ポリシーについて」をご覧ください。

ほとんどの Office 365 用サード パーティ製ツールは、クライアントから開始され、Office 365 にデータをプッシュします。これらのツールでは、一般的に移行サーバーが必要です。これらの移行サーバーには、システムのパフォーマンス、バックエンド タスク、移行元サーバーの調整ポリシーなどの要因があてはまります。

メモメモ:
一部のサード パーティ製移行ソリューションは、クラウドベースのサービスとしてインターネット上にホストされ、社内移行サーバーを必要としません。

ソリューションとプラクティス

移行サーバーを使用する場合の移行のパフォーマンスを向上させるには、データ ソース サーバーのセクションで説明したベスト プラクティスを適用します。

サード パーティ製移行ツールで使用される最も一般的なプロトコルは、Exchange Web Service および RPC over HTTP です。

Exchange Web サービス

Exchange Web Service (EWS) は、大きなデータ バッチをサポートし、優れたサービス指向の調整が行うため、Office 365 への移行ではこのプロトコルの使用をお勧めします。偽装モードで EWS を使用した Office 365 への移行では、ユーザーに割り当てられた Office 365 EWS リソースは使用されず、割り当てられたリソースのコピーが以下のように使用されます。

  • 同じ管理者アカウントによる EWS 偽装呼び出しはすべて、その管理者アカウントに対する割り当てとは別に計算されます。

  • 偽装セッションごとに、ユーザーの実際の予算のシャドウ コピーが作成されます。この特定のセッションのすべての移行がこのシャドウ コピーを消費します。

  • 偽装に基づく調整はユーザー移行セッションごとに別々に行われます。

ベスト プラクティス

  • EWA 偽装を使用したサード パーティ製移行ツールを使用するお客様の移行のパフォーマンスは、他のテナントによる EWS ベースの移行およびサービス リソースの使用と競合します。そのため、移行のパフォーマンスは場合によって異なります。

  • お客様は、可能な限り EWS 偽装を使用したサード パーティ製移行ツールを使用する必要があります。これらのツールは、通常、RPC over HTTP などのクライアント プロトコルを使用した場合に比べて、より高速で効率的なためです。

RPC over HTTP

従来の多くの移行ソリューションでは、RPC over HTTP プロトコルが使用されています。この方法は、完全に Outlook などのクライアント アクセス モデルに基づいています。また、Office 365 のサービスはアプリケーションではなくユーザーによる使用を前提としてアクセスを調整するため、スケーラビリティおよびパフォーマンスが限定されます。

ベスト プラクティス

  • RPC over HTTP を使用する移行ツールでは、移行サーバーを追加し、複数の Office 365 管理ユーザー アカウントを使用することにより、移行のスループットを上げるのが一般的です。このプラクティスでは、それぞれの管理ユーザーが O365 ユーザー調整の対象となるため、並行してデータを挿入でき、より高いデータ スループットを実現できます。多くの企業のお客様は 20 ~ 30 GB/時の移行スループットを実現するために 40 台以上の移行サーバーをセットアップする必要があったという報告があります。

  • 移行ツールの開発フェーズでは、メッセージを移行するのに必要な RPC 操作の数を考慮することが重要です。このことを説明するため、お客様がメールボックスを Office 365 に移行するために使用した 2 つの (サード パーティ企業によって開発された) サード パーティ製移行ソリューションについて、Office 365 サービスが記録したログを収集しました。サード パーティ企業によって開発された 2 つの移行ソリューションを比較しました。各移行ソリューションにおける 2 つのメールボックスの移行を比較し、Microsoft Outlook の PST ファイルのアップロードとも比較しました。結果は次のとおりです。

     

    メソッド メールボックスのサイズ アイテム数 移行時間 合計 RPC トランザクション数 平均クライアント待ち時間 (ミリ秒) AvgCasRPCProcessingTime (ミリ秒)

    ソリューション A (メールボックス 1)

    376.9 MB

    4,115

    4:24:33

    132,040

    48.4395

    18.0807

    ソリューション A (メールボックス 2)

    249.3 MB

    12,779

    10:50:50

    423,188

    44.1678

    4.8444

    ソリューション B (メールボックス 1)

    618.1 MB

    4,322

    1:54:58

    12,196

    37.2931

    8.3441

    ソリューション B (メールボックス 2)

    56.7 MB

    2,748

    0:47:08

    5,806

    42.1930

    7.4439

    Outlook

    201.9MB

    3,297

    0:29:47

    15,775

    36.9987

    5.6447

    クライアントおよびサービスの処理時間は近い数値ですが、ソリューション A ではデータの移行により多くの RPC 操作を必要としています。それぞれの操作でクライアント待機時間およびサーバー処理時間がかかるため、ソリューション A はソリューション B や Outlook と比較して、同じデータ量の移行にもより長い時間がかかります。

ベスト プラクティス

RPC over HTTP プロトコルを使用するサード パーティ製移行ソリューションでは、次の方法で移行のパフォーマンスを推測できます。

  1. 移行サーバーから RPC over HTTP を使用して Microsoft Outlook で Office 365 メールボックスに接続します。キャッシュ モードを使用して接続していないことを確認してください。

  2. サンプル データを含む大きな PST ファイルを Exchange Online メールボックスにインポートします。

  3. この PST ファイルをアップロードするのにかかる時間を計って、移行のパフォーマンスを測定します。他に制約がない場合、移行のスループットは、RPC over HTTP を使用したサード パーティ製移行ツールを使用した場合のスループットと似た数値になるはずです。実際の移行時にはオーバーヘッドが発生するため、スループットは若干変動する可能性があります。

Office 365 のリソース正常性ベースの調整は、サード パーティ製移行ツールを使用した移行に影響します。詳細については、上記 Office 365 のリソース正常性ベースの調整セクションを参照してください。

 
表示: