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.