Performance mit NAS-Filern

[GTMK]

Schönen guten Abend,

momentan läuft meine virtuelle Umgebung in einem 2 Gbit-FC-SAN mit teilweise schon etwas älterer IBM-Hardware (DS4300). Da also in nächster Zukunft (auch in anderen Bereichen) einige Gerätschaften ersetzt werden müssen, ziehen wir momentan auch die Anschaffung eines NAS-Filers in Betracht, der dann auch die VI- (bzw. demnächst vSphere-) Umgebung bedienen müsste. Zumindest Teile der Umgebung sollten dann auch gespiegelt werden, wobei der Spiegel in einem anderen Brandabschnitt steht.

Der Storage müsste also per NFS an die VI angebunden werden. Was das ganze Infrastrukturgeraffel angeht, habe ich weniger Bedenken; Bauchschmerzen bekomme ich aber (wenn auch zunächst nur rein gefühlsmäßig) dabei, IOps-intensive Anwendungen wie die virtualisierten Exchange und SQL-Server auf diese Weise anzubinden.

Wie sind hier die Erfahrungen in diesem Umfeld mit NFS-Anbindung des Storage? Ich war bislang auf Präsentationen von Isilon, Dell/EMC (Celerra) und IBM (SoFS - wird noch nicht von VMware unterstützt, soll aber). Bei EMC und IBM könnten wohl auch LUNs am Filer vorbei per SAN an die ESXe herausgereicht werden, bei IBM aber nur mit den teuren 5er und 8er Serien (von EMC habe ich da momentan keine Informationen).

In der Diskussion ist alternativ auch eine SAN-Lösung mit DataCore, wobei ich aber sagen muss, dass ich grundsätzlich eine Tendenz zu größeren Herstellern habe (das betrifft auch Isilon), weil ich mit kleineren auch schon mal auf die Nase gefallen bin, weil keine Firmware-Updates mehr kamen...

Kommentare?

Viele Grüße, Georg.

[mangold]

Datacore ist ja nun auch nicht neu, gibt es seit 1998. Ausserdem - wenn du von Sanmelody oder SANsymphony sprichst - ist das ja eine Hardware unabhängige Lösung, also egal welches physische SAN du da hinter packst.

EMC finde ich derzeit interessant, weil sie in Zukunft Powerpath in vSphere integrieren wollen, aber das sind noch alles ungelegte Eier.

Bei IO intensiven Anwendungen hätte ich mit Filern so grundsätzlich auch Bauchschmerzen ohne das wirklich mir Zahlen begründen zu können.

[Tschoergez]

Hm, bei NFS-Speicher für VMware ist z.Z wohl Netapp ziemlich vorne. Da gibts etliche Referenzumgebungen auch mit io-intensiven VMs.
Allerdings brauchts auch dazu natürlich die entsprechenden Spindeln dahinter, wirklich billiger als ein SAN ist das dann nicht.

Und (egal ob iSCSI oder NFS): Das Netzwerk sollte auf jeden Fall die Last aushalten, je nachdem empfiehlt sich sogar der Aufbau eines zweiten, physikalisch getrennten Storage-Netzwerkes (auch da ist dann natürlich wieder nicht viel um zu FC-SAN).

Was sind denn für Euch die Argumente für NFS anstatt block-based SAN?

Viele Grüße,
Jörg
PS.: Ich find gut, dass Ihr das überhaupt diskutiert! Meistens gibts in Unternehmen mit einer etablierten FC-SAN-Fraktion kaum verfünftige Diskussionen um Alternativen

[bla!zilla]

Einziger Vorteil von NFS gegenüber iSCSI oder FC: Keine SCSI Reservations. Bei der Performance kann NFS oder iSCSI nicht viel gegen FC machen. Da stehen 98,5% nutzbare Bandbreite gegenüber rund 50% bis 60%.

[mangold]

PS.: Ich find gut, dass Ihr das überhaupt diskutiert! Meistens gibts in Unternehmen mit einer etablierten FC-SAN-Fraktion kaum verfünftige Diskussionen um Alternativen

ja wie bei uns, weil sich leider die Netzwerker in den Storage Bereich einmischen und meinen mal eben schnell ein Storage Netzwerk neben dem normalen Netzwerk zu administrieren aber natürlich NUR mit Cisco und der eigentlich Storage Admin (nämlich ich) soll in Zukunft nicht mehr administrieren. Um solchen Diskussionen und Streitereien aus dem Wege zu gehen, werden Argumente pro FC gesucht und damit ist Ruhe.

[bla!zilla]

Für FC spricht das Protokoll einfach für sich. Ich habe iSCSI nur in recht kleinen Umgebungen, alles was ein wenig produktiver genutzt wird, basiert auf Fibre-Channel. SAN ist nun mal nicht Netzwerk und Ethernet und IP sind auch nicht wirklich darauf ausgelegt.

[Tschoergez]

NFS hat schon noch weitere Eigenschaften (ob das nun Vorteile sind, muss jeder selber wissen ): Die VMs sind standardmäßig Thin-provisioned, und man kommt auch von woanders an die Datastores hin, was sehr interessante Möglichkeiten für Backup und DR bietet.

Klar ist, dass IP mehr Overhead erzeugt, dafür gibts ja dann 10GbE (immer "günstiger" mit der Zeit )...

Aber da kann man natürlich ewig weiterdiskutieren....

Viele Grüße,
Jörg

[bla!zilla]

10 GbE bringt vielleicht 500 MB/s über die Leitung. 8 GB FC aber locker > 750 MB/s.

[GTMK]

Sorry, ich bin gerade erst wieder dazu gekommen, hier hereinzuschauen... schön, dass so viele Antworten gekommen sind...

Zur Frage, warum wir das diskutieren: Wir haben eine (gewachsene) extrem heterogene Umgebung. Unix/Linux/Solaris- und Windows-Fraktion marschieren getrennt, vor allem auch, was den Storage angeht. Ich betreue Windows und habe parallel dazu die VI hochgezogen (auf dem "Windows"-Storage); in der VI laufen auch einige Linux/Solaris-Server. Neuer Speicher wurde und wird üblicherweise "angeflascht", eine Lösung "aus einem Guss" haben wir nicht. Das ist es, was den Reiz der diskutierten Lösungen für mich ausmacht - die Möglichkeit, neuen Storage ohne etwa die Notwendigkeit zu Migrationen einbinden zu können und alten außer Betrieb zu nehmen. Es ist klar, dass das eine Menge Geld kostet und nur institutsweit zu realisieren ist.

Ich persönlich finde vor allem IBMs SoFS sehr attraktiv (leider noch nicht VMware-zertifziert) und hier eben das globale Filesystem und die HSM/TSM-Integration. Und dahinter den Support von IBM, und zwar dann für die komplette Lösung (das wäre etwa bei DataCore anders). Ja, und außerdem sagt man auch, dass noch niemand gefeuert worden ist, weil er bei IBM eingekauft hat...

Zum Thema Bandbreite: Bandbreite (in MB/s) ist für mich (Windows/VMware) eher kein Thema.

Über iSCSI müssen wir hier nicht diskutierten, die Frage lautet "Filer ja oder nein", und der muss dann auch VMware und vor allem Exchange (optimal wie bisher in einer VM) bedienen können.

Georg.