Colocation to Virtualization

I had a demo of EMC Recoverpoint in the office today.  I manage 2 EMC Cariion units housing Oracle databases and VMWare fileystems.  The EMCs are currently connected with fiber running at 4 gig on Cisco MDS 9120 standalone units (not blade chassis).  It seems that this solution should work perfectly since the write splitting can be done in the EMC controllers… One hitch on our implementation.  Since a critical part of our database resides on a non EMC SAN device, we would need to upgrade the fiber network to Cisco MDS 9000 series blade systems.  This would allow us to put in a Storage Services Enabler (SSE) card in each switch, thus splitting writes in the fiber switch instead of the EMC.  Doing this would enable RecoverPoint to index the data of other SAN devices, in our case a NetApp and possibly the Texas Memory SSD SAN.  All of this would add up to a significant amount of money needed to go from non-modular to modular blade style Cisco switches.  Here is a little more information on the RecoverPoint system:

RecoverPoint currently come in 1u appliance chassis.  EMC will send 2 units per order, one being redundant.

From the demo, they do an amazing job of data replication!  One thing not to be confused about is the ability to do bi-directional replication allowing fail over from a primary site to a disaster recovery site.  Then replicate the changed data (only changes, not all the data) back to the primary site after the center is fully functional.

QOS

Each consistency group volumes can be assigned specific QOS (Quality of Service) settings that allow prioritizing, number of snapshots, time in between and alerting.  If a volume falls outside of the QOS thresholds the RecoverPoint can be set to alert via email and SNMP.

Hands off backups

One way to help justify the costs of moving to RecoverPoint in an EMC only implementation is the ability to get rid of the old backup systems.  The cost of server upgrades, direct attached storage, tape systems, etc can somewhat offset the final bill of implementing RecoverPoint.  Needless to say, I have to keep an eye out for any backup solution that I have ever worked with or implemented.  The ability to just step back and let “the plumbing (recover point)” handle this would be a load off of my shoulders.  RecoverPoint can be set to maintain longer term snapshots “point in time” in their words.  Be it a certain number, a week, month, or year.

Journal volume
The following is direct from EMC documentaiton.  I could not find better wording to describe it, so why re-write it?

“Journal volumes hold data waiting to be distributed to target volumes and also retain copies of the data
previously distributed to the target volumes. Each consistency group has its own journal volumes that allow
for differing retention periods across consistency groups. Each consistency group has two or three journal
volumes, one assigned to the local copy volumes (if present), one assigned to the remote copy volumes (if
present), and one assigned to the source volumes. Journal volumes are used for the source and both copies
in order to support production failover from the current active source volume to either the local or remote
copy volume.  Storage efficiency is realized in the history journal by retaining only the changes between
journal entries.  Additionally, the journal volume is also compressed, resulting in even more storage savings.
Source and target images on the CDP volumes are always consistent upon completing the distribution of each write
change.”

Miscellaneous

• RecoverPoint can be used with VMWare and Site Recovery Manager(SRM).  SRM can support up to 60 consistency groups(group of volumes).  This should be more than enough for most VM clusters.
• Can do application consistent snapshots
• Manual “bookmarks” (recovery points) can be created.  Example:  create a bookmark called “before patch” and then patch the database.  If any problems occur, you can rollback to the manual bookmark you created
• RecoverPoint has the ability to restore forwards and backwards through the recover points in the system.  This means that you could roll back to a point in time a week ago and if you so desired, move forward in time from that week could recover point to a newer one.  Basically, you do not loose all the newer points when you choose to recover to the older one.
• Allows for quick DR testing when incorporated with a VM environment
• Support up to 1000 volumes currently
• Compression can be setup and thresholds changed on each volume
• Alerting capabilities on almost all aspects of QOS and performance
• Each appliance supports up to 60 meg per second throughput
• For more throughput, more nodes(RecoverPoint servers) can be added, up to 8 servers.  This would bring the total transfer rate up to 480 meg per second
• The RecoverPoint server has two 73 gig drives for caching of changes.  In a short term link loss between locations, the information will be stored there.  When link is re-established, only the changes are sent.  No re-syncing all data.
• If a long tern outage occurs, all the write changes (markers) are still written to the local journal.  Once communication is back up, the system will then send those markers over.  Thus, allowing outages to span longer than what the local RecoverPoint cache can handle

In the near future, I will be sitting in on a true live demo of RecoverPoint.  This will incorporate a lab running VMWare and Oracle.  Will update after this happens.

Featurs from EMC

~ by Kevin Goodman on October 21, 2008.

Posted in Networking, SAN (Storage Area Network), VMWare
Tags: cisco, cisco recoverpoint, clariion, EMC, fiber, mds, mds 9000, mds 9120, recover point, RecoverPoint, sse, Storage Services Enabler, write splitting