This post was originally published on this siteAt Pure//Accelerate 2018 Cody Hosterman and I delivered a session on “Moving Data Between Cloud and On-Premises Virtualized Environments“....
In hospitals and health systems, it’s vital that applications keep pace with the velocity of care. Storage latency is critical to performance and efficiency of mission-critical healthcare applications. With thousands of patients and healthcare providers simultaneously accessing and updating electronic medical records (EMR) information 24/7, on site or via mobile apps, database response times determine how quickly data arrives in surgery or during patient visits. Few industries are as storage-latency sensitive as hospitals and health systems. At Pure, we started the move toward all-flash solutions for healthcare — offering low latency at a lower total cost of ownership with higher reliability and efficiency for healthcare environments.. The newly introduced Pure Storage FlashArray//X Family are taking the fast response times and high availability of flash even further.
Epic is one of the main electronic health records (EHRs) in use at U.S. healthcare organizations today. Epic’s production OLTP database server — also known as the Operational Database, or ODB — has well-defined storage response requirements for both reads and writes in order to ensure low response times for high performing interactive user workflows, to meet the needs of providers and patients in the health system.
The underlying InterSystems Caché database on which the Epic application runs has a write cycle of 80 seconds. To keep things humming, the flush of writes from the database must be completed within 45 seconds, well before the next write cycle begins, even under the heaviest of workloads. And, in order to maintain great response times and user experience, the ongoing voluminous random application reads must be reliably fast. The existing FlashArray//M, when configured properly, meets and exceeds Epic’s requirements, but we wanted to see how the new flagship FlashArray//X90 compares to the //M70 which launched in 2015.
For this test we compared a FlashArray//X90 with a FlashArray//M70, each with their own respective versions of Purity at GA . The server we used for both tests was a Cisco UCS Blade B200M4 running Red Hat Enterprise Linux RHEL 7.4 over VMware ESXi 6.5.
Epic uses its “Epic IO Simulator tool” (aka GenerateIO) to validate the performance of new storage configurations at customer sites; here we are using it to evaluate the performance of the storage array. Pure Storage FlashArray//M and //X show great results with Epic’s IO Simulator, meeting the service-level agreement (SLA) requirements for write I/Os and exceeding the read latency expectation
The “Total IOPS” number is the number of Read and Write IO (8K IO at 75/25 Read/Write ratio) generated by the tool before it reached the either of the read or write SLA limit .
However, we found that the new FlashArray//X offers a significant improvement, even when compared to the already exceptional performance of the FlashArray//M.
|Epic IO Simulator||Total IOPS||RandRead (ms) @MAX|
|//M70 152T 40 SSD||147,500||1.04|
|//X90 182T 20 DirectFlash Modules||187,000||0.58|
|//X vs //M performance increase||27% more IOPS||45% read latency improvement|
Figure 1: Epic IO Simulator Results with default parameters
These results demonstrate that the //X90 reached Epic’s SLA for write cycles much later than the //M70R2 at 187,000 Total IOPS. The read latency with the //X was 80% less than on the //M70. This demonstrate the improvements in density performance, meaning that the //X90 accomplishes more with the same amount of flash as the //M70.
This test results demonstrate that the new FlashArray//X90 is setting a new bar in density and performance for Epic workloads, delivering higher performance with less flash than before. For most Epic customers seeking to migrate their workloads to all flash to meet SLA requirements, both the //M and //X arrays are great solutions. The new //X90 provides the greatest density and cutting edge performance for the largest Epic customers, while the //M provides a great option that exceeds Epic’s SLAs for most health systems today. Pure’s Evergreen™ Storage program means existing customers on //M arrays can upgrade non-disruptively to the //X, and avoid re-buying the same TBs twice. New customers have even more options for configuration and performance with the //X when sourcing storage from Pure, allowing them to take advantage of the next step in technology with NVMe and DirectFlash™.
For more information on announcements this year at Pure//Accelerate, check out our overall launch blog, Data Centric Architecture Powers Digital Business.