Tanya jawab umum (FAQ) tentang Azure Files

  • Artikel

Azure Files menawarkan berbagi file yang dikelola sepenuhnya di cloud yang dapat diakses melalui protokol Server Message Block (SMB) standar industri dan protokol Network File System (NFS). Anda dapat memasang berbagi file Azure secara bersamaan di cloud atau penyebaran Windows, Linux, dan macOS lokal. Anda juga dapat menyimpan berbagi file Azure dalam cache di mesin Windows Server dengan menggunakan Azure File Sync untuk akses cepat yang dekat dengan tempat data digunakan.

Azure File Sync

  • Bisakah saya memiliki server yang bergabung dengan domain dan non-domain dalam grup sinkronisasi yang sama?
    Ya. Grup sinkronisasi dapat berisi titik akhir server yang memiliki keanggotaan Direktori Aktif yang berbeda, meskipun tidak bergabung dengan domain. Meskipun konfigurasi ini secara teknis berfungsi, kami tidak merekomendasikan ini sebagai konfigurasi umum karena daftar kontrol akses (ACL) yang didefinisikan untuk file dan folder di satu server mungkin tidak dapat diberlakukan oleh server lain dalam grup sinkronisasi. Untuk hasil terbaik, sebaiknya sinkronkan antara server yang berada di forest Direktori Aktif yang sama, antara server yang berada di forest Direktori Aktif yang berbeda tetapi telah menjalin hubungan kepercayaan, atau antar server yang tidak berada di domain. Sebaiknya hindari penggunaan campuran konfigurasi ini.

  • Saya membuat file langsung di berbagi file Azure saya menggunakan SMB atau di portal. Berapa lama waktu yang dibutuhkan file untuk disinkronkan ke server di grup sinkronisasi?

    Perubahan yang dilakukan pada berbagi file Azure dengan menggunakan portal Azure atau SMB tidak langsung terdeteksi dan direplikasi seperti perubahan pada titik akhir server. Azure Files belum memiliki pemberitahuan perubahan atau penjurnalan, jadi tidak ada cara untuk memulai sesi sinkronisasi secara otomatis saat file diubah. Di Windows Server, Azure File Sync menggunakan penjurnalan Windows USN untuk memulai sesi sinkronisasi secara otomatis saat file berubah.

    Untuk mendeteksi perubahan pada berbagi file Azure, Azure File Sync memiliki pekerjaan terjadwal yang disebut pekerjaan deteksi perubahan. Pekerjaan deteksi perubahan menghitung setiap file dalam berbagi, lalu membandingkannya dengan versi sinkronisasi untuk file tersebut. Saat pekerjaan deteksi perubahan menentukan bahwa file telah berubah, Azure File Sync memulai sesi sinkronisasi. Pekerjaan deteksi perubahan dimulai setiap 24 jam. Karena pekerjaan deteksi perubahan bekerja dengan menghitung setiap file di berbagi file Azure, deteksi perubahan membutuhkan waktu lebih lama di ruang nama yang lebih besar daripada di namespace yang lebih kecil. Untuk namespace yang lebih besar, mungkin perlu waktu lebih lama dari sekali setiap 24 jam untuk menentukan file mana yang telah berubah.

    Untuk segera menyinkronkan file yang diubah dalam berbagi file Azure, cmdlet Invoke-AzStorageSyncChangeDetection PowerShell dapat digunakan untuk secara manual memulai deteksi perubahan dalam berbagi file Azure. Cmdlet ini ditujukan untuk skenario yang mengatur agar beberapa jenis proses otomatis membuat perubahan dalam berbagi file Azure atau perubahan dilakukan oleh administrator (seperti memindahkan file dan direktori ke berbagi file). Untuk perubahan pengguna akhir, rekomendasinya adalah memasang agen Azure File Sync di IaaS VM dan meminta pengguna akhir mengakses berbagi file melalui IaaS VM. Dengan cara ini, semua perubahan akan disinkronkan dengan cepat ke agen lain tanpa perlu menggunakan cmdlet Invoke-AzStorageSyncChangeDetection. Untuk belajar lebih lanjut, lihat dokumentasi Invoke-AzStorageSyncChangeDetection.

    Kami sedang menjajaki penambahan deteksi perubahan untuk berbagi file Azure yang mirip dengan USN untuk volume di Windows Server. Bantu kami memprioritaskan fitur ini untuk pengembangan mendatang dengan memilihnya di Umpan Balik Komunitas Azure.

  • Jika file yang sama diubah pada dua server pada waktu yang hampir bersamaan, apa yang terjadi?
    Konflik file dibuat ketika file di berbagi file Azure tidak cocok dengan file di lokasi titik akhir server (ukuran dan/atau waktu terakhir diubah berbeda).

    Skenario berikut dapat menyebabkan konflik file:

    • File dibuat atau dimodifikasi di titik akhir (misalnya, Server A). Jika file yang sama diubah pada titik akhir yang berbeda sebelum perubahan pada Server A disinkronkan ke titik akhir tersebut, file konflik dibuat.
    • File ada di berbagi file Azure dan lokasi titik akhir server sebelum pembuatan titik akhir server. Jika ukuran file dan/atau waktu terakhir diubah berbeda antara file di server dan berbagi file Azure saat titik akhir server dibuat, file konflik dibuat.
    • Database sinkronisasi dibuat ulang karena kerusakan atau batas pengetahuan tercapai. Setelah database dibuat ulang, sinkronisasi memasuki mode yang disebut rekonsiliasi. Jika ukuran file dan/atau waktu terakhir diubah berbeda antara file di server dan berbagi file Azure saat rekonsiliasi terjadi, file konflik dibuat.

    Azure File Sync menggunakan strategi penyelesaian konflik sederhana: kami menyimpan kedua perubahan pada file yang diubah dalam dua titik akhir secara bersamaan. Perubahan yang terakhir ditulis menyimpan nama file asli. File yang lebih lama (ditentukan oleh LastWriteTime) memiliki nama titik akhir dan nomor konflik yang ditambahkan ke nama file. Untuk titik akhir server, nama titik akhir adalah nama server. Untuk titik akhir cloud, nama titik akhir adalah Cloud. Namanya mengikuti taksonomi ini:

    <FileNameWithoutExtension>-<endpointName>[-#].<ext>

    Misalnya, konflik pertama CompanyReport.docx akan menjadi CompanyReport-CentralServer.docx jika CentralServer adalah tempat tulisan yang lebih lama terjadi. Konflik kedua akan diberi nama CompanyReport-CentralServer-1.docx. Azure File Sync mendukung 100 file konflik per file. Setelah jumlah maksimum file konflik tercapai, file akan gagal disinkronkan sampai jumlah file konflik kurang dari 100.

  • Saya menonaktifkan tingkatan cloud, mengapa ada file bertingkat di lokasi titik akhir server?
    Ada dua alasan mengapa file berjenjang mungkin ada di lokasi titik akhir server:

    • Saat menambahkan titik akhir server baru ke grup sinkronisasi yang sudah ada, jika Anda memilih opsi kembali ke namespace pertama atau opsi pemanggilan kembali namespace saja untuk mode unduhan awal, file akan muncul sebagai bertingkat hingga diunduh secara lokal. Untuk menghindari hal ini, pilih opsi hindari file berjenjang untuk mode pengunduhan awal. Untuk memanggil kembali file secara manual, gunakan Invoke-StorageSyncFileRecall cmdlet .

    • Jika tingkatan cloud diaktifkan di titik akhir server lalu dinonaktifkan, file akan tetap bertingkat hingga dapat diakses.

  • Mengapa file berjenjang saya tidak menampilkan gambar mini atau pratinjau di Windows File Explorer?
    Untuk file bertingkta, gambar mini dan pratinjau tidak akan terlihat di titik akhir server Anda. Ini adalah perilaku yang diharapkan karena fitur singgahan gambar mini di Windows sengaja melompati membaca file dengan atribut offline. Dengan Tingkatan Cloud diaktifkan, membaca file bertingkat akan menyebabkan diunduh (dipanggil kembali).

    Perilaku ini tidak spesifik untuk Azure File Sync. Windows File Explorer menampilkan "X abu-abu" untuk file apa pun yang memiliki set atribut offline. Anda akan melihat ikon X saat mengakses file melalui SMB. Untuk penjelasan rinci tentang perilaku ini, lihat Mengapa saya tidak mendapatkan thumbnail untuk file yang ditandai secara offline?

    Untuk pertanyaan tentang cara mengelola file bertingkat, lihat Cara mengelola file bertingkat.

  • Mengapa file bertingkat ada di luar namespace layanan titik akhir server?
    Sebelum agen Azure File Sync versi 3, Azure File Sync memblokir pemindahan file bertingkat di luar titik akhir server tetapi pada volume yang sama dengan titik akhir server. Operasi salin, pemindahan file yang tidak berjenjang, dan pemindahan file berjenjang ke volume lain tidak terpengaruh. Alasan untuk perilaku ini adalah asumsi implisit bahwa File Explorer dan Windows API lainnya memiliki bahwa memindahkan operasi pada volume yang sama adalah (hampir) operasi ganti nama instan. Ini berarti gerakan akan membuat File Explorer atau metode pemindahan lainnya (seperti baris perintah atau PowerShell) tampak tidak responsif sementara Azure File Sync memanggil kembali data dari cloud. Dimulai dengan agen Azure File Sync versi 3.0.12.0, Azure File Sync akan memungkinkan Anda memindahkan file bertingkat di luar titik akhir server. Kami menghindari efek negatif yang disebutkan sebelumnya dengan memungkinkan file berjenjang ada sebagai file bertingkat di luar titik akhir server dan kemudian memanggil kembali file di latar belakang. Ini berarti bahwa bergerak pada volume yang sama bersifat instan, dan kami melakukan semua pekerjaan untuk memanggil kembali file ke disk setelah pemindahan selesai.

  • Saya mengalami masalah dengan Azure File Sync di server saya (sinkronisasi, tingkatan cloud, dll.). Haruskah saya menghapus dan membuat ulang titik akhir server saya?

    Tidak: menghapus titik akhir server tidak seperti me-reboot server! Menghapus dan membuat ulang titik akhir server hampir tidak pernah menjadi solusi yang tepat untuk memperbaiki masalah dengan sinkronisasi, jenjang cloud, atau aspek lain dari Sinkronisasi File Azure. Menghapus titik akhir server adalah operasi yang merusak. Ini mungkin mengakibatkan kehilangan data jika file berjenjang ada di luar namespace layanan titik akhir server. Untuk informasi selengkapnya, lihat mengapa file berjenjang berada di luar namespace layanan titik akhir server untuk informasi selengkapnya. Atau mungkin mengakibatkan file yang tidak dapat diakses untuk file berjenjang yang ada dalam namespace titik akhir server. Masalah ini tidak dapat diatasi ketika titik akhir server dibuat ulang. File berjenjang mungkin ada di dalam namespace layanan titik akhir server Anda meskipun Anda tidak pernah mengaktifkan jenjang cloud. Itulah sebabnya kami menyarankan agar Anda tidak menghapus titik akhir server kecuali jika Anda ingin berhenti menggunakan Sinkronisasi File Azure dengan folder tertentu ini atau telah secara eksplisit diinstruksikan untuk melakukannya oleh teknisi Microsoft. Untuk informasi selengkapnya tentang menghapus titik akhir server, lihat Menghapus titik akhir server.

  • Bisakah saya memindahkan layanan sinkronisasi penyimpanan dan/atau akun penyimpanan ke grup sumber daya, langganan, atau penyewa Microsoft Entra yang berbeda?
    Ya, Anda dapat memindahkan layanan sinkronisasi penyimpanan dan/atau akun penyimpanan ke grup sumber daya, langganan, atau penyewa Microsoft Entra yang berbeda. Setelah memindahkan layanan sinkronisasi penyimpanan atau akun penyimpanan, Anda perlu memberikan akses aplikasi Microsoft.StorageSync ke akun penyimpanan. Ikuti langkah-langkah ini:

    1. Masuk ke portal Azure dan pilih Kontrol akses (IAM) dari navigasi sebelah kiri.

    2. Pilih tab Penetapan peran untuk mencantumkan pengguna dan aplikasi (perwakilan layanan) yang memiliki akses ke akun penyimpanan Anda.

    3. Verifikasi Microsoft.StorageSync atau Hybrid File Sync Service (nama aplikasi lama) muncul dalam daftar dengan peran Pembaca dan Akses Data.

      Jika Microsoft.StorageSync atau Hybrid File Sync Service tidak muncul dalam daftar, lakukan langkah-langkah berikut:

      • Pilih Tambahkan.
      • Di bidang Peran, pilih Akses Data dan Pembaca.
      • Di bidang Pilih, ketik Microsoft.StorageSync, pilih peran lalu pilih Simpan.

      Catatan

      Saat membuat titik akhir cloud, layanan sinkronisasi penyimpanan dan akun penyimpanan harus berada di penyewa Microsoft Entra yang sama. Setelah titik akhir cloud dibuat, layanan sinkronisasi penyimpanan dan akun penyimpanan dapat dipindahkan ke penyewa Microsoft Entra yang berbeda.

  • Apakah Azure File Sync mempertahankan ACL NTFS tingkat direktori/file bersama dengan data yang disimpan di Azure Files?

    Pada tanggal 24 Februari 2020, ACL baru dan yang sudah ada yang dilapisi oleh sinkronisasi file Azure akan disimpan dalam format NTFS, dan modifikasi ACL yang dibuat langsung ke berbagi file Azure akan disinkronkan ke semua server dalam grup sinkronisasi. Setiap perubahan pada ACL yang dilakukan pada berbagi file Azure akan disinkronkan melalui Azure File Sync. Saat menyalin data ke Azure Files, pastikan Anda menggunakan alat salin yang mendukung "keakuratan" yang diperlukan untuk menyalin atribut, tanda waktu, dan ACL ke dalam berbagi file Azure - baik melalui SMB atau REST. Saat menggunakan alat salin Azure seperti AzCopy, penting untuk menggunakan versi terbaru. Periksa tabel alat penyalinan file untuk mendapatkan gambaran umum alat salin Azure untuk memastikan Anda bisa menyalin semua metadata penting file.

    Jika Anda telah mengaktifkan Azure Backup pada berbagi file terkelola Azure File Sync, ACL file dapat terus dipulihkan sebagai bagian dari alur kerja pemulihan cadangan. Ini berfungsi baik untuk seluruh file/direktori berbagi atau individual.

    Jika Anda menggunakan rekam jepret sebagai bagian dari solusi pencadangan yang dikelola sendiri untuk berbagi file yang dikelola oleh Azure File Sync, ACL Anda mungkin tidak dipulihkan dengan benar ke ACL NTFS jika rekam jepret diambil sebelum 24 Februari 2020. Jika hal ini terjadi, pertimbangkan untuk menghubungi Dukungan Azure.

  • Apakah Azure File Sync menyinkronkan LastWriteTime untuk direktori? Mengapa tanda waktu yang diubah tanggal pada direktori tidak diperbarui saat file di dalamnya diubah?
    Tidak, Azure File Sync tidak menyinkronkan LastWriteTime untuk direktori. Selain itu, Azure Files tidak memperbarui tanda waktu yang dimodifikasi tanggal (LastWriteTime) untuk direktori saat file dalam direktori diubah. Ini adalah perilaku yang diharapkan.

Keamanan, autentikasi, dan kontrol akses

  • Bagaimana cara mengaudit akses dan perubahan file di Azure Files?

    Ada dua opsi yang menyediakan fungsionalitas pengauditan untuk Azure Files:

    • Jika pengguna mengakses berbagi file Azure secara langsung, Anda dapat menggunakan log Azure Storage untuk melacak perubahan file dan akses pengguna untuk tujuan pemecahan masalah. Permintaan dicatat di log dengan basis upaya terbaik.
    • Jika pengguna mengakses berbagi file Azure melalui Windows Server yang memasang agen Azure File Sync, gunakan kebijakan audit atau produk pihak ketiga untuk melacak perubahan file dan akses pengguna di Windows Server.

  • Apakah Azure Files mendukung penggunaan Access-Based Enumeration (ABE) untuk mengontrol visibilitas file dan folder di berbagi file Azure SMB?

    Penggunaan ABE dengan File Azure saat ini tidak didukung, tetapi Anda dapat menggunakan DFS-N dengan berbagi file Azure SMB.

Autentikasi berbasis identitas

  • Apakah Microsoft Entra Domain Services mendukung akses SMB menggunakan kredensial Microsoft Entra dari perangkat yang bergabung atau terdaftar dengan ID Microsoft Entra?

    Tidak, skenario ini tidak didukung.

  • Bisakah saya menggunakan nama kanonis (CNAME) untuk memasang berbagi file Azure saat menggunakan autentikasi berbasis identitas?

    Ya, skenario ini sekarang didukung di lingkungan forest tunggal dan multi-forest untuk berbagi file Azure SMB. Namun, Azure Files hanya mendukung konfigurasi CNAMEs menggunakan nama akun penyimpanan sebagai awalan domain. Jika Anda tidak ingin menggunakan nama akun penyimpanan sebagai awalan, pertimbangkan untuk menggunakan Namespace DFS sebagai gantinya.

  • Bisakah saya mengakses berbagi file Azure dengan kredensial Microsoft Entra dari VM di bawah langganan lain?

    Jika langganan tempat berbagi file disebarkan dikaitkan dengan penyewa Microsoft Entra yang sama dengan penyebaran Microsoft Entra Domain Services tempat VM bergabung dengan domain, Anda kemudian dapat mengakses berbagi file Azure menggunakan kredensial Microsoft Entra yang sama. Batasan diberlakukan bukan pada langganan tetapi pada penyewa Microsoft Entra terkait.

  • Bisakah saya mengaktifkan Microsoft Entra Domain Services atau autentikasi AD DS lokal untuk berbagi file Azure menggunakan penyewa Microsoft Entra yang berbeda dari penyewa utama berbagi file Azure?

    Tidak. Azure Files hanya mendukung Microsoft Entra Domain Services atau integrasi AD DS lokal dengan penyewa Microsoft Entra yang berada dalam langganan yang sama dengan berbagi file. Langganan hanya dapat dikaitkan dengan satu penyewa Microsoft Entra. Saat menggunakan AD DS lokal untuk autentikasi, kredensial AD DS harus disinkronkan ke ID Microsoft Entra yang terkait dengan akun penyimpanan.

  • Apakah autentikasi AD DS lokal untuk berbagi file Azure integrasi dukungan dengan lingkungan AD DS menggunakan beberapa hutan?

    Autentikasi AD DS lokal Azure Files hanya terintegrasi dengan hutan layanan domain tempat akun penyimpanan didaftarkan. Untuk mendukung autentikasi dari hutan lain, lingkungan Anda harus memiliki kepercayaan lingkungan yang dikonfigurasi dengan benar. Untuk instruksi mendetail, lihat Menggunakan Azure Files dengan beberapa forest Direktori Aktif.

    Catatan

    Dalam penyiapan multi-forest, jangan gunakan File Explorer untuk mengonfigurasi izin ACL/NTFS Windows di tingkat akar, direktori, atau file. Gunakan icacls sebagai gantinya.

  • Apakah ada perbedaan dalam membuat akun komputer atau akun masuk layanan untuk mewakili akun penyimpanan saya di AD?

    Membuat akun komputer (default) atau akun masuk layanan tidak memiliki perbedaan tentang cara kerja autentikasi dengan Azure Files. Anda dapat membuat pilihan sendiri tentang cara mewakili akun penyimpanan sebagai identitas di lingkungan AD Anda. DomainAccountType default yang diatur dalam Join-AzStorageAccountForAuth cmdlet adalah akun komputer. Namun, usia kedaluwarsa kata sandi yang dikonfigurasi di lingkungan AD Anda dapat berbeda untuk akun masuk komputer atau layanan, dan Anda perlu mempertimbangkannya untuk Memperbarui kata sandi identitas akun penyimpanan Anda di AD.

  • Bagaimana cara menghapus kredensial cache dengan kunci akun penyimpanan dan menghapus koneksi SMB yang ada sebelum menginisialisasi koneksi baru dengan ID Microsoft Entra atau kredensial AD?

    Ikuti proses dua langkah di bawah ini untuk menghapus kredensial tersimpan yang terkait dengan kunci akun penyimpanan dan menghapus koneksi SMB:

    1. Jalankan perintah berikut dari perintah Windows untuk menghapus kredensial. Jika Anda tidak dapat menemukannya, itu berarti Anda belum mempertahankan kredensial dan dapat melewati langkah ini.

      cmdkey /delete:Domain:target=storage-account-name.file.core.windows.net

    2. Hapus koneksi yang sudah ada ke berbagi file. Anda dapat menentukan jalur pemasangan sebagai huruf kandar yang dipasang atau storage-account-name.file.core.windows.net jalur.

      net use <drive-letter/share-path> /delete

  • Apakah mungkin untuk melihat userPrincipalName (UPN) pemilik file/direktori di File Explorer alih-alih pengidentifikasi keamanan (SID)?

    File Explorer memanggil API RPC langsung ke server (Azure Files) untuk menerjemahkan SID ke UPN. Azure Files tidak mendukung API ini, jadi di File Explorer, SID pemilik file/direktori ditampilkan alih-alih UPN untuk file dan direktori yang dihosting di Azure Files. Namun, dari klien yang bergabung dengan domain, Anda bisa menggunakan perintah PowerShell berikut untuk menampilkan semua item dalam direktori dan pemiliknya, termasuk UPN:

    Get-ChildItem <Path> | Get-ACL | Select Path, Owner

Sistem File Jaringan (NFS v4.1)

Salinan bayangan berbagi

Buat salinan bayangan berbagi

  • Apakah salinan bayangan berbagi saya bersifat redundansi geografis?
    Salinan bayangan berbagi memiliki redundansi yang sama dengan berbagi file Azure yang diambil. Jika Anda telah memilih penyimpanan geo-redundan untuk akun Anda, snapshot berbagi Anda juga disimpan secara berlebihan di wilayah yang dipasangkan.

Menghapus salinan bayangan berbagi

  • Dapatkah saya menghapus berbagi saya tetapi tidak menghapus salinan bayangan berbagi saya?
    Jika memiliki snapshot berbagi aktif untuk dibagikan, Anda tidak dapat menghapus berbagi. Anda dapat menggunakan API untuk menghapus salinan bayangan berbagi, bersama dengan berbagi. Anda juga dapat menghapus salinan bayangan berbagi dan berbagi di portal Microsoft Azure.

Penagihan dan harga

  • Apa itu transaksi di Azure Files, dan bagaimana transaksi tersebut ditagih? Transaksi protokol terjadi setiap kali pengguna, aplikasi, skrip, atau layanan berinteraksi dengan berbagi file Azure (menulis, membaca, mencantumkan, menghapus file, dll.). Penting untuk diingat bahwa beberapa tindakan yang mungkin Anda anggap sebagai operasi tunggal mungkin benar-benar melibatkan beberapa transaksi. Untuk berbagi file Azure standar yang ditagih pada model bayar sesuai penggunaan, berbagai jenis transaksi memiliki harga yang berbeda berdasarkan dampaknya pada berbagi file. Transaksi tidak memengaruhi penagihan untuk berbagi file premium, yang ditagih menggunakan model yang disediakan. Untuk informasi selengkapnya, lihat Memahami penagihan.

  • Berapa biaya salinan bayangan berbagi?
    Bagikan salinan bayangan bersifat bertambah bertahap. Salinan bayangan berbagi dasar adalah berbagi itu sendiri. Semua salinan bayangan berbagi berikutnya bertahap dan hanya menyimpan perbedaan dari salinan bayangan berbagi sebelumnya. Anda hanya ditagih untuk konten yang diubah. Jika Anda memiliki berbagi dengan 100 GiB data tetapi hanya 5 GiB yang telah berubah sejak snapshot berbagi terakhir Anda, snapshot berbagi hanya menggunakan 5 GiB tambahan, dan Anda ditagih seharga 105 GiB. Untuk informasi selengkapnya tentang transaksi dan biaya keluar standar, lihat halaman Harga.

Interoperabilitas dengan layanan lain

  • Bisakah saya menggunakan berbagi file Azure saya sebagai Saksi Berbagi File untuk Kluster Failover Windows Server saya?
    Konfigurasi ini saat ini tidak didukung untuk Azure Files. Untuk mempelajari cara menyiapkan ini menggunakan penyimpanan Azure Blob, lihat Menyebarkan Cloud Witness untuk Kluster Failover.

Baca juga