![](https://csdnimg.cn/release/download_crawler_static/11546442/bg11.jpg)
17
this could take a long time depending on whether the data is inconsistent and the quantity
of it to be checked and then repaired. You should really factor this issue into your recovery
time objectives. The first thing to ensure in your DR plan is that you have an effective
backup and restore strategy to handle possible data corruption and virus attacks.
Principles of Storage Management and Replication
In my next chapter I will document in detail a series of different storage systems. Before I
do that I want to write very briefly and generically about how storage management is
handled by the vendors – and how they commonly manage duplication of data from one
location to another. By its necessity this following section is going to be very vanilla and
not vendor specific, so to address that issue I will end with a whole series of web links
from these many varied storage vendors that point to their specific documentation which
outlines their requirements for their arrays and their configuration with VMware’s Site
Recovery Manager.
When I started writing the first edition of this book I had some very ambitious, I would
say outlandish hopes, that I would be able to cover the basic configuration of every
storage vendor and how to get VMware’s SRM communicating to them. However, after a
short time I recognised how unfeasible and unrealistic this ambition was! In this second
edition I hope to out-source this content to people in the VMware/Storage Community and
release this material as PDFs as a companion to this book. After all this is a book about
VMware’s SRM – not storage. But storage and duplication is an absolute requirement for
VMware’s SRM to function, so I would feel it remiss of me not to at least outline some
basic concepts and caveats for those for whom storage is not the daily meat and drink.
Caveat Number 1: In essence all storage management systems are the same, it’s just
that storage vendors confuse the hell out of everyone (and me in particular) by using their
own vendor specific terms. The storage vendors have never got together and agreed on
terms. So for some vendors a “storage group” is a “device group” whereas others will call
this a “volume group”. For others a volume is a LUN, but with another storage vendor
“volumes” are collections of LUNs.
Indeed some storage vendors think that the word LUN is some kind of dirty word, and
storage teams will look at you like you are from Planet Zog if you use the word LUN. In
short, download the documentation from your storage vendor – and immerse yourself in
their terms and language – so that they become almost second nature to you. This will
stop you feeling confused, and reduce the number of times you put your foot in
inappropriate places when discussing data replication concerns with your storage guys.
Caveat Number 2: All storage vendors sell replication. In fact they may well support
three different types and a fourth legacy type that they inherited from a previous
development or acquisition – and oh, they will have their own unique trademarked product
names! Some vendors will not implement or support ALL their types of replication with
VMware SRM. So you may have a license for replication type A, but your vendor only
supports type B, C and D – this may force you to upgrade your licenses, firmware,
management systems to support either type B, C or D. Indeed in some case you may well
need a combination of features forcing you to buy B and C or C and D. In fairness to the
storage vendors, as SRM has matured you will find they support all their different types of
replication. This is mainly been triggered by responding to their competition.
In a nutshell it could well cost you money to make the switch to the right type of
replication. Alternatively, you might find that although the type of replication you have is
supported – you discover it isn’t the most efficient from an I/O or storage capacity
perspective. A good example of this situation is with EMC’s Clariion systems. On the
Clariion system you can use a replication technology called MirrorView. In 2008,
MirrorView was supported by EMC with VMware’s SRM, but only in an asynchronous mode,
not in a synchronous mode. However, by the end of 2008 this support changed. The