| 四月 28, 2020 |
适用于 S/4HANA 和其他 SAP 平台的高可用性和 DR
SAP 是企业应用软件的市场领导者。多年来，SAP 帮助各种规模和所有行业的公司高效运营，多年来建立了依赖于其平台的企业生态系统。事实证明，全球 77% 的交易收入涉及 SAP 系统。 SAP 应用程序涉及公司的许多关键部分，例如其 ERP、制造、业务流程、客户服务等。它已成为许多企业赖以经营才能正常运行的生命线。因此，高可用性已成为公司管理层在其 SAP 系统方面最关心的问题之一。 在本文中，我们将在高级别上讨论什么是 HANA 系统复制、它的工作原理、在高可用性方面有哪些限制，以及我们如何克服这些限制。我们还将讨论 HANA 高可用性选项以及主要区别是什么，以便您可以为正确的工作选择正确的工具。 为了选择适合 HA 的解决方案，您可能需要在一天结束时问自己一些关键问题：
—— SAP 可以关闭多长时间才能恢复？
——恢复服务时数据可能有多旧
——你需要多少时间？ SAP HANA 系统复制 SAP HANA 系统复制是一种可靠的数据保护和灾难恢复解决方案，可提供 HANA 数据库与同一数据中心、远程站点或云中的辅助位置的连续同步。 系统复制是软件附带的标准 SAP HANA 功能。使用此功能，所有数据都会复制到辅助站点，数据会预加载到辅助站点上的内存中，从而显著缩短恢复时间目标 （RTO）。因此，在故障转移的情况下，辅助站点将能够接管，甚至无需执行 HANA DB （重新）启动，并在故障转移时立即作为主数据库工作。但是，故障转移必须由使用sr_takeover命令的管理员手动触发，并且要反转复制，或者故障回主，还需要发出单独的命令。  以下是 HA 和 DR 的 HANA 系统复制方法的一些要点：
限制
现在您可能从上述点推断出，HANA 系统复制旨在防止数据丢失。因此，当主节点出现问题时，管理员可以手动运行”sr_takeover”命令，以便主系统的问题不会关闭整个 SAP 设置，该设置依赖于 HANA 数据库的长期停机时间。然而，许多这项工作必须手动进行，并且依赖于人工干预，虽然对 DR 足够好，但它并不能为 HA（需要防止停机）提供理想的情况。 SIOS 高可用性群集 SIOS 面向 SAP 的高可用性软件可让您在物理、虚拟、云（公共、私有和混合）和高性能闪存环境的任何配置（或组合）中保护 SAP S/4HANA。SIOS 软件提供简单灵活的配置、快速复制以及对整个 SAP S/4HANA 环境的全面监控和保护。 专门用于 SAP S/4HANA 和 HANA 数据库。SIOS 可用于补充 SAP 已经在使用 HANA 系统复制（添加到其上）执行的操作，以提供真正的高可用性 – 自动监视关键 HANA 应用程序进程，并提供自动故障转移、故障恢复（包括虚拟 IP），即使您在单个 HANA 节点中具有多实例也是如此。  以下是 SAP HANA HA 和 DR SIOS 保护套件的一些要点：
为 HANA 数据库安装和配置 HA 的四个步骤 我们不会讨论如何配置 SAP HANA 的具体步骤，因为已经有许多在线资源涵盖这些步骤。但在高级别上，您需要执行 4 个基本步骤：
安装过程流与其他 SAP 组件（ASCS、ERS、PAS、Web 调度程序等）也类似。 使用 SIOS 保护套件软件中包含的 HANA 恢复工具包，您基本上可以使用 SIOS Lifekeeper 管理 GUI 中的向导，快速保护 HANA 数据库实例，为客户端分配虚拟 IP 地址以进行连接到它，并管理整个堆栈。您可以拥有多实例环境，解决方案将管理所有实例、虚拟 IP 等。在完全集成的 GUI 中，它非常容易配置、管理 SIOS HA 上的整个 SAP 环境。  用于 SAP 的全面 HA/DR 堆栈 – 除了 HANA 数据库之外，SIOS 保护套件还为关键的 SAP 服务和支持应用程序提供保护，所有这些服务都可以从同一 GUI 进行管理：
云中群集 将 SAP 迁移到云时，关键挑战之一是如何保护 SAP 数据库以及 SAP 应用程序堆栈在 SAP 支持的体系结构中。SIOS 一直是这一举措的前沿，由 SAP 以及所有主要云提供商设计、认证和支持。 下图是一个高级设计，用于了解如何跨不同可用性区域甚至区域部署一对 S/4HANA 系统。在云环境中，由于提供商在 AZ 之间的延迟非常低，因此完全可以在 AZ 中使用同步复制，从而创建一对高度可用的 S/4HANA 系统，不仅针对 HA，还用于 DR。这是因为 AZ 在地理上是独立的数据中心，这与本地 DR 数据中心的本地化程度非常类似，即它们之间的高度冗余高速网络连接。  为什么要使用 SIOS 于 SAP 而不是开源的 HA？ 这个问题总是会出现在人们的脑海里，因为一些Linux供应商已经提供了他们的HA扩展（HAE）或集群，为什么有人想要使用商业第三方HA解决方案，如SIOS？
总结 SAP HANA 系统复制功能作为软件的一部分，在硬件或系统故障出现问题时，可很好地保护数据库免受数据丢失的影响。但是，如果要求高可用性，它仍然需要第三方解决方案，以获得一些自动监视、故障转移业务流程、虚拟 IP 等。虽然 SAP 的企业 Linux OS 订阅形式有开源选项，但它们肯定不是免费的，并且技术支持仍然有限，因为它们完全依靠开源社区来维护起搏器、Corosync 等。项目。并获得贡献者的支持。本机系统复制（开源 HAE）也有限制，可以由像 SIOS 这样的商业软件解决方案供应商克服。 因此，SIOS 作为可靠的第三方高可用性解决方案提供商，可帮助确保企业客户获得其关键任务 SAP 系统操作所需的可靠性和高可用性，让您高枕无忧，从而证明自己是 SAP HANA 系统复制的非常可行的补充解决方案，SAP 和所有主要的操作系统和平台供应商也完全支持该解决方案。 作者：
|
| 四月 26, 2020 |
东洋高世有限公司 将 SAP 企业系统迁移到 Azure东洋高世有限公司 将 SAP 企业系统迁移到 Azure：通过复制构建"永不停止的系统"
东洋高赛是一家历史悠久的化工制造商，已经经营了65年。公司的主要产品是光刻的感光材料，是制造液晶显示器和半导体集成电路不可或缺的材料。公司还专注于最先进的感光材料的技术开发。 2007年，公司被要求选择GLOVIA/流程C1的后续系统，该系统曾被用作核心业务系统。在收到多家公司的建议时，他们选择引入"SAP"，这是德国SAP公司的ERP系统，因为它的J-SOX支持非常可靠。时间已经过去，大约在 2015 年左右，引入 SAP 时安装的服务器已结束维护。
|
| 四月 22, 2020 |
SIOS 高可用性解决方案及其优势 |
| 四月 18, 2020 |
网络研讨会：Oracle 数据库云中高可用性 |
| 四月 7, 2020 |
使用 SIOS 应用程序保持器管理 AWS EC2 的警报压力使用 SIOS 应用程序保持器管理 AWS EC2 的警报压力
随着公司迁移到云，不得不管理更复杂的计算环境，这种"警报压力"开始对工人的生产力和心理健康造成影响。云监控解决方案正在尝试为您提供更多信息，以便您可以更快地解决问题，但它们提供的信息的深度和警报量可能非常庞大。 AWS 的应用程序性能管理是否足够？迁移到 AWS 云基础架构意味着您通常必须采用新的方法来管理和监视应用程序。您可以利用 AWS 的本机云管理功能为您的 EC2 环境服务。但是，许多公司迅速扩展了这些工具的功能，并部署了商业应用程序性能管理 （APM） 解决方案，以扩大覆盖范围和更深入的见解。 但事情是这样的。这些复杂的 APM 解决方案可以为您创造更多工作。 是的，它们通常附带警报通知工作流，以便快速将正确的信息交到正确的人员手中。 但是，在没有人工干预的情况下，他们很少去解决问题。结果：许多压力诱导警报需要您立即关注。 这就是我们创建 SIOS 应用程序保持器的原因。 这是业界首款自动响应 Amazon EC2 实例上服务中断的解决方案。AppKeeper 允许公司保护应用程序免受服务中断和停机，同时无需昂贵且耗时的手动干预。 AppKeeper 自动重新启动 AWS EC2 中的失败服务SIOS 应用程序保持器不仅标识并发送故障通知。但是，如有必要，它也会自动尝试重新启动失败的服务或重新启动实例。我们的用户发现 AppKeeper 会自动解决几乎 85% 的应用程序服务故障。 不用打扰你，你的I. 或开发团队或第三方。 自 2017 年以来，日本 SIOS 客户和合作伙伴一直在使用 SIOS AppKeeper 来保护其 AWS 环境。ForgeVision 是 AWS 高级咨询合作伙伴，将 AppKeeper 集成到其云管理控制台中。它一直允许它以更经济经济的价格监控和恢复客户的故障。AppKeeper允许东京的出版公司HobbyJapan创造一个免维护、低成本的环境。 我们邀请您通过观看此简短视频或注册使用 AppKeeper 免费了解 SIOS AppKeeper，直到 6 月 30 日。 然后，您可以亲自了解 AWS EC2 中系统故障自动解决的情况。 • 西冈大久，SIOS 应用程序保管人业务发展经理。
|
系统代表小林明彦（Akihiko Kobayashi）表示："我们提出了多项本地和云提案，并决定根据富士通提出的SIOS数据保持器方案迁移到微软 Azure，这最适合我们的要求。
IT 基础设施
你发生过这种事吗？当您外出时，您会收到有关应用程序问题的警报，而您没有解决问题所需的信息？您是否需要从不方便的位置访问云管理控制台，或者将信息传递给其他同事以进行寻址？或者，您正在调查另一个警报时需要您注意？研究表明，一般人需要23分钟才能从意外的中断中恢复过来。