Share via

Az Apache Cassandra futtatása Azure-beli virtuális gépeken

  • Cikk

Figyelemfelhívás

Ez a cikk a CentOS-ra, egy olyan Linux-disztribúcióra hivatkozik, amely közel áll az élettartam (EOL) állapotához. Fontolja meg a használatát, és ennek megfelelően tervezze meg. További információ: CentOS End Of Life útmutató.

Ez a cikk az Apache Cassandra Azure-beli virtuális gépeken való futtatásával kapcsolatos teljesítménybeli szempontokat ismerteti.

Ezek a javaslatok a GitHubon található teljesítménytesztek eredményein alapulnak. Ezeket a javaslatokat alapkonfigurációként kell használnia, majd tesztelnie kell a saját számítási feladatait.

Felügyelt Azure-példány az Apache Cassandrához

Ha automatizáltabb szolgáltatást keres az Apache Cassandra Azure-beli virtuális gépeken való futtatásához, fontolja meg az Azure Managed Instance for Apache Cassandra használatát. Ez a szolgáltatás automatizálja az Apache Cassandra-fürtön belüli csomópontok üzembe helyezését, kezelését (javítása és csomópontállapota) és skálázását. Emellett hibrid fürtökhöz is használható, így az Azure-ban üzembe helyezett Apache Cassandra-adatközpontok csatlakozhatnak egy meglévő helyszíni vagy harmadik fél által üzemeltetett Cassandra-gyűrűhöz. A szolgáltatás üzembe helyezése azure-beli virtuálisgép-méretezési csoportok használatával történik. A szolgáltatás fejlesztése során a következő ajánlásokat fogadták el.

Azure-beli virtuális gépek méretei és lemeztípusai

Az Azure-beli Cassandra számítási feladatai általában Standard_DS14_v2, Standard_DS13_v2, Standard_D16s_v5 vagy Standard_E16s_v5 virtuális gépeket használnak. A Cassandra számítási feladatainak előnye, hogy több memória van a virtuális gépen, ezért fontolja meg a memóriaoptimalizált virtuális gépek méretét, például Standard_DS14_v2 vagy Standard_E16s_v5, vagy a helyi tárolásra optimalizált méreteket, például a Standard_L16s_v3.

A tartósság érdekében az adatokat és a véglegesítési naplókat általában két-négy, 1 TB-os prémium szintű felügyelt lemezen (P30) tárolják .

A Cassandra-csomópontok nem lehetnek túl nagy adattovábbítók. Azt javasoljuk, hogy virtuális gépenként legfeljebb 1–2 TB adat legyen, és elegendő szabad hely legyen a tömörítéshez. A lehető legmagasabb kombinált átviteli sebesség és IOPS elérése prémium szintű felügyelt lemezek használatával, javasoljuk, hogy egyetlen 2 TB-os vagy 4 TB-os lemez helyett hozzon létre egy sávkészletet néhány 1 TB-os lemezből. Egy DS14_v2 virtuális gépen például négy 1 TB-os lemez maximális IOPS-értéke 4 × 5000 = 20 K, míg egyetlen 4 TB-os lemez esetén 7,5 K.

Értékelje ki a kisebb lemezkapacitást igénylő Cassandra-számítási feladatokHoz tartozó Azure Ultra Disk-eket. Nagyobb IOPS-/átviteli sebességet és kisebb késést biztosíthatnak a virtuális gépek méretén, például Standard_E16s_v5 és Standard_D16s_v5.

Olyan Cassandra-számítási feladatok esetében, amelyekhez nincs szükség tartós tárolásra – vagyis ahol az adatok egyszerűen rekonstruálhatók egy másik tárolóeszközből – fontolja meg Standard_L16s_v3 vagy Standard_L16s_v2 virtuális gépek használatát. Ezek a virtuális gépek nagy és gyors helyi ideiglenes NVMe-lemezekkel rendelkeznek.

További információ: Az Azure helyi/rövid élettartamú és a csatlakoztatott/állandó lemezek teljesítményének összehasonlítása (GitHub).

Gyorsított hálózatkezelés

A Cassandra-csomópontok nagyban használják a hálózatot arra, hogy adatokat küldjenek és fogadjanak az ügyfél virtuális gépéről, és kommunikáljanak a csomópontok között replikáció céljából. Az optimális teljesítmény érdekében a Cassandra virtuális gépek kihasználják a nagy átviteli sebességet és az alacsony késleltetésű hálózatot.

Javasoljuk, hogy engedélyezze a gyorsított hálózatkezelést a Cassandra csomópont hálózati adapterén és a Cassandrát elérő ügyfélalkalmazásokat futtató virtuális gépeken.

A gyorsított hálózatkezelés modern Linux-disztribúciót igényel a legújabb illesztőprogramokkal, például Cent OS 7.5+ vagy Ubuntu 16.x/18.x. További információ: Linux rendszerű virtuális gép létrehozása gyorsított hálózatkezeléssel.

Azure-beli virtuálisgép-adatlemez gyorsítótárazása

A Cassandra olvasási számítási feladatai akkor teljesítenek a legjobban, ha a véletlenszerű hozzáférésű lemez késése alacsony. Javasoljuk, hogy az Azure által felügyelt lemezeket engedélyezze a ReadOnly gyorsítótárazást. A ReadOnly gyorsítótárazás alacsonyabb átlagos késést biztosít, mivel az adatokat a rendszer a gazdagép gyorsítótárából olvassa be ahelyett, hogy a háttértárba kerül.

Az olyan írásvédett, véletlenszerűen olvasható számítási feladatok, mint a Cassandra, kihasználják az alacsonyabb olvasási késést, annak ellenére, hogy a gyorsítótárazott mód alacsonyabb átviteli sebességkorlátokkal rendelkezik, mint a nem gyorsítótárazott mód. (Például: DS14_v2 virtuális gépek maximális gyorsítótárazott átviteli sebessége 512 MB/s, szemben a nem gyorsítótárazott 768 MB/s-ral.)

A ReadOnly gyorsítótárazása különösen hasznos a Cassandra idősorai és más olyan számítási feladatok esetében, ahol a munkaadatkészlet elfér a gazdagép gyorsítótárában, és az adatok nem íródnak felül folyamatosan. A DS14_v2 például 512 GB gyorsítótárméretet biztosít, amely egy Cassandra-csomópont adatainak akár 50%-át is tárolhatja 1–2 TB adatsűrűséggel.

Ha a ReadOnly gyorsítótárazása engedélyezve van, a gyorsítótárazási hibák nem járnak jelentős teljesítménnyel, ezért a gyorsítótáras mód a legtöbb írási terhelést igénylő számítási feladaton kívül mindenkinek ajánlott.

További információ: Az Azure-beli virtuális gépek adatlemez-gyorsítótárazási konfigurációinak (GitHub) összehasonlítása.

Linux írásvédett

Az Azure Marketplace legtöbb Linux-disztribúciójában az alapértelmezett blokkeszköz olvasási beállítása 4096 KB. A Cassandra olvasási I/O-k általában véletlenszerűek és viszonylag kicsik. Ezért a nagy előre olvashatóság miatt a fájlok nem szükséges részeinek olvasása pazarolja az átviteli sebességet.

A szükségtelen lookahead minimalizálásához állítsa be a Linux blokkeszköz olvasási előre beállítását 8 KB-ra. (Lásd: Ajánlott éles beállítások a DataStax dokumentációjában.)

Konfiguráljon 8 KB-os olvasási időt a sávkészletben és magában a tömbeszközben lévő összes blokkeszközhöz (például /dev/md0).

További információ: A lemez írásvédett beállításainak (GitHub) hatásainak összehasonlítása.

Lemeztömb mdadm-adattömb mérete

A Cassandra Azure-on való futtatásakor gyakori, hogy több adatlemezből álló mdadm-sávkészletet (azaz RAID 0-t) hozunk létre, hogy növeljük a teljes lemez átviteli sebességét és az IOPS-t a virtuálisgép-korlátokhoz közelebb. Az optimális lemezcsík-méret alkalmazásspecifikus beállítás. Az SQL Server OLTP számítási feladatai esetében például a javaslat 64 KB. Az adattárház-számítási feladatok esetében a javaslat 256 KB.

Tesztjeink nem találtak jelentős különbséget a 64k, 128k és 256 ezer adattömbméret között a Cassandra olvasási számítási feladatai esetében. Úgy tűnik, hogy van egy kis, kissé észrevehető, előnye, hogy a 128k darab adattömb mérete. Ezért a következőket javasoljuk:

  • Ha már 64 K vagy 256 K méretű adattömböt használ, nem érdemes újraépíteni a lemeztömböt 128 K méretűre.

  • Új konfiguráció esetén érdemes a 128 K-t használni az elejétől kezdve.

További információ: Mdadm-adattömbök méretének mérése a Cassandra teljesítményére (GitHub).

Napló fájlrendszer véglegesítése

A Cassandra-írások akkor teljesítenek a legjobban, ha a véglegesítési naplók nagy átviteli sebességgel és alacsony késéssel rendelkező lemezeken találhatók. Az alapértelmezett konfigurációban a Cassandra 3.x ~10 másodpercenként kiüríti az adatokat a memóriából a véglegesítési naplófájlba, és nem érinti a lemezt minden íráshoz. Ebben a konfigurációban az írási teljesítmény majdnem azonos, függetlenül attól, hogy a véglegesítési napló prémium szintű csatlakoztatott lemezeken van-e, szemben a helyi/rövid élettartamú lemezekkel.

A véglegesítési naplóknak tartósnak kell lenniük, hogy az újraindított csomópontok rekonstruálhassák az adatfájlokban még nem szereplő adatokat a kiürített véglegesítési naplókból. A jobb tartósság érdekében a véglegesítési naplókat prémium szintű felügyelt lemezeken tárolja, nem pedig a helyi tárolóban, ami elveszhet, ha a virtuális gépet egy másik gazdagépre migrálják.

A tesztek alapján a CentOS 7.x rendszeren található Cassandra írási teljesítménye alacsonyabb lehet, ha a véglegesítési naplók az xfs és az ext4 fájlrendszeren vannak. A véglegesítési naplótömörítés bekapcsolása az xfs teljesítményét az ext4-nek megfelelően hozza létre. A tömörített xfs a tesztek során a tömörített és a nem tömörített ext4-et is elvégzi.

További információ: Megfigyelések az ext4 és xfs fájlrendszerekről és a tömörített véglegesítési naplókról (GitHub).

Alapszintű virtuális gép teljesítményének mérése

A Cassandra-gyűrű virtuális gépeinek üzembe helyezése után futtasson néhány szintetikus tesztet az alaphálózat és a lemez teljesítményének megállapításához. Ezekkel a tesztekkel ellenőrizheti, hogy a teljesítmény összhangban van-e az elvárásokkal a virtuális gép méretétől függően.

Később, amikor a tényleges számítási feladatot futtatja, a teljesítmény alapkonfigurációjának ismerete megkönnyíti a lehetséges szűk keresztmetszetek vizsgálatát. Ha például ismeri a virtuális gép hálózati kimenő forgalmának alapkonfigurációs teljesítményét, az segíthet kizárni a hálózat szűk keresztmetszetét.

A teljesítménytesztek futtatásával kapcsolatos további információkért tekintse meg az Azure-beli virtuális gépek alapteljesítményének (GitHub) érvényesítését ismertető témakört.

Dokumentum mérete

A Cassandra olvasási és írási teljesítménye a dokumentum méretétől függ. Nagyobb dokumentumok olvasása vagy írása esetén nagyobb késésre és kisebb műveletekre/másodpercre számíthat.

További információ: A különböző Cassandra-dokumentumméretek (GitHub) relatív teljesítményének összehasonlítása.

Replikációs tényező

A Cassandra számítási feladatainak többsége 3-ból álló replikációs tényezőt (RF) használ a csatlakoztatott prémium lemezek használatakor, és akár 5-öt is, ha ideiglenes/rövid élettartamú helyi lemezeket használ. A Cassandra-gyűrű csomópontjainak számának a replikációs tényező többszörösének kell lennie. Az RF 3 például 3, 6, 9 vagy 12 csomópontból álló gyűrűt jelent, míg az RF 5 5, 10, 15 vagy 20 csomópontot. Ha 1-nél nagyobb RF-t és LOCAL_QUORUM konzisztenciaszintet használ, az olvasási és írási teljesítmény általában alacsonyabb, mint az RF 1-et futtató számítási feladaté.

További információ: A különböző replikációs tényezők (GitHub) relatív teljesítményének összehasonlítása.

Linux-lap gyorsítótárazása

Amikor a Cassandra Java-kódja adatfájlokat olvas be, normál fájl-I/O-t használ, és a Linux-lapok gyorsítótárazásának előnyei. A fájl egyes részeinek egyszeri olvasása után az olvasási tartalom az operációsrendszer-lap gyorsítótárában lesz tárolva. Ugyanezekhez az adatokhoz a későbbi olvasási hozzáférés sokkal gyorsabb.

Ezért az olvasási teljesítménytesztek ugyanazon adatokon való végrehajtásakor a második és az azt követő olvasás sokkal gyorsabbnak tűnik, mint az eredeti olvasás, amely a távoli adatlemezen vagy a gazdagép gyorsítótárában lévő adatok eléréséhez szükséges, amikor a ReadOnly engedélyezve van. A következő futtatásokhoz hasonló teljesítménymérések lekéréséhez törölje a Linux-lap gyorsítótárát, és indítsa újra a Cassandra szolgáltatást a belső memória kiürítéséhez. Ha a ReadOnly gyorsítótárazás engedélyezve van, előfordulhat, hogy az adatok a gazdagép gyorsítótárában lesznek, és a későbbi olvasások még az operációsrendszer-lap gyorsítótárának törlése és a Cassandra szolgáltatás újraindítása után is gyorsabbak lesznek.

További információ: Megfigyelések a Linux-lap gyorsítótárazásának Cassandra-használatáról (GitHub).

Több adatközpontú replikáció

A Cassandra natív módon támogatja a több adatközpont fogalmát, így egyszerűen konfigurálhat egy Cassandra-gyűrűt több Azure-régióban vagy egy régió rendelkezésre állási zónáiban .

Többrégiós üzembe helyezés esetén az Azure Global VNet-társviszony-létesítéssel csatlakoztassa a virtuális hálózatokat a különböző régiókban. Ha a virtuális gépek ugyanabban a régióban, de különálló rendelkezésre állási zónákban vannak üzembe helyezve, a virtuális gépek ugyanabban a virtuális hálózaton lehetnek.

Fontos, hogy megmérjük a régiók közötti alapkonfigurációs kerekítés késését. A régiók közötti hálózati késés 10-100-szor nagyobb lehet, mint egy régión belüli késés. Ha LOCAL_QUORUM írási konzisztenciát használ, a második régióban megjelennek az adatok, vagy jelentősen csökken az írási teljesítmény EACH_QUORUM használatakor.

Az Apache Cassandra nagy léptékű és kifejezetten több tartományvezérlős környezetben történő futtatásakor a csomópontok javítása kihívást jelent. Az olyan eszközök, mint a Reaper , segíthetnek a javítások nagy léptékű koordinálásában (például egy adatközpont összes csomópontján, egyszerre egy adatközpontban, a teljes fürt terhelésének korlátozásához). A nagy fürtök csomópontjavítása azonban még nem teljesen megoldott probléma, és minden környezetben érvényes, akár a helyszínen, akár a felhőben.

Ha csomópontokat adnak hozzá egy másodlagos régióhoz, a teljesítmény nem skálázódik lineárisan, mivel a sávszélesség és a cpu/lemez erőforrásainak egy része a replikációs forgalom fogadására és régiók közötti küldésére kerül.

További információ: A több tartományvezérlős régiók közötti replikáció (GitHub) hatásának mérése.

Emlékeztetőkonfiguráció

Többrégiós Cassandra-gyűrűkben a LOCAL_QUORUM konzisztenciájú számítási feladatai elveszhetnek a másodlagos régióban. A Cassandra által javasolt átadás alapértelmezés szerint viszonylag alacsony maximális átviteli sebességre és háromórás emlékeztető élettartamra van szabályozva. A nehéz írási feladatokkal rendelkező számítási feladatok esetében javasoljuk, hogy növelje a javasolt handoff-szabályozást és a tippidőt annak érdekében, hogy a tippek ne legyenek elvetve a replikálás előtt.

További információ: Megfigyelések a régiók közötti replikációban (GitHub).

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerző:

Egyéb közreműködő:

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

Következő lépések

További információ ezekről a teljesítményeredményekről: Cassandra on Azure VMs Performance Experiments.

Az Azure-ra nem jellemző általános Cassandra-beállításokról a következő témakörben olvashat: