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:
- ETERNUS SF AdvancedCopy Manager V15.0 Quick Reference.
- ETERNUS SF AdvancedCopy Manager V15.0 Installation and Setup Guide.
- ETERNUS SF AdvancedCopy Manager V15.0 OperationGuide.
- ETERNUS SF AdvancedCopy Manager V15.0 OperationGuide for Copy Control Module.
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.
