Jump to content

Performance über iSCSI und NAS


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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

Link zu diesem Kommentar

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 von NilsK
Link zu diesem Kommentar

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 von Vinc211
Link zu diesem Kommentar

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

Link zu diesem Kommentar
  • 1 Monat später...

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.

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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 von Vinc211
Link zu diesem Kommentar

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

Link zu diesem Kommentar

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 ;)

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...