Zabbix2 のハマリどころ

※-お詫びの追記 - 検索エンジンからこのブログを間違って見つけてしまった貴方は不幸かも知れません。この文書は Zabbix のソフトウェアアプライアンスというものを発見して誰の力も借りずに無知なまま 二、三日使ってみての感想文です。ちゃんと勉強するには Zabbix の公式サポートや他のサイトの情報や公式ドキュメントを参考にした方が何百倍もためになります。それでも読んでみたい方、ありがとうございます。今のバージョンでは解決されている、おかしな突っ込みどころが沢山ある記事なので、そのつもりでご参考ください。まだ随分お読みになる方がいらっしゃるので ..... -以上お詫び※

ほとんど「ネットワーク管理」という力技に頼ってきたSUSE Linux 一本の技術者が Zabbix2 という管理ツールを使ってみた感想です。

SUSE Studio から Zabbix 管理ツールの導入
Zabbix2 で linux サーバーを管理する
Zabbix2 で Windows を管理
Zabbix2 でマップを作成

の続きです。ここでは、どこがハマリ易いポイントであるか、あるいは使いづらいなぁと思えるポイントを説明してみます。

追記: Zabbix 2.2.1 アプライアンスは随分雰囲気がかわりました。2014/8 現在 2.2.2 です。
Zabbix 2.2.1 openSUSE アプライアンス ファーストインプレッション

-SNMP監視-

相手がそもそも snmp が有効でなければ snmp 監視はできません。ping の死活監視しかできないわけです。

まず監視対象の FireWall 周りを確認します。

Zabbix のターミナルコンソールから

# snmpwalk -v 2c -c mycommynity target-IP .1.3.6.1.2.1

を実行して返事が無ければ動きません。 ODI 1.3.6.1.2.1(.1) はよく使う snmp の OID なので覚えておくと便利です。Zabbix のデフォルト snmp テンプレートは snmp v2c です。MIB OID という言葉だけで「なんじゃそれ」と思う方もこの OID はよく使うものらしいので覚えておくと便利です。

a0056607_17123670.jpg


「SNMPによるネットワークモニタリング」
--http://www.itmedia.co.jp/enterprise/articles/0705/21/news015.html

の記事が詳しいので参考にしてください。

ディスカバリーした後はデフォルトで zabbix agent のポート 10050 を監視します。snmp 監視を行うように設定し直す必要があります。この辺りはデフォルトテンプレートを使わず、何らかのカスタマイズしたテンプレートを作ることになるでしょう。

a0056607_15581285.jpg


NAS やルータなどの agent を組み込めない機器を監視対象としたい場合は snmp 監視が行えるよう、 Interface に追加します。 Zabbix Agent の 10050 は remove しても構いません。

-なかなか監視対象が出てこない-

監視対象が出てこない、あるいはグラフが出ないのは、デフォルトで 3600 秒(1時間)が検出の間隔であることによります。残念ながら

「今すぐアクティブに監視」

という機能は一見するとないため、じっくり待つしか方法はないと諦めていました。ディスカバリーの間隔をテンプレートでもっと短くすることもできますが、あまりお勧めできないところです。

Host > Discovery, Application, item などの機能を"Enable" > go すれば Graph の描画はすぐ始まるようです。
a0056607_11105590.jpg


また、ディスカバリーはデフォルトで 3600 秒(一時間)です。最初はもっと短めにしても良いのですがテンプレートの修正は結構面倒です。テンプレートを選んで mass update > go で Update Interval でまとめて修正します。

-Host Templateの利用-

一つの Host に複数のテンプレートを使うとエラーになります。
a0056607_1626193.jpg


例えば Linux SNMP のテンプレートと Generic SNMP のテンプレートを当てはめるとエラーになります。lこれは大きなテンプレートが小さなテンプレートにリンクしているためです。どうせなら上書きして欲しいのだけれどなぁと思いました。

素直にテンプレートは一つだけ使うのが一番よさそうです。 Zabbix Agent が動作する監視対象であれば Agent 用テンプレート。 Linux ベースの NAS なら Linux SNMP などですね。

-Host の設定は Cloneを使う-

一つの Host がうまく管理できるようになれば、あとは Clone 機能を使い、同じ機能や目的のサーバーにコピーして利用するのが一番良いようです。この Clone 機能は非常に便利です。ただし Clone ボタンを押した時にこれがクローンなのか、大元なのかがはっきりしないので、使う時は不安になるでしょう。せめて Clone を押した後の Name フィールドに 'MyHost-(Cloned)' とでもしてくれるととてもありがたいところです。

-監視されているかどうかの確認-

このホストが監視できているかどうかの核には Monitering スクリーンではなく Configuration > Host スクリーンで一発で解ります。Zabbix Agent と通信できない場合は 'Z' のアイコンが赤に、SNMP 監視がうまくいかない場合は SNMP の部分が赤になります。
a0056607_16585531.jpg


できれば、こういったステータススクリーンは Monitering スクリーンから一発で解るようにして欲しいのですが、 Monitering スクリーンにはテキストのアラートが表示されるだけなので、あまり便利ではありません。

-Monitering Screen-

Monitering のメインスクリーンではイベントの発生を優先して表示するようになっています。ここは非常に不満を感じるところです。

例えばメインスクリーンからあるホストの状態らグラフの遷移を見たいと思うと

Dashbord > Graph > Group > Host > Graph のカテゴリ

を選ぶという5ステップが必要です。
a0056607_1720109.jpg
※ 慌てるな、グラフは直ぐには出てこない。Linux SNMP のテンプレートでも60分くらいかかります。

慣れればどうということはないのですが、できればイベント確認画面からダイレクトにグラフを見るような機能が欲しいところです。

もっとも、よく見るイベントや重要なホストを管理する場合は Favorite Graph や Screen 機能を使い、あらかじめ用意すれば良いのですが、予知能力がない管理者が

「この異常事態のどこを見ればよいのか」

といった場合に、ホストの一覧や、イベントスクリーンからのグラフの参照ができないのはちょっと残念です。

できれば、「通信トラフィック」「ディスクIOの状態」「CPU負荷」と言ったカスタマイズできるグラフを、Favorite や Screen あるいは Map の機能の中でツリー構造で見れるとか、せめてこれらの表示を Favorite や Screen のグループ化、できれば文句のつけようがありません。

また、死活管理 "ping実行" は map を作らなければいけません。マップに配置された Host に対して Ping を送ったりサービスの確認は行えるのですが、マップ以外からは死活確認やサービス状態の確認は行えませんでした。
a0056607_17333632.jpg

この操作を行うにはあらかじめ map に Host を配置しておく必要があります。昔 Kinetics という自動マップ作成の管理用アプライアンス(当時はダイキン工業が代理店だった)を扱ったことがありますが、そのうちの1台は南極の昭和基地で働いていたという記憶があります。どんなコンセプトであれ、自動的にマップが作られると嬉しいと思います。

また、map には Host やその他の Element を作っているのですが一旦 Host のオブジェクトを削除してしまうと、リンクされたマップからも Host は消え去ってしまいます。リカバリーするには、マップに新規に Host を再定義しなければなりません。

map の Export/Imprt はできるようですが、私の未熟さなのか、うまく動作しませんでした。例えばネットワークが大きくなったのでマップのサイズを変えるにも、マップを再作成しなければならないようです。

-全く機能しないインベントリ管理-

インベントリ収集は私の未熟さもあり全く機能しませんでした。残念ながらそうレポートするしかありません。うまく動いたという事例も海外のもので、それもあまりはっきりした情報ではありませんでした。もっとも日本語で挑戦した報告はありますが、「こうすれば間違えなく動く」という結果は探した限りありませんでした。

うまく動かす方法があれば、また報告の機会があるでしょう。

致命的なのはインベントリの収集が行えたとしても、そこに「リースの期限」だとか「支払いや管理は誰がやっている」という情報は極めてニンゲン的な情報だということです。それを自動化するのは不可能です。

致命的なことは、インベントリが収集できても、情報をインポート、エクスポートする機能が全く見当たらないことです。

例えばエクスポートした内容をスプレッドシートに読み込んで、資産台帳と照合して、欠けた情報、例えばリース先や期間だとか、どの部署で利用しているとか、責任者は誰か、修理連絡先はどこか、とかを書き加えて、インポートできれば価値のあるものとなりますが、これらの情報を上長に「報告」するには Zabbix のコンソールで見せるしかないのです。

「じゃぁ紙で報告して」

と言われれば、呆然とするしかないのです。これらの情報を操作ミスの多いブラウザ画面から行うのは相当に困難な作業です。利用するには API を直接操作するエクステンションを開発して組み込む必要があります。こういったところがオープンソースを使う上での見えないコストとなります。もちろんそうした機能を組み込むことで SIA Inc. はじめ関係者 はビジネスを行っていることを理解すべき点でしょう。


-基本的には「狼が来た」-

Zabbix の Dashboard を見て、このソフトウェアの主な利用方法は「イベント管理」に主力を置いているということがしみじみと理解できます。

イベント管理はアラートを出して「狼が来た」ことを知らせる機能です。ただし、その「狼」が郡狼なのか、タヌキなのかはイベントだけでは把握できません。ベテランは別にしても、初心者にはそのイベントが持つ重要性は中々理解できないでしょう。

イベントの通知があると、そのイベントを発生したデバイスにダイレクトに、状況を見て、確認し、何が問題になっているのかを調べてレポートを作るという基本的なオペレーターの操作に対する機能がZannix には欠けています。

例えば一つの一つのホストが死活管理で「エラー」を報告した場合、「このマシンはどのルーターにつながっていたんだろう」と思い出すより、そのイベントから直接関連するルート、スイッチやルーター、ホスト、およびそのサービスに順番にアクセスできれば最高です。

-最後に-

ここでは Zabbix のハマリどころよりも、欠点ばかりを書いてしまいましたが、それだけ取っ付きやすさがあり、コミュニティも活発で「使える」ものであることは評価しておいていいでしょう。この使いやすさ、魅力があるからこれだけの突っ込みたくなる欠点が見えてしまうということです。ネットワーク管理に未熟な私でさえも、ここまで理解できたことは、それだけ夢中になれるということで高く評価しています。

たいていの日本の顧客は、高価なネットワークの統合管理ツールを導入しても、導入から運用、障害対策さえもSI事業者にまかせっきりです。とても残念なことですが、それだけネットワークの運用管理に携わるエンジニアのスキルが低い(というより低く見られている)ことが最大の問題です。オープンソースならタダだろうと上長に進言して甘く見ると痛い目にあいます。

オープンソースならではの導入の敷居の低さ、それに有償のプロフェッショナルのサポートもあり得るということは、このような商用OSSの良いところです。大規模なシステムだけではなく、この敷居の低さは中小規模のせいぜいサーバーが2,30台と言うところでも導入がしやすいでしょう。

ベンダー任せで高価なのに痒いところに手が届かない(「そういう仕様はない」と言われる)ツールより、技術者同士が困難を乗り越えて改良、解決できるオープンソースの一つの魅力です。

islandcenter.jp


あわせて読みたい関連記事

-keyword-

ネットワーク統合管理ツール オープンソース  SUSE openSUSE プライベートクラウド

[PR]
by islandcenter | 2013-04-30 17:03 | プライベートクラウド | Trackback | Comments(0)

http://susestudio.comは最小の労力で必要なアプライアンスを作ってくれる非常に便利なサイトです。

susestudio.com にアクセスすると Novell, Facebook, Twitter といったアカウントで利用できます。
ということでここでは DNS/DHCP NTP SSH といった最小限必要な機能を必要としたアプライアンスを作ってみました。


Create New Appliance を選ぶと SUSE のいろいろなバージョンを選択できます。ここでは SLES11sp2 を選択してみました。SUSE Linux は一つのサブスクリプションで仮想インスタンスが無制限という太っ腹な制限で、しかもリポジトリの登録(Basic Support)なら2CPUソケット $375 と激安で、Linux 発祥の地、EU諸国で最大の顧客のエンタープライズビジネスを行っています。

蛇足ですが RedHat の最大利用都市は日本(千代田)です。(2013/4 Google Trend 調べ)お膝元アメリカでは NYC しかトップ10に入っていません。
a0056607_0151379.jpg


さてこのスクリーンで好みのデスクトップと 32/64bit の選択をします。デフォルトは32ビットなので、ここではSLES11サーバx64 を選びました。

Software Screen では基本パッケージに追加で必要なパッケージを Search して追加できます。例えば DNS/DHP だけとか Apache だけとか Samba だけとかですね。
a0056607_0202427.jpg

標準パッケージしか選べない点はちょっと残念です。


Configuration Screen では言語と地域の設定、IP の指定方法(ここでは Dualing Bootとしました)他のアイコンを開くと仮想ディスクのサイズなどを選ぶ項目が出てきます。仮想メモリは後でも実装時に変更できるので気にする必要はありませんが、ディスクサイズは一旦作った後、Version 0.2 で作り直すことも出来ます。追加言語で日本語を入れることができないのがちょっと残念でした。初期言語では選べます。
a0056607_026398.jpg


最後に Build 画面です。
ここで、 XEN 用アプライアンス、Amazon AWS 用 Hyper-V 用 VMware 用などさまざまな用途にカスタマイズできます。
a0056607_0361888.jpg


Build ボタンが Gray Out して押せない場合は、必要なパッケージが無いためです。
a0056607_03953100.jpg

Software の画面に戻って、赤い警告をチェックします。どうやら、Startup でアドレスを決めるための Yast のモジュールが無かったようでした。


Build は数分から10分程度で終わります。Build スクリーンの下のほうに進捗バーが出てきます。ここでは170Mb程度の tar.gz 圧縮イメージが出来上がりました。ダウンロードして解凍します。raw ファイルをXEN に実装してアプライアンスを見てみましょう。

End user license agreement (EULA)許諾に "Yes"した後、ホスト名の設定画面が出てきました。
a0056607_04644.jpg


この後、IP の設定画面などが出てきます。
a0056607_0474311.jpg


yast のカスタマセンターの機能で、購入したアクティベーションキーを登録します。
a0056607_0503863.jpg

これでリポジトリが登録されます。

実際にどれくらいのサイズを使っているのでしょう

dns4:~ # df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 4.0G 581M 3.2G 16% /
udev 229M 68K 229M 1% /dev
tmpfs 229M 0 229M 0% /dev/shm
/dev/xvda1 4.0G 581M 3.2G 16% /
dns4:~ #



実際作ってみたら 4G も必要はなく、僅か581Mbで DNS/DHCP が作成できました。日本語の言語設定も入れればもう少し大きくなるのでしょうが、この目的ではまず必要になるケースもないので、これでよしとすれば、1G程度の仮想ディスクでも何とかなってしまうのでしょう。

仮想ディスクのサイズを1G程度に減らしてみても、ビルドには数分で終わりました。1Gの仮想マシンイメージであれば、フットプリントも小さいため、簡単に他のハードウェアにマイグレートできます。

--
SUSE Linux Enterprise Server (SLES) はまさに「クラウドで使ってくれ」というようなライセンス体系です。 XEN 運用をしているとついつい購入したインスタンス数を超えて仮想マシンを作ってしまい勝ちです。また、緊急に仮想マシンをマイグレートすると、インスタンス数を超えてしまうこともあります。そんな時にいちいち、ベンダーさんの「見積もり」と稟議を待つ余裕はありません。

また、ベースとなるシステムを簡単に作成できるため、何かのアプリケーションを仮想環境などで実装テストする際のテスト用のイメージベースを作るには最適です。何しろ作業は数分で終わります。

うらやむべきは、こうして出来上がったイメージをダウンロードしなければならないこと。しかし Web/LAMP を使ったシステム用に一つ用意しておけば、後は自由にカスタマイズできるので、利用価値は高いと思います。

今回は商用版 SLES を使いましたが 2013 年現在 openSUSE12.3 の選択肢もあるので、こちらを使えば、古いPCを使ったUSBやライブCDなどでシンクライアントも作成できそうです。

islandcenter.jp

-Keyword-

openSUSE SUSE Linux SLES 仮想化 プライベートクラウド susestudio
[PR]
by islandcenter | 2013-04-20 01:19 | SUSE | Trackback | Comments(0)

Booo ....!

OpenSUSE 12.2, How to import GnuPG Key screen on XEN Environment durling 1 clieck install ? It met same with openSUSE 12.3.
a0056607_18353415.jpg


Where is "Import" Button on this Virt-Managers at this narrow screen ?
I want to know who can find "push Import" button from here. I could not resize this dialogue.

ALT + I: didn't work....

Who designed thi dialogue? He(she) mey use 24"inch Display. but my tiny laptop display is 13"inches.
[PR]
by islandcenter | 2013-04-18 22:02 | SUSE | Trackback | Comments(0)

Organization CA はディレクトリツリー上の各サーバーで必要な公開鍵を自動的に作成するためのオブジェクトです。通常は eDirectory(8.x) を作った「最初のサーバー」がホストサーバーとして認証鍵を持ちます。この鍵を元に、全てのサーバーのキーが作成されます。

Organization CA の概要についてはこちら。(と逃げてみる)
Organization CA Overview
http://www.novell.com/documentation/crt32/?page=/documentation/crt32/crtadmin/data/a2ebon6.html

そこで、古くなった「最初のサーバー」を V2V する場合はあまり問題なく移行できますが、P2V移行などの場合、「サーバー丸ごと」移行に失敗するととんでもない問題になります。また、何らかの問題でホストサーバーに問題が発生すると、ディレクトリ全ての認証鍵を再作成する必要があり、大変な労力を必要としてしまいます。

この記事は「OES NetWare/Linux CA Authority サーバの移行
の iManager 版です。

この文書そのままの作業です。
http://www.novell.com/support/kb/doc.php?id=3618399

※ブラウザの設定は英語を優先言語に設定しています。優先言語を日本語にすると、ほぼ全てのメニューは日本語表示されます。
上の文書にもありますが、 CA のホストサーバーをexport キーなしで作り直した場合、全てのサーバーの認証局をアップデートしなければなりません。私はCA局を持ったサーバーは「小規模な仮想サーバー」を使い、定期的にシャットダウン、バックアップコピー、再起動するように運用することをお勧めしています。


-現行のホストサーバーからのエクスポート-

iManager > Directory Management > Modify Object > "Tree -> Security -> My-Tree CA"を選びます。

この画面は Tree ビューで表示した場合です。Tree オブジェクトの直下の "Security" コンテナに存在します。
a0056607_10535693.jpg

ツリービューで見てみます

Role(役割) 画面から操作する場合
Certificates > Self Signed Certificate(check) > "Export"
リンクをクリックします。
a0056607_11644100.jpg


ここでパスワードをセットします。
Enter Next
a0056607_11104056.jpg



Save Export リンクをクリックすると、鍵のダウンロードを行います。
a0056607_11123083.jpg


> save as "My-Tree.pfx

ここで保存したキー(デフォルトでは cert.pfx ) を安全な記憶媒体にパスワードと共に保管します。My-Tree(CApassword).pfx などの名前にしておけば便利でしょう。admin や root のパスワードを記したメモなどと一緒にUSB メモリなどの安全な記憶メディアに厳重に保存します。

万が一、CA オブジェクトのホストサーバーがクラッシュした場合はこのキーファイルとパスワードで復旧します。

-Organation CAの作成-

古い CA Object を削除します。

Delete My-Tree CA.Security
a0056607_11152270.jpg



pfx ファイルをインポートします。
Novell Certificate Server > Configure Certificate Server Authority > browse and set "New Destination Server" : "My-Tree CA" > Import
a0056607_11222555.jpg


エクスポートしたときのパスワードをセット
Chose "Your-Tree.pfx" and set password when set password ""YourNewSecretPassword" >
a0056607_11265095.jpg
"

作成されました。(たまにプラグインエラーが出ましたが無視)
OK > Next
a0056607_11314541.jpg


Next > Finish
a0056607_11343115.jpg


ホストサーバーが入れ替わっています
a0056607_11363398.jpg



islandcenter.jp

-Keyword-

Novell Netiq eDirectory Identitimanagement Organation CA How to move CA server into another Server iManager
[PR]
by islandcenter | 2013-04-18 12:34 | Identity Management | Trackback | Comments(0)

ここでは Novell Openenterprise Server 11 (OES11)を使っていた iSCSI デバイス上の NSSボリュームを他の OES11 システムに切り替える作業を行ってみました。

実は元サーバーがどうしても復旧できなくてLDAP も NSS も正常に動かなくなってしまいましたので....

-オリジナルサーバー-

元サーバーの iSCSI を解除します。

yast2 > iSCSI Initiator > Connect > "Logout"
a0056607_16424781.jpg


また、必ず使わないサーバーの iSCSI Initiator は onboot -> Manual に変更します
a0056607_1645013.jpg

ここだけ CUI 版 yast を使っているのはこれが後に敗因となったからです...

-移行先サーバー-
YaST(YaST2) Network Service iSCSI Initiator を設定します。 iSCSI ターゲットのアドレスを指定して Login
a0056607_16481276.jpg


Status が Fail > True になります。
a0056607_16511518.jpg


起動方法を Manual > Automatic に変更します。(onboot ではマウントできない場合がありました:敗因2)
a0056607_16535183.jpg


-iManagerよりマウント-

※ ここではブラウザを英語環境で使用しています。ブラウザ環境を日本語に変更しても全く問題なくメニューなどの表示は日本語になります。

Role > Storage > "Server"を Brows > Device
sda がマウントされていることを確認します。
a0056607_16564769.jpg

くれぐれも "Initialize" ボタンを押してしまわないように、「押しちゃった」人からのアドバイスです。もっとも確認ボタンは出ますが。

Volume > Mount を確認します。 "Not Mounted" なので "Mount" ボタンを押します。
a0056607_1711156.jpg


Mounted, Active になりました。
a0056607_1731489.jpg


ストレージプールを確認します。引き継がれています。
a0056607_1752154.jpg


クライアントから見てみます。
a0056607_1771175.jpg



トラスティも引き継がれています。
a0056607_1785090.jpg


サーバーが変わってしまったためログインスクリプトは書き換えが必要です。
a0056607_17104681.jpg


--
このテクニックは、筐体内に NSS ボリュームを仮想イメージとした場合にも応用が利くかも知れません。

islandcenter.jp

-Keyword-

Novell OES Openenterprise Server iSCSI Device Replace Volume another Server How to
[PR]
by islandcenter | 2013-04-16 17:18 | OES Linux | Trackback | Comments(0)

-現象-

XEN 上の Windows 2008 をクリーンインストールし、 Windows Update やアクティベーションなどを行った後、スタートボタンから正常にシャットダウン(再起動)できない。

「シャットダウン中.....」で止まる。

YaST > Virt-Manager のメニューより Shutdown を選択すると問題なくシャットダウンできる。 xm shutdown コマンドでもシャットダウンできない。

通常運用中の xm shutdown では問題なし

-原因-

どうもそういう仕様なのかバグなのか。大幅にハードウェアの構成を変えたりすると発生するようです。

Windows 2008 does not shutdown properly under XEN and needs activation afterwards

Not familiar with Xen so I will defer to someone else regarding it's configuration. However, you are like using retail media and if the OS detects significant hardware changes, in your case this is all emulated from the Hypervisor, it will prompt for activation in the same way as if you replaced/changed the CPU's or motherboard in a physical machine. I would focus on Xen and its configuration as it doesn't sound like a Windows issue.

Windows のせいじゃないということらしいのですが、Hyper Visor 側で CPU やメモリの値を変えて再起動するとどうもそういう現象が発生するという事のようです。

The only one I can think of are the following below which may show Windows detecting new devices etc. From my point of view, that's a symptom not the problem. I would ask why does Windows get abruptly shutdown and why does it think hardware is changing. Both of those answers likely have to do with virtualization solution.

おそらく、大幅な更新がかかった後など、アクティベーションキーのチェックで「違うハードウェアにもインストールしたな?」という判断で、怪しい動作をするようです。

--
あまり、ハイパーバイザー上で動作しているシステムをいじくっちゃダメですよ、ということのようです。 Hyper-V でも同じ現象出るのかしら。というか「現在も進行中」の現象のようです。おそらく他のハイパーバイザーでもあり得そうな話です。

Windows Update を行った後おかしくなった。
After Windows Update - Cannot Boot in Windows 8 Pro

NICのドライバ変えたら動かなくなった。
Windows no-longer reconises Hyper-V switch after boot from shutdown

-対策-

Windows Update は自動インストール(unattend)しない。ダウンロードのみ行い、インストールは手動(attend)で行います。運用中はライブマイグレーションなどを行わない。


islandcenter.jp


- Keyword -
SUSE SLES Linux XEN 仮想環境 Windows 2008 R2 update Shutdown Freeze Reboot xm shutdown Virtualization
[PR]
by islandcenter | 2013-04-12 16:54 | XEN | Trackback | Comments(0)

タブブラウザが一般的になり、ブラウザの種類も増えると、一つのコンピューターで多くのウェブページを開いて...ということが一般的になってきました。おまけに gmail や google Calender などのクラウドサービスを標準で使う所もあるでしょう。BYODによって、持ち込みのBYODタブレットを社内の無線ルータにつないで、「トイレの個室で Youtube を見る」なんてことも当たり前になります。

そうなると、いかにWAN回線の効率化を行うかが課題となります。

ここではSUSE Linux 11 で squid キャッシュを作り、チューニングを行う方法を説明します。

SLES11 ではデフォルトでは squid 2.7 系がインストールされます。目先を変えてここでは squid 3.x 系をインストールしてみました。

参考文献:SUSE 公式(日本語)
第30章 Squidプロキシサーバ

-インストール-

YaST > Software Management より squid を検索すると、 squid 2 と 3 の選択肢が出てきます。
a0056607_18382847.jpg

スペースキーで "Squid 3 WWW Proxy" を選びます。

Yast(YaST2) でインストールすると、 2.7 系に上書きされてしまうので Yast 用のプラグインは無効(削除)にしておくと良いでしょう。ここでは squid3 をインストールします。

squidcache:/etc/squid # rpm -qa | grep squ
:squidGuard-1.4-13.6.1
squidGuard-doc-1.4-13.6.1
squid3-3.1.12-8.10.1
squidcache:/etc/squid # :



SUSE のパッケージにある squid3 の conf ファイルは以下の通りです。従来のマニュアルを兼ねた squid.conf は必要最小限の設定ファイルとなりました。従来の形式の squid.conf は squid.conf.documented に置き換えられています。

squidcache:/etc/squid # ls -l
total 244
-rw-r--r-- 1 root root 419 Dec 22 2011 cachemgr.conf
-rw-r--r-- 1 root root 419 Dec 22 2011 cachemgr.conf.default
-rw-r--r-- 1 root root 1547 Dec 22 2011 errorpage.css
-rw-r--r-- 1 root root 1547 Dec 22 2011 errorpage.css.default
lrwxrwxrwx 1 root root 26 Apr 10 13:40 errors -> /usr/share/squid/errors/de
-rw-r--r-- 1 root root 11651 Dec 22 2011 mime.conf
-rw-r--r-- 1 root root 421 Dec 22 2011 msntauth.conf
-rw-r--r-- 1 root root 421 Dec 22 2011 msntauth.conf.default
-rw-r--r-- 1 root root 2557 Dec 22 2011 squid.conf
-rw-r--r-- 1 root root 2557 Dec 22 2011 squid.conf.default
-rw-r--r-- 1 root root 200091 Dec 22 2011 squid.conf.documented



-設定-

squid.conf の初期設定は次のように非常にすっきりしたものになっています。

squidcache:/etc/squid # cat squid.conf
#
# Recommended minimum configuration:
#
acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1

# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7 # RFC 4193 local private network range
acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines

acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT

#
# Recommended minimum Access Permission configuration:
#
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager

# Deny requests to certain unsafe ports
http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user
#http_access deny to_localhost

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#

# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow localnet

# Allow localhost always proxy functionality
http_access allow localhost

# And finally deny all other access to this proxy
http_access deny all

# Squid normally listens to port 3128
http_port 3128

# We recommend you to use at least the following line.
hierarchy_stoplist cgi-bin ?

# Uncomment and adjust the following to add a disk cache directory.
#cache_dir aufs /var/cache/squid 100 16 256

# Leave coredumps in the first cache dir
coredump_dir /var/cache/squid

# Add any of your own refresh_pattern entries above these.
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
squidcache:/etc/squid #



-変更部分-

デフォルトで使ってもかまいませんが、一般的なものとしてここでは 8080 のポート番号にしました。 cachemgr を使う場合を考慮して 80 はあえて使いませんでした。

# http_port 3128
http_port 8080



-追加部分-

# キャッシュディレクトリの指定がコメントアウトされているので、キャッシュサイズ(ここでは8G)、階層数を記述します。

#cache_dir aufs /var/cache/squid 100 16 256
cache_dir ufs /var/cache/squid 8000 16 256



# パフォーマンスに関わる記述です。最大キャッシュオブジェクトサイズは 128Mb としました。

maximum_object_size 128 Mb
maximum_object_size_in_memory 32 Mb



#dns キャッシュを行う場合のDNSサーバーのアドレスです。
#イントラ用DNSと google のDNSキャッシュを指定しました。
#(覚えやすいので...)

dns_nameservers 192.168.1.2 8.8.4.4 8.8.8.8

# squid のバージョンや内部の IP アドレス、ホストを相手に記録させないための設定です。
# 一部のサイトでは匿名プロクシ経由のアクセスを禁止する場合があるため、
# この設定をしました。


via off
header_replace User-Agent Nutscrape/1.0 (CP/M; 8-bit)
visible_hostname unknown
forwarded_for off

※header_replace の行は効果があるとは思えないのですが....

この状態で squid を起動します。/etc/init.d/squid start をしても良し、yast > System > System Service(Runlevel) で初期起動設定を行い start しても良いでしょう。

a0056607_18474751.jpg


「かくにん君」などのサイトにアクセスしてみて squid キャッシュ経由で、squid のバージョンや内部ホスト名などの情報が漏洩していないことを確認します。デフォルトのままだと、squid キャッシュのバージョンから、内部のPCの名前、ローカルアドレスなどがバレバレとなってしまいます。かくにん君はこちら
http://www.ugtop.com/spill.shtml
a0056607_18495923.jpg

LAN内での運用ということでこういう設定にしました。LAN 外部に設置する場合、全世界に「匿名串」を提供することになるので注意が必要です。

-動作確認 cachemanager-

squid には squidclient という「動作状態確認ツール」がありますが、ここでは cachemanager を使います。
事前に apache2 をインストールしておきます。cgi を /srv/www/cgi-bin にコピーします。

squidcache:/etc/squid # find / -name "cachemgr*"
/usr/lib64/squid/cachemgr.cgi
/usr/share/man/man8/cachemgr.cgi.8.gz
/usr/share/doc/packages/squid3/scripts/cachemgr.readme
/etc/squid/cachemgr.conf.default
/etc/squid/cachemgr.conf
squidcache:/etc/squid # ls /srv/www/
cgi-bin htdocs
squidcache:/etc/squid # cp /usr/lib64/squid/cachemgr.cgi /srv/www/cgi-bin/ -v
`/usr/lib64/squid/cachemgr.cgi' -> `/srv/www/cgi-bin/cachemgr.cgi'

squidcache:/etc/squid #



cachemanager の conf ファイルを修正します。デフォルトポートを使う場合は変更の必要はありませんが、 8080 のようにポート番号を変えた場合は次のように変更します。

squidcache:/etc/squid # cat cachemgr.conf
# コメント行略
localhost:8080
squidcache:/etc/squid #


ここで apache2 をリスタートさせます。

# /etc/init.d/apache2 restart



ブラウザから

http://MySquidCache.intra/cgi-bin/cachemgr.cgi



にアクセスします。パスワードは設定していないので localhost:8080 を選んだまま continue します。
a0056607_18544239.jpg


# squidclient -h localhost -p 8080 mgr:client_list

を実行した時と同じ内容の動作状態がブラウザで確認できます。メニューの 2/3 あたりに client_list を確認するリンクがあります。
a0056607_18552396.jpg


cachemgr はブラウザでどのユーザからも参照できます。ただし一部の作業を許可する場合は、次のように squid.conf に記述を追加します。シャットダウンを許可する場合は

# cache_mgr
cache_mgr squidman
cachemgr_passwd yourpassword shutdown



と記述します。
a0056607_1224625.jpg

シャットダウン操作だけ Authentication (squidman/yourpassword)が必要になります。cachemgr_passwd の許可するコマンドリストはsquid.conf.documented に詳しく書かれています。


一週間程度稼動させた squid3 のキャッシュヒット率は 40% を超えました。実際にはここまでは行くことはなさそうですが、業務の内容によっては20%程度は目標としておきたいところです。
a0056607_18563515.jpg


mrtg で見てみると、青線(output) が緑(in)よりはるかに多く 「ブラウザ立ち上げっぱなし」でかなり効果が出ているようです。
a0056607_10342097.png


--
本来は、"Youtube のコンテンツを快適にできないか" という不純な動機でした。しかし、これらの動画サイトや Windows Update といったサービスは「重い」にも関わらず、 squid ではキャッシュできないようです。ということで回線容量の確保にはあまり squid キャッシュサーバーは貢献できないようです。

また最近のブラウザはどれもこれらのコンテンツをブラウザキャッシュとして保管していない(できない?)ようです。これはおそらくサイト側の作りによってキャッシュが行われないような仕組みになっているためだろうなと思います。もし、他に良いアイディアがあればコメント下さい。


逆に「まじめにお仕事をしている」人にとっては、繰り返し参考にするウェブサイトは、キャッシュヒット率が上がります。隣のヤツが不純な動機でトイレで隠れて動画サイトばかりを見ていても、かなり快適に仕事ができるという「非常に良い効果」があるでしょう。

本来であれば、トランスペアレントにしても良いのですが、隊障害性対策やインフラやトポロジの変更が必要です。

zabbix2 で状態を管理していると、幾つかの Disk Busy のアラートが上がっていました。 /var/cache/squid は出来れば本体とは別なディスクデバイスを使い、別パーティションとしたほうが良いようです。あるいは、思い切りメモリを増設して RAM ディスクをキャッシュパーティションとするのも手段かも知れません。あるいは、SSDをキャッシュとするのも良いアイディアでしょう。SSDの寿命を考えてもどうせキャッシュデータですからそういう割り切り方も良いでしょう。

仮想環境で運用するならルートパーティションのディスクイメージはHDDに収容し、キャッシュ用の仮想ディスクは SSD という方法もあります。本来「キャッシュ」データですからSSDの寿命を考えても「消耗品」と割り切れば、この構成も良いアイディアでしょう。

個人的にはSSDをデータ保管のためサーバーで使うのは止めた方がいいと思いますが、キャッシュ目的で消耗品だと思えばそういう選択もアリだなと思います。

ということで、"きゃりーぱみゅぱみゅ"の「にんじゃりばんばん」を何十回もロードしたにも関わらず、 squid やブラウザキャッシュは有効にならずに、コンピューターの中ではなく私の頭の中にキャッシュされてしまいました。すっかり頭の中のキャッシュが「にんじゃりばんばん」です。トイレの隣の個室で「にんじゃりばんばん」を鼻歌でほざいていたら、私かも知れません。こういったコンテンツはコンピュータを使わず「心に染み付くまで楽しめ」というメッセージなのでしょうね。

※もっと「こうしたほうがいいよ」というご意見があれば歓迎します。

続き
squid の効率をチェックして、キャッシュをクリアする。


問い合わせは
islandcenter.jp


-Keyword-
SUSE SLES11 Squid3 キャッシュ 設定 チューニング
[PR]
by islandcenter | 2013-04-10 19:03 | SUSE | Trackback | Comments(0)

Windows Update Server (WSUS 3.0 sp2) を Windows 2008 R2 で作ってみました。

Windows Update は「月の物」でいざ「今日は残業覚悟の締日」という時に限りダウンロードが始まったりすることがあります。それぞれのデータサイズが数十Mバイトもあるわけですから、みんなで動画サイトを訪問するようなもので、ISPとの回線を圧迫します。

しかも悪いことにSquid などのウェブキャッシュは無視してくれるようで、クライアントがアップデートを取りに行くときはすべてのコンピュータの通信が Microsoft のサーバーに集中してアクセスしてくれます。

Windows Update Service (WSUS) は、マイクロソフトさんの投資を減らし、サーバーライセンスの売り上げにも貢献してくれるため、無料で配布されています。

-環境-

Windows 2008 R2 sp1(x64) を使用しました。機材の関係で C: 40Gb D:30Gb のディスクをSUSE+XEN で仮想化し1.2Gのメモリ、4VCPU を与えました。かなり無理した構成なので実際には最低でも4G程度のメモリが必要だと思います。また、たかがパッチ管理と侮ってはいけません。かなり WSUS のサーバーはハードな処理を要求します。あまり重要な仮想サーバーとの物理マシンとの同居は避けるべきでしょう。 大元の update.windows.com が相当ハードな処理を強いられているのは想像に難くありません。Windows Update はアップデートサーバーとかなり激しいバトルを繰り広げるためでしょうか。単純にパッチのチェックをするだけでかなりのハードワークをサーバーに要求しました。どうも、ちょっとしたアップデートの確認だけでもタスクマネージャを見る限りではSQLサーバーの性能が Windows Update Service の性能を決めます。

「単なるデータのローカルキャッシュだろう」とマシンパワーを甘く設定すると、WSUS の性能が付いてこれなくて、逆効果になる可能性もありそうなケースもありそうなので、ご注意ください。禁断の手法であるフラッシュ メモリ ストレージの利用は、データベース管理者の手間を減らすこともできるのです!!とマイクロソフトさんが赤字で強調するくらいです。大量のメモリと大量の書き込みでは賞味期限があっという間になくなるSSDシステムを前提として検討した方がよさそうです。

仮想マシンのドライバは suse の VMDP2.002 を使用し、準仮想化(パラバーチャル)ドライバで動作しています。 VMDP は SUSE のサイトで探すと自動的に Novell のサイトに飛びます。

Windows Server Update Services 3.0 SP2 はこちらからダウンロードします。
http://www.microsoft.com/en-us/download/details.aspx?id=5216

他に

Microsoft Report Viewer 再頒布可能パッケージ 2008
http://www.microsoft.com/ja-jp/download/details.aspx?id=577
が必要となります。

また Windows8/2012 用にパッチが提供されています。

WSUS 3.0 SP2 の Windows 8 / Windows Server 2012 対応について (KB2734608)
http://blogs.technet.com/b/jpwsus/archive/2012/09/05/kb2734608.aspx

これを入れないと、 Windows 8 の Windows Update を起動すると「あれれ?」ということになります。最後にインストールします。
a0056607_1724223.jpg

WSUS クライアントがエラー 0x800B0001 で更新プログラムの検出に失敗する
http://blogs.technet.com/b/jpwsus/archive/2012/07/05/wsus-client-error-0x800b0001.aspx#

-WSUS 3.0 sp2 のインストール-

[サーバーの役割の選択] ページで、[アプリケーション サーバー] と [Web サーバー (IIS)] が選択されていることを確認します。選択されている場合は、この手順の残りを実行して、必要な役割サービスが選択されていることを確認します。選択されていない場合は、次の手順を実行して、アプリケーション サーバーと Web サーバー (IIS) をインストールします。

まず、 IIS と アプリケーションサーバー をサーバーマネージャの「役割」からインストールします。
a0056607_1328580.jpg


-「インターネットインフォメーションサービス(IIS)または、追加のIISロールサービスがインストールされている必要があります」ってなんだ?-

a0056607_1323253.jpg


もう一度「手順 1 : WSUS 3.0 SP2 のインストール要件を確認する」で確認しましょう。

1. [サーバーの役割の選択] ページで、[アプリケーション サーバー] と [Web サーバー (IIS)] を選択します。[次へ] をクリックします。

2. アプリケーション ロール サービスをインストールする場合は、[アプリケーション サーバー] ページで、[次へ] をクリックします。[アプリケーション サーバーの役割サービス] ページで、既定の設定を受け入れて、[次へ] をクリックします。
3. Web サーバー IIS をインストールする場合は、[Web サーバー (IIS)] ページで、[次へ] をクリックします。Web サーバー (IIS) の役割サービスのページで、既定の設定に加えて、[ASP.NET][Windows 認証][動的なコンテンツの圧縮]、および [IIS 6 管理互換] を選択します。[役割の追加ウィザード] ウィンドウが表示されたら、[必要な役割サービスを追加] をクリックします。[次へ] をクリックします。
4. [インストール オプションの確認] ページで、[インストール] をクリックします。


ということで「IIS 6 管理互換」「追加のIISロールサービス」ということになります。

IIS のインストールスクリーンで ASP.NET をチェック
a0056607_13334454.jpg


Windows 認証、動的なコンテンツの圧縮、IIS 6 管理互換をチェックしてインストールします。
a0056607_1338696.jpg


アプリケーションサービスは .NET Frame work だけインストールします。
a0056607_13421220.jpg


さてこれで WSUS 3.0 のインストーラーの罠を回避することができました。
a0056607_13451018.jpg

許諾画面が出てきたら、あとはウィザードに従ってインストールするだけです。

ちなみにプロクシサーバーを指定すると「同期エラー」になりました。どうも Windows Update はどのシーンでも Squid キャッシュとは相性が悪いようです。この辺は徹底しています。(プロクシのポート番号まちがってしまいました...)
a0056607_13482798.jpg


※ なるべくISPとの回線に余裕がある時間帯や update.microsoft.com などに負荷がかかっていない時間帯に作業すべきです。事前に ping で「ご本尊」との通信を確認してください。以外と失敗するものです。

初期データベースがロードされると、あらかじめダウンロードすべきプロダクトの一覧が出ますから、必要な分だけチェックマークを入れます。
a0056607_13522890.jpg

基本的な Windows のサービスパックや Office などですね。

言語パックも必要に応じてチェックしておきます。外資系企業や貿易関連のお仕事であれば、とりひきが多い、英語や中国語などのパックも選んでおくと良いでしょう。

クラスは最低限のものだけ選択されていたので、全てのクラスをセットしました。(これは敗因)
a0056607_1355090.jpg


ここから「同期」という長いタスクが始まります。

同期後は700Mb強の Windows Update キャッシュが作られます。今後どれだけ増えるかたのしみですね。
a0056607_13575068.jpg


ここで一旦サーバ自体を Update しておいて、再起動しておくと良いでしょう。
次に、WSUS 3.0sp2 用パッチを入れます。これは Windows8/2012 には必須です。手順は下の文書に詳しいのですが

※コマンド実行例
nlb.exe disable all


はパスが通っていないので見つかりません。nlb.exe は C:\Windows\winsxs のはるか彼方にありますので「検索」して、パスを見つけてコマンドプロンプトで cd してから実行します。

WSUS 3.0 SP2 の Windows 8 / Windows Server 2012 対応について (KB2734608)
http://blogs.technet.com/b/jpwsus/archive/2012/09/05/kb2734608.aspx

※ 一連のコマンドを実行する場合、「コマンドプロンプト」アイコンから右ボタンで「管理者として実行」を選ぶことをお勧めします。 Administrator グループのユーザではうまく動かないケースがありました。

-クライアント側の設定-

MADであれば特に述べる必要もありませんが、LANdesk や Novell ZenWorks など他のサードパーティ製ポリシー管理ツールを使っている場合だとか、なぜか社内に 「Professional 版じゃない」通常版はある場合(結構そういうケースがあるんです)は参考にしてください。

古い情報ですが、XP Home Edition を始め「無印」Windows7/8 (非Proffesional版)は mmc コンソールが使えないので、レジストリを直接設定することになります。こちらの記事が詳しいのでご参考にしてください。

Windows XP Home EditionをSUSクライアントに
http://www.atmarkit.co.jp/fsecurity/rensai/securitytips/025sus.html


> gpedit を使い「ローカルコンピューターポリシー」>「コンピューターの構成」>「管理用テンプレート」>「Windows コンポーネント」 > 「Windows Update」 に次の項目があります。

- 自動更新を構成する
- イントラネットの Microsoft 更新サーバーを指定する。

a0056607_1711040.jpg

この設定は任意です。自社のポリシーに従って提供します。

a0056607_17115742.jpg

WSUS サーバーの http://FQDN か http://xx.xx.xx.xx の直接アドレスを指定します。・

これ以外にも Windows Update の階層に設定する項目があります。それぞれの運用ポリシーで設定します。

この直後に

> wuauclt /detectnow

を実行します。別に実行しなくても良いのですが、実行すると WSUS サーバーに「私はあなたの管理下に入りました」というシグナルを送るため、WSUSの管理コンソールに変更結果がただちに(ちょっと待ちます)反映されます。

-関連記事-

Squid Proxy 経由で WSUS 3.0 sp2, Windows10 Update がエラー。

この状態で WSUS のコンソールを見ても「何もないじゃないか」と一瞬焦りますが、「状態」トグルを「すべて」に変更すると
a0056607_17285985.jpg


wuauclt を実行したクライアントが登録されます。
a0056607_1732630.jpg


これで次の「締日」にどういう効果があるのかを確認することになります。

「ご本尊」との同期が終わると、WSUSの「更新」の中にアップデートプログラムが出てきます。必要な項目、というよりほぼ「重要な更新」類は「重要」なので右ボタンから「承認」、インストールダイアログから「インストール」を選択すると、SQLサーバーがガリガリと処理を初めて配信の準備をしてくれます。
a0056607_1202831.jpg


あとは Windows Update から更新のチェックを行うと、設定したポリシーに従ってアップデートを行うことができます。
a0056607_1262438.jpg

「更新プログラムの確認中」はWSUSとの間でパンチの応酬が始まり、ダウンロードそのものは文字通り「一瞬」で終わります。その後のインストールはクライアント側の性能次第でインストールされるということです。

-結論-
WSUS を使った Windows Update は、各PCのアップデートにかかる時間と、ISPとの回線トラフィックを大幅に減らすことができます。しかし、「必要になるのは月一回、しかしパワーが必要」ということがわかりました。

月一度、猛烈なパワーを使いたいという事になるので、あまりクリティカルな目的ではありません。ただしパッチ管理は重要であるということです。ですから、CPUやメモリと言ったリソースの配分を自由に変化できるプライベートクラウド、仮想化に対しては非常に有効です。

例えば XEN 仮想環境では Dom-U の VM ファイルを

- メモリ小、vcpu 最小の「アイドリング状態」でパッチを蓄積
- メモリ大、vcup 最大の「スクランブル状態」でパッチを配信

の二種類の設定ファイルを作って、 cron などで「今月の Windows Update の日」である毎月第二火曜日

マイクロソフト セキュリティ情報の事前通知
http://technet.microsoft.com/ja-jp/security/bulletin/advance

直前にアイドリングモードから xm shutdown を行い、 "xm create -f スクランブル用 vm ファイル" に切り替えて起動して、一週間ほど運用したら元のアイドリング状態に切り替えるなどの方法が使えそうです。何も、WSUS は千歳基地で常時スクランブル状態のジェット戦闘機の様に構えている必要はありません。月の3週間はB767のように鷹揚にHDDで稼働し、スクランブル状態であれば、イメージを SSD などに mv してスクランブル状態にしておけば良いわけです。

しかし Windows Update サーバーには巨大な「使わなくなった」アップデートの残骸が残るので、こまめに「インストール済み」の更新を「拒否」して「オプション」のクリーンアップウィザードで削除しないと、 WSUS のストアされたディレクトリが「増えるワカメちゃん」状態になってしまいます。この作業は手動です。(敗因)

※一週間くらい運用しただけで30Gbなんてディスクは食いつぶすくらい更新をダウンロードしてしまいますから容量のチェックは十分な注意が必要です。食いつぶすと「クリーンアップ」も受け付けなくなってしまいます。

※補足:「同期」というプロセスはあくまでも「本家」とのデータベース照合で、実際にはパッチのダウンロードは行っていないようです。実際に登録したPCへパッチを「承認」して配信する時点で「パッチ本体」をダウンロードしているようです。
私の環境ではプロクシをとおしているのですが、使用しているプロクシの I/O を zabbix で監視していると、どうも「同期」している時点ではパッチ本体のインターネットへのトラフィックは増えません。「承認」して配信が始まると、なんじゃこれ、というくらい、すごい勢いでプロクシのI/O が増えていました。
したがって、「承認」するタイミングも絶妙です。午後おそくに「承認」して定時後にボチボチ配信が始まる様にするのが良いのかも知れません。

お問い合わせはこちら
islandcenter.jp

-追加-
実際の日常の運用オペレーションはこちらに動画でまとめてみました。
Windows Update Service(WSUS) の日常の運用
WSUS のディスク容量がピンチ!空き容量を一挙に増やすには

-Keyword-
Windows update service WSUS 3.0 sp2 Windows8 Windows2012 0x800B0001 SUSE XEN Novell VMDP Virtual Machine Driver Pack 仮想化



http://xx.xx.xx.xx

[PR]
by islandcenter | 2013-04-03 18:43 | Windows | Trackback | Comments(0)