Tuesday, January 29, 2013

Configuring SRA for Fujitsu DX8400 on SRM 5.0


Following my SRM Defitive Guide, today we will cover the configuration of Storage Replication Adapter (SRA) for the Fujitsu DX8400 storage on SRM 5.0

Components:
VMware vCenter: 5.0
Site Recovery Manager (SRM): 5.0
Storage Vendor: Fujitsu
Storage Model: DX8400
Replication Technology: Advanced Copy Manager 2.1

The document that comes with SRA, ETERNUS SF AdvancedCopy Manager Adapter for VMware SRM, provides you most the information you need to set up your SRM environment, but if you need some more information about the ETERNUS, I recommend you take a look at the following documents:


To operate ETERNUS Disk storage system from SRM server with AdvancedCopy Manager Adapter, you will need a way to manipulate the storage, the Copy Control Module can be used to that, once it’s configured you will be able to discovery and manages the storage arrays on behalf of SRM.
During the setup of AdvancedCopy, you will have to decide how to interact with the storage, there are 2 types of copy function: Copy function via SAN and Copy function via LAN.
My advise is to use copy via SAN, which works when the SRM server has access to a small LUN, some times called access volume, it works as a kind of control LUN.
If you decide to install SRM on a virtual server, provision this access volume as a RDM/RAW disk in physical mode. (Remember that this disk must be provisioned by the storage you have your replicated disks).
If you choose to use copy via LAN, basically, you point your SRM to another server, which already has AdvancedControl installed and an access volume to the replicated storage. IMHO, it just adds more complexity and dependency on your solution.
Also if testing recovery plans is on your mind, and of course, everyone wants to tests their plans, you will need to set up a snapshot LUN, with the same size of your replicated LUN, for each LUN you will protect.
You might think it’s a lot space to waste, well….that’s the way DX8400 works.


In the picture above, you see 2 sites where both of them have production LUNs, characterizing an active/active configuration. You might be wondering why there’s a snapshot LUN on the production side ?!?
Well, after a failover your production site will become the recovery site and before failback you might want to test the failback plan before going hot.

There’s also another point of attention, when configuring the snapshot LUN, which copy type to choose, QuickOPC or SnapOPC+, CHOOSE QuickOPC.

When using SnapOPC+, ATS locking cannot be used. Which means you need to disable ATS on your ESXi host, reverting back to SCSI reservation behavior, something we all avoid to getting into. If ATS locking is enabled, a recovery plan testing may fail.
Tip: There’s a small note on the procedure, which says, “It’s not possible to have the same logical volume number allocated to several different affinity groups.”
I had this problem on a client once, SRM was not able to identify the LUNs replicated, not being able to make SRM to works.
The issue was related with the note above; the client configured the replicated LUNs to a group of backup servers along with the ESXi servers, using different affinity groups. Once he removed the affinity groups for the backup servers from the replicated LUNs, it worked like a charm.

I know it’s a solution full of details, but everything is document, just read everything carefully and I’m sure you will succeed.

Good luck.



No comments:

Post a Comment

Who am I

My photo
I’m an IT specialist with over 15 years of experience, working from IT infrastructure to management products, troubleshooting and project management skills from medium to large environments. Nowadays I'm working for VMware as a Consulting Architect, helping customers to embrace the Cloud Era and make them successfully on their journey. Despite the fact I'm a VMware employee these postings reflect my own opinion and do not represents VMware's position, strategies or opinions. Reach me at @dumeirell

Most Viewed Posts

Blog Archive