I've just read your response to a question about storage virtualization. I agree with you about the performance benefits of out-of-band, but I've got a question...
I'd prefer to move the remote synchronous mirroring function into the virtualization space, in order to save on the license fees applicable to the disk subsystems, as well as being able to place data on appropriate price/performance devices. I'm somewhat uncomfortable with out-of-band because I'm not sure how we would ensure point-in-time consistency across multiple heterogeneous hosts in the event of a rolling disaster. I want to be able to emergency restart all of the databases should we have to fall back, such that they can all come up at the last transaction point.
I'm struggling to get my head around how out-of-band can achieve that. Can you help? Or should be considering in-band for this requirement?
I normally do not like to mention vendors specifically in these things, but I don't think I can answer your question without doing so. Topio claims to have a way to sync the I/Os from multiple systems in the point-in-time copy solution, but I do not understand how they perform the time sync between systems. I'm fairly certain they time-stamp all I/Os but I do not know how or if they are able to do so in multiple systems. You might want to talk with them for more details. Also, I do not know if their drivers are tested and compatible with the out-of-band virtualization drivers you may be considering.
Outside of that, yes it would appear that in-band virtualization would be able to sync the I/Os from multiple servers more easily since a single clustered in-band virtualization system could receive all I/Os and process them. But this is not necessarily foolproof either, as it makes the assumption that the network is working perfectly and not experiencing problems. After all, an event that causes a rolling blackout could impact the network in unexpected ways, preventing I/Os from being received at the in-band system as expected.
These are difficult areas, its good to know the limitations of your implementations. There are no perfect solutions.
This was first published in August 2004