High available cluster samenstellen

[djazete]

Voor een product dat binnen korte tijd live gaat met 5000 (dagelijkse) eind gebruikers van een - gelukkig - niet bedrijfskritisch programma, moet ik een architectuur verzinnen waarop het product gaat draaien. Dat is nu 1 server en dat is niet zo handig.

Er zijn een aantal dingen belangrijk:

1. Availability (uptime)
2. Beveiliging
3. Stabiliteit
4. Backup
5. Uitbreidbaarheid

Geen hele vreemde eisen. Nu draait het geheel op LAMP en na wat geprobeer bevalt Ubuntu mij erg goed.

Wat ik in elk geval wil is meerdere servers die 1 taak doen, dus geen single point of failure qua servers (liefst dan ook redundante switches maar dat spreekt dan voor zich).

Dan kan ik een aantal dingen doen.

1. Twee joekels van servers kopen, de een de andere laten schaduwen en dmv loadbalancing of een ander systeem er voor zorgen dat de 2e backup server inspringt als de 1e uitvalt
2. 4 servers kopen, zelfde als hierboven maar dan gescheiden SQL en web nodes.
3. Loadbalancer met webservers en daarachter MySQL Cluster. Nadeel daarvan is dat ik géen ervaring met MySQL cluster heb en na wat lezen aardig wat nadelen heb gevonden (alle DB's in RAM bv).

In principe voel ik heel veel voor een modulaire opzet zoals bij optie 3 hierboven. Dan kan je als het druk wordt (er bestaat kans dat het aantal eindgebruikers in 2007 nog gaat stijgen naar 15000) er een webserver bij prikken.
Nadeel is dan je SQL bak. Hoe doe ik dat? Met MySQL Cluster zou ik een boel verhelpen denk ik maar is dit uberhaupt productiefähig? En wat zijn de nadelen?

Ik kan dan ook kiezen voor 1 zware SQL bak (zoals T.net) met een replicatie erachter voor de zekerheid.

En daar komt bij, ik heb dit nog nooit gedaan, zo'n park in gericht. Nou kom ik er vermoedelijk wel uit maar ik kán en wil niet alle 'beginnersfouten' maken. Dus misschien moet ik kennis inhuren, maar heb totaal géen idee wie of wat een geschikt bedrijf cq freelance persoon zou zijn. Misschien hebben jullie ook daar ervaringen mee?

[Question Mark]

Waarom High Available als het geen bedrijfs-kritische applicatie is?

[Asteroid9]

Gezien het aantal gebruikers kan ik me daar wel wat bij voorstellen.

Het is maar net hoe je bedrijfskritisch definieert. Het bedrijf zal best wel doordraaien bij een stukje downtime, maar productiviteitsverlies kan ook al een goede reden voor HA zijn.

[Mr_gadget]

Waarom ubuntu? Neem dan gewoon debian, veel veiliger en ubuntu is op debian gebaseerd..alleen dan meer desktopgericht.

Misschien dat de grote supportbedrijven van bv Red Hat kennis voor het inrichten hebben..

[ Voor 7% gewijzigd door Mr_gadget op 06-12-2006 20:28 ]

[Gertjan]

1. Gebruik inderdaad niet Ubuntu, maar Debian als je een stabiel OS/distributie wilt die op Ubuntu lijkt.
2. Gebruik geen MySQL cluster in een productieomgeving

Wat voor type applicatie is het? Kun je de insert/update queries makkelijk scheiden van select queries, en wat zal er voornamelijk gedaan worden? Aan de hand daarvan kan dan iets meer gezegd worden over een MySQL-setup. Nu is het nog gissen. Verkijk je echter niet op de capaciteit van een brute machine: waarschijnlijk doet een Apollo als T.net heeft 5000 clients met twee vingers in de neus. Met een replicating server ben je dan een heel eind.

En niet het minst belangrijk: wat is je budget? Heb je geld om twee loadbalancers, twee webservers en twee brute databaseservers te kopen, of moet je ergens beknibbelen?

[djazete]

In principe is het budget +/- 15000 euro.
Belangrijker is dat het product een runner is voor ons bedrijf en vandaar ook de HA: als het mis gaat dan verlies je niet alleen productiviteit maar ook je gezicht + de kans dat er kantoren gaan bellen en dat willen we niet.

Het zullen veel select queries worden, naar ik vermoed 80% select 20% insert. Dat zou ik nog kunnen nakijken.

Dus geen ubuntu.... ok. Kan ik me iets bij voorstellen maar hun 6.06 LTS lijkt er goed uit te zien.
Moet van te voren wel goed weten of debian/ubuntu of wie dan ook het gaat doen met de hardware die ik wil gebruiken (zal wel iets van HP worden, DL360's ofzo). maar dat komt dan wel. Meestal worden alleen Suse en Red Hat officieel ondersteund.

De applicatie is voornamelijk een gedistributeerde intranet omgeving, waarin content gedistributeerd wordt vanuit 1 bron en aangepast in alle 'clients'. Die zullen dus meer lezen dan schrijven. Ik kan de queries niet scheiden of iets doen aan een database layer of iets dergelijks omdat de applicatie gebouwd is op een bestaand framework.

Een ding wat wel van belang kan zijn is dat elke client zijn eigen database heeft. Dat betekent dus 300 databases (300 kantoren * 15 medewerkers/gebruikers = +/- 4500 eindgebruikers).
Die 300 databases hoeven niet perse op 1 server te draaien, alleen als je die load zou spreiden (bv alle databases A-M server 1, N-Z server 2) dan heb je daar ook weer een extra redudantieslag die je moet maken. Niet superhandig.

Dat Apollo 5000 gebruikers aan kan, dat geloof ik wel. Een dual Xeon quadcore met 16GB ram en weet ik veel wat allemaal zal wel hard gaan, maar probleem is dat het binnen 9 maanden extreem kan groeien en ik ook nog niet écht een goed beeld heb van de belasting. We beginnen sowieso met minimaal 5000 eindgebruikers. Als die (en daar leent het product zich voor) het product als startpagina gaan gebruiken dan heb je kans dat er meer belasting is dan dat dat niet gaat gebeuren, maar dat kan ik nu niet zeggen. En straks komen er waarschijnlijk meer klanten en eindgebruikers, factor 5, bij. Dus schaalbaarheid is misschien niet gek. Waar te beginnen?

[TheBrain]

Je moet zorgen voor meetbare zaken zoals:

- hoeveel transacties
- hoeveel gebruikers (weet je al)
- hoeveel pagina's
- hoeveel acties op de DB per transactie
- verwachte groei van bovenstaande

Op basis daarvan kan je een berekende schatting doen van de specificaties die je nodig hebt.

Architectuur technisch gezien is het altijd een goed idee om web- en databaseservers van elkaar te scheiden. Als het een applicatie is die aan internet hangt is het zelfs te overwegen om alleen de webservers buiten de firewall te plaatsen en de rest binnen (sizing van je firewall throughput gaat dan ook een rol spelen).

Als je zaken dubbel uit moet voeren met kwaliteitsservers dan kom je met die 15000 euro waarschijnlijk niet uit aangezien je ook nog supportcontracten op je hardware in die 15K moet rekenen.