Den nye måde at administrere Open Source-databaser på

For ikke så længe siden bestod databaseindustrien af ​​en håndfuld leverandører. Databaser var hovedsageligt relationelle og kørte på enkelte maskiner. Høj tilgængelighed blev implementeret via aktive standby 'klynger'. Med en vertikal 'opskaleringsmodel' handlede det mest om delt lagring (SAN eller DRBD) eller asynkron replikering af logfiler for at synkronisere tilstand til en standby-knude. I 2001, da jeg begyndte at arbejde med NDB Cluster (hvad der senere skulle blive til MySQL Cluster), var konceptet med at holde en hel database i hovedhukommelsen underligt - 'hvad nu hvis du slukker serveren?'. At distribuere en database på tværs af flere servere var bekymrende - 'du har stykker data her og der'. Og hele ideen med en open source-database til missionskritiske arbejdsbelastninger var til grin.

Spol 15 år frem, og vi har nu snesevis af databaseleverandører på markedet - for det meste open source, forskellige modeller (nøgleværdi, dokument, graf, …) og distribueret som standard. Hukommelsesresidente data er stort set normen for at opnå høj ydeevne og lav latenstid. Tre af de 5 mest populære databaser (ifølge db-engines ranking) er open source (MySQL, PostgreSQL og MongoDB). I dag er det mere sandsynligt, at du administrerer en flåde af databaseservere fordelt på forskellige datacentre. Du kan endda få nogle af dine databaser administreret af en tredjeparts cloudleverandør.

Så hvordan er det at administrere databaser i 2018?

AUTOMATION

Med så mange opgaver at håndtere og kun så mange timer på en dag, ville man være gal af at gøre tingene manuelt.

Automatisering er en fantastisk måde at få tingene gjort på. Når vi havde få databaser at administrere, ville betjeningen af ​​databasen være meget praktisk, med nogle opgaver skrevet i noget som bash eller perl - f.eks. et script til at sikkerhedskopiere databasen, et andet til at flytte backup-filer til et eller andet sted. Failover ville være manuel, og vi ville endda diskutere, om det skulle automatiseres eller ej.

I dag er automatisering en no-brainer. Der er en række IT-automatiserings- eller konfigurationsstyringssystemer, der kan udnyttes - Puppet, Chef, Ansible og Salt tilbyder alle generelle rammer, der kan bruges til at bygge automatisering til forskellige databasetopologier. Cluster management software skrevet specifikt til at administrere database opsætninger inkluderer MongoDB Ops Manager og ClusterControl. De gør det muligt for ops-holdene at administrere deres klynger med noget, der er let tilgængeligt fra hylden. Opbygning af et klyngestyringssystem fra bunden ved hjælp af et konfigurationsstyringssystem er ingen lille bedrift. Det kræver betydelig ekspertise inden for automatiseringsværktøjet samt forståelse for administrationsoperationer som planlægning og verifikation af backup, automatisk failover med efterfølgende rekonfiguration af systemer, udrulning af konfigurationsændringer, patching, versionsopgradering eller -nedgradering osv.

Og selvfølgelig er der fremkomsten af ​​DBaaS-serviceplatforme, hvor udrulning, sundhed, failover, sikkerhedskopier osv. alt sammen styres af software. Cloud-udbydere er virkelig gode til automatisering. Amazon RDS er et godt eksempel på databaseautomatisering i stor skala - det automatiserer implementering, patch-opgraderinger, sikkerhedskopier, gendannelse af tidspunkter, skalering af replikaer og høj tilgængelighed/failover.

KÆREdyr kontra Kvæg

I 90'erne og indtil dotcom-boomet og busten tjente Sun Microsystems og Oracle en formue på at sælge opskaleringsdatabaser på stor SMTP-hardware. Smid noget SAN-lager og Veritas-failover-software ind der, og du ville have fået dig en topmoderne aktiv-standby-failover-klynge for høj tilgængelighed. Databaseservere var relativt få i antal, men kraftfulde, da de ville vokse vertikalt. De fik navne (ligesom du navngiver dine kæledyr!) og blev passet af DBA'er.

I dag er databaser billige og kører godt på råvarehardware. Der er masser af dem, og vi giver dem numre - ligesom kvæg. Hvis en går i stykker, kan vi bare få en ny.

Det er også en ny kvægrace - open source kvæg! Tre af de fem bedste databaser, ifølge db-engines, er alle open source - de er langsomt, men sikkert ved at tære på markedsandelen for de to proprietære leverandører. Open source er den nye datacenterstandard, ikke kun for operativsystemer, men også for databaser.

Så hvad betyder det for dig? Nå, i fremtiden er det mere sandsynligt, at du vil administrere en open source-database - eller endda flere til applikationer, der bruger heterogene datasamlinger. I en verden af ​​polyglot-vedholdenhed og mikrotjenester, er det underliggende datalager nu dikteret af arten af ​​data. Fra et arkitektonisk synspunkt viger enkeltinstansdatabaser med diskbaseret HA for klynger, der potentielt er fordelt på tværs af flere datacentre.

Har vi brug for en DBA?

DBA-rollen er specialiseret - det kræver mange års erfaring at blive det. Tidligere, hvor der kun var et par proprietære databaseleverandører at vælge imellem, ville du have specialiserede DBA'er med et specifikt sæt færdigheder og erfaring. Det var også påkrævet - databaser som Oracle eller SQL Server har enorme funktionssæt, bygget over årtier. De er ikke nemme at administrere. De blev typisk implementeret som den eneste database for en applikation og skulle overvåges, sikkerhedskopieres data, og eventuelle problemer, der dukkede op, skulle håndteres. Disse opgaver var præcis, hvad DBA'erne var her for at fokusere på.

I det sidste årti er der dog opstået en helt ny databaseindustri - med snesevis og snesevis af open source-databaser såvel som cloud-databasetjenester. Som vi så tidligere, er det ikke ualmindeligt, at en applikation bruger et par forskellige datalagre. Men virksomheder har sjældent en DBA for disse datastores, de bruger. Hvor finder du en MongoDB eller Cassandra eller DBA med 5+ års produktionserfaring? Man kan argumentere for, at den nye generation af NoSQL-databaser er meget enklere end deres forgængere med lukket kildekode og derfor ikke ville pådrage sig den samme indlæringskurve.

At administrere dem ville blot være endnu en opgave, der føjes til todo-listen for SysAdmin- eller DevOps- eller Site Reliability Engineering (SRE)-teamet. Og vi ser i dag, at mange virksomheder ikke har fuldtids-DBA'er. Ansvaret er i stedet fordelt på tværs af teams, hvor automatiseringsværktøjer i stigende grad bliver brugt til at varetage de rutinemæssige daglige opgaver. For databaser, der er flyttet til skyen, outsources de operationelle aspekter af, hvordan dataene opbevares, helt til cloud-udbyderen. Så i stedet for at arbejde på, hvordan man gemmer data, kan ops-teamet nu fokusere på brugen af ​​dataene.

Databaselivscyklus

Den gennemsnitlige livscyklus for en database plejede at være meget længere, end den er i dag. Når du først valgte en databaseplatform, var det det. Beslutningen ville blive truffet mellem to eller tre relationelle databaser, normalt af DBA eller en højere oppe i organisationen. Virksomheden ville finde penge til at købe evige licenser. Da beslutningen var taget, skulle du nu leve med den i de næste 10+ år. Databaser var monolitiske, og applikationer ville typisk bruge en enkelt delt database.

I dag, i en verden af ​​containere, cloud, mikrotjenester og CI/CD-pipelines, er det ikke ualmindeligt, at udviklere træffer de teknologiske valg - især hvis det er en open source-database, der nemt kan downloades eller tilbydes som en service, uden at skulle tale med en sælger, eller at skulle søge budget hos ledelsen. Organisationer bliver udfordret til at skabe værdi hurtigere, så ændringshastigheden af ​​infrastrukturen/applikationerne er steget dramatisk. Monolitiske databaser er nu opdelt i flere små databaser, hvor hver database administrerer domænedata for en individuel mikrotjeneste. Med de mange forskellige databaseprodukter, der er tilgængelige i dag i open source-økosystemet, har teams valget og friheden til at flytte til et bedre datalager. Efterhånden som tjenester idriftsættes og nedlægges, følger der også databaser med - selvom selve dataene måske bliver arkiveret eller flyttet ind i en datasø. I et infrastrukturlandskab, som er meget mere dynamisk i dag, oplever vi, at vores databaser lever kortere.

DBA-ROLE

DBA'en, der traditionelt er både vogter og gatekeeper for databasen, vil servicere databasebehovene hos forskellige applikations-/infrastrukturteams i organisationen. Ændringer, der krævede adgang eller ændringer til databasen, vil kræve DBA's tjenester. Men modstridende prioriteringer og manglende DBA-tilgængelighed kan betyde, at projektet ville blive blokeret/forsinket, og uundgåelig friktion ville følge.

Høje omkostninger ved samarbejde og hurtig innovation/kort time to market går ikke godt sammen. Som vi så tidligere, er mikrotjenester et eksempel på, hvordan infrastruktur og applikationstjenester nu er opbygget, så de afkobles så meget som muligt. Databaser bliver i stigende grad automatiseret, og kontrollen over databasen flyttes til udviklere eller projektteams. Selv ting som skemaændringer er ikke så tunge, som de plejede at være. De var meget sværere i forbindelse med en central database til en monolitisk applikation. Da data deles mellem forskellige komponenter, skal skemaændringer koordineres og planlægges omhyggeligt - normalt måneder i forvejen. DBA'er havde en nøglerolle i at forstå og udføre ændringer. Dynamikken er anderledes i dag, hvor forandringshastigheden er meget hurtigere. Det er ikke ualmindeligt, at udviklingsteams presser kodeændringer i produktionen på en ugentlig eller daglig basis - eller flere gange om dagen endda! Databaser har brug for konstante opdateringer for at holde trit med applikationsændringer, og disse udføres af udviklere. Nogle af de nyere databaser som MongoDB gør det endda meget enkelt ved at have en skemaløs model. Hvad det faktisk betyder, er, at databaseskemaet flytter ind i applikationskoden.

Så hvis alle de almindelige kerneopgaver bliver automatiseret væk, hvad sker der så med DBA-rollen i fremtiden? I stedet for at fokusere på administrative opgaver vil DBA i højere grad fungere som mentor for andre teams i organisationen. Organisationer skal forstå, hvilke data de har, og hvordan disse data kan bruges. Når alt kommer til alt, er data mest værdifulde, når de deles og kombineres med andre ressourcer, ikke blot gemt. Schemaless lyder fantastisk, men vi mangler stadig at holde styr på vores data – enten i databasen eller i koden. Sikkerhed er en udfordring, og databrud bliver bare værre. Så hvis vi skal gøre data fantastisk igen, skal DBA skifte til en horisontal rådgiver/enabler-rolle, der spænder på tværs af teams. Fra et kompetenceperspektiv er den moderne DBA nødt til at forstå, hvordan man designer distribuerede systemer med høj tilgængelighed, og indføre effektive automatiseringssystemer til at tage sig af de hverdagsagtige opgaver. Når virksomheder implementerer infrastruktur på tværs af cloud- eller endda containermiljøer, vil forståelsen af, hvordan man bygger yderst tilgængelige og skalerbare databaser på disse platforme, sikre DBA's overlevelse.

Oversigt

Vi sidder i et fascinerende knudepunkt i databaseindustriens historie, som har gennemgået en massiv transformation i de sidste 2 årtier. Tabellen nedenfor forsøger at opsummere det.

Jeg ville være interesseret i at høre dine tanker om open source-databasestyring, og om du har set de samme tendenser? Hvordan har dine kampe eller succeser set ud med OSDB'er i de seneste år? Og hvad forudser du, der sker næste år?

Vi hos Severalnines vil selvfølgelig fortsætte med at soldater for at hjælpe med at lette styringen og automatiseringen af ​​dine open source-databaser ind i næste år og fremover. Så følg med for opdateringer om det fra næste januar.

Men i mellemtiden, lad mig vide dine tanker, og vi ses i 2019!

Fotos af SoRad (Shutterstock) &The Simpsons; andre billeder er af deres respektive ejere.