IBM PureApplication System V2.0 引入了对多系统管理和部署的支持。通过将多个 PureApplication System 添加到一个管理域中,您可以跨该域中的多个系统执行目录和用户管理。在管理域中,可以创建一个或多个部署子域。 部署子域 使得模式和共享的服务可同时部署在两个系统上。这提供了额外的灵活性,简化了 IBM WebSphere Application Server、IBM DB2® 和 IBM Business Process Manager 等产品的高可用性的实现。
本教程的目的是帮助您使用 IBM PureApplication System 设置一个管理域和部署子域。您还将了解设置管理域和部署子域的需求。最后,您将了解使用部署子域来部署模式时面临的限制。本信息会为您规划多系统 IBM PureApplication System 实现提供一个基于事实的开端。
在设置您的域之前,一定要在所有 IBM PureApplication System 上安装 2.1.0.0 Interim Fix 1 或更高版本。
回页首
在通过模式部署某些 IBM 产品时,多系统部署可提供明显的优势。当然,您首先至少需要两个 PureApplication System。执行第一次多系统部署之前,还需要拥有以下资源:
外部托管的环境配置文件准备就绪之后,就可以使用该环境配置文件执行多系统部署了。
图 1 给出了一个包含两个部署子域的管理域的示例。
图 1. 管理域和部署子域
以下规则在设置管理域和部署子域时适用:
在实现之前,一定要仔细想好想要的设置。当某个管理域已经存在后,如果其中的一个系统也包含在部署子域中,则无法从该域中删除该系统。此外,如果不删除部署子域,则无法从子域中删除系统。要删除子域,首先需要 删除 子域中所有部署到 外部托管的 环境配置文件的模式实例和共享服务。甚至在外部托管的部署的虚拟机仅位于子域中的一个系统上时,也应如此。
回页首
创建 PureApplication 管理域之前,让我们看看网络和安全需求。
使用 PureApplication Software 时,不需要配置额外的 IP 地址。
PureApplication System 必须配置一个或两个额外的系统管理 IP 地址,然后才能将它们添加到域中。这些地址用于对部署的虚拟机执行工作负载管理;它们的使用会在后面的外部云组配置部分中进行更详细的介绍。这些额外的 IP 地址是在 System > Network Configuration 面板上的 “Additional IPs for Cloud Management by way of External Networks” 部分进行配置的。
尽管在 IP address 1 下也列出了系统控制台的动态地址,但此地址无法在这一部分中编辑。它只是用于提醒。
PureApplication System 型号 1500 和 2500 必须配置一个额外的 IP 地址,如图 2 所示;PureApplication System 型号 1700 和 2700 必须配置两个额外的 IP 地址。在两种情况下,新地址都必须在与现有系统管理 IP 地址相同的子网内定义。额外的管理地址只能是 IPv4 地址。
图 2. 在 PureApplication System 型号 W1500/W2500 上配置额外的工作负载控制台访问管理 IP 地址
必须确保管理域中的 PureApplication Systems(或 PureApplication Software 安装)在它们的所有系统管理 IP 地址之间共享 IP 连接。如果在二者的系统管理 VLAN 之间有一个防火墙,则应确保已允许使用 ICMP 流量以及端口 22、443、1191 和 49300–49320 上的 TCP 流量。
图 3 给出了计划创建一个包含两个 PureApplication System 的域时的需求。
图 3. 一个管理域中的两个 PureApplication System 的网络
默认情况下,PureApplication Systems 配置为信任 IBM 预先安装的 IBM 自签名控制台 SSL 证书。如果为控制台配置了您自己的 SSL 证书,则必须将此证书导入到域中其他所有系统的信任存储中。图 3 给出了一个包含两个 PureApplication System 的域中的信任关系。
在将系统添加到域中之前,在导入新控制台证书之前,以及在每次升级域中的 PureApplication System 之后,必须执行此操作。
执行以下过程来将控制台证书导入到域中其他所有系统的信任存储中。
$ bin/pure -h hostnameA -u user -p password -c "print admin.racks[0].location_name"
1000056
$ bin/pure -a -h hostnameB -u user -p password -c
"deployer.peercertificate._import({'certfilepath':'systemA.crt','peername':'1000056'})"
$ bin/pure -a -h hostnameC -u user -p password -c
"deployer.peercertificate._import({'certfilepath':'systemA.crt','peername':'1000056'})"
管理域中的所有系统都必须配置为使用 LDAP 且使用相同的 LDAP 配置。这可在 System > System Security 下配置,如图 4 所示。
图 4. PureApplication Web 控制台中的 System Security
点击查看大图
关闭 [x]
实际上,这会让系统拥有用于用户身份验证的共享的信任权威。大多数子域活动都需要 LDAP 用户,比如复制工件或部署模式,如图 5 所示。
图 5. PureApplication Web 控制台中的 LDAP 用户示例
如果安全管理员是 LDAP 用户且拥有域中所有系统上的足够权限,那么用户角色编辑器会提供一个按钮,安全管理员可以使用该按钮来累积性地将用户的角色分配设置传播到域中的其他所有系统。
尽管用户身份验证是在域中的系统之间共享的,但基于角色的用户权限(授权)在每个系统的 本地 管理;用户角色必须在域中的每个系统上手动分配。
域管理操作可由 本地 用户执行,只要他们拥有该系统上的足够权限。
为了将系统添加到域中,用户必须在执行添加操作的系统上拥有完整的安全和硬件管理权限,还必须提供用户凭据,在将要添加到域中的系统上拥有完整的安全和硬件管理权限。将系统添加到域中会在该系统与域中的其他所有现有系统之间建立一种信任关系。
其他所有域和子域操作(创建子域、将系统添加到子域、删除子域、从域中删除系统)只需执行该操作的系统上的硬件管理权限。
图 6. 在 PureApplication Web 控制台中创建管理域
尽管模式不会自动在系统之间同步,但在跨部署子域中的两个系统部署一种模式时不需要同步。只要执行部署的系统的本地目录包含正确的模式,两个系统就会采用相同的模式。
目录内容可在同一个管理域中的系统之间传输和同步。这些操作可从 Web 控制台执行或通过命令行接口执行。但是,在 PureApplication System V2.1 中,此功能仅限于虚拟镜像、脚本包和加载项。所以,举例而言,虚拟系统模式将需要手动导出和导入。
在升级系统的时间里,您的域和子域可能拥有不同版本级别的系统。PureApplication System 支持此配置,但有一些限制。
版本说明中记录了特定于具体的 PureApplication System 版本的额外考虑因素。PureApplication V2.1.0.0 拥有特定的共存需求。
回页首
两个系统和部署子域中部署的实例之间会进行大量的协调和通信,所以部署子域需要满足许多前提条件、配置需求和限制。
子域中的两个 PureApplication System 具有一种镜像关系:它们实时共享部署的实例的信息。此数据存储在一个名为 SubdomainData 的新 LUN(逻辑单元编号)中,子域创建完成时会在每个系统的主存储节点上创建该 LUN。每个系统上至少有 512GB,它才能添加到子域中。您可以从 Hardware > Storage Devices 验证空想存储容量。图 7 中显示了一个示例。
图 7. 在 PureApplication System 中的主存储节点上配置空闲存储容量
由于子域通信的延迟限制,您子域中的系统不应相距超过 300 千米远。这种镜像关系还需要您提供一个外部 iSCSI 目标来用作 tiebreaker。这样,在这些系统彼此失去联系时,它们可确定法定容量。该 iSCSI 目标必须拥有最少 1GB,而且应遵守与系统相同的距离和延迟建议。
因为 tiebreaker 用来建立法定容量,所以如果子域中的系统使用不同的电源和子网,建议您将 tiebreaker 放在第三个电源和网络上。您的防火墙必须允许 PureApplication System 上的主要、辅助和动态管理 IP 地址与 iSCSI 目标的至少一个 IP 地址之间的 iSCSI 流量(端口 860 和 3260 上的 TCP 流量)。图 8 演示了这些提供与 tiebreaker 之间的连接。
图 8. 系统与 iSCSI tiebreaker 的通信
在 PureApplication System V2.1.0.0 之前,iSCSI 目标需要拥有一个小于 4096 字节的扇区。PureApplication System 2.1.0.0 和更高版本支持更大的扇区。我们已在 IBM XIV、IBM V7000、IBM SVC、Linux®、AIX® 和 Windows® 上使用 iSCSI 目标成功执行过子域部署。在 Linux 上,基于我们的测试,推荐使用 scsi-target-utils 1.0.24 或更高版本;我们发现在更早的版本上很难持久保存 iSCSI 配置。
如果两个系统都无法访问 tiebreaker,但仍可彼此通信,那么子域可用性不受影响。如果这些同时彼此失去了联系,但仍然能够与 tiebreaker 通信,那么成功通信的系统仍能够维护子域。在无法访问子域的系统上,会实际冻结向外部环境配置文件的部署:现有的部署无法扩展,新部署无法执行,而且部署无法删除。
在这个内部镜像上存储和共享的部署数据没有加密,无论是系统存储控制器上的静止数据,还是在它与系统建立镜像后在系统管理 IP 地址之间传输的数据。此数据包含系统用来管理部署的实例的安全密钥。您应为系统计划足够的物理安全保护,为移动数据计划足够的网络安全保护。
管理域和它的部署子域通过 PureApplication Web 控制台来配置。转到 System > Management Domain Configuration 并单击 Create Deployment Subdomain ,如图 9 中所示。
图 9. PureApplication Web 控制台中的部署子域配置
创建子域后,可通过以下方式向子域添加 PureApplication System:将它们拖放到子域上,或者单击子域中的 Add a Location 按钮。将第二个系统添加到子域时,系统会提示您配置 iSCSI tiebreaker,如图 10 所示。(请注意,这里的用户和密码是可选的。)
图 10. iSCSI tiebreaker 配置对话框
配置 iSCSI tiebreaker 后,系统将完成子域的创建,此过程会花几分钟。完成后,部署子域类似于图 11。
图 11. PureApplication Web 控制台中配置的部署子域
回页首
在 PureApplication System V2.0 之前,会为每个云组自动创建一个内部 IPv6 管理 VLAN。这个 VLAN 用于在 PureSystem Management Node (PSM) 与 VM 之间通信,也可用于在共享服务与 VM 之间通信。
本节简要介绍了创建和使用外部托管的云组所需满足的需求,您也可以参阅这篇文章。
为了支持多系统部署,V2.0 中引入了外部托管的云组。这些云组使用了一个外部管理 VLAN,而没有使用内部 IPv6 VLAN 来进行管理通信。部署子域中的两个系统之间的管理通信需要这个 VLAN。
PureApplication System 仍然全面支持内部托管的云组。尽管多云和多系统部署需要外部托管的云组,但与内部托管的云组相比,它们有一些限制,稍后将会介绍它们。出于这个原因,您应评估部署需求,仔细计划计算界线向内部或外部托管的云组或二者的分配。可以将现有的云组从一种管理类型转换为另一种管理类型。
创建外部托管云组之前,需要在您的网络中设置一个外部 VLAN,将这个 VLAN 配置为连接到 PureApplication System。在后面,您会看到还需要为这个外部管理 VLAN 创建一个 IP 组,以及一个特殊的环境配置文件。
使用外部托管的云组时,PureSystems Managers 必须能够通过外部云组管理 VLAN 访问部署的虚拟机。这需要向 PureApplication 管理网络公开额外的管理服务。它们必须能够访问从这个外部网络访问外部云组管理网络。通常,这需要在数据中心网络中的这些 VLAN 之间设置路由。
除了(动态)系统控制台 IP 地址之外,还必须为工作负载控制台配置 PureApplication 管理网络中的 IPv4 地址。使用 PureApplication System 型号 1700 或 2700 时,还需要为 DLPAR Management 分配另一个 IPv4 地址。新 IPv4 地址必须位于现有 PureApplication 管理网络中;也就是说,使用与原始(动态)系统控制台 IPv4 地址相同的网络和子网。
您之前在将系统添加到管理域之前,已定义了这些额外的管理地址。
图 12 中的图展示了系统管理 VLAN 上的管理 IP 地址如何与部署的虚拟机进行交互。要知道,系统管理 VLAN 与云组管理 VLAN 之间需要 Data Center Network 中的路由。
图 12. 在 PureApplication System 型号 W1500/W2500 上配置额外的管理 IP 地址
在创建新的外部托管云组之前,必须拥有定义至少一个 用于 云管理 用途的 IP 组。定义这样一个 IP 组与定义用于数据的 IP 组没什么不同,它是一个普通的 IP 组。图 13 展示了如何定义这个用于管理云的 IP 组。请记住将它分配给您之前定义和配置的云组管理 VLAN。
图 13. 配置一个用于管理云的 IP 组
在 Web 控制台中,可以看到这个新 IP 组确实用于管理云。可以在图 14 中看到一个例子。
图 14. 配置一个云管理 IP 地址
您虚拟机的默认路由通常分配给第一个数据接口(eth1 或 en1)。出于这个原因,现在必须为管理接口 eth0 或 en0 配置额外的路由,以确保管理流量不会通过 eth1 或 en1 路由。可在 IP 组定义中定义额外的路由。
您必须为每个云管理 IP 组配置以下路由:
不需要配置到远程系统的系统管理网络的路由。
前面已经提到,数据中心网络中的各个 VLAN 之间必须存在 3 层网络路由。图 15 给出了两个 PureApplication System 的这一配置。已为以下 VLAN 设置了路由:
图 15. 外部托管的部署的管理通信
可使用所包含的示例 Python 脚本validateRouting.py,验证您的外部托管环境配置文件所引用的所有管理 IP 组的路由配置。此脚本可从任何系统运行,只要它可访问 PureSystems Manager 的动态地址。因为此脚本使用环境配置文件来推断哪些 IP 组需要拥有到彼此的路由,所以您需要在运行该脚本之前创建和配置您的环境配置文件。使用至少拥有 “查看所有工作负载资源” 和 “查看所有硬件资源” 权限的 LDAP 用户名来运行此脚本。可使用此脚本来测试单个系统上的外部管理配置,以及多系统子域;如果测试多系统子域,则应该单独验证两个机架。
为了简便起见,我们使用了 PureApplication 命令行接口。清单 1 展示了如何运行该 Python 脚本。如果未找到预期的路由,该脚本将报告警告;如果所有预期的路由都已正确配置,将成功运行。
清单 1.
C:/Tools/pure.cli/bin>pure -h intel-system-2 -u admin -p ******** 15 -f C:/Temp/validateRouting.py Checking profile ExtMgdTest Checking profile RedBook HADR External Checking profile RedBook-External-R1R4 Checking profile Redbook-External-R1R4 w10.x.x.x SUCCESS
另请记住,需要满足端口和协议的一些具体需求。请参见参考资料了解有关的更多信息。
图 16. 创建外部托管的云组
在创建外部托管的云组时,不要选择 VLAN ID。相反,应该创建一个或多个指定用于 “云管理” 而不是 “数据” 的 IP 组。这些 IP 组用于将 IPv4 地址分配给部署在这些云组中的虚拟机的管理接口。与用于数据流量的 IP 组一样,您的云管理 IP 组中的地址必须在 DNS 中定义了前向和反向查找。
系统不会对用于管理 IP 组的 VLAN 执行任何需求。可创建仅用于 VM 管理的新 VLAN,或者可与数据 IP 组共享相同的 VLAN。在任何情况下,您的外部托管云组都不会标记为 “可用”,直到它们为管理和数据用途定义了 IP 组。
为了部署到这些外部托管的云组中,您还必须创建引用这些云组的外部托管的环境配置文件。不能混合使用内部托管的云组与外部托管的环境配置文件。
外部托管的环境配置文件是多系统部署中的系统之间的集成点。可将任意一个系统的外部托管云组添加到外部托管的环境配置文件中。
回页首
无论部署到单个系统还是多个系统,向外部托管环境配置文件的部署都需要执行一些激活和接口更改,以建立外部托管的网络接口和在单个部署的实例中引用多个系统和云组。这意味着只有新的模式内容支持部署到外部托管的环境配置文件。以下限制适用:
使用一个或多个 Hypervisor Edition 虚拟镜像的模式无法部署到外部托管的云组。因此,经典(和升级的经典)虚拟系统模式无法用于多系统部署。尝试部署将得到此错误:
CWZKS0417E:Failed to deploy because one or more virtual images do not support multi-target deployment.
要将虚拟机放在部署子域中的两个系统的云组中,需要在部署时进行设置。部署后,虚拟机无法从一个系统上的云组迁移到另一个系统上的云组。
在跨子域中的多个系统部署一个模式时,该模式本身只需存在于部署系统上。但是,对于放在任何给定系统上的每个虚拟机,该系统必须已包含该虚拟机需要的所有模式工件的准确副本:虚拟镜像、脚本包、模式类型、插件、软件组件、安装管理器存储库等。系统将在其放置建议和验证过程中验证此条件,安装管理器存储库内容除外。可以让系统选择所有虚拟机的放置位置,或者可以选择您自行放置。
因为外部托管的部署可能涵盖多个云组,所以在此情况下将共享服务限定到单个云组没有意义。相反,部署到外部托管环境配置文件时,会在环境配置文件的范围建立共享服务关联,而不是云组范围。所以,使用外部托管的环境配置文件时,需要为每个配置文件部署一个共享服务实例。这有助于将应用程序彼此隔离,或者甚至将生产环境与非生产环境隔离。图 17 演示了内部和外部托管的环境配置文件在发范围上的区别。
此考虑因素适用于所有外部托管的环境配置文件,无论您的系统当前是否在一个部署子域中,以及无论您的环境配置文件当前是否包含来自多个系统的云组。您应小心地计划外部托管的云组和环境配置文件配置,避免需要的共享服务部署数量成倍增长。
图 17. 内部和外部托管的环境配置文件的共享服务范围差异
为了让用户身份可在系统之间证实,有可能跨越多个系统的所有工作负载相关操作都需要一个 LDAP 用户。这意味着,除了需要授予每个系统上的合适的访问权,您还必须以 LDAP 用户身份登录,才能创建、查看或管理外部托管的配置文件 - 才能创建、查看或管理向这些配置文件的部署。所有这些资源都对非 LDAP 用户隐藏,无论这些用户的访问级别和角色是什么。多系统环境配置文件和部署的访问控制,会自动在子域中的系统之间同步。
多系统部署为跨系统或数据中心的模式实例的高可用性奠定了基础。但是,此可用性依赖于您应用程序的设计和它使用的所有服务。该应用程序和它的服务必须正确地设置和配置来支持高可用性,才能容忍对一个系统上的虚拟机的访问丢失。
当某个虚拟机失败时,如果该虚拟机被视为非持久性的,在许多情况下系统将尝试克隆一个新虚拟机来恢复它。对于多系统部署,只能在与最初失败的虚拟机相同的系统上尝试恢复。持久和非持久虚拟机上的后台信息记录在 PureApplication 知识中心 中。
多系统部署的横向扩展会尝试跨云组和系统而大体平衡虚拟机。但是,如果一个新虚拟机的实例最初未部署到一个云组或系统,横向扩展无法将它部署到该云组或系统。因此,要实现高可用性,必须确保最初的部署将您的可扩展虚拟机的至少一个实例放在每个系统上。
每个共享服务有一个叫做 共享服务提供程序 的实体仅存在于发起该共享服务部署的系统上。这意味着,如果这个部署系统临时对子域不可用,新的共享服务客户端将无法连接到该共享服务,即使剩余系统上的共享服务 VM 仍能够为客户端服务,即使客户端 VM 都在仍可用的系统上。
回页首
本文介绍了如何配置一个多系统域和子域,以及多系统部署需要的其他所有资源,包括 IP 组、云组和环境配置文件。本文旨在帮助您了解多系统部署的需求和限制,为计划您的多系统实现做更好的准备。
回页首
描述 | 名字 | 大小 |
---|---|---|
示例脚本 | validateRouting.py | 8 KB |