Access Manager Policy Server 群集

核心提示： 与主和备用 Policy Server 相比，负载均衡的 Policy Server 应是一组独立的服务器，Access Manager Policy Server 群集(6)，这把负载均衡的 Policy Server 从主 Policy Server 中分离出来，主 Policy Se

与主和备用 Policy Server 相比，负载均衡的 Policy Server 应是一组独立的服务器。这把负载均衡的 Policy Server 从主 Policy Server 中分离出来。主 Policy Server 是用于下载授权数据库的唯一 Policy Server，这很重要，因为它是唯一拥有最新授权数据库副本的服务器。在这种配置中，Policy Server 通常只是到用户注册表的网关，它提供了一组高级别的功能以对 Access Manager 用户注册表进行操作。在这种情况下，授权数据库通常是空的且没有被使用，这意味着不支持委托管理。

图 4. 对用户操作进行负载均衡

每个管理应用程序每次只能与一个 Policy Server 建立安全性上下文。对于有多个都执行用户和组操作的管理应用程序而言，该群集配置很理想。TCP/IP 路由器必须确保维持每个管理应用程序和 Policy Server 之间的连接。如果 TCP/IP 路由器决定在管理客户机上切换 Policy Server，那么只能在某个 Policy Server 发生故障时才能这样做。

由于管理客户机的安全性上下文是由管理应用程序维护的，因此当 TCP/IP 路由器将管理功能重定向到另一个 Policy Server 时，管理应用程序必须创建与新的 Policy Server 之间的新的安全性上下文。Java 管理 API 将自动恢复安全性上下文，而 C 管理 API 不会这样做。

创建管理 API 安全性上下文有很大的开销，因此只有在必要的时候才执行该任务。

该选项最好用于高性能的情形，因为有多个专用的服务器都运行 Plicy Server，它们只处理用户和组的管理请求。其中，每个 Policy Server 都可以完全并行地处理多个管理请求。但是，因为这些 Policy Server 不包含授权数据库的副本，因此它们不能就哪些管理可以确定地执行管理请求做任何授权决定，这些请求将留给管理应用程序，从而使得在修改了缺省的管理访问控制规则时（如委托管理）不可使用该选项。