От самото начало има нарастващ брой миграции към облачна среда. В крайна сметка облачните изчисления могат да осигурят много предимства за бизнеса, особено за тези, които работят с големи данни.
Въпреки това, с нарастването на търсенето се увеличават и разходите и може да се окажете в ситуация, при която месечните разходи в облака стават твърде високи и негативите скоро надхвърлят ползите от работата в облака. Или може би имате изисквания за сигурност или съответствие, които изискват от вас да имате по-директен контрол върху вашите системи. Това в крайна сметка може да ви накара да мигрирате обратно към локална среда.
AWS предоставя инструменти за наблюдение и управление за работа на нашата система в облака, като същевременно има видимост и контрол за оптимизиране. Въпреки това, когато се окажем готови за локално решение, може да бъде предизвикателство да мигрираме данните си и да пресъздадем всички инструменти за правилното управление на системите ни.
В този блог ще обсъдим как можете да мигрирате системите си от AWS към локален център за данни и как ClusterControl може да помогне за рационализиране на процеса.
Концепции
Преди да се заемем, нека разгледаме някои основни концепции за Amazon Cloud и ClusterControl.
AWS
Уеб услугите на Amazon (AWS) са платформа за инфраструктура като услуга, състояща се от голям брой независими и полунезависими услуги. Целта на платформата „Инфраструктура като услуга“ е да предлага на база суровини услуги, които преди това изискваха закупуване на капиталоемки инфраструктурни компоненти като сървъри от висок клас, мрежови рутери и комутатори, а за по-големите предприятия дори техните собствени центрове за данни.
RDS
Услугата за релационна база данни на Amazon (RDS) улеснява настройването, работата и мащабирането на релационна база данни в облака. Той осигурява рентабилен капацитет с възможност за промяна на размера, като същевременно автоматизира отнемащи време административни задачи, като осигуряване на хардуер, настройка на база данни, корекция и архивиране.
Amazon RDS е наличен в няколко типа екземпляри на база данни и ви предоставя шест познати системи за управление на бази данни, от които да избирате, включително Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle Database и SQL Server.
EC2
Amazon Elastic Compute Cloud (EC2) е услуга, която осигурява сигурен и преоразмеряем изчислителен капацитет в облака. Той е проектиран да улесни изчисленията в облак в уеб мащаб за разработчиците.
Простият уеб интерфейс на Amazon EC2 ви позволява да получите и конфигурирате капацитет с минимално триене. Той ви предоставя пълен контрол върху вашите изчислителни ресурси и ви позволява да работите в доказана компютърна среда на Amazon.
ClusterControl
ClusterControl е цялостна система за управление на бази данни с отворен код, която автоматизира внедряването, функциите за управление и наблюдението на здравето и производителността от едно стъкло.
ClusterControl поддържа внедряването, управлението, наблюдението и мащабирането за различни технологии за бази данни във всяка среда.
Защо да мигрираме към On-Prem?
Както споменахме по-рано, най-честите причини за мигриране от AWS към локална среда са разходи, сигурност, съответствие или стартиране на локални приложения. В AWS не знаете какво се случва под капака на инфраструктурата. Знаеш само дали всичко работи. Ако имате лоша производителност или аномалии, единственото решение е да се свържете с поддръжката на Amazon.
Примерен сценарий за миграция
В AWS имате два различни продукта, свързани с този блог:EC2 и RDS.
Основната разлика между тях е, че в EC2 имате SSH достъп до сървъра и трябва сами да управлявате базата данни. RDS е хоствана услуга за база данни и имате достъп само до екземпляра на базата данни.
В RDS, тъй като нямате SSH достъп, трябва да създадете дъмп и да го импортирате в новия сървър или да конфигурирате репликация и да популяризирате репликата до новия основен. И за двата варианта процесът е ръчен. Можете също да добавите балансьор на натоварване, за да подобрите този процес. Разгледахме тази задача в тези блогове:Част 1 и Част 2.
И така, нека се съсредоточим върху миграцията от EC2.
В нашия пример нека да видим как да мигрираме MySQL от AWS EC2 към локален център за данни. Ще използваме среда за репликация на MySQL, но тези стъпки трябва да работят за други технологии като PostgreSQL.
Ще приемем, че основната ви база данни MySQL работи на EC2 екземпляр. В локалния център за данни също ще приемем, че имате инсталиран ClusterControl и нов сървър на база данни, към който да мигрирате.
В конзолата за управление на AWS трябва да имате нещо подобно в EC2 раздел с екземпляри:
Първо, ще трябва да импортирате текущия си основен възел, работещ на EC2 към ClusterControl. За този процес на импортиране трябва да отворите порт 3306, като редактирате групата за сигурност, свързана с екземпляра EC2.
След това в ClusterControl отидете на секцията Импортиране:
Там можете да изберете технологията на базата данни, в този пример MySQL Replication, и трябва да посочите потребителя, ключа или паролата и порта, за да се свържете с вашия сървър чрез SSH. Също така трябва да предоставите името на вашия нов клъстер.
След като настроите информацията за SSH достъп, трябва да дефинирате някаква информация за базата данни, като идентификационните данни на администратора на базата данни, порт и baseir. Освен това можете да активирате функциите ClusterControl Node AutoRecovery и Cluster AutoRecovery за новия клъстер.
След това трябва да добавите своя сървър, като използвате IP адреса или името на хоста и натиснете Импортиране.
След като това стане, можете да наблюдавате състоянието на заданието за импортиране от Монитор на активността на ClusterControl.
След като задачата приключи, ще видите своя възел на базата данни в главния Екран ClusterControl:
Уверете се, че сте активирали генерирането на binlog в текущата си основна база данни.
Сега можете да добавите бъдещия си нов първичен възел като нова реплика от текущата си основна база данни. За това отидете на ClusterControl -> Изберете Cluster -> Cluster Actions -> Add Replication Slave.
Тук трябва да добавите името на хоста или IP адреса на новата реплика сървър и ако искате ClusterControl да инсталира софтуера вместо вас.
Уверете се, че имате свързаност от AWS към портове 3306 и 9999 на локалния сървър.
ClusterControl поетапно реплика с данни, като взема горещо резервно копие на основния, поточно го предава към репликата и го възстановява там. Веднъж възстановен, възелът на репликата е свързан с основния възел, за да може да навакса събитията и да се синхронизира. Имайте предвид, че за големи бази данни, работещи с известно натоварване, може да искате да избегнете допълнителното натоварване на тази операция на основния възел. В този случай е възможно първо да се изгради реплика възел от съществуващ резервно копие и след това да се свърже репликата, така че да настигне основния възел.
След тази задача трябва да имате нещо подобно:
Можете също да потвърдите топологията си в секцията ClusterControl Topology.
След това трябва да повишите репликата до основно (ClusterControl -> Изберете Cluster -> Node Actions -> Promote Slave) и променете крайната точка във вашето приложение.
За да подобрите тази топология, можете да добавите балансьор на натоварването за управление на трафика от сървъра на приложения към базата данни. Когато използвате балансьор на натоварване, няма да е необходимо да променяте крайната точка от приложението си по време на миграцията; балансиращото натоварване ще промени основния възел по прозрачен начин.
Има много начини да изпълните тази задача и трябва да можете да приемете стратегия като тази за вашата среда, в зависимост от вашата инфраструктура, сигурност и т.н.
От съображения за сигурност трябва да обмислите използването на VPN между AWS и локалната среда.
В случай на топология с няколко главни като Galera Cluster, трябва да добавите само възлите, които искате на място, но внимавайте с латентността. Можете да използвате, например, различни сегменти на Galera, за да намалите използването на мрежата.
Съображения за миграция
Накрая, ето някои съображения, които трябва да вземете предвид, ако искате да напуснете AWS и да започнете да използвате собствената си среда:
- Наблюдение:Не забравяйте да използвате система за наблюдение. Трябва да знаете какво се случва във вашата система през цялото време!
- Стратегия за възстановяване след бедствие:Трябва да помислите за добър DRP. По принцип трябва да разполагате с информацията на три различни физически места:основно, копие и резервно копие.
- Висока наличност:В днешно време високата наличност е задължителна в повечето производствени среди, така че трябва да помислите за най-доброто решение за висока наличност в зависимост от вашата инфраструктура.
- Мащабиране:Трябва да можете да мащабирате, ако е необходимо в бъдеще или за конкретно събитие.
- Отмяна:Ако искате да мигрирате от AWS към локална среда, имайте предвид, че нещо може да се обърка (както при всеки тип миграция), така че трябва да имате план за връщане назад.
- Да предположим, че търсите някаква хибридна среда, с екземпляри, работещи на AWS и on-prem. В този случай ClusterControl е отлично подходящ за наблюдение, управление на наличността, архивиране, мащабиране и други. Опитайте!
Приключване
Понякога работата в облака просто не е най-подходящата и може да се окаже, че трябва да мигрирате обратно към локално решение. Надяваме се, че този блог ви е предоставил полезна информация относно мигрирането на вашите базирани на MySQL данни към вашия локален център за данни от AWS и как ClusterControl предоставя инструментите, от които се нуждаете, за да управлявате правилно вашите системи.
След като завършите успешно миграцията си, подобрете системата си за наблюдение с проактивни стратегии като предсказуемо предупреждение. Вижте нашата наскоро актуализирана публикация за мониторинг на база данни с ClusterControl, за да научите повече.
За повече актуализации относно съветите и най-добрите практики за управление на бази данни, не забравяйте да се абонирате за нашия блог, RSS емисия и ни последвайте в LinkedIn и Twitter.
