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

Chapter 2. Keepalived Overview


Keepalived runs on an active LVS router as well as one or more optional backup LVS routers. The active LVS router serves two roles:
  • To balance the load across the real servers.
  • To check the integrity of the services on each real server.
The active (master) router informs the backup routers of its active status using the Virtual Router Redundancy Protocol (VRRP), which requires the master router to send out advertisements at regular intervals. If the active router stops sending advertisements, a new master is elected.

Note

Red Hat does not support rolling updates of keepalived where the configuration changes the VRRP version to use. All routers must be running the same version of VRRP in a keepalived load balancer configuration. A VRRP version mismatch will lead to the following messages:
Aug  3 17:07:19 hostname Keepalived_vrrp[123]: receive an invalid ip number count associated with VRID!
Aug  3 17:07:19 hostname Keepalived_vrrp[123]: bogus VRRP packet received on em2 !!!
Aug  3 17:07:19 hostname Keepalived_vrrp[123]: VRRP_Instance(vrrp_ipv6) ignoring received advertisment...
Red Hat recommend that all systems should run the same keepalived version and keepalived configurations should be identical where possible to avoid compatibility issues.

2.1. A Basic Keepalived Load Balancer Configuration

Figure 2.1, “A Basic Load Balancer Configuration” shows a simple Keepalived Load Balancer configuration consisting of two layers. On the first layer is one active and several backup LVS routers. Each LVS router has two network interfaces, one interface on the Internet and one on the private network, enabling them to regulate traffic between the two networks. For this example the active router is using Network Address Translation or NAT to direct traffic from the Internet to a variable number of real servers on the second layer, which in turn provide the necessary services. Therefore, the real servers in this example are connected to a dedicated private network segment and pass all public traffic back and forth through the active LVS router. To the outside world, the servers appear as one entity.
A Basic Load Balancer Configuration

Figure 2.1. A Basic Load Balancer Configuration

Service requests arriving at the LVS router are addressed to a virtual IP address, or VIP. This is a publicly-routable address the administrator of the site associates with a fully-qualified domain name, such as www.example.com, and is assigned to one or more virtual servers. A virtual server is a service configured to listen on a specific virtual IP. A VIP address migrates from one LVS router to the other during a failover, thus maintaining a presence at that IP address. A VIP is also known as a floating IP addresses.
VIP addresses may be assigned to the same device which connects the LVS router to the Internet. For example, if eth0 is connected to the Internet, then multiple virtual servers can be assigned to eth0. Alternatively, each virtual server can be associated with a separate device per service. For example, HTTP traffic can be handled on eth0 at 192.168.1.111 while FTP traffic can be handled on eth0 at 192.168.1.222.
In a deployment scenario involving both one active and one passive router, the role of the active router is to redirect service requests from virtual IP addresses to the real servers. The redirection is based on one of eight supported load-balancing algorithms described further in Section 2.3, “keepalived Scheduling Overview”.
The active router also dynamically monitors the overall health of the specific services on the real servers through three built-in health checks: simple TCP connect, HTTP, and HTTPS. For TCP connect, the active router will periodically check that it can connect to the real servers on a certain port. For HTTP and HTTPS, the active router will periodically fetch a URL on the real servers and verify its content.
The backup routers perform the role of standby systems. Router failover is handled by VRRP. On startup, all routers will join a multicast group. This multicast group is used to send and receive VRRP advertisements. Since VRRP is a priority based protocol, the router with the highest priority is elected the master. Once a router has been elected master, it is responsible for sending VRRP advertisements at periodic intervals to the multicast group.
If the backup routers fail to receive advertisements within a certain time period (based on the advertisement interval), a new master will be elected. The new master will take over the VIP and send an Address Resolution Protocol (ARP) message. When a router returns to active service, it may either become a backup or a master. The behavior is determined by the router's priority.
The simple, two-layered configuration used in Figure 2.1, “A Basic Load Balancer Configuration” is best for serving data which does not change very frequently — such as static web pages — because the individual real servers do not automatically sync data between each node.
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.