iSCSI, SAS oder FC für Exchange/MS SQL on ESX?

[webvirgin]

Hallo Leute

Das Umfeld:
- 1 IBM x236 (1x Xeon 3,2GHz/4GB/5x300GB SCSI 10K RAID 5)
- Small Business Server 2003 Premium
- GigaBit LAN
- 15 Mitarbeiter
- CRM/ERP Software auf MS SQL (ca. 19GB), je Benutzer ca. 3-6 Fenster offen
- Exchange 2003 SP3 mit etwa. 45GB Datenbank
- 100GB Daten

Planung:
2x Server (Ausfallsicherheit)
1x Direct Attached Storage (SAS RAID 6) mit Dual Controller -> hier stehe ich nun vor der Frage:

Welche Anbindung - vom Aspekt der Geschwindigkeit bzw. I/O - ist zum Host sinnvoll bzw. notwendig: iSCSI, SAS oder gleich FC?

Anbei ein IOMeter Testergebnis des derzeit vorhandenen Systems:




Danke + Grüße

[echt_weg]

bedeutet auf dem einen physikalischem server laufen all diese dienste? sql, exchange, fileserver usw?

wenn du virtualisierst solltest du das auf jeden fall auf verschieden vms entzerren.

ansonsten würde da wohl iscsi langen, wenn du es richtig machst und expandieren können willst dann fc zumal nur da ein failover ordentlich funktioniert

[webvirgin]

bedeutet auf dem einen physikalischem server laufen all diese dienste? sql, exchange, fileserver usw?

Ja, läuft alles auf einer Maschine - Ist ein SBS 2003 Premium.

dann fc zumal nur da ein failover ordentlich funktioniert

Ein Server on, einer off. Stirbt der laufende Server, wird der andere hochgefahren.

[bla!zilla]

Da es sich um einen SBS handelt kann man die Dienste kaum sinnvoll entzerren. Ist bei der Nutzeranzahl aber auch nicht unbedingt notwendig.

Leute, vergesst RAID 6!!! Es gibt da ein paar "Marktbegleiter" die das für das Nonplusultra halten, aber wahrscheinlich auch nur deswegen, um haufenweise SATA Platten zu verwenden, der weil sie den Kunden glauben machen wollen "Höherer RAID Level = besser". RAID 6 ist nett, wenn ich viele SATA Platten einsetze und viel mehr lesen, als schreiben muss. Nun laufen auf dem Server aber Exchange und SQL. Und da ist RAID 6 tötlich.

iSCSI ist IMHO okay, bei Verwendung von iSCSI HBAs. Der Software-Initiator von VMware ist Müll. Daher lieber direkt richtige iSCSI HBAs verwenden. Wenn leistungsfähige Switches vorhanden sind, können diese genutzt werden, sonst bitte dafür dedizierte, performante Switches (keinen Kram von D-Link oder Netgear) einplanen.

[echt_weg]

ok wenn es ein sbs ist dann kann man natürlich nicht entzerren. schade weil ich von diesen einier macht alles nichts halte aber geht dann nicht anders. wenn tatsächlich manueller failover reicht dann iscsi

[mangold]

mal leicht offtopic: Ich bin ein Befürworter von FC und will auf keinen Fall iSCSI. Leider kenne ich mit iSCSI auch nicht wirklich aus. Gibt es irgendwo eine Liste von pros und cons über iSCSI, welche Funktionen auch mit iSCSI vorhanden sind, und welche nicht?

Eigentlich geht es mir darum mehr Argumente FÜR FibreChannel zu haben.

[MatZ]

argumente für FC:

- 4/8 gbit durchsatz am kabel versus 1gbit oder im bestfall 10GE
- große frames die extra für datenmengen ausgelegt sind (jumboframes kann ESX ja noch nicht)
- weniger overhead - schlankeres protokoll du schleppst den TCP und iSCSI header nicht mit dir rum
- frames werden gebuffert beim abschicken von den FC-switchen da bei einem fehler schickt der switch nochmal und nicht der host
- FC- switche haben (meiner meinung) weniger latenz
- LWL kabel sind mehr oder weniger standard dh gegenüber ethernet über kupfer galvanisch nicht beinflussbar
- FC lässt sich (meiner meinung) besser und effektiver verwalten zoning vs VLAN (VLANs hätten auch noch einen weiteren header)


das einzige was für iSCSI spricht (meine meinung):

brauch nicht zwingend eine neue infrastruktur (dann aber lahm)
brauch nicht nicht zwingend HBAs (dann aber...lahm)
storrage kann ein normales system (PC/server) sein mit speicher und ist relativ schnell aufgesetzt (lahm)

auch spricht nicht soviel mehr für iSCSI im gegensatz zu NFS aber wir habens hier bei uns dennoch im einsatz mit einer AIO600 und einem opensolaris...es tut aber es fliegt nicht wirklich und neigt dazu instabil zu sein - soweit meine erfahrung...wenn mans aber gut aufsetzt und von anfang an alles dediziert auslegt und getrennte switches, HBAs hat und evtl 10GE ist es recht brauchbar

ich bin auch immer für FC aber wenn man recyclen muss und nicht viel budget hat muss man halt auf vorhandenes zurückgreifen, ein netzwerk und server hat ja jeder denke ich mal

[mangold]

argumente für FC:

- 4/8 gbit durchsatz am kabel versus 1gbit oder im bestfall 10GE
- große frames die extra für datenmengen ausgelegt sind (jumboframes kann ESX ja noch nicht)
- weniger overhead - schlankeres protokoll du schleppst den TCP und iSCSI header nicht mit dir rum
- frames werden gebuffert beim abschicken von den FC-switchen da bei einem fehler schickt der switch nochmal und nicht der host
- FC- switche haben (meiner meinung) weniger latenz
- LWL kabel sind mehr oder weniger standard dh gegenüber ethernet über kupfer galvanisch nicht beinflussbar
- FC lässt sich (meiner meinung) besser und effektiver verwalten zoning vs VLAN (VLANs hätten auch noch einen weiteren header)


das einzige was für iSCSI spricht (meine meinung):

brauch nicht zwingend eine neue infrastruktur (dann aber lahm)
brauch nicht nicht zwingend HBAs (dann aber...lahm)
storrage kann ein normales system (PC/server) sein mit speicher und ist relativ schnell aufgesetzt (lahm)

auch spricht nicht soviel mehr für iSCSI im gegensatz zu NFS aber wir habens hier bei uns dennoch im einsatz mit einer AIO600 und einem opensolaris...es tut aber es fliegt nicht wirklich und neigt dazu instabil zu sein - soweit meine erfahrung...wenn mans aber gut aufsetzt und von anfang an alles dediziert auslegt und getrennte switches, HBAs hat und evtl 10GE ist es recht brauchbar

ich bin auch immer für FC aber wenn man recyclen muss und nicht viel budget hat muss man halt auf vorhandenes zurückgreifen, ein netzwerk und server hat ja jeder denke ich mal

danke für deine Auflistung. Ich denke auch fürs Recyclen ist das ok, aber ich geh jetzt mal von einer neuen sauberen Installation. Das Problem ist, das Netzwerker gerne mal anfangen über SAN zu meckern und sagen, Cisco hat das alles und viel besser (10GBit) und wir haben ja schon LAN und wir managen wir das schon und FC ist wieder was neues und und und. Ich sehe das von der VM Seite und will das Beste in diesem Sektor. Jumbo Frames sind da schon ein Argument, Lichtwelle ist im RZ-Netzwerk auch schon Pflicht und "schlankeres Protokoll" plus "weniger Overhead" zieht bei Netzwerkern ohne Fakten auch schlecht.

VLANs vs. Zoning ist leider auch ein "weiches" Argument, VLANs werde ja auch schon eingesetzt und sind Standard.

Nicht funktionierendes Failover wäre schon ein sehr gutes Argument pro FC.

Am schönsten wäre eine Analyse mit Benchmarks LAN vs. FC im VMware Umfeld.

MEIN wichtigstes Argument, FC kontrolliere ich selbst, iSCSI müsste ich an die Netzwerkabteilung abgeben.

[webvirgin]

Herzlichen Dank für Eure sehr hilfreichen Antworten!

Hat vielleicht noch jemand Inputs bezüglich einer SAS Hostanbindung?
Ich denke da an Geräte wie zB. IBM DS3200 oder Promise VTrak E310s.

Soweit ich herausgefunden habe, ist die DS3200 VMWare zertifiziert, die E310s nicht.

Bei der Hardware Compatibility finde ich sehr viele iSCSI Storages, jedoch nur eine Handvoll SAS Storages. Hat das einen besonderen Grund?

LG
wv

[PeterDA]

Hi,
ich glaube du verwechslest hier etwas:

iSCSI Storages werden meistens mit den 3 Optionen SATA, SAS und FC angeboten!
Das was du als SAS Storage bezeichnest sind wohl "Direct Attached Storage" DAS als Storages die direkt am Server hängen man könnte auch sagen nichts anderes als den internen Festplattenspeicher in eine externe Box gepackt.
Diese DAS sind für VMware nicht so interessant, da viele von uns Vmotion nutzen wollen, gerade dann wenn es um große Umgebungen geht und das geht mit DAS Storage nicht.

Gruß Peter

[Tschoergez]

Hi!

Bzgl iSCSI schaut doch mal in den sticky post mit den Links. Da gibts einen recht ausführlichen Link zum Thema iSCSI.

Woher habt Ihr die Info, dass der Software Initiator von VMware so schlecht bzw. langsam ist?

Hat jemand die Möglichkeit, das auf nem echten ESX mal durchzutesten?

(Ich hab da nämlich meine Zweifel, aber eben leider (noch) keine harten Daten....

Viele Grüße,
Jörg

[webvirgin]

@mangold

Wäre so gesehen SAS dann die goldene Mitte?:
Schneller als iSCSI und günstiger als FC, aber fast so schnell (4Gbps vs 3 Gbps per port)?

Hi,
ich glaube du verwechslest hier etwas:

iSCSI Storages werden meistens mit den 3 Optionen SATA, SAS und FC angeboten!

Ich denke nicht, denn Du sprichst hier von der internen Anbindung (SATA, SAS oder FC HDDs).
Ich spreche hier aber von der externen Anbindung, welche sich durch iSCSI, FC und SAS unterscheidet - sprich: die Anbindung zum Host via iSCSI, FC oder SAS:
iSCSI via LAN Verkabelung
SAS via SAS Kabel zum Host HBA
FC via FC Kabel zum Host HBA

Das was du als SAS Storage bezeichnest sind wohl "Direct Attached Storage" DAS als Storages die direkt am Server hängen man könnte auch sagen nichts anderes als den internen Festplattenspeicher in eine externe Box gepackt.

Somit wären dann alle Storages, welches nicht via iSCSI zum Host angebunden werden als DAS zu bezeichnen...

Diese DAS sind für VMware nicht so interessant, da viele von uns Vmotion nutzen wollen, gerade dann wenn es um große Umgebungen geht und das geht mit DAS Storage nicht.

Soll heißen: will ich vMotion komme ich um iSCSI nicht herum?
Will ich Geschwindigkeit und I/O und kann auf vMotion verzichten, komme ich um FC nicht herum?
Wo bleibt da SAS? Mittendrin?

LG
wv

[irix]

Soll heißen: will ich vMotion komme ich um iSCSI nicht herum.

Das ist so nicht richtig.
Wer vMotion will der braucht shared Storage aka SAN. Das kann iSCSI, FC in einer Fabric oder evlt. auch NFS sein. Wobei ich nicht weis ob vMotion auf NFS supportet ist.

Gruss
Joerg

[Tschoergez]

jupp, VMotion, HA DRS usw. gehen auch mit NFS und ist auch supported.

Und ja, es gibt auch entsprechende Storage Systeme, die via NFS sehr perfomrant angesprochen werden können und es gibt Kunden, die fast hundert VMs auf einem NFS-Share betreiben ohne Probleme.

Für die hier gestellten Anforderungen macht DAS wohl keinen Sinn, weil eben nicht erweiterbar ist, und nur einer der beiden Server das Shelf nutzen könnte. Da macht ein kleines, aber gut erweiterbares Storage System mehr Sinn.

Evtl. kann auch Lefthand ne interesannte Lösung sein...

Viele Grüße,
Jörg

[webvirgin]

Wir werden uns für eine Promise vtrak E310F Dual entscheiden.
Diese wird via FC zum Host HBA angebunden und unterstützt - für ev. späteren Bedarf - auch vmotion.

Danke für Eure Unterstützung.

LG
wv

[Tschoergez]

was bisher noch nicht erwähnt wurde glaub ich:
auf jeden Fall muss das Storage System natürlich von VMware supported werden, also da genau die Compatibility Guides lesen.

grüße,
jörg

[MatZ]

SAS ist clusterfähig, SCSI auch zwar nicht ohne entsprechende storrages machbar aber es geht definitiv (siehe zb HP MSA500)...es ist zwar nicht schön aber es funktioniert, mit SAS kann man durchaus topologien aufbauen...

ein SAS beispiel ist zb der smartarray p700 plus SAS-switch für die c-class mit dem man auf einfache sb40c intern sowie extern auch zugrifen kann, auch shared!

SAS und SCSI storrages sind also durchaus fähig ein shared laufwerk anzubieten

[irix]

SAS ist clusterfähig, SCSI auch zwar nicht ohne entsprechende storrages machbar aber es geht definitiv (siehe zb HP MSA500)...es ist zwar nicht schön aber es funktioniert, mit SAS kann man durchaus topologien aufbauen...

ein SAS beispiel ist zb der smartarray p700 plus SAS-switch für die c-class mit dem man auf einfache sb40c intern sowie extern auch zugrifen kann, auch shared!

SAS und SCSI storrages sind also durchaus fähig ein shared laufwerk anzubieten

Jetzt wo du es sagst.... mir sind neulich SAS Switche untergekommen in einem Bericht. Die Frage natuerlich immer wie es mit VMWare Support aussieht.

Gruss
Joerg