UJP - 技術情報

SUSの適用を考えてみる

０．改訂履歴

2002.07.30　新規作成

１．はじめに

　このドキュメントでは，Microsoftが提供する，SUS(Softwaren Update Service)を利用する場合の色々な考慮点を思う限り列挙してみる．

　「SUSってなに？」という人は，ドキュメント「Software Update Serviceについて」を参照．

２．SUSを利用した基本的な利点

SUSは，平たく言えば「WindowsUpdateのイントラネット版」である．
ネットワークインフラ側から見ると，帯域の有効利用が可能である．
普通のWindowsUpdateを利用している場合，次の図のような利用方法となる．

この場合の問題点は，社内にある多数のクライアントから，Microsoftのサーバに対してトラフィックが発生する．
SUSを運用すると，次のようなイメージなる．

SUSサーバがMicorosoftのサイトから，最新版のモジュールをダウンロードする．
社内のクライアントは，社内にあるSUSサーバからモジュールをダウンロードする．
よって，LAN内，もしくは近くのネットワークの範囲内で作業を完了する事が可能なため，トラフィックに悪影響を出しにくい．

３．サーバ

３．１．SUSの中継サーバ機能

SUSでは，ネットワーク的に多段配置が可能となる．
たとえば次の様な例．

この例では，Floor1とFloor2のLANがあるというイメージである．
それぞれのLAN上にSUSサーバを配置する．
それぞれのSUSサーバが，Microsoftからデータを取得してくるのは経済効率が良くない．

そのような場合は，SUSサーバ間でデータを複製する事によって，対外接続の回線トラフィックを軽減する事が可能になる．
また，データセンターなど，直接Internetに接続していない場所へのアップデータの供給方法と考える事が出来る．
当然，この中継の仕組みを使えば，次の様な多段で配布する仕組みを構成する事が出来る．

そうするかどうかは別にして，このような複雑な配置も可能．

３．２．ステータスサーバについて考える

SUSでは，ステータスサーバという仕組みを備えている．
要は，どのクライアントにWindowsUpdateが適用されたかを確認するためのログ機能である．
ステータスサーバといっても，単純なHTTPサーバに対するアクセスログを残すだけの仕組みなので，難しい事はない．
SUSのクライアント側では，レジストリの設定によって，パッチのダウンロード元のサーバ(WUserver)の指定と，ステータスサーバ(WUStatusServer)の指定に分かれている．
概念的には次の通り．

仕組み的には，IISサーバであれば良い．

よって，この図のように，複数のSUSサーバを運用している場合でも，ステータスサーバは１つでも良い．
ただし，現在，このステータスサーバに残るアクセスログを分析しやすいようにレポートを作成してくれる機能がない．

４．クライアント

次に考慮するのは，SUSのクライアントについて．

４．１．対象について

SUSのクライアントになれるOSは，Windows2000以降のマシンとなる．
よって，WindowsNT4.0以前のOSを搭載したマシンでは，この自動アップデートの対象とならない．
また，今後WindowsNT4.0について新たに細かい修正パッチが継続的に提供されそうにない為，ここはMicrosoftの指示通り，OSのアップグレードを検討した方がよいと思われる．
2002年7月30日現在，対象となるOSでも，このSUSを使った運用が可能となるのは次の通りとなる．
- Windows2000 ServicePack2とSUSClientを導入したマシン
- Windows2000 ServicePack3には，SUSClientが同梱されている．
- WindowsXP ServicePack1にも，SUSClientが同梱されている．
なお，執筆時現在，SUSClientに問題があるようで，各種ServicePackの提供が遅れている模様である．

４．２．クライアントの設定について

では，実際の適用について考えてみる．
現在の所，SUSClientの設定は各マシンのレジストリに取得開始時間を設定しなければならない．
よって，SUSClientを配布した後でも，個別にレジストリを設定する事が必要である．
設定する項目の概略は，次の通り．
- SUSで自動アップデートするか否か．
- サーバのアドレス（URL）
- 新規パッチがでているかチェックするタイミング．
このレジストリの設定方法は，次のパターンが考えられる．
- ドメインに参加しているマシンであれば，ログオンスクリプトで.regファイルを実行するように設定する．
- regedt32.exeを使って，リモートマシンに接続して設定する．
ドメイン管理を行っていれば，ある程度は楽であるが，確実に全てのクライアントに設定されているか否かを確認するには手間がかかる．
結局，人海戦術で確認しないと確実性が損なわれる．

４．３．適用のタイミングについて

SUSClientでは，サーバにアップデータの有無をチェックする時間を指定できる．
- 指定できる単位は，「何時」であり，「何時何分」ではないので曖昧．
- 逆に，この曖昧さがロードバランスを意味しているのかもしれない．
よって，たとえば次の図の様に時間帯をずらして設定する事が可能となる．

時間をずらして設定する意味として，２つ考えられる．
- SUSClientの台数が多いと，当然一度にアクセスが集中してしまうため，ネットワークトラフィックやサーバレスポンスに影響があるので分散した方がよい．
- サーバシステムで，複数代をロードバランスして稼働させているような場合，適用時間に時差をもうける事で，システム全体としての連続稼働を実現できる．

４．４．パッチ適用の可否について

場合によっては，そのパッチが適用される事によって，他のアプリケーションが稼働しなくなる可能性も否定できない．
- 最近の「感覚」でいうと，昔ほどパッチやServicePackが大きく環境を変更してAPI等に互換性の問題が出る事は少なくなっているとは思える．
- ただし，サードパーティ製品のはまた別．
よって，本来ならばパッチを適用しても問題ない事を検証した上で，配布するのが筋である．
SUSのサーバでは，新しいパッチがリリースしてダウンロードされても，自動定期にクライアントに配布されない．
- SUSサーバを取り巻くフローについえは，「プロセスフローとタイムラグの考慮点」を参照．

５．プロセスフローとタイムラグの考慮

SUSサーバで行うフローについて，次のように簡単なプロセスフローとして図解して考えてみる．

ここで気にするのは２点．
一度設定してしまうと，自動でモジュールを入手する事が出来る．
しかし，新しい物がダウンロードされたか否かを自動通知する仕組みがない．
- よって，定期的にチェックする．
  - 実際には，Microsoftが提供する無料のメールサービスを使えば，新しく提供されたパッチがあればその情報を入手する事は可能であるが．．．
- チェックして，新しいパッチがあり，それを配布して良ければ「許可」を選択する．
この手動処理部分に，管理者の都合によるタイムラグが発生する．
さらに，クライアントからSUSサーバに対して更新チェックが行われるタイミングもあるので，通常，営業日で１日程度のタイムラグが発生すると考えられる．

６．SUSで実現する範囲（許容性）について

タイトルは難しいが，じゃぁ実際SUSがどこまで使えるかについて考えてみる．
これまでの評価の結果を次にまとめてみる．
- 評価できる点
  - ソフトは無料．（Windows2000Serverが必要だが）
  - SUSServerの構築自体は難しくない．
  - 中継機能を使う事によって，大規模なネットワークにも対応できる．
  - 安全策を取っている模様で，完全自動化ではない．
- 物足りない点
  - WindowsのOSがらみのソフトウェアしか対応していない．
  - 同じMicrosoftの製品でも，Office系ソフトのパッチには対応していない．
  - 当然，サードパーティ製品のパッチをSUSで提供しようとしても無理．
  - 人で介入が必要なため，タイムラグが発生しやすいフローである．
  - パッチの即時反映が行えない．
  - ステータス（適用状況）のわかりやすい集計レポート機能がない．
総じてこの「物足りない点」については，MicrosoftのSystem Management Server(SMS)を使って解決するしかなさそうである．