SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

适用于Linux 9.5版的SIOS保护套件就在这里！

by Leave a Comment

适用于Linux 9.5版的SIOS保护套件就在这里！

我们很自豪地宣布推出适用于Linux 9.5版的SIOS保护套件。该产品引入了先进的自动化和可感知应用程序的监视功能，使其成为业界最全面的现成的SAP S / 4HANA集群软件。

我们知道尝试手动构建SAP S / 4HANA集群很麻烦，以确保所有HANA服务都将故障转移到正确的位置并以正确的顺序启动。数小时的脚本编写，测试和处理工作。赌注很高。弄错了，可能意味着故障转移不会发生或变得更糟–停机时间，数据丢失，大量加急的用户通话。

因此，我们为使用HANA系统复制（HSR）的两节点SAP S / 4HANA数据库配置添加了智能应用程序可用性。我们构建此版本的目的是消除构建和管理集群的麻烦和风险。

SIOS Protection Suite v9.5可以自动化和监视

从简单的，向导驱动的配置开始，该配置实际上会验证您的输入。无需花费大量时间进行手动脚本编写…或在出现问题时查找错误的按键。

它监视从应用程序到硬件，服务器和网络的HANA堆栈中的所有进程-不仅检查服务器是否像其他集群软件一样可操作。

与其他触发所有故障转移的群集解决方案不同，如果SIOS Protection Suite检测到问题，它会自动采取适当的恢复操作–无论是只是重新启动服务，在使用中的节点上进行恢复还是将故障转移编排到辅助节点上节点。

说到故障转移编排，它将自动确保始终保留特定于SAP的最佳实践。例如，它可以确保在故障转移或切换时，ASCS永远不会位于具有主应用程序的服务器上或与ERS处于同一服务器上。

如果向导驱动的配置还不容易，我们还添加了新的命令行界面（CLI）克隆功能，通过导入CLI进行配置，您就可以部署SIOS集群。您还可以导出现有集群的CLI指令以创建其克隆。

现在，借助适用于Linux的SIOS Protection Suite，您可以快速轻松地创建高可用性群集，以保护任何应用程序。其中包括停机和灾难造成的SQL Server，Oracle，SAP和S / 4HANA。

要求免费试用

经SIOS许可转载

EC2监控最佳实践：使用SIOS AppKeeper保护Amazon EC2上的NGINX Web服务器

by Leave a Comment

NGINX是一个Web服务器，还可以充当负载平衡器，反向代理等。它们之间，NGINX和Apache一起提供了超过50％的网络流量。  如今，许多公司正在使用Amazon Linux，Red Hat Linux和Ubuntu在Amazon EC2环境上运行其NGINX开源或NGINX Plus Web服务器。

每个人都同意，最佳做法是监视EC2上的NGINX之类的应用程序，并快速响应任何系统异常情况。  用户期望其应用程序能够快速访问并保持正常运行时间。

在Amazon EC2上监视NGINX Web服务器的当前选择

许多公司正在部署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：EC2上NGINX Web服务器的自动修复

我们的许多客户都选择使用SIOS AppKeeper来保护其NGINX Web服务器。  尽管他们可以选择标准的应用程序性能监视（APM）解决方案或第三方监视解决方案，但他们选择依靠AppKeeper来自动恢复服务或发生故障的整个EC2实例。  我们将看一下其中的一些原因，并与您分享一个简短的视频，展示AppKeeper如何与NGINX一起使用。

SIOS AppKeeper是一项SaaS服务，易于安装和配置并监视在Amazon EC2上运行的任何应用程序，例如NGINX Web服务器及其“ nginx”，“缓存管理器”和“工作程序”服务。  当检测到异常时，AppKeeper会自动重新启动服务，如果该操作不起作用，它将重新启动整个实例。  无需再仔细阅读痛苦的日志以查明失败的原因，或升级到开发人员以重新启动服务或昂贵的外包费用。  AppKeeper提供了“设置并忘记”功能，因此您可以放心知道NGINX Web服务器正在遵循EC2监视最佳实践并且运行正常，或者如果遇到任何问题将很快重启。

Wistia视频缩略图

如今，数百家公司依靠AppKeeper来保持其云环境正常运行。  我们邀请您观看此快速视频，以演示AppKeeper如何保护NGINX Web服务器。

如果您想亲自尝试SIOS AppKeeper，我们提供14天的免费试用期。  只需单击此处进行注册。

什么是Amazon CloudWatch？

by Leave a Comment

什么是Amazon CloudWatch

 

什么是Amazon CloudWatch？

您可以使用CloudWatch做什么以及需要考虑的一些障碍

随着AWS在云市场中占据主导地位，许多公司正在使用Amazon AWS将其本地系统迁移到云中。  那么，应该如何管理在AWS环境中运行的系统？

在此博客文章中，我们将介绍AWS提供的监视服务Amazon CloudWatch的功能，以及实现它的挑战以及如何解决它们。

使用Amazon CloudWatch密切监视您的AWS环境

为了确保您拥有稳定的云环境，快速检测异常（“系统损害”）并及时做出响应非常重要。  对于任何迁移到云的组织而言，监视已成为一项重要且必要的任务。  这与管理本地应用程序和基础结构没有什么不同。那么，您应该如何在AWS环境中进行监控？一种选择是使用Amazon CloudWatch，它监视CPU，内存和磁盘使用情况，并在超过预定阈值时通知您。  另外，您可以设置自己的指标来监视各种项目，例如应用程序日志。

关于Amazon CloudWatch的最好之处在于，它是AWS本身提供的一项服务。  它与Amazon EC2和其他AWS服务具有很高的亲和力，因此它可以快速响应频繁的功能扩展和规范更改，并可以轻松支持AWS Auto Scaling，后者会根据负载自动增加或减少资源。  Amazon CloudWatch可根据每种环境的独特情况提供精确的监控。

Amazon CloudWatch实施挑战

尽管Amazon CloudWatch非常适合拥有经验丰富的云工程师和DevOps团队的组织，但一般用户应该注意一些事项。

Amazon CloudWatch可有效监视组织的AWS环境，但它需要一定水平的技能和知识来配置和部署。  尤其是当您设置自己的指标，设置警报或考虑到Auto Scaling时，复杂性会增加。 例如，如果要设置监视，这很容易，但是如果要设置电子邮件，重新启动，自动缩放等，则可能会遇到困难，具体取决于资源情况。

如果您要使用“发生错误时重新启动服务器”之类的指示来自动化恢复过程，则必须首先使用AWS Lambda脚本创建恢复方案，该脚本提供了有关条件和要采取的措施的详细说明。  您的团队对AWS Lambda有多熟悉？

Amazon CloudWatch的主要优点是您可以密切监视您的环境，但是要做到这一点，您必须事先为每个系统正确设计要监视的项目以及何时监视阈值等。  这些设计任务可能会花费很多时间。  当然，您的关键任务系统需要以这种方式进行严密监视，但是这种详细程度和复杂程度并不适合所有系统。对于某些网站，例如内部网站或WordPress服务器，您将希望最大程度地降低运营和人工成本。在这种情况下，我们建议您考虑使用一种更易于操作和管理的工具。

SIOS AppKeeper，用于监视在AWS上运行的操作系统和应用程序服务

对于非关键任务应用，我们建议使用SIOS Technology的SIOS AppKeeper。  AppKeeper易于安装和配置，并可监视在EC2实例上运行的应用程序的服务（进程）。  当检测到错误时，AppKeeper会自动重新启动服务，并在必要时重新启动实例。  即使是初次迁移到云的用户也可以设置AppKeeper来监视其EC2实例并自动恢复，而无需具备复杂的脚本编写技能。

使用AppKeeper，无需选择要监视的单个服务。您只需选择要监视的EC2实例以及要自动执行的操作即可。  您始终可以更详细地了解要监视哪些服务以及如何监视这些服务，但是AppKeeper旨在易于配置。  当检测到错误或从中自动恢复错误时，会记录并存储故障日志，以便以后可以调查故障原因。

使用AppKeeper进行AWS EC2监控

建议您不要根据Amazon SLA和恢复要求清点环境清单，而要使用SIOS AppKeeper监视您想减少运营开销的系统和应用程序，而不是使用Amazon CloudWatch来密切监视AWS环境中的所有内容。

请继续关注未来的博客文章，我们将更详细地比较如何设置CloudWatch和AppKeeper以执行相同的功能。

了解有关SIOS AppKeeper的更多信息

注册免费试用SIOS AppKeeper

 

测试/质量保证系统是企业可用性的关键部分

by Leave a Comment

测试/质量保证系统是企业可用性的关键部分

测试/质量保证系统是企业可用性的关键部分

“我可以吻你，”这就是三十年前一个朋友向我冲来时对我脱口而出的意思。在前往我们地区最大的乐队比赛之一的途中，她已将簧片放到萨克斯管上。我不知道它们是谁，但是当我看到一堆芦苇在公交车上的座位上时，我把它们捡起来，带他们去了暖身区。热身三分钟后，她的第一个簧片破裂了，当她伸手去拿空口袋进行替换时，她惊慌失措。当我找到我发现它们的管道时，她脱口而出：“我现在可以吻你。”

担任SIOS Technology Corp.客户体验副总裁 在可用性频谱的不同阶段，我与许多企业客户和合作伙伴一起工作感到非常独特和独特。有时，我有机会与最终客户一起解决问题，缓解问题和进行改进。在其他时候，我们的团队会与合作伙伴和客户积极合作，以设计和实现企业可用性，以保护其系统免于停机。最近的一次客户体验使我想起了大约30年前发生的一件事情，当时我的朋友脱口而出：“我可以吻你。”

我和我的团队正在打客户电话。通话从平时的欢愉，介绍和对客户企业环境的概述开始。通话30分钟后，一切进展顺利。他们的体系结构扎实，周到并且有据可查。他们的团队知识渊博，技术精湛，经验丰富。但是随后，客户暗示，由于节省了成本，他们将不打算维护专用的测试/质量系统。我深吸了一口气。  实际上，这更像是呼气，就像是从肠子上冲来的空气一样。我准备做出回应，但在此之前，我的声音就爆发了。  “停机的首要原因是缺乏流程，”合作伙伴代表架构师在与我们的电话中惊呼道。经过短暂的开玩笑，客户同意维护测试/ QA系统，我差点脱口而出：“我可以亲你！”

在许多企业部署的前线（新系统，数据中心迁移和系统更新）中，我在支持和服务部门的团队已经看到许多问题，这些问题可以通过利用测试系统/群集来解决。

测试/质量系统是避免停机的HA策略的重要组成部分。与维护企业部署相关的常见任务（例如补丁，更新和配置更改）存在风险。巨大的风险。

通常在生产中进行测试的风险包括几个严重的潜在灾难性问题： 

  • 数据损坏或无效
  • 受保护的数据泄漏
  • 错误的收入确认（取消的订单等）
  • 重载系统
  • 对其他生产系统的意外副作用或影响
  • 错误率高，可触发警报并呼叫人员
  • 偏斜的分析（流量漏斗，A / B测试结果等）
  • 充满脚本和漫游器活动的不正确流量日志（a）

如果客户尝试在生产中进行风险较大的更改，则结果可能会非常有害。除了上面列出的那些故障之外，还有更多的停机时间风险，应用程序安装损坏，以及在某些情况下不可逆转的损坏。以客户X（在制造业中知名的SAP Enterprise商店）为例。

在从信誉良好的站点上读取紧急通知后，OS管理员迅速将其生产节点更新为可用的最新内核更新。在数小时内，生产节点开始了一系列未启动的崩溃和内核崩溃。他急忙安装了与他的配置不兼容的内核。现有应用程序软件包，设备，文件系统和相关软件包的组合。这导致生产中断，并向多个供应商几次高优先级升级。

将补丁程序应用于测试/ QA或沙箱系统时，可以管理和验证补丁程序和关键修订，以减少生产力损失和计划外停机。在类似生产的环境中测试应用程序使您能够发现无法预料的问题，并在这些问题对您的运营产生不利影响之前进行纠正。产前设计和测试消除了代价高昂的业务中断，改善了客户体验并保护了品牌。

使用测试质量检查系统改善生产可用性和过程

这些是使用测试/质量检查系统可以改善生产可用性和过程的基础知识。 与生产环境类似的受控环境（必须与生产环境尽可能相似）必须具有以下功能：

  1. 测试内核更新和安全更新
  2. 验证设置和配置调整
  3. 重现生产问题并测试软件更新和补丁
  4. 验证应用程序版本兼容性，并减少由于不兼容的更改而导致停机的风险
  5. 提供一个安全的空间来练习和修订上线，维护，中断和其他企业程序活动
  6. 在不影响企业客户的情况下培训新员工和团队成员

如果您具有用于部署关键企业可用性软件的测试/质量检查环境，我现在可以亲吻您。有了这种环境，您的团队就可以“测试，验证和验证（2）”体系结构，业务需求，用户场景，以及与与生产环境最相似的一个系统或一组系统的一般集成-您知道赚钱。当然，您仍然必须安排窗口来维护您的生产系统并对其进行测试，但是要在这之间完成一个安全的缓冲步骤之后。

—客户体验副总裁Cassius Rhue

————-

参考文献：

  1. https://opensource.com/article/19/5/dont-test-production已访问2020年5月4日
  2. https://www.softwaretestingclass.com/system-testing-what-why-how/访问时间：5/4/2020

企业可用性：法院的教训

by Leave a Comment

企业可用性：法院的教训

企业可用性：法院的教训

我爱篮球。我喜欢玩游戏，观看游戏并仔细思考游戏的大脑方面；思想和动机，策略和战术。我想寻找能正常工作或失败的小东西，屏幕设置太早或滚动太晚。我喜欢防守和轮换。我想知道教练的练习，演练，旅行等策略。  几个月前我自然而然地离开了24/7全天候工作日，想象一下，我抽出一天时间去看篮球，更具体地说是我女儿在中学篮球练习。

在观看的大约三分之一时间内，我无法控制自己。我吹口哨，“劝诱”那个年轻的女孩，恶作剧地着小跑到球场上，大喊：“快跑！忙！”她做到了，耳边的队友也做到了。  接下来的几分钟，戏剧和演习充满了活力，清晰的切割，流畅的动作和动力。  但是，它并没有持续。  取而代之的是，需要更多的哨声，需要更多的举动来移动和奔跑，努力发挥，大刀阔斧，下潜，专心，专注，学习和纠正。2个小时快结束时，我将最后一刻的注意力转移到预言上，“练习的方式就是演奏的方式！”

我几乎可以感觉到您传达了AI的精神，而不是人工智能（AI），艾伦·艾弗森（AI）。  “我们在谈论，练习。  实践！”我认为这与可用性有关。  好吧，当我考虑女儿和队友时，我对篮球的热爱满足了我对可用性的热爱。怎么样？

篮球策略与可用性策略类似的三种方式：

  • 在篮球运动中，每个团队都需要一个计划，以确保企业可用性。
  • 在篮球运动中，每个团队都需要练习该计划，同上以确保可用性，灾难恢复，尤其是计划好的维护。
  • 在篮球比赛中，该计划在火中受到考验的情况下，其执行效果只会与实施该计划时一样好

企业可用性需要计划 

您的可用性（特别是灾难，计划的维护和中断恢复策略）仅与您创建的一样好。简而言之，您对中断的计划是什么（请注意，云故障，服务器崩溃，网络饱和以及人为错误）。  您有书面计划吗？您是否已确定所有者和备份所有者？您是否知道您的体系结构和拓扑（什么服务器做什么，它位于什么位置，它属于哪个团队，服务什么功能，与它相关的业务优先级以及它需要什么SLO / SLA）？谁是您的主要供应商，他们的召唤清单是什么？您的检查点，数据保护计划和备份策略是什么？您有什么测试计划和验证计划来验证该计划？

企业可用性需求实践 

一个好的计划，检查一下。现在练习。  实施灾难恢复步骤和计划外的停机策略是每个企业配置的必要组成部分。但是，不进行演练的策略并不是真正的策略。在这种情况下，这只是一种可能的提议方法。  它更像是一个建议，而不是实际的记录计划。第二步是练习。逐步了解您的计划策略。排练维护时间。恢复备份和数据。验证假设和失败模式。

企业可用性需要测试 

一个计划和一个演练，检查。现在您拥有三个中的两个，让我回到女儿的团队。  作为“非官方教练”，我的临别词如下：“练习的方式就是比赛的方式！”快进三天。比赛已经结束了。他们所参加的球队在运动能力上不匹配，并且与去年一样，当时该球队的比赛在半场结束时规模过大。  但是今年，人员不足和规模较小的团队显然已经做好了更多准备。本来应该是轻松的胜利现在进入了接近并列的最后一分钟。主队，即对手，开始进行新闻报道。尽管如此，我女儿的球队还是为这种命运的练习而无意中做出了准备。  随之而来的不是很好。四次失误的失误，三分球命中两次关键犯规，四分命中或零失误，以及一系列挫败感最终导致毁灭性的一分失误。

我的最后一点是，您在实际中断，灾难或计划内维护方面做得如何？您是否使用真实的数据，真实的客户以及真正的紧迫感进行练习？您的高层管理人员多久签到一次？相信我，在充满压力的时刻出现老板会让人做出奇怪而不明智的事情！您的沙盒和测试系统看起来像生产环境吗？在过去的生活中，我曾经与一位客户在产品和质量保证之间使用不同的硬件，存储和Linux OS版本进行过合作。当他们进入应用程序更新的过程中，灾难就来了。  您是否有用户和数据以及测试期间运行的作业？实际的灾难模拟呢？这是一项难以接受的工作，它会测试具有潜在破坏性后果的硬崩溃，从异地恢复，甚至更难于模拟同时发生的多点，多个系统故障，但这种做法往往不可行，往往会使2小时的计划维护变成八小时的多团队企业灾难。  练习不足或实践不佳是您的战略和团队取得惊人胜利，还是团队，供应商，企业和客户遭受惨败和代价高昂的失败之间的区别。

在篮球运动中，受到抨击的计划只能维持与计划相同的状态。  在实施恢复和灾难计划时，关键是要制定良好的计划和验证，但是出色的实践才是王道。

请与SIOS的销售代表联系，以了解我们的可用性专家和产品如何帮助您制定计划，程序和实践。

回访有关您永远不应避免进行模拟的测试的帖子。

—客户体验副总裁Cassius Rhue

文章转载自SIOS