SLES12 より Squid プロクシが YaST からインストールできるようになったので、SLES12 SP3 で YaST インストーラからインストール、設定、起動までをやってみました。

- 参考 -

SUSE 11 で Squid3 を導入、設定

YaST > Software Management で調べると SLES12 sp3 で標準装備されているのは Squid 3.5 の様です。

a0056607_12252656.jpg

- Squid Proxy のインストール -

yast(yast2) より NetWork Service > Squid を Open します。YaST インストーラが起動し、自動的にインストールが開始されます。

a0056607_12261181.jpg


Start-Up : When Booting に変更

a0056607_12264319.jpg

HTTP Port は 3127 がデフォルトです。 ここでは 8080 に変更します。

a0056607_12270217.jpg

デフォルトでは最大キャッシュサイズ ( Max Object Size ) が小さいので大きな値を設定します。例えば Memory Cache 128 MB, Max Object Size 256Mb などです。Squid 専用サーバーであれば、これくらい与えても良いでしょう。

a0056607_12272542.jpg



Cache Memory と Max Object サイズを設定します。

キャッシュディレクトリのサイズは実装されたメモリ、ディスクのサイズに合わせて適度な数字を設定してみてください。また、キャッシュディレクトリは "/" ルートと違うパーティションに作成するのが理想です。特に物理的なハードディスクが違うパーティションを与えると、効果が上がります。SSD を使って割り当てると "爆速キャッシュ" になります。

a0056607_12281144.jpg
一旦、Squid キャッシュを再起動します。

確認くん

で確認してみました。
a0056607_12291638.jpg

Squid のバージョンが漏れています。

- 匿名性の確保 -

/etc/squid.conf を書き換え、次の行を追加しました。

visible_hostname unknown
forwarded_for off
request_header_access X-FORWARDED-FOR deny all
request_header_access Via deny all
request_header_access Cache-Control deny all

Squid を再起動して、もう一度確認くん


a0056607_12295289.jpg

Squid のバージョンを隠す事が出来ました。

- Squid cachemanager の設定 -

Squid cachemgr.cgi スクリプトが、Squid のインストールと同時に /usr/lib64 の下にコピーされます。これを /srv/www/cgi-bin の下にコピーします。

また apache2 がインストールされていなければ Apache2 をインストールしてください。

SUSE Linux (SLES12) で apache2 HTTPサーバー と PHP スクリプトのインストール

sles12sp3:~ # find / -name cachemgr.*
/usr/share/doc/packages/squid/scripts/cachemgr.readme
/usr/share/man/man8/cachemgr.cgi.8.gz
/usr/lib64/squid/cachemgr.cgi
/etc/squid/cachemgr.conf
/etc/squid/cachemgr.conf.default
sles12sp3:~ #
sles12sp3:~ # cp /usr/lib64/squid/cachemgr.cgi /srv/www/cgi-bin
sles12sp3:~ #

/etc/squid/cachemgr.cfg の localhost 行にポート番号(:8080)を追加しデフォルト 3128 から変更します。

sles12sp3:~ # vi /etc/squid/cachemgr.conf

: 編集中

sles12sp3:~ # cat /etc/squid/cachemgr.conf | grep localhost
localhost:8080
sles12sp3:~ #

ブラウザから cgi を開き "Cache Server" を トグルボタンで localhost:8080 に設定して "Continue" します。


a0056607_12324146.jpg


"Continue..."

a0056607_12332764.jpg

"Cache Clients:” のリンクを開くと、キャッシュのヒット率、ヒット数が表示されます。

a0056607_12340971.jpg
キャッシュのヒット率、ヒット数は、"ヒットしたキャッシュの量" を表すものではない事に注意してください。効率が良いキャッシュサーバーは、どれだけ、"トラフィック量" を捌いたかが重要です。実際、キャッシュ量は Squid キャッシュディレクトリの量を du コマンドなどで定期的に測って見るべきでしょう。

sles12sp3:~ # cd /var/cache/squid/
sles12sp3:/var/cache/squid # du -h
2.8M ./00/00
4.1M ./00/01
0 ./00/02

 : 中略

0 ./0F/FF
0 ./0F
6.9M .
sles12sp3:/var/cache/squid #

キャッシュは様々な理由で壊れたり、 Squid 自身がクラッシュする可能性もあるので、cron でキャッシュ最大サイズになる前に定期的に squid を停止させて、キャッシュディレクトリ全体を削除して再起動するのが良いでしょう。

実際の Squid の効率を調べる方法はこちらをご参考にしてください。

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

--
Squid の Local Cache は "効果がない" という意見もありますが、Cache サーバーを導入することで、インターネットの出入り口が交通整理されるため、混雑した環境では、ブラウザの動作が安定する場合があります。また、「遅い」と思う人ほど、最初のキャッシュミスヒットなので、遅いのは当たり前なんですね。

最近は動的コンテンツが多いため、あまり効果が分かりにくいのも事実です。

まぁ高速道路で "渋滞の中、加速したり止まったりで平均 40Km/h"で走るのと、"混んでいても 40Km/h で定速で安定して走っている"との違いのようなものなのですが、自動車の運転と違って、通信は目に見えないので、判りにくいのもよくわかります。

一人でも多くのユーザが利用できるようにすれば、静的コンテンツのキャッシュ効果が表れてきます。

「インターネットがブラウジングが遅い」というのは、相手サーバーとの距離でもありますし、多くはブラウザ内部のキャッシュを処理する使っているPCの性能の問題の様な気がします。相手サーバーとの間の MTU は経路のルータで 1,500 バイトに分割される事を忘れてはいけません。大抵は 1.5Kb 以上の画像などのコンテンツがあれば、やり取りを地球七周半/sec で経路中の装置のオーバーヘッドの影響を受けながら「行ったり来たり」しているのです。

また、Squid の負荷状態を様々なツールで分析できれば、ネットワークの実効容量が測れるので、その固定回線への固定投資は効果があるのかどうかの判断材料にもなります。



- Key Word -

SUSE Linux, SLES, SLES12, SLES12 SP3, Squid3.5, YaST, インストール, 導入, 設定


[PR]
by islandcenter | 2017-09-30 12:42 | SUSE | Trackback | Comments(0)

-現象-

ローカルネットワークから、Squid プロクシ経由でインターネット接続している場合、 Windows Update Service 3.0 (WSUS) サーバからアップデートできない。この現象は Windows7 環境では発生せず Windows10 以降(具体的には 1607以降)のバージョンで発生する。

Windows 10 / Windows Server 2016 を含め、プロキシ サーバーを介して Windows Update サイトへアクセスした際に、更新プログラムの検出が通信エラー (0x80240030 / 0x80072efe / 0x80244022 / 0x80072EFD / 0x80072EE2 等) でうまくいかない、あるいは更新プログラムのダウンロードが通信エラー (0x80072ee7 / 0x8024402c 等) で進まないといったお問い合わせをいただくことがございます。

プロキシ サーバー経由での Windows Update へのアクセスについて

また、WinHTTP に対してプロキシ サーバーが適切に設定されているかをご確認ください。

-------

「ナヌ! WinHTTP って聞いたことないぞな?」

と、どうやらインターネットマーケットで一般的な Squid などのプロクシ経由では、「WinHTTP という、我等大変困惑独善非標準的詳細非公開的謎通信網」はエラーになってしまうようですね。つまり、WSUS は HTTP(s) 80,443 ポートを使うにも関わらず、一般的な HTTP(s) ではなく WinHTTP というレッドチャイナ並の特殊で非公開な極秘な通信するという事なのですね。(はじめて知った......)

「うちは、ほぼ世界標準の Squid プロクシなんだけどなぁ.....」

という場合、例外リストに明示的にプロクシの設定から WSUS サーバーを除外する必要があるようです。

- 対策 -

ローカルLAN内に Squid などの Proxy がある場合、コントロールパネル > インターネットオプション > 「接続」タブ > プロシサーバー > 「詳細設定」ボタンから「例外」リストに

"*.mylocalzone.mycompany.com;" のローカルゾーンか WSUS の、生IP アドレス(192.168.1.xx;)などをセミコロン区切りで明示的に追加します。
a0056607_15232155.jpg

どうも Windows10 Version 1607 あたりから、WSUS の挙動がおかしくなったナとは思っていました。この場合、単純なLAN内部のプロキシキャッシュなので、月のモノのWindows Update をする場合、一時的にプロクシを外せばいいのですが、Windows10 1607 以降、Windows Update ってやたらと時間がかかるじゃないですか。その間、色々モンダイがあるわけですよ。まぁ、このケースではこれで「一応」解決できていますが。

例えば、 Windows Update の「更新プログラムのチェック」をしても、全部アップデートできない。その様なときは "オンラインで Microsoft Update から更新プログラムを確認します"をクリックすると "ご本尊" からのアップデートを更新して、 WSUS にアップデートがキャッシュされるようです。最初の1台目でキャッシュすると、以降はイントラネットの WSUS からアップデートを "ダウンロード"だけはしてくれるので、2台目以降は、 WSUS から、文字通り "Windows Update Service" のキャッシュが参照されて、ピピッと、"ダウンロードだけは" 行われます。もっともその後の「更新のインストール」だけは、ユーザさんには、朝のコーヒー飲んで、ついでにトイレにでも行ってPCの性能次第で「まったり待つ」必要があります。
a0056607_23382112.jpg
もっとも、Windows Update の”状態の更新”は、深夜に行われるようスケジュールされるので、実際の現場では "朝イチバン"に、パッチの適用と、 WSUS への通知が行くようです。月モノによっては二度のリブートが必要なケースもあるので、翌日もう一度"リブートしろ"と出るケースもあります。ユーザさんは待ち時間でゆっくりトイレで××コ「していても、インフラ担当者は、漏れそうでも「そんなヒマねぇよ」という我慢の時間帯です。

まぁこれも給料の一部だとおもって、諦めてください。あらかじめ総務にお願いして Windows Update を 「承認」した、翌数日間は、役員用トイレも解放しておくようお願いするのもイイかも。

a0056607_23400558.jpg
でも、同時にWSUS 上にも正しく更新された情報が伝わるようで、WSUS の登録されたPCの全てが数日後に 100% パッチ完了となります。やれやれ......

山市良のうぃんどうず日記(97):進まないWindows Update、やっぱり止まっていなかった

--

でセキュリティアプライアンスや、チャイニーズ製グレートファイアウォールなどが導入されている環境の場合、

Windows Update / Microsoft Update の接続先 URL について

によると、2017/2 現在....

http://download.windowsupdate.com
http://*.download.windowsupdate.com
http://download.microsoft.com
https://*.update.microsoft.com
http://*.update.microsoft.com
https://update.microsoft.com
http://update.microsoft.com
http://*.windowsupdate.com
http://*.windowsupdate.microsoft.com
http://windowsupdate.microsoft.com
https://*.windowsupdate.microsoft.com
http://ntservicepack.microsoft.com
http://wustat.windows.com
—————————-
※Windows 10 の配信の最適化を使用するためには以下の URL も併せて通信を許可するように設定ください。
—————————-
*.download.windowsupdate.com
*.au.windowsupdate.com
*.tlu.dl.delivery.mp.microsoft.com

の全てを、プロクシキャッシュなどの、セキュリティアプライアンスを使う経路から除外しろ、という事になりますね。これらを除外リストにズラズラと Windows10 の場合(;) セミコロンで区切って羅列します。(それも全部)

コピペ用に書いてみましたが、プロクシがある環境では、例外リストを「こうしろ」という事ですかね。間違っていたらご指摘下さい。
------ここから
*.download.windowsupdate.com;*.download.windowsupdate.com;*.download.microsoft.com;*.update.microsoft.com;*.windowsupdate.com;*.windowsupdate.microsoft.com;*.ntservicepack.microsoft.com;*.wustat.windows.com;*.download.windowsupdate.com;*.au.windowsupdate.com;*.tlu.dl.delivery.mp.microsoft.com;
ここまで-----

ちなみに

Windows Update / Microsoft Update サイトへの接続先 URL は不定期に変更されることがございますので変更が生じた際は本ブログも更新いたします。

とあるので要チェックです。(つまり予期なく変更ということで.... はぁ?)

セキュリティアプライアンスなどの設定も要注意ということになります。あるいは "WinHTTP という謎” を克服するか。

どうも

netsh winhttp set proxy proxy-server=

というインディジョーンズも解読できない呪文を管理者モードで実行せよというのもありです。

これで謎の WinHTTP も強制的に、システムプロクシの設定に合わせてしまうようです。世間一般および新華社通信によると、どうもこのコマンドはプロクシを使う環境では香港土産の謎の萬金丹のように良く効くようです。

プロキシ サーバーを使用する環境にて Windows Update を実行すると通信エラーが発生する

じゃ、トランスペアレントプロクシだとかセキュリティアプライアンスがインターネット接続のトポロジのグレートファイアウォールにある場合はどーなるンでしょうね。ウチの環境の場合 WSUS サーバーも LAN内にあるので、WSUS 自体も Squid Proxy を使う事(なぜか問題ない)になるので、とりあえずは問題解決ですが、トランスペアレントプロクシがグレートファイアウォールを作って、そこから経由して WSUS がローカルで構築していない環境では、ちょっと困ったモンダイになりそうな悪寒です。

また必ずしも、全て WSUS 3.0 経由では当たらない「累積パッチ」もあるようです。この問題は Windows2012r2 標準の WSUS 4.0 で解決しているかどうかはわかりませんが....やっぱりこれも謎の呪文を唱える必要があるようです。

Windows Update で通信系のエラーが出た場合、近所のセブンイレブンとかの無料、暗号化なし Wifi フリースポットへ走って(あるいはPCをかついで)アップデートし、ついでにウィルスクサいメールをかたっぱしから開きまくって、アンチウィルスが正しく動作しているかどうかテストしたり、銀行振込してパスワードダダ漏れさせてみる、のもヒマつぶしには面白いかもしれません。

Squid 本家の次の文書も見つけましたが、情報が古くて全然アテにならないようです。どうやら "Windows そのものの問題” と捉えているようなので、あの謎の萬金丹のコマンドを使え、という見解のようです。

How do I make Windows Updates cache?

全く、Windows10 anniversary Update 以降の Windows Update はどうも問題が謎な部分が多くあります。中国製かと思われるぐらい不可思議.....
Windows7 時代に構築して問題なかった WSUS の運用方法も Windows10 時代では適応できないようです。


-その他の記事-

Windows 2008R2 で作る WSUS 3.0 sp2 Windows Update Server

WSUS のディスク容量がピンチ!空き容量を一挙に増やすには

Windows Update Service(WSUS) の日常の運用

Windows10の Windows Update はデフォルトで使ってはいけない。



※言い訳:すみません、いつも「串」って言ってるんで「風呂串=プロクシ」と読ンじゃう私はやっぱり古いタイプなのです。世間では「風呂岸」なんですね。




Windows10 WSUS 3.0 Windows Update Error Squid Proxy キャッシュ、キャッシュアプライアンス、プロクシ、プロキシ、



[PR]
by islandcenter | 2017-06-16 15:20 | プライベートクラウド | Trackback | Comments(0)

SUSE Linux で squid を動かしていたXEN仮想サーバーを sp レベルでバージョンアップしたところ、/(ルートパーティション)と別イメージの Squid のキャッシュディレクトリを保持するSSDの仮想ディスクがマウントできなくなってしまいました。どうせ、キャッシュだし、という事で、Squid キャッシュディスクをフォーマットしてマウントしたり、色々やっているのですが、 Squid が起動できない。SSD に割り当ててマウントした /var/cache/squid 外すと上手く起動できるのですが。元のSSD に戻すと起動しない。

はて何ででしょう? という事で /var/log/messeges をダンプしてみます。

dnssquid: # cat /var/log/messages | grep squid

Feb 16 09:51:19 dnssquid squid[7191]: Squid Cache (Version 3.1.12): Exiting normally.
Feb 16 09:52:46 dnssquid squid: Failed to make swap directory /var/cache/squid/00: (13) Permission denied
Feb 16 09:53:23 dnssquid squid: Failed to make swap directory /var/cache/squid/00: (13) Permission denied
Feb 16 09:55:55 dnssquid squid: Failed to make swap directory /var/cache/squid/00: (13) Permission denied
Feb 16 09:57:37 dnssquid squid: Failed to make swap directory /var/cache/squid/00: (13) Permission denied
Feb 16 09:59:38 dnssquid squid: Failed to make swap directory /var/cache/squid/00: (13) Permission denied
Feb 16 10:00:25 dnssquid squid: Failed to make swap directory /var/cache/squid/00: (13) Permission denied
Feb 16 10:01:21 dnssquid squid[3691]: Squid Parent: child process 3693 started
Feb 16 10:01:21 dnssquid squid[3693]: Starting Squid Cache version 3.1.12 for x86_64-suse-linux-gnu...

: 中略

Feb 16 10:13:01 dnssquid squid[3473]: Using 32768 Store buckets
Feb 16 10:13:01 dnssquid squid[3473]: Max Mem size: 262144 KB
Feb 16 10:13:01 dnssquid squid[3473]: Max Swap size: 5632000 KB
Feb 16 10:13:01 dnssquid squid[3473]: /var/cache/squid/swap.state.new: (13) Permission denied
Feb 16 10:13:01 dnssquid squid[3473]: storeDirOpenTmpSwapLog: Failed to open swap log.
Feb 16 10:13:01 dnssquid squid[3465]: Squid Parent: child process 3473 exited with status 1
Feb 16 10:13:04 dnssquid squid[3465]: Squid Parent: child process 3479 started
Feb 16 10:13:04 dnssquid squid[3479]: Starting Squid Cache version 3.1.12 for x86_64-suse-linux-gnu...

Squid が起動するときに作成される、/var/cache/squid/xx ディレクトリや swap.state が作成できないという事のようです。 "Permission denied" と出るので調べてみると、 squid ディレクトリのオーナーが root になっていました。

dnssquid:/var/cache/squid # ls -al
total 176
drwxr-xr-x 18 root root 4096 Feb 16 10:25 .
drwxr-xr-x 19 root root 4096 Feb 16 10:04 ..
drwxr-x--- 258 squid nogroup 4096 Feb 16 10:25 00
drwxr-x--- 258 squid nogroup 4096 Feb 16 10:25 01
drwxr-x--- 258 squid nogroup 4096 Feb 16 10:25 02
drwxr-x--- 258 squid nogroup 4096 Feb 16 10:25 03
drwxr-x--- 258 squid nogroup 4096 Feb 16 10:25 04
drwxr-x--- 258 squid nogroup 4096 Feb 16 10:25 05
drwxr-x--- 258 squid nogroup 4096 Feb 16 10:25 06
drwxr-x--- 258 squid nogroup 4096 Feb 16 10:25 07
drwxr-x--- 258 squid nogroup 4096 Feb 16 10:25 08
drwxr-x--- 258 squid nogroup 4096 Feb 16 10:25 09
drwxr-x--- 258 squid nogroup 4096 Feb 16 10:25 0A
drwxr-x--- 258 squid nogroup 4096 Feb 16 10:25 0B
drwxr-x--- 258 squid nogroup 4096 Feb 16 10:25 0C
drwxr-x--- 258 squid nogroup 4096 Feb 16 10:25 0D
drwxr-x--- 258 squid nogroup 4096 Feb 16 10:25 0E
drwxr-x--- 258 squid nogroup 4096 Feb 16 10:25 0F
-rw-r----- 1 squid nogroup 102240 Feb 16 11:20 swap.state


dnssquid:/var/cache/squid # chown squid:nogroup /var/cache/squid

で治りました。

根本的な原因はアップデートする手順で誤りがあり、/etc/fstab にごみ行が入ってしまったのが原因なのですが、ここにたどり着くまでちょっと長かった。トラブルシューティングの良い練習になりました.....

lslandcenter.jp
[PR]
by islandcenter | 2016-02-16 14:58 | SUSE | Trackback | Comments(0)

SUSE 11 で Squid3 を導入、設定
の続き話です。

ユーザにとっては「ウェブアプリケーションが重い」と思うのは全てが「インフラの責任」と考えています。しかし、実際には、最高のインフラを与えても「重いものは重い」のです。多くはクライアント、ブラウザの性能と、通信遅延、相手のサーバーの負荷によるもののようです。

squid を使っていると時々トラフィックが上がり不安定な時があり、その場合は大抵 squid キャッシュを削除して、squid を再起動すると「治ってしまう」ようです。どうも、squid.conf で設定した閾値(threshold)付近で squid の動作が不安定になるようです。

となると、どのタイミングで「キャッシュをクリア」するかが問題となります。

-squidclient を使う-

squid:~ # squidclient -h localhost -p 8080 mgr:client_list
(-p は squid.conf で設定した値)

-cachemgr.cgi で調べる-

Cache Clients:
Address: 192.168.1.40
Currently established connections: 4
ICP Requests 0
HTTP Requests 3
TCP_MISS 3 100%

:
: 略
:

Address: 192.168.1.55
Currently established connections: 2
ICP Requests 0
HTTP Requests 31130
NONE 17 0%
TCP_HIT 1409 5%
TCP_MISS 15538 50%
TCP_REFRESH_UNMODIFI 2859 9%
TCP_REFRESH_MODIFIED 188 1%
TCP_CLIENT_REFRESH_M 2 0%
TCP_IMS_HIT 2764 9%
TCP_MEM_HIT 4236 14%
TCP_DENIED 4117 13%

Address: 192.168.1.28
Currently established connections: 0
ICP Requests 0
HTTP Requests 5
TCP_MISS 5 100%

TOTALS
ICP : 0 Queries, 0 Hits ( 0%)
HTTP: 50620 Requests, 14024 Hits ( 28%) <-- ここ注目

-ログから調べる-

access.log の MISS 行と HIT 行をカウントします。

squid:~ # cat /var/log/squid/access.log | grep MISS | wc -l
17843 <- ミスヒットしたアクセス数
squid:~ # cat /var/log/squid/access.log | grep HIT | wc -l
7539 <- ヒットしたアクセス数
squid:~ #


ただし、これではあくまでも「ヒット数」であり「実際のトラフィック」ではありません。


-キャッシュヒット数ではなく容量を-

そこで、実際にどれくらいの「量」がキャッシュされているのかを考えなければなりません。
du コマンドでキャッシュの「量」を測ってみます。

squid:~ # du -h /var/cache/squid/
4.0K /var/cache/squid/0B/E8
4.0K /var/cache/squid/0B/21

:
: 略
:

323M /var/cache/squid/
squid:~ #

今のところ 300M 程度のキャッシュが使われています。

-そのキャッシュは使われているの?-

squid:~ # ls /var/cache/squid -lR

実際に使われているキャッシュの日付があります。

/var/cache/squid/0E:
total 1024
drwxr-x--- 2 squid nogroup 4096 Nov 7 08:31 00
drwxr-x--- 2 squid nogroup 4096 Nov 7 08:31 01
drwxr-x--- 2 squid nogroup 4096 Nov 7 08:31 02

: 略


空のキャッシュもあります。
/var/cache/squid/0E/00:
total 0

/var/cache/squid/0F/FF:
total 0


-一日でキャッシュはどれだけ育つか-

squid:~ # /etc/init.d/squid stop
Shutting down WWW-proxy squid - wait a minute or two... .............done
squid:~ #

この間に squid のキャッシュを削除します。

squid:~ # rm /var/cache/squid/* -rf

squid を起動します。

squid:~ # /etc/init.d/squid start
Starting WWW-proxy squid done
squid:~ #

この状態から

squid:~ # du -h /var/cache/squid/

を実行して "xxxM /var/cache/squid/" の行を「毎日」チェックすると、「一日どれだけキャッシュが育つか」がわかるわけです。

-リアルタイムに iftop で状況を調べる-
コンソールで iftop コマンドを実行すると今の TX(送信)と RX(受信)状態がリアルタイムに監視できます。
a0056607_4185656.jpg


ただし、このコマンドをリモート端末から実行すると、アップデートのパケットも含まれてしまうため、あまり信頼性があるとは思えません。gnome の場合 gnome-system-monitor があるのでこりゃ便利と思って使ってみたら、半分の TX パケットはリモート端末からのものでした。

まぁ「ちょっとだけ見てみたい」場合には有効なツールだと思います。

-snmp 監視ツール-
mrtg や zabbix のような snmp を使った監視ツールは、比較的少ないクエリで、通信量をグラフ化してくれます。
a0056607_4231934.jpg


--
さまざまなツールでいったいどれくらいの「量」のデータが squid キャッシュを通り抜けているのかをいろいろ調べてみると、やっぱり3割から4割程度の通信が squid 経由で提供されているというのがなんとなくわかりました。だからと言ってブラウザ全体のパフォーマンスが異常によくなったということはあまりありません。

しかしPDFなどのドキュメント類は「爆速」です。
もし、PDF や画像を多用する事業所のネットワークであれば、ヒット率、よりも「ヒット量」に貢献する可能性は高いと思います。

実際に「何となく」調べてみると、ウチの様な零細事業所では週に1Gバイト以上、1日数百Mバイト程度「キャッシュが育つ」ことが解りました。これが多いか少ないかは微妙なところですが、明らかにある面ではブラウザの体感速度が上がるケースもあるわけです。この「キャッシュが育つ量」を使うブラウザの数で割ってみれば、大体ブラウザ一つでどれくらい効果があるのかわかるでしょう。ウチの場合、主に2台のPCを使っているわけですが、これが100台1000台となるとキャッシュ効果は結構なものとなるわけです。

実際、色々とLinux の ISO ファイルのダウンロードだとかをしているわけですが、巨大なファイルはキャッシュしても意味がありませんし、ブラウザ経由でsquidが「仕事」をしているのはこの程度なのですね。

--
最近はブラウザのバージョンアップが頻繁で、IEの古いバージョン(6はもちろん7,8,9までも)が対応していないため、仕方がないので他のブラウザも併用するケースもあります。となると結構な効果があります。社内業務はIE8で、GoogleApps は Chrome でといったケースですね。こうなると、エンドユーザは「好きなブラウザ」を使うしか方法はなくなります。もっとも Chrome はシステムの設定を使うことになるので Group Policy で制御できます。

また ls -lR コマンドでキャッシュの日付を見ると古いものも結構あります。古くても更新されていないコンテンツであれば、キャッシュを返してくれるわけですから、一概に「古いキャッシュはいらない」というのはちょっと無理ですが、実際、どれくらい「役に立つか」は納屋に繋がれた老馬の価値とか、昨日鶏が生んだ卵の新鮮さを判断するようなものです。

ここで重要になってくるのは「どのタイミングで古い」と判断するかでしょう。

業務によっては「昨日のキャッシュでも古い」ところもあれば、「一週間前のキャッシュでも」ありがたいところもあるということです。この判断は難しいところですね。

ただし du -h コマンドで測定した「キャッシュ量」と ls -lR コマンドでみたら、指定したキャッシュサイズに達したのに「キャッシュがないフォルダがある」ところが微妙です。

ということで、閾値に達するまでひと月、私の環境では月に一度、squid キャッシュをクリアして、squid を再起動するのがちょうど良さそうです。もう少し利用料が多くなれば、 squid キャッシュのクリアの間隔は短めにするか、 squid の閾値を上げるのがよさそうです。


-クラウド時代のキャッシュ-

さて、いろいろ見てきたところ

- Update 系のキャッシュはほとんど役に立たない。
- ストリーミング系はキャッシュされない。

また残念なことに

- アプリストア系のキャッシュはあり得ない。

ということがわかってきました。やれ「ブラウザでアプリケーションが使える」と言った Web App 系はほとんどキャッシュ効果はありません。

逆にタブレット系のアプリキャッシュもほとんど squid キャッシュでは効果がないと言えます。(ちゃんとマニュアルに書いてあるじゃん!)


第30章 Squidプロキシサーバ

また、FTP、Gopher、SSL、およびWAISの各プロトコルをサポートしていますが、Real Audio、news、またはビデオ会議など、他のインターネットプロトコルはサポートしていません。Squidは様々なキャッシュ間に通信を提供するUDPプロトコルのみをサポートしているため、他の多くのマルチメディアプログラムはサポートされません。

私は開発者ではありませんが、インフラ系の技術者として、開発者に「文句」を言うなら、「クラウドのキャッシュ」も考えて開発してほしいということです。勿論、アクセス数だとか利用者数なんかをリアルタイムに見たいという欲望はあるので、それは理解します。しかし余りにも開発者がインフラの容量を「無限大」に考えていることは問題だと指摘してみたいですね。私も開発者でしたから、「UNIX ではメモリは無限大につかっていい」と言われてマイコン向けプログラミングのケチケチしたメモリの使い方はいったん忘れたことがあります。

現実に、今まで5分かかっていたダウンロードがウェブキャッシュのおかげで30秒に短縮されたとしても、ユーザにとっては「待てない時間」であることは変わりありません。

先日 Windows 8 を 8.1 にアップデートしましたが、これは「最悪なクラウドアプリケーションのダウンロード方法」だと思います。この中にインフラ系技術者が入り込む工夫の余地はありません。

ブラウザで何でもできる、という幻想は既に時代遅れ。Evernote だとか SkyDrive だとかのクラウドサービスが出てくると、ブラウザ一辺倒ではなくなります。

クラウド時代のキャッシュサービスの考え方も見直さないといけないのでしょうね。



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

[PR]
by islandcenter | 2013-11-13 04:44 | SUSE | 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)

なにを今更 Squid なんだ。という事を突っ込まれそうですが、SUSE Linux に Squid を導入してみました

2000 年前後のインターネット回線はまだ128K などの低速回線だったし、ウェブサイトも固定コンテンツだったため、それなりにこの種のネットワークアクセラレータも必要でした。

しかし、その後、ブログ、SNS、動画配信、ユーザー嗜好やロケーション公告など、利用者側のニーズが変わってきたし、合わせてサービスも変化しました。回線も高速化すると、ウェブアクセラレータの必要性も下がります。

しかし、最近はタブブラウザばかりで、クラッシュした後自動保存したページを一気に開いたりすると、ストレスが貯まります。

-ちなみに-

以前は Novell BorderManger や volera excelerator などの爆速プロクシキャッシュを使う時、「プロクシ認証」をさせてIPアドレスではなく「誰がどこのサイトを閲覧したか」を記録するようなシステムを作り、このやり方が一時、流行りましたが、最近はあまりそのような話は聞きません。個人情報保護対策はどこへ行ったのでしょう。

しかし、まだ大手のISPなどでは Squid などのアクセラレータにコンテンツフィルタを組み込んで利用しているところもあるでしょう。先年まで日本通信の b-mobile を使っていましたが「高速化のお知らせ」というメールがきたので見てみると、何のことはないただのプロクシの設定方法を説明したものでした。ユーザ側サイトでプロクシを使うことよりも、WEBアクセラレータとしてISP側やサイト側が導入するケースに絞られてしまいました。

しかし、タブブラウザはじめ、LAN内のユーザが複数のPCやタブレットなどを利用すると、LANからインターネットへのトラフィックは一気に上昇します。

私は東京めたりっく以来のADSL回線なので、それほど不便は感じてきていませんでしたが、最近はやれディストリビューションのダウンロードだとかクラウドだとかを考えると、ちょっと回線効率を考えるようになります。結局ちょっと下調べものはモバイル3Gルータをつかうことになります。

もっとも100Kmしか出ない車にで東名高速に乗っていて200Km出る車に乗り換えると、確かに感動しますが、そうなると今度は300Km出る車に乗りたくなるわけで、その後は高速道路でパトカーで高速機動隊が赤旗振って待っていたというオチもありますから、「凡人余計なことを考えるべからず」で今の回線をどううまく使うかを考えています。

--
ということで今回は SUSE Linux に Suquid を導入してみました。

-インストール-
YaST > Software Management から Squid を Search します。本来は yast2-squid はチェックされているはずなのですが時折チェックが外れていることがあるので、確認してチェックします。
a0056607_15273553.jpg

Acept すると Squid がインストールされます。

あとは YaST の Squid アイコンから設定を行います。

-HTTP ポート
a0056607_15295024.jpg

デフォルトで300番台のポートが降られているのでここでは 80 に変えました。

-ACL
デフォルトでは xx許可>xx許可xx許可>あとは全て拒否(Deny) なので、全て許可(Any;allow) としました。最近は Google のように SSL 接続しか許可しないところも多く、デフォルトでは Google にアクセスできません。ホワイトリストを作っていくのも大変です。
a0056607_15351468.jpg

ということで、どうせ所内のネットワークだし、「性善説」をとることにしました。

※ちなみに ssl 通信はクライアント側で使わない設定にしたほうが Google さんには確実につながるようです。(チェックははずしておくこと)
a0056607_15472259.jpg


-キャッシュ
キャッシュディレクトリば /var/cache/squid です。できれば、このディレクトリを別なデバイスを使ってマウントしておくことをお勧めします。 df -h コマンドを使って空き容量を確認してMB単位で与えます。ここでは仮想環境なので 10G のディスクを /var/cache/squid にマウントして 9990Mb 与えました。
a0056607_15583966.jpg


-保存して起動
あとは、 Save & restart するだけです。 When Booting もチェックしておきます。
a0056607_15413441.jpg


-入れてみて-

-決して早くなるわけではない-

いまどきのウェブサービスは動的なコンテンツが多いので、静的な画像や同じ広告のバナーを表示するのは速いことは早いのですが、html ソース自体が二度目のアクセスで書き換えられるケースも多く、決して「早くなった」ということはありません。逆にキャッシュされた差分の更新のため、ページの表示が一時停止してしまい、リロードなどが必要なケースも増えます。特にウェブページの先頭に別サイトへの広告リンクやSNSへのリンクがあるサイトはあまり高速化されません。

そもそもローカルキャッシュが先に使われるわけですから、同じページを見たときに「早い」と思うか「遅い」と感じるかは、そもそもPC自体の使い方、性能の問題です。プロクシが間に入る分、オーバーヘッドがあるので、一概に「早く快適」になるものではありません。

かつて「爆速キャッシュ」だった NetWare ベースの BorderManager とは時代も機材も状況も違うので、構内LANエッジとしての Squid の効果はあまりないように思えます。

個人的には Squid よりも、エッジの効率化を目的としたキャッシュアプライアンンスを導入したほうがよいように思います。


- PCが安定した -

早くなるか > ほとんど No です。何しろプロクシがあっても、ローカルキャッシュの方がよいに決まっています。

 ディストリビューションのダウンロードなどは、「あまりいじらない」仮想PCで行うのが一番確実なのですが、LAN内に「暴れん坊PC」が一台あるとたちまち回線は混雑してくれます。彼らが動画サイトなどにアクセスすると、他でダウンロードが途切れたりするのですが、構内LANにあるキャッシュを経由するようになると、トラフィックの交通整理をしてくれるためなのか、非常に安定した速度でダウンロードしてくれます。また、利用者のPCとサイトの接続をプロクシが代理応答するわけですから、たとえ遅くてもユーザシステムの通信負荷は若干減ります。実際 Proxy を使ってみてもらうと、よく落ちていたシステムが安定したという話は聞きます。逆に「プチフリーズしたか」という面もあります。

もちろん「暴れん坊」のアクセスは途切れたりするわけですが、これはこれで「ルールを守って100Kmで走ろう」ということであれば、仕方のないことです。

高速道路には、日常物資を運ぶトラックも走っているというわけです。

-再起動するとダウンロードがエラーになる-

当たり前ですが、Squid は設定を変更して再起動すると、これまでキャッシュ経由してダウンロードしていたリクエストは全部キャンセルされます。設定の変更は十分な計画とテストを行うべきでしょう。

-明示的にキャッシュを指定する必要がある-

アプリケーションによっては明示的にキャッシュサーバを指定しなければならないものがあります。

Windows 本題のIE や Chrome, Safari や SUSE Linux 本体はシステムのデフォルトを使用しますが Firefox(手動設定かシステムデフォルトとの切り替えはユーザ任意) Opera は自分で設定する必要があります。他のアプリケーション、特にアップデート系のアクセスは不明です。グループポリシーで設定できないと、ユーザに明示的に利用させるしかないでしょう。

100 台のマシンに Google Chrome を導入する際にダウンロードできるのは「本体」ではなくインストーラだけです。インストーラが Google さんから本体をダウンロードさせます。

アプリケーションではプロクシを使った場合どのような結果になるか、明らかにしている場合もあれば、まったく公開していない場合もあります。アナライザで調べるしか方法はありません。

簡単にボタンひとつで変更ができればよいのですが、プロクシの設定は管理者権限が必要なので、一般ユーザ権限でプロクシの設定を変えることはできないのは何とかしたいものです。

一応 tcpmon などのツールで見る限り、これらのアプリケーションのアップデートはシステムのデフォルトプロクシを使っているようですが例外も多くあります。Windows Update Server 並に利用中のアプリケーションのアップデートが始まったら、ユーザになるべく同じ時間帯にアップデートさせれば、効果はあるのかもしれません。

一番よいのは、トランスペアレントプロクシを使うことですが、耐障害性を考えると複数用意したいところです。しかし複数用意するとキャッシュ効果も下がるため、お勧めできるものでもありません。また、ネットワークの設計がかなり複雑になります。凝ったネットワークデザインは「マニアック」に陥りやすく運用面でトラブルが出るとお手上げになります。

ただし、全てのトラフィックがプロクシを経由するため、通信状況(ログ)の把握やブラックリストの管理は容易になります。

-キャッシュ容量-

これだけ光だDSLだ動画だSNSだとなると、今まで数Gもあれば良かったキャッシュ容量も膨大になります。本当に「効果」を感じるには数百Gバイト単位でウェブキャッシュを使う必要がありそうです。

たとえば、3G通信などは3Gバイトの転送制限をしている、あるいはOCNの光通信では月間アップロード量が30Gあると「お仕置き」が待っているように、1日1人1Gというのが最低の目安だとすれば、100人で1日100Gは最低。できれば1Tくらいのキャッシュ容量がなければ「快適になった」という実感はなさそうです。

となると squid 本体が動作するどこかのディスクにキャッシュを用意しなければならないということになります。デフォルトは /var/cache/squid なので、ここだけ別パーティション、別デバイスとするべきでしょう。しかし、iSCSI デバイスなどを使う限り、ローカルLAN内のトラフィックを増やすだけなので、DAS接続したドライブを使うべきなのかもしれません。


-それでも入れて見るべきかウェブキャッシュ-

これは技術の問題よりモラルの問題かもしれません。固定専用回線であっても、上位のISPがパンクするようでは意味がないので、クラウドを有効活用するには、少しでも自分たちの回線の「効率化」と「整流化」を考えても良いと思います。

ここでもし自分たちのためにウェブキャッシュを導入しようとするならば、自分たちの構内に置かなければまったく意味がないということです。データセンターにウェブキャッシュをおきたいというお客様がいましたが、データセンター自体、巨大なウェブキャッシュを持っているだろうから、まったく効果はありません。センターと構内を結ぶエッジに置くべきものです。

-DNSと同居-

ウェブキャッシュはDNSと同居させるのが一番楽な方法です。アドレスクエリを内部で処理できるため、余分なトラフィックを作らないでしょう。ただし、DNS本体が肥大化するため、この点でも設計は結構難しいかもしれません。


-問題はCIFSのアクセラレーション-

これは現実にお客様で聞いた話なのですが、某社の高価なCIFSアクセラレータを100人程度のリモートオフィスに導入したところ、全く役に立たなかったという話を聞いたことがあります。結局、そこでは全社的に Novell iFolder を導入しました。(現在はオープンソース化されています)結局 Windowsサーバ + CIFS を諦めて、全社的に Novell NCP (Port 524) を使った OES サーバを利用することになったようでした。結果的には CIFS キャッシュより NCP プロトコルの方が効率は良かったようです。エッジの効率化はまだまだ問題が多そうです。


islandcenter.jp
[PR]
by islandcenter | 2012-11-30 18:18 | プライベートクラウド