Dies ist eine kanonische Frage zu iSCSI, die wir als Referenz verwenden können.

iSCSI ist ein Protokoll, mit dem SCSI-Befehle als Nutzdaten in TCP-Netzwerkpakete eingefügt werden. Als solches ist es anderen Problemen ausgesetzt als beispielsweise Fibre Channel. Wenn beispielsweise eine Verbindung überlastet ist und die Puffer des Switch voll sind, löscht Ethernet standardmäßig Frames, anstatt dem Host mitzuteilen, dass er langsamer werden soll. Dies führt zu erneuten Übertragungen, was zu einer hohen Latenz für einen sehr kleinen Teil des Speicherverkehrs führt.

Abhängig vom Client-Betriebssystem gibt es Lösungen für dieses Problem, einschließlich der Änderung der Netzwerkeinstellungen. Wie würde eine optimale iSCSI-Client-Konfiguration für die folgende Liste von Betriebssystemen aussehen? Wäre es notwendig, die Einstellungen an den Schaltern zu ändern? Was ist mit der Lagerung?

• VMWare 4 und 5
• Windows Hyper-V 2008 und 2008r2
• Windows 2003 und 2008 auf Bare Metal
• Linux auf Bare Metal
• AIX VIO
• Jedes andere Betriebssystem, von dem Sie glauben, es sei relevant

Ich bin nicht mit VMWare vertraut, verwende jedoch Xenserver und habe Hyper-V (R2) verwendet.

Mit meiner aktuellen Xenserver-Konfiguration habe ich:

• 8 Dell Poweredge 29xx-Server
• 2 Dell Powerconnect 6248-Switches
• 2 Dell MD3000i SAN (iSCSI)

Ich habe meine Switches in einer Multipath-Konfiguration eingerichtet und für iSCSI optimiert durch:

• Aufteilen meiner Switches in 3 VLANs (2 für iSCSI-Datenverkehr und 1 für die Verwaltung)
• JumboFrames verwenden
• Anwenden der "iSCSI" -Optimierungen, über die der Powerconnect verfügt

Jeder Server verfügt über mehrere Netzwerkkarten, die eine Verbindung zu jedem Switch herstellen. Dies sorgt für Redundanz über Multipathing zwischen den Servern und dem iSCSI-SAN. Die iSCSI-VLANs enthalten keinen anderen Datenverkehr als iSCSI.

Ich freue mich, Ihnen mitteilen zu können, dass mit dieser Konfiguration der Xenserver "Cluster" hervorragend funktioniert.

Nebenbei bemerkt habe ich einen Windows 2008-Server, der direkt über iSCSI mit einem HP SAN (alter Dateiserver) verbunden ist. Früher lief Windows 2003 und die Verbindung wurde regelmäßig getrennt (auch nach einer Neuinstallation von 2003). Sobald ich jedoch ein Upgrade auf Windows 2008 durchgeführt habe, bleibt die Verbindung bestehen.

Bei Fragen zu meinem Setup stehe ich Ihnen gerne zur Verfügung.

Dies ist noch keine Antwort. Dies ist der Rahmen für die generische Antwort. Wenn Sie Zeit haben, füllen Sie bitte alles aus, was Sie wissen. Wenn Sie bestimmte Hardware konfigurieren möchten, geben Sie für jeden Anbieter eine separate Antwort, damit diese Informationen organisiert und getrennt aufbewahrt werden können.

QoS-Profil für die Ports sowie Deaktivieren der Sturmkontrolle, Einrichten der MTU auf 9000, Aktivieren der Flusskontrolle und Einrichten der Ports in portfast

Durchsatz und Latenz

Aktualisierte Firmware, Treiber und andere Systeme

MPIO

Jumbo Frames / MTU

Mit zunehmender Geschwindigkeit der Netzwerkverbindungen steigt auch die Anzahl der potenziell generierten Pakete. Dies führt zu immer mehr CPU / Interrupt-Zeit, die für die Erzeugung von Paketen aufgewendet wird, was sowohl eine übermäßige Belastung des Übertragungssystems als auch eine übermäßige Inanspruchnahme der Verbindungsbandbreite durch Framing zur Folge hat.

Sogenannte "Jumbo" -Frames sind Ethernet-Frames, die die kanonische Grenze von 1518 Byte überschreiten. Während die Anzahl je nach Switch-Anbieter, Betriebssystem und Netzwerkkarte variieren kann, liegen die typischen Jumbo-Paketgrößen bei 9000 und 9216 Byte (wobei letztere am häufigsten vorkommen). Angesichts der Tatsache, dass ungefähr das 6-fache der Daten in einen 9-KB-Frame gepackt werden kann, wird die Anzahl der tatsächlichen Pakete (und Interrupts) auf dem Host um einen ähnlichen Betrag verringert. Diese Zuwächse sind insbesondere bei Verbindungen mit höherer Geschwindigkeit (z. B. 10GE) zu verzeichnen, die große Datenmengen senden (z. B. iSCSI).

Die Aktivierung von Jumbo-Frames erfordert die Konfiguration sowohl des Hosts als auch des Ethernet-Switches. Vor der Implementierung ist besondere Vorsicht geboten. Mehrere Richtlinien sollten befolgt werden -

1.) Innerhalb eines bestimmten Ethernet-Segments (VLAN) sollten alle Hosts und Router dieselbe MTU konfiguriert haben. Ein Gerät ohne ordnungsgemäße Konfiguration erkennt größere Frames als Verbindungsfehler (insbesondere "Riesen") und löscht sie.

2.) Innerhalb des IP-Protokolls benötigen zwei Hosts mit unterschiedlichen Rahmengrößen einen Mechanismus, um eine geeignete gemeinsame Rahmengröße auszuhandeln. Für TCP ist dies die Pfad-MTU (PMTU) -Erkennung und basiert auf der Übertragung von ICMP-nicht erreichbaren Paketen. Stellen Sie sicher, dass PMTU auf allen Systemen aktiviert ist und dass alle ACLs oder Firewall-Regeln diese Pakete zulassen.

Ethernet-Flusskontrolle (802.3x)

Trotz einiger iSCSI Hersteller empfohlen wird, einfach 802.3x Ethernet - Flusssteuerung sollte nicht in den meisten Umgebungen aktiviert werden , wenn alle Switch - Ports, NICs und Links sind völlig gewidmet iSCSI - Datenverkehr und sonst nichts. Wenn auf den Verbindungen anderer Datenverkehr vorhanden ist (z. B. SMB- oder NFS-Dateifreigabe, Heartbeats für Clusterspeicher oder VMware, Steuerung / Überwachung des Datenverkehrs durch NIC-Teams usw.), sollte die einfache 802.3x-Flusssteuerung nicht verwendet werden, da sie ganze Ports blockiert und anderer Nicht-iSCSI-Datenverkehr wird ebenfalls blockiert. Die Leistungssteigerungen von Ethernet Flow Control sind häufig minimal oder nicht vorhanden. Ein realistisches Benchmarking sollte für die gesamte Kombination aus Betriebssystem, Netzwerkkarte, Switch und Speicher durchgeführt werden, um festzustellen, ob tatsächlich ein Nutzen vorliegt.

Die eigentliche Frage aus Sicht des Servers lautet: Beende ich den Netzwerkverkehr, wenn meine Netzwerkkarte oder mein Netzwerk überlastet ist, oder beginne ich mit dem Verwerfen und erneuten Senden von Paketen? Wenn Sie die Flusskontrolle einschalten, können die Puffer der Netzwerkkarte auf der Empfängerseite geleert werden, die Puffer auf der Senderseite werden jedoch überlastet (normalerweise puffert ein Netzwerkgerät hier).

TCP-Überlastungskontrolle (RFC 5681)

TOE (TCP / IP-Offload-Engines)

iSOE (iSCSI-Offload-Engines)

LSO (TCP-Segmentierung / Large Send Offload)

Netzwerkisolation

Eine gängige Best Practice für iSCSI besteht darin, Initiatoren und Ziele von anderem Netzwerkverkehr zu isolieren, der kein Speicher ist. Dies bietet Vorteile in Bezug auf Sicherheit, Verwaltbarkeit und in vielen Fällen die Bereitstellung von Ressourcen für den Speicherverkehr. Diese Isolierung kann verschiedene Formen annehmen:

1.) Physikalische Isolation - Alle Initiatoren verfügen über eine oder mehrere NICs, die ausschließlich für den iSCSI-Verkehr bestimmt sind. Dies kann - abhängig von den Fähigkeiten der betreffenden Hardware und den spezifischen Sicherheits- und Betriebsanforderungen innerhalb einer bestimmten Organisation - eine dedizierte Netzwerkhardware bedeuten oder auch nicht.

2.) Logische Isolation - Die meisten Initiatoren, die in schnelleren (dh 10GE) Netzwerken anzutreffen sind, verfügen über ein VLAN-Tagging (siehe 802.1q), das zum Trennen von Speicher- und Nicht-Speicher-Verkehr konfiguriert ist.

In vielen Organisationen werden zusätzliche Mechanismen eingesetzt, um sicherzustellen, dass iSCSI-Initiatoren über diese dedizierten Netzwerke nicht miteinander in Kontakt treten können und diese dedizierten Netzwerke nicht über Standard-Datennetze erreichbar sind. Zu diesen Maßnahmen gehören Standardzugriffskontrolllisten, private VLANs und Firewalls.

Auch hier geht es um Backplane und Switching Fabric.

QoS (802.1p)

vLAN (802.1q)

STP (RSTP, MSTP usw.)

Verkehrsunterdrückung (Storm Control, Multi / Broadcast Control)

Sicherheit

Authentifizierung und Sicherheit

KERL

IPSec

LUN-Zuordnung (Best Practices)

Einige Überlegungen und Recherchen sollten Sie subjektiv in Bezug auf Folgendes anstellen:

1) Multi-Pathing - Für Ihre SAN-Lösung und Ihr Betriebssystem, sei es Hypervisor oder Bare-Metal-Betriebssystem, ist möglicherweise herstellerspezifische Software erforderlich, damit dies ordnungsgemäß funktioniert.

2) Initiatoren - Sie müssen überprüfen, ob der Software-Initiator den Anforderungen entsprechend ausreicht. Viele Netzwerkkarten verfügen über iSCSI-Offloading-Funktionen, mit denen sich der Durchsatz erheblich verbessern lässt. Es ist jedoch bekannt, dass bestimmte ältere Hypervisoren mit ihrer Unterstützung ziemlich pissig werden. Die ausgereifteren Angebote (ESXi 4.1+) scheinen sich gut zu platzieren.

3) Sicherheit / Berechtigungen - Stellen Sie sicher, dass Sie vollständig überprüfen, welche Initiatoren Zugriff auf welche LUNs benötigen. Sie werden einen schlechten Tag erleben, wenn ein Administrator auf einem Ihrer Windows-Computer einen "Initialisierungsdatenträger" auf einem Datenträger erstellt, auf dem dies der Fall ist wird von einem anderen Server tatsächlich als VMware-Datenspeicher verwendet.