Comparison of 7 Block Storage Offerings of Popular Public Clouds by StorPool

This abstract of a report from StorPool Ltd. compares the block storage offerings of well-known public clouds (AWS, Digital Ocean, OVH, DreamHost) with a number of StorPool-based public cloud offerings.

The tests were performed between November 2018 and February 2019.

The aim was to asses the block storage offerings of a number of public clouds, including Amazon AWS, Digital Ocean, DreamHost and OVH vs. a number of StorPool-based public cloud offerings. To the best of our ability we’ve selected VM instance types and everything else in the configurations to be identical, because we are comparing storage systems/offerings, not other aspects.

All systems under test are in production clusters. All but one of the systems (StorPool BCP) are behind available public cloud offerings, so our results are reproducible.

The StorPool BCP (standing for Best Current Practice of design) system is a production cluster of a StorPool customer, which is approximately 70% full with a high density shared hosting use-case. This cluster uses 2x25GbE networking for storage and public Internet access. In the cluster the VMs were running on a hypervisor host separate from the storage nodes, to emulate a hyper-scale deployment (not hyperconverged).

The company performed 4 types of tests:
1. PGBENCH – a database benchmark, perhaps closest to ‘application performance’
2. Sysbench/mysql – a second database benchmark for control of PGBENCH results
3. fio – a set synthetic benchmarks – random reads/writes, sequential reads/writes, latency measurements
4. rsync – copying files and syncing, simulating rapid deployment and backup workloads

Between these tests StorPool consider PGBENCH and Sysbench/mysql to be somewhat representative of most real-world transactional workloads (including most web applications), and the remaining tests are somewhat further away from being representative of real-world applications.

The VMs
7 VMs with identical parameters were procured from all tested clouds. Medium-sized VMs with 16GB RAM and with dedicated CPUs were selected to represent a medium-sized database server (the system in the heart of many web applications).

* the VM procured from OVH had 30GB RAM instead of the required 16GB. In our test this was adjusted for by instructing the Linux kernel to ignore all but 16GB of the memory.

The storage volumes
StorPool procured block storage volumes, associated with each VM, attached to the VMs as virtual disks. The goal here was to give each provider a fair chance with their SSD-based block storage offering. In Digital Ocean and AWS StorPool procured larger volumes to ensure a higher IO/s limit. In OVH and DreamHost, it could not find information about per-gigabyte performance so went with 200GB size, which is enough for its tests.

In the StorPool-based clouds customers don’t use IO/s limits to allow each VM to receive high performance for short periods of time, so the firm went with 200GB size as well. This is typical usage for a StorPool system.