UISS双引擎热备技术.docx
《UISS双引擎热备技术.docx》由会员分享，可在线阅读，更多相关《UISS双引擎热备技术.docx（12页珍藏版）》请在冰豆网上搜索。
UISS双引擎热备技术
UISS双引擎热备技术白皮书.doc
UISS双引擎热备技术
前言
摘要
高可用性的要求包括故障检测与故障恢复两方面，本文档主要关心的是故障恢复方面的实现，
简要介绍基于UISS的热备份功能的技术特点、应用方案及实现要点。
关键词
UISS、高可用性、冗余、热备份
缩略语清单
缩略语英文全名中文解释
UISSUnInterruptedSupervisorEngineSwitchover无中断引擎切换
UISS双引擎热备技术白皮书.doc
目录
1概述
随着网络规模及应用领域的急速扩张，网络日益成为社会生活中不可或缺的部分，企业与个
人的通信与交流都离不开网络的使用。
随着企业对网络依赖性的增加，网络必须安全可靠，
一旦网络服务不可用，可能严重影响企业的生产力及赢利。
系统停机可划分两类：
l未经计划的停机（故障）
它们是不可控的、随机的，通常与软硬组件缺陷相关。
l有计划的停机（维护）
如系统的修理、升级等，由于它们在一定范围内是可调度的，因此对可用性的冲击可以
降低到最低限度。
由于网络应用需要穿越多个网络段，要保证网络的可用性，所有的网络段都必须具有故障中
恢复的能力，恢复要快至对于用户和网络应用都是透明的、不可觉察的。
增加网络的可用性与可靠性的最佳方法是减少偶然停机的发生，以及出故障后减少恢复时间
（MTTR）。
即使停机时间的小规模减少和MTTR小幅度的改善也能显著增加网络可用性。
要实现较高的可用性，避免出现由于单点故障而导致网络不可用。
从全局来看两个通信节点
之间应该有冗余链路，并进行拓扑的自动管理（如二层的STP、三层的路由协议等）或手工管
理；从局部来看网络节点特别是转发设备也应该具备应对单个组件故障的能力。
应对单点故
障，冗余是一种重要的策略。
高可用性的技术要求设备具有较高的可靠性，由于组件的可靠性提升空间有限，达到高可用
性目标的不能只依靠提高组件/器件的高可靠性，通常的实现方法是硬件上对一些关键组件进
行冗余备份，提供不停机更换组件的能力。
相应的软件支持则包括了热插拔、故障检测、隔
离与故障恢复。
从故障检测到故障恢复，如果冗余板采用冷启动的方式，则需要较长的恢复时间（异常处理+
机器冷启动）。
要实现快速的故障恢复，需要对设备的状态进行备份，这就是热备份功能需求
的来源。
通过状态的实时备份，组件与其对应的冗余组件保持状态同步，从而能够实现快速
的故障恢复。
UISS双引擎热备技术白皮书.doc
2
2UISS热备份技术需求及实现要点
2.1热备份技术需求
l能够提供引擎冗余的设备一般都采用基于Chassis的结构，功能方面的分布式构成（即
引擎和线卡的分离）是高可用性方案的硬件基础。
l引擎的高可靠性通过冗余来保证，在一块引擎发生故障或进行维护时，由另一块接替它
的工作（以下称为主板、备用板）。
l要想保证通信不中断，要保证冗余切换时线卡的物理状态与管理状态都不发生变化。
从通信支持的角度，网络设备的内部功能可划分为数据平面、控制平面与管理平面，它给网
络用户提供的通信转发服务是由数据面提供的，因此只要转发面的功能正常，对于用户而言
网络就是可用的。
对于单个设备而言，可以通过提引擎可靠性来提高设备的可用性，但这种方法的潜力有限，
很难达到高可用性的要求，要想提高可靠性只能采用冗余的方法，需要通过两方面保证：
l硬件构成上允许冗余
l软件要提供相应支持
能够提供引擎冗余的设备一般都采用基于Chassis的结构，功能方面的分布式构成（即引擎和
线卡的分离）是高可用性方案的硬件基础。
机器的组件构成包括引擎、线卡和Chassis，还有
风扇、电源等关键组件，这些组件都提供热插拔的硬件支持。
引擎提供管理面与控制面的功
能，线卡提供数据面的功能，Chassis负责将引擎、线卡连接起来，只要线卡工作正常，数据
转发就可以进行。
引擎是整个机器的管理与控制的汇聚点，一旦失效，会影响整个机器的可用性。
由于采用分
布式结构，引擎的失效一般不会引起整个机器的立即不可用。
引擎的高可靠性通过冗余来保
证，在一块引擎发生故障或进行维护时，由另一块接替它的工作（以下称为主板、备用板）。
下图是UISS热备份功能基础的物理构成模型：
UISS双引擎热备技术白皮书.doc
3
图2-1UISS热备份的物理模型
要想保证通信不中断，要保证冗余切换时线卡的物理状态与管理状态都不发生变化。
因为线卡的reload总是会引起通信的中断，即使线卡不重新初始化，而带有拓扑管理功能的
协议在开始运行时，一般会将接口的管理状态设置为禁用（如STP），而路由协议的重收敛会
带来路由震荡，通信不可避免的中断。
如果采用热备份的方法保证冗余板与主板的状态时刻一致，它在接替主板工作时，就不需要
去reload线卡或者重新设置内容，因而不会影响数据的转发，这样管理板的切换对于通信而
言是透明的。
2.2热备份技术要点
热备份的设计重点是解决以下几个问题：
双引擎间的状态同步
在主板一端如何收集信息、收集哪些信息；在从板一端如何处理这些信息，才能保证它与主
板的状态保持同步；
备用引擎内部的状态一致性
系统内部各个组件的状态是有关联的，而它们的状态信息是不是同时同步的，不能保证时刻
备用板系统内部各组件的状态都是一致的，由于切换可能在任意时刻发生，并且存在从产生
故障到检测到故障的时间差，因此在系统切换时，不能假设从板内部的组件状态是一致的，
也不能假设从板记录的状态与线卡的实际状态是一致的，因此切换需要有状态一致性检查。
UISS双引擎热备技术白皮书.doc
4
由于软件功能复杂，软件组件的构造方法千差万别，网络UISS按照设计“分而治之”的
原则，热备份按如下思路设计（技术实现要点）：
l主板与从板内的组件（或称实体）是一一对应，状态同步也建立在这种对应关系基础上，
称为“对等同步”。
“对等同步”的目标是保证对等实体的状态同步，并不能保证从板系
统内的组件之间、以及从板与线卡之间的状态一致；
l在系统切换期间，采用“数据面与控制面分离”的方法保证通信不中断。
因为上一步中
不能保证系统状态一致，所以在系统切换时，要进行状态一致性检查，包括两个部分：
1.从板系统内的状态一致检查
2.从板与线卡之间的状态同步
技术要点1：
对等同步
主引擎中实体的信息同步以备份引擎中的peer（对应实体）为目标，它只负责收集本实体内的信
息发送给peer，同步信息的解释只在实体内有意义，在对等实体之间可以采用各种方法达到同
步目标，如直接将状态发送过来、或将实体收到的事件发送来等。
实体之间的关联关系如何
体现，由更高层次的系统机制来解决。
图2-2对等同步
对等同步要保证实体内部状态在任意时刻都是一致的，因此不能将中间状态发送给peer，但是
不用保证在备份引擎的关联实体之间是同步的。
如上图中，假设实体A与实体B是有关联的，实体A的状态变化会引起实体B的状态变化，
但在对等同步中，只要求A`与A是同步的，A`与B`状态一致由B负责。
由于中途故障或切
换引起的A`与B`的状态不一致，在系统切换时解决。
UISS双引擎热备技术白皮书.doc
5
技术要点2：
数据面与控制面分离（数据不间断转发）
热备份指标要求数据面通信中断时间在数毫秒内，而控制面在切换后的恢复需要一定时间，
按正常操作规则，在初始化时将旧的转发表项清除。
在旧的表项已清除，而新的表项还未产
生的间隙中，数据转发就会中断。
“数据面与控制面分离”是指在新的转发决定表尚未产生以前，先使用旧的转发决定表。
在
系统切换后的一段时间内，逐渐以新的转发表取代旧转发表。
在的UISS热备份方案中，转发相关表项中动态、静态ARP表项都进行同步，路由的动
态表项、MAC地址表的动态表项均不进行同步。
但是这些表项在各线卡中具有软件或硬件的
Cache，因此在切换后，虽然管理板中未构造出完整的路由表，但各线卡的转发仍然可以继续。
在后续的收敛过程中，各协议运行产生的新表项，除了存储于引擎的路由表中外，还会逐渐
取代线卡中的旧表项。
在协议收敛后仍未被取代的旧表项，由线卡自行清除。
UISS双引擎热备技术白皮书.doc
6
3UISS热备份技术实现原理
3.1UISS热备份主备阶段简介
主备引擎的热备份过程主要分为批量状态备份、实时状态备份和数据不间断转发三个阶段。
通过对等同步技术来实现批量状态备份、实时状态备份，通过数据面与控制面分离和对等同
步实现数据不间断转发。
备用主引擎启动后，由于此时主引擎和备份引擎差异比较大，主引擎会将当前所有模块的备
份数据同步到备用引擎，这个过程称之为批量备份（见下图）。
图3-1主备切换前的阶段
批量备份过程结束后，系统进入实时备份过程，在此过程中，当主用主控板备份数据发生变
化时，备份数据将实时同步到备用板。
主备切换后，备用引擎升为新的主引擎，会通知各个模块向线卡进行数据收集和同步，这个
过程称之为数据不间断转发。
在这个过程中，各模块主动与线卡进行通信，在硬件状态、链
路层状态、配置数据三个方面进行确认和同步，以保证整个系统维护的数据和状态是一致的，
从而确保主备切换之后，系统能够正常运行。
这个阶段结束，新的引擎才称之为完全意义上
的主引擎（见下图）。
UISS双引擎热备技术白皮书.doc
7
图3-2主备切换后的阶段
3.2UISS热备份状态机简介
支持热备份系统的运行生命周期典型模型如下图所示：
UISS双引擎热备技术白皮书.doc
8
图3-3UISS生命周期模型
主用引擎状态机在如下五个状态顺序迁移，分别为：
等待备用引擎插入状态、等待批量备份
请求状态、批量备份状态、实时备份状态以及切换时数据不间断转发状态。
备用引擎状态则在就绪状态、批量接收数据状态、实时接收数据状态三个状态顺序迁移。
l主引擎启动后，首先处于等待备用引擎插入状态，等待备份引擎的批量请求；备份引擎
在初始化完成后，开始与主引擎进行批量备份的协商。
在单引擎环境下，主备状态机会
一直停留该阶段。
l备份引擎而启动后，则首先处于就绪状态，便发送自己在位消息至主用主控板。
在主引
擎进入正常运行态，备份引擎已完成初始化后，便准备发送批量备份请求。
l主引擎收到备份引擎在位消息后，状态迁移至等待批量备份请求状态。
l备份引擎状态迁移定时器超时后，主动向主引擎发送批量备份请求，同时迁移至批量接
收数据状态；主引擎收到备份引擎的批量备份请求后，状态迁移至批量备份状态，开始
UISS双引擎热备技术白皮书.doc
9
收集各模块数据并向备用引擎进行同步。
l主引擎上各模块批量备份结束后，向备份引擎发送批量备份结束消息，同时迁移至实时
备份状态；而备用引擎在接收到批量备份结束消息后，迁移至实时接收数据状态。
进入
实时备份状态后，主用和备用引擎的状态机就进入了一个相对稳定的状态，基本不再变
化。
l备份引擎在接收到同步信息后，只负责本实体的配置或状态同步，不用将自身的状
态变化作为事件发送给关联实体。
l备份引擎采用“对等同步”的方法，主引擎备份集合中的每个实体只备份自身的配
置或状态到对端，不负责关联实体的状态同步。
l当备用引擎检测到主引擎非正常状态时，则跃迁至数据不间断转发。
新主引擎在平滑过
程中，会向业线卡进行数据收集以及信息同步，过程完成后，正式升级为主引擎，状态
机迁移至等待备用引擎插入状态。
而原主引擎重新启动，启动后变为备用引擎，状态机
初始态为就绪状态。
3.3备份引擎到主引擎的切换
主备切换通常有以下几种可能：
l命令行执行主备倒换命令，
升级会员 