Beste klant/collega,

(Is dit bericht niet goed leesbaar? Bekijk dan de online versie.)

Wij vragen aandacht voor het volgende:

1. Afkondiging Verstoring CHP5-Prod ODF storage controller
2. Oorzaakanalyse en maatregelen/vervolgstappen storing
3. Tips voor goed gebruik van persistent volumes in CHP

De verstoring op de ODF storage controller is verholpen. Sinds 19 juni 2025, 12:00h werkt de clusterstorage weer naar behoren.

Laat het ons weten indien er nog problemen optreden in applicaties.

De aanleiding van de storing was een overbelasting van een component van de in het cluster gebruikte storage oplossing, te weten de Ceph Metadata Server (MDS). Als gevolg van deze overbelasting kwam de reguliere operatie van de MDS in de knel, wat zich uitte in het niet meer goed op kunnen starten van pods en vertragingen in reeds draaiende pods. Dit was vooral zichtbaar in pods waar persistent volumes (PVC's) aan hangen met veel bestanden er in.

Een belangrijk onderdeel van het CHP openshift cluster is de storage. Elke applicatie in het cluster kan een stuk storage aanvragen (een zogenaamde PVC; Persistent Volume Claim) om data voor langere tijd op te slaan. Dit is nuttig overal waar langere termijn opslag nodig is. Denk aan databases, ge-uploade data, caches, enz. Deze storage komt in een aantal smaken; een belangrijk onderscheid is RWX (Read Write Many) vs RWO (Read Write Once). In geval van RWO storage is er een 1-op-1 koppeling tussen de storage en de gebruiker daarvan (een pod). Dus 1 RWO PVC kan maar tegelijkertijd worden gebruikt door maximaal 1 pod. RWO storage is geschikt voor bijvoorbeeld databases of caches waar er maar 1 proces hoeft te lezen of te schrijven naar de storage. Bij RWX storage kunnen meerdere pods tegelijkertijd met dezelfde storage connecten. Dit kan van belang zijn waar storage gedeeld moet worden. Denk aan een website waar redacties of gebruikers content kunnen uploaden. In zo'n geval zullen er vanuit performance en redundancy overwegingen meerdere pods tegelijkertijd draaien en is het wenselijk dat een stukje content dat ge-upload is via pod X later weer uitgeserveerd kan worden door pod Y.

Nu wil het geval dat de techniek achter de RWX resp. RWO storage heel verschillend is. In beide gevallen wordt de storage geleverd door een techniek genaamd Ceph, maar de details verschillen. In geval van RWO storage is er maar 1 schrijvend proces en hoeft er dus nergens kennis gedeeld te worden over wat er allemaal op de PVC staat. Het schrijvende proces (en de linux kernel daarachter) kan dat in z'n eentje regelen. Het mechanisme dat daarvoor gebruikt wordt heet Rados Block Device". Bij RWX storage echter zijn er verschillende processen, vanaf verschillende servers die tegelijkertijd naar dezelfde storage aan het schrijven of lezen zijn. Hiervoor is onderlinge synchronisatie nodig om ervoor te zorgen dat alle processen een consistent beeld hebben wat op enig moment de status van de gedeelde storage is. Het mechanisme hiervoor heet CephFS.

Een belangrijk concept bij elke vorm van storage is metadata. De metadata in een filesysteem zegt iets over de individuele bestanden. “Hoe groot is een bestand”, “Wie is de eigenaar”, “Wat zijn de lees/schrijf-rechten”. Naast de inhoud van een bestand moet ook de metadata gesynchroniseerd worden tussen alle gebruikers ervan. In CephFS is dit de taak van de “Metadata Server” (MDS). Deze fungeert als een soort centraal aanspreekpunt voor alles wat met metadata van bestanden te maken heeft. In de huidige opzet van het cluster is er maar 1 MDS en die moet in z'n eentje alle opdrachten van alle processen in het cluster afhandelen. Normaal gaat dat goed, totdat…

In een gedeeld cluster is het belangrijk dat alle processen uitsluitend bij hun eigen content kunnen en niet bij die van andere processen. Je zou niet willen dat website X zomaar de content van website Y aan kan passen. Ook niet als pods van beide websites toevallig even op dezelfde servers draaien. Hiertoe is in Openshift een rechtenstructuur ingericht om dit af te dwingen. Dit volgt deels uit het container aspect van Openshift; in elke pod zitten 1 of meer containers en de bedoeling is dat processen niet kunnen zien wat er buiten hun container gebeurt. Maar stel nou dat er een bug in het besturingssysteem zit waardoor in bepaalde gevallen processen toch buiten hun container kunnen kijken. Voor die gevallen is er een tweede laag van security, genaamd Security Enhanced Linux (SELinux). In SELinux heeft elke container en elk stuk storage z'n eigen zogeheten Security Context. Daarbovenop zijn regels actief die afdwingen dat een proces met security context X uitsluitend bij storage met security context Y mag kijken. Dus stel dat er in dit scenario een probleem is waardoor een proces buiten z'n eigen container kan kijken, dan kan dit proces nog steeds niet bij de storage van z'n buren, omdat de security contexts niet bij elkaar passen.

Dat is leuk, maar het probleem is dat die security context voor de storage enkel gedefinieerd is op losse bestanden. Dit zorgt ervoor dat als een pod opstart die gebruik maakt van persistent storage alle bestanden in die persistent storage voorzien moeten worden van een nieuw label waarin in essentie staat “Hee, vanaf nu mag ook pod X bij dit bestand”.

Goed, dus zo ver weten we dat als een pod gestart wordt waar een PVC aan hangt, dat er dan een relabel actie op alle bestanden in de PVC uitgevoerd moet worden. Maar als een pod eenmaal draait dan hoeft dat niet meer en is het probleem maar tijdelijk, toch?

Dit valt in de praktijk nogal tegen, er zijn namelijk in het cluster meerdere omstandigheden die voor frequent opstartende pods kunnen zorgen:

1. Cronjobs: De mogelijkheid bestaat om in het cluster een z.g.n. “cronjob” in te stellen. Dit is voor taken die met een bepaalde frequentie (elke minuut, of elk uur) moeten gebeuren. Als er een cronjob is die elke minuut vuurt zal er dus elke minuut een nieuwe pod gestart worden.
2. Autoscaling: In het cluster is het mogelijk om automatisch pods bij te schalen als het drukker wordt en weer af te schalen als ze niet meer nodig zijn. Mooi, maar elke bijschaalactie zorgt voor het starten van een pod.

Stel nou dat een pod opstart waar een PVC gekoppeld is met daarin heel veel (denk tienduizenden of honderdduizenden) bestanden. Voordat die pod kan starten moeten eerst alle bestanden voorzien worden van een nieuw label. En zo'n label is informatie over een bestand, m.a.w. metadata. En als het nou RWX storage betreft dan moet dat allemaal via het centrale aanspreekpunt, de metadataserver (MDS).

Dus als er maar genoeg pods zijn die frequent opstarten (cronjobs, autoscaling), met daarin genoeg bestanden die bij elke opstart actie gerelabeled moeten worden en het betreft RWX storage waarbij elke individuele metadata actie resulteert in een opdracht naar de centrale metadata server, dan is het niet gek dat op enig moment die MDS de beperkende factor wordt en de werkdruk niet meer aankan. Met als resultaat dat relabel acties langer duren, dus pods er langer over doen om op te starten en websites vertragingen ondervinden als ze data willen gebruiken die zich op een stukje gedeelde storage bevinden.

En dat is precies wat we de afgelopen week hebben zien gebeuren.

Het relabelen van bestanden is in overleg met de betrokken afnemers tijdelijk uitgezet. Hiermee ruilen we security in voor performance. De checks op de labels staan voor deze pods en storage nu uit. Hierdoor hoeft niet meer elk bestand gerelabeld te worden als een pod start. Dit heeft ervoor gezorgd dat de CPU belasting van de MDS gedaald van ~200% naar 20%–80% en hiermee is het acute probleem verholpen.

We kijken naar manieren om betere monitoring op de MDS te hebben zodat we in een vroeger stadium zien dat deze overbelast dreigt te raken.

De brand is vooralsnog geblust, maar er slingert nogsteeds brandbaar materiaal rond in het cluster. Om te voorkomen dat dit in de toekomst ook een keer vlam vat is het zaak om de oorzaken weg te gaan nemen.

We gaan met onze afnemers in gesprek hoe de storage beter uitgenut kan worden. Maatregelen waar aan gedacht kan worden zijn:

• Waar mogelijk RWX storage omzetten in RWO storage
• Het opruimen en in toom houden van bestanden die niet meer gebruikt worden. (denk aan caches waar honderdduizenden bestandjes inzitten)
• Het anders inrichten van cronjobs (supercronic), zodat er minder opstartende pods zijn.

Daarnaast gaan we kijken naar een setup met meerdere MDS'en, zodat ze een hogere load aankunnen. (in eerdere versies van het cluster was dit technisch nog niet mogelijk, sinds enige tijd lijkt dit wel gesupport te zijn)

Tot slot wat tips om de storage in CHP effectief te benutten:

• Gebruik waar mogelijk de RWO storage class ipv RWX.
• Zet cronjobs om naar Supercronic.
• Doe geen caching op een RWX filesysteem. Nginx is veel blijer met een cache die in een tmpfs (ramdisk) leeft. Object caching (waar de applicatie z'n eigen caching doet) is beter op z'n plek in een key/value store als Redis dan op een (shared) filesysteem.
• Zorg dat het aantal bestanden in RWX storage in toom gehouden wordt. Als het cache bestanden zijn die weer eenvoudig opnieuw aangemaakt kunnen worden, maak dan een cronjob (supercronic…) die bestanden ouder dan een bepaalde tijd verwijdert.

Team Hosting&Streaming is gedurende al het onderhoud via de normale kanalen bereikbaar. Zie de contact pagina.