新しい Exchange コア ストア機能
適用先: Exchange Server 2010 SP2
トピックの最終更新日: 2016-11-28
Microsoft Exchange Server 2010 では、Exchange データベース アーキテクチャに対して多くの機能強化が行われています。
パブリック フォルダーのレポート機能が強化されました。
データベースがストレージ グループに関連付けられなくなりました。 ストレージ グループは削除されました。
ストア スキーマと Extensible Storage Engine (ESE) の最適化への投資によって、IOPS が 70% 減少しました。
以下では、これらの機能強化の詳細について説明します。
目次
パブリック フォルダーのレポート機能の強化
データベースの管理
ストアの変更
ESE の新機能
パブリック フォルダーのレポート機能の強化
パブリック フォルダーのレポート機能が強化され、ユーザーによって開始されたパブリック フォルダー内のアイテムに対する変更を表示できるようになりました。 この情報は、Exchange 管理シェルで Get-PublicFolderStatistics コマンドレットを使用すると表示できます。 詳細については、「Exchange 2010 で PowerShell を使用する (Exchange 管理シェル)」を参照してください。
データベースの管理
データベースがストレージ グループに関連付けられなくなりました。 Exchange 2010 では、ストレージ グループの機能はデータベースに移行されました。
Exchange 2010 では、EMC の [組織の構成] ノードで、メールボックスとパブリック フォルダーのデータベースを管理できます (Exchange Server 2007 では、データベースの管理は [サーバーの構成] ノードで行っていました)。
パブリック フォルダー データベースの管理はメール ボックス データベースの管理と共に、[サーバーの構成] ノードから [組織の構成] ノードへ移されましたが、パブリック フォルダー データベースの機能は Exchange 2010 でも変わっていません。 Exchange 2007 と同様、パブリック フォルダー データベースのデータベース コピーを作成することや、パブリック フォルダー データベースをデータベース可用性グループ (DAG) に追加することはできません。 ただし、DAG に含まれるメールボックス サーバーで、パブリック フォルダー データベースをホストすることは可能ですが、ログ配布やその他の DAG の機能は、パブリック フォルダー データベースには適用されません。
データベース コマンドレットの変更
Exchange 2010 ではストレージ グループが削除されたため、Exchange 2007 で使用されていたストレージ グループ コマンドレットは削除され、これらの機能は Exchange 2010 データベース コマンドレットによって提供されるようになりました。詳細は次の表のとおりです。
Exchange 2007 のストレージ グループ コマンドレットに代わる、Exchange 2010 のデータベース コマンドレット
| Exchange 2007 コマンドレット | Exchange 2010 での機能変更の内容 |
|---|---|
New-StorageGroup |
このコマンドレットは削除されました。構成パラメーターは、New-MailboxDatabase および New-PublicFolderDatabase コマンドレットに移行されました。 |
Remove-StorageGroup |
このコマンドレットは削除されました。構成パラメーターは、Remove-MailboxDatabase および Remove-PublicFolderDatabase コマンドレットに移行されました。 |
Set-StorageGroup |
このコマンドレットは削除されました。構成パラメーターは、Set-MailboxDatabase および Set-PublicFolderDatabase コマンドレットに移行されました。 |
Get-StorageGroup |
このコマンドレットは削除されました。構成パラメーターは、Get-MailboxDatabase および Get-PublicFolderDatabase コマンドレットに移行されました。 |
Move-StorageGroupPath |
このコマンドレットは削除されました。構成パラメーターは、Move-DatabasePath コマンドレットに移行されました。 |
Exchange 2007 コマンドレットから機能が拡張された、Exchange 2010 のデータベース コマンドレット
| Exchange 2010 コマンドレット | Exchange 2010 での機能拡張の内容 |
|---|---|
New-MailboxDatabase New-PublicFolderDatabase |
これらのコマンドレットのパラメーターと機能は、New-StorageGroup から拡張されています。 新しいデータベースへのリンクを持つサーバー オブジェクトや、ホスト サーバー名を持つデータベース オブジェクトも更新します。 |
Remove-MailboxDatabase Remove-PublicFolderDatabase |
これらのコマンドレットのパラメーターと機能は、Remove-StorageGroup から拡張されています。 さらに、新しいデータベースへのリンクを持つサーバー オブジェクトや、ホスト サーバー名を持つデータベース オブジェクトも更新します。 |
Set-MailboxDatabase Set-PublicFolderDatabase |
これらのコマンドレットのパラメーターと機能は、Set-StorageGroup から拡張されています。 ホスト サーバーを変更する際、新しいデータベースへのリンクを持つサーバー オブジェクトや、ホスト サーバー名を持つデータベース オブジェクトも更新します。 |
Get-MailboxDatabase Get-PublicFolderDatabase |
これらのコマンドレットのパラメーターと機能は、Get-StorageGroup から拡張されています。 Get-StorageGroupCopyStatus コマンドレットによって現在返される状態の情報を返すよう、Status パラメーターが拡張されました。 |
Move-DatabasePath |
このコマンドレットのパラメーターと機能は、Move-StorageGroupPath から拡張されています。 |
上記のコマンドレットの変更のほか、StorageGroupCopy コマンドレットが削除されています。 詳細については、「メールボックス データベースのコピーの管理」を参照してください。
ストアの変更
Exchange 2010 ではストア スキーマが変更され、サーバー オブジェクト上のメールボックス データベースの依存性が削除されています。 また、新しいスキーマでは、情報を格納するテーブルのリファクタリングを行って、データベースの 1 秒あたりの入出力数 (IOPS) を減少できるよう、強化されています。 テーブルのリファクタリングによって、論理的な連続性と参照の局所性を向上できます。 これらの変更によって、ESE が維持するセカンダリ インデックスへのストアの依存度を抑制します。 この結果、ストアが、セカンダリ インデックスに関連するパフォーマンス上の問題の影響を受けにくくなります。
また、ストアの復元性と正常性は、エラーの検出と修正および警告の通知に関連するいくつかの機能追加によっても向上しています。
問題のあるメールボックスに対するメールボックス検疫
領域が 1 GB 未満のデータベースに対するトランスポート遮断
スレッド タイムアウトの検出と報告
ストアの復元性と正常性の詳細については、「Exchange 2010 のストアについて」を参照してください。
コア ストア機能には、高可用性機能を強化するために多くの変更が行われています。 高可用性機能は Exchange 2010 のコア アーキテクチャに統合され、規模や業種を問わずすべての組織において、メッセージング継続性サービスを経済的に展開できます。 Exchange 2010 の高可用性に関する変更の詳細については、「高可用性とサイトの復元について」を参照してください。
ESE の新機能
Extensible Storage Engine (ESE) は、Exchange 2010 において、以下の目標を実現するために強化されています。
入出力サイズを大きくし、連続した入出力による IOPS の減少
市販ストレージ向けの最適化
データベース管理の低減
オンラインでの最適化
オンラインでのデータベース スキャン
サイズが大きく連続した入出力
Exchange 2010 では、入出力サイズを大きくして読み取りや書き込みの頻度を少なくすることで、ESE のパフォーマンス向上を可能にしています。 また、ESE のパフォーマンスは、データベース内のデータの連続性を高めることによっても向上できます。データの連続性が高いと、関連するデータが、B ツリー内の同じ近接領域に存在する確率が高くなります。
Exchange では、データベース内のデータはすべて B ツリーに格納され、B ツリーは複数のページに分割されます。 Exchange 2007 以前では、B ツリーに格納されたデータは連続的ではありませんでした。 実際、Exchange の以前のバージョンでは、データベースに対してランダムな読み取りと書き込みが実行されていました。 つまり、関連するデータがハード ディスクの同じ近接領域に存在しないことがあります。 データが連続していない場合、ハード ディスクの読み取りと書き込みに、より多くの入出力処理が必要です。
B ツリーの最適化
B ツリー内のデータの連続性を維持して入出力処理を削減するため、B ツリーの最適化処理が強化されています。
B ツリーの最適化は、次の 3 つの新しい操作により、(新しい B ツリーを作成してインデックスとテーブルの名前を変更するのではなく) インプレースで実行されます。
ページ移動 ページ移動は、1 つのページから新しく割り当てられたページへの、すべてのデータの移動によって構成されます。
部分的左マージ 部分的左マージは、データが左ページから右ページへ移動されること以外は、Exchange 2007 以前の右マージと同じです。
全体左マージ 全体左マージは、Exchange 2007 以前の全体右マージと同じです。
パフォーマンスを最適化するため、最適化は右マージから左マージに変更されました。 データの読み取りや書き込みは、ハード ディスクの右から左へ実行されます。 データベースの最適化が読み取りや書き込みと同じ方向で実行される場合、最適化と読み取りや書き込みが競合します。 また、領域の割り当てによって、次のページには割り当てを追加できますが、前のページには追加できません。 ページ移動には新しいページの割り当てが必要なため、左から右へのデータベースの最適化は大きな効果があります。
最適化マネージャーは、最適化が必要な B ツリーと、既に最適化されている B ツリーを監視する、ESE の新しいイベントです。 最適化マネージャーは、最適化が必要な、マウントされているすべてのデータベースの B ツリーの一覧を収集します。 断片化している B ツリーを検出すると、それらの B ツリーは最適化マネージャーに登録され、最適化マネージャーによって処理されます。
ページ サイズが 32 KB に増加
データベース内のデータはすべて B ツリーに格納され、B ツリーは複数のページに分割されます。 ページ サイズは、データベースの読み取りおよび書き込みの最小サイズで、データベースのキャッシュに使用するユニット サイズでもあります。 ディスクからの読み取りはメモリ内で処理を実行する場合に比べて低速であるため、ページ サイズが 32 KB に増えたことによって、ESE で IOPS を削減でき、メモリでキャッシュするページのサイズが大きくなることでパフォーマンスが向上します。
市販ストレージ向けの最適化
Exchange 2010 の ESE のもう 1 つの目標は、Exchange の展開にかかる初期コストと運用コストを削減することです。 これは、ストレージ コストの抑制と、JBOD および SATA クラスのハードディスクを使用する市販のストレージ向けの最適化を行うことによって実現できます。
ディスク サブシステムはより少ない回数でより大きな容量の入出力を処理するほうが効率的です。Exchange 2010 以前の場合、ページ サイズは最小の読み取り/書き込みサイズであり、最小のデータベース キャッシュ サイズです。 入出力の統合とは、データベース ページ操作を 1 つの入出力操作にまとめることを言い、これによって、低頻度で大容量サイズの入出力操作を生成できます。
入出力の統合による平均データベース入出力サイズの増加には、次のメリットがあります。
ディスクの使用効率の向上 大容量サイズの入出力を処理することで、ディスクを効率よく使用できます。 ディスクの使用効率が向上すると、そのディスクでより多くのメールボックスをホストできます。
キャッシュ ウォーミング率の向上 キャッシュ ウォーミングは、データベースが前回起動されたときにデータベースに対して実行された初期クエリを事前に読み込むことで、実行時間を短縮できるようにする処理です。 サーバーの再起動、フェールオーバー、またはスイッチオーバー後、サイズの大きな入出力によって、ESE でキャッシュ ウォーミング率を増やすことができます。
データベースの保守
Exchange 2010 の ESE の最後の目標は、データベースの保守と管理にかかるコストを削減することです。 データベースの保守は、メールボックス データベースの整合性を管理および維持する、いくつかのタスクによって構成されています。
データベースの保守は、次のように分けられます。
ストア メールボックスの保守
ESE データベースの保守
Exchange 2007 では、ESE データベースの保守において、ディスクが集中的に使用されていました。 Exchange 2010 では、パフォーマンスを向上するための強化が行われています。 Exchange 2010 では、サイズが大きく負荷が非常に高いプロファイル サーバーにおいて、ESE データベースの保守ではサイズの大きい Exchange 2007 データベース (2 GB のクォータ) を完了するのに通常 1 晩あたり 6 ～ 8 時間かかるのに対し、ストア メールボックスの保守作業では約 45 分間しかかかりません。
Exchange 2010 では、サイズが大きいメールボックスのほか、JBOD ストレージや RAID を使用しないストレージもサポートするよう改善されています。
注意
Exchange ストア集中型のオンライン データベース保守機能 (回復アイテムのクリーンアップなど) は、Exchange 2007の場合と同様に、Exchange 2010 でも同様です。 ESE 機能、オンラインでの最適化、およびデータベース チェックサムのみ変更されています。
データベースの最適化
最適化により、Exchange データベースの内部ページが連続化します。 最適化は、データベースがオンラインの場合にシステムによって自動的に実行することもできれば (オンライン最適化)、データベースがオフラインのときに管理者が手動で実行することもできます (オフライン最適化)。
オンラインでの最適化
Exchange 2010 では、オンラインでの最適化のアーキテクチャが変更されています。 オンラインでの最適化は、メールボックス データベースの保守処理対象から外されました。 現在では、オンラインでの最適化がバックグラウンドで常時実行されるようになっています。オンラインでの最適化が常時実行されるため、Exchange が、データベース内の空白領域の量を示すためのイベントをイベント ログに送信することはありません。 バックグラウンドのデータベース保守時に、データベースから削除するようにマークされたアイテムが削除され、データベース ページが解放されます。 空白領域の割合は、継続的なオンライン最適化プロセスの効果によって常に変化しています。
データベース内の空白領域の量は、データベース内にメールボックスがあるユーザーが送受信したメールの容量を確認して見積もることができます。たとえば、データベース内に 2 GB のメールボックスが 100 個存在し (合計 200 GB)、ユーザーが 1 日に送受信するメールが平均 10 MB の場合、空白領域は約 1 GB (100 メールボックス × 1 メールボックスあたり 10 MB) です。 バックグラウンドのデータベース保守ですべての処理を完了できない場合は、空白領域の量がこの見積りよりも大きくなる可能性があります。
この機能に関して、設定を構成する必要はありません。 Exchange は、データベースを使用中に監視し、小さな変更を継続的に行って、領域と連続性が保たれるようにデータベースを最適化します。 データベースでは、ページの範囲を分析して本来の連続性がないことを検出すると、非同期スレッドを開始して B ツリーまたはテーブルのセクションを最適化します。 オンラインでの最適化は、クライアントのパフォーマンスに悪影響が出ないようにするためにも調整されます。
ESE パフォーマンス カウンター セット MSExchange Database ==> Defragmentation Tasks を使用して、実行されているタスクを表示できます。 詳細については、「拡張された ESE パフォーマンス カウンターを有効にする方法」を参照してください。
オフラインでの最適化
オフラインでの最適化は、データベースがマウント解除 (オフライン) 状態のときに管理者によって実行される手動プロセスです。 このプロセスでは、ESEUTIL ツールを使用して、データベース ファイルの読み込みと、コンテンツを使用した新しいデータベース ファイルの書き込みが継続的に実行されます。 オフラインでの最適化プロセスは、元のデータベースの空白領域をコピーしないため、新たに作成されたデータベース ファイルのサイズはディスク上の元のデータベースより小さくなります (データベースの空白領域の量によってはかなり小さくなる可能性があります)。 これまでデータベースのオフラインでの最適化が実行されてきた一般的な理由は、次のとおりです。
ディスク上のデータベース ファイルのサイズを縮小するため
データベース内の空白領域を再構築するため
空きディスク領域の不足を避けるため
破損したデータベースを修復するため (ESEUTIL /p に続く修復の第 2 ステップ)
オフラインでの最適化は Exchange データベースの定期的な保守の一部ではありません。これまでかなりの期間、Microsoft は定期的かつプロアクティブにデータベースのオフラインでの最適化を実行しないように推奨してきました。このことは以下を含むさまざまな理由から推奨されています。
データベースをオフラインにする必要があるため、結果的にダウンタイムが生じます。
レプリケートされたメールボックス データベース環境では、オフラインで最適化されたアクティブ コピーのすべてのパッシブ コピーを再シードする必要があり、さらに、オフラインで最適化されたあらゆるパッシブ コピーを再シードする必要があります (そのため、パッシブ データベース コピーのオフラインでの最適化は避ける必要があります)。
結果として、新しいデータベースの署名で新しいデータベースが作成されるため、オフラインでの最適化より前のデータベースのバックアップからログ ファイルを復元することができなくなります。
オフラインでの最適化の代替として、顧客が新しいデータベースを作成し、メールボックスを新たに作成されたデータベースに移動することが推奨されています。 Exchange 2010 環境では、メールボックスは、エンド ユーザーへのサービスを中断することなくオンラインで移動されます。 さらに、すべてのメールボックスを既存のデータベースから新しいデータベースに移動した場合も、最終的な結果は同じです。つまり、 継続的に書き込まれるページを持ち、データベース ファイルに大量の空白領域のない最適化されたデータベースとなります。 プロセスの完了後は、古い (現在は空の) データベースを削除するだけです。このガイダンスは、空白領域を再構築するためのプロアクティブなオフラインでの最適化についてのみ説明しています。 Microsoft カスタマー サポート サービスから指示があった場合は、引き続き最適化を実行する必要があります。
オンラインでのデータベース スキャン
オンラインでのデータベース スキャン (データベース チェックサムとも言います) も変更されています。 Exchange 2007 Service Pack 1 (SP1) では、オンラインでの最適化にかかる時間の半分を、(Exchange が特定の時間内にデータベースの全ページを読み取って破損を検出できるようにするための) データベース スキャン処理に使用するオプションを選択できました。
Exchange 2010 では、オンライン データベース スキャンは、データベースをチェックサム検査し、Exchange 2010 ストアのクラッシュ後の処理を実行します。 領域では、クラッシュによってリークが発生する可能性があり、オンラインでのデータベース スキャンでは、失われた領域を検出して回復します。 Exchange 2010 のシステムは、すべてのデータベースが 7 日に一度完全にスキャンされることを想定して設計されています。 この時間枠でデータベースがスキャンされないと、警告イベントが発生します。 Exchange 2010 では、アクティブなデータベース コピーに対するオンラインでのデータベース スキャンを、2 つのモードで実行できるようになりました。
スケジュールされたメールボックス データベースの保守処理の最後のタスクとして実行します。 メールボックス データベースの保守スケジュールを変更することで、どのくらい実行するかを構成できます。 このオプションは、完全なスキャンの終了に要する時間が短い 1 TB 未満の小サイズのデータベースの場合に使用できます。
バックグラウンドで常時実行します。これは既定の動作です。 このオプションは、あらゆるサイズのデータベースで有効ですが、大容量のデータベース (サイズが 1 ～ 2 TB) で使用することをお勧めします。 Exchange がデータベースのスキャンを 1 日に複数回行うことはありません。 この読み取り入出力は完全に連続的に行われ (ディスク上で実行しやすい)、ほとんどのシステムにおいて約 5 MB/秒のスキャン速度に相当します。
データベースの保守の構成の詳細については、「メールボックス データベースの保守」を参照してください。
© 2010 Microsoft Corporation.All rights reserved.