- 連載第1回 「社内のWindows更新処理を集中管理、「WSUS 3.0」とは」
- 連載第2回 「Windows Updateの管理を効率化する「WSUS」導入手順の基本」
より複雑な環境でWSUSを利用するための設計方針
前回は基本的な構成を持つWSUSを構築して、更新プログラム管理を行うまでの一連の手順を紹介しました。第3回となる今回は、より複雑な環境でWSUSを利用するための設計の考え方を、ケーススタディ形式で紹介します。
- ケースA: さまざまな拠点を持つ環境にWSUSを導入する
- ケースB: インターネットや社内ネットワークに接続できない環境にWSUSを導入する
- ケースC: 大規模環境に適合するWSUSサーバーを構築する
- ケースD: WSUS 2.0からアップグレードする
ケースA: さまざまな拠点を持つ環境にWSUSを導入する
シナリオ
A社は東京に本社を置く1,000人規模の企業です。本社以外にも大阪と名古屋に支社があり、それぞれが本社と接続するWAN回線を持っています。
| 拠点名 | PC台数 | 概要 |
|---|---|---|
| 東京本社 | 800台 | 約700名の社員が在籍している最大拠点で、主要な業務サーバーも本社内で稼動している。 全社を管理するITシステム管理者はここに在籍している。 |
| 名古屋 | 150台 | 東京とは100MbpsのWANで接続されているが、業務時間帯におけるWANトラフィックに遅延が発生している点が問題となっている。 また常駐のIT管理者が存在せず、通常は本社のIT部門がリモート管理を行っている。 |
| 大阪 | 200台 | 東京とは1GbpsのWANで接続されている。 専任のIT管理者が在籍しており、更新プログラム管理は独自に行いたいという要望がある。本社としてはこれを認める方針だが、更新プログラムの適用状態は一元的に把握できるようにしたいと考えている。 |
上記のような環境を持つA社では、クライアントPCの更新プログラム管理を確実に行う手段として、全社でWSUSを採用することを検討しています。
現状と課題
WSUSの設計に入る前に、A社の現状と課題を確認していきましょう。
まず東京本社に関してはややPC台数が多いものの、全体を統括するIT管理者がいること、さらに他のサーバーの多くも本社に設置されている現状を考えると、ここにWSUSサーバーを導入することに大きな問題はないでしょう。
次に名古屋ですが、現状で業務時間帯におけるWANトラフィックに遅延が発生していることから、できる限りWANを利用したトラフィックを発生させるのは避けたいところです。
最後に大阪を確認します。この拠点は本社と1GpbsのWAN回線で接続されているため十分な帯域幅があります。しかし本社に設置するWSUSサーバーからWAN経由で200台のクライアントへ更新プログラムを配信するのは、あまりよい手段であるとはいえません。さらに大阪には更新プログラム管理を独自に行いたいという要望があり、これを満たす方法を検討する必要があります。
設計のポイント
それではここから、上記のような環境にWSUSを導入するための設計のポイントを解説していきます。
ポイント1： できるだけシンプルな構成を検討する
WSUSに限らず、システムは可能な限りシンプルなものにすることが推奨されています。シンプルな構成は導入費用の観点だけではなく、運用面から見ても結果として最も効率的なものになることが多いためです。
WSUSの設計で最もシンプルな構成は、一台のWSUSサーバーですべてのクライアントを管理する構成です。A社の場合、ネットワークですべて本社とつながっているため、本社にWSUSサーバーを導入すれば技術的にはこの構成を採用することができそうです。
ポイント2： WANをまたぐ場合は、子WSUSサーバーの設置を検討する
しかしこの場合、名古屋や大阪からはそれぞれのクライアントが東京のWSUSサーバーにアクセスして更新プログラムをダウンロードすることになるため、相当のWANトラフィックを発生させることになります。特にWANの帯域幅が問題となっている名古屋では、ネットワークへの悪影響が懸念されます。
そこでWSUSの機能の一つである「WSUSサーバー間の階層構造」を利用して、地方拠点にWSUSサーバーを追加導入することを検討します。
各拠点にWSUSサーバーを設置した場合、クライアントはそれぞれの拠点内にあるサーバーから更新プログラムをダウンロードできるようになるため、WANトラフィックを極小化することができます。たとえばA社の名古屋拠点には150台の端末がありますが、拠点WSUSサーバーを設置した場合はWANを越えた更新プログラムの取得が一度（WSUSサーバー間）で済むようになるため、単純計算ではWANトラフィックを150分の1にまで抑えることになります。
なおWSUSサーバー間で同期を行う日時は、WSUSサーバーオプションで指定することができます。トラフィック使用量の少ない夜間に実行するように構成すれば、業務時間帯ネットワークへの影響を回避することが可能です。
ポイント3： 管理上の境界を分けたい場合は、子WSUSサーバーを設置する
次に大阪拠点のケースを考えてみます。大阪・東京間のWAN帯域幅は1Gpbsと太く、ネットワーク上は大阪にWSUSサーバーを設置しなくても対応可能かもしれません。しかしWANはWSUSで占有できるものではないため、できる限り使用帯域幅を節約するために拠点WSUSサーバーを配置することが望まれます。
さらに大阪では、更新プログラム管理を拠点独自で実施したいという要件があります。WSUSはコンピュータグループ単位で更新プログラムを配信するなどの機能があるため、ある程度はサーバーを分割しなくても管理を分離させることができます。とはいえ、拠点管理者に付与するアクセス権が高いものになってしまったり、WSUSサーバー単位で構成する一部の設定を拠点ごとに変更することができなかったりと、いくらかの制約が発生します。
そこでより柔軟に管理境界を作る方法として、拠点ごとにWSUSサーバーを設置するという案が考えられます。地方拠点に子WSUSサーバーを導入し、さらに親WSUSサーバー（アップストリームサーバー）から設定を引き継がないように構成すれば、今回の要件である拠点での独自管理を実現させることができます。
また更新プログラムの適用状態を示すインベントリ・レポートに関しては、親WSUSサーバーに集約（ロールアップ）させることもできます。そのため管理上の境界を分けつつも、全社レベルで更新プログラムの適用状況を一元的に把握することが可能です。
以上3つのポイントを踏まえると、A社のWSUS構成は次の図のようなものになるでしょう。
