了解业务关键型应用程序高可用性的复杂性

最大限度地减少系统、数据库和应用程序的停机时间是最大限度提高生产力的关键。 现代组织依靠关键业务系统、数据库和应用程序（例如企业资源规划 (ERP)、客户关系管理 (CRM)、电子商务、财务系统和供应链管理）来高效运营并提供卓越的客户体验. 当系统、数据库或应用程序出现故障时，高可用性保护会恢复操作以保持业务正常运行。

什么是高可用性？

高可用性是系统、数据库或应用程序的一个属性，旨在长时间连续可靠地运行。 高可用性的目标是通过合并冗余组件和其他技术来解决系统、数据库或应用程序中的单点故障，从而减少或消除关键应用程序的计划内和计划外停机时间。

简单地说，高可用性确保您的系统、数据库或应用程序按预期运行：“何时”是指系统、数据库或应用程序必须按预期启动和运行的时间百分比——这意味着应用程序按用户期望和满足的方式运行及时满足他们的需求。

数据中心模式

高可用性服务级别协议 (SLA) 有助于确保 IT 基础架构的关键组件在工作时间内正常运行和可用。 IDC 为高可用性创建了一个 SLA 模型，该模型定义了具有以下正常运行时间要求的五个级别： • AL4（持续可用性——系统容错）：无用户中断，每年计划内和计划外停机时间总计最多不超过 5 分 15 秒（99.999% 或“五个九”可用性）。
• AL3（高可用性——传统集群）：最少的用户中断和每年最多不超过 52 分 35 秒的计划内和计划外停机时间（99.99% 或“四个九”可用性）。
• AL2（恢复——数据复制和备份）：一些用户中断和每年最多不超过 8 小时 45 分 56 秒的计划内和计划外停机时间（99.9% 或“三个九”的可用性）。
• AL1（可靠性——热插拔组件）：所有服务停止，每年总计 87 小时 39 分 29 秒的计划内和计划外停机时间（99% 或“两个九”的可用性）。
• AL0（未受保护的服务器）：所有服务停止，并且未定义正常运行时间 SLA。

您的高可用性要求取决于整个系统、应用程序和许多其他因素的重要性，包括： • 应用程序对业务有多重要 • 客户是否注意到影响 • 应用程序运行的频率 • 有多少用户受到停机影响 • 数据库或应用程序必须以多快的速度故障转移到冗余系统以避免中断 • 有多少数据损失是可以容忍的 五个九的可用性通常是为需要连续“有状态”操作的应用程序保留的。 对于业务关键型应用程序，四个九的可用性是标准的。 非关键系统和应用程序，您可能只需要两个九的可用性。 在确定可接受的停机时间时，重要的是要考虑： • 计划外停机时间（即硬件或软件故障） • 例行硬件和软件维护的计划停机时间 • 应用程序和数据库级别的正常运行时间 各种高可用性解决方案可以帮助企业实现其 SLA 目标针对不同的系统、数据库和应用程序。 尽管持续可用性 (AL4) 似乎是关键业务部署的最合适目标，但在成本和可用性之间找到适当的平衡点很重要。 连续可用性还会对计划维护所需的停机时间产生负面影响，因为在应用应用程序或操作系统更新时系统通常必须脱机，而高可用性通常允许滚动更新。

高可用性指标：RTO 与 RPO

除了正常运行时间和可用性之外，恢复时间目标 (RTO) 和恢复点目标 (RPO) 是用于评估系统、数据库或应用程序中的高可用性（以及灾难恢复）的重要指标。

反收购行动是任何中断的最大可容忍持续时间。 在线事务处理应用程序通常具有最低的 RTO，而那些业务关键型应用程序的 RTO 通常只有几秒钟。

RPO是发生故障时可以容忍的最大数据丢失量。 对于灾难恢复，应用程序及其相关数据的典型 RPO 可能是 24 小时。 每晚备份可确保在发生灾难时可以恢复过去 24 小时内对数据所做的任何更改。 但是，对于高可用性应用程序和数据，RPO 通常为零。 也就是说，在任何故障情况下都不应该有数据丢失。

传统聚类

高可用性集群是一组服务器节点（和其他组件），它们支持需要最少停机时间的关键业务应用程序。集群软件允许您将服务器配置为集群，以便多个服务器可以协同工作以提供高可用性并防止数据丢失。 IT 组织依靠高可用性集群来消除单点故障并将停机和数据丢失的风险降至最低。

传统的本地高可用性集群是一组连接到共享存储（通常是存储区域网络或 SAN）的两个或多个服务器节点，这些节点配置有相同的操作系统、数据库和应用程序（参见图 1） ).

其中一个节点被指定为主要（或活动）节点，其他节点被指定为次要（或备用）节点。 如果主节点发生故障，集群允许系统、数据库或应用程序的操作自动故障转移到一个或多个辅助节点，并继续正常运行，中断最少。 由于辅助节点连接到同一存储，因此操作继续进行，数据丢失为零。 这种集群架构的好处是减少停机时间、消除数据丢失和保护数据完整性。

但是，有很多场景不需要共享存储。 共享存储中的故障将使所有集群脱机，从而产生单点故障 (SPoF) 风险。 SAN 存储的拥有和管理成本高昂且复杂。 最后，在云中使用共享存储会显着增加不必要的成本和复杂性。 有些云根本不提供共享存储选项。

如图所示图 2, SANless 或“无共享”集群是共享存储的最佳替代方案。 在这些配置中，每个集群节点都有自己的本地存储。 高效的基于主机的块级复制用于同步集群节点上的存储，使它们保持相同。 在发生故障转移时，辅助节点访问主节点使用的存储的相同副本。 这种集群架构的优势在于消除 SPoF、消除 SAN 成本和复杂性、在云中易于使用和节省成本、减少停机时间并减少数据丢失。

设计原则

最先进的高可用性集群包含以下设计原则： • 当一个活动组件发生故障时，它们会自动快速地故障转移到冗余系统 • 它们在故障转移期间和之后保持特定于应用程序的最佳实践 • 它们提供手动切换和切回的能力，以实现高效测试和“滚动”维护，且成本最低计划内停机 • 它们可以自动检测网络、存储、操作系统、硬件或应用程序中的故障 • 它们可以防止在系统发生故障时丢失数据 • 它们可以跨不同地理位置的节点进行故障转移以实现灾难恢复

高可用性集群

各种集群软件解决方案可用于 Windows、Linux 发行版和各种管理程序（虚拟机解决方案）。 一组仅支持一个操作系统，例如： • Windows 服务器故障转移群集 (WSFC)：为 Microsoft SQL Server 和 Microsoft Exchange 等托管应用程序提供高可用性和灾难恢复 • SUSE Linux Enterprise 高可用性扩展 (HAE)：支持物理和虚拟 Linux 服务器的集群，具有策略驱动的集群和连续数据复制• 红帽起搏器（Pacemaker）：为性能、高可用性、负载平衡和可伸缩性创建单站点集群 例如，这里列出的解决方案都不能保护在 Oracle Linux 操作系统上运行的 SAP。 因此，每个解决方案都会限制您的灵活性和部署选项。 更先进高可用性解决方案，例如适用于 Linux 的 SIOS Protection Suite，在主要 Linux 发行版（包括 Oracle Linux、Red Hat 和 SUSE）中提供应用程序感知保护。

此外，每个应用程序、数据库和 ERP 系统都有自己的配置和持续管理要求。 为了满足这些要求，HAE 和 Pacemaker 通常需要高度的技术技能和复杂的手动脚本，这会引入人为错误和不可靠的故障转移的可能性。

通常受故障转移集群保护的关键业务应用程序、数据库和 ERP 系统的一些示例包括 SAP S/4HANA、SQL Server 和其他应用程序和数据库。

SAP S/4HANA多家 Linux 供应商在其“Enterprise for SAP”订阅中为 SAP 提供开源高可用性扩展。 SAP S/4HANA 环境包含多项服务，例如 ABAP SAP 中央服务 (ASCS)、评估收据结算 (ERS) 和其他 SAP 组件，这些服务需要在正确的位置进行维护并以正确的顺序启动。 在 SUSE HAE 和 Red Hat Pacemaker 等开源集群产品中，在这些复杂环境中手动配置和管理集群可能非常耗时，而且容易出现人为错误，从而增加灾难性停机和数据丢失的风险。

创建应用程序感知的高可用性解决方案还需要在应用程序和数据库方面具有特定的深厚专业知识。 相比之下，适用于 Linux 的 SIOS 保护套件包括用于 SAP 和 HANA 的应用程序恢复工具包，可确保故障转移保持应用程序最佳实践。

SAP 还提供 HANA 系统复制，这是 HANA 软件附带的一项功能。 它可以将 SAP HANA 数据库持续同步到同一数据中心、远程站点或云中的辅助位置。 数据被复制到辅助站点并预加载到内存中。 发生故障时，备站点接管，无需重启数据库，有助于降低RTO。 但是，必须手动触发到主节点的故障回复。 HSR 需要与应用感知集群软件（如 SIOS Protection Suite）搭配使用，后者可以检测故障并在必要时协调故障转移。

数据库服务器

许多公司依靠 SQL Server 作为支持重要业务功能的关键应用程序的后端数据库。 Microsoft WSFC 通常用于支持 SQL Server 应用程序的 Always On 可用性组 (AG) 和 SQL Server 故障转移群集实例 (FCI)。

但是，带有 AG 的 WSFC 需要昂贵的 SQL Server 企业版许可。 此外，使用 FCI 时，整个实例将故障转移到备用节点。 使用 AG，只有组中的数据库受到保护。
使用SIOS 数据管理员WSFC 允许您使用具有成本效益的标准版许可为 SQL Server 提供高级高可用性保护。

其他应用程序和数据库

SIOS 软件可用于保护各种关键业务应用程序、数据库和 ERP，包括 Oracle、MaxDB、MySQL、PostgreSQL 和 DB2。 SIOS 软件支持集群和灾难恢复。

在我们的下一篇博客中，我们将研究特定的行业用例，以帮助您了解不同的企业如何为其关键任务应用程序实现高可用性。

经许可转载自信息系统

Epicure 使用 Amazon EC2 和 SIOS SANLess 集群软件保护关键业务 SQL Server

SIOS DataKeeper Cluster Edition 软件提供高可用性和灾难保护。

Epicure 是加拿大领先的直销公司，通过 16,000 多名顾问组成的网络销售健康、易于准备的食品。 该公司依靠两个网站进行关键业务运营。 他们的公共网站向其客户和有兴趣成为顾问的人提供公司和产品信息、食谱、博客和注册信息。 他们的内部网站为顾问提供有关产品的重要信息，并使他们能够下达所有订单。 “我们的网站对我们的业务至关重要，”Epicure 高级网络基础设施管理员 Russell Born 说。

环境

Epicure 的两个网站都在使用两个 SQL Server Standard Edition 实例的单个服务器上运行——每个网站一个。 随着公司扩展其产品和服务，Epicure IT 部门需要更新并确保其两个关键业务网站在发生故障或灾难时继续运行。 他们决定将这两个网站从第三方托管设施迁移到其本地数据中心，并使用 Amazon Web Services EC2 云进行灾难恢复。 “通过将网站引入内部，我们可以确保我们的网站在业务持续增长的同时为我们的客户和顾问提供出色的用户体验，”Born 说。

挑战

作为此网站更新过程的一部分，Epicure IT 人员希望以一种高效、经济的方式为两个网站提供高可用性和灾难保护，同时继续在 SQL Server Standard Edition 的两个实例上运行它们。

“如果我们可以为 HA 和 DR 提供更具成本效益的标准版，我们不希望因迁移到 SQL Server 企业版而增加费用，”Born 说。

解决方案

使用 SIOS DataKeeper Cluster Edition 软件，Epicure IT 人员在主动-被动故障转移配置中创建了一个双节点 SANLess 集群，使每个 SQL 实例能够独立进行故障转移。 一个集群节点位于 Epicure 本地数据中心，第二个节点位于 AWS EC2 云实例中。 Epicure IT 人员创建了 SIOS SANLess 集群，并使用该软件直观的图形用户界面对其进行了配置。

结果

SIOS 软件为 Epicure 提供了一种简单、经济高效的方式来为其关键业务 SQL Server 应用程序提供 HA 和 DR 保护，而无需构建远程 DR 站点或购买昂贵的 SAN 存储或 SQL Server Enterprise Edition 许可证的成本和复杂性. “SIOS 软件使我们能够创建一个混合解决方案，既可以节省本地运行的成本，又可以提供在云中运行的可靠性和灵活性，”Born 说。 “因为我们知道，如果出现网站中断，它会自动进行故障转移，我们的 IT 团队现在可以将注意力集中在其他优先事项上，以加强我们的业务。”

经许可转载自信息系统

SIOS DataKeeper 集群软件使 Gulliver International 能够将内部 IT 系统安全地迁移到 Amazon Web Services

SIOS 软件在 AWS 环境中提供高可用性，使领先的二手车公司能够将所有 IT 系统迁移到云端。

Gulliver International 是一家领先的二手车公司，总部位于东京，在日本各地拥有 420 家门店。 在接下来的四年里，该公司计划扩展到全球业务，在全球拥有 1600 家门店。 为确保其 IT 基础设施能够适应这种快速增长，该公司正在将其所有内部系统迁移到 AWS，并在全公司范围内推广针对所有新应用程序的“云优先”政策。

Gulliver International 的 IT 经理月岛学 (Manabu Tsukishima) 表示：“将我们的系统迁移到云端将为我们提供快速和经济高效增长所需的灵活性和可扩展性，同时持续为我们的客户提供优质服务。”

挑战

为了确保他们的云优先计划取得成功，Gulliver 需要保护他们的关键业务应用程序在云环境中免受停机，而传统的故障转移集群是不可能的。

“如果没有高效、易于实施的高可用性解决方案，我们不会考虑将我们的应用程序迁移到云端，”Tsukishima 说。 Gulliver 选择使用 SIOS DataKeeper 软件，该软件由 SIOS Technology, Inc. 在日本销售。

解决方案

SIOS DataKeeper 软件使 Gulliver 能够使用 Windows Server 故障转移集群 (WSFC) 在云环境中构建故障转移集群，而传统的共享存储集群是不可能的。

SIOS 软件使用高效、实时的复制来同步在 AWS 环境中作为 WSFC 集群运行的服务器之间的存储。

使用 SIOS 软件，Gulliver 可以将两台服务器配置为跨不同的 Amazon 可用区作为集群运行。

就像在传统的物理环境中一样，如果一个可用区内的AWS云中的主服务器发生故障，WSFC将应用程序移动到位于另一个亚马逊可用区的第二台服务器上，提供完全的云容灾和恢复.

结果

“我们对 SIOS DataKeeper 软件为我们公司的云优先计划带来的价值感到非常高兴，”Tsukishima 说。 借助 SIOS DataKeeper 软件，Gulliver 可以迁移到云端，而不会增加现有操作的复杂性或中断。

“通过使我们能够以与在物理环境中相同的方式在云中使用集群配置，SIOS DataKeeper 软件使我们能够迁移到 AWS，而不会牺牲应用程序保护或完全改变我们现有系统的配置。 ” Gulliver 大约 30% 的现有本地系统已迁移到 AWS，而没有对公司的系统管理进行任何更改或增加复杂性。

随着 Gulliver 继续执行其扩展计划，它很快将需要保护更大量的数据和更广泛的应用程序。 为了满足这一需求，它将在将系统迁移到云端时继续使用 SIOS DataKeeper 软件。 作为 APN（AWS 合作伙伴网络）的标准咨询合作伙伴，SIOS 致力于继续提供在 AWS 上运行的高可用性系统。”

经许可转载自信息系统

在 AWS 中创建 HA Oracle 数据库服务器集群

介绍作为一名负责为需要 Oracle 高可用性 (HA) 实例的关键业务应用程序创建 POC 的开发人员，我需要在 AWS EC2 中设置一个 Oracle EC2 HA 集群。你从哪里开始？如果您像我们大多数人一样，您将花费无尽的时间在谷歌上搜索您的下一个任务、阅读文章、安装指南、文档和关于堆栈溢出的问题。 您会发现很多几乎正确的答案，但它们永远不会完全适合您的版本或环境。 更糟糕的是，您掉进了一个兔子洞，最终浪费了数天时间来构建一个无法正常工作的环境。

我将构建一系列博客，这些博客专注于设置 HA 环境以使用各种SIOS HA 解决方案例如：DataKeeper、LifeKeeper 和 SIOS Protection Suite。 如果您有我尚未涵盖的即时需求，请告诉我，我会将您的配置移到我的待办事项列表中。

谢谢您阅读此篇。我希望它能让你的生活更轻松。 我在下面有一个任务列表，如果您已经熟悉如何完成这些任务，您可以直接完成这些任务。 下面是执行每项任务的分步指南。

AWS HA Oracle 数据库 SIOS Protection Suite for Linux

1. 在 Linux 上启动 2 个 Oracle 实例
2. 让 Xwindows 工作
3. 连接到实例并安装额外的磁盘
4. 安装 AWS 命令行工具包
5. 配置安全/访问
6. 为虚拟 IP 创建路由条目
7. 禁用 ENI 的源/目标检查
8. 编辑/etc/hosts
9. 使用 VIP 主机名配置侦听器
10. 禁用 SELinux
11. 安装适用于 Linux 的 SIOS 保护套件
12. 启动 LifeKeeper
13. 连接到第二台服务器
14. 建立沟通路径
15. 创建 DataKeeper 资源
16. 使用虚拟 IP 资源创建层次结构
17. 创建 Oracle 侦听器资源
18. 使用 Oracle 数据库创建层次结构
19. 使用 EC2 创建层次结构
20. 更改关机行为
21. 测试故障转移

1. 在 Linux 上启动 2 个 Oracle 实例

在第一篇博客中，我们将使用 SIOS LifeKeeper for Linux 在 AWS 中为 Oracle 集群设置 HA 环境。这意味着排除所有先决条件。 我将在 Oracle Linux 8 AMI 上使用 aws-marketplace/Oracle 数据库 19.8.0 企业版。这些经常变化，很难找到适合您需要的正确的。这个 AMI 是我的第 3 次尝试，因为由于存储库、许可、注册和安全问题，在云中安装任何东西，尤其是 Oracle 之类的东西都非常困难。这个 AMI 实际上可以工作，因为 Oracle 已经安装在映像上。确保操作系统版本和 Oracle DB 版本受 SIOS 支持。可以检查这里.

我的实例有：

21. 单一专有网络
22. 单一区域
23. 每个服务器的不同可用区
24. 用于数据库存储的附加驱动器
25. 2 不同子网中每个实例的网络接口
26. 创建 2 个弹性 IP 地址并为每个服务器附加一个

我将一个额外的磁盘附加到数据库实例，并为冗余通信路径附加一个 NIC。确保两个 NIC 位于不同的子网上。这也意味着您必须手动创建和分配弹性 IP 地址才能连接到实例。

连接到实例并安装附加磁盘。 我正在使用 Putty 和 Xming 连接我的实例。如果使用 Xming，请确保在尝试建立连接之前运行 Xlaunch。

启动实例后，您需要对新磁盘进行分区。最容易找到[ ls /dev/disk/by-path ]:

现在你需要分区磁盘磁盘:

接下来在新分区上创建文件系统mkfs.xfs :

我们现在将挂载文件系统山:

最后，我们将在 fstab 中添加自动挂载磁盘的条目：

请务必注意，您不需要为 Oracle 运行安装。AMI 已经做到了这一点，并为您创建了一个数据库。我删除了使用此 AMI 预先配置的数据库，并使用 DBCA 在 /data 磁盘上创建了一个新数据库。我启动了数据库并创建了一个模式并使用 SQLPLUS 添加了数据。这一切都需要您让 Xwindows 正常工作。

2. 让 Xwindows 工作

可以使用 Xming for Windows 设置使用 Putty 的 Xdisplay。先安装Xming。然后确保开启了X11转发，在x显示位置输入localhost:0.0，在x权限文件中输入路径和xming.exe可执行文件进行本地显示：

这解决了 Windows 方面的问题，但您仍然需要修复 Linux 方面。首先编辑 /etc/ssh/sshd_config 并取消注释“X11Forwarding yes”。接下来是查找正确的密钥并将其添加到 Xauthority。如果您进行了任何用户切换，您可能必须开始一个新会话。以 ec2-user 身份登录后运行xauth列表这将为您提供您需要添加到 Xauthority 文件中的十六进制密钥。切换到oracle用户：苏 – 甲骨文。然后运行xauth 添加 $DISPLAY 。 <从 xauth 列表复制的 hexkey> 。这会将信息存储到 /home/oracle/.Xauthority 文件中。出口回到 ec2-user。

3.连接到实例并挂载额外的磁盘

我正在使用 Putty 和 Xming 连接我的实例。如果使用 Xming，请确保在尝试建立连接之前运行 Xlaunch。

启动实例后，您需要对新磁盘进行分区。最容易找到[ ls /dev/disk/by-path ]:

现在你需要分区磁盘磁盘:

接下来我们在新分区上创建文件系统mkfs.xfs :

此时我们想将 /u01 重命名为 /oracle 目录，以便我们可以将新文件系统挂载到 /u01 上，这是我们使用 AMI 构建的服务器上 Oracle 所在的位置。

使用 mkdir /u01 创建安装点并使用 mount 安装卷。使用 mv /oracle /u01 将文件移动到新磁盘。这将需要一些时间，因为它大约是 11GB 的数据。

最后，我们将在 fstab 中添加自动挂载磁盘的条目：

请务必注意，您不需要为 Oracle 运行安装。AMI 已经做到了这一点，并为您创建了一个数据库。我启动了数据库，创建了一个模式，并使用 SQLPLUS 添加了数据。

4. 安装 AWS cli 工具包

我们需要 awscli 套件；所以，当我们是 root 下载文件时卷曲“https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip”-o“awscliv2.zip”

解压文件解压 awscliv2.zip

安装应用程序须藤./aws/安装

接下来通过单击控制台右上角的帐户在 AWS 中设置访问密钥，然后选择安全凭证

单击创建访问密钥：

然后单击下载 .csv 文件：

将此文件传输到您的服务器上，并使用您的 csv 文件中的密钥 ID 和访问密钥配置 AWS aws配置命令：

测试它是否正在使用类似的东西： aws –no-paginate –no-cli-pager ec2 描述实例

5.配置安全/访问

首先，我将 Oracle 用户添加到 root 和 wheel 组，赋予它伪特权（ Usermod -aG wheel oracle) .这将使 Oracle 帐户成为 lkadmin 帐户，使生活变得轻松。我将 sps.img 和许可证文件下载到两台服务器上。

在安装软件之前，还需要完成一些先决条件步骤。首先为服务器配置安全组，使它们可以通过开放TCP端口5900-59010进行通信。同时打开 TCP 端口 81 和 82。 还要确保端口已为虚拟 IP 打开。

6.为虚拟IP创建路由条目

路由表需要更新才能使集群的虚拟 IP 正常工作。在此多子网集群配置中，虚拟 IP 需要位于分配给您的 VPC 的 CIDR 范围之外。定义一个新路由，将流量定向到集群的虚拟 IP (172.30.0.101) 到主集群节点 (Oracle1) 从 VPC 仪表板中，选择路由表，单击编辑。添加“172.30.0.101/32”的路由，目标是主服务器上的主弹性网络接口 (ENI)：

7. 禁用 ENI 的源/目标检查

在 Network Interfaces 下，一次选择一个接口，然后在 Actions 下选择 change source/dest。

只要您没有收到身份验证错误，就说明它已正确安装和配置。

取消勾选使能够盒子：

对所有接口重复。

8.编辑/etc/hosts

除非您已经设置了 DNS 服务器，否则您需要在两台服务器上创建主机文件条目，以便它们可以正确地按名称相互解析。

9. 使用 VIP 主机名配置监听器

编辑或创建 $ORACLE_HOME/network/admin/listener.ora 文件以指向 oracle-vip：

10. 禁用 SELinux

编辑 /etc/sysconfig/selinux 文件并设置“SELINUX=disabled”

重新启动服务器。如果此时服务器没有恢复，则可能是您将 SELINUX 设置保留为允许并将 SELINUXTYPE 设置为禁用，这将使实例变砖。只需取消 AWS 中的卷与您的实例的关联并将其挂载到mount -o rw, nouuid {设备} {挂载目录}命令到新的或现有的工作实例。编辑/{挂载目录]/etc/sysconfig/selinux文件，修改错误。保存文件，卸载并取消卷与此实例的关联，然后将其重新附加到旧实例。

11. 为 Linux 安装 SIOS 保护套件

接下来，我以 root 身份通过安装映像文件来安装 SIOS 保护套件mount /home/ec2-user/sps.img /mnt/ -t iso9660 -o loop . 运行安装程序/mnt/设置:

在 LifeKeeper 身份验证下，我向下滚动到 lkadmin 组，按回车键并将 oracle 添加到“lkadmin”组：

选择“确定”，然后选择“完成”并按回车键。下一步滚动到安装许可证密钥文件并按回车键：

从这里输入您的许可证文件的位置和名称：

接下来，我选择 Recovery Kit Selection Menu 并按下回车键：

这里我选择网络：

按空格键选择 LifeKeeper Recovery Kit for EC2。 Tab 到 Done 并回车。接下来我选择数据库菜单，向下滚动并在 LifeKeeper Oracle RDBMS 恢复工具包上点击空格键：

Tab 到 Done 或按 D 并向下滚动到 Storage 并按 Enter。接下来我按下空格键并选择 DataKeeper for Linux：

Tab 到 Done 并按回车键或按 d 退出恢复工具包选择，然后按 Tab 键到 Done 或按 D 退出 Main Configuration 菜单：

确保 LifeKeeper Startup After Install 被选中，然后最后一个选项卡完成或点击 d，我们会看到安装确认屏幕：

在这里按 enter 或 y，安装将开始。

12.启动LifeKeeper

使用以下命令启动 LifeKeeper GUI /opt/LifeKeeper/bin/lkGUIapp如果失败，可能是因为您没有登录 .Xauthority 文件的帐户的幻数。我以 oracle 身份登录，然后做了一个须藤-我扎根。因此，如果我的 gui 未加载，我会将 /home/oracle/.Xauthority 文件复制到 /root ：

在这里我以 oracle 身份登录：

13.连接到第二个服务器

然后单击 Cluster Connect 按钮

以 oracle 身份登录：

14.建立沟通渠道

单击“创建通信路径”按钮：

如果出现故障，请确保禁用防火墙和 iptables。下一步：

下一步：

选择您的第一个 IP 地址并点击下一步：

选择远程IP：

下一步：

点击创建：

下一步：

现在点击完成：接下来我们需要通过使用辅助地址重复步骤 14 来创建第二个通信路径。

成功建立两条路径后，服务器应变为绿色。

15. 创建 DataKeeper 资源

单击“创建资源层次结构”按钮：

选择数据复制并点击下一步：

点击下一步（智能意味着在故障转移后您需要手动故障回复）：

下一步：

选择您的主服务器并点击下一步：

选择复制现有文件系统并点击下一步：

选择现有的挂载点并点击下一步：

创建一个数据复制资源标签并点击下一步：

选择一个文件系统资源标签并点击下一步：[1]

为获得最佳性能，位图文件应放置在临时卷上。 出于测试目的，可以将位图放置在 OS 磁盘上，如上所示。 选择位图文件位置并点击下一步：

为启用异步复制选择否，然后单击下一步：

选择目标服务器并点击下一步：

选择 Switchback 类型并点击下一步：

选择模板优先级并点击下一步：

选择目标优先级并点击下一步：

下一步：

选择目标磁盘并点击下一步：

下一步：

下一步：

选择要用于复制的网络端点并点击下一步：

选择挂载点，点击下一步：

选择资源标签并点击下一步：

点击完成：

点击完成：

如果您单击 /u01，您将看到音量同步：

16. 使用虚拟 IP 资源创建层次结构

单击创建资源按钮：

选择IP并点击下一步：

选择 Switchback 类型并点击下一步：

选择主服务器并点击下一步：

输入第 6 步中的虚拟 IP 地址，然后点击下一步：

输入 VIP 的子网掩码并点击下一步：

进入网络界面，点击下一步

输入资源标签并点击下一步：

创建成功后点击下一步：

选择目标服务器并点击下一步：

选择 switchback 类型并点击下一步：

选择优先级并点击下一步：

选择优先级并点击下一步：

完成后点击下一步：

下一步：

选择适当的网络掩码并点击下一步：

选择接口并点击下一步：

选择资源标签并点击扩展：

成功完成后点击完成：

验证后点击完成。

17. 创建 Oracle Listener 资源

在尝试在 LifeKeeper 中配置这些资源之前，请确保数据库和侦听器正在运行。单击创建资源按钮：

选择 Oracle Database Listener 并点击下一步：

选择主服务器并点击下一步：

输入监听器配置文件路径和文件名，然后点击下一步：

下一步：

输入侦听器可执行文件的路径并点击下一步：

选择保护级别并点击下一步：

选择恢复级别并点击下一步：

如果需要，选择与侦听器关联的 IP 地址，然后点击下一步：

输入侦听器标签名称并点击创建：

下一步：

点击接受默认值以在第二台服务器上构建资源：

点击完成：

单击完成并展开 LSNR 和 /u01：

18. 使用 Oracle 数据库创建层次结构

单击“创建资源层次结构”按钮：

选择 Oracle 数据库并点击下一步：

选择 Switchback 类型并点击下一步：

选择服务器并点击下一步：

选择数据库名称并点击下一步（如果出现无法找到主目录的错误，请确保数据库正在运行）：

输入 sysdba 用户名并点击下一步：

输入该帐户的密码，然后点击下一步：

选择 Oracle 监听器并点击下一步：

点击创建：

创建成功后选择下一步：

选择接受默认值：

选择完成：

点击完成：扩展树以查看所有资源：

19. 使用 EC2 创建层次结构

单击“创建资源层次结构”按钮：

选择 Amazon EC2 并点击 Next>

选择智能并点击下一步>

选择您的主服务器并点击 Next>

选择 EC2 资源类型（我们在此示例中使用后端集群）并点击 Next>

选择 IP 资源并选择 Next>

选择 EC2 资源标签名称并点击创建

成功创建资源后，点击 Next> 几秒钟后，预扩展向导将弹出。点击接受默认值：

检查成功完成后，再次点击接受默认值：

点击完成，验证后点击完成：

配置完成。现在我们可以测试故障转移。

20. 改变关机行为

默认情况下，LifeKeeper 不会故障转移如果您只是关闭或重新启动服务器，则资源不足。 如果您想在关闭服务器之前移动工作负载，您应该在关闭活动节点之前手动将资源移动到备用服务器。 但是，您可能希望更改默认行为以方便测试。 这是通过更改关机策略来控制的，如下所示。

右键单击您的主服务器并选择属性：

在 General 选项卡下，将 Shutdown Strategy 更改为 Switchover Resources，然后点击 Apply：

接下来从服务器下拉菜单中选择辅助服务器并验证设置更改：点击确定：

21. 测试故障转移

我正在从辅助服务器运行 lkGUIapp。如果您在主服务器上，退出 LifeKeeper GUI 并从辅助服务器运行它。

展开所有资源层次结构并打开与主服务器的 SSH 会话。

我也在运行 ping -i 5 到 oracle-vip：

关闭主服务器：

在我的案例中，您可以看到 IP 停止响应的时间 < 25 秒。我以 5 秒的间隔错过了 4 次 20-23 次。现在一切都在备份服务器上处于活动状态。因为我们的主节点仍然关闭，所以我们在层次结构上收到警告。

如果您将切回切换为智能，一旦启动主服务器，您将必须手动在主服务器上启动该服务。在尝试将其投入使用之前，请确保主服务器处于 InSync 状态：

右键单击 cdb1 的 StandBy 按钮并选择 In Service…

点击服务

点击完成。

磁盘重新同步需要几分钟时间，但最终会完成。

恢复所有内容后，我们现在在 AWS 中拥有一个可用于开发的高可用性 Oracle 数据库。

经许可转载自信息系统

领先的饮料制造商保护 AWS EC2 云中的关键 SAP ERP

SIOS 基于对 SAP、Amazon Web Services 和 Red Hat Linux 的认证和验证而被选中

一家领先的香港饮料制造商生产 61 个饮料品牌，包括世界第一的软饮料品牌，并向香港、中国大陆、台湾和美国西部的超过 7.28 亿客户分销。

环境

该公司依靠在 Red Hat Linux 环境中运行的 SAP ERP（企业资源规划）系统来管理各种关键业务运营。 SAP 环境包含各种服务，包括 ABAP（高级业务应用程序编程）、SAP 中央服务 (ASCS)、评估收据结算、Web 调度程序和 DB2 数据库。 他们使用大型存储区域网络 (SAN) 进行数据存储。 核心 SAP 应用程序处理公司饮料部门的所有业务运营。 在他们的本地数据中心，该公司使用 SAN 的数据复制和备份为该系统提供正常运行时间保护。

挑战

公司的 IT 部门确定他们可以通过迁移到云并使用故障转移集群来保护他们的关键 SAP 系统，从而实现真正的高可用性（99.99% 的正常运行时间）、灾难恢复、可扩展性和成本节约。 然而，他们意识到传统故障转移集群所需的 SAN 和其他共享存储在某些云中并不实用，在其他云中也不可用。

评估

经过广泛评估后，该公司选择将他们的 SAP 环境迁移到 Amazon EC2。 他们建立了四个关键标准来评估他们对 HA/DR 解决方案的选择。 他们的解决方案需要：

• 获得与 SAP、AWS 和 Red Hat 一起使用的认证和验证
• 提供高可用性和高性能
• 防止所有可能的故障情况
• 实现轻松的持续操作和维护

该公司的云客户经理建议他们考虑通过 AWS 中国提供的 SIOS Protection Suite。 SIOS 软件已通过 SAP 的 NetWeaver 和 DB2 认证，并且 SIOS 在 Red Hat Enterprise 和其他 Linux 发行版上经过了全面测试和支持。 该公司在各种具有挑战性的故障场景下对 SIOS 集群软件进行了广泛测试，并评估了高峰需求期间的吞吐量性能。 IT 团队对 SIOS Protection Suite 的信心增加了，因为它通过了他们的每一项严格测试并被证明非常易于使用。

解决方案

适用于 Linux 的 SIOS Protection Suite 支持 SANless 故障转移集群，为 SAP 及其关键服务提供完整的 HA 和 DR。 SIOS 软件独特地包括称为应用程序恢复套件 (ARK) 的模块，这些模块提供特定于应用程序的功能，可简化配置并确保故障转移编排保持应用程序最佳实践。 SAP 和 HANA ARK 可自动执行配置步骤并验证配置输入并管理 IP 故障转移和启动顺序以最大限度地减少人为错误。 与仅验证服务器可操作性的其他集群软件不同，SIOS 集群软件验证 SAP 和关键服务是否正在运行、数据库是否已安装且可用、任何文件共享或导出是否可用以及客户端是否能够连接。 为确保这些服务都正常运行，SIOS 软件持续监控服务器、虚拟机、操作系统和 SAP 软件的所有主要组件。 为了容灾保护，公司将主备集群节点分布在不同的AWS可用区，实现地域隔离。

结果

SIOS Protection Suite 使这家领先的饮料制造商能够满足为其 SAP/DB2 环境制定的严格恢复时间和恢复点目标。 迄今为止，该配置没有出现明显的停机时间，包括在计划维护期间。 而且这些结果是用最少的努力实现的，使 IT 员工可以更多地关注提高员工生产力或以其他方式改善业务运营的项目。

经许可转载自信息系统