当前位置:云计算云计算与数据中心 → 正文

“多活”不易! —— GitHub事件在前,青云推出真正的多活是良机也是挑战!

责任编辑:jcao 作者:曹建菊 |来源:企业网D1Net  2018-12-05 09:44:35 本文摘自:企业网D1Net

“多活”不易!活得有质量更不容易!当然,这里的“多活”并非生物学概念,一般常将“本地多活”与“异地灾备”拿来做比较。但最近“多活”被提起来的次数越来越多,也越来越被重视,GitHub事件成为多活这个技术领域的标志性事件。

多活不易 GitHub标志性事件回顾

GitHub在全球拥有2800万用户,托管着5700万个代码仓库,Python、Ruby on Rails等绝大多数开源项目托管于此。被戏称为“全球最大的同性交友社区”的GitHub,却在2018年10月22日时出现了一次大规模的故障,导致服务中断时间24小时,这24小时故障导致绝大部分互联网企业的技术人员无法正常工作,影响很大。

事实上,GitHub搭建了自己的多活系统,而10月份的故障,正是因为其多活系统出现故障而导致的。GitHub两个机房之间的网络出现中断,服务发生切换后,多活系统考虑不全,导致系统发生脑裂,两边数据不一致,为了保证用户数据的一致性,只能直接停服,用了24小时时间恢复数据,最终导致了服务中断。

GitHub这样一个实力强劲的技术网站,多活业务也出现了如此大的故障。由此可见,实现真正的多活并不容易。

什么是真正的多活?

不容易的多活技术,催生的不仅是这个市场,更缘于业务对多活的需求。对客户而言,业务的可靠性、连续性、稳定性才是真正的诉求。

无论是设备还是硬件,便一定会有故障的几率。电饭煲发生故障便无法做饭;热水器发生故障就没法洗澡;数据中心里需要依赖的硬件也有故障的可能性,服务器故障时会影响这台服务器上运行的所有虚拟主机;交换机故障会影响数据中心网络。即便是整个数据中心,也有可能因为断电、起火、雷击等原因发生整体故障。

因而,多活应该是基于多个数据中心的多活,而且最终的多活一定是业务的多活,可以7*24小时保证业务在线,同时必须规避任何的单点,包括一个数据中心内部的单点甚至是整个数据中心宕机的单点。

青云QingCloud运营副总裁林源在接受企业网D1Net记者采访时指出:“部署多活,一定要理解多活的目的是什么?增强系统的可靠性、提升业务的连续性,使业务在运行过程中不受任何故障和灾难的影响。这是多活的价值所在,这才是真正的多活。”

多活的两大技术指标:RTO与RPO

多活有两个重要的技术指标:一是RTO(业务恢复时间),二是RPO(数据的丢失量)。

这两个指标无论对于互联网企业还是对于银行等核心业务,都至关重要。业务恢复时间决定了客户体验,数据的丢失量决定了数据的质量,因此,这两个指标都必须趋近于0,同时需要保证是7*24小时在线的可用服务。

多活场景探讨

并不是所有的场景都需要多活,因为多活需要付出一定的成本。需要多活的业务,一是这个业务很重要,它故障后会影响公司业务,导致客户资金受损;二是这个业务面向广泛的客户,影响较大。一般包括如下几类:

第一种是大规模线上运营业务,比如电商网站、微信、微博等,业务中断是不能忍受的,因为每天都有大量的客户在使用这个服务。双十一的每秒宕机就可能损失几十万笔交易,这样的业务要求零中断,必须保证业务的连续性。

第二种是银行、保险、重型制造等场景,银行IT架构需要符合银监会的规定,需要有两地三中心。即两个城市,三个数据中心的部署。

多活不易  “不易”的深层原因探讨

多活不易,除了我们看到类似GitHub这样的技术企业都很难搞定的表象外,更深层次的原因在于它是一个系统工程,既需要技术,也需要人才储备,还有各种大额成本投入等等因素。

首先,构建多活系统成本极高,比如银行两地三中心的业务至少需要在两个城市投入三个机房,三个机房需要有网络连接,在每个机房里要投入大规模的硬件,业务在两个机房都要部署,成本极高。

其次,多活系统需要招聘和培养专业人员;

第三,需要花费大量的时间,挑机房、铺光纤、铺网络。

实际上,要做好支撑业务的多活,首先需要在数据中心、网络、数据、负载等层面做准备,其次,作为一个复杂的系统工程,只要底层任意一个环节出现问题,便有可能造成整套多活系统的崩溃。

青云多活以服务形式交付多活能力

据林源介绍,青云多活推出的Region服务,可以从基础设施、基础架构(IaaS)、分布式应用等各个层面提供多活基础架构服务,以服务形式交付多活能力,从而让客户以更低的成本、更低的门槛部署他们自己的多活业务。

第一,青云将从基础设施层持续投入,青云现有三个大区提供多活服务:北京3区、广东2区、上海1区。北京3区最早便上线了多活Region架构。

第二,青云将在基础架构(IaaS)给用户提供足够多的通用组件,当用户部署业务时,会需要负载均衡器、网络、公网带宽等。青云提供的负载均衡、网络和公网本身均是多活架构。

第三,青云将在应用层或者PaaS层给用户提供支撑,通过青云的MySQL Plus(基于MySQL的数据库服务)、MongoDB,为客户提供数据库服务,让用户部署业务更简单。

同时,青云拥有全方位一体化的交付能力,不仅提供公有云服务,也可以提供混合云和私有云的交付。在公有云上,青云可以交付多活的基础设施;在混合云架构下,也可以利用青云的SD-WAN骨干网加上私有云和公有云统一架构,给客户提供混合云架构下的多活基础设施。

写在最后

事实上,GitHub事件在前,让多活解决方案提供商及服务商惊出一身冷汗的同时,也倒逼各供应商从技术与流程入手,更加努力为客户提供一个更加稳定的服务。这对行业而言无疑是从教训中长进。

青云QingCloud推出的真正多活Region架构服务,是良机也是挑战!

关键字:青云云计算多活

本文摘自:企业网D1Net

x “多活”不易! 扫一扫
分享本文到朋友圈
当前位置:云计算云计算与数据中心 → 正文

“多活”不易! —— GitHub事件在前,青云推出真正的多活是良机也是挑战!

责任编辑:jcao 作者:曹建菊 |来源:企业网D1Net  2018-12-05 09:44:35 本文摘自:企业网D1Net

“多活”不易!活得有质量更不容易!当然,这里的“多活”并非生物学概念,一般常将“本地多活”与“异地灾备”拿来做比较。但最近“多活”被提起来的次数越来越多,也越来越被重视,GitHub事件成为多活这个技术领域的标志性事件。

多活不易 GitHub标志性事件回顾

GitHub在全球拥有2800万用户,托管着5700万个代码仓库,Python、Ruby on Rails等绝大多数开源项目托管于此。被戏称为“全球最大的同性交友社区”的GitHub,却在2018年10月22日时出现了一次大规模的故障,导致服务中断时间24小时,这24小时故障导致绝大部分互联网企业的技术人员无法正常工作,影响很大。

事实上,GitHub搭建了自己的多活系统,而10月份的故障,正是因为其多活系统出现故障而导致的。GitHub两个机房之间的网络出现中断,服务发生切换后,多活系统考虑不全,导致系统发生脑裂,两边数据不一致,为了保证用户数据的一致性,只能直接停服,用了24小时时间恢复数据,最终导致了服务中断。

GitHub这样一个实力强劲的技术网站,多活业务也出现了如此大的故障。由此可见,实现真正的多活并不容易。

什么是真正的多活?

不容易的多活技术,催生的不仅是这个市场,更缘于业务对多活的需求。对客户而言,业务的可靠性、连续性、稳定性才是真正的诉求。

无论是设备还是硬件,便一定会有故障的几率。电饭煲发生故障便无法做饭;热水器发生故障就没法洗澡;数据中心里需要依赖的硬件也有故障的可能性,服务器故障时会影响这台服务器上运行的所有虚拟主机;交换机故障会影响数据中心网络。即便是整个数据中心,也有可能因为断电、起火、雷击等原因发生整体故障。

因而,多活应该是基于多个数据中心的多活,而且最终的多活一定是业务的多活,可以7*24小时保证业务在线,同时必须规避任何的单点,包括一个数据中心内部的单点甚至是整个数据中心宕机的单点。

青云QingCloud运营副总裁林源在接受企业网D1Net记者采访时指出:“部署多活,一定要理解多活的目的是什么?增强系统的可靠性、提升业务的连续性,使业务在运行过程中不受任何故障和灾难的影响。这是多活的价值所在,这才是真正的多活。”

多活的两大技术指标:RTO与RPO

多活有两个重要的技术指标:一是RTO(业务恢复时间),二是RPO(数据的丢失量)。

这两个指标无论对于互联网企业还是对于银行等核心业务,都至关重要。业务恢复时间决定了客户体验,数据的丢失量决定了数据的质量,因此,这两个指标都必须趋近于0,同时需要保证是7*24小时在线的可用服务。

多活场景探讨

并不是所有的场景都需要多活,因为多活需要付出一定的成本。需要多活的业务,一是这个业务很重要,它故障后会影响公司业务,导致客户资金受损;二是这个业务面向广泛的客户,影响较大。一般包括如下几类:

第一种是大规模线上运营业务,比如电商网站、微信、微博等,业务中断是不能忍受的,因为每天都有大量的客户在使用这个服务。双十一的每秒宕机就可能损失几十万笔交易,这样的业务要求零中断,必须保证业务的连续性。

第二种是银行、保险、重型制造等场景,银行IT架构需要符合银监会的规定,需要有两地三中心。即两个城市,三个数据中心的部署。

多活不易  “不易”的深层原因探讨

多活不易,除了我们看到类似GitHub这样的技术企业都很难搞定的表象外,更深层次的原因在于它是一个系统工程,既需要技术,也需要人才储备,还有各种大额成本投入等等因素。

首先,构建多活系统成本极高,比如银行两地三中心的业务至少需要在两个城市投入三个机房,三个机房需要有网络连接,在每个机房里要投入大规模的硬件,业务在两个机房都要部署,成本极高。

其次,多活系统需要招聘和培养专业人员;

第三,需要花费大量的时间,挑机房、铺光纤、铺网络。

实际上,要做好支撑业务的多活,首先需要在数据中心、网络、数据、负载等层面做准备,其次,作为一个复杂的系统工程,只要底层任意一个环节出现问题,便有可能造成整套多活系统的崩溃。

青云多活以服务形式交付多活能力

据林源介绍,青云多活推出的Region服务,可以从基础设施、基础架构(IaaS)、分布式应用等各个层面提供多活基础架构服务,以服务形式交付多活能力,从而让客户以更低的成本、更低的门槛部署他们自己的多活业务。

第一,青云将从基础设施层持续投入,青云现有三个大区提供多活服务:北京3区、广东2区、上海1区。北京3区最早便上线了多活Region架构。

第二,青云将在基础架构(IaaS)给用户提供足够多的通用组件,当用户部署业务时,会需要负载均衡器、网络、公网带宽等。青云提供的负载均衡、网络和公网本身均是多活架构。

第三,青云将在应用层或者PaaS层给用户提供支撑,通过青云的MySQL Plus(基于MySQL的数据库服务)、MongoDB,为客户提供数据库服务,让用户部署业务更简单。

同时,青云拥有全方位一体化的交付能力,不仅提供公有云服务,也可以提供混合云和私有云的交付。在公有云上,青云可以交付多活的基础设施;在混合云架构下,也可以利用青云的SD-WAN骨干网加上私有云和公有云统一架构,给客户提供混合云架构下的多活基础设施。

写在最后

事实上,GitHub事件在前,让多活解决方案提供商及服务商惊出一身冷汗的同时,也倒逼各供应商从技术与流程入手,更加努力为客户提供一个更加稳定的服务。这对行业而言无疑是从教训中长进。

青云QingCloud推出的真正多活Region架构服务,是良机也是挑战!

关键字:青云云计算多活

本文摘自:企业网D1Net

电子周刊
回到顶部

关于我们联系我们版权声明隐私条款广告服务友情链接投稿中心招贤纳士

企业网版权所有 ©2010-2024 京ICP备09108050号-6 京公网安备 11010502049343号

^