互联网服务云存储

在云时代,如何应对云端资料存储突发故障?

前些天,亚马逊Amazon S3发生故障中断,连带使数千个采用Amazon S3服务的网站受到波及,故障持续4小时。怎么解决这类问题?

参与81

16同行回答

asdf-asdfasdf-asdf  研究学者 , cloudstone
使用多个 云公司产品  然后自建最小基础的 业务系统使用两个以上 云产品  部署业务  并在自己公司创建 最小业务系统  进行备份如果你的业务非常重要   上面的部署计划还是必须的单一的云公司   一定会有 ...显示全部

使用多个 云公司产品  然后自建最小基础的 业务系统

使用两个以上 云产品  部署业务  

并在自己公司创建 最小业务系统  进行备份

如果你的业务非常重要   上面的部署计划还是必须的

单一的云公司   一定会有 宕机时间

如果按照  三份业务备份部署    业务停止率会很小

但这样给开发和运维带来复杂的环境配置考验.

业务要做分布式    数据 要做复制   

收起
软件开发 · 2017-03-17
浏览2176
yangsuhuayangsuhua  存储架构师 , 浪潮信息
我认为这与云服务供应商所供应的服务等级SLA有关。在高级别的服务等级,应当包括应对突发故障的故障转移服务。如若想要摆脱单一厂商的局限性,现在有许多做DR as a service的公司,可以了解一下。但是这会增加额外的容灾成本。...显示全部

我认为这与云服务供应商所供应的服务等级SLA有关。在高级别的服务等级,应当包括应对突发故障的故障转移服务。如若想要摆脱单一厂商的局限性,现在有许多做DR as a service的公司,可以了解一下。但是这会增加额外的容灾成本。

收起
硬件生产 · 2017-03-17
浏览1795
xp123321xp123321  系统工程师 , 某股份制商业银行
说实话,AWS的S3是我见过的可靠性最高的公有云对象存储服务,基于AWS的“Design for Failure”原则S3面向故障恢复做过充分设计的(详细可以去了解一下AWS的7大设计原则)。但这次人为的故障场景确实没有被覆盖,从而导致了大范围服务不可用,后续aws也作出了改进方案(最小资源数、部...显示全部

说实话,AWS的S3是我见过的可靠性最高的公有云对象存储服务,基于AWS的“Design for Failure”原则S3面向故障恢复做过充分设计的(详细可以去了解一下AWS的7大设计原则)。但这次人为的故障场景确实没有被覆盖,从而导致了大范围服务不可用,后续aws也作出了改进方案(最小资源数、部分重要服务最小化方便快速启动恢复等)。从整个事件的发生和后续处置和改进过程来看,公有云服务持续在各种故障和怀疑声中加速前行。另外,还需要回顾一下公有云中关于基础设施层的两个关键抽象概念:Region区域、Avaliable Zone可用区,区域是一个提供服务一致性的能力抽象;可用区可以理解为就是物理相互隔离的网络、供电等基础设施区域,作为故障隔离的边界。不同的AZ之间相互独立不受影响,而在同一个Region内的不同AZ之间的服务能力是一致的(最关键的是网络延迟很小,这个很重要)。而对于AZ内存储服务基本上都会有高可用的技术方案支持,比如数据多副本、镜像等等。

终于可以跟这个问题有些关系了:)

一、我想说的是为了避免云端存储故障带来的影响,要先问问自己要面对哪种级别的故障,RPO和RTO的需求到底是多少(书面一点叫业务影响分析)。我理解合理利用公有云本身的高可用设计远比跨云做数据容灾来的容易(很多是物理限制,比如AWS到阿里云网络延迟和带宽成本谁解决的了),最简单的就是跨AZ部署自己的应用和数据做到负载均衡,数据跨AZ进行准实时的异步复制、备份都可以;至于跨Region或者跨公有云(AWS到青云、阿里云、企业自己的私有云等)以目前的技术限制都无法实现理想的RPO,也就是说除了问题数据丢的量和恢复时间都无法达到预期。

二、数据的可靠性远大于可用性,就这次AWS S3故障而言只是影响了可用性,没有真正的丢失数据,这已经是很好的结果了。就像墨菲定律说的会出错的总会出错,小到单个企业都会有大大小小的生产事故,更何况大规模运营的公有云。所以,选择提供高数据可靠性的服务商和技术,增加自己在业务架构层面的高可用设计是我认为比较好的方法。所谓业务架构层面高可用设计我觉得除了面向跨AZ进行业务部署和逻辑架构设计,实现水平扩展的分布式架构。

最后,还需要补充业务连续性计划方面的手段,比如应急情况客服安抚、赔偿、挽回声誉等等。因为技术还在不断进步和完善,总有我们预想不到的问题发生,需要我们配以非技术手段应对。

以上是个人观点,逻辑稍乱,请见谅。

收起
银行 · 2017-03-18
浏览1234
haizdlhaizdl  技术经理 , 大连
首先,我认为公有云的资源,无论是存储还是计算资源。它的的重要性或者是业务的RPO&RTO要求相对于成本来讲属于次要地位。也就是说对于这样的事情,我们是可以在一定程度上容忍。假设我们不能容忍或者是只能在很小程度上容忍,那么有如下建议:1 重要数据一定要有备份、有容灾镜像...显示全部

首先,我认为公有云的资源,无论是存储还是计算资源。它的的重要性或者是业务的RPO&RTO要求相对于成本来讲属于次要地位。也就是说对于这样的事情,我们是可以在一定程度上容忍。

假设我们不能容忍或者是只能在很小程度上容忍,那么有如下建议:

1 重要数据一定要有备份、有容灾镜像。

2 重要业务一定要有共有云和本地私有云之间的切换机制和具体可实施性切换方案。

3 选择云服务商可以有冗余,当一个服务商有问题的时候,我们可以启用另外一个服务商的资源。

以上,个人观点。

收起
银行 · 2017-03-18
浏览1202
wangqlwangql  系统工程师 , NULL
云计算大势所趋,相比传统的IT架构,多了灵活性、便利性等收益,减少了运维难度,卸载了自身维护的一些技术难度和风险。相对的,也少了一些可控性。从IAAS PAAS SAAS,越往上层,企业所需的技术储备越少,对it资产的可控性也越来越小。对云计算提供商的依赖性也越来越大。平时没事还好,一...显示全部

云计算大势所趋,相比传统的IT架构,多了灵活性、便利性等收益,减少了运维难度,卸载了自身维护的一些技术难度和风险。相对的,也少了一些可控性。从IAAS PAAS SAAS,越往上层,企业所需的技术储备越少,对it资产的可控性也越来越小。对云计算提供商的依赖性也越来越大。

平时没事还好,一旦出了问题,只能坐等服务商恢复服务。要想避免这种情况,有两条路:

1是倒回去,选择原来的自建架构。有点不现实,但可以梳理自己的应用,分类对待,一些不太重要的it轻应用类可以运行在云上,重要的选择自己维护。

2是在现有的云服务基层上做高可用或灾备,保证一方出了问题的时候,整体业务可以切换。当然,也可以选择自己做私有云或混合云。

收起
IT咨询服务 · 2017-03-17
浏览1184
mmsc5166mmsc5166  系统工程师 , 某金融公司信息技术中心
其实这个是 投入 与 产出 的关系。鱼与熊掌难以兼得。在IT业没有最好的方案,只有合适的方案。不管是公有云还是私有云,都是客户或者厂商基于自己的目的或者诉求推出的解决方案。云解决了用户繁琐的选型、招标采购、建设的烦恼,其实其本质没变,机房运维中会出现的痛点、难点还...显示全部

其实这个是 投入 与 产出 的关系。鱼与熊掌难以兼得。

在IT业没有最好的方案,只有合适的方案。

不管是公有云还是私有云,都是客户或者厂商基于自己的目的或者诉求推出的解决方案。云解决了用户繁琐的选型、招标采购、建设的烦恼,其实其本质没变,机房运维中会出现的痛点、难点还是会存在,一样会宕机、会丢数据。。。

其实还是绕不开冗不冗余的问题,不管是前端、中段、后端,或是前置、中间件、数据库,只要一条线的蚂蚱都是跑不了谁的。

云的优点是基础设施有人给我管,而且通用性好,虚拟化,高可用,最重要是便宜,可是那云服务也分等级,投入和产出基本还是相向而行的。不可能同样的需求,一百万和五百万的服务保障是相同的。

在相同服务等级或质量的情况下,其他的就看的还是自己的设计、维护能力,云服务商给的是资源(比如是房子),怎么用(比如装修风格、买格力空调还是美的)那可就是使用者的问题了。重要的还是要冗余的,不管你是热备冷备,还是双活、单活,言而总之你要以防万一,不要到时万年想不起信息技术的领导打电话找你,你可就happy了。

再新的技术也是有源头的,干IT该干嘛干嘛,哎。。。小王该搬砖了。。。

收起
金融其它 · 2017-03-17
浏览1214

提问者

avril024
数据库运维工程师北京同为科技有限公司
擅长领域: 存储数据安全数据保护

相关问题

相关资料

相关文章

问题状态

  • 发布时间:2017-03-17
  • 关注会员:17 人
  • 问题浏览:13198
  • 最近回答:2017-03-19
  • X社区推广