确保访问关键教育应用程序

确保访问关键教育应用程序

教育和信息技术 (IT) 越来越密不可分。所讨论的 IT 是否是支持课堂白板的应用程序、支持大学注册系统的数据库、学习管理系统 (LMS)，还是控制学生进入实验室、宿舍和餐厅的建筑维护系统（如果是关键组件）如果您的 IT 基础设施突然陷入瘫痪，教师、管理员和学生都无法完成他们应该完成的任务。该机构的使命被中断。如果中断太频繁，如果学生、教师和管理人员的经历受到影响，机构本身的声誉也会受到影响。

IT 基础设施旨在确保对教育体验至关重要的应用程序的高可用性 (HA)，可以最大限度地降低由于任何原因这些系统变得无响应时可能发生的中断和声誉损失的风险。在这种情况下，HA 基础设施被定义为能够确保关键应用程序在不低于 99.99% 的时间内可用性的基础设施。换句话说，这意味着您的关键应用程序每月不会意外离线超过四分钟。

如何实现 HA？这个问题很容易回答，但这并不是您需要问的唯一问题。同样重要的是：哪些应用程序非常重要以至于需要 HA 配置？从本质上讲，为 HA 配置的 IT 基础架构具有一组或多组辅助服务器和存储子系统，这些服务器和存储子系统位于不同的地理位置（如果您的主服务器驻留在本地或单独的可用性中，则可以是远程数据中心）区域 [AZ]（如果您的服务器驻留在云中）。如果某些原因导致主服务器上运行的应用程序停止响应，管理应用程序的 HA 软件会立即将应用程序故障转移到辅助服务器，您的关键应用程序将从主服务器停止响应的位置再次启动。根据您计划复制的主服务器的大小和性能特征，辅助服务器可能会很昂贵，因此您不太可能为 HA 配置所有学术应用程序。一旦确定哪些应用程序值得对 HA 进行投资，您就会知道需要在哪里构建 HA 环境。

实现高可用性的选择

一旦您选择了要保护的应用程序，您实现 HA 的选项就会变得更加清晰。它们在 Windows 还是 Linux 上运行？您的数据库管理系统 (DBMS) 是否内置对 HA 配置的支持？如果是这样，它的局限性是什么？例如，如果您的关键应用程序在 Windows 和 SQL Server 上运行，您可以使用 SQL Server 本身的可用性组 (AG) 功能来启用 HA。或者，您可以使用第三方 SANless 群集工具来配置 HA，该工具提供 SQL Server 中的 AG 服务不提供的选项。如果您试图保护来自多个供应商的数据库服务器，或者如果您的某些关键应用程序在 Windows 上运行而其他应用程序在 Linux 上运行，则使用支持多个 DBMS 和操作系统的 HA 解决方案将有助于您管理 HA 的能力平台。与同时处理多个数据库本机 HA 服务的潜在复杂性和繁琐相比，选择适应不同 DBMS 和操作系统平台的集群解决方案可以简化管理。

通过数据库本机 HA 解决方案确保高可用性

如果您使用数据库本机 HA 解决方案（例如 SQL Server 的 AG 功能），该软件会将主 SQL Server 数据库中的所有数据同步复制到辅助系统服务器上该数据库的相同实例。如果某些原因导致主服务器停止响应，AG 组件中的监控功能将自动导致辅助服务器接管。由于AG功能实时复制了所有数据，因此辅助服务器可以立即接管，几乎不会出现服务中断或数据丢失的情况。

许多数据库本机 HA 工具都以类似的方式运行。不过，在考虑数据库本机方法时，有一些注意事项：如果将 HA 服务捆绑到 DBMS 本身中，它们可能只复制与该 DBMS 关联的数据。如果其他关键数据驻留在主服务器上，则在数据库本机 HA 场景中，这些数据不会复制到辅助服务器。数据库本机服务复制的内容可能还存在其他限制。例如，如果您使用捆绑到 SQL Server 标准版中的基本 AG 功能，则每个 AG 只能将单个 SQL 数据库复制到单个辅助位置。如果您的应用程序涉及多个 SQL 数据库，您可以创建多个基本 AG，但您无法控制在故障转移情况下每个 AG 是否同时进行故障转移，否则可能会出现问题。解决此限制的一种方法是使用捆绑到 SQL Server Enterprise Edition 中的 Always On AG 功能，该功能可以将多个 SQL 数据库复制到多个辅助服务器，但如果您的应用程序不这样做，从许可角度来看，这可能会变得非常昂贵否则，请使用 SQL Server Enterprise Edition 的任何功能。

其他数据库本机 HA 解决方案可能有类似的限制，因此在投资这种方法之前一定要了解它们。

通过 SANless 集群确保高可用性

作为数据库本机 HA 方法的替代方法，您可以使用第三方工具创建 SANless 集群。正如上述 AG 配置一样，SANless 集群软件自动将数据从主服务器同步复制到辅助服务器；如果主服务器无响应，它还会安排立即故障转移到辅助服务器。由于故障转移只需几秒钟，管理员、教师和学生对关键应用程序的访问几乎不会中断。

SANless 集群和数据库本机方法之间的关键区别在于实际细节。SANless 集群方法与数据库无关。它复制指定存储卷上的任何数据。这可能包括来自多个供应商的多个数据库、文本文件、视频文件或任何其他可用性很重要的教育资产。如果数据库本机 HA 方法需要升级到更昂贵的数据库版本，这可以为机构节省大量资金。最后，如前所述，如果您试图保护在多个操作环境中运行的应用程序和数据，SANless 集群方法可能比单个数据库本机方法更易于管理。您可以使用 SANless 集群来确保 Windows 或 Linux 环境中的高可用性，这可以消除因操作环境而异的数据库本机方法部署所带来的复杂性。

经许可转载安全操作系统

网络研讨会：云中的灾难恢复：了解 SQL Server 的挑战和策略

网络研讨会：云中的灾难恢复：了解 SQL Server 的挑战和策略

注册参加点播网络研讨会

确保云中的高可用性 (HA) 和灾难恢复 (DR) 对于许多组织来说可能是一个挑战。与云中 HA/DR 相关的挑战包括利用不同云供应商的各种工具的复杂性、数据主权考虑、合规性挑战以及持续的成本管理。

本次网络研讨会将讨论应对这些挑战的方法，强调冗余和故障转移对于不间断服务和数据保护的重要性，并探讨有关云弹性的常见误解以及强大的备份和灾难恢复策略的必要性。

经许可转载安全操作系统

使用 SIOS LifeKeeper 在 AWS 中通过 HANA 3 节点 HSR 集群构建高可用性

使用 SIOS LifeKeeper 在 AWS 中通过 HANA 3 节点 HSR 集群构建高可用性

简介：如何确保数据库的 HA 和 DR

在 AWS 中创建高度可用的 SAP HANA 环境是许多企业的一项关键任务。本指南提供了使用以下命令设置 3 节点 HANA 系统复制 (HSR) 集群的详细演练：SIOS 生命守护者在AWS中，确保数据库弹力和高可用性。

先决条件

• 能够部署 EC2 实例的 AWS 帐户。
• SIOS LifeKeeper 软件
• SIOS LifeKeeper 评估或永久许可证
• SAP HANA 软件
• 熟悉 AWS 服务和 SAP HANA。

步骤 1：准备您的 AWS 环境

EC2实例部署

在 AWS 中部署三个 EC2 实例。这些实例将充当 HANA 集群的主节点、辅助节点和第三节点。确保它们满足 SAP HANA 和 SIOS LifeKeeper 的硬件和软件要求。确保在构建实例时遵循 SAP HANA 大小调整指南。

网络配置

配置您的 VPC、子网和安全组，以允许节点之间进行通信并允许访问必要的服务。

在不同区域配置 HANA 节点时，您可以使用 SIOS LifeKeeper for Linux Route53 应用程序恢复套件或 ARK 保护 DNS 名称。以下是 AWS 中 3 节点 HANA 数据库的架构：

设置存储时，请为 /usr/sap、/hana/data、/hana/log 和 /hana/shared 使用单独的 EBS 卷。

我们有 2 个 VPC，每个区域一个。我们需要在 VPC 之间设置对等互连，并将路由添加到路由表中，以确保服务器可以相互通信。我们还需要修改安全组以允许服务器之间的流量。

最后，我们需要创建一个包含两个 VPC 的托管区域，并添加用于与活动 HANA 节点通信的域和主机名的记录。

步骤 2：安装和配置 SAP HANA

每个节点上的安装

在每个 EC2 实例上安装 SAP HANA。确保所有节点的版本一致，以避免兼容性问题。这是迄今为止最具挑战性的过程。

首先确定您的安装设置。对于我来说，我使用以下内容：

SID：D11

• HANA实例数量：11
• Route53 中的 HANA 数据库 FQDN：saphana.sapdemo
• Node1 主机名：sapdemohana1
• 节点2主机名：sapdemohana2
• Node3 主机名：sapdemohana3
• 实例类型：r5.4xlarge

本地实例存储：

• 30GB /（根卷）
• 15GB/usr/sap
• 60GB /hana/共享*
• 200GB /hana/数据
• 200GB /hana/日志

*对于此安装，这些 HANA 数据库服务器之间未共享存储。如果您尝试使用共享存储，您将无法创建相同的服务器，因为 hdblcm 将阻止安装并出现有关 SID 和实例已存在的错误。

在每个节点上独立安装 HANA 服务器软件，就好像它是一个独立系统一样。确保安装了所有必需的库，对于 RHEL 8，它们位于 SAP note 2772999 中。您需要确保在安装 compact-sap-c++-9-9.1.1-2.3.el7_6.x86_64.rpm 后创建符号链接通过运行： ln -s /opt/rh/SAP/lib64/compat-sap-++-10.so /usr/sap/lib/libstdc++.so.6

• yum install xorg-x11-server-Xorg xorg-x11-xauth -y #for LifeKeeper GUI
• yum 安装 nfs-utils

创建分区、格式化存储并附加它。创建您的交换文件。

我在所有主机上创建 RSA 密钥，然后通过将公钥添加到 .ssh/authorized_keys 文件来允许 root ssh 在 hana 节点之间登录。这将使安装变得更加容易。

装载 HANA 安装介质卷。

• yum localinstall compat-sap-c++-10-10.2.1-11.el7_9.x86_64.rpm
• yum localinstall compat-sap-c++-9-9.1.1-2.3.el7_6.x86_64.rpm
• mkdir /usr/sap/lib
• ln -s /opt/rh/SAP/lib64/compat-sap-++-10.so /usr/sap/lib/libstdc++.so.6
• 百胜安装 compat-sap-c++-10 libatomic -y

从正确的 hana 安装介质目录运行 hdblcm。在所有节点上成功安装 HANA 后，您就可以开始下一步了。

系统复制设置

您需要在启用 HSR 之前进行备份：

• su – <SID>adm [即。苏-d11adm]
• hdbsql -i <实例编号>adm -u system -p <密码> [即。hdbsql -i 11 -u系统-p“密码123”]
• 使用文件备份数据(‘/usr/sap/<SID>/HDB<实例编号>’) [即。使用文件备份数据(‘/usr/sap/D11/HDB11’)

在所有节点上重复上述备份过程。

在每个节点上配置 HANA 系统复制：

在主 HANA 系统上启动 HDB 实例（如果尚未运行）： sapcontrol -nr <实例编号> -function StartSystem HDB [即：sapcontrol -nr 11 -function StartSystem HDB]

在主站点启动 HSR： hdbnsutil -sr_enable –name=<主站点名称> [即。hdbnsutil -sr_enable –name=sapdemohana1

停止辅助 HANA 系统上的 HDB 实例： sapcontrol -nr <实例编号> -function StopSystem HDB [即。sapcontrol -nr 11 -function StopSystem HDB]

在其他 HANA 系统中，备份 KEY 和 DAT 文件并将主 KEY 和 DAT 文件复制到所需位置：

• mv /usr/sap/<SID>/SYS/global/security/rsecssfs/data/SSFS_<SID>.DAT /usr/sap/<SID>/SYS/global/security/rsecssfs/data/SSFS_<SID>。 DAT.BAK [即。mv /usr/sap/D11/SYS/global/security/rsecssfs/data/SSFS_D11.DAT /usr/sap/D11/SYS/global/security/rsecssfs/data/SSFS_D11.DAT.BAK]

• mv /usr/sap/<SID>/SYS/global/security/rsecssfs/key/SSFS_<SID>.KEY /usr/sap/<SID>/SYS/global/security/rsecssfs/key/SSFS_<SID>. KEY.BAK [即。mv /usr/sap/D11/SYS/global/security/rsecssfs/key/SSFS_D11.KEY /usr/sap/D11/SYS/global/security/rsecssfs/key/SSFS_D11.KEY.BAK]

• scp root@<主节点>:/usr/sap/<SID>/SYS/global/security/rsecssfs/data/SSFS_<SID>.DAT /usr/sap/<SID>/SYS/global/security/rsecssfs/数据/SSFS_<SID>.DAT [即。scp root@sapdemohana1:/usr/sap/D11/SYS/global/security/rsecssfs/data/SSFS_D11.DAT /usr/sap/D11/SYS/global/security/rsecssfs/data/SSFS_D11.DAT]

• scp root@<主节点>:/usr/sap/<SID>/SYS/global/security/rsecssfs/key/SSFS_<SID>.KEY /usr/sap/<SID>/SYS/global/security/rsecssfs/ key/SSFS_<SID>.KEY [即。scp root@sapdemohana1:/usr/sap/D11/SYS/global/security/rsecssfs/key/SSFS_D11.KEY /usr/sap/D11/SYS/global/security/rsecssfs/key/SSFS_D11.KEY]

确保密钥和 dat 文件的所有者是 <SID>adm sapsys：

• [root@sapdemohana2 ~]# ls -l /usr/sap/D11/SYS/global/security/rsecssfs/data/
• 总计 12
• -rw-r–r– 1 d11adm sapsys 2960 年 1 月 3 日 22:19 SSFS_D11.DAT
• -rw-r–r– 1 d11adm sapsys 2960 年 1 月 3 日 22:15 SSFS_D11.DAT.BAK

将附加 HANA 系统注册到主 HANA 系统 – 必须以管理员用户身份完成：

• hdbnsutil -sr_register –name=<辅助 HSR 名称> –remoteHost=<SAP HANA 系统的主主机名> –remoteInstance=<远程实例编号> –operationMode=<delta_datashipping | 日志重放 | logreplay_readaccess> –replicationMode=<同步 | 同步内存 | 异步>

[IE。hdbnsutil -sr_register –name=sapdemohana2 –remoteHost=sapdemohana1 –remoteInstance=11 –operationMode=logreplay –replicationMode=sync]

检查所有系统上的 HSR 状态，以管理员用户身份运行以下命令： d11adm@sapdemohana4:/usr/sap/D11/HDB11>hdbnsutil -sr_state

一旦所有系统都在线，您就可以进入下一步。

步骤 3：安装 SIOS LifeKeeper

AWS CLI 安装

安装 AWS CLI 并使用具有以下权限的密钥对其进行配置：

路由表（后端）配置：

• ec2:描述路由表
• ec2:替换路由
• ec2:描述网络接口属性
• ec2:修改网络接口属性
• 弹性IP（前端）配置：
• ec2:描述地址
• ec2:关联地址
• ec2:解除关联地址

LifeKeeper安装

在每个节点上安装 SIOS LifeKeeper。这涉及运行安装脚本并遵循安装向导，该向导将指导您完成必要的步骤。对于此安装，我使用网络、Route53 ARK 和数据库、SAP HANA ARK 以及见证功能。

编辑 /etc/selinux/config 文件并禁用 selinux：

我还更改了主机名并编辑了 /etc/hosts 文件。最后编辑 /etc/default/LifeKeeper 文件并将 /usr/local/bin 添加到 PATH 中：

更改 NOBCASTPING=1：

我还将 QUORUM_LOSS_ACTION 更改为 osu：

确保 Xwindows 可以工作。我从 .bashrc 中删除 cp 别名，并将 /opt/LifeKeeper/bin 和 /usr/local/bin 添加到我的 .bash_profile 中，并将 ec2-users .Xauthority 文件复制到 root 和 <SID>adm 主目录，以便 Xwindows将工作：

我更改 root 密码并重新启动。在启动 LifeKeeper GUI 之前。确保 HSR 在所有节点上都在线并且所有节点都已注册：

配置

启动 LifeKeeper GUI：lkGUIapp 并使用 root 用户和密码登录：

单击连接按钮登录集群中的其他节点：

登录到所有节点后，单击“创建通信路径”按钮：

当它要求本地服务器时点击下一步，然后按住 Shift 并选择所有节点：

点击“接受默认值”并在完成后点击“完成”。再次单击“创建通信路径”按钮，这次更改为第二个节点：

点击下一步并选择第三个节点：

单击“下一步”按钮，直到您可以单击“接受默认值”按钮。当完成击中完成。现在单击“创建资源层次结构”按钮：

选择 IP 套件并点击下一步：

点击下一步，直到到达 IP 资源页面。这里输入 0.0.0.0 并点击下一步：

点击下一步，直到到达“创建”按钮。点击创建按钮：

完成后点击下一步：点击接受默认值，目标服务器显示第二个节点：

完成后点击下一个服务器：

点击“接受默认值”，显示第三个节点，完成后点击“完成”：

命中完成：

现在我们有了一个 IP 资源，我们可以添加 Route53 资源，这将更改 dns 条目以将 FQDN 解析为活动节点 IP 地址。在这种情况下，saphana.sapdemo 将解析为 sapdemohana1 的 IP 地址 (172.31.0.25)。点击“创建资源层次结构”按钮开始该过程：

选择 Route53 并点击下一步：

继续点击下一步，直到到达域名。它应该预先填充活动托管区域名称。点击下一步。

输入所有内容将用于连接到 HANA 数据库的主机名，然后点击下一步：

点击下一步，直到到达创建按钮，然后单击创建按钮。完成后点击下一步：

在预扩展向导中点击接受默认值：

完成后点击下一个服务器：

目标服务器将显示第三个节点。点击接受默认值：

完成后点击“完成”。然后点击“完成”。然后您可以展开树。打开与第二个节点的终端会话并 ping HANA 数据库的 FQDN [即。ping -c3 saphana.sapdemo]

右键单击 sapdemohana3 下的顶部 Standby，然后选择 In Service：

在下一个屏幕上点击“服务中”，然后在完成后点击“完成”：

转到终端窗口并重复 ping 测试：

您可以看到主机名现在解析为 sapdemohana3。在继续下一步之前，将 sapdemohana1 重新投入使用。

步骤 4：将 SAP HANA 与 SIOS LifeKeeper 集成

资源层次结构创建

使用 LifeKeeper GUI，在每个节点上为 SAP HANA 创建资源层次结构。此设置对于管理故障转移和恢复过程至关重要。确保 HSR 在节点 1 上处于活动状态并且其他节点已注册：

单击创建资源按钮：

选择 SAP HANA 恢复工具包并点击下一步，直到到达 IP 地址屏幕：

选择无并点击下一步：

点击下一步，直到到达“创建”屏幕并点击“创建”：

创建后点击下一步，然后接受节点2的默认值：

当node2完成后，再次点击“Next Server”并接受默认值：

完成后点击“完成”，然后点击“完成”：

右键单击 Hana Hierarchy 并选择 Create Dependency：

对于子资源标签，从下拉列表中选择route53资源，然后点击下一步：

单击创建依赖项：

单击“完成”。然后选择查看展开树：

如果一切都是绿色的，我们就准备测试了。

第 5 步：测试和验证

故障转移/切换测试

进行彻底的故障切换测试，确保在主节点发生故障时系统能够正确切换到辅助或第三节点。此测试应包括网络故障、硬件问题和软件崩溃等场景。

我们将执行的第一个测试是切换，用于执行维护活动或计划停机。右键单击第二个节点并选择 In Service – Takeover with Handshake…

点击执行接管：

此测试将切换到第二个节点，以最大限度地减少用户的停机时间。当第二个节点启动并运行时点击完成：

一段时间后，节点 1 将恢复待机状态 – 同步。

现在我们可以执行故障转移测试。打开节点 2 的终端并输入 echo c > /proc/sysrq-trigger 以模拟系统崩溃。您将看到节点 1 接管，因为它具有最高优先级 1：

最终，一切都会恢复正常：

您可能希望测试许多其他类型的故障场景。只需在开始测试之前确保备用节点同步即可。

数据同步验证

验证数据是否在所有节点之间正确复制。节点间数据的一致性对于 HSR 设置的完整性至关重要。

性能监控

定期监控 SAP HANA 实例和 LifeKeeper 设置的性能。检查是否存在任何可能表明潜在问题的异常或问题。检查 /var/log/lifekeeper.log 文件以确保一切都按预期执行。您可能需要根据网络性能调整心跳定时器和心跳丢失次数。这些可以在 /etc/default/LifeKeeper 文件中配置。可调参数为 LCMHBEATTIME 和 LCMNUMHBEATS。您还可以使用命令 lcdstatus -q 从命令行检查 Lifekeeper 的状态。

结论

使用 SIOS LifeKeeper 在 AWS 中设置 3 节点 HANA HSR 集群涉及详细的规划和执行。通过仔细遵循这些步骤，您可以在云中建立强大、有弹性且高度可用的 SAP HANA 环境，确保您的关键数据保持可访问且安全。适用于 Linux 的 SIOS LifeKeeper 使 SAP HANA 的管理、监控和维护变得快速、轻松。

SIOS提供资源和训练对于我们所有的产品。

经许可转载安全操作系统

美国国家首都地区利用 SIOS DataKeeper 保护关键紧急调度服务

美国国家首都地区利用 SIOS DataKeeper 保护关键紧急调度服务

SIOS DataKeeper 保护 Azure SQL Server 上的关键 CAD-EX CAD2CAD 软件

直到最近，调度员还使用计算机辅助调度 (CAD) 系统来推测邻近辖区单位的可能位置和可用性，但要请求调度，他们必须通过专用电话线致电邻近机构，以验证单位的实际位置和可用性。此过程减慢了响应时间，并且无法让急救人员访问调度机构可能提供的关键事件详细信息。

为了提高效率，NCR 机构领导层和新兴数字概念 (EDC) 合作创建了数据交换中心 (DEH)，这是一个数据交换和功能互操作性平台，旨在为 NCR 紧急服务机构成员提供对数据和应用程序的安全访问。他们使用国家信息交换模型 (NIEM) 来确保系统、通信和程序的互操作性。

DEH已成为全国应急响应高效区域合作的典范。确保国家首都地区高效的紧急调度服务 SIOS DataKeeper 保护 Azure 中 SQL Server 上的关键 CAD-EX CAD2CAD 软件。

主要的 DEH 信息交换是 CAD 到 CAD (C2C) 交换，它使所有 NCR DEH 机构的调度员能够立即了解前线资源位置、资源可用性，并共享相关事件的最新信息。所有 C2C Exchange 连接成员辖区的 CAD 系统。

NCR DEH C2C Exchange 使用在 Windows 服务器上运行的 Microsoft SQL Server 数据库，并部署在 Azure 商业云中。鉴于这些系统的关键性，DEH 要求为 C2C 交换平台提供高可用性数据保护。 故障转移集群而不增加复杂性 在涉及数据库的传统 Windows 高可用性 (HA) 环境中，配置了两个或多个数据库实例节点。具有共享存储（通常是 SAN）的 Windows Server 故障转移群集。

数据库在主节点上运行，HA 故障转移软件监控其运行情况。如果检测到问题，HA 软件会协调数据库操作的故障转移到集群中的备用辅助节点。在云和其他共享存储不可用且经济高效的环境中，复制用于通过同步每个集群节点上的本地存储来创建 SANless 集群，以便在发生故障转移时，辅助节点可以继续运行使用当前数据进行操作。

在项目的早期阶段，NCR IT 团队已在多个环境中部署了 C2C Exchange 平台。这包括费尔法克斯县本地数据中心，以及随后在多个第三方、国家和本地托管提供商环境中的数据中心。在这些环境中，C2C Exchange 数据库部署体系结构使用 Microsoft SQL Server Enterprise Edition 和 Always On 可用性组。

随着项目的扩展，NCR IT 团队积极利用先进的云技术，将 C2C 平台部署到 Azure 商业云。云提供了在更加虚拟的环境中管理 C2C 平台所需的灵活性和服务级别。

Azure 云还允许 NCR 部署更具成本效益、高可用性的数据库集群解决方案，以自信地交付 C2C Exchange 应用程序数据，同时降低与 SQL Server Enterprise Edition 相关的较高许可成本。

解决方案

NCR DEH C2C Exchange 开始使用 SIOS DataKeeper Cluster Edition 软件创建 SANless 集群，以保护其 C2C Exchange 数据在 Azure 商业云中的可用性。该软件在两节点主动-被动 Windows Server 故障转移群集配置上运行，利用 SQL Server 标准版和 Always On 故障转移群集。

SIOS DataKeeper 软件使用带宽高效、基于主机的块级复制来同步所有数据库集群节点上的本地存储。如果检测到应用程序可用性问题，操作会自动转移到辅助节点，无需手动干预。云供应商保证的服务水平确保硬件可操作性，但不包括与软件和网络相关的应用程序停机原因。

结果

NCR DEH C2C Exchange 已在 Azure 商业云中使用 SIOS DataKeeper 集群版软件两年多了。参与互操作性计划的人数有所增加。除了最初的成员​​外，该计划现在还包括华盛顿都会机场管理局 (MWAA)、弗吉尼亚州的劳登县和威廉王子县，以及马里兰州的蒙哥马利县和乔治王子县。C2C 交易所管理着数千个共享单元，每年在这些参与者之间共享数十万起事件的数据。

使用 SIOS DataKeeper Cluster Edition 在云中建立高可用性数据库集群既快速又简单。EDC 首席技术官兼联合创始人 Greg Crider 表示：“我们只需将 SIOS DataKeeper 安装到 Windows Server 故障转移群集节点，将本地节点存储配置为 SIOS 托管存储以进行复制，并且它可以无缝运行。” “SIOS DataKeeper 集群软件的另一个好处是，它使我们能够通过按需转换集群节点来对数据库执行定期、滚动的软件维护，而无需计划内停机或服务中断。”

自从在 NCR C2C Exchange 中实施 SIOS DataKeeper 以来，没有出现涉及数据库的停机问题或节点之间的数据丢失问题。EDC 总裁、首席执行官兼联合创始人 Chris Wiseman 补充道：“虽然出现了一些意想不到的、无法控制的网络问题，但数据库很快就发生了故障，C2C 交换操作仍在继续，最终用户没有受到服务长期减少的影响。SIOS DataKeeper 软件使我们能够提供更高级别的数据保护和交付，而无需更昂贵的 SQL Server Enterprise Edition 许可。这为我们的利益相关者每年持续节省大量资金。”

DHS/SAFECOM 在视频链接中介绍了具有 SIOS DataKeeper 保护的 NCR C2C 交换。最近，银行、公寓楼和疗养院同时发生三起大火，这一点受到了考验。CAD 系统之间的互操作性在确保快速、高效地响应这些事件方面发挥了关键作用。

EDC 正在通过其商用 NG-CAD-X C2C Exchange 产品在美国其他市场扩大 C2C Exchange 的采用。这种功能先进的 C2C 产品正在由丹佛市中北部全灾区和佛罗里达州东南部地区实施。NG-CAD-X 与 NCR C2C Exchange 消息兼容，部署在 Azure 政府云中，以实现除消防和 EMS ESF 之外的 CJIS 合规性和执法采用，并且还将 SIOS DataKeeper Cluster Edition 实施到其所有数据库架构中上面强调的操作和成本效益原因。“战略合作伙伴关系在为我们的客户提供市场上最佳技术解决方案方面发挥着重要作用。SIOS DataKeeper 是我们系统不可或缺的一部分，并且是有价值的 EDC 合作伙伴。” EDC 副总裁 Kevin Konczal 说道。

下载pdf

经许可转载安全操作系统

网络研讨会：保护 Azure 上的 SAP 和 SAP S/4HANA：灾难恢复最佳实践

网络研讨会：保护 Azure 上的 SAP 和 SAP S/4HANA：灾难恢复最佳实践

在当今的数字环境中，保护 SAP 和 SAP S/4HANA 等关键业务应用程序的安全对于防范可能影响业务连续性的潜在灾难至关重要。Azure 利用云计算的强大功能，为 SAP 和 SAP S/4HANA 环境提供强大的灾难恢复解决方案。此点播研讨会讨论了保护 Azure 上的 SAP 和 SAP S/4HANA 系统的最佳实践，包括以下策略：数据复制、备份和恢复、高可用性和故障转移。SAP on Azure 云的 Microsoft Fast Track 高级客户工程师 Harikrishna Madathala 分享见解、实用技巧和实际示例，帮助实施灾难恢复最佳实践，以保护 Azure 上的 SAP 和 SAP S/4HANA 部署，确保最高水平关键业务应用程序的安全性、弹性和可用性。

经许可转载安全操作系统