专业术语: SQL Server 群集
定义:每当承载 SQL Server 实例的服务器出现故障时,群集 SQL 服务器都可以提供高可用性和灾难保护。
转载自SIOS
SIOS SANless clusters High-availability Machine Learning monitoring
领先的数字广告代理的 IT 部门需要一种简单、经济高效的方法,为在 AWS EC2 中运行的应用程序提供保护,同时消除警报风暴和不必要的 IT 任务。他们实现了 AppKeeper 和分钟,并看到了应用程序可用性的即时、节省成本的改进。
INFOBAHN集团是INFOBAHN集团(INFOBAHN Group,Inc.)的子公司,是一家总部位于东京的数字广告公司,为客户拥有的媒体提供数字品牌、广告和内容管理。INFOBAHN Group Inc. 的 IT 部门是一个小型部门,为其客户拥有的媒体及其姊妹公司 Mediagene Inc. 提供完整的 Web 服务器管理服务,该公司是主要内容媒体网站的所有者,如"日本 Gizmodo"、"cafeglove"、"生活黑客"(日文版)、"商业信息日本"、"ROOMIE"等。
使用 Amazon Web 服务 (AWS) 的 INFOBAHN 客户中约有 80% 依赖内容管理系统 (CMS) 向读者提供最新内容。由于 INFOBAHN 的客户对这些 CMS 工具的停机时间和严格可用性 SLA 寄予厚望,因此他们将运行在服务器上的服务器的监视和管理外包给托管服务提供商 (MSP)。
对于 INFOBAHN 来说,他们同时满足自己的内部、客户和可用性服务级别协议 (SLA) 非常重要。他们还使用 MSP 监视其某些内部服务器,同时监视其他服务器,这需要自己进行更密切的管理。
"虽然我们可以继续将服务器的监控外包给客户的系统。此模型不适用于我们的内部服务器,因为它不会随着业务规模的扩大而扩展,"INFOBAHN 集团 IT 部门经理 Yu 天野之弥说。INFOBAHN已经每月花费近1,400美元来监控其内部服务器,而他们的内部团队无法自行管理更多的服务器。
天野之弥和他的同事日夜收到故障通知。每个通知都要求天野之弥或其同事放弃所有内容,调查原因并解决问题。
天野之弥认识到他们需要更好的解决方案,因此考虑了 SIOS 技术针对 AWS EC2 的 SIOS AppKeeper 可用性软件。他们测试AppKeeper与他们的WordPress服务器,通过关闭它的Apache服务,并检查AppKeeper通知电子邮件和故障日志,以验证状态和行动由AppKeeper。
"我们多次执行验证测试,包括停止服务,并确认服务按预期启动。我们可以看到 AppKeeper 是可靠的。我们还发现,经过非常简单的配置过程,它提供了自动监控和恢复服务,"天野之弥说。
SIOS AppKeeper 作为软件即服务提供,支持 AWS EC2 服务和实例的自动监控和恢复。它通过 AWS API 监控它们,并快速检测故障并从故障中恢复。
AppKeeper 通过检测并首次重新启动应用程序服务自动还原应用程序操作。此步骤通常在几秒钟内还原服务。如果服务重新启动失败,则重新启动整个实例。它发布故障报告,根据从虚拟机服务和 AWS 恢复之前和之后获得的相关信息显示任何故障发生和恢复。
如果客户选择 EC2 自动缩放功能,他们可以轻松地添加更多实例以进行 AppKeeper 保护。AppKeeper 将自动缩放以近乎实时地监视这些新实例,如果需要,将自动应用指定的设置。
2017 年 3 月初,INFOBAHN 开始使用 SIOS 应用程序保持器监控其内部服务器。"通过在线注册流程提交 AWS 凭据后,我要做的就是选择我希望 AppKeeper 在检测到故障时采取的步骤的设置。只需点击在线用户指南中所述的屏幕即可配置 AppKeeper,只需 10 到 15 分钟,"天野之弥说。
天野之弥说,自从他们开始使用SIOS应用程序保持以来,没有失败,他们无法自动恢复。SIOS 应用程序保持器甚至帮助他们免受人为错误。"有时,其他 IT 成员无意中将活动目录服务器关闭。我收到来自 AppKeeper 的电子邮件通知时,我出去说服务已经恢复。恢复是如此顺利,我甚至没有注意到它,直到我被告知,"天野之弥笑了起来。
INFOBAHN 正在考虑扩大 AppKeeper 的使用范围,以监控其所有内部 AWS 服务器。他们还考虑在未来为客户项目使用 AppKeeper。天野之弥说:"如果我们有SIOS AppKeeper,我们可以在一台带有 AWS 的服务器上安装必要的 CMS,如 WordPress 和可移动类型,并提供附加价值,使服务在发生故障时自动恢复。
SIOS AppKeeper 软件持续监控和保护 AWS EC2 中的应用程序免受服务中断和停机,同时无需昂贵且耗时的手动干预。
欲了解更多信息,https://us.sios.com/products/sios-appkeeper/
注册 SIOS 应用程序保持器的免费试用版
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 和所有主要的操作系统和平台供应商也完全支持该解决方案。
作者:
Jason 胡
IT 专业人员,20 多年来一直专注于高可用性和灾难恢复。目前受雇于SIOS技术公司,担任亚太地区的战略业务发展。
迁移到云不需要涉及对体系结构和应用程序设计的破坏性更改。保持高可用性冗余和对 HA 群集的体系结构更改的成本也不高。
即使 Oracle 从 19c 开始从标准版中删除 RAC 功能,并终止对 12c 的支持,您仍可以通过 SIOS 等第三方 HA 解决方案实现高可用性。无需升级到企业版 Oracle DB 即可节省高达 70% 的成本。
在此 1 小时的在线会话中,了解如何实现上述目标等。这包括为您的组织使用 Oracle 和其他应用程序时的成本节约。所有这些都不影响云中 99.99% 的上山时间要求。
议程
云中的 Oracle DB HA:
节省成本并减少迁移后的停机时间
您的 Oracle 云工作负载
现场网络研讨会 – 2020年4月23日,星期四
SGT 下午 12 点,美国东部时间下午 2 点,PHT 上午 11 点,美国东部时间上午 9:30
使用一些最苛刻的企业在亚太地区,包括 – AGL澳大利亚 • 珀斯体育场 • 交通部和主要道路澳大利亚 • 英格姆斯集团澳大利亚 • 克里斯·奥布莱恩医院 • 韩国教育局 • LG Display Korea • 三菱重工 • NH 银行韩国 • 柬埔寨长野赌场 • 野村研究所 (上海) • 松下亚洲 • Razer 亚太私人有限公司 • 三星韩国 • Zespri 新西兰
演讲者:Jason Aw
持续时间:60分钟
等级:初级
跟踪:应用程序,DBA和数据库开发
首席执行官只是要求您将所有SQL Server实例移至Azure,或者您正在部署一个全新的应用程序,并希望利用Azure IaaS来托管SQL Server。除了安全性和性能之外,您最紧迫的问题可能是确保在Azure中运行的SQL Server具有高可用性。
虽然SQL Server的本地高可用性和灾难恢复选项已经很好地定义,但将这些实例移动到Azure会立即带来一些问题和挑战。我可以简单地将SQL Server故障转移群集实例提升并迁移到云端吗?我是否需要升级到SQL Server企业版和我们的Always On Availability Groups?那么共享存储和故障转移群集呢?那么灾难恢复,我有什么选择?负载均衡器,故障域,可用区,Azure站点恢复和区域对,这些是什么以及为什么它们对我很重要?
具有20年经验的高可用性和灾难恢复专业人员Jason Aw解释了所有这些以及更多细节。
随附材料