Köra Apache Cassandra på virtuella Azure-datorer
I den här artikeln beskrivs prestandaöverväganden för att köra Apache Cassandra på virtuella Azure-datorer.
Dessa rekommendationer baseras på resultatet av prestandatester, som du hittar på GitHub. Du bör använda dessa rekommendationer som baslinje och sedan testa mot din egen arbetsbelastning.
Azure Managed Instance för Apache Cassandra
Om du letar efter en mer automatiserad tjänst för att köra Apache Cassandra på virtuella Azure-datorer kan du överväga att använda Azure Managed Instance för Apache Cassandra. Den här tjänsten automatiserar distribution, hantering (uppdatering och nodhälsa) och skalning av noder i ett Apache Cassandra-kluster. Det ger också funktioner för hybridkluster, så Att Apache Cassandra-datacenter som distribueras i Azure kan ansluta till en befintlig lokal eller värdbaserad Cassandra-ring från tredje part. Tjänsten distribueras med hjälp av skalningsuppsättningar för virtuella Azure-datorer. Följande rekommendationer godkändes under utvecklingen av den här tjänsten.
Storlekar och disktyper för virtuella Azure-datorer
Cassandra-arbetsbelastningar i Azure använder ofta antingen Standard_DS14_v2 eller Standard_DS13_v2 virtuella datorer. Cassandra-arbetsbelastningar drar nytta av att ha mer minne på den virtuella datorn, så överväg minnesoptimerade storlekar för virtuella datorer, till exempel Standard_DS14_v2 eller storlekar som är optimerade för lokal lagring, till exempel Standard_L16s_v2.
För hållbarhet lagras data och genomförandeloggar vanligtvis på en stripe-uppsättning med två till fyra premium-hanterade diskar på 1 TB (P30).
Cassandra-noder bör inte vara för datat kompakta. Vi rekommenderar att du har högst 1–2 TB data per virtuell dator och tillräckligt med ledigt utrymme för komprimering. För att uppnå högsta möjliga kombinerade dataflöde och IOPS med premium-hanterade diskar rekommenderar vi att du skapar en stripe-uppsättning från några få diskar på 1 TB i stället för att använda en enda disk på 2 TB eller 4 TB. På en virtuell DS14_v2-dator har till exempel fyra 1 TB-diskar en maximal IOPS på 4 × 5000 = 20 K, jämfört med 7,5 K för en enskild disk på 4 TB.
När Azure Ultradiskar blir mer tillgängligt i olika regioner bör du utvärdera dem för Cassandra-arbetsbelastningar som behöver mindre diskkapacitet. De kan ge högre IOPS/dataflöde och kortare svarstider för VM-storlekar som Standard_D32s_v3 och Standard_D16s_v3.
För Cassandra-arbetsbelastningar som inte behöver beständig lagring – det vill säga där data enkelt kan rekonstrueras från ett annat lagringsmedium – bör du överväga att använda Standard_L32s_v2eller Standard_L16s_v2 virtuella datorer. Dessa vm-storlekar har stora och snabba lokala tillfälliga NVMe-diskar.
Mer information finns i Jämföra prestanda för lokala/tillfälliga Azure-diskar jämfört med anslutna/beständiga diskar (GitHub).
Accelererat nätverk
Cassandra-noder använder nätverket mycket för att skicka och ta emot data från den virtuella klientdatorn och för att kommunicera mellan noder för replikering. För optimala prestanda kan virtuella Cassandra-datorer dra nytta av nätverk med högt dataflöde och korta svarstider.
Vi rekommenderar att du aktiverar accelererat nätverk på nätverkskortet för Cassandra-noden och på virtuella datorer som kör klientprogram som har åtkomst till Cassandra.
Accelererat nätverk kräver en modern Linux-distribution med de senaste drivrutinerna, till exempel Cent OS 7.5+ eller Ubuntu 16.x/18.x. Mer information finns i Skapa en virtuell Linux-dator med accelererat nätverk.
Cachelagring av datadiskar på virtuella Azure-datorer
Cassandra-läsarbetsbelastningar presterar bäst när svarstiden för diskar med slumpmässig åtkomst är låg. Vi rekommenderar att du använder Azure-hanterade diskar med ReadOnly-cachelagring aktiverat. ReadOnly-cachelagring ger kortare genomsnittlig svarstid eftersom data läses från cachen på värden i stället för att gå till backend-lagringen.
Läsintensiva, slumpmässiga läsarbetsbelastningar som Cassandra drar nytta av den lägre läsfördröjningen även om cachelagrat läge har lägre dataflödesgränser än läget för icke-frånkopplade. (Till exempel DS14_v2 virtuella datorer har ett maximalt cachelagrat dataflöde på 512 MB/s jämfört med 768 MB/s.
Skrivskyddad cachelagring är särskilt användbart för Cassandra-tidsserier och andra arbetsbelastningar där den fungerande datauppsättningen får plats i värdcachen och data inte hela tiden skrivs över. Till exempel DS14_v2 en cachestorlek på 512 GB, vilket kan lagra upp till 50 % av data från en Cassandra-nod med 1–2 TB datadensitet.
Det finns ingen betydande prestandaförseelse från cachemissar när ReadOnly-cachelagring är aktiverat, så cachelagrat läge rekommenderas för alla utom de mest skrivintensiva arbetsbelastningarna.
Mer information finns i Jämföra konfigurationer för cachelagring av datadiskar på virtuella Azure-datorer (GitHub).
Linux-vidareläsning
I de flesta Linux-distributioner i Azure Marketplace är standardinställningen för att läsa i förväg för blockenhet 4 096 kB. Cassandras läs-I/O:er är vanligtvis slumpmässiga och relativt små. Därför slösar ett stort dataflöde med läsföreläsning genom att läsa delar av filer som inte behövs.
Om du vill minimera onödig lookahead ställer du in read-ahead-inställningen för Linux-blockenheten på 8 KB. (Se Rekommenderade produktionsinställningar i DataStax-dokumentationen.)
Konfigurera 8 KB read-ahead för alla blockenheter i stripe-uppsättningen och på själva matrisenheten (till exempel /dev/md0 ).
Mer information finns i Jämföra effekten av inställningar för diskläsning (GitHub).
Segmentstorlek för diskmatris mdadm
När du kör Cassandra på Azure är det vanligt att skapa en mdadm stripe-uppsättning (d.v.s. RAID 0) för flera datadiskar för att öka det totala diskgenomflödet och IOPS närmare VM-gränserna. Optimal disk stripe-storlek är en programspecifik inställning. Till exempel är SQL Server OLTP-arbetsbelastningar 64 KB. För arbetsbelastningar i informationslager är rekommendationen 256 KB.
Våra tester hittade ingen betydande skillnad mellan segmentstorlekar på 64 000, 128 000 och 256 000 för Cassandra-läsarbetsbelastningar. Det verkar finnas en liten, något märkbar fördel med segmentstorleken på 128 000. Därför rekommenderar vi följande:
Om du redan använder en segmentstorlek på 64 K eller 256 K är det inte meningsfullt att återskapa diskmatrisen för att använda storleken 128 K.
För en ny konfiguration är det klokt att använda 128 K från början.
Mer information finns i Mäta effekten av mdadm-segmentstorlekar på Cassandra-prestanda (GitHub).
Filsystem för genomförandelogg
Cassandra-skrivningar fungerar bäst när genomförandeloggar finns på diskar med högt dataflöde och låg latens. I standardkonfigurationen rensar Cassandra 3.x data från minnet till genomförandeloggfilen var 10:e sekund och rör inte disken för varje skrivning. I den här konfigurationen är skrivprestanda nästan identiskt oavsett om genomförandeloggen finns på premium-anslutna diskar jämfört med lokala/tillfälliga diskar.
Genomförandeloggar måste vara beständiga, så att en omstartad nod kan rekonstruera alla data som ännu inte finns i datafilerna från de rensade genomförandeloggarna. För bättre hållbarhet lagrar du commit logs på premium-hanterade diskar och inte på lokal lagring, vilket kan gå förlorat om den virtuella datorn migreras till en annan värd.
Baserat på våra tester kan Cassandra på CentOS 7.x ha lägre skrivprestanda när genomförandeloggar finns i xfs jämfört med ext4-filsystemet. När du slår på komprimering av genomförandeloggar får du xfs-prestanda i linje med ext4. Komprimerade xfs utför samt komprimerade och icke-komprimerade ext4 i våra tester.
Mer information finns i Observationer på ext4- och xfs-filsystem och komprimerade genomförandeloggar (GitHub).
Mäta baslinjeprestanda för virtuella datorer
När du har distribuerat de virtuella datorerna för Cassandra-ringen kör du några syntetiska tester för att upprätta baslinjenätverks- och diskprestanda. Använd de här testerna för att bekräfta att prestandan är i linje med förväntningarna, baserat på VM-storleken.
När du senare kör den faktiska arbetsbelastningen blir det enklare att undersöka potentiella flaskhalsar om du känner till prestandabaslinjen. Om du till exempel känner till baslinjeprestandan för utgående nätverkstrafik på den virtuella datorn kan det hjälpa att utesluta nätverk som en flaskhals.
Mer information om hur du kör prestandatester finns i Verifiera baslinjeprestanda för virtuella Azure-datorer (GitHub).
Dokumentstorlek
Cassandras läs- och skrivprestanda beror på dokumentstorleken. Du kan förvänta dig högre svarstid och lägre åtgärder/sekund när du läser eller skriver med större dokument.
Mer information finns i Jämföra relativa prestanda för olika cassandra-dokumentstorlekar (GitHub).
Replikeringsfaktor
De flesta Cassandra-arbetsbelastningar använder en replikeringsfaktor (RF) på 3 när du använder anslutna premiumdiskar och till och med 5 när du använder tillfälliga/tillfälliga lokala diskar. Antalet noder i Cassandra-ringen ska vara en multipel av replikeringsfaktorn. Rf 3 innebär till exempel en ring på 3, 6, 9 eller 12 noder, medan RF 5 skulle ha 5, 10, 15 eller 20 noder. När du använder RF som är större än 1 och en konsekvensnivå på LOCAL_QUORUM, är det normalt att läs- och skrivprestanda är lägre än samma arbetsbelastning som körs med RF 1.
Mer information finns i Jämföra relativa prestanda för olika replikeringsfaktorer (GitHub).
Cachelagring av Linux-sida
När du läser datafiler använder Cassandras Java-kod vanliga fil-I/O och fördelar med cachelagring av Linux-sidor. När delar av filen har lästs en gång lagras läsinnehållet i OS-sidcachen. Efterföljande läsåtkomst till samma data går mycket snabbare.
Därför, när du kör läsprestandatester mot samma data, verkar den andra och efterföljande läsningen vara mycket snabbare än den ursprungliga läsningen, som behövde komma åt data på fjärrdatadisken eller från värdcachen när ReadOnly är aktiverat. Om du vill få liknande prestandamått för efterföljande körningar rensar du Linux-sidcachen och startar om Cassandra-tjänsten för att rensa det interna minnet. När ReadOnly-cachelagring är aktiverat kan data finnas i värdcachen och efterföljande läsningar går snabbare även efter att cacheminnet för operativsystemet och Cassandra-tjänsten har startats om.
Mer information finns i Observationer om Cassandra-användningen av Linux-sidcachelagring (GitHub).
Replikering med flera datacenter
Cassandra har inbyggt stöd för begreppet flera datacenter, vilket gör det enkelt att konfigurera en Cassandra-ring i flera Azure-regioner eller mellan tillgänglighetszoner inom en region.
För en distribution i flera regioner använder du Azure Global VNet-peering för att ansluta de virtuella nätverken i de olika regionerna. När virtuella datorer distribueras i samma region men i separata tillgänglighetszoner kan de virtuella datorerna finnas i samma virtuella nätverk.
Det är viktigt att mäta baslinjens svarstid för tur och retur mellan regioner. Nätverksfördröjningen mellan regioner kan vara 10–100 gånger högre än svarstiden inom en region. Förvänta dig en fördröjning mellan data som visas i den andra regionen när du använder LOCAL_QUORUM skrivkonsekvens eller avsevärt minskad prestanda för skrivningar när du använder EACH_QUORUM.
När du kör Apache Cassandra i stor skala, och mer specifikt i en miljö med flera domänkontrollanter, blir nodreparation en utmaning. Verktyg som Reaper kan hjälpa till att samordna reparationer i stor skala (till exempel över alla noder i ett datacenter, ett datacenter i taget, för att begränsa belastningen på hela klustret). Nodreparation för stora kluster är dock ännu inte ett fullständigt löst problem och gäller i alla miljöer, antingen lokalt eller i molnet.
När noder läggs till i en sekundär region skalas inte prestanda linjärt eftersom viss bandbredd och processor-/diskresurser används för att ta emot och skicka replikeringstrafik mellan regioner.
Mer information finns i Mäta effekten av replikering mellan flera domänkontrollanter (GitHub).
Konfiguration av hinted-handoff
I en Cassandra-ring i flera regioner kan skrivarbetsbelastningar med konsekvensnivå LOCAL_QUORUM förlora data i den sekundära regionen. Som standard begränsas cassandra hinted handoff till ett relativt lågt maximalt dataflöde och tretimmars hint-livslängd. För arbetsbelastningar med tunga skrivningar rekommenderar vi att du ökar tiden för hinted handoff-begränsning och tipsfönster för att säkerställa att tips inte tas bort innan de replikeras.
Mer information finns i Observationer om hinted handoff i replikering mellan regioner (GitHub).
Nästa steg
Mer information om dessa prestandaresultat finns i Cassandra på prestandaexperiment för virtuella Azure-datorer.
Information om allmänna Cassandra-inställningar, som inte är specifika för Azure, finns i:
Följande referensarkitektur distribuerar Cassandra som en del av en n-nivåkonfiguration: