UCloud可用区的设计理念及功能图文详解
| 导读 | 过去的几个月内，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通过完善复杂的系统设计和细粒度灰度控制，向用户安全平滑地交付了可用区这一重大功能，为用户基于云平台搭建更灵活更可靠的业务系统提供了底层保障。
免费提供最新Linux技术教程书籍，为开源技术爱好者努力做得更多更好：https://www.linuxprobe.com/
