Dela via

Köra Apache Cassandra på virtuella Azure-datorer

  • Artikel

Varning

Den här artikeln refererar till CentOS, en Linux-distribution som är End Of Life (EOL). Överväg att använda och planera i enlighet med detta. Mer information finns i CentOS End Of Life-vägledningen.

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 kan hitta 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å Azure Virtual Machines kan du överväga att använda Azure Managed Instance för Apache Cassandra. Den här tjänsten automatiserar distribution, hantering (korrigering och nodhälsa) och skalning av noder i ett Apache Cassandra-kluster. Det ger också möjlighet för hybridkluster, så Apache Cassandra-datacenter som distribueras i Azure kan ansluta till en befintlig lokal eller tredjeparts värdbaserad Cassandra-ring. Tjänsten distribueras med hjälp av Skalningsuppsättningar för virtuella Azure-datorer. Följande rekommendationer antogs under utvecklingen av den här tjänsten.

Storlekar och disktyper för virtuella Azure-datorer

Cassandra-arbetsbelastningar i Azure använder vanligtvis antingen Standard_DS14_v2, Standard_DS13_v2, Standard_D16s_v5 eller Standard_E16s_v5 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 Standard_E16s_v5 eller storleksoptimerade storlekar för lokal lagring, till exempel Standard_L16s_v3.

För hållbarhet lagras data och incheckningsloggar ofta på en stripe-uppsättning med två till fyra 1 TB premiumhanterade diskar (P30).

Cassandra-noder bör inte vara för datatäta. 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 premiumhanterade diskar rekommenderar vi att du skapar en stripe-uppsättning från några 1 TB diskar i stället för att använda en enda 2 TB eller 4 TB disk. På en DS14_v2 virtuell dator har till exempel fyra 1 TB diskar maximalt IOPS på 4 × 5 000 = 20 K, jämfört med 7,5 K för en enda 4 TB disk.

Utvärdera Azure Ultra Disks för Cassandra-arbetsbelastningar som behöver mindre diskkapacitet. De kan ge högre IOPS/dataflöde och lägre svarstid på VM-storlekar som Standard_E16s_v5 och Standard_D16s_v5.

Överväg att använda Standard_L16s_v3 eller Standard_L16s_v2 virtuella datorer för Cassandra-arbetsbelastningar som inte behöver varaktig lagring, dvs. där data enkelt kan rekonstrueras från ett annat lagringsmedium. Dessa virtuella datorer har stora och snabba, tillfälliga NVM Express-diskar (NVMe).

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 för att skicka och ta emot data från den virtuella klientdatorn och kommunicera mellan noder för replikering. För optimala prestanda drar virtuella Cassandra-datorer nytta av nätverk med högt dataflöde och låg latens.

Vi rekommenderar att du aktiverar accelererat nätverk på nätverkskortet för Cassandra-noden och på virtuella datorer som kör klientprogram med å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 datadisk för virtuella Azure-datorer

Cassandra-läsarbetsbelastningar fungerar bäst när diskfördröjningen för slumpmässig åtkomst är låg. Vi rekommenderar att du använder Azure-hanterade diskar med ReadOnly-cachelagring aktiverat. ReadOnly-cachelagring ger lägre genomsnittlig svarstid eftersom data läse från cacheminnet på värden i stället för att gå till serverdelslagringen.

Läsintensiva, slumpmässigt lästa arbetsbelastningar 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 ej angiven. (Till exempel DS14_v2 virtuella datorer har ett maximalt cachelagrat dataflöde på 512 Mbit/s jämfört med 768 Mbit/s.)

ReadOnly-cachelagring är särskilt användbart för Cassandra-tidsserier och andra arbetsbelastningar där arbetsdatauppsättningen passar i värdcachen och data inte skrivs över hela tiden. Till exempel ger DS14_v2 en cachestorlek på 512 GB, vilket kan lagra upp till 50 % av data från en Cassandra-nod med datadensitet på 1–2 TB.

Det finns ingen betydande prestandapåföljd 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 cachelagringskonfigurationer för virtuella Azure-datorer (GitHub).

Linux-läsning framåt

I de flesta Linux-distributioner på Azure Marketplace är standardinställningen blockera enhetsläsning 4 096 KB. Cassandras läs-I/OS är vanligtvis slumpmässiga och relativt små. Därför slösar ett stort dataflöde för läsning framåt genom att läsa delar av filer som inte behövs.

Om du vill minimera onödig lookahead anger du inställningen läs framåt för Linux-blockenheten till 8 KB. (Se Rekommenderade produktionsinställningar i DataStax-dokumentationen.)

Konfigurera 8 KB läs framåt 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 diskläsningsinställningar (GitHub).

Storlek på diskmatris mdadm-segment

När du kör Cassandra på Azure är det vanligt att skapa en mdadm stripe-uppsättning (d.v.s. RAID 0) med flera datadiskar för att öka det totala diskgenomflödet och IOPS närmare gränserna för virtuella datorer. Optimal diskrandstorlek är en programspecifik inställning. För TILL exempel SQL Server OLTP-arbetsbelastningar är rekommendationen 64 KB. För datalagerarbetsbelastningar är rekommendationen 256 KB.

Våra tester fann ingen betydande skillnad mellan segmentstorlekarna 64k, 128k och 256k för Cassandra-läsarbetsbelastningar. Det verkar finnas en liten, något märkbar, fördel till 128k segmentstorlek. 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 så att den använder 128 K-storlek.

  • 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).

Checka in loggfilsystem

Cassandra-skrivningar fungerar bäst när incheckningsloggar finns på diskar med högt dataflöde och låg svarstid. I standardkonfigurationen rensar Cassandra 3.x data från minnet till incheckningsloggfilen var ~10:e sekund och rör inte disken för varje skrivning. I den här konfigurationen är skrivprestanda nästan identiska om incheckningsloggen finns på premiumanslutna diskar jämfört med lokala/tillfälliga diskar.

Incheckningsloggarna måste vara varaktiga, så att en omstartad nod kan rekonstruera alla data som ännu inte finns i datafiler från de tömda incheckningsloggarna. För bättre hållbarhet kan du lagra incheckningsloggar på premiumhanterade 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 incheckningsloggarna finns på xfs jämfört med ext4-filsystemet. Om du aktiverar incheckningsloggkomprimering blir xfs-prestandan i linje med ext4. Komprimerade xfs fungerar samt komprimerade och icke-komprimerade ext4 i våra tester.

Mer information finns i Observationer på ext4- och xfs-filsystem och komprimerade incheckningsloggar (GitHub).

Mäta vm-baslinjeprestanda

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ätverk 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.

Senare, när du kör den faktiska arbetsbelastningen, gör det enklare att undersöka potentiella flaskhalsar med tanke på prestandabaslinjen. Att till exempel känna till baslinjeprestanda för nätverksutgående på den virtuella datorn kan hjälpa till att utesluta nätverket som en flaskhals.

Mer information om hur du kör prestandatester finns i Verifiera azure VM-baslinjeprestanda (GitHub).

Dokumentstorlek

Cassandras läs- och skrivprestanda beror på dokumentstorleken. Du kan förvänta dig att se 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 Premium-diskar 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 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-sidor

När Cassandras Java-kod läser datafiler använder den vanlig fil-I/O och drar nytta av cachelagring av Linux-sidor. När delar av filen har lästs en gång lagras läsinnehållet i operativsystemets sidcache. Efterföljande läsåtkomst till samma data går mycket snabbare.

Av den anledningen verkar den andra och efterföljande läsningen vara mycket snabbare när du kör prestandatester för läsning mot samma data än den ursprungliga läsningen, som behövs för att komma åt data på fjärrdatadisken eller från värdcachen när ReadOnly är aktiverat. Om du vill få liknande prestandamätningar vid efterföljande körningar rensar du Linux-sidcacheminnet och startar om Cassandra-tjänsten för att rensa dess interna minne. När ReadOnly-cachelagring är aktiverat kan data finnas i värdcachen och efterföljande läsningar kommer att gå snabbare även efter att du rensat os-sidcacheminnet och startat om Cassandra-tjänsten.

Mer information finns i Observationer om Cassandra-användning av Cachelagring av Linux-sidor (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 svarstiden för baslinjens tur och retur mellan regioner. Nätverksfördröjningen mellan regioner kan vara 10–100 gånger högre än svarstiden i 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 lägre prestanda för skrivningar när du använder EACH_QUORUM.

När du kör Apache Cassandra i stor skala, och särskilt i en miljö med flera domänkontrollanter, blir nodreparation utmanande. 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, vare sig 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 spenderas på att ta emot och skicka replikeringstrafik mellan regioner.

Mer information finns i Mäta effekten av replikering mellan flera domäner (GitHub).

Konfiguration av tipsad överlämning

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 Den antydda överlämningen i Cassandra till ett relativt lågt maximalt dataflöde och en livslängd på tre timmars tips. För arbetsbelastningar med tunga skrivningar rekommenderar vi att du ökar den antydda överlämningsbegränsningen och tiden för tipsfönstret för att säkerställa att tipsen inte tas bort innan de replikeras.

Mer information finns i Observationer om antydd överlämning i replikering mellan regioner (GitHub).

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

Annan deltagare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

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: