Pemulihan bencana dan failover untuk Azure Files
Microsoft berusaha untuk memastikan bahwa layanan Azure selalu tersedia. Namun, pemadaman layanan yang tidak diencana mungkin terjadi, dan Anda harus memiliki rencana pemulihan bencana (DR) untuk menangani pemadaman layanan regional. Bagian penting dari rencana pemulihan bencana sedang bersiap untuk gagal ke titik akhir sekunder jika titik akhir utama menjadi tidak tersedia. Artikel ini menjelaskan konsep dan proses yang terlibat dengan pemulihan bencana (DR) dan failover akun penyimpanan.
Penting
Azure File Sync hanya mendukung failover akun penyimpanan jika Storage Sync Service juga gagal. Ini karena Azure File Sync mengharuskan akun penyimpanan dan Storage Sync Service berada di wilayah Azure yang sama. Jika hanya akun penyimpanan yang gagal, operasi sinkronisasi dan penjenjangan cloud akan gagal hingga Storage Sync Service dialihkan ke wilayah sekunder. Jika Anda ingin melakukan failover pada akun penyimpanan yang berisi berbagi file Azure yang digunakan sebagai titik akhir cloud di Azure File Sync, lihat Praktik terbaik pemulihan bencana Azure File Sync dan pemulihan server Azure File Sync.
Failover terencana yang dikelola pelanggan (pratinjau)
Failover yang dikelola pelanggan juga dapat digunakan dalam beberapa skenario, termasuk pengujian pemulihan bencana yang direncanakan, pendekatan proaktif untuk bencana skala besar, atau untuk pulih dari pemadaman terkait non-penyimpanan.
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.
Metrik dan biaya pemulihan
Untuk merumuskan strategi DR yang efektif, organisasi harus memahami:
- Berapa banyak data yang mampu kehilangan jika terjadi gangguan (tujuan titik pemulihan atau RPO)
- Seberapa cepat diperlukan untuk dapat memulihkan fungsi dan data bisnis (tujuan waktu pemulihan atau RTO)
Biaya DR umumnya meningkat dengan RPO/RTO yang lebih rendah atau nol. Perusahaan yang perlu aktif dan berjalan dalam beberapa detik setelah bencana dan tidak dapat mempertahankan kehilangan data apa pun akan membayar lebih banyak untuk DR, sementara mereka yang memiliki nomor RPO/RTO yang lebih tinggi akan membayar lebih sedikit. Azure menyediakan solusi yang dapat bekerja dengan berbagai persyaratan RPO dan RTO.
Pilih opsi redundansi yang tepat
Azure Files menawarkan berbagai opsi redundansi untuk melindungi data Anda dari peristiwa yang direncanakan dan tidak direncanakan mulai dari kegagalan perangkat keras sementara, pemadaman jaringan dan listrik, hingga bencana alam. Semua berbagi file Azure dapat menggunakan penyimpanan redundan lokal (LRS) atau zona redundan (ZRS). Untuk informasi selengkapnya, lihat Redundansi Azure Files.
Azure Files mendukung failover akun untuk akun penyimpanan standar yang dikonfigurasi dengan penyimpanan geo-redundan (GRS) dan penyimpanan redundan zona geografis (GZRS) untuk perlindungan terhadap pemadaman regional. Dengan kegagalan akun, Anda dapat memulai proses kegagalan untuk akun penyimpanan Anda jika titik akhir utama menjadi tidak tersedia. Kegagalan memperbarui titik akhir sekunder agar menjadi titik akhir primer untuk akun penyimpanan Anda. Setelah kegagalan selesai, klien dapat mulai menulis ke titik akhir primer baru.
GRS dan GZRS masih membawa risiko kehilangan data karena data disalin ke wilayah sekunder secara asinkron, yang berarti ada penundaan sebelum penulisan ke wilayah utama disalin ke wilayah sekunder. Jika terjadi pemadaman, operasi tulis ke titik akhir utama yang belum disalin ke titik akhir sekunder akan hilang. Ini berarti kegagalan yang memengaruhi wilayah utama dapat mengakibatkan kehilangan data jika wilayah utama tidak dapat dipulihkan. Interval antara penulisan terbaru ke wilayah utama dan penulisan terakhir ke wilayah sekunder adalah RPO. Azure Files biasanya memiliki RPO 15 menit atau kurang, meskipun saat ini tidak ada SLA tentang berapa lama waktu yang diperlukan untuk mereplikasi data ke wilayah sekunder.
Penting
GRS/GZRS tidak didukung untuk berbagi file Azure premium. Namun, Anda dapat menyinkronkan antara dua berbagi file Azure untuk mencapai redundansi geografis .
Desain untuk ketersediaan tinggi
Penting untuk merancang aplikasi Anda untuk ketersediaan tinggi sejak awal. Lihat sumber daya Azure ini untuk panduan tentang 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 guna memanfaatkan penyimpanan geo-redundan untuk berbagi file SMB.
Kami juga menyarankan agar Anda merancang aplikasi Anda untuk mempersiapkan kemungkinan kegagalan penulisan. Aplikasi Anda harus mengekspos kegagalan tulis dengan cara yang memperingatkan Anda tentang kemungkinan pemadaman di wilayah utama.
Sebagai praktik terbaik, rancang aplikasi Anda untuk memeriksa properti Waktu Sinkronisasi Terakhir untuk mengevaluasi kehilangan data yang diharapkan. Misalnya, jika Anda mencatat semua operasi tulis, maka Anda dapat membandingkan waktu operasi tulis terakhir Anda dengan waktu sinkronisasi terakhir untuk menentukan penulisan mana yang belum disinkronkan ke sekunder.
Melacak pemadaman
Anda dapat berlangganan Dasbor Azure Service Health untuk melacak kesehatan dan status Azure Files dan layanan Azure lainnya.
Memahami proses failover akun
Kegagalan akun yang dikelola pelanggan memungkinkan Anda untuk menggagalkan seluruh akun penyimpanan Anda ke wilayah sekunder jika utama menjadi tidak tersedia karena alasan apa pun. Ketika Anda memaksa kegagalan ke wilayah sekunder, klien dapat mulai menulis data ke titik akhir sekunder setelah kegagalan selesai. Kegagalan biasanya berlangsung sekitar satu jam. Sebaiknya tangguhkan beban kerja Anda sebanyak mungkin sebelum memulai failover akun.
Untuk mempelajari cara memulai failover akun, lihat Memulai failover akun.
Cara kerja kegagalan akun
Dalam keadaan normal, klien menulis data ke akun penyimpanan di wilayah utama, dan data tersebut disalin secara asinkron ke wilayah sekunder. Gambar berikut menunjukkan skenario saat wilayah utama tersedia:
Jika titik akhir utama menjadi tidak tersedia karena alasan apa pun, klien tidak lagi dapat menulis ke akun penyimpanan. Gambar berikut menunjukkan skenario di mana primer menjadi tidak tersedia, tetapi belum ada pemulihan yang terjadi:
Pelanggan memulai kegagalan akun ke titik akhir sekunder. Proses kegagalan memperbarui entri DNS yang disediakan oleh Azure Storage sehingga titik akhir sekunder menjadi titik akhir utama baru untuk akun penyimpanan Anda, seperti yang diperlihatkan dalam gambar berikut:
Akses tulis dipulihkan untuk akun geo-redundan setelah entri DNS diperbarui dan permintaan diarahkan ke titik akhir utama baru. Titik akhir layanan penyimpanan yang ada tetap sama setelah failover. Handel dan sewa file tidak dipertahankan pada failover, sehingga klien harus melepas dan melepas kembali berbagi file.
Penting
Setelah failover selesai, akun penyimpanan dikonfigurasi untuk menjadi redundan secara lokal di titik akhir/wilayah utama baru. Untuk melanjutkan replikasi ke sekunder baru, konfigurasikan akun untuk geo-redundansi lagi.
Ingatlah bahwa mengonversi akun penyimpanan redundan lokal untuk menggunakan geo-redundansi memerlukan biaya dan waktu. Untuk informasi selengkapnya, lihat Waktu dan biaya failover.
Mengantisipasi kehilangan data
Perhatian
Kegagalan akun biasanya menyebabkan beberapa data hilang. Penting agar memahami implikasi memulai kegagalan akun.
Karena data ditulis secara asinkron dari wilayah utama ke wilayah sekunder, jika wilayah utama menjadi tidak tersedia, tulisan terbaru mungkin belum disalin ke wilayah sekunder.
Ketika Anda memaksakan failover, semua data di wilayah utama hilang sementara wilayah sekunder menjadi wilayah utama baru. Wilayah utama baru dikonfigurasi untuk menjadi redundan secara lokal setelah failover.
Semua data yang sudah disalin ke sekunder dipertahankan ketika kegagalan terjadi. Namun, data apa pun yang ditulis ke primer yang belum juga disalin ke sekunder akan hilang secara permanen.
Memeriksa properti Waktu Sinkronisasi Terakhir
Properti Waktu Sinkronisasi Terakhir (LST) menunjukkan waktu terbaru bahwa data dari wilayah utama dijamin telah ditulis ke wilayah sekunder. Semua data yang ditulis sebelum waktu sinkronisasi terakhir tersedia pada sekunder, sementara data yang ditulis setelah waktu sinkronisasi terakhir mungkin tidak ditulis ke sekunder dan mungkin hilang. Gunakan properti ini jika terjadi pemadaman untuk memperkirakan jumlah kehilangan data yang mungkin Anda timbulkan dengan memulai failover akun.
Untuk memastikan berbagi file dalam keadaan konsisten ketika failover terjadi, rekam jepret sistem dibuat di wilayah utama setiap 15 menit dan direplikasi ke wilayah sekunder. Ketika failover terjadi ke wilayah sekunder, status berbagi akan didasarkan pada rekam jepret sistem terbaru di wilayah sekunder. Jika kegagalan terjadi di wilayah utama, wilayah sekunder kemungkinan berada di belakang wilayah utama, karena semua penulisan ke primer belum akan direplikasi ke sekunder. Karena geo-lag atau masalah lain, rekam jepret sistem terbaru di wilayah sekunder mungkin lebih lama dari 15 menit.
Semua operasi tulis yang ditulis ke wilayah utama sebelum LST telah berhasil direplikasi ke wilayah sekunder, yang berarti bahwa operasi tersebut tersedia untuk dibaca dari sekunder. Setiap operasi tulis yang ditulis ke wilayah utama setelah waktu sinkronisasi terakhir mungkin atau mungkin belum direplikasi ke wilayah sekunder, yang berarti bahwa operasi tersebut mungkin tidak tersedia untuk operasi baca.
Anda dapat mengkueri nilai properti Waktu Sinkronisasi Terakhir menggunakan Azure PowerShell, Azure CLI, atau pustaka klien. Properti Waktu Sinkronisasi Terakhir adalah nilai tanggal/waktu GMT. Untuk informasi selengkapnya, lihat Memeriksa properti Waktu Sinkronisasi Terakhir untuk akun penyimpanan.
Berhati-hatilah saat gagal kembali ke primer asli
Seperti yang disebutkan sebelumnya, setelah Anda melakukan failover dari wilayah utama ke sekunder, akun penyimpanan Anda dikonfigurasi agar redundan secara lokal di wilayah utama baru. Kemudian Anda dapat mengonfigurasi akun di wilayah utama baru untuk geo-redundansi. Ketika akun dikonfigurasi untuk geo-redundansi lagi setelah failover, wilayah utama baru segera mulai menyalin data ke wilayah sekunder baru, yang merupakan utama sebelum failover asli. Namun, mungkin perlu waktu sebelum data yang ada di primer baru sepenuhnya disalin ke sekunder baru.
Setelah akun penyimpanan dikonfigurasi ulang untuk geo-redundansi, inisiasi failback lain dari primer baru kembali ke sekunder baru dapat dilakukan. Dalam hal ini, wilayah utama asli sebelum failover menjadi wilayah utama lagi, dan dikonfigurasi untuk menjadi redundan secara lokal atau zona-redundan, tergantung pada apakah konfigurasi utama asli adalah GRS atau GZRS. Semua data di wilayah utama pasca-failover (sekunder asli) kemudian akan hilang selama failback. Jika sebagian besar data di akun penyimpanan belum disalin ke sekunder baru sebelum Anda gagal kembali, data utama Anda dapat hilang.
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 hilangnya data yang diharapkan.
Setelah operasi failback, Anda dapat mengonfigurasi wilayah utama baru untuk menjadi geo-redundan lagi. Jika primer asli dikonfigurasi untuk LRS, Anda dapat mengonfigurasinya menjadi GRS. Jika primer asli dikonfigurasi untuk ZRS, Anda dapat mengonfigurasinya menjadi GZRS. Untuk opsi tambahan, lihat Mengubah cara akun penyimpanan direplikasi.
Memulai kegagalan akun
Anda dapat memulai kegagalan akun dari portal Azure, PowerShell, Azure CLI, atau API penyedia sumber daya Azure Storage. Untuk informasi selengkapnya tentang cara memulai kegagalan, lihat Memulai kegagalan akun.
Failover yang dikelola Microsoft
Dalam keadaan ekstrem di mana suatu wilayah hilang karena bencana yang signifikan, Microsoft mungkin memulai failover regional. Dalam hal ini, tidak ada tindakan yang diperlukan pada bagian Anda. Hingga kegagalan yang dikelola Microsoft selesai, Anda tidak akan memiliki akses tulis ke akun penyimpanan Anda.