华为高可靠性设计指导手抄本.docx
《华为高可靠性设计指导手抄本.docx》由会员分享，可在线阅读，更多相关《华为高可靠性设计指导手抄本.docx（26页珍藏版）》请在冰点文库上搜索。
华为高可靠性设计指导手抄本
1
图1
《软件公司地理容灾设计指导书》
基于EMC磁盘陈列的硬件数据复制也能实现数据层面的容灾。
TELLIN容灾系统对信令的切换控制根据网络配置的不同，主要支持备用信令点模式和GT翻译路由模式。
备用信令点模式由SCCP检测信令点的状态自动实现信令业务的转接；GT翻译路由模式通过修改STP上的GT翻译数据实现信令的切换。
图2
TELLIN的CDR容灾和GDR容灾组网示意图
设计参考：
支持动态资源管理的BOSS双中心系统
双中心配置，业务负荷分担设计，每个中心同时承载对方中心的备份业务，实现了基于虚拟化的动态资源调整技术，即一台物理主机划分成假如干个分区，每个分区有独立的操作系统，系统管理员可以自由添加、删除或分区间移动系统资源.例如CPU、内存、I/O适配器的分配，而不需要重新启动系统。
在主机、分区和业务的分配上，设计为：
1）物理主机分为多个分区；2）将同一业务中一个中心主用端和另一个中心备用端部署到同一台物理主机；3）同一主机所在分区承载业务为关键与非关键搭配；4）将主机剩余的资源和局部备用资源统一放在预留资源中；5）同一主机的预留资源可以灵活在生产局部和备份局部之间动态调整。
对于突发的资源需求或者定期的资源需求，可以动态调整资源，以保证系统运行稳定。
1.3网络冗余容错
要求单条链路存在故障时，整个网络系统不失效。
网络提供的业务仍是根本可用或者网络可以降级运行。
设计上，要求在组网上对网络节点之间的链路提供冗余。
冗余方式可以通过网元之间的直接并行连接，也可以通过其也网络节点迂回实现，并要求主备用链路经过不同的物理连接。
设计参考：
设备冗余组网
路由器、防火墙、负载均衡器、局域网交换机、光纤交换机等网络设备全部采用冗余设计。
主机上，所有业务主机采用冗余，非关键服务器使用单机。
网络连接冗余设计主要保证单个网络连接异常或接口卡故障时，设备之间仍有备用通道可以正常访问。
具有多个网络接口的网络适配器在整个适配器出现故障时会成为单点故障。
为了获得最高的可用性，集群配置时应确保两上节点间的唯一路径不依赖一个网络适配器。
设计参考：
路由器冗余与高可靠性
在两个层面实现；一种是通过对主机进展某种设置，当主机在访问主路由器失败时能够查找并切换到备用路由器；一种是路由器自身组成高可用性的集群，通过浮动IP等机制对外提供服务。
需要主机主动参与切换的路由器备份技术有：
●ProxyARP:
切换时间长
●IRDP（ICMPRouterDiscoveryProtocol）
●动态路由：
RIP/RIP2,OSPF:
缺点是主路由器与备份路由器间的转换较慢。
其它一些技术支持路由器集群或主备路由器间透明快速地切换：
●HSRP
●VRRP：
RFC2338
●GLBP
设计参考：
防火墙冗余与高可靠性
主备方式或负载均衡方式
为了支持业务无损的故障保护，防火墙冗余需要支持路由备份和数据备份。
热备的防火墙工作在混合模式下，通过透明模式的接口接收和发送业务报文，用以完成网络应用；通过路由模式的接口传送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风暴是网络风暴的一种，同拒绝服务攻击一样，一般与网络安全有关。
业务主机、数据库主机必须采用集群或双机冗余设计。
根据内存会话等运行数据的同步和备份关系，双机可以分为冷备、温备、热备等方式，热备是指备用单元与主用单元处理一样的业务，但不产生有效输出；温备是指备用单元备份主用单元上必要的信令和业务，倒换时业务可能会受到轻微影响，一般稳态业务不中断；冷备是指备用单元上电，但不备份主用单元的信令和业务，倒换时已建立的会话会中断。
冷双机：
共享数据库存储、主备应用不同步：
图3
热双机：
1.采用内存数据库同步应用数据
2.heartbeat管理内存数据库与其它资源
3.备机应用进程不处理业务
图4
常见双机系统可采用的心跳冗余配置：
Linux+HA集群：
心跳冗余方式：
以太网+串口
同时检测主备通信链路状态，同时LinuxHA把心跳消息看成是控制消息的特例，采用接收者发起的模式时行重传，来确保消息的可靠传递。
并且，通过计时器来限制每秒重传消息包的次数，防止发送者因为请求重传的次数过多而发生内爆，导致发送者负载过高。
HPServiceGuard:
心跳冗余方式；冗余IP网络+锁盘+串口
通过主LAN和专用LAN提供冗余心跳，二者都传输心跳。
如果用于数据〔心跳线〕子网的主局域网卡出现故障，ServiceGuard将执行本地切换，切换到同一节点上的备用局域网卡上。
专用心跳线LAN不需要本地切换。
ServiceGuard支持使用串口线〔RS232〕传输心跳，只能在双节点集群配置使用。
在仅拥有一个心跳心跳线LAN的双节点集群中，串行心跳线是必需的。
如果至少拥有两个心跳线LAN,或者一个心跳线LAN和备用LAN，如此不应使用串行心跳线。
图5
HP集群心跳冗余LAN设计
设计参考：
VCS冗余心跳网络将导致双机机制失效
设计层面对双机心跳的增强包括：
监控心跳网卡，心跳网卡故障时告警并与时更新；配置I/Ofencing功能，在只存在单条心跳链路的情况下，仍然能够通过抢占磁盘的方式确定主备用节点。
设计参考：
双机故障检测和切换设计
1.系统监控X围：
所有关键进程、关键系统资源〔数据库,文件,文件系统，网卡，IP,卷系统,裸设备等〕都进展状态监控，在异常时自动重启或触发切换。
所有异常应记录日志。
对于需人工修复的故障上报告警。
2.监控的容错设计：
对关键应用的监控应考虑各种异常情况。
比如：
PS监控的选项和项目需要考虑用户是否会手工修改配置导致出现新的同名进程〔比如用vi编辑与监控进程局部同名的文件〕或shell中执行通过管道执行会fork新的子进程，而这些子进程可能与被监控的进程局部同名。
3.数据备份关系：
主备系统中，主备机之间的同步率决定了备机任意时刻的更新程度。
也决定了系统恢复速度。
由于突发故障中断了主备机间的通信，备机数据同步可能无法完成，将导致信息失配。
新的处于工作状态的部件和系统中其它部件间的交互必须从这种失配中恢复过来，防止引发问题。
4.数据同步关系：
双机热备方式中，主备机存在数据同步关系。
局部双机软件对同步时长有要求，如果超过10秒无响应即认为同步关系断裂会关闭备机。
而有时双机切换时主机退出或者备机启动时间较长会导致切换失败。
设计改良中需跟踪各种条件综合分析。
判断同步关系断裂的条件不公包括响应时长，还需要包括主机状态、业务可用状态等信息。
这些信息可以通过心跳消息在双机中传递。
5.故障切换的容错设计；双机切换时，会有主机应用退出和备机应用启动的过程。
主机应用退出有时会因为记录日志或其他功能访问文件系统。
此时需要有异常判断或超时机制，防止因为磁盘陈列卡损坏等原因触发切换时主机应用已无法正常访问文伯系统导致吊死。
另外一个典型案例是磁盘阵列与主机完全断连时，oracle无法正常停止，这时必须进展特殊的容错处理，查找将数据库shutdownabort才能切换。
6.共用部件状态：
双机运行或切换时，必须对共用部件〔比如双机冷备的共用数据库，HP双机ServiceGuard中的锁盘〕进展状态检查。
在共用部件异常时，或必要时重启操作系统等方式保证共用部件正常，备机接收后能正常运行。
备机接收过程中需要特别注意共享资源的故障检测与容错保护，防止因备机加载资源失败导致切换失败。
双机切换通常在故障条件下发生，由于HBA、磁盘等故障，资源释放可能出现吊死，导致原主机无法成功退出，备机接收资源失败等故障。
必须对资源释放过程时行监控，超时后采取更强制性的措施；强制释放失败时，应能够重启系统，确保备机接收。
Heartbeat双机只能通过stop停止资源，脚本需要自行处理吊死判断，一般做法是使用nohup执行停止资源的脚本，并循环检测资源是否停止，如超时如此使用Kill-9直接杀死，如果仍然超时可使用reboot重启主机，确保备机接收。
2.2.6HA集群分裂和保护
集群系统内部网络故障，各节点间通信中断，如果设计不当可能会导致多主、多备等异常情况，甚至多台主机同时访问存储的数据，造成数据破坏。
常见的改良设计包括客户网络可用性检测、节点仲裁与有效性保证、共享存储冲突保护等多种措施。
设计参考：
ipfail机制保护主机业务网络故障的可靠性设计
集群系统中，IP接收和资源接收并不能保证业务的可用性。
例如，如果只是主机与客户机之间的网络发生故障，这时因为heartbeat配置完好，心跳信号正常，不会发生失效接收，然而客户机却无法访问主机，系统业务中断。
LinuxHA对此的机制是采用ipfail技术，即使用ipfailAPI插件在HeartBeat配置文伯中指定一个或多个ping服务器，如果主机无法ping通其中一个服务器，会询问备机：
“Didyouseethatpingservergodowntoo？
〞如果备机能ping到这个服务器，如此备机会知道主机的网络通信不正常，会触发失效切换。
设计参考：
SunPlex防止集群分区的可靠性设计
1）集群分割
2）失忆
仲裁和仲裁设备
故障保护
设计参考：
VS防止SplitBrain的可靠性设计
1）LowPriorityLink
2）Diskreservations
3）I/OFencing
设计参考：
通过fencing技术保护共享意象派访问冲突
1）shoottheothernodeinthehead
2）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与BASE
ACID:
Atomicity，consistency，Isolation，Durability
CAP:
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如此认为承载网连接已中断，上报告警。
设计参考：
对关键消息收发接口进展消息失衡检测
消息收发比例不仅包括本地接口收发比例，也可包括链路两端的收发比例。
对于消息收发数量具有特定比例的接口，检测收发消息数量是否符合比例是常见的方法。
此外，通过监控接口消息收发比例还可检测出双向接口单通的故障。
网络设备包括负载均衡器，交换机，路由器。
要求对网络设备与关键部件提供监控确保与时发现设备本身的可用性故障，以与当设备关键部件或其备件发生故障时能迅速告警。
对设备可靠性监控的方法：
1）利用SNMPTRAP能力
2）利用设备的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。
图11
设计参考：
通过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。
1.Tomcat端口检测：
Tomcat端口异常的话，系统默认检测3次，间隔时间3S，三次都失败了如此认为失败，重启oss进程。
2.数据库状态检测：
Monitor将使用JDBC去连接数据库，如果检测失败，如此记录日志，不会重启oss。
3.oss连接池检测：
默认连续检测3次，间隔时间3S，三次都失败如此认为检测失败，进入重启流程。
当JPM出现内在泄漏时，在物理内存配置较小的情况下会造成交换分区频繁换页引起JVMGC时间超长，oss僵死导致Monitor程序误判，检测oss时间延长到5秒一次。
ossMonitor和双机监控需协同工作，防止双机切换减小业务中断时间。
1.检测到oss异常时，优先通过重新拉起方式迅速恢复业务，减少双机切换的机率；
2.双机监控脚本分别检查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时间、空闲时间。
一个正常系统预期达到的性能指标包括：
1.每个处理器上的运行队列不超过3个线程，例如双核处理器的运行队列不6个线程；
2.对于充分利用的CPU，其利用率比例通常为：
a）65%~70%用户时间
b）30%~35%系统时间
c）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系统内存占用率动态检测
系统内存占有率包括以下几种：
●物理内存利用率
●广义物理内存利用率〔物理+交换
升级会员 