Хибридните среди, при които част от инфраструктурата на базата данни се намира локално, а част от нея се намира в публичен облак, не са рядкост. Може да има различни причини за използване на такава настройка - мащабируемост, гъвкавост, висока наличност, възстановяване след бедствие. Как да приложим тази настройка по правилен начин? Това може да е предизвикателство, тъй като трябва да обмислите няколко части от пъзел, които трябва да паснат заедно. Този блог има за цел да ви даде известна представа за това как може да изглежда такава настройка.
Свързване
Тук няма да навлизаме в подробности, защото има много начини за настройване на връзка между вашата локална настройка и публичния облак. Това ще зависи от инфраструктурата, която имате, публичния облак, който искате да използвате, и много други фактори. Обхватът от опции може да започне с рутери, поддържащи BGP, през хардуерен VPN, софтуерен VPN, завършващ в SSH тунели като начин за временно свързване на вашата мрежа с екземпляри в публичен облак. Важното е, каквото и да правите, крайният резултат трябва да бъде пълна и прозрачна свързаност от вашата локална мрежа към екземплярите, разположени в публичния облак.
Съображения за висока наличност
Репликацията на MySQL е чудесен начин за изграждане на високодостъпни системи, но идва със значителни ограничения. Основното нещо, което трябва да вземете предвид, е писателят - можете да имате само едно място, на което да изпратите вашите записи - майсторът. Без значение как искате да проектирате цялата среда, трябва внимателно да обмислите разположението на капитана. Най-вероятно искате той да бъде част от средата, която съдържа хостовете на приложението. Нека разгледаме следната настройка:
Имаме локална настройка с три MySQL възела и два допълнителни подчинени намиращ се в публичния облак, действащ като средство за възстановяване при бедствия за компанията, е съвсем ясно, че възелът за запис трябва да бъде разположен заедно с хостовете на приложението в частната част на облака. Искаме да запазим латентността възможно най-ниска за връзките, които имат най-голямо значение.
Този вид дизайн се фокусира върху наличността на базите данни - ако възлите, разположени на prem, няма да бъдат налични, хостовете на приложението може да могат да се свържат с отдалечената част на настройката - възлите на базата данни, разположени в публичния облак. В идеалния случай бихте използвали някакъв прокси за това - ProxySQL е едно от решенията, които могат да проследяват топологията и да преконфигурират според нуждите въз основа на съществуващата верига на репликация.
Ако искате да обмислите повече активна-активна настройка, при която имате възли на приложение както в частни, така и в публични, трябва да направите някои компромиси, тъй като записите ще трябва да се прехвърлят през WAN, от публичния към частния облак (или обратно, ако основното ви местоположение, където работите в публичния облак).
Отново, ProxySQL е избраното прокси. Това, което е страхотно, ProxySQL може да бъде конфигуриран като ProxySQL клъстер, като се гарантира, че промените в конфигурацията, въведени в единия възел, ще бъдат репликирани в останалите ProxySQL възли.
Обработка на неуспехи
Нека разгледаме няколко сценария на неуспех. Преди всичко трябва да имаме предвид, че асинхронната репликация на MySQL не е наясно с клъстер, следователно разделянето на мрежата е нещо, което трябва да се обработва ръчно - от потребителя ще зависи да вземе решението и да дръпне превключвателя, за да популяризира един от робите в средата, която е налична. Освен това от потребителя зависи да гарантира, че средата, която е загубила мрежовата връзка, ще се държи както трябва и няма да продължи да работи.
Ако частната част на облака стане недостъпна, както споменахме по-рано, ще са необходими ръчни действия, за да се повиши един от подчинените устройства, за да стане нов главен. Тогава всички останали сървъри на уеб приложения, разположени в публичния облак, използващи локален ProxySQL, ще имат трафика си пренасочен към новия главен и всички останали подчинени устройства. От друга страна, като се има предвид, че загубихме три от пет MySQL възела, искаме да увеличим мащаба на настройката на публичния облак - ClusterControl може да ви помогне при ефективно добавяне на допълнителни възли към вашия клъстер.
Друг сценарий може да е, че записващият се е сринал, докато връзката между нашата локална настройка и публичния облак работи добре.
В такъв сценарий ние искаме да повишим един от робите да стане нов господар. В зависимост от изискванията може също да искаме новият главен обект да бъде повишен между възли в дадена част от средата. ClusterControl има възможността да поставя в белия или черния списък възлите за преминаване при отказ, като гарантира, че имате пълен контрол върху процеса на отказ и че можете да изберете кои възли да се считат за кандидати за нов главен код и в какъв ред.
Надяваме се, че този блог ви даде някаква представа за това как работи настройката на хибридния облак за MySQL репликация и как може да ви защити в случай на повреда на базата данни или мрежата.
