redundante verbinding met switches

[lazybones]

Korte situatieschets:

Ik heb een aantal computers en laptops welke zijn verbonden met twee switches.
Een stuk verderop staan servers in een aparte ruimte welke op één switch zijn aangesloten.
Situatie is nu als volgt:



Duidelijk is dat er geen enkele vorm van redundantie is . . . in een poging dat te verbeteren dacht ik aan een 2e switch aan de rechterkant zodat de servers dubbel aangesloten kunnen worden. Ik dacht er verder aan om de switches aan de linkerkant elk met een verbinding naar beide andere switches rechts te koppelen , maar ben bang dat je dan loops krijgt.

Ik heb gepoogd me hier een beetje op in te lezen v.w.b. de nodig instellingen, maar ik kom verschillende scenario's tegen waarin de methode van de ene juist weer ontraden wordt bij een ander. Daarnaast zijn sommige scenario's gemaakt met een heel andere categorie switches waarbij de gebruikte functionaliteit niet in de huidige switches aanwezig is. Ik zie even door de bomen het bos niet meer

Kan iemand verduidelijken op welke manier ik enige vorm van redundantie kan aanbrengen hier? Uitgaande van een 2e switch aan de rechterkant die er bij geplaatst moet worden.

Tussen beide ruimtes zijn nog 2 ongebruikte cat.5E kabels beschikbaar naast de exemplaren die in bovenstaand plaatje al in gebruik zijn.

[Cpt_ZakLamP]

Ik denk dat je zoekt naar 'Spanning tree'

[plizz]

Je kunt gerust aan de rechterkant een switch plaatsen. Spanning-tree functie op de switches zal dan een of twee poorten blocken om loops te verkomen.

[Glashelder]

Die 1910-48G switches ondersteunen toch IRF? Daarmee kan je switches in een ring hangen waarbij beiden paden actief gebruikt wordt kunnen worden, in tegenstelling tot met Spanning Tree.

Zo'n opstelling gebruiken wij hier (alleen met HP A5800 switches en 10G).

[ Voor 16% gewijzigd door Glashelder op 12-11-2014 14:32 ]

[lazybones]

Dank voor de reacties tot nog toe!

Is er ook een mogelijkheid om alle paden/poorten te gebruiken zodat je meer bandbreedte hebt in plaats van blocking door Spanning Tree ?

Moet ik de connecties tussen de switches nog instellen als trunk of speciaal type ?

[HollowGamer]

Dat ligt aan het protocol: OSPF, RIP, etc.

[Bigs]

Glashelder schreef op woensdag 12 november 2014 @ 14:31:
Die 1910-48G switches ondersteunen toch IRF? Daarmee kan je switches in een ring hangen waarbij beiden paden actief gebruikt wordt kunnen worden, in tegenstelling tot met Spanning Tree.

Zo'n opstelling gebruiken wij hier (alleen met HP A5800 switches en 10G).

De stacking functionaliteit van de 1910 heet wel IRF, maar dit is niet dezelfde technologie als op HP's duurdere switches als de A5800. Toen deze switches gerebrand werden van 3com 2952 naar HP 1910 heeft HP het 'Simple Stacking' menu hernoemd naar 'IRF' De 1910 heeft dus geen features als aggegration over meerdere switches.

[Paul]

Die 1810 ondersteunt het (afaik) helaas niet, maar je zoekt dus eigenlijk switches die je in een stack kunt zetten. Dan zou je naar pricewatch: HP Procurve 2920-24G Switch + pricewatch: HP Procurve 2920 2-Port Stacking module moeten (bij HP): http://pro-networking-h17...tches/selector/index.aspx

Dan zet je de 'core'-switches in een stack, iedere server sluit je aan met 2 touwtjes per functie (ik zie VMware, dus ik neem aan dat je losse touwtjes hebt voor vMotion en evt. FT) die je in het OS samen knoopt (voor vSphere hoef je daar niet veel voor te doen, lees je wel in op multiple-NIC vMotion! Voor 2008 gebruik je de HP NCU, 2012 kan het native) en iedere edge-switch sluit je ook aan met 2 touwtjes.

Let op de configuratie, zaken als LACP gaan nu meespelen. Spanning Tree zoals geopperd kan ook, maar dan benut je maar de helft van de beschikbare bandbreedte tussen core en edge

Links tussen de ene edge-switch en de andere edge-switch zou ik niet doen om eerlijk te zijn, dat voegt alleen maar complexiteit toe en lost hoegenaamd niks op.

Als die HP's te duur zijn: pricewatch: Netgear Prosafe GS728TS Laat je door het plaatje niet misleiden, 728 == '24p', S = stacking

[ Voor 13% gewijzigd door Paul op 12-11-2014 15:31 ]

[lazybones]

Ik realiseer me dat de switches van het "simpele" soort zijn zonder echte IRF, maar die zijn nu eenmaal aanwezig. VMware is ook aanwezig, maar vrij simpel: twee fysieke servers (DL385 gen8) met VMWare Essentials er op. VMotion is niet van toepassing hier.

Als ik het goed begrijp is spanning tree voldoende om loops te voorkomen en een heel erg basic failover mogelijk te maken en zijn advanced features nodig om dit naadloos te kunnen doen en tegelijkertijd de max. bandbreedte er uit te halen.

Moeten de NIC's aan de VMWare kant dan active/spare of active/active zijn en is link detection als foutdetectie dan voldoende?

[BCC]

Spanning tree. Probeer niet om bandbreedte te winnen, dat gaat ten eerste rare issues geven en ten tweede: als er dan een switch klapt, dan kan je netwerk het verkeer niet aan, wat je redundantie om zeep helpt. Ik weet niet of active/spare hetzelfde is als een bond met Back-up, maar ik denk het wel.

[ Voor 17% gewijzigd door BCC op 12-11-2014 15:37 ]

[Paul]

Met spanning tree kun je wel zorgen dat je edge-switches beschikbaar blijven als één van je core-switches uitvalt, je moet alleen een beetje spelen met link costs om ervoor te zorgen dat de link die JIJ wilt in block gaat in plaats van net welke link het STP uitkomt

Qua servers: Zonder 'echte' stack zou ik de Windows-machines NFT w/ PO geven, met als voorkeur-NIC degene die naar de switch loopt met de actieve link naar de edge, en in VMware de ene active en de andere passive, wederom de NIC active die aan de switch zit met de 'goedkoopste' link naar de edge.

[goakiller900]

Stomme vraag misschien tussen door, maar onder steunen alle switches standaard Spanning tree of niet ?
Of moet je bij de iets duurdere varianten daar voor zijn ?

[Paul]

Of het per se duurdere moeten zijn niet direct, in de specs zoeken op IEEE 802.1D of -W danwel Spanning Tree vertelt je of de switch er mee overweg kan. Of je het kunt managen is een tweede. Die optie zit vaak wel enkel op de duurdere varianten. Ik vraag me af of de 1910's het kunnen, de 1810 heeft alleen (R)STP in de v2-modellen.

[Bigs]

De 1910's hebben vrij uitgebreide RSTP en MSTP functionaliteit. Voor een simpele setup als dit moet je daarmee zeker uit de voeten kunnen. Van de 1810 kan ik het me zo snel niet herinneren, maar als het erin zit moet je het in het menu zo terug kunnen vinden (een functie om de prioriteit in te stellen zou al genoeg zijn).

[lazybones]

Dank voor jullie reacties, ik weet nu welke richting ik het zoeken moet, dan ga ik me daar dieper op inlezen ... en ... proberen. Het betreft overigens de v2 versies van de 1810, dus RSTP zou daarmee moeten kunnen.

[Paul]

Ik zeg: Uittekenen Maak een schema welke switch aan welke switch hangt, schuif dan zo dat er niet teveel lijnen elkaar kruisen (in deze opstelling moet dat zelfs kunnen zonder één kruising, beide 'core'-switches in het midden, ene edge-switch erboven, de andere eronder), identificeer alle driehoekjes en ga dan bepalen welke van de lijnen je wilt onderbreken om de lus te verbreken. Die lijn geef je dan een hele hoge link cost om zo (R)STP te vertellen dat die link down moet en niet een andere.

[EverLast2002]

- Aan de linkerzijde haal je 1x HP1910 weg (als de infrastructuur/bekabeling het toelaat).
- De HP1910 die je "overhoudt" hou je achter de hand wanneer er een productieswitch defect gaat.
- benut de 2 ongebruikte cat5E kabels en creeer een trunk/teaming tussen de HP1910 (linkerzijde) en de HP1810 (rechterzijde).
Op die manier hoef je ook geen extra switch aan te schaffen.

[lazybones]

EverLast2002 schreef op donderdag 13 november 2014 @ 20:40:
- Aan de linkerzijde haal je 1x HP1910 weg (als de infrastructuur/bekabeling het toelaat).
- De HP1910 die je "overhoudt" hou je achter de hand wanneer er een productieswitch defect gaat.
- benut de 2 ongebruikte cat5E kabels en creeer een trunk/teaming tussen de HP1910 (linkerzijde) en de HP1810 (rechterzijde).
Op die manier hoef je ook geen extra switch aan te schaffen.

Volgens mij maak je daarmee het risico op uitval juist groter, als dan één van beide switches stuk gaat heb je geheel geen communicatie meer.

[EverLast2002]

lazybones schreef op vrijdag 14 november 2014 @ 00:51:
[...]


Volgens mij maak je daarmee het risico op uitval juist groter, als dan één van beide switches stuk gaat heb je geheel geen communicatie meer.

Klopt. Mijn scenario was el cheapo en gebaseerd op wat je nu hebt staan.
Aan de andere kant, hoe vaak gaat een switch kapot (en als het gebeurt dan heb je een spare switch liggen).
Misschien een advies in de nieuwe situatie (wanneer downtime nihil moet zijn) om meteen 2 switches te kopen, 1 om in te zetten, en 1 als reserve.

[BCC]

Naast uptime is het voordeel van redundantie dat je maintenance kan uitvoeren (dingen ompatchen, switches upgraden) zonder downtime. Of je dit nodig hebt is iets wat afhankelijk is van je eisen.

[ Voor 31% gewijzigd door BCC op 14-11-2014 14:04 ]

[lazybones]

EverLast2002 schreef op vrijdag 14 november 2014 @ 12:22:
[...]
Aan de andere kant, hoe vaak gaat een switch kapot (en als het gebeurt dan heb je een spare switch liggen).

De kans is klein, maar toevallig is dat een paar weken geleden wel gebeurd met de 1810 switch (rechts in de tekening). Da's toch best lastig als je op dat moment zo'n 140km van de zaak verwijderd bent. Downtijd viel op zich nog wel mee, maar als het te voorkomen is door 1 switch extra voor weinig geld, waarom dan niet doen?

[Paul]

Ik zeg: bepaal hoeveel budget er voor is Ze hebben nu gezien dat het kan, en wat het gevolg is.

Die Netgear die ik eerder linkte kom je in hele grote omgevingen niet tegen, maar ze doen niet echt onder voor die 1810 Je hoeft dan echter niet met spanning tree in de weer, je kunt dan LAG's / portchannels maken.