QNAP mit MyCloudNAS, Netgear mit ReadyNAS Photos II sowie Egnyte, Buffalo mit Cloudstation und Thecus mit Thecusshare bieten ähnliche Cloud-Funktionalitäten.

Ich habe mir im weihnachtlichen Konsumrausch ein Synology DS411j zugelegt. In diesem Artikel möchte ich auf Besonderheiten und Fallstricke beim Einsatz von von Photo Station 5 aufmerksam machen.

Auf der Homepage wird zwar der Sachverhalt erklärt. Aber wer liest schon die Anleitung oder Produktbeschreibung vollständig durch? Hier der relevante Absatz:

Eine weitere Option zum Hochladen von Fotos ist Synology Assistant. Mit ihm können Sie Fotos hochladen, ohne die Verwaltungsoberfläche zu öffnen. Wählen Sie einfach die Anwendung Foto-Uploader im Synology Assistant, und Sie erhalten eine intuitive Benutzeroberfläche, die einem Assistenten ähnelt. Der Foto-Uploader vereinfacht das Hochladen und ermöglicht Ihnen das Veröffentlichen von Fotos und Videos, ohne dass ein Browser erforderlich ist. Zusätzlich wandelt der Foto-Uploader die Miniaturansichten der Fotos und Videos mit der Rechnerleistung Ihres Desktops um, was den Vorgang deutlich beschleunigt. Diese kompakte Anwendung wird ergänzt durch die Vorschau der Miniaturansichten und die Auswahl der Videoqualität.

Wenn man sich wundert, warum das Synology-NAS nach dem Betanken mit Photos und Videos via CIFS/NFS permanent ausgelastet ist, hat man obigen Absatz überlesen. Beim Befüllen des NAS werden Miniaturansichten von Bildern und Web-kompatible Versionen von Videos erstellt. Der integrierte ARM-Prozessor ist hier aber schnell hoffnungslos überlastet. Man muß aber deshalb nicht zwangsläufig zu einem NAS mit Intel CPU greifen. Über die Funktion Foto Uploader im Synology assistant kann man diese CPU intensiven Berechnungen am PC/MAC ausführen.

 Jeder sollte das Recht haben, eine eigene Fotosammlung oder ein Blog auf der DiskStation zu besitzen – und genau das bietet Ihnen Photo Station jetzt in DSM.

Standardmäßig richtet das Synology NAS eine Freigabe für Photos ein, z.B.\\nas\photo bzw. http://nas/photo/

Wenn man auf dem Synology NAS individuelle Home-Verzeichnisse pro Benutzer anlegt besteht die Möglichkeit pro Benutzer auch einen Photo-Bereich anzulegen: \\nas\admin\photo bzw. http://nas/~admin/photo/

Zunächst einmal aktiviert man individuelle Home-Verzeichnisse im DSM. Danach aktiviert man Photo Station 5 im DSM, stellt die Qualität für Miniaturansichten ein und vergibt ggf. noch Berechtigungen:

Nun kann jeder DSM Benutzer eine persönliche Photo Station 5 auf Wunsch aktivieren:

Nun wird der Synology Assistant konfiguriert um den Foto-Uploader nutzen zu können:

Danach wählt man den Karteireiter Foto-Uploader aus und bestimmt Quelle und Ziel des Photo/Video-Uploads:

Update

Im Synology Wiki gibt es einen Artikel wie man die Berechnung der Miniaturansicht über die NAS-CPU beschleunigt.

EMC hatte einen product manager und Leute aus der Entwicklung (siehe Photo) über den großen Teich fliegen lassen und Trainer aus dem Schulungscenter Schwalbach bereitgestellt um Kundenfeedback direkt entgegenzunehmen, an Diskussionen teilzunehmen und Auskunft zur Roadmap zu geben.

Rückblick

Mit der Übernahme von Avamar und Datadomain (und zuvor Legato) war eine Umstrukturierung bei EMC überfällig. Gerade im Networker-Umfeld hinkte die Entwicklung in einigen Punkten dem Markt hinterher, was mit dem kürzlich erschienenem Networker 7.6.2 und NMM 2.3 endlich kompensiert wurde. Die EMC BRS Division erweckt heute den Eindruck sich intern sortiert und strategisch neu ausgerichtet zu haben.

Fazit

Als Kunde möchte ich mich bei EMC hiermit für die gelungene Veranstaltung bedanken. Sehr positiv fand ich den direkten Kontakt zu Entwicklung und Produktmanagement. Alleine die Möglichkeit RFE bei dieser Gelegenheit einzukippen und direktes Feedback zu Machbarkeit und Chancen auf Realisierung zu bekommen ist aus meiner Sicht die Anreise wert. Die Frage/Antwort-Stunde und die entstandenen Diskusssionen während der Vorträge fand ich überwiegend positiv. Im Gegensatz zu anderen Herstellerveranstaltungen hielten sich hier die Marketing stunts in engen Grenzen, was wohl dem überwiegend Admin-lastigen Publikum zuzuschreiben war Die Gespräche mit anderen Kunden in den Pausen waren einerseits interessant und informativ, anderseits fiel manches auch in die Kategorie “geteiltes Leid ist halbes Leid”

Mein Dank auch an Hr. Lehner, der sich mit einer Kundenpräsentation vorgewagt und damit eine fruchtbare Diskussion angestoßen hatte. Aus meiner Sicht ist diese Veranstaltung ein echter Pflichttermin für Leute, die Networker einsetzen.

Wie man hier sieht funktioniert die Deduplizierung. Es wird weniger Platz in der VTL benötigt als Daten dorthin gesichert werden.

Allerdings wird bereits deutlich mehr Platz benötigt als ursprünglich veranschlagt…

Man kann deutlich erkennen, dass nur ein Bruchteil der Daten, die zur VTL gesichert werden (blau) auch tatsächlich auf der Platte landen. Allerdings nähert sich die Auslastung bereits dem tatsächlich phys. vorhandenem Platz.

Problemanalyse – woher kommen die Daten?

Woran könnte das liegen? …hoffentlich nicht falsches Sizing?!?

Nun, bei genauerem Hinsehen fiel mir auf, dass die blaue Linie immer weiter steigt. Diese Kapazität war bereits ein Vielfaches der Menge, die beim Sizing veranschlagt wurde. Was also läuft hier falsch? Nach Analyse der anfallenden Datenmengen stand fest, dass nicht signifikant mehr Daten pro Woche anfallen, als im Sizing veranschlagt. Allerdings fiel beim Sichten der Pools auf, daß Bänder eines best. Pools nicht laut Vorgabe verfielen.

Beim Prüfen eines betroffen Bandes, das schon abgelaufen sein sollte fiel auf, dass savesets eines best. Rechner die falsche Aufbewahrungsfrist (deutlich länger als vorgesehen) eingetragen hatten.

savesets des Bands xxx anzeigen, sortiert nach Verfallsdatum:
mminfo -av -r ‘volume, client, name, savetime, ssflags, clflags, ssid(53), ssretent’ -q “volume=xxx” -o e

In den Einstellungen des betroffenen Networker Clients wurden danach auf die korrekte Browse/Retention Policy umgestellt. Damit würden zukünftige Sicherungen korrekt aufbewahrt.

Durch die unterschiedlichen Einstellungen der Clients bei Browse/Retention Policy und zugleich Sichern in den selben Pool kam es zu negativen Effekten. Zur ungeplant größeren Datenmenge des einen Rechners kam hinzu, dass Bänder mit savesets (von verschiedenen Clients und) unterschiedlicher Aufbewahrungsfrist erst verfallen, wenn die längste Aufbewahrungsfrist abgelaufen ist.

Problembeseitigung im EMC Networker

Zunächst einmal galt es die savesets zu löschen, die eigentlich bereits verfallen sein sollten.

savesets des Clients ZZ älter als Datum MM/DD/YY löschen:
for xxx in `mminfo -av -r “ssid(53)” -q “client=ZZ,savetime<=MM/DD/YY”`; do nsrmm -d -S $xxx -y; echo $xxx; done

danach Mediendatenbank bereinigen:
nsrim -X

Dadurch änderte sich der Status einiger Bänder: full->recyclable

Das Aufräumen hat sich scheinbar gelohnt:

backup:/ # mminfo -mv|grep expired|wc -l
685
backup:/ # mminfo -mv|wc -l
2831

Es wurden 24% der Bänder zum Überschreiben freigegeben.

space reclamation

Wann aber wird der belegte Platz wieder freigegeben? Bei einer Datadomain VTL wird der Platz zum Freigeben vorgemerkt, wenn entweder im Networker das Band mit Status recyclable mit neuen Daten überschrieben, d.h. das Band wiederverwendet wird, oder das Band neu gelabelt wird. Das manuelle Labeln ist je nach Dringlichkeit ggf. die geschickerte Variante.

Status vor dem Labeln:

sysadmin@datadomain2# vtl tape show all barcode V20908L1
Processing tapes….
Barcode    Pool        Location        State      Size             Used (%)   Comp   ModTime
——–   ———   ————-   —–   ——-   ——————   —-   ——————-
V20908L1   NetWorker   vtl2 slot 909   RW      100 GiB   100.0 GiB (99.95%)    22x   2011/04/04 00:01:21
——–   ———   ————-   —–   ——-   ——————   —-   ——————-
VTL Tape Summary
—————-
Total number of tapes:     1
Total pools:               1
Total size of tapes:       100 GiB
Total space used by tapes: 100.0 GiB
Average Compression:       22.4x

backup:/datadomain2/vtc/NetWorker # ls -lh V20908L1
-rw-rw-rw- 1 root root 101G 13. Mär 23:53 V20908L1

Status nach dem Labeln:

sysadmin@datadomain2# vtl tape show all barcode V20908L1
Processing tapes….
Barcode    Pool        Location        State      Size           Used (%)   Comp   ModTime
——–   ———   ————-   —–   ——-   —————-   —-   ——————-
V20908L1   NetWorker   vtl2 slot 909   RW      100 GiB   0.0 GiB ( 0.00%)     0x   2011/04/18 17:46:44
——–   ———   ————-   —–   ——-   —————-   —-   ——————-
VTL Tape Summary
—————-
Total number of tapes:     1
Total pools:               1
Total size of tapes:       100 GiB
Total space used by tapes: 0.0 GiB
Average Compression:       44.6x

backup:/datadomain2/vtc/NetWorker # ls -lh V20908L1
-rw-rw-rw- 1 root root 251M 18. Apr 17:46 V20908L1

Der Platz wird aber tatsächlich erst nach dem Lauf des cleanup-Jobs in der Datadomain VTL nach Prüfen der Dedupe-Abhängigkeiten freigeben. Das Cleanup lässt sich auch manuell starten. Dazu möglichst eine betriebsarme Zeit der VTL wählen und dann per sysadmin anmelden:

login as: sysadmin
Data Domain OS 4.9.2.0-222697
Using keyboard-interactive authentication.
Password:
Welcome to Data Domain OS 4.9.2.0-222697
—————————————-
sysadmin@datadomain2# filesys clean status
Cleaning finished at 2011/04/12 11:38:57.
sysadmin@datadomain2# filesys clean start
Cleaning started.  Use ‘filesys clean watch’ to monitor progress.
sysadmin@datadomain2# filesys clean watch
Beginning ‘filesys clean’ monitoring.  Use Control-C to stop monitoring.
Cleaning: phase 1 of 10 (pre-enumeration)
100.0% complete,  7532 GiB free; time: phase  0:00:25, total  0:00:26
Cleaning: phase 2 of 10 (pre-merge)
100.0% complete,  7532 GiB free; time: phase  0:01:33, total  0:41:32
Cleaning: phase 3 of 10 (pre-filter)
100.0% complete,  7532 GiB free; time: phase  0:08:41, total  0:50:14
Cleaning: phase 4 of 10 (pre-select)
100.0% complete,  7517 GiB free; time: phase  0:59:20, total  1:49:34
Cleaning: phase 5 of 10 (candidate)
100.0% complete,  7513 GiB free; time: phase  0:26:27, total  2:16:01
Cleaning: phase 6 of 10 (enumeration)
100.0% complete,  7486 GiB free; time: phase  0:44:14, total  3:00:15
Cleaning: phase 7 of 10 (merge)
100.0% complete,  7481 GiB free; time: phase  0:02:02, total  3:02:18
Cleaning: phase 8 of 10 (filter)
100.0% complete,  7471 GiB free; time: phase  0:09:48, total  3:12:07
Cleaning: phase 9 of 10 (copy)
100.0% complete, 10571 GiB free; time: phase  9:58:40, total 13:10:47
Cleaning: phase 10 of 10 (summary)
100.0% complete, 10569 GiB free; time: phase  0:47:24, total 13:58:12

Somit konnten 3TB Kapazität auf o.g. DD670  zurückgewonnen werden, auf der zweiten DD670 waren es 5TB.

zum Thema “Split-Brain”

Zum Thema Vmware SRM vs. Vmware Stretched Cluster mit EMC VPLEX:

Understanding vSphere Disaster Recovery/Avoidance options

Als zentrale Komponente kommt dann eine VTL mit Deduplizierung zum Einsatz – zuletzt war noch EMC mit 2 Datadomain DD670 und Quantum mit 2 DXi6700 im Rennen. Die Entscheidung fiel letztendlich knapp zugunsten von EMC aus.

Nächstes Jahr wird es also hier wieder etwas RZ-techniklastiger im Blog zugehen. Zu berichten gibt es sicherlich genügend.

P.S.

Für dich Anton hier nochmals der Hinweis: Die zukünftige Backuplösung für die Niederlassungen heißt nicht EMC Avatar

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.

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

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.

Knapp 1t schwere DMX4s sanft zu bewegen ist gar nicht so einfach.

Die ebenfalls geladenen einarmigen Banditen für die Spielbank wollte der Spediteur nicht herausrücken, obwohl die im RZ einen guten Platz bekommen hätten.

Zum Download ist das in Kürze als SXCE (Solaris Express Community Edition) verfügbar. Dabei wird aber vorerst nur der textbasierte Installer die Auswahl für ZFS ermöglichen (ab build 90).

Laut dem Blog von Robin Guo, Mitarbeiter am ZFS-Projekt, arbeitet Sun eifrig auf die Integration in Solaris 10 Update 6 hin.

Das sind doch erfreuliche Aussichten! Ich bin allerdings gespannt wie nun das Thema Liveupgrade aussehen wird – darf hier Project Indiana aka OpenSolaris 2008.05 Pate stehen? Dieses dürfte durch den Putback in der nächsten Version dann auch für Sparc erhältlich sein.

Jeff Bonwick, Chief Technical Officer (CTO) of Storage Technologies bei Sun, hat in seinem jüngsten Blogbeitrag Photos mit Linus Torvalds und dem vielversprechenden Hinweis “stay tuned” veröffentlicht. Man sollte dazu auch wissen, daß Bonwick Leiter des ZFS-Entwicklungsteams ist.

Was man nun in dieses Treffen hineininterpretieren kann überlasse ich dem Leser. Nur so viel vorab: das Thema CDDL und GPL v2/3 dürfte eine Rolle gespielt haben.

Interessant dazu dürfte der Blogeintrag von Jim Grisanzio, Mitglied des OGB, und die Auflösung des Bilderrätsels im Blog von Leon Koll sein.

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