Sammenligning af Galera Cluster Cloud-tilbud:Anden del af Google Cloud Platform (GCP)

I vores sidste blog diskuterede vi de tilbud, der er tilgængelige i Amazon Web Services (AWS), når du kører en MySQL Galera Cluster. I denne blog vil vi fortsætte diskussionen ved at se nærmere på, hvad tilbuddene er for at køre den samme klyngeteknologi, men denne gang på Google Cloud Platform (GCP).

GCP, som et alternativ til AWS, har løbende tiltrukket applikationer, der er egnede til DevOps, ved at tilbyde support til en bred vifte af full-stack-teknologier, containeriserede applikationer og store produktionsdatabasesystemer. Google Cloud er et komplet, kamptestet miljø, som driver sin egen hardwareinfrastruktur hos Google til produkter som YouTube og Gmail.

GCP har vundet indpas hovedsageligt på grund af dens stadigt voksende liste over muligheder. Det tilbyder support til platforme som Visual Studio, Android Studio, Eclipse, Powershell og mange andre. GCP har et af de største og mest avancerede computernetværk, og det giver adgang til adskillige værktøjer, der hjælper dig med at fokusere på at bygge din applikation.

En anden ting, der tiltrækker kunder til at migrere, importere eller bruge Google Cloud, er deres stærke support og løsninger til containerisering. Kubernetes (GKE:Google Kubernetes Engine) er bygget på deres platform.

GCP har også for nylig lanceret en ny løsning kaldet Anthos. Dette produkt er designet til at give organisationer mulighed for at administrere arbejdsbelastninger ved hjælp af den samme grænseflade på Google Cloud Platform (GCP) eller on-premises ved hjælp af GKE On-Prem og endda på rivaliserende skyer såsom Amazon Web Services (AWS) eller Azure.

Ud over disse teknologier tilbyder GCP sofistikerede og kraftfulde, computeroptimerede maskintyper som C2-familien i GCE, der er bygget på den seneste generation af Intel Scalable Processorer (Cascade Lake).

GCP fortsætter også med at understøtte open source, hvilket gavner brugerne ved at levere en velunderstøttet og ligetil ramme, der gør det nemt at levere et endeligt produkt til tiden. På trods af denne understøttelse af open source-teknologi, giver GCP ikke indbygget support til implementering eller konfiguration af en MySQL Galera Cluster. I denne blog vil vi vise dig den eneste mulighed, der er tilgængelig for dig, hvis du ønsker at bruge denne teknologi, implementering via en computerinstans, som du selv skal administrere.

Google Compute Engine (GCE)

GCE har et sofistikeret og kraftfuldt sæt af beregningsknuder til rådighed for dit forbrug. I modsætning til AWS har GCE den mest kraftfulde computernode på markedet (n1-ultramem-160 med 160 vCPU og 3,75 TB hukommelse). GCE har også for nylig introduceret en ny type computerinstansfamilie kaldet C2-maskine-type. Bygget på den seneste generation af Intel-skalerbare processorer (Cascade Lake), tilbyder C2-maskinetyper op til 3,8 GHz vedvarende turbo med alle kerner og giver fuld gennemsigtighed i arkitekturen af ​​de underliggende serverplatforme; lader dig finjustere ydelsen. C2 maskintyper tilbyder meget mere computerkraft, kører på en nyere platform og er generelt mere robuste til computerintensive arbejdsbelastninger end N1 høj-CPU maskintyperne. C2 familietilbud er begrænsede (i skrivende stund), og det er ikke tilgængeligt i alle regioner og zoner. C2 understøtter heller ikke regionale persistente diske, selvom det ville være en fantastisk tilføjelse til stateful databasetjenester, der kræver redundans og høj tilgængelighed. Ressourcerne i en C2-instans er for store til en Galera-knude, så vi fokuserer i stedet på beregningsknuderne, som er ideelle.

GCE bruger også KVM som software til virtualiseringsteknologi, hvorimod Amazon bruger Xen. Lad os tage et kig på de tilgængelige beregningsknuder i GCE, som er egnede til at køre Galera sammen med dets ækvivalens i AWS EC2. Priserne varierer afhængigt af region, men for dette diagram bruger vi us-east region ved hjælp af on-demand prissætningstype for AWS.

Prisfastsættelse (Compute Instance, Disk, vCPU, Memory og Network)

Prisen afhænger også af den region, hvor den er placeret, typen af ​​OS eller licens (RHEL vs Suse Linux Enterprise), og også typen af ​​disklager, du bruger.

GCP tilbyder også rabatter, som giver dig mulighed for at spare på dit ressourceforbrug. For Compute Engine giver det forskellige rabatter at benytte.

Rabatter ved vedvarende brug gælder for følgende ressourcer:

• VCPU'erne og hukommelsen til brugerdefinerede og foruddefinerede maskintyper til generelle formål

• VCPU'erne og hukommelsen til hukommelsesoptimerede maskintyper

• VCPU'erne og hukommelsen til computeroptimerede maskintyper

• VCPU'erne og hukommelsen til noder med ene-lejer

• De 10 % præmieomkostninger for noder med ene-lejer, selvom vCPU'erne og hukommelsen i disse noder er dækket af rabatter på forpligtet brug

• GPU-enheder1

Bemærk, at rabatter ved vedvarende brug ikke gælder for VM'er, der er oprettet ved hjælp af App Engine Flexible Environment og Cloud Dataflow.

Du kan også bruge forpligtede brugsrabatter, når du køber en VMS, som er bundet til en kontrakt. Denne type valg er ideel til forudsigelige arbejdsbelastninger og ressourcebehov. Når du køber en kontrakt om forpligtet brug, køber du en vis mængde vCPU'er, hukommelse, GPU'er og lokale SSD'er til en nedsat pris til gengæld for at forpligte dig til at betale for disse ressourcer i 1 år eller 3 år. Rabatten er op til 57 % for de fleste ressourcer som maskintyper eller GPU'er. Rabatten er op til 70% for hukommelsesoptimerede maskintyper. Når du har købt det, faktureres du månedligt for de ressourcer, du har købt, i løbet af den periode, du har valgt (uanset om du bruger tjenesterne eller ej).

En udtagelig VM er en instans, som du kan oprette og køre til en meget lavere pris end normale instanser. Compute Engine kan dog afslutte (foregribe) disse tilfælde, hvis det kræver adgang til disse ressourcer til andre opgaver. Udskiftelige forekomster bruger overskydende Compute Engine-kapacitet, så deres tilgængelighed varierer med brugen.

Hvis dine applikationer er fejltolerante og kan modstå mulige instansforbedringer, kan kasserbare instanser reducere dine Compute Engine-omkostninger betydeligt. F.eks. kan batchbehandlingsjob køre på udskiftelige forekomster. Hvis nogle af disse tilfælde afsluttes under behandlingen, bliver jobbet langsommere, men stopper ikke helt. Udskiftelige forekomster fuldfører dine batchbehandlingsopgaver uden at lægge yderligere arbejdsbyrde på dine eksisterende forekomster og uden at kræve, at du betaler fuld pris for yderligere normale forekomster.

For Compute Engine beregnes diskstørrelse, maskintypehukommelse og netværksforbrug i gigabyte (GB), hvor 1 GB er 230 bytes. Denne måleenhed er også kendt som en gibibyte (GiB). Det betyder, at GCP tilbyder dig kun at betale ud fra det ressourceforbrug, du har afsat.

Nu, hvis du har en højkvalitets produktionsdatabaseapplikation, anbefales det (og ideelt) at vedhæfte eller tilføje en separat persistent disk. Du ville så bruge den disk som din databasevolumen, da den giver dig pålidelig og konsistent diskydeevne i GCE. Jo højere størrelse du opsætter, jo højere IOPS giver den dig. Tjek deres liste over vedvarende diskpriser for at bestemme prisen, du ville få. Ud over dette har GCE regional persistent disk, som er velegnet, hvis du har brug for mere solid og bæredygtig høj tilgængelighed i din databaseklynge. Regional persistent disk tilføjer mere redundans i tilfælde af, at din instans afsluttes eller går ned eller bliver beskadiget. Det giver synkron replikering af data mellem to zoner i én region, hvilket sker gennemsigtigt i VM-instansen. I det usandsynlige tilfælde af zonefejl kan din arbejdsbyrde overgå til en anden VM-instans i den samme eller en sekundær zone. Du kan derefter tvinge din regionale persistente disk til den instans. Tvungen vedhæftningstid er estimeret på mindre end et minut.

Hvis du gemmer sikkerhedskopier som en del af din disaster recovery-løsning og kræver en volumen, der er klyngedækkende, tilbyder GCP Cloud Filestore, NetApp Cloud Volumes og nogle andre alternative fildelingsløsninger. Disse er fuldt administrerede tjenester, der tilbyder standard- og premiumtjenester. Du kan tjekke NetApps prisside her og Filestore-priser her.

Galera-kryptering på GCP

GCP inkluderer ikke specifik understøttelse af den krypteringstype, der er tilgængelig for Galera. GCP krypterer dog som standard kundedata, der er gemt i hvile, uden yderligere handling fra dig. GCP tilbyder også en anden mulighed for at kryptere dine data ved hjælp af kundeadministrerede krypteringsnøgler (CMEK) med Cloud KMS såvel som med kundeleverede krypteringsnøgler (CSEK). GCP bruger også SSL/TLS-kryptering til al kommunikation, der opfanges, når data flyttes mellem dit websted og cloud-udbyderen eller mellem to tjenester. Denne beskyttelse opnås ved at kryptere dataene før transmission; autentificering af slutpunkterne; og dekryptering og verificering af data ved ankomst.

Fordi Galera bruger MySQL under motorhjelmen (Percona, MariaDB eller Codership build), kan du drage fordel af File Key Management Encryption Plugin fra MariaDB eller ved at bruge MySQL Keyring plugins. Her er en ekstern blog af Percona, som er en god ressource til, hvordan du kan implementere dette.

Galera Cluster Multi-AZ/Multi-Region/Multi-Cloud-implementeringer med GCP

I lighed med AWS tilbyder GCP ikke direkte support til at implementere en Galera-klynge på en Multi-AZ/-Region/-Cloud.

Galera Cluster høj tilgængelighed, skalerbarhed og redundans på GCP

En af de primære grunde til at bruge en Galera-nodeklynge er høj tilgængelighed, redundans og dets evne til at skalere. Hvis du betjener trafik globalt, er det bedst, at du imødekommer din trafik baseret på regioner med dit arkitektoniske design, herunder en geo-fordeling af dine databasenoder. For at opnå dette er implementering af multi-AZ og multi-region eller multi-cloud/multi-datacenter anbefalelsesværdig og opnåelig. Dette forhindrer klyngen i at gå ned eller en klyngefejl på grund af manglende kvorum.

For at hjælpe dig mere med dit skalerbarhedsdesign har GCP også en autoskalering, du kan konfigurere med en autoskaleringsgruppe. Dette vil fungere, så længe du har oprettet din klynge som administrerede forekomstgrupper. For eksempel kan du overvåge CPU-udnyttelsen eller stole på metrics fra Stackdriver, der er defineret i din autoskaleringspolitik. Dette giver dig mulighed for at klargøre og automatisere forekomster, når en bestemt tærskel er nået, eller afslutte forekomsterne, når den går tilbage til sin normale tilstand.

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. Dette inkluderer skrivesæt-relæ og IST- og SST-donorudvælgelse. Denne type opsætning giver dig mulighed for at implementere flere noder i forskellige regioner. Bortset fra det kan du også implementere dine Galera-noder på en anden cloud-leverandør-routing fra GCP, AWS, Microsoft Azure eller inden for det lokale område.

Vi anbefaler, at du tjekker 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 mere information om, hvordan man implementerer disse typer af implementeringer.

Galera Cluster Database Performance på GCP

Da der ikke er nogen tilgængelig support til Galera i GCP, afhænger dine valg af kravene og designet af din applikations trafik- og ressourcebehov. For forespørgsler, der har et højt hukommelsesforbrug, kan du starte med n1-highmem-2-instans. Høje CPU-instanser (n1-highcpu*-familien) kan passe godt, hvis dette er en højtransaktionsbaseret database eller passer godt til spilapplikationer.

Valg af det rigtige lager og påkrævet IOPS til din databasevolumen er et must. Generelt er SSD-baseret persistent disk dit valg her. Det afhænger af mængden af ​​trafik, der kræves. Du skal muligvis tjekke GCP-lagringsmulighederne, så du kan bestemme den rigtige størrelse til din applikation.

Vi anbefaler også, at du tjekker og læser vores blog Sådan forbedrer du ydeevnen af ​​Galera Cluster til MySQL eller MariaDB for at lære mere om optimering af din Galera Cluster.

Galera Data Backups på GCP

Ikke kun skal dine MySQL Galera-data sikkerhedskopieres, du bør også sikkerhedskopiere hele niveauet, som omfatter din databaseapplikation. Dette inkluderer logfiler (logiske eller binære), eksterne filer, midlertidige filer, dumpfiler osv. Google anbefaler, at du altid opretter et øjebliksbillede af dine persistente diskvolumener, som bliver brugt af dine GCE-forekomster. Du kan nemt oprette og planlægge snapshots. GCP Snapshots gemmes i Cloud Storage, og du kan vælge din ønskede placering eller region, hvor sikkerhedskopien vil blive placeret. Du kan også konfigurere en tidsplan for dine snapshots samt indstille en snapshot-opbevaringspolitik.

Du kan også bruge eksterne tjenester som ClusterControl, som giver dig både overvågnings- og backupløsninger. Tjek dette ud, hvis du vil vide mere.

Galera Cluster Database Monitoring på GCP

GCP tilbyder ikke databaseovervågning ved brug af GCE. Overvågning af din instanstilstand kan udføres gennem Stackdriver. Til databasen skal du dog have fat i et eksternt overvågningsværktøj, som har avancerede, meget granulære databasemetrikker. Der er mange valgmuligheder, du kan vælge imellem, såsom PMM af Percona, DataDog, Idera, VividCortex eller vores helt egen ClusterControl (overvågning er GRATIS med ClusterControl Community.)

Galera Cluster Database Security på GCP

Som diskuteret i vores tidligere blog, kan du bruge den samme tilgang til at sikre din database i den offentlige sky. I GCP kan du opsætte et privat undernet, firewall-regler til kun at tillade de porte, der kræves for at køre Galera (især porte 3306, 4444, 4567, 4568). Du kan bruge NAT Gateway eller konfigurere en bastion-vært for at få adgang til dine private databasenoder. Når disse noder er indkapslet, kan de ikke tilgås fra ydersiden af ​​GCP-lokalerne. Du kan læse vores tidligere blog Deploying Secure Multicloud MySQL Replication på AWS og GCP med VPN om, hvordan vi sætter dette op.

Udover dette kan du sikre dine data under transport ved at bruge en TLS/SSL-forbindelse eller ved at 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 du følge diskussionen, som jeg tidligere har nævnt i afsnittet Kryptering på denne blog.

Galera Cluster Fejlfinding 

GCP tilbyder Stackdriver Logging, som du kan bruge til at hjælpe dig med observerbarhed, overvågning og underretningskrav. Det fantastiske ved Stackdriver Logging er, at det tilbyder integration med AWS. Med den kan du fange begivenhederne selektivt og derefter lave en alarm baseret på den begivenhed. Dette kan holde dig orienteret om visse problemer, der kan opstå, og hjælpe dig under fejlfinding. GCP har også Cloud Audit Logs, som giver dig mere sporbar information inde fra GCP-miljøet, fra administratoraktivitet, dataadgang og systemhændelser.

Hvis du bruger ClusterControl, skal du gå til Logs -> System Logs, og du vil 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

Google Cloud Platform tilbyder en bred vifte af effektive og kraftfulde tjenester, som du kan udnytte. Der er faktisk fordele og ulemper ved hver af de offentlige cloud-platforme, men GCP beviser, at AWS ikke har en lås på skyen.

Det er interessant, at store virksomheder som Vimeo flytter til GCP fra on-premise, og de oplevede nogle interessante resultater i deres teknologistack. Bloomberg er også tilfreds med GCP og bruger Percona XtraDB Cluster (en Galera-variant). Fortæl os, hvad du synes om at bruge GCP til MySQL Galera-opsætninger i kommentarerne nedenfor.