Load balancing gennemgået: også kaldet F5 – med virkelige cases

Inden for drift og sikkerhed kan man næsten ikke komme udenom ét ord – load balancing. Og når det nævnes, er den første enhed, mange tænker på, “F5”. Det interessante er, at F5 egentlig er et firmanavn (F5 Networks), men produkterne blev så kendte, at navnet langsomt blev synonymt med en load balancer – ligesom “at google” blev synonymt med at søge.

Denne artikel gennemgår det grundigt: hvad F5 egentlig er, hvordan lag 4 og lag 7 adskiller sig, og hvordan man konfigurerer i virkelige scenarier.

1. Hvad løser load balancing egentlig?

Load balance handler i bund og grund om at fordele arbejdsopgaver på flere driftsenheder – fx webservere, FTP-servere eller virksomhedens kritiske applikationsservere – så de udfører arbejdet i fællesskab.

Teknisk set præsenterer den sig udadtil som envirtuel serveradresse. Når brugere forbinder, videresender den forbindelsen via todvejs netværksadressetranslation (NAT) til den mest egnede fysiske server. Brugeren ser altid den samme indgang; bagved bærer en hel flok maskiner byrden.

Den skal løse tre ting:frygt for nedbrud(single point of failure),frygt for at knække under belastning(ydeevneflaskehals),frygt for ikke at kunne skalere(manglende horisontal skalering).

2. Lag 4 vs. lag 7: det sted, man lettest bliver forvirret

Forskellen i én sætning:skal applikationslagsprotokollen fortolkes eller ej. Den forskel afgør direkte både evnegrænser og ydeevne.

Load balancing på lag 4 (transportlaget)

• Arbejdslag: OSI lag 4, TCP/UDP-protokollen
• Videresendelsesgrundlag: kilde-IP, destinations-IP, portnummer – applikationsdata berøres ikke
• Kerneevner: portvideresendelse, genbrug af TCP-forbindelser, health checks på lag 4 (TCP-handshake), basal DDoS-beskyttelse
• Ydeevne: ekstremt høj videresendelseseffektivitet, tæt på hardwaregrænsen, forsinkelser på mikrosekundniveau
• Typiske scenarier: databaser (MySQL/Redis), TCP-tjenester (spilservere, Netty-tjenester), lastbalancering af links på tværs af datacentre
• Representative produkter: LVS, F5 (lag 4-tilstand), HAProxy (lag 4-tilstand), Nginx (stream-modulet)

Load balancing på lag 7 (applikationslaget)

• Arbejdslag: OSI lag 7, applikationsprotokoller som HTTP/HTTPS, DNS og FTP
• Videresendelsesgrundlag: URL, cookies, HTTP-headere, forespørgselsparametre, JSON-indhold
• Kerneevner: indholdsbaseret routing, SSL-offload, caching, rate limiting/circuit breaking, WAF-integration, session persistens, canary-udrulning
• Ydeevne: funktionsrig, men skal fortolke applikationsprotokollen; lidt højere forsinkelse (millisekundniveau), kompenseres via klyngeskalering
• Typiske scenarier: webapplikationer, mikrotjeneste-API'er, HTTPS-tjenester, canary-udrulning, API-gateways
• Representative produkter: Nginx, HAProxy (lag 7-tilstand), F5 (lag 7-modul), Kong, Spring Cloud Gateway

Huskeregel i én sætning: lag 4 ser på “vejskiltet” (IP og port) og videresender; lag 7 skal “pakke pakken ud” (se på indholdet), før den beslutter, hvor det skal sendes hen. Vil du have ydeevne, vælg lag 4; vil du have tricks, vælg lag 7.

3. Hvad er F5 BIG-IP egentlig stærk til?

F5's hovedprodukt BIG-IP LTM hedder officieltLocal Traffic Managerog kan lave load balancing på lag 4-7. Det er ikke blot en videresender; funktionslisten er temmelig lang: applikationsswitching, sessionswitching, tilstandsovervågning, intelligent NAT, generel persistens, håndtering af svarfejl, IPv6-gateway, avanceret routing, SSL-acceleration, intelligent HTTP-komprimering, TCP-optimering, indholdsbuffring, cookie-kryptering, filtrering af applikationsangreb, DoS- og SYN Flood-beskyttelse, firewall-pakkefiltrering …

Her er de mest praktiske udvalgt:

1. Multi-link load balancing og redundans

Kritiske forretningstjenester er ofte koblet til flere ISP-linjer for at sikre kvalitet og fjerne single points of failure. Her er to retninger:

• OUTBOUND-trafik(internt netværk → internettet): BIG-IP LC fordeler trafikken intelligent på forskellige internetgrænseflader og laver kildeadresse-NAT
• INBOUND-trafik(internet → internt netværk): binder begge ISP'ers offentlige adresser, besvarer DNS-forespørgsler til begge ISP'er og svarer intelligent ud fra servernes sundhedstilstand og RTT-tider

2. Server load balancing

Tilbyder tjenester udadtil via en VIP (virtuel IP, sammensat af IP-adresse og TCP/UDP-port) og udfører løbende health checks på lag 4-7 af målserverne. Opdages en fejlbetonet server, tages den ud af load balancing-gruppen. Med iRules kan TCP/UDP-pakker endda åbnes og behandles efter regler baseret på indholdstræk – fx dirigeres trafikken til forskellige servere efter URL.

3. Høj systemtilgængelighed

Dette er F5's største pral. I dual-redundans-tilstand sker derfailover på millisekundniveau(hurtigst på under 200 ms) med en påstået tilgængelighed på 99,999 %. Princippet: når alle sessioner passerer den aktive enhed, synkroniseres sessionsoplysningerne via synkroniseringsledningen til backup-enheden – derfor afbrydes brugernes forbindelser ikke ved failover. En watchdog-chip i enheden overvåger via hjerteslagsledningen modpartens spændingsniveau; dør den aktive, får backup straks besked om at overtage Shared IP og VIP.

4. Sikkerhed

BIG-IP følger firewallens designprincipper meddefault deny. Den kan rive ledige forbindelser ned for at modvirke DoS, udføre kilde-routingsporing for at modvirke IP-spoofing og afvise SYN uden ACK mod SYN-angreb. Funktionerne Dynamic Reaping fjerner effektivt ledige forbindelser under DoS-angreb, ogden accelererer afbrydelseshastigheden, efterhånden som angrebsvolumenet stiger– det er temmelig brutalt. Delay Binding-teknologien giver derimod bagendens servere fuld SYN Flood-beskyttelse.

5. SSL-acceleration

Hver BIG-IP har en SSL-hardwareaccelereringschip samt en licens med 100 TPS inkluderet uden ekstra betaling. Skal der skaleres senere, opgraderer man blot licensen.

4. F5 eller Nginx? Valgsammenligning

Det er det spørgsmål, der oftest stilles i det virkelige arbejde. De to er ikke konkurrenter, snarere komplementære.

F5 BIG-IP (hardware)

• Udrulningsform: dedikeret hardwareenhed (med specialfremstillede chips)
• Ydeevne: TCP-forbindelser i millionklassen, videresendelsesforsinkelse på mikrosekundniveau
• Funktioner: alt-i-ét – lag 4+7, SSL-offload, DDoS-beskyttelse, WAF, VPN, link-lastbalancering
• Pålidelighed: hardwareredundans (aktiv-standby), 99,999 % tilgængelighed
• Omkostninger: høje (hundrede tusinder til over en million), kræver professionelle ingeniører til vedligehold
• Skalerbarhed: afhænger af hardwareopgraderinger, lav fleksibilitet
• Drift: kompleks, kræver fortrolighed med den dedikerede konfigurationsgrænseflade og CLI

Nginx (software)

• Udrulningsform: software, kører på almindelige servere eller cloud-VM'er
• Ydeevne: TCP-forbindelser i hundredetusindklassen, forsinkelser på millisekundniveau, kan skaleres som klynge
• Funktioner: let og effektiv – lag 7 i centrum, understøtter lag 4, SSL-offload, caching, rate limiting, omvendt proxy
• Pålidelighed: aktiv-standby (Keepalived) skal konfigureres manuelt, afhænger af serverhardwarens stabilitet
• Omkostninger: open source og gratis, også Nginx Plus er forholdsvis billig
• Skalerbarhed: understøtter klyngeudrulning, elastisk skalering i cloudmiljøer
• Drift: enkel, konfigurationsfilen er letlæst, og backend-udviklere kommer hurtigt i gang

Vælg efter følgende pejlemærker:

• TCP-tjeneste med høj samtidighed (spil, værdipapirhandel) + maksimal tilgængelighed → F5 lag 4
• Kritisk forretningsindgang + sikkerhedskrav (WAF/DDoS) → F5 lag 7
• Mikrotjeneste-API-gateway + cloududrulning → Nginx lag 7
• Database/Redis-belastning + høj omkostningseffektivitet → Nginx lag 4
• Mellemstor forretning + hurtig iteration → Nginx (lag 4/7)
• Enterprise-datacenter + flere links → F5 ved indgangen, Nginx til intern trafiklast

Den sidste kombination er meget udbredt hos de store aktører – F5 vogter porten, Nginx styrer det indre.

5. Praktisk case: hvor indviklet er F5's konfiguration?

Mange, der får en F5 i hånden, reagerer først med:dette er en helt anden tankegang end en switch; jeg ved slet ikke, hvor jeg skal begynde. Konfigurationslogikken er et helt andet system.

Scenarie: to webservere betjener eksterne brugere med IP 192.168.192.10-20/24; der skal load balances via den eksterne adresse 192.168.27.100 på port 80.

Den simpleste load balancing behøver kun tre parametre, og de hænger lag på lag sammen:

• Node: den mest basale definition; hver server er en Node
• Pool: en gruppe Nodes, der modtager og behandler trafik, fx en webserverklynge
• Virtual Server: den udadtil vendende indgang, knyttet til en Pool

Dataflow: kundeforespørgsel → Virtual Server → Pool → Node.

Praktiske trin (BIG-IP-administrationsgrænsefladen):

• Trin 1: Aktivér enheden. Få F5 aktiveret først; guiden er enkel, men huskden skal være på nettet; gør det helst, før enheden monteres i rack– det er en erfaring fra en smertefuld lærdom
• Trin 2: Log ind. Åbn https://admin-IP i browseren; både standardbrugernavn og -kodeord er admin
• Trin 3: Opret VLAN. Network → VLANs; opret VLAN og tilføj grænseflader (vælg Untagged)
• Trin 4: Konfigurer IP. Networks → Self IPs; tildel en adresse til hvert VLAN
• Trin 5: Konfigurer routing. Networks → Routes; angiv standardgateway eller statiske ruter
• Trin 6: Konfigurer Pool. Local Traffic → Virtual Servers → Pools; angiv navn, health check (fx TCP), lastbalanceringsalgoritme (fx observed-member, observationsmetoden) samt de fysiske serveres IP og port
• Trin 7: Konfigurer Virtual Server. Local Traffic → Virtual Servers; associér Pool'en ovenfor og vælg balanceringsmetode (oftest RoundRobin)
• Trin 8: Konfigurer Monitor. Local Traffic → Monitors; tjek servernes sundhedstilstand og associér med Pool'en
• Trin 9: Konfigurer Redundantfor at etablere dual-redundans

6. Nogle nøgleparametre for Virtual Server

F5's kerne er Virtual Server; et par parametre, man ikke er opmærksom på, skaber problemer.

VS Type (type)har tre almindelige varianter:

• Performance L4: ren lag 4-videresendelse; TMM står kun for fordelingen af forbindelser og ændrer ikke TCP-parametre; klient-server-forbindelsen er 1:1. Hurtig videresendelse, ofte brugt i virksomheder. For at mindske påvirkningen af applikationen –vælg denne som førstevalg, når det er muligt
• Standard VS: klientens og serverens TCP-forbindelser er helt uafhængige. Bruges, når der behøves lag 7-funktioner (cookie-persistens, Session ID-persistens, header-persistens, transaktionsbaseret opdeling af langvarige forbindelser, SYN-angrebsbeskyttelse). Bemærk en egenskab:dens port er altid åben udadtil– selvom alle bagende Node'er er nede, kan VIP'ens port 80 stadig nås via telnet, blot websiden ikke kan åbnes. Husk det, når du bruger det til fejlfinding
• Forwarding IP: bruges til forbindelser mellem internt og eksternt netværk; har ingen Pool Member, og videresendelsen afhænger af lokal routing. Som standard har F5 ingen routing-funktion; der skal oprettes en VS med alle nuller for at aktivere routing-funktionen

Timeout skal stemme overens(det er en ægte faldgrube). Hvis der er konfigureret en TCP-profil på VS'en, accepteres UDP-forbindelser ikke. Vær særligt opmærksom på Idle Timeout-værdien i tcp –den skal koordineres med serveren. Sætter F5 150 sekunder, mens IIS-serveren har 300, opstår der masser af fejl. De to sider skal aftale tiderne indbyrdes.

Address/Port Translation: begge er som standard slået til. Skal VS-IP og den fysiske maskines IP være forskellige, skal Address Translation slås til; svarer VS'ens port 8080 til den fysiske adresses port 80, skal Port Translation slås til.

SNAT AutoMap: hvilken VLAN trafikken går ud ad, bliver SNAT-kildeadressen denne VLAN's Self IP. Har en VLAN flere Self IP'er, bruges de i rotation.

7. Hvorfor man absolut skal forstå “session persistens”

Dette er load balancing'ens mest oversete og mest fejludløsende begreb.

I e-handels- og onlineautentificeringssystemer skal en kunde gennem flere interaktioner for at fuldføre en transaktion. Disse interaktionerer tæt forbundne– når serveren behandler det andet trin, behøver den ofte at kende resultatet af det første. Det kræver, at alle disse interaktionerfuldføres af én og samme serverog ikke spredes af load balanceren ud på forskellige maskiner.

Det er her, session persistens (Persistence) har sin berettigelse. F5 realiserer det via Connectivity med valgfrie tilstande:

• Persistens efter kildeadresse: binding efter klientens kilde-IP
• Cookie-persistens: F5 indsætter automatisk en sessionscookie; mest brugt på lag 7
• SSL Session ID-persistens: genbruger SSL-sessionen
• Persistenstabel: understøtter flere timeouts og matchregler

Hvad er konsekvensen af en fejlkonfiguration? Brugeren lægger varer i kurven, genindlæser siden – og varerne er væk, fordi forespørgslen blev sendt til en anden server. Den slags driftsfejl er ekstremt besværlige at fejlfinde.

8. Et par uundgåelige praktiske detaljer

Her til sidst et par faldgruber, andre er trådt i, med direkte konklusioner:

• Vælg det rigtige lag til health checks: ser man kun på TCP-handshaket, bliver trafikken stadig videresendt, selvom serverporten er i live, men applikationen er død; skal applikationslaget tjekkes, brug en HTTP-type Monitor mod endpoints som /actuator/health
• Firewall skal bygges som “sandwich”: en enkelt firewall når ofte kun 30 % af linjehastighedens gennemstrømning; mere kræver flere enheder. Men en firewall kræver, at data går ind og ud ad samme vej, ellers afvises forbindelsen – F5's firewall load balancing-løsning løser dette problem og realiserer persistens gennem transparente enheder
• SSL-offload er den store CPU-besparelse: lad F5 håndtere HTTPS-handshakes og kryptering/dekryptering, mens backendens Java-applikation kun håndterer HTTP; ydeevneforbedringen er markant
• Lav belastningstest, før du kobler til produktion: lag 4 er hurtigt, men aktiverer du session persistens på en lag 4-VS, introducerer du tilstand – så skal ydeevneforventningerne beregnes på ny
• Hold øje med tre målinger: pool-status, Virtual Serverens gennemstrømning og nodernes sundhedstilstand
• Fejlfindingskommandoer: tmsh show ltm pool <pool-name> viser pool-status, tmsh show ltm virtual <vs-name> viser Virtual Server-status

Afsluttende ord

En load balancer ligner en “videresendelsesenhed”, men står reelt på den mest afgørende position i hele arkitekturen – al trafik skal passere dens hænder. Er den godt konfigureret, lægger brugerne ikke mærke til dens eksistens; er den dårligt konfigureret, ringer telefonen midt om natten.

I den nuværende cloud-native bølge er softwareløsninger som LVS, Nginx og HAProxy fuldt tilstrækkelige i små og mellemstore scenarier, med åbenlyse omkostningsfordele. Men ved kerneindgange i finans, værdipapirhandel og stor e-handel kan hardware-load balancing'ens værdi i stabilitet, failover på millisekundniveau og samlet sikkerhed endnu ikke erstattes på kort sigt.

Og selve navnet “F5” – rejsen fra virksomhed til kategori – siger noget i sig selv: når et produkt bruges som verbum, har det allerede vundet dette marked.

Lag 4 ser på vejskiltet, lag 7 pakker pakken ud; ydeevne → lag 4, tricks → lag 7.

Referencer: officielt materiale om F5 BIG-IP LTM, F5 load balancing-cases fra “Network Operations and Management”, teknisk sammenligning af load balancing på lag 4/7