[PPNL-Techteam] VM's en IP's
Casper Gielen
casper at gielen.name
Mon Jun 11 20:23:27 CEST 2012
On 06/11/12 13:35, Sander Plas wrote:
> Even onder voorbehoud :) maar zolang het binnen redelijke proporties blijft hoeft dat geen geld te
> kosten. Als opeens ons halve rack vol PP spul hangt wordt het wel een ander verhaal;)
>
> Ik zou wel het liefst eerst kijken of er inderdaad niet "past" op de huidige hardware. Is ook wat
> makkelijker uit te leggen aan mijn collega's (niet-piraten) hier als onze "sponsorklant" simpelweg
> uit de hardware is gegroeid dan dat ik nu bij voorbaat al allerlei extra apparatuur ga reserveren
> terwijl de site (en sponsorpagina;P) nog niet eens op de server staan.
>
Ik ben voldoende overtuigd van de mogelijkheden bij Seeas (en de goede bedoelingen van Sander) dat
ik het niet nodig vind om nu al extra hardware te claimen.Dat zien we wel weer als het nodig is.
4G is wat krap, maar we draaien nu alles uit 2G, dus het moet maar lukken.
Ik wil sowieso niet alles meeverhuizen. Ik ben van plan om tpb en lqfb achter te laten op de huidige
host.
Ik zit nog te dubben over de VMs. Op m'n eigen systemen maak ik voor iedere scheet een VM aan, maar
daar dit ik zeer ruim in de resources.
Een paar ideetjes
A webserver en database apart
1. webserver (apache + php)
2. database (mysql + psql + ldap)
3. al het andere
B web_site_ (met alles dat er bij hoort) en civicrm apart
1. www (apache + webserver + mysql(percora?))
2. civicrm (eigen apache, eigen database, etc...)
3. overige websites
C databases afsplitsen
1. webserver
2. mysql
3. postgres
4. ldap
5. loghost
6. memcache
D alles apart
1. www
2. test
3. civicrm
4. wiki
5. forum
6. mysql
7. psql
8. ldap
9. loghost
10. pwm
11. memcache
E dedicated drupal stack
1. drupal (nginx + percora, www. test. civicrm)
2. wiki, forum (apache + mysql)
3. ldap, logs, pwm
Bovenstaande is allemaal uit de losse pols geschreven en is niet compleet.
Dingen opsplitsen maakt het beheer makkelijker (want minder kans op conflicten) maar geeft wel meer
werk (al die vm's moeten ook weer beheerd worden). Opsplitsen in veel VM's heeft ook ontzettend veel
overhead.
Er is ook wel wat voor te zeggen om bv alles wat bij www. hoort samen te houden, zodat we dat als 1
makkelijk te verhuizen geheel kunnen behandelen. Het nadeel daarvan is dat we dingen dubbel gaan
doen (bv meerdere datbases).
Van de andere kant is het wel een goed idee om dat databases niet op de webserver te hebben staan.
Het nadeel daarvan is dat zo'n beetje alles gebruik maakt van mysql en ldap, het opsplitsen wordt er
niet makkelijker van.
Jullie nog radicale ideeen?
--
Casper
More information about the Techteam
mailing list