Sådan kommer du i gang med databaseautomatisering

Databaseautomatisering hjælper med at gøre komplekse og tidskrævende opgaver enkle og hurtige. De opgaver, der oftest og let identificeres for automatisering, er dem, der er tidskrævende, men alligevel gentagne. Disse tærer ofte på produktiviteten og kan påvirke virksomhedens økonomi, fordi du skal betale de mennesker, der arbejder med disse opgaver. Imidlertid kan de processer, hvor tid og kræfter forbruges unødigt, konverteres til virtuel automatisering, hvorved man undgår ofte kedeligt, udmattende arbejde.

Databaseautomatisering har været en almindelig praksis for databaseadministratorer og serveradministratorer, som sammen er mere almindeligt kendt nu som DevOps. DevOps refererer også til kombinationen af ​​DBA'er og serveradministrationsopgaver. På gammeldags måde skrives traditionelle og almindelige automatiserede opgaver som en række SQL-sætninger eller .sql-filer, som implementerer og klargør servere via scripts, opsætning af kryptering/dekryptering eller udnyttelse af sikkerheden til det miljø, hvor din automatisering er formodet. at løbe. Her er automatisering ikke et eksempel på, at en virksomhed erstatter folk med scripts. Den er der som assistent for at bringe tingene op i hastighed og afslutte opgaver hurtigere med færre fejl. Automatisering kan ikke erstatte den måde, DBA'er udfører deres opgaver på eller den værdi, de kan levere til hele virksomheden eller organisationen.

Sofistikerede værktøjer til Infrastructure as Code (IaC) såsom Puppet, Chef, Ansible, SaltStack og Terraform hjælper DBA'er med at fuldføre de opgaver, der nemt kan replikeres, såsom backup og gendannelse, fail over, implementering af nye klynger, justering af sikkerhedsindstillinger, justering af OS Kernel og databaseydelse og meget mere. Ved hjælp af automatisering har mange DBA'er også forbedret eller flyttet deres kompetencer fra at fokusere på datadomænespecifikke opgaver til også at dække, hvordan man koder for at bruge disse IaC-værktøjer, der gør tingene nemmere end at bruge den traditionelle tilgang. Der er også værktøjer i øjeblikket, der gør det nemmere at administrere dine aktiver i skyen, såsom administration af din virksomheds brugerkonti, logfiler, implementering af forekomster eller administration af dine servere. Værktøjer til skyen fra de tre store cloud-udbydere inkluderer AWS CloudFormation, Azure Resource Manager og Google Cloud Deployment Manager og giver DBA'er eller DevOps mulighed for at udnytte automatiseringens kraft og gøre tingene hurtigere. Dette imponerer ikke kun din organisation eller virksomheds ledere, men også de kunder, der stoler på din service.

Hvad skal automatiseres?

Som nævnt ovenfor er databaseautomatisering ikke nyt for DBA'er, serveradministratorer eller endda DevOps. Der er ingen grund til at tøve eller stille spørgsmålstegn ved, om man skal automatisere. Som tidligere nævnt er almindelige sager, der let kan identificeres til automatisering, opgaver, der er gentagne.

Nedenfor opregner vi ting, der er aksiomatiske fra DBA's perspektiv.

• Provisionering af dine servere (f.eks. start VM-instanser som f.eks. brug af vagrant, start docker eller start dine Kubernetes platform) og opsætte SSH-adgang eller opsætte VPN-adgang

• Implementering af en ny databaseklynge

  • Identificer hvilken type databaseudbyder, typen af ​​opsætning (primær/standby, master-master replikering, synkron replikering)

• Importér eksisterende databaseklynge

• Implementer/importér eksisterende databaser til din nuværende databaseklynge

• Auto-failover eller overgang

• Automatisk gendannelse af node eller klynge

• Replika/slavepromovering eller nedrykning af en mester

• Implementering af belastningsbalancere (f.eks. ProxySQL, HaProxy, pgpool, pgbouncer, MaxScale, Keepalived)

• Sikkerhedskopiering og gendannelse

• Opsæt dit databaseovervågningsmiljø (implementer f.eks. agentbaseret overvågning som Prometheus)

• Aktiver sikkerhedsjusteringer

• Udfør automatiske optimeringer og tuning i overensstemmelse med typen af ​​miljø

• Aktiver alarmsystemer til andre tredjepartsintegrationer

• Generer advarsler eller alarmer og meddelelser

• Generer rapporter såsom grafer

• Behandle forespørgselslogfiler (langsomme logfiler) til forespørgselsanalyse

• Generer forespørgselsanalyse

• Databasearkivering eller oprydning

Der er selvfølgelig mange sager, som du kan automatisere, men dette viser de mest almindelige opgaver, og automatisering af dem er utvivlsomt. Det er den type opgaver, der er gentagne i naturen, og de fleste er fejltilbøjelige, især når de skal udføres hurtigt på grund af tidsbegrænsninger.

Hvad er ting, der ikke bør automatiseres?

Disse områder er, hvor dine DBA'er eller SysAdmins udfører det meste af arbejdet. Automatisering kan ikke erstatte DBA's kompetencer og intelligens, når det kommer til ting, der ikke kan automatiseres.

Det er underforstået, at en DBA skal være dygtig, med en dyb forståelse af: den database, de bruger, og de databaser, der vil blive implementeret; de data, der behandles og opbevares; og om den måde, de behandles på, er sikker, eller om den overholder virksomhedens sikkerhedsstandarder. DBA'er gennemgår også og betragtes for det meste som DevOps, såvel som automationsarkitekten. De dikterer, hvad der skal gøres, og hvad der ikke vil blive gjort. Almindelige ting, der ikke bør automatiseres, er følgende:

• Indstilling af dine planlagte sikkerhedskopier. Planlagte sikkerhedskopieringer er naturligvis automatiserede og skal køre i overensstemmelse hermed, men de planlagte datoer eller tidsrum, der kræves, bør være baseret på de lave spidsbelastningstider, serveren vil udføre. For eksempel kan du ikke tage en backup, hvis klyngen er optaget i dagtimerne. Der er også almindelige tilfælde, hvor servere stadig er optaget om natten afhængigt af typen af ​​applikation, du betjener, og hvor den er geografisk placeret.

• Auto-failover kunne ikke promovere en ny master. Dette er et af de vigtigste tilfælde og skal forstås godt. Hvis du har automatiserede scripts designet til failover, bør det ikke være designet til at tvangsforfølge en failover i tilfælde af, at det skulle fejle. Du ved måske aldrig, hvad der er hovedproblemet, og hvis der er en fejl, kan der være transaktioner, der har at blive inddrevet, før der skulle gøres andet. Det kunne f.eks. være en finansiel transaktion, der blev gemt på den mislykkede master, og du ville tvangspromovere en slave, men kandidatslaven havde undladt at replikere den seneste transaktion. I så fald kan du ende med beskadigede data.

• Datagendannelse. Selvfølgelig, når du støder på datakorruption, eller en klynge ikke kan genoprette fra din automatiske node/servergendannelse, skal du muligvis undersøge den primære årsag. Du skal dokumentere dette for din RCA (Root Cause Analysis) for at undgå det i fremtiden. Der er dog tilfælde, hvor fejlen er en fejl i den databasesoftware, du bruger, eller det kan være en VM-korruption.

• Datadrift eller datainkonsistens. Dette er bestemt ikke en ideel situation for automatisering. Du ønsker ikke, at din automat skal generalisere eller stereotype dine data til en praksis, der ville anvende dette koncept:"hvis data er beskadiget, lad os automatisk rette det". Det er bestemt ikke en god praksis. Der er rigtig mange sager, der først skal forstås og undersøges, før man kan tage stilling. I MySQL, for eksempel, er der et Percona-værktøj kaldet pt-table-checksum, derefter pt-table-sync, hvor begge er korrelative med hinanden for at rette datainkonsistens. Du vil bestemt ikke automatisere dette, medmindre du kender dine data meget godt, eller dine data ikke er omfattende, eller dataene kan genskabes.

• Kernetuning og databasetuning. Dette kan naturligvis ses som i modstrid med det, vi har anført ovenfor. Der er dog automatisk tunerbare variabler kendt for specifikke typer miljøer, såsom hukommelse, bufferpulje, HugePages eller virtuelle hukommelsesparametre. Der er dog helt sikkert en masse parametre, der kræver forståelse, undersøgelse, test, benchmarking, før du beslutter dig for at anvende ændringerne eller ej.

Helt sikkert, der er mange ting, du ikke bør automatisere, som vi ikke nævnte. I databaseverdenen er der et stort antal situationer, der afhænger af typen af ​​data og applikation, du betjener. Husk det, og vær følsom over for de ting, der kan automatiseres. Ellers kan automatisering føre til ødelæggelse.

Værktøjer til automatisering

Det er her, du kan komme i gang med dine automatiseringsscripts. Den vigtigste komponent i automatisering er hastighed! Når det kommer til hastighed, måles det ikke på, hvor hurtigt et værktøj er i stand til at afslutte opgaverne, men hvor komfortable udviklerne eller vedligeholderne af scripts eller IaC er med værktøjet. Der er bestemt fordele og ulemper ved disse automatiseringsværktøjer. Hvad der er vigtigere er at bestemme specifikationerne for disse automatiseringsværktøjer, da der er mere at tilbyde udover at være kun automatisering. Mere almindeligt giver de konfigurationsstyring og implementeringsmekanismer.

Automation handler om hastighed, det vil sige, hvor hurtigt det er i modsætning til at bruge en traditionel tilgang eller bruge dine egne foretrukne sprogscripts. Selvfølgelig kan det være perfekt at bruge dine egne scripts, men hvis din organisation eller virksomhed er til teknologiske fremskridt, så er det mere ideelt at bruge tredjepartsværktøjer som Ansible, Puppet, Chef, SaltStack eller Terraform. Hvorfor er det mere ideelt? Disse tredjepartsværktøjer er designet til at besejre lange og langvarige opgaver, der skal udføres, og kan udføres med få linjer kode.

F.eks. er Terraform kendt for sine portabilitetsfordele. Bare forestil dig, med Terraform har du ét værktøj og ét sprog til at beskrive infrastruktur til Google Cloud, AWS, OpenStack og ENHVER anden sky. Hvis du skifter til en anden udbyder, behøver du ikke at ændre eller gentage dine scripts. Det giver dig også mulighed for at have fuld-stack-implementering, og det inkluderer administration af dine Kubernetes-containere. Forestil dig, at du fra ét værktøj kan gøre mange ting.

Når du starter din databaseautomatisering, skal du ikke starte fra bunden, fordi målet med automatisering er hastighed! Igen måles hastighed ikke her i, hvor hurtigt det er at afslutte jobbet, men hvor hurtigt det er i forhold til en traditionel tilgang eller manuelle opgaver. Selvfølgelig afhænger hastigheden af, hvor hurtigt den er i stand til at afslutte jobbet, f.eks. kan en del af dine scripts forårsage lange forsinkelser på grund af en masse behandlede data og lange jobudførelser.

Vælg altid baseret på dine krav

Når du vælger værktøjer, skal du ikke stole på hype, eller hvad der er det mest populære, du har hørt om. Selvom de almindelige værktøjer, der blev nævnt tidligere, stort set er omfattet af fællesskabet, introducerer de også kompleksitet. For eksempel, når du bruger Ansible, skal du være fortrolig med YAML, mens du med Puppet eller Chef skal være fortrolig med Ruby og dets underliggende domænespecifikke sprog.

Udnyt de tilgængelige virksomhedsværktøjer

Der er en masse lovende databaseautomatiseringsværktøjer at komme i gang med. Hvis du føler, det er ubehageligt og tidskrævende at hyre DBA'er, SysAdmins eller DevOps til at udvide dit team, er der tilgængelige værktøjer, der tilbyder hjælp, når det kommer til databasestyring, backup-administration og observerbarhed.

Severalnines ClusterControl for Database Automation

ClusterControl tilbyder en masse automatiserede opgaver, der eliminerer behovet for manuelle tilgange. ClusterControl er designet til at gøre databaseoperationer nemme for organisationer, virksomheder, DBA'er, SysAdmins, DevOps og endda udviklere. Dens mål er at automatisere langvarige og gentagne opgaver. Den store fordel ved ClusterControl er, at det er et modent databasestyringsværktøj og har omfattende funktioner, der er meget kraftfulde til at administrere dine databaseservere. Den anvender også de mest opdaterede, branchestandard bedste praksisser til administration af dine databaser. Vi lytter til vores kunders krav, og derefter implementerer vi kapaciteter for at imødekomme dem.

Nogle af de mest funktionsrige ClusterControl-automatiseringsfunktioner, som du kan drage fordel af, er:

• Implementering af dine databaseservere. Vælg udbyder, angiv den rigtige version, bestem hvilken type klynge, angiv serverens værtsnavn/IP såsom brugernavn, adgangskode osv.

• Import af eksisterende servere til ClusterControl

• Implementering i skyen

• Databasesundhedsovervågning og -rapportering

• Advarsler og meddelelser

• Sikkerhedskopiering og gendannelse

• Backupbekræftelse

• Auto-failover, overgang

• Opsætning med høj tilgængelighed

• Forfrem en slave eller nedryk en mester

• Tilføj ny/eksisterende replika til din klynge

• Udvid endnu en klynge som slave af en anden klynge (perfekt til geografisk opsætning til din katastrofegendannelse)

• Knude- og klyngendannelse

• LDAP-integration

• Tredjepartsadvarsler

• Implementering af en hvilken som helst af en omfattende liste af belastningsbalancere  (pgbouncer, ProxySQL, MaxScale, HAProxy, Keepalived, garbd )

• Implementering af agentbaseret overvågning ved hjælp af Prometheus-eksportører

• Forespørgselsanalyse

• Sikkerhedsjusteringer

• Automatisk tuning for OS-kerne- og databaseparametre

Ud over  alle disse har ClusterControl også indbyggede rådgivere, der gør det muligt for DBA'er eller DevOps at oprette deres egne scripts og integrere i ClusterControl Performance Advisors.

Oversigt

Databaseautomatisering hjælper med at bringe komplekse, men gentagne opgaver op i hastighed. Det hjælper DBA'er med at komme hurtigt videre med forskellige opgaver og forbedre deres kompetencer afhængigt af omfanget af arbejdet. Databaseautomatisering frigør DBA'er til at være mere innovative, samtidig med at de nemt administrerer databasen. Databaseautomatisering erstatter ikke DBA's rolle. Der vil altid være brug for dygtige og kloge folk til at administrere dine databaser, især når katastrofen rammer. Stol altid på de værktøjer, som dine DBA'er anbefaler, mens du stoler på, at deres DBA's færdigheder kan administrere dine databasers sundhed og liv.