Bei der automatischen Erkennung stürzte zuletzt das Programm jbconfig ab, deshalb folgt nun die manuelle Variante (bei Sun/STK Librarys habe ich den Absturz noch nicht erlebt).

Zunächst einmal noch ein paar Grundlagen für das Einrichten der Jukebox und Dynamic Drive Sharing:

Für ein Tape drive werden am Host jede Menge Devices angelegt. Für Backup-Programme wird i.d.R. das no rewind – device inc. Hardwarekomprimierung bevorzugt, das die max. Kapizität nutzt. Bei den verwendeten LTO-3-drives könnte man z.B. LTO-2-Kompatibilität nutzen, was aber nur ggf. bei einem gemischten Betrieb von Drives Sinn ergibt.

Beim Dynamic Drive Sharing (DDS) übernimmt der Networker Server (oder ein Storage Node) die Steuerung der Jukebox (Controlpath/Changer/Robotik). Andere Hosts, z.B. auch NDMP-Tapeserver, können auch auf die Drives der Jukebox zugreifen. Für jedes gesharte Drive wird eine DDS-Lizenz benötigt. Die Jukebox wird gestaffelt nach Anzahl Slots lizensiert. Sollen außer dem Networker Server weitere Rechner direkt die Drives nutzen wird dafür eine Dedicated Storage Node – Lizenz benötigt. NAS-Systeme wie Netapp benötigen eine NDMP-Lizenz, die gestaffelt nach Tieren abgerechnet wird.

Aufgrund der vorherigen Auswertung auf dem Backup Server und den NAS-Geräten läßt sich sich eine Zuordnung zwischen WW(P)N und Tape-Device erstellen:

Changer: WWPN 50:03:08:c1:43:97:b0:02 / Lun 1
senbackup1: /dev/scsi/changer/c5t500308C14397B002d1

Tape drive 1: WWPN 50:03:08:c1:43:97:b0:02 / Lun 0
senbackup1: /dev/rmt/6cbn
filer1: nrst16a
sennst1: nrst7a

Tape drive 2: WWPN 50:03:08:c1:43:97:b0:05 / Lun 0
senbackup1: /dev/rmt/7cbn
filer1: nrst17a
sennst1: nrst4a

Tape drive 3: WWPN 50:03:08:c1:43:97:b0:08 / Lun 0
senbackup1: /dev/rmt/8cbn

Mit diesem Wissen kann nun die Jukebox für den EMC Networker konfiguriert werden:

root@senbackup1 # jbconfig

Jbconfig is running on host senbackup1 (SunOS 5.10),
and is using senbackup1 as the NetWorker server.

1) Configure an AlphaStor Library.
2) Configure an Autodetected SCSI Jukebox.
3) Configure an Autodetected NDMP SCSI Jukebox.
4) Configure an SJI Jukebox.
5) Configure an STL Silo.

What kind of Jukebox are you configuring? [1] 4
Enter the number corresponding to the type of jukebox you are installing:
1) ADIC-1200c/ADIC-1200d 20) Exabyte 690D          39) HP-Optical
2) ADIC-VLS              21) Exabyte Jukebox       40) Sony TSL-7000
3) ARC DiamondBack       22) Hitachi ML010 Series  41) Sony TSL-A500C
4) Sun 20Gb 4mm Tape Loader 23) HP-C1553A/Surestore 12000e 42) Sony TSL-AIT
5) Breece Hill Saguaro   24) HP-C1557A/Surestore 12000e 43) Digital 4mm DAT TLZ9L
6) Breece Hill           25) HP C5713A             44) Digital 4mm DAT (TLZxx)
7) Philips Blackjack     26) Hewlett-Packard A4853A 45) Digital TL800 Series
DLI Libra Series      27) Metrum (SCSI)         46) Digital TL810 Series
9) Quantum DLT/Digital DLT 28) Qualstar              47) Digital TL820 Series
10) Exabyte 10e or 10h    29) Spectralogic          48) Digital TL893
11) Exabyte 10i           30) STK 9704/Lago 340     49) Digital TL893
12) Exabyte 18D           31) STK 9708/Lago 380 (SCSI) Datawheel 50) Digital TL896
13) Exabyte 60            32) StorageTek 9730       51) Digital TL896
14) Exabyte 120           33) StorageTek 9738       52) Digital TL899
15) Exabyte 210           34) STK 9708/Lago 380 (SCSI) Datawheel 53) Digital TL899
16) Exabyte 218           35) Dell PowerVault 130T  54) Digital Optical
17) Exabyte 220           36) IBM 3570              55) Digital TK Series
18) Exabyte 230D          37) IBM 7331/IBM 9427     56) Standard SCSI Jukebox
19) Exabyte 400 Series    38) ATL/Odetics SCSI

Choice? 56
Installing an ‘Standard SCSI Jukebox’ jukebox.

What name do you want to assign to this jukebox device? senlib2
39744:jbconfig: Enter the control port of the jukebox in the following format:

scsidev@3.0.0 Pathname of the control port for the jukebox device? /dev/scsi/changer/c5t500308C14397B002d1
15814:jbconfig: Attempting to detect serial numbers on the jukebox and drives …

15815:jbconfig: Will try to use SCSI information returned by jukebox to configure drives.

Turn NetWorker auto-cleaning on (yes / no) [yes]? no
The drives in this jukebox cannot be auto-configured with the available
information. You will need to provide the path for the drives.
Is (any path of) any drive intended for NDMP use? (yes / no) [no] yes
Is any drive going to have more than one path defined? (yes / no) [no] yes

You will be prompted for multiple paths for each drive.
Pressing <Enter> on a null default advances to the next drive.

Please enter the device path information in one of the following formats:

/dev/rmt/1cbn –for local path or
host:device-path –for remote node or NDMP device(s) or
host:drive-letter:directory path –for Windows disk file

After you have entered a device path, you will be prompted for an NDMP
user name for that path’s host. If this device path is not an NDMP device,
press the enter key to advance to the next device path.  For NDMP devices,
you need to enter the user name and password the first time we encounter
that NDMP host. Pressing the enter key for the NDMP user name for any
subsequent device path on the same host will set the user name and password
to those defined the first time. You will not be prompted for the password
in such a case.

Drive  1, element 1
Device path 1 ? /dev/rmt/6cbn
Device path 2 ? filer1:nrst16a
Is this device configured as NDMP? (yes / no) [no]yes
Device path 3 ? sennst1:nrst7a
Is this device configured as NDMP? (yes / no) [no]yes
Device path 4 ?

Drive  2, element 2
Device path 1 ? /dev/rmt/7cbn
Device path 2 ? filer1:nrst17a
Is this device configured as NDMP? (yes / no) [no]yes
Device path 3 ? sennst1:nrst4a
Is this device configured as NDMP? (yes / no) [no]yes
Device path 4 ?

Drive  3, element 3
Device path 1 ? /dev/rmt/8cbn
Device path 2 ?

Please select the appropriate drive type number:
1) 3480                  24) 9840b                 47) optical
2) 3570                  25) 9840C                 48) qic
3) 3590                  26) 9940                  49) SAIT-1
4) 3592                  27) 9940B                 50) SD3
5) 4890                  28) adv_file              51) sdlt
6) 4mm                   29) dlt                   52) sdlt320
7) 4mm 12GB              30) dlt vs160             53) sdlt600
4mm 20GB              31) dlt-s4                54) SLR
9) 4mm 4GB               32) dlt-v4                55) T10000
10) 4mm 8GB               33) dlt1                  56) tkz90
11) 4mm DAT160            34) dlt7000               57) travan10
12) 4mm DAT72             35) dlt8000               58) TS1120
13) 8mm                   36) dst                   59) tz85
14) 8mm 20GB              37) dst (NT)              60) tz86
15) 8mm 5GB               38) dtf                   61) tz87
16) 8mm AIT               39) dtf2                  62) tz88
17) 8mm AIT-2             40) file                  63) tz89
18) 8mm AIT-3             41) himt                  64) tz90
19) 8mm AIT-4             42) logical               65) tzs20
20) 8mm AIT-5             43) LTO Ultrium           66) VXA
21) 8mm Mammoth-2         44) LTO Ultrium-2         67) VXA-172
22) 9490                  45) LTO Ultrium-3         68) VXA-2
23) 9840                  46) LTO Ultrium-4         69) VXA-320

Enter the drive type of drive 1? 45
Are all the drives the same model? (yes / no) [yes] yes

Jukebox has been added successfully

The following configuration options have been set:

> Autocleaning off.
> At least one drive was defined with multiple paths.  All such drives are
defined with a hardware identification as well as a path value to avoid
confusion by uniquely identifying the drive.  The hardware identification
for all drives which have one is always ‘autochanger_name – Drive #’ where
“autochanger_name” is the name you gave to the autochanger that was
just defined, and the # symbol is the drive number.
> Barcode reading to on.
> Volume labels that match the barcodes.

You can review and change the characteristics of the autochanger and its
associated devices using the NetWorker Management Console.

Would you like to configure another jukebox? (yes/no) [no]no

Das manuelle Erstellen der Jukebox hat also geklappt.

Hinweise:

Beim erstmaligen Anlegen eines NDMP-Devices wird ein User/Paßwort für die Authentifizierung am NAS-Gerät abgefragt. In diesem Beispiel sind bereits NDMP-Devices einer anderen Jukebox angelegt, deshalb entfiel die Frage.

Das Autocleaning im Networker sollte wenn möglich nicht benutzt werden und besser die Funtionalität der Tape Library zum Einsatz kommen. Der Networker reinigt nach fest eingestellten Intervallen, auch wenn die Laufwerke ggf. keine Reinigung benötigen. zu häufige Reinigungen verringern die Lebensdauer der Drives.

Zusätzlich zur vorhandenen Tape Library im FC-SAN soll noch eine weitere in Betrieb genommen werden. Es handelt sich um eine IBM 3583 mit 3 LTO-3 FC-Tape drives. Die Tape Library soll im EMC Networker eingerichtet werden und zusätzlich zum Backup-Server auf Basis Solaris 10 auch 2 Netapp NAS-Systemen zur Verfügung gestellt werden. Aus Performancegründen sollen die Netapp-Geräte direkt auf die Tape drives zugreifen (also soll nicht der Networker-Server, sondern die NAS-Systeme selbst als NDMP-Tape-Server agieren). Deshalb stehen zusätzlich zur 64 Slot Autochanger-Lizenz noch 2 Dynamic Drive Sharing – Lizenzen (DDS) zur Verfügung.

Einrichtung der Tape Library IBM 3583

Ich zeige hier nur exemplarisch die wichtigsten Konfigurationsschritte.Die Library ist prinzipiell schon betriebsbereit, im LAN angeschlossen und konfiguriert.

Öffnen der Weboberfläche:

Auf der Weboberfläche stehen Links zur IBM-Homepage. Dort sollte man sich aktuelle Updates für das Gerät besorgen (Firmware für Tape drives, etc.) und diese installieren:

Für diese Arbeit sollte man Geduld mitbringen…

Die Standardeinstellung bei den meisten Herstellern zur Barcode-Label-Erkennung läßt die letzten beiden Zeichen (L2, L3, L4) bei LTO-Bändern aus. Diese kennzeichnen den Bandtyp (LTO-2, LTO-3, LTO-4). Bei IBM Tape Librarys ist das oft auf “Extended” eingestellt. Das verhindert später die sinnvolle Nutzung der Medien in anderen Geräten. Deshalb Volser auf “Default” stellen:

Das Reinigen der Laufwerke sollte man besser der Tape Library überlassen, die das nach Bedarf automatisch durchführen kann (statt im Networker feste Reinigungsintervalle):

Die IBM 3583 hat keinen eigenen FC-Anschluß für die Robotik. Deshalb muß der sog. Control Path auf eines der Tape drives gelegt werden (selbe Target-ID, aber drive = Lun 0, changer = Lun 1).

Anschließend die Library wieder in Betrieb nehmen:

Nun kann man die 3 FC-Tape drives mit dem FC-Switch verbinden.

Kurz und knapp gesagt gab es einige Ecken und Kanten und im Nachhinein ist man wieder ein Stück schlauer… Mittlerweile mit Networker 7.4.2 bin ich mit dem Betrieb des Backups i.A. zufrieden und möchte ein paar Gedanken dazu niederschreiben. Man möge mir die häufige Nennung von EMC Produkten verzeihen, aber da kenne ich das Portfolio einigermaßen.

Backup to Disk aka. B2D

Eigentlich handelt es sich oftmals um Backup to Disk to Tape, aber das nur am Rande… Hier gibt es prinzipiell mehrere Ansätze. In erster Linie spielt hier Performance und der Geldbeutel die maßgebende Rolle:

• Storage-interne Replikation (Point in time Copy), z.B. EMC Timefinder Clone für EMC DMX Storage, Applikationsintegration (Exchange, Oracle, …) und GUI mit EMC Replication Manager → Vorteil: sehr schnell, keine Last im SAN, da Replikation Storage-intern → Nachteil: Preis, herstellerabhängig (jeder große Storage-Hersteller hat das aber: z.B. HDS truecopy, Netapp snapvault/snapmanager)
• Spezialfall CDP: relativ neu auf dem Markt sind Produkte für Continous Data Protection, wo eine fortlaufende Replikation stattfindet und ein Restore auf einen nahezu beliebigen Zeitpunkt erfolgen kann, z.B. EMC Recoverpoint → Vorteil: schnelle Wiederherstellung eines nahezu beliebigen Zeitpunkts → Nachteil: noch zu neu…, Skalierbarkeit, Kompatibilität, herstellerabhängig
• Storage-externe Replikation (Point in time Copy), z.B. Sun AVS unter Solaris → Vorteil: Preis, passend für jedes Storage unter Solaris → Nachteil: hohe Last im SAN
• Backup per LAN auf Networker Advanced File Type devices, die wiederum auf Disks des Servers/Storage Nodes liegen. → Vorteil: unbhängig vom Storage-Hersteller, individuell einstellbar → div. “Ecken und Kanten”, langsamer als Storage-Replikation → bei der Nutzung von Storage mit Datendeduplizierung sehr gute Ausnutzung der Kapazität, z.B. mit ASIS bei Netapp Storage
• Spezialfall Dedup: Backup per LAN mit EMC Avamar Appliance und EMC Networker, Avamar Client ist im aktuellen Networker Client bereits integriert → Vorteil: Datendeduplizierung bereits am Client, d.h. unnötige Daten werden nicht per LAN übertragen → Nachteil: herstellerabhängig, langsamer als Storage-Replikation
• Virtual Tape Library (VTL): Disksystem, das sich nach außen wie eine Tape-Library verhält, z.B. EMC DL3D 4000 → Vorteil: einfache Integration und Bedienung → Nachteil: langsamer als Storage-Replikation → bei der Nutzung der EMC VTL gibt es den zus. Nutzen, daß die EMC Networker Storage Node Funktionalität inegriert ist (gleiches gilt für Netbackup), eine Datendeduplizierung ist ebenso integriert

Networker Advanced Filetype Device (AFTD)

Wie bereits angesprochen haben die AFTDs einige Ecken und Kanten.

• Prinzipiell sind AFTDs wie Tape-Laufwerke zu betrachten, in denen man Volumes einlegen kann. Im Gegensatz zu Tapes funktioniert aber Volume-übergreifendes Backup (Spanning) nicht (wenn das erste Volume voll ist wird für das bereits laufende Backup nicht beim nächsten Volume fortgesetzt). Der Nutzen von mehr als einem Volume pro AFTD ist also eher gering.
• Man muß durch rechtzeitiges Auslagern in einen anderen Pool (Staging – i.d.R. auf Tape) verhindern, daß das AFTD 100% Füllgrad erreicht. Dafür muß das Staging konfiguriert werden. Damit einem das AFTD während des Stagings nicht voll läuft (die Aufräumaktion findet erst nach erfolgreichem Staging statt) muß genügend Reserve in der Speicherkapazität des AFTDs vorgesehen werden. 
• Während eines Staging-Vorgangs kann keine Restore-Operation mit Daten des betroffenen AFTD durchgeführt werden. Aus diesem Grund ist es von Vorteil mehrere AFTDs anzulegen und die Staging-Intervalle relativ kurz zu halten.
• Automatisches Cloning von savesets (über Eigenschaft in der savegroup einstallbar) und zeitlich überlappendes Staging führt zu Problemen (saveset ist ggf. bereits gestagt und kann nicht mehr geclont werden). Es gilt bzgl. Restore die selbe Einschränkung wie beim Staging.

ZFS für AFTDs

ZFS bietet einige Vorteile, aber auch Einschränkungen für die Nutzung von AFTDs.

• Mit ZFS-Filesystemen/Mountpoints als Speicher für AFTDs ist die kurzfristige Erweiterung bei Speichermangel kein Problem – einfach dem ZPool zus. Disks spendieren…
• Ohne das Setzen von Quotas teilen sich alle Filesysteme den gemeinsamen Platz, was eine bessere Ausnutzung der vorhandenen Kapazitäten ermöglicht. allerdings funktioniert dann das Staging nur noch sinnvoll auf Basis der Aufbewahrungsfrist.
• ZFS läßt sich schön verwalten – entweder per GUI oder eingängen CLI-Befehlen.
• ZFS sollte nicht ohne Tuning betrieben werden. Um eine gute Performance zu bekommen sollte man Solaris 10 Update 5 einsetzen. Dort kann z.B. der ZFS Cache Flush für externe, batteriegepufferte Storagesysteme abgeschaltet werden. Ein paar sinnvolle Kernelparameter zu ZFS und Networker können dem Screenshot der /etc/system entnommen werden. Eine Anpassung an die eigene Umgebung ist ggf. erforderlich.

Ü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.

http://www.opensolaris.org/os/community/storage/

SVM, UFS, ZFS – Volumemanager, Filesysteme, Volumes, Snapshots, uvm.

Traditionell wird unter Solaris der SVM als Volumemanager benutzt, UFS ist das Standard-Filesystem. Mit Multiterabyte-Support und Journaling per SVM wurde UFS im Nachhinein aufgebohrt. UFS-Snapshots funktionieren, wirken aber irgendwie wie ein angestückelter Fremdkörper. Das Handling von SVM ist sehr gewöhnungsbedürftig, Freunde gewinnt man so sicherlich nicht. SVM/UFS ist heute nach wie vor für die Spiegelung von lokalen Bootdevices üblich.

Der große Wurf gelang Sun mit ZFS. ZFS ist Volumemanager und Filesystem zugleich. Damit ist die Liste der Features aber noch lange nicht erschöpft. Prinzipiell werden Platten oder Slices (Partitionen) einem Pool zugewiesen, ein entsprechender RAID-Level gesetzt (Striping, Mirroring, RAID-Z) und diverse Parameter wie z.B. Blocksize gesetzt. In einem Pool können dann ZFS-Filesysteme oder Volumes (ähnlich RAW-devices) angelegt und mit Parametern, wie z.B. Quota und Reservierung, versehen werden. Auf Volumes können beliebige Filesysteme aufgebracht werden.

Auf ZFS-Pools, -Filesysteme und -Volumes können Snapshots angewendet werden. Diese können auch geclont und damit beschreibbar wiederverwendet werden.

Mit zfs send/receive können ZFS-Daten über IP repliziert werden.

ZFS Pools können exportiert und auf einem anderen Rechner wieder importiert werden. Geänderte Hardwarepfade, etc. spielen keine Rolle – so lange alle Platten eines Pools zur Verfügung stehen klappt der Import.

ZFS ist (noch?) nicht als Shared Filesystem geeignet. D.h. im Cluster kann es nur für Failoverszenarien eingesetzt werden.

Die Performance von ZFS ist abhängig vom Szenario, wo es zum Einsatz kommen soll. Mittlerweile in den meisten Bereichen UFS ebenbürtig gibt es noch Potential zu VxFS. Tuning ist oft sinnvoll. Je höher das Solaris-Release, desto mehr Möglichkeiten zur Optimierung gibt es.

ZFS bietet neben der eingängen Shell-Kommandos auch ein Webgui.

ZFS hat eingebaute Mechanismen wie “Self Healing” und Schutz gegen “silent data corruption”.

http://blogs.sun.com/chrisg/entry/latency_bubble_in_your_io

http://przemol.blogspot.com/2008/02/zfs-vs-vxfs-vs-ufs-on-x4500-thumper.html

http://blogs.sun.com/SC/entry/why_sunw_nfs_is_required

http://www.solarisinternals.com//wiki/index.php?title=Category:ZFS

http://www.opensolaris.org/os/community/zfs/docs/

http://wiki.edv-widhalm.com/index.php/Solaris_Volume_Manager_%28HowTo%29

http://wiki.edv-widhalm.com/index.php/Zfs_%28HowTo%29

http://www.learning-solaris.com/index.php/category/unix-solaris-storage-volume-management/

http://www.osnews.com/story/19665/Solaris_Filesystem_Choices

http://blogs.digitar.com/jjww/?itemid=52

NAS – iSCSI

Solaris beherrscht iSCSI Initiator (Zugriff auf iSCSI-Volume) und iSCSI Target (Bereitstellen
eines iSCSI Volumes). Dabei kann z.B. ein ZFS Volume als iSCSI Target genutzt werden. Das kann man z.B. nutzen um einem Windows- oder VMware-ESX-Server Diskspace zur Verfügung zu stellen. Von den ZFS Volumes können dann Snapshots erstellt werden.

http://blogs.sun.com/mhuff/entry/introduction_to_iscsi_in_solaris

http://www.opensolaris.org/os/project/iscsitgt/

http://www.opensolaris.org/os/project/isns/

http://blogs.sun.com/lokibear/entry/download_isns_web_based_management

NAS Freigaben – NFS und CIFS

ZFS-Filesysteme beherrschen UNIX- und Windows-ACLs (W2K kompatibel) – damit entfallen viele Hürden als Netzwerkspeicher. Darüber hinaus können in ZFS-Filesystemen NFS- und CIFS-Freigaben als Eigenschaften eingerichtet werden. Eine ADS-Integration ist auch möglich. Der brandneue CIFS-Server mit ZFS-Integration dürfte unter Solaris eine ernsthafte Konkurrenz zu Samba werden.

http://blogs.sun.com/timthomas/entry/opensolaris_as_a_storageos_the

http://blogs.sun.com/dougm/

http://blogs.sun.com/amw/entry/cifs_in_solaris

SAN – Fibrechannel, FCoE

Im Bereich Fibrechannel wurde zuletzt in erster Linie in leichtere Administration auf der Shell investiert. Interessant sind die OpenSolaris-Projekte Comstar und FC over Ethernet. Hier bewegt sich einiges, gerade auch im Bereich Virtualisierung mit NPIV (virtuelle FC-HBAs).

http://www.opensolaris.org/os/project/comstar/

http://www.opensolaris.org/os/project/fcoe/

http://www.opensolaris.org/os/project/npiv/

mpxio – Multipathing

Solaris unterstützt mit mpxio Multipathing für SCSI-, FC-, SAS- und iSCSI-Disks. Speichersysteme mit SCSI SPC-2/3 werrden automatisch erkannt, eine manuelle Zuordnung in der Konfigurationsdatei durch Vendor und Product ist auch möglich, z.B. “EMC SYMMETRIX”. Es wird Failover und Roundrobin als Verfahren unterstützt. Mit dem mpathadm-Kommando ist die Administration sehr eingängig. Durch mpxio wird aus den verschiedenen Hardwarepfaden (verschiedene Controller/Targets, gleiche LUN) ein virtueller Pfad erstellt, der dann für die Konfiguration im Volumemanager benutzt wird.

http://www.opensolaris.org/os/project/mpxio/

last but not least: ZFS in der Praxis … (Achtung! US-Propaganda)

Netapp als Storagepartner stellte kurz die aktuelle Filer-Generation vor. Hauptthema war aber die Netapp-Software zum Thema Exchange. Snapshots, Snapclone und Snapmirror waren mir bekannt, interessant fand ich snapdrive/snapmanager. Hier macht es Netapp den Administratoren leicht. Der Storageadministrator erstellt ein aggregate (~Plattenpool) und weist Disks zu, danach wird darauf ein volume erzeugt und diesem ein entsprechendes Quota zugewiesenen. Die SAN-Konfiguration auf den Switches muß natürlich auch noch getan werden. Danach kann der Exchange/System-Admin mit Snapdrive, das in die MS Managementconsole integriert ist, per iSCSI oder FC (inc. Multipathing, hier aber keine Mischung der beiden Varianten!) 1-x LUNs auf dem freigegebenen volume des Filers erstellen (Größenbegrenzung durch Quota). Das Ganze erfolgt per Wizard. Ebenso das Planen von Snapshots/Snapclones und die Bereitstellung der selbigen als LUN. Hier entfällt also wirklich viel Handarbeit im Bereich LUN-Masking und -Mapping sowie Volumemanager.

Danach wurde noch das Produkt SMBR (Single Mailbox Recovery) vorgestellt. Damit kann man einzelne Mails aus einem Snapshot zurücksichern. Das ist gelinde gesagt etwas schneller als der Weg über die Wiederherstellungsspeichergruppe per Restore. Den Unterschied zwischen Marketing und Realität konnte man in der Live-Demo sehen. Während Netapp noch vor kurzem bei einem Hausbesuch SMBR als Alleinstellungsmerkmal gegenüber den Mitbewerbern anpries fiel beim Start des Programms der Schriftzug “SMBR – powered by Kroll Ontrack” ins Auge. Wie eine kurze Google-Suche bestätigt, hat hier Netapp lediglich die ontrack powercontrols als OEM-Version herausgebracht. EMC hatte sich dazu nicht die Mühe gemacht und empfiehlt das Third Party Produkt ohne Umschweife. Willkommen im richtigen Leben

Irgendwie erinnert mich das an den Open File Manager von St. Bernard, die so ziemlich jeder Backup-Softwareproduzent als OEM vertreibt.

Insgesamt war es eine gelunge Halbtagesveranstaltung – einziger Wermutstropfen war der arg komprimierte Stoff, der etwas kleine Konferenzraum und die arg reduzierte Anzahl der Schnittchen bereits zur Halbzeit Witzig war, daß sich irgendwie keiner traute, mit der Xbox im Warteraum zu zocken…

Die “Fakten”, die beide vorbringen, sind oft unvollständig und zudem kaum nachprüfbar. Eine Entscheidung, wer hier tatsächlich Recht hat/bekommt, wird vor Gericht getroffen werden und das kann dauern. In der Zwischenzeit kann die öffentliche Meinung zu einer Firma aber das Verhalten von Kunden und Aktionären beeinflussen.

Bei der Meinungsmache spielen auch Emotionen einen große Rolle. So versucht Suns CEO Schwartz geschickt die wichtige Open Source Gemeinde auf seine Seite zu ziehen, frei nach dem Motto “ZFS=Open Source=gut gegen WAFL=proprietär=böse“. Dabei wird der Streit zwischen der im Linux-Umfeld verbreiteten GPL-Lizenz und der dazu inkompatiblen von Sun verwendeten CDDL-Lizenz möglichst unter den Teppich gekehrt. Eine Freigabe von ZFS und weiterer unter CDDL-Lizenz stehender Software unter der GPL(v3) will Sun aber wohl tunlichst vermeiden oder zumindest hinauszögern, um sich im Storage-Umfeld und Servermarkt von Linux abgrenzen zu können. Darüber hinaus verweist Schwartz auf das Gericht, welches Netapp für das Verfahren gewählt hat – ein texanisches Provinzgericht, das bereits negativ in Urteilen zu Patentstreitigkeiten aufgefallen ist.

Hitz hingegen verweist auf eine schlecht nachprüfbare Drohung von Seiten Sun aufgrund dessen Netapp die Patentklage einreichte. Darüber hinaus geht er darauf ein, daß Sun durch die Gegenklage Jobs von Netapp-Mitarbeitern in Gefahr bringt und Kunden verunsichert würden.

Für mich sieht es momentan so aus, daß Sun und seine Technologien wie ZFS aktuell willkommene Publicity bekommen. Bis ein Gericht die Sache klärt kann sich Sun als Verteidiger der Open Source darstellen. Dagegen kann Netapp nicht nur einen Imageverlust riskieren. Bei Erfolg der Gegenklage von Sun dürfte wohl eher die Existenz bedroht sein.

Es bleibt also spannend…

Ab OpenSolaris build 77 wird ein im Kernel integrierter CIFS-Server eingeführt, der auf Samba basiert. Dieser unterstützt NFSv4 (inc. Windows-ACLs) und ZFS (integrierter Volumemanager, Quotas, Snapshots, Snapshot-Clones).

Geplant ist darüber hinaus NFSv4 Mirror Mounts (auf NFS-Servern verteilt liegende Daten, die Server-übergreifend transparent für den User im Zugriff sind), ICAP (für Virenscanner-Engines), NDMP und ADS-Integration. Vor kurzem wurde bereits ISCSI-Target bereitgestellt.

Ich glaube damit dürfte der wesentliche Hintergrund zum Patent-Streit zwischen Netapp und Sun klar sein…

Als eher technikorientierter Mensch kann man nur Kopfschmerzen von dieser Patentgeschichte zwischen Netapp und Sun wegen WAFL und angeblichen Patentverletzungen durch ZFS bekommen. Als Kunde von Netapp, Sun, EMC, uvm. und Storageadministration als Tagesgeschäft kennt man die Vorzüge des einen oder anderen Systems der unterschiedlichen Hersteller. Da macht Sun eine gute Figur mit OpenSource-Ambitionen und dem noch ausbaufähigem ZFS, Netapp stellt mit der ASIS-Datendeduplizierungstechnik neue Innovationen integriert in Ontap vor und EMC bietet ein reichhaltiges Spektrum an Produkten von Software bis Hardware. Überall gibt es Sahnestücke und Altbekanntes, ein friedliches Nebeneinander oder gar Miteinander (z.B. Verwaltung von Netapp Filer mit EMC ControlCenter) ist durchaus möglich.

Die Klage von Netapp kann von einem Außenstehenden als Panikreaktion aufgrund guter Wachstumschancen von ZFS im Opensource-Umfeld gewertet werden. ZFS-User sollen damit wahrscheinlich verunsichert werden.

Letztendlich entscheidet aber immer noch König Kunde über Kauf bzw. Einsatz einer Technologie. Dieser kennt zwischenzeitlich auch den unterschiedlichen Einsatz von Patenten: vom Schutz geistigen Eigentums gegen Code-Klau bis zum Machtmittel zur Verhinderung bzw. Verzögerung von Konkurrenz. Wie man am Beispiel SCO gegen den Rest der Welt erkennen kann ist ein Patentstreit nicht zwingend gut fürs Image.