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
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
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.