面向大型站点的 Oracle 企业管理器网格控制体系结构

        从oracle官方转载一篇文章关于部署上千节点的grid，porus说的很明白了，简单讲就是oms的单一管理进程无法承受上千节点的压力，必须分多节点，就是多个OMS server然后做硬件负载均衡，可以按端口进行，4889端口做management 4777端口做agent的上传，用虚拟服务器做自定义管理装有agent的database，比方核心的几个库，经常出现问题的几个库。repository用rac和dg保证高可用，repository是共享的，这个必须处于可用的状态。总得来说，数据库增加就是加机器进行横向扩展，横向扩展的能力十分可观。

面向大型站点的 Oracle 企业管理器网格控制体系结构

作者：Porus Homi Havewala

 

需要保证企业管理器网格控制的高可扩展性？这一体系结构正好可满足您的需要。

2009 年 2 月发表

就 Oracle 企业管理器网格控制而言，什么样的站点才算是大型站点？大型站点就是意味着要监视和管理一个庞大的目标集合。

我的团队直接参与了世界上第一个网格控制生产站点的构建，该站点属于澳大利亚的一家大型电信公司（获得了来自 Oracle 的很多帮助）。该项目涉及设置一个中心网格控制站点，以管理公司组织中不同 DBA 团队下各不相同的服务器和数据库。团队、服务器和数据库分散在澳洲大陆的各地。

之所以要进行管理，主要原因如下：它需要一个可供查看所有 Oracle 版本和许可的视图以及一种减少使用昂贵 SAN 存储的方式。不仅仅每年要为这个空间花费高额的成本，而且在 Unix 级别它会处于未分配状态或在数据库级别处于过度分配的状态，但在表空间中会有很多可用的未使用空间。为了处理这个特殊方面，Oracle 用专门开发的网格控制存储报告提供协助。这些报告非常有用，它们最终会整合至第 2 版的网格控制中。

推进这个项目的其他目标是让整个企业有一个数据库管理工具并使用网格控制的出色功能，如数据库性能分析、RMAN 备份设置和计划、Oracle Data Guard 设置、通过所谓的“金牌复制”监视和克隆 Oracle 数据库以及 Oracle 主目录，从而节省很多内部数据库咨询时间。在网格控制之前，所有这些任务都是使用传统手动方法执行的，这不仅会占用很多时间，而且还容易出现人为错误。

若要针对差不多两千台以上的数据库服务器执行所有这些活动、连续监视这些服务器以及让多个 DBA 团队出于此目的使用中央站点，我们需要一个设计特别出色的站点，以便在需要引入越来越多的目标（达到 2000 台或更多服务器）时能够按等级 I、II 和 III 进行扩展。

在本文中，我将概述用于在网格控制中实现这个高可扩展性的体系结构。对于打算使用网格控制，但需要指导方可正确设计其解决方案的客户而言，这类信息是非常有用的。

错误的体系结构

假设一个 DBA 团队或其管理层决定实施网格控制。一般的做法是使用测试或开发服务器安装该产品，最好将其安装在 Unix、Linux 或 Windows 上。这意味着所有网格控制组件（编写本文时的当前版本是第 4 版）都必须放在一个服务器上。 这包括信息数据库、Oracle 管理服务 (OMS) 和 EM 代理。

然后，使用推或拉方法将 EM 代理安装在几个其他开发和测试数据库服务器上。DBA 团队测试网格控制的功能之后，可能会暂时性地决定首次在生产服务器上安装代理。

假设管理人员最终决定将所有网格控制的事情移到生产环境中进行，但现在犯了一个错误，即假定适合几个开发服务器的所有内容也适合生产环境。这允许 DBA 团队将网格控制再次安装到一个生产服务器上。该团队将所有组件再次安装到一个服务器上，可能会与生产或测试数据库共享网格控制安装。之后，将 EM 代理安装在所有指回网格控制服务器的生产和测试数据库服务器上。

这样做只能一时凑效。随着网格控制负载的逐渐增加，越来越多的数据库需要由更多的 DBA 管理，执行越来越多的监视，随着网格控制越来越多地用于 RMAN 备份，Data Guard 设置和监视、数据库和主目录的克隆等等，网格控制系统逐渐停顿下来。

为什么会发生这种情况呢？要获得答案，我们需要了解网格控制的内部构造。网格控制的主要工作组件是 OMS，它就如同引擎一样。OMS 是部署在 Oracle 应用服务器 10g 上的 J2EE 应用程序；成员组件有 Oracle HTTP Server、Oracle Application Server Containers for Java (OC4J) 以及 OracleAS Web Cache。因此，网格控制是 Oracle 应用服务器自身的简化版本。

在 Unix 服务器级别，我们看到的 Unix 进程实际上是 OC4J_EM 进程。当执行 opmnctl 命令时也会看到这种情况：

./opmnctl status    
Processes in Instance: EnterpriseManager0.GridMgt001.in.mycompany.com
-------------------+--------------------+-------+---------
ias-component      | process-type       |   pid | status
-------------------+--------------------+-------+---------
WebCache           | WebCacheAdmin      |  2071 | Alive
WebCache           | WebCache           |  2099 | Alive
                                OC4J | OC4J_EM | 27705 | Alive
OC4J               | home               |   N/A | Down
dcm-daemon         | dcm-daemon         |   N/A | Down
LogLoader          | logloaderd         |   N/A | Down
HTTP_Server        | HTTP_Server        |  2072 | Alive
                            

此时说句题外话：由于 OMS 运行在 Oracle 应用服务器上，因此您可以像使用应用服务器一样对其进行控制：使用 EM 应用服务器控制或在命令行使用 opmnctl (Oracle Process Management Notification Control) 或 dcmctl (Distributed Configuration Management Control)。这是除了 Enterprise Manager Control (emctl) 实用程序之外的工具。

因此，OC4J_EM 只是具有其自己的 PID 的一个 Unix 进程。该进程使用的内存也有限制，可通过文件 $ORACLE_HOME/opmn/conf/opmn.xml 设置。您可以增加该进程使用的内存，但它仍然只是一个进程。我们可以想像使用一个进程来管理众多数据库和服务器 — 执行各种任务（如 Data Guard 设置、克隆等等）— 并了解为什么这样设置不能进行扩展的原因。

很明显，如果数据库自身要在一个进程上运行，而数据库写入器、日志写入器以及归档器以及很多其他进程功能也都由一个进程来执行，则该数据库将变得没有效率并且不可扩展。这是主要原因，如果所有网络控制组件都放在一个服务器上，则只能获得有限的可扩展性：您将局限于一个 OC4J_EM 进程，而该进程又有其内存和处理器速度的局限性。如果 OC4J_EM 进程在较大负载下达到了它的内存限制，以及该进程速度减慢或没有响应，则其他 DBA 将无法登录到网格控制控制台进行他们自己的数据库管理工作。

在生产中，不建议将网格控制组件放在一个服务器上，也不建议与同一服务器上的生产或测试数据库共享。网格控制需要其自己的服务器，并且在正确设计的解决方案中需要拥有自己的一组服务器。建议花点时间来规划打算用于生产的网格控制站点。应当说服高级管理层认识到该初识研究的重要性，以批准对此解决方案提供预算支持，并作为专业项目进行开展，因为网络控制是一个企业解决方案，不是部署在 DBA 工作站上的次要工具。

网格控制内部构造

网格控制与以前版本的企业管理器有很大不同。过去，由于企业管理器不是 N 层，因此其可扩展性不像现在这么好。最旧的版本是服务器管理器，它是 PC 可执行实用程序。在网格控制之前，有 OEM 9i，它就像盘踞在 PC 内存上的大型 Java 兽，因此出现了很多问题。

创建网格控制时，内部体系结构进行了大量改变，以使其适合 N 层模型。Oracle 的构想是广义的 N 层，符合现代的 IT 想法并朝此方向发展。网格控制变成了之前提到的三个组件，并且由于主要引擎 OMS 现在作为 OC4J 应用程序运行在应用服务器上，因此它即刻具有了可扩展性。

为什么可以这样呢？首先，网格控制未依赖于一个 PC 或一个服务器；多个 OC4J EM 应用程序可以放在不同服务器上的应用服务器上，并且它们可以都指向同一 EM 信息库。

此处阐释了为什么网格控制具有如此巨大的可扩展性。边界被打破，横向扩展面向 EM 领域开放。向 EM 站点中添加的 OMS 服务器越多，可以管理的目标就越多。

正确的体系结构

实际的大型站点实施示例将更加清楚地说明这个概念。在实施的基础上，可以利用行业标准的开放式体系结构，如具有以下配置的 Linux 服务器：

规格类型	规格详细信息
硬件	任何业界供应商
操作系统	Linux（已通过网格控制认证的任何版本）
CPU	4（2.2 GHZ 或更高）
内存要求	8GB
磁盘空间	10GB 可用空间

不需要部署功能强大且昂贵的服务器（庞大的体系结构通常具有 24 个或更多 CPU 以及 32 GB 或更多内存）。目前使用的是具有 8 GB 内存与 4 个 CPU 的更小型计算机，因为目的是进行横向而非纵向扩展。

规格表中提到的“可用空间”是针对 Oracle 软件，如 Oracle 数据库主目录、Oracle 管理服务主目录和代理主目录。不包括将放置到 SAN 或 NAS (Netapps filer) 上的数据库。EM 信息库的数据库空间要求大约为 60 到 70 GB，同时为快速恢复区（将存储所有归档日志和 RMAN 备份）留出同等数量的空间。Oracle 建议将数据库备份到磁盘（快速恢复区），以便进行基于磁盘的快速恢复。

即使要监视和管理大量目标，数据库大小也很少会上升到提供即需即用功能的 60 到 70 GB 以上。网格控制的一个新功能就是 EM 信息数据库 (10g) 管理自身（就空间而言），这意味着它按预定义的间隔执行量度数据的汇总。因此，从目标连续不断地收集量度数据并不会大幅增加数据库的大小。另一方面，也可以手动创建用于监视的其他量度，但这样可能会导致增加数据库大小，使其大于此示例数字。

在安装阶段，首先是使用网格控制安装光盘将完整的网格控制软件安装在其中一个服务器上。该操作可通过使用新数据库安装类型选择企业管理器 10g 网格控制来完成。信息数据库在该机器上创建后，该服务器就变成了信息服务器。作为完整安装，还必须将 OMS 和 EM 代理安装在同一信息服务器上。（此时，您可以忽略 OMS：本文稍后部分将对此进行详细介绍。）

接下来，将另一个 OMS 安装在其他每个服务器上，该操作可使用同一网格控制安装光盘完成，但选择“其他管理服务”安装类型。在安装其他服务期间，将要求您指向现有信息库，因此指向第一个服务器上的信息数据库。如果在 Sysman 模式下成功安装信息库，则在这个阶段，该信息数据库必须启动和运行。

在“其他管理服务”安装类型的过程中，将只安装管理服务 (OMS) 和 EM 代理。在三个或更多其他服务器上完成该操作，现在这些服务器就变成了管理服务器池。

信息数据库服务器可以与使用 Oracle Data Guard 的备用数据库服务器彼此形成互补，如果需要的话，也可以用多个节点上的 Oracle RAC 集群来横向扩展信息数据库的性能。但值得注意的是，在网格控制中性能要求大多不在数据库方，而更多地在于管理服务器方。由于 OC4J_EM 是批量执行网格控制工作，因此可在管理服务器上实现最高的可扩展性。这就是为什么体系结构应该包括三个或更多管理服务器（这些服务器已经针对大型网格控制设置进行了负载平衡）的原因。

对管理服务器池进行负载平衡成为了该体系结构不可或缺的一部分。可以使用硬件负载平衡器（如来自 F5 Networks 的 Big IP Application Switch Load Balancer）来实现这个目的。（该公司的旗舰产品就是 BIG-IP 网络设备。最初网络设备就是网络负载平衡器，但是现在还可提供更多功能，如访问控制和应用程序安全性。）

负载平衡器设置有其自己的 IP 地址和域名，例如：gridcentral.in.mycompany.com。负载平衡器依次指向三个管理服务器的 IP 地址。当在负载平衡器的 IP 地址或域名上（这也可能是在可以在平衡器级别设置的特殊端口上）收到服务请求时，平衡器将会决定在指定的端口上将传入的服务请求分发给其池中三个同时活动的管理服务器之一。网格控制使用各种端口实现不同的目的，例如，有用于控制台登录的特定端口以及用于将目标量度数据上载到代理的其他端口。必须为所有这些端口设置 Big IP，以便当网格控制控制台登录以及将目标量度数据上载到代理时进行负载平衡。

另一个好处是这会为网格控制系统提供出色的冗余。如果由于任何原因（如较大负载）其中一个管理服务器停止工作，则可能需要使用 opmnctl 重新启动 OC4J_EM 进程。因此可以停用其中一个管理服务器，而其他活动的管理服务器继续进行由 Big-IP 负载平衡器分发的服务请求。负载平衡器将自动忽略无法访问的 IP（通过其自己的监视器来发现这个问题，方法是以预先确定的时间间隔持续检查池成员）。因此，任何现有管理服务器实例出现故障都会导致负载平衡器将所有随后的服务请求指向活动且未发生故障的实例。当 Big IP 监视器检测到节点重新联机时，会自动将该节点或服务添加回池中。

也可以使用软件负载平衡来代替硬件负载平衡。这是一个使用软件（如网络域名）将请求路由给三个管理服务器的简单解决方案。虽然硬件解决方案更加昂贵，但由于它的功能比较强大，因此建议使用。负责负载平衡以及故障切换功能的硬件负载平衡器应该是总体系结构解决方案中一个不可或缺的部分，以使解决方案更加强健和灵活。

如果在 Big IP 负载平衡器级别需要进一步冗余，则可以部署备用负载平衡器。更改所有配置时，备用负载平衡器可作为生产负载平衡器的“影子”，如果生产计算机出现任何错误，备用负载平衡器将无缝地进行接管。这是一个附加的预防措施。如果很多生产数据库团队都使用集中网格控制管理和监视生产系统，则这种类型的高可用性体系结构绝对是非常重要的，其中甚至可以通过冗余方式部署负载平衡器。

要管理 Big IP 负载平衡器，必须将内部 IP 分配给主要负载平衡器和备用负载平衡器，并且必须分配浮动 IP 地址，该地址指向主要负载平衡器或备用负载平衡器，具体取决于哪个平衡器处于活动状态。然后使用下表中列出的 URL 通过浮动 IP 管理负载平衡器。这是 Big IP 管理实用程序或 Web 控制台。使用 Admin 口令或 Support 口令登录该控制台。（如果需要，可以在 Big IP Web 控制台中创建具有只读权限的新用户。）

Big IP 根口令用来使用 SSH 在 Linux 级别登录。平衡器运行 Linux，但具有减少的命令集 shell。这是 Big IP 的命令行接口 (CLI)。命令与正常的 Linux 稍有不同，例如，在 CLI 中命令“bigtop”用来监视负载平衡器。

下表列出了内部 IP 和浮动 IP（每个 IP 地址以 nnn.nnn.nnn.nn 形式显示且绝对唯一）：

主机名	Ip 地址	描述	Big Ip 管理 URL
GridBal001	nnn.nnn.nnn.nn	设备 1 IP 地址	https://<设备 1 IP 地址>/bigipgui/bigconf.cgi
GridBal002	nnn.nnn.nnn.nn	设备 2 IP 地址	https://<设备 2 IP 地址>/bigipgui/bigconf.cgi
GridBal003	nnn.nnn.nnn.nn	浮动 IP 地址	https://<浮动 IP 地址>/bigipgui/bigconf.cgi

两个负载平衡器设备 GridBal002 和 GridBal002 之中任何一个设备都可以处于活动状态（实际处理负载平衡）。通常，两个设备将拥有与其关联的 3 个地址：设备 1 IP、设备 2 IP、浮动 IP。浮动 IP 是一个共享的 IP 地址，它只存在于当时处于活动状态的设备上。因此，如果您希望只管理活动设备，则连接到 https://FloatingIP。但是，如果您希望直接管理设备，则可以通过 https://Unit1IP 或 https://Unit2IP 访问这些设备来进行管理。

网格控制配置中的其他服务器如下表所示：

主机名	Ip 地址	描述
GridMgt001	nnn.nnn.nnn.nn	管理服务器 1 (OMS 1)
GridMgt002	nnn.nnn.nnn.nn	管理服务器 2 (OMS 2)
GridMgt003	nnn.nnn.nnn.nn	管理服务器 3 (OMS 3)
GridMgt100	nnn.nnn.nnn.nn	虚拟管理服务器（虚拟 OMS）
GridDb001	nnn.nnn.nnn.nn	数据库服务器 1 (DBS 1)（主或 RAC 节点）
GridDb002	nnn.nnn.nnn.nn	数据库服务器 2 (DBS 2)（备用或 RAC 节点）

为了进行负载平衡，Big IP 使用虚拟服务器、池、关联节点（成员）以及规则的概念来指导负载平衡。虚拟 OMS 服务器在 Big IP 级别使用其自己的 IP 地址进行设置，这将依次指向具有其自己的 IP 地址的 Oracle 管理服务器池。因此，对于网格控制台登录或从多个目标进行代理上载来说，外部世界必须指向虚拟 OMS 服务器的 IP 地址或域名。Oracle 管理服务器池使用 IP 地址:端口组合进行设置，这意味着您可以设置一个池用进行网格控制台登录，设置另一个池以将代理上载到 OMS。

记住，了解了企业管理器高级配置指南中有关负载平衡的建议之后，后面的设置使用 Big IP 管理控制台执行：

创建两个新池 EMAgentUploads 和 EMConsoles。每个池具有三个 OMS 节点（3 个活动的节点；但您可以添加仍然正在设置的节点并使其在 Big IP 中保持“强制关闭”状态，以便不会监视该节点）。这两个池之间的差别在于端口级别。池 EMAgentUploads 使用端口 4889 进行代理上载，而池 EMConsoles 使用端口 7777 进行控制台访问（7777 是 Oracle Web Cache 的默认端口）。

在池级别，Big IP 还允许您定义随后的服务请求是否持久（粘附）路由到同一池成员。尽管网格控制台登录不需要粘附（我们不关心控制台是否在每次 DBA 连接时使用不同的 OMS），但是代理上载可以获益于此种粘附，这一点是肯定的。对这两个池进相应地修改并为针对代理上载池设置“简单持久性”，但不为控制台登录池设置。

创建两个新的虚拟 OMS 服务器，第一个服务器针对使用 EMAgentUploads 池的代理上载使用端口 4889，第二个服务器针对使用 EMConsoles 池的 Web Cache EM 控制台使用端口 7777。这两个虚拟服务器使用同一保留 IP 地址（但端口不同）。

还可以设置连续不断地检查池成员状态的 Big IP 监视器。按照 企业管理器高级配置指南所述使用“GET /em/upload”发送字符串和“Http XML File receiver”接收规则设置这样一个监视器 EMMon。但是，该监视器为 4889 端口工作，而不是 7777 端口。因此，基于 http 以及“GET /”发送字符串创建一个新监视器“EMConsoleMonitor”，以成功监视 7777 端口。

现在 URL http://GridMgt100:7777/em 成功工作并且将网格控制台登录的负载平衡到池中的所有三个管理服务器。

测试 URL http://GridMgt100:4889/em，它也采用类似方式成功进行了负载平衡，但该 URL 将只用于代理上载。

现在，当切换公司网络别名“gridcentral.in.mycompany.com”以指向虚拟 OMS 服务器 GridMgt100 时，Big IP 负载平衡器开始由生产使用。

需要注意的是，当 Big IP 故障切换到其备用以及再次切换回来之后，在 Big IP 管理控制台看到的成功初始更改才会在 URL 级别生效（URL 不工作）。在活动负载平衡器上所执行的任何配置更改应该传播到备用负载平衡器。通过 Big-IP 配置实用程序完成该操作，方法是转到Redundant Properties 并单击 Synchronize Configuration。这使得备用平衡器配置与活动平衡器的配置相同，包括所有池、虚拟服务器以及规则，因此备用服务器已准备好在故障切换时接管负载平衡。另一个需要注意的是，当更改 admin 口令时，由于 admin 用户已配置为 configsync 用户，因此您必须对口令进行更改使其匹配对等控制器，configsync 才能工作。

也可以手动进行故障切换。在将任何故障切换到备用 Big IP 之前，建议镜像所有连接。但是，注意该设置会影响 CPU 性能。这是在 Virtual server ..Mirror 连接的属性下选择的。

注意，在初始安装期间，管理服务器已经安装到网格控制信息服务器上。由于在该体系结构中，管理服务器功能已经从信息库功能中分离出来，因此不建议使用已经安装在信息服务器上的其他管理服务器。只需将该服务器专门用于信息库。为此，只将三个独立的管理服务器放置在 Big IP 负载平衡器池中。

其他管理服务器是在信息服务器上运行并占据内存和处理功能的 Java 进程，因此最好在该服务器上使用 opmnctl 并关闭管理服务器 (OC4J_EM)。或者，如果正在编写只要重新启动就在服务器上启动 OMS、代理和数据库的 Unix 重新启动脚本，则只需在信息服务器中去掉启动 OMS。只需启动侦听器、数据库，然后是代理。在其他管理服务器上，启动 OMS 和代理。

该体系结构图如下所示：

结论

这种使用硬件负载平衡器和多个管理服务器的横向扩展体系结构功能非常强大，并完美地体现了 Oracle 的网格构想。借助这样一个体系结构，您可以轻松管理数百个、甚至上千个目标。部署该项目的大型公司借助只包含三个管理服务器的池即可轻松扩展至管理 600 到 700 个目标，并且将来计划管理 2,000 或更多个目标，这是一个很大的成就。

Porus Homi Havewala（Oracle ACE 总监）是 S & I Systems（新加坡）的首席顾问。他在 Oracle 技术方面经验丰富，自 1994 年以来他担任过生产 DBA、高级顾问、电子商务技术 DBA 和系统管理员，以及开发 DBA 和数据库设计人员/建模人员（使用 Oracle Designer 课程）。

http://www.oracle.com/technetwork/cn/articles/havewala-gridcontrol-085226-zhs.html