Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 4. Initial Load Balancer Configuration with Keepalived


After installing Load Balancer packages, you must take some basic steps to set up the LVS router and the real servers for use with Keepalived. This chapter covers these initial steps in detail.

4.1. A Basic Keepalived configuration

In this basic example, two systems are configured as load balancers. LB1 (Active) and LB2 (Backup) will be routing requests for a pool of four Web servers running httpd with real IP addresses numbered 192.168.1.20 to 192.168.1.24, sharing a virtual IP address of 10.0.0.1. Each load balancer has two interfaces (eth0 and eth1), one for handling external Internet traffic, and the other for routing requests to the real servers. The load balancing algorithm used is Round Robin and the routing method will be Network Address Translation.

4.1.1. Creating the keapalived.conf file

Keepalived is configured by means of the keepalived.conf file in each system configured as a load balancer. To create a load balancer topology like the example shown in Section 4.1, “A Basic Keepalived configuration”, use a text editor to open keepalived.conf in both the active and backup load balancers, LB1 and LB2. For example:
vi /etc/keepalived/keepalived.conf
A basic load balanced system with the configuration as detailed in Section 4.1, “A Basic Keepalived configuration” has a keepalived.conf file as explained in the following code sections. In this example, the keepalived.conf file is the same on both the active and backup routers with the exception of the VRRP instance, as noted in Section 4.1.1.2, “VRRP Instance”

4.1.1.1. Global Definitions

The Global Definitions section of the keepalived.conf file allows administrators to specify notification details when changes to the load balancer occurs. Note that the Global Definitions are optional and are not required for Keepalived configuration. This section of the keepalived.conf file is the same on both LB1 and LB2.
global_defs {

   notification_email {
       admin@example.com
   }
   notification_email_from noreply@example.com
   smtp_server 127.0.0.1
   smtp_connect_timeout 60
}
The notification_email is the administrator of the load balancer, while the notification_email_from is an address that sends the load balancer state changes. The SMTP specific configuration specifies the mail server from which the notifications are mailed.

4.1.1.2. VRRP Instance

The following examples show the vrrp_sync_group stanza of the keeplalived.conf file in the master router and the backup router. Note that the state and priority values differ between the two systems.
The following example shows the vrrp_sync_group stanza for the keepalived.conf file in LB1, the master router.
vrrp_sync_group VG1 {
   group {
      RH_EXT
      RH_INT
   }
}

vrrp_instance RH_EXT {
    state MASTER
    interface eth0
    virtual_router_id 50
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass passw123
    }
    virtual_ipaddress {
    10.0.0.1
    }
}

vrrp_instance RH_INT {
   state MASTER
   interface eth1
   virtual_router_id 2
   priority 100
   advert_int 1
   authentication {
       auth_type PASS
       auth_pass passw123
   }
   virtual_ipaddress {
       192.168.1.1
   }
}
The following example shows the vrrp_sync_group stanza of the keepalived.conf file for LB2, the backup router.
vrrp_sync_group VG1 {
   group {
      RH_EXT
      RH_INT
   }
}

vrrp_instance RH_EXT {
    state BACKUP
    interface eth0
    virtual_router_id 50
    priority 99
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass passw123
    }
    virtual_ipaddress {
    10.0.0.1
    }
}

vrrp_instance RH_INT {
   state BACKUP
   interface eth1
   virtual_router_id 2
   priority 99
   advert_int 1
   authentication {
       auth_type PASS
       auth_pass passw123
   }
   virtual_ipaddress {
       192.168.1.1
   }
}
In these example, the vrrp_sync_group stanza defines the VRRP group that stays together through any state changes (such as failover). There is an instance defined for the external interface that communicates with the Internet (RH_EXT), as well as one for the internal interface (RH_INT).
The vrrp_instance line details the virtual interface configuration for the VRRP service daemon, which creates virtual IP instances. The state MASTER designates the active server, the state BACKUP designates the backup server.
The interface parameter assigns the physical interface name to this particular virtual IP instance.
virtual_router_id is a numerical identifier for the Virtual Router instance. It must be the same on all LVS Router systems participating in this Virtual Router. It is used to differentiate multiple instances of keepalived running on the same network interface.
The priority specifies the order in which the assigned interface takes over in a failover; the higher the number, the higher the priority. This priority value must be within the range of 0 to 255, and the Load Balancing server configured as state MASTER should have a priority value set to a higher number than the priority value of the server configured as state BACKUP.
The authentication block specifies the authentication type (auth_type) and password (auth_pass) used to authenticate servers for failover synchronization. PASS specifies password authentication; Keepalived also supports AH, or Authentication Headers for connection integrity.
Finally, the virtual_ipaddress option specifies the interface virtual IP address.

4.1.1.3. Virtual Server Definitions

The Virtual Server definitions section of the keepalived.conf file is the same on both LB1 and LB2.
virtual_server 10.0.0.1 80 {
    delay_loop 6
    lb_algo rr
    lb_kind NAT
    protocol TCP

    real_server 192.168.1.20 80 {
        TCP_CHECK {
                connect_timeout 10
        }
    }
    real_server 192.168.1.21 80 {
        TCP_CHECK {
                connect_timeout 10
        }
    }
    real_server 192.168.1.22 80 {
        TCP_CHECK {
                connect_timeout 10
        }
    }
    real_server 192.168.1.23 80 {
        TCP_CHECK {
                connect_timeout 10
        }
    }

}
In this block, the virtual_server is configured first with the IP address. Then a delay_loop configures the amount of time (in seconds) between health checks. The lb_algo option specifies the kind of algorithm used for availability (in this case, rr for Round-Robin; for a list of possible lb_algo values see Table 4.1, “lv_algo Values for Virtual Server”). The lb_kind option determines routing method, which in this case Network Address Translation (or nat) is used.
After configuring the Virtual Server details, the real_server options are configured, again by specifying the IP Address first. The TCP_CHECK stanza checks for availability of the real server using TCP. The connect_timeout configures the time in seconds before a timeout occurs.

Note

Accessing the virtual IP from the load balancers or one of the real servers is not supported. Likewise, configuring a load balancer on the same machines as a real server is not supported.
Table 4.1. lv_algo Values for Virtual Server
Algorithm Namelv_algo value
Round-Robin
rr
Weighted Round-Robin
wrr
Least-Connection
lc
Weighted Least-Connection
wlc
Locality-Based Least-Connection
lblc
Locality-Based Least-Connection Scheduling with Replication
lblcr
Destination Hash
dh
Source Hash
sh
Source Expected Delay
sed
Never Queue
nq
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.