【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数据库在实现读写分离后，也可实现良好的负载均衡能力。

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