一、简述HA cluster原理
HA cluster高可用集群:高可用集群就是当某一个节点或服务器发生故障时,另一个节点能够自动且立即向外提供服务,即将有故障节点上的资源转移到另一个节点上去,这样另一个节点有了资源既可以向外提供服务。高可用集群是用于单个节点发生故障时,能够自动将资源、服务进行切换,这样可以保证服务一直在线。在这个过程中,对于客户端来说是透明的。
1.高可用集群的衡量标准:高可用集群一般是通过系统的可靠性(reliability)和系统的可维护性(maintainability)来衡量的。通常用平均无故障时间(MTTF)来衡量系统的可靠性,用平均维护 时间(MTTR)来衡量系统的可维护性。因此,一个高可用集群服务可以这样来定义:HA=MTTF/(MTTF+MTTR)*100%
2.高可用集群的相关特性:
1.提供冗余系统:HA Cluster:为提升系统调用性,组合多台主机构建成为的集群
2.vote system投票系统:HA中的各节点无法探测彼此的心跳信息时,必须无法协调工作;此种状态即为partitioned cluster
3.failover: 失效转移,故障转移,failback:失效转回,故障转回,通过配置ha.cf文件中的 auto_failback on启用
4.心跳信息传递机制。
二、keepalived实现主从、主主架构
keepalived:vrrp(virtual redundant routing protocol)协议的软件实现,原生设计的目的是为了高可用ipvs服务。
1.基于vrrp协议完成地址流动;
2.为vip地址所在的节点生成ipvs规则(在配置文件中预先定义);
3.为ipvs集群的各RS做健康状态监测;
4.基于脚本调用接口通过执行脚本完成脚本中定义的功能,进而影响集群事务;
Keepalived的配置前提:
1.各节点时间必须同步;
2.确保iptables及selinux不会成为阻碍;
3.各节点之间可通过主机名互相通信;
4.确保各节点的用于集群服务的接口支持MULTICAST通信;
keepalived的主从架构:使用node1,node2中部署keepalived做主从和主主的架构,在后端服务器node3,node4部署nginx搭建web站点。
1.搭建后端nginx服务:
[root@node1 ~]# yum install -y nginx #安装nginx服务
2.配置nginx显示页面配置:
[root@node1 ~]# vim /usr/share/nginx/html/index.html
<h1>Server 1 10.3.223.11</h1> #修改配置
[root@node2 ~]# systemctl start nginx #启动nginx服务
3.在node1上配置lvs-dr的配置,创建lvsdr脚本:
[root@node1 ~]# vim lvsdr.sh
#!bin/bash
#
vip=10.3.88.188
mask='255.255.255.255'
case $1 in
start)
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
ifconfig lo:0 $vip netmask $mask broadcast $vip up
route add -host $vip dev lo:0
;;
stop)
ifconfig lo:0 down
echo 0 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 0 > /proc/sys/net/ipv4/conf/lo/arp_announce
;;
*)
echo "Usage $(basename $0) start|stop"
exit 1
;;
esac
执行RS脚本:
[root@node1 ~]# bash lvsdr.sh start #启动脚本
[root@node1 ~]# ifconfig lo:0
lo:0: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 10.3.88.188 netmask 255.255.255.255
loop txqueuelen 0 (Local Loopback)
4.node2采取同样的配置。
搭建node3服务:安装keepalived和ipvsadm程序包:
[root@node3 ~]# yum install -y keepalived ipvsadm #安装ipvsadm和keepalived服务
编辑keepalived配置文件:
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 30
route_id node3
vrrp_mcast_group4 224.0.88.188
vrrp_garp_interval 0
vrrp_gna_interval 0
}
vrrp_instance VI_1 {
state MASTER
interface eno16777736
virtual_router_id 1
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
10.3.88.188/16 dev eno16777736 label eno16777736:0
}
}
virtual_server 10.3.88.188 80 {
delay_loop 6
lb_algo rr
lb_kind DR
protocol TCP
real_server 10.3.223.11 80 {
weight 1
HTTP_GET {
url {
path /index.html
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
real_server 10.3.223.12 80 {
weight 1
HTTP_GET {
url {
path /index.html
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}
查看ipvsadm的端口状态:
[root@node3 keepalived]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.3.88.188:80 rr
-> 10.3.223.11:80 Route 1 0 0
-> 10.3.223.12:80 Route 1 0 0
配置node4服务器的keepalived,配置node3,修改相对应的参数即可,使用ipvsadm查看状态:
[root@node4 keepalived]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.3.88.188:80 rr
-> 10.3.223.11:80 Route 1 0 0
-> 10.3.223.12:80 Route 1 0 0
测试,访问vip地址,获得的服务如下:
[root@node1 ~]# for i in {1..10};do curl http://10.3.88.188;done
<h1>Server 1 10.3.223.11</h1>
<h1>Server 2 10.3.223.12</h1>
<h1>Server 1 10.3.223.11</h1>
<h1>Server 2 10.3.223.12</h1>
<h1>Server 1 10.3.223.11</h1>
<h1>Server 2 10.3.223.12</h1>
<h1>Server 1 10.3.223.11</h1>
<h1>Server 2 10.3.223.12</h1>
<h1>Server 1 10.3.223.11</h1>
h1>Server 2 10.3.223.12</h1>
此时node3为master,node4为backup,将node3服务关闭,此时node4将成为master,同样测试vip的服务:
[root@node1 ~]# for i in {1..10};do curl http://10.3.88.188;done
<h1>Server 2 10.3.223.12</h1>
<h1>Server 1 10.3.223.11</h1>
<h1>Server 2 10.3.223.12</h1>
<h1>Server 1 10.3.223.11</h1>
<h1>Server 2 10.3.223.12</h1>
<h1>Server 1 10.3.223.11</h1>
<h1>Server 2 10.3.223.12</h1>
<h1>Server 1 10.3.223.11</h1>
<h1>Server 2 10.3.223.12</h1>
<h1>Server 1 10.3.223.11</h1>
此时服务仍正常,说明keepalived的主从配置正确。
keepalived主主配置:
修改node3的keepalived配置文件:
[root@node3 keepalived]# cat keepalived.conf
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 30
route_id node3
vrrp_mcast_group4 224.0.88.188
vrrp_garp_interval 0
vrrp_gna_interval 0
}
vrrp_instance VI_1 {
state MASTER
interface eno16777736
virtual_router_id 1
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
10.3.88.188/16 dev eno16777736 label eno16777736:0
}
}
vrrp_instance VI_2 {
state BACKUP
interface eno16777736
virtual_router_id 2
priority 96
advert_int 1
authentication {
auth_type PASS
auth_pass 2222
}
virtual_ipaddress {
10.3.88.187/16 dev eno16777736 label eno16777736:1
}
}
virtual_server_group backend {
10.3.88.188 80
10.3.88.187 80
}
virtual_server group backend 80 {
delay_loop 6
lb_algo rr
lb_kind DR
protocol TCP
real_server 10.3.223.11 80 {
weight 1
HTTP_GET {
url {
path /index.html
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
real_server 10.3.223.12 80 {
weight 1
HTTP_GET {
url {
path /index.html
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}
查看ipvsadm的状态为:
[root@node3 keepalived]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.3.88.187:80 rr
-> 10.3.223.11:80 Route 1 0 0
-> 10.3.223.12:80 Route 1 0 0
TCP 10.3.88.188:80 rr
-> 10.3.223.11:80 Route 1 0 0
-> 10.3.223.12:80 Route 1 0 0
node4如node3一样配置,修改相应的参数即可。
在node1和node2上添加lo:1的地址,如下:
lo:0: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 10.3.88.188 netmask 255.255.255.255
loop txqueuelen 0 (Local Loopback)
lo:1: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 10.3.88.187 netmask 255.255.255.255
loop txqueuelen 0 (Local Loopback)
在客户端上访问10.3.88.188,及10.3.88.187均能访问到服务:
[root@node1 keepalived]# for i in {1..10};do curl http://10.3.88.188;done
<h1>Server 2 10.3.223.12</h1>
<h1>Server 1 10.3.223.11</h1>
<h1>Server 2 10.3.223.12</h1>
<h1>Server 1 10.3.223.11</h1>
<h1>Server 2 10.3.223.12</h1>
<h1>Server 1 10.3.223.11</h1>
h1>Server 2 10.3.223.12</h1>
<h1>Server 1 10.3.223.11</h1>
<h1>Server 2 10.3.223.12</h1>
<h1>Server 1 10.3.223.11</h1>
[root@node1 keepalived]# for i in {1..10};do curl http://10.3.88.187;done
<h1>Server 2 10.3.223.12</h1>
<h1>Server 1 10.3.223.11</h1>
<h1>Server 2 10.3.223.12</h1>
<h1>Server 1 10.3.223.11</h1>
<h1>Server 2 10.3.223.12</h1>
<h1>Server 1 10.3.223.11</h1>
<h1>Server 2 10.3.223.12</h1>
<h1>Server 1 10.3.223.11</h1>
<h1>Server 2 10.3.223.12</h1>
<h1>Server 1 10.3.223.11</h1> #测试完成,keepalived的主主配置正确。
三、简述http协议缓存原理及常用首部讲解
http协议缓存的原理: 程序的运行具有局部性特征:
1.时间局部性:一个数据被访问过之后,可能很快会被再次访问到;
2.空间局限性:一个数据被访问时,其周边的数据也有可能被访问到。
http缓存处理的步骤:
接受请求–>解析请求(提取请求的URL及各种首部)–>查询缓存–>判断缓存的有效性–>构建响应报文–>发送响应–>记录日志
与缓存相关的首部:
1.expire:缓存的有效期限,是一个绝对时间
2.if-modified-since:表示基于last-modified机制,缓存服务器到后端真实服务器上判断缓存有效时,判断自从某个绝对时间后,缓存内容是否发生过更改
3.if-none-match:基于Etag机制,用于缓存服务器向后端服务器验证缓存有效性
4.public:可被所有公共缓存缓存,仅可以在响应报文中
5.private:仅可被私有缓存缓存
6.no-store:在响应报文中表示该内容不可花怒才能,在请求报文中表示不能从缓存中进行响应
7.no-cache
在响应报文中表示可以缓存,但是客户端请求的内容缓存命中后,不能直接用缓存直接响应,而是要先到原始服务器上进行校验缓存有效性;
在请求报文中表示要先到原始服务器上进行校验有效性后才能用缓存的内容进行响应
8.max-age:以秒为单位指定的相对时长,表示缓存的最大有效期,是一个相对时长,与expire类似,
9.s-maxage:与max-age类似,但是仅仅用作于公共缓存。
四、varnish实现缓存对象及反代后端主机
varnish简介
1.varnish的程序结构:
varnish主要运行两个进程:Management进程和Child进程(cache进程)。
Management进程主要实现新的配置,编译VLC,监控varnish,初始化varnish以及提供一个命令接口等。management进程会每隔几秒钟探测一下child进程以判断其是否正常运行,如果在指定的时长内未得到child进程的回应,management将会重启此child进程。
varnish基础架构如下:
2.varnish的缓存存储机制:
varnish支持多种不同类型的后端存储,这可以再varnishd启动时使用-s选项指定。后端存储的类型包括:
1.file:自管理的文件系统,使用特定的一个文件存储全部的缓存数据,并通过操作系统的mmap()系统调用将整个缓存文件映射至内存区域(如果内存大小条件允许);varnish重启时,所有缓存对象都将被清除;
2.malloc:使用malloc()库调用在varnish启动时间操作系统申请指定大小的内容空间以缓存对象,varnish重启后,所有缓存对象都将被清除。
3.persistent:与file的功能相同,但可以持久存储数据(即重启varnish数据时不会被清除),处于测试期。
3.varnish日志:
varnish通过可以基于文件系统接口进行访问的共享内存区域来记录日志,为了与系统的其它部分进行交互,Child进程使用了可以通过文件系统接口进行访问的共享内存日志(shared memory log),因此,如果某线程需要记录信息,其仅需要持有一个锁,而后向共享内存中的某内存区域写入数据,再释放持有的锁即可。而为了减少竞争,每个worker线程都使用了日志数据缓存。
varnish的程序环境: /etc/varnish/varnish.params: 配置varnish服务进程的工作特性,例如监听的地址和端口,缓存机制; /etc/varnish/default.vcl:配置各Child/Cache线程的缓存策略; 主程序: /usr/sbin/varnishd CLI interface: /usr/bin/varnishadm Shared Memory Log交互工具: /usr/bin/varnishhist /usr/bin/varnishlog /usr/bin/varnishncsa /usr/bin/varnishstat /usr/bin/varnishtop 测试工具程序: /usr/bin/varnishtest VCL配置文件重载程序: /usr/sbin/varnishreloadvcl Systemd Unit File: /usr/lib/systemd/system/varnish.service varnish服务 /usr/lib/systemd/system/varnishlog.service /usr/lib/systemd/system/varnishncsa.service 日志持久的服务;
varnish的缓存存储机制( Storage Types): -s [name=]type[,options]
· malloc[,size]
内存存储,[,size]用于定义空间大小;重启后所有缓存项失效;
· file[,path[,size[,granularity]]]
磁盘文件存储,黑盒;重启后所有缓存项失效;
· persistent,path,size
文件存储,黑盒;重启后所有缓存项有效;实验;
varnish程序的选项: 程序选项:/etc/varnish/varnish.params文件 -a address[:port][,address[:port][…],默认为6081端口; -T address[:port],默认为6082端口; -s [name=]type[,options],定义缓存存储机制; -u user -g group -f config:VCL配置文件; -F:运行于前台; … 运行时参数:/etc/varnish/varnish.params文件, DEAMONOPTS DAEMONOPTS=”-p threadpoolmin=5 -p threadpoolmax=500 -p threadpooltimeout=300″
-p param=value:设定运行参数及其值; 可重复使用多次;
-r param[,param...]: 设定指定的参数为只读状态;
本文来自投稿,不代表Linux运维部落立场,如若转载,请注明出处:http://www.178linux.com/100814