centos nginx 负载均衡 nginx负载均衡怎么配置

大家好,如果您还对centos nginx 负载均衡不太了解,没有关系,今天就由本站为大家分享centos nginx 负载均衡的知识,包括nginx负载均衡怎么配置的问题都会给大家分析到,还望可以解决大家的问题,下面我们就开始吧!

CentOS环境下Nginx实现3台虚拟机负载均衡

负载均衡

先来简单了解一下什么是负载均衡,单从字面上的意思来理解就可以解释N台服务器平均分担负载,不会因为某台服务器负载高宕机而某台服务器闲置的情况。那么负载均衡的前提就是要有多台服务器才能实现,也就是两台以上即可。

测试环境

在VMware里安装了三台。

A服务器IP:192.168.0.219(主)

B服务器IP:192.168.0.119

C服务器IP:192.168.0.109

部署思路

A服务器做为主服务器,域名直接解析到A服务器(192.168.0.219)上,由A服务器负载均衡到B服务器(192.168.0.119)与C服务器(192.168.0.109)上。

在A服务器上,upstream指令——分配负载

vi/etc/nginx/conf.d/default.conf

upstream 192.168.0.219{

server 192.168.0.119:80;

server 192.168.0.109:80;

}

server{

listen 80;

server_name 192.168.0.219;

charset utf8;

location/{

proxy_pass

proxy_set_header Host$host;

proxy_set_header X-Real-IP$remote_addr;

proxy_set_header X-Forwarded-For$proxy_add_x_forwarded_for;

}

}

保存重启nginx

在B、C服务器上,

vi/etc/nginx/conf.d/default.conf

server{

listen 80;

server_name 192.168.0.219;

index index.html;

root/usr/share/nginx/html;

}

保存重启nginx

测试

当访问的时候,为了区分是转向哪台服务器处理我分别在B、C服务器下写一个不同内容的index.html文件,以作区分。

打开浏览器访问a.com结果,刷新会发现所有的请求均分别被主服务器(192.168.5.149)分配到B服务器(192.168.0.119)与C服务器(192.168.0.109)上,实现了负载均衡效果。

主服务器不能提供服务吗?

以上例子中,我们都是应用到了主服务器负载均衡到其它服务器上,那么主服务器本身能不能也加在服务器列表中,这样就不会白白浪费拿一台服务器纯当做转发功能,而是也参与到提供服务中来。

怎么解决这个问题呢?因为80端口已经用来监听负载均衡的处理,那么本服务器上就不能再使用80端口来处理192.168.0.219的访问请求,得用一个新的。

于是我们在主服务器中编辑/etc/nginx/conf.d/default.conf,添加以下内容

server{

listen 8080;

server_name 192.168.0.219;

index index.html;

root/usr/share/nginx/html;

}

重启nginx

然后,再重新渡负载均衡。

更多Nginx相关教程见以下内容:

CentOS 6.2实战部署Nginx+MySQL+PHP

使用Nginx搭建WEB服务器

搭建基于Linux6.3+Nginx1.2+PHP5+MySQL5.5的Web服务器全过程

CentOS 6.3下Nginx性能调优

CentOS 6.3下配置Nginx加载ngx_pagespeed模块

CentOS 6.4安装配置Nginx+Pcre+php-fpm

Nginx安装配置使用详细笔记

Nginx日志过滤使用ngx_log_if不记录特定日志

求助关于centos6.6搭建nginx反向代理服务器

〉直接作为http server(代替apache,对PHP需要FastCGI处理器支持);

〉另外一个功能就是作为反向代理服务器实现负载均衡

以下我们就来举例说明如何使用 nginx实现负载均衡。因为nginx在处理并发方面的优势,现在这个应用非常常见。当然了Apache的 mod_proxy和mod_cache结合使用也可以实现对多台app server的反向代理和负载均衡,但是在并发处理方面apache还是没有 nginx擅长。

1)环境:

a.我们本地是Windows系统,然后使用VirutalBox安装一个虚拟的Linux系统。

在本地的Windows系统上分别安装nginx(侦听8080端口)和apache(侦听80端口)。在虚拟的Linux系统上安装apache(侦听80端口)。

这样我们相当于拥有了1台nginx在前端作为反向代理服务器;后面有2台apache作为应用程序服务器(可以看作是小型的server cluster。;-));

b. nginx用来作为反向代理服务器,放置到两台apache之前,作为用户访问的入口;

nginx仅仅处理静态页面,动态的页面(php请求)统统都交付给后台的两台apache来处理。

也就是说,可以把我们网站的静态页面或者文件放置到nginx的目录下;动态的页面和数据库访问都保留到后台的apache服务器上。

c.如下介绍两种方法实现server cluster的负载均衡。

我们假设前端nginx(为127.0.0.1:80)仅仅包含一个静态页面index.html;

后台的两个apache服务器(分别为localhost:80和158.37.70.143:80),一台根目录放置phpMyAdmin文件夹和test.php(里面测试代码为print“server1“;),另一台根目录仅仅放置一个test.php(里面测试代码为 print“server2“;)。

2)针对不同请求的负载均衡:

a.在最简单地构建反向代理的时候(nginx仅仅处理静态不处理动态内容,动态内容交给后台的apache server来处理),我们具体的设置为:在nginx.conf中修改:

复制代码代码如下:

location~\.php${

proxy_pass 158.37.70.143:80;

}

〉这样当客户端访问localhost:8080/index.html的时候,前端的nginx会自动进行响应;

〉当用户访问localhost:8080/test.php的时候(这个时候nginx目录下根本就没有该文件),但是通过上面的设置 location~\.php$(表示正则表达式匹配以.php结尾的文件,详情参看location是如何定义和匹配的 ),nginx服务器会自动pass给 158.37.70.143的apache服务器了。该服务器下的test.php就会被自动解析,然后将html的结果页面返回给nginx,然后 nginx进行显示(如果nginx使用memcached模块或者squid还可以支持缓存),输出结果为打印server2。

如上是最为简单的使用nginx做为反向代理服务器的例子;

b.我们现在对如上例子进行扩展,使其支持如上的两台服务器。

我们设置nginx.conf的server模块部分,将对应部分修改为:

复制代码代码如下:

location ^~/phpMyAdmin/{

proxy_pass 127.0.0.1:80;

}

location~\.php${

proxy_pass 158.37.70.143:80;

}

上面第一个部分location ^~/phpMyAdmin/,表示不使用正则表达式匹配(^~),而是直接匹配,也就是如果客户端访问的 URL是以开头的话(本地的nginx目录下根本没有phpMyAdmin目录),nginx会自动pass到127.0.0.1:80的Apache服务器,该服务器对phpMyAdmin目录下的页面进行解析,然后将结果发送给nginx,后者显示;

如果客户端访问URL是的话,则会被pass到158.37.70.143:80的apache进行处理。

因此综上,我们实现了针对不同请求的负载均衡。

〉如果用户访问静态页面index.html,最前端的nginx直接进行响应;

〉如果用户访问test.php页面的话,158.37.70.143:80的Apache进行响应;

〉如果用户访问目录phpMyAdmin下的页面的话,127.0.0.1:80的Apache进行响应;

3)访问同一页面的负载均衡:

即用户访问这个同一页面的时候,我们实现两台服务器的负载均衡(实际情况中,这两个服务器上的数据要求同步一致,这里我们分别定义了打印server1和server2是为了进行辨认区别)。

a.现在我们的情况是在windows下nginx是localhost侦听8080端口;

两台apache,一台是127.0.0.1:80(包含test.php页面但是打印server1),另一台是虚拟机的158.37.70.143:80(包含test.php页面但是打印server2)。

b.因此重新配置nginx.conf为:

〉首先在nginx的配置文件nginx.conf的http模块中添加,服务器集群server cluster(我们这里是两台)的定义:

复制代码代码如下:

upstream myCluster{

server 127.0.0.1:80;

server 158.37.70.143:80;

}

表示这个server cluster包含2台服务器

〉然后在server模块中定义,负载均衡:

复制代码代码如下:

location~\.php${

proxy_pass 这里的名字和上面的cluster的名字相同

proxy_redirect off;

proxy_set_header Host$host;

proxy_set_header X-Real-IP$remote_addr;

proxy_set_header X-Forwarded-For$proxy_add_x_forwarded_for;

}

这样的话,如果访问页面的话,nginx目录下根本没有该文件,但是它会自动将其pass到myCluster定义的服务区机群中,分别由127.0.0.1:80;或者158.37.70.143:80;来做处理。

上面在定义upstream的时候每个server之后没有定义权重,表示两者均衡;如果希望某个更多响应的话例如:

复制代码代码如下:

upstream myCluster{

server 127.0.0.1:80 weight=5;

server 158.37.70.143:80;

}

这样表示5/6的几率访问第一个server,1/6访问第二个。另外还可以定义max_fails和fail_timeout等参数。

综上,我们使用nginx的反向代理服务器reverse proxy server的功能,将其布置到多台apache server的前端。

nginx仅仅用来处理静态页面响应和动态请求的代理pass,后台的apache server作为app server来对前台pass过来的动态页面进行处理并返回给nginx。

通过以上的架构,我们可以实现nginx和多台apache构成的机群cluster的负载均衡。

两种均衡:

1)可以在nginx中定义访问不同的内容,代理到不同的后台server;如上例子中的访问phpMyAdmin目录代理到第一台server上;访问test.php代理到第二台server上;

2)可以在nginx中定义访问同一页面,均衡(当然如果服务器性能不同可以定义权重来均衡)地代理到不同的后台server上。如上的例子访问test.php页面,会均衡地代理到server1或者server2上。

实际应用中,server1和server2上分别保留相同的app程序和数据,需要考虑两者的数据同步。

如何安装nginx负载均衡配置详解

负载均衡

先来简单了解一下什么是负载均衡,单从字面上的意思来理解就可以解释N台服务器平均分担负载,不会因为某台服务器负载高宕机而某台服务器闲置的情况。那么负载均衡的前提就是要有多台服务器才能实现,也就是两台以上即可。

测试环境

由于没有服务器,所以本次测试直接host指定域名,然后在VMware里安装了三台CentOS。

测试域名:a.com

A服务器IP:192.168.5.149(主)

B服务器IP:192.168.5.27

C服务器IP:192.168.5.126

部署思路

A服务器做为主服务器,域名直接解析到A服务器(192.168.5.149)上,由A服务器负载均衡到B服务器(192.168.5.27)与C服务器(192.168.5.126)上。

域名解析

由于不是真实环境,域名就随便使用一个a.com用作测试,所以a.com的解析只能在hosts文件设置。

打开:C:WindowsSystem32driversetchosts

在末尾添加

192.168.5.149 a.com

保存退出,然后启动命令模式ping下看看是否已设置成功

从截图上看已成功将a.com解析到192.168.5.149IP

A服务器nginx.conf设置

打开nginx.conf,文件位置在nginx安装目录的conf目录下。

在http段加入以下代码

upstream a.com{

server 192.168.5.126:80;

server 192.168.5.27:80;

}

server{

listen 80;

server_name a.com;

location/{

proxy_pass ;

proxy_set_header Host$host;

proxy_set_header X-Real-IP$remote_addr;

proxy_set_header X-Forwarded-For$proxy_add_x_forwarded_for;

}

}

保存重启nginx

B、C服务器nginx.conf设置

打开nginx.confi,在http段加入以下代码

server{

listen 80;

server_name a.com;

index index.html;

root/data0/htdocs/www;

}

保存重启nginx

测试

当访问a.com的时候,为了区分是转向哪台服务器处理我分别在B、C服务器下写一个不同内容的index.html文件,以作区分。

打开浏览器访问a.com结果,刷新会发现所有的请求均分别被主服务器(192.168.5.149)分配到B服务器(192.168.5.27)与C服务器(192.168.5.126)上,实现了负载均衡效果。

B服务器处理页面

C服务器处理页面

假如其中一台服务器宕机会怎样?

当某台服务器宕机了,是否会影响访问呢?

我们先来看看实例,根据以上例子,假设C服务器192.168.5.126这台机子宕机了(由于无法模拟宕机,所以我就把C服务器关机)然后再来访问看看。

访问结果:

我们发现,虽然C服务器(192.168.5.126)宕机了,但不影响网站访问。这样,就不会担心在负载均衡模式下因为某台机子宕机而拖累整个站点了。

如果b.com也要设置负载均衡怎么办?

很简单,跟a.com设置一样。如下:

假设b.com的主服务器IP是192.168.5.149,负载均衡到192.168.5.150和192.168.5.151机器上

现将域名b.com解析到192.168.5.149IP上。

在主服务器(192.168.5.149)的nginx.conf加入以下代码:

upstream b.com{

server 192.168.5.150:80;

server 192.168.5.151:80;

}

server{

listen 80;

server_name b.com;

location/{

proxy_pass ;

proxy_set_header Host$host;

proxy_set_header X-Real-IP$remote_addr;

proxy_set_header X-Forwarded-For$proxy_add_x_forwarded_for;

}

}

保存重启nginx

在192.168.5.150与192.168.5.151机器上设置nginx,打开nginx.conf在末尾添加以下代码:

server{

listen 80;

server_name b.com;

index index.html;

root/data0/htdocs/www;

}

保存重启nginx

完成以后步骤后即可实现b.com的负载均衡配置。

主服务器不能提供服务吗?

以上例子中,我们都是应用到了主服务器负载均衡到其它服务器上,那么主服务器本身能不能也加在服务器列表中,这样就不会白白浪费拿一台服务器纯当做转发功能,而是也参与到提供服务中来。

如以上案例三台服务器:

A服务器IP:192.168.5.149(主)

B服务器IP:192.168.5.27

C服务器IP:192.168.5.126

我们把域名解析到A服务器,然后由A服务器转发到B服务器与C服务器,那么A服务器只做一个转发功能,现在我们让A服务器也提供站点服务。

我们先来分析一下,如果添加主服务器到upstream中,那么可能会有以下两种情况发生:

1、主服务器转发到了其它IP上,其它IP服务器正常处理;

2、主服务器转发到了自己IP上,然后又进到主服务器分配IP那里,假如一直分配到本机,则会造成一个死循环。

怎么解决这个问题呢?因为80端口已经用来监听负载均衡的处理,那么本服务器上就不能再使用80端口来处理a.com的访问请求,得用一个新的。于是我们把主服务器的nginx.conf加入以下一段代码:

server{

listen 8080;

server_name a.com;

index index.html;

root/data0/htdocs/www;

}

重启nginx,在浏览器输入a.com:8080试试看能不能访问。结果可以正常访问

既然能正常访问,那么我们就可以把主服务器添加到upstream中,但是端口要改一下,如下代码:

upstream a.com{

server 192.168.5.126:80;

server 192.168.5.27:80;

server 127.0.0.1:8080;

}

由于这里可以添加主服务器IP192.168.5.149或者127.0.0.1均可以,都表示访问自己。

重启Nginx,然后再来访问a.com看看会不会分配到主服务器上。

阅读剩余
THE END