最稳定的香港服务器香港和记机房服务器出租

最稳定的香港服务器香港和记机房服务器出租

自12月18日阿里云香港可用区C因为机房水冷机组出现故障,导致一次,阿里云历史上最长的宕机后,官方终于在圣诞节那天,出具了一份非常翔实的调查报告《关于阿里云香港Region可用区C服务中断事件的说明》,称得上是实事求是面对问题了。

我从业十五年,参与建设过4000个节点的私有云,也搞过机房装修和上架,还有一点:运?维经验,算是有相;关经验,跟大家讨论一下以后自家单位的容灾应、该怎么!做吧。

大家先看这次阿里云宕机事故的重点时间线就发现机房。温控告警了,然后9点01就正确定位?到制冷异常了。这个问题阿里云没有隐瞒的必要,因为机房突然升、温,只能是空调(冷机?)故障了。

12月25日,阿里云发布香港Region可用区C服务中断事件说明,并向所有受到故障影响的客户公开致歉,称将尽快处理!赔偿事宜。阿里云表示,将尽一切努力从此次事件中吸取经验教训,持续提升云服务的稳定性。在说明中,阿里云公。布了本”次事件”的故障情。况、问题,分析,和改进!措施,具体如下:

12月18日08:56,阿里云监控到香港Re、g“ion可用区C机房包间通道温控告警,阿里云”工程师;介入。应急处理,通知:机房服“务商进行现场排查。09:01,阿里云监控、到该:机房多个包间温升告警,此时工程师排。查到冷机异常。09:09,机房服务商按应急预案对异常”冷机进行4+4主备切换以及重启,但操作;失败,冷水机组无法恢复正常。09:17,依照“故障处”理流程,启动制冷!异常,应急预案,进行辅助。散热和;应急通风。尝试对“冷机控制系统逐个进;行隔离和手工恢复操作,但发现无法稳定。运行,联系冷机设备供应商到、现场排查。此时,由于高温、原因,部分服务器开!始受到影响。

自10:30开始,为避免可能出现的高“温消防问题,阿里云工程师陆续对整个机房计算、存储、网络、数据库、大数?据集群进。行降载处”理。期间,继续?多次对:冷机设备进行操。作,但均不能保持稳定运行。

12:30,冷机:设备供;应商到场,在多方工;程师诊断、下,对冷塔、冷却水管!路及”冷机冷凝。器?进行手工”补水排气操作,但系统仍然无法保持稳定运行。阿里云工程师对部分高温包间启动服务器关机操作。14:47,冷机设备供应商,对设备问题排查遇到困难,其中一个包间因高温触发了强制消防喷淋。15:20,经冷机设备商工程师?现场手?工调整配?置,冷机群控解锁完成并。独立运行,第1台冷机恢复正常,温度开始下降。工程师随后继续通过相同方法对其他冷机进;行操作。18:55,4台冷,机恢复到、正常制:冷量。19:02,分批启;动服务器,并持续观察:温升情况。19:47香港服务器搭建一个多少钱,机房温?度趋于稳定。同时,阿里云工程师开始进行服务启动恢复,并进行必要的数据完整性检查。

21:36,大部:分机房包间服务器陆续启动并;完成检查,机房温度稳定。其中一个包间因消防喷淋启动,未进行服务“器上电。因为!保持数据!的完。整性至关重。要,工程师对这个包!间的服务器进行了仔细的数据安全检查,这里花费”了一些必要的!时间。22:50,数据检查以及风险评估完成,最后一个包间依据安全性逐步进行供电恢复和服务器启动。

12月18日09:23,香港Re,gion可用区C部分ECS服务器;开始出;现停机,触发同可用区内宕机迁移。随着温度继续升高,受影”响的服务器;停;机数量持续增加,客户业务开;始受到;影响,影响面扩大到香港?可用区C的EBS、OSS、RDS等更多云服务。

阿里云香港可用区C的故障最稳定的香港服务器,没有直接影响客户在香港其他可用区运行的业务,但影响了香港Region ECS管控服务(Control Plane)的正常使用。因大量可用区C的客户在香港其他可用区新购ECS实例,从12月18日14:49开始,EC!S管控“服务触!发限流,可用性最!低跌!至20%。客户在使用RunInsta:nces/CreateInstance API购买新ECS实例时,如果指定了、自定义镜像,部分实例在购买成功之后会出现,启动失败的现象,由于自定义镜像数据服务依赖可用区C的单AZ冗余版本的OSS服务,无法通过重试解决。此时,部分Dataworks、k8s用户控制台操作也受到了故障影响。API完全恢”复可用为当日23:11。

12月18日!10:37,阿里云香港可用区C的部分存储服务!OSS开始受到停机影响,此时客户暂不会感知,但持续高温会导致磁盘坏道,影响数据安全,工程师?对服务器。进行停机操作,从11:07至18:26中断,了服务。阿里云在香?港R!egion,可用区C提供了2种类型的OSS服务,一种是OSS本地冗余LRS服务(通常叫单AZ冗余服务),仅部署在可:用区C;另一种是O”SS同城冗余ZRS服务(通常叫3AZ冗余服务),部署:在可用区B、C和D。在此”次故障中,OSS同城冗余ZRS服务基本没有受到影响。可用区C的OSS本地冗余服务中断时间较长,因不支持跨可用区切换,需要依赖最稳定的香港服务器,故障机房的恢复。从18:26开始,存储服务器重新分批启动。其中,单AZ本地冗余LRS服务有部分服务器因消防问题需要做隔离处理。恢复服务前,我们必须要确保数据可靠性,花费了较多的、时间进行完整性检验”工作。直至12月;19日?00:30,这部分。OS:S服务(单AZ冗。余服务)才恢复:了对外服,务能。力。

阿里云网络少量单可用区产品(如:VPN、Pr,ivatelink以“及少量GA实例)在此次故障中;受到影响。12月18日11:21,工程师启动网络产品可?用区;容灾逃逸,12:45完成SLB等大部分网络产品可用区容灾逃逸,13:47NAT产品完成收尾逃逸。除上述少量单可用、区产品以外,各网络产品在故障期间保持了业务连续性,NAT有分钟级业务受损。

12月18日10:17开始,阿里云香港Region可用区C部;分RDS实例,出现不可用的报警。随着”该可用!区受故!障影响的主机范围扩大,出现服务异常的实例数量随之增加,工程师启动数据库应急切换预案流程。截至12:30,RD。S 、MySQL、与R;edis、MongoDB、DTS等跨可用区实例完成跨可用区切换。部分单可用区实例以及单可用区高可用实例,由于依赖单可用区的数据备份,仅少量实例实现有效迁移。少量支持跨可用区切换的RDS实例没有及时完成切换。经排查是由于这部分RDS实例依赖了部署在香港Region可用区C的代理服务,由于代理服务不可用,无法通过代!理地址访问RD”S实例。我们协助相关客户通:过临时切换到使用RDS主实例的地址访问来进行恢复。随着“机房制冷设备恢复,21:30左、右绝大部分数据库实例恢”复正常。对于受故!障影响的单机版实例及主备均在香港Region可用区C的高可用版实例,我们提供了克隆实例、实例迁移等临时性恢复方案,但由于底层服务资源。的限制,部分实例的,迁移,恢复过程遇到一些异常情况,需要花费较长的时;间来处?理解决。

我、们注意到,同时在多个可用区运行业务的客户,在这次事件中依然可以维持业务运行。对于业务需要绝对!高可用!的客户,我们持续建议您采用全链路多可用区的业务架构设计,以应对各种可能的“意外事件。

原因分析:机房冷却系统缺水进气!形成气阻,影响水路循环导致4台主冷机服务异常,启动4台备冷机时因主备共。用的水路循环系统气阻导致启动失败。水盘补水后,因机房冷却系?统的群控逻辑,无法单立启动冷机,手工修改冷机配置,将冷机从群控调整为独”立运行后,陆续启动冷机,影响了冷却系统的恢复时长。整个过:程中,原因定,位耗时“3小、时34分“钟,补水排;气耗。时、2小”时57分钟,解锁:群控,逻辑启动4台冷机耗时3小时32分钟。

改进措施:全面检查机房基础设施管?控系统,在监控数据采集,层面,扩大覆:盖度,提升精,细度,提高对故!障的排查和,定位速度;在设施管控逻辑层面,确保系统自动切换逻辑符合预期,同时保证手工切换的准。确性,防止内。部状态,死!锁从而影响”故障的;恢复。

原因分析:随着机房冷、却系”统失效,包间温度逐渐!升高,导致一机房包间温度达?到临界值触发消防系统喷淋,电源柜和多列机柜进水,部分机器硬件损坏,增加了后:续。恢复难度和时长。

改进措施:加强机房服务商管理,梳理机房温升预案及标准化执行动作,明确温升场景下的业务侧关机和机房强制、关电的预案,力求更?简单有效,并通过常态?化演练强化执行。

原;因分析:ECS;管控;系统为B、C可用区、双“机房容灾,C可用区,故障后由B可”用区对外提供服务,由于大量可用区C的!客户在香港其他可用区!新购实例,同时可用:区C的ECS实例拉起恢复动作引入的流量,导致、可用区 B 管控服务资源不足。新扩容。的ECS管控系统!启动时依赖的中间件服务部署在可用区C机房,导致较长时间内无法扩容。ECS管控依赖的自定义镜像数据服务,依赖可用区C的单AZ冗余版本“的OSS服务,导致客户新购实例后出现启动失败的现象。

改进“措施:全网巡检,整体优化多“AZ产品:高可用设计,避免出现依赖OSS单AZ和中间件单AZ的问题。加强阿里云管控平面的容灾演练,进一步提升云产品高可用容灾逃逸能力。

原因分!析:故障发生后阿里云启动对客。钉群、公告等通知手段,由于现场冷机处理进展缓慢,有效信?息不够。Status Page页面信!息更新不及时!引发客户困惑。

改进措施:提升故障影响和客户影响的快速评估和识别拉取能力。尽快上线新版的阿里云服务健康状态页面(Status Page),提高信息发布!的;速度,让客“户可以更便捷地了解故障事件对各类产品服务的影响。

这个事故的主要原因,就是因为制冷设备整整10个小时不能恢复工作,机房升温太快,工程师为了保护数据,只能逐步关机。

次!要原因是,在关机后还是有某个包间因为温度”过高导致喷淋,装、置启动。手机和电脑不能进;水都“已经是常识了,服务器上淋了水那还得了?

再次原因,就是阿里云香港Reigon的架构设计,同样没有遵循自己提到的「全链路多可用区的业务架构设计」,新扩容的ECS管控;系统启动;时依赖的中间件服务、部署在可用区C机房,导致可用区C一旦宕机,扩容服:务也启,动不了。相信后续阿里云一定会全网巡检,整体优化多可用区?高可用设计,避免“制造单点故障,类似依赖OSS单AZ和中间件单AZ的问题,再次出现?就说不过去了。

第四?个原因,是对于云服、务来说,高可用架构能够保障是某几台物理服务器(ECS、OSS、RDS)因为故障“宕机时,原来的应用可以漂移到同一个AZ(可用区)的其他服务器上,保证服务的连续性和数据的可用性。但是原有复杂的分布式架构在一个AZ(可用区)整体出现网络、服务器最稳定的香?港:服务器、存储?全部下线!的时候,国内没。有厂”家敢于。承诺100%实现?全”量无伤漂移到其他可用区,或者其他机房的。

打个比方,如果把中国大陆看成一个CN可用区,那么当武汉或者上海出现疫情的时候,是能够把病人疏散到其他城市去治疗,缓解自身医疗压”力的。但是当举国上下都遭遇新;冠的时候,病人还能往哪:送?阿里云这次遭遇的是一个AZ(可用区)整体下线,里面近千个机、柜、上万台设备的数据,又能”切换到哪”里?

第五个原因,是对极小概率事件的应急预案,是没法考虑得那么、周详的,甚至完全考虑不“到。比如谁能提前考虑服务器被喷淋装置喷水导致损坏的场景?谁能考虑一个主备配置4+4的水冷机组,能够同时。出现故障,修好却需要10个小时?

第六个,原因,是对于一个;巨“型系统来说,有能力搞清楚里面所有的细节的总工程师,一定,在新“项目上,绝不:是去搞运。维浪,费人,才。其他的成员?都是分模块承担任务的,他们“只能选!择信,任其他”模块。例如搞“数据库(,RD、S、)的同学关注的:是支持跨区迁移,谁能考虑到跨区迁移依赖的反向代理竟然不是跨区高可用:的,结果大部分数据库成功迁移了,但是香港可用区C一旦宕。机,依赖这个反向代理的的数。据库就迁移不了。

阿里云宕机的主要原因是机房主备水冷机组共用了同一”个水路循环、系统,存在单点故”障,修这个就用了10个小时。然而这个机房还只”是阿里、云租的。查了一下阿里云香港C区所在的?机房,应该是下图的香港粉岭安汇中心/安乐电话机房。(来自知乎@香港sim精神小伙)

这个机房原来是PCCW电讯盈科的,然后Vantage(数据中心园区提供商,其母公司是纽交所上市公司,代码DBRG)在2021年刚刚收购了电讯盈!科的数据中心。

所以阿里。云也是倒霉,租了个机房还换了东家。换了:东家之后,最了解情况的中基层领导很可能已经被扫地出门了,Twitter不就是这样么?所以故障响应就会不及时。

修个水冷机组还要用10个小时,其中真正有效,的、时间就是排水补气的3小时,除此之外,定位原因怎么“要用?3个半小,时的?这个水冷机!组的服务商也挺废物“的。

定:位原因的3个半小时,就是设备维护商赶到现场的时间。一个重要数据中:心的冷机坏了,香港的设备维护上用了3个半小时才到达现场,这种服务水平和响应速度极不可靠,从深圳到广州也用不?了三个小时吧。

另外,解锁群控逻辑,手动启动4台冷机,竟然要用3小时32分,也说明,服务商的工、程师对:这个、系统根本都不熟,大概率是照着操作手。册现学现卖的。

2020年,微软Azure位于美国东部的数据中心发、生服务中断,持续”六小时。微软披露说,冷却系统故障是导致这次停机的原因,发生故障的楼宇自动化控制导致气流减少,随后整个数据中心的温度峰值阻碍了网络设备的性能,使计算和存“储实“例无法访问。但是微:软的信息披露没有阿里云这一次这么。翔实,这一?点还是要给阿里云的实事、求是点个赞。

2021年11月,网易游?戏机:房大规?模服务器宕机,原因同事、是机房过“热,空调重新开机也没有解决问题。但幸好这只是游戏服务器,玩家是“可以接受的。但是大陆的服务更到位,网易的宕机只:用了3小时就恢复了。

2022年夏天,伦敦的谷歌云及甲骨文数据中心出现制冷系统故障,导致数据中心气温升高,产生宕机。甲骨文的是系统自动采取保护措施关闭作业,于是业务宕机;谷歌的是温度过;高导致存储故障,引起虚拟机?宕机,然后谷歌也关闭了一部分机器。

所以根据《建筑设计防火规范》GB50016规定,重要机房、配电房是需要做气体自动灭火,这是中国大陆的规定。

但是我国的国标之。间也有冲突,比如根据《《数据中心设计规范》GB 50174-2017》,只要数据中心的系统在其他数据中心内有承担相同功能的备份系统时,也可以:设置自动喷水灭火!系统。这个规范的主编单位是中国电子工程设计院。

我在2010年参与了苏州国科数据中心Tier-I!V机房项目,当时是东北亚最。高端的机房,那时候!我们用的就”是;七氟丙烷气体灭火。参见《运营环境 苏州国科数据中心》

为什么要用对人体有微毒性的七氟丙烷灭火,而不是用干粉、气水雾或”者喷淋方“式灭火呢?因为电子设!备就、没有不怕水的,干粉也会对设备造成伤害。顺口再说一“句,国外声称他们重视员“工”生命,所以,建议少用这!种有毒的气体灭火方式。这方面很多公司都参考了美。国消防协会。NFPA的标准,国际某个;头部的云厂商也有不少这类设?计。

我参与的项目还是经受住了考验,2022年10月13日,苏州国科、数据中心A2栋“建筑屋顶备?用冷却塔起火,半小时后。扑灭,但是建筑内的苏州超算中心数据机房安然无恙,数据、没受影响,说明”气体灭火还是极有必要!的,要不然超算中心就无了。

当然,气体灭?火也有”弊端,比如对?空间有要、求,大于3600平方就达不到消防效果,这些、在国标里:都有提;及。此外、气体的储,备量也是有限制的。

这个机房原来是PCCW电讯盈科的,也是资深数据中心。运营商,真的会这。么离谱么?《电讯盈科PowerBase方案》里面也写的非常,清楚,数据中心对制冷机组、供电机组全“年无休监控。现在看来,制冷机组的“监控明显”失灵,反而是机”房先升温告警,然后才找!到了制冷机组的问题。

虽然”这次故障的源起是机房。但硬件设备:的能力和可靠性是有限的,这就?是为什么有云计算的原!因。我认为,我们需“要提升数;据中?心设。施的可靠性,但不应该只专注于此。云计算不应当如此严重的依赖于单个机房,阿里云更应该做“的是提升云产品的稳定性,加强整!个AZ层面。的灾备演练。

IDC圈盘点了近几年的”前十大数据中心。灾难事故,《盘点:近年数据中心十大灾难事件_、机房_火灾_服务器》,包括2020年韩国SK公司数据中心火灾,影响了3.2万“个服务器;2021年3月,欧洲云计算巨头OVH在法国的数据中心严重火,灾,一共4座数据:中”心,有一座被“完全烧毁。导致法国360个政府、企业与公。共事业网站直接瘫痪。

2021年,河南。多机房因汛情断电,还有位于河南的数据中心出现机房进水情况;2022年谷歌数据中;心电气爆炸,影响了40多个国家。的1338台服务器。这种事一篇稿、子都写不下。

所以,重要应用和数:据,请务必做,到狡;兔三窟,一定要:充分考虑云主机的单点故障,做好;多可用区的高可!用,做好数据?的容灾和备!份;千万不要全盘相信连锁:型的自动化操作。

在极?端情况下,全自动化操作容易导致出现多米诺骨牌一”样的连锁反应。比如这次阿里云香港机房的冷机就是群控启动的,死活就启动不起来。因为再完备、再安全、再可靠的自动化。方案,哪怕平时运转非常正“常,赶上寸劲和巧合,总会出?现无法预计的问题。

人体的设计也有这种Bug,当免疫系统在体内杀新冠病毒杀疯了的时候,他才不会管人体是否受得了,直接烧?到42度,或者免;疫风暴走起。反正新冠病毒总得!死,但是人会不会死,免疫系统不在乎。

自动喷淋灭火系统也是,反正只:要温度过高我就;要喷水,我的任务是保?证火被扑灭了,但是物理服务器进水会不会损坏,自动喷淋灭火系统不在乎。特斯拉也是,他的自动控制系统只负责接管车辆驾驶,至于是不是刹!车失败,会不。会造成“人员伤亡,自动。控制系统不在!乎。

我的群晖NAS有100T的容量,其中有?5T工作文档数据,算是我十五年来攒下。的命根子。两个月之前,我在三天里连续。坏”了两块硬盘,真的是吓出一身冷汗;我做了Raid5,如果只坏一块盘,数据是可以恢复的;但是如果同时坏了两块盘,那我事务的数据就全game over了。

在这件事情之后,我直接搞了个同城灾备和异地容灾。同城灾备是我买了一块16T的硬盘,接在群晖:NAS上,把我?的重要数据每日备份;异地容灾就是一年几百块买了阿里云盘,映射成WebDAV香港服务器2h2g,也是每天备份我的重要数据,这样才能保证数。据可靠性。

对于应用服务来说,一定要考虑”好安全性,比如反亲和性,两台虚拟机不要放在同一台物理机上;比如做好镜像备份和容器的编排,在异地设置好备份,保证必;要的时候可以快速在异地拉起容器;比如做好数据库的异步、同步,基本保证数据的一致性,在应用里不要直接写死?数据?库的IP地址,还是要用域名指向香港和记机房服务器出租。

比如2019年。3月,腾讯云上海南汇机房的光缆被施、工挖断,等于所;有网络都不?通了,暖暖、QQ 飞车,王者荣耀,吃鸡等 90 多个服务、受到影响,这种问题就属于意?外,也没法问责云厂商。

所以,如果老板问为什么要花。这么多资金和人力来搞容灾,那就可以告诉老。板,不管是谷歌?云、甲骨文、微软云、阿里云、还是、腾讯云,全都出过“故障,只要:是服务,就有不,可用、的时候,所以!靠谁不:如靠自己。像阿里云?这次故,障中,在架构?层面设计了多可用区高可用方案的客户,就完全没有受到影响,当然,安全;是需要!额外成本的。

每个公司都是自己业务应用和数据的第一!责任人,不应该也不能把希望全部寄托在云厂商身上。

比如2021年3月,云厂商:OVH在?法国的、数据中心起火之后,游戏《?Rust》表示,25台欧洲服务器完全损毁,没有备份,数据无法被修复。你说这个数据丢失的主责是云厂商OVH,还是游戏运营商呢?像阿里云香港机房本月的可用时间大约是98%左右,也会按照规则赔偿25%的月费用,但是用户的业务”稳定和数据安全,能全部依赖于供应商么?当然不能。

阿里云这一次;的信息披露,算是这么”多家云!厂商中最坦“诚、最详尽的了,也是给各个企业一个充分的经验借鉴,让大家在容灾方:案设计时,除了保证应用和数据的高可用,还要考虑中间件”的高可用;除了考虑自身的架构设计,也要考虑租赁的数据中心的制冷和防火设计者有没有脑血栓

毕竟人生中充满了黑天鹅事”件,我们除了积极“应对风、险,还能怎么办呢?狡兔务必三窟就是唯一的答案。最稳定的香港服务器香港和记机房服务器出租

© 版权声明
THE END
喜欢就支持一下吧
点赞9 分享
评论 抢沙发
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情代码图片