Bekijk Volledige Versie : Hoe je eigen cluster te maken op basis van DirectAdmin
De komende periode zal ik in delen de opzet van ons cluster benoemen en bijzonderheden aangeven waar op te letten als je een vergelijkbare omgeving op wilt zetten. Daarnaast zal ik ook vragen beantwoorden die hier over kunnen ontstaan. Mocht je het zelf ook op willen zetten reken dan op meerdere servers, grote capaciteit voor pieken en makkelijk schalen indien nodig/gewenst. Zodra het cluster groter van omvang is wordt het ook mogelijk delen uit te zetten als het rustiger is (kan handig zijn in bepaalde gevallen).
In deze eerste post ga ik een globale beschrijving van de opzet geven. Alle systemen draaien Debian (maar een andere Linux distributie naar eigen voorkeur kan natuurlijk ook).
De volgende functies hebben wij gekozen voor de servers:
- Loadbalancers (met Keepalived/LVS), 1 netwerk interface vereist
- Caching (kan weggelaten worden, op basis van Varnish en Nginx)
- Webservers (Apache httpd, PHP)
- Database servers (MySQL master-master, automatische failover moeten we nog toe gaan voegen. Gebruikt geen NFS)
- Rest (DirectAdmin/mail/ftp/NFS, momenteel nog de enige SPOF. NFS wil ik op termijn overbodig maken als ik hier een goede optie voor heb gevonden)
Waarom deze opsplitsing? Uit ervaring weten we dat als er ergens problemen ontstaan en extra capaciteit gewenst is dit altijd gaat om webservers of database servers bij ons, het wordt veroorzaakt door veel bezoekers/slechte code. Om dit op te kunnen vangen hebben we deze opzet gemaakt en was het met name van belang om makkelijk webservers er bij in te kunnen zetten en om waar nodig extra database servers neer te kunnen zetten (dan kunnen bepaalde klanten andere database servers gebruiken). Een laatste voordeel van deze opzet is dat onderhoud aan de webservers/loadbalancers/caching overdag uitgevoerd kan worden, dit wordt automatisch door een andere server overgenomen.
Bepaalde design keuzes zal ik de komende tijd nader toelichten, net als waar op te letten. De scripts die we hiervoor geschreven hebben zal ik niet delen, hiervoor zal het beheer van de omgeving waar dit wenselijk is aan ons uitbesteed moeten worden.
Ah leuk dit ga ik even volgen. Wij doen alles qua hosting op een HA VPS cluster en doen dit op een ander niveau dan jij van plan bent. Echter is onze manier stabiel, gemakkelijk en behoorlijk betrouwbaar maar is het op jouw manier mogelijk nog veel groter te schalen met 1 omgeving.
Zelf hebben we hier wel eens naar gekeken en zeker omdat we vrij veel met clusters werken ook ivm wat grote websites. Alleen is dit altijd exclusief Directadmin wat sommige best graag hebben.
Alleen wat jij ook aangeeft de SPOF bij directadmin bevalt me nooit zo erg. Is het niet beter om te gaan kijken voor een alternatief voor Directadmin wat wel een beetje te schalen is?
In ieder geval enorm leuk dat je ons een kijkje gaat geven in de ontwikkelingen bij jullie.
systemdeveloper
07/01/13, 19:09
Leuk. Hebben we ook al jaren op die manier draaien. Ideaal om te schalen :)
Alleen wat jij ook aangeeft de SPOF bij directadmin bevalt me nooit zo erg. Is het niet beter om te gaan kijken voor een alternatief voor Directadmin wat wel een beetje te schalen is?
In werkelijkheid wordt de SPOF veroorzaakt doordat ik nog geen goed filesystem heb gevonden dat stabiel draait in tests terwijl het vanaf meerdere locaties tegelijk gemount is. Onze centrale storage (volledig HA) ondersteund helaas geen NFS en daardoor moet ik daarvoor een laag er tussen zetten. DirectAdmin zelf is wel dubbel uit te voeren incl. dat alles aan beide kanten er hetzelfde uit ziet voor de gebruikers maakt het dan niet uit waar ze inloggen. Hiervoor zijn er wel een paar eisen (zelfde DirectAdmin versie/besturingssysteem), de rest kan met de juiste mappen via een gedeeld bestandssysteem beschikbaar maken.
Als iemand een goede en stabiele oplossing weet zonder hardware te vervangen (onze storage servers staan er nog niet zo lang) om met een bestandssysteem te werken dat op meerdere systemen te mounten is (als blockdevice) dan verneem ik het graag en ga ik daar ook zeker mee testen en als het stabiel is zal ik dat ook mee nemen in de volgende posts.
Het geheel is opgezet op VPSen, voor de uitleg (om het simpel te houden) ga ik uit van losse servers in de beschrijving. De extra virtualisatie laag maakt voor de beschrijving relatief weinig verschil.
Voor je servers kunt inrichten die ook beschikbaar zijn voor clients is het handig om het netwerk te regelen (ook makkelijk bij de installatie). Hiervoor is gekozen om elke server met 2 kabels te verbinden met switches, daarnaast gaat het interne verkeer over een ander VLAN dan het verkeer naar de buitenwereld ("het internet"/"externe verkeer"). We hebben voor het interne VLAN IPs gebruikt uit RFC1918 en hier is IPv6 niet beschikbaar. Het verkeer naar het internet kan wel gebruik maken van IPv6. De IPs en VLANs die ik hier noem komen niet overeen met onze werkelijke setup, hieronder een beschrijving van wat gebruikt wordt.
Externe IP adressen:
198.51.100.0/24 (RFC5737)
203.0.113.0/24 (RFC5737)
2001:DB8::/32 (RFC3849)
Interne IP adressen:
192.168.0.0/16 (RFC1918)
Domeinnamen (RFC2606):
example.com
example.net
example.org
Extern VLAN:
VLAN 1
Intern VLAN (een verdere opsplitsing is natuurlijk mogelijk):
VLAN 10
De basis installatie (incl. SSH) van Debian ga ik hier verder niet beschrijven, als je niet weet hoe dat moet dan adviseer ik om niet verder te lezen. Van enige basis kennis mbt Linux ga ik wel uit. eth0 wordt gebruikt voor extern verkeer en eth1 voor intern verkeer. In de voorbeelden/verwijzingen noem ik mogelijk Debian specifieke opties voor de installatie (apt-get) of bestandslocaties, bij een andere Linux distributie zal gekeken moeten worden waar het daar staat.
Hieronder volgt een overzicht van de servers met IP adressen per interface. Ik ga er niet vanuit dat onder de korte naam van de server deze vanaf een andere server bereikbaar is, hier kom ik later nog op terug zodra ik de webservers uitgebreider beschrijf (de overige servers hoeven elkaar enkel op IP te kunnen vinden in bepaalde gevallen).
lb01:
eth0: 198.51.100.10 & 2001:DB8::10
eth1: 192.168.10.10
lb02:
eth0: 198.51.100.11 & 2001:DB8::11
eth1: 192.168.10.11
cache01:
eth0: 198.51.100.20 & 2001:DB8::20
eth1: 192.168.10.20
cache02:
eth0: 198.51.100.21 & 2001:DB8::21
eth1: 192.168.10.21
web01:
eth0: 198.51.100.30 & 2001:DB8::30
eth1: 192.168.10.30
web02:
eth0: 198.51.100.31 & 2001:DB8::31
eth1: 192.168.10.31
mysql01:
eth0: 198.51.100.40 & 2001:DB8::40
eth1: 192.168.10.40
mysql02:
eth0: 198.51.100.41 & 2001:DB8::41
eth1: 192.168.10.41
da01:
eth0: 198.51.100.50 & 2001:DB8::50
eth1: 192.168.10.50
Te gebruiken door websites:
198.51.100.60-198.51.100.69
2011:db8::60-2001:db8::69
De IPs die door websites gebruikt kunnen worden moeten toegevoegd worden aan de loopback interface (lo), in dit voorbeeld ga ik uit van het instellen zoals hieronder (in /etc/network/interfaces, de overige IPs zijn op een vergelijkbare wijze toegevoegd).
auto lo:60
iface lo:60 inet static
address 198.51.100.60
netmask 255.255.255.255
up ip -6 addr add 2011:db8::60/128 dev lo
Dit moet zo gedaan worden op cache01, cache02, web01, web02 en da01. De reden hiervan is dat deze "virtuele IPs" later gebruikt worden voor de sites en met verschillende poorten hiernaar verwijzen, dit gecombineerd met het feit dat ik geen NAT wil doen op de loadbalancers (anders moet alles op de loadbalancers na enkel interne IPs hebben).
Ik ga dit even volgen. Altijd leuk om de setup te zien en hoe collega's bepaalde dingen inregelen.
Leuk mark17. Ik ga dit zeker volgen. Altijd leuk hoe anderen hun omgeving opzetten.
Kevin Bentlage
08/01/13, 12:55
Dit zijn nou interessante topics, ik volg hem ook!
Ramon Fincken
08/01/13, 13:00
Schatjes .. reply nu gewoon even als je echt iets bij wil dragen. En niet "ik volg ook".
Als je wat fijn vindt .. klik dan op de like knop.
Op de loadbalancers (lb01 en lb02) hebben we Keepalived v1.2.2 geïnstalleerd (met apt-get). Het instellen hiervan is niet echt heel moeilijk, voorbeelden van delen van keepalived.conf staan hieronder. Op basis van deze voorbeelden zal de rest redelijk in te vullen zijn verwacht ik.
Verzin een naam voor de configuratie en definieer deze.
global_defs {
lvs_id LVS_CLUSTER_01
}
Maak groepen van IPs die allemaal tegelijk master/slave moeten zijn.
vrrp_sync_group VG1 {
group {
CL01_VI_WAN
CL01_VI_LAN
}
}
Voeg een virtueel IP (VIP) toe (later configureer ik de acties voor de poorten). Op de andere server is de state en priority anders (zie voor details de Keepalived documentatie). Voor de andere vrrp instellingen gebruik ik andere namen en een andere virtual_router_id, voor je hiermee begint adviseer ik de documentatie van Keepalived even te lezen.
vrrp_instance CL01_VI_WAN {
state MASTER
interface eth0
virtual_router_id 101
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass verzinMaarEenWachtwoord
}
virtual_ipaddress {
198.51.100.60
198.51.100.61
}
}
Voor poort 80 heb ik per IP een blok dat er uit ziet als volgt, voor andere poorten heb ik een vergelijkbare configuratie.
virtual_server 198.51.100.60 80 {
delay_loop 6
lb_algo rr
lb_kind DR
persistence_timeout 3600
protocol TCP
real_server 198.51.100.20 80 {
weight 100
TCP_CHECK {
connect_timeout 3
connect_port 80
}
}
real_server 198.51.100.21 80 {
weight 100
TCP_CHECK {
connect_timeout 3
connect_port 80
}
}
}
Poorten die via de loadbalancer gaan:
- 25
- 80
- 85 (verwijst naar de webservers, Apache draait op poort 85 en zo kunnen klanten hun site zonder cache benaderen. Dit kan soms enorm handig zijn)
- 110
- 143
- 443
- 587
- 993
- 995
- 2222
SSH en FTP gaan niet via de loadbalancers. FTP werkt niet echt lekker via de loadbalancers (hier heb ik nog geen oplossing voor gevonden helaas, gebruikers verbinden rechtstreeks met da01 als ze naar ftp.domein gaan). SSH toegang krijgen klanten bij ons niet, anders hadden we hier mogelijk wel iets mee gedaan.
Commentaar op onze opstelling is overigens ook welkom. Een goede discussie waarom bepaalde keuzes gemaakt zijn kan juist zeer verhelderend werken lijkt mij.
Op cache01 en cache02 draaien Varnish (luistert op poort 80) en Nginx (luistert op poort 443). Nginx levert voor sites de SSL laag, wij stellen dit verder handmatig in per klant met SSL (we moeten dan toch een IP reserveren voor deze klant). Nginx stuur alle verzoeken (na het afhandelen van het SSL deel) door naar Varnish. Varnish haalt via een roundrobin achtige instelling vervolgens van de webservers het verkeer (op poort 85 luisteren de webservers).
Poort 80 en 443 worden door de loadbalancers verwezen naar cache01 en cache02.
===================================
mysql01 en mysql02 draaien in een master-master opstelling. Er is hier nog geen automatische failover ingesteld (tips? Dit wil ik nog wel in gaan stellen), afhankelijk van de webserver is welke MySQL server gebruikt wordt. Hier is een script toegevoegd om aan elke MySQL gebruiker die rechten heeft om vanaf localhost (de DirectAdmin standaard) te verbinden rechten worden gegeven om vanaf 192.168.10.% te verbinden. Verder is dit een vrij simpele opzet en overweeg ik om nog een keer een plugin voor DirectAdmin te maken om meerdere MySQL servers te gaan ondersteunen. Mocht hier interesse in zijn dan verneem ik dat graag.
De volgende keer ga ik in op een combinatie van web01, web02 en da01. Dit deel is relatief gezien het lastigste.
Waarvoor gebruik je varnish ? Om te cachen of puur om te routeren van het http verkeer ?
Waarvoor gebruik je varnish ? Om te cachen of puur om te routeren van het http verkeer ?
Volgens mij ook voor cachen. Hij zei namelijk dat hij port 85 door laat verwijzen naar apache zodat ze eventueel cache kunnen omzeilen wat soms handig kan zijn.
Volgens mij ook voor cachen. Hij zei namelijk dat hij port 85 door laat verwijzen naar apache zodat ze eventueel cache kunnen omzeilen wat soms handig kan zijn.
U heeft gelijk :)
Wat ik mij dan afvraag, geef je klanten de mogelijkheid om objects uit de varnish cache te flushen ? Of puur op verlopen van cache ?
U heeft gelijk :)
Wat ik mij dan afvraag, geef je klanten de mogelijkheid om objects uit de varnish cache te flushen ? Of puur op verlopen van cache ?
Zeg maar "je" ik ben nog niet zo oud ;).
Eerlijk gezegd verwacht ik niet (enkel mark17 kan bevestigen) dat dat mogelijk gaat zijn. Daarom is in zekere zin ook die :85 om even changes te checken. Wel denk ik dat ze het met bepaalde headers kunnen forcen. Ook is nog maar de vraag of cache altijd actief is of enkel bij drukke websites.
De cache is bij alle pagina's zonder cookies actief. Wel zijn we nog aan het afwegen om het standaard voor plaatjes te gaan forceren (op bestandsextensie). Het flushen van objecten kunnen klanten nu nog niet, op termijn wil ik dit echter wel mogelijk gaan maken (hiervoor kunnen klanten nu nog contact opnemen).
De cache is bij alle pagina's zonder cookies actief. Wel zijn we nog aan het afwegen om het standaard voor plaatjes te gaan forceren (op bestandsextensie). Het flushen van objecten kunnen klanten nu nog niet, op termijn wil ik dit echter wel mogelijk gaan maken (hiervoor kunnen klanten nu nog contact opnemen).
Als jullie nu de mogelijkheid hebben om gemakkelijk PER domein te flushen dan is het toch ook nihil werk om een scriptje te maken die dat doet met behulp van button in DA of iets dergelijks?
afhankelijk van welke versie, maar met 3.0 zou je dit kunnen proberen:
ban req.http.host == domein.nl && req.url ~ ^/path/met/beginnende/slash.html
mysql01 en mysql02 draaien in een master-master opstelling. Er is hier nog geen automatische failover ingesteld (tips? Dit wil ik nog wel in gaan stellen), afhankelijk van de webserver is welke MySQL server gebruikt wordt.
Percona. XtraDB gaat wel uit van InnoDB en MyISAM is niet volledig ondersteunt zover ik weet. Wij doen de failover met haproxy maar met keepalived kun je waarschijnlijk zo ongeveer hetzelfde doen. Werkt zoveel makkelijker dan MySQL zelf, zeker met een cluster set up.
Het is automatisch een master-master set up maar je wilt niet schrijven naar alle nodes tegelijk. Kan wel, maar de kans is er dat je tegen locks aan loopt.
Als jullie nu de mogelijkheid hebben om gemakkelijk PER domein te flushen dan is het toch ook nihil werk om een scriptje te maken die dat doet met behulp van button in DA of iets dergelijks?
Het is inderdaad niet veel werk en we hebben een dergelijke optie wel om het per URL te doen (incl. domein). Echter wil ik hier eerst even rustig naar kijken voor ik dit beschikbaar maak voor klanten om het zelf te doen (dan moeten ook de domain pointers meegenomen worden om maar iets simpels te noemen). Dit gaat er wel komen voor klanten (hoewel de vraag zeer klein lijkt te zijn). Het voordeel van onze huidige opzet voor klanten is dat verkeer dat door Varnish wordt opgevangen niet doorberekend wordt, enkel wat bij Apache komt belasten we door (en hebben we logs van).
Percona. XtraDB gaat wel uit van InnoDB en MyISAM is niet volledig ondersteunt zover ik weet. Wij doen de failover met haproxy maar met keepalived kun je waarschijnlijk zo ongeveer hetzelfde doen. Werkt zoveel makkelijker dan MySQL zelf, zeker met een cluster set up.
Het is automatisch een master-master set up maar je wilt niet schrijven naar alle nodes tegelijk. Kan wel, maar de kans is er dat je tegen locks aan loopt.
Ik ga er naar kijken, MyISAM is voor ons wel een eis (we kunnen moeilijk richting klanten aangeven dat we dat niet ondersteunen).
Het is inderdaad niet veel werk en we hebben een dergelijke optie wel om het per URL te doen (incl. domein). Echter wil ik hier eerst even rustig naar kijken voor ik dit beschikbaar maak voor klanten om het zelf te doen (dan moeten ook de domain pointers meegenomen worden om maar iets simpels te noemen). Dit gaat er wel komen voor klanten (hoewel de vraag zeer klein lijkt te zijn). Het voordeel van onze huidige opzet voor klanten is dat verkeer dat door Varnish wordt opgevangen niet doorberekend wordt, enkel wat bij Apache komt belasten we door (en hebben we logs van).
Hoe ga je om met bezoekers logboek? Veel lui waarvan ik weet die directadmin gebruiken gebruiken vaak website statistieken van directadmin. Natuurlijk als je een beetje kennis hebt kan je ook google analytics inbouwen maar toch.
Ga je dit nog op een manier opvangen voor de echte dummy's?
En je gaf aan foto's misschien te willen forcen om te cachen. Hoe wil je dan omgaan met bijv grote fotogalleries? Lekker handig als ik gallery heb met duizenden foto's met xxxxx bezoekers per uur en jij kan voor het traffic opdraaien.
Ik snap dat het vergezocht is hoor maar ben wel benieuwd of je hier ook over nagedacht hebt en waarom je gekozen hebt voor datgene wat je gekozen hebt.
De varnish traffic is wel te loggen en zelfs te mergen in de bestaande logfiles :)
De varnish traffic is wel te loggen en zelfs te mergen in de bestaande logfiles :)
Dat is bekend. Echter geeft Mark17 aan dit niet te gaan doen wat volgens mij best gaten in je dienstverlening brengt.
Hoe ga je om met bezoekers logboek? Veel lui waarvan ik weet die directadmin gebruiken gebruiken vaak website statistieken van directadmin. Natuurlijk als je een beetje kennis hebt kan je ook google analytics inbouwen maar toch.
Ga je dit nog op een manier opvangen voor de echte dummy's?
En je gaf aan foto's misschien te willen forcen om te cachen. Hoe wil je dan omgaan met bijv grote fotogalleries? Lekker handig als ik gallery heb met duizenden foto's met xxxxx bezoekers per uur en jij kan voor het traffic opdraaien.
Ik snap dat het vergezocht is hoor maar ben wel benieuwd of je hier ook over nagedacht hebt en waarom je gekozen hebt voor datgene wat je gekozen hebt.
Wat Apache bereikt wordt nog netjes verwerkt in DirectAdmin, daarnaast installeren we op verzoek van klanten een pakket als Piwik. Voor veel mensen voldoen de standaard statistieken pakketten bij DirectAdmin in de praktijk niet hebben we in het verleden al vernomen van klanten die iets met de statistieken doen.
De cache is een beperkte tijd. Voor ons is het relatief gezien duur om verkeer via Apache af te handelen, extra verkeer is in de meeste gevallen voordeliger voor ons.
De varnish traffic is wel te loggen en zelfs te mergen in de bestaande logfiles :)
Dat is mij bekend, dit deden we echter in het verleden al niet en we hebben nu gekozen om dat niet te blijven doen. Wij zien hier meer nadelen dan voordelen in.
Dat is bekend. Echter geeft Mark17 aan dit niet te gaan doen wat volgens mij best gaten in je dienstverlening brengt.
Welke gaten zou het opleveren? Het enige dat ik kan bedenken is eventueel de statistieken en daarvoor hebben we een alternatieve oplossing die we aanbieden.
Ik ga er naar kijken, MyISAM is voor ons wel een eis (we kunnen moeilijk richting klanten aangeven dat we dat niet ondersteunen).
Ik heb zelf ook nog even nagezocht hoe het ook alweer zat, maar MyISAM wordt sinds 5.5.23 dus wel ondersteunt in hun cluster set up. Zie ook: http://www.mysqlperformanceblog.com/2012/05/14/announcement-of-percona-xtradb-cluster-5-5-23/.
da01, web01 en web02 ga ik kort toelichten. Dit is het deel met de meeste onderlinge koppelingen en bijzonderheden.
Deze servers delen een aantal mappen, voor de volledigheid heb ik er kort bijgezet wie er heen moet kunnen schrijven. Dit kan door NFS of door een andere techniek te gebruiken.
/usr/local/directadmin/data/users/ da01 schrijven, rest lezen (voor de httpd.conf bestanden van de gebruikers)
/var/log/httpd/domains/ allen schrijven
/home/ allen schrijven
/etc/httpd/conf/extra/ allen lezen (1 voor beheer ook schrijven)
/tmp/ web01/web02 schrijven (sessies zijn gedeeld)
De logbestanden van de webserver moet je wegschrijven naar een apart bestand per webserver en vervolgens samenvoegen, voor dit laatste zijn verschillende scripts beschikbaar. De webservers zijn voorzien van Apache 2.4 (let op dat sommige opties die in een .htaccess staan anders moeten dan met Apache 2.2) en PHP 5.4 (PHP 5.3 is naar verwachting in maart 2013 EOL). Naast het aanpassen van wat DirectAdmin templates voor de config bestanden en het niet luisteren op een specifiek IP voor een bezoeker (maar op *:85) is er verder niet veel gewijzigd.
Voor de DNS is enkel bijzonder te noemen dat FTP momenteel rechtstreeks gaat naar da01 (op het externe IP daarvan). Dit is eventueel aan te passen door losse FTP servers toe te voegen, dan kan dit deel ook HA uitgevoerd worden. Alle functies van da01 op NFS na is vrij simpel HA uit te voeren, dit zonder dat eindgebruikers dit hoeven te merken/weten. Wel is het zo dat we het verstoppen in variabelen welke systemen ergens bij betrokken zijn (handig met debuggen).
Veel meer is er niet te zeggen over een dergelijk cluster. Als je globaal weet wat je doet, de wil hebt om het te doen en de hardware hebt dan kun je een dergelijk cluster zonder voorbereiding opzetten in 1 avond (het finetunen kan wel vrij veel tijd kosten helaas, dat is iets waar je nooit helemaal mee klaar bent denk ik).
Ramon Fincken
09/02/15, 13:44
Ben je al verder gekomen met de mail?
In een test opstelling draait inmiddels alles in HA. Dit betekend effectief dat alles minimaal 2x is uitgevoerd.
tomadmiraal
10/02/15, 13:43
Mark17 - zou je misschien kunnen delen hoe je DA volledig redundant hebt gemaakt
Mark17 - zou je misschien kunnen delen hoe je DA volledig redundant hebt gemaakt
Een globaal plaatje kan ik waarschijnlijk op niet al te lange termijn hier wel plaatsen.
Het is een bumpje, maar ik ben alsnog benieuwd hoe je DirectAdmin redundant hebt gekregen.
tomadmiraal
19/09/15, 09:23
Ik heb inderdaad (helaas) nooit antwoord gekregen op deze vraag. Ik ben vooral geinteresseerd naar het redundant maken van de mail.
Misschien dat Mark17 meer kan vertellen inmiddels ?
Op dit moment ben ik het aan het uitwerken voor mezelf om zodra ik wat tijd heb in een blogpost te kunnen zetten. Een update met hoe we andere onderdelen gedaan hebben volgt dan ook nog. Ik verwacht op het moment dat dat dit jaar nog moet lukken.
op niet al te lange termijn == 9 maanden ?
Er was wat tussen gekomen. Dit jaar wil ik er nog een blog over schrijven. Bij specifieke vragen kunnen partijen me voor de tijd ook een keer ergens aanspreken of een mail sturen.
Er was wat tussen gekomen. Dit jaar wil ik er nog een blog over schrijven. Bij specifieke vragen kunnen partijen me voor de tijd ook een keer ergens aanspreken of een mail sturen.
Hoe staat het hiermee ? Dusver zie ik een hoop bla bla, maar puntje bij paaltje kom je niet.
Zeg dan of je wilt het niet delen, of je kan het niet :)