Jämföra Galera Cluster Cloud-erbjudanden:Del två Google Cloud Platform (GCP)

I vår förra blogg diskuterade vi de erbjudanden som är tillgängliga inom Amazon Web Services (AWS) när vi kör ett MySQL Galera Cluster. I den här bloggen kommer vi att fortsätta diskussionen genom att titta vidare på vad erbjudandena är för att köra samma klustringsteknik, men den här gången på Google Cloud Platform (GCP).

GCP, som ett alternativ till AWS, har kontinuerligt attraherat applikationer som är lämpade för DevOps genom att erbjuda stöd för ett brett utbud av full-stack-teknologier, containeriserade applikationer och stora produktionsdatabassystem. Google Cloud är en komplett, stridstestad miljö som driver sin egen hårdvaruinfrastruktur hos Google för produkter som YouTube och Gmail.

GCP har vunnit dragkraft till stor del på grund av dess ständigt växande lista med funktioner. Det erbjuder stöd för plattformar som Visual Studio, Android Studio, Eclipse, Powershell och många andra. GCP har ett av de största och mest avancerade datornätverken och det ger tillgång till många verktyg som hjälper dig att fokusera på att bygga din applikation.

En annan sak som lockar kunder att migrera, importera eller använda Google Cloud är deras starka stöd och lösningar för containerisering. Kubernetes (GKE:Google Kubernetes Engine) är byggd på deras plattform.

GCP har också nyligen lanserat en ny lösning som heter Anthos. Den här produkten är utformad för att låta organisationer hantera arbetsbelastningar med samma gränssnitt på Google Cloud Platform (GCP) eller lokalt med GKE On-Prem, och även på rivaliserande moln som Amazon Web Services (AWS) eller Azure.

Utöver dessa teknologier erbjuder GCP sofistikerade och kraftfulla, beräkningsoptimerade maskintyper som C2-familjen i GCE som är byggd på den senaste generationen Intel Scalable-processorer (Cascade Lake).

GCP fortsätter också att stödja öppen källkod, vilket gynnar användarna genom att tillhandahålla välstödda och enkla ramar som gör det enkelt att leverera en slutprodukt i tid. Trots detta stöd för teknik med öppen källkod, tillhandahåller inte GCP inbyggt stöd för distribution eller konfiguration av ett MySQL Galera-kluster. I den här bloggen kommer vi att visa dig det enda alternativet som är tillgängligt för dig om du vill använda den här tekniken, distribution via en beräkningsinstans som du måste hantera själv.

Google Compute Engine (GCE)

GCE har en sofistikerad och kraftfull uppsättning beräkningsnoder tillgängliga för din konsumtion. Till skillnad från AWS har GCE den mest kraftfulla beräkningsnoden som finns på marknaden (n1-ultramem-160 med 160 vCPU och 3,75 TB minne). GCE introducerade nyligen också en ny typ av beräkningsinstansfamilj kallad C2-maskintyp. Byggd på den senaste generationen av skalbara Intel-processorer (Cascade Lake), erbjuder C2-maskintyper upp till 3,8 GHz ihållande turbo med alla kärnor och ger full insyn i arkitekturen för de underliggande serverplattformarna; låter dig finjustera prestandan. C2-maskintyper erbjuder mycket mer datorkraft, körs på en nyare plattform och är i allmänhet mer robusta för datorintensiva arbetsbelastningar än N1-maskintyperna med hög CPU. C2 familjeerbjudanden är begränsade (i skrivande stund) och det är inte tillgängligt i alla regioner och zoner. C2 stöder inte heller regionala beständiga diskar även om det skulle vara ett bra tillägg för stateful databastjänster som kräver redundans och hög tillgänglighet. Resurserna i en C2-instans är för mycket för en Galera-nod, så vi fokuserar istället på beräkningsnoderna, som är idealiska.

GCE använder också KVM som programvara för virtualiseringsteknologi, medan Amazon använder Xen. Låt oss ta en titt på beräkningsnoderna som finns tillgängliga i GCE som är lämpliga för att köra Galera tillsammans med dess ekvivalens i AWS EC2. Priserna varierar beroende på region, men för det här diagrammet använder vi oss-östra regionen med prissättning på begäran för AWS.

Priser (datorinstans, disk, vCPU, minne och nätverk)

Priset beror också på regionen där den finns, typen av operativsystem eller licensiering (RHEL vs Suse Linux Enterprise), och även vilken typ av disklagring du använder.

GCP erbjuder även rabatter som gör att du kan spara på din resursförbrukning. För Compute Engine ger det olika rabatter att utnyttja.

Rabatter för uthållig användning gäller för följande resurser:

• VCPU:erna och minnet för allmänna anpassade och fördefinierade maskintyper

• VCPU:erna och minnet för minnesoptimerade maskintyper

• VCPU:erna och minnet för datoroptimerade maskintyper

• VCPU:erna och minnet för noder för ensamhyresgäster

• Premiumkostnaden på 10 % för noder för ensamhyresgäster, även om vCPU:erna och minnet i dessa noder täcks av rabatter för engagerad användning

• GPU-enheter1

Observera att rabatter för långvarig användning inte gäller virtuella datorer som skapats med App Engine Flexible Environment och Cloud Dataflow.

Du kan också använda rabatter för engagerad användning när du köper ett VMS som är bundet till ett kontrakt. Denna typ av val är idealisk för förutsägbara arbetsbelastningar och resursbehov. När du köper ett avtal om engagerad användning köper du en viss mängd vCPU:er, minne, GPU:er och lokala SSD:er till ett rabatterat pris i utbyte mot att du förbinder dig att betala för dessa resurser under 1 eller 3 år. Rabatten är upp till 57 % för de flesta resurser som maskintyper eller GPU:er. Rabatten är upp till 70 % för minnesoptimerade maskintyper. När du har köpt den faktureras du månadsvis för de resurser du köpt under den period du valt (oavsett om du använder tjänsterna eller inte).

En undanträngbar virtuell dator är en instans som du kan skapa och köra till ett mycket lägre pris än vanliga instanser. Compute Engine kan dock avsluta (förebygga) dessa instanser om den kräver åtkomst till dessa resurser för andra uppgifter. Undantagbara instanser använder överskott av Compute Engine-kapacitet, så deras tillgänglighet varierar med användning.

Om dina applikationer är feltoleranta och kan motstå möjliga instansförhandsavgöranden, kan utgångsbara instanser minska dina Compute Engine-kostnader avsevärt. Till exempel kan batchbearbetningsjobb köras på undanträngbara instanser. Om några av dessa instanser avslutas under bearbetningen saktar jobbet ner men stoppas inte helt. Undantagbara instanser slutför dina batchbearbetningsuppgifter utan att lägga ytterligare arbetsbelastning på dina befintliga instanser och utan att du behöver betala fullt pris för ytterligare normala instanser.

För Compute Engine beräknas diskstorlek, maskintypsminne och nätverksanvändning i gigabyte (GB), där 1 GB är 230 byte. Denna måttenhet är också känd som en gibibyte (GiB). Det innebär att GCP erbjuder dig att endast betala baserat på den resursförbrukning du har allokerat.

Nu, om du har en högkvalitativ produktionsdatabasapplikation, är det att rekommendera (och idealiskt) att bifoga eller lägga till en separat beständig disk. Du skulle då använda den disken som din databasvolym, eftersom den ger dig pålitlig och konsekvent diskprestanda i GCE. Ju högre storlek du ställer in, desto högre IOPS erbjuder den dig. Kolla in deras lista över prissättning för beständiga diskar för att bestämma priset du skulle få. Utöver detta har GCE regional persistent disk som är lämplig om du behöver mer solid och hållbar hög tillgänglighet inom ditt databaskluster. Regional persistent disk lägger till mer redundans om din instans avslutas eller kraschar eller blir skadad. Det ger synkron replikering av data mellan två zoner i en region, vilket sker transparent i VM-instansen. I den osannolika händelsen av zonfel kan din arbetsbelastning övergå till en annan VM-instans i samma, eller en sekundär, zon. Du kan sedan tvinga din regionala beständiga disk till den instansen. Tvingad fastsättningstiden beräknas på mindre än en minut.

Om du lagrar säkerhetskopior som en del av din katastrofåterställningslösning och kräver en volym som är klusteromfattande, erbjuder GCP Cloud Filestore, NetApp Cloud Volumes och några andra alternativa fildelningslösningar. Dessa är helt hanterade tjänster som erbjuder standard- och premiumtjänster. Du kan kolla in NetApps prissida här och Filestores prissättning här.

Galera-kryptering på GCP

GCP inkluderar inte specifikt stöd för den typ av kryptering som är tillgänglig för Galera. GCP krypterar dock kunddata som lagras i vila som standard, utan att du behöver göra någon ytterligare åtgärd. GCP erbjuder också ett annat alternativ för att kryptera dina data med hjälp av kundhanterade krypteringsnycklar (CMEK) med Cloud KMS såväl som med Customer-supplied krypteringsnycklar (CSEK). GCP använder också SSL/TLS-kryptering för all kommunikation som fångas upp när data flyttas mellan din webbplats och molnleverantören eller mellan två tjänster. Detta skydd uppnås genom att kryptera data före överföring; autentisera ändpunkterna; och dekryptera och verifiera data vid ankomst.

Eftersom Galera använder MySQL under huven (Percona, MariaDB eller Codership build), kan du dra fördel av File Key Management Encryption Plugin från MariaDB eller genom att använda MySQL Keyring-plugins. Här är en extern blogg av Percona som är en bra resurs om hur du kan implementera detta.

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

I likhet med AWS erbjuder GCP inte direkt stöd för att distribuera ett Galera-kluster på ett Multi-AZ/-Region/-Cloud.

Galera Cluster High Availability, Scalability och Redundans på GCP

En av de främsta anledningarna till att använda ett Galera-nodkluster är hög tillgänglighet, redundans och dess förmåga att skala. Om du betjänar trafik globalt är det bäst att du tillgodoser din trafik baserat på regioner med din arkitektoniska design inklusive en geo-distribution av dina databasnoder. För att uppnå detta rekommenderas och genomförbar implementering av multi-AZ och multi-region eller multi-cloud/multi-datacenter. Detta förhindrar att klustret går ner eller ett klusterfel på grund av brist på beslutförhet.

För att hjälpa dig mer med din skalbarhetsdesign har GCP också en autoskalare som du kan ställa in med en autoskalningsgrupp. Detta kommer att fungera så länge du skapade ditt kluster som hanterade instansgrupper. Du kan till exempel övervaka CPU-användningen eller lita på statistiken från Stackdriver som definieras i din autoskalningspolicy. Detta låter dig tillhandahålla och automatisera instanser när en viss tröskel har nåtts, eller avsluta instanserna när den går tillbaka till sitt normala tillstånd.

För distribution i flera regioner eller flera moln har Galera sin egen parameter som heter gmcast.segment som du kan ställa in för vid serverstart. Denna parameter är utformad för att optimera kommunikationen mellan Galera-noderna och minimera mängden trafik som skickas mellan nätverkssegment. Detta inkluderar förmedling av skrivuppsättningar och val av IST- och SST-givare. Den här typen av inställningar låter dig distribuera flera noder i olika regioner. Bortsett från det kan du också distribuera dina Galera-noder på en annan routing från molnleverantörer från GCP, AWS, Microsoft Azure eller på plats.

Vi rekommenderar att du kollar in vår blogg Multiple Data Center Setups Using Galera Cluster for MySQL eller MariaDB and Zero Downtime Network Migration With MySQL Galera Cluster Using Relay Node för att samla mer information om hur man implementerar dessa typer av distributioner.

Galera Cluster Database Performance on GCP

Eftersom det inte finns något tillgängligt stöd för Galera i GCP beror dina val på kraven och utformningen av din applikations trafik- och resursbehov. För frågor som har hög minnesförbrukning kan du börja med n1-highmem-2-instans. Höga CPU-instanser (n1-highcpu*-familjen) kan passa bra om det här är en databas med höga transaktioner eller en bra passform för spelapplikationer.

Att välja rätt lagring och nödvändig IOPS för din databasvolym är ett måste. I allmänhet är SSD-baserad beständig disk ditt val här. Det beror på mängden trafik som krävs, du kanske måste kolla in GCP-lagringsalternativen så att du kan bestämma rätt storlek för din applikation.

Vi rekommenderar också att du kollar och läser vår blogg How to Improve Performance of Galera Cluster for MySQL eller MariaDB för att lära dig mer om hur du optimerar ditt Galera Cluster.

Galera Data Backups på GCP

Inte bara måste din MySQL Galera-data säkerhetskopieras, du bör också säkerhetskopiera hela nivån som omfattar din databasapplikation. Detta inkluderar loggfiler (logiska eller binära), externa filer, temporära filer, dumpfiler etc. Google rekommenderar att du alltid skapar en ögonblicksbild av dina beständiga diskvolymer som används av dina GCE-instanser. Du kan enkelt skapa och schemalägga ögonblicksbilder. GCP-ögonblicksbilder lagras i Cloud Storage och du kan välja önskad plats eller region där säkerhetskopian ska placeras. Du kan också ställa in ett schema för dina ögonblicksbilder samt ställa in en lagringspolicy för ögonblicksbilder.

Du kan också använda externa tjänster som ClusterControl, som ger dig både övervaknings- och säkerhetskopieringslösningar. Kolla in det här om du vill veta mer.

Galera Cluster Database Monitoring on GCP

GCP erbjuder inte databasövervakning när du använder GCE. Övervakning av din instanshälsa kan göras genom Stackdriver. För databasen måste du dock ta tag i ett externt övervakningsverktyg som har avancerade, mycket granulära databasmått. Det finns många val du kan välja mellan såsom PMM av Percona, DataDog, Idera, VividCortex eller vår alldeles egna ClusterControl (övervakning är GRATIS med ClusterControl Community.)

Galera Cluster Database Security på GCP

Som diskuterades i vår tidigare blogg kan du använda samma tillvägagångssätt för att säkra din databas i det offentliga molnet. I GCP kan du ställa in ett privat undernät, brandväggsregler för att endast tillåta de portar som krävs för att köra Galera (särskilt portarna 3306, 4444, 4567, 4568). Du kan använda NAT Gateway eller ställa in en bastionvärd för att komma åt dina privata databasnoder. När dessa noder är inkapslade kan de inte nås från utsidan av GCP:s lokaler. Du kan läsa vår tidigare blogg Deploying Secure Multicloud MySQL Replication på AWS och GCP med VPN om hur vi ställer in detta.

Utöver detta kan du säkra din data under transport genom att använda en TLS/SSL-anslutning eller genom att kryptera din data när den är i vila. Om du använder ClusterControl är det enkelt och enkelt att distribuera en säker dataöverföring. Du kan kolla in vår blogg SSL Key Management and Encryption of MySQL Data in Transit om du vill testa. För data i vila kan du följa diskussionen som jag har nämnt tidigare i avsnittet Kryptering av den här bloggen.

Galera Cluster Felsökning 

GCP erbjuder Stackdriver Logging som du kan använda för att hjälpa dig med observerbarhet, övervakning och aviseringskrav. Det fantastiska med Stackdriver Logging är att det erbjuder integration med AWS. Med den kan du fånga händelserna selektivt och sedan aktivera en varning baserat på den händelsen. Detta kan hålla dig uppdaterad om vissa problem som kan uppstå och hjälpa dig under felsökning. GCP har också Cloud Audit Logs som ger dig mer spårbar information inifrån GCP-miljön, från administratörsaktivitet, dataåtkomst och systemhändelser.

Om du använder ClusterControl, gå till Loggar -> Systemloggar, och du kommer att kunna bläddra i de fångade felloggarna som tagits från själva MySQL Galera-noden. Bortsett från detta tillhandahåller ClusterControl realtidsövervakning som skulle förstärka ditt larm- och aviseringssystem i händelse av en nödsituation eller om din MySQL Galera-nod(er) är kaput.

Slutsats

Google Cloud Platform erbjuder ett brett utbud av effektiva och kraftfulla tjänster som du kan dra nytta av. Det finns verkligen för- och nackdelar för var och en av de offentliga molnplattformarna, men GCP bevisar att AWS inte har ett lås på molnet.

Det är intressant att stora företag som Vimeo flyttar till GCP från on-premise och de upplevde några intressanta resultat i sin teknologistack. Bloomberg är också nöjd med GCP och använder Percona XtraDB Cluster (en Galera-variant). Berätta för oss vad du tycker om att använda GCP för MySQL Galera-inställningar i kommentarerna nedan.