Otmanix’ Blog

Einrichtung der Tape Library im EMC Networker – 2. Versuch

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.

Problemstellung

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.

• Der Serverraum – bequem erreichbar durch die Damentoilette
• Chuck Hollis von EMC über “Do it yourself Storage”
• Mike Dillon von Sun zum aktuellen Stand des Patentstreits Sun ZFS vs. Netapp WAFL
• Dave Hitz von Netapp im o.g. Patentstreit zu ZFS und OpenSource

Vor einiger Zeit stand ein Austausch der Backup-Hardware an. Damals wurde sich für eine T2000 als Backup-Server, ein SE6140 als Disksystem für Backup to Disk und ein STK SL500 Tapesystem (LTO3) entschieden. Bei dieser Gelegenheit wurde auch die Backupsoftware EMC Networker von 7.2.2 auf 7.4 aktualisiert.

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.

Das Projekt “Common Multiprotocol SCSI Target” hat es mit dem build90 zurück in den OpenSolaris-Code geschafft. Was bringt das nun für neue Features? Prinzipiell ist das Ziel des Projekts OpenSolaris als Storageplattform in die Lage zu versetzen in einem Fibrechannel-SAN Plattenplatz per SCSI-LUNs zur Verfügung zu stellen.

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