定义、设计和提供成功 Oracle RAC 项目的指南。
2006 年 4 月发布
Oracle 真正应用集群 (RAC) 是 RDBMS 市场中的最佳数据库集群。Oracle RAC 的配置选项和特性为公司提供设计其高可用性解决方案的广泛的灵活性。但是，如何使用所有配置选项、特性和灵活性成功地实施？
本文是定义、设计和提供成功 Oracle RAC 项目的指南。它详细介绍了减少风险和增加成功实施机会的详细步骤。此外，它还突出了您在实施 Oracle RAC 项目过程中可能会犯的错误，并提供了避免这些错误的建议。
尽管这篇文章侧重于 Oracle RAC，但下列步骤对许多种 Oracle 实施项目均试用。（注意，本指南仅用于提供信息，无论在何种情形下，您都不可将其视为咨询服务。）
下面我们开始吧！
确定需求
成功实施 Oracle RAC 的第一个重要阶段是确定项目的真实目标。“确定需求”一步涉及识别和记录项目实施阶段要提供的特性和功能。
在实施 Oracle RAC 过程中，您还要经常核对这些需求。将需求记录成文将有助于实施 Oracle RAC 项目。否则，您将发现该项目难以管理，这是因为在项目实施过程中会不断出现意料不到的新问题。
避免错误的方法 1： 确保关键业务和技术人员积极地参加项目需求的确定。明确地将所有需求传达给项目负责人，包括关键的管理人员、技术人员以及最终用户。
第 1 步 — 确定项目范围
“确定需求”阶段的第一步就是确定项目范围。项目范围是用于论证项目业务需求的一系列细项，它说明了项目的可交付成果。项目范围有时也称为“业务需求”。
要确定项目范围，请回答下列问题：
以下是一个详细说明一个 Oracle RAC 示例的高级目标的项目范围文档。
|
理由 |
我们实施 Oracle RAC 是为了使我们的应用程序可伸缩和高度可用，以及为我们的客户提供更可靠的服务。 |
|
目标/可交付产品 |
该项目的最终产品将是一个新的 Oracle RAC 系统，它支持在我们的服务等级要求文档中详细规定的服务等级*。*见下面的附件 |
|
项目日程限制 |
该项目必须在 2006 8 月 前完成。 |
|
项目成本限制 |
项目成本应不超过 $XXX,XXX。 |
避免错误的方法 2： 努力使项目目标量化。您将能重新核对这些目标，掌握整个项目的完成情况。量化目标的工作包括记录项目日程和成本限制。
第 2 步 – 确定项目团队
确定项目团队就要确定为项目制定交付目标的人和愿意完成项目方案中的任务的人。这些人可能来自组织的多个部门，如决策人员、业务分析人员和技术人员。
下表是典型 Oracle RAC 项目的人员组成，并列明了他们的职能和完成项目所采取的步骤。
|
角色 |
职责 |
参与阶段 |
Oracle RAC–具体任务 |
|
决策人 |
|
|
|
|
IT 经理 |
|
|
|
|
项目经理 |
|
|
|
|
数据库管理员 |
|
|
|
|
网络管理员 |
|
|
|
|
系统管理员 |
|
|
|
|
应用程序开发人员 |
|
|
|
|
测试人员 |
|
|
|
|
应用程序用户 |
|
|
|
Oracle RAC 项目团队成员的职责会因地制宜，这取决于场地的大小和系统需求。
在组建该项目团队的时候，可能无法找到最合适的人员，因此，您只能找到可用 的人员。在这种情况下，对项目团队成员进行适当的技术培训可以降低实施风险。技术培训通常可以降低项目风险和较高质量地完成项目。
避免错误的方法 3： 如果新的 Oracle RAC 系统要取代已有的旧系统，需要让对旧系统经验丰富的人也参与。吸纳这些团队成员将有助于确保满足所有项目需求。
第 3 步 – 确定服务等级需求
“需求确定”阶段的第三步是确定服务等级需求。服务等级需求是指期望 Oracle RAC 项目实施支持的服务等级。这些需求包含预期的服务等级和操作需求，并提供处理延期和失败的指导原则。
服务等级需求可以分为两类：服务等级需求和操作需求。
服务等级需求帮助 Oracle RAC 技术实施与项目的范围（项目的业务目标）保持一致。确定服务等级需求应先从分析现有系统的需求开始。分析包括查看现有系统的操作、技术以及支持的程序和文档。
可以通过回答诸如以下问题进一步确定服务等级需求
这些问题的回答通常可组成一个分级、分层的服务等级需求表，该表定义了不同的服务等级。
下面是一个服务等级表示例。具体的服务等级和层数取决于您的组织数和业务部门数。
|
层 |
安全等级描述 |
性能 |
可用性 |
所需解决方法 |
|
5 |
正常操作 |
系统响应正常。 |
系统 100% 可用。所有中断均正确排定。 |
无 |
|
4 |
安全等级 4： 问题微不足道，影响很小或无影响 |
性能比所要求的基准低 10%-30%。 |
应用程序应用程序功能的 90%-95% 可用。 |
必须在五天内解决 |
|
3 |
安全等级 3： 问题很小，几乎没有影响 |
性能比所要求的基准低 30%-50%。 |
应用程序应用程序功能的 85%-90% 可用。 |
必须在三天内解决 |
|
2 |
安全等级 2： 问题需要关注，可感受到有影响 |
性能比所要求的基准低 50%-70%。 |
应用程序应用程序功能的 80%-85% 可用。 |
必须在一天内解决 |
|
1 |
安全等级 1： 问题很严重，对业务有严重影响 |
性能比所要求的基准低 70% 或更低。 |
应用程序应用程序功能的 75% 以下可用。 |
必须在三小时内解决 |
操作需求规定了维护 Oracle RAC 系统和满足以上定义的服务等级需求所需的程序。通常，操作需求包括排定的维护中断、系统启动和关闭、系统备份、Oracle RAC 系统可用性、故障切换程序以及灾难恢复计划的信息。
可以通过回答诸如以下问题确定操作需求
以下是一个 Oracle RAC 操作需求列表示例。
|
排定的维护中断 |
留出每个月的最后一个周末来进行 Oracle RAC 系统维护操作。中断时间不会超过 56 小时（从星期五晚上开始）。这些中断专门留给那些无法“联机”执行的维护操作。 |
|
系统备份 |
完整备份将在周末联机执行，而在一周其他天的晚上则执行累积备份。磁带上保存着相当于四周的备份，而磁盘上则保存相当于一天的备份。 |
|
故障切换程序 |
所有应用程序会话在发生单节点故障时都应可切换到可用的 Oracle RAC 节点上。在发生一个局部灾难，使所有 Oracle RAC 节点都不可用时，该处的备用环境应在三个小时内联机。 |
|
灾难恢复程序 |
当灾难遍及整个场所时，场所外的备用环境将在三个小时内联机。 |
|
系统容量 |
系统应支持当前的用户负载（以及两年内的用户数量预期增长）以及当前的应用程序。在系统无法满足用户负载要求时，就需要增加 Oracle RAC 节点。处理器、内存和存储需求将基于从运行在现有硬件上的当前应用程序的性能来确定。 |
避免错误的方法 4： 获得系统最终用户、客户和操作人员对服务等级和操作需求的认可和官方批准。这包括就性能、可用性以及对系统失败的适当反应达成一致。
第 4 步 – 确定项目日程
“确定需求”阶段的最后一步就是确定项目日程。由于需要确保有足够的时间建立 Oracle RAC 解决方案来满足以上定义的所有需求，因此日程安排对项目成败至关重要。
日程安排涉及构建系统、为每个任务分配时间、以最优的顺序排列任务等所有任务的细节。
避免错误的方法 5： 在安排项目日程的过程中，应努力使每个项目成员清楚所有时间限制（见“第 1 步”）。征询每个团队成员的意见，准确评估和规划项目日程。
有时，可以在项目日程中同时执行多个任务。巧妙地并行安排任务通常会按时完成项目并节省项目成本。
以下是一个高级 Oracle RAC 日程示例。它展示了在 Oracle RAC 部署中经常执行的任务。
|
任务名称 |
存在期间 |
开始时间 |
结束时间 |
前置任务 | |
|
1 |
服务器硬件配置 |
2 天 |
2005 年 12 月 1 日星期四 |
2005 年 12 月 2 日星期五 |
|
|
2 |
共享存储配置 |
1 天 |
2005 年 12 月 1 日星期四 |
2005 年 12 月 1 日星期四 |
|
|
3 |
OS 安装 |
1 天 |
2005 年 12 月 5 日星期一 |
2005 年 12 月 5 日星期一 |
1 |
|
4 |
网络配置 |
1 天 |
2005 年 12 月 6 日星期二 |
2005 年 12 月 6 日星期二 |
3 |
|
5 |
Oracle 数据库软件安装 |
1 天 |
2005 年 12 月 7 日星期三 |
2005 年 12 月 7 日星期三 |
4 |
|
6 |
数据库构建 |
2 天 |
2005 年 12 月 8 日星期四 |
2005 年 12 月 9 日星期五 |
5 |
|
7 |
数据加载 |
5 天 |
2005 年 12 月 12 日星期一 |
2005 年 12 月 16 日星期五 |
6 |
|
8 |
单元测试 |
2 天 |
2005 年 12 月 19 日星期一 |
2005 年 12 月 20 日星期二 |
7 |
|
9 |
压力/集成测试 |
5 天 |
2005 年 12 月 21 日星期三 |
2005 年 12 月 29 日星期四 |
8 |
|
10 |
故障切换测试 |
2 天 |
2005 年 12 月 30 日星期五 |
2005 年 1 月 3 日星期二 |
9 |
|
11 |
备份与恢复测试 |
19 天 |
2006 年 12 月 12 日星期三 |
2005 年 1 月 4 日星期三 |
5 |
|
12 |
系统集成 |
5 天 |
2006 年 1 月 5 日星期四 |
2006 年 1 月 11 日星期三 |
11 |
|
… |
… |
一个相对详细的项目日程可以使 Oracle RAC 团队跟踪项目的进度，主动对日程迟延做出回应。当需要更改日程时，一定要确保完全记录了所有更改。最初的项目日程和该更改报告为以后项目日程的制定提供了重要的参考。
避免错误的方法 6： 利用可同时执行的多个任务。在上述的项目日程中，注意 Task #11 是如何与 Task #7 到 Task #10 同时运行的。
在确定和记录了项目范围、项目团队、服务等级需求以及项目日程后，采用一个强有力的更改控制机制。仔细管理对需求的任意更改，把成本控制在预算内，使项目按日程进行。
技术架构设计和构建
成功部署 RAC 实施的第二个主要阶段是确定和实施 Oracle RAC 部署的技术架构规范。技术架构描述了将组成新系统的硬件、软件和配置的详细情况。由于大多数 Oracle RAC 实施集中在从单实例环境移植到 Oracle RAC 实例环境，而没有重新设计他们的应用程序和数据库，因此您将在该阶段中设计和构建 Oracle RAC 环境。
下列步骤解释了如何将需求转化为可用的设计。
第 1 步 – 确定硬件和软件规范
该步骤包括了解上面定义的服务等级需求和操作需求，然后把这些需求转化为硬件和软件规范。它还考虑了硬件的兼容性，特定的操作系统要求以及 Oracle RAC 特定的软件需求。
使用下面的“硬件/软件注意事项表”组为核对单，用于记录在本步骤中决定。对于您的个别实施，填写您项目使用的真正硬件和软件。
填写该表时，回答以下问题
避免错误的方法 7： 确保 Oracle RAC 项目团队知道组成 Oracle RAC 系统每个组件的功能和特性，以及所有组件已通过认证，可以一起使用。您可以通过适当的技术培训和概念验证测试来降低 Oracle RAC 项目的风险。
|
组件 |
满足项目需求？ |
满足 OS 需求？ |
满足 Oracle RAC 需求？ |
与其他硬件/软件组件兼容？ |
|
硬件组件 |
||||
|
服务器（节点数） |
||||
|
处理器（每节点 CPU 数） |
||||
|
内存（每节点 GB 数） |
||||
|
HBA |
||||
|
网卡（每节点网卡数） |
||||
|
本地磁盘（每节点 GB 数） |
||||
|
SAN/共享存储（GB） |
||||
|
软件组件 |
||||
|
操作系统 |
||||
|
硬件驱动器 |
||||
|
卷管理/多路径软件 *包括 ASM、RAW 或 OCFS 卷管理决定 |
||||
|
Oracle Clusterware/Oracle 数据库软件 |
||||
|
Oracle 客户端软件 |
避免错误的方法 8： 如果要移植到一个全新的硬件和/或软件平台，那一定要测试一下您的应用程序。更换平台可能需要更多的处理器或内存，以满足服务等级需求。
第 2 步 – 执行规范
填完上述核对单后，就要搭建 Oracle RAC 环境了。
这些任务包括：
RAC 系统测试
Oracle RAC 测试策略应至少包括四种测试：概念验证测试、单元测试、集成测试以及负载测试。
该测试策略不是一个独立于以上阶段单独执行的功能，而是一个集成到了确定、设计、构建等阶段中的一个过程。
该部分着重强调四种测试，并确定每种测试所对应的项目阶段。
概念验证测试
概念验证测试是对概念可行性的测试。它可以是新技术、新软件架构或新硬件的测试。概念验证测试使项目团队可以测试项目决策的有效性，从而使他们可以快速做出有关项目方向的重要决策。概念验证测试通常在“服务级别需求”和“技术架构设计和构建”步骤中执行。
|
测试 |
说明 |
项目阶段 |
好处 |
|
概念验证测试 |
确认项目决策的有效性，尤其是硬件和软件决策的有效性 |
|
使项目团队可以做出大是大非的项目决策 |
单元测试
单元测试包含单一硬件或软件组件测试以及单一应用程序或应用程序模块测试。这些孤立的测试确定单一组件或模块是否按执行要求运行。
Oracle 10g 第 2 版包括一个称为 Cluster Verification Utility (CVU) 的验证实用程序，它是一个用于对 Oracle RAC 节点的硬件和软件配置进行测试的工具。可以使用该实用程序验证 Oracle RAC 节点的配置、检查操作系统以及检查网络设置。
单元测试的一个重要元素就是“破坏性测试”的引入。测试人员通过破坏性测试模拟异常活动以及试图破坏系统。Oracle RAC 环境中的一个破坏性测试示例为故意破坏 Oracle Cluster Registry (OCR)，然后执行恢复系统所需的步骤。像这样的测试会让项目成员发现系统的薄弱环节，从而做好应对准备。
|
测试 |
说明 |
项目阶段 |
好处 |
|
单元测试 |
测试个别硬件、软件和应用程序组件，加入“破坏性测试”发现系统的薄弱环节 |
“技术架构构建”任务：
|
确认单个组件和模块正常运行 |
集成测试
集成测试包括确认多个硬件、软件或应用程序模块可共同运行。集成测试确认系统是否按规定运行。
|
测试 |
说明 |
项目阶段 |
好处 |
|
集成测试 |
测试多个硬件、软件以及应用程序组件共同运行 |
“技术架构构建”任务：
|
确认集成的组件和模块可共同运行 |
压力测试
压力测试也称为负载测试或系统测试，是一个模拟动态生产负载的端到端测试。它用于确定系统是否可以承受生产使用等级、是否满足服务等级需求，以及收集性能数据。它还用于预测当前和未来的使用容量。通常在上述测试返回肯定的结果时以及完全配置硬件、软件和应用程序组件后才执行压力测试。由于它代表一个重要的项目里程碑，因此将其视为一个独立的项目阶段。
|
测试 |
说明 |
项目阶段 |
好处 |
|
压力测试 |
模拟系统上的一个动态生产负载 |
压力测试 |
确认系统已可用于生产 |
避免错误的方法 9： 测试会耗费大量时间和金钱。对比执行测试所需的资源和再生产阶段发生系统故障的风险，仔细权衡测试方案的长处和短处。
操作就绪
什么时候可以使用新系统？
前述项目阶段及其相关的步骤简化了新系统可用性的测试。尽管完整的核对单取决于您具体的站点，但以下通用大纲可以帮助您定义、设计、测试您的 Oracle RAC 实施。
操作就绪的确定取决于已完成的任务熟、项目日程中完成任意未完成任务所剩的时间、新系统当前状态下的稳定性。它还取决于已满足的项目需求数。
下面是一个包含本文所述的所有事实阶段和步骤地一个详细的项目方案。它包括一个集成的测试方案和一个“启动必需？”列，帮助您确定是否确实需要该特定项来使系统联机 — 或是否在系统启动后将该特定项联机。
|
任务 |
任务说明 |
启动必需？ |
完成？ |
|
定义 |
确定需求 |
||
|
确定项目范围 |
确定项目的高级业务目标 |
||
|
确定项目团队 |
确定项目团队 |
||
|
确定服务等级需求 |
确定服务等级需求 |
||
|
确定操作需求 |
确定操作需求 |
||
|
概念验证测试 |
使项目团队初步熟悉所涉及的技术，帮助确定项目日程以及为“设计和构建”阶段做好准备 |
||
|
确定项目日程 |
确定项目日程 |
||
|
设计和构建 |
技术架构设计和构建 |
||
|
硬件和软件规范 |
确定项目要使用的硬件和软件组件 |
||
|
概念验证测试 |
验证硬件和软件组件的选择 |
||
|
服务器硬件配置 |
构建服务器硬件 |
||
|
操作系统配置 |
安装和配置操作系统 |
||
|
服务器单元测试 |
测试节点单元（在安装 Oracle 数据库前使用 CVU 预验证服务器配置） |
||
|
操作系统单元测试 |
测试 OS 单元（在安装 Oracle 数据库软件前使用 CVU 验证 OS 配置） |
||
|
网络单元测试 |
测试节点单元（在安装 Oracle 数据库前使用 CVU 验证网络配置） |
||
|
Oracle 软件配置 |
安装和配置 Oracle 数据库软件 |
||
|
集成测试 |
确认所有硬件和软件组件可正常运行，例如通过创建一个 Oracle RAC 测试数据库 |
||
|
操作任务 |
为压力测试和生产使用准备好系统 |
||
|
集成测试 |
确认应用程序在新 Oracle RAC 环境中正常运行 |
||
|
测试 |
Oracle RAC 系统测试 |
||
|
压力测试 |
模拟 Oracle RAC 系统上的生产负载 |
总结
在前三个项目阶段中，您确定了核心的项目目标、确定了项目需求、把需求转换为规范、创建了测试方案。此外，您还创建了确定 Oracle RAC 实施的操作就绪性的标准。所有这些加在一起就是您的 Oracle RAC 实施项目方案。
该方案变成了一个无价的工具，帮助您实现您的最终目标，使您可以一路预测任意问题。使用这样的方案可以 确保成功的 Oracle RAC 实施 — 在预算内按时交付。