Lindorm memungkinkan Anda membuat instance di beberapa zona. Dalam solusi penyebaran multi-zona, instance Lindorm ditempatkan di beberapa zona untuk meningkatkan kemampuan pemulihan bencana dan menjamin konsistensi data yang kuat di berbagai zona. Anda dapat mengirim permintaan ke instance Lindorm, yang akan mengembalikan hasil dengan cepat jika konsistensi akhir diperlukan untuk data, sehingga meningkatkan kualitas layanan bisnis online Anda.
Perbandingan dengan arsitektur tradisional
Ikhtisar pemulihan bencana primer/sekunder tradisional
Untuk pemulihan bencana primer/sekunder tradisional, Anda dapat membeli dua instance bernama Primary Instance 1 dan Secondary Instance 2 di Zona A dan Zona B guna memastikan ketersediaan tinggi. Anda dapat menggunakan Layanan Terowongan Lindorm (LTS) untuk melakukan sinkronisasi dua arah antara instance Lindorm. Jika Primary Instance 1 gagal atau Zona A tidak tersedia, Anda dapat beralih koneksi ke Secondary Instance 2 atau Zona B untuk memastikan ketersediaan tinggi. Gambar berikut menunjukkan arsitektur ketersediaan tinggi dari pemulihan bencana primer/sekunder.
Solusi pemulihan bencana primer/sekunder dapat memenuhi persyaratan ketersediaan tinggi sebagian besar pengguna. Namun, solusi ini tidak cocok untuk semua skenario bisnis karena memiliki kekurangan sebagai berikut:
Latensi terjadi saat data disinkronkan antara instance primer dan sekunder, sehingga konsistensi data yang kuat tidak dapat dijamin.
Sinkronisasi data antara instance primer dan sekunder dilakukan secara asinkron. Data bisnis hanya dapat disinkronkan ke Secondary Instance 2 setelah ditulis ke Primary Instance 1. Saat failover dilakukan, data terbaru tidak dapat segera dibaca untuk aplikasi bisnis. Namun, data terbaru perlu segera diperoleh untuk aplikasi bisnis. Jika bisnis Anda menggunakan antarmuka semantik atomik seperti Increment dan CheckAndPut untuk membaca data sebelum data ditulis dan data terbaru gagal dibaca, data menjadi tidak sesuai urutan atau terjadi rollback data. Jika masalah terjadi pada jaringan di Zona A, data di Zona B tetap hilang karena latensi sinkronisasi selama periode waktu sebelum jaringan di Zona A pulih.
Pemanfaatan sumber daya instance sekunder tidak optimal.
Dalam skenario pemulihan bencana primer/sekunder, sumber daya instance sekunder tidak digunakan sebagian besar waktu. Sumber daya hanya diakses selama failover.
Administrator database harus melakukan failover.
Pemulihan bencana primer/sekunder harus diselesaikan di sisi bisnis. Administrator database aplikasi bisnis perlu memperhatikan status instance primer. Saat instance primer gagal, administrator database menentukan apakah akan memindahkan beban kerja ke instance sekunder. Anda perlu menentukan logika dan solusi kustom untuk failover, yang dapat memengaruhi bisnis Anda.
Masalah-masalah di atas terjadi saat menggunakan pemulihan bencana primer/sekunder tradisional. Fitur penyebaran multi-zona yang disediakan oleh Lindorm dapat digunakan untuk menyelesaikan masalah-masalah tersebut.
Ikhtisar multi-zona penyebaran ketersediaan tinggi Lindorm
Lindorm mendukung penyebaran multi-zona. Setiap partisi tabel lebar dalam instance Lindorm memiliki replika independen di setiap zona. Log Write-Ahead Logging (WAL) disimpan di LindormDFS dasar Zona C. Jika Zona A tidak tersedia, data di Zona C digunakan untuk memulihkan data di Zona B. Data antar replika disinkronkan menggunakan protokol konsensus replika yang disediakan oleh Lindorm. Untuk menyinkronkan data antar replika, data dari setidaknya dua replika diperlukan. Dalam mode penyebaran multi-zona, Lindorm memungkinkan Anda mengonfigurasi tingkat konsistensi tabel untuk memenuhi persyaratan bisnis yang berbeda, termasuk konsistensi kuat dan konsistensi akhir.
Konsistensi kuat: Jika Anda menetapkan tingkat konsistensi tabel ke konsistensi kuat, data hanya dapat dibaca dari partisi utama tabel dan hanya dapat ditulis ke partisi utama. Partisi sekunder hanya dapat menerima data dari partisi utama melalui protokol konsensus replika. Saat semua server di zona utama dihentikan atau zona tidak tersedia, Lindorm secara otomatis memilih zona utama baru. Diperlukan waktu untuk mempromosikan zona sekunder menjadi zona utama. Dalam mode konsistensi kuat, Anda dapat membaca data terbaru yang telah ditulis.
Konsistensi akhir: Konsistensi akhir juga disebut konsistensi lemah. Jika Anda menetapkan tingkat konsistensi tabel ke konsistensi akhir, data dapat dibaca dari partisi utama dan partisi sekunder tabel, serta ditulis ke partisi utama dan partisi sekunder tabel. Protokol konsensus replika digunakan untuk menyinkronkan data yang ditulis di Zona A ke Zona B. Data replika mungkin tidak konsisten karena data disinkronkan secara asinkron. Dalam kebanyakan kasus, latensi sinkronisasi adalah 100 ms. Dalam mode konsistensi akhir, data dapat dibaca dari partisi utama dan partisi sekunder tabel, serta ditulis ke partisi utama dan partisi sekunder tabel. Jika Zona A tidak tersedia dan terjadi gangguan seperti glitch atau kegagalan server selama operasi penulisan dan pembacaan data, Lindorm dapat secara otomatis memilih Zona B untuk mengirim permintaan. Ini membantu memastikan ketersediaan tinggi dan mengurangi glitch operasi baca dan tulis.
Fitur
Lindorm menggunakan arsitektur terdistribusi yang menyediakan ketersediaan tinggi. Beberapa bisnis memiliki persyaratan ketersediaan yang lebih tinggi. Dalam hal ini, Lindorm perlu menangani beberapa kegagalan server dan masalah ekstrem seperti ketidaktersediaan jaringan dan bencana tingkat kota. Penyebaran multi-zona yang disediakan oleh Lindorm mendukung fitur-fitur berikut, yang dapat digunakan untuk memastikan bahwa database berjalan seperti yang diharapkan dalam berbagai kondisi tak terduga.
Penyebaran multi-zona menyediakan kemampuan pemulihan bencana pada tingkat pusat data atau tingkat kota.
Persyaratan konsistensi data yang kuat atau persyaratan konsistensi data akhir dari instance Lindorm dapat dipenuhi.
Identifikasi gangguan dan operasi failover dipicu secara otomatis oleh Lindorm. Metode ini mudah digunakan.
Tabel berikut membandingkan fitur dalam skenario di mana penyebaran multi-zona dengan ketersediaan tinggi, pemulihan bencana primer/sekunder, dan protokol konsistensi berbasis Paxos atau Raft digunakan.
Fitur | Penyebaran multi-zona dengan ketersediaan tinggi | Pemulihan bencana primer/sekunder | Protokol konsistensi berbasis Paxos atau Raft | |
Konsistensi kuat | Konsistensi akhir | |||
Kehilangan data (recovery point objective (RPO)) | 0 | < 100 ms | < 1s | 0 |
Pemulihan layanan (recovery time objective (RTO)) | 1 menit | 10s hingga 30s | RTO ditentukan berdasarkan periode waktu yang diperlukan untuk melakukan operasi failover. | 30 detik hingga 3 menit |
Waktu respons akses | Akses data di zona utama. Dalam hal ini, data mungkin dibaca dan ditulis di beberapa zona. | Akses data di zona terdekat. Dalam hal ini, data dapat dibaca dari dan ditulis ke beberapa zona, mengurangi glitch. | Akses data di zona utama. Dalam hal ini, data mungkin dibaca dan ditulis di beberapa zona. | Akses data di zona utama. Dalam hal ini, data mungkin dibaca dan ditulis di beberapa zona. |
Kemudahan penggunaan | Solusi ini tidak memengaruhi bisnis. | Solusi ini tidak memengaruhi bisnis. | Bisnis perlu ditransformasi. Tautan sinkronisasi eksternal disediakan. Anda dapat beralih tautan berdasarkan kebutuhan bisnis. | Solusi ini tidak memengaruhi bisnis. |
Jumlah zona minimum yang diperlukan untuk menyimpan log dan data |
|
|
|
|
Dibandingkan dengan solusi pemulihan bencana primer/sekunder tradisional dan solusi berbasis protokol konsistensi berbasis Paxos atau Raft, penyebaran multi-zona Lindorm memberikan akses data yang lebih fleksibel, waktu pemulihan layanan yang lebih singkat, dan kemudahan penggunaan yang lebih tinggi.
Untuk penyebaran multi-zona dengan ketersediaan tinggi Lindorm, identifikasi gangguan dan failover untuk tabel lebar instance Lindorm ditentukan oleh instance tanpa memandang apakah konsistensi kuat atau konsistensi lemah diperlukan. Seluruh proses ini transparan bagi pengguna. Anda dapat mengakses satu instance Lindorm untuk membaca dan menulis data. Anda tidak perlu mengembangkan middleware untuk menghubungkan beberapa instance dan beralih antar instance.
Jika bisnis Anda tidak memerlukan konsistensi kuat, kami sarankan Anda memilih instance Lindorm multi-zona dan menetapkan tingkat konsistensi tabel Anda ke konsistensi akhir.
Jika bisnis Anda memerlukan konsistensi kuat, kami sarankan Anda memilih instance Lindorm multi-zona dan menetapkan tingkat konsistensi tabel Anda ke konsistensi kuat.
Batasan
Klien open-source, seperti klien HBase open-source, tidak mendukung penyebaran instance Lindorm dalam mode multi-zona dengan ketersediaan tinggi.
Penyebaran multi-zona hanya berlaku untuk LindormTable. Oleh karena itu, fitur yang bergantung pada mesin lain, seperti indeks pencarian dan indeks kolom, tidak didukung oleh instance Lindorm multi-zona. Fitur yang didukung oleh LindormTable, seperti indeks sekunder, kolom dinamis, dan kolom wildcard, juga didukung oleh instance Lindorm multi-zona.
Fitur penyimpanan dingin dan pemisahan data panas-dingin tidak didukung oleh instance Lindorm multi-zona.
Beli instance Lindorm yang ditempatkan dalam mode multi-zona dengan ketersediaan tinggi
Anda dapat membeli instance Lindorm yang ditempatkan dalam mode multi-zona dengan ketersediaan tinggi di konsol Lindorm. Untuk informasi lebih lanjut, lihat Buat instance.
Gunakan instance Lindorm yang ditempatkan dalam mode multi-zona dengan ketersediaan tinggi
Pilih tingkat konsistensi
Dalam kebanyakan kasus, tingkat konsistensi tabel yang dibuat untuk instance Lindorm diatur ke konsistensi akhir secara default. Konsistensi akhir dapat memenuhi persyaratan konsistensi sebagian besar pengguna untuk memastikan ketersediaan tinggi dan mengurangi glitch. Kami sarankan Anda menggunakan model konsistensi akhir. Dalam kebanyakan kasus, data yang dihasilkan sebelum 100 ms dapat dibaca. Anda dapat menggunakan klien Lindorm untuk membaca dan menulis data di zona terdekat. Jika klien baca dan klien tulis Anda berada di zona yang sama, data yang dibaca oleh klien adalah data terbaru. Partisi di zona saat ini tetap tersedia atau tidak timeout meskipun terjadi masalah seperti glitch atau shutdown server. Jika bisnis Anda memiliki persyaratan berikut, atur tingkat konsistensi tabel Anda ke konsistensi kuat:
Data terbaru harus dibaca.
Antarmuka semantik atomik seperti Increment dan CheckAndPut perlu digunakan.
Indeks sekunder untuk tabel harus dibuat.
Dalam mode konsistensi kuat, jitter dan glitch tidak dapat dikurangi dengan membaca beberapa replika di Lindorm. Jika zona utama gagal, diperlukan waktu untuk mempromosikan zona sekunder menjadi zona utama.
Buat tabel dan konfigurasikan tingkat konsistensi tabel
API HBase dan HBase shell tidak menjamin konsistensi data. Jika Anda menggunakan API HBase untuk mengakses LindormTable, gunakan API HBase dan HBase shell untuk membuat tabel. Secara default, tingkat konsistensi tabel yang dibuat diatur ke konsistensi akhir. Anda dapat melakukan langkah-langkah berikut untuk memodifikasi atribut CONSISTENCY tabel.
Gunakan Lindorm-cli untuk terhubung keLindormTable dan jalankan pernyataan SQL untuk mengakses LindormTable. Untuk informasi lebih lanjut, lihat Gunakan Lindorm-cli untuk terhubung dan menggunakan LindormTable.
Konfigurasikan atribut CONSISTENCY tabel.
Saat Anda membuat tabel, jalankan pernyataan berikut untuk mengatur atribut CONSISTENCY tabel ke konsistensi kuat:
CREATE TABLE dt ( p1 INT, p2 INT, c1 VARCHAR, c2 BIGINT, PRIMARY KEY(p1) ) WITH (CONSISTENCY='strong');Saat Anda membuat tabel, jalankan pernyataan berikut untuk mengatur atribut CONSISTENCY tabel ke konsistensi akhir:
CREATE TABLE dt2 ( p1 INT, p2 INT, c1 VARCHAR, c2 BIGINT, PRIMARY KEY(p1) ) WITH (CONSISTENCY='eventual');Setelah tabel dibuat, jalankan pernyataan berikut untuk mengubah nilai atribut CONSISTENCY untuk tabel menjadi konsistensi akhir:
ALTER TABLE dt SET CONSISTENCY='enventual';Setelah tabel dibuat, jalankan pernyataan berikut untuk mengubah nilai atribut CONSISTENCY untuk tabel menjadi konsistensi kuat:
ALTER TABLE dt2 SET CONSISTENCY='strong';
Tulis data ke tabel lebar
Instance Lindorm yang ditempatkan dalam mode multi-zona dengan ketersediaan tinggi digunakan dengan cara yang sama seperti instance single-zona. Hubungkan ke LindormTable dan tulis data ke tabel lebar. Untuk informasi lebih lanjut, lihat Gunakan Lindorm-cli untuk terhubung dan menggunakan LindormTable.
Impor data ke tabel lebar
Anda dapat memanggil operasi API untuk mengimpor data ke instance Lindorm yang ditempatkan dalam mode multi-zona atau dalam mode multi-zona dengan ketersediaan tinggi. Anda hanya perlu memperoleh titik akhir instance Lindorm di konsol Lindorm dan menggunakan titik akhir tersebut untuk mengimpor data.
Jika Anda menggunakan BulkLoad untuk mengimpor data ke instance Lindorm yang ditempatkan dalam mode multi-zona dengan ketersediaan tinggi, impor salinan data di setiap zona. Jika Anda memiliki pertanyaan saat mengimpor data, hubungi dukungan teknis.