NetWork

工业级大规模RDMA技术杂谈 & 《RDMA杂谈》专栏索引

《RDMA杂谈》专栏索引 工业级大规模RDMA技术杂谈

非常好的资料，扫盲RDMA用

Deploying User-space TCP at Cloud Scale with LUNA

链接 需要用户态tcp的原因

1. 存储集群内可以rdma，但计算集群和存储集群之间可能跨pod，RDMA默认流控为PFC，跨Pod通信，存在PFC风暴和死锁等隐患;且计算节点硬件可能不支持rdma
2. 内核tcp性能不达标（一次4KB的RTT大概需要50us，而EBS的SLO就是100us），不够scale，存在datacenter tax
3. 方便做RTC

Luna的几个特点

1. 作为一个libary，集成到用户进程中
2. share nothing，利用网卡多队列技术，按照核心划分流量。没有work steal这种复杂的机制。
3. 兼容内核TCP
4. 线程模型上，Run to Completion
5. 内存模型上，构建用户态内存分配器，实现全路径zero copy

Luna 4KB的RTT latency大概在20us（kernel 为50us）

From Luna to Solar: The Evolutions of the Compute-to-Storage Networks in Alibaba Cloud

链接 Luna相比于Kernel，能节省CPU，但随着硬件的发展，它对CPU的 消耗还是不可忽视，比如说Luna需要吃掉4个core来跑满200Gbps网卡（Kernel需要12个）；再加上计算节点上的存储Agent（做路由，加解密，CRC等），会消耗客户机的不少CPU。 Solar就将协议栈和Agent Offload到了FPGA中（相当于DPU）。基于RoceV2,传出层协议为UDP，拥塞控制算法为HPCC

Storage

S3: A Scalable In-memory Skip-List Index for Key-Value Store

链接

1. Skip-List顶层节点称为Guard Entry，限制其的总大小，使其能被L2 Cache住。
2. 其余节点称为Data Entry，一个Data Entry可以容纳若干kv，Data Entry内key无序，Data Entry间有序i（看论文的图就明白
3. Guard Entry按照线程来shard写入，第i个Guard Entry和i+1个Guard Entry之间的数据更新由一个线程负责

CloudJump: Optimizing Cloud Database For Cloud Storage

链接

PolarDB在PolarFS上运行存储引擎，相比于Aurora给计算层定制一个log存储层，PolarFS更像是一个通用的云存储系统，文章主要提出了在云存储之上构建单机存储引擎的挑战和优化手段。 云存储跟本地SSD相比，latency更高，但吞吐、带宽和并行度都更高，所以在设计存储引擎的时候，需要利用其优点，避其短板

1. Aries-style的集中式日志导致io并行度很低，并将云存储的高latency直接暴露在前台写入中。优化成page partition log，并且每一路log都有多个writer，因为一个文件的多个chunk可能分布在不同存储节点，并行写文件也可以提高并行度。
2. io要分优先级，其中log的写入和page的读取是前台流量，优先级最高。log读取和脏页下刷优先级较低
3. pre-fetch的收益相比基于ssd要更大
4. 细粒度锁。因为io慢了，所以按理来说持有各种锁的时间也会更长，同步的开销也会更大。CloudJump用了影子页机制，加锁->内存里拷一份->直接解锁，而不是写完了再解锁。还实现了B-Link Tree，一次最多锁2个节点。

Evolving Ext4 for Shingled Disks

链接

ext4 on SMR的优化。 SMR也分host-managed和device-managed，其中device-managed会通过STL（类似SSD FTL）来暴露出一个支持random write的普通设备，方法就是在内部用一个“persistent cache”来吸收用户的随机写（但），并将smr上对应的zone标记为脏（意思是有一部分数据是在这个cache上的，读的时候需要merge），cache上的数据定时回刷到对应的zone上，然后这个zone就从dirty变成clean了。这个回刷的过程对一个zone的rmw。

ext4跑在这种device-managed SMR上效果并不好，因为cache回刷的过程需要吃掉大量带宽。而通过分析workload发现，ext4的随机写主要来自于metadata的更新。metadata的写入分两次，一次是jbd2中的顺序写，一次是随机写到对应的数据块中，后者就是随机写的主要来源。所以文章的目标是消除这一次随机写。

方法就是不写第二次了，只在内存里维护一个metadata的索引，指向journal中的元数据payload，读元数据就是读内存索引然后读journal，重启的时候要根据journal在内存里重建索引，over。

这里就两个问题：内存占用和重启速度。内存占用上，用63MB内存可以维护3.8GB 元数据，重启速度上，1GB journal需要恢复5-6s。感觉还是有点久。