第一期Tech Talk 会议内容整理

10月12日，由UCloud主办的首期Tech Talk在沪举行，Tech Talk是UCloud面向用户做深度技术交流的首次尝试，会议分为云硬盘、虚拟网络、云主机三个议题方向。深度技术分享之外，三位讲师也通过互动沟通为UCloud用户答疑解惑。
议题一：云硬盘架构升级和性能提升详解
云盘为云服务器提供高可用、高可靠、持久化的数据块级随机存储，其性能和数据可靠性尤为重要。UCloud根据以往的运营经验，在过去一年里重新设计了云盘的底层架构，在提升普通云盘性能的同时，完成了对NVME高性能存储的支持。UCloud块存储研发部负责人彭晶鑫作为开场分享，从IO路径优化、元数据分片、支持NVME等技术维度着手，详细讲解了UCloud云硬盘的架构升级和性能提升策略。
IO路径优化
过去，IO读写需要经过三层架构，请求首先通过网络，访问proxy代理服务器（proxy主要负责IO的路由获取、缓存、读写转发以及IO写操作的三份复制），最后到达后端存储节点。老的架构里，每一次读/写IO都需要经过2次网络转发操作。

为了降低延时，优化后的方案将proxy负责的功能拆分，定义由client负责IO的路由获取、缓存，以及将IO的读写发送到主chunk当中，由主chunk负责IO写的三份复制。架构升级之后，IO的读写只需经过两层架构，尤其对于读IO而言，一次网络请求可直达后端存储节点，其时延平均可降低0.2-1ms。
元数据分片
分布式存储会将数据进行分片，从而将每个分片按多副本打散存储于集群中。老架构中，UCloud支持的分片大小是1G。但是，在特殊场景下（如业务IO热点局限在较小范围内），1G分片会使普通SATA磁盘的性能非常差，并且在SSD云盘中，也不能均匀的将IO流量打撒到各个存储节点上。所以新架构中，UCloud将元数据分片调小，支持1M大小的数据分片。
分片过小时，需要同时分配或挂载的元数据量会非常大，容易超时并导致部分请求失败。这是由于元数据采用的是预分配和挂载，申请云盘时系统直接分配所有元数据并全部load到内存。
例如，同时申请100块300G的云盘，如果按1G分片，需要同时分配3W条元数据；如果按照1M分片，则需要同时分配3000W条元数据。

为了解决性能瓶颈，团队采用放弃路由由中心元数据节点分配的方式。该方案中，Client 端和集群后端采用同样的计算规则R（分片大小、pg个数、映射方法、冲突规则）；云盘申请时，元数据节点利用计算规则四元组判断容量是否满足；云盘挂载时，从元数据节点获取计算规则四元组； IO时，按计算规则R（分片大小、pg个数、映射方法、冲突规则）计算出路路由元数据然后直接进行IO。通过这种改造方案，可以确保在1M数据分片的情况下，元数据的分配和挂载畅通无阻，并节省IO路径上的消耗。

对NVME高性能存储的支持
NVME充分利用 PCI-E 通道的低延时以及并行性极大的提升NAND固态硬盘的读写性能和降低时延，其性能百倍于HDD。目前常用的基于NAND的固态硬盘可支持超10W的写IOPS、40-60W的读IOPS以及1GB-3GB读写带宽，为支持NVME，软件上需要配套的优化设计。

首先，传统架构采用单线程传输，单个线程写 IOPS达6W，读IOPS达8W，难以支持后端NVME硬盘几十万的IOPS以及1-2GB的带宽。为了利用NVME磁盘的性能，需要将单线程传输改为多线程传输，系统定期上报线程CPU以及磁盘负载状态，当满足某线程持续繁忙、而有线程持续空闲情况时，可将选取部分磁盘分片的IO切换至空闲线程，目前5个线程可以完全发挥NVME的能力。

此外，在架构优化上，除了减少IO路径层级以及更小分片外，UCloud在IO路径上使用内存池、对象池，减少不停的new delete，同时尽量用数组索引，减少查询消耗，并避免字符串比较以及无谓的拷贝，最终充分地发挥NVME磁盘性能。
议题二：灰度发布在UCloud虚拟网络中的应用
第二个议题是由技术专家徐亮讲解如何利用ServiceMesh技术在虚拟网络控制面以及利用可编程交换机在转发面实现灰度发布。
ServiceMesh实现控制面灰度
在控制面，早期灰度发布采用APIGW的方式实现。APIGW通常仅部署在用户流量的入口，完全灰度发布就需要完整地部署两套系统。但在微服务化的时代，任何一个微服务发生变更都需要完整地部署两套系统，这不仅成本高且严重影响产品变更速度。ServiceMesh以类似于将APIGateway部署到本地，同时提供集中化控制的方式，解决了这些问题。
UCloud的轻量级ServiceMesh平台基于Istio，继续使用Envoy代理，修改Pilot在保留完整的DSL支持的基础上实现了脱离K8S运行。
因此网络团队对Pilot做了高度订制，从而更能满足自身的需求。

• 订制方案一：按账号灰度。在GRPC或者HTTP请求中添加⾃自定义Header x-ucloud-routeby，x-ucloud-routeby采用Cookie的编码格式，在其中包含账户信息，配置Envoy根据该Header进行策略路由。
• 订制方案二：采用显式代理而不是IPTables透明引流的方式和Envoy集成，支持HTTP 1.0、HTTP 2.0和gRPC。在配置了Envoy的Proxy Port情况下，通过Envoy接入ServiceMesh；如果配置域名且没有配置Envoy的Proxy，则自动采用ETCD gRPC naming and discovery的方式； 如果配置IP地址和端口，则直连指定地址；

订制方案三：采用docker-compose管理container实现sidecar。新方案中仍然采用container的方式打包和部署微服务，但采用Host的网络方式简化了现存服务的网络通信方式。通过采用docker-compose管理container实现sidecar，实现了一个简单的服务管理、版本管理、集群管理、路由策略管理层，为集群中的每台Node（VM或物理服务器）生成docker-compose配置文件，从而部署和管理每台Node的服务。
可编程交换机实现转发面灰度
在转发面灰度的方案选择上，团队采用了可编程交换机（基于Barefoot Tofino芯片）来实现灰度网关，替换普通交换机实现强灰度能力。
灰度网关最大提供64个100G的接口提供6.4T带宽，PPS性能可达4400兆，延迟为us级别，能够很好支持网络宽带的高性能要求。灰度网关可以提供：一致性哈希ECMP的能力；可以基于任意定制字段（包括内层虚拟网络地址以及租户ID）计算哈希；在计算哈希前优先应用灰度规则，可以根据任意字段定制灰度规则，最小粒度可以做到按TCP流来灰度。
转发面灰度示例
有了上述这些新工具，可以通过部署新的策略实现更加细粒的灰度发布，具体方案为：可编程交换机BGP宣告集群VIP引流，根据选择字段计算一致性哈希后将流量量分发给后端服务器，并按照选择字段（VNI、源地址、目的地址）配置灰度规则。
灰度步骤如下：

• 按VM的粒度将流量量切换到灰度后端服务器器
• 切换完成后立刻自动回归测试，根据路由表自动生成监测地址列表，并Ping检测网络互通性
• 测试通过则逐步增加灰度的VM地址
• 直到整个VPC的流量量全部切换到灰度后端服务器器
• 再切换一个新的VPC，直到所有分片内的VPC都切换到新的灰度后端服务器
• 完成灰度发布

议题三：云主机连续快照备份设计解析
最后是邱模炯总监介绍秒级自动连续快照的后台设计细节。
OpenStack快照方案的不足
在早期的云主机快照方案中，UCloud尝试采用了OpenStack的internal snapshot和external snapshot两种方案，也是KVM虚拟化自带的快照方案，这两种方案均比较复杂，难以符合云平台的需要。
内置快照（internal snapshot）是原始磁盘和快照耦合在同一个文件，实现复杂，不方便进行快照的操作，此外这种方案不支持raw格式，合并麻烦， 对性能有较大影响。
外置快照（external snapshot）的快照文件和原始磁盘文件分离， 进行快照操作后，原始磁盘映像将处于“只读”状态，新的写操作都会写入到新的快照文件中。这种快照方式解决了内置快照的大部分问题，也是目前KVM虚拟化主流快照方案。但是实现仍然复杂，对性能有影响。设想1000个快照的情况下对性能的影响， 快照的管理。
不管内置快照还是外置快照，都需要用户理解较多快照原理才能操作，而且对源云主机是有影响的，另外备份也受云主机所在软硬件环境的稳定性影响。考虑到这些方面，UCloud采用了完全不同的做法，重新设计了独立的快照备份系统。
UCloud数据方舟快照方案
虚拟化层本身足够复杂且使用麻烦，而紧耦合的设计无法在不影响源主机的前提下又能追求快速恢复和足够细粒度的快照点 。复杂和紧耦合，是影响快照性能和体验的根源。
数据方舟可以自动进行秒级连续快照，无需用户触发也无需用户管理这些快照。恢复速度也足够快，1T硬盘可以达到10分钟级别。用户无需理解复杂概念，运维也无需理解复杂的虚拟化。数据方舟背后的基本设计理念是，极简体验和异构解耦。

实时IO与异构解耦
为了免去用户定期制作快照的繁琐事项，让数据可以恢复到任意一秒，UCloud通过记录实时IO的方式，将虚拟机所有的写IO按顺序的引入流方式，同步到数据方舟的备份集群中，数据恢复时，再将这些IO流反推回来，恢复到本地盘或者云盘里面，实现备份集群与本地盘的异构解耦。这种方案下快照对原有业务路径侵入小，不影响源主机的运行，且备份独立可靠，不受原有软硬件约束，容易运维。
但是，秒级快照会造成较大的吞吐量，假如1000台云主机以10MB每秒的速度写入1年，那么将会产生近300P的数据量，这将产生大量的存储量且几乎无法恢复出快照盘。
海量随机IO和巨大存储量优化
UCloud通过IO合并以及 SSD扛住随机IO，另外通过分层存储和定期预合并的方式，来减少实时IO引来的存储量。首先，将实时的IO用SSD记录下来，但在真正的存储硬盘中，将数据分成秒级、小时级、天级和基准数据。只由第一层去接纳实时的IO流，下面四层做分层和合并。这样存储量理论上只跟云主机盘的大小相关，成正比例的关系，而不是和云主机产生IO的速度成比例关系。

快速恢复优化
存储服务器一般会采用特殊配置，每台服务器会配置12块硬盘，12块盘理论上的读写速度是单块12倍，因此，可以将这些数据按磁盘寻址范围，进行分片，每个粒度的数据按分片分布式存储于容量存储层的集群上。
那么，在恢复快照结果的时候，就可以对前述秒/小时/天/base等各层数据的各自分片进行并发合并。通常恢复一个1T盘大小，在物理上多台服务器的几十块硬盘同时读取，所以恢复速度很快，可以达到10分钟级别。
恢复出来的快照结果需要转存回业务存储上，通常是云盘集群和本地盘。

• 对于云盘集群，由于云盘也是分片的，可以把数据方舟的分片并发写到云盘集群，极大降低快照结果写入云盘的耗时。对于本地盘，无法利用分布式集群的能力，本地盘则采用了copy on read模式，无需整个快照结果写完就可以启动云主机。

以上就是Tech Talk第一期的内容回顾。Tech Talk后面也会继续举办，欢迎参加。