Brocade Communications Systems StorageWorks 4400 - Enterprise Virtual Array Manual de usuario Pagina 36

  • Descarga
  • Añadir a mis manuales
  • Imprimir
  • Pagina
    / 38
  • Tabla de contenidos
  • MARCADORES
  • Valorado. / 5. Basado en revisión del cliente
Vista de pagina 35
36
Conclusion
The test results and related information contained in this paper clearly illustrate how to properly plan for
and successfully deploy a fully operational remote copy infrastructure, using VMware vCenter Site Recovery
Manager in conjunction with HP Continuous Access EVA and the EVA VMware Site Recovery Adapter.
Key planning and deployment considerations include the following:
VMware vCenter Site Recovery Manager controls and orchestrates failover and test operations by using a
software component called the Storage Replication Adapter (SRA). The EVA VMware Site Recovery
Adapter (EVA SRA) provides the communication layer between VMware SRA and the EVA array. The
EVA SRA must be installed on both the local (protected) server and the remote (recovery) Site Recovery
Manager servers.
It is important to understand the hierarchical relationships between VMware recovery plans, VMware
protection groups, and VMware datastore groups, as well as how each maps to EVA DR groups. In
general, Site Recovery Manager datastore groups should map 1-1 with EVA DR groups, though it is
possible under certain circumstances for a datastore group to map to multiple EVA DR groups.
The addition of Continuous Access EVA, when used in conjunction with VMware, significantly changes
the planning considerations for implementing multipathing between the VMs and the EVA array.
When upgrading from a standalone to a protected environment with Site Recovery Manager, virtual
machine physical placement may have to be re-evaluated and modified to ensure that all VMs and their
data elements are appropriately mapped into the described hierarchies.
Key operational considerations include the following:
Site Recovery Manager provides the ability to fully test a disaster recovery plan by executing a failover in
an isolated environment. This environment is quickly and automatically cleaned up following the testing to
avoid disrupting production operations. The impact of testing failovers that include application recovery
can be mitigated with adequate disk array and server sizing.
When an environment is significantly modified or reconfigured, initiate a test failover to ensure that the
recovery plans remain fully operational.
Because both unplanned failovers and test failovers leave databases in a crash-consistent state, some
number of uncommitted transactions exist that were not written to the database files. This requires a data
consistency check (soft recovery) when the VMs and applications are re-started during a failover. The
resulting application recovery intricacies (transaction log replay, database consistency checks, and so
forth) can generate a significant amount of additional IOPS, which in turn may affect overall
performance. For this reason, HP recommends avoiding peak production hours when executing test
failovers.
Managing the failback process with Site Recovery Manager is a manual process, and the steps vary
depending upon the degree of failure at the protected site. For example, if failback follows an unplanned
failover, a full data re-mirroring between the two sites may be required.
The combination of understanding all of these major considerations, along with knowing exactly what to
do, are keys to the successful deployment of a remote copy infrastructure when using VMware vCenter Site
Recovery Manager in conjunction with HP Continuous Access EVA and the EVA VMware Site Recovery
Adapter. The test-proven techniques developed here serve as a complete guide that can be used with
confidence to ensure success.
Vista de pagina 35
1 2 ... 31 32 33 34 35 36 37 38

Comentarios a estos manuales

Sin comentarios