并行综合系统原则
Parallel Sysplex ® 是 z/OS® 系统的集合，可协同使用某些硬件和软件组件来实现高可用性工作负载处理环境。
- 基本综合系统是在 1990 年推出的。
- Parallel Sysplex 于 1994 年推出，新增了耦合设施。
- 减少/除去服务器， LPAR 和子系统中的单点故障
- 提高了应用程序可用性
- 单个系统映像
- 动态会话平衡
- 动态事务路由
- 可扩展容量
并行综合系统组件
并行系统复用是一组系统，所有这些系统都可以访问相同的一个或多个耦合设施。 虽然基本综合系统是具有已定义名称 (综合系统名称) 的实际实体，但并行综合系统更具概念性。 没有单个位置可维护 Parallel Sysplex 的名称及其包含的系统列表。 并行综合系统有许多组成部分:
- 锁定:
用于对具有高粒度的数据进行序列化。 例如，锁定由 IRLM 用于 IMS DB 和 IBM® MQ 数据库，以及由 CICS® 在使用 DFSMS VSAM RLS 时使用。
- 缓存：
用于存储数据和维护本地缓冲池一致性信息。 例如，高速缓存由 DFSMS 用于目录共享， RACF® 数据库， IBM MQ 数据库， IMS的 VSAM 和 OSAM 数据库以及 CICS 在使用 DFSMS VSAM RLS 时使用。 高速缓存同时包含目录条目和可选数据条目
- 列表
用于共享队列和共享状态信息。 CICS 使用的列表结构包括耦合设施数据表 (CFDT) ，指定的计数器， CICS 共享临时存储器和 CICSPlex ® SM 区域状态。
z/OS 的跨系统扩展服务 (XES) 组件使应用程序和子系统能够利用耦合设施。
Parallel Sysplex 的高可用性特征依赖于以非中断方式将结构从一个 CF 移动到另一个 CF 的能力，从而允许 CF 脱机以进行服务，而不会影响使用该 CF 的系统。 所有并行综合系统都应该至少有两个 CF ，并且这些 CF 应该可供综合系统的每个成员访问。
z/OS 要求数据集 (建议使用备用数据集以实现可用性) 由 Parallel Sysplex 中的所有系统共享。 z/OS 将与 Parallel Sysplex ，系统， XCF 组及其成员相关的信息存储在综合系统耦合数据集中。
跨系统耦合设施 (XCF) 服务允许一个系统上的授权程序与同一系统或其他系统上的程序进行通信。 如果系统发生故障，那么 XCF 服务还为要在综合系统中的另一个合格系统上重新启动的批处理作业和启动式任务提供功能。
应用程序组件是针对 XCF 定义的，并且了解是否存在支持该应用程序的其他组件。 如果一个组件发生故障， XCF 会自动通知其他组件。 有关 XCF 的更多信息，请参阅 z/OS MVS Programming: Sysplex Services Guide 中的 "XCF 概念"。
综合系统中的节点使用 XCF 通信服务 (XCF) 在综合系统 TCP/IP 堆栈之间执行协调，发现何时启动新的 TCP/IP 堆栈，以及了解 TCP/IP 堆栈何时停止或离开 XCF 组 (发生故障后)。 此信息对于自动移动应用程序和使综合系统分发器能够做出智能工作负载管理决策至关重要。 XCF 通信消息可以通过耦合设施传输，也可以直接通过 IBM Enterprise Systems Connection (ESCON) 或 IBM 光纤通道连接 (FICON ®) 传输。
z/OS System Logger 提供了用于保存和重新调用日志记录的通用日志记录功能。 它提供了单个系统日志，用于组合综合系统中所有系统的所有信息。 系统记录器的利用程序包括 OPERLOG (用于综合系统范围的系统日志) ， LOGREC (用于综合系统范围的错误信息) 和 CICS(用于将其 DFHLOG 和 DFHSHUNT 日志记录写入记录器)。
z/OS 的一个组件，它提供在一个 z/OS 映像内或跨多个映像同时运行多个工作负载的能力。
并行综合系统网络
设计用于高可用性的 Parallel Sysplex 环境的总体目标是创建一个环境，其中任何单个组件的丢失都不会影响应用程序的可用性。 为了实现高可用性并自动克服 Parallel Sysplex 中的系统或子系统故障，必须避免将应用程序与单个固定网络地址绑定。 有多种方法可以这样做:
传统上， IP 地址与物理链路相关联，虽然网络中中间链路的故障可以重新路由，但端点是故障点。 引入 VIPA 是为了提供到 TCP/IP for z/OS 系统堆栈的容错网络连接。 这将启用未与硬件组件关联且始终可用的虚拟接口的定义。 对于路由网络， VIPA 似乎是间接连接到 z/OS的主机地址。 名称服务器配置为返回 TCP/IP 堆栈的 VIPA ，而不是物理接口的 VIPA。 如果物理接口发生故障，那么将发出动态路由更新以更新 IP 路由表，从而使用备用路径; 不会中断 IP 连接，而是通过剩余的物理接口以非中断方式恢复 IP 连接。
- 静态 VIPA
- 动态 VIPA (DVIPA)
静态 VIPA 是与特定 TCP/IP 堆栈关联的 IP 地址。 使用 ARP 接管或动态路由协议 (例如， OSPF) ，静态 VIP 可以使大型机应用程序通信不受网络接口故障的影响而继续进行。 当单个网络接口在主机上运行时，与主机上的应用程序的通信会持久存在。 静态 VIPA 不需要综合系统 (XCF 通信) ，因为它不需要 TCP/IP 堆栈之间的协调。
可以在多个堆栈上定义动态 VIPA (DVIPA) ，并自动从综合系统中的一个 TCP/IP 堆栈移至另一个 TCP/IP 堆栈。 一个堆栈定义为主堆栈或拥有堆栈，其他堆栈定义为备份堆栈。 只有主堆栈对 IP 网络是已知的。
综合系统中的 TCP/IP 堆栈会交换有关 DVIPA 及其存在和当前位置的信息，并且堆栈会持续了解伙伴堆栈是否仍在运行。 如果拥有的堆栈离开了 XCF 组 (例如，由于某种故障) ，那么其中一个备份堆栈将自动取代它并承担 DVIPA 的所有权。 网络只会在路由表或响应 ARP 请求的适配器中看到更改。 与这些 DVIPA 关联的应用程序在备份系统上处于活动状态，为服务提供热备用和高可用性。 DVIPA 地址标识应用程序，独立于服务器应用程序在综合系统中执行的映像，并允许应用程序在综合系统中的映像之间移动时保留其标识。
综合系统分发器在综合系统中提供连接工作负载管理。 它在实施多个并发应用程序实例的系统之间平衡工作负载和登录，每个实例共享对数据的访问权。 综合系统分发器支持将 IP 工作负载分发到综合系统中的多个服务器实例，而无需更改客户机或联网硬件，并且不会延迟连接设置。 通过综合系统分发器，您可以将动态 VIPA 作为单个网络可视 IP 地址来实现，该 IP 地址用于属于同一综合系统集群的一组主机。 IP 网络上的客户机将综合系统集群视为一个 IP 地址，而不考虑集群中的主机数。
在 z/OS 环境中使用内部工作负载管理，当接收到针对给定分布式 DVIPA 地址的 TCP 连接请求时，将由配置为路由堆栈的 TCP/IP 堆栈中运行的综合系统分发器来决定应用程序的哪个实例为该特定请求提供服务。 综合系统分发器具有可用的实时容量信息 (来自综合系统工作负载管理器) ，并且可以使用服务策略代理程序中的 QoS 信息。 因此，内部工作负载管理不需要特殊的外部硬件。 但是，所有到分布式 DVIPA 的入站消息必须先传输路由堆栈，然后再转发到相应的应用程序实例。
端口共享是在 z/OS LPAR 中为 IP 应用程序分配工作负载的方法。 TCP/IP 允许多个侦听器在端口和接口的同一组合上进行侦听。 发往此应用程序的工作负载可以分布在侦听同一端口的服务器组中。 端口共享不依赖于活动的综合系统分发器实现; 它在没有综合系统分发器的情况下工作。 但是，除了综合系统分发器操作外，您还可以使用端口共享。
- SHAREPORT
- SHAREPORTWLM
在 PORT 语句中指定 SHAREDPORT 时，此端口和接口的入局客户机连接由 TCP/IP 堆栈通过使用基于共享此端口的侦听器的服务器接受效率分数 (SEF) 的加权循环法在侦听器之间分发。 SEF 是服务器应用程序在接受新连接请求和管理其积压队列方面的效率的度量 (按大约 1 分钟的时间间隔计算)。
可以使用 SHAREPORTWLM 来代替 SHAREPORT。 与 SHAREPORT 类似， SHAREPORTWLM 会导致入局连接分布在一组 TCP 侦听器之间。 但是，与 SHAREPORT 不同，侦听器选择基于特定于 WLM 服务器的建议，这些建议由每个侦听器的 SEF 值修改。 这些建议以大约 1 分钟的时间间隔从 WLM 获取，它们反映了侦听器处理其他工作的能力。
z/OS Communications Server 通用资源提供应用程序的单个系统映像，无论该应用程序在综合系统中的运行位置如何。 用户通过使用应用程序的通用资源名称来访问应用程序， z/OS Communications Server 根据性能和工作负载条件来确定实际应用程序实例。 这允许在不影响用户的情况下添加，除去和移动应用程序实例。
有关在 CICS中使用 z/OS Communications Server 通用资源的更多信息，请参阅 配置 z/OS Communications Server 通用资源。