On the surface VMware’s Site Recovery Manager (SRM) is heaven sent bringing the promise of taking your servers running in production and getting them back up in a DR site in a mostly automated way. SRM does deliver on this promise but as we see all to often, it’s not as easy as it looks and some thoughtful planning is a must. This blog is about some key considerations you should make if, like most people, you have different subnets in use at your DR site and you are using SRM to change the IP address of your severs during failover.DR sites are commonly using kit that has other primary uses, or is older, re-used ex-production kit. Typically, your DR site is going to offer lower performance. This is key for storage. While most companies are willing to take a performance and productivity hit in DR, recovery time objectives (RTO) are typically something that they aren’t willing to miss – when every hour of downtime costs money, getting those systems back online is critical. When you have low performance available from the storage, managing the load an SRM failover generates is key to having a successful recovery.
0 Comments
