De nieuwe manier om open source databases te beheren

Nog niet zo lang geleden bestond de database-industrie uit een handvol leveranciers. Databases waren voornamelijk relationeel en draaiden op afzonderlijke machines. Hoge beschikbaarheid werd geïmplementeerd via actief-standby ‘clusters’. Bij een verticaal ‘scale-up’ model ging het vooral om shared storage (SAN of DRBD) of asynchrone replicatie van logs om de status te synchroniseren met een standby node. In 2001, toen ik begon te werken met NDB Cluster (wat later MySQL Cluster zou worden), was het concept om een ​​hele database in het hoofdgeheugen te houden raar - 'wat als je de server uitschakelt?'. Het distribueren van een database over meerdere servers was zorgwekkend - 'je hebt hier en daar stukjes data'. En het hele idee van een open source database voor missiekritieke workloads was lachwekkend.

Fast forward 15 jaar en we hebben nu tientallen databaseleveranciers op de markt - meestal open source, verschillende modellen (sleutelwaarde, document, grafiek, ...) en standaard gedistribueerd. Geheugenresidente gegevens zijn vrijwel de norm om hoge prestaties en lage latentie te bereiken. Drie van de top 5 meest populaire databases (volgens db-engines ranking) zijn open source (MySQL, PostgreSQL en MongoDB). Tegenwoordig is de kans groter dat u een vloot databaseservers beheert die over verschillende datacenters zijn verdeeld. Mogelijk laat u zelfs een aantal van uw databases beheren door een externe cloudleverancier.

Dus, hoe is het om databases te beheren in 2018?

AUTOMATIE

Met zoveel taken om te beheren en maar zoveel uren in een dag, zou je gek zijn om dingen handmatig te doen.

Automatisering is een geweldige manier om dingen voor elkaar te krijgen. Toen we weinig databases moesten beheren, zou het bedienen van de database erg praktisch zijn, met sommige taken gescript in zoiets als bash of perl - bijvoorbeeld een script om een ​​back-up van de database te maken, een ander om back-upbestanden naar een bepaalde locatie te verplaatsen. Failover zou handmatig zijn en we zouden zelfs discussiëren of het geautomatiseerd moet worden of niet.

Tegenwoordig is automatisering een no-brainer. Er zijn een aantal IT-automatiserings- of configuratiebeheersystemen die kunnen worden gebruikt - Puppet, Chef, Ansible en Salt bieden allemaal frameworks voor algemene doeleinden die kunnen worden gebruikt om automatisering te bouwen voor verschillende databasetopologieën. Clusterbeheersoftware die speciaal is geschreven om database-instellingen te beheren, omvat MongoDB Ops Manager en ClusterControl. Ze stellen de operationele teams in staat om hun clusters te beheren met iets dat direct beschikbaar is. Het is geen sinecure om vanaf het begin een clusterbeheersysteem te bouwen met behulp van een configuratiebeheersysteem. Het vereist aanzienlijke expertise in de automatiseringstool, evenals begrip van beheeractiviteiten zoals back-upplanning en -verificatie, automatische failover met daaropvolgende herconfiguratie van systemen, uitrol van configuratiewijzigingen, patching, versie-upgrade of -downgrade, enz.

En natuurlijk is er de opkomst van DBaaS-serviceplatforms, waar implementatie, gezondheid, failover, back-ups, enz. allemaal door software worden bestuurd. Cloudproviders zijn inderdaad erg goed in automatisering. Amazon RDS is een geweldig voorbeeld van database-automatisering op schaal:het automatiseert implementatie, patch-upgrades, back-ups, herstel op een bepaald tijdstip, schalen van replica's en hoge beschikbaarheid/failover.

HUISDIEREN vs VEE

In de jaren 90 en tot de dotcom-boom en -bust, verdienden Sun Microsystems en Oracle een fortuin door opschalingsdatabases op grote SMTP-hardware te verkopen. Voeg daar wat SAN-opslag en Veritas-failoversoftware aan toe en je hebt een ultramodern actief-standby-failovercluster voor hoge beschikbaarheid. Databaseservers waren relatief klein in aantal, maar krachtig omdat ze verticaal zouden groeien. Ze kregen namen (net zoals je je huisdieren noemt!), en werden verzorgd door DBA's.

Tegenwoordig zijn databases goedkoop en draaien ze goed op standaardhardware. Het zijn er veel, en we geven ze nummers - net als vee. Als er een kapot gaat, kunnen we gewoon een nieuwe krijgen.

Het is ook een nieuw runderras - open source runderen! Drie van de top vijf databases zijn volgens db-engines allemaal open source - ze vreten langzaam maar zeker het marktaandeel van de twee propriëtaire leveranciers op. Open source is de nieuwe datacenterstandaard, niet alleen voor besturingssystemen maar ook voor databases.

Dus wat betekent dit voor jou? Welnu, in de toekomst is de kans groter dat u een open source-database beheert - of zelfs meerdere voor toepassingen die heterogene gegevensverzamelingen gebruiken. In een wereld van polyglot-persistentie en microservices wordt de onderliggende datastore nu bepaald door de aard van de data. Vanuit architectonisch oogpunt maken single-instance databases met schijfgebaseerde HA plaats voor clusters die mogelijk over meerdere datacenters worden verspreid.

Hebben we een DBA nodig?

De DBA-rol is een gespecialiseerde - er is jaren ervaring voor nodig om er een te worden. In het verleden, toen er slechts een paar eigen databaseleveranciers waren om uit te kiezen, had u gespecialiseerde DBA's met een specifieke reeks vaardigheden en ervaring. Het was ook vereist - databases zoals Oracle of SQL Server hebben enorme functiesets, die in de loop van tientallen jaren zijn gebouwd. Ze zijn niet gemakkelijk te beheren. Ze werden doorgaans ingezet als de enige database voor een applicatie en moesten worden gecontroleerd, er moest een back-up van de gegevens worden gemaakt en alle problemen die zich voordeden, moesten worden opgelost. Deze taken waren precies waar de DBA's zich op moesten concentreren.

In het afgelopen decennium is er echter een geheel nieuwe database-industrie ontstaan ​​- met tientallen en tientallen open source databases, evenals clouddatabaseservices. Zoals we eerder zagen, is het niet ongebruikelijk dat een toepassing een aantal verschillende datastores gebruikt. Maar bedrijven hebben zelden een DBA voor deze datastores die ze gebruiken. Waar vind je een MongoDB of Cassandra of DBA met meer dan 5 jaar productie-ervaring? Men kan stellen dat de nieuwe generatie NoSQL-databases veel eenvoudiger is dan hun voorgangers met gesloten bronnen, en daarom niet dezelfde leercurve zou ondergaan.

Het beheren ervan zou gewoon een taak zijn die wordt toegevoegd aan de takenlijst van het SysAdmin- of DevOps- of Site Reliability Engineering (SRE) -team. En we zien vandaag dat veel bedrijven geen fulltime DBA's hebben. In plaats daarvan wordt de verantwoordelijkheid verdeeld over teams, waarbij automatiseringstools steeds vaker worden gebruikt om routinematige dagelijkse taken uit te voeren. Voor databases die naar de cloud zijn verhuisd, worden de operationele aspecten van hoe de gegevens worden opgeslagen volledig uitbesteed aan de cloudprovider. Dus in plaats van te werken aan het opslaan van gegevens, kan het ops-team zich nu concentreren op het gebruik van de gegevens.

Databaselevenscyclus

De gemiddelde levenscyclus van een database was vroeger veel langer dan nu. Toen je eenmaal een databaseplatform had gekozen, was dat het. De beslissing zou worden genomen tussen twee of drie relationele databases, meestal door de DBA of iemand hoger in de organisatie. Het bedrijf zou het geld vinden om eeuwigdurende licenties aan te schaffen. Toen het besluit eenmaal was genomen, moest je er nu de komende 10+ jaar mee leven. Databases waren monolithisch en applicaties gebruikten meestal een enkele gedeelde database.

Tegenwoordig, in een wereld van containers, cloud, microservices en CI/CD-pijplijnen, is het niet ongebruikelijk dat ontwikkelaars de technologische keuzes maken - vooral als het een open source-database is die gemakkelijk kan worden gedownload of als een service kan worden aangeboden, zonder een verkoper te hoeven spreken of budget van het management te hoeven vragen. Organisaties worden uitgedaagd om sneller waarde te creëren, waardoor de snelheid van verandering in de infrastructuur/applicaties drastisch is gestegen. Monolithische databases zijn nu opgesplitst in meerdere kleine databases, waarbij elke database domeingegevens voor een individuele microservice beheert. Met de verscheidenheid aan databaseproducten die momenteel beschikbaar zijn in het open source-ecosysteem, hebben teams de keuze en vrijheid om over te stappen naar een betere datastore. Naarmate services in gebruik worden genomen en buiten gebruik worden gesteld, volgen databases ook - hoewel de gegevens zelf kunnen worden gearchiveerd of naar een datameer worden verplaatst. In een infrastructuurlandschap dat tegenwoordig veel dynamischer is, merken we dat onze databases een korter leven leiden.

DBA-ROL

De DBA, traditioneel zowel bewaker als poortwachter van de database, zou de databasebehoeften van verschillende applicatie-/infrastructuurteams in de organisatie kunnen voorzien. Voor alle wijzigingen die toegang of wijzigingen in de database vereisen, zijn de diensten van de DBA vereist. Conflicterende prioriteiten en gebrek aan DBA-beschikbaarheid kunnen echter betekenen dat het project wordt geblokkeerd/vertraagd, en onvermijdelijke wrijvingen zullen volgen.

Hoge kosten van samenwerking en snelle innovatie/korte time-to-market gaan niet goed samen. Zoals we eerder zagen, is microservices een voorbeeld van hoe infrastructuur en applicatieservices nu zo zijn ontworpen dat ze zoveel mogelijk ontkoppelen. Databases worden steeds meer geautomatiseerd en de controle over de database verschuift naar ontwikkelaars of projectteams. Zelfs dingen als schemawijzigingen zijn niet zo zwaar als vroeger. Ze waren veel moeilijker in de context van een centrale database voor een monolithische applicatie. Omdat gegevens tussen verschillende componenten worden gedeeld, moeten schemawijzigingen worden gecoördineerd en zorgvuldig worden gepland - meestal maanden van tevoren. DBA's speelden een sleutelrol bij het begrijpen en uitvoeren van veranderingen. De dynamiek is vandaag anders, waar de snelheid van verandering veel sneller is. Het is niet ongebruikelijk dat ontwikkelteams wekelijks of dagelijks codewijzigingen in productie doorvoeren - of zelfs meerdere keren per dag! Databases hebben constante updates nodig om de applicatiewijzigingen bij te houden, en deze worden uitgevoerd door ontwikkelaars. Sommige van de nieuwere databases zoals MongoDB maken het zelfs heel eenvoudig door een schemaloos model te hebben. Wat het in feite betekent, is dat het databaseschema naar de applicatiecode gaat.

Dus als alle gemeenschappelijke kerntaken worden weggeautomatiseerd, wat gebeurt er dan met de DBA-rol in de toekomst? In plaats van zich te concentreren op administratieve taken, zal de DBA meer fungeren als mentor voor andere teams in de organisatie. Organisaties moeten begrijpen welke gegevens ze hebben en hoe die gegevens kunnen worden gebruikt. Gegevens zijn immers het meest waardevol wanneer ze worden gedeeld en gecombineerd met andere bronnen, niet alleen opgeslagen. Schemaloos klinkt geweldig, maar we moeten nog steeds onze gegevens bijhouden - in de database of in de code. Beveiliging is een uitdaging en datalekken worden alleen maar erger. Dus als we data weer geweldig willen maken, moet de DBA verschuiven naar een horizontale adviseur/enabler-rol die zich uitstrekt over teams heen. Vanuit een competentieperspectief moet de moderne DBA begrijpen hoe gedistribueerde systemen met hoge beschikbaarheid moeten worden ontworpen en hoe efficiënte automatiseringssystemen moeten worden geïmplementeerd om de alledaagse taken uit te voeren. Aangezien bedrijven infrastructuur inzetten in cloud- of zelfs containeromgevingen, zal inzicht in het bouwen van zeer beschikbare en schaalbare databases op deze platforms het voortbestaan ​​van de DBA verzekeren.

Samenvatting

We bevinden ons op een fascinerend kruispunt in de geschiedenis van de database-industrie, die de afgelopen twee decennia een enorme transformatie heeft doorgemaakt. De onderstaande tabel probeert het samen te vatten.

Ik zou graag uw mening horen over het open source databasebeheer en of u dezelfde trends hebt gezien? Hoe zagen uw worstelingen of successen er de afgelopen jaren uit met OSDB's? En wat verwacht je dat er volgend jaar gaat gebeuren?

Wij bij Verschillendenines zullen ons uiteraard blijven inzetten om het beheer en de automatisering van uw open source databases te vergemakkelijken tot volgend jaar en daarna. Dus houd ons in de gaten voor updates hierover vanaf januari.

Maar laat me in de tussentijd weten wat je ervan vindt en tot ziens in 2019!

Foto's door SoRad (Shutterstock) &The Simpsons; andere foto's zijn van hun respectievelijke eigenaren.