Brocade Communications Systems StorageWorks 4400 - Enterprise Virtual Array Manual do Utilizador descarregar pdf (Página 17)

Figure 9. Site Recovery Manager datastore groups

Two factors determine what causes LUNs and datastores to be grouped together and not distinctly

managed.

First, a datastore spanning multiple LUNs causes those LUNs to be grouped together in the datastore group.

Failing over part of a datastore is not possible. In our example, the extended volume VMFS2 spans across

LUNs 2 and 3. Since all six virtual machines on that datastore sit only on volume VMFS 2 and touch no

others. VMFS 2 (and therefore LUNs 2 and 3) is alone in the second datastore group.

Second, a virtual machine can have multiple virtual disks and those virtual disks may reside in different

datastores or point to a Raw Device Mapping (RDM). In that case, RDMs and datastores are forced

together into a datastore group so that you do not try to fail over only part of a virtual machine. In our

example, LUN4 is formatted with VMFS3, and LUN5 is formatted with VMFS4. These LUNS are grouped in

a third datastore group because the virtual machine has a virtual disk in each VMFS datastore.

More than one virtual machine can, and generally should, be stored on each datastore or volume. With

Site Recovery Manager, choosing where to put virtual machines should be driven by the protected

applications service level agreement, the virtual machine’s relationships to each other, and performance. In

general, virtual machines that do not have a relationship to one another should not be mixed on the same

volume nor they should be mixed in the same Continuous Access DR Group. For example, a three-tier

application consisting of a database server, a web front end server, and the business logic application

server should be placed into the same protection group.

1 2 ... 12 13 14 15 16 17 18 19 20 21 22 ... 37 38

Sem comentários

Brocade Communications Systems StorageWorks 4400 - Enterprise Virtual Array Manual do Utilizador Página 17