test

Sun Identity Manager 概述

第 3 章 群集和高可用性

本章提供有关如何实施高可用性/容错 (HA/FT) Identity Manager 环境的指南。

注 –

有关确保针对每种技术实现高可用部署的最佳做法，请查阅 Web 服务器、应用服务器和数据库提供商的文档。本指南不能替代供应商特定的 Web 服务器建议。

评估可用性需求

本节介绍如何评估特定部署所需的可用性程度。

评估停机时间成本

由于普通用户在处理他们已经能够访问的系统和应用程序时不需要 Identity Manager，因此 Identity Manager 停机时间不像您想象的那样可怕。如果 Identity Manager 不可用，最终用户仍能够通过为他们置备的帐户来访问资源。

Identity Manager 停机时间的主要成本是工作效率降低。如果 Identity Manager 关闭，最终用户将无法使用 Identity Manager 访问已对他们锁定或者未向他们置备的系统。

要计算停机时间的成本，需要的第一个数值就是由于最终用户无法访问企业内的计算资源而导致工作效率下降所带来的平均成本。在我们的评估中，此数值称为每个工时的工作效率。

需要确定的另一个主要数值就是用户群中需要在任何给定时间使用 Identity Manager 的用户所占的百分比。这些用户通常包括需要为其置备系统的新雇员，以及忘了密码的最终用户（如果密码管理是部署的一部分）。

请考虑下面的虚拟场景：

员工总数 

20,000 

 

一天内重置密码的次数 

130 

 

一天内新雇员的数量 

30 

 

一个工作日内的小时数 

8 

 

对于这个特定场景，可以按如下公式计算：

然后可以使用这些数值估计 Identity Manager 中断所带来的成本：

每个工时的工作效率 

$100 

   

工作效率下降比例 

0.5 

 

（由于无法访问系统而导致工作效率下降 50%） 

受影响的人数 

20 

   

小计 

$1,000 

   
       

中断时间间隔 

2 个小时 

   

总直接损失 

$2,000 

   

此示例说明即使由 Identity Manager 管理的用户很多，在任何给定时间内需要通过 Identity Manager 访问系统的用户通常很少。

需要考虑的另一点就是，将系统（如 Identity Manager）重新联机所需的时间通常少于手工执行正由 Identity Manager 自动完成的置备过程所需的时间。因此，尽管 Identity Manager 停机时间会带来成本，但该成本通常低于使用手动过程来让用户访问资源所带来的成本。

了解停机时间的原因

在规划 Identity Manager 高可用部署时，有必要考虑停机时间的原因。

这些原因包括：

计算投资回报率

Identity Manager 自动执行相关过程并避免工作效率降低。在高可用性 Identity Manager 体系结构方面的投资回报率可通过尽可能缩短停机时间和避免工作效率降低来实现。

您可以使用停机时间所带来的成本来确定 Identity Manager 最终需要的可用性程度。通常，为使 Identity Manager 具有高可用性而进行适度投资是值得的。

在计算投资成本时，请记住，购买 HA/FT 硬件和软件只是实施可用解决方案的一部分。让知识渊博的人员启动并运行它也会带来成本。

了解 Identity Manager 高可用性功能集

Identity Manager 在设计上能够利用可用的 HA 基础结构。例如，Identity Manager 不需要通过应用服务器群集来实现高可用性，但是它可以利用现有的群集。

下图显示了在非冗余体系结构中部署的主要 Identity Manager 组件。随后的几节将描述如何使 Identity Manager 系统信息库、应用服务器和网关具有高可用性。

图 3–1 标准的 Identity Manager 系统体系结构

该逻辑图表代表标准的 Identity Manager 系统体系结构。

注 –

有关为了尽可能减少因延迟和网络拥塞所造成的性能问题，而应当使哪些组件相邻放置的信息，请参见了解系统分隔和物理接近性准则。

使系统信息库具有高可用性

Identity Manager 将其所有的置备和状态信息都存储在 Identity Manager 系统信息库中。

用来存储 Identity Manager 系统信息库的数据库实例的可用性是实现高可用性 Identity Manager 部署的最关键部分。系统信息库代表整个 Identity Manager 安装，其中的数据必须与其他重要数据库应用程序一起进行保护。至少，必须定期执行备份。

注 –

不要将 Identity Manager 系统信息库放在虚拟平台（如 VMware 虚拟机）上，因为性能（每秒的事务数）将会受到显著影响。

系统信息库只能有一个映像。对于 Identity Manager 不可能有两个不同的数据库，而且不要尝试在夜间同步它们。Sun 建议使用数据库的群集或镜像功能来提供容错。

使应用服务器具有高可用性

Identity Manager 可以在一个应用服务器群集内运行，而且可以利用群集所提供的附加可用性和负载平衡。但是，Identity Manager 不使用任何需要群集的 J2EE 功能。

Identity Manager 使用可通过 Servlet API 访问的 HTTP Session 对象。此会话对象在用户登录和执行操作时跟踪用户的访问情况。在群集内，可以选择在给定会话期间让多个节点处理用户请求。但通常不建议这样做，因为多数安装都配置为将用户针对给定会话的整个请求发送到同一台服务器。

可以为运行 Identity Manager 的应用服务器额外增加可用性和容量，即使您未设置群集也是如此。可通过以下方法来增加可用性和容量：安装多台带有 Identity Manager 的应用服务器，将这些服务器连接到同一个系统信息库，并在所有的应用服务器前面放置一个具有会话关联的负载平衡器。

注 –

有关会话关联的详细信息，请参见与会话关联和会话持久性有关的常见问题解答。

Identity Manager 在后台运行某些任务（例如，预定的协调任务）。这些任务存储在数据库中，而且可以由任何 Identity Manager 服务器选取运行。Identity Manager 使用数据库来确保这些任务始终完成运行，即使数据库必须故障切换到另一个节点也是如此。

在应用服务器节点上配置 Active Sync 群集

Waveset.properties 文件中的 sources.hosts 设置控制多实例环境中的哪些主机可用于执行 Active Sync 请求。此设置提供有关可在其上运行源适配器的主机的列表。将该设置配置为 localhost 或 null 将允许源适配器在 Web 群中的任何主机上执行。（这是默认行为。）通过列出一个或多个主机，可以只允许该列表中的主机执行。如果存在来自另一个系统且进入某个主机的入站更新，请使用 sources.hosts 设置记录主机名。

另外，可以定义一个名为 sources. resourceName.hosts 的属性来控制将在何处运行资源的 Active Sync 任务。将 resourceName 替换为要指定的资源对象的名称。

使网关具有高可用性

Identity Manager 要求用轻量网关来管理不能直接从服务器访问的资源。这些资源包括需要执行特定于平台的客户端 API 调用的系统。例如，如果 Identity Manager 在基于 UNIX 的应用服务器上运行，则不可能对所管理的 NT 或 Active Directory 域进行 NTLM 或 ADSI 调用。由于 Identity Manager 需要用网关来管理这些资源，因此一定要确保使 Identity Manager Gateway 具有高可用性。

为了防止 Gateway 成为单个故障点，Sun 建议在多台计算机上运行 Gateway 实例。网络路由设备应当配置为在主 Gateway 实例终止时提供故障转移。应当针对粘性会话设置故障转移设备，并让故障转移设备使用一个简单的循环方案。请不要将 Gateway 放在负载平衡设备后面！因为该配置不受支持，而且将导致某些 Identity Manager 功能失败。

由 网关 管理的所有 Windows 域必须属于同一个林。不支持跨林边界管理域。如果您有多个林，请在每个林中至少安装一个 网关。

Win32 监视工具可以配置为在 Win32 主机上监视 gateway.exe 进程。如果 gateway.exe 失败，该进程会自动重新启动。

了解所建议的 HA 体系结构

下图显示在没有 Web 应用程序基础结构时，Sun 建议使用的 Identity Manager 体系结构。

图 3–2 Identity Manager 高可用性体系结构

该逻辑图表代表所建议的 Identity Manager 高可用性体系结构。

在实际部署中，应当尽可能充分利用现有的冗余应用服务器基础结构。此体系结构的价值在于它仅使用负载平衡器即可在应用服务器上实现冗余。具有会话关联的负载平衡器会检测失败的应用服务器实例并将其故障切换到活动实例。在 Web 环境中，负载平衡器还可以在服务器群集内分布用户请求，从而提供水平伸缩。

尽管这是一种简单的体系结构，但其运行时间特征能够与更复杂的部署媲美。由于该体系结构比较简单，因此需要维护和监视的软件更少，有可能失败的软件也会更少。由于人为错误是导致停机时间的首要原因，因此与更为复杂的解决方案相比，相对简单的解决方案可以实现更佳的运行时间特征。没有通用的正确答案。要点在于，了解导致停机时间的所有原因，并为您的投资选择将实现最佳可用性的体系结构。

注 –

不可能像对 Web 应用程序（如 Identity Manager）那样，描述所有不同的 HA 体系结构。

由于 Identity Manager 可以部署在各种可能的组合中，因此最经济的方法就是在部署 Identity Manager 时，确定现有的基础结构并尽可能充分利用它。

了解所建议的 Service Provider HA 体系结构

如果要利用 Identity Manager Service Provider 功能，Sun 建议您在用户层和应用层之间添加一个 Web 层。该 Web 层由一台或多台驻留在隔离区 (DMZ) 中的 Web 服务器组成，并由防火墙将其与应用层隔开。

如果要利用 Service Provider 功能，则需要使用 LDAP 系统信息库。如果 Identity Manager 仅支持外联网客户端，建议使用标准的 Identity Manager 系统信息库，但这不是必需的。否则，如果 Identity Manager 既支持内联网又支持外联网用户，则需要一个 LDAP 系统信息库和一个标准的 Identity Manager 系统信息库。

图 3–3 Identity Manager Service Provider 高可用性体系结构

该逻辑图表代表为 Service Provider 实施建议的 Identity Manager 高可用性体系结构。

了解故障方案

本节列出了八个故障方案，并对两个分别具有会话持久性和不具有会话持久性的部署进行了比较。

方案 1：无工作流的方案

方案描述

最终用户或管理员正在编辑不属于工作流的表单。最终用户已在其上建立会话的实例已关闭。

不具有会话持久性

用户体验：不透明的故障转移。在提交表单时，系统将用户返回到登录页面。

恢复步骤：用户重新输入其用户名和密码。Identity Manager 随后处理该表单并在用户登录之后立即将结果显示在下一页。

具有会话持久性

用户体验：用户无需注销和重新登录，即可提交表单并得到返回的结果。

恢复步骤：不需要用户执行任何操作。

该方案的其他示例

方案 2：工作流正在进行的方案

方案描述

最终用户或管理员提交了触发工作流的表单。正针对其执行工作流的实例通常就是存在用户会话的实例，但是在某些预定任务上，它们可能不是同一个。实例在工作流正在进行时关闭。

不具有会话持久性

用户体验：不透明的故障转移。在提交表单时，系统将用户返回到登录页面。正在执行的工作流任务实例应当位于系统信息库中，但是，由于执行节点已关闭，因此工作流状态将为“已终止”。

恢复步骤：必须再次提交工作流，方法是返回到同一表单，重新输入在节点失败之前用来触发工作流的信息。

在某些情况（但并非所有情况）下，提交同样的请求数据可能会起作用。如果在工作流执行期间将其置备给多个资源，而其中的一些资源在发生故障之前已经置备，则在用户重新提交工作流时将必须考虑“已经置备的”资源。请注意，已终止的工作流仍停留在系统信息库中，直到 resultLimit 在 TaskInstance 对象上过期为止。

具有会话持久性

用户体验：不透明的故障转移。不会将用户注销，因为用户的会话将得以保持并在新实例中重新建立。但是，在提交表单时可能会因工作流将被终止而导致错误。此故障转移是不透明的，因为需要执行恢复操作。

恢复步骤：与不具有会话持久性的模式相同。用户必须使用相同或经过修改的参数重新提交在先前的工作流中触发的请求。

该方案的其他示例

方案 3：工作流暂停或休眠方案

方案描述

此方案包括如下情况：工作流已启动，但是正在等待批准者手动执行操作。

不具有会话持久性

用户体验：故障转移相对于批准者是透明的，但前提是批准者尚未登录。在节点出现故障之后，当批准者登录时，批准者仍能够在其收件箱中看到批准请求，即使该请求是从已经关闭的节点触发也是如此。

恢复步骤：不需要用户执行任何操作。

具有会话持久性

用户体验：与不具有会话持久性的模式相同。

恢复步骤：与不具有会话持久性的模式相同。

该方案的其他示例

方案 4：工作项目编辑方案

方案描述

此方案包括如下情况：用户正在编辑一个工作项目，在提交该工作项目之前，用户在其中具有会话的节点关闭。

不具有会话持久性

用户体验：不透明的故障转移。在提交了工作项目编辑表单之后，系统将用户注销并返回到登录页面。

恢复步骤：在重新提交登录凭据时，用户的工作项目被标记为已完成，而且工作流能够从那时继续执行。该工作流应当由新模式拾取并从用户的手动操作被标记为已完成时开始执行。

具有会话持久性

用户体验：在提交了工作项目编辑表单之后，用户看到其提交操作的结果，例如，自定义工作流中的下一个表单（如果有的话）或者指示成功的消息。

恢复步骤：不需要用户执行任何操作。

该方案的其他示例

方案 5：预定任务正在进行的方案

方案描述

这些方案包括如下情况：在正在进行协调或者正在执行报告时，节点出现故障。

不具有会话持久性

用户体验：预定的任务正在被终止。

恢复步骤：必须重新启动正在进行的预定任务。该任务必须从头开始启动。（该任务将不会从出现故障的时间点重新启动。）这与创建和启动新任务相同。

具有会话持久性

用户体验：与不具有会话持久性的模式相同。

恢复步骤：与不具有会话持久性的模式相同。

该方案的其他示例

方案 6：预定任务暂停方案

方案描述

这些方案包括如下情况：用户的自定义工作流已经预定了一个日后在特定节点上执行的任务。在到达预定日期之前，预定在其上运行该任务的节点出现故障。

不具有会话持久性

用户体验：故障转移对于确保此任务在其预定时间执行而必须采取的恢复操作是透明的。

恢复步骤：在到达预定的执行时间时，预定任务由任何活动节点拾取。

具有会话持久性

用户体验：与不具有会话持久性的模式相同。

恢复步骤：与不具有会话持久性的模式相同。

该方案的其他示例

方案 7：Web 服务工作流请求尚未由 Identity Manager 接收的方案

方案描述

这些方案包括如下情况：Identity Manager GUI 不用于启动置备功能。相反，该用户界面由使用 SPML 或其他自定义 Web 服务接口在内部调用 Identity Manager 的应用程序提供。在这里，与通过用户界面进入的用户有关的用户会话借助于调用应用程序来管理。对于 Identity Manager，请求均作为“soapadmin”主体来启动。

在类似的使用案例中，此故障方案包括如下情况：在经由 Identity Manager 端点的请求尚未接收时，目标节点出现故障。

不具有会话持久性

用户体验：透明的故障转移。对于每个 SOAP 请求来说，SOAP 管理员的凭据通过有线通信或者通过 Waveset.properties 设置在 Identity Manager 中传入。只要将要接收此 SOAP 请求的节点在关闭之前尚未收到请求，则无论具有或不具有会话持久性，故障转移都是透明的。

恢复步骤：不需要执行任何操作。SOAP 请求发送到执行它的实时节点。

具有会话持久性

用户体验：与不具有会话持久性的模式相同。

恢复步骤：与不具有会话持久性的模式相同。

方案 8：Web 服务工作流请求正在由 Identity Manager 进行的方案

方案描述

此方案与方案 7 类似。二者唯一的区别在于，在方案 8 中，当节点出现故障时，工作流正在进行；在方案 7 中，当节点出现故障时，节点尚未收到 SOAP 请求。

不具有会话持久性

用户体验：此方案与方案 2（工作流正在进行）相似。工作流被标记为已终止，用户看到一个因 SOAP 请求产生的错误。

恢复步骤：用户必须使用相似的或经过修改的参数（基于故障出现在工作流中的位置），通过第三方应用程序中的用户界面重新提交表单。

具有会话持久性

用户体验：与不具有会话持久性的模式相同。

恢复步骤：与不具有会话持久性的模式相同。

与会话关联和会话持久性有关的常见问题解答

在对应用服务器水平伸缩时，是否应当启用会话关联？

是。

在对应用服务器水平伸缩时，是否应当使用会话持久性？

除非您的业务要求特别强调在会话持久性会产生影响的有限情况下实施透明故障转移，否则 Sun 不建议使用会话持久性。会话持久性具有其自己的性能开销，除非您的业务要求确实需要透明的故障转移，否则请关闭会话持久性。

在研究了解故障方案中记录的八个故障方案后就会发现，在其中的六个方案中，无论是否启用了业务持久性，最终用户体验或所需的恢复操作没有任何区别。只有在方案 1 和方案 4 中，具有会话持久性的方案才会与没有会话持久性的方案有区别。

在这两个方案中，会话持久性可以提供故障转移透明性，但会话持久性会降低性能。根据会话对象的大小、用于会话持久性的系统信息库以及对于特定应用服务器的会话管理代码的优化，性能开销可能会从 10% 到 20% 或更高。

在水平伸缩时，一个群集内是否应当有多个应用服务器实例？

除非您需要会话持久性，否则并不是绝对需要多个应用服务器实例。即使所有的应用服务器节点都不在一个群集内，也可以实现不具有会话持久性的故障转移。