運用
|
|
このようなSUSシステムを使わなくても、Hotfixを当てるだけならば通常のWindows Updateを使えば同様のことができる。だがSUSでHotfixを配布すれば、ユーザーと管理者の双方に次のようなメリットがある。
■スケジュールに基づいたクライアントへのHotfixの自動配布と適用
SUSによるHotfixの自動配布と適用は、もともとWindows XPに用意されているWindows Updateによる自動更新の機能をベースにしたサービス(「Automatic Updates」サービス)を使って実現している。これはWindows Updateサイトを定期的に調べて、新しいHotfixが用意されているとそれをユーザーに通知したり、自動的にシステムに適用して、必要ならばシステムを再起動したりするというサービスである(従来のWindows 2000における「Windows重要な更新の通知サービス」を置き換えるもの)。クライアント側にこの自動更新モジュールを導入しておくことにより、ユーザーの手をわずらわせることなく、システムの状態を常に最新に保つことができる。
クライアントへいつHotfixをダウンロードして適用させるかというスケジュールや、どのSUSサーバ(「配布ポイント」という)からHotfixをダウンロードするかなどは、基本的にはActive Directoryのグループ・ポリシー機能を使って制御する。クライアント側にはSUSのクライアント・モジュールをインストールしなければならないが、必要ならばそのインストールもグループ・ポリシーで制御したり、SMSで配布したり、もしくはログオン・スクリプトなどで制御したりするという方法がある。いずれにしろ、1度自動更新のクライアントさえインストールしてしまえば、あとはクライアント側のユーザーの手を煩わせることなく(ユーザーが管理者権限でログオンする必要はない)、指定したHotfixを適用することができる。
グループ・ポリシーによる自動更新の設定 |
Hotfixをいつクライアントへ配布して、インストールするかは、Active Directoryのグループ・ポリシーによって一括して制御することができる。 |
ただし実際には、常に指定した時間にだけダウンロード、実行するというわけではなく、ネットワークのトラフィックやシステムのCPU稼働率などに応じてダウンロードする時間帯が(ランダムに)ずれるようになっている。もちろんシステムの電源が入っていないときは、次回のシステム稼働時にダウンロードが行われる。基本的には、システムがアイドル状態もしくは負荷が低いときにHotfixファイルのダウンロード作業を行い、指定された時間になるとそのHotfixのインストール作業が行われるようである。また何らかの理由(システムがシャットダウンしたとか、負荷が高くなったなど)でダウンロード処理を途中で中断した場合は、あとでその続きからダウンロードを行うようになっている。このバックグラウンドでのダウンロード機能はBITS(Background Intelligent Transfer Service、バックグラウンド・インテリジェント転送サービス)と呼ばれる。
Active Directoryによるグループ・ポリシーを使っていないネットワークの場合は(ワークグループ・ネットワーク、もしくはスタンドアロンでのテストの場合は)、ローカル・マシン上で直接レジストリを操作するか、ローカル・グループ・ポリシーを使って、SUSサーバの配布ポイントを正しく指し示すように設定する必要がある。
■インターネット・アクセス回線の混雑の緩和
SUSの導入によるいちばん分かりやすいメリットは、全体的なネットワーク・トラフィックの軽減であろう。SUSではなく、通常のWindows Updateで配布されるHotfixは、基本的には各マシンから直接インターネットへ接続して、ダウンロードとインストールが行われる。Hotfixは場合によっては更新されることがあるので(一度公開したHotfixに問題が含まれていたりすると、あとで更新版が再公開される)、一度インストールしたものでも再インストールを余儀なくされることがある。そのため、Hotfixをダウンロードする場合には、Webアクセスのキャッシュ(Proxy)が効かないようになっている。だからHotfixのリストを取得する場合や、Hotfix自身を実際にダウンロードする場合に発生するインターネットへのアクセス・トラフィックは、各マシンごとに個別に発生することになる。Windowsマシンの台数が多ければ多いほど、このトラフィックはインターネットへのアクセス回線の帯域を圧迫することになる。
これに対してSUSを使うと、インターネットとやりとりされるHotfixは、SUSサーバへダウンロードするときの1回だけで済む。各クライアントへ送信されるHotfixはすべてSUSのサーバからダウンロードされるので、トラフィックは組織内だけに限定することができる。
■Hotfixの集中管理と選択的な適用
SUSでは、マイクロソフト社のWindows UpdateサーバからすべてのHotfixをダウンロードするが、そのすべてを無条件にクライアントへダウンロードするわけではない。管理者はHotfixごとに、それを適用するかどうかを決めることができる。Hotfixの内容をチェックして、不適切なものはクライアントへの適用を行わないようにしたり、インストールされている各種のアプリケーションとの互換性テストが完了して、修正プログラムを適用しても安全であると確認されるまで、その適用を一時的に見合わせたりすることができる。
配布するHotfixの選択画面 |
クライアントにインストールするHotfixは、SUSの管理画面で取捨選択できる。新しいHotfixがリリースされてもすぐにはクライアントへは配布せず、十分なテストが完了するまで、新しいHotfixの配布とインストールを一時見合わせておくことができる。チェック・ボックスを有効にすると、長くても1日以内にはクライアントへ配布される。 |
■複数台のSUSサーバによる連携と負荷分散
社内に配置するSUSサーバは1台だけではなく、負荷分散やネットワークの構成などに応じて、複数台用意することができる。この場合、マイクロソフトのWindows Updateサーバと通信するのは1台だけで、残りのSUSサーバは、親となるSUSサーバからHotfix情報を受け取ってそのミラーとして動作する。離れた場所にある支社や部署ごとに分散してSUSサーバを配置すれば、それらの間を結ぶLANやWAN回線の帯域を圧迫することなく、それぞれの場所に設置されたクライアント・マシンにHotfixを適用することができる。
SUSサーバではHotfixごとに配布を許可したり、禁止したりすることができるが、これらの設定を子のSUSサーバへも伝達することができる。こうすると、全社中のHotfixをすべて同様に管理することになる。逆に親SUSサーバの設定とは関係なく、MicrosoftのWindows UpdateサーバにあるHotfixをすべて(親SUSサーバ経由で)ダウンロードして、あらためてHotfixごとに設定を施すことも可能である。
さらに変わった構成として、Hotfixごとの更新の許可/不許可の指示は親SUSサーバから取得するものの、Hotfixのバイナリ自体はマイクロソフト社のWindows Updateサーバから直接取得するという構成もとることができる。例えば本社から遠く離れた支社内に子のSUSサーバを置き(この支社には、インターネットへ直接アクセスできる回線がすでに存在しているものとする)、更新の許可/不許可リストは本社から取得、Hotfixはインターネットから取得という構成にすれば、本社―支社間の回線に大きな負荷をかけることなく、最新のHotfixリストを維持することができる。
■インターネットから切り離されたWindows Updateサービス
従来Windows Updateサービスを利用する場合は、直接的にしろ間接的にしろ、インターネットへ接続しておかなければならないという制約があった。マイクロソフト社のWindows Updateサイトへ接続するのであるから、これは当然であろう。だがWindows UpdateでHotfixを適用するまでのわずかな隙に、逆にインターネットからの攻撃を受けてしまう可能性もある。具体的にいえば、Code RedやNimdaへの対策をしようと作業している間に、対策前のIISがそれらのワームに感染してしまうという危険性である。
これに対しSUSでは、安全なイントラネット内にサーバを置いた状態で、これらのセキュリティ対策を施すことができる。すべての対策が完了してからインターネット向けセグメント上に配置すれば、従来よりも安全にシステムの導入作業などを行うことができる。
■Web(HTTP)ベースの通信と管理ツール
SUSサーバは、マイクロソフトのWindows UpdateサイトからのHotfixの取得や、クライアントへの配布、SUSサーバ同士の通信、そしてSUSサーバへの管理ツールなど、すべての通信をHTTPプロトコルだけで行っている(暗号化を行う場合はHTTPSを使用)。そのため、一般的な企業におけるファイアウォール・システムやネットワークなどとの親和性が高い。
SUSのサーバ・ソフトウェアは、すべてIIS上で動作している。マイクロソフトのWindows Updateサイトへ接続する場合と同様に、すべてのSUSクライアントは、SUSサーバに対してHTTPプロトコルでアクセスし、最新のHotfixリストを入手して、必要なHotfixをだけを選択的にダウンロード/インストールしている。
SUSサーバを管理するには、Internet Explorerを使ってSUSサーバの管理画面にアクセスすればよい。マイクロソフトのWindows Updateサーバと同期を取ったり、オプションの設定、クライアントへ配布するHotfixの選択や情報の表示などは、すべてIE経由で行うことができる。
■多言語のサポート
SUSサーバで配布可能なHotfixは、日本語Hotfixだけに限らない。SUSサーバを構築するには英語版のWindows 2000 Serverか日本語版のWindows 2000 Server以上が必要だが、SUSサーバ上に格納したり、SUSクライアントへ配布したりするHotfixは、日本語版Hotfixだけでなく、もともとのWindows Updateサーバ上に存在する20以上の言語がサポートされている。そのため、企業内に複数の言語のWindows 2000/XPシステムが混在していても、1つのSUSサーバだけでこれらをサポートすることができる。
ただし多くの言語のHotfixをサポートすると、それだけ多くのディスク領域を消費するのはしかたがないところだろう。とはいうものの、日本語版と英語版のHotfixをすべてサポートするように設定した場合でも、必要なディスク領域は200Mbytes程度であった(2002年7月上旬現在のHotfix)。
多国語サポートのSUSサーバ |
日本語版ソフトウェアに対するHotfixだけでなく、英語版のシステムに対するHotfixも1台のSUSサーバでまとめて管理して、クライアントへ自動配布することができる。ただしその分ディスク容量は必要となるが。 |
関連リンク | |
Microsoft Software Update Servicesのページ |
INDEX | ||
[運用]Microsoft Software Update Servicesの実力を探る | ||
1.Software Update Servicesの概要 | ||
2.SUSの仕組み | ||
3.SUSで管理するHotfixの配布 | ||
4.SUSサーバのインストール | ||
5.SUSサーバの設定 | ||
6.SUSクライアントの制御 | ||
7.SUSのクライアントの動作 | ||
8.SUSの運用 | ||
運用 |
- Azure Web Appsの中を「コンソール」や「シェル」でのぞいてみる (2017/7/27)
AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう - Azure Storage ExplorerでStorageを手軽に操作する (2017/7/24)
エクスプローラのような感覚でAzure Storageにアクセスできる無償ツール「Azure Storage Explorer」。いざというときに使えるよう、事前にセットアップしておこう - Win 10でキーボード配列が誤認識された場合の対処 (2017/7/21)
キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。英語キーボードが日本語配列として認識された場合などは、正しいキー配列に設定し直そう - Azure Web AppsでWordPressをインストールしてみる (2017/7/20)
これまでのIaaSに続き、Azureの大きな特徴といえるPaaSサービス、Azure App Serviceを試してみた! まずはWordPressをインストールしてみる
|
|