高负载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 80

server 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 {万一服务器挂了时,用邮件通知给谁

[email protected]

[email protected]

[email protected]

}

[email protected]

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   修改

时间: 2024-10-24 16:04:57

高负载web框架(五)的相关文章

大型高并发高负载web应用系统架构-数据库架构策略

转自CSDN 在WEB网站的规模从小到大不断扩展的过程中,数据库的访问压力也不断的增加,数据库的架构也需要动态扩展,在数据库的扩展过程基本上包含如下几步,每一个扩展都可以比上一步骤的部署方式的性能得到数量级的提升. 1.WEB应用和数据库部署在同一台服务器上 一般的小规模的网站采用这种方式,用户量.数据量.并发访问量都比较小,否则单台服务器无法承受,并且在遇到性能瓶颈的时候升级硬件所需要的费用非常高昂,在访问量增加的时候,应用程序和数据库都来抢占有限的系统资源,很快就又会遇到性能问题. 2.WE

高可用web框架

nginx nginx简介 Nginx是一个自由.开源.高性能及轻量级的HTTP服务器及反转代理服务器.Nginx以其高性能.稳定.功能丰富.配置简单及占用系统资源少而著称. Nginx 超越 Apache 的高性能和稳定性,使得国内使用 Nginx 作为 Web 服务器的网站也越来越多. 基础功能 反向代理加速,简单的负载均衡和容错: 优势 1.Nginx专为性能优化而开发,性能是其最重要的考量, 实现上非常注重效率 .有报告表明能支持高达 50,000 个并发连接数. 2.Nginx具有很高

大型高并发高负载web应用系统架构

在WEB网站的规模从小到大不断扩展的过程中,用户访问量和并发量不断增加. 构建大型的商业网站绝对不可能像构建普通的小型网站一样一蹴而就,需要从严格的软件工程管理的角度进行认真规划,有步骤有逻辑地进行开发. 对于大型网站来说,所采用的技术涉及面极其广泛,从硬件到软件.编程语言.数据库.Web服务器.防火墙等各个领域都有了很高的要求,已经不是原来简单的html静态网站所能比拟的. 那如何优化程序和网站进行部署呢? 以下是我的几点个人看法(个人用NHibernater + MySQL或MSSQL) 一

高负载web架构(一)

架构图 需求分析1.haproxy用来做多个web服务的前端反代,由于haproxy处于最前端而且是向外提供服务,如果出现宕机时那么整个服务都不可用,那么需要给haproxy做高可用,这里使用比较轻量级的keepalived作为haproxy的高可用:2.使用varnish作为整个服务的第二层,我们知道varnish的并发能力并不是很优秀,这里varnish既提供了缓存功能又提供了反向代理的功能,此处用2台varnish来做高可用,并且实现后端内容的动静分离,动态内容都分发node4.node5

高负载web架构(三)

d.在node4上安装apache+tomcat 安装jdk1.7.0_67 需要依赖JDK才能运行 jdk1.7.0_67和apache-tomcat-7.0.55.tar.gz存在兼容性问题   apache-tomcat-7.0.42.tar.gz #rpm -ivh jdk-7u67-linux-x64.rpm # tar xf apache-tomcat-7.0.55.tar.gz-C /usr/local/ 导出命令 # cat/etc/profile.d/java.sh expor

高负载web架构(四)

f.在node9上部署好zabbix 监控: 最关键的工具:传感器:收集数据,检测数据 过程: 数据采集 --> 数据存储 --> 数据展示 报警:采集到的数据超出阈值 常见的实现监控SNMP:Simple Network Management Protocol 简单网络管理协议 有两部分组成:监控端(NMS)和被监控端(agent) SNMP的工作模式: NMS主动向agent采集数据 agent主动向NMS报告数据 NMS请求agent修改配置 SNMP的组件:三部分组成 MIB:mana

高负载web架构(二)

b.在node6上安装nginx作为静态内容处理 编译安装nginx # tar xfnginx-1.6.1.tar.gz -C /usr/local/ 首先添加用户nginx,实现以之运行nginx服务进程: # groupadd -rnginx # useradd -r -gnginx nginx 安装一些依赖的包 # yum install -ygcc gcc-c++ pcre-devel openssl-devel 接着开始编译和安装: # ./configure--prefix=/us

HAproxy+Keepalived负载均衡-高可用web站

haproxy+keepalived负载均衡高可用web站   OS IP 子网掩码 路由网关 Centos6.6 HAproxy Keepalived Eth0:192.168.26.210 255.255.252.0 192.168.25.3 VIP:192.168.27.210 Centos6.6 HAporxy Keepalived Eth0:192.168.26.211 255.255.252.0 192.168.25.3 VIP:192.168.27.210 Centos6.6(WE

Python之路【第十五篇】:Web框架

Python之路[第十五篇]:Web框架 Web框架本质 众所周知,对于所有的Web应用,本质上其实就是一个socket服务端,用户的浏览器其实就是一个socket客户端. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 #!/usr/bin/env python #coding:utf-8   import socket   def handle_request(client):     buf = client.recv(10