VPG Configuration Best Practices

When defining a VPG to protect Oracle Database virtual machines, you need to consider the following:

The virtual machines to include in the VPG and the boot order between these machines. See Virtual Machines in the VPG.
SLA Considerations.
Journaling Considerations
Storage Considerations
Network Considerations

Virtual Machines in the VPG

Place all of the virtual machines that form a single application in the same VPG. If multiple applications use the same database and all require consistency then one VPG should be created with all the application virtual machines, even if the number of virtual machines is large.

If the application virtual machines don't require consistency to the database virtual machine, then create separate VPGs for the applications and the database virtual machine. If multiple database virtual machines update each other continuously and are interdependent then they should be placed in the same VPG for cross-database consistency.

Zerto best practice: Boot ordering within a VPG should be applied to ensure that the Oracle Database virtual machines boot first and that the database services are online before any application servers that use the database services begin booting.

SLA Considerations

The VPG SLAs should be configured to allow a sufficient amount of data retention for recovery to previous points‑in‑time, give sufficient leeway on the RPO to allow spikes in data change rates without raising false alerts, and to send reminders to test on a reasonable schedule.

Zerto best practice: Start with a five minute RPO and leave the VPG protected for at least one working day in this configuration. Configure email alerts to be sent immediately when there is a breach of the RPO SLA during this time period. After 24 hours, the RPO should be altered up or down depending on the SLA requirements of the business. That is, if the RPO regularly hits 5 minutes but typically lasts for 10 minutes before returning to normal, then the RPO alert and SLA should be changed to 15 minutes or the bandwidth between the sites should be increased.

Zerto does not recommend changing the RPO alert to less than 20 seconds as this leaves no leeway for any spikes in data change rates or network connectivity, and can result in unnecessary RPO alerts being generated. Neither should the RPO alert be configured to the exact SLA defined by the business as this gives no leeway on the replication alert vs. the SLA defined. For example, if the business requires an RPO of 30 minutes then best practice would be to configure the RPO alert at 20 minutes to allow a comfortable leeway. If the RPO alert was constantly breached in this scenario then the situation can be remedied by increasing available bandwidth without breaching the business SLAs.

Zerto best practice: The default test frequency of 6 months is recommended when first configuring the protection of a VPG. It should be increased or decreased based on the frequency of testing required by business defined SLAs.

Journaling Considerations

Performance of the journal storage is important as the protected virtual machine data is inserted with the same I/O profile and the journal can be heavily used during the pre-commit and commit phases of a failover, before committing the failover.

Maintaining space availability on the journal datastore is also key to maintaining replication. Filling the datastore will break replication, whereas multiple journals hitting their size limit will only reduce the time frame of the journal, but it will not break the replication.

Zerto best practice: When configuring journaling for Oracle Database virtual machines, start with a one hour journal. After one hour of production data has been replicated, use the size of the journal to calculate the space required over the time period the business dictates as an SLA requirement for data retention. The journal should then be increased to the desired time frame for retention.

Zerto best practice: The storage used for the journal should have the same I/O profile as the storage containing the replica virtual machine data.

Zerto best practice: The journal storage should have enough space to accommodate the data change rate over the time period specified. To cope with spikes in data change there should be at least 30% of disk space free on the storage and the maximum journal size should be configured on each journal to ensure no journal can fill the storage specified.

Storage Considerations

The datastore configuration of the protected Oracle database virtual machine should be matched in the recovery site to ensure the same performance in a recovery scenario. Since Zerto is storage agnostic, it is possible to replicate from any storage to any storage, and therefore any LUN to any LUN configuration. However, this does not take into account the performance requirements of the protected virtual machines.

Zerto best practice: Use different storage for the journal and for the replica virtual machine data.

The number of virtual machines running per storage, as recommended by the storage vendor, should be taken into account if you are replicating multiple virtual machines to a consolidated number of storages in a target site.

Network Considerations

The networking configuration of the Oracle Database virtual machines running in production should be mirrored in the recovery site. If a different IP address is required in the recovery site, the VPG can be configured on a per virtual NIC basis to change the IP address automatically as part of a failover, move, or test operation. If an IP change is required, ensure that the listener.ora and tnsnames.ora configuration files do not have hard coded IP addresses, but use hostnames.

For failover testing, a mirror of the production networking should be configured in an isolated network segment to allow failover testing with no impact on production.