12
2 redundate Switche pro RZ
Guten Tag,
es geht mal wieder im das schöne Thema Redundanz und wie löse ich ein Problem.
Zum Hintergrund:
- Es existieren zwei Serverräume
- Ziel ist es beide Serverräume so miteinander zu vernetzen,dass der Ausfall eines Switches für den Anwender nicht bemerkbar sein wird.
- Pro Serverraum sollen zwei "große" Switche installiert werden und alle Server in dem jeweiligen Raum sollen mit den Servern verbunden werden.
- Nach Möglichkeit soll zu dem die Performance durch die beiden Switche pro Serverraum deutlich erhöht werden.
Ich habe mir die Konfiguration wie folgt vorgestellt:
Die Switch die jeweils in einem Serverraum (je Zwei) sind, werden zu logischen Switch per Stacking zusammen gefasst. Die Server in dem jeweiligen Serverraum werden an beide Switche angebunden. Das gleiche analog dazu in dem zweiten Serverraum.
Die Verbindungen zwischen den Serverräumen werden mit Trunk-Ports oder Link Aggregation Control realisiert.
Die Switche der jeweiligen Unterverteilungen werden alle dann mit je einem Kabel an jeden Switch angeschlossen.
Hier noch eine Abbildung der Verkabelung die geplant ist:
Wegen der zwei geforderten Switche pro Serverraum bin ich doch etwas verunsichert ob das der falche Ansatz wäre.
Vielen Dank schon mal.
es geht mal wieder im das schöne Thema Redundanz und wie löse ich ein Problem.
Zum Hintergrund:
- Es existieren zwei Serverräume
- Ziel ist es beide Serverräume so miteinander zu vernetzen,dass der Ausfall eines Switches für den Anwender nicht bemerkbar sein wird.
- Pro Serverraum sollen zwei "große" Switche installiert werden und alle Server in dem jeweiligen Raum sollen mit den Servern verbunden werden.
- Nach Möglichkeit soll zu dem die Performance durch die beiden Switche pro Serverraum deutlich erhöht werden.
Ich habe mir die Konfiguration wie folgt vorgestellt:
Die Switch die jeweils in einem Serverraum (je Zwei) sind, werden zu logischen Switch per Stacking zusammen gefasst. Die Server in dem jeweiligen Serverraum werden an beide Switche angebunden. Das gleiche analog dazu in dem zweiten Serverraum.
Die Verbindungen zwischen den Serverräumen werden mit Trunk-Ports oder Link Aggregation Control realisiert.
Die Switche der jeweiligen Unterverteilungen werden alle dann mit je einem Kabel an jeden Switch angeschlossen.
Hier noch eine Abbildung der Verkabelung die geplant ist:
Wegen der zwei geforderten Switche pro Serverraum bin ich doch etwas verunsichert ob das der falche Ansatz wäre.
Vielen Dank schon mal.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 196092
Url: https://administrator.de/contentid/196092
Printed on: April 19, 2024 at 17:04 o'clock
12 Comments
Latest comment
Ein übliches Szenario. Wo ist das Problem? Die Produktauswahl?
Bedenke, dass Du bei dieser Konfiguration mit STP arbeiten musst. Schöner wäre es daher, Du würdest alle 4 Switche stacken. Dafür benötigst Du Switche, die sich über normale Ethernetports stacken lassen (oft "Geo-Stacking" genannt). Sinnvoller Weise nimmt man dafür natürlich mind. 10GBE-Ports.
Geostacking sollte von allen großen Herstellern unterstützt werden. Bei Extreme weiss ich es. Selbst Netgear kann es mittlerweile bei den Topmodellen. Wir machen dies mit 2x HP A7510 (ehem. H3C). Die A5800er Serie kanns aber auch, wenn keine Chassis benötigt werden. Das Feature nennt sich IRF.
Gruß
sk
P.S.
Die Kabelwege zwischen den RZ sollten redundant sein.
Bedenke, dass Du bei dieser Konfiguration mit STP arbeiten musst. Schöner wäre es daher, Du würdest alle 4 Switche stacken. Dafür benötigst Du Switche, die sich über normale Ethernetports stacken lassen (oft "Geo-Stacking" genannt). Sinnvoller Weise nimmt man dafür natürlich mind. 10GBE-Ports.
Geostacking sollte von allen großen Herstellern unterstützt werden. Bei Extreme weiss ich es. Selbst Netgear kann es mittlerweile bei den Topmodellen. Wir machen dies mit 2x HP A7510 (ehem. H3C). Die A5800er Serie kanns aber auch, wenn keine Chassis benötigt werden. Das Feature nennt sich IRF.
Gruß
sk
P.S.
Die Kabelwege zwischen den RZ sollten redundant sein.
Also bei den Produkten wurden uns die HP 5406 ans Herz gelegt.
Stimmt das STP habe ich nicht erwähnt.. sorry =)
10GBE Ports sind auch vorgesehen, allein schon wegen der "größeren" Server.
Ist diese Vorgehensweise denn richtig bzw. sinnvoll wie es geplant habe? Also sprich ich Stacke zwei Switches pro RZ und verbinde die Switche wie eingezeichnet LAC mit einander? Somit sollte ich doch ausfallsicherheit sowie eine hohe Performance erhalten oder nicht?
Kabelwege zwischen den RZs wurden so geplant das diese unterschiedlich verlaufen. Nur entscheiden darf man ja nicht
Stimmt das STP habe ich nicht erwähnt.. sorry =)
10GBE Ports sind auch vorgesehen, allein schon wegen der "größeren" Server.
Ist diese Vorgehensweise denn richtig bzw. sinnvoll wie es geplant habe? Also sprich ich Stacke zwei Switches pro RZ und verbinde die Switche wie eingezeichnet LAC mit einander? Somit sollte ich doch ausfallsicherheit sowie eine hohe Performance erhalten oder nicht?
Kabelwege zwischen den RZs wurden so geplant das diese unterschiedlich verlaufen. Nur entscheiden darf man ja nicht
Die 5406 sind kleine Chassis-Switche aus der ehemaligen Procurve-Serie. Die lassen sich meines Wissens überhaupt nicht stacken! Jedenfalls nicht in dem Sinne, wie es hier benötigt wird. Siehe http://www.hp.com/rnd/device_help/help/hpwnd/webhelp/HPJ4121A/configura ... Was seit kurzem unterstützt wird, ist "distributed Trunking" - also Switch-übergreifendes Link-Aggregation. Dann muss man auf diesem Links auch kein STP fahren. Ein virtueller gemeinsamer Switch wird anders als bei echtem Stacking dennoch nicht daraus! Nimm lieber die A-Serie - diese sind zwar ganz anders zu konfigurieren, sind m.E. aber für das Vorhaben deutlich besser geeignet.
Ohnehin frage ich mich, wofür das gut sein soll, 2 lokale Chassis-Switche zu stacken. Da nehme ich doch lieber ein größeres Chassis und lege es redundant aus (2 Management-Module, redundante Netzteile). Die Server werden redundant auf mind. 2 Slots angebunden oder bei maximaler Verfügbarkeitsanforderung (und ausreichend Faseranzahl zwischen den RZ) jeweils auch an den Switch im anderen RZ!
Ohnehin frage ich mich, wofür das gut sein soll, 2 lokale Chassis-Switche zu stacken. Da nehme ich doch lieber ein größeres Chassis und lege es redundant aus (2 Management-Module, redundante Netzteile). Die Server werden redundant auf mind. 2 Slots angebunden oder bei maximaler Verfügbarkeitsanforderung (und ausreichend Faseranzahl zwischen den RZ) jeweils auch an den Switch im anderen RZ!
Habe mir den HP 7510 mal kurz angesehen. Eigentlich hast du Recht mit deiner Aussage. Wenn der große im eigentlichen im inneren Redundant ausgelegt ist, sollte ein komplett Ausfall nicht auftreten. Innerhalb des Chassis kann ich alle Module ja doppelt verbauen. Wenn ich zwei 24-Port 10/100/1000 Module verbaue, und je einen LAN-Port pro Server auf je ein Modul stecke, sollte ein Ausfall schon relativ unrealistisch sein. Das die Switche stabil laufen setze ich jetzt einfach mal voraus.
Somit sollte der Switch auch ausreichend ausgelegt sein für die weiteren Jahre.
Ob die Konfiguration anders ist, sehe ich nicht kritisch. Ich hoffe ja das man eh sehr wenig verändern muss und alles relativ schnell stabil funktioniert.
Darf ich fragen wie zufrieden ihr mit dem Modell seit? Gab es schon größere Probleme? Ist das Gerät sehr Wartungsintensiv (ich meine nicht die Auswertung von Bandbreiten oder LOGs)?
Somit sollte der Switch auch ausreichend ausgelegt sein für die weiteren Jahre.
Ob die Konfiguration anders ist, sehe ich nicht kritisch. Ich hoffe ja das man eh sehr wenig verändern muss und alles relativ schnell stabil funktioniert.
Darf ich fragen wie zufrieden ihr mit dem Modell seit? Gab es schon größere Probleme? Ist das Gerät sehr Wartungsintensiv (ich meine nicht die Auswertung von Bandbreiten oder LOGs)?
Zitat von @Andy1987:
Eigentlich hast du Recht mit deiner Aussage. Wenn der große im eigentlichen im inneren Redundant ausgelegt ist,
sollte ein komplett Ausfall nicht auftreten.
Eigentlich hast du Recht mit deiner Aussage. Wenn der große im eigentlichen im inneren Redundant ausgelegt ist,
sollte ein komplett Ausfall nicht auftreten.
Ja das ist eher unwahrscheinlich. Man könnte alternativ auch 4 Stück 5800er stacken. Dann hast Du 2 Switche pro Seite und könntest einen auch mal durchstarten oder austauschen, ohne dass lediglich lokal angeschlossene physische Server offline gehen.
Zitat von @Andy1987:
Innerhalb des Chassis kann ich alle Module ja doppelt verbauen. Wenn ich zwei 24-Port 10/100/1000 Module verbaue,
und je einen LAN-Port pro Server auf je ein Modul stecke, sollte ein Ausfall schon relativ unrealistisch sein.
Innerhalb des Chassis kann ich alle Module ja doppelt verbauen. Wenn ich zwei 24-Port 10/100/1000 Module verbaue,
und je einen LAN-Port pro Server auf je ein Modul stecke, sollte ein Ausfall schon relativ unrealistisch sein.
So haben wir das auch gemacht. Wobei das eigentlich nach meiner Planung nur für die Lagacy-Hosts mit Cat-Anbindung so sein sollte. Die neuen Server mit 10G-LWL-Karten wollte ich eigentlich über Kreuz an beide Rechenzentren anbinden. Die Serverleute waren dafür aber zu geizig oder zu faul und haben ihre ESX-Server nur lokal angeschlossen. Da es ohnehin ein ESX-Cluster ist, genügt das wohl als Ausfallsicherheit.
Zitat von @Andy1987:
Ob die Konfiguration anders ist, sehe ich nicht kritisch. Ich hoffe ja das man eh sehr wenig verändern muss
Ob die Konfiguration anders ist, sehe ich nicht kritisch. Ich hoffe ja das man eh sehr wenig verändern muss
Naja nach einem Rechtsstreit mit Cisco musste H3C halt die CLI-Befehle etwas ändern. Statt "show" schreibt man jetzt "display", statt "no" schreibt man "undo" usw. Gewöhnt man sich dran.
Die Weboberfläche ist natürlich auch anders als bei Procurve. M.E. ist sie aber besser!
Zitat von @Andy1987:
Darf ich fragen wie zufrieden ihr mit dem Modell seit? Gab es schon größere Probleme? Ist das Gerät sehr
Wartungsintensiv (ich meine nicht die Auswertung von Bandbreiten oder LOGs)?
Darf ich fragen wie zufrieden ihr mit dem Modell seit? Gab es schon größere Probleme? Ist das Gerät sehr
Wartungsintensiv (ich meine nicht die Auswertung von Bandbreiten oder LOGs)?
Sehr zufrieden. Die Büchsen laufen jetzt seid einem Jahr. Keine Probleme. Wir nutzen sie als kombinierte Core- und Datacenter-Switche. Sprich: daran sind die Server wie beschrieben angebunden und redundant die Distribution-Layer-Switche in den jeweiligen Standorten/Gebäuden. Die Cores sind mit 8x10G untereinander verbunden und agieren per IRF als ein Gerät. Außerdem nutzen wir VRF, um verschiedene Sicherheitszonen abzubilden. Die Cores halten für jede Sicherheitszone eine eigene Routingtabelle bereit, so dass zwischen den Subnetzen einer Zone mit Wirespeed geroutet werden kann. Sofern Traffic zwischen diesen Zonen stattfindet, wird dieser über einen Fortigate-Cluster geroutet und dort entsprechend reglementiert.
Hier ein Bild vom Redundanztest im Labor: http://www10.pic-upload.de/20.12.12/f16t6286y95.jpg Wir haben damals alle möglichen Ausfallkombinationen durchgespielt: vom Ausfall einzelner Module bis zum Ausfall eines gesamten Switches, HotSwap-Modulnachrüstung usw. - alles super!
Mittlerweile sind natürlich noch ein paar Einschübe hinzu gekommen...
Gruß
sk
Servus Andy,
stellt sich nur die Frage, wieviel Geld bist Du bereit auszugeben bzw. kannst Du ausgeben ?
Diese Umgebung kann man auch komplett ohne STP bauen und alle Ports gleichzeitig nutzen !
Wieviele Server hast Du zum anbinden ?
Wieviele Ports benötigst Du ?
Welche Server sind das ?
Rackmounted ?
Bladesysteme ?
Welche Bandbreits pro Server benötigst Du ?
Gruß
Anton
stellt sich nur die Frage, wieviel Geld bist Du bereit auszugeben bzw. kannst Du ausgeben ?
Diese Umgebung kann man auch komplett ohne STP bauen und alle Ports gleichzeitig nutzen !
Wieviele Server hast Du zum anbinden ?
Wieviele Ports benötigst Du ?
Welche Server sind das ?
Rackmounted ?
Bladesysteme ?
Welche Bandbreits pro Server benötigst Du ?
Gruß
Anton
Wie wäre es mit Cisco 4900 oder Brocade ICX 6450. Allemal performanter als HP von denen man im Core besser die Finger lässt. Nur um das mal nicht ganz so HP lastig werden zu lassen die ja nichtmal PVST geschweige denn PVSTP+ können sondern noch mit steinzeitlichen STP Protokollen hantieren. Aber egal...Hersteller gibt es zahllose...
Deine Vorgehensweise ist auf alle Fälle richtig und korrekt.
Alternativ kannst du in so einer RZ Verkabelng auch modernere und zukunftssichere Fabric basierte Switches nehmen die DCB Traffic supporten wie Cisco Nexus oder Brocade VDX. Die HP Gurken können das nicht, da sie nicht Fabric und DCB fähig sind. Nicht wirklich gut für zukünftige RZ Infrastrukturen !
Im Hinblick auf kommende Converged Adapter in Server oder Blade Systemen ist das allemal besser und erheblich zukunftssicherer als standard Ethernet Switches. Da diese im Netz dann Fabric Path oder TRILL als Standard nutzen bist du da dann vollkommen STP frei.
Solltest du drüber nachdenken wenn das eine längerfristige Anschaffung fürs RZ werden soll !
Deine Vorgehensweise ist auf alle Fälle richtig und korrekt.
Alternativ kannst du in so einer RZ Verkabelng auch modernere und zukunftssichere Fabric basierte Switches nehmen die DCB Traffic supporten wie Cisco Nexus oder Brocade VDX. Die HP Gurken können das nicht, da sie nicht Fabric und DCB fähig sind. Nicht wirklich gut für zukünftige RZ Infrastrukturen !
Im Hinblick auf kommende Converged Adapter in Server oder Blade Systemen ist das allemal besser und erheblich zukunftssicherer als standard Ethernet Switches. Da diese im Netz dann Fabric Path oder TRILL als Standard nutzen bist du da dann vollkommen STP frei.
Solltest du drüber nachdenken wenn das eine längerfristige Anschaffung fürs RZ werden soll !
Zitat von @aqui:
Wie wäre es mit Cisco 4900 oder Brocade ICX 6450. Allemal performanter als HP von denen man
die Finger im Core besser lässt. Nur um das mal nicht ganz so HP lastig werden zu lassen die
ja nichtmal PVST geschweige denn PVSTP+ können sondern noch mit steinzeitlichen STP Protokollen
hantieren.
Wie wäre es mit Cisco 4900 oder Brocade ICX 6450. Allemal performanter als HP von denen man
die Finger im Core besser lässt. Nur um das mal nicht ganz so HP lastig werden zu lassen die
ja nichtmal PVST geschweige denn PVSTP+ können sondern noch mit steinzeitlichen STP Protokollen
hantieren.
Wieviele Jahre möchtest Du noch HP Networking mit der Procurve-Linie gleichsetzen? Ich kann mir nicht vorstellen, dass Dir die Übernahmen der letzten Jahre entgangen sind. Die vorgeschlagene A-Serie sind ehemalige H3C-Switche. Und die Chinesen haben anders als Procurve keine Probleme damit, proprietäre Protokolle abzukupfern! PVST/PVST+ sind auf der A-Serie verfügbar.
Zitat von @aqui:
Alternativ kannst du in so einer RZ Verkabelng auch modernere und zukunftssichere Fabric basierte
Switches nehmen die DCB Traffic supporten wie Cisco Nexus oder Brocade VDX.
Die HP Gurken können das nicht, da sie nicht Fabric und DCB fähig sind. Nicht wirklich gut für RZ
zukünftige Infrastrukturen!
Alternativ kannst du in so einer RZ Verkabelng auch modernere und zukunftssichere Fabric basierte
Switches nehmen die DCB Traffic supporten wie Cisco Nexus oder Brocade VDX.
Die HP Gurken können das nicht, da sie nicht Fabric und DCB fähig sind. Nicht wirklich gut für RZ
zukünftige Infrastrukturen!
Bei der Übernahme von H3C ging es HP in erster Linie um den Einzug ins Rechenzentrum bzw. darum, alles aus einer Hand anbieten zu können - nicht nur Server etc. H3C brachte halt die Netzwerkkomponenten fürs Rechenzentrum mit in die Ehe ein. Siehe z.B. http://h17007.www1.hp.com/us/en/products/switches/HP_5920_Switch_Series ...
Ob nun gut oder schlecht - hab ich ehrlich keine Ahnung. Ist nicht meine Baustelle.
Das schrieb Gartner 2010: http://www.searchnetworking.de/themenbereiche/infrastruktur/router-swit ...
Nichts für ungut: Ich frag mich halt nur, wie lange Du noch undifferenziert auf der alten Leier HP=Procurve=Schrott rumreiten möchtest. Irgendwann bekommt man den Eindruck, dass Du da eine kleine Privatfede mit HP austrägst...
Gruß
sk
Guten Tag und ein frohes neues wünsche ich euch noch.
Vielen Dank erst mal für eure Unterstützung und Hilfe.
Wahrscheinlich wird die Entscheidung auf die HP 5406 fallen.
Hier die Konfiguration welche es vermutlich wird.
- In jedes Rechenzentrum wird ein Switch installiert. Alle Module werde doppelt vorhanden sein.
- Die Core-Switche werden 4 10 Gbit Leitungen Verbunden. Die Switch-Ports werden im Trunk zusammen gefasst.
- Die Switche der Unterverteilung werden mit je einer LWL 1 Gbit Leitung an beide Switche angeschlossen. Auf den Switchen der Unterverteilung wird das Spanning Tree Protocol aktiviert.
- Die Server werden mit mindestens einer 10 Gbit Leitung an beide Switche angeschlossen (Sprich überkreuz Verbunden)
- Die restlichen "Geräte" welche für die Infrastrutur wichtig sind wie Router etc. sind in beiden Serveräumen verhanden und müssen somit kann ein Ausfall hiervon verkraftet werden.
Was haltet ihr von diesem Aufbau? Seht ihr hierbei Probleme? Weitere Punkte auf die geachtet werden sollte?
Danke für eure Hilfe.
Vielen Dank erst mal für eure Unterstützung und Hilfe.
Wahrscheinlich wird die Entscheidung auf die HP 5406 fallen.
Hier die Konfiguration welche es vermutlich wird.
- In jedes Rechenzentrum wird ein Switch installiert. Alle Module werde doppelt vorhanden sein.
- Die Core-Switche werden 4 10 Gbit Leitungen Verbunden. Die Switch-Ports werden im Trunk zusammen gefasst.
- Die Switche der Unterverteilung werden mit je einer LWL 1 Gbit Leitung an beide Switche angeschlossen. Auf den Switchen der Unterverteilung wird das Spanning Tree Protocol aktiviert.
- Die Server werden mit mindestens einer 10 Gbit Leitung an beide Switche angeschlossen (Sprich überkreuz Verbunden)
- Die restlichen "Geräte" welche für die Infrastrutur wichtig sind wie Router etc. sind in beiden Serveräumen verhanden und müssen somit kann ein Ausfall hiervon verkraftet werden.
Was haltet ihr von diesem Aufbau? Seht ihr hierbei Probleme? Weitere Punkte auf die geachtet werden sollte?
Danke für eure Hilfe.
Hallo,
jo das wäre doch noch so ein Punkt, die Router.
Was habt Ihr denn für welche im Einsatz, wenn man mal fragen darf.
Und vor allem wie viele davon, über was und wie angebunden? (Untereinander, Internet)
Gruß
Dobby
jo das wäre doch noch so ein Punkt, die Router.
Was habt Ihr denn für welche im Einsatz, wenn man mal fragen darf.
Und vor allem wie viele davon, über was und wie angebunden? (Untereinander, Internet)
Gruß
Dobby
Also wenn wirklich alle Server, Access-Switche usw. jeweils an beide Core-/Datacenter-Switche angeschlossen sind, müssten die Core-/Datacenter-Switche intern noch nicht mal redundant ausgelegt sein.
Wie gesagt: beachte jedoch bei der Switch-übergreifenden Nutzung von Links-Aggregation, dass die Procurve beim Stacking nicht als ein Switch agieren. Du musst stattdessen auf jedem Switch "distributed trunking" konfigurieren.
Gruß
sk
Wie gesagt: beachte jedoch bei der Switch-übergreifenden Nutzung von Links-Aggregation, dass die Procurve beim Stacking nicht als ein Switch agieren. Du musst stattdessen auf jedem Switch "distributed trunking" konfigurieren.
Gruß
sk
Zitat von @108012:
Hallo,
jo das wäre doch noch so ein Punkt, die Router.
Was habt Ihr denn für welche im Einsatz, wenn man mal fragen darf.
Und vor allem wie viele davon, über was und wie angebunden? (Untereinander, Internet)
Gruß
Dobby
Hallo,
jo das wäre doch noch so ein Punkt, die Router.
Was habt Ihr denn für welche im Einsatz, wenn man mal fragen darf.
Und vor allem wie viele davon, über was und wie angebunden? (Untereinander, Internet)
Gruß
Dobby
Wir (eigentlich) alles mindestens zwei mal im Einsatz sodass der Ausfall einer Komponente zeitnah behoben werden kann bzw. im Idealfall von den Anwendern gar nicht bemerkt wird.
Zitat von @sk:
Also wenn wirklich alle Server, Access-Switche usw. jeweils an beide Core-/Datacenter-Switche angeschlossen sind, müssten die
Core-/Datacenter-Switche intern noch nicht mal redundant ausgelegt sein.
Wie gesagt: beachte jedoch bei der Switch-übergreifenden Nutzung von Links-Aggregation, dass die Procurve beim Stacking nicht
als ein Switch agieren. Du musst stattdessen auf jedem Switch "distributed trunking" konfigurieren.
Gruß
sk
Also wenn wirklich alle Server, Access-Switche usw. jeweils an beide Core-/Datacenter-Switche angeschlossen sind, müssten die
Core-/Datacenter-Switche intern noch nicht mal redundant ausgelegt sein.
Wie gesagt: beachte jedoch bei der Switch-übergreifenden Nutzung von Links-Aggregation, dass die Procurve beim Stacking nicht
als ein Switch agieren. Du musst stattdessen auf jedem Switch "distributed trunking" konfigurieren.
Gruß
sk
Naja die Redundate Auslegung der Komponenten resultiert auch der Anzahl der benötigten Ports und die Redundanz ist der Module ist hierbei ein schöner Nebeneffekt.
Leider wird es nicht gehen beide als einen logischen Switch zu konfigurieren, aber die Hauptsache ist, dass die Konfiguration stabil ist, das Netz einen allgemeinen Performance anstieg bekommt und zudem die Ausfallsicherheit gegeben ist.
