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 juga memungkinkan konfigurasi untuk ditimpa, tergantung pada kebutuhan spesifik setiap beban kerja, memungkinkan fleksibilitas dan kontrol maksimum jika diperlukan.
Apache Cassandra adalah pilihan yang tepat untuk membangun aplikasi yang sangat tangguh karena sifat terdistribusi dan arsitektur tanpa master - node apa pun dalam database dapat memberikan fungsionalitas yang sama persis dengan node lain - berkontribusi pada ketahanan dan ketahanan Cassandra. Artikel ini memberikan tips tentang cara mengoptimalkan ketersediaan tinggi dan cara mendekati pemulihan bencana.
RPO dan RTO
RPO (tujuan titik pemulihan) dan RTO (tujuan waktu pemulihan), keduanya biasanya akan rendah (mendekati nol) untuk Apache Cassandra selama Anda memiliki:
- Penyebaran multi-wilayah dengan replikasi lintas wilayah, dan faktor replikasi 3.
- Zona ketersediaan yang diaktifkan (pilih opsi saat membuat kluster di portal atau melalui Azure CLI).
- Mengonfigurasi failover tingkat aplikasi menggunakan kebijakan penyeimbangan beban di driver klien dan/atau failover tingkat penyeimbangan beban menggunakan manajer lalu lintas/front door Azure.
RTO ("berapa lama Anda mengalami pemadaman") akan rendah karena kluster akan tangguh di seluruh zona dan wilayah, dan karena Apache Cassandra sendiri adalah sistem yang sangat toleran terhadap kesalahan, tanpa master (semua simpul dapat menulis) secara default. RPO ("berapa banyak data yang dapat Anda kehilangan dalam pemadaman") akan rendah karena data akan disinkronkan antara semua simpul dan pusat data, sehingga kehilangan data dalam pemadaman akan minimal.
Catatan
Secara teoritis tidak mungkin untuk mencapai RTO=0 dan RPO=0 per Cap Theorem. Anda harus mengevaluasi trade off antara konsistensi dan ketersediaan/performa optimal - ini akan terlihat berbeda untuk setiap aplikasi. Misalnya, jika aplikasi Anda dibaca berat, mungkin lebih baik untuk mengatasi peningkatan latensi penulisan lintas wilayah untuk menghindari kehilangan data (mendukung konsistensi). Jika aplikasi menulis berat, dan pada anggaran latensi yang ketat, risiko kehilangan beberapa penulisan terbaru dalam pemadaman regional utama mungkin dapat diterima (mendukung ketersediaan).
Zona ketersediaan
Arsitektur masterless Cassandra menghadirkan toleransi kesalahan dari bawah ke atas, dan Azure Managed Instance for Apache Cassandra menyediakan dukungan untuk zona ketersediaan di wilayah yang dipilih untuk meningkatkan ketahanan di tingkat infrastruktur. Mengingat faktor replikasi 3, dukungan zona ketersediaan memastikan bahwa setiap replika berada di zona ketersediaan yang berbeda, sehingga mencegah pemadaman zona memengaruhi database/aplikasi Anda. Sebaiknya aktifkan zona ketersediaan jika memungkinkan.
Redundansi multi-wilayah
Arsitektur Cassandra, ditambah dengan dukungan zona ketersediaan Azure, memberi Anda beberapa tingkat toleransi dan ketahanan kesalahan. Namun, penting untuk mempertimbangkan dampak pemadaman regional untuk aplikasi Anda. Sebaiknya sebarkan kluster multi wilayah untuk melindungi dari pemadaman tingkat wilayah. Meskipun jarang terjadi, dampak potensialnya sangat parah.
Untuk kelangsungan bisnis, tidak cukup untuk hanya membuat database multi-wilayah. Bagian lain dari aplikasi Anda juga perlu disebarkan dengan cara yang sama baik dengan didistribusikan, atau dengan mekanisme yang memadai untuk failover. Jika pengguna Anda tersebar di banyak lokasi geografis, penyebaran pusat data multi-wilayah untuk database Anda memiliki manfaat tambahan untuk mengurangi latensi, karena semua simpul di semua pusat data di seluruh kluster kemudian dapat melayani baca dan tulis dari wilayah yang paling dekat dengan mereka. Namun, jika aplikasi dikonfigurasi menjadi "aktif-aktif", penting untuk mempertimbangkan bagaimana teori CAP berlaku untuk konsistensi data Anda antara replika (simpul), dan trade-off yang diperlukan untuk pengiriman ketersediaan tinggi.
Dalam istilah teorem CAP, Cassandra secara default merupakan sistem database AP (Available Partition-tolerant), dengan konsistensi yang sangat dapat ditunjukkan. Untuk sebagian besar kasus penggunaan, sebaiknya gunakan local_quorum untuk membaca.
- Dalam aktif-pasif untuk menulis ada trade-off antara keandalan dan performa: untuk keandalan kami sarankan QUORUM_EACH tetapi bagi sebagian besar pengguna LOCAL_QUORUM atau QUORUM adalah kompromi yang baik. Namun perhatikan bahwa dalam kasus pemadaman regional, beberapa penulisan mungkin hilang dalam LOCAL_QUORUM.
- Dalam kasus aplikasi yang dijalankan secara paralel QUORUM_EACH tulis lebih disukai untuk sebagian besar kasus untuk memastikan konsistensi antara dua pusat data.
- Jika tujuan Anda adalah untuk mendukung konsistensi (RPO yang lebih rendah) daripada latensi atau ketersediaan (RTO yang lebih rendah), ini harus tercermin dalam pengaturan konsistensi dan faktor replikasi Anda. Sebagai aturan praktis, jumlah node 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 sarana kontrol untuk Azure Managed Instance for Apache Cassandra hanya akan disebarkan dalam satu wilayah (wilayah yang dipilih saat awalnya menyebarkan 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. Ini tidak memengaruhi ketersediaan SLA untuk layanan, karena pusat data masih harus terus berfungsi. Namun, selama periode ini, mungkin tidak mungkin untuk membuat perubahan pada konfigurasi database dari portal atau alat penyedia sumber daya.
Replikasi
Sebaiknya audit keyspaces dan pengaturan replikasinya dari waktu ke waktu untuk memastikan replikasi yang diperlukan antara pusat data telah dikonfigurasi. Pada tahap awal pengembangan, kami sarankan pengujian bahwa semuanya berfungsi seperti yang diharapkan dengan melakukan pengujian sederhana menggunakan cqlsh. Misalnya, menyisipkan nilai saat tersambung ke satu pusat data dan membacanya dari pusat data lainnya.
Secara khusus, saat menyiapkan pusat data kedua di mana pusat data yang ada sudah memiliki data, penting untuk menentukan bahwa semua data telah direplikasi dan sistem siap. Sebaiknya pantau kemajuan replikasi melalui perintah DBA kami dengan nodetool netstats. Pendekatan alternatif adalah menghitung baris di setiap tabel, tetapi perlu diingat bahwa dengan ukuran big data, karena sifat Terdistribusi Cassandra, 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 sehingga aplikasi Anda dapat melakukan failover secara instan ke pusat data "siaga panas" di wilayah sekunder. Ini memastikan tidak ada penurunan performa dalam kasus pemadaman regional. Sebagian besar driver klien Cassandra menyediakan opsi untuk memulai failover tingkat aplikasi. Secara default, mereka mengasumsikan pemadaman regional berarti bahwa aplikasi juga tidak berfungsi, dalam hal ini failover harus terjadi di tingkat penyeimbang beban.
Namun, 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 pemadaman terjadi, peningkatan skala menjadi lebih mudah di Azure Managed Instance for Apache Cassandra dengan penskalaan vertikal dan horizontal turnkey. Meskipun failover aplikasi Anda ke wilayah sekunder, Anda dapat meluaskan skala dan meningkatkan simpul secara manual di pusat data sekunder Anda. Dalam hal ini, pusat data sekunder Anda bertindak sebagai siaga hangat biaya yang lebih rendah. Mengambil pendekatan ini perlu diseimbangkan terhadap waktu yang diperlukan untuk memulihkan sistem Anda ke kapasitas penuh jika terjadi pemadaman. Penting untuk menguji dan mempraktikkan apa yang terjadi ketika suatu wilayah hilang.
Catatan
Meningkatkan simpul jauh lebih cepat daripada menskalakan. Ingatlah hal ini saat mempertimbangkan keseimbangan antara skala vertikal dan horizontal, dan jumlah simpul yang akan disebarkan di kluster Anda.
Jadwal pencadangan
Pencadangan otomatis di Azure Managed Instance for Apache Cassandra, tetapi 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 dengan Cassandra, dan 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 geo-redundan, dan bahkan jika itu, bisa memakan waktu yang sangat lama untuk memulihkan database dari cadangan. Oleh karena itu, kami sangat merekomendasikan penyebaran multi-wilayah, ditambah dengan mengaktifkan zona ketersediaan jika memungkinkan, untuk mengurangi skenario bencana, dan untuk dapat pulih secara efektif dari mereka. Ini sangat penting dalam skenario langka di mana wilayah yang gagal tidak dapat dicakup, di mana tanpa replikasi multi-wilayah, semua data mungkin hilang.
Langkah berikutnya
Dalam artikel ini, kami menyusun beberapa praktik terbaik untuk membangun aplikasi tangguh dengan Cassandra.