Redundante setup vragen

[DieterVDW]

Hallo,

Ik ben momenteel bezig met te onderzoeken hoe we een volledig redundante serversetup kunnen maken.
De setup waar we zullen voor kiezen zal bestaan uit 2 load-balancers met failover, met daarachter x aantal applicatieserver (2 om te beginnen, minimum setup).
Dit zie ik allemaal wel in orde komen, maar ik heb nog wat vragen over de omringende infrastructuur.

Netwerk: hoe zorg je voor een redundant netwerk?
Als je volledig redundant wil werken, heb je ook 2 switches nodig niet? Hoe pak je dit praktisch aan? Welke netwerkconfiguratie vereist dit? Welke gevolgen heeft dit voor netwerkconfiguratie van de serverapplicaties?
(Veronderstel dat de colocation provider 2 netwerkaansluitingen aanbiedt.)

Maar ook: redundante power. Veronderstel alweer dat de colocation provider 2 poweraansluitingen aanbiedt, en 'klassieke' servers met eigen voeding. Hoe regel je dit? Welke extra hardware komt daarbij kijken?

Verder vraag ik me ook nog af welke extra hardware jullie als noodzakelijk zien in een eigen netwerk setup in colocation? (Buiten servers en switches.) KVM-over-IP toestel? Remote powerswitch? ... ?

[Predator]

DieterVDW schreef op vrijdag 14 november 2008 @ 10:49:
Netwerk: hoe zorg je voor een redundant netwerk?
Als je volledig redundant wil werken, heb je ook 2 switches nodig niet? Hoe pak je dit praktisch aan? Welke netwerkconfiguratie vereist dit? Welke gevolgen heeft dit voor netwerkconfiguratie van de serverapplicaties?
(Veronderstel dat de colocation provider 2 netwerkaansluitingen aanbiedt.)

De server connecties en loadbalancers is vrij simpel te doen.

Neem 2 switches, trunks in etherchannel met 2 of meer kabels.
Elke switch op een apart power circuit.
Op je servers zorgt je voor de dubbele NIC's met failover mogelijkheid (geen aggregation), zoals ALB ...)
Intel support ook nog wat andere methoden.
Eén loadbalancer per switch natuurlijk.

Let wel ff op hou die loadbalancer failover & heartbeat gebeurd (VRRP ? proprietary via broadcast of multicast ? enz ...) Normaal mag dat wel geen probleem zijn.


Check eerst eens met de colo wat zij onder 2 redundante netwerkaansluitingen verstaan.
Is dat layer-3 of layer-2 ? Wat supporteren ze voor failover ? e.d.

Maar ook: redundante power. Veronderstel alweer dat de colocation provider 2 poweraansluitingen aanbiedt, en 'klassieke' servers met eigen voeding. Hoe regel je dit? Welke extra hardware komt daarbij kijken?

Normaal zijn dat aparte WDC of stopcontacten duidelijk gemarkeerd in een ander kleur.
In je servers neem je N+N redundante voedingen. Alles wat maar 1 voeding heeft (bv die loadbalancers en de switches) steek je van elk 1 op elk circuit natuurlijk.
In principe zou je ook maar 1 PSU in je servers kunnen steken, maar dat is wel zonde aangezien een extra PSU weinig kost, en je dan bij falen van een stroomcircuit de helft van de serverfarm verliest.

[ Voor 22% gewijzigd door Predator op 14-11-2008 12:13 ]

[wasted247]

Wij hebben een redundante omgeving bij onze hostings provider staan. Bij voorbaat wil ik je aangeven dat dit nogal wat denkwerk en voorbereiding nodig heeft, maar hier was je je vast al van bewust. Het load balancing gedeelte is bij ons niet aan de orde.

Om je een beeld te geven hoe wij het hebben aangepakt:

een tweetal uplinks met hieraan een tweetal pix ASA 5510 firewalls in failover mode, hieronder een tweetal dell 48 poorts switches (onafhankelijk van elkaar geconfigureerd). Hieronder hebben wij 3 ESX servers hangen welke met getrunkte verbindingen aan beide switches verbonden zijn, 3 gigabit verbindingen naar de een, 3 naar de ander. Deze servers zijn vervolgens weer verbonden met een tweetal brocade glasvezel switches, welke op hun beurt weer gezellig babbelen met een volledig redundante CX320 SAN opstelling.

Dit klinkt natuurlijk allemaal heel leuk, echter gaat het nadenken veel verder als dit.

Voorbeeld, je hebt een dual port nic. wat als deze het begeeft? Dan liggen beide verbindingen er uit, dan zou je dus eigenlijk al 2 losse nics moeten hebben met 1 poort. Nog beter, 2 dual port nics, nic 1 poort 1 op switch 1, nic 1 poort 2 op switch 2. vervolgens de andere nic weer andersom.

Dit zelfde geld dan eigenlijk ook weer vor je fiber aansluiting, en zo kun je nog wel even doorgaan

Met betrekking tot je stroom voorziening, dergelijke apparatuur is doorgaans redundant uitgevoerd, dell servers hebben bvb de mogelijkheid tot 2 voedingen. In een rack heb je dan meestal ook 2 stroom voorzieningen (iig de keuze hiervoor). Dit kan je zelfs nog redundanter maken door ook nog een pittige ups te plaatsen.

De optie van Predator met betrekking tot het aansluiten van je apparatuur kan natuurlijk, echter hebben wij bewust voor apparatuur gekozen met de mogelijkheid voor 2 stroomvoorzieningen. Zo zijn ook onze switches bijgestaan door een RPS600, dit is een redundante power supply voor switches. Welke dan weer op beide stroom voorzieningen aangesloten zit binnen het rack.

Dit juist vanwege het feit dat mocht er iets uitvallen, wat kan, en in feite mag, je niet de helft van je netwerk capaciteit direct verliest. Gewoon een extra stukje redundantie dus.

Probleem met dit soort setups is dat je het zo gek nog niet kunt bedenken. Je zal ergens een streep moeten trekken. Hoever ga je? Wat dient er echt redundant te zijn? Een aantal dingen zijn zo bij ons bvb buiten beschouwing gelaten, gewoonweg omdat je ook kan overdrijven

[Predator]

wasted247 schreef op vrijdag 14 november 2008 @ 12:46:
Voorbeeld, je hebt een dual port nic. wat als deze het begeeft? Dan liggen beide verbindingen er uit, dan zou je dus eigenlijk al 2 losse nics moeten hebben met 1 poort. Nog beter, 2 dual port nics, nic 1 poort 1 op switch 1, nic 1 poort 2 op switch 2. vervolgens de andere nic weer andersom.

Dat is natuurlijk waar, maar je blijft verder nog met SPOF in je server zelf zitten.
PCI controller bijvoorbeeld en dergelijke. Met een defecte CPU zal je server ook meteen BSOD'n, ook al zit er meer dan 1 in.

Ook kan een NIC een defect hebben zonder dat het OS dat detecteert (en dus niet overschakeld).

Dan kijk je toch beter uit naar 1 of andere server cluster oplossing of failover.

Dit zelfde geld dan eigenlijk ook weer vor je fiber aansluiting, en zo kun je nog wel even doorgaan

De meeste FC SAN's hebben normaal altijd dubbele controllers, en de FC kaarten ook.
Maar ja, dan kan je toch nog altijd een extra FC kaart steken, maar idem zelfde opmerking als voor aparte NIC's.

Ik zou eerder een extra server bij zetten dan.

De optie van Predator met betrekking tot het aansluiten van je apparatuur kan natuurlijk, echter hebben wij bewust voor apparatuur gekozen met de mogelijkheid voor 2 stroomvoorzieningen. Zo zijn ook onze switches bijgestaan door een RPS600, dit is een redundante power supply voor switches. Welke dan weer op beide
stroom voorzieningen aangesloten zit binnen het rack.

Dit juist vanwege het feit dat mocht er iets uitvallen, wat kan, en in feite mag, je niet de helft van je netwerk capaciteit direct verliest. Gewoon een extra stukje redundantie dus.

Je verliest geen capaciteit (toch in de setup van de topicstarter). Je servers gebruiken gewoon de andere NIC interfaces. Alleen als je ALB gebruikt verlies je downstream bandwith, maar met gig interfaces is dat eigenlijk geen issue.

Het switchen is ook bijna onmiddelijk (< 1 sec).

Probleem met dit soort setups is dat je het zo gek nog niet kunt bedenken. Je zal ergens een streep moeten trekken. Hoever ga je? Wat dient er echt redundant te zijn? Een aantal dingen zijn zo bij ons bvb buiten beschouwing gelaten, gewoonweg omdat je ook kan overdrijven

Beginnen bij begin
• In kaart brengen van de aangeboden diensten
• Bepalen van de impact bij verlies
• Kosten bepalen van oplossing om dat verlies te vermijden
• Knopen doorhakken



Je moet ook zien wat je onder redundant verstaat.
Als je loadbalancing doet tussen 2 zaken omdat je anders performantie issues hebt, dan is dat eigenlijk geen zuivere redundantie. Want het verliezen van 1 van de 2 heeft een performance impact.

Keuzes makes zoals je zei.

[ Voor 5% gewijzigd door Predator op 14-11-2008 15:38 ]

[wasted247]

Predator schreef op vrijdag 14 november 2008 @ 15:32:
[...]

*knip

Keuzes makes zoals je zei.

I agree, zoals je zelf ook zegt, begin bij het begin, en werk het stapje voor stapje uit, met daarbij weer rekening houdend met de verschillende scenario's waar je in zou kunnen belanden.

En idd, die meerdere controllers op fiber nics, dode pci controller etc, zijn allemaal geldige argumenten. Maar wou het lichtjes houden

Iig heeft de TS nu een praktijk voorbeeldje...

[DieterVDW]

Phew dit wordt nog lastig.
Ter info: ik heb nauwelijks ervaring met dit soort ingewikkelde netwerk setups... Please bear with me ...

Qua falen van de hardware ga ik er vanuit dat ik met 2 loadbalancers en 2 appservers safe zit.
Gelijk welke server volledig wegvalt, de boel blijft draaien. Ik ga gewoon uit van volledige systemen die uitvallen, als die situatie opgevangen kan worden, dan lukt het ook wel als een deel van de server / hardware component uitvalt niet? (Hmm wat met een server die het netwerk gaat spammen oid?)

Even focussen op de netwerk setup: ik heb het gevoel dat ik er niet kom met 2 huis-tuin-keuken routertjes, en ik weet echt niks van geavanceerde routers. Welke vereisten moet ik stellen aan een router zodat deze in zo'n redundante netwerk setup kan geconfigureerd worden?

Kun je die trunking wat meer verduidelijken?
Ik veronderstel dat dit inhoudt dat je 2 of meer netwerkpoorten zo configureert dat de netwerktraffiek over deze poorten verdeeld wordt. Dit vereist dus configuratie aan de serverkant?
Is dit iets wat de switch ook moet ondersteunen, of is deze daar agnostisch van en gaat deze gewoon het deel van het verkeer dat deze krijgt gaan routeren? Welke componenten van de netwerksetup hebben te maken met deze trunking?

[ Voor 6% gewijzigd door DieterVDW op 14-11-2008 17:40 ]

[Gomez12]

DieterVDW schreef op vrijdag 14 november 2008 @ 17:39:
Qua falen van de hardware ga ik er vanuit dat ik met 2 loadbalancers en 2 appservers safe zit.

Bepaal eerst eens voor jezelf wat je wilt kunnen opvangen.
Simpel voorbeeldje, met 2 applicatieservers en 2 loadbalancers blijven je apps draaien, maar je clients verliezen wel alle lopende sessies inclusief de data die daarin bewerkt werd.
In principe zonder shared storage die niet op die 2 servers staat verlies je altijd data als er 1 uitvalt. Met een enkele shared storage heb je wederom een nieuwe SPOF gecreeerd. Dus heb je ook meerdere shared storages nodig. Een shared storage moet ook dubbel bekabeld zijn per server voor als er 1 kabel breekt / uitvalt.
Aan de invoer zijde heb je kans dat die switch eruit vliegt dus ook redundant switches.

In pure theorie bij een volledige redundante serversetup heb je van alles ( dus elk schroefje in een server zo ongeveer ) een redundant onderdeel erin hangen. Dit redundante onderdeel gebruik je niet, maar is in normale praktijk alleen maar bezig met het mirroren van de state van het wel werkende onderdeel.

In praktijk is dit veelal te duur en worden er gewoon compromissen gemaakt ( zelfs als je alles dubbel uitvoert, van schroefje tot datacenter aan toe dan nog blijf je afhankelijk van verbindingen van ams-ix etc )

Even focussen op de netwerk setup: ik heb het gevoel dat ik er niet kom met 2 huis-tuin-keuken routertjes,

Praktisch gezien kom je juist een heel eind met 2 huis-tuin-keuken routertjes. Geavanceerdere routers hebben instelmogelijkheden als teaming etc, dit wil je niet gebruiken bij redundancy als je niet 100% weet waar je mee bezig bent.

Ik veronderstel dat dit inhoudt dat je 2 of meer netwerkpoorten zo configureert dat de netwerktraffiek over deze poorten verdeeld wordt. Dit vereist dus configuratie aan de serverkant?
Is dit iets wat de switch ook moet ondersteunen, of is deze daar agnostisch van en gaat deze gewoon het deel van het verkeer dat deze krijgt gaan routeren?

Als je gaat verdelen en 1 vd 2 valt uit, dan heb je al dataverlies. En je moet nog instellen dat hij moet stoppen met verdelen ook.

Sowieso is alle configuratie aan 2 kanten, nooit alleen aan 1 kant. Als de server geen foutmelding krijgt kan er nog steeds 1 netwerkpoort aan de routerkant stuk zijn of de kabel kan stuk zijn.

Bijna geen enkel netwerkcomponent staat in zijn factory instellingen agnostisch ingesteld voor redundancy ( want dat kost performance )

Welke componenten van de netwerksetup hebben te maken met deze trunking?

ALs ik even het trunking daar laat, alle netwerkcomponenten hebben te maken met de redundancy en moeten daarvoor ingesteld worden.

[Predator]

DieterVDW schreef op vrijdag 14 november 2008 @ 17:39:
Phew dit wordt nog lastig.
Ter info: ik heb nauwelijks ervaring met dit soort ingewikkelde netwerk setups... Please bear with me ...

Qua falen van de hardware ga ik er vanuit dat ik met 2 loadbalancers en 2 appservers safe zit.
Gelijk welke server volledig wegvalt, de boel blijft draaien. Ik ga gewoon uit van volledige systemen die uitvallen, als die situatie opgevangen kan worden, dan lukt het ook wel als een deel van de server / hardware component uitvalt niet? (Hmm wat met een server die het netwerk gaat spammen oid?)

Ja en nee.
Normaal gezien wel, maar dat hangt ook van je loadbalancer intelligentie af.
Het is je loadbalancer die moet beslissen wanneer een server niet meer OK is.

Even focussen op de netwerk setup: ik heb het gevoel dat ik er niet kom met 2 huis-tuin-keuken routertjes, en ik weet echt niks van geavanceerde routers. Welke vereisten moet ik stellen aan een router zodat deze in zo'n redundante netwerk setup kan geconfigureerd worden?

De eerste vraag is of je uberhaupt een router gaat nodig hebben. Dan kan je bij je colo checken hoe zij de connectie aanbieden.

Als je toch moet gaan routeren en je router moet weinig meer doen dan basic IP routering, dan kan je ook nog gewoon een layer-3 switch nemen. Die hebben als voordeel dat de performantie zeer hoog ligt, maar de prijs is er ook naar natuurlijk. Het hangt er een beetje vanaf hoeveel bandbreedte je ter beschikking hebt.
Als dat 100Mb of minder is, dan kan je even goed 2 switches en 2 routers nemen (als je die nodig hebt).
Ze moeten in ieder geval HSRP (cisco) of VRRP (open standaard, voor de rest vrij gelijk met HSRP) ondersteunen.
Met HSRP/VRRP kan je een redundante setup opzetten.

De meeste cisco routers (behalve de echte low-end) ondersteunen HSRP (en eventueel ook VRRP).

HSRP is in principe zeer simpel in te stellen, maar er zijn toch een paar zaken dat je moet op letten.

Maar ik denk dat je je best toch laat bijstaan door iemand met wat kennis van die materie ;-)

Kun je die trunking wat meer verduidelijken?
Ik veronderstel dat dit inhoudt dat je 2 of meer netwerkpoorten zo configureert dat de netwerktraffiek over deze poorten verdeeld wordt. Dit vereist dus configuratie aan de serverkant?
Is dit iets wat de switch ook moet ondersteunen, of is deze daar agnostisch van en gaat deze gewoon het deel van het verkeer dat deze krijgt gaan routeren? Welke componenten van de netwerksetup hebben te maken met deze trunking?

Je haalt een paar dingen door elkaar.

Je hebt:
Server 1 NIC 1 -> SW 1
Server 2 NIC 2 -> SW 2

Als we even Adaptive load balancing buiten beschouwing laten dan stuur Server 1 zijn verkeer over NIC 1 naar SW 1. NIC 2 staat aan aan maar verstuurd en ontvangt niets. Valt NIC 1 uit of SW 1 uit, dan veranderd server naar NIC 2. Vrij simpel en dat werkt in de praktijk prima.

Dat is natuurlijk nooit 100% bulletproof. Je server moet wel detecteren dat de NIC slecht werkt.
Maar dat probleem lost je loadbalancer voor jou op. Die zal de server uit de groep halen en de andere server alle clients geven.

Je kan ook gewoon met 1 NIC (of 2) naar SW1 werken, en andere server op SW2. Dus 1 server per switch.
Maar dan heb je het nadeel dat een defecte switch of NIC (als het maar 1 NIC is) je server ook meetrekt.
Met bovenstaande ben je niet afhankelijk van de switch.

Maar wat je natuurlijk ook moet voorzien is dat SW1 met SW2 verbonden is. Dat is die trunk waar ik het over had. Ik spreek van trunks omdat connecties tussen switches meestal meerdere VLAN's omvatten en in dot1q mode staan

Je verbinding tussen beide switches is zeer belangrijk. Die moet ook dubbel zijn natuurlijk.
Je kan gewoon via spanning tree (of wat betere cisco alternatieven) doen maar dat is vrij idioot voor zo iets.
Gewoon een etherchannel maken tussen beide switches (dat is een bundle van 2 of meer connecties. Bv 2xgig = etherchannel van 2 gig).

Je moet zeker vermijden dat de switch interlink weg valt.
Dan krijg je rare situaties waar active/standy plotseling active/active wordt.
Je loadbalancer (die wellicht VRRP gebruikt) zal dat ook echt niet leuk vinden.
Nou ja, dat hangt er vanaf. In jouw geval zal misschien nog meevallen.

PS: wil je nog FW's ertussen zetten ?

[Predator]

Gomez12 schreef op vrijdag 14 november 2008 @ 18:48:
[...]
Praktisch gezien kom je juist een heel eind met 2 huis-tuin-keuken routertjes. Geavanceerdere routers hebben instelmogelijkheden als teaming etc, dit wil je niet gebruiken bij redundancy als je niet 100% weet waar je mee bezig bent.

Euh, dat is onzin.

Je bent niets met 'huis-tuin-keuren' routertjes.
Laat dat in de huis-tuin-keuken.

Ik veronderstel dat met 'geavanceerd routers met teaming' dual-wan routers bedoeld en dat heeft hier absoluut niets mee te maken.

Je hebt HSRP of VRRP nodig.

Als je gaat verdelen en 1 vd 2 valt uit, dan heb je al dataverlies. En je moet nog instellen dat hij moet stoppen met verdelen ook.

Onzin, je hebt geen dataverlies.

Stoppen met verdelen

Sowieso is alle configuratie aan 2 kanten, nooit alleen aan 1 kant. Als de server geen foutmelding krijgt kan er nog steeds 1 netwerkpoort aan de routerkant stuk zijn of de kabel kan stuk zijn.

Als de router zijn NIC (welke ook serverkant of colo kant) stuk is, of de kabel, neemt de andere router over.
Daarvoor heb je HSRP (en interface tracking in HSRP).

Bijna geen enkel netwerkcomponent staat in zijn factory instellingen agnostisch ingesteld voor redundancy ( want dat kost performance )


[...]

ALs ik even het trunking daar laat, alle netwerkcomponenten hebben te maken met de redundancy en moeten daarvoor ingesteld worden.

[DieterVDW]

Extra informatie: In eerste instantie is er geen shared data, elke appserver werkt volledig zelfstandig.
(Zal in de toekomst allicht veranderen, maar is probleem voor later.)
Loadbalancer kan ook wel als firewall dienst doen lijkt mij? Is het nodig om daar een dedicated oplossing voor te voorzien?

Stel voor de volgende setup:

Elke switch is verbonden met alle applicatieservers (APPx), maar elke switch is wel gekoppeld aan zijn eigen loadbalancer (LBx) en netwerk link (LINKx).
Voordeel: gemakkelijk
Nadeel: Indien een LINK, LB of SW faalt valt de volledige combo (LINK-LB-SW) weg...

Verbetering?:

Zelfde als vorige setup, maar de loadbalancers gaan switchen naar een de andere switch indien hun 'eigen' exemplaar er de brui aan geeft ...

(Er zal mij inderdaad iemand bijstaan om de volledige setup uit te tekenen, maar ik zou toch graag ook beetje op de hoogte zijn voor het zo ver is. Vandaar deze thread.)

Iemand tips voor goeie boeken over deze materie trouwens?

[DieterVDW]

offtopic:
kickje

Iemand opmerkingen over de setup hierboven?
Firewall op de loadbalancer is ok?
Verbeteringen mogelijk?

[Predator]

DieterVDW schreef op dinsdag 18 november 2008 @ 11:18:

offtopic:
kickje

Iemand opmerkingen over de setup hierboven?
Firewall op de loadbalancer is ok?
Verbeteringen mogelijk?

Dat hangt er vanaf.

Wat voor services biedt je aan ? (gewoon webverkeer ?).
Wat kan je op die loadbalancer doen ?
Werkt die transparant, als router of als application GW (proxy) ?
Als die als proxy werkt dan hoef je misschien inderdaad niets meer te doen.
Die loadbalancer zal wel al afgeschermd zijn, en wat er achter staat is dan niet meer bereikbaar.

Meer kan altijd, dat hangt er vanaf wat voor intelligentie jouw netwerksecurity moet hebben.
Dat gaat van simpel TCP/UDP filtering tot protocol verificatie en intrusion protection.

[ Voor 5% gewijzigd door Predator op 18-11-2008 12:02 ]

[DieterVDW]

Predator schreef op dinsdag 18 november 2008 @ 12:01:
[...]

Dat hangt er vanaf.

Wat voor services biedt je aan ? (gewoon webverkeer ?).
Wat kan je op die loadbalancer doen ?
Werkt die transparant, als router of als application GW (proxy) ?
Als die als proxy werkt dan hoef je misschien inderdaad niets meer te doen.
Die loadbalancer zal wel al afgeschermd zijn, en wat er achter staat is dan niet meer bereikbaar.

Meer kan altijd, dat hangt er vanaf wat voor intelligentie jouw netwerksecurity moet hebben.
Dat gaat van simpel TCP/UDP filtering tot protocol verificatie en intrusion protection.

Webapplicatie, HTTP verkeer.
Voor de loadbalancer gaan we allicht voor het softwarepakket van Zeus (ZXTM LB). Ofwel voor Linux Virtual Server oid., maar daar ken ik nog niks van, moet ik nog bekijken.
Het is de bedoeling dat die loadbalancer transparant werkt in de zin dat deze de request naar een applicatieserver gooit en that's it (wel met session affinity). Al de rest is extra.
(De software van Zeus kan wel het eea. in ieder geval... SSL offloading etc, leuk maar niet nodig.)