aankondigingen:2020:c2020d07-keepalived-aanpassingen

no way to compare when less than two revisions

Differences

This shows you the differences between two versions of the page.


aankondigingen:2020:c2020d07-keepalived-aanpassingen [2024/03/07 17:08] (current) – created - external edit 127.0.0.1
Line 1: Line 1:
 +~~META:
 +title = C2020D07: Aanpassingen aan High Availability van Upload Omgevingen
 +~~
 +{{htmlmetatags>
 +metatag-keywords=(storing upload-sites.omroep.nl)
 +metatag-og:title=(Aanpassingen aan High Availability van Upload Omgevingen)
 +metatag-og:description=(
 + In de periode van 9--12 maart voeren we aanpasingen door in onze
 + upload omgevingen (upload-sites.omroep.nl,
 + upload-testsites.omroep.nl, upload.omroep.nl, upload-extern.omroep.nl
 + en upload-backendcluster.omroep.nl) Als gevolg van de aanpassingen
 + zullen bovengenoemde sites enkele seconden niet bereikbaar zijn.
 + Bestaande sessies zullen een hikje ondervinden en daarna gewoon weer
 + doorgaan. Er is geen impact voor websites of andere diensten.
 + )
 +}}
 +====== C2020D07:  Aanpassingen aan High Availability van Upload Omgevingen ======
 +Beste klant/collega,
 +
 +(Is dit bericht niet goed leesbaar? Bekijk dan de [[|online versie]].)
 +
 +Naar aanleiding van de
 +[[a2020d04-storing-upload-sites-20200225|verstoring van 25 februari 2020]]
 +voeren we in de periode van 9--12 maart aanpassingen door in onze upload
 +omgevingen (upload-sites.omroep.nl, upload-testsites.omroep.nl,
 +upload.omroep.nl, upload-extern.omroep.nl en upload-backendcluster.omroep.nl)
 +Als gevolg van de aanpassingen zullen bovengenoemde sites enkele
 +seconden niet bereikbaar zijn. Bestaande sessies zullen een hikje
 +ondervinden en daarna gewoon weer doorgaan. Er is geen impact voor
 +websites of andere diensten.
 +
 +Wat is het probleem? Onze upload omgevingen draaien in paartjes van 2
 +servers. Het idee is dat als de ene server uitvalt, de andere het werk
 +automatisch over kan nemen. Daarvoor gebruiken we een stukje software
 +genaamd "[[https://www.keepalived.org/|keepalived]]". Dat werkt heel goed
 +als een server ook werkelijk uitvalt. Maar er is iets anders dat fout
 +kan gaan, namelijk een verstoring in de netwerkverbinding tussen beide
 +servers. Ze doen het allebei nog, maar kunnen tijdelijk niet meer met
 +elkaar praten en weten van elkaar dus niet of ze up of down zijn.
 +Deze situatie heet "split-brain" Keepalived is zo gemaakt dat het altijd
 +**minstens** 1 instantie in leven wil houden. De prijs die daarvoor
 +betaald wordt is dat bij een split-brain beide nodes onafhankelijk
 +van elkaar beslissen dat ze de dienst in kwestie moeten gaan draaien
 +en dus op beide plekken de dienst (in ons geval een upload server)
 +geactiveerd wordt. Helaas conflicteert dat met onze cluster setup,
 +waar maar **maximaal** 1 instantie van een dienst mag draaien. (denk
 +bijvoorbeeld aan een job scheduling server waarbij je niet wilt dat jobs
 +dubbel uitgevoerd worden)
 +De laatste tijd zien we meer dan normaal korte verstoringen in de
 +netwerkverbindingen tussen paartjes van servers, met als gevolg een
 +grotere kans op een split-brain situatie. Omdat zo'n split-brain in het
 +geval van upload servers tot een volledige uitval van de dienst kan
 +leiden achten wij het noodzakelijk om dit probleem te adresseren.
 +
 +Wat gaan we er dan aan doen?
 +We constateren dat het eigenljk nooit voorkomt dat een server zomaar
 +uitvalt, maar dat recent de kans op een split-brain wel is toegenomen.
 +Dat betekent dat in dit geval het middel (keepalived) eigenlijk erger is
 +dan de kwaal (onverwachte uitval van een server) Daarom gaan we voor de
 +upload omgevingen keepalived de-activeren. Dat houdt in dat er in geval
 +van server-uitval geen automatische failover meer plaatsvindt. Inplaats
 +daarvan zal dan een handmatige failover nodig zijn. Dit kost uiteraard
 +iets meer tijd, maar weegt ons inziens op tegen het feit dat dan geen uitval als
 +gevolg van een split-brain situatie meer voor kan komen.
 +
 +Overigens gebruiken we voor onze loadbalancers ook keepalived. Daar
 +verandert helemaal niets aan. Dat komt omdat voor een loadbalancer een
 +split-brain situatie nauwelijks impact heeft. Er zijn in dat geval geen
 +diensten waarvan er maar maximaal 1 zou mogen draaien. Het te
 +loadbalancen IP adres is in zo'n geval tijdelijk even actief op beide
 +loadbalancers. Daar merkt verder niemand iets van.
 +
 +Naast keepalived bestaat er ook andere software (o.a.
 +([[https://github.com/opensvc/opensvc|opensvc]],
 +[[https://clusterlabs.org/pacemaker/|pacemaker]] en
 +[[https://corosync.github.io/corosync/|corosync]]) die garandeert dat er
 +maar **maximaal** 1 instance van een dienst draait. Echter, om die
 +garantie te kunnen maken zorgt deze software ervoor dat in een
 +split-brain situatie er maar 0 instanties draaien. Dus dat is nog steeds
 +een beetje middel-erger-dan-de-kwaal voor onze use case. Vandaar dat we
 +vooralsnog geen plannen hebben om voor upload instanties te switchen
 +naar deze klasse software.
 +
 +We hopen je op deze manier voldoende geinformeerd te hebben,
 +
 +het NPO Hosting team.
  
  • aankondigingen/2020/c2020d07-keepalived-aanpassingen.txt
  • Last modified: 2024/03/07 17:08
  • by 127.0.0.1