Vendor lock-in er et velkendt koncept for databaseteknologier. Med stigende cloud-brug er denne lock-in også udvidet til at omfatte cloud-udbydere. Vi kan definere leverandørlåsning som en proprietær låsning, der gør en kunde afhængig af en leverandør for deres produkter eller tjenester. Nogle gange betyder denne låsning ikke, at du ikke kan skifte leverandør/udbyder, men det kan være en dyr eller tidskrævende opgave.
PostgreSQL, en open source-databaseteknologi, har ikke leverandørens indlåsningsproblem i sig selv, men hvis du kører dine systemer i skyen, er det sandsynligt, at du bliver nødt til at klare det problem på et tidspunkt.
I denne blog vil vi dele nogle tips om, hvordan du undgår PostgreSQL-cloud-indlåsning og også se på, hvordan ClusterControl kan hjælpe med at undgå det.
Tip #1:Tjek, om der er begrænsninger eller begrænsninger for cloududbyderen
Skyudbydere tilbyder generelt en enkel og venlig måde (eller endda et værktøj) til at migrere dine data til skyen. Problemet er, at når du vil forlade dem, kan det være svært at finde en nem måde at migrere dataene til en anden udbyder eller til en lokal opsætning. Denne opgave har normalt en høj pris (ofte baseret på mængden af trafik).
For at undgå dette problem skal du altid først tjekke cloududbyderens dokumentation og begrænsninger for at kende de begrænsninger, der kan være uundgåelige, når du forlader.
Tip nr. 2:Planlæg på forhånd for afslutning af en cloududbyder
Den bedste anbefaling, vi kan give dig, er, at du ikke skal vente til sidste øjeblik med at vide, hvordan du forlader din cloud-udbyder. Du bør planlægge det lang tid i forvejen, så du kan kende den bedste, hurtigste og billigste måde at gøre din exit på.
Fordi denne plan højst sandsynligt afhænger af dine specifikke forretningskrav, vil planen være anderledes afhængigt af, om du kan planlægge vedligeholdelsesvinduer, og om virksomheden vil acceptere nedetidsperioder. Planlægger du det på forhånd, vil du helt sikkert undgå hovedpine i slutningen af dagen.
Tip nr. 3:Undgå at bruge eksklusive cloud-udbyderprodukter
En cloud-udbyders produkt vil næsten altid køre bedre end et open source-produkt. Dette skyldes, at det er designet og testet til at køre på cloud-udbyderens infrastruktur. Ydeevnen vil ofte være betydeligt bedre end den anden.
Hvis du har brug for at migrere dine databaser til en anden udbyder, har du et teknologisk lock-in-problem, da cloud-udbyderproduktet kun er tilgængeligt i det nuværende cloud-udbydermiljø. Dette betyder, at du ikke nemt vil være i stand til at migrere. Du kan sikkert finde en måde at gøre det på ved at generere en dumpfil (eller en anden backupmetode), men du vil sandsynligvis have en lang nedetid (afhængigt af mængden af data og teknologier, du vil bruge).
Hvis du bruger Amazon RDS eller Aurora, Azure SQL Database eller Google Cloud SQL (for at fokusere på de mest aktuelt brugte cloud-udbydere), bør du overveje at tjekke alternativerne for at migrere det til en open source database. Med dette siger vi ikke, at du skal migrere det, men du bør helt sikkert have mulighed for at gøre det, hvis det er nødvendigt.
Tip #4:Gem dine sikkerhedskopier hos en anden cloud-udbyder
En god praksis til at mindske nedetiden, uanset om det er i tilfælde af migrering eller katastrofegendannelse, er ikke kun at gemme sikkerhedskopier på samme sted (af hensyn til hurtigere gendannelse), men også at gemme sikkerhedskopier i en anden cloud-udbyder eller endda on-prem.
Ved at følge denne praksis, når du skal gendanne eller migrere dine data, skal du blot kopiere de seneste data, efter at sikkerhedskopien blev taget tilbage. Mængden af trafik og tid vil være betydeligt mindre end at kopiere alle data uden komprimering under migreringen eller fejlhændelsen.
Tip #5:Brug en multisky- eller hybridmodel
Dette er sandsynligvis den bedste mulighed, hvis du vil undgå skylåsning . Lagring af data to eller flere steder i realtid (eller så tæt på realtid som du kan komme) giver dig mulighed for at migrere på en hurtig måde, og du kan gøre det med mindst mulig nedetid. Hvis du har en PostgreSQL-klynge i én cloud-udbyder, og du har en PostgreSQL-standby-knude i en anden, kan du, i tilfælde af at du skal skifte udbyder, bare promovere standby-knuden og sende trafikken til denne nye primære PostgreSQL-knude.
Et lignende koncept anvendes på hybridmodellen. Du kan beholde din produktionsklynge i skyen, og så kan du oprette en standby-klynge eller en databasenode on-prem, som genererer en hybrid (cloud/on-prem) topologi, og i tilfælde af fejl eller behov for migrering, kan du fremme standby-knuden uden nogen cloud-låsning, da du bruger dit eget miljø.
I dette tilfælde skal du huske på, at cloududbyderen sandsynligvis vil debitere dig for den udgående trafik, så under tung trafik, hvis denne metode fungerer, kan det generere en overdreven omkostning for virksomheden.
Hvordan ClusterControl kan hjælpe med at undgå PostgreSQL-låsning
For at undgå PostgreSQL-låsning kan du også bruge ClusterControl til at implementere (eller importere), administrere og overvåge dine databaseklynger. På denne måde er du ikke afhængig af en bestemt teknologi eller udbyder for at holde dine systemer oppe og køre.
ClusterControl har en venlig og letanvendelig brugergrænseflade, så du behøver ikke bruge en cloud-udbyderstyringskonsol til at administrere dine databaser, du skal bare logge ind, og du har en oversigt over alle dine databaseklynger i samme system.
Den har tre forskellige versioner (inklusive en gratis fællesskabsversion). Du kan stadig bruge ClusterControl (uden nogle betalte funktioner), selvom din licens er udløbet, og det vil ikke påvirke din databaseydeevne.
Du kan implementere forskellige open source-databasemotorer fra det samme system og kun SSH-adgang og en privilegeret bruger er påkrævet for at bruge det.
ClusterControl kan også hjælpe med at administrere dit backup-system. Herfra kan du planlægge en ny backup ved hjælp af forskellige backupmetoder (afhængigt af databasemotoren), komprimere, kryptere, verificere dine backups ved at gendanne den i en anden node. Du kan også gemme det på flere forskellige steder på samme tid (inklusive skyen).
Multisky- eller hybridimplementeringen kan nemt udføres med ClusterControl ved at bruge Klynge-til-klynge-replikering eller funktionen Tilføj replikeringsslave. Du behøver kun at følge en simpel guide for at implementere en ny databasenode eller klynge et andet sted.
Konklusion
Da data nok er det vigtigste aktiv for virksomheden, vil du sandsynligvis gerne holde data så kontrolleret som muligt. At have en cloud lock-in hjælper ikke på dette. Hvis du er i et cloud-lock-in-scenarie, betyder det, at du ikke kan administrere dine data, som du ønsker, og det kan være et problem.
Men cloud lock-in er ikke altid et problem. Det kan være muligt, at du kører alt dit system (databaser, applikationer osv.) i den samme cloud-udbyder ved at bruge udbyderens produkter (Amazon RDS eller Aurora, Azure SQL Database eller Google Cloud SQL), og du leder ikke efter migrere hvad som helst, i stedet for det, er det muligt, at du udnytter alle fordelene ved cloud-udbyderen. At undgå cloud lock-in er ikke altid et must, da det afhænger af hvert enkelt tilfælde.
Vi håber, du kunne lide vores blog, der deler de mest almindelige måder at undgå en PostgreSQL cloud-indlåsning på, og hvordan ClusterControl kan hjælpe.