В тази статия ще ви запознаем с Load Balancer и видовете разпределения на натоварването.

Load Balancer в буквален превод означава разпределител на натоварването. Най-често се използват два вида разпределения – на ниво TCP/IP (Layer 4 от OSI модела) и на ниво приложение (Layer 7 от OSI модела). Балансиране на натоварването се налага, когато в развитието на даден уеб сайт се достига до момент, в който един сървър не е достатъчен за натоварването, което генерира самият сайт. Тогава даденият уеб сайт се разполага на поне два сървъра, като натоварването се разпределя между тях.

1. Round Robin

Най-простият вид Load Balancer е задаването на два или повече A записа за домейн. По този начин може сайтът Ви да се зарежда от два различни сървъра, като ролята на Load Balancer играе DNS сървъра. Този тип разпределяне на натоварването се нарича Round Robin.

Как да създадем Round Robin Load balancer:

Всеки един домейн има основен A запис (преобразувател domain.com -> IP адрес) от тип:

domain.com <TTL (време за кеширане на информацията) в секунди> A <IP адрес>

Примерен запис:

icn.bg.    120    IN    A    91.215.218.14

За да създадем Round Robin Load balancer, ни трябва втори сървър съдържащ същото съдържание като на основния, но с друго публично IP. Пример: 91.215.218.15. След което създаваме втори A запис, за домейна, но с другия IP адрес.

Пример:

icn.bg.    120    IN    A    91.215.218.15

По този начин за домейна ще отговаря не едно IP, както при повечето сайтове, а два или повече. Съответно при проверка за DNS записите, ще ни излиза следния резултат:

icn.bg.    120    IN    A    91.215.218.14
icn.bg.    120    IN    A    91.215.218.15

Това е напълно достатъчно, за да имаме елементарно разпределяне на натоварването между два или повече сървъра.

Кога се използва най-често?

- Когато не искаме да влагаме допълнително пари в хардуер;
- Когато нямаме знанията да настроим хардуерен Load Balancer;
- Когато трафикът е изключително натоварен и се налага, както хардуерен Load Balancer, така и DNS балансиране на натоварването.

Пример за този принцип ще дадем с ebay.com: 

В Linux терминал изпълняваме командата dig (или nslookup в Command prompt при Windows). Получаваме следната информация:

dig ebay.com
ebay.com.        3231    IN    A    66.135.216.190
ebay.com.        3231    IN    A    66.211.160.86
ebay.com.        3231    IN    A    66.211.160.87

Какво разбираме от горните редове? Разбираме, че при първо зареждане ще отворим ebay.com от сървър с IP адрес примерно 66.135.216.190. След близо 60 минути (цифрата 3231, показва времето в секунди, за което ще се кешира информацията за това, че ebay.com има адрес 66.135.216.190) при презареждане, сайтът вече ще ни се отвори от сървър с IP адрес 66.211.160.86. Така всеки посетител посещава сайта от различен сървър и това намалява натоварването на всеки един от тях.

Защо този принцип се използва рядко и не винаги е приложим?

Това е така поради няколко причини:

- Нямаме свободата да изберем на кой, кога и от кой сървър да му се зареди уеб сайтът. Това означава, че в случая на ebay.com, натоварването не е разпределено 33.33% на всеки от сървърите. Може един сървър да е много по-натоварен от останалите.

- Ако единият сървър спре работа поради някаква причина, ние не можем да спрем трафика към него. Това се дължи на времето за кеширане. В случая, ако сървър с IP адрес 66.135.216.190 откаже, то сайта няма да ни се зарежда в рамките на 60 минути, докато информацията се опресни, независимо че сайтът работи на други сървъри. На картинката по-долу е показан принцип Round Robin. Показани са два сървъра Web Server 1 и Web Server 2 с разпределено натоварване посредством два A записа в DNS сървъра. Когато Web Server 1 не работи, то на клиенти Client 1 и Client 2 сайтът не се отваря, тъй като те се опитват да се свържат именно с него. Сайтът се отваря на Client 3, тъй като той зарежда сайта от Web Server 2, който е работещ. Както става ясно от показания пример, Round Robin не е много удачен за важни сайтове, тъй като при спиране на работата на сървър, то това довежда до загуба на трафик и потенциални клиенти, които не успяват да заредят самия уеб сайт. Ние нямаме свободата да пренасочим трафика към друг работещ сървър, тъй като в компютъра на клиента е кеширана информацията за IP адреса на неработещия сървър.





- Ако сайта ни се обновява, то трябва да обновяваме информация на всеки един от сървърите.

Всички тези минуси довеждат до нуждата от различен тип Load Balancer. Или иначе казано: създаването на хардуерен клъстър.

2. Хардуерен клъстър

Най-общо казано хардуерният клъстър представлява свързани помежду си минимум три сървъра - Load Balancer, който разпределя натоварването между 2 или повече Node-а. Под Node, разбираме сървър, който изпълнява идентични функции с друг сървър в цялостната клъстърна инфраструктура. На картинката е визуализиран Load Balancer (Server) свързан посредством суич (10/100 Mb/s Ethernet Switch) с 5 node сървъра с общ мрежови дисков масив (Networked Disk Storage). От показания пример става ясно, че при спиране на работата на един от Node сървърите, ние можем да го изключим от списъка автоматично посредством правило в Load Balancer-а (Server), като тази промяна ще се отрази мигновено и няма да бъде загубен трафик и съответно клиенти, тъй като няма да има потребител, който да не може да зареди сайта.

Какви са предимствата на този тип Load Balancing?

1. Самия Load Balancer сървър не изпитва почти никакво натоварване. Това се дължи на факта, че той не обработва информация, а само пренасочва заявки към сървърите зад него.
2. Възможност за добавяне на безброй Node машини.
3. Възможност за решаване кой посетител към кой Node да бъде препратен. Натоварването може да бъде разпределено на Round Robin принцип (всеки посетител на случаен принцип), принцип 50/50 за еднакво разпределяне на натоварването или задаване на приоритетни сървъри с по-добри хардуерни възможности.
4. Сървърите могат да бъдат обединени с единна файлова система, което позволява по-лесно администриране на сайтовете, разположени на тях.
5. Възможност за Failover – ако даден сървър от системата спре работа, то той може да бъде изключен от списъка без това да нарушава работата на сайтовете в мрежата.