Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Det största problemet med opensource-versionen av varnish är just att den inte stödjer inkommande HTTPS, eller utgående HTTPS. För att lösa det är tanken att använda HAproxy både som TLS-terminerare för inkommande trafik, samt som "TLS onloader" för trafik riktat till origin-server. Det finns fungerande exempel på hur man använder HAproxy som onloader här: https://varnish-cache.org/docs/trunk/users-guide/vcl-backends.html#connecting-through-a-proxy

Vidare är det relevant att vi kan behålla cache även om varnish (eller maskinen den går på) startar om, så vi kan fortsätta servera data från cache om bakomliggande nod är nere i händelse av att våra egna maskiner får strömavbrott, behöver uppdatera kernel eller liknande. Detta finns inte i open source varnish som standard (enterprise-versionen verkar kunna läsa det med sin MSE (Massive Storage Engine), däremot finns det ett nytt open source storage backend som dykt upp som ser ut att kunna lösa detta i form av SLASH med sin storage engine "fellow": https://gitlab.com/uplex/varnish/slash/-/blob/master/README.rst så den ser ut som en bra kandidat för att lösa detta problem.

Cache-invalidering

Sekunden efter man aktiverar en cache kommer någon undra varför en ändring man gjort inte syns på hemsidan. Vi behöver därför stödja invalidering av cache på beställning. Antingen genom att man skickar en HTTP PURGE request till den URL som ska invalideras, eller, om applikationen på origin-servern är mer cache-aware, kan tagga sidor med headers och sedan använda exempelvis varnish modulen xkey för att kasta alla relaterade sidor. En sådan request behöver spridas över alla körande cache-noder. Tanken är att sköta detta purge-spridande via MQTT-meddelanden som kan spridas både inom ett DC och mellan DC. Förmodligen kommer vi använda en MQTT-broker per datacenter, och sen bygga bryggor så varje MQTT-broker ansvarar för att pusha sina dc-specifika topics till alla andra brokers i andra datacenter, det leder i så fall till en full mesh koppling mellan alla brokers. Work-in-progress kod för MQTT-prataren finns här: https://github.com/SUNET/sunet-cdnp.

...