30
Umzug der Firewall und Einsatz eines Core-Switches - Tipps und Empfehlungen
Hallo zusammen,
unser Firmengelände verfügt über zwei große Hallen mit angrenzenden Büroräumen (grobe Skizze am Ende des Beitrags). Bis vor kurzem haben wir die neue Halle samt Büroräumen vermietet. Wir ziehen jetzt selbst dort ein. Wir haben den Serverraum in der neuen Halle bereits mitbenutzt, da wir mit der Firma zusammenarbeiten, die die Halle und die Büros gemietet hatte. Unsere Server usw. befinden sich bereits dort. Wir haben in der alten Halle im Serverraum noch unsere Firewall stehen. Diese muss umziehen, weil der Großteil der Bürokräfte, insbesondere die Konstrukteure, welche große CAD-Dateien öffnen und auf ein schnelles und zuverlässiges Netzwerk angewiesen sind, mit umziehen.
Unser Netzwerk ist derzeit nicht besonders redundant und besteht aus einer Vielzahl von Switchen, die nacheinander miteinander verbunden sind. Im Ausfall eines Switches haben auch alle anderen Switche, die dahinter hängen, kein Netzwerk mehr. Das muss geändert werden. Ich schlage vor, einen kleinen Switch mit 12–24 Ports (direkte Glasfaser Ports oder SFP+) als Core-Switch einzusetzen. Der interne Datenverkehr läuft weiter über die Firewall. Der Switch soll lediglich als Verteiler dienen, damit wir die elendig lange Aneinanderreihung von Switchen auflösen können. Wenn wir die Firewall umsetzten, können wir fast alle Switche direkt an den Core-Switch anschließen. Lediglich ein paar Ausnahmen lassen sich nicht vermeiden.
Umgebung:
2x Sophos XGS3100 (Master/Slave)
ca. 20 managebare 24- und 48-Port Switche (Access Switche für alle Clients)
ca. 20 managebare 8-Port Switche (in den Büros)
ca. 200 Workstations
Jetzt zu meinen Fragen:
1) Ist das ganze so überhaupt machbar uns sinnvoll? Wenn nicht, habt ihr andere Vorschläge?
2) Welchen Switch würdet ihr als Core-Switch dafür einsetzten, der genug Bandbreite hat, um alle Switche zentral anzubinden und per Glasfaser mit der Firewall verbunden ist.
Falls irgendwelche Angaben fehlen oder ihr andere Fragen habt stelle ich euch gerne alle nötigen Infos zur Verfügung.
Mit freundlichen Grüßen
tacobell03
unser Firmengelände verfügt über zwei große Hallen mit angrenzenden Büroräumen (grobe Skizze am Ende des Beitrags). Bis vor kurzem haben wir die neue Halle samt Büroräumen vermietet. Wir ziehen jetzt selbst dort ein. Wir haben den Serverraum in der neuen Halle bereits mitbenutzt, da wir mit der Firma zusammenarbeiten, die die Halle und die Büros gemietet hatte. Unsere Server usw. befinden sich bereits dort. Wir haben in der alten Halle im Serverraum noch unsere Firewall stehen. Diese muss umziehen, weil der Großteil der Bürokräfte, insbesondere die Konstrukteure, welche große CAD-Dateien öffnen und auf ein schnelles und zuverlässiges Netzwerk angewiesen sind, mit umziehen.
Unser Netzwerk ist derzeit nicht besonders redundant und besteht aus einer Vielzahl von Switchen, die nacheinander miteinander verbunden sind. Im Ausfall eines Switches haben auch alle anderen Switche, die dahinter hängen, kein Netzwerk mehr. Das muss geändert werden. Ich schlage vor, einen kleinen Switch mit 12–24 Ports (direkte Glasfaser Ports oder SFP+) als Core-Switch einzusetzen. Der interne Datenverkehr läuft weiter über die Firewall. Der Switch soll lediglich als Verteiler dienen, damit wir die elendig lange Aneinanderreihung von Switchen auflösen können. Wenn wir die Firewall umsetzten, können wir fast alle Switche direkt an den Core-Switch anschließen. Lediglich ein paar Ausnahmen lassen sich nicht vermeiden.
Umgebung:
2x Sophos XGS3100 (Master/Slave)
ca. 20 managebare 24- und 48-Port Switche (Access Switche für alle Clients)
ca. 20 managebare 8-Port Switche (in den Büros)
ca. 200 Workstations
Jetzt zu meinen Fragen:
1) Ist das ganze so überhaupt machbar uns sinnvoll? Wenn nicht, habt ihr andere Vorschläge?
2) Welchen Switch würdet ihr als Core-Switch dafür einsetzten, der genug Bandbreite hat, um alle Switche zentral anzubinden und per Glasfaser mit der Firewall verbunden ist.
Falls irgendwelche Angaben fehlen oder ihr andere Fragen habt stelle ich euch gerne alle nötigen Infos zur Verfügung.
Mit freundlichen Grüßen
tacobell03
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 668243
Url: https://administrator.de/contentid/668243
Ausgedruckt am: 26.09.2024 um 22:09 Uhr
30 Kommentare
Neuester Kommentar
Besser wäre in so einem Falle immer ein redundantes Netzwerk zu realisieren. Firmennetze mit deinen o.a. Anforderungen im CAD Bereich heutzutage ohne Redundanz zu planen oder umzusetzen ist eigentlich ein laienhaftes NoGo, da ihr von der Verfügbarkeit des Netzes wirtschaftlich vollständig abhängig seit.
Die Switchfrage ist, wie leider üblich, wieder einmal völlig sinnfrei, weil du rein gar nichts zu den technischen Anforderungen der Switches z.B. Stacking, L3, .1x Port Security, red. Netzteil usw. usw noch zum Budget gesagt hast. Zielführend kann niemand sowas ohne diese Rahmenbedingungen zu kennen sinnvoll beantworten.
Weisst du (hoffentlich) auch selber...?!
Ein übliches Allerwelts Standarddesign sieht so aus:
Die Switchfrage ist, wie leider üblich, wieder einmal völlig sinnfrei, weil du rein gar nichts zu den technischen Anforderungen der Switches z.B. Stacking, L3, .1x Port Security, red. Netzteil usw. usw noch zum Budget gesagt hast. Zielführend kann niemand sowas ohne diese Rahmenbedingungen zu kennen sinnvoll beantworten.
Weisst du (hoffentlich) auch selber...?!Ein übliches Allerwelts Standarddesign sieht so aus:
3
Es gibt schöne Spine Leaf Konzepte.
Ein einzelnes Core Switch ist auch wieder ein Single Point of Failure. N+1 CS an verschiedenen Orten sollte eine Prüfung wert sein.
Die Masse der CAD Programme profitiert nicht von Bandbreite. Hier hilft ein Storage Protokoll im Ethernet am günstigsten weiter.
Ein einzelnes Core Switch ist auch wieder ein Single Point of Failure. N+1 CS an verschiedenen Orten sollte eine Prüfung wert sein.
Die Masse der CAD Programme profitiert nicht von Bandbreite. Hier hilft ein Storage Protokoll im Ethernet am günstigsten weiter.
1
Moin,
du redest von Redundanz und planst dann schon wieder nur "einen" Core Switch?
Zieh es wenn dann richtig durch.
Gruß
Spirit
du redest von Redundanz und planst dann schon wieder nur "einen" Core Switch?
Zieh es wenn dann richtig durch.
Gruß
Spirit
1
Hi,
wäre noch die Frage nach dem VLan ....
Wenn keins da, bitte einrichten.
Gr.
wäre noch die Frage nach dem VLan ....
Wenn keins da, bitte einrichten.
Gr.
Hi,
@aqui hat ja schon grob gezeigt wie das generelle Design aussehen sollte.
ich habe aber noch ein paar Fragen um ggf. einw mögliches Umsetzung vorschlagen zu können.
Ich nehme an, daß zwischen Serverräumen und den Büros eine gute Kupfer Netzwerverkabelung vorhanden ist (CAT6/6a/7 und =<95m, alles eingemessen).
- wie und mit welcher Bandbreite sind die Storages und Server im Netzwerk angeschlossen ?
- welche Verkabelung habt ihr zwischen beiden Hallen, welche Distanz ist zwischen den zwei Serverräumen ?
- kann ggf. noch OM4 oä. zwischen den Hallen nachverlegt werden.
- wieviele Netzwerkdosen müssen in Halle 1 und 2 von den Switchen versorgt werden ?
- welches Budget habt ihr zur Verfügung.
Gruß
CH
@aqui hat ja schon grob gezeigt wie das generelle Design aussehen sollte.
ich habe aber noch ein paar Fragen um ggf. einw mögliches Umsetzung vorschlagen zu können.
Ich nehme an, daß zwischen Serverräumen und den Büros eine gute Kupfer Netzwerverkabelung vorhanden ist (CAT6/6a/7 und =<95m, alles eingemessen).
- wie und mit welcher Bandbreite sind die Storages und Server im Netzwerk angeschlossen ?
- welche Verkabelung habt ihr zwischen beiden Hallen, welche Distanz ist zwischen den zwei Serverräumen ?
- kann ggf. noch OM4 oä. zwischen den Hallen nachverlegt werden.
- wieviele Netzwerkdosen müssen in Halle 1 und 2 von den Switchen versorgt werden ?
- welches Budget habt ihr zur Verfügung.
Gruß
CH
1
Servus,
also in erster Linie sollte ein schickes PDM System Einklang finden. So kann die Konstruktion auch eine ganze Zeit ohne aktives Netzwerk weiterarbeiten, mal abgesehen von den vielen Annehmlichkeiten wie Revision, Cold-Storage, Rechteverwaltung, Offline-Modus, Referenzen und Metadaten-Suche. ;)
Die Frage mit einer sinnvollen Antwort zu beantworten ist meines Erachtens nach schwierig. Sinnvoll ist das, was ihr als Anspruch habt und technisch umsetzt.
Geht es wirklich um Redundanz? Ich habe teilweise Kunden die bewusst darauf verzichten und sich dessen bewusst sind, wenn ein Gerät/Dienst ausfällt, damit leben zu müssen. Andere Kunden wiederum haben schon fast Panik in den Augen, wenn die daran denken das ein Konstrukteur mal 30 Minuten nicht arbeiten kann.
Anyway, die in Reihe geschalteten Switche würde ich auf jeden Fall in einer neuen Halle eliminieren und diese zu mindestens an einem Punkt ankommen lassen. Ist das erledigt würde ich mir Gedanken über die Segmentierung des Netzwerkes machen. Und wenn wenigstens Gäste-WLAN schon "rausgelöst" wird.
Cheers
also in erster Linie sollte ein schickes PDM System Einklang finden. So kann die Konstruktion auch eine ganze Zeit ohne aktives Netzwerk weiterarbeiten, mal abgesehen von den vielen Annehmlichkeiten wie Revision, Cold-Storage, Rechteverwaltung, Offline-Modus, Referenzen und Metadaten-Suche. ;)
Die Frage mit einer sinnvollen Antwort zu beantworten ist meines Erachtens nach schwierig. Sinnvoll ist das, was ihr als Anspruch habt und technisch umsetzt.
Geht es wirklich um Redundanz? Ich habe teilweise Kunden die bewusst darauf verzichten und sich dessen bewusst sind, wenn ein Gerät/Dienst ausfällt, damit leben zu müssen. Andere Kunden wiederum haben schon fast Panik in den Augen, wenn die daran denken das ein Konstrukteur mal 30 Minuten nicht arbeiten kann.
Anyway, die in Reihe geschalteten Switche würde ich auf jeden Fall in einer neuen Halle eliminieren und diese zu mindestens an einem Punkt ankommen lassen. Ist das erledigt würde ich mir Gedanken über die Segmentierung des Netzwerkes machen. Und wenn wenigstens Gäste-WLAN schon "rausgelöst" wird.
Cheers
Moin @Trinatrium,
wenn es ein richtiger Core Switch ist, also ein HA Gerät, dann sicher nicht.
Ja, die Bandbreite eines Netzwerks ist bei den meisten CAD-Anwendungen eher zweitrangig, eine so gering wie mögliche Latenz, ist meiner Erfahrung nach, jedoch bei so gut wie allen Fällen sehr wichtig.
Das gilt übrigens nicht nur für CAD Anwendungen, sondern auch für die meisten CRM, ERP, DMS & Co Systeme, die mir bisher über den Weg gelaufen sind.
Gruss Alex
Ein einzelnes Core Switch ist auch wieder ein Single Point of Failure.
wenn es ein richtiger Core Switch ist, also ein HA Gerät, dann sicher nicht.
Die Masse der CAD Programme profitiert nicht von Bandbreite. Hier hilft ein Storage Protokoll im Ethernet am günstigsten weiter.
Ja, die Bandbreite eines Netzwerks ist bei den meisten CAD-Anwendungen eher zweitrangig, eine so gering wie mögliche Latenz, ist meiner Erfahrung nach, jedoch bei so gut wie allen Fällen sehr wichtig.
Das gilt übrigens nicht nur für CAD Anwendungen, sondern auch für die meisten CRM, ERP, DMS & Co Systeme, die mir bisher über den Weg gelaufen sind.
Gruss Alex
Moin @simple198,
das nennt sich in der Fachsprache glaube ich "IT-Hypochondrie". 🤪
Das Problem lässt sich jedoch mit etwas Logik lösen, meistens zumindest. 🙃
Denn, wenn die Verantwortlichen mal realisieren, dass man hier von einem Risiko spricht, sprich, Switch "raucht" warum auch immer ab, welches bei ordentlichen Switchen höchstens alle 10 Jahre vorkommt, wird die Sachen meiner Erfahrung nach, meistens auch recht schnell viel entspannter.
Gruss Alex
Andere Kunden wiederum haben schon fast Panik in den Augen, wenn die daran denken das ein Konstrukteur mal 30 Minuten nicht arbeiten kann.
das nennt sich in der Fachsprache glaube ich "IT-Hypochondrie". 🤪
Das Problem lässt sich jedoch mit etwas Logik lösen, meistens zumindest. 🙃
Denn, wenn die Verantwortlichen mal realisieren, dass man hier von einem Risiko spricht, sprich, Switch "raucht" warum auch immer ab, welches bei ordentlichen Switchen höchstens alle 10 Jahre vorkommt, wird die Sachen meiner Erfahrung nach, meistens auch recht schnell viel entspannter.
Gruss Alex
1
Definiere HA. Hier laufen Leute rum, die bauen Stacks in den Core.
1
Hi,
aquis Bild sagt eigentlich alles aus. Mach es so und gut ist.
Guck aber bitte das der Core Switch (der redundant aus 2 Switches besteht!) auch 2 Netzteile hat, das halte ich für wichtig.
Eines davon an das Stromnetz und das andere an eine USV.
Das entspannt nicht nur beim Stromausfall, sondern auch wenn ein Netzteil ausfällt.
Auch sollte der Switch nicht der billigste sein, also die üblichen Verdächtigen wie Cisco, Ruckus, Juniper, Zyxel, Netgear, HP, ... (nein, das ist keine Reihenfolge, und jetzt bitte auch keine Post wer besser oder schlechter ist)
24 Port SFP+ (10G) sollte passen, der Stack Link zwischen den beiden Switches >25G
Viele Grüße
Deepsys
aquis Bild sagt eigentlich alles aus. Mach es so und gut ist.
Guck aber bitte das der Core Switch (der redundant aus 2 Switches besteht!) auch 2 Netzteile hat, das halte ich für wichtig.
Eines davon an das Stromnetz und das andere an eine USV.
Das entspannt nicht nur beim Stromausfall, sondern auch wenn ein Netzteil ausfällt.
Auch sollte der Switch nicht der billigste sein, also die üblichen Verdächtigen wie Cisco, Ruckus, Juniper, Zyxel, Netgear, HP, ... (nein, das ist keine Reihenfolge, und jetzt bitte auch keine Post wer besser oder schlechter ist)
24 Port SFP+ (10G) sollte passen, der Stack Link zwischen den beiden Switches >25G
Viele Grüße
Deepsys
Ja, die Bandbreite eines Netzwerks ist bei den meisten CAD-Anwendungen eher zweitrangig, eine so gering wie mögliche Latenz, ist meiner Erfahrung nach, jedoch bei so gut wie allen Fällen sehr wichtig.
Muss ich widersprechen. Im Fall eines PDM-System für die CAD Anwendungen können diese auch offline und temporär lokal weiter arbeiten. Mit allem was dazu gehört (Lizenz, Dateien, Vorlagen, sogar fortlaufende Nummern sind möglich).
Das gilt übrigens nicht nur für CAD Anwendungen, sondern auch für die meisten CRM, ERP, DMS & Co Systeme, die mir bisher über den Weg gelaufen sind.
Wichtig, meine Aussage oben bezieht sich auf ein PDM-System. ERP und CRM ist da eine andere Nummer.
aquis Bild sagt eigentlich alles aus. Mach es so und gut ist.
Uff, die Aussage finde ich zu pauschal. Der TO muss meines Erachtens nach die Anforderung genauer definieren. Also nicht unbedingt hier, aber mit der GF/IT/CAD, usw. Vergleich mit folgender Aussage:
ordentlichen Switchen höchstens alle 10 Jahre vorkommt,
Ist ein Ausfall so gering, dann lohnt sich meines Erachtens nach der Kostenaufwand nicht um dieses Minimal Risiko noch abzufangen. Konfig, Anschaffung und die Wartung sind dann unproportional zum Nutzen.
Dann kann man doch eher überlegen die Switch nach 7/8 Jahren rauszuwerfen oder man lebt dann mit einem Ausfall...
Allerdings gehe ich jetzt nicht von in Reihe geschaltete Switche aus. Grundprinzip ist schon ein "Core-Switch" mit der oben genannten Abwägung.
Zitat von @Deepsys:
Hi,
aquis Bild sagt eigentlich alles aus. Mach es so und gut ist.
Viele Grüße
Deepsys
Hi,
aquis Bild sagt eigentlich alles aus. Mach es so und gut ist.
Viele Grüße
Deepsys
"Klassisches Design" im Jahr 2024? Ernsthaft?
Dann noch ein LACP LAG, im Core zum verbinden der beiden des Coreswitchs untereinander? Dann noch VRRP oder HSRP usw?
Sorry, aber da läuten alle Glocken, auch die roten Glocken für Alarm.
Überall wo etwas Ahnung vorhanden ist, im Großen im Kleinen, wird man so etwas nicht implementieren.
Wenn ich proprietäre Techniken einsetze, dann setze ich sie ein und leben damit. Wenn ich auf übergreifende Standards setze, dann baue ich keine solche Konstruktion.
1die bauen Stacks in den Core...
Was ja dann zweifelsohne HA wäre! 
Ein Stack ist definitionsbedingt nicht HA. Stacks gibt es hin und wieder aus historischen Gründen am Edge. Aber nicht im Core.
Und wer das da platziert, dem ist aus anderen Gründen nicht zu helfen.
Das einfachste wäre, mal eine Referenz zu zeigen, nicht die eigene, in der jemand ein Stack im Core platziert. Kannst Du das liefern?
Und wer das da platziert, dem ist aus anderen Gründen nicht zu helfen.
Das einfachste wäre, mal eine Referenz zu zeigen, nicht die eigene, in der jemand ein Stack im Core platziert. Kannst Du das liefern?
Stack im Core und dann am besten VSAN drüber. Herzliches Beileid 🤣
1Ein Stack ist definitionsbedingt nicht HA.
Da bist du mit deiner Meinung aber recht einsam auf weiter Flur. Das Gros der etablierten Hersteller sieht das wohl etwas anders.Sofern die Stack Member redundante Netzteile haben und die Stack Links als Trunks im Daisy Chaining verkabelt sind inkl. dual active Detection über einen physisch, separaten Link, was genau ist daran d. M. nicht HA? 3facher Gürtel mit 3fachem Hosenträger.
Gut, du zielst vermutlich auf die ISSU Fähigkeit im Stack bei einem Major Firmware Upgrade ab?! Da trennt sich dann in der Tat die Spreu vom Weizen. Zu mindestens bei den einfachen Massenherstellern. Im Premium Segment ist das durch entsprechende FW Virtualisierung aber abgefangen und klappt hitless.
Ist es immer noch nicht HA, was wäre denn die "wirkliche" HA Alternative? Trill, SPB oder MLAG und VRRPe? IP Fabric m. BGP EVPN? Ein dicker Chassis Switch mit doppelten Einschüben? Bleibt ja nicht mehr viel...
Stacking ist im Access Bereich okay. Aber im Core oder Datencenter wird es spätestens beim Update zum Problem weil dadurch alle Member im worst case weg sind. Dann bringt mir aller HA nix.
Daher sehe ich dort Technologien wir VRF oder wie sie es halt alle nennen. Kurz um wird dann alles per MLAG auf multi-Chassi angebunden.
Mein VSAN Beispiel beim strecht Cluster ist da ideal!
Daher sehe ich dort Technologien wir VRF oder wie sie es halt alle nennen. Kurz um wird dann alles per MLAG auf multi-Chassi angebunden.
Mein VSAN Beispiel beim strecht Cluster ist da ideal!
spätestens beim Update
Nein, kommt eben, wie immer, auf den Hersteller und natürlich auf das Design an. Aber auch nüchtern betrachtet supporten Midrange Hersteller in der Regel zumindestens den Minor Patch immer hittless ohne Ausfall. Major Release Wechsel kommen alle 3-5 Jahre vor. In dem Zeitraum muss man Winblows, ESXi und Co. sicher 5mal oder mehr updaten/rebooten und kann das Wartungszeitfenster dann auch im Core sinnvoll nutzen sofern man keine HW betreibt die nicht ISSU fähig ist.
Aber jeder sieht das natürlich entsprechend anders wo seine Prioritäten liegen, keine Frage. Stacks im Core generell zu verteufeln ohne das man ein paar Worte übers Design verliert ist aber schon lange nicht mehr state of the art. Auch Stacks kann man per MLAG und VRRP oder Routing ISSU konform verbinden. Zumal es ja auch nicht sehr viele Alternativen gibt.
@aqui selbst Cisco bekommt das nur mit teuren Zusatz Features ansatzweise seemless hin 😉
Mir wollte niemand versichern das ein VSAN dabei nicht drauf geht!
Mir wollte niemand versichern das ein VSAN dabei nicht drauf geht!
@aqui Du sollst einen Praxisfall nennen. Wo wird sowas aufgebaut und betrieben. Außer außerhalb von deinem Kopf und der peinlichen Show hier!
Wo, in Zeiten von disaggregierten Netzwerken, baut sich jemand diese Bandbreiten- und Invest-Leiche auf?
Wo, in Zeiten von disaggregierten Netzwerken, baut sich jemand diese Bandbreiten- und Invest-Leiche auf?
Zitat von @Trinatrium:
@aqui Du sollst einen Praxisfall nennen. Wo wird sowas aufgebaut und betrieben. Außer außerhalb von deinem Kopf und der peinlichen Show hier!
Bei uns.@aqui Du sollst einen Praxisfall nennen. Wo wird sowas aufgebaut und betrieben. Außer außerhalb von deinem Kopf und der peinlichen Show hier!
Core Update ist kein Problem, da Ruckus ISSU booten die Switche der Reihe nach durch und da alles per LACP angebunden ist, klappt das auch
Wo, in Zeiten von disaggregierten Netzwerken, baut sich jemand diese Bandbreiten- und Invest-Leiche auf?
Bei Mittelständlern die nicht die 100G Switche kaufen können?Zeigt doch bitte mal im detail auf wie du das lösen würdest OHNE alle Switche neu zu kaufen.
Das könnten dem TO helfen
Da wo die Fasern/Kabel sich häufen die Spine-Switches platzieren? Alles andere Leaf Switches? Muss ja, auf Grund der Topologie kein symmetrisches Pfadsetup sein. Das kostet maximal 1/4 des Blödsinns von dem Bild oben und ist Up to Date.
Und das geht auch mit 1/10GBit. Keine Ahnung wie Du auf 100GBit kommst.
Ich sehe im Core, zwischen den Core-Switches, ein LACP über einem LAG. Sorry, aber das kann man nicht ernst nehmen. Besonders nicht weil dann Features aufgezählt werden von Switches die pro Stück Zehntausende kosten um dann eine Abgrenzung zu "Massenhersteller" zu propagieren. Das ist wirklich maximal abnorm.
Und auch der Hinweis auf VSAN scheint nicht inhaltlich durchgedrungen zu sein. Dabei ist VSAN das Beispiel, was jeder Vertriebler kennt und jeder Networker zu berücksichtigen weiß. Deshalb zeigt es die Schwäche des 3-Tier überdeutlich auf. Das betrifft aber viele weitere Fallstricke genau so.
Ich will auch noch mal in Erinnerung bringen, dass der TO eine Switch-Kette hat. Als Lösungsansatz kommt dann unter anderem ein 3-Tier Enterprise Setup und in der Detailerklärung werden dann noch Features aufgezählt, die in der Kombination keinen Sinn ergeben und zusätzlich die ganze Sache noch mal im Preis mindestens verdoppeln.
Also lieber TO, du wirst auch mit 100k nicht hinkommen, weil Du ein 2004-Setup braucht für deine durchschnittlichen 15MBit over all Ports.
Das Schicksal fast jeder Diskussion ist hier so. Und nur ein paar merken überhaupt wie absurd das ist.
Und das geht auch mit 1/10GBit. Keine Ahnung wie Du auf 100GBit kommst.
Ich sehe im Core, zwischen den Core-Switches, ein LACP über einem LAG. Sorry, aber das kann man nicht ernst nehmen. Besonders nicht weil dann Features aufgezählt werden von Switches die pro Stück Zehntausende kosten um dann eine Abgrenzung zu "Massenhersteller" zu propagieren. Das ist wirklich maximal abnorm.
Und auch der Hinweis auf VSAN scheint nicht inhaltlich durchgedrungen zu sein. Dabei ist VSAN das Beispiel, was jeder Vertriebler kennt und jeder Networker zu berücksichtigen weiß. Deshalb zeigt es die Schwäche des 3-Tier überdeutlich auf. Das betrifft aber viele weitere Fallstricke genau so.
Ich will auch noch mal in Erinnerung bringen, dass der TO eine Switch-Kette hat. Als Lösungsansatz kommt dann unter anderem ein 3-Tier Enterprise Setup und in der Detailerklärung werden dann noch Features aufgezählt, die in der Kombination keinen Sinn ergeben und zusätzlich die ganze Sache noch mal im Preis mindestens verdoppeln.
Also lieber TO, du wirst auch mit 100k nicht hinkommen, weil Du ein 2004-Setup braucht für deine durchschnittlichen 15MBit over all Ports.
Das Schicksal fast jeder Diskussion ist hier so. Und nur ein paar merken überhaupt wie absurd das ist.
Zitat von @Trinatrium:
Da wo die Fasern/Kabel sich häufen die Spine-Switches platzieren? Alles andere Leaf Switches? Muss ja, auf Grund der Topologie kein symmetrisches Pfadsetup sein. Das kostet maximal 1/4 des Blödsinns von dem Bild oben und ist Up to Date.
Da wo die Fasern/Kabel sich häufen die Spine-Switches platzieren? Alles andere Leaf Switches? Muss ja, auf Grund der Topologie kein symmetrisches Pfadsetup sein. Das kostet maximal 1/4 des Blödsinns von dem Bild oben und ist Up to Date.
Ähm, das ist doch das Gleiche wie in aquis Bild ....
Nur das du die Core-Switche Spine nennst und die Access Leaf
Aqui hat auch kein klassisches 3-Tier, weil dort der Distribution Switch (der hier nicht nötig ist) fehlt.
Der TO braucht zwei neue Switche die Stacking beherrschen, bindet die Access im Stern per LACP (=LAG) ein und ist fertig. Das ist zumindest mein Lösungsvorschlag.
Damit bin ich hier raus und wünsche allen einen schönen Rest-Sonntag
Nein ist es nicht. Aber ja, es ist Sonntag.
Moin @Trinatrium,
na ja HA (High Availability / Hochverfügbarkeit) lässt sich im Netzwerk grundsätzlich auf unterschiedlichen Wegen realisieren. Unter einem HA-Core-Switch, verstehe ich persönlich jedoch mindesten ein Gerät der folgenden Kategorie ...
https://www.arubanetworks.com/de/products/switches/access/5400r-series/
... sprich, EIN Gerät, welches selbst auf HA ausgelegt ist.
Stacking ist Stacking und ein Core Switch ist ein Core Switch.
Gruss Alex
Definiere HA.
na ja HA (High Availability / Hochverfügbarkeit) lässt sich im Netzwerk grundsätzlich auf unterschiedlichen Wegen realisieren. Unter einem HA-Core-Switch, verstehe ich persönlich jedoch mindesten ein Gerät der folgenden Kategorie ...
https://www.arubanetworks.com/de/products/switches/access/5400r-series/
... sprich, EIN Gerät, welches selbst auf HA ausgelegt ist.
Hier laufen Leute rum, die bauen Stacks in den Core.
Stacking ist Stacking und ein Core Switch ist ein Core Switch.
Gruss Alex
Schön gesagt, aber nicht jeder hält das so einfach.
Wir haben doch gelesen dass man z. B. ein Stack hat und das ISSU auch updatet. Um die Folgen abzumildern scheint man ein weiteres Stack zu haben und "rettet" sich mit LAGs.
Ich liege dann vor Lachen schon am Boden und Frage mich, was mit z. B. SVL oder vergleichbar ist. Das ist slapstickartige IT-Komik in der IT Werkstatt der Lebenshilfe.
Oder anders ausgedrückt, warum baue ich mir kombiniert alle Nachteile ein, nur weil es mit etwas Kreativität sich kombinieren lässt?
Gleich kommt noch jemand, der seine Jumboframes durch die L3-Ebene des 3-Tier-Design lokal routet, aus "Sicherheitsgründen" usw... usw...
Ich z.b verstehe unter einem Core Switch ein Switch mit enormer Forward-Leistung ohne (nennenswerten) Impact auf die Latenz.
Das CS muss noch nicht mal zwingend L3 können.
Währendessen Leaf Switches, gerne ToR alles im Rack verbinden und möglichst viel Forward auch im Rack lassen, außer er wird rackübergreifend benötigt, was nach Traffic-Art zu unterscheiden und bewerten wäre.
Redundanz in Form von Stromversorgungen, Pfaden, Backplanes usw... Ist noch mal ein Thema für sich.
Aber redundante Hardwares vorzuhalten um sie dann mit einem LACP zu verbinden: rofl
Das kann man nur noch steigern in dem man Stacks per LACP bündelt.
Deepsys 22.09.2024 aktualisiert um 18:10:49 Uhr
Zitat von @Trinatrium:
@aqui Du sollst einen Praxisfall nennen. Wo wird sowas aufgebaut und betrieben. Außer außerhalb von deinem Kopf und der peinlichen Show hier!
Bei uns.
Core Update ist kein Problem, da Ruckus ISSU booten die Switche der Reihe nach durch und da alles per LACP angebunden ist, klappt das auch
Zitat von @Trinatrium:
@aqui Du sollst einen Praxisfall nennen. Wo wird sowas aufgebaut und betrieben. Außer außerhalb von deinem Kopf und der peinlichen Show hier!
Bei uns.
Core Update ist kein Problem, da Ruckus ISSU booten die Switche der Reihe nach durch und da alles per LACP angebunden ist, klappt das auch
Mag man von ausgehen. Aber die Realität sieht so aus, dass es dir niemand versichert.
Das Problem fängt an, wenn der erste Switch ggf. noch nicht 100% wieder da ist und dann der nächste weg bricht. Damit ist der tot vom VSAN geboren. (klar ein richtiges Wittness Setup mal außen vor. Aber auch das bringt ja nichts wenn alles über einen Stack läuft)
Ich spreche hier aus Erfahrung und löse das gerade genau so ab!
Habe ich hingehen einen VRF Cluster, so kann ich ohne Probleme im live Betrieb einen Switch nach dem anderen standalone updaten.
Sowas geht ja als Beispiel mit den Cisco Nexus Geräte super. Daher sind die ja auch für den Datacenter Betrieb.
Schlussendlich können wir uns hier auch streiten.
Mir ist es auch egal was der TO später macht. Ich zeig nur die Probleme auf.
Ein Wald und Wiesen Stack mag zu 99% der Zeit laufen. Bis es Bspw. mein beschriebenes Problem gibt.
Im blödesten Fall lässt sich der Stack nicht updaten, da es z.B. unmöglich ist eine Downtime dafür zu generieren. Wieder VSAN, denn was ist wenn der Cluster überbucht ist und daher keine Downtime ohne herunterfahren der meisten Ressourcen möglich ist?
Aber hier ist dann der nächste Streitpunkt. Wie viel HA oder besser Uptime braucht der TO denn?
Ihr könnt euch da gerne Stacks rein schrauben. Ich werde das nicht mehr machen. Und wenn doch, lasss ich mir die Konsequenzen bei der GF bescheinigen und es ist nicht mehr mein Problem.
Mir ist es auch egal was der TO später macht. Ich zeig nur die Probleme auf.
Ein Wald und Wiesen Stack mag zu 99% der Zeit laufen. Bis es Bspw. mein beschriebenes Problem gibt.
Im blödesten Fall lässt sich der Stack nicht updaten, da es z.B. unmöglich ist eine Downtime dafür zu generieren. Wieder VSAN, denn was ist wenn der Cluster überbucht ist und daher keine Downtime ohne herunterfahren der meisten Ressourcen möglich ist?
Aber hier ist dann der nächste Streitpunkt. Wie viel HA oder besser Uptime braucht der TO denn?
Ihr könnt euch da gerne Stacks rein schrauben. Ich werde das nicht mehr machen. Und wenn doch, lasss ich mir die Konsequenzen bei der GF bescheinigen und es ist nicht mehr mein Problem.
Nehmen wir mal speziell den Fall VSAN.
Im Rack sind in der Regel zwei ToR Switches, die nicht gestackt sind. In größeren Umgebungen nutzt man ggf noch Switches des Nachbar-Racks.
Und, jetzt kommt das UND: VSAN Traffic is L2 Traffic, das das Leaf gar nicht verlässt bzw nur L2-Uplinks hätte, falls es ein Ethernet Storage gebe. L3 VSAN geht zwar, aber bringt viele weitere Besonderheiten die nicht nur den Layer 3 betreffen.
Ich würde aber nicht mal so weit gehen, sondern erstmal gucken welche Eier ich mir bei den Basis in den Korb lege: Z.B. STP.
Coreswitches mit LAG, Server im Access mit LAG und dann noch STP drüber. Dabei von Switches philosophieren die mehrpfadig redundant arbeiten könnten ohne STP, aber Designs in Bilder malen die alle Nachteile vereinen auf Hardware die das nicht nötig hat.
Das verrückte ist, das man sich Admin Forum nennt...
@Spirit-of-Eli: Hatten wir doch schon. Stacks haben vielleicht am Edge als Access eine Daseinsberechtigung. Aber in Zeiten von SDN bringt das dort auch keine Punkte.
Im Rack sind in der Regel zwei ToR Switches, die nicht gestackt sind. In größeren Umgebungen nutzt man ggf noch Switches des Nachbar-Racks.
Und, jetzt kommt das UND: VSAN Traffic is L2 Traffic, das das Leaf gar nicht verlässt bzw nur L2-Uplinks hätte, falls es ein Ethernet Storage gebe. L3 VSAN geht zwar, aber bringt viele weitere Besonderheiten die nicht nur den Layer 3 betreffen.
Ich würde aber nicht mal so weit gehen, sondern erstmal gucken welche Eier ich mir bei den Basis in den Korb lege: Z.B. STP.
Coreswitches mit LAG, Server im Access mit LAG und dann noch STP drüber. Dabei von Switches philosophieren die mehrpfadig redundant arbeiten könnten ohne STP, aber Designs in Bilder malen die alle Nachteile vereinen auf Hardware die das nicht nötig hat.
Das verrückte ist, das man sich Admin Forum nennt...
@Spirit-of-Eli: Hatten wir doch schon. Stacks haben vielleicht am Edge als Access eine Daseinsberechtigung. Aber in Zeiten von SDN bringt das dort auch keine Punkte.
Trinatrium 22.09.2024 aktualisiert um 20:07:28 Uhr
Nehmen wir mal speziell den Fall VSAN.
Im Rack sind in der Regel zwei ToR Switches, die nicht gestackt sind. In größeren Umgebungen nutzt man ggf noch Switches des Nachbar-Racks.
Und, jetzt kommt das UND: VSAN Traffic is L2 Traffic, das das Leaf gar nicht verlässt bzw nur L2-Uplinks hätte, falls es ein Ethernet Storage gebe. L3 VSAN geht zwar, aber bringt viele weitere Besonderheiten die nicht nur den Layer 3 betreffen.
Ich würde aber nicht mal so weit gehen, sondern erstmal gucken welche Eier ich mir bei den Basis in den Korb lege: Z.B. STP.
Coreswitches mit LAG, Server im Access mit LAG und dann noch STP drüber. Dabei von Switches philosophieren die mehrpfadig redundant arbeiten könnten ohne STP, aber Designs in Bilder malen die alle Nachteile vereinen auf Hardware die das nicht nötig hat.
Das verrückte ist, das man sich Admin Forum nennt...
Nehmen wir mal speziell den Fall VSAN.
Im Rack sind in der Regel zwei ToR Switches, die nicht gestackt sind. In größeren Umgebungen nutzt man ggf noch Switches des Nachbar-Racks.
Und, jetzt kommt das UND: VSAN Traffic is L2 Traffic, das das Leaf gar nicht verlässt bzw nur L2-Uplinks hätte, falls es ein Ethernet Storage gebe. L3 VSAN geht zwar, aber bringt viele weitere Besonderheiten die nicht nur den Layer 3 betreffen.
Ich würde aber nicht mal so weit gehen, sondern erstmal gucken welche Eier ich mir bei den Basis in den Korb lege: Z.B. STP.
Coreswitches mit LAG, Server im Access mit LAG und dann noch STP drüber. Dabei von Switches philosophieren die mehrpfadig redundant arbeiten könnten ohne STP, aber Designs in Bilder malen die alle Nachteile vereinen auf Hardware die das nicht nötig hat.
Das verrückte ist, das man sich Admin Forum nennt...
Was möchtest du mit dem Text erreichen?
@Spirit-of-Eli: Hatten wir doch schon. Stacks haben vielleicht am Edge als Access eine Daseinsberechtigung. Aber in Zeiten von SDN bringt das dort auch keine Punkte.
Ja, aber scheint ja dennoch für viele nicht wichtig genug zu sein.
1
