Минулого разу ми говорили про можливості NSX Edge у розрізі статичної та динамічної маршрутизації, а сьогодні розбиратимемося з балансувальником.
Перш ніж розпочати налаштування, я хотів би дуже коротко нагадати про основні види балансування.
Теорія
Усі сьогоднішні рішення щодо балансування корисного навантаження найчастіше ділять на дві категорії: балансування на четвертому (транспортному) та сьомому (прикладному) рівнях моделі . Модель OSI не найкраща референтна точка при описі методів балансування. Наприклад, якщо L4-балансувальник також підтримує термінування TLS, чи стає він у такому разі L7-балансувальником? Але що є, то є.
- Балансувальник L4 найчастіше являє собою middle proxy, що стоїть між клієнтом і набором доступних бекендів, який термінує TCP-з'єднання (тобто самостійно відповідає на SYN), вибирає бекенд та ініціює в його бік нову TCP-сесію, самостійно відправляючи SYN. Цей тип – один із базових, можливі й інші варіанти.
- Балансувальник L7 розподіляє трафік доступними бекендами «витонченішим», ніж це робить L4-балансувальник. Він може приймати рішення про вибір бекенда на основі, наприклад, вмісту повідомлення HTTP (URL-адреса, файл cookie і т.д.).
Незалежно від типу балансувальник може підтримувати такі функції:
- Виявлення сервісів – процес визначення набору доступних бекендів (Static, DNS, Consul, Etcd тощо).
- Перевіряє працездатність виявлених бекендів (активний «пінг» бекенду за допомогою HTTP-запиту, пасивне виявлення проблем у TCP-з'єднаннях, наявність у відповідях кількох поспіль 503 HTTP-code і т.д.).
- Сама балансування (round robin, random selection, source IP hash, URI).
- Термінування TLS та верифікація сертифікатів.
- Опції, пов'язані із забезпеченням безпеки (автентифікація, запобігання DoS-атакам, обмеження швидкості) та багато іншого.
NSX Edge пропонує підтримку двох режимів розгортання балансувальника:
Режим проксі, або one-arm. У цьому режимі NSX Edge під час надсилання запиту на один з бекендів використовує свою IP-адресу як адресу джерела. Таким чином, балансувальник виконує одночасно функції Source та Destination NAT. Бекенд бачить весь трафік як відправлений з балансувальника та відповідає йому безпосередньо. У такій схемі балансувальник має бути в одному мережевому сегменті із внутрішніми серверами.
Ось як це відбувається:
1. Користувач надсилає запит на VIP-адресу (адресу балансувальника), яка налаштована на Edge.
2. Edge вибирає один з бекендів і виконує destination NAT, замінюючи VIP-адресу на адресу вибраного бекенда.
3. Edge виконує source NAT, замінюючи адресу відправив запит користувача на власний.
4. Пакет відправляється до обраного бекенд.
5. Бекенд відповідає не безпосередньо користувачеві, а Edge, оскільки початкова адреса користувача була змінена на адресу балансувальника.
6. Edge передає відповідь сервера користувачеві.
Схема нижче.
Прозорий, або inline, режим. У цьому сценарії балансувальник має інтерфейси у внутрішній та зовнішній мережі. При цьому до внутрішньої мережі немає прямого доступу із зовнішньої. Вбудований балансувальник навантаження діє як шлюз NAT для віртуальних машин у внутрішній мережі.
Механізм наступний:
1. Користувач надсилає запит на VIP-адресу (адресу балансувальника), яка налаштована на Edge.
2. Edge вибирає один з бекендів і виконує destination NAT, замінюючи VIP-адресу на адресу вибраного бекенда.
3. Пакет відправляється до обраного бекенд.
4. Бекенд отримує запит із початковою адресою користувача (source NAT не виконувався) та відповідає йому безпосередньо.
5. Трафік знову приймається балансувальником навантаження, так як у inline схемі він зазвичай виступає як шлюз за замовчуванням для ферми серверів.
6. Edge виконує source NAT для відправки трафіку користувачу, використовуючи свій VIP як source IP-адресу.
Схема нижче.
Практика
На моєму тестовому стенді налаштовані 3 сервери з Apache, який налаштований для роботи з HTTPS. Edge виконуватиме балансування HTTPS-запитів за методом round robin, проксіруючи кожен новий запит на новий сервер.
Приступимо.
Генеруємо SSL-сертифікат, який використовуватиме NSX Edge
Ви можете імпортувати валідний сертифікат CA або використовувати самопідписаний. У цьому тесті я скористаюся самопідписаним.
- В інтерфейсі vCloud Director переходимо до налаштувань сервісів Edge.
- Переходимо до вкладки Certificates. Зі списку дій вибираємо додавання нового CSR.
- Заповнюємо необхідні поля та натискаємо Keep.
- Виділяємо щойно створений CSR та вибираємо опцію self-sign CSR.
- Вибираємо термін валідності сертифікату та натискаємо Keep
- Самопідписаний сертифікат з'явився у списку доступних.
Налаштовуємо Application Profile
Application profiles дають повніший контроль над мережевим трафіком і роблять управління ним простим і ефективним. З їхньою допомогою можна визначати поведінку для конкретних типів трафіку.
- Переходимо у вкладку Load Balancer і вмикаємо балансувальник. Опція Acceleration enabled тут дозволяє балансувальнику використовувати більш швидке балансування L4 замість L7.
- Перейдіть у вкладку Application profile, щоб встановити профіль програми. Натисніть +.
- Задаємо назву профілю та вибираємо тип трафіку, для якого профіль буде застосований. Поясню деякі параметри.
Наполегливість – зберігає та відстежує дані сеансу, наприклад: який конкретний сервер з пулу обслуговує запит користувача. Це дозволяє гарантувати, що запити користувача надсилаються одному і тому ж члену пулу протягом усього життя сеансу або наступних сеансів.
Enable SSL passthrough - при виборі цієї опції NSX Edge перестає термінувати SSL. Натомість термінація відбувається безпосередньо на серверах, для яких виконується балансування.
Insert X-Forwarded-For HTTP header – дозволяє визначати вихідну IP-адресу клієнта, що підключається до веб-сервера через балансувальник.
Enable Pool Side SSL – дозволяє вказати, що вибраний пул складається з серверів HTTPS.
- Так як я балансуватиму HTTPS-трафік, потрібно включити Pool Side SSL і вибрати згенерований раніше сертифікат у вкладці Virtual Server Certificates -> Service Certificate.
- Аналогічно для Pool Certificates -> Service Certificate.
Створюємо пул серверів, трафік до яких балансуватиметься Pools
- Переходимо у вкладку Pools. Натискаємо +.
- Задаємо ім'я пула, вибираємо алгоритм (я використовуватиму round robin) і тип моніторингу для health check бекенда. Опція Transparent вказує, чи видно початкові source IP клієнтів внутрішнім серверам.
- Якщо опцію вимкнено, трафік для внутрішніх серверів йде з source IP балансувальника.
- Якщо опція увімкнена, внутрішні сервери бачать source IP клієнтів. У такій конфігурації NSX Edge повинен виступати як шлюз за замовчуванням, щоб гарантувати, що пакети, що повертаються, проходять через NSX Edge.
NSX підтримує такі алгоритми балансування:
- IP_HASH – вибір сервера на основі результатів виконання хеш-функції для source та destination IP кожного пакета.
- LEASTCONN – балансування вхідних з'єднань, залежно від кількості наявних на конкретному сервері. Нові з'єднання будуть направлені на сервер із найменшою кількістю з'єднань.
- КРУГОВОЇ – нові з'єднання відправляються на кожен сервер по черзі, відповідно до заданої вагою.
- URI - ліва частина URI (до знаку питання) хешується і ділиться на загальну вагу серверів в пулі. Результат вказує, який сервер отримує запит, гарантуючи, що запит завжди надсилається на той самий сервер, доки всі сервери залишаються доступними.
- HTTPHEADER – балансування на основі певного заголовка HTTP, який можна вказати як параметр. Якщо заголовок відсутній або не має значення, застосовується алгоритм ROUND_ROBIN.
- URL – у кожному запиті HTTP GET виконується пошук за параметром URL, вказаним як аргумент. Якщо за параметром слід знак рівності та значення, то значення хешується і поділяється на загальну вагу запущених серверів. Результат показує, який сервер отримує запит. Цей процес використовується для відстеження ідентифікаторів користувачів у запитах і забезпечення того, щоб один і той же user id завжди відправлявся на той самий сервер, доки всі сервери залишаються доступними.
- У блоці Members натискаємо +, щоб додати сервер до пул.
Тут слід зазначити:- ім'я сервера;
- IP-адреса сервера;
- порт, на який сервер отримуватиме трафік;
- порт для health check (Monitor healthcheck);
- вага (Weight) – за допомогою цього параметра можна регулювати пропорційну кількість трафіку для конкретного члена пулу;
- Max Connections – максимальна кількість з'єднань до сервера;
- Min Connections – мінімальна кількість з'єднань, яку має обробити сервер, перш ніж трафік буде перенаправлено наступному члену пулу.
Ось так виглядає підсумковий пул із трьох серверів.
Додаємо Virtual Server
- Переходимо до вкладки Virtual Servers. Натискаємо +.
- Активуємо віртуальний сервер за допомогою Enable Virtual Server.
Задаємо йому ім'я, вибираємо створені раніше Application Profile, Pool і вказуємо IP-адресу, на яку Virtual Server прийматиме запити ззовні. Вказуємо протокол HTTPS та порт 443.
Опціональні параметри тут:
Ліміт підключення - максимальна кількість одночасних з'єднань, які може обробити віртуальний сервер;
Connection Rate Limit (CPS) – максимальна кількість нових запитів в секунду.
На цьому конфігурацію балансувальника завершено, можна перевірити його працездатність. Сервера мають найпростішу конфігурацію, що дозволяє зрозуміти, яким саме сервером з пулу було опрацьовано запит. Під час налаштування ми вибрали алгоритм балансування Round Robin, а параметр Weight для кожного сервера дорівнює одиниці, тому кожен наступний запит оброблятиметься наступним сервером з пулу.
Вводимо у браузері зовнішню адресу балансувальника та бачимо:
Після оновлення сторінки запит буде опрацьовано наступним сервером:
І ще раз – щоб перевірити і третій сервер із пулу:
При перевірці можна бачити, що сертифікат, який надсилає нам Edge, той самий, що ми генерували на початку.
Перевірка статусу балансувальника з консолі Edge Gateway. Для цього введіть show service loadbalancer pool.
Налаштовуємо Service Monitor для перевірки стану серверів у пулі
За допомогою Service Monitor ми можемо відстежувати стан серверів у бекенд-пулі. Якщо відповідь на запит не відповідає очікуваному, сервер можна вивести з пула, щоб він не отримував нових запитів.
За замовчуванням налаштовано три методи перевірки:
- TCP-monitor,
- HTTP-monitor,
- HTTPS monitor.
Створимо новий.
- Переходимо у вкладку Service Monitoring, натискаємо +.
- Вибираємо:
- ім'я нового методу;
- інтервал, з яким надсилатимуться запити,
- тайм-аут очікування відповіді,
- тип моніторингу – HTTPS request з використанням методу GET, очікуваний status code – 200(OK) та URL-адреса запиту.
- На цьому налаштування нового Service Monitor закінчено, тепер ми можемо використовувати його під час створення пулу.
Налаштовуємо Application Rules
Application Rules – спосіб маніпулювання трафіком, що базується на певних тригерах. За допомогою цього інструменту ми можемо створювати розширені правила балансування навантаження, налаштування яких може бути неможливим через Application profiles або за допомогою інших сервісів, доступних на Edge Gateway.
- Для створення правила переходимо у вкладку Application Rules балансувальника.
- Вибираємо ім'я, скрипт, який використовуватиме правило, і натискаємо Keep.
- Після того, як правило, створено, нам потрібно відредагувати вже налаштований Virtual Server.
- У вкладці Advanced додаємо створене нами правило.
У цьому прикладі ми включили підтримку tlsv1.
Ще кілька прикладів:
Редирект трафіку в інший пул.
За допомогою цього скрипта ми можемо перенаправити трафік в інший пул балансування, якщо основний пул не працює. Щоб правило спрацювало, на балансувальнику має бути налаштовано кілька пулів і всі члени основного пулу мають бути в змозі вниз. Вказувати потрібно саме ім'я пула, а чи не його ID.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Редирект трафіку на зовнішній ресурс.
Тут ми перенаправляємо трафік на зовнішній веб-сайт, якщо всі учасники основного пулу здатні вниз.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Ще більше прикладів .
На цьому про балансувальник у мене все. Якщо залишилися питання, запитуйте, чи я готовий відповісти.
Джерело: habr.com