Jalankan Apache Cassandra di Azure VM

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 pengujian performa, 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 hibrid, sehingga pusat data Apache Cassandra yang disebarkan di Azure dapat bergabung dengan cincin Cassandra yang dihosting 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 ketahanan, data dan log komit umumnya disimpan pada set stripe dua hingga empat SSD 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 terpadu dan IOPS setinggi mungkin dengan menggunakan SSD Premium, kami sarankan untuk membuat set stripe dari beberapa disk 1-TB, alih-alih menggunakan satu disk 2-TB atau 4-TB. 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 disk lokal/sementara Azure vs disk terlampir/persisten (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.

Sebaiknya aktifkan 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 komputer virtual Linux dengan Accelerated Networking.

Penembolokan disk data Azure VM

Beban kerja pembacaan Cassandra berkinerja terbaik ketika latensi disk akses acak rendah. Kami merekomendasikan menggunakan disk terkelola Azure dengan caching ReadOnly diaktifkan. Cache ReadOnly memberikan latensi rata-rata yang lebih rendah, karena data dibaca dari cache pada host alih-alih mengakses penyimpanan backend.

Beban kerja baca-berat, baca-acak seperti Cassandra mendapat manfaat dari latensi baca yang lebih rendah meskipun mode cache memiliki batas throughput yang lebih rendah daripada mode tanpa cache. (Misalnya, DS14_v2 mesin virtual memiliki throughput cache maksimum 512 MBps dibandingkan dengan yang tidak di-cache sebesar 768 MBps.)

Caching ReadOnly sangat membantu untuk seri waktu Cassandra dan beban kerja lainnya di mana himpunan data yang sedang digunakan 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 simpul Cassandra dengan kepadatan data 1-2 TB.

Tidak ada penurunan performa yang signifikan akibat cache-misses ketika cache readonly diaktifkan, sehingga mode cache direkomendasikan untuk semua kecuali beban kerja dengan intensitas penulisan tinggi.

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

Linux baca-depan

Pada sebagian besar distribusi Linux yang tersedia untuk Azure di Microsoft Marketplace, pengaturan read-ahead perangkat blok secara 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 dalam 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 Perbandingan dampak pengaturan disk read-ahead (GitHub).

Ukuran potongan disk array mdadm

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 kelebihan kecil yang sedikit terasa untuk ukuran gugus 128k. Oleh karena itu, kami merekomendasikan pendekatan 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 beroperasi penulisan berperforma terbaik ketika log komit berada di disk dengan throughput tinggi dan latensi rendah. Dalam konfigurasi default, Cassandra 3.x memindahkan data dari memori ke berkas catatan komitmen setiap ~10 detik dan tidak menyentuh disk untuk setiap penulisan. Dalam konfigurasi ini, kinerja penulisan hampir identik apakah log komit ada pada disk premium yang terpasang dibandingkan dengan disk lokal atau sementara.

Log komit harus bersifat permanen, sehingga node yang di-restart dapat membangun kembali data apapun yang belum ada dalam file data dari log komit yang telah di-flush. Untuk durabilitas yang lebih baik, simpan log penerapan pada SSD 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 saat log penerapan berada di sistem file xfs versus ext4. Mengaktifkan kompresi log komit menyelaraskan performa xfs dengan ext4. Xfs terkompresi berkinerja sebaik ext4 terkompresi dan non-terkompresi dalam pengujian kami.

Untuk informasi selengkapnya, lihat Pengamatan pada sistem file ext4 dan xfs, serta 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 pengujian 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 kinerja dasar untuk egress jaringan pada VM dapat membantu mengesampingkan jaringan sebagai kemacetan.

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

Ukuran dokumen

Kinerja baca dan tulis Cassandra tergantung pada 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 ketika mereka menggunakan disk premium yang terpasang dan bahkan 5 ketika mereka 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 Anda menggunakan RF yang lebih besar dari 1 dan tingkat konsistensi LOCAL_QUORUM, biasanya performa baca dan tulis lebih rendah dari 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 berkas reguler dan memanfaatkan 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, saat menjalankan pengujian performa baca terhadap data yang sama, bacaan kedua dan berikutnya kemudian tampak jauh lebih cepat daripada bacaan asli, yang diperlukan untuk mengakses data pada disk data jarak jauh atau dari cache host saat 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 berada di cache host, dan pembacaan selanjutnya lebih cepat bahkan setelah membersihkan cache halaman OS dan memulai ulang layanan Cassandra.

Untuk informasi selengkapnya, lihat Pengamatan tentang penggunaan caching halaman di Linux oleh Cassandra (GitHub).

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. Perkirakan adanya jeda ketika data muncul di wilayah kedua saat Anda menggunakan konsistensi penulisan LOCAL_QUORUM, atau penurunan performa penulisan yang signifikan saat Anda 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 tetap menjadi tantangan yang belum terkelola 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 penyerahan isyarat

Dalam cincin Cassandra multiregion, pengerjaan penulisan dengan tingkat konsistensi LOCAL_QUORUM mungkin mengalami kehilangan data di wilayah sekunder. Secara bawaan, hinted handoff Cassandra dibatasi pada throughput maksimum yang relatif rendah dan masa berlaku petunjuk tiga jam. Untuk beban kerja dengan penulisan intensif, sebaiknya tingkatkan batas laju handoff yang diisyaratkan dan periode 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 Performa Azure VM.

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

  • Last updated on