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). Vänligen överväg ditt användande och planera därefter. 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 set från några 1-TB-diskar istä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äses från cacheminnet på värden istället för att gå till det bakomliggande lagret.

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 icke-cachad läge. (Till exempel har DS14_v2 virtuella datorer ett maximalt cachelagrat dataflöde på 512 MBps jämfört med ej cachelagrat på 768 MBps.)

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-förinläsning

I de flesta Linux-distributioner på Azure Marketplace är standardinställningen för blockenhetens föravläsning 4096 KB. Cassandras läs-I/O är vanligtvis slumpmässiga och relativt små. Därför slösar en stor förläsning bandbredd genom att läsa delar av filer som inte behövs.

För att minimera onödig förhandsläsning anger du Linux-blockenhetens läs framåt-inställning till 8 KB. (Se Rekommenderade produktionsinställningar i DataStax-dokumentationen.)

Konfigurera 8 KB läsframåt för alla blockenheter i stripe-setet och på själva array-enheten (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 med 128k chunkstorlek. 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).

Kommittéra 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 oavsett om commit-loggen finns på premiumdiskar eller lokala/tillfälliga (efemära) 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. Genom att aktivera komprimering av commit-logg blir xfs-prestandan i nivå med ext4. Komprimerad xfs presterar lika bra som komprimerade och okompresserade 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, blir det enklare att undersöka potentiella flaskhalsar om du känner till prestandanivån. 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 i synligheten av data i den andra regionen när du använder LOCAL_QUORUM för skrivkonsistens, eller avsevärt minskad prestanda för skrivoperationer 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 indikerad överlämning

I en Cassandra-ring över flera regioner kan skrivbelastningar med konsekvensnivån 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 mycket skrivningar rekommenderar vi att du ökar den indikerade överlämningsbegränsningen och tidsfönstret för att säkerställa att indikationerna inte förloras 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: