|
I am a fan of using good (but not the extreme high-end) hardware with software-based replication. I have seen too many expensive, high-end storage arrays with hidden or poorly documented single points of failure, such as backplanes. Also, if the replication function was added on to the array's firmware, and is not native to the hardware; it can be less feature-rich than a product that was designed specifically for replication.
Once either kind of replication is set up and functioning, it should not require very much regular maintenance, so I don't think that should enter the decision process. (Note: I have not worked day-to-day with TrueCopy, and that's really the only way to know the degree of regular maintenance that a product requires.)
If the products you are looking to use require identical OS and VxVM revision levels, you should certainly meet those requirements. Even if it is not absolutely required, it is an excellent practice to run the same versions of the OS and of all system and otherwise critical applications on clustered systems. You don't want some subtle difference or incompatibility to bite you. Besides, how likely is it that your vendor has tested every combination of mixed versions that you might need?
You should also consider how much data will be lost in the event of a disaster. If replication is being done synchronously, you should only lose transactions that were in process when the failure occurred. If the replication is asynchronous or semi-synchronous, then more transactions can be lost.
One final consideration, and one that is often overlooked, is to think about what happens after the disaster. Can you use the remote systems and storage as the new primary? Are there limitations? What if you want to switch back to the old configuration? I know that VVR does that very well.
|
