xunaa 4.1。基本的Keepalived配置
在此基本示例中，两个系统配置为负载平衡器。 LB1（主动）和LB2（备份）将请求路由到由四个运行httpd 的Web 服务器组成的池，其真实IP 地址编号为192.168.1.20 到192.168.1.24，共享虚拟IP 地址为10.0.0.1。每个负载均衡器都有两个接口（eth0 和eth1），一个用于处理外部Internet 流量，另一个用于将请求路由到真实服务器。使用的负载均衡算法是循环算法，路由方法是网络地址转换。
4.1.1。创建keapalived.conf文件
Keepalived 通过配置为负载均衡器的每个系统中的keepalived.conf 文件进行配置。要创建负载均衡器拓扑，如第4.1 节“基本Keepalived 配置”中所示，请使用文本编辑器打开主用和备用负载均衡器LB1 和LB2 中的keepalived.conf。例如：
vi /etc/keepalived/keepalived.conf 具有第4.1 节“基本Keepalived 配置”中详细介绍的配置的基本负载平衡系统有一个keepalived.conf 文件，如以下代码部分所述。在此示例中，keepalived.conf 文件在活动路由器和备份路由器上相同，但VRRP 实例除外，如第4.1.1.2 节“VRRP 实例”中所述
4.1.1.1。 全球定义
keepalived.conf 文件的“全局定义”部分允许管理员在负载平衡器发生更改时指定通知详细信息。请注意，全局定义是可选的，对于Keepalived 配置来说不是必需的。 keepalived.conf 文件的这部分在LB1 和LB2 上是相同的。
global_defs { notification_email { admin@example.com } notification_email_fromnoreply@example.com smtp_server 127.0.0.1 smtp_connect_timeout 60} notification_email 是负载均衡器的管理员， notification_email_from 是发送负载均衡器状态更改的地址。 SMTP 特定配置指定发送通知的邮件服务器。
4.1.1.2。 VRRP实例
以下示例显示主路由器和备用路由器中keeplalived.conf 文件的vrrp_sync_group 部分。请注意，两个系统之间的状态和优先级值有所不同。
以下示例显示LB1（主路由器）中keepalived.conf 文件的vrrp_sync_group 节。
vrrp_sync_group VG1 { 组{ RH_EXT RH_INT }}vrrp_instance RH_EXT { 状态MASTER 接口eth0 virtual_router_id 50 优先级100 advert_int 1 身份验证{ auth_type PASS auth_pass passw123 } virtual_ipaddress { 10.0.0.1 }}vrrp_instance RH_INT { 状态MASTER 接口eth1 virtual_router _id 2 优先级100 advert_int 1 authentication { auth_type PASS auth_pass passw123 } virtual_ipaddress { 192.168.1.1 }} 以下示例显示LB2（备份路由器）的keepalived.conf 文件的vrrp_sync_group 节。
vrrp_sync_group VG1 { 组{ RH_EXT RH_INT }}vrrp_instance RH_EXT { 状态BACKUP 接口eth0 virtual_router_id 50 优先级99 advert_int 1 身份验证{ auth_type PASS auth_pass passw123 } virtual_ipaddress { 10.0.0.1 }}vrrp_instance RH_INT { 状态BACKUP 接口eth1 virtual_rou ter_id 2 优先级99 advert_int 1 authentication { auth_type PASS auth_pass passw123 } virtual_ipaddress { 192.168.1.1 }} 在这些示例中， vrrp_sync_group 节定义在任何状态更改（例如故障转移）中仍保持在一起的VRRP 组。为与Internet 通信的外部接口(RH_EXT) 定义了一个实例，为内部接口(RH_INT) 定义了一个实例。
vrrp_instance 行详细说明了VRRP 服务守护程序的虚拟接口配置，该守护程序创建虚拟IP 实例。状态MASTER 指定活动服务器，状态BACKUP 指定备份服务器。
Interface 参数将物理接口名称分配给该特定虚拟IP 实例。
virtual_router_id 是虚拟路由器实例的数字标识符。在参与该虚拟路由器的所有LVS 路由器系统上必须相同。它用于区分同一网络接口上多个正在运行的keepalived 实例。
优先级指定分配的接口在故障转移中接管的顺序；数字越大，优先级越高。该优先级值必须在0到255范围内，并且状态为MASTER的负载均衡服务器的优先级值应设置为高于状态为BACKUP的服务器的优先级值。
身份验证块指定用于对服务器进行故障转移同步身份验证的身份验证类型(auth_type) 和密码(auth_pass)。 PASS指定密码认证； Keepalived 还支持AH 或身份验证标头以确保连接完整性。
最后，virtual_ipaddress 选项指定接口虚拟IP 地址。
4.1.1.3。虚拟服务器定义
keepalived.conf 文件的虚拟服务器定义部分在LB1 和LB2 上相同。
virtual_server 10.0.0.1 80 {delay_loop 6 lb_algo rr lb_kind NAT 协议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 168.1。 22 80 { TCP_CHECK { 连接超时10 } } real_server 192.168.1.23 80 { TCP_CHECK { connect_timeout 10 } }} 在此块中，首先使用IP 地址配置virtual_server。然后，delay_loop 配置运行状况检查之间的时间量（以秒为单位）。 lb_algo 选项指定用于可用性的算法类型（在本例中，rr 表示循环；有关可能的lb_algo 值的列表，请参阅表4.1，“虚拟服务器的LV_algo 值”）。 lb_kind 选项确定路由方法，在本例中使用网络地址转换（或NAT）。
配置虚拟服务器详细信息后，首先指定IP 地址，再次配置real_server 选项。 TCP_CHECK 部分使用TCP 检查真实服务器的可用性。 connect_timeout 配置发生超时之前的时间（以秒为单位）。
注意
不支持从负载均衡器或其中一台真实服务器访问虚拟IP。同样，不支持在与真实服务器相同的计算机上配置负载均衡器。
表4.1。 lv_algo 虚拟服务器值
4.2。 Keepalived直接路由配置
Keepalived的直接路由配置与NAT类似。在以下示例中，Keepalived 配置为在端口80 上为一组运行HTTP 的真实服务器提供负载平衡。要配置直接路由，请将lb_kind 参数更改为DR。其他配置选项将在第4.1 节“基本Keepalived 配置”中讨论。
以下示例显示使用直接路由的Keepalived 配置中活动服务器的keepalived.conf 文件。
global_defs { notification_email { admin@example.com } notification_email_fromnoreply_admin@example.com smtp_server 127.0.0.1 smtp_connect_timeout 60}vrrp_instance RH_1 { 状态MASTER 接口eth0 virtual_router_id 50 优先级100 advert_int 1 身份验证{ auth_type PASS auth_pass passw12 3 } { 172.31.0.1 } } virtual_server 172.31.0.1 80 delay_loop 10 lb_algo rr lb_kind DR persistence_timeout 9600 协议TCP real_server 192.168.0.1 80 { 权重1 TCP_CHECK { connect_timeout 10 connect_port 80 } } real_server 192.168.0.2 80 { 权重1 TCP_CHECK { connect_超时10 connect_port 80 } } real_server 192.168 。 0.3 80 { Weight 1 TCP_CHECK { connect_timeout 10 connect_port 80 } }}以下示例显示使用直接路由的Keepalived 配置中备份服务器的keepalived.conf 文件。请注意，状态和优先级值与活动服务器中的keepalived.conf文件不同。
global_defs { notification_email { admin@example.com } notification_email_fromnoreply_admin@example.com smtp_server 127.0.0.1 smtp_connect_timeout 60}vrrp_instance RH_1 { 状态BACKUP 接口eth0 virtual_router_id 50 优先级99 advert_int 1 身份验证{ auth_type PASS auth_pass passw12 3 } { 172.31.0.1 } } virtual_server 172.31.0.1 80 delay_loop 10 lb_algo rr lb_kind DR persistence_timeout 9600 协议TCP real_server 192.168.0.1 80 { 权重1 TCP_CHECK { connect_timeout 10 connect_port 80 } } real_server 192.168.0.2 80 { 权重1 TCP_CHECK { connect_超时10 connect_port 80 } } real_server 192.168 。 0.3 80 { Weight 1 TCP_CHECK { connect_timeout 10 connect_port 80 } }}
4.3。 启动服务
通过在负载均衡器配置中的服务器上输入以下命令来启动服务：
# systemctl start keepalived.service 要在重新启动后保持Keepalived 服务不变，请在负载均衡器配置中的服务器上输入以下命令：
第5章HAProxy配置
本章介绍基本设置的配置，重点介绍管理员在为高可用性环境部署HAProxy 服务时可能遇到的常见配置选项。
HAProxy 有自己的一套负载均衡调度算法。这些算法在第5.1 节“HAProxy 调度算法”中描述。
通过编辑/etc/haproxy/haproxy.cfg 文件来配置HAProxy。
使用HAProxy 的负载均衡器配置由五个配置部分组成：
第5.2 节“全局设置”
代理部分由4个小部分组成：
第5.3 节“默认设置”设置
5.4节“前端设置”设置
5.5节“后端设置”设置
5.1。 HAProxy调度算法
用于负载平衡的HAProxy 调度算法可以在/etc/haproxy/haproxy.cfg 配置文件后端部分的Balance 参数中进行编辑。需要注意的是，HAProxy支持多个后端的配置，每个后端都可以配置调度算法。
循环赛（roundrobin）
将每个请求按顺序分布在真实服务器池中。使用此算法，所有真实服务器都被认为是平等的，无论容量或负载如何。这种调度模型类似于循环DNS，但由于它基于网络连接而不是主机，因此更加细粒度。负载均衡器循环调度也不受缓存DNS 查询引起的不平衡的影响。然而，在HAProxy 中，由于服务器权重的配置可以使用此调度程序动态完成，因此每个后端的活动服务器数量限制为4095 个。
静态循环（static-rr）
与循环法一样，每个请求都按顺序分布在真实服务器池周围，但不允许动态配置服务器权重。然而，由于服务器权重的静态特性，后端的活动服务器数量没有限制。
最小连接（最小连接）
将更多请求分发到活动连接较少的真实服务器。具有不同会话或连接长度的动态环境的管理员可能会发现此调度程序更适合他们的环境。它也非常适合一组服务器具有不同容量的环境，因为管理员可以使用此调度程序动态调整权重。
对服务器的请求通过对请求源IP 地址进行哈希处理并除以所有正在运行的服务器的权重来分发，以确定哪台服务器将收到该请求。当所有服务器都运行时，源IP 请求将始终由同一台真实服务器提供服务。如果正在运行的服务器的数量或权重发生变化，则会话可能会移动到另一台服务器，因为散列/权重结果已发生变化。
URI（URI）
通过散列整个URI（或URI 的可配置部分）并除以所有正在运行的服务器的权重来确定请求的服务器，从而将请求分发到服务器。当所有活动服务器都运行时，目标IP 请求将始终由同一台真实服务器提供服务。该调度器还可以通过配置URI 的目录部分开头的字符长度来计算哈希结果以及URI 中的目录深度（由URI 中的正斜杠指定）来计算哈希结果。
URL 参数(url_param)
通过在源URL 请求中查找特定参数字符串并执行除以所有正在运行的服务器的权重的哈希计算，将请求分发到服务器。如果URL 中缺少此参数，则调度程序默认为循环调度。可以根据POST 参数以及管理员在计算哈希结果之前分配给特定参数权重的最大八位字节数来使用修饰符。
标题名称(hdr)
通过检查每个源HTTP 请求的特定标头名称并执行除以所有正在运行的服务器的权重的哈希计算，将请求分发到服务器。如果标头不存在，则调度程序默认为循环调度。
RDP Cookie（rdp-cookie）
通过查找每个TCP 请求的RDP cookie 并执行除以所有正在运行的服务器的权重的哈希计算，将请求分发到服务器。如果标头不存在，则调度程序默认为循环调度。此方法非常适合持久性，因为它可以保持会话完整性。
5.2。 全局设置
全局设置配置适用于所有运行HAProxy 的服务器的参数。典型的全局部分可能如下所示：
global log 127.0.0.1 local2 maxconn 4000 user haproxy group haproxy daemon 在上述配置中，管理员已将服务配置为将所有条目记录到本地syslog 服务器。默认情况下，这可能是/var/log/syslog 或某个用户指定的位置。
maxconn 参数指定服务的最大并发连接数。默认情况下，最大值为2000。
user和group参数指定haproxy进程所属的用户名和组名。
最后，daemon 参数指定haproxy 作为后台进程运行。
5.3。 默认设置
适用于配置中所有代理子部分（前端、后端和侦听）的参数的默认设置配置。典型的默认部分可能如下所示：
注意
代理子部分（前端、后端或侦听器）中配置的任何参数都优先于默认参数值。
defaults mode http log 全局选项httplog 选项dontlognull retries 3 timeout http-request 10s 超时队列1m timeout connect 10s 超时client 1m timeout server 1mmode 指定HAProxy 实例的协议。使用http 模式将源请求连接到真正的基于HTTP 的服务器，非常适合负载平衡Web 服务器。对于其他应用程序，请使用tcp 模式。
log 指定写入日志条目的日志地址和syslog 工具。全局值将HAProxy 实例引用到全局部分的日志参数中指定的任何内容。
选项httplog 允许记录HTTP 会话的各种值，包括HTTP 请求、会话状态、连接数、源地址和连接计时器等值。
选项dontlognull 禁用空连接的日志记录，这意味着HAProxy 不会记录未传输数据的连接。不建议在Internet 上的Web 应用程序中使用此类环境，因为空连接可能表示恶意活动，例如开放端口扫描漏洞。
retries 指定真实服务器在第一次连接尝试失败后重试连接请求的次数。
各种超时值指定给定请求、连接或响应的不活动长度。这些值通常以毫秒表示（除非另有明确说明），但也可以通过在单位后加上数值来以任何其他单位表示。支持的单位包括us（微秒）、ms（毫秒）、s（秒）、m（分钟）、h（小时）和d（天）。 http-request 10s 等待来自客户端的完整HTTP 请求10 秒。 Queue 1m 设置为一分钟，作为连接断开且客户端收到503 或“服务不可用”错误之前等待的时间。 connect 10s 指定等待成功连接到服务器的秒数。 client 1m 指定客户端可以保持不活动状态（既不接受也不发送数据）的时间（以分钟为单位）。 server 1m 指定服务器在发生超时之前接受或发送数据的时间（以分钟为单位）。
5.4。 前端设置
前端设置为客户端连接请求配置服务器的侦听套接字。前端的典型HAProxy 配置可能如下所示：
frontend main bind 192.168.0.10:80 default_backend app 名为main 的前端配置有192.168.0.10 IP 地址，并使用bind 参数侦听端口80。连接后，指定所有会话以使用后端连接到应用程序后端。
5.5。 后端设置
后端设置指定实际服务器IP 地址和负载均衡器调度算法。以下示例显示了典型的后端部分：
后端应用余额roundrobin 服务器app1 192.168.1.1:80 检查服务器app2 192.168.1.2:80 检查服务器app3 192.168.1.3:80 检查inter 2s 上升4 下降3 服务器app4 192.168.1.4:80 备份后端服务器名为app。 Balance 指定要使用的负载均衡器调度算法，在本例中为循环算法，但可以是HAProxy 支持的任何调度器。有关在HAProxy 中配置调度程序的更多信息，请参阅第5.1 节“HAProxy 调度算法”。
服务器行指定后端可用的服务器。 app1 到app4 是内部分配给每个真实服务器的名称。日志文件将按名称指定服务器消息。地址是分配的IP地址。 IP 地址中冒号后面的值是发生连接的特定服务器上的端口号。检查选项标记服务器进行定期运行状况检查，以确保其可用并能够接收和发送数据以及获取会话请求。服务器app3还将健康检查间隔配置为两秒（间隔2），检查app3必须通过才能确定服务器是否正常运行（最多4次），以及服务器连续检查失败的次数才被视为失败（秋天4) 3)。
5.6。 开始haproxy
要启动HAProxy 服务，请输入以下命令：
# systemctl start haproxy.service 要在重新启动后保持HAProxy 服务不变，请输入以下命令：
# systemctl enable haproxy.service 附录A. 示例配置：使用HAProxy 和Keepalived 对Ceph 对象网关服务器进行负载平衡
本附录提供了一个示例，显示使用Ceph 集群配置HAProxy 和Keepalived。 Ceph 对象网关允许您将对象网关的多个实例分配到单个区域，以便您可以随着负载的增加进行扩展。由于每个对象网关实例都有自己的IP 地址，因此您可以使用HAProxy 和keepalived 来平衡Ceph 对象网关服务器之间的负载。
在此配置中，HAproxy 在Ceph 对象网关服务器上执行负载均衡，Keepalived 用于管理Ceph 对象网关服务器的虚拟IP 地址并监控HAProxy。
HAProxy 和keepalived 的另一个用例是终止HAProxy 服务器上的HTTPS。 Red Hat Ceph Storage (RHCS) 1.3.x 使用Civetweb，RHCS 1.3.x 中的实现不支持HTTPS。您可以使用HAProxy 服务器终止HAProxy 服务器上的HTTPS，并在HAProxy 服务器和Civetweb 网关实例之间使用HTTP。此示例包含此配置作为过程的一部分。
A.1。先决条件
要使用Ceph 对象网关设置HAProxy，您必须具有：
正在运行的Ceph 集群；
同一区域中至少两台Ceph 对象网关服务器配置为在端口80 上运行；
至少有两台用于HAProxy 和keepalived 的服务器。
注意
此过程假设您至少有两个正在运行的Ceph 对象网关服务器，并且在通过端口80 运行测试脚本时获得有效响应。
A2。准备HAProxy节点
以下设置假设有两个名为haproxy 和haproxy2 的HAProxy 节点，以及两个名为rgw1 和rgw2 的Ceph 对象网关服务器。您可以使用任何您喜欢的命名约定。在两个HAProxy 节点上执行以下过程：
1. 安装红帽企业Linux 7。
2. 注册节点。
# 订阅管理器注册3。启用Red Hat Enterprise Linux 7 服务器存储库。
# 订阅管理器存储库--enable=rhel-7-server-rpms4.更新服务器
# 百胜更新-y5.安装管理软件，wget vim等
6.
开启80端口 # firewall-cmd --zone=public --add-port 80/tcp --permanent# firewall-cmd --reload7.如果是https，开启443端口 # firewall-cmd --zone=public --add-port 443/tcp --permanent# firewall-cmd --reloadA.3。 安装和配置keepalived
在两个HAProxy节点上执行以下过程： 1. 安装keepalived
A.4。 安装和配置HAProxy
在两个HAProxy节点上执行以下过程： 1.安装haproxy # yum install haproxy2.为SELinux和HTTP配置haproxy # vim /etc/firewalld/services/haproxy-http.xml添加如下行： <?xml version="1.0" encoding="utf-8"?><service><short>HAProxy-HTTP</short><description>HAProxy load-balancer</description><port protocol="tcp" port="80"/></service>以root用户身份，将正确的SELinux上下文和文件权限分配给haproxy-http.xml文件。 # cd /etc/firewalld/services# restorecon haproxy-http.xml# chmod 640 haproxy-http.xml3.如果您打算使用HTTPS，请为SELinux和HTTPS配置haproxy。 # vim /etc/firewalld/services/haproxy-https.xml添加如下行： <?xml version="1.0" encoding="utf-8"?><service><short>HAProxy-HTTPS</short><description>HAProxy load-balancer</description><port protocol="tcp" port="443"/></service>以root用户身份，将正确的SELinux上下文和文件权限分配给haproxy-https.xml文件。 # cd /etc/firewalld/services# restorecon haproxy-https.xml# chmod 640 haproxy-https.xml4.如果您打算使用HTTPS，请为SSL生成密钥。 如果您没有证书，则可以使用自签名证书。 有关生成密钥和自签名证书的信息，请参阅“Red Hat Enterprise Linux系统管理员指南”。 最后，将证书和密钥放入PEM文件中。 # cat example.com.crt example.com.key > example.com.pem# cp example.com.pem /etc/ssl/private/5.配置haproxy # vim /etc/haproxy/haproxy.cfghaproxy.cfg的全局和默认部分可能保持不变。 在默认部分之后，您将需要配置前端和后端部分，如以下示例所示： frontend http_web *:80 mode http default_backend rgwfrontend rgw-https bind <insert vip ipv4>:443 ssl crt /etc/ssl/private/example.com.pem default_backend rgwbackend rgw balance roundrobin mode http server rgw1 10.0.0.71:80 check server rgw2 10.0.0.80:80 check6.使能 开启haproxy # systemctl enable haproxy# systemctl start haproxyA.5。 测试您的HAProxy配置
在HAProxy节点上，检查以确保显示来自keepalived配置的虚拟IP地址。 $ ip addr show在您的calamari节点上，查看是否可以通过负载平衡器配置访问网关节点。 例如： $ wget haproxy这应该返回相同的结果： $ wget rgw1 如果它返回带有以下内容的index.html文件，那么您的配置工作正常。 <?xml version="1.0" encoding="UTF-8"?><ListAllMyBucketsResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/"><Owner><ID>anonymous</ID><DisplayName></DisplayName></Owner><Buckets></Buckets></ListAllMyBucketsResult>附录B.修订历史
修订记录 修订版3.1-2 2018年10月4日星期四史蒂芬莱文 准备7.6 GA出版物的文件。 修订版2.1-1 2014年3月15日星期四史蒂芬莱文 准备7.5 GA出版物的文件。 修订版2.1-0 2017年12月14日星期四史蒂芬莱文
用户评论
负载均衡简直太重要了，不然服务器压力大的时候网站就崩啊。
有5位网友表示赞同！
这篇文章讲的挺明白了，让我终于把那些负载均衡术语搞懂了
有8位网友表示赞同！
在云计算时代，负载均衡是必不可少的配置，要懂得怎么用才能优化好系统性能。
有11位网友表示赞同！
哈哈，原来负载均衡还有这么多种策略！之前只知道简单的那种。
有7位网友表示赞同！
看了这篇文章感觉自己对负载均衡管理又更了解了
有16位网友表示赞同！
实践中常用的负载均衡类型有很多种?
有19位网友表示赞同！
转发到公司群里让同事学习下，这些知识真的太实用了!
有6位网友表示赞同！
希望可以再详细介绍一下常见的负载均衡方案吧
有16位网友表示赞同！
服务器性能优化真的很重要，负载均衡是我最近在学习的目标。
有20位网友表示赞同！
理解了！
有8位网友表示赞同！
这篇文章的内容太棒了，简直是干货满满!
有9位网友表示赞同！
负载均衡策略的选择真的很关键，要根据实际情况去综合判断
有12位网友表示赞同！
负载均衡管理是一个比较复杂的系统，需要认真学习和理解才行。
有19位网友表示赞同！
想要了解更多关于不同类型负载均衡的特点吗？
有10位网友表示赞同！
文中提到几种常见的方法，不过我觉得还可以再多介绍一些其他方案！
有5位网友表示赞同！
负载均衡真的很重要，可以提高系统稳定性和性能
有19位网友表示赞同！
这篇文章让我对负载均衡管理有了更深刻的认识。
有9位网友表示赞同！
做开发的小伙伴们必须掌握这方面的知识！
有12位网友表示赞同！