高考中国网高可用、负载均衡、可扩展设计与实现

原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://sery.blog.51cto.com/10037/252992

 

作者：田逸（sery@163.com）

 

第一章 项目描述

 

高考中国主要包含“高考志愿通”志愿填报系统的研究开发、产品运营；高考中国网站（www.gaokaochina.com)的开发、维护与运营。

 

“高考志愿通”是经过数十位全国高考志愿填报指导专家、计算机网络专家、数学模型专家和数据统计专家历时多年精心打造。成为中国第一套高考志愿填报综合分析系统，信息最全最新的高考志愿填报综合分析系统，分析最科学、最精确的填报指导系统。

 

目前已经开发了服务全国高考考生的志愿填报辅助参考系统——《高考志愿通》网络版，光盘版和校园版。高考志愿通每年服务上百万考生，目前在全国20多个省市设立销售机构。

 

他全国独创的位次、线差、曲线填报方式，为考生们科学合理的填报志愿，提供了方法和依据，让所有家长和考生一看就能够清楚明白好用的系统。从03年推广至今，深受家长和考生们的好评。高达98%以上的志愿填报成功率，帮助考生实现上大学、上好大学好专业的梦想。

 

高考中国网站（www.gaokaochina.com)是以刊登高考最新动态、高考新闻、招生信息、各大院校最新信息、备考辅导、政策法规等高考相关内容为主。高考中国网站本着发布最新最全的高考信息为目标，为高考生打造一个专业的高考门户网站。

 

 

1.1 高考中国网现行的运行架构

高考中国网的基本架构是典型的LAMP架构,即系统采用linux,应用使用apache整合php,然后加上开源数据库mysql.经验证 明,这是一个比较高效而且节省成本的解决方案:除了硬件而外,每个组件都是免费的。当初，由于用户数量少，就把所有的组件都安装在一个服务器硬件上面；其 主要目的是节省带宽费、托管费以及硬件购置费。图1-1是其基本结构逻辑。

图1-1 所有应用运行在一个服务主机上的逻辑图

随着公司商业推广的进行，访问该网站的用户数量急剧增加。加之高考即将临近，估计未来几个月内，用户数量可能成几何级的增长，这对于公司来说，应该是件好事。但是，随着用户的增长，现行的平台将无法支撑更大规模的访问服务。

由于是商业网站，保证其365*7*24可用是必须的了。以一个服务器运行所有程序，将可能面临如下几个问题：

◆ 故障：只要任何一个组件服务出故障，整个服务都会停止。

◆ 扩展：为提高性能或存储容量，可以增加内存等部件，但总有一个限度。

◆ 性能：用户越多，性能越差，速度越慢。

◆ 带宽：用户越多，消耗的带宽也就越大，但是单个服务器的带宽是固定的，理论值是1G，当带宽消耗带一定量时，即不能提供访问，也无法在增加带宽。

◆ 硬件冗余：服务器任何一个部件实效，整个网站的服务都不再可用。

把这些不利状况归纳起来，就是现行的网站不具备高可用、可扩展、负载均衡的特点。尽管当前网站运行状况还能应付，但对于上述几个方面的忧虑却令企业负责人寝食难安，他要求务必在高考来临之前解决这些问题。

 

1.2 功能需求

本系统为典型的互联网服务型网站,需要达到365*7*24可提供访问服务,用现在流行的专业术语描述,就是高可用、可扩展、负载均衡的架构；只有这样的架构，才有可能达到这个要求。

 

1.2.1 高可用

高可用是指在一段时间内（通常是一年），系统能正常提供服务的时间，它是以一个百分比来度量，如可用性99.99%。当然，没有任何人能保证系统可用性达到100%，但可以通过良好的设计，不断地接近100%。对外宣称小数点后能到达9的个数，是一个技术团队实力的体现。

 

1.2.2 可扩展

用户的增加，引起访问数乃至流量的增加，这种情形下，需要对系统进行扩容，以应对这种快速增长。对于提供高可用服务的互联网网站，其对可扩展的 基本要求就是在保持系统服务不终止的情况下，透明的扩充容量，即用户不知道扩容的存在，或者说是扩容不对现有的服务产生任何负面作用。这些扩展主要包括： 带宽扩展、服务器扩展、存储容量扩展、数据库扩展等，当然也包括主机增加内存等方面的扩展。只要能保证可以在线扩展，我们就可以认为系统具有很好的扩展 性。

 

1.2.3负载均衡

一个应用或服务由数个物理服务器提供,并且每个物理服务器运行的应用或服务是相同的,我们可以让用户的访问通过某种控制策略,把负载分摊到不同 的物理服务器,从而保持每个物理服务器有比较合理的负载。同时,负载均衡还具备故障隔离的功能,当某些物理服务器失效时，自动从负载转发队列剔除故障服务 器，一旦故障得以恢复，用户访问负载则自动加载上来。负载均衡一般是2层架构：转发器和真实提供服务或应用的服务器。除了真实服务器可以失效且不影响服务 外，转发器也能做到其中一个失效，另外一个自动失败切换，从来保持服务的可用性。

当整个系统的负载趋于饱和时，通过增加物理服务器和扩充物理带宽来扩容。增加物理服务器以后，系统的负载情况将重新在所有集群的物理服务器之间 按照指定的算法重新达到新的均衡。例如：现在有50000个并发连接，4个机器，按照wlc 等权值的负载策略，则每个物理服务器的大概连接数为1250；此时再增加一个服务器，负载策略不变，则稳定后的每个物理服务器连接数大概为1000。

 

1.2.4 平台状态可视化

尽管有前面描述的措施保证系统的高可用、可扩展及负载均衡，但我们还需要随时知道系统的运行状态，一旦有机器失效或者某个服务不可用，应当及时 发现并及时处理，而不要让故障一直积累，直到所有的服务都不可用以后，再来处理就谈不上什么高可用了。因此，监控平台的启用是不可或缺的了，有了它，就相 当于多了一双“眼睛”，随时随地，我们都可以知道整个平台是否正常运行。

监控平台可视化可以以以下几个方面予以表现：

◆ web方式，即通过浏览器观看被监控的对象；如正常状态下，其状态（status）是以绿色填充并显示一个OK。
◆邮件通知，发生故障时，到达设定重试次数和探测间隔时间后发送邮件给管理员或相关人员，报告问题的大致情况。
◆手机短信，这是非常有用和及时的功能。深夜时分，再也没可能看web页面或查阅邮件，可以一旦发生故障，手机短信却能随时通知管理员所发生的故障。
一般情况下，这3者是同时进行的：上班时间通过浏览器查看页面显示、打开邮件程序定时收取邮件、保持手机24小时在线。

第二章 方案选择

根据前文的需求描述,我们有几种可供选择的方案,这些方案主要包括: 主机部件扩容、应用分离以及高可靠、可扩展、负载均衡等几种方案，下面我们分别对这几种方案进行说明，然后再选择最终的方案。

 

2.1 主机部件扩容

仍然是一个单独的物理服务器，所有相关应用运行在它上面，为了获得更好的处理能力，可以通过增加处理器数量或更换频率更高的处理器、增加更大的硬盘、更换更大带宽的网络适配器（如几个千兆网卡绑定）、使用磁盘阵列等方式，达到一定限度的性能增加。

 

2.1.1 主机部件扩容的优点

主机部件扩容的主要优点包括：

1、 不改变系统的逻辑。增加部件后，开机就能运行原来的应用。

2、 节省空间。在物理服务器机箱内增建部件，不会再增加占用idc机房的机位。

3、 节省能源和线缆等。

4、 硬件维护简单。

5、 维护成本低。一个服务器，不必雇用专业的运维人员，人力资源成本极低。

 

2.1.2 主机部件扩容的缺点

单个物理服务器扩容，一般需要停机关闭电源后才能操作，这意味着在扩容的时候服务不可用。同时，由于总线速度/带宽等方面的限制，扩容到一定程 度后，性能的增长效果反而会下降。另外一个瓶颈就是不具备高可用和可扩展性性，随着用户的增加，访问的迅猛增加，故障率增加导致服务不可用的几率大大增 加。因此要靠部件扩容来应对用户增长，是不可能从根本上解决问题的。

 

2.1.3 主机部件扩容成本组成

主要的成本是购买服务器配件，如cpu、内存等。

 

2.2 应用分拆

应用分拆就是再购买一个服务器，把相关应用单独分布在独立的服务器上。例如把apache和php部署在一个物理服务器，mysql数据库单独部署在一个物理服务器。图2-1是其逻辑结构。

图2-1 应用拆分后的逻辑图

 

2.2.1 应用分拆的优点

应用分拆的主要优点包括：

1、 平台结构更加简洁。这对于排除故障很有帮助，同时对调试工作，也是很有利的。

2、 更高的系统性能。

3、 维护成本较低。只增加了一个服务器。

4、 故障概率降低。举例来说，原来所有的应用都在一个服务器上，系统运行过程可能产生较高的磁盘I/O;应用分拆后，单个服务器的磁盘I/O理所当然的降低，出故障的几率也就降低了。

5、 数据可靠性得以增强。当以单个服务器单个硬盘运行所有应用的时候，文件系统或硬盘发生故障，存储在磁盘上的数据可能全部丢失；而使用2个服务器分开来运行 web和数据库以后，数据全部丢失的可能性降低了—web服务器的硬盘坏了，不会引起数据库服务器数据的丢失；反之亦然。

 

2.2.2 应用分拆的缺点

应用分拆的主要缺点包括：

1、 成本增加。这些增加的成本有购买服务器的成本和增加托管机位的成本。

2、 增加能源耗费和线缆。

3、 维护复杂度增加。要维护2个服务器。

4、 存在单点故障，不能实现高可用，更不能应对未来不断增长的业务需求。

 

2.3 高可用、可扩展、负载均衡解决方案

 

高可用、可扩展、负载均衡的方案是在应用分拆的基础上，通过增加冗余物理服务器来避免单点故障。可扩展性表现在系统强大的容量伸缩能力，可以根 据用户数量，随时增加或减少资源（服务器或带宽），而不会对正常的服务产生影响。要保证365*7*24不间断服务，高可用、可扩展、负载均衡这几项往往 需要结合在一起，才能到达理想的效果。

 

2.3.1高可用、可扩展、负载均衡解决方案的优点

 

高可用、可扩展、负载均衡的方案的主要优点包括：

1、 高可用。降低了系统故障恢复时间，从而降低运营压力和由此带来的负面影响。试想一般的场景，当系统不可用时，来自用户或同事的催促会对系统运维人员产生巨大的压力，这种压力随停机时间的增加越发令人恐慌。

2、 高可靠性。由于冗余服务器的使用，最大限度地减少了单点故障，这就保证了业务的持续性和稳定性。

3、 可扩展性。通过增加物理服务器，极大地增强了运算能力和处理速度。

4、 负载均衡能力。不但增强了系统的总体吞吐能力，而且还具备故障隔离和失败切换的功能，这也是保证系统高可用的一个方面。

5、 降低长期维护成本。

6、 不能保证100%的高可用。

7、 可以应对不断增长的业务需求。

 

2.3.1高可用、可扩展、负载均衡解决方案的缺点

 

高可用、可扩展、负载均衡解决方案的缺点主要有：

1、 先期投入成本较高。需要购置更多的服务器、增加机位、雇用专职技术维护人员。

2、 实现技术复杂。

3、 需要更改应用程序逻辑或程序本身。

4、 需要更多的辅助资源，如监控系统、共享存储系统等。

 

2.4 方案选择

 

通过前面的对比，可以知道每种方案都有其优势和不足，但从业务本身特点和着眼于将来这些方面考虑，高可用、可扩展、负载均衡的方案应该是不二之 选。根据笔者以前实施的数个类似的实际应用，这个方案是经得起考验的、也是成熟的。据调查，目前有不少互联网网站也采用了这样的架构；同时也有一些机构开 始考虑采用笔者所发布的方案。

 

笔者已经实施的高可用、可扩展、负载均衡的网站有：某某心理网、某某技术在线、某某论坛、某某通行证、某某在线收藏等等。

 

 

第三章 高可用、可扩展、负载均衡方案设计

 

高可用、可扩展、负载均衡方案包括硬件和软件两个主要的方面.硬件有服务器、交换机、远程管理设备；软件包括操作系统、负载均衡软件、web应用软件（这里是apache和php）、数据库软件mysql、监控软件Nagios 等。

 

3.1 系统总体架构

 

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

图3-1 3层结构的高可用、可扩展、负载均衡结构

 

3.1.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的共享数据进行同步备份。图3-2说明了其结构特征。

图3-2 应用程序共享NFS文件系统

这种架构除了性能问题而外，还存在单点故障，一旦这个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-3展示了moossfs文件系统的基本结构：

图3-3 moosefs 文件系统体系结构（图片来源：http://www.moosefs.com/pages/mfs.html）

 

3.1.2 网络划分

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

 

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

图3-4 用户访问路径

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

 

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

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

 

3.1.3系统架构评价

 

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

 

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

 

3.2 部件/工具选择

 

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

 

3.2.1 负载均衡层的部件选择

 

◆硬件

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

表3-1 负载均衡服务器的配置及成本
名称	描 述	单价
CPU	Intel Xeon 5405 2.0G	￥1320
主板	Intel S5000VSA	￥1780
硬盘	希捷500G ST3500320NS	￥580
内存	南亚4G/667  FBD  NT8GTT72U4PB6UD-3C	￥740
机箱	联智1U机箱（型号：1365）	￥420
电源	台达500瓦电源	￥720
风扇	酷冷1U纯铜	￥150
合计（含税3%）		￥5900

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

◆软件

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

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

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

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

1、 操作系统 centos 5.2。 http://www.centos.org

2、 Lvs内核ipvsadm-1.24。 http://www.linuxvirtualserver.org

3、 负载均衡失败切换框架工具 keepalived-1.1.17. http://www.keepalived.org

 

3.2.2 应用层部件选择

 

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

◆硬件

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

表3-2一个组装服务器的配置及成本
名称	描 述	单价
CPU	Intel Xeon 5405 2.0G	￥1320
主板	Intel S5000VSA	￥1780
硬盘	希捷500G ST3500320NS	￥580
内存	南亚8G/667  FBD  NT8GTT72U4PB6UD-3C	￥1740
机箱	联智1U机箱（型号：1365）	￥420
电源	台达500瓦电源	￥720
风扇	酷冷1U纯铜	￥150
合计（含税3%）		￥6900

◆软件

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

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

1、 操作系统 centos 5.2。 http://www.centos.org

2、 web程序apache。 http://www.apache.org

3、 php程序。http://www.php.net

4、 分布式文件挂接工具moosefs. http://www.moosefs.org.

 

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

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

◆硬件

（一）数据库硬件

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

 

（二）分布式文件系统硬件

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

 

◆软件

（一）、数据库

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

数据库可从 http://www.mysql.org 获得。

 

（二）、分布式文件系统

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

从http://www.moosefs.org 可以取得分布式文件系统所需的软件moosefs.

 

3.2.4 网络设备选择

 

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

 

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

 

第4章 辅助功能—监控系统的设计

 

 

通过上述合理的方案设计,系统已经具备很高的可用性,即便有一些服务器实效或发生故障,也不会中断服务。但是，发生故障或失效的服务器，还是需 要处理和恢复服务的，不要等到所有服务都停了，才知道发生了故障。为了随时知道整个系统的运行状态，我们需要一双“眼睛”，时刻监控每个对象的运行情况， 如当某个服务器负载过高时，给系统管理员发送报警信息。一旦有了这样一个平台，就实现了所有服务的可视性。

 

4.1 监控平台选择

 

这里使用网络监控软件Nagios,个人认为它最大的好处是可以发故障报警短信—只要Nagios监控的对象发生故障，系统就会自动发送短信到手机上。下面摘录Nagios官方网站的描述：

Nagios is an open source host, service and network monitoring program. Who uses it? Lots of people, including many big companies and organizations：Nagios是一个用来监控主机、服务和网络的开放源码软件，很多大的公司或组织都在使用它。

Nagios 是开源的GNU源码包，可以安装在各种类unix平台，如centos、freebsd、solaris 等，并且在各个平台的安装方法基本上是相同的。

Nagios为了方便我们的管理工作，提供了至少3种表现手段：

1、web方式，即通过浏览器观看被监控的对象；如正常状态下，其状态（status）是以蓝色填充并显示一个OK。

2、邮件通知，发生故障时，到达设定重试次数和探测间隔时间后发送邮件给管理员或相关人员，报告问题的大致情况。

4、 手机短信，这是非常有用和及时的功能了；晚上熟睡中，再也没可能看web页面或查阅邮件，可以一旦发生故障，相关人员马上就能知道发生故障。

一般情况下，这3者是同时进行的：上班时间开个浏览器看页面显示、打开邮件程序定时收取邮件、手机24小时在线。

 

4.2 nagios的监控对象

 

监控应该具备效率和有效性，不要把所有的对象都放在监控里面，否则会发生类似“狼来了”这样的问题。

 

4.2.1 负载均衡层监控对象

 

负载均衡层主要监控包括存活检查及vip服务状态检查。

负载均衡器有2个服务器，首先需要知道的是这2个服务器是否存活。由于负载均衡器运行中既不耗费资源又不产生大的日志（日志直接输出屏幕了），为了保证其转发效率和性能，不必再在上面安装NRPE(nagios远程插件执行)。

 

用户的访问通常被指引到负载均衡设定的vip（在DR模式中，所有的服务器都用这个vip实现负载均衡功能），监控系统只需模拟用户访问vip的url页面，即可获知服务是否正常。

 

4.2.2 应用服务器层监控对象

 

应用服务器层需要监控的对象可归纳成2种：服务监控和资源监控。服务监控的目的是掌握服务的存活情况，资源监控是为了掌握系统的运行情况。在实际运行中，系统状态往往可以预测服务是否会出现问题，如较高的负载、较多的连接数、分区超过可用容量的80%等等。

 

应用层服务开启了2个基本的网络服务：sshd服务和web服务。前者用于远程连接，后者用于web服务。当我们配置了对sshd和web服务监控以后，默认状况下已经启用了服务器的存活检查，所以不必单独列出存活检查这个项目。

 

资源监控包括：负载监控、磁盘使用空间监控、进程数监控、ip连接数监控这4个项目。Nagios服务器本身不能像监控服务一样直接监控系统资 源，它需要在被监控的服务器上安装NRPE-nagios remote plug execute,由NRPE收集信息，然后返还信息给nagios服务器。

 

图4-1是一个nagios监控真实服务器的运行状况。

图4-1 nagios监控服务器和主机资源示意图

应用服务器以fuse方式挂接和访问moosefs分布式文件系统，在监控资源里，加入了磁盘使用的空间检查，假如分布式文件系统不可用，则也可以通过这个磁盘监控可以体现出来。

 

4.2.3 数据库层监控和分布式文件系统监控

数据库除了监控系统资源及服务端口外,需要额外创建一个空的数据库和一个权限极低的帐号,NRPE通过这个账号登陆mysql即可实现对 mysql数据库有效的监控.在数据库复制过程中,辅助服务器很有可能复制失败而停止数据同步,nagios用常规的插件无法检查同步失败,所以需要手动 写个脚本,然后根据脚本的输出来判别是否正常.在把脚本整合到NRPE.

 

分布式文件系统的监控分成两个部分:元数据服务器和数据存储服务器.除了监控系统资源外,还要监控这两者服务。元数据服务器和数据存储服务器分 别使用不同的端口进行监听，监控元数据服务器，用tcp 9420端口；监控数据存储服务器，用tcp 9422端口。再综合应用服务器层对磁盘空间利用的监控情况，我们就可以很准确的知道整个moosefs分布式文件系统的运行状况。

 

 

第5章 高可用、可扩展、负载均衡的总体架构技术实现

 

 

架构规划和设计好以后，就需要选择服务商，把设备放入idc机房，连接线缆，准备测试，无误后上线运行。

 

5.1 选择服务商及硬件上架

 

由于特殊的原因，中国的网络形成了划江而治的格局，这导致南北互联很大的问题，即网通和电信互访效果极差，要达到南北用户都能快速的访问网站， 得使用第三方的idc机房。第三方的idc机房有两种可选，一种是双线机房，另一种是BGP机房。这两种机房相比较，BGP效果最佳，但价格最贵，可根据 自己的资金预算和性能要求来权衡使用哪一类机房。另外在选定前先测试一下机房的网络状况，同时了解其电力供应，空调设施已经服务器堆放密度，最好观察一下 是否有知名的网站也放置在这里？

 

托管上选定以后，就要放置设备，接上电源、网线等线缆进行物理连接，为开机运行做好准备，如果有必要，则需要对交换机作一些设置。原则上是不需设置则不设置，保持简单化总是对的。

 

在本方案中，我们采用了短信报警的机制，监控服务器本身并不发送短信的能力，因此需要选择短信服务商，购买其服务，然后通过接口程序来实现发送报警短信的功能。

 

5.2 安装操作系统及部署相关软件

 

除了负载均衡器而外，其他两层的底层操作系统可以是任何一种类unix环境。理论上，负载均衡器也可以是其他类型的unix，如 freebsd，但这些系统都不能linux来得方便，因为lvs已经集成在各个linux的发行版里了，不需要额外的处理，就可以实现lvs的转发（主 要内核模块是ip_vs）。本方案以开源为宗旨，并且考虑以节省成本，因此所有服务器都安装和运行centos5。

 

5.2.1 负载均衡层的软件部署

 

负载均衡层要实现负载均衡、故障隔离、失败切换（负载均衡器之间failover）这3个功能，需要ipvsadm和keepalived这个 两个工具紧密配合来实现。Ipvsadm是lvs的核心，由它完成负载均衡和包转发，但它本身没有故障隔离和失败切换的机制。在其他人实施的一些项目里， 有采用heartbeat这样的工具来实现故障隔离和失败切换。但heartbeat太复杂了—要写ipvsadm脚本、要写资源文件、要安装 ldirectord等等。现在我们采用keepalived这个工具，只需要一个配置文件，即可轻松实现故障隔离、失败切换。

 

Lvs即可在安装系统是选择安装，也可在系统安装完成后下载ipvsadm源码进行安装。当按需求配置好 keepalived以后，运行keepalived 后，将能够查看到lvs的内核模块ip_vs已经被加载。

 

负载均衡器采用DR(直接路由)模式进行包转发，这种方式可获得最大的网络吞吐能力。在DR模式下，负载均衡器与后面的真实服务器（即本方案中应用服务器层）使用一个公用的ip地址，称为vip（virtual ip）。

 

5.2.2 应用层软件部署

 

应用层涉及的软件比较多，它主要包括apache、php、mysql 客户端、分布式文件系统客户端、lvs客户端等几个部分。看起来类别比较多，但只要配置好一个服务器以后，然后复制这个过程即可。这是因为负载均衡服务器之间存在配置一致性的特点。

 

安装步骤：

1、 安装apache,php,mysql客户端，并整合apache与php。

2、 安装分布式文件系统moosefs，接着挂接共享存储。

3、 编写lvs客户端脚本，并赋予执行权限。脚本的内容大致如下：

[root@tj-pp3 conf]# more /usr/local/bin/lvs_real

#!/bin/bash

#description : start realserver

VIP=61.135.22.101

/etc/rc.d/init.d/functions

case "$1" in

start)

echo " start LVS of REALServer"

/sbin/ifconfig lo:0 $VIP broadcast $VIP netmask 255.255.255.255 up

echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore

echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce

echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore

echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce

;;

stop)

/sbin/ifconfig lo:0 down

echo "close LVS Directorserver"

echo "0" >/proc/sys/net/ipv4/conf/lo/arp_ignore

echo "0" >/proc/sys/net/ipv4/conf/lo/arp_announce

echo "0" >/proc/sys/net/ipv4/conf/all/arp_ignore

echo "0" >/proc/sys/net/ipv4/conf/all/arp_announce

;;

*)

echo "Usage: $0 {start|stop}"

exit 1

esac

4、 安装和配置Nagios 远程执行插件（Nagios Remote Plug Execute）。

5、 复制程序开发人员编写的程序到apache设定的站点的根文档目录，检查apache语法，无误后启动apache。

6、 执行lvs客户端脚本，运行 ip add检查其正确性。

7、 启动NRPE,并测试其正确性。

8、 总体检查其正确性。

 

5.2.3 数据库及分布式文件系统部署

 

数据库分主从两个部分，主从数据库的安装方法是相同的，只要稍微改一下从服务器的选项文件，就能实现主从服务器之间的数据同步。为了更进一步保证数据安全性，可以写一个脚本，自动执行一个全数据备份。

 

分布式文件系统moosefs的原数据服务器和数据存储服务器的安装方法也是相同的，不同的地方在于启动命令和其关联的配置文件。存储服务器之间的配置（只软件及配置文件）是相同的，因此只要配置好其中的一个后，把这个配置文件复制到其它服务器相同的路径即可。

 

为了实现nagios的有效监控，需要在数据库系统和分布式文件系统安装和配置nrpe.

 

5.3 测试

 

测试过程包括功能测试和性能测试。

 

功能测试是逐个测试3层结构中各部分的功能是否正常，然后再模拟用户行为访问站点，看总体功能是否实现。例如，在浏览器中输入网站域名（通过dns把网站域名指向LVS的vip地址），然后注册用户，成功后用这个功能登陆，看一切是否正常。

 

性能测试就是进行一些破坏性测试或者模拟大量用户进行访问。在这里，最主要的是破坏性测试。在3层结构中，通过逐层逐个启停服务甚至服务器，看 用户访问是否正常。如停掉主负载均衡器，观察辅助负载均衡器能否自动接管转发服务；主负载均衡器恢复，转发能不能再回到原来的状态。

 

性能测试过程：

1、 负载均衡器启停测试，主要目的在于其失败切换failover功能。前文描述过，不再说明。

2、 应用服务器启停测试,主要目的在于其故障隔离功能。当停掉一个web服务时，用户访问是否正常，再停掉一个web服务，情况有怎样？

3、 分布式文件系统测试。停止其中的一个数据存储服务，观察从浏览器访问网站是否受影响。再停止一个数据存储服务器，情况又会如何？

4、 数据库测试。关闭从数据库，观察从浏览器访问网站是否受影响。再启动辅助服务器，看数据同步是否能再进行。

5、 做上述测试时，监控系统是否发送报警信息？

 

5.4 加固和平台运行

 

加固主要是在系统安全性方面考虑。目前出于商业利益方面的原因，ddos攻击相当的流行。要防范ddos攻击，单靠主机本身的防火墙如 iptables或传统的硬件防火墙，基本没效果。如果预算充足一点（其实前面的设计已经节省了大笔费用），买个防ddos流量攻击的硬件设备部署在网络 的前端，可以有效地抵挡大部分非法访问和攻击。

 

当一切准备就绪，就可以正式上线，通知用户可以使用本网站了。

 

第六章 方案实施后的效果

 

截至本文撰写之时，高考中国网www.gaokaochina.com 目前已经上线运行有半个多月，运行状况十分良好；目前的并发在线ip数只有几百个，等到高考结束，学生填报自愿时，流量就会急剧增加，到那个时候，再观察其运行状况，以决定其伸缩。

 

附录

主要参考资料

1. 开源监控利器nagios实战,田逸,http://net.it168.com/a2009/0309/267/000000267878.shtml
2.基于LVS的互联网应用架设攻略,田逸,http://server.it168.com/server/2007-12-11/200712110855723.shtml
3.Nagios远程监控软件的安装与配置详解,田逸,http://netsecurity.51cto.com/art/200706/48728.htm
4.分布式文件系统MFS(moosefs)实现存储共享,田逸,http://net.it168.com/a2009/0403/270/000000270867.shtml

总体拓扑图：

本文出自 “sery” 博客，请务必保留此出处http://sery.blog.51cto.com/10037/252992