At køre en MySQL Galera Cluster (enten Percona, MariaDB eller Codership build) er desværre ikke understøttet (og heller ikke en del af) de databaser, der understøttes af Amazon RDS. De fleste af de databaser, der understøttes af RDS, bruger asynkron replikering, mens Galera Cluster er en synkron multi-master replikeringsløsning. Galera kræver også InnoDB som sin storage-motor for at fungere korrekt, og mens du kan bruge andre storage-motorer såsom MyISAM, frarådes det, at du bruger denne storage-motor på grund af den manglende transaktionshåndtering.
På grund af den manglende understøttelse i RDS, vil denne blog fokusere på de tilbud, der er tilgængelige, når du vælger og hoster din Galera-baserede klynge ved hjælp af et AWS-miljø.
Der er helt sikkert mange grunde til, hvorfor du ville vælge eller ikke vælge AWS-skyplatformen, men for dette særlige emne vil vi gennemgå fordelene og fordelene ved det, du kan udnytte, snarere end hvorfor du ville vælge AWS-platformen.
De virtuelle servere (Elastic Compute Instances)
Som tidligere nævnt er MySQL Galera ikke en del af RDS, og InnoDB er en transaktionslagringsmotor, som du har brug for de rigtige ressourcer til dit applikationskrav. Det skal have kapacitet til at betjene efterspørgslen fra din kundeanmodningstrafik. På tidspunktet for denne artikel er dit eneste valg til at køre Galera Cluster ved at bruge EC2, Amazons cloud-tilbud til computerforekomster.
Fordi du har fordelen ved at køre dit system på en række noder på EC2-instanser, er det ikke meget forskelligt at køre en Galera Cluster på EC2-vers on-prem. Du kan få fjernadgang til serveren via SSH, installere dine ønskede softwarepakker og vælge den slags Galera Cluster-bygning, du kan lide at bruge.
Desuden er dette tilbud med EC2 mere elastisk og fleksibelt, hvilket giver dig mulighed for at levere og tilbyde en enklere, granulær opsætning. Du kan udnytte webtjenesterne til at automatisere eller bygge en række noder, hvis du skal skalere dit miljø, eller for eksempel automatisere opbygningen af dit iscenesættelses- eller udviklingsmiljø. Det giver dig også et forspring til hurtigt at bygge dit ønskede miljø, vælge og konfigurere dit ønskede OS og hente de rigtige computerressourcer, der passer til dine krav (såsom CPU, hukommelse og disklager). EC2 eliminerer tiden til at vente på hardware. , da du kan gøre dette med det samme. Du kan også bruge deres AWS CLI-værktøj til at automatisere din Galera-klyngeopsætning.
Priser for Amazon EC2-forekomster
EC2 tilbyder en række valgmuligheder, som er meget fleksible for forbrugere, der gerne vil hoste deres Galera Cluster-miljø på AWS-beregningsnoder. AWS Free Tier inkluderer 750 timers Linux- og Windows t2.micro-forekomster hver måned i et år. Du kan forblive inden for Free Tier ved kun at bruge EC2 Micro-instanser, men dette er måske ikke det bedste til produktionsbrug.
Der er flere typer EC2-instanser, som du kan implementere, når du klargør dine Galera-noder. Ideelt set er disse r4/r5/x1-familier (hukommelsesoptimeret) og c4/c5-familier (computeroptimerede) et ideelt valg, og disse priser varierer afhængigt af, hvor stort dit behov for serverressourcer er og typen af OS.
Dette er de typer af betalte tilfælde, du kan vælge...
On Demand
Betal efter beregningskapacitet (pr. time eller pr. sekund), afhænger af typen af forekomster, du kører. For eksempel kan priserne variere, når der leveres en Ubuntu-forekomst vs RHEL-forekomst bortset fra typen af forekomst. Den har ingen langsigtede forpligtelser eller forudgående betalinger. Det har også fleksibiliteten til at øge eller reducere din computerkapacitet. Disse instanser anbefales til lave omkostninger og fleksible miljøbehov som applikationer med kortsigtede, spidse eller uforudsigelige arbejdsbelastninger, der ikke kan afbrydes, eller applikationer, der udvikles eller testes på Amazon EC2 for første gang. Tjek det ud her for mere info.
Dedikerede værter
Hvis du leder efter overholdelse og lovkrav, såsom behovet for at anskaffe en dedikeret server, der kører på en dedikeret hardware til brug, passer denne type tilbud til dine behov. Dedikerede værter kan hjælpe dig med at håndtere overholdelseskrav og reducere omkostninger ved at give dig mulighed for at bruge din eksisterende serverbundne softwarelicens, herunder Windows Server, SQL Server, SUSE Linux Enterprise Server, Red Hat Enterprise Linux eller andre softwarelicenser, der er bundet til VM'er , stikkontakter eller fysiske kerner, underlagt dine licensvilkår. Det kan købes On-Demand (hver time) eller som en reservation for op til 70 % rabat på On-Demand-prisen. Tjek det ud her for mere info.
Spotforekomster
Disse tilfælde giver dig mulighed for at anmode om ekstra Amazon EC2-computerkapacitet til op til 90 % rabat på On-Demand-prisen. Dette anbefales til applikationer, der har fleksible start- og sluttider, applikationer, der kun er mulige til meget lave beregningspriser, eller brugere med presserende computerbehov for store mængder ekstra kapacitet. Tjek det ud her for mere info.
Reserverede forekomster
Denne type betalingstilbud giver dig mulighed for at få op til 75 % rabat, og afhængigt af hvilken instans du ønsker at reservere, kan du erhverve en kapacitetsreservation, hvilket giver dig ekstra tillid til dine evner at starte forekomster, når du har brug for dem. Dette anbefales, hvis dine applikationer har steady state eller forudsigelig brug, applikationer, der kan kræve reserveret kapacitet, eller kunder, der kan forpligte sig til at bruge EC2 over en periode på 1 eller 3 år for at reducere deres samlede computeromkostninger. Tjek det ud her for mere info.
Prisbemærkning
En sidste ting med EC2, de tilbyder også en fakturering pr. sekund, som også tager udgifter til ubrugte minutter og sekunder i en time fra regningen. Dette er fordelagtigt, hvis du skalerer ud i et minimalt tidsrum, bare for at håndtere trafikanmodninger fra en Galera-knude, eller hvis du vil prøve at teste på en specifik node i et begrænset tidsrum.
Databasekryptering på AWS
Hvis du er bekymret for fortroligheden af dine data eller overholdelse af de love, der kræves for din overholdelse af sikkerhed og regler, tilbyder AWS data-at-rest-kryptering. Hvis du bruger MariaDB Cluster version 10.2+, har de indbygget plugin-understøttelse til grænseflade med Amazon Web Services (AWS) Key Management Service (KMS) API. Dette giver dig mulighed for at drage fordel af AWS-KMS nøgleadministrationstjeneste for at lette adskillelse af ansvar og fjernlogning og revision af nøgleadgangsanmodninger. I stedet for at gemme krypteringsnøglen i en lokal fil, beholder dette plugin hovednøglen i AWS KMS.
Når du starter MariaDB første gang, vil AWS KMS-plugin'et oprette forbindelse til AWS Key Management Service og bede den om at generere en ny nøgle. MariaDB vil gemme denne nøgle på disken i en krypteret form. Nøglen gemt på disken kan ikke bruges til at dekryptere dataene; snarere ved hver opstart forbinder MariaDB til AWS KMS og får tjenesten til at dekryptere den eller de lokalt lagrede nøgler. Den dekrypterede nøgle gemmes i hukommelsen, så længe MariaDB-serverprocessen kører, og den dekrypterede nøgle i hukommelsen bruges til at kryptere de lokale data.
Alternativt, når du implementerer dine EC2-instanser, kan du kryptere din datalagervolumen med EBS (Elastic Block Storage) eller kryptere selve instansen. Kryptering til EBS-type-volumener er alle understøttet, selvom det kan have en indvirkning, men latensen er meget minimal eller endda ikke synlig for slutbrugerne. For kryptering af EC2-instanstypen understøttes de fleste af de store instanser. Så hvis du bruger computer- eller hukommelsesoptimerede noder, kan du udnytte dens kryptering.
Nedenfor er listen over understøttede instanstyper...
- Generelt formål:A1, M3, M4, M5, M5a, M5ad, M5d, T2, T3 og T3a
- Beregningsoptimeret:C3, C4, C5, C5d og C5n
- Hukommelse optimeret:cr1.8xlarge, R3, R4, R5, R5a, R5ad, R5d, u-6tb1.metal, u-9tb1.metal, u-12tb1.metal, X1, X1e og z1d
- Lager optimeret:D2, h1.2xlarge, h1.4xlarge, I2 og I3
- Accelereret beregning:F1, G2, G3, P2 og P3
Du kan konfigurere din AWS-konto til altid at aktivere kryptering ved implementering af dine EC2-type instanser. Det betyder, at AWS vil kryptere nye EBS-volumener ved lanceringen og krypterer nye kopier af ukrypterede snapshots.
Multi-AZ/Multi-Region/Multi-Cloud-implementeringer
Desværre, når dette skrives, er der ingen sådan direkte support i AWS-konsollen (og heller ikke nogen af deres AWS API), der understøtter Multi-AZ/-Region/-Cloud-implementeringer til Galera-nodeklynger.
Høj tilgængelighed, skalerbarhed og redundans
For at opnå en multi-AZ-implementering anbefales det, at du sørger for dine galera-noder i forskellige tilgængelighedszoner. Dette forhindrer klyngen i at gå ned eller en klyngefejl på grund af manglende kvorum.
Du kan også konfigurere en AWS automatisk skalering og oprette en automatisk skaleringsgruppe til at overvåge og udføre statustjek, så din klynge altid vil have redundans, skalerbar og høj tilgængelighed. Automatisk skalering burde løse dit problem i tilfælde af, at din node går ned af en ukendt årsag.
For multi-region eller multi-cloud-implementering har Galera sin egen parameter kaldet gmcast.segment, som du kan indstille dette til ved serverstart. Denne parameter er designet til at optimere kommunikationen mellem Galera-knuderne og minimere mængden af trafik, der sendes mellem netværkssegmenter, inklusive skrivesæt-relæ og IST- og SST-donorvalg.
Denne type opsætning giver dig mulighed for at implementere flere noder i forskellige områder til din Galera Cluster. Bortset fra det kan du også implementere dine Galera-noder på en anden leverandør, for eksempel hvis den er hostet i Google Cloud, og du ønsker redundans på Microsoft Azure.
Jeg vil anbefale dig at tjekke vores blog Multiple Data Center Setups Using Galera Cluster til MySQL eller MariaDB og Zero Downtime Network Migration With MySQL Galera Cluster Using Relay Node for at indsamle flere oplysninger om, hvordan man implementerer disse typer af implementeringer.
Databaseydelse på AWS
Afhængigt af din applikationsefterspørgsel, er hukommelse, der optager de hukommelsesoptimerede forekomster, dit ideelle valg, hvis dine forespørgsler. Hvis din applikation har højere transaktioner, der kræver høj ydeevne til webservere eller batchbehandling, så vælg beregningsoptimerede forekomster. Hvis du vil lære mere om optimering af din Galera Cluster, kan du tjekke denne blog Sådan forbedrer du ydeevnen af Galera Cluster til MySQL eller MariaDB.
Database-sikkerhedskopier på AWS
Oprettelse af sikkerhedskopier kan være svært, da der ikke er nogen direkte support i AWS, der er specifik for MySQL Galera-teknologi. AWS giver dig dog en katastrofe- og gendannelsesløsning ved hjælp af EBS Snapshots. Du kan tage snapshots af de EBS-volumener, der er knyttet til din instans, og derefter enten tage en sikkerhedskopi efter tidsplan ved hjælp af CloudWatch eller ved at bruge Amazon Data Lifecycle Manager (Amazon DLM) til at automatisere snapshots.
Bemærk, at de taget snapshots er trinvise sikkerhedskopier, hvilket betyder, at kun de blokke på enheden, der er ændret efter dit seneste snapshot, gemmes. Du kan gemme disse snapshots på AWS S3 for at spare lageromkostninger. Alternativt kan du bruge eksterne værktøjer som Percona Xtrabackup og Mydumper (til logiske sikkerhedskopier) og gemme disse på AWS EFS -> AWS S3 -> AWS Glacier.
Du kan også konfigurere Lifecycle Management i AWS, hvis du har brug for, at dine backupdata skal lagres på en mere omkostningseffektiv måde. Hvis du har store filer og skal bruge AWS EFS, kan du udnytte deres AWS Backup-løsning, da dette også er en enkel, men omkostningseffektiv løsning.
På den anden side kan du også bruge eksterne tjenester (såvel som ClusterControl), som giver dig både overvågnings- og backupløsninger. Tjek dette ud, hvis du vil vide mere.
Databaseovervågning på AWS
AWS tilbyder sundhedstjek og nogle statustjek for at give dig synlighed i dine Galera-noder. Dette gøres gennem CloudWatch og CloudTrail.
CloudTrail giver dig mulighed for at aktivere og inspicere loggene og udføre revisioner baseret på, hvilke handlinger og spor der er foretaget.
CloudWatch lader dig indsamle og spore metrics, indsamle og overvåge logfiler og indstille brugerdefinerede alarmer. Du kan konfigurere det i overensstemmelse med dine tilpassede behov og få systemdækkende synlighed i ressourceudnyttelse, applikationsydelse og driftstilstand. CloudWatch kommer med et gratis niveau, så længe du stadig falder inden for dets grænser (se skærmbilledet nedenfor.)
CloudWatch kommer også med en pris afhængig af mængden af metrics, der distribueres. Tjek dens aktuelle priser ved at tjekke her.
Bemærk:Der er en ulempe ved at bruge CloudWatch. Det er ikke designet til at imødekomme databasens sundhed, især til overvågning af MySQL Galera-klyndeknuder. Alternativt kan du bruge eksterne værktøjer, der tilbyder grafer eller diagrammer i høj opløsning, der er nyttige i rapportering og er nemmere at analysere, når du diagnosticerer en problematisk node.
Til dette kan du bruge PMM af Percona, DataDog, Idera, VividCortex eller vores helt egen ClusterControl (da overvågning er GRATIS med ClusterControl Community.) Jeg vil anbefale, at du bruger et overvågningsværktøj, der passer til din behov baseret på dine individuelle ansøgningskrav. Det er meget vigtigt, at dit overvågningsværktøj er i stand til at underrette dig aggressivt eller give dig integration til instant messaging-systemer såsom Slack, PagerDuty eller endda sende dig SMS, når du eskalerer alvorlig helbredstilstand.
Databasesikkerhed på AWS
Sikring af dine EC2-instanser er en af de mest vitale dele af udrulning af din database i den offentlige sky. Du kan konfigurere et privat undernet og konfigurere de påkrævede sikkerhedsgrupper, der kun foretrækkes til at tillade porten eller kilde-IP afhængigt af din opsætning. Du kan indstille dine databasenoder med en ikke-fjernadgang og bare opsætte en jump-vært eller en internetgateway, hvis noder kræver adgang til internettet for at få adgang til eller opdatere softwarepakker. Du kan læse vores tidligere blog Deploying Secure Multicloud MySQL Replication på AWS og GCP med VPN om, hvordan vi konfigurerer dette.
Udover dette kan du sikre dine data under transport ved at bruge TLS/SSL-forbindelse eller kryptere dine data, når de er i ro. Hvis du bruger ClusterControl, er det enkelt og nemt at implementere en sikker datatransit. Du kan tjekke vores blog SSL Key Management og Kryptering af MySQL Data in Transit, hvis du vil prøve det. For data i hvile kan lagring af dine data via S3 krypteres ved hjælp af AWS Server-Side Encryption eller bruge AWS-KMS, som jeg har diskuteret tidligere. Tjek denne eksterne blog om, hvordan du opsætter og udnytter en MariaDB-klynge ved hjælp af AWS-KMS, så du kan gemme dine data sikkert i hvile.
Galera Cluster Fejlfinding på AWS
AWS CloudWatch kan hjælpe, især når man undersøger og tjekker systemmålingerne. Du kan tjekke netværket, CPU'en, hukommelsen, disken og dets instans eller computerbrug og balance. Dette opfylder muligvis ikke dine krav, når du graver i en specifik sag.
CloudTrail kan udføre solide spor af handlinger, der er blevet styret baseret på din specifikke AWS-konto. Dette vil hjælpe dig med at afgøre, om forekomsterne ikke kommer fra MySQL Galera, men kan være en fejl eller problemer i AWS-miljøet (såsom Hyper-V har problemer på værtsmaskinen, hvor din instans, som gæst, bliver vært.)
Hvis du bruger ClusterControl, går du til Logs -> System Logs, vil du være i stand til at gennemse de fangede fejllogfiler taget fra selve MySQL Galera-noden. Ud over dette giver ClusterControl overvågning i realtid, der vil forstærke dit alarm- og notifikationssystem i tilfælde af en nødsituation, eller hvis din MySQL Galera-knude(r) er kaput.
Konklusion
AWS har ikke ren support til en MySQL Galera Cluster-opsætning, i modsætning til AWS RDS, som har MySQL-kompatibilitet. På grund af dette er de fleste anbefalinger eller udtalelser, der kører en Galera Cluster til produktionsbrug i AWS-miljøet, baseret på erfarne og gennemtestede miljøer, der har kørt i meget lang tid.
MariaDB Cluster kommer med en fantastisk produktivitet, da de konstant yder kortfattet support til AWS-teknologistackløsningen. I den kommende udgivelse af MariaDB 10.5-versionen vil de tilbyde en support til S3 Storage Engine, som kan være ventetiden værd.
Eksterne værktøjer kan hjælpe dig med at administrere og kontrollere din MySQL Galera Cluster, der kører på AWS Cloud, så det er ikke en stor bekymring, hvis du har nogle dilemmaer og FUD om, hvorfor du skal køre eller skifte til AWS Cloud Platform.
AWS er måske ikke den ene-størrelse-pas-alle-løsning i nogle tilfælde, men den giver en bred vifte af løsninger, som du kan tilpasse og skræddersy den til at passe til dine behov.
I den næste del af vores blog vil vi se på en anden offentlig cloud-platform, især Google Cloud, og se, hvordan vi kan udnytte det, hvis vi vælger at køre vores Galera Cluster ind i deres platform.