高负载web框架（五）

h.部署前端haproxy并且用keepalived高可用
先在node1上部署好haproxy，而后在安装好keepalived，把node1上的配置复制到node11上。
安装haproxy，在base源下有
# yum install -yhaproxy
haproxy的配置：
global settings: 全局配置段
主要用于定义haproxy进程自身的工作特性；
proxies: 代理配置段
事先定义好一组后端服务器，事先定义好一组前端监听的地址，而后将他们关联起来
backend: 后端服务器组
frontend: 定义面向客户的监听的地址和端口，以及关联到的后端服务器组；
listen: 组合方式直接定义frontend及相关的backend的一种机制；
defaults: 定义默认配置；
haproxy的部分配置说明 /etc/haproxy/haproxy.cnf
使用本机的facility来记录日志，就不用发往服务器了，
# local2.* /var/log/haproxy.log 把这项写到/etc/rsyslog.conf中

log 127.0.0.1 local2 日志发往服务器的哪里？使用facility的local2来记录日志，也需要在/etc/rsyslog.conf中指明记录到那个位置，没有写的话则记录到/var/log/messages文件中，在rsyslog启动时，需要监听在udp或者tcp的端口上
# Provides UDPsyslog reception
#$ModLoad imudp
#$UDPServerRun 514

# Provides TCPsyslog reception
#$ModLoad imtcp
#$InputTCPServerRun514 /etc/rsyslog.conf中都注释了，所以记录不了日志，要启用记录日志，这里要取消对tcp和udp的注释
+++++++++
具体实现
启用/etc/haproxy/haproxy.cnf中
log 127.0.0.1 local2
在/etc/rsyslog.conf中启用
# Provides UDPsyslog reception
$ModLoad imudp
$UDPServerRun 514
# Include allconfig files in /etc/rsyslog.d/
$ModLoad imtcp
$InputTCPServerRun514
再添加
local2.* /var/log/haproxy.log

性能调整相关的参数
-maxconn <number>：设定每个haproxy进程所接受的最大并发连接数，其等同于命令行选项“-n”；“ulimit -n”自动计算的结果正是参照此参数设定的；
- spread-checks<0..50, in percent>：在haproxy后端有着众多服务器的场景中，在精确的时间间隔后统一对众服务器进行健康状况检查可能会带来意外问题；此选项用于将其检查的时间间隔长度上增加或减小一定的随机时长；
- tune.maxaccept<number>：设定haproxy进程内核调度运行时一次性可以接受的连接的个数，较大的值可以带来较大的吞吐率，默认在单进程模式下为100，多进程模式下为8，设定为-1可以禁止此限制；一般不建议修改；

代理相关的配置可以如下配置段中。
name是必须指定的
- defaults <name>
- frontend <name>
- backend <name>
- listen <name>
所有代理的名称只能使用大写字母、小写字母、数字、-(中线)、_(下划线)、.(点号)和:(冒号)。此外，ACL名称会区分字母大小写。
frontend <name>IP:PORT
use_backend
default_backend

backend <name>
balance<scheduler> 指明调度方法
server <name>IP:PORT [check] check对后端服务器做健康检测
...

listen <name> IP:PORT
balance 指明调度方法
server
server

defaults 定义默认配置

balance
balance<algorithm> [ <arguments> ]
balance url_param<param> [check_post [<max_wait>]]

定义负载均衡算法，可用于“defaults”、“listen”和“backend”。<algorithm>用于在负载均衡场景中挑选一个server，其仅应用于持久信息不可用的条件下或需要将一个连接重新派发至另一个服务器时。支持的算法有：
roundrobin：基于权重进行轮叫，在服务器的处理时间保持均匀分布时，这是最平衡、最公平的算法。此算法是动态的，这表示其权重可以在运行时进行调整，不过，在设计上，每个后端服务器仅能最多接受4128个连接；
static-rr：基于权重进行轮叫，与roundrobin类似，但是为静态方法，在运行时调整其服务器权重不会生效；不过，其在后端服务器连接数上没有限制；
leastconn：新的连接请求被派发至具有最少连接数目的后端服务器；在有着较长时间会话的场景中推荐使用此算法，如LDAP、SQL等，其并不太适用于较短会话的应用层协议，如HTTP；此算法是动态的，可以在运行时调整其权重；
source：将请求的源地址进行hash运算，并由后端服务器的权重总数相除后派发至某匹配的服务器；这可以使得同一个客户端IP的请求始终被派发至某特定的服务器；不过，当服务器权重总数发生变化时，如某服务器宕机或添加了新的服务器，许多客户端的请求可能会被派发至与此前请求不同的服务器；常用于负载均衡无cookie功能的基于TCP的协议；其默认为静态，不过也可以使用hash-type修改此特性；
uri：对URI的左半部分(“问题”标记之前的部分)或整个URI进行hash运算，并由服务器的总权重相除后派发至某匹配的服务器；这可以使得对同一个URI的请求总是被派发至某特定的服务器，除非服务器的权重总数发生了变化；此算法常用于代理缓存或反病毒代理以提高缓存的命中率；需要注意的是，此算法仅应用于HTTP后端服务器场景；其默认为静态算法，不过也可以使用hash-type修改此特性；
url_param：通过<argument>为URL指定的参数在每个HTTP GET请求中将会被检索；如果找到了指定的参数且其通过等于号“=”被赋予了一个值，那么此值将被执行hash运算并被服务器的总权重相除后派发至某匹配的服务器；此算法可以通过追踪请求中的用户标识进而确保同一个用户ID的请求将被送往同一个特定的服务器，除非服务器的总权重发生了变化；如果某请求中没有出现指定的参数或其没有有效值，则使用轮叫算法对相应请求进行调度；此算法默认为静态的，不过其也可以使用hash-type修改此特性；
hdr(<name>)：对于每个HTTP请求，通过<name>指定的HTTP首部将会被检索；如果相应的首部没有出现或其没有有效值，则使用轮叫算法对相应请求进行调度；其有一个可选选项“use_domain_only”，可在指定检索类似Host类的首部时仅计算域名部分(比如通过www.magedu.com来说，仅计算magedu字符串的hash值)以降低hash算法的运算量；此算法默认为静态的，不过其也可以使用hash-type修改此特性；

ACL
haproxy的ACL用于实现基于请求报文的首部、响应报文的内容或其它的环境状态信息来做出转发决策，这大大增强了其配置弹性。其配置法则通常分为两步，首先去定义ACL，即定义一个测试条件，而后在条件得到满足时执行某特定的动作，如阻止请求或转发至某特定的后端。定义ACL的语法格式如下。

acl<aclname> <criterion> [flags] [operator] <value> ...

<aclname>：ACL名称，区分字符大小写，且其只能包含大小写字母、数字、-(连接线)、_(下划线)、.(点号)和:(冒号)；haproxy中，acl可以重名，这可以把多个测试条件定义为一个共同的acl；
<criterion>：测试标准，即对什么信息发起测试；测试方式可以由[flags]指定的标志进行调整；而有些测试标准也可以需要为其在<value>之前指定一个操作符[operator]；
[flags]：目前haproxy的acl支持的标志位有3个：
-i：不区分<value>中模式字符的大小写；
-f：从指定的文件中加载模式；
--：标志符的强制结束标记，在模式中的字符串像标记符时使用；
<value>：acl测试条件支持的值有以下四类：
整数或整数范围：如1024:65535表示从1024至65535；仅支持使用正整数(如果出现类似小数的标识，其为通常为版本测试)，且支持使用的操作符有5个，分别为eq、ge、gt、le和lt；
字符串：支持使用“-i”以忽略字符大小写，支持使用“\”进行转义；如果在模式首部出现了-i，可以在其之前使用“--”【是两个-】标志位；
正则表达式：其机制类同字符串匹配；
IP地址及网络地址

同一个acl中可以指定多个测试条件，这些测试条件需要由逻辑操作符指定其关系。条件间的组合测试关系有三种：“与”(默认即为与操作)、“或”(使用“||”操作符)以及“非”(使用“!”操作符)。

常用的测试标准(criteria)
be_sess_rate(backend) <integer>

用于测试指定的backend上会话创建的速率(即每秒创建的会话数)是否满足指定的条件；常用于在指定backend上的会话速率过高时将用户请求转发至另外的backend，或用于阻止攻击行为。例如：
backend dynamic
mode http
acl being_scanned be_sess_rate gt 50 如果每秒钟会话创建数大于50个，则认为是遭到攻击了
redirect location /error_pages/denied.html if being_scanned 如果说遭到攻击，则将请求内容重定向到/error_pages/denied.html上

fe_sess_rate(frontend) <integer>

用于测试指定的frontend(或当前frontend)上的会话创建速率是否满足指定的条件；常用于为frontend指定一个合理的会话创建速率的上限以防止服务被滥用。例如下面的例子限定入站邮件速率不能大于50封/秒，所有在此指定范围之外的请求都将被延时50毫秒。
frontend mail
bind :25
mode tcp
maxconn 500
acl too_fast fe_sess_rate ge 50
tcp-request inspect-delay 50ms 将速率大于50的都延迟50ms
tcp-request content accept if ! too_fast 如果请求速率没有超过50，则accept
tcp-request content accept if WAIT_END 等待结束了，也可以接收进来
访问速率值设置需要注意，不要把正常的都阻止了

hdr(header) <string>

用于测试请求报文中的所有首部或指定首部是否满足指定的条件；指定首部时，其名称不区分大小写，且在括号“()”中不能有任何多余的空白字符。测试服务器端的响应报文时可以使用shdr()。例如下面的例子用于测试首部Connection的值是否为close。
hdr(Connection) -i close

method <string>

测试HTTP请求报文中使用的方法。

path_beg <string>

用于测试请求的URL是否以<string>指定的模式开头。下面的例子用于测试URL是否以/static、/images、/javascript或/stylesheets头。
acl url_static path_beg -i /static /images /javascript/stylesheets

path_end <string>

用于测试请求的URL是否以<string>指定的模式结尾。例如，下面的例子用户测试URL是否以jpg、gif、png、css或js结尾。
aclurl_static path_end -i .jpg .gif .png .css .js
在acl中使用同一个名字是可以的

hdr_beg <string>

用于测试请求报文的指定首部的开头部分是否符合<string>指定的模式。例如，下面的例子用记测试请求是否为提供静态内容的主机img、video、download或ftp。
acl host_static hdr_beg(host) -i img. video. download. ftp.

hdr_end <string>

用于测试请求报文的指定首部的结尾部分是否符合<string>指定的模式。例如，下面的例子用记测试请求是否为

hdr_reg (header) <regex> 对指定请求的值做正则表达式匹配
path_reg <regex> 对请求路径做作则表达式匹配的

这里要实现动静分离，通过haproxy的ACL功能来实现，动态内容分发到node4和node5，静态内容分发到varnish上。
配置内容：
frontend main
maxconn 6000
bind :80
acl url_static path_beg -i /images /video /music 如果这里加了/，则所有请求都被定位到此处
acl url_static path_end -i .jpg .html .css .png .gif .txt
use_backend static if url_static
default_backend webapp

backend static
balance uri
server static1 192.168.21.178check port 80server static2 192.168.21.167check port 80 server h1 127.0.0.1 backup port 8080

backend webapp
balance source
server s1 192.168.21.166check port 80 maxconn 4000 weight 2 server s2 192.168.21.150 check port 80 maxconn 4000 weight 2
server h1 127.0.0.1:8080 backup
stats enable 显示状态页的
stats hide-version
stats uri /hap?stats
stats scope .
stats realm HAproxy\ Statistic
stats auth look:look
stats admin ifTRUE keepalived的实现
keepalived：主要实现在两个或多个节点之间实现VRRP协议的，也即运行keepalived，keepalived可以实现VRRP功能
vrrp就是将两个或两个以上的物理路由设备定义成一个虚拟的路由器，此时称为路由组，这一组路由设备共同联合起来构建成虚拟路由，在虚拟路由上配置一个vip和与vip共同对应vmac，这一组的路由器上，每一个路由器都有对应的优先级，每一节点刚开始都是初始化的，而后通告自己的优先级，最后通过优先级来确定优先级最高的作为主节点，其他的节点都为备节点，只有当主节点宕机时，其他节点就会把主节点上vip等资源抢到自身主机，由此在末端主机上只需配置一个网关，指向虚拟ip，这时就实现了路由协议的高可用效果，vrrp 虚拟冗余路由协议

两个虚拟主机各自都安装keepalived服务进程，keepalived进程能够通过互相通信，通过vrrp协议的工作机制，通告优先级、选举主节点配置ip地址

keepalived在centos 6.4之后收录REHL系了
#yum install –y keepalived
# rpm -qlkeepalived | less
/etc/keepalived
/etc/keepalived/keepalived.conf 配置文件
/etc/rc.d/init.d/keepalived 服务脚本，keepalived在通信时，需要进行认证的，最好换一个多播地址，默认vrid为51，如果不换多播地址，则一般是vrid都是唯一的
/etc/sysconfig/keepalived
/usr/bin/genhash
/usr/libexec/keepalived
/usr/sbin/keepalived
keepalived.conf配置文件中 !是注释
# vim/etc/keepalived/keepalived.conf
! ConfigurationFile for keepalived

global_defs {
notification_email {万一服务器挂了时，用邮件通知给谁
acassen@firewall.loc
failover@firewall.loc
sysadmin@firewall.loc
}
notification_email_fromAlexandre.Cassen@firewall.loc
smtp_server 192.168.200.1邮件服务器，如果有邮件服务器则使用邮件服务器的地址
smtp_connect_timeout 30
router_id LVS_DEVEL
}

vrrp_instance VI_1{
state MASTER
interface eth0
virtual_router_id 21
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass keepalived
}
virtual_ipaddress {
192.168.21.152
} notify_master "/etc/rc.d/init.d/haproxystart"
notify_backup "/etc/rc.d/init.d/haproxystop"
notify_fault "/etc/rc.d/init.d/haproxystop"
}
备节点需要修改的地方
state BACKUP 修改
priority 98 修改

本文出自 “快乐就好” 博客，请务必保留此出处http://wdllife.blog.51cto.com/6615958/1684322