下载安卓APP箭头
箭头给我发消息

客服QQ:3315713922

云储存故障原因详解

作者:课课家教育     来源: http://www.kokojia.com点击数:1374发布时间: 2017-05-02 13:00:49

标签: 云计算云储存虚拟化

  云存储[1]是在云计算(cloudcomputing)概念上延伸和发展出来的一个新的概念,是一种新兴的网络存储技术,[1]是指通过集群应用、网络技术或分布式文件系统等功能,将网络中大量各种不同类型的存储设备通过应用软件集合起来协同工作,共同对外提供数据存储和业务访问功能的一个系统。当云计算系统运算和处理的核心是大量数据的存储和管理时,云计算系统中就需要配置大量的存储设备,那么云计算系统就转变成为一个云存储系统,所以云存储是一个以数据存储和管理为核心的云计算系统。

  简单来说,云存储就是将储存资源放到云上供人存取的一种新兴方案。使用者可以在任何时间、任何地方,透过任何可连网的装置连接到云上方便地存取数据。

云储存故障原因详解_云计算_云储存_虚拟化_课课家教育

  如今2017年,云是重要业务技术选型的最好选择。使用云也为管理基础设施带来了很多益处,包括提升灵活性、可扩展性,同时降低了IT成本。但是上周我们目睹了AWSS3停机故障[1],看来即使是最可靠的服务提供商也可能遇到倒霉的一天。服务不可用直接导致了数百万的收入损失,以及难以估量的公司品牌负面影响。尽管如此,你依然可以采取一些预防措施来减少这种事件的负面影响。

  事故报告

  亚马逊Web服务(AWS)是当今被广泛使用的的云基础设施服务,占据全球40%以上的市场份额。一直以来AWS的服务质量都高于其服务质量协议(SLA),达到99.9%的正常运行时间。但是上周发生的AWS简单对象存储服务(S3)故障说明没有什么服务是完美无懈可击的。

  在星期二上午11:30左右,AWS美国东一区(US-EAST-1)的S3存储服务宕机,并且迅速产生了巨大的影响。服务恢复后,AWS发布了一个声明,有意思的是,我们从官方声明中发现,这次故障既不是人为破坏的,也是不是系统损坏的原因,而仅仅是由简单的错误输入命令导致。难以置信吧?但确实是,一个完全无意的命令输入错误[1],这导致像Adobe,Slack,Expedia,甚至是美国证券交易委员会,都遭受了严重的性能影响,据悉还有小的在线电商网站因此被拖垮。

  目前很难准确估量在这将近5个小时的宕机过程中造成的财产损失,但据不完全统计,已经造成了数千万的财产损失,数十万的用户受到影响。

  事故真相

  整个事故过程中,虽然许多依赖美国东一区S3服务的公司在宕机期间受到严重影响,但仍然有一些公司部分或全部业务毫不受影响。这是为什么?有几个因素发挥作用。

  隐藏的依赖

  S3服务已经成为大多数基于云的分布式系统中至关重要的组件。正因为其被广泛使用,同时大量复杂的服务或系统构建在它之上,所以当S3服务不可用时加剧了事故影响范围和深度。对于那些直接或间接依赖(S3服务)的系统,S3服务都会成为潜在的影响因素。

  网络性能监控公司ThousandEyes归纳了3种可能被所依赖的S3服务影响的表现形式:

  如果一个公司的静态网页直接或单独托管在宕机的S3服务器上,那么将变得完全不可用。很不幸,LululemonAthleticaInc是这类公司之一。

  如果页面中的某些元素(脚本、资源)直接或间接依赖于S3服务,则会发生部分失效。比如Slack,事故造成它的文件上传功能变得不可用。

  应用程序的关键服务可能依赖于受影响的S3或其他AWS服务,这将导致应用部分或完全无法使用。8thLight的创始人之一介绍了他对AWSLambda功能的使用,通过它可以实现ratelimit功能以限制用户恶意请求,但在宕机期间它变得无法使用,因为该功能依赖S3服务。最后他给出了一条建议:“清楚的认识你依赖的依赖。“

  滑稽的是,事故刚开始发生时,AWS无法将S3服务状态更新到仪表板上,因为它也依赖于S3来存储。这意味着出现故障的服务在宕机期间显示为正常?!这就是我们说的隐藏的依赖!

  这里我们强调的是要知道风险在哪里,并做有针对性得规划。将每个远程依赖关系都看作是潜在的故障点这会有所帮助,特别是以这次AWS事故为例,对远程依赖关系的分析首先将会帮你反思是否真的有依赖的必要。

这里我们强调的是要知道风险在哪里,并做有针对性得规划。将每个远程依赖关系都看作是潜在的故障点这会有所帮助,特别是以这次AWS事故为例,对远程依赖关系的分析首先将会帮你反思是否真的有依赖的必要。

  AWS的数据中心(zone)遍布全球16个不同的国家地区。在美国,有四个地区:北弗吉尼亚州、俄亥俄州、俄勒冈州和北加利福尼亚州,剩下的则分布在欧洲、亚洲、南美洲和澳大利亚。

  在AWS上部署/使用服务时,可以选择要部署到哪个独立区域。显而易见,通过跨地区、或者跨云服务提供商来创造冗余,将提供最健壮的业务连续性。在这次事故中,只有一个区(美国东一区)受到影响,但对那些资源/服务/依赖集中在这个区的公司来说,这便成他们的噩梦。

  云存储中的存储设备数量庞大且分布多在不同地域,如何实现不同厂商、不同型号甚至于不同类型(如FC存储和IP存储)的多台设备之间的逻辑卷管理、存储虚拟化管理和多链路冗余管理将会是一个巨大的难题,这个问题得不到解决,存储设备就会是整个云存储系统的性能瓶颈,结构上也无法形成一个整体,而且还会带来后期容量和性能扩展难等问题。

  云存储中的存储设备数量庞大、分布地域广造成的另外一个问题就是存储设备运营管理问题。虽然这些问题对云存储的使用者来讲根本不需要关心,但对于云存储的运营单位来讲,却必须要通过切实可行和有效的手段来解决集中管理难、状态监控难、故障维护难、人力成本高等问题。因此,云存储必须要具有一个高效的类似与网络管理软件一样的集中管理平台,可实现云存储系统中设有存储设备、服务器和网络设备的集中管理和状态监控。

  为故障而设计

  前面提到,一些公司在这次事故中损失较小。这是因为他们部署服务时,带着某一天某些事会出错的预期,从而更有针对性得做准备。

  虽然AWS正在处理此次事故的后续事宜,但是亚马逊的零售部门(amazon.com),尽管依赖S3,但在事故期间并没有受多大影响。诚然,亚马逊在任何时候都会采取所有必要和建议的预防措施,以确保其旗舰产品的健壮。

  如何为故障做规划和预防,我们可以参考Netflix。他们内部使用一套被称为猴子军团(SimianArmy)的云测试工具,这些工具专门用于模拟系统上的破坏,以便捕获可能导致服务中断或性能问题的任何潜在故障点。通过规划一系列可能遇到的小问题和大问题,Netflix能够预测他们系统面对问题时反应,并依此建立各种保护措施,以确保系统在故障期间依然可以提供服务。

  应对故障的准备措施不应采取”一刀切“的方法。亚马逊和Netflix都拥有海量的数据、数亿用户,他们的预防措施和解决方案可能有很大不同。在决定如何防止第三方故障时,应考虑诸如数据容量,针对不同情况进行防护的性价比,以及计算损失风险等因素。

  对于较小的规模,解决方案可能不是完全预防,而是如何优雅的降级。这意味着需要对应用中各个功能进行不同优先级的容错。例如网络故障时,对于需要远程访问的资源降级成从本地文件/缓存中获取。

  S3事故也暴露了网络架构设计的缺陷,AWS官方提出了未来防止这类事故的举措,也表态采取更多的预防措施来保护客户们的业务不受损失是十分重要且明智的。

对于较小的规模,解决方案可能不是完全预防,而是如何优雅的降级。这意味着需要对应用中各个功能进行不同优先级的容错。例如网络故障时,对于需要远程访问的资源降级成从本地文件/缓存中获取。    S3事故也暴露了网络架构设计的缺陷,AWS官方提出了未来防止这类事故的举措,也表态采取更多的预防措施来保护客户们的业务不受损失是十分重要且明智的。

  真正的云存储系统将会是一个多区域分布、遍布全国、甚至于遍布全球的庞大公用系统,使用者需要通过ADSL、DDN等宽带接入设备来连接云存储。只有宽带网络得到充足的发展,使用者才有可能获得足够大的数据传输带宽,实现大量容量数据的传输,真正享受到云存储服务,否则只能是空谈。

  更多详细内容,尽在课课家教育,我们期待您的咨询!

赞(21)
踩(0)
分享到:
华为认证网络工程师 HCIE直播课视频教程