For those how have been reading my blog posts, and wondering why the sudden interest in ZFS as an object store, here is another reason.
The idea behind this is pretty simple, many customers are looking for an additional tier of storage behind the ZDLRA for 2 reasons
- They want to extend the the recovery window onto a lower tier of storage. This may include going from a full "any point in time" recovery to a set of "recovery points"
- They want an archival backup for a long period of time that is a set backup point. Keep backups are the perfect example of this. With Keep backups you get a self-contained restore point of your choosing.
Now for the magic of how all this works.
1. The first step is to configure your ZFSSA as an OCI object store. As long you are on the latest patched release of OS 8.8, this functionality is available to you. If you are unfamiliar with how to do this, in previous posts, I have walked through the steps of configuring this. Below are some places to start.
Also, here is the documentation from ZFS.
2. The second step is to configure Key Vault (OKV), which is a licensed product. Key vault is a centralized Encryption Key management system that is used to store the master encryption key for the backups. OKV is released as a virtual image, that can be installed on physical hardware, or in a virtual environment. the installation is self-contained and walks through a series of questions to finish the configuration. Easy.
WHY do I need TDE ? I'm sure you are asking this question. The "Copy-to-cloud" functionality of the ZDLRA is being utilized to present ZFS as an "OCI cloud store". It acts just like an object store in the Oracle Public Cloud. The only difference is that there is no "ARCHIVE" tier on ZFS. Since ZFS is considered a "Cloud destination", it follows the Larry rule that "All data in the Cloud is encrypted.". Because of that, the backups going to ZFS will be RMAN encrypted (no license needed for this part). The ZDLRA uses OKV to store the master keys used to encrypt the RMAN backupsets.
3. The third step is to configure the ZDLRA to utilize OKV as a client, and to point the ZDLRA to your ZFS.
One of the great things of using this solution is that the process is exactly the same as configuring the ZDLRA to send backups to the Oracle public cloud. This link points to the documentation that makes it clear how to configure this process.
That's all there is to it. The most complicated task is configuring the authentication for the OCI object store on ZFS, as it requires setting up a public and private key.
Now to walk through the workflow.
Backups -- Below is the backup workflow from the presentation. The ZDLRA creates an RMAN backupset from the backup pieces on the ZDLRA. This backupset is an RMAN encrypted backupset.
One item is NOT mentioned on this slide is compression. If your Database is using TDE, then the backup cannot be compressed when sent to the ZFS because the ZDLRA does not have the encryption master key for the database. BUT, if your database is NOT TDE enabled, then you should be using compression when sending the backups to the ZFS. As I've said earlier, the backset is an RMAN encrypted backupset. Because it is already encrypted when sent to ZFS, the ZFS will be unable to compress the backups. You can find instructions to add compression in the documentation for creating a job template. There is a setting for the template called
Compression_algorithm=> By implementing compression on the ZDLRA you are:
- Decreasing the size of the backups on the ZFS..
- Decreasing the networkwork traffic between the ZDLRA and ZFS as the data is compressed before it is sent to ZFS. This can double the throughput for backups and restores.
Keep in mind, that if you restore directly to your database host from the ZFS Object store, the database host will be performing the uncompression.
Restores - Below is the restore workflow. Typically you would utilize the catalog on the ZDLRA and let the ZDLRA be the conduit for uncompressing (if it was compressed when sent to ZFS), and unencrypting it, as the ZDLRA encrypted it. The ZDLRA already has the credentials for the object store, and it has the Encryption master key available to it from OKV.
Alternately you can restore the backups directly from the ZFS object store.
This would be a 3 step process..
1) You would download the Oracle Database Cloud Backup Module . Once downloaded you would configure the database to utilize the OCI object store. The link above also contains links to documentation for the module, and to a MOS note containing the FAQ. Keep in mind that in this case you are configuring the Module for the on-premise ZFS (rather than the Oracle public cloud), and the instructions may have to be modified. The table below gives you an idea of the differences.
2) You would catalog the backup pieces. If the RMAN catalog is not available (for some reason) the MOS note mentioned below contains detail on how to list what is in the object store, and how to clean it out.
How to report or delete backup pieces stored in Cloud Object Storage by Database Backup Cloud Service without using RMAN (Doc ID 2360800.1)
The script contained in the MOS note ( odbsrmt.py) should work with a few minor changes to the instructions (since we are talking about an on-prem ZFS). I will continue to work through the changes and post the results in a future blog post.
3) You would register the restore location as an OKV endpoint (if it isn't already registered), OR you can alternately export the encryption key and create a wallet file.
Conclusion - This is a very exciting addition to the many features that the ZDLRA already provides.
No comments:
Post a Comment