Spuštění Apache Cassandra na virtuálních počítačích Azure
Upozornění
Tento článek odkazuje na CentOS, linuxovou distribuci, která je konec životnosti (EOL). Zvažte své použití a odpovídajícím způsobem naplánujte. Další informace najdete v doprovodných materiálech CentOS End Of Life.
Tento článek popisuje aspekty výkonu pro spouštění Apache Cassandra ve službě Azure Virtual Machines.
Tato doporučení vycházejí z výsledků testů výkonnosti, které najdete na GitHubu. Tato doporučení byste měli použít jako směrný plán a pak otestovat vlastní úlohu.
Azure Managed Instance for Apache Cassandra
Pokud hledáte automatizovanější službu pro spouštění Apache Cassandra ve službě Azure Virtual Machines, zvažte použití spravované instance Azure pro Apache Cassandra. Tato služba automatizuje nasazení, správu (opravy a stav uzlu) a škálování uzlů v clusteru Apache Cassandra. Poskytuje také možnosti pro hybridní clustery, takže datacentra Apache Cassandra nasazená v Azure se můžou připojit k existujícímu místnímu okruhu Cassandra nebo okruhu Cassandra hostované třetí stranou. Služba se nasadí pomocí služby Azure Virtual Machine Scale Sets. 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 běžně používají virtuální počítače Standard_DS14_v2, Standard_DS13_v2, Standard_D16s_v5 nebo Standard_E16s_v5 . Úlohy Cassandra můžou mít na virtuálním počítači více paměti, proto zvažte velikosti virtuálních počítačů optimalizovaných pro paměť, jako jsou Standard_DS14_v2 nebo Standard_E16s_v5 nebo velikosti optimalizované pro místní úložiště, jako jsou Standard_L16s_v3.
V případě odolnosti se protokoly dat a potvrzení běžně ukládají na pruhovou sadu dvou až čtyř disků spravovaných na 1 TB úrovně Premium (P30).
Uzly Cassandra by neměly být příliš zhuštěné. Doporučujeme mít maximálně 1 až 2 TB dat na virtuální počítač a dostatek volného místa pro komprimace. Pokud chcete dosáhnout nejvyšší možné kombinované propustnosti a vstupně-výstupních operací za sekundu pomocí spravovaných disků Úrovně Premium, doporučujeme vytvořit prokládání nastavené z několika disků o kapacitě 1 TB místo použití jednoho disku o kapacitě 2 TB nebo 4 TB. 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 a 7,5 K pro jeden 4TB disk.
Vyhodnoťte disky Azure Ultra pro úlohy Cassandra, které potřebují menší kapacitu disku. U velikostí virtuálních počítačů, jako jsou Standard_E16s_v5 a Standard_D16s_v5, můžou poskytovat vyšší IOPS/propustnost a nižší latenci.
U úloh Cassandra, které nepotřebují trvalé úložiště – to znamená, že data je možné snadno rekonstruovat z jiného úložného média – zvažte použití Standard_L16s_v3 nebo Standard_L16s_v2 virtuálních počítačů. Tyto velikosti virtuálních počítačů mají velké a rychlé místní dočasné disky NVM Express (NVMe).
Další informace najdete v tématu Porovnání výkonu místních nebo dočasných disků Azure vs. připojených nebo trvalých disků (GitHub).
Akcelerované síťové služby
Uzly Cassandra využívají velkou část sítě k odesílání a přijímání dat z klientského virtuálního počítače a ke komunikaci mezi uzly pro replikaci. Pro zajištění optimálního výkonu využívají virtuální počítače Cassandra vysokou propustnost a nízkou latenci sítě.
Doporučujeme povolit akcelerované síťové služby na síťové kartě uzlu Cassandra a na virtuálních počítačích s klientskými aplikacemi, které přistupují k Cassandře.
Akcelerované síťové služby vyžadují moderní linuxovou distribuci 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 s akcelerovanými síťovými službami.
Ukládání datových disků virtuálních počítačů Azure do mezipaměti
Úlohy čtení Cassandra fungují nejlépe, když je nízká latence disku s náhodným přístupem. 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 místo přechodu do back-endového úložiště.
Úlohy s velkými náhodnými čteními, jako je Cassandra, využívají nižší latenci čtení, i když má režim s mezipamětí nižší limity propustnosti než režim bez mezipaměti. (Příklad: DS14_v2 virtuální počítače mají maximální propustnost 512 MB/s v mezipaměti a necached 768 MB/s.)
Ukládání do mezipaměti Jen pro čtení je zvláště užitečné pro časovou řadu Cassandra a další úlohy, ve kterých se pracovní datová sada vejde do mezipaměti hostitele a data se nepřepíšou neustále. Například DS14_v2 poskytuje velikost mezipaměti 512 GB, která může ukládat až 50 % dat z uzlu Cassandra s hustotou dat 1–2 TB.
Při povolení ukládání do mezipaměti do mezipaměti není žádné významné snížení výkonu, takže režim ukládání do mezipaměti se doporučuje pro všechny úlohy náročné na zápis.
Další informace najdete v tématu Porovnání konfigurací ukládání datových disků virtuálních počítačů Azure do mezipaměti (GitHub).
Linux pro čtení dopředu
Ve většině linuxových distribucí na Azure Marketplace je výchozí nastavení pro čtení blokového zařízení 4096 kB. Vstupně-výstupní operace cassandry jsou obvykle náhodné a relativně malé. Proto se při čtení částí souborů, které nejsou potřeba, promítá propustnost s velkým předstihem.
Pokud chcete minimalizovat nepotřebné pohledy, nastavte blokové zařízení s Linuxem dopředu na 8 kB. (Viz Doporučená produkční nastavení v dokumentaci k DataStaxu.)
Nakonfigurujte 8 kB pro čtení pro všechna bloková zařízení v sadě stripe a na samotném maticovém zařízení (například /dev/md0).
Další informace najdete v tématu Porovnání dopadu nastavení čtení na disk (GitHub).
Velikost bloku bloku disku mdadm
Při spouštění Cassandra v Azure je běžné vytvořit sadu prokládání mdadm (tj. RAID 0) více datových disků, aby se zvýšila celková propustnost disku a počet IOPS blíže k limitům virtuálních počítačů. Optimální velikost pruhu disku je nastavení specifické pro aplikaci. Například pro úlohy OLTP SQL Serveru je doporučení 64 kB. U úloh datových skladů je doporučení 256 kB.
Naše testy nenašly žádný významný rozdíl mezi velikostmi bloků dat 64k, 128k a 256k pro úlohy čtení Cassandra. Zdá se, že je malý, mírně znatelný, výhoda velikosti 128 tisíc bloků dat. Proto doporučujeme následující:
Pokud už používáte blok dat o velikosti 64 K nebo 256 K, nemá smysl znovu sestavit pole disku tak, aby používalo velikost 128 K.
Pro novou konfiguraci je vhodné použít od začátku 128 K.
Další informace najdete v tématu Měření dopadu bloků dat mdadm na výkon Cassandra (GitHub).
Potvrzení systému souborů protokolu
Zápisy Cassandra fungují nejlépe, když jsou protokoly potvrzení na discích s vysokou propustností a nízkou latencí. Ve výchozí konfiguraci Cassandra 3.x vyprázdní data z paměti do souboru protokolu potvrzení každých ~10 sekund a nedotkne se disku pro každý zápis. V této konfiguraci je výkon zápisu téměř stejný, jestli je protokol potvrzení na připojených discích Premium a na místních/dočasných discích.
Protokoly potvrzení musí být trvalé, aby restartovaný uzel mohl rekonstruovat všechna data, která ještě nejsou v datových souborech z vyprázdněných protokolů potvrzení. Kvůli lepší odolnosti uložte protokoly potvrzení na spravovaných discích Úrovně Premium a ne do místního ú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 na CentOS 7.x nižší výkon zápisu, pokud jsou protokoly potvrzení v systému souborů xfs a ext4. Zapnutí komprese protokolu potvrzení přináší výkon xfs v souladu s ext4. Komprimované xfs provádí v našich testech i komprimované a nekomprimované ext4.
Další informace najdete v tématu Pozorování v systémech 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čů pro okruh Cassandra spusťte několik syntetických testů, abyste vytvořili 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.
Později, když spustíte skutečnou úlohu, znalost standardních hodnot výkonu usnadňuje zkoumání potenciálních kritických bodů. Znalost základního výkonu výchozího přenosu dat na virtuálním počítači může například pomoct vyloučit síť jako kritický bod.
Další informace o spouštění testů výkonnosti najdete v tématu Ověřování standardního výkonu virtuálního počítače Azure (GitHub).
Velikost dokumentu
Výkon čtení a zápisu Cassandra závisí na velikosti dokumentu. Při čtení nebo zápisu s většími dokumenty můžete očekávat vyšší latenci a nižší operace 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 i 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ásobkem faktoru replikace. Například RF 3 znamená okruh 3, 6, 9 nebo 12 uzlů, zatímco RF 5 by měl 5, 10, 15 nebo 20 uzlů. Pokud používáte RF větší než 1 a úroveň konzistence LOCAL_QUORUM, je normální, aby výkon čtení a zápisu byl 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í do mezipaměti na stránce s Linuxem
Když kód Cassandra v Javě čte datové soubory, používá běžné vstupně-výstupní operace souborů a výhody ukládání do mezipaměti na stránce s Linuxem. Po jednorázovém čtení částí souboru se obsah pro čtení uloží do mezipaměti stránky operačního systému. Následný přístup ke čtení stejných dat je mnohem rychlejší.
Z tohoto důvodu se při provádění testů výkonu čtení na stejných datech zdá, že druhé a následné čtení bude mnohem rychlejší než původní čtení, které je potřeba pro přístup k datům na vzdáleném datovém disku nebo z mezipaměti hostitele, když je povoleno čtení jen pro čtení. Pokud chcete získat podobné měření výkonu při následný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 povolené ukládání do mezipaměti Jen pro čtení, můžou se data v mezipaměti hostitele nacházet 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 Pozorování týkající se využití ukládání do mezipaměti na stránce s Linuxem (GitHub).
Replikace s více datovými centry
Cassandra nativně podporuje koncept několika datacenter, což usnadňuje konfiguraci jednoho okruhu Cassandra napříč několika oblastmi Azure nebo zónami dostupnosti v jedné oblasti.
Pro nasazení ve více oblastech použijte globální partnerský vztah virtuálních sítí Azure k propojení virtuálních sítí v různých oblastech. Pokud jsou virtuální počítače nasazené ve stejné oblasti, ale v samostatných zónách dostupnosti, můžou být virtuální počítače ve stejné virtuální síti.
Je důležité měřit základní latenci odezvy mezi oblastmi. Latence sítě mezi oblastmi může být 10 až 100krát vyšší než latence v rámci oblasti. Při použití LOCAL_QUORUM konzistence zápisu nebo výrazného snížení výkonu zápisu při použití EACH_QUORUM počítejte s prodlevou mezi daty v druhé oblasti.
Když spustíte Apache Cassandra ve velkém měřítku a konkrétně v prostředí s více řadiči domény, bude 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 datacentru, jedním datacentrem najednou, aby se omezilo zatížení celého clusteru). Oprava uzlů pro velké clustery ale zatím není plně vyřešený problém a vztahuje se ve všech prostředích, ať už místně nebo v cloudu.
Když se uzly přidají do sekundární oblasti, výkon se nes škáluje lineárně, protože některé prostředky šířky pásma a procesoru a disku se tráví příjmem a odesíláním provozu replikace napříč oblastmi.
Další informace najdete v tématu Měření dopadu replikace mezi více dc mezi oblastmi (GitHub).
Konfigurace hinted-handoff
V okruhu Cassandra ve více oblastech můžou úlohy s úrovní konzistence LOCAL_QUORUM ztratit data v sekundární oblasti. Cassandra ve výchozím nastavení naznačuje, že předání je omezené na relativně nízkou maximální propustnost a tříhodinovou životnost nápovědy. U úloh s velkými zápisy doporučujeme zvýšit omezení naznačenou dobu předání a interval nápovědy, aby se zajistilo, že se před replikací neodhodí rady.
Další informace najdete v tématu Pozorování naznačená předání v replikaci mezi oblastmi (GitHub).
Přispěvatelé
Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.
Hlavní autor:
- Vladimirskij Vladimirskij | Hlavní zákaznický inženýr
Další přispěvatel:
- Theo van Kraay | Vedoucí programový manažer
Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.
Další kroky
Další informace o těchto výsledcích výkonu najdete v tématu Cassandra na experimentech s výkonem virtuálních počítačů Azure.
Informace o obecných nastaveních Cassandra, které nejsou specifické pro Azure, najdete tady: