<br><font size=2 face="sans-serif">Hallo Hermann,</font>
<br>
<br><font size=2 face="sans-serif">dann mal kurz meine Erfahrungen (mit
etwas weniger Netapp-Bashing) :-)</font>
<br>
<br><font size=2 face="sans-serif">Der Parallel-Betrieb von NFS und CIFS
ist technisch (fast) problemlos moeglich. Probleme kriegst Du,</font>
<br><font size=2 face="sans-serif">wenn auf Windows UND UNIX Applikationen
die gleichen Files locken. Das passiert in der Realitaet</font>
<br><font size=2 face="sans-serif">sehr selten (hatte ich 1 Mal) und kann
nur auf dem Filer mit einem privilegierten Kommando behoben werden (Locks
entfernen).</font>
<br>
<br><font size=2 face="sans-serif">Viel mehr Probleme bereiten die Permissions/ACL's:</font>
<br><font size=2 face="sans-serif">Man kann einen Q-Tree entweder mit CIFS-
oder mit NFS-Rechten anlegen, ihn dann aber ueber</font>
<br><font size=2 face="sans-serif">beide Protokolle sharen/exportieren.</font>
<br><font size=2 face="sans-serif">Fall man einen CIFS-Q-Tree auf eine
UNIX-Maschine per NFS mountet, sieht man, dass alle Directories/Files</font>
<br><font size=2 face="sans-serif">world writeable sind, also 777 etc...
sind sie aber nicht. Das nervt die UNIX-User, weil es nicht so funtkioniert,
wie</font>
<br><font size=2 face="sans-serif">es aussieht.</font>
<br><font size=2 face="sans-serif">Andersrum kann man komplexe Windows-ACL's
nicht abbilden, da die UNIX-Permissions manchmal arg einschraenken.</font>
<br>
<br><font size=2 face="sans-serif">Fuer UNIXer einigermassen praktikabel
sind NFS-Q-Trees in beide Welten. Bei nicht als zu komplexen Permissions
(man kann</font>
<br><font size=2 face="sans-serif">sowas ja auch ueber separate Q-Trees
regeln) ist das ganze gut handhabbar.</font>
<br>
<br><font size=2 face="sans-serif">Fuer HA gibt es auch mehrere Moeglichkeiten..
nicht nur einfach "den zweiten Kopf".</font>
<br><font size=2 face="sans-serif">Das Ganze heisst SnapMirror (soweit
ich mich erinnere) und bietet synchrone/asynchrone Kopien auf einen anderen
Filer/Cluster.</font>
<br><font size=2 face="sans-serif">Das kostet nicht nur extra Lizenzen
sondern noch mehr Verschnitt. Das kann der Netapp-VB aber sicher besser
erklaeren.</font>
<br>
<br><font size=2 face="sans-serif">Ein Cluster-Failover ist abhaengig von
der Anzahl der zu uebernehmenden Platten und dauert normalerweise nicht</font>
<br><font size=2 face="sans-serif">laenger als 1-2 Minuten... bei vielen
Platten vielleicht laenger... weiss wieder der Netapp-VB.</font>
<br><font size=2 face="sans-serif">Hierbei wird der komplette Zustand uebernommen,
d.h. Locks "wandern" mit.</font>
<br><font size=2 face="sans-serif">Ich habe das im laufenden Betrieb "testen"
muessen, die NFS-Clients haben das mehrfach ohne Probleme verkraftet.</font>
<br><font size=2 face="sans-serif">"Herkoemmliche" NFS-Server-Cluster
kriegen das selten so gut hin (meine Meinung).</font>
<br>
<br><font size=2 face="sans-serif">Was man immer mit einkalkulieren muss,
ist, dass das Ontap-Betriebssystem (BSD-Kernel) manchmal ziemlich</font>
<br><font size=2 face="sans-serif">buggy ist und man "oefter"
mal einen Reboot zum Ontap-Upgrade braucht. Der dauert auch nur ein paar
Minuten,</font>
<br><font size=2 face="sans-serif">es ist aber nervig, wenn der Bug wieder
mal nicht gefixt wurde. Ob hier ein Cluster was bringt, weiss ich nicht,</font>
<br><font size=2 face="sans-serif">kann mir aber gut vorstellen, dass beide
Knoten die gleiche Ontap-Release installiert haben muessen.</font>
<br><font size=2 face="sans-serif">Man sollte einen Mixed-Filer nicht sofort
in einer neuen Windows-Umgebung einsetzen... also wenn ihr schon Vista
spielen</font>
<br><font size=2 face="sans-serif">wollt, solltet ihr auf Bugs gefasst
sein. Der NFS-Teil scheint mir recht stabil... zumindest bis NFSv3. NFSv4
koennen die</font>
<br><font size=2 face="sans-serif">Filer laut Spec auch. Kann ich aber
nix dazu sagen.</font>
<br>
<br><font size=2 face="sans-serif">Und noch ein "Don't do it"
mit Netapp: Netapp ist gut fuer NFS/CIFS, aber (meiner Meinung nach) nicht
fuer iSCSI, oder</font>
<br><font size=2 face="sans-serif">zum Bereitstellen von FC-LUN's ims SAN.
Persoenliche Erfahrungen habe ich "nur" mit FC-LUN's und die
sind massiv langsamer</font>
<br><font size=2 face="sans-serif">als NFS/CIFS (wie schon von Wolfgang
beschrieben).</font>
<br>
<br><font size=2 face="sans-serif">Beim Erweitern des Storage muss man
beachten, dass man immer gleich mehrere Platten ordert, damit das Raid
performant</font>
<br><font size=2 face="sans-serif">bleibt... das ist aber bei jedem Raid-System
so.</font>
<br>
<br><font size=2 face="sans-serif">Unterm Strich bleibt das Fazit: Teuer
und funktioniert als NAS wesentlich problemloser als selbstgebaute UNIX-NFS-Cluster.</font>
<br><font size=2 face="sans-serif">Wer SAN-Storage braucht soll sich HDS/EMC
anschauen.</font>
<br>
<br><font size=2 face="sans-serif">My 2 cents,</font>
<br><font size=2 face="sans-serif">Armin</font>
<br>
<br><font size=2 face="sans-serif">PS: Meine Erfahrungen beziehen sich
noch auf Ontap 6.x (Konfiguration) bzw. (aus Client-Sicht) auch auf aktuelle
Filer/Releases.</font>
<br><font size=2 face="sans-serif">Einiges kann sich also schon geaendert
haben :-)</font>
<br>
<br><font size=2 face="sans-serif">PPS: Angeblich hat EMC auch NAS-Boxen,
die das gleiche koennen wie die Netapp-Filer.. sollen auch "erschwinglich"
sein.</font>
<br>
<br>
<br>
<br>
<br><font size=2><tt>Hat sonst noch jemand Erfahrungen mit failover bzw.
dem parallelen <br>
Betrieb von Devices unter NFS und CIFS?<br>
<br>
Merci und Gruss,<br>
Hermann<br>
<br>
<br>
<br>
</tt></font>
<br>