Python第十四周网络知识和数据库知识总结

604603701@qq.com • • Python笔记

高性能集群Linux virtual server、Nginx、高可用性集群keepalived

三、高性能集群Linux virtual server

1、cluster概念

系统扩展方式：

Scale up：向上扩展，增强。

Scale out：向外扩展增加设备，调度分配问题，cluster

u Cluster：集群,为解决某个特定问题将多台计算机组合起来形成的单个系统

u Linux Cluster类型：

Ø LB：Load Balancing，负载均衡

Ø HA：High Availiablity，高可用，SPOF（single Point Of failure）

MTBF:Mean Time Between Failure 平均无故障时间

MTTR:Mean Time To Restoration（ repair）平均恢复前时间

A=MTBF/（MTBF+MTTR）

(0,1)：99%, 99.5%, 99.9%, 99.99%, 99.999%, 99.9999%

Ø HPC：High-performance computing，高性能 www.top500.org

u 分布式系统：

分布式存储：云盘

分布式计算：hadoop，Spark

 

uLB Cluster的实现

u硬件

F5 Big-IP

Citrix Netscaler

A10 A10

u软件

lvs：Linux Virtual Server

nginx：支持四层调度

haproxy：支持四层调度

ats：apache traffic server，yahoo捐助

perlbal：Perl 编写

Pound

 

u基于工作的协议层次划分：u

传输层（通用）：DPORTLVS：nginx：streamhaproxy：mode tcpu

应用层（专用）：针对特定协议，自定义的请求模型分类

proxy server：

http：nginx, httpd, haproxy(mode http), …fastcgi：nginx, httpd, …mysql：mysql-proxy,

 

会话保持：负载均衡

(1) session sticky：同一用户调度固定服务器

Source IP：LVS sh算法（对某一特定服务而言）

Cookie

(2) session replication：每台服务器拥有全部session

session multicast cluster

(3) session server：专门的session服务器

Memcached，Redis

u HA集群实现方案

keepalived:vrrp协议

ais:应用接口规范

heartbeat

cman+rgmanager(RHCS)

coresync_pacemaker

 

分布式系统。

 

2、lvs介绍

章文嵩 基层内接。

Vs：虚拟服务器。

Rs：真正提供服务

L4：四层调度

u LVS：Linux Virtual Server，负载调度器，集成内核 章文嵩 阿里

官网：http://www.linuxvirtualserver.org/

VS: Virtual Server，负责调度

RS: Real Server，负责真正提供服务

L4：四层路由器或交换机

u 工作原理：VS根据请求报文的目标IP和目标协议及端口将其调度转发至某RS，根

据调度算法来挑选RS

u iptables/netfilter：

iptables：用户空间的管理工具

netfilter：内核空间上的框架

流入：PREROUTING –> INPUT

流出：OUTPUT –> POSTROUTING

转发：PREROUTING –> FORWARD –> POSTROUTING DNAT：

目标地址转换； PREROUTING

 

工作原理：vs根据请求报文的目标ip和目标协议及端口将其调度转发至某RS。根据调度算法来挑选RS。

 

数据包三种流向：进入、经过、穿过。

 

lvs集群类型中的术语：

ØVS：Virtual Server，Director Server(DS)

Dispatcher(调度器)，Load Balancer

ØRS：Real Server(lvs), upstream server(nginx)

backend server(haproxy)

ØCIP：Client IP

ØVIP: Virtual serve IP VS外网的IP

ØDIP: Director IP VS内网的IP

ØRIP: Real server IP

Ø访问流程：CIP <–> VIP == DIP <–> RIP

 

四表：mangle，nat，filter，raw

五链：

 

DANT：目标的地址的转变。

 

 

访问流程：cip—-vip—-dip—-rip

 

3、Lvs集群的类型

 

ulvs: ipvsadm/ipvs

ipvsadm：用户空间的命令行工具，规则管理器

用于管理集群服务及RealServer

ipvs：工作于内核空间netfilter的INPUT钩子上的框架

ulvs集群的类型：

lvs-nat：修改请求报文的目标IP,多目标IP的DNAT

lvs-dr：操纵封装新的MAC地址

lvs-tun：在原请求IP报文之外新加一个IP首部

lvs-fullnat：修改请求报文的源和目标IP

 

4、Lvs-nat模式

本质上就是多目标的DNAT。通过将请求报文

 

调度过程：NAT模式IP包调度过程。

  • RIP和DIP在一个网段上（可以不再一个上），应该使用私网地址。rs的网关要指向dip。

（2）请求报文和响应报文都必须经由Director转发，Director易于成为系统瓶颈

（3）支持端口映射，可修改请求报文的目标PORT

（4）VS必须是Linux系统，RS可以是任意OS系统

Nat模式ip包调度过程

 

Vs/nat的体系结构

 

5、lvs-DR模型

Ip地址，启动时候发出arp的广播，使用此地址。

数据发送回去的时候直接到达cip，不是原路返回的。

 

LVS-DR：Direct Routing，直接路由，LVS默认模式,应用最广泛,通过为请求报文重新

封装一个MAC首部进行转发，源MAC是DIP所在的接口的MAC，目标MAC是某挑选出

的RS的RIP所在接口的MAC地址；源IP/PORT，以及目标IP/PORT均保持不变

u Director和各RS都配置有VIP

(1) 确保前端路由器将目标IP为VIP的请求报文发往Director

Ø 在前端网关做静态绑定VIP和Director的MAC地址

Ø 在RS上使用arptables工具

arptables -A IN -d $VIP -j DROP

arptables -A OUT -s $VIP -j mangle –mangle-ip-s $RIP

Ø 在RS上修改内核参数以限制arp通告及应答级别

arp_announce

arp_ignore

  • RS的RIP可以使用私网地址，也可以是公网地址；RIP与DIP在同一IP网络；R的网关不能指向DIP，以确保响应报文不会经由Director(3) RS和Director要在同一个物理网络(4) 请求报文要经由Director，但响应报文不经由Director，而由RS直接发往Client(5) 不支持端口映射（端口不能修败）(6) RS可使用大多数OS

 

避免ip冲突：

  • 网络中发广播，
  • 对外不宣城使用ip的地址。

 

Rs的rip可以使用私网地址，可以使用公网地址。

请求报文经由lvs，响应报文不经过lvs，有rs直接到达客户端。

端口不支持映射。

 

Rs距离太近了。

6、lvs-tun模式

不修改请求报文的头部，直接增加一层报文头部。

  • dip，VIP，rip都应该是公网地址
  • Rs的网关不能，也不能指向dip
  • 请求报文要经由director，但影响不能经由director
  • 不支持端口映射
  • Rs的os必须支持隧道功能

 

 

 

7、lvs-fullnat模式

同时更改请求报文的源ip地址和目标ip地址进行转发。

Cip   —-> dip

Vip   —–>rip

  • VIP是公网地址，rip和dip是私网地址，且通常不在同一ip网络，因此，rip的网关一般不会指向dip。
  • 认识收到的请求报文原地址是dip，因此，只需要响应给dip，但director还要将其发往client。
  • 请求和享用报文都经由director
  • 支持端口映射

此类型kernel默认不支持。

8、lvs工作模式总结

 

  Vs/nat Vs/tun Vs/dr
Server Any Tunneling Non-arp device
Server network Private Lan/wan Lan
Servernumber Low（10-20） High（100） High（100）
Server gateway Load balancer Own router Own router

 

 

u lvs-nat与lvs-fullnat：请求和响应报文都经由Director

lvs-nat：RIP的网关要指向DIP，源地址指向VIP，

lvs-fullnat：RIP和DIP未必在同一IP网络，但要能通信，源地址也要替换。

 

u lvs-dr与lvs-tun：请求报文要经由Director，但响应报文由RS直接发

往Client

lvs-dr：通过封装新的MAC首部实现，通过MAC网络转发，客户端发请求到lvs，只是参与请求报文，不参与报文的转发。

 

lvs-tun：通过在原IP报文外封装新IP头实现转发，支持远距离通信。两个报文头部。请求和响应报文不是同路返回。

9、ipvs scheduler

ipvs scheduler：

u根据其调度时是否考虑各RS当前的负载状态

两种：静态方法和动态方法

调度：静态调度和动态调度

静态方法：仅根据算法本身进行调度。

  • RR轮询
  • WRR加权轮询
  • sh，实现session sticky，源地址hash运算。
  • DH：目标地址hash。正向代理缓存的情况。

不考虑后端服务器的负载状态。

6种动态算法：

动态方法：主要根据每rs当前的负载状态机调度算法进行调度，overhead=value较小的rs将被调度：

  • LC：least connections适用于长连接应用

Overhead=activeconns*256+inactiveconns

  • WLC：默认调度。

Overhead=(activeconns*256+inactiveconns)/weight

  • SED：初始连接高权重优先

Overhead=(activeconns+1)*256/weight

  • NQ：第一轮均匀分配，后续SED。
  • LBLC：动态的DH算法，使用场景，根据负载状态实现正向代理。
  • LBLCR：带复制功能的LBLC。解决LBLC负载不均衡问题，从负载重的复制到负载轻的rs。

10、ipvs

Ipvsadm/ipvs：

Ipvs：

grep -i -C 10 “ipvs” /boot/config-VERSION-RELEASE.x86_64

支持的协议：TCP， UDP， AH， ESP， AH_ESP, SCTP

Ipvs集群：

管理集群服务

管理服务商的rs

11、ipvsadm包构成

程序包：ipvsadm：

Unit File: ipvsadm.service

Ø主程序：/usr/sbin/ipvsadm

Ø规则保存工具：/usr/sbin/ipvsadm-save

Ø规则重载工具：/usr/sbin/ipvsadm-restore

Ø配置文件：/etc/sysconfig/ipvsadm-config

12、ipvsadm命令

核心功能：

集群服务管理：增删改，

集群服务的rs管理：增、删、改

查看：

ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]] [-M netmask] [–ppersistence_engine] [-b sched-flags]

ipvsadm -D -t|u|f service-address 删除

ipvsadm –C 清空

ipvsadm –R 重载

ipvsadm -S [-n] 保存

ipvsadm -a|e -t|u|f service-address -r server-address [options]

ipvsadm -d -t|u|f service-address -r server-address

ipvsadm -L|l [options]

ipvsadm -Z [-t|u|f service-addres

 

u管理集群服务：增、改、删

u增、改：

ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]]

u删除：

ipvsadm -D -t|u|f service-address

uservice-address：

-t|u|f：

-t: TCP协议的端口，VIP:TCP_PORT

-u: UDP协议的端口，VIP:UDP_PORT

-f：firewall MARK，标记，一个数字

u[-s scheduler]：指定集群的调度算法，默认为wlc

 

u管理集群上的RS：增、改、删

u增、改：ipvsadm -a|e -t|u|f service-address -r server-address [-g|i|m] [-w

weight]

u删：ipvsadm -d -t|u|f service-address -r server-address

userver-address：

rip[:port] 如省略port，不作端口映射

u选项：

lvs类型：

-g: gateway, dr类型，默认

-i: ipip, tun类型

-m: masquerade, nat类型

-w weight：权重

 

清空定义的所有内容：ipvsadm –C

u清空计数器：ipvsadm -Z [-t|u|f service-address]

u查看：ipvsadm -L|l [options]

–numeric, -n：以数字形式输出地址和端口号

–exact：扩展信息，精确值

–connection，-c：当前IPVS连接输出

–stats：统计信息

–rate ：输出速率信息

uipvs规则： /proc/net/ip_vs

uipvs连接：/proc/net/ip_vs_conn

 

13、保存及重载规则

保存：议保存至/etc/sysconfig/ipvsadm

ipvsadm-save > /PATH/TO/IPVSADM_FILE

ipvsadm -S > /PATH/TO/IPVSADM_FILE

systemctl stop ipvsadm.service

u重载：

ipvsadm-restore < /PATH/FROM/IPVSADM_FILE

ipvsadm -R < /PATH/FROM/IPVSADM_FILE

systemctl restart ipvsadm.service

 

 

yum clean all 清理yum源的缓存。

Lvs只是处理请求报文，网关可以随意配置，不能不配置。

 

14、Lvs

u负载均衡集群设计时要注意的问题

(1) 是否需要会话保持

(2) 是否需要共享存储

共享存储：NAS， SAN， DS（分布式存储）

数据同步：

ulvs-nat：

设计要点：

(1) RIP与DIP在同一IP网络, RIP的网关要指向DIP

(2) 支持端口映射

(3) Director要打开核心转发功能

 

##############练习题一个

 

15、lvs-DR

DR模型中各主机均需要配置VIP，解决地址冲突的方式有三种：

  • 在前端网关做静态绑定
  • 在各rs使用arptables
  • 在各rs修改内核参数，来限制arp响应和通告的级别

限制响应级别：arp_ignore

0：默认值，表示可使用本地任意接口上配置的任意地址进行响应

1: 仅在请求的目标IP配置在本地主机的接收到请求报文的接口上时，才给予响应

u 限制通告级别：arp_announce

0：默认值，把本机所有接口的所有信息向每个接口的网络进行通告

1：尽量避免将接口信息向非直接连接网络进行通告

2：必须避免将接口信息向非本网络进行通告

 

16、rs预配置脚本信息

#!/bin/bash

vip=192.168.0.100

mask=’255.255.255.255‘

dev=lo:1

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 $dev $vip netmask $mask broadcast $vip up

route add -host $vip dev $dev

;;

stop)

ifconfig $dev 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

 

17、vs的配置脚本

#!/bin/bash

vip=’192.168.0.100′

iface=’eth0:1’mask=’255.255.255.255′

port=’80’

rs1=’192.168.0.101′

rs2=’192.168.0.102′

scheduler=’wrr’

type=’-g’

case $1 in

start)

ifconfig $iface $vip netmask $mask broadcast $vip up

iptables -F

ipvsadm -A -t ${vip}:${port} -s $schedule

ripvsadm -a -t ${vip}:${port} -r ${rs1} $type -w 1

ipvsadm -a -t ${vip}:${port} -r ${rs2} $type -w 1

;;

stop)

ipvsadm -C

ifconfig $iface down

;;

*)

echo “Usage $(basename $0) start|stop“;exit 1

;;

esac

 

##############################实现NAT模式

18、firewall Mark

Fwm：fire wall mark

Mark target 可用于给特定的报文打标记

–set-mark value

其中：value为十六进制数字

借助于防火墙标记分类报文，而后基于标记定义集群服务，可将多个不同的应用使用同一个集群服务进行调度。

实现方法：

在Director主机打标记：

iptables -t mangle -A PREROUTING -d $vip -p $proto –m multiport –dports $port1,$port2,… -j MARK –set-mark NUMBER

Ø在Director主机基于标记定义集群服务：

ipvsadm -A -f NUMBER [options]

19、持久连接

u session 绑定：对共享同一组RS的多个集群服务，需要统一进行绑定，lvs sh算法无

法实现

u 持久连接（ lvs persistence ）模板：实现无论使用任何调度算法，在一段时间内

（默认360s ），能够实现将来自同一个地址的请求始终发往同一个RS

ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]]

u 持久连接实现方式：

Ø 每端口持久（PPC）：每个端口对应定义为一个集群服务，每集群服务单独调度

Ø 每防火墙标记持久（PFWMC）：基于防火墙标记定义集群服务；可实现将多个端

口上的应用统一调度，即所谓的port Affinity

Ø 每客户端持久（PCC）：基于0端口（表示所有服务）定义集群服务，即将客户端

对所有应用的请求都调度至后端主机，必须定义为持久模式

20、lvs高可用性

u 1 Director不可用，整个系统将不可用；SPoF Single Point of Failure

解决方案：高可用

keepalived heartbeat/corosync

u 2 某RS不可用时，Director依然会调度请求至此RS

解决方案： 由Director对各RS健康状态进行检查，失败时禁用，成功时启用

keepalived heartbeat/corosync ldirectord

检测方式：

(a) 网络层检测，icmp

(b) 传输层检测，端口探测

(c) 应用层检测，请求某关键资源

RS全不用时：backup server, sorry server

21、ldirectord

uldirectord：监控和控制LVS守护进程，可管理LVS规则

u包名：ldirectord-3.9.6-0rc1.1.1.x86_64.rpm

u文件：

/etc/ha.d/ldirectord.cf 主配置文件

/usr/share/doc/ldirectord-3.9.6/ldirectord.cf 配置模版

/usr/lib/systemd/system/ldirectord.service 服务

/usr/sbin/ldirectord 主程序

/var/log/ldirectord.log 日志

/var/run/ldirectord.ldirectord.pid pid文件

22、ldirectord配置文件实例

checktimeout=3

checkinterval=1

autoreload=yes

logfile=“/var/log/ldirectord.log“ #日志文件

quiescent=no #down时yes权重为0，no为删除

virtual=5 #指定VS的FWM或IP：port

real=172.16.0.7:80 gate 2

real=172.16.0.8:80 gate 1

fallback=127.0.0.1:80 gate #sorry server

service=http

scheduler=wrr

checktype=negotiate

checkport=80

request=”index.html”

receive=“Test Ldirector”

 

 

 

四、Nginx

1、性能影响

u有很多研究都表明，性能对用户的行为有很大的影响：u79%的用户表示不太可能再次打开一个缓慢的网站u47%的用户期望网页能在2秒钟以内加载u40%的用户表示如果加载时间超过三秒钟，就会放弃这个网站u页面加载时间延迟一秒可能导致转换损失7%，页面浏览量减少11%u8秒定律：用户访问一个网站时，如果等待网页打开的时间超过8秒，会有超过30%的用户放弃

 

2、httpd mpm

Prefork：进程模型，两级结构，主进程master负责生成子进程，每个子进程负责影响一个请求。

Worker：线程模型，三级结构，主进程master负责生成子进程，每个子进程负责生成多个线程，每个线程响应一个请求。

Event：线程模型，三级结构，主进程master负责生成子进程，每个子进程响应多个请求。

3、I/O模型

网络IO：本质上就是socket读取

磁盘IO、

每次IO，都要经由两个阶段。

第一步：将数据从磁盘文件先加载至内核内存空间（缓冲区），等待数据准备完成，时间较长。

第二步：将数据从内核缓冲区复制到用户空间的进程的内存中，时间较短。

 

同步/异步：关注的是消息通信机制。

同步：synchronous 调用者自已主动等待被调用者返回消息，才能继续执行

异步：asynchronous 被调用者通过状态、通知或回调机制主动通知调用者被调用者的运行状态

 

阻塞/非阻塞：关注调用者在等待结果返回之前所处的状态

阻塞：blocking，指IO操作需要彻底完成后才返回到用户空间，调用结果返回之前，调用者被挂起。

非阻塞：nonblocking，指IO操作被调用后立即返回给用户一个状态值，无需等到IO操作彻底完成，最终的调用结果返回之前，调用者不会被挂起

I/O：模型：

阻塞型，非阻塞型、复用型、信号驱动型、异步

 

4、IO模型的实现

1）同步阻塞IO模型

u同步阻塞IO模型是最简单的IO模型，用户线程在内核进行IO操作时被阻塞

u用户线程通过系统调用read发起IO读操作，由用户空间转到内核空间。内核等

到数据包到达后，然后将接收的数据拷贝到用户空间，完成read操作

u用户需要等待read将数据读取到buffer后，才继续处理接收的数据。整个IO请

求的过程中，用户线程是被阻塞的，这导致用户在发起IO请求时，不能做任何

事情，对CPU的资源利用率不够

 

2）同步非阻塞IO模型

u用户线程发起IO请求时立即返回。但并未读取到任何数据，用户线程需要不断

地发起IO请求，直到数据到达后，才真正读取到数据，继续执行。即 “轮询”

机制

u整个IO请求的过程中，虽然用户线程每次发起IO请求后可以立即返回，但是为

了等到数据，仍需要不断地轮询、重复请求，消耗了大量的CPU的资源

u是比较浪费CPU的方式，一般很少直接使用这种模型，而是在其他IO模型中使

用非阻塞IO这一特性

 

3）IO多路复用模型

u 多个连接共用一个等待机制，本模型会阻塞进程，但是进程是阻塞在select或者poll这两个系统调用上，而不是阻塞在真正的IO操作上

u 用户首先将需要进行IO操作添加到select中，继续执行做其他的工作（异步），同时等待select系统调用返回。当数据到达时，IO被激活，select函数返回。用户线程正式发起read请求，读取数据并继续执行。

u 从流程上来看，使用select函数进行IO请求和同步阻塞模型没有太大的区别，甚至还多了添加监视IO，以及调用select函数的额外操作，效率更差。并且阻塞了两次，但是第一次阻塞在select上时，select可以监控多个IO上是否已有IO操作准备就绪，即可达到在同一个线程内同时处理多个IO请求的目的。而不像阻塞IO那种，一次只能监控一个IO

u 虽然上述方式允许单线程内处理多个IO请求，但是每个IO请求的过程还是阻塞的（在select函数上阻塞），平均时间甚至比同步阻塞IO模型还要长。如果用户线程只是注册自己需要的IO请求，然后去做自己的事情，等到数据到来时再进行处理，则可以提高CPU的利用率

u IO多路复用是最常使用的IO模型，但是其异步程度还不够“彻底”，因为它使用了会阻塞线程的select系统调用。因此IO多路复用只能称为异步阻塞IO模型，而非真正的异步IO

4）多路IO复用

IO多路复用是指内核一旦发现进程指定的一个或者多个IO条件准备读取，它就通

知该进程

u IO多路复用适用如下场合：

Ø 当客户端处理多个描述符时（一般是交互式输入和网络套接口），必须使用

I/O复用

Ø 当一个客户端同时处理多个套接字时，此情况可能的但很少出现

Ø 当一个TCP服务器既要处理监听套接口，又要处理已连接套接口，一般也要用

到I/O复用

Ø 当一个服务器即要处理TCP，又要处理UDP，一般要使用I/O复用

Ø 当一个服务器要处理多个服务或多个协议，一般要使用I/O复用

5）信号驱动IO模型

信号驱动IO：signal-driven I/O

u用户进程可以通过sigaction系统调用注册一个信号处理程序，然后主程序可以

继续向下执行，当有IO操作准备就绪时，由内核通知触发一个SIGIO信号处理程

序执行，然后将用户进程所需要的数据从内核空间拷贝到用户空间

u此模型的优势在于等待数据报到达期间进程不被阻塞。用户主程序可以继续执

行，只要等待来自信号处理函数的通知

u该模型并不常用

I/O模型的具体实现：

Select：Linux实现对应，I/O复用模型，BSD4.2最早实现。

 

6）异步IO模型

u异步IO与信号驱动IO最主要的区别是信号驱动IO是由内核通知何时可以进行IO

操作，而异步IO则是由内核告诉我们IO操作何时完成了。具体来说就是，信号

驱动IO当内核通知触发信号处理程序时，信号处理程序还需要阻塞在从内核空

间缓冲区拷贝数据到用户空间缓冲区这个阶段，而异步IO直接是在第二个阶段

完成后内核直接通知可以进行后续操作了

u相比于IO多路复用模型，异步IO并不十分常用，不少高性能并发服务程序使用

IO多路复用模型+多线程任务处理的架构基本可以满足需求。况且目前操作系统

对异步IO的支持并非特别完善，更多的是采用IO多路复用模型模拟异步IO的方

式（IO事件触发时不直接通知用户线程，而是将数据读写完毕后放到用户指定

的缓冲区中）

 

7）五种IO模型

 

lamp  lnmp  lemp

8）IO模型的具体实现

主要实现方式有几种：

Select：Linux实现对应，IO复用模型，bsd4.2最早实现。

Poll：Linux实现，对应IO复用模型，system v Unix最早实现。

Epoll：Linux实现，对应IO模型，具有信号驱动IO模型的某些特征。

Kqueue：rreedsd实现，对应IO复用模型，具备信号驱动IO模型的某些特征。

/dev/poll：SUN的Solaris实现，对应I/O复用模型，具有信号驱动I/O模型的某些特性

Iocp Windows实现，对应第5种（异步I/O）模型

5、select/poll/epoll

uSelect:POSIX所规定，目前几乎在所有的平台上支持，其良好跨平台支持也是

它的一个优点，本质上是通过设置或者检查存放fd标志位的数据结构来进行下

一步处理

u缺点

Ø单个进程可监视的fd数量被限制，即能监听端口的数量有限

cat /proc/sys/fs/file-max

Ø对socket是线性扫描，即采用轮询的方法，效率较低

Øselect 采取了内存拷贝方法来实现内核将 FD 消息通知给用户空间，这样一

个用来存放大量fd的数据结构，这样会使得用户空间和内核空间在传递该结

构时复制开销大

 

poll

Ø本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每

个fd对应的设备状态

Ø其没有最大连接数的限制，原因是它是基于链表来存储的

Ø大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复

制是不是有意义

Øpoll特点是“水平触发”，如果报告了fd后，没有被处理，那么下次poll时会

再次报告该fd

Ø边缘触发：只通知一次

 

u epoll：在Linux 2.6内核中提出的select和poll的增强版本

Ø 支持水平触发LT和边缘触发ET，最大的特点在于边缘触发，它只告诉进程哪些fd刚刚

变为就需态，并且只会通知一次

Ø 使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用

类似callback的回调机制来激活该fd，epoll_wait便可以收到通知

u 优点:

Ø 没有最大并发连接的限制：能打开的FD的上限远大于1024(1G的内存能监听约10万个

端口)

Ø 效率提升：非轮询的方式，不会随着FD数目的增加而效率下降；只有活跃可用的FD

才会调用callback函数，即epoll最大的优点就在于它只管理“活跃”的连接，而跟连

接总数无关

Ø 内存拷贝，利用mmap()文件映射内存加速与内核空间的消息传递；即epoll使用

mmap减少复制开销

 

 

 

6、Nginx介绍

Nginx：engine X ，2002年，开源，商业版

uhttp协议：web服务器（类似于httpd）、http reverse proxy（类似于

httpd）、imap/pop3 reverse proxy,tcp

uNGINX is a free, open-source, high-performance an HTTP and reverse

proxy server, a mail proxy server, and a generic TCP/UDP proxy server

uC10K（10K Connections）

u二次开发版：Tengine, OpenResty

u官网：http://nginx.org

 

正向代理和反向代理：

 

u特性：

Ø 模块化设计，较好的扩展性

Ø 高可靠性

Ø 支持热部署：不停机更新配置文件，升级版本，更换日志文件

Ø 低内存消耗：10000个keep-alive连接模式下的非活动连接，仅需要2.5M内存

Ø event-driven,aio,mmap，sendfile

u基本功能：

Ø 静态资源的web服务器

Ø http协议反向代理服务器

Ø pop3/imap4协议反向代理服务器

Ø FastCGI(lnmp),uWSGI(python)等协议

Ø 模块化（非DSO），如zip，SSL模块

 

7、Nginx架构

 

uweb服务相关的功能：

虚拟主机（server）

支持 keep-alive 和管道连接

访问日志（支持基于日志缓冲提高其性能）

url rewirte

路径别名

基于IP及用户的访问控制

支持速率限制及并发数限制

重新配置和在线升级而无须中断客户的工作进程

Memcached 的 GET 接口

 

 

nginx的程序架构：

master/worker结构

Ø一个master进程：

负载加载和分析配置文件、管理worker进程、平滑升级

Ø一个或多个worker进程

处理并响应用户请求

Ø缓存相关的进程：

cache loader：载入缓存对象

cache manager：管理缓存对象

 

unginx高度模块化，但其模块早期不支持DSO机制；1.9.11版本支持动态装载和

卸载

u模块分类：

Ø核心模块：core module

Ø标准模块：

  • HTTP 模块： ngx_http_*

HTTP Core modules 默认功能

HTTP Optional modules 需编译时指定

  • Mail 模块 ngx_mail_*
  • Stream 模块 ngx_stream_*

Ø第三方模块

8、nginx的功用

静态的web资源服务器

html，图片，js，css，txt等静态资源

u结合FastCGI/uWSGI/SCGI等协议反向代理动态资源请求

uhttp/https协议的反向代理

uimap4/pop3协议的反向代理

utcp/udp协议的请求转发（反向代理）

 

curl www.jd.com -I  查看一个网站的web服务器。

 

9、安装nginx

1）yum install epel-release -y  安装epel源。  centos7上面

2）yum install nginx

3）systemctl start nginx  （查看80端口是否是nginx占用的）

4）systemctl stop firewalld 关闭防火墙

5）curl-ip地址就可以访问主页，浏览器上也可以访问。

6）cd /etc/nginxvim nginx.conf相关配置文件。

7）使用：

mkdir /app/website{1,2,3} -pv  创建三个网站

写入文件：echo www.a.com > /app/website1/index.html

cd /etc/nginx/conf.d编辑vim vhost.conf

文件，创建以下内容：

server {

listen 80;

server_name www.a.com;

root /app/website1/;

}

server {

listen 80;

server_name www.b.com;

root /app/website2/;

}

server {

listen 80;

server_name www.c.com;

root /app/website3/;

}

生效以下服务：

systemctl restart nginx

 

Ping www.a.com网站和curl 网站。

 

利用另外一台虚拟主机访问网站：

改变主机的vim /etc/hosts文件，增加要访问的网址ip和网站名词。

 

 

反向代理服务器实现：

 

 

课件文档：官方：

http://nginx.org/packages/centos/7/x86_64/RPMS

u Fedora-EPEL:

https://mirrors.aliyun.com/epel/7/x86_64/

u 编译安装：

  • yum install pcre-devel openssl-devel zlib-devel
  • useradd -r nginx
  • ./configure –prefix=/usr/local/nginx –conf-path=/etc/nginx/nginx.conf –error-logpath=/var/log/nginx/error.log –http-log-path=/var/log/nginx/access.log –pidpath=/var/run/nginx.pid –lock-path=/var/run/nginx.lock –user=nginx –group=nginx

–with-http_ssl_module –with-http_v2_module –with-http_dav_module –withhttp_stub_status_module –with-threads –with-file-aio

  • make && make install

u编译安装nginx选项：

Ø –prefix=/etc/nginx 安装路径

Ø –sbin-path=/usr/sbin/nginx 指明nginx程序文件安装路径

Ø –conf-path=/etc/nginx/nginx.conf 主配置文件安装位置

Ø –error-log-path=/var/log/nginx/error.log 错误日志文件安装位置

Ø –http-log-path=/var/log/nginx/access.log 访问日志文件安装位置

Ø –pid-path=/var/run/nginx.pid 指明pid文件安装位置

Ø –lock-path=/var/run/nginx.lock 锁文件安装位置

Ø –http-client-body-temp-path=/var/cache/nginx/client_temp 客户端body部分的临时文

件存放路径，如果服务器允许客户端使用put方法提交大数据时，临时存放的磁盘路

径

 

–http-proxy-temp-path=/var/cache/nginx/proxy_temp 作为代理服务器，服务器响应

报文的临时文件存放路径

Ø –http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp 作为fastcgi代理服务器，服务

器响应报文的临时文件存放路径

Ø –http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp 作为uwsgi代理服务器，服务器

响应报文的临时文件存放路径

Ø –http-scgi-temp-path=/var/cache/nginx/scgi_temp 作为scgi反代服务器，服务器响应

报文的临时文件存放路径

Ø –user=nginx 指明以那个身份运行worker进程，主控master进程一般由root运行

Ø –group=nginx

Ø –with-http_ssl_module 表示把指定模块编译进来

 

u ls /usr/local/nginx/

html是测试页，sbin是主程序

u ls /usr/local/nginx/sbin/

nginx 只有一个程序文件

u ls /usr/local/nginx/html/

50x.html index.html 测试网页

u Nginx：默认为启动nginx

-h 查看帮助选项

-V 查看版本和配置选项

-t 测试nginx语法错误

-c filename 指定配置文件(default: /etc/nginx/nginx.conf)

-s signal 发送信号给master进程，signal可为：stop, quit, reopen, reload 示例：-s

stop 停止nginx -s reload 加载配置文件

-g directives 在命令行中指明全局指令

 

分为master进程和worker进程。

制作虚拟主机网站

 

 

 

4、反向代理http协议

调度的集合

 

 

 

 

Weight=number权重

设置down，只是先更新一部分。

 

 

Ip-hash：客户端的ip地址做hash计算。源地址。

 

 

 

五、高可用性集群keepalived

1、集群cluster

集群类型：

Lb lvs/nginx(http/upstream,stream/upstream)。

HA的高可用性

Spof：single point of failure

Hpc

系统可用性的公式： A=MTB/（MTBF+MTTR）

（0,1），95%

几个9指标：99%，99.999%，99.9999%：

系统故障：

硬件故障：设计缺陷，wear out（损耗）、自然灾害

软件故障：设计缺陷

2、集群cluster

u提升系统高用性的解决方案之降低MTTR：

手段：冗余redundant

active/passive 主备

active/active双主

active –> HEARTBEAT –> passive

active <–> HEARTBEAT <–> active

u高可用的是“服务”：

HA nginx service：

vip/nginx process[/shared storage]

资源：组成一个高可用服务的“组件”

(1) passive node的数量

(2) 资源切换

 

shared storage：

NAS：文件共享服务器；

SAN：存储区域网络，块级别的共享

uNetwork partition：网络分区

quorum：法定人数

with quorum： > total/2

without quorum: <= total/2

隔离设备： fence

node：STONITH = Shooting The Other Node In The Head，断

电重启

资源：断开存储的连接

 

TWO nodes Cluster

辅助设备：ping node, quorum disk

uFailover：故障切换，即某资源的主节点故障时，将资源转移至其它节点的操作

uFailback：故障移回，即某资源的主节点故障后重新修改上线后，将之前已转移

至其它节点的资源重新切回的过程

uHA Cluster实现方案:

ais：应用接口规范 完备复杂的HA集群

RHCS：Red Hat Cluster Suite红帽集群套件

heartbeat

corosync

vrrp协议实现：虚拟路由冗余协议

Keepalived

 

 

 

3、keepalived

vrrp协议：Virtual Router Redundancy Protocol

u术语：

虚拟路由器：Virtual Router

虚拟路由器标识：VRID(0-255)，唯一标识虚拟路由器

物理路由器：

master：主设备

backup：备用设备

priority：优先级

VIP：Virtual IP

VMAC：Virutal MAC (00-00-5e-00-01-VRID)

 

u通告：心跳，优先级等；周期性

u工作方式：抢占式，非抢占式

u安全工作：

认证：

无认证

  • 简单字符认证：预共享密钥Ssh-keygen生产公钥私钥。

MD5

u工作模式：

主/备：单虚拟路径器

主/主：主/备（虚拟路径器1），备/主（虚拟路径器2）

 

ukeepalived:

vrrp协议的软件实现，原生设计目的为了高可用ipvs服务

u功能：

Øvrrp协议完成地址流动

Ø为vip地址所在的节点生成ipvs规则(在配置文件中预先定义)

Ø为ipvs集群的各RS做健康状态检测

Ø基于脚本调用接口通过执行脚本完成脚本中定义的功能，进而影响集群事务，

以此支持nginx、haproxy等服务

 

u组件：

Ø 核心组件：

vrrp stack

ipvs wrapper

checkers

Ø 控制组件：配置文件分析器

Ø IO复用器

Ø 内存管理组件

 

Keepalived组成：

 

 

Keepalived实现：

uHA Cluster 配置准备：

Ø (1) 各节点时间必须同步

ntp, chrony

Ø (2) 确保iptables及selinux不会成为阻碍

Ø (3) 各节点之间可通过主机名互相通信（对KA并非必须）

建议使用/etc/hosts文件实现

Ø (4) 各节点之间的root用户可以基于密钥认证的ssh服务完成互相通信（对KA并

非必须）

 

keepalived安装配置：

CentOS 6.4+ Base源

u程序环境：

Ø主配置文件：/etc/keepalived/keepalived.conf

Ø主程序文件：/usr/sbin/keepalived

ØUnit File：/usr/lib/systemd/system/keepalived.service

ØUnit File的环境配置文件：/etc/sysconfig/keepalived

 

配置文件组件部分：

uTOP HIERACHY

GLOBAL CONFIGURATION

Global definitions

Static routes/addresses

VRRPD CONFIGURATION

VRRP synchronization group(s)：vrrp同步组

VRRP instance(s)：即一个vrrp虚拟 路由器

LVS CONFIGURATION

Virtual server group(s)

Virtual server(s)：ipvs集群的vs和rs

 

配置语法：

u 配置虚拟路由器：

vrrp_instance <STRING> {

….

}

u 专用参数：

state MASTER|BACKUP：当前节点在此虚拟路由器上的初始状态；只能有一个是

MASTER，余下的都应该为BACKUP

interface IFACE_NAME：绑定为当前虚拟路由器使用的物理接口

virtual_router_id VRID：当前虚拟路由器惟一标识，范围是0-255

priority 100：当前物理节点在此虚拟路由器中的优先级；范围1-254

advert_int 1：vrrp通告的时间间隔，默认1s

 

 

authentication { #认证机制auth_type AH|PASSauth_pass <PASSWORD> 仅前8位有效}virtual_ipaddress { #虚拟IP<IPADDR>/<MASK> brd <IPADDR> dev <STRING> scope <SCOPE> label

<LABEL>192.168.200.17/24 dev eth1192.168.200.18/24 dev eth2 label eth2:1}track_interface { #配置监控网络接口，一旦出现故障，则转为FAULT状态实现地址转移eth0eth1

 

unopreempt：定义工作模式为非抢占模式

upreempt_delay 300：抢占式模式，节点上线后触发新选举操作的延迟时长，

默认模式

u定义通知脚本：

notify_master <STRING>|<QUOTED-STRING>：

当前节点成为主节点时触发的脚本

notify_backup <STRING>|<QUOTED-STRING>：

当前节点转为备节点时触发的脚本

notify_fault <STRING>|<QUOTED-STRING>：

当前节点转为“失败”状态时触发的脚本

notify <STRING>|<QUOTED-STRING>：

通用格式的通知触发机制，一个脚本可完成以上三种状态的转换时的通知

 

 

4、单主配置详细信息

u单主配置示例：

! 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

router_id node1 #主机名，在另一结点为node2

vrrp_mcast_group4 224.0.100.100

}

 

vrrp_instance VI_1 {

state MASTER #在另一个结点上为BACKUP

interface eth0virtual_router_id 6 #多个节点必须相同

priority 100 #在另一个结点上为90

advert_int 1  #通告间隔1s

authentication {

auth_type PASS #预共享密钥认证

auth_pass 571f97b2}

virtual_ipaddress {

172.18.100.66/16 dev eth0 label eth0:0

}

track_interface {

eth0

}

}

 

5、双主配置信息

双主模型示例：

! Configuration File for keepalived

Global_defs{

notification_emai{

root@localho

}

notification_email_from keepalived@localhost

smtp_server 127.0.0.1

smtp_connect_timeout 30

router_id node1

vrrp_mcast_group4 224.0.100.100

}

 

vrrp_instance VI_1 {

state MASTER

interface eth0

virtual_router_id 6

priority 100

advert_int 1

authentication {

auth_type PASS

auth_pass 571f97b2

}

virtual_ipaddress {

172.16.0.10/16 dev eth0

}

}

 

vrrp_instance VI_2 {

state BACKUP

interface eth0

virtual_router_id 8

priority 98

advert_int 1

authentication {

auth_type PASS

auth_pass 578f07b2

}

virtual_ipaddress {

172.16.0.11/16 dev eth0

}

}

 

脚本：

#!/bin/bash

#

contact=’root@localhost’

notify() {

mailsubject=”$(hostname) to be $1, vip floating”

mailbody=”$(date +’%F %T’): vrrp transition, $(hostname) changed to be $1″

echo “$mailbody” | mail -s “$mailsubject” $contact

}

case $1 in

master)

notify master

;;

backup)

notify backup

;;

fault)

notify fault

;;

*)

echo “Usage: $(basename $0) {master|backup|fault}”

exit 1

;;

esac

 

脚本调用方法：

notify_master “/etc/keepalived/notify.sh master”

notify_backup “/etc/keepalived/notify.sh backup”

notify_fault “/etc/keepalived/notify.sh faul

 

常用参数：

u delay_loop <INT>：检查后端服务器的时间间隔

u lb_algo rr|wrr|lc|wlc|lblc|sh|dh：定义调度方法

u lb_kind NAT|DR|TUN：集群的类型

u persistence_timeout <INT>：持久连接时长

u protocol TCP：服务协议，仅支持TCP

u sorry_server <IPADDR> <PORT>：所有RS故障时，备用服务器地址

u real_server <IPADDR> <PORT>

{

weight <INT> RS权重

notify_up <STRING>|<QUOTED-STRING> RS上线通知脚本

notify_down <STRING>|<QUOTED-STRING> RS下线通知脚本

HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHEC K { … }：定义当前主

机的健康状态检测方法

}

6、Keepalived配置检测

u HTTP_GET|SSL_GET：应用层检测

HTTP_GET|SSL_GET {

url {

path <URL_PATH>：定义要监控的URL

status_code <INT>：判断上述检测机制为健康状态的响应码

digest <STRING>：判断为健康状态的响应的内容的校验码

}

connect_timeout <INTEGER>：连接请求的超时时长

nb_get_retry <INT>：重试次数

delay_before_retry <INT>：重试之前的延迟时长

connect_ip <IP ADDRESS>：向当前RS哪个IP地址发起健康状态检测请求

connect_port <PORT>：向当前RS的哪个PORT发起健康状态检测请求

bindto <IP ADDRESS>：发出健康状态检测请求时使用的源地址

bind_port <PORT>：发出健康状态检测请求时使用的源端口

}

u TCP_CHECK {

connect_ip <IP ADDRESS>：向当前RS的哪个IP地址发起健康状态检测

请求

connect_port <PORT>：向当前RS的哪个PORT发起健康状态检测请求

bindto <IP ADDRESS>：发出健康状态检测请求时使用的源地址

bind_port <PORT>：发出健康状态检测请求时使用的源端口

connect_timeout <INTEGER>：连接请求的超时时长

}

7、单主模型ipvs实例

u高可用的ipvs集群示例：

! 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

router_id node1

vrrp_mcast_group4 224.0.100.10

}

 

vrrp_instance VI_1 {

state MASTER

interface eth0

virtual_router_id 6

priority 100

advert_int 1

authentication {

auth_type PASS

auth_pass 571f97b2

}

virtual_ipaddress {

172.16.0.10/16 dev eth0

}

notify_master “/etc/keepalived/notify.sh master”

notify_backup “/etc/keepalived/notify.sh backup”

notify_fault “/etc/keepalived/notify.sh fault”

}

 

virtual_server 172.16.0.10 80 {

delay_loop 3

lb_algo rr

lb_kind DR

protocol TCP

sorry_server 127.0.0.1 80

real_server 172.16.0.11 80 {

weight 1

HTTP_GET {

url {

path /

status_code 200

}

connect_timeout 1

nb_get_retry 3

delay_before_retry 1

}

}

 

real_server 172.16.0.12 80 {

weight 1

HTTP_GET {

url {

path /

status_code 200

}

connect_timeout 1

nb_get_retry 3

delay_before_retry 1

}

}

8、双主模型的lvs集群

双主模式的lvs集群，拓扑、实现过程；

配置示例（一个节点）：

! Configuration File for keepalived

global_defs {

notification_email {

root@localhost

}

notification_email_from kaadmin@localhost

smtp_server 127.0.0.1

smtp_connect_timeout 30

router_id node1

vrrp_mcast_group4 224.0.100.100

}

}

 

vrrp_instance VI_1 {

state MASTER

interface eth0

virtual_router_id 6

priority 100

advert_int 1

authentication {

auth_type PASS

auth_pass f1bf7fde

}

virtual_ipaddress {

172.16.0.80/16 dev eth0 label eth0:0

}

 

 

track_interface {

eth0

}

notify_master “/etc/keepalived/notify.sh master”

notify_backup “/etc/keepalived/notify.sh backup”

notify_fault “/etc/keepalived/notify.sh fault”

}

 

vrrp_instance VI_2 {

state BACKUP

interface eth0

virtual_router_id 8

priority 98

advert_int 1

authentication {

auth_type PASS

auth_pass f2bf7ade

}

 

virtual_ipaddress {

172.16.0.90/16 dev eth0 label eth0:1

}

track_interface {

eth0

}

notify_master “/etc/keepalived/notify.sh master”

notify_backup “/etc/keepalived/notify.sh backup”

notify_fault “/etc/keepalived/notify.sh fault”

}

 

virtual_server fwmark 3 {

delay_loop 2

lb_algo rr

lb_kind DR

nat_mask 255.255.0.0

protocol TCP

sorry_server 127.0.0.1 80

real_server 172.16.0.11 80 {

weight 1

HTTP_GET {

url {

path /

status_code 200

}

connect_timeout 2

nb_get_retry 3

delay_before_retry 3

}

}

 

real_server 172.16.0.12 80 {

weight 1

HTTP_GET {

url {

path /

status_code 200

}

connect_timeout 2

nb_get_retry 3

delay_before_retry 3

}

}

}

 

9、keepalived调用脚本进行资源监控

u keepalived调用外部的辅助脚本进行资源监控，并根据监控的结果状态能实现优先动态调整

u vrrp_script:自定义资源监控脚本，vrrp实例根据脚本返回值，公共定义，可被多个实例调用，

定义在vrrp实例之外

u track_script:调用vrrp_script定义的脚本去监控资源，定义在实例之内，调用事先定义的

vrrp_script

u 分两步：(1) 先定义一个脚本；(2) 调用此脚本

vrrp_script <SCRIPT_NAME> {

script “”

interval INT

weight -INT

}

track_script {

SCRIPT_NAME_1

SCRIPT_NAME_2

}

 

! 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

router_id node1

vrrp_mcast_group4 224.0.100.10

}

 

vrrp_script chk_down {

script “[[ -f /etc/keepalived/down ]] && exit 1 || exit 0”

interval 1

weight -20

}

vrrp_script chk_nginx {

script “killall -0 nginx && exit 0 || exit 1”

interval 1

weight -20

fall 2 #2次检测失败为失败

rise 1 #1次检测成功为成功

}

 

vrrp_instance VI_1 {

state MASTER

interface eth0

virtual_router_id 14

priority 100

advert_int 1

authentication {

auth_type PASS

auth_pass 571f97b2

}

virtual_ipaddress {

172.18.0.93/16 dev eth0

}

track_script {

chk_down

chk_nginx

}

notify_master “/etc/keepalived/

notify.sh master”notify_backup “/etc/keepalived/

notify.sh backup”notify_fault “/etc/keepalived/notify.sh fault

}

 

10、同步组

u LVS NAT模型VIP和DIP需要同步，需要同步组

u vrrp_sync_group VG_1 {

group {

VI_1 # name of vrrp_instance (below)

VI_2 # One for each moveable IP.

}

}

vrrp_instance VI_1 {

eth0

vip

}

vrrp_instance VI_2 {

eth1

dip

}

 

 

双主模型，解决高可用问题。

带有lvs的功能。

两个虚拟路由器，每个里面都有worker和master。

Keepalived支持ipvs：配置虚拟主机。

 

本文来自投稿，不代表Linux运维部落立场，如若转载，请注明出处：http://www.178linux.com/100807

赞 (0)
604603701@qq.com604603701@qq.com
0
上一篇 2018-06-10
下一篇 2018-06-10

相关推荐

电话咨询
在线咨询