Menggunakan RoboCopy untuk melakukan migrasi ke berbagi file Azure

Artikel migrasi ini menjelaskan penggunaan RoboCopy untuk memindahkan atau memigrasikan file ke berbagi file Azure. RoboCopy adalah utilitas penyalinan file tepercaya dan terkenal dengan set fitur yang membuatnya sangat cocok untuk melakukan migrasi. RoboCopy menggunakan protokol SMB yang membuatnya dapat diterapkan secara luas untuk kombinasi sumber dan target apa pun, sehingga mendukung SMB.

  • Sumber data: Sumber apa pun yang mendukung protokol SMB, seperti Penyimpanan yang Terhubung ke Jaringan (Network Attached Storage/NAS), server Windows atau Linux, berbagi file Azure lain, dan banyak lagi
  • Rute migrasi: Dari penyimpanan sumber ⇒ komputer Windows dengan RoboCopy ⇒ berbagi file Azure

Ada banyak rute migrasi yang berbeda untuk kombinasi sumber dan penyebaran yang berbeda. Bacalah tabel panduan migrasi untuk menemukan migrasi yang paling sesuai dengan kebutuhan Anda.

Berlaku untuk

Jenis berbagi File SMB NFS
Berbagi file standar (GPv2), LRS/ZRS Ya Tidak
Berbagi file standar (GPv2), GRS/GZRS Ya Tidak
Berbagi file premium (FileStorage), LRS/ZRS Ya Tidak

AzCopy vs. RoboCopy

AzCopy dan RoboCopy adalah dua alat penyalin file yang pada dasarnya berbeda. RoboCopy menggunakan versi protokol SMB apa pun. AzCopy adalah alat "born-in-the-cloud" yang dapat digunakan untuk memindahkan data selama target berada di penyimpanan Azure. AzCopy bergantung pada protokol REST.

RoboCopy, sebagai alat penyalin berbasis Windows yang tepercaya, memiliki keuntungan lokal dalam hal menyalin file dengan ketelitian penuh. RoboCopy mendukung banyak skenario migrasi karena kekayaan set fiturnya dan kemampuannya untuk menyalin file dan folder dengan ketelitian penuh. Lihat bagian ketelitian file dalam artikel gambaran umum migrasi untuk mempelajari selengkapnya tentang pentingnya menyalin file dengan ketelitian maksimal.

Di sisi lain, AzCopy baru akhir-akhir ini berekspansi untuk mendukung penyalinan file dengan tingkat ketelitian tertentu dan telah menambahkan fitur pertama yang perlu dipertimbangkan sebagai alat migrasi. Namun, masih ada kesenjangan dan dapat dengan mudah terjadi kesalahpahaman fungsionalitas ketika membandingkan bendera AzCopy dengan bendera RoboCopy.

Contoh: RoboCopy/MIR akan mencerminkan sumber ke target, yang berarti file yang ditambahkan, diubah, dan dihapus akan diperhitungkan. Perbedaan penting dengan AzCopy -sync adalah bahwa file yang dihapus pada sumber tidak akan dihapus pada target. Hal itu akan menghasilkan set fitur salinan diferensial yang tidak sempurna. AzCopy akan terus berkembang. Namun, untuk saat ini, AzCopy bukanlah alat yang direkomendasikan untuk skenario migrasi dengan berbagi file Azure sebagai target.

Tujuan migrasi

Tujuannya adalah untuk memindahkan data dari lokasi berbagi file yang ada ke Azure. Di Azure, Anda akan menyimpan data dalam berbagi file Azure asli yang dapat Anda gunakan tanpa perlu Windows Server. Migrasi ini harus dilakukan dengan cara yang menjamin integritas data produksi dan ketersediaan selama migrasi. Yang disebut belakangan mengharuskan menekan downtime seminimum mungkin sehingga dapat cocok atau sedikit melebihi jendela pemeliharaan reguler.

Gambaran umum migrasi

Proses migrasi terdiri dari beberapa fase. Anda harus menggunakan akun penyimpanan Azure dan berbagi file. Selain itu, Anda juga perlu mengonfigurasi jaringan, mempertimbangkan penggunaan DFS Namespaces (DFS-N), atau memperbarui yang sudah ada. Setelah tiba waktunya untuk benar-benar menyalin data, Anda harus mempertimbangkan eksekusi RoboCopy yang berulang dan diferensial untuk meminimalkan waktu henti dan terakhir, memindahkan pengguna Anda ke berbagi file Azure yang baru dibuat. Bagian yang berikut menjelaskan fase dari proses migrasi secara terperinci.

Tip

Jika Anda kembali ke artikel ini, gunakan navigasi di sisi kanan untuk melompat ke fase migrasi tempat Anda sebelumnya.

Fase 1: Identifikasi berapa banyak berbagi file Azure yang dibutuhkan

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

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

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

Berbagi pengelompokan

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

Sinkronisasi volume

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

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

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

Tip

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

Pendekatan terstruktur untuk peta penyebaran

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

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

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

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

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

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

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

Tip

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

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

Penting

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

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

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

Membuat tabel pemetaan

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

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

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


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

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: Bersiap menggunakan berbagi file Azure

Dengan informasi pada fase ini, Anda akan mampu memutuskan bagaimana server dan pengguna Anda di Azure dan di luar Azure akan berkemamuan menggunakan berbagi file Azure Anda. Keputusan yang paling kritikal adalah:

  • Jaringan: Aktifkan jaringan Anda untuk merutekan lalu lintas SMB.
  • Autentikasi: Konfigurasi akun penyimpanan Azure untuk autentikasi Kerberos. AdConnect dan Domain yang bergabung dengan akun penyimpanan Anda akan memungkinkan aplikasi dan pengguna Anda menggunakan identitas AD-nya untuk autentikasi
  • Otorisasi: ACL tingkat berbagi untuk setiap berbagi file Azure akan memungkinkan pengguna dan grup AD mengakses suatu berbagi yang diberikan dan di dalam berbagi file Azure, NTFS ACL setempat akan mengambil alih. Otorisasi yang didasarkan pada file dan ACL folder lalu mengerjakannya seperti berbagi SMB lokal.
  • Kontinuitas bisnis: Integrasi berbagi file Azure ke dalam lingkungan yang sudah ada seringkali menyebabkan pelestarian alamat berbagi yang ada. Jika Anda belum menggunakan DFS-Namespaces, pertimbangkan membuatnya di lingkungan Anda. Anda akan dapat menyimpan alamat berbagi pengguna Anda dan penggunaan skrip tanpa perubahan. DFS-N memberikan layanan perutean namespace untuk SMB dengan mengalihkan klien ke berbagi file Azure.

Video ini adalah panduan dan demo tentang cara menjelaskan berbagi file Azure dengan aman langsung ke pekerja informasi dan aplikasi dalam lima langkah sederhana.
Video ini merujuk kepada dokumentasi khusus untuk beberapa topik:

Memasang berbagi file Azure

Sebelum Anda dapat menggunakan RoboCopy, Anda harus memastikan berbagi file Azure dapat diakses pada SMB. Cara termudah adalah memasang berbagi sebagai drive jaringan lokal ke Windows Server yang Anda rencanakan gunakan untuk RoboCopy.

Penting

Sebelum Anda dapat memasangkan berbagi file Azure ke Windows Server lokal, Anda harus menyelesaikan Fase 3: Bersiap menggunakan berbagi file Azure.

Setelah Anda siap, baca artikel panduan tentang cara menggunakan berbagi file Azure dengan Windows. Kemudian, pasangkan berbagi file Azure yang untuknya Anda ingin menggunakan RoboCopy.

Fase 4: RoboCopy

Perintah RoboCopy berikut hanya akan menyalin perbedaan (file dan folder yang diperbarui) dari penyimpanan sumber ke berbagi file Azure Anda.

robocopy /MT:128 /R:1 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /UNILOG:<FilePathAndName> <SourcePath> <Dest.Path> 
Mengalihkan Makna
/MT:n Memungkinkan Robocopy untuk menjalankan multiutas. Default untuk n adalah 8. Maksimum adalah 128 utas. Mulailah dengan jumlah utas tinggi untuk eksekusi awal. Jumlah utas yang tinggi membantu memenuhi bandwidth yang tersedia. 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.
/R:n Jumlah coba lagi maksimum untuk file yang gagal disalin pada upaya pertama. Anda dapat meningkatkan kecepatan eksekusi Robocopy dengan menentukan angka maksimum (n) dari coba lagi sebelum file secara permanen gagal disalin dalam proses. Pengalih ini bekerja saat sudah jelas bahwa akan ada lebih banyak eksekusi Robocopy. Jika file gagal disalin dalam eksekusi saat ini, pekerjaan Robocopy berikutnya akan dicoba lagi. File yang gagal karena sedang digunakan atau karena masalah waktu habis akhirnya dapat berhasil disalin jika Anda menggunakan pendekatan ini.
/W:n Menentukan waktu Robocopy menunggu 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 oleh aplikasi cadangan. Pengalih ini memungkinkan Robocopy memindahkan file yang izinnya tidak dimiliki pengguna saat ini.
/MIR (Mencerminkan sumber ke target.) Memungkinkan Robocopy menyalin hanya delta antara sumber dan 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 antara dua eksekusi Robocopy, file tersebut ditandai 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 kemajuan salinan 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.
/UNILOG:<file name> Menulis status ke file log sebagai Unicode. (Menimpa log yang ada.)
/L Hanya untuk uji coba
File harus terdaftar saja. 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
Menentukan bahwa Robocopy beroperasi dalam "mode ruang bebas rendah." Pengalih ini hanya berguna untuk target dengan penyimpanan bertingkat 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, /B, atau /ZB.
/Z Gunakan dengan hati-hati
Menyalin file dalam mode mulai 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 mulai ulang. Jika akses ditolak, opsi ini menggunakan mode pencadangan. Opsi ini secara signifikan mengurangi performa salinan karena titik pemeriksaan.

Penting

Gunakan Windows Server 2019 dengan minimal pembaruan OS 26 Agustus 2021 KB5005103. Ini berisi perbaikan penting untuk skenario RoboCopy tertentu.

Tip

Lihat bagian Pemecahan masalah jika RoboCopy berdampak pada lingkungan produksi Anda, melaporkan banyak kesalahan, atau tidak berjalan seperti yang diharapkan.

Fase 5: Pemindahan pengguna

Saat Anda menjalankan perintah RoboCopy untuk pertama kalinya, pengguna dan aplikasi Anda masih akan mengakses file pada sumber mirasi dan berpotensi mengubahnya. Tidak menutup kemungkinan bahwa RoboCopy memproses sebuah direktori, berpindah ke direktori berikutnya, lalu pengguna di lokasi sumber menambahkan, mengubah, atau menghapus file yang sekarang tidak akan diproses dalam eksekusi RoboCopy saat ini. Perilaku ini diharapkan.

Run pertama ini tentang memindah sebagian besar data churn ke berbagi file Azure Anda. Salinan pertama dapat membutuhkan waktu agak lama. Lihat Bagian pemecahan masalah untuk informasi lebih banyak tentang apa yang dapat mempengaruhi kecepatan RoboCopy.

Setelah run awal selesai, jalankan lagi perintah itu.

Kedua kali Anda menjalankan RoboCopy untuk berbagi yang sama, ini akan selesai lebih cepat, karena hanya harus memindah perubahan yang terjadi sejak run terakhir. Anda dapat menjalankan pekerjaan berulang untuk berbagi yang sama.

Jika Anda menilai waktu hentinya masih dapat diterima, Anda harus menghapus akses pengguna ke berbagi file sumber. Anda dapat melakukan itu melalui langkah apa pun yang mencegah pengguna mengubah struktur dan konten file dan folder. Misalnya adalah dengan mengarahkan DFS-Namespaces Anda ke lokasi yang tidak ada atau mengubah ACL di setiap berbagi file.

Jalankan babak RoboCopy terakhir. Ini akan menemukan perubahan apa pun, yang mungkin terlewat sebelumnya. Lamanya langkah ini berlangsung akan bergantung pada kecepatan pemindaian RoboCopy. Anda dapat memperkirakan waktu (yang sebanding dengan downtime Anda) dengan mengukur berapa lama run sebelumnya berjalan.

Pada bagian sebelumnya, Anda telah mengonfigurasi pengguna untuk mengakses berbagi file dengan identitas mereka dan seharusnya sudah menetapkan strategi bagi pengguna untuk menggunakan jalur yang sudah dibuat ke berbagi file Azure baru (DFS-N) Anda.

Anda dapat mencoba menjalankan beberapa salinan ini antara berbagi file sumber dan target yang berbeda secara paralel. Saat melakukannya, ingatlah throughput jaringan dan rasio jumlah core to thread Anda agar tidak memberikan beban berlebih pada sistem.

Memecahkan masalah dan melakukan pengoptimalan

Kecepatan dan tingkat keberhasilan menjalankan RoboCopy tertentu akan bergantung pada beberapa faktor:

  • IOPS pada penyimpanan sumber dan target
  • bandwidth jaringan yang tersedia antara sumber dan target
  • kemampuan memproses file dan folder dengan cepat dalam suatu namespace
  • jumlah perubahan antara run RoboCopy

Pertimbangan IOPS dan bandwidth

Dalam kategori ini, Anda perlu mempertimbangkan kemampuan penyimpanan sumber, penyimpanan target, dan jaringan yang menyambungkannya. Throughput maksimum yang mungkin ditentukan oleh yang paling lambat dari ketiga komponen ini. Pastikan infrastruktur jaringan Anda dikonfigurasi untuk mendukung kecepatan transfer optimal ke kemampuan terbaiknya.

Perhatian

Meskipun menyalin secepat mungkin sering kali paling diinginkan, pertimbangkan penggunaan jaringan lokal Anda dan alat NAS untuk tugas lain yang sering kali penting bagi bisnis.

Menyalin secepat mungkin, mungkin tidak diinginkan saat ada risiko bahwa migrasi dapat memonopoli sumber daya yang tersedia.

  • Pertimbangkan kapan waktu terbaik di lingkungan Anda untuk menjalankan migrasi: di siang hari, di luar jam kerja, atau selama akhir pekan.
  • Pertimbangkan juga QoS jaringan pada Windows Server untuk mempercepat kecepatan RoboCopy.
  • Hindari pekerjaan yang tidak perlu untuk alat migrasi.

RobCopy dapat memasukkan penundaan antar-paket dengan menentukan switch /IPG:n di mana n diukur dalam milidetik antara paket RobCopy. Menggunakan switch ini dapat membantu menghindari monopoli sumber daya pada perangkat yang dibatasi IO, dan tautan jaringan yang padat.

/IPG:n tidak dapat digunakan untuk pembatasan jaringan yang tepat ke Mbps tertentu. Gunakan QoS Jaringan Windows Server sebagai gantinya. RoboCopy sepenuhnya bergantung pada protokol SMB untuk semua kebutuhan jaringan. Menggunakan SMB adalah alasan mengapa RoboCopy tidak dapat mempengaruhi throughput jaringan itu sendiri, tetapi dapat memperlambat penggunaannya.

Garis pemikiran serupa berlaku untuk IOPS yang diamati pada NAS. Ukuran kluster pada volume NAS, ukuran paket, dan array faktor lain memengaruhi IOPS yang diamati. Memperkenalkan penundaan antar-paket sering kali merupakan cara termudah untuk mengontrol beban pada NAS. Uji beberapa nilai, misalnya dari sekitar 20 milidetik (n=20) hingga kelipatan angka tersebut. Setelah Anda memperkenalkan penundaan, Anda dapat mengevaluasi apakah aplikasi Anda yang lain sekarang dapat berfungsi seperti yang diharapkan. Strategi pengoptimalan ini akan memungkinkan Anda menemukan kecepatan RoboCopy yang optimal di lingkungan Anda.

Kecepatan pemrosesan

RoboCopy akan melintasi namespace layanan yang ditunjuk dan mengevaluasi setiap file dan folder untuk disalin. Setiap file akan dievaluasi selama salinan awal dan selama salinan menyusul. Misalnya, menjalankan RoboCopy /MIR berulang terhadap sumber dan target lokasi penyimpanan yang sama. Eksekusi berulang ini berguna untuk mengecilkan waktu henti bagi pengguna dan aplikasi, dan untuk meningkatkan tingkat keberhasilan keseluruhan file yang dimigrasikan.

Kami sering default untuk mempertimbangkan bandwidth sebagai faktor yang paling membatasi dalam migrasi - dan itu bisa benar. Namun kemampuan untuk menghitung namespace layanan dapat memengaruhi total waktu untuk menyalin lebih banyak lagi untuk namespace layanan yang lebih besar dengan file yang lebih kecil. Pertimbangkan bahwa menyalin 1 TiB file kecil akan memakan waktu jauh lebih lama daripada menyalin 1 TiB file yang lebih sedikit tetapi lebih besar. Dengan asumsi bahwa semua variabel lainnya tetap sama.

Penyebab perbedaan ini adalah kekuatan pemrosesan yang diperlukan untuk berjalan melalui namespace layanan. RoboCopy mendukung salinan multi-rangkaian melalui parameter /MT:n di mana n adalah jumlah rangkaian yang akan digunakan. Jadi, saat memprovisikan komputer khusus untuk RoboCopy, pertimbangkan jumlah inti prosesor dan hubungannya dengan jumlah utas yang disediakan. Yang paling umum adalah dua utas per core. Jumlah core dan utas komputer adalah titik data penting untuk memutuskan nilai multi-utas /MT:n apa yang harus Anda tentukan. Pertimbangkan juga berapa banyak pekerjaan RoboCopy yang Anda rencanakan untuk dijalankan secara paralel pada komputer tertentu.

Lebih banyak utas akan menyalin contoh file kecil 1-TiB jauh lebih cepat daripada utas yang lebih sedikit. Pada saat yang sama, investasi sumber daya ekstra pada 1 TiB file yang lebih besar mungkin tidak menangguhkan keuntungan proporsional. Jumlah utas yang tinggi akan mencoba menyalin lebih banyak file besar melalui jaringan secara bersamaan. Aktivitas jaringan ekstra ini meningkatkan kemungkinan dibatasi oleh throughput atau IOPS penyimpanan.

Selama RoboCopy pertama menjadi target kosong atau menjalankan diferensial dengan banyak file yang diubah, Anda mungkin dibatasi oleh throughput jaringan Anda. Mulailah dengan jumlah utas tinggi untuk eksekusi awal. Jumlah utas yang tinggi, bahkan di luar utas yang tersedia saat ini di komputer, membantu memenuhi bandwidth jaringan yang tersedia. Eksekusi /MIR berikutnya secara progresif dipengaruhi oleh pemrosesan item. Lebih sedikit perubahan dalam menjalankan diferensial berarti lebih sedikit transportasi data melalui jaringan. Kecepatan Anda sekarang lebih bergantung pada kemampuan Anda untuk memproses item namespace layanan daripada memindahkannya melalui tautan jaringan. Untuk eksekusi selanjutnya, cocokkan nilai jumlah utas Anda dengan jumlah core prosesor dan jumlah utas per core. Pertimbangkan apakah core perlu dicadangkan untuk tugas lain yang mungkin dimiliki server produksi.

Tip

Aturan praktis: Eksekusi pertama RoboCopy, yang akan memindahkan banyak data dari jaringan dengan latensi lebih tinggi, mendapat manfaat dari provisi jumlah rangkaian yang berlebihan (/MT:n). Eksekusi berikutnya akan menyalin lebih sedikit perbedaan dan Anda lebih cenderung beralih dari throughput jaringan terbatas untuk komputasi yang dibatasi. Dalam keadaan ini, seringkali lebih baik untuk mencocokkan jumlah rangkaian robocopy dengan rangkaian yang benar-benar tersedia pada mesin. Provisi berlebihan dalam skenario itu dapat menyebabkan lebih banyak pergeseran konteks di prosesor, yang kemungkinan memperlambat salinan Anda.

Hindari pekerjaan yang tidak perlu

Hindari perubahan skala besar di namespace layanan Anda. Misalnya, memindahkan file antar direktori, mengubah properti dalam skala besar, atau mengubah izin (NTFS ACL). Terutama perubahan ACL dapat berdampak tinggi karena sering kali memiliki efek perubahan berjenjang pada file yang lebih rendah dalam hierarki folder. Konsekuensinya dapat berupa:

  • perpanjangan waktu menjalankan pekerjaan RoboCopy karena setiap file dan folder yang terpengaruh oleh perubahan ACL perlu diperbarui
  • menggunakan kembali data yang dipindahkan sebelumnya mungkin perlu disalin kembali. Misalnya, lebih banyak data perlu disalin saat struktur folder berubah setelah file telah disalin sebelumnya. Pekerjaan RoboCopy tidak dapat "memutar ulang" perubahan namespace layanan. Pekerjaan selanjutnya harus menghapus menyeluruh file yang sebelumnya diangkut ke struktur folder lama dan mengunggah file di struktur folder baru lagi.

Aspek penting lainnya adalah menggunakan alat RoboCopy secara efektif. Dengan skrip RoboCopy yang disarankan, Anda akan membuat dan menyimpan file log untuk kesalahan. Kesalahan penyalinan dapat terjadi - itu normal. Kesalahan ini seringkali membuatnya perlu untuk menjalankan beberapa putaran alat penyalinan seperti RoboCopy. Eksekusi awal, katakanlah dari NAS ke DataBox atau server ke berbagi file Azure. Dan satu atau lebih ekstra ekseskusi dengan switch /MIR untuk menangkap dan mencoba kembali file yang tidak disalin.

Anda harus siap untuk menjalankan beberapa putaran RoboCopy terhadap cakupan namespace layanan tertentu. Eksekusi yang berurutan akan selesai lebih cepat karena eksekusi memiliki lebih sedikit untuk disalin tetapi semakin dibatasi oleh kecepatan pemrosesan namespace layanan. Saat Anda menjalankan beberapa putaran, Anda dapat mempercepat setiap putaran dengan tidak meminta RoboCopy berusaha terlalu keras untuk menyalin semuanya dalam eksekusi tertentu. Switch RoboCopy ini dapat membuat perbedaan yang signifikan:

  • /R:n n = seberapa sering Anda mencoba menyalin file yang gagal dan
  • /W:n n = berapa detik untuk menunggu di antara percobaan ulang

/R:5 /W:5 adalah pengaturan yang masuk akal yang dapat Anda sesuaikan dengan keinginan Anda. Dalam contoh ini, file yang gagal akan dicoba ulang lima kali, dengan waktu tunggu lima detik antar percobaan ulang. Jika file masih gagal disalin, pekerjaan RoboCopy berikutnya akan mencoba lagi. Sering kali file yang gagal karena sedang digunakan atau karena masalah waktu habis mungkin akhirnya berhasil disalin dengan cara ini.

Langkah berikutnya

Ada lebih banyak yang dapat ditemukan tentang berbagi file Azure. Artikel berikut membantu memahami opsi tingkat lanjut, praktik terbaik, dan juga memuat bantuan pemecahan masalah. Aritkel ini bertautan ke dokumentasi berbagi file Azure yang sesuai.