Hi Guys,
I know you can help us in this area so thought I'd post after a long time...
We are shortly going to have 2 Datacenters in the UK next year and are hoping to utilise Veeam Replication for DR. We will be using Backup as we do today direct to a smaller IBM SAN unit at each datacenter. We may be running ESXi 5 at this stage and need some guidance on best practices for the quickest and easiest DR scenarios. Approx. 300VMs.
DC1 - 3 ESXi Hosts - IBM XIV SAN Storage (Primary)
DC2 - 3 ESXi Hosts - IBM XIV SAN Storage (Primary / Secondary)
Network = 2 x 10Gb links between sites or more if needed but shared with other equipment.
We have a few options. DC1 will be primary but we will load balance VMs across both datacenters
Option 1 - We can mirror the SAN Storage asynchronously and just register the VMX files of the VMs at DC2 from DC1. Not sure how we could use Veeam in this scenario
Option 2 - Use Veeam Replication to at each DC to pull replicate the VMs that are not at each DC so we have a mirror copy of each. I guess we would not use SAN mirroring in this scenario.
Option 3 - ???
Please can you give us some ideas as we really want to stay with Veeam and possibly market it to the rest of our business based on the results we achieve for our project next year.
By the way...we are happy with Veeam backup at the moment and the replication but this solution should improve everything.
-
- Enthusiast
- Posts: 35
- Liked: never
- Joined: Dec 02, 2009 8:32 am
- Full Name: Amit Panchal
- Contact:
-
- Chief Product Officer
- Posts: 31814
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Veeam for DR Best Practices
Hi Amit,
Storage level replication (SAN mirroring) is awesome! If you have 2 SANs and good WAN link, why not use it? This will give you great protection from certain types of disasters (such as natural, when the whole site goes down) with amazing RTO and RPO.
Top 10 consideration around storage level replication to keep in mind (in no particular order):
1. Requires doubling your storage (expensive). Not an issue for you, since you already own boxes.
2. Very traffic inefficient (you will need fat WAN link to handle the traffic - there going to be a lot). Links are expensive. If your WAN link cannot handle the load, use Veeam replication (more traffic efficient). Again, not an issue for you though with 2 x 10Gb links.
3. Site-wide outage is less than 1% of cases, single VM outage is more than 99% of cases. Are you going to failover the whole site over a single VM outage? Probably not! This is why you need to additionally replicate your most critical VMs with low RTO with Veeam. Don't worry about other VMs with normal RTO, you can just restore them from backup if they fail.
4. SAN snapshot is not a backup, because SAN outage will take away all the snapshots as well. Proper backups must always be done to 3rd storage, whether or not you use SAN mirroring. You are doing right already, so you are good here.
5. Any SAN data corruption will be mirrored nicely to DR SAN. Thus, consider Veeam-replicating most critical VMs with lwo RTO with Veeam to local ESXi storage in DR site (again, 3rd storage rule) to be able to meet RTOs in case of such disaster. Connected with (3).
6. You need multiple restore points no matter how you do your replication (to protect from viruses, silent app data corruption etc). You don't typically notice these kind of things until it is too late. Make sure you can do that with your SAN replication, if not - Veeam provides that - again, use for most critical VMs.
7. Asynchonous SAN replication is preferred if your RPO is not zero (usually SAN vendors implement at least some level of consistency with async replication - and consistency is always better than inconsistency). Synchronous replication is crash-consistent (technically RPO is still not zero - anything in-flight will be lost - but very close to zero).
8. SAN snapshots are not application-aware and do not implement application-specific back and restore steps (chance of issues upon recovery with the certain apps). Again, always have a proper and tested Veeam backup available for cases like that (your last resort), and preferably replicas for most critical VMs to be able to meet RTO (see 3 and 5).
9. Test failover! May end up finding serious flaws (such as replica re-IP requirement).
10. Use Veeam v6 for best results with ESXi targets.
If I sound too negative about SAN replication, I just sound so. Just wanted you to be aware about all the issues and considerations, however I cannot stress enough how great storage level replication is if you can afford it (bullets 1 and 2). Nothing better against natural disasters, blackouts, SAN outages, etc.
Hope this helps.
Storage level replication (SAN mirroring) is awesome! If you have 2 SANs and good WAN link, why not use it? This will give you great protection from certain types of disasters (such as natural, when the whole site goes down) with amazing RTO and RPO.
Top 10 consideration around storage level replication to keep in mind (in no particular order):
1. Requires doubling your storage (expensive). Not an issue for you, since you already own boxes.
2. Very traffic inefficient (you will need fat WAN link to handle the traffic - there going to be a lot). Links are expensive. If your WAN link cannot handle the load, use Veeam replication (more traffic efficient). Again, not an issue for you though with 2 x 10Gb links.
3. Site-wide outage is less than 1% of cases, single VM outage is more than 99% of cases. Are you going to failover the whole site over a single VM outage? Probably not! This is why you need to additionally replicate your most critical VMs with low RTO with Veeam. Don't worry about other VMs with normal RTO, you can just restore them from backup if they fail.
4. SAN snapshot is not a backup, because SAN outage will take away all the snapshots as well. Proper backups must always be done to 3rd storage, whether or not you use SAN mirroring. You are doing right already, so you are good here.
5. Any SAN data corruption will be mirrored nicely to DR SAN. Thus, consider Veeam-replicating most critical VMs with lwo RTO with Veeam to local ESXi storage in DR site (again, 3rd storage rule) to be able to meet RTOs in case of such disaster. Connected with (3).
6. You need multiple restore points no matter how you do your replication (to protect from viruses, silent app data corruption etc). You don't typically notice these kind of things until it is too late. Make sure you can do that with your SAN replication, if not - Veeam provides that - again, use for most critical VMs.
7. Asynchonous SAN replication is preferred if your RPO is not zero (usually SAN vendors implement at least some level of consistency with async replication - and consistency is always better than inconsistency). Synchronous replication is crash-consistent (technically RPO is still not zero - anything in-flight will be lost - but very close to zero).
8. SAN snapshots are not application-aware and do not implement application-specific back and restore steps (chance of issues upon recovery with the certain apps). Again, always have a proper and tested Veeam backup available for cases like that (your last resort), and preferably replicas for most critical VMs to be able to meet RTO (see 3 and 5).
9. Test failover! May end up finding serious flaws (such as replica re-IP requirement).
10. Use Veeam v6 for best results with ESXi targets.
If I sound too negative about SAN replication, I just sound so. Just wanted you to be aware about all the issues and considerations, however I cannot stress enough how great storage level replication is if you can afford it (bullets 1 and 2). Nothing better against natural disasters, blackouts, SAN outages, etc.
Hope this helps.
-
- Enthusiast
- Posts: 35
- Liked: never
- Joined: Dec 02, 2009 8:32 am
- Full Name: Amit Panchal
- Contact:
Re: Veeam for DR Best Practices
Thanks gostev. Some good answers there. Might get a member of my team to talk to you at vmworld just to make sure we are all good in this area.
Who is online
Users browsing this forum: Bing [Bot], Google [Bot], Semrush [Bot] and 40 guests