Perencanaan dan failover pemulihan bencana penyimpanan Azure
Microsoft berusaha untuk memastikan bahwa layanan Azure selalu tersedia. Namun, pemadaman layanan yang tidak dienkripsi kadang-kadang mungkin terjadi. Komponen utama dari rencana pemulihan bencana yang baik mencakup strategi untuk:
- Perlindungan data
- Pencadangan dan pemulihan
- Redundansi data
- Kegagalan
- Merancang aplikasi untuk ketersediaan tinggi
Artikel ini menjelaskan opsi yang tersedia untuk akun penyimpanan geo-redundan, dan memberikan rekomendasi untuk mengembangkan aplikasi yang sangat tersedia dan menguji rencana pemulihan bencana Anda.
Pilih opsi redundansi yang tepat
Azure Storage mempertahankan beberapa salinan akun penyimpanan Anda untuk memastikan bahwa target ketersediaan dan durabilitas terpenuhi, bahkan dalam menghadapi kegagalan. Cara data direplikasi memberikan tingkat perlindungan yang berbeda. Setiap opsi menawarkan manfaatnya sendiri, sehingga opsi yang Anda pilih tergantung pada tingkat ketahanan yang diperlukan aplikasi Anda.
Penyimpanan redundan lokal (LRS), opsi redundansi dengan biaya terendah, secara otomatis menyimpan dan mereplikasi tiga salinan akun penyimpanan Anda dalam satu pusat data. Meskipun LRS melindungi data Anda dari rak server dan kegagalan drive, LRS tidak memperhitungkan bencana seperti kebakaran atau banjir dalam pusat data. Dalam menghadapi bencana tersebut, semua replika akun penyimpanan yang dikonfigurasi untuk menggunakan LRS mungkin hilang atau tidak dapat dipulihkan.
Sebagai perbandingan, penyimpanan zona redundan (ZRS) menyimpan salinan akun penyimpanan dan mereplikasinya di masing-masing dari tiga zona ketersediaan terpisah dalam wilayah yang sama. Untuk informasi selengkapnya tentang zona ketersediaan, lihat Zona ketersediaan Azure.
Penyimpanan geo-redundan dan failover
Penyimpanan geo-redundan (GRS), penyimpanan geo-zona-redundan (GZRS), dan penyimpanan geo-zona redundan akses baca (RA-GZRS) adalah contoh opsi penyimpanan yang berlebihan secara geografis. Saat dikonfigurasi untuk menggunakan penyimpanan geo-redundan (GRS, GZRS, dan RA-GZRS), Azure menyalin data Anda secara asinkron ke wilayah geografis sekunder. Wilayah-wilayah ini terletak ratusan, atau bahkan ribuan mil jauhnya. Tingkat redundansi ini memungkinkan Anda memulihkan data jika ada pemadaman di seluruh wilayah utama.
Tidak seperti LRS dan ZRS, penyimpanan geo-redundan juga memberikan dukungan untuk failover yang tidak direncanakan ke wilayah sekunder jika ada pemadaman di wilayah utama. Selama proses failover, entri DNS (Sistem Nama Domain) untuk titik akhir layanan akun penyimpanan Anda secara otomatis diperbarui sedih sehingga titik akhir wilayah sekunder menjadi titik akhir utama baru. Setelah failover yang tidak direncanakan selesai, klien dapat mulai menulis ke titik akhir utama baru.
Penyimpanan geo-redundan akses baca (RA-GRS) dan penyimpanan geo-zona-redundan akses baca (RA-GZRS) juga menyediakan penyimpanan geo-redundan, tetapi menawarkan manfaat tambahan akses baca ke titik akhir sekunder. Opsi ini sangat ideal untuk aplikasi yang dirancang untuk aplikasi penting bisnis ketersediaan tinggi. Jika titik akhir utama mengalami pemadaman, aplikasi yang dikonfigurasi untuk akses baca ke wilayah sekunder dapat terus beroperasi. Microsoft merekomendasikan RA-GZRS untuk ketersediaan dan durabilitas maksimum akun penyimpanan Anda.
Untuk informasi selengkapnya tentang redundansi untuk Azure Storage, lihat Redundansi Azure Storage.
Merencanakan failover
Akun Azure Storage mendukung tiga jenis failover:
- Failover terencana yang dikelola pelanggan (pratinjau) - Pelanggan dapat mengelola failover akun penyimpanan untuk menguji rencana pemulihan bencana mereka.
- Failover yang dikelola pelanggan (tidak terencana) - Pelanggan dapat mengelola failover akun penyimpanan jika ada pemadaman layanan yang tidak terduga.
- Failover yang dikelola Microsoft - Berpotensi dimulai oleh Microsoft karena bencana yang parah di wilayah utama. 1,2
1 Failover yang dikelola Microsoft tidak dapat dimulai untuk akun penyimpanan individu, langganan, atau penyewa. Untuk informasi lebih lanjut, lihat Failover yang dikelola Microsoft.
2 Gunakan opsi failover yang dikelola pelanggan untuk mengembangkan, menguji, dan menerapkan rencana pemulihan bencana Anda. Jangan mengandalkan failover yang dikelola Microsoft, yang hanya akan digunakan dalam keadaan ekstrem.
Setiap jenis failover memiliki serangkaian kasus penggunaan yang unik, harapan yang sesuai untuk kehilangan data, dan dukungan untuk akun dengan namespace hierarki yang diaktifkan (Azure Data Lake Storage). Tabel ini meringkas aspek-aspek dari setiap jenis failover:
| Jenis | Cakupan Failover | Gunakan huruf besar | Kehilangan data yang diharapkan | Namespace Hierarkis (HNS) didukung |
|---|---|---|---|---|
| Failover terencana yang dikelola pelanggan (pratinjau) | Akun Penyimpanan | Titik akhir layanan penyimpanan untuk wilayah utama dan sekunder tersedia, dan Anda ingin melakukan pengujian pemulihan bencana. Titik akhir layanan penyimpanan untuk wilayah utama tersedia, tetapi layanan lain mencegah beban kerja Anda berfungsi dengan baik. Untuk secara proaktif mempersiapkan bencana skala besar, seperti badai, yang mungkin memengaruhi suatu wilayah. |
Tidak | Ya (Dalam pratinjau) |
| Failover yang dikelola pelanggan (tidak direncanakan) | Akun Penyimpanan | Titik akhir layanan penyimpanan untuk wilayah utama menjadi tidak tersedia, tetapi wilayah sekunder tersedia. Anda menerima Azure Advisory di mana Microsoft menyarankan Anda untuk melakukan operasi failover akun penyimpanan yang berpotensi terpengaruh oleh pemadaman. |
Ya | Ya (Dalam pratinjau) |
| Dikelola Microsoft | Seluruh wilayah | Wilayah utama menjadi tidak tersedia karena bencana yang signifikan, tetapi wilayah sekunder tersedia. | Ya | Ya |
Tabel berikut membandingkan status redundansi akun penyimpanan setelah setiap jenis failover:
| Hasil failover pada... | Failover terencana yang dikelola pelanggan (pratinjau) | Failover yang dikelola pelanggan (tidak direncanakan) |
|---|---|---|
| ... wilayah sekunder | Wilayah sekunder menjadi primer baru | Wilayah sekunder menjadi primer baru |
| ... wilayah utama asli | Wilayah utama asli menjadi sekunder baru | Salinan data di wilayah utama asli dihapus |
| ... konfigurasi redundansi akun | Akun penyimpanan dikonversi ke GRS | Akun penyimpanan dikonversi ke LRS |
| ... konfigurasi geo-redundansi | Redundansi geografis dipertahankan | Redundansi geografis hilang |
Tabel berikut ini meringkas konfigurasi redundansi yang dihasilkan pada setiap tahap proses failover dan failback untuk setiap jenis failover:
| Asli konfigurasi |
Sesudah failover |
Setelah mengaktifkan kembali redundansi geografis |
Sesudah failback |
Setelah mengaktifkan kembali redundansi geografis |
|---|---|---|---|---|
| Failover terencana yang dikelola pelanggan | ||||
| GRS | GRS | n/a 1 | GRS | n/a 1 |
| GZRS | GRS | n/a 1 | GZRS | n/a 1 |
| Failover yang dikelola pelanggan (tidak direncanakan) | ||||
| GRS | LRS | GRS | LRS | GRS |
| GZRS | LRS | GRS | ZRS | GZRS |
1 Geo-redundansi dipertahankan selama failover yang direncanakan dan tidak perlu dikonfigurasi ulang secara manual.
Failover terencana yang dikelola pelanggan (pratinjau)
Failover yang direncanakan dapat digunakan dalam beberapa skenario termasuk pengujian pemulihan bencana yang direncanakan, pendekatan proaktif untuk bencana skala besar, atau untuk pulih dari pemadaman terkait nonstorage.
Selama proses failover yang direncanakan, wilayah utama dan sekunder ditukar. Wilayah utama asli diturunkan dan menjadi wilayah sekunder baru. Pada saat yang sama, wilayah sekunder asli dipromosikan dan menjadi primer baru. Setelah failover selesai, pengguna dapat melanjutkan untuk mengakses data di wilayah utama baru dan administrator dapat memvalidasi rencana pemulihan bencana mereka. Akun penyimpanan harus tersedia di wilayah utama dan sekunder sebelum failover yang direncanakan dapat dimulai.
Kehilangan data tidak diharapkan selama proses failover dan failback yang direncanakan selama wilayah utama dan sekunder tersedia di seluruh proses. Untuk detail selengkapnya, lihat bagian Mengantisipasi kehilangan dan inkonsistensi data.
Untuk memahami efek dari jenis failover ini pada pengguna dan aplikasi Anda, sangat membantu untuk mengetahui apa yang terjadi selama setiap langkah proses failover dan failback yang direncanakan. Untuk detail tentang cara kerja proses ini, lihat Cara kerja failover yang dikelola pelanggan (terencana).
Penting
Failover terencana yang dikelola pelanggan saat ini dalam PRATINJAU dan terbatas pada wilayah berikut:
- Prancis Tengah
- Prancis Selatan
- India Tengah
- India Barat
- Asia Timur
- Asia Tenggara
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.
Untuk ikut serta dalam pratinjau, lihat Menyiapkan fitur pratinjau di langganan Azure dan menentukan AllowSoftFailover sebagai nama fitur. Nama penyedia untuk fitur pratinjau ini adalah Microsoft.Storage.
Penting
Setelah failover yang direncanakan, nilai Waktu Sinkronisasi Terakhir (LST) akun penyimpanan mungkin tampak kedaluwarsa atau dilaporkan sebagai NULL saat data Azure Files ada.
Rekam jepret sistem dibuat secara berkala di wilayah sekunder akun penyimpanan untuk mempertahankan titik pemulihan yang konsisten yang digunakan selama failover dan failback. Memulai failover terencana yang dikelola pelanggan menyebabkan wilayah utama asli menjadi sekunder baru. Dalam beberapa kasus, tidak ada rekam jepret sistem yang tersedia pada sekunder baru setelah failover yang direncanakan selesai, menyebabkan nilai LST keseluruhan akun tampak basi atau ditampilkan sebagai Null.
Karena aktivitas pengguna seperti membuat, memodifikasi, atau menghapus objek dapat memicu pembuatan rekam jepret, akun apa pun tempat aktivitas ini terjadi setelah failover yang direncanakan tidak akan memerlukan perhatian tambahan. Namun, akun yang tidak memiliki rekam jepret atau aktivitas pengguna dapat terus menampilkan Null nilai LST hingga pembuatan rekam jepret sistem dipicu.
Jika perlu, lakukan salah satu aktivitas berikut untuk setiap berbagi dalam akun penyimpanan untuk memicu pembuatan rekam jepret. Setelah selesai, akun Anda harus menampilkan nilai LST yang valid dalam waktu 30 menit.
- Pasang berbagi, lalu buka file apa pun untuk dibaca.
- Unggah file pengujian atau sampel ke berbagi.
Failover yang dikelola pelanggan (tidak direncanakan)
Jika titik akhir data untuk layanan penyimpanan di akun penyimpanan Anda menjadi tidak tersedia di wilayah utama, Anda dapat memulai failover yang tidak direncanakan ke wilayah sekunder. Setelah failover selesai, wilayah sekunder menjadi primer baru dan pengguna dapat melanjutkan untuk mengakses data di sana.
Untuk memahami efek dari jenis failover ini pada pengguna dan aplikasi Anda, sangat membantu untuk mengetahui apa yang terjadi selama setiap langkah dari proses failover dan failback yang tidak direncanakan. Untuk detail tentang cara kerja proses, lihat Cara kerja failover yang dikelola pelanggan (tidak direncanakan).
Failover yang dikelola Microsoft
Microsoft mungkin memulai failover regional dalam keadaan ekstrem, seperti bencana bencana yang berdampak pada seluruh wilayah geografis. Selama peristiwa ini, tidak ada tindakan di bagian Anda yang diperlukan. Jika akun penyimpanan Anda dikonfigurasi untuk RA-GRS atau RA-GZRS, aplikasi Anda dapat membaca dari wilayah sekunder selama failover yang dikelola Microsoft. Namun, Anda tidak memiliki akses tulis ke akun penyimpanan Anda sampai proses failover selesai.
Penting
Gunakan opsi failover yang dikelola pelanggan untuk mengembangkan, menguji, dan menerapkan rencana pemulihan bencana Anda. Jangan mengandalkan failover yang dikelola Microsoft, yang mungkin hanya digunakan dalam keadaan ekstrem. Failover yang dikelola Microsoft akan dimulai untuk seluruh unit fisik, seperti wilayah atau pusat data. Ini tidak dapat dimulai untuk akun penyimpanan individu, langganan, atau penyewa. Jika Anda memerlukan kemampuan untuk secara selektif melakukan failover akun penyimpanan individual Anda, gunakan failover terencana yang dikelola pelanggan.
Mengantisipasi kehilangan data dan inkonsistensi
Perhatian
Failover yang tidak direncanakan yang dikelola pelanggan biasanya melibatkan beberapa jumlah kehilangan data, dan juga berpotensi memperkenalkan inkonsistensi file dan data. Dalam rencana pemulihan bencana Anda, penting untuk mempertimbangkan dampak yang akan terjadi pada failover akun pada data Anda sebelum memulainya.
Karena data ditulis secara asinkron dari wilayah utama ke wilayah sekunder, selalu ada penundaan sebelum penulisan ke wilayah utama disalin ke sekunder. Jika wilayah utama menjadi tidak tersedia, ada kemungkinan bahwa penulisan terbaru mungkin belum disalin ke sekunder.
Ketika failover yang tidak direncanakan terjadi, semua data di wilayah utama hilang karena wilayah sekunder menjadi primer baru. Semua data yang sudah disalin ke wilayah sekunder dipertahankan saat failover terjadi. Namun, data apa pun yang ditulis ke primer yang belum ada di wilayah sekunder hilang secara permanen.
Wilayah utama baru dikonfigurasi menjadi redundan lokal (LRS) setelah failover.
Anda juga mungkin mengalami inkonsistensi file atau data jika akun penyimpanan Anda mengaktifkan satu atau beberapa hal berikut:
- Namespace hierarkis (Azure Data Lake Storage)
- Pengubahan umpan
- Pemulihan point-in-time untuk blob blok
Waktu sinkronasi terakhir
Properti Waktu Sinkronisasi Terakhir menunjukkan waktu terbaru di mana data dari wilayah utama juga ditulis ke wilayah sekunder. Untuk akun yang memiliki namespace hierarkis, properti Waktu Sinkronisasi Terakhir yang sama juga berlaku untuk metadata yang dikelola oleh namespace hierarkis, termasuk daftar kontrol akses (ACL). Semua data dan metadata yang ditulis sebelum waktu sinkronisasi terakhir tersedia di sekunder. Sebaliknya, data dan metadata yang ditulis setelah waktu sinkronisasi terakhir mungkin belum disalin ke sekunder dan berpotensi hilang. Selama pemadaman, gunakan properti ini untuk memperkirakan jumlah kehilangan data yang mungkin Anda timbulkan saat memulai failover akun.
Sebagai praktik terbaik, rancang aplikasi Anda sehingga Anda dapat menggunakan Waktu Sinkronisasi Terakhir untuk mengevaluasi kehilangan data yang diharapkan. Misalnya, mencatat semua operasi tulis memungkinkan Anda membandingkan waktu operasi tulis terakhir Anda dengan waktu sinkronisasi terakhir. Metode ini memungkinkan Anda menentukan penulisan mana yang belum disinkronkan ke sekunder dan berada dalam bahaya hilang.
Untuk informasi selengkapnya tentang memeriksa properti Waktu Sinkronisasi Terakhir, lihat Memeriksa properti Waktu Sinkronisasi Terakhir untuk akun penyimpanan.
Konsistensi file untuk Azure Data Lake Storage
Replikasi untuk akun penyimpanan dengan namespace hierarki yang diaktifkan (Azure Data Lake Storage) terjadi di tingkat file. Karena replikasi terjadi pada tingkat ini, pemadaman di wilayah utama mungkin mencegah beberapa file dalam kontainer atau direktori berhasil mereplikasi ke wilayah sekunder. Konsistensi untuk semua file dalam kontainer atau direktori setelah failover akun penyimpanan tidak dijamin.
Mengubah inkonsistensi data umpan dan blob
Failover akun penyimpanan yang dikelola pelanggan (tidak direncanakan) dengan umpan perubahan diaktifkan dapat mengakibatkan inkonsistensi antara log umpan perubahan dan data blob dan/atau metadata. Inkonsistensi tersebut dapat dihasilkan dari sifat asinkron pembaruan log perubahan dan replikasi data antara wilayah utama dan sekunder. Anda dapat menghindari inkonsistensi dengan melakukan tindakan pencegahan berikut:
- Pastikan bahwa semua rekaman log dihapus ke file log.
- Pastikan bahwa semua data penyimpanan direplikasi dari wilayah utama ke sekunder.
Untuk informasi selengkapnya tentang umpan perubahan, lihat Cara kerja umpan perubahan.
Perlu diingat bahwa fitur akun penyimpanan lainnya juga mengharuskan umpan perubahan diaktifkan. Fitur-fitur ini termasuk pencadangan operasional Azure Blob Storage, Replikasi objek, dan pemulihan Point-in-time untuk blob blok.
Inkonsistensi pemulihan titik waktu
Failover yang dikelola pelanggan didukung untuk akun penyimpanan tingkat standar v2 tujuan umum yang menyertakan blob blok. Namun, melakukan failover yang dikelola pelanggan pada akun penyimpanan mengatur ulang titik pemulihan paling awal yang mungkin untuk akun tersebut. Data untuk pemulihan Point-in-time untuk blob blok hanya konsisten hingga waktu penyelesaian failover. Akibatnya, Anda hanya dapat memulihkan blob blok ke titik waktu tidak lebih awal dari waktu penyelesaian failover. Anda dapat memeriksa waktu penyelesaian failover di tab redundansi akun penyimpanan Anda di portal Azure.
Waktu dan biaya failover
Waktu yang diperlukan agar failover yang dikelola pelanggan selesai setelah dimulai dapat bervariasi, meskipun biasanya membutuhkan waktu kurang dari satu jam.
Failover yang dikelola pelanggan yang direncanakan tidak kehilangan geo-redundansinya setelah failover dan failback berikutnya, tetapi failover yang dikelola pelanggan yang tidak direncanakan.
Memulai failover yang tidak direncanakan yang dikelola pelanggan secara otomatis mengonversi akun penyimpanan Anda ke penyimpanan redundan lokal (LRS) dalam wilayah utama baru, dan menghapus akun penyimpanan di wilayah utama asli.
Anda dapat mengaktifkan kembali penyimpanan geo-redundan (GRS) atau penyimpanan geo-redundan akses baca (RA-GRS) untuk akun tersebut, tetapi mereplikasi ulang data ke wilayah sekunder baru dikenakan biaya. Selain itu, setiap blob yang diarsipkan perlu direhidrasi ke tingkat online sebelum akun dapat dikonfigurasi ulang untuk geo-redundansi. Rehidrasi ini juga dikenakan biaya tambahan. Untuk informasi selengkapnya tentang harga, lihat:
Setelah mengaktifkan kembali GRS untuk akun penyimpanan Anda, Microsoft mulai mereplikasi data di akun Anda ke wilayah sekunder yang baru. Jumlah waktu yang diperlukan untuk menyelesaikan replikasi tergantung pada beberapa faktor. Faktor-faktor ini meliputi:
- Jumlah dan ukuran objek di akun penyimpanan. Mereplikasi banyak objek kecil dapat memakan waktu lebih lama daripada mereplikasi objek yang lebih sedikit dan lebih besar.
- Sumber daya yang tersedia untuk replikasi latar belakang, seperti CPU, memori, disk, dan kapasitas WAN. Lalu lintas langsung lebih diprioritaskan daripada replikasi geografis.
- Jumlah rekam jepret per blob, jika berlaku.
- Strategi pemartisian data, jika akun penyimpanan Anda berisi tabel. Proses replikasi tidak dapat diskalakan melebihi jumlah kunci partisi yang Anda gunakan.
Jenis akun penyimpanan yang didukung
Semua penawaran geo-redundan mendukung failover yang dikelola Microsoft. Selain itu, beberapa jenis akun mendukung failover akun yang dikelola pelanggan, seperti yang diperlihatkan dalam tabel berikut:
| Jenis failover | GRS/RA-GRS | GZRS/RA-GZRS |
|---|---|---|
| Failover terencana yang dikelola pelanggan (pratinjau) | Akun tujuan umum v2 Akun tujuan umum v1 Akun warisan Blob Storage |
Akun tujuan umum v2 |
| Failover yang dikelola pelanggan (tidak direncanakan) | Akun tujuan umum v2 Akun tujuan umum v1 Akun warisan Blob Storage |
Akun tujuan umum v2 |
| Failover yang dikelola Microsoft | Semua jenis akun | Akun tujuan umum v2 |
Akun penyimpanan klasik
Penting
Failover yang dikelola pelanggan hanya didukung untuk akun penyimpanan yang disebarkan menggunakan model penyebaran Azure Resource Manager (ARM). Model penyebaran Azure Service Manager (ASM), juga dikenal sebagai model klasik , tidak didukung. Untuk membuat akun penyimpanan klasik memenuhi syarat untuk failover akun yang dikelola pelanggan, akun tersebut harus terlebih dahulu dimigrasikan ke model ARM. Akun penyimpanan Anda harus dapat diakses untuk melakukan peningkatan, sehingga wilayah utama saat ini tidak dapat berada dalam status gagal.
Selama bencana yang memengaruhi wilayah utama, Microsoft akan mengelola failover untuk akun penyimpanan klasik. Untuk informasi lebih lanjut, lihat Failover yang dikelola Microsoft.
Namespace hierarkis (HNS)
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.
Fitur dan layanan yang tidak didukung
Fitur dan layanan berikut tidak didukung untuk failover yang dikelola pelanggan:
- Azure File Sync tidak mendukung failover akun yang dikelola pelanggan. Akun penyimpanan yang digunakan sebagai titik akhir cloud untuk Azure File Sync seharusnya tidak gagal. Failover mengganggu sinkronisasi file dan dapat menyebabkan hilangnya data file yang baru berjenjang yang tidak terduga. Untuk informasi selengkapnya, lihat Praktik terbaik untuk pemulihan bencana dengan Azure File Sync untuk detailnya.
- Akun penyimpanan yang berisi blob blok premium tidak dapat di-failover. Akun penyimpanan yang mendukung blob blok premium saat ini tidak mendukung geo-redundansi.
- Failover yang dikelola pelanggan tidak didukung untuk akun sumber atau tujuan dalam kebijakan replikasi objek.
- Network File System (NFS) 3.0 (NFSv3) tidak didukung untuk failover akun penyimpanan. Anda tidak dapat membuat akun penyimpanan yang dikonfigurasi untuk geo-redundansi dengan NFSv3 diaktifkan.
Tabel berikut ini dapat digunakan untuk mereferensikan dukungan fitur.
| Kegagalan terencana | Kegagalan tidak terencana | |
|---|---|---|
| Azure Data Lake Storage | Didukung (Pratinjau) | Didukung (Pratinjau) |
| Pengubahan Umpan | Tidak didukung | Didukung |
| Replikasi Objek | Tidak didukung | Tidak didukung |
| SFTP | Didukung (Pratinjau) | Didukung (Pratinjau) |
| NFSv3 | GRS tidak didukung | GRS tidak didukung |
| Tindakan Penyimpanan | Didukung1 | Didukung1 |
| Pemulihan titik waktu (PITR) | Tidak didukung | Didukung |
1 Jika Anda memulai failover yang direncanakan atau tidak direncanakan yang dikelola pelanggan, tugas penyimpanan tidak dapat beroperasi pada akun hingga gagal kembali ke wilayah utama asli. Pelajari selengkapnya.
Failover bukan untuk migrasi akun
Failover akun penyimpanan adalah solusi sementara yang digunakan untuk mengembangkan dan menguji rencana pemulihan bencana (DR) Anda, atau untuk pulih dari pemadaman layanan. Failover tidak boleh digunakan sebagai bagian dari strategi migrasi data Anda. Untuk informasi tentang cara memigrasikan akun penyimpanan Anda, lihat Gambaran umum migrasi Azure Storage.
Akun penyimpanan yang berisi blob yang diarsipkan
Akun penyimpanan yang berisi kegagalan akun dukungan blob yang diarsipkan. Namun, setelah failover yang dikelola pelanggan selesai, semua blob yang diarsipkan harus direhidrasi ke tingkat online sebelum akun dapat dikonfigurasi untuk geo-redundansi.
Penyedia sumber daya penyimpanan
Microsoft menyediakan dua REST API untuk bekerja dengan sumber daya Azure Storage. API ini merupakan dasar dari semua tindakan yang dapat Anda lakukan terhadap Azure Storage. Azure Storage REST API memungkinkan Anda bekerja dengan data di akun penyimpanan Anda, termasuk data blob, antrean, file, dan tabel. REST API penyedia sumber daya Azure Storage memungkinkan Anda mengelola akun penyimpanan dan sumber daya terkait.
Setelah failover selesai, klien dapat sekali lagi membaca dan menulis data Azure Storage di wilayah utama baru. Namun, penyedia sumber daya Azure Storage tidak gagal, sehingga operasi manajemen sumber daya masih harus berlangsung di wilayah utama. Jika wilayah utama tidak tersedia, Anda tidak dapat melakukan operasi manajemen di akun penyimpanan.
Karena penyedia sumber daya Azure Storage tidak gagal, properti Lokasi akan mengembalikan lokasi utama asli setelah failover selesai.
Komputer virtual Azure
Komputer virtual (VM) Azure tidak gagal sebagai bagian dari failover akun penyimpanan. Setiap VM yang gagal ke wilayah sekunder sebagai respons terhadap pemadaman perlu dibuat ulang setelah failover selesai. Failover akun berpotensi mengakibatkan hilangnya data yang disimpan dalam disk sementara saat komputer virtual (VM) dimatikan. Microsoft merekomendasikan untuk mengikuti panduan ketersediaan tinggi dan pemulihan bencana khusus untuk komputer virtual di Azure.
Disk tidak terkelola Azure
Disk yang tidak dikelola disimpan sebagai blob halaman di Azure Storage. Saat VM berjalan di Azure, disk apa pun yang tidak dikelola yang terpasang pada VM disewakan. Failover akun tidak dapat dilanjutkan ketika ada sewa pada blob. Sebelum failover dapat dimulai pada akun yang berisi disk yang tidak dikelola yang dilampirkan ke Azure VM, disk harus dimatikan. Untuk alasan ini, praktik terbaik yang direkomendasikan Microsoft termasuk mengonversi disk yang tidak dikelola ke disk terkelola.
Untuk melakukan failover pada akun yang berisi disk yang tidak dikelola, ikuti langkah-langkah berikut:
- Sebelum memulai, perhatikan nama disk yang tidak dikelola, nomor unit logis (LUN), dan VM yang dilampirkan. Melakukannya akan membuatnya lebih mudah untuk melampirkan ulang disk setelah kegagalan.
- Matikan VM-nya.
- Hapus VM, tetapi pertahankan file hard disk virtual (VHD) untuk disk yang tidak dikelola. Perhatikan waktu saat Anda menghapus VM.
- Tunggu hingga waktu sinkronisasi terakhir diperbarui, dan pastikan bahwa itu lebih lambat dari waktu Anda menghapus VM. Langkah ini memastikan bahwa titik akhir sekunder sepenuhnya diperbarui dengan file VHD ketika failover terjadi, dan bahwa VM berfungsi dengan baik di wilayah utama baru.
- Memulai kegagalan akun.
- Tunggu hingga failover akun selesai dan wilayah sekunder menjadi wilayah utama baru.
- Buat VM di wilayah utama baru dan melampirkan ulang VHD.
- Mulai VM baru.
Perlu diingat bahwa data apa pun yang disimpan dalam disk sementara hilang saat VM dimatikan.
Menyalin data sebagai alternatif failover
Seperti yang dibahas sebelumnya, Anda dapat mempertahankan ketersediaan tinggi dengan mengonfigurasi aplikasi untuk menggunakan akun penyimpanan yang dikonfigurasi untuk akses baca ke wilayah sekunder. Namun, jika Anda lebih suka tidak melakukan failover selama pemadaman di wilayah utama, Anda dapat menyalin data Anda secara manual sebagai alternatif. Alat seperti AzCopy dan Azure PowerShell memungkinkan Anda menyalin data dari akun penyimpanan Anda di wilayah yang terpengaruh ke akun penyimpanan lain di wilayah yang tidak terpengaruh. Setelah operasi salin selesai, Anda dapat mengonfigurasi ulang aplikasi Anda untuk menggunakan akun penyimpanan di wilayah yang tidak terpengaruh untuk ketersediaan baca dan tulis.
Desain untuk ketersediaan tinggi
Penting untuk merancang aplikasi Anda untuk ketersediaan tinggi sejak awal. Lihat sumber daya Azure ini untuk panduan saat merancang aplikasi Anda dan merencanakan pemulihan bencana:
- Merancang aplikasi tangguh untuk Azure: Gambaran umum konsep utama untuk merancang aplikasi yang sangat tersedia di Azure.
- Daftar periksa ketahanan: Daftar periksa untuk memverifikasi bahwa aplikasi Anda menerapkan praktik desain terbaik untuk ketersediaan tinggi.
- Gunakan geo-redundansi untuk merancang aplikasi yang sangat tersedia: Panduan desain untuk membangun aplikasi untuk memanfaatkan penyimpanan geo-redundan.
- Tutorial: Bangun aplikasi yang sangat tersedia dengan penyimpanan Blob: Tutorial yang menunjukkan cara membangun aplikasi yang sangat tersedia yang secara otomatis beralih di antara titik akhir karena kegagalan dan pemulihan disimulasikan.
Lihat praktik terbaik ini untuk mempertahankan ketersediaan tinggi untuk data Azure Storage Anda:
- Disks: Gunakan Azure Backup untuk mencadangkan disk VM yang digunakan oleh komputer virtual Azure Anda. Pertimbangkan juga untuk menggunakan Azure Site Recovery untuk melindungi VM Anda dari bencana regional.
- Blob blok: Aktifkan penghapusan sementara untuk melindungi dari penghapusan dan penjaminan tingkat objek, atau salin blob blok ke akun penyimpanan lain di wilayah lain menggunakan AzCopy, Azure PowerShell, atau pustaka Azure Data Movement.
- File: Gunakan Azure Backup untuk mencadangkan berbagi file Anda. Aktifkan juga penghapusan sementara untuk melindungi dari penghapusan berbagi file yang tidak disengaja. Untuk geo-redundansi saat GRS tidak tersedia, gunakan AzCopy atau Azure PowerShell untuk menyalin file Anda ke akun penyimpanan lain di wilayah lain.
- Tabel: Gunakan AzCopy untuk mengekspor data tabel ke akun penyimpanan lain di wilayah lain.
Melacak pemadaman
Pelanggan dapat berlangganan Dasbor Azure Service Health untuk melacak kesehatan dan status Azure Storage dan layanan Azure lainnya.
Microsoft juga menyarankan agar Anda merancang aplikasi untuk mempersiapkan kemungkinan kegagalan tulis. Aplikasi Anda harus mengekspos kegagalan tulis dengan cara yang memperingatkan Anda tentang kemungkinan pemadaman di wilayah utama.
Lihat juga
- Menggunakan geo redundansi untuk merancang aplikasi dengan ketersediaan tinggi
- Tutorial: Membangun aplikasi yang sangat tersedia dengan penyimpanan Blob
- Redundansi Azure Storage
- Cara kerja failover terencana yang dikelola pelanggan (pratinjau)
- Cara kerja failover yang dikelola pelanggan (tidak direncanakan)