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
