I have to help setup a configuration where a ZPOOL on MPXIO on OpenSolaris is being used with Symmetrix devices with replication being handled via Symmetrix Remote Data Facility (SRDF). So I am curious whether anyone has used this configuration and have any feedback/suggestions. Will there be any issues with importing the replicated zpool on the secondary host in a failure scenario ? Regards, Moinak. This message posted from opensolaris.org
Hello Moinak,
Wednesday, August 13, 2008, 1:58:34 PM, you wrote:
MG> I have to help setup a configuration where a ZPOOL on MPXIO on
MG> OpenSolaris is being used with Symmetrix devices with replication
MG> being handled via Symmetrix Remote Data Facility (SRDF).
MG> So I am curious whether anyone has used this configuration and have any
feedback/suggestions.
MG> Will there be any issues with importing the replicated zpool on
MG> the secondary host in a failure scenario ?
Currently you won''t be able to import the SRDF copy on the same host
where source disks are present. Unless you manually (unsupported
currently) change guid.
--
Best regards,
Robert Milkowski mailto:milek at task.gda.pl
http://milek.blogspot.com
Robert Milkowski wrote:> Wednesday, August 13, 2008, 1:58:34 PM, you wrote: > > MG> I have to help setup a configuration where a ZPOOL on MPXIO on > MG> OpenSolaris is being used with Symmetrix devices with replication > MG> being handled via Symmetrix Remote Data Facility (SRDF). > MG> So I am curious whether anyone has used this configuration and have any feedback/suggestions. > MG> Will there be any issues with importing the replicated zpool on > MG> the secondary host in a failure scenario ? > > Currently you won''t be able to import the SRDF copy on the same host > where source disks are present. Unless you manually (unsupported > currently) change guid.One assumes that the DR host is different (or why would he be using SRDF?), so this won''t be an issue. And why on earth would anyone try and import both sides of the SDRF arrays on the same host at the same time? He''ll probably need to force the pool import (with -f), but otherwise should be OK. I will note that due to some proprietary array logic used by EMC, PowerPath will usually be faster than MPxIO if you have multiple FC links. (I _really_ don''t line PowerPath, but the numbers in our testing are consistent... we don''t see this with our Hitachi arrays and use MPxIO with them). -- Carson
On Aug 13, 2008, at 5:58 AM, Moinak Ghosh wrote:> I have to help setup a configuration where a ZPOOL on MPXIO on > OpenSolaris is being used with Symmetrix devices with replication > being handled via Symmetrix Remote Data Facility (SRDF). > So I am curious whether anyone has used this configuration and have > any feedback/suggestions. > Will there be any issues with importing the replicated zpool on the > secondary host in a failure scenario ?We have customers using SRDF with ZFS, but one issue that comes up is failing *back* to the original host. If that host never goes down (panic, reboot), then the pool is already imported on the original host, and when you try to fail back, there will be a mismatch between what''s in memory vs. what''s on disk (assuming the pool was modified by the secondary host). See: 6695687 Force-export a ZFS pool Ugly workaround is to purposely reboot the original host. And you will want: 6282725 hostname/hostid should be stored in the label http://blogs.sun.com/erickustarz/en_US/entry/poor_man_s_cluster_end which will be in s10u6. eric
Actually the SRDF copy has to be imported on the standby(R2) host if the primary host/storage has to be offlined for some reason; but thanks for the note. Regards, Moinak. This message posted from opensolaris.org
Thanks. This is useful to know. I see that 6282725 went into B63. Regards, Moinak. This message posted from opensolaris.org
We do this all the time SRDF with zfs. Zones built on R!-R2 pairs as are the application disks. Fast failover and some intelligence with scripts checking that a resync has been completed before we failback. v This message posted from opensolaris.org