i read vsphere replication document it say vr not use snapshot but realy i don,t understand how can work vr without use snapshot
From the VR FAQ (Storage and Availability Technical Documents):
VMware developed the vSphere Replication engine. The method vSphere Replication uses to track changes to a virtual machine is very similar to the CBT mechanism that is part of VMware vSphere Storage APIs – Data
Protection. However, it is not CBT, preventing interference with other solutions that utilize CBT—for example, VMware vSphere Data Protection. Virtual machine snapshots are not used at the source unless Microsoft
Volume Shadow Copy Service (VSS) quiescing is enabled when configuring replication. In that case, the virtual machine is quiesced, a snapshot is taken to capture the application-consistent state of the virtual
machine, the delta (changes) is created for replication, the snapshot is committed, and the delta package of data is replicated. This occurs with every replication cycle.
At the source location, changed blocks are tracked in memory. The actual contents of the blocks are not normally tracked, although there is an exception: If a block is changed (again) while replication is in progress, the
contents of the block are copied to the persistent state file (PSF) to ensure the consistency of the virtual disk at the target location. This can cause the PSF to grow considerably for virtual machines that have very high data
change rates. Copies of the blocks in the PSF are kept only until the replication cycle completes.
No. vSphere Replication does not replicate a virtual machine snapshot hierarchy from the source location to the target location. Snapshots are collapsed into a single aggregate virtual machine disk (VMDK) file at the target
location. In other words, a virtual machine with snapshots might be configured for replication, but it will be recovered with no snapshots—snapshot data committed—when it is recovered at the target location.
However, vSphere Replication 5.5 introduced Multiple Point In Time (MPIT) recovery. MPIT recovery enables an administrator to recover a virtual machine to the latest replicated copy at the target site and then revert, or “roll
back,” that virtual machine to a previous point in time. When MPIT recovery is configured, these recovery points appear as virtual machine snapshots at the target location when a virtual machine is recovered using vSphere
Replication. There are no dependencies between snapshots at the source location and recovery points at the target location. A virtual machine at the source location with no snapshots can still be configured to utilize MPIT
recovery with vSphere Replication.
This is a redo log found at the target location. This data is applied to the last consistent instance of the base disk after replication has completed successfully. The size of these files depends on the number of changes at the
source since the last successful replication cycle. It is possible for a redo log to be the same size as the source if all of the blocks have been changed, but this is unusual. After data has been committed successfully from the
redo log to the base disk, a new redo log is started. There are occasions when more than one redo log for a virtual disk is observed—for example, if multiple recovery points are enabled for the virtual machine.
so thanks but i said read these documents but clearly could not understand how vr work without snapshot because when it want sync or replicate have to freeze disk and during replication new data have to write to new disk and without snapshot how can freeze disk for prevent change on disk and how can create new disk?
Because it is tracking changes to the source vmdk in memory and then transferring these writes to the target vmdk and applying them - pretty similar to how array based replication works.
VR sits at the vSCSI filter level and sees the VM writing to its disks as it's doing it. It doesn't have to freeze anything to accomplish this.
For a great walk through of the tech check this out: BCO4977 - VMware vSphere Replication: Technical Walk-Through with Engineering
WHatever in understood is vr when doing replication keep all of new changes in memory of that machine is replicate and after replication finished transfer all of them to delta disk is that correct?
Within the RPO defined by the administrator, VR tracks which blocks are being dirtied and will create a “lightweight delta” (LWD) bundle of data to be transferred to the remote site. Pointers to changed blocks are kept in both a memory bitmap as well as a “persistent state file” (psf) located in the directory of a VM. Memory contents are always current, the PSF file represents the current shipping LWD. After an LWD is shipped and completely acknowledged, the memory bitmap is copied to the PSF file and the memory bitmap is restarted for the next LWD. VR will use the defined RPO to determine how often to create a LWD. Time must be allowed to create the block bundle, transfer it, and successfully complete writing the entire bundle to ensure that the RPO is not violated. In order to do this, VR will track the length of the previous 15 transfers to create an estimate of how long it will take to complete the transaction of the subsequent LWD.