[SAGE-MUC] Erfahrungen ueber netapp

Andreas Walter awalter at goldenhind.de
Son Mai 6 22:31:15 CEST 2007


Hallo,

noch ein paar Ergänzungen von meiner Seite.
Meine praktischen erfahrungen beziehen sich auf Ontap 6.
Bzgl. Ontap 7 (aktuelle Version) kann ich nur Erfahrungen von
Kollegen weiter geben.

Wir verwenden die NetApp Filer hauptsachlich zu Speicherung von
Office Dokumenten in Kunden Lokationen (über ganz Deutschlan
verteilt) wo z. T. kein technisches Wissen vorhanden ist.

Wir haben auf wenigen Filern NFS Lizenzen (bei der Beschaffung kostete
es noch extra.

Die Sicherung erfolgt per Snap Mirror (eigener Mechanismus von NetApp)
auf ein R200 System nach München. Da immer nur die Deltas übertragen
werden, geht es damit ganz gut.


Armin.Kunaschik at computacenter.com wrote:

[...]

> Viel mehr Probleme bereiten die Permissions/ACL's:
> Man kann einen Q-Tree entweder mit CIFS- oder mit NFS-Rechten anlegen,
> ihn dann aber ueber
> beide Protokolle sharen/exportieren.
> Fall man einen CIFS-Q-Tree auf eine UNIX-Maschine per NFS mountet, sieht
> man, dass alle Directories/Files
> world writeable sind, also 777 etc... sind sie aber nicht. Das nervt die
> UNIX-User, weil es nicht so funtkioniert, wie
> es aussieht.
> Andersrum kann man komplexe Windows-ACL's nicht abbilden, da die
> UNIX-Permissions manchmal arg einschraenken.
Kann ich bestätigen.

> Fuer HA gibt es auch mehrere Moeglichkeiten.. nicht nur einfach "den
> zweiten Kopf".
> Das Ganze heisst SnapMirror (soweit ich mich erinnere) und bietet
> synchrone/asynchrone Kopien auf einen anderen Filer/Cluster.
> Das kostet nicht nur extra Lizenzen sondern noch mehr Verschnitt. Das
> kann der Netapp-VB aber sicher besser erklaeren.
SnappMirror erstellt einen Snapshot des Volumes und überträgt dann das
Delta an das Zielsystem.
Der initiale Lauf darf nicht unterbrochen werden, danach sind
Unterbrechungen möglich.
Durch den Snapshot entsteht der Verschnitt.

> Und noch ein "Don't do it" mit Netapp: Netapp ist gut fuer NFS/CIFS,
> aber (meiner Meinung nach) nicht fuer iSCSI, oder
> zum Bereitstellen von FC-LUN's ims SAN. Persoenliche Erfahrungen habe
> ich "nur" mit FC-LUN's und die sind massiv langsamer
> als NFS/CIFS (wie schon von Wolfgang beschrieben).
Bei uns wurde iSCSI getestet und nicht wéiter verwendet.
Der mir bekannte Grund ist, dass die iSCSI Laufwerke als ein File im
Filesystem des Filer erscheinen. Da sich bei der kleinsten Änderung
das File ändert, wird bei jeder Sicherung ein 50 GB File gesichert.
Auf die Dauer nicht besonders effizient.
Über die iSCSI Clients wollte man es nicht machen.


> Beim Erweitern des Storage muss man beachten, dass man immer gleich
> mehrere Platten ordert, damit das Raid performant
> bleibt... das ist aber bei jedem Raid-System so.
NetApp verwendet ein RAID4. Wer es nicht gleich weis: Fürs Parity gibt es
hier eine eigene Platte, die immer angefasst werden muss. Das erklärt
die von Wolfgang beobachtete, schlechte Performance.
Wenn jetzt ein Volume erweitert wird, versucht die Firmware auch die
neuen Platten zuerst auf den gleichen füllstand zu bringen. Das tötet
bei wenigen (einer) Platten natürlich die Performance.


> Unterm Strich bleibt das Fazit: Teuer und funktioniert als NAS
> wesentlich problemloser als selbstgebaute UNIX-NFS-Cluster.
Oder als ein eignenbau CIFS Server. Wenn mal Hardware ausfällt, kommt
jemand von NetApp und tauscht es aus und es muss keiner hin fahren.

> Wer SAN-Storage braucht soll sich HDS/EMC anschauen.
ACK.

	Andreas