Bagikan melalui

Keandalan pada Azure Files

Artikel ini menjelaskan dukungan keandalan di Azure Files. Azure Files menyediakan berbagi file yang dikelola sepenuhnya di cloud yang dapat diakses melalui protokol Server Message Block (SMB) dan Network File System (NFS) standar industri.

Saat Anda menggunakan Azure, keandalan adalah tanggung jawab bersama. Microsoft menyediakan berbagai kemampuan untuk mendukung ketahanan dan pemulihan. Anda bertanggung jawab untuk memahami cara kerja kemampuan tersebut dalam semua layanan yang Anda gunakan, dan memilih kemampuan yang Anda butuhkan untuk memenuhi tujuan bisnis dan tujuan waktu aktif Anda.

Artikel ini menjelaskan cara membuat Azure Files tahan terhadap berbagai potensi pemadaman dan masalah, termasuk kesalahan sementara, pemadaman zona ketersediaan, dan pemadaman wilayah. Ini juga menjelaskan bagaimana Anda dapat menggunakan cadangan untuk memulihkan dari jenis masalah lain, dan menyoroti beberapa informasi utama tentang perjanjian tingkat layanan (SLA) Azure Files.

Nota

Azure Files adalah bagian dari platform Azure Storage. Beberapa kemampuan Azure Files umum di banyak layanan Azure Storage. Dalam artikel ini, kami menggunakan Azure Storage untuk merujuk ke kemampuan umum ini.

Rekomendasi penyebaran produksi

Untuk mempelajari cara menyebarkan Azure Files untuk mendukung persyaratan keandalan solusi Anda dan bagaimana keandalan memengaruhi aspek lain dari arsitektur Anda, lihat Praktik terbaik arsitektur untuk Azure Files di Azure Well-Architected Framework.

Gambaran umum arsitektur keandalan

Penyimpanan redundan lokal (LRS) mereplikasi data dalam akun penyimpanan Anda ke satu atau beberapa zona ketersediaan Azure yang terletak di wilayah utama pilihan Anda. Meskipun tidak ada opsi untuk memilih zona ketersediaan pilihan Anda, Azure dapat memindahkan atau memperluas akun LRS di seluruh zona untuk meningkatkan penyeimbangan beban. Tidak ada jaminan bahwa data Anda akan tersebar di seluruh zona. Untuk informasi selengkapnya tentang zona ketersediaan, lihat Apa itu Zona Ketersediaan?.

Diagram yang memperlihatkan bagaimana data direplikasi di zona ketersediaan dengan menggunakan LRS.

Penyimpanan zona redundan (ZRS), penyimpanan geo-redundan (GRS), dan penyimpanan geo-zona-redundan (GZRS) memberikan perlindungan ekstra. Artikel ini menjelaskan opsi ini secara rinci.

Azure Files tersedia dalam dua tingkat media:

  • Tingkat Premium menggunakan solid-state drive (SSD) untuk performa tinggi. Tingkat ini direkomendasikan untuk beban kerja yang memerlukan latensi rendah.

  • Tingkat Standar mendukung hard disk drive (HDD). Berbagi file HDD menyediakan opsi penyimpanan hemat biaya untuk berbagi file tujuan umum.

Untuk informasi selengkapnya, lihat Merencanakan untuk menyebarkan Azure Files - Tingkat penyimpanan.

Azure Files menerapkan redundansi di tingkat akun penyimpanan, dan berbagi file mewarisi konfigurasi redundansi tersebut secara otomatis. Layanan ini mendukung beberapa model redundansi yang berbeda dalam pendekatannya terhadap perlindungan data.

Ketahanan terhadap kesalahan sementara

Kesalahan sementara adalah kegagalan yang bersifat sementara dan intermiten dalam komponen. Mereka sering terjadi di lingkungan terdistribusi seperti cloud, dan mereka adalah bagian normal dari operasi. Kesalahan sementara memperbaiki diri setelah waktu yang singkat. Penting bahwa aplikasi Anda dapat menangani kesalahan sementara, biasanya dengan mencoba kembali permintaan yang terpengaruh.

Semua aplikasi yang dihosting cloud harus mengikuti panduan penanganan kesalahan sementara Azure saat berkomunikasi dengan API, database, dan komponen lain yang dihosting cloud. Untuk informasi selengkapnya, lihat Rekomendasi untuk menangani kesalahan sementara.

Untuk mengelola kesalahan sementara secara efektif saat Anda menggunakan Azure Files, konfigurasikan nilai batas waktu yang sesuai untuk operasi file Anda berdasarkan ukuran file dan kondisi jaringan. File yang lebih besar memerlukan batas waktu yang lebih lama, sementara operasi yang lebih kecil dapat menggunakan nilai yang lebih pendek untuk mendeteksi kegagalan dengan cepat.

Untuk memastikan bahwa hanya koneksi aman yang dibuat ke berbagi NFS Anda, kami sarankan Anda mengonfigurasi titik akhir privat untuk akun penyimpanan Anda. Titik akhir privat menggunakan Azure Private Link untuk menetapkan alamat IP statis ke akun penyimpanan Anda dari dalam ruang alamat privat jaringan virtual Anda. Titik akhir privat membantu mencegah gangguan konektivitas dari perubahan alamat IP dinamis. Untuk informasi selengkapnya tentang keamanan untuk berbagi NFS Anda, lihat Berbagi file NFS - Keamanan dan jaringan.

Ketahanan terhadap kegagalan zona ketersediaan

Zona ketersediaan adalah grup pusat data yang terpisah secara fisik dalam wilayah Azure. Ketika satu zona gagal, layanan dapat melakukan failover ke salah satu zona yang tersisa.

Azure Files menyediakan dua jenis dukungan zona ketersediaan:

Persyaratan

  • Dukungan wilayah:

  • Jenis berbagi file:

    • ZRS: ZRS didukung oleh semua jenis berbagi file.

    • LRS dengan penempatan zona: LRS dengan penempatan zona tersedia untuk akun penyimpanan yang memenuhi persyaratan berikut:

      • Harus menggunakan tingkat penyimpanan premium (tingkat media SSD).
      • Berbagi file Azure klasik saja (menggunakan penyedia sumber daya Microsoft.Storage). Penempatan zona saat ini tidak dimungkinkan untuk file share yang dibuat dengan provider sumber daya Microsoft.FileShares (versi pratinjau).

Biaya

Dampak biaya berbeda tergantung pada jenis dukungan zona ketersediaan yang Anda gunakan:

  • ZRS: Saat Anda mengaktifkan penyimpanan redundan zona (ZRS), Anda dikenakan biaya dengan tarif yang berbeda dari penyimpanan redundan lokal (LRS) karena replikasi tambahan dan overhead penyimpanan.

  • LRS dengan penempatan zona: LRS dengan penempatan zona dikenakan tarif yang sama dengan LRS.

Untuk informasi harga terperinci, lihat Harga Azure Files.

Mengonfigurasi dukungan zona ketersediaan

Perilaku ketika semua zona sehat

Bagian ini menjelaskan apa yang diharapkan ketika akun penyimpanan file dikonfigurasi untuk dukungan zona ketersediaan dan semua zona ketersediaan beroperasi.

  • Perutean lalu lintas antar zona:

    • ZRS: Azure Storage dengan penyimpanan zona redundan (ZRS) secara otomatis mendistribusikan permintaan di seluruh kluster penyimpanan di beberapa zona ketersediaan. Distribusi lalu lintas transparan untuk aplikasi dan tidak memerlukan konfigurasi sisi klien.

    • LRS dengan penempatan zona: Azure Storage dengan penyimpanan redundan lokal (LRS) secara otomatis mendistribusikan permintaan di seluruh kluster penyimpanan di zona ketersediaan yang Anda pilih. Distribusi lalu lintas transparan untuk aplikasi dan tidak memerlukan konfigurasi sisi klien.

  • Replikasi data antar zona:

    • ZRS: Semua operasi tulis ke ZRS direplikasi secara sinkron di semua zona ketersediaan dalam wilayah tersebut. Saat Anda mengunggah atau mengubah data, operasi tidak dianggap selesai hingga data berhasil direplikasi di semua zona ketersediaan. Replikasi sinkron ini memastikan konsistensi yang kuat dan kehilangan data nol selama kegagalan zona.

    • LRS dengan penempatan zona: Semua operasi tulis ke LRS direplikasi secara sinkron di beberapa replika penyimpanan dalam zona. Saat Anda mengunggah atau mengubah data, operasi tidak dianggap selesai sampai data berhasil direplikasi di semua replika.

Perilaku selama kegagalan zona

Bagian ini menjelaskan apa yang diharapkan ketika akun penyimpanan file dikonfigurasi untuk dukungan zona ketersediaan dan ada pemadaman zona ketersediaan.

  • Deteksi dan respons:

    • ZRS: Microsoft secara otomatis mendeteksi kegagalan zona dan memulai proses pemulihan. Tidak ada tindakan pelanggan yang diperlukan untuk akun penyimpanan zona redundan (ZRS). Jika suatu zona menjadi tidak tersedia, Azure akan melakukan pembaruan jaringan, seperti repointing Sistem Penamaan Domain (DNS).

    • LRS dengan penempatan zona: Anda perlu mendeteksi hilangnya zona ketersediaan. Jika perlu, Anda dapat memulai failover ke file share sekunder yang sudah Anda buat sebelumnya di zona ketersediaan lain.

  • Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat zona tidak berfungsi. Namun, Anda dapat menggunakan Azure Resource Health untuk memantau kesehatan sumber daya individual, dan Anda dapat menyiapkan pemberitahuan Resource Health untuk memberi tahu Anda tentang masalah. Anda juga dapat menggunakan Azure Service Health untuk memahami kesehatan layanan secara keseluruhan, termasuk kegagalan zona apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

  • Permintaan aktif:

    • ZRS: Permintaan dalam penerbangan mungkin dihilangkan selama proses pemulihan dan harus dicoba kembali. Aplikasi harus menerapkan logika coba lagi untuk menangani gangguan sementara ini.

    • LRS dengan penempatan zona: Permintaan dalam penerbangan dihilangkan dan harus dicoba kembali saat zona pulih.

  • Kehilangan data yang diharapkan:

    • ZRS: Tidak ada kehilangan data yang terjadi selama kegagalan zona karena data direplikasi secara sinkron di beberapa zona sebelum operasi tulis selesai.

    • LRS dengan penempatan zona: Data pada berbagi file di zona yang terpengaruh tidak tersedia hingga zona pulih.

  • Waktu henti yang diharapkan:

    • ZRS: Sejumlah kecil waktu henti, biasanya, beberapa detik, mungkin terjadi selama pemulihan otomatis karena lalu lintas dialihkan ke zona sehat. Saat Anda merancang aplikasi untuk ZRS, ikuti praktik untuk penanganan kesalahan sementara, termasuk menerapkan kebijakan coba lagi dengan back-off eksponensial.

    • LRS dengan penempatan zona: Berbagi file di zona yang terpengaruh tetap tidak berfungsi hingga zona ketersediaan pulih.

  • Pengalihan lalu lintas:

    • ZRS: Azure secara otomatis mengalihkan lalu lintas ke zona ketersediaan sehat yang tersisa. Layanan ini mempertahankan fungsionalitas penuh dengan menggunakan zona yang masih aktif tanpa memerlukan intervensi pelanggan. Tidak diperlukan pemasangan ulang berbagi file Azure dari klien yang terhubung.

    • LRS dengan penempatan zona: Anda bertanggung jawab untuk beralih ke akun penyimpanan file lain di zona sehat, jika diperlukan.

Pemulihan zona

Perilaku pemulihan zona tergantung pada jenis replikasi yang digunakan akun penyimpanan file:

  • ZRS: Saat zona ketersediaan yang gagal pulih, Azure Storage secara otomatis memulihkan operasi normal di semua zona ketersediaan. Layanan ini secara otomatis memastikan konsistensi data dengan menyinkronkan operasi apa pun yang terjadi selama periode pemadaman.

  • LRS dengan penempatan zonal: Setelah zona kembali berfungsi normal, berbagi file di zona tersebut tersedia kembali. Anda bertanggung jawab atas prosedur pemulihan zona dan sinkronisasi data apa pun yang diperlukan beban kerja Anda.

Uji kegagalan zona

Opsi pengujian zona-bawah bergantung pada jenis replikasi yang dipakai oleh akun penyimpanan berkas tersebut.

  • ZRS: Saat Anda menggunakan penyimpanan redundan zona (ZRS), Azure Storage mengelola replikasi, perutean lalu lintas, dan respons zona mati secara otomatis. Karena fitur ini dikelola sepenuhnya, Anda tidak perlu memulai atau memvalidasi proses kegagalan zona ketersediaan.

  • LRS dengan penempatan zona: Tidak ada cara untuk mensimulasikan pemadaman zona ketersediaan yang berisi akun penyimpanan file Anda. Namun, Anda dapat mengonfigurasi aplikasi upstream, firewall, gateway, atau load balancer secara manual untuk mengalihkan lalu lintas ke akun penyimpanan file yang berbeda di zona ketersediaan yang berbeda.

Ketahanan terhadap kegagalan di seluruh wilayah

Azure Storage, termasuk Azure Blob Storage, Azure Files, Azure Table Storage, dan Azure Queue Storage, menyediakan berbagai kemampuan geo-redundansi dan failover agar sesuai dengan persyaratan yang berbeda.

Penting

Penyimpanan geo-redundan (GRS) hanya berfungsi dalam wilayah berpasangan Azure. Jika wilayah akun penyimpanan Anda tidak dipasangkan, pertimbangkan menggunakan solusi multi-wilayah kustom untuk ketahanan.

Penyimpanan geo-reduntansi untuk wilayah yang dipadukan

Azure Storage menyediakan beberapa jenis GRS di wilayah berpasangan. Jenis GRS mana pun yang Anda gunakan, data di wilayah sekunder selalu direplikasi dengan menggunakan penyimpanan redundan lokal (LRS). Pendekatan ini memberikan perlindungan terhadap kegagalan perangkat keras di wilayah sekunder.

Penting

Azure Files hanya mendukung geo-redundansi (GRS atau GZRS) untuk berbagi file standar (HDD).

Azure Files tidak mendukung penyimpanan geo-redundan dengan akses baca (RA-GRS) atau penyimpanan geo-zona-redundan dengan akses baca (RA-GZRS). Jika akun penyimpanan dikonfigurasi untuk menggunakan RA-GRS atau RA-GZRS, berbagi file standar (HDD) akan ditagih sebagai GRS atau GZRS.

Jenis failover

Azure Storage mendukung tiga jenis failover untuk skenario yang berbeda.

  • Failover yang tidak direncanakan yang dikelola pelanggan: Anda bertanggung jawab untuk memulai pemulihan jika ada kegagalan penyimpanan di seluruh wilayah di wilayah utama Anda.

  • Failover terencana yang dikelola pelanggan: Anda bertanggung jawab untuk memulai pemulihan jika bagian lain dari solusi Anda mengalami kegagalan di wilayah utama Anda, dan Anda perlu mengalihkan seluruh solusi Anda ke wilayah sekunder. Gunakan failover yang direncanakan ketika penyimpanan tetap beroperasi di wilayah utama, tetapi Anda perlu mengalihkan seluruh solusi Anda ke wilayah sekunder, seperti untuk latihan pemulihan bencana yang dirancang untuk memastikan persyaratan kepatuhan dan audit.

  • Failover yang dikelola Microsoft: Dalam keadaan luar biasa, Microsoft mungkin memulai failover untuk semua akun penyimpanan geo-redundan (GRS) di suatu wilayah. Namun, failover yang dikelola Microsoft adalah upaya terakhir dan diharapkan hanya dilakukan setelah periode pemadaman yang diperpanjang. Anda tidak boleh mengandalkan failover yang dikelola Microsoft.

Akun GRS dapat menggunakan salah satu jenis failover ini. Anda tidak perlu mengonfigurasi akun penyimpanan terlebih dahulu untuk menggunakan salah satu jenis failover sebelumnya.

Persyaratan

  • Dukungan wilayah: Konfigurasi geo-redundan Azure Storage menggunakan wilayah berpasangan Azure untuk replikasi wilayah sekunder. Wilayah sekunder secara otomatis ditentukan berdasarkan pilihan wilayah utama Anda dan tidak dapat disesuaikan. Untuk daftar lengkap wilayah berpasangan Azure, lihat Daftar wilayah Azure.

    Jika wilayah akun penyimpanan Anda tidak dipasangkan, pertimbangkan menggunakan solusi multi-wilayah kustom untuk ketahanan.

  • Hanya berbagi file standar: Azure Files hanya mendukung geo-redundansi (GRS atau GZRS) untuk berbagi file standar (HDD). Berbagi file Premium (SSD) harus menggunakan LRS atau ZRS. Jika Anda memiliki file share premium dan ingin mereplikasi data di seluruh wilayah untuk resiliensi yang lebih tinggi, lihat Solusi multi-wilayah kustom untuk resiliensi.

  • GRS dan GZRS saja: Azure Files tidak mendukung penyimpanan geo-redundan akses baca (RA-GRS) atau penyimpanan geo-zona-redundan akses baca (RA-GZRS). Jika akun penyimpanan dikonfigurasi untuk menggunakan RA-GRS atau RA-GZRS, berbagi file standar (HDD) akan ditagih sebagai GRS atau GZRS.

Pertimbangan

Saat Anda menerapkan Azure Files multi-wilayah, pertimbangkan faktor-faktor penting berikut:

  • Latensi replikasi asinkron: Replikasi data ke wilayah sekunder tidak sinkron, yang berarti bahwa ada jeda antara ketika data ditulis ke wilayah utama dan ketika tersedia di wilayah sekunder. Jeda ini dapat mengakibatkan potensi kehilangan data jika kegagalan wilayah utama terjadi sebelum data terbaru direplikasi. Kehilangan data diukur oleh tujuan titik pemulihan (RPO). Anda dapat mengharapkan jeda replikasi kurang dari 15 menit, tetapi kali ini adalah perkiraan dan tidak dijamin.

    Anda dapat memeriksa properti Waktu Sinkronisasi Terakhir untuk memahami berapa banyak data yang mungkin hilang jika akun penyimpanan Anda memiliki failover yang tidak direncanakan.

  • Waktu Sinkronisasi Terakhir: Untuk Azure Files, Waktu Sinkronisasi Terakhir didasarkan pada rekam jepret sistem terbaru di wilayah sekunder.

    Perhitungan Waktu Sinkronisasi Terakhir dapat kehabisan waktu jika ada lebih dari 100 berbagi file di akun penyimpanan. Kami menyarankan agar Anda menyebarkan tidak lebih dari 100 unit berbagi file untuk setiap akun penyimpanan guna menghindari kadaluwarsa waktu.

  • Akses wilayah sekunder: Wilayah sekunder tidak dapat diakses untuk pembacaan hingga failover terjadi.

  • Batasan fitur: Beberapa fitur Azure Files tidak didukung atau memiliki batasan saat Anda menggunakan GRS atau failover yang dikelola pelanggan. Batasan ini mencakup jenis berbagi file tertentu, tingkat akses, dan alat dan operasi manajemen. Tinjau dokumentasi kompatibilitas fitur sebelum Anda menerapkan geo-redundansi.

Biaya

Konfigurasi akun Azure Storage multi-wilayah dikenakan biaya tambahan untuk replikasi dan penyimpanan lintas wilayah di wilayah sekunder. Transfer data antar wilayah Azure dikenakan biaya berdasarkan tarif bandwidth antarwilayah standar.

Untuk informasi harga terperinci, lihat Harga Azure Files.

Mengonfigurasi dukungan multiregional

  • Buat akun penyimpanan geo-redundan baru (GRS). Untuk membuat akun GRS, lihat Membuat akun penyimpanan dan memilih GRS, penyimpanan geo-redundan akses baca (RA-GRS), penyimpanan geo-zona-redundan (GZRS), atau penyimpanan geo-zona redundan akses baca (RA-GZRS) selama pembuatan akun.

  • Aktifkan geo-redundansi pada akun penyimpanan file yang ada. Untuk mengonversi akun penyimpanan file yang sudah ada ke GRS, lihat Mengubah konfigurasi redundansi untuk Azure Files.

    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 wilayah sekunder baru.

    Untuk menghindari kehilangan data utama, periksa nilai properti Waktu Sinkronisasi Terakhir sebelum Anda memulai failover yang tidak direncanakan. Untuk mengevaluasi potensi kehilangan data, bandingkan waktu sinkronisasi terakhir dengan terakhir kali data ditulis ke wilayah utama baru.

  • Nonaktifkan geo-redundansi. Konversi akun GRS kembali ke konfigurasi wilayah tunggal (LRS atau ZRS) melalui proses perubahan konfigurasi redundansi yang sama.

Perilaku ketika semua wilayah sehat

Bagian ini menjelaskan apa yang diharapkan ketika akun penyimpanan dikonfigurasi untuk geo-redundansi dan semua wilayah beroperasi.

  • Perutean lalu lintas antar wilayah: Azure Files menggunakan pendekatan pasif aktif di mana semua operasi baca dan tulis diarahkan ke wilayah utama.

  • Replikasi data antar wilayah: Operasi tulis pertama kali diterapkan ke wilayah utama dengan menggunakan jenis redundansi yang dikonfigurasi (LRS untuk GRS, atau ZRS untuk GZRS). Setelah berhasil diselesaikan di wilayah utama, data direplikasi secara asinkron ke wilayah sekunder, tempat data disimpan dengan menggunakan LRS.

    Sifat asinkron dari replikasi lintas wilayah berarti bahwa biasanya ada waktu jeda antara saat data ditulis ke wilayah utama dan kapan tersedia di wilayah sekunder. Anda dapat memantau waktu replikasi dengan menggunakan properti Waktu Sinkronisasi Terakhir.

Perilaku selama kegagalan wilayah

Bagian ini menjelaskan apa yang diharapkan ketika akun penyimpanan dikonfigurasi untuk geo-redundansi dan ada pemadaman di wilayah utama.

  • Failover yang dikelola pelanggan (tidak direncanakan): Gunakan failover yang tidak direncanakan saat penyimpanan di wilayah utama tidak tersedia.

    • Deteksi dan respons: Dalam kejadian yang tidak terduga di mana akun penyimpanan Anda tidak tersedia di wilayah utama Anda, Anda dapat mempertimbangkan untuk memulai failover yang dikelola pelanggan tanpa perencanaan. Untuk membuat keputusan ini, pertimbangkan faktor-faktor berikut:

      • Apakah Azure Resource Health menunjukkan masalah saat mengakses akun penyimpanan di wilayah utama Anda

      • Apakah Microsoft menyarankan Anda untuk melakukan failover ke wilayah lain

      Peringatan

      Failover yang tidak direncanakan dapat mengakibatkan hilangnya data. Sebelum Anda memulai failover yang dikelola pelanggan, putuskan apakah pemulihan layanan membenarkan risiko kehilangan data.

    • Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat suatu wilayah tidak berfungsi. Namun:

    • Permintaan aktif: Selama proses failover, titik akhir akun penyimpanan primer dan sekunder menjadi tidak tersedia untuk baca dan tulis untuk sementara waktu. Setiap permintaan aktif mungkin dihilangkan, dan aplikasi klien perlu mencoba kembali setelah failover selesai.

    • Kehilangan data yang diharapkan: Kehilangan data umum terjadi selama failover yang tidak direncanakan karena lag replikasi asinkron, yang berarti bahwa penulisan terbaru mungkin tidak direplikasi. Anda dapat memeriksa properti Waktu Sinkronisasi Terakhir untuk memahami berapa banyak data yang mungkin hilang selama failover yang tidak direncanakan. Kehilangan data yang diharapkan sering disebut sebagai tujuan titik pemulihan (RPO). Anda umumnya dapat mengharapkan RPO kurang dari 15 menit, meskipun waktu tersebut tidak dapat dijamin.

    • Waktu henti yang diharapkan: Jumlah waktu henti yang diharapkan sering disebut sebagai tujuan waktu pemulihan (RTO). Failover yang dikelola pelanggan biasanya selesai dalam waktu 60 menit, tergantung pada ukuran dan kompleksitas akun.

    • Pengalihan lalu lintas: Saat failover selesai, Azure secara otomatis memperbarui titik akhir akun penyimpanan sehingga aplikasi tidak perlu dikonfigurasi ulang. Jika aplikasi Anda menyimpan entri Sistem Nama Domain (DNS) yang di-cache, mungkin perlu untuk menghapus cache untuk memastikan bahwa aplikasi mengirim lalu lintas ke wilayah utama baru.

    • Konfigurasi pasca-failover: Setelah failover yang tidak direncanakan selesai, akun penyimpanan Anda di wilayah tujuan menggunakan tingkat penyimpanan redundan lokal (LRS). Jika Anda perlu mereplikasinya secara geografis lagi, Anda perlu mengaktifkan kembali penyimpanan geo-redundan (GRS) dan menunggu data direplikasi ke wilayah sekunder baru.

    Untuk informasi selengkapnya tentang cara memulai failover yang dikelola pelanggan, lihat Cara kerja failover yang dikelola pelanggan (tidak direncanakan) dan Memulai failover akun penyimpanan.

  • Failover yang dikelola pelanggan (direncanakan): Gunakan failover yang direncanakan ketika penyimpanan tetap beroperasi di wilayah utama, tetapi Anda perlu mengalihkan seluruh solusi Anda ke wilayah sekunder karena alasan lain. Misalnya, layanan Azure lain mungkin mengalami masalah dan Anda perlu beralih menggunakan wilayah sekunder untuk seluruh solusi Anda. Atau Anda dapat menggunakan failover yang direncanakan untuk melakukan latihan pemulihan bencana (DR) untuk tujuan kepatuhan dan audit.

    • Deteksi dan respons: Anda bertanggung jawab untuk memutuskan melakukan fail-over. Anda biasanya membuat keputusan ini jika Anda perlu melakukan failover antar wilayah, meskipun akun penyimpanan Anda sehat. Misalnya, Anda mungkin memicu failover ketika ada pemadaman besar komponen aplikasi lain yang tidak dapat Anda pulihkan di wilayah utama.

      • Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat suatu wilayah tidak berfungsi. Namun:

    • Permintaan aktif: Selama proses failover, titik akhir akun penyimpanan primer dan sekunder menjadi tidak tersedia untuk baca dan tulis untuk sementara waktu. Setiap permintaan aktif mungkin dihilangkan, dan aplikasi klien perlu mencoba kembali setelah failover selesai.

    • Kehilangan data yang diharapkan: Tidak ada kehilangan data yang diharapkan karena proses failover selesai hanya setelah semua data disinkronkan, yang menghasilkan RPO nol.

    • Waktu henti yang diharapkan: Failover biasanya selesai dalam waktu 60 menit, yang berarti bahwa RTO yang diharapkan adalah 60 menit, tergantung pada ukuran dan kompleksitas akun. Selama proses failover, titik akhir akun penyimpanan primer dan sekunder menjadi tidak tersedia untuk baca dan tulis untuk sementara waktu.

    • Pengalihan lalu lintas: Saat failover selesai, Azure secara otomatis memperbarui titik akhir akun penyimpanan sehingga aplikasi tidak perlu dikonfigurasi ulang. Jika aplikasi Anda menyimpan entri DNS yang di-cache, mungkin perlu untuk menghapus cache untuk memastikan bahwa aplikasi mengirim lalu lintas ke wilayah utama baru.

    • Konfigurasi pasca-failover: Setelah failover yang direncanakan selesai, akun penyimpanan Anda di wilayah tujuan terus direplikasi secara geografis dan tetap berada di tingkat GRS.

    Untuk informasi selengkapnya tentang cara memulai failover yang dikelola pelanggan, lihat Cara kerja failover yang dikelola pelanggan (terencana) dan Memulai failover akun penyimpanan.

  • Failover yang dikelola Microsoft: Jika terjadi bencana besar yang jarang terjadi di mana Microsoft menentukan bahwa wilayah utama tidak dapat dipulihkan secara permanen, failover otomatis ke wilayah sekunder mungkin dimulai. Microsoft menangani seluruh proses dan tidak ada tindakan pelanggan yang diperlukan. Jumlah waktu yang berlalu sebelum failover terjadi tergantung pada tingkat keparahan bencana dan waktu yang diperlukan untuk menilai situasi.

    • Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat suatu wilayah tidak berfungsi. Namun:

    Penting

    Gunakan opsi failover yang dikelola pelanggan untuk mengembangkan, menguji, dan mengimplementasikan rencana DR Anda. Jangan mengandalkan failover yang dikelola Microsoft, yang mungkin hanya digunakan dalam keadaan ekstrem. Failover yang dikelola Microsoft kemungkinan dimulai untuk seluruh wilayah. Ini tidak dapat dimulai untuk akun penyimpanan individu, langganan, atau pelanggan. Failover mungkin terjadi pada waktu yang berbeda untuk layanan Azure yang berbeda. Kami menyarankan agar Anda menggunakan failover yang dikelola pelanggan.

Pemulihan wilayah

Proses failback berbeda secara signifikan antara skenario failover yang dikelola Microsoft dan dikelola pelanggan.

  • Failover yang dikelola pelanggan (tidak direncanakan): Setelah failover yang tidak direncanakan, akun penyimpanan dikonfigurasi dengan penyimpanan redundan lokal (LRS). Untuk melakukan failback, Anda perlu membuat ulang hubungan penyimpanan geo-redundan (GRS) dan menunggu data direplikasi.

  • Failover yang dikelola pelanggan (direncanakan): Setelah failover yang direncanakan, akun penyimpanan tetap direplikasi secara geografis. Anda dapat memulai failover lain yang dikelola pelanggan untuk melakukan failback ke wilayah utama asli. Pertimbangan failover yang sama berlaku.

  • Failover yang dikelola Microsoft: Jika Microsoft memulai failover, kemungkinan bencana signifikan terjadi di wilayah utama, dan wilayah utama mungkin tidak dapat dipulihkan. Setiap garis waktu atau rencana pemulihan tergantung pada sejauh mana upaya bencana dan pemulihan regional. Anda harus memantau komunikasi Azure Service Health untuk detailnya.

Pengujian untuk mendeteksi kegagalan wilayah

Untuk akun GRS, Anda dapat melakukan operasi failover terjadwal selama jendela pemeliharaan untuk menguji proses failover dan failback secara menyeluruh. Failover yang direncanakan tidak memerlukan kehilangan data, tetapi memerlukan waktu henti selama failover dan failback.

Solusi multi-wilayah kustom untuk ketahanan

Kemampuan failover lintas wilayah Azure Storage mungkin tidak cocok karena alasan berikut:

  • Akun penyimpanan Anda berada di wilayah yang tidak berpasangan.

  • Tujuan waktu aktif bisnis Anda tidak terpenuhi oleh waktu pemulihan atau kehilangan data yang disediakan opsi failover bawaan.

  • Anda perlu melakukan failover ke wilayah yang bukan pasangan wilayah utama Anda.

  • Anda memerlukan konfigurasi aktif/aktif di seluruh wilayah.

  • Anda menggunakan jenis berbagi file yang tidak mendukung geo-redundansi.

Bagian ini memberikan gambaran umum tingkat tinggi tentang beberapa pendekatan yang perlu dipertimbangkan. Gambaran umum komprehensif topologi penyebaran multi-wilayah untuk Azure Storage berada di luar cakupan artikel ini.

Pertimbangkan pendekatan tingkat tinggi umum berikut:

  • Beberapa akun penyimpanan: Azure Files dapat disebarkan di beberapa wilayah dengan menggunakan akun penyimpanan terpisah di setiap wilayah. Pendekatan ini memberikan fleksibilitas dalam pemilihan wilayah, kemampuan untuk menggunakan wilayah yang tidak berpasangan, dan kontrol yang lebih terperinci atas waktu replikasi dan konsistensi data. Saat menerapkan beberapa akun penyimpanan di seluruh wilayah, Anda perlu mengonfigurasi replikasi data lintas wilayah, menerapkan kebijakan penyeimbangan beban dan failover, dan memastikan konsistensi data di seluruh wilayah.

  • Replikasi tingkat aplikasi: Terapkan logika replikasi kustom dengan menggunakan Azure Data Factory atau AzCopy untuk menyinkronkan data antar berbagi file di berbagai wilayah. Pendekatan ini memerlukan mekanisme pengembangan kustom dan resolusi konflik.

  • Gunakan Azure File Sync untuk mereplikasi file ke berbagi file di wilayah Azure lain. Anda dapat menggunakan Azure File Sync untuk menyinkronkan antara berbagi file Azure SMB (titik akhir cloud), server file Windows lokal, dan berbagi file yang dipasang yang berjalan pada komputer virtual (VM) di wilayah Azure lain ( titik akhir server DR).

    Pendekatan ini mengharuskan Anda untuk menggunakan beberapa file share dan mesin virtual (VM) untuk mengoordinasikan proses sinkronisasi.

    Jika Anda menggunakan pendekatan ini untuk replikasi file multi-wilayah:

    • Nonaktifkan penjenjangan cloud untuk memastikan bahwa semua data ada secara lokal di server file.

    • Memprovisikan penyimpanan yang cukup di Azure VM untuk menahan seluruh himpunan data.

    • Akses dan ubah file di titik akhir server, dan bukan di Azure, untuk memastikan bahwa perubahan mereplikasi dengan cepat ke wilayah sekunder.

Pencadangan dan pemulihan

Pencadangan Azure Files adalah integrasi asli antara Azure Files dan Azure Backup yang dirancang untuk melindungi data dari penghapusan, kerusakan, dan serangan ransomware yang tidak disengaja.

Pencadangan Azure Files membuat rekam jepret tingkat berbagi yang disimpan dalam akun penyimpanan yang sama. Kemampuan ini memungkinkan pemulihan cepat untuk file-file individual dan seluruh file share. Anda juga dapat menggunakan kebijakan pencadangan untuk memberikan periode retensi yang panjang dengan frekuensi pencadangan yang dapat disesuaikan.

Anda dapat membuat rekam jepret dan menyimpannya dengan dua cara berbeda:

  • Penyimpanan tingkat berbagi: Untuk skenario pemulihan operasional dan jangka pendek, Anda dapat membuat rekam jepret tingkat berbagi dan menyimpannya dalam akun penyimpanan yang sama. Rekam jepret tingkat berbagi memungkinkan pemulihan cepat file individual atau seluruh berbagi file ke lokasi asli atau alternatif.

  • Penyimpanan cadangan vault: Dengan menggunakan cadangan vault, Anda dapat menyalin rekam jepret harian Anda ke vault Azure Recovery Services. Untuk meningkatkan keamanan, brankas ini diisolasi dan dipisahkan secara fisik dari akun penyimpanan utama.

    Saat Anda menggunakan wilayah Azure yang telah dipasangkan dan mengonfigurasi vault untuk menggunakan GRS, data dalam vault direplikasi ke wilayah pasangan tersebut. Replikasi ini mendukung pemulihan lintas wilayah dan alur kerja DR.

Perjanjian tingkat layanan

Perjanjian tingkat layanan (SLA) untuk Azure Storage menjelaskan ketersediaan layanan yang diharapkan dan kondisi yang harus dipenuhi untuk mencapai harapan ketersediaan tersebut. SLA ketersediaan yang memenuhi syarat untuk Anda bergantung pada tingkat penyimpanan dan jenis replikasi yang Anda gunakan. Untuk informasi selengkapnya, lihat SLA untuk Layanan Online.

Konten terkait

  • Last updated on