VMware Site Recovery Manager 4.0详解：配置与管理指南

需积分: 10 121 浏览量更新于2024-07-17 收藏 20.35MB PDF 举报

《Administering VMware Site Recovery Manager 4.0》是一本由Mike Laverick撰写的专业指南，涵盖了VMware Site Recovery Manager (SRM) 4.0的系统管理和设置教程。该书旨在帮助读者深入了解和管理灾难恢复解决方案，特别是与EMC Celerra Replicator、EMC Clariion MirrorView/S和HP LeftHand Scheduled Remote Copy等存储阵列的集成。第1章介绍了SRM 4.0的背景和新特性，强调了本书的目的和适用范围。它提到，SRM是VMware的一款关键产品，用于实现虚拟机的快速、高效灾备恢复，通过存储管理、复制和文件一致性保障。章节中还提到了技术原理，以及如何利用存储厂商的指导文档。第2章详细讲解了如何与EMC Celerra Replicator协作，包括创建iSCSI目标、授权ESX主机访问权限、建立新的文件系统和iSCSI LUN，以及配置数据复制。这一章着重于实际操作步骤，确保读者能够顺利配置和管理Celerra Replicator。第3章介绍了EMC Clariion MirrorView/S的使用，包括创建LUN、配置镜像视图和一致性组，以及授权ESX主机访问Clariion存储。这里强调了推荐的做法，以便提高灾备性能和数据一致性。第4章专门针对HP LeftHand Scheduled Remote Copy，解答了一些常见问题，并指导读者如何下载、安装和配置VSA，以及对VSA主机进行基本配置。这部分内容关注实际部署中的注意事项和最佳实践。《Administering VMware Site Recovery Manager 4.0》是一本实用的指南，适合IT专业人员在实施和维护SRM 4.0时参考，旨在确保高效的虚拟机灾备策略和存储资源管理。书中提供了丰富的实战经验和深入的技术细节，对于那些希望提升灾备能力的读者来说，是一份宝贵的资源。

leave a big question mark over the long-term viability of such “third party software” based

replication. However, the door is open to VMware developing host-based replication in

future editions of ESX. This might be attractive to SMBs who find storage vendor based

solutions cost prohibitive.

As replication or snapshots are an absolute requirement for SRM to work, I felt it was a

good idea to begin with covering a couple of different storage arrays from the SRM

perspective. This will give people a basic run through on how to get the storage replication

or snapshot piece working – especially for those like myself who would not class

themselves as storage experts. Remember that VMware’s SRM does not currently provide

a replication or snapshot engine or control that engine. This book does not constitute a

replacement for good training and education in these technologies, ideally directly from

the storage array vendor. If you are already confident with your particular vendor’s

storage array replication or snapshot features you could decide to progress to Chapter 6:

Installing VMware SRM.

It was my very good fortune to be introduced via the product manager for SRM to guys

from LeftHand Networks at the VMworld Europe event in Cannes in 2008. From that

introduction I was offered two free NFR licenses for LeftHand Networks iSCSI SAN Virtual

Appliance for testing purposes, called the VSA. Some time later I was introduced to guys

from both EMC and NetApp. I became very interested in these storage technologies both

from a SRM and VDI perspective. I was fortunate in having access to two EMC NS20 and

NetApp FAS2020 systems whist writing this book – it was this that allowed me to spread

my knowledge into other storage vendors replication technologies.

In terms of the initial setup – I will deliberately keep it simple – starting with a single

LUN/volume replicated to another array. However, later on I will change the configuration

so I have multiple LUN/Volumes with virtual machines that have virtual disks on those

LUNs. Clearly, managing this frequency of replication will be important. If we have

multiple VMDK files on multiple LUNs/Volumes – the parts of the VM could easily become

unsynchronized or even missed out all together in the replication strategy – thus creating

half-baked, half-complete VMs at the DR location. Additionally, at a VMware ESX host

level, if you use VMFS extents but fail to include all the LUNs/Volumes that make up those

extents – then the extent would be broken at the recovery location and the files making

up the VM corrupted. So how you use LUNs and where your VMs are stored can be more

complicated than this simple example will first allow. Our focus is on VMware SRM, not

storage. However, with this said a well thought out storage and replication structure is

fundamental to an implementation of SRM.

What about File Level Consistency?

One concern you will and should have is what level of consistency will the recovery have?

This is very easy to answer – the same level of consistency had you not virtualized your

DR. Through the storage layer we could be replicating the virtual machines from one site

to anther synchronously. This means the data held at both sites is going to be of a very

high quality. However, what is not being synchronized is the memory state of your servers

at the production location. What this means is, if a real disaster occurs that memory state

would be lost. So whatever happens there will be some kind of data loss incurred unless

your storage vendor has a way to quiesce the applications and services inside your virtual

machine. This level of awareness inside the virtual machine was historically limited to your

backup software, but increasingly storage vendors such as EMC and NetApp are hooking

into the new VMware vStorage APIs – which allow for such things as VMware Snapshots to

be created.

So although you may well be able to power on virtual machines in a recovery location –

you may still need to use your application vendor’s tools to repair these systems from this

“crash consistent” state – indeed if these vendor tools fail you may be forced to repair

them with something called a BACKUP. With applications like Microsoft SQL and Exchange

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

reason this was so significant to EMC customers is because of the practical limits imposed

by synchronous replication. Although synchronous replication is highly desirable it is

frequently limited by distance between the Protected and Recovery Site. In short the

Recovery Site is perhaps too close to the Protected Site to be regarded as a true DR

location. At the upper level synchronous replication’s maximum distance is in the range of

400-450Km, however in practice the real world distances can come down as low as 50-

60Km. The upshot of this limitation is that without asynchronous replication it becomes

increasingly difficult to class the Recovery Site as a genuine DR location. Distance is

clearly relative – in the US these limitations become especially significant as the recent

hurricanes have demonstrated, but in my postage stamp sized country they are perhaps

less pressing!

If you’re looking for another example of these vendor specific support differences, HP

EVAs are supported with SRM. However, you must have licenses for both their “Business

Copy” feature and their “Continuous Access” technology for it to function properly. The

Business Copy license is only used when snapshots are created during testing a SRM

Recovery Plan. The Continuous Access license enables the replication of what HP rather

confusingly call “vdisks” in the storage groups.

Caveat Number 3: Storage management systems have lots of containers which contain

other containers and so on. This means the system can be very flexibly managed. You can

see this a bit like Microsoft having a rich and varied group structure options in Active

Directory. Beware that sometimes this means that storage replication is limited to a

particular type of container or level. This means you or your storage team have to sit

down very carefully and think how you will group your LUNs to ensure that you ONLY

replicate what you need to and that your replication process doesn’t in itself cause

corruption by mismatched replication schedules. Critically, some storage vendors have

VERY specific requirements about the relationships between these various containers when

used with VMware SRM. Additionally, some storage vendors impose naming requirements

for the name of these objects and snapshots. If you deviate from these recommendations

you might find that you can’t even get SRM communicating with your storage correctly. In

a nutshell it’s a combination of the right type of replication coupled with the right

management structures that will make it work – and you can only know that by consulting

the documentation that comes with your storage vendor. In short – RTFM!

Now we have these caveats in place. I want to map out the structures of how most

storage vendors’ systems work – and then outline some storage planning considerations. I

will initially use non-vendor specific terms. Below is a diagram of a storage array which

contains many drives.

In this case:

A. is the array you are using, whether this is fibre-channel, iSCSI or NFS it isn’t dreadfully

important in this case.

B. shows that even before allowing access, many storage vendors allow disks in the array

to be grouped. For example NetApp refers to this grouping as a disk aggregate, and this is

often your first opportunity to set a default RAID level.

C. is another group – this is referred to by some vendors as a storage group, device group

or volume group.

D. Within these groups we can have blocks of storage, and most vendors do call these

LUNs. With some vendors they stop at this point, and replication is enabled at Group Type

C indicated by arrow E. In this case every LUN within this group is replicated to the other

array – and if this was incorrectly planned you might find LUNs that did not need

replicating were being unnecessarily duplicated to the recovery location wasting valuable

bandwidth and space.

F. Some storage vendors allow for another sub-group. These are sometimes referred to as

recovery groups, protected groups, contingency groups or consistency groups - in this

case only LUNs contained in Group E are replicated to the other array. LUNs not included

in sub-group E are not replicated. If you like, group C is the rule, but group E represents

an exception to the rule.

G. The last group is G: this a group of ESX hosts that allow access either to Group C or

Group E depending on what the array vendor supports. These ESX hosts will be added to

Group G by either the fibre-channel WWN, iSCSI IQN or IP address or hostname. The

vendors who develop their Site Recovery Adapter (software that allows SRM to

communicate to the storage layer) to work with VMware’s SRM - often have their own

rules and regulations about the creation of these groupings, for instance they may state

that no group E can be a member of more than one group C at anytime. This can result in

SRA failing to return all the LUNs expected back to the ESX hosts. Some vendors SRAs

automatically allow the hosts access to the replicated LUNs/Volumes at the Recovery Site

剩余393页未读，继续阅读

drjiachen

粉丝: 171
资源: 2139

VMware Site Recovery Manager 4.0详解：配置与管理指南

Administering.VMware.Site.Recovery.Manager.5.0.pdf

Administering.VMware.Site.Recovery.Manager

if you are a server admin, the Firewall Policy is in place

有没有sqlserver2022的书籍

电脑升级改造纪实，增加路由器刷机固件

私域人员配置表.xlsx

捷报体育——体育保龄球打卡_HidordProject.zip

1997-2023年中国企业跨国并购数据Zephyr数据库(全新整理)

仿真-基于多智能体算法的城市交通信号控制仿真系统实现-附项目源码-优质项目实战.zip

51单片机温度传感器Proteus仿真

最新资源