|
Hi nenad,
Here is a detailed setup for LVS-HA using a VRRP setup.
1. Topology description
-----------------------
In a "standard" design, when you are playing with a LVS/NAT setup, then you
need 2 IP classes. Consider the following sketch :
+---------------------+
| Internet |
+---------------------+
|
|
eth0 | 192.168.100.254
+---------------------+
| LVS Box |
+---------------------+
eth1 | 192.168.200.254
|
--------------+-------------
| |
| 192.168.200.2 | 192.168.200.3
+------------+ +------------+
| Webserver1 | | Webserver2 |
+------------+ +------------+
So you have 2 classes defining your both LVS-Box segments : 192.168.100.x
for WAN segment and 192.168.200.x for LAN segment.
For the LVS loadbalancing, we want to define a VIP 192.168.100.253 that
will loadbalance traffic on both 192.168.200.2 & 192.168.200.3.
For the LVS-Box HA we want to use VRRP setup to use a floating IP to handle
director takeover. When playing with LVS-NAT and VRRP, then you need 2 VRRP
instances, one for WAN segment and one for LAN segment. To make routing
path consitent then we need to define a VRRP synchronization group between
this both VRRP instances to be sure that both VRRP instances will have all
the time the same state.
2. VRRP Configuration description
---------------------------------
vrrp_sync_group G1 { # must be before vrrp_instance declaration
group {
VI_1
VI_2
}
}
vrrp_instance VI_1 {
interface eth0
state MASTER
virtual_router_id 51
priority 100
authentication {
auth_type PASS
auth_pass nenad
}
virtual_ipaddress {
192.168.100.253 # default CIDR mask is /32
}
}
vrrp_instance VI_2 {
interface eth1
state MASTER
virtual_router_id 52
priority 100
authentication {
auth_type PASS
auth_pass nenad
}
virtual_ipaddress {
192.168.200.253
}
}
This configuration will set IP 192.168.100.253 on eth0 and 192.168.200.253
on eth1
3. LVS Configuration description
--------------------------------
In order to use HA, we use VRRP VIP as LVS VIP so the LVS configuration
will be :
virtual_server 192.168.100.253 80 {
delay_loop 6
lb_algo rr
lb_kind NAT
persistence_timeout 50
protocol TCP
sorry_server 192.168.200.254 80
real_server 192.168.200.2 80 {
weight 1
HTTP_GET {
url {
path /testurl3/test.jsp
digest 640205b7b0fc66c1ea91c463fac6334d
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.200.3 80 {
weight 1
TCP_CHECK {
connect_timeout 3 # By default connection port is service
port
}
}
}
=> VRRP IP 192.168.100.253 will loadbalance traffic to both realservers.
4. Realservers Configuration description
----------------------------------------
And finally, the only things missing in our configuration is the
realservers default gateway... This is why we define a VRRP instance for
LAN segment. So
Realservers default gateway MUST be : VRRP VIP LAN segment =
192.168.100.253
5. Keepalived sumup Configuration
---------------------------------
! Configuration File for keepalived
global_defs {
lvs_id lvs01
}
vrrp_sync_group G1 { # must be before vrrp_instance declaration
group {
VI_1
VI_2
}
}
vrrp_instance VI_1 {
interface eth0
state MASTER
virtual_router_id 51
priority 100
authentication {
auth_type PASS
auth_pass nenad
}
virtual_ipaddress {
192.168.100.253 # default CIDR mask is /32
}
}
vrrp_instance VI_2 {
interface eth1
state MASTER
virtual_router_id 52
priority 100
authentication {
auth_type PASS
auth_pass nenad
}
virtual_ipaddress {
192.168.200.253
}
}
virtual_server 192.168.100.253 80 {
delay_loop 6
lb_algo rr
lb_kind NAT
persistence_timeout 50
protocol TCP
sorry_server 192.168.200.254 80
real_server 192.168.200.2 80 {
weight 1
HTTP_GET {
url {
path /testurl3/test.jsp
digest 640205b7b0fc66c1ea91c463fac6334d
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.200.3 80 {
weight 1
TCP_CHECK {
connect_timeout 3 # By default connection port is service
port
}
}
}
6. Keepalived sumup Configuration on BACKUP node
------------------------------------------------
! Configuration File for keepalived
global_defs {
lvs_id lvs02
}
vrrp_sync_group G1 { # must be before vrrp_instance declaration
group {
VI_1
VI_2
}
}
vrrp_instance VI_1 { # We just change state & priority
interface eth0
state BACKUP
virtual_router_id 51
priority 50
authentication {
auth_type PASS
auth_pass nenad
}
virtual_ipaddress {
192.168.100.253
}
}
vrrp_instance VI_2 {
interface eth1
state BACKUP
virtual_router_id 52
priority 50
authentication {
auth_type PASS
auth_pass nenad
}
virtual_ipaddress {
192.168.200.253
}
}
virtual_server 192.168.100.253 80 {
delay_loop 6
lb_algo rr
lb_kind NAT
persistence_timeout 50
protocol TCP
sorry_server 192.168.200.254 80
real_server 192.168.200.2 80 {
weight 1
HTTP_GET {
url {
path /testurl3/test.jsp
digest 640205b7b0fc66c1ea91c463fac6334d
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.200.3 80 {
weight 1
TCP_CHECK {
connect_timeout 3 # By default connection port is service
port
}
}
}
7. LVS-HA scenario
------------------
Now run all this on your both director and simulate a crash by unplug the
wire on LVS1 eth0 for example.
Detecting this trouble, VRRP will takeover eth0 instance on LVS2 and sync
eth1 instance on LVS2. So all traffic will run throught LVS2.
This a typical active/passive scenario.
If you want to extend this configuration to an active/active configuration,
then you need to add MASTER VRRP instances on your LVS2. active/active
configuration consist of one realserver pool segmentation. This mean that
you create 2 realservers pools (in the same IP range) but with a different
default gateway that will be the new VRRP LAN VIP. => This part will be
described more indepth in the documents I will write soon :)
Best regards,
Alexandre
|
