Spuštění Apache Cassandra na virtuálních počítači Azure
Tento článek popisuje důležité informace o výkonu při spouštění Apache Cassandra na virtuálních počítačích Azure.
Tato doporučení vycházejí z výsledků testů výkonnosti, které najdete na GitHub. Tato doporučení byste měli použít jako základ a pak je otestovat na vlastní úlohu.
Spravovaná instance Azure pro Apache Cassandra
Pokud hledáte automatizovanější službu pro spouštění Apache Cassandra na virtuálních počítačích Azure, zvažte použití spravované instance Azure pro Apache Cassandra. Tato služba automatizuje nasazení, správu (opravy a stav uzlů) a škálování uzlů v clusteru Apache Cassandra. Poskytuje také funkce pro hybridní clustery,takže datacentra Apache Cassandra nasazená v Azure se mohou připojit k existujícímu okruhu Cassandra hostovanému v místním prostředí nebo třetí straně. Služba se nasazovat pomocí škálovací sady virtuálních počítačů Azure. Během vývoje této služby byla přijata následující doporučení.
Velikosti a typy disků virtuálních počítačů Azure
Úlohy Cassandra v Azure obvykle používají Standard_DS14_v2 nebo Standard_DS13_v2 virtuální počítače. Úlohy Cassandra těží z většího využití paměti na virtuálním počítači, proto zvažte velikosti virtuálních počítačů optimalizovaných pro paměť, jako je Standard_DS14_v2 nebo velikosti optimalizované pro místní úložiště, jako je Standard_L16s_v2.
Kvůli odolnosti se data a protokoly potvrzení běžně ukládají na sadu pruhů se dvěma až čtyřmi spravovanými disky úrovně Premium 1 TB (P30).
Uzly Cassandra by neměly mít příliš hustotu dat. Pro komprimaci doporučujeme mít na virtuálním počítače nejvíce – 1 2 TB dat a dostatek volného místa. Pokud chcete dosáhnout nejvyšší možné kombinované propustnosti a IOPS pomocí spravovaných disků úrovně Premium, doporučujeme místo použití jednoho disku o 2 TB nebo 4 TB vytvořit sadu prokládanou z několika 1TB disků. Například na virtuálním počítači DS14_v2 mají čtyři 1TB disky maximální počet IOPS 4 × 5000 = 20 K, místo 7,5 K pro jeden 4TB disk.
S tím, disky úrovně Ultra Azure napříč oblastmi stále častěji dostupné, je vyhodnoťte pro úlohy Cassandra, které potřebují menší kapacitu disku. Díky velikosti virtuálních počítačů, jako jsou Standard_D32s_v3 a Standard_D16s_v3,mohou poskytovat vyšší vstupně-výstupní operace za Standard_D16s_v3.
U úloh Cassandra, které nepo potřebují trvalé úložiště, to znamená, kde je možné data snadno rekonstruovat z jiného úložného média, zvažte použití virtuálních Standard_L32s_v2 nebo — — Standard_L16s_v2 počítače. Tyto velikosti virtuálních počítačů mají velké a rychlé místní dočasné disky NVMe.
Další informace najdete v tématu Porovnání výkonu místních/dočasných disků Azure vs. připojených nebo trvalých disků (GitHub).
Akcelerované síťové služby
Uzly Cassandra velmi využívají síť k odesílání a příjmu dat z klientského virtuálního počítače a ke komunikaci mezi uzly kvůli replikaci. Pro zajištění optimálního výkonu využívají virtuální počítače Cassandra výhody sítě s vysokou propustností a nízkou latencí.
Doporučujeme povolit akcelerované síťové služby na síťovém rozhraní uzlu Cassandra a na virtuálních počítačech s klientskými aplikacemi, které přistupují k Cassandře.
Akcelerované síťové služby vyžadují moderní distribuci Linuxu s nejnovějšími ovladači, jako je Cent OS 7.5 nebo Ubuntu 16.x/18.x. Další informace najdete v tématu Vytvoření virtuálního počítače s Linuxem a akcelerované síťové služby.
Ukládání datových disků virtuálního počítače Azure do mezipaměti
Úlohy čtení Cassandra mají nejlepší výkon, když je latence disku s náhodným přístupem nízká. Doporučujeme používat spravované disky Azure s povoleným ukládáním do mezipaměti jen pro čtení. Ukládání do mezipaměti jen pro čtení poskytuje nižší průměrnou latenci, protože data se čtou z mezipaměti na hostiteli, a ne z back-end úložiště.
Úlohy náročné na čtení s náhodným čtením, jako je Cassandra, těží z nižší latence čtení, i když režim mezipaměti má nižší limity propustnosti než režim bez mezipaměti. (Například virtuální DS14_v2 mají maximální propustnost v mezipaměti 512 MB/s oproti propustnosti bez mezipaměti 768 MB/s.)
Ukládání do mezipaměti jen pro čtení je zvlášť užitečné pro časovou řadu Cassandra a další úlohy, u kterých se pracovní datová sada vejde do mezipaměti hostitele a data se neustále přepisují. Například DS14_v2 mezipaměť o velikosti 512 GB, která může uchovávat až 50 % dat z uzlu Cassandra s hustotou dat 1–2 TB.
Pokud je povolené ukládání do mezipaměti Jen pro čtení, nenastane žádná významná penalizace z mezipaměti, takže režim mezipaměti se doporučuje pro všechny úlohy s největší zátěží, ale s největší zátěží zápisu.
Další informace najdete v tématu Porovnání konfigurací ukládání datových disků do mezipaměti virtuálního počítače Azure (GitHub).
Linux – dopředné čtení
Ve většině linuxových distribucí v Azure Marketplace je výchozí nastavení pro čtení blokového zařízení 4096 kB. V/V pro čtení Cassandry jsou obvykle náhodné a relativně malé. Velký prostor pro čtení proto plýtvá propustností čtením nepotřebné části souborů.
Pokud chcete minimalizovat nepotřebné dopředné vyhledávání, nastavte nastavení pro čtení blokového zařízení s Linuxem na 8 kB. (Viz Doporučená produkční nastavení v dokumentaci k DataStax.)
Nakonfigurujte 8 kB čtení pro všechna bloková zařízení v sadě pruhů a na samotném zařízení pole (například /dev/md0 ).
Další informace najdete v tématu Porovnání dopadu nastavení čtení z disku (GitHub).
Velikost bloku bloků mdadm diskového pole
Při spuštění Cassandry v Azure je běžné vytvořit sadu mdadm stripe (to znamená RAID 0) několika datových disků, která zvýší celkovou propustnost disku a IOPS blíže limitům virtuálních počítačů. Optimální velikost pruhu disku je nastavení specifické pro aplikaci. Například pro úlohy SQL Server OLTP je doporučení 64 kB. Pro úlohy datových skladů je doporučení 256 kB.
Naše testy nenašly žádný významný rozdíl mezi velikostmi bloků dat 64 kB, 128 000 a 256 000 pro úlohy čtení Cassandra. Zdá se, že má malou, mírně znatelnou výhodu velikosti 128 000 bloků dat. Proto doporučujeme následující:
Pokud už používáte bloky dat o velikosti 64 k nebo 256 K, nemá smysl diskové pole znovu sestavit tak, aby bylo velikosti 128 K.
Pro novou konfiguraci dává smysl používat 128 K od začátku.
Další informace najdete v tématu Měření dopadu velikostí bloků bloků mdadm na výkon Cassandra (GitHub).
Systém souborů protokolu potvrzení
Zápisy Cassandra mají nejlepší výkon, pokud jsou protokoly potvrzení na discích s vysokou propustností a nízkou latencí. Ve výchozí konfiguraci Cassandra 3.x každých 10 sekund vyprázdní data z paměti do souboru protokolu potvrzení a při každém zápisu se disku nedotknu. V této konfiguraci je výkon zápisu téměř stejný bez ohledu na to, jestli se protokol potvrzení nachází na připojených discích úrovně Premium a na místních nebo dočasných discích.
Protokoly potvrzení musí být odolné, aby restartovaný uzel mohl rekonstruovat jakákoli data, která ještě nejsou v datových souborech z vyprázdněných protokolů potvrzení. Kvůli lepší stálosti uložte protokoly potvrzení na spravované disky úrovně Premium, a ne na místní úložiště, které může být ztraceno, pokud je virtuální počítač migrován na jiného hostitele.
Na základě našich testů může mít Cassandra v CentOS 7.x nižší výkon zápisu, pokud se protokoly potvrzení nachází v systému souborů xfs a ext4. Zapnutí komprese protokolů potvrzení přináší výkon XFS v souladu s ext4. Komprimovaný soubor xfs provádí v našich testech také komprimovaný a nekomprimovaný ext4.
Další informace najdete v tématu Pozorování systémů souborů ext4 a xfs a komprimovaných protokolech potvrzení (GitHub).
Měření výkonu základního virtuálního počítače
Po nasazení virtuálních počítače pro okruh Cassandra spusťte několik syntetických testů, abyste nasadili základní výkon sítě a disku. Pomocí těchto testů ověřte, že výkon je v souladu s očekáváními na základě velikosti virtuálního počítače.
Když později spustíte skutečnou úlohu, znalost směrného plánu výkonu usnadňuje prozkoumání potenciálních kritických míst. Například znalost základního výkonu výchozího přenosu dat sítě na virtuálním počítači může pomoct vyloučit síť jako kritický bod.
Další informace o spouštění testů výkonnosti najdete v tématu Ověřování standardních hodnot výkonu virtuálních GitHub).
Velikost dokumentu
Výkon čtení a zápisu Cassandra závisí na velikosti dokumentu. Při čtení nebo zápisu větších dokumentů můžete očekávat vyšší latenci a nižší počet operací za sekundu.
Další informace najdete v tématu Porovnání relativního výkonu různých velikostí dokumentů Cassandra (GitHub).
Faktor replikace
Většina úloh Cassandra používá faktor replikace (RF) 3 při použití připojených disků Premium a dokonce 5 při použití dočasných nebo dočasných místních disků. Počet uzlů v okruhu Cassandra by měl být násobným faktorem replikace. Rf 3 například implikuje okruh 3, 6, 9 nebo 12 uzlů, zatímco RF 5 by měl 5, 10, 15 nebo 20 uzlů. Při použití RF větší než 1 a úrovně konzistence LOCAL_QUORUM je normální, že výkon čtení a zápisu je nižší než stejná úloha spuštěná s RF 1.
Další informace najdete v tématu Porovnání relativního výkonu různých faktorů replikace (GitHub).
Ukládání stránek do mezipaměti v Linuxu
Při čtení datových souborů používá kód Java Cassandry pravidelné V/V soubory a výhody ukládání linuxových stránek do mezipaměti. Po jednom čtení částí souboru se obsah pro čtení uloží do mezipaměti stránky operačního systému. Následný přístup pro čtení ke stejným datům je mnohem rychlejší.
Z tohoto důvodu se při provádění testů výkonnosti čtení na stejných datech bude zdát, že druhé a následné čtení bude mnohem rychlejší než původní čtení, které bylo potřeba pro přístup k datům na vzdáleném datovém disku nebo z mezipaměti hostitele, pokud je povoleno jen pro čtení. Pokud chcete získat podobná měření výkonu při dalších spuštěních, vymažte mezipaměť stránky Linuxu a restartujte službu Cassandra, aby se vymaže její interní paměť. Pokud je ukládání do mezipaměti jen pro čtení povolené, můžou být data v mezipaměti hostitele a následná čtení budou rychlejší i po vymazání mezipaměti stránky operačního systému a restartování služby Cassandra.
Další informace najdete v tématu Poznámky k používání ukládání stránek do mezipaměti v Linuxu (GitHub).
Replikace více datacenter
Cassandra nativně podporuje koncept více datových center, což usnadňuje konfiguraci jednoho okruhu Cassandra v několika oblastech Azure nebo napříč zónami dostupnosti v jedné oblasti.
Pro nasazení ve více oblastech propojte virtuální sítě v různých oblastech pomocí globálního partnerského vztahu virtuálních sítí Azure. Když jsou virtuální počítače nasazené ve stejné oblasti, ale v samostatných zónách dostupnosti, mohou být ve stejné virtuální síti.
Je důležité změřit standardní latenci odezvy mezi oblastmi. Latence sítě mezi oblastmi může být 10 až 100krát vyšší než latence v rámci oblasti. Očekávejte prodlevu mezi daty, která se zobrazují ve druhé oblasti, LOCAL_QUORUM konzistence zápisu, nebo výrazně snížit výkon zápisů při použití EACH_QUORUM.
Při spouštění Apache Cassandry ve velkém měřítku, konkrétně v prostředí s více řadiči domény, je oprava uzlů náročná. Nástroje, jako je Reaper, můžou pomoct koordinovat opravy ve velkém měřítku (například napříč všemi uzly v datovém centru, po jednotlivých datových centrech, aby se omezilo zatížení celého clusteru). Oprava uzlů pro velké clustery ale zatím není plně vyřešená a platí pro všechna prostředí, ať už místní nebo cloudová.
Když se uzly přidávají do sekundární oblasti, výkon se nebude škálovat lineárně, protože na příjem a odesílání provozu replikace mezi oblastmi se spotřebuje některá šířka pásma a prostředky procesoru a disku.
Další informace najdete v tématu Měření dopadu replikace mezi oblastmi s více řadiči domény (GitHub).
Konfigurace hinted-handoff
V okruhu Cassandra ve více oblastech může úloha zápisu s úrovní konzistence LOCAL_QUORUM může ztratit data v sekundární oblasti. Ve výchozím nastavení se předání podle pokynů Cassandře omešká na relativně nízkou maximální propustnost a životnost tříhodinových tipů. U úloh s častými zápisy doporučujeme zvýšit limit hinted handoff a dobu okna nápovědy, aby se zajistilo, že se nápovědy před replikací neztrácely.
Další informace najdete v tématu Poznámky k předání tipů v replikaci mezi oblastmi (GitHub).
Další kroky
Další informace o těchto výsledcích výkonu najdete v tématu Cassandra na webu Azure VMs Performance Experiments.
Informace o obecných nastaveních Cassandra, která nejsou specifická pro Azure, najdete v těchto tématu:
Následující referenční architektura nasadí Cassandu jako součást n-vrstvé konfigurace: