Updated RP release yesterday here are the new features that lie within..

• Support for Gen 4 hardware-Support for Dell R610 hardware which uses a single, quad port QLE25XX 8Gb HBA
• Support for 8Gb/s SANs
• Enhanced support for thin LUNs on Clariion CX4 arrays with FLARE 29 installed
• Support for Clariion LUNs up to 32TB in size
• GUI for major and minor non-disruptive upgrades
• Brocade binding verification

There are also a number of issues fixed, so please take note of those as well.

Alright a little forward I admit but I wanted you to feel my point…

Ok. What option am I talking about? Namely the, “Consolidate snapshots between bookmarks”. Now a couple of things:

• The option has its purpose <to someone no doubt>. What it means is that the ONLY snapshots that will be consolidated are the ones between user defined bookmarks. ONLY…
• The option is unchecked by default. So its not EMC’s fault if you check the option and consolidation doesn’t work as intended. Know your options <myself included>, Although to me this should say Only Consolidate Snapshots between bookmarks as that is the producible outcome within the GUI.
• IMO the reference in the admin guide (page 51) is a bit, shall we say, poo-poo laden…

  Consolidate snapshots between bookmarks. Default = disabled. The system will snap the start and end times of the consolidation to a bookmark with the time stamp nearest to the times specified when daily and weekly consolidations are configured—within a ten percent range.

  NOTE: This setting has no effect on the Maintain all snapshots for
  period.

Where is this option located? See below,  but under the replica volume within your CG > policy configuration tab> protection settings…

  <-------Select the secondary copy under your CG                                                  

             What a consolidated snapshot looks like ---------->

 

Seems so sweet, so natural, to check this box, you know? It might as well be laced with white fluffy bunnies. One would think you would want to consolidate snapshots between bookmarks but oh no checking this option will cease system automated snapshot consolidation. As noted it only ceases automation, you can still consolidate snapshots outside of user defined bookmarks manually via the CLI.

For your reference the Primus number is emc216467 below…

Environment:	EMC SW: EMC RecoverPoint 3.1
Environment:	EMC SW: EMC RecoverPoint 3.1 SP1
Environment:	EMC SW: RecoverPoint with Snapshot Consolidation
Problem:	Automated Snapshot Consolidation does not appear to be working.
Problem:	No consolidated snapshots listed in journal.
Problem:	Snapshot Consolidation taken manually using the CLI work as expected when executing 'consolidate_snapshots'.
Root Cause:	This is a configuration issue. User enabled "consolidate snapshots between bookmarks" when configuring snapshot consolidation. This check box means that the snapshots that will be consolidated will be only the 'user' created bookmarks.
Fix:	Using the RecoverPoint Console, go to Policy and disable consolidate snapshots between bookmarks.
Fix:	Support Center: For more information consult Bugzilla defect number 17027 and 18199. Bugzilla access is only available to authorized Customer Service Representatives.

Well, well, well, what do we have here. A new point release from our old pal gill. Looks to be feature rich and full of tasty morsels. You’ve heard it from me before <until I was blue in the face> but again if you aren’t using RecoverPoint for your local and remote replication needs then perhaps you would have more fun kicking yourself in the chest. Hey to each his own..

Anyways lets take a look at some key improvements shall we…source as follows here.

• Synchronous replication support-Not sure I fully get this statement, “Data can now be replicated synchronously over Fiber Channel”. Yeah, yeah, OK, I get it but wasn’t this a feature in 3.1? I assumed that all replication over FC albeit local or remote (stretched CDP) was synchronous.  Continuing on with the next statement, the fact that you now have the option to always replicate in sync mode or always replicate in async mode or dynamically float between the two (which was the default option) is a welcome change. Now forcing sync replication was possible in 3.1 but hardly intuitive. It was a force regulation,  snapshot granularity/write lag tweak <hut, hut, hike> from what I remember.
• Hardware Management GUI wizards- You cant go wrong with GUI’s in my opinion. It simplifies common tasks providing workflow to multi step processes. Personally, I don’t feel I have to assert my smarts, my manhood, by truck in’ it up at the command line when a task can easily be accomplished via the GUI. I hear you, CLI has its place (i.e. scripting mundane tasks, larger env’s maybe) just don’t follow the herd on this unless you enjoy inflicting pain to yourself.  But hey, you know me I’m into simplicity as a virtue, doing what is right and efficient for our customers and ultimately making it reproducible and comprehendible for others to grasp. I don't have to manage these environments but I have a vested interest in seeing our customers succeed. Remember its not about you : ) Anyways here are the additions..
  • RecoverPoint Installation Wizard-this was available in 3.1 (or something like it) but not part of the RP management application.
  • Add New RPAs Wizard - HIP
  • RPA Replacement Wizard -HIP
  • Upgrade tool-Assists in providing NDU’s of 3.1 code to 3.2 code – HOO-
  • New RP/SE Installer Wizard -RAY
• New Management Application GUI wizards
  • Getting Started Wizard-Guides user through RP licensing, system reporting, alert settings for new installs.
  • New Consistency Group Wizard
  • Add Replication Set Wizard
  • Journal Volumes Wizard
• More Granular System Monitoring
  • Increased awareness around looming limits, i.e. licensing, RPOs, specific policies, etc.
• Stat tools-Optimized, Unified, and Amalgamized
  • Granularity of stats available at the per minute, hour, and day (per year available for this time frame)
  • Also available a tool that binds these stats into a graphical representation within Excel.
• vCenter Server Monitoring
  • This by far is one of the most magnetic features worth mentioning, integration between vCenter and the RecoverPoint Management. Yes you now have view-only insight into the replication status of each LUN within vCenter via RP GUI. In addition RP can even generate alerts informing you when a VM is no longer protected. Nice to see that VMware partnership leveraged a bit more..
• LDAP support
  • I hear the need for this a lot, it was only a matter of time before it made its appearance and the time is now. Complete integration with MS-AD.
  • With that said the Security-Admin role as been added to allow configuration of LDAP, change users, roles, and security levels. Sadly the “admin” account has been stripped of said permissions and has taken on custodial duties at a local Dairy Queen in Poughkeepsie NY, a real EGO killer if you ask me…
• Support for CLARiiON LUNs greater than 2TB and attachment of up to 2048 LUNs-CLARiiON Splitter Only
• Online help
  • Not sure if you ever noticed but prior to 3.2 there was no online help within the RP Management GUI, peachy addition if I must say.
• ESRS support
  • Now Available-Remote preemptive support, monitoring and auditing via secure means by EMC Support for your RPA’s.
• Improved SAN Diagnostics
  • Of note here, during the initial installation it is no longer possible to continue forth if there are any errors during the SAN Diagnostic phase.
• AND FINALLY VMWARE SRM TOLERENCE OF CLR CONFIGURATIONS WITHIN RECOVERPOINT IS NOW SUPPORTED. Note: Updated compatible SRA is not available from VMware’s site as of 6-26-2009.

Well that’s about it for now. This list is certainly not definitive as it only focuses on the new features. So I encourage you visit the source for more detail especially in the way of what this release fixes. Happy hunting and bravo EMC, thanks for making a great product even better!

 

Well its been a while, thanks for returning. This is the third installment of the Recoverpoint Bit Series, finishing it out with design considerations. Now to this point I have sprinkled in a few design tips for any Recoverpoint implementation such as repository sizing but really nothing else of any girth. Point noted. So lets see if I can change that…

Changes

First things first, lets make some changes here. The repository as part of 3.1 no longer should be sized to 124GB. Remember 4G for cluster metadata/configuration info and 120G  marking mode used in times of WAN flapping. Now the repository is sized to no larger than 5G and marking mode occurs, or is stored,  within the production journal volume, hence the size reduction.  So properly size your PJV for both marking mode operations and failback.

Journal Volume Sizes

Keep it tight, keep it snappy, this volume needs to perform well. Generally, it should be mirrored for protection and capable of sustaining a large amount of writes. RAID 1/0 may be overkill (depends on your env) so stick to R5, remember JVol’s can be expanded on the fly to increase throughput and capacity but keep the following in mind during creation.

• What is your RPO? How far back do you need to recover from?


• What is your change rate? Yeah easier said than done, when in doubt use the EMC rule of thumb, 20%..


• Will remote target side processing come into play? Temporary action or lengthy? Write activity?

For those sappy math buff’s out there here is an equation to determine your proper journal size OR you can engage your friendly neighborhood consultant to assist, we would be more than happy to help : )

Journal Size = [(data per second) * (required RPO in seconds) / (1 – target log size)] x 1.05

Consistency Groups

Any doubt what a Consistency Group is?  Maybe I can help. Design concerns? Here are a few..

• What are my maximums per CG?
  
  
  
  • 64 per RPA, 128 per cluster. No worries, remember you can have multiple replication sets per CG (or 2048 replicated LUNs in a single cluster). Now in points of failover a single RPA can handle 128 CG’s temporarily but depending on the amount of replicated traffic you could run into periods of high load (ie. system can’t keep up with replicating your data)
  
  
  
  


• A Consistency Group cannot span RPA’s so YOU will have to properly load balance your traffic across the available RPA’s. Manual process, done at CG creation or can be tuned on the fly or failed over to the another RPA with minimal interruption to replication.


• If cross consistency group consistency is needed across RPA’s or across CG’s on the same RPA consider using or defining a Group Set. This allows you to group (key word here) multiple CG’s together to establish a parallel bookmark for write consistency.

What else? WAN sizing and potential bottlenecks….although I may take a hiatus from RP posts for a short stint…

And for those that are visually impaired here is a quick sketch of how a typical Recoverpoint-CDP implementation would look. Although not represented the splitting could occur either at that host, fabric or array.

 

Well here you have it the first of a multi-vid series on RecoverPoint configuration scenarios. This vid walks through the process of configuring a Consistency group from scratch up to the point of adding the replication sets (soon, Bit II). The shots were taking from the 3.0 RP Simulator, so some options may be different or not available in relation to the current GA release, 3.1. I would love to hear any feedback you have, so please comment.

Screencast Hi-Res Video

[youtube=http://www.youtube.com/watch?v=PXeQRavx8ow]