В предишния блог от поредицата обсъдихме плюсовете и минусите на използването на Galera Cluster за създаване на георазпределен клъстер. В тази публикация ще проектираме базиран на Galera гео-разпределен клъстер и ще покажем как можете да разположите всички необходими части с помощта на ClusterControl.
Проектиране на гео-разпределен клъстер Galera
Ще започнем с обяснението на средата, която искаме да изградим. Ще използваме три отдалечени центъра за данни, свързани чрез Wide Area Network (WAN). Всеки център за данни ще получава записи от локални сървъри на приложения. Четенията също ще бъдат само локални. Това има за цел да избегне ненужния трафик, пресичащ WAN.
За тази настройка връзката е на място и е защитена, но няма да описваме как точно може да се постигне това. Има много методи за осигуряване на свързаността, като се започне от собствени хардуерни и софтуерни решения през OpenVPN и се стигне до SSH тунели.
Ще използваме ProxySQL като loadbalancer. ProxySQL ще бъде разгърнат локално във всеки център за данни. Той също така ще насочва трафика само към локалните възли. Отдалечените възли винаги могат да се добавят ръчно и ние ще обясним случаите, в които това може да е добро решение. Приложението може да бъде конфигурирано да се свърже с един от локалните възли на ProxySQL, използвайки кръгов алгоритъм. Можем също така да използваме Keepalived и Virtual IP за насочване на трафика към единичния възел на ProxySQL, стига един възел на ProxySQL да може да обработва целия трафик.
Друго възможно решение е да разпределите ProxySQL с възли на приложението и да конфигурирате приложението да се свързва с прокси сървъра на локалния хост. Този подход работи доста добре при допускането, че е малко вероятно ProxySQL да не е наличен, но приложението ще работи добре на същия възел. Обикновено това, което виждаме, е или повреда на възел, или повреда на мрежата, което би засегнало както ProxySQL, така и приложението едновременно.
Диаграмата по-горе показва версията на средата, където ProxySQL е разположен на същия възел като приложението. ProxySQL е конфигуриран да разпределя натоварването между всички възли на Galera в локалния център за данни. Един от тези възли ще бъде избран като възел за изпращане на записите, докато SELECT ще бъдат разпределени между всички възли. Наличието на един специален възел за записване в център за данни помага за намаляване на броя на възможните конфликти при сертифициране, което обикновено води до по-добра производителност. За да намалим това още повече, ще трябва да започнем да изпращаме трафика през WAN връзката, което не е идеално, тъй като използването на честотната лента значително ще се увеличи. В момента, с наличните сегменти, само две копия от набора за запис се изпращат през центровете за данни – по едно на DC.
Основният проблем при георазпределените внедрявания на Galera Cluster е забавянето. Това е нещо, което винаги трябва да тествате, преди да стартирате средата. Добре ли съм с времето за ангажимент? При всеки комит трябва да се случи сертифициране, така че наборите за запис трябва да бъдат изпратени и сертифицирани на всички възли в клъстера, включително отдалечените. Възможно е високата латентност да сметне настройката за неподходяща за вашето приложение. В този случай може да намерите няколко клъстера на Galera, свързани чрез асинхронна репликация, по-подходящи. Това обаче би било тема за друга публикация в блога.
Разгръщане на гео-разпределен клъстер Galera с помощта на ClusterControl
За да изясним нещата, ще покажем тук как може да изглежда едно внедряване. Няма да използваме действителна настройка за няколко DC, всичко ще бъде разгърнато в локална лаборатория. Предполагаме, че латентността е приемлива и цялата настройка е жизнеспособна. Това, което е страхотно за ClusterControl е, че не зависи от инфраструктурата. Не се интересува дали възлите са близо един до друг, разположени в един и същ център за данни или дали възлите са разпределени между множество доставчици на облак. Докато има SSH свързаност от екземпляр на ClusterControl към всички възли, процесът на внедряване изглежда абсолютно същият. Ето защо можем да ви го покажем стъпка по стъпка, използвайки само местна лаборатория.
Инсталиране на ClusterControl
Първо, трябва да инсталирате ClusterControl. Можете да го изтеглите безплатно. След като се регистрирате, трябва да получите достъп до страницата с ръководство за изтегляне и инсталиране на ClusterControl. Това е толкова просто, колкото стартирането на шел скрипт. След като инсталирате ClusterControl, ще ви бъде представен формуляр за създаване на административен потребител:
След като го попълните, ще ви бъде представен екран за добре дошли и достъп към съветниците за внедряване:
Ще продължим с внедряването. Това ще отвори съветник за внедряване:
Ще изберем MySQL Galera. Трябва да предадем подробности за SSH свързаност - поддържат се или root потребител, или sudo потребител. На следващата стъпка трябва да дефинираме сървъри в клъстера.
Ще внедрим три възела в един от центровете за данни. Тогава ще можем да разширим клъстера, конфигурирайки нови възли в различни сегменти. Засега всичко, което трябва да направим, е да щракнем върху „Разгръщане“ и да гледаме как ClusterControl внедрява клъстера Galera.
Първите ни три възела вече работят и вече можем да продължим с добавянето допълнителни възли в други центрове за данни.
Можете да направите това от менюто за действие, както е показано на екранната снимка по-горе .
Тук можем да добавяме допълнителни възли, един по един. Важното е, че трябва да промените сегмента Galera на различен от нула (0 се използва за първите три възела).
След известно време получаваме всичките девет възела, разпределени в три сегмента.
Сега трябва да разположим прокси слоя. Ще използваме ProxySQL за това. Можете да го разположите в ClusterControl чрез Manage -> Load Balancer:
Това отваря поле за внедряване:
Първо трябва да решим къде да разположим ProxySQL. Ще използваме съществуващите възли на Galera, но можете да въведете всичко в полето, така че е напълно възможно да разположите ProxySQL върху възлите на приложението. Освен това трябва да подадете идентификационни данни за достъп за администратора и потребителя за наблюдение.
След това трябва или да изберем един от съществуващите потребители в MySQL, или да създадем такъв точно сега. Също така искаме да гарантираме, че ProxySQL е конфигуриран да използва възли на Galera, разположени само в същия център за данни.
Когато имате готов ProxySQL в центъра за данни, можете да го използвате като източник на конфигурацията:
Това трябва да се повтори за всеки сървър на приложения, който имате във всички центрове за данни . След това приложението трябва да бъде конфигурирано да се свързва с локалния ProxySQL екземпляр, в идеалния случай през Unix сокета. Това идва с най-добра производителност и най-ниска латентност.
След внедряването на последния ProxySQL, нашата среда е готова. Приложните възли се свързват с локален ProxySQL. Всеки ProxySQL е конфигуриран да работи с възли на Galera в един и същ център за данни:
Заключение
Надяваме се, че тази поредица от две части ви помогна да разберете силните и слабите страни на георазпределените клъстери Galera и как ClusterControl прави много лесно разгръщането и управлението на такъв клъстер.
