PDA

Bekijk Volledige Versie : Poor man's availability cluster



Riven
02/11/08, 17:15
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.

avanmessen
02/11/08, 17:30
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 ...

Riven
02/11/08, 17:37
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?

avanmessen
02/11/08, 18:41
Al meer dan genoeg denk ik, misschien een post
plaatsen in de "Aanbiedingen gezocht" sectie !?

:thumbup:

Riven
02/11/08, 19:26
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?

SF-Jeroen
02/11/08, 19:59
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).

Riven
02/11/08, 20:05
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.

avanmessen
02/11/08, 22:29
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 !

:yes:

Wemag
02/11/08, 22:40
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/

Randy
02/11/08, 22:52
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?

Riven
02/11/08, 23:30
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.

Freezer
03/11/08, 09:50
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?

wonko
03/11/08, 12:32
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.

Riven
04/11/08, 01:21
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.

Mikey
04/11/08, 12:46
afhankelijk om hoeveel data het gaat, maar drdb is prima in staat om over het netwerk data synchroom te houden.

t.bloo
04/11/08, 13:17
DNS is geen ding om snel wijzigingen in te maken, dat wordt namelijk overal gecached.

Je zou het zo aan kunnen pakken, maar of dat voor het genoemde budget lukt weet ik niet:
* meerdere servers (VPS ofzo) waar je programma op draait
* iedere server heeft een DNS entry: server1.nogwat, server2.nogwat, server3.nogwat
* deze DNS beheer je zelf op meerdere nameservers
* zorg dat de nameservers in je "nogwat" record niet allemaal dezelfde tld hebben
* laat je client random connecten op domein basis met een van de servers uit je lijstje
* het onderling synchroniseren daar had je al wat voor

Dreas
04/11/08, 13:34
Wat je ook kan doen .. is alles eerst lokaal op de server wegschrijven .. en vervolgens steeds migreren naar de logging server. Als je lokale server down is is er ook geen logging. Als je logging server down is, dan wordt de boel op je lokale server "gequeued"