none
WSUSのDBサイジングについて RRS feed

 > 

  • 質問

  • Question
    サインインして投票
    0
    サインインして投票

     

    はじめまして。
    WSUS3.0SP1の導入を準備しているnyvokと言います。

    導入に際してSQLサーバ2005SP1ExpressEdtionを使いたいと考えていますが、
    DBサイズの上限が4Gbyteということなので、サイズが足りるかどうか気になっております。

    対象台数は2500台です。
    WSUSサーバは複数用意しますが、管理情報を１つの親サーバに集約するつもりです。
    その親サーバが上記のExpressEditionでまかなえるのかどうかご教示頂ければと思います。

    もしDBのテーブル構成と保存している項目のデータサイズがわかれば試算できると考えていますが、そのような情報を提供しているところはないでしょうか。

    図々しいかと思いますが、何とぞよろしく御願いします。

    2008年5月14日 9:41
    |

回答

  • Question
    サインインして投票
    0
    サインインして投票

    nyvok 様

     

    こんにちは、forknife と申します。

     

    鈴木 様も仰っているとおり、WSUS 3.0 (SP1) には「Windows 内部データベース」という容量無制限のデータベースが同伴されます。

     

    このデータベースの特徴を以下にまとめておきます。

    • 管理ツールからアクセス不可 (SQLCMD ユーティリティからのコマンド ベース アクセスは可能)
    • データベース サイズに制限なし
    • 実体は Microsoft SQL Server 2005 Embedded Edition SP2

    WSUS 3.0 SP1 の導入を検討されているとのことですが、以下のご要望が無い限りは「Windows 内部データベース」を利用することをオススメします。

    • SQL Reporting Services を使用したレポートのカスタマイズを行いたい
    • データベースを MSCS クラスタを使用して冗長化したい

     

    また、データベースの容量の想定をされたいとのことですので、データベース内の大半を占めることになるテーブルの情報をお知らせします。

     

    WSUS サーバーはクライアントから状態レポートされるたびにデータベースの tbEventInstance テーブルにレコードを追加します。

    このテーブルには、サーバーの同期履歴、変更履歴、クライアントの状態報告履歴などが格納されます。

    この中でも特に容量を必要とするのが、クライアントの状態報告履歴レコードです。

    既定でクライアントは22時間おきに WSUS サーバーに報告を行いますが、例えばクライアント数が2,500台の場合、約1日に2,500レコード、1ヶ月に75,000レコードが記録されることになります。

    (これは全クライアントが24時間起動しているという極端な状況下での話ですが。)

     

    クライアントの状態報告履歴レコードは、既定で90日間削除されずに保持されるため、この履歴のみで225,000レコードを常に占有することになります。

    ただし既定の設定では、WSUS サーバーが1日に削除できるレコード数が2,000件に制限されているため、225,000レコードに達した後は日々500レコードずつ増え続けていくことになります。

    この問題を回避するには、PowerShell 等を使用して1日に削除できるレコード数の上限を変更するか、または1日に報告されるレコード数が2,000件以下になるようにクライアントを複数の WSUS サーバーに振り分けます。

    nyvok 様は WSUS サーバーを複数ご用意される予定とのことですので、この問題には該当しないかもしれませんが、クライアントの報告頻度を変更する際はご注意下さい。

    なお、私が確認したところ、クライアント状態報告履歴は1レコードあたり約21KBを消費していました。

     

    tbEventInstance テーブル以外のテーブルについては、同期する更新プログラムの種類にも依存しますが、2GB もあれば問題ないかと思います。

    私の環境では以下の更新プログラムを対象として同期を行い、700MB程度のデータベースサイズとなっています。

    • Windows Server 2003
    • Windows XP
    • Office 2003
    • セキュリティ問題の修正プログラム
    • 重要な更新

     

    また、複数の WSUS サーバーを主従構成とし、レポートのロールアップを行った場合は、親サーバーのデータベースに、子サーバー上の全クライアントの最新の状態のみが記録されるため、データベース サイズ増加への影響はほとんどありません。

     

    もしご自身でデータベースの中身を分析されるのであれば、構築した WSUS サーバーのデータベースを SQLCMD ユーティリティを使用してバックアップし、別の SQL Server (Express でも可) にリストアすることで Management Studio から確認することができます。

     

    以上、ご参考まで。

    2008年5月21日 2:18
    |

すべての返信

  • Question
    サインインして投票
    0
    サインインして投票

    nyvok さん、こんにちは。
    フォーラム オペレータの鈴木裕子です

     

    ご希望のような情報がないか、探してみたのですが、
    残念ながら見つかりませんでした。

     

    ただ、
    ↓こちらの技術情報によると、
    WSUSに付属しているデータベースであれば、サイズに制限がないようなので、
    検討されてみては？と思ったのですが。。。。

     

    計画と査定 : Windows Server Update Services (WSUS) を使用する
    手順 3: WSUS に使用するデータベースを選択する
    http://www.microsoft.com/japan/technet/updatemanagement/plan/wsus-step3.mspx

     

    既にご存じで、
    理由あってSQL Server 2005 SP1 ExpressEdtion を想定、
    ということでしたらごめんなさい！

     

    また、どなたか、
    nyvok さんご希望の情報、
    参考になりそうな情報をご存知の方、いらっしゃいましたら、
    コメントいただけるとありがたいです！
    よろしくお願いします。

    2008年5月21日 1:37
    |
    モデレータ
  • Question
    サインインして投票
    0
    サインインして投票

    nyvok 様

     

    こんにちは、forknife と申します。

     

    鈴木 様も仰っているとおり、WSUS 3.0 (SP1) には「Windows 内部データベース」という容量無制限のデータベースが同伴されます。

     

    このデータベースの特徴を以下にまとめておきます。

    • 管理ツールからアクセス不可 (SQLCMD ユーティリティからのコマンド ベース アクセスは可能)
    • データベース サイズに制限なし
    • 実体は Microsoft SQL Server 2005 Embedded Edition SP2

    WSUS 3.0 SP1 の導入を検討されているとのことですが、以下のご要望が無い限りは「Windows 内部データベース」を利用することをオススメします。

    • SQL Reporting Services を使用したレポートのカスタマイズを行いたい
    • データベースを MSCS クラスタを使用して冗長化したい

     

    また、データベースの容量の想定をされたいとのことですので、データベース内の大半を占めることになるテーブルの情報をお知らせします。

     

    WSUS サーバーはクライアントから状態レポートされるたびにデータベースの tbEventInstance テーブルにレコードを追加します。

    このテーブルには、サーバーの同期履歴、変更履歴、クライアントの状態報告履歴などが格納されます。

    この中でも特に容量を必要とするのが、クライアントの状態報告履歴レコードです。

    既定でクライアントは22時間おきに WSUS サーバーに報告を行いますが、例えばクライアント数が2,500台の場合、約1日に2,500レコード、1ヶ月に75,000レコードが記録されることになります。

    (これは全クライアントが24時間起動しているという極端な状況下での話ですが。)

     

    クライアントの状態報告履歴レコードは、既定で90日間削除されずに保持されるため、この履歴のみで225,000レコードを常に占有することになります。

    ただし既定の設定では、WSUS サーバーが1日に削除できるレコード数が2,000件に制限されているため、225,000レコードに達した後は日々500レコードずつ増え続けていくことになります。

    この問題を回避するには、PowerShell 等を使用して1日に削除できるレコード数の上限を変更するか、または1日に報告されるレコード数が2,000件以下になるようにクライアントを複数の WSUS サーバーに振り分けます。

    nyvok 様は WSUS サーバーを複数ご用意される予定とのことですので、この問題には該当しないかもしれませんが、クライアントの報告頻度を変更する際はご注意下さい。

    なお、私が確認したところ、クライアント状態報告履歴は1レコードあたり約21KBを消費していました。

     

    tbEventInstance テーブル以外のテーブルについては、同期する更新プログラムの種類にも依存しますが、2GB もあれば問題ないかと思います。

    私の環境では以下の更新プログラムを対象として同期を行い、700MB程度のデータベースサイズとなっています。

    • Windows Server 2003
    • Windows XP
    • Office 2003
    • セキュリティ問題の修正プログラム
    • 重要な更新

     

    また、複数の WSUS サーバーを主従構成とし、レポートのロールアップを行った場合は、親サーバーのデータベースに、子サーバー上の全クライアントの最新の状態のみが記録されるため、データベース サイズ増加への影響はほとんどありません。

     

    もしご自身でデータベースの中身を分析されるのであれば、構築した WSUS サーバーのデータベースを SQLCMD ユーティリティを使用してバックアップし、別の SQL Server (Express でも可) にリストアすることで Management Studio から確認することができます。

     

    以上、ご参考まで。

    2008年5月21日 2:18
    |
  • Question
    サインインして投票
    0
    サインインして投票

    forknife です。

     

    大変失礼致しました。

    誤記がありましたので以下の通り訂正致します。

     

    >クライアントの状態報告履歴レコードは、既定で90日間削除されずに保持されるため

     

    「クライアントの状態報告履歴レコードは、既定で15日間削除されずに保持されるため」

     

    クライアントのイベントは15日間、サーバーのイベントは90日間となります。

    ※この設定自体は tbConfigurationB テーブルに格納されています。

    2008年5月26日 0:45
    |
  • Question
    サインインして投票
    0
    サインインして投票

    こんにちは、フォーラム オペレータ大久保です。

     

    nyvok さん、forknife さんからいただいた情報ですが、参考になりましたでしょうか？

    forknife さん、非常に詳細で、かつ説得力のある情報ありがとうございます。

    この情報をぜひ有効活用していただきたく、forknife さんの投稿に「回答済み」チェックをつけさせていただきました。

    また、事後報告で恐縮ですが、この投稿は WSUS についての情報ですが「Windows 2003 全般」フォーラムに投稿されておりましたので、大変勝手ながら「Windows Server Update Services 全般 」フォーラムへ移動させていただきました。

    貴重な情報を多くの皆様にご覧いただきたく思いますので、なにとぞご理解くださいませ。

     

    それでは

     

    2008年6月24日 7:06
    |
  • Question
    サインインして投票
    0
    サインインして投票

    forknife様

     

    貴重な意見をいただいたにもかかわらず、長期に返信せず大変失礼しました。

    別のサイトで同じ質問をし、こちらへ投稿していたことを失念しておりました。

     

    実際にパッチのリスト、データをダウンロードし、コンピュータを複数台登録して、容量増加の比率がそれほど高くないということで決着が付きました。

    いただいた意見は今後の参考にさせていただきます。ありがとうございました。

     

    2008年8月30日 6:51
    |