Load balancing uitgelegd: ook bekend als F5, met praktijkvoorbeelden

Wie in operations of security werkt, komt haast niet om één begrip heen: load balancing. En bij load balancing is het eerste apparaat dat velen te binnen schiet 'F5'. Het grappige is: F5 is in werkelijkheid een bedrijfsnaam (F5 Networks), maar omdat het product zo beroemd werd, groeide het langzaam uit tot synoniem voor de load balancer — net zoals 'even googelen' het woord voor zoeken werd.

In dit artikel zetten we hem volledig uiteen: wat F5 precies is, waar layer 4 en layer 7 van elkaar verschillen en hoe je echte scenario's configureert.

1. Welk probleem lost load balancing eigenlijk op

Load balancing komt er in essentie op neer dat werk over meerdere operationele eenheden wordt verdeeld — denk aan webservers, FTP-servers en kritieke bedrijfsservers — zodat ze samen het werk verrichten.

Technisch gezien presenteert het zich naar buiten toe als éénvirtueel serveradres. Wanneer een gebruiker verbindt, stuurt het via tweewegs NAT (network address translation) de verbinding door naar de meest geschikte echte server. De gebruiker ziet altijd dezelfde ingang; achter de schermen dragen een hele rij machines de last.

Het lost drie dingen op:angst voor uitval(single point of failure), angst voor overbelasting(prestatieknelpunten), angst voor geblokkeerde groei(geen horizontale schaalbaarheid).

2. Layer 4 vs layer 7: het punt waar iedereen de mist ingaat

Het verschil komt in één zin neer op:of je het applicatielaagprotocol parseert of niet. Dat verschil bepaalt direct de capaciteitsgrenzen en de prestaties.

Layer 4-load balancing (transportlaag)

• Werklaag: laag 4 van het OSI-model, protocollen TCP/UDP
• Doorstuurcriteria: bron-IP, doel-IP, poortnummer — applicatiedata blijft onaangeroerd
• Kerncapaciteiten: poortdoorsturing, hergebruik van TCP-verbindingen, health checks op layer 4 (TCP-handshake), basale DDoS-bescherming
• Prestaties: extreem efficiënt doorsturen, dicht bij de hardwarelimiet, vertraging in microseconden
• Typische scenario's: databases (MySQL/Redis), TCP-diensten (gameservers, Netty-diensten), linkverdeling over datacenters heen
• Representatieve producten: LVS, F5 (layer-4-modus), HAProxy (layer-4-modus), Nginx (stream-module)

Layer 7-load balancing (applicatielaag)

• Werklaag: laag 7 van het OSI-model, applicatieprotocollen als HTTP/HTTPS, DNS en FTP
• Doorstuurcriteria: URL, cookie, HTTP-headers, verzoekparameters, JSON-inhoud
• Kerncapaciteiten: routering op basis van inhoud, SSL-offloading, caching, rate limiting en circuit breaking, WAF-integratie, sessiepersistentie, canary-releases
• Prestaties: rijk aan functies, maar applicatieprotocollen moeten worden geparseerd, wat iets meer vertraging geeft (milliseconden); op te vangen met clusteruitbreiding
• Typische scenario's: webapplicaties, microservice-API's, HTTPS-diensten, canary-releases, API-gateways
• Representatieve producten: Nginx, HAProxy (layer-7-modus), F5 (layer-7-module), Kong, Spring Cloud Gateway

Ezelsbruggetje in één zin: layer 4 kijkt alleen naar het 'verkeersbord' (IP en poort) en stuurt door; layer 7 'pakt het pakket uit' (bekijkt de inhoud) voordat het beslist waar het heen moet. Prestaties? Kies layer 4. Extra functies? Kies layer 7.

3. Waarin is F5 BIG-IP nu echt sterk

F5's vlaggenschip BIG-IP LTM heet officieel deLocal Traffic Manager, die load balancing op laag 4 tot 7 aankan. Het is meer dan een doorstuurmachine; de functielijst is behoorlijk lang: applicatie-switching, sessie-switching, statusmonitoring, intelligente NAT, algemene persistentie, respons- en foutafhandeling, IPv6-gateway, geavanceerde routering, SSL-versnelling, slimme HTTP-compressie, TCP-optimalisatie, contentbuffering, cookieversleuteling, filters tegen applicatieaanvallen, bescherming tegen DoS en SYN floods, firewallpakketfiltering ...

Een paar van de meest praktische:

1. Load balancing over meerdere links en redundantie

Kritieke bedrijfsprocessen hangen vaak aan lijnen van meerdere ISP's, voor kwaliteitsgarantie en om single points of failure weg te nemen. Daarbij zijn er twee richtingen:

• OUTBOUND-verkeer(intern naar extern): BIG-IP LC verdeelt het verkeer intelligent over verschillende internetinterfaces en past bron-NAT toe
• INBOUND-verkeer(extern naar intern): het koppelt de publieke adressen van beide ISP's, lost de DNS-verzoeken van beide partijen op en antwoordt intelligent op basis van de servergezondheid en RTT-tijden

2. Server load balancing

Via een VIP (virtueel IP, opgebouwd uit een IP-adres en een TCP/UDP-poort) biedt het diensten naar buiten aan, met continu L4- tot L7-health checks op de doelservers. Zodra een server uitvalt, wordt hij uit de load balancing-groep gehaald. Met iRules kun je bovendien TCP/UDP-pakketten openen en op inhoudskenmerken regels toepassen — bijvoorbeeld verkeer per URL naar verschillende servers sturen.

3. Hoge systeembeschikbaarheid

Dit is waar F5 het meest op steunt. In dubbele-redundantiemodusverloopt de omschakeling binnen milliseconden(het snelst binnen 200 ms), met een beschikbaarheid van naar verluidt 99,999%. Het principe: zodra sessies het Active-apparaat passeren, worden de sessiegegevens via een synchronisatiekabel naar het Backup-apparaat gestuurd — daardoor loopt de toegang van gebruikers bij een omschakeling niet vast. Een watchdog-chip in het apparaat bewaakt via heartbeatlijnen de signalen van de ander; valt de Active uit, dan neemt de Backup onmiddellijk het Shared IP en de VIP over.

4. Beveiliging

BIG-IP volgt het ontwerpprincipe van een firewall:standaard alles weigeren. Het kan inactieve verbindingen verbreken tegen DoS, bronroutering traceren tegen IP-spoofing en SYN's zonder ACK weigeren tegen SYN-aanvallen. De functie Dynamic Reaping ruimt efficiënt inactieve verbindingen op tijdens een DoS-aanval, enversnelt de verbreekfrequentie naarmate de aanval toeneemt— dat is flink. Delay Binding biedt de backendservers bovendien volledige bescherming tegen SYN floods.

5. SSL-versnelling

Elke BIG-IP heeft een hardwarechip voor SSL-versnelling en wordt geleverd met een licentie voor 100 TPS, zonder meerprijs. Moet je later opschalen, dan upgrade je gewoon de licentie.

4. F5 of Nginx? De keuzevergelijking

Dit is de vraag die in de praktijk het vaakst gesteld wordt. Het zijn geen concurrenten; ze vullen elkaar veeleer aan.

F5 BIG-IP (hardware)

• Vorm: speciale hardwareapparatuur (met aangepaste chips)
• Prestaties: TCP-verbindingen in de miljoenen, doorstuurvertraging in microseconden
• Functies: alleskunner — layer 4 + 7, SSL-offloading, DDoS-bescherming, WAF, VPN, linkverdeling
• Betrouwbaarheid: hardwareredundantie (dubbele stand-by), 99,999% beschikbaarheid
• Kosten: hoog (honderdduizenden tot miljoenen), professionele ingenieurs nodig voor beheer
• Schaalbaarheid: afhankelijk van hardware-upgrades, weinig flexibiliteit
• Beheer: complex, vraagt kennis van de eigen configuratie-interface en CLI

Nginx (software)

• Vorm: software, draaiend op gewone servers of cloudhosts
• Prestaties: TCP-verbindingen in de honderdduizenden, vertraging in milliseconden, uitbreidbaar via clusters
• Functies: licht en efficiënt — layer 7 als kern, met ondersteuning voor layer 4, SSL-offloading, caching, rate limiting en reverse proxy
• Betrouwbaarheid: dubbele stand-by (Keepalived) handmatig configureren, afhankelijk van de stabiliteit van de serverhardware
• Kosten: open source en gratis; Nginx Plus is betaalbaar
• Schaalbaarheid: clusterdeployment mogelijk, elastisch opschalen in cloudomgevingen
• Beheer: eenvoudig, configuratiebestanden goed leesbaar, backend-ingenieurs zijn snel wegwijs

Kiespad, volg het gewoon:

• Zwaar belaste TCP-diensten (gaming, effecten) + maximale beschikbaarheid → F5 op layer 4
• Kritieke bedrijfstoegang + beveiligingsbehoeften (WAF/DDoS) → F5 op layer 7
• Microservice-API-gateway + deployment in de cloud → Nginx op layer 7
• Database-/Redis-belasting + hoge kostenefficiëntie → Nginx op layer 4
• Kleine en middelgrote workloads + snelle iteratie → Nginx (layer 4/7)
• Enterprise-datacenter + meerdere links → F5 aan de ingang, Nginx voor de interne servicedistributie

Die laatste combinatie komt bij grote bedrijven vaak voor — F5 bewaakt de toegang, Nginx regelt het binnenwerk.

5. Praktijkcase: hoe kronkelig F5-configureren is

De eerste reactie van velen bij een F5 is:dit is totaal een andere denkwijze dan bij een switch; je weet niet waar je moet beginnen. De configuratielogica is een compleet ander systeem.

Scenario: twee webservers met externe dienstverlening, met IP's 192.168.192.10-20/24; load balancing moet lopen via het externe adres 192.168.27.100 op poort 80.

De eenvoudigste load balancing heeft maar drie parameters nodig, die trapsgewijs op elkaar volgen:

• Node: de meest basale definitie; elke server is een node
• Pool: een groep nodes die verkeer opvangt en verwerkt, bijvoorbeeld een webservercluster
• Virtual Server: de externe ingang, gekoppeld aan de pool

Gegevensstroom: clientverzoek → Virtual Server → Pool → Node.

Stappen in de praktijk (BIG-IP-beheerinterface):

• Stap 1: activeer het apparaat. Activeer een nieuwe F5 eerst; de wizard is eenvoudig, maar onthouddat je internet nodig hebt; doe dit bij voorkeur vóór het racken— les uit eigen ervaring
• Stap 2: inloggen. Open in je browser https://<beheer-IP>; standaard is gebruikersnaam én wachtwoord admin
• Stap 3: VLAN's instellen. Network → VLANs: maak een VLAN aan en voeg de interfaces toe (kies Untagged)
• Stap 4: IP's configureren. Networks → Self IPs: definieer per VLAN een adres
• Stap 5: routering configureren. Networks → Routes: stel de standaardgateway of statische routes in
• Stap 6: de pool configureren. Local Traffic → Virtual Servers → Pools: stel de naam in, de health check (zoals TCP), het verdeelalgoritme (zoals observed-member), en de IP's en poorten van de echte servers
• Stap 7: de Virtual Server configureren. Local Traffic → Virtual Servers: koppel de pool hierboven en kies een verdelingsmethode (meestal RoundRobin)
• Stap 8: de monitor configureren. Local Traffic → Monitors: controleer de servergezondheid en koppel aan de pool
• Stap 9: redundantie configureren, voor dubbele-redundantie

6. Een paar kritieke Virtual Server-parameters

De kern van F5 is de Virtual Server; een paar parameters die je negeert veroorzaken problemen.

VS Type, drie veelvoorkomende varianten:

• Performance L4: puur layer-4-doorsturing; de TMM verdeelt alleen verbindingen en past geen TCP-parameters aan, de client-serververbinding is 1:1. Snel doorsturen, vaak gebruikt in enterprises. Om de impact op de applicatie te beperken,kies er altijd voor deze te nemen als dat kan
• Standard VS: de TCP-verbindingen tussen client en server zijn volledig onafhankelijk. Gebruik dit wanneer je layer-7-functies nodig hebt (cookiepersistentie, Session ID-persistentie, headerpersistentie, transactiegerichte splitsing van lange verbindingen, bescherming tegen SYN-aanvallen). Let op een eigenschap:de poort is altijd naar buiten open— zelfs als alle backend-nodes down zijn, is poort 80 van de VIP nog telnetbaar; alleen de pagina laadt niet. Bedenk dit bij het troubleshooten
• Forwarding IP: voor verbindingen tussen intern en extern netwerk; geen poolleden, het doorsturen hangt af van de lokale routering. Standaard heeft F5 geen routering; je moet een VS met allemaal nullen maken om die functie te activeren

Timeouts moeten op elkaar aansluiten(echte valkuil). Als er een TCP-profiel op de VS staat, worden UDP-verbindingen niet geaccepteerd. Let vooral op de Idle Timeout-waarde binnen tcp —die moet aansluiten bij de server. Zet je op de F5 150 seconden terwijl de IIS-server op 300 seconden staat, dan stapelen de fouten zich op. De tijden aan beide kanten moeten op elkaar zijn afgestemd.

Address/Port Translation: standaard beide ingeschakeld. Verschild het VS-IP van het IP van de echte machine, zet dan Address Translation aan; loopt poort 8080 van de VS op poort 80 van het echte adres uit, zet dan Port Translation aan.

SNAT AutoMap: vertrekt een verzoek via een VLAN, dan is het SNAT-bronadres de Self IP op dat VLAN. Zijn er meerdere Self IP's op het VLAN, dan worden ze om de beurt gebruikt.

7. Waarom je 'sessiepersistentie' per se moet begrijpen

Dit is het begrip in load balancing dat het makkelijkst wordt genegeerd én het vaakst voor problemen zorgt.

In systemen als e-commerce en online authenticatie doorloopt een klant meerdere interacties voordat een transactie rond is. Die interactieshangen nauw samen— bij het verwerken van de tweede stap moet de server vaak het resultaat van de eerste stap weten. Daardoor moeten al die interactiesop dezelfde server plaatsvindenen mogen ze niet door de load balancer over verschillende machines worden verdeeld.

Daarom bestaat sessiepersistentie (persistence). F5 realiseert dat via Connectivity, met keuzemodi als:

• Bronadrespersistentie: koppeling op basis van het bron-IP van de client
• Cookiepersistentie: F5 voegt automatisch een sessiecookie toe; het meest gebruikt op layer 7
• SSL Session ID-persistentie: hergebruik van SSL-sessies
• Persistentietabel: ondersteunt meerdere timeouts en matchregels

Wat gebeurt er als je het verkeerd instelt? Een klant stopt iets in de winkelwagen, ververs de pagina en het is weg — omdat het verzoek op een andere server landde. Dit soort live-incidenten is verschrikkelijk lastig te debuggen.

8. Een paar praktijkdetails die je niet kunt omzeilen

Tot slot een paar valkuilen waar anderen al in zijn getrapt, meteen met de conclusie:

• Kies het juiste niveau voor health checks: kijk je alleen naar de TCP-handshake, dan wordt verkeer nog doorgestuurd naar een server waarvan de poort leeft maar de applicatie hangt; wil je de applicatielaag checken, gebruik dan een HTTP-monitor op een endpoint als /actuator/health
• Firewalls in een 'sandwich' opstellen: één firewall haalt vaak maar 30% van de lijnsnelheid aan doorvoer; verbeteren betekent er meerdere neerzetten. Maar firewalls eisen dat data via dezelfde kant terugkomt, anders worden verbindingen geweigerd — de firewall load balancing-oplossing van F5 lost dit op en realiseert persistentie voor transparante apparaten
• SSL-offloading is de grootste CPU-besparing: laat F5 de HTTPS-handshake en encryptie/decryptie afhandelen en de backend-Java-applicatie alleen HTTP verwerken; de prestatiewinst is duidelijk merkbaar
• Doe loadtests vóór je naar productie gaat: layer 4 is snel, maar zet je sessiepersistentie aan op een layer-4-VS, dan introduceer je state en moet je de prestatieverwachtingen opnieuw doorrekenen
• Houd drie monitoringwaarden in de gaten: poolstatus, doorvoer van de virtual server, gezondheid van de nodes
• Troubleshooting-commando's: tmsh show ltm pool <pool-name> voor de poolstatus, tmsh show ltm virtual <vs-name> voor de status van de virtual server

Tot slot

Load balancing lijkt een 'doorstuurapparaat', maar staat in werkelijkheid op de meest kritieke plek van de hele architectuur — al het verkeer moet erlangs. Goed geconfigureerd, merkt niemand dat het bestaat; slecht geconfigureerd, dan belt de telefoon midden in de nacht.

In deze cloudnative tijd zijn softwareoplossingen als LVS, Nginx en HAProxy voor kleinere en middelgrote scenario's ruim voldoende, met een duidelijk kostenvoordeel. Maar bij de kerningangen van financiën, effectenhandel en grote e-commerce blijft de waarde van hardware load balancing — stabiliteit, omschakelen binnen milliseconden, beveiliging in één pakket — voorlopig onvervangbaar.

En wat de naam 'F5' betreft: het traject van bedrijfsnaam naar categorie zegt genoeg — als een product als werkwoord wordt gebruikt, heeft het die markt al gewonnen.

Layer 4 kijkt naar het verkeersbord, layer 7 pakt het pakket uit; prestaties? Layer 4. Extra functies? Layer 7.

Bronnen: officiële F5 BIG-IP LTM-documentatie, de F5 load balancing-case in 'Network Operations and Management', technische vergelijking van layer 4-/layer 7-load balancing