Балансирането на натоварването на базата данни или обратното прокси сървър на базата данни разпределя входящото работно натоварване на базата данни между множество сървъри на база данни, работещи зад него. Целите на балансирането на натоварването на базата данни са да предоставят единна крайна точка на базата данни на приложенията, към които да се свързват, да увеличат пропускателната способност на заявките, да минимизират забавянето и да увеличат максимално използването на ресурсите на сървърите на базата данни.
Може да има два начина за топология за балансиране на натоварването на базата данни:
- Централизирана топология
- Разпределена топология
В тази публикация в блога ще покрием и двете топологии и ще разберем някои плюсове и минуси на всяка настройка. Също така, дали е възможно да се смесват двете топологии заедно?
Централизирана топология
При централизирана настройка обратно прокси се намира между нивото на данни и представяне, както е представено от следната диаграма:
За да елиминирате единична точка на повреда, трябва да зададете до два или повече възли за балансиране на натоварването за целите на резервирането. Ако вашето приложение може да обработва множество крайни точки на база данни, например приложението или драйверът на базата данни е в състояние да извършва проверки на състоянието, ако балансиращото натоварване е изправно за обработка на заявки, вероятно можете да пропуснете частта за виртуален IP адрес. В противен случай и двата възела за балансиране на натоварването трябва да бъдат свързани заедно с общо име на хост или виртуален IP адрес, за да се осигури прозрачност на клиентите на базата данни, където просто трябва да използва единична крайна точка на базата данни за достъп до нивото на данни. Използването на DNS или съпоставяне на хост също е възможно, ако искате да пропуснете използването на виртуални IP адреси.
Този базиран на нива подход е много по-лесен за управление поради независимото статично разположение на хоста. Малко вероятно е нивото на балансиране на натоварването да бъде мащабирано (добавяне на повече възли) поради стабилната му основа за устойчивост, излишък и прозрачност към нивото на приложение. Вероятно трябва да увеличите мащаба на хоста (да добавите повече ресурси към хоста), което обикновено ще се случи много далече в бъдеще, след като работните натоварвания на балансира на натоварване са станали по-взискателни с разрастването на вашия бизнес.
Тази топология изисква допълнително ниво и хостове, което може да бъде скъпо в гола метална инфраструктура с физически сървъри. Тази настройка е по-лесна за управление в облачна или виртуална среда, където имате гъвкавостта да добавите допълнително ниво между нивото на приложението и базата данни, без да ви струва твърде много разходите за физическа инфраструктура, като електричество, пространство в стелаж и разходи за мрежа.
Разпределена топология
При настройка на разпределена топология балансьорите на натоварване са разположени съвместно в рамките на нивото на презентация (приложение или уеб сървъри), както е опростено от следната диаграма:
Приложенията третират балансиращото натоварване на базата данни подобно на локален сървър на база данни, където балансирането на натоварването се превръща в представяне на отдалечените бази данни от гледна точка на приложението. Обикновено балансьорът на натоварване ще слуша интерфейса на локалната мрежа като 127.0.0.1 или „localhost“, което ще рационализира хоста на базата данни за крайната точка на базата данни за приложенията.
Едно от предимствата на работата в тази топология е, че не се нуждаете от допълнителни хостове за целите на балансиране на натоварването. Чрез комбиниране на нивото на балансиране на натоварването в рамките на нивото на презентация, бихме могли да спестим поне два хоста. В среда без метал, тази топология може потенциално да ви спести много пари през годините. Като цяло работното натоварване за балансиране на натоварването е далеч по-малко взискателно в сравнение с натоварванията на база данни или приложения, което прави оправдано споделянето на същите хардуерни ресурси с приложенията.
Когато се намира съвместно със сървъра на приложения, вие приближавате обратния прокси до приложението и елиминирате единичната точка на повреда. Това може значително да подобри производителността на приложението, когато имате географско разделение между приложението и нивото на данни, особено за балансиращите натоварвания на база данни, които поддържат кеширане на набор от резултати като ProxySQL и MaxScale. От друга страна, броят на балансьорите на натоварване на базата данни обикновено е равен на броя на възлите на приложението, което означава, че ако нивото на приложението се разшири, броят на балансьорите на натоварване на базата данни ще се увеличава, което може потенциално да влоши производителността за здравето на базата данни проверка на услугата. Имайте предвид, че проверките на състоянието на балансиращото натоварване са малко по-бъбливи поради отговорността му да поддържа правилното състояние на възлите на базата данни.
С помощта на инструменти за автоматизация на ИТ инфраструктурата, като Chef, Puppet и Ansible, заедно с инструментите за оркестриране на контейнери, вече не е невъзможна задача да се автоматизира внедряването и управлението на множество екземпляри за балансиране на натоварването за тази топология. Въпреки това, ще има друга крива на обучение за оперативния екип, за да излезе с изпитани в битка, производствени стандарти за разгръщане и политики за управление, за да се намали прекомерната работа при работа с много възли за балансиране на натоварването. Не пропускайте всички важни аспекти на управлението на балансирането на натоварването на базата данни, като архивиране/възстановяване, надграждане/понижаване, управление на конфигурацията, контрол на услугите, управление на грешки и т.н.
Разпределената топология може да се смесва заедно с централизираната топология за някои поддържани балансатори на натоварване на база данни като ProxySQL, както е илюстрирано на следната диаграма:
Задните "сървъри" на екземпляр на ProxySQL могат да бъдат друг набор от ProxySQL вместо това възли. С тази конфигурация виртуален IP адрес не е необходим за единична крайна точка за достъп до възлите на базата данни, тъй като локалният ProxySQL екземпляр, хостван локално на сървъра на приложения, ще бъде достъпът на единична крайна точка от гледна точка на приложението.
Това обаче изисква две версии на конфигурациите за балансиране на натоварването - едната, която се намира на нивото на приложението, а другата се намира на нивата на балансиращото натоварване. Той също така изисква повече хостове, с изключение на необходимостта да научите за технологията за виртуални IP адреси, IP failover и така нататък. Предимствата и недостатъците както на разпределените, така и на централизираните настройки се сливат заедно в тази топология.
Заключение
Всяка топология има своите предимства и недостатъци и трябва да бъде добре планирана от самото начало. Това ранно решение е от решаващо значение и може значително да повлияе на производителността, мащабируемостта, надеждността и наличността на вашето приложение в дългосрочен план.
