Menggunakan RoboCopy untuk melakukan migrasi ke berbagi file Azure

Artikel
10/23/2023

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

Sumber data: Sumber apa pun yang mendukung protokol SMB, seperti Network Attached Storage (NAS), server Windows atau Linux, berbagi file Azure lainnya, dan banyak lagi
Rute migrasi: Dari penyimpanan sumber ⇒ komputer Windows dengan RoboCopy ⇒ berbagi file Azure
Tidak ada file penembolokan lokal: Karena tujuan akhir adalah menggunakan berbagi file Azure langsung di cloud, tidak ada rencana untuk menggunakan Azure File Sync.

Ada banyak rute migrasi yang berbeda untuk kombinasi sumber dan penyebaran yang berbeda. Lihat 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
Berbagi file standar (GPv2), GRS/GZRS
Berbagi file premium (FileStorage), LRS/ZRS

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 celah, dan mungkin ada kesalahpahaman fungsionalitas dengan mudah saat 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 dalam menggunakan AzCopy -sync adalah bahwa file yang dihapus pada sumber tidak dihapus pada target. Hal itu akan menghasilkan set fitur salinan diferensial yang tidak sempurna. AzCopy akan terus berkembang. Saat ini, kami tidak merekomendasikan penggunaan AzCopy 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 Anda di 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. Pertama, Anda harus menyebarkan akun penyimpanan Azure dan berbagi file. Selanjutnya, Anda akan mengonfigurasi jaringan, mempertimbangkan penyebaran DFS Namespace (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.

Fase 1: Menyebarkan sumber daya penyimpanan Azure

Dalam fase ini, Anda akan memprovisikan akun penyimpanan Azure dan berbagi file Azure SMB di dalamnya.

Ingatlah bahwa berbagi file Azure disebarkan di cloud di akun penyimpanan Azure. Untuk berbagi file standar, pengaturan tersebut menjadikan akun penyimpanan sebagai target skala untuk nomor performa seperti IOPS dan throughput. Jika Anda menempatkan beberapa berbagi file dalam satu akun penyimpanan, Anda membuat kumpulan IOPS dan throughput bersama untuk berbagi ini.

Sebagai aturan umum, Anda dapat mengumpulkan beberapa berbagi file Azure ke akun penyimpanan yang sama jika Anda memiliki berbagi arsip atau Anda mengharapkan aktivitas sehari-hari rendah di dalamnya. Namun, jika Anda memiliki berbagi yang sangat aktif (berbagi yang digunakan oleh banyak pengguna dan/atau aplikasi), Anda harus menyebarkan akun penyimpanan dengan masing-masing satu berbagi file. Batasan ini tidak berlaku untuk akun penyimpanan FileStorage (premium), di mana performa secara eksplisit disediakan dan dijamin untuk setiap berbagi.

Catatan

Ada batas 250 akun penyimpanan per langganan per wilayah Azure. Dengan penambahan kuota, Anda dapat membuat hingga 500 akun penyimpanan per wilayah. Untuk informasi selengkapnya, lihat Meningkatkan kuota akun Azure Storage.

Pertimbangan lain saat Anda menyebarkan akun penyimpanan adalah redundansi. Lihat Redundansi Azure Files.

Berbagi file Azure standar dibuat dengan batas 5 TiB secara default. Jika Anda membutuhkan lebih banyak kapasitas, Anda dapat membuat berbagi file besar (hingga 100 TiB). Namun, berbagi tersebut hanya dapat menggunakan penyimpanan redundan lokal atau opsi redundansi penyimpanan zona-redundan. Pertimbangkan kebutuhan redundansi penyimpanan Anda sebelum menggunakan berbagi file 100 TiB.

Jika Anda telah membuat daftar berbagi, Anda harus memetakan setiap berbagi ke akun penyimpanan tempat berbagi tersebut akan dibuat.

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.

Sekarang sebarkan jumlah akun penyimpanan Azure yang sesuai dengan jumlah berbagi file Azure yang sesuai di dalamnya, mengikuti instruksi di Membuat berbagi file SMB. Dalam kebanyakan kasus, Anda harus memastikan wilayah setiap akun penyimpanan Anda sama.

Fase 2: Bersiap menggunakan berbagi file Azure

Dengan informasi dalam fase ini, Anda akan dapat memutuskan bagaimana server dan pengguna Anda di Azure dan di luar Azure akan diaktifkan untuk 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. Menggunakan autentikasi berbasis identitas dan domain yang bergabung dengan akun penyimpanan Anda akan memungkinkan aplikasi dan pengguna Anda menggunakan identitas AD mereka 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.
Kelangsungan bisnis: Mengintegrasikan berbagi file Azure ke lingkungan yang ada sering kali memerlukan pelestarian alamat berbagi yang ada. Jika Anda belum menggunakan DFS-Namespaces, pertimbangkan untuk menetapkannya di lingkungan Anda. Anda akan dapat menyimpan alamat berbagi yang digunakan pengguna dan skrip Anda, tidak berubah. 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 mereferensikan dokumentasi khusus untuk topik berikut. Perhatikan bahwa Azure Active Directory sekarang menjadi ID Microsoft Entra. Untuk informasi selengkapnya, lihat Nama baru untuk Azure ACTIVE Directory.

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

Penting

Pastikan Anda memasang berbagi file Azure menggunakan kunci akses akun penyimpanan. Jangan gunakan identitas domain. Sebelum berhasil memasang berbagi file Azure ke Windows Server lokal, Anda harus menyelesaikan Fase 2: Bersiap untuk menggunakan berbagi file Azure.

Setelah Anda siap, tinjau Menggunakan berbagi file Azure dengan Windows. Kemudian, pasangkan berbagi file Azure yang untuknya Anda ingin menggunakan RoboCopy.

Fase 3: RoboCopy

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

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 Information`folder 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 uji coba File yang akan dicantumkan 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.
`/Z`	Gunakan dengan hati-hati Menyalin file 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.

Tip

Lihat bagian Pemecahan Masalah jika RoboCopy memengaruhi lingkungan produksi Anda, melaporkan banyak kesalahan, atau tidak berkembang secepat yang diharapkan.

Fase 4: Cut-over pengguna

Saat Anda menjalankan perintah RoboCopy untuk pertama kalinya, pengguna dan aplikasi Anda masih mengakses file pada sumber migrasi Anda dan berpotensi mengubahnya. Ada kemungkinan bahwa RoboCopy telah memproses direktori, melanjutkan ke direktori berikutnya, dan kemudian 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 kalinya Anda menjalankan RoboCopy untuk berbagi yang sama, itu akan selesai lebih cepat, karena hanya perlu mengangkut perubahan yang terjadi sejak eksekusi terakhir. Anda dapat menjalankan pekerjaan berulang untuk berbagi yang sama.

Setelah mempertimbangkan jumlah waktu henti yang dapat diterima, maka Anda perlu menghapus akses pengguna ke berbagi sumber Anda. 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 mengambil perubahan apa pun yang mungkin terlewatkan. Berapa lama langkah terakhir ini tergantung pada kecepatan pemindaian RoboCopy. Anda dapat memperkirakan waktu (yang sebanding dengan downtime Anda) dengan mengukur berapa lama run sebelumnya berjalan.

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

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
ukuran dan jumlah file yang perlu Anda salin

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 merupakan hal yang paling diinginkan, pertimbangkan penggunaan jaringan lokal Anda dan alat NAS untuk tugas lainnya, yang sering kali merupakan tugas bisnis penting.

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 menyisipkan 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 akurat hingga 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 semua variabel lain tetap sama. Oleh karena itu, Anda mungkin mengalami transfer lambat jika Anda memigrasikan sejumlah besar file kecil. Ini adalah perilaku yang diprediksi.

Penyebab perbedaan ini adalah kekuatan pemrosesan yang diperlukan untuk berjalan melalui namespace layanan. RoboCopy mendukung salinan multi-rangkaian melalui parameter /MT:n di manan 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 1 TiB file kecil kami jauh lebih cepat dari lebih sedikit utas. 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 berikutnya, 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 RoboCopy pertama (yang akan memindahkan banyak data jaringan latensi yang lebih tinggi) mendapat manfaat dari provisi jumlah utas yang berlebihan (/MT:n). Eksekusi berikutnya akan menyalin lebih sedikit perbedaan, dan Anda lebih mungkin beralih dari throughput jaringan yang dibatasi ke komputasi yang dibatasi. Dalam keadaan ini, seringkali lebih baik untuk mencocokkan jumlah utas RoboCopy dengan utas yang benar-benar tersedia pada komputer. 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 Anda, seperti memindahkan file antar direktori, mengubah properti dalam skala besar, atau mengubah izin direktori dan tingkat file (ACL NTFS). 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 salin dapat terjadi - itu normal. Kesalahan ini sering kali membuatnya perlu menjalankan beberapa putaran alat salin seperti RoboCopy: Eksekusi awal, katakanlah dari NAS ke DataBox atau server ke berbagi file Azure, dan satu atau beberapa eksekusi tambahan dengan /MIR sakelar 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.

Memperkirakan biaya transaksi penyimpanan

Saat Anda memulai migrasi ke Azure Files, RoboCopy menyalin file dan folder Anda ke Azure. Bergantung pada model penagihan Anda untuk Azure Files, biaya transaksi mungkin berlaku. Lihat Memahami penagihan.

Jika Anda menggunakan model penagihan bayar sesuai penggunaan untuk berbagi file Azure standar, mungkin sulit untuk memperkirakan jumlah transaksi yang akan dihasilkan migrasi Anda.

Tidak dimungkinkan untuk memperkirakan jumlah transaksi berdasarkan kapasitas penyimpanan sumber yang digunakan. Jumlah transaksi diskalakan dengan jumlah item namespace (file dan folder) dan propertinya yang dimigrasikan, bukan ukurannya. Misalnya, lebih banyak transaksi diperlukan untuk memigrasikan 1 GiB file kecil daripada 1 GiB file yang lebih besar.
Untuk meminimalkan waktu henti, Anda mungkin perlu menjalankan operasi penyalinan beberapa kali dari sumber ke target. Semua item sumber dan target diproses selama setiap operasi salin, meskipun eksekusi berikutnya selesai lebih cepat. Setelah operasi awal, hanya perbedaan yang diperkenalkan antara eksekusi salinan yang diangkut melalui jaringan. Penting untuk dipahami bahwa meskipun lebih sedikit data yang diangkut, jumlah transaksi yang diperlukan mungkin tetap sama.
Menyalin file yang sama dua kali mungkin tidak menghasilkan jumlah transaksi yang sama. Memproses item yang dimigrasikan dalam eksekusi salinan sebelumnya dapat mengakibatkan hanya beberapa transaksi baca. Sebaliknya, perubahan pada metadata atau konten antara eksekusi salinan mungkin memerlukan jumlah transaksi yang lebih besar untuk memperbarui target. Setiap file di namespace Anda mungkin memiliki persyaratan unik, menghasilkan jumlah transaksi yang berbeda.

Disarankan untuk menjalankan beberapa pengujian awal pada data Anda sendiri untuk lebih memahami berapa banyak transaksi yang terjadi. Ini akan memberi Anda gambaran yang lebih baik tentang jumlah total transaksi yang mungkin dihasilkan migrasi file.

Langkah berikutnya

Artikel berikut akan membantu Anda memahami opsi tingkat lanjut dan praktik terbaik.