Ett hybridmoln avser en blandad dator-, lagrings- och tjänstemiljö som består av lokal infrastruktur, privata molntjänster och en offentlig molnorkestrering mellan de olika plattformarna. Att använda en kombination av offentliga moln, lokal datoranvändning och privata moln i ditt datacenter innebär att du har en hybrid molninfrastruktur.
Prestandan har vanligtvis lägre prioritet i ett hybridmoln, eftersom fokus för att ha hybridmolninfrastruktur vanligtvis ligger på katastrofåterställning, tillgänglighet och skalbarhet. I det här blogginlägget kommer vi att täcka några allmänna tips för att driva prestandan för våra applikationer, arbetsbelastningar och kluster som körs på en hybrid molnkonfiguration.
Dedikerade värdar/instanser/resurser
Kostnaden för molntjänster påstås vara lägre på grund av den omfattande resursdelningen. En högre grad av delning skulle dock automatiskt innebära färre garantier för prestanda.
Molninstanser är benägna att få oförutsägbar stabilitet men med vissa extra kostnader kan vi minska denna risk med dedikerade resurser. Dedikerade instanser är instanser som körs på hårdvara som är dedikerad till en enda klient. Vanligtvis är de dedikerade värdarna eller instanserna fysiskt isolerade på värdhårdvarunivån från instanser som tillhör andra hyresgäster. Detta kommer att garantera tillräckliga resurser till tjänsten och praktiskt taget stabilisera prestandan för dina arbetsbelastningar på lång sikt. Beroende på din budget har du flera alternativ för dedikerade resurser som dedikerade värdar, instanser eller bandbredd.
Det finns också många erbjudanden och rabatter om du planerar att köra instanserna under en längre period. Genom att till exempel förbinda sig till AWS EC2 Reserve Instance kan användare spara upp till 70 % av instanskostnaden jämfört med standardkostnaden på begäran. När applikationerna eller arbetsbelastningarna är testade och redo för produktion, rekommenderas det starkt att du väljer ett långsiktigt kontrakt förutsatt att du allokerar tillräckligt med resurser till instansen för just den kontraktsperioden.
Bandbreddshantering
Bandbredd är dyrt. Det som är dyrt är infrastrukturen för att transportera bandbredden från en plats till en annan. Utläggningsfibern, routinghårdvara av leverantörsgrad och leverantörsgrad, övervaknings- och underhållskostnader för att hålla det hela igång, uthyrning av datacentersviter, bemanning av en 24/7 Network Operation Center (NOC) ingenjör, bidrar alla till det höga priset för en pålitlig bandbredd. För att inte tala om takten i tekniken, användarnas krav och leverantörens produktlivslängder kräver ofta att en stor del av ovanstående investering kastas bort och livscykel vart 7:e till 10:e år, i vissa fall vart 5:e år.
Det mesta av det offentliga molnet tillåter datautbyte med andra molntjänsteleverantörer (CSP), vilket kan uppnås på flera sätt:
-
Överföring av data via offentliga IP-adresser över internet.
-
Använda en hanterad VPN-tjänst mellan det lokala nätverket och CSP-nätverket.
-
Anslut direkt från det lokala nätverket eller privata molnnätverk med den andra CSP som Partner Interconnect för Google Cloud eller AWS Direct Connect för AWS.
-
Överför data till den andra CSP:n via en gemensam närvaropunkt (POP).
-
Peering i nätverk med privata molnnätverk och CSP-nätverket.
Dessa alternativ skiljer sig åt när det gäller överföringshastighet, latens, tillförlitlighet, servicenivåavtal (SLA), komplexitet och kostnader. Oavsett alternativ är tanken densamma - ju mindre dataöverföring som används, desto lägre kostar det.
För att minska bandbreddsanvändningen är komprimering det viktigaste vi bör göra. De flesta av replikeringstjänsterna stöder nu anslutningskomprimering, vilket avsevärt kan minska storleken på dataöverföringen mellan flera platser. Att till exempel aktivera anslutningskomprimering för MySQL master-slave kan enkelt minska bandbreddsanvändningen ner till 1,5x, utan ytterligare konfiguration på komprimeringsnivån eller algoritmen. Detta kallas för förlustfri datakomprimeringsteknik. Du kan ställa in ett ännu högre kompressionsförhållande, med en avvägning av processorkraft för komprimering och dekompression på båda slutpunkterna.
Arbetsbelastningsplaceringen är också viktig. Med hybridmolnkonfiguration kan applikationer och arbetsbelastningar finnas på både privata eller offentliga moln. För interna applikationer är det mycket bättre att placera dem i det privata molnet närmare de lokala med lägre nätverkslatens. För att förbättra prestanda för offentliga applikationer, placera applikationerna på kantservrarna för Content Delivery Network (CDN), vilket avsevärt kommer att minska bördan för huvudservern att endast hantera den dynamiska begäran och avlasta den statiska innehållsleveransen till flera edge-servrar, som geografiskt ligger närmare slutanvändarna.
Snabbare kryptering
Kryptering under transport och vila är obligatoriskt i en hybridmolninstallation eftersom vi bara äger en bråkdel av infrastrukturen. Vi vill inte att nyfikna ögon ska titta på vår data medan den överförs, eller risken för dataintrång från stöld eller utomstående som har fysisk tillgång till vår data. Med enkla ord måste varje del av att flytta data eller icke-fysiskt tillgänglig data vara krypterad, punkt. Vissa krypteringschiffer kan dock äventyra hastigheten och prestanda för arbetsbelastningarna.
En vanlig felaktighet är att anta att ett meddelande krypterat med AES256 är svårare att knäcka än samma information som skyddas med AES128. Det är logiskt logiskt att en större nyckelstorlek introducerar större komplexitet, men som med alla system är implementeringar föremål för svagheter. Om vi antar att vi talar om AES128 kontra AES256, finns det en känd svaghet i nyckelexpansionsfunktionen som påverkar AES256. I grund och botten reducerar svagheten komplexiteten hos AES256 till den lägre än AES128.
Några av tunnlingsverktygen som WireGuard är välkända för sin snabbare kryptering och ganska enkla att implementera när man tunnlar mellan flera platser. Det fungerar på samma sätt som SSH-kryptering, med hjälp av en asymmetrisk kryptografi. Enligt denna forskning är WireGuard i genomsnitt 58 % snabbare än OpenVPN på alla testade platser. Snabbare kryptering innebär mindre tid att kryptera och dekryptera data, vilket gör att ditt datautbyte kan öka avsevärt.
Om du undrar hur du ställer in WireGuard VPN för en hybridmolnmiljö, kolla in det här blogginlägget, Multi-Cloud Deployment for MariaDB Replication Using WireGuard.
Övervaka allt
Molnbaserade miljöer är beroende av en komplicerad uppsättning resurser och det är en utmaning att identifiera de tillgänglighets- och prestandaproblem som mest påverkar företagstjänster. Driftsteamet måste kunna övervaka applikationshälsan på ett holistiskt sätt inklusive de medföljande molninfrastrukturkomponenterna.
Prestandaförbättringen på ett hybridmoln kan inte ske utan bred insyn i alla resurser hela tiden. Resurser som instans- och nätverksanvändning, applikationsprestanda, användarupplevelse, latens och loggfiler är mycket viktiga att samlas in och ta prov för att säkerställa att vi proaktivt kan felsöka prestanda- och tillgänglighetsproblem innan de når slutanvändare eller blir värre. Felallokering av resurser kommer alltid att ske i en dålig leveransmiljö, vilket så småningom leder till dålig kapacitetsplanering och slöseri med pengar och resurser.
De flesta offentliga molnleverantörer erbjuder djupgående övervakningstjänster som täcker flera lager och komponenter i de prenumererade molntjänsterna. Den saknade biten är dock vanligtvis en övervakningsenhet mellan olika molnplattformar, leverantörer och miljöer. Öppen källkod allt-i-ett-övervakningsverktyg som Icinga, Nagios Core och Zabbix kan konfigureras för att övervaka nästan allt som är involverat i ett hybridmoln, särskilt molninstanser, nätverk, tjänster och applikationer.
I fallet med prestandaövervakning för databasservrar i hybridmolnmiljön kan följande resurser hjälpa:
-
Övervaka MariaDB-prestanda i ett hybridmoln
-
Övervaka PostgreSQL i en hybridmiljö