[PPNL-Techteam] VM's en IP's
Geert-Johan Riemer
geertjohan.riemer at gmail.com
Tue Jun 12 09:07:56 CEST 2012
Ik denk dat E een erg mooie optie is zowel kwa security en performance.
Ik denk dat de drupal stack (nginx, caching, database) op 1 VM moet ivm
performance. Het liefst die zelfs niet op een VM maar op de machine zelf.
De LDAP op een VM lijkt me goed ivm security, daarbij ga ik er even van uit
dat je met ldap kan zorgen dat een user maar een beperkt aantal velden kan
zien.. dus dat de drupal connection alleen maar
username/password/employeeType/email kan zien. Klopt dat? Anders zou het
alsnog weinig zin hebben die af te splitsen denk ik.
En dan voor forum een losse VM met daarop databse+forum lijkt me ook een
strak plan.
En voor alle andere services dus ook.
Ik moet hier trouwens wel bij zeggen dat ik altijd het gevoel heb dat
VM<->VM of VM<->Host communicatie aardige overhead en delay heeft, maar ik
weet niet of dat fact is met de VM software die wij willen gebruiken.
2012/6/11 Casper Gielen <casper at gielen.name>
> 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
> _______________________________________________
> Techteam mailing list
> Techteam at lists.piratenpartij.nl
> https://lists.piratenpartij.nl/mailman/listinfo/techteam
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.piratenpartij.nl/mailman/private/techteam/attachments/20120612/08bfc780/attachment-0001.html>
More information about the Techteam
mailing list