云不得不聊的故事
货拉拉技术约 10 分钟货拉拉是较早一批使用云资源发展业务的企业。
当云服务器资源使用达到一定规模后，部分细节问题需要特别关注处理，可分为以下几个方面：
可用区
网络延迟、抖动
最新一代ECS 实例规格
多可用区使用
云服务器资源瓶颈
机房容量
ECS实例规格选用
ECS 聚合度
运维事件
计划内运维事件
非计划内运维事件
热迁移及冷迁移技术
LLC 争抢问题
货拉拉早期接触云平台其中一个1 Region ，只有A B 两个可用区，云上SaaS服务并不多，大多数服务都是通过ECS 自建。云平台经过一定时期发展，IaaS、PaaS、SaaS服务SLA逐步被认可，云平台可用区从2个可用区发展至现在的6个可用区。货拉拉也是随着云平台发展逐步使用多可用区以及部分中间件服务直接使用云平台PaaS及SaaS服务。货拉拉在2018年得到高速发展，需要大量的ECS 资源，货拉拉将部分业务接入了另外一朵云，形成了多云架构。下面以ECS 资源为例讲述货拉拉云服务器实践经验。
多可用区自建集群服务，需要注意各可用区网络延迟问题，平常各可用区延迟在3ms以内，不排除可用区网络抖动情况发生，服务本身健壮性需要测试好。
对延迟比较敏感的业务，云服务器在同一可用区延迟会比跨可用区延迟小。
通过云平台网络智能服务显示各可用区之间延迟。
可以通过监控了解可用区之间网络情况，如：SmokePing 监控网络延迟及丢包情况。
云平台可用区发展都是逐步发展的，其最新的ECS 架构及最新的ECS 机型，往往都是绑定最新的可用区。旧可用区想要使用最新的ECS实例，只能等云平台对旧可区技术改造后，才能采购到新一代ECS实例规格。
受机房容量及集群规模影响，同一Region及同一可用区的ECS 资源采购并不是无可止的，常常会遇到某规格的实例无法购买到，为了避免因ECS 资源不够影响业务发展，货拉拉有以下经验:
￮ 在公司需要做活动需要大量ECS资源的时候，提前一个月报备云平台，让其安排扩容或腾挪资源。
￮ 让云平台帮忙提前锁定部分某可用区及其所需的机型资源。
￮ 机型尽量选通用型资源，冷门机型其集群规模并不大，云平台扩容并不会多。
￮ 鸡蛋不要放在一个篮子里，某一个可用区资源不足，多可用区是一个选择。某一云资源不足，多云部署也是一个选择。
￮ 目前各云平台自推出了自研的ARM架构服务器，部分服务可以从X86架构更换至ARM，或者结合使用。
受云平台机房容量影响，ECS 集群无法扩容。当公司ECS 资源使用过大后，ECS聚合度过高问题就会出现。因云平台底层资源对于我们客户来说是黑盒，我们看不到，往往是通过宕机告警发现。如突然发现同一时间有多台ECS 实例同时宕机重启了，那基本可以确认所在NC（Node Controller 虚拟机所在的物理机） 实例过多问题导致。如果同一业务所有master 节点都在同一台宿主机上，那对业务影响是灾难级的。
为了避免这个情况发生，我们可以要求云平台按UID 维度对ECS 实例进行打散。除了要求云平台对ECS 进行打散以外，也可以使用以下几种方法避免同一业务聚合在同一台宿主机上。
要求云平台定期安排ECS聚合度巡检，如发现聚合度过高，要求进行打散。
服务使用多可用区进行部署，可尽可能避免同业务服务在同一台宿主机上。
使用阿里云部署集，可保障ECS 高可用。每个云平台名称有所不同，但使用策略大至相同。华为云为云服务器组，腾讯云为置放群组。
￮ 以阿里云部署集为例：
▪ 高可用策略
采用高可用策略后，部署集内所有ECS实例会在指定地域内严格分散在不同的物理服务器上。适用于需要将几台ECS实例相互隔离的应用架构，大幅降低服务不可用的几率。
▪ 部署集组高可用策略
该策略支持将部署集划分为最多7个分组，多台ECS实例可以根据实际需要分散部署在不同的分组中。不同分组的ECS实例会在指定地域内严格分散在不同的物理服务器上；相同分组的ECS实例不保障严格分散部署。
▪ 网络低时延策略
采用网络低时延策略后，部署集内所有ECS实例会集中部署到所在可用区内同一个网络拓扑范围内，降低网络互通的时延。此策略下可能会出现多台ECS实例调度到同一台物理服务器上的情况。在网络低时延策略下，无法保证高可用。
￮ 部署集创建：
￮ 部署集示例：
云平台ECS 运维事件发生是不可避免的，可总结相关经验避免业务受运维事件影响。
计划内运维事件是云平台发现ECS实例的底层软硬件服务存在可能导致ECS无法正常使用（比如宕机或性能受损等）的风险，提前告知用户。
用户在收到主动运维事件后，用户可以对该实例上的业务进行切流，然后在合适的时间通过重启或重新部署实例规避该实例面临的底层软硬件风险。
非预期运维事件指的是因系统错误或宿主机硬件故障类事件，无法提前告知用户，ECS被直接宕机重启冷迁移到其它健康物理机上。
6.3 运维事件处理
事件类型 | 是否提前通知 | 备份数据 | 是否需要重启服务器 | 后续动作 | 场景举例 |
热迁移 | 不会 | 不需要 | 不会重启服务器 | 热迁移虚拟机受损后，才会有告警提示，让客户观察业务是否有损 | 常见ECS 网络抖动 |
计划内运维事件 | 会 | 不需要 | 需要重启服务器 | 检查业务是否正常 | ALL |
非计划内运维事件 （宕机） | 不会 | 不需要 | 会重启服务器 | 检查业务是否正常 | ALL |
本地盘运维事件 | 会 | 需要提前备份数据，本地盘数据会清空 | 部分需要重启服务器 或重新部署 | 检查业务是否正常 | 大数据--CDH hadoop |
7. 云平台热迁移技术
热迁移是一种将运行状态的虚拟机从一个物理宿主机迁移到其它物理宿主机的技术。在迁移的过程中，虚拟机持续保持运行，虚拟机内部业务对虚拟机的迁移无感知，或者只感知到有一个非常小的业务中断时间（100ms-1000ms ）
• 以阿里云为例：
￮ 当物理宿主机机器故障了，ECS热迁移无损情况下不会有任可通知发出给客户。
￮ 当物理宿主机机器故障了，ECS热迁移有损会发出告警提醒客户ECS有抖动，提醒业务是否有受损。
￮ 当物理宿主机机器故障了机器故障了，ECS热迁移不成功，会发出计划内运维事件（提醒用户ECS 在什么时候会重启，用户可提前处理，冷迁移）。
￮ 当物理宿主机机器故障了机器故障了，ECS热迁移不成功，无法延迟处理，就会直接宕机重启，冷迁移。
虚拟机热迁移主要目的是保证服务不中断的同时， 将一个虚拟机在物理机之间进行移动，对于应用程序状态来说,，主要涉及到其CPU状态和内存中的运行状态。CPU状态的拷贝几乎可以瞬间完成，而内存的拷贝通常是一个相对比较长的持续过程，拷贝过程中，已经拷贝的内存可能会被重写。目前流行的内存拷贝技术。
预拷贝(Pre-Copy)
延迟拷贝(Post-Copy)
混合拷贝技术
……等
• 内存写入过高业务热迁移可能会失败。
系统运维中，需要使用热迁移技术的主要场景包含以下 3 种：
• 主动运维：物理机出现故障需要维修，但是这些故障并不影响系统的运行。此时，可以通过热迁移的方式，在将虚拟机迁移至其他物理机后，将该物理机下线维修。
• 负载均衡：当某个物理上出现比较明显的负载冲高时，通过热迁移的方式，将部分虚拟机迁移到其它空载的物理机上，从而降低源物理机的资源争抢。
• 其他需要对虚拟机进行迁移，但是又不希望重启影响虚拟机内部业务运行的场景。
￮ 某可用区架构升级等
￮ 如客户要求发起：ECS聚合度过高，需要进行打散操作。
￮ 如ECS 出现LLC（CPU 三级缓存争抢）问题，进行热迁移。
主动巡检宿主机有告警，将ECS热迁移到健康的物理主机上。
在进行热迁移之前，您需要了解相关限制条件。
• 只支持在同类型物理主机间进行迁移，且2台机器的软件版本（宿主机底层）必须完全一样。
• 对于使用了本地存储方案的VM，不支持热迁移。因为迁移到其它物理机后，无法再访问该存储。
使用了GPU/FPGA或者其他（直通/SRIOV）设备的VM，将不支持热迁移。
• 通过业内调研总结
8. LLC 争抢问题导致应用RT增高
在发现LLC 问题前，通过监控发现部分服务，会莫名其妙的RT 出现增高情况，总有1到2个节点CPU 比其它节点高10%~20%，在经过一段时间排查发现，该节点流量与其它节点一样，重启服务及重启ECS 都无效，最后只能踢除该节点，业务RT才恢复正常。
问题提交至云平台深入检查最后发展，同宿主机下其它公司ECS CPU三级缓存使用较高，影响到了同宿主机下的其它ECS。由此我们对LLC 争抢问题有了认识。
CPU 最后一级缓存 (Last Level Cache, LLC) = L3缓存。CPU 3级缓存是多核共享，很容易出现争抢问题。
• 部分节点CPU 升高，时间长了后，会导致整体应用(Response Time, RT)增高。需要摘除CPU异常节点后，RT才能恢复正常。
• CPU表现比其它节点高10%~20%，需要热迁移才能恢复。
￮ 在发生CPU 三级缓存争抢时，服务重启及ECS 重启，CPU 利用率无法降低到其它节点同水位。
￮ 如果物理机LLC 已经被其它ECS使用很多的情况下，不管你机器CPU 使用率是否高或低，LLC 命中率都会下降，这台物理机上的所有ECS CPU 利用率都会升高。
￮ 热迁移到较空闲的物理机上，CPU 可立刻恢复正常。
• 4C 8G 规格实例与32C 128G 规格实例机器放在一台物理机上，同样会发生LLC 争抢，高规格机型并不占优势。
• X86 Intel CPU 3级缓存是多核共享
• X86 AMD 三级缓存四核心共享
如X86 AMD EPYC （霄龙）7200
￮ CCD(Core Chiplet Die 核心复合芯片)由两个四核核心复合体组成(1个CCD= 2个CCX)
￮ CCX(CPU Complex)由四个内核和16mb L3缓存
• ARM 架构
如：阿里Yitian 710 单颗--128核，无超线程，独享物理核。
重算力业务在云平台环境下避免出现LLC 争抢问题，可以有以下选择。
• X86架构---AMD 机型优于Intel 机型
• X86架构对比ARM 架构，ARM 架构使用的是物理核，比X86架构有优势。
• 使用裸金属服务器，搭建的K8S容器环境，需要将LLC 敏感业务进行打散处理，避免影响其它业务。
• 做好业务监控，如集群各节点CPU 环比监控，出现差异就告警。
货拉拉会不定期与云商沟通交流，制定1年~3年目标，共同合作发展。