ネットワーク備忘録

アラフォーエンジニアのネットワーク系の備忘録。twitter:@deigo25374582

続・LVS検証(DSR)

前回の検証からちょっと追加で確認

↓が前回のやつ

klock-3rd.hatenablog.com

 

前回は、Web1、Web2にWRRで分散していたけど、以下の2点が気になった
1.普段はWeb1のみにアクセスさせ、Web1が死んだ時のみWeb2へアクセスさせる。

2.DSR方式でLeast Connectionしたらどういう風になるんだろ?

 

1.普段はWeb1のみにアクセスさせ、Web1が死んだ時のみWeb2へアクセスさせる。

Active/Standby方式をLVSでやる場合をちょっと調べてみた。
Big-IPとかだと、PriorityGroup機能、NetScalerだとBackupServer機能が↑に近い事を実現させられそうだけど、LVSではどうなんだろう・・・と

 

まず、単純にWeb2の重みを0にすればいいんじゃね? という発想
ただし、この場合は、Web1が死ぬとWeb1&Web2が0になるため、クライアントからのアクセスがエラーになる可能性大

 

web_servers.conf

virtual_server_group web_servers {
192.168.10.110 80
}

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

real_server 192.168.10.103 80 {
weight 1
inhibit_on_failure
HTTP_GET {
url {
path /health_check.html
status_code 200
}
connect_port 80
connect_timeout 3
}
}
real_server 192.168.10.104 80 {
weight 0
inhibit_on_failure
HTTP_GET {
url {
path /health_check.html
status_code 200
}
connect_port 80
connect_timeout 3
}
}
}

 この状態でLVSの状態確認

[root@LVS1 ]# 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.10.110:80 wrr
-> 192.168.10.103:80      Route     1         0                  9
-> 192.168.10.104:80      Route     0         0                  0

これは想定どおり。 実際Weightを0にしたところには振り分けられず。
そして、「.103」のサーバのhttpdをstopして確認。

[root@LVS1 keepalived]# 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.10.110:80 wrr
-> 192.168.10.103:80      Route   0    0    0
-> 192.168.10.104:80      Route   0    0    0

この状態でWebでアクセスすると・・・・・やはりアクセスできない。
一応、前回と同様にCiscoのshow ip arpで確認したら、ARPテーブルにはVIPがいたから、やはりLVSでDropしてるっぽい。

 

そこで、sorryでやってみる。

web_servers.conf

virtual_server_group web_servers {
192.168.10.110 80
}

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

sorry_server 192.168.10.104 80

real_server 192.168.10.103 80 {
weight 1
inhibit_on_failure
HTTP_GET {
url {
path /health_check.html
status_code 200
}
connect_port 80
connect_timeout 3
}
}
#real_server 192.168.10.104 80 {
#weight 1
#inhibit_on_failure
#HTTP_GET {
#url {
#path /health_check.html
#status_code 200
#}
#connect_port 80
#connect_timeout 3
#}
#}
}

 

この設定で、LVSの状態を確認

[root@LVS1 keepalived]# 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.10.110:80 wrr
-> 192.168.10.103:80       Route  1    0     0

勿論、これだと「.103」にしかパケットは転送されない。
この状態もう一度「.103」のhttpdを落とす。

[root@LVS1 keepalived]# 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.10.110:80 wrr
-> 192.168.10.103:80       Route  0    0     0
-> 192.168.10.104:80       Route  1    0     0

Sorry_serverで設定した項目が浮上してきた。
一応これだと、Active/Standbyチックな動きは出来る。
(ただ、Standby側についてはLVSでは監視していないことになる。)

 

2.DSR方式でLeast Connectionしたらどういう風になるんだろ?

F5や、CitrixでのLB構築がほとんどだったので、大体負荷分散方式といえばLeast Connectionだった。 ただし、これらアプライアンスはセッションを管理できたから実現できるけど、LVSのDSR方式だとサーバからの戻りのパケットがLVSを経由しないため、セッション管理は出来ないのではないか?という想定

そんなわけで、「lvs_sched lc」に変えて、別PCからWeb1の実IPアドレス宛てにHTTPアクセス(F5連打)しつつ、HTTPのVIPにアクセスしてみた。

 

[root@LVS1 keepalived]# 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.10.110:80 lc
-> 192.168.10.103:80      Route   1    0    19
-> 192.168.10.104:80      Route   1    0    20
[root@LVS1 keepalived]#

 

検証に作ったのは静的ページという点と、HTTPはコネクションを張りっぱなしというわけではないから、検証としては完璧ではないにしろ、VIPへのアクセスが均等に割り振られている事も考えると、DSR方式ではセッション管理は出来ていないような雰囲気。 

 

とりあえず検証おわり