Praktik terbaik untuk ketersediaan tinggi dan pemulihan bencana

Azure Managed Instance for Apache Cassandra adalah layanan terkelola penuh untuk kluster Apache Cassandra sumber terbuka murni. Layanan ini memungkinkan konfigurasi untuk diubah, tergantung pada kebutuhan setiap beban kerja, yang memungkinkan fleksibilitas dan kontrol maksimum saat dibutuhkan.

Apache Cassandra adalah pilihan tepat untuk membangun aplikasi yang sangat tangguh karena sifat terdistribusi dan arsitektur peer-to-peer. Simpul apa pun dalam database dapat menyediakan fungsionalitas yang sama dengan simpul lain. Desain ini berkontribusi pada kekuatan dan ketahanan Cassandra. Artikel ini memberikan tips tentang cara mengoptimalkan ketersediaan tinggi dan cara mendekati pemulihan bencana.

Tujuan titik pemulihan dan tujuan waktu pemulihan

Selama Anda memiliki elemen berikut, tujuan titik pemulihan (RPO) dan tujuan waktu pemulihan (RTO) keduanya biasanya rendah, mendekati nol:

• Penyebaran beberapa wilayah dengan replikasi lintas wilayah dan faktor replikasi 3.
• Zona ketersediaan yang diaktifkan. Konfigurasikan opsi ini saat Anda membuat kluster di portal Microsoft Azure atau dengan menggunakan Azure CLI.
• Mengonfigurasi failover pada tingkat aplikasi dengan menggunakan kebijakan penyeimbangan beban di driver klien atau failover pada tingkat penyeimbangan beban dengan menggunakan Azure Traffic Manager atau Azure Front Door.

RTO adalah berapa lama sistem tidak beroperasi selama pemadaman. Ini rendah karena kluster tangguh di seluruh zona dan wilayah. Selain itu, Apache Cassandra sendiri adalah sistem peer-to-peer yang sangat toleran terhadap kesalahan, di mana semua simpul dapat menulis secara default.

RPO adalah berapa banyak data yang dapat Anda hilangkan dalam pemadaman. Ini rendah karena data disinkronkan antara semua simpul dan pusat data. Kehilangan data dalam pemadaman akan minimal.

Catatan

Tidak dimungkinkan untuk mencapai RTO=0 dan RPO=0 per teori CAP. Evaluasi keseimbangan antara konsistensi dan ketersediaan atau performa yang optimal.

Saldo ini terlihat berbeda untuk setiap aplikasi. Misalnya, jika aplikasi Anda memiliki beban baca tinggi, mungkin lebih baik menerima peningkatan latensi penulisan di lintas wilayah untuk menghindari kehilangan data, yang lebih mengutamakan konsistensi. Jika aplikasi berfokus pada penulisan dengan persyaratan latensi yang ketat, risiko kehilangan beberapa penulisan terbaru dalam pemadaman regional besar mungkin dapat diterima, yang mendukung ketersediaan.

Zona ketersediaan

Arsitektur peer-to-peer Cassandra membawa toleransi kesalahan dari bawah ke atas. Azure Managed Instance for Apache Cassandra menyediakan dukungan untuk zona ketersediaan di wilayah yang dipilih. Dukungan ini meningkatkan ketahanan di tingkat infrastruktur. Untuk faktor replikasi 3, dukungan zona ketersediaan memastikan bahwa setiap replika berada di zona ketersediaan yang berbeda. Pendekatan ini mencegah pemadaman zona memengaruhi database atau aplikasi Anda. Sebaiknya aktifkan zona ketersediaan jika memungkinkan.

Redundansi multi-wilayah

Arsitektur Cassandra, ditambah dengan dukungan zona ketersediaan Azure, memberi Anda tingkat toleransi dan ketahanan kesalahan. Pertimbangkan juga dampak pemadaman regional untuk aplikasi Anda. Untuk melindungi dari pemadaman tingkat wilayah, kami sangat menyarankan untuk menyebarkan beberapa kluster wilayah. Meskipun jarang terjadi, dampak potensialnya sangat parah.

Untuk kelangsungan bisnis, tidak cukup untuk menggunakan database beberapa wilayah. Bagian lain dari aplikasi Anda juga perlu didistribusikan atau memiliki mekanisme pengalihan kegagalan yang memadai. Jika pengguna Anda tersebar di banyak lokasi geografis, penyebaran pusat data beberapa wilayah untuk database Anda memiliki manfaat tambahan untuk mengurangi latensi. Semua simpul di semua pusat data di seluruh kluster dapat melayani permintaan baca dan tulis dari wilayah terdekat dengan mereka.

Jika aplikasi dikonfigurasi agar aktif-aktif, pertimbangkan bagaimana teori CAP berlaku pada konsistensi data Anda di antara replika (node-node) dan kompromi yang diperlukan untuk mempertahankan ketersediaan tinggi.

Dalam istilah teorem CAP, Cassandra secara default adalah sistem database Available Partition-tolerant (AP), dengan konsistensi yang sangat dapat disesuaikan. Untuk sebagian besar kasus penggunaan, sebaiknya gunakan LOCAL_QUORUM untuk membaca.

• Dalam aktif-pasif untuk penulisan, ada trade-off antara keandalan dan performa. Untuk keandalan, kami merekomendasikan QUORUM_EACH tetapi bagi sebagian besar pengguna LOCAL_QUORUM atau KUORUM adalah kompromi yang baik. Jika ada pemadaman regional, beberapa data mungkin hilang di LOCAL_QUORUM.

• Jika aplikasi berjalan secara paralel, lebih disarankan menggunakan penulisan QUORUM_EACH dalam sebagian besar kasus agar memastikan konsistensi antara dua pusat data.

• Jika tujuan Anda adalah untuk mendukung konsistensi, atau RPO yang lebih rendah, daripada latensi atau ketersediaan, atau RTO yang lebih rendah, pengaturan konsistensi dan faktor replikasi Anda harus mencerminkan tujuan ini.

  Secara umum, jumlah simpul kuorum yang diperlukan untuk baca ditambah jumlah node kuorum yang diperlukan untuk penulisan harus lebih besar dari faktor replikasi. Misalnya, jika Anda memiliki faktor replikasi 3, dan quorum_one pada bacaan (satu simpul), Anda harus melakukan quorum_all pada tulis (tiga node), sehingga total 4 lebih besar dari faktor replikasi 3.

Catatan

Operator bidang kendali untuk Azure Managed Instance for Apache Cassandra hanya diimplementasikan di satu wilayah. Wilayah yang dipilih ketika Anda menerapkan pusat data pertama. Jika terjadi pemadaman total wilayah yang tidak mungkin, kami berkomitmen untuk waktu pemulihan 3 jam karena gagal atas sarana kontrol ke wilayah lain.

Karena pusat data masih harus terus berfungsi, masalah ini tidak memengaruhi ketersediaan SLA untuk layanan. Selama periode ini, mungkin tidak mungkin untuk membuat perubahan pada konfigurasi database dari portal Microsoft Azure atau alat penyedia sumber daya.

Replikasi

Kami merekomendasikan untuk mengaudit keyspaces dan pengaturan replikasinya secara berkala untuk memastikan bahwa replikasi yang diperlukan antara pusat data telah dikonfigurasi dengan benar. Pada tahap awal pengembangan, kami sarankan Anda melakukan pengujian sederhana menggunakan cqlsh. Misalnya, sisipkan nilai saat tersambung ke satu pusat data dan baca dari pusat data lainnya.

Secara khusus, ketika Anda menyiapkan pusat data kedua di mana pusat data yang ada sudah memiliki data, tentukan bahwa Anda mereplikasi semua data dan bahwa sistem siap. Kami menyarankan agar Anda memantau kemajuan replikasi melalui perintah DBA kami dengan nodetool netstats. Pendekatan alternatif adalah menghitung baris di setiap tabel. Perlu diingat bahwa dengan ukuran big data, karena sifat Cassandra yang didistribusikan, pendekatan ini hanya dapat memberikan perkiraan kasar.

Menyeimbangkan biaya pemulihan bencana

Jika aplikasi Anda aktif-pasif, kami masih umumnya menyarankan Agar Anda menyebarkan kapasitas yang sama di setiap wilayah. Pendekatan ini membantu aplikasi Anda untuk langsung beralih ke pusat data cadangan aktif di wilayah sekunder. Jika pemadaman regional terjadi, pendekatan ini memastikan tidak ada penurunan performa. Sebagian besar driver klien Cassandra menyediakan opsi untuk memulai failover tingkat aplikasi. Secara default, mereka mengasumsikan pemadaman regional berarti bahwa aplikasi juga tidak berfungsi, sehingga failover harus terjadi di tingkat penyeimbang beban.

Untuk mengurangi biaya penyediaan pusat data kedua, Anda mungkin lebih suka menyebarkan SKU yang lebih kecil dan lebih sedikit simpul di wilayah sekunder Anda. Ketika terjadi pemadaman, penskalaan vertikal dan horizontal yang siap pakai mempermudah peningkatan skala di Azure Managed Instance untuk Apache Cassandra. Saat aplikasi Anda beralih ke wilayah sekunder, Anda dapat menambah kapasitas dan meningkatkan simpul secara manual di pusat data sekunder Anda. Pusat data sekunder Anda bertindak sebagai siaga hangat dengan biaya lebih rendah. Mengambil pendekatan ini perlu diseimbangkan terhadap waktu yang diperlukan untuk memulihkan sistem Anda ke kapasitas penuh jika pemadaman terjadi. Penting untuk menguji dan mempraktikkan apa yang terjadi ketika suatu wilayah hilang.

Catatan

Menambah simpul jauh lebih cepat daripada menskalakan keluar. Ingatlah fakta ini ketika Anda mempertimbangkan pertimbangan antara skala vertikal dan horizontal, serta jumlah simpul yang akan didistribusikan di kluster Anda.

Jadwal pencadangan

Pencadangan otomatis di Azure Managed Instance for Apache Cassandra. Anda dapat memilih jadwal Anda sendiri untuk pencadangan harian. Sebaiknya pilih waktu dengan beban yang lebih sedikit. Meskipun cadangan dikonfigurasi untuk hanya menggunakan CPU diam, mereka dapat dalam beberapa keadaan memicu pemadatan di Cassandra, yang dapat menyebabkan peningkatan penggunaan CPU. Pemadatan dapat terjadi kapan saja dalam sistem Cassandra. Mereka bergantung pada beban kerja dan strategi pemadatan yang dipilih.

Penting

Niat pencadangan murni untuk mengurangi kehilangan data yang tidak disengaja atau kerusakan data. Kami tidak merekomendasikan pencadangan sebagai strategi pemulihan bencana.

Pencadangan tidak memiliki redundansi geografis. Bahkan jika ya, dibutuhkan waktu lama untuk memulihkan database dari cadangan. Oleh karena itu, kami sangat merekomendasikan beberapa penyebaran wilayah, ditambah dengan mengaktifkan zona ketersediaan jika memungkinkan, untuk mengurangi skenario bencana, dan untuk dapat pulih secara efektif dari mereka. Pendekatan ini sangat penting dalam skenario langka di mana wilayah yang gagal tidak dapat dipulihkan. Tanpa replikasi multi-wilayah, semua data mungkin hilang.

Langkah selanjutnya

Membuat kluster menggunakan Portal Microsoft Azure