Efficient Memory Disaggregation with Infiniswap

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

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

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

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 原理浅析

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

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,导致重复的内存开销。


kata 系统架构解读

https://github.com/kata-containers/kata-containers/tree/main/docs/design/architecture

https://github.com/kata-containers/kata-containers/tree/main/docs/design

1. 整体架构

如下图:

kata-containers 的核心 binary 就2个:

  1. containerd-shim-kata-v2,对应源代码目录 src/runtime
  2. kata-agent,对应源码目录 src/agent

containerd 实现了 cri 协议,可以天然直接无缝对接到 kublet 上,而 containerd-shim-kata-v2 实现了 containerd 的 shim-v2 协议,直接实现了对 kata-agent 以及 hypervisor 通讯的封装。


TMO – Transparent Memory Offloading in Datacenters

论文: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等基础服务贡献


dCat – Dynamic Cache Management for Efficient Performance-sensitive Infrastructure-as-a-Service

核心前提:只要独占 cache size 足够大,业务的性能是可以得到保证的
we can conclude that whether CAT can provide perfor mance isolation between workloads is highly dependent on the size of the dedicated cache

思路:基于CPI的动态反馈,来动态调整每个容器的独占 cache 和共享 cache 容量,达到每个容器都可以得到很好的性能

难点:预测 wss(业务真正需要的cache size)。这里面有一个容量失效和冲突失效的问题,冲突失效和容量失效是 有一定的overlap的,冲突失效是因为多条cache数据映射到同一个cache line上,导致的miss,这个问题会导致wss难以预估。这个问题没有什么太好的思路,所以dCat的思路是基于feedback来动态扩大cache size

dCat 的状态机是这样的:
简单来说,是一个实时feedback的过程
Reclaim:初始状态
Recevier:减少cache退化,增加cache会提升
keeper:减少cache退化,增加cache不提升
Donor:减少cache不退化,增加cache不提升
Streaming:增加cache不断提升

系统流程:

备注:

  1. baseline是基准性能,但是每个阶段,都有不同的 baseline,会动态变化 Baseline performance is only defined for a specifi workload phase, so it has to be determined again at every phase change.
  2. Categonize workloads,就是识别容器的状态,对应到上面的几个状态机上,Reciver、keeper、Doner

问题:

  1. 论文中CAT隔离,使用的是qpos,qpos是CAT的前身,只支持core级别的cache隔离,也就是cache隔离相当于是通过绑核实现的

Software-defined far memory in warehouse-scale computers

论文重点

  • 采用软件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数据行为:业务的数据冷热是会变化的,比如不同该时间段