Richtige Platzierung von Geräten auf einem Fibre Channel-Fabric

10

Wir bekommen ein Paar neuer 8-Gbit-Switches für unser Fibre-Channel-Fabric. Dies ist eine gute Sache, da wir in unserem primären Rechenzentrum keine Ports mehr haben und mindestens eine 8-Gbit-ISL zwischen unseren beiden Rechenzentren ausgeführt werden kann.

Unsere beiden Rechenzentren sind etwa 3,2 km voneinander entfernt, während die Glasfaser läuft. Wir haben seit ein paar Jahren einen soliden 4-Gbit-Service und ich hoffe sehr, dass er auch 8 Gbit unterstützen kann.

Ich überlege gerade, wie wir unsere Fabric neu konfigurieren können, um diese neuen Switches zu akzeptieren. Aufgrund von Kostenentscheidungen vor einigen Jahren betreiben wir kein vollständig separates Double-Loop-Fabric. Die Kosten für die vollständige Redundanz wurden als teurer angesehen als die unwahrscheinlichen Ausfallzeiten eines Switch-Fehlers. Diese Entscheidung wurde vor meiner Zeit getroffen, und seitdem haben sich die Dinge nicht viel verbessert.

Ich möchte diese Gelegenheit nutzen, um unsere Fabric angesichts eines Switch-Fehlers (oder eines FabricOS-Upgrades) widerstandsfähiger zu machen.

Hier ist ein Diagramm dessen, was ich für ein Layout denke. Blaue Elemente sind neu, rote Elemente sind vorhandene Links, die (neu) verschoben werden.

FibreChannel-Digramm
(Quelle: sysadmin1138.net )

Die rote Pfeillinie ist die aktuelle ISL-Switch-Verbindung. Beide ISLs stammen von demselben Switch. Der EVA6100 ist derzeit an beide 16/4-Switches mit ISL angeschlossen. Mit den neuen Switches können wir zwei Switches im Remote-DC haben, von denen einige der ISLs mit großer Reichweite auf den neuen Switch umsteigen.

Dies hat den Vorteil, dass jeder Switch nicht mehr als 2 Hops von einem anderen Switch entfernt ist und die beiden EVA4400, die sich in einer EVA-Replikationsbeziehung befinden, 1 Hop voneinander entfernt sind. Der EVA6100 in der Tabelle ist ein älteres Gerät, das irgendwann ersetzt wird, wahrscheinlich durch einen weiteren EVA4400.

In der unteren Hälfte des Diagramms befinden sich die meisten unserer Server, und ich habe Bedenken hinsichtlich der genauen Platzierung. Was muss da reingehen:

  • 10 VMWare ESX4.1-Hosts
    • Zugriff auf Ressourcen des EVA6100
  • 4 Windows Server 2008-Server in einem One-Failover-Cluster (Dateiserver-Cluster)
    • Zugriff auf Ressourcen sowohl auf dem EVA6100 als auch auf dem Remote-EVA4400
  • 2 Windows Server 2008-Server in einem zweiten Failovercluster (Blackboard-Inhalt)
    • Zugriff auf Ressourcen des EVA6100
  • 2 MS-SQL-Datenbankserver
    • Zugriff auf Ressourcen auf dem EVA6100, wobei nächtliche DB-Exporte auf den EVA4400 gehen
  • 1 LTO4-Bandbibliothek mit 2 LTO4-Bandlaufwerken. Jedes Laufwerk erhält einen eigenen Glasfaseranschluss.
    • Die Sicherungsserver (nicht in dieser Liste enthalten) spoolen auf sie

Momentan kann der ESX-Cluster bis zu 3, möglicherweise 4 Hosts tolerieren, die ausfallen, bevor VMs aus Platzgründen heruntergefahren werden müssen. Glücklicherweise hat alles MPIO eingeschaltet.

Die aktuellen 4-Gbit-ISL-Links haben nicht die Sättigung erreicht, die ich bemerkt habe. Dies kann sich mit der Replikation der beiden EVA4400 ändern, aber mindestens eine der ISLs ist 8 GB groß. Wenn ich mir die Leistung von EVA4400-A anschaue, bin ich mir sehr sicher, dass wir selbst bei Replikationsverkehr Schwierigkeiten haben werden, die 4-Gbit-Linie zu überqueren.

Der Datei-Serving-Cluster mit 4 Knoten kann zwei Knoten in SAN1SW4 und zwei in SAN1SW1 haben, da beide Speicher-Arrays einen Sprung entfernt sind.

Die 10 ESX-Knoten sind mir etwas unangenehm. Drei auf SAN1SW4, drei auf SAN1SW2 und vier auf SAN1SW1 sind eine Option, und ich wäre sehr interessiert, andere Meinungen zum Layout zu hören. Die meisten davon haben FC-Karten mit zwei Ports, sodass ich einige Knoten doppelt ausführen kann. Nicht alle , aber genug, um einen einzelnen Schalter ausfallen zu lassen, ohne alles zu töten.

Die beiden MS-SQL-Boxen müssen auf SAN1SW3 und SAN1SW2 ausgeführt werden, da sie sich in der Nähe ihres primären Speichers befinden müssen und die Leistung des DB-Exports weniger wichtig ist.

Die LTO4-Laufwerke befinden sich derzeit auf SW2 und 2 Hops von ihrem Haupt-Streamer, daher weiß ich bereits, wie das funktioniert. Diese können auf SW2 und SW3 bleiben.

Ich würde es vorziehen, die untere Hälfte des Diagramms nicht zu einer vollständig verbundenen Topologie zu machen, da dies unsere Anzahl verwendbarer Ports von 66 auf 62 reduzieren würde und SAN1SW1 25% ISLs betragen würde. Aber wenn das dringend empfohlen wird, kann ich diesen Weg gehen.


Update: Einige Leistungszahlen, die wahrscheinlich nützlich sein werden. Ich hatte sie, ich habe nur beachtet, dass sie für diese Art von Problem nützlich sind.

EVA4400-A in der obigen Tabelle führt Folgendes aus:

  • Während des Arbeitstages:
    • E / A-Operationen sind im Durchschnitt unter 1000 mit Spitzenwerten auf 4500 während ShadowCopy-Snapshots des Dateiserverclusters (dauert etwa 15 bis 30 Sekunden).
    • MB / s bleiben im Allgemeinen im Bereich von 10 bis 30 MB, mit Spitzen von bis zu 70 MB und 200 MB während ShadowCopies.
  • Während der Nacht (Backups) tritt es wirklich schnell in die Pedale:
    • E / A-Operationen liegen im Durchschnitt bei 1500, mit Spitzen von bis zu 5500 während DB-Sicherungen.
    • MB / s variieren stark, laufen jedoch mehrere Stunden lang mit etwa 100 MB und pumpen während des SQL-Exportvorgangs beeindruckende 15 MB / s für etwa 15 Minuten.

EVA6100 ist viel beschäftigter, da hier der ESX-Cluster, MSSQL und eine gesamte Exchange 2007-Umgebung untergebracht sind.

  • Während des Tages beträgt der Durchschnitt der E / A-Operationen etwa 2000 mit häufigen Spitzen bis zu etwa 5000 (mehr Datenbankprozesse) und MB / s im Durchschnitt zwischen 20 und 50 MB / s. Spitzen-MB / s treten während ShadowCopy-Snapshots im Dateiserving-Cluster auf (~ 240 MB / s) und dauern weniger als eine Minute.
  • Während der Nacht pumpt die Exchange Online-Defragmentierung, die von 1 Uhr morgens bis 5 Uhr morgens läuft, E / A-Operationen mit 7800 (nahe der Flankengeschwindigkeit für wahlfreien Zugriff mit dieser Anzahl von Spindeln) und 70 MB / s auf die Leitung.

Ich würde mich über Ihre Vorschläge freuen.

sysadmin1138
quelle
Wissen Sie, wie viele Systeme Sie CA'ing werden? Wir sehen ~ 20 Mbit / s für ein "typisches" abteilungsbasiertes Oracle-basiertes System.
Simon Catlin
@ Simon Unser Oracle-Zeug befindet sich komplett in einer anderen Umgebung. Derzeit kommunizieren 6 Server über die ISLs mit großer Reichweite, von denen nur 4 dies kontinuierlich tun. Die anderen beiden machen 1-2 mal am Tag große Bursts. Der durchschnittliche Durchsatz für diesen EVA beträgt ca. 15 bis 30 MBit / s mit Spitzenwerten von bis zu 150 MB bei normalen Sicherungen und 320 MB bei SQL-Exporten (dauert ca. 15 Minuten).
sysadmin1138

Antworten:

6

Entschuldigung für die Verspätung.

Ich habe mir angesehen, was Sie haben und was Sie erreichen möchten. Ich hatte ein paar Gedanken, hier ist zuerst ein schönes Bild ...

Alt-Text

  • Es scheint derzeit keinen Sinn zu machen, eine 8-Gbit / s-Verbindung zwischen Standorten zu verwenden. Der Grund dafür ist, dass Sie durch die 4-Gbit / s-Ports auf der Remote-4400 eingeschränkt sind. Sie haben bereits stabile 4-Gbit / s-Verbindungen und die verfügbare Bandbreite ist viel höher als die tatsächliche Nutzungsanforderung - Es scheint heute nur eine Verschwendung zu sein, einen der 24x8-Schalter dort zu platzieren. Ich würde zwei der 16x4Gb-Switches am Remote-Standort verwenden.
  • Ich wäre versucht, die neuen 24x8-Switches als Haupt-Switches zu verwenden. Der größte Teil Ihres Datenverkehrs erfolgt von Server zu 6100, und die neue Box wird viel schneller sein. Auf diese Weise sollten Sie einige kleine Leistungssteigerungen sehen, da der neue Switch über größere Puffer und eine geringere Latenz verfügt. Außerdem können Sie auswählen, welche Server nach Belieben auf 8 GB umgestellt werden sollen. Dies gilt auch für den Austausch des 6100 (der 4600 haben native 8-Gbit-Ports, aber das ist noch nicht offiziell;)).
  • Wir kommen dann zu einem Teil des Entwurfs, in dem wir zwei Möglichkeiten haben; um die beiden 16x4Gb-Mittelschalter zu behalten oder zu verwerfen - ausschließlich basierend auf der Anzahl der Ports. Grundsätzlich haben Sie, wenn Sie die 24x8-Switches als Core-Boxen verwendet haben, nur 3 Ersatzports (da Sie 18 für die 18 Server verwenden, plus 2 für den 6100 und eine ISL-Verbindung, was 21 entspricht). Du könntestSchließen Sie den lokalen 4400 an die 24x8-Switches an, sodass Sie genau 1 Port für Ihre Bandlaufwerke frei haben, aber keine freien Ports mehr haben. Ich wäre versucht, die beiden mittleren 16x4-GB-Switches entweder als sekundäre lokale Switches für die lokalen 4400- und Bandlaufwerke oder möglicherweise für die ISL-Verbindungen zwischen Standorten zu verwenden, wenn Sie dies wünschen - obwohl Sie über Ports verfügen kostenlos auf den 24x8Gb-Switches, um dies direkt von dort aus zu tun, wenn Sie es wünschen - ich habe nicht beide gezeigt, da sie sich wirklich sehr ähnlich sind.

Das sind meine Gedanken - es gibt überall Verbesserungen, aber meine allgemeinen Ideen sind da - Sie können sich gerne mit Klarstellungen an mich wenden.

Chopper3
quelle
Budget Ghods will, die Hoffnung ist, dass wir, wenn wir den 6100 ersetzen, auch ein paar ESX-Server an der Remote-Site installieren können. Ich bin sehr glücklich zu warten, bis die Kräfte, die erkennen, dass das Post-6100-Array einen Replikationspartner am Remote-Standort hat, The Thing sind, und warten, bis dieses Projekt für 8-Gbit-ISLs zwischen Standorten erfolgt. Wenn ich wieder zur Arbeit komme, muss ich die Leute darüber informieren, wie wahrscheinlich es ist, dass diese neuen ESX-Boxen ohne den 6100-Ersatz sind.
sysadmin1138
1
Nachdem ich Kaffee getrunken und darüber nachgedacht habe, habe ich einige Kommentare. Eines meiner Ziele ist es, besser mit Switch-Fehlern (oder Neustarts) umzugehen. In diesem Fall wird das lineare Topo beschädigt. Ein paar ISLs werden das beheben. Es ist eine sehr gute Idee, die 24/8 an einem Ort zu behalten. Lecker 4600.
sysadmin1138