Merencanakan penyebaran Azure File Sync

Wawancara dan demo pengantar Azure File Sync - klik untuk memutar!

Azure File Sync adalah layanan yang memungkinkan Anda menyimpan cache beberapa berbagi file Azure di Windows Server lokal atau VM cloud.

Artikel ini memperkenalkan konsep dan fitur Azure File Sync. Setelah Anda terbiasa dengan Azure File Sync, pertimbangkan untuk mengikuti panduan penyebaran Azure File Sync untuk mencoba layanan ini.

File akan disimpan dalam cloud di Berbagi file Azure. Berbagi file Azure dapat digunakan dengan dua cara: dengan langsung memasang berbagi file Azure tanpa server (SMB) ini atau dengan menyimpan cache berbagi file Azure secara lokal menggunakan Azure File Sync. Opsi penyebaran yang Anda pilih mengubah aspek yang perlu dipertimbangkan, saat Anda merencanakan penyebaran.

  • Pemasangan langsung berbagi file Azure: Karena Azure Files menyediakan akses SMB, Anda dapat memasang berbagi file Azure secara lokal atau di cloud menggunakan klien SMB standar yang tersedia di Windows, macOS, dan Linux. 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.

  • Menyimpan cache berbagi file Azure secara lokal dengan Azure File Sync: Azure File Sync memungkinkan Anda untuk memusatkan berbagi organisasi Anda di Azure Files, sambil mempertahankan fleksibilitas, performa, dan kompatibilitas server file lokal. Azure File Sync mentransformasi Windows Server menjadi cache cepat dari berbagi file Azure Anda.

Konsep pengelolaan

Penyebaran Azure File Sync memiliki tiga objek pengelolaan dasar:

  • Berbagi file Azure:Berbagi file Azure adalah fitur berbagi cloud tanpa server, yang menyediakan titik akhir cloud hubungan sinkronisasi Azure File Sync. File dalam berbagi file Azure dapat diakses langsung dengan SMB atau protokol FileREST, meskipun kami mendorong Anda untuk terutama mengakses file melalui cache Windows Server ketika berbagi file Azure sedang digunakan dengan Azure File Sync. Ini karena Azure Files saat ini tidak memiliki mekanisme deteksi perubahan yang efisien, seperti yang dimiliki Windows Server, sehingga penyebaran kembali perubahan berbagi file Azure ke titik akhir server secara langsung akan memakan waktu.
  • Titik akhir server: Jalur di Windows Server yang sedang disinkronkan ke berbagi file Azure. Jalur ini bisa berupa folder tertentu di volume atau akar volume. Beberapa titik akhir server dapat ada di volume yang sama jika namespace-nya tidak tumpang tindih.
  • Grup sinkronisasi: Objek yang menentukan hubungan sinkronisasi antara titik akhir cloud, atau berbagi file Azure, dan titik akhir server. Titik akhir dalam grup sinkronisasi tetap sinkron satu sama lain. Jika misalnya, Anda memiliki dua set file berbeda yang ingin dikelola dengan Azure File Sync, Anda akan membuat dua grup sinkronisasi dan menambahkan titik akhir yang berbeda ke setiap grup sinkronisasi.

Konsep pengelolaan berbagi file Azure

Berbagi file Azure disebarkan ke akun penyimpanan, yang merupakan objek tingkat atas yang mewakili kumpulan 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.

Konsep pengelolaan Azure File Sync

Grup sinkronisasi disebarkan ke dalam Storage Sync Services, yang merupakan objek tingkat atas yang mendaftarkan server untuk digunakan dengan Azure File Sync dan berisi hubungan grup sinkronisasi. Sumber daya Storage Sync Service adalah serekan sumber daya akun penyimpanan, dan juga dapat disebarkan ke grup sumber daya Azure. Storage Sync Service dapat membuat grup sinkronisasi yang berisi berbagi file Azure di beberapa akun penyimpanan dan beberapa Server Windows yang terdaftar.

Sebelum dapat membuat grup sinkronisasi di Storage Sync Service, Anda harus terlebih dahulu mendaftarkan Server Windows dengan Storage Sync Service. Tindakan ini akan membuat objek server terdaftar, yang mewakili hubungan kepercayaan antara server atau kluster Anda dan Storage Sync Service. Untuk mendaftarkan Storage Sync Service, Anda harus memasang agen Azure File Sync terlebih dahulu di server. Namun, server atau kluster hanya dapat didaftarkan dengan satu Storage Sync Service pada satu waktu.

Grup sinkronisasi berisi satu titik akhir cloud, atau berbagi file Azure, dan minimal satu titik akhir server. Objek titik akhir server berisi pengaturan yang mengonfigurasi kemampuan penjenjangan cloud, yang menyediakan kemampuan penyimpanan cache Azure File Sync. Untuk menyinkronkan dengan berbagi file Azure, akun penyimpanan yang berisi berbagi file Azure harus berada di wilayah Azure yang sama dengan Storage Sync Service.

Penting

Anda bisa membuat perubahan pada namespace titik akhir cloud atau titik akhir server dalam grup sinkronisasi dan menyinkronkan file Anda ke titik akhir lainnya dalam grup sinkronisasi. Jika Anda membuat perubahan pada titik akhir cloud (berbagi file Azure) secara langsung, perubahan harus terlebih dahulu ditemukan oleh pekerjaan deteksi perubahan Azure File Sync. Pekerjaan deteksi perubahan dimulai untuk titik akhir cloud saja setiap 24 jam sekali. Untuk informasi selengkapnya, lihat Tanya jawab umum tentang Azure Files.

Pertimbangkan jumlah Storage Sync Services yang diperlukan

Bagian sebelumnya membahas sumber daya inti yang akan dikonfigurasi untuk Azure File Sync: Storage Sync Service. Server Windows hanya dapat didaftarkan ke satu Storage Sync Service. Jadi opsi terbaik adalah hanya menyebarkan satu Storage Sync Service dan mendaftarkan semua server tersebut.

Buat beberapa Storage Sync Service hanya jika Anda memiliki:

  • set server berbeda yang tidak boleh bertukar data satu sama lain. Dalam hal ini, Anda ingin mendesain sistem untuk mengecualikan set server tertentu untuk disinkronkan dengan berbagi file Azure, yang sudah digunakan sebagai titik akhir cloud dalam grup sinkronisasi di Storage Sync Service yang berbeda. Cara lain untuk melihat ini adalah bahwa Windows Server yang terdaftar ke layanan sinkronisasi penyimpanan yang berbeda tidak dapat disinkronkan dengan berbagi file Azure yang sama.
  • kebutuhan untuk memiliki lebih banyak server terdaftar atau grup sinkronisasi daripada yang dapat didukung oleh satu Storage Sync Service. Untuk mengetahui detailnya, tinjau target skala Azure File Sync.

Rencanakan topologi sinkronisasi yang seimbang

Sebelum Anda menyebarkan sumber daya apa pun, penting untuk merencanakan apa yang akan Anda sinkronkan di server lokal, yang berbagi file Azure. Membuat rencana akan membantu Anda menentukan berapa banyak akun penyimpanan, berbagi file Azure, dan sumber daya sinkronisasi yang Anda butuhkan. Pertimbangan ini masih relevan, bahkan jika data Anda saat ini tidak berada di Windows Server atau server yang ingin Anda gunakan dalam jangka panjang. Bagian migrasi dapat membantu menentukan jalur migrasi yang sesuai untuk situasi Anda.

Dalam langkah ini, Anda akan menentukan berapa banyak berbagi file Azure yang Anda butuhkan. Satu instans Windows Server (atau kluster) dapat menyinkronkan hingga 30 berbagi file Azure.

Anda mungkin memiliki lebih banyak folder pada volume yang saat ini Anda bagikan secara lokal sebagai berbagi SMB kepada pengguna dan aplikasi Anda. Cara termudah untuk menggambarkan skenario ini adalah membayangkan pembagian lokal yang memetakan 1:1 ke berbagi file Azure. Jika Anda memiliki jumlah pembagian yang cukup kecil, di bawah 30 untuk satu instans Windows Server, kami merekomendasikan pemetaan 1:1.

Jika Anda memiliki lebih dari 30 berbagi, pemetaan berbagi lokal 1:1 ke berbagi file Azure seringkali tidak perlu. Pertimbangkan opsi berikut.

Berbagi pengelompokan

Misalnya, jika departemen sumber daya manusia (SDM) Anda memiliki 15 pembagian, Anda mungkin mempertimbangkan untuk menyimpan semua data SDM dalam satu berbagi file Azure. Menyimpan beberapa pembagian lokal dalam satu berbagi file Azure tidak mencegah Anda membuat 15 pembagian SMB biasa pada instans Windows Server lokal Anda. Ini hanya berarti bahwa Anda mengatur folder akar dari 15 pembagian ini sebagai subfolder di bawah folder umum. Anda kemudian menyinkronkan folder umum ini ke berbagi file Azure. Dengan begitu, hanya satu berbagi file Azure di cloud yang diperlukan untuk grup berbagi lokal ini.

Sinkronisasi volume

Azure File Sync mendukung sinkronisasi akar volume ke berbagi file Azure. Jika Anda menyinkronkan akar volume, semua subfolder dan file akan masuk ke berbagi file Azure yang sama.

Menyinkronkan akar volume tidak selalu merupakan opsi terbaik. Ada manfaat untuk menyinkronkan beberapa lokasi. Misalnya, melakukannya membantu menjaga jumlah item lebih rendah per lingkup sinkronisasi. Kami menguji berbagi file Azure dan Azure File Sync dengan 100 juta item (file dan folder) per berbagi. Tetapi praktik terbaik adalah mencoba mempertahankan angka di bawah 20 juta atau 30 juta dalam satu bagian. Menyiapkan Azure File Sync dengan jumlah item yang lebih rendah tidak hanya bermanfaat untuk sinkronisasi file. Jumlah item yang lebih rendah juga menguntungkan skenario seperti ini:

  • Pemindaian awal konten cloud dapat diselesaikan lebih cepat, yang pada gilirannya mengurangi penantian hingga ruang nama muncul di server yang diaktifkan untuk Azure File Sync.
  • Pemulihan sisi cloud dari snapshot berbagi file Azure akan lebih cepat.
  • Pemulihan bencana server lokal dapat mempercepat secara signifikan.
  • Perubahan yang dilakukan secara langsung di berbagi file Azure (di luar sinkronisasi) dapat dideteksi dan disinkronkan lebih cepat.

Tip

Jika Anda tidak tahu berapa banyak file dan folder yang Anda miliki, lihat alat TreeSize dari JAM Software GmbH.

Pendekatan terstruktur untuk peta penyebaran

Sebelum Anda menerapkan penyimpanan cloud di langkah selanjutnya, penting untuk membuat peta antara folder lokal dan berbagi file Azure. Pemetaan ini akan menginformasikan berapa banyak dan sumber daya grup sinkronisasi mana dari Azure File Sync yang akan Anda provisikan. Grup sinkronisasi mengikat berbagi file Azure dan folder di server Anda bersama-sama dan membuat koneksi sinkronisasi.

Untuk memutuskan berapa banyak berbagi file Azure yang Anda butuhkan, tinjau batasan dan praktik terbaik berikut. Melakukannya akan membantu Anda mengoptimalkan peta Anda.

  • Server tempat agen Azure File Sync dipasang dapat disinkronkan dengan hingga 30 berbagi file Azure.

  • Berbagi file Azure disebarkan di akun penyimpanan. Pengaturan itu menjadikan akun penyimpanan sebagai target skala untuk angka performa seperti IOPS dan throughput.

    Satu berbagi file Azure standar secara teoritis dapat menjenuhkan performa maksimum yang dapat dihasilkan akun penyimpanan. Jika Anda menempatkan beberapa pembagian dalam satu akun penyimpanan, Anda membuat kumpulan bersama IOPS dan throughput untuk berbagi ini. Jika Anda berencana untuk hanya melampirkan Azure File Sync ke berbagi file ini, mengelompokkan beberapa berbagi file Azure ke akun penyimpanan yang sama tidak akan membuat masalah. Tinjau target performa berbagi file Azure untuk wawasan yang lebih mendalam tentang metrik terkait. Batasan ini tidak berlaku untuk penyimpanan premium, saat performa diprovisikan secara khusus dan dijamin untuk setiap pembagian.

    Jika Anda berencana untuk mengangkat aplikasi ke Azure yang akan menggunakan berbagi file Azure secara asli, Anda mungkin memerlukan lebih banyak performa dari berbagi file Azure Anda. Jika jenis penggunaan ini adalah kemungkinan, bahkan di masa depan, yang terbaik adalah membuat satu berbagi file Azure standar di akun penyimpanannya sendiri.

  • Ada batas 250 akun penyimpanan per langganan per wilayah Azure.

Tip

Mengingat informasi ini, sering kali perlu untuk mengelompokkan beberapa folder tingkat atas pada volume Anda ke direktori akar umum baru. Anda kemudian menyinkronkan direktori akar baru ini, dan semua folder yang Anda kelompokkan ke dalamnya, ke satu berbagi file Azure. Teknik ini memungkinkan Anda untuk tetap berada dalam batas 30 sinkronisasi berbagi file Azure per server.

Pengelompokan di bawah akar umum ini tidak memengaruhi akses ke data Anda. ACL Anda tetap seperti mereka. Anda hanya perlu menyesuaikan jalur berbagi apa pun (seperti berbagi SMB atau NFS) yang mungkin Anda miliki di folder server lokal yang sekarang Anda ubah menjadi akar umum. Tidak ada perubahan lain.

Penting

Vektor skala terpenting untuk Azure File Sync adalah jumlah item (file dan folder) yang perlu disinkronkan. Untuk mengetahui detailnya, tinjau target skala Azure File Sync.

Ini adalah praktik terbaik untuk menjaga jumlah item per lingkup sinkronisasi tetap rendah. Itu adalah faktor penting untuk dipertimbangkan dalam pemetaan folder Anda ke berbagi file Azure. Azure File Sync diuji dengan 100 juta item (file dan folder) per berbagi. Tetapi sering kali yang terbaik adalah menjaga jumlah item di bawah 20 juta atau 30 juta dalam berbagi tunggal. Pisahkan namespace Anda menjadi beberapa pembagian jika Anda mulai melebihi angka-angka ini. Anda dapat terus mengelompokkan beberapa berbagi lokal ke dalam berbagi file Azure yang sama jika Anda tetap berada di bawah angka-angka ini. Praktik ini akan memberi Anda ruang untuk berkembang.

Ada kemungkinan bahwa, dalam situasi Anda, himpunan folder dapat secara logis menyinkronkan ke berbagi file Azure yang sama (dengan menggunakan pendekatan folder akar umum baru yang disebutkan sebelumnya). Tetapi mungkin masih lebih baik untuk mengelompokkan kembali folder sehingga mereka menyinkronkan ke dua alih-alih satu berbagi file Azure. Anda dapat menggunakan pendekatan ini untuk menjaga jumlah file dan folder per berbagi file seimbang di seluruh server. Anda juga dapat membagi berbagi dan menyinkronkan di server lokal lainnya, menambahkan kemampuan untuk menyinkronkan dengan 30 lebih banyak berbagi file Azure per server tambahan.

Membuat tabel pemetaan

Diagram yang memperlihatkan contoh tabel pemetaan. Unduh file berikut untuk menjalankan dan menggunakan konten gambar ini.

Gunakan informasi sebelumnya untuk menentukan berapa banyak berbagi file Azure yang Anda butuhkan dan bagian mana dari data Anda yang sudah ada akan berakhir saat berbagi file Azure.

Buat tabel yang merekam pemikiran Anda sehingga Anda bisa merujuknya saat Anda perlu. Tetap terorganisir penting karena dapat dengan mudah kehilangan detail rencana pemetaan Anda saat Anda menyediakan banyak sumber daya Azure sekaligus. Unduh file Excel berikut ini untuk digunakan sebagai templat untuk membantu membuat pemetaan Anda.


Excel icon that sets the context for the download. Unduh templat pemetaan kumpulan nama XML.

Pertimbangan server file Windows

Untuk mengaktifkan kapabilitas sinkronisasi di Windows Server, Anda harus memasang agen yang dapat diunduh Azure File Sync. Agen Azure File Sync menyediakan dua komponen utama: FileSyncSvc.exe, layanan Windows latar belakang yang bertanggung jawab untuk memantau perubahan pada titik akhir server dan memulai sesi sinkronisasi, dan StorageSync.sys, filter sistem file yang memungkinkan penjenjangan cloud dan pemulihan bencana cepat.

Persyaratan sistem operasi

Azure File Sync didukung dengan versi Windows Server berikut:

Versi SKU yang didukung Opsi penyebaran yang didukung
Server Windows 2019 Pusat Data, Standar, dan IoT Lengkap dan Inti
Server Windows 2016 Pusat Data, Standar, dan Server Penyimpanan Lengkap dan Inti
Windows Server 2012 R2 Pusat Data, Standar, dan Server Penyimpanan Lengkap dan Inti

Versi Windows Server yang akan datang akan ditambahkan saat dirilis.

Penting

Sebaiknya Anda tetap memperbarui semua server yang Anda gunakan dengan Azure File Sync dengan pembaruan terbaru dari Windows Update.

Sumber daya sistem minimum

Azure File Sync memerlukan server fisik atau virtual, dengan minimal satu CPU dan minimal 2 GiB memori.

Penting

Jika server berjalan di komputer virtual dengan memori dinamis diaktifkan, VM harus dikonfigurasi dengan memori minimum 2048 MiB.

Untuk sebagian besar beban kerja produksi, sebaiknya Anda tidak mengonfigurasi server sinkronisasi Azure File Sync hanya dengan persyaratan minimum. Lihat Sumber daya sistem yang direkomendasikan untuk informasi selengkapnya.

Sama seperti fitur atau aplikasi server apa pun, persyaratan sumber daya sistem untuk Azure File Sync ditentukan oleh skala penyebaran; penyebaran yang lebih besar pada server memerlukan sumber daya sistem yang lebih besar. Untuk Azure File Sync, skala ditentukan oleh jumlah objek di seluruh titik akhir server dan churn di himpunan data. Server tunggal bisa memiliki beberapa titik akhir server di beberapa grup sinkronisasi dan jumlah objek yang tercantum dalam akun tabel berikut untuk namespace lengkap tempat server dipasang.

Misalnya, titik akhir server A dengan 10 juta objek + titik akhir server B dengan 10 juta objek = 20 juta objek. Untuk penyebaran contoh tersebut, kami merekomendasikan 8 CPU, 16 GiB memori agar status stabil, dan (jika mungkin) 48 GiB memori untuk migrasi awal.

Data namespace disimpan dalam memori karena alasan performa. Karena itu, namespace yang lebih besar membutuhkan lebih banyak memori untuk mempertahankan performa prima, dan lebih banyak churn membutuhkan lebih banyak CPU untuk pemrosesan.

Dalam tabel berikut, kami telah menyediakan ukuran namespace serta konversi ke kapasitas untuk berbagi tujuan umum tipikal, di mana rata-rata ukuran file adalah 512 KiB. Jika ukuran file Anda lebih kecil, pertimbangkan untuk menambahkan memori tambahan untuk jumlah kapasitas yang sama. Dasarkan konfigurasi memori Anda pada ukuran namespace.

Ukuran namespace - file & direktori (jutaan) Kapasitas umum (TiB) Inti CPU Memori yang direkomendasikan (GiB)
3 1,4 2 8 (sinkronisasi awal)/ 2 (churn khusus)
5 2,3 2 16 (sinkronisasi awal)/ 4 (churn khusus)
10 4,7 4 32 (sinkronisasi awal)/ 8 (churn khusus)
30 14,0 8 48 (sinkronisasi awal)/ 16 (churn khusus)
50 23,3 16 64 (sinkronisasi awal)/ 32 (churn khusus)
100* 46,6 32 128 (sinkronisasi awal)/ 32 (churn umum)

*Menyinkronkan lebih dari 100 juta file & direktori tidak direkomendasikan saat ini. Ini adalah batas sementara berdasarkan ambang batas yang kami uji. Untuk informasi lebih lanjut, lihat target skala Azure File Sync.

Tip

Sinkronisasi awal namespace adalah operasi intensif, dan sebaiknya Anda mengalokasikan lebih banyak memori hingga sinkronisasi awal selesai. Ini tidak diperlukan, tetapi dapat mempercepat sinkronisasi awal.

Churn khusus adalah 0,5% dari namespace yang berubah per hari. Untuk tingkat churn yang lebih tinggi, pertimbangkan untuk menambahkan lebih banyak CPU.

  • Volume yang dipasang secara lokal diformat dengan sistem file NTFS.

Cmdlet evaluasi

Sebelum menyebarkan Azure File Sync, Anda harus mengevaluasi apakah ini kompatibel dengan sistem Anda menggunakan cmdlet evaluasi Azure File Sync. Cmdlet ini memeriksa potensi masalah dengan sistem file dan himpunan data Anda, seperti karakter yang tidak didukung atau versi sistem operasi yang tidak didukung. Pemeriksaannya mencakup sebagian besar tetapi tidak semua fitur yang disebutkan di bawah; sebaiknya Anda membaca seluruh bagian ini dengan seksama untuk memastikan penyebaran Anda berjalan lancar.

Cmdlet evaluasi dapat dipasang dengan memasang modul Az PowerShell, yang dapat dipasang dengan mengikuti petunjuk di sini: Memasang dan mengonfigurasi Azure PowerShell.

Penggunaan

Anda dapat menggunakan alat evaluasi dengan beberapa cara yang berbeda: Anda dapat melakukan pemeriksaan sistem, pemeriksaan himpunan data, atau keduanya. Untuk melakukan pemeriksaan sistem dan himpunan data:

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

Untuk menguji himpunan data saja:

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

Untuk menguji persyaratan sistem saja:

Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks

Untuk menampilkan hasil di CSV:

$validation = Invoke-AzStorageSyncCompatibilityCheck C:\DATA
$validation.Results | Select-Object -Property Type, Path, Level, Description, Result | Export-Csv -Path C:\results.csv -Encoding utf8

Kompatibilitas sistem file

Azure File Sync hanya didukung pada volume NTFS yang dipasang secara langsung. Penyimpanan yang terpasang langsung, atau DAS, di Windows Server berarti bahwa sistem operasi Windows Server memiliki sistem file. DAS dapat disediakan dengan melampirkan disk secara fisik ke server file, melampirkan disk virtual ke VM server file (seperti VM yang dihosting oleh Hyper-V), atau bahkan melalui ISCSI.

Hanya volume NTFS yang didukung; ReFS, FAT, FAT32, dan sistem file lainnya yang tidak didukung.

Tabel berikut memperlihatkan status interop fitur sistem file NTFS:

Fitur Status dukungan Catatan
Daftar kontrol akses (ACL) Didukung sepenuhnya Daftar kontrol akses diskresi gaya Windows dipertahankan oleh Sinkronisasi File Azure, dan diberlakukan oleh Windows Server pada titik akhir server. ACL juga dapat diberlakukan saat memasang berbagi file Azure secara langsung, namun hal ini memerlukan konfigurasi tambahan. Lihat bagian Identitas informasi selengkapnya.
Tautan keras Dilompati
Link simbolik Dilompati
Titik pemasangan Didukung sebagian Titik pemasangan mungkin merupakan akar titik akhir server, tetapi dilewati jika terkandung dalam namespace titik akhir server.
Persimpangan Dilompati Misalnya, Folder Sistem File Terdistribusi DfrsrPrivate dan DFSRoots.
Titik reparse Dilompati
Kompresi NTFS Didukung sepenuhnya
File sparse Didukung sepenuhnya Sinkronisasi file sparse (tidak diblokir), tetapi disinkronkan ke cloud sebagai file lengkap. Jika konten file berubah di cloud (atau di server lain), file tidak lagi sparse ketika perubahan diunduh.
Aliran Data Alternatif (ADS) Dicadangkan, tetapi tidak disinkronkan Misalnya, tag klasifikasi yang dibuat oleh Infrastruktur Klasifikasi File tidak disinkronkan. Tag klasifikasi yang ada pada file pada setiap titik akhir server dibiarkan tidak tersentuh.

Azure File Sync juga akan melewati file sementara dan folder sistem tertentu:

File/folder Catatan
pagefile.sys File khusus untuk sistem
Desktop.ini File khusus untuk sistem
thumbs.db File sementara untuk gambar mini
ehthumbs.db File sementara untuk gambar mini media
~$*.* File sementara Office
*.tmp File sementara
*.laccdb Mengakses file penguncian DB
635D02A9D91C401B97884B82B3BCDAEA.* File Sinkronisasi Internal
\Informasi Volume Sistem Folder khusus untuk volume
$RECYCLE.BIN Folder
\SyncShareState Folder untuk Sinkronisasi

Pertimbangkan berapa banyak ruang kosong yang Anda butuhkan pada disk lokal Anda

Saat berencana untuk menggunakan Azure File Sync, pertimbangkan berapa banyak ruang kosong yang Anda butuhkan pada disk lokal yang Anda rencanakan untuk memiliki titik akhir server.

Dengan Azure File Sync, Anda harus memperhitungkan penggunaan ruang berikut pada disk lokal Anda:

  • Jika tingkatan cloud diaktifkan:

    • Pemilahan ulang poin untuk file bertingkat
    • Database metadata Azure File Sync
    • Penyimpanan file yang sering diakses (heatstore) di Azure File Sync
    • File yang telah diunduh sepenuhnya di cache hot (jika ada)
    • Persyaratan kebijakan ruang bebas volume
  • Jika tingkatan cloud dinonaktifkan:

    • File yang telah diunduh sepenuhnya
    • Penyimpanan file yang sering diakses (heatstore) di Azure File Sync
    • Database metadata Azure File Sync

Kami akan menggunakan contoh untuk mengilustrasikan cara memperkirakan jumlah ruang kosong yang dibutuhkan pada disk lokal Anda. Katakanlah Anda telah menginstal agen Azure File Sync di mesin virtual Azure Windows Anda, dan berencana untuk membuat titik akhir server pada disk F. Anda memiliki 1 juta file dan ingin memberikan tingkatan pada semua file tersebut, 100.000 direktori, dan ukuran kluster disk sebesar 4 KiB. Kapasitas disknya adalah 1000 GiB. Anda ingin mengaktifkan tingkatan cloud dan mengatur kebijakan ruang bebas volume Anda menjadi 20%.

  1. NTFS mengalokasikan ukuran kluster untuk masing-masing file bertingkat. 1 juta file * Ukuran kluster 4 KiB = 4.000.000 KiB (4 GiB)

Catatan

Ruang yang diisi oleh file bertingkat dialokasikan oleh NTFS. Oleh karena itu, ruang tersebut tidak akan muncul di antarmuka pengguna mana pun. 3. Metadata sinkronisasi menempati ukuran kluster per item. (1 juta file + 100.000 direktori) * Ukuran kluster 4 KiB = 4.400.000 KiB (4,4 GiB) 4. Heatstore Azure File Sync mengisi sebanyak 1,1 KiB untuk setiap file. 1 juta file * Ukuran kluster 1,1 KiB = 1.100.000 KiB (1,1 GiB) 5. Kebijakan ruang bebas volume adalah 20%. 1000 GiB * 0,2 = 200 GiB

Dalam hal ini, Azure File Sync akan membutuhkan sekitar 209.500.000 KiB (209,5 GiB) ruang untuk namespace layanan ini. Tambahkan jumlah ini ke ruang kosong tambahan yang diinginkan untuk mengetahui berapa banyak ruang kosong yang diperlukan untuk disk ini.

Pengklusteran Failover

  1. Pengklusteran Failover Windows Server didukung oleh Azure File Sync untuk opsi penyebaran "Server File untuk penggunaan umum".
  2. Satu-satunya skenario yang didukung oleh Azure File Sync adalah Kluster Failover Server Windows dengan Disk Berkluster
  3. Pengklusteran failover tidak didukung pada "Server File Peningkatan Skala untuk data aplikasi" (SOFS) atau pada Volume Bersama Berkluster (CSV) atau disk lokal.

Catatan

Agen Azure File Sync harus dipasang di setiap simpul dalam Kluster Failover agar sinkronisasi berfungsi dengan benar.

Deduplikasi Data

Windows Server 2016 dan Windows Server 2019
Deduplikasi Data didukung terlepas dari apakah penjenjangan cloud diaktifkan atau dinonaktifkan di satu atau beberapa titik akhir server pada volume untuk Windows Server 2016 dan Windows Server 2019. Mengaktifkan Deduplikasi Data pada volume dengan penjenjangan cloud diaktifkan memungkinkan Anda menyimpan lebih banyak file di tempat tanpa menyediakan lebih banyak penyimpanan.

Ketika Deduplikasi Data diaktifkan pada volume dengan penjenjangan cloud diaktifkan, file optimal Deduplikasi dalam lokasi titik akhir server akan ditingkatkan mirip dengan file normal berdasarkan pengaturan kebijakan penjenjangan cloud. Setelah file optimal Deduplikasi telah ditingkatkan, pekerjaan pengumpulan sampah Data Deduplikasi akan berjalan secara otomatis, untuk mengklaim kembali ruang disk dengan menghapus gugus yang tidak perlu yang tidak lagi dirujuk oleh file lain pada volume.

Perhatikan bahwa penghematan volume hanya berlaku untuk server; data Anda di berbagi file Azure tidak akan dideduplikasi.

Catatan

Untuk mendukung Deduplikasi Data pada volume dengan penjenjangan cloud diaktifkan di Windows Server 2019, pembaruan Windows KB4520062 - Oktober 2019 atau pembaruan rollup bulanan yang lebih baru harus dipasang, dan agen Azure File Sync versi 12.0.0.0 atau versi lebih baru diwajibkan.

Windows Server 2012 R2
Azure File Sync tidak mendukung Deduplikasi dan penjenjangan cloud pada volume yang sama di Windows Server 2012 R2. Jika Deduplikasi Data diaktifkan pada volume, maka penjenjangan cloud harus dinonaktifkan.

Catatan

  • Jika Deduplikasi Data dipasang sebelum memsang agen Azure File Sync, hidupkan ulang diperlukan untuk mendukung Deduplikasi Data dan penjenjangan cloud pada volume yang sama.

  • Jika Deduplikasi Data diaktifkan pada volume setelah penjenjangan cloud diaktifkan, pekerjaan pengoptimalan Deduplikasi awal akan mengoptimalkan file pada volume yang belum ditingkatkan, dan akan memiliki dampak berikut pada penjenjangan cloud:

    • Kebijakan ruang kosong akan terus membuat menjenjangkan file sesuai ruang kosong pada volume tersebut dengan menggunakan peta panas.
    • Kebijakan tanggal akan melewati penjenjangan file yang mungkin memenuhi syarat untuk penjenjangan, karena pekerjaan pengoptimalan Deduplikasi yang mengakses file.
  • Untuk pekerjaan pengoptimalan Deduplikasi yang sedang berlangsung, penjenjangan cloud dengan kebijakan tanggal akan ditunda oleh pengaturan Deduplikasi Data MinimumFileAgeDays, jika file belum dijenjangkan.

    • Contoh: Jika pengaturan MinimumFileAgeDays adalah tujuh hari dan kebijakan tanggal penjenjangan cloud adalah 30 hari, kebijakan tanggal akan menjenjangkan file setelah 37 hari.
    • Catatan: Setelah file dijenjangkan oleh Azure File Sync, pekerjaan pengoptimalan Deduplikasi akan melewati file.
  • Jika server yang menjalankan Windows Server 2012 R2 dengan agen Azure File Sync terpasang ditingkatkan ke Windows Server 2016 atau Windows Server 2019, langkah-langkah berikut harus dilakukan untuk mendukung Deduplikasi Data dan penjenjangan cloud pada volume yang sama:

    • Copot pemasangan agen Azure File Sync untuk Windows Server 2012 R2 dan hidupkan ulang server.
    • Unduh agen Azure File Sync untuk versi sistem operasi server baru (Windows Server 2016 atau Windows Server 2019).
    • Pasang agen Azure File Sync dan hidupkan ulang server.

    Catatan: Pengaturan konfigurasi Azure File Sync di server dipertahankan saat agen dicopot pemasangannya dan dipasang ulang.

Sistem File Terdistribusi (DFS)

Azure File Sync mendukung interop dengan DFS Namespaces (DFS-N) dan DFS Replication (DFS-R).

DFS Namepaces (DFS-N) : Azure File Sync didukung sepenuhnya di server DFS-N. Anda dapat memasang agen Azure File Sync pada satu atau beberapa anggota DFS-N untuk menyinkronkan data antara titik akhir server dan titik akhir cloud. Untuk informasi selengkapnya, lihat Ringkasan DFS Namespaces.

DFS Replication (DFS-R) : Karena DFS-R dan Azure File Sync adalah solusi replikasi, dalam banyak kasus, Sebaiknya Anda mengganti DFS-R dengan Azure File Sync. Namun ada beberapa skenario di mana Anda ingin menggunakan DFS-R dan Azure File Sync secara bersamaan:

  • Anda melakukan migrasi dari penyebaran DFS-R ke penyebaran Azure File Sync. Untuk informasi selengkapnya, lihat Melakukan migrasi penyebaran DFS Replication (DFS-R) ke Azure File Sync.
  • Tidak setiap server lokal yang membutuhkan salinan data file Anda dapat tersambung langsung ke internet.
  • Server cabang mengonsolidasikan data ke satu server hub tempat Anda ingin menggunakan Azure File Sync.

Agar Azure File Sync dan DFS-R berfungsi secara berdampingan:

  1. Penjenjangan cloud Azure File Sync harus dinonaktifkan pada volume dengan folder replikasi DFS-R.
  2. Titik akhir server tidak boleh dikonfigurasi pada folder replikasi DFS-R baca-saja.

Untuk informasi selengkapnya, lihat Ringkasan Replikasi DFS.

Sysprep

Menggunakan sysprep pada server dengan agen Azure File Sync terpasang tidak didukung dan dapat menyebabkan hasil yang tidak diharapkan. Pemasangan agen dan pendaftaran server akan terjadi setelah menyebarkan citra server dan menyelesaikan pengaturan mini sysprep.

Jika penjenjangan cloud diaktifkan pada titik akhir server, file yang ditingkatkan akan dilewati dan tidak diindeks oleh Windows Search. File yang tidak dijenjangkan akan diindeks dengan benar.

Solusi Hierarchical Storage Management (HSM) lainnya

Tidak ada solusi HSM lainnya yang akan digunakan dengan Azure File Sync.

Performa dan skalabilitas

Karena agen Azure File Sync berjalan pada mesin Windows Server yang tersambung ke berbagi file Azure, performa sinkronisasi yang efektif bergantung pada sejumlah faktor dalam infrastruktur Anda: Windows Server dan konfigurasi disk yang mendasarinya, bandwidth jaringan antara server dan penyimpanan Azure, ukuran file, ukuran himpunan data total, dan aktivitas pada himpunan data. Karena Azure File Sync berfungsi pada tingkat file, karakteristik performa solusi berbasis Azure File Sync lebih baik diukur dalam jumlah objek (file dan direktori) yang diproses per detik.

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 informasi selengkapnya, lihat Metrik performa Azure File Sync dan Target skala Azure File Sync

Identitas

Azure File Sync berfungsi dengan identitas berbasis AD standar Anda, tanpa penyiapan khusus selain menyiapkan sinkronisasi. Saat Anda menggunakan Azure File Sync, harapan umumnya adalah bahwa sebagian besar akses melalui server penyimpanan cache Azure File Sync, bukan melalui berbagi file Azure. Karena titik akhir server terletak di Windows Server, dan Windows Server telah mendukung AD dan ACL bergaya Windows untuk waktu yang lama, tidak ada yang diperlukan selain memastikan server file Windows yang terdaftar di Azure File Sync adalah gabungan domain. Azure File Sync akan menyimpan ACL pada file di berbagi file Azure, dan akan mereplikasinya ke semua titik akhir server.

Meskipun perubahan yang dilakukan langsung ke berbagi file Azure akan memerlukan waktu lebih lama untuk disinkronkan ke titik akhir server di grup sinkronisasi, sebaiknya Anda memastikan bahwa Anda juga dapat menerapkan izin AD di berbagi Anda langsung di cloud. Untuk melakukan ini, Anda harus bergabung dengan domain akun penyimpanan Anda ke AD lokal Anda, seperti bagaimana server file Windows Anda adalah gabungan domain. Untuk mempelajari selengkapnya tentang domain yang bergabung dengan akun penyimpanan Anda ke Direktori Aktif milik pelanggan, lihat Ringkasan Direktori Aktif Azure Files.

Penting

Domain yang bergabung dengan akun penyimpanan Anda ke Direktori Aktif tidak harus berhasil menyebarkan Azure File Sync. Ini adalah langkah opsional yang memungkinkan berbagi file Azure untuk memberlakukan ACL lokal saat pengguna memasang berbagi file Azure secara langsung.

Jaringan

Agen Azure File Sync berkomunikasi dengan Storage Sync Service, dan berbagi file Azure menggunakan protokol Azure File Sync REST dan protokol FileREST, yang keduanya selalu menggunakan HTTPS melalui port 443. SMB tidak pernah digunakan untuk mengunggah atau mengunduh data antara Server Windows dan berbagi file Azure. Karena sebagian besar organisasi mengizinkan lalu lintas HTTPS melalui port 443, sebagai persyaratan untuk mengunjungi sebagian besar situs web, konfigurasi jaringan khusus biasanya tidak diperlukan untuk menyebarkan Azure File Sync.

Berdasarkan kebijakan organisasi Anda atau persyaratan peraturan yang unik, Anda mungkin memerlukan komunikasi yang lebih ketat dengan Azure, dan oleh karena itu Azure File Sync menyediakan beberapa mekanisme untuk mengonfigurasi jaringan. Berdasarkan kebutuhan, Anda dapat:

  • Menyinkronkan tunnel dan lalu lintas pengunggahan/pengunduhan file melalui ExpressRoute atau Azure VPN.
  • Memanfaatkan fitur Azure Files dan Azure Networking seperti titik akhir layanan dan titik akhir privat.
  • Mengonfigurasi Azure File Sync untuk mendukung proksi di lingkungan Anda.
  • Membatasi aktivitas jaringan dari Azure File Sync.

Penting

Azure File Sync tidak mendukung perutean internet. Opsi perutean jaringan default, perutean Microsoft, didukung oleh Azure File Sync.

Untuk mempelajari Azure File Sync dan jaringan lebih lanjut, lihat Pertimbangan jaringan Azure File Sync.

Enkripsi

Saat menggunakan Azure File Sync, ada tiga lapisan enkripsi yang berbeda untuk dipertimbangkan: enkripsi pada penyimpanan Windows Server yang tidak aktif, enkripsi saat transit antara agen Azure File Sync dan Azure, dan enkripsi pada data yang tidak aktif berbagi file Azure.

Enkripsi Server Windows yang tidak aktif

Ada dua strategi untuk mengenkripsi data di Server Windows yang umumnya berfungsi dengan Azure File Sync: enkripsi di bawah sistem file sedemikian rupa sehingga sistem file dan semua data yang ditulis untuk sistem file akan dienkripsi, dan enkripsi dalam format file itu sendiri. Metode ini tidak terpisah satu sama lain; metode ini dapat digunakan bersama-sama jika diinginkan karena tujuan enkripsinya berbeda.

Untuk menyediakan enkripsi di bawah sistem file, Server Windows menyediakan kotak masuk BitLocker. BitLocker sangat transparan terhadap Azure File Sync. Alasan utama untuk menggunakan mekanisme enkripsi seperti BitLocker adalah untuk mencegah eksfiltrasi fisik data dari pusat data lokal Anda oleh seseorang yang mencuri disk dan untuk mencegah pemuatan sisi OS yang tidak sah untuk melakukan aktivitas baca/tulis yang tidak sah ke data Anda. Untuk mempelajari BitLocker lebih lanjut, lihat Ringkasan BitLocker.

Produk pihak ketiga yang bekerja serupa dengan BitLocker dalam hal kedudukannya berada di bawah volume NTFS juga akan bekerja sepenuhnya secara transparan dengan Azure File Sync.

Metode utama lainnya untuk mengenkripsi data adalah mengenkripsi aliran data file saat aplikasi menyimpan file. Beberapa aplikasi dapat melakukan ini secara native, namun ini biasanya tidak terjadi. Contoh metode untuk mengenkripsi aliran data file adalah Microsoft Azure Information Protection (AIP)/Azure Rights Management Services (Azure RMS)/Active Directory RMS. Alasan utama penggunaan mekanisme enkripsi seperti AIP/RMS adalah untuk mencegah penyelundupan data dari berbagi Anda oleh orang yang menyalinnya ke lokasi alternatif, seperti flash drive, atau mengirimnya melalui email ke orang yang tidak sah. Saat aliran data file dienkripsi sebagai bagian dari format file, file ini akan terus dienkripsi di berbagi file Azure.

Azure File Syn tidak beroperasi dengan NTFS Encrypted File System (NTFS EFS) atau solusi enkripsi pihak ketiga yang berada di atas sistem file tetapi di bawah aliran data file.

Enkripsi saat transit

Catatan

Layanan Azure File Sync akan menghapus dukungan untuk TLS1.0 dan 1.1 pada 1 Agustus 2020. Semua versi agen Azure File Sync yang didukung sudah menggunakan TLS1.2 secara default. Menggunakan versi TLS yang lebih lama dapat terjadi jika TLS1.2 dinonaktifkan pada server Anda atau proksi digunakan. Jika Anda menggunakan proksi, sebaiknya Anda memeriksa konfigurasi proksi. Wilayah layanan Azure File Sync yang ditambahkan setelah 1/5/2020 hanya akan mendukung TLS1.2 dan dukungan untuk TLS1.0 dan 1.1 akan dihapus dari wilayah yang ada pada 1 Agustus 2020. Untuk informasi selengkapnya, lihat panduan pemecahan masalah.

Agen Azure File Sync berkomunikasi dengan Storage Sync Service dan berbagi file Azure menggunakan protokol Azure File Sync REST dan protokol FileREST, yang keduanya selalu menggunakan HTTPS melalui port 443. Azure File Sync tidak mengirim permintaan yang tidak terenkripsi melalui HTTP.

Akun penyimpanan Azure berisi tombol sakelar untuk mewajibkan enkripsi saat transit yang diaktifkan secara default. Bahkan jika tombol di tingkat akun penyimpanan dinonaktifkan, yang berarti bahwa penyambungan yang tidak dienkripsi ke berbagi file Azure dapat dilakukan, Azure File Sync tetap akan menggunakan saluran terenkripsi untuk mengakses berbagi Anda.

Alasan utama untuk menonaktifkan enkripsi saat transit untuk akun penyimpanan adalah untuk mendukung aplikasi lama yang harus dijalankan sistem operasi yang lebih lama, seperti Windows Server 2008 R2 atau distribusi Linux yang lebih lama, untuk berkomunikasi dengan Akun Azure file share secara langsung. Jika aplikasi lama berkomunikasi dengan cache berbagi Windows Server, mengubah-ubah pengaturan ini tidak akan berpengaruh.

Sebaiknya Anda memastikan bahwa enkripsi data saat transit diaktifkan.

Untuk informasi selengkapnya tentang enkripsi saat transit, lihat mewajibkan transfer aman di penyimpanan Azure.

Enkripsi berbagi file Azure 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.

Tingkat penyimpanan

Azure Files menawarkan empat tingkat penyimpanan, premium, transaksi yang dioptimalkan, hot, dan cool yang berbeda untuk memungkinkan Anda menyesuaikan bagian Anda dengan persyaratan performa dan harga skenario Anda:

  • Premium: Berbagi file premium didukung oleh solid-state drive (SSD) dan memberikan performa tinggi dan latensi rendah yang konsisten, dalam milidetik satu digit untuk sebagian besar operasi IO, untuk beban kerja intensif IO. Berbagi file premium cocok untuk berbagai macam beban kerja seperti database, hosting situs web, dan lingkungan pengembangan. Berbagi file premium dapat digunakan dengan protokol Server Message Block (SMB) dan Network File System (NFS).
  • Transaksi dioptimalkan: Pembagian file yang dioptimalkan transaksi memungkinkan beban kerja transaksi yang berat yang tidak memerlukan latensi yang ditawarkan oleh berbagi file premium. Berbagi file yang dioptimalkan untuk transaksi, ditawarkan pada perangkat keras penyimpanan standar yang didukung oleh hard disk drive (HDD). Transaksi yang dioptimalkan secara historis disebut "standar", namun ini mengacu pada jenis media penyimpanan daripada tingkatan itu sendiri (hot dan cool juga merupakan tingkatan "standar", karena menggunakan perangkat keras penyimpanan standar).
  • Hot: Berbagi file hot menawarkan penyimpanan yang dioptimalkan untuk skenario berbagi file serba guna seperti berbagi tim. Berbagi file hot ditawarkan pada perangkat keras penyimpanan standar yang didukung oleh HDD.
  • Cool: Berbagi file cool menawarkan penyimpanan hemat biaya yang dioptimalkan untuk skenario penyimpanan arsip online. Berbagi file cool ditawarkan pada perangkat keras penyimpanan standar yang didukung oleh HDD.

Pembagian file premium diterapkan dalam jenis akun penyimpanan FileStorage dan hanya tersedia dalam model tagihan yang disediakan. Untuk informasi selengkapnya tentang model tagihan yang disediakan untuk berbagi file premium, lihat Memahami provisi untuk berbagi file premium. Berbagi file standar, termasuk transaksi yang dioptimalkan, berbagi file hot dan cool, disebarkan dalam jenis akun penyimpanan versi 2 (GPv2) serba guna, dan tersedia melalui tagihan bayar sesuai pemakaian.

Saat memilih tingkat penyimpanan untuk beban kerja, pertimbangkan performa dan persyaratan penggunaan Anda. Jika beban kerja Anda memerlukan latensi satu digit, atau Anda menggunakan media penyimpanan SSD di tempat, tingkat premium mungkin yang paling sesuai. Jika latensi rendah tidak terlalu menjadi perhatian, misalnya dengan pembagian tim yang dipasang di tempat dari Azure atau di-cache di tempat menggunakan Azure File Sync, penyimpanan standar mungkin lebih cocok dari perspektif biaya.

Setelah Anda membuat berbagi file di akun penyimpanan, Anda tidak dapat memindahkannya ke tingkat yang eksklusif untuk jenis akun penyimpanan yang berbeda. Misalnya, untuk memindahkan pembagian file yang dioptimalkan transaksi ke tingkat premium, Anda harus membuat berbagi file baru di akun penyimpanan FileStorage dan menyalin data dari berbagi asal 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.

Berbagi file disebarkan dalam akun penyimpanan GPv2 dapat dipindahkan di antara tingkat standar (transaksi dioptimalkan, panas, dan keren) tanpa membuat akun penyimpanan baru dan memigrasi data, tetapi Anda akan dikenakan biaya transaksi saat mengubah tingkat. Saat Anda memindahkan bagian dari tingkat yang lebih hot ke tingkat yang lebih cool, Anda akan dikenakan biaya transaksi tingkat tulis yang lebih cool untuk setiap file di bagian tersebut. Memindahkan berbagi file dari tingkat yang lebih cool ke tingkat yang lebih hot akan dikenakan biaya transaksi tingkat baca cool untuk setiap file yang dibagikan.

Lihat Memahami tagihan Azure Files untuk informasi selengkapnya.

Ketersediaan regional

Berbagi file standar dengan kapasitas 100 TiB memiliki batasan tertentu.

  • Saat ini, hanya akun penyimpanan berlebihan secara lokal (LRS) dan penyimpanan berlebihan secara zona (ZRS) yang didukung.
  • Setelah Anda mengaktifkan berbagi file besar, Anda tidak dapat mengonversi akun penyimpanan ke akun penyimpanan berlebihan secara geografis (GRS) atau penyimpanan berlebihan secara zona geografis (GZRS).
  • Setelah mengaktifkan berbagi file besar, Anda tidak dapat menonaktifkannya.

Ketersediaan wilayah Azure File Sycn

Untuk ketersediaan wilayah, lihat Produk yang tersedia menurut wilayah.

Wilayah berikut ini mengharuskan Anda meminta akses ke Azure Storage sebelum dapat menggunakan Azure File Sync dengannya:

  • Prancis Selatan
  • Afrika Selatan Barat
  • UAE Tengah

Untuk meminta akses untuk wilayah ini, ikuti proses dalam dokumen ini.

Redundansi

Untuk melindungi data dalam berbagi file Azure Anda dari kehilangan atau kerusakan data, semua berbagi file Azure menyimpan beberapa salinan setiap file saat sedang ditulis. Tergantung pada persyaratan beban kerja Anda, Anda dapat memilih tingkat redundansi tambahan. Azure Files saat ini mendukung opsi redundansi data berikut:

  • Penyimpanan yang redundan secara lokal (LRS) : Dengan LRS, setiap file disimpan tiga kali dalam kluster penyimpanan Azure. Ini melindungi dari hilangnya 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 berlebihan secara zona (ZRS) : Dengan ZRS, tiga salinan dari setiap file disimpan, namun salinan ini secara fisik diisolasi dalam tiga kelompok penyimpanan berbeda di zona ketersediaan Azure yang berbeda. Zona ketersediaan adalah lokasi fisik unik yang berada dalam wilayah Azure. Setiap zona terbuat dari satu atau beberapa pusat data yang dilengkapi dengan daya, pendinginan, dan jaringan yang independen. Sebuah tulisan ke penyimpanan tidak diterima sampai ditulis ke kluster penyimpanan di semua tiga zona ketersediaan.
  • Penyimpanan berlebihan secara geografis (GRS) : Dengan GRS, Anda memiliki dua wilayah, wilayah primer dan sekunder. File disimpan tiga kali dalam kluster penyimpanan Azure di wilayah primer. Penulisan direplikasi secara asinkron ke wilayah sekunder yang ditentukan Microsoft. GRS menyediakan enam salinan data Anda yang tersebar di antara dua wilayah Azure. Jika terjadi bencana besar seperti kehilangan permanen wilayah Azure karena bencana alam atau peristiwa serupa lainnya, Microsoft akan melakukan failover dan yang sekunder menjadi yang primer, melayani semua operasi. Karena peniruan antara wilayah primer dan sekunder tidak sinkron, jika terjadi bencana besar, data yang belum ditiru ke wilayah sekunder akan hilang. Anda juga dapat melakukan failover manual akun penyimpanan berlebihan secara geografis.
  • Penyimpanan berlebihan secara zona geografis (GZRS) : Anda dapat menganggap GZRS seolah-olah seperti ZRS tetapi dengan redundansi geo. Dengan GZRS, file disimpan tiga kali 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 versi tujuan umum 2 (GPv2) menyediakan dua opsi redundansi tambahan yang tidak didukung oleh Azure Files: membaca penyimpanan berlebihan secara geografis yang dapat diakses, sering disebut sebagai RA-GRS, dan membaca penyimpanan berlebihan secara zona geografis yang dapat diakses, sering disebut sebagai 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 disebar ke dalam akun penyimpanan berlebihan secara geografis atau zona geogafis yang dapat dibaca akan ditagih sebagai penyimpanan berlebihan secara geografis atau berlebihan secara zona geografis pada masing-masing.

Penting

Penyimpanan redundan geografis dan redundan zona geografis memiliki kemampuan untuk secara manual melakukan failover penyimpanan ke wilayah sekunder. Sebaiknya Anda tidak melakukan ini di luar bencana, saat Anda menggunakan Azure File Sync karena data kemungkinan besar bisa hilang. Jika terjadi bencana saat ingin memulai failover penyimpanan manual, Anda harus membuka kasus dukungan dengan Microsoft untuk mendapatkan Azure File Sync guna melanjutkan sinkronisasi dengan titik akhir sekunder.

Migration

Jika Anda sudah memiliki server file Windows 2012R2 atau lebih baru, Azure File Sync dapat langsung dipasang di tempat, tanpa perlu memindahkan data ke server baru. Jika berencana bermigrasi ke server file Windows baru sebagai bagian dari adopsi Azure File Sync, atau jika data Anda saat ini berada di Network Attached Storage (NAS), ada beberapa kemungkinan pendekatan migrasi dalam menggunakan Azure File Sync dengan data ini. Pendekatan migrasi yang harus dipilih bergantung pada lokasi keberadaan data Anda saat ini.

Lihat artikel Ringkasan migrasi Azure File dan berbagi file Azureyang berisi panduan mendetail untuk skenario Anda.

Antivirus

Karena antivirus bekerja dengan memindai file untuk kode berbahaya yang diketahui, produk antivirus dapat menyebabkan penarikan kembali file berjenjang, yang mengakibatkan biaya keluar yang tinggi. Pada agen Azure File Sync versi 4.0 dan yang lebih baru, file yang dijenjangkan memiliki set atribut Windows aman FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS. Sebaiknya hubungi vendor perangkat lunak untuk mempelajari cara mengonfigurasi solusi melewati pembacaan file dengan kumpulan atribut ini (banyak yang melakukannya secara otomatis).

Solusi antivirus bawaan Microsoft, Windows Defender dan System Center Endpoint Protection (SCEP), keduanya secara otomatis melewati pembacaan file yang memiliki kumpulan atribut ini. Kami telah mengujinya dan mengidentifikasi satu masalah kecil: ketika Anda menambahkan server ke grup sinkronisasi yang ada, file yang lebih kecil dari 800 byte dipanggil kembali (diunduh) pada server baru. File ini akan tetap berada di server baru dan tidak akan dijenjangkan karena tidak memenuhi persyaratan ukuran penjenjangan (>64kb).

Catatan

Vendor antivirus dapat memeriksa kompatibilitas antara produknya dan Azure File Sync menggunakan Suite Uji Kompatibilitas Antivirus Azure File Sync, yang dapat diunduh di Pusat Unduhan Microsoft.

Cadangan

Jika penjenjangan cloud diaktifkan, solusi yang langsung mencadangkan titik akhir server atau VM tempat titik akhir server berada tidak boleh digunakan. Penjenjangan cloud hanya berupa subset data yang disimpan di titik akhir sever, beserta himpunan data lengkap yang ada di berbagi file Azure. Bergantung pada solusi pencadangan yang digunakan, file berjenjang akan diabaikan dan tidak dicadangkan (karena file berjenjang memiliki set atribut FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS), atau file berjenjang akan dipanggil kembali ke disk, yang mengakibatkan biaya keluar yang tinggi. Sebaiknya gunakan solusi pencadangan cloud untuk mencadangkan berbagi file Azure secara langsung. Untuk informasi selengkapnya, lihat Tentang pencadangan berbagi file Azure, atau hubungi penyedia pencadangan untuk mengetahui apakah mereka mendukung pencadangan berbagi file Azure.

Jika Anda lebih suka menggunakan solusi pencadangan lokal, pencadangan harus dilakukan pada server di grup sinkronisasi yang telah menonaktifkan penjenjangan cloud. Saat melakukan pemulihan, gunakan opsi pemulihan tingkat volume atau tingkat file. File yang dipulihkan menggunakan opsi pemulihan tingkat file akan disinkronkan ke semua titik akhir dalam grup sinkronisasi dan file yang sudah ada akan diganti dengan versi yang dipulihkan dari cadangan. Pemulihan tingkat volume tidak akan menggantikan versi file yang lebih baru di berbagi file Azure atau titik akhir server lainnya.

Peringatan

Jika Anda perlu menggunakan Robocopy /B dengan agen Azure File Sync yang berjalan di server sumber atau target, tingkatkan agen Azure File Sync ke versi v12.0 atau yang lebih baru. Jika Robocopy /B dengan versi agen yang lebih lama dari v12.0 digunakan, kerusakan file berjenjang rusak selama penyalinan.

Catatan

Pemulihan bare-metal (BMR) dapat menyebabkan hasil tidak terduga dan saat ini tidak didukung.

Catatan

Dengan agen Azure File Sync versi 9, rekam jepret VSS (termasuk tab Versi Sebelumnya) sekarang didukung pada volume yang mengaktifkan penjenjangan cloud. Namun, Anda harus mengaktifkan kompatibilitas versi sebelumnya melalui PowerShell. Pelajari caranya.

Klasifikasi Data

Jika Anda telah memasang perangkat lunak klasifikasi data, mengaktifkan penjenjangan cloud dapat mengakibatkan peningkatan biaya karena dua alasan:

  1. Dengan penjenjangan cloud yang diaktifkan, file terbaru akan disimpan di cache secara lokal dan file terlama akan dijenjangkan ke berbagi file Azure di cloud. Jika klasifikasi data Anda memindai semua file secara teratur dalam berbagi, file yang dijenjangkan ke cloud harus dipanggil kembali setiap kali dipindai.

  2. Jika perangkat lunak klasifikasi data menggunakan metadata dalam aliran data file, file harus dipanggil kembali sepenuhnya agar perangkat lunak dapat melihat klasifikasinya.

Peningkatan jumlah penarikan ini dan jumlah data yang dipanggil kembali dapat meningkatkan biaya.

Kebijakan pembaruan agen Azure File Sync

Agen Azure File Sync diperbarui secara berkala untuk menambahkan fungsionalitas baru dan mengatasi masalah. Sebaiknya konfigurasikan Microsoft Update untuk mendapatkan pembaruan untuk agen Azure File Sync saat tersedia.

Versi agen utama vs. minor

  • Versi agen utama sering berisi fitur baru dan memiliki jumlah yang meningkat sebagai bagian pertama dari nomor versi. Contoh: *2.*.**
  • Versi agen minor juga disebut "patch" dan dirilis lebih sering daripada versi utama. Versi ini sering berisi perbaikan bug dan peningkatan yang lebih kecil, tetapi tidak ada fitur baru. Contoh: **.3.**

Meningkatkan jalur

Ada empat cara yang disetujui dan teruji untuk menginstal pembaruan agen Azure File Sync.

  1. (Disukai) Konfigurasikan Microsoft Update untuk mengunduh dan menginstal pembaruan agen secara otomatis.
    Kami selalu merekomendasikan untuk melakukan setiap pembaruan Azure File Sync untuk memastikan Anda memiliki akses ke perbaikan terbaru untuk agen server. Microsoft Update menjadikan proses ini mulus, dengan mengunduh dan menginstal pembaruan secara otomatis untuk Anda.
  2. Gunakan AfsUpdater.exe mengunduh dan menginstal pembaruan agen.
    AfsUpdater.exe terletak di direktori penginstalan agen. Klik dua kali executable untuk mengunduh dan menginstal pembaruan agen.
  3. Buat patch agen Azure File Sync yang ada menggunakan file patch Microsoft Update, atau executable .msp. Paket pembaruan Azure File Sync terbaru dapat diunduh dari Katalog Pembaruan Microsoft.
    Menjalankan executable .msp akan meningkatkan penginstalan Azure File Sync Anda dengan metode yang sama yang digunakan secara otomatis oleh Microsoft Update di jalur peningkatan sebelumnya. Menerapkan patch Microsoft Update akan melakukan peningkatan di tempat dari penginstalan Azure File Sync.
  4. Unduh penginstal agen Azure File Sync terbaru dari Pusat Unduhan Microsoft.
    Untuk meningkatkan penginstalan agen Azure File Sync yang sudah ada, hapus instalasi versi lama, lalu instal versi terbaru dari penginstal yang diunduh. Pendaftaran server, grup sinkronisasi, dan pengaturan lainnya dikelola oleh penginstal Azure File Sync.

Manajemen siklus hidup agen otomatis

Dengan agen versi 6, tim sinkronisasi file sudah memperkenalkan fitur peningkatan otomatis agen. Anda dapat memilih salah satu dari dua mode dan menentukan jendela pemeliharaan tempat peningkatan akan dicoba pada server. Fitur ini dirancang untuk membantu Anda dengan manajemen siklus hidup agen dengan menyediakan guardrail yang mencegah agen Anda berakhir atau memungkinkan pengaturan yang tidak rumit dan tetap terbaru.

  1. Pengaturan default akan mencoba mencegah agen berakhir. Dalam 21 hari sejak tanggal berakhir yang diposting dari agen, agen akan mencoba untuk meningkatkan sendiri. Ini akan memulai upaya untuk meningkatkan seminggu sekali dalam 21 hari sebelum berakhir dan di jendela pemeliharaan yang dipilih. Opsi ini tidak menghilangkan kebutuhan untuk mengambil patch Microsoft Update reguler.
  2. Secara opsional, Anda dapat memilih agen akan secara otomatis meningkatkan dirinya sendiri segera setelah versi agen baru tersedia (saat ini tidak berlaku untuk server berkluster). Pembaruan ini akan terjadi selama jendela pemeliharaan yang dipilih dan memungkinkan server Anda mendapatkan manfaat dari fitur dan peningkatan baru segera setelah tersedia secara umum. Ini adalah pengaturan yang direkomendasikan dan bebas khawatir yang akan menyediakan versi agen utama serta patch pembaruan reguler ke server Anda. Setiap agen yang dirilis memiliki kualitas GA. Jika Anda memilih opsi ini, Microsoft akan menerbangkan versi agen terbaru kepada Anda. Server berkluster dikecualikan. Setelah penerbangan selesai, agen juga akan tersedia di Microsoft Download Center aka.ms/AFS/agent.
Mengubah pengaturan peningkatan otomatis

Instruksi berikut menjelaskan cara mengubah pengaturan setelah Anda menyelesaikan penginstal, jika Anda perlu membuat perubahan.

Buka konsol PowerShell dan navigasi ke direktori tempat Anda menginstal agen sinkronisasi, lalu impor cmdlet server. Secara default ini akan terlihat seperti ini:

cd 'C:\Program Files\Azure\StorageSyncAgent'
Import-Module -Name .\StorageSync.Management.ServerCmdlets.dll

Anda dapat menjalankan Get-StorageSyncAgentAutoUpdatePolicy untuk memeriksa pengaturan kebijakan saat ini dan menentukan apakah Anda ingin mengubahnya.

Untuk mengubah pengaturan kebijakan saat ini ke jalur pembaruan yang tertunda, Anda bisa menggunakan:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

Untuk mengubah pengaturan kebijakan saat ini ke jalur pembaruan segera, Anda bisa menggunakan:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest

Siklus hidup agen dan jaminan manajemen perubahan

Azure File Sync adalah layanan cloud, yang terus memperkenalkan fitur dan penyempurnaan baru. Ini berarti versi agen Azure File Sync tertentu hanya dapat didukung untuk waktu yang terbatas. Untuk memfasilitasi penyebaran Anda, aturan berikut menjamin Anda memiliki cukup waktu dan pemberitahuan untuk mengakomodasi pembaruan/peningkatan agen dalam proses manajemen perubahan Anda:

  • Versi agen utama didukung setidaknya selama enam bulan sejak tanggal rilis awal.
  • Kami menjamin ada tumpang tindih setidaknya tiga bulan di antara dukungan versi agen utama.
  • Peringatan dikeluarkan untuk server terdaftar menggunakan agen yang akan segera berakhir setidaknya tiga bulan sebelum berakhir. Anda dapat memeriksa apakah server terdaftar menggunakan versi agen yang lebih lama di bawah bagian server terdaftar dari Layanan Sinkronisasi Penyimpanan.
  • Masa pakai versi agen kecil terikat ke versi utama terkait. Misalnya, ketika agen versi 3.0 dirilis, agen versi 2.* semuanya akan diatur untuk berakhir bersama-sama.

Catatan

Menginstal versi agen dengan peringatan kedaluwarsa akan menampilkan peringatan, tetapi berhasil. Mencoba menginstal atau menyambungkan dengan versi agen yang berakhir tidak didukung dan akan diblokir.

Langkah berikutnya