高可用性软件可防止SAP停机
我们每个人都需要购买保险-为我们的汽车,房屋,我们的生命。没有人愿意为我们希望永远不必使用的服务付费。但是我们都知道我们应该以防万一。大多数人要么推迟保险,直到不幸的事情发生,要么买最便宜的,或者实际上做功课,然后从他们信任的人那里购买。 最后一组通常表现最好。
SIOS SANless clusters High-availability Machine Learning monitoring
我们每个人都需要购买保险-为我们的汽车,房屋,我们的生命。没有人愿意为我们希望永远不必使用的服务付费。但是我们都知道我们应该以防万一。大多数人要么推迟保险,直到不幸的事情发生,要么买最便宜的,或者实际上做功课,然后从他们信任的人那里购买。 最后一组通常表现最好。
保险通常是针对消费者的,但对企业也至关重要。您拥有运行您的业务的计算机系统和应用程序。 如果它们由于某种原因而失败,则您希望您的业务继续运营,否则可能会因丢失交易和客户数据而蒙受数百万美元的业务损失,并给您在客户中的声誉带来无法弥补的损失。 高可用性软件是您防止系统停机的“保证”。这不是您不能忽略的事情。这不是您可以信任的随硬件或软件基础结构一起提供的东西。您想使用一家拥有数十年高可用性专业知识并且知道如何保持系统正常运行的公司的高可用性解决方案。
当今企业中使用的关键应用程序之一是基于HANA内存数据库的SAP S / 4HANA。 到2025年,大多数SAP客户将被要求在SAP上运行HANA数据库。 您想从一家了解高可用性,了解SAP,了解HANA并了解如何确保您的关键SAP应用程序和业务继续平稳运行的公司中找到智能的HANA可用性解决方案。
SIOS Technology是值得信赖的可靠高可用性软件公司。LifeKeeper for Linux产品的9.5版本包含一个新的HANA应用程序恢复工具包。这将为您提供保持SAP和HANA环境运行所需的一切。 需要有关此版本的更多信息吗?观看这次采访。
经SIOS许可转载
作为提供SIOS客户体验的软件工程师,我经常帮助那些将其内部高可用性群集环境迁移到云的公司。
云迁移是一个过程,而不是目标。当我们吸引客户过渡到云时,通常是在计划过程的后期,这不是理想的选择,但在云迁移中却并非罕见。以下是我们经常看到的六个云迁移挑战。
将您的数据从本地部署到云需要多长时间?根据您的应用程序,数据类型和云提供商的不同,它可能会有很大的不同。一个经常被忽略的细节是将数据从主节点同步到辅助节点,有时甚至同步到灾难恢复(DR)站点所需的时间。不考虑重新同步时间的客户在数据复制时会费时费力。
在云区域内的数据传输是免费的。区域之间的数据传输将产生费用。通常,我们看到的架构中,主节点和辅助节点位于一个区域内的单独云可用性区域中。引入灾难恢复站点时,成本可能会大大增加,因为灾难恢复站点将始终位于另一个区域。SAP NetWeaver等数据丰富的应用程序的灾难恢复可能会抑制跨区域复制的成本。
区域间复制带来了另一个挑战:复制类型。可用区内的异步或同步复制由客户的RTO和RPO要求确定。无论实例大小如何,跨区域之间进行数据复制时都会遇到一些延迟。SIOS建议在区域之间进行异步复制,以减少该延迟的影响。 并发实验室提供了一些有关EC2区域之间的延迟的有见地的信息。
可以从云中部署现成的OS映像。这种便利需要付出一定的代价,这为配置管理引入了另一个因素。SuSE Enterprise Linux映像中包含的针对云进行了优化的cloud-init服务可以删除用户定义的虚拟IP地址。没有什么能像阻止虚拟IP地址每两分钟消失一样阻止PoC了!
云计算的规模提供了比企业在本地数据中心中提供的更高的安全性。云工作负载甚至不知道就利用了尖端的安全性。例如,默认情况下,AWS EC2实例会阻止实例本身未发送或未发送给实例本身的任何流量。这是确保云中网络安全的重要功能。如果系统需要网络地址转换(NAT),则EC2的默认安全措施将导致IP地址失败。从控制台禁用源/目的地检查将解决此问题。根据用户对AWS的熟悉程度,这可能需要几次点击到几次支持电话之间。了解系统如何在环境中进行交互的细节是成功进行云迁移的关键。
需要提醒来自本地系统的客户,资源不再是限制因素。在云中,可以毫不费力地复制系统并在生产环境中隔离运行,这在内部部署中并不简单。按需访问IT资源允许HA和DR的UAT扩展到“关闭主节点”之外。网络可能遭到破坏,内核可能会崩溃,甚至数据库也可能损坏,而这些都不会影响生产!识别和测试这些方案可以改善HA和DR的状态。
执行成功的云迁移需要所有利益相关者的投入。高可用性和灾难恢复是任何企业工作负载的核心方面。无论SIOS已经是您当前系统的一部分,还是将来云迁移的一部分,请让我们参与其中!
-哈里森·豪威尔(Harrison Howell),客户体验软件工程师
经SIOS许可转载
我们很自豪地宣布推出适用于Linux 9.5版的SIOS保护套件。该产品引入了先进的自动化和可感知应用程序的监视功能,使其成为业界最全面的现成的SAP S / 4HANA集群软件。
我们知道尝试手动构建SAP S / 4HANA集群很麻烦,以确保所有HANA服务都将故障转移到正确的位置并以正确的顺序启动。数小时的脚本编写,测试和处理工作。赌注很高。弄错了,可能意味着故障转移不会发生或变得更糟–停机时间,数据丢失,大量加急的用户通话。
因此,我们为使用HANA系统复制(HSR)的两节点SAP S / 4HANA数据库配置添加了智能应用程序可用性。我们构建此版本的目的是消除构建和管理集群的麻烦和风险。
从简单的,向导驱动的配置开始,该配置实际上会验证您的输入。无需花费大量时间进行手动脚本编写…或在出现问题时查找错误的按键。
它监视从应用程序到硬件,服务器和网络的HANA堆栈中的所有进程-不仅检查服务器是否像其他集群软件一样可操作。
与其他触发所有故障转移的群集解决方案不同,如果SIOS Protection Suite检测到问题,它会自动采取适当的恢复操作–无论是只是重新启动服务,在使用中的节点上进行恢复还是将故障转移编排到辅助节点上节点。
说到故障转移编排,它将自动确保始终保留特定于SAP的最佳实践。例如,它可以确保在故障转移或切换时,ASCS永远不会位于具有主应用程序的服务器上或与ERS处于同一服务器上。
如果向导驱动的配置还不容易,我们还添加了新的命令行界面(CLI)克隆功能,通过导入CLI进行配置,您就可以部署SIOS集群。您还可以导出现有集群的CLI指令以创建其克隆。
现在,借助适用于Linux的SIOS Protection Suite,您可以快速轻松地创建高可用性群集,以保护任何应用程序。其中包括停机和灾难造成的SQL Server,Oracle,SAP和S / 4HANA。
经SIOS许可转载
NGINX是一个Web服务器,还可以充当负载平衡器,反向代理等。它们之间,NGINX和Apache一起提供了超过50%的网络流量。 如今,许多公司正在使用Amazon Linux,Red Hat Linux和Ubuntu在Amazon EC2环境上运行其NGINX开源或NGINX Plus Web服务器。
每个人都同意,最佳做法是监视EC2上的NGINX之类的应用程序,并快速响应任何系统异常情况。 用户期望其应用程序能够快速访问并保持正常运行时间。
许多公司正在部署Amazon CloudWatch来监视其应用程序,甚至通过开发脚本或使用AWS Lambda来创建某种程度的自动化。 但是,使用自定义指标正确配置Amazon CloudWatch并设置Amazon Lambda需要一定数量的技术专长,而这可能超出了许多公司。 然后,随着应用程序的发展,维护任何脚本都需要付出成本和精力。
另一种选择是部署应用程序性能监视(APM)解决方案,例如New Relic,Dynatrace,Datadog或LogicMonitor中的一种。 APM解决方案很棒。 他们在监视您的所有系统以及查明发生的情况和原因方面做得非常好。 他们创建可以与您的开发团队共享并由您的开发团队解释的日志,以重新创建问题并确保不再发生。 但是事情是这样的:APM解决方案提供了许多您必须分类的数据(将“信号与噪音分离''),并且它们在故障发生时无法恢复。 在减少NGINX Web服务器的停机时间时,APM工具只是解决方案的一部分。
但是有些公司没有内部人员或工具来自己监控EC2环境。这就是为什么他们选择将任务外包给托管服务提供商的原因。 与MSP一起管理环境有一些非常实际的好处,例如,随着环境的扩展而不必雇用更多的员工,或者不必对团队进行新技术培训。 MSP可以提高投资效率,因为它们可以将其投资分散到许多客户。 但是有缺点。 在某些情况下,您可能会陷入高额的固定成本合同,并且如果遇到问题并且必须逐步解决这些问题,成本可能会上升。 而且,您将失去监视环境的团队与负责构建和部署应用程序的团队之间的连续性。
无论您是选择投资APM解决方案还是将其外包给MSP,您都仍然需要考虑在发生故障时以及从故障停机时恢复NGINX Web服务器的速度。 我们想提出另一种选择:使用SOIS AppKeeper进行自动修复。
我们的许多客户都选择使用SIOS AppKeeper来保护其NGINX Web服务器。 尽管他们可以选择标准的应用程序性能监视(APM)解决方案或第三方监视解决方案,但他们选择依靠AppKeeper来自动恢复服务或发生故障的整个EC2实例。 我们将看一下其中的一些原因,并与您分享一个简短的视频,展示AppKeeper如何与NGINX一起使用。
SIOS AppKeeper是一项SaaS服务,易于安装和配置并监视在Amazon EC2上运行的任何应用程序,例如NGINX Web服务器及其“ nginx”,“缓存管理器”和“工作程序”服务。 当检测到异常时,AppKeeper会自动重新启动服务,如果该操作不起作用,它将重新启动整个实例。 无需再仔细阅读痛苦的日志以查明失败的原因,或升级到开发人员以重新启动服务或昂贵的外包费用。 AppKeeper提供了“设置并忘记”功能,因此您可以放心知道NGINX Web服务器正在遵循EC2监视最佳实践并且运行正常,或者如果遇到任何问题将很快重启。
如今,数百家公司依靠AppKeeper来保持其云环境正常运行。 我们邀请您观看此快速视频,以演示AppKeeper如何保护NGINX Web服务器。
如果您想亲自尝试SIOS AppKeeper,我们提供14天的免费试用期。 只需单击此处进行注册。
随着AWS在云市场中占据主导地位,许多公司正在使用Amazon AWS将其本地系统迁移到云中。 那么,应该如何管理在AWS环境中运行的系统?
在此博客文章中,我们将介绍AWS提供的监视服务Amazon CloudWatch的功能,以及实现它的挑战以及如何解决它们。
为了确保您拥有稳定的云环境,快速检测异常(“系统损害”)并及时做出响应非常重要。 对于任何迁移到云的组织而言,监视已成为一项重要且必要的任务。 这与管理本地应用程序和基础结构没有什么不同。那么,您应该如何在AWS环境中进行监控?一种选择是使用Amazon CloudWatch,它监视CPU,内存和磁盘使用情况,并在超过预定阈值时通知您。 另外,您可以设置自己的指标来监视各种项目,例如应用程序日志。
关于Amazon CloudWatch的最好之处在于,它是AWS本身提供的一项服务。 它与Amazon EC2和其他AWS服务具有很高的亲和力,因此它可以快速响应频繁的功能扩展和规范更改,并可以轻松支持AWS Auto Scaling,后者会根据负载自动增加或减少资源。 Amazon CloudWatch可根据每种环境的独特情况提供精确的监控。
尽管Amazon CloudWatch非常适合拥有经验丰富的云工程师和DevOps团队的组织,但一般用户应该注意一些事项。
Amazon CloudWatch可有效监视组织的AWS环境,但它需要一定水平的技能和知识来配置和部署。 尤其是当您设置自己的指标,设置警报或考虑到Auto Scaling时,复杂性会增加。 例如,如果要设置监视,这很容易,但是如果要设置电子邮件,重新启动,自动缩放等,则可能会遇到困难,具体取决于资源情况。
如果您要使用“发生错误时重新启动服务器”之类的指示来自动化恢复过程,则必须首先使用AWS Lambda脚本创建恢复方案,该脚本提供了有关条件和要采取的措施的详细说明。 您的团队对AWS Lambda有多熟悉?
Amazon CloudWatch的主要优点是您可以密切监视您的环境,但是要做到这一点,您必须事先为每个系统正确设计要监视的项目以及何时监视阈值等。 这些设计任务可能会花费很多时间。 当然,您的关键任务系统需要以这种方式进行严密监视,但是这种详细程度和复杂程度并不适合所有系统。对于某些网站,例如内部网站或WordPress服务器,您将希望最大程度地降低运营和人工成本。在这种情况下,我们建议您考虑使用一种更易于操作和管理的工具。
对于非关键任务应用,我们建议使用SIOS Technology的SIOS AppKeeper。 AppKeeper易于安装和配置,并可监视在EC2实例上运行的应用程序的服务(进程)。 当检测到错误时,AppKeeper会自动重新启动服务,并在必要时重新启动实例。 即使是初次迁移到云的用户也可以设置AppKeeper来监视其EC2实例并自动恢复,而无需具备复杂的脚本编写技能。
使用AppKeeper,无需选择要监视的单个服务。您只需选择要监视的EC2实例以及要自动执行的操作即可。 您始终可以更详细地了解要监视哪些服务以及如何监视这些服务,但是AppKeeper旨在易于配置。 当检测到错误或从中自动恢复错误时,会记录并存储故障日志,以便以后可以调查故障原因。
建议您不要根据Amazon SLA和恢复要求清点环境清单,而要使用SIOS AppKeeper监视您想减少运营开销的系统和应用程序,而不是使用Amazon CloudWatch来密切监视AWS环境中的所有内容。
请继续关注未来的博客文章,我们将更详细地比较如何设置CloudWatch和AppKeeper以执行相同的功能。