何をいまさら SUSE Linux にSquid

なにを今更 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 | プライベートクラウド