华为高可靠性设计指导(手抄本)

wordword27/27word1图SEQ图\*ARABIC1《软件公司地理容灾设计指导书》基于EMC磁盘陈列的硬件数据复制也能实现数据层面的容灾。TELLIN容灾系统对信令的切换控制根据网络配置的不同，主要支持备用信令点模式和GT翻译路由模式。备用信令点模式由SCCP检测信令点的状态自动实现信令业务的转接；GT翻译路由模式通过修改STP上的GT翻译数据实现信令的切换。图SEQ图\*ARABIC2TELLIN的CDR容灾和GDR容灾组网示意图设计参考：支持动态资源管理的BOSS双中心系统双中心配置，业务负荷分担设计，每个中心同时承载对方中心的备份业务，实现了基于虚拟化的动态资源调整技术，即一台物理主机划分成假如干个分区，每个分区有独立的操作系统，系统管理员可以自由添加、删除或分区间移动系统资源.例如CPU、内存、I/O适配器的分配，而不需要重新启动系统。在主机、分区和业务的分配上，设计为：1)物理主机分为多个分区；2)将同一业务中一个中心主用端和另一个中心备用端部署到同一台物理主机；3)同一主机所在分区承载业务为关键与非关键搭配；4)将主机剩余的资源和局部备用资源统一放在预留资源中；5)同一主机的预留资源可以灵活在生产局部和备份局部之间动态调整。对于突发的资源需求或者定期的资源需求，可以动态调整资源，以保证系统运行稳定。1.3网络冗余容错要求单条链路存在故障时，整个网络系统不失效。网络提供的业务仍是根本可用或者网络可以降级运行。设计上，要求在组网上对网络节点之间的链路提供冗余。冗余方式可以通过网元之间的直接并行连接，也可以通过其也网络节点迂回实现，并要求主备用链路经过不同的物理连接。设计参考：设备冗余组网路由器、防火墙、负载均衡器、局域网交换机、光纤交换机等网络设备全部采用冗余设计。主机上，所有业务主机采用冗余，非关键服务器使用单机。网络连接冗余设计主要保证单个网络连接异常或接口卡故障时，设备之间仍有备用通道可以正常访问。具有多个网络接口的网络适配器在整个适配器出现故障时会成为单点故障。为了获得最高的可用性，集群配置时应确保两上节点间的唯一路径不依赖一个网络适配器。设计参考：路由器冗余与高可靠性在两个层面实现；一种是通过对主机进展某种设置，当主机在访问主路由器失败时能够查找并切换到备用路由器；一种是路由器自身组成高可用性的集群，通过浮动IP等机制对外提供服务。需要主机主动参与切换的路由器备份技术有：ProxyARP:切换时间长IRDP(ICMPRouterDiscoveryProtocol)动态路由：RIP/RIP2,OSPF:缺点是主路由器与备份路由器间的转换较慢。其它一些技术支持路由器集群或主备路由器间透明快速地切换：HSRPVRRP：RFC2338GLBP设计参考：防火墙冗余与高可靠性主备方式或负载均衡方式为了支持业务无损的故障保护，防火墙冗余需要支持路由备份和数据备份。热备的防火墙工作在混合模式下，通过透明模式的接口接收和发送业务报文，用以完成网络应用；通过路由模式的接口传送VRRP、VGMP和HRP报文，用以维护防火墙的主备关系VGMP:HRP:RDMP:在防火墙组网中，通过配置VRRP备份组或RDO的优先级可以调整防火墙的工作模式。例如，如果所有VRRP备份组都在单台防火墙上具有多优先级，那么防火墙就运行在主备模式；如果调整VRRP备份组优先级让主用备份组分布在不同主机上，那么防火墙就运行在负载均衡模式。设计参考：交换机冗余与可靠性为提高可靠性一般采用设备冗余〔即双星形拓扑〕，并在冗余交换机之间实现互联。交换机冗余通常会带来交换网络循环的问题，一般使用STP在交换网络中产生一条无循环的转发路径。为了实现交换机之间VLAN信息互通和链路共享，一般需要建立L2Trunk〔端口聚合〕，此时交换机间相互连接的端口称为Trunk口。当交换机链路、端口或故障时，局域网可通过路由协议进展重路由修复。对于使用GE光口进展trunk互连的交换机双机，应重点关注Trunk单通故障。GE光纤单通时两端的光信号并未完全中断，局部交换机将无法检测该故障，造成业务中断，常用的检测保护方法是采用自协商GE光口模式或DLDP、UDLD等协议。对于作为静态配置缺省网关的第三层交换机，为提高可靠性可使用VRRP虚拟路由器冗余协议。管理/维护网络、业务网络、数据备份网络、数据同步网络之间应当隔离，管理/维护网络、数据备份网络发生故障不应影响到用户业务的正常进展，更不应导致业务网络瘫痪。应用系统内部，网络隔离使用VLAN，屏蔽安全等级不同的各网络区域，对于需要从外部接入的维护节点，常用的隔离技术包括：防火墙，屏蔽外部接入节点的地址X围，并通过NAT防止对外暴露内部节点的IP地址;双网卡，支持外部接入访问的网络节点分别使用不同的网卡分别连接内部业务网络和外部维护网络；必要时，可以使用网关网元隔离外部接入网络与内部业务网络。上述隔离技术的核心是防止网络节点在故障状态下非法访问或冲击无关的其它网元，隔离局部故障对整个系统的影响。案例：IP地址冲突引发全网中断案例改良措施：对核心网交换机虚拟IP的MAC地址进展绑定，对系统关键服务器的IP地址进展MAC绑定，防止IP地址冲突。在核心网交换机上配置专用的维护网口和网段。划分维护专用VLAN防止接入维护网络时影响全网业务。设计参考：抵抗网络消息风暴网络风暴包括广播风暴，HRP风暴和拒绝服务攻击。常见的可靠性改良措施包括网络流量监控和VLAN隔离。[此处原文为广播定义，广播包类型，例子广播风暴定义]原因：网络设备、网卡损坏，网络环路，病毒攻击。广播风暴保护措施：网络监控〔每秒广播包平均数变化趋势：每秒广播包数量突增。网络利用率监控：快速以太网带宽利用率一般不会80%。Sniffer等工具支持上述监控和告警功能〕或VLAN隔离。ARP风暴是网络风暴的一种，同拒绝服务攻击一样，一般与网络安全有关。业务主机、数据库主机必须采用集群或双机冗余设计。根据内存会话等运行数据的同步和备份关系，双机可以分为冷备、温备、热备等方式，热备是指备用单元与主用单元处理一样的业务，但不产生有效输出；温备是指备用单元备份主用单元上必要的信令和业务，倒换时业务可能会受到轻微影响，一般稳态业务不中断；冷备是指备用单元上电，但不备份主用单元的信令和业务，倒换时已建立的会话会中断。冷双机：共享数据库存储、主备应用不同步：图SEQ图\*ARABIC3热双机：采用内存数据库同步应用数据heartbeat管理内存数据库与其它资源备机应用进程不处理业务图SEQ图\*ARABIC4常见双机系统可采用的心跳冗余配置：Linux+HA集群：心跳冗余方式：以太网+串口同时检测主备通信链路状态，同时LinuxHA把心跳消息看成是控制消息的特例，采用接收者发起的模式时行重传，来确保消息的可靠传递。并且，通过计时器来限制每秒重传消息包的次数，防止发送者因为请求重传的次数过多而发生内爆，导致发送者负载过高。HPServiceGuard:心跳冗余方式；冗余IP网络+锁盘+串口通过主LAN和专用LAN提供冗余心跳，二者都传输心跳。如果用于数据〔心跳线〕子网的主局域网卡出现故障，ServiceGuard将执行本地切换，切换到同一节点上的备用局域网卡上。专用心跳线LAN不需要本地切换。ServiceGuard支持使用串口线〔RS232〕传输心跳，只能在双节点集群配置使用。在仅拥有一个心跳心跳线LAN的双节点集群中，串行心跳线是必需的。如果至少拥有两个心跳线LAN,或者一个心跳线LAN和备用LAN，如此不应使用串行心跳线。图SEQ图\*ARABIC5HP集群心跳冗余LAN设计设计参考：VCS冗余心跳网络将导致双机机制失效设计层面对双机心跳的增强包括：监控心跳网卡，心跳网卡故障时告警并与时更新；配置I/Ofencing功能，在只存在单条心跳链路的情况下，仍然能够通过抢占磁盘的方式确定主备用节点。设计参考：双机故障检测和切换设计系统监控X围：所有关键进程、关键系统资源〔数据库,文件,文件系统，网卡，IP,卷系统,裸设备等〕都进展状态监控，在异常时自动重启或触发切换。所有异常应记录日志。对于需人工修复的故障上报告警。监控的容错设计：对关键应用的监控应考虑各种异常情况。比如：PS监控的选项和项目需要考虑用户是否会手工修改配置导致出现新的同名进程〔比如用vi编辑与监控进程局部同名的文件〕或shell中执行通过管道执行会fork新的子进程，而这些子进程可能与被监控的进程局部同名。数据备份关系：主备系统中，主备机之间的同步率决定了备机任意时刻的更新程度。也决定了系统恢复速度。由于突发故障中断了主备机间的通信，备机数据同步可能无法完成，将导致信息失配。新的处于工作状态的部件和系统中其它部件间的交互必须从这种失配中恢复过来，防止引发问题。数据同步关系：双机热备方式中，主备机存在数据同步关系。局部双机软件对同步时长有要求，如果超过10秒无响应即认为同步关系断裂会关闭备机。而有时双机切换时主机退出或者备机启动时间较长会导致切换失败。设计改良中需跟踪各种条件综合分析。判断同步关系断裂的条件不公包括响应时长，还需要包括主机状态、业务可用状态等信息。这些信息可以通过心跳消息在双机中传递。故障切换的容错设计；双机切换时，会有主机应用退出和备机应用启动的过程。主机应用退出有时会因为记录日志或其他功能访问文件系统。此时需要有异常判断或超时机制，防止因为磁盘陈列卡损坏等原因触发切换时主机应用已无法正常访问文伯系统导致吊死。另外一个典型案例是磁盘阵列与主机完全断连时，oracle无法正常停止，这时必须进展特殊的容错处理，查找将数据库shutdownabort才能切换。共用部件状态：双机运行或切换时，必须对共用部件〔比如双机冷备的共用数据库，HP双机ServiceGuard中的锁盘〕进展状态检查。在共用部件异常时，或必要时重启操作系统等方式保证共用部件正常，备机接收后能正常运行。备机接收过程中需要特别注意共享资源的故障检测与容错保护，防止因备机加载资源失败导致切换失败。双机切换通常在故障条件下发生，由于HBA、磁盘等故障，资源释放可能出现吊死，导致原主机无法成功退出，备机接收资源失败等故障。必须对资源释放过程时行监控，超时后采取更强制性的措施；强制释放失败时，应能够重启系统，确保备机接收。Heartbeat双机只能通过stop停止资源，脚本需要自行处理吊死判断，一般做法是使用nohup执行停止资源的脚本，并循环检测资源是否停止，如超时如此使用Kill-9直接杀死，如果仍然超时可使用reboot重启主机，确保备机接收。2.2.6HA集群分裂和保护集群系统内部网络故障，各节点间通信中断，如果设计不当可能会导致多主、多备等异常情况，甚至多台主机同时访问存储的数据，造成数据破坏。常见的改良设计包括客户网络可用性检测、节点仲裁与有效性保证、共享存储冲突保护等多种措施。设计参考：ipfail机制保护主机业务网络故障的可靠性设计集群系统中，IP接收和资源接收并不能保证业务的可用性。例如，如果只是主机与客户机之间的网络发生故障，这时因为heartbeat配置完好，心跳信号正常，不会发生失效接收，然而客户机却无法访问主机，系统业务中断。LinuxHA对此的机制是采用ipfail技术，即使用ipfailAPI插件在HeartBeat配置文伯中指定一个或多个ping服务器，如果主机无法ping通其中一个服务器，会询问备机：“Didyouseethatpingservergodowntoo？〞如果备机能ping到这个服务器，如此备机会知道主机的网络通信不正常，会触发失效切换。设计参考：SunPlex防止集群分区的可靠性设计集群分割失忆仲裁和仲裁设备故障保护设计参考：VS防止SplitBrain的可靠性设计LowPriorityLinkDiskreservationsI/OFencing设计参考：通过fencing技术保护共享意象派访问冲突1)shoottheothernodeinthehead2)selfFencing需要考虑故障切换时如何保持会话，实现故障切勿不中断稳态业务设计参考：BMS系统使用checkpoint技术双机切换不中断业务当IPQAM资源分配情况变化时，逻辑日志线程将相应的操作记录保存到逻辑日志中。当逻辑日志达到指定大小或定时器到期后，check线程会根据前一次的checkpoint数据和新增的逻辑日志生成最新的checkpoint数据，即当前的IPQAM资源分配状况。SRM子系统恢复时会从DBIP获取最近一次的checkpoint数据与其后的逻辑日志，并根据这两次内容重新生成SRM停止服务时刻的资源分配状况，从而保证SRM资源分配的延续性，保证了BMS系统的高可用性。5.2支持数据一致性校验与同步措施：分布式事务定期校验重传。6.1.5流控算法过载窗口：CPU占用率上升到80%时，30%－50%丢弃率？CPU占用率下降到60%时，50%－30%丢弃率？看报文过载控制高价值业务优先处理简化流程消息超时时间/单个消息处理时长设计参考：ACID,CAP与BASEACID:Atomicity，consistency，Isolation，DurabilityCAP:Consistency,Availability，ToleranceofNetworkPartition分区容忍性〔在网络局局部裂故障下系统仍能正常工作〕BASE:BasicallyAvailable:根本可用。Softstate:软状态，柔性事务EventualConsistency:最终一致性。设计参考：幂等性：幂等性的前提是不以时间为转移。支持幂等性的有两个设计模式：SyncronizedToken：序列化令牌，保证每个会话具有唯一的令牌以防止重复提交，唯一令牌通常根据用户会话ID和当前系统时间生成IdempotentReceiver〔幂等接收器〕：通过核对输入消息的唯一消息ID来保证，只有拥有唯一ID的消息才能被服务接收，消息ID需要持久化，用于追踪哪些消息已经处理过。7.1支持独立、可靠的信息采集与监控“独立〞的信息采集模块指第三方工具和程序。如果产品自主开发，其功能应与业务处理模块使用不同的进程实现，一方面信息采集和监控模块故障不影响正常业务提供，另一方面业务模块的故障也能被正常的检测和告警。设计参考：对监控进程或模块自身的故障检测和恢复监控模块是系统正常运行的守护者，对于与时发现故障，缩短系统中断时间有重要意义。系统应支持对监控进程或模块自身的故障监测和恢复。当监控进程出现资源占用超限、异常退出等故障时，应能够对监控进程进展重启恢复。对监控进程进展监控的常用方法有：通过双机脚本监控监控进程；通过与OAM系统的配合监控业务系统监控进程；监控进程通过子进程或精灵进程〔由于监控监控进程的进程功能单一，一般认为可靠性较高,或者与监控进程相互监控〕实现自我监控等。设计参考：CTI网络故障检测机制TopEng智能呼叫中心各服务器间ICDm进展通讯，而ICDm底层单用的是TCP/IP协议。当系统出现故障时，可以使用NetCheck检测TCP/IP协议协议的通讯是否异常，从而定位故障是网络问题还是呼叫中心部件本身问题。如果TCP/IP协议通讯异常，可将出现的故障定位为网络问题。如果TCP/IP协议通讯正常，可将出现的故障定位为CTI平台本身部件问题。与NetCheck基于ICDm检测的机制相似，CTI进程本身也实现了对网络连接性的检测：将ICDm通讯中非本机IP消息包数量进展累加,每3秒统计一次，如果数量为0如此认为承载网连接已中断，上报告警。设计参考：对关键消息收发接口进展消息失衡检测消息收发比例不仅包括本地接口收发比例，也可包括链路两端的收发比例。对于消息收发数量具有特定比例的接口，检测收发消息数量是否符合比例是常见的方法。此外，通过监控接口消息收发比例还可检测出双向接口单通的故障。网络设备包括负载均衡器，交换机，路由器。要求对网络设备与关键部件提供监控确保与时发现设备本身的可用性故障，以与当设备关键部件或其备件发生故障时能迅速告警。对设备可靠性监控的方法：利用SNMPTRAP能力利用设备的TELNET/SSH接口很多设备都对外开放TELNET/SSH接口，通过这类接口的API，可获取设备的一些信息，包括设备异常各故障信息。阵列：阵列控制器〔一般电池故障较多〕、陈列卡、磁盘采用数据库可用性监控，IO监控等方式，可有效监控阵列故障。案例：HP主机对温度和风扇系统的监控与统计7.4数据库与中间件故障监控数据库的可用性：数据库服务中断〔吊死、软件中BUG、服务器宕机、阵列连接故障〕性能故障〔索引，服务器易超限等原因导致数据库响应缓慢〕。设计参考：SUN双机的数据库检测机制Suncluster的oraclefaultmonitoragent的工作原理是：当oracle数据库运行在hwhlr-ph1机器上时，Suncluster的oraclefaultmonitoragent在hwhlr-ph2机器上，定时利用oracle数据库用户gsm通过公网用SQL登录到hwhlr-ph1机器上的oracle数据库，创建一个表，查询这个表，删除这个表，根据运行结果来判断oracle数据库是否运行正常，假如出现错误，根据oracle数据库出错信息，查询/etc/opt/sunwscor/haoracle-config-v1文件，根据文件配置，决定对oracle数据库重起、切换、还是不采取行动。一般情况下数据库检测的参数配置为：循环检测时间间隔20S，检测次数2次，检测超时60S，重启延时300S。图SEQ图\*ARABIC11设计参考：通过web服务映射间接监控数据库可用性MDSP双机脚本通过web服务映射机制监控后台数据库的可用性，telnet到本地端口，并向其中的指定url发送get请求，最后检查web服务返回的文中是否有预先设定的关键字。7.4.2数据库关键资源监控数据库关键资源包括：表空间，日志空间、数据表空间、连接数、锁资源数。设计参考：Inforix重大事故和断言错误即时抓获和警告处理案例：缺乏内存表和物理表一致性检测机制导致升级失败的重大中断事故改良措施：平台引入关键资源监控机制，每10分钟刷新一次内存数据表，主动同步数据库表与内存数据，发现数据库表丢失、数据错误等异常立即告警设计参考：oracle数据库UNDO空间占用率监控系统容量增加或应用侧SQL操作不当时，可能会导致大量事务或长时间未提交导致的undo空间占用，造成新的访问申请不到undo空间而全部超时导致业务失败，因些有必要监控undo空间的active占用率并告警或预警。设计参考：informix数据库索引状态的检测informix数据库具备记录“全表扫描〞次数的能力，发现某X数据量的表在最近一段时间内发生全表扫描时，认为该表索引出现问题，触发告警设计参考：两阶段锁监控由于业务系统复杂，涉与多个数据库操作的均采用分布事务控制数据一致性，两阶段锁问题不能完全防止。修改方案：在数据库端部署程序，每隔5分钟检查数据库锁的情况，一旦发现两阶段锁，通过短信与时告警给DBA或局方维护人员，人工分析后，手工去除。7.4.3web服务中间件故障监控设计参考：对Tomcat/oss的故障监控方案BMPMonitor监控程序是一个独立于oss单独运行的进程，是为了发现oss提供服务的异常状态，与时发现并重启oss。BMPMonitor对oss的检测包括对Tomcat端口状态、数据库状态、oss连接池状态的检测，每次检测的时间间隔为5S。Tomcat端口检测：Tomcat端口异常的话，系统默认检测3次，间隔时间3S，三次都失败了如此认为失败，重启oss进程。数据库状态检测：Monitor将使用JDBC去连接数据库，如果检测失败，如此记录日志，不会重启oss。oss连接池检测：默认连续检测3次，间隔时间3S，三次都失败如此认为检测失败，进入重启流程。当JPM出现内在泄漏时，在物理内存配置较小的情况下会造成交换分区频繁换页引起JVMGC时间超长，oss僵死导致Monitor程序误判，检测oss时间延长到5秒一次。ossMonitor和双机监控需协同工作，防止双机切换减小业务中断时间。检测到oss异常时，优先通过重新拉起方式迅速恢复业务，减少双机切换的机率；双机监控脚本分别检查ossmonitor和oss进程状态，只有在ossMonitor进程退出并且oss异常时才会进展双机切换。7.5系统资源故障监控关键系统资源包括：CPU、内存、磁盘空间、交换空间、网络I/O、磁盘I/O、系统句柄、单目录内文件数、文件系统中iNode数等。系统资源包括系统级资源和进程级资源两种。CPU占用率包括：CPU整体占用率、单CPU占用率、单核占用率监控方法：proc文件系统，sar命令等CPU占用率超限不仅要报警，还应采取适当的保护措施，比如暂时拒绝新请求、重启占用率过高的进程，等等。设计参考：CPU主要负载指标CPU主要负责进程/线程和中断两种资源的调度，进程又分为内核进程和用户进程。与CPU负荷相关的主要指标包括上下文切换〔context〕、运行队列〔runqueue〕和占用率(utiliation)。CPU占用率分为4种：用户时间、系统时间、等待I/O时间、空闲时间。一个正常系统预期达到的性能指标包括：每个处理器上的运行队列不超过3个线程，例如双核处理器的运行队列不6个线程；对于充分利用的CPU，其利用率比例通常为：65%~70%用户时间30%~35%系统时间0%~5%空闲时间过高的I/O时间意味着I/O或内存过载，过高的系统时间说明系统已超过负荷。3上下文切换的数目直接关系到CPU的使用率，如果CPU的使用率保持在上述均衡状态，大量的上下文切换也是正常的，但通常上下文切换的数量要小于中断的数量。以vmstat命令为例。其输出信息中与CPU负荷相关的包括：r:当前运行队列中线程数，代表线程处于可运行态但CPU还未能执行;b:当前并等待I/O完成的进程的数目;in:当前中断被处理的数目;cs：当前系统中发生上下文切换的数目;us:CPU占用率中用户时间所占百分比;sy:CPU占用率中系统时间所占百分比;wa:CPU占用率中I/O等待时间所占百分比;id:CPU占用率中空闲时间所占百分比。mpstat可以给出每个独立芯片的CPU运行统计指标。设计参考：数据域monitor的CPU占用率监控设计方案Monitor监控工具检测主机系统总的CPU占用率超过可配置限额会触发告警，每个线程都有自己的临界值〔可配置〕和持续时间〔分钟级，可配置〕，当检查单个进程CPU占用率持续超过预设时间后即判断该进程出现故障，自动将其杀死并重新拉起。7.5.2系统内存占用率动态检测系统内存占有率包括以下几种：物理内存利用率广义物理内存利用率〔物理+交换空间〕内存换页频率页面错误率其中物理内存监控明确了物理内存耗尽大量页面交换操作之前的系统状态，内存换页频率明确了内存申请和使用效率，需要重点关注。系统内存的监控方法包括vmstat、sar命令、proc虚拟文件系统等方式。系统必须明确给出具体的内存占用率指标，建议值60%等等。设计参考：内存主要负荷指标现在操作系统都采用基于页面管理的虚拟存储系统机制，用户进程在虚拟存储空间上运行，以页为根底分配单位〔页大小各操作系统不一定一样〕。虚拟存储空间由物理内存空间+交换空间构成。通常我们说的内存，狭义上是指物理内存，即RAM。通过内存占用率和内存换页频率的监控可以分别检测物理内存和虚拟内存的使用情况。Linux系统中，kswapd进程负责确保内存空间总是在被释放中，它监控内核中的pages-high和pages-low阈值，如果空闲内存的数值低于pages-low如此进程启动扫描并尝试释放32个空闲页面，并且一直重复这个过程直到空闲内存的数值高于pages-high。而pdflush进程负责将内存中的内容和文件系统进展同步操作，也就是说，当文件在内存中修改后，pdflush将负责写回到磁盘上。内存的过载通常表现为交换空间的繁忙，以vmstat命令为例，其输出信息与内存指标相关的包括〔单位都为KB〕：swpd：当前虚拟内存使用总额;free:物理内存中当前使用的空间;buff:当前物理内存中用于读写的缓冲区大小;cache：当前物理内存中映射到进程地址空间的大小;so;写入交换空间的字节总数;si:从交换空间写回内存的字节总数;bo:从物理内存到文件系统或交换空间掏出的页面数;bi:从文件系统或交换空间换入物理内在的页面数。设计参考：数据域Monitor的内存监控设计方案对于进程内存检测，Monitor采用定时策略，默认在每天2:00进展检测。如果发现进程内存占用超过控制门限〔默认1G〕,如此Monitor通知业务进程内存占用过高。业务模块需要控制用户接入并处理完内存数据。如果处理完毕，业务模块进程可以自行退出，或Monitor将业务进程进展重启。如果连续15分钟还没处理完毕，如此Monitor认为业务模块进程异常，强制进展重启。设计参考：内存换页频率异常检测设计方案为了检测内存是否足够，OAM系统实现“内存换页频率异常〞的告警，此告警支持自动恢复。内存换页频率通过PageIn和PageOut计算。Solaris8，pi和po包括Executable，Auonymous和FileSystem三种，可以使用vmstat-p查看。在solaris8中，内存被4种业务消耗：内核、进程、严密共享内存和文件系统高速缓存，内存的一个最大消耗者是文件系统高速缓存机制，读写文件都需要在内存中缓存该文件。由于solaris8所有文件系统I/O都是通过页面调度机制处理的，因此观察到大量的页调入(fpi)和页调出(fpo)完全是正常的。在系统检测设计中，使用vmstat-p的输出作为判断依据，如果sr.api和apo持续非0，如此认为内存不足，其中sr是页面进程的扫描速度活动，以每秒多少页面表示，这是最重要的表示内存缺乏的指示器。api和apo分别表示anomymousmemoryins和anonymousmemeoryouts。Auonymouspages包括应用程序和堆栈。实现内存不足预警的具体设计如下：vmstat-p命令每5秒来获取sr.api和apo字段的值，保存到一个文件中，对最近的30条数据进展处理，分别计算sr.api、apo的值不为0的个数，如果它们的和大于60，就上报内存不足告警。案例：单个目录下文件个数过多影响性能7.5.5磁盘空间占用率动态检测具体的磁盘空间占用率阀值指标，超限时不仅要告警，还要采取适当的保护策略：暂停日志记录、将日志改成绕接方式、将数据转移到其它磁盘空间等等。7.5.6系统交换空间占用率监控swap空间主要用于匿名内存数据的交换〔系统内存中的读写文件和可执行文件会直接交换到文件系统，而通过malloc/new等函数分配对象的数据如此交换到swap空间，因为它们在文件系统中没有对应的实体文件〕。必须明确给出具体的交换空间超限指标，典型值为50%。交换空间监控命令：swap-s(SUN)lsps-s(AIX)wsapinto-at(HP-UX)cat/proc/meminfo(Linux2.x)虚拟swap空间与/tmp目录有很大关系，许多应用程序，特别是数据库服务都会频繁使用/tmp目录作为临时数据保护区。保护措施：在mount/tmp目录时，使用〔-osize〕选项控制tmp目录的大小，编译文件时，将TMPDIP环境变量指向其它临时目录而非tmp目录等等。案例：Windows系统中句柄耗尽引发系统内在泄漏文件描述符数量查看：lsof–pPID/proc/PID/fd案例：Linux单进程使用文件描述符的默认限制：Linux下默认一个进程只能使用1024个文件描述符,如果超出1024个，创建时会失败；2使用select()API的时候传入大的文件述符〔大于1024〕会出现溢出情况，出现segmentfault错误。对于1024个文件描述符的限制，通过修改系统文件/etc/security/limits.conf来消除Linux的限制；在使用select()的时候传入大的文件描述符〔大于1024〕可以使用poll()代替select()。7.6.1业务成功率和服务质量监控业务成功率是指提供应用户的业务能否完整的满足用户的使用需求。mms中，Monitor通过检测业务日志的方式实现对业务状态的监控，可以监控的项目包括日志格式、单位时间段内业务量等等。业务可用性是指业务能否被终端用户访问。对最终用户提供服务的检查必须是自动进展的，当业务异常时，应有告警或必要的保护措施。除了直接模拟请求报文的方式检查可用性，还可检查话单和日志文件的输出时间或更新时间。设计参考：基于健康检测的服务器监控软件设计设计参考：业务过载指标确实定：cpu占用率内存占用率；业务处理平均时间缓冲区数据的堆积情况其中1和2是产品整体，3和4是单个业务的负载。通常情况下CPU占用率为60%，取5秒平滑值比拟合理。尽量保证数据库故障时系统根本业务可用，因数据库故障是发生频率最高的故障之一。设计参考：CC&CRM数据库中断设计方案呼叫中心114查询中断方案：数据本地缓存设计，数据库中断时，业务记录自动到话务员本地磁盘，数据库恢复后自动导入数据库。数据本地备份设计：数据库中数据定时备份保存在本地磁盘，并建立本地全文索引。图SEQ图\*ARABIC10“单表查询〞“file〞设计参考：IIN简易流程数据库放通设计方案。数据库故障时SCP处于瘫痪状态，引起大量呼叫中断事故。S