Brocade Communications Systems StorageWorks 4400 - Enterprise Virtual Array Manual de usuario descargar pdf (Pagina 31)

Failover considerations

Failover occurs when a Site Recovery Manager recovery plan is executed, and the Site Recovery Manager

recovery plan is configured to fail over Site Recovery Manager protection groups that use replicated EVA

Vdisks as VMFS datastores or Raw Mapped LUNs. During normal operation, the replication path is from a

protected site (local site) to a recovery site (remote site). When a failure occurs at the local site (due to

hardware failure or the entire site loss) an administrator can initiate a failover. The replication path is

reversed from the recovery site to the protected site and the virtual machines are restarted at the recovery

site. With HP EVA Replication Adapter and Site Recovery Manager, the failover process is an automated

feature and the process is executed, using a recovery plan defined at the recovery site.

Site Recovery Manager also enhances the efficiency of testing disaster recovery plans. In this case, failover

executes in an isolated environment, and the environment is quickly and automatically cleaned up following

the testing to avoid disrupting operations. As a result, the IT team can minimize impact on the production

environment and avoid downtime for customers. Site Recovery Manager allows administrators to initiate a

test failover every time the environment goes through significant modifications or reconfiguration that can

possibly affect the recovery of the protected virtual machines and applications.

In a test failover, data replication is not suspended and the protected virtual machines keep running. To

simulate a storage unit failover, a snapshot is created for each of the replicated EVA Vdisk that is used by

the protected virtual machines. The snapshots are exposed to the recovery host and the protected VMs are

started in an isolated network environment. This is a nondisruptive process, but a heavily loaded array may

experience slight performance degradation when the snapshots are established. In addition, test failover in

some cases causes another side effect that may require additional planning prior to executing a test

failover. The non disruptive nature of the test failovers simulates an unplanned failover where the production

VMs are running in parallel with the recovered VMs.

Because databases are not quiesced during an unplanned failover, a number of transactions that were not

flushed to the database files exist. As a result, a consistency check or a soft recovery is usually required

when the VM and application are started during the execution of a test failover. This primarily affects

transactional applications, such as MS Exchange, SQL server, or My SQL.

Note: Soft recovery is used as a generic term here and refers to the action of

rolling forward or backward the transaction log to bring an application database

to a consistent and up-to-date state.

Failover in test mode provides an accurate unplanned failover simulation, including the application

recovery intricacies. However, transaction log replay and database consistency checks can generate a

significant amount of additional IOPS on the snapshots, which may affect the performance of the replicated

Vdisks parents and the housed applications. For this reason, HP recommends that you avoid peak

production hours to execute test failovers in environments where both sites are hosting production servers.

1 2 ... 26 27 28 29 30 31 32 33 34 35 36 37 38

Sin comentarios

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