| 12月 18, 2020 |
计算云中的应用程序可用性
计算云中的应用程序可用性在云中部署关键业务应用程序时，您要确保它们具有高可用性。 好消息是，如果您进行适当的计划，则可以实现99.99％（4-nines）的可用性或更高。 但是，计算您的真实可用性可能并不像看起来那样简单。 在考虑可用性时，您必须考虑使访问应用程序成为可能的关键组件，我将其称为可用性链。 可用性链的组成部分是：
您的应用程序只有最弱的链接才可用，并且您向链中添加的每个其他链接的停机时间都会成倍增加。让我们检查每个链接。 计算可用性三个主要的云服务提供商中的每一个都有一些相似之处。 这三个平台的共同点是它们将致力于计算的服务级别协议（SLA）。 当您在不同可用性区域中配置了两个或多个VM时，所有三个VM的公共云提供商的SLA为99.99％。请记住，此SLA仅保证在任何给定时间对其中一个VM的远程访问，它不保证VM内运行的服务或应用程序的可用性。如果在单个数据中心内部署单个VM，则此SLA的范围从“每小时90％”（AWS）到99.5％（Azure和GCP）或99.9％（使用Premium SSD时，Azure单个VM）。 真正的高可用性从99.99％开始，因此第一步是确保您的应用程序可用，是确保该应用程序分布在两个或多个跨越可用区的VM中。 通过将两个VM分布在两个可用区中，可以为您提供至少其中一个VM的99.99％的可用性，您可以得出以下理论：如果三个VM分布在三个可用区中，则您的可用性将甚至超过99.99％。 尽管云提供商的SLA永远不会保证可用性超过99.99％（无论正在使用的可用性区域有多少），但是如果您使用纯统计信息，您可能会得出结论，您的可用性可能会高达99.999999％或8倍可用性，每月停机时间为26.30毫秒。 1-（。0001 * .0001）= .99999999 具有三个可用区的99.999999％可用性？ 不要四处引用那个数字。 但是请记住，如果两个可用性区域可以为您提供99.99％的可用性，这是有道理的。 可以肯定地说，三个可用区将为您提供超过99.99％的可用性。 计算只是可用性链中的一个环节。 我们仍然必须解决网络，存储和其他相关服务，这些都代表了可能的故障点。 网络可用性为了使您的应用程序可用，客户端与应用程序之间的每个网络跃点以及应用程序依赖的所有资源都必须可用，并且必须在可容忍的延迟范围内工作。 您需要了解数据库服务器，应用程序服务器，Web服务器和客户端之间的网络链接，以准确了解网络可能在哪里发生故障。 请记住，可用性链中的链接越多，总体可用性就越低。 尽管标准计算SLA涵盖了同一vNet中虚拟机之间的网络可用性，但是您可能仍在使用其他网络服务。 这只是您可能会使用的网络服务的一些示例，这些示例会影响整体应用程序的可用性。 快速路线– 99.95％ 基于到目前为止所学的知识，让我们看一下跨两个可用区部署的应用程序的可用性。 99.99％的计算可用性 99.99％负载均衡器可用性 .9999 * .9999 = .9998 99.98％的可用性=每月约9分钟的停机时间 既然我们已经解决了计算和网络可用性问题，那么让我们继续进行存储。 存储空间现在这里是故事多毛的地方。 看一下以下存储SLA https://azure.microsoft.com/zh-CN/support/legal/sla/storage/v1_5/ https://cloud.google.com/storage/sla https://aws.amazon.com/compute/sla/ 显然，Azure和Google在块存储解决方案上提供了99.9％的SLA。 AWS在这里没有特别提及EBS。 他们只谈论虚拟机，并按小时而不是其他云提供商那样按月衡量其单实例虚拟机的可用性。 为了便于讨论，让我们使用Azure和GCP均已发布的99.9％可用性保证。 在前面的示例的基础上，让我们为方程式添加一些存储空间。 99.99％的计算可用性 99.99％负载均衡器可用性 99.9％托管磁盘 .9999 * .9999 * .999 = .9988 99.88％的可用性=每月约53分钟的停机时间。 53分钟的停机时间比我们在先前示例中计算的9分钟的停机时间要长得多。 我们如何才能最大程度地降低99.9％的存储可用性的影响？ 我们必须在存储中建立更多的冗余！ 幸运的是，在计划应用程序可用性时，我们通常会包括存储冗余。 例如，当我们站起Web服务器时，每个Web服务器通常会将数据存储在本地连接的磁盘上。 部署域控制器时，Microsoft Active Directory负责在所有域控制器之间复制AD信息。 对于类似SQL Server的情况，我们利用AlwaysOn可用性组或SIOS DataKeeper来保持数据在本地连接的磁盘之间的同步。 我们跨不同可用性区域分布的数据副本越多，我们越有可能幸免于难。 例如，将数据存储在不同可用性区域中的两个不同磁盘上的应用程序将受益于冗余，而不是99.9％的可用性，它更有可能实现99.9999％的存储可用性。 1 –（.001 * .001）= .999999 如果将其放到先前的方程式中，图片将开始看起来更亮一些。 .9999 * .9999 * .999999 = .9998 通过跨多个可用区（因此跨多个磁盘）复制数据，我们有效地减轻了与云存储相关的停机时间。 应用程序和相关服务的可用性您已尽力确保计算，网络和存储的可用性。 但是应用程序本身呢？ 某些应用程序可以通过在同一应用程序的多个实例之间进行负载平衡来横向扩展并提供冗余。 想想典型的Web服务器场，您通常可以在其中平衡五台服务器之间的Web请求。 如果您丢失一台服务器，则负载平衡器仅将其从旋转中删除，直到再次响应为止。 其他应用程序则需要更多的维护和监视。 以SQL Server为例。 通常，“始终在线可用性组”或“故障转移群集实例”用于监视数据库可用性，并在数据库由于应用程序或系统级故障而变得无响应时使用恢复操作。 尽管没有针对SQL Server可用性解决方案的已发布SLA，但通常公认的是，如果为高可用性进行了正确配置，则SQL Server可以提供99.99％的可用性。 您可能依赖于其他基于云的服务，例如托管的Active Directory，托管的DNS，微服务，甚至云门户本身的可用性都应纳入整体可用性方程中。 概要应用程序可用性是所有活动部分的总和。 仅在一个区域中跳过会成倍地影响应用程序的整体可用性。 花点时间研究可用性链中的所有链接是否存在漏洞，包括计算，网络，存储，应用程序和相关服务。 总的来说，这里列出的数字是最坏的情况，希望您的实际可用性超过已发布的SLA。 做好家庭作业，并提防任何不能保证99.99％可用性的服务，这是被认为具有高可用性的典型阈值。 本文未解决人为错误和安全问题。 您可以使您的应用程序尽可能地高可用性。 但是，如果您尚未采取措施保护应用程序免受外部威胁和愚蠢的人为错误，那么在可用性方面，所有赌注都没有了。 |
||||
| 12月 11, 2020 |
使用Datadog进行Amazon EC2监控？ 与SIOS AppKeeper配对以进行自动修复 |
5， 定义警报条件
| {
“ instanceId”：“ {{EC2实例ID}}”， “名称”：“ nginx” } |
自定义标题：选中该复选框并输入以下内容
| { “内容类型”：“应用程序/ json”， “ accept”：“ application / json”， “ appkeeper-integration-token”：“ {{获取AppKeeper外部集成令牌}}中获得的令牌” } |
完成后，按“保存”。
第八步：将AppKeeper连接到综合测试
接下来，我必须配置AppKeeper（注册的Webhooks集成），以便在发生Synthetics监视警报时调用它。
从菜单的“ UX监视”>“综合测试”中打开在“使用Datadog配置综合监视”中设置的测试用例。
从右上方的变速箱中选择“编辑测试详细信息”，然后在“ 5.输入以下值”中输入以下值。 通知您的团队”框以保存更改。
| @webhook-{{Datadog中Webhook集成的名称}} |
※您可以设置“如果显示器尚未解决则重新通知”。如果AppKeeper第一次无法恢复，则可以重试。测试不是必需的，但是我们建议您将其设置为（[10 minutes]最小间隔）。
安装完成。
第九步：通过再次运行测试来确认集成
然后，我确认如果Datadog检测到它关闭，AppKeeper将还原Web服务器。
打开您刚刚从Datadog中的UX监视>综合测试中设置的综合监视测试用例。
单击右上角的“恢复测试”，然后打开“合成”监视。
现在，Datadog将定期执行Synthetics监视。
测试结果表明服务器已成功访问。
接下来，我创建了网络服务器的伪故障，以测试AppKeeper的自动修复。
由于很难造成真正的失败，因此我停止了该服务，并造成了无法查看网页的情况。为此，我连接到使用SSH安装Nginx服务器并停止Nginx的EC2实例。
| sudo systemctl停止nginx |
短暂等待后，Datadog检测到Web服务器不再可访问。
Datadog中的“综合测试”页面还显示测试用例失败。
如果测试用例失败，Datadog将通知AppKeeper Synthetics监视失败。
当AppKeeper收到通知时，它将自动尝试重新启动Nginx。
因此，如果您稍等片刻，就会发现Datadog的Synthetics监控检查将再次通过。
另外，如果您登录到AppKeeper仪表板，则会看到恢复已执行。
–
在本练习中，我以Web服务器（Nginx）为例，通过Datadog自动执行检测故障并通过AppKeeper恢复服务的过程。
通过将Datadog与EventBridge和Lambda集成或创建自定义脚本，可以实现类似的自动化。
但是，如果您经常添加目标实例或重新启动各种服务，则维护EventBridge和Lambda或脚本的成本和复杂性将会增加。
AppKeeper已与Datadog进行了可靠的集成，并且您可以轻松地向应用程序添加目标实例，从而可以轻松地将自动化添加到DevOps环境中，从而减少停机时间。
如果您当前正在使用Datadog，并且想试用AppKeeper的Restart API，请先在此处注册我们的14天免费试用版（安装免费试用版后即可购买订阅）。然后单击此处以请求免费试用。 我们将引导您完成整个过程，并为您提供免费的评估令牌，以帮助您入门。
申请评估令牌
谢谢。我希望您能借此机会更多地了解SIOS AppKeeper，它可以自动监视和恢复在EC2上运行的应用程序。
-SIOS Technology技术团队的Tatsuya Hirao。
经SIOS许可转载
5个迹象表明，要修复高可用性，需要花费比博客文章更多的时间
5个迹象表明，要修复高可用性，需要花费比博客文章更多的时间
标志在那里。 警告灯闪烁。在您的直觉中，您可以感觉到它。 也许你睡不着您的高可用性问题很深。 但是，也许您不太确定。
1.如果您认为云SLA是高可用性所需的全部
云解决方案在提高硬件可用性和弹性方面取得了巨大进步。 但是，应用程序高可用性不仅需要选择正确的管理程序或云提供商，还需要更多。 云或虚拟化提供商提供的SLA不能阻止您的高可用性策略。 正如Wired所引用的那样，“ 2011年4月近四天的Amazon中断并未违反Amazon的EC2 SLA，正如FAQ所解释的那样，“保证了在365年内某个区域内99.95％的服务可用性。”在这篇DZone文章中，我们自己的David Bermingham详细细分了云SLA和应用程序可用性之间的差异。 如果您想要一个高度可用的基础架构，则它还必须包括在数据和应用程序层的监视，恢复和弹性。
2.如果您仅使用开源操作系统随附的高可用性群集
如果是这样，那么您很可能没有根据与操作系统捆绑在一起的数据库来选择数据库，那么为什么仅根据该标准选择HA解决方案。 捆绑的工具在提供额外的保证，可能性和功能方面大有帮助。 但是，尽管易于访问，捆绑的工具和OS群集软件并不总是能够满足您的SLA，RPO，RTO和可用性要求。 如果您的企业具有操作系统的组合，则您的团队可能需要导航不同工具并了解它们如何集成在一起的帮助。 这有点像选择树篱修剪器，然后将路边的割草机推到路边，在13洞5杆洞（奥古斯塔）上塑造“杜鹃花”。 两台割草机都旨在割草，但是您有多少时间？ 您将如何处理复杂性？ 您会信任哪个？ 您的高可用性策略所需要的不只是考虑与操作系统捆绑在一起的便利性，否则，您将运行MySQL而不是SAP HANA。
3.如果您认为企业应用程序许可（例如SQL Enterprise或Oracle Enterprise）与企业高可用性相同
除了增加成本外，许多企业应用程序许可证还提高了应用程序在某些高可用性方案中恢复的能力。 但是，整个企业极不可能基于单个应用程序。 您的高可用性不仅需要高可用性的数据库解决方案。 您将需要一个企业级应用程序监视和恢复解决方案，该解决方案需要对所有应用程序和数据库的广泛支持。 此外，您不仅需要管理和复制数据库数据的能力，还需要管理和复制关键应用程序和配置数据的能力。 单个数据库或简单应用程序的可用性是一回事，但是复杂，多部分应用程序和支持数据库的HA却大不相同。 在故障转移/切换之前，期间和之后，需要提供更多的服务，需要协调的更多部分，要协调的更复杂的体系结构，要遵循的更具体的最佳实践。 超出您企业许可证所支付的价格。
4.如果您的停机时间在增加，而停机时间在减少
在许多领域，生活的节奏都在不断增加。 您的团队最后一次从备份中恢复，手动重新启动被认为是关键的应用程序或重新启动一组故障的虚拟机或节点是什么时候？ 中断事件的速度不能继续超过可持续性，或者您的团队有能力从消防转向防火和防火。 “你只能跑那么久这么久（Carey Nieuwhof）。”对于某些人来说，您交火已经太久了，而且停机时间比正常运行时间更为普遍。
5.如果您的第一个故障转移测试是在生产服务器上
最近的一位客户指出，不可能针对每种可能的灾难情况进行测试。 随着新软件的创建，部署，更新和修补，更高可用性方面的挑战越来越大。 但是，您的实时生产数据不是找出不能一起很好发挥作用的地方。 尽管Go-Live和Post-Go-Live总是会带来很多惊喜，但是无法真正进行故障转移和在备份节点上运行不应是其中之一。
精练博客可以为您提供有用的提示和见解，以定义，重新定义和提高您的更高可用性。 但是，如果警告信号消失了，您已经用某种“足够”来换取了真正的可用性，那么修复该问题所需要的不仅仅是博客文章，或者是在可用性世界中搜索每篇博客文章来解决的问题。您的医管局。
–客户体验副总裁Cassius Rhue
经SIOS许可转载
9个迹象表明您存在应用程序可用性问题
SIOS AppKeeper现在可在AWS Marketplace中使用
SIOS AppKeeper现在可在AWS Marketplace中使用
使您可以更轻松地在您的DevOps环境中添加自动修复。
今天，我们很高兴地宣布，我们的SIOS AppKeeper解决方案现已在AWS Marketplace上提供，AWS Marketplace是一个数字目录，其中包含来自独立软件供应商的数千个软件清单，可轻松查找，测试，购买和部署在Amazon Web Services上运行的软件（AWS）。 现在，最终用户和AWS Partner Network（APN）成员比以往任何时候都更容易尝试，获取和部署SIOS AppKeeper，以向其DevOps环境添加自动修复。单击此处以在AWS Marketplace中查看AppKeeper。
SIOS AppKeeper持续监视和保护您在Amazon EC2上运行的应用程序。 自2017年以来，我们一直在日本销售AppKeeper，并于今年初将SaaS服务推向了美国市场。我们创建AppKeeper是为了响应我们从迁移到云的客户那里听到的需求，他们关心的是减少潜在的停机时间，同时又在有限的资源中苦苦挣扎。 如果您想观看有关如何安装和使用AppKeeper的视频，请单击此处。
AWS EC2应用程序监视– SIOS AppKeeper |操作系统
Amazon EC2用户多长时间遇到一次停机？ 根据我们的客户数据，只有三个Amazon EC2实例的普通客户每月至少要经历一次停机时间。那可能是由于软件配置错误等引起的。
超越应用程序监视，提供自动修复
许多AWS用户正在部署应用程序性能监视（APM）解决方案（例如来自AppDynamics，Datadog，Dynatrace或New Relic的解决方案）来监视其AWS环境。但是，这些仅使您警惕某些事情发生的事实以及发生的原因。 他们不会采取任何措施来减少停机时间。
这就是AppKeeper的用武之地。 如果AppKeeper在Amazon EC2上运行的任何应用程序服务中都检测到停机，它将通过重启受影响的服务并在必要时重启实例来自动响应。 AppKeeper解决了85％的应用程序服务故障。 通过自动恢复，减少了IT团队对昂贵的外包监控或干扰的需求。从AppKeeper了解有关APM自动化的更多信息。
如果已经检测到Amazon EC2停机，并且已经在使用APM解决方案并希望将功能扩展到包括自动修复的AWS客户，则可以利用AppKeeper的webhooks API与他们选择的APM解决方案集成。
为什么我们决定将SIOS AppKeeper列出到AWS Marketplace
自2014年以来，在SIOS Technology Corporation，我们与Amazon AWS建立了战略合作伙伴关系，主要围绕我们的SIOS DataKeeper和SIOS LifeKeeper高可用性解决方案。SIOS Technology是当今的APN高级合作伙伴，我们共享100个共同客户。
既然我们已经为SIOS AppKeeper的有效性提供了客户证明（这里是您可能会喜欢的一些最新案例研究），我们希望使Amazon客户和APN合作伙伴更容易尝试，购买和使用AppKeeper。据许多估计，使用AWS Marketplace中的软件的活跃AWS客户超过200,000，他们都在利用AWS Marketplace轻松进行云计算之旅时发现，获取和使用补充解决方案的便利性。
克里斯·格鲁斯（Chris Grusz）说：“我们的亚马逊朋友再好不过了：“随着我们的客户将越来越多的应用程序迁移到云中，他们正在寻求灵活性，以平衡可用性水平和所有应用程序的成本。” Amazon Web Services，Inc. AWS市场总监。“我们很高兴欢迎SIOS AppKeeper加入AWS Marketplace，并在发生性能变化时为我们的客户提供更多选择。”
有兴趣保护EC2应用程序免受不必要的停机影响的AWS客户现在可以自己快速试用AppKeeper，并且可以在自己的Amazon Enterprise Discount Plan中购买AppKeeper。SIOS AppKeeper的起价为每个实例每月40美元。
合作伙伴现在将AppKeeper集成到他们的客户解决方案中
现在有许多合作伙伴将AppKeeper集成到其客户解决方案中，并且在AWS Marketplace中提供了AppKeeper，这意味着APN成员可以更轻松地评估该解决方案是否适合其业务和客户。 托管服务提供商（MSP）开始将AppKeeper纳入他们如何监视和管理客户的AWS环境中，以减少停机时间和自身运营成本。其他ISV正在将AppKeeper的自动修复功能集成到自己的云管理解决方案中，AWS咨询合作伙伴正在打包AppKeeper，因为他们为客户开发并在AWS上部署了应用程序。
有兴趣评估AppKeeper是否适合其业务的APN成员应通过电子邮件d-yoshioka@us.sios.com与我们联系。
我们希望您自己尝试SIOS AppKeeper（我们有14天的免费试用期和简单的安装过程），并加入许多现在放松的客户，他们知道他们已经进行了自动修复以减少任何Amazon EC2停机时间他们可能会经历。