Netwerktopologie voor in het datacenter

woensdag 6 februari 2008 16:20

Topicstarter

jvanhambelgium schreef op woensdag 06 februari 2008 @ 13:32:
Klinkt allemaal eigenlijk alvast niet slecht, maar veel zal afhangen welke risico's op downtime je wenst te accepteren en hoeveel centen je te spenderen hebt.

De switches zijn al in huis (besteld voordat ik werkzaam werd), dus daar zijn geen kosten meer aan.

Heb je ook concreet STATS waaruit je kan opmaken wat huidige pijnpunten zijn ??
Vb netwerk saturatie of eerder server/vm bottelnecks ?

Redundantie is momenteel het enige pijnpunt: de uplink naar de provider trekken we maar voor 40% vol (dus 40Mbit). Intern is het nog niet zo dat bijv. de backup niet snel genoeg gaat.

Zoals ik ook al aangaf in de startpost: throughput en latency tellen momenteel nog niet.

Je spreekt over LinkAgg, maar is een "gewone" 2 x 1000BaseT (waarvan 1 actief is en 1 niet) per server niet genoeg dat je nog moet gaan aggregeren? Dus al je servers hebben 1 default gateway (de loadbalancer) die daarachter dan verder alles gaat regelen met de upstream routers van die ISP?

Het gaat om LinkAgg tussen de kasten onderling (dus tussen de core switches en de distributieswitches). Het gaat erom dat als twee servers van kast 1 willen communiceren met ieder 1 server uit kast 2 dat dat bijv. niet op halve snelheid gaat. Als het verkeer 'in de kast' zou blijven zou het namelijk wel op volle snelheid gaan.

Hoe zit het met security ? Als je gewoon een L2 oplossing gaat bouwen, hoe zit het met de security, heb je ergens transparante firewalls tussen tussen de VLAN's staan ?
Met routing heb je een direct wel meer mogelijkheden natuurlijk.
Nu heb je mischien wel een VLAN-segment in elk van de kasten steken, maar geen visibility of control op alle flows in & uit.

Zoals ik al aangaf heb ik geen rekening gehouden met L3. Daar moet ik me nog op inlezen.
Overigens kan ik wel aangeven wat ik weet: we hebben twee loadbalancers (ipvs/lvs) waar ook de firewalls op draaien. Het verkeer komt binnen via VLAN 5, wordt gefirewalld en geloadbalanced en gaat weer naar buiten via VLAN 2. Dan gaat het naar de interne machines, daar komt het weer van terug en dan wordt het weer via VLAN 5 naar buiten gegooid. Mits ik het goed heb begrepen.

Je zegt dat je 3 ethernet touwtjes hebt van de provider ? Hoe zit het met IP ? Hoeveel IP's of blokken heb je tot je beschikking ? Heb je eigen IPspace via RIPE ?

We hebben twee blokken van 256 IP's en per kast een 100Mbit ethernet link.

Acties:

woensdag 6 februari 2008 16:21

Topicstarter

keur0000 schreef op woensdag 06 februari 2008 @ 13:45:
Ander advies;

Verdeel de eindgroepen in de patch kasten over 3 fasen, dus;
- fase 1 > 1 of 2 x eindgroep C16A/230V. Switch 1, Switch 4.
- fase 2 > 1 of 2 x eindgroep C16A/230V. Switch 2, Switch 5.
- fase 3 > 1 of 2 x eindgroep C16A/230V. Switch 3, Switch 6.
Hiermee verspreid je het risico optimaal, en heb je de laagste fout tolerantie.

Tevens zo uit te voeren voor de redundant uitgevoerde servers..........

Dit is de manier waarop pro's de server ruimte ontwerpen, maar er zijn nog veel meer opties ;-).

Ik heb maar 2 fasen tot mijn beschikking. Ik ontwerp geen server ruimte, ik probeer in een gehuurde ruimte een goede invulling te maken.

Acties:

woensdag 6 februari 2008 16:34

McFallafel, nu met paardevlees

Je hebt nu overal maar 1 failover, waarom kies je niet voor een fully meshed oplossing?

Acties:

woensdag 6 februari 2008 16:50

Topicstarter

Kippenijzer schreef op woensdag 06 februari 2008 @ 16:21:
Je hebt nu overal maar 1 failover, waarom kies je niet voor een fully meshed oplossing?

Op den duur niet schaalbaar.

Verder is het zo dat onze kasten niet naast elkaar staan en dat we via de provider patches moeten aanvragen van de ene naar de andere kast. Fysiek is het mogelijk om maar 12 patches te hebben per kast, waarvan er al 1 in gebruik is voor de uplink. Dus ik moet ook rekening houden met de poortjes

Acties:

woensdag 6 februari 2008 17:15

McFallafel, nu met paardevlees

En ze bieden geen mogelijkheid om tussen de kasten een vol patch-panel aan te leggen? Ik ben gewend met 24 'vrije' patchpoorten per kast te kunnen werken

.
Tzt zul je natuurlijk nooit een fully meshed setup houden, maar altijd dubbele 'uplinks' tussen elke apparaat en de laag erboven. Dat zou schaalbaar genoeg moeten zijn (tegen de tijd dat je in je uplink switches geen poorten meer hebt moet je sowiezo een extra distributielaag toevoegen).

Acties:

donderdag 7 februari 2008 07:54

Topicstarter

Kippenijzer schreef op woensdag 06 februari 2008 @ 16:50:
En ze bieden geen mogelijkheid om tussen de kasten een vol patch-panel aan te leggen? Ik ben gewend met 24 'vrije' patchpoorten per kast te kunnen werken .
Tzt zul je natuurlijk nooit een fully meshed setup houden, maar altijd dubbele 'uplinks' tussen elke apparaat en de laag erboven. Dat zou schaalbaar genoeg moeten zijn (tegen de tijd dat je in je uplink switches geen poorten meer hebt moet je sowiezo een extra distributielaag toevoegen).

Ik weet niet zeker of het mogelijk is om meer patches te krijgen. Ik heb wel een vraag uitstaan bij hun helpdesk of dat mogelijk is. Vooralsnog ga ik er vanuit dat dat niet het geval is.

Bij mijn vorige werkgever hadden we een x aantal kasten naast elkaar. Toen was het makkelijk om via de vloer gewoon extra kabels te trekken tussen de kasten onderling, maar dat was ook bij een andere provider. Dat was nu wel makkelijk geweest, maar zo werkt deze provider (begrijpelijk) niet.

Momenteel heb ik geen onderscheid tussen distributie en access switches omdat er maximaal maar 25 machines per kast geplaatst kunnen worden. Mochten we in de toekomst kasten gaan 'specialiseren' en er kasten komen met dezelfde specialisatie dan wil ik nog wel extra distributieswitches toe gaan voegen, maar momenteel heeft dat nog geen zin.

Acties:

donderdag 7 februari 2008 09:57

Karnemelk FTW

Ik snap niet hoe je de onafhankelijk VLAN wil gaan bereiken als je nergens een L3 device hebt. Over het algemeen bouwen wij ook zo'n setup maar dan is de Distributie laag verantwoordelijk voor het routen van de VLANs. Dit is bij jou niet handig en je zou die moeten verplaatsen naar de Core.

Het L2 design is prima maar hoe het op L3 gaat werken is me een groot raadsel.

Acties:

Verwijderd

Ik zou een server met solaris als "portalserver" gebruiken. Binnen de zogeheten "containers" maak je routers en SSh of andere databeveiligers aan. Elke container kan gelinkt worden aan vlans binnen je kasten en kun je tevens gebruik maken van trunking. (een container is een virtuele server binnen je solaris doos)

Naar mijn mening heb je dan de volgende voordelen:

1. 1 server voor beheer toegang routing
2. eenvoudige management van routings
3a. beheer van eventuele vlans is makkelijk en snel
3b elke container krijgt zijn eigen Ipadressen en netmasks en eventueel netwerkkaart(en)
4. processors en geheugen en tevens delen daarvan kun je toewijzen aan die containers die het nodig hebben.
5. containers kun je backuppen (zelfs op een USB stick ) zodat je deze zeer eenvoudig kunt overzetten naar nieuwe hardware tijdens een failure of hardwareupgrade

Er is gigantisch veel te vinden op het www over solaris en routing, bijvoorbeeld dit document

donderdag 7 februari 2008 11:02

Acties:

donderdag 7 februari 2008 12:50

Karnemelk FTW

Routen moet je doen op een router niet meer en niet minder. Daar is die voor gemaakt en heeft, als he een beetje goede is, allemaal ASIC om het zo snel mogelijk te kunnen doen.

Acties:

BrammeS

Verwijderd schreef op donderdag 07 februari 2008 @ 09:57:
Ik zou een server met solaris als "portalserver" gebruiken. Binnen de zogeheten "containers" maak je routers en SSh of andere databeveiligers aan. Elke container kan gelinkt worden aan vlans binnen je kasten en kun je tevens gebruik maken van trunking. (een container is een virtuele server binnen je solaris doos)

Naar mijn mening heb je dan de volgende voordelen:

1. 1 server voor beheer toegang routing
2. eenvoudige management van routings
3a. beheer van eventuele vlans is makkelijk en snel
3b elke container krijgt zijn eigen Ipadressen en netmasks en eventueel netwerkkaart(en)
4. processors en geheugen en tevens delen daarvan kun je toewijzen aan die containers die het nodig hebben.
5. containers kun je backuppen (zelfs op een USB stick ) zodat je deze zeer eenvoudig kunt overzetten naar nieuwe hardware tijdens een failure of hardwareupgrade

Er is gigantisch veel te vinden op het www over solaris en routing, bijvoorbeeld dit document

Let wel op dat alsj e een solaris bak gaat gebruiken voor je routing je alsnog een single point of failure hebt.

Wij hebben een soortgelijke situatie. Daar hebben we 2 OpenBSD machines met quagga(ivm BGP routering).

Advanced sheep-counting strategies

donderdag 7 februari 2008 15:52

Acties:

donderdag 7 februari 2008 16:11

Topicstarter

TrailBlazer schreef op donderdag 07 februari 2008 @ 07:54:
Ik snap niet hoe je de onafhankelijk VLAN wil gaan bereiken als je nergens een L3 device hebt. Over het algemeen bouwen wij ook zo'n setup maar dan is de Distributie laag verantwoordelijk voor het routen van de VLANs. Dit is bij jou niet handig en je zou die moeten verplaatsen naar de Core.

Het L2 design is prima maar hoe het op L3 gaat werken is me een groot raadsel.

Mij ook!

Ik ga me vandaag en morgen inlezen op layer 3 en dan ga ik dat op het ontwerp toepassen. Daar was ik vandaag nog niet aan toegekomen, want de hele dag in het datacentrum geweest om 2 van de drie kasten met bonding aan de praat te krijgen.

Acties:

donderdag 21 februari 2008 16:12

Karnemelk FTW

Je moet trouwens ook goed naar je spanning-tree pio's Je wil namelijk je 2 cores switches als root van de tree hebben.

Acties:

donderdag 21 februari 2008 16:33

Topicstarter

TrailBlazer schreef op donderdag 07 februari 2008 @ 07:54:
Ik snap niet hoe je de onafhankelijk VLAN wil gaan bereiken als je nergens een L3 device hebt. Over het algemeen bouwen wij ook zo'n setup maar dan is de Distributie laag verantwoordelijk voor het routen van de VLANs. Dit is bij jou niet handig en je zou die moeten verplaatsen naar de Core.

Het L2 design is prima maar hoe het op L3 gaat werken is me een groot raadsel.

Later dan verwacht heb ik dan toch het stuk over Layer 3 gelezen. Het is me nog niet helemaal duidelijk.

Momenteel hebben we enkele machines (load balancers) die zowel in vlan 5 (extern verkeer) als in vlan 2 (intern server verkeer) hangen. Pakketten komen dus via vlan 5 op de load balancers binnen. Daar wordt het gefirewalld, geloadbalanced en naar de interne servers gestuurd via vlan 2. Intern draaien we een ander IP-subnet dan extern. Dus hier zit dan een stukje routering, waarvan je je afvroeg waar deze was.

Verder hebben we nog enkele machines op het interne netwerk die zowel in vlan 3 als in vlan 2 hangen, zodat we via het interne netwerk de switches etc. kunnen beheren. Dus ook daar zit een stukje routering.

Als ik het O'reilly boek moet geloven is het niet slim om routering door 'end devices' te laten uitvoeren.

Wat zou dan een betere setup zijn? Een router in het netwerk plaatsen en als we de switches willen beheren gaan we via de router het management subnet (en dus vlan 3) op?

En zou loadbalancing dan ook door een router verzorgd moeten worden? Of is dat functionaliteit die wel wel door een machine kunnen laten verzorgen?

Acties:

donderdag 21 februari 2008 16:34

Karnemelk FTW

Je beheert de switches op vlan 3 ? Dit is best een uitzonderlijke situatie want meestal is dit vlan 1.

hoe ik het zou doen dan.

-------------     vlan 5 (extern)
 |         |
lb1	  lb2
 |         |
-------------	  vlan 100 (transit)
 |         |
rtr1	 rtr2
| I      | I 
-------------	  vlan 2 (user1)
  I        I
-------------	  vlan 3 (mgmt)

Maar ik weet niet precies hoe die loadbalancers werken. Die krijgen een request binnen voor een bepaald ip adres en die veranderen die destination dan neem ik aan naar een van de werkelijke member ip adressen.

Die dingen die ik met | of I heb getekend hoeven niet perse fysieke touwtjes te zijn. Dit kan ook gewoon een 802.1q trunk zijn naar een enkele router. Iedere behoorlijke router kan dit aan. Hoewel ik hier eerde voor een L3 switch zou kiezen. Je kan dan op alle vlans HSRP of VRRP gaan draaien voor extra redundancy.

[ Voor 21% gewijzigd door TrailBlazer op 21-02-2008 16:38 ]

Acties:

donderdag 21 februari 2008 16:40

McFallafel, nu met paardevlees

Het is natuurlijk totaal je eigen keuze (vooral qua hoeveelheid hardware en eisen die je aan het geheel stelt) om je load-balancer tevens router te laten spelen. Als je een machine puur als router inricht is het ook geen 'end-device' meer. Wel zou ik, indien dat nu niet zo is je load-balancers van 2 aparte nics voorzien (3 eigenlijk): een eigen voor intern en een eigen voor extern en je interne verkeer 'standaard' gewoon over het default vlan gooien en enkel waar dit nodig is extra vlan's toevoegen. (En dus evt. een 3e voor dedicated heartbeat tussen de routers/load-balancers)
[edit]
Nav hierboven (zit zelf atm te kijken naar een oplossing om management van de switches te scheiden van de eigenlijke netwerken die eroverheen lopen): zou ik alle netwerken op mijn switches dan het beste in vlans kunnen gooien en enkel de management in VLAN1? En hoe 'voorkom' ik dat ik alle switches (4 ranges) tot een spanning-tree hell degradeer omdat via de management vlan ze allemaal 1 collision domain zouden vormen? (Zou helaas niet de 1e keer zijn dat een range eruit ligt omdat de switch besluit een poort uit een andere range en VLAN op blocking te gooien

[ Voor 33% gewijzigd door Kippenijzer op 21-02-2008 16:37 ]

Acties:

donderdag 21 februari 2008 17:03

Karnemelk FTW

ja het enige wat in vlan 1 moet zitten is je switch management geen user verkeer of wat dan ook. Gewoon lekker vlans aanmaken voor elk subnet.
Spanning tree zal geen problemen moeten geven hoor. Als je cisco's hebt kan je ook een instance per vlan draaien dan kan je ook nog loadbalancen als je wil.

[ Voor 35% gewijzigd door TrailBlazer op 21-02-2008 16:42 ]

Acties:

donderdag 21 februari 2008 18:13

McFallafel, nu met paardevlees

Mjah, helaas zijn het dell's die het met MVST moeten stellen en volgens mij moet ik daar 'hardcoded' elk vlan aan een vst instance toewijzen helaas.

Acties:

donderdag 21 februari 2008 19:38

Karnemelk FTW

Yep en dat is gelijk de renden dat wij geen MSTP gaan draaien. Beetje klote als je 1 vlan toevoegd en dat je dan 50 switches moet herconfiguren omdat anders je MSTP region gescheiden wordt tot je klaar bent.

Acties:

vrijdag 22 februari 2008 12:36

McFallafel, nu met paardevlees

Haha, dus ik ben gewoon een beetje f-ed dan met de dell switches? (Dan zal ik dus een cisco switch als 'mangement root switch' in gaan zetten denk ik zo

Acties:

vrijdag 22 februari 2008 13:16

Topicstarter

TrailBlazer schreef op donderdag 21 februari 2008 @ 16:33:
Je beheert de switches op vlan 3 ? Dit is best een uitzonderlijke situatie want meestal is dit vlan 1.

Voor zover ik het begrepen heb wisselen de switches op vlan 1 zelf wel informatie uit (bijv. voot STP), maar het managen van de switches doen we via vlan 3.

hoe ik het zou doen dan.
-------------     vlan 5 (extern)
 |         |
lb1	  lb2
 |         |
-------------	  vlan 100 (transit)
 |         |
rtr1	 rtr2
| I      | I 
-------------	  vlan 2 (user1)
  I        I
-------------	  vlan 3 (mgmt)		
Maar ik weet niet precies hoe die loadbalancers werken. Die krijgen een request binnen voor een bepaald ip adres en die veranderen die destination dan neem ik aan naar een van de werkelijke member ip adressen.

Die dingen die ik met | of I heb getekend hoeven niet perse fysieke touwtjes te zijn. Dit kan ook gewoon een 802.1q trunk zijn naar een enkele router. Iedere behoorlijke router kan dit aan. Hoewel ik hier eerde voor een L3 switch zou kiezen. Je kan dan op alle vlans HSRP of VRRP gaan draaien voor extra redundancy.

Voor zover ik het O'Reilly boek snap, raad men aan om te gaan routeren om zo je broadcast domains te verkleinen.

Normaal gesproken zou je vlans aanmaken voor bijv. servergroups of bijv. alle workstations op een bepaalde verdieping (en dan een vlan en ip subnet per verdieping).

Wij hebben te maken met kasten in een datacentrum en alle functies zijn over die kasten verdeeld: dus er staan een aantal webservers in kast 1, maar er staan er ook een aantal in kast 2 en 3. Vlan's aanmaken voor een servergroep (bijv. alle webservers) heeft dus niet veel zin, want het valt niet te routeren als de groep over meerdere kasten verdeeld is.

Daarom zou het enige criterium om te routen de kast zelf zijn, eventueel aangevuld met vlans per functie. Ik zou dan op de volgende setup komen:
Afbeeldingslocatie: http://www.kikvors.com/prive/routing.jpg

Afbeeldingslocatie: http://www.kikvors.com/prive/routing.jpg

Is dit een slimme setup?
Ik zie zelf als bezwaar dat als ik een machine verplaats van de ene naar de andere kast, ik zijn ip-adres moet gaan aanpassen, terwijl ik dat nu niet heb.

Ik vind het lastig om tot een goede setup te komen, omdat functies over meerdere kasten verdeeld zijn (webservers in alle kasten) en omdat sommige functies (file storage) weer verbonden zijn met alle andere functies (mail, web).

Ik krijg mijn vingers niet echt achter layer 3 design: ik snap het principe van routing, snap ook de verschillende routing protocollen maar zie niet goed hoe ik dit zou moeten toepassen in mijn situatie. Heeft iemand goede leestips? Ik ben momenteel whitepapers van cisco aan het doorspitten om op goede ideeen te komen.

Acties:

vrijdag 22 februari 2008 13:19

Karnemelk FTW

Je kan gewoon je vlans doortrekken over je kasten dat is zelfs aan te raden. Je maakt tussen je access en core switches 802.1q trunks aan hierdoor kunnen poorten in hetzelfde vlan prima met elkaar praten ook al zitten ze op verschillende switches.

Je tekening klopt ook niet elke horizontale lijn onder je routers is een vlan en dus ook 1 subnet.

Server verhuizen naar een andere kast is dan een kwestie van een poortje op de switch in die kast in het goede vlan zetten. Als jij maar 1 vlan heb voor je servers is dat prima te verantwoorden. Wij hebben enkel de servers per functiegroep in een ander vlan gezet. Dat zal er ook wel mee te maken hebben dat we een enorm aantal servers hebben staan. Maar dat hoeft helemaal niet nodig te zijn.

Ik weet niet of je ILO boards (remote management kaarten) in je server hebt hangen maar maak daar dan ook een apart vlan voor. Je kan dan veel beter je beveiliging regelen.

Overigens wat wel een aardig boek is (en als je cisco switches hebt een must) is het BCMSN boek hierin wordt deze setup helemaal uitgelegd.

[ Voor 21% gewijzigd door TrailBlazer op 22-02-2008 13:19 ]

Acties:

vrijdag 22 februari 2008 13:22

Topicstarter

TrailBlazer schreef op vrijdag 22 februari 2008 @ 13:16:
Je kan gewoon je vlans doortrekken over je kasten dat is zelfs aan te raden. Je maakt tussen je access en core switches 802.1q trunks aan hierdoor kunnen poorten in hetzelfde vlan prima met elkaar praten.

Server verhuizen naar een andere kast is dan een kwestie van een poortje op de switch in die kast in het goede vlan zetten. Als jij maar 1 vlan heb voor je servers is dat prima te verantwoorden.

Op deze manier hebben we het nu al ingericht.

WIj hebben enkel de servers per functiegroep in een ander vlan gezet. Maar dat hoeft helemaal niet nodig te zijn

Zoals ik al schreef twijfel ik ook over het nut om meerdere VLAN's te maken voor serverfunctiegroepen omdat in de praktijk toch storage, webservers, mail etc met elkaar verbonden zijn.

Ik weet niet of je ILO boards (remote management kaarten) in je server hebt hangen maar maak daar dan ook een apart vlan voor. Je kan dan veel beter je beveiliging regelen.

Deze zitten op vlan 3. Ze doen aan piggy-backing met de eerste interface.

Acties: