业务连续性的命名标准

核心提示：简介系统、节点、主机和别名的计算机命名标准对于实现成功的业务连续性环境非常重要，这些标准必须提供一种定义 “企业范围惟一” 标识符的机制，业务连续性的命名标准，从而满足组织的所有计算机命名需求，计算机命名标准的考虑因素命名标准应该具备以下性质：是一致的并产生可重复的过程，只需从 HMC 生成 L

简介

系统、节点、主机和别名的计算机命名标准对于实现成功的业务连续性环境非常重要。这些标准必须提供一种定义 “企业范围惟一” 标识符的机制，从而满足组织的所有计算机命名需求。

计算机命名标准的考虑因素

命名标准应该具备以下性质：

是一致的并产生可重复的过程。

能够适应单独的环境、高可用性、灾难恢复、业务连续性、分区和虚拟化环境。

灾难恢复过程可以用它们消除资源冲突。

高可用性过程可以用它们消除资源冲突。

存储路径优先级机制可以用它们平衡 SAN 通信流负载。

etherchannel 适配器配置可以用它们平衡网络通信流负载。

主机以太网适配器 (HEA) 配置可以用它们平衡网络通信流负载。

可以用它们协调和平衡通过 VIO 服务器的 I/O。

可以用它们区分和定义分区、配置文件、节点和主机。

为了解释计算机命名标准对业务连续性的重要性，有必要定义 “业务连续性” 在本文中的含义。还要提供 “灾难恢复” 的定义，以便与业务连续性区分开。下面的两个定义摘自 Mt Xia: Technical Consulting Group 定义页面。

业务连续性（Business Continuity，BC） 业务连续性由日常执行的活动组成，其目的是确保业务在今天、明天及以后都会正常运营。业务连续性有时候可能与灾难恢复混为一谈，但它们实际上是不同的概念。灾难恢复只是业务连续性中的一个小子集。可以把业务连续性计划看作一种方法论，或者在整个企业范围内对运营日常业务的思维方式。 灾难恢复（Disaster Recovery，DR） 灾难恢复项目计划描述在发生灾难之后恢复关键业务功能所需的任务，灾难恢复是这种计划的实现。恢复在地理上分离的数据中心之间执行，需要在数据中心之间进行存储复制。

当前，系统设计领域的趋势是为每个应用程序或应用程序实例提供单独的系统，比如数据库、Web 应用程序或财务包。在过去，一个计算机系统包含在一套物理硬件中，包括机箱、CPU、内存、主板、适配器、磁盘等等。当前的 IBM 硬件平台使系统管理员能够把一个受管理的物理系统划分为多个称为逻辑分区（Logical Partition，LPAR）的系统。可以为这些 LPAR 分配受管理系统中包含的所有或部分硬件资源，比如 CPU、内存和 I/O 适配器。每个 LPAR 都可以用来运行通常在单独的计算机、高可用性集群或灾难恢复环境中运行的任何应用程序。

业务连续性的命名标准

实现这种环境需要一个命名结构，而不只是考虑系统中的单一主机名。必须采用一个可扩展的标准，它应该能够适应可能需要的任何环境。本文描述在为现代的分区和虚拟化业务连续性环境设计命名标准时必须考虑的一些需求。

受管理系统名

“受管理系统” 这个词是指一套物理硬件，其中包含 CPU、内存、I/O 适配器、存储磁盘等组件。它有时候也称为 “主机” 或 “系统”，可以按照逻辑划分为多个分区。在 IBM® System p® 系统中，受管理系统或主机并没有用户可以访问的网络地址，但是逻辑分区 (LPAR) 几乎总是有一个或多个网络地址。Hardware Management Console (HMC) 使用受管理系统名识别硬件的物理容器，此名称应该是企业范围惟一标识符。在默认情况下，当 HMC 发现一个新硬件时，它会自动生成和分配一个受管理系统名，此名称由硬件型号编号、型号类型和序号组成。因为这个受管理系统名包含物理机器的序号，所以确保它在整个企业范围内是惟一的。下面的表 1 给出一些自动生成的受管理系统名示例。

表 1. 受管理系统名示例

型号 编号	型号 类型	序列号	主机或 受管理系统名
9119	590	12A345B	Server-9119-590-SN12A345B
9117	MMA	12C678D	Server-9117-MMA-SN12C678D
9133	55A	066ABCD	Server-9133-55A-SN066ABCD

应该以这些自动生成的受管理系统名作为标准，因为它们符合可用的数据中心自动化软件的要求；但是，如果组织决定改变这些名称，那么要遵守以下原则：

只使用字母数字字符 —— 不使用空格、下划线、点号、逗号或其他标点符号。因为自动生成的命名结构包含连字符，所以如果需要的话，在新的系统名中可以包含连字符。

使用企业范围惟一名称，这意味着在组织中没有同名的其他实体。这意味着，不仅是其他受管理系统，而且其他分区、配置文件、节点、主机和别名都不使用相同的名称。对于此名称所指的实体不会产生混淆，应该能够立即看出它是一个受管理系统名。

使用受管理系统名特有的命名结构格式，从而进一步帮助识别受管理系统和组织中的其他实体。

逻辑分区 (LPAR) 名

在一个受管理系统中，可以把物理资源划分为称为逻辑分区 (LPAR) 的组。物理资源包括 CPU、内存、I/O 适配器、存储磁盘等。每个受管理系统可能划分为一个或多个 LPAR，每个 LPAR 需要一个名称。数据中心自动化技术的经验表明，这些 LPAR 的名称应该与每个操作系统实例使用的节点名对应，而且应该是在企业范围内惟一的 LPAR 名。详细信息参见 节点名 一节。

分区配置文件名

分区配置文件是与一个 LPAR 相关联的物理和虚拟资源的定义，一个 LPAR 可以有一个或多个配置文件。每个配置文件都必须有一个名称，此名称应该是在企业范围内惟一的配置文件名。与 LPAR 名一样，数据中心自动化技术的经验表明，默认的配置文件名应该与节点名对应，应该是在企业范围内惟一的配置文件名。可以为每个 LPAR 定义多个配置文件，每个额外的配置文件的名称应该是默认配置文件名的变体。详细信息参见 节点名 一节。

节点名

节点名与一个操作系统实例相关联，不应该与 TCP/IP 网络主机名混淆。主机名与一个网络适配器相关联。一个操作系统实例可以有许多不同的主机名，但是只能有一个节点名。另外，节点名总是与一个固定的操作系统实例相关联，而主机名可以在一个操作系统实例中的适配器之间、节点之间或跨数据中心转移。所有分区、主机和节点名都应该是在企业范围内惟一的，从而在故障转移期间避免冲突，无论故障转移是计划内、计划外、手工、自动故障转移，还是灾难恢复活动中的故障转移。为了适应数据中心自动化应用程序、软件和技术的需要，建议采用表 2 中提供的节点命名标准，但是在这些软件实体之间调整命名标准超出了本文的范围。

表 2. 节点命名结构

位置编码	+	操作系统类型	+	环境	+	应用程序编码	+	序列 ID
3 个字符	+	1 个字符	+	1 个字符	+	3 个字符	+	2 个字符

节点名应该只包含字母数字字符，应该在组织中的所有平台上保持一致。下面的表 3 详细解释节点命名标准的每个成分。

表 3. 节点名成分

节点名描述	字符数	示例值
位置编码	3	bos = Boston dal = Dallas phx = Phoenix
操作系统类型	1	a = AIX l = Linux o = OS/400 v = VIO Server w= Microsoft® Windows®
环境	1	a = Acceptance Testing d = Development p = Production t = Testing x = Disaster Recovery
应用程序编码	3	vio = VIO Server nim = NIM Server sap = SAP mqs = MQ Series ora = Oracle db2 = DB2 ifx = Informix
序列 ID	2	这是一个两字符的标识符，用来区分一个节点类型的多个实例。这个两字符的标识符可以包含以下字符： 0-9, A-Z, a-z

例如，假设在 Boston 数据中心有一个 AIX® 节点，它是一个运行 Oracle 的生产系统，是序列中的第一个节点。那么，它的节点名应该由表 4 所示的成分组成。

表 4. 节点名成分示例

位置编码	+	操作系统类型	+	环境	+	应用程序编码	+	序列 ID
bos	+	a	+	p	+	ora	+	01

主机名

主机名是 IP 地址的引用，而 IP 地址与一个或多个网络适配器相关联。一定要注意，一个 IP 地址不一定总是与固定的网络适配器相关联，而是可以跨适配器、节点和数据中心转移。主机名也是如此。应该认为主机名是独立于任何节点、受管理系统或数据中心的。为了在手工、自动或灾难恢复故障转移期间避免冲突，主机名必须是企业范围惟一标识符。

对于任何节点，可以创建一个或多个主机名来标识所有网络适配器。在一般情况下，每个节点有一个与节点名相同的主机名。以 表 4 中的 “bosapora01” 节点为例，这个节点名也用作主机名，与分配给节点的一个 IP 地址相关联。这里要指出的要点是，系统的节点名和主机名是不同的实体，在设计单独的、虚拟化和集群系统时应该这样看待它们。

额外的主机名

在灾难恢复期间避免网络冲突的最佳解决方案是，确保每个网络 (TCP/IP) 地址或名称都是在企业范围内惟一的值。如果组织有多个数据中心，生产数据中心的网络 (TCP/IP) 地址不应该被故障转移到 DR 站点。要想转移网络地址，就需要重新配置路由器和交换机，这可能会危及在接收灾难恢复工作负载的数据中心中运行的现有生产系统。因此，生产应用程序不应该依赖于特定的 TCP/IP 网络地址；否则，在发生灾难时这些地址会改变，应用程序就无法工作了。另外，应用程序和用户（非管理员）不应该通过服务的 TCP/IP 地址使用或指定网络服务；他们应该只使用符号名。应用程序和一般用户使用的符号名应该是指向主机名的 “别名”。

在这个上下文中，“节点” 是指一个操作系统实例，它可能是集群的一部分或单独的系统，节点名与主机名是不同的实体。节点名应该只由字母数字字符组成。可以基于系统的节点名派生出一个或多个主机名。表 5 给出 “bosapora00” 节点的五个主机名。

表 5. 节点和相关联的主机名

节点名	主机名	描述
bosapora00	bosapora00-bt01	引用在引导时分配给一个网络适配器的 IP 地址。
bosapora00	bosapora00-pr01	引用分配给一个总是存在的网络适配器的持久 IP 地址。
bosapora00	bosapora00-rg01	引用分配给一个在应用程序服务运行时可用的网络适配器的 IP 地址。
bosapora00	bosapora00-mt01	引用分配给一个总是存在的网络适配器的系统管理 IP 地址。
bosapora00	bosapora00	引用分配给一个在节点上总是可用的网络适配器的持久 IP 地址。

表 5 中有一个称为 “bosapora00” 的主机名，此名称恰好与节点名相同。一定要注意，尽管这两个名称相同，但是它们的用途是不同的。在此示例中，节点名不是在企业范围内惟一的值；每个节点名对应一个具有相同值的主机名。

别名

应用程序和一般用户引用的网络名不应该是 表 5 中给出的任何主机名；他们应该只使用这些主机名的别名，见表 6。

表 6. 主机名和别名

主机名	别名
bosapora00-rg01	myappl5
bosapdb201-rg22	db2sys
bosapmqs03-rg05	mqseries5

注意，表 6 中的所有主机名都有后缀 “-rg##”。这些后缀是称为 “资源组地址名” 或 “服务地址名” 的实体的引用。尽管这是一个集群概念，但是应该在所有节点上实现它：单独的节点、虚拟化节点和集群节点。服务地址名用来引用网络应用程序或服务。任何需要访问网络应用程序服务的应用程序或一般用户都应该只引用别名，别名把他们重定向到与服务 IP 地址相关联的服务地址主机名。

在发生灾难时，在系统的 DR 站点上用不同的 TCP/IP 地址、不同的节点名和不同的主机名重新启动生产应用程序。为了访问在 DR 站点上重新启动的应用程序，只需修改 DNS 中的别名，让它们指向 DR 站点上新的 RG 主机名。应用程序和一般用户不需要做任何修改，会自动地路由到正确的位置和应用服务器。

定义别名的规则比主机名宽松得多，但是别名也应该是在企业范围内惟一的标识符。别名可以是任意的名称，只要在域中是惟一的。这样就可以通过对于用户有意义的名称访问应用程序。例如，Boston 数据中心中的 Oracle 生产应用服务器的主机名是 “bosapora01”；但是，所有用户引用的别名是 “myappl5”。使用别名可以保留主机名所需的结构，同时简化用户使用的名称。

通信流的分布

对于要在跨双网络、交换机和 VIO 服务器平均地分布通信流，一种常用的技术是根据与节点名相关联的序列 ID 号自动地选择主路径和辅路径。例如，如果节点名的序列 ID 号是偶数，就选用偶数编号的存储通信适配器作为主路径，选用奇数编号的适配器作为辅路径。但是，这种技术假设每个节点上都有多个适配器，而且在每个受管理系统中编号为偶数和奇数的节点数量相等。这意味着，不应该把所有偶数编号的节点配置在一个受管理系统中，并把所有奇数编号的节点配置在另一个受管理系统中。

例如，在 表 7 所示的配置中，在偶数编号的客户机 LPAR 上，所有偶数编号的硬盘的主通信路径都是通过一个偶数编号的 VIO 服务器（实际上是通过一个偶数编号的虚拟 SCSI 适配器；这里假设偶数编号的虚拟 SCSI 适配器与偶数编号的 VIO 服务器相关联）。在偶数编号的客户机 LPAR 上，所有偶数编号的硬盘的辅路径是通过一个奇数编号的 VIO 服务器。当然，对于奇数编号的硬盘，采用相反的规则。

如果使用路径优先级脚本并把这种节点命名标准应用于一个 p590 受管理系统上的数十个 LPAR，那么对于偶数节点名的 LPAR，“hdisk0” 的主通信路径都是通过一个偶数编号的 VIO 服务器。因为 “hdisk0” 通常包含 “rootvg” 卷组，一个受管理系统上的所有 LPAR 的 “hdisk0” 的主通信路径都通过同一个 VIO 服务器是不合适的。因此，在两个受管理系统之间配置 LPAR 时，建议不要对一个受管理系统上的所有 LPAR 都使用偶数节点名，而在另一个受管理系统上都使用奇数节点名。否则，使用路径优先级脚本会导致偶数节点名的所有 LPAR 都使用偶数节点名的同一个 VIO 服务器作为 “hdisk0” 的主路径；而奇数节点名的所有 LPAR 都使用奇数节点名的同一个 VIO 服务器作为 “hdisk0” 的主路径（见表 7），这种配置是不合适的。

表 7. 不合适的通信路径

受管理系统名	客户机 LPAR 节点名	偶数 编号的 硬盘 主 VIOS	奇数 编号的 硬盘 主 VIOS
Server-9119-590-SN12A345B	bosapora00	bosapvio00	bosapvio01
	bosapora02	bosapvio00	bosapvio01
	bosapora04	bosapvio00	bosapvio01
	bosapora06	bosapvio00	bosapvio01
Server-9119-590-SN67D890E	bosapora01	bosapvio03	bosapvio02
	bosapora03	bosapvio03	bosapvio02
	bosapora05	bosapvio03	bosapvio02
	bosapora07	bosapvio03	bosapvio02

更合适的配置是把 “hdisk0” 的通信流平均分布给两个 VIO 服务器；如果在每个受管理系统中偶数和奇数节点名的节点数量相等，就很容易自动实现这种配置。表 8 给出一个更好的节点名配置方案，其中有 8 个 Oracle 服务器分布在两个 p590 受管理系统上，“hdisk0” 的通信流分布给两个 VIO 服务器。所有硬盘都是连续编号的，它们的主路径和辅路径会平均地分布。

表 8. 合适的通信路径

受管理系统名	客户机 LPAR 节点名	偶数 编号的 硬盘 主 VIOS	奇数 编号的硬盘 主 VIOS
Server-9119-590-SN12A345B	bosapora00	bosapvio00	bosapvio01
	bosapora01	bosapvio01	bosapvio00
	bosapora02	bosapvio00	bosapvio01
	bosapora03	bosapvio01	bosapvio00
Server-9119-590-SN67D890E	bosapora04	bosapvio02	bosapvio03
	bosapora05	bosapvio03	bosapvio02
	bosapora06	bosapvio02	bosapvio03
	bosapora07	bosapvio03	bosapvio02

当然，可以跨双 VIO 服务器手工配置存储和网络通信流的分布；但是，这会耗费许多时间和精力。另外，通过配置执行此任务的路径优先级脚本，可以反转分布通信流的逻辑，使管理员可以指定主路径和辅路径，但是这意味着管理员必须跟踪每个 LPAR 的配置方式，才能决定如何配置新的 LPAR。实现节点命名结构是更容易更高效的方法，这样至少可以自动执行这个配置过程的一部分，使管理员不必监视和跟踪 LPAR 配置信息。

结束语

用户和应用程序应该只使用别名引用网络应用程序服务，而不应该直接使用主机名或 TCP/IP 网络地址。访问网络应用程序所用的别名应该指向作为应用程序的服务名实现的主机名。每个网络适配器应该配置一个引导地址和相关联的主机名。可以根据需要在每个网络适配器上配置更多 TCP/IP 地址并分配相应的主机名。给每个操作系统实例分配一个节点名。此名称也用作分区和默认的配置文件名。通过使用节点名作为 LPAR 和默认的配置文件名，自动化脚本就很容易识别要操作和修改的 LPAR 和配置文件。另外，获取受管理系统上的节点名列表非常容易，只需从 HMC 生成 LPAR 的列表。由于每个节点都应该配置一个与节点名对应的主机名，因此也简化了网络访问。