Vendor lock-in is een bekend concept voor databasetechnologieën. Met het toenemende cloudgebruik is deze lock-in ook uitgebreid met cloudproviders. We kunnen vendor lock-in definiëren als een propriëtaire lock-in die een klant afhankelijk maakt van een leverancier voor zijn producten of diensten. Soms betekent deze lock-in niet dat je niet van leverancier/aanbieder kunt veranderen, maar het kan een dure of tijdrovende taak zijn.
PostgreSQL, een open source databasetechnologie, heeft op zich geen vendor lock-in-probleem, maar als u uw systemen in de cloud draait, zult u waarschijnlijk te maken krijgen met dat probleem ooit.
In deze blog zullen we enkele tips delen over het voorkomen van PostgreSQL cloud lock-in en ook bekijken hoe ClusterControl kan helpen dit te voorkomen.
Tip #1:Controleer op beperkingen of beperkingen van cloudproviders
Cloudproviders bieden over het algemeen een eenvoudige en gebruiksvriendelijke manier (of zelfs een tool) om uw gegevens naar de cloud te migreren. Het probleem is dat wanneer u ze wilt verlaten, het moeilijk kan zijn om een gemakkelijke manier te vinden om de gegevens naar een andere provider of naar een installatie op locatie te migreren. Deze taak heeft meestal hoge kosten (vaak gebaseerd op de hoeveelheid verkeer).
Om dit probleem te voorkomen, moet u altijd eerst de documentatie en beperkingen van de cloudprovider controleren om de beperkingen te kennen die onvermijdelijk kunnen zijn bij het verlaten.
Tip #2:Plan vooraf voor een exit uit de cloudprovider
De beste aanbeveling die we u kunnen geven, is om niet tot het laatste moment te wachten om te weten hoe u uw cloudprovider kunt verlaten. Je moet het lang van tevoren plannen, zodat je weet wat de beste, snelste en goedkoopste manier is om af te sluiten.,
Omdat dit plan hoogstwaarschijnlijk afhangt van uw specifieke zakelijke vereisten, zal het plan verschillen, afhankelijk van of u onderhoudsperiodes kunt plannen en of het bedrijf eventuele uitvalperiodes accepteert. Als je het van tevoren plant, vermijd je zeker hoofdpijn aan het eind van de dag.
Tip #3:Vermijd het gebruik van exclusieve cloudproviderproducten
Het product van een cloudprovider zal bijna altijd beter werken dan een open source-product. Dit komt door het feit dat het is ontworpen en getest om te draaien op de infrastructuur van de cloudprovider. De prestatie zal vaak aanzienlijk beter zijn dan de tweede.
Als u uw databases naar een andere provider moet migreren, krijgt u het technologie-lock-in-probleem, aangezien het product van de cloudprovider alleen beschikbaar is in de huidige cloudprovideromgeving. Dit betekent dat u niet gemakkelijk kunt migreren. U kunt waarschijnlijk een manier vinden om dit te doen door een dumpbestand te genereren (of een andere back-upmethode), maar u zult waarschijnlijk een lange downtime hebben (afhankelijk van de hoeveelheid gegevens en technologieën die u wilt gebruiken).
Als u Amazon RDS of Aurora, Azure SQL Database of Google Cloud SQL gebruikt (om u te concentreren op de meest gebruikte cloudproviders), kunt u overwegen de alternatieven te bekijken om het naar een open source te migreren databank. Hiermee zeggen we niet dat je het moet migreren, maar je zou zeker een optie moeten hebben om het indien nodig te doen.
Tip #4:Bewaar uw back-ups op een andere cloudprovider
Een goede gewoonte om downtime te verminderen, of het nu gaat om migratie of voor herstel na noodgevallen, is niet alleen om back-ups op dezelfde plaats op te slaan (voor een sneller herstel), maar ook om back-ups op te slaan in een andere cloudprovider of zelfs op locatie.
Door deze gewoonte te volgen wanneer u uw gegevens moet herstellen of migreren, hoeft u alleen de nieuwste gegevens te kopiëren nadat de back-up is teruggenomen. De hoeveelheid verkeer en tijd zal aanzienlijk minder zijn dan het kopiëren van alle gegevens zonder compressie tijdens de migratie- of storingsgebeurtenis.
Tip #5:gebruik een multicloud- of hybride model
Dit is waarschijnlijk de beste optie als u cloud-lock-in wilt vermijden . Door de gegevens in realtime op twee of meer plaatsen op te slaan (of zo dicht mogelijk bij realtime als u kunt krijgen), kunt u op een snelle manier migreren en kunt u dit doen met zo min mogelijk downtime. Als je een PostgreSQL-cluster hebt in de ene cloudprovider en je hebt een PostgreSQL-standby-node in een andere, voor het geval je van provider moet veranderen, kun je de stand-by-node promoten en het verkeer naar deze nieuwe primaire PostgreSQL-node sturen.
Een soortgelijk concept wordt toegepast op het hybride model. U kunt uw productiecluster in de cloud houden en vervolgens een stand-bycluster of databaseknooppunt on-prem maken, dat een hybride (cloud/on-prem) topologie genereert, en in geval van storing of migratiebehoeften kunt u de stand-by node zonder enige cloud lock-in omdat je je eigen omgeving gebruikt.
Houd er in dit geval rekening mee dat de cloudprovider u waarschijnlijk kosten in rekening brengt voor het uitgaande verkeer, dus als er veel verkeer is, kunt u deze methode laten werken, wat buitensporige kosten voor het bedrijf kan veroorzaken.
Hoe ClusterControl kan helpen PostgreSQL-lock-in te voorkomen
Om PostgreSQL-lock-in te voorkomen, kunt u ClusterControl ook gebruiken om uw databaseclusters te implementeren (of te importeren), te beheren en te bewaken. Op deze manier bent u niet afhankelijk van een specifieke technologie of provider om uw systemen draaiende te houden.
ClusterControl heeft een gebruiksvriendelijke en gebruiksvriendelijke gebruikersinterface, dus u hoeft geen beheerconsole van een cloudprovider te gebruiken om uw databases te beheren. U hoeft alleen maar in te loggen en u heeft een overzicht van al uw databaseclusters in hetzelfde systeem.
Het heeft drie verschillende versies (inclusief een gratis communityversie). U kunt ClusterControl nog steeds gebruiken (zonder enkele betaalde functies), zelfs als uw licentie is verlopen en dit heeft geen invloed op uw databaseprestaties.
U kunt verschillende open source database-engines implementeren vanaf hetzelfde systeem, en alleen SSH-toegang en een bevoorrechte gebruiker is vereist om het te gebruiken.
ClusterControl kan ook helpen bij het beheren van uw back-upsysteem. Vanaf hier kunt u een nieuwe back-up plannen met behulp van verschillende back-upmethoden (afhankelijk van de database-engine), comprimeren, coderen en verifiëren van uw back-ups door deze op een ander knooppunt te herstellen. Je kunt het ook op meerdere verschillende locaties tegelijk opslaan (inclusief de cloud).
De multi-cloud of hybride implementatie is eenvoudig te doen met ClusterControl door gebruik te maken van de Cluster-naar-clusterreplicatie of de functie Replicatieslave toevoegen. U hoeft alleen een eenvoudige wizard te volgen om een nieuw databaseknooppunt of cluster op een andere plaats te implementeren.
Conclusie
Omdat gegevens waarschijnlijk het belangrijkste bezit van het bedrijf zijn, wilt u hoogstwaarschijnlijk gegevens zo gecontroleerd mogelijk houden. Het hebben van een cloud lock-in helpt hier niet bij. Als u zich in een cloud-lock-in-scenario bevindt, betekent dit dat u uw gegevens niet kunt beheren zoals u wilt, en dat kan een probleem zijn.
Cloud lock-in is echter niet altijd een probleem. Het kan zijn dat u al uw systemen (databases, applicaties, enz.) in dezelfde cloudprovider gebruikt met behulp van de providerproducten (Amazon RDS of Aurora, Azure SQL Database of Google Cloud SQL) en dat u niet op zoek bent naar alles migreert, in plaats daarvan is het mogelijk dat u profiteert van alle voordelen van de cloudprovider. Het vermijden van cloud lock-in is niet altijd een must, omdat het van elk geval afhangt.
We hopen dat je genoten hebt van onze blog met de meest voorkomende manieren om een PostgreSQL cloud lock-in te voorkomen en hoe ClusterControl kan helpen.