Contoh setelan replikasi

Halaman ini menjelaskan beberapa kasus penggunaan umum untuk mengaktifkan replikasi Bigtable, kemudian menyajikan setelan yang dapat Anda gunakan untuk mendukung kasus penggunaan tersebut.

Mengisolasi beban kerja analisis batch dari aplikasi lain
Menciptakan ketersediaan tinggi
Menyediakan pencadangan yang mendekati real-time
Mempertahankan ketersediaan tinggi dan ketahanan regional
Menyimpan data di dekat pengguna

Halaman ini juga menjelaskan cara memutuskan setelan yang akan digunakan jika kasus penggunaan Anda tidak tercantum di sini.

Sebelum membaca halaman ini, Anda harus sudah memahami ringkasan replikasi Bigtable.

Sebelum menambahkan cluster ke instance, Anda harus mengetahui batasan yang berlaku saat mengubah kebijakan pembersihan sampah memori pada tabel replika.

Apa pun kasus penggunaan Anda, selalu sediakan node yang cukup di setiap cluster dalam sebuah instance untuk memastikan bahwa setiap cluster dapat menangani replikasi selain beban yang diterimanya dari aplikasi. Jika cluster tidak memiliki cukup node, penundaan replika dapat meningkat, cluster dapat mengalami masalah performa karena penumpukan memori, dan operasi tulis ke cluster lain dalam instance mungkin ditolak.

Mengisolasi beban kerja analisis batch dari aplikasi lain

Jika Anda menggunakan satu cluster untuk menjalankan tugas analisis batch yang melakukan banyak pembacaan besar bersama aplikasi yang melakukan campuran baca dan tulis, tugas batch besar dapat memperlambat berbagai hal bagi pengguna aplikasi. Dengan replikasi, Anda dapat menggunakan profil aplikasi dengan perutean cluster tunggal untuk merutekan tugas analisis batch dan traffic aplikasi ke berbagai cluster, sehingga tugas batch tidak memengaruhi pengguna aplikasi Anda.

Untuk mengisolasi dua workload:

Buat instance baru dengan 2 cluster, atau tambahkan cluster kedua ke instance yang sudah ada.

Ikuti rekomendasi penggunaan CPU standar untuk konfigurasi ini.
Buat 2 profil aplikasi, satu profil bernama live-traffic dan profil lainnya bernama batch-analytics.

Jika ID cluster Anda adalah cluster-a dan cluster-b, profil aplikasi live-traffic harus mengarahkan permintaan ke cluster-a dan profil aplikasi batch-analytics harus mengarahkan permintaan ke cluster-b. Konfigurasi ini memberikan konsistensi baca-Anda-tulis untuk aplikasi yang menggunakan profil aplikasi yang sama, tetapi tidak untuk aplikasi yang menggunakan profil aplikasi yang berbeda.

Anda dapat mengaktifkan transaksi baris tunggal di profil aplikasi live-traffic jika diperlukan. Anda tidak perlu mengaktifkan transaksi baris tunggal di profil aplikasi batch-analytics, dengan asumsi bahwa Anda hanya akan menggunakan profil aplikasi ini untuk pembacaan.
Gunakan profil aplikasi live-traffic untuk menjalankan beban kerja traffic live.
Saat beban kerja traffic live sedang berjalan, gunakan profil aplikasi batch-analytics untuk menjalankan beban kerja batch hanya baca.
Pantau penggunaan CPU untuk cluster instance, dan tambahkan node ke cluster jika perlu.
Pantau latensi sisi klien menggunakan alat pilihan Anda. Jika menggunakan klien HBase untuk Java, Anda dapat memantau latensi dengan metrik sisi klien.

Untuk mengisolasi dua workload yang lebih kecil dari satu workload yang lebih besar:

Buat instance baru dengan 3 cluster, atau tambahkan cluster ke instance yang ada hingga instance memiliki 3 cluster.

Ikuti rekomendasi penggunaan CPU standar untuk konfigurasi ini.

Langkah-langkah ini mengasumsikan bahwa cluster Anda menggunakan ID cluster-a, cluster-b, dan cluster-c.

Gunakan jumlah node yang sama dalam cluster-a dan cluster-b jika melayani aplikasi yang sama. Gunakan jumlah node yang lebih besar di cluster-c untuk mendukung beban kerja yang lebih besar.
Buat profil aplikasi berikut:
- live-traffic-app-a: Perutean cluster tunggal dari aplikasi Anda ke cluster-a
- live-traffic-app-b: Perutean cluster tunggal dari aplikasi Anda ke cluster-b
- batch-analytics: Perutean cluster tunggal dari tugas analisis batch ke cluster-c
Gunakan profil aplikasi live traffic untuk menjalankan workload traffic live.
Saat beban kerja traffic live sedang berjalan, gunakan profil aplikasi batch-analytics untuk menjalankan beban kerja batch hanya baca.
Pantau penggunaan CPU untuk cluster instance, dan tambahkan node ke cluster jika perlu.
Pantau latensi sisi klien menggunakan alat pilihan Anda. Jika menggunakan klien HBase untuk Java, Anda dapat memantau latensi dengan metrik sisi klien.

Membuat ketersediaan tinggi (HA)

Jika instance hanya memiliki 1 cluster, ketahanan dan ketersediaan data Anda terbatas pada zona tempat cluster tersebut berada. Replikasi dapat meningkatkan ketahanan dan ketersediaan dengan menyimpan salinan data Anda secara terpisah di beberapa zona atau region, dan secara otomatis menggagalkan antar-cluster jika diperlukan.

Untuk mengonfigurasi instance Anda untuk kasus penggunaan ketersediaan tinggi (HA), buat profil aplikasi baru yang menggunakan perutean multi-cluster, atau perbarui profil aplikasi default untuk menggunakan perutean multi-cluster. Konfigurasi ini memberikan konsistensi akhir. Anda tidak akan dapat mengaktifkan transaksi baris tunggal karena transaksi baris tunggal dapat menyebabkan konflik data saat Anda menggunakan perutean multi-cluster.

Untuk mempelajari lebih lanjut cara Bigtable membantu mencapai ketersediaan tinggi, lihat Membangun Kehadiran Data Global dengan Bigtable .

Konfigurasi untuk meningkatkan ketersediaan mencakup hal berikut.

Cluster di 3 region atau lebih yang berbeda (konfigurasi yang direkomendasikan). Konfigurasi yang direkomendasikan untuk HA adalah instance yang memiliki cluster N+2 yang masing-masing berada di region berbeda. Misalnya, jika jumlah minimum cluster yang Anda perlukan untuk menyajikan data adalah 2, Anda memerlukan instance 4 cluster untuk mempertahankan HA. Konfigurasi ini memberikan waktu beroperasi meskipun 2 region menjadi tidak tersedia. Sebaiknya Anda menyebarkan cluster di beberapa benua.

Contoh konfigurasi:
- cluster-a di zona us-central1-a di Iowa
- cluster-b di zona europe-west1-d di Belgia
- cluster-c di zona asia-east1-b di Taiwan
Untuk konfigurasi ini, sediakan node yang cukup untuk mempertahankan target pemakaian CPU sebesar 23% untuk instance 3 cluster, 3 region, dan 35% pemakaian CPU untuk instance 4 cluster dengan 4 region. Hal ini memastikan bahwa meskipun 2 region tidak tersedia, cluster atau cluster yang tersisa dapat melayani semua traffic.
Dua cluster berada di region yang sama, tetapi zonanya berbeda. Opsi ini memberikan ketersediaan tinggi dalam ketersediaan region, kemampuan untuk melakukan failover tanpa menimbulkan biaya replikasi lintas region, dan tanpa peningkatan latensi pada failover. Data Anda dalam instance Bigtable yang direplikasi tersedia selama zona tempatnya direplikasi tersedia.

Contoh konfigurasi:
- cluster-a di zona australia-southeast1-a di Sydney
- cluster-b di zona australia-southeast1-b di Sydney
Ikuti rekomendasi penggunaan CPU standar untuk konfigurasi ini.
Dua cluster di region berbeda. Konfigurasi multi-region ini menyediakan ketersediaan tinggi seperti konfigurasi multi-zona sebelumnya, tetapi data Anda tetap tersedia meskipun Anda tidak dapat terhubung ke salah satu region.

Anda akan dikenai biaya untuk mereplikasi operasi tulis antar-region.

Contoh konfigurasi:
- cluster-a di zona asia-northeast1-c di Tokyo
- cluster-b di zona asia-east2-b di Hong Kong
Ikuti rekomendasi penggunaan CPU standar untuk konfigurasi ini.
Dua klaster di region A dan klaster ketiga di region B. Opsi ini membuat data Anda tersedia meskipun Anda tidak dapat terhubung ke salah satu region, dan memberikan kapasitas tambahan di region A.

Anda akan dikenai biaya untuk mereplikasi operasi tulis antar-region. Jika menulis ke region A, Anda akan dikenai biaya sekali karena hanya memiliki 1 cluster di region B. Jika menulis ke region B, Anda akan ditagih dua kali karena memiliki 2 cluster di region A.

Contoh konfigurasi:
- cluster-a di zona europe-west1-b di Belgia
- cluster-b di zona europe-west1-d di Belgia
- cluster-c di zona europe-north1-c di Finlandia
Mulailah dengan target penggunaan CPU sebesar 35% di region dengan 2 cluster dan 70% di region lain. Pantau cluster instance dan sesuaikan jumlah node sesuai kebutuhan sehingga setiap cluster memiliki resource yang cukup untuk menangani failover.

Anda dapat menyimulasikan failover untuk kasus penggunaan ini guna menguji aplikasi Anda:

Gunakan profil aplikasi dengan perutean multi-cluster untuk menjalankan beban kerja pengujian.
Gunakan konsol Google Cloud untuk memantau cluster instance dan memastikan bahwa cluster menangani permintaan masuk.
Menghapus salah satu cluster untuk melakukan simulasi pemadaman.

Perubahan ini juga akan menghapus salinan data Anda yang disimpan di cluster.
Terus pantau latensi dan tingkat error. Jika cluster yang tersisa memiliki resource CPU yang cukup, cluster tersebut harus dapat memenuhi permintaan masuk.
Menambahkan cluster ke instance tersebut, dan terus memantau instance tersebut. Data akan mulai direplikasi ke cluster baru.

Menyediakan pencadangan hampir secara real-time

Dalam beberapa kasus—misalnya, jika Anda tidak dapat membaca data yang tidak berlaku—Anda harus selalu merutekan permintaan ke satu cluster. Namun, Anda masih dapat menggunakan replikasi dengan menangani permintaan dengan satu cluster dan menyimpan cluster lain sebagai cadangan yang mendekati real-time. Jika cluster penyaluran tidak tersedia, Anda dapat meminimalkan periode nonaktif dengan menggagalkan cluster cadangan secara manual.

Untuk mengonfigurasi instance Anda untuk kasus penggunaan ini, buat profil aplikasi yang menggunakan perutean cluster tunggal, atau perbarui profil aplikasi default agar menggunakan perutean cluster tunggal. Cluster yang Anda tentukan dalam profil aplikasi menangani permintaan masuk. Cluster lainnya bertindak sebagai cadangan jika Anda perlu melakukan failover. Pengaturan ini terkadang dikenal sebagai konfigurasi pasif aktif, dan memberikan konsistensi yang kuat dan konsistensi baca-Anda-tulis. Anda dapat mengaktifkan transaksi baris tunggal di profil aplikasi jika diperlukan.

Ikuti rekomendasi penggunaan CPU standar untuk konfigurasi ini.

Untuk menerapkan konfigurasi ini:

Gunakan profil aplikasi dengan perutean cluster tunggal untuk menjalankan beban kerja.
Gunakan konsol Google Cloud untuk memantau cluster instance dan pastikan hanya 1 cluster yang menangani permintaan masuk.

Cluster lainnya masih akan menggunakan resource CPU untuk melakukan replikasi dan tugas pemeliharaan lainnya.
Update profil aplikasi agar mengarah ke cluster kedua di instance Anda.

Anda akan menerima peringatan tentang kehilangan konsistensi baca-Anda-tulis, yang juga berarti Anda kehilangan konsistensi yang kuat.

Jika mengaktifkan transaksi baris tunggal, Anda juga akan menerima peringatan tentang potensi kehilangan data. Anda akan kehilangan data jika mengirim penulisan yang bertentangan saat failover terjadi.
Lanjutkan untuk memantau instance Anda. Anda akan melihat bahwa cluster kedua menangani permintaan masuk.

Mempertahankan ketersediaan tinggi dan ketahanan regional

Misalnya Anda memiliki konsentrasi pelanggan di dua wilayah berbeda di satu benua. Anda ingin melayani setiap konsentrasi pelanggan dengan cluster Bigtable sedekat mungkin dengan pelanggan. Anda ingin data Anda sangat tersedia di setiap region, dan Anda mungkin menginginkan opsi failover jika satu atau beberapa cluster tidak tersedia.

Untuk kasus penggunaan ini, Anda dapat membuat instance dengan 2 cluster di region A dan 2 cluster di region B. Konfigurasi ini memberikan ketersediaan tinggi meskipun Anda tidak dapat terhubung ke region Google Cloud. Hal ini juga memberikan ketahanan regional karena meskipun suatu zona menjadi tidak tersedia, cluster lain di region zona tersebut masih tersedia.

Anda dapat memilih untuk menggunakan perutean multi-cluster atau perutean cluster tunggal untuk kasus penggunaan ini, bergantung pada kebutuhan bisnis Anda.

Untuk mengonfigurasi instance Anda untuk kasus penggunaan ini:

Buat instance Bigtable dengan 4 cluster: 2 di region A dan 2 di region B. Cluster di region yang sama harus berada di zona yang berbeda.

Contoh konfigurasi:
- cluster-a di zona asia-south1-a di Mumbai
- cluster-b di zona asia-south1-c di Mumbai
- cluster-c di zona asia-northeast1-a di Tokyo
- cluster-d di zona asia-northeast1-b di Tokyo
Menempatkan server aplikasi di dekat tiap region.

Anda dapat memilih untuk menggunakan perutean multi-cluster atau perutean cluster tunggal untuk kasus penggunaan ini, bergantung pada kebutuhan bisnis Anda. Jika Anda menggunakan perutean multi-cluster, Bigtable menangani failover secara otomatis. Jika menggunakan perutean cluster tunggal, Anda harus menggunakan penilaian Anda sendiri untuk memutuskan kapan harus mengalihkan ke cluster yang berbeda.

Opsi pemilihan rute cluster tunggal

Anda dapat menggunakan perutean cluster tunggal untuk kasus penggunaan ini jika tidak ingin cluster Bigtable mengalami kegagalan secara otomatis jika suatu zona atau region menjadi tidak tersedia. Opsi ini adalah pilihan yang tepat jika Anda ingin mengelola biaya dan latensi yang mungkin terjadi jika Bigtable mulai merutekan traffic ke dan dari region yang jauh, atau jika Anda lebih suka membuat keputusan failover berdasarkan penilaian atau aturan bisnis Anda sendiri.

Untuk mengimplementasikan konfigurasi ini, buat minimal satu profil aplikasi yang menggunakan perutean cluster tunggal untuk setiap aplikasi yang mengirim permintaan ke instance. Anda dapat merutekan profil aplikasi ke cluster mana pun di instance Bigtable. Misalnya, jika Anda memiliki tiga aplikasi yang berjalan di Mumbai dan enam aplikasi di Tokyo, Anda dapat mengonfigurasi satu profil aplikasi untuk aplikasi Mumbai untuk dirutekan ke asia-south1-a dan dua aplikasi tersebut ke asia-south1-c. Untuk aplikasi Tokyo, konfigurasi tiga profil aplikasi yang dirutekan ke asia-northeast1-a dan tiga profil tersebut mengarah ke asia-northeast1-b.

Ikuti rekomendasi penggunaan CPU standar untuk konfigurasi ini.

Dengan konfigurasi ini, jika satu atau beberapa cluster tidak tersedia, Anda dapat melakukan failover manual atau memilih untuk membiarkan data Anda tidak tersedia untuk sementara di zona tersebut hingga zona tersebut tersedia lagi.

Opsi pemilihan rute multi-cluster

Jika Anda mengimplementasikan kasus penggunaan ini dan ingin Bigtable secara otomatis menggagalkan satu region jika aplikasi Anda tidak dapat menjangkau region lain, gunakan perutean multi-cluster.

Untuk menerapkan konfigurasi ini, buat profil aplikasi baru yang menggunakan perutean multi-cluster untuk setiap aplikasi, atau perbarui profil aplikasi default untuk menggunakan perutean multi-cluster.

Konfigurasi ini memberikan konsistensi akhir. Jika suatu region menjadi tidak tersedia, permintaan Bigtable akan otomatis dikirim ke region lain. Jika ini terjadi, Anda akan dikenai biaya untuk traffic jaringan ke region lain, dan aplikasi Anda mungkin mengalami latensi yang lebih tinggi karena jarak yang lebih jauh.

Saat Anda pertama kali menyiapkan instance, jangan melebihi 35% pemakaian CPU untuk setiap cluster. Target ini memastikan bahwa setiap cluster dapat menangani traffic yang biasanya ditangani oleh cluster lain di region-nya jika terjadi failover. Anda mungkin perlu menyesuaikan target ini bergantung pada pola traffic dan penggunaan Anda.

Anda dapat menyimulasikan failover untuk kasus penggunaan ini guna menguji aplikasi Anda:

Menjalankan beban kerja pengujian.
Gunakan konsol Google Cloud untuk memantau cluster instance dan memastikan bahwa keempat cluster menangani permintaan masuk.
Hapus salah satu cluster di region A untuk menyimulasikan masalah saat menghubungkan ke zona.

Perubahan ini juga akan menghapus salinan data Anda yang disimpan di cluster.
Terus pantau latensi dan tingkat error untuk cluster yang tersisa.

Jika memiliki resource CPU yang cukup, cluster harus dapat memenuhi permintaan masuk.
Tambahkan cluster ke instance di region A dan terus pantau instance tersebut.

Data akan mulai direplikasi ke cluster baru.
Hapus kedua cluster di region A untuk menyimulasikan masalah saat menghubungkan ke suatu region.

Perubahan ini akan menghapus salinan data Anda yang ada di cluster tersebut.
Terus pantau latensi dan tingkat error untuk cluster yang tersisa.

Jika memiliki resource CPU yang cukup, cluster harus dapat memenuhi permintaan masuk yang sebelumnya ditangani oleh region lain. Jika cluster tidak memiliki resource yang cukup, Anda mungkin perlu menyesuaikan jumlah node.

Menyimpan data dekat dengan pengguna Anda

Jika memiliki pengguna di seluruh dunia, Anda dapat mengurangi latensi dengan menjalankan aplikasi di dekat pengguna dan menempatkan data sedekat mungkin dengan aplikasi. Dengan Bigtable, Anda dapat membuat instance yang memiliki cluster di beberapa region Google Cloud, dan data Anda secara otomatis direplikasi di setiap region.

Untuk kasus penggunaan ini, gunakan profil aplikasi dengan perutean cluster tunggal. Perutean multi-cluster tidak diinginkan untuk kasus penggunaan ini karena jarak antar-cluster. Jika cluster menjadi tidak tersedia dan profil aplikasi multi-clusternya secara otomatis mengalihkan traffic dari jarak jauh, aplikasi Anda mungkin mengalami latensi yang tidak dapat diterima dan menimbulkan biaya jaringan tambahan yang tidak terduga.