Webhosting high availability

[djluc]

Ik ben bezig met de vervolgstap wat betreft onze hostingsactiviteiten. Wij zijn een bedrijf wat websites en webapplicaties ontwikkelt. We hosten deze op dit moment op shared webservers met Apache, MySQL en PHP.

We willen toe naar een meer betrouwbare hostingsoplossing en daarnaast willen we iets meer mogelijkheden. Daarom overwegen we een investering in een eigen hostingsplatform. We kijken bij onze keuze naast technische zaken met name naar TCO, total cost of ownership. Onderhoudskosten e.d. zijn dus ook zeer belangrijk.

Wat we nu overwegen is de kwestie die ik jullie voor wil leggen:

We kunnen kiezen voor een server bij een betrouwbare partij. Klinkt opzich goed maar we willen niet afhankelijk zijn van 1 server. Als we nu een crash hebben, denk aan moederbord kapot, dan ligt alles plat. Dat willen we niet.

We kunnen dus meerdere servers met verdeelde taken, denk aan een databaseserver, fileserver en een webserver. Kan en is simpel (niet complex) maar is weer geheel afhankelijk van elkaar.

Als derde optie kunnen we kiezen voor virtualisatie, 1 actieve server en een backup server bijvoorbeeld waarbij we snel kunnen switchen.

Als vierde optie zien we clustering. Dat vinden we persoonlijk erg interessant. Meerdere servers die vervangbaar zijn en zodra er 1 kapot gaat geen downtime.

Ik heb nog meer informatie maar voorlopig lijkt dit me even voldoende. We hebben qua capaciteit voldoende aan 1 server is wellicht nog relevant. Graag hoor ik wat jullie ervaringen zijn, welke oplossing kost weinig onderhoud en is stabiel. Uiteraard is hardware die we aanschaffen nieuw en goed.

[Question Mark]

De te kiezen oplossing is sterk afhankelijk van de gewenste beschikbaarheid.

Dus punt één: welke beschikbaarheid wens je?

[djluc]

Een exacte waarde vind ik erg lastig, alle hosters lopen te roepen dat ze van 99 tot 99,999 procent uptime hebben. Maar dat zegt met niet zo veel. Wat ik niet wil is dat zodra een server (een ding wat mijns inziens kapot kan) uitvalt er op locatie iets moet gebeuren voordat de websites weer online gaan.

[KoeKk]

djluc schreef op maandag 28 december 2009 @ 20:04:
Een exacte waarde vind ik erg lastig, alle hosters lopen te roepen dat ze van 99 tot 99,999 procent uptime hebben. Maar dat zegt met niet zo veel. Wat ik niet wil is dat zodra een server (een ding wat mijns inziens kapot kan) uitvalt er op locatie iets moet gebeuren voordat de websites weer online gaan.

De vraag van Question Mark zal je toch, zo goed en kwaad als het gaat, moeten beantwoorden. Zonder duidelijke probleem stelling kunnen we adviseren wat we willen maar is het moeilijk om een goed antwoord te geven. Tevens zijn zaken als budget enzovoorts ook erg belangrijk om te kunnen bepalen welke failover/redundancy methode wenselijk en haalbaar is.

Geen enkele hoster zal die 99,xxx% echt kunnen waarborgen. Vaak geld deze garantie alleen op onderdeel van de omgeving, zoals de connectivity, en niet op de gehele omgeving. Zet het ook uit je hoofd dat je de bizar hoge uptime waardes gaat halen, als ik kijk naar onze windows en unix servers hebben de meeste een uptime van rond de 99,5%, en dat zijn dan servers die nog nooit een crash hebben gehad en alleen down zijn geweest vanwege onderhoud of het installeren van updates.

Daarnaast zal, hoe uitgebreid je failover oplossing ook is, het niet te voorkomen zijn dat er bij een failover iets mis gaat (failover = complex, complex = foutgevoelig) en er als nog iemand in een datacenter zit te zweten om het allemaal weer op rolletjes te krijgen.

Als je er niet van terugschrikt om €30.000 te investeren dan zou je kunnen kijken naar een lichte VMWare omgeving bestaande uit 2 fysieke servers en een shared storage oplossing. Als dit niet de bedoeling is zou je kunnen kijken of je bij een hoster een (Vmware) virtuele machine kan huren. Er zijn er wel een aantal die dit doen (bijvoorbeeld PINS met HyperGrid (http://www.pins.nl/infrastructuur_hypergrid.aspx), bij mijn werkgever doen we iets gelijks maar dan op een wat kleinere schaal). Dan ben je wel beschermd tegen hardware uitval, en met meer machines zou je dan kunnen kijken naar failover in je software laag.

[djluc]

Ok, ik zal een concreet target stellen: Maximaal 24 uur per jaar. Dus 1 volle dag.

Ik voel veel voor oplossingen zoals Google deze gebruikt waarbij je dus wat meer goedkope hardware hebt en die slim laat samenwerken in plaats van een dure san bijvoorbeeld waarbij je alsnog spofs houdt.

Ik zat bijvoorbeeld te kijken naar: http://hadoop.apache.org/ waarmee je distributed oplossingen kan maken.

Compeliteit willen we inderdaad zoveel mogelijk vermijden. We hebben bijvoorbeeld situaties gezien met loadbalancers, meerdere synchroniserende database servers, webservers etc. en het valt toch om.

[Verwijderd]

Allereerst moet ik zeggen dat ik niet geheel objectief ben, maar ik vind dat ontwikkelaars van webapplicaties precies dat moeten doen. Hosting en serverbeheer zijn net weer even een andere tak van sport.

Wij hebben zelf verschillende HA platforms opgeleverd, vaak telkens net weer even anders. Het kan enerzijds met VM's op een ESX cluster, anderzijds kan het met fysieke servers. Vaak moet je met clustering wel direct aan 4 machines denken in plaats van één. Soms kan het ook wel met twee fysieke servers, als er niet teveel op MySQL wordt geleund. De eerste stap naar clustering is het grootst, daarna is het wel vaak goed schaalbaar.

Als voorbeeld geef ik even een enkele webapplicatie die van 2 VM's naar 5 VM's ging toen het even flink druk werd. En na de piek werd het weer afgebouwd.

Dus nogmaals, ik zou afraden dit zelf te gaan doen. Vraag gewoon wat offertes aan bij enkele partijen waarvan je verwacht dat ze goede oplossingen kunnen bieden.

[Gomez12]

djluc schreef op maandag 28 december 2009 @ 23:14:
Ok, ik zal een concreet target stellen: Maximaal 24 uur per jaar. Dus 1 volle dag.

Ik voel veel voor oplossingen zoals Google deze gebruikt waarbij je dus wat meer goedkope hardware hebt en die slim laat samenwerken in plaats van een dure san bijvoorbeeld waarbij je alsnog spofs houdt.

Ik zat bijvoorbeeld te kijken naar: http://hadoop.apache.org/ waarmee je distributed oplossingen kan maken.

Compeliteit willen we inderdaad zoveel mogelijk vermijden. We hebben bijvoorbeeld situaties gezien met loadbalancers, meerdere synchroniserende database servers, webservers etc. en het valt toch om.

Tja, ik zou wel goed nadenken over wat je wilt.
Goedkope hardware en dingen als hadoop etc zijn zeker wel uitvoerbaar als je de schaalbaarheid en de kennis ervan hebt.

Goedkope hardware heeft als nadeel dat het met bosjes tegelijk uit kan vallen / dat je incompatibiliteit kan krijgen. Hadoop klinkt leuk totdat je er 1 klein probleempje mee hebt en je hele handel omkeilt zonder dat je ergens een SLA oid hebt.

Heb je 200 servers en uitgebreide ervaring met troubleshooting van hadoop dan is het leuk om te doen, als er dan 20 servers omvallen vanwege 1 hadoop foutje dan is het niet erg en is 1 dag uitval niet erg. Heb je 5 servers en moet je op inet gaan zoeken naar je hadoop oplossing dan vraag ik me sterk af waar je mee bezig bent.

Goedkope hardware is alleen leuk als je de aantallen hebt, OS projectjes zonder commerciele support zijn imho alleen leuk als je er de kennis van hebt. Gratis usenet support klinkt leuk totdat je een probleem hebt en je hele business plat ligt en er net die dag even niemand online is die het antwoord weet.

[KoeKk]

djluc schreef op maandag 28 december 2009 @ 23:14:
Ok, ik zal een concreet target stellen: Maximaal 24 uur per jaar. Dus 1 volle dag.

Ik voel veel voor oplossingen zoals Google deze gebruikt waarbij je dus wat meer goedkope hardware hebt en die slim laat samenwerken in plaats van een dure san bijvoorbeeld waarbij je alsnog spofs houdt.

Ik zat bijvoorbeeld te kijken naar: http://hadoop.apache.org/ waarmee je distributed oplossingen kan maken.

Compeliteit willen we inderdaad zoveel mogelijk vermijden. We hebben bijvoorbeeld situaties gezien met loadbalancers, meerdere synchroniserende database servers, webservers etc. en het valt toch om.

Punt met een SAN is dat het geen SPOF is, het is wel een enkel apparaat, maar alles hoort onder de motorkap dubbel uitgevoerd te zijn. Daarnaast zijn zaken als Hadoop en zelf je failover logica in je applicatie bouwen (Zoals Google dat doet) ontzettend leuk maar ook zeer complex. Er is een reden dat VMWare en clustering veel gebruikt worden in het MKB: Het is de goedkoopste en simpelste methode om de benodigde failover en redundancy te bereiken.

Oh en als je van een hardware investering van €10.000 al zit te slikken, zet heel dit verhaal dan uit je hoofd, zowel de keuze voor "logica in je applicatie" of in de hardware/OS maakt dan niet zo veel uit, failover kost gewoon geld.

Verder sluit ik me helemaal aan bij Cheatah en Gomez12 .

[axis]

Je kunt natuurlijk ook stapsgewijs gaan uitbouwen en spofs (single points of failure) uitsluiten.. Je begint met bijvoorbeeld met een balancer clustertje (bijvoorbeeld 2 simpele linux machines met haproxy als load balancer die met heartbeat failover doen). Daarachter kun je dan web servers gaan zetten die je identiek houdt (configuratie+content bijvoorbeeld syncen met rsync).

Qua sql backend is het wat lastiger, zeker als je zelf de php applicatie niet schrijft. Geen idee hoe mysql clustering werkt.

Ik kan je dit boek aanraden, gaat met name over schaalbaarheid, maar ook voor een groot deel over high availability, met voorbeeld configs en dergelijke.

[Rolfie]

Een belangrijker iets, wat je ook maakt, alles kan kapot gaan. Waarbij vaak geld hoe simpeler de omgeving, hoe makkelijk te recoveren.
Clusters zijn heel mooi, maar hou er rekening mee dat je een extra laag introduceerd. En die laag kan ook problemen veroorzaken. Hierbij maakt het niet uit, of je nu een load balancer cluster of een HA cluster maakt.

En het uit elkaar trekken van je omgeving, bied voordelen, maar ook nadelen. Immers als je nu naar 3 servers gaat (Web, DB, File), en 1 van die gaat onderuit, werkt je website dan nog?

Hardware storingen zijn bij A-merken (HP, Dell, IBM) vaak binnen 4 uur te vervangen. Er zitten steeds minder componenten in, dus is steeds gemakkelijk om te vervangen. En met een 24*7 SLA op je hardware, van je daarmee zo goed als altijd alles af.
Software storingen, das vaak een stuk lastiger. Daar kan vanalles mee mis gaan. Hoe meer langen, hoe moeilijker de troubleshooting is, en hoe meer onderuit kan gaan.

Misschien is Amazon Elastic Compute Cloud iets wat je zoekt? Storage genoeg, als je even een extra server nodig hebt, heb je die zo (al is dit heel gevaarlijk voor ontwikkelaars, je heb er dan zo heeeeeel veel draaien). Prijzen zijn netjes.

[djluc]

Ik begrijp uiteraard dat we het zo simpel mogelijk moeten houden, dat is een vrij logische gedachte en kennen wij o.a. ook uit software ontwikkeling. Verder gaan we het beheer natuurlijk uitbesteden, ieder z'n vak.

Wat ik een beetje vreemd vind is dat iedereen z'n eigen clusters loopt te bouwen. Dus een loadbalancer installeren, replicatie enzovoorts. Dat vind ik een lastig hoofdstuk, je zou denken dat er goede standaard oplossingen zijn om zoiets op te zetten zonder al teveel configuratie.

Het werken met servicecontracten en dus dure hardware live proberen te houden strookt echt niet meer met mijn visie. Wellicht kan dit wel onterecht zijn maar ook complete raid systemen heb ik om zien vallen.

Amazon EC2 met http://www.rightscale.com/ ziet er erg interessant uit. Je kan daarmee eenvoudig op het EC2 cluster gaan hosten met een vrij handige webinterface.

@axis: Dank voor de tip over het boek!

[Verwijderd]

djluc schreef op dinsdag 29 december 2009 @ 12:13:
Ik begrijp uiteraard dat we het zo simpel mogelijk moeten houden, dat is een vrij logische gedachte en kennen wij o.a. ook uit software ontwikkeling. Verder gaan we het beheer natuurlijk uitbesteden, ieder z'n vak.

Wat ik een beetje vreemd vind is dat iedereen z'n eigen clusters loopt te bouwen. Dus een loadbalancer installeren, replicatie enzovoorts. Dat vind ik een lastig hoofdstuk, je zou denken dat er goede standaard oplossingen zijn om zoiets op te zetten zonder al teveel configuratie.

Dat kunnen we ook wel over webapplicaties zeggen. Als jullie nou eens een standaard bedenken zodat er een vast pakket van eisen is, hoeven wij geen bijzondere configuraties te leveren

Maar serieus, er komt haast altijd wel wat specifieke configuratie bij kijken. Dat hoeft ook helemaal niet zo erg te zijn. Het belangrijkst is natuurlijk dat de beheerders hun vak goed verstaan.

Het werken met servicecontracten en dus dure hardware live proberen te houden strookt echt niet meer met mijn visie. Wellicht kan dit wel onterecht zijn maar ook complete raid systemen heb ik om zien vallen.

Dat kan inderdaad gebeuren, al is het zeldzaam. Maar als je het echt goed wilt doen, moet je ook nog eens op twee fysiek gescheiden locaties clusteren, zodat je ook bijvoorbeeld een totale power outage aan kunt. En zelfs dan kan alles er ineens uitliggen als alle verbindingen naar alle locaties plat gaan. Er is altijd wel een doemscenario te bedenken. Vandaar dat niemand 100% uptime kan garanderen. Je noemt zelf al dat je er maximaal 24 uur per jaar uit wilt liggen. Dat is al vrij veel, dus zal het doorgaans niet zo'n problemen geven daar iets voor te vinden. 99.7% uptime is prima haalbaar voor een serieuze partij.

Amazon EC2 met http://www.rightscale.com/ ziet er erg interessant uit. Je kan daarmee eenvoudig op het EC2 cluster gaan hosten met een vrij handige webinterface.

De vraag is dan alleen hoe het zit met de support, en of jullie applicatie er lekker mee overweg kan. Vergis je er niet in dat je soms ook een applicatie moet aanpassen

[raymonvdm]

Ik zou zelf kiezen voor 2 of 3 front-ends eventueel met single disk,psu maar wel veel mem en snelle processor om de kosten te besparen. Daarvoor 2 oude/simpele machines met VRRP en LVS als loadbalancers.

Voor de database server zou je kunnen kiezen voor een zware machine en een lichte fallback (MySQL Master/Slave) Of een single mysql server en een van de zwaardere webserver inrichten als eventuele MySQL fallback


Wikipedia: Linux Virtual Server
Wikipedia: Virtual Router Redundancy Protocol
Wikipedia: Multi-master replication

[Verwijderd]

raymonvdm schreef op dinsdag 29 december 2009 @ 13:22:
Ik zou zelf kiezen voor 2 of 3 front-ends eventueel met single disk,psu maar wel veel mem en snelle processor om de kosten te besparen. Daarvoor 2 oude/simpele machines met VRRP en LVS als loadbalancers.

Waarom zou je zelf de loadbalancing willen doen? De topicstarter wil het zo eenvoudig mogelijk. Dan lijkt het mij onverstandig zelf voor die loadbalancing te zorgen. Uiteindelijk kosten die loadbalancers toch ook rackspace en stroom. En dus ook nog eigen beheer? Dan kun je toch beter gebruik maken van loadbalancers van je ISP.

Voor de database server zou je kunnen kiezen voor een zware machine en een lichte fallback (MySQL Master/Slave) Of een single mysql server en een van de zwaardere webserver inrichten als eventuele MySQL fallback

Of je gebruikt twee servers in een master-master opstelling, zodat er geen bijzondere dingen hoeven worden gedaan als een van de twee er om welke reden dan ook even mee ophoudt. Bij een master met een slave als fallback moet ineens de master worden veranderd, of als je een zwakkere machine neerzet in een master-master opstelling merk je direct mindere performance. Dan zou ik toch liever voor twee identieke masters kiezen. Als je applicaties het toelaten kun je er dan nog wel meerdere slaves bij zetten.

Wikipedia: Linux Virtual Server
Wikipedia: Virtual Router Redundancy Protocol
Wikipedia: Multi-master replication

Het probleem van dit soort artitkelen is dat je de indruk krijgt dat je zoiets wel even opzet. Dat is ook wel zo als je de nodige ervaring hebt. Heb je dat niet, of wil je je er simpelweg niet druk om hoeven maken en je gewoon op je core business willen richten, kun je dat soort kennis best tot je nemen, maar zou ik het beheer toch echt niet zelf willen doen.

Overigens ben ik zelf 5 jaar webdeveloper geweest en ben ik nu alweer een paar jaar werkzaam bij een zakelijke ISP. Op basis van die ervaring zeg ik: blijf webdevelopen en doe er geen serverbeheer bij, tenzij het echt om zo'n groot aantal gaat dat je een volledig eigen cluster kunt verantwoorden. Denk dan wel direct even aan storage, databaseservers, webservers en loadbalancers. De stap van hosting op een eigen server naar hosting op een eigen cluster is erg groot. Vaak doe je dan een te lage investering.

Wij als zakelijke ISP hebben uiteraard wel verschillende storage platforms, ESX clusters, loadbalancers, etc. die gebruikt worden voor meerdere klanten. Dat betekent dat de kosten daardoor omlaag kunnen, ook omdat het beheer vanzelfsprekend ook in de prijs meegenomen wordt en dus wordt gedeeld.

Kortom, ik vind het wijs als iemand wat kennis opdoet op dit vlak. Vergis je echter niet in de impact op een webdevelopmentbureau. In feite introduceer je een nieuwe afdeling, en daar moeten minimaal 2 mensen zitten met voldoende kennis en ervaring, in verband met mogelijke ziekte, vakanties, etcetera. Denk er dus vooral niet te makkelijk over

[Compuhair]

Amazon EC2 is al eens genoemd. Ik denk dat 't voor start-ups zeker de moeite waard is om te kijken naar cloud computing. Microsoft biedt ook cloud computing aan onder de naam Azure. Er is nu al een SDK voor php en Azure. In de toekomst kan je waarschijnlijk ook hele VM's beheren op Azure en dan worden de mogelijkheden eindeloos.

Ik werk zelf veel met Azure en ik vind 't ideaal voor als je zelf de infra niet wilt regelen maar wel betrouwbare hosting wil. Bovendien is de schaalbaarheid bijzonder flexibel. Wil je een extra instance erbij, dan hoog je een cijfertje in de config op. Wil je meer geheugen, dan hoog je een ander cijfertje op. En je kan dat zelf geautomatiseerd doen, via de SDK's.

[CrankyGamerOG]

Dit lijkt me niet zo moeilijk?

Wij hebben een aantal klanten die ook HA vereisen.

2 servers op gescheiden locaties, aan elkaar geknoopt dmv hearbeat.

Valt a weg neemt b het over, en vice versa.

De data staat op een losse drbd cluster die ook gemirrored is op 2 locaties en dan ook hearbeat draait.

_{even heel simpel en plat gezegd dan}

[ Voor 24% gewijzigd door CrankyGamerOG op 30-12-2009 22:55 ]

[EDIT]

Servers in eigen beheer zou ik als applicatie-ontwikkelaar niet zo snel doen, omdat het (zeker in een geclusterde omgeving) toch gewoon specialistisch werk is en je moet weten waar je mee bezig bent als jij je klanten garanties over uptimes wilt bieden.
Als eerste zou ik zelf kijken naar geclusterde shared hosting. Indien je naar een goede uptime wilt, maar ook de kosten binnen de perken wilt houden, lijkt me dat een redelijk logische eerste stap als je vanaf een shared webhosting omgeving af komt.
Er zijn volgens mij een aantal partijen die geclusterde hosting ook als shared pakket aanbieden (bijvoorbeeld even googlen levert al veel op).

[djluc]

We hebben voor een eerste testproject gekozen voor http://heroku.com/ zodat we een start-up een Ruby on Rails applicatie kunnen geven. Het is mogelijk dat deze applicatie over een tijdje flink moet gaan schalen. Dus dan is zo'n cloud platform wel handig denk ik. Daarnaast is het zeer betaalbaar en draait het op EC2 wat schaalbaarheid te goede komt.

Ik ben zeer benieuwd hoe dit gaat werken, de installatie e.d. verliepen in elk geval super eenvoudig met wat commando's dus dat is top. Ook ben ik benieuwd hoe het zit met latencies. Omdat we op dit moment een applicatie hebben die relatief traag is maakt dat niet veel uit maar voor andere projecten zal dit wel interessant gaan worden.

Het idee om zelf eens zo'n cluster in elkaar te gaan zetten leeft nog wel. Gelukkig is het op dit moment nog iets te druk maar het gaat komen.