Webhosting bij NPO ICT

Het hosten van webapplicaties en websites gebeurt bij ons in wat we het Applicatie Cluster (appcluster) noemen. Dit is een omgeving ingericht die is toegespitst op het hosten van willekeurige Java en PHP web-applicaties.

Bij NPO ICT zijn twee omgevingen ingericht, die samen een aantal webhostingmogelijkheden bieden. Het zgn Applicatie Cluster (appcluster) is een omgeving ingericht die is toegespitst op het hosten van willekeurige Java, PHP en Ruby on Rails web-applicaties. In deze omgeving hanteert NPO ICT geen acceptatiecriteria en zullen wij dus proberen om elke site te hosten. Het Webservices Cluster (webcluster) is toegespitst op het hosten van high-volume sites. Hier worden alleen statische websites (“platte html”) specifieke door NPO ICT geaccepteerde applicaties gehost. In het webcluster wordt gestreefd naar 24×7 beschikbaarheid, dus de sites die daar draaien zijn per definitie gebouwd met behulp van High Availability technieken. In het appcluster is dit optioneel, maar veel voorkomend en vaak ook gewenst.

Naast het app- en het webcluster is er ook een testcluster beschikbaar. Dit testcluster is op dezelfde manier opgezet als de productieclusters en kan gebruikt worden als testomgeving voor zowel het app- als het webcluster, maar kent geen uptime-garanties.

Beide omgevingen zijn server clusters bestaande uit twee loadbalancers, een aantal web-, applicatie- en database servers. Alle data bevindt zich op centrale, betrouwbare storage servers. Niet alleen is uw data daar veilig, maar dit zorgt er ook voor dat uw omgeving bijzonder flexibel is. Een database server kan a la minute een applicatieserver worden mocht dat nodig zijn. Of, als u al uw diensten op 1 server draaide en uw sites worden populair kan er zeer snel een tweede server bijgeschakeld worden om de last te verdelen.

De hardware, het OS, de web-, applicatie- en databaseservers worden beheerd door NPO ICT, wat garant staat voor een stabiele, veilige omgeving. In het appcluster kunt u uw eigen applicaties zelf beheren, uitbesteden aan NPO ICT of aan een derde partij. In het webcluster worden de applicaties uitsluitend beheerd door NPO ICT, waarbij NPO ICT delen van het beheer kan delegeren aan derden. (b.v. de makers van een applicatie)

Vragen? Deze kunnen gericht worden aan de NPO ICT Servicedesk servicedesk@omroep.nl

Alles dat te maken heeft met de diensten vind je in het filesysteem onder “/e”. Daar is voor elk type dienst een subdirectory, met daaronder alle instanties van die dienst, en daar weer onder de zaken die nodig zijn voor die dienst. Oftwel: alle paden zien er uit als /e/<dienst>/<instantie-naam>/<instantie specifieke zaken>

Dit zijn symlinks/snelkoppelingen voor extra flexibiliteit voor ons als beheerders en overzichtelijkheid voor de websitebouwers/ontwikkelaars. De onderliggende storage laag en daarmee /d/-paden kunnen veranderen maar zolang je gewoon de /e/-paden gebruikt heb je daar geen last van. Sterker nog het is absoluut niet de bedoeling dat paden onder /d/ worden gebruikt in configuratiebestanden of dat hier directe verwijzingen naar zijn in de code. Er zijn een aantal valkuilen waar je op moet letten om dit goed te (blijven) doen.

De bedoeling van de split tussen /e en /d is dat systeembeheerders makkelijk data naar andere filesystemen kunnen schuiven, zonder dat er configuratie in de draaiende applicatie aangepast moet worden. Het zorgt ook voor een centraal 'aanspreekpunt' voor de instanties. Bijvoorbeeld: apache kan met dezelfde configuratie nog steeds de code vinden en zijn logs wegschrijven als het onderliggende /d/pad is veranderd. Zolang de symbolic link maar naar het juiste pad verwijst is er niets aan de hand. Voor de software hebben we een vergelijkbare constructie. Dit is voor een sitebouwer wat minder relevant, maar het staat hier beschreven.

Het “locate” commando geeft vaak padnamen terug met /d/. Ook php en diverse ftp clients willen graag symlinks 'dereferencen', waardoor in die hoek ook nog wel eens /d paden zichtbaar willen zijn. Wees hier bedacht op.

De /e/paden zijn dus belangrijk voor websitebouwers en in het bijzonder /e/ap/(naam van je site)/pages. Dit is de documentroot. Een veelgebruikte constructie is om de documentroot pages/current te maken. Hiermee kun je meerdere versies hebben van de site en door een symbolic link te veranderen de versie veranderen die de 'huidige' is en daarmee dus live staat. Alle andere /e/ paden staan hier beschreven.

Voor applicaties ligt het iets anders; php applicaties hebben een iets andere directory structuur dan java applicaties.

PHP applicaties hebben de volgende structuur onder /e/ap/<applicatienaam>

• pages

(php applicaties) De document root van een php website. Deze is standaard php-enabled; maar -niet- schrijfbaar voor de webserver. Files hebben standaard als groep 'cw<naampje>'; zodat verschillende uploaders (bijvoorbeeld een omroep samen met een externe webbouwer) schrijfrechten hebben op de files. Belangrijk daarvoor is dat files mode 0664 hebben, en directories 2775. Dit valt prima te bereiken door een 'umask 002' in je .profile neer te zetten.

• data

De plek waar een applicatie z'n data kan wegschrijven. Deze directory wordt direct via de proxy-webserver uitgeserveerd. Het zelfde rechtenverhaal gaat hier ook op, behalve dan dat de bestanden en directories allemaal lid zijn van een 'dw<naampje>'-groep. Hierin zitten dezelfde mensen als in het 'cw<naampje>'-groepje, maar de webservers die data weg mogen schrijven zijn hier ook aan toegevoegd.

• config

Hier kunnen config bestanden geplaatst worden. Deze directory zit in het php include path. Bijvoorbeeld de database parameters zijn hier altijd terug te vinden, maar ook allerlei php-code valt hier te plaatsen die niet in de docomentroot hoeft te staan (denk aan generieke classes, libraries, etcetera). Ook deze directory is niet schrijfbaar voor de webserver. Wat betreft de rechten geldt hier hetzelfde als onder /pages.

Tot slot hebben we nog

• /home/omroep/<accountnaam>

De unix home directory van het upload-account genaamd <accountnaam>. Dit is de plek waar je binnenkomt als je inlogt. Als dit upload account bedoeld is voor het uploaden van applicatie X, dan zal er in de home directory vaak een verwijzing (symlink) naar applicatiedirectory X, dwz /e/ap/X gemaakt worden.

In onze omgeving maken wij onderscheid tussen read-only en read-write filesystemen. Voor de read-only filesystemen geldt dat deze vanaf de web, applicatie en database servers niet gewijzigd kunnen worden. Deze filesystemen worden gebruikt om de uitvoerbare delen en de configuratie van applicaties op te slaan.

In onze omgeving is het zo dat alle web-app en pages directories op read-only filesystemen liggen. Verder ligt alle configuratie (frontproxy, database, applicatieserver) op een read-only filesysteem. De read-write filesystemen worden alleen gebruikt voor logfiles, temp-directories en databases.

De reden hiervoor is dat als een site gehacked wordt, het voor de hacker onmogelijk is om b.v. jsp of php files te wijzigen. Concreet houdt dit in dat bij een geslaagde hack poging de applicatie zichzelf niet kan wijzigen (op instigatie van de hacker), en dat het dus bijzonder moeilijk zal zijn om b.v. aan de database inhoud te komen.

Dit houdt in dat het voor applicaties dus niet mogelijk is om self-modifying code te gebruiken (bv een jsp die een nieuwe versie van zichzelf neerzet). In het geval van MMBase houdt dit in dat er niet via het web-interface nieuwe delen van MMBase geinstalleerd kunnen worden (want de applicatieserver mag niet schrijven in z'n web-app directory) Zelfs als u bijvoorbeeld “chmod 777” (= unix speak voor world writable) op een jsp bestand zou doen, dan nog is het niet te wijzigen vanaf een applicatieserver. Dit willen we dan ook ten zeerste afraden.

De enige plek vanaf waar naar de read-only filesystemen geschreven mag worden is de upload server. Da's ook nodig, anders zouden er b.v. nooit nieuwe jsp bestanden geplaatst kunnen worden.

De policy voor naamgeving is als volgt: (ingewikkeld? Vertel ons wat u wilt en wij regelen het zonder u te vermoeien met onderstaande details)

• Websites

Elke omroep is geheel vrij een naam voor de website te kiezen. Elke applicatie kan onder een andere naam draaien (bv “www.groente.nl” vs “www.fruit.nl”), een gedeelde naam (bv “www.plantaardig.nl/groente vs www.plantaardig.nl/fruit”) of onder de default naam “sites.omroep.nl” (bv sites.omroep.nl/groente) De naam die u kiest, is de naam die in de locatiebalk van de webserver zichbaar is en de naam die extern bekend gemaakt wordt. Alle naamgeving die hieronder nog staat is alleen maar intern, en niet extern zichtbaar. In de testomgeving hebben wij liefst dat applicaties draaien onder “testsites.omroep.nl/<applicatie>”, maar indien gewenst kunnen er ook (lange!) namen als “<omroep>-<applicatie>test.omroep.nl” aangemaakt worden (bv degezondeomroep-groentetest.omroep.nl)

• Frontproxies

Deze worden genoemd naar de omroep waar ze bij horen, gevolgd door een volgnummer. B.v. /e/fp/dgo01 zou de 1e frontproxy van “De Gezonde Omroep” (DGO) zijn. De shared frontproxy heet <tt/shrd01/ De dns naam van een frontproxy wordt “<omroep>-sites.omroep.nl”. (bv “degezondeomroep-sites.omroep.nl”). Deze naam wordt iha niet extern genoemd, maar is alleen een “kapstok” om domeinnamen aan op te kunnen hangen, dmv DNS CNAMES. (b.v. www.groente.nl is een CNAME naar degezondeomroep-sites.omroep.nl; dmv een virtualhost constructie in de frontproxy zorgen wij er dan voor dat www.groente.nl uitkomt bij de groente applicatie)

• Databases

Deze worden ook genoemd naar de omroep waar ze bij horen, gevolgd door een volgnummer. In de naamgeving wordt geen onderscheid tussen de verschillende types database (mysql of postgresql) aangehouden. B.v. /e/db/dgo01 zou de eerste database instance van de gezonde omroep zijn. De shared database instances heten shrd01 (mysql) en shrd02 (postgresql) Binnen de database instances kunnen voor de diverse applicaties diverse databases aangemaakt worden. Als er een applicatie genaamd “groente” zou zijn, zou de database die daarbij hoort “groentedb” heten en de database user die daarbij hoort zou “groente' heten.

• Applicatie Servers

Ook deze worden genoemd naar de omroep waar ze bij horen, met een volgnummer. De tiende DGO applicatieserver zou /e/as/dgo10 heten. De naam van applicatieservers wordt generiek gehouden, omdat een applicatieserver geen 1 op 1 relatie met een applicatie heeft.

• Applicaties

Voor applicaties wordt bij voorkeur gepoogd om een 1 op 1 mapping tussen url en applicatienaam te hebben. Dwz als een website www.groentenenfruit.nl heet, dan is de applicatienaam ook /e/ap/www.groentenenfruit.nl In geval van java hosting wil het nog wel eens voorkomen dat er onder 1 url meerdere applicaties hangen (verschillende mountpoints in tomcat) In dat geval wordt gepoogd een min of meer descriptieve naam te gebruiken. Stel dat onder de groentenenfruit site nog een speciale shop module nodig is, dan zou deze op disk /e/ap/groentenenfruitshop kunnen heten en bereikbaar kunnen zind als www.groentenenfruit.nl/shop.

• Upload Accountnamen

De upload accounts worden meestal genoemd naar de organisatie die de uploads wil kunnen doen. Stel dat DGO het maken van z'n Groenten en Fruit site geheeld uit zou besteden aan de “DeNeefjesCompany Ltd” dan zou het upload account iets als “neefjes” kunnen heten; dit account zou vervolgens schrijfrechten onder onder /e/ap/groentenenfruit/web-app krijgen om daar de applicatie te plaatsen. Als een omroep zelf z'n eigen applicaties plaatst, dan wordt de accountnaam weer iets als “omroep+volgnummer”.

Er zijn meerdere manieren om loadbalancing te implementeren, deze sectie beschrijft hoe wij dit het liefste doen, nl met twee gestapelde loadbalancers. De gedachte is dat we aan de buitenkant een paartje loadbalancers hebben, welke in master/slave configuratie draaien. Deze loadbalancers gebruiken keepalived met direct routing. Dat betekent dat de loadbalancers puur op IP niveau kijken en losse IP pakketjes doorsturen naar de te loadbalancen instanties.

Normaal zouden die te loadbalancen instanties een farm van webservers zijn die het eigenlijke werk doen, maar hier zit er een extra laag tussen, nl er wordt geloadbalanced over een farm(pje) van http proxies. En die proxies op hun beurt loadbalancen (mod-proxy-balancer igv apache) dan over de farm van (php enabled) webservers die het echte werk doen. In ascii art ziet dat er als volgt uit

          Interweb
           |
         web1a....web1b         Load balancers
         /   \
        /     \
   xxx1afp  xxx1bfp             static, loadbalancing http proxies
       |\    /|
       | \  / |
       |  \/  |
       |  /\  |
       | /  \ |
       |/    \|
   xxx2afp  xxx2bfp		php nodes

Er is voor deze getrapte setup gekozen om de volgende redenen:

• Aan webserving zitten twee kanten: enerzijds het spoonfeeden

(bitje voor bitje uitserveren, over een tergend traag internet lijntje) van data naar je kijkers, anderzijds het uitrekenen (denk php) van hoe een webpagina eruit moet zien. Voor het uitrekenen (php) heb je hele “dure” webserver slots nodig; bij apache is dat single threaded, ze hebben veel geheugen nodig etc. Het spoonfeeden echter is een simpele taak, die heel goed threaded kan. Normaal bij een php webserver zit je dus 90% van de tijd dure php slots te gebruiken om data naar je kijkers te spoonfeeden. Rescources die beter anders gebruikt zouden kunnen worden. Door er een http proxy tussen te zetten ontkoppel je het rekenen van het spoonfeeden. Het spoonfeeden gebeurt nu door de proxy, die daartoe geoptimaliseerd is (threaded webserver, veel slots e.d.) Het rekenen gebeurt door de geproxiede server. Omdat er tussen de proxy en de reken-server een snelle connectie ligt, is daar geen sprake van spoonfeeding en zijn de dure php slots alleen in gebruik op het moment dat ze ook echt nodig zijn. In apache termen betekent dit dat je op de php servers kan volstaan met>MaxClients 8, wat in normale mensentermen betekent dat je heel veel apache instanties naast elkaar zou kunnen gaan draaien zonder dat het geheugen volloopt.

• Een aardige bijkomstigheid van het gebruik van apache als proxy is

dat deze ook alvast het domme werk kan doen, nl zelf de statische data uitserveren, zonder daar de php server mee te belasten.

• Deze setup kan gebruikt worden voor het high-volume uitserveren

van statische websites. In dit geval zijn de proxies gewoon de eindpunten (ze proxyen zelf niks, omdat alles statische data is). Het schalen gaat hier door maar genoeg http proxies bij te schakelen. Stel dat er gekozen zou zijn voor een ongetrapt, simpeler alternatief, waarbij je de keepalived / DR loadbalancing gewoon niet zou doen (dwz direct aan de voorkant 1 proxy instantie, welke mbv keepalived in een master/slave config gedraaid wordt), dan zou dat prima werken voor groots php hosten, maar uiteindelijk zou je ene proxy server dan een choke point kunnen worden. Andersom, als de buitenkant een keepalived/DR loadbalancer zou zijn, die direct balanced over een aantal php nodes, dan heb je dus last van alle spoonfeeding issues zoals boven beschreven

• De keepalived/DR loadbalancer kan meerdere IP adressen en meerdere

poorten aan. Dit kan bv gebruikt worden om op 1 website http en https verkeer vasn elkaar te scheiden, waarbij het https verkeer naar ssl enabled instanties gaat, terwijl voor http verkeer alle ssl overhead niet nodig is en deze dus door leaner and meaner instanties gedaan kan worden. Andersom kan het ook gebruikt worden om 1 shared loadbalancer neer te zetten, die gebruikt kan worden voor een aantal verschillende klanten/applicaties, die dan allemaal hun eigen webserver isntances hebben staan.

Webservers leven altijd onder /e/fp. De naam daaronder ziet eruit als xxxx[0-9][a-z], waarbij de xxxx een tag is om aan te duiden van of voor wie deze instantie is (bv een omroepnaam of een applicatienaam), daarna volgt een cijfer, wat een volgnummer is. De N'e instance van klant xxxx. Tenslotte volgt weer een letter om aan te geven dat iets geloadbalanced is. Stel dat foo1 geloadbalanced zou worden over 3 instanties, dan zou je deze onder /e/fp terugvinden als foo1a, foo1b en foo1c.

Vaak zullen de a,b en c instanties onderling veel configuratie delen. Om deze nu niet 3x te dupliceren is deze terug te vinden in een gedeelde directory /e/fp/foo1 (dwz zonder volgletter).

Zowel de static proxies, als de php enabled servers zijn webservers en leven dus beide onder /e/fp. Er is geen onderscheid in naamgeving tussen proxies en php servers. In praktijk betekent dit vaak dat een proxy en php server dezelfde prefix hebben (“foo”), maar een ander volgnummertje (“foo1” tegenover “foo2”). Het kan natuurlijk ook zo zijn dat 1 setje proxies (foo1&lsqb;a-z&rsqb;) loadbalanced over meerdere setjes php servers (foo2&lsqb;a-z&rsqb; voor applicatie X en foo3&lsqb;a-z&rsqb; voor applicatie Y). Wij streven ernaar om in het GECOS veld van de password file aan te geven wat een webserver isntantie precies doet.

De user waar een webserver onder draait is z'n naam gevolgd door de letters “fp”. B.v. foo1afp. En het adres waar die aan bindt heeft meestal als DNS naam foo1afp.omroep.nl,

de configuratie van apache virtual hosts leeft bij ons altijd in losse .vhost files, welke door de webserver geinclude worden. In een loadbalanced context moeten zowel de proxies als de php servers weet hebben van de vhosts. Om nu niet alle informatie N maal te dupliceren hebben we vsan elke vhost file slechts een kopie, die door alle (proxies <em>en</em> php servers) webserver geinclude wordt. In de vhost file wordt met Define's gespeeld om ervoor te zorgen dat elke instantie alleen maar het stukje configuratie krijgt dat voor die instantie van toepassing is.

Niet alles is rozegeur en maneschijn, nl sessies zijn een probleem. Er is geen garantie dat een sessie altijd bij dezelfde php node terecht komt. Er zijn een aantal oplossingen:

• route constructies gebruiken

We gaan er van uit dat sessie informatie in http cookies gestopt zit. Als de cookies op een zodanige wijze gegenereerd kunnen worden dat het duidelijk is door welke worker node dit gedaan is, dan zit er in de http proxy functionaliteit om op basis van zo'n cookie het request naar de juiste worker door te sturen. Concreet betekent dat dat de cookiename statisch moet zijn (bv PHPSESSIONID) en dat de waarde van de cookie eruit moet zien als sessiadata.NODE_ID, waarbij het NODE_ID bepalend is voor naar welke node een request doorgezet moet worden. In een java tomcat context is dit tamelijk eenvoudig te doen door in de tomcat server.xml een jvmRoute op te nemen:

<Engine name="Standalone" defaultHost="none" jvmRoute="NODE_x">

Dit zorgt ervoor dat er cookies JSESSIONID=sessiedata.NODE_x gezet worden. Vervolgens stellen we op de proxy in:

ProxyPass / balancer://cluster/ stickysession=JSESSIONID
<Proxy balancer://cluster>
	BalancerMember	http://node1 route=NODE_1
	BalancerMember	http://node2 route=NODE_2
	BalancerMember	http://node3 route=NODE_3
	...
</Proxy>

En zo weet de proxy dat sessies met NODE_1 doorgestuurd moeten worden naar node1. Het probleem hierbij echter is dat dat bij php niet zo fijn werkt. Er is in php geen makkelijke manier (a la jvmRoute in tomcat) om php duidelijk te maken dat ie z'n sessie namen volgens een bepaalde syntax aan moet maken. Daarom hebben we een speciale truc verzonnen, waardoor door middel van een RewriteRule in de PHP-worker een cookie geset wordt (vaak iets als 'BALANCEID'), wat dan als stickysession gebruikt kan worden. Hierdoor komt uiteindelijk dan alsnog brafa elk request van 1 bezoeker op dezelfde PHP-worker terecht.

• sessies in database opslaan

Aangezien de verschillende webserver nodes uiteindelijk weer aan dezelfde database refereren, kan de database goed gebruikt worden om sessie informatie in op te slaan.

• sessies op het filesysteem opslaan

Dit zou in theorie kunnen, maar is in praktijk een slecht idee. De gedachte is dat de verschillende php nodes een shared filesysteem hebben. Dus, als node 1 op het filesysteem wat sessie info neerzet, dan kan node 2 dat weer oppikken. Probleem hierbij is dat we NFS gebruiken voor het filesysteem en dat NFS geen cache consistency biedt. Dat betekent dat op het moment dat node 1 iets weggeschreven heeft, dit niet meteen op node 2 bekend is.

• sessies in memcache opslaan

We bieden inmiddels ook support voor memcache, een stukje geheugen dat op een eigen intern ip-adresje beschikbaar is voor alle php-workers.

• statische content door de frontproxies uit laten serveren

Het komt natuurlijk best wel eens voor dat een site allemaal 'statische' content heeft staan onder /pages, en dan gaat het bovenstaande verhaal van de loadbalancing minder snel op. Daarom zorgen wij er standaard voor dat files met de extensies *.gif, *.html, *.htm, *.jpg, *.png, *.css, *.js, *.txt, *.swd, *.flv, *.xml, *.ico, *.pdf, *.gz, *.mp3 door de proxy uitgeserveerd worden. Hierbij is er wel een maar: het kan zijn dat een site speciale rewriterules heeft die botsen met deze constructie. In dat geval zullen we een custom oplossing moeten maken.

• xml

Ook zien we vaak dat er XML gegenereerd wordt aan de hand van gegevens uit een database. Dat is natuurlijk helemaal geen probleem, maar wordt het vanzelf wel als 15.000 mensen tegelijkertijd diezelfde XML willen opvragen uit de database. Daarom adviseren wij om in dat geval de XML-file door middel van een cronjob, bijvoorbeeld elke minuut, te genereren en onder /data neer te laten zetten. Op deze manier wordt een vaak opgevraagde xml toch actueel gehouden, maar uitgeserveerd door de proxiende webserver. Dit scheelt heel erg in de performance.

• caching

Er zijn nogal wat caching-mechanismes in omloop in de php-wereld; varierend van zelf bedachte dingen tot het gebruik van componenten als smarty en memcache. Wij supporten in ieder geval deze 2 mechanismes, en willen iedereen dan ook adviseren caching-vormen toe te passen op de applicaties.

Een aantal websites op onze omgeving maken gebruik van statische html files welke door php gegenereerd zijn. Binnen Apache heb je dan een aantal rewrite rules die bij een request controleerd of er een statische versie van de opgevraagde url beschikbaar is. Als dit het geval is, dan wordt deze uitgeserveerd en komt het request dus niet aan bij de backend (php) instanties. Bestaat de statische variant niet, of is het een type request wat niet gecached kan worden, dan wordt deze alsnog doorgestuurd naar de backend. Het voordeel hiervan is dat je zelf behoorlijk precies kunt bepalen wat er in de cache komt en hoe lang dit hier bijv. staat. Ook heb je potentieel minder last van thundering herd (ineens veel requests op iets wat nog niet in de cache staat). Je kunt bijv. cache fillers in een cronjob draaien die pagina's al vast in html vorm klaarzetten. Het nadeel kan zijn dat het wat meer werk kost om op te zetten binnen de applicatie.

Ook een webserver kan cachen op basis van cache headers. Hiermee wordt vanuit de applicatie aangegeven hoe lang een bepaalde pagina gecached mag worden voordat weer vanuit de backend een nieuwe versie opgevraagd mag worden. Zelfs een korte cache tijd van slechts een paar minuten kan al een enorme ontlasting op de backend geven omdat op piekmomenten nog maar een beperkt aantal requests doorkomen op de php instanties. Het voordeel van deze methode is dat het meestal relaties makkelijk te implementeren is. Het meesturen van de juiste headers op pagina's is voldoende om het op te laten nemen in de apache cache (dit moeten wij wel even inschakelen voor de betreffende vhost). Daarnaast is er in geval van Apache geen mogelijkheid om geforceerd een pagina uit de cache te verwijderen. Bij pagina updates moet je dus altijd de cache-tijd afwachten voordat de wijziging zichtbaar is. Omdat zelfs korte cache tijden van een paar minuten al enorm veel kunnen helpen is dit meestal niet direct een groot probleem omdat wijzigingen alsnog relatief snel doorgevoerd zijn.

• NPO ICT, servicedesk@omroep.nl, tel 035-6773555.

  • Algemeen aanspreekpunt voor het beheer van de omgeving.
• Dick Snippe, Dick.Snippe@tech.omroep.nl, Senior hostingsbeheerder