Onderwerp: server indeling voor starters

damn, fijne antwoorden mensen thnx

ik heb inmiddels een oude compaq opgezet met Xen en wat virtuele machines. 2 loadbalancers en 2 webservers. Werkt perfect na een middagje rustig stoeien

als ik de boel klaar en compleet heb komt er hier een howto waarop jullie je mogen uitleven met commentaar

de opzet die ik wil bouwen:

Code:

=== phys1
--virtual1
-loadbalancer/failover
-dns
--virtual2
-www
--virtual3
-postfix
-courier
--virtual4
-mysql
--virtual5
-nfs

=== phys2
--virtual1
-loadbalancer/failover
-dns
--virtual2
-www
--virtual3
-postfix
-courier
--virtual4
-mysql
--virtual5
-controlpanel (+webmail/pma)
-ftp
-dns

en ja, er komen denk ik 3 dns servers en ja, het lijkt mss een virtuele en wellicht onlogische puinhoop maar in feite is dat natuurlijk niet waar het omgaat

Goed plan !
Ik ben i.i.g. benieuwd naar de uitvoer aangezien ik hier ook nog wel wat vm's heb draaien.

Wanneer zien we de 'Howto (become a fullblown webhoster with only this install.sh)' ? hehe

nou binnen nu en enkele weekjes ofzo

ik zit nu al met het volgende: het cp zit op een andere server als de eigelijke webservers... Hoe gaan we dat oplossen met het oog op de users.... /etc/passwd overcopieren lijkt me niet helemaal de bedoeling toch....

en ook de dns servers syncen... kan ik de zone bestanden en de configs op een nfs share dumpen en bind dan eens per X uur herstarten (cronjob) waardoor het die bestanden opnieuw leest ? ik bewerk ze immers maar vanaf 1 host (die met het cp) en de andere 2 _lezen_ slechts... In theorie lijkt me dat wel een aardige methode...

Heb je al eens naar nis gekeken (yp, ypbind e.d.) voor het verdelen van de passwds. Technisch kun je daar ook je dns in kwijt, maar of dat handig is....

kijk eens naar ispman, gebruikt LDAP icm agents op iedere host.

eventueel maak je een eigen versie ervan want de standaard versie is echt afzichtelijk om te zien. Kwa techniek vind ik het een super systeem en ontzettend schaalbaar.

Helaas ligt de ontwikkeling wel behoorlijk stil, maar als je een eigen implementatie maakt is dat natuurlijk geen probleem.

@nzyme,

Ik zit vol interesse te lezen.. wat is de status?

Het is wel interessant als Proof of Concept. Je gaat dit toch niet in productie gebruiken of wel?

Misschien heb ik het fout maar zo te zien heb je wel echt zware servers nodig om zoveel virtual servers te draaien

neej waarom ? je bent als starter echt niet duizenden ditjes of datjes nodig toch

iig, het project loopt behoorlijk anders als "verwacht". Namelijk niet...

ik ben wel tot de volgende bevindingen gekomen:
-redundante storage is mogelijk dmv drbd
-loadbalancers voor een webserver park gaat niet werken: wat gebeurd er als je -een- site host met een php script die een waarde in een file moet zetten (denk aan een teller)... Wat gebeurd er als dit vanaf alle clusterservers tegelijk gebeurd wegens een tiental bezoekers op de site in kwestie ? juist, dan kom je hopeloos in de problemen.

in het kort zijn dat de grote problemen.

Waar ik nu wel mee aan het stoeien ga is het volgende:

een tweetal Xen Debian hosts met daarop een of meerdere DomU's die in een cluster opereren. Moet alleen nog even precies uitzoeken hoe en wat, maar op die manier is de scalability een behoorlijk stap 'lager' dan in de eerste situatie. Immers, het gaat dan om 1 systeem opzich en niet slechts om apache of nfs.

edit: ik ga trouwens wel steeds uit van starters met voorkennis

edit2: ik bedenk met net dat zo'n cluster niet echt zal werken, puur omdat je qua bandbreedte in de problemen zal komen.... Toch denk ik dat de oplossing wel in die hoek gezocht kan worden......

Waarom zou je met bandbreedte in problemen komen, je doet het toch over lokaal netwerk?

Oorspronkelijk geplaatst door nzyme

het project loopt behoorlijk anders als "verwacht". Namelijk niet...

Ehh... Ik houdt wel van een beetje techniek, maar als je d'r een business mee wilt voeren dringt zich toch de vraag op: Waarom?

Is het doel een hoge betrouwbaarheid of juist een hoge prestaties/schaalbaarheid? (beide in termen van zowel 'het systeem' als een individuele site)

Bij je eerste post dacht ik aan betrouwbaarheid, maar je laatste post lijkt meer op capaciteit en gedistribueerde, loadbalanced, sites gericht.

Op zich denk ik dat je aan betrouwbaarheid kan winnen door gebruik te maken van virtualisatie en VM's te verdelen over een paar fysieke machines. Dat is wat wij ook doen (en we beginnen ook maar net met ons managed platform).

Maar voor de capaciteit/schaalbaarheid/performance/loadbalancing zijn de voordelen dan niet zo direct aanwezig. Als bepaalde sites zoveel resources gebruiken dat je ze over verschillende fysieke machines en VM's moet verdelen en gaan loadbalancen, is het wellicht tijd om deze een dedicated server te geven (met een VM fail-over backup misschien).

Het voordeel van VM's is dat je ze lekker snel van de ene naar de andere machine kan 'slepen', en dat je backups kan maken van hele machines en deze, ongeacht het fysieke systeem, snel weer up kan hebben.

Wij gebruiken VM's zowel voor redundante services als ook om een korte downtime/recovery tijd te hebben als er iets misgaat. Hierbij hangt het van de app (in jouw geval wellicht van de site) af of wel bij een calamiteit gaan voor volledige recovery of snel herstellen van de service (fail-over en later alle bits weer integreren).

Onze hosts zijn Windows (vanwege onze apps; we doen eigenlijk geen webhosting) met nogal wat redundantie en gekoppeld aan een gedeelde SAN host voor non-critical files en backups.

George/

Oh... en counters worden meestal apart gehost (om deze reden). Een meer generieke oplossing voor een gedistribueerde site zou een front-end/back-end model kunnen zijn, misschien wel met web-services. Da's schaalbaar 'by design'.