IBM HACMP GLVM 容灾测试流程参考

合集下载

HACMP 5.2 的安装、配置、测试完全手册

HACMP 5.2 的安装、配置、测试完全手册摘要：IBM HACMP 自从出了5.2 版本后，到了5.205比较稳定，并已经过充分的测试（见测试篇）和实践证明（已有多个系统成功自动切换）。

这里我整理了一下，以比较复杂的双机互备情况为例，其他类似设置可适当简化。

样例为AIX5304+HACMP5205.第一章规划篇第二章安装篇1、安装前提1) 操作系统版本要求：AIX５.203以上2) 环境要求用户确认HA要求所有切换需要用到的用户必须一一对应，userid完全相同。

如tlg1d0上oracle用户为orarun，tlg1a0上的orarun必须为切换保留，sid均为209平时用的oracle用户就改为oraclt[tlg1a0][root][/]lsuser -a id ALLroot id=0daemon id=1bin id=2sys id=3adm id=4uucp id=5nobody id=-2lpd id=9lp id=11invscout id=6snapp id=200ipsec id=201nuucp id=7radiusd id=202ldap id=203oradev id=204tuxrun id=205oraclt id=208orarun id=209sshd id=211bsx1 id=210[tlg1d0][root][/]>lsuser -a id ALLroot id=0daemon id=1bin id=2sys id=3adm id=4uucp id=5nobody id=-2lpd id=9lp id=11invscout id=6snapp id=200ipsec id=201nuucp id=7radiusd id=202ldap id=203oradev id=204orarun id=209tuxrun id=205oraclt id=208bsx1 id=210Ø 文件系统确认HA要求切换相关的文件系统不能重名，如tlg1d0上oracle软件目录为/ora10msrun，tlg1a0上的/ora10msrun必须为切换保留，改为/ora10msclt[tlg1d0][root][/]>df -kFilesystem 1024-blocks Free %Used Iused %Iused Mounted on/dev/hd4 524288 487820 7% 3276 3% //dev/hd2 7077888 1868516 74% 91290 18% /usr/dev/hd9var 524288 458364 13% 991 1% /var/dev/hd3 917504 826700 10% 120 1% /tmp/dev/hd1 655360 524856 20% 291 1% /home/proc - - - - - /proc/dev/hd10opt 1179648 589072 51% 11370 8% /opt/dev/lv00 131072 126912 4% 18 1% /var/adm/csd/dev/fslv01 131072 130724 1% 4 1% /tftpboot/dev/fslv00 6684672 3719036 45% 6 1% /export/eznim/dev/ora10msrunlvbak 8912896 5165508 43% 24814 3% /ora10msrunbak /dev/msrundatalvbak 13107200 2895980 78% 32 1% /msrundatabak/dev/msrunloglvbak 5242880 3094480 41% 8185 2% /msrunlogbak/dev/mksysblv 13107200 6238868 53% 5 1% /mksysb/dev/tlg1d0_baklv 26214400 17495848 34% 1111 1% /tlg1d0_bak/dev/msrundatalv 13107200 2896000 78% 31 1% /msrundata/dev/msrunloglv 5242880 3112216 41% 7996 2% /msrunlog/dev/ora10msrunlv 8912896 5173252 42% 23406 2% /ora10msrun[tlg1a0][root][/]>df -kFilesystem 1024-blocks Free %Used Iused %Iused Mounted on/dev/hd4 655360 93968 86% 3450 14% //dev/hd2 8650752 3779000 57% 90347 10% /usr/dev/hd9var 1179648 1001248 16% 1164 1% /var/dev/hd3 1179648 1136192 4% 143 1% /tmp/dev/hd1 655360 587592 11% 489 1% /home/proc - - - - - /proc/dev/hd10opt 1835008 1244528 33% 11374 4% /opt/dev/lv00 131072 126912 4% 18 1% /var/adm/csd/dev/fslv01 131072 118800 10% 7 1% /tftpboot/dev/fslv00 7733248 960696 88% 27298 12% /export/eznim/dev/fslv02 15335424 1143804 93% 4525 2% /soft_ins/dev/tlg1a0_baklv 26214400 20751500 21% 16 1% /tlg1a0_bak/dev/ora10mscltlvbak 13107200 9386904 29% 16852 1% /ora10mscltbak /dev/tux81msrunlvbak 655360 407932 38% 2685 3% /tux81msrunbak /dev/meslvbak 8912896 4815640 46% 6349 1% /BSMesWare/BSX1bak /dev/xcomlvbak 5242880 5186260 2% 4178 1% /xcombak/dev/ora10mscltlv 13107200 9386748 29% 16852 1% /ora10msclt/dev/tux81msrunlv 786432 538952 32% 2685 3% /tux81msrun/dev/meslv 14155776 10057876 29% 6343 1% /BSMesWare/BSX1/dev/xcomlv 5242880 5186280 2% 4178 1% /xcom3) 安装包要求：RSCT 2.3.6.0 或更高版本。

ibm存储容灾方案v

i b m存储容灾方案v This manuscript was revised by the office on December 22, 2012存储容灾解决方案目录一、概述1.1信息系统现状1.1.1存储系统现状目前业务系统主要应用系统有文件服务器（windows ）、应用服务器（windows ）、邮件服务器（windows ）、防病毒服务器（windows ）、HR 服务器（windows ）和ERP 服务器（SUN 小机）。

目前应用系统均运行在独立的服务器中，一方面服务器本身容量空间有限，随着业务数据的不断增长，空间已基本饱和，另一方面数据安全性没有保障，服务器故障将面临整个业务系统数据丢失（单台服务器故障，怎么会造成整个数据丢失）。

应用系统的高性能存储空间及数据保护工作是信息中心最为重视的现有存储系统情况统计：（表格把客户目前服务型号及硬盘分布要写的详细些，表格我会提供）序号系统组成系统类型/存储方式（位置）现有磁盘阵列及类型、容量1文件服务器 Windows/本地 // 2应用服务器 Windows/本地 3邮件服务器 Windows/本地 4防病毒服务器 Windows/本地 5HR 服务器 Windows/本地 6 ERP 服务器 SUN 小机/本地从上表情况来看，所有业务系统的数据都存放在本地硬盘上，本地硬盘存储具有如下缺陷：单硬盘或者原始RAID 方式，故障率高，安全性低。

性能低下，影响应用主机性能。

磁盘容量性能扩展性差。

只能通过与之连接的主机进行访问。

每一个主机管理它本身的文件系统，但不能实现与其他主机共享数据。

数据分散，管理复杂。

综上所述，在信息中心现有的业务系统环境中，各业务主机的存储环境主要由本地硬盘，存储数据分散在各自单独的本地存储中，导致数据分散管理，管理非常繁琐，数据的安全性和高可用性得不到根本保障。

从存储方式来看，对业务系统来说，改善存储架构，用先进的集中统一管理的FCSAN存储架构代替现有的存储架构，提高存储的安全性和高可用性是非常有必要和必须的。

IBM 小型机巡检服务过程

IBM 小型机巡检服务过程一．提取机器的型号。

#uname -uM二．机房内场地环境检查。

三．检查系统硬件灯是否有亮。

四．查看系统错误报告。

1.查看是否有硬件和软件故障。

#Errpt –d H | more ,# errpt –d S | more, #errpt –aj *******|more查看具体错误信息# errpt -d H -T PERM>/tmp/hwerror.log //可以把错误的报告存成一个文件。

2.有否发给root用户的错误报告（mail）。

#Mail3.检查hacmp.out,smit.log,bootlog等.#lssrc –g cluster/#>lssrc –g cluster,一般hacmp.out的位置在：/use/sbin/cluster/或者/tmp/，找到最近hacmp.out文件查看是否有错误信息。

4.查看是否有“满”的系统文件。

#df –k 查看系统文件有没有超过90%的使用率，有请用户改善。

5.查看是否有“stale”（不可用）状态的逻辑卷.#lsvg -l rootvg,系统还有其卷组的也要查看。

6.查看内存使用率是否超过70%。

#Lsps -a五．系统性能检查，查看系统是否有性能瓶颈。

#topas #vmstat 1 10 #iostat 1 10六．网络与通讯检查,查看网卡的状态，IP地址，路由器等。

#ifconfig –a,#netstat–in,#netstat –rn(查看路由情况),#vi/etc/hosts(查看hosts文件有否特殊定义)，#ping ******（IP），#lsattr –Elet0(路由的检测，显示true正确的就是没问题)。

七，数据安全检查。

1.查看是否有符合要求的备份。

#ls –l/image.date(查看系统有没有备份image文件，记录备份最后日期),#lsvg –l rootvg(查看有否符合要求的数据备份和保护)。

IBM+HACMP双机服务器系统的解决方案

IBM HACMP双机服务器系统的解决方案【导读】Hacmp（High Availability Cluster Multi-Processing）双机热备份软件的主要功能是提高客户计算机系统及其应用的可靠性，而不是单台主机的可靠性。

Hacmp（High Availability Cluster Multi-Processing）双机热备份软件的主要功能是提高客户计算机系统及其应用的可靠性，而不是单台主机的可靠性。

一、Hacmp双机系统的工作原理HACMP的工作原理是利用LAN来监控主机及网络、网卡的状态。

在一个HACMP环境中有TCP/IP网络和非TCP/IP网络。

TCP/IP网络即应用客户端访问的公共网，该网可以是大多数AIX所支持的网络，如Ethernet，T.R.，FDDI，ATM，SOCC，SLIP，等等。

非TCP/IP 网络用来为HACMP对HA环境（Cluster）中的各节点进行监控而提供的一个替代TCP/IP 的通讯路径，它可以是用RS232串口线将各节点连接起来，也可以是将各节点的SCSI卡或SSA卡设置成Target Mode方式。

1、作为双机系统的两台服务器（主机A和B）同时运行Hacmp软件；2、服务器除正常运行自机的应用外，同时又作为对方的备份主机；主机A（运行应用）：Service_ip: 172.16.1.1Standby_ip: 172.16.2.1Boot_ip: 172.16.1.3主机B（standby）：Service_ip: 172.16.1.2Standby_ip: 172.16.2.2Boot_ip: 172.16.1.43、两台主机系统（A和B）在整个运行过程中，通过“心跳线”相互监测对方的运行情况（包括系统的软硬件运行、网络通讯和应用运行情况等）；4、一旦发现对方主机的运行不正常（出故障）时，故障机上的应用就会立即停止运行，本机（故障机的备份机）就会立即在自己的机器上启动故障机上的应用，把故障机的应用及其资源（包括用到的IP地址和磁盘空间等）接管过来，使故障机上的应用在本机继续运行；5、应用和资源的接管过程由Ha软件自动完成，无需人工干预；6、当两台主机正常工作时，也可以根据需要将其中一台机上的应用人为切换到另一台机(备份机)上运行。

IBM HACMP双机服务器系统的解决方案

IBM HACMP双机服务器系统解决方案Hacmp（High Availability Cluster Multi-Processing）双机热备份软件主要功能是提高客户计算机系统及其应用可靠性，而不是单台主机可靠性。

一、Hacmp双机系统工作原理HACMP工作原理是利用LAN来监控主机及网络、网卡状态。

在一个HACMP环境中有TCP/IP网络和非TCP/IP网络。

TCP/IP网络即应用客户端访问公共网，该网可以是大多数AIX所支持网络，如Ethernet，T.R.，FDDI，ATM，SOCC，SLIP，等等。

非TCP/IP网络用来为HACMP对HA环境（Cluster）中各节点进行监控而提供一个替代TCP/IP通讯路径，它可以是用RS232串口线将各节点连接起来，也可以是将各节点SCSI卡或SSA卡设置成Target Mode方式。

1、作为双机系统两台服务器（主机A和B）同时运行Hacmp软件；2、服务器除正常运行自机应用外，同时又作为对方备份主机；3、两台主机系统（A和B）在整个运行过程中，通过“心跳线”相互监测对方运行情况（包括系统软硬件运行、网络通讯和应用运行情况等）；4、一旦发现对方主机运行不正常（出故障）时，故障机上应用就会立即停止运行，本机（故障机备份机）就会立即在自己机器上启动故障机上应用，把故障机应用及其资源（包括用到IP地址和磁盘空间等）接管过来，使故障机上应用在本机继续运行；5、应用和资源接管过程由Ha软件自动完成，无需人工干预；6、当两台主机正常工作时，也可以根据需要将其中一台机上应用人为切换到另一台机(备份机)上运行。

HACMP双机系统结构图（点击看大图）二、Hacmp安装配置前需作准备工作1、划分清楚两台服务器主机各自要运行应用(如A机运行应用，B机作为standby)；2、给每个应用(组)分配Service_ip、Standby_ip、boot_ip和心跳线tty，如：主机A（运行应用）：Service_ip: 172.16.1.1Standby_ip: 172.16.2.1Boot_ip: 172.16.1.3主机B（standby）：Service_ip: 172.16.1.2Standby_ip: 172.16.2.2Boot_ip: 172.16.1.43、按照各主机应用要求，建立好各自磁盘组，并分配好磁盘空间；4、根据Ha软件要求，对服务器操作系统参数作必要修改。

IBM POWERHA 同城灾备解决方案

同城灾备解决方案建议书DigitalChina同城灾备解决方案建议书目录1.1构建容灾解决方案的重要性 (1)1.2同城灾备解决方案简述 (2)2.1PowerHA （HACMP）实现应用高可用 (5)2.2存储高可用方案 (5)3.1 IBM Power 服务器的技术优势 (9)第1章容灾方案为您的业务运营遮风挡雨1.1 构建容灾解决方案的重要性随着社会的发展和科技的进步，企业越来越依赖于数据处理来进行业务运营，业务的连续运营依赖于 IT 系统的稳定运行。

然而，灾难就像灰尘一样伏击在企业周围，您的业务系统可能正在一个充满风险和威胁的世界里运行：无法预知的IT 硬件设备的损坏、断电、火灾、自然灾害、恐怖袭击等，造成数据丢失或业务的突然中断；系统人员误操作造成意外宕机或关键数据丢失，无法避免；手段频多的黑客攻击、病毒入侵、垃圾邮件、网络与系统的漏洞，造成网络瘫痪、系统崩溃。

如果不能对风险采取有效治理，一旦数据由于上述某种原因丢失，就有可能造成整个企业在运营上的重大不便和经济损失，企业的信誉也将受到影响。

如果核心数据丢失，严重时完全有可能造成整个企业的瘫痪。

由此可见，保证企业的业务连续运营及数据处理的高可靠性和高可用性，已经成为所有 IT 人员在建设 IT 基础架构中首先要考虑的问题。

与此同时，我们需要考虑建立和加强企业的业务恢复计划，以便在发生系统灾难后能够从容应对风险。

企业对 IT 系统提出了以下要求：数据与存储系统的高可用性，保证数据 7X24 小时的连续访问；将现有的存储技术集成，创造出一种更有效的数据存储管理，实现高效、高可靠性、低成本的数据管理；需要对企业现有的数据库、邮件系统、文件服务器以及各种应用系统进行集中化、自动化的基于策略的保护；需要一套成熟度高，业内应用广泛的企业级软硬件整体解决方案；易于IT部门日常的管理维护，界面友好，可操作性强；一旦发生灾难(洪水、地震、火灾等)，或者人为灾难(用户失误、磁盘失效等)导致数据丢失或者业务中断时，能够快速、及时地恢复数据，保证业务的连续运行。

服务器容灾测试与演练验证恢复计划和流程

服务器容灾测试与演练验证恢复计划和流程概述：服务器容灾测试与演练验证是确保服务器系统能够在发生灾难性故障时快速、高效地恢复的重要环节。

本文将详细介绍容灾测试的目的、流程以及验证恢复计划的重要性。

一、容灾测试目的服务器容灾测试的目的是为了验证服务器系统在意外故障发生时的可靠性和恢复能力。

通过模拟真实的灾难情景，测试各种灾难恢复计划的有效性，以评估系统的脆弱性和改进容灾策略。

容灾测试还有助于发现潜在的问题和风险，提高整个系统的稳定性和可用性。

二、容灾测试流程1.制定测试计划在进行服务器容灾测试前，首先需要制定详细的测试计划。

测试计划应包括测试的目标和范围、测试环境的准备、测试时间、测试人员以及测试的具体流程和步骤等信息。

2.模拟灾难场景根据不同的灾难类型，模拟相应的灾难场景。

比如，可以模拟硬盘故障、电源故障、网络故障等。

在模拟灾难场景时，需要确保测试环境与真实生产环境尽可能相似，以保证测试结果的可信度。

3.执行容灾计划和恢复流程根据容灾计划和恢复流程，对服务器系统进行恢复测试。

在测试的过程中，需要记录测试结果和执行过程，以便后续分析和改进。

4.评估测试结果并分析问题根据测试结果评估服务器容灾能力，并对问题进行深入分析。

分析过程中，可以借助一些监控工具和日志来追踪和判断问题的原因，并提出相应的解决方案。

5.改进容灾策略根据测试中发现的问题和分析结果，及时优化和改进容灾策略。

这可能涉及到硬件设备的升级、备份策略的完善、数据恢复流程的优化等。

同时，还需要对容灾计划进行修订和更新，以保持其与实际情况的匹配度。

三、验证恢复计划的重要性容灾测试不仅检验服务器系统的可恢复性，也验证了恢复计划的有效性。

验证恢复计划的重要性体现在以下几个方面：1.确保业务连续性恢复计划是保障企业业务连续性的重要手段。

通过容灾测试，可以验证恢复计划在实际应急情况下的可靠性和有效性，提高系统的可用性和服务质量，确保业务不因灾难性故障而中断。

HACMP规划、实施与配置的经验分享

HACMP规划、实施与配置的经验分享李一峰IBM系统与科技事业部liyifeng@议题•HACMP的主要概念•HACMP配置要点•HACMP测试、排错要点•HACMP配置界面•HACMP与Oracle 9i RAC高可用& 容错10+2-31Relative CostNo loss of DataLast transactionGood as your last fullbackupData Availability In theory, none Depends, but typically 3 mins Couple of days Downtime •Lock Step CPUs•Hardened Operating System •Hot Swap Everything •Continuous Restart•Redundant Servers •Redundant Networks•Redundant Network Adapters •Heartbeat Monitoring •Failure Detection •Failure Diagnosis •Automated Fallover•Automated Reintegration•Journaled File System•Dynamic CPU Deallocation •Service Processor •Redundant Power •Redundant Cooling •ECC Memory•Hot Swap Adapters •Dynamic KernelAvailability benefitsSolutionsFault Tolerant ComputersH igh A vailabilityClusters StandaloneFailover possibilities什么环境不适合HACMP•You cannot suffer any downtime–Failovers will cause at least some downtime•Your environment is not stable–HACMP depends on stable software levels and stable configuration–HACMP is susceptible to the “fiddle factor”•Your application needs manual intervention to recover from a failure–Manual reset of a device, etc.使用HACMP的考虑点•Application must be able to recover from a stop/restart operation–Must release all resources when stopped—either normally or abnormally–Must tolerate a loss of memory contents–Must tolerate a loss of processor state–Must perform a restart from a checkpoint–Must recover from partial data writes–Must operate in a “transactional”protocol•There must not be a single point of failure in the HA cluster–Shared power supply, non-protected disk, etc.–HACMP is a software solution什么是HACMP•H igh A vailability C luster M ulti P rocessing •Allows a set of applications to move quickly to astandby processing system.–Heartbeat monitor–IP Address takeover–Resource Grouping–Shared I/OSoftware Layers on a HACMP node •Application–Uses the services made highly available byHACMP•HACMP–Makes services highly available forapplications–Co-ordinates resource availability throughthe cluster•RSCT–Provides reliable communication betweennodes–Co-ordination of subsystems•AIX–Operating system services•LVM–Logical storage management•TCP/IP–Manages communications at a logical layerHACMP的构成•HACMP has a number ofcomponents that make up acomprehensive highavailability package for AIX•HACMP is an applicationwhich:–Monitors clustercomponents,–Detects status changes,–Diagnoses and recoversfrom failures and...–Reintegrates previousfailed components back into the cluster uponrecovery.两节点HACMP 拓扑结构示意图Network ClientsSerial HeartbeatpSeries Cluster Node pSeries Cluster NodeIP NetworkService & Standby Network AdaptersShared DiskIP HeartbeatsCluster Nodes•Since the cluster is treated as a single entity, we refer to the individual computers as nodes.•Each node is an independent system•Inter node communication is defined when the cluster is initialized.Service IP aliases •"Service Address" or "Service Label" is the connection tothe computer•AIX allows many addresses on a single adapter•Does not affect the original configuration•Allows separation of services•Faster to move if necessaryIP 地址切换(IPAT)方式一(替换方式)At systembootWithHACMPrunningAfter adapter failure After failure Adapter Type192.168.0.1192.168.0.6nana Boot /Service 1.1.1.11.1.1.1naStandbyBoot 1.1.1.21.1.1.2Standby192.168.0.2192.168.0.2192.168.0.6192.168.0.6192.168.0.2192.168.0.21.1.1.2Node ANode Bhost •Two logical IP networks (Netmask 255.255.255.0)•One physical network•Clients always access 192.168.0.6•MAC address takeover or ARP cache update is also neededIP 地址切换(IPAT)方式二(别名方式)At system bootWith HACMPrunningAfter adapter failure 192.168.0.110.1.1.1nana 1.1.1.11.1.1.1na1.1.1.21.1.1.2192.168.0.2192.168.0.210.1.1.150192.168.0.110.1.1.15010.1.1.110.1.1.15010.1.1.16010.1.1.160192.168.0.210.1.1.160192.168.0.210.1.1.1601.1.1.210.1.1.1Node ANode BAfter failure host 1.1.1.1 1.1.1.2•Initially configured addresses (Boot IP)•Persistent IP addresses -useful for applications like Tivoli •Service IP addresses -used by clients to access the cluster-multiple are allowedHow Volume Groups are Handled •Two types:–Shared–Non-shared•Shared volume groups can"migrate"•Non-Shared volume groupsare node bound•Application data must be ona shared volume group tobe "moved"•Application code may be oneither type of diskApplication Server Scripts •"Application server", a name given to a series of scripts:–Start the application–Stop the application–Monitor the application (optional)–Re-start the application (optional)•Applications must be able to be started from a previously unknown state by a script•Applications must be able to be stopped by a scriptResource Groups•Logical constructs that group related attributes together •The "container" used by HACMP to "move" resources •Participating node list–default node priorities–Home node•Have Policies on:–Start up–Fall over–Fall back–Distribution policy–Dependant resource groupsResource Group Policies: startup•Resource group start up occurs:–during initial cluster start up–initial acquisition of theresource group–May be modified by a"settling" timer •Online on Home Node Only (OHNO)–only start on the highestpriority•Online on First Available Node (OFAN)–will start on any one node •Online on All Available Nodes (OAAN)–The resource groups will start on all nodes•Online Using DistributionPolicy (OUDP)–One resource group pernetwork or node depending onthe distribution policyResource Group Policies: Fallover•Resource group falloveroccurs:–When the current node can no longer support the resourcegroup and it is "moved" toanother node•Failure has occurred•Graceful shutdown withtabkover of the current node •Fallover to Next Priority Node (FNPN)–Resource group is moved to the next node in the resourcegroup's node list•Fallover using Dynamic Node Priority (FDNP)–Resource group is moved to the next node in the resourcegroup's node list asrecalculated based on thedynamic node criteria policy •Bring Offline on Error Node (BOEN)–Resource group is set to an offline state on this node onlyResource Group Policies: Fallback•Resource group fallback occurs:–The resource group is not on its home node– A higher priority nodebecomes available–Can be modified by a fallback timer •Fallback to a Higher Priority Node (FHPN)–When the higher priority node is available and/or the optionaltimer expires, the resourcegroup moves•Never Fallback (NFB)–Regardless if a higher priority node becomes available, theresource group will not moveHACMP 资源组（Cascading Resource Group ）ABABSystem A fails System B fails System B takes over resource groupNo activitiesSystem A returns to clusterSystem B returnsto clusterA owns resource groupB is backup for AA BA BA owns resource groupB is backup for ASystem B releases resource group(Simple standby operation)C a s c a d i ngHACMP 资源组（Rotating Resource Group ）B owns resource group:ABABSystem A fails System B fails System B takes over resource groupSystem A returns to clusterSystem B returns toclusterA B A BA owns resource group:B is backup for ASystem A takes overresource groupRotatingHACMP 资源组（Concurrent Resource Group ）ABABSystem A fails System B fails No activitiesSystem A returns to clusterSystem B returns to clusterA andB owns resource group:A BA B No activitiesConcurrentA andB owns resource group:Custom Resource Groups (HACMP 5.2, 5.3, 5.4)•Relatively same as HACMP v5.1•Custom Resource Groups are only option•“Types”of Cascading, Rotating, Concurrent by name no longer exist.•All previous configuration options can be created via policies:Startup –what happens when the cluster first startsFallover–what happens when a failure occursFallback –what happens when a node rejoins the clusterCustom Resource Groups (HACMP 5.2, 5.3)•Startup Policy (Select one)–Online On Home Node Only (highest priority to be available)–Online On First Available Node ( like rotating resource group)–Online Using Distribution Policy–Online On All Available Nodes (like concurrnet resource group)•Fallover Policy (Select one)–Fallover to Next Priority Node in the List (like cascading)–Fallover Using Dynamic Node priority (user defined priority policy)–Bring Offline (On Error Node Only) (offline resource during an error condition)•Fallback Policy (Select one)–Fallback To Higher Priority node in the List ( like cascading)–Never Fallback (like rotating resource)C-SPOC•Cluster-Single Point of Control, the System Management interface in HACMP•Cluster wide, cluster aware tool–Add, change, delete users–Add, change, delete file systems–Add, change, delete logical volumes–Add, change, delete physical volumes–Start and stop the cluster–Manage log files–File collectionsCluster Communication•TCP/IP based communication–All network adapters•Use separate logical subnets•Use single subnet with heartbeatover IP aliasing•Non-TCP/IP basedcommunication–Serial (RS232) connection–Target mode–Disk heartbeat• A non-TCP/IP basedcommunication network is highlyrecommendedHACMP监测三类故障•Node Failures-Processor hardware or operationg system failures-One or more surviving nodes can acquire resources•Network Adapter Failures-Move IP address to standby network adapter in same node •Network Failure-Message displayed on console and event is logged-As every site's network configurations are unique , no other default actionis taken-Action to be taken in response to network failures is customizable其它类型的故障•Disk Drive Failures–LVM Mirroring–RAID Disk Devices•Other Hardware Failure–Application Failure (Customization needed , SRC)•HACMP Failure–Promoted to node failure•Power Failure–Avoid common power supplies across replicated devices –Use a UPSNetwork availabilityHubHubDual homingDual networksRouterRouterEliminates hubs as SPOFWhere are clients attached?Routing is trickierUse dual homing and dual networks in a cluster backbone with intelligent routers to provide network availabilityHACMP 2 Node Cluster SAN ExampleHACMP配置要点• 1. Network–1) TCP/IP network: adapter, boot IP address–2) Modify /etc/hosts and /.rhostsor /usr/es/sbin/cluster/etc/rhosts–3) No-TCP/IP network:•Target mode SCSI/SSA•Disk Heartbeat•RS232 (define the device)• 2. Storage–1) Internal disk–2) SSA disk, Fibre disk–3) VG/LV/FS (if you used the concurrent vg ,you must install the package bos.clvm)HACMP配置要点• 3. Application–1) Client/Server–2) Client/Application Server/DBServer–3) Informix / Informix HDR–4) Oracle or RAC–5) DB2 / UDB EEE• 4. Resource Planning–1) Volume group–2)Disk drive–3) File system–4)NFS–5)IP Address–6) ApplicationHACMP配置要点• 5. Resource policies–Startup–Fallover–FallbackHACMP测试要点•Power Off Box•Plug out network cable•ifconfig en# down•stop cluster with takeover mode e.g: –#clstop-gr•Shutdown not takeover•monitoring cluster takeover results:–ifconfig-a --> Service IP takeover ?–lsvg-o --> vg takeover or varyon?–df--> fs mounted ?–ps-ef--> application started ?–tail -f /tmp/hacmp.outHACMP排错要点•Cluster Log Files•Cluster Daemons•Monitoring Cluster:•clstat/xclstat•check log files•check daemons by lssrc-g cluster or ps-ef•lsvg-o•ifconfig-a•netstat-in•lslpp-l cluster.*•Config_too_long•Deadman Switch•CDE and HACMP•Apply patchHACMP相关的日志文件•/tmp/clstrmgr.debug•Generated by the clstrmgr daemon•/usr/es/adm/cluster.log•Generated by cluster scripts and daemons•/usr/es/sbin/cluster/history/cluster.mmddyyyy•Cluster history files generated daily•/tmp/cl_sm.log•Generated by the cluster Shared Memory library•/tmp/cspoc.log•Generated by CSPOC commands•/tmp/dms_loads.out•Generated by deadman's switch activity•/tmp/emuhacmp.out•Generated by the event emulator scripts•/tmp/hacmp.out•Generated by event scripts and utilities•/var/adm/clavan.log•Generated by Application Availability Analysis tool•/var/hacmp/clverify/clverify.log•Generated by Cluster Verification utility.•/var/hacmp/clcomd/clcomd.log•Generated by clcomd daemon•/var/hacmp/clcomd/clcomddiag.log•Generated by clcomd daemon, debug information•/var/hacmp/log/clconfigassist.log•Generated by Two-Node Cluster Configuration Assistant•/var/hacmp/log/clutils.log•Generated by cluster utilities and file propagation.•/var/hacmp/log/cl_testtool.log•Generated by the Cluster Test Tool.•system error log•errpt-aDeadman Switch•AIX kernel extension•Reset by clstrmgr daemon•Tune the system using I/O pacingsmit chgsys to changehigh water mark 0 --> 33low water mark 0 --> 24•Increase the syncd frequency/sbin/rc.bootdefault 60change to 45, 30 or 20•Increase the memory size used by communication subsystemno -ano -o thewall=mem_size•Tuning Virtual Memory Managementincreasing minfree/maxfree•Change the Failure Detection Ratesmit hacmp-->Extended Configuration > Extended Topology Configuration > Configure HACMP Network ModulesFast , normal --> slow•Deadman Switch Time to TriggerRunning the /usr/es/sbin/rsct/bin/hatsdmsinfo commandChange Shared LVM Components•Add/Change/Remove VG/LV/FS•Manual update•Lazy update–Automatic export and import by HACMP While failed takeover time–compare time stamp between on VGDA on disk and in /usr/es/sbin/cluster/etc/vg file–extend takeover time•C_SPOC–real time update–perform on only one nodeHACMP相关的AIX文件包•bos.adt.lib•bos.adt.libm•bos.adt.syscalls•.tcp.client•.tcp.server•bos.rte.SRC•bos.rte.libc•bos.rte.libcfg•bos.rte.libcur•bos.rte.libpthreads•bos.rte.odm•pat.basic.hacmp•pat.clients.hacmp•rsct.core.secConcurrent Logical Volume Manager for concurrent access•bos.rte.lvm.rte•bos.clvm.enh•After both RSCT and HACMP have been installed successfully on all the nodes, all the machines have to been rebooted before going on with HACMPconfiguration.HACMP相关术语HACMP配置菜单Smitty hacmp配置管理Extended Configuration123Extended Topology Configuration1.11.21.31.41.5Extended Resource Configuration2.12.2Extended Resources Configuration2.1.12.1.2Extended Resource Group Configuration2.2.12.2.2启动和停止HACMP服务HACMP实施“案例”Oracle RAC所需的HACMP环境。

IBM HACMP 配置

IBM HACMP 系列-- 安装和配置一规划是成功的实现的一半，就 HACMP 而言，如何强调正确规划的重要性都不过分。

如果规划做得不正确，您可能会在以后某个时候发现自己陷入种种限制之中，而要摆脱这些限制可能是非常痛苦的经历。

因此，请保持镇定从容，并使用产品附带的规划工作表；这些工作表对于任何迁移或问题确定情形或者对于为规划做文档记录都是非常有价值的。

一. HACMP 软件安装HACMP 软件提供了一系列可用于使应用程序高度可用的功能。

务必记住，并非所有的系统或应用程序组件都受到 HACMP 的保护。

例如，如果某个关键应用程序的所有数据都驻留在单个磁盘上，并且该磁盘发生了故障，则该磁盘就成了整个集群的单点故障，并且未受到 HACMP 的保护。

在此情况下，必须使用 AIX 逻辑卷管理器或存储子系统保护功能。

HACMP 仅在备份节点上提供磁盘接管，以使数据可继续使用。

这就是 HACMP 规划是如此重要的原因，因为整个规划过程中的主要目标是消除单点故障。

当关键集群功能由单个组件提供时，就存在单点故障。

如果该组件发生故障，集群没有提供该功能的其他途径，依赖该组件的应用程序或服务就会变得不可用。

还要记住，规划良好的集群非常容易安装，可提供更高的应用程序可用性，能够按预期执行，并且比规划不当的集群需要更少的维护。

1.1 检查先决条件在完成规划工作表以后，请验证您的系统是否满足 HACMP 所必需的要求；执行这项额外的工作可以消除许多潜在的错误。

HACMP V5.1 需要下列操作系统组件之一：（1）带 RSCT V2.2.1.30 或更高版本的 AIX 5L V5.1 ML5。

（2）带 RSCT V2.3.1.0 或更高版本（建议使用 2.3.1.1）的 AIX 5L V5.2 ML2。

（3）C-SPOC vpath 支持（需要 SDD 1.3.1.3 或更高版本）。

有关先决条件和 APAR 的最新信息，请参考产品附带的自述文件和以下 IBM 网站：/server/cluster/1.2 全新安装HACMP 支持网络安装管理（Network Installation Management，NIM）程序，包括“备选磁盘迁移”(Alternate Disk Migration) 选项。

BCManager VMware容灾管理详解

华为BCManager在VMware场景双站点部署（2）
适配方案主备容灾双活容灾形态分类生产和灾备中心均部署BCManager Server，生产中心的BCManager Server用于灾备策略制定和日常维护，灾备中心BCManager Server用于恢复。灾备中心BCManager不能同时访问生产和灾备中心业务和存储时选择该形态
华为BCManager FusionSphere场景容灾管理过程华为华为BCManager FusionSphere场景容灾部署形态
华为BCManager在VMware场景容灾架构
BCManager基于B/S架构，通过浏览器即可进行容灾的管理BCManager虚拟化容灾主要包含BCM UI和BCM Server系统： BCM UI提供图形化操作界面，用户可以通过浏览器访问来管理整个BCM系统 BCM Server安装在独立服务器上，生产端BCM提供基于策略的容灾保护功能；灾备端BCM提供容灾切换自动化调度功能组件间通信BCM间以及BCM与存储、FC、VRG之间：REST over Https BCM与FM： SOAP over Https
华为BCManager在FusionSphere场景容灾部署方案
适配方案：点对点容灾（主备、AA、互备）ROBO（多分支机构）容灾形态分类灾备中心部署BCM，部署简单，成本低，优选该形态。但要求生产端FM、FC、VRG间与灾备BCM管理网络互通生产和灾备中心均部署BCM主机，生产中心BCM用于灾备策略制定和日常维护，灾备BCM用于恢复，不能同时访问生产和灾备中心业务及存储网络时选择该形态
华为BCManager在VMware场景三站点级联部署
配置建议推荐配置两套BCManager Server，分别部署在灾备中心1与灾备中心2. 要求灾备中心1上的BCManager Server可访问生产中心的存储、虚拟化平台服务器有限情况下至少在灾备中心1配置BCManager Server（不建议）,要求BCManager Server可访问三站点上存储、虚拟化平台形态分类不支持同时部署3套BCManager主机客户管理或者存储网络不存在特殊情况

IBM存储灾备方案

IBM 存储灾难备份方案灾难备份方案1、灾难设计的目的随着信息技术的发展，企业越来越依赖于数据处理来进行它的商业行为，保证它在业界的竞争力。

数据处理的高可靠性和高可用性越来越成为关键。

如果企业发现数据丢失，业务的开展将变得极其困难，更为重要的是，企业将失去客户的信任以及一系列的企业赖以生存发展的市场。

核心数据的丢失，严重时完全有可能造成整个企业的瘫痪。

尽管随着科学技术的发展，计算机系统的可靠性日益增加，像IBM的HACMP高可用集群多处理技术可以在局域网范围内解决大部分的硬件和软件引起的系统不可用问题，但是由地震、洪水、火灾、战争等天灾人祸或由于软硬件故障而使生产系统整体无法正常工作等情况所造成的损失依然可以轻而易举地摧毁企业赖以生成的IT系统。

所以，在异地建立灾备中心对于极度依赖IT的企业便成了必然的选择。

IBM提供了从数据级到应用级的灾难备份解决方案。

其中数据级的方案采用PPRC。

传统的灾难恢复方法（如每天对重要文件进行磁带拷贝并将这些拷贝转移到远地点）仍然能够满足大部分公司的需要。

不过，某些公司的需求已经证明了使用远程拷贝功能的必要，远程拷贝就是在一个远地点维护生产数据的一份最新拷贝。

（远程拷贝也被称为远程镜像）。

业界有两种基本的基于磁盘系统的远程拷贝形式：同步远程拷贝：来自处理器的更新被写往本地连接的磁盘系统，该系统将数据转发给远地点连接的磁盘系统。

只有当两个系统都拥有数据的拷贝以后本地系统才会向处理器返回一个I/O完成指示。

同步远程拷贝能够在远地点提供最新程度的数据当前值，但应用程序会因等待写I/O操作的完成而被延迟。

异步远程拷贝：来自处理器的更新被写往本地连接的磁盘系统，该系统立即向处理器返回一个I/O完成指示。

更新在很短的一段时间(在实际中通常在数秒钟到一分钟左右)以后被送往一个远程系统。

异步远程拷贝对应用程序性能的影响最小，但远程磁盘系统在数据最新性方面与本地系统相比会有一个延迟。

如何进行计算机系统容灾方案和测试

如何进行计算机系统容灾方案和测试计算机系统容灾方案和测试在现代社会，计算机已经成为了人们生活和工作中不可或缺的一部分。

然而，由于各种原因，计算机系统可能会遭遇各种故障，例如硬件故障、软件错误、网络中断等等。

为了确保计算机系统的稳定运行以及数据的安全，进行计算机系统容灾方案和测试显得尤为重要。

首先，制定一套完善的容灾方案是保证计算机系统可靠性的基础。

容灾方案应该考虑系统的整体架构、数据的备份与恢复、故障的处理流程等方面。

系统的整体架构设计需要充分考虑到各种可能的故障场景，并在设计中引入冗余机制和备份策略。

对于数据的备份与恢复，应该设置合理的备份周期和备份介质，同时进行定期的恢复测试，以确保备份数据的可靠性和可用性。

对于故障的处理流程，应该明确责任人员和各个部门的职责和流程，以便能够迅速进行故障的排查和修复。

其次，进行计算机系统容灾测试是评估和验证系统容灾能力的关键步骤。

容灾测试可以分为两个阶段，即静态测试和动态测试。

静态测试主要是通过模拟真实的故障场景，如断电、断网等，来评估系统在不同故障情况下的表现。

动态测试则是在实际生产环境中进行，通过真实的故障恢复和数据恢复来验证系统容灾方案的可行性和有效性。

在进行容灾测试时，应该设置明确的测试目标和指标，并记录、分析测试结果，从而发现系统中的潜在问题并进行改进。

在实施计算机系统容灾方案和测试时，还需要注意以下几点。

首先是持续改进，容灾方案和测试不是一次性的工作，而是一个不断演化和完善的过程。

因此，应该定期进行系统和容灾方案的评估，并根据评估结果对容灾方案进行调整和优化。

其次是团队协作，容灾方案和测试需要各个部门之间的密切合作和协调。

因此，建立一个高效的沟通机制和团队合作意识是非常重要的。

此外，还需要加强员工的培训和技能提升，以确保团队成员能够熟练掌握容灾方案的操作和测试方法。

综上所述，计算机系统容灾方案和测试是保障计算机系统可靠性和数据安全的重要环节。

通过制定完善的容灾方案，进行规范的容灾测试，以及持续改进和团队协作，能够大大提高计算机系统的容灾能力，保障系统的稳定运行。

IBM的三种PowerAA高可用性容灾方案参考

一步满足合规要求(验证平台、准生产平台)等
• 区域性商业银行，以初步建立两地三中心容灾体系为目标。目前更关注于：同城容灾中心的建设和优化(提高应用覆盖范围、资源利用率)、异地容灾中心合规
3
双活并不只是IT技术组件的架构设计问题，还涉及到运维管理、自动化监控等诸多方面
双活网络架构设计以及快速切换问题
6A6A4334c03c30-S22t-S2tc2imcivy“voym“osadssdaosrrttateoaatbeiaAioArborti7tkli7kniiecncl8””8ess00::
After
32 static
采购成本
16 mobile 16 “dark”
128 core -----> 96 core
MetroMirror
Primary Site
DWDDMWMDUMX MUX
Router
Power 7 AIX 6.1 PowerHA Ent. Ed. 7 DB Bkup
SAN Switch
DS8800 (Secondary Storage)
MetroMirror
Secondary Site
7
Power DB2 GDPC 特性：<双活+容灾>
▪ 双活：自动负载均衡，节点可随需求增长而增长，不需修改程序。 ▪ 容灾#1：单节点故障发生时，客户端连接自动路由到余下节点。 ▪ 容灾#2：整站点故障发生时，客户端连接自动路由到余下节点
ClCielCnieltCnieltCnieltCnieltCnieltCnieltCnieltCnieltnietnt ApApplAipcpAlapipctAlipaiopcAtlnpiapcoAstlpainpcoAtlpainpcoAtlpianpcoAtlpainpcotlpiancotlaincotainotinon

IBM为用户提供第七级的容灾方案-安全软件解决方案

IBM为用户提供第七级的容灾方案-安全软件解决方案容灾对企业的重要性已无需多言，在需要全天候运行的全球经济环境中，没有一家企业能够承受宕机，无论是计划的宕机（升级、维护和修复）还是突发的宕机（由于人为错误、处理故障、电源故障、甚至灾难事件）。

但许多企业都制订了在24到48小时内恢复核心应用的业务连续性计划。

虽然数据丢失了24小时，但实现全面恢复需要数天或者数星期的时间。

这些企业通常依赖后台和人工流程来保持业务的正常运行，直到系统恢复为止。

随着信息成为越来越重要的企业资产，许多企业都致力于最大限度地降低宕机风险和避免业务中断的潜在影响，从而影响：生产力：由于系统闲置，您的员工和业务运营都会造成收入损失。

客户满意度：如果您不能及时响应客户需求，只需点击一下鼠标，他们就会转向另一家供应商。

业务合作伙伴和供应商关系：经常性宕机会引发对您业务的可靠性的质疑，从而驱使重要的合作伙伴和供应商与其它企业开展业务。

事实上，专家声称一个典型的计算基础设施的宕机估计为每小时42,000美元。

按照这一比例，1%的可用性改进都可能导致通过降低风险和提高生产力创造数百万美元的收入。

IBM Windows业务连续性（CA）旨在帮助您的企业显著减少宕机、提供高可用性和改进关键应用的灾难恢复。

灾难备份技术方案的七个级别：7 Tiers for Disaster Recovery Solution，是指根据国际标准SHARE 78的定义，灾难备份技术方案可以根据以下主要方面所达到的程度而分为七级。

目前大部分厂商的容灾技术最高达到了第6级，只负责复制数据，没有自动接管和启动应用的功能。

但很多用户真正追求的是第七级的容灾解决方案，即完全做到自动判断切换时机、自动切换、自动启动应用等，尽量减小容灾切换过程中的人为干预，减少人为的错误判断。

本文将重点介绍真正的第七级自动的容灾实现方式。

目前IBM本身存储的容灾软件（metro mirror）同主机的双机软件（如AIX 上的HACMP-XD）相结合可以到达真正的7级别的解决方案。

服务器容灾测试与演练

服务器容灾测试与演练在当今数字化时代，服务器的稳定性和可用性对于企业和组织来说至关重要。

不可避免地，服务器可能会面临各种故障和风险，如硬件故障、软件漏洞、自然灾害等。

为了确保服务器的高可用性和业务连续性，企业需要进行容灾测试与演练。

本文将探讨服务器容灾测试的重要性、常见的容灾测试方法以及容灾演练的步骤。

一、服务器容灾测试的重要性1. 保障业务连续性：容灾测试可以帮助企业确保即使在灾难事件发生时，业务能够持续运行。

通过模拟各种故障和风险，验证服务器的容灾方案是否能够在实际应急情况下有效运作，并及时采取措施修复问题，保障业务连续性。

2. 提升服务器可用性：通过容灾测试，企业可以发现服务器系统中的潜在问题并及时解决，以提升服务器的可用性。

容灾测试可以帮助企业识别硬件故障、软件漏洞和网络问题等潜在风险，并制定相应的应对方案，提高服务器的容错能力。

3. 降低经济损失：服务器故障可能导致企业的数据丢失、业务中断，进而造成巨大的经济损失。

容灾测试可以帮助企业及时发现并修复潜在的问题，减少因服务器故障而导致的经济损失。

二、常见的容灾测试方法1. 故障注入测试：故障注入测试是一种通过故意引发服务器故障来测试容灾方案的方法。

企业可以模拟硬件故障、软件故障、网络中断等场景，并观察服务器是否能够在出现故障时自动切换到备用服务器，并确保业务的持续运行。

2. 并发性能测试：并发性能测试是通过模拟大量用户同时访问服务器的场景，测试服务器的性能和承载能力。

在容灾演练中，企业可以模拟服务器的性能瓶颈，观察服务器是否能够应对高并发的访问请求，并及时切换到备用服务器以保障服务的可用性。

3. 数据恢复测试：数据恢复测试是测试服务器备份方案和数据恢复速度的方法。

企业可以模拟数据丢失的情况，并观察备份方案是否能够及时恢复数据，并确保数据的完整性。

三、容灾演练的步骤1. 制定容灾演练计划：在进行容灾演练之前，企业应制定详细的演练计划，明确演练的目标和流程。