共计 4923 个字符,预计需要花费 13 分钟才能阅读完成。
导读 | 过去的几个月内,UCloud 对自身的云计算基础架构进行了全面升级,于日前宣布基础架构全面支持地域和可用区,并将可用区项目命名为 Sixshot。通过这两层的设计架构来组织云服务,可以为用户提供高可用的云服务。随着可用区的推出,用户可以获得更灵活的资源规划能力和更强大的容灾设计能力。 |
从 2014 年起 UCloud 开始致力为分布在各个地区的数据中心建设高可用、高带宽的同城环网,将北京的多个主力机房的内网互相打通;其后在完善环网之余,先后对华北、华南、华东、亚太等地的网络架构进行了升级优化,完成了各地的双星型 pop 点建设。这种设计理念充分考虑了机房内网连接的高速性、稳定性、冗余能力和可扩展性,之后各地只需选址新建机房并连入 pop 点即可。
此次 UCloud 可用区的设计,是在原有工作基础上进行了网络基础架构的系统性升级,相比原同城环网,内网表现更加高速稳定。与此同时,伴随着产品层面的系统级重构,可用区也提供了各云产品的跨机房内网互通能力。
地域(Region)是指根据地理位置不同将同一地区的云服务组成合集。目前,UCloud 全球共有 7 个地域,其中国内有北京一、北京二、浙江、上海、广东五个地域,海外两个地域分别设在香港和美国加州。
可用区(Availability Zones)则是指在同一个地域之内的一组数据中心群,即可用区是由多个数据中心组成,一个地域内一般会有多个可用区。可用区在设计上相互独立,是不同地点的数据中心,在物理和电力上都相互隔离,有独立的安全保障,单个数据中心的故障影响范围被隔离在单个可用区范围内。同时,同一地域内的可用区之间通过高速、稳定、低延迟的网络互相连接,内网互通。
为了实现多机房的容灾部署,按传统方式,企业往往需要增加额外的容灾机房,在计算、网络和存储设备上增加上千万元的成本。另外,企业还要解决机房间的专线部署和复杂的运维问题。这样的成本和复杂度是一般企业所难以承受的。
- 用户可以把应用部署在多个可用区中运行,实现高可用性的应用架构。即使某个可用区的基础设施发生故障(例如,实例硬件故障、存储故障或网络中断),部署在另一个可用区的应用可以不受影响、继续运行。
- 用户可以将业务中的同种资源(例如主机)随机地创建在两个可用区内,由于可用区间的内网通信延时只有约 1.5ms,当一个可用区故障后,另一个可用区的主机仍可不受影响地继续运行,从而保证了业务的持续性。
- 值得一提的是,随着基础网络的改造,跨地域的内网通信质量也获得了提升,例如使用 UCloud 提供的跨域内网通道,北京到广州地域的内网延迟仅约 30ms,这为建设两地三中心的容灾方案提供了物理上的保证。
可用区设计之初,UCloud 吸取了之前本行业内的一些经验教训,确保为用户提供更流畅的产品体验,着重体现了以下几点:
- 提供在原有产品上的无缝升级能力;
- 确保可用区的核心功能有出色的使用体验;
- 设计出解决用户痛点的特色功能,例如混合云的网元互通、共享带宽的自由分组等。
其中,产品的无缝升级能力一直是 UCloud 重点强调的设计理念,因为如此才能保证既有用户的权益,让他们随着 UCloud 的成长而不断获利。
以 EIP(Elastic IP,又称弹性 IP) 跨可用区漂移这个功能为例,AWS 和部分国内云服务提供商,虽然具有 EIP 跨可用区使用的能力,但为此需要申请专门的 EIP,并需要将原主机上绑定的 IP 销毁,再绑上新申请的 IP 方能达到目的。使用不方便之余,旧有 IP 也无法再找回;若有备案等原因导致 IP 无法替换,则原有资源就无法享受到 EIP 漂移的便利。
然而,UCloud 设计方案之初,便考虑了已有用户的立场和便利性,确保其存量 IP 都能自由使用 IP 漂移等所有可用区功能。防火墙的设计也是秉承着同样的理念。 如 UCloud 特色的共享带宽,原本只限定在单一机房内使用,随可用区上线,该功能也新增了自由编组能力,可以满足用户更加灵活丰富的使用场景。而存量的共享带宽,都可无缝的继续使用和扩展。
1.1 外网 EIP,支持跨可用区绑定
随着网络底层的重新设计,用户的外网 IP(EIP)可以在一个地域内的任何可用区使用。为了保证业务连续性,IP 地址经常有保留的必要(如备案要求或者应用调用需要)。当需要重新规划可用区间的资源分布时,外网 IP 支持从一个可用区的资源上解绑,并在另一个可用区内使用。
1.2 带宽管理,支持多个 EIP 跨可用区及自由分组
同时,UCloud 特有的外网 IP 带宽管理产品“共享带宽”的形态也有了很大的演进。共享带宽是一种多个外网 IP 共享网络带宽总量的带宽模式。相比每个 IP 需要单独指定和购买带宽,多 IP 共享带宽大大提高了带宽使用效率,节省了用户成本。
现在,新形态的共享带宽支持用户将一个地域内的所有 EIP 自由地分组计算。例如,可以将某 10 个 EIP 划分为一个共享带宽组,共享 50M 的带宽,其他 5 个 EIP 归属于另一个共享带宽组,共享 30M 的带宽。而对于核心业务使用的某 IP 地址,为了保证其带宽不被其余业务抢占,该 IP 仍可以使用独立的带宽计费方式。这种 UCloud 特有的独立带宽和共享带宽协同使用的模式,进一步地满足了用户多样的场景需求,保证了用户业务的稳定性,同时也降低了用户成本。
1.3 ULB 负载均衡,支持挂载跨可用区后端
一个地域内的网络设计,除了跨可用区的内网通信保障外,还提供了网络产品层面的高度灵活性。负载均衡(ULB)本次也支持了在一个地域内自由使用,ULB 支持同时挂载不同可用区内的后端实例,为实现跨可用区的资源平衡和容灾在技术上铺平了道路。
可用区和混合云方案结合,也可以产生 1 +1>2 的效果,创造更大的价值。UCloud 提供物理云、托管云、专线等多种云接入方式,支持用户创造公私结合的混合云方案,解决用户分步骤平滑上云的痛点。所以,在同一地域内(例如北京),UCloud 也提供了多个可供选择的托管云接入机房以及多个专线接入点,这些接入点都有完善的冗余和容灾设计。
在可用区未上线前,混合云的接入位置和公有云资源的位置存在一定的耦合关系,给用户使用带来了限制。例如,用户将自有服务器托管到 UCloud 北京 C 数据中心,则默认只能与北京 C 的公有云形成互通。这种混合云模式对用户业务扩展造成不便,若其在北京 D 又部署了公有云资源,则需要单独搭建转发集群,才能与 C 的托管云互通,增加了维护成本。
随着可用区上线,用户将混合云就近接入到任一位置,都能把其私有资源和该地域内所有可用区的公有云资源直接打通。这种一揽子解决的接入方案,提供了将混合云和公有云部署解耦的能力,大大减少了用户在上云过程中所耗费的精力和产生的顾虑。
传统方式的跨数据中心容灾,对用户而言是一个成本高昂且费事费力的任务。用户需要在两个数据中心都部署一套同样的系统,并通过数据中心间的专线进行数据同步等工作。对外则需要通过 DNS 解析等方式,在灾备时将业务从一处切换到另一处。
地域和可用区的产品特性,结合 UCloud 的跨域内网高速连接,可以为用户构建更高层次的容灾设计和完整的两地三中心解决方案。
由于 EIP 和 ULB 可以在地域级别存在,一个地域内可以部署一套 EIP 和 ULB,并以此固定地向外提供服务。ULB 后端可以挂载来自两个可用区的资源。因而可以将后端业务中使用的主机、数据库、内存缓存等分散地分布于多个可用区内,这样就构成了同城内双活的两个中心(生产中心和同城灾备中心)。这两个中心具有基本同等的业务处理能力,数据通过跨可用区自身的内网进行实时同步。日常情况下,两个中心可同时分担业务和管理系统的运行,并可切换运行或同时运行;灾难情况下,可在基本不丢失数据的情况下进行灾备应急切换,保持业务连续运行。
此外,UCloud 提供的跨域内网高速连接(UDPN),可以为相对地理位置较远的两个地域(如北京和广东)的公有云之间提供高速而稳定的内网连接。使用 UDPN 后,北京到广州的内网延迟可以稳定在 30ms 左右,而 UDPN 的成本比用户自建北京 - 广州的专线成本低很多,这为部署“两地三中心”中的异地灾备中心,创造了基础设施层面的条件。
同时,UDB 数据库产品支持跨可用区的数据实时同步能力,通过将主库和从库分别部署在不同的可用区内,支持业务节点和数据节点的热备能力;还可用通过跨域的内网连接实现多地的数据节点冷备。相比原来的集群,具备的指数级的容灾能力提升。
用户可以在另一地域,创建一套轻量级的灾备系统,并与主地域进行内网打通,备地域的数据进行跨地域的主从同步。当主地域发生故障时,备地域的系统可以按既定计划拉起,并暂时提供服务。
UCloud 可用区带来的更多更具体的特性提升,可参见下表。
云重度用户,其有大量的服务器资源,因历史原因和系统设计,无法全部上云,为享受云计算技术的红利,他们选择 UCloud 的混合云方案,其自有的服务器接入 UCloud 北京的混合云接入点,同时在北京的 B、C、D 等多机房部署了公有云业务,两者通过北京地区的内网环网打通。
出于其自身业务和管理的需要,中手游托管云采用分批分项目的方式,分别接入了北京 B、C、D 等地的托管接入点,公有云资源也平均分布于北京 B、C、D 等处。这就造成北京 B 机房的托管云和北京 C 机房的公有云、北京 D 机房的托管云和北京 B 机房的公有云通信等需求。为应对这类通信需要,中手游使用了 UCloud 为其搭建的转发集群,但是转发集群存在一定的运维成本,而且流量有突发等情况,原有集群面临转发能力限制和扩容需求。且随其项目的增多,集群管理的复杂度也相应上升。UCloud 可用区的推出,很好地帮助中手游解决了该痛点。
伴随着网络架构的升级,混合云和跨可用区的公有云直接可以通过内网高速互通,吞吐率和稳定性直接通过 UCloud 基础架构进行保障,其性能不再依赖转发集群,也让中手游的运维成本降低至零。
可用区整体上线也体现了 UCloud 强大的运营系统和运营能力。为支持可用区,UCloud 现有的所有产品和基础设施都需要进行大幅度的重构。而 UCloud 现已为 3 万多家企业级用户提供公有云服务,上面运行着海量的服务和数据。如何在不影响用户业务的情况下,进行全系统级的复杂重构?这就要求整个底层的业务运营系统设计,能满足无缝、透明的要求。唯有如此,底层功能大大小小的每一次迭代,才不会影响用户的数据安全和业务安全。
除运营系统设计外,UCloud 还拥有专业的运营团队和丰富的运营经验。 在功能实际上线前,预先设计了详细周密的发布计划,经过了数次发布演练和压力测试,此外还有监控分析系统,不断实时监测实施状况并反馈,并分析潜在风险点。
而数万量级的用户,根据业务特性、资源种类、地域分布等,被细化拆分成上百组用户组。这些群组按事先设计的计划表,按序分批上线功能。上线前后,售前售后团队保持全程跟踪,保证用户最快的适应和使用功能。
除保证功能升级对用户业务无影响外,UCloud 还通过合理的技术方案,努力让原有的存量机房都具有产品持续升级的能力。确保不同阶段建设的机房,尽管底层的物理实现存在差异,但都能在产品层面上向同一个方面不断演进,维护原有用户的利益。
云计算是一个飞速发展的行业,新产品新特性不断涌现,UCloud 依靠强大的云平台运营能力,让每位用户安全、便利的享受云计算带来的好处,跟上云时代的步伐。
可用区体现了云服务商的更高层次的基础设施设计能力,是一个 IaaS 服务商发展到一定规模和阶段后必然的选择。UCloud 通过完善复杂的系统设计和细粒度灰度控制,向用户安全平滑地交付了可用区这一重大功能,为用户基于云平台搭建更灵活更可靠的业务系统提供了底层保障。
![post-qrcode](https://www.xgss.net/wp-content/uploads/2023/07/二维码-微信公众号256x256.jpg)