NPO Hosting en Streaming

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
~~META:
title = Migratie Appcluster Storage
~~
====== Migratie Appcluster Storage ======

====== Klantcommunicatie ======

===== Aankondiging =====
>Onderwerp: Migratie webhosting storage
>
>Beste Klant/Collega,
>
>In de periode van 16 januari tot 3 februari zal de storage van de NPO
>webhosting omgeving ("het appcluster") gemigreerd worden naar een nieuw
>storage platform.
>
>Omdat dit impact gaat hebben op de beschikbaarheid van websites zullen
>de migratieacties 's nachts tussen 1:00h en 5:00h uitgevoerd worden.
>Veel data (m.n. die behorend bij  PHP en RoR websites) kan zonder
>downtime gemigreerd worden. Waar dat niet mogelijk is (databases,
>sommige java applicaties) is de downtime meestal beperkt tot 1--10
>minuten, afhankelijk van hoeveel data er gemigreerd wordt en hoe
>"veranderlijk" deze data is.
>
>Let op: bij deze laatste migratie is het van belang om aandacht
>te besteden aan de zgn "/d paden" vs "/e paden", want ook hier geldt
>dat als gevolg van de migratie de "/d" paden gaan wijzigen.
>Door nu aandacht aan dit issue te besteden voorkom je dat je website in
>de toekomst als gevolg van dit probleem stuk kan gaan.
>Zie ook:
>http://hosting.omroep.nl/sterretje-cluster:cluster-hosting#filesysteem_layoute_en_d
>
>Het is zo dat alle applicaties leven onder een "/e" pad, bijvoorbeeld:
>"/e/ap/website.nl". Daaronder bevinden zich zgn "symlinks" (shortcuts)
>die wijzen naar het eigenlijke pad waar de data zich op de storage
>server bevind. Bijvoorbeeld: "/e/ap/website.nl/data" is een symlink
>die wijst naar "/d/app1/rw/00/website.nl/data". Deze symlinks zijn
>onder het beheer van NPO ICT en in principe doet het er niet toe
>waar deze heen wijst, omdat we iedereen aanmoedigen het /e pad,
>"/e/ap/website.nl/data" te gebruiken. Deze symlinks zijn nodig om
>onderscheid tussen verschillende soorten data te kunnen maken en om
>datamigraties zoals deze te kunnen doen.  Bij een migratie kopieren
>we de data naar een nieuwe locatie, in dit geval iets onder "/d/app3",
>zeg "/d/app3/rw/00/website.nl/data". ("app2" was al ergens anders voor
>in gebruik, vandaar de naam "app3") Na het kopieren van de data zorgen
>wij ervoor dat de symlink naar de nieuwe locatie gaat wijzen en als
>je voorheen "/e/ap/website.nl/data" gebruikte dan kan je dat gewoon
>blijven doen, hoef je niets aan te passen, omdat wij ervoor zorgen
>dat deze naar de correcte, nieuwe locatie wijst.  So far so good, dus.
>
>Wat is dan het probleem? PHP en ook sommige ftp clients hebben de
>gewoonte om symlinks te willen "dereferencen" (af te lopen). Dat
>betekent dat als php een symlink "/e/ap/website.nl/data" ziet, deze
>uitzoekt waar deze naar wijst (in dit geval
>"/d/app1/rw/00/website.nl/data") en daar vervolgens mee aan de slag
>gaat. Dit gebeurt als de "realpath" functie in PHP aangeroepen wordt en
>er zijn CMS'en die dit doen om paden canoniek te maken.
>Als zo'n canoniek pad vervolgens in een database opgeslagen wordt, of
>als het in een template oid terechtkomt, dan kan het mis gaan.
>Want wat gebeurt er dan? In een database komt ten onrechte een pad
>"/d/app1" te staan. Wij migreren de data naar "/d/app3", maar wij weten
>niet wat er in elke database staat (want de inhoud van databases is niet
>onder ons beheer), dus in de database blijft gewoon "/d/app1" staan. Op een
>later moment wordt de oude storage behorend bij "/d/app1" uitgezet
>en zal de website waarschijnlijk stuk gaan omdat er geen data onder
>"/d/app1" meer beschikbaar is.
>
>Om hiertegen te beschermen doen wij 3 dingen:
>1) Tijdens de migratie zorgen we ervoor dat de oude /d paden ("/d/app1")
>tijdelijk nog blijven werken. Dat doen we door een extra symlink te
>maken, die van het oude /d pad terug naar het /e pad wijst.
>Bijvoorbeeld: "/d/app1/rw/00/website.nl/data" -> "/e/ap/website.nl/data". 
>
>2) We maken een scan van het filesysteem om op zoek te gaan naar plekken
>waar ten onrechte /d paden gebruik worden. De output van deze scan is
>aan deze email toegevoegd. Met behulp van deze scan kun je zelf je
>website alvast checken op het gebruik van /d paden. Indien er /d paden
>gebruikt worden kunnen die simpel vervangen worden door /e paden:
>Als je de eerste 4 pad componenten ("/d/app1/XX/NN") vervangt door "/e"
>dan heb je altijd een correct "/e" pad.
>
>3) Bovenstaande vervangingsactie zullen wij na afloop van de migratie
>uitvoeren voor alle voorkomens van /d paden die we maar kunnen vinden.
>
>Er zijn 3 plekken waar /d paden kunnen voorkomen:
>1) In databases. Attached is de lijst van databases waar wij /d paden in
>vonden. 
>2) In bestanden. Attached is een lijst van php bestanden waar wij /d
>paden in vonden. Deze lijst is nog niet compleet, naast php bestanden
>zijn er nog vele andere bestandstypen. Na afloop van de migratie zullen
>we een vollediger lijst publiceren.
>3) In symlinks! Als je zelf een symlinks aangemaakt hebt, dan zou dat
>naar een /d pad kunnen zijn. Het is onze overtuiging dat het nooit nodig
>is om een symlink naar een /d pad aan te maken. Deze kunnen altijd of
>relatief zijn, of over een /e pad lopen. Voorbeeld: het kan gebeuren dat
>je een symlink van de docroot v/e website (welke leeft onder
>/e/ap/website.nl/pages) wilt maken naar z'n data partitie (welke leeft
>onder /e/ap/website.nl/data). In zo'n geval is het niet nodig om een /d
>pad te gebruiken, maar kan de symlink lopen van
>/e/ap/website.nl/page/.../link -> /e/ap/website.nl/data/.../target
>Ook gebeurt het vaak dat er meerdere deployments naast elkaar staan,
>met 1 symlink die de actieve deployment aangeeft. Wij adviseren om daar
>relatieve symlinks voor te gebruiken. Dus als je deployment "D1", "D2",
>"D3" hebt en een symlink "active" die de actieve aanwijst, dan kan je
>deze beter niet naar het absolute pad laten wijzen
>("/e/ap/website.nl/pages/active -> /e/ap/website.nl/pages/deployments/D3")
>maar naar een relatief pad ("/e/ap/website.nl/pages/active -> deployments/D3")
>
>Wij zullen alle 3 voorkomens aanpakken, maar het kan natuurlijk zijn dat
>er deployscripts oid gebruikt worden die het verkeerd doen. Dus bij deze
>het advies om nog eens goed naar dergelijke scripts te kijken en nog eens
>goed naar je website code en configuratie te kijken, zodat je zelf
>gecontroleerd deze zaken aan kan passen, voordat NPO ICT dit voor je
>doet.

==== Attachements ====
Hier de 3 genoemde lijsten:
  - {{:internetbeheer:algemeen:change:2017:databases.txt|databases}}
  - {{:internetbeheer:algemeen:change:2017:files.txt|files}}
  - {{:internetbeheer:algemeen:change:2017:symlinks.txt|symlinks}}

===== Herinnering =====
>Onderwerp: Migratie webhosting storage (herinnering)
>
>Beste Klant/Collega,
>
> Afgelopen week kondigden we aan dat in de periode van 16 januari tot 3
> februari de storage van de NPO webhosting omgeving ("het appcluster")
> gemigreerd wordt naar een nieuw storage platform.
>
> Afgelopen week is de storage behorend bij databases succesvol
> gemigreerd. Deze week is de website data zelf aan de beurt (denk aan
> code, plaatjes en andere data die bij een website kan horen)
> Ook deze migraties zullen weer tussen 1:00h en 5:00h 's nachts
> uitgevoerd worden.
>
> Voor de storage die deze week gemigreerd wordt gelden de
> waarschuwingen m.b.t. /e vs /d paden. Dus wellicht ten overvloede hier
> nogmaals de wall of text over dit onderwerp:
>
>---------------------------------------------------------------------
>Let op: bij deze laatste migratie is het van belang om aandacht
>te besteden aan de zgn "/d paden" vs "/e paden", want ook hier geldt
>dat als gevolg van de migratie de "/d" paden gaan wijzigen.
>Door nu aandacht aan dit issue te besteden voorkom je dat je website in
>de toekomst als gevolg van dit probleem stuk kan gaan.
>Zie ook:
>http://hosting.omroep.nl/sterretje-cluster:cluster-hosting#filesysteem_layoute_en_d
>
>Het is zo dat alle applicaties leven onder een "/e" pad, bijvoorbeeld:
>"/e/ap/website.nl". Daaronder bevinden zich zgn "symlinks" (shortcuts)
>die wijzen naar het eigenlijke pad waar de data zich op de storage
>server bevind. Bijvoorbeeld: "/e/ap/website.nl/data" is een symlink
>die wijst naar "/d/app1/rw/00/website.nl/data". Deze symlinks zijn
>onder het beheer van NPO ICT en in principe doet het er niet toe
>waar deze heen wijst, omdat we iedereen aanmoedigen het /e pad,
>"/e/ap/website.nl/data" te gebruiken. Deze symlinks zijn nodig om
>onderscheid tussen verschillende soorten data te kunnen maken en om
>datamigraties zoals deze te kunnen doen.  Bij een migratie kopieren
>we de data naar een nieuwe locatie, in dit geval iets onder "/d/app3",
>zeg "/d/app3/rw/00/website.nl/data". ("app2" was al ergens anders voor
>in gebruik, vandaar de naam "app3") Na het kopieren van de data zorgen
>wij ervoor dat de symlink naar de nieuwe locatie gaat wijzen en als
>je voorheen "/e/ap/website.nl/data" gebruikte dan kan je dat gewoon
>blijven doen, hoef je niets aan te passen, omdat wij ervoor zorgen
>dat deze naar de correcte, nieuwe locatie wijst.  So far so good, dus.
>
>Wat is dan het probleem? PHP en ook sommige ftp clients hebben de
>gewoonte om symlinks te willen "dereferencen" (af te lopen). Dat
>betekent dat als php een symlink "/e/ap/website.nl/data" ziet, deze
>uitzoekt waar deze naar wijst (in dit geval
>"/d/app1/rw/00/website.nl/data") en daar vervolgens mee aan de slag
>gaat. Dit gebeurt als de "realpath" functie in PHP aangeroepen wordt en
>er zijn CMS'en die dit doen om paden canoniek te maken.
>Als zo'n canoniek pad vervolgens in een database opgeslagen wordt, of
>als het in een template oid terechtkomt, dan kan het mis gaan.
>Want wat gebeurt er dan? In een database komt ten onrechte een pad
>"/d/app1" te staan. Wij migreren de data naar "/d/app3", maar wij weten
>niet wat er in elke database staat (want de inhoud van databases is niet
>onder ons beheer), dus in de database blijft gewoon "/d/app1" staan. Op een
>later moment wordt de oude storage behorend bij "/d/app1" uitgezet
>en zal de website waarschijnlijk stuk gaan omdat er geen data onder
>"/d/app1" meer beschikbaar is.
>
>Om hiertegen te beschermen doen wij 3 dingen:
>1) Tijdens de migratie zorgen we ervoor dat de oude /d paden ("/d/app1")
>tijdelijk nog blijven werken. Dat doen we door een extra symlink te
>maken, die van het oude /d pad terug naar het /e pad wijst.
>Bijvoorbeeld: "/d/app1/rw/00/website.nl/data" -> "/e/ap/website.nl/data". 
>
>2) We maken een scan van het filesysteem om op zoek te gaan naar plekken
>waar ten onrechte /d paden gebruik worden. De output van deze scan is
>aan deze email toegevoegd. Met behulp van deze scan kun je zelf je
>website alvast checken op het gebruik van /d paden. Indien er /d paden
>gebruikt worden kunnen die simpel vervangen worden door /e paden:
>Als je de eerste 4 pad componenten ("/d/app1/XX/NN") vervangt door "/e"
>dan heb je altijd een correct "/e" pad.
>
>3) Bovenstaande vervangingsactie zullen wij na afloop van de migratie
>uitvoeren voor alle voorkomens van /d paden die we maar kunnen vinden.
>
>Er zijn 3 plekken waar /d paden kunnen voorkomen:
>1) In databases. Attached is de lijst van databases waar wij /d paden in
>vonden. 
>2) In bestanden. Attached is een lijst van php bestanden waar wij /d
>paden in vonden. Deze lijst is nog niet compleet, naast php bestanden
>zijn er nog vele andere bestandstypen. Na afloop van de migratie zullen
>we een vollediger lijst publiceren.
>3) In symlinks! Als je zelf een symlinks aangemaakt hebt, dan zou dat
>naar een /d pad kunnen zijn. Het is onze overtuiging dat het nooit nodig
>is om een symlink naar een /d pad aan te maken. Deze kunnen altijd of
>relatief zijn, of over een /e pad lopen. Voorbeeld: het kan gebeuren dat
>je een symlink van de docroot v/e website (welke leeft onder
>/e/ap/website.nl/pages) wilt maken naar z'n data partitie (welke leeft
>onder /e/ap/website.nl/data). In zo'n geval is het niet nodig om een /d
>pad te gebruiken, maar kan de symlink lopen van
>/e/ap/website.nl/page/.../link -> /e/ap/website.nl/data/.../target
>Ook gebeurt het vaak dat er meerdere deployments naast elkaar staan,
>met 1 symlink die de actieve deployment aangeeft. Wij adviseren om daar
>relatieve symlinks voor te gebruiken. Dus als je deployment "D1", "D2",
>"D3" hebt en een symlink "active" die de actieve aanwijst, dan kan je
>deze beter niet naar het absolute pad laten wijzen
>("/e/ap/website.nl/pages/active -> /e/ap/website.nl/pages/deployments/D3")
>maar naar een relatief pad ("/e/ap/website.nl/pages/active -> deployments/D3")
>
>Wij zullen alle 3 voorkomens aanpakken, maar het kan natuurlijk zijn dat
>er deployscripts oid gebruikt worden die het verkeerd doen. Dus bij deze
>het advies om nog eens goed naar dergelijke scripts te kijken en nog eens
>goed naar je website code en configuratie te kijken, zodat je zelf
>gecontroleerd deze zaken aan kan passen, voordat NPO ICT dit voor je
>doet.

==== Attachements ====
Hier de 3 genoemde lijsten:
  - {{:internetbeheer:algemeen:change:2017:databases.txt|databases}}
  - {{:internetbeheer:algemeen:change:2017:files.txt|files}}
  - {{:internetbeheer:algemeen:change:2017:symlinks.txt|symlinks}}

===== Update =====
>Onderwerp: Migratie webhosting storage (update)
>
>Beste Klant/Collega,
>
> In de periode van 16 januari tot 3 februari is de storage van de NPO
> webhosting omgeving ("het appcluster") gemigreerd naar een nieuw
> storage platform.
>
> Voor die migratie hebben we aangegeven dat er een potentieel probleem
> met zgn "/d paden" is. In het kort: er zijn paden die beginnen met /d
> en paden die beginnen met /e. Voor paden die beginnen met /e kunnen
> wij garanderen dat die gelijk blijven. Paden beginnend met /d
> zijn gewijzigd. Zorg dus dat je altijd in code of configuratie een /e-pad
> en nooit een /d-pad gebruikt, want dan kan je website stuk gaan".
>
> In de tussentijd hebben we 2 dingen gedaan:
> 1) Een nieuwe scan op het gebruik van /d paden gemaakt.
> 2) Ervoor gezorgd dat de oude /d paden voorlopig nog blijven werken.
>
> Uit de nieuwe scan blijkt dat er nog steeds veel referenties aan /d
> paden zijn. Zo veel dat wij het niet verstandig achten dit
> grootschalig om te zetten. Inplaats hiervan zullen we de voorlopige
> workaround waarbij oude /d paden blijven werken voorlopig behouden.
>
> Wij adviseren om deze nieuwe lijsten door te nemen en waar nodig
> aanpassingen te maken, om zo beter voorbereid te zijn op het moment
> dat de huidige workaround niet meer voortgezet kan worden.
>
> Wellicht ten overvloede hier nogmaals de oorspronkelijke tekst over
> dit onderwerp:
>
>---------------------------------------------------------------------
>Let op: bij deze laatste migratie is het van belang om aandacht
>te besteden aan de zgn "/d paden" vs "/e paden", want ook hier geldt
>dat als gevolg van de migratie de "/d" paden gaan wijzigen.
>Door nu aandacht aan dit issue te besteden voorkom je dat je website in
>de toekomst als gevolg van dit probleem stuk kan gaan.
>Zie ook:
>http://hosting.omroep.nl/sterretje-cluster:cluster-hosting#filesysteem_layoute_en_d
>
>Het is zo dat alle applicaties leven onder een "/e" pad, bijvoorbeeld:
>"/e/ap/website.nl". Daaronder bevinden zich zgn "symlinks" (shortcuts)
>die wijzen naar het eigenlijke pad waar de data zich op de storage
>server bevind. Bijvoorbeeld: "/e/ap/website.nl/data" is een symlink
>die wijst naar "/d/app1/rw/00/website.nl/data". Deze symlinks zijn
>onder het beheer van NPO ICT en in principe doet het er niet toe
>waar deze heen wijst, omdat we iedereen aanmoedigen het /e pad,
>"/e/ap/website.nl/data" te gebruiken. Deze symlinks zijn nodig om
>onderscheid tussen verschillende soorten data te kunnen maken en om
>datamigraties zoals deze te kunnen doen.  Bij een migratie kopieren
>we de data naar een nieuwe locatie, in dit geval iets onder "/d/app3",
>zeg "/d/app3/rw/00/website.nl/data". ("app2" was al ergens anders voor
>in gebruik, vandaar de naam "app3") Na het kopieren van de data zorgen
>wij ervoor dat de symlink naar de nieuwe locatie gaat wijzen en als
>je voorheen "/e/ap/website.nl/data" gebruikte dan kan je dat gewoon
>blijven doen, hoef je niets aan te passen, omdat wij ervoor zorgen
>dat deze naar de correcte, nieuwe locatie wijst.  So far so good, dus.
>
>Wat is dan het probleem? PHP en ook sommige ftp clients hebben de
>gewoonte om symlinks te willen "dereferencen" (af te lopen). Dat
>betekent dat als php een symlink "/e/ap/website.nl/data" ziet, deze
>uitzoekt waar deze naar wijst (in dit geval
>"/d/app1/rw/00/website.nl/data") en daar vervolgens mee aan de slag
>gaat. Dit gebeurt als de "realpath" functie in PHP aangeroepen wordt en
>er zijn CMS'en die dit doen om paden canoniek te maken.
>Als zo'n canoniek pad vervolgens in een database opgeslagen wordt, of
>als het in een template oid terechtkomt, dan kan het mis gaan.
>Want wat gebeurt er dan? In een database komt ten onrechte een pad
>"/d/app1" te staan. Wij migreren de data naar "/d/app3", maar wij weten
>niet wat er in elke database staat (want de inhoud van databases is niet
>onder ons beheer), dus in de database blijft gewoon "/d/app1" staan. Op een
>later moment wordt de oude storage behorend bij "/d/app1" uitgezet
>en zal de website waarschijnlijk stuk gaan omdat er geen data onder
>"/d/app1" meer beschikbaar is.
>
>Om hiertegen te beschermen doen wij 3 dingen:
>1) Tijdens de migratie zorgen we ervoor dat de oude /d paden ("/d/app1")
>tijdelijk nog blijven werken. Dat doen we door een extra symlink te
>maken, die van het oude /d pad terug naar het /e pad wijst.
>Bijvoorbeeld: "/d/app1/rw/00/website.nl/data" -> "/e/ap/website.nl/data". 
>
>2) We maken een scan van het filesysteem om op zoek te gaan naar plekken
>waar ten onrechte /d paden gebruik worden. De output van deze scan is
>aan deze email toegevoegd. Met behulp van deze scan kun je zelf je
>website alvast checken op het gebruik van /d paden. Indien er /d paden
>gebruikt worden kunnen die simpel vervangen worden door /e paden:
>Als je de eerste 4 pad componenten ("/d/app1/XX/NN") vervangt door "/e"
>dan heb je altijd een correct "/e" pad.
>
>3) Bovenstaande vervangingsactie zullen wij na afloop van de migratie
>uitvoeren voor alle voorkomens van /d paden die we maar kunnen vinden.
>
>Er zijn 3 plekken waar /d paden kunnen voorkomen:
>1) In databases. Attached is de lijst van databases waar wij /d paden in
>vonden. 
>2) In bestanden. Attached is een lijst van php bestanden waar wij /d
>paden in vonden. Deze lijst is nog niet compleet, naast php bestanden
>zijn er nog vele andere bestandstypen. Na afloop van de migratie zullen
>we een vollediger lijst publiceren.
>3) In symlinks! Als je zelf een symlinks aangemaakt hebt, dan zou dat
>naar een /d pad kunnen zijn. Het is onze overtuiging dat het nooit nodig
>is om een symlink naar een /d pad aan te maken. Deze kunnen altijd of
>relatief zijn, of over een /e pad lopen. Voorbeeld: het kan gebeuren dat
>je een symlink van de docroot v/e website (welke leeft onder
>/e/ap/website.nl/pages) wilt maken naar z'n data partitie (welke leeft
>onder /e/ap/website.nl/data). In zo'n geval is het niet nodig om een /d
>pad te gebruiken, maar kan de symlink lopen van
>/e/ap/website.nl/page/.../link -> /e/ap/website.nl/data/.../target
>Ook gebeurt het vaak dat er meerdere deployments naast elkaar staan,
>met 1 symlink die de actieve deployment aangeeft. Wij adviseren om daar
>relatieve symlinks voor te gebruiken. Dus als je deployment "D1", "D2",
>"D3" hebt en een symlink "active" die de actieve aanwijst, dan kan je
>deze beter niet naar het absolute pad laten wijzen
>("/e/ap/website.nl/pages/active -> /e/ap/website.nl/pages/deployments/D3")
>maar naar een relatief pad ("/e/ap/website.nl/pages/active -> deployments/D3")
>
>Wij zullen alle 3 voorkomens aanpakken, maar het kan natuurlijk zijn dat
>er deployscripts oid gebruikt worden die het verkeerd doen. Dus bij deze
>het advies om nog eens goed naar dergelijke scripts te kijken en nog eens
>goed naar je website code en configuratie te kijken, zodat je zelf
>gecontroleerd deze zaken aan kan passen, voordat NPO ICT dit voor je
>doet.

==== Attachements ====
Hier de 3 genoemde lijsten:
  - {{:internetbeheer:algemeen:change:2017:databases-update.txt|databases}}
  - {{:internetbeheer:algemeen:change:2017:files-update.txt|files}}
  - {{:internetbeheer:algemeen:change:2017:symlinks-update.txt|symlinks}}