Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Microsoft berusaha memastikan bahwa layanan Azure selalu tersedia. Namun, pemadaman layanan yang tidak terencana mungkin sesekali terjadi. Komponen kunci 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 yang berlebihan secara geografis, dan memberikan rekomendasi untuk mengembangkan aplikasi yang sangat tersedia dan menguji rencana pemulihan bencana Anda.
Pilih opsi redundansi yang tepat
Azure Storage memelihara beberapa salinan akun penyimpanan Anda untuk memastikan bahwa target ketersediaan dan daya tahan tercapai, bahkan menghadapi kegagalan. Cara duplikasi data memberikan tingkat perlindungan yang berbeda-beda. Setiap opsi menawarkan keuntungannya sendiri, jadi opsi yang Anda pilih tergantung pada tingkat ketahanan yang dibutuhkan oleh aplikasi Anda.
Penyimpanan lokal yang redundan (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 kegagalan rak server dan drive, LRS tidak mengatasi bencana seperti kebakaran atau banjir di dalam pusat data. Menghadapi bencana seperti itu, semua replika dari akun penyimpanan yang dikonfigurasi untuk menggunakan LRS mungkin akan hilang atau tidak dapat dipulihkan.
Sebagai perbandingan, penyimpanan redundant zona (ZRS) menahan salinan akun penyimpanan dan mereplikasinya di setiap dari tiga zona ketersediaan yang terpisah dalam wilayah yang sama. Untuk informasi selengkapnya tentang zona ketersediaan, lihat Zona ketersediaan Azure.
Penyimpanan geo-redundan dan pindah-layanan otomatis
Penyimpanan redundan secara geografis (GRS), penyimpanan redundan zona geografis (GZRS), dan penyimpanan redundan zona geografis dengan akses baca (RA-GZRS) adalah contoh opsi penyimpanan redundan secara geografis. Ketika 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 Anda jika terjadi pemadaman di seluruh wilayah utama.
Tidak seperti LRS dan ZRS, penyimpanan geo-redundan juga memberikan dukungan untuk pemindahan otomatis yang tidak direncanakan ke wilayah sekunder jika terjadi 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 tak terencana selesai, klien dapat mulai menulis ke titik akhir utama yang baru.
Penyimpanan geo-redundant akses-baca (RA-GRS) dan penyimpanan geo-zone-redundant akses-baca (RA-GZRS) juga menyediakan penyimpanan geo-redundant, tetapi menawarkan manfaat tambahan berupa akses-baca ke endpoint sekunder. Opsi-opsi ini ideal untuk aplikasi yang dirancang untuk aplikasi bisnis kritis dengan ketersediaan tinggi. Jika titik akhir utama mengalami gangguan, aplikasi yang dikonfigurasi untuk akses baca ke wilayah sekunder dapat terus beroperasi. Microsoft menyarankan RA-GZRS untuk ketersediaan maksimum dan ketahanan akun penyimpanan Anda.
Untuk informasi selengkapnya tentang redundansi untuk Azure Storage, lihat Redundansi Azure Storage.
Rencana Pemulihan Gangguan
Akun Azure Storage mendukung tiga jenis failover.
- Failover terencana yang dikelola pelanggan - 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 - Mungkin diprakarsai oleh Microsoft karena bencana serius di regional utama. 1,2
1 Failover yang dikelola Microsoft tidak dapat dimulai untuk akun penyimpanan individu, langganan, atau penyewa. Untuk informasi selengkapnya, 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, ekspektasi terkait kehilangan data, dan dukungan untuk akun dengan namespace hierarkis diaktifkan (Azure Data Lake Storage). Tabel ini merangkum aspek-aspek dari setiap jenis failover.
| Jenis | Cakupan Pemulihan Otomatis | Kasus penggunaan | Kehilangan data yang diharapkan | Namespace Hirarkis (HNS) didukung |
|---|---|---|---|---|
| Failover terencana yang dikelola pelanggan | Akun penyimpanan | Titik akhir layanan penyimpanan untuk wilayah primer dan sekunder tersedia, dan Anda ingin melakukan pengujian pemulihan bencana. Ujung layanan penyimpanan untuk wilayah utama tersedia, tetapi layanan lain mencegah beban kerja Anda berfungsi dengan baik. Untuk secara proaktif mempersiapkan bencana skala besar, seperti angin topan, yang mungkin mempengaruhi suatu wilayah. |
Tidak | Ya |
| Failover yang dikelola pelanggan (tidak terencana) | Akun penyimpanan | Titik akhir layanan penyimpanan untuk wilayah utama menjadi tidak tersedia, tetapi wilayah kedua tersedia. Anda menerima peringatan Azure di mana Microsoft menyarankan Anda untuk melakukan operasi failover pada akun penyimpanan yang berpotensi terkena dampak pemadaman. |
Ya | Ya |
| dikelola oleh Microsoft | Seluruh wilayah | Wilayah utama menjadi tidak tersedia karena bencana besar, 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 | Failover yang dikelola pelanggan (tidak terencana) |
|---|---|---|
| wilayah sekunder | Wilayah sekunder menjadi yang utama yang baru. | Wilayah sekunder menjadi yang utama yang 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 telah diubah menjadi LRS |
| ...konfigurasi redundansi-geografis | Pemulihan data geografis tetap dipertahankan | Redundansi geo hilang |
Tabel berikut merangkum konfigurasi redundansi yang dihasilkan pada setiap tahap proses failover dan failback untuk setiap jenis failover.
| Asli konfigurasi |
Setelah failover |
Setelah diaktifkan kembali redundansi geografis |
Setelah pemulihan kembali |
Setelah diaktifkan 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 oleh pelanggan (tidak terencana) | ||||
| GRS | LRS | GRS | LRS | GRS |
| GZRS | LRS | GRS | ZRS | GZRS |
1 Redundansi geo tetap terjaga selama failover yang direncanakan dan tidak memerlukan pengaturan ulang secara manual.
Failover terencana yang dikelola pelanggan
Failover terencana dapat digunakan dalam berbagai skenario termasuk pengujian pemulihan bencana yang direncanakan, pendekatan proaktif terhadap bencana skala besar, atau untuk memulihkan dari gangguan yang tidak terkait dengan penyimpanan.
Selama proses failover yang direncanakan, wilayah primer dan sekunder ditukar. Wilayah utama asli diturunkan dan menjadi wilayah sekunder yang baru. Pada saat yang sama, wilayah sekunder asli dipromosikan dan menjadi yang utama yang 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 primer dan sekunder tersedia sepanjang proses tersebut. Untuk detail selengkapnya, lihat bagian Mengantisipasi kehilangan dan inkonsistensi data .
Untuk memahami dampak dari jenis failover ini pada pengguna dan aplikasi Anda, akan bermanfaat untuk mengetahui apa yang terjadi selama setiap langkah dari proses failover dan failback yang direncanakan. Untuk detail tentang cara kerja proses ini, lihat Cara kerja failover yang dikelola pelanggan (terencana).
Failover yang dikelola pelanggan (tidak terencana)
Jika titik akhir data untuk layanan penyimpanan di akun penyimpanan Anda menjadi tidak tersedia di wilayah utama, Anda dapat memulai pemulihan tak terencana ke wilayah sekunder. Setelah failover selesai, wilayah sekunder menjadi utama yang baru dan pengguna dapat melanjutkan mengakses data di sana.
Untuk memahami dampak dari jenis failover ini pada pengguna dan aplikasi Anda, penting untuk mengetahui apa yang terjadi di setiap langkah proses failover dan failback yang tidak terencana. Untuk detail tentang cara kerja proses, lihat Cara kerja failover yang dikelola pelanggan (tidak direncanakan).
Failover yang dikelola oleh Microsoft
Microsoft mungkin memulai failover regional dalam keadaan ekstrem, seperti bencana yang berdampak pada seluruh kawasan geografis. Selama acara ini berlangsung, tidak ada tindakan yang perlu Anda ambil. Jika akun penyimpanan Anda dikonfigurasi untuk RA-GRS atau RA-GZRS, aplikasi Anda dapat membaca dari wilayah sekunder selama pemulihan gagal yang dikelola Microsoft. Namun, Anda tidak memiliki akses menulis ke akun penyimpanan Anda sampai proses failover selesai.
Penting
Gunakan opsi failover yang dikelola oleh 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 oleh Microsoft akan dimulai untuk seluruh unit fisik, seperti wilayah atau pusat data. Itu tidak dapat dimulai untuk akun penyimpanan individu, langganan, atau penyewa. Jika Anda memerlukan kemampuan untuk melakukan failover secara selektif atas akun penyimpanan individual Anda, gunakan failover terencana yang dikelola pelanggan.
Antisipasi hilangnya data dan ketidakkonsistenan
Peringatan
Pengelolaan failover tak terencana oleh pelanggan biasanya melibatkan beberapa kehilangan data, dan juga dapat berpotensi menimbulkan inkonsistensi file dan data. Dalam rencana pemulihan bencana Anda, penting untuk mempertimbangkan dampak yang akan ditimbulkan oleh failover akun terhadap data Anda sebelum memulai satu.
Karena data ditulis secara asinkron dari wilayah utama ke wilayah sekunder, selalu ada penundaan sebelum penulisan ke wilayah utama disalin ke wilayah sekunder. Jika wilayah utama menjadi tidak tersedia, ada kemungkinan bahwa penulisan terbaru belum disalin ke wilayah sekunder.
Ketika terjadi failover yang tidak direncanakan, semua data di wilayah utama hilang karena wilayah sekunder menjadi wilayah utama yang baru. Semua data yang telah disalin ke wilayah sekunder tetap terjaga saat kegagalan sistem terjadi. Namun, data apa pun yang ditulis ke wilayah utama dan belum ada di wilayah sekunder akan hilang secara permanen.
Wilayah utama yang baru dikonfigurasi untuk menjadi redundant lokal (LRS) setelah failover.
Anda mungkin juga mengalami inkonsistensi file atau data jika akun penyimpanan Anda memiliki satu atau lebih dari berikut ini yang diaktifkan:
Waktu sinkronisasi 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 perangkat sekunder dan berpotensi hilang. Saat terjadi gangguan, gunakan properti ini untuk memperkirakan jumlah kehilangan data yang mungkin Anda alami ketika 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 penulisan memungkinkan Anda membandingkan waktu operasi penulisan terakhir Anda dengan waktu sinkronisasi terakhir. Metode ini memungkinkan Anda untuk menentukan penulisan mana yang belum disinkronkan ke perangkat sekunder dan berisiko hilang.
Untuk informasi selengkapnya tentang memeriksa properti Waktu Sinkronisasi Terakhir , lihat Memeriksa properti Waktu Sinkronisasi Terakhir untuk akun penyimpanan.
Konsistensi Berkas 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, gangguan di wilayah utama mungkin mencegah beberapa file dalam sebuah kontainer atau direktori berhasil direplikasi ke wilayah sekunder. Konsistensi untuk semua file di dalam kontainer atau direktori setelah failover akun penyimpanan tidak dijamin.
Ketidakkonsistenan data umpan perubahan dan blob
Failover tak terencana pada akun penyimpanan yang dikelola oleh pelanggan dengan umpan perubahan diaktifkan dapat menyebabkan inkonsistensi antara log umpan perubahan dan data blob dan/atau metadata. Ketidakkonsistenan semacam itu dapat terjadi akibat sifat asinkron dari pembaruan log perubahan dan replikasi data antara wilayah utama dan sekunder. Anda dapat menghindari ketidakkonsistenan dengan mengambil tindakan pencegahan berikut:
- Pastikan bahwa semua catatan log ditulis ke dalam berkas log.
- Pastikan bahwa semua data penyimpanan direplikasi dari wilayah utama ke wilayah sekunder.
Untuk informasi selengkapnya tentang umpan perubahan, lihat Cara kerja umpan perubahan.
Ingatlah bahwa fitur lain dari akun penyimpanan juga memerlukan pengaktifan umpan perubahan. Fitur-fitur ini termasuk pencadangan operasional Azure Blob Storage, Replikasi objek, dan pemulihan Point-in-time untuk blob blok.
Ketidakkonsistenan pemulihan titik waktu
Failover yang dikelola oleh pelanggan didukung untuk akun penyimpanan tingkat standar tujuan umum v2 yang mencakup blok blob. 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 mengembalikan blok blob ke titik waktu yang tidak lebih awal dari waktu penyelesaian failover. Anda dapat memeriksa waktu penyelesaian failover di tab redundansi dari akun penyimpanan Anda di portal Azure.
Waktu dan biaya pengalihan
Waktu yang diperlukan untuk menyelesaikan failover yang dikelola pelanggan setelah dimulai dapat bervariasi, meskipun biasanya memerlukan waktu kurang dari satu jam.
Failover terkelola pelanggan yang direncanakan tidak kehilangan geo-redundansinya setelah failover dan kemudian failback, tetapi failover terkelola pelanggan yang tidak direncanakan akan kehilangan geo-redundansinya.
Memulai failover yang tidak direncanakan dan dikelola oleh pelanggan secara otomatis mengonversi akun penyimpanan Anda menjadi penyimpanan redundan lokal (LRS) dalam wilayah primer baru, dan menghapus akun penyimpanan di wilayah primer asli.
Anda dapat mengaktifkan kembali penyimpanan geo-redundan (GRS) atau penyimpanan geo-redundan akses baca (RA-GRS) untuk akun tersebut, tetapi menyalin ulang data ke wilayah sekunder baru akan dikenakan biaya. Selain itu, setiap blob yang diarsipkan perlu dihidupkan kembali ke tingkat daring sebelum akun dapat dikonfigurasi ulang untuk redundansi geografis. Rehidrasi ini juga memerlukan biaya tambahan. Untuk informasi lebih lanjut tentang harga, lihat:
Setelah Anda mengaktifkan kembali GRS untuk akun penyimpanan Anda, Microsoft akan mulai mereplikasi data di akun Anda ke wilayah sekunder yang baru. Waktu yang dibutuhkan untuk menyelesaikan replikasi tergantung pada beberapa faktor. Faktor-faktor ini termasuk:
- Jumlah dan ukuran objek dalam akun penyimpanan. Mereplikasi banyak objek kecil dapat memakan waktu lebih lama dibandingkan dengan mereplikasi objek yang lebih sedikit dan lebih besar.
- Sumber daya yang tersedia untuk replikasi latar belakang, seperti CPU, memori, kapasitas disk, dan WAN. Lalu lintas langsung memiliki prioritas lebih tinggi dibandingkan replikasi geografis.
- Jumlah cuplikan per blob, jika berlaku.
- Strategi pemartisian data, jika akun penyimpanan Anda mengandung tabel. Proses replikasi tidak dapat berkembang melampaui jumlah kunci partisi yang Anda gunakan.
Jenis akun penyimpanan yang didukung
Semua tawaran geo-redundan mendukung failover yang dikelola oleh Microsoft. Selain itu, beberapa jenis akun mendukung failover akun yang dikelola pelanggan, seperti yang ditunjukkan dalam tabel berikut:
| Jenis failover | GRS/RA-GRS | GZRS/RA-GZRS |
|---|---|---|
| Failover terencana yang dikelola pelanggan | Akun General-purpose v2 Akun General-purpose v1 Akun Penyimpanan Blob Legasi |
Akun serbaguna v2 |
| Failover yang dikelola oleh pelanggan (tidak terencana) | Akun General-purpose v2 Akun General-purpose v1 Akun Penyimpanan Blob Legasi |
Akun serbaguna v2 |
| Failover yang dikelola oleh Microsoft | Semua jenis akun | Akun serbaguna v2 |
Akun penyimpanan klasik
Penting
Failover yang dikelola pelanggan hanya didukung untuk akun penyimpanan yang diterapkan menggunakan model penerapan 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, jadi wilayah utama saat ini tidak boleh berada dalam keadaan gagal.
Selama bencana yang memengaruhi wilayah utama, Microsoft mengelola failover untuk akun penyimpanan klasik. Untuk informasi selengkapnya, lihat Failover yang dikelola Microsoft.
Fitur dan layanan yang tidak didukung
Fitur dan layanan berikut tidak didukung untuk failover yang dikelola pelanggan:
- Sinkronisasi File Azure tidak mendukung failover akun yang dikelola pelanggan. Akun penyimpanan yang digunakan sebagai titik akhir cloud untuk Azure File Sync sebaiknya tidak dilakukan failover. Pemindahan sistem cadangan mengganggu sinkronisasi file dan dapat menyebabkan kehilangan data yang tidak terduga dari file yang baru dipindahkan. 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 premium block blobs saat ini tidak mendukung geo-redundansi.
- Pemulihan bencana yang dikelola pelanggan tidak didukung baik pada akun sumber maupun akun tujuan dalam kebijakan replikasi objek.
- Sistem Berkas Jaringan (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 dapat digunakan sebagai referensi untuk dukungan fitur.
| Failover Terencana | Pengalihan yang Tidak Direncanakan | |
|---|---|---|
| Azure Data Lake Storage | Didukung | Didukung |
| Ubah Umpan | Tidak didukung | Didukung |
| Replikasi Objek | Tidak didukung | Tidak didukung |
| SFTP | Didukung | Didukung |
| 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 lebih lanjut.
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 gangguan layanan. Sistem 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 blob yang diarsipkan mendukung pengalihan akun. Namun, setelah failover yang dikelola pelanggan selesai, semua blob yang diarsipkan harus direhidrasi ke lapisan online sebelum akun dapat dikonfigurasi untuk geo-redundansi.
Penyedia sumber daya penyimpanan
Microsoft menyediakan dua API REST untuk bekerja dengan sumber daya Azure Storage. API ini membentuk dasar dari semua tindakan yang dapat Anda lakukan terhadap Azure Storage. API REST Azure Storage memungkinkan Anda untuk bekerja dengan data dalam akun penyimpanan Anda, termasuk data blob, antrian, file, dan tabel. API REST penyedia sumber daya Azure Storage memungkinkan Anda untuk mengelola akun penyimpanan dan sumber daya terkait.
Setelah failover selesai, klien dapat membaca dan menulis data Azure Storage di wilayah utama baru. Namun, penyedia sumber daya Azure Storage tidak dialihkan, sehingga operasi pengelolaan sumber daya harus tetap dilakukan di wilayah utama. Jika wilayah utama tidak tersedia, Anda tidak dapat melakukan operasi manajemen pada akun penyimpanan.
Karena penyedia sumber daya Azure Storage tidak gagal, properti Lokasi akan mengembalikan lokasi utama asli setelah failover selesai.
Mesin virtual Azure
Mesin virtual Azure (VM) tidak mengalami failover sebagai bagian dari failover akun penyimpanan. Mesin virtual yang dialihkan ke wilayah sekunder sebagai respons terhadap gangguan perlu dibuat ulang setelah failover selesai. Failover akun berpotensi menyebabkan kehilangan data yang disimpan di dalam disk sementara ketika mesin virtual (VM) dimatikan. Microsoft merekomendasikan untuk mengikuti panduan ketersediaan tinggi dan pemulihan bencana khusus untuk komputer virtual di Azure.
Azure disk tidak terkelola
Disk tidak terkelola disimpan sebagai blob halaman di Penyimpanan Azure. Ketika sebuah VM berjalan di Azure, setiap disk yang tidak dikelola yang terpasang pada VM tersebut disewakan. Proses pemulihan akun tidak dapat dilanjutkan ketika ada sewa pada sebuah blob. Sebelum failover dapat dilakukan pada akun yang berisi disk tidak terkelola yang terpasang pada Azure VM, disk tersebut harus dimatikan. Untuk alasan ini, praktik terbaik yang direkomendasikan oleh Microsoft termasuk mengonversi disk tak terkelola menjadi disk terkelola.
Untuk melakukan failover pada akun yang berisi disk yang tidak dikelola, ikuti langkah-langkah berikut:
- Sebelum Anda memulai, catatlah nama dari disk yang tidak dikelola, nomor unit logisnya (LUN), dan VM yang terhubung dengan mereka. Melakukan hal ini akan mempermudah penyambungan kembali disk setelah failover.
- Matikan mesin virtual.
- Hapus VM, tetapi pertahankan file hard disk virtual (VHD) untuk disk yang tidak dikelola. Catat 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 saat failover terjadi, dan bahwa VM berfungsi dengan baik di wilayah utama yang baru.
- Lakukan inisiasi pengalihan akun.
- Tunggu sampai alih fungsi akun selesai dan wilayah sekunder menjadi wilayah utama yang baru.
- Buat VM di wilayah primer baru dan pasang kembali VHD.
- Mulai VM baru.
Ingatlah bahwa data apa pun yang disimpan di disk sementara akan hilang ketika VM dimatikan.
Menyalin data sebagai alternatif pemulihan darurat
Seperti yang telah dibahas sebelumnya, Anda dapat mempertahankan ketersediaan tinggi dengan mengkonfigurasi aplikasi untuk menggunakan akun penyimpanan yang dikonfigurasi untuk akses baca di wilayah sekunder. Namun, jika Anda lebih memilih untuk tidak gagal beralih selama gangguan 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 penyalinan selesai, Anda dapat mengkonfigurasi 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 agar memiliki ketersediaan tinggi sejak awal. Rujuk ke 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: Membangun aplikasi dengan ketersediaan tinggi menggunakan penyimpanan Blob: Tutorial yang menunjukkan cara membangun aplikasi dengan ketersediaan tinggi yang secara otomatis beralih antar titik akhir ketika kegagalan dan pemulihan disimulasikan.
Rujuk praktik terbaik ini untuk menjaga ketersediaan tinggi data Azure Storage Anda:
- Disk: 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.
- Blok blob: Aktifkan penghapusan lunak untuk melindungi dari penghapusan dan penimpaan pada tingkat objek, atau salin blok blob ke akun penyimpanan lain di wilayah yang berbeda menggunakan AzCopy, Azure PowerShell, atau Azure Data Movement Library.
- File: Gunakan Azure Backup untuk mencadangkan berbagi file Anda. Juga aktifkan soft delete untuk melindungi dari penghapusan file share 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 yang berbeda.
Lacak pemadaman
Pelanggan dapat berlangganan Dasbor Azure Service Health untuk melacak kesehatan dan status Azure Storage dan layanan Azure lainnya.
Microsoft juga merekomendasikan agar Anda merancang aplikasi Anda untuk bersiap menghadapi kemungkinan kegagalan penulisan. Aplikasi Anda harus memaparkan kegagalan penulisan dengan cara yang memberi tahu Anda tentang kemungkinan terjadinya gangguan di wilayah utama.