AIX 灾难恢复

引言

在实施灾难恢复的过程中，您最不希望出现的是未预料到的硬件和软件资源冲突。这些冲突往往会消耗时间、人员资源，并导致恢复时间的目标无法实现。本文的目的是，确定导致资源冲突的最常见的原因，并提供相关的机制以避免或解决这些冲突。最理想的解决方案是完全地避免这些冲突，以便在实施灾难恢复的过程中根本不需要解决这些冲突。

许多 IT 部门尝试支持多种实现标准，其中一种用于非集群系统，一种用于集群系统，还有另一种用于支持灾难恢复系统。维护多种标准本身可能会导致在实施灾难恢复的过程中出现冲突。将它们整合为一组标准应该作为您的灾难恢复规划项目的目标，以及业务连续性的整体策略。

在实施 AIX® 灾难恢复的过程中，会碰到一些典型的问题，具体包括：

为进行灾难恢复而提供的系统（与生产系统相比，这些系统具有不同的类型、规模、以及容量；通常，这些系统将随着操作系统的更新而更新。）

用户和组权限问题

应用程序的多个实例（在生产中，每个应用程序会在单独的系统加以实现，并且在灾难恢复配置的单个系统中加以组合。）

网络命名和寻址问题

生产应用程序（在安装过程中绑定于某个特定的网络地址或者网络名）

节点名和主机名冲突（灾难恢复站点中现有的系统与在灾难恢复计划中实现的新的系统之间的冲突）

面向各种功能性系统类型（如独立、高可用性以及灾难恢复）的多种实现标准

本文中所讨论的资源冲突和解决方法假设组织具有多个运行生产系统的数据中心，并且每个数据中心都可以作为一个或多个其他数据中心的灾难恢复站点。本文中所提供的信息适用于任何数据中心和灾难恢复计划。

网络冲突

在实施灾难恢复的过程中，避免网络冲突的最佳解决方案是，始终确保每个网络地址 (TCP/IP) 或者名称在企业范围内具有唯一的值。在拥有多个活动数据中心的组织中，不应该将生产数据中心的网络地址 (TCP/IP) 故障转移到灾难恢复站点。要做到这一点，需要对路由器和交换机重新进行配置，并且这可能会使得数据中心中运行的现有生产系统承担灾难恢复工作负载。因此，生产应用程序不应该绑定于或者依赖于某个特定的网络 TCP/IP 地址，因为在发生灾难的时候，这些网络 TCP/IP 地址可能会更改，从而导致应用程序无法正常工作。应用程序和常规用户不应该使用 TCP/IP 地址、或者通过 TCP/IP 地址来指定网络服务，他们应该只使用符号名称。而且，应用程序和常规用户所使用的符号名称应该仅仅是一个别名，并且指向某个主机名。

在这种上下文中，节点 可以指向任何系统（作为一个整体），无论它是不是某个集群或者独立系统中的一部分，而节点名称 是独立于主机名的实体。节点名结构中只包含字母数字字符。可以根据系统的节点名导出一个或多个主机名。表 1 说明了一个名为 abcdefgh00 的节点具有五个主机名。

表 1：节点名和主机名

表 1 中还显示了一个名为 abcdefgh00 的主机名，它正好与该系统的节点名相对应。请务必认识到，尽管它们具有相同的名称，但它们的用途是不同的。

应用程序和常规用户所使用的符号名称不应该为表 1 中提及的任何主机名，并且他们应该只使用这些主机名的别名，如表 2 中所示。

表 2：主机名和别名

请注意，在表 2 中，所有主机名的扩展都是 -rg##。这些是对资源组服务地址的引用。尽管这是一个 HACMP 概念，但是它可以用于任何集群的或者独立的系统，以指向某个系统提供的网络服务。任何需要访问系统网络服务的应用程序或者常规用户应该只引用别名，通过别名可以将他们重定向到资源组主机名，而资源组主机名会将他们重定向到资源组服务 IP 地址。

在发生灾难的时候，在系统的灾难恢复站点中使用不同的 TCP/IP 地址、不同的节点名称，以及不同的主机名重新启动生产应用程序。要为灾难恢复站点中刚刚重新启动的应用程序提供访问，唯一所需的更改是，在 DNS 中将这些别名重新指向灾难恢复站点中新的资源组主机名。不需要对应用程序和常规用户进行任何更改，并且所有的应用程序都将自动地重新路由到正确的位置和应用服务器。

用户名

在整个企业的范围内，应该为组织中的每个人分配唯一的标识符，并且当他离开组织之后，不再继续使用这个标识符。这样可以确保在评估问题、难题和操作时进行无缝审核跟踪。用户名应该由字母数字字符组成，并且对于组织内部所有的系统都应该是有效的结构，以便每个人只使用一个用户名。指定一个适用于所有系统的用户名结构并且提供一定的灵活性，这可能是一项棘手的任务。这是因为大多数组织现在运行着各种各样的操作系统，而每种操作系统对用户名结构都有各自的要求。要设计一种通用的用户名结构，您必须考虑到 Microsoft® Windows®、UNIX® 的多个变体、Linux®、OS/400®、RACF® 以及其他操作系统的需求。

有一些用户名结构看上去可以适用于这些环境，包括：

四到七个小写字母和字母数字字符，以字母开头。

七个小写字母和字母数字字符，前三个字符为字母，而后四个字符为数字。

七个小写字母和字母数字字符，前四个字符为字母，而后三个字符为数字。

当然还有一些其他用户名结构也是有效的，但上述这些是最常用的结构。这些结构提供了所需的共同点以满足大多数需求，并提供足够的灵活性，以便用于大型和小型组织。

用户 ID 和 组 ID 编号

在灾难恢复规划过程中，必须意识到，分配给用户和组的用户 ID (UID) 和组 ID (GID) 编号应该在企业范围内是唯一的，以避免在实施灾难恢复的过程中出现冲突或者安全破坏的情况。

为了避免维护工作，并支持保存 UID 和 GID 值及其关联用户和组名的数据库的问题，应该使用一种可再现的算法来计算 UID 和 GID 值。一种执行 UID 和 GID 计算工作的简单算法是，使用 sum 命令和 -r 选项以生成 Berkeley 校验值。下面的示例中使用了这种技术：

$ print "abc1234" | sum -r
　29247　1

本系列文章中所有的命令都采用了 Korn Shell 语法。

下面是上述命令的一个变体，其中使用了 Korn Shell 93 语法：

/usr/bin/ksh93
　UID=$( print "abc1234" | sum -r )
　UID=${UID//[!0-9]/}
　print "UID=${UID}"

该技术的一个限制是，对于三个小写字母加上四个数字的指定用户名格式，它仅计算 600 到 65,000 之间的编号。所以，整个企业内用户和组的数目必须小于 65,000，并且采用这个算法可能会出现重复的值。

资源组名

这里所使用的资源组的概念，要比高可用性实体的范畴更大一些。资源组用于定义资源的任何逻辑集合，它可能包括磁盘、I/O、用户、应用程序，等等，无论节点是否参与到一个高可用性集群或者灾难恢复提供方案。在这种上下文中，应该将资源组看作独立于任何计算机、服务器、或者数据中心。

下面提供了关于定义资源组名的标准：

表 3：资源组名结构定义

表 4 中描述了资源组名中每个成分的详细信息。

表 4：资源组名结构定义

表 5：资源组名示例

卷组名

为了帮助实现一般的维护、灾难恢复和业务连续性，建议在企业范围内为每个卷组名使用唯一的值。一个 AIX 系统可能包含多个资源组，并且通常为每个资源组定义一个卷组。然而，一个资源组可能包含几个卷组，这取决于应用程序的需求。

卷组名应该是基于前面定义的资源组名的，并且在字符 vg 后使用两位数字的序列编号唯一地标识该卷组。

使用这个标准，卷组名恰好由 12 个字符组成，并具有下面的结构：

表 6：卷组名结构定义

逻辑卷名

在企业范围内，将这种唯一性的思想扩展到逻辑卷名，这样可以在发生计划内或者计划外停机时，在执行系统故障转移的过程中避免命名冲突。逻辑卷名也应该基于前面定义的资源组名。每个逻辑卷都关联于一个卷组，并且每个卷组通常包含几个逻辑卷。

使用资源组名定义一个逻辑卷名，确定这个逻辑卷属于哪个卷组和资源组。然后，添加四个字符的字母数字标识符，字符 lv 后面的这个标识符可以唯一地标识逻辑卷。

表 7：逻辑卷名结构定义

日志逻辑卷名

JFS 和 JFS2 文件系统需要一个用于 JFS 日志的逻辑卷。同样地，也需要在企业范围内使用唯一的名称。日志逻辑卷名结构应该与前面定义的逻辑卷名结构相同；然而，逻辑卷序列标识符应该包含字母字符 jfs，后面加上单个数字以唯一地标识这个名称。为一个日志中的每个卷组定义逻辑卷；然而，可以定义多个逻辑卷。作为一个示例，名为 db2apmx0 的资源组可能拥有一个名为 db2apmx00vg 的卷组。这个卷组拥有多个与其相关联的 JFS 日志逻辑卷：

表 8：日志逻辑卷名结构定义

文件系统装入点目录名

为了确保在灾难恢复场景中将一个应用程序的多个实例恢复到单个系统，每个包含应用程序文件的文件系统都应该在企业范围内具有唯一的装入点目录。要实现这一点，最好的方法是，使用资源组名或者逻辑卷名的一个子字符串作为顶层目录，因为通常每个逻辑卷都需要一个文件系统装入点。

作为一个示例，名为 db2apmx0 的资源组可能拥有多个与其相关联的文件系统：

表 9：文件系统装入点目录名定义

结束语

在企业范围内对资源进行唯一地命名，这样可以提供一种有效的方法，以便在灾难恢复或者高可用性故障转移的过程中避免发生冲突。使用资源组名作为这种方法的基础，可以将其扩展到比本文中所介绍的更大的范围。附加的潜在资源冲突包括：

应用程序启动和终止脚本的文件名

工作负载管理器 (Workload Manager) 的类和子类

性能监视

作业调度

打印队列

Tivoli Storage Manager

MQSeries

本文中所描述的标准并不一定适合您的组织的特定要求和需求；然而，对本文中的基本原则进行相应的修改，您的组织就可以得到类似的标准，以帮助解决或者消除这些潜在的冲突。不要等到必须使用它们的时候才确定所需的标准，比如在出现了计划内或者计划外停机的情况时。

要避免资源冲突，组织需要采用企业范围内的业务连续性思想。而且，业务连续性必须作为系统设计工作中的起点，而不是终点。不幸的是，很少有系统在构建时考虑到后面的业务连续性。