7/27/2019 Byan.pdf

1/1 2011 NetApp. All rights reserved.

KVM/QEMU virtio paravirtualized device

rawblock driverdisk-under-test

aioreadopen close

open close

aiowrite

POSIX syscalls through Linux-KVM hypervisor host

open close

iSCSI volume

rawblock driverflash SSD

open close

open close

SSD

GbE

Linux Guest VM

aioread aiowriteaioread aiowrite

aioread aiowrite aioread aiowrite

QEMU virtual disk

hgMercury caching block filter driver

Mercury: host-side flash caching

for the datacenterSteve Byan, James Lentini, Luis Pabn, Christopher Small, Mark W. Storer

Mercury flash cache implementation

Performance results

Shared-pool datacenter Integrated flash memory

FCoE/iSCSI/NFS/CIFS

+10s-100s GB of flash being integrated into serversNew price/perf tier between disk and DRAMFlash is 10-100x faster than disk, price of DRAMHigh IO-per-second (IOPS) storage close to CPUbut using integrated flash for primary storage

breaks the shared-pool datacenter model

Binds software services to specific serversPuts flash primary storage out of reach of storage

management tools

Shared VM servers

No persistent stateVMs not tied to servers,

can be dynamically

added, moved

Servers can be added,upgraded, repurposed

on-the-fly

Shared Storage

Unified central storagemanagement

Shared pool scales moreeasily; resources can be

reassigned on-the-fly

Data can be moved tomost appropriate media

Mercury portable flash cache

Uses integrated flash or other local storage as acache for centrally-managed shared storage

Implements a block-oriented cache; write-through tomaintain coherence with backing store

Deployable as-Hypervisor filter driver, transparent to guest OS-OS filter driver, transparent to applications-Application cache-Proxy cache for a network storage protocol

Prototype deployment

KVM/QEMU block driver, loads into stock QEMUProvides new disk format, hgRequests sent to hgdevice handed to SSD cache or

passed to rawbacking device

0%

20%

40%

60%

80%

100%

Serial Random

Timerelativetocontrol

Speedup

Control

Mercury

Replayed disk-level traces fromWindows XP desktop

Cache warmed with one to threedays of traces

All tests run on same trace

Nearly 40% reduction in meanI/O service time

Near 50% reduction of requestssent to server (almost all reads

handled by Mercury)

Desktop traces iozone

iozone run directly against serveriSCSI volume and via Mercury cache

Serial I/O showed small improvementRandom I/O had substantial speedup

(almost all reads handled by Mercury)

0%

20%

40%

60%

80%

100%

control one day two days three days

Timerelativetocontrol

Size of trace used to warm cache

Speedup

0

500

1000

1500

2000

2500

3000

control one day two days three days

ServerI/O

load(Kops)

Size of trace used to warm cache

Server Load Reduction

reads

writes