Bekijk Volledige Versie : Services op een server splitsen of niet
Ik vroeg me af waarom mensen ervoor kiezen om alle services op één server dan wel te verdelen over meedere servers.
Wat ik bedoel is het volgende. Stel iemand heeft 3 servers in gebruik dan zijn er de volgende mogelijkheden.
Optie A
- Op elke server Apache, PHP, MySQL, SMTP, POP3 etc.
Optie B
- Server 1: Apache, PHP
- Server 2: MySQL
- Server 3: SMTP / POP3
- Server 4: file server
Ik weet dat veel mensen optie A gebruiken door middel van Bestaande Control Panels als Plesk, Cpanel, DirectAdmin etc. Maar wat zou men doen in de ideale situatie en waarom?
Hier is 't een beetje een twijfelgeval.
Stel: je splitst het op en jouw MySQL server crasht, dan zitten al jouw klanten zonder MySQL.
In de situatie waar alle services op alle servers draaien, dan kan er gerust 1 crashen en zullen de overige gewoon doorwerken.
Echter 'verlies' je een hoop processing kracht door alles te draaien.
Deimos,
Ik denk dat je met een beetje kennis van zaken een controle paneel ook over meerdere servers kan verdelen.
Denk alleen dat je dan moet weten wat waar en hoe stuur ik dit aan :-)
Plesk bijvoorbeeld heeft ook al een oplossing voor clusters cq. Plesk Expand.
Persoonlijk zou ik voor een clustering optie gaan... eventueel inclusief hardware firewall (of OpenBSD/FreeBSD pf based firewalling of linux als je je daar in thuis voelt)
Echter kan ik me ook voorstellen dat iemand zoiets heeft van ik laat elke server "alle" services draaien omdat dit dan betekend als er 1 server plat gaat dat je dan een handje vol klanten last van hebben en doe je Optie B dan hebben al je klanten er last van.
Alles opsplitsen is de boodschap. Voor 1,2 of 3 servers te hebben die alle services draaien, dan valt dit nog mee, maar eenmaal je nog meer servers zal moeten gaan draaien, dan is het al onoverzichtelijk en moeilijker te beheren.
De enige reden lijkt me waarom dat mensen alle services op elke server draaien, is omdat dat de makkelijkste manier is in combinatie met een commerciel controle paneel zoals cpanel/plesk/en anderen. Word je serverpark iets groter, dan ga je toch naar een gesplitste omgeving moeten overgaan, omdat dit veel makkelijker te beheren valt.
Origineel geplaatst door Deimos
Ik vroeg me af waarom mensen ervoor kiezen om alle services op één server dan wel te verdelen over meedere servers.
Wat ik bedoel is het volgende. Stel iemand heeft 3 servers in gebruik dan zijn er de volgende mogelijkheden.
Optie A
- Op elke server Apache, PHP, MySQL, SMTP, POP3 etc.
Optie B
- Server 1: Apache, PHP
- Server 2: MySQL
- Server 3: SMTP / POP3
- Server 4: file server
Ik weet dat veel mensen optie A gebruiken door middel van Bestaande Control Panels als Plesk, Cpanel, DirectAdmin etc. Maar wat zou men doen in de ideale situatie en waarom?
Ik prefereer een server per functie. Dit heeft een paar voordelen maar voor velen een groot nadeel, de meeste control panels kunnen er namelijk niet echt super mee overweg :)
De voordelen van services splitsen zijn:
- 1 Server dood betekend niet meteen je complete bedrijf dood
- Makkelijker servers te vervangen (je hoeft enkel 1 service tijdelijk down te gooien)
- Hardware kan specifiek afgestemd worden op service, netzoals partitionering en dergelijke.
Wel makkelijker te beheren. Maar de kans op problemen is veel groter. Tenzij je alles redundant gaat uitvoeren (dus ook: meerdere datacentra) maar dat gaat je tonnen aan investeringen kosten.
Even de voordelen van de reactie boven mij weerleggen:
"De voordelen van services splitsen zijn:
- 1 Server dood betekend niet meteen je complete bedrijf dood
Als je MySQL server crasht liggen wel ál je klanten plat in plaats van een deel van je klanten
- Makkelijker servers te vervangen (je hoeft enkel 1 service tijdelijk down te gooien)
1 server down gooien (bijvoorbeeld MySQL) heeft gevolg op ál je klanten die geen gebruik kunnen maken van MySQL.
- Hardware kan specifiek afgestemd worden op service, netzoals partitionering en dergelijke.
Volledig mee eens"
Origineel geplaatst door eMiz0r
Wel makkelijker te beheren. Maar de kans op problemen is veel groter. Tenzij je alles redundant gaat uitvoeren (dus ook: meerdere datacentra) maar dat gaat je tonnen aan investeringen kosten.
Even de voordelen van de reactie boven mij weerleggen:
"De voordelen van services splitsen zijn:
- 1 Server dood betekend niet meteen je complete bedrijf dood
Als je MySQL server crasht liggen wel ál je klanten plat in plaats van een deel van je klanten
Als al je klanten op 1 server draaien zijn ook al je klanten stuk. Daarnaast hebben klanten die geen MySQL gebruiken helemaal geen last ervan terwijl dit wel het geval kan zijn als ze op dezelfde server draaien, Daarnaast voer je je onderhoud toch uit in daluren dus er is minimale downtime.
- Makkelijker servers te vervangen (je hoeft enkel 1 service tijdelijk down te gooien)
1 server down gooien (bijvoorbeeld MySQL) heeft gevolg op ál je klanten die geen gebruik kunnen maken van MySQL.
Je hoeft wel maar 1 server down te gooien voor updates, ipv meerderen. Het maakt het een stuk makkelijker voor jezelf.
Cliff,
Dat gaat op als je niet meer dan 200 klanten hebt. Geloof mij dat als je meer dan 6000 klanten hebt je niet wilt dat al je klanten ineens geen gebruik meer kunnen maken van MySQL. Als 1 server er uit klapt (om welke reden dan ook) is de schade beperkt :)
Origineel geplaatst door eMiz0r
Cliff,
Dat gaat op als je niet meer dan 200 klanten hebt. Geloof mij dat als je meer dan 6000 klanten hebt je niet wilt dat al je klanten ineens geen gebruik meer kunnen maken van MySQL. Als 1 server er uit klapt (om welke reden dan ook) is de schade beperkt :)
Je zult altijd downtime moeten introduceren voor updates en upgrades. Voor de rest zorg je dat je db servers online blijven. Je kunt altijd services blijven spreiden, maar als je alleen maar 'complete' servers blijft neerstampen verdwijnt je overzicht al snel als je er meer als 5 draait. Alle grote shared hosting platformen die ik ken hebben een aantal dedicated mysql servers staan. En daarna een hele stapel webservers. Dat is ook mijn punt, de services scheiden van elkaar. Jij maakt daarvan maar 1 mysql server draaien. (Liever wil je helemaal geen MySQL maarja).
Gelukkig houd ik me niet bezig met webhosting, veels te veel gepiel in de marge en veels te veel gezeik.
clownyenator
01/11/05, 16:09
of gewoon 10 servers zelfde config draaien met een hot-spare langs de lijn die de server overneemt die down is... *ip-change script met heartbeat*
Origineel geplaatst door clownyenator
of gewoon 10 servers zelfde config draaien met een hot-spare langs de lijn die de server overneemt die down is... *ip-change script met heartbeat*
Jep en van 10 servers alle shit nog eens backuppen zodat de hotspare wel met de goede data gaat draaien...
jinxedworld
01/11/05, 17:00
Origineel geplaatst door WE-Create!
Jep en van 10 servers alle shit nog eens backuppen zodat de hotspare wel met de goede data gaat draaien...
Of alles op 2 grote storagebakken draaien, welke synchroon draaien, en de data via NFS mounten naar je slave-bakken (MySQL, Web, Mail). Round-Robin DNS erachter, of loadbalancen, uiteraard redundant.
Uh, wat is het prijskaartje van zulke oplossingen?
jinxedworld
01/11/05, 17:01
Origineel geplaatst door frvge
Uh, wat is het prijskaartje van zulke oplossingen?
Niet weinig :-)
Origineel geplaatst door frvge
Uh, wat is het prijskaartje van zulke oplossingen?
afhankelijk van de kwaliteit en het aantal servers kan dit redelijk in de papieren lopen. echter zal je totale uptime er weer door omhoog gaan als je het goed doet (updates aan software kunnen zonder downtime, hdd crach niet gelijk de sites offline).
Ik ben voor optie A.
Dat betekent:
- Slechts 100 sites die plat liggen bij uitval van een server, i.p.v. grofweg 2000 (in ons geval)
- Nieuwe klanten komen op de nieuwste servers en dus op de snelste, je gaat dus automatisch met je tijd mee en blijft concurrerend
- Minder risico op abuse (hooguit één server per keer die hinder ondervindt)
Ik ben voor een load balanced solution. Onze situatie bijvoorbeeld:
Alteon loadbalancers
2 synched controle paneel servers
2 servers als communicatie laag cp - cluster
12 webservers
2 x 2 fileservers in raid-50 en synched
5 mailservers
4 x 2 SQL servers (Synched per paar)
In dit geval kun je probleemloos upgrades uitvoeren zonder dat een klant het merkt. Upgrades aan webserver software doe je per server. Is er te weinig CPU power dan voeg je een node erbij. Is een node stuk, vervang je hem.
Idem met de fileservers, deze draaien raid-50 (dus soort van gekopieerde raid-5) en ook nog een synched met elkaar. De fileservers bewaren alleen html/webdata, de SQL en mailservers hebben hun eigen schijven (wederom Raid-50)
Al met al valt het kostenplaatje van deze uitvoering wel mee, groot nadeel is dat je echt zelf je control panel software moet ontwerpen of je zit vast aan zoiets als HELM, na veel wikken en wegen hebben we destijds besloten om zelf het controle paneel te maken.
tot nu toe geen moment spijt ervan, als een server platgaat merkt niemand het, als we upgrades uitvoeren mertk niemand het, backups maken gaat probleemloos zonder performance verlies, billing is veel handiger, accounts zijn uitbreidbaar zonder dat we ze moeten verplaatsen naar andere server etc.
Het is in ieder geval heel belangrijk dat je direct de juiste keuze maakt. Later switchen is lastig, al dan niet onmogelijk.
Optie A lijkt me in elk geval geen goede keuze. Om te beginnen noem je POP3 en SMTP als services - met A heb je drie praktisch identieke services lopen die je nu elk handmatig moet bijhouden, patchen, blacklists updaten, etc. Backups moet je nu ook van verschillende machines gaan maken - allemaal ellende.
Ik stel een aanpassing van optie B voor.
Server 1 levert de publieke services, dus Apache/PHP, POP3, SMTP.
Server 2 de MySQL server en wellicht een LDAP server voor user management en andere configuratie meuk (kan ook alleen in MySQL gebeuren). Dit is waar alle services op Server 1 hun variabelen vandaan halen. Data files voor deze services staan echter op..
Server 3 - De fileserver. Hier heb je je databases, user data, etc staan. NFS mounts richting Server 1 en 2.
Server 4 - mirror van de fileserver (no 3). Configs + data is het aller belangrijkste. Als je al het andere verliest maar je hebt dit nog is het prima mogelijk om alles weer snel op te bouwen. Rsync, Intermezzo, maakt allemaal niet zoveel uit.
Daarnaast is het een goed idee om server data niet op IP adres te doen. (Dus geen '$db_server = '12.12.12.12'; ). Gebruik generieke service namen. Hou deze in een hosts file bij en synchroniseer deze over alle machines - dan ben je niet afhankelijk van DNS en kan je je services makkelijk uitbreiden. Dit geldt trouwens ook voor de Optie A situatie waar je maar een server hebt maar later wellicht wil uitbreiden. Als je overal 'localhost' gebruikt wordt dit vervelend, maar als je in hosts een entry
127.0.0.1 localhost xxx.xxx.xx db-01.internal.example.com
hebt wordt het makkelijk om mysql naar een andere machine te verhuizen, hosts aan te passen comme ca,
127.0.0.1 localhost xxxx.xxxx.xx
10.0.0.10 db-01.internal.example.com
Let er natuurlijk wel op dat de DB user nu via het management net verbinding mag maken (lang leve het UPDATE statement!)
Het voordeel van zo'n opstelling is dat je je flexibel opstelt (zonder er extra geld aan te besteden..) en ruimte laat om replicatie, load-balancing, etc in te bouwen op knelpunten als je gaat schalen.
Daarnaast nog even een opmerking over Apache/PHP - vaak is het PHP die erg veel CPU time en memory consumeert. Met lighttpd op een machine met idioot lage specs heb ik wel eens hoge performance behaald door daarachter dedicated PHP machines neer te zetten. http://www.lighttpd.net/ heeft wel wat voorbeelden staan.
Origineel geplaatst door mpk
Daarnaast nog even een opmerking over Apache/PHP - vaak is het PHP die erg veel CPU time en memory consumeert. Met lighttpd op een machine met idioot lage specs heb ik wel eens hoge performance behaald door daarachter dedicated PHP machines neer te zetten. http://www.lighttpd.net/ heeft wel wat voorbeelden staan.
Dit vind ik zeer interssant. Op dit moment draaien wij namelijk PHP icm suphp(.org) om ervoor te zorgen dat alles netjes onder zijn / haar uid / gid draait. Dit heeft echter als nadeel dat je PHP als CGI module dient te gebruiken ipv als MOD van bijvoorbeeld apache. Nu komt het de laatste tijd geregeld voor dat Apache idd bijna niets te doen heeft maar dat PHP de resource vreter is.
Nu heb ik op de site van lighttpd.net gekeken maar kon daar zo 123 niet een vorobeeld vinden om PHP en Httpd te scheiden (het kan zijn dat ik er over heen heb gelezen / gekeken). Mocht iemand dan ook hier nog iets meer informatie over hebben, dan verneem ik dit graag. :)
enige probleem van apache/php vind ik dat je niet beiden onder de user kunt draaien, dit is handig als je snel wilt kunnen achterhalen wie veel resources van je servers vragen. daarnaast zou het handig zijn om per gebruiker in dat geval in te stellen dat ze bijvoorbeeld 5% van de hoeveelheid ram mogen gebruiken en hetzelfde geld voor de processor kracht. dan hebben namelijk andere klanten minder last als 1 klant extreem slechte scripts heeft (een cluster met een loadbalancer is in deze situatie optimaal).
Origineel geplaatst door Mark17
enige probleem van apache/php vind ik dat je niet beiden onder de user kunt draaien, dit is handig als je snel wilt kunnen achterhalen wie veel resources van je servers vragen. daarnaast zou het handig zijn om per gebruiker in dat geval in te stellen dat ze bijvoorbeeld 5% van de hoeveelheid ram mogen gebruiken en hetzelfde geld voor de processor kracht. dan hebben namelijk andere klanten minder last als 1 klant extreem slechte scripts heeft (een cluster met een loadbalancer is in deze situatie optimaal). Dit is o.a. mogelijk dmv suphp / apache 2. Maar daar gaat het niet om in dit verhaal. ;)
Origineel geplaatst door Deimos
Nu heb ik op de site van lighttpd.net gekeken maar kon daar zo 123 niet een vorobeeld vinden om PHP en Httpd te scheiden (het kan zijn dat ik er over heen heb gelezen / gekeken). Mocht iemand dan ook hier nog iets meer informatie over hebben, dan verneem ik dit graag. :)
OK, komt 'ie :)
In lighttpd.conf de fastcgi mod enable'n en dan een handler voor de extensies php toevoegen (kan ook op vhost basis, maar dat laten we er even uit),
fastcgi.server = ( ".php" =>
( "php-server" =>
( "host" => "10.0.0.10",
"port" => 1066 )
),
)
Of load-balanced,
fastcgi.server = ( ".php" =>
(
"php-server-01" =>
( "host" => "10.0.0.10",
"port" => 1066 ),
"php-server-02" =>
( "host" => "10.0.0.10",
"port" => 1066 ),
"php-server-03" =>
( "host" => "10.0.0.10",
"port" => 1066 ),
),
)
Nu moet je PHP natuurlijk als stand-alone process draaien.. Daarvoor gebruik ik het meegeleverde spawn-php.sh script,
#!/bin/bash
## ABSOLUTE path to the spawn-fcgi binary
SPAWNFCGI="/usr/local/bin/spawn-fcgi"
## ABSOLUTE path to the PHP binary
FCGIPROGRAM="/usr/local/bin/php"
## bind to tcp-port on localhost
FCGIPORT="1066"
## number of PHP childs to spawn
PHP_FCGI_CHILDREN=3
## number of request server by a single php-process until is will be restarted
PHP_FCGI_MAX_REQUESTS=1000
## IP adresses where PHP should access server connections from
FCGI_WEB_SERVER_ADDRS="10.0.0.100"
# allowed environment variables sperated by spaces
ALLOWED_ENV="ORACLE_HOME PATH USER"
## if this script is run as root switch to the following user
USERID=wwwrun
GROUPID=wwwrun
################## no config below this line
if test x$PHP_FCGI_CHILDREN = x; then
PHP_FCGI_CHILDREN=5
fi
export PHP_FCGI_MAX_REQUESTS
export FCGI_WEB_SERVER_ADDRS
ALLOWED_ENV="$ALLOWED_ENV PHP_FCGI_MAX_REQUESTS FCGI_WEB_SERVER_ADDRS"
if test x$UID = x0; then
EX="$SPAWNFCGI -p $FCGIPORT -f $FCGIPROGRAM -u $USERID -g $GROUPID -C $PHP_FCGI_CHILDREN"
else
EX="$SPAWNFCGI -p $FCGIPORT -f $FCGIPROGRAM -C $PHP_FCGI_CHILDREN"
fi
D_ENV="ORACLE_HOME PATH USER"
# copy the allowed environment variables
E=
for i in $ALLOWED_ENV; do
E="$E $i=${!i}"
done
# clean environment and set up a new one
env - $E $EX
Verder kan je php natuurlijk tweaken in php.ini zoals je gewend bent.
De exacte instellingen wisselen natuurlijk per setup, dus het hangt er een beetje van af wat je precies wil doen.
Origineel geplaatst door mpk
KNIP
WHOO woot woot, waar kan ik de donatie "kusje achter het oor" heen sturen ? Dit is precies wat we op korte termijn nodig hebben. Tevens hoe stable/snel is dit ?
Origineel geplaatst door Mikey
WHOO woot woot, waar kan ik de donatie "kusje achter het oor" heen sturen ? Dit is precies wat we op korte termijn nodig hebben. Tevens hoe stable/snel is dit ?
Verbazingwekkend stabiel, eigenlijk. Van PHP is dat niet zo gek, het is tenslotte een 'mature codebase' - maar toen ik lighttpd voor het eerst probeerde was ik daar natuurlijk niet zo zeker over. Een paar maanden met lighttpd + SCGI/Rails en FCGI/PHP later was die onzekerheid wel over. Ik heb van lighttpd tot nog toe geen memory leaks of anderzijds spontaan falen meegemaakt.
Ook het schrijven (of genereren) van config files werkt lekker. Je kan natuurlijk files includen en je kan in de config gebruik maken van conditionals en variables zoals,
Zo heb ik een lighttpd.conf met een regel,
include "vhosts.conf"
vhosts.conf wordt automatisch gegenereerd en zit vol met blokken als,
$HTTP["host"] =~ "example.org" {
var.hostname = "www.example.org"
include "vhostconfig.conf"
}
en in vhostconfig.conf (die dus op elke vhost toegepast wordt..)
server.document-root = "/www/vhosts/" + hostname + "/html/"
accesslog.filename = "/www/vhosts/" + hostname + "/log/access.log"
$HTTP["referer"] !~ "(hostname)" {
url.access-deny = ( ".jpg", ".jpeg", ".png", ".mpg", ".mpeg", ".gif" )
}
Het enige wat me nog een klein beetje dwars zit bij 'lighty' is dat de reload een start/stop is (wel graceful vanaf 1.4.3), maar dat is een klein detail.
http://trac.lighttpd.net/trac/file/branches/lighttpd-merge-1.4.x/doc/rc.lighttpd?rev=686
Ohja, en er is geen mod_svn voor lighttpd. Dat is het enige wat me echt stoort...
Performance is prima - maar zoals altijd hangt het van je omgeving af. Test en tweak voordat je naar produktie gaat :)
[edit : config typo fixed]
Ik kan niet anders zeggen dan verbazendwekkend....
Dit ziet er wel HEEL goed uit :). Nu eens gaan bekijken hoe we het cluster gaan inrichten :D.
Origineel geplaatst door eMiz0r
Wel makkelijker te beheren. Maar de kans op problemen is veel groter. Tenzij je alles redundant gaat uitvoeren (dus ook: meerdere datacentra) maar dat gaat je tonnen aan investeringen kosten.
Even de voordelen van de reactie boven mij weerleggen:
"De voordelen van services splitsen zijn:
- 1 Server dood betekend niet meteen je complete bedrijf dood
Als je MySQL server crasht liggen wel ál je klanten plat in plaats van een deel van je klanten
- Makkelijker servers te vervangen (je hoeft enkel 1 service tijdelijk down te gooien)
1 server down gooien (bijvoorbeeld MySQL) heeft gevolg op ál je klanten die geen gebruik kunnen maken van MySQL.
- Hardware kan specifiek afgestemd worden op service, netzoals partitionering en dergelijke.
Volledig mee eens"
Je moet uiteraard ook fall backs hebben draaien hé ;)
Origineel geplaatst door Jacobs.T
Je moet uiteraard ook fall backs hebben draaien hé ;)
Die óf:
- niet consistent zijn zodra de hoofdserver uitvalt
- of je data real-time synched en uitermate gevoelig bent voor succesvolle hackpogingen (en kwaadwillende gasten hou je niet buiten de deur :))
Inmiddels een minder subtiele kick. Maar naar aanleiding van bovenstaande ben ik op dit moment aan het testen met lighttpd icm fastcgi. Nu vraag ik me alleen af of mensen ook daadwerkelijk php en http hebben gesplitst over verschillende servers. En indien ja, hoe men er vervolgens voor heeft gezorgt dat elke gebruiker toch PHP onder zijn uid/gid draait. Dit aangezien (als ik het goed heb begrepen) eigenlijk voor elke user een eigen fastcgi php deamon moet draaien als je aparte permissies wilt. Kortom, heb je 1000 fysieke users, dan zul je in theorie ook 1000 verschillende fastcgi-php deamons moeten draaien. Dit lijkt me ook niet geheel wenselijk, of heb ik nu iets over het hoofd gezien? Of is er wellicht nog een andere methode om PHP onder de eigen uid/gid te draaien...?!?
Inmiddels een minder subtiele kick. Maar naar aanleiding van bovenstaande ben ik op dit moment aan het testen met lighttpd icm fastcgi. Nu vraag ik me alleen af of mensen ook daadwerkelijk php en http hebben gesplitst over verschillende servers. En indien ja, hoe men er vervolgens voor heeft gezorgt dat elke gebruiker toch PHP onder zijn uid/gid draait. Dit aangezien (als ik het goed heb begrepen) eigenlijk voor elke user een eigen fastcgi php deamon moet draaien als je aparte permissies wilt. Kortom, heb je 1000 fysieke users, dan zul je in theorie ook 1000 verschillende fastcgi-php deamons moeten draaien. Dit lijkt me ook niet geheel wenselijk, of heb ik nu iets over het hoofd gezien? Of is er wellicht nog een andere methode om PHP onder de eigen uid/gid te draaien...?!?
PHP dat op een externe server draait en meerdere servers/klanten bedient ben ik nog niet tegen gekomen en ik vraag me af of dit wel mogelijk is. Iemand die hier meer over kan vertellen?