LUNs vs. NFS

[Azrael]

Hallo Leute,

ich bin neu in diesem Forum und habe direkt eine Frage.

Wir haben im Unternehmen mehrere ESX Server die über FC-Adapter an ein SAN angeschlossen sind.

Demnächst kommt die Storage virtualisierung in unser Haus. Von NetApp.

Die NetApp Jungs sagten uns, wir sollen die ESXen mit NFS Volumes betreiben. (Ethernet Protokoll)

Unsere Struktur ist auf FC aufgebaut.. was etwas Teuer war

Nun gaben uns die Jungs einen Tipp FC over IP ! ! ???? Fiber Channel Protokoll in IP Protokoll umwandeln?

Für mich ist das doppelt gemoppelt und nicht wirkliche Perfomant.

Kennt jemand von Euch vielleicht einen richtigen Grund von LUNs auf NFS umzusteigen?

Gruß
Azrael

[Oculus]

Also FCoE ist ja noch nicht wirklich etabliert und im Wesentlichen dazu da, das FC-Protokoll über weitere Strecken zu transportieren und dass sich damit relativ leicht komplexere Topologien aufbauen lassen.
Von der Perfomance ist das sicher okay - mit 10GE sollte das flutschen, auch, wenn das Protokoll einen ziemlichen Overhead haben soll.

Naja, und NFS ist sicher mindestens so schnell wie FC, wenn nicht schneller - mit 10GE ist das richtig schnell! Aber eben auch nicht so sicher. In der Version 3, wird einzig die IP-Adresse des Client als Authentifizierungskriterium herangezogen. Zwar ist das in der Version 4 anders, aber die hat ja wohl meines Wissens nach noch keinen Einzug in die ESX-Welt gefunden. Also, NFS ist nicht langsamer als FC und iSCSI, wenn das Ethernet entsprechende Performance hat. Rein von der geschwindigkeit her, ist NFS das Schnellere von allen (10GE), weil es nur wenig Overhead hat.

Gruß,
Oculus

[bla!zilla]

NetApp sagt euch, ihr sollt IPFC fahren, damit ihr NFS nutzen könnt? Fragt bitte mal nach was die für Drogen nehmen, ich kaufe gleich einen ganzen Sack davon.

Also FCoE ist ja noch nicht wirklich etabliert und im Wesentlichen dazu da, das FC-Protokoll über weitere Strecken zu transportieren und dass sich damit relativ leicht komplexere Topologien aufbauen lassen.

Das ist falsch. FCoE ist der Ansatz Fibre-Channel über Ethernet zu fahren, damit man im RZ nur noch eine einzige Netzwerktopologie hat. Das hat NICHTS mit Weitverkehr oder so zu tun. Einfach nur mit Kostensenkung und Vereinheitlichung der Infrastruktur.

Von der Perfomance ist das sicher okay - mit 10GE sollte das flutschen, auch, wenn das Protokoll einen ziemlichen Overhead haben soll.

Deswegen schrauben die auch wie dir Irren am Ethernetstandard rum, damit Ethernet endlich all das kann, was FC schon seit Jahren kann....

Naja, und NFS ist sicher mindestens so schnell wie FC, wenn nicht schneller - mit 10GE ist das richtig schnell!

Niemals. Um diesen ganzen Ethernethype mal zu entmystifizieren: Fibre-Channel hat vom Protokollstandard her eine nutzbare Bandbreite von 98,5%. Gerade einmal 1,5% sind Protokolloverhead. Das heißt ich kann bei 1 GB FC rund 98 MB/s übertragen, bei 2 GB knapp 196 MB/s, bei 4 GB 392 MB/s und bei 8 GB Fibre-Channel sind es rund 784 MB/s. Ethernet dagegen ist, dank CSMA/CD, die Hölle... Wenn es bei iSCSI gut läuft komme ich auf vielleicht im Schnitt 70 MB/s bei 1 GbE. Bei 10 GbE sind es also max. 700 MB/s, wenn alles perfekt läuft. Bei Fibre-Channel habe ich das garantiert. Vergleichen wir noch mal: 8 GB Fibre-Channel rund 780 MB/s, 10 GbE vielleicht 700 MB/s. Na, was ist nun "richtig schnell"?

Also, NFS ist nicht langsamer als FC und iSCSI, wenn das Ethernet entsprechende Performance hat. Rein von der geschwindigkeit her, ist NFS das Schnellere von allen (10GE), weil es nur wenig Overhead hat.

NFS ist langsamer als FC und iSCSI. Nur leidet NFS nicht unter dem Problem der SCSI Reservations.

Und mal ehrlich: Wenn ihr eine FC Infrastruktur habt und nun NFS nutzt, dann müsste euch euer Controller/ Geschäftsführer/ Vorstand eigentlich in den Hintern treten. Macht doch nicht so einen Quatsch.

btw: Wenn euch ein Hersteller sowas empfiehlt, solltet ihr überlegen evtl. den Hersteller zu wechseln. Also wenn der Deal nicht schon gelaufen ist, schaut euch doch mal DataCore SANmelody oder SANsymphony, bzw. HP StorageWorks SAN Virtualization Services Platform als Storage-Virtualisierungsslösung an.

Bei mehr Fragen zu den Produkten kannst du mich gerne per PN oder ICQ ansprechen.

[Azrael]

Hallo bla!zilla

vielen Dank für deine Antwort.

Wir haben im Unternehmen mehrere Abteilungen. Eine davon ist die Storage Abteilung die andere ist die "ESX-Abteilung" und wir haben extra für viel Geld ein FC Netz aufgebaut. Das wir natürlich behalten werden.

Wir waren nur bei NetApp um uns auch ein bissel zu Informieren.

Ich habe von Anfang an gesagt, dass wir niemals FCoE machen sollen. Weil ich versuche ein optimiertes Protokoll umzuwandeln in ein Ethernet Protokoll.

Ich wollte nur einmal Eure Meinung wissen und danke Euch, dass ihr die gleiche Meinung habt.

Vielen Dank nochmal.

Der Deal mit NetApp bezüglich der Storage virtualisierung ist gelaufen. Das ist ja auch ein super Produkt. NetApp hat ja auch die Möglichkeit uns LUNs zur Verfügung zu stellen. Das wird keine Probleme geben.

Nur das geile ist ja, es gibt Mitarbeiter die hören das und denken... das ist Die Lösung! Das was wir haben ist scheisse... na ja das kennt Ihr sicherlich.

Gruß
Azrael

[bla!zilla]

Was für Systeme virtualisiert ihr denn hinter den NetApps? Auch wieder Filer oder andere Systeme? Also wenn mir ein Hersteller FCoE oder gar IP über FC vorschlägt, dann bringe ich ihn maximal noch freundlich zur Tür, aber dessen Produkte werde ich bestimmt nicht einsetzen.

[Azrael]

Die Storage Abteilung von uns hat direkt mit NetApp gesprochen. Die haben das eingeführt um ihre SAP System zu verwalten. Die Abteilung übernimmt somit unser HP EVA SAN und will das mit NetApp zu ihren bereits vorhandenen Storage hinzufügen.

Wir wollten uns nur einmal Persönlich informieren um bei dem Thema mitzusprechen.

Wir haben um es genau zu sagen mit einer Firma gesprochen die mit NetApp arbeitet und uns Möglichkeiten bezüglich Backup /Recover gezeigt.

Bei den Gesprächen haben die uns nur vorgeschlagen das zu benutzen. Wir haben uns das angehört aber mehr auch nicht.

Welche Systeme sich nun genau hinter NetApp sind weiß ich leider nicht.

Für mich ist es nur wichtig, dass ich meine LUNs bekomme

Gruß
Azrael

[bla!zilla]

Eine EVA hinter einem Filer???

*schrei*

Sorry, aber mit einer hintergeschalteten EVA ist der Filer definitiv overchicked.

[mullfreak]

Wahnsinn, was es alles gibt!

[Azrael]

Hallo,

Sorry das ich net so schnell Antworten konnte.

Hab mich falsch ausgedrückt. Die Leute von der Storage Abteilung wollen nur die Platten mehr net. ^^


Gruß
Azrael

[irix]

Hallo,

Sorry das ich net so schnell Antworten konnte.

Hab mich falsch ausgedrückt. Die Leute von der Storage Abteilung wollen nur die Platten mehr net. ^^

Und dann steht die EVA nackt da? Na bei euch gehts ja komisch zu

Nochmal zum Thema zurueck. Da bei Netapp ja alle Zauberrei per Software gemacht wird kann es je nach gekaufter Lizenz schon "Sinn" machen NFS zubenutzen. Hier hat das Storage mehr Einfluss da es das FS direkt beeinflussen kann. Kenne sogar Kunden welche das CIFS benutzen und es in die VMs einbinden.

Euch allerdings nun einen IP basierten Storage vorzuschlagen wo ihr eine FC Infrastruktur habt ist irgendwie "mutig". Wobei ich auch nicht glaube das die schon 10GbE im Auge hatten. Anzunehmen das Sie euch einfach nur gezeigt haben was es so gibt im Portfolio.

Bei Storagevirtualisierung muss ich allerdings zuerst an Datacore denken und nicht an Netapp.

Gruss
Joerg

[bla!zilla]

Ich finde es halt merkwürdig, ein Storage, welches eh schon vollvirtualisiert arbeitet noch mal zu virtualisieren. Das ist irgendwie doppelt gemoppelt. Es mag ja durchaus Systeme geben wo das Sinn macht (CLARiiONs fallen mir spontant ein oder auch MSAs oder kleinere Systeme), aber bei einer EVA... hinter einem Filer? Neee, macht gar keinen Sinn, auch nicht administrativ. Aber wenn es eine politische Entscheidung von oben war... da macht man nix.

@ Irix

Jap. Bei Storagevirtualisierung habe ich auch eher DataCore auf dem Schirm, je nach größe auch XPs/ TagmaStores.

[mronge]

Hallo Azrael,
leider sind die Antworten hier ziemlich eindimensional. In Bezug auf Performance ist bei Fibre Channel nicht allein die Bandbreite entscheidend - genau wie im Ethernet. Wichtig sind auch Fragen wie Paketgröße und Latenzzeiten.
Gerade VMware verursacht extrem viele kleine Pakete. Dabei spielen Latenzeiten eine viel größere Rolle als die Übertragungsrate. Platt ausgedrückt: Wenn ich 100 MB als einen Block übertrage, kann ich bei 100 MBit/s schneller sein als mit GbE und 100 MB in Portionen von jeweils 1 kB.
Ein relativ guter Artikel dazu ist unter http://storagefoo.blogspot.com/2007/09/ ... r-nfs.html zu finden.

Neben der reinen Performance gibt es noch weitere Gründe, über NFS nachzudenken. Ich betreibe eine Farm mit derzeit ca. 150 VMs. Je nach Anzahl der VMs auf einer LUN gibt es Probleme mit SCSI Reservations. Wenn dazu noch eine HP-UX-Maschine tausende von Trespasses auf einer emc CLARiiON macht, führt das in der Summe zu einem Stillstand der ESX-Farm. Es hat drei Tage gedauert, die VMs wieder betriebsbereit zu bekommen, weil das Problem so schwer zu finden war. Um solche Fehler grundsätzlich auszuschließen, wurden die VMs dann von der CLARiiON mit Aktiv/Passiv-Controller auf eine HP-EVA mit Aktiv/Aktiv-Controller umgezogen. Die Kosten stiegen dementsprechend.

Bei diesem Problem, aber auch bei einer anderen Situation, als ein zentrale Router ausfiel, und die ESX-Server mit Log-Dateien die VMFS-Volumes vollschrieben, gab es noch ein Phänomen: Unter bestimmten Umständen kann es vorkommen, dass wenn mehrere ESX-Server gleichzeitig auf eine LUN zugreifen, sie sich Dateien überschreiben. Solange das nur .log-Dateien sind, ist das unproblematisch. Aber wehe, es handelt sich um die .vmx-Datei (die beim Herunterfahren und Starten einer VM jedes mal neu geschrieben wird). Die Wiederherstellung ist grauenvoll.

Es gibt noch einen weiteren Grund für NFS. Bei SCSI kommt es zu einem SCSI-Timeout, wenn eine bestimmte Zeitlang die Platten nicht erreichbar sind. Das bedeutet Datenverlust im Betriebssystem der VM, und damit korrupte Datenbestände. NFS wartet einfach so lange, bis die Volumes wieder da sind. Solange also der ESX-Server nicht gleichzeitig gebootet sind, ist Datenverlust durch Zugriffsprobleme nahezu ausgeschlossen.

Ich werde, wenn unsere NetApp geliefert wird, NFS auf jeden Fall mal ausprobieren - unter anderen auch, weil ich dort abgesehen von der deutlich schnelleren Datensicherung das Volume im laufenden Betrieb vergrößern und verkleinern kann, was bei VMFS nur sehr eingeschränkt geht.
Viele Grüße
Michael

[kastlr]

Hallo zusammen,

das wird hier ja immer mehr zur Glaubensfrage.

In den allermeisten Fällen wird das verwendete Storage Array (FC oder NFS) im normalen Bereich betrieben, was Utilisation und Performance angeht.
Somit stellt sich die Frage nach Performance und Utilisation eher selten, es geht eher um Features und Verfügbarkeit.

Da sowohl NFS, SCSI als auch FC seit Jahren etablierte Standards und in Rechenzentren allgegenwärtig sind, haben Sie ihre Zuverlässigkeit hinreichend nachgewiesen.
Selbstverständlich gibt es immer mal Probleme und zwar unäbhängig vom verwendeten Protokol.
Wenn ein Host tausende Trespass (Umschalten einer/mehrere LUN's vom activen auf den passiven Storageprozessor) initiert, kann man das kaum als Regelbetrieb verstehen.
Ich bin mir sicher, das ESX Server mit NFS äußerst empfindlich reagieren würden, wenn ein Host tausenden von IP Collisions im selben VLAN/LAN Segment verursachen würde.

Hierbei handelt es sich nicht um ein Problem des Protokolls, sondern um eine Störung, die analysiert und behoben werden muß.

Das Thema SCSI Reservierungen wird eindeutig überbewertet, da es nur unter bestimmten Bedingungen zum Einsatz von SCSI Reservierungen kommt.
Allerdings gibt es durch aus Umgebungen, wo das zum negativen Effekten führen kann.

Doch auch hier ist fast immer das Design schlecht gewählt und/oder bei der Verteilung der VM's unsauber gearbeitet worden.
Zu diesem Thema gibt es übrigens einen sehr guten Blog.
VMFS – Best Practices, and counter-FUD

Zum Thema SCSI-Timeout nur eine Anmerkung.
Ein TimeOut bedeutet kein Datenverlust, schließlich gilt ein IO erst als geschrieben, wenn der Host ein ACK erhält.
Erhält der Host diese ACk nicht innerhalb des eingestellten SCSI Timeout Zeitraumes, schickt er es einfach erneut.
Außerdem muß hier die Frage erlaubt sein, in welcher Umgebung die Platten längere Zeit nicht verfügbar sein können, ohne das dies Grund zur Besorgnis ist.

Der Datenverlust entsteht, weil das OS/ die Applikation einfach nicht so lange auf austehende IO's warten kann und sich dann verabschiedet.
Somit trifft das auf alle Protokolle zu.

Ich kann euch nur dringend folgenden Artikel empfehlen, in dem EMC und NetApp sich zum Thema NFS äußern.
A "Multivendor Post" to help our mutual NFS customers using VMware.

Bin gespannt wie's weitergeht.

Gruß
Ralf

[bla!zilla]

leider sind die Antworten hier ziemlich eindimensional. In Bezug auf Performance ist bei Fibre Channel nicht allein die Bandbreite entscheidend - genau wie im Ethernet. Wichtig sind auch Fragen wie Paketgröße und Latenzzeiten.

Jeder Fibre-Channel Frame hat genau 2112 Byte. Ein TCP/IP Paket, wie es von NFS genutzt wird, kann 1460 Bytes verpacken. Fibre-Channel hat garantiert Bandbreiten, bei NFS muss ich nachhelfen. Egal wie ich es drehe und wende: Bei gleicher Anzahl Platten wird FC schneller sein. Klar, wenn ich nur 10MB/s fordere, dann liefern beide das. Aber welche Applikation macht das schon. Es ist die Frage ob ich auf die durchschnittliche Übertragungsrate optimiere, oder auf Peakleistung.

[Tschoergez]

Hi Leute!

Super Diskussion !

Wir diskutieren hier ja "nur" über das Protokoll zwischen ESX und Storage, das sind natürlich nur ein Glied in der langen Kette. Relevant ist das überhaupt nur, wenn die VMs erstmal so viel IO-Last erzeugen, klar. Und dann spielen die Physik auf dem Array natürlich auch noch ne Rolle. Darum:

Eine Frage noch an die Experten:
Wie viele Spindeln brauchts denn Eurer Erfahrung nach, um die genannten Bandbreiten und Latenzen überhaupt zu liefern?

(Bei nem RAID6 über 4 Platten wage ich zu behaupten, jede Diskussion über Vor- und Nachteile der jeweiligen Protokolle sind wohl ziemlich sinnlos )

Was sind da Eure Erfahrungen?


Viele Grüße,
Jörg

[bla!zilla]

Einen 4 GB FC Link mache ich dir recht leicht voll. Dazu brauche ich lediglich

- ca. 50 Platten (10k)
- 64k IOs
- RAID 5
- sequential Read

Bei RAID 0 wird es noch leichter. Das könnte ich also z.B. bei einem Backup hinbekommen. Ist es random, und die IOs bewegen sich eher zwischen 8 und 16 KB, dann brauche ich natürlich mehr Platten. Aber auf der anderen Seite: 4 GB FC heißt umgerechnet ca. 390 MB/s! Dafür brauchst du schon 10 GbE und NFS. Und dann will ich nicht die CPU Last auf der Kiste sehen...

RAID 6 macht nie Spaß. Sowas nimmt man NUR (und ausschließlich) bei vielen SATA/ FATA Platten und sequentiellen IOs. Bei Archiven z.B. Bei allem anderen macht RAID 6 gar keinen Spaß.