《Cisco IOS XR技术精要》一4.3　配置管理组件

4.3　配置管理组件

Cisco IOS XR技术精要
控制平面与数据平面的分离是由多种不同的组件共同完成的。本节详细讨论了配置管理中的一些关键组件，包括配置管理器（Cfgmgr）、配置文件系统（CFS）、系统数据库（SysDB），以及副本数据服务文件系统（RDSFS）。

4.3.1　配置管理器

Cisco IOS XR配置管理器（Cfgmgr）是一个必不可少的软件组件，为路由器的配置提供维护、应用、与维护支持。配置管理器还负责通过RDSFS实现CFS访问区域。多说一句，CFS对所有管理节点的复制与同步工作也是通过RDSFS完成的。

配置管理器主要功能性如下所示。

当路由器启动并运行时，Cfgmgr可以在很短的时间内完成配置的保存与应用。
在CRS或GSR XR12000分布式结构中，Cfgmgr也是分布式的，每个Cfgmgr分别负责各自节点的配置应用。
Cfgmgr负责在管理节点上存储配置，用于访问所有其他节点。
活动状态下，MSC驱动器/客户端会发送配置请求给Cfgmgr来保存配置。
在系统运行期间，Cfgmgr可以优化过量配置信息的提交处理。
Cfgmgr负责管理与配置相关的服务，如配置检查点、配置回退、配置历史，以及配置上锁或解锁。
注释：回退（rollback）是指将系统恢复到执行某一动作前的版本。用户可以使用配置回退这一强大的配置特性轻松地将配置恢复到先前的某个状态。

我们来讨论一下在路由器使用主用寄存配置启动的环境下，Cfgmgr的作用。主用寄存配置（primary persistent configuration）是IOS XR中的一个新的概念，后文会对其进行解释。首先，RP上的Cfgmgr会检查主用寄存配置的状态。基于主用寄存配置的状态，系统会选择使用主用寄存配置，或是ASCII备用配置（备用寄存配置）来恢复路由器的运行配置。当主用寄存配置版本变更、文件损坏或是不能向下兼容时，系统也会选择ASCII备用配置。

配置管理器由一组名为Cfgmgr RP和Cfgmgr LC的进程组成。这些进程的主要用途是恢复系统的配置。表4-1及表4-2通过分布区域及配置示例总结了Cfgmgr RP与Cfgmgr LC的功能、角色，及作用。

图4-1中的Cfgmgr RP进程恢复共享平面配置及其本地平面配置（例如管理节点接口）。运行在每个MSC或节点上的Cfgmgr LC进程将配置应用在各自的节点上。

4.3.2　配置文件系统（CFS）

配置文件系统（CFS）是一组用来保存二进制格式主用寄存配置的文件和目录。CFS受Cfgmgr管理，并通过RDSFS将自身复制到SDR内的其他管理节点上（RP和DRP）。CFS中除了主用寄存配置之外，还包括ASCII备用配置、配置历史、配置提交检查点、启动失败配置文件、版本信息、元数据文件等。配置文件存放在管理节点的CFS根目录中。默认情况下，配置文件位于< 文件系统>/config/目录下。Cfgmgr会使用diskutil系统工具找出哪个文件系统是CFS。

注释：默认系统使用disk0文件系统作为CFS，用户可以设置ROMMON变量将CFS设置成disk1或CF卡等平台支持的其他文件系统。

命令dir可用来查看文件系统中的文件（目录）。例4-2中列出了CFS中的系统配置文件：running config、历史配置（已提交的配置）、admin配置等1。

例4-2　disk0上的CFS

在例4-2中，disk0:config的输出中包含以下主目录。

admin目录包含所有管理平面配置。
lr目录包含所有SDR相关文件。
failed目录包含所有启动未成功的配置。如需要，可以查看这些启动失败配置，并重新输入来恢复系统配置。
history目录包含所有与配置修改相关的系统事件（如提交操作）。命令show configuration history可查看history目录中的内容。
removed_cfg目录包含了在PIE卸载或是在版本升降级时CLI命令不支持的场景下被删除的配置信息。例如，如果系统配置了组播特性，那么当组播PIE从系统中删除时，所有与组播相关的配置将被放入romoved_cfg目录中。

CFS会周期性地在主备RP之间保持同步，用以维护RP故障切换后系统的配置状态。CFS也会在除MSC之外的所有其他管理节点中创建目录并保持同步（原因是MSC中无磁盘）。图4-2清楚地列出了CFS的目录结构。

如先前提到的，主用寄存配置（primary persistent configuration）是Cisco IOS XR中的一个新的概念，不要将其与IOS中的启动配置（startup configuration）弄混。主用寄存配置是基于提交基准点（commit refpoint）与绝对基准点（absolute refpoint）创建的。主用寄存配置以二进制形式保存（SysDB格式）；因此，在系统启动阶段可以方便地将主用寄存配置直接地恢复到内存中。绝对基准点与提交基准点保存在CFS中，每次修改或提交配置都会被更新。

注释：对于每次成功的提交操作，系统都会创建一条commit数据库记录。基准点（refpoint）便是引用数据库中这些记录的基准。

举个例子来说明这些绝对基准点和提交基准点是如何创建并且恢复路由器配置的。在图4-3中，磁盘中的CFS包含所有从1000000120～1000000219的提交基准点文件。这些提交基准点中的每一个文件都对应着用户配置修改后的一次提交操作。绝对基准点包含了在提交了1000000216之后的路由器配置。后续的三次提交的提交变更文件（1000000217～1000000219）和先前提交的（1000000120～1000000216）都是可以查看的。

当用户在这个时间点重启系统时，路由器将从由绝对基准点和3个提交基准点组成的主用寄存配置中恢复配置。

备用寄存配置同样存储在CFS内的commit数据库中，相当于IOS中的startup configuration。备用寄存配置是以ASCII格式保存的，ASCII备份文件使用CLI形式保存着整台路由器的配置。在系统重启或是PIE/SMU激活之前，备用寄存配置是根据一定的时间间隔更新的。当系统启动出现以下情形时，备用寄存配置会被判定在启动阶段恢复配置。

当检测出二进制配置文件损坏或配置不一致（inconsistency）。
路由器升级后的软件与二进制配置不兼容。
ASCII配置仅能用来恢复最新的路由器配置，先前的历史配置变更无法恢复。一旦配置从ASCII备份中恢复，用户将无法查看并回退到先前的提交基准点。只有系统从主用寄存配置中恢复后才能使用回退功能。

CFS中的文件与目录是路由器内部使用的。用户不应对其修改或删除。修改操作会导致配置丢失并且会影响业务。

注释：绝对基准点是路由器周期定自动更新的。提交基准点是每次对配置更改执行commit命令时更新的。提交基准点文件中会保留最近100次的提交实例。

4.3.3　SysDB在配置管理中的作用

在第2章中曾提到过，SysDB是一个完全分布的数据库系统，其数据结构与UNIX目录结构很相似，用户可以查看到完整的路径。存放在CFS中的主用寄存配置使用的便是SysDB格式（二进制），这是一种私有的格式。实际上，所有保存在CFS中的配置文件使用的都是这种SysDB格式。使用SysDB格式，配置恢复时可以绕过parser（分析程序）的命令解析过程，从而实现更快的配置恢复。

SysDB与其他类型的数据库一样，当不同用户尝试修改同一数据时，SysDB将会被锁住，防止配置不一致（inconsistency）的情况发生。配置以二进制数组的格式储存在SysDB数据库中，使得配置命令可以更快地被解析，间接地提升了系统启动速度。

注释：在传统IOS中，配置文件是以ASCII格式保存的，与IOS XR中备用寄存配置使用的格式相同。

每次SysDB信息的变更或修改都需要通过commit进程来完成，这样的设计是为IOS XR的回退特性考虑的。路由器配置恢复（或路由器启动）阶段是没有commit ID的，因为实际上并没有用户执行提交操作。SysDB提供了一种管理客户端从进程中访问可操作数据的方法。SysDB可以理解成是通过CLI或SNMP配置设备的用户与系统特性之间的实现接口，允许用户创建、修改配置，并将语法正确的配置保存起来。

配置会在SysDB的帮助下分发到三个不同的平面——管理平面、共享平面、本地平面。当配置提交给路由器时，配置信息将被会被parser程序解析（假定通过CLI方式配置）。parser会将CLI格式的配置转换成内部SysDB格式（也叫做SysDB数组）。当SysDB接收到一组配置数据后，首先会将这部分数据处于阻断（block）状态，并将配置分发给其他节点来确认配置的有效性。本地平面数据会被发送到合适的节点上进行验证。共享平面数据会发送到某个RP/DRP卡上（DSDRSC）进行验证及处理。

SysDB是由3个负责不同配置平面的服务器进程组成的。这些服务器进程分别为sysdb_svr_admin(管理SysDB服务器)、sysdb_svr_shared（共享/全局SysDB服务器），以及sysdb_svr_local（本地SysDB服务器）。此外，还有一个叫做“medusa”代理服务器的sysdb_mc的进程。服务器进程会储存各自平面的配置，medusa（sysdb_mc）主要扮演管理代理的角色，负责在各个配置平面服务器之间转发信息。

注释：在IOS XR中，管理代理（Management Agent）是位于配置管理器和外部环境之间的一个进程。代理（Agent）负责与用户或外部管理系统进行交互，实现配置的查看与编辑。

对SysDB的访问受控于以下三种不同的服务器进程。

共享/全局SysDB服务器：包含系统的公共信息，以及主要的控制平面特性，如AAA、路由选择协议等。它运行于RP和DRP上。
管理SysDB服务器：包含系统的管理信息，仅运行在RP上。
本地SysDB服务器：包含节点的本地信息（如接口信息），运行在每个LC节点上。
不同平面配置数据基于SysDB命名空间子树相互分开。系统为本地平面数据和共享平面数据分别定义了各自的子树。例如，所有在/cfg/gl目录下的数据都被认为是共享平面数据，会被发送给DSDRSC验证并更新running config。/cfg/if/act/< ifname>目录下的配置都是本地平面配置，会被发送到接口所在节点上的本地SysDB服务器。

SysDB数据在逻辑上具有层次化的命名空间。命名空间特点包括：

层次化的分组信息；
有序的数据结构，有效访问数据存储中的数据项。
数据项在SysDB中以一种支持快速查找的结构存放起来。SysDB数据存储通过树形结构的方式，实现了层次化的命名空间。三个不同的服务器分别负责转换SysDB数据库中各自平面的数据部分。

简单地说，SysDB就是内存中running config的一个副本，其中存放着由管理代理提供的、由不同平面验证的running config。在此基础上，SysDB会在节点之间复制管理和共享平面配置，并在本地节点间分配本地平面配置。图4-4诠释了本地、管理、全局SysDB空间之间的关系。

4.3.4　副本数据服务文件系统（RDSFS）

副本数据服务文件系统（RDSFS）是一种可提供如下服务的应用。

分布式虚拟文件系统。
通过文件/数据副本实现高可用性。基本上，任何从文件系统接口输出的对象都可以通过RDSFS复制并访问。
由于节点可能随时会停止工作，又会在任何时间内恢复工作。所以节点上的应用需要以一种与节点位置无关的方式访问配置文件系统（CFS）。在CFS对可扩展性、高可用性、可靠性的要求的这种条件下，引出了RDSFS技术。RDSFS通过复制CFS数据以及分布式的文件系统访问功能来试图解决这些问题。RDSFS负责维护这些数据副本的一致性，并确保在磁盘错误、配置并发，以及节点故障或恢复时不会影响到数据副本及业务。MSC自身没有磁盘，也是通过RDSFS的虚拟磁盘系统的功能读取CFS文件的。