Re: [zfs-discuss] Cold failover of COMSTAR iSCSI targets on shared storage
On 26/09/12 00:52, Richard Elling wrote: On Sep 25, 2012, at 1:32 PM, Jim Klimov jimkli...@cos.ru mailto:jimkli...@cos.ru wrote: Q: Which services are the complete list needed to set up the COMSTAR server from scratch? Dunno off the top of my head. Network isn't needed (COMSTAR can serve FC), but you can look at the SMF configs for details. The service name must be system/stmf, we played with COMSTAR configuration export/import for disaster recovery exercises, it worked flawlessly. Best regards, ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Cold failover of COMSTAR iSCSI targets on shared storage
Hello all, With original old ZFS iSCSI implementation there was a shareiscsi property for the zvols to be shared out, and I believe all configuration pertinent to the iSCSI server was stored in the pool options (I may be wrong, but I'd expect that given that ZFS-attribute-based configs were deigned to atomically import and share pools over various protocols like CIFS and NFS). With COMSTAR which is more advanced and performant, all configs seem to be in the OS config files and/or SMF service properties - not in the pool in question. Does this mean that importing a pool with iSCSI zvols on a fresh host (LiveCD instance on the same box, or via failover of shared storage to a different host) will not be able to automagically share the iSCSI targets the same way as they were known in the initial OS that created and shared them - not until an admin defines the same LUNs and WWN numbers and such, manually? Is this a correct understanding (and does the problem exist indeed), or do I (hopefully) miss something? Thanks, //Jim Klimov ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Cold failover of COMSTAR iSCSI targets on shared storage
On Sep 25, 2012, at 12:30 PM, Jim Klimov jimkli...@cos.ru wrote: Hello all, With original old ZFS iSCSI implementation there was a shareiscsi property for the zvols to be shared out, and I believe all configuration pertinent to the iSCSI server was stored in the pool options (I may be wrong, but I'd expect that given that ZFS-attribute-based configs were deigned to atomically import and share pools over various protocols like CIFS and NFS). With COMSTAR which is more advanced and performant, all configs seem to be in the OS config files and/or SMF service properties - not in the pool in question. Does this mean that importing a pool with iSCSI zvols on a fresh host (LiveCD instance on the same box, or via failover of shared storage to a different host) will not be able to automagically share the iSCSI targets the same way as they were known in the initial OS that created and shared them - not until an admin defines the same LUNs and WWN numbers and such, manually? Is this a correct understanding (and does the problem exist indeed), or do I (hopefully) miss something? That is pretty much how it works, with one small wrinkle -- the configuration is stored in SMF. So you can either do it the hard way (by hand), use a commercially-available HA solution (eg. RSF-1 from high-availability.com), or use SMF export/import. -- richard -- illumos Day ZFS Day, Oct 1-2, 2012 San Fransisco www.zfsday.com richard.ell...@richardelling.com +1-760-896-4422 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Cold failover of COMSTAR iSCSI targets on shared storage
2012-09-26 0:21, Richard Elling пишет: Does this mean that importing a pool with iSCSI zvols on a fresh host (LiveCD instance on the same box, or via failover of shared storage to a different host) will not be able to automagically share the iSCSI targets the same way as they were known in the initial OS that created and shared them - not until an admin defines the same LUNs and WWN numbers and such, manually? Is this a correct understanding (and does the problem exist indeed), or do I (hopefully) miss something? That is pretty much how it works, with one small wrinkle -- the configuration is stored in SMF. So you can either do it the hard way (by hand), use a commercially-available HA solution (eg. RSF-1 from high-availability.com http://high-availability.com), or use SMF export/import. -- richard So if I wanted to make a solution where upon import of the pool with COMSTAR shared zvols, the new host is able to publish the same resources as the previous holder of the pool media, could I get away with some scripts (on all COMSTAR servers involved) which would: 1) Regularly svccfg export certain SMF service configs to a filesystem dataset on the pool in question. 2) Upon import of the pool, such scripts would svccfg import the SMF setup, svcadm refresh and maybe svcadm restart (or svcadm enable) the iSCSI SMF services and thus share the same zvols with same settings? Is this a correct understanding of doing shareiscsi for COMSTAR in the poor-man's HA setup? ;) Apparently, to be transparent for clients, this would also use VRRP or something like that to carry over the iSCSI targets' IP address(es), separate from general communications addressing of the hosts (the addressing info might also be in same dataset as SMF exports). Q: Which services are the complete list needed to set up the COMSTAR server from scratch? Thanks, //Jim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Cold failover of COMSTAR iSCSI targets on shared storage
On Sep 25, 2012, at 1:32 PM, Jim Klimov jimkli...@cos.ru wrote: 2012-09-26 0:21, Richard Elling пишет: Does this mean that importing a pool with iSCSI zvols on a fresh host (LiveCD instance on the same box, or via failover of shared storage to a different host) will not be able to automagically share the iSCSI targets the same way as they were known in the initial OS that created and shared them - not until an admin defines the same LUNs and WWN numbers and such, manually? Is this a correct understanding (and does the problem exist indeed), or do I (hopefully) miss something? That is pretty much how it works, with one small wrinkle -- the configuration is stored in SMF. So you can either do it the hard way (by hand), use a commercially-available HA solution (eg. RSF-1 from high-availability.com http://high-availability.com), or use SMF export/import. -- richard So if I wanted to make a solution where upon import of the pool with COMSTAR shared zvols, the new host is able to publish the same resources as the previous holder of the pool media, could I get away with some scripts (on all COMSTAR servers involved) which would: 1) Regularly svccfg export certain SMF service configs to a filesystem dataset on the pool in question. This is only needed when you add a new COMSTAR share. You will also need to remove old ones. Fortunately, you have a pool where you can store these :-) 2) Upon import of the pool, such scripts would svccfg import the SMF setup, svcadm refresh and maybe svcadm restart (or svcadm enable) the iSCSI SMF services and thus share the same zvols with same settings? Import should suffice. Is this a correct understanding of doing shareiscsi for COMSTAR in the poor-man's HA setup? ;) Yes. Apparently, to be transparent for clients, this would also use VRRP or something like that to carry over the iSCSI targets' IP address(es), separate from general communications addressing of the hosts (the addressing info might also be in same dataset as SMF exports). Or just add another IP address. This is how HA systems work. Q: Which services are the complete list needed to set up the COMSTAR server from scratch? Dunno off the top of my head. Network isn't needed (COMSTAR can serve FC), but you can look at the SMF configs for details. I haven't looked at the OHAC agents in a long, long time, but you might find some scripts already built there. -- richard -- illumos Day ZFS Day, Oct 1-2, 2012 San Fransisco www.zfsday.com richard.ell...@richardelling.com +1-760-896-4422 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
