Netzwerkdesign unter Serverräumen
Hallo zusammen,
ich benötige Unterstützung oder informative Gedanken zur Gestaltung eines Netzwerkdesign für folgendes Szenario.
Gegeben sind drei "Serverräume", diese beinhalten jeweils ein Rack mit Hardware.
In zwei Räumen halten wir VMWare-Systeme inkl. Storage-System vor. Die Storage-Systeme sind untereinander redundant und können für das Netzwerkdesign erstmal außer acht gelassen werden.
In beiden Räumen wird eine Firewall existieren, die im Cluster betrieben wird.
Der dritte Raum beinhaltet die Systeme zur Datensicherungen.
Der Einfachheit könnte ich nun in jedem Schrank einen Switch installieren, diese untereinander verbinden und hätte mein "Netzwerk". Allerdings wäre ich dadurch über keinen Ausfall der Hardware geschützt. Ich strebe eine Konstellation aus zwei Switchen pro Rack an, die untereinander verbunden sind. Pro Rack klemme ich nun die Endgeräte jeweils auf den einen und anderen Switch, soweit es mir möglich ist.
Die Frage ist nun, ob das ein gängiges Szenario ist und/oder ob es eine Best-Practice für mein "kleines" Vorhaben gibt. Thema ist auch Einbindung der Firewall.
ich benötige Unterstützung oder informative Gedanken zur Gestaltung eines Netzwerkdesign für folgendes Szenario.
Gegeben sind drei "Serverräume", diese beinhalten jeweils ein Rack mit Hardware.
In zwei Räumen halten wir VMWare-Systeme inkl. Storage-System vor. Die Storage-Systeme sind untereinander redundant und können für das Netzwerkdesign erstmal außer acht gelassen werden.
In beiden Räumen wird eine Firewall existieren, die im Cluster betrieben wird.
Der dritte Raum beinhaltet die Systeme zur Datensicherungen.
Der Einfachheit könnte ich nun in jedem Schrank einen Switch installieren, diese untereinander verbinden und hätte mein "Netzwerk". Allerdings wäre ich dadurch über keinen Ausfall der Hardware geschützt. Ich strebe eine Konstellation aus zwei Switchen pro Rack an, die untereinander verbunden sind. Pro Rack klemme ich nun die Endgeräte jeweils auf den einen und anderen Switch, soweit es mir möglich ist.
Die Frage ist nun, ob das ein gängiges Szenario ist und/oder ob es eine Best-Practice für mein "kleines" Vorhaben gibt. Thema ist auch Einbindung der Firewall.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7523642502
Url: https://administrator.de/forum/netzwerkdesign-unter-serverraeumen-7523642502.html
Ausgedruckt am: 22.12.2024 um 18:12 Uhr
33 Kommentare
Neuester Kommentar
Moin,
so ganz verstehe ich deine Erklärung nicht.
(Wobei ich das nicht im L2 sondern eher per L3 und OSPF o.Ä. machen würde) Welche Speed wird zwischen den Räumen gewünscht?
lg,
Slainte
so ganz verstehe ich deine Erklärung nicht.
In beiden Räumen wird eine Firewall existieren, die im Cluster betrieben wird.
Du hast a) in jedem Raum einen FW-Cluster oder b) je eine FW pro Raum, die dann zusammen als Cluster betrieben werden? Sichern die FWs dann das LAN gegen das Internet ab, oder werden die Racks an sich vom restlichen Netzwerk getrennt?Die Frage ist nun, ob das ein gängiges Szenario ist
Hm, ja, kann man so machen. Pro Rack 2 Switche, und dann alles "über Kreuz" und xSTP entscheidet wo's langgeht.(Wobei ich das nicht im L2 sondern eher per L3 und OSPF o.Ä. machen würde) Welche Speed wird zwischen den Räumen gewünscht?
Thema ist auch Einbindung der Firewall.
Einzahl? Oder meisnt du damit den/die FW-Cluster? Wo siehst du da die Herausforderung?lg,
Slainte
Ich würde definitiv zwei Switche pro Raum/Rack machen und alles im Rack nach Möglichkeit redundant stecken. Die Switches können gestacked sein, das kann aber herstellerspezifisch unterschiedlich sein. Ich z.B. habe pro Raum/Rack einen Modular-Switch der in sich redundant ist, dessen Management Interface allerdings beim stacken nicht mehr so richtig redundant läuft, daher habe ich die Switche untereinander (also aus beiden Räumen) nicht gestackt sondern per "inter switch connect (ISC)" vervunden.
Bei mir sind außerdem die Server sofern möglich an beiden Switches gepatcht, also ein Adapter lokal, einer über Gebäudeverkabelung im Nebengebäude.
@aqui kann dir vermutlich zu jedem Switch-Hersteller eine entsprechende Empfehlung aussprechen, steht der schon fest?
Bei mir sind außerdem die Server sofern möglich an beiden Switches gepatcht, also ein Adapter lokal, einer über Gebäudeverkabelung im Nebengebäude.
@aqui kann dir vermutlich zu jedem Switch-Hersteller eine entsprechende Empfehlung aussprechen, steht der schon fest?
Hallo,
schließe mich dein beiden Kollegen an. Würde dir auch empfehlen je Serverraum min. 2 Switche die wiederum im Ring mit je switch 2x10GBs LWL zu verbinden. Die Restlichen switche würde ich dann an beide switche verbinden.
Frage ist in welchem Raum ist denn euer Glasfaser Anschluss (ISP) und wie weit ist der zum zweiten FW?
Hast du dir Gedanken Datensicherung/Aufbewahrung gemacht? z.B: Feuerlöschanlage. Wir haben z.B. in zwei Serverräumen eine Gaslöschanlage die in 50 Sekunden das Feuer auspustet....
LG
schließe mich dein beiden Kollegen an. Würde dir auch empfehlen je Serverraum min. 2 Switche die wiederum im Ring mit je switch 2x10GBs LWL zu verbinden. Die Restlichen switche würde ich dann an beide switche verbinden.
Frage ist in welchem Raum ist denn euer Glasfaser Anschluss (ISP) und wie weit ist der zum zweiten FW?
Hast du dir Gedanken Datensicherung/Aufbewahrung gemacht? z.B: Feuerlöschanlage. Wir haben z.B. in zwei Serverräumen eine Gaslöschanlage die in 50 Sekunden das Feuer auspustet....
LG
die wiederum im Ring
"Im Ring" bei Ethernet?? Besser nicht, sofern es nicht DC Fabric Switches mit TRILL oder SPB sind oder Full Stacks mit Daisy Chain Stacking und Stack Trunks. Ansonsten sind Ringe im klassischen STP für jeden Admin bekanntlich ein NoGo im Design, ganz besonders im RZ.Ansonsten ist der o.g. Rest mit 2 Switches richtig und klassisches RZ Design sofern man nicht Rack- bzw. raumübergreifend patchen kann.
Dann 6 Einzelswitches in einem Ring?
In einem klassischen Einzelswitch Umfeld ist das ein ziemliches NoGo. Auch ein Laie weiss das Ethernet immer Stern ist. Ring Topologien sind tödlich was STP Recovery Times anbetrifft und es besteht immer die Gefahr eines Split Brain. Kein guter Netzwerk Admin realisiert aus diesen und anderen Gründen niemals Ring Designs im RZ.
Es gibt 2 Ausnahmen davon:
Switches die nicht Full Stack oder Fabric fähig sind erfordern im RZ immer ein sog. Multi Tier Design mit einem Aggregation Core für die Rack Switches.
Es kommt also entweder darauf WAS du designtechnisch planst und das die Infrastruktur Hardware dazu passt. Oder du bei bestehenden Hardware Vorgaben das Infrastruktur Design an die möglichen Features der Hardware anpasst.
Wenn du noch weitere Details wissen musst einfach fragen...
Alles simple Binsenweisheiten die du als verantwortlicher Admin bei einer DC Planung aber eigentlich kennen solltest statt in Foren nachzufragen. 🧐
In einem klassischen Einzelswitch Umfeld ist das ein ziemliches NoGo. Auch ein Laie weiss das Ethernet immer Stern ist. Ring Topologien sind tödlich was STP Recovery Times anbetrifft und es besteht immer die Gefahr eines Split Brain. Kein guter Netzwerk Admin realisiert aus diesen und anderen Gründen niemals Ring Designs im RZ.
Es gibt 2 Ausnahmen davon:
- Alles Switches sind Full Stack fähig und man realisiert einen Stack Trunk über alle 6 Switches
- Alle Switches sind Fabric Switches und arbeiten mit TRILL oder SPB ohne STP.
Switches die nicht Full Stack oder Fabric fähig sind erfordern im RZ immer ein sog. Multi Tier Design mit einem Aggregation Core für die Rack Switches.
Es kommt also entweder darauf WAS du designtechnisch planst und das die Infrastruktur Hardware dazu passt. Oder du bei bestehenden Hardware Vorgaben das Infrastruktur Design an die möglichen Features der Hardware anpasst.
Wenn du noch weitere Details wissen musst einfach fragen...
Alles simple Binsenweisheiten die du als verantwortlicher Admin bei einer DC Planung aber eigentlich kennen solltest statt in Foren nachzufragen. 🧐
und wie groß die Distanzen zwischen den Räumen ist.
Richtig! Bzw. auch was für eine Glasfaser dort ggf. schon liegt (OM Typ), denn davon sind die 10G Distanzen abhängig.Im Hinblick darauf das 10G bei vielen Servern und NAS mittlerweile Standard ist oder wird sollte man ggf. überlegen ob man nicht gleich auf skalierbare 40G im RZ Backbone geht. Das ist aber wieder eine Frage der zukünftigen Anforderungen und auch des Budgets zu dem der TO leider keinerlei Angaben macht.
Zitat von @aqui:
Ansonsten ist der o.g. Rest mit 2 Switches richtig und klassisches RZ Design sofern man nicht Rack- bzw. raumübergreifend patchen kann.
die wiederum im Ring
"Im Ring" bei Ethernet?? Besser nicht, sofern es nicht DC Fabric Switches mit TRILL oder SPB sind oder Full Stacks mit Daisy Chain Stacking und Stack Trunks. Ansonsten sind Ringe im klassischen STP für jeden Admin bekanntlich ein NoGo im Design, ganz besonders im RZ.Ansonsten ist der o.g. Rest mit 2 Switches richtig und klassisches RZ Design sofern man nicht Rack- bzw. raumübergreifend patchen kann.
Hallo @aqui
ich meinte eigentlich seinen core ohne stp. den rest schließe ich mich an ;)
LG
Ich würde in jedem Raum zwei Switche vorsehen und die über die 10G-LWL zu einem Stack zusammenfassen. Das Stacking dann über die LWL als Ring auslegen.
Damit hast du immer noch einen funktionierenden Stack wenn eine Verbindung ausfällt.
Optimalerweise sollten die LWL dann auch noch auf unterschiedlichen Wegen in getrennten Kabeln verlaufen. Sonst sind bei einem Kabelschaden gleichzeitig mehr als eine Strecke weg und der Stack dann gleich mit.
Manuel
Damit hast du immer noch einen funktionierenden Stack wenn eine Verbindung ausfällt.
Optimalerweise sollten die LWL dann auch noch auf unterschiedlichen Wegen in getrennten Kabeln verlaufen. Sonst sind bei einem Kabelschaden gleichzeitig mehr als eine Strecke weg und der Stack dann gleich mit.
Manuel
Moin,
Je nachdem bist du schnell bei einem komplexen Layer 3 Routing Design mit unterschiedlichen Subnetzen oder/und mit dynamischen Routing wie OSPF. Oder einfach wie hier mehrfach skizziert bei einem Layer 2 Netz.
Gruß,
Dani
In zwei Räumen halten wir VMWare-Systeme inkl. Storage-System vor. Die Storage-Systeme sind untereinander redundant und können für das Netzwerkdesign erstmal außer acht gelassen werden.
das Design hängt meiner Meinung nach davon ab, ob- das eine oder das andere RZ bzw. LWL Kabel funktionstüchtig sein muss.
- bei einem Ausfall die VMs einfach in RZ B kalt gestartet werden oder ob es eine Applikation Redundanz geben muss.
Je nachdem bist du schnell bei einem komplexen Layer 3 Routing Design mit unterschiedlichen Subnetzen oder/und mit dynamischen Routing wie OSPF. Oder einfach wie hier mehrfach skizziert bei einem Layer 2 Netz.
Gruß,
Dani
Zitat von @aqui:
Im Hinblick darauf das 10G bei vielen Servern und NAS mittlerweile Standard ist oder wird sollte man ggf. überlegen ob man nicht gleich auf skalierbare 40G im RZ Backbone geht. Das ist aber wieder eine Frage der zukünftigen Anforderungen und auch des Budgets zu dem der TO leider keinerlei Angaben macht.
...und wenn wir schon dabei sind auch wie viele Fasern dir zur Verfügung stehen.und wie groß die Distanzen zwischen den Räumen ist.
Richtig! Bzw. auch was für eine Glasfaser dort ggf. schon liegt (OM Typ), denn davon sind die 10G Distanzen abhängig.Im Hinblick darauf das 10G bei vielen Servern und NAS mittlerweile Standard ist oder wird sollte man ggf. überlegen ob man nicht gleich auf skalierbare 40G im RZ Backbone geht. Das ist aber wieder eine Frage der zukünftigen Anforderungen und auch des Budgets zu dem der TO leider keinerlei Angaben macht.
Denkbar ist auch statt 2 redundante Switche pro RZ nur einen und dann wirklich alles wichtige über die Gebäudeverkabelung einmal lokal und einmal am entfernten Switch patchen. Das geht aber wirklich nur wenn a) genug Fasern da sind, b) der Abstand / die Leitungsqualität oder was auch immer kein Problem werden und c) jeder wichtige Server, Router, Access-Switch etc. so angebunden werden kann. Ist da z.B. ein alter Server mit Kupfer GbE, ne kleine NAS oder sonstwas hinter und das soll immer erreichbar sein geht es halt nicht oder man kann damit leben das dann was fehlt.
Zitat von @informatikkfm:
Versteh ich das also richtig, dass ich die Switche pro Rack lieber zu einem Stack zusammenfassen sollte und dann jeweils die drei Stacks mit einem oder mehr 10G-Verbindungen untereinander verbinde?
Versteh ich das also richtig, dass ich die Switche pro Rack lieber zu einem Stack zusammenfassen sollte und dann jeweils die drei Stacks mit einem oder mehr 10G-Verbindungen untereinander verbinde?
Ich würde einen Stack bestehend aus den sechs Switchen bauen.
Ich würde es erstmal mit den Aruba 2930F versuchen, stacking fähig sind die, keine Ahnung welche Einschränkungen es da noch gibt. Wie viele hast du denn und sind die noch nicht im Stack? Ich habe zwei 5406 da hatte ich wegen des Management Modul auf stacking verzichtet aber das sollte bei dir anders laufen.
https://community.arubanetworks.com/discussion/backplane-stacking-and-vs ...
https://community.arubanetworks.com/discussion/backplane-stacking-and-vs ...
ich meinte eigentlich seinen core ohne stp. den rest schließe ich mich an ;)
OK, das wäre dann natürlich korrekt sofern es denn einen Core beim TO gibt. Auch dazu macht der TO ja leider keine Aussage. Von Aruba solltest du besser die Finger lassen, denn oftmals machen die nur billiges Clustering und verkaufen das unwissenden Kunden dann als "Stacking". Die einfachen Switches sind zudem Accton/EdgeCore OEMs und Massenhardware mit wenig skalierenden Marvell ASICs. HP hat einen gruseligen Zoo zugekaufter Marken und OEM Hardware und keine eigene Entwicklung. Netzwerk Infrastruktur ist nicht deren Core Strategie und Geschäft das sollte man nie vergessen sofern das außer Preis ein Gesichtspunkt ist.
Bei Cisco nimmst du Cat 9000er mit Stackwise Virtual oder wenn du bei der SoHo Billigschiene bleiben willst CBS350X.
Empfehlung für ein wirklich gutes Full Stacking sind immer Ruckus Switches z.B. ICX7550 die eine skalierbare 40G Stacking Option gleich on Board haben und wo du in den Racks SFP und RJ45 Modelle im Stack mischen kannst sofern deine Server unterschiedliche Anschluss Optionen haben und supporten.
Mit OM4 Verkabelung und 3rd Party BiDi QSFPs die MM Faserlängen mit 100m supporten bekommst du hier ein auch in Zukunft sehr gut skalierendes RZ Backbone. Außerdem hast du über ein 4er Modul 10G Optionen zum Nachrüsten sowie redundante Netzteile. Das 24er Modell hat 12 Multigig Ports bis 10G Base T und bietet so auch höhere Bandbreiten für Server. Inkludiert ist ein 5 Jahre NBD Service.
Wenn du Cisco und HP gewohnt bist hast du mit den ICX keine Problem da die die gleiche Konfig Syntax verwenden. (Cisco CLI). KlickiBunti geht natürlich auch.
Mit SoHo Switches solltest du im RZ Bereich vorsichtig sein, denn die haben in der Regel alle überbuchte ASICS was dann zu Problemen führen kann wenn es um entsprechende Datenvoluminas und Bandbreite geht. Da kann man aber nur wieder raten weil man deine RZ Anforderungen nicht kennt.
Ist das finanziell auch mit anderen Systemen realisierbar?
Siehe oben Thema ICX.Außerdem nennst du hier Listenpreise von Cisco die natürlich kein Mensch real bezahlt. Alternative sind dann immer die Cisco CBS350-X.
Im SoHo Bereich musst du dann immer mit überbuchten und etwas schwachbrüstigen ASICS leben. Aruba bezeichnet die 2930 selber als "Access" Switches. Ob man sowas dann in einem RZ als Backbone einsetzt musst du selber entscheiden. Normal macht man das aus guten Gründen in einem RZ nicht.
Du musst dir die grundsätzliche Frage stellen was du willst. Ein Optimum an RZ Funktionen die dir auch für die Zukunft ein skalierendes RZ garantieren oder ein Budget Preis der dir diktiert was du machen kannst und dir entsprechende Grenzen setzt.
Kauft man sich als Paketbote also besser einen Mercedes Vaio oder einen Dacia Dokker...?!
Du bist selber Kaufmann und kannst das anhand deiner Anforderungen und denen der Zukunft sicher besser entscheiden als ein technisches Forum.
Hi,
im Grunde haben wir einen ähnlichen Aufbau wie du vor hast.
Es gibt zwei 3 Serverräume, 2 davon sind identisch aufgebaut mit je einem Host inkl. SAN, einer Firewall und ein CoreSwitch mit 2 Management Modulen und redundantem Netzteil.
Der 3. Raum beinhaltet das Backupystem mit Veeam, NAS und Bandlaufwerk mit TapeLoader.
Die beiden Hosts stecken jeweils mit mehreren Karten auf mind. zwei Modulen im CoreSwitch.
Die San sind jeweils mit Ihrem Host mit 2x LWL und untereinander per 4x LWL miteinander verbunden.
Die Firewals sind untereinander per LWL im HA verbund und sind jeweils mit dem CoreSwitch in ihrem Raum verbunden.
So kann bei uns jedes Gerät (Host/SAN/Firewall/Switch/oder ein kompletter Serverraum) ausfallen, ohne den Geschäftsprozess zu unterbrechen. Für Notstrom sorgen USV und ein Notstromdiesel.
Wichtig ist, dass alle Räume mindestens über zwei verschiedene Wege angebunden sind. Fällt eine Strecke aus, geht es über eine andere.
Das Veeam BackupSystem ist jeweils auch mit beiden Serverräumen verbunden, so dass es bei Ausfall des einen Hosts, den anderen sichern kann. Sind ja identisch
Dürfte doch genau dein Szenario sein?
Gruss der Hoshi
im Grunde haben wir einen ähnlichen Aufbau wie du vor hast.
Es gibt zwei 3 Serverräume, 2 davon sind identisch aufgebaut mit je einem Host inkl. SAN, einer Firewall und ein CoreSwitch mit 2 Management Modulen und redundantem Netzteil.
Der 3. Raum beinhaltet das Backupystem mit Veeam, NAS und Bandlaufwerk mit TapeLoader.
Die beiden Hosts stecken jeweils mit mehreren Karten auf mind. zwei Modulen im CoreSwitch.
Die San sind jeweils mit Ihrem Host mit 2x LWL und untereinander per 4x LWL miteinander verbunden.
Die Firewals sind untereinander per LWL im HA verbund und sind jeweils mit dem CoreSwitch in ihrem Raum verbunden.
So kann bei uns jedes Gerät (Host/SAN/Firewall/Switch/oder ein kompletter Serverraum) ausfallen, ohne den Geschäftsprozess zu unterbrechen. Für Notstrom sorgen USV und ein Notstromdiesel.
Wichtig ist, dass alle Räume mindestens über zwei verschiedene Wege angebunden sind. Fällt eine Strecke aus, geht es über eine andere.
Das Veeam BackupSystem ist jeweils auch mit beiden Serverräumen verbunden, so dass es bei Ausfall des einen Hosts, den anderen sichern kann. Sind ja identisch
Dürfte doch genau dein Szenario sein?
Gruss der Hoshi
Nichts anderes macht (oder plant) der TO ja auch.
Das sind grob die beiden technischen Optionen die der TO hat für sein RZ. Die Option Trill oder SPB Fabric Switches dürfte wohl aus Budget Gründen wegfallen wie der TO oben schon nebenbei hat durchblicken lassen.
Ohne Stacking kann man zwar dann billigere Switches verwenden mit reduziertem Feature Set, bedeutet dann durch die zusätzlichen Core/Aggregation Switches dann aber mehr (Hardware) Aufwand.
Die Full Stacking Option ist die deutlich bessere Wahl.
- Die jeweils 2 Rack Switches pro Raum (in Summe dann 6) werden in einem Full Stack Design mit einem Stack Trunk zu einem virtuellen "Core" Switch verbunden. Pro Rack dann an die beiden Member Switches redundante Anbindung der Server.
- Ohne Stacking Option der Rack Switches benötigt der TO immer einen separaten, redundanten Core bzw. Aggregation Switch auf den seine Rack Switches dann per LACP LAG connecten. Ein Ring Design mit reinem Ethernet und z.B. RSTP wäre hier ein absolutes NoGo.
Das sind grob die beiden technischen Optionen die der TO hat für sein RZ. Die Option Trill oder SPB Fabric Switches dürfte wohl aus Budget Gründen wegfallen wie der TO oben schon nebenbei hat durchblicken lassen.
Ohne Stacking kann man zwar dann billigere Switches verwenden mit reduziertem Feature Set, bedeutet dann durch die zusätzlichen Core/Aggregation Switches dann aber mehr (Hardware) Aufwand.
Die Full Stacking Option ist die deutlich bessere Wahl.
Zitat von @informatikkfm:
Hallo @ukulele-7,
von den 2930 habe ich aktuell 4 Stück in Betrieb, es würden sozusagen zwei Stück fehlen.
Du kannst die vermutlich auch nicht entbehren um eine Teststellung aufzubauen oder? Habt ihr noch Access Switches an den Core Switches oder sind das die einzigen Switches die im Einsatz sind?Hallo @ukulele-7,
von den 2930 habe ich aktuell 4 Stück in Betrieb, es würden sozusagen zwei Stück fehlen.
Liest du die dir hier für dich geposteten Informationen eigentlich?!
Das stand doch oben alles schon sogar mit einer Designzeichnung unter der Rubrik: "Ohne Stacking Option der Rack Switches benötigt der TO...."
Das dortige Design ist dann für dich bindend.
Du wirst aber um die Investition zumindestens eines Aggregation Switches nicht drum rumkommen.
Aber das ist ggf. auch nicht zwingend erforderlich wenn zumindestens eins der o.a. Racks genügend Switchports übrig hat für die sternförmige Anbindung der anderen Racks.
Ist das der Fall kannst du ein elegantes und auch redundantes Netzwerk Design mit der vorhandenen Hardware problemlos lösen. Das könnte dann z.B. so aussehen:
Leider machst du zur Verfügbarkeit von Ports dafür keine Angaben so das man das nur als 2te Option in den Raum schmeissen kann.
Das stand doch oben alles schon sogar mit einer Designzeichnung unter der Rubrik: "Ohne Stacking Option der Rack Switches benötigt der TO...."
Das dortige Design ist dann für dich bindend.
Du wirst aber um die Investition zumindestens eines Aggregation Switches nicht drum rumkommen.
Aber das ist ggf. auch nicht zwingend erforderlich wenn zumindestens eins der o.a. Racks genügend Switchports übrig hat für die sternförmige Anbindung der anderen Racks.
Ist das der Fall kannst du ein elegantes und auch redundantes Netzwerk Design mit der vorhandenen Hardware problemlos lösen. Das könnte dann z.B. so aussehen:
Leider machst du zur Verfügbarkeit von Ports dafür keine Angaben so das man das nur als 2te Option in den Raum schmeissen kann.
die vier vorhandenen SFP-Slots stehen zur freien Verfügung.
Ja, das macht absolut Sinn die dafür zu verwenden.Für die Verbindungen innerhalb der Racks kannst du dafür preiswerte DAC/Twinax Kabel oder AOC Kabel verwenden die auch deutlich robuster sind als LC Optiken und Patchkabel.
Das 2te Design ist ausfalltechnisch etwas günstiger und solltest du bevorzugen, denn das federt dir den Ausfall eines der Switches im Verteilerraum 1 ab. Beim ersten Design ist das nicht gegeben.
Fällt da eins der Switches aus ist der gesamte daran hängende Raum betroffen. Beim Design 2 passiert das nicht!
d.h. die beiden Switche pro Raum untereinander und die jeweils einen anderen aus den anderen Räumen pro Switch.
Ja, richtig!- 2 der 10G Ports konfigurierst du als LACP LAG (Etherchannel) um die Switches untereinander im Rack redundant mit doppelter Bandbreite zu verbinden
- Jeweils einen 10G Port pro Rack Switch bringst du auf den Raum 1 Verteiler auf je einen Switch.
Wenn du pro Rack zwischen den Switches sehr wenig Traffic hast könnte man den LAG (Etherchannel) dort auch durch einen singulären Link ersetzen. Das kann man als Außenstehender aber schlecht beurteilen, da du zum Traffic Flow innerhalb der Racks leider keinerlei Angaben machst.
Hast du also viel Switch übergreifenden Traffic innerhalb der Racks wie z.B. große Backups usw. solltest du den LAG (Etherchannel) beibehalten. Ansonsten würdest du pro Rackswitch noch einen 10G Port gewinnen.
Best Practise Design:
Ideal wäre es wenn du alle vier 10G Ports vollredundant auslegen würdest. Das macht Sinn wenn es vorerst keine Erweiterungen in Bezug auf Räume oder Racks mehr geben soll, weil du dann alle 4 Ports belegst.
Das sähe dann so aus:
⚠️ ACHTUNG:
In allen der beiden o.a. Designs ist unbedingt darauf zu achten das in der Konfiguration die beiden Switches in "Raum 1" als Root und Backup Root Switches zu setzen sind im Spanning Tree!!
Andernfalls kann es passieren das die falschen Uplinks in den Blocking Mode gehen was den Daten Traffic zw. den Racks beeinträchtigt!
Das erreicht man indem man die globale PVRSTP Spanning Tree Priority in allen VLANs entsprechend anpasst:
Beim Root Switch: spanning-tree vlan <vlan-id> priority 4096
Beim Backup Root Switch: spanning-tree vlan <vlan-id> priority 8192
Wenn ich die VMWare-Server anschliesse, sollten diese über die verteilten Räume auch via LAG angebunden werden?
Nein, das ist nicht erforderlich!Zu einen weil innerhalb des Racks ein verteilter LAG sprich MLAG auf die jeweils 2 Rackswitches sinnvoll wäre aber nicht funktioniert weil die Cat 29er kein vPC (virtual Portchannel) VFS oder VSS supporten. Die Frage stellt sich also bei reinen Access Switches die eigentlich keine RZ Switches sind gar nicht erst!
Zum anderen weil das auch völlig überflüssig sind, denn VmWare benutzt einen eigenen Layer 2 Balancing Mode auf Basis der Mac Adressen was einen LAG dann so oder so völlig überflüssig macht.
Mit anderen Worten: Es ist in dem o.a. Design völlig egal wo du deine VmWare Server aufsteckst. Du kannst deren NICs nach Wahl auf jeden Switch deiner Wahl verteilen.
Idealerweise verteilt man sie pro Rack auf die 2 Top of Rack Switches in den Racks. Aber auch Rack übergreifend ist das problemlos möglich. Server LAGs sind nicht erforderlich.
Wenn es das denn nun war bitte deinen Thread hier dann auch als erledigt schliessen!