Onderwerp: Services op een server splitsen of niet

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

Code:

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,

Code:

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),

Code:

fastcgi.server = ( ".php" =>
                   ( "php-server" =>
                     ( "host" => "10.0.0.10",
                       "port" => 1066 )
                   ),
                 )

Of load-balanced,

Code:

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,

Code:

#!/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,

Code:

include "vhosts.conf"

vhosts.conf wordt automatisch gegenereerd en zit vol met blokken als,

Code:

$HTTP["host"] =~ "example.org" {
  var.hostname          = "www.example.org"
  include "vhostconfig.conf"
}

en in vhostconfig.conf (die dus op elke vhost toegepast wordt..)

Code:

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/b...ghttpd?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 .

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...?!?