Scaling Oracle SLOB to 7M IOPS and 55.4GB/s Throughput with Datrium – and the Latency FAKE NEWS!
My previous Oracle article (here) was focused on single-instance performance, and at the end of the post I alluded to the scale-up potential. How many Oracle instances can you run on the same platform?
In this article, I demonstrate how we can keep adding Oracle instances, continuously, without disrupting performance.
With Datrium Oracle application datasets are stored on Flash devices on the host where the Oracle VM is running, and a secondary copy of the data is synchronously 3-way committed to nodes dedicated to persistently storing data, aka datanodes. That means all Read IO is local to the host, and only the Write IO traffic goes over the network, therefore decreasing Read latencies.
SLOB 80/20 - 3 instances and 3 servers
The picture below demonstrates Oracle SLOB instances running with an 80% Read, and 20% Write profile, scaling to three instances and three hosts. In this example, the system delivers 165K IOPS and 1.3GB/s throughput, with an average VM-Level latency of 1.7ms. (I copied this test profile from a Pure Storage paper)
[Update] I have been privately asked about the server hardware used for this test. I used three Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz with 2 regular Intel SSDs each.
Upper Limits
However, considering Datrium upper system limit of 128 hosts, and assuming the exact same workload, we can estimate that Datrium can handle approximately 7M IOPS and 55.4GB/s throughput with the same VM-Level latency of 1.7ms.
You: – Yeah! But, you are showing us the system handling only 3 servers.
Me: – You will need to take my word for that.
Just joking, because despite not having 128 servers to demonstrate this particular Oracle SLOB workload we have previously partnered with IOMark, StorageReview, Dell, and Intel to demonstrate the ridiculous high-scale results Datrium can achieve.
- Datrium Audited as the Highest IOmark Benchmark Result in History
- Storage Review also does an excellent piece on scalability here.
- ...and below are the supported systems limits.
Latency FAKE NEWS
I also want to address another important point; the application storage latency, and how the storage industry continues to manipulate results and mislead customers.
First of all, as you can see we openly publish the VM-level latency being delivered by the system because at the end of the day the latency that matters is the latency that applications and users experience.
The problem is that storage vendors, especially SAN vendors, continue to demonstrate latencies at the SAN Array controller - and this is the reason why I decided to mimic this Pure Storage benchmark, where they claim to provide 0.21ms latency, without qualifying where the latency is measured.
However, in another public post where they talk about their Pure1 application we can clearly see how a 1.08ms latency measured at the SAN array controller translate to 7.40ms at the VM disk-level. Consequently, using the same behaviour, their Oracle SLOB benchmark latency is likely neighboring 6.53ms.
I'm glad to see vendors starting to address application latency, and not what is seen by SAN array controllers, and hopefully, we will see more vendors moving in this direction.
It's very telling how even the most modern Flash arrays cannot match Datrium performance, scalability and latency – and I am not even mentioning additional high-valued features like integrated data protection and orchestrated disaster recovery.
Lastly, as always, Datrium runs with all data services turned on, including Checksumming, inline Erasure Coding, inline Compression, and inline Deduplication.
Reference paper from Pure storage (here)
This article was first published by Andre Leibovici (@andreleibovici) at myvirtualcloud.net