Onderwerp: Poor man's availability cluster

Beste,

Voor een hosted logging applicatie heb ik een zeer hoge availability nodig, waar 'de service' liefst geen minuut downtime heeft. Nu lijkt mij dat je dat met 1 server niet kunt bereiken, dus heb je al gauw meerdere servers in verschillende racks/datacenters nodig om het risico van server- / netwerkproblemen te spreiden. Op het moment dat de service er (als geheel) uit ligt merken klanten dit namelijk gelijk door een gat in hun statistieken.

Nu is het loggen van data niet echt een CPU / memory intensieve taak. Ik heb het programma zo geschreven dat er enkel SELECT (op prim keys) / INSERT queries naar de database gaan, dus de queries zijn doodeenvoudig en zouden de CPU en HDD voornamelijk laten idle-n. De verwachtte read:write verhouding is resp. 1:1000.

Nu wil ik op het oog van de kosten niet voor dedicated servers gaan, maar voor (een groeiend aantal) VPS accounts, daar deze over het algemeen over veel betere hardware beschikken (en 'dus' uptime) dan voor dat geld zelf samen te stellen / te huren is.

Nu is de hele applicatie technisch doodeenvoudig: inkomende HTTP data parsen en direct de DB in. Af en toe wordt enkele uren oude data uit de DB gewipt en sterk compressed als bestandje weggeschreven (of als binary data weer de DB in). Deze 'chunks' worden tussen de nodes verspreid.

Tot zover mijn plannen. Is een dergelijk ontwerp geschikt? Is het een goed idee om zo'n high availability service te draaien op een vloot VPS accounts met goede hardware (minimaal RAID1, ECC RAM, Xeon CPUs) ? Of zouden jullie dit helemaal anders doen. Let wel, budget is beperkt (<100e/m) zolang de service geen groot klantenbestand kent.

Hangt natuurlijk ook af van de verdere specs die je hebt !
Voor een 100-tal Euro per maand geraakt je wel rond met
twee VPSen, dedicated wordt dit al wat moeilijker ...

Ik verwacht dat een VPS van 256MB RAM, ~5GB HDD en 50GB traffic al meer dan genoeg is. Ik denk dat ik net 3 VPS accounts kan hebben voor dat geld: 2x normaal (40 euro) en 1x budget (20 euro) als 'last resort'.

Verder natuurlijk Linux.

Welke specs zijn er nog meer relevant?

Al meer dan genoeg denk ik, misschien een post
plaatsen in de "Aanbiedingen gezocht" sectie !?

Ik ben deze thread eigenlijk meer begonnen om feedback te krijgen op het plan.

Mag ik aannemen - aangezien jullie al aan de volgende stap denken - dat het met het ontwerp wel snor zit?

En hoe had je het redunant maken in gedachten dan? Ik bedoel hoe wil je gaan zorgen dat als server A offline is, server B de taken overneemt?

Bovendien vind ik het plan een paar budget vpssen te huren bijzonder slecht. Dan kan je beter 1 goede (met SLA's) vps huren van een gerenommeerd hostingbedrijf (en netwerk).

Client X doet een request naar A. Bij een timeout/error doet X een connect naar B, daarna C, D, etc...

Er zit dus een klein beetje intelligentie in de client, da's misschien het zwakke punt.

Ik zat ook te denken aan een systeem als een loadbalancer, maar dan met maar 1 target (bijv. A), tot die ermee uit scheidt, waarna alle traffic naar B doorgestuurd wordt. Voordeel is dat de client maar met 1 IP hoeft te communiceren, nadeel is dat als de loadbalancer/proxy(?) eruit ligt je geen fallback hebt.

High-availability onder linux is voor twee
machines, verbonden met een LAN of een
crossed cable bvb, de ene machine is dan
backup voor de andere.

Info op http://www.linux-ha.org

Je zou dit op VPS basis ook kunnen doen
maar dan zit je waarschijnlijk op dezelfde
server of netwerk en dan moet je een 2de
virtual NIC hebben om de twee VPSen aan
mekaar te verbinden.

Het klinkt ernaar dat de intelligentie in de
client zal moeten zitten.

Heb zelf met high-availability zitten spelen
in een firewall concept, onder OpenBSD met
CARP (proprietary protocol). Hoop dat je wat
interessante input krijgt van anderen, meer in
verband met jouw specifieke project !

Wat in een hele andere hoek zit maar misschien nog interessant is om te overwegen:
Amazon EC2 icm Amazon S3. Amazon EC2 is een cloud computing dienst die je in staat stelt om "instant" VPS-en aan te maken die achteraf gefactureerd worden op basis van daadwerkelijk aantal uren gebruik. Het handige in jouw situatie is dat je zelf kan beslissen in welk Amazon datacentrum (verspreid over de hele wereld) je jouw VPS wilt hebben.
Zodra het VPS is aangemaakt kun je ook intern via een web interface/ API IP's omrouten.

Omdat alles dus ook via de API te benaderen is zou je mbv scripts automatisch je applicatie in een nieuwe VPS op een ander continent kunnen starten zodat 1 VPS down gaat. Het voordeel hiervan is dat je niet dubbel betaald voor een VPS dat je toch niet gebruikt. Nadeel dat een VPS oplossing waarschijnlijk goedkoper is.

Er zijn overigens ook bedrijven die de scripts voor High Availability op basis van Amazon EC2 geschreven hebben en netjes gebundeld hebben in een web interface. Hier zijn echter wel kosten aan verbonden. Voorbeelden zijn RightScale en Scalr (https://scalr.net/login.php). Van Scalr is een deel ook open source: http://code.google.com/p/scalr/

Een hoop mensen roepen hier alweer wat, maar op basis van wat werkt de logging applicatie: Java / J2EE i.c.m. bijvooorbeeld Apache Tomcat of welk platform wil je gebruiken?

Het is inderdaad geschreven in Java. De applicatie draait niet binnen een framework, het is simpelweg Java SE met wat eigen classes. Het technische deel is zo idioot simpel dat ik al die overhead van J2EE niet wil. Ik heb een eigen op Java NIO gebaseerde HTTP/1.1 server geschreven, die zich al bewezen heeft in een productie omgeving met een uptime van enkele maanden.

Over elke verbinding komen meerdere requests binnen, die na het parsen en valideren vrijwel 1-op-1 in een MySQL database terecht komen. Het is allemaal zo eenvoudig dat ik denk dat een PIII al zou staan te niksen.

Het is dus allemaal extreem licht van opzet, de JRE heeft een heap van 64MB of minder (!). Het enige wat performance eist is het af en toe leeg trekken van de DB, comprimeren, en opslaan van dat 'archief'.

Het 'echte' werk, gebeurt in een desktop app die die archieven van de server trekt en er, met behulp van 101 filters, grafieken en tabellen uit tovert.

Ik zou waarschijnlijk toe kunnen met een VPS van 128MB, maar om onverhoopt niet te gaan swappen lijkt 256MB een veiligere keuze. Serverside zijn er dus bijna geen eisen, als de boel maar in de lucht blijft om de data binnen te halen.

Trouwens, je stelt dat de writes minder belasting dan een read opleveren. Vaak is het juist andersom, omdat de reads vaak direct uit het geheugen kunnen worden gedaan, wat geen i/o (=traag) aktie tot gevolg heeft. Zeker budget vps'en hebben vaak limieten op het aantal i/o bewerkingen, en als je dus veel i/o hebt (wat je dus hebt omdat je steeds writes doet) is het wel zaak om rekening mee te houden dat je niet een vps krijgt waar z'n beperking op zit.

Opzich je idee is goed, maar is het niet eenvoudiger om je nodes allemaal dezelfde data te laten lezen en per node alle data te hebben? ipv het rondedelen, heb je bv 3 nodes met alle data. De kans dat alle 3 down zijn is dan een stuk kleiner?

hiervoor raad ik je aan om toch even je plan voor te leggen aan een hoster met ervaring. Hoe ga je bvb databases syncroon houden over de verschillende locaties, en wat als er eentje offline gegaan is, en die komt terug? Waar zit de "hoofd"-databank?

Het is perfect mogelijk om dit uit te bouwen, en aangezien je de client-kant en de server-kant beheert is het mogelijk om allerlei oplossingen in te bouwen, maar het gaat niet lukken met een budgetje van 100 euro per maand.

Er is inderdaad een synchronisatie probleem, als er 1 node uitvalt. Er is een kans dat een deel van de data verloren gaat, als de node echt stuk is - oplossing daarvoor is om data altijd naar minstens 2 actieve (random) nodes te sturen. In alle andere gevallen komt de node weer online, en gaat weer zijn data vergelijken met de andere nodes, waarna bij beiden de ontbrekende delen aangevuld worden. Er is dus geen master/slave relatie. Iedere node vult bij een ander aan wat hij wel heeft en de ander niet.

Het gaat hier niet om het synchroniseren van een database, maar om de 'archieven' (data uit de database van 1-2uur oud). Dit zijn bestandjes van minder dan 1MB en kunnen snel rondgestuurd worden. Bestandjes kunnen ge-merged worden met bestandjes van diezelfde periode van een andere server. Uiteindelijk heb je dus een reeks bestandjes die - als ze meer dan 2 uur oud zijn, nooit meer zullen veranderen (mits alle nodes up zijn). Het synchroon houden hiervan is eenvoudig.

Ik heb dus een soort P2P systeem in gedachten van 3+ servers die constant met elkaar communiceren en waarbij met een kleine vertraging op alle nodes uiteindelijk dezelfde data staat.

Wat ik mij nog afvraag is hoe betrouwbaar/stabiel een proxy nou eigenlijk kan zijn. Ik heb het niet zo op een single-point-of-failure, maar uiteindelijk hebben alle sites hiermee te maken. Waarschijnlijk maak ik me te druk om de stabiliteit van de frontend, en ligt de kunst van het online houden van de service eerder bij de cluster backend. De frontend heb je 'zo' vervangen met een DNS wijziging, waarna de cluster weer zijn ding doet. Ik ben als devver vooral gericht op software (als het werkt, werkt het) maar in de afgelopen tijd ben ik me uit pure noodzaak ook met systeembeheer bezig gaan houden waar naar mijn ervaring hele andere regels gelden. Ik ben vooral geinteresseerd hoe ik voor die paar centen en een goed ontwerp toch een stabiel systeem kan krijgen met een streven van >99.9% uptime.

afhankelijk om hoeveel data het gaat, maar drdb is prima in staat om over het netwerk data synchroom te houden.