Why it is important to beware of EPIC data protection and EPIC rapid restore with Pure FlashRecover at the time of catastrophes!
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 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 Intersystem Caché database on which the Epic application runs has a write cycle limit which is in a few seconds. And to keep the things humming, the flush of writes from the database must be completed before that limit 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.
For organizations that have deployed EPIC infrastructure in their ecosystem, it becomes really crucial to have a more optimized disaster recovery planning or a rapid recovery of the EPIC databases. Medical institutes such as research centers and hospitals are the lifeline for the patients and most of those institutes need a better rapid recovery solution for their EPIC implementation, and hence Pure Storage FlashRecover has helped solve those restore challenges associated with EPIC.
The epic deployment consists of a production server which comprises EPIC server databases, a reporting server, a read-only server, and an EPIC disaster recovery server, each of the EPIC deployed components is hosted on an EPIC cache database. The storage of EPIC cache databases is hosted on a high performant primary storage such as FlashArray. The data protection for the EPIC cache database is conducted via exposing the volume of the associated databases from the disaster recovery site to a Linux proxy server or AIX server and later this filesystem is backed up. This document will cover the performance of backup and restore of the cache data files by Pure FlashRecover powered by Cohesity. The following Figure 1 depicts the EPIC deployment and the FlashRecover data protection of EPIC cache data files.
How Pure Storage FlashRecover does solve the EPIC restore Challenge?
A four-node FlashRecover cluster with single 15 blades FlashBlade chassis is configured. A data protection policy is created on a Linux physical server as the source (in this case it is EPIC proxy server) and ran the filesystem backup and recovery test.
The most reliable test would be to utilize existing Data from a real EPIC Cache database, as it is a little tricky to have a complete EPIC test environment in the Lab. Hence, we used the EPIC developed tool GenerateIO which is very close to EPIC datasets. For more information on GenIO read how Generate IO can use to simulate EPIC.
A Linux proxy host is registered as a source to Cohesity. A full backup and restore of EPIC data is performed through FlashRecover UI by default settings in the data protection policy. The backup and restore speed are captured from the Cohesity job run and hence this shows the end-to-end backup timing.
Based on our environment set up with 4 nodes Cohesity cluster a single host backup performance achieved on an average of 950 MBps and it took 5 hours and 50 minutes to finish 18.3TB of data as shown in the below screenshots.
A full restore is triggered for the above backup data and captured the performance from the Cohesity UI, the restore performance was achieved on an average of 1.5GBps on 4 nodes FlashRecover cluster as shown in the below screenshot 6. It took 3 hours and 35 minutes to finish the restore of the 18.3 TB EPIC data set which is ~1.45GBps end to end restore performance rate.
For more information on Pure FlashRecover and Modern Data Protection solutions please reach out to the Pure sales team.