SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

  • Home
  • 产品
    • SIOS DataKeeper for Windows
    • SIOS Protection Suite for Linux
  • 新闻与活动
  • 服务器集群简单化
  • 成功案例
  • 联系我们
  • English
  • 中文 (中国)
  • 中文 (台灣)
  • 한국어
  • Bahasa Indonesia
  • ไทย

云迁移停滞的六个原因

12月 22, 2020 by Jason Aw Leave a Comment

您的云迁移停滞的六个原因

 

 

云迁移停滞的六个原因

越来越多的客户正在寻求利用云的灵活性,可扩展性和性能。 随着做出这一转变的应用程序,解决方案,客户和合作伙伴的数量增加,请确保您的迁移不会停止。

避免以下六个原因导致云迁移停滞

1.不完整的云迁移项目计划

人们普遍认为,项目计划是项目成功的关键因素。 计划在帮助指导利益相关者,多样化的实施团队和合作伙伴完成项目阶段中起着至关重要的作用。 规划可帮助确定所需目标,使资源和团队与这些目标保持一致,降低风险,避免错过最后期限,并最终在云中提供高可用性解决方案。计划不完整和计划不完整通常是导致项目停滞的主要原因。在第九个小时,确定了关键依赖性。 在服务器意外重启期间,将识别应用程序监视和HA漏洞(请参阅下文)。 确保您的云迁移有一个计划,然后执行该计划。

2.在本地过度设计

“这就是我们在本地节点上做到的方式”,这是开始最近的客户对话的短语。 当客户尝试迁移到云时,他们与SIOS专业服务项目经理Edmond Melkomian进行了接触。在一次发现会议中,Edmond能够发现许多与内部部署和云架构有关的过度设计的项目。 对于某些项目,复制在场所进行的操作可能会成为膨胀,复杂和延迟的简历。 分析您的架构和迁移计划,并无情地消除过度设计的组件和设计,尤其是在网络和存储方面。

3.预留空间不足

控制成本和防止蔓延是云迁移的重要和关键方面。但是,一些担心每小时收费以及磁盘和带宽相关成本的客户陷入了配置不足的陷阱。在此陷阱中,资源的大小不正确,例如具有错误的速度特征的磁盘,使用错误的CPU或内存占用量来计算资源或具有错误数目的节点的群集。在这种配置不足的情况下,当用户接受测试(UAT)开始并且预期/预期的工作负载在容量不足的资源上造成日志阻塞时,就会出现问题。或者目标节点的成本优化无法在故障转移方案中正确处理资源。 虽然在云中调整虚拟机的大小是一个简单的过程,但是这些大小调整问题通常会造成延迟,而架构师和首席财务官则试图了解重新配置资源的影响。

4.内部IT流程

每个伟大的企业公司都有一套内部流程,您的团队和公司也不例外。在流程中,IT流程通常是关键的,可能会对您的云迁移策略的成功产生重大影响。 过去,许多公司的采购和采购流程都很漫长,包括投标,规模调整指南,订单批准,服务器准备和配置以及最终部署。云过程极大地改变了获取,部署计算,存储和网络资源的方式。但是,如果您的流程跟不上云的速度,那么当计划更改时,迁移可能会遇到障碍。

5.高可用性计划不佳

云迁移可能会停止的另一个原因涉及高可用性计划。 高可用性不仅需要一捆工具或企业许可证。HA需要仔细,彻底和周到的系统设计。部署高可用性解决方案时,您的计划将需要考虑容量,冗余以及恢复和更正的要求。 通过计划,可以正确识别需求,提出解决方案,考虑风险并管理部署和验证的依赖性。 如果没有计划,项目和部署将容易受到风险,单点故障问题,安装不当以及缺少应用程序保护或恢复策略的层次和级别的威胁。通常,在缺乏高可用性计划的情况下,项目会停顿,而需求却没有得到解决。

6.不完整或无效的测试

罗恩(Ron)是将其最终客户迁移到云的合作伙伴,计划在接下来的三天周末上线。 “执行/不执行”的最后决定点是在登台服务器上进行了一批用户接受测试。第一次测试失败。为了弥补由于其他迁移障碍而造成的时间浪费,Ron和团队跳过了一些测试案例,这些测试案例与将最新的安全性和备份软件最终集合集成到支持补丁的最新OS上有关。 这种模拟负载是新创建的服务器上的第一个负载,它解决了Ron体系结构中的一系列问题,包括内核错误,CPU和内存供应问题以及存储布局和容量问题。 该项目被推迟了四个多星期,以解决客户的信心,正确的测试和验证,调整大小和架构以及应用软件和操作系统修复的问题。

云的前景令人鼓舞,精心计划的云迁移将使您和您的团队能够利用这些优势。 无论您是开始迁移还是正在进行云迁移,我们希望本文可以帮助您更多地了解常见的陷阱,以期可以避免它们。

–客户体验副总裁Cassius Rhue

 

 

转载自SIOS

Filed Under: 服务器集群简单化

计算云中的应用程序可用性

12月 18, 2020 by Jason Aw Leave a Comment

计算云中的应用程序可用性

计算云中的应用程序可用性

在云中部署关键业务应用程序时,您要确保它们具有高可用性。 好消息是,如果您进行适当的计划,则可以实现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%
V
PN网关– 99.9%至99.95%
负载均衡器– 99.99%
流量管理器–
99.99%
弹性负
载平衡器– 99.99%
直接连接– 99.9%– 99.99%

基于到目前为止所学的知识,让我们看一下跨两个可用区部署的应用程序的可用性。

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

99.98%的可用性=约9分钟的停机时间

通过跨多个可用区(因此跨多个磁盘)复制数据,我们有效地减轻了与云存储相关的停机时间。

应用程序和相关服务的可用性

您已尽力确保计算,网络和存储的可用性。 但是应用程序本身呢? 某些应用程序可以通过在同一应用程序的多个实例之间进行负载平衡来横向扩展并提供冗余。 想想典型的Web服务器场,您通常可以在其中平衡五台服务器之间的Web请求。 如果您丢失一台服务器,则负载平衡器仅将其从旋转中删除,直到再次响应为止。

其他应用程序则需要更多的维护和监视。 以SQL Server为例。 通常,“始终在线可用性组”或“故障转移群集实例”用于监视数据库可用性,并在数据库由于应用程序或系统级故障而变得无响应时使用恢复操作。 尽管没有针对SQL Server可用性解决方案的已发布SLA,但通常公认的是,如果为高可用性进行了正确配置,则SQL Server可以提供99.99%的可用性。

您可能依赖于其他基于云的服务,例如托管的Active Directory,托管的DNS,微服务,甚至云门户本身的可用性都应纳入整体可用性方程中。

概要

应用程序可用性是所有活动部分的总和。 仅在一个区域中跳过会成倍地影响应用程序的整体可用性。 花点时间研究可用性链中的所有链接是否存在漏洞,包括计算,网络,存储,应用程序和相关服务。

总的来说,这里列出的数字是最坏的情况,希望您的实际可用性超过已发布的SLA。 做好家庭作业,并提防任何不能保证99.99%可用性的服务,这是被认为具有高可用性的典型阈值。

本文未解决人为错误和安全问题。 您可以使您的应用程序尽可能地高可用性。 但是,如果您尚未采取措施保护应用程序免受外部威胁和愚蠢的人为错误,那么在可用性方面,所有赌注都没有了。

转载自《星际争霸》的许可

Filed Under: 服务器集群简单化

使用Datadog进行Amazon EC2监控? 与SIOS AppKeeper配对以进行自动修复

12月 11, 2020 by Jason Aw Leave a Comment

Amazon EC2监控SIOS AppKeeper

使用Datadog进行Amazon EC2监控? 与SIOS AppKeeper配对以进行自动修复

您是否曾经想过:“如果Datadog能够监视我们的Amazon EC2服务并在检测到故障时自动重新启动它们,那将是一件很好的事吗?”我也有同样的想法,因此决定自己尝试一下。

SIOS AppKeeper会自动监视Amazon EC2实例的故障,并在检测到故障时自动重启实例甚至重启服务。我心想:“如果将Datadog的监视功能与AppKeeper的自动修复功能结合起来,该怎么办?”

它有效,这就是我的工作方式。

如果您已经在使用Datadog,并且有兴趣自己尝试一下,请在本文结尾处注册以访问我们的API。

这是我设置AppKeeper以便从Datadog接收警报并在检测到停机时重新启动Amazon EC2上的Web服务器的步骤。

为了成功运行此实验,我们已经在Amazon EC2(使用Linux 2)上运行了Datadog帐户,AppKeeper帐户和NGINX Web服务器。

如何将Datadog与AppKeeper集成以提供自动修复

第一步:从AppKeeper获取重启API令牌

通过以下表单请求用于Datadog集成的API令牌:

https://mk.sios.jp/BC_AppKeeper_Datadog_api_application

如果您从表单中请求,令牌将被发送到您提供的电子邮件地址。

第二步:在AppKeeper中创建租户

下一步是在AppKeeper中注册受监视实例所属的AWS账户。 (AppKeeper将注册的AWS账户称为“租户”。)

https://sioscoati.zendesk.com/hc/zh-CN/articles/900000123406-Quick-Start-Guide#h_39404cfb-4a76-450f-99c2-e197cc63e50d

第三步:在AWS中创建IAM角色

然后,我在AWS中创建了一个IAM角色(您需要使用它来设置AppKeeper帐户)。如果您不熟悉此过程,请按以下说明进行操作。

第四步:在AppKeeper中添加租户

下一步是在AppKeeper中添加“租户”(AppKeeper认为AWS账户为“租户”)。这是有关执行此操作的详细说明的链接。

第五步:在Datadog中设置综合测试

然后,我需要为我们要监视的Nginx服务器(EC2实例)配置Datadog的轮廓监视。方法如下:

打开Datadog仪表板,然后从菜单中选择UX监视>综合测试。

单击[New Test]右上角的按钮,然后选择[New API Test]创建轮廓监视案例。

在表单中输入以下信息以创建概要监视案例。

  1. 选择请求类型
    选择“ HTTP”。
  2. 定义请求:
    设置以下值。
    网址:获取http:// {{{EC2 IP地址}}
    名称:AppKeeper Datadog集成测试(任何名称)
    地点:东京

3。 指定测试频率
没变化

4。 定义断言
点击“新断言”并设置以下值

什么时候 :

[status code][is][200]
5, 定义警报条件
没变化

6。通知您的团队
没变化

第六步:在Datadog中运行综合测试

完成上述输入后,请按“创建测试”以创建用于外部监视的测试用例。

结果可见,我们可以在“测试结果”部分中看到网络服务器正常工作。

这就是使用Datadog配置Synthetics监视所需要做的全部工作。

第七步:将AppKeeper设置为接收合成警报

接下来,我必须将AppKeeper设置为通知目标。从Datadog菜单中,转到Integrations,然后选择Integrations选项卡。

在搜索框中,输入“ Webhooks”以查找Webhooks集成。

单击“可用”以在您的Datadog帐户中启用Webhooks集成。 (一旦启用,它将显示在“已安装”列中。)

单击“配置”以打开Webhooks集成配置页面。

在页面底部的“ Webhooks”列中,单击“新建+”以创建新的Webhooks通知目标。 对于参数,输入以下内容

名称:集成名称(任何名称)

网址:https://api.appkeeper.sios.com/v2/integration/ {{AWS账户ID}} / actions / recover

有效载荷

{

“ 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许可转载

Filed Under: 服务器集群简单化

5个迹象表明,要修复高可用性,需要花费比博客文章更多的时间

12月 8, 2020 by Jason Aw Leave a Comment

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许可转载

Filed Under: 服务器集群简单化

9个迹象表明您存在应用程序可用性问题

11月 27, 2020 by Jason Aw Leave a Comment

9个迹象表明您存在应用程序可用性问题

9个迹象表明您存在应用程序可用性问题

您已经听说过“认识到问题是解决问题的第一步。”但是,许多小型,中型甚至令人惊讶的大型企业都没有意识到他们的应用程序可用性不是应该的。

继续阅读以下九个迹象,表明您仍然存在应用程序可用性问题:

1.重新启动应用程序所花的时间比使用它所花费的时间多

应用程序崩溃可能是生活中不可或缺的事实,但是如果您的应用程序宕机多于宕机,那就成问题了。

2.您已开始细心浏览收件箱或控制中心中的警报风暴

您已为应用程序或服务器停机部署了警报,但是警报风暴使收件箱不堪重负,以至于所有警报均已静音。

3.您拥有一个用于所有关键操作的数据中心

单个数据中心进行操作听起来很方便,但是已知一个意图良好但方向错误的施工人员会将单个数据中心变成昂贵的不可用区域。

4.您的数据保护理念涉及备份检索和存档

您的数据保护策略至关重要。数据复制技术和站点到站点,区域到区域复制已成为主流,因此,如果您的复制或数据保护策略不存在或对文件库进行冗长的操作,这可能是一个大问题。

5.您的恢复过程始终需要手动干预

手动干预本身不是问题。 有些事件是如此的困难和复杂,以至于可能需要大量的人工。但是,如果在服务器或应用程序中断之后,手动干预始终是第一,第二和第三项业务,那么这就是一个问题。

6.您的RTO以天而不是小时或分钟为单位进行度量

您如何衡量恢复时间目标(RTO)? 您是否以天或小时而不是每月的分钟数来衡量您的RTO?的确,每个企业的RTO都有容忍度。但是,您的RTO不应是服务器重建和体系结构中严重不稳定的函数。

7.您不知道自己的RPO,因为您的待机状态永远不会可靠地同步

您已经选中了可靠监视和恢复应用程序的复选框,并进一步采取了行动,以提供备用集群就绪系统。做得好。但是,在让您摆脱困境之前,您的恢复点目标(RPO)是什么? RPO应该比“第0天到昨晚之间的某个地方”更准确。

8.单点故障并不只是存在,而是正常现象

您的单点故障在哪里?您的预算可能无法消除每个故障点,但是如果您可以在企业的每个主要类别和每个关键组成部分中确定一个故障点,那么……

9.您上次的灾难成为地方,区域或国家新闻

如果上一次重大风暴,电网故障或故障事件由于停机而使您的业务陷入困境,那么下一个业务便是更高的可用性。

停机会在客户,生产力和安心方面给您的业务造成损失。未解决的风险会对您的业务和声誉产生确定的影响。如果这些警告标记在那里,则可能存在可用性问题。而且,如果您忽略它们,那么此后不久您可能会遇到更大的问题,因此应用程序可用性的重要性。

—客户体验副总裁Cassius Rhue

经SIOS许可转载

Filed Under: 服务器集群简单化

  • « Previous Page
  • 1
  • …
  • 56
  • 57
  • 58
  • 59
  • 60
  • …
  • 100
  • Next Page »

最近的帖子

  • 在 Nutanix 环境中选择高可用性解决方案的 10 个注意事项
  • 我的服务器是一次性的吗?高可用性软件如何融入云最佳实践
  • 灾难频发世界的数据恢复策略
  • DataKeeper 和棒球:灾难恢复的战略举措
  • SQL Server 停机风险预算

最热门的帖子

加入我们的邮件列表

Copyright © 2025 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in