アシアルブログ

アシアルの中の人が技術と想いのたけをつづるブログです

Zabbix to the rescue!

Hello Anthony here, from infrastructure ( & England)

Well it’s with great relief that I've been allowed to write this in English so welcome to my first, and AFAIK Asial's first English-language blog.

The big news here in infrastructure is that we're getting towards the end of a rollout of the Zabbix network management system. This has been quite a long and protracted process as well as a steep learning curve for me. But first let me give you a bit of background.

Well as you might expect Asial has dozens of servers. Some of them, like the mail server or the main website are pretty high profile. Others, located in dark and far-flung corners of the organisation are much less obvious, but the fact is they're all important for someone. Our problem is how to keep an eye on them all, make sure they're working properly, have advance warning if they’re about to go wrong and immediate notification if they do.

Most of this information is available in the log files of course but who wants to spend all day trawling through those? Enter Zabbix. First of all you build your Zabbix server, then you install the Zabbix agent on all your other servers. The agent runs in the background collecting information about processor load, free disk space, running services and so on, and periodically sends this info back to your Zabbix server. And not just servers either, Zabbix can collect just about any information you want from just about any network device you can think of. Printers, routers, disk arrays – no problem.

The basic installation was pretty straightforward and the basic templates are enough to get you started but with all this information gathering potential, configuration has taken a while. In fact I expect to be tweaking this for a good while yet.

Anyway the good news is that it works, better than I ever thought. I can get an up to the minute overview of the server status any time, as well as detailed information on specific servers, times of spikes in load, long—term historical trends and goodness knows what else. And an email or text message if anything goes horribly wrong. Blimey, this is great stuff.



So how much does Zabbix cost and where can I get it? Well thanks to the hard work of Alexei Vladishev and the Open Source community, nothing, it’s free! You can download it from here

What did we do before Zabbix? I don't remember but it wasn't as pretty as this.

Thanks for reading and hope to have more for you next month
読んでくれてありがとう、また来月

Anthony

OpenVPNで細々便利な設定

以前OpenVPNについて紹介しましたが、今回はもう少し深い部分について書こうと思います。

1・ルート追加
例えば、下記のようにVPNサーバのセグメント以外に接続先ネットワークを指定する場合に使用できます。


|クライアント|-----|VPNサーバ|------|接続先サーバorネットワーク|


■サーバ側からpushする方法
接続する全クライアントに対して適用させることができます。

設定方法は簡単で、サーバ側の設定ファイルに下記のように追加してください。
※L3を使用している場合に使用可能な方法です。
 L2を使用する場合は調べきれていないので割愛。


push "route 192.168.10.0 255.255.255.0"


pushにて第一引数にクライアントで実行するコマンドを指定、
routeは、第一引数に接続先ネットワーク、第二匹数にネットマスクを指定

上記設定のみで、接続先ネットワークに行くにはこのVPNサーバを使用するという命令を発行できます。
OpenVPNサーバを再起動後、クライアントから接続すれば適用されているはずです。

実は、下記のように書けばメトリックを指定できますので、
PCでは年中OpenVPNを起動しておいて、社内に移動した時は通常のLANを使用(Metricが0なので)、社外に出た時はOpenVPN経由にするなどの使い方ができます。


push "route-metric 100"


■クライアント側で指定
一部のクライアントのみ有効にしたい場合などは、クライアント側に指定もできます。
指定というか、起動時にrouteコマンドを実行するだけですが、


route-up "route add -net 172.16.0.0/16 gw 10.0.0.1"

route-up で、任意のコマンドを実行できるので、routeコマンドを直接実行します。

■その他、クライアント側で指定する場合
L2で接続している場合は、見える範囲なら普通にrouteコマンドを使用出来ます。
L3で接続している場合ですが、クライアント側から出ていくためのゲートウェイが存在しますので、そこに投げればOKです。


※クライアントが192.168.100.6の場合
$ /sbin/route -n
(ry)
192.168.100.5     0.0.0.0          255.255.255.255 UH    0      0        0 tun0 <- VPN側のGWへのルート
192.168.10.0      192.168.100.5    255.255.0.0     UG    100    0        0 tun0 <- 接続先へはVPNのGWを通る


2・暗号化方式の変更

下記のように指定してやれば暗号化方式を変更することができます。
速度と強度の兼ね合いでお好きな物をご使用ください。


cipher aes-256-cbc

方式のアルゴリズムや強度については割愛します。
なお、自分の場合はAES256を使用しています。

こっちの方が重要で、AES-NI対応のCPUの場合は数倍のスループットを引き出せるようです。
※自分の場合はサーバが対応していないため未検証
設定は下記のようになります。


engine aesni


以上、少し便利にする設定でした。

Xen移行・・・ネットワークでハマる

お久しぶりです。門脇です。

最近、自宅サーバーをXenに統合しました。

旧環境は、Atomマシン + ノートPC + 玄箱 で構成していたので消費電力が低いのは嬉しいですが、性能は若干非力なため、新サーバー構築を決意。
一日中秋葉原をまわり、中古パーツをかき集めてきました。
(余談ですが、結局新サーバーの性能はML115の最低スペック+メモリとHDDを増設したものとほぼ同じとなったので、ぶっちゃけML115買った方がお得だったかもしれません)

Xenの構築自体は簡単で、



sudo apt-get install xen-tools linux-image-2.6.26-1-xen-amd64 xen-linux-system-2.6.26-1-xen-amd64 xen-utils-3.2-1 bridge-utils


あたりをインストールして、リブートしてxenを起動し、基本的な設定をすれば準備完了です。

Domain-Uの作成は


sudo xen-create-image --hostname hogehoge --dir=/var/lib/xend --memory 512Mb --size 2GB --dist lenny --ip 0.0.0.0

さくっとこんな感じで作成できます。
Debianは楽でいいですね。

早速起動します。


sudo xm create /etc/xen/hogehoge -c


実際の移行は、


old_machine# dpkg --get-selections > packages #リストを出力
old_machine# scp packages new_machine:        #リストをコピー
new_machine# dpkg --set-selections < packages #リストを入力
new_machine# apt-get dselect-upgrade          #インストール開始

とかすれば、パッケージをまるまるインストールできます。
その他は、rsyncかければ完成。


移行自体は楽にできましたが、ネットワークでハマりました。

旧構成では、

ルーター(172.16.0.1, 172.16.1.1)
ファイルサーバー(172.16.0.100, 172.16.1.100)
HTTPサーバー(172.16.1.10)
その他PCなど(172.16.0.10-100 DHCP)

になっており、
ルーターは 0x <-> 1x の通信は遮断。
1xと通信するときは、ファイルサーバーをルーターにしてアクセスしていました。

Xen構築後は、将来的には、XenにPPPoEをさせて完全にルーター化させるため、

0x -> 0.1(xen) -> 3.1(ルーター)
1x -> 1.1(xen) -> 3.1(ルーター)

とりあえずこんな構成に。


iptablesとrouteとbrctlを使用して、どうにか設定完了。

・・・がしかし。

外部から1xにsshで接続をして、ps aux など、多量に通信をするとフリーズ・・・。

ちなみに、
0x->1xは正常。
3x->1xは正常。

つまり、ルーター -> xen -> http
時だけ発生する模様。

現象の名前が分からないので、

debian パケット 多量 フリーズ
linux パケット フリーズ
ps aux フリーズ ssh

など、思いつく限りで検索をかけて見たところ、

PMTUD Black Hole

と言う言葉に当たる。

参考: http://www.infraexpert.com/info/5.2adsl.htm

要は、MTUの値が大きすぎると。

試しに、httpマシンにて、


sudo ifconfig eth0 mtu 1000

とすると・・・正常に動いた!

あとは、適当に値を設定して試してみると・・・ 1452 に落ち着く。

原因は調査中です。何か分かったら追加するかもしれません。


もし、一度に多量のパケットを扱う処理をしてフリーズするようなら、「PMTUD Black Hole」と言う言葉を思い出して見てください。なにか分かるかもしれません。