Van databaseconsultants naar database-reliability-engineers
Onze klanten hebben heel verschillende manieren van werken. Sommigen werken met virtuele machines, anderen gebruiken bare metal. Weer anderen hebben gekozen voor een modernere infrastructuur zoals Kubernetes. Dankzij onze kennis van de bestaande omgeving van de klant en ons inzicht in de wensen van de klant, zijn we in staat om de best mogelijke oplossing te creëren.
Daar is wel de nodige database-ervaring en een echte Devops-mentaliteit voor nodig. Onze databaseconsultants zijn heel ervaren en draaien hun hand niet om voor een complexe omgeving. Ze hebben gedegen kennis van en ervaring met meerdere platformen. We vinden database-reliability-engineers dan ook een betere benaming.
Ze zorgen er immers voor dat onze klanten hun database op de meest efficiënte, consistente en kosteneffectieve manier beheren, waaronder ook Cloud databases en Cloud native producten.
Kubernetes flexibel mechanisme voor het implementeren van applicaties
De reden voor klanten om voor Kubernetes te kiezen is vaak omdat ze zo applicaties op een gemakkelijke en onderhoudsvriendelijke manier kunnen implementeren en wijzigen. Met de juiste helm-charts en tooling biedt het een zeer flexibel mechanisme voor de implementatie van applicaties.
Postgres is in onze beleving de meest geavanceerde open-source-database, vooral als je die in containers op Kubernetes draait. Het heeft een kleine footprint en kan worden uitgebreid met bijvoorbeeld PostGIS en TimescaleDB. Sommige van onze klanten weten van de mogelijkheid om Postgres op containers te draaien, anderen twijfelen nog en moeten overtuigd worden met argumenten en een goed Proof of Concept.
Met de verbeteringen van ‘persistent storage’ in Kubernetes en de evolutie van ‘orchestrators’ voor allerlei soorten databases zoals MySQL – met of zonder Galera – en Postgres, kunnen wij onze klanten optimaal adviseren.
Kubernetes in productie: Het kan!
De vraag leeft of Kubernetes-operators kunnen worden gebruikt in een productie omgeving. Wij hebben dat bijvoorbeeld succesvol gedaan bij Royal Van Oord, een internationale maritieme aannemer. Royal Van Oord is een geweldige partij om mee te werken. Royal Van Oord draaide al op Crunchy Postgres-containers en het bedrijf was op zoek naar uitgebreide Postgres-support.
Dit was voordat de Crunchy-operator werd ontwikkeld. Begin 2019 vroeg het bedrijf ons om hun Postgres-containers te ondersteunen en gedegen back-up en herstel te faciliteren. We hebben dit geïmplementeerd door logische replicatie te gebruiken van de containers in Kubernetes naar twee Postgres-instanties op virtuele machines.
Uitdagingen
Het aantal Postgres-containers, of applicaties die een Postgres-pod gebruiken, liep op van een handje vol tot enkele tientallen. De belasting verschilt van applicatie tot applicatie. Sommige zijn analytisch, bij andere gaat het om online transaction processing (OLTP). De omvang kan ook erg variëren, sommige pods zijn honderden Gigabyte, andere zijn een paar Gigabyte. Met deze logische replicatie-opstelling hadden we een paar uitdagingen:
- De applicatielevenscyclus (Postgres-containers worden opnieuw gestart).
- De grootte van sommige Postgres-containers en de initiële gegevenssynchronisatie met logische replicatie duurt lang.
- Specifieke extensies zoals PostGIS en TimescaleDB die worden gebruikt door Royal Van Oord’s applicaties hebben wat aandacht nodig tijdens initialisatie van logische replicatie.
Postgres Kubernetes Operator
Gaandeweg de samenwerking en gelet op de situatie hebben we begin 2021 Royal Van Oord geadviseerd om een Postgres Kubernetes Operator in te zetten om die uitdagingen en het omslachtige onderhoud te tackelen. Voor we dat deden hebben we een advies geschreven over de beschikbare operators op dat moment, eind 2020. Dat waren er drie:
- De Postgres Kubernetes-operator van Zalando
- De Crunchy data-operator
- De Could Native PostgreSQL-operator van EDB
Enkele van de factoren die we hebben gewogen zijn kosten, ondersteuning, gebruiksgemak, flexibiliteit, documentatie en voor zover te bepalen, marktaandeel. Wij zijn toen uitgekomen op de Cloud Native PostgreSQL Operator van EDB.
Waarom de Cloud Native PostgreSQL Operator van EDB?
Bij het selecteren van een operator is het belangrijk om ook naar de toekomst te kijken en niet alleen naar de huidige applicatie. Met de beschikbare opties op dat moment hadden we sterk het gevoel dat op de lange termijn de EDB Cloud Native PostgreSQL (CloudNativePG) de meest complete en toekomstbestendige fit zou zijn voor dit project en voor Royal Van Oord in het algemeen. De belangrijkste aspecten bij dit besluit waren:
- De Enterprise-grade ondersteuning van EDB (en een groot partnernetwerk).
- De goed doordachte operator.
- De ondersteuning voor bi-directionele replicatie (de enige operator met deze mogelijkheid).
- De operator maakt ook gebruik van de Enterprise-monitor. Deze geeft een uniform beeld van alle clusters en knooppunten, zowel in k8s als op IaaS.
Top-drie-voordelen
Ten eerste, de zeer snelle implementatie van een clusteropstelling. Dat kan letterlijk in minuten. Ook het uitrollen van een pgbouncer-setup is een kwestie van een paar regels code.
Ten tweede, dankzij de state fullness van het cluster zorgt de operator ervoor dat het cluster altijd wordt weergegeven zoals gedefinieerd, waardoor het cluster dichterbij echte High Availability komt met minimale menselijke tussenkomst.
Last but not least: de CloudNative Postgres Plugin, cnp, waarmee het heel eenvoudig is om een Postgres-cluster op Kubernetes te beheren.
De grote uitdagingen bij het draaien van databases in Kubernetes
Die veranderingen waren niet eenvoudig. Het vereist een goede samenwerking met de klant. Het vroeg ook om een flinke mentaliteitsverandering: van traditionele implementaties naar een verklarend model, en van scripts naar helm charts. Een andere uitdaging was dat er op dat moment geen EDB-ondersteunde image was met PostGIS- en TimescaleDB-extensies.
Natuurlijk zijn er de nodes, node pools, taint en affinity die geconfigureerd kunnen worden. Een goed advies hierbij is om er gewoon mee te experimenteren. Er waren ook enkele uitdagingen op het gebied van monitoring en waarschuwingen en om de juiste statistieken in de dashboards krijgen.
Maar de dashboards die bij de operator worden geleverd, zijn een goed startpunt. Je moet nadenken over resource limieten op knooppunten waarop pods worden uitgevoerd die meer resource-intensief zijn. Dat is het zo’n beetje.
CloudNativePG is open source geworden
Wij hebben begrepen dat EDB er voor heeft gekozen om Cloud Native Postgres als open source software open stellen. Wij juichen dat toe. Wanneer meer mensen uit de gemeenschap bereid en in staat zijn om een bijdrage te leveren, wordt de operator alleen maar sterker.
Vanuit een puur financieel business perspectief zou je wellicht een andere keuze kunnen maken, maar dat mag naar mijn mening een beslissing als deze niet tegenhouden. Ik denk dat we blij mogen zijn met een geweldig nieuw open-source-product als de Cloud Native PostgreSQL-operator, CloudnativePG.
Demo CloudNativePG en interview bekijken
Hieronder kun je het interview tussen Gabriele Bartolini van EDB en Martijn Wallet bekijken.
Via deze link kun je de hele sessie van EDB bekijken, start met een inleiding over de Postgres Kubernetes Operator, vervolgens een sterke uitleg en het open source project, het interview met Martijn (vanaf 25:55) en daarna de demo.
Meer weten?
Nieuwsgierig of cloud-native-technologie iets voor jouw organisatie kan betekenen en hoe dat precies in z’n werk gaat? Neem gerust vrijblijvend contact op! We denken graag met je mee.