VMware-vSphere5.5-Platform-Whats-New(14)

vSphere 5.5最新资料

What’s New in VMware vSphere 5.5 Platform vSphere Replication then retained the most recent redo log as a snapshot, which would be automatically committed during a failover. This snapshot was retained in case of error during the commit; this would ensure that during crash or corruption, there was always a “last-known good snapshot” ready to be committed or recommitted. This prevents finding only corrupted data when recovering a virtual machine.

Historically, the snapshot was retained but the redo log was discarded. Each new replication overwrote the previous redo log, and each commit of the redo log overwrote the active snapshot. The recoverable point in time was always the most recent complete replication.

A new feature is introduced in vSphere 5.5 that enables retention of historical points in time. The old redo

logs are not discarded; instead, they are retained and cleaned up on a schedule according to the MPIT retention policy.

For example, if the MPIT retention policy dictates that 24 snapshots must be kept over a one-day period, vSphere Replication retains 24 snapshots. If there is a 1-hour recovery-point objective (RPO) set for replication, vSphere Replication likely retains every replication during the day, because roughly 24 replicas will be made during that day.

If, however, a 15-minute RPO is set, approximately 96 replications will take place over a 24-hour period, thereby creating many more snapshots than are required for retention. On the basis of the retention policy cycle (for example, hourly—24 retained per day), vSphere Replication scans through the retained snapshots and discards those deemed unnecessary. If it finds four snapshots per hour (on a 15-minute RPO) but is retaining only one per hour (24-per-day retention policy), it retains the earliest replica snapshot in the retention cycle and discards the rest.

The most recent complete snapshot is always retained, to provide the most up-to-date data available for failover. This most recent complete point in time is always used for failover; there is no way to select an earlier point in time for failover. At the time of failover, the replicated VMDK is attached to the virtual machine

within the replicated vmx, and the virtual machine is powered on. After failover, an administrator opens the snapshot manager for that virtual machine and selects from the retained historical points in time, as with any other snapshot.

Additional vSphere 5.5 Storage Feature Enhancements

VAAI UNMAP Improvements

vSphere 5.5 introduces a new and simpler VAAI UNMAP/Reclaim command:

# esxcli storage vmfs unmap

As before, this command creates temporary files and uses UNMAP primitive to inform the array that these blocks in this temporary file can be reclaimed. This enables a correlation between what the array reports as free space on a thin-provisioned datastore and what vSphere reports as free space. Previously, there was a mismatch between the host and the storage regarding the reporting of free space on thin-provisioned datastores.

There are two major enhancements in vSphere 5.5: the ability to specify the reclaim size in blocks rather than as a percentage value; dead space can now be reclaimed in increments rather than all at once.

VMFS Heap Improvements

In previous versions of vSphere, there was an issue with VMware vSphere VMFS heap: There were concerns when accessing open files of more than 30TB from a single vSphere host. vSphere 5.0 p5 and vSphere 5.1 Update 1 introduced a larger heap size to confront this. In vSphere 5.5, VMware introduces a much improved heap eviction process, so there is no need for the larger heap size, which consumes memory. vSphere 5.5, with a maximum of 256MB of heap, enables vSphere hosts to access all address space of a 64TB VMFS.

T E C H N I C A L W H I T E P A P E R/14