Üblicherweise werden bisher für solche Aufgaben spezielle Storagesysteme von z.B. EMC, Hitachi, oder HP eingesetzt. Aus technologischer Sicht ähnelt der Ansatz von OpenSolaris am ehesten dem von Netapp, die auch mit Standardhardware und optimiertem OS (ontap) arbeiten.

Das OpenSolaris-System stellt sich also nach außen im FC-SAN als SCSI Target dar (vgl. dazu auch ISCSI Target). Rechner mit FC-HBAs (Emulex, QLogic, …) können dann per SAN auf die bereitgestellten LUNs zugreifen.

LUN erstellen

Im OpenSolaris muß zunächst eine LUN im “Backing Store” mit dem sbdadm-Kommando erstellt werden. Dazu kann Plattenplatz in Form einer Disk, Datei oder eines ZFS-Volumes dienen. Die Größe der LUN kann im Nachhinein erweitert werden.

Hostgruppe erstellen

Mit dem stmfadm-Kommando wird im Anschluß eine sog. Hostgruppe erstellt, die z.B. alle WWPNs der gewünschten Initiator enthält (also alle HBA-Ports eines Rechners, die auf diese LUN zugreifen soll).

Mapping

Danach wird das Mapping mit dem stmfadm-Befehl durchgeführt. Die LUN wird nach außen sichtbar auf den HBA-Ports des OpenSolaris-Systems exportiert, welche dann die SCSI-Targets darstellen.

Zoning

Am FC-Switch bzw. in der Fabric muß obligatorischerweise noch das Zoning durchgeführt werden.

Zugriff auf die LUN

Am Rechner mit dem Initiator (OS ist dabei egal) ist nun (autom.) Persistent Binding angesagt. Daraufhin kann die Disk im Volumemanager des Betriebssystems verwendet werden.

Wissenswertes…

Der für die LUN benötigte Platz im Backingstore wird dynamisch, also nach Bedarf allokiert. Bestimmte Initialisierungsverfahren wollen aber alle Blöcke einer Disk beschreiben und belegen damit trotzdem bereits initial die volle zugewiesene Kapazität.

Am Rechner mit dem SCSI-Initiator muß eine Multipathing-Software aktiv sein wenn die LUNs über mehrere Initiator-HBAs und/oder Target-HBAs angesprochen wird. Im Gegensatz zu (Open) Solaris und Linux bringt Windows kein Multipathing im Auslieferungszustand mit, deshalb benötigt man z.B. EMC Powerpath oder Symantec/Veritas DMP.