一个软件Bug,就能让全球“蓝屏”,航空、铁路、银行、企业甚至媒体都被迫按下暂停键。一场机房火灾,就能让云服务中断甚至崩溃。物理世界中大大小小的灾难,人为操作过程中有意或无意的失误,都将给这个连续的世界造成停顿。这也难怪,为什么企业在上云初期,都将“安全性”视为第一大隐患。
直至今天,云计算虽然已经在各行各业快速普及,但增强云的韧性这一话题还是要老生常谈,反复被强调。
迷之韧性
在日常生活中,韧性是指物体受外力作用时产生变形而不易折断的性质,通常形容顽强持久的精神。所谓IT的韧性,顾名思义,指的是信息系统在面对突发状况时能够迅速恢复,并保持业务连续性的关键能力。推而广之,云的韧性是保障云服务永续的基础,它是由理念、技术、平台和架构,以及服务构成的一套完整体系,无论云平台遭受什么样的故障或灾难,都能在最短时间内恢复,最大程度地保证客户的业务连续性。
可以这样说,云的韧性是现代云服务中至关重要的组成部分。它既彰显了云服务提供商的技术能力,同时也是用户选择云服务时的重要参考依据。
亚马逊云科技大中华区解决方案架构总经理代闻
提到佛宫寺释迦塔很多人可能都不知道,但如果说起它的别称“应县木塔”,那应该是家喻户晓了吧。这座位于山西省朔州市应县佛宫寺内的木塔,是世界上现存最高大、最古老的纯木结构楼阁式建筑,与意大利比萨斜塔、巴黎埃菲尔铁塔并称“世界三大奇塔”。
既然被称为奇塔,那么应县木塔究竟“奇”从何来呢?它的整个建筑没有使用一颗铁钉,全靠木构件互相卯榫咬合而成,虽历经千年风雨,遭受过无数次地震和炮火的冲击,依然矗立不倒。这就是它令人称奇的韧性。
应县木塔之所以稳固耐久,得益于其精巧的设计、稳定而又动态的架构,还有一代又一代人的精心维护。这些基因投射到云上,也正是保持云之韧性的秘诀。
亚马逊云科技大中华区解决方案架构总经理代闻分析归纳了系统故障的三大类原因:第一,基础设施层,包括数据中心、主机、机架、网络故障或自然灾害等导致的损害等;第二,架构设计层,数据状态、应用程序状态异常、依赖项失效等;第三,运营机制层,即由运维操作、代码部署、配置错误等引起的故障。
既然故障来源已经一目了然,那么对症下药也就不是难事。下面,就让我们看看亚马逊云科技是如何不断增强其云之韧性的吧!
韧性“过三关”
依上文所述,影响业务连续性的漏洞和隐患来自三个方面,那么对应起来,也就需要有的放矢,从基础设施的韧性、韧性的技术架构,以及卓越的运营机制三个方面筑起高墙。这正是亚马逊云科技构建可靠云服务的三大基石。
先来看基础设施的韧性。你以为是简单的“以多取胜”?其实不然。
亚马逊云科技在全球设置了多个区域(Region)和可用区(AZ)。所谓区域,就是亚马逊云科技在世界各地聚集数据中心的物理位置。在中国大陆,有亚马逊云科技(北京)区域和(宁夏)区域两个区域。
可用区是区域的下一级。亚马逊云科技将每个逻辑数据中心组称为可用区。为提升可用性,每个区域通常由三个或更多个可用区组成。以宁夏区域为例,它就包含三个可用区,每个可用区又由多个或单个超大数据中心连接而成。同一区域内的可用区之间保持足够的安全距离,一般约100公里内。万一某个可用区发生电力中断或自然灾害时,区域内的其他可用区不会受到任何影响。安全距离既能防止相关故障,又能实现单位毫秒级延迟的同步复制。
在可用区内部、可用区之间、区域和区域之间,均铺设光纤线路,两两互联,实现高速数据传输的同时,任一连接都是冗余的,确保高可用性。
截止目前,亚马逊云科技在全球34个地理区域运营108个可用区,包括刚刚在马来西亚推出的新区域。全球化高冗余的数据中心基础设施能够帮助中国“出海”企业以更低延迟构建、运行更接近用户的应用程序。
2022年,奇瑞捷豹路虎选择将其关键SAP系统迁移至亚马逊云科技的云上,就利用了亚马逊云科技独有的一个区域三个可用区的特性,在亚马逊云科技特有的自适应跨可用区的高可用集群上进行整体切换,将高可用与同城灾备完美融合,故障切换时间从半小时缩短至3分钟,确保了业务连续性。
再来看韧性的技术架构。这是云服务商技术综合实力的体现。
为提升云服务的韧性,亚马逊云科技共设立了四道安全防线——区域隔离和多可用区、控制面与数据面独立、单元架构和随机分片。
根据故障隔离边界,亚马逊云科技将服务划分为三种不同类别:可用区级、区域级和全球级,以控制故障发生时对客户的影响范围。以全球级服务Amazon IAM为例,在全球级别的控制平面,IAM的增删改逻辑和数据存储架构被切分成细小的计算和存储单元。这些分布式的数据细胞共同提供服务,通过单元细胞模型实现高可用且极小“爆炸半径”,以确保服务韧性。即使在极端情况下,全球控制平面和数据下发出现故障,影响范围也仅限于无法创建新的IAM信息,而每个区域的数据平面依然可以继续稳定地提供本区域的认证授权服务。
亚马逊云科技之所以将服务拆分为控制平面与数据平面两个层面,主要出于两个原因:确保云服务的数据平面能够独立于控制平面的状态,持续稳定运行:独立扩展,互不影响。代闻打比方说:“控制面与数据面的隔离,类似于叫车软件和打车行为,两者其实是相对独立的。当你坐上车以后,如果一段时间内叫车软件因没有信号无法响应,也不会影响司机将你送到预定的目的地。之所以会出现很多故障失效的情况,主要原因在于没有将数据面与控制面做到很好的隔离。”
亚马逊云科技单元架构的设计思想,是将整个系统分解为更小的独立单元,当发生故障时,只有该单元受影响,而不会导致整个系统瘫痪。以数据库为例,亚马逊云科技为常规数据库添加分片分区层,并在存储和计算维度将整个系统分割成更小的单元,当发生故障时,无论硬件、网络、电力系统,还是代码,都可以将影响最小化。而随机分片,则可以进一步提高整个应用和系统的可用性。
最后看运营。运营与技术相关,但又不是唯技术论,而是理念、机制、技术、人员、文化的综合体。
亚马逊云科技的运营机制可以归纳为4个模块——服务责任模型、运营就绪审查、持续安全部署和纠错流程。具体来看,服务责任模型——采用服务所有权模型,激励团队不断改进运营,这种所有权不仅要负责设计和启动服务,还要在生产期间运营它,并在出现问题时随叫随到;运营就绪性审查——在发布和更新亚马逊云科技服务之前,要使用运营就绪性审查(ORR)流程对所有新服务进行审查,服务部署后,每周要举行运营会议,检查系统的运营性能以及任何悬而未决的问题;安全、持续部署——亚马逊云科技进行服务更新或推出新服务时会使用安全、持续部署管道,通过使用广泛的生产前测试、自动回滚和交错生产部署,将自动化部署安全性构建于发布过程中,从而最大限度地减少错误部署对生产造成的潜在影响;纠错流程——在出现问题时,会利用纠错(CoE)流程等事件管理机制,协助团队了解根本原因。
代闻表示:“亚马逊云科技去年每天稳定启动的Amazon EC2实例超过1亿,每秒API请求数高达100万亿。正是因为做对了很多事情,才有今天全球数百万客户的选择和信任。”基础设施的韧性、韧性的技术架构、卓越的运营机制,缺一不可,而且还要相互融合嵌套,顺畅运行。这不仅要求云服务商有深厚的技术底蕴,更要通过长期实践的积累、打磨和优化。
经验之谈
为了帮助用户构建系统韧性,亚马逊云科技打造了多种服务和工具。比如Amazon Resilience Analysis Framework可以提供指导方案,Amazon Aurora和Amazon DynamoDB都能提供多可用区同步功能,Amazon Resilience Hub韧性监测中心可以覆盖多个建设阶段,而Amazon DevOps Guru使用机器学习的方式来检测异常运维模式,还有贯穿全生命周期的Well-Architected Framework优良架构,可以量化企业构建系统时的问题列表与评估机制等。
其实除了卓越的服务和工具以外,亚马逊云科技身上更“稀缺”的价值在于,它在提升系统韧性方面具有多年实践经验,可以让客户在构建端到端韧性的过程中少走弯路。代闻介绍说,企业在韧性构建工程中,需要尤其注意以下四方面问题:系统韧性的提高是一个持续的过程,而不是一次性的努力;需要在业务需求、可靠性、成本、系统复杂度之间取得均衡;以标准软件开发生命周期为蓝本,可轻松整合到企业现有流程中;从业务、技术与持续运营等多个维度来提高系统韧性。
往/期/回/顾
从科技赋能到价值引领,东莞证券可进化的信创云建设启示录“智算”雄起 | 智算操作系统要“顶天立地”