Best Practices zum Hinzufügen eines zweiten FC-Switches zum Fabric in der Produktionsumgebung?

Best Practices zum Hinzufügen eines zweiten FC-Switches zum Fabric in der Produktionsumgebung?

Ich habe derzeit einen einzelnen Brocade Silkworm 200e-Switch in Betrieb. Der Corp Exchange Server und 3 ESX 3.5-Hosts sind darüber mit dem Clariion CX3-Array verbunden. Port 0,1 sind SPA0 und 1 und Port 4,5 sind SPB0 und 1.

Mein Plan besteht darin, neben dem 200 einen Brocade Silkworm 300-Switch hinzuzufügen (er ist bereits im Rack montiert und eingeschaltet), ins Rechenzentrum zu gehen, SPA1 und SPB0 aus dem 200 zu ziehen und sie in die Ports des 300-Switches einzufügen.

Ich bin etwas paranoid, wenn es darum geht, FC-Pfade herauszuziehen, die in Produktion sind. Ich gehe logisch davon aus, dass die Dinge einfach auf SPA0 und SPB1 umgeschaltet werden und A1 und B0 nicht fehlen werden. Ich möchte jedoch zu 100 % sicher sein, was ich tun könnte, um die Risiken möglichst weiter zu minimieren.

Wenn eine LUN derzeit SPA gehört, nutzt sie dann automatisch sowohl SPA0 als auch SPA1 im Round Robin-Verfahren oder bevorzugt der Switch ausschließlich einen bestimmten Pfad, sofern er nicht ausfällt? Beispiel: Verwendet der Exchange-Server SPA0 oder SPA1 oder nutzt er sowohl 0 als auch 1 aktiv/aktiv?

Ich vermute, dass es weniger riskant ist, einen der beiden Pfade zu einem SP aktiv/aktiv zu unterbrechen, wenn beide Pfade verwendet werden, da ich sicher bin, dass der andere Pfad bereits ohne Probleme verwendet wird. Ich habe Angst, ein Failover auf einen alternativen Pfad zu erzwingen, den der Server noch nicht verwendet hat, und dann herauszufinden, dass das Kabel defekt war oder so.

Sollte ich den Betrieb des Unternehmens komplett unterbrechen und alle virtuellen Maschinen und den Exchange-Server herunterfahren, nur um sicherzugehen, dass im Falle eines fehlerhaften Failovers keine Daten beschädigt werden? Oder ist das übertrieben? In jedem Fall werde ich den Vorgang unmittelbar nach einem vollständigen Sicherungszyklus durchführen.

Wie würden Sie das Failover überwachen, während es passiert? Protokolliert der Brocade 200e es detailliert? Ich möchte die maximale Sicherheit, dass alles noch funktioniert, wenn ich die Stecker ziehe. Ich kann den Speicher auf den ESX-Hosts erneut scannen und den Powerpath-Monitor von Exchange beobachten. Kann ich etwas Besseres tun?

Ich möchte lieber weitaus vorsichtiger sein, als es die Situation erfordert, als voreilige Schlüsse zu ziehen, wenn wir so etwas zum ersten Mal machen und dabei alle Eier in einen Korb legen.

Antwort1

Ich hoffe, dass Ihr Plan darin besteht, eine zweite unabhängige Struktur einzurichten, das wird grundsätzlich als eine gute Idee angesehen.

Sie sagen nicht, ob Ihre Server mehrere HBAs haben oder nicht. Ich hoffe, dass dies der Fall ist, da Sie dann für redundante Strukturen richtig neu konfigurieren können. Wenn nicht, hat dies jedoch keine wesentlichen Auswirkungen auf Ihren unmittelbaren Plan.

Powerpath übernimmt das Failover für den Exchange-Server und sollte einen Pfad über A1 wählen, wenn A0 getrennt ist, und nicht über B0 oder B1, es sei denn, beide SPA-Ports sind ausgefallen. Wenn Pfade nicht betriebsbereit sind, wird Ihnen dies mitgeteilt, oder Sie werden zumindest die erwarteten Pfade nicht sehen. Je nachdem, welche Version von Powerpath (d. h. die SE-Version oder die voll lizenzierte Version) Sie haben, sind möglicherweise Multipfad-Richtlinien zum Lastausgleich aktiv, aber in jedem Fall sollte das Pfad-Failover für die von Ihnen beschriebene Konfiguration zuverlässig sein. Wenn Sie zufällig einen aktiven Pfad trennen, leitet Powerpath die ausgefallenen IOs über den alternativen Pfad um, sofern sie fehlerfrei sind. Sie können den Pfadstatus in der Powerpath-GUI oder über die Befehlszeile überprüfen, powermt checkum nach fehlgeschlagenen/neuen Pfaden zu suchen oder powermt restoreum tote/neue Pfade zu überprüfen und zu entfernen/hinzuzufügen. Wenn die Pfadrichtlinie bereits für den Lastausgleich festgelegt ist und fehlerfreie Pfade über SPA0 und SPA1 (zum Beispiel) sichtbar sind, können Sie ziemlich sicher sein, dass alles in Ordnung ist.

Auf den ESX-Servern sollten Sie die für jede LUN verfügbaren Pfade über die Registerkarte VI-Client->Konfiguration->Speicher überprüfen können. In den Eigenschaften können Sie die verfügbaren Pfade sehen, die aktiv und die in Standby sind, und im Dialogfeld „Pfade verwalten“ können Sie die Richtlinie ändern (Festgelegt\MRU\Round Robin). Sie müssen eigentlich nichts ändern, aber Sie sollten erneut sicherstellen, dass der gewünschte Failover-Pfad verfügbar ist. Auch hier wird der Multipfad-Stack von ESX das Failover handhaben. Wenn IOs auf einem aktiven Pfad unterwegs sind, werden sie auf einem anderen Pfad erneut gesendet, wenn festgestellt wird, dass dieser fehlgeschlagen ist. ESX 3.5 unterstützt Round-Robin-Multipathing nur experimentell, daher sollten Sie in diesem Fall nicht damit herumspielen. Sie könnten vorübergehend eine feste Pfadrichtlinie festlegen und die LUNs auf den gewünschten Pfad zwingen, wenn Sie proaktiv vorgehen möchten, aber die Standardeinstellung für den CX3 ist, es bei MRU zu belassen, und das sollte in Ordnung sein.

In beiden Fällen kann es zu einer gewissen Verzögerung kommen, bevor das Failover erfolgt, und die E/A-Vorgänge können kurzzeitig ins Stocken geraten. Vorausgesetzt jedoch, die redundanten Pfade sind tatsächlich fehlerfrei, sollte nichts ausfallen.

verwandte Informationen