分类： 数据中心 & 云计算

Efficient Memory Disaggregation with Infiniswap

Posted on by remaper in 内存池化

1. 概要

infiniswap 可以实现把一个机器的内存 swap 到另外多个机器上（1对多）
和其他实现相比，infiniswap 可以把开销做到很小，并且故障容错能力更强
  1. A transparent remote paging model for virtual machines @2008
  2. Swapping to remote memory over Infiniband: An approach using a high performance network block device @2005
  3. 还有一堆20+年前的论文（参考意义不大）

2. 架构设计

infiniswap 的组件其实就2个，非常简单：
  1. infiniswap-bd：一个虚拟的 swap 设备，其后端是远程内存
  2. infiniswap-daemon：管理本机对外提供的 remote memory（包括内存到虚拟地址的映射，等等）
这2个组件每个机器都会部署，类似于 daemonset
而且有个比较有意思的地方是，infiniswap 是去中心化的，它并没有一个中心式的管理组件（你看zombieland，中心式的管控组件就挺多的）
如下：
0

Zombieland: Practical and Energy-efficientmemory disaggregation in a datacenter

Posted on by remaper in 内存池化
Zombieland: Practical and Energy-efficientmemory disaggregation in a datacenter

1. 概要

zombieland 从硬件视角，实现了CPU&内存的池化
和传统的专门做内存池化的系统不太一样，zombieland 做到了把cpu和内存彻底的分离，甚至连供电都是分开的，它可以做到把cpu的电源关掉的情况下仍然可以让内存提供远程访问服务
（有点牛逼，这不得把主板设计都改了？）
通过这个设计，zombieland 实现了 86% 的能效提升

2. 设计实现

zombieland 的思路是实现服务器的 ”半关机“，增加了一个新的 ACPI 状态，叫 Sz，处于这种状态的服务器叫 zombie
这种 Sz 服务器，它的内存是可以被远程访问的，但是功耗只比 S3 状态增加了 15%，而且这种设计对硬件的改动很小
然后 zombieland 给 hypervisor 实现了2种远程内存扩展：RAM ext 和 Explicit swap device，允许 hypervisor 把虚机的冷内存卸载到远程内存上，或者用户可以显式的把内存swap到远端

2.1. 理论收益

和其他方案对比：
1）Server-centric architecture
0
能效：Total Energy Consumed = 2.1 × Emax.

AIFM – High-Performance, Application-Integrated Far Memory

Posted on by remaper in 内存池化
AIFM 提出一种在用户态完成 swap 的方案，相比传统的内核态（虚拟内存）的方案，实现了：
  1. 更低的延迟：相比 fastswap，有6倍吞吐的提升
  2. 更高的灵活性：用户可以显式指定一块内存是local还是far（指向 remote memory）
0

1. 一些背景

1) OS swapping and far memory
之前对 swap 以及 far memory 相关的研究，大多都是在内核态的，由于内核态的 swap 都是 4k 粒度的，对于一些随机大量的小object场景，会带来很多性能问题
另一方面，如果你要依赖一些应用的信息（比如访存的行为、访存策略、内存热点）去做性能优化，这也是做不到的（madvise有一些近似的功能，但是不够）
为此，AIFM 提出了一种object级别的，可以访问远端内存的，类似于c++弱指针的一种新型指针
2）Disaggregated and distributed shared memory
当前大多数 Disaggregated memory 相关的实现，都要求数据中心具备高速互联的能力（但是现在很多数据中心其实还不具备这个能力），AFIM 提供了一种软件级的解决方案
另外一个问题是，传统的 far memory 系统里面，一份数据需要被多个 host 共享，这就要解决很复杂的数据一致性问题（同时带来了很大的性能开销）
AIFM 简化了这个问题， far memory 中的数据只属于一个 host

Distributed Shared Persistent Memory

Posted on by remaper in 内存池化
NVM：Next-generation non-volatile memories，一种非易失性，按字节寻址，低延迟（接近DRAM的读写性能），新型设备
Hotpot 应该是第一个支持 PM 的 DSM 系统，传统的 DSM 都没有为 PM 做过真正意义上的支持。17年的Octopus也算是一个支持 PM 的 DSM 系统，但是它只有文件系统接口
Octopus: an RDMA-enabled DistributedPersistent Memory File System
因此，作者实现了一个支持 PM 的（所以叫DSPM区别于传统的DSM），内核态的DSM 系统，然后把一个 NoSQL 数据库部署到了 Hotpot 上，性能提升了3倍

1. 场景

作者发现 Tensorflow 和 PowerGraph 这类应用程序，在多个线程之间有大量的共享数据。
但是这个地方我没太理解，DSM 系统对同机多线程之间的数据共享是没有价值的，因为多线程本来就共享一个地址空间，数据只有一份
唯一的解析可能是，dsm 可以让这类系统，实现跨node级别的线性扩展

2. DSPM 的挑战

First）应该提供什么样的接口来同时支持直接内存访问，以及数据持久化？同时如果支持直接内存访问，会带来一个新的问题，怎么保证“指针”在不同机器上的一致性？
Second) 如何有效地组织DSPM中的数据以提供良好的应用程序性能？
Finally) 分布式缓存的数据一致性和可靠性怎么解决？

vm template 原理浅析

Posted on by remaper in Kata & Firecracker
vm template 是一种加速虚机创建、节省vm内存的技术。

1. 背景

我们之所以说虚机是强隔离的，主要是因为虚机有独立的内核。不同vm之间的进程是完全运行在自己的内核空间里面的，相互不可见
引起虚机的启动，需要引导一个完整的内核，以及完整的os
这在传统的虚机场景下，问题不大，一个物理机上启动的vm数量可能就十几个
但是容器场景下，kata-containers，容器粒度要远小于虚机，一个物理机可能启动上百个kata容器，每个kata容器都有自己独立的内核，这样算来，开销就不小了
由于每个kata容器的内核，操作系统镜像，都是相同的。如果虚机之间的内核、操作系统镜像所占用的内存能够共享，这样就能省掉不少内存。
于是，vm template 技术出现了

2. vm template 原理

主要是利用了linux内核fork系统的cow原理（copy on write）
cow：fork一个新的进程，会把原进程的内存空间全部copy一份，但这个copy只是一个引用。只有新进程在写这块内存区域的时候，才会发生真正的copy操作
所以 vm template 的核心思路是：通过一个事先创建好的最小 factory-vm，包含公共的内核、操作系统镜像、以及kata-agent。创建kata容器的时候，从factory-vm fork一个vm出来，然后再通过热插拔的方式，调整vm的规格以符合kata容器的要求
但是这里有一个问题是，template vm 的规格是固定的，但是 Pod 的规格不是固定的，所以必须通过 Pod vm 的热插拔 & resize 能力来实现 vm 规格的调整

RunD – A Lightweight Secure Container Runtime

Posted on by remaper in Kata & Firecracker
RunD – A Lightweight Secure Container Runtime for High-density Deployment and High-concurrency Startup in Serverless Computing
rund 是阿里提出的一种新的轻量级容器运行时技术。
不过目前从论文内容来看，更多是一些技术点的优化，而不是架构层面的创新

1. 设计目标

实现 serverless 场景下，pod的高密度部署、高频、高速启动
高密度部署：随着机型规格越来越大，比如 AMD milan 就有256核，可以部署数千个 pod
高频：faas 和 batch job 等负载，每天上百万的实例创建量，上亿次系统调用
高速：faas 场景的毫秒级启动，极致弹性

2. 问题分析

kata 容器的技术栈：
0
启动一个 kata 容器，首先需要通过qemu（或者其他hypervisor，比如fire cracker）拉起一个虚机，然后还需要再虚机内启动一个agent，来实现完整的oci语义
基本过程如下：
0

2.1 并发启动的开销

（1）在准备容器rootfs的可写层时有很长的耗时：同时启动200个kata container，准备rootfs需要耗时207ms，会产生4500iops和100MB/s的IO带宽，带来很高的cpu overhead
（2）同时启动多个kata containers时，涉及到host侧cgroup的创建及维护，在内核层面，凡涉及到cgroup 操作，需要持有全局粒度的自旋锁，导致cgroup 的创建及维护是一个串行过程

2.2 高密部署的瓶颈

（1）虚机（guest系统 + kata-agent + guest kernel）耗损
容器不是虚机，但是实现安全容器就必须依赖虚机。容器的规格一般都是很小的，比如内存100m 0.1vcpu，但是这个规格对虚机来说太小了，都起不来。所以为了能开一个100m的容器，你就得把虚机开到200m甚至更大，这就产生了 overhead
对于kata-qemu，一个内存规格为128MB的kata-containers，其内存overhead可以达到168MB;当部署密度从1提升到1500时，平均每个内存规格为128MB的kata-containers，其内存overhead 仍然会有145MB。
0
对于小内存规格的kata容器，guest kernel image所占内存占用了很大的比重。AWS数据：47% 的function computer的内存规格时128MB，Azure数据：90%的应用内存规格小于400MB。
（2）rootfs 内存耗损
rootfs基于块的主流解决方案在Host和Guest中生成相同的Page Cache，导致重复的内存开销。

TMO – Transparent Memory Offloading in Datacenters

Posted on by remaper in 混部技术
论文：https://www.pdl.cmu.edu/ftp/NVM/tmo_asplos22.pdf
内存是数据中心最大的瓶颈。百度也是如此，因为内存不足，导致大量机器cpu空闲但是利用率无法提升的主要原因
这篇论文的思路和 google 的 software-defined far memory 思路几乎是一样的，都是把 colder memory 卸载到 cheaper memory 上
google 论文是19年发表的，实际上项目2016年就已经上线了
facebook 论文是22年发表的，线上已经运行一年多。另外，论文里也隐约的提了，facebook就是在google的基础上做的，但是发现效果和 google 说的不一样，于是做了很多改进。如果我们要落地，也会有类似的问题。

1. INTRODUCTION

下文所有对比的地方，我简称：
  1. google的方案，g-swap
  2. facebook的方案，tmo
现状：
cpu的发展速度比memory要快
随着AI算法的发展，业务对内存的需求正在快速膨胀
硬件上，nvm和nvme ssd等技术的出现，Non-dram cheaper memory 开始越来越多的被使用
还有 CXL 这种 non-DDR memory bus 技术，可以接近 DDR 的原生性能
方向：内存分层技术，不管是 google 的 software-defined far memory 也有还是 facebook 的 TMO（透明内存卸载），本质上都是将低频访问的内存卸载到低速设备上
With memory tiering, less frequently accessed data is migrated to slower memory.
g-swap的一些问题：
  1. 核心是压缩
  2. 非常简单
    1. 好处：不用解决异构这些复杂的问题（感觉解决了？做了负载分类）
    2. 坏处：不利于最大化的 memory-cost saving
  3. promotion rate 的设定依赖离线分析
  4. 所有应用的 promotion rate 是一样的。没有考虑不同业务对内存的敏感性，以及不同分层设备的 performance（后者其实有简单的考虑，具体的 P% 的设备就取决于 far memory 到 near memory 的性能表现）
    1. g-swap的观点：为了保证应用程序的性能，memory offloading 应该控制在一个预先配置好的比例下面
    2. tmo的观点：facebook 对它们部署规模最大的程序，发现，在一些高速设备上，提高 memory offloading 比例，可以提高性能。 –> 反人类假设？？
0
为了解决这些问题，facebook 提出了 tmo 方案，优点：
  1. 核心是卸载（但是卸载的backend 支持 compressed memory pool，也支持 NVMe SSDs）
  2. 不需要离线分析，依赖 PSI 的反馈，直接单机决定不同的 offloading 比例。不依赖app的任何先验知识（g-swap的方案就有一个冷启动问题，新app默认不回收任何内存）
  3. PSI accounts for application’s sensitivity to memory-access slowdown（这里其实是比较误导的，facebook认为psi观测出来的内存延迟一定是对业务敏感的，但是实际上不同的业务对延迟的敏感性是不一样的，简单来说这个是充分不必要条件）
收益空间：20-32% 收益，百万服务器，其中7-19%由应用贡献，13%由sidecar等基础服务贡献

Software-defined far memory in warehouse-scale computers

Posted on by remaper in 混部技术

论文重点

  • 采用软件zswap的方式进行cold memory数据压缩
  • google的业务有32%的memory数据是cold memory，其中20%的数据是可压缩的，压缩效率中位数为3倍，那么TCO有4.2%的收益
  • 该压缩策略保证了SLA不受影响：通过cold memory和promotion rate的模型保证
  • 压缩解压缩的开销不大，完全可以接受
  • 使用ML进行autotuner

1 introduction

问题：
  • 随着资源的scaling，一个资源瓶颈会影响整个scaling的TCO。
  • DRAM成为scaling的瓶颈，memory的TCO减少逐渐放缓
  • 随着大数据workload的普及，主流的in-memory computing的方式加速了DRAM的需求
方向：far memory（介于DRAM和DISK之间的存储）
far memroy需要解决的问题：
  • 不影响应用的性能
  • 应用数量多且种类多样，不能对每个应用单独优化（不现实），需要对业务透明且robust的机制，有效使用Far memory
  • 动态的cold数据行为：业务的数据冷热是会变化的，比如不同该时间段

 

Autopilot: workload autoscaling at Google

Posted on by remaper in 混部技术

autopilot 算是 google 今年混部领域最重磅的论文了吧

论文原址：https://dl.acm.org/doi/pdf/10.1145/3342195.3387524

在传统的数据中心里，资源超售最简单的方式就是把闲置资源回收再分配，total = total – allocated + reclaim

有时候，业务为了应对峰值流量（特别是互联网服务这种有明显流量特征的），都会购买多一些冗余资源。但是这些冗余资源会因为各种原因，不是那么准确。比如流量随着时间流逝会逐渐发生变化、或者用户过于焦虑

用户填的Quota永远都是不准的

这会带来一些问题：

  1. 集群资源浪费，由于Quota不准，导致机器资源被大量闲置和浪费。比如 Quota 分配出去了100c，但实际使用了10c
  2. 集群负载不均衡，同样两个机器，分配率一样，但是实际使用差别很大，对混部性能的影响就不一样

为了解决这个问题，google设计了autopilot，尝试通过自动的校准用户的 Quota，实现一定程度的超售，降低成本

Borg: the next generation

Posted on by remaper in 数据中心 & 云计算

论文原址：https://dl.acm.org/doi/pdf/10.1145/3342195.3387517

这篇论文主要是分析了google内部8个集群的workload数据，并和2011年（1个集群）的数据集做了一些对比，以此来跟踪数据中心这几年的workload变化

相较于2011年的workload数据，可以发现，无论是资源模型、负载分布、混部密度、系统架构，等，都有很大的变化。这里面的很多内容和想法，和我们过去做过的还有正在做的，都不谋而合

1. 资源模型

2011年的时候，google的资源模型只有4个优先级，分别是：

  1. Free tier：免费资源，基本上不承诺任何SLA，通常是研发用来跑一些测试任务
  2. Best-effort Batch (beb) tier：同样不承诺SLA，低优先级资源，一般用来跑离线任务
  3. Production tier：生产级别，承诺SLA，一般用来托管在线服务，比如以下 long runing service
  4. Monitoring tier：监控级别，具有最高级别的SLA，用来运行数据中心的基础系统