Hi, this is Todd Price, HPE's Database Solutions, Technical Marketing Engineer.
In this video, I'm going to talk about using
HPE Zerto replication and data retention on Oracle databases in a VMware environment,
using HPE Primera and Alletra Storage Solutions.
HPE Primera and Alletra primary storage is the flagship enterprise and medium business storage for Oracle databases.
This video will show how an Oracle database can be integrated into a VMware environment
with Zerto disaster recovery and data retention.
The VMware data store is used in this video are configured on both HPE Primera and HPE Alletra.
The original production database on site A is an Alletra 9000 and the site B recovery data store is on HPE Primera.
Any HPE Primera storage can be used.
Talk to your HPE storage representative for the right configuration in your environment.
HPE would love to have a discussion with you about our storage offerings
as well as the Zerto solutions we provide for disaster recovery.
Looking at the building blocks for an Oracle database replication and data retention solution,
to a disaster recovery site.
Each of the sites have their own vCenter installations with a land link between the sites
having the proper bandwidth to handle the database rights for the solution.
This example shows both Oracle Enterprise and MySQL databases being replicated from site A to site B.
Each of these databases are running their own virtual machines.
Each site has at least one ESXi server.
The HPE storage arrays are configured into VMware Data Stores using either VMFs volumes, RDMs or vVaults.
The Oracle database can be a file system or a SM.
Note. Oracle rack clusters are not supported with Zerto solutions.
In this use case, we are using Oracle automatic storage manager, ASM.
Three volumes will be replicated: one from the Oracle Linux OS,
a second for the Oracle data, table spaces, redo logs, etcetera,
and a third for Oracle archive logs.
Oracle databases using traditional file systems would work as well.
There are three main components to Zerto in this solution.
ZVM, the VRA and the VPG
ZVM is a Zerto Virtual Manager, which is used to visually manage the Zerto solution.
The ZVM runs on a Microsoft Windows VM
and the application runs on the Internet browser.
The VRA is the virtual replication appliance.
Each site will have its own VRA which is set up using the ZVM.
The VRA is responsible for intercepting I/O and replicating it
through the WAN connection for remote replication and replicating locally,
if chosen as part of the configuration.
Let's have a look at the main dashboard on the ZVM. Across the very top of the dashboard,
we have the main components and the number of instances being used are set up,
shows two VPGs: one for my SQL database, and one for Oracle database.
We have two VMs: 734 GB of data being protected.
Compression is showing 37% and the average recovery point objective is three seconds.
The dashboard also shows I/O write throughputs, the general health of the VPGs
and the various alerts and tasks running.
The two green boxes in the top middle represent each VPG.
Green is a healthy status.
Yellow would mean more of a warning and red would indicate an issue exists.
The color circle indicates how well the replication setup is meeting the service level agreement.
Clicking into the colored square for the VPG, we can see the monitoring information.
Up on the top left, for the Oracle database we're replicating.
This is the point at which we can recover.
We can see this instance is averaging between six and 10 seconds. Also we can see
I/O throughput information specific to the VPG.
In this case, it's only the Oracle database.
If the VPG also had another application or WebServer replicating the I/O metrics
would be all of the apps or databases in the VPG.
We also can see information about specific VMs that are being protected in the VPG.
Let's go back to the Zerto dashboard.
Next, let's have a look at how the VPG itself is configured.
This screen shows a list of configured VPGs. Each VPG entry shows the actual real-time RPO
for that VPG. For Oracle database, it reads six seconds.
We can see as well if the VPG is meeting the defined SLA.
Looking closer into the VPG for the Oracle database, we can get more details.
These details are defined when the VPG is created.
By going into the edit function, we see the first page where you choose the VPG type.
The choice types are: Remote Continuous Backup,
Local Continuous Backup and Data Mobility.
The VPG has also given a name and a priority.
On the next page, you will choose the VMs you want to be in the VPG.
In this case, it is the Oracle database.
The unprotected VMs can be moved over to the selected VM side,
if you want them to also be in the VPG.
In the replication section, the ESXi host for recovery is defined,
along with the associated data store and replicated data and journal data recovery.
Data store must have the appropriate capacity to handle any VMs and
applications being replicated, along with their journal information.
The storage page is where you define the storage volumes that will be attached to the VMs in the VPG.
In this case, we have one volume that is Linux OS,
the other two volumes belong to Oracle Automatic Storage Manager
for database objects, redo logs, and archive logs.
The number of volumes attached can likely be many more,
depending on the Oracle implementation.
These volumes can also be file systems.
Follow normal best practices for the database architecture.
Next, is a recovery page that defines a WAN link and test link for the recovery.
There is a failover network, as well as a test network
where the Oracle database can be failed over in a test scenario
or in a real production scenario.
This page simply defines the network specifics required for that recovery.
The next page goes into even more detail about the network interfaces used for recovery,
specific IP addresses, subnet masks, and gateways are defined for both
the fail over production network and the test failover network.
Information about the specific VMs can be edited.
Monitoring for alerts, events and tasks running.
Long-term retention can be defined for an Oracle database or a solution.
This long-term retention is where the data can be stored in many places.
In this instance we are using the HPE StoreOnce VSA for a long-term retention.
Reports of the database VPG can be generated showing the RPO over time,
as well as data throughput.
Here is where the VRA is defined. For each site, configured data stores can be seen.
The repository is where we define the targets for long-term retention.
When creating a new repository for Oracle data, storage types range from cloud AWS,
Amazon S3, Microsoft Azure, to network NFS, and even purpose-built appliances, like StoreOnce.
Failover can be easily done by selecting the VPG or database to fail over
with the ability to even select a specific checkpoint by auto checkpoints, VSS,
or other tag checkpoints such as an Oracle application,
consistent checkpoint created using scripts
and Zerto commandlets, to create the checkpoint tag.
A huge benefit from using Zerto is the data analytics functionality showing your entire Zerto space
within your organization.
Data can be moved all through the organization. For Oracle, this can be an entire database,
could be log files, offline ASM groups
with specific table spaces and database objects, web servers, other applications, and more.
Anything in a VMware environment now has data mobility at the VM and data store level,
with the defined data consistency and write ordering.
In summary, Oracle databases can be replicated real-time by defining everything
in the database to a single VPG.
The VPG provides data consistency and write ordering, with checkpoints
every five seconds, as well as tag checkpoints done by the user.
Oracle databases can be replicated for DR purposes
and data can be migrated and mobilized to other areas of the organization.
Thank you for your time and enjoy your virtual Oracle and Zerto Solutions experience.