Pemulihan bencana dan kegagalan akun penyimpanan
Microsoft berusaha untuk memastikan bahwa layanan Azure selalu tersedia. Namun, pemadaman layanan yang tidak direncanakan dapat terjadi. Jika aplikasi Anda memerlukan ketahanan, Microsoft merekomendasikan penggunaan penyimpanan geo-redundan, sehingga data Anda disalin ke wilayah kedua. Selain itu, pelanggan harus memiliki rencana pemulihan bencana 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.
Azure Storage mendukung kegagalan akun untuk akun penyimpanan geo-redundan. 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.
Kegagalan akun tersedia untuk jenis akun penyimpanan tujuan umum v1, tujuan umum v2, dan Blob dengan penyebaran Azure Resource Manager. Kegagalan akun tidak didukung untuk akun penyimpanan dengan ruang nama hierarki diaktifkan.
Artikel ini menjelaskan konsep dan proses yang terlibat dengan kegagalan akun dan membahas cara menyiapkan akun penyimpanan Anda untuk pemulihan dengan jumlah dampak pelanggan yang paling sedikit. Untuk mempelajari cara memulai kegagalan akun di portal Azure atau PowerShell, lihat Memulai kegagalan akun.
Catatan
Artikel ini menggunakan modul Azure Az PowerShell, yang merupakan modul PowerShell yang direkomendasikan untuk berinteraksi dengan Azure. Untuk mulai menggunakan modul Az PowerShell, lihat Menginstal Azure PowerShell. Untuk mempelajari cara bermigrasi ke modul Az PowerShell, lihat Memigrasikan Azure PowerShell dari AzureRM ke Az.
Pilih opsi redundansi yang tepat
Azure Storage menyimpan beberapa salinan akun penyimpanan Anda untuk memastikan ketahanan dan ketersediaan tinggi. Opsi redundansi mana yang Anda pilih untuk akun Anda tergantung pada tingkat ketahanan yang Anda butuhkan. Untuk perlindungan terhadap pemadaman regional, konfigurasikan akun Anda untuk penyimpanan geo-redundan, dengan atau tanpa opsi akses baca dari wilayah sekunder:
Penyimpanan geo-redundant (GRS) atau penyimpanan geo-zone-redundant (GZRS) menyalin data Anda secara asinkron di dua wilayah geografis yang setidaknya terpisah ratusan mil. Jika wilayah utama mengalami pemadaman, maka wilayah sekunder berfungsi sebagai sumber redundan untuk data Anda. Anda dapat memulai kegagalan untuk mengubah titik akhir sekunder menjadi titik akhir utama.
Penyimpanan read-access geo-redundant storage (RA-GRS) atau penyimpanan read-access geo-zone-redundant (RA-GZRS) menyediakan penyimpanan geo-redundan dengan manfaat tambahan akses baca ke titik akhir sekunder. Jika pemadaman terjadi di titik akhir utama, aplikasi yang dikonfigurasi untuk akses baca ke sekunder dan dirancang untuk ketersediaan tinggi dapat terus membaca dari titik akhir sekunder. Microsoft merekomendasikan RA-GZRS untuk ketersediaan dan ketahanan maksimum untuk aplikasi Anda.
Untuk informasi selengkapnya tentang redundansi di Azure Storage, lihat Redundansi Azure Storage.
Peringatan
Penyimpanan geo-redundan membawa risiko kehilangan data. Data disalin ke wilayah sekunder secara asinkron, yang berarti ada keterlambatan antara ketika data yang ditulis ke wilayah utama ditulis ke wilayah sekunder. Jika terjadi pemadaman, operasi tulis ke titik akhir utama yang belum disalin ke titik akhir sekunder akan hilang.
Desain untuk ketersediaan tinggi
Penting untuk merancang aplikasi Anda untuk ketersediaan tinggi sejak awal. Lihat sumber daya Azure ini untuk panduan dalam mendesain aplikasi dan perencanaan Anda untuk 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.
Selain itu, ingatlah 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 jika terjadi bencana setempat.
- 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 Dashboard 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.
Memahami proses kegagalan 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.
Catatan
Failover akun yang dikelola pelanggan belum didukung di akun yang memiliki namespace layanan hierarkis (Azure Data Lake Storage Gen2). Untuk daftar lengkapnya, lihat Fitur penyimpanan Blob yang tersedia di Azure Data Lake Storage Gen2.
Jika terjadi bencana yang memengaruhi wilayah utama, maka Microsoft akan mengelola failover akun yang memiliki namespace layanan hierarkis. Untuk informasi lebih lanjut, lihat Failover yang dikelola Microsoft.
Cara kerja kegagalan akun
Dalam keadaan normal, klien menulis data ke akun Azure Storage di wilayah utama, dan data tersebut disalin secara tidak sinkron 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 untuk blob, tabel, antrean, dan file tetap sama setelah kegagalan.
Penting
Setelah kegagalan selesai, akun penyimpanan dikonfigurasi untuk menjadi redundan secara lokal di titik akhir 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 Implikasi penting dari failover akun.
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 primer ke wilayah sekunder, selalu ada penundaan sebelum menulis ke wilayah utama disalin ke wilayah sekunder. Jika wilayah utama menjadi tidak tersedia, tulis 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, setiap data yang ditulis ke primer yang belum juga disalin ke sekunder hilang secara permanen.
Properti Waktu Sinkronisasi Terakhir menunjukkan waktu terbaru bahwa data dari wilayah utama dijamin telah ditulis ke wilayah sekunder. Semua data yang ditulis sebelum waktu sinkronisasi terakhir tersedia di 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 keluarkan dengan memulai kegagalan akun.
Sebagai praktik terbaik, rancang aplikasi Anda sehingga Anda dapat menggunakan waktu sinkronisasi terakhir untuk mengevaluasi hilangnya 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 tulisan mana yang belum disinkronkan ke sekunder.
Untuk informasi selengkapnya tentang memeriksa properti Waktu Sinkronisasi Terakhir, lihat Memeriksa properti Waktu Sinkronisasi Terakhir untuk akun penyimpanan.
Berhati-hatilah saat gagal kembali ke primer asli
Setelah Anda gagal 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 beberapa waktu sebelum data yang ada di wilayah utama 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 primer asli adalah GRS/RA-GRS atau GZRS/RA-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 wilayah utama asli dikonfigurasi untuk LRS, Anda dapat mengonfigurasinya menjadi GRS atau RA-GRS. Jika wilayah utama asli dikonfigurasi untuk ZRS, Anda dapat mengonfigurasinya menjadi GRS atau RA-GRS. 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.
Pertimbangan tambahan
Tinjau pertimbangan tambahan yang dijelaskan di bagian ini untuk memahami bagaimana aplikasi dan layanan Anda mungkin terpengaruh saat Anda memaksakan kegagalan.
Akun penyimpanan berisi blob yang diarsipkan
Akun penyimpanan yang berisi kegagalan akun dukungan blob yang diarsipkan. Setelah kegagalan selesai, semua blob yang diarsipkan perlu 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 kegagalan selesai, klien dapat kembali 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 akan dapat melakukan operasi manajemen pada akun penyimpanan.
Karena penyedia sumber daya Azure Storage tidak gagal, properti Lokasi akan mengembalikan lokasi utama asli setelah kegagalan selesai.
Komputer virtual Azure
Komputer virtual Azure (VM) tidak gagal sebagai bagian dari kegagalan akun. Jika wilayah utama menjadi tidak tersedia, dan Anda gagal ke wilayah sekunder, maka Anda harus membuat ulang VM setelah kegagalan. Juga, ada potensi kehilangan data yang terkait dengan kegagalan akun. Microsoft merekomendasikan panduan ketersediaan tinggi dan pemulihan bencana khusus berikut ke komputer virtual Azure.
Disk tidak terkelola Azure
Sebagai praktik terbaik, Microsoft merekomendasikan untuk mengonversi disk yang tidak dikelola ke disk terkelola. Namun, jika Anda perlu menggagalkan akun yang berisi disk yang tidak dikelola yang terpasang pada Azure VM, Anda harus mematikan VM sebelum memulai kegagalan.
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. Kegagalan akun tidak dapat dilanjutkan ketika ada sewa pada blob. Untuk melakukan kegagalan, ikuti langkah-langkah berikut:
- Sebelum Anda mulai, 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 VHD untuk disk yang tidak dikelola. Perhatikan waktu saat Anda menghapus VM.
- Tunggu hingga Waktu Sinkronisasi Terakhir telah diperbarui, dan lebih baru dari waktu Anda menghapus VM. Langkah ini penting, karena jika titik akhir sekunder belum sepenuhnya diperbarui dengan file VHD ketika kegagalan terjadi, maka VM mungkin tidak berfungsi dengan baik di wilayah utama baru.
- Memulai kegagalan akun.
- Tunggu hingga kegagalan akun selesai dan wilayah sekunder telah 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.
Fitur dan layanan yang tidak didukung
Fitur dan layanan berikut ini tidak didukung untuk kegagalan akun:
- Sinkronisasi File Azure tidak mendukung kegagalan akun penyimpanan. Akun penyimpanan yang berisi berbagi file Azure yang digunakan sebagai titik akhir cloud di Sinkronisasi File Azure tidak boleh gagal. Melakukannya akan menyebabkan sinkronisasi berhenti berfungsi dan juga dapat menyebabkan kehilangan data yang tidak terduga dalam kasus berkas yang baru ditingkatkan.
- Akun penyimpanan yang memiliki namespace hierarkis yang diaktifkan (seperti untuk Data Lake Storage Gen2) tidak didukung saat ini.
- Akun penyimpanan yang berisi blob blok premium tidak dapat failover. Akun penyimpanan yang mendukung blob blok premium saat ini tidak mendukung geo-redundansi.
- Akun penyimpanan yang mengaktifkan kebijakan imutabilitas WORM apa pun yang tidak dapat failover. Kebijakan retensi berbasis waktu atau penahanan legal yang tidak/terkunci mencegah kegagalan demi menjaga kepatuhan.
Menyalin data sebagai alternatif untuk kegagalan
Jika akun penyimpanan Anda dikonfigurasi untuk akses baca ke sekunder, maka Anda dapat merancang aplikasi Anda untuk membaca dari titik akhir sekunder. Jika Anda lebih suka tidak gagal jika terjadi pemadaman di wilayah utama, Anda bisa menggunakan alat seperti AzCopy, Azure PowerShell, atau pustaka Azure Data Movement untuk menyalin data dari akun penyimpanan Anda di wilayah sekunder ke akun penyimpanan lain di wilayah yang tidak terpengaruh. Anda kemudian dapat mengarahkan aplikasi ke akun penyimpanan tersebut untuk ketersediaan baca dan tulis.
Perhatian
Kegagalan akun tidak boleh digunakan sebagai bagian dari strategi migrasi data Anda.
Kegagalan yang dikelola Microsoft
Dalam keadaan ekstrem ketika suatu wilayah hilang karena bencana yang signifikan, Microsoft dapat memulai kegagalan regional. Dalam hal ini, Anda tidak perlu melakukan tindakan apa pun. Hingga kegagalan yang dikelola Microsoft selesai, Anda tidak akan memiliki akses tulis ke akun penyimpanan Anda. Aplikasi Anda dapat membaca dari wilayah sekunder jika akun penyimpanan Anda dikonfigurasi untuk RA-GRS atau RA-GZRS.