[SAGE-MUC] Erfahrungen ueber netapp

Armin.Kunaschik at computacenter.com Armin.Kunaschik at computacenter.com
Sam Mai 5 22:25:52 CEST 2007


Hallo Hermann,

dann mal kurz meine Erfahrungen (mit etwas weniger Netapp-Bashing) :-)

Der Parallel-Betrieb von NFS und CIFS ist technisch (fast) problemlos 
moeglich. Probleme kriegst Du,
wenn auf Windows UND UNIX Applikationen die gleichen Files locken. Das 
passiert in der Realitaet
sehr selten (hatte ich 1 Mal) und kann nur auf dem Filer mit einem 
privilegierten Kommando behoben werden (Locks entfernen).

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.

Fuer UNIXer einigermassen praktikabel sind NFS-Q-Trees in beide Welten. 
Bei nicht als zu komplexen Permissions (man kann
sowas ja auch ueber separate Q-Trees regeln) ist das ganze gut handhabbar.

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.

Ein Cluster-Failover ist abhaengig von der Anzahl der zu uebernehmenden 
Platten und dauert normalerweise nicht
laenger als 1-2 Minuten... bei vielen Platten vielleicht laenger... weiss 
wieder der Netapp-VB.
Hierbei wird der komplette Zustand uebernommen, d.h. Locks "wandern" mit.
Ich habe das im laufenden Betrieb "testen" muessen, die NFS-Clients haben 
das mehrfach ohne Probleme verkraftet.
"Herkoemmliche" NFS-Server-Cluster kriegen das selten so gut hin (meine 
Meinung).

Was man immer mit einkalkulieren muss, ist, dass das Ontap-Betriebssystem 
(BSD-Kernel) manchmal ziemlich
buggy ist und man "oefter" mal einen Reboot zum Ontap-Upgrade braucht. Der 
dauert auch nur ein paar Minuten,
es ist aber nervig, wenn der Bug wieder mal nicht gefixt wurde. Ob hier 
ein Cluster was bringt, weiss ich nicht,
kann mir aber gut vorstellen, dass beide Knoten die gleiche Ontap-Release 
installiert haben muessen.
Man sollte einen Mixed-Filer nicht sofort in einer neuen Windows-Umgebung 
einsetzen... also wenn ihr schon Vista spielen
wollt, solltet ihr auf Bugs gefasst sein. Der NFS-Teil scheint mir recht 
stabil... zumindest bis NFSv3. NFSv4 koennen die
Filer laut Spec auch. Kann ich aber nix dazu sagen.

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

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.

Unterm Strich bleibt das Fazit: Teuer und funktioniert als NAS wesentlich 
problemloser als selbstgebaute UNIX-NFS-Cluster.
Wer SAN-Storage braucht soll sich HDS/EMC anschauen.

My 2 cents,
Armin

PS: Meine Erfahrungen beziehen sich noch auf Ontap 6.x (Konfiguration) 
bzw. (aus Client-Sicht) auch auf aktuelle Filer/Releases.
Einiges kann sich also schon geaendert haben :-)

PPS: Angeblich hat EMC auch NAS-Boxen, die das gleiche koennen wie die 
Netapp-Filer.. sollen auch "erschwinglich" sein.




Hat sonst noch jemand Erfahrungen mit failover bzw. dem parallelen 
Betrieb von Devices unter NFS und CIFS?

Merci und Gruss,
Hermann




-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://lists.guug.de/pipermail/sage-muc/attachments/20070505/4c88bb47/attachment.html