核心结论

Oracle 海波龙 Foundation Services 是 Oracle Enterprise Performance Management（EPM）体系的公共基础层。它提供的共享服务包括用户与角色管理、安全认证、元数据存储、系统注册、生命周期迁移和统一配置入口。所有 Hyperion 模块，例如 Planning、Essbase、HFM、PCM 等，都通过 Foundation Services 获得一致的基础能力。

在部署架构上，Foundation Services 需要与应用服务器、数据库、身份目录和共享存储协同工作。推荐采用“独立数据库 + 应用服务集群 + 共享文件目录 + 负载均衡”的组合方式。这种拓扑能够让系统在用户量上升时平滑增加节点，同时保持配置和迁移过程的稳定性。

本文的部署指南重点覆盖：环境验证、组件安装、配置编排、身份整合、高可用设计、启动校验和运维交接。按此路径执行，团队可以搭建一套清晰且可扩展的 Oracle 海波龙基础平台。

场景分析

企业在构建绩效管理平台时，通常面对多种业务诉求。有的需要统一预算流程，有的需要集中合并与报告，有的需要将本地应用迁移到新数据中心。无论哪种场景，Oracle 海波龙 Foundation Services 都承担相同职责：为业务产品提供认证、权限、元数据和生命周期管理。因此，理解部署场景能帮助我们选择合适的目标架构。

场景一：集团企业统一绩效平台

集团型企业在总部和各成员单位之间需要运行统一的管理口径。使用 Foundation Services 作为公共入口后，成员单位的用户可以按照统一角色访问不同 Hyperion 产品。管理员在 Shared Services 中维护角色和权限，无需在每个模块中重复操作。

场景二：多模块融合部署

当企业同时采用预算、合并、盈利分析等模块时，Foundation Services 可以集中管理各模块的产品注册信息。任何一个模块在启动时都会读取公共元数据，确保各模块间的用户、维度和规则引用关系一致。

场景三：集中身份认证与外部目录对接

企业已有的 Active Directory 或 LDAP 目录可以接入 Foundation Services。人员入离调转信息由身份平台统一推送，Foundation Services 只负责映射内部角色。该场景对降低运维重复操作有明显价值。

场景四：环境迁移与灾备

在开发、测试、生产多个环境之间，需要通过 LCM 迁移业务对象。Foundation Services 提供统一的生命周期管理目录，让报表、规则、数据源连接等信息可以按目录导出并导入到目标环境。

{{image:0}}

Foundation Services 架构组件

组件概览

Foundation Services 包含五个核心层：安全服务层、元数据层、配置服务层、生命周期管理层和 Web 服务层。

• Shared Services：负责用户目录、角色、权限以及单点登录票据验证。所有 Hyperion 产品共用此服务。
• EPM System Configurator：负责数据库脚本执行、WebLogic 域创建、服务部署和配置项写入。它使安装过程从命令行变为可重复执行的流程。
• Lifecycle Management：用于跨环境移动业务工件，包括计算脚本、表单、规则包、安全配置和配置文件。
• EPM System Registry：保存产品实例的注册信息、依赖关系和版本信息。
• WebLogic Domain：提供 Java 容器运行环境，承载 Foundation Services 和各个业务模块的 Web 应用。

数据存储分层

在物理部署中，Foundation Services 通常需要三类存储：系统数据库、配置存储和共享文件目录。系统数据库保存注册信息和元数据；配置存储保存 WebLogic 域与安全配置；共享文件目录保存 LCM 归档、日志、上传的证书和临时文件。将共享文件目录挂载到所有应用节点，是集群部署的基础条件。

网络与端口

生产环境建议将应用服务器放在内网隔离区，外部流量通过反向代理或负载均衡器转发。管理端口、应用端口和数据库端口分别设置防火墙规则。启用 HTTPS 后，证书可统一由企业内部 CA 签发，也可以使用公开证书。

分阶段部署步骤

下面通过四个阶段说明部署路径。每个阶段都包含可验证的产出物，便于团队掌握进度。

阶段 A：环境准备

在安装之前，确认操作系统版本在 Oracle 海波龙支持列表中。安装匹配版本的 JDK，并配置 JAVA_HOME 环境变量。准备数据库实例，字符集和排序规则与 EPM 安装要求保持一致。创建专用操作系统账号，用于启动和停止服务。建立共享目录，并确保所有应用节点都能读写。

同时检查主机名解析。集群节点之间应使用完整的域名互相访问。避免使用动态分配的地址，因为在 WebLogic 域配置中，主机名和 IP 映射需要保持稳定。

部署物料清单

• 数据库实例：存放系统表、配置表、元数据和审计信息。
• Foundation Services 安装介质：与已选 Hyperion 模块保持版本兼容。
• WebLogic 中间件：作为 Foundation Services 的容器。
• LDAP 或 Active Directory：提供企业用户目录源。
• 共享存储：用于 LCM 归档、日志和证书文件。
• 负载均衡设备：对外提供统一访问入口。
• SSL 证书：用于 HTTPS 通信加密。

阶段 B：安装 EPM 系统

运行安装介质中的安装程序，选择产品目录。安装过程中需要选择 Foundation Services 以及需要使用的 Hyperion 模块。按照安装向导配置中间件主目录。二进制文件安装完成后，可以运行安装目录下的验证脚本，查看基础文件是否齐全。

在多节点集群中，有两种安装方式。一种是在共享存储上安装一次，让所有节点使用同一套二进制文件。另一种是每台节点独立安装，保证本地文件一致。两种方式各有适用条件，建议由经验丰富的架构团队确认。

阶段 C：配置 Foundation Services

配置是整个部署过程的核心。运行 EPM System Configurator 后，根据提示填写数据库连接信息。配置工具会自动创建系统表空间和配置表空间。选择 WebLogic 域模式，设置管理服务账号和密码。然后选择部署节点，将 Foundation Services 应用部署到指定的 Managed Server。

完成基础配置后，进入共享服务配置界面。将企业 LDAP 作为外部用户目录接入，创建内部角色与外部组之间的映射关系。如果企业需要单点登录，导入身份提供商提供的元数据或证书，开启 HTTPS，并设置票据验证方式。

阶段 D：启动与健康检查

启动顺序与停止顺序不同。启动时先启动 WebLogic Admin Server，再启动 Foundation Services Managed Server。观察日志输出，确认服务状态正常后，打开 Shared Services 控制台，使用管理员账号登录。

随后执行 EPM System Diagnostics，检查系统组件是否在线。验证 LCM 目录可以正常创建和读取归档文件。完成这些检查后，获取一份初始备份，作为未来回滚基准。

启动验证清单

• Admin Server 状态显示为 RUNNING。
• Foundation Services Managed Server 状态显示为 RUNNING。
• Shared Services 控制台可正常打开和管理员登录。
• EPM System Diagnostics 报告全部在线。
• LDAP 用户可同步并能映射到角色。
• LCM 目录可创建导出包。

部署中的关键技术控制点

身份目录映射

LDAP 对接时，需要控制好用户对象、组对象和角色三者的关系。先在外部目录中定义组，再将 EPM 内部角色赋予外部组。这样人员变动时，只需调整外部目录中的组关系，不需要逐个修改 EPM 用户。

内存配置

Foundation Services 运行在 WebLogic 上，JVM 堆大小要根据并发用户数设置。服务启动脚本中的内存参数要留出系统开销余量。每次调整内存后，观察 GC 日志和系统负载，找到合适数值。

共享文件目录权限

LCM 导出目录需要同时具备读写和删除权限。所有应用节点使用相同的挂载路径。目录权限建议由操作系统账号控制，避免使用过于宽松的权限设置。

健康检查与日志

建立每日健康检查脚本，检查 Admin Server、Managed Server、数据库连接和共享目录状态。日志目录按日期滚动，保留足够周期。通过集中日志平台收集关键日志，可提高问题定位效率。

高可用部署要点

生产环境推荐使用两个应用节点组成集群。负载均衡器开启会话保持，确保用户在一次登录期间始终访问相同节点。数据库层使用集群模式，避免单一数据库节点成为瓶颈。共享存储建议使用 NAS 或 SAN，并启用冗余链路。

在集群架构中，Foundation Services 的配置信息存放于数据库和共享目录中。当某个节点发生故障时，管理员可以从负载均衡列表中临时移除该节点，由剩余节点继续承担服务。修复完成后，再将该节点重新注册到集群。

贝则科技（beizetech）方案案例

某大型制造业集团计划构建统一的全面预算和管理报表平台。该集团已存在独立的身份认证系统，需要将多个绩效模块接入同一套用户权限体系。

贝则科技（beizetech）在项目初期完成基础设施调研，梳理现有网络、数据库和身份源。随后输出目标环境架构方案：使用两台应用服务器组成集群，承载 Foundation Services 与预算、合并模块；数据库使用独立高可用集群；共享文件目录用于 LCM 归档和日志输出。该方案可支撑企业后续增加新的绩效模块。

实施过程中，贝则科技完成了 EPM 系统安装、Foundation Services 配置、LDAP 对接、角色映射、HTTPS 证书部署和负载均衡配置。在联调阶段，通过 LCM 将开发环境中的预算规则、报表模板和元数据迁移到生产环境。上线后，用户通过企业统一门户访问海波龙系统，管理员在 Shared Services 中集中控制权限。

贝则科技同时向企业运维团队交付了部署文档、配置清单、操作手册和故障处理流程图。客户对交付过程表示认可，认为整体架构清晰，服务启动顺序明确，日常维护有据可依。

FAQ

Foundation Services 与 Shared Services 有什么关系？

Shared Services 是 Foundation Services 内部的安全与用户管理组件。Foundation Services 还包含配置、元数据、生命周期管理等功能。可以理解为 Shared Services 是 Foundation Services 的组成模块之一。

部署 Foundation Services 对数据库有什么要求？

需要准备独立数据库实例，用于存放系统表、配置表和元数据。数据库版本和字符集需对照 Oracle 海波龙支持矩阵进行选择。不建议与业务生产库共用实例。

多节点部署时，哪些内容必须共享？

共享 LCM 归档目录是必须项。系统配置目录和证书目录也应在节点间保持一致。数据库和应用服务本身运行在独立资源上，网络层面通过负载均衡对外提供服务。

如何保障环境迁移的一致性？

使用 LCM 将开发环境中的对象以目录方式导出，导入到测试和生产环境。导入前检查目标环境的 Foundation Services 版本与源环境一致，导入后执行系统诊断，并比较导入日志中的对象数量。

客户评论

“贝则科技的部署方案帮我们把 Hyperion 基础平台梳理得井井有条。上线后服务运行稳定，运维团队能按文档完成日常巡检。” —— 某集团财务共享中心负责人

“Foundation Services 的权限统一和 LCM 迁移在项目中起到了关键作用。贝则科技的架构建议给了我们继续扩展的信心。” —— 某企业信息化中心总监