[PPNL-Techteam] VM's en IP's
Sander Plas
sander at oele.net
Wed Jun 13 08:00:46 CEST 2012
Iets anders waar we denk ik rekening mee moeten houden is dat Anker nu
op een SSD van maar 80 GB draait.
Elke VM neemt weer een paar gig aan OS + lege schijfruimte + swap in.
Ik kan makkelijk een grote normale harde schijf toevoegen (met een
beetje proppen misschien 2) maar dan heb je weer het probleem dat het
bij een reguliere harde schijf zonder RAID niet de vraag is OF hij gaat
crashen, maar wanneer dat gaat gebeuren. Dus: een strak backup &
recovery proces is dan erg belangrijk.
Ik denk trouwens dat het belangrijker is DAT we een keuze maken dan
WELKE keuze dat gaat zijn. Volgens mij kunnen we beter een verkeerde
keuze kunnen maken met wat stress door een korte outage of overbelasting
tot gevolg dan dat we dit soort beslissingen eindeloos voor ons uit
blijven schuiven. Morgen wordt al de lijsttrekker bekend gemaakt, daarna
is de campagne dus gewoon echt begonnen. Een keer een week over iets
nadenken lijkt niet zo erg, maar als we dat voor 12 onderwerpen achter
elkaar gaan doen zijn de verkiezingen alweer voorbij zijn al onze mooie
websiteplannen voor niets geweest.
On 06/12/2012 09:07 AM, Geert-Johan Riemer wrote:
> 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 <mailto: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 <mailto:Techteam at lists.piratenpartij.nl>
> https://lists.piratenpartij.nl/mailman/listinfo/techteam
>
>
>
>
> _______________________________________________
> Techteam mailing list
> Techteam at lists.piratenpartij.nl
> https://lists.piratenpartij.nl/mailman/listinfo/techteam
More information about the Techteam
mailing list