[SAGE-MUC] Erfahrungen ueber netapp

[Wolfgang Stief]

Hallo nochmal!

On 2007-05-05 17:43 +0200, Christian Horn wrote:
>> unseren User-Fileserver-Cluster zu ersetzen durch eine Netapp Box.
>
> An dem punkt frag' die netapp-typen auch nochmal genauer.

Ach, den Cluster-Punkt habe ich ja vorhin ganz ueberlesen :-)

> Mein letzter stand zu solchen cluster-sachen war der, das man wenn man 
> richtig clustern will also mit 2 netapp-koepfen in verschiedenen 
> brand- abschnitten, jeder mit einem plattenstapel im zugriff, ein 
> cluster bilden koennen.

Das Grundprinzip eines NetApp Metro-Clusters ist folgendes: Ein Knoten 
je Brandabschnitt, jeder Knoten hat lokal einen Plattenstapel und am 
Remote-Knoten nochmal einen Plattenstapel, ausgefuehrt als Mirror. Der 
Remote-Knoten entsprechend umgekehrt. Alles redundant verkabelt. Eine 
solche Anordnung bringt von Haus aus vier (!) Brocade-Switches mit. Die 
duerfen auch fuer nichts anderes verwendet werden. Kundige Mitleser 
koennen sich mal Gedanken ueber die Anzahl der notwendigen 
Querverbindungen machen. Es sind deutlich mehr als zwei. Wenn du mehr 
Platten brauchst, musst du die Disk-Shelfs natuerlich doppelt kaufen, 
ist ja alles gespiegelt. Die Volumes auf den Platten selbst sind aber 
nochmal als RAID-5 oder RAID-DP ausgefuehrt. RAID-DP ist NetApps 
Implementierung von douple parity (was woanders gerne mal RAID-6 
heisst).

In der Praxis heisst das: um zB. 2TB Nutzkapazitaet in einem RAID-DP zu 
erreichen, brauchst du an EINEM Plattenstapel -- je nach Plattengroesse 
-- ca. 2.4 TB - 3 TB physikalische Platten. Und das ganze dann nochmal 
am Remote-Knoten, weil der das ja alles spiegelt (blockweise). Heisst: 
aus ca. 5-6 TB Physik werden 2TB netto fuer deine User. Das ist vor 
allem gut fuer Disk-Hersteller.

Der Cluster kann zwar als active/active laufen, kann aber NICHT an 
beiden Nodes die gleichen Freigaben rausgeben. Ist also nur ein 
halbherziges active/active. Man kann sehr wohl an jedem Knoten 
unterschiedliche Freigaben haben.

Bei Ausfall eines Knotens uebernimmt der andere Platten und IP des 
ausgefallenen, startet Aggregate und Volumes an und gibt die Shares 
wieder frei. Das passiert ueberwiegend automatisch. Ob man das 
Rueckschalten von Hand initiieren muss oder ob das auch automatisch 
geht, weiss ich nicht mehr genau, ich hatte so ein Ding erst einmal fuer 
drei Wochen in der Hand und das ist etwa ein Jahr her.

Deutlich weniger Verschnitt hat man uebrigens mit einem V-Cluster: Die 
Knoten koennen mit fast beliebigen Storages drunter arbeiten, sind aber 
insgesamt auch etwas weniger HA.

In dem Zusammenhang faellt mir noch ein genereller Nachteil von Netapp 
ein: Die RAID-Berechnung passiert in Software auf einer Legacy-CPU. 
Heisst im Klartext irgendwas intelmaessiges. Das Betriebssystem basiert 
auf Linux oder BSD (kann mich nicht mehr genau erinnern, sieht man an 
den Bootmeldungen). Darin laeuft auch der Code zum Volume-Management und 
damit eben auch das XOR-Zeugs. Wir haben mal an einem fast identischen 
Versuchsaufbau eine FCP-LUN aus einer Netapp mit einer FCP-LUN aus einer 
IBM DS4500 gemessen, alles mit 2Gbit/s FC, Brocade-Switches, mit 
QLA-HBAs unter Linux. Auf der IBM haben wir knapp die Obergrenze eines 
einzelnen Kanals erreicht (ca. 160MB/s sustained sequential write), die 
NetApp konnten wir nicht ueber die 100MB/s kriegen. Was mir dabei auch 
noch auffiel: Eine FCP-LUN wird bei Netapp als Containerfile ins WAFL 
gelegt. Richtiges Storage macht sowas als Block auf das Array. Mit 
iSCSI-LUNs macht NetApp uebrigens das gleiche *kopfschuettel*

Mal sehen, was mir noch so an NetApp-Bashing in den Sinn kommt den Abend 
ueber :-)


Gruesse aus Muenchen
wolfgang

-- 
stief at guug.de                                   http://www.guug.de/
GPG: www.chaes.de/id.html        http://www.guug.de/lokal/muenchen/