Балансирането на натоварване (Load Balance) подробно: наричано още F5, с представяне на реални случаи
В работата по експлоатация и сигурност почти не можеш да заобиколиш един термин — балансиране на натоварване. А щом се спомене, първото устройство, което изскача в главата на мнозина, е „F5“. Интересното е, че F5 всъщност е име на компания (F5 Networks), но продуктите ѝ са толкова известни, че постепенно думата стана синоним на балансьор — както „тицни в Baidu“ се превърна в синоним на търсене.

Тук ще го разгледаме до дъно: какво всъщност е F5, какво различава четвъртия от седмия слой и как се конфигурира в реални сценарии.
Първо: какъв проблем решава балансирането на натоварване
Балансирането на натоварване (Load Balance) по същество е разпределянето на работните задачи между множество оперативни единици — например уеб сървъри, FTP сървъри, критични за фирмата приложения — така че заедно да свършат работата.
От техническа гледна точка навън то се представя катоадрес на виртуален сървър. Когато потребител се свърже, чрез двупосочен network address translation (NAT) пренасочва връзката към най-подходящия реален сървър. Потребителят винаги вижда един и същ вход, а отзад товарът държи група машини.
То решава три неща:страх от падане(единична точка на отказ), страх от свръхнатоварване(производителностно тясно място), страх, че не можеш да разширяваш(липса на хоризонтално мащабиране).
Второ: четвърти срещу седми слой — най-лесно объркваното място
Ядрото на разликата се събира в едно изречение:да се анализира ли протоколът от приложния слой. Тази разлика директно определя границите на възможностите и производителността.
Балансиране на четвърти слой (транспортен слой)
- Работно ниво: 4-ти слой на OSI, протоколи TCP/UDP
- Основа за препращане: изходен IP, целеви IP, порт — не пипа данните от приложението
- Ключови възможности: препращане на портове, мултиплексиране на TCP връзки, проверка на здравето на четвърти слой (TCP ръкостискане), базова DDoS защита
- Производителност: изключително висока ефективност на препращане, близо до хардуерната граница, закъснение от микросекунди
- Типични сценарии: бази данни (MySQL/Redis), TCP услуги (игрови сървъри, Netty услуги), балансиране на връзки между центрове за данни
- Представителни продукти: LVS, F5 (режим четвърти слой), HAProxy (режим четвърти слой), Nginx (модул stream)
Балансиране на седми слой (приложен слой)
- Работно ниво: 7-ми слой на OSI, приложни протоколи като HTTP/HTTPS, DNS, FTP
- Основа за препращане: URL, Cookie, HTTP заглавки, параметри на заявката, JSON съдържание
- Ключови възможности: маршрутизация по съдържание, SSL offload, кеширане, ограничение на скоростта и прекъсване (circuit breaking), интеграция с WAF, задържане на сесии, канарично публикуване
- Производителност: богати функции, но трябва да анализира приложните протоколи — малко по-високо закъснение (милисекунди), компенсира се с мащабиране на клъстера
- Типични сценарии: уеб приложения, микросервизни API, HTTPS услуги, канарично публикуване, API шлюзове
- Представителни продукти: Nginx, HAProxy (режим седми слой), F5 (модул за седми слой), Kong, Spring Cloud Gateway
Запомняне с едно изречение: четвъртият слой препраща само по „пътната табела“ (IP и порт), седмият разопакова „пратката“ (гледа съдържанието) и чак тогава решава къде да я изпрати. За производителност — четвърти; за изтънчени трикове — седми.
Трето: къде всъщност е силата на F5 BIG-IP
Основният продукт на F5 — BIG-IP LTM — официално се наричамениджър на локалния трафик и прави балансиране на слоеве 4–7. Той не е само препращач — списъкът с функции е дълъг: обмяна на приложения, обмяна на сесии, мониторинг на състоянието, интелигентен NAT, универсална персистентност, обработка на грешки в отговорите, IPv6 шлюз, разширена маршрутизация, SSL ускорение, интелигентна HTTP компресия, TCP оптимизация, буфериране на съдържание, шифроване на бисквитки, филтриране на атаки срещу приложения, защита от DoS и SYN Flood, пакетно филтриране като защитна стена…
Да вземем най-полезните:
1. Балансиране и резервиране на множество връзки
Критичният бизнес често ползва линии от няколко ISP, за да гарантира качество и да премахне единичните точки на отказ. Тук има две посоки:
- OUTBOUND трафик(вътрешната мрежа достъпва външната): BIG-IP LC интелигентно разпределя трафика към различни интернет интерфейси и прави NAT на изходния адрес
- INBOUND трафик(външната достъпва вътрешната): свързват се публичните адреси на двата ISP, отговаря се на DNS заявките и на двата ISP с интелигентни отговори според здравето на сървърите и RTT времето
2. Балансиране на сървърно натоварване
Чрез VIP (виртуален IP, съставен от IP адрес и TCP/UDP порт) обслужва външния свят и непрекъснато прави проверки на здравето от L4 до L7 на целевите сървъри. Щом открие повреден сървър, го изважда от групата за балансиране. Може и с iRules да отваря TCP/UDP пакетите и да прилага правила по признаци на съдържанието — например да насочва трафика към различни сървъри по URL.
3. Висока наличност на системата
Това е мястото, където F5 най-много се хвали. При двоен резервиран режимпревключването е от порядъка на милисекунди(най-бързо до 200 ms) и се декларират 99,999% наличност. Принципът: докато всички сесии минават през Active устройството, информацията за сесиите се синхронизира към Backup устройството по синхронизиращата линия — затова при превключване достъпът на потребителите не прекъсва. Watchdog чипът в устройството следи електрическото ниво на другия по сърдечната линия и при падане на Active веднага уведомява Backup да поеме Shared IP и VIP.
4. Сигурност
BIG-IP следва принципите на проектиране на защитни стени —забрана по подразбиране. Може да прекъсва неактивни връзки срещу DoS, да изпълнява проследяване на source routing срещу IP измами и да отхвърля SYN без ACK срещу SYN атаки. Функцията Dynamic Reaping ефективно премахва неактивните връзки при DoS атака, катоускорява темпа на прекъсване на връзките с нарастването на атаката — доста сурово. Технологията Delay Binding пък дава пълна SYN Flood защита на сървърите зад него.
5. SSL ускорение
Всеки BIG-IP има хардуерен чип за SSL ускорение и лиценз за 100 TPS в комплекта, без отделно плащане. По-късно, при разширение, стига ъпгрейд на лиценза.

Четвърто: F5 или Nginx? Сравнение при избора
Това е най-често задаваният въпрос в реалната работа. Двете не са конкуренти, а по-скоро се допълват.
F5 BIG-IP (хардуер)
- Форма на разполагане: специализиран хардуер (с персонализирани чипове)
- Производителност: милиони TCP връзки, закъснение при препращане в микросекунди
- Функции: универсален — четвърти+седми слой, SSL offload, DDoS защита, WAF, VPN, балансиране на линии
- Надеждност: хардуерна резервираност (горещ резерв на две машини), 99,999% наличност
- Цена: висока (стотици хиляди до милиони), нуждае се от специализирани инженери за поддръжка
- Мащабируемост: зависи от хардуерни ъпгрейди, ниска гъвкавост
- Експлоатация: сложна, изисква запознатост със собствения конфигурационен интерфейс и CLI
Nginx (софтуер)
- Форма на разполагане: софтуер на универсални сървъри или облачни хостове
- Производителност: стотици хиляди TCP връзки, закъснение в милисекунди, мащабиране с клъстер
- Функции: лек и ефективен — ядрото е седми слой, поддържа четвърти слой, SSL offload, кеширане, ограничение на скоростта, reverse proxy
- Надеждност: ръчна настройка на горещ резерв (Keepalived), зависи от стабилността на сървърния хардуер
- Цена: безплатен с отворен код, а Nginx Plus е също относително евтин
- Мащабируемост: поддържа клъстерно разполагане, в облачна среда — еластично разширение
- Експлоатация: проста, конфигурационният файл е лесен за четене, backend инженерите бързо се справят
Кръстовище при избора — вървете по него:
- TCP услуги с висока едновременност (игри, ценни книжа) + максимална наличност → F5 на четвърти слой
- вход на ключовия бизнес + изисквания за сигурност (WAF/DDoS) → F5 на седми слой
- микросервизен API шлюз + разполагане в облак → Nginx на седми слой
- натоварване от база данни/Redis + висока рентабилност → Nginx на четвърти слой
- бизнес с малък и среден мащаб + бързи итерации → Nginx (четвърти/седми слой)
- корпоративен център за данни + множество линии → F5 на входа, Nginx за вътрешното балансиране на услугите
Последната комбинация е много честа в големите компании — F5 пази границата, Nginx стопанисва вътрешността.
Пето: реален случай — колко заплетена е конфигурацията на F5
Първата реакция на мнозина, взели F5 в ръце, е:логиката е съвсем различна от тази при суичовете — не знаеш откъде да хванеш. Конфигурационната му логика е друга система.
Сценарий: два уеб сървъра обслужват външния свят с IP 192.168.192.10-20/24; изискването е балансиране през външния адрес 192.168.27.100 на порт 80.
Най-простото балансиране се нуждае само от три параметъра, а връзката между тях е пластова:
- Node (възел): най-елементарната дефиниция — всеки сървър е един Node
- Pool (пул от ресурси): група Node-ове, които приемат и обработват трафика — например клъстер уеб сървъри
- Virtual Server (виртуален сървър): външният вход, свързан с Pool
Посока на данните: заявка от клиента → Virtual Server → Pool → Node.
Практически стъпки (административният интерфейс на BIG-IP):
- Стъпка едно: активирайте устройството. Вземайки F5, първо го активирайте — съветникът е прост, но запомнетенепременно трябва да има интернет, най-добре още преди поставянето му в шкафа — опит, придобит по трудния начин
- Стъпка две: влезте. Отворете в браузъра https://управленския-IP; потребителско име и парола по подразбиране са admin
- Стъпка три: създайте VLAN. Network → VLANs — създайте VLAN и добавете интерфейсите (изберете Untagged)
- Стъпка четири: настройте IP. Networks → Self IPs — задайте адрес за всеки VLAN
- Стъпка пет: настройте маршрутизация. Networks → Routes — задайте подразбиращ се шлюз или статични маршрути
- Стъпка шест: настройте Pool. Local Traffic → Virtual Servers → Pools — задайте име, проверка на здравето (например TCP), алгоритъм за балансиране (например метода на наблюдение observed-member), реални IP адреси на сървърите и портове
- Стъпка седем: настройте Virtual Server. Local Traffic → Virtual Servers — свържете горния Pool и изберете метод на разпределение (често RoundRobin)
- Стъпка осем: настройте Monitor. Local Traffic → Monitors — проверявайте здравето на сървърите и свържете с Pool
- Стъпка девет: настройте Redundant, за двоен резерв
Шесто: няколко ключови параметъра на Virtual Server
Ядрото на F5 е Virtual Server, а няколко параметъра, оставени без внимание, ще създадат проблеми.
VS Type (тип), най-често три вида:
- Performance L4: чисто препращане на четвърти слой; TMM се грижи само за разпределението на връзките, не променя TCP параметрите, а връзката клиент–сървър е 1:1. Скоростта на препращане е висока и в корпоративната среда се ползва често. За да намалите въздействието върху приложението,избирайте този, когато може
- Standard VS: TCP връзката клиент–сървър е изцяло независима. Ползва се, когато трябват функции на седми слой (персистентност по Cookie, по Session ID, по Header, разделяне на дълги връзки базирано на транзакции, защита от SYN атаки). Внимавайте с една особеност:портът му е винаги отворен навън — дори всички задни Node-ове да са паднали, порт 80 на VIP-а пак се отваря по telnet, само страницата не се зарежда. Помнете това при отстраняване на неизправности
- Forwarding IP: за връзки между вътрешната и външната мрежа; няма Pool Member, а препращането зависи от локалната маршрутизация. По подразбиране F5 няма маршрутизационна функция — трябва да се създаде VS с нулев адрес (всички 0), за да се включи маршрутизирането
Timeout трябва да е съгласуван(това е истински яд). Ако на VS е зададен TCP Profile, UDP връзки няма да бъдат приемани. Още по-важно е стойността Idle Timeout в tcp —трябва да съответства на сървъра. Ако на F5 е 150 секунди, а на IIS сървъра 300 секунди, ще се появят множество грешки. Времената от двете страни трябва да са договорени.
Address/Port Translation: и двете са enabled по подразбиране. Когато IP на VS се различава от реалния IP на машината, включете Address Translation; когато порт 8080 на VS отговаря на порт 80 на реалния адрес, включете Port Translation.
SNAT AutoMap: през кой VLAN излиза заявката, такъв Self IP на този VLAN е SNAT изходният адрес. Ако на VLAN има няколко Self IP, те се ползват по кръгов принцип.
Седмо: защо задължително трябва да разбираш „задържането на сесиите“
Това е концепцията в балансирането, която най-лесно се пренебрегва и най-лесно създава проблеми.
В системи като е-търговия и онлайн автентикация клиентът преминава през множество взаимодействия, за да завърши една транзакция. Тези взаимодействия сатясно свързани — при обработката на втората стъпка сървърът често трябва да знае резултата от първата. Това изисква всички тези взаимодействия да сазадължително извършени от един и същ сървър, а не да са разпилени от балансьора по различни машини.
В това е смисълът на съществуването на персистентността (Persistence). F5 я реализира чрез Connectivity; възможните режими включват:
- Персистентност по изходен адрес: обвързване по изходния IP на клиента
- Cookie персистентност: F5 автоматично вмъква сесиен cookie, най-често на седми слой
- Персистентност по SSL Session ID: повторно ползване на SSL сесията
- Таблица на персистентността: поддържа различни таймаути и правила за съвпадение
Какво става при грешна настройка? Потребителят слага артикул в количката, освежи страницата — и нещата са изчезнали, защото заявката е отишла на друг сървър. Такива проблеми в реално време се отстраняват с изключителни усилия.
Осмо: няколко неизбежни практически детайла
Накрая — няколко яда, на които други са се натъкнали, направо с изводите:
- Проверката на здравето трябва да е на правилния слой: ако гледате само TCP ръкостискането, портът на сървъра е жив, но приложението е паднало — трафикът пак ще се препраща; за проверка на приложния слой ползвайте HTTP тип Monitor с интерфейси като /actuator/health
- Защитната стена трябва да е „сандвич“: една защитна стена често постига едва 30% от линейната скорост на пропускливост; за повече трябва да се слагат няколко. Но защитната стена изисква данните да влизат и излизат през едно и също устройство, иначе връзката се отхвърля — решението на F5 за балансиране на защитни стени решава този проблем, осигурявайки персистентност към прозрачните устройства
- SSL offload е най-големият спестител на CPU: оставете F5 да се занимава с HTTPS ръкостискането и шифроването/дешифроването, а Java приложенията зад него да обработват само HTTP — подобрението на производителността е осезаемо
- Преди да свържете продукционна среда, направете товарен тест: четвъртият слой е бърз, но ако сте включили персистентност на четвъртослойния VS, сте внесли състояние — очакванията за производителност трябва да се пресметнат наново
- Следете три метрики: състояние на пула, пропускателна способност на виртуалния сървър, здраве на възлите
- Команди за отстраняване на неизправности: tmsh show ltm pool <pool-name> за състоянието на пула, tmsh show ltm virtual <vs-name> за състоянието на виртуалния сървър

В заключение
Балансирането изглежда като „устройство за препращане“, но всъщност стои на най-критичното място в цялата архитектура — целият трафик минава през неговите ръце. Настроено добре, потребителите не усещат съществуването му; настроено зле — телефонът звъни полунощ при вас.
Сега, при вълната на cloud-native, софтуерните решения като LVS, Nginx и HAProxy напълно стигат за малки и средни сценарии с очевидно ценово предимство. Но когато става дума за входа на ключови системи във финанси, ценни книжа и голяма е-търговия, стойността на хардуерното балансиране — в стабилност, превключване в милисекунди и цялостна сигурност — все още не може да бъде заместена в краткосрочен план.
Що се отнася до името „F5“, самият му път от компания до категория говори сам за себе си — щом един продукт започне да се ползва като глагол, той вече е спечелил този пазар.
Четвърти слой гледа табелата, седми разопакова пратката; за производителност — четвърти, за трикове — седми.
Източници: официални материали за F5 BIG-IP LTM, случай на F5 балансиране от „Network Operations and Management“, техническо сравнение на балансиране на четвърти/седми слой