Windows Server 2012 以降での AD RMS サーバー上の DB メンテナンスについて

  • Article

こんにちは、RMS サポート 益戸です。

本記事では、AD RMS をご利用いただく中で、データベースのメンテナンス処理を実施する際の注意点について、ご案内します。
AD RMS では、以下の 3 つのデータベースを使用し、サービスを提供しております。

 

• 構成データベース
証明書やクラスター名など、AD RMS が動作する際に必要な情報が格納されます。
• ログ データベース
AD RMS へ接続したユーザー情報等が格納されます。
• ディレクトリ サービス データベース
ユーザーや、電子メールアドレス、SID など、AD RMS がドメインコントローラーより取得したユーザー情報を確認します。

 

AD RMS の機能としては、それぞれのデータベースをメンテナンスする機能は有しておらず、バックアップや、メンテナンス処理などを手動にて作りこむ必要があります。
-> AD RMS では、上記のデータベースをメンテナンスする機能を提供いたしておりません。
そのため、バックアップや削除等、メンテナンス処理を手動にて実装いただく必要がある場合もございます。

この際、Windows Server 2008 R2 環境と、Windows Server 2012 以降の環境にて仕様の差異から意図せずサービスが使用できなくなる状況が発生する可能性がある為、以下に注意点としてまとめました。
ログデータベースの削除の際に、以下の公開情報を参考に、ログデータベースの削除処理を実施しているお客様が多いかと存じます。

 

AD RMS Log Purging Sample
https://technet.microsoft.com/ja-jp/library/dd941624(v=ws.10).aspx

 

Windows Server 2012 以降でも、スクリプトは流用いただく事が可能です。
しかしながら、Windows Server 2008 R2 と Windows Server 2012 では、Message Queuing (MSMQ) service を使用しているかどうかという実装の違いによって、ユーザーへの影響が変わってきます。
具体的には、Windows Server 2008 R2 環境では、メンテナンス最中であっても、ユーザーに対して影響が発生しないのに対して、Windows Server 2012 以降については、メンテナンス中にはサービスが利用できなくなるという影響が発生します。

 

メンテナンスのスクリプトを実行する際に、スクリプト内にて、ログデータベースに対して DELETE の為のロックを取りながら処理を実施します。
その際に、クライアント端末から要求が発生した場合、ロック中のテーブルに対して、UPDATE の為のロックを試み、結果的にデッドロックが発生し、テーブルの情報更新が失敗します。
この際、Windows Server 2008 R2 環境では、MSMQ サービス上に要求を一旦保留し、ロック解除まで AD RMS サーバー側で待機する動作となるため、クライアントからは正常に処理が行われているように見えます。
一方で、Windows Server 2012 以降のAD RMS では MSMQ サービスを使用しない実装と変わった為、クライアント側へ SQL クエリに失敗したというエラーを渡し、要求が失敗します。

 

これは、 MSMQ サービスを使用しない実装となった為、避けることが出来ない事象となります。
そのため、可能な限り、データベースのバックアップやログ削除処理などは、ユーザー影響の少ない夜間や非営業日などにスケジュールすることを推奨しております。
また、上記公開情報のログ削除期間をご利用の環境に合わせて、削除時の時間を調整するなども可能ですので、運用に合わせてカスタマイズしてご利用ください。

 

「AD RMS Log Purging Sample」抜粋

SET @DeleteEndTime = DATEADD(day, -30,  getutcdate())

 

もちろん、一時的なデッドロックでのエラーとなりますので、メンテナンス処理が完了した後は、通常通りご利用いただく事が可能となります。

なお、ログのメンテナンスを実施していない環境においては、サンプルの通りの 30 日指定のまま実施すると、削除対象が多くなるため、処理に時間が掛かる場合がございます。

ログのボリュームによって、定期運用までの削除についても、環境に応じて調整ください。