利用数据库内核实现高可用性网络设计

随着语音、数据和多媒体业务需求的不断提升，通信架构也日趋复杂。数据管理是目前通信网络和业务开发中最具挑战性的领域，本文介绍的数据管理技术不仅能提供高可用性，而且还能提供卓越的性能、可量测性和成本效益。

全互联网协议(all-Internet Protocol)网络以及基于IP的业务通常要求通信系统不仅具有较短的开发周期，还要能保证传统的电信级业务的连续性和响应度。而且，随着语音、数据和多媒体业务需求的不断提升，通信架构也日趋复杂。静态信息的日益动态化、定制用户特性的不断增加以及内容丰富的预付费和在线点播业务的持续增长则使问题进一步复杂化。所有这些因素均要求大幅提升数据量，并对数据进行快速、可靠、精确地存储和访问，而且每次处理一项业务请求。

面对这些压力，系统供应商正试图采用一种基于公开的标准架构块方法以削减产品上市时间并降低通信架构开发和维护的成本。例如，业务可用性论坛(www.saforum.org)通过创建、宣传业界广泛采用的加速高可用架构和应用系统开发及部署的公开标准规范，详细讨论了该问题。

高速实时数据库是该设备的中枢架构块，可提供下一代网络所需的数据处理功能。这些数据库还可满足业务可用性和可靠性需要。该数据库通常基于专用解决方案，这往往加大了开发成本并延长了产品上市时间。现在，架构生产商则能从现有的实时数据库产品中受益，即以较短的时间及较低的成本提供更具竞争力的通信平台。

数据库分析

嵌入至通信系统内部的实时数据库系统需要：

* 对数量极大的简单查询进行响应(总是通过主键或唯一的辅助键加以实现)；

* 通过频繁的更新来管理简单数据；

* 具有高可用性，故障时间每年最多半分钟；

* 具有极短的响应时间，通常只为几个毫秒。

这些需求还必须适应不断增加的用户数需求。目前，大型移动网络所能处理的用户数范围已经达到一千万。将来，虚拟业务提供商将能共享相同的网络架构，这样单个网络将不得不支持更多的用户数。此外，用户也许很快就能使用嵌入至汽车和家用电器的移动设备，由此导致连接数目呈几何指数增长。

传统方法

传统基于磁盘的数据库可采用磁盘复制技术确保数据可用性。为了改进性能，存储进程可将处理程序从应用系统转移到数据库本身。这样，可以通过在RAM中获取数据以改进存取时间。该方法的存储速率仍然相对降低，尤其对于需要大量进行写操作的应用，因为这时磁盘I/O仍将成为主要瓶颈。

为了获得更高性能，专用实时数据管理系统可在RAM中进行所有的数据处理。通过在固定的内存位置存储数据，而不像高速缓存那样到处移动数据，即可实现更高的性能。该解决方案也同样适用于简单的数据结构。然而，这类实时数据库并不能提供很高的可靠性并且易受系统崩溃的影响。改进可靠性和可用性的方法(例如，通过在不同的内存段中采用同步复制)通常代价昂贵，使系统灵活地适应各类不同的应用通常需要不同的事务处理模式，这进一步增加了专用解决方案的成本。下一代通信系统将需要一种新型数据库以有效地进行实时数据管理。

分布式方法

为了满足实时系统中新型数据管理的需要，可以考虑能对分布在诸多网络节点上的数据进行同步复制的并行主存数据库系统。

所谓的无共享簇(由众多节点组成的并行系统，每个节点均自备操作系统、磁盘和RAM，这些节点实现高速互联)可以在多个处理器中进行分布式处理并能自动隐藏局部系统中的故障。

一旦出现故障，数据库系统可以自动配置并隐藏故障的处理器。故障切换时间(发现故障节点至切换至备用节点的时间)可以限制在50毫秒以内以保证业务不受干扰。此外，还可采用同步复制和动态配置支持在线轮询升级。这种设计可实现每年最多30秒故障时间的高可用性，即在99.9999％的时间内均能正常运行。

为使广大应用开发人员迅速采用这些特性，必须使其具有标准的应用编程接口，同时，还必须保持足够的灵活性以满足各种应用需要。这意味着必须开发出既能支持共享内存又支持无共享架构，同时还具有相当灵活度的冗余模型。因此，开发人员提出了所谓的N*Active/M*Standby冗余模型以适用实时分布式数据库，并被业务可用性论坛加以标准化。

在N*Active/M*Standby冗余模型中，数据库采用N个活动节点，在这些节点上，数据库服务器运行表征应用的事务。模型可以通过以下两条途径实现冗余：在活动节点间进行节点复制以及将数据复制到备用节点。

M个备用数据库节点可在数据库重配置过程中激活。这些激活可以是数据库管理人员提出的有计划重配置，也可以是由于节点故障导致的意外重配置。一旦活动数据库出现故障，应用系统将重新连接到备用数据库。

在全复制过程中，所有数据将在所有活动节点中加以复制。然而，在大多数场合下，具有两个副本的分离复制就能满足绝大多数可用性需求。

配置过程中，数据将采用一种对应用开发人员完全透明的分布式线性散列方法。活动节点将分成两类节点组，而数据则将在节点组内的节点进行复制，这样就形成了数据的主级复制和辅助复制(参见图1)。只要所有的节点组最少具有一个正常工作的活动节点，系统就能正常运行。

分布式数据库可解决多个节点故障。当一个节点故障时，节点组中的其他节点仍然能包含相关的信息分段，从而可以继续工作。当节点重启时，主级复制将配合节点重启并获取所有分段信息。这样，系统不仅不会出现任何故障时间，而且还允许对数据库进行写操作。

当所有的复制完成更新并将日志写入主存储器后，即可汇报情况。事务可以一种恒定的方式异步进行磁盘操作，这样如果出现系统故障，仍然能使数据库恢复到恒定的事务状态。

对于灾难恢复，异步复制还可用于分散分布的数据库。全部复制间的并行日志信道可提供处理网络冗余的灵活机制。

基准测试表明，基于无共享簇的实时分布式数据库设计可提供比非分布式主存数据库更优的性能以及更高的可靠性和可用性。

例如，爱立信公司开发的实时分布式数据库系统NDB簇已成为通过配置32个节点数据库簇解决每秒150万个事务的商用Unix系统的基准。负载则由利用高带宽实现互联并连接至数据库簇的23个远程处理器生成。

实际应用中的数据库

分布式实时数据库广泛应用于核心网节点，如移动切换中心，媒体网关和媒体网关控制器。数据库可用于存储面向会话的数据，这些数据反映了正在进行的连接和通信业务的状态。在部分系统故障条件下保存会话数据对于实现高可用性至关重要。数据库也可用于资源管理，下面的示例说明了这一点。

例如，在媒体网关中，数据库可用于管理一组表征节点物理资源的虚拟对象(图2)。媒体网关的任务就是通过对实际数据流进行处理(在用户平面上)以建立和拆除通话。媒体网关应用实现了用户平面控制功能。首先媒体网关为媒体网关控制器试图建立的通话分配实际资源 ，应用为设备建立与通话相关的协议，以完成连接并处理之后的数据流。通话结束，媒体网关将释放连接和设备。

一旦应用进程出现故障，另一进程可以通过从数据库获取信息从而接管应用。对于那些无法保存的通话，资源可利用数据库中的信息加以释放。在媒体网关中采用数据库可以显著简化资源管理。

数据库需要考虑的因素包括：

* 高可用性特性；

* 数据库处理器出现故障时，故障切换的时间小于50ms；

* 实时软件更新时的数据可用性；

* 性能和可量测性；

* 客户机—服务器模式下复制系统具有每秒10,000个事务的处理能力并使用尽可能少的处理器；

* 通过添加更多设备卡以提高数据库容量的能力；

* 对于数据的不同部分具有不同的响应时间需求；

* 在某些极端情形下，如当接入时间小于0.1 ms时，能在客户端缓存数据；

* 内存使用；

* 每个设备卡的内存容量有限(通常RAM的容量为0.5 G)；

* 较小的数据库内存规格以及每个数据库记录都具有最小开支；

* 应用开发；

* 可以便捷地将数据库集成至应用系统；

* 解析数据的物理位置(缓存在API或配置在远程处理器)；

* 解析数据库配置(是否运行于两个或更多处理器之上)。

数据管理是目前通信网络和业务开发中最具挑战性的领域，得益于分布式实时操作系统、数据库系统、网络运营商、产品生产商和设计人员的共同努力，目前已经推出的数据管理技术不仅能提供高可用性，而且还能提供卓越的性能、可量测性和成本效益。

作者简介：

Tomas Ulin是Alzato公司的总经理，Alzato公司是一家由爱立信公司出资，专注于在通信领域开发和销售分布式实时数据库技术的商务创新投资公司。Ulin于瑞典Royal Institute of Technology大学(Stockholm)获得计算机科学博士学位，于Case Western Reserve (Cleveland)大学和瑞典Uppsala大学分别获得电子工程硕士学位和工程物理硕士学位。