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.
(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.
