![]() I don't need to put in the source path as well because we can only replicate one volume into the destination - when I specify the destination path, the system knows which replication I'm referring to. We can specify just the destination path. To do that, we use the ‘snapmirror initialize’ command. When we put the ‘snapmirror create’ command in, it creates the relationship but it doesn't actually replicate any data across yet. In our example, we are using a 10-minute schedule. We say ‘-type dp’ for a Data Protection mirror. The destination path in our example here is ‘DeptA_DP:vol1_DP’. The command for this is ‘snapmirror create’. This says that it's going to be used as the destination for a SnapMirror relationship, which turns it into a read-only volume. When you create the destination volume, it needs to be at least as big as the source volume. We've put it in aggr1 with a size of 100 gigabytes. We create a volume called ‘vol1_DP’ that we're going to use to replicate volume 1 from the source site. Here we’ve named the VServer on the destination side ‘DeptA_DP’. These commands are all done on the DR site.Īfter we've created an SVM we need to create a volume to replicate the data into. Next, we're ready to create and initialise the volume mirror relationship. We also need to peer the SVMs.Ĭreate and Initialise NetApp SnapMirror Volume Mirror Relationship After we've done that, we can then peer the clusters. Then, we also need to configure Intercluster and logical interfaces on every node in both clusters. Use the ‘license add’ command to license SnapMirror on both clusters. To configure, we need to run through the initial configuration steps. Initial Configuration Steps on Both Clusters This saves me having to buy and manage tape devices in each of my sites. We’re replicating them all into a central site where my tape devices are also located so I can back them up there. In the example here, we've got multiple remote systems. The final reason that we're going to cover is for staging to remote tape. If we had some data that was in Singapore and we wanted to move it across to Sydney, we could use a DP mirror. It's kind of like building your own content delivery network.Īnother reason we can use SnapMirror Data Protection mirrors is for data migration. Not only does this give us a disaster recovery solution, because we've got the data in more than one site, but it also gives us load balancing for our read-only data. We're going to give them the lowest latency access based on where they're accessing the data from. What we can do is direct the users who are based in Southeast Asia to the Singapore or KL sites and the users who are based in Australia to the Sydney site. Let's say we've also got a read-only copy in Sydney. The Singapore site is the writable copy and KL is the read-only copy. In this configuration, let's say that our main site is in Singapore and we've got another site in Kuala Lumpur. A read-only load balancing setup consists of a writable copy at the source site and read-only copies in the destination remote sites. The next reason to use NetApp SnapMirror DP mirrors is for read-only load balancing. If you want to be able to maintain the same performance during a disaster, then you will have to use the same disk types in both sites. The reason being if you do have to failover and the DR site is running SATA disks, you're going to have a performance hit until you can get your primary site running again. To save money we can use less expensive drives in the DR site because it's just being used as a hot spare.ĭeciding on the types of disks to use will need to be a management decision though. In this scenario, we could use inexpensive SATA drives in the DR site and SSDs or SAS drives in the primary site. We're going to use DP mirrors to replicate from the source site to our destination, the DR site. Let’s say we have a main site that we're using as the active site for our data, and we also have a standby disaster recovery site. The first reason mentioned, and the best-known reason for implementing Data Protection mirrors is for disaster recovery. When we talk about ‘NetApp SnapMirror’ in general, we're talking about DP mirrors. To replicate data to a centralised tape backup location.To replicate data between different SVMs in the same cluster.To provide load balancing for read access across different sites.When used for disaster recovery, intervention is required to failover to the DR site. This is usually the main reason we use DP mirrors. To replicate data between volumes in different clusters for disaster recovery.They can be used for the following reasons: Typically we'll be replicating to a different cluster. NetApp SnapMirror Data Protection DP Mirrorsĭata Protection mirrors can replicate a source volume to a destination volume in the same or in a different cluster. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |