Gunakan Data Box untuk migrasi dari Network Attached Storage (NAS) ke penyebaran {i>cloud Artikel migrasi ini adalah salah satu dari beberapa yang berlaku untuk kata kunci NAS, Azure File Sync, dan Azure Data Box. Periksa apakah artikel ini berlaku untuk skenario Anda:
- Sumber data: Network Attached Storage (NAS)
- Rute migrasi: NAS ⇒ Data Box ⇒ berbagi Azure ⇒ sinkronkan dengan Windows Server
- File penembolokan lokal: Ya, tujuan akhirnya adalah penyebaran Azure File Sync
Jika skenario Anda berbeda, bacalah tabel panduan migrasi dengan saksama.
Azure File Sync berfungsi pada lokasi Direct Attached Storage (DAS). Tidak mendukung sinkronisasi ke lokasi Network Attached Storage (NAS).
Jadi Anda perlu memigrasi file Anda. Artikel ini memandu Anda melalui perencanaan dan implementasi dari migrasi tersebut.
Berlaku untuk
Jenis berbagi File
SMB
NFS
Berbagi file standar (GPv2), LRS/ZRS
Berbagi file standar (GPv2), GRS/GZRS
Berbagi file premium (FileStorage), LRS/ZRS
Tujuan migrasi
Tujuannya adalah untuk memindahkan berbagi Anda yang ada di {i>appliance cloud
Gambaran umum migrasi
Proses migrasi terdiri dari beberapa fase. Anda perlu:
- Menyebarkan akun penyimpanan Azure dan berbagi {i>file
- Menyebarkan komputer lokal yang sedang menjalankan Windows Server.
- Mengonfigurasi Azure File Sync.
- Memigrasi {i>file
- Mengambil langkah langsung.
Bagian yang berikut menjelaskan fase dari proses migrasi secara terperinci.
Tip
Jika Anda kembali ke artikel ini, gunakan navigasi di sisi kanan layar untuk beralih ke fase migrasi tempat Anda sebelumnya.
Fase 1: Tentukan berapa banyak berbagi {i>file
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
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.
Unduh templat pemetaan namespace layanan.
Fase 2: Sebar sumber daya penyimpanan Azure
Dalam fase ini, perhatikan tabel pemetaan dari Fase 1 dan gunakan untuk menyediakan jumlah akun penyimpanan Azure yang tepat dan berbagi file di dalamnya.
Berbagi file Azure disimpan di cloud di akun penyimpanan Azure.
Tingkat pertimbangan performa lainnya berlaku di sini.
Jika Anda memiliki berbagi yang sangat aktif (berbagi yang digunakan oleh banyak pengguna dan/atau aplikasi), dua berbagi file Azure mungkin mencapai batas performa akun penyimpanan.
Praktik terbaiknya adalah menyebarkan akun penyimpanan dengan masing-masing satu berbagi file.
Anda dapat mengumpulkan beberapa berbagi file Azure ke akun penyimpanan yang sama jika Anda memiliki berbagi file arsip atau Anda mengharapkan aktivitas harian yang rendah di dalamnya.
Pertimbangan ini lebih berlaku untuk akses cloud langsung (melalui Azure VM) daripada Azure File Sync. Jika Anda berencana untuk hanya menggunakan Azure File Sync pada pembagian ini, beberapa dapat dikelompokkan ke dalam satu akun penyimpanan Azure.
Jika Anda telah membuat daftar berbagi, Anda harus memetakannya masing-masing ke akun penyimpanan yang akan digunakan.
Pada fase sebelumnya, Anda menentukan jumlah berbagi yang sesuai. Pada langkah ini, Anda memiliki pemetaan akun penyimpanan untuk berbagi file. Sekarang sebarkan jumlah akun penyimpanan Azure yang tepat dengan jumlah berbagi file Azure yang sesuai di dalamnya.
Pastikan wilayah setiap akun penyimpanan Anda sama dan cocok dengan wilayah sumber Storage Sync Service yang telah Anda sebarkan.
Perhatian
Jika Anda membuat berbagi file Azure yang memiliki batas 100 TiB, berbagi ini hanya dapat menggunakan opsi penyimpanan redundan lokal atau redundansi penyimpanan redundan zona. Pertimbangkan kebutuhan redundansi penyimpanan Anda sebelum menggunakan berbagi file 100 TiB.
Secara default, berbagi file Azure tetap dibuat dengan batas 5 TiB. Ikuti langkah-langkah di Membuat berbagi file Azure untuk membuat berbagi file besar.
Pertimbangan lain saat Anda menyebarkan akun penyimpanan adalah redundansi Azure Storage. Lihat Opsi redundansi Azure Storage.
Nama-nama sumber daya Anda juga penting. Misalnya, jika Anda mengelompokkan beberapa berbagi file untuk departemen SDM ke dalam akun penyimpanan Azure, Anda harus memberi nama akun penyimpanan dengan tepat. Demikian pula, saat menamai berbagi file Azure, Anda harus menggunakan nama yang mirip dengan yang digunakan untuk rekan lokalnya.
Fase 3: Tentukan berapa banyak appliance Azure Data Box yang Anda butuhkan
Mulailah langkah ini hanya setelah Anda menyelesaikan fase sebelumnya. Sumber daya penyimpanan Azure Anda (akun penyimpanan dan berbagi file) harus dibuat saat ini. Saat Anda memesan Data Box, Anda perlu menentukan akun penyimpanan tempat Data Box memindahkan data.
Pada fase ini, Anda perlu memetakan hasil rencana migrasi dari fase sebelumnya ke batasan opsi Data Box yang tersedia. Pertimbangan ini akan membantu Anda membuat rencana untuk opsi Data Box mana yang harus dipilih dan berapa banyak yang dibutuhkan untuk memindahkan berbagi NAS Anda ke berbagi file Azure.
Untuk menentukan berapa banyak perangkat dan jenis yang dibutuhkan, pertimbangkan batasan penting ini:
- Appliance Azure Data Box apa pun dapat memindahkan data hingga ke 10 akun penyimpanan.
- Setiap opsi Data Box hadir dengan kapasitasnya sendiri yang dapat digunakan. Lihat Opsi Data Box.
Lihat rencana migrasi Anda untuk menemukan jumlah akun penyimpanan yang Anda putuskan untuk dibuat dan melihat berbaginya masing-masing. Lalu lihat ukuran dari setiap berbagi ini di NAS Anda. Menggabungkan informasi ini akan memungkinkan Anda mengoptimalkan dan memutuskan appliance mana harus mengirim data ke akun penyimpanan mana. Dua perangkat Data Box dapat memindahkan file ke akun penyimpanan yang sama, tetapi jangan pecah konten dari satu berbagi file ke dua Data Box.
Opsi Data Box
Untuk migrasi standar, pilih satu atau kombinasi dari opsi Data Box berikut ini:
- Data Box Disk.
Microsoft akan mengirimi Anda satu atau lima disk SSD yang memiliki kapasitas masing-masing 8 TiB, untuk total maksimum 40 TiB. Kapasitas yang dapat digunakan berkurang sekitar 20 persen karena enkripsi dan overhead sistem file. Untuk informasi lebih lanjut, lihat Dokumentasi Data Box Disk.
- Data Box.
Opsi ini adalah yang paling umum. Microsoft akan mengirimkan appliance{i>
Dokumentasi Data Box.
- Data Box Heavy.
Opsi ini menampilkan appliance{i>
Dokumentasi Data Box Heavy.
Fase 4: Tentukan instans Windows Server lokal yang sesuai
Saat Anda menunggu perangkat Azure Data Box tiba, Anda dapat mulai meninjau kebutuhan satu atau beberapa instans Windows Server yang akan Anda gunakan dengan Azure File Sync.
- Buat instans Windows Server 2022 (minimal, Windows Server 2012 R2) sebagai komputer virtual atau server fisik. Kluster failover Windows Server juga didukung.
- Provisikan atau tambahkan Direct Attached Storage. NAS tidak didukung.
Konfigurasi sumber daya (komputasi dan RAM) instans Windows Server yang Anda terapkan sebagian besar bergantung pada jumlah {i>file
Pelajari cara mengukur instans Windows Server berdasarkan jumlah item yang perlu Anda sinkronkan.
Catatan
Artikel yang ditautkan sebelumnya menyajikan tabel dengan rentang untuk memori server (RAM). Anda dapat menggunakan angka di ujung bawah rentang untuk {i>server
Fase 5: Salin file ke Data Box Anda
Saat Data Box tiba, Anda perlu menyiapkannya dengan konektivitas jaringan tak terbatas ke appliance NAS Anda. Ikuti dokumentasi penyiapan untuk jenis Data Box yang Anda pesan:
Alat salin Data Box mungkin tersedia tergantung pada jenis Data Box. Pada titik ini, kami tidak menyarankan alat itu untuk migrasi ke berbagi file Azure karena ia tidak menyalin file Anda ke Data Box dengan keakuratan penuh. Alih-alih, gunakan Robocopy.
Ketika Data Box Anda tiba, ia akan memiliki berbagi SMB yang telah disediakan sebelumnya untuk setiap akun penyimpanan yang Anda tentukan saat Anda memesannya.
- Jika file Anda pergi ke berbagi file Azure premium, akan ada satu berbagi SMB per akun penyimpanan “File storage” premium.
- Jika file Anda pergi ke akun penyimpanan standar, akan ada tiga berbagi SMB per akun penyimpanan standar (GPv1 dan GPv2). Hanya berbagi file yang berakhiran dengan
_AzFiles yang relevan untuk migrasi Anda. Abaikan segala berbagi blok dan blob halaman.
Ikuti langkah-langkah dalam dokumentasi Azure Data Box:
- Sambungkan ke Data Box.
- Salin data ke Data Box.
Anda dapat menggunakan Robocopy (ikuti instruksi di bawah) atau layanan penyalinan data Data Box baru.
- Siapkan Data Box Anda untuk pengunggahan ke Azure.
Tip
Sebagai alternatif untuk Robocopy, Data Box telah membuat layanan penyalinan data. Anda dapat menggunakan layanan ini untuk memuat file ke Data Box Anda dengan keakuratan penuh. Ikuti tutorial layanan penyalinan data ini dan pastikan untuk mengatur target berbagi file Azure yang benar.
Dokumentasi Data Box menentukan perintah Robocopy. Perintah itu tidak cocok untuk mempertahankan keakuratan penuh file dan folder. Alih-alih, gunakan perintah ini:
robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
Mengalihkan
Makna
/MT:nMemungkinkan Robocopy untuk menjalankan multiutas. Default untuk n adalah 8. Maksimum adalah 128 utas. Sementara jumlah utas yang tinggi membantu memenuhi bandwidth yang tersedia, itu tidak berarti migrasi Anda akan selalu lebih cepat dengan lebih banyak utas. Pengujian dengan Azure Files menunjukkan antara 8 dan 20 memperlihatkan kinerja yang seimbang untuk menjalankan salinan awal. Proses /MIR berikutnya secara progresif dipengaruhi oleh komputasi yang tersedia vs bandwidth jaringan yang tersedia. Untuk proses selanjutnya, cocokkan nilai jumlah utas Anda lebih dekat dengan jumlah inti prosesor dan jumlah utas per inti Anda. Pertimbangkan apakah core perlu dicadangkan untuk tugas lain yang mungkin dilakukan oleh server produksi. Pengujian dengan Azure Files telah menunjukkan bahwa hingga 64 utas menghasilkan performa yang baik, tetapi hanya jika prosesor Anda dapat membuatnya tetap hidup pada saat yang sama.
/R:nJumlah coba lagi maksimum untuk file yang gagal disalin pada upaya pertama. Robocopy akan mencoba n waktu sebelum file secara permanen gagal menjalankan salinan. Anda dapat mengoptimalkan kinerja yang Anda jalankan: Pilih nilai dua atau tiga jika Anda yakin masalah batas waktu menyebabkan kegagalan di masa lalu. Ini mungkin lebih umum melalui tautan WAN. Pilih tidak mencoba ulang atau nilai satu jika Anda yakin file gagal menyalin karena sedang digunakan secara aktif. Mencoba lagi beberapa detik kemudian mungkin tidak cukup waktu untuk status file yang digunakan untuk berubah. Pengguna atau aplikasi yang menahan file terbuka mungkin memerlukan waktu beberapa jam lebih lama. Dalam hal ini, menerima file tidak disalin dan menangkapnya di salah satu rencana Anda, Robocopy berjalan berikutnya, mungkin akhirnya berhasil dalam menyalin file dengan sukses. Hal itu membantu eksekusi saat ini untuk menyelesaikan lebih cepat tanpa diperpanjang oleh banyak percobaan ulang yang akhirnya berakhir di sebagian besar kegagalan salinan karena file masih terbuka melewati batas waktu percobaan ulang.
/W:nMenentukan waktu tunggu Robocopy sebelum mencoba menyalin file yang tidak berhasil disalin selama upaya sebelumnya. n adalah jumlah detik untuk menunggu di antara coba lagi. /W:n sering digunakan bersama dengan /R:n.
/BMenjalankan Robocopy dalam mode yang sama dengan yang akan digunakan aplikasi cadangan. Pengalih ini memungkinkan Robocopy memindahkan file yang izinnya tidak dimiliki pengguna saat ini. Sakelar cadangan bergantung pada menjalankan perintah Robocopy di konsol tinggi administrator atau jendela PowerShell. Jika Anda menggunakan Robocopy untuk Azure Files, pastikan Anda memasang berbagi file Azure menggunakan kunci akses akun penyimpanan vs. identitas domain. Jika tidak, pesan kesalahan mungkin tidak secara intuitif mengarahkan Anda ke resolusi masalah.
/MIR(Mencerminkan sumber ke target.) Memungkinkan Robocopy menyalin hanya delta antara sumber serta target. Subdirektori kosong akan disalin. Item (file atau folder) yang telah berubah atau tidak ada pada target akan disalin. Item yang ada pada target tetapi tidak pada sumber akan dihapus menyeluruh (dihapus) dari target. Saat Anda menggunakan pengalih ini, cocokkan struktur folder sumber dan target. Pencocokan berarti menyalin dari tingkat sumber dan folder yang benar ke tingkat folder yang cocok pada target. Hanya dengan begitu salinan "catch up" bisa berhasil. Saat sumber dan target tidak cocok, penggunaan /MIR akan menyebabkan penghapusan dan penyalinan ulang dalam skala besar.
/ITMemastikan fidelitas dipertahankan dalam skenario cermin tertentu.
Misalnya, jika file mengalami perubahan ACL dan pembaruan atribut di antara dua proses Robocopy, file tersebut akan ditandai sebagai tersembunyi. Tanpa /IT, perubahan ACL mungkin terlewatkan oleh Robocopy dan tidak ditransfer ke lokasi target.
/COPY:[copyflags]Fidelitas salinan file. Default: /COPY:DAT. Bendera salinan: D= Data, A= Atribut, T= Tanda waktu, S= Keamanan = ACL NTFS, O= Informasi pemilik, U= Informasi audit. Informasi audit tidak dapat disimpan dalam berbagi file Azure.
/DCOPY:[copyflags]Fidelitas untuk salinan direktori. Default: /DCOPY:DA. Bendera salinan: D= Data, A= Atribut, T= Tanda waktu.
/NPMenentukan bahwa perkembangan penyalinan untuk setiap file dan folder tidak akan ditampilkan. Menampilkan kemajuan secara signifikan menurunkan performa salinan.
/NFLMenentukan bahwa nama file tidak dicatat. Meningkatkan performa salinan.
/NDLMenentukan bahwa nama direktori tidak dicatat. Meningkatkan performa salinan.
/XDMenentukan direktori yang akan dikecualikan. Saat menjalankan Robocopy pada akar volume, pertimbangkan untuk mengecualikan System Volume Informationfolder tersembunyi. Jika digunakan seperti yang dirancang, semua informasi di sana spesifik untuk volume yang tepat pada sistem yang tepat ini dan dapat dibangun kembali sesuai permintaan. Menyalin informasi ini tidak akan membantu di cloud atau ketika data pernah disalin kembali ke volume Windows lain. Meninggalkan konten ini di belakang tidak dianggap kehilangan data.
/UNILOG:<file name>Menulis status ke file log sebagai Unicode. (Menimpa log yang ada.)
/LHanya untuk file uji coba
yang hanya akan dicantumkan. Mereka tidak akan disalin, tidak dihapus, dan tidak waktu dicap. Sering digunakan dengan /TEE untuk keluaran konsol. Bendera dari skrip sampel, seperti /NP, /NFL, dan /NDL, mungkin perlu dihapus untuk mendapatkan hasil pengujian yang terdokumentasi dengan baik.
/LFSMHanya untuk target dengan penyimpanan bertingkat. Tidak didukung ketika tujuan adalah berbagi SMB jarak jauh.
Menentukan bahwa Robocopy beroperasi dalam "mode ruang kosong rendah." Sakelar ini hanya berguna untuk target dengan penyimpanan berjenjang yang mungkin kehabisan kapasitas lokal sebelum Robocopy selesai. Ini ditambahkan khusus untuk digunakan dengan target yang diaktifkan untuk tingkatan cloud Azure File Sync. Ini dapat digunakan secara terpisah dari Azure File Sync. Dalam mode ini, Robocopy akan berhenti sejenak setiap kali salinan file akan menyebabkan ruang bebas volume tujuan berada di bawah nilai "lantai". Nilai ini dapat ditentukan oleh bentuk /LFSM:n bendera. Parameter n ditentukan dalam basis 2: nKB, nMB atau nGB. /LFSMJika ditentukan tanpa nilai lantai eksplisit, lantai diatur ke 10 persen dari ukuran volume tujuan. Mode ruang bebas rendah tidak kompatibel dengan /MT, /EFSRAW, atau /ZB. Dukungan untuk /B ditambahkan di Windows Server 2022. Silakan lihat bagian Windows Server 2022 dan RoboCopy LFSM di bawah ini untuk informasi selengkapnya, termasuk detail mengenai bug dan solusi terkait.
/ZGunakan salin file dengan hati-hati
dalam mode hidupkan ulang. Pengalih ini hanya disarankan dalam lingkungan jaringan yang tidak stabil. Ini secara signifikan mengurangi performa salinan karena pengelogan ekstra.
/ZBGunakan dengan hati-hati
Menggunakan mode hidupkan ulang. Jika akses ditolak, opsi ini menggunakan mode pencadangan. Opsi ini secara signifikan mengurangi performa salinan karena titik pemeriksaan.
Penting
Sebaiknya gunakan Windows Server 2022. Saat menggunakan Windows Server 2019, pastikan pada tingkat patch terbaru atau setidaknya pembaruan OS KB5005103 terpasang. Ini berisi perbaikan penting untuk skenario Robocopy tertentu.
Fase 6: Menerapkan sumber daya {i>cloud
Sebelum Anda melanjutkan dengan panduan ini, tunggu sampai semua {i>file file
Untuk menyelesaikan langkah ini, Anda memerlukan info masuk langganan Azure Anda.
Sumber daya inti yang akan dikonfigurasi untuk Sinkronisasi File Azure disebut Storage Sync Service. Disarankan agar Anda hanya menggunakan satu untuk semua server yang menyinkronkan kumpulan file yang sama sekarang atau di masa mendatang. Buat beberapa Storage Sync Service hanya jika Anda memiliki kumpulan server berbeda yang tidak boleh bertukar data. Misalnya, Anda mungkin memiliki server yang tidak boleh menyinkronkan berbagi file Azure yang sama. Jika tidak, menggunakan Storage Sync Service tunggal adalah praktik terbaik.
Pilih wilayah Azure untuk Storage Sync Service yang dekat dengan lokasi Anda. Semua sumber daya cloud lainnya harus disebarkan di wilayah yang sama. Untuk menyederhanakan manajemen, buat grup sumber daya baru di langganan Anda yang menampung sumber daya sinkronisasi dan penyimpanan.
Untuk informasi selengkapnya, lihat bagian tentang menyebarkan Storage Sync Service di artikel tentang menyebarkan Sinkronisasi File Azure. Ikuti hanya bagian artikel ini. Akan ada tautan ke bagian lain dari artikel di langkah-langkah selanjutnya.
Fase 7: Terapkan alat Azure File Sync
Di bagian ini, Anda memasang agen Azure File Sync pada instans Windows Server Anda.
Panduan penyebaran menjelaskan bahwa Anda perlu menonaktifkan Konfigurasi Keamanan Tingkat Tinggi Internet Explorer. Langkah keamanan ini tidak berlaku untuk Azure File Sync. Menonaktifkannya memungkinkan Anda mengautentikasi ke Azure tanpa masalah.
Buka PowerShell. Pasang modul PowerShell yang diperlukan dengan menggunakan perintah berikut. Pastikan untuk memasang modul lengkap dan penyedia NuGet ketika Anda diminta untuk melakukannya.
Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync
Jika Anda memiliki masalah menjangkau internet dari server Anda, sekarang saatnya untuk menyelesaikannya. Azure File Sync menggunakan koneksi jaringan yang tersedia ke internet. Mengharuskan server proxy untuk menjangkau internet juga didukung. Anda dapat mengonfigurasi proksi di seluruh komputer sekarang atau, selama penginstalan agen, tentukan proksi yang hanya akan digunakan oleh Azure File Sync.
Jika mengonfigurasi proxy berarti Anda perlu membuka firewall untuk server, pendekatan tersebut mungkin dapat diterima oleh Anda. Di akhir penginstalan server, setelah Anda menyelesaikan pendaftaran server, laporan konektivitas jaringan akan menunjukkan titik akhir URL yang tepat di Azure yang perlu dikomunikasikan dengan Azure File Sync untuk wilayah yang Anda pilih. Laporan ini juga memberi tahu Anda mengapa komunikasi diperlukan. Anda dapat menggunakan laporan untuk mengunci firewall di sekitar server ke URL tertentu.
Anda juga dapat mengambil pendekatan yang lebih konservatif ketika Anda tidak membuka firewall lebar-lebar. Sebagai gantinya, Anda dapat membatasi server untuk berkomunikasi dengan ruang nama DNS tingkat lebih tinggi. Untuk informasi selengkapnya, lihat Proksi Azure File Sync dan pengaturan firewall. Ikuti praktik terbaik jaringan Anda sendiri.
Di akhir wisaya pemasangan wisaya server, wisaya pendaftaran server akan terbuka. Daftarkan server ke sumber daya Azure Storage Sync Service Anda dari yang lebih lama.
Langkah-langkah ini dijelaskan secara lebih rinci dalam panduan penyebaran, yang mencakup modul PowerShell yang harus Anda pasang terlebih dahulu: Pemasangan agen Azure File Sync.
Gunakan agen terbaru. Anda dapat mengunduhnya dari Pusat Unduhan Microsoft: Azure File Sync Agent.
Setelah penginstalan dan pendaftaran server berhasil, Anda dapat mengonfirmasi bahwa Anda telah berhasil menyelesaikan langkah ini. Buka sumber daya Storage Sync Service di portal Microsoft Azure. Di menu sebelah kiri, buka Server terdaftar. Anda akan melihat server Anda tercantum di sana.
Fase 8: Konfigurasikan Azure File Sync pada instans Windows Server
Instans Windows Server lokal Anda yang terdaftar harus siap dan terhubung ke internet untuk proses ini.
Langkah ini menyatukan semua sumber daya dan folder yang telah Anda siapkan di instans Windows Server Anda selama langkah sebelumnya.
- Masuk ke portal Azure.
- Temukan sumber daya Storage Sync Service Anda.
- Buat grup sinkronisasi baru dalam sumber daya Storage Sync Service untuk setiap berbagi file Azure. Di terminologi Sinkronisasi File Azure, berbagi file Azure akan menjadi titik akhir cloud di topologi sinkronisasi yang Anda jelaskan dengan pembuatan grup sinkronisasi. Saat Anda membuat grup sinkronisasi, beri nama yang familier sehingga Anda mengenali kumpulan file mana yang disinkronkan di sana. Pastikan Anda mereferensikan berbagi file Azure dengan nama yang cocok.
- Setelah Anda membuat grup sinkronisasi, baris untuk grup tersebut akan muncul dalam daftar grup sinkronisasi. Pilih nama (tautan) untuk menampilkan konten grup sinkronisasi. Anda akan melihat berbagi file Azure di Titik akhir Cloud.
- Temukan tombol Tambahkan Titik Akhir Server. Folder di server lokal yang telah Anda provisikan akan menjadi jalur untuk titik akhir server ini.
Aktifkan fitur penjenjangan cloud dan pilih Namespace hanya di bagian unduhan awal.
Penting
Tingkatan {i>cloud cloudnamespace disk cloud cloud
Untuk semua berbagi file Azure / lokasi server yang perlu Anda konfigurasikan untuk sinkronisasi, ulangi langkah-langkah untuk membuat grup sinkronisasi dan menambahkan folder server yang cocok sebagai titik akhir server. Tunggu sampai sinkronisasi {i>namespace
Catatan
Setelah Anda membuat titik akhir {i>serverfile file namespace cloud servernamespace
Fase 9: Tunggu {i>namespace
Sebelum Anda melanjutkan langkah selanjutnya dari migrasi Anda, tunggu sampai {i>servernamespace cloudfile server file
Untuk menentukan apakah {i>server
Cari peristiwa 9102 terbaru.
ID Peristiwa 9102 dicatat ketika sesi sinkronisasi selesai. Dalam teks peristiwa, ada bidang untuk petunjuk sinkronisasi unduhan. (HResult harus nol, dan file perlu diunduh.)
Anda ingin melihat dua peristiwa berturut-turut dari jenis ini, dengan konten ini, untuk memastikan bahwa {i>server namespace
Fase 10: Jalankan Robocopy dari NAS Anda
Setelah {i>server namespace cloud
Dalam langkah ini, Anda akan menjalankan pekerjaan RoboCopy untuk sinkronisasi berbagi {i>cloud churn
Peringatan
Karena perilaku Robocopy yang mengalami kemunduran di Windows Server 2019, sakelar Robocopy /MIR tidak kompatibel dengan direktori target bertingkat. Anda tidak dapat menggunakan Windows Server 2019 atau klien Windows 10 untuk fase migrasi ini. Gunakan Robocopy pada instans Windows Server 2016 menengah.
Berikut adalah pendekatan migrasi dasar:
- Jalankan Robocopy dari appliance NAS Anda untuk sinkronisasi instans Windows Server Anda.
- Gunakan Azure File Sync untuk sinkronisasi berbagi {i>file
Jalankan salinan lokal pertama ke folder target di Windows Server Anda:
- Identifikasi lokasi pertama di appliance NAS Anda.
- Identifikasi folder yang cocok pada instans Windows Server yang sudah memiliki Azure File Sync yang dikonfigurasi di dalamnya.
- Mulai penyalinan menggunakan Robocopy.
Perintah RoboCopy berikut hanya akan menyalin perbedaan ({i>file
robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
Mengalihkan
Makna
/MT:nMemungkinkan Robocopy untuk menjalankan multiutas. Default untuk n adalah 8. Maksimum adalah 128 utas. Sementara jumlah utas yang tinggi membantu memenuhi bandwidth yang tersedia, itu tidak berarti migrasi Anda akan selalu lebih cepat dengan lebih banyak utas. Pengujian dengan Azure Files menunjukkan antara 8 dan 20 memperlihatkan kinerja yang seimbang untuk menjalankan salinan awal. Proses /MIR berikutnya secara progresif dipengaruhi oleh komputasi yang tersedia vs bandwidth jaringan yang tersedia. Untuk proses selanjutnya, cocokkan nilai jumlah utas Anda lebih dekat dengan jumlah inti prosesor dan jumlah utas per inti Anda. Pertimbangkan apakah core perlu dicadangkan untuk tugas lain yang mungkin dilakukan oleh server produksi. Pengujian dengan Azure Files telah menunjukkan bahwa hingga 64 utas menghasilkan performa yang baik, tetapi hanya jika prosesor Anda dapat membuatnya tetap hidup pada saat yang sama.
/R:nJumlah coba lagi maksimum untuk file yang gagal disalin pada upaya pertama. Robocopy akan mencoba n waktu sebelum file secara permanen gagal menjalankan salinan. Anda dapat mengoptimalkan kinerja yang Anda jalankan: Pilih nilai dua atau tiga jika Anda yakin masalah batas waktu menyebabkan kegagalan di masa lalu. Ini mungkin lebih umum melalui tautan WAN. Pilih tidak mencoba ulang atau nilai satu jika Anda yakin file gagal menyalin karena sedang digunakan secara aktif. Mencoba lagi beberapa detik kemudian mungkin tidak cukup waktu untuk status file yang digunakan untuk berubah. Pengguna atau aplikasi yang menahan file terbuka mungkin memerlukan waktu beberapa jam lebih lama. Dalam hal ini, menerima file tidak disalin dan menangkapnya di salah satu rencana Anda, Robocopy berjalan berikutnya, mungkin akhirnya berhasil dalam menyalin file dengan sukses. Hal itu membantu eksekusi saat ini untuk menyelesaikan lebih cepat tanpa diperpanjang oleh banyak percobaan ulang yang akhirnya berakhir di sebagian besar kegagalan salinan karena file masih terbuka melewati batas waktu percobaan ulang.
/W:nMenentukan waktu tunggu Robocopy sebelum mencoba menyalin file yang tidak berhasil disalin selama upaya sebelumnya. n adalah jumlah detik untuk menunggu di antara coba lagi. /W:n sering digunakan bersama dengan /R:n.
/BMenjalankan Robocopy dalam mode yang sama dengan yang akan digunakan aplikasi cadangan. Pengalih ini memungkinkan Robocopy memindahkan file yang izinnya tidak dimiliki pengguna saat ini. Sakelar cadangan bergantung pada menjalankan perintah Robocopy di konsol tinggi administrator atau jendela PowerShell. Jika Anda menggunakan Robocopy untuk Azure Files, pastikan Anda memasang berbagi file Azure menggunakan kunci akses akun penyimpanan vs. identitas domain. Jika tidak, pesan kesalahan mungkin tidak secara intuitif mengarahkan Anda ke resolusi masalah.
/MIR(Mencerminkan sumber ke target.) Memungkinkan Robocopy menyalin hanya delta antara sumber serta target. Subdirektori kosong akan disalin. Item (file atau folder) yang telah berubah atau tidak ada pada target akan disalin. Item yang ada pada target tetapi tidak pada sumber akan dihapus menyeluruh (dihapus) dari target. Saat Anda menggunakan pengalih ini, cocokkan struktur folder sumber dan target. Pencocokan berarti menyalin dari tingkat sumber dan folder yang benar ke tingkat folder yang cocok pada target. Hanya dengan begitu salinan "catch up" bisa berhasil. Saat sumber dan target tidak cocok, penggunaan /MIR akan menyebabkan penghapusan dan penyalinan ulang dalam skala besar.
/ITMemastikan fidelitas dipertahankan dalam skenario cermin tertentu.
Misalnya, jika file mengalami perubahan ACL dan pembaruan atribut di antara dua proses Robocopy, file tersebut akan ditandai sebagai tersembunyi. Tanpa /IT, perubahan ACL mungkin terlewatkan oleh Robocopy dan tidak ditransfer ke lokasi target.
/COPY:[copyflags]Fidelitas salinan file. Default: /COPY:DAT. Bendera salinan: D= Data, A= Atribut, T= Tanda waktu, S= Keamanan = ACL NTFS, O= Informasi pemilik, U= Informasi audit. Informasi audit tidak dapat disimpan dalam berbagi file Azure.
/DCOPY:[copyflags]Fidelitas untuk salinan direktori. Default: /DCOPY:DA. Bendera salinan: D= Data, A= Atribut, T= Tanda waktu.
/NPMenentukan bahwa perkembangan penyalinan untuk setiap file dan folder tidak akan ditampilkan. Menampilkan kemajuan secara signifikan menurunkan performa salinan.
/NFLMenentukan bahwa nama file tidak dicatat. Meningkatkan performa salinan.
/NDLMenentukan bahwa nama direktori tidak dicatat. Meningkatkan performa salinan.
/XDMenentukan direktori yang akan dikecualikan. Saat menjalankan Robocopy pada akar volume, pertimbangkan untuk mengecualikan System Volume Informationfolder tersembunyi. Jika digunakan seperti yang dirancang, semua informasi di sana spesifik untuk volume yang tepat pada sistem yang tepat ini dan dapat dibangun kembali sesuai permintaan. Menyalin informasi ini tidak akan membantu di cloud atau ketika data pernah disalin kembali ke volume Windows lain. Meninggalkan konten ini di belakang tidak dianggap kehilangan data.
/UNILOG:<file name>Menulis status ke file log sebagai Unicode. (Menimpa log yang ada.)
/LHanya untuk file uji coba
yang hanya akan dicantumkan. Mereka tidak akan disalin, tidak dihapus, dan tidak waktu dicap. Sering digunakan dengan /TEE untuk keluaran konsol. Bendera dari skrip sampel, seperti /NP, /NFL, dan /NDL, mungkin perlu dihapus untuk mendapatkan hasil pengujian yang terdokumentasi dengan baik.
/LFSMHanya untuk target dengan penyimpanan bertingkat. Tidak didukung ketika tujuan adalah berbagi SMB jarak jauh.
Menentukan bahwa Robocopy beroperasi dalam "mode ruang kosong rendah." Sakelar ini hanya berguna untuk target dengan penyimpanan berjenjang yang mungkin kehabisan kapasitas lokal sebelum Robocopy selesai. Ini ditambahkan khusus untuk digunakan dengan target yang diaktifkan untuk tingkatan cloud Azure File Sync. Ini dapat digunakan secara terpisah dari Azure File Sync. Dalam mode ini, Robocopy akan berhenti sejenak setiap kali salinan file akan menyebabkan ruang bebas volume tujuan berada di bawah nilai "lantai". Nilai ini dapat ditentukan oleh bentuk /LFSM:n bendera. Parameter n ditentukan dalam basis 2: nKB, nMB atau nGB. /LFSMJika ditentukan tanpa nilai lantai eksplisit, lantai diatur ke 10 persen dari ukuran volume tujuan. Mode ruang bebas rendah tidak kompatibel dengan /MT, /EFSRAW, atau /ZB. Dukungan untuk /B ditambahkan di Windows Server 2022. Silakan lihat bagian Windows Server 2022 dan RoboCopy LFSM di bawah ini untuk informasi selengkapnya, termasuk detail mengenai bug dan solusi terkait.
/ZGunakan salin file dengan hati-hati
dalam mode hidupkan ulang. Pengalih ini hanya disarankan dalam lingkungan jaringan yang tidak stabil. Ini secara signifikan mengurangi performa salinan karena pengelogan ekstra.
/ZBGunakan dengan hati-hati
Menggunakan mode hidupkan ulang. Jika akses ditolak, opsi ini menggunakan mode pencadangan. Opsi ini secara signifikan mengurangi performa salinan karena titik pemeriksaan.
Penting
Sebaiknya gunakan Windows Server 2022. Saat menggunakan Windows Server 2019, pastikan pada tingkat patch terbaru atau setidaknya pembaruan OS KB5005103 terpasang. Ini berisi perbaikan penting untuk skenario Robocopy tertentu.
Jika Anda menyediakan lebih sedikit penyimpanan di instans Windows Server daripada yang digunakan oleh {i>fileappliance cloudtingkatan cloud akan dimulai dan file tingkat yang telah berhasil disinkronkan. Cloud tiering akan menghasilkan ruang yang cukup untuk melanjutkan penyalinan dari appliance NAS. Pemeriksaan tingkatan {i>cloud disk
Robocopy mungkin perlu memindahkan lebih banyak {i>file file /MIR akan memastikan bahwa hanya delta yang dipindahkan. Setelah delta dipindahkan, pekerjaan menghidupkan ulang tidak perlu memindahkan {i>file
Ambil jalan pintas
Saat Anda menjalankan perintah RoboCopy untuk pertama kalinya, pengguna dan aplikasi Anda masih mengakses {i>file file
Proses pertama adalah tentang memindahkan sebagian besar data {i>churn cloud
- Bandwidth unggahan.
- Kecepatan jaringan lokal dan seberapa optimal jumlah alur RoboCopy yang cocok.
- Jumlah item ({i>file
Setelah proses awal selesai, jalankan kembali perintah tersebut.
Robocopy akan selesai lebih cepat untuk kedua kalinya Anda menjalankannya untuk berbagi. Hanya perlu membawa perubahan yang terjadi sejak eksekusi terakhir. Anda dapat menjalankan pekerjaan berulang untuk berbagi yang sama.
Saat Anda menilai bahwa waktu hentinya dapat diterima, Anda harus menghapus akses pengguna ke berbagi yang berbasis NAS Anda. Anda dapat melakukannya melalui langkah apa pun yang dapat mencegah pengguna mengubah struktur dan konten {i>file namespace
Jalankan Robocopy untuk terakhir kalinya. Proses ini akan menemukan perubahan apa pun, yang mungkin terlewat sebelumnya.
Berapa lama langkah terakhir ini bergantung pada kecepatan pemindaian Robocopy. Anda dapat memperkirakan waktu (yang sebanding dengan waktu henti Anda) dengan mengukur berapa lama eksekusi alur sebelumnya.
Buat berbagi di folder Windows Server dan kemungkinan sesuaikan penyebaran DFS-N Anda untuk mengarahkannya ke sana. Pastikan untuk mengatur izin akses level berbagi yang sama seperti di berbagi NAS SMB Anda. Jika Anda memiliki NAS kelas {i>enterprise file metadata
- Membuat kembali pengguna-pengguna ini sebagai pengguna lokal Windows Server.
- Memetakan SID yang sudah ada yang dipindahkan Robocopy ke instans Windows Server Anda ke SID pengguna lokal Windows Server baru.
Anda telah selesai memigrasikan berbagi atau grup berbagi ke dalam akar atau volume yang sama (bergantung pada pemetaan Anda dari Fase 1).
Anda dapat mencoba menjalankan beberapa salinan ini secara paralel. Sebaiknya proses cakupan dari satu berbagi {i>file
Opsi tidak digunakan lagi: "transfer data offline"
Sebelum agen Azure File Sync versi 13 dirilis, integrasi Data Box dilakukan melalui proses yang disebut "transfer data offline". Proses ini tidak digunakan lagi, dan Anda tidak dapat lagi membuat titik akhir server dalam mode "transfer data offline". Dengan agen versi 13, ini diganti dengan langkah-langkah yang jauh lebih sederhana dan lebih cepat yang diuraikan dalam artikel ini.
Pemecahan Masalah
Masalah yang paling umum adalah bahwa perintah Robocopy gagal dengan “Volume penuh” di sisi Windows Server. Cloud tiering bertindak sekali setiap jam untuk mengevakuasi konten dari disk Windows Server lokal yang telah disinkronkan. Tujuannya adalah untuk mencapai 99% ruang kosong pada volume Anda.
Biarkan kemajuan sinkronisasi dan cloud tiering mengosongkan ruang disk. Anda dapat mengamatinya di File Explorer di Instans Windows Server Anda.
Ketika instans Windows Server Anda memiliki kapasitas tersedia yang cukup, jalankan kembali perintah untuk menyelesaikan masalah. Tidak ada yang putus dalam situasi ini. Anda bisa meneruskan dengan keyakinan. Ketidaknyamanan menjalankan perintah lagi adalah satu-satunya konsekuensi.
Untuk memecahkan masalah Azure File Sync, lihat artikel yang tercantum di bagian berikutnya.
Langkah berikutnya
Artikel berikut ini akan membantu Anda memahami opsi tingkat lanjut dan praktik terbaik untuk Azure Files dan Azure File Sync.
Artikel migrasi ini adalah salah satu dari beberapa yang berlaku untuk kata kunci NAS, Azure File Sync, dan Azure Data Box. Periksa apakah artikel ini berlaku untuk skenario Anda:
- Sumber data: Network Attached Storage (NAS)
- Rute migrasi: NAS ⇒ Data Box ⇒ berbagi Azure ⇒ sinkronkan dengan Windows Server
- File penembolokan lokal: Ya, tujuan akhirnya adalah penyebaran Azure File Sync
Jika skenario Anda berbeda, bacalah tabel panduan migrasi dengan saksama.
Azure File Sync berfungsi pada lokasi Direct Attached Storage (DAS). Tidak mendukung sinkronisasi ke lokasi Network Attached Storage (NAS). Jadi Anda perlu memigrasi file Anda. Artikel ini memandu Anda melalui perencanaan dan implementasi dari migrasi tersebut.
Berlaku untuk
| Jenis berbagi File | SMB | NFS |
|---|---|---|
| Berbagi file standar (GPv2), LRS/ZRS | |
|
| Berbagi file standar (GPv2), GRS/GZRS | |
|
| Berbagi file premium (FileStorage), LRS/ZRS | |
|
Tujuan migrasi
Tujuannya adalah untuk memindahkan berbagi Anda yang ada di {i>appliance
Gambaran umum migrasi
Proses migrasi terdiri dari beberapa fase. Anda perlu:
- Menyebarkan akun penyimpanan Azure dan berbagi {i>file
- Menyebarkan komputer lokal yang sedang menjalankan Windows Server.
- Mengonfigurasi Azure File Sync.
- Memigrasi {i>file
- Mengambil langkah langsung.
Bagian yang berikut menjelaskan fase dari proses migrasi secara terperinci.
Tip
Jika Anda kembali ke artikel ini, gunakan navigasi di sisi kanan layar untuk beralih ke fase migrasi tempat Anda sebelumnya.
Fase 1: Tentukan berapa banyak berbagi {i>file
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
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.
Unduh templat pemetaan namespace layanan.
Fase 2: Sebar sumber daya penyimpanan Azure
Dalam fase ini, perhatikan tabel pemetaan dari Fase 1 dan gunakan untuk menyediakan jumlah akun penyimpanan Azure yang tepat dan berbagi file di dalamnya.
Berbagi file Azure disimpan di cloud di akun penyimpanan Azure.
Tingkat pertimbangan performa lainnya berlaku di sini.
Jika Anda memiliki berbagi yang sangat aktif (berbagi yang digunakan oleh banyak pengguna dan/atau aplikasi), dua berbagi file Azure mungkin mencapai batas performa akun penyimpanan.
Praktik terbaiknya adalah menyebarkan akun penyimpanan dengan masing-masing satu berbagi file.
Anda dapat mengumpulkan beberapa berbagi file Azure ke akun penyimpanan yang sama jika Anda memiliki berbagi file arsip atau Anda mengharapkan aktivitas harian yang rendah di dalamnya.
Pertimbangan ini lebih berlaku untuk akses cloud langsung (melalui Azure VM) daripada Azure File Sync. Jika Anda berencana untuk hanya menggunakan Azure File Sync pada pembagian ini, beberapa dapat dikelompokkan ke dalam satu akun penyimpanan Azure.
Jika Anda telah membuat daftar berbagi, Anda harus memetakannya masing-masing ke akun penyimpanan yang akan digunakan.
Pada fase sebelumnya, Anda menentukan jumlah berbagi yang sesuai. Pada langkah ini, Anda memiliki pemetaan akun penyimpanan untuk berbagi file. Sekarang sebarkan jumlah akun penyimpanan Azure yang tepat dengan jumlah berbagi file Azure yang sesuai di dalamnya.
Pastikan wilayah setiap akun penyimpanan Anda sama dan cocok dengan wilayah sumber Storage Sync Service yang telah Anda sebarkan.
Perhatian
Jika Anda membuat berbagi file Azure yang memiliki batas 100 TiB, berbagi ini hanya dapat menggunakan opsi penyimpanan redundan lokal atau redundansi penyimpanan redundan zona. Pertimbangkan kebutuhan redundansi penyimpanan Anda sebelum menggunakan berbagi file 100 TiB.
Secara default, berbagi file Azure tetap dibuat dengan batas 5 TiB. Ikuti langkah-langkah di Membuat berbagi file Azure untuk membuat berbagi file besar.
Pertimbangan lain saat Anda menyebarkan akun penyimpanan adalah redundansi Azure Storage. Lihat Opsi redundansi Azure Storage.
Nama-nama sumber daya Anda juga penting. Misalnya, jika Anda mengelompokkan beberapa berbagi file untuk departemen SDM ke dalam akun penyimpanan Azure, Anda harus memberi nama akun penyimpanan dengan tepat. Demikian pula, saat menamai berbagi file Azure, Anda harus menggunakan nama yang mirip dengan yang digunakan untuk rekan lokalnya.
Fase 3: Tentukan berapa banyak appliance Azure Data Box yang Anda butuhkan
Mulailah langkah ini hanya setelah Anda menyelesaikan fase sebelumnya. Sumber daya penyimpanan Azure Anda (akun penyimpanan dan berbagi file) harus dibuat saat ini. Saat Anda memesan Data Box, Anda perlu menentukan akun penyimpanan tempat Data Box memindahkan data.
Pada fase ini, Anda perlu memetakan hasil rencana migrasi dari fase sebelumnya ke batasan opsi Data Box yang tersedia. Pertimbangan ini akan membantu Anda membuat rencana untuk opsi Data Box mana yang harus dipilih dan berapa banyak yang dibutuhkan untuk memindahkan berbagi NAS Anda ke berbagi file Azure.
Untuk menentukan berapa banyak perangkat dan jenis yang dibutuhkan, pertimbangkan batasan penting ini:
- Appliance Azure Data Box apa pun dapat memindahkan data hingga ke 10 akun penyimpanan.
- Setiap opsi Data Box hadir dengan kapasitasnya sendiri yang dapat digunakan. Lihat Opsi Data Box.
Lihat rencana migrasi Anda untuk menemukan jumlah akun penyimpanan yang Anda putuskan untuk dibuat dan melihat berbaginya masing-masing. Lalu lihat ukuran dari setiap berbagi ini di NAS Anda. Menggabungkan informasi ini akan memungkinkan Anda mengoptimalkan dan memutuskan appliance mana harus mengirim data ke akun penyimpanan mana. Dua perangkat Data Box dapat memindahkan file ke akun penyimpanan yang sama, tetapi jangan pecah konten dari satu berbagi file ke dua Data Box.
Opsi Data Box
Untuk migrasi standar, pilih satu atau kombinasi dari opsi Data Box berikut ini:
- Data Box Disk.
Microsoft akan mengirimi Anda satu atau lima disk SSD yang memiliki kapasitas masing-masing 8 TiB, untuk total maksimum 40 TiB. Kapasitas yang dapat digunakan berkurang sekitar 20 persen karena enkripsi dan overhead sistem file. Untuk informasi lebih lanjut, lihat Dokumentasi Data Box Disk.
- Data Box.
Opsi ini adalah yang paling umum. Microsoft akan mengirimkan appliance{i>
Dokumentasi Data Box.
- Data Box Heavy.
Opsi ini menampilkan appliance{i>
Dokumentasi Data Box Heavy.
Fase 4: Tentukan instans Windows Server lokal yang sesuai
Saat Anda menunggu perangkat Azure Data Box tiba, Anda dapat mulai meninjau kebutuhan satu atau beberapa instans Windows Server yang akan Anda gunakan dengan Azure File Sync.
- Buat instans Windows Server 2022 (minimal, Windows Server 2012 R2) sebagai komputer virtual atau server fisik. Kluster failover Windows Server juga didukung.
- Provisikan atau tambahkan Direct Attached Storage. NAS tidak didukung.
Konfigurasi sumber daya (komputasi dan RAM) instans Windows Server yang Anda terapkan sebagian besar bergantung pada jumlah {i>file
Pelajari cara mengukur instans Windows Server berdasarkan jumlah item yang perlu Anda sinkronkan.
Catatan
Artikel yang ditautkan sebelumnya menyajikan tabel dengan rentang untuk memori server (RAM). Anda dapat menggunakan angka di ujung bawah rentang untuk {i>server
Fase 5: Salin file ke Data Box Anda
Saat Data Box tiba, Anda perlu menyiapkannya dengan konektivitas jaringan tak terbatas ke appliance NAS Anda. Ikuti dokumentasi penyiapan untuk jenis Data Box yang Anda pesan:
Alat salin Data Box mungkin tersedia tergantung pada jenis Data Box. Pada titik ini, kami tidak menyarankan alat itu untuk migrasi ke berbagi file Azure karena ia tidak menyalin file Anda ke Data Box dengan keakuratan penuh. Alih-alih, gunakan Robocopy.
Ketika Data Box Anda tiba, ia akan memiliki berbagi SMB yang telah disediakan sebelumnya untuk setiap akun penyimpanan yang Anda tentukan saat Anda memesannya.
- Jika file Anda pergi ke berbagi file Azure premium, akan ada satu berbagi SMB per akun penyimpanan “File storage” premium.
- Jika file Anda pergi ke akun penyimpanan standar, akan ada tiga berbagi SMB per akun penyimpanan standar (GPv1 dan GPv2). Hanya berbagi file yang berakhiran dengan
_AzFiles yang relevan untuk migrasi Anda. Abaikan segala berbagi blok dan blob halaman.
Ikuti langkah-langkah dalam dokumentasi Azure Data Box:
- Sambungkan ke Data Box.
- Salin data ke Data Box.
Anda dapat menggunakan Robocopy (ikuti instruksi di bawah) atau layanan penyalinan data Data Box baru.
- Siapkan Data Box Anda untuk pengunggahan ke Azure.
Tip
Sebagai alternatif untuk Robocopy, Data Box telah membuat layanan penyalinan data. Anda dapat menggunakan layanan ini untuk memuat file ke Data Box Anda dengan keakuratan penuh. Ikuti tutorial layanan penyalinan data ini dan pastikan untuk mengatur target berbagi file Azure yang benar.
Dokumentasi Data Box menentukan perintah Robocopy. Perintah itu tidak cocok untuk mempertahankan keakuratan penuh file dan folder. Alih-alih, gunakan perintah ini:
robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
Mengalihkan
Makna
/MT:nMemungkinkan Robocopy untuk menjalankan multiutas. Default untuk n adalah 8. Maksimum adalah 128 utas. Sementara jumlah utas yang tinggi membantu memenuhi bandwidth yang tersedia, itu tidak berarti migrasi Anda akan selalu lebih cepat dengan lebih banyak utas. Pengujian dengan Azure Files menunjukkan antara 8 dan 20 memperlihatkan kinerja yang seimbang untuk menjalankan salinan awal. Proses /MIR berikutnya secara progresif dipengaruhi oleh komputasi yang tersedia vs bandwidth jaringan yang tersedia. Untuk proses selanjutnya, cocokkan nilai jumlah utas Anda lebih dekat dengan jumlah inti prosesor dan jumlah utas per inti Anda. Pertimbangkan apakah core perlu dicadangkan untuk tugas lain yang mungkin dilakukan oleh server produksi. Pengujian dengan Azure Files telah menunjukkan bahwa hingga 64 utas menghasilkan performa yang baik, tetapi hanya jika prosesor Anda dapat membuatnya tetap hidup pada saat yang sama.
/R:nJumlah coba lagi maksimum untuk file yang gagal disalin pada upaya pertama. Robocopy akan mencoba n waktu sebelum file secara permanen gagal menjalankan salinan. Anda dapat mengoptimalkan kinerja yang Anda jalankan: Pilih nilai dua atau tiga jika Anda yakin masalah batas waktu menyebabkan kegagalan di masa lalu. Ini mungkin lebih umum melalui tautan WAN. Pilih tidak mencoba ulang atau nilai satu jika Anda yakin file gagal menyalin karena sedang digunakan secara aktif. Mencoba lagi beberapa detik kemudian mungkin tidak cukup waktu untuk status file yang digunakan untuk berubah. Pengguna atau aplikasi yang menahan file terbuka mungkin memerlukan waktu beberapa jam lebih lama. Dalam hal ini, menerima file tidak disalin dan menangkapnya di salah satu rencana Anda, Robocopy berjalan berikutnya, mungkin akhirnya berhasil dalam menyalin file dengan sukses. Hal itu membantu eksekusi saat ini untuk menyelesaikan lebih cepat tanpa diperpanjang oleh banyak percobaan ulang yang akhirnya berakhir di sebagian besar kegagalan salinan karena file masih terbuka melewati batas waktu percobaan ulang.
/W:nMenentukan waktu tunggu Robocopy sebelum mencoba menyalin file yang tidak berhasil disalin selama upaya sebelumnya. n adalah jumlah detik untuk menunggu di antara coba lagi. /W:n sering digunakan bersama dengan /R:n.
/BMenjalankan Robocopy dalam mode yang sama dengan yang akan digunakan aplikasi cadangan. Pengalih ini memungkinkan Robocopy memindahkan file yang izinnya tidak dimiliki pengguna saat ini. Sakelar cadangan bergantung pada menjalankan perintah Robocopy di konsol tinggi administrator atau jendela PowerShell. Jika Anda menggunakan Robocopy untuk Azure Files, pastikan Anda memasang berbagi file Azure menggunakan kunci akses akun penyimpanan vs. identitas domain. Jika tidak, pesan kesalahan mungkin tidak secara intuitif mengarahkan Anda ke resolusi masalah.
/MIR(Mencerminkan sumber ke target.) Memungkinkan Robocopy menyalin hanya delta antara sumber serta target. Subdirektori kosong akan disalin. Item (file atau folder) yang telah berubah atau tidak ada pada target akan disalin. Item yang ada pada target tetapi tidak pada sumber akan dihapus menyeluruh (dihapus) dari target. Saat Anda menggunakan pengalih ini, cocokkan struktur folder sumber dan target. Pencocokan berarti menyalin dari tingkat sumber dan folder yang benar ke tingkat folder yang cocok pada target. Hanya dengan begitu salinan "catch up" bisa berhasil. Saat sumber dan target tidak cocok, penggunaan /MIR akan menyebabkan penghapusan dan penyalinan ulang dalam skala besar.
/ITMemastikan fidelitas dipertahankan dalam skenario cermin tertentu.
Misalnya, jika file mengalami perubahan ACL dan pembaruan atribut di antara dua proses Robocopy, file tersebut akan ditandai sebagai tersembunyi. Tanpa /IT, perubahan ACL mungkin terlewatkan oleh Robocopy dan tidak ditransfer ke lokasi target.
/COPY:[copyflags]Fidelitas salinan file. Default: /COPY:DAT. Bendera salinan: D= Data, A= Atribut, T= Tanda waktu, S= Keamanan = ACL NTFS, O= Informasi pemilik, U= Informasi audit. Informasi audit tidak dapat disimpan dalam berbagi file Azure.
/DCOPY:[copyflags]Fidelitas untuk salinan direktori. Default: /DCOPY:DA. Bendera salinan: D= Data, A= Atribut, T= Tanda waktu.
/NPMenentukan bahwa perkembangan penyalinan untuk setiap file dan folder tidak akan ditampilkan. Menampilkan kemajuan secara signifikan menurunkan performa salinan.
/NFLMenentukan bahwa nama file tidak dicatat. Meningkatkan performa salinan.
/NDLMenentukan bahwa nama direktori tidak dicatat. Meningkatkan performa salinan.
/XDMenentukan direktori yang akan dikecualikan. Saat menjalankan Robocopy pada akar volume, pertimbangkan untuk mengecualikan System Volume Informationfolder tersembunyi. Jika digunakan seperti yang dirancang, semua informasi di sana spesifik untuk volume yang tepat pada sistem yang tepat ini dan dapat dibangun kembali sesuai permintaan. Menyalin informasi ini tidak akan membantu di cloud atau ketika data pernah disalin kembali ke volume Windows lain. Meninggalkan konten ini di belakang tidak dianggap kehilangan data.
/UNILOG:<file name>Menulis status ke file log sebagai Unicode. (Menimpa log yang ada.)
/LHanya untuk file uji coba
yang hanya akan dicantumkan. Mereka tidak akan disalin, tidak dihapus, dan tidak waktu dicap. Sering digunakan dengan /TEE untuk keluaran konsol. Bendera dari skrip sampel, seperti /NP, /NFL, dan /NDL, mungkin perlu dihapus untuk mendapatkan hasil pengujian yang terdokumentasi dengan baik.
/LFSMHanya untuk target dengan penyimpanan bertingkat. Tidak didukung ketika tujuan adalah berbagi SMB jarak jauh.
Menentukan bahwa Robocopy beroperasi dalam "mode ruang kosong rendah." Sakelar ini hanya berguna untuk target dengan penyimpanan berjenjang yang mungkin kehabisan kapasitas lokal sebelum Robocopy selesai. Ini ditambahkan khusus untuk digunakan dengan target yang diaktifkan untuk tingkatan cloud Azure File Sync. Ini dapat digunakan secara terpisah dari Azure File Sync. Dalam mode ini, Robocopy akan berhenti sejenak setiap kali salinan file akan menyebabkan ruang bebas volume tujuan berada di bawah nilai "lantai". Nilai ini dapat ditentukan oleh bentuk /LFSM:n bendera. Parameter n ditentukan dalam basis 2: nKB, nMB atau nGB. /LFSMJika ditentukan tanpa nilai lantai eksplisit, lantai diatur ke 10 persen dari ukuran volume tujuan. Mode ruang bebas rendah tidak kompatibel dengan /MT, /EFSRAW, atau /ZB. Dukungan untuk /B ditambahkan di Windows Server 2022. Silakan lihat bagian Windows Server 2022 dan RoboCopy LFSM di bawah ini untuk informasi selengkapnya, termasuk detail mengenai bug dan solusi terkait.
/ZGunakan salin file dengan hati-hati
dalam mode hidupkan ulang. Pengalih ini hanya disarankan dalam lingkungan jaringan yang tidak stabil. Ini secara signifikan mengurangi performa salinan karena pengelogan ekstra.
/ZBGunakan dengan hati-hati
Menggunakan mode hidupkan ulang. Jika akses ditolak, opsi ini menggunakan mode pencadangan. Opsi ini secara signifikan mengurangi performa salinan karena titik pemeriksaan.
Penting
Sebaiknya gunakan Windows Server 2022. Saat menggunakan Windows Server 2019, pastikan pada tingkat patch terbaru atau setidaknya pembaruan OS KB5005103 terpasang. Ini berisi perbaikan penting untuk skenario Robocopy tertentu.
Fase 6: Menerapkan sumber daya {i>cloud
Sebelum Anda melanjutkan dengan panduan ini, tunggu sampai semua {i>file file
Untuk menyelesaikan langkah ini, Anda memerlukan info masuk langganan Azure Anda.
Sumber daya inti yang akan dikonfigurasi untuk Sinkronisasi File Azure disebut Storage Sync Service. Disarankan agar Anda hanya menggunakan satu untuk semua server yang menyinkronkan kumpulan file yang sama sekarang atau di masa mendatang. Buat beberapa Storage Sync Service hanya jika Anda memiliki kumpulan server berbeda yang tidak boleh bertukar data. Misalnya, Anda mungkin memiliki server yang tidak boleh menyinkronkan berbagi file Azure yang sama. Jika tidak, menggunakan Storage Sync Service tunggal adalah praktik terbaik.
Pilih wilayah Azure untuk Storage Sync Service yang dekat dengan lokasi Anda. Semua sumber daya cloud lainnya harus disebarkan di wilayah yang sama. Untuk menyederhanakan manajemen, buat grup sumber daya baru di langganan Anda yang menampung sumber daya sinkronisasi dan penyimpanan.
Untuk informasi selengkapnya, lihat bagian tentang menyebarkan Storage Sync Service di artikel tentang menyebarkan Sinkronisasi File Azure. Ikuti hanya bagian artikel ini. Akan ada tautan ke bagian lain dari artikel di langkah-langkah selanjutnya.
Fase 7: Terapkan alat Azure File Sync
Di bagian ini, Anda memasang agen Azure File Sync pada instans Windows Server Anda.
Panduan penyebaran menjelaskan bahwa Anda perlu menonaktifkan Konfigurasi Keamanan Tingkat Tinggi Internet Explorer. Langkah keamanan ini tidak berlaku untuk Azure File Sync. Menonaktifkannya memungkinkan Anda mengautentikasi ke Azure tanpa masalah.
Buka PowerShell. Pasang modul PowerShell yang diperlukan dengan menggunakan perintah berikut. Pastikan untuk memasang modul lengkap dan penyedia NuGet ketika Anda diminta untuk melakukannya.
Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync
Jika Anda memiliki masalah menjangkau internet dari server Anda, sekarang saatnya untuk menyelesaikannya. Azure File Sync menggunakan koneksi jaringan yang tersedia ke internet. Mengharuskan server proxy untuk menjangkau internet juga didukung. Anda dapat mengonfigurasi proksi di seluruh komputer sekarang atau, selama penginstalan agen, tentukan proksi yang hanya akan digunakan oleh Azure File Sync.
Jika mengonfigurasi proxy berarti Anda perlu membuka firewall untuk server, pendekatan tersebut mungkin dapat diterima oleh Anda. Di akhir penginstalan server, setelah Anda menyelesaikan pendaftaran server, laporan konektivitas jaringan akan menunjukkan titik akhir URL yang tepat di Azure yang perlu dikomunikasikan dengan Azure File Sync untuk wilayah yang Anda pilih. Laporan ini juga memberi tahu Anda mengapa komunikasi diperlukan. Anda dapat menggunakan laporan untuk mengunci firewall di sekitar server ke URL tertentu.
Anda juga dapat mengambil pendekatan yang lebih konservatif ketika Anda tidak membuka firewall lebar-lebar. Sebagai gantinya, Anda dapat membatasi server untuk berkomunikasi dengan ruang nama DNS tingkat lebih tinggi. Untuk informasi selengkapnya, lihat Proksi Azure File Sync dan pengaturan firewall. Ikuti praktik terbaik jaringan Anda sendiri.
Di akhir wisaya pemasangan wisaya server, wisaya pendaftaran server akan terbuka. Daftarkan server ke sumber daya Azure Storage Sync Service Anda dari yang lebih lama.
Langkah-langkah ini dijelaskan secara lebih rinci dalam panduan penyebaran, yang mencakup modul PowerShell yang harus Anda pasang terlebih dahulu: Pemasangan agen Azure File Sync.
Gunakan agen terbaru. Anda dapat mengunduhnya dari Pusat Unduhan Microsoft: Azure File Sync Agent.
Setelah penginstalan dan pendaftaran server berhasil, Anda dapat mengonfirmasi bahwa Anda telah berhasil menyelesaikan langkah ini. Buka sumber daya Storage Sync Service di portal Microsoft Azure. Di menu sebelah kiri, buka Server terdaftar. Anda akan melihat server Anda tercantum di sana.
Fase 8: Konfigurasikan Azure File Sync pada instans Windows Server
Instans Windows Server lokal Anda yang terdaftar harus siap dan terhubung ke internet untuk proses ini.
Langkah ini menyatukan semua sumber daya dan folder yang telah Anda siapkan di instans Windows Server Anda selama langkah sebelumnya.
- Masuk ke portal Azure.
- Temukan sumber daya Storage Sync Service Anda.
- Buat grup sinkronisasi baru dalam sumber daya Storage Sync Service untuk setiap berbagi file Azure. Di terminologi Sinkronisasi File Azure, berbagi file Azure akan menjadi titik akhir cloud di topologi sinkronisasi yang Anda jelaskan dengan pembuatan grup sinkronisasi. Saat Anda membuat grup sinkronisasi, beri nama yang familier sehingga Anda mengenali kumpulan file mana yang disinkronkan di sana. Pastikan Anda mereferensikan berbagi file Azure dengan nama yang cocok.
- Setelah Anda membuat grup sinkronisasi, baris untuk grup tersebut akan muncul dalam daftar grup sinkronisasi. Pilih nama (tautan) untuk menampilkan konten grup sinkronisasi. Anda akan melihat berbagi file Azure di Titik akhir Cloud.
- Temukan tombol Tambahkan Titik Akhir Server. Folder di server lokal yang telah Anda provisikan akan menjadi jalur untuk titik akhir server ini.
Aktifkan fitur penjenjangan cloud dan pilih Namespace hanya di bagian unduhan awal.
Penting
Tingkatan {i>cloud cloudnamespace disk cloud cloud
Untuk semua berbagi file Azure / lokasi server yang perlu Anda konfigurasikan untuk sinkronisasi, ulangi langkah-langkah untuk membuat grup sinkronisasi dan menambahkan folder server yang cocok sebagai titik akhir server. Tunggu sampai sinkronisasi {i>namespace
Catatan
Setelah Anda membuat titik akhir {i>serverfile file namespace cloud servernamespace
Fase 9: Tunggu {i>namespace
Sebelum Anda melanjutkan langkah selanjutnya dari migrasi Anda, tunggu sampai {i>servernamespace cloudfile server file
Untuk menentukan apakah {i>server
Cari peristiwa 9102 terbaru.
ID Peristiwa 9102 dicatat ketika sesi sinkronisasi selesai. Dalam teks peristiwa, ada bidang untuk petunjuk sinkronisasi unduhan. (HResult harus nol, dan file perlu diunduh.)
Anda ingin melihat dua peristiwa berturut-turut dari jenis ini, dengan konten ini, untuk memastikan bahwa {i>server namespace
Fase 10: Jalankan Robocopy dari NAS Anda
Setelah {i>server namespace cloud
Dalam langkah ini, Anda akan menjalankan pekerjaan RoboCopy untuk sinkronisasi berbagi {i>cloud churn
Peringatan
Karena perilaku Robocopy yang mengalami kemunduran di Windows Server 2019, sakelar Robocopy /MIR tidak kompatibel dengan direktori target bertingkat. Anda tidak dapat menggunakan Windows Server 2019 atau klien Windows 10 untuk fase migrasi ini. Gunakan Robocopy pada instans Windows Server 2016 menengah.
Berikut adalah pendekatan migrasi dasar:
- Jalankan Robocopy dari appliance NAS Anda untuk sinkronisasi instans Windows Server Anda.
- Gunakan Azure File Sync untuk sinkronisasi berbagi {i>file
Jalankan salinan lokal pertama ke folder target di Windows Server Anda:
- Identifikasi lokasi pertama di appliance NAS Anda.
- Identifikasi folder yang cocok pada instans Windows Server yang sudah memiliki Azure File Sync yang dikonfigurasi di dalamnya.
- Mulai penyalinan menggunakan Robocopy.
Perintah RoboCopy berikut hanya akan menyalin perbedaan ({i>file
robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
Mengalihkan
Makna
/MT:nMemungkinkan Robocopy untuk menjalankan multiutas. Default untuk n adalah 8. Maksimum adalah 128 utas. Sementara jumlah utas yang tinggi membantu memenuhi bandwidth yang tersedia, itu tidak berarti migrasi Anda akan selalu lebih cepat dengan lebih banyak utas. Pengujian dengan Azure Files menunjukkan antara 8 dan 20 memperlihatkan kinerja yang seimbang untuk menjalankan salinan awal. Proses /MIR berikutnya secara progresif dipengaruhi oleh komputasi yang tersedia vs bandwidth jaringan yang tersedia. Untuk proses selanjutnya, cocokkan nilai jumlah utas Anda lebih dekat dengan jumlah inti prosesor dan jumlah utas per inti Anda. Pertimbangkan apakah core perlu dicadangkan untuk tugas lain yang mungkin dilakukan oleh server produksi. Pengujian dengan Azure Files telah menunjukkan bahwa hingga 64 utas menghasilkan performa yang baik, tetapi hanya jika prosesor Anda dapat membuatnya tetap hidup pada saat yang sama.
/R:nJumlah coba lagi maksimum untuk file yang gagal disalin pada upaya pertama. Robocopy akan mencoba n waktu sebelum file secara permanen gagal menjalankan salinan. Anda dapat mengoptimalkan kinerja yang Anda jalankan: Pilih nilai dua atau tiga jika Anda yakin masalah batas waktu menyebabkan kegagalan di masa lalu. Ini mungkin lebih umum melalui tautan WAN. Pilih tidak mencoba ulang atau nilai satu jika Anda yakin file gagal menyalin karena sedang digunakan secara aktif. Mencoba lagi beberapa detik kemudian mungkin tidak cukup waktu untuk status file yang digunakan untuk berubah. Pengguna atau aplikasi yang menahan file terbuka mungkin memerlukan waktu beberapa jam lebih lama. Dalam hal ini, menerima file tidak disalin dan menangkapnya di salah satu rencana Anda, Robocopy berjalan berikutnya, mungkin akhirnya berhasil dalam menyalin file dengan sukses. Hal itu membantu eksekusi saat ini untuk menyelesaikan lebih cepat tanpa diperpanjang oleh banyak percobaan ulang yang akhirnya berakhir di sebagian besar kegagalan salinan karena file masih terbuka melewati batas waktu percobaan ulang.
/W:nMenentukan waktu tunggu Robocopy sebelum mencoba menyalin file yang tidak berhasil disalin selama upaya sebelumnya. n adalah jumlah detik untuk menunggu di antara coba lagi. /W:n sering digunakan bersama dengan /R:n.
/BMenjalankan Robocopy dalam mode yang sama dengan yang akan digunakan aplikasi cadangan. Pengalih ini memungkinkan Robocopy memindahkan file yang izinnya tidak dimiliki pengguna saat ini. Sakelar cadangan bergantung pada menjalankan perintah Robocopy di konsol tinggi administrator atau jendela PowerShell. Jika Anda menggunakan Robocopy untuk Azure Files, pastikan Anda memasang berbagi file Azure menggunakan kunci akses akun penyimpanan vs. identitas domain. Jika tidak, pesan kesalahan mungkin tidak secara intuitif mengarahkan Anda ke resolusi masalah.
/MIR(Mencerminkan sumber ke target.) Memungkinkan Robocopy menyalin hanya delta antara sumber serta target. Subdirektori kosong akan disalin. Item (file atau folder) yang telah berubah atau tidak ada pada target akan disalin. Item yang ada pada target tetapi tidak pada sumber akan dihapus menyeluruh (dihapus) dari target. Saat Anda menggunakan pengalih ini, cocokkan struktur folder sumber dan target. Pencocokan berarti menyalin dari tingkat sumber dan folder yang benar ke tingkat folder yang cocok pada target. Hanya dengan begitu salinan "catch up" bisa berhasil. Saat sumber dan target tidak cocok, penggunaan /MIR akan menyebabkan penghapusan dan penyalinan ulang dalam skala besar.
/ITMemastikan fidelitas dipertahankan dalam skenario cermin tertentu.
Misalnya, jika file mengalami perubahan ACL dan pembaruan atribut di antara dua proses Robocopy, file tersebut akan ditandai sebagai tersembunyi. Tanpa /IT, perubahan ACL mungkin terlewatkan oleh Robocopy dan tidak ditransfer ke lokasi target.
/COPY:[copyflags]Fidelitas salinan file. Default: /COPY:DAT. Bendera salinan: D= Data, A= Atribut, T= Tanda waktu, S= Keamanan = ACL NTFS, O= Informasi pemilik, U= Informasi audit. Informasi audit tidak dapat disimpan dalam berbagi file Azure.
/DCOPY:[copyflags]Fidelitas untuk salinan direktori. Default: /DCOPY:DA. Bendera salinan: D= Data, A= Atribut, T= Tanda waktu.
/NPMenentukan bahwa perkembangan penyalinan untuk setiap file dan folder tidak akan ditampilkan. Menampilkan kemajuan secara signifikan menurunkan performa salinan.
/NFLMenentukan bahwa nama file tidak dicatat. Meningkatkan performa salinan.
/NDLMenentukan bahwa nama direktori tidak dicatat. Meningkatkan performa salinan.
/XDMenentukan direktori yang akan dikecualikan. Saat menjalankan Robocopy pada akar volume, pertimbangkan untuk mengecualikan System Volume Informationfolder tersembunyi. Jika digunakan seperti yang dirancang, semua informasi di sana spesifik untuk volume yang tepat pada sistem yang tepat ini dan dapat dibangun kembali sesuai permintaan. Menyalin informasi ini tidak akan membantu di cloud atau ketika data pernah disalin kembali ke volume Windows lain. Meninggalkan konten ini di belakang tidak dianggap kehilangan data.
/UNILOG:<file name>Menulis status ke file log sebagai Unicode. (Menimpa log yang ada.)
/LHanya untuk file uji coba
yang hanya akan dicantumkan. Mereka tidak akan disalin, tidak dihapus, dan tidak waktu dicap. Sering digunakan dengan /TEE untuk keluaran konsol. Bendera dari skrip sampel, seperti /NP, /NFL, dan /NDL, mungkin perlu dihapus untuk mendapatkan hasil pengujian yang terdokumentasi dengan baik.
/LFSMHanya untuk target dengan penyimpanan bertingkat. Tidak didukung ketika tujuan adalah berbagi SMB jarak jauh.
Menentukan bahwa Robocopy beroperasi dalam "mode ruang kosong rendah." Sakelar ini hanya berguna untuk target dengan penyimpanan berjenjang yang mungkin kehabisan kapasitas lokal sebelum Robocopy selesai. Ini ditambahkan khusus untuk digunakan dengan target yang diaktifkan untuk tingkatan cloud Azure File Sync. Ini dapat digunakan secara terpisah dari Azure File Sync. Dalam mode ini, Robocopy akan berhenti sejenak setiap kali salinan file akan menyebabkan ruang bebas volume tujuan berada di bawah nilai "lantai". Nilai ini dapat ditentukan oleh bentuk /LFSM:n bendera. Parameter n ditentukan dalam basis 2: nKB, nMB atau nGB. /LFSMJika ditentukan tanpa nilai lantai eksplisit, lantai diatur ke 10 persen dari ukuran volume tujuan. Mode ruang bebas rendah tidak kompatibel dengan /MT, /EFSRAW, atau /ZB. Dukungan untuk /B ditambahkan di Windows Server 2022. Silakan lihat bagian Windows Server 2022 dan RoboCopy LFSM di bawah ini untuk informasi selengkapnya, termasuk detail mengenai bug dan solusi terkait.
/ZGunakan salin file dengan hati-hati
dalam mode hidupkan ulang. Pengalih ini hanya disarankan dalam lingkungan jaringan yang tidak stabil. Ini secara signifikan mengurangi performa salinan karena pengelogan ekstra.
/ZBGunakan dengan hati-hati
Menggunakan mode hidupkan ulang. Jika akses ditolak, opsi ini menggunakan mode pencadangan. Opsi ini secara signifikan mengurangi performa salinan karena titik pemeriksaan.
Penting
Sebaiknya gunakan Windows Server 2022. Saat menggunakan Windows Server 2019, pastikan pada tingkat patch terbaru atau setidaknya pembaruan OS KB5005103 terpasang. Ini berisi perbaikan penting untuk skenario Robocopy tertentu.
Jika Anda menyediakan lebih sedikit penyimpanan di instans Windows Server daripada yang digunakan oleh {i>fileappliance cloudtingkatan cloud akan dimulai dan file tingkat yang telah berhasil disinkronkan. Cloud tiering akan menghasilkan ruang yang cukup untuk melanjutkan penyalinan dari appliance NAS. Pemeriksaan tingkatan {i>cloud disk
Robocopy mungkin perlu memindahkan lebih banyak {i>file file /MIR akan memastikan bahwa hanya delta yang dipindahkan. Setelah delta dipindahkan, pekerjaan menghidupkan ulang tidak perlu memindahkan {i>file
Ambil jalan pintas
Saat Anda menjalankan perintah RoboCopy untuk pertama kalinya, pengguna dan aplikasi Anda masih mengakses {i>file file
Proses pertama adalah tentang memindahkan sebagian besar data {i>churn cloud
- Bandwidth unggahan.
- Kecepatan jaringan lokal dan seberapa optimal jumlah alur RoboCopy yang cocok.
- Jumlah item ({i>file
Setelah proses awal selesai, jalankan kembali perintah tersebut.
Robocopy akan selesai lebih cepat untuk kedua kalinya Anda menjalankannya untuk berbagi. Hanya perlu membawa perubahan yang terjadi sejak eksekusi terakhir. Anda dapat menjalankan pekerjaan berulang untuk berbagi yang sama.
Saat Anda menilai bahwa waktu hentinya dapat diterima, Anda harus menghapus akses pengguna ke berbagi yang berbasis NAS Anda. Anda dapat melakukannya melalui langkah apa pun yang dapat mencegah pengguna mengubah struktur dan konten {i>file namespace
Jalankan Robocopy untuk terakhir kalinya. Proses ini akan menemukan perubahan apa pun, yang mungkin terlewat sebelumnya.
Berapa lama langkah terakhir ini bergantung pada kecepatan pemindaian Robocopy. Anda dapat memperkirakan waktu (yang sebanding dengan waktu henti Anda) dengan mengukur berapa lama eksekusi alur sebelumnya.
Buat berbagi di folder Windows Server dan kemungkinan sesuaikan penyebaran DFS-N Anda untuk mengarahkannya ke sana. Pastikan untuk mengatur izin akses level berbagi yang sama seperti di berbagi NAS SMB Anda. Jika Anda memiliki NAS kelas {i>enterprise file metadata
- Membuat kembali pengguna-pengguna ini sebagai pengguna lokal Windows Server.
- Memetakan SID yang sudah ada yang dipindahkan Robocopy ke instans Windows Server Anda ke SID pengguna lokal Windows Server baru.
Anda telah selesai memigrasikan berbagi atau grup berbagi ke dalam akar atau volume yang sama (bergantung pada pemetaan Anda dari Fase 1).
Anda dapat mencoba menjalankan beberapa salinan ini secara paralel. Sebaiknya proses cakupan dari satu berbagi {i>file
Opsi tidak digunakan lagi: "transfer data offline"
Sebelum agen Azure File Sync versi 13 dirilis, integrasi Data Box dilakukan melalui proses yang disebut "transfer data offline". Proses ini tidak digunakan lagi, dan Anda tidak dapat lagi membuat titik akhir server dalam mode "transfer data offline". Dengan agen versi 13, ini diganti dengan langkah-langkah yang jauh lebih sederhana dan lebih cepat yang diuraikan dalam artikel ini.
Pemecahan Masalah
Masalah yang paling umum adalah bahwa perintah Robocopy gagal dengan “Volume penuh” di sisi Windows Server. Cloud tiering bertindak sekali setiap jam untuk mengevakuasi konten dari disk Windows Server lokal yang telah disinkronkan. Tujuannya adalah untuk mencapai 99% ruang kosong pada volume Anda.
Biarkan kemajuan sinkronisasi dan cloud tiering mengosongkan ruang disk. Anda dapat mengamatinya di File Explorer di Instans Windows Server Anda.
Ketika instans Windows Server Anda memiliki kapasitas tersedia yang cukup, jalankan kembali perintah untuk menyelesaikan masalah. Tidak ada yang putus dalam situasi ini. Anda bisa meneruskan dengan keyakinan. Ketidaknyamanan menjalankan perintah lagi adalah satu-satunya konsekuensi.
Untuk memecahkan masalah Azure File Sync, lihat artikel yang tercantum di bagian berikutnya.
Langkah berikutnya
Artikel berikut ini akan membantu Anda memahami opsi tingkat lanjut dan praktik terbaik untuk Azure Files dan Azure File Sync.
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
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.
|
|
Unduh templat pemetaan namespace layanan. |
Fase 2: Sebar sumber daya penyimpanan Azure
Dalam fase ini, perhatikan tabel pemetaan dari Fase 1 dan gunakan untuk menyediakan jumlah akun penyimpanan Azure yang tepat dan berbagi file di dalamnya.
Berbagi file Azure disimpan di cloud di akun penyimpanan Azure. Tingkat pertimbangan performa lainnya berlaku di sini.
Jika Anda memiliki berbagi yang sangat aktif (berbagi yang digunakan oleh banyak pengguna dan/atau aplikasi), dua berbagi file Azure mungkin mencapai batas performa akun penyimpanan.
Praktik terbaiknya adalah menyebarkan akun penyimpanan dengan masing-masing satu berbagi file. Anda dapat mengumpulkan beberapa berbagi file Azure ke akun penyimpanan yang sama jika Anda memiliki berbagi file arsip atau Anda mengharapkan aktivitas harian yang rendah di dalamnya.
Pertimbangan ini lebih berlaku untuk akses cloud langsung (melalui Azure VM) daripada Azure File Sync. Jika Anda berencana untuk hanya menggunakan Azure File Sync pada pembagian ini, beberapa dapat dikelompokkan ke dalam satu akun penyimpanan Azure.
Jika Anda telah membuat daftar berbagi, Anda harus memetakannya masing-masing ke akun penyimpanan yang akan digunakan.
Pada fase sebelumnya, Anda menentukan jumlah berbagi yang sesuai. Pada langkah ini, Anda memiliki pemetaan akun penyimpanan untuk berbagi file. Sekarang sebarkan jumlah akun penyimpanan Azure yang tepat dengan jumlah berbagi file Azure yang sesuai di dalamnya.
Pastikan wilayah setiap akun penyimpanan Anda sama dan cocok dengan wilayah sumber Storage Sync Service yang telah Anda sebarkan.
Perhatian
Jika Anda membuat berbagi file Azure yang memiliki batas 100 TiB, berbagi ini hanya dapat menggunakan opsi penyimpanan redundan lokal atau redundansi penyimpanan redundan zona. Pertimbangkan kebutuhan redundansi penyimpanan Anda sebelum menggunakan berbagi file 100 TiB.
Secara default, berbagi file Azure tetap dibuat dengan batas 5 TiB. Ikuti langkah-langkah di Membuat berbagi file Azure untuk membuat berbagi file besar.
Pertimbangan lain saat Anda menyebarkan akun penyimpanan adalah redundansi Azure Storage. Lihat Opsi redundansi Azure Storage.
Nama-nama sumber daya Anda juga penting. Misalnya, jika Anda mengelompokkan beberapa berbagi file untuk departemen SDM ke dalam akun penyimpanan Azure, Anda harus memberi nama akun penyimpanan dengan tepat. Demikian pula, saat menamai berbagi file Azure, Anda harus menggunakan nama yang mirip dengan yang digunakan untuk rekan lokalnya.
Fase 3: Tentukan berapa banyak appliance Azure Data Box yang Anda butuhkan
Mulailah langkah ini hanya setelah Anda menyelesaikan fase sebelumnya. Sumber daya penyimpanan Azure Anda (akun penyimpanan dan berbagi file) harus dibuat saat ini. Saat Anda memesan Data Box, Anda perlu menentukan akun penyimpanan tempat Data Box memindahkan data.
Pada fase ini, Anda perlu memetakan hasil rencana migrasi dari fase sebelumnya ke batasan opsi Data Box yang tersedia. Pertimbangan ini akan membantu Anda membuat rencana untuk opsi Data Box mana yang harus dipilih dan berapa banyak yang dibutuhkan untuk memindahkan berbagi NAS Anda ke berbagi file Azure.
Untuk menentukan berapa banyak perangkat dan jenis yang dibutuhkan, pertimbangkan batasan penting ini:
- Appliance Azure Data Box apa pun dapat memindahkan data hingga ke 10 akun penyimpanan.
- Setiap opsi Data Box hadir dengan kapasitasnya sendiri yang dapat digunakan. Lihat Opsi Data Box.
Lihat rencana migrasi Anda untuk menemukan jumlah akun penyimpanan yang Anda putuskan untuk dibuat dan melihat berbaginya masing-masing. Lalu lihat ukuran dari setiap berbagi ini di NAS Anda. Menggabungkan informasi ini akan memungkinkan Anda mengoptimalkan dan memutuskan appliance mana harus mengirim data ke akun penyimpanan mana. Dua perangkat Data Box dapat memindahkan file ke akun penyimpanan yang sama, tetapi jangan pecah konten dari satu berbagi file ke dua Data Box.
Opsi Data Box
Untuk migrasi standar, pilih satu atau kombinasi dari opsi Data Box berikut ini:
- Data Box Disk. Microsoft akan mengirimi Anda satu atau lima disk SSD yang memiliki kapasitas masing-masing 8 TiB, untuk total maksimum 40 TiB. Kapasitas yang dapat digunakan berkurang sekitar 20 persen karena enkripsi dan overhead sistem file. Untuk informasi lebih lanjut, lihat Dokumentasi Data Box Disk.
- Data Box.
Opsi ini adalah yang paling umum. Microsoft akan mengirimkan appliance{i>
- Data Box Heavy.
Opsi ini menampilkan appliance{i>
Fase 4: Tentukan instans Windows Server lokal yang sesuai
Saat Anda menunggu perangkat Azure Data Box tiba, Anda dapat mulai meninjau kebutuhan satu atau beberapa instans Windows Server yang akan Anda gunakan dengan Azure File Sync.
- Buat instans Windows Server 2022 (minimal, Windows Server 2012 R2) sebagai komputer virtual atau server fisik. Kluster failover Windows Server juga didukung.
- Provisikan atau tambahkan Direct Attached Storage. NAS tidak didukung.
Konfigurasi sumber daya (komputasi dan RAM) instans Windows Server yang Anda terapkan sebagian besar bergantung pada jumlah {i>file
Pelajari cara mengukur instans Windows Server berdasarkan jumlah item yang perlu Anda sinkronkan.
Catatan
Artikel yang ditautkan sebelumnya menyajikan tabel dengan rentang untuk memori server (RAM). Anda dapat menggunakan angka di ujung bawah rentang untuk {i>server
Fase 5: Salin file ke Data Box Anda
Saat Data Box tiba, Anda perlu menyiapkannya dengan konektivitas jaringan tak terbatas ke appliance NAS Anda. Ikuti dokumentasi penyiapan untuk jenis Data Box yang Anda pesan:
Alat salin Data Box mungkin tersedia tergantung pada jenis Data Box. Pada titik ini, kami tidak menyarankan alat itu untuk migrasi ke berbagi file Azure karena ia tidak menyalin file Anda ke Data Box dengan keakuratan penuh. Alih-alih, gunakan Robocopy.
Ketika Data Box Anda tiba, ia akan memiliki berbagi SMB yang telah disediakan sebelumnya untuk setiap akun penyimpanan yang Anda tentukan saat Anda memesannya.
- Jika file Anda pergi ke berbagi file Azure premium, akan ada satu berbagi SMB per akun penyimpanan “File storage” premium.
- Jika file Anda pergi ke akun penyimpanan standar, akan ada tiga berbagi SMB per akun penyimpanan standar (GPv1 dan GPv2). Hanya berbagi file yang berakhiran dengan
_AzFilesyang relevan untuk migrasi Anda. Abaikan segala berbagi blok dan blob halaman.
Ikuti langkah-langkah dalam dokumentasi Azure Data Box:
- Sambungkan ke Data Box.
- Salin data ke Data Box.
Anda dapat menggunakan Robocopy (ikuti instruksi di bawah) atau layanan penyalinan data Data Box baru. - Siapkan Data Box Anda untuk pengunggahan ke Azure.
Tip
Sebagai alternatif untuk Robocopy, Data Box telah membuat layanan penyalinan data. Anda dapat menggunakan layanan ini untuk memuat file ke Data Box Anda dengan keakuratan penuh. Ikuti tutorial layanan penyalinan data ini dan pastikan untuk mengatur target berbagi file Azure yang benar.
Dokumentasi Data Box menentukan perintah Robocopy. Perintah itu tidak cocok untuk mempertahankan keakuratan penuh file dan folder. Alih-alih, gunakan perintah ini:
robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
| Mengalihkan | Makna |
|---|---|
/MT:n |
Memungkinkan Robocopy untuk menjalankan multiutas. Default untuk n adalah 8. Maksimum adalah 128 utas. Sementara jumlah utas yang tinggi membantu memenuhi bandwidth yang tersedia, itu tidak berarti migrasi Anda akan selalu lebih cepat dengan lebih banyak utas. Pengujian dengan Azure Files menunjukkan antara 8 dan 20 memperlihatkan kinerja yang seimbang untuk menjalankan salinan awal. Proses /MIR berikutnya secara progresif dipengaruhi oleh komputasi yang tersedia vs bandwidth jaringan yang tersedia. Untuk proses selanjutnya, cocokkan nilai jumlah utas Anda lebih dekat dengan jumlah inti prosesor dan jumlah utas per inti Anda. Pertimbangkan apakah core perlu dicadangkan untuk tugas lain yang mungkin dilakukan oleh server produksi. Pengujian dengan Azure Files telah menunjukkan bahwa hingga 64 utas menghasilkan performa yang baik, tetapi hanya jika prosesor Anda dapat membuatnya tetap hidup pada saat yang sama. |
/R:n |
Jumlah coba lagi maksimum untuk file yang gagal disalin pada upaya pertama. Robocopy akan mencoba n waktu sebelum file secara permanen gagal menjalankan salinan. Anda dapat mengoptimalkan kinerja yang Anda jalankan: Pilih nilai dua atau tiga jika Anda yakin masalah batas waktu menyebabkan kegagalan di masa lalu. Ini mungkin lebih umum melalui tautan WAN. Pilih tidak mencoba ulang atau nilai satu jika Anda yakin file gagal menyalin karena sedang digunakan secara aktif. Mencoba lagi beberapa detik kemudian mungkin tidak cukup waktu untuk status file yang digunakan untuk berubah. Pengguna atau aplikasi yang menahan file terbuka mungkin memerlukan waktu beberapa jam lebih lama. Dalam hal ini, menerima file tidak disalin dan menangkapnya di salah satu rencana Anda, Robocopy berjalan berikutnya, mungkin akhirnya berhasil dalam menyalin file dengan sukses. Hal itu membantu eksekusi saat ini untuk menyelesaikan lebih cepat tanpa diperpanjang oleh banyak percobaan ulang yang akhirnya berakhir di sebagian besar kegagalan salinan karena file masih terbuka melewati batas waktu percobaan ulang. |
/W:n |
Menentukan waktu tunggu Robocopy sebelum mencoba menyalin file yang tidak berhasil disalin selama upaya sebelumnya. n adalah jumlah detik untuk menunggu di antara coba lagi. /W:n sering digunakan bersama dengan /R:n. |
/B |
Menjalankan Robocopy dalam mode yang sama dengan yang akan digunakan aplikasi cadangan. Pengalih ini memungkinkan Robocopy memindahkan file yang izinnya tidak dimiliki pengguna saat ini. Sakelar cadangan bergantung pada menjalankan perintah Robocopy di konsol tinggi administrator atau jendela PowerShell. Jika Anda menggunakan Robocopy untuk Azure Files, pastikan Anda memasang berbagi file Azure menggunakan kunci akses akun penyimpanan vs. identitas domain. Jika tidak, pesan kesalahan mungkin tidak secara intuitif mengarahkan Anda ke resolusi masalah. |
/MIR |
(Mencerminkan sumber ke target.) Memungkinkan Robocopy menyalin hanya delta antara sumber serta target. Subdirektori kosong akan disalin. Item (file atau folder) yang telah berubah atau tidak ada pada target akan disalin. Item yang ada pada target tetapi tidak pada sumber akan dihapus menyeluruh (dihapus) dari target. Saat Anda menggunakan pengalih ini, cocokkan struktur folder sumber dan target. Pencocokan berarti menyalin dari tingkat sumber dan folder yang benar ke tingkat folder yang cocok pada target. Hanya dengan begitu salinan "catch up" bisa berhasil. Saat sumber dan target tidak cocok, penggunaan /MIR akan menyebabkan penghapusan dan penyalinan ulang dalam skala besar. |
/IT |
Memastikan fidelitas dipertahankan dalam skenario cermin tertentu. Misalnya, jika file mengalami perubahan ACL dan pembaruan atribut di antara dua proses Robocopy, file tersebut akan ditandai sebagai tersembunyi. Tanpa /IT, perubahan ACL mungkin terlewatkan oleh Robocopy dan tidak ditransfer ke lokasi target. |
/COPY:[copyflags] |
Fidelitas salinan file. Default: /COPY:DAT. Bendera salinan: D= Data, A= Atribut, T= Tanda waktu, S= Keamanan = ACL NTFS, O= Informasi pemilik, U= Informasi audit. Informasi audit tidak dapat disimpan dalam berbagi file Azure. |
/DCOPY:[copyflags] |
Fidelitas untuk salinan direktori. Default: /DCOPY:DA. Bendera salinan: D= Data, A= Atribut, T= Tanda waktu. |
/NP |
Menentukan bahwa perkembangan penyalinan untuk setiap file dan folder tidak akan ditampilkan. Menampilkan kemajuan secara signifikan menurunkan performa salinan. |
/NFL |
Menentukan bahwa nama file tidak dicatat. Meningkatkan performa salinan. |
/NDL |
Menentukan bahwa nama direktori tidak dicatat. Meningkatkan performa salinan. |
/XD |
Menentukan direktori yang akan dikecualikan. Saat menjalankan Robocopy pada akar volume, pertimbangkan untuk mengecualikan System Volume Informationfolder tersembunyi. Jika digunakan seperti yang dirancang, semua informasi di sana spesifik untuk volume yang tepat pada sistem yang tepat ini dan dapat dibangun kembali sesuai permintaan. Menyalin informasi ini tidak akan membantu di cloud atau ketika data pernah disalin kembali ke volume Windows lain. Meninggalkan konten ini di belakang tidak dianggap kehilangan data. |
/UNILOG:<file name> |
Menulis status ke file log sebagai Unicode. (Menimpa log yang ada.) |
/L |
Hanya untuk file uji coba yang hanya akan dicantumkan. Mereka tidak akan disalin, tidak dihapus, dan tidak waktu dicap. Sering digunakan dengan /TEE untuk keluaran konsol. Bendera dari skrip sampel, seperti /NP, /NFL, dan /NDL, mungkin perlu dihapus untuk mendapatkan hasil pengujian yang terdokumentasi dengan baik. |
/LFSM |
Hanya untuk target dengan penyimpanan bertingkat. Tidak didukung ketika tujuan adalah berbagi SMB jarak jauh. Menentukan bahwa Robocopy beroperasi dalam "mode ruang kosong rendah." Sakelar ini hanya berguna untuk target dengan penyimpanan berjenjang yang mungkin kehabisan kapasitas lokal sebelum Robocopy selesai. Ini ditambahkan khusus untuk digunakan dengan target yang diaktifkan untuk tingkatan cloud Azure File Sync. Ini dapat digunakan secara terpisah dari Azure File Sync. Dalam mode ini, Robocopy akan berhenti sejenak setiap kali salinan file akan menyebabkan ruang bebas volume tujuan berada di bawah nilai "lantai". Nilai ini dapat ditentukan oleh bentuk /LFSM:n bendera. Parameter n ditentukan dalam basis 2: nKB, nMB atau nGB. /LFSMJika ditentukan tanpa nilai lantai eksplisit, lantai diatur ke 10 persen dari ukuran volume tujuan. Mode ruang bebas rendah tidak kompatibel dengan /MT, /EFSRAW, atau /ZB. Dukungan untuk /B ditambahkan di Windows Server 2022. Silakan lihat bagian Windows Server 2022 dan RoboCopy LFSM di bawah ini untuk informasi selengkapnya, termasuk detail mengenai bug dan solusi terkait. |
/Z |
Gunakan salin file dengan hati-hati dalam mode hidupkan ulang. Pengalih ini hanya disarankan dalam lingkungan jaringan yang tidak stabil. Ini secara signifikan mengurangi performa salinan karena pengelogan ekstra. |
/ZB |
Gunakan dengan hati-hati Menggunakan mode hidupkan ulang. Jika akses ditolak, opsi ini menggunakan mode pencadangan. Opsi ini secara signifikan mengurangi performa salinan karena titik pemeriksaan. |
Penting
Sebaiknya gunakan Windows Server 2022. Saat menggunakan Windows Server 2019, pastikan pada tingkat patch terbaru atau setidaknya pembaruan OS KB5005103 terpasang. Ini berisi perbaikan penting untuk skenario Robocopy tertentu.
Fase 6: Menerapkan sumber daya {i>cloud
Sebelum Anda melanjutkan dengan panduan ini, tunggu sampai semua {i>file file
Untuk menyelesaikan langkah ini, Anda memerlukan info masuk langganan Azure Anda.
Sumber daya inti yang akan dikonfigurasi untuk Sinkronisasi File Azure disebut Storage Sync Service. Disarankan agar Anda hanya menggunakan satu untuk semua server yang menyinkronkan kumpulan file yang sama sekarang atau di masa mendatang. Buat beberapa Storage Sync Service hanya jika Anda memiliki kumpulan server berbeda yang tidak boleh bertukar data. Misalnya, Anda mungkin memiliki server yang tidak boleh menyinkronkan berbagi file Azure yang sama. Jika tidak, menggunakan Storage Sync Service tunggal adalah praktik terbaik.
Pilih wilayah Azure untuk Storage Sync Service yang dekat dengan lokasi Anda. Semua sumber daya cloud lainnya harus disebarkan di wilayah yang sama. Untuk menyederhanakan manajemen, buat grup sumber daya baru di langganan Anda yang menampung sumber daya sinkronisasi dan penyimpanan.
Untuk informasi selengkapnya, lihat bagian tentang menyebarkan Storage Sync Service di artikel tentang menyebarkan Sinkronisasi File Azure. Ikuti hanya bagian artikel ini. Akan ada tautan ke bagian lain dari artikel di langkah-langkah selanjutnya.
Fase 7: Terapkan alat Azure File Sync
Di bagian ini, Anda memasang agen Azure File Sync pada instans Windows Server Anda.
Panduan penyebaran menjelaskan bahwa Anda perlu menonaktifkan Konfigurasi Keamanan Tingkat Tinggi Internet Explorer. Langkah keamanan ini tidak berlaku untuk Azure File Sync. Menonaktifkannya memungkinkan Anda mengautentikasi ke Azure tanpa masalah.
Buka PowerShell. Pasang modul PowerShell yang diperlukan dengan menggunakan perintah berikut. Pastikan untuk memasang modul lengkap dan penyedia NuGet ketika Anda diminta untuk melakukannya.
Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync
Jika Anda memiliki masalah menjangkau internet dari server Anda, sekarang saatnya untuk menyelesaikannya. Azure File Sync menggunakan koneksi jaringan yang tersedia ke internet. Mengharuskan server proxy untuk menjangkau internet juga didukung. Anda dapat mengonfigurasi proksi di seluruh komputer sekarang atau, selama penginstalan agen, tentukan proksi yang hanya akan digunakan oleh Azure File Sync.
Jika mengonfigurasi proxy berarti Anda perlu membuka firewall untuk server, pendekatan tersebut mungkin dapat diterima oleh Anda. Di akhir penginstalan server, setelah Anda menyelesaikan pendaftaran server, laporan konektivitas jaringan akan menunjukkan titik akhir URL yang tepat di Azure yang perlu dikomunikasikan dengan Azure File Sync untuk wilayah yang Anda pilih. Laporan ini juga memberi tahu Anda mengapa komunikasi diperlukan. Anda dapat menggunakan laporan untuk mengunci firewall di sekitar server ke URL tertentu.
Anda juga dapat mengambil pendekatan yang lebih konservatif ketika Anda tidak membuka firewall lebar-lebar. Sebagai gantinya, Anda dapat membatasi server untuk berkomunikasi dengan ruang nama DNS tingkat lebih tinggi. Untuk informasi selengkapnya, lihat Proksi Azure File Sync dan pengaturan firewall. Ikuti praktik terbaik jaringan Anda sendiri.
Di akhir wisaya pemasangan wisaya server, wisaya pendaftaran server akan terbuka. Daftarkan server ke sumber daya Azure Storage Sync Service Anda dari yang lebih lama.
Langkah-langkah ini dijelaskan secara lebih rinci dalam panduan penyebaran, yang mencakup modul PowerShell yang harus Anda pasang terlebih dahulu: Pemasangan agen Azure File Sync.
Gunakan agen terbaru. Anda dapat mengunduhnya dari Pusat Unduhan Microsoft: Azure File Sync Agent.
Setelah penginstalan dan pendaftaran server berhasil, Anda dapat mengonfirmasi bahwa Anda telah berhasil menyelesaikan langkah ini. Buka sumber daya Storage Sync Service di portal Microsoft Azure. Di menu sebelah kiri, buka Server terdaftar. Anda akan melihat server Anda tercantum di sana.
Fase 8: Konfigurasikan Azure File Sync pada instans Windows Server
Instans Windows Server lokal Anda yang terdaftar harus siap dan terhubung ke internet untuk proses ini.
Langkah ini menyatukan semua sumber daya dan folder yang telah Anda siapkan di instans Windows Server Anda selama langkah sebelumnya.
- Masuk ke portal Azure.
- Temukan sumber daya Storage Sync Service Anda.
- Buat grup sinkronisasi baru dalam sumber daya Storage Sync Service untuk setiap berbagi file Azure. Di terminologi Sinkronisasi File Azure, berbagi file Azure akan menjadi titik akhir cloud di topologi sinkronisasi yang Anda jelaskan dengan pembuatan grup sinkronisasi. Saat Anda membuat grup sinkronisasi, beri nama yang familier sehingga Anda mengenali kumpulan file mana yang disinkronkan di sana. Pastikan Anda mereferensikan berbagi file Azure dengan nama yang cocok.
- Setelah Anda membuat grup sinkronisasi, baris untuk grup tersebut akan muncul dalam daftar grup sinkronisasi. Pilih nama (tautan) untuk menampilkan konten grup sinkronisasi. Anda akan melihat berbagi file Azure di Titik akhir Cloud.
- Temukan tombol Tambahkan Titik Akhir Server. Folder di server lokal yang telah Anda provisikan akan menjadi jalur untuk titik akhir server ini.
Aktifkan fitur penjenjangan cloud dan pilih Namespace hanya di bagian unduhan awal.
Penting
Tingkatan {i>cloud cloudnamespace disk cloud cloud
Untuk semua berbagi file Azure / lokasi server yang perlu Anda konfigurasikan untuk sinkronisasi, ulangi langkah-langkah untuk membuat grup sinkronisasi dan menambahkan folder server yang cocok sebagai titik akhir server. Tunggu sampai sinkronisasi {i>namespace
Catatan
Setelah Anda membuat titik akhir {i>serverfile file namespace cloud servernamespace
Fase 9: Tunggu {i>namespace
Sebelum Anda melanjutkan langkah selanjutnya dari migrasi Anda, tunggu sampai {i>servernamespace cloudfile server file
Untuk menentukan apakah {i>server
Cari peristiwa 9102 terbaru.
ID Peristiwa 9102 dicatat ketika sesi sinkronisasi selesai. Dalam teks peristiwa, ada bidang untuk petunjuk sinkronisasi unduhan. (HResult harus nol, dan file perlu diunduh.)
Anda ingin melihat dua peristiwa berturut-turut dari jenis ini, dengan konten ini, untuk memastikan bahwa {i>server namespace
Fase 10: Jalankan Robocopy dari NAS Anda
Setelah {i>server namespace cloud
Dalam langkah ini, Anda akan menjalankan pekerjaan RoboCopy untuk sinkronisasi berbagi {i>cloud churn
Peringatan
Karena perilaku Robocopy yang mengalami kemunduran di Windows Server 2019, sakelar Robocopy /MIR tidak kompatibel dengan direktori target bertingkat. Anda tidak dapat menggunakan Windows Server 2019 atau klien Windows 10 untuk fase migrasi ini. Gunakan Robocopy pada instans Windows Server 2016 menengah.
Berikut adalah pendekatan migrasi dasar:
- Jalankan Robocopy dari appliance NAS Anda untuk sinkronisasi instans Windows Server Anda.
- Gunakan Azure File Sync untuk sinkronisasi berbagi {i>file
Jalankan salinan lokal pertama ke folder target di Windows Server Anda:
- Identifikasi lokasi pertama di appliance NAS Anda.
- Identifikasi folder yang cocok pada instans Windows Server yang sudah memiliki Azure File Sync yang dikonfigurasi di dalamnya.
- Mulai penyalinan menggunakan Robocopy.
Perintah RoboCopy berikut hanya akan menyalin perbedaan ({i>file
robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
Mengalihkan
Makna
/MT:nMemungkinkan Robocopy untuk menjalankan multiutas. Default untuk n adalah 8. Maksimum adalah 128 utas. Sementara jumlah utas yang tinggi membantu memenuhi bandwidth yang tersedia, itu tidak berarti migrasi Anda akan selalu lebih cepat dengan lebih banyak utas. Pengujian dengan Azure Files menunjukkan antara 8 dan 20 memperlihatkan kinerja yang seimbang untuk menjalankan salinan awal. Proses /MIR berikutnya secara progresif dipengaruhi oleh komputasi yang tersedia vs bandwidth jaringan yang tersedia. Untuk proses selanjutnya, cocokkan nilai jumlah utas Anda lebih dekat dengan jumlah inti prosesor dan jumlah utas per inti Anda. Pertimbangkan apakah core perlu dicadangkan untuk tugas lain yang mungkin dilakukan oleh server produksi. Pengujian dengan Azure Files telah menunjukkan bahwa hingga 64 utas menghasilkan performa yang baik, tetapi hanya jika prosesor Anda dapat membuatnya tetap hidup pada saat yang sama.
/R:nJumlah coba lagi maksimum untuk file yang gagal disalin pada upaya pertama. Robocopy akan mencoba n waktu sebelum file secara permanen gagal menjalankan salinan. Anda dapat mengoptimalkan kinerja yang Anda jalankan: Pilih nilai dua atau tiga jika Anda yakin masalah batas waktu menyebabkan kegagalan di masa lalu. Ini mungkin lebih umum melalui tautan WAN. Pilih tidak mencoba ulang atau nilai satu jika Anda yakin file gagal menyalin karena sedang digunakan secara aktif. Mencoba lagi beberapa detik kemudian mungkin tidak cukup waktu untuk status file yang digunakan untuk berubah. Pengguna atau aplikasi yang menahan file terbuka mungkin memerlukan waktu beberapa jam lebih lama. Dalam hal ini, menerima file tidak disalin dan menangkapnya di salah satu rencana Anda, Robocopy berjalan berikutnya, mungkin akhirnya berhasil dalam menyalin file dengan sukses. Hal itu membantu eksekusi saat ini untuk menyelesaikan lebih cepat tanpa diperpanjang oleh banyak percobaan ulang yang akhirnya berakhir di sebagian besar kegagalan salinan karena file masih terbuka melewati batas waktu percobaan ulang.
/W:nMenentukan waktu tunggu Robocopy sebelum mencoba menyalin file yang tidak berhasil disalin selama upaya sebelumnya. n adalah jumlah detik untuk menunggu di antara coba lagi. /W:n sering digunakan bersama dengan /R:n.
/BMenjalankan Robocopy dalam mode yang sama dengan yang akan digunakan aplikasi cadangan. Pengalih ini memungkinkan Robocopy memindahkan file yang izinnya tidak dimiliki pengguna saat ini. Sakelar cadangan bergantung pada menjalankan perintah Robocopy di konsol tinggi administrator atau jendela PowerShell. Jika Anda menggunakan Robocopy untuk Azure Files, pastikan Anda memasang berbagi file Azure menggunakan kunci akses akun penyimpanan vs. identitas domain. Jika tidak, pesan kesalahan mungkin tidak secara intuitif mengarahkan Anda ke resolusi masalah.
/MIR(Mencerminkan sumber ke target.) Memungkinkan Robocopy menyalin hanya delta antara sumber serta target. Subdirektori kosong akan disalin. Item (file atau folder) yang telah berubah atau tidak ada pada target akan disalin. Item yang ada pada target tetapi tidak pada sumber akan dihapus menyeluruh (dihapus) dari target. Saat Anda menggunakan pengalih ini, cocokkan struktur folder sumber dan target. Pencocokan berarti menyalin dari tingkat sumber dan folder yang benar ke tingkat folder yang cocok pada target. Hanya dengan begitu salinan "catch up" bisa berhasil. Saat sumber dan target tidak cocok, penggunaan /MIR akan menyebabkan penghapusan dan penyalinan ulang dalam skala besar.
/ITMemastikan fidelitas dipertahankan dalam skenario cermin tertentu.
Misalnya, jika file mengalami perubahan ACL dan pembaruan atribut di antara dua proses Robocopy, file tersebut akan ditandai sebagai tersembunyi. Tanpa /IT, perubahan ACL mungkin terlewatkan oleh Robocopy dan tidak ditransfer ke lokasi target.
/COPY:[copyflags]Fidelitas salinan file. Default: /COPY:DAT. Bendera salinan: D= Data, A= Atribut, T= Tanda waktu, S= Keamanan = ACL NTFS, O= Informasi pemilik, U= Informasi audit. Informasi audit tidak dapat disimpan dalam berbagi file Azure.
/DCOPY:[copyflags]Fidelitas untuk salinan direktori. Default: /DCOPY:DA. Bendera salinan: D= Data, A= Atribut, T= Tanda waktu.
/NPMenentukan bahwa perkembangan penyalinan untuk setiap file dan folder tidak akan ditampilkan. Menampilkan kemajuan secara signifikan menurunkan performa salinan.
/NFLMenentukan bahwa nama file tidak dicatat. Meningkatkan performa salinan.
/NDLMenentukan bahwa nama direktori tidak dicatat. Meningkatkan performa salinan.
/XDMenentukan direktori yang akan dikecualikan. Saat menjalankan Robocopy pada akar volume, pertimbangkan untuk mengecualikan System Volume Informationfolder tersembunyi. Jika digunakan seperti yang dirancang, semua informasi di sana spesifik untuk volume yang tepat pada sistem yang tepat ini dan dapat dibangun kembali sesuai permintaan. Menyalin informasi ini tidak akan membantu di cloud atau ketika data pernah disalin kembali ke volume Windows lain. Meninggalkan konten ini di belakang tidak dianggap kehilangan data.
/UNILOG:<file name>Menulis status ke file log sebagai Unicode. (Menimpa log yang ada.)
/LHanya untuk file uji coba
yang hanya akan dicantumkan. Mereka tidak akan disalin, tidak dihapus, dan tidak waktu dicap. Sering digunakan dengan /TEE untuk keluaran konsol. Bendera dari skrip sampel, seperti /NP, /NFL, dan /NDL, mungkin perlu dihapus untuk mendapatkan hasil pengujian yang terdokumentasi dengan baik.
/LFSMHanya untuk target dengan penyimpanan bertingkat. Tidak didukung ketika tujuan adalah berbagi SMB jarak jauh.
Menentukan bahwa Robocopy beroperasi dalam "mode ruang kosong rendah." Sakelar ini hanya berguna untuk target dengan penyimpanan berjenjang yang mungkin kehabisan kapasitas lokal sebelum Robocopy selesai. Ini ditambahkan khusus untuk digunakan dengan target yang diaktifkan untuk tingkatan cloud Azure File Sync. Ini dapat digunakan secara terpisah dari Azure File Sync. Dalam mode ini, Robocopy akan berhenti sejenak setiap kali salinan file akan menyebabkan ruang bebas volume tujuan berada di bawah nilai "lantai". Nilai ini dapat ditentukan oleh bentuk /LFSM:n bendera. Parameter n ditentukan dalam basis 2: nKB, nMB atau nGB. /LFSMJika ditentukan tanpa nilai lantai eksplisit, lantai diatur ke 10 persen dari ukuran volume tujuan. Mode ruang bebas rendah tidak kompatibel dengan /MT, /EFSRAW, atau /ZB. Dukungan untuk /B ditambahkan di Windows Server 2022. Silakan lihat bagian Windows Server 2022 dan RoboCopy LFSM di bawah ini untuk informasi selengkapnya, termasuk detail mengenai bug dan solusi terkait.
/ZGunakan salin file dengan hati-hati
dalam mode hidupkan ulang. Pengalih ini hanya disarankan dalam lingkungan jaringan yang tidak stabil. Ini secara signifikan mengurangi performa salinan karena pengelogan ekstra.
/ZBGunakan dengan hati-hati
Menggunakan mode hidupkan ulang. Jika akses ditolak, opsi ini menggunakan mode pencadangan. Opsi ini secara signifikan mengurangi performa salinan karena titik pemeriksaan.
Penting
Sebaiknya gunakan Windows Server 2022. Saat menggunakan Windows Server 2019, pastikan pada tingkat patch terbaru atau setidaknya pembaruan OS KB5005103 terpasang. Ini berisi perbaikan penting untuk skenario Robocopy tertentu.
Jika Anda menyediakan lebih sedikit penyimpanan di instans Windows Server daripada yang digunakan oleh {i>fileappliance cloudtingkatan cloud akan dimulai dan file tingkat yang telah berhasil disinkronkan. Cloud tiering akan menghasilkan ruang yang cukup untuk melanjutkan penyalinan dari appliance NAS. Pemeriksaan tingkatan {i>cloud disk
Robocopy mungkin perlu memindahkan lebih banyak {i>file file /MIR akan memastikan bahwa hanya delta yang dipindahkan. Setelah delta dipindahkan, pekerjaan menghidupkan ulang tidak perlu memindahkan {i>file
Ambil jalan pintas
Saat Anda menjalankan perintah RoboCopy untuk pertama kalinya, pengguna dan aplikasi Anda masih mengakses {i>file file
Proses pertama adalah tentang memindahkan sebagian besar data {i>churn cloud
- Bandwidth unggahan.
- Kecepatan jaringan lokal dan seberapa optimal jumlah alur RoboCopy yang cocok.
- Jumlah item ({i>file
Setelah proses awal selesai, jalankan kembali perintah tersebut.
Robocopy akan selesai lebih cepat untuk kedua kalinya Anda menjalankannya untuk berbagi. Hanya perlu membawa perubahan yang terjadi sejak eksekusi terakhir. Anda dapat menjalankan pekerjaan berulang untuk berbagi yang sama.
Saat Anda menilai bahwa waktu hentinya dapat diterima, Anda harus menghapus akses pengguna ke berbagi yang berbasis NAS Anda. Anda dapat melakukannya melalui langkah apa pun yang dapat mencegah pengguna mengubah struktur dan konten {i>file namespace
Jalankan Robocopy untuk terakhir kalinya. Proses ini akan menemukan perubahan apa pun, yang mungkin terlewat sebelumnya.
Berapa lama langkah terakhir ini bergantung pada kecepatan pemindaian Robocopy. Anda dapat memperkirakan waktu (yang sebanding dengan waktu henti Anda) dengan mengukur berapa lama eksekusi alur sebelumnya.
Buat berbagi di folder Windows Server dan kemungkinan sesuaikan penyebaran DFS-N Anda untuk mengarahkannya ke sana. Pastikan untuk mengatur izin akses level berbagi yang sama seperti di berbagi NAS SMB Anda. Jika Anda memiliki NAS kelas {i>enterprise file metadata
- Membuat kembali pengguna-pengguna ini sebagai pengguna lokal Windows Server.
- Memetakan SID yang sudah ada yang dipindahkan Robocopy ke instans Windows Server Anda ke SID pengguna lokal Windows Server baru.
Anda telah selesai memigrasikan berbagi atau grup berbagi ke dalam akar atau volume yang sama (bergantung pada pemetaan Anda dari Fase 1).
Anda dapat mencoba menjalankan beberapa salinan ini secara paralel. Sebaiknya proses cakupan dari satu berbagi {i>file
Opsi tidak digunakan lagi: "transfer data offline"
Sebelum agen Azure File Sync versi 13 dirilis, integrasi Data Box dilakukan melalui proses yang disebut "transfer data offline". Proses ini tidak digunakan lagi, dan Anda tidak dapat lagi membuat titik akhir server dalam mode "transfer data offline". Dengan agen versi 13, ini diganti dengan langkah-langkah yang jauh lebih sederhana dan lebih cepat yang diuraikan dalam artikel ini.
Pemecahan Masalah
Masalah yang paling umum adalah bahwa perintah Robocopy gagal dengan “Volume penuh” di sisi Windows Server. Cloud tiering bertindak sekali setiap jam untuk mengevakuasi konten dari disk Windows Server lokal yang telah disinkronkan. Tujuannya adalah untuk mencapai 99% ruang kosong pada volume Anda.
Biarkan kemajuan sinkronisasi dan cloud tiering mengosongkan ruang disk. Anda dapat mengamatinya di File Explorer di Instans Windows Server Anda.
Ketika instans Windows Server Anda memiliki kapasitas tersedia yang cukup, jalankan kembali perintah untuk menyelesaikan masalah. Tidak ada yang putus dalam situasi ini. Anda bisa meneruskan dengan keyakinan. Ketidaknyamanan menjalankan perintah lagi adalah satu-satunya konsekuensi.
Untuk memecahkan masalah Azure File Sync, lihat artikel yang tercantum di bagian berikutnya.
Langkah berikutnya
Artikel berikut ini akan membantu Anda memahami opsi tingkat lanjut dan praktik terbaik untuk Azure Files dan Azure File Sync.
Sebelum Anda melanjutkan dengan panduan ini, tunggu sampai semua {i>file
Untuk menyelesaikan langkah ini, Anda memerlukan info masuk langganan Azure Anda.
Sumber daya inti yang akan dikonfigurasi untuk Sinkronisasi File Azure disebut Storage Sync Service. Disarankan agar Anda hanya menggunakan satu untuk semua server yang menyinkronkan kumpulan file yang sama sekarang atau di masa mendatang. Buat beberapa Storage Sync Service hanya jika Anda memiliki kumpulan server berbeda yang tidak boleh bertukar data. Misalnya, Anda mungkin memiliki server yang tidak boleh menyinkronkan berbagi file Azure yang sama. Jika tidak, menggunakan Storage Sync Service tunggal adalah praktik terbaik.
Pilih wilayah Azure untuk Storage Sync Service yang dekat dengan lokasi Anda. Semua sumber daya cloud lainnya harus disebarkan di wilayah yang sama. Untuk menyederhanakan manajemen, buat grup sumber daya baru di langganan Anda yang menampung sumber daya sinkronisasi dan penyimpanan.
Untuk informasi selengkapnya, lihat bagian tentang menyebarkan Storage Sync Service di artikel tentang menyebarkan Sinkronisasi File Azure. Ikuti hanya bagian artikel ini. Akan ada tautan ke bagian lain dari artikel di langkah-langkah selanjutnya.
Fase 7: Terapkan alat Azure File Sync
Di bagian ini, Anda memasang agen Azure File Sync pada instans Windows Server Anda.
Panduan penyebaran menjelaskan bahwa Anda perlu menonaktifkan Konfigurasi Keamanan Tingkat Tinggi Internet Explorer. Langkah keamanan ini tidak berlaku untuk Azure File Sync. Menonaktifkannya memungkinkan Anda mengautentikasi ke Azure tanpa masalah.
Buka PowerShell. Pasang modul PowerShell yang diperlukan dengan menggunakan perintah berikut. Pastikan untuk memasang modul lengkap dan penyedia NuGet ketika Anda diminta untuk melakukannya.
Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync
Jika Anda memiliki masalah menjangkau internet dari server Anda, sekarang saatnya untuk menyelesaikannya. Azure File Sync menggunakan koneksi jaringan yang tersedia ke internet. Mengharuskan server proxy untuk menjangkau internet juga didukung. Anda dapat mengonfigurasi proksi di seluruh komputer sekarang atau, selama penginstalan agen, tentukan proksi yang hanya akan digunakan oleh Azure File Sync.
Jika mengonfigurasi proxy berarti Anda perlu membuka firewall untuk server, pendekatan tersebut mungkin dapat diterima oleh Anda. Di akhir penginstalan server, setelah Anda menyelesaikan pendaftaran server, laporan konektivitas jaringan akan menunjukkan titik akhir URL yang tepat di Azure yang perlu dikomunikasikan dengan Azure File Sync untuk wilayah yang Anda pilih. Laporan ini juga memberi tahu Anda mengapa komunikasi diperlukan. Anda dapat menggunakan laporan untuk mengunci firewall di sekitar server ke URL tertentu.
Anda juga dapat mengambil pendekatan yang lebih konservatif ketika Anda tidak membuka firewall lebar-lebar. Sebagai gantinya, Anda dapat membatasi server untuk berkomunikasi dengan ruang nama DNS tingkat lebih tinggi. Untuk informasi selengkapnya, lihat Proksi Azure File Sync dan pengaturan firewall. Ikuti praktik terbaik jaringan Anda sendiri.
Di akhir wisaya pemasangan wisaya server, wisaya pendaftaran server akan terbuka. Daftarkan server ke sumber daya Azure Storage Sync Service Anda dari yang lebih lama.
Langkah-langkah ini dijelaskan secara lebih rinci dalam panduan penyebaran, yang mencakup modul PowerShell yang harus Anda pasang terlebih dahulu: Pemasangan agen Azure File Sync.
Gunakan agen terbaru. Anda dapat mengunduhnya dari Pusat Unduhan Microsoft: Azure File Sync Agent.
Setelah penginstalan dan pendaftaran server berhasil, Anda dapat mengonfirmasi bahwa Anda telah berhasil menyelesaikan langkah ini. Buka sumber daya Storage Sync Service di portal Microsoft Azure. Di menu sebelah kiri, buka Server terdaftar. Anda akan melihat server Anda tercantum di sana.
Fase 8: Konfigurasikan Azure File Sync pada instans Windows Server
Instans Windows Server lokal Anda yang terdaftar harus siap dan terhubung ke internet untuk proses ini.
Langkah ini menyatukan semua sumber daya dan folder yang telah Anda siapkan di instans Windows Server Anda selama langkah sebelumnya.
- Masuk ke portal Azure.
- Temukan sumber daya Storage Sync Service Anda.
- Buat grup sinkronisasi baru dalam sumber daya Storage Sync Service untuk setiap berbagi file Azure. Di terminologi Sinkronisasi File Azure, berbagi file Azure akan menjadi titik akhir cloud di topologi sinkronisasi yang Anda jelaskan dengan pembuatan grup sinkronisasi. Saat Anda membuat grup sinkronisasi, beri nama yang familier sehingga Anda mengenali kumpulan file mana yang disinkronkan di sana. Pastikan Anda mereferensikan berbagi file Azure dengan nama yang cocok.
- Setelah Anda membuat grup sinkronisasi, baris untuk grup tersebut akan muncul dalam daftar grup sinkronisasi. Pilih nama (tautan) untuk menampilkan konten grup sinkronisasi. Anda akan melihat berbagi file Azure di Titik akhir Cloud.
- Temukan tombol Tambahkan Titik Akhir Server. Folder di server lokal yang telah Anda provisikan akan menjadi jalur untuk titik akhir server ini.
Aktifkan fitur penjenjangan cloud dan pilih Namespace hanya di bagian unduhan awal.
Penting
Tingkatan {i>cloud
Untuk semua berbagi file Azure / lokasi server yang perlu Anda konfigurasikan untuk sinkronisasi, ulangi langkah-langkah untuk membuat grup sinkronisasi dan menambahkan folder server yang cocok sebagai titik akhir server. Tunggu sampai sinkronisasi {i>namespace
Catatan
Setelah Anda membuat titik akhir {i>server
Fase 9: Tunggu {i>namespace
Sebelum Anda melanjutkan langkah selanjutnya dari migrasi Anda, tunggu sampai {i>servernamespace cloudfile server file
Untuk menentukan apakah {i>server
Cari peristiwa 9102 terbaru.
ID Peristiwa 9102 dicatat ketika sesi sinkronisasi selesai. Dalam teks peristiwa, ada bidang untuk petunjuk sinkronisasi unduhan. (HResult harus nol, dan file perlu diunduh.)
Anda ingin melihat dua peristiwa berturut-turut dari jenis ini, dengan konten ini, untuk memastikan bahwa {i>server namespace
Fase 10: Jalankan Robocopy dari NAS Anda
Setelah {i>server namespace cloud
Dalam langkah ini, Anda akan menjalankan pekerjaan RoboCopy untuk sinkronisasi berbagi {i>cloud churn
Peringatan
Karena perilaku Robocopy yang mengalami kemunduran di Windows Server 2019, sakelar Robocopy /MIR tidak kompatibel dengan direktori target bertingkat. Anda tidak dapat menggunakan Windows Server 2019 atau klien Windows 10 untuk fase migrasi ini. Gunakan Robocopy pada instans Windows Server 2016 menengah.
Berikut adalah pendekatan migrasi dasar:
- Jalankan Robocopy dari appliance NAS Anda untuk sinkronisasi instans Windows Server Anda.
- Gunakan Azure File Sync untuk sinkronisasi berbagi {i>file
Jalankan salinan lokal pertama ke folder target di Windows Server Anda:
- Identifikasi lokasi pertama di appliance NAS Anda.
- Identifikasi folder yang cocok pada instans Windows Server yang sudah memiliki Azure File Sync yang dikonfigurasi di dalamnya.
- Mulai penyalinan menggunakan Robocopy.
Perintah RoboCopy berikut hanya akan menyalin perbedaan ({i>file
robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
Mengalihkan
Makna
/MT:nMemungkinkan Robocopy untuk menjalankan multiutas. Default untuk n adalah 8. Maksimum adalah 128 utas. Sementara jumlah utas yang tinggi membantu memenuhi bandwidth yang tersedia, itu tidak berarti migrasi Anda akan selalu lebih cepat dengan lebih banyak utas. Pengujian dengan Azure Files menunjukkan antara 8 dan 20 memperlihatkan kinerja yang seimbang untuk menjalankan salinan awal. Proses /MIR berikutnya secara progresif dipengaruhi oleh komputasi yang tersedia vs bandwidth jaringan yang tersedia. Untuk proses selanjutnya, cocokkan nilai jumlah utas Anda lebih dekat dengan jumlah inti prosesor dan jumlah utas per inti Anda. Pertimbangkan apakah core perlu dicadangkan untuk tugas lain yang mungkin dilakukan oleh server produksi. Pengujian dengan Azure Files telah menunjukkan bahwa hingga 64 utas menghasilkan performa yang baik, tetapi hanya jika prosesor Anda dapat membuatnya tetap hidup pada saat yang sama.
/R:nJumlah coba lagi maksimum untuk file yang gagal disalin pada upaya pertama. Robocopy akan mencoba n waktu sebelum file secara permanen gagal menjalankan salinan. Anda dapat mengoptimalkan kinerja yang Anda jalankan: Pilih nilai dua atau tiga jika Anda yakin masalah batas waktu menyebabkan kegagalan di masa lalu. Ini mungkin lebih umum melalui tautan WAN. Pilih tidak mencoba ulang atau nilai satu jika Anda yakin file gagal menyalin karena sedang digunakan secara aktif. Mencoba lagi beberapa detik kemudian mungkin tidak cukup waktu untuk status file yang digunakan untuk berubah. Pengguna atau aplikasi yang menahan file terbuka mungkin memerlukan waktu beberapa jam lebih lama. Dalam hal ini, menerima file tidak disalin dan menangkapnya di salah satu rencana Anda, Robocopy berjalan berikutnya, mungkin akhirnya berhasil dalam menyalin file dengan sukses. Hal itu membantu eksekusi saat ini untuk menyelesaikan lebih cepat tanpa diperpanjang oleh banyak percobaan ulang yang akhirnya berakhir di sebagian besar kegagalan salinan karena file masih terbuka melewati batas waktu percobaan ulang.
/W:nMenentukan waktu tunggu Robocopy sebelum mencoba menyalin file yang tidak berhasil disalin selama upaya sebelumnya. n adalah jumlah detik untuk menunggu di antara coba lagi. /W:n sering digunakan bersama dengan /R:n.
/BMenjalankan Robocopy dalam mode yang sama dengan yang akan digunakan aplikasi cadangan. Pengalih ini memungkinkan Robocopy memindahkan file yang izinnya tidak dimiliki pengguna saat ini. Sakelar cadangan bergantung pada menjalankan perintah Robocopy di konsol tinggi administrator atau jendela PowerShell. Jika Anda menggunakan Robocopy untuk Azure Files, pastikan Anda memasang berbagi file Azure menggunakan kunci akses akun penyimpanan vs. identitas domain. Jika tidak, pesan kesalahan mungkin tidak secara intuitif mengarahkan Anda ke resolusi masalah.
/MIR(Mencerminkan sumber ke target.) Memungkinkan Robocopy menyalin hanya delta antara sumber serta target. Subdirektori kosong akan disalin. Item (file atau folder) yang telah berubah atau tidak ada pada target akan disalin. Item yang ada pada target tetapi tidak pada sumber akan dihapus menyeluruh (dihapus) dari target. Saat Anda menggunakan pengalih ini, cocokkan struktur folder sumber dan target. Pencocokan berarti menyalin dari tingkat sumber dan folder yang benar ke tingkat folder yang cocok pada target. Hanya dengan begitu salinan "catch up" bisa berhasil. Saat sumber dan target tidak cocok, penggunaan /MIR akan menyebabkan penghapusan dan penyalinan ulang dalam skala besar.
/ITMemastikan fidelitas dipertahankan dalam skenario cermin tertentu.
Misalnya, jika file mengalami perubahan ACL dan pembaruan atribut di antara dua proses Robocopy, file tersebut akan ditandai sebagai tersembunyi. Tanpa /IT, perubahan ACL mungkin terlewatkan oleh Robocopy dan tidak ditransfer ke lokasi target.
/COPY:[copyflags]Fidelitas salinan file. Default: /COPY:DAT. Bendera salinan: D= Data, A= Atribut, T= Tanda waktu, S= Keamanan = ACL NTFS, O= Informasi pemilik, U= Informasi audit. Informasi audit tidak dapat disimpan dalam berbagi file Azure.
/DCOPY:[copyflags]Fidelitas untuk salinan direktori. Default: /DCOPY:DA. Bendera salinan: D= Data, A= Atribut, T= Tanda waktu.
/NPMenentukan bahwa perkembangan penyalinan untuk setiap file dan folder tidak akan ditampilkan. Menampilkan kemajuan secara signifikan menurunkan performa salinan.
/NFLMenentukan bahwa nama file tidak dicatat. Meningkatkan performa salinan.
/NDLMenentukan bahwa nama direktori tidak dicatat. Meningkatkan performa salinan.
/XDMenentukan direktori yang akan dikecualikan. Saat menjalankan Robocopy pada akar volume, pertimbangkan untuk mengecualikan System Volume Informationfolder tersembunyi. Jika digunakan seperti yang dirancang, semua informasi di sana spesifik untuk volume yang tepat pada sistem yang tepat ini dan dapat dibangun kembali sesuai permintaan. Menyalin informasi ini tidak akan membantu di cloud atau ketika data pernah disalin kembali ke volume Windows lain. Meninggalkan konten ini di belakang tidak dianggap kehilangan data.
/UNILOG:<file name>Menulis status ke file log sebagai Unicode. (Menimpa log yang ada.)
/LHanya untuk file uji coba
yang hanya akan dicantumkan. Mereka tidak akan disalin, tidak dihapus, dan tidak waktu dicap. Sering digunakan dengan /TEE untuk keluaran konsol. Bendera dari skrip sampel, seperti /NP, /NFL, dan /NDL, mungkin perlu dihapus untuk mendapatkan hasil pengujian yang terdokumentasi dengan baik.
/LFSMHanya untuk target dengan penyimpanan bertingkat. Tidak didukung ketika tujuan adalah berbagi SMB jarak jauh.
Menentukan bahwa Robocopy beroperasi dalam "mode ruang kosong rendah." Sakelar ini hanya berguna untuk target dengan penyimpanan berjenjang yang mungkin kehabisan kapasitas lokal sebelum Robocopy selesai. Ini ditambahkan khusus untuk digunakan dengan target yang diaktifkan untuk tingkatan cloud Azure File Sync. Ini dapat digunakan secara terpisah dari Azure File Sync. Dalam mode ini, Robocopy akan berhenti sejenak setiap kali salinan file akan menyebabkan ruang bebas volume tujuan berada di bawah nilai "lantai". Nilai ini dapat ditentukan oleh bentuk /LFSM:n bendera. Parameter n ditentukan dalam basis 2: nKB, nMB atau nGB. /LFSMJika ditentukan tanpa nilai lantai eksplisit, lantai diatur ke 10 persen dari ukuran volume tujuan. Mode ruang bebas rendah tidak kompatibel dengan /MT, /EFSRAW, atau /ZB. Dukungan untuk /B ditambahkan di Windows Server 2022. Silakan lihat bagian Windows Server 2022 dan RoboCopy LFSM di bawah ini untuk informasi selengkapnya, termasuk detail mengenai bug dan solusi terkait.
/ZGunakan salin file dengan hati-hati
dalam mode hidupkan ulang. Pengalih ini hanya disarankan dalam lingkungan jaringan yang tidak stabil. Ini secara signifikan mengurangi performa salinan karena pengelogan ekstra.
/ZBGunakan dengan hati-hati
Menggunakan mode hidupkan ulang. Jika akses ditolak, opsi ini menggunakan mode pencadangan. Opsi ini secara signifikan mengurangi performa salinan karena titik pemeriksaan.
Penting
Sebaiknya gunakan Windows Server 2022. Saat menggunakan Windows Server 2019, pastikan pada tingkat patch terbaru atau setidaknya pembaruan OS KB5005103 terpasang. Ini berisi perbaikan penting untuk skenario Robocopy tertentu.
Jika Anda menyediakan lebih sedikit penyimpanan di instans Windows Server daripada yang digunakan oleh {i>fileappliance cloudtingkatan cloud akan dimulai dan file tingkat yang telah berhasil disinkronkan. Cloud tiering akan menghasilkan ruang yang cukup untuk melanjutkan penyalinan dari appliance NAS. Pemeriksaan tingkatan {i>cloud disk
Robocopy mungkin perlu memindahkan lebih banyak {i>file file /MIR akan memastikan bahwa hanya delta yang dipindahkan. Setelah delta dipindahkan, pekerjaan menghidupkan ulang tidak perlu memindahkan {i>file
Ambil jalan pintas
Saat Anda menjalankan perintah RoboCopy untuk pertama kalinya, pengguna dan aplikasi Anda masih mengakses {i>file file
Proses pertama adalah tentang memindahkan sebagian besar data {i>churn cloud
- Bandwidth unggahan.
- Kecepatan jaringan lokal dan seberapa optimal jumlah alur RoboCopy yang cocok.
- Jumlah item ({i>file
Setelah proses awal selesai, jalankan kembali perintah tersebut.
Robocopy akan selesai lebih cepat untuk kedua kalinya Anda menjalankannya untuk berbagi. Hanya perlu membawa perubahan yang terjadi sejak eksekusi terakhir. Anda dapat menjalankan pekerjaan berulang untuk berbagi yang sama.
Saat Anda menilai bahwa waktu hentinya dapat diterima, Anda harus menghapus akses pengguna ke berbagi yang berbasis NAS Anda. Anda dapat melakukannya melalui langkah apa pun yang dapat mencegah pengguna mengubah struktur dan konten {i>file namespace
Jalankan Robocopy untuk terakhir kalinya. Proses ini akan menemukan perubahan apa pun, yang mungkin terlewat sebelumnya.
Berapa lama langkah terakhir ini bergantung pada kecepatan pemindaian Robocopy. Anda dapat memperkirakan waktu (yang sebanding dengan waktu henti Anda) dengan mengukur berapa lama eksekusi alur sebelumnya.
Buat berbagi di folder Windows Server dan kemungkinan sesuaikan penyebaran DFS-N Anda untuk mengarahkannya ke sana. Pastikan untuk mengatur izin akses level berbagi yang sama seperti di berbagi NAS SMB Anda. Jika Anda memiliki NAS kelas {i>enterprise file metadata
- Membuat kembali pengguna-pengguna ini sebagai pengguna lokal Windows Server.
- Memetakan SID yang sudah ada yang dipindahkan Robocopy ke instans Windows Server Anda ke SID pengguna lokal Windows Server baru.
Anda telah selesai memigrasikan berbagi atau grup berbagi ke dalam akar atau volume yang sama (bergantung pada pemetaan Anda dari Fase 1).
Anda dapat mencoba menjalankan beberapa salinan ini secara paralel. Sebaiknya proses cakupan dari satu berbagi {i>file
Opsi tidak digunakan lagi: "transfer data offline"
Sebelum agen Azure File Sync versi 13 dirilis, integrasi Data Box dilakukan melalui proses yang disebut "transfer data offline". Proses ini tidak digunakan lagi, dan Anda tidak dapat lagi membuat titik akhir server dalam mode "transfer data offline". Dengan agen versi 13, ini diganti dengan langkah-langkah yang jauh lebih sederhana dan lebih cepat yang diuraikan dalam artikel ini.
Pemecahan Masalah
Masalah yang paling umum adalah bahwa perintah Robocopy gagal dengan “Volume penuh” di sisi Windows Server. Cloud tiering bertindak sekali setiap jam untuk mengevakuasi konten dari disk Windows Server lokal yang telah disinkronkan. Tujuannya adalah untuk mencapai 99% ruang kosong pada volume Anda.
Biarkan kemajuan sinkronisasi dan cloud tiering mengosongkan ruang disk. Anda dapat mengamatinya di File Explorer di Instans Windows Server Anda.
Ketika instans Windows Server Anda memiliki kapasitas tersedia yang cukup, jalankan kembali perintah untuk menyelesaikan masalah. Tidak ada yang putus dalam situasi ini. Anda bisa meneruskan dengan keyakinan. Ketidaknyamanan menjalankan perintah lagi adalah satu-satunya konsekuensi.
Untuk memecahkan masalah Azure File Sync, lihat artikel yang tercantum di bagian berikutnya.
Langkah berikutnya
Artikel berikut ini akan membantu Anda memahami opsi tingkat lanjut dan praktik terbaik untuk Azure Files dan Azure File Sync.
Sebelum Anda melanjutkan langkah selanjutnya dari migrasi Anda, tunggu sampai {i>server
Untuk menentukan apakah {i>server
Cari peristiwa 9102 terbaru.
ID Peristiwa 9102 dicatat ketika sesi sinkronisasi selesai. Dalam teks peristiwa, ada bidang untuk petunjuk sinkronisasi unduhan. (HResult harus nol, dan file perlu diunduh.)
Anda ingin melihat dua peristiwa berturut-turut dari jenis ini, dengan konten ini, untuk memastikan bahwa {i>server
Fase 10: Jalankan Robocopy dari NAS Anda
Setelah {i>server
Dalam langkah ini, Anda akan menjalankan pekerjaan RoboCopy untuk sinkronisasi berbagi {i>cloud
Peringatan
Karena perilaku Robocopy yang mengalami kemunduran di Windows Server 2019, sakelar Robocopy /MIR tidak kompatibel dengan direktori target bertingkat. Anda tidak dapat menggunakan Windows Server 2019 atau klien Windows 10 untuk fase migrasi ini. Gunakan Robocopy pada instans Windows Server 2016 menengah.
Berikut adalah pendekatan migrasi dasar:
- Jalankan Robocopy dari appliance NAS Anda untuk sinkronisasi instans Windows Server Anda.
- Gunakan Azure File Sync untuk sinkronisasi berbagi {i>file
Jalankan salinan lokal pertama ke folder target di Windows Server Anda:
- Identifikasi lokasi pertama di appliance NAS Anda.
- Identifikasi folder yang cocok pada instans Windows Server yang sudah memiliki Azure File Sync yang dikonfigurasi di dalamnya.
- Mulai penyalinan menggunakan Robocopy.
Perintah RoboCopy berikut hanya akan menyalin perbedaan ({i>file
robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
| Mengalihkan | Makna |
|---|---|
/MT:n |
Memungkinkan Robocopy untuk menjalankan multiutas. Default untuk n adalah 8. Maksimum adalah 128 utas. Sementara jumlah utas yang tinggi membantu memenuhi bandwidth yang tersedia, itu tidak berarti migrasi Anda akan selalu lebih cepat dengan lebih banyak utas. Pengujian dengan Azure Files menunjukkan antara 8 dan 20 memperlihatkan kinerja yang seimbang untuk menjalankan salinan awal. Proses /MIR berikutnya secara progresif dipengaruhi oleh komputasi yang tersedia vs bandwidth jaringan yang tersedia. Untuk proses selanjutnya, cocokkan nilai jumlah utas Anda lebih dekat dengan jumlah inti prosesor dan jumlah utas per inti Anda. Pertimbangkan apakah core perlu dicadangkan untuk tugas lain yang mungkin dilakukan oleh server produksi. Pengujian dengan Azure Files telah menunjukkan bahwa hingga 64 utas menghasilkan performa yang baik, tetapi hanya jika prosesor Anda dapat membuatnya tetap hidup pada saat yang sama. |
/R:n |
Jumlah coba lagi maksimum untuk file yang gagal disalin pada upaya pertama. Robocopy akan mencoba n waktu sebelum file secara permanen gagal menjalankan salinan. Anda dapat mengoptimalkan kinerja yang Anda jalankan: Pilih nilai dua atau tiga jika Anda yakin masalah batas waktu menyebabkan kegagalan di masa lalu. Ini mungkin lebih umum melalui tautan WAN. Pilih tidak mencoba ulang atau nilai satu jika Anda yakin file gagal menyalin karena sedang digunakan secara aktif. Mencoba lagi beberapa detik kemudian mungkin tidak cukup waktu untuk status file yang digunakan untuk berubah. Pengguna atau aplikasi yang menahan file terbuka mungkin memerlukan waktu beberapa jam lebih lama. Dalam hal ini, menerima file tidak disalin dan menangkapnya di salah satu rencana Anda, Robocopy berjalan berikutnya, mungkin akhirnya berhasil dalam menyalin file dengan sukses. Hal itu membantu eksekusi saat ini untuk menyelesaikan lebih cepat tanpa diperpanjang oleh banyak percobaan ulang yang akhirnya berakhir di sebagian besar kegagalan salinan karena file masih terbuka melewati batas waktu percobaan ulang. |
/W:n |
Menentukan waktu tunggu Robocopy sebelum mencoba menyalin file yang tidak berhasil disalin selama upaya sebelumnya. n adalah jumlah detik untuk menunggu di antara coba lagi. /W:n sering digunakan bersama dengan /R:n. |
/B |
Menjalankan Robocopy dalam mode yang sama dengan yang akan digunakan aplikasi cadangan. Pengalih ini memungkinkan Robocopy memindahkan file yang izinnya tidak dimiliki pengguna saat ini. Sakelar cadangan bergantung pada menjalankan perintah Robocopy di konsol tinggi administrator atau jendela PowerShell. Jika Anda menggunakan Robocopy untuk Azure Files, pastikan Anda memasang berbagi file Azure menggunakan kunci akses akun penyimpanan vs. identitas domain. Jika tidak, pesan kesalahan mungkin tidak secara intuitif mengarahkan Anda ke resolusi masalah. |
/MIR |
(Mencerminkan sumber ke target.) Memungkinkan Robocopy menyalin hanya delta antara sumber serta target. Subdirektori kosong akan disalin. Item (file atau folder) yang telah berubah atau tidak ada pada target akan disalin. Item yang ada pada target tetapi tidak pada sumber akan dihapus menyeluruh (dihapus) dari target. Saat Anda menggunakan pengalih ini, cocokkan struktur folder sumber dan target. Pencocokan berarti menyalin dari tingkat sumber dan folder yang benar ke tingkat folder yang cocok pada target. Hanya dengan begitu salinan "catch up" bisa berhasil. Saat sumber dan target tidak cocok, penggunaan /MIR akan menyebabkan penghapusan dan penyalinan ulang dalam skala besar. |
/IT |
Memastikan fidelitas dipertahankan dalam skenario cermin tertentu. Misalnya, jika file mengalami perubahan ACL dan pembaruan atribut di antara dua proses Robocopy, file tersebut akan ditandai sebagai tersembunyi. Tanpa /IT, perubahan ACL mungkin terlewatkan oleh Robocopy dan tidak ditransfer ke lokasi target. |
/COPY:[copyflags] |
Fidelitas salinan file. Default: /COPY:DAT. Bendera salinan: D= Data, A= Atribut, T= Tanda waktu, S= Keamanan = ACL NTFS, O= Informasi pemilik, U= Informasi audit. Informasi audit tidak dapat disimpan dalam berbagi file Azure. |
/DCOPY:[copyflags] |
Fidelitas untuk salinan direktori. Default: /DCOPY:DA. Bendera salinan: D= Data, A= Atribut, T= Tanda waktu. |
/NP |
Menentukan bahwa perkembangan penyalinan untuk setiap file dan folder tidak akan ditampilkan. Menampilkan kemajuan secara signifikan menurunkan performa salinan. |
/NFL |
Menentukan bahwa nama file tidak dicatat. Meningkatkan performa salinan. |
/NDL |
Menentukan bahwa nama direktori tidak dicatat. Meningkatkan performa salinan. |
/XD |
Menentukan direktori yang akan dikecualikan. Saat menjalankan Robocopy pada akar volume, pertimbangkan untuk mengecualikan System Volume Informationfolder tersembunyi. Jika digunakan seperti yang dirancang, semua informasi di sana spesifik untuk volume yang tepat pada sistem yang tepat ini dan dapat dibangun kembali sesuai permintaan. Menyalin informasi ini tidak akan membantu di cloud atau ketika data pernah disalin kembali ke volume Windows lain. Meninggalkan konten ini di belakang tidak dianggap kehilangan data. |
/UNILOG:<file name> |
Menulis status ke file log sebagai Unicode. (Menimpa log yang ada.) |
/L |
Hanya untuk file uji coba yang hanya akan dicantumkan. Mereka tidak akan disalin, tidak dihapus, dan tidak waktu dicap. Sering digunakan dengan /TEE untuk keluaran konsol. Bendera dari skrip sampel, seperti /NP, /NFL, dan /NDL, mungkin perlu dihapus untuk mendapatkan hasil pengujian yang terdokumentasi dengan baik. |
/LFSM |
Hanya untuk target dengan penyimpanan bertingkat. Tidak didukung ketika tujuan adalah berbagi SMB jarak jauh. Menentukan bahwa Robocopy beroperasi dalam "mode ruang kosong rendah." Sakelar ini hanya berguna untuk target dengan penyimpanan berjenjang yang mungkin kehabisan kapasitas lokal sebelum Robocopy selesai. Ini ditambahkan khusus untuk digunakan dengan target yang diaktifkan untuk tingkatan cloud Azure File Sync. Ini dapat digunakan secara terpisah dari Azure File Sync. Dalam mode ini, Robocopy akan berhenti sejenak setiap kali salinan file akan menyebabkan ruang bebas volume tujuan berada di bawah nilai "lantai". Nilai ini dapat ditentukan oleh bentuk /LFSM:n bendera. Parameter n ditentukan dalam basis 2: nKB, nMB atau nGB. /LFSMJika ditentukan tanpa nilai lantai eksplisit, lantai diatur ke 10 persen dari ukuran volume tujuan. Mode ruang bebas rendah tidak kompatibel dengan /MT, /EFSRAW, atau /ZB. Dukungan untuk /B ditambahkan di Windows Server 2022. Silakan lihat bagian Windows Server 2022 dan RoboCopy LFSM di bawah ini untuk informasi selengkapnya, termasuk detail mengenai bug dan solusi terkait. |
/Z |
Gunakan salin file dengan hati-hati dalam mode hidupkan ulang. Pengalih ini hanya disarankan dalam lingkungan jaringan yang tidak stabil. Ini secara signifikan mengurangi performa salinan karena pengelogan ekstra. |
/ZB |
Gunakan dengan hati-hati Menggunakan mode hidupkan ulang. Jika akses ditolak, opsi ini menggunakan mode pencadangan. Opsi ini secara signifikan mengurangi performa salinan karena titik pemeriksaan. |
Penting
Sebaiknya gunakan Windows Server 2022. Saat menggunakan Windows Server 2019, pastikan pada tingkat patch terbaru atau setidaknya pembaruan OS KB5005103 terpasang. Ini berisi perbaikan penting untuk skenario Robocopy tertentu.
Jika Anda menyediakan lebih sedikit penyimpanan di instans Windows Server daripada yang digunakan oleh {i>file
Robocopy mungkin perlu memindahkan lebih banyak {i>file
Ambil jalan pintas
Saat Anda menjalankan perintah RoboCopy untuk pertama kalinya, pengguna dan aplikasi Anda masih mengakses {i>file
Proses pertama adalah tentang memindahkan sebagian besar data {i>churn
- Bandwidth unggahan.
- Kecepatan jaringan lokal dan seberapa optimal jumlah alur RoboCopy yang cocok.
- Jumlah item ({i>file
Setelah proses awal selesai, jalankan kembali perintah tersebut.
Robocopy akan selesai lebih cepat untuk kedua kalinya Anda menjalankannya untuk berbagi. Hanya perlu membawa perubahan yang terjadi sejak eksekusi terakhir. Anda dapat menjalankan pekerjaan berulang untuk berbagi yang sama.
Saat Anda menilai bahwa waktu hentinya dapat diterima, Anda harus menghapus akses pengguna ke berbagi yang berbasis NAS Anda. Anda dapat melakukannya melalui langkah apa pun yang dapat mencegah pengguna mengubah struktur dan konten {i>file
Jalankan Robocopy untuk terakhir kalinya. Proses ini akan menemukan perubahan apa pun, yang mungkin terlewat sebelumnya. Berapa lama langkah terakhir ini bergantung pada kecepatan pemindaian Robocopy. Anda dapat memperkirakan waktu (yang sebanding dengan waktu henti Anda) dengan mengukur berapa lama eksekusi alur sebelumnya.
Buat berbagi di folder Windows Server dan kemungkinan sesuaikan penyebaran DFS-N Anda untuk mengarahkannya ke sana. Pastikan untuk mengatur izin akses level berbagi yang sama seperti di berbagi NAS SMB Anda. Jika Anda memiliki NAS kelas {i>enterprise
- Membuat kembali pengguna-pengguna ini sebagai pengguna lokal Windows Server.
- Memetakan SID yang sudah ada yang dipindahkan Robocopy ke instans Windows Server Anda ke SID pengguna lokal Windows Server baru.
Anda telah selesai memigrasikan berbagi atau grup berbagi ke dalam akar atau volume yang sama (bergantung pada pemetaan Anda dari Fase 1).
Anda dapat mencoba menjalankan beberapa salinan ini secara paralel. Sebaiknya proses cakupan dari satu berbagi {i>file
Opsi tidak digunakan lagi: "transfer data offline"
Sebelum agen Azure File Sync versi 13 dirilis, integrasi Data Box dilakukan melalui proses yang disebut "transfer data offline". Proses ini tidak digunakan lagi, dan Anda tidak dapat lagi membuat titik akhir server dalam mode "transfer data offline". Dengan agen versi 13, ini diganti dengan langkah-langkah yang jauh lebih sederhana dan lebih cepat yang diuraikan dalam artikel ini.
Pemecahan Masalah
Masalah yang paling umum adalah bahwa perintah Robocopy gagal dengan “Volume penuh” di sisi Windows Server. Cloud tiering bertindak sekali setiap jam untuk mengevakuasi konten dari disk Windows Server lokal yang telah disinkronkan. Tujuannya adalah untuk mencapai 99% ruang kosong pada volume Anda.
Biarkan kemajuan sinkronisasi dan cloud tiering mengosongkan ruang disk. Anda dapat mengamatinya di File Explorer di Instans Windows Server Anda.
Ketika instans Windows Server Anda memiliki kapasitas tersedia yang cukup, jalankan kembali perintah untuk menyelesaikan masalah. Tidak ada yang putus dalam situasi ini. Anda bisa meneruskan dengan keyakinan. Ketidaknyamanan menjalankan perintah lagi adalah satu-satunya konsekuensi.
Untuk memecahkan masalah Azure File Sync, lihat artikel yang tercantum di bagian berikutnya.
Langkah berikutnya
Artikel berikut ini akan membantu Anda memahami opsi tingkat lanjut dan praktik terbaik untuk Azure Files dan Azure File Sync.