Cara kerja failover yang dikelola pelanggan (tidak direncanakan)
Failover yang dikelola pelanggan (tidak direncanakan) memungkinkan Anda untuk melakukan failover pada seluruh akun penyimpanan geo-redundan Anda ke wilayah sekunder jika titik akhir layanan penyimpanan untuk wilayah utama menjadi tidak tersedia. Selama failover, wilayah sekunder asli menjadi wilayah utama baru. Semua titik akhir layanan penyimpanan kemudian 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 yang dikelola pelanggan (tidak direncanakan) pada setiap tahap proses.
Penting
Failover yang dikelola pelanggan (tidak direncanakan) untuk akun yang mengaktifkan Azure Data Lake Storage Gen2 saat ini dalam PRATINJAU dan didukung di semua wilayah GRS/GZRS publik.
Untuk ikut serta dalam pratinjau, lihat Menyiapkan fitur pratinjau di langganan Azure dan menentukan AllowHNSAccountFailover sebagai nama fitur.
Penting
Failover yang dikelola pelanggan (tidak direncanakan) untuk akun yang mengaktifkan Protokol Transfer File SSH (SFTP) 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 yang tidak direncanakan
Tip
Untuk memahami berbagai status redundansi selama proses failover dan failback yang tidak direncanakan secara rinci, lihat Redundansi Azure Storage untuk definisi masing-masing.
Ketika akun penyimpanan dikonfigurasi untuk penyimpanan geo-redundan (GRS) atau redundansi penyimpanan geo-redundan akses baca (RA-GRS), data direplikasi tiga kali dalam wilayah primer dan sekunder penyimpanan redundan lokal (LRS). Ketika akun penyimpanan dikonfigurasi untuk replikasi penyimpanan geo-zona-redundan (GZRS) atau akses baca replikasi penyimpanan geo-zona-redundan (RA-GZRS), data bersifat redundan zona dalam wilayah utama penyimpanan redundan zona (ZRS) dan direplikasi tiga kali dalam wilayah sekunder LRS. Jika akun dikonfigurasi untuk akses baca (RA), Anda dapat membaca data dari wilayah sekunder selama titik akhir layanan penyimpanan ke wilayah tersebut tersedia.
Selama proses failover yang dikelola pelanggan (tidak direncanakan), entri Sistem Nama Domain (DNS) untuk titik akhir layanan penyimpanan dialihkan. Titik akhir sekunder akun penyimpanan Anda menjadi titik akhir utama baru, dan titik akhir utama asli menjadi sekunder baru. Setelah failover, salinan akun penyimpanan Anda di wilayah utama asli dihapus dan akun penyimpanan Anda terus direplikasi tiga kali secara lokal dalam wilayah utama baru . Pada saat itu, akun penyimpanan Anda menjadi redundan secara lokal dan menggunakan LRS.
Konfigurasi redundansi asli dan saat ini disimpan dalam properti akun penyimpanan. Fungsionalitas ini memungkinkan Anda untuk kembali ke konfigurasi asli saat Anda gagal kembali. Untuk daftar lengkap konfigurasi redundansi yang dihasilkan, baca Perencanaan pemulihan dan failover.
Untuk mendapatkan kembali geo-redundansi setelah failover, Anda perlu mengonfigurasi ulang akun Anda sebagai GRS. 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 ke wilayah sekunder, akses tersebut tersedia. Namun, replikasi dari wilayah utama ke sekunder mungkin perlu waktu untuk diselesaikan.
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. Untuk mengevaluasi potensi kehilangan data, bandingkan waktu sinkronisasi terakhir dengan terakhir kali data ditulis ke primer baru.
Proses failback pada dasarnya sama dengan proses failover, kecuali bahwa konfigurasi replikasi dipulihkan ke status pra-failover aslinya.
Setelah failback, Anda dapat mengonfigurasi ulang akun penyimpanan Anda untuk memanfaatkan geo-redundansi. Jika primer asli dikonfigurasi sebagai ZRS, Anda dapat mengonfigurasinya menjadi GZRS atau RA-GZRS. Untuk opsi lainnya, lihat Mengubah cara akun penyimpanan direplikasi.
Cara memulai failover yang tidak direncanakan
Untuk mempelajari cara memulai failover yang tidak direncanakan, lihat Memulai failover akun.
Perhatian
Failover yang tidak direncanakan biasanya melibatkan beberapa kehilangan data, dan berpotensi inkonsistensi file dan data. Penting untuk memahami dampak yang akan terjadi pada failover akun pada data Anda sebelum memulai jenis failover ini.
Untuk detail tentang potensi kehilangan data dan inkonsistensi, lihat Mengantisipasi kehilangan dan inkonsistensi data.
Proses failover dan failback yang tidak direncanakan
Bagian ini meringkas proses failover untuk failover yang dikelola pelanggan (tidak direncanakan).
Ringkasan transisi failover yang tidak direncanakan
Setelah failover yang dikelola pelanggan (tidak direncanakan):
- 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 (tidak direncanakan):
| Asli konfigurasi |
Sesudah failover |
Setelah mengaktifkan kembali redundansi geografis |
Sesudah 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 (tidak direncanakan) dan harus dikonfigurasi ulang secara manual.
Detail transisi failover yang tidak direncanakan
Diagram berikut menunjukkan proses failover dan failback yang dikelola pelanggan (tidak direncanakan) untuk 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 sebelum pemulihan terjadi:
Proses failover yang tidak direncanakan (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 tidak berubah, tetapi entri DNS mereka diubah untuk menunjuk ke wilayah sekunder seperti yang ditunjukkan:
Failover yang dikelola pelanggan (tidak direncanakan) 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 untuk menggunakan 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 tersedia lagi sampai masalah yang menyebabkan pemadaman asli teratasi.
Proses failback yang tidak diencana (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 failback ke wilayah utama asli. Proses ini dijelaskan dalam gambar 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 dialihkan. Titik akhir dalam 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, 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, replikasi ke wilayah sekunder asli dilanjutkan seperti yang ditunjukkan pada gambar ini:
