Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Keepalived knowledge carding

2025-04-03 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

Shulou(Shulou.com)06/02 Report--

Outline of the article

Preface

VRRP introduction

Keepalived detailed explanation

Preface

Keepalived is a highly available solution for LVS services based on VRRP protocol, which can be used to avoid a single point of failure. As we all know, in a LVS cluster, although LVS can schedule client requests based on IP, LVS itself does not provide high reliability, that is, fault tolerance. And LVS can only schedule client services to back-end servers for processing based on some scheduling algorithm, but cannot check the status of back-end servers, so we need a tool to implement these functions, and keepalived can just provide these functions. In a high availability cluster (HAC) formed by keepalived and LVS, at least two servers are required to run Keepalived and one master server (MASTER) One is a backup server (BACKUP), but it appears as a virtual IP (VIP in LVS). The master server will send a specific message to the backup server. When the backup server does not receive this message, that is, when the master server goes down, the backup server will take over the virtual IP and continue to provide services, thus ensuring high availability. Keepalived is a perfect implementation of VRRP, so before introducing keepalived, let's introduce the principle of VRRP.

VRRP introduction

1 VRRP concept

VRRP is the abbreviation of "Virtual Router Redundancy Protocol", that is, virtual routing redundancy protocol. It is a fault-tolerant protocol, which ensures that when the next-hop router of the host fails, another router will replace the failed router to work, so as to maintain the continuity and reliability of network communication. VRRP has the following advantages:

Simplify network management. In a local area network (such as Ethernet) with multicast or broadcast capability, VRRP can still provide a highly reliable default link when a device fails, effectively avoiding the problem of network interruption after a single link failure, without modifying the configuration information such as dynamic routing protocol, route discovery protocol, or the default gateway configuration of the host.

Adaptable. VRRP packets are encapsulated in IP packets and support a variety of upper layer protocols.

The network overhead is small. VRRP defines only one kind of message-VRRP advertisement message, and only routers in Master state can send VRRP message.

2 VRRP working process

1) the router in the virtual router elects the Master according to the priority. By sending free ARP messages, the Master router notifies its virtual MAC address to the device or host connected to it, thus undertaking the task of message forwarding.

2) Master routers periodically send VRRP messages to announce their configuration information (priority, etc.) and working status

3) if the Master router fails, the Backup router in the virtual router will re-elect the new Master according to the priority

4) during the state switching of the virtual router, the Master router switches from one device to another, and the new Master router simply sends a free ARP message with the virtual router's MAC address and virtual IP address information, so that the ARP related information in the host or device connected to it can be updated. Hosts in the network are not aware that the Master router has switched to another device.

5) when the priority of the Backup router is higher than that of the Master router, it is the operation of the Backup router (preemptive and non-preemptive) that determines whether or not to re-elect the Master.

In the end, in order for the Master router and the Backup router to work together, VRRP needs to implement the following functions:

Election of Master Router

Advertisement of Master router statu

At the same time, in order to improve security, VRRP also provides authentication function

3 MSTER election method

VRRP determines the role of each router in the virtual router (Master router or Backup router) based on priority. The higher the priority, the more likely it is to become a Master router. The initially created router works in the Backup state and learns the priority of other members of the virtual router through the interaction of VRRP messages:

If the priority of the Master router in the VRRP message is higher than its own, the router remains in the Backup state

If the priority of the Master router in the VRRP message is lower than its own, the router in preemptive mode will preempt into the Master state and send VRRP messages periodically, while the router in non-preemptive mode will remain in Backup state.

If the VRRP message is not received within a certain period of time, the router switches to Master

The VRRP priority ranges from 0 to 255. the higher the value, the higher the priority, and the configurable range is from 1 to 254. priority 0 is used when the system is reserved for the router to relinquish the Master location, and 255 is reserved for the IP address owner. When the router is the owner of the IP address, its priority is always 255. Therefore, when there is an IP address owner in the virtual router, it is a Master router as long as it is working properly.

4. Three authentication methods of VRRP

No authentication: no legal authentication of any VRRP messages and no security guarantee.

Simple character authentication: in a network that may be threatened by security, the authentication method can be set to simple character authentication. The router that sends the VRRP message fills the authentication word into the VRRP message, while the router that receives the VRRP message compares the authentication word in the received VRRP message with the locally configured authentication word. If the authentication word is the same, the received message is considered to be a legitimate VRRP message; otherwise, the received message is considered to be an illegal message.

MD5 authentication: in a very insecure network, the authentication method can be set to MD5 authentication. The router that sends the VRRP message encrypts the VRRP message using the authentication word and MD5 algorithm, and the encrypted message is stored in the Authentication Header (authentication header). The router that receives the VRRP message will use the authentication word to decrypt the message and check the validity of the message.

Keepalived

1 keepalived working principle

Keepalived is a highly available service software developed based on the principle of vrrp, and it has health-check function, which can be used to provide dual-computer floating vip (vrrp virtual routing function), so that a dual-computer hot standby high availability function can be easily realized. Keepalived implements high availability on the basis of VRRP virtual routing redundancy protocol, and can also be regarded as a protocol to achieve high availability of routers, that is, N routers with the same function are formed into a router group, in which there is a master and multiple backup,master with an external service vip (the default route of other machines in the local area network of the router is this vip), and master will send multicast When the backup does not receive the VRRP packet, it is considered that the master is down, so it is necessary to elect a backup as the master according to the priority of the VRRP. In this way, the high availability of the router can be ensured. The following is the official KeepAlived component diagram

As can be seen from the above figure, keepalived is also a modular design, and different modules implement different functions. It mainly has three modules, namely core, check and VRRP, among which:

Core module: the core component of keepalived, responsible for the startup and maintenance of the main process and the loading and parsing of global configuration files

Check module: responsible for health check-up, including common check-up methods

VRRP module: to implement the VRRP protocol.

System call: system call

Watch dog: monitors the management process of check and vrrp processes, which is used to achieve high availability for check and vrrp processes.

Checkers: responsible for detecting the health status of the child process and notifying vrrp to transfer it to the backup server when it detects that a service on the master is not available.

2 keepalived action

Keepalived is mainly used for the health check of RealServer and the implementation of failover between LoadBalance host and BackUP host. The role of Keepalived is to detect the status of the web server. If a web server crashes or fails, Keepalived will detect and remove the malfunctioning web server from the system. When the web server works normally, Keepalived automatically adds the web server to the server farm. All these tasks are completed automatically, without human intervention, and all you need to do is to repair the faulty web server.

3 keepalived profile

Keepalived is a relatively lightweight service and works very well with LVS. It has only one configuration file, which mainly includes settings for global_defs, static_ipaddress, static_routes, VRRP_script, VRRP_instance and virtual_server. These configurations can be divided into three categories: global configuration, VRRP configuration and LVS configuration.

1) Global configuration

Global_defs {# Block id notification_email {admin@example1.com # indicates the mailbox that received keepalived information.} notification_email_from admin@example.com # mailbox name smtp_server 127.0.0.1 # host address smtp_connect_timeout 30 # integer Seconds router_id my_hostname # A string that marks the host May not be a hostname. It is recommended to use the hostname vrrp_mcast_group4 224.0.0.18 # Multicast Group address. The default is 224.0.0.18 vrrp_mcast_group6 ff02::12 # ipv6 Multicast Group address. The default is ff02::12 enable_traps # to enable SNMP traps, but not to enable}.

2) VRRP configuration

VRRPD configuration includes three classes: VRRP synchronization group (synchroization group), VRRP instance (VRRP Instance), and VRRP script

* VRRP instance (s) * # describes the moveable IP for each instance of a group in vrrp_sync_group. Here are described two IPs # (on inside_network and on outside_network), on machine "my_hostname", which belong to the group VG_1 and which # will transition together on any state change. Vrrp_instance inside_network {state MASTER # interface eth0 # use_vmac # Use VRRP Virtual MAC. # vmac_xmit_base # VMAC interface dont_track_primary # track_interface {eth0 eth2...} mcast_src_ip # Multicast Group Source ip unicast_src_ip Unicast_peer {...} lvs_sync_daemon_interface eth2 garp_master_delay 10 # secs Default 5 virtual_router_id 51 priority 100 # priority advert_int 1 authentication {# Authentication Information Module auth_type PASS auth_pass 1234 # Authentication password It is recommended to use "openssl rand-hex 4" to generate an 8-bit random password} virtual_ipaddress {# vrrp instance / brd dev scope label # address definition format 172.18.14.7777 and 24 dev eth2 # address + interface 172.18.14. 66Accord 24 dev eth3 label eth3:1 172.18.14.55 Blade 24 # can also write address directly} virtual_ipaddress_excluded {/ brd dev scope / brd dev scope.} virtual_routes {# Virtual Gateway Src 192.168.100.1 to 192.168.109.0 to 192.168.109.0 via 192.168.200.254 dev eth2 192.168.110.0 dev eth2 192.168.200.254 dev eth2 192.168.111.0 dev eth2 192.168.112.0 via 192.168.100.254 or 192.168.113.0 / 24 via 192.168.200.254 or 192.168.100.254 dev eth2 blackhole 192.168.114.0/24} nopreempt nopreempt preempt_delay 300 # waits 5 minutes debug # Debug level Not implemented yet. # notify scripts, alert as above notify_master | notify_backup | notify_fault | notify | smtp_alert}

3) LVS configuration

If you do not configure LVS+keepalived, you do not need to configure this area, if you are using nginx instead of LVS, you do not need to configure this, the LVS configuration here is specifically for keepalived+LVS integration. It uses keepalived configuration file instead of ipvsadm to configure LVS, not using ipvsadm to configure, this will be much more convenient, a configuration file to do these, maintenance is also convenient. The LVS configuration also has two configurations: one is the definition of the cluster, that is, the VIP is specified, and the other is to add the real server address.

* Virtual server (s) * fwmark # firewall tag. If you are a LVS based on firewall tag, you need to set this item virtual_server group string {# configure virtual server Can be virtual_server IP port | virtual_server fwmark int delay_loop # delay timer for service polling lb_algo rr | wrr | lc | wlc | lblc | sh | dh # LVS scheduler ops # Enable One-Packet-Scheduling for UDP (- O in ipvsadm) lb_kind NAT | DR | TUN # LVS forwarding method persistence_timeout # LVS persistence timeout Sec persistence_granularity # LVS granularity mask (- M in ipvsadm) protocol TCP # Only TCP is implemented ha_suspend # If VS IP address is not set,suspend healthchecker's activity virtualhost # VirtualHost string for HTTP_GET or SSL_GET Eg virtualhost www.firewall.loc alpha omega quorum hysteresis quorum_up | quorum_down | sorry_server # RS to add when all realservers are down real_server {weight # relative weight to use Default: 1 notify_up | notify_down | HTTP_GET | SSL_GET {# select HTTP_GET if it is http Select the url visited by SSL_GET url {# for a health check when you https You can determine the delayed connect_ip of multiple url digest # A url to test can have multiple entries here status_code # status code returned in the HTTP headereg status_code 200} delay_before_retry # after failure. # connection IP address connect_port # connection port bindto bind_port connect_timeout # connection timeout fwmark warmup} TCP_CHECK { # definition of TCP_CHECK-based health detection module connect_ip connect_port bindto bind_port connect_timeout fwmark warmup} SMTP_CHECK {# health check module based on mail service Host {connect_ip connect_port bindto bind_port connect_timeout fwmark} retry delay_before_retry Helo_name | warmup} MISC_CHECK {misc_path | misc_timeout warmup misc_dynamic}

Summary of this chapter

The above analysis of almost all the configuration information of keepalived.conf, in some places I directly quote the official instructions, without translation, I feel that the English is more accurate. Of course, there are some options that have not been explained in detail, which I will explain in the following article. The following article will understand the meaning of these instructions from examples and actual cases, of course, not all instructions will be used in actual production, we will choose the most important one to define it, and it will be easy to think about it at that time.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report