Exadata is a powerful database appliance solution, featuring excellent redundancy throughout and abundant storage to support large databases. However, organizations must extend the protection of data externally from the Exadata to ensure a comprehensive disaster recovery solution is in place.
The implementation of an Oracle ZFS storage appliance is one option to provide such capability. The following post will review best practices for protecting the Exadata Database Machine with Oracle ZFS Storage Appliance Configuration.
1. Determine a Backup Strategy
The first step in implementing a disaster recovery solution is to develop the backup strategy, whether it’s traditional or incremental. What are the benefits and limitations of each?
There are clear benefits of the traditional backup strategy:
- Reduced IO
- Higher throughput rates
- Greater flexibility in backup scheduling
- Reduced space consumption for level 0 backups
However, there are also limitations to this approach:
- Longer backup times
- More storage requirements.
By contrast, an incremental backup implementation is beneficial when two circumstances are met:
- The daily change rate does not exceed 3% so as to keep these backups small and short in duration.
- A weekly level 0 backup negatively impacts computing and/or network resources due to the size of the database.
It should be noted the incremental strategy is best suited in large data warehousing operations and provides accelerated restores for data within a narrow period of time. Careful attention must be given to the restore requirements and the recovery point objective (RPO) due to the limited number level 0 backups associated with this strategy.
2. Configure Hardware
The ZFS Storage Appliance can be configured with varying levels of DRAM, write flash accelerators, and disk options. For maximum throughput and capacity, best practices recommend utilizing high capacity disk shelf models for maximizing storage without compromising too significantly with performance. If solely used for RMAN backups, write flash accelerators will not offer any additional performance benefits meaning, these can be omitted from the hardware configuration.
Network configuration is yet another important decision prior to the hardware purchase. There are two networking options available: 1/10GbE and Infiniband. Best practices are to purchase the Infiniband network cards to seamlessly connect the ZFS to the Exadata spine or leaf switches when an Exadata serves as the data source. These switches provide dedicated ports for connectivity providing maximum throughput rates which enhances both backup and recovery performance.
3. Configure Storage
A storage profile will be selected to create each storage pool for expressing the characteristics required for redundancy, performance, and the like. Basic storage profiles include mirrored, single parity, and double parity. Each profile is beneficial to certain aspects of operation and impact the resulting usable space. Special consideration of the choices should be conducted and selected based upon performance along with capacity requirements among other factors.
For general purposes of backup performance and capacity savings, the stripe profile works well. Once the storage pool, project, and desired shares are created, additional share settings are required to maximize operability. Settings include record size, synchronous write bias, and more.
4. Share Connectivity
The two available options for share connectivity to the desired database servers are NFS or dNFS. Oracle best practices for Exadata recommend dNFS to take advantage of lower overhead compared to NFS version protocols. The dNFS option provides lower CPU utilization and advanced high availability since the protocol resides at the database kernel level and not that of the operating system. The configuration and setup guide is located in the Oracle MAA for Exadata.
Infiniband connectivity can be maximized by configuring scatter gather on the Exadata compute nodes which provides non-contiguous memory allocations for Infiniband buffering to reduce latency in the protocol stack. This effectively eliminates Linux memory fragmentation preventing page allocation failures. Additional items of this configuration step include an mtu setting of 65520 and a queue size of 2048 to further reduce latency.
5. Database and RMAN Configuration
Configuring RMAN is the final step in the process of setting up a disaster recovery solution which will include setting the number of channels for use. Also, ensure additional settings such as filesperset, section size, block change tracking, etc. Tuning the buffer settings will only apply to restores as Automatic Storage Management (ASM) dynamically tunes these during backup operations.
Oracle best practices recommend placing the database in archivelog mode to enable backups to be performed while the database is open and active. Archivelog mode offer additional benefits such as data protection during media failure, point-in-time recovery, and the ability to restore the database from an inconsistent backup.
Conclusion
ZFS storage appliances offer a robust and a full feature set to provide external backup capabilities to the Exadata database appliance. The ZFS Storage Appliance offers a multitude of additional features beyond this discussion to further enhance disaster recovery solutions. It provides a robust set of capabilities for a diverse user base, including:
- Ndmp capabilities to external disk or tape media, and
- Data replication functionality to additional ZFS storage appliances
ZFS should be strongly considered by any Oracle Engineered Solution customer looking for external storage for offloading backups and enhancing the overall system architecture.
If you have further questions about this content, just let me know and I'd be happy to discuss with you or refer you to appropriate resources.
