Rencanakan untuk menyebarkan Azure Files
Anda dapat menyebarkan Azure Files dengan dua cara utama: dengan langsung memasang berbagi file Azure tanpa server atau dengan menyimpan cache berbagi file Azure secara lokal menggunakan Azure File Sync. Pertimbangan penyebaran akan berbeda berdasarkan opsi mana yang Anda pilih.
Pemasangan langsung dari berbagi file Azure: Karena Azure Files menyediakan akses Server Message Block (SMB) atau Network File System (NFS), Anda dapat memasang berbagi file Azure di tempat atau di cloud menggunakan klien SMB atau NFS standar yang tersedia di OS Anda. Karena berbagi file Azure tanpa server, penyebaran untuk skenario produksi tidak memerlukan pengelolaan server file atau perangkat NAS. Ini berarti Anda tidak perlu menerapkan patch perangkat lunak atau menukar disk fisik.
Men-cache berbagi file Azure di tempat dengan Azure File Sync: Azure File Sync memungkinkan Anda untuk memusatkan pembagian file organisasi Anda di Azure Files, sekaligus menjaga fleksibilitas, performa, dan kompatibilitas server file lokal. Azure File Sync mengubah Server Windows lokal (atau cloud) menjadi cache cepat dari berbagi file Azure SMB Anda.
Artikel ini terutama membahas pertimbangan penyebaran untuk menyebarkan berbagi file Azure untuk secara langsung dipasang oleh klien lokal atau cloud. Untuk merencanakan penyebaran Azure File Syn, lihat Merencanakan penyebaran Azure File Sync.
Protokol yang tersedia
Azure Files menawarkan dua protokol sistem file standar industri untuk memasang berbagi file Azure: protokol Server Message Block (SMB) dan protokol Network File System (NFS), memungkinkan Anda memilih protokol yang paling sesuai untuk beban kerja Anda. Berbagi file Azure tidak mendukung protokol SMB dan NFS pada berbagi file yang sama, meskipun Anda dapat membuat berbagi file SMB dan NFS Azure dalam akun penyimpanan yang sama. NFS 4.1 saat ini hanya didukung dalam jenis akun penyimpanan FileStorage baru (hanya berbagi file premium).
Untuk semua berbagi {i>file
| Fitur | SMB | NFS |
|---|---|---|
| Versi protokol yang didukung | SMB 3.1.1, SMB 3.0, SMB 2.1 | NFS 4.1 |
| OS yang Disarankan |
|
Linux kernel versi 4.3+ |
| Jenjang yang tersedia | Premium, transaksi yang dioptimalkan, panas, dan sejuk | Premium |
| Model tagihan | Kapasitas yang diprovisikan | |
| Titik akhir Zona Azure DNS (pratinjau) | Didukung | Didukung |
| Redundansi | LRS, ZRS, GRS, GZRS | LRS, ZRS |
| Semantik sistem file | Win32 | POSIX |
| Autentikasi | Autentikasi berbasis identitas (Kerberos), autentikasi kunci bersama (NTLMv2) | Autentikasi berbasis {i>host |
| Authorization | Daftar kontrol akses (ACL) gaya-Win32 | Izin ala UNIX |
| Sensitivitas huruf besar/besar | Tidak sensitif huruf besar/kecil, mempertahankan huruf besar/kecil | Peka huruf besar/kecil |
| Menghapus atau mengubah file yang terbuka | Hanya dengan kunci | Ya |
| Berbagi file | Mode berbagi Windows | Manajer kunci jaringan nasihat rentang byte |
| Dukungan tautan keras | Tidak didukung | Didukung |
| Dukungan link simbolik | Tidak didukung | Didukung |
| Dapat diakses internet secara opsional | Ya (hanya SMB 3.0+) | No |
| Mendukung FileREST | Ya | Subset: |
| Kunci rentang byte wajib | Didukung | Tidak didukung |
| Kunci rentang byte penasihat | Tidak didukung | Didukung |
| Atribut yang diperluas/dinamai | Tidak didukung | Tidak didukung |
| Aliran data alternatif | Tidak didukung | T/A |
| Pengidentifikasi objek | Tidak didukung | T/A |
| Ulangi poin | Tidak didukung | T/A |
| File Sparse | Tidak didukung | T/A |
| Kompresi | Tidak didukung | T/A |
| Saluran bernama | Tidak didukung | T/A |
| SMB Direct | Tidak didukung | T/A |
| Sewa Direktori UKM | Tidak didukung | T/A |
| Salinan Bayangan Volume | Tidak didukung | T/A |
| Nama file pendek (8.3 alias ) | Tidak didukung | T/A |
| Layanan server | Tidak didukung | T/A |
| Transaksi sistem file (TxF) | Tidak didukung | T/A |
Konsep pengelolaan
berbagi file Azure disebarkan ke akun penyimpanan, yang merupakan objek tingkat atas yang mewakili gabungan penyimpanan bersama. Kumpulan penyimpanan ini dapat digunakan untuk menyebarkan beberapa file bersama, serta sumber daya penyimpanan lainnya seperti kontainer blob, antrean, atau tabel. Semua sumber daya penyimpanan yang disebarkan ke akun penyimpanan berbagi batas yang berlaku untuk akun penyimpanan tersebut. Untuk batas akun penyimpanan saat ini, lihat skalabilitas Azure Files dan target kinerja.
Ada dua jenis akun penyimpanan utama yang akan Anda gunakan untuk penyebaran Azure Files:
- Akun penyimpanan tujuan umum versi 2 (GPv2): Akun penyimpanan GPv2 memungkinkan Anda menyebarkan berbagi file Azure pada perangkat keras standar/berbasis hard disk (berbasis HDD). Selain menyimpan berbagi file Azure, akun penyimpanan GPv2 dapat menyimpan sumber daya penyimpanan lain seperti kontainer blob, antrean, atau tabel.
- Akun penyimpanan FileStorage:Akun penyimpanan FileStorage memungkinkan Anda menyebarkan berbagi file Azure pada perangkat keras premium/berbasis solid-state disk (berbasis SSD). Akun FileStorage hanya dapat digunakan untuk menyimpan berbagi file Azure; tidak ada sumber daya penyimpanan lain (kontainer blob, antrean, tabel, dll.) yang dapat digunakan di akun FileStorage. Hanya akun FileStorage yang dapat menggunakan berbagi file SMB dan NFS.
Ada beberapa jenis akun penyimpanan lain yang mungkin Anda temui di portal Microsoft Azure, PowerShell, atau CLI. Dua jenis akun penyimpanan, BlockBlobStorage dan BlobStorage, tidak boleh berisi berbagi file Azure. Dua jenis akun penyimpanan lainnya yang mungkin Anda lihat adalah tujuan umum versi 1 (GPv1) dan akun penyimpanan klasik, yang keduanya dapat berisi berbagi file Azure. Meskipun GPv1 dan akun penyimpanan klasik mungkin berisi berbagi file Azure, sebagian besar fitur baru Azure Files hanya tersedia di akun penyimpanan GPv2 dan FileStorage. Oleh karena itu, kami menyarankan untuk hanya menggunakan akun penyimpanan GPv2 dan FileStorage untuk penyebaran baru, dan untuk meningkatkan akun penyimpanan GPv1 dan klasik jika sudah ada di lingkungan Anda.
Saat menyebarkan Azure fle share ke akun penyimpanan, sebaiknya Anda:
Hanya menyebarkan berbagi file Azure ke akun penyimpanan dengan berbagi file Azure lainnya. Meskipun akun penyimpanan GPv2 memungkinkan Anda untuk memiliki akun penyimpanan tujuan campuran, karena sumber daya penyimpanan seperti berbagi file Azure dan kontainer blob berbagi batas akun penyimpanan, pencampuran sumber daya bersama-sama dapat membuat lebih sulit untuk memecahkan masalah performa nanti.
Memperhatikan batasan IOPS akun penyimpanan saat menyebarkan berbagi file Azure. Idealnya, Anda akan memetakan berbagi file 1:1 dengan akun penyimpanan. Namun, ini mungkin tidak selalu dapat dilakukan karena berbagai batasan dan batasan, baik dari organisasi Anda maupun dari Azure. Ketika tidak mungkin hanya memiliki satu berbagi yang digunakan dalam satu akun penyimpanan, pertimbangkan berbagi mana yang akan sangat aktif dan berbagi mana yang akan kurang aktif untuk memastikan bahwa berbagi terpanas tidak dimasukkan ke dalam akun penyimpanan yang sama bersama-sama.
Hanya menyebarkan akun GPv2 dan FileStorage, dan meningkatkan akun penyimpanan GPv1 dan klasik saat Anda menemukannya di lingkungan Anda.
Identitas
Untuk mengakses berbagi file Azure, pengguna berbagi harus diautentikasi dan memiliki otorisasi untuk mengakses berbagi. Hal ini dilakukan berdasarkan identitas pengguna yang mengakses berbagi. Azure Files mendukung metode autentikasi berikut:
- Active Directory Domain Services Lokal (AD DS, atau AD DS lokal): Akun penyimpanan Azure dapat digabungkan dengan domain ke Active Directory Domain Services milik pelanggan, seperti server file Windows Server atau perangkat NAS. Anda dapat menerapkan pengontrol domain secara lokal, di Azure VM, atau bahkan sebagai VM di penyedia cloud lain; Azure Files adalah agnostik tempat pengontrol domain Anda dihosting. Setelah akun penyimpanan bergabung dengan domain, pengguna akhir dapat memasang berbagi dengan akun pengguna tempat mereka masuk ke PC mereka. Autentikasi berbasis AD menggunakan protokol autentikasi Kerberos.
- Microsoft Entra Domain Services: Microsoft Entra Domain Services menyediakan pengendali domain yang dikelola Microsoft yang dapat digunakan untuk sumber daya Azure. Domain yang bergabung dengan akun penyimpanan Anda ke Microsoft Entra Domain Services memberikan manfaat serupa dengan domain yang menggabungkannya ke AD DS milik pelanggan. Opsi penyebaran ini dapat berfungsi maksumal penerapan untuk skenario lift-and-shift aplikasi yang memerlukan izin berbasis AD. Karena Microsoft Entra Domain Services menyediakan autentikasi berbasis AD, opsi ini juga menggunakan protokol autentikasi Kerberos.
- Microsoft Entra Kerberos untuk identitas hibrid: Microsoft Entra Kerberos memungkinkan Anda menggunakan ID Microsoft Entra untuk mengautentikasi identitas pengguna hibrid, yang merupakan identitas AD lokal yang disinkronkan ke cloud. Konfigurasi ini menggunakan ID Microsoft Entra untuk mengeluarkan tiket Kerberos untuk mengakses berbagi file dengan protokol SMB. Ini berarti pengguna akhir Anda dapat mengakses berbagi file Azure melalui internet tanpa memerlukan konektivitas jaringan ke pengontrol domain dari Microsoft Entra hybrid joined dan VM yang bergabung dengan Microsoft Entra.
- Autentikasi Direktori Aktif melalui SMB untuk klien Linux: Azure Files mendukung autentikasi berbasis identitas melalui SMB untuk klien Linux menggunakan protokol autentikasi Kerberos melalui AD DS atau Microsoft Entra Domain Services.
- Kunci akun penyimpanan Azure:Berbagi file Azure juga dapat dipasang dengan kunci akun penyimpanan Azure. Untuk memasang berbagi dengan cara ini, nama akun penyimpanan digunakan sebagai nama pengguna dan kunci akun penyimpanan digunakan sebagai kata sandi. Menggunakan kunci akun penyimpanan untuk memasang berbagi file Azure secara efektif merupakan operasi administrator, karena berbagi file yang dipasang akan memiliki izin penuh untuk semua file dan folder yang dibagikan, bahkan jika mereka memiliki ACL. Saat menggunakan kunci akun penyimpanan yang dipasang melalui SMB, protokol autentikasi NTLMv2 digunakan. Jika Anda ingin menggunakan kunci akun penyimpanan untuk mengakses berbagi file Azure Anda, sebaiknya gunakan titik akhir privat atau titik akhir layanan seperti yang dijelaskan di bagian Jaringan .
Untuk pelanggan yang bermigrasi dari server file lokal, atau membuat berbagi file baru di Azure Files yang dimaksudkan untuk berperilaku seperti server file Windows atau appliance NAS, domain yang bergabung dengan akun penyimpanan Anda ke AD DS milik pelanggan adalah opsi yang direkomendasikan. Untuk mempelajari selengkapnya tentang domain yang bergabung dengan akun penyimpanan Anda ke AD DS milik pelanggan, lihat Gambaran Umum - Active Directory lokal autentikasi Domain Services melalui SMB untuk berbagi file Azure.
Jaringan
Memasang langsung berbagi file Azure Anda sering kali memerlukan pemikiran tentang konfigurasi jaringan karena:
- Port yang digunakan berbagi file SMB untuk komunikasi, port 445, sering diblokir oleh banyak organisasi dan penyedia layanan internet (ISP) untuk lalu lintas keluar (internet).
- Berbagi file NFS mengandalkan autentikasi tingkat jaringan dan oleh karena itu hanya dapat diakses melalui jaringan terbatas. Menggunakan berbagi file NFS selalu memerlukan beberapa tingkat konfigurasi jaringan.
Untuk mengonfigurasi jaringan, Azure Files menyediakan titik akhir publik yang dapat diakses internet dan integrasi dengan fitur jaringan Azure seperti titik akhir layanan, yang membantu membatasi titik akhir publik ke jaringan virtual tertentu, dan titik akhir privat, yang memberi akun penyimpanan Anda alamat IP pribadi dari dalam ruang alamat IP jaringan virtual. Meskipun tidak ada biaya tambahan untuk menggunakan titik akhir publik atau titik akhir layanan, tarif pemrosesan data standar berlaku untuk titik akhir privat.
Ini berarti Anda harus mempertimbangkan konfigurasi jaringan berikut:
- Jika protokol yang diperlukan adalah SMB dan semua akses melalui SMB berasal dari klien di Azure, tidak diperlukan konfigurasi jaringan khusus.
- Jika protokol yang diperlukan adalah SMB dan aksesnya berasal dari klien lokal, maka koneksi VPN atau ExpressRoute dari lokal ke jaringan Azure Anda diperlukan, dengan Azure Files yang diekspos di jaringan internal Anda menggunakan titik akhir privat.
- Jika protokol yang diperlukan adalah NFS, Anda dapat menggunakan titik akhir layanan atau titik akhir privat untuk membatasi jaringan ke jaringan virtual yang ditentukan. Jika Anda memerlukan alamat IP statis dan/atau beban kerja Anda memerlukan ketersediaan tinggi, gunakan titik akhir privat. Dengan titik akhir layanan, peristiwa langka seperti pemadaman zona dapat menyebabkan alamat IP yang mendasar dari akun penyimpanan berubah. Meskipun data masih akan tersedia di berbagi file, klien akan memerlukan remount berbagi.
Untuk mempelajari lebih lanjut tentang cara mengonfigurasi jaringan untuk Azure Files, lihat Pertimbangan jaringan Azure Files.
Selain menghubungkan langsung ke berbagi file menggunakan titik akhir publik atau menggunakan koneksi VPN/ExpressRoute dengan titik akhir privat, SMB menyediakan strategi akses klien tambahan: SMB melalui QUIC. SMB melalui QUIC menawarkan "SMB VPN" tanpa konfigurasi untuk akses SMB melalui protokol transport QUIC. Meskipun Azure Files tidak secara langsung mendukung SMB melalui QUIC, Anda dapat membuat cache ringan dari berbagi file Azure Anda di Windows Server 2022 VM Edisi Azure menggunakan Azure File Sync. Untuk mempelajari opsi ini lebih lanjut, lihat SMB melalui QUIC dengan Azure File Sync.
Enkripsi
Azure Files mendukung dua jenis enkripsi yang berbeda:
- Enkripsi saat transit, yang berkaitan dengan enkripsi yang digunakan saat memasang/mengakses berbagi file Azure
- Enkripsi saat tidak aktif, yang berkaitan dengan bagaimana data dienkripsi saat disimpan di disk
Enkripsi saat transit
Penting
Bagian ini membahas detail enkripsi saat transit untuk berbagi SMB. Untuk detail tentang enkripsi saat transit dengan berbagi NFS, lihat Keamanan dan jaringan.
Secara default, semua akun penyimpanan Azure mengaktifkan enkripsi saat transit. Ini berarti bahwa saat Anda memasang berbagi melalui SMB atau mengaksesnya melalui protokol FileREST (seperti melalui portal Microsoft Azure, PowerShell/CLI, atau Azure SDK), Azure Files hanya akan mengizinkan sambungan jika dibuat dengan SMB 3.x dengan enkripsi atau HTTPS. Klien yang tidak mendukung SMB 3.x atau klien yang mendukung SMB 3.x tetapi tidak enkripsi SMB tidak akan dapat memasang berbagi file Azure jika enkripsi saat transit diaktifkan. Untuk informasi selengkapnya tentang sistem operasi mana yang mendukung SMB 3.x dengan enkripsi, lihat dokumentasi kami untuk Windows, macOS, dan Linux. Semua versi PowerShell, CLI, dan SDK saat ini mendukung HTTPS.
Anda dapat menonaktifkan enkripsi saat transit untuk akun penyimpanan Azure. Saat enkripsi dinonaktifkan, Azure Files juga akan mengizinkan SMB 2.1 dan SMB 3.x tanpa enkripsi, dan panggilan API FileREST yang tidak terenkripsi melalui HTTP. Alasan utama untuk menonaktifkan enkripsi saat transit adalah untuk mendukung aplikasi lama yang harus dijalankan di sistem operasi yang lebih lama, seperti Windows Server 2008 R2 atau distribusi Linux yang lebih lama. Azure Files hanya mengizinkan koneksi SMB 2.1 dalam wilayah Azure yang sama dengan berbagi file Azure; klien SMB 2.1 di luar wilayah Azure dari berbagi file Azure, seperti lokal atau di wilayah Azure yang berbeda, tidak akan dapat mengakses berbagi file.
Sebaiknya Anda memastikan bahwa enkripsi data saat transit diaktifkan.
Untuk informasi selengkapnya tentang enkripsi saat transit, lihat mewajibkan transfer aman di penyimpanan Azure.
Enkripsi saat tidak aktif
Semua data yang disimpan di Azure Files dienkripsi saat tidak digunakan menggunakan enkripsi layanan penyimpanan Azure (SSE). Enkripsi layanan penyimpanan berfungsi mirip dengan BitLocker di Windows: data dienkripsi di bawah tingkat sistem file. Karena data dienkripsi di bawah sistem file berbagi Azure, karena dikodekan ke disk, Anda tidak perlu memiliki akses ke kunci yang mendasari klien untuk membaca atau menulis ke berbagi Azure. Enkripsi saat tidak berlaku untuk protokol SMB dan NFS.
Secara default, data yang disimpan di Azure Files dienkripsi dengan kunci yang dikelola Microsoft. Dengan kunci yang dikelola Microsoft, Microsoft memiliki kunci untuk mengenkripsi/mendekripsi data, dan bertanggung jawab untuk memutarnya secara teratur. Anda juga dapat memilih untuk mengelola kunci Anda sendiri, yang memberi Anda kontrol atas proses rotasi. Jika Anda memilih untuk mengenkripsi berbagi dengan kunci yang dikelola pelanggan, Azure Files diizinkan untuk mengakses kunci Anda untuk memenuhi permintaan baca dan tulis dari klien Anda. Dengan kunci yang dikelola pelanggan, Anda dapat mencabut otorisasi ini sewaktu-waktu, tetapi ini berarti bahwa berbagi Azure Anda tidak akan lagi dapat diakses melalui SMB atau API FileREST.
Azure Files menggunakan skema enkripsi yang sama dengan layanan penyimpanan Azure lainnya seperti penyimpanan Azure Blob. Untuk mempelajari selengkapnya tentang enkripsi layanan penyimpanan Azure (SSE), lihat Enkripsi penyimpanan Azure untuk data tidak aktif.
Perlindungan data
Azure Files memiliki pendekatan berlapis untuk memastikan data Anda dicadangkan, dipulihkan, dan dilindungi dari ancaman keamanan. Lihat Gambaran umum perlindungan data Azure Files.
Penghapusan sementara
Penghapusan sementara adalah pengaturan tingkat akun penyimpanan yang memungkinkan Anda memulihkan berbagi file saat dihapus secara tidak sengaja. Jika dihapus, berbagi akan dialihkan ke status dihapus sementara, bulan dihapus permanen. Anda dapat mengonfigurasi jumlah waktu berbagi yang dihapus sementara dapat dipulihkan sebelum dihapus secara permanen, dan membatalkan penghapusan berbagi kapan saja selama periode retensi ini.
Penghapusan sementara diaktifkan secara default untuk akun penyimpanan baru. Jika Anda memiliki alur kerja di mana penghapusan berbagi umum dan diharapkan, Anda mungkin memutuskan untuk memiliki periode retensi singkat atau tidak mengaktifkan penghapusan sementara sama sekali.
Untuk informasi selengkapnya tentang penghapusan sementara, lihat Mencegah penghapusan data yang tidak disengaja.
Cadangan
Anda dapat mencadangkan berbagi file Azure melalui rekam jepret yang dibagikan, yang merupakan salinan baca-saja, titik waktu tertentu berbagi Anda. Rekam jepret bersifat bertahap, artinya hanya berisi data sebanyak yang telah berubah sejak rekam jepret sebelumnya. Anda dapat memiliki hingga 200 rekam repret per berbagi dan menyimpannya hingga 10 tahun. Anda dapat mengambil rekam jepret secara manual di portal Azure, melalui PowerShell, atau antarmuka baris perintah (CLI), atau Anda dapat menggunakan Azure Backup.
Azure Backup untuk berbagi file Azure menangani penjadwalan dan penyimpanan rekam jepret. Kemampuan Grandfather-Father-Son (GFS) berarti Anda dapat mengambil rekam jepret harian, mingguan, bulanan, dan tahunan, masing-masing dengan periode retensinya sendiri. Azure Backup juga mengatur pengaktifkanan penghapusan sementara dan mengambil kunci penghapusan pada akun penyimpanan segera setelah berbagi apa pun di dalamnya dikonfigurasi untuk cadangan. Terakhir, Azure Backup menyediakan kemampuan pemantauan dan pemberitahuan utama tertentu yang memungkinkan pelanggan memiliki tampilan konsolidasi dari keadaan cadangan mereka.
Anda dapat melakukan pemulihan tingkat item dan tingkat berbagi di portal Azure menggunakan Azure Backup. Yang perlu Anda lakukan adalah memilih titik pemulihan (rekam jepret tertentu), file atau direktori tertentu jika relevan, dan kemudian lokasi (awal atau alternatif) tempat tujuan Anda memulihkan file atau direktori. Layanan cadangan menangani penyalinan data rekam jepret dan menunjukkan kemajuan pemulihan Anda di portal.
Lindungi Azure Files dengan Microsoft Defender untuk Storage
Pertahanan Microsoft untuk Penyimpanan adalah lapisan kecerdasan keamanan asli Azure yang mendeteksi potensi ancaman terhadap akun penyimpanan Anda. Ini memberikan keamanan komprehensif dengan menganalisis data plane dan telemetri sarana kontrol yang dihasilkan oleh Azure Files. Ini menggunakan kemampuan deteksi ancaman tingkat lanjut yang didukung oleh Microsoft Threat Intelligence untuk memberikan pemberitahuan keamanan kontekstual, termasuk langkah-langkah untuk mengurangi ancaman yang terdeteksi dan mencegah serangan di masa mendatang.
Defender for Storage terus menganalisis aliran telemetri yang dihasilkan oleh Azure Files. Peringatan keamanan akan timbul ketika aktivitas yang berpotensi berbahaya terdeteksi. Pemberitahuan ini ditampilkan dalam Microsoft Defender untuk Cloud, bersama dengan detail aktivitas mencurigakan, langkah investigasi, tindakan remediasi, dan rekomendasi keamanan.
Defender for Storage mendeteksi malware yang diketahui, seperti ransomware, virus, spyware, dan malware lainnya yang diunggah ke akun penyimpanan berdasarkan hash file lengkap (hanya didukung untuk REST API). Ini membantu mencegah malware memasuki organisasi dan menyebar ke lebih banyak pengguna dan sumber daya. Lihat Memahami perbedaan antara Pemindaian Malware dan analisis reputasi hash.
Defender for Storage tidak mengakses data akun penyimpanan dan tidak memengaruhi performanya. Anda dapat mengaktifkan Pertahanan Microsoft untuk Penyimpanan di tingkat langganan (disarankan) atau tingkat sumber daya.
Tingkat penyimpanan
Azure Files menawarkan dua tingkat penyimpanan media yang berbeda, SSD (disk solid-state) dan HDD (hard disk drive), yang memungkinkan Anda menyesuaikan berbagi Anda dengan persyaratan performa dan harga skenario Anda:
SSD (premium): Berbagi file SSD memberikan performa tinggi yang konsisten dan latensi rendah, dalam milidetik satu digit untuk sebagian besar operasi IO, untuk beban kerja intensif IO. Berbagi file SSD cocok untuk berbagai beban kerja seperti database, hosting situs web, dan lingkungan pengembangan. Berbagi file SSD dapat digunakan dengan protokol Server Message Block (SMB) dan Network File System (NFS). Berbagi file SSD tersedia dalam model penagihan v1 yang disediakan. Berbagi file SSD menawarkan ketersediaan SLA yang lebih tinggi daripada berbagi file HDD (lihat "Tingkat Premium Azure Files").
HDD (standar): Berbagi file HDD menyediakan opsi penyimpanan hemat biaya untuk berbagi file tujuan umum. Berbagi file HDD tersedia dengan model penagihan v2 dan bayar sesuai penggunaan yang disediakan, meskipun kami merekomendasikan model v2 yang disediakan untuk penyebaran berbagi file baru. Untuk informasi tentang SLA, lihat halaman perjanjian tingkat layanan Azure (lihat "Akun Penyimpanan").
Saat memilih tingkat media untuk beban kerja Anda, pertimbangkan persyaratan performa dan penggunaan Anda. Jika beban kerja Anda memerlukan latensi satu digit, atau Anda menggunakan media penyimpanan SSD lokal, tingkat berbagi file SSD mungkin paling cocok. Jika latensi rendah tidak terlalu menjadi perhatian, misalnya dengan berbagi tim yang dipasang secara lokal dari Azure atau cache lokal menggunakan Azure File Sync, berbagi file HDD mungkin lebih cocok dari perspektif biaya.
Setelah membuat berbagi file di akun penyimpanan, Anda tidak dapat langsung memindahkannya ke tingkat media yang berbeda. Misalnya, untuk memindahkan berbagi file HDD ke tingkat media SSD, Anda harus membuat berbagi file SSD baru dan menyalin data dari berbagi asli Anda ke berbagi file baru di akun FileStorage. Sebaiknya gunakan AzCopy untuk menyalin data antara berbagi file Azure, tetapi Anda juga dapat menggunakan alat seperti robocopy di Windows atau rsync untuk macOS dan Linux.
Lihat Memahami tagihan Azure Files untuk informasi selengkapnya.
Redundansi geografis
Untuk melindungi data dalam berbagi file Azure Anda dari kehilangan atau kerusakan data, Azure Files menyimpan beberapa salinan setiap file saat ditulis. Tergantung pada kebutuhan Anda, Anda dapat memilih tingkat redundansi yang berbeda. Azure Files saat ini mendukung opsi redundansi data berikut:
- Penyimpanan yang redundan secara lokal (LRS): Dengan LRS, setiap file disimpan dalam tiga rangkap dalam kluster penyimpanan Azure. Ini melindungi dari kehilangan data karena kesalahan perangkat keras, seperti drive disk yang buruk. Namun, jika bencana seperti kebakaran atau banjir terjadi di dalam pusat data, semua replika akun penyimpanan yang menggunakan LRS mungkin hilang atau tidak dapat dipulihkan.
- Penyimpanan zona redundan (ZRS): Dengan ZRS, tiga salinan setiap file disimpan. Namun, salinan ini secara fisik diisolasi dalam tiga kluster penyimpanan yang berbeda di zona ketersediaan Azure yang berbeda. Zona Ketersediaan adalah lokasi fisik yang unik dalam wilayah Azure. Setiap zona terbuat dari satu atau beberapa pusat data yang dilengkapi dengan daya, pendinginan, dan jaringan yang independen. Penulisan ke penyimpanan tidak diterima sampai ditulis ke kluster penyimpanan di ketiga zona ketersediaan.
- Penyimpanan geo-redundan (GRS): Dengan GRS, Anda memiliki dua wilayah, wilayah utama dan wilayah sekunder. File disimpan dalam tiga rangkap dalam kluster penyimpanan Azure di wilayah primer. Penulisan akan direplikasi secara asinkron ke wilayah sekunder yang ditentukan oleh Microsoft. GRS menyediakan enam salinan data Anda yang tersebar di antara dua wilayah Azure. Jika terjadi bencana besar seperti hilangnya wilayah Azure secara permanen karena bencana alam atau peristiwa serupa lainnya, Microsoft akan melakukan failover. Dalam hal ini, sekunder menjadi yang utama, melayani semua operasi. Karena replikasi antara wilayah primer dan sekunder tidak sinkron, jika terjadi bencana besar, data yang belum direplikasi ke wilayah sekunder akan hilang. Anda juga dapat melakukan failover manual akun penyimpanan berlebihan secara geografis.
- Penyimpanan geo-zona-redundan (GZRS): Anda dapat menganggap GZRS sebagai ZRS, tetapi dengan geo-redundansi. Dengan GZRS, file akan disimpan dalam tiga rangkap di tiga kluster penyimpanan berbeda di wilayah utama. Semua tulisan kemudian ditiru secara asinkron ke wilayah sekunder yang ditentukan Microsoft. Proses failover untuk GZRS bekerja sama dengan GRS.
Berbagi file Azure standar hingga 5 TiB mendukung keempat jenis redundansi. Berbagi file standar yang lebih besar dari 5 TiB hanya mendukung LRS dan ZRS. Berbagi file Azure premium hanya mendukung LRS dan ZRS.
Akun penyimpanan tujuan umum versi 2 (GPv2) menyediakan dua opsi redundansi lain yang tidak didukung Azure Files: membaca penyimpanan geo-redundan yang dapat diakses (RA-GRS) dan membaca penyimpanan geo-zona-redundan yang dapat diakses (RA-GZRS). Anda dapat memprovisikan berbagi file Azure di akun penyimpanan dengan kumpulan opsi ini, namun Azure Files tidak mendukung pembacaan dari wilayah sekunder. Berbagi file Azure yang disebarkan ke akun penyimpanan RA-GRS atau RA-GZRS masing-masing ditagih sebagai GRS atau GZRS.
Untuk informasi selengkapnya tentang redundansi, lihat Redundansi data Azure Files.
Ketersediaan ZRS standar
ZRS untuk akun penyimpanan v2 tujuan umum standar tersedia untuk subset wilayah Azure.
Premium ketersediaan ZRS
ZRS untuk berbagi file premium tersedia untuk subset wilayah Azure.
Ketersediaan GZRS standar
GZRS tersedia untuk subset wilayah Azure.
Pemulihan bencana dan failover
Dalam kasus pemadaman layanan regional yang tidak diencana, Anda harus memiliki rencana pemulihan bencana (DR) untuk berbagi file Azure Anda. Untuk memahami konsep dan proses yang terlibat dengan DR dan failover akun penyimpanan, lihat Pemulihan bencana dan failover untuk Azure Files.
Migration
Dalam banyak kasus, Anda tidak akan membuat berbagi file baru bersih untuk organisasi Anda, tetapi sebaliknya memigrasikan berbagi file yang ada dari server file lokal atau perangkat NAS ke Azure Files. Memilih strategi dan alat migrasi yang tepat untuk skenario Anda penting untuk keberhasilan migrasi.
Artikel ringkasan migrasi secara singkat membahas dasar-dasar dan berisi tabel yang mengarahkan Anda ke panduan migrasi yang kemungkinan mencakup skenario Anda.