Storage-System mit Open Solaris und COMSTAR

-Misha, Fotolia

Vollgas

Was bisher teuren Storage-Lösungen vorbehalten war, ist mit dem freien Betriebssystem Open Solaris und COMSTAR auch kostengünstig möglich. Die Rede ist von einem Speichersystem, das neben iSCSI auch Fibre Channel beherrscht. Dieser Artikel beschreibt, wie Sie damit ein funktionierendes System aufsetzen.

Mit dem fortschrittlichen Dateisystem ZFS hat Sun – heute bei Oracle – einen großen Wandel im Storage-Segment eingeläutet. Die herausragenden Eigenschaften von ZFS schreien förmlich danach, in vollem Umfang auf ein Storage-System angewandt zu werden. Mit einem klassischen NAS-System konnte Sun nicht überzeugen, die Implementierung eines modernen Framework zur Netzwerk-weiten Bereitstellung von Blockdevices war dann der nächste Schritt.

Das Ergebnis war COMSTAR (Common Multi Protocol SCSI Target, [1]), ein Subsystem, um über aktuelle wie auch künftige Medien und Protokolle Speicherplatz in Form von Blockgeräten anzubieten. In Verbindung mit Open Solaris [2], ZFS und der NFS- und CIFS-Implementierung wird das Ganze zu einem vollwertigen Unified-Storage-System.

ZFS ist zwar keine unumgängliche Voraussetzung, COMSTAR ist durchaus in der Lage, auch Dateien, Partitionen (im Solaris-Fachjargon Slices genannt) in Form einer Logical Unit einem beliebigen Konsumenten bereitzustellen. Der Mehrwert von ZFS in Form von Snapshots, Clones, Thin Provisioning und so weiter macht den Einsatz so attraktiv. Ein Schelm, wer sich Böses denkt: Die Ähnlichkeiten zu einem Netapp-Storage-System sind kaum zu übersehen [2].

Die ersten Schritte in Richtung Open Solaris und COMSTAR lassen sich ohne Weiteres auf einer virtuellen Maschine zurücklegen, man ist lediglich auf iSCSI als Transportprotokoll beschränkt. Dieses Vorhaben ist vergleichbar mit der Installation des bekannten Openfiler-Systems auf Linux-Basis. Am Rande sei bemerkt, dass Oracle in den Oracle-RAC- und Oracle-Grid-Howtos bisher gerne auf Openfiler zurückgriff. Konsequenterweise sollte Oracle nach der Übernahme von Sun hier nachbessern und Openfiler durch Open Solaris und COMSTAR ersetzen.

Die Umsetzung eines Open-Solaris-COMSTAR-Systems gliedert sich in folgende Schritte:

  • Installation von Open Solaris
  • Installation der COMSTAR-Pakete
  • Bereitstellen des Blockdevice
  • Bekanntgabe des Blockdevice in COMSTAR
  • Präsentation des Blockdevice einschließlich des so genannten LUN-Masking

Die Anforderungen an die virtuelle Maschine fallen für die ersten Gehversuche relativ gering aus: 1 GByte Arbeitsspeicher, eine virtuelle CPU, eine rund 20 GByte große Systemfestplatte und ein Bridged-Netzwerkadapter mit Anbindung an das Internet sollten für den Anfang genügen. Als Virtualisierungsprodukt ist Sun XVM Virtualbox zu empfehlen, aber auch VMware Workstation ist geeignet. Beide Lösungen bieten Vorlagen für Open-Solaris- und Solaris-10-Installationen an. Die Installation von Open Solaris sollte keine Fragen aufwerfen. Danach empfiehlt es sich, die herstellerspezifischen Tools (zum Beispiel VMware-Tools) zu installieren, um den Bedienkomfort des virtuellen Gastes zu verbessern.

iSCSI-Target

Im ersten Schritt soll Open Solaris mit COMSTAR als ein iSCSI-Target konfiguriert werden. Hierzu ist eine feste IP-Adresse zu empfehlen. Um die Komplexität nicht unnötigerweise in die Höhe zu treiben, soll es bei dem schon bestehenden Netzwerkanschluss mit Internetverbindung bleiben. Lediglich die virtuelle Maschine erhält eine feste IP-Adresse. Wer einen DHCP-Server betreibt, kann auch dort der Maschine eine feste Adresse geben.

Einfacher ist allerdings die feste Zuordnung der IP-Adresse, die Sie als Root dem Open-Solaris-Gast in einem Terminalfenster folgendermaßen zuweisen:

$ pfexec su
# echo 192.168.1.200 > /etc/hostname.e1000g0

Dabei stellt »e1000g0« das primäre Netzwerkinterface dar. Der folgende Befehl gibt Auskunft über die Netzwerkschnittstellen:

# ifconfig -a

Den Device-Namen des konfigurierten Netzwerkadapters müssen Sie dem Dateinamen »/etc/hostname.« anfügen – vergleichen Sie die MAC-Adresse mit den Einstellungen in der Virtualisierungssoftware. Mit den Befehlen in Listing 1 schließen Sie die Netzwerkkonfiguration des Open-Solaris-Systems ab.

Listing 1

Netzwerk-Konfiguration

01 # echo meiniscsiserver > /etc/nodename (Setzen des Computernamens)
02 # echo 192.168.1.0 255.255.255.0 >> /etc/netmasks
03 # echo 192.168.1.1 > /etc/defaultrouter (Setzen des Standardgateways)
04 # vi /etc/resolv.conf (Konfigurieren der Namensauflösung)
05 search zuhause.local
06 nameserver 192.168.1.1
07 # vi /etc/nsswitch.conf (Konfigurieren der Namensauflösung)
08 ...
09 hosts           files dns
10 ipnodes         files dns
11 ...
12 # vi /etc/hosts
13 ::1 localhost
14 127.0.0.1 localhost
15 192.168.1.200 meiniscsiserver meiniscsiserver.local loghost
16 # svcadm disable network/physical:nwam
17 # svcadm enable network/physical:default

Starten Sie nun Open Solaris mit einem Reboot neu. Danach sollte das System auf der IP-Adresse 192.168.1.200 lauschen. Wenn alle vorangegangen Befehle korrekt ausgeführt wurden und DNS sowie Standard-Gateway entsprechend konfiguriert sind, hat der neue Server nun Internetzugang, den Sie für die COMSTAR-Installation unbedingt brauchen. Dazu machen Sie sich zum Administrator, installieren das passende Paket und rebooten:

$ pfexec su
# pkg install storage-server SUNWiscsit
# reboot

Nach dem Neustart des Systems aktivieren Sie COMSTAR als Open-Solaris-Services:

$ pfexec svcadm enable stmf

Ab sofort steht Ihnen ein vollwertiges Storage-System zur Verfügung, das sowohl iSCSI als auch Fibre Channel – entsprechende Hardware vorausgesetzt – beherrscht. Um einen weiteren ZFS-Pool für die künftigen Blockdevices zu erstellen, brauchen Sie eine zusätzliche virtuelle Festplatte. Dazu fahren Sie zuerst das Open-Solaris-System herunter:

$ pfexec shutdown -y -g0 -i5

In den Einstellungen der virtuellen Maschine fügen Sie dem Gast eine neue Festplatte mit ausreichend Kapazität hinzu. Starten Sie im Anschluss wieder den Open-Solaris-Gast und erstellen nach der Anmeldung aus der hinzugefügten Festplatte den ZFS-Pool. Sie finden den Device-Namen mit Hilfe des »format« -Kommandos heraus. Den ZFS-Pool erzeugen Sie dann zum Beispiel mit »zfs create mypool c8t1d0« . Listing 2 zeigt noch einmal den vollständigen Ablauf.

Listing 2

Neuer ZFS-Pool

01 $ pfexec su
02 # format
03 AVAILABLE DISK SELECTIONS:
04      0. c8t0d0 <DEFAULT cyl 2607 alt 2 hd 255 sec 63>
05           /pci@0,0/pci15ad,1976@10/sd@0,0
06      1. c8t1d0 <VMware,-VMware Virtual S-1.0-10.00GB>
07           /pci@0,0/pci15ad,1976@10/sd@1,0
08 #
09 # zpool create mypool c8t1d0
10 # zpool status -v
11   pool: mypool
12  state: ONLINE
13  scrub: none requested
14 config:
15         NAME STATE READ WRITE CKSUM
16         mypool ONLINE 0 0 0
17           c8t1d0 ONLINE 0 0 0
18 errors: No known data errors

Ab sofort steht der Speicherplatz dem COMSTAR-Framework zur Verfügung. Wie angekündigt beschränkt sich dieser Artikel auf die Anwendung so genannter ZFS-Volumes. Wenn Sie lieber eine Containerdatei oder eine Partition nutzen wollen, hilft ein Blick in die Dokumentation weiter. Die Vorteile von ZFS liegen aber auf der Hand: Das ZFS-Volume ist Snapshot- und Clone-fähig. Hinzu kommt die gesteigerte Performance durch das ZFS-Dateisystem. In produktiven Umgebungen können spezielle Schreib- und Lesecache-Geräte auf einer Solid State Disk (SSD) sie noch steigern.

Das erste ZFS-Volume erstellen Sie wie folgt:

$ pfexec su
# zfs create -V 2G mypool/vol1

Jetzt steht auf dem ZFS-Pool »mypool« ein 2 GByte großes Volume bereit. Das zugehörige Rawdevice findet sich unter »/dev/zvol/rdsk/mypool/vol1« . Das Rawdevice müssen Sie dem COMSTAR-Framework noch als neue Logical Unit bekannt machen:

$ pfexec su
# sdbadm create-lu /dev/zvol/rdsk/mypool/vol1
Created the following LU:
              GUID               ...
-------------------------------- ...
600144f05f71070000004bc981ec0001 ...
 /dev/zvol/rdsk/mypool/vol1

Die Logical Unit ist damit erstellt und erhält vom COMSTAR-Framework eine eindeutige Identifikation, die GUID. Über die können Sie in den folgenden Schritten die Logical Unit eindeutig referenzieren. Die GUID einer Logical Unit lässt sich mit »sdbadm list-lu« ermitteln, das alle Logical Units ausgibt.

Nun muss die Logical Unit noch im SAN veröffentlicht werden, sonst ist sie für die Clients nicht sichtbar. Für einen ersten Test genügt:

# stmfadm add-view 600144f05f71070000004bc981ec0001

Das ist die GUID der zuvor erstellten Logical Unit. Ab sofort lässt sich das Blockdevice über ein beliebiges Protokoll ansprechen. Sie müssen lediglich das passende COMSTAR-Targetdevice konfigurieren und aktivieren, im ersten Schritt iSCSI. Die COMSTAR-iSCSI-Target-Implementierung fällt sehr einfach aus. Zwei Schritte genügen, um die Logical Unit im IP-SAN zugänglich zu machen:

# svcadm enable iscsi/target
# itadm create-target
Target iqn.1986-03.com.sun:02:8f4cd1fa-b81d-c42b-c008-a70649501262 successfully created

Ganz wichtig an dieser Stelle: Bei der Erstellung des iSCSI-Target wird der so genannte iSCSI Qualified Name (IQN) des Target automatisch generiert, den Sie in den kommenden Schritten noch brauchen. Als iSCSI-Client (im iSCSI-Dialekt auch Initiator genannt) dient im Beispiel Ubuntu 9.10. Listing 3 zeigt alle notwendigen Schritte, um ein COMSTAR-Blockdevice mit Hilfe des Linux-Open-iSCSI-Initiators anzubinden.

Listing 3

Blockdevice und Initiator

01 $ sudo -s
02 # aptitude install open-iscsi
03 # vi /etc/iscsi/iscsid.conf
04 node.startup = automatic
05 # /etc/init.d/open-iscsi restart
06 # iscsiadm -m discovery -t st -p 192.168.209.200
07 192.168.209.200:3260,1 iqn.1986-03.com.sun:02:8f4cd1fa-b81d-c42b-c008-a70649501262
08 # iscsiadm -m node
09 # /etc/init.d/open-iscsi restart
10 # fdisk -l
11 Disk /dev/sdb: 2147 MB, 2147418112 bytes
12 67 heads, 62 sectors/track, 1009 cylinders
13 Units = cylinders of 4154 * 512 = 2126848 bytes
14 Disk identifier: 0x00000000
15
16 Disk /dev/sdb doesn't contain a valid partition table
17 # fdisk /dev/sdb
18 # mkfs.ext3 /dev/sdb1
19 # mkdir /vol1
20 # mount /dev/sdb1 /vol1

Ab sofort steht unter »/vol1« das aus COMSTAR heraus präsentierte Blockdevice bereit. Sie können nun weitere Blockdevices hinzufügen, indem Sie ein neues ZFS-Volume erstellen und es wie oben beschrieben dem Clientsystem bekannt machen und entsprechend anbinden. Weit interessanter sind aber die Möglichkeiten, die ZFS bietet. Wenn zum Beispiel einem Volume der Speicherplatz ausgeht, können Sie es mit ZFS jederzeit vergrößern (Listing 4).

Listing 4

ZFS-Volume vergrößern

01 # zfs list
02 NAME                       USED  AVAIL  REFER  MOUNTPOINT
03 mypool                    2.00G  7.78G    19K  /mypool
04 mypool/vol1                  2G  9.72G  65.3M  -
05 # zfs get volsize mypool/vol1
06 NAME         PROPERTY  VALUE    SOURCE
07 mypool/vol1  volsize   2G       -

Aktuell ist das Volume 2 GByte groß. Die folgenden Befehle vergrößern es auf 3 GByte.

01 # zfs set volsize=3g mypool/vol1
02 # zfs get volsize mypool/vol1
03 NAME         PROPERTY  VALUE    SOURCE
04 mypool/vol1  volsize   3G       -
05 # sbdadm modify-lu -s 3g 600144f05f71070000004bc981ec0001

Beachten Sie, dass die angegebene GUID der Logical Unit Ihrer Installation entspricht. Ein »sbdadm list-lu« verschafft den entsprechenden Überblick über vorhandene Logical Units. Starten Sie den Linux-Client neu und vergrößern die Ext-3-Partition, zum Beispiel mit Hilfe von Gparted. Das Ergebnis sollte dann wie folgt aussehen:

# mount /dev/sdb1 /vol1
# cd /vol1
# df -h .
Filesystem            Size  Used Avail Use%Mounted on
/dev/sdb1             3.0G   36M  2.8G   2%/vol1

Das ZFS-Volume bietet nun die voreingestellten 3 GByte Speicherplatz. Unter Open Solaris ist der ganze Vorgang sogar bei laufendem Betrieb möglich.

Das Vergrößern von ZFS-Volumes ist nur eine der vielen Möglichkeiten des ZFS-Dateisystems. Es kann zum Beispiel auch in wenigen Millisekunden einen Snapshot des Volume erstellen:

# zfs snapshot mypool/vol1@2010-04-17-1

Wenn die Daten in diesem Zeitraum konsistent bleiben, können Sie den Snapshot sogar für eine Datensicherung auf Band heranziehen. Systeme wie zum Beispiel eine Oracle-Datenbank bieten auch Mittel und Wege an, um einen solchen konsistenten Snapshot im laufenden Betrieb durchzuführen. Damit sind Backups ohne Downtime möglich.

Beschreibbare Snapshots

Ein weiteres Feature von ZFS sind die so genannten Clones, das sind beschreibbare Kopien eines Snapshot. Den Clone können Sie wie das ZFS-Volume mittels COMSTAR exportieren und dann an ein Testsystem anbinden. So verfügen Sie beispielsweise über die vollständige Kopie einer produktiven Datenbank und können ohne Gefahr Tests darauf durchführen. Diese Vorgehensweise ist heute übliche Praxis, um vollwertige Testsysteme abzubilden. Führen Sie

# zfs clone mypool/vol1@2010-04-17-1 mypool/vol1-test

aus, um aus dem zuvor erstellten Snapshot den Clone »vol1-test« zu erstellen. Im Anschluss veröffentlichen Sie den Clone wie zuvor das Volume »vol1« im IP-SAN:

# sbdadm create-lu /dev/zvol/rdsk/mypool/vol1-test
Created the following LU:
              GUID                ...
--------------------------------  ...
600144f05f71070000004bc999020002      /dev/zvol/rdsk/mypool/vol1-test
# stmfadm add-view 600144f05f71070000004bc999020002

Auf dem Clientsystem sollte nun nach kurzem Warten ein weiteres Blockdevice erscheinen.

Da das neue Volume eine Kopie des ursprünglichen Volume »vol1« darstellt, sind die Partitionstabelle und das Dateisystem vorhanden. Ein Neustart des Ubuntu-Systems und die beiden Befehle

# mkdir /vol1-test
# mount /dev/sdd1 /vol1-test

genügen, um den Clone einzubinden und zu nutzen. Unter Live-Bedingungen würde dafür selbstverständlich ein entsprechendes Testsystem zur Verfügung stehen. Die iSCSI-Demo zeigt, wie leicht mit Open Solaris, ZFS und COMSTAR ein äußerst professionelles Storage-System zu implementieren ist, für das Sie bei Premium-Anbietern wie Net App, EMC und HP eine ganze Menge Geld hinblättern müssten.

comments powered by Disqus
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Ausgabe  04/2014