Chinaunix首页 | 论坛 | 博客
  • 博客访问: 391741
  • 博文数量: 63
  • 博客积分: 3142
  • 博客等级: 中校
  • 技术积分: 838
  • 用 户 组: 普通用户
  • 注册时间: 2007-12-06 13:35
文章分类

全部博文(63)

文章存档

2011年(2)

2010年(114)

2009年(3)

我的朋友

分类: 系统运维

2010-02-09 12:51:28

高可用负载均衡最佳实践三: 设计

  2009年11月02日 18:06  
[] [] [] [] [] [] [] []

【内容导航】
  • 第1页:系统总体架构
  • 第2页:部件/工具选择
关键词 文本Tag: 服务器集群 操作系统 linux 负载均衡 服务器操作系统 高可用

  【IT168 专稿】 (接前文1,2)高可用、可扩展、负载均衡方案包括硬件和软件两个主要的方面.硬件有服务器、交换机、远程管理设备;软件包括操作系统、负载均衡软件、web应用软件(这里是apache和php)、数据库软件mysql、监控软件Nagios 等。

  一、系统总体架构

  高可用、可扩展、负载均衡的总体架构分为负载均衡层、应用层、数据库层及共享文件系统三层。其中数据库和共享文件可看成同一个层次,图1展示了这个层次逻辑。
 

高可用负载均衡最佳实践三:设计

  (一) 总体架构中各层的作用

  ◆负载均衡层:

  负载均衡层负责负载转发或失败切换,一般情况下由2个服务器组成一组,一个充当主服务器,另一个充当备用服务器。用户的请求首先达到负载均衡层,然后负载均衡设备根据指定的算法把负载转发到第二层的某个应用服务器,应用服务器响应这个请求并进行相应的处理(如进行数据库连接、读写文件等操作),然后把数据返直接返还给用户(这是DR模式),或者先返还给负载均衡器,封包后再返还用户(这是NAT模式)。

  使用主备方式的负载均衡环境,当主设备发生故障或失效时,备份负载均衡器会自动接管它的工作-即失败切换(Failover)功能。

  与一般应用层负载均衡(如apache负载均衡)不同的是,内核层的负载均衡具备对后面真实应用服务器进行健康检查/存活检查的功能,一旦真实应用服务器的某个主机实效,负载均衡器能自动地把故障隔离;而当这个故障得也恢复时,则再把它再加入先前的转发队列。

  ◆ web应用层:

  web应用层由两个或2个以上的物理服务器组成,运行诸如apache+php之类的应用,本方案的具体应用是apache+php。在这些物理服务器上,运行相同的应用,但物理服务器的配置可以不相同;为求得一致的性能,可以使用硬件配置完全相同的服务器。

  Web应用层一个比较困难的问题是数据同步。假定有3个web应用服务器,现在需要修改某些php程序,可以选择的操作方式有:

  1、 登录每个服务器,逐个进行修改,或者用scp复制到其他服务器。

  2、 修改其中的一个服务器的文件,使用rsync这样的工具进行同步。

  3、 共享文件系统,如NFS、分布式文件系统等。

  方法1和2是把应用所需的文件/数据在每个服务器上各自保存一份,当其中的任何一个服务器的数据发生变化,则需要以某种方式把变化同步到其他服务器。方法3是所有服务器共享同一份数据,因此不存在数据同步的问题。在笔者的某个工作场景中,曾有过用方法2同步各服务器数据的经历,这种方式耗费系统/网络资源,特别是需要的同步数据巨大无比时,系统性能下降更是明显。同时,怎样选择同步间歇,也难以权衡---同步间歇短了,前一次同步还未完成,后一个同步又开始了,如此堆积,占用大量的系统资源;同步间歇长了,用户的访问结果会不一致(如bbs发帖子,却很长时间显示不出来,因为其他用户访问的可能是另外没有同步过数据的服务器)。对于web应用类型的集群服务,最合适的方式就是共享文件系统这样的方式。即保证了数据的一致性,又有较好的速度和性能。为保证数据的可靠性和性能,本案采用分布式文件系统moosefs 作为web应用的共享存储。

  ◆ 数据库层:

  在互连网领域,mysql无疑是使用得最多的数据库平台,估计其在数据库市场的占用率超过40%。Mysql先被SUN system 收购,SUN 又被 ORACLE收购,让人眼花缭乱,以至于不少人对开源数据库的未来发展担忧。但这些,并不妨碍mysql的易用性和受欢迎的程度。

  为了保证mysql的高可用性,mysql有2种方法来实现:主从复制和mysql cluster(中文翻译成"簇")。在实际应用中,很少听说有人使用mysql cluster,因为这个配置过程过于复杂,而且还有很多地方不完善。对于一般的应用场景,使用mysql主从复制(一主一从或一主多从)就能满足要求。如果负载再大一些的应用,可以再增加读写分离的机制,提高性能和可靠性。本方案初始设计使用一主一从的方式,同时使用脚本,在夜间用户访问少的时候,对整个数据库进行完全备份。

  数据库数据的存储,即可以放在本地硬盘,也可以使用分布式共享存储系统。使用分布式共享存储系统,能大大提高其性能和速度。分布式共享系统将在下面介绍。

  ◆ 分布式文件系统

  在以前的项目里,笔者曾经用单个服务器以nfs的方式共享存储给应用层的服务器,当用户数量少于一定规模的时候,似乎也能很好的工作。为了保证数据的安全性,增加一台服务器用rsync对这个nfs的共享数据进行同步备份。图2说明了其结构特征。
 

高可用负载均衡最佳实践三:设计

  这种架构除了性能问题而外,还存在单点故障,一旦这个NFS服务器发生故障,所有靠共享提供数据的应用就不再可用,尽管用rsync方式同步数据到另外一个服务器上做NFS服务的备份,但这对提高整个系统的性能毫无帮助。基于这样一种需求,我们需要对NFS服务器进行优化或采取别的解决方案,然而优化并不能对应对日益增多的客户端的性能要求,因此唯一的选择只能是采取别的解决方案了;通过调研,分布式文件系统是一个比较合适的选择。采用分布式文件系统后,服务器之间的数据访问不再是一对多的关系(1个NFS服务器,多个NFS客户端),而是多对多的关系,这样一来,单个磁盘的i/o降低,从而使得整个存储系统的性能大幅提升。

  到目前为止,有数十种以上的分布式文件系统解决方案可供选择,如lustre,hadoop,Pnfs等等。我尝试了PVFS,hadoop,moosefs这三种应用,参看了lustre、KFS等诸多技术实施方法,最后选择了moosefs(以下简称MFS)这种分布式文件系统来作为共享存储服务器。为什么要选它呢?

  1、 实施起来简单。MFS的安装、部署、配置相对于其他几种工具来说,要简单和容易得多。

  2、 不停服务扩容。MFS框架做好后,随时增加服务器扩充容量;扩充和减少容量皆不会影响现有的服务。注:hadoop也实现了这个功能。

  3、 恢复服务容易。除了MFS本身具备高可用特性外,手动恢复服务也是非常快捷的,原因参照第1条。

  4、 我在实验过程中得到作者的帮助,这让我很是感激。

  MFS特性(根据官方网站翻译)

  ★ 高可靠性(数据能被分成几个副本存储在不同的计算机里)

  ★ 通过增加计算机或增加新的硬盘动态扩充可用磁盘空间

  ★ 可以设置删除文件的空间回收时间

  [root@mysql-bk serydir]# mfsgettrashtime bind-9.4.0.tar.gz

  bind-9.4.0.tar.gz: 600

  文件被删除10分钟后(600秒),才真正删除文件,回收磁盘空间。

  ★ 为文件创建快照

  MFS文件系统的组成

  1、 元数据服务器。在整个体系中负责管理管理文件系统,目前MFS只支持一个元数据服务器master,这是一个单点故障,需要一个性能稳定的服务器来充当。希望今后MFS能支持多个master服务器,进一步提高系统的可靠性。

  2、 数据存储服务器chunkserver。真正存储用户数据的服务器。存储文件时,首先把文件分成块,然后这些块在数据服务器chunkserver之间复制(复制份数可以手工指定,建议设置副本数为3)。数据服务器可以是多个,并且数量越多,可使用的"磁盘空间"越大,可靠性也越高。

  3、 客户端。使用MFS文件系统来存储和访问的主机称为MFS的客户端,成功挂接MFS文件系统以后,就可以像以前使用NFS一样共享这个虚拟性的存储了。

  图3展示了moossfs文件系统的基本结构:
 

高可用负载均衡最佳实践三:设计

  (二) 网络划分

  根据业务特点,以及需要应对用户数急剧增加的要求,需要对这个系统进行网络划分。本系统需要划分出两个网段,一个公网网段和一个内部/私有网段。

  公网网段(全球唯一ip地址)提供给负载均衡器和应用服务器使用。为了提供最高的访问转发性能,负载均衡采用直接路由的模式(DR),因此真实提供服务的应用服务器也得使用与负载均衡器相同网段的公网ip地址。图4是直接路由模式的访问路径。
 

高可用负载均衡最佳实践三:设计

  从这个图示我们可以得知,用户发出请求后先经过负载均衡器,再被转发到真实的应用服务器,数据返还时,直接给用户了,而不必经过负载均衡器,这极大地增强了网络的吞吐能力。

  内部网络主要是在应用服务器、数据库、共享存储之间进行通讯使用。使用192.168这样的私有地址,即保证了系统的安全,又减少了它对其他部分的影响。

  应用服务器同时属于这个两个网段,因此它需要者少有两个网卡用于网络连接。

  (三)系统架构评价

  高考中国网高可用、可扩展、负载均衡设计方案,基本解决了单点故障(数据库和分布式文件系统的元数据服务器还是存在单点故障);可扩展能力得以大大提高-应用服务器可以按需扩展、分布式文件系统可以按需扩展、数据库从服务器可以按需扩展-这种扩展可以线形的增强性能和速度;负载均衡方面,负载均衡器具备内核级的负载均衡功能、分布式文件系统也具备数据存储和访问的负载均衡功能、mysql数据库在实现读写分离后,也可实现良好的负载均衡能力。

  因此,从局部到整体,都具备了高可用、可扩展、负载均衡的能力,这些措施,强有力的保证了系统的持续服务,同时也具备了非常灵活的伸缩特性。

内容导航

  二、 部件/工具选择

  部件/工具选择主要在硬件和软件这个两个方面,根据前文的设计,也按3层模式来说明各层的部件选择。

  (一)负载均衡层的部件选择

  ◆硬件

  本层需要服务器2台,并且不需要太高的配置即可胜任,使用市场上入门级的服务器即可满足要求,为了减少托管机柜的占用,使用1u尺寸的机架式服务器是最佳的选择。表1是某个生产环境负载均衡器的硬件配置。
 

高可用负载均衡最佳实践三:设计

  这个服务器是在市场上组装的,当然,如果预算资金充足,可以自行购买品牌机。由于负载均衡的主要任务是转发,系统运行时负载非常的小,所以也可以使用配置更低一点的服务器或者使用其他淘汰下来的机器。

  ◆软件

  软件包括2个部分:操作系统和应用程序。在本方案中,完全选择开源且免费的软件方案。

  操作系统方面,使用centos和FreeBSD。由于lvs已经包含在linux发行版的内核中,因此在负载均衡器中使用centos5.2作为操作系统,比选择freebsd要有优势(也可以选择freebsd,不过配置起来要复杂一些)。

  应用程序方面,负载均衡器使用lvs及keepalived来实现负载均衡,同时实现负载均衡器本身的失败切换(failover)--主负载均衡器失效备份负载均衡器自动接管转发、主负载均衡器恢复后负载自动被主负载均衡器接管。也有另外的方案可供选择,如lvs+heatbeat。不过这与keepalived的方案相比较,配置操作更复杂。Keepalived安装成功以后,仅仅需要使用一个配置文件,就实现了我们所要的全部功能;而用heartbeat 则需要撰写资源文件、撰写运行脚本等等。

  通过下列站点取得负载均衡所需的软件资源:

  1、 操作系统 centos 5.2。

  2、 Lvs内核ipvsadm-1.24。

  3、 负载均衡失败切换框架工具 keepalived-1.1.17.

  (二) 应用层部件选择

  应用层主要是运行web服务,它由apache整合php来完成。为了使用分布式共享文件系统,需要额外的软件来实现文件系统的挂接。要使apache发挥更好的性能,需要使用apache的worker模式(默认是prefork)。在worker模式下,通过查看进程数,可以发现开启的进程数远远少于默认的prefork模式。Worker模式需要4G以上的内存支持才能发挥较好的作用。

  ◆硬件

  与负载均衡层所需的服务器硬件相比,所需的硬件要求差别不是太大。因此我们可以采用与负载均衡层相同的配置,增加内存到8G。从成本看,增加4G内存大概就是增加几百元的成本而已。前文描述过,应用层至少需要2个以上的服务器,建议初始配置使用3个服务器,以后根据业务需求再逐步扩充服务器的数量。反之也可以根据用户数量的降低减少服务器数量。表2是某个生产环境的服务器硬件配置。
 

高可用负载均衡最佳实践三:设计

  ◆软件

  基于使用开源软件的宗旨,本层的操作系统可使用Centos或FreeBSD,甚至是其他GNU/linux或者solaris。应用程序包括了web应用apache和php;共享文件系统的挂接需要Fuse(系统默认安装)及挂接程序,本方案采用moosefs文件系统。

  通过下列站点取得负载均衡所需的软件资源:

  1、 操作系统 centos 5.2。

  2、 web程序apache。

  3、 php程序。

  4、 分布式文件挂接工具moosefs.

  (三) 分布式文件系统及数据库层部件的选择

  本层包含数据库和分布式文件系统。对于数据库来说,需要更快的处理能力,即频率更高的cpu和更大的内存;而对于分布式文件系统,则需要大容量的硬盘,以便可以存储更多的数据。

  ◆硬件

  A、数据库硬件

  主从复制最少要2个服务器,本方案初始设计使用2个服务器,一主一从。以后可以根据业务增长实现扩充,形成一主多从、速写分离的方式。这样既保证了数据安全,又能大幅提高负载。数据库服务器仍然使用1u机架式服务器,安装4核双cpu,16G内存,300G sas硬盘2个(做成raid 10)。数据库文件即可使用本地硬盘存储,也可以使用分布式文件系统。

  B、分布式文件系统硬件

  分布式文件系统由2个部分组成:元数据服务器master和数据存储服务器chunkserver。其中元数据服务器需要的配置要求不高,按负载均衡器那个标准配置就可以;数据存储服务器则尽可能地增加硬盘数量也获得最大的容量。初始配置时,使用一个元数据服务器,3个数据存储服务器。数据存储服务器采用2u机架式服务器,安装6个1T sata硬盘,做成RAID 5,再用一个单独的sata安装硬盘来安装操作系统,这样可以获得4.5T的可用磁盘空间来共享。3个服务器可提供总容量大概为13T存储空间。以后再随业务增长增加数据存储服务器。

  ◆软件

  A、数据库

  包括操作系统和数据库两个部分。操作系统可以是centos或freebsd。

  数据库可从 获得。

  B、分布式文件系统

  分布式文件可以运行在各种类unix平台,因此可以根据自己的喜好选择开源和免费的操作系统。元数据库服务器、数据存储服务器及分布式文件客户端(即第2层的应用服务器)都使用同一个软件moosefs,它们之间的差别在于安装过程配置过程使用哪些选项。

  从 可以取得分布式文件系统所需的软件moosefs.

  (四)网络设备选择

  出于安全和速度考虑,我们把网络分成内外两个网段,这两个网段在物理上分离开,即使用两个交换机.在我们这个方案里,暂时没有考虑交换机的高可用性,因此对交换机本身的质量要求比较高.具体的配置是:外网交换机使用100M 的cisco交换机,型号为ws-c3560-48TS;内网使用华为千兆交换机,型号是H3C S5100-SI。为简化管理,减少后期维护成本,交换机只设置了snmp community 用于服务器的流量监控和统计(每个有流量的端口对应一个服务器,就没有必要再在每个服务器上配置和启用snmp服务)。一个需要注意的地方是,应用服务器同时连接这两个网络,为了安全,请勿在任何双网络的服务器设置NAT。

  服务器的托管一般是在远离办公室的专用的机房,在通常情况下,如果出现不能登录服务器等故障,需要亲自跑到机房去处理,这很费时、费钱。为了解决这个问题,需要购买一个KVM over ip的网络设备,初始投资大概在5000元,安装配置好KVM之后,基本上就不用去机房现场操作。

  下篇文章中,介绍监控系统的设计,敬请关注。

  

阅读(1172) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~