用户名：zys467754239 文章数：71 评论数：17
访问量：8733：1340：836：4 注册日期：2012-04-18
nginx+keepalived构建主备负载均衡代理服务器 一、架构
二、唠叨一会原理：
1、nginx
Nginx进程基于于Master+Slave(worker)多进程模型，自身具有非常稳定的子进程管理功能。在Master进程分配模式下，Master进程永远不进行业务处理，只是进行任务分发，
从而达到Master进程的存活高可靠性，Slave(worker)进程所有的业务信号都 由主进程发出，Slave(worker)进程所有的超时任务都会被Master中止，属于非阻塞式任务模型。
2、keepalived
Keepalived是Linux下面实现VRRP 备份路由的高可靠性运行件。基于Keepalived设计的服务模式能够真正做到主服务器和备份服务器故障时IP瞬间无缝交接,作用:
主要用作RealServer的健康状态检查以及LoadBalance主机和BackUP主机之间failover的实现
3、单点故障
Nginx有很强代理功能，但是一台nginx就形成了单点，现在使用keepalived来解决这个问题，keepalived的故障转移时间很短.
Nginx+keepalived双机实现nginx反向代理服务的高可用,一台nginx挂掉之后不影响应用也不影响内网访问外网.
4、此架构需要考虑的问题
1)Master没挂，则Master占有vip且nginx运行在Master上
2)Master挂了，则backup抢占vip且在backup上运行nginx服务
3)如果master服务器上的nginx服务挂了，则vip资源转移到backup服务器上
4)检测后端服务器的健康状态
5、叙述
Master和Backup两边都开启nginx服务，无论Master还是Backup，当其中的一个keepalived服务停止后，vip都会漂移到keepalived服务还在的节点上，
如果要想使nginx服务挂了，vip也漂移到另一个节点，则必须用脚本或者在配置文件里面用shell命令来控制。
首先必须明确后端服务器的健康状态检测keepalived在这种架构上是无法检测的，后端服务器的健康状态检测是有nginx来判断的，但是nginx的检测机制有一定的缺陷，后端服务器某一个宕机之后，nginx还是会分发请求给它，在一定的时间内后端服务响应不了，nginx则会发给另外一个服务器，然后当客户的请求来了，nginx会一段时间内不会把请求分发给已经宕机的服务器，但是过一段时间后，nginx还是会把分发请求发给宕机的服务器上。
三、准备工作
系统版本：CentOS6.464bit nginx版本：nginx-1.4.7.tar.gz keepalived版本：keepalived-1.2.7.tar.gz nginx+keepalived主192.168.0.189master nginx+keepalived辅192.168.0.200badkup vip 192.168.0.250vip |
四、安装nginx和keepalived服务
1、安装nginx服务[分别在master机器和backup机器安装nginx服务]
#time2014-08-18 yum-yinstallgccgcc-c++makeunzipwgetvimopenssh-clients #支持重写rewrite,正则表达式 unzippcre-8.33.zip ./configure--prefix=/usr/local/pcre make&&makeinstall tarxfzlib-1.2.8.tar.gz ./configure--prefix=/usr/local/zlib make&&makeinstall tarxfopenssl-1.0.0l.tar.gz cdopenssl-1.0.0l ./config--prefix=/usr/local/openssl make&&makeinstall tarxfnginx_mod_h264_streaming-2.2.7_update.tar.gz #创建运行nginx服务的账号和组 groupadd-rnginx useradd-gnginx-r-s/sbin/nologinnginx tarxfnginx-1.4.7.tar.gz --group=nginx\ --prefix=/usr/local/nginx\ --with-pcre=../pcre-8.33\ --with-zlib=../zlib-1.2.8\ --with-openssl=../openssl-1.0.0l\ --with-http_stub_status_module\ --pid-path=/var/run/nginx/nginx.pid\ --lock-path=/var/lock/nginx.lock\ --with-http_gzip_static_module\ --http-proxy-temp-path=/var/tmp/nginx/proxy/\ --http-fastcgi-temp-path=/var/tmp/nginx/fcgi/\ --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi\ --http-scgi-temp-path=/var/tmp/nginx/scgi\ RAID? 阅读原文» 传统RAID的性能瓶颈点在哪里? 众所周知，传统RAID在数据重构方面表现极差，当一块盘发生故障之后，需要几十个小时才能将故障盘中的数据恢复。特别在数据重构的过程中，上层文件系统的性能也会受到极大的影响。并且在应用数据压力的情况下，数据重构的IO和应用的IO交错在一起，导致恶性循环，使得数据重构和应用IO性能都表现极差。 大容量磁盘对传统RAID的最大挑战就在于此。两年前或者更早，存储界的很多公司开始寻找下一代磁盘RAID的技术，其中最有可能和新意的就是DDP（Dynamic Disk Pool），国内的华为将这种技术称之为RAID2.0。DDP最大的特征在于将RAID构建在一系列随意的CHUNK之上，而不是将若干个磁盘做成RAID。这些CHUNK是磁盘中的资源块，可以是1GB或者更大的容量。在DDP中普遍会存在Storage Pool的概念，这个概念会将这些CHUNK资源块组织起来，池化。在这个池中通过一定的算法获取一些资源块CHUNK，然后在这些CHUNK的基础上组建RAID。目前，应该有很多的存储公司都在研发这种新型的RAID。咋看一眼，这种技术好像很简单，其实在现象的表面隐藏了很多的技术问题，并且不是很容易解决的。 本文不想过多的讨论DDP的技术细节，最主要想讨论一下为什么采用DDP就能解决传统磁盘RAID的问题，到底磁盘RAID的性能瓶颈点在哪里？ 为了分析得出这个问题的答案，先来看一下磁盘RAID数据重构的过程。 通过上图我们可以看到，当一块磁盘发生故障以后，处于同一个Disk Group中的其他盘将会存在大量的读操作，去获取条带数据，然后生成故障盘上的数据，最后写入Spare盘。这是一个完整的数据重构过程。所有的读发生在故障盘所处的Disk Group中，写操作只存在Spare上。因此，我们很容易的发现两个性能瓶颈点：
由于上述两大性能瓶颈点的存在，传统RAID的数据重构带宽理论上限只能达到130MB/s。要想突破这个理论上限值，只能破除这两个性能瓶颈点。 DDP就能破除这两个性能瓶颈点。为什么呢？因为DDP是基于CHUNK来做RAID的，CHUNK又是从一个Storage Pool中获取的。因此，RAID中的CHUNK在磁盘上的布局不再像传统RAID的Disk Group那样非常的规整。也就是说，DDP可以达到：
通过上述两点，DDP完全破除了传统RAID的两大性能瓶颈点，从而可以使得数据重构的性能大幅度提升。下图就是采用DDP技术之后，每块磁盘上的读写IO分布。 从上图可以看出，在数据重构的过程中，每块磁盘上同时存在读和写操作，而不像传统RAID那样，只有若干块盘存在读操作，一块盘存在写操作。并且由于读写混合之后，磁盘会存在抖动，因此，从单盘的角度来看，无论是读还是写操作性能都大大降低了。但是，从总体来看，由于参与数据重构的磁盘数量增加了，因此，总体的数据重构性能增强了。从这句话里我们也可以理解出来，DDP技术的应用是有局限的，当磁盘数量不是很多的情况下，DDP技术无法发挥性能优势，发而会导致性能下降。当前，SSD技术正在悄然兴起，并且其没有读写混合的性能问题，因此， DDP技术在SSD上面就显得非常合适了。 引入DDP技术之后最大的好处是可以提升RAID的数据重构性能，并且可以做到随者系统中磁盘数量的增加，数据重构性能可以线性扩展。而传统的RAID是没有办法做到这一点的。 在Flash存储如火如荼开展的今天，磁盘存储依然会存在。在未来，很多人估计其存在的最大理由就是在于容量（价格），因此可以通过组建混合存储的方式架构存储系统。在大容量磁盘存储中，我们有理由相信DDP技术会大发光彩，推动着传统RAID技术继续前进。 本文出自 "存储之道" 博客，请务必保留此出处http://alanwu.blog.51cto.com/3652632/1541408 
订阅：
博文评论 (Atom)
|
没有评论:
发表评论