Performance über iSCSI und NAS

[Vinc211 1]

Hallo,

 

Ich habe eine Storage mit fünf 2TB SAS Platten im Raid 5 und sieben 1TB Sas Platten im Raid 5 (historisch gewachsen)

Die Maschine hat 32Gb Ram, Intel Xeon 2630v3 und 4x Gbit LAN (Nic Teaming). Die Maschine soll mein Storage über iSCSI werden.

Als VM Server habe ich einen Server mit 2x Intel XEON X5650 128GB RAM (2Gbit Lan) und einen 2x Intel XEON X5650 96GB RAM (2Gbit Lan).

Auf dem Storage läuft Windows Storage Server 2012 R2 und die beiden VM Server sollen im Cluster laufen ebenfalls mit Windows Server 2012 R2

Als VM's habe ich einen Fileserver, CRM mit SQL Datenbank. Domaincontroller. Exchange Server, Intranet, WSUS., etc.

 

Ich mache mir sorgen um die Performance. Nicht der der Maschinen sondern um die IO's und generell um die iSSCI anbindung. FC ist leider keine option.

Eventuell könnten die VMServer auf mit 4Gbit angeschlossen werden.

 

Vielen Dank für Hilfe.

Mfg

[NilsK 2.934]

Moin,

 

2 Gigabitkarten sind auf jeden Fall zu wenig, wenn du einen Cluster bauen willst. Wenn du iSCSI machen willst, musst du noch mehr Karten einrechnen.

 

Entweder auf 10 GbE umsteigen (2 Karten) oder minimal sechs Karten für die Hosts (so kommst du mit je einem 4-Port-Adapter zusätzlich pro Host aus). Die dann idealerweise als Team und dann folgende vNICs für das Management OS:

• VM-LAN (keine vNICs für das Management OS, nur für die VMs)
• Cluster und Live Migration
• iSCSI
• Management

Die Bandbreitensteuerug auf "Weight" setzen. DefaultFlow auf 50 setzen. Für das Management 5, für den Cluster 5, für iSCSI 40. So hast du im Normalfall für die VMs die Hälfte der Bandbreite und für iSCSI auch. Nur wenn was anfällt, können sich Cluster und Management mehr nehmen, sie werden aber nie voll ausgebremst.

 

Wenn du ohne Teaming "über alles" arbeitest, dann auch minimal sechs Karten:

• 2 für VM-LAN (als Team)
• 2 für iSCSI (kein Team, sondern MPIO)
• 1 für Management und als Fallback für den Cluster
• 1 für Cluster und Live Migration

Gruß, Nils

bearbeitet 14. Juli 2016 von NilsK

[Doso 77]

Für iSCSI nutzt man kein NIC Teaming, man nutzt MPIO. Das iSCSI Target von Microsoft ist gefühlt recht lahm da es kein Caching kann. Für unseren Testcluster nutze ich seit Jahren StarWind Virtual SAN. Das kann Arbeitsspeicher als Cache nutzen und läuft dadurch geschmeidiger. Die kleine Version ist kostenlos.

[Vinc211 1]

Vielen Dank für die Antworten. Sehe ich das richtig das ich die MPIO nur auf den Host Servern aktivieren muss? Mein Storage wird weiterhin mit 4Gbit NIC Teaming betrieben?

Mit 6 Gbit Ports pro Host würde es dann so aussehen.

2x VM LAN (vlan x - Ip Range für Server) pro Server und in diesem vlan x ist auch das 4Gbit NIC Team vom Storage?

2x iSCSI MPIO (vlan y - IP Range iSCSI) pro Server

1x management (vlan z) pro Server

1x cluster (vlan z) pro Server

 

Das bezieht sich jetzt komplett auf die Windows Server 2012 R2 ebene und nicht auf die vSwitch Ebene. Ich hoffe wir reden da nicht aneinander vorbei.

bearbeitet 15. Juli 2016 von Vinc211

[magheinz 110]

Ich würde das Storage dann auch so konfigurieren das ich für jeden Pfad eine NIC habe.

Bei VMware geht das auch gar nicht anders. Wenn man mit dem SW-iSCSI arbeiten will dann dürfen die zugwiesenen vmks nur jeweils eine NIC haben. Auch keine zweite als Standby.

[Vinc211 1]

Nebenbei schaue ich mir grad entsprechende Netzwerkkarten mit 4 Ports an. Gibt es da empfehlungen?

Die Preise zwischen einer Intel PRO/1000 PT MT etc, 340 oder 350I-T4 und einer DELL Broadcom 5719 QP sind ja schon nicht unerheblich. Wahrscheinlich gibt es da unterschiede in den Features die unterstützt werden. Gibt es da etwas besonderes auf das man achten sollte

[Doso 77]

Hände weg von Broadcom NICs, da gibt es immer mal wieder Probleme mit Treibern und vmq.

[Vinc211 1]

Meine aktuelle Konfiguration auf Storage Seite sieht wie folgt aus:

8 NIC's =

2x Client Netz für Management (wird noch aufgelöst)

3x NIC Team Vlan X mit MPIO

3x NIC Team Vlan Y mit MPIO.

 

Host Seite:

6NIC's

2x NIC Team für Clients (Hyper V Virtual Switch)

1x MPIO Vlan Y

1x MPIO Vlan Z

1x Cluster Live MIgration

 

Es funktioniert meines erachtens ziemlich gut. Nur leider finde ich nichts über diese Methode NIC Teaming und MPIO zu kombinieren. Hier wären weitere Erfahrungswerte ganz interessant.

Das NIC Team habe ich gemacht da weitere Host Server das Storage ansprechen.

[NilsK 2.934]

Moin,

 

tendenziell würde ich in deinem Setup ein Team über vier der sechs Karten machen und dann mit vNICs im Management OS (= Host-Ebene) arbeiten. In deiner Konfig hast du nur eine Karte für Cluster und LM, was einen SPoF darstellen kann und die Geschwindigkeit begrenzt, wenn du einen Host mal per LM evakuieren willst.

 

Gruß, Nils

[Dunkelmann 96]

Moin,

 

man kann es wie Nils machen und 4 NICs zu einem Team mit einem vSwitch zusammenfassen und vNICs für die verschiedenen Funktionen im HostOS bereitstellen.

 

Ich tendiere bei so einem Szenario dazu zwei Teams á 2 NICs zu bilden. Ein Team mit vSwitch für die VMs und ein weiteres Team mit Teaminterfaces (ohne vSwitch/vNICs) für den Host.

[Vinc211 1]

Moin,

 

man kann es wie Nils machen und 4 NICs zu einem Team mit einem vSwitch zusammenfassen und vNICs für die verschiedenen Funktionen im HostOS bereitstellen.

 

Ich tendiere bei so einem Szenario dazu zwei Teams á 2 NICs zu bilden. Ein Team mit vSwitch für die VMs und ein weiteres Team mit Teaminterfaces (ohne vSwitch/vNICs) für den Host.

 

Ich kann dir leider nicht ganz folgen.

 

Ich weiß leider nicht wie gut vNIC's mitlerweile sind. Wie ich euch verstehe ist es die beste Lösung. Ich hätte jetzt gedacht das würde zuviel Overhead produzieren und eine weitere "Software" Abhängigkeit schaffen...?

bearbeitet 16. September 2016 von Vinc211

[Doso 77]

Ich habe das mit separaten NIC Teams gemacht weil mir das logischer erschien aber letztlich dürfte das wohl auf das selbe raus laufen. Letztlich bist du bei einer Virtualisierung immer total Software abhängig :)

[NilsK 2.934]

Moin,

 

Ich weiß leider nicht wie gut vNIC's mitlerweile sind.

 

wieso? Waren die mal schlecht?

 

 

Ich hätte jetzt gedacht das würde zuviel Overhead produzieren und eine weitere "Software" Abhängigkeit schaffen...?

 

Der "Overhead" ist zu vernachlässigen. Und Abhängigkeit von der Software hat man in jedem Fall. Der entscheidende Vorteil ist, dass man auf diese Weise die Detailkonfiguration per Software vornehmen und bei Bedarf auch im laufenden Betrieb ändern kann. Zudem würde "ein Team über alles" das Partitionierungsproblem vermeiden: Das Team hat (geeignete Datenströme vorausgesetzt, aber das ist bei Virtualisierung i.d.R. gegeben) eine rechnerische Bandbreite von viermal Gigabit, die man recht frei zwischen den verschiedenen Traffic-Arten aufteilen kann. Bewegt eines der "logischen" Netze keine Daten, dann ist auch die zugeordnete Bandbreite frei und kann von den anderen Netzen genutzt werden.

 

Würdest du hingegen einzelne Karten "physisch" für einen bestimmten Zweck zuweisen, dann liegen diese einfach brach, wenn kein Traffic darüber fließt. Ähnlich wie bei der Partitionierung einer Festplatte: Ist auf einer Partition Platz frei, dann nützt das der anderen Partition, die gerade vollläuft, nichts. Richtet man die Platte als eine große Partition ein, dann ist man da flexibler.

 

Gruß, Nils

[Dunkelmann 96]

Ich kann dir leider nicht ganz folgen.

 

Ich weiß leider nicht wie gut vNIC's mitlerweile sind. Wie ich euch verstehe ist es die beste Lösung. Ich hätte jetzt gedacht das würde zuviel Overhead produzieren und eine weitere "Software" Abhängigkeit schaffen...?

Seit Server 2012 sind die Themen Teaming, vSwitch und vNICs relativ gut abgebildet. Der Overhead ist bei aktuellen Netzwerkkarten in den meisten KMU Szenarien zu vernachlässigen.

Ein Teaminterface (Cisco-Sprech: Subinterface) ist ein virtuelles LAN Interface mit taged VLAN. Hier wird kein vSwitch und kein vNIC eingerichtet.

 

 

Würdest du hingegen einzelne Karten "physisch" für einen bestimmten Zweck zuweisen, dann liegen diese einfach brach, wenn kein Traffic darüber fließt.

Wird rein die Performance betrachtet, hast Du recht.

Beziehe ich auch Sicherheitsaspekte in die Planung ein, sind zwei Teams möglicherweise zu bevorzugen.

 

Das Deployment per PXE und/oder Management des Hyper-V Hosts finden häufig im native VLAN statt. Vielleicht ist es nicht erwünscht, dass VMs ebenfalls in dieses native VLAN gelangen (können).

Der vSwitch unter Hyper-V bildet nur einen Trunk zur physischen Infrastruktur und sollte nicht anders behandet werden als ein Trunk zwischen physischen Switches. "tagging the native VLAN" und "VLAN traversal" sind geeignete Suchbegriffe ;)

[magheinz 110]

Also bei diesem ganzen teaming würde ich noch mal die 10g-variante überdenken.

Minimal:

Dualportkarte für storage

Singleport in die zwei host.

2 dac-Kabel.

Minimale komplexität, maximale Performance.