Gunakan DataBox untuk bermigrasi dari Network Attached Storage (NAS) ke berbagi file Azure

Artikel
11/21/2023

Artikel migrasi ini adalah salah satu dari beberapa upaya melibatkan NAS kata kunci dan Azure DataBox. Periksa apakah artikel ini berlaku untuk skenario Anda:

Sumber data: Network Attached Storage (NAS)
Rute migrasi: NAS ⇒ DataBox ⇒ 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.

Jika skenario Anda berbeda, bacalah tabel panduan migrasi dengan saksama.

Artikel ini memandu Anda dari ujung ke ujung melewati perencanaan, penyebaran, dan konfigurasi jaringan yang dibutuhkan untuk bermigrasi dari appliance NAS Anda ke berbagi file Azure yang fungsional. Panduan ini menggunakan Azure DataBox untuk transportasi data dala jumlah besar (transpor data offline).

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 memindahkan berbagi file yang Anda miliki di appliance NAS ke Azure dan membuatnya menjadi berbagi file Azure asli. Anda dapat menggunakan berbagi file Azure asli 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 dan mengonfigurasi jaringan. Kemudian, Anda akan memigrasikan file menggunakan Azure DataBox dan untuk mengetahui perubahan, Anda dapat menggunakan RoboCopy. Terakhir, Anda akan memindahkan pengguna dan aplikasi 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 yang Anda tinggalkan.

Fase 1: Mengidentifikasi berapa banyak berbagi file Azure yang dibutuhkan

Dalam langkah ini, Anda akan menentukan berapa banyak berbagi file Azure yang Anda butuhkan. Anda mungkin memiliki lebih banyak folder pada volume yang saat ini Anda bagikan secara lokal sebagai berbagi SMB kepada pengguna dan aplikasi Anda. Bergantung pada jumlah berbagi file yang ingin Anda migrasikan ke cloud, Anda dapat memilih untuk menggunakan pemetaan 1:1 atau pengelompokan berbagi.

Menggunakan pemetaan 1:1

Jika Anda memiliki jumlah berbagi yang cukup kecil, kami sarankan pemetaan 1:1. Cara termudah untuk menggambarkan skenario ini adalah membayangkan pembagian lokal yang memetakan 1:1 ke berbagi file Azure.

Jika Anda memiliki sejumlah besar berbagi file, pertimbangkan untuk 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. Dengan begitu, hanya satu berbagi file Azure di cloud yang diperlukan untuk grup berbagi lokal ini.

Fase 2: Sebar sumber daya penyimpanan Azure

Dalam fase ini, Anda akan menyediakan akun penyimpanan Azure dan berbagi file 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 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 3: Tentukan berapa banyak appliance Azure DataBox yang dibutuhkan

Hanya mulai langkah ini saat Anda telah menyelesaikan fase sebelumnya. Sumber daya penyimpanan Azure Anda (akun penyimpanan dan berbagi file) harus dibuat saat ini. Selama pemesanan DataBox Anda, Anda harus menetapkan ke dalam akun penyimpanan tempat DataBox memindah data.

Dalam fase ini, Anda harus memetakan hasil dari rencana migrasi dari fase sebelumnya ke batasan dari opsi DataBox yang tersedia. Pertimbangan ini akan membantu Anda membuat rencana untuk opsi DataBox mana yang harus dipilih dan berapa banyak yang dibutuhkan untuk memindah berbagai NAS Anda ke berbagi file Azure.

Untuk menentukan berapa banyak peranti dari jenis yang dibutuhkan, pertimbangkan batasan penting ini:

Azure DataBox apa pun dapat memindah data hingga ke 10 akun penyimpanan.
Setiap opsi DataBox memiliki kapasitasnya sendiri yang dapat digunakan. Lihat Opsi DataBox.

Baca rencana migrasi Anda untuk jumlah akun penyimpanan yang Anda butuhkan untuk dibuat dan bagikan di masing-masingnya. 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. Anda bisa memiliki dua peranti DataBox memindah file ke akun penyimpanan yang sama, tetapi jangan pecah konten dari satu berbagi file tunggal ke 2 DataBox.

Opsi DataBox

Untuk migrasi standar, satu atau beberapa kombinasi dari dua opsi DataBox ini harus dipilih:

DataBox Ini adalah opsi paling umum. Appliance DataBox yang diperkuat, yang bekerja mirip seperti NAS, akan dikirim kepada Anda. Kapasitas yang dapat digunakan adalah 80 TiB. Untuk informasi selengkapnya, buka Dokumentasi DataBox.
DataBox Heavy Opsi ini menampilkan appliance DataBox yang diperkuat yang dapat bergerak, dengan fungsi mirip NAS, dengan kapasitas 1 PiB. Kapasitas yang dapat digunakan berkurang sekitar 20%, dikarenakan enkripsi dan sistem file. Untuk informasi selengkapnya, buka Dokumentasi DataBox Heavy.

Peringatan

Disk Data Box tidak disarankan untuk migrasi ke berbagi file Azure. Disk Data Box tidak mempertahankan metadata file, seperti izin akses (ACL) dan atribut lainnya.

Fase 4: Penyediaan Windows Server sementara

Sembari menunggu Azure DataBox tiba, Anda dapat menyebar satu Windows Server atau lebih yang dibutuhkan untuk menjalankan pekerjaan RoboCopy.

Penggunaan pertama dari server ini adalah menyalin file ke DataBox.
Penggunaan kedua dari server ini adalah mengejar perubahan yang telah terjadi pada appliance NAS saat DataBox dalam perjalanan. Pendekatan ini mengurangi downtime pada sisi sumber hingga level minimum.

Kecepatan kerja RoboCopy Anda bergantung terutama pada faktor-faktor ini:

IOPS pada penyimpanan sumber dan target
bandwidth jaringan yang tersedia antara semuanya
Temukan detail selengkapnya di bagian Pemecahan Masalah: Pertimbangan IOPS dan Bandwidth
kemampuan untuk memproses file dan folder dengan cepat di namespace layanan
Temukan detail selengkapnya di bagian Pemecahan Masalah: Kecepatan pemrosesan
jumlah perubahan di antara eksekusi RoboCopy:
Temukan lebih banyak detail pada bagian Pemecahan Masalah: Hindari pekerjaan yang tidak perlu

Penting untuk menyimpan detail yang direferensikan saat memutuskan jumlah RAM dan utas yang Anda sediakan ke Windows Server sementara.

Fase 5: Bersiap menggunakan berbagi file Azure

Untuk menghemat waktu, Anda harus melanjutkan dengan fase ini sembari menunggu DataBox Anda tiba. 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. Anda akan menggunakan DFS-N sebagai layanan perutean namespace untuk SMB, dengan mengarahkan ulang target DFS-Namespace ke berbagi file Azure setelah migrasinya.

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.

Fase 6: Salin file ke DataBox Anda

Saat DataBox tiba, Anda perlu menyiapkan DataBox dengan konektivitas jaringan yang tidak di-unimped ke appliance NAS Anda. Ikuti dokumentasi penyiapan untuk jenis DataBox yang Anda pesan.

Bergantung pada jenis DataBox, mungkin ada alat salin DataBox yang tersedia untuk Anda. Pada titik ini, alat itu tidak disarankan untuk migrasi ke berbagi file Azure karena tidak menyalin file Anda dengan lengkap ke DataBox. Alih-alih, gunakan RoboCopy.

Saat DataBox tiba, itu akan memiliki prapenyiapan berbagai SMB yang tersedia untuk setiap akun penyimpanan yang Anda tentukan pada saat 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 relevan untuk migrasi Anda. Abaikan segala berbagi blok dan blob halaman.

Ikuti langkah-langkah dalam dokumentasi Azure DataBox:

Hubungkan ke Data Box
Menyalin data ke Data Box
Siapkan DataBox Anda untuk perpindahan ke Azure

Dokumentasi DataBox yang terkait menetapkan perintah RoboCopy. Namunm perintah itu tidak cocok untuk mempertahankan keutuhan file dan folder lengkap. Alih-alih, gunakan perintah ini:

Robocopy /MT:32 /NP /NFL /NDL /B /MIR /IT /COPY:DATSO /DCOPY:DAT /UNILOG:<FilePathAndName> <SourcePath> <Dest.Path>

Untuk mempelajari lebih lanjut tentang detail dari setiap bendera RoboCopy, liat tabel pada bagian RoboCopy mendatang.
Untuk mempelajari lebih lanjut tentang cara menghitung ukuran utas dengan tepat /MT:n, mengoptimalkan kecepatan RoboCopy, dan menjadikan RoboCopy tetangga yang baik di pusat data Anda, perhatikan bagian pemecahan masalah RoboCopy.

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.

Fase 7: Tangani RoboCopy dari NAS Anda

Setelah DataBox Anda melaporkan bahwa semua file dan folder telah ditaruh di berbagi file Azure yang direncanakan, Anda dapat melanjutkan dengan fase ini. Penanganan RoboCopy hanya dibutuhkan jika data di NAS mungkin sudah berubah sejak salinan DataBox dimulai. Dalam skenario tertentu tempat Anda menggunakan berbagi untuk mencapai tujuan, Anda mungkin dapat menghentikan perubahan pada berbagi di NAS Anda hingga migrasi selesai. Anda mungkin juga memiliki kemampuan untuk melayani persyaratan bisnis Anda dengan mengatur berbagi NAS ke baca-saja selama migrasi.

Dalam kasus saat Anda membutuhkan suatu berbagi dalam status baca-saja selama migrasi dan hanya dapat menyerap jendela downtime yang singkat, langkah penanganan RoboCopy ini akan menjadi penting untuk diselesaikan sebelum fail-over akses pengguna langsung ke berbagi file Azure.

Dalam langkah ini, Anda akan menjalankan pekerjaan RoboCopy untuk menangani berbagai cloud dengan perubahan terakhir pada NAS Anda sejak saat Anda mencabangkan berbagi Anda ke DataBox. Penanganan RoboCopy ini dapat selesai dengan cepat atau membutuhkan waktu, bergantung pada jumlah churn yang terjadi pada berbagai NAS Anda.

Jalankan salinan lokal pertama ke folder target di Windows Server Anda:

Identifikasi lokasi pertama di appliance NAS Anda.
Identifikasi berbagi file Azure yang sesuai.
Pasang berbagi file Azure sebagai drive jaringan lokal di Windows Server sementara Anda
Mulai penyalinan menggunakan RoboCopy seperti dijelaskan

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 memasang berbagi file Azure ke Windows Server lokal, Anda harus menyelesaikan Fase: Bersiap menggunakan berbagi file Azure!

Setelah siap, baca Artikel cara menggunakan berbagi file Azure dengan Windows dan pasang berbagi file Azure yang Anda inginkan untuk memulai RoboCopy penanganan NAS.

RoboCopy

Perintah RoboCopy berikut hanya akan menyalin perbedaan (file dan folder yang diperbarui) dari penyimpanan NAS 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 berdampak pada lingkungan produksi Anda, melaporkan banyak kesalahan, atau tidak berjalan seperti yang diharapkan.

Cut-ver pengguna

Saat Anda menjalankan perintah RoboCopy untuk pertama kalinya, pengguna dan aplikasi Anda masih mengakses file pada NAS dan berpotensi mengubahnya. Memungkinkan bahwa RoboCopy memproses direktori, berpindah ke yang berikutnya, lalu pengguna on-premises sumber (NAS) menambah, mengubah, atau menghapus file yang sekarang tidak diproses dalam run 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.

Saat Anda mempertimbangkan downtime yang dapat diterima, Anda harus menghapus akses pengguna ke berbagi berbasis NAS Anda. Anda dapat melakukan itu melalui langkah apa pun yang mencegah pengguna mengubah struktur dan konten file dan folder. Contohnya adalah mengarahkan DFS-Namespace Anda ke lokasi yang tidak ada atau mengubah ACL akar pada berbagi.

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

Buat berbagi di folder Windows Server dan kemungkinan sesuaikan penyebaran DFS-N Anda untuk mengarahkannya ke sana. Pastikan untuk mengatur izin level berbagi yang sama seperti di berbagi NAS SMB Anda. Jika Anda memiliki NAS kelas enterprise yang digabungkan dengan domain, SID pengguna akan secara otomatis dicocokkan dengan pengguna yang ada di Active Directory dan RoboCopy menyalin file dan metadata dengan kejelasan penuh. Jika Anda sudah menggunakan pengguna lokal di NAS Anda, Anda harus membuat ulang pengguna ini sebagai pengguna lokal Windows Server dan memetakan SID yang ada yang dipindah RoboCopy ke Windows Server Anda ke SID pengguna lokal Windows Server Anda yang baru.

Anda telah selesai memigrasikan berbagi/grup berbagi ke akar atau volume umum.

Anda dapat mencoba menjalankan beberapa salinan ini secara paralel. Kami menyarankan pemroses cakupan satu berbagi file Azure pada satu waktu.

Pecahkan masalah

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 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 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 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, sering kali lebih baik untuk mencocokkan jumlah rangkaian RoboCopy dengan rangkaian 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 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.