What can we do with our Oracle Database using Peer Persistence?
HPE 3PAR Peer Persistence is a storage clustering feature offered on the 3PAR array. By making use of 3PAR Remote Copy synchronous replication, the industry-standard protocol Asymmetric Logical Unit Assignment (ALUA), and HPE Quorum Witness technology, you can achieve automated transparent failover of your Oracle workload to a second 3PAR array in the same or a nearby datacenter.
Once the infrastructure is in place with two HPE 3PAR arrays, there are many uses for this powerful data centric solution. Here are some use cases for Oracle in a Peer Persistence set-up:
- Storage fail-over data protection – protect Oracle database and other data from inter or intra-site failure
- Oracle RAC stretch clusters – extend Oracle Grid Infrastructure and Real-time Application Clusters to another site.
- Integrate Oracle DB replication with other applications and infrastructure components (e.g. DB + Web Apps + DevOps)
- Data Reporting – use snapshots and clones on remote array for data extraction, backup, querying, etc
- RMC-O integration – Build a backup and recovery solution on the target site
- DevOps snapshot and cloning – Create snapshots and clones of production data at the target site for DevOps and QA testing
How it works
The diagram in Figure 1 below is an example of a scenario where the solution consisted of a RAC cluster with two nodes each running an instance of Oracle RAC. The RAC cluster provides for the automatic fail-over of the host servers as well as the storage. However, RAC is not required. If failover of only the storage and not the host is desired, the solution can be configured with only a single instance Oracle database.
The storage in our solution is an HPE 3PAR array at each site. Synchronous Remote Copy is configured between site A and site B. The links between sites can be either redundant Fiber Channel connections or Ethernet links, following Remote Copy guidelines. Data from the primary site (site A) gets replicated real-time to the target array (site B). When the host issues an IO write request, the request is not complete until the data has been written to both arrays. The low latency fiber channel connections allow Oracle RAC to operate as a stretch cluster. There is an exact copy of the database on the target array at all times. What’s more, 3PAR Peer Persistence automatically creates both the source and target copies of a volume with the same WWN. Therefore, even though the host has LUNs that span two different storage arrays, it actually appears to the host as if it has a single LUN, simply one with multiple paths. This is made possible because the ALUA technology marks the host’s paths to the source array in site A as primary, whereas the paths to the target array in site B are seen by the host as standby.
The last piece of the puzzle is the Quorum Witness. The Quorum Witness runs in a VMware or Hyper-V Virtual Machine and continuously monitors the heartbeat of both 3PAR storage arrays over the arrays’ management interfaces. When communication between the primary and secondary arrays is lost, this enables the solution to distinguish between a real failure of the primary array and the failure of just the Remote Copy replication links.
Now when the primary array fails, it is up to the target array to initiate the fail-over. The target array polls the Quorum Witness which is able to validate that it too has lost communication with the primary. Now the target array automatically initiates the failover by switching the volumes states on both storage arrays - the volumes in site A become the secondary volumes and the volumes in site B, the target site, become the primary volumes. At the same time, the primary and standby paths to the storage from the host are also swapped. The workload seamlessly fails over and it is all transparent to Oracle.
Additional details on this can be found in the HPE Reference Architecture for Oracle 12c RAC Scaling on HPE ProLiant DL380 Gen9 and HPE 3PAR StoreServ 8450 All Flash whitepaper. The guidelines and specifications for setting up both Oracle Database Single Instance and RAC can be found in the Peer Persistence section of the HPE Single Point of Connectivity Knowledge (SPOCK).
Figure 2 below shows how the paths are dispersed from the volumes or volume sets. With the 3PAR array every volume has a unique WWID. When Peer Persistence is configured the source and its target volumes being replicated have the same WWID. The host sees the primary and target volumes as one volume. Looking at the primary array the paths are active and looking at the target array the paths are in standby. When a fail-over occurs the target array volume becomes the active path to the Oracle host.
The video below shows the functionality in action. This video is running an Oracle Database workload on a single instance database between 3PAR 9450 and 8440 storage arrays. Special Thanks to Tech Marketing 3PAR Product Engineer Nancy Berliner for producing the video and assisting with this blog.
Documentation Resources
Link for the paper HPE Reference Architecture for Oracle 12c RAC Scaling on HPE ProLiant DL380 Gen9 and HPE 3PAR StoreServ 8450 All Flash
Link to SPOCK HPE SPOCK
Please blog any questions you may need addressing or just any general discussion is ALWAYS welcome!
Best Regards
Todd – HPE Technical Marketing Engineering – Oracle Solutions
ToddPrice
Expertise in Oracle Database Technologies on HPE Storage
