You can control access and visibility of LUNs either based on Initiators
(host groups), targets (target groups), network links (target portal
groups) or views that make a logical unit visible in a target. Every
solution works with a different use case idea.
In napp-it I am currently working on full appliance redundancy with
Z-Raid pool mirroring over iSCSI for a storage and service failover
cluster. I have played with the solutions above but in the end I
decided to use none of them but use manual target discovery with
switchable IP aliases for iSCSI targets to restrict and switchover LUNs
and for NFS/SMB failover between the active master storage appliance and
the slave. The reason was simplicity and that this works on a lower
level that does not rely to Comstar timings and delays.
Gea
Am 03.09.2016 um 13:05 schrieb Johan Kragsterman:
Hi!
I'd like to hear from people using omnios as a scsi target appliance, how/if
they use host group members in multiple groups, or just in one?
The use case for putting a member in multiple(or perhaps just two) host groups,
would be a cluster where you can have a host group for the entire cluster, with
all members included there, and then individual host groups for each host for
os/boot or other private lu's.
The other way to do this is of coarse to provide multiple views for the lu's
that should be shared across the cluster. IMHO, though, a single cluster host
group would be more simple to handle.
So, how do YOU do it? And why...?
Opinions pls...?
Best regards from/Med vänliga hälsningar från
Johan Kragsterman
Capvert
_______________________________________________
OmniOS-discuss mailing list
[email protected]
http://lists.omniti.com/mailman/listinfo/omnios-discuss
_______________________________________________
OmniOS-discuss mailing list
[email protected]
http://lists.omniti.com/mailman/listinfo/omnios-discuss
