灾难：活着！ SQL Server 从灾难到运营

发生了什么SQL Server 灾难? 这是您参与行动的机会。

该网络研讨会将指导您完成一些 SQL Server 模拟灾难。 通过 DR 计划和清单离开此网络研讨会，以确保您的业务运营在发生中断时按预期运行。

白皮书：高可用性解决方案为 Oracle 提供成本节约和灵活性

迁移 Oracle 数据库可能是一项艰巨的任务。 这个过程通常很复杂，而且成本很高。 然而，有时迁移是不可避免的。 当支持和许可考虑一起使迁移成为必要时，尤其如此。 在迁移业务关键型数据库时，提供高可用性保护以防止停机很重要，因为停机会导致收入和生产力损失。 Oracle 已宣布即将结束对 Oracle Database 12c 的支持。 因此，运行 Oracle Database 12c 的组织将面临迫在眉睫的迁移需求。

下载白皮书：高可用性解决方案为 Oracle 提供成本节约和灵活性

白皮书：了解关键业务应用程序高可用性的复杂性

在当今竞争激烈、永远在线的全球经济中，对于现代企业来说，停机时间变得比以往任何时候都更加昂贵。 除了损失生产力和收入之外，当组织的关键业务系统、数据库和应用程序无法提供可靠和卓越的客户体验时，他们还面临失去客户的风险。 SIOS 的这份技术简报解释了在关键业务应用程序中实现高可用性的复杂性。

下载白皮书：了解关键业务应用程序高可用性的复杂性

介绍适用于 SIOS LifeKeeper 和 Google Cloud 的通用负载平衡器套件

这将讨论通用负载均衡器应用程序恢复工具包(ARK) 适用于 SIOS Lifekeeper for Linux，特别是如何在 Google Cloud 上配置它。 SIOS ARK 是 SIOS LifeKeeper 产品的插件，可增加平台或应用程序感知。

本博客展示了如何使用双节点 NFS 集群以及它们提供的 NFS 导出最终可以通过负载均衡器访问。

SIOS 创建了这个 ARK 来促进 SIOS LifeKeeper 中的客户端重定向在 GCP 中运行的集群.

由于 GCP 不支持免费 ARP（对路由器自己的 IP 地址的广播请求），因此客户端无法直接连接到传统的集群虚拟 IP 地址。 相反，客户端必须连接到负载均衡器，负载均衡器将流量重定向到活动集群节点。 GCP 实现了在第 4 层 TCP、第 4 层 UDP 或第 7 层 HTTP/HTTPs 上运行的单独负载平衡器解决方案，负载平衡器可以配置为具有私有或公共前端 IP，这是一个健康探测，可以确定哪个节点处于活动状态，一系列后端 IP 地址（针对集群中的每个节点）和传入/传出网络流量规则。

传统上，健康探测将监视应用程序上的活动端口并确定该应用程序在哪个节点上处于活动状态，SIOS 通用负载平衡器 ARK 配置为让活动节点侦听用户定义的端口。 然后在 GCP 负载均衡器中将此端口配置为运行状况探测端口。 这允许活动集群节点响应 TCP 健康检查探测，从而启用自动客户端重定向。

GCP 中的安装和配置简单明了，详细如下：

在 GCP 门户中，选择负载平衡在这种情况下，我们需要 TCP 负载平衡 创建一个负载平衡器，您将选择要部署它的资源组以及名称，我喜欢使用与我的集群类型一致的名称将负载平衡器与例如 IMA-NFS-LB 一起使用将位于两个 IMA-NFS 节点的前面。

您可以确定这将是面向 Internet 还是在您的 VPC 内部。 在这种情况下，我将配置一个仅用于内部的负载平衡器来放置在我的 NFS 服务器前面，以便仅在我的 VPC 中使用。

一旦您确定了名称、区域等，您将被要求分配一个后端配置，这将需要一个包含您将作为前端的 HA 节点的实例组。

一旦您分配了一个实例组，您将定义一个运行状况检查 – 这是与您将在 Lifekeeper 通用负载均衡器配置中使用的端口匹配的端口，在这种情况下我使用的是 54321。同样，请注意端口号，因为这将与 Lifekeeper 一起使用。

我只是坚持使用健康标准的默认值。

为负载均衡器输入后端配置信息和运行状况检查后，您将需要定义前端配置。 这包括您要为负载均衡器创建的子网、区域和 IP。

您将配置您的 IP，这将匹配您正在保护的 Lifekeeper IP。

一旦您对配置感到满意，您可以查看它或直接单击创建。

一旦我们选择“创建”，GCP 将开始部署负载均衡器，这可能需要几分钟，一旦完成，配置就会转到 SIOS 保护套件。

使用 SIOS 保护套件进行配置

在本博客中，我配置了三个 NFS 导出以使用 SPS-L 进行保护，这三个导出配置为使用与 GCP 负载均衡器的前端 IP 相同的 IP。 我在用着数据管理员复制存储在导出上的数据。

第一步是获取脚本，最简单的方法是使用 wget，但您也可以下载整个包并使用 winscp 或类似工具将 rpm 直接上传到节点。 您需要在 Lifekeeper 集群的所有节点上安装 Hotfix。

完整的恢复套件可在此处获得： http://ftp.us.sios.com/pickup/LifeKeeper_Linux_Core_en_9.5.1/patches/Gen-LB-PL-7172-9.5.1可以使用 wget 在这里找到这些部分： wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm.md5sum wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/Gen-LB-readme.txt下载后，根据 FTP 站点上记录的值验证 MD5 总和。

按如下方式安装 RPM： rpm -ivh steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm通过运行检查安装是否成功： rpm -qa | grep steeleye-lkHOTFIX-Gen-LB-PL-7172如果您出于某种原因需要删除 RPM，可以通过运行以下命令来完成： rpm -e steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64 下面是显示我已经配置的三个 NFS 导出的 GUI：我们需要在SIOS 保护套件使用 SIOS 提供的 Hotfix 脚本定义负载均衡器。

首先我们创建一个新的资源层次结构，我们从下拉列表中选择 Generic Application定义位于 /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/ 中的 restore.pl 脚本定义位于 /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/ 中的 remove.pl 脚本定义位于 /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/ 中的 quickCheck 脚本没有本地恢复脚本，因此请确保清除此输入当询问应用程序信息时，我们希望输入与在 Healthcheck 端口中配置的端口号相同的端口号，例如 54321我们将选择在服务创建后将其投入使用Resource Tag 是我们将在 SPS-L GUI 中看到的名称，我喜欢使用易于识别的名称如果一切配置正确，您将看到“结束成功还原”，然后我们可以将其扩展到另一个节点，以便资源可以托管在任一节点上。

这显示了扩展至两个节点后完成的负载均衡器配置该集群的最后一步是为三个 NFS 导出创建子依赖项，这意味着所有带有 Datakeeper 镜像和 IP 的 NFS 导出都将依赖于负载均衡器。 如果活动节点上出现严重问题，那么所有这些资源都将故障转移到其他正常运行的节点。

上图是 Lifekeeper GUI 中完整的层次结构。 下面显示了扩展的 GUI 视图，显示 NFS 导出、IP、文件系统和 DataKeeper 复制卷作为负载均衡器资源的子级。

这只是如何在 GCP 中使用 SIOS LifeKeeper 保护简单 NFS 集群的一个示例。 同样的概念适用于您需要保护的任何关键业务应用程序。 您只需利用 SIOS 提供的负载均衡器 ARK 来允许 GCP 负载均衡器（互联网或内部）确定当前托管应用程序的节点。

如何减少 SAP 的停机时间

想着怎么做减少 SAP 的停机时间是在初始解决方案设计期间应该访问的一个重要主题。 可以对现有的 SAP 环境进行更改，但在现有的生产环境中，这些可能会更加棘手，停机时间会成为问题。

SAP 环境中有几个典型的组件可以被视为单点故障； ASCS（中央服务）、HANA DB、NFS 节点和 SAP 应用程序服务器。 理想情况下，应该通过在高可用性配置中使用冗余服务器来保护这些。

SAP 的 HA/DR 目标

为 SAP 设计高可用性/灾难恢复组件时的核心目标应该是：

● 最大限度地减少停机时间 ● 消除数据丢失 ● 保持数据完整性 ● 支持灵活配置 在当今的现代云环境中，底层硬件的基础架构通常通过使用多个冗余 NIC、冗余存储和硬件可用区得到很好的保护，避免出现故障——然而，这仍然没有'不保证您的 SAP 应用程序将运行并响应请求。

用一个高可用性SIOS 保护套件等解决方案引入了智能高可用性以及本地磁盘复制，以确保您的 SAP 应用程序和服务受到持续监控和保护，并能够在检测到故障时自动切换到冗余硬件。

现在让我们考虑一个不受 HA 保护的 SAP 配置的简单示例，它可能看起来像这样（图 1）：如果此环境用于处理来自用于向客户销售服装的 Web 服务器的交易，那么 SAP 将用于处理销售、跟踪订单、跟踪库存并基于这些交易提供多个自动订购等。

现在让我们假设这个销售处理环境（如上图）是在没有 HA 的情况下在云中配置的，因为架构师认为云环境中的高度冗余硬件足以防止故障。如果该 HANA 数据库遇到问题并关闭，让我们看看使数据库恢复正常运行所需的典型步骤： ● 即使HANA 配置了HANA 系统复制，故障转移到辅助HANA 数据库系统也不会自动进行。 这将需要知道 HANA 的人在检测到故障并通知他们中断后进行纠正。
● 来自网络服务器的实时交易将暂停，直到问题得到解决 如果这家小型服装零售商每年通过网络销售进行约 1000 万美元的交易，这相当于全年平均销售额约为每小时 1150 美元。 高峰时间每小时会花费更多。

IBM 的这份报告表明每小时的平均停机成本为 1 万美元图 2：具有 HA/DR 的 SAP 环境如果 HA 软件一直在使用中（图 2），HANA DB 故障转移将是自动的，并且 Web 服务器的中断将在配置的超时范围内，并且绝对不会有任何销售损失。 将生成警报，并且可以比系统停机情况更轻松地查看和诊断原因。

扩大客户规模，很可能任何系统停机情况都会开始花费数十万美元并消耗大量人力资源来解决。

其他IBM 报告表明惊人的 44% 的受访者每两个月进行一次计划外停机，另有 35% 的受访者每月进行一次计划外停机。

计划中断本身是另一个潜在问题，46% 的受访者报告每月计划中断，另有 29% 报告年度计划中断。 让应用程序和服务受 HA 软件保护还可以通过允许在维护活动期间将服务转移到正在运行的系统来缓解这些计划内的中断。

学习更多关于SAP 和 S/4HANA 的高可用性.