四大要点管理维护双机热备系统

理解双机热备，必须要认清这样几点：

    1. 对于一台服务器而言，坏的可能总是存在的。故障的原因多种多样，包括硬件、软件、人为故障等，任何一个环节都有可能发生。
    2. 服务中断不仅可能发生在管理员在的时候，也可能发生在机房空无一人的时候，而一台跑着应用系统的数据库服务器，并不是很容易就能恢复的。
    3. 数据备份当然是重要的数据保护措施，但只是事后的解决方法，无法预防应用停止。
    4. RAID只能解决硬盘的问题，解决不了服务器的问题。

    当然如果系统中没重要应用，我们没必要考虑双机热备。或者我们可以容忍应用系统停止运行一天，双机系统也并非十分重要。但是，如果应用停上一个小时就会带来严重的问题，那么就无疑应该考虑一下双机系统，而如果业务系统停上十分钟都难以承受，这时候双机热备方案就是必须的了。

    双机系统实际上是服务器应用的冗余备份，但是因为通常采用外置磁盘阵列存储数据，因而企业可以更方便集中的对数据进行管理和备份，从而进一步提高整个系统的效率和可用性。当一台服务器上的应用发生故障时，系统可以方便无缝的切换到另外一台服务器，承担起原有该服务器所承担的大部分应用，从而保证业务的不停顿运行。最重要的是，整个切换过程是自动进行的，前端几乎很难察觉到后台的服务器系统的故障。

    双机热备系统本身已经是较为稳定的系统，这表现在双机热备系统已经具备了一定的抗风险能力，但是双机热备系统也意味着更复杂的管理、维护和升级工作。因此，在这里，我们通过两台IBM P630小型机和7133磁盘阵列实现双机热备为例，来说明通过HACMP 5.1来实现AIX 5.2的Oracle 9i数据库主从热备系统的运行维护和升级管理工作。

IBM HACMP双机热备方案说明

    HACMP 是 High Availability Cluster Multi-Processing 的缩写。HACMP 是 IBM 公司在 P 系列 AIX 操作系统上的高可靠集群软件，配置冗余，消除单点故障，保证整个系统连续可用性和安全可靠性。HACMP是利用网络来侦测主机及网卡的状况，搭配AIX所提供的硬盘镜像等功能，在主机、网卡、硬盘控制卡、硬盘或网络任何一个环节发生故障时，都可自动切换到另一套备用元件上重新工作；若是主机故障还切换至备份机上继续应用系统的运行。

图1

 
图2

    如上图，两台主机A和B分别都安装AIX 5.2系统，HACMP软件和Oracle 9i数据库，数据和应用系统安装在7133磁盘阵列上。作为双机系统的两台服务器A和B同时运行 HACMP 软件，一台P630作为主机A运行oracle 9i和应用系统，另一台P630作为备份机B处于备份状态（此时没有运行数据库和应用系统）。

    在整个运行过程中，通过 串口的SCSI“心跳线”相互监测对方的运行情况 (包括系统的软硬件运行、网络通讯和应用运行情况等)一旦发现对方主机A运行不正常时，备份机B就会立即在自己的机器上启动应用，把主机A的应用及其资源(包括用到的IP地址和磁盘空间等)接管过来，使主机A上的应用在备份机B继续运行。

    主机和备份机的确定取决于哪台机器先启动了HACMP服务，先启动的就是主机，另外一台就是备份机。应用和资源的接管过程由 HACMP 软件自动完成，无需人工干预；当两台主机正常工作时，也可以根据需要将其中一台机上的应用人为切换到另一台机 (备份机)上运行。

    双机系统的维护与管理更为复杂一点，在双机热备系统的维护与管理中，个人认为以下四大环节是必须注意的：

一、重视双机热备的启动程序

    双机热备系统的开机顺序是必须重视的，我们以前不久机房的一次断电事故来说明双机热备系统启动程序的重要性。

    由于单位进行机房改造，需要切换市电。为保证业务不间断运营，我们通过60KVA的梅兰日蓝UPS给机房提供不间断供电，同时考虑到60KVA所带的负载较重，关闭了一些不重要的服务器，也做了一些应急措施。但是当机房停电5分钟时间后，UPS突然宕机，随即机房的所有网络设备和服务器全体“罢工”。

    检查UPS发现供电电池出现问题，不能提供30分钟的正常供电，我们只好重新恢复市电工作。断电前由于没有及时关闭P630小型机和7133磁盘阵列的电源开关，当市电启用时，小型机和7133磁盘阵列也就自动启动了。

    AIX系统起来后，我们到两台小型机上查看运行ORACLE数据库和应用系统时，发现找不到“数据盘”，用Lsvg显示当前系统的所有卷组，发现只有rootvg，没有datavg，而数据卷组是放在7133磁盘阵列上的。这就是典型的因为掉电造成的非正常关机和开机导致了无法正常启动。

    在这个方案中，双机热备系统正确的开机步骤应当是这样的：

• 先开外设如磁盘阵列7133和磁带机
• 然后再开两台主机A和B
• 等主机AIX系统启动后，然后再分别启动HACMP服务，注意不能同时启动HACMP服务
• 最后启动ORACLE数据库和应用系统。
• 关机则正好相反，先关闭ORACLE数据库服务和应用系统，再停止HACMP服务，然后关闭主机系统，最后关闭磁盘阵列7133和磁带机。

    所以启动双机热备系统的时候遵循正确的启动程序非常重要，在上面的案例中，因为来电时，小型机和磁盘阵列同时启动，等AIX启动好后就认不出磁盘阵列等外设了。解决方法是关闭小型机和7133磁盘阵列，再按照规范开机顺序开启系统，等AIX系统起来后，启动HACMP，再查看数据卷组时，就能找到了。启动数据库和应用服务，测试结果一切正常。这一点与现在的PC机操作不同，外设和主机同时启动都不会出什么问题的。

    此外，在使用HACMP服务时，两台小型机也不能同时打开，必须按先后顺序来开机。这是因为我们采用的双机热备模式是主从热备，启动HACMP服务的先后顺序决定了哪一台作为主机，哪一台作为备机。因此，当两台机器同时启动的时候，就会造成HACMP服务运行“混乱”，结果当一台小型机发生故障时，另外一台小型机不能进行自动接管，不能真正达到双机热备的效果。

    同样地关机时也要严格按照关机顺序，如果先关闭7133磁盘阵列时，就有可能引发的数据丢失。这必须要引起大家在运行维护中高度重视，否则的话，造成数据丢失，后果将是非常严重的。

二、定期查询HACMP的运行状态
    我们需要定期地查询HACMP 双机系统的状态，在双机系统的运行当中，我们经常需要知道双机系统的当前状态，才有可能对双机系统出现的异常情况进行恢复处理，才能保证双机系统的高可用性和高容错性。查询HACMP 双机系统的状态只需以root 用户进入需要查询的节点进行下列操作：

    首先检查HACMP 双机软件在该节点是否已启动命令如下。 
    # lssrc -g cluster

    若是系统显示出下面类似的信息则说明HACMP 双机软件已正常启动。 
    Subsystem Group PID Status 
    clstrmgr cluster 22500 active 
    clsmuxpd cluster 23674 active 
    clinfo cluster 28674 active

    在已确认双机软件HACMP 正常启动的情况下在命令行执行下述命令来察看双机系统的当前状态。
    # /usr/sbin/cluster/clstat -a

    HACMP运行时只去检测网卡、网络和节点是否发生故障，并作出相应的转移、接管行为。对于其他故障，那么HACMP缺省不作任何动作。对于双机热备时出现硬盘控制卡和应用故障处理方法，一般是结合AIX基本功能和HACMP提供的一些机制，如Error  Notification Facility, clinfo API 等，同样可以实现对故障的监控并采取相应措施。

    如果用户的应用有kernel call调用，或以root身份来启动等，一旦应用发生故障，很容易导致AIX操作系统down掉，发生死机。这时实际上等于节点故障，HACMP会采取相应接管措施。如果只是应用自身死掉，AIX仍正常运行，HACMP最多利用Error Notification Facility来提供监控功能，对应用本身不采取任何动作。

    但如果应用中调用了AIX的SRC=\'#\'" Resource Controller)机制所提供的API接口，就可以使应用在down掉后自动重新启动。除了SRC提供API接口外，HACMP中的clinfo也提供这样的API。clinfo是cluster Information daemon,它负责维护整个cluster的状态的信息，clinfo API允许应用程序利用这些状态信息来采取相应行动。

三、Oracle 9i数据库的日常性维护

    在Oracle数据库中，我们可以通过观测一定的表或视图来了解当前空间的使用状况，进而作出可能的调整决定。通过对表空间的自由空间的观察，可用来判断分配给某个表空间的空间是太多还是不够。关于自由空间的管理，可以利用Export及Import命令卸出和装入表空间可以释放大量的空间，从而缓解增加另外的数据文件的要求。

    如果包含具有高插入(insert)和更新(update)活动的表的表空间中自由空间的比重下降到了15%以下，要为此表空间增加更多的空间。对于一个基本是静态表数据的表空间，如果有多于20%的自由空间，则可以考虑减少分配给它的文件空间量。减少SYSTEM表空间的空间量比较困难，因为那要重建数据库。

    为了防止表或索引被过分扩展，及时实现对数据库的调整，用户应当经常对有关对象进行观察。我们可以利用export卸出表，然后删除表，再利用import命令将表装入，这样，可以将不连续的区域合并成一个连续的空间。

    ORACLE 9i数据库在AIX运行维护过程中，经常会遇到使用Shutdown（只有Internal用户有此权）命令不能关闭数据库的故障。不能关闭数据库是因为数据库有未提交事务，此时可用Shutdown Abort命令关闭数据库，但是所有未提交事务将被废弃。

    有时候，系统管理员会发现数据库Client端经常无故发生死机的情况，此时可在Server端使用Platinum EPM产品确认问题所在。使用EMP可以监控系统的运行，最有可能的原因是，用户因为误操作在数据库中发生死锁，引起Client 死机。经确定进程号后，到ORACLE用户下，使用“KILL －9进程号”命令，即可释放死锁，解决Client端死机问题。

四、保护磁盘阵列的数据安全

    企业运行的重要数据平时都保存在磁盘阵列上，因此对磁盘阵列的日常运行维护就显得十分重要。需要做以下及几个方面的工作：

    及时检查运行日志文件 

    磁盘阵列的日志文件详细记录了磁盘阵列内部运行情况，包括发生的每个事件序列号、严重级别、相关的服务器IP地址、有关设备的具体位置及事件发生的时间等内容，这些信息对于诊断和排除磁盘阵列故障十分有用。做好日志文件的日常管理工作，往往能起到防患与未然的作用。

    采用RAID数据冗余技术，即使有一个物理磁盘损坏，也不会影响系统正常运行和数据的I/O，用户也仍能够正常访问服务器，这时故障不易被察觉，但阵列实际上已处于安全临界状态，下一步就会面临着突然宕机和存储数据随时丢失的危险，日志文件及时将这一情况记录在册，损坏的磁盘记录为下线(off line)，其所在阵列记录为临界状态(critical)，通过检查日志就能够及时发现阵列运行中存在的这个错误和隐患，迅速排除故障，保证阵列始终处于安全运行状态。

    定期检查数据一致性

    数据冗余是磁盘阵列主要技术之一，磁盘阵列通过数据冗余达到容错目的，但是由于各种原因，难免会遇到冗余数据与主数据块（Primary Data）不一致的情况，结果造成数据失效甚至宕机等现象。一致性检查能及时发现和纠正潜在的错误数据，保证阵列中数据的完整性。通过对RAID互为镜像的磁盘数据一致性检查，或者主数据块进行重新校验，将产生的校验数据与冗余数据比较，都能发现不一致的错误数据。一致性检查一般间隔时间以每周1～2次为宜。

    建立热备用磁盘

    热备用磁盘也是RAID技术的又一项技术，当磁盘阵列中一个正在使用的物理磁盘发生故障后，一个待机的磁盘会立刻上线，代替此故障盘，阵列控制器根据逻辑驱动器上的冗余数据，通过校验算法把原来存储在故障盘上的数据重建到热备用磁盘上。

    成为热备用磁盘必须有三个条件：一是有不小于故障盘的容量；二是平时不得存储任何数据，也就是闲置不用；三是阵列控制器自动重建数据功能有效。在一个阵列中，只能有一个热备用磁盘。热备用磁盘增加了一次数据逃生的机会，系统管理员要及时更换发生故障的磁盘，并指定新的热备用磁盘。

    定时备份重要数据

    配备了磁盘阵列并不意味着可以高枕无忧了，对于重要业务数据一定要备份。数据备份的介质可以是磁带、可读写光盘，也可以还是磁盘。备份方式可以是通过操作系统本地备份或通过网络系统远程备份，目前可以采用DAS、NAS或SAN方式来进行数据备份。

    在本方案中，对于7133磁盘阵列运行维护时，主要是通过它前面面板本身自带的指示灯来判断有无异常情况，也可以通过AIX的如diag、errpt和smit ssaraid等命令来运行和管理磁盘阵列。

Case study：7133硬盘故障的判断与处理

    举例说明，我们有时候会在AIX系统中用#errpt –aj|more命令查看到有描述为“pdiskx error”，级别显示为“H”类型显示为“P”。该报错的服务器所连接的存储阵列很有可能发生物理硬盘损坏的故障，这时用户可以用以下命令察看7133 RAID的状态。

    在AIX系统中用#smitty ssaraid

    这时，系统将列出所有定义的SSA RAID阵列的状态（List Status of all Defined SSA RAID Arrays），当RAID中的硬盘出现问题时，此RAID的状态是“degraded”。这时可用以下命令判断硬盘是否被阵列删除：

    在AIX系统中用#smit ssaraid

图3

    这时，系统将运行列出/标识 SSA物理磁盘（List/Identify SSA Physical Disks），列出删除阵列磁盘（List Rejected Array Disks），如果看到pdiskx被阵列剔除，说明该pdiskx存在物理故障，可采取更换该pdiskx的物理硬盘的办法来解决。

Case Study：从双机热备升级为SAN

    目前大部分企业使用7133 磁盘阵列所采用的主要架构为 HA（双机热备） 架构，基本架构为两台IBM 小型机连接一台 IBM 的 7133 磁盘阵列做 HACMP 架构。随着企业应用的不断增长，数据量的不断增加，企业初期配置的存储设备已经远远不能满足用户对性能及存储容量的需求，企业对存储设备的更新迫在眉睫。

    为解决企业对容量扩展及对性能提升的需求，因此考虑了升级方案，将企业原有架构中的 7133 磁盘阵列替换为 IBM的 DS 系列光纤磁盘阵列，同时将原来7133 磁盘阵列中的数据平滑安全的迁移到新的 DS 光纤磁盘阵列中，并且在迁移过程中，尽量不中断企业应用。同时考虑到设备利旧问题，将企业原有的 7133 磁盘阵列用作的数据库备份系统，从而提高整体系统的性能。

图4

    升级方案一般为IBM DS 系列产品, IBM DS系列最近两年经过了不少升级与换代，现在主流产品为DS4800/DS4700等等4Gb光纤磁盘阵列，兼顾其他DS系列产品，如 4500/4800/6800，使用8口的 SAN 交换机和数据迁移服务软件，可实现平滑迁移用户数据,保持用户日常应用的正常运行。现有 7133 存储设备可以作为数据库备份设备继续使用，因而可保护前期投资,降低未来投入。

图5

    整个方案通过提高存储网络性能从而进一步提高整个 IT 系统的整体性能；引进 SAN 光纤交换连接技术，从而提高 IT 系统的灵活性，可以更方便的引进、更新系统；可以支持各种高级的数据备份技术，包括远程拷贝、时间点拷贝等等，简易 GUI 管理,实现资源利用最大化利用。拥有统一的硬件平台，图形化管理更为方便。