Am 11.09.2014 19:44, schrieb Dr. David Alan Gilbert:
For keeping the complete system state consistent on the secondary system
there must be a possibility for MC to commit/discard block device state
changes. In normal operation the mirrored block device state changes (block
buffer) are committed to disk when the complete checkpoint is committed. In
case of a crash of the primary system while transferring a checkpoint the
data in the block buffer corresponding to the failed Checkpoint must be
discarded.
I think for COLO there's a requirement that the secondary can do reads/writes
in parallel with the primary, and the secondary can discard those reads/writes
- and that doesn't happen in MC (Yang or Eddie should be able to confirm that).
The storage architecture should be ???shared nothing??? so that no shared
storage is required and primary/secondary can have separate block device
images.
I admit that my formulation was unintentionally a bit ambiguous :)
I should have written that a shared storage should not be mandatory.
I'm comming from an SMB environment and (redundant) shared storage
systems are still not usual in small companies :)
I looked for a storage agnostic approach which allows the number of
system components to be as low as possible and still get redundancy and
fault tolerance.
MC/COLO with shared storage still needs some stuff like this; but it's subtely
different. They still need to be able to buffer/release modifications
to the shared storage; if any of this code can also be used in the
shared-storage configurations it would be good.
The proposed approach with block filter and the commit/discard protocol
should be storage agnostic and will also work in a shared storage
environment, but only with distinct images (because of the protocol).
In case of a shared storage and a common image used by the primary and
secondary another storage protocol must be used.
It's not commit/discard but commit/rollback
The primary still sends asynchronously the block state changes. The
secondary buffers block device state changes but doesn't apply them in
normal operation. When the next checkpoint is complete the secondary
clears the buffer and forgets about the old block state data.
If the primary fails the secondary must rollback the common image with
the block state data corresponding to the actual checkpoint.
Otherwise the state of the image and rest of the system state on the
secondary will not be in sync.
When there is no block state data corresponding to the actual
checkpoint, then there is nothing to do on the storage for the secondary :)
There is a little danger in this though. When the secondary fails during
rollback, the common image will be left in an inconsistent state.
I think this risk cannot be avoided when using a common image. But this
unfortunate situation can also happen in other scenarios.
Sharing a common immage with this protocol will lead to a longer fail
over time in case of existing block device state data for the actual
checkpoint. The secondary must initiate the rollback and wait until all
blocks of the actual checkpoint are commited to the common immage before
taking over the active role.
Walid