Заключването на доставчик е добре позната концепция за технологиите за бази данни. С увеличаването на използването на облак, това заключване също се разшири, за да включи доставчици на облак. Можем да дефинираме заключването на доставчика като собствено заключване, което прави клиента зависим от доставчик за техните продукти или услуги. Понякога това заключване не означава, че не можете да промените доставчика/доставчика, но може да е скъпа или отнемаща време задача.
PostgreSQL, технология за бази данни с отворен код, сама по себе си няма проблема със заключване на доставчика, но ако използвате системите си в облака, вероятно ще трябва да се справите с този проблем по някое време.
В този блог ще споделим някои съвети как да избегнете блокирането в облак PostgreSQL и също така ще разгледаме как ClusterControl може да помогне за избягването му.
Съвет №1:Проверете за ограничения или ограничения на облачния доставчик
Облачните доставчици обикновено предлагат прост и удобен начин (или дори инструмент) за мигриране на вашите данни в облака. Проблемът е, че когато искате да ги оставите, може да е трудно да намерите лесен начин за мигриране на данните към друг доставчик или към локална настройка. Тази задача обикновено има висока цена (често въз основа на количеството трафик).
За да избегнете този проблем, винаги първо трябва да проверявате документацията и ограниченията на доставчика на облак, за да знаете ограниченията, които може да са неизбежни при напускане.
Съвет №2:Предварително планиране за излизане от доставчик на облак
Най-добрата препоръка, която можем да ви дадем, е да не чакате последната минута, за да знаете как да напуснете доставчика си на облак. Трябва да го планирате много предварително, за да можете да знаете кой е най-добрият, най-бързият и най-евтиният начин да излезете.,
Тъй като този план най-вероятно зависи от вашите специфични бизнес изисквания, планът ще бъде различен в зависимост от това дали можете да планирате прозорци за поддръжка и дали компанията ще приеме някакви периоди на престой. Планирайки го предварително, определено ще избегнете главоболие в края на деня.
Съвет №3:Избягвайте да използвате всякакви ексклузивни продукти на облачен доставчик
Продуктът на доставчик на облак почти винаги ще работи по-добре от продукт с отворен код. Това се дължи на факта, че е проектиран и тестван да работи в инфраструктурата на облачния доставчик. Изпълнението често ще бъде значително по-добро от второто.
Ако трябва да мигрирате базите си данни към друг доставчик, ще имате проблем с технологичното заключване, тъй като продуктът на доставчика на облак е достъпен само в текущата среда на доставчик на облак. Това означава, че няма да можете да мигрирате лесно. Вероятно можете да намерите начин да го направите, като генерирате дъмп файл (или друг метод за архивиране), но вероятно ще имате дълъг период на престой (в зависимост от количеството данни и технологии, които искате да използвате).
Ако използвате Amazon RDS или Aurora, Azure SQL Database или Google Cloud SQL, (за да се съсредоточите върху най-използваните в момента доставчици на облак), трябва да помислите за проверка на алтернативите за мигрирането им към отворен код база данни. С това не казваме, че трябва да го мигрирате, но определено трябва да имате възможност да го направите, ако е необходимо.
Съвет №4:Съхранявайте резервните си копия в друг доставчик на облак
Добра практика за намаляване на времето на престой, независимо дали в случай на миграция или за възстановяване след бедствие, е не само да съхранявате резервни копия на едно и също място (за по-бързо възстановяване), но и да съхранявате резервни копия в различен доставчик на облак или дори локален.
Като следвате тази практика, когато трябва да възстановите или мигрирате данните си, просто трябва да копирате най-новите данни, след като резервното копие е било взето обратно. Обемът на трафика и времето ще бъдат значително по-малко от копирането на всички данни без компресия по време на събитието на миграция или отказ.
Съвет №5:Използвайте многооблачен или хибриден модел
Това е може би най-добрият вариант, ако искате да избегнете заключването в облак . Съхраняването на данните на две или повече места в реално време (или възможно най-близо до реално време) ви позволява да мигрирате по бърз начин и можете да го направите с възможно най-малко престой. Ако имате PostgreSQL клъстер в един облачен доставчик и имате PostgreSQL standby възел в друг, в случай, че трябва да промените доставчика си, можете просто да популяризирате резервния възел и да изпратите трафика към този нов първичен PostgreSQL възел.
Подобна концепция се прилага към хибридния модел. Можете да запазите производствения си клъстер в облака и след това можете да създадете резервен клъстер или възел на база данни on-prem, който генерира хибридна (облачна/на-премиум) топология и в случай на неуспех или необходимост от миграция, можете да популяризирате възела в режим на готовност без заключване в облак, тъй като използвате собствената си среда.
В този случай имайте предвид, че вероятно доставчикът на облак ще ви таксува за изходящия трафик, така че при натоварен трафик поддържането на този метод да работи може да генерира прекомерни разходи за компанията.
Как ClusterControl може да помогне за избягване на PostgreSQL заключването
За да избегнете блокирането на PostgreSQL, можете също да използвате ClusterControl за разгръщане (или импортиране), управление и наблюдение на клъстерите на вашите бази данни. По този начин няма да разчитате на конкретна технология или доставчик, за да поддържате системите си работещи.
ClusterControl има удобен и лесен за използване потребителски интерфейс, така че не е необходимо да използвате конзола за управление на доставчик на облак, за да управлявате вашите бази данни, просто трябва да влезете и ще имате преглед на всички ваши клъстери от база данни в една и съща система.
Има три различни версии (включително безплатна версия за общността). Все още можете да използвате ClusterControl (без някои платени функции), дори ако лицензът ви е изтекъл и това няма да повлияе на производителността на вашата база данни.
Можете да разгръщате различни механизми за бази данни с отворен код от една и съща система и само SSH достъп и се изисква привилегирован потребител, за да го използва.
ClusterControl може също да помогне при управлението на вашата система за архивиране. От тук можете да планирате ново архивиране, като използвате различни методи за архивиране (в зависимост от двигателя на базата данни), компресирате, шифровате, проверявате вашите архиви, като го възстановите в различен възел. Можете също да го съхранявате на няколко различни места едновременно (включително в облака).
Многооблачната или хибридната реализация е лесно осъществима с ClusterControl с помощта на Репликация от клъстер към клъстер или функцията Добавяне на подчинен репликация. Трябва само да следвате прост съветник, за да разположите нов възел на базата данни или клъстер на друго място.
Заключение
Тъй като данните вероятно са най-важният актив за компанията, най-вероятно ще искате да поддържате данните възможно най-контролирани. Наличието на облачно заключване не помага за това. Ако сте в сценарий на заключване в облак, това означава, че не можете да управлявате данните си, както желаете, и това може да е проблем.
Въпреки това, заключването в облак не винаги е проблем. Възможно е да използвате цялата си система (бази данни, приложения и т.н.) в един и същ доставчик на облак, използвайки продуктите на доставчика (Amazon RDS или Aurora, Azure SQL база данни или Google Cloud SQL) и да не търсите мигрирайки каквото и да било, вместо това е възможно да се възползвате от всички предимства на доставчика на облак. Избягването на блокиране в облак не винаги е задължително, тъй като зависи от всеки отделен случай.
Надяваме се, че сте харесали нашия блог, в който споделяте най-често срещаните начини за избягване на блокиране на PostgreSQL в облак и как ClusterControl може да помогне.
