Author | Yao Jie (myself Columbia) Ali cloud platform container cluster management senior technical experts
REVIEW : Alibaba technology worth people proud of the 2019 Alibaba Cloud on dual-core systems 11 100% cloud-native ways, the perfect support 54.4w peak flow and 268.4 billion turnover. Massive computing power behind the transaction is carried container from technology integration and perfect dragon bare metal.
Clouds form on a machine resource group
Ali Baba 11 uses three double pentad architecture, in addition to mixing two section units, the other three units are cloud. Dragon models big promotion after 618,99 validation, performance and stability has been greatly improved, can a stable support dual 11. Dual 11 this year three transactions cloud unit, based on 100 percent of bare metal dragon, dragon core transaction electricity supplier cluster size has reached tens of thousands.
Dragon architecture
Ali cloud ECS virtualization technology after three generations, is a former second-generation Xen and KVM, Dragon Alibaba self-development of the third generation of ECS virtualization technology products, it has the following four technical features:
- ECS VMM and storage and network control, and the calculated virtual disposed separately;
- Further evolution to virtualized computing Near
Metal Hypervisor; - VMM accelerated by storage and network IP services dedicated chip;
- And pool elastic support bare-metal and virtual machines ECS production.
In short, the Shenlong virtualization overhead network / storage of the FPGA hardware accelerators to offload a card called MOC, decreased by about 8% of the original ECS computing virtualization overhead, through large-scale manufacturing MOC card cost advantages, smoothing the Dragon overall cost overhead. Dragon class physical characteristics of the machine, may be secondary virtualization, so that for the evolution of new technologies leave enough space for the use of some of the various virtualization technologies, such as Kata, Firecracker, etc. become possible.
Before the mass migration to the Dragon architecture in Alibaba double 11, by promoting the validation 618/99 large, we found that container group run electricity supplier instead of 10% to 15% better performance than non-cloud physical machines in a cloud on the dragon, this makes us very surprised. After analysis, we find that mainly because of virtualization overhead to the MOC has been offload card, Dragon CPU / Mem is no virtualization overhead, and after each container on a cloud running on the Dragon are exclusive ENI elasticity card, performance obvious advantages. While each container an exclusive disk storage cloud ESSD blocks, up to one million IOPS single disk, SSD cloud disc than 50 times faster than the performance of the non-local cloud SATA disk and SSD. This also allows us a firm determination to support the large-scale adoption Dragon double 11.
+ + Kubernetes container Dragon
All in Cloud era in enterprise IT infrastructure is being remodeling, and native cloud has become the shortest path to release the value of cloud computing. 2019 Alibaba cloud on double 11 to 100% cloud-native way of core systems, server-based Dragon, lightweight cloud-native container and compatible with the new ASI scheduled Kubernetes of (alibaba serverless infra.) Scheduling platform. Wherein the container is running Kubernetes Pod Dragon blend with bare metal, Pod service delivery container as a section, running on the dragon instance.
The following is running on the morphology Pod Dragon:
- ASI Pod runs on Dragon bare metal junctions, the network virtualization and storage virtualization offload to the independent hardware node MOC card, and the FPGA chip acceleration technology, storage and network performance are more than ordinary physical machine and the ECS; MOC a separate operating system kernel, can be independently assigned CPU core and TDC (storing process) as the AVS (network processing);
- ASI Pod by the Main container (the main tank), operation and maintenance of the container (star-agent side-car containers) and other auxiliary container (e.g., a Local cache container application) configuration. Pod shared network namespace within the container through Pause, UTS namespace namespace and PID (ASI closed shared namespace PID);
- Pod 的 Main 容器和运维容器共享数据卷，并通过 PVC 声明云盘，将数据卷挂载到对应的云盘挂载点上。在 ASI 的存储架构下，每一个 Pod 都有一块独立的云盘空间，可支持读写隔离和限制磁盘大小；
- ASI Pod 通过 Pause 容器直通 MOC 卡上的 ENI 弹性网卡；
- ASI Pod 无论内部有多少容器，对外只占用独立的资源，例如 16C（CPU）/60G（内存）/60G（磁盘）。
大规模神龙运维
2019 年 双11 云上核心交易的神龙集群规模已达到数万台，管理和运维如此大规模神龙集群极具挑战，这其中包括云上各类业务实例规格的选择、大规模集群弹性扩缩容、节点资源划分与管控、核心指标统计分析、基础环境监控、宕机分析、节点标签管理、节点重启/锁定/释放、节点自愈、故障机轮转、内核补丁升级、大规模巡检等能力建设。
下面就几个领域细化展开：
实例规格
首先需要针对不同类型业务规划不同的实例规格，包括入口层、核心业务系统、中间件、数据库、缓存服务这些不同特性的基础设施和业务，有些需要高性能的计算、有些需要高网络收发包能力，有些需要高性能的磁盘读写能力。在前期需要系统性整体规划，避免实例规格选择不当影响业务性能和稳定性。实例规格的核心配置参数包括 vcpu、内存、弹性网卡数，云盘数、系统盘大小、数据盘大小、网络收发包能力 (PPS)。
电商核心系统应用的主力机型为 96C/527G，每个 Kubernetes Pod 容器占用一块弹性网卡和一块 EBS 云盘，所以弹性网卡和云盘的限制数非常关键，此次电商上云，神龙将弹性网卡和 EBS 云盘的限制数提高到 64 与 40，有效避免了 CPU 与内存的资源浪费。另外对于不同类型的业务，核心配置也会略有差异，例如入口层 aserver 神龙实例由于需要承担大量的入口流量，对 MOC 的网络收发包能力的要求极高，为避免 AVS 网络软交换 CPU 打满，对于神龙 MOC 卡里的网络和存储的 CPU 分配参数的需求不同，常规计算型神龙实例的 MOC 卡网络/存储的 CPU 分配是 4+8，而 aserver 神龙实例需要配置为 6:6；例如对于云上混部机型，需要为离线任务提供独立的 nvme 本盘实例。为不同类型业务合理规划机型和规格，会极大程度的降低成本，保证性能和稳定性。
资源弹性
双11 需要海量的计算资源来扛住洪峰流量，但这部分资源不可能常态化持有，所以需要合理划分日常集群与大促集群，并在 双11 前几周，通过大规模节点弹性扩容能力，从阿里云弹性申请大批量神龙，部署在独立的大促集群分组里，并大规模扩容 Kubernetes Pod 交付业务计算资源。在 双11 过后，立即将大促集群中的 Pod 容器批量缩容下线，大促集群神龙实例整体销毁下线，日常只持有常态化神龙实例，通过大规模集群弹性扩缩容能力，可大幅节约大促成本。另外从神龙交付周期而言，今年上云后从申请到创建机器，从小时/天级别缩短到了分钟级，上千台神龙可在 5 分钟内完成申请，包括计算、网络、存储资源；在 10 分钟内完成创建并导入 Kubernetes 集群，集群创建效率大幅度提高，为未来常态化弹性资源池奠定基础。
核心指标
对于大规模神龙集群运维，有三个非常核心的指标可以来衡量集群整体健康度，分别是宕机率、可调度率、在线率。
云上神龙宕机原因通常分为硬件问题和内核问题。通过对日宕机率趋势统计和宕机根因分析，可量化集群的稳定性，避免出现潜在的大规模宕机风险出现。可调度率是衡量集群健康度的关键指标，集群机器会因为各种软硬件原因出现容器无法调度到这些异常机器上，例如 Load 大于 1000、磁盘出现压力、docker 进程不存在，kubelet 进程不存在等，在 Kubernetes 集群中，这批机器的状态会是 notReady。2019 年 双11，我们通过神龙宕机重启与冷迁移特性，极大提升了故障机轮转效率，使神龙集群的可调度率始终维持在 98% 以上，大促资源备容从容。而 双11 神龙的宕机率维持在 0.2‰ 以下，表现相当稳定。
标签管理
随着集群规模的增加，管理难度也随之变大。例如如何能筛选出 "cn-shanghai"Region 下生产环境，且实例规格为 "ecs.ebmc6-inc.26xlarge" 的所有机器。我们通过定义大量的预置标签来实现批量资源管理。在 Kubernetes 架构下，通过定义 Label 来管理机器。Label 是一个 Key-Value 健值对，可在神龙节点上使用标准 Kubernetes 的接口打 Label。例如机器实例规格的 Label 可定义 "sigma.ali/machine-model":"ecs.ebmc6-inc.26xlarge", 机器所在的 Region 可定义为 "sigma.ali/ecs-region-id":"cn-shanghai"。通过完善的标签管理系统，可从几万台神龙节点中快速筛选机器，执行诸如灰度分批次服务发布、批量重启、批量释放等常规运维操作。
宕机分析
对于超大规模集群，日常宕机是非常普遍的事情，对宕机的统计与分析非常关键，可以甄别出是否存在系统性风险。宕机的情况分为很多种，硬件故障会导致宕机，内核的 bug 等也会导致宕机，一旦宕机以后，业务就会中断，有些有状态应用就会受到影响。我们通过 ssh 与端口 ping 巡检对资源池的宕机情况进行了监控，统计宕机历史趋势，一旦有突增的宕机情况就会报警；同时对宕机的机器进行关联分析，如根据机房、环境、单元、分组 进行归类，看是否跟某个特定的机房有关；对机型、CPU 进行分类统计，看是否跟特定的硬件有关系；同时 OS 版本、内核版本进行归类，看是否都发生在某些特定的内核上。
对宕机的根因，也进行了综合的分析，看是硬件故障，还是有主动运维事件。内核的 kdump 机制会在发生 crash 的时候生成 vmcore，我们也对 vmcore 里面提取的信息进行归类，看某一类特定的 vmcore 关联的宕机数有多少。内核日志有些出错的信息，如 mce 日志、soft lockup 的出错信息等，也能发现系统在宕机前后是否有异常。
通过这一系列的宕机分析工作，把相应的问题提交给内核团队，内核专家就会分析 vmcore，属于内核的缺陷会给出 hotfix 解决这些导致宕机的问题。
节点自愈
运维大规模神龙集群不可避免地会遇到软硬件故障，而在云上技术栈更厚，出现问题会更为复杂。如果出问题单纯依靠人工来处理是不现实的，必须依赖自动化能力来解决。1-5-10 节点自愈可提供 1 分钟异常问题发现，5 分钟定位，10 分钟修复的能力。主要的神龙机器异常包括宕机、夯机、主机 load 高、磁盘空间满、too many openfiles、核心服务（Kubelet、Pouch、Star-Agent）不可用等。主要的修复动作包括宕机重启、业务容器驱逐、异常软件重启、磁盘自动清理，其中 80% 以上的问题可通过重启宕机机器与将业务容器驱逐到其他节点完成节点自愈。另外我们通过监听神龙 Reboot 重启与 Redepoly 实例迁移两个系统事件来实现 NC 侧系统或硬件故障的自动化修复。
未来展望
2020 年 双11，阿里巴巴经济体基础设施将会 100% 基于 Kubernetes，基于 runV 安全容器的下一代混部架构将会大规模落地，轻量化容器架构会演进到下一阶段。
在此大背景下，一方面 Kubernetes 节点管理将会朝向阿里巴巴经济体并池管理方向发展，打通云库存管理，提升节点弹性能力，根据业务特性错峰资源利用，进一步降低机器持有时间从而大幅降低成本。
在技术目标上，我们会采用基于 Kubernetes Machine-Operator 的核心引擎，提供高度灵活的节点运维编排能力，支持节点运维状态的终态维持。另一方面，基于完整的全域数据采集和分析能力，提供极致的全链路监控/分析/内核诊断能力，全面提升容器基础环境的稳定性，为轻量化容器/不可变基础设施架构演进提供极致性能观测与诊断的技术保障。
《不一样的 双11 技术：阿里巴巴经济体云原生实践》
双11 的 2684 亿成交额背后是对一个个技术问题的反复尝试与实践。
这一次，我们对云原生技术在 双11 的实践细节进行深挖，筛选了其中 22 篇有代表性的文章进行重新编排，整理成《不一样的 双11 技术：阿里巴巴经济体云原生实践》一书。
We will bring you a different double original 11 cloud technology highlights:
- Dual 11 large scale cluster K8s practice, problems encountered and solutions in detail;
- Cloud original biochemical best combination: Kubernetes + + Dragon container, to achieve 100% technical details on the cloud core system;
- Dual 11 Service Mesh ultra-large-scale ground solutions.
"Alibaba Cloud native micro-channel public number (ID: Alicloudnative) focus on micro service, Serverless, container, Service Mesh and other technical fields, focusing popular technology trends in cloud native, cloud native large-scale landing practice, do most understand cloud native developers technology public number. "