Bagikan melalui

Jalankan Apache Cassandra di Azure VM

  • Artikel

Perhatian

Artikel ini mereferensikan CentOS, distribusi Linux yang merupakan End Of Life (EOL). Harap pertimbangkan penggunaan dan rencanakan yang sesuai. Untuk informasi selengkapnya, lihat panduan Akhir Masa Pakai CentOS.

Artikel ini menjelaskan pertimbangan performa untuk menjalankan Apache Cassandra di Azure Virtual Machines.

Rekomendasi ini didasarkan pada hasil tes kinerja, yang dapat Anda temukan di GitHub. Anda harus menggunakan rekomendasi ini sebagai garis besar dan kemudian menguji terhadap beban kerja Anda sendiri.

Azure Managed Instance for Apache Cassandra

Jika Anda mencari layanan yang lebih otomatis untuk menjalankan Apache Cassandra di Azure Virtual Machines, pertimbangkan untuk menggunakan Azure Managed Instance for Apache Cassandra. Layanan ini mengotomatiskan penyebaran, manajemen (patching dan kesehatan node), dan penskalaan node dalam kluster Apache Cassandra. Ini juga menyediakan kemampuan untuk kluster hibrida, sehingga pusat data Apache Cassandra yang dikerahkan di Azure dapat bergabung dengan cincin Cassandra lokal atau pihak ketiga yang ada. Layanan ini disebarkan dengan menggunakan Azure Virtual Machine Scale Sets. Rekomendasi berikut diadopsi selama pengembangan layanan ini.

Ukuran dan tipe disk Azure VM

Beban kerja Cassandra di Azure biasanya menggunakan komputer virtual Standard_DS14_v2, Standard_DS13_v2, Standard_D16s_v5, atau Standard_E16s_v5 . Beban kerja Cassandra mendapat manfaat dari memiliki lebih banyak memori di VM, jadi pertimbangkan ukuran komputer virtual yang dioptimalkan memori, seperti Standard_DS14_v2 atau Standard_E16s_v5, atau ukuran yang dioptimalkan penyimpanan lokal seperti Standard_L16s_v3.

Untuk durabilitas, data dan log komit biasanya disimpan pada set stripe dua hingga empat disk terkelola premium 1 TB (P30).

Node Cassandra seharusnya tidak terlalu padat data. Sebaiknya memiliki paling banyak 1 - 2 TB data per VM dan ruang kosong yang cukup untuk pemadatan. Untuk mencapai throughput gabungan dan IOPS setinggi mungkin menggunakan disk terkelola premium, sebaiknya buat set stripe dari beberapa disk 1 TB, alih-alih menggunakan disk 2 TB atau 4 TB tunggal. Misalnya, pada VM DS14_v2, empat disk 1 TB memiliki IOPS maksimum 4 × 5000 = 20 K, versus 7,5 K untuk disk 4 TB tunggal.

Evaluasi Azure Ultra Disks untuk beban kerja Cassandra yang membutuhkan kapasitas disk yang lebih kecil. Mereka dapat memberikan IOPS/throughput yang lebih tinggi dan latensi yang lebih rendah pada ukuran VM seperti Standard_E16s_v5 dan Standard_D16s_v5.

Untuk beban kerja Cassandra yang tidak memerlukan penyimpanan tahan lama—yaitu, di mana data dapat dengan mudah direkonstruksi dari media penyimpanan lain—pertimbangkan untuk menggunakan VM Standard_L16s_v3 atau Standard_L16s_v2 . Ukuran VM ini memiliki disk NVM Express (NVMe) sementara lokal yang besar dan cepat.

Untuk informasi selengkapnya, lihat Membandingkan performa azure local/ephemeral vs terlampir/persistent disks (GitHub).

Penjaringan Dipercepat

Node Cassandra memanfaatkan jaringan secara besar-berat untuk mengirim dan menerima data dari VM klien dan untuk berkomunikasi antar node untuk replikasi. Untuk performa optimal, VM Cassandra mendapat manfaat dari throughput tinggi dan jaringan latensi rendah.

Kami merekomendasikan untuk mengaktifkan Accelerated Networking pada NIC node Cassandra dan pada VM yang menjalankan aplikasi klien yang mengakses Cassandra.

Accelerated Networking memerlukan distribusi Linux modern dengan driver terbaru, seperti Cent OS 7.5+ atau Ubuntu 16.x/18.x. Untuk informasi selengkapnya, lihat Membuat mesin virtual Linux dengan Accelerated Networking.

Penembolokan disk data Azure VM

Beban kerja baca Cassandra berkinerja terbaik saat latensi disk akses acak rendah. Sebaiknya gunakan disk terkelola Azure dengan penembolokan ReadOnly diaktifkan. Penembolokan ReadOnly memberikan latensi rata-rata yang lebih rendah, karena data dibaca dari cache pada host alih-alih pergi ke penyimpanan backend.

Beban kerja baca-berat dan acak seperti Cassandra mendapat manfaat dari latensi baca yang lebih rendah meskipun mode cache memiliki batas throughput yang lebih rendah daripada mode yang tidak tertutup. (Misalnya, DS14_v2 komputer virtual memiliki throughput cache maksimum 512 MBps versus tidak di-cache 768 MBps.)

Penembolokan ReadOnly sangat membantu untuk rangkaian waktu Cassandra dan beban kerja lainnya di mana himpunan data yang berfungsi cocok dalam cache host dan data tidak terus-menerus ditimpa. Misalnya, DS14_v2 menyediakan ukuran cache 512 GB, yang dapat menyimpan hingga 50% data dari node Cassandra dengan kepadatan data 1-2 TB.

Tidak ada penalti performa yang signifikan dari cache-misses ketika penembolokan ReadOnly diaktifkan, sehingga mode cache direkomendasikan untuk semua kecuali beban kerja yang paling berat tulis.

Untuk informasi selengkapnya, lihat Membandingkan konfigurasi penembolokan disk data Azure VM (GitHub).

Linux read-ahead

Di sebagian besar distribusi Linux di Azure Marketplace, pengaturan read-ahead perangkat blok default adalah 4096 KB. I/OS baca Cassandra biasanya acak dan relatif kecil. Oleh karena itu, memiliki pembacaan besar menyia-nyiakan throughput dengan membaca bagian file yang tidak diperlukan.

Untuk meminimalkan pandangan yang tidak perlu ke depan, atur pengaturan read-ahead perangkat blok Linux ke 8 KB. (Lihat Pengaturan produksi yang direkomendasikan di dokumentasi DataStax.)

Konfigurasikan read-ahead 8 KB untuk semua perangkat blok di set stripe dan pada perangkat array itu sendiri (misalnya, /dev/md0).

Untuk informasi selengkapnya, lihat Membandingkan dampak pengaturan baca-baca disk (GitHub).

Ukuran disk array mdadm chunk

Saat menjalankan Cassandra di Azure, adalah umum untuk membuat kumpulan garis mdadm (yaitu, RAID 0) dari beberapa disk data untuk meningkatkan throughput disk keseluruhan dan IOPS lebih dekat ke batas VM. Ukuran garis disk yang optimal adalah pengaturan khusus aplikasi. Misalnya, untuk beban kerja SQL Server OLTP, rekomendasinya adalah 64 KB. Untuk beban kerja pergudangan data, rekomendasinya adalah 256 KB.

Tes kami tidak menemukan perbedaan yang signifikan antara ukuran gugus 64k, 128k, dan 256k untuk beban kerja baca Cassandra. Tampaknya ada keuntungan kecil, sedikit terlihat, untuk ukuran gugus 128k. Oleh karena itu, kami merekomendasikan hal-hal berikut:

  • Jika Anda sudah menggunakan ukuran gugus 64 K atau 256 K, tidak masuk akal untuk membangun kembali array disk untuk menggunakan ukuran 128-K.

  • Untuk konfigurasi baru, masuk akal untuk menggunakan 128 K dari awal.

Untuk informasi selengkapnya, lihat Mengukur dampak ukuran gugus mdadm pada performa Cassandra (GitHub).

Sistem berkas log penerapan

Cassandra menulis berperforma terbaik ketika log penerapan berada di disk dengan throughput tinggi dan latensi rendah. Dalam konfigurasi default, Cassandra 3.x flushes data dari memori ke file log komit setiap ~ 10 detik dan tidak menyentuh disk untuk setiap tulisan. Dalam konfigurasi ini, performa tulis hampir identik apakah log komit ada pada disk terlampir premium versus disk lokal / sementara.

Log komit harus tahan lama, sehingga node yang dimulai ulang dapat merekonstruksi data apa pun yang belum ada dalam file data dari log komit yang memerah. Untuk daya tahan yang lebih baik, simpan log komit pada disk terkelola premium dan bukan pada penyimpanan lokal, yang dapat hilang jika VM dimigrasikan ke host lain.

Berdasarkan pengujian kami, Cassandra di CentOS 7.x mungkin memiliki performa tulis yang lebih rendah ketika log commit berada di sistem file xfs versus ext4. Mengaktifkan kompresi log komit membawa performa xfs sejalan dengan ext4. Xfs terkompresi melakukan serta ext4 terkompresi dan non-terkompresi dalam pengujian kami.

Untuk informasi selengkapnya, lihat Pengamatan pada sistem file ext4 dan xfs dan log komit terkompresi (GitHub).

Mengukur performa VM dasar

Setelah menyebarkan VM untuk cincin Cassandra, jalankan beberapa tes sintetis untuk membangun performa jaringan dan disk dasar. Gunakan tes ini untuk mengonfirmasi bahwa performa sesuai dengan harapan, berdasarkan ukuran VM.

Kemudian, ketika Anda menjalankan beban kerja yang sebenarnya, mengetahui garis besar performa membuatnya lebih mudah untuk menyelidiki potensi penyempitan. Misalnya, mengetahui performa garis besar untuk keluar jaringan pada VM dapat membantu mengesampingkan jaringan sebagai penyempitan.

Untuk informasi selengkapnya tentang menjalankan pengujian performa, lihat Memvalidasi performa Azure VM garis besar (GitHub).

Ukuran dokumen

Cassandra membaca dan menulis performa tergantung dengan ukuran dokumen. Anda dapat mengharapkan untuk melihat latensi yang lebih tinggi dan operasi / detik yang lebih rendah saat membaca atau menulis dengan dokumen yang lebih besar.

Untuk informasi selengkapnya, lihat Membandingkan performa relatif dari berbagai ukuran dokumen Cassandra (GitHub).

Faktor replikasi

Sebagian besar beban kerja Cassandra menggunakan faktor replikasi (RF) 3 saat menggunakan disk premium terlampir dan bahkan 5 saat menggunakan disk lokal sementara / sementara. Jumlah node dalam cincin Cassandra harus menjadi kelipatan faktor replikasi. Misalnya, RF 3 menyiratkan cincin 3, 6, 9, atau 12 node, sedangkan RF 5 akan memiliki 5, 10, 15, atau 20 node. Saat menggunakan RF lebih besar dari 1 dan tingkat konsistensi LOCAL_QUORUM, wajar jika performa baca dan tulis lebih rendah daripada beban kerja yang sama yang berjalan dengan RF 1.

Untuk informasi selengkapnya, lihat Membandingkan performa relatif dari berbagai faktor replikasi (GitHub).

Penembolokan halaman Linux

Ketika kode Java Cassandra membaca file data, kode tersebut menggunakan I/O file reguler dan manfaat dari penembolokan halaman Linux. Setelah bagian file dibaca satu kali, konten baca disimpan dalam cache halaman OS. Akses baca berikutnya ke data yang sama jauh lebih cepat.

Untuk alasan ini, ketika menjalankan tes performa baca terhadap data yang sama, pembacaan kedua dan berikutnya akan tampak jauh lebih cepat daripada pembacaan asli, yang diperlukan untuk mengakses data pada disk data jauh atau dari cache host ketika ReadOnly diaktifkan. Untuk mendapatkan pengukuran performa serupa pada putaran berikutnya, hapus cache halaman Linux dan mulai ulang layanan Cassandra untuk menghapus memori internalnya. Ketika penembolokan ReadOnly diaktifkan, data mungkin ada di cache host, dan pembacaan berikutnya akan lebih cepat bahkan setelah membersihkan cache halaman OS dan memulai ulang layanan Cassandra.

Untuk informasi selengkapnya, lihat Pengamatan tentang penggunaan penembolokan halaman Linux (GitHub) Cassandra.

Replikasi multi pusat data

Cassandra secara asli mendukung konsep beberapa pusat data, sehingga memudahkan untuk mengonfigurasi satu cincin Cassandra di beberapa wilayah Azure atau di seluruh zona ketersediaan dalam satu wilayah.

Untuk penyebaran multiregion, gunakan Azure Global VNet-peering untuk menghubungkan jaringan virtual di berbagai wilayah. Ketika VM disebarkan di wilayah yang sama tetapi di zona ketersediaan terpisah, VM dapat berada di jaringan virtual yang sama.

Sangat penting untuk mengukur latensi pulang pergi dasar antar wilayah. Latensi jaringan antar wilayah bisa 10-100 kali lebih tinggi dari latensi dalam suatu wilayah. Harapkan jeda antara data yang muncul di wilayah kedua saat menggunakan LOCAL_QUORUM menulis konsistensi, atau penurunan performa penulisan secara signifikan saat menggunakan EACH_QUORUM.

Ketika Anda menjalankan Apache Cassandra dalam skala besar, dan khususnya di lingkungan multi-DC, perbaikan simpul menjadi menantang. Alat seperti Reaper dapat membantu mengoordinasikan perbaikan dalam skala besar (misalnya, di semua simpul di pusat data, satu pusat data sekaligus, untuk membatasi beban pada seluruh kluster). Namun, perbaikan node untuk kluster besar belum menjadi masalah yang sepenuhnya terselesaikan dan berlaku di semua lingkungan, baik lokal maupun di cloud.

Ketika simpul ditambahkan ke wilayah sekunder, performa tidak diskalakan secara linier, karena beberapa bandwidth dan sumber daya CPU/disk dihabiskan untuk menerima dan mengirim lalu lintas replikasi di seluruh wilayah.

Untuk informasi selengkapnya, lihat Mengukur dampak replikasi lintas wilayah multi-dc (GitHub).

Konfigurasi handoff yang diisyaratkan

Dalam cincin Cassandra multiregion, tulis beban kerja dengan tingkat konsistensi LOCAL_QUORUM mungkin kehilangan data di wilayah sekunder. Secara default, Cassandra mengisyaratkan handoff dibatasi ke throughput maksimum yang relatif rendah dan masa petunjuk tiga jam. Untuk beban kerja dengan penulisan berat, sebaiknya tingkatkan pembatasan handoff yang diisyaratkan dan waktu jendela petunjuk untuk memastikan petunjuk tidak dihilangkan sebelum direplikasi.

Untuk informasi selengkapnya, lihat Pengamatan tentang handoff yang diisyaratkan dalam replikasi lintas wilayah (GitHub).

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

Kontributor lainnya:

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

Untuk informasi selengkapnya tentang hasil performa ini, lihat Cassandra di Eksperimen Kinerja Azure VM.

Untuk informasi tentang pengaturan Cassandra umum, tidak spesifik untuk Azure, lihat: