LVS ロードバランサ (3) VRRP

こんばんは、Cです。

LVS ロードバランサのフィナーレは、
LVS自体の冗長化だ。

もう1機LVSを追加しAct/Std構成にする。

■LVS01の仮想IPを解除する
VIPはkeepalivedのVRRPで管理するため、
前回まで使用していた、eth0:0を削除する。

#vi /etc/network/interfaces
auto lo eth0 bond0
iface lo inet loopback
allow-hotplug eth0 eth1 eth2

iface eth0 inet static
address 192.168.24.161
netmask 255.255.255.0
gateway 192.168.24.1

#iface eth0:0 inet static
#address 192.168.24.160
#netmask 255.255.255.0
#gateway 192.168.24.1

iface bond0 inet static
address 10.10.10.11
netmask 255.255.255.0
broadcast 10.10.10.255
slaves eth1 eth2

■LVS02をセットアップ
　・ifslave,ipvsadm,keepalivedのインストール
　・LVS01にあわせてネットワーク設定

■LVS01 VRRP設定

vrrp_instance VI {
state BACKUP
interface bond0
garp_master_delay 5
virtual_router_id 1
priority 101
nopreempt
advert_int 1
authentication {
auth_type PASS
auth_pass p@ssw0rd
}
virtual_ipaddress {
192.168.24.160/24 dev eth0
}
}


virtual_server_group PROXY10 {
192.168.24.160 8080
}

virtual_server group PROXY10 {
delay_loop 3
lvs_sched wrr
lvs_method DR
protocol TCP


real_server 10.10.10.10 8080{
weight 1
inhibit_on_failure

TCP_CHECK {
connect_port 8080
connect_timeout 2
}
}

real_server 10.10.10.20 8080{
weight 1
inhibit_on_failure

TCP_CHECK {
connect_port 8080
connect_timeout 2
}
}

}

■LVS02 VRRP設定

vrrp_instance VI {
state BACKUP
interface bond0
garp_master_delay 5
virtual_router_id 1
priority 100
nopreempt
advert_int 1
authentication {
auth_type PASS
auth_pass p@ssw0rd
}
virtual_ipaddress {
192.168.24.160/24 dev eth0
}
}


virtual_server_group PROXY10 {
192.168.24.160 8080
}

virtual_server group PROXY10 {
delay_loop 3
lvs_sched wrr
lvs_method DR
protocol TCP


real_server 10.10.10.10 8080{
weight 1
inhibit_on_failure

TCP_CHECK {
connect_port 8080
connect_timeout 2
}
}

real_server 10.10.10.20 8080{
weight 1
inhibit_on_failure

TCP_CHECK {
connect_port 8080
connect_timeout 2
}
}

}

LVS01と違うのはpriorityだけ。

■VRRPを動かす

1号機のkeepalivedを動作させる。

#/etc/init.d/keepalived start

syslogにMASTERとなった事が出力されていれば、OK。

#ip addr show eth0
2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 08:00:27:ff:3b:21 brd ff:ff:ff:ff:ff:ff
inet 192.168.24.161/24 brd 192.168.24.255 scope global eth0
inet 192.168.24.160/24 scope global secondary eth0

VIPが設定されているはずだ。

次に2号機でもkeepalivedを動作させよう。
2号機はBACKUPとなりVIPは振られない。

■障害テスト

１．クライアントからVIP宛にping -t しておこう。
２．LVS01をshutdownする。
３．pingは途切れず、クライアントからブラウザでPROXY経由でWebが見れる事を確認

自分の場合は1回だけPing応答が途切れたが、タイミングの問題だろう。

以上、動作も問題ない。

LVS ロードバランサ (2) keepalived

Cです。

前回作成したロードバランサはリアルサーバが死んでいても、
ロードバランスアルゴリズムに基づいてパケットを投げつける。

クライアントから見ればたまに接続不能状態になる。
ロードバランスアルゴリズムが「lc」になっていた場合、
セッション数が一番少ないリアルサーバにパケットを投げつけるので、
リアルサーバが1台死んでしまうと、死んでいるやつに投げつけ続ける状態に
陥ってしまうことまである。

そこで登場「keepalived」だ。

リアルサーバをLVSから監視し続けて死んでいると判断した場合に、
重み付け設定を変えたり、LVSの設定からはずしてしまったり出来る。

■keepalived インストール

#apt-get install keepalived

■ipvsadm設定初期化
前回設定したipvsadmの設定は消しておこう。
なぜならkeepalivedによってipvsadmの設定を自動的に行うからだ。
2重になって変な動きにならないようにね。

#echo "" > /etc/ipvsadm.rules
#ipvsadm -C
#ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn

設定が消えたことを確認。OK。

■keepalived.conf の作成

#vi /etc/keepalived/keepalived.conf
virtual_server_group PROXY10 {
192.168.24.160 8080
}

virtual_server group PROXY10 {
delay_loop 3
lvs_sched wrr
lvs_method DR
protocol TCP

#sorry_server none

real_server 10.10.10.10 8080{
weight 1
inhibit_on_failure

TCP_CHECK {
connect_port 8080
connect_timeout 2
}
}

real_server 10.10.10.20 8080{
weight 1
inhibit_on_failure

TCP_CHECK {
connect_port 8080
connect_timeout 2
}
}

}

こんな感じだ、今回はsorry_serverは設定していない。
2個のリアルサーバに対して、8080ポートにアクセスし応答が無ければweightを0にする。
ロードバランスアルゴリズム「wrr」を設定している場合はこういう風にすればいい。

応答が無ければipvsadmから外しちゃう設定もあるけど、
ipvsadm -Lnで視覚的に確認できない為、こっちのほうが良い。

keepalivedはrunlevel 2で自動的に起動するようになっているので再起動して
設定できているか確認しておこう。
確認できたら障害テストをしてみよう。　

■障害テスト
PROXY01へログインしてsquidをストップする。

#/etc/init.d/squid stop

LVS01へ戻って状態を確認。

#ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.24.160:8080 wrr
-> 10.10.10.10:8080 Route 0 0 0
-> 10.10.10.20:8080 Route 1 0 2

PROXY01のWeightが0になっていることを確認。
クライアントからブラウザでWebへアクセスし接続できることを確認。

PROXY02のsquidも落とすと、全滅の為アクセスは出来なくなる。
その後両PROXYのsquidを復活させて、アクセスできることが確認できれば問題なかろう。

ここまでくれば後一息だ、
次はVRRPを使い、LVSをもう1機追加してLVSのAct/Std構成を取る。

以上、

iptables 設定保存

こんばんは、Cです。

iptablesの設定をinterfaceがdownする前に保存し、
interfaceがupする前に読み込む設定をする。

■保存設定

#vi /etc/network/if-post-down.d/iptables
#!/bin/sh
iptables-save > /etc/iptables_rule.save
exit 0

これだけ、ただ単にiptables-saveを実行してファイルに書き出してるだけ。

■読み込み

#vi /etc/network/if-pre-up.d/iptables
#!/bin/sh
iptables-restore < /etc/iptables_rule.save
exit 0

これだけ、保存の逆をしただけ。

以上。

電子回路 LEDを光らせる

hi.C desu.

レタスプラントを製作したときもLEDはたくさん使ったのだけれども、

その時にLEDを何個も破裂させて、電気、電子の基礎の大切さを学んだ。

基本的なところがわかっていない、出来たらいいでやっていくと

いずれ困ったことになるだろう、だから私は１からやり直すことにした。

■やる事

　乾電池4本で1個のLEDをまばゆく光らせる。

■回路考察

　乾電池4本なので６Vの電圧でスタートすることになる。

　LEDのデータシートでは「DC Forwerd Current」は「30mA」と記載されている。

　そのため大体半分以下の10mAくらい流してやることにしよう。

　LEDのデータシートでは「DC Forwerd Voltage」は「2.0V」とある。

　オームの法則から抵抗は「400Ω」と導き出されるが、400Ωの抵抗見たこと無い。

　そのため「390Ω」のでいいや。

■シミュレート結果

結果としては回路全体に10.75mAの電流が流れた、
この辺は電子パーツの特性によって誤差はでるだろう。許容範囲だ。
抵抗が390Ωの為、LEDにかかる電圧は1.81Vだ、２Vより低いけどぜんぜん許容範囲。
LEDには優しい回路が出来上がった。

まあ、４Vほど無駄になっているので、電池2本でもLEDを光らせることは出来る。
その場合はredisterは100Ωほどでよかろう。

いまさらこんな基礎かと思うけど基礎は大切。
今後も続けていこう。

以上。

LVS ロードバランサ (1) LVS

Cです。

LVSでのロードバランサ構築方法をまとめておく。(DSR方式）

まずはdebian6.03(squeeze)を最小構成（標準もチェックはずす）でインストール。
openssh-serverをインストールしておく。

今回はLAN内にあるPROXYサーバなどの負荷分散することを目的としたLVSを構築する。
インターネットにへ出て行くような通信を受ける機器の過労死を防ごう。

既存ネットワークがフラットなネットワークであれば、
下の図のように導入するのがいいんだが、

これはさすがに試すのがしんどいので、シンプル構成にした。こんな感じ。
L3設計はIPアドレスから妄想してくれ。

2重になってるとこを全部省いてLVS同士のvrrpを
既存のネットワーク側インターフェイスでやり取りするようにした。
ネットワーク構成として正しいのかどうかわからないが、まあいい。

■必要なパッケージインストール

#apt-get install ifenslave ←チーミングするんだから
#apt-get install ipvsadm
#apt-get install bridge-utils

■ipvs 初期設定

#dpkg-reconfigure ipvsadm

自動的にロードするを選択。

これはマスターを選択

■パケット転送ON

#vi /etc/sysctl.conf
↓この部分を
#net.ipv4.ip_forward=1
↑コメントアウトをはずして↓こうする
net.ipv4.ip_forward=1

■LVS01のip address設定

#vi /etc/network/interface

auto lo eth0 eth0:0 bond0
iface lo inet loopback

allow-hotplug eth0 eth1 eth2

iface eth0 inet static
address 192.168.24.161
netmask 255.255.255.0
gateway 192.168.24.1

iface eth0:0 inet static
address 192.168.24.160
netmask 255.255.255.0
gateway 192.168.24.1

iface bond0 inet static
address 10.10.10.11
netmask 255.255.255.0
broadcast 10.10.10.255
slaves eth1 eth2

■PROXY01のip address設定

#vi /etc/network/interface

auto lo bond0 eth2
iface lo inet loopback

allow-hotplug eth0 eth1 eth2

iface bond0 inet static
address 10.10.10.10
netmask 255.255.255.0
broadcast 10.10.10.255
slaves eth0 eth1

iface eth2 inet static
address 192.168.24.163
netmask 255.255.255.0
broadcast 192.168.24.255
gateway 192.168.24.1

■PROXY02のip address設定

#vi /etc/network/interface

auto lo bond0 eth2
iface lo inet loopback

allow-hotplug eth0 eth1 eth2

iface bond0 inet static
address 10.10.10.20
netmask 255.255.255.0
broadcast 10.10.10.255
slaves eth0 eth1

iface eth2 inet static
address 192.168.24.164
netmask 255.255.255.0
broadcast 192.168.24.255
gateway 192.168.24.1

■疎通確認(LVS01とPROXY01,PROXY02の間）

#ping 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
64 bytes from 10.10.10.10: icmp_req=1 ttl=64 time=2.32 ms

# ping 10.10.10.20
PING 10.10.10.20 (10.10.10.20) 56(84) bytes of data.
64 bytes from 10.10.10.20: icmp_req=1 ttl=64 time=3.39 ms

疎通OK
プロキシの構築方法はここでは説明しない。
LVSなしの状態でプロキシ経由でWebを見れることを確認する。

■ロードバランス設定(一時的)

#ipvsadm -A -t 192.168.24.160:8080 -s rr
↑VIPに対してのロードバランスサービスを定義してあげる。

#ipvsadm -a -t 192.168.24.160:8080 -r 10.10.10.10 -g
#ipvsadm -a -t 192.168.24.160:8080 -r 10.10.10.20 -g
↑リアルサーバたちを紐付けてあげる。

rrってのはロードバランスアルゴリズムを指定しているんだ。
他にもいろんなアルゴリズムがあるが、
メジャーなのは下のやつら。（manを参照すれば全部書いてあるよ）

■ロードバランスアルゴリズム

rr : ラウンドロビン。実サーバに順番にリクエストを渡す。
wrr : 重み付け(eeight)ラウンドロビン。重み付け設定(weight)が有効になる。
lc : 最小コネクション数。接続数が一番少ないサーバにリクエストがいく。
wlc : 重み付け(weight)最小コネクション数。重み付け設定(weight)が有効になる。
lblc : クライアント(Locality-Based)に応じた最小コネクション数。
　　　　同じクライアントからのリクエストは同じ実サーバにいく。
　　　　接続数が多い場合は別の実サーバにいく。

■動作テスト（結果は失敗する）
クライアントのWebブラウザにプロキシを設定（↑の例だと192.168.24.160）
適当なサイトへアクセスする。
表示されない。

なぜか。

tcpdumpでパケットを追っかけてみると当然だと納得できるだろう。

クライアントからLVSへ渡されるパケットのdestination IPはLVSの持っているVIPだ、
そこでLVSはipvsの設定(DSR)に従い、リアルサーバへ投げつける。
この時もdestination IPはLVSの持っているVIPだ。（↑の例だと192.168.24.160)

でも、リアルサーバ達はそんなIP自分達のじゃないので破棄しちゃう。

これが接続できない原因。当たり前のことなんだよ。


■リアルサーバへ到着したパケットのdestination IPを書き換える

#iptables -t nat -A PREROUTING -d 192.168.24.160 -j REDIRECT

destination IP をリアルサーバの物に書き換えて自分(リアルサーバ)に
渡してあげれば、問題無く受け取れるようになる。

ここではiptablesについては詳しくは書かないが、
PREROUTINGはそのマシンのNICに到着したパケットを
最初に処理するところだと思っておけば間違いは無い。

そして！つぎに！PROXY(リアルサーバ)がインターネットへパケットを投げるとき！
（正確にはdefault gw経由だけど）
パケットのsource IP は クライアントのIPアドレスだ！！！
これがDSRの魅力だ。

PROXYからgatewayへ渡されたパケットはアドレス変換してインターネットに出て行くが、
変換元のsouce IPはクライアントIPアドレスだ！！！
これがDSRの魅力だ。

インターネットから帰ってきたパケットはgatewayで変換テーブルに覚えておいた物に
変換すると思うのだけど、このときにdestination IPアドレスをクライアントのIPに
変換してくれる。（ごく普通のIPマスカレードの動作）

結果、gatewayはLVSやPROXYを経由せずにクライアントにパケットを送ったとさ。
めでたしめでたし。



このまま再起動するとipvsadmの設定消えます。

■ipvsadm設定保存

#/etc/init.d/ipvsadm save
#cat /etc/ipvsadm.rules
# ipvsadm.rules
-A -t 192.168.24.160:8080 -s rr
-a -t 192.168.24.160:8080 -r 10.10.10.10:8080 -g -w 1
-a -t 192.168.24.160:8080 -r 10.10.10.20:8080 -g -w 1

ipvsadmは起動時に/etc/ipvsadm.rulesの中身を自動設定してくれる。
再起動してちゃんと設定されてるか確認しとこう。

#ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.24.160:8080 rr
-> 10.10.10.10:8080 Route 1 0 0
-> 10.10.10.20:8080 Route 1 0 0

ちゃんと設定されていた。

PROXY側のiptablesも起動時に読み込むようにしておこう。
再起動後にも、正常に動作していることを確認しておこう。

以上、LVSの設定はこんな感じ。
ただ、この状態だとLVSはダウンしているリアルサーバにも遠慮なくパケットを投げつける。
そこでkeepalivedの登場。LVSからkeepalivedを使ってリアルサーバを監視して、
応答が無かったりしたらipvsの設定からはずしたりする設定をしてやる。

お楽しみに。

scp SSHを使ってファイル転送

こんばんわ、Cです。

sshを使ってファイルを送る。
設定ファイルのコピーのときによく使う。

#ssh -p /etc/squid/squid.conf root@192.168.24.164:/etc/squid/

-p オプションは送信元ファイルのタイムスタンプを引き継ぐ。

以上

Linux NIC チーミング

Cです。こんばんは

debian系でのチーミングの方法を書いておく。
Redhat系では必要なパッケージ名が違う。（iputilsだったかな）

ifenslaveでカーネルモジュールのbondingをコントロールする
インストールしとこう。

■インストール

#apt-get install ifenslave

■カーネルモジュールbonding読み込み

#echo "bonding" >> /etc/modules
#modprobe bonding

■bondingモジュール設定

#touch /etc/modprobe.d/bonding
#echo "options bonding miimon=2000 mode=0" >> /etc/modprobe.d/bonding
#modprobe bonding

■modeについて

　0: load balancing (round-robin):ラウンドロビン方式。
　　　使用できるスレーブデバイスから順にデータの送受信を行い、負荷分散と冗長化に対応する。
　1: fault-tolerance (active-backup):アクティブ・バックアップ方式。
　　　1つのスレーブがアクティブでありそのスレーブに障害が起きたとき自動的に他のスレーブを使用し、
　　　冗長化に対応
　2: load balancing (xor):XOR方式。
　　　同じ送信先のMACアドレス対して同じスレーブを使用し、負荷分散と冗長化に対応　　
　3: fault-tolerance (broadcast):
　　　全部のスレーブデバイスでデータの送信を行う。
　4: IEEE 802.3ad Dynamic link aggregation:IEEE 802.3ad ダイナミックリンク集合方式。
　　　IEEE 802.3adに対応しているスイッチを用いて、Speed(通信速度100M/1Gb等）と
　　　Duplex(全／半二重設定)が同じグループを作って、 全てのスレーブデバイスで
　　　データの送受信をする。
　5: transmit load balancing:
　　　送信時のみ負荷分散を行い受信時は冗長化(MACアドレスを引き継ぐ)
　6: adaptive load balancing:アクティブロードバランシング方式。
　　　送受信共に負荷分散を行う

■NICの死活監視(miimon or arp)
miiに対応したNICであればmiiで監視して
対応してなければarpで監視をする。
miiを使えばネットワークにパケットを出さないのでそっちのほうがいい。
大抵対応している。

このコマンドでmii対応しているか確認できる。

#mii-tool

Operation not supportedとか出なければ対応している。

監視間隔はmiimonで設定する（※ミリ秒単位）

options bonding miimon=2000 mode=0

arpのほうで監視する場合は下記のように設定する。
(※intervalはミリ秒単位!!!!!!!!間違うとえらいことになる）

arp_interval=1000 arp_ip_target=IPアドレス,IPアドレス

あとはネットワークの設定ファイルをいじくろう。

■設定サンプル(eth0とeth1をbond0にまとめる設定)

#vi /etc/network/interfaces

auto lo bond0 eth2
iface lo inet loopback

allow-hotplug eth0 eth1 eth2

iface bond0 inet static
address 10.10.10.10
netmask 255.255.255.0
broadcast 10.10.10.255
slaves eth0 eth1

iface eth2 inet static
address 192.168.24.163
netmask 255.255.255.0
broadcast 192.168.24.255

以上、これはよく使うのでいい加減覚えておきたい。

ntfs を読み書きする

こんばんはCです。

linuxはもともと、ntfsへアクセスできない。
でも残念なことに、アクセスする必要があるタイミングが結構ある。

Windowsを使わされている友人のノートPCのデータ救済等など、
DDで事足りることもあるが、できたほうが中身確認できるから良いぞ。

あと、Windowsがディスクにインストールされているマシンで、
外部メディアからlinuxを起動したりして使っている場合などは超使う。

■インストール(squeezeではデフォルトでリポジトリに入ってるからこれだけ）

#apt-get install ntfs-3g

■ntfsをマウント
先に適当にマウントポイントを作っておこう。
そしてmout コマンドのタイプ指定でntfs-3gを指定してやろう。

#mount -t ntfs-3g /dev/sdb1 /media/gates

よくマウントする場合は/etc/fstabに書いてやれば良いみたい。
問題なく動作した。

ベテルギウス 爆発の可能性

こんばんは、Cです。

最近プライベートが忙しく、
ブログ更新もネタがたまっていって記事にできない状態が続いています。

オリオン座の周りの4つの星のうちの1つ、「ベテルギウス」
この星は直径が太陽の1000倍。地球から640光年の距離にある。
とっても大きなお星様である。

オーストラリアの研究者が「2012年に星の最後を向かえ爆発し、地球にとって2つ目の太陽となる可能性がある」といっている。

星が最後に爆発することを「超新星爆発（supernova）」という。
ベテルギウスは現在急速に収縮中で、爆発前の現象だとのこと。
もちろん640光年先にあるので、すでに爆発している可能性はある。

地球もいつか爆発してしまうんだろうから、
目指すところは宇宙への移住かな。