Cara kerja failover akun penyimpanan yang dikelola pelanggan
Failover akun Azure Storage yang dikelola pelanggan memungkinkan Anda melakukan failover pada seluruh akun penyimpanan geo-redundan ke wilayah sekunder jika titik akhir layanan penyimpanan untuk wilayah utama menjadi tidak tersedia. Selama failover, wilayah sekunder asli menjadi primer baru dan semua titik akhir layanan penyimpanan untuk blob, tabel, antrean, dan file dialihkan ke wilayah utama baru. Setelah pemadaman titik akhir layanan penyimpanan diselesaikan, Anda dapat melakukan operasi failover lain untuk melakukan failback ke wilayah utama asli.
Artikel ini menjelaskan apa yang terjadi selama failover dan failback akun penyimpanan yang dikelola pelanggan di setiap tahap proses.
Penting
Failover akun yang dikelola pelanggan untuk akun yang memiliki namespace hierarkis (Azure Data Lake Storage Gen2) saat ini dalam PRATINJAU dan hanya didukung di wilayah berikut:
- (Asia Pasifik) India Tengah
- (Asia Pasifik) Asia Tenggara
- (Eropa) Eropa Utara
- (Eropa) Swiss Utara
- (Eropa) Swiss Barat
- (Eropa) Eropa Barat
- (Amerika Utara) Kanada Tengah
- (Amerika Utara): US Timur 2
- (Amerika Utara) US Tengah Selatan
Untuk ikut serta dalam pratinjau, lihat Menyiapkan fitur pratinjau di langganan Azure dan menentukan AllowHNSAccountFailover sebagai nama fitur.
Lihat Ketentuan Penggunaan Tambahan untuk Pratinjau Microsoft Azure untuk persyaratan hukum yang berlaku pada fitur Azure dalam versi beta, pratinjau, atau belum dirilis secara umum.
Jika terjadi bencana signifikan yang memengaruhi wilayah utama, Microsoft akan mengelola failover untuk akun dengan namespace hierarkis. Untuk informasi lebih lanjut, lihat Failover yang dikelola Microsoft.
Manajemen redundansi selama failover dan failback
Tip
Untuk memahami berbagai status redundansi selama proses failover dan failback akun penyimpanan secara rinci, lihat Redundansi Azure Storage untuk definisi masing-masing.
Ketika akun penyimpanan dikonfigurasi untuk redundansi GRS atau RA-GRS, data direplikasi tiga kali secara lokal dalam wilayah utama dan sekunder (LRS). Ketika akun penyimpanan dikonfigurasi untuk replikasi GZRS atau RA-GZRS, data redundansi zona dalam wilayah utama (ZRS) dan direplikasi tiga kali secara lokal dalam wilayah sekunder (LRS). Jika akun dikonfigurasi untuk akses baca (RA), Anda akan dapat membaca data dari wilayah sekunder selama titik akhir layanan penyimpanan ke wilayah tersebut tersedia.
Selama proses failover yang dikelola pelanggan, entri DNS untuk titik akhir layanan penyimpanan diubah sedingin itu untuk wilayah sekunder menjadi titik akhir utama baru untuk akun penyimpanan Anda. Setelah failover, salinan akun penyimpanan Anda di wilayah utama asli dihapus dan akun penyimpanan Anda terus direplikasi tiga kali secara lokal dalam wilayah sekunder asli (primer baru). Pada saat itu, akun penyimpanan Anda menjadi redundan secara lokal (LRS).
Konfigurasi redundansi asli dan saat ini disimpan di properti akun penyimpanan untuk memungkinkan Anda akhirnya kembali ke konfigurasi asli saat Anda gagal kembali.
Untuk mendapatkan kembali geo-redundansi setelah failover, Anda harus mengonfigurasi ulang akun Anda sebagai GRS. (GZRS bukan opsi pasca-failover karena primer baru akan menjadi LRS setelah failover). Setelah akun dikonfigurasi ulang untuk geo-redundansi, Azure segera mulai menyalin data dari wilayah utama baru ke sekunder baru. Jika Anda mengonfigurasi akun penyimpanan untuk akses baca (RA) ke wilayah sekunder, akses tersebut akan tersedia tetapi mungkin perlu waktu untuk replikasi dari primer untuk membuat arus sekunder.
Peringatan
Setelah akun Anda dikonfigurasi ulang untuk geo-redundansi, mungkin perlu waktu yang signifikan sebelum data yang ada di wilayah utama baru sepenuhnya disalin ke sekunder baru.
Untuk menghindari kehilangan data utama, periksa nilai properti Waktu Sinkronisasi Terakhir sebelum gagal kembali. Bandingkan waktu sinkronisasi terakhir dengan terakhir kali data ditulis ke primer baru untuk mengevaluasi potensi kehilangan data.
Proses failback pada dasarnya sama dengan proses failover kecuali Azure memulihkan konfigurasi replikasi ke status aslinya sebelum gagal (konfigurasi replikasi, bukan data). Jadi, jika akun penyimpanan Anda awalnya dikonfigurasi sebagai GZRS, wilayah utama setelah faillback menjadi ZRS.
Setelah failback, Anda dapat mengonfigurasi akun penyimpanan anda untuk menjadi geo-redundan lagi. Jika wilayah utama asli dikonfigurasi untuk LRS, Anda dapat mengonfigurasinya menjadi GRS atau RA-GRS. Jika primer asli dikonfigurasi sebagai ZRS, Anda dapat mengonfigurasinya menjadi GZRS atau RA-GZRS. Untuk opsi tambahan, lihat Mengubah cara akun penyimpanan direplikasi.
Cara memulai failover
Untuk mempelajari cara memulai failover, lihat Memulai failover akun penyimpanan.
Perhatian
Failover akun penyimpanan biasanya melibatkan beberapa kehilangan data, dan berpotensi inkonsistensi file dan data. Penting untuk memahami dampak failover akun pada data Anda sebelum memulainya.
Untuk detail tentang potensi kehilangan data dan inkonsistensi, lihat Mengantisipasi kehilangan dan inkonsistensi data.
Proses failover dan failback
Bagian ini meringkas proses failover untuk failover yang dikelola pelanggan.
Ringkasan transisi failover
Setelah failover yang dikelola pelanggan:
- Wilayah sekunder menjadi primer baru
- Salinan data di wilayah utama asli dihapus
- Akun penyimpanan dikonversi ke LRS
- Redundansi geografis hilang
Tabel ini meringkas konfigurasi redundansi yang dihasilkan pada setiap tahap failover dan failback yang dikelola pelanggan:
| Asli konfigurasi |
Setelah failover |
Setelah mengaktifkan kembali redundansi geografis |
Setelah failback |
Setelah mengaktifkan kembali redundansi geografis |
|---|---|---|---|---|
| GRS | LRS | GRS 1 | LRS | GRS 1 |
| GZRS | LRS | GRS 1 | ZRS | GZRS 1 |
1 Geo-redundansi hilang selama failover yang dikelola pelanggan dan harus dikonfigurasi ulang secara manual.
Detail transisi failover
Diagram berikut menunjukkan apa yang terjadi selama failover yang dikelola pelanggan dan failback akun penyimpanan yang dikonfigurasi untuk geo-redundansi. Detail transisi untuk GZRS dan RA-GZRS sedikit berbeda dari GRS dan RA-GRS.
Operasi normal (GRS/RA-GRS)
Dalam keadaan normal, klien menulis data ke akun penyimpanan di wilayah utama melalui titik akhir layanan penyimpanan (1). Data kemudian disalin secara asinkron dari wilayah utama ke wilayah sekunder (2). Gambar berikut menunjukkan status normal akun penyimpanan yang dikonfigurasi sebagai GRS saat titik akhir utama tersedia:
Titik akhir layanan penyimpanan menjadi tidak tersedia di wilayah utama (GRS/RA-GRS)
Jika titik akhir layanan penyimpanan utama menjadi tidak tersedia karena alasan apa pun (1), klien tidak lagi dapat menulis ke akun penyimpanan. Tergantung pada penyebab pemadaman yang mendasarinya, replikasi ke wilayah sekunder mungkin tidak lagi berfungsi (2), sehingga beberapa kehilangan data harus diharapkan. Gambar berikut menunjukkan skenario di mana titik akhir utama menjadi tidak tersedia, tetapi belum ada pemulihan yang terjadi:
Proses failover (GRS/RA-GRS)
Untuk memulihkan akses tulis ke data Anda, Anda dapat memulai failover. URI titik akhir layanan penyimpanan untuk blob, tabel, antrean, dan file tetap sama tetapi entri DNS mereka diubah untuk menunjuk ke wilayah sekunder (1) seperti yang ditunjukkan dalam gambar ini:
Failover yang dikelola pelanggan biasanya memakan waktu sekitar satu jam.
Setelah failover selesai, sekunder asli menjadi primer baru (1) dan salinan akun penyimpanan di primer asli dihapus (2). Akun penyimpanan dikonfigurasi sebagai LRS di wilayah utama baru dan tidak lagi geo-redundan. Pengguna dapat melanjutkan penulisan data ke akun penyimpanan (3) seperti yang ditunjukkan pada gambar ini:
Untuk melanjutkan replikasi ke wilayah sekunder baru, konfigurasi ulang akun untuk geo-redundansi.
Penting
Ingatlah bahwa mengonversi akun penyimpanan redundan lokal untuk menggunakan geo-redundansi memerlukan biaya dan waktu. Untuk informasi selengkapnya, lihat Waktu dan biaya failover.
Setelah mengonfigurasi ulang akun sebagai GRS, Azure mulai menyalin data Anda secara asinkron ke wilayah sekunder baru (1) seperti yang ditunjukkan pada gambar ini:
Akses baca ke wilayah sekunder baru tidak akan tersedia lagi sampai masalah yang menyebabkan pemadaman asli telah diselesaikan.
Proses failback (GRS/RA-GRS)
Peringatan
Setelah akun Anda dikonfigurasi ulang untuk geo-redundansi, mungkin perlu waktu yang signifikan sebelum data di wilayah utama baru sepenuhnya disalin ke sekunder baru.
Untuk menghindari kehilangan data utama, periksa nilai properti Waktu Sinkronisasi Terakhir sebelum gagal kembali. Bandingkan waktu sinkronisasi terakhir dengan terakhir kali data ditulis ke primer baru untuk mengevaluasi potensi kehilangan data.
Setelah masalah yang menyebabkan pemadaman asli diselesaikan, Anda dapat memulai failover lain untuk gagal kembali ke wilayah utama asli, yang mengakibatkan hal berikut:
- Wilayah utama saat ini menjadi baca saja.
- Dengan failover dan failback yang dimulai pelanggan, data Anda tidak diizinkan untuk menyelesaikan replikasi ke wilayah sekunder selama proses failback. Oleh karena itu, penting untuk memeriksa nilai properti Waktu Sinkronisasi Terakhir sebelum gagal kembali.
- Entri DNS untuk titik akhir layanan penyimpanan diubah sehingga entri untuk wilayah sekunder menjadi titik akhir utama baru untuk akun penyimpanan Anda.
Setelah failback selesai, wilayah utama asli menjadi yang saat ini lagi (1) dan salinan akun penyimpanan di sekunder asli dihapus (2). Akun penyimpanan dikonfigurasi sebagai redundan secara lokal di wilayah utama dan tidak lagi geo-redundan. Pengguna dapat melanjutkan penulisan data ke akun penyimpanan (3) seperti yang ditunjukkan pada gambar ini:
Untuk melanjutkan replikasi ke wilayah sekunder asli, konfigurasikan akun untuk geo-redundansi lagi.
Penting
Ingatlah bahwa mengonversi akun penyimpanan redundan lokal untuk menggunakan geo-redundansi memerlukan biaya dan waktu. Untuk informasi selengkapnya, lihat Waktu dan biaya failover.
Setelah mengonfigurasi ulang akun sebagai GRS, replikasi ke wilayah sekunder asli dilanjutkan seperti yang ditunjukkan pada gambar ini:
