Subscribe in a reader

Enter your email address:

Delivered by FeedBurner

 

Joe Kelly

 

 

« H.O.W:EMC PowerPath Virtual Server Path Management and PowerPath Encryption #EMCworld | Main | Session: EMC PowerPath and PowerPath/VE: What’s New in 2009 #EMCworld »
Tuesday
May192009

Session: EMC RecoverPoint-Best Practices for Replicating VMware ESX Server Env. #EMCworld

This session focuses on design considerations, use cases and best practices for RecoverPoint and VMware ESX and SRM integrations. The presenters for the session were Donald Kush and Hari Kannan. Note: Yes I had to go to at least one RecoverPoint session just out of curiosity, although I came out none the wiser. But I did get to see some RP 3.2 goodness.

The first 10 to 15 minutes of this presentation were focused on a brief overview of RecoverPoint that touched on the following:

The next 15 minutes were tuned toward “What’s New” with the current release of RecoverPoint, even though 3.1 has been out for several months. There were some shoulder rubs on what was coming in 3.2, of which I will mention in a few. Here are a few notes on the initial thought…

  • Integration with Virtual Infrastructure
  • Virtual provisioning aware
  • Integration with Hyper-V virtual infrastructure

Advanced Deployment Topologies

  • Recoverpoint Cluster Enabler
  • Synchronous replication over fiber or stretched CDP to you and me

Backup and Recovery Integration

  • Journal snapshot consolidation for extended retention and recovery
  • Expanded integration with Networker and Replication Manager (for application consistent bookmarking)

Expanded Deployment Scenarios

  • 2 site stretched CDP configurations
  • 3 site replication configurations (cascaded)

RecoverPoint with Replication Manager for VMware

  • Manages RP for Clariion and Symm
  • Single pane of glass for managing CDP, CRR and CLR application and VM consistency
  • Automate replica management

RecoverPoint Considerations for Replication

Looked at the following use cases:

    • Failover, Failback, test failover, and failover to many points and time

Choice of location for Splitters

Array, Fabric and Host are your options, something I have touched on a number of times. Please visit here if there is any question to what splitter you should be using.

Support for Heterogonous Storage Array’s

  • EMC-X to EMC-Y replication
    • Symm-to-Clar (SAN only)
    • Clar-NS-480FC (SAN to NAS Head)
    • Support for 3rd party  storage arrays
    • Protection using local copy, remote copy, both

Ok so now finally, and I had to wait 45 minutes for this info. In the next release of RP there will be integration with vCenter. Which will give you a view into what VM exist within what consistency group, within what replication set and on what copy. Additionally it will also show the replication states of each VM, noted as Fully, Partly or Not All.

There were also some provisions and integration around P2V replication and V2V replication that I didn’t quite get but seemed important as there was some dedicated slides focused on this piece.

Ahh….Best Practices (RP and VMware) were up next and frankly I was looking for some real goodness hear but as you will see there was much to be desired. And to no fault to the presenters I was just expecting more, you’ll see what I am talking about…

  1. Map all replicated LUNs to all ESX servers
  2. All LUNs that make up a VMFS volume should be in the same consistency group
  3. VMFS FS should be balanced over different LUNs
  4. Fabric and CX based splitters only are supported for VMFS
  5. Fabric and CX splitters are required for interoperability with VMotion and DRS
  6. Host splitters require the use of RDM in physical mode. Only support 16 VM’s total in this configuration.
  7. ESX Env. tweaks-LVM.Enable.ReSignature=1
  8. Swap file on separate non-replicated LUN, transient data that does not need to be replicated. Ok I get it,I don’t design my SRM enabled environments in this manner, I think it is completely unnecessary and only complicates your environment but yet I still see this BP littered through out design considerations. Don’t agree sorry..
  9. Consistency Group-single or multiple datastores? Pro’s and cons to both, my stance? A single Datastore per CG if your environment allows it (ie.no VMs spread across multiple DS’s, as implied in BP #8)

There were some additional slides on SRM most notably the next release will be tolerant of CLR configurations within RP. Currently only CRR is supported.

Ok..and finally there was a  Demo of VMware Affinity (hasnt this been used?) which essentially is management at a per VM level within the RP management interface, nice! Here are the options that need to be configured within the RP GUI to make this happen.

  • Site-Production or Recovery
  • VC IP or DNS address
  • Port number (443)
  • Credentials for access to VC
  • Certificate file on VC server-this needs to be imported from the vCenter server itself

Additionally here are the options that are viewable once integration is configured:

  • Name of VM, vmhba#
  • IP address
  • Consistency Group
  • Copy involved
  • Replication Set
  • Datastore
    • Non VM LUNs such as local datastores that are not replicated

Last but not least there will be an additional option on a per CG that enabled SRM support. The option “Group is managed by SRM Management Mode”. From what I gathered, this keeps consistency between SRM failed over LUNs and LUNs failed over outside of SRM.

 

 

 

 

Enhanced by Zemanta

Reader Comments (1)

where can i get this paper you are referencing ?
i would like to play with the new version.

July 13, 2009 | Unregistered Commenteremawah1

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
All HTML will be escaped. Hyperlinks will be created for URLs automatically.