У мінулы раз мы казалі аб магчымасцях 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 Limit - Максімальную колькасць адначасовых злучэнняў, якія можа апрацаваць віртуальны сервер;
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.
Яшчэ пара прыкладаў:
Рэдырэкт трафіку ў іншы пул.
З дапамогай гэтага скрыпту мы можам перанакіраваць трафік у іншы пул балансавання, калі асноўны пул не працуе. Каб правіла спрацавала, на балансавальнік павінна быць сканфігуравана некалькі пулаў і ўсе члены асноўнага пула павінны быць у стане down. Указваць трэба менавіта імя пула, а не яго ID.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Рэдырэкт трафіку на знешні рэсурс.
Тут мы перанакіроўваем трафік на знешні вэб-сайт, калі ўсе ўдзельнікі асноўнага пула ў стане down.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Яшчэ больш прыкладаў .
На гэтым пра балансавальнік у мяне ўсё. Калі засталіся пытанні, пытайцеся, я гатовы адказаць.
Крыніца: habr.com