Thursday, April 30, 2020

Three-Site Data Center Data Protection using NetApp ONTAP 9.7 SnapMirror



In today’s constantly connected global business environment, companies expect rapid recovery of critical application data with zero data loss. Organizations devise effective disaster recovery plans by keeping the below requirements in mind:

• Data should be recoverable in the event of catastrophic failure at one or more data centers (disaster recovery).
• Data should be replicated and distributed in an optimal way, taking into consideration major business criteria such as cost of storage, protection level against site failures, and so on.
• What needs to be protected and for how long should be driven by:
Shrinking recovery point objective (RPO), to achieve zero data loss
     Near-zero recovery time objective (RTO), for faster recovery of business-critical applications in case of disaster

Three-Site Data Center Topology
The three-site data center configuration can be done in either fan-out or cascade topology.

Fan-out Topology
Fan-out topology consists of primary and near disaster recovery data centers within region sites (with replication network having <10ms round trip time), will synchronously replicate data between themselves to achieve zero RPO. And the primary asynchronously replicates data on a regular basis depending on the quantity of new data being generated to the remote or far disaster recovery out-of-region data center. If disaster strikes the primary site, the application can be started with zero data loss from the near disaster recovery data center, which would also take over asynchronous replication to the far disaster recovery data center.



Steps to Configure Fan-out Topology:

Create intercluster role Lif's and configure cluster peer and SVM peer.

Check the cluster peer and vserver peer in all the 3 site NetApp Clusters.

Cluster1  --- peered with cluster2 and cluster3





Cluster2 peered with cluster1 and cluster3.



Cluster3 is peered with cluster1 and cluster2.




In cluster1, create a new source volume (Ex- volnew). (Primary Site)



In cluster2, create a destination volume with DP type. (Near DR Site)



In cluster2, create SnapMirror  (SM-S) Sync relationship. 




Then initialize the Snapmirror relationship, once the base line transfer is successful, the status will be Insync.




In Cluster3, (Far DR Site) create a DP volume and create a Async SnapMirror relationship between Primary Site and Far DR site.



Initialize the SnapMirror Relationship.







Primary Site to Near  DR Site (Sync) 


Primary Site to Far DR Site (Async).




Cascade Topology

Cascade topology is where the primary would synchronously replicate to the near disaster recovery site, and the near disaster recovery site would asynchronously replicate data to the far disaster recovery site. In case the near disaster recovery site goes down, you can configure an asynchronous replication directly to the far disaster recovery site over longer distance to ensure all the delta updates are being updated or replicated.


In Cluster1(Primary Site), Create a source volume to replicate.






In Cluster2 (Near DR Site) , Create a DP volume.



In Cluster2, create a SnapMirror Sync relationship between these two volumes.





In Cluster3(Far DR Site), create a DP volume.




In cluster3, create a Snapmirror (Async) between cluster2 and Clster3 volumes.






Wednesday, April 29, 2020

NetApp ONTAP 9.7 - Converting FlexVol volumes to FlexGroup volumes



FlexGroup Volume:

A FlexGroup volume is a scale-out NAS container that provides high performance along with automatic load distribution and scalability. A FlexGroup volume contains several constituents that automatically and transparently share the traffic.

If you want to expand a FlexVol volume beyond its space limit, you can convert the FlexVol volume to a FlexGroup volume. Starting with ONTAP 9.7, you can convert standalone FlexVol volumes or FlexVol volumes that are in a SnapMirror relationship to FlexGroup volumes.

Starting with ONTAP 9.7, you can perform an in-place conversion of a FlexVol volume to a FlexGroup volume without requiring a data copy or additional disk space.



To convert a FlexVol volume SnapMirror relationship to a FlexGroup volume SnapMirror relationship in ONTAP, you must first convert the destination FlexVol volume followed by the source FlexVol volume.


1. Create a new source flexvol volume (Ex- Volfg2) in cluster1. Check the volume style.




2.Mount the Flexvol in Linux Server and create files.






3. Create a destination flexvol volume (Ex- volfg2_dr) with DP type  in cluster2.




4. In cluster2, Create a snapmirror relationship.

Source : Cluster1  Vserver : svm_src1   Volume: volfg2
Target  : Cluster2  vserver : svm_dst1    volume : volfg2_dr




5. Initialize the snapmirror relationship.




6. To convert Flexvol to flexgroup, first quiesce the relationship.




7.Now verify the conversion process (-check-only option). Rectify if you will get any error.



8. Start the volume conversion in cluster2 (Snapmirror Destination volume).





9. Check the destination volume volume style. It changed to flexgroup.



10. Now convert the source volume in cluster1. (source volume - volfg2)





11. Successfully converted to flexgroup.



12. Then, in Cluster2 resync the snapmirror relationship.




Important: You cannot convert a FlexGroup volume back to a FlexVol volume.

Sunday, April 12, 2020

NetBackup - Performing ORACLE Database restores using RMAN Client




Overview of using NetBackup for Oracle

The NetBackup graphical user interfaces and command line interfaces let you perform Oracle backup and recovery operations using Oracle RMAN utilities. You can also use the Oracle Enterprise Manager to perform Oracle backup and recovery operations. The Oracle RMAN command line interface is also used to maintain and query the RMAN repository.


About NetBackup for Oracle restores

NetBackup for Oracle includes a recovery wizard that solicits information from the user about the desired RMAN restore and recovery operations. The wizard uses the information to create a template.
The recovery wizard saves a recovery template locally in a user-specified location on the NetBackup client. Recovery templates are not stored on the master server because recovery is always user directed, not scheduled.

Because recovery can be a complex process, it might be necessary to perform manual steps as part of the operation.

The wizard does not restore control files.

Before going for restore, ensure the backup has completed with status code 0.


In this example I have created OIP (ex: orap1).

For further information click :  ORACLE RMAN BACKUP

Run a manual backup to test the restore.




Oracle database backup job started successfully.




In a Detailed job status, you can see RMAN commands are using to take a backup of oracle database.




Backup job completed successfully.






Performing Restore:

You can use NetBackup Client restore wizard to restore the Oracle DB.







Restoring DB using RMAN Client:

Use the bplist command to list oracle backups for the particular client.

You can use this command in NetBackup Master server or Client.
 






For testing oracle restore scenario, I had shutdown the ORCL database and rename the control file.





Start the database with nomount option.




Using RMAN Client, connect to Target and Catalog Databases.


> rman target sys/password catalog rman/password@catalogdb
Connected to both the databases successfully.




Run the following RMAN command to restore the Control file.

Master Server Name: nbumaster
Ora_client : windbsr



It is restoring the control file.


Control file restored successfully.





Use the following command to restore the database and recover the database.




Reading from the backup piece and restore starts.




Restore job completed successfully.




Then open the Database to access.




Now you can login to sqlplus and access the database.




Same as you can run a backup also using RMAN Client.

You need Default Application schedule is mandatory.

In this example I have used the following:


Master : nbumaster  

ORA_Client: windbsr   

ORA_Policy: orap2








Backup job completed successfully.