容错服务器在播出数据库中的应用

　　序言

　　业界周知，播出系统是全台最复杂、安全性要求最高的系统，而数据库的安全稳定运行则是播出系统的核心要素之一。在设计建设播出系统时，我们始终致力使数据库安全稳定运行。但在现实场景中，由于数据库故障导致的播出事故仍然常发，影响程度轻重不一，严重时将导致大面积长时间停播，恢复时间较长。本文就播出系统数据库的几个经典架构展开讨论，供读者参考。

　　一.共享盘阵双机热备数据库

　　双机热备数据库架构见图1，核心是采用DAS（Direct Attached Storage）存储和双机热备软件，任一时刻只有一台主机处于服务状态，另一台主机处于等待服务状态。处于服务状态的主机占用对外的IP地址，对共享盘阵有读写权限，对应的数据库进程处于活动状态。而等待服务的主机释放出对外的IP地址，没有访问共享盘阵的权限（甚至根本看不见盘符），数据库进程处于停止状态。在这个架构中，盘阵有两个SAS接口，分别接到主、备机上，主机写进去的数据可被备机读出，反之亦然，实现了数据的共享，数据的一致性非常好。

　　双机热备软件是一套资源管理系统，负责对外IP地址的转移、数据库进程的管理、盘符保护。特别是在主、备机倒换期间，对各资源按规定顺序停止、启动，违反这些规定都将使数据出错。从主机倒换到备机的过程是：1.停止主机数据库进程、撤销主机对外IP地址、关闭主机的盘阵访问权限；2.开启备机盘阵访问权限、加载备机对外IP地址、启动备机数据库进程。从备机到主机的倒换与此类似，倒换的时间大约在1分钟左右，倒换后客户机的工作状态需要认真确认。

　　这个架构的优点是数据“一致性”好，靠的是盘阵双SAS连接主机实现共享读写。缺点是，盘阵必须选用高端的RAID，而且是故障“单点”。

　　在实际部署中，双机热备软件需要作复杂的配置，在日常运行维护中，需要定期检查和倒换测试。双机通过RS232或CAT5心跳线相互检测对方是否存活，对环境要求非常苛刻。在实际使用中，出现过双机互检失败而争抢资源致宕机的情况，因盘阵故障导致数据丢失的情况也发生过。

　　由于这种架构设备昂贵，且盘阵是故障“单点”，目前这类案例逐渐减少。

　　这种类型的架构适合多种平台（W i n d o w、L i n u x、Solaris）、数据库软件（SQL Server、Oracle）、双机热备软件（Costandby、EMC autostart、NEC Express cluster ）。

　　二.动态镜像双机热备数据库

　　为了规避共享盘阵的单点，动态镜像双机热备数据库架构得到广泛使用，在播出系统中占比较大。

　　这种动态镜像双机热备架构不再需要昂贵的DAS存储盘阵，直接用服务器内置存储就可以部署系统。数据的“一致性”是靠双机热备软件实时镜像数据来保证的。

　　这里的实时镜像，不是文件级镜像，文件级镜像不能保证数据的一致性。在这个架构中，数据镜像是磁盘指令级的镜像，是单步镜像，一步完成了再进行下一步。

　　该架构消除了单点故障，综合性能较好。在实际使用中，发现的问题是，数据镜像其实是很困难的，曾发生过倒换前后数据不一致的情况。

　　这种类型的架构也适合多种平台（Window、Linux、Solaris）、数据库软件（SQL Server、Oracle）、双机热备软件（Costandby、EMC autostart、NEC Express cluster ）。

　　三.实时应用集群数据库系统

　　数据库，有一台主机处于待机状态，未对外提供服务，存在浪费现象，并且倒换时会中断1分钟左右，对于访问数量较大的业务（如金融、票务等）不太适合，這种环境下可采用实时应用集群。

　　实时应用集群数据库RAC（real application clusters）多见于Oracle数据库，是一种集数据多重复制、负载均衡、多层次故障转移的系统架构。在该架构中，前台有多个主机，每个主机有两个网卡，每个网卡有一个IP地址。在后台，用SAN网络部署块级（BLOCK）存储，实现数据多重复制和故障转移。另外，还有心跳线专属网络，这是系统正常工作的首要条件。

　　需要特别补充说明的是，在该架构中，Oracle数据库系统自动部署Servicename服务，该服务类似于DNS，实现负载均衡。客户端连接数据库时，首先连接Servicename服务，得到相应的IP地址和数据库SID，当有多个客户端连接时，每个客户端得到IP地址和SID都不同，分别对应不同的主机，实现了负载均衡。当某个主机一个网卡的网线断开后，这个网卡的IP地址便转移到另一网卡；当两个网卡的网线都断开后，两个IP地址都转移到另外的主机。在发生网卡断线、主机失效等情况时，servicename服务系统会相应调整分配策略，以实现可靠的故障转移和负载均衡。

　　实时应用集群数据库，从多个层次保障了数据的安全性和服务的连续性，能够满足金融、股票等访问量很大的业务需求。但该架构的缺点是系统复杂，对系统环境要求极高，稍不满足就可能发生故障，维护成本高。在现实应用中，出现过网络的瞬间丢包导致切换，也出现过因网络的轻微故障导致保护性关机的情况。

　　四.容错服务器搭建数据库

　　前面介绍的三种数据库架构，关系到三个层次：硬件及OS、集群软件、数据库软件，结构复杂。在安装部署时，有复杂的连接线，如SAS电缆、SAN存储系统、心跳线，这些连接线要求很高，稍有缺陷便会成为隐患。然后每台主机安装操作系统和集群软件，最复杂的是集群软件的资源配置，几乎涉及所有硬件的参数，没有足够的经验是没有把握的，在日常应用中，还要定期进行倒换实验。尽管做了如此多而复杂的工作，这三种架构的数据库故障并未显著降低，离安全播出的“零事故”要求相差甚远。

　　这三种架构的数据库，我台均采用过，但都不省心。在建设全频道高清播出系统时，我们再次为数据库的选型而纠结。“众里寻他千百度……”，一个偶然的机会，我们了解到容错服务器（fault tolerance server），该服务器在高速ETC、国家气象、国家电网、钢铁生产等行业广泛应用。这些行业的安全性要求与播出等同，容错服务器能否为我所用，我们作了必要的分析调研。

　　从图4左边可以看到，容错服务器是一个可以插入两个服务器模块的机箱，形成一个完整的容错服务器。从图4右边可以看到，两个模块并非独立存在，而是通过Lockstep关联起来。正是这个关联，解决了前面说的三种架构中数据同步、心跳检测、故障切换的问题。

　　在安装部署上，一个容错服务器就是一个框体，自然不再需要集群软件，操作系统、数据库软件只需安装一次（在购买操作系统和数据库软件时，也只支付单台服务器费用），便自动同步到两个模块。运行管理上，也就是一台服务器，但从内部看，具备完整的硬件容错、数据镜像、失效切换、安全离线等机制。

　　容错服务器的设计理念，是将主要的硬件（CPU、内存、主板、I/O设备、硬盘驱动器和风扇）全部冗余化，实现在同一框体内的两台完整的服务器之间形成完全冗余结构，以提供服务器的连续可用能力。容错服务器上线后，无间断运行、无中断维护，系统运行状态下可直接拉出故障模块进行维修，修复后可直接插入模块，恢复到原始冗余状态。容错服务器的冗余机制见图5。

　　五.总结

　　在播出一线，效率和安全是王道，系统建设应该朝着傻瓜化努力，降低系统的技术门槛，减轻运行维护人员的负担，把精力投入到提升业务水平、产生更多的效益上去。在采用容错服务器后，数据库变得非常简单，只需做好日常巡查和数据备份，经过两年多的使用证明，容错服务器的确安全省心。B&P

罗星屏