某公司zxg10-sc可靠性说明.doc

此文档收集于网络，如有侵权，请联系网站删除天马行空官方博客：/tmxk_docin ；QQ:1318241189；QQ群：175569632ZXG10-SC可靠性说明此文档仅供学习与交流目 录1系统可靠性设计11.1 硬件冗余设计11.1.1模块处理机（MP）11.1.2T交换网11.1.3 T交换网驱动板21.1.4 FBI板21.1.5 主处理机网卡21.1.6 通讯板21.1.7 电源21.1.8 业务处理机和数据库服务器31.1.9 核心交换网31.2软件可靠性设计41.2.1 层次化、模块化设计41.2.2 系统运行监测和日志41.2.3 资源管理41.2.4 指针越界、堆栈溢出的预防51.2.5 过负荷控制51.2.6 容错处理61.2.7 监控程序71.2.8 数据可靠性72 短消息中心的MTBF和MTTR81系统可靠性设计1.1 硬件冗余设计为了提高硬件的可靠性，采用的主要方法是冗余设计。ZXG10-SC系统中的关键部件均采用冗余设计。1.1.1模块处理机（MP）ZXG10-SC中的模块处理机（MP）采用主备用设计。其中一块MP处于主用状态，另外一块MP处于备用状态。主用MP处理所有的业务，备用MP处于热备份状态。备用MP每隔10ms扫描一次主用MP的运行状态，当发现主用MP的运行状态发生变化，即从主用状态变化为非主用状态时，立即进行倒换。倒换成功后，原来的备用MP成为主用MP，并承担所有的业务处理任务。为保证MP倒换后业务处理的正确性和延续性，备用MP的数据应和主用MP保持同步。同步过程分为两个阶段，起动阶段和运行阶段。当备用MP起动时，和主用MP做系统配置数据的同步。该同步过程由数据库应用进程负责。当备用MP进入运行状态后，备用MP中的各进程每隔一定的周期与主用MP上的相同进程做进程间的数据同步。ZXG10-SC系统中提供多种MP倒换方式，包括手动倒换、故障倒换、周期性倒换、人机命令倒换。当MP发生故障时，系统以图形界面和声光方式通知维护人员，以便及时更换发生故障的MP。1.1.2T交换网T交换网由两块交换网板组成，采用主备用方式。这两块交换网板的主备用状态由MP控制。当主用T交换网板发生故障时，MP能立即检测到，并把备用T交换网板转为主用。从故障发生到倒换结束的时间在五秒之内。当T交换网发生故障时，系统以图形界面和声光方式通知维护人员，以便及时更换发生故障的T交换网板。1.1.3T交换网驱动板SP级别T交换网驱动板采用主备用方式，备用驱动板时刻监测主用驱动板的状态。当主用驱动板发生故障，备用驱动板立即监测到，并把自身倒换为主用状态，时间为一到两秒。1.1.4FBI板FBI板（模块之间的光纤接口板）采用主备用方式，备用驱动板时刻监测主用驱动板的状态。当主用驱动板发生故障，备用驱动板立即监测到，并把自身倒换为主用状态，倒换时间为一秒左右。1.1.5主处理机网卡每个模块处理机上有两块网卡（10M/100M自适应），采用主备用方式。当主用网卡10秒钟内没有收到任何数据包时，关闭主用网卡，起动备用网卡。1.1.6通讯板为了使ZXG10-SC的模块内通讯更为可靠，硬件在连接上实现双备份，每个SP均通过64kb/s HDLC链路与一对通讯板相连。为了加快遇有故障时的链路切换的速度，将同一SP与该对互助通讯板的链路全部建立好，至于选择哪一条链路通讯，由主用MP来决定。当两条链路均建立成功时，主用MP为平衡这对互助通讯板的负荷，在链路选择时采用优先选择的方法，原则是通讯板上偶数号通道优先选择左板位通讯板上的链路，奇数号通道优先选择右板位通讯板上的链路。当选用的链路发生故障时，MP选用另一块通讯板上的正常链路。ZXG10-SC的模块间通讯的硬件在连接上实现双备份，每个模块均通过464kb/s HDLC链路与一对通讯板相连。为了加快遇有故障时的链路切换的速度，将同一模块与该对互助通讯板的链路全部建立好，至于选择哪一条链路通讯，由主用MP来决定。当两条链路均建立成功时，主用MP选择左板位通讯板上的链路。当选用的链路发生故障时，MP选用另一块通讯板上的正常链路。1.1.7电源ZXG10-SC（V3.0）系统每层机框采用双电源并联方式供电。当其中一个电源发生故障时，仍能保证正常的供电。当电源发生故障时，系统以图形界面和声光方式通知维护人员，以便及时更换发生故障的电源。1.1.8业务处理机和数据库服务器ZXG10-SC系统中的业务处理机和数据库服务器采用双机热备份、磁盘冗余阵列等方式保证业务处理机和数据库服务器的可靠性。双机系统的技术基础是集群（Cluster）结构。Cluster集群技术的出发点是提高系统的可靠性、可扩充性和抗灾难性。一个Cluster包含多台拥有共享数据存储空间的服务器。当一台服务器发生故障时，它所运行的应用程序由其它服务器自动接管。该系统能实时监测主机系统的如下故障并自动发起倒换，由另一台服务器接管应用。1）系统软件或应用软件造成服务器宕机。2）SCSI卡损坏，造成服务器无法从磁盘阵列读取资料。3）服务器硬件损坏，造成服务器宕机。4）服务器关机。双机各自拥有自己的机器名和IP地址。对外界提供同一个虚拟机器名和IP地址，并以此对外界提供服务。自身的IP地址在主机状态时将失效。磁盘阵列采用IBM SSA技术，共有4个双向40MB/S通道，总带宽达到160MB/S，对磁阵每个硬盘的读写构成一个双向环，中间任何一块硬盘的损坏不影响系统的处理速率。且带宽的使用不使用共享方式，独特的带宽空间复用方式极大地提高了系统的处理能力。1.1.9核心交换网ZXG100-SC系统采用100以太交换网将所有的设备联接在一起，为了避免单点故障，系统设计采用双网双平面的设计方式。任何一台服务器和其他设备的联接都存在两条通路，通路采用Cisco 3548交换机，同时提供千兆以太网端口，以供以后扩容接入，带宽使用不采用侦听/检测技术，最大程度提高系统的安全行。1.2软件可靠性设计ZXG10-SC系统采用以下方法提高软件的可靠性。1.2.1层次化、模块化设计ZXG10-SC软件系统可分为以下几个系统：1）运行支撑子系统；2）数据库子系统；3）信令子系统；4）SMPP代理子系统；5）业务控制子系统；6）操作维护子系统。各个子系统相对独立，并形成一个层次结构。按照高内聚性、低偶合性的原则，把每个子系统细分为多个功能模块，提高系统的可靠性。1.2.2系统运行监测和日志运行支撑子系统中提供运行监测功能。它能及时发现进程运行过频、进程死循环，以及中断12和中断13等故障，并提供故障自动恢复功能。当系统发生异常，把运行现场数据记录到磁盘上的日志中。日志中记载的数据能够帮助开发人员迅速发现并排除故障，提高了系统的可靠性。操作维护子系统各模块把运行过程中检测的异常情况写入日志数据库中，通过查询日志数据库，维护人员能及时发现并排除故障。1.2.3 资源管理1）内存资源的管理ZXG10-SC软件系统采用两种方式避免内存的枯竭。第一种方式为静态分配法，适应于所需内存数固定的情况。具体方法是在程序中定义全局数组。第二种方式为系统初始化时动态分配内存，适用于所需内存数不固定的情况。这两种方法避免了在系统运行过程中动态分配内存，不会发生内存资源枯竭的现象，提高了系统的可靠性。2）数据区资源的管理系统在投递短消息时，会先申请一个进程数据区，用以保存相关信息。在收到投递响应后，可以根据保存的信息进行处理，在处理完成后，释放该进程数据区。但是，若系统由于某种原因，未能收到投递响应消息，则此进程数据区将会被长期占用，导致系统可用资源的减少，最后导致系统耗尽所有的进程数据区，从而无法进行正常的业务处理。为防止上述情况的发生，系统记录每个进程数据区被占用的时刻，将所有被占用的数据区按占用时刻先后排列（以链表方式），定时检查最早被占用的进程数据区的占用时刻，若该时刻距当前时间已超过一定的门限，则可认为该进程数据区消息丢失，系统将释放此进程数据区。1.2.4指针越界、堆栈溢出的预防系统中的每个进程都有自己的堆栈，堆栈的大小是固定的。进程函数中定义的局部变量占用堆栈的地址空间，如果局部变量定义太多，会导致堆栈溢出，即中断12。为避免这种情况的发生，一般不在进程函数中定义长度很长的局部变量，而是把它们定义成全局变量。以上方法减少了发生堆栈溢出的可能性，提高了系统的可靠性。系统从底层收到的消息，包括消息事件号、消息指针、消息长度等参数，其中，消息指针指向包含消息内容的内存空间，消息长度指明该内存空间的大小。系统会直接根据消息指针访问消息内容。若消息长度比预期的要短，则系统在访问消息内容所在的内存区域时，可能会发生指针越界，导致系统崩溃。为防止这种情况的发生，系统在收到每条消息时，首先比较一下消息长度参数是否小于预期的消息长度：若低于，则拒绝该消息，认为消息有误；否则，进行正常处理。1.2.5过负荷控制作为GSM网的一个独立实体，短消息中心的主要功能是：接收MS或ESME提交的短消息，并将之转发给其他MS或ESME。因此，短消息中心的负荷主要来源于外部实体的短消息提交等业务处理请求。SC业务处理机负责集中处理来自短消息网关MSC和SMPP Agent的短消息提交、查询、替换、删除、用户查询、留言、修改密码等请求消息。在业务繁忙时，由于处理能力有限，业务处理机会出现来不及处理的情况，导致底层支撑系统积压了大量的待处理的消息。其后果是：一方面，积压的消息可能要等待很长时间后才能得到处理，而消息发起方认为已超时，业务处理机的处理无效；另一方面，因为存储空间有限，底层支撑系统会丢弃一些消息，若丢弃的是系统的短消息投递响应，会使系统认为该消息投递未成功，进入不必要的重试处理。为此系统提供拥塞控制功能。在发现消息已积累到一定程度时，有选择地对一些消息不进行处理，而是直接加以拒绝，拒绝原因就是“系统拥塞”。拒绝对象主要是那些处理比较耗时的消息，如提交短消息等。这样可以加快系统的处理，减少消息的积累，提高了系统的可靠性。在系统负荷略超过系统处理能力时，对过载消息直接返回响应，拒绝此消息，原因为“系统拥塞”。在系统受到外部的大话务量冲击（远高于系统的处理能力）时，对过载消息直接丢弃，不返回任何响应。为运营者提供系统运行监测工具，在系统出现过负荷时，给出具体信息（如发生地点、详细原因、建议措施等）。在系统因为异常原因（如，受到恶意攻击）出现过负荷时，通过告警手段提醒运营者。1.2.6容错处理1）业务队列的恢复在SC业务处理机中，有三个重要的业务控制队列：等待用户队列、重试用户队列和定时消息队列，这三个队列均保存在内存中，以提高系统处理速度。若系统因为故障、倒换等原因而发生重起，则会丢失这三个队列。为保证重启后系统的正常运行，系统在重起时，首先遍历所有的目的用户短消息索引表（该表保存在数据库中），取出相关数据，重建这三个队列。方法如下：当发现该目的用户有等待发送的新短消息时，将该用户加入到等待用户队列中；若发现该目的用户存在未成功发送的短消息，则将该用户加入到重试用户队列中；若发现该目的用户存在需要定时发送的短消息，则将该条短消息加入到定时消息队列中。2）定时器的保护系统由于业务处理的需要，会使用一些由底层支撑软件提供的定时器，进行定时监测系统资源、定时处理业务队列等工作。由于底层支撑软件的特点，每次定时器消息到达后，系统均需要重新设置该定时器。若定时器设置失败，或者定时消息丢失，则该定时工作就无法再度执行。为此系统采取以下措施。系统设置一个定时时间较长的定时器，用以定时检测定时时间较短的定时器的工作情况。设置一个全局标志数，系统启动时设为0；当短定时器的定时消息到达时，对此标志数增1；当长定时器的定时消息到达时，首先检查该标志数，若为0，则表示此短定时器已丢失，可重新设置；若标志数不为0，则表示此短定时器仍在工作，再对此标志数清零，以待下次检查。3）目的用户状态的超时检测在目的用户短消息索引表中，保存了该用户的当前处理状态，包括：空闲、等待发送、正在发送等。正在发送是指正在向该用户投递短消息，且尚未收到响应。当用户处于正在发送状态时，不能向该用户投递其他短消息，只有在收到投递响应后，用户状态才能改变，才能投递其他短消息。若投递响应丢失，则用户一直处于正在发送状态，无法投递其他短消息。为此系统采取以下措施。在目的用户短消息索引表中，记录用户状态改变的时间。当有新消息提交时，首先检查目的用户短消息索引表，若发现用户处于正在发送状态，但是发送时间距当前时间已超过合理范围，则可以认为该用户的投递响应丢失，系统可以投递此新消息。1.2.7监控程序在OMM Server采用软件看门狗程序监控服务器程序的运行。软件看门狗周期性的发握手消息给每个服务器程序，如果服务器程序没有返回应答，软件看门狗认为服务器程序发生故障，把服务器程序进程杀死并重新启动该程序。1.2.8数据可靠性1）数据访问当系统中的不同子系统访问SC的用户数据、短消息数据等信息时，根据特定要求分配给不同的权限，使其无法越权操作、破坏系统数据。2）数据存储SC中的重要数据，如用户业务信息、短消息信息等，采用成熟的、可靠的商用数据库系统进行存储管理，保存在磁盘上，并可以备份到磁带机、光盘等设备上，即使因系统故障导致数据丢失，也可以恢复到最近备份前的状态。3）数据处理在数据处理过程中，利用商用数据库的事务处理机制，将相关处理放在同一个事务中，保证相关数据的处理不破坏整体数据的一致性和完整性。通过对记录加锁，保证多个处理进程修改或删除同一条记录时，保证记录的一致性。2 短消息中心的MTBF和MTTR短消息中心主要由IW/GMSC、网络，SC业务处理组成。所有主要部件均采用热备份工作方式。短消息中心系统是一个复杂系统，其模型大致可以看做并串联系统，如下：IW/GMSCSwitch HubSwitch HubSCSCIW/GMSCIW/GMSC也是并串联系统，其MTBF约为60000小时,计算方式