Server opstelling

[Foxie_s]

Voor ons bedrijf ben ik een hosted setup aan het bouwen. Helaas is hardware niet onze core-business en is de opleveringsdatum zo nipt dat alle externe hulp/advies welkom is. Ik heb al verschillende bedrijven gecontacteerd maar helaas spreken die elkaar nogal eens tegen en praat iedereen voor zijn eigen winkel.

Hoe werkt de software.
De software die we gebruiken bestaat uit 2 delen. De Message Server, een webapplicatie geschreven in PHP die een paar windows services bevat en de client applicatie die bij mensen thuis wordt geïnstalleerd. Deze client zal om de x minuten via een HTTP verbinding “kijken” of er iets nieuws op de server staat. Indien de informatie op de server nieuwer is dan de informatie op de client wordt deze gedownload en getoond. Het is dus belangrijk dat de webservers geen of minimale caching hebben.

Schema idee:
Bedoeling is dat mensen via de Message Server nieuwe berichten kunnen invoeren. De data wordt opgeslagen op de SQL server en de geuploade bestanden op de file server. De client applicatie zal vervolgens via de web servers (WEB 1 –n) de data terug kunnen downloaden. Wij kunnen de interne servers (SQL en file server) bereiken via de firewall (VPN verbinding). Alle servers draaien onder windows 2003 (web, standaard of enterprise) en het is een MS SQL database (standaard edition).




Tussen het internet en de web servers zit er een loadbalancer en tussen het internet en de Message Servers is er een loadbalancer.

Nu zitten we nog met paar vragen ivm met deze setup.

• Moet er een DC komen in de private IP range voor user accounts?
• Is het nodig om met een DMZ te werken tussen de webservers en File/SQL server of is het voldoende om 2 netwerkkaarten per server te hebben met verschillende IP adressen?
• De file en SQL server zouden zo robuust mogelijk moeten zijn. Nu hadden wij gedacht aan een cluster actief/passief maar hoe voer je dit uit zodat bij een software of hardware probleem de andere server het overneemt?
• Voor de loadbalancing zit ik te kijken naar eentje van Foundry ServerIron 4G. (link ) Maar ik sta open voor alternatieven.

Tis nogal een lijstje maar dit zijn zaken waarover tussen de verschillende gecontacteerde partijen elkaar tegengesproken.

[Bl@ckbird]

Loadbalancing alternatief: CSS11500

Als je naar het kleinste model kijkt, moet je weten of je SSL offloading wel doen of niet.
Dit omdat de 11501 niet modulair is. (CSS11501 non-SSL, CSS11501S-C met SSL offloading)

Als firewall kan je naar een ASA5500 kijken met een IPS module.

Hiermee kan je o.a. wormen en scripting aanvallen tegen houden. Maar het ligt er natuurlijk aan hoeveel je voor beveiliging wil uitgeven en wat voor data over de lijn loopt.

[axis]

[b][message=308529
• Moet er een DC komen in de private IP range voor user accounts?

Ik neem aan dat de user accounts slechts voor administrators/developers zijn?

Je hoeft in principe geen AD te draaien, je kunt ook voor iedereen handmatig een account aanmaken op iedere server, of een paar algemene accounts aanmaken. Heb ik ook jaren gedaan. Active Directory opzetten is het netste natuurlijk (ben ik ook steeds meer een meer aan het doen, als je veel users hebt wordt dat toch wel erg handig), omdat je dan alle admin accounts op 1 plek kunt beheren.

Ik heb zelf bijvoorbeeld een netwerk op kantoor met een AD domein, bijvoorbeeld 'BEDRIJF', en in elk datacenter voor ieder project (groep servers of racks voor een specifiek project) aparte domeinen zoals 'BEDRIJFCOLO2', of 'PROJECTCOLO'. Door trusts te maken kan ik zorgen dat mijn collega administrator of developer Pietje met zijn eigen account BEDRIJF\Pietje kan inloggen op alle servers in de andere domeinen.

Maar je wilt dan wel op z'n minst 2 DC's hebben lijkt me, omdat je hele infrastructuur afhankelijk wordt van AD en DNS, beetje onhandig als je ene DC plat ligt en je niet meer in kunt loggen, of servers elkaar niet meer kunnen vinden, etc.

• Is het nodig om met een DMZ te werken tussen de webservers en File/SQL server of is het voldoende om 2 netwerkkaarten per server te hebben met verschillende IP adressen?

Niet nodig, wel netjes. Bij de meeste projecten geef ik webservers een extern ip-adres en een intern ip-adres op verschillende netwerkkaarten, en dus ook een interne switch (Gbit) en een externe (100Mbit). Je kunt er nog een filewall tussen zetten, dat is allemaal wat netter. Maar is met active directory integratie iets lastiger.

Daarnaast wil je waarschijnlijk 's nachts ook backups maken naar een interne server, en dan is het fijn als die backups een beetje snel gaan. Als je dan een firewall ertussen hebt die maar 100mbit routeert...

Een aan de publieke kant voor je webservers zou je kunnen volstaan door op iedere webserver een ipsec-policy te zetten (als portfilter, draait in kernel in tegenstelling tot windows firewall, dus veel sneller). Een hardware firewall ervoor is echter wel netter. Maarja, heb je weer single point of failure tenzij je er 2 koopt en de failover-licentie koopt.

Je kunt zo makkelijk een Cisco ASA 5505 ervoor zetten a 450 euro, en die in transparent mode zetten, hoef je niets te configureren. Dan kun je alleen niets meer met ipv6, want dat doen die krengen dan weer niet, maar misschien voor jou niet van toepassing.

• De file en SQL server zouden zo robuust mogelijk moeten zijn. Nu hadden wij gedacht aan een cluster actief/passief maar hoe voer je dit uit zodat bij een software of hardware probleem de andere server het overneemt?

Voor de fileserver zou je kunnen kijken naar DFS (voor replicatie is volgens mij een domein vereist), zodat 2 fileservers automatisch een share repliceren.

Voor SQL server is een active/passive server redelijk standaard, maar daar heb ik zelf (nog) geen kaas van gegeten.

• Voor de loadbalancing zit ik te kijken naar eentje van Foundry ServerIron 4G. (link ) Maar ik sta open voor alternatieven.

Ik ga zelf voor Microsoft NLB (Network Load Balancing). Is gratisch, zit bij Windows Server inbegrepen (2003,2008, alle editions). Werkt als een trein, en is erg simpel te configureren als je je een beetje hebt ingelezen. Daarnaast is het peer-based, dus je hebt geen single point of failure.

Enige nadeel van NLB dat ik zie is dat NLB een layer 4 load balancer is, hij is niet applicatie-aware. als je instelt dat ie poort 80 moet balancen tussen de 5 hosts, doet ie dat. Ook als op een van de nodes een error teruggeeft, of IIS niet draait. Alleen als een host uitvalt of je stopt hem via de cluster tool, doet ie niet meer mee.

Gebruiken hier al een jaar of 5 NLB, en nog steeds erg tevreden. Als een developer een nieuwe versie op een node zet, gebruikt ie de NLB cluster tool om de node uit het cluster te halen, installeert de nieuwe verzie, test, en klikt in de NLB tool weer op het start-knopje .Simpel als wat.

[Foxie_s]

@Axis

Bedankt voor je reactie. Hoe zorg je er eigenlijk voor dat alle content op de webservers synchroon loopt? Oorsprongelijke bedoeling was om de home Directory te pointen naar "A share located on another computer" om zo te zorgen dat de webservers allemaal dezelfde content terug geven aan de clients. Door deze opstelling zal alle load bij de fileserver komen te liggen.

[--MeAngry--]

Plus, je bent meteen je redundancy voor een groot deel kwijt. Misschien is het verstandig om met een rsync achtige oplossing alles in sync te houden? Ik heb eerlijk gezegd geen ervaringen met zoiets in een Windows omgeving.

[Mike2k]

Uhh...Je kan je web servers aan elkaar knopen met NLB. Kost niks, zit er gewoon in...
Ik zou dan 2 DMZ's maken...1 voor je message servers en 1 voor je windows servers.
Je file servers en SQL servers zet je buiten je DMZ en dus ik je 'gewone' lan. Inderdaad een vpn'tje er naar toe...

O en je file servers kan je ook in een clutser hangen...is dat ook weer redundant...same goes voor SQL

Niet te moeilijk maken

[ Voor 14% gewijzigd door Mike2k op 09-10-2008 09:48 ]

[Kokkers]

Foundry ServerIron is een prima loadbalancer. Dingen zijn niet stuk te krijgen en leveren performance die je niet snel in een pure software oplossing zult halen. Een hardware load-balancer zou ik enkel uit durven voeren (met een service contract), ding doet wat hij moet doen onder load en je kan er fatsoenlijke (vendor backed) support op krijgen. Dit is een redelijk cruciaal apparaat in je setup.

Kijk, zoals eerder genoemd, wel goed welk model je neemt, met een feature als Layer 7 (Application) switching op de Foundry heb je altijd een handige trucendoos achter de hand in de toekomst, voor eventueel SSL heb je de 4G-SSL versie nodig.

Je hebt het over het aanbieden van downloads; als je grote files uit gaat sturen vanaf je webservers is het misschien handig om in je architectuur rekening te houden met een Direct Server Return setup. Inkomende requests en health-checking worden door de loadbalancer afgehandeld maar het verkeer terug naar de client kan direct terug via je core en hoeft dan niet via je loadbalancer. Dit werkt ook voor servers die niet fysiek aan de loadbalancer hangen. Blijf je onder de gigabit aan uitgaand verkeer dan is dit niet relevant.

High-availability voor file en database servers is leuk maar je moet bijzonder goed weten waar je mee bezig bent.
Elke noodgreep om 'near-realtime automated failover' te realiseren brengt ook weer extra risico's met zich mee.
In de praktijk zie je zo vaak dat er juist in het High availability gedeelte iets misgaat waardoor de service op zijn bek gaat hetgeen in een 'Keep It Simple Stupid' oplossing waarschijnlijk nooit was gebeurd.

Voor active-active file en database server opstellingen heb je vaak dure specialistische spullen en kennis nodig en vaak heb je dan nog een single-point-of-failure en dat is de vereiste gedeelde storage. Je komt dan in aanraking met zaken als shared block storage of block-level replicatie, clustered file systems, heartbeats, automatische failover situaties en dan is het nog maar de vraag wat je clients doen met open-files en connecties. Iemand die de hele dag niets anders doet de hele dag roept misschien dat het simpel is, je hebt dan wel een vergelijkbaar poppetje nodig die 24/7 aan jouw zijde staat...

De vraag is of je je hiermee bezig wil houden en niet gewoon een active-passive opstelling bouwt voor zowel je file- als database server en alles op applicatie en file niveau laat repliceren. Voor file replicatie is software beschikbaar en database replicatie zou een eitje moeten zijn. Ik heb zelf slechte ervaringen met DFS en bijbehorende file replicatie maar wellicht is die techniek inmiddels geperfectioneerd. Hier zijn ook nog 3rd party applicaties voor en afhankelijk van de situatie kom je met periodieke Xcopy of Rsync's nog wel weg.
Alternatief is shared storage voor je database en fileservers, ook een single point of failure en vergt extra aandacht op het gebied van performance.

Je bent dan wel afhankelijk van handmatige failover (desnoods in je loadbalancer) mocht er een keer een mainboard, backplane of controller uitfikken. Je slaves kun je dan mooi gebruiken voor read-only en backup acties zodat je productie hier geen last van heeft. File en databaseservers (en clients) vinden het (tenzij je hier in je applicatie rekening mee houdt) niet leuk als er een failover plaatsvindt. Als er om welke reden dan ook automatisch teruggeswitched wordt heb je een probleem met je data integriteit. Een fileserver kun je nog wel mergen maar voor een database zal dit al snel fataal zijn.

Alles hangt af van de functie van je systeem, het eisenpakket, de hoeveelheid tijd en mankracht die je beschikbaar hebt en uiteindelijk natuurlijk het budget.

Vergeet de backup en restore procedure en de impact hiervan ook niet mee te nemen in je plaatje.

/edit
Kleine toevoeging, heb nu genoeg getikt waar je helemaal niet op zat te wachten en heb mijn koffie op :-)

[ Voor 14% gewijzigd door Kokkers op 09-10-2008 11:10 ]

[axis]

Foxie_s schreef op donderdag 09 oktober 2008 @ 09:34:
@Axis

Bedankt voor je reactie. Hoe zorg je er eigenlijk voor dat alle content op de webservers synchroon loopt? Oorsprongelijke bedoeling was om de home Directory te pointen naar "A share located on another computer" om zo te zorgen dat de webservers allemaal dezelfde content terug geven aan de clients. Door deze opstelling zal alle load bij de fileserver komen te liggen.

Onze developers uploaden hun applicatie handmatig naar alle nodes, één voor één. Zo kunnen ze ook testen of de deployment goed gaat, en als er wat fout gaat, hebben niet alle nodes de foute content, zodat je site plat ligt

Je zou de web servers ook kunnen synchen met Microsoft's DFS, maar geen ervaring mee in productie.

[stiena]

Hoe ben je tot deze setup gekomen? Met deze aantallen kun je enkele miljoenen requests per maand gaan verwerken, gaat het echt zo'n veel gebruikte omgeving worden of zit er een andere gedachte achter?

Ik heb bouw en beheer soortgelijke omgevingen en zou het op de volgende manier aanpakken:

Frontend segment:

- Firewall / Loadbalancer node 1
- Firewall / Loadbalancer node 2 (met heartbeat naar node 1)
- messageserver 1
- messageserver 2
- Webserver 1 t/m n

Backend segment

- Cluster node 1 (MS clustering, MSSQL, CIFS fileserver en de custom windowsservices)
- Cluster node 2 (MS clustering, MSSQL, CIFS fileserver en de custom windowsservices)
- shared storage (IPSAN)
- backend firewall voor VPN verbindingen om omgeving te beheren
- NAS voor DB dumps / overige backups en monitoring

Voordelen:
- alles redudant
- goede scheiding van Front en backend
- geen replicatie voor DB of Files nodig (slechte ervaringen mee)

Nadelen:
- Je hebt een domain nodig voor MS clustering
- Shared storage is redelijk duur
- benodigde kennis

Voor de loadbalancers heb ik goede ervaringen met de F5 BigIP's, maar ook met het veel goedkopere LVS (hiervoor hoef je alleen de hardware aan te schaffen).

Zonder meer te weten over de exacte werking van de applicaties en verwachtingen van jullie kant kunnen we eigenlijk niet tot een goed advies komen, als de applicatie bijvoorbeeld niet heel zwaar is en de requests per maand niet ontzettend hoog zijn kun je ook aan virtualiseren gaan denken.

Gaan jullie de omgeving zelf bouwen en beheren of gaan jullie het uit besteden? Mochten jullie het gaan uitbesteden dan is de benodigde kennis vaak wel aanwezig van clustering e.d.

[alt-92]

Foxie_s schreef op donderdag 09 oktober 2008 @ 09:34:
Door deze opstelling zal alle load bij de fileserver komen te liggen.

DFS gebruiken.

[Mike2k]

Inderdaad, gewoon DFS gebruiken...werkt prima..zoals ik al zei, dan kan je je fileservers ook clusteren...heb je weer redundantie...

[Foxie_s]

Mijn excuses dat ik niet eerder gereageerd heb maar alvast bedankt voor alle reacties. We zijn intern eens rond de tafel gaan zitten en vanwege de kostprijs, tijdslimiet enz hebben we beslist om de redundancy niet hoog op de prioriteiten lijst te zetten. Hierdoor bevat het schema dat we nu op het oog hebben iets meer single point of failures.

Schema is geworden:



De firewall wordt waarschijnlijk een Juniper Networks SSG 140 (linkje) met een 16 port Gigabit uitbreiding (linkje).

Voor de loadbalancer zitten we naar deBarracuda Load Balancer 340 (linkje) te kijken. Deze is een stuk goedkoper dan de ServerIron.

Alle servers (hardware) is vrijdag besteld en gisteren geleverd dus dat gedeelte is afgesloten. Nu hebben we 2 mogelijke opbouw scenario’s. Waarschijnlijk zijn er nog andere en betere dus ideeen zijn meer dan welkom.

Eerste is om alles in 1 IP range te zetten. We configuren de firewall zo dat alle HTTP/HTTPS verkeer naar de loadbalancer gaat en deze het verdeelt onder de 3 webservers. Al het andere verkeer tussen de servers, webservers en SQL enz gaat over dat zelfde LAN.



Tweede opstelling die ik in gedachte had is



We configuren de firewall zo dat alle HTTP/HTTPS verkeer naar de loadbalancergaat in het 10.2.3.0/24 range en deze het verdeelt onder de 3 webservers. De webservers zijn uitgerust met een tweede netwerkkaart die op een aparte Lan zitten (2de security zone). Ik besef dat men via de webservers van het eene lan op het andere kan maar ik kan me niet onmiddellijk een alternatief bedenken om ervoor te zorgen dat de webservers op de SQL en fileserver kunnen en ook nog in domain zitten.

Samengevat zit ik dus met alweer paar vragen:
1. heeft iemand slechte ervaringen met de gekozen firewall en/of Loadbalancer?
2. Welke van de 2 bovenstaande methodes is het beste of is er nog een 3de betere alternatief (moet wel gemakkellijk opzetbaar zijn).

@Kokkers

Alles hangt af van de functie van je systeem, het eisenpakket, de hoeveelheid tijd en mankracht die je beschikbaar hebt en uiteindelijk natuurlijk het budget.

Vergeet de backup en restore procedure en de impact hiervan ook niet mee te nemen in je plaatje.

/edit
Kleine toevoeging, heb nu genoeg getikt waar je helemaal niet op zat te wachten en heb mijn koffie op :-)

Tijd is heel krap, begin november moeten we live zijn, mankracht zijn mijn collega en ik (dus 2 MK) en het budget is zoals altijd ... zo goedkoop mogelijk

Genoeg getyped, tijd voor mijn koffie

[axis]

Sja, scenario 1 is het snelst op te zetten, scenario 2 misschien iets veiliger. Ik neem aan dat je firewall een DMZ setup kent, waarbij je dan je webservers in de DMZ zou kunnen zetten. (zoals scenario 2 dus)

Je er dan voor kunnen zorgen dat men vanaf het internet alleen naar de DMZ mag, en dat de webservers in de DMZ niet zelf connecties naar het internet kunnen initieren. Machines in de DMZ mogen alleen naar je interne servers connecten.

Maar als je in tijdnood zit, ga dan voor scenario 1, en keep it stupid simple.. Hele volksstammen doen het op die manier.

Let wel dat je nu een opstelling hebt waarbij je 5 single points of failure hebt (firewall, loadbalancer, dc, fileserver en sql server).. Hoeft niet erg te zijn, maar goed, je moet je er wel bewust van zijn.

[Robinski]

Ik weet niet hoeveel verschil er zit tussen je DC en fileserver kwa hardware, maar misschien is het slim om ook in je DC genoeg disks te zetten zodat je ook een backup fileserver hebt.

Kleine investering voor een point of failure minder. Deze fileservers kun je vervolgens met DFS synchroon houden (en automatisch failover/loadbalancen)

Eventueel kun je ook je webservers in de DFS zetten voor de files/mappen die zij synchroon moeten hebben voor hun functioneren.

Verder weet ik niet wat voor hardware je hebt, maar je zou door middel van virtualisatie nog beter je point of failures kunnen verminderen. Je DC gaat toch al uit z'n neus zitten eten voor een groot deel van de dag, dus als je hierop eventueel nog virtueel een SQL server gaat draaien als backup, blijf je tenminste up als je SQL server plat gaat en heb je meteen een backup van je data.

Overigens is virtualisatie altijd handig om snel en gemakkelijk services te schuiven tussen fysieke servers, ook als er een keer hardware kapot gaat, gewoon de image overzetten naar een andere machine en alles is weer up (geld voornamelijk voor de SQL, DC, File en Message server)

[Foxie_s]

@axis,

De 5 single point of failures is inderdaad iets waar rekening mee gehouden moet worden. Maar de server hardware is zo redundant mogelijk uitgevoerd. Tevens zullen de loadbalancer en firewall support contracten hebben.

@Robinske,

De DC en fileserver zijn identiek en samengesteld met virtualistatie in ons achterhoofd. Helaas hebben we niet veel ervaring met virtualistatie en vanwege de tijdsdruk is dit naar achter geschoven. Trouwens bij everrun hoeft je zelf geen images over te zetten ... Maar om dit nu op zo korte tijd in elkaar te steken is iets teveel van het goede

[Li0nHeart]

We hebben sinds kort een Juniper SSG550. Dit is volgens mij de iets grotere broer van de 140.
Ik vind het ideale firewalls. Duidelijke webinterface om alles te configureren. Ik denk alleen wel dat je daar voor de eerste configuratie hulp bij nodig zult hebben. Dat heb ik ook niet zelf gedaan. Daarna is het beheer makkelijk. Je kunt er ook met SSH heen om debugging info te bekijken (zeg maar tcp pakketjes).

Bij een Juniper is het wel aardig om een syslog server te hebben, kijk een naar kiwi syslog, aangezien je dan ook logging historie kunt bijhouden van de firewall.

Ik zou de message servers en webservers in een DMZ zetten.
De back-end servers in een 'LAN', of Trust in Juniper termen. Firewall heeft dus 3 interfaces, of 3 virtual interfaces:

UnTrust
DMZ
Trust

Voor loadbalancing gebruiken wij een Foundry ServerIron. Deze doet het inmiddels al 2 jaar probleemloos. Maar kost wel wat. Ik ben aan op dit moment aan het kijken naar vervanging, omdat we ook SSL-offloading moeten gaan doen, en onze ServerIron heeft geen slot voor zo'n kaart.

Cisco is mij geadviseerd, schijnt qua configuratie vrijwel identiek te zijn aan de Foundry, maar ook qua prijs.
Ik ga zelf ook maar eens naar de Barracuda LB kijken.

Trouwens, met een DMZ en LAN zou je 2 DC nodig hebben (is in ieder geval makkelijker), maar is wel prijziger. Wellicht kun je SureSync gebruiken ( www.suresync.com). Wij gebruiken dit om een server op LAN te synchroniseren met een server op DMZ. Maar het werkt net zo goed als DFS, en ik vermoed een stuk goedkoper.

[LEiPiE]

Foxie_s schreef op donderdag 16 oktober 2008 @ 10:06:
Voor de loadbalancer zitten we naar deBarracuda Load Balancer 340 (linkje) te kijken. Deze is een stuk goedkoper dan de ServerIron.

Als ik deze thread even omhoog mag halen: hoe zijn jullie ervaringen in deze setup met de Barracuda 340?
Ben daar namelijk wel naar benieuwd aangezien wij een soortgelijke setup hebben en de 340 tot nu toe op piekmomenten het niet aan kan.
(ik twijfel over een nieuw topic betreffende loadbalancers, maar dat kan onafhankelijk hier van wel )

[Foxie_s]

Loadbalancer doet het eigenlijk heel goed. Probleem waar we nu tegenaanlopen is de Firewall, het aantal gelijktijdige verbindingen, netwerksnelheid en dataverkeer.

We zitten nu aan ongeveer aan 2,5 miljoen requests per dag en we vermoeden dat onze firewall dit niet meer aankan waardoor onze hosted setup onbereikbaar wordt.

[LEiPiE]

Ok, zolang je niet tegen het rare geval aanloopt dat op een gegeven nieuwe verbindingen worden geweigerd terwijl oude netjes afgehandeld worden zit je goed
Ondertussen hebben wij die van ons vervangen door een Kemp LoadMaster 2500 en die bevalt op dit moment al heel wat beter, zal niet offtopic gaan in een Barracuda-flame

[DukeBox]

LEiPiE schreef op woensdag 14 januari 2009 @ 00:16:
Ok, zolang je niet tegen het rare geval aanloopt dat op een gegeven nieuwe verbindingen worden geweigerd terwijl oude netjes afgehandeld worden zit je goed
Ondertussen hebben wij die van ons vervangen door een Kemp LoadMaster 2500 en die bevalt op dit moment al heel wat beter, zal niet offtopic gaan in een Barracuda-flame

Gelukkig had ik er ook al niet zo'n fijn gevoel bij en hebben voor de foundry 4g ssl gekozen.