RGAC高可用群集技术白皮书

RGAC高可用群集技术是一种提供高可用性、改善性能和增强应用软件可管理性的有效途径。随着IT运营管理的规范，系统安全和重要性的日益增加，集群技术必将会有着极为广阔的应用前景。

发布时间：2009-11-04
点击量：
点赞：

分享至

我想评论

发展趋势以及面临的挑战

随着计算机在社会各个领域的广泛使用，人们已习惯于计算机系统带来的便捷和高效率，但计算机系统也非常脆弱，它会受各种因素的影响，如硬件系统本身的故障，电源故障，病毒，自然灾害或人为的恶意破坏，都会导致系统无法正常运行。现有很多系统均是单主机工作环境，任何一个单点故障，都会影响IT运维业务的正常运转，而且产生很多不良后果。

在高校校园数字化校园管理中，核心的业务应用系统越来越多，这些系统都是关系到高校管理的核心业务，如：财务系统、办公系统、精品课程系统、安全管理认证系统等，尤其是安全管理认证系统，这个系统是管控所有上网用户的最基本的核心系统，是所有高质量网络服务的基础，高稳定和高性能历来是高校网络中心管理者的首要考虑的问题。
不能稳定运行和低性能的系统常导致

1. 用户满意度非常极差，从而影响用户的使用感受，极大的降低了用户对网络中心信任和依赖；

2. IT部门承受极大的压力，一方面要保证系统的稳定性，另一方面，系统一旦出现故障，必须在尽可能短的时间内让系统再次运行，但这往往又无法保证的；

3. 可能导致数据的不完整和不一致，甚至部分数据的丢失，尤其在大规模数据应用环境中尤为突出；

4. 当业务大量增加时，用户使用系统性能严重下降，但是用户不认为是由于业务大量拓展导致的，而是认为网络中心提供的服务质量不好造成的；
以上这些问题频繁如果出现，则会引起高校领导对网络中心服务的不信任，从而可能促使高校领导考虑网络中心业务外包，所以解决网络管理的稳定和扩展性已成为网络运维管理的重要任务。

2 技术背景

2.1 负载均衡

在计算机硬件价格下降和计算机网络拓扑发展的情况下。分布式计算机系统给用户提供了一个丰富的资源集合。人们在研究分布式系统时就注意到这样一个问题：在一个由网络连接起来的多计算机环境中，在某一时刻。一些计算机的负载过重。而另外一些计算机的负载较轻，平衡各计算机之间的负载是任务分配与调度的一个主要目标。它能够提高整个系统的性能。

为了改善系统的性能，通过在多台计算机之间合理地分配负载，使各台计算机的负载基本达到均衡，这种计算能力共享的形式通常被称为负载平衡或负载共享。

负载均衡建立在现有网络结构之上，它提供了一种廉价有效的方法扩展服务器带宽和增加吞吐量，加强网络数据处理能力，提高网络的灵活性和可用性。

现代负载均衡技术通常操作于网络的第四层或第七层。负载均衡器可以根据实际的响应时间制定优先级交付决策，从而实现高性能、智能化流量管理，达到最佳的服务器群性能。采用第七层应用控制还可以减少通信高峰期的错误信息，因为差错控制和流量管理技术可以侦测到一些错误信息并透明地将会话重定向到另一个服务器，使用户顺利地进行使用。

由于采用了负载均衡技术，自动故障恢复得以实现，服务的时间可以延长，24×7可靠性和持续运行成为可能。另外，负载均衡器一般也支持路径外返回模式，即绕过流量分配器，为那些焦急等待大量数据文件请求响应的客户提供更快的响应时间。

在最新的负载均衡产品中，智能化越来越明显。一些智能化的负载均衡器能够侦测到像数据库错误、服务器不可用等信息，从而采取措施使会话恢复和重定向服务器使电子商务能够得以顺利进行。多址负载均衡器可以对客户发来的访问请求进行解析，计算出最佳地址，然后将该地址返回客户，使客户自动连接到对其请求来说最佳的数据中心。

负载均衡，从结构上分为本地负载均衡和地域负载均衡(全局负载均衡)，前一种是指对本地的服务器集群做负载均衡，后一种是指对分别放置在不同的地理位置、在不同的网络及服务器群集之间作负载均衡。

2.2 群集服务

服务器群集是一组协同工作并运行群集服务的独立服务器。服务器群集为资源和应用程序提供高可用性、故障恢复、可伸缩性和可管理性。服务器群集允许客户端在出现故障和计划中的暂停时，依然能够访问应用程序和资源。如果群集中的某一台服务器由于故障或维护需要而无法使用，资源和应用程序将转移到可用的群集节点上。

群集服务可以对应用程序和资源进行监控，并能够自动识别和恢复众多故障状况。这为在群集中管理工作负荷提供了灵活性。另外，还提高了整个系统的可用性。

集群技术是一种通用的技术，其目的是为了解决单机运算能力的不足、IO能力的不足、提高服务的可靠性、获得规模可扩展能力，降低整体方案的运维成本（运行、升级、维护成本）。只要在其他技术不能达到以上的目的，或者虽然能够达到以上的目的，但是成本过高的情况下，就可以考虑采用集群技术。

采用群集技术可以获得以下优点：

高可用性：通过服务器群集，资源（例如：磁盘驱动器和Internet协议（IP）地址）的所有权会自动从故障服务器转移到可用的服务器。当群集中的某个系统或应用程序发生故障时，群集软件会在可用的服务器上重新启动故障应用程序，或者将工作从故障节点分散到剩下的节点上。由此，用户只在瞬间感觉到服务的暂停。

故障恢复：当故障服务器重新回到其预定的首选所有者的联机状态时，群集服务将自动在群集中重新分配工作负荷。该特性可配置，但默认禁用。避免了网络关键部位出现单点失效。

可管理性：您可以使用“群集管理器”工具（CluAdmin.exe），将群集作为一个单一的系统进行管理，并对犹如运行于一个单一服务器的应用程序实施管理。您可以将应用程序转移到群集中的其它服务器。“群集管理器”可用于手动平衡服务器的工作负荷，并针对计划维护释放服务器。您还可以监控群集的状态、所有节点以及来自网络任何地方的资源。

可伸缩性：群集服务可扩展以满足需求的增长。当群集监督应用程序的总体负荷超出了群集的能力范围时，可以添加附加的节点，解决网络拥塞问题，服务就近提供，实现地理位置无关性。

3 技术特性介绍

3.1 技术概述

高可用的群集技术不但可以有效地解决单服务器的性能限制，而且可以实现故障的快速转移，保证服务的高可用性以及灵活的扩展性。RGAC（即：RG Application Cluster——锐捷应用群集，下同）方案很好地应用了这一技术，由多台服务器以对称的方式组成一个服务器集合，每台服务器都具有等价的地位，都可以单独对外提供服务而无须其他服务器的辅助。通过某种负载均衡技术，将外部发送来的请求均匀分配到对称结构中的某一台服务器上，而接收到请求的服务器独立地回应客户的请求。这种技术可以用最少的投资获得接近于大型主机的性能。

同时，RGAC方案整合了数据库的事务复制功能，并针对SAM系统提供的服务，自主进行了研发，达到多台服务器之间的信息同步，在客户的眼里，SAM系统只有一个，但它所提供的服务，较之单台，更加快捷，也更加稳定！

3.1.1 NLB

Windows server系统（Windows 2000高级服务器版本、Windows server 2003所有版本）中提供了NLB（即：Network Load Balancing——网络负载均衡，下同）功能。
NLB技术包含两大特点：负载均衡和故障转移。

1. 负载均衡

NLB能将传入的请求传播到多达32台服务器上，即最多可以使用32台服务器构成一个集群，共同分担对外的网络请求服务。该技术保证即使是在负载很重的情况下，服务器也能做出快速响应。

网络负载均衡对外只需提供一个IP地址，即集群IP，客户端使用这个IP即可访问集群。所有的服务器上使用相同的规则，来决定并发的流量被分配到哪一台上进行处理，从而很大程度上提高了服务器的处理能力。

2. 故障转移

NLB第二个强大的特性是故障转移。集群内每台服务器靠定时发送心跳信息来估定其它服务器的状态。当有一台或几台服务器不可用时，服务不会中断，能够迅速在剩余的服务器中重新指派服务器接管过来，从而对用户是一直可用的，这个过程叫做“聚合”。这项特性能够保障服务被不间断地提供。

3.1.2 信息同步

RGAC方案提供了信息同步功能。

举个例子，系统中有两台设置了NLB的认证服务器A、B，各对应数据库C、D。一个用户发起添加500个用户的请求，这个请求被NLB分配到服务器A进行处理，数据库C的用户表中也随之增加这500个用户。但对于请求被分配到服务器B处理的用户来说，服务器B上并没有这新增的500个用户，那么，用户得到的信息就不一致了。不同的用户，不同的操作，得到的结果可能不同。

在RGAC方案中，通过SQL SERVER数据库事务复制和内存同步来解决信息同步的问题。在上面的例子中，数据库C在增加了用户信息后，会把这一变化同步到数据库D上，对于请求被分配到服务器B处理的用户来说，服务器B上也有新增用户的信息。这样所有的SAM服务器的信息就是同步一致的。

3.2 群集技术在SAM各业务模块的应用

3.2.1 报文交互过程

对于SAM来说，来自外部的请求有如下几大方面：

Radius相关认证，记账请求报文

Web管理端http请求/https请求

Web自助端http请求/https请求

和交换机之间的SNMP报文交互

和交换机之间的TRAP报文交互

和NTD之间的IPFIX报文交互

和第三方系统之间的JMS消息通信

发送EMAIL的pop3通信

这些报文交互涉及到的SAM功能非常广泛，各个模块都有功能涉及。

3.2.2 技术框架

系统（NTD，交换机，路由器等）和SAM之间的在NLB的前提下交互过程。

报文传输过程中，涉及到2种流量，HTTP和HTTPS的，NLB是基于IP包的源IP的负载均衡，正常情况下并不会出现什么问题，同一个源IP的HTTP或者HTTPS请求都是如上所述的交互方式。

如图3-2所示，在正常运行情况下，任何一个固定client都只会和NLB中某台服务器进行交互，并且在下次请求过程中仍然维持这种1对1的对应关系。对于单纯的http和https交互不会出现什么问题。

但需要考虑的是在出现单点故障时，会受到影响的参数主要考虑如下2点：Session、Cookies。

1. 由于Session产生的影响

假设SAM S2出现单点故障时，NLB自动把Client A的http请求发送给SAM S3，如果在SAM S2出现单点故障之前Client A已经在SAM S2上登陆（目前做法是把用户的信息保存到session中），则在下次http请求到SAM S3之后，会出现SAM S3让Client A重新登陆认证的情况，因为SAM S2的session信息并没有转移到SAM S3上。当SAM S2恢复后，如果NLB自动又把Client A的请求发给SAM S2，则需要看S2上面的session是否已经过期（时间过期或者系统重启导致被清空），如果过期则仍然需要进行重新登陆，而且起码在SAM S3中存入Session的相关信息也丢失了。

2. 由于Cookies产生的影响

而对于cookies（可能会用到），由于cookies是保存在Client A上面的，并不会因为服务器的改变而改变，所以cookies的应用是不会受到影响的。
综上，对于http/https来说，session不能同步是负载均衡带来的问题，解决方式有如下的一些：

不要向Session中存储用户的登陆信息，权限信息以及一些关键的信息，避免由于session不同步而导致重登陆或者信息丢失的问题；

把登陆信息，权限信息及其他一些信息存储到cookies里面或者存储到数据库里面，然后通过数据库同步达到信息同步的目的；

3.2.1 认证模块

对于认证模块，涉及到网络流量有如下一些类型：

Radius认证报文(UDP)

Ipfix的连接认证报文（TCP）

当平常负载均衡正常的情况下，由于数据同步的因素，所以相关设备的信息无论哪个服务器都是一致的，所以不存在什么问题。

由于IPFIX是计费模块的计费采集器，所以该部分放到计费模块去讲，这里主要讲Radius认证报文受到的影响。

Radius本身是基于UDP传输的，也就是每次一个报文，你来我往，并不像TCP那样需要建立一个通道，设备认证信息，用户信息等等都通过数据库同步达到数据同步，平常正常运行在负载均衡模式下不会出现任何问题，对外就是一台服务器。而当出现单点故障时，会有如下一些影响：

认证开始之前原定进行该认证报文处理的服务器出现故障，则由NLB自动调整到另外一台服务器上进行认证报文的处理。从认证开始到结束用户是不会有什么感觉的。

认证交互过程中处理该认证报文的服务器出现故障，则由NLB自动调整到另外一台服务器上进行从新开始的一次认证报文。对于1次交互的PAP，CHAP来说，那表现就是Radius服务器没响应，然后重发认证报文或者认证超时（这里需要看NLB什么时候侦测到单点故障以及调整的速度了）。对于多次交互的认证方式比如EAP，PEAP等将会给用户予认证失败的提示，然后需要重新进行认证，那么这里需要考虑如何做？

认证完成之后进行该认证报文处理的服务器出现故障时，对于认证报文来说是没有任何影响的，因为认证已经完成，相关权限已经下发。

综述，在认证过程中需要考虑在认证交互过程中出现单点故障时，认证的处理及回馈用户的信息，如果理论上该段时间可以忽略不计的话，那么该考虑也可以只做说明书说明即可。

3.2.2 计费模块

对于计费模块，必须考虑如下内容：

Radius记账报文采集器

Ipfix流量报文采集器

对于Radius记账报文采集器来说，它不像认证报文一样可以丢弃，所以必须用一个Radius记账临时表来存储记账开始报文信息或者记账更新报文信息。然后这些信息通过数据库同步方式来达到各NLB服务器数据同步的目的，进而使得在服务器未收到记账结束报文之前，仍然能够根据session id正常的处理记账结束和记账更新。并形成临时计费记录给计费处理模块进行计费处理。

对于出现单点故障时，由NLB切换该源IP（交换机）上的所有IP报文到另外一个服务器上去处理，那么此时已经发送出记账开始/更新报文的信息通过数据库同步在另外那个服务器上也存在，再次收到记账更新/结束报文时也能够正常进行处理。这样的情况下必须满足如下条件：

交换机/路由器必须具备Radius记账报文重发机制

记账临时表的数据库同步必须是实时的，最高优先级的

SAM当收到记账结束报文却找不到对应session id时，需要把报文放入延迟处理队列，避免因为数据库同步不及时而把重要的计费信息给丢弃了。

对于IPFIX流量报文采集器，在负载均衡中出现单点故障时，由于TCP连接和UDP连接方式不同，TCP连接必须建立TCP通道，然后再在通道中传输数据，如果其建立TCP通道的服务器出现单点故障时，相关协议处理模块必须达到如下要求：

NTD端必须具备TCP通道重连功能

NTD方面没有成功发出的流量需要保留并且做延迟重发处理
而由于IPFIX流量是通过报文－内存－数据库临时表－数据库记录表，这样的层次存储，所以一旦出现单点故障，则在内存中的流量数据将会丢失，单数据库临时表信息由于数据库同步的存在使得数据能够共享并继续完成流量的解析处理。基于此，内存中的流量信息保存时间最大值必须是可控范围的，需要设定一些策略来保障内存中信息及时更新到数据库临时表中。

3.3 技术应用

3.3.1 认证流量负载均衡

采用NLB技术，可以让多个服务器同时均衡的处理多点并发访问要求，在不增加每台服务器配置的情况下，成倍的提高网络服务的认证管理的性能。

同一高可用群集中的SAM分担处理认证请求，系统性能倍增。

RGAS可实现技术参数：

单机40用户/秒

双机80用户/秒

四机120用户/秒

3.3.2 业务实时热备份

安全管理认证系统的无故障运行是确保全网用户能够随时使用网络的关键要素，也是网络中心为全校提供高质量网络服务的一个重要保证。通过高可用群集技术的支撑，可达成单台服务不可能实现的全年无故障运行的性能指标。

3.3.3 跨校区帐号漫游

　　各大高校的园区规模不断扩大，高校的基础设施建设规模也随之持续完善，由此产生的在高校各园区之间透明的帐号漫游需求已经成为越来越多高校亟待解决的问题。RGAC解决方案通过提供在不同园区之间、不同接入方式的帐号漫游满足帐号漫游需求，这种漫游对用户是完全透明的。在所有部署了RGAC系统的地理区域，网络接入用户可以方便使用唯一的帐号接入网络，而且该帐号下的所有用户信息与其它园区保持一致。在后台，网络中心管理者在进行统一管理，帐号的统一管理极大的提高管理者的工作效率，减轻工作量。
　

3.3.4 数据备份

　由于RGAC具有数据库实时同步技术，可在各数据库服务器同步数据。当某一台数据库服务出现故障，其它同步的数据库服务器可实时的替代，不会影响数据的正常使用，而且在故障排除后，系统需要在可控的时间范围内自动同步缺失的数据到新的数据库服务器上，从而实现系统容灾的特性，确保数据库单点故障不影响全局系统的正常运行。

4 典型组网案例

4.1 拓扑方案

方案介绍

系统由2台SAM服务器组成一个RG-AC（锐捷应用群集），它是双机同时处理认证请求的，具有负载分担，冗余备份的特点。

4.2 实现应用

4.2.1 数据库自动同步复制

组成NLB系统的二台服务器，当一台服务器数据库有读写操作时，另一台服务器中自动同步操作。可以实现另一台服务器上开立的用户，数据库自动同步复制正常。

4.2.2 NLB双机热备

二台服务器组成NLB双机热备，SAM3.0具有双机热备功能。关掉一台SAM服务器或者离线，用户可通过认证。

4.2.3 方案效益

通过RGAC技术，可以在较少的投资和不改变原有网络部署方案的情况下解决以下问题。
峰值问题

SAM系统在上线和下线的高峰期时，这是网络流量的高峰阶段，其它时间网络流量相对较少。服务器的处理存在“波峰”和“波谷”的变化，而且“波峰”时，业务量大小的变化又不规律，这就使SAM服务器不得不面对“峰值堵塞”问题。原有解决方法为增加服务器的本身硬件配置或实现单机热备，提高处理能力。但仍存在性能不平衡问题，且这样做，投资成本大而且本身硬件配置提升对于高校客户来说是有瓶颈的。

单点故障

单台SAM服务器的设置，不可避免会出现“单点故障”，需要进行SAM服务器“容错”。为实现容错，现在2.x的做法是主服务器旁安置一台备份服务器做热备。但这样做，平时只有一台服务器工作，另外一台服务器处于空闲状态，无法完全利用所有服务器的处理资源，投资得不到充分利用，还是相当于一台服务器在工作而已。且当出现“峰值堵塞”时，所得到的很可能是“多米诺”效应，即所有服务器连续被“堵”至“死”，互相切换直到最后所有服务器都死掉，最终系统完全瘫痪。并且，当所有服务器都损坏时，无法动态、合理地利用其它资源提供服务或备份。

扩展不便

随着SAM应用规模不断的增大，服务器上所要处理的数据量不断增大，同时在线产生的数据和web管理员需要进行管理的数据也会越来越多。若处理资源不够，在未超出系统容量时，往往是客户的请求回应越来越慢，可容纳的同时连接数量逐渐减小，系统性能严重下降。当超出系统容量后，系统出现故障导致业务中断。为应对日益增多的业务量，系统的扩展性尤为重要。

5 支持AC技术的产品
　　

集群技术	产品
支持网卡	Intel系列网卡
	3Com系列网卡
	不支持其他如TP LINK等网卡
支持系统	Windows Server 2003
支持数据库	MS SQL Server 2000