Læser om nedbrud på NemID: Fordel datapakker med ECMP-router

Verison2-brugerne debatterer ivrigt, hvordan man kan undgå nedbrud på NemID.

En router af typen ECMP (Equal Cost Multi Path) kan fordele trafikken mellem dine load balancere, og det kan være løsningen, der skal til for at sikre driften på systemer som NemID. Det anfører en Version2-bruger i debatten om nedbruddet på NemID 21. oktober.

I en time og et kvarter om morgenen var det ikke muligt at anvende NemID. Selvom der bliver anvendt redundans i systemet bag NemID, var det ikke nok til at holde systemet oppe, da en load balancer stod af som følge af en softwarefejl.

Læs også: Fejlramt loadbalancer sendte NemID til tælling trods redundans

ECMP-type routere fungerer på den måde, at alle pakker fra en TCP-forbindelse havner på samme load balancer, skriver Version2-brugeren. Det er stateless og kan performe i terabit klassen.

Hvis routerne og load balancerne bruger BFD eller tilsvarende fejldetekteringsprotokol, så kan et sådant setup have failover på 50 ms eller mindre. Og det er active-active, så i normal drift behøver man altså ikke have dyr hardware til at stå og lave ingenting.

Muligt at klare sig uden load balancer

Hvis routerne kan fungere som en load balancer, behøver man så en load balancer? Næh, i mange tilfælde kan man klare sig uden. Man skal bare have god overvågning, så en dårlig node kan blive sparket ud hurtigt. Men den hemmelighed oplyser sælgeren af hundedyre load balancer løsninger angiveligt ikke.

Man kan få en switch med 24x 10G og 4x 40G for cirka 30.000 og med support for ECMP. To af dem, og du burde være mere end godt kørende. Hvis man alene skal levere trafik i 1G-klassen, så kan man også få switche til under 10.000, der kan det samme.

Læs mere af debatten her

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (8)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Lasse Leegaard

ECMP er lavet til at fordele trafik over flere links i et netværk hvis du har flere veje gennem nettet der koster lige meget. Normalt vælges der kun en enkelt vej af routningsprotokollerne, men man kan etablere flere veje for at øge kapaciteten ved at bruge ECMP. Det er også en god måde at sikre man bruge sin backup kapacitet så den ikke bare står ubrugt hen. ECMP er ikke en server load balancing mekanisme mod dine servere da du typiske ikke flere paths fra din sidste router/firewall/loadbalancer.
BFD (BiDirectional Forwarding Detection) er en protokol der bruges mellem routere for at detektere om der kan sendes trafik begge veje mellem den - den kan reagere meget hurtigt. Det er typisk ikke noget der implementeres på en load balancer da den har clustermekanismer til at håndtere fejl.
Server load balancering er en helt anden historie.SLB devices er typisk sat op i et cluster, hvor to devices opfører sig som et device og deler state mellem sig - ganske som en firewall, så hvis den ene fejler vil den anden tage over med det samme (indenfor ganske få ms). Selv når du har to firewalls i et cluster omtaler du dem oftest som "firewallen" og ikke som "vores firewalls". Jeg gætter på at det er her forvirringen er opstået i første omgang.

SLB handler om meget andet end blot at fordele trafik. Det handler i høj grad om at fordele load, men også at gøre det intelligent og overtage nogle roller fra serverne. Der er blandt andet SSL offload, hvor SSL termineringen sker på SLBen istedet for på serveren, reel load balancering, hvor SLBen via prober kigger ned mod serverne og fordeler sessioner baseret på hvor travlt serverne har det eller hvor hurtigt de svarer. Det er heller ikke ualmindeligt at implementere visse L7 sikkerhedsfeatures som URL normalization eller TCP proxy, hvor mange sessioner fra en enkelt client opleves som en enkelt session fra serverens synpunkt - altsammen for at lette loadet på serverene.

En stor serverpark der kører samme applikation skal enten selv implementere disse funktionaliteter eller lade andre gøre det. Du kan sætte en eller to servere op til at have denne rolle - eventuelt samtidigt med at de er normale servere - eller du kan bede en SLB om at varetage opgaven.

Man kan sagtens klare sig med indbyggede routerfunktionaliteter langt hen af vejen, men der er en grund til at der er et marked for mere inteligente devices der kan mere, netop fordi der i nogle tilfælde er brug for mere.

  • 2
  • 0
Mikkel Mondrup Kristensen

Jeg ville ikke anbefale folk der ikke er meget inde i netværk at bruge ECMP som load balancing på andet end meget simple ting som f.eks DNS.
For eksempel giver det problemer at ICMP ikke nødvendigvis bliver load balanceret til samme maskine så det kan give MTU problemer der er meget svære at debugge.
Hvis man skal have mere en 2 maskiner som backends så ødelægger man sandsynligvis alle sessioner hver gang man tager en maskine ind og ud af produktion.
Så ikke at have state giver bare andre problemer.

  • 0
  • 0
Claus Bobjerg Juul

Én som i single point of failure ?

Kort sagt der er altid et single point for failure et eller andet sted. Det kunne fx være i den software der benyttes i et ellers redundant storage system, eller et Firewall cluster, eller at personen der opsætter dit redundante system begår en fejl.

  • 0
  • 0
Klavs Klavsen

Dem jeg har snakket med der kører ECMP - har en ecmp dæmon, enten ved hvert loadbalancer sæt eller per loadbalancer (hvis man ikke kører f.ex. vrrp imellem loadbalancerne - for oftest vil man jo gerne køre aktiv/aktiv) - og således kører ecmp dæmonen på hver LB og melder sig ind hvis "den er tilfreds" - og i det øjeblik den ikke længere annoncerer at den er et muligt endpoint for den offentlige ip - ryger den LB bare ud af mulige endpoints der routes til. ligsom routning på internettet foregår (sådan ca.)

  • 1
  • 0
Baldur Norddahl

Nu gik spørgsmålet på hvordan load balancerer man load balanceren. Et forslag hertil kunne være ECMP.

At man ikke kører BFD mellem load balanceren og dens tilhørende router betyder blot at man kan være lang tid om at opdage link fejl. Det kan load balancerens cluster funktionalitet ikke ændre på. Ikke at det normalt betyder så meget, da responstid på mindre end et sekund oftest ikke er relevant for de applikationer hvor de kommercielle off the shelf load balancere kan benyttes.

Når leverandører af load balancerer importerer funktioner fra serverne, som f.eks. SSL offloading, så betyder det netop at der ikke kan være effektiv fordeling af load på denne funktion. Set herfra er der to årsager til at vi ser load balancere med SSL offloading. Det ene er at producenterne kan tage flere penge for den funktion. Det andet at såfremt man bruger f.eks. cookies til at markere hvilken backend server der skal håndtere forespørgslen, så er det nødvendigt at load balanceren kan see data bagved krypteringen.

Men ud over det nødvendige SSL offloading, så er det temmeligt dumt at flytte funktionalitet fra serverne, som der trivielt kan være mange af, og over på load balanceren, som der typisk kun er en eller to af.

Det er også værd at nævne at Google har droppet SSL offloading fordi det ikke længere er relevant på moderne hardware. Førhen var det en funktion der kunne forbedres væsentligt med dedikeret hardware i en load balancer. Men nu er det noget der klares fint af serverne selv.

  • 1
  • 0
Baldur Norddahl

Én som i single point of failure ?

Nej du har naturligvis mindst to routere. De kan sættes op så at de laver den samme beslutning omkring routing af hver enkelt pakke, så at trafikken sendes det korrekte sted hen uanset hvilken router det går igennem.

Et simpelt setup kan være to routere og N servere. Hver server har to netkort og er forbundet direkte til begge routere.

En router i denne sammenhæng kan være en routing layer 3 switch med ECMP funktionalitet.

  • 1
  • 0
Baldur Norddahl

Fordele ved at bruge ECMP til load balancing:

1) Det skalerer 100%.
2) Det er billigt. Koster typisk en lille brøkdel af en traditionel hardware load balancer.
3) Passer godt til en biks hvor man foretrækker software løsninger, f.eks. Linux servere som load balancere.

Ulemper:

1) Der er et ICMP problem. Men det kan løses, se link til Cloudflare tidligere i tråden.
2) Det er ikke muligt at bruge f.eks. en cookie til at lave "sticky" http sessions. Hver ny indkommende TCP forbindelse havner på en tilfældig server.
3) Trafikken fordeles jævnt til alle servere uden hensyn til om en server er overbelastet i forhold til andre.
4) Hvis du ændrer i server antal, så vil de fleste af dine aktive TCP forbindelser tabes.
5) Mindre automatik, du skal selv stå for at bygge noget solidt overvågning der kan trække en server ud. BFD kan bruges til at detektere at serveren er gået helt død eller at et link er nede, men det opdager ikke en fejl på et højere niveau.

På trods af at listen over ulemper ser ud til at være længere end listen med fordele, så ville jeg ikke tøve med at bruge det. Specielt ikke i en virksomhed hvor penge ikke er noget der hænger på træerne. Kommercielle load balancere kan være endog meget dyre hvis de skal performe. Vi kan snakke om en million kroner eller mere og så kan den stadig ikke følge med den simple layer 3 switch med 24x 10G og 4x 40G der kun koster 30.000 kr i indkøb. Eller i den anden ende af spektret, så kan du få to ting for en pris ved at købe din switch med ECMP funktionalitet for under 10.000 kr.

Der er forholdsvise nemme løsninger til problemstillingerne. F.eks. kan man installere en software load balancer på samtlige servere. Så rammer et indgående request godt nok en tilfældig software load balancer, som så laver SSL dekryptering og aflæsning af HTTP sticky cookie, for så at sende det videre til den korrekte server. Det system skalerer også rent og man har tilmed altid det helt rigtige forhold mellem load balancere og backends. Hardwaren udnyttes optimalt.

Andre ting kan man ofte leve med. F.eks. så kan det godt ske at TCP session afbrydes hvis der ændres på antallet af servere, men det sker sjældent, så dine brugere vil formodentlig ikke beklage sig over det.

Der er en årsag til at de store drenge, som Cloudflare, ender med løsninger som f.eks. ECMP. De kommercielle aktører har simpelthen ikke en løsning der kan skalere til det niveau, og det de har, er prissat så at det truer forretningsplanen.

  • 2
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize