On 12/12/2011 04:37 AM, Jankowski, Chris wrote:
GFS2 or any other filesystems being replicated are not aware at all of the block replication taking place in the storage layer. This is entirely transparent to the OS and filesystems clustered or not. Replication happens entirely in the array/SAN layer and the servers are not involved at all.
That's not strictly true. While it is the case that normal I/O issued on the active (R1 in SRDF-speak) side of the replicated volume needs no special handling things get a bit more complex when the SRDF pair state changes (e.g. splits/failovers/partitions).
SRDF pair states govern which side of the replicated volume is writable and a change in state may mean a device abruptly becomes write-disabled.
There's currently no mechanism for handling these changes automatically on the host side so there is a need for manual intervention (or clever scripting) whenever such a change occurs.
So, there is nothing for Red Hat to support or not support - they just do not see it. Nor do they have any ability to see it even if they wanted. Very often the array ports for replication are on separate ports and in separate FC zones.
SRDF is normally used between two or more Symmetrix arrays (often but not always in physically separate locations). Replication traffic travels over a dedicated inter-array link via a remote link director (a specialised symm channel adapter) rather than the regular front end director ports of the array.
In a typical deployment the R2 (remote/slave) side of the replicated volume is not reachable from the same fabric as the R1 (master).
This means additional considerations are required in a disaster recovery scenario since any backup hosts on the R2 side will need to be configured to cope with the fact that LUNs and ports will have different WWIDs than on the R1 site (this may cause problems for some multipath boot implementations for e.g.).
Regards, Bryn. -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
