Keepalive+Nginx高可用配置(主从)

Keepalive+Nginx可用配置主从

Keepalived可用集群 一、Keepalived介绍 Keepalived软件主要通过VRRP协议实现可用功能的。VRRP是Virtual Router Redundancy Protocol(虚拟路由器冗余协议)的缩写,VRRP出现的目的就是为了解决静态路由单点故障问题,它能够保证当个别节点宕机时,整个网络可以不间断地运行。keepalived除了能够管理LVS软件外,还可以作为其他服务(Nginx,Haproxy、MySQL等)的可用解决方案软件。 二、keepalived软件的三个主要功能 1、管理LVS负载均衡软件 早起的LVS软件,需要通过命令行或脚本实现管理,并且没有针对LVS节点的健康检查功能。为了解决LVS的这些不方便的问题,keepalived诞生了。因此keepalived跟LVS的感情很深,关系如夫妻一样,可以紧密的结合。keepalived可以通过读取自身的配置文件,实现通过更底层的接口直接管理LVS的配置以及控制服务的启动、停止等功能,这使得LVS的应用更加简单方便。 2、实现对LVS集群节点的健康检查功能 Keepalived可以通过在自身的keepalived.conf文件里配置LVS的节点IP和相关参数实现对LVS的直接管理;除此之外,当LVS集群中的某一个甚至几个节点服务器同时发生故障无法提供服务时,keepalived服务会自动将失效的节点服务器从LVS的正常转发队列清楚出去,并将请求调度到别的正常节点服务器上,保证最终用户的访问不受影响,故障修复以后,keepalived服务又会自动把它们加入到正常转发队列中。 3、作为系统网络服务的可用功能(failover) keepalived可以实现任意两台主机之间,例如Master和Backup主机之间的故障转移和自动切换,这个主机可以是普通的不能停机的业务服务器,也可以是LVS负载均衡、Nginx反向代理这样的服务器。 原理就是:两台主机同时安好keepalived软件并启动服务,开始正常工作时,由角色为Master的主机获得所有资源并对用户提供服务,角色为Backup的主机作为Master主机的热备;当角色为Master的主机失效或出现故障时,角色为Backup的主机将自动接管Master主机的所有工作,包括接管VIP资源及相应资源服务;而当角色为Master的主机故障修复后,又会自动接管回它原理处理的工作,角色为Backup的主机则同时释放Master主机失效时它接管的工作,还原为最初启动各自的角色。 三、keepalived可用故障切换转移原理 在Keppalived服务正常工作时,主Master节点会不断地向备节点发送(多播的方式)心跳消息,用以告诉备Backup节点自己还活着,当主Master节点发生故障时,就无法发送心跳消息,备节点也就因此无法继续检测到来自主Master节点的心跳了,于是调用自身的接管程序,接管主Master节点的IP资源及服务。而当主Master节点恢复时,备Backup节点又会释放主节点故障时自身接管的IP资源及服务,恢复到原来的备用角色。 VRRP,全称Virtual Router Redundancy Protocol,虚拟路由冗余协议,VRRP的出现就是为了解决静态路由的单点故障问题,VRRP是通过一种 竞选机制 来将路由任务交给某台VRRP路由器的。 在一组虚拟路由器中,只有作为Master的VRRP路由器会一直发送VRRP广播包(VRRP Advertisement messages),此时Backup不会抢占Master。当Master不可用时,Backup就收不到来自Master的广播包了,此时多台Backup中优先级最高的路由器会抢占为Master。这种抢占非常快速的,以保证服务的连续性,处于安全性考虑,VRRP数据包使用了加密协议进行加密。 总结就是下面四句话: (1)VRRP,全程,Virtual Router Redundancy Protocol,中文名为虚拟路由冗余协议,VRRP的出现是为了解决静态路由的单点故障。 (2)VRRP是通过一种竞选协议机制来将路由任务交给某台VRRP路由器的 (3)VRRP是IP多播的方式,实现可用对之间的通信。 (4)工作时主节点发包,备节点接包,当备节点接受不到主节点发的数据包的时候,就启动接管程序接管主节点的资源。备节点可以有多个,通过优先级竞选,但一般Keepalived系统运维工作中都是一对。 (5)VRRP使用了加密协议加密数据,但keepalived官方目前还是推荐用明文的方式配置认证类型和密码 四、Keepalived可用
2017-01-01 05:22   [nginx]

Keepalive可用Nginx服务测试

环境 系统版本:CentOS 7.2 节点1地址:10.1.8.81 节点2地址:10.1.8.83 虚拟IP地址:10.1.8.248 安装软件 yum -y install nginx yum -y install keepalived 配置nginx服务 1.1、提供测试页面: mkdir -pv /web/www 修改主页面路径为/web/www,创建测试页面 1.2、启动服务 [root@node1 ~]# systemctl start nginx.service [root@node2 ~]# systemctl start nginx.service 节点1: 节点2: 配置keepalive服务 2.1、编辑主配置文件:/etc/keepalived/keepalived.conf 节点1: 节点2: 2.2、启动服务: [root@node1 ~]# systemctl start keepalived.service [root@node2 ~]# systemctl start keepalived.service 2.3测试: 查看主节点IP地址: 此时访问web服务: 在节点1的/etc/keepalived/下创建一个名为down的文件(此前配置的资源控制脚本,创建此文件即会将节点1的权重减5,虚拟IP将会被转移至节点2),此时查看节点2的IP地址。 再访问web服务: 删除掉节点1的down文件,再测试:
2017-02-16 19:32   [nginx]

nginx+keepalive实现可用热备负载均衡

一、负载均衡是什么(摘自百度百科)         负载均衡 建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。         负载均衡,英文名称为Load Balance,其意思就是分摊到多个操作单元上进行执行,例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等,从而共同完成工作任务。 二、常用的负载均衡     1、HTTP重定向         HTTP 重定向可以将 HTTP 请求进行转移,在 Web 开发中我们经常会用它来完成自动跳转,比如用户登录成功后跳转到相应的管理页面。 这种重定向完全由HTTP 定义,并且由HTTP 代理和Web 服务器共同实现。很简单,当HTTP 代理(比如浏览器)向Web服务器请求某个URL后,Web 服务器可以通过HTTP 响应头信息中的Location 标记来返回一个新的URL,这意味着HTTP代理需要继续请求这个新的URL ,这便完成了自动跳转。当然,如果你自己写了一个 HTTP 代理,也可以不支持重定向,也就是对于Web 服务器返回的Location 标记视而不见,虽然这可能不符合HTTP 标准,但这完全取决于你的应用需要。 也正是因为HTTP 重定向具备了请求转移和自动跳转的本领,所以除了满足应用程序需要的各种自动跳转之外,它还可以用于实现负载均衡,以达到Web 扩展的目的。     2、DNS负载均衡         DNS负责提供域名解析服务,当我们访问某个站点时,实际上首先需要通过该站点域名的DNS服务器来获取域名指向的IP 地址,在这一过程中,DNS服务器完成了域名到IP 地址的映射,同样,这种映射也可以是一对多的,这时候,DNS 服务器便充当了负载均衡调度器(也称均衡器),它就像前面提到的重定向转移策略一样,将用户的请求分散到多台服务器上,但是它的实现机制完全不同。     3、反向代理负载均衡          反向代理服务器的核心工作便是转发 HTTP 请求,因此它工作在 HTTP 层面,也就是 TCP 七层结构中的应用层(第七层),所以基于反向代理的负载均衡也称为七层负载均衡,实现它并不困难,目前几乎所有主流的 Web 服务器都热衷于支持基于反向代理的负载均衡。     4、IP负载均衡          事实上,在数据链路层(第二层)、网络层(第三层)以及传输层(四层)都可以实现不同机制的负载均衡,但有所不同的是,这些负载均衡调度器的工作必须由Linux 内核来完成,因为我们希望网络数据包在从内核缓冲区进入进程用户地址空间之前,尽早地被转发到其他实际服务器上,没错,Linux 内核当然可以办得到,位于内核的Netfilter和IPVS可以解决问题,而用户空间的应用程序对此却束手无策。 另一方面,也正是因为可以将调度器工作在应用层以下,这些负载均衡系统可以支持更多的网络服务协议,比如FTP 、SMTP 、DNS ,以及流媒体和VoIP 等应用。 三、规划和准备         两台相同配置的web 用途 IP MASTER 192.168.1.100 BACKUP 192.168.1.101 四、安装         两台接入服务器分别安装nginX和keepalived         准备依赖包         yum -y install gcc pcre-devel zlib-devel openssl-devel popt-devel         下载         wget http://nginx.org/download/nginx-1.8.1.tar.gz        
2016-03-23 18:22   [nginx]

构建可用服务器之三 Keepalive冗余Nginx

实验目的: 使用Keepalive来保证Nginx可用,进而实现网站的可用! 实验拓扑: 实验环境: 如上拓扑图所示,master与slave是mysql主从,且有discuz论坛,且已经做可用。(可参加《构建可用服务器之三Keepalive冗余Mysql》)。现在是刚搭建两台
2015-05-22 01:42   [nginx]

keepalived入门之keepalive+nginx实例部署

在实际环境中,keepalive常常与lvs,nginx,haproxy,Mysql等等应用组成可用计算集群服务,比如web前端应用等等场景,接下来一起来讲讲关于keepalive+lvs实例部署   Keepalive+Lvs(lvs/dr模式)实例部署 如图所示为整体的拓扑图
2016-03-11 02:29   [nginx]

负载均衡_集群方案_keepalive+nginx

引言 Nginx是一个高性能的代理服务器,单台Nginx容易出现单点故障,使用keepalived可以实现Nginx的故障转移,保证了网站的可用性 一、 使用Nginx+keepalived的两种方案 1、主从模式 使用一个VIP,前端有2台服务器,一主一从,正常情况下是主服务器
2016-06-21 20:31   [nginx]

如何配置Nginx可用

操作系统: Linux 服务器: tomcat7 nginx版本:1.6.0         nginx是一个高性能的http和反向代理服务器,因其稳定性、丰富的功能性、以及低能耗被广泛采用。本文将示范在fedora16上配置安装nginx,并且整合tomcat做服务器负载均衡配置Nginx 安装 从官网下载Nginx包  http://nginx.org/en/download.html 在终端su进入root用户(必须以root权限安装,因为安装路径为/usr/local,普通权限无法对该位置的文件进行写操作)。 1.tar -zxvf nginx-1.6.0.tar.gz 2.cd nginx-1.6.0 3../configure--with-http_stub_status_module --with-http_ssl_module--prefix=/usr/local/nginx   这行命令执行后,可能会提示 ./configure: error: the HTTP rewritemodule requires the PCRE library.这个错误,是缺少pcre 包,可用yum install pcrepcre-devlel来解决 4.make && make install 安装成功的话,安装目录为 /usr/local/nginx        测试是否安装成功,在终端中执行usr/local/nginx/sbin/nginx, 然后在浏览器中输入localhost,若出现 welcome to nginx 则表示安装成功。        若要关闭Nginx,则在终端中 ps aux | grep nginx  ,然后kill 掉相关进程即可。或者输入 usr/local/nginx/sbin/nginx -s stop来停止,该命令 -s 表示将signal 发送到nginx主进程中。 Nginx配置         Nginx配置主要是修改 /usr/local/nginx/conf/nginx,conf文件 #配置用户和用户组 user www www; #工作进程数,建议设置为CPU的总核数 worker_processes  2; #全局错误日志定义类型,日志等级从低到依次为: debug | info | notice | warn | error | crit error_log  logs/error.log  info; #记录主进程ID的文件 pid        /usr/local/nginx/nginx.pid; #一个进程能打开的文件描述符最大值,理论上该值因该是最多能打开的文件数除以进程数。但是由于nginx负载并不是完全均衡的, #所以这个值最好等于最多能打开的文件数。执行 sysctl -a | grep fs.file 可以看到linux文件描述符。 worker_rlimit_nofile 65535; #工作模式与连接数上限 events {     #工作模式,linux2.6版本以上用epoll     use epoll;     #单个进程允许的最大连接数     worker_connections  65535;} #设定http服务器,利用它的反向代理功能提供负载均衡支持 http {     #文件扩展名与文件类型映射表     include       mime.types;     #默认文件类型     default_type  application/octet-stream;     #日志格式     log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '                                   '$status $body_bytes_sent "$http_referer" '                                   '"$http_user_agent" "$http_x_forwarded_for"';     #access log 记录了哪些用户,哪些页面以及用户浏览器、ip和其他的访问信息     access_log  logs/access.log  main;     #服务器名字的hash表大小     server_names_hash_bucket_size 128;     #客户端请求头缓冲大小。nginx默认会用client_header_buffer_size这个buffer来读取header值,    #如果header过大,它会使用large_client_header_buffers来读取。     #如果设置过小HTTP头/Cookie过大 会报400 错误 nginx 400 bad request    #如果超过buffer,就会报HTTP 414错误(URI Too Long)    #nginx接受最长的HTTP头部大小必须比其中一个buffer大,否则就会报400的HTTP错误(Bad Request)。     client_header_buffer_size 32k;     large_client_header_buffers 4 32k;     #客户端请求体的大小     client_body_buffer_size    8m;     #隐藏ngnix版本号     server_tokens off;     #忽略不合法的请求头     ignore_invalid_headers   on;     #指定启用除第一条error_page指令以外其他的error_page。     recursive_error_pages    on;     #让 nginx 在处理自己内部重定向时不默认使用  server_name 设置中的第一个域名     server_name_in_redirect off;     #开启文件传输,一般应用都应设置为on;若是有下载的应用,则可以设置成off来平衡网络I/O和磁盘的I/O来降低系统负载     sendfile                 on;     #告诉nginx在一个数据包里发送所有头文件,而不一个接一个的发送。     tcp_nopush     on;     #告诉nginx不要缓存数据,而是一段一段的发送--当需要及时发送数据时,就应该给应用设置这个属性,     #这样发送一小块数据信息时就不能立即得到返回值。     tcp_nodelay    on;     #长连接超时时间,单位是秒     keepalive_timeout  65;     #gzip模块设置,使用 gzip 压缩可以降低网站带宽消耗,同时提升访问速度。     gzip  on;             #开启gzip     gzip_min_length  1k;          #最小压缩大小     gzip_buffers     4 16k;        #压缩缓冲区     gzip_http_version 1.0;       #压缩版本     gzip_comp_level 2;            #压缩等级     gzip_types       text/plain application/x-javascript text/css application/xml;           #压缩类型     #upstream作负载均衡,在此配置需要轮询的服务器地址和端口号,max_fails为允许请求失败的次数,默认为1.     #weight为轮询权重,根据不同的权重分配可以用来平衡服务器的访问率。     upstream hostname {         server 192.168.2.149:8080 max_fails=0 weight=1;         server 192.168.1.9:8080 max_fails=0 weight=1;     }     #主机配置     server {         #监听端口         listen       80;         #域名         server_name  hostname;        #字符集        charset utf-8;        #单独的access_log文件        access_log  logs/192.168.2.149.access.log  main;        #反向代理配置,将所有请求为http://hostname的请求全部转发到upstream中定义的目标服务器中。        location / {             #此处配置的域名必须与upstream的域名一致,才能转发。             proxy_pass     http://hostname;             proxy_set_header   X-Real-IP $remote_addr;         }         #启用nginx status 监听页面         location /nginxstatus {             stub_status on;             access_log on;         }         #错误页面         error_page   500 502 503 504  /50x.html;         location = /50x.html {             root   html;        }     } }         至此,nginx基本的负载均衡配置完成,实验中部署2台tomcat, 然后访问时返回不同的结果,在浏览器中输入地址,确实能看到不同的返回结果。nginx配置文件的内容还有待于继续学习。  4、Tomcat配置    对于tomcat大家都很熟悉,只需要修改server.xml配置文件即可,这里我们以apache-tomcat-6.0.14为例,分别在server目录,解压缩并命名为:apache-tomcat-6.0.14_1、apache-tomcat-6.0.14_2。     第一处端口修改: Xml代码   <!--  修改port端口:18006 俩个tomcat不能重复,端口随意,别太小-->   <Server port="18006" shutdown="SHUTDOWN">       第二处端口修改: Xml代码   <!-- port="18081" tomcat监听端口,随意设置,别太小 --> 
2016-02-25 11:01   [nginx]

keepalived+nginx可用配置

;ln -s keepalived-1.2.15 keepalived 3.配置keepalive:     [root@localhost keepalived]# cat /etc/keepalived/keepalived.conf   
2015-05-29 04:14   [nginx]

nginx HA可用

公司内部 代理服务器nginx 系统要做线上高可用,避免单点故障,所以计划使用2台nginx代理 通过 Keepalived 工具来实现 nginx可用(High Avaiability),达到一台nginx入口服务器宕机,另一台备机自动接管服务的效果。(nginx做反向代理,实现后端
2016-07-30 13:12   [nginx]

heartbeat实现Nginx可用

corosync+pacemaker成了可用集群中的最佳组合。 本文首先介绍HA套件中的heartbeat,为nginx实现可用 环境: vm3     172.16.1.203 vm4     172.16.1.204 VIP
2015-08-04 15:34   [nginx]

Keepalived+Nginx+Tomcat可用主从切换)以及灾难恢复

/2013-09/89732.htm Keepalived+HAProxy配置可用负载均衡 http://www.linuxidc.com/Linux/2012-03/56748.htm CentOS 6.3下Haproxy+Keepalived+Apache配置笔记 http
2016-12-19 17:13   [Tomcat]

Redis可用架构(1)-Keepalive+VIP

最近整理一下Redis可用架构的文档,也准备分享出来,虽然这些架构也不是很复杂。Redis的可用方案目前主要尝试过5种方式,其中2种方式已经在线上使用。 1)Redis Master-Slave + Keepalive + VIP。 这是很经典的db架构,也可以用与mysql的主从切换
2016-04-13 13:49   [Redis]

  1  2  3  4  5 下一页>