次の方法で共有

容量計画 – データベースを正常でマウントされた状態に維持するためのトランザクション ログ領域の重要性

  • [アーティクル]

原文の記事の投稿日: 2011 年 11 月 9 日 (水曜日)

以前、サポータビリティ プログラム マネージャーの Nino Bilic とチャットしているときに、ちょっと気がかりなことを聞きました。つまり、プレミア カスタマーが Exchange 2010 で重大な状況になる第 1 の理由は、トランザクション ログ LUN でのディスク領域の不足によるメールボックス データベースのマウント解除だというのです。

そのことについてしばらくじっくり考えてみました。当然のことながらびっくりしました。正直に言えば、私は Mailbox Requirements Calculator と TechNet でのガイダンスについて考えたことがあり、この問題は今頃はもう解決していたはずなのです。この情報を共有した後で、(彼ではなく) この私がトランザクション ログの容量計画に関するブログ記事を書くことになりました (ありがとう、Nino!)。

容量計画 101

トランザクション ログの LUN のサイズを適切に決定するには、環境についていくつかのことを理解する必要があります。

  1. データベースに作成されるメールボックスの数
  2. データベース内のメールボックスのメッセージ プロファイル
  3. メッセージの平均サイズ
  4. メールボックスの平均サイズ
  5. 1 日に移動されるメールボックスの数
  6. バックアップと復元のソリューション
  7. ネットワーク障害など、他の障害シナリオをソリューションで考慮する必要があるか

この説明では、各データベースに 250 のメールボックスが格納されるものとします。各メールボックスは毎日 150 のメッセージを送受信し、メッセージの平均サイズは 100KB であるものとします。「メールボックス データベースおよびログの容量の要因について」の表によると、150 のメッセージ プロファイルと 75 KB の平均メッセージ サイズでは、1 日 (24 時間) あたり 30 のトランザクション ログが生成されることがわかります。ここでのメッセージ サイズは 75 KB より大きいので、メールボックス生成ごとのトランザクション ログではそのことを考慮する必要があります。ガイダンスでは次のように規定されています。

メッセージの平均サイズが 2 倍の 150 KB になった場合、メールボックスごとに生成されるログは 1.9 倍に増えます。この値は、添付ファイルとメッセージ テーブル (メッセージ本文と添付ファイル) を含むデータベースの割合を表します。

したがって、100 KB の平均メッセージ サイズによる影響は、次の式で求めることができます。

150 / 1.9 = [プロファイルの平均メッセージ サイズ] / x

x = (100 * 1.9) / 150

x = 1.266666666666667 ~ 1.27

つまり、メッセージのサイズが基準より 25 KB だけ大きいと、1 つのメールボックスで 1 日に生成されるトランザクション ログの数は、1.27 倍に増加します。したがって、"30 トランザクション ログ * 1.27 = 39 トランザクション ログ/日/メールボックス" となります。これは、250 メールボックスのデータベースの場合は、各データベースで "39 * 250 = 9,750 メールボックス生成トランザクション ログ/日/データベース" となることを意味します。

メールボックスの移動によっても、トランザクション ログが生成されます。移動先のデータベースに移動されるメールボックスごとに、メールボックスのサイズ (回復可能なアイテム フォルダーの内容を含みます) にほぼ匹敵するログが (移動元ではなく移動先に) 生成されます。たとえば、1 日に 1% のメールボックスが移動されると、データベースに移動されるメールボックスは毎日 2.5 個になります。各メールボックスの平均サイズが 5.4 GB とすると (1 つのアイテムの回復が有効な状態で 14 日間の削除済みアイテムの保持を含みます)、"2.5 * 5.4 GB/1024 = 13,888 メールボックス移動トランザクション ログ/日/データベース" となります。

バックアップ/復元の観点からは、使用するバックアップ アーキテクチャの種類を考慮する必要があります。バックアップのシナリオごとに、メールボックス生成トランザクション ログの容量の観点から準備する必要のある、推奨される追加日数があります。余分な領域を用意することで、停止状態に苦しめられずに複数の障害に耐えることができます。トランザクション ログの切り捨ての詳細については、「バックアップ、復元、および障害復旧について」を参照してください。

  トランザクション ログの切り捨て 推奨されるバックアップ障害保護
毎日の完全バックアップ 毎日 3 日
毎週の完全バックアップ/毎日の増分バックアップ 毎日 3 日
毎週の完全バックアップ/毎日の差分バックアップ 毎週 7 日
2 か月ごとの完全バックアップ/毎日の増分バックアップ 毎日 3 日
Exchange のネイティブデータ保護 ログが不要になったとき 3 日

当然のことながら、他にも考慮する必要のあるシナリオがあります。たとえば、2 つのデータセンターにまたがるデータベース可用性グループ (DAG) を展開している場合は、2 つのデータセンター間のネットワーク リンクが機能していて、データベースのコピーが正常な場合にのみ、ログの切り捨てが行われます。WAN リンク停止の修復に 5 日かかることがわかっている場合は、それを考慮してバックアップ障害保護を調整する必要があります。

このブログのシナリオでは、切り捨ての障害に 3 日だけ耐えられるようにすればよいものとします。つまり、メールボックス生成トランザクション ログのために必要なディスク領域は、9,750 / 1024 * 3 = 28.5 GB です。

さらに、1 週間のメールボックス移動イベントのために必要なディスク領域を考慮する必要があります。このブログのメールボックス移動操作の場合は、13,888 / 1014 * 7 日 = 94.9 GB です。

まとめると、トランザクション ログのために各データベースで必要なディスク領域は 123 GB です。また、説明されてはいなくても発生する可能性のある状況を考慮して、データ オーバーヘッドの要素を含める必要があり、トランザクション ログのディスク領域は 123GB * 1.2 = 148 GB になります。

トランザクション ログに専用の LUN を展開し、LUN に 150 GB 確保しないと、バックアップの障害が発生して多くのメールボックス移動が行われた場合、ディスク領域をすべて使用してしまう可能性があります。通常は、ディスク容量の 80% だけが使用されるように、各 LUN を準備します。その場合の式は次のようになります。

LUN 領域 = [予想されるディスク領域使用量] / (1 – [望ましい空き領域の割合])

LUN 領域 = 148 GB / (1 – 0.2) = 148 GB / 0.8 = 専用トランザクション ログ ボリュームに 185 GB の LUN

データベースと同じ LUN にトランザクション ログを展開する場合は、トランザクション ログに必要なディスク領域とデータベースに必要なディスク領域を単純に加えて、[予想されるディスク領域使用量] の値を求めます。

トランザクション ログのディスク領域がすべて消費されるのを防ぐ方法

まず最初に、環境の基準値を求めて、標準的な 1 日あたりのログ生成量を特定する必要があります。さらに、監視機能を設定し、警告が発生した場合にはそれに対処する必要があります。監視機能では次のシナリオを監視する必要があります。

  1. トランザクション ログ LUN のディスク領域。複数のしきい値と複数の異なる警告メカニズムを設定します。ディスク消費が 90% になったことを示す警告が最初に出るようではいけません。標準的なログ生成基準がわかっていれば、たとえば 20% 超過した場合に報告されるようにしきい値を設定できます。
  2. バックアップの正常な完了を監視します (Exchange のネイティブ データ保護を利用していない場合)。ディスク領域に空きがなくなってから初めてバックアップ障害が示されるのでは困ります。
  3. アプリケーション ログの切り捨てイベントを監視します。
  4. データベース コピーの複製の状態を監視します。

トランザクション ログで原因不明の拡大が発生する場合の対処

友人の Mike Lagase が、https://blogs.technet.com/b/mikelag/archive/2009/07/12/troubleshooting-store-log-database-growth-issues.aspx (英語) でこのシナリオのトラブルシューティング方法について優れた記事を書いています (この記事は Exchange 2007 について書かれており、一部のツールや推奨事項は Exchange 2010 には該当しないことに注意してください)。Mike が示している手順に加えて、Exchange 2010 では以下の方法を使用して、トランザクション ログの原因不明の拡大を判別できます (この一覧の作成に協力してくれた Todd Luttinen に感謝します)。

  1. ストア使用統計情報コマンドレット (get-StoreUsageStatistics で DigestCategory = ‘LogBytes’ を指定) を使用して、生成されているログのバイト数が多いメールボックスを識別できます。この方法は、ログの内容がメールボックス所有者によって生成されていない場合、または操作がクライアントの代わりに実行されていて (CopyOnWrite など)、システム サービスによって生成されたログの内容が含まれない場合 (イベント ID 9826 で報告されます) には、うまくいかない場合があることに注意してください。これらの統計情報では、ログ アクティビティの生成が多い上位のメールボックスについて (過去 1 時間を対象とする最大 6 サンプル)、過去 10 分間のアクティビティの概要が示されます。次に示すのは、ストア使用統計情報を使用して、過去 1 時間にログを大量に生成した上位のメールボックスを見つける方法です。

    [PS] C:\>$stats = Get-StoreUsageStatistics –Database <Database Name>
    [PS] C:\>$stats | ? {$_.DigestCategory -eq 'LogBytes'} | group MailboxGuid |sort count -Descending | Select -first 1 -ExpandProperty Group | sort SampleTime | ft -a MailboxGuid,Sample*,Log*

    MailboxGuid SampleID SampleTime LogRecordCount LogRecordBytes
    c007c87a-e030-4414-b741-9cf61e88b9de 5 11/7/2011 4:25:05 PM 237 274163
    c007c87a-e030-4414-b741-9cf61e88b9de 4 11/7/2011 4:35:05 PM 451 387362
    c007c87a-e030-4414-b741-9cf61e88b9de 3 11/7/2011 4:45:06 PM 483 144999
    c007c87a-e030-4414-b741-9cf61e88b9de 2 11/7/2011 4:55:06 PM 734 293433
    c007c87a-e030-4414-b741-9cf61e88b9de 1 11/7/2011 5:05:06 PM 933 411485
    c007c87a-e030-4414-b741-9cf61e88b9de 0 11/7/2011 5:15:06 PM 247 209987

  2. 管理クライアントに対して生成されるアプリケーション イベントもあります (イベント ID 9826)。これらの統計情報は、2 時間のアクティビティを表します。

    Starting from <date/time> service <name> has performed this activity on the server:
    RPC Operations: 24168.
    Database Pages Read: 1329 (of which 629 pages preread).
    Database Pages Updated: 12418 (of which 11555 pages reupdated).
    Database Log Records Generated: 13906.
    Database Log Records Bytes Generated: 660331.
    Time in Server: 19142 ms.
    Time in User Mode: 6100 ms.
    Time in Kernel Mode: 63 ms.

  3. パフォーマンス モニターのカウンター "MSExchangeIS Client(*)\JET Log Record Bytes/sec" を使用すると、ログの拡大の原因になっているクライアントの種類を識別できます。

データベースの可用性が影響を受けないように十分な領域を用意することの重要性は誰でも理解していると思います。トランザクション ログ容量の計画にこの情報が役立つことを期待します。

Ross Smith IV
プリンシパル プログラム マネージャー
Exchange カスタマー エクスペリエンス

これはローカライズされたブログ投稿です。原文の記事は、「Capacity Planning – Yes Transaction Log Space is Critical to Keeping your Databases Healthy and Mounted」をご覧ください。