Mitigating the Performance-Efficiency Tradeoff in Resilient Memory Disaggregation

Abstract

Memory disaggregation has received attention in recent years as a promising idea to reduce the total cost of ownership (TCO) of memory in modern datacenters. However, relying on remote memory expands an application's failure domain and makes it susceptible to tail latency variations. In attempts to making disaggregated memory resilient, stateof-the-art solutions face the classic tradeoff between performance and efficiency: some double the memory overhead of disaggregation by replicating to remote memory, while many others limit performance by replicating to the local disk.We present Hydra, a configurable, erasure-coded resilience mechanism for common memory disaggregation solutions. It can transparently handle uncertainties arising from remote failures, evictions, memory corruptions, and stragglers from network imbalance with a significantly better performanceefficiency tradeoff than the state-of-the-art. We design a finetuned data path to achieve single µs read/write latency to remote memory, develop decentralized algorithms for clusterwide memory management, and analyze how to select parameters to mitigate independent and correlated uncertainties. Our integration of Hydra with two major memory disaggregation systems and evaluation on a 50-machine RDMA cluster demonstrates that it achieves the best of both worlds: it improves the latency and throughput of memory-intensive applications by up to 64.78× and 20.61×, respectively, over the state-of-the-art disk backup-based solution. At the same time, it provides performance similar to that of in-memory replication with 1.6× lower memory overhead.

First-generation Memory Disaggregation for Cloud Platforms

“…DDA and SR-IOV require the whole address range of a VM to be statically pinned in hypervisor-level page tables [15,[75][76][77][78][79]. As a consequence, memory disaggregation cannot rely on hypervisor page faults, which would be needed to deploy existing RDMA-based systems at the platform level [29][30][31][32][33][34][35][36][37]. For the same reason, we cannot migrate pages between local memory and a pool as used in existing two-tier memory systems [31,[49][50][51][52].…”

“…ThymesisFlow advocates application changes for performance, while we focuse on platform-level MLdriven pool memory management that is transparent to users. Hypervisor/OS level disaggregation: Hypervisor/OS level approaches [11,[28][29][30][31][32][33][34][35][36][37] rely on page faults and access monitoring to maintain the working set in local DRAM. Such OSbased approaches bring significant overhead, jitter, and are incompatible with virtualization acceleration (e.g., DDA).…”

“…Due to these requirements, most of the prior memory disaggregation work does not apply: custom hardware-based designs [13,[17][18][19][20], systems that require changes to the VM guest [11,[21][22][23][24][25][26][27][28][29][30][31][32][33][34][35][36][37], and implementations that rely on page faults [15] are not deployable in the cloud today (see §4.1).…”

uBFT: Microsecond-scale BFT using Disaggregated Memory

“…In our prototype, we do not assume that we are given a reliable disaggregated memory [54,91], but rather show how to implement a reliable disaggregated memory using RDMA. 2 To do so, we assume 2𝑓 𝑚 +1 memory nodes out of which 𝑓 𝑚 can fail.…”

“…Carbink [91] and Hydra [54] build reliable disaggregated memory to improve memory utilization in a cluster, albeit without support for concurrent shared access. MIND [53], GAM [21] and Clover [85], on the other hand, provide reliable shared memory, but they do not tolerate Byzantine writers.…”