Otmanix’ Blog

Thecus (Halle 13, D85) stellt auf der Cebit neue NAS-Systeme vor, darunter auch das N5500 mit 5 Disks. Das Gerät soll stromsparend und leise arbeiten, mit einem Intel Celeron ausgestattet sein und als Filesysteme ext3, XFS und ZFS unterstützen.

Ich habe noch keine Details zum OS des Geräts gefunden, bzgl. ZFS vermute ich aber mal schwer, dass das mit ZFS auf Fuse realisiert wird.

• FCoE Target Packages and Source Available
• GCC for Sun Systems 4.2.0 cross compiler now available
• Zielsetzungen für OpenSolaris 2008.11
• APC USV daemon unter Solaris
• POWERtop
• OpenSolaris FAQ for newbies
• OpenSolaris auf Sparc
• PuTTY Connection Manager
• Building Solaris from Source
• Solaris iSCSI Chap/Radius FAQ
• Skript für Zuordnung von Prozessen zu Portbelegung
• Mounting an ISO

Im OpenSolaris-Storagebereich gibt es wieder News: ab Nevada Build93 ist der erste Wurf einer herstellerneutralen Tape Multipathing Lösung verfügbar. Änderungen in der Multipathing-Software MPxIO (bis dato nur für Disks) und im ST-Tapetreiber machten das möglich. Die Informationen dazu sind noch etwas spärlich, im Code Review und im Opensolaris-Storage-Forum findet sich etwas dazu.

Die Code-Änderungen ermöglichen es, daß ein mehrpfadig angebundenes Tape-Laufwerk über MPxIO als nur ein ST-Tape-device dargestellt wird. Die Lösung bietet Failover bei Ausfall des aktiven Pfads, aber kein Loadbalancing.

Hersteller wie IBM bieten für ihre größeren Tapelibraries schon länger Multipathing-Support (inc. Loadbalancing) für verschiedene Betriebssysteme. Dazu muß allerdings der IBM-Tapetreiber benutzt und das kostenpflichtige Multipathing-Feature aktiviert werden. Infos zum IBM Tape Treiber unter Solaris und Multipathing gibt es hier (Seite 188).

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