zfs discuss - Sep 2012 - 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

On Sep 25, 2012, at 12:30 PM, Jim Klimov <jimklimov at 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.Elling at RichardElling.com
+1-760-896-4422








-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20120925/6ec09e09/attachment.html>

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

On Sep 25, 2012, at 1:32 PM, Jim Klimov <jimklimov at 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.Elling at RichardElling.com
+1-760-896-4422








-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20120925/b81407af/attachment.html>

On 26/09/12 00:52, Richard Elling wrote:
> On Sep 25, 2012, at 1:32 PM, Jim Klimov <jimklimov at cos.ru 
> <mailto:jimklimov at 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,

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20121001/eb8c121b/attachment.html>