Inlåsning av leverantörer är ett välkänt koncept för databasteknik. Med ökande molnanvändning har denna inlåsning även utökats till att omfatta molnleverantörer. Vi kan definiera leverantörslåsning som en proprietär inlåsning som gör en kund beroende av en leverantör för sina produkter eller tjänster. Ibland betyder denna inlåsning inte att du inte kan byta leverantör/leverantör, men det kan vara en dyr eller tidskrävande uppgift.
PostgreSQL, en databasteknik med öppen källkod, har inte problemet med leverantörslåsning i sig, men om du kör dina system i molnet är det troligt att du kommer att behöva hantera det problemet någon gång.
I den här bloggen kommer vi att dela med oss av några tips om hur du undviker PostgreSQL-molnlåsning och även titta på hur ClusterControl kan hjälpa till att undvika det.
Tips #1:Kontrollera om molnleverantörens begränsningar eller begränsningar finns
Molnleverantörer erbjuder i allmänhet ett enkelt och vänligt sätt (eller till och med ett verktyg) för att migrera din data till molnet. Problemet är att när du vill lämna dem kan det vara svårt att hitta ett enkelt sätt att migrera data till en annan leverantör eller till en lokal installation. Denna uppgift har vanligtvis en hög kostnad (ofta baserat på mängden trafik).
För att undvika detta problem måste du alltid först kontrollera molnleverantörens dokumentation och begränsningar för att veta vilka begränsningar som kan vara oundvikliga när du lämnar.
Tips #2:Planera i förväg för att avsluta en molnleverantör
Den bästa rekommendationen vi kan ge dig är att inte vänta till sista minuten för att veta hur du lämnar din molnleverantör. Du bör planera det långt i förväg så att du kan veta det bästa, snabbaste och billigaste sättet att göra din utgång.
Eftersom den här planen troligen beror på dina specifika affärskrav kommer planen att vara annorlunda beroende på om du kan schemalägga underhållsfönster och om företaget kommer att acceptera några stilleståndsperioder. Planerar du det i förväg kommer du definitivt att undvika huvudvärk i slutet av dagen.
Tips #3:Undvik att använda några exklusiva molnleverantörsprodukter
En molnleverantörs produkt kommer nästan alltid att fungera bättre än en produkt med öppen källkod. Detta beror på det faktum att det designades och testades för att köras på molnleverantörens infrastruktur. Prestandan blir ofta betydligt bättre än den andra.
Om du behöver migrera dina databaser till en annan leverantör har du problem med tekniklåsning eftersom molnleverantörsprodukten endast är tillgänglig i den nuvarande molnleverantörsmiljön. Det betyder att du inte kommer att kunna migrera lätt. Du kan förmodligen hitta ett sätt att göra det genom att generera en dumpfil (eller annan säkerhetskopieringsmetod), men du kommer förmodligen att ha en lång stilleståndsperiod (beroende på mängden data och teknik som du vill använda).
Om du använder Amazon RDS eller Aurora, Azure SQL Database eller Google Cloud SQL (för att fokusera på de mest använda molnleverantörerna) bör du överväga att kontrollera alternativen för att migrera den till en öppen källkod databas. Med detta säger vi inte att du ska migrera det, men du bör definitivt ha ett alternativ att göra det om det behövs.
Tips #4:Lagra dina säkerhetskopior hos en annan molnleverantör
En bra praxis för att minska stilleståndstiden, vare sig det gäller migrering eller katastrofåterställning, är att inte bara lagra säkerhetskopior på samma ställe (för snabbare återställningsskäl), utan också att lagra säkerhetskopior i en annan molnleverantör eller till och med on-prem.
Genom att följa denna praxis när du behöver återställa eller migrera dina data behöver du bara kopiera den senaste informationen efter att säkerhetskopian togs tillbaka. Mängden trafik och tid kommer att vara betydligt mindre än att kopiera all data utan komprimering under migreringen eller felhändelsen.
Tips #5:Använd en multimoln- eller hybridmodell
Detta är förmodligen det bästa alternativet om du vill undvika molnlåsning . Att lagra data på två eller flera platser i realtid (eller så nära realtid som du kan komma) gör att du kan migrera på ett snabbt sätt och du kan göra det med minsta möjliga stilleståndstid. Om du har ett PostgreSQL-kluster i en molnleverantör och du har en PostgreSQL standby-nod i en annan, om du behöver byta leverantör, kan du bara marknadsföra standby-noden och skicka trafiken till denna nya primära PostgreSQL-nod.
Ett liknande koncept tillämpas på hybridmodellen. Du kan behålla ditt produktionskluster i molnet och sedan kan du skapa ett standby-kluster eller en databasnod på plats, som genererar en hybrid (moln/on-prem) topologi, och i händelse av misslyckande eller migrering kan du främja standbynoden utan någon molnlåsning när du använder din egen miljö.
Tänk i det här fallet på att molnleverantören förmodligen kommer att debitera dig för den utgående trafiken, så under tung trafik, om den här metoden fungerar kan det generera en överdriven kostnad för företaget.
Hur ClusterControl kan hjälpa till att undvika PostgreSQL-låsning
För att undvika PostgreSQL-låsning kan du också använda ClusterControl för att distribuera (eller importera), hantera och övervaka dina databaskluster. På så sätt är du inte beroende av en specifik teknik eller leverantör för att hålla dina system igång.
ClusterControl har ett vänligt och lättanvänt användargränssnitt, så du behöver inte använda en hanteringskonsol för molnleverantörer för att hantera dina databaser, du behöver bara logga in och du får en översikt över alla dina databaskluster i samma system.
Den har tre olika versioner (inklusive en gratis version för communityn). Du kan fortfarande använda ClusterControl (utan vissa betalda funktioner) även om din licens har löpt ut och det kommer inte att påverka din databasprestanda.
Du kan distribuera olika databasmotorer med öppen källkod från samma system och endast SSH-åtkomst och en privilegierad användare krävs för att använda den.
ClusterControl kan också hjälpa till att hantera ditt backupsystem. Härifrån kan du schemalägga en ny säkerhetskopia med olika säkerhetskopieringsmetoder (beroende på databasmotorn), komprimera, kryptera, verifiera dina säkerhetskopior genom att återställa den i en annan nod. Du kan också lagra den på flera olika platser samtidigt (inklusive molnet).
Multimoln- eller hybridimplementeringen är lätt genomförbar med ClusterControl genom att använda Kluster-till-klusterreplikering eller funktionen Lägg till replikeringsslav. Du behöver bara följa en enkel guide för att distribuera en ny databasnod eller kluster på en annan plats.
Slutsats
Eftersom data förmodligen är den viktigaste tillgången för företaget, vill du troligen hålla data så kontrollerad som möjligt. Att ha en molnlåsning hjälper inte på detta. Om du befinner dig i ett molnlåsningsscenario betyder det att du inte kan hantera din data som du vill, och det kan vara ett problem.
Men molnlåsning är inte alltid ett problem. Det kan vara möjligt att du kör alla dina system (databaser, applikationer, etc) i samma molnleverantör med leverantörsprodukterna (Amazon RDS eller Aurora, Azure SQL Database eller Google Cloud SQL) och att du inte letar efter migrera vad som helst, istället för det är det möjligt att du drar fördel av molnleverantörens alla fördelar. Att undvika molnlåsning är inte alltid ett måste eftersom det beror på varje enskilt fall.
Vi hoppas att du gillade vår blogg som delar de vanligaste sätten att undvika en PostgreSQL-molnlåsning och hur ClusterControl kan hjälpa.