Merencanakan penyebaran Azure File Sync

  • Artikel

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

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

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 pada volume yang sama jika namespace layanannya 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 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.

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 awan (berbagi berkas Azure) secara langsung, perubahan terlebih dahulu harus ditemukan oleh pekerjaan deteksi perubahan Azure File Sync. Pekerjaan deteksi perubahan dimulai untuk titik akhir cloud saja setiap 24 jam sekali. Untuk informasi lebih lanjut, 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 seringkali yang terbaik adalah hanya menyebarkan satu Storage Sync Service dan mendaftarkan semua server di dalamnya.

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-nya. Membuat paket 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.

    Perhatikan batasan IOPS akun penyimpanan saat menyebarkan berbagi file Azure. Idealnya, Anda harus memetakan berbagi file 1:1 dengan akun penyimpanan. Namun, ini mungkin tidak selalu dimungkinkan karena berbagai batasan dan pembatasan, baik dari organisasi Anda maupun dari Azure. Ketika tidak mungkin hanya memiliki satu berbagi file yang disebarkan dalam satu akun penyimpanan, pertimbangkan berbagi mana yang akan sangat aktif dan berbagi mana yang akan kurang aktif untuk memastikan bahwa berbagi file terpanas tidak dimasukkan ke akun penyimpanan yang sama bersama-sama.

    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.

Skenario dan pertimbangan sinkronisasi file umum

# Skenario sinkronisasi Didukung Pertimbangan (atau batasan) Solusi (atau solusi)
1 Server file dengan beberapa disk/volume dan beberapa berbagi ke berbagi file Azure target yang sama (konsolidasi) No Berbagi file Azure target (titik akhir cloud) hanya mendukung sinkronisasi dengan satu grup sinkronisasi.

Grup sinkronisasi hanya mendukung satu titik akhir server per server terdaftar.		 1) Mulailah dengan menyinkronkan satu disk (volume akarnya) untuk menargetkan berbagi file Azure. Dimulai dengan disk/volume terbesar akan membantu persyaratan penyimpanan lokal. Konfigurasikan tingkatan cloud untuk menjenjangkan semua data ke cloud, sehingga mengosongkan ruang pada disk server file. Pindahkan data dari volume/berbagi lain ke volume saat ini yang sedang disinkronkan. Lanjutkan langkah satu per satu hingga semua data dijenjangkan ke cloud/dimigrasikan.
2) Targetkan satu volume akar (disk) pada satu waktu. Gunakan tingkatan cloud untuk menjenjangkan semua data untuk menargetkan berbagi file Azure. Hapus titik akhir server dari grup sinkronisasi, buat ulang titik akhir dengan volume/disk akar berikutnya, sinkronkan, dan ulangi prosesnya. Catatan: Penginstalan ulang agen mungkin diperlukan.
3) Merekomendasikan penggunaan beberapa berbagi file Azure target (akun penyimpanan yang sama atau berbeda berdasarkan persyaratan performa)
2 Server file dengan volume tunggal dan beberapa berbagi ke berbagi file Azure target yang sama (konsolidasi) Ya Tidak dapat memiliki beberapa titik akhir server per sinkronisasi server terdaftar ke berbagi file Azure target yang sama (sama seperti di atas) Sinkronkan akar volume yang menyimpan beberapa berbagi atau folder tingkat atas. Lihat Berbagi konsep pengelompokan dan Sinkronisasi volume untuk informasi selengkapnya.
3 Server file dengan beberapa berbagi dan/atau volume ke beberapa berbagi file Azure di bawah akun penyimpanan tunggal (pemetaan berbagi 1:1) Ya Satu instans Windows Server (atau kluster) dapat menyinkronkan hingga 30 berbagi file Azure.

Akun penyimpanan adalah target skala untuk performa. IOPS dan throughput dibagikan di seluruh berbagi file.

Simpan jumlah item per grup sinkronisasi dalam 100 juta item (file dan folder) per berbagi. Idealnya yang terbaik adalah tinggal di bawah 20 atau 30 juta per saham.		 1) Gunakan beberapa grup sinkronisasi (jumlah grup sinkronisasi = jumlah berbagi file Azure untuk disinkronkan).
2) Hanya 30 berbagi yang dapat disinkronkan dalam skenario ini pada satu waktu. Jika Anda memiliki lebih dari 30 berbagi di server file tersebut, gunakan Konsep pengelompokan Berbagi dan Sinkronisasi volume untuk mengurangi jumlah folder tingkat akar atau atas di sumbernya.
3) Gunakan server File Sync tambahan lokal dan pisahkan/pindahkan data ke server ini untuk mengatasi batasan pada server Windows sumber.
4 Server file dengan beberapa berbagi dan/atau volume ke beberapa berbagi file Azure di bawah akun penyimpanan yang berbeda (pemetaan berbagi 1:1) Ya Satu instans Windows Server (atau kluster) dapat menyinkronkan hingga 30 berbagi file Azure (akun penyimpanan yang sama atau berbeda).

Simpan jumlah item per grup sinkronisasi dalam 100 juta item (file dan folder) per berbagi. Idealnya yang terbaik adalah tinggal di bawah 20 atau 30 juta per saham.		 Pendekatan yang sama seperti di atas
5 Beberapa server file dengan satu (volume akar atau berbagi) ke berbagi file Azure target yang sama (konsolidasi) No Grup sinkronisasi tidak dapat menggunakan titik akhir cloud (berbagi file Azure) yang sudah dikonfigurasi di grup sinkronisasi lain.

Meskipun grup sinkronisasi dapat memiliki titik akhir server di server file yang berbeda, file tidak dapat berbeda.		 Ikuti panduan dalam Skenario # 1 di atas dengan pertimbangan tambahan untuk menargetkan satu server file pada satu waktu.

Membuat tabel pemetaan

Diagram yang menunjukkan contoh tabel pemetaan. Unduh file tersebut 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.


Ikon excel yang mengatur konteks unduhan. Unduh templat pemetaan namespace layanan.

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 yang cepat.

Persyaratan sistem operasi

Azure File Sync didukung dengan versi Windows Server berikut:

Versi SKU yang didukung Opsi penyebaran yang didukung
Windows Server 2022 Azure, Pusat Data, Standar, dan IoT Lengkap dan Inti
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

*Memerlukan pengunduhan dan penginstalan Windows Management Framework (WMF) 5.1. Paket yang sesuai untuk diunduh dan dipasang untuk Windows Server 2012 R2 adalah Win8.1AndW2K12R2-KB*******-x64.msu.

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, baik fisik atau virtual, dengan setidaknya satu CPU, minimal 2 GiB memori dan volume yang terpasang secara lokal yang diformat dengan sistem file NTFS.

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, kami tidak menyarankan untuk 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 file tujuan umum umum, di mana ukuran file rata-rata 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 disarankan. 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 alokasikan lebih banyak memori hingga sinkronisasi awal selesai. Ini tidak diperlukan tetapi mungkin 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.

Cmdlet evaluasi

Sebelum menyebarkan Azure File Sync, Anda harus mengevaluasi apakah 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. Pemeriksaan ini mencakup sebagian besar tetapi tidak semua fitur yang disebutkan di bawah ini; kami sarankan Anda membaca seluruh bagian ini dengan hati-hati 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 melalui 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 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 Dilewati
Link simbolik Dilewati
Titik pemasangan Didukung sebagian Titik pemasangan mungkin merupakan akar titik akhir server, tetapi dilewati jika terkandung dalam namespace titik akhir server.
Persimpangan Dilewati Misalnya, Folder Sistem File Terdistribusi DfrsrPrivate dan DFSRoots.
Ulangi poin Dilewati
Kompresi NTFS Didukung sebagian Azure File Sync tidak mendukung titik akhir server yang terletak pada volume yang memiliki direktori informasi volume sistem (SVI) yang dikompresi.
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 disinkronkan
. SystemShareInformation Folder untuk disinkronkan di berbagi file Azure

Catatan

Meskipun Azure File Sync mendukung sinkronisasi file database, database bukan beban kerja yang baik untuk solusi sinkronisasi (termasuk Azure File Sync) karena file log dan database perlu disinkronkan bersama-sama, dan mereka bisa tidak sinkron karena berbagai alasan yang dapat menyebabkan kerusakan database.

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

Saat berencana menggunakan Azure File Sync, pertimbangkan berapa banyak ruang kosong yang Anda butuhkan pada disk lokal yang Anda rencanakan untuk mengaktifkan 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

    Untuk sepenuhnya mendapat manfaat dari penjenjangan cloud, disarankan untuk menggunakan ukuran kluster NTFS yang lebih kecil (kurang dari 64KiB) karena setiap file berjenjang menempati kluster. Selain itu, ruang yang ditempati oleh file berjenjang dialokasikan oleh NTFS. Oleh karena itu, ruang tersebut tidak akan muncul di antarmuka pengguna mana pun.

  2. Metadata sinkronisasi menempati ukuran kluster per item. (1 juta file + 100.000 direktori) * Ukuran kluster 4 KiB = 4.400.000 KiB (4,4 GiB)
  3. 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)
  4. 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". Untuk informasi selengkapnya mengenai cara mengonfigurasi peran "Server File untuk penggunaan umum" pada Kluster Failover, lihat Menyebarkan server file berkluster dua simpul.
  2. Satu-satunya skenario yang didukung oleh Azure File Sync adalah Kluster Failover Server Windows dengan Disk Berkluster
  3. Pengklusteran Failover tidak didukung pada "Scale-Out File Server for application data" (SOFS) atau pada Clustered Shared Volumes (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 2022, Windows Server 2019, dan Windows Server 2016
Deduplikasi Data didukung terlepas dari apakah penjenjangan cloud diaktifkan atau dinonaktifkan di satu atau beberapa titik akhir server pada volume untuk Windows Server 2016, Windows Server 2019, dan Windows Server 2022. 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 disimpulkan.

Catatan

Untuk mendukung Deduplikasi Data pada volume dengan tingkatan cloud diaktifkan di Windows Server 2019, pembaruan Windows KB4520062 - Oktober 2019 atau pembaruan rollup bulanan yang lebih baru harus dipasang.

Windows Server 2012 R2
Azure File Sync tidak mendukung Deduplikasi Data dan tingkatan 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 MinimumFileAgeDays Deduplikasi Data, jika file belum berjenjang.

    • 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, Windows Server 2019, dan Windows Server 2022, 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, Windows Server 2019, atau Windows Server 2022).
    • 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 Namespaces (DFS-N): Azure File Sync didukung sepenuhnya dengan implementasi DFS-N. Anda dapat menginstal agen Azure File Sync di satu atau beberapa server file untuk menyinkronkan data antara titik akhir server dan titik akhir cloud, lalu menggunakan DFS-N untuk menyediakan layanan namespace. Untuk informasi selengkapnya, lihat Gambaran umum DFS Namespaces dan DFS Namespaces dengan Azure Files.

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 bermigrasi 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 baca-saja DFS-R.
  3. Hanya titik akhir server tunggal yang dapat tumpang tindih dengan lokasi DFS-R. Beberapa titik akhir server yang tumpang tindih dengan lokasi DFS-R aktif lainnya dapat menyebabkan konflik.

Untuk informasi selengkapnya, lihat Ringkasan Replikasi DFS.

Sysprep

Menggunakan sysprep di server yang menginstal agen Azure File Sync tidak didukung dan dapat menyebabkan hasil yang tidak terduga. Pemasangan agen dan pendaftaran server akan terjadi setelah menyebarkan citra server dan menyelesaikan pengaturan mini sysprep.

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

Catatan

Klien Windows akan menyebabkan pengenalan saat mencari berbagi file jika pengaturan Selalu cari nama file dan konten diaktifkan pada mesin klien. Pengaturan ini dinonaktifkan secara default.

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 Azure file share, 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 segera terdeteksi dan direplikasi seperti perubahan pada titik akhir server. Azure Files tidak memiliki pemberitahuan perubahan atau penjurifikasian, 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 sebagian besar akses melalui server penembolokan 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 memakan waktu lebih lama untuk disinkronkan ke titik akhir server di grup sinkronisasi, Anda mungkin juga ingin memastikan bahwa Anda dapat memberlakukan izin AD pada berbagi file Anda secara langsung di cloud juga. 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 diperlukan untuk berhasil menyebarkan Azure File Sync. Ini adalah langkah opsional ketat 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.

Penting

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

Berdasarkan kebijakan organisasi Anda atau persyaratan peraturan unik, Anda mungkin memerlukan komunikasi yang lebih ketat dengan Azure, dan oleh karena itu Azure File Sync menyediakan beberapa mekanisme bagi Anda 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.

Tip

Jika Anda ingin berkomunikasi dengan berbagi file Azure Anda melalui SMB tetapi port 445 diblokir, pertimbangkan untuk menggunakan SMB over QUIC, yang menawarkan "SMB VPN" konfigurasi nol untuk akses SMB ke berbagi file Azure Anda menggunakan protokol transportasi QUIC melalui port 443. Meskipun Azure Files tidak secara langsung mendukung SMB melalui QUIC, Anda dapat membuat cache ringan berbagi file Azure Anda di VM Windows Server 2022 Azure Edition menggunakan Azure File Sync. Untuk mempelajari selengkapnya tentang opsi ini, lihat SMB melalui QUIC dengan 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 saling eksklusif; mereka dapat digunakan bersama-sama jika diinginkan karena tujuan enkripsi berbeda.

Untuk menyediakan enkripsi di bawah sistem file, Server Windows menyediakan kotak masuk BitLocker. BitLocker sepenuhnya transparan untuk 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 memuat samping OS yang tidak sah untuk melakukan 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 mungkin melakukan ini secara asli, 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 Sync 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 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 mendukung TLS1.2. 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 dua tingkat penyimpanan media yang berbeda, SSD dan HDD, yang memungkinkan Anda menyesuaikan berbagi Anda dengan persyaratan performa dan harga skenario Anda:

  • SSD (Premium): Berbagi file premium digunakan oleh solid-state drive (SSD) dan memberikan performa tinggi yang konsisten dan latensi rendah, 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). 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 premium menawarkan SLA ketersediaan yang lebih tinggi daripada berbagi file standar (lihat "Tingkat Premium Azure Files").

  • HDD (Standar): Berbagi file standar menggunakan hard disk drive (HDD) dan menyediakan opsi penyimpanan hemat biaya untuk berbagi file tujuan umum. Berbagi file standar disebarkan dalam jenis akun penyimpanan tujuan umum versi 2 (GPv2). Untuk informasi tentang SLA, lihat halaman perjanjian tingkat layanan Azure (lihat "Akun Penyimpanan"). Berbagi file standar menggunakan model bayar sesuai penggunaan yang menyediakan harga berbasis penggunaan. Tingkat akses berbagi file memungkinkan Anda menyesuaikan biaya penyimpanan terhadap biaya IOPS untuk mengoptimalkan total tagihan Anda:

    • Berbagi file yang dioptimalkan transaksi menawarkan harga transaksi biaya terendah untuk beban kerja berat transaksi yang tidak memerlukan latensi rendah yang ditawarkan oleh berbagi file premium. Disarankan saat memigrasikan data ke Azure Files.
    • Berbagi file panas menawarkan penyimpanan seimbang dan harga transaksi untuk beban kerja yang memiliki ukuran yang baik dari keduanya.
    • Berbagi file dingin menawarkan harga penyimpanan yang paling hemat biaya untuk beban kerja intensif 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 secara lokal, tingkat premium mungkin yang paling cocok. 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 membuat berbagi file di akun penyimpanan, Anda tidak dapat memindahkannya ke tingkat eksklusif ke 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.

Lihat Memahami tagihan Azure Files untuk informasi selengkapnya.

Ketersediaan regional

Saat ini, berbagi file standar dengan berbagi file besar diaktifkan (kapasitas hingga 100 TiB) memiliki batasan tertentu.

  • Hanya akun penyimpanan redundan lokal (LRS) dan penyimpanan redundan zona (ZRS) yang didukung.
  • Setelah mengaktifkan berbagi file besar di akun penyimpanan, Anda tidak dapat mengonversi akun penyimpanan untuk menggunakan penyimpanan geo-redundan (GRS) atau penyimpanan geo-zona-redundan (GZRS).
  • Setelah mengaktifkan berbagi file besar, Anda tidak dapat menonaktifkannya.

Jika Anda ingin menggunakan GRS atau GZRS dengan berbagi file Azure SMB standar, lihat Geo-redundansi Azure Files untuk pratinjau berbagi file besar.

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 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.

Penting

Penyimpanan redundan geografis dan redundan zona geografis memiliki kemampuan untuk melakukan failover penyimpanan secara manual ke wilayah sekunder. Kami menyarankan agar Anda tidak melakukan ini di luar bencana saat Anda menggunakan Azure File Sync karena peningkatan kemungkinan kehilangan data. Jika terjadi bencana di mana Anda ingin memulai failover penyimpanan manual, Anda harus membuka kasus dukungan dengan Microsoft untuk mendapatkan Azure File Sync untuk 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 Anda berencana untuk bermigrasi ke server file Windows baru sebagai bagian dari mengadopsi Azure File Sync, atau jika data Anda saat ini terletak di Network Attached Storage (NAS), ada beberapa kemungkinan pendekatan migrasi untuk menggunakan Azure File Sync dengan data ini. Pendekatan migrasi mana yang harus Anda pilih tergantung pada tempat data Anda saat ini berada.

Lihat artikel gambaran umum migrasi Azure File Sync dan berbagi file Azure untuk panduan terperinci.

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. File berjenjang memiliki set atribut FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS Windows yang aman, dan kami sarankan untuk berkonsultasi dengan vendor perangkat lunak Anda untuk mempelajari cara mengonfigurasi solusi mereka untuk melewati membaca file dengan set 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-file ini akan tetap berada di server baru dan tidak akan dijenjangkan karena tidak memenuhi persyaratan ukuran tingkatan (>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. Tergantung pada solusi cadangan yang digunakan, file berjenjang akan dilewati dan tidak dicadangkan (karena mereka memiliki FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS set atribut), atau mereka 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 menonaktifkan tingkatan cloud dan memastikan tidak ada file berjenjang. 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 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.

Catatan

Pemulihan bare-metal (BMR), pemulihan VM, pemulihan sistem (pemulihan OS bawaan Windows), dan pemulihan tingkat file dengan versi berjenjangnya (ini terjadi ketika perangkat lunak cadangan mencadangkan file berjenjang alih-alih file lengkap) dapat menyebabkan hasil yang tidak terduga dan saat ini tidak didukung saat penjenjangan cloud diaktifkan. Snapshot 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 memiliki perangkat lunak klasifikasi data yang terinstal, mengaktifkan tingkatan cloud dapat mengakibatkan peningkatan biaya karena dua alasan:

  1. Dengan penjenjangan cloud diaktifkan, file terpanas Anda di-cache secara lokal, dan file paling keren Anda 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. Kami rekomendasikan untuk memperbarui agen Azure File Sync karena versi baru telah tersedia.

Versi agen utama vs. minor

  • Versi agen utama sering berisi fitur baru dan memiliki jumlah yang meningkat sebagai bagian pertama dari nomor versi. Misalnya, 14.0.0.0
  • 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. Misalnya, 14.1.0.0

Meningkatkan jalur

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

  1. Gunakan fitur peningkatan otomatis agen Azure File Sync untuk menginstal pembaruan agen. Agen Azure File Sync akan meningkatkan otomatis. Anda dapat memilih untuk menginstal agen versi terbaru saat tersedia atau memperbarui ketika agen yang ada saat ini diinstal mendekati kedaluwarsa. Untuk mempelajari selengkapnya, lihat Manajemen siklus hidup agen otomatis.
  2. Konfigurasikan Microsoft Update untuk mengunduh dan menginstal pembaruan agen secara otomatis. Kami merekomendasikan untuk melakukan setiap pembaruan Azure File Sync guna memastikan Anda memiliki akses ke perbaikan terbaru ke agen server. Microsoft Update membuat proses ini mulus dengan mengunduh dan menginstal pembaruan secara otomatis untuk Anda.
  3. 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. Bergantung pada versi rilis, Anda mungkin perlu memulai ulang server.
  4. Patch agen Azure File Sync yang sudah ada menggunakan file patch Microsoft Update, atau .msp yang dapat dijalankan. Paket pembaruan Azure File Sync terbaru dapat diunduh dari Katalog Microsoft Update. Menjalankan executable .msp akan meningkatkan penginstalan Azure File Sync Anda dengan metode yang sama yang digunakan secara otomatis oleh Microsoft Update. Menerapkan patch Microsoft Update akan melakukan peningkatan di tempat dari penginstalan Azure File Sync.
  5. Unduh alat 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.

Catatan

Penurunan tingkat agen Azure File Sync tidak didukung. Versi baru sering kali mencakup perubahan yang melanggar jika dibandingkan dengan versi lama, membuat proses penurunan tingkat tidak didukung. Jika Anda mengalami masalah dengan versi agen Anda saat ini, hubungi untuk mendukung atau meningkatkan ke rilis terbaru yang tersedia.

Manajemen siklus hidup agen otomatis

Agen Azure File Sync akan meningkatkan otomatis. 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 navigasikan 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 -Day <day> -Hour <hour>

Siklus hidup agen dan jaminan manajemen perubahan

Azure File Sync adalah layanan cloud yang terus memperkenalkan fitur dan peningkatan 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 14.0.0.0 diatur kedaluwarsa, agen versi 14.*.*.* semuanya akan diatur untuk kedaluwarsa bersama-sama.

Catatan

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

Langkah berikutnya