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: | ||
+ | metatag-og: | ||
+ | In de periode van 9--12 maart voeren we aanpasingen door in onze | ||
+ | upload omgevingen (upload-sites.omroep.nl, | ||
+ | upload-testsites.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: | ||
+ | Beste klant/ | ||
+ | |||
+ | (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.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 " | ||
+ | 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 " | ||
+ | **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:// | ||
+ | [[https:// | ||
+ | [[https:// | ||
+ | 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. | ||