Migrasi StorSimple 8100 dan 8600 ke Azure File Sync

Artikel
03/21/2023

Seri StorSimple 8000 mencakup appliance fisik 8100 atau 8600 lokal dan komponen layanan cloud mereka. Appliance virtual StorSimple 8010 dan 8020 juga tercakup dalam panduan migrasi ini. Dimungkinkan untuk memigrasikan data dari salah satu appliance ini ke berbagi file Azure dengan Azure File Sync opsional. Azure File Sync adalah layanan Azure jangka panjang default dan strategis yang menggantikan fungsi StorSimple lokal. Artikel ini menyediakan pengetahuan latar belakang dan langkah-langkah migrasi yang diperlukan untuk keberhasilan migrasi ke Azure File Sync.

Catatan

Layanan StorSimple (termasuk StorSimple Device Manager untuk seri 8000 dan 1200 dan StorSimple Data Manager) telah mencapai akhir dukungan. Akhir dukungan untuk StorSimple diterbitkan pada tahun 2019 di halaman Kebijakan Siklus Hidup Microsoft dan Azure Communications . Pemberitahuan tambahan dikirim melalui email dan diposting di portal Azure dan di gambaran umum StorSimple. Hubungi Dukungan Microsoft untuk detail tambahan.

Video ini memberikan gambaran umum tentang:

Azure Files
Azure File Sync
Perbandingan StorSimple & Azure Files
Alat migrasi dan gambaran umum proses StorSimple Data Manager

Fase 1: Persiapan migrasi

Bagian ini berisi langkah-langkah yang harus Anda ambil di awal tahap migrasi Anda dari volume StorSimple ke berbagi file Azure.

Video ini mencakup:

Memilih tingkat penyimpanan
Memilih opsi redundansi penyimpanan
Memilih akses berbagi langsung vs. Azure File Sync
Kunci Dan Nomor Seri Enkripsi Data Layanan StorSimple
Migrasi Cadangan Volume StorSimple
Memetakan volume dan berbagi StorSimple ke berbagi file Azure
Mengelompokkan berbagi di dalam berbagi file Azure
Pertimbangan pemetaan
Lembar kerja perencanaan migrasi
Lembar bentang pemetaan namespace

Inventaris

Ketika Anda mulai merencanakan migrasi, pertama-tama identifikasi semua appliance dan volume StorSimple yang perlu Anda migrasikan. Setelah itu, Anda dapat memutuskan jalur migrasi terbaik.

Appliance fisik StorSimple (seri 8000) menggunakan panduan migrasi ini.
Appliance virtual StorSimple (seri 1200) menggunakan panduan migrasi yang berbeda.

Ringkasan biaya migrasi

Migrasi ke berbagi file Azure dari volume StorSimple melalui pekerjaan migrasi di sumber daya Manajer Data StorSimple tidak dikenakan biaya. Biaya lain mungkin muncul selama dan setelah migrasi:

Jalan keluar jaringan: File StorSimple Anda berada pada akun penyimpanan dalam wilayah Azure tertentu. Jika Anda menyediakan berbagi file Azure yang Anda migrasikan ke akun penyimpanan di wilayah Azure yang sama, tidak ada biaya keluar yang terjadi. Namun, jika Anda memindahkan file ke akun penyimpanan di wilayah lain sebagai bagian dari migrasi ini, biaya keluar akan berlaku.
Transaksi berbagi file Azure: Ketika file disalin ke dalam berbagi file Azure (sebagai bagian dari migrasi maupun bukan), biaya transaksi akan berlaku saat file dan metadata sedang ditulis. Sebagai praktik terbaik, mulai berbagi file Azure Anda pada tingkat transaksi yang dioptimalkan selama migrasi. Silakan alihkan ke tingkat yang Anda inginkan setelah migrasi selesai. Fase yang dijelaskan dalam artikel ini memanggil ini pada titik yang sesuai.
Mengubah tingkat berbagi file Azure: Mengubah tingkat transaksi biaya berbagi file Azure. Dalam kebanyakan kasus, lebih hemat biaya untuk mengikuti saran dari titik sebelumnya.
Biaya penyimpanan: Saat migrasi ini mulai menyalin file ke dalam berbagi file Azure, penyimpanan akan digunakan dan ditagih. Pencadangan yang dimigrasikan menjadi rekam jepret berbagi file Azure. Rekam jepret berbagi file hanya mengonsumsi kapasitas penyimpanan untuk perbedaan yang dimilikinya.
StorSimple: Hingga Anda mendeprovisi perangkat dan akun penyimpanan StorSimple, biaya StorSimple untuk penyimpanan, cadangan, dan appliance akan terus terjadi.

Berbagi file Azure membuka dunia peluang baru untuk menyusun penyebaran layanan file Anda. Berbagi file Azure adalah berbagi SMB di cloud yang dapat Anda siapkan agar pengguna mengakses langsung melalui protokol SMB dengan autentikasi Kerberos yang sudah dikenal dan izin NTFS yang ada (ACL file dan folder) yang berfungsi secara asli. Pelajari selengkapnya tentang akses berbasis identitas ke berbagi file Azure.

Alternatif dari akses langsung adalah Azure File Sync. Azure File Sync serupa dengan kemampuan StorSimple untuk menyimpan file yang sering digunakan secara lokal di tembolok.

Azure File Sync adalah layanan cloud Microsoft, yang didasarkan pada dua komponen utama:

Sinkronisasi file dan penyusunan tingkat cloud untuk membuat tembolok akses kinerja di Windows Server apa pun.
Berbagi file sebagai penyimpanan asli di Azure yang dapat diakses melalui berbagai protokol seperti SMB dan file REST.

Berbagi file Azure mempertahankan aspek keakuratan file penting seperti atribut, izin, dan tanda waktu. Dengan berbagi file Azure, aplikasi atau layanan untuk menginterpretasikan file dan folder yang disimpan di cloud tidak lagi diperlukan. Anda dapat mengaksesnya secara asli melalui protokol dan klien yang familier. Berbagi file Azure memungkinkan Anda menyimpan data server file serbaguna dan data aplikasi di cloud.

Artikel ini berfokus pada langkah-langkah migrasi. Jika Anda ingin mempelajari selengkapnya tentang Azure File Sync sebelum melakukan migrasi, lihat artikel berikut ini:

Kunci enkripsi data layanan StorSimple

Saat pertama kali menyiapkan appliance StorSimple, alat ini menghasilkan kunci enkripsi data layanan dan menginstruksikan Anda untuk menyimpan kunci dengan aman. Kunci ini digunakan untuk mengenkripsi semua data di akun penyimpanan Azure terkait tempat appliance StorSimple akan menyimpan file Anda.

Kunci enkripsi data layanan diperlukan untuk keberhasilan migrasi. Ambil kunci ini dari catatan Anda, satu untuk setiap appliance di inventaris Anda.

Jika Anda tidak dapat menemukan kunci dalam catatan, Anda dapat membuat kunci baru dari appliance yang ada. Setiap appliance memiliki kunci enkripsi yang unik.

Mengubah kunci enkripsi data layanan

Kunci enkripsi data layanan digunakan untuk mengenkripsi data rahasia pelanggan, seperti kredensial akun penyimpanan, yang dikirim dari layanan StorSimple Manager Anda ke perangkat StorSimple. Anda perlu mengubah kunci ini secara berkala jika organisasi TI Anda memiliki kebijakan rotasi kunci pada perangkat penyimpanan. Proses perubahan kunci dapat sedikit berbeda tergantung apakah ada satu perangkat atau beberapa perangkat yang dikelola oleh layanan StorSimple Manager. Untuk informasi selengkapnya, buka keamanan dan perlindungan data StorSimple.

Mengubah kunci enkripsi data layanan adalah proses 3 langkah:

Menggunakan skrip Windows PowerShell untuk Azure Resource Manager, lakukan otorisasi perangkat untuk mengubah kunci enkripsi data layanan.
Menggunakan Windows PowerShell untuk StorSimple, mulai perubahan kunci enkripsi data layanan.
Jika Anda memiliki lebih dari satu perangkat StorSimple, perbarui kunci enkripsi data layanan di perangkat lain.

Langkah 1: Gunakan skrip Windows PowerShell untuk Mengotorisasi perangkat untuk mengubah kunci enkripsi data layanan

Biasanya, administrator perangkat akan meminta agar administrator layanan mengotorisasi perangkat untuk mengubah kunci enkripsi data layanan. Administrator layanan kemudian akan mengotorisasi perangkat untuk mengubah kunci.

Langkah ini dilakukan menggunakan skrip berbasis Azure Resource Manager. Administrator layanan dapat memilih perangkat yang memenuhi syarat untuk diotorisasi. Perangkat kemudian diotorisasi untuk memulai proses perubahan kunci enkripsi data layanan.

Untuk informasi selengkapnya tentang cara menggunakan skrip, buka Authorize-ServiceEncryptionRollover.ps1

Perangkat mana yang dapat diotorisasi untuk mengubah kunci enkripsi data layanan?

Perangkat harus memenuhi kriteria berikut sebelum dapat diotorisasi untuk memulai perubahan kunci enkripsi data layanan:

Perangkat harus online agar memenuhi syarat untuk otorisasi perubahan kunci enkripsi data layanan.
Anda dapat mengotorisasi perangkat yang sama lagi setelah 30 menit jika perubahan kunci belum dimulai.
Anda dapat mengotorisasi perangkat yang berbeda, asalkan perubahan kunci belum dimulai oleh perangkat yang diotorisasi sebelumnya. Setelah perangkat baru diberi otorisasi, perangkat lama tidak dapat menginisiasi perubahan.
Anda tidak dapat mengotorisasi perangkat selama rollover kunci enkripsi data layanan sedang berlangsung.
Anda dapat mengotorisasi perangkat ketika beberapa perangkat yang terdaftar dengan layanan telah menyelesaikan rollover enkripsi sementara yang lain belum.

Langkah 2: Menggunakan Windows PowerShell untuk StorSimple guna menginisiasi perubahan kunci enkripsi data layanan

Langkah ini dilakukan di antarmuka Windows PowerShell untuk StorSimple pada perangkat StorSimple yang diberi otorisasi.

Catatan

Tidak ada operasi yang dapat dilakukan di portal Azure pada layanan StorSimple Manager hingga rollover kunci selesai.

Jika Anda menggunakan konsol serial perangkat untuk tersambung ke antarmuka Windows PowerShell, lakukan langkah-langkah berikut.

Untuk menginisiasi perubahan kunci enkripsi data layanan

Pilih opsi 1 untuk masuk dengan akses penuh.
Pada command prompt, ketik:

Invoke-HcsmServiceDataEncryptionKeyChange
Setelah cmdlet berhasil diselesaikan, Anda akan mendapatkan kunci enkripsi data layanan baru. Salin dan simpan kunci ini untuk digunakan di langkah 3 dalam proses ini. Kunci ini akan digunakan untuk memperbarui semua perangkat terdaftar yang tersisa dengan layanan StorSimple Manager.

Catatan

Proses ini harus diinisiasi dalam empat jam setelah mengotorisasi perangkat StorSimple.

Kunci baru ini kemudian dikirimkan ke layanan agar diteruskan ke semua perangkat yang terdaftar dengan layanan. Pemberitahuan akan muncul setelahnya pada dasbor layanan. Layanan akan menonaktifkan semua operasi pada perangkat terdaftar, dan administrator perangkat perlu memperbarui kunci enkripsi data layanan pada perangkat lain. Namun, I/O (host yang mengirim data ke cloud) tidak akan terganggu.

Jika telah memiliki satu perangkat yang terdaftar ke layanan Anda, maka proses rollover kini telah selesai dan Anda dapat melewati langkah berikutnya. Jika memiliki beberapa perangkat yang terdaftar ke layanan Anda, lanjutkan ke langkah 3.

Langkah 3: Memperbarui kunci enkripsi data layanan pada perangkat StorSimple lain

Langkah ini harus dilakukan di antarmuka Windows PowerShell pada perangkat StorSimple jika memiliki beberapa perangkat yang terdaftar ke layanan StorSimple Manager Anda. Kunci yang Anda dapatkan di Langkah 2 harus digunakan untuk memperbarui semua perangkat StorSimple terdaftar yang tersisa dengan layanan StorSimple Manager.

Lakukan langkah berikut untuk memperbarui enkripsi data layanan di perangkat Anda.

Untuk memperbarui kunci enkripsi data layanan di perangkat fisik

Gunakan Windows PowerShell untuk StorSimple guna tersambung ke konsol. Pilih opsi 1 untuk masuk dengan akses penuh.
Pada prompt perintah, ketik: Invoke-HcsmServiceDataEncryptionKeyChange – ServiceDataEncryptionKey
Masukkan kunci enkripsi data layanan yang Anda dapatkan di Langkah 2: Menggunakan Windows PowerShell untuk StorSimple guna menginisiasi perubahan kunci enkripsi data layanan.

Untuk memperbarui kunci enkripsi data layanan di semua appliance cloud 8010/8020

Unduh dan siapkan skrip PowerShell Update-CloudApplianceServiceEncryptionKey.ps1.
Buka PowerShell dan pada prompt perintah, ketik: Update-CloudApplianceServiceEncryptionKey.ps1 -SubscriptionId [subscription] -TenantId [tenantid] -ResourceGroupName [resource group] -ManagerName [device manager]

Skrip ini akan memastikan bahwa kunci enkripsi data layanan diatur di semua appliance cloud 8010/8020 di manajer perangkat.

Perhatian

Saat Anda sedang mempertimbangkan cara untuk terhubung ke appliance StorSimple, mohon pertimbangkan hal berikut:

Menghubungkan melalui sesi HTTPS adalah opsi yang paling aman dan direkomendasikan.
Koneksi langsung ke konsol serial perangkat aman, tetapi menyambungkan ke konsol serial melalui sakelar jaringan tidak.
Koneksi sesi HTTP merupakan salah satu opsi, tetapi koneksi tersebut tidak dienkripsi. Opsi tersebut tidak disarankan, kecuali dalam jaringan tertutup dan tepercaya.

Pembatasan yang diketahui

Berbagi file StorSimple Data Manager dan Azure memiliki beberapa batasan yang harus Anda pertimbangkan sebelum memulai, karena dapat mencegah migrasi:

Hanya volume NTFS dari alat StorSimple Anda yang didukung. Volume ReFS tidak didukung.
Volume apa pun yang ditempatkan pada Disk Dinamis Windows Server tidak didukung.
Layanan ini tidak dapat digunakan dengan volume yang dienkripsi BitLocker atau mengaktifkan Data Deduplikasi.
Cadangan StorSimple yang rusak tidak dapat dimigrasikan.
Opsi jaringan khusus, seperti firewall atau komunikasi khusus titik akhir privat, tidak dapat diaktifkan pada akun penyimpanan sumber tempat cadangan StorSimple disimpan, atau pada akun penyimpanan target yang menyimpan berbagi file Azure Anda.

Keakuratan file

Jika tidak ada batasan dalam Batasan yang diketahui mencegah migrasi, masih ada batasan tentang apa yang dapat disimpan di berbagi file Azure.

Keakuratan file mengacu pada banyak atribut, tanda waktu, dan data yang menyusun file. Dalam migrasi, keakuratan file adalah ukuran seberapa baik informasi pada sumber (volume StorSimple) dapat diterjemahkan (dimigrasikan) ke berbagi file Azure target.

Azure Files mendukung subset dari properti file NTFS. ACL Windows, metadata umum, dan beberapa tanda waktu dimigrasikan.

Item berikut tidak akan mencegah migrasi tetapi akan menyebabkan masalah per item selama migrasi:

Tanda waktu: Waktu perubahan file tidak akan diatur. Saat ini baca-saja melalui protokol REST. Tanda waktu akses terakhir pada file tidak akan dipindahkan, karena bukan atribut yang didukung pada file yang disimpan dalam berbagi file Azure.
Aliran Data Alternatif tidak dapat disimpan dalam berbagi file Azure. File yang menyimpan Data Alternatif Aliran akan disalin, tetapi Data Alternatif Aliran dilucuti dari file dalam proses.
Tautan simbolik, tautan keras, persimpangan, dan titik reparse dilewati selama migrasi. Log salinan migrasi mencantumkan setiap item yang dilewati dan alasannya.
File terenkripsi EFS gagal disalin. Salin log memperlihatkan item gagal disalin dengan "Akses ditolak".
File yang rusak dilewati. Log salinan mungkin mencantumkan kesalahan yang berbeda untuk setiap item yang rusak pada disk StorSimple: "Permintaan gagal karena kesalahan perangkat keras perangkat fatal" atau "File atau direktori rusak atau tidak dapat dibaca" atau "Struktur daftar kontrol akses (ACL) tidak valid".
File individu yang lebih besar dari 4 TiB dilewati.
Panjang jalur file harus sama dengan atau kurang dari 2048 karakter. File dan folder dengan jalur yang lebih panjang dilewati.
Titik pemisahan ulang dilewati. Setiap poin reparse Microsoft Data Deduplication / SIS atau pihak ketiga tidak dapat diselesaikan oleh mesin migrasi dan akan mencegah migrasi file dan folder yang terpengaruh.

Bagian pemecahan masalah di akhir artikel ini memiliki detail selengkapnya untuk tingkat item dan kode kesalahan tingkat pekerjaan migrasi dan jika memungkinkan, opsi mitigasinya.

Cadangan volume StorSimple

StorSimple menawarkan cadangan diferensial di tingkat volume. Berbagi file Azure juga memiliki kemampuan yang disebut sebagai berbagi rekam jepret (share snapshot).

Pekerjaan migrasi Anda hanya dapat memindahkan cadangan, bukan data dari volume langsung. Oleh karena itu, cadangan terbaru adalah yang paling dekat dengan data aktif, sehingga harus selalu menjadi bagian dari daftar cadangan yang akan dipindahkan dalam migrasi.

Putuskan apakah Anda perlu memindahkan cadangan yang lebih lama selama proses migrasi. Ini adalah praktik terbaik untuk menjaga daftar ini sesecil mungkin sehingga pekerjaan migrasi Anda selesai lebih cepat.

Untuk mengidentifikasi cadangan penting yang harus dimigrasikan, buatlah daftar periksa kebijakan pencadangan Anda. Contohnya:

Cadangan terkini.
Satu cadangan per bulan selama 12 bulan.
Satu cadangan per tahun selama tiga tahun.

Saat membuat pekerjaan migrasi, Anda dapat menggunakan daftar ini untuk mengidentifikasi cadangan volume StorSimple yang tepat yang harus dimigrasikan untuk memenuhi kebutuhan Anda.

Sebaiknya tangguhkan semua kebijakan retensi cadangan StorSimple sebelum Anda memilih cadangan untuk migrasi. Memigrasikan cadangan Anda dapat memakan waktu beberapa hari atau minggu. StorSimple menawarkan kebijakan retensi cadangan yang menghapus cadangan. Cadangan yang Anda pilih untuk migrasi ini mungkin dihapus sebelum mereka memiliki kesempatan untuk dimigrasikan.

Perhatian

Memilih lebih dari 50 cadangan volume StorSimple tidak didukung.

Memetakan volume StorSimple Anda yang sudah ada ke berbagi file Azure

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.

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

Sinkronisasi volume

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

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

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

Tip

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

Pendekatan terstruktur untuk peta penyebaran

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

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

Server tempat agen Azure File Sync dipasang dapat disinkronkan dengan hingga 30 berbagi file Azure.
Berbagi file Azure disebarkan di akun penyimpanan. Pengaturan itu menjadikan akun penyimpanan sebagai target skala untuk angka performa seperti IOPS dan throughput.

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

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

Tip

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

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

Penting

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

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

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

Skenario dan pertimbangan sinkronisasi file umum

#	Skenario sinkronisasi	Didukung	Pertimbangan (atau batasan)	Solusi (atau solusi)
1	Server file dengan beberapa disk/volume dan beberapa berbagi ke berbagi file Azure target yang sama (konsolidasi)	No	Berbagi file Azure target (titik akhir cloud) hanya mendukung sinkronisasi dengan satu grup sinkronisasi. Grup sinkronisasi hanya mendukung satu titik akhir server per server terdaftar.	1) Mulailah dengan menyinkronkan satu disk (volume akarnya) untuk menargetkan berbagi file Azure. Dimulai dengan disk/volume terbesar akan membantu persyaratan penyimpanan lokal. Konfigurasikan tingkatan cloud untuk menjenjangkan semua data ke cloud, sehingga mengosongkan ruang pada disk server file. Pindahkan data dari volume/berbagi lain ke volume saat ini yang sedang disinkronkan. Lanjutkan langkah satu per satu hingga semua data dijenjangkan ke cloud/dimigrasikan. 2) Targetkan satu volume akar (disk) pada satu waktu. Gunakan tingkatan cloud untuk menjenjangkan semua data untuk menargetkan berbagi file Azure. Hapus titik akhir server dari grup sinkronisasi, buat ulang titik akhir dengan volume/disk akar berikutnya, sinkronkan, dan ulangi prosesnya. Catatan: Penginstalan ulang agen mungkin diperlukan. 3) Merekomendasikan penggunaan beberapa berbagi file Azure target (akun penyimpanan yang sama atau berbeda berdasarkan persyaratan performa)
2	Server file dengan volume tunggal dan beberapa berbagi ke berbagi file Azure target yang sama (konsolidasi)	Ya	Tidak dapat memiliki beberapa titik akhir server per sinkronisasi server terdaftar ke berbagi file Azure target yang sama (sama seperti di atas)	Sinkronkan akar volume yang menyimpan beberapa berbagi atau folder tingkat atas. Lihat Berbagi konsep pengelompokan dan Sinkronisasi volume untuk informasi selengkapnya.
3	Server file dengan beberapa berbagi dan/atau volume ke beberapa berbagi file Azure di bawah akun penyimpanan tunggal (pemetaan berbagi 1:1)	Ya	Satu instans Windows Server (atau kluster) dapat menyinkronkan hingga 30 berbagi file Azure. Akun penyimpanan adalah target skala untuk performa. IOPS dan throughput dibagikan di seluruh berbagi file. Simpan jumlah item per grup sinkronisasi dalam 100 juta item (file dan folder) per berbagi. Idealnya yang terbaik adalah tinggal di bawah 20 atau 30 juta per saham.	1) Gunakan beberapa grup sinkronisasi (jumlah grup sinkronisasi = jumlah berbagi file Azure untuk disinkronkan). 2) Hanya 30 berbagi yang dapat disinkronkan dalam skenario ini pada satu waktu. Jika Anda memiliki lebih dari 30 berbagi di server file tersebut, gunakan Konsep pengelompokan Berbagi dan Sinkronisasi volume untuk mengurangi jumlah folder tingkat akar atau atas di sumbernya. 3) Gunakan server File Sync tambahan lokal dan pisahkan/pindahkan data ke server ini untuk mengatasi batasan pada server Windows sumber.
4	Server file dengan beberapa berbagi dan/atau volume ke beberapa berbagi file Azure di bawah akun penyimpanan yang berbeda (pemetaan berbagi 1:1)	Ya	Satu instans Windows Server (atau kluster) dapat menyinkronkan hingga 30 berbagi file Azure (akun penyimpanan yang sama atau berbeda). Simpan jumlah item per grup sinkronisasi dalam 100 juta item (file dan folder) per berbagi. Idealnya yang terbaik adalah tinggal di bawah 20 atau 30 juta per saham.	Pendekatan yang sama seperti di atas
5	Beberapa server file dengan satu (volume akar atau berbagi) ke berbagi file Azure target yang sama (konsolidasi)	No	Grup sinkronisasi tidak dapat menggunakan titik akhir cloud (berbagi file Azure) yang sudah dikonfigurasi di grup sinkronisasi lain. Meskipun grup sinkronisasi dapat memiliki titik akhir server di server file yang berbeda, file tidak dapat berbeda.	Ikuti panduan dalam Skenario # 1 di atas dengan pertimbangan tambahan untuk menargetkan satu server file pada satu waktu.

Membuat tabel pemetaan

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

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

Ikon excel yang mengatur konteks unduhan.

Unduh templat pemetaan namespace layanan.

Jumlah akun penyimpanan

Migrasi Anda kemungkinan akan mendapat manfaat dari penyebaran beberapa akun penyimpanan yang masing-masing memiliki jumlah berbagi file Azure yang lebih kecil.

Jika berbagi file Azure Anda sangat aktif (digunakan oleh banyak pengguna atau aplikasi), dua berbagi file Azure mungkin akan mencapai batas kinerja akun penyimpanan Anda. Karena itu, seringkali lebih baik bermigrasi ke beberapa akun penyimpanan, masing-masing dengan berbagi file individual mereka sendiri, dan biasanya tidak lebih dari dua atau tiga berbagi per 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 di dalamnya.

Pertimbangan ini lebih berlaku untuk akses cloud langsung (melalui Azure VM atau layanan) daripada Azure File Sync. Jika Anda berencana hanya menggunakan Azure File Sync pada berbagi file ini, Anda dapat mengelompokkan beberapa hal tersebut ke dalam satu akun penyimpanan Azure. Di masa mendatang, Anda mungkin ingin mengangkat dan mengalihkan aplikasi ke cloud yang kemudian akan langsung mengakses berbagi file, karena skenario ini akan mendapat manfaat dari memiliki IOPS dan throughput yang lebih tinggi. Selain itu, Anda dapat mulai menggunakan layanan di Azure yang juga akan mendapat manfaat dari IOPS dan throughput yang lebih tinggi.

Setelah membuat daftar berbagi Anda, petakan setiap berbagi ke akun penyimpanan tempat berbagi tersebut akan berada. Tentukan wilayah Azure dan pastikan setiap akun penyimpanan dan sumber daya Azure File Sync cocok dengan wilayah yang Anda pilih.

Penting

Jangan mengonfigurasi pengaturan jaringan dan firewall untuk akun penyimpanan sekarang. Membuat konfigurasi ini sekarang akan menggagalkan migrasi. Konfigurasikan pengaturan penyimpanan Azure setelah migrasi selesai.

Pengaturan akun penyimpanan

Ada banyak konfigurasi yang dapat Anda buat pada akun penyimpanan. Gunakan daftar periksa berikut untuk mengonfirmasi konfigurasi akun penyimpanan Anda. Anda dapat mengubah konfigurasi jaringan setelah migrasi selesai.

Berbagi file besar: Diaktifkan - Berbagi file besar meningkatkan performa dan memungkinkan Anda menyimpan hingga 100 TiB dalam berbagi. Pengaturan ini berlaku untuk akun penyimpanan dengan berbagi file Azure.
Firewall dan jaringan virtual: Dinonaktifkan - jangan konfigurasikan pembatasan IP apa pun atau batasi akses akun penyimpanan ke jaringan virtual tertentu. Titik akhir publik akun penyimpanan digunakan selama migrasi. Semua alamat dari IP Azure VM harus diizinkan. Sebaiknya konfigurasikan aturan firewall apa pun di akun penyimpanan setelah migrasi. Konfigurasikan akun penyimpanan sumber dan target Anda dengan cara ini.
Titik Akhir Privat: Didukung - Anda dapat mengaktifkan titik akhir privat, tetapi titik akhir publik digunakan untuk migrasi dan harus tetap tersedia. Ini berlaku untuk akun penyimpanan sumber dan target Anda.

Ringkasan Fase 1

Di akhir Fase 1:

Anda memiliki gambaran umum tentang perangkat dan volume StorSimple Anda.
Layanan Data Manager siap mengakses volume StorSimple Anda di cloud karena Anda telah mengambil kunci enkripsi data layanan untuk setiap perangkat StorSimple.
Anda memiliki rencana yang untuknya volume dan cadangan (jika ada selain yang terbaru) perlu dimigrasikan.
Anda tahu cara memetakan volume Anda ke berbagi file Azure dan akun penyimpanan dalam jumlah yang sesuai.

Fase 2: Menyebarkan sumber daya penyimpanan dan migrasi Azure

Bagian ini membahas pertimbangan terkait penyebaran berbagai jenis sumber daya yang diperlukan di Azure. Beberapa akan menyimpan data Anda pasca-migrasi dan beberapa diperlukan hanya untuk melakukan migrasi. Jangan menyebarkan sumber daya hingga Anda menyelesaikan rencana penyebaran. Akan sulit, terkadang tidak mungkin, untuk mengubah aspek tertentu dari sumber daya Azure Anda setelah disebarkan.

Video ini mencakup penyebaran:

Akun penyimpanan
Langganan dan grup sumber daya
Akun penyimpanan
Jenis dan nama
Performa dan ukuran berbagi
Jenis lokasi dan replikasi
Berbagi file Azure
Layanan StorSimple Data Manager

Menyebarkan akun penyimpanan

Anda mungkin perlu menyebarkan beberapa akun Azure storage. Masing-masing akan menyimpan jumlah berbagi file Azure yang lebih kecil, sesuai rencana penyebaran Anda. Buka portal Microsoft Azure untuk menyebarkan akun penyimpanan yang telah direncanakan. Pertimbangkan juga untuk mematuhi pengaturan dasar berikut untuk setiap akun penyimpanan baru.

Penting

Jangan konfigurasikan pengaturan jaringan dan firewall untuk akun penyimpanan Anda sekarang. Melakukan konfigurasi tersebut pada saat ini akan membuat migrasi menjadi mustahil. Konfigurasikan pengaturan penyimpanan Azure setelah migrasi selesai.

Langganan

Anda dapat menggunakan langganan yang sama dengan yang Anda gunakan untuk penyebaran StorSimple, atau Anda dapat menggunakan langganan lain. Satu-satunya batasan adalah langganan Anda harus berada di penyewa Microsoft Entra yang sama dengan langganan StorSimple. Pertimbangkan untuk memindahkan langganan StorSimple ke penyewa yang tepat sebelum Anda memulai migrasi. Anda hanya dapat memindahkan seluruh langganan, karena sumber daya StorSimple individual tidak dapat dipindahkan ke penyewa atau langganan lain.

Grup sumber daya

Grup sumber daya di Azure membantu organisasi sumber daya dan izin manajemen admin. Cari tahu lebih lanjut.

Nama akun penyimpanan

Nama akun penyimpanan Anda akan menjadi bagian dari URL yang digunakan untuk mengakses berbagi file Anda, dan memiliki batasan karakter tertentu. Dalam konvensi penamaan Anda, pertimbangkan bahwa nama akun penyimpanan harus unik di dunia, hanya mengizinkan huruf kecil dan angka, memerlukan antara 3 hingga 24 karakter, dan tidak mengizinkan karakter khusus seperti tanda hubung atau garis bawah. Lihat Aturan penamaan sumber daya penyimpanan Azure.

Lokasi

Wilayah Azure dari akun penyimpanan penting. Jika Anda menggunakan Azure File Sync, semua akun penyimpanan Anda harus berada di wilayah yang sama dengan sumber daya Storage Sync Service Anda. Wilayah Azure yang Anda pilih harus merupakan yang terdekat atau terpusat ke server dan pengguna lokal Anda. Setelah menyebarkan sumber daya, Anda tidak dapat mengubah wilayahnya.

Anda dapat memilih wilayah yang berbeda dari tempat data StorSimple (akun penyimpanan) Anda saat ini berada, namun, jika Anda melakukannya, biaya keluar akan berlaku selama migrasi. Data akan meninggalkan wilayah StorSimple dan memasuki wilayah akun penyimpanan Anda yang baru. Tidak ada biaya bandwidth yang dikenakan jika Anda tetap berada di wilayah Azure yang sama.

Performa

Anda memiliki opsi untuk memilih penyimpanan premium (SSD) untuk berbagi file Azure atau penyimpanan standar. Penyimpanan standar mencakup beberapa tingkatan untuk berbagi file. Penyimpanan standar adalah opsi tepat untuk sebagian besar pelanggan yang bermigrasi dari StorSimple.

Pilih penyimpanan premium jika Anda memerlukan kinerja berbagi file Azure yang premium.
Pilih penyimpanan standar untuk beban kerja server file serbaguna yang mencakup data panas dan data arsip. Pilih juga penyimpanan standar jika satu-satunya beban kerja pada berbagi file di cloud adalah Azure File Sync.
Untuk berbagi file premium, pilih Bagikan file di wizard akun penyimpanan buat.

Replikasi

Terdapat beberapa pengaturan replikasi yang tersedia. Hanya pilih dari dua opsi berikut:

Penyimpanan lokal yang redundan (LRS).
Penyimpanan zona yang redundan (ZRS) yang tidak tersedia di semua wilayah Azure.

Catatan

Penyimpanan redundan geografis (GRS) dan penyimpanan redundan zona geografis tidak didukung.

Aktifkan berbagi file berkapasitas 100 TiB

Di bagian Tingkat Lanjut dari wizard akun penyimpanan baru di portal Microsoft Azure, Anda bisa mengaktifkan dukungan Berbagi file berukuran besar di akun penyimpanan ini. Jika opsi ini tidak tersedia, Kemungkinan besar Anda memilih jenis redundansi yang salah. Pastikan Anda hanya memilih LRS atau ZRS agar opsi ini dapat tersedia.

Menggunakan berbagi file besar memiliki beberapa manfaat:

Performa sangat meningkat dibandingkan dengan berbagi file 5 TiB yang lebih kecil (misalnya, 10 kali IOPS).
Migrasi Anda akan selesai lebih cepat.
Anda memastikan bahwa berbagi file memiliki kapasitas yang cukup untuk menyimpan semua data yang akan Anda migrasikan ke dalamnya, termasuk kapasitas penyimpanan yang diperlukan cadangan diferensial.
Pertumbuhan masa depan terjamin.

Penting

Jangan terapkan jaringan khusus ke akun penyimpanan Anda sebelum atau selama migrasi Anda. Titik akhir publik harus dapat diakses pada akun penyimpanan sumber serta target. Pembatasan pada rentang IP atau jaringan virtual tertentu tidak didukung. Anda dapat mengubah konfigurasi jaringan akun penyimpanan setelah melakukan migrasi.

Berbagi file Azure

Setelah membuat akun penyimpanan Anda, buka bagian Berbagi file dari akun penyimpanan dan sebarkan jumlah berbagi file Azure yang sesuai dengan rencana migrasi Anda dari Fase 1. Pertimbangkan untuk mematuhi pengaturan dasar berikut untuk berbagi file Azure baru Anda.

Nama
Huruf kecil, angka, dan tanda hubung didukung.

Kuota
Kuota di sini dibandingkan dengan kuota keras SMB pada Windows Server eksternal. Praktik terbaik adalah tidak menetapkan kuota di sini karena migrasi Anda dan layanan lain akan gagal saat kuota tercapai.

Tingkat
Pilih Transaksi yang dioptimalkan untuk berbagi file baru Anda. Selama migrasi, banyak transaksi yang akan terjadi. Lebih hemat biaya untuk mengubah tingkat Anda nanti ke tingkat yang paling cocok untuk beban kerja Anda.

Pengelola Data StorSimple

Sumber daya Azure yang menyimpan pekerjaan migrasi Anda disebut StorSimple Data Manager. Pilih Sumber daya baru dan cari sumber daya tersebut. Lalu pilih Buat.

Sumber daya sementara ini akan digunakan untuk orkestrasi. Anda menghapusnya setelah migrasi selesai. Pastikan untuk menyebarkannya di langganan, grup sumber daya, dan wilayah yang sama dengan akun penyimpanan StorSimple Anda.

Azure File Sync

Dengan Azure File Sync, Anda dapat menambahkan penembolokan lokal dari file yang paling sering diakses. Mirip dengan kemampuan penembolokan StorSimple, fitur tingkatan cloud Azure File Sync menawarkan latensi dengan akses lokal dalam kombinasi dengan peningkatan kontrol atas kapasitas tembolok yang tersedia pada instans Windows Server dan sinkronisasi multi-situs. Jika Anda ingin memiliki tembolok lokal, maka di jaringan lokal Anda, siapkan VM Windows Server (server fisik dan klaster failover juga didukung) dengan kapasitas penyimpanan memadai yang terpasang langsung.

Penting

Jangan menyiapkan Azure File Sync Anda terlebih dahulu. Penyebaran Azure File Sync seharusnya tidak dimulai sebelum Fase 4 migrasi.

Ringkasan Fase 2

Pada akhir Fase 2, Anda sudah akan menyebarkan akun penyimpanan dan semua berbagi file Azure. Anda juga sudah akan memperoleh sumber daya Manajer Data StorSimple. Anda sudah akan menggunakan sumber daya Manajer Data StorSimple di Fase 3 saat mengonfigurasi pekerjaan migrasi Anda.

Fase 3: Membuat dan menjalankan pekerjaan migrasi

Bagian ini menjelaskan cara menyiapkan pekerjaan migrasi dan memetakan direktori pada volume StorSimple yang harus disalin ke dalam berbagi file Azure target yang Anda pilih.

Video ini mencakup:

Membuat pekerjaan migrasi
Ringkasan
Sumber
Memilih cadangan volume untuk migrasi
Target
Pemetaan direktori
Aturan semantik
Menjalankan Pekerjaan migrasi
Menjalankan definisi pekerjaan
Menampilkan status pekerjaan
Menjalankan pekerjaan secara paralel
Menginterpretasikan file log

Untuk memulai, buka Manajer Data StorSimple Anda, temukan Definisi pekerjaan pada menu, dan pilih + Definisi pekerjaan. Tipe penyimpanan target yang benar adalah default: berbagi file Azure.

Jenis pekerjaan migrasi seri StorSimple 8000.

Cuplikan layar formulir pembuatan lapangan kerja baru untuk migrasi.

Nama definisi pekerjaan
Nama harus menunjukkan himpunan file yang Anda pindahkan. Memberi nama yang sama seperti berbagi file Azure Anda adalah praktik yang baik.

Lokasi tempat pekerjaan berlangsung
Saat memilih wilayah, Anda harus memilih wilayah yang sama dengan akun penyimpanan StorSimple Anda atau jika wilayah tersebut tidak tersedia, pilihlah wilayah yang paling dekat.

Sumber

Langganan sumber
Pilih langganan untuk menyimpan sumber daya Manajer Perangkat StorSimple.

Sumber daya StorSimple
Pilih Manajer Perangkat StorSimple tempat appliance Anda terdaftar.

Kunci enkripsi data layanan
Periksa bagian sebelumnya dalam artikel ini jika Anda tidak dapat menemukan kunci dalam catatan Anda.

Perangkat
Pilih perangkat StorSimple yang menyimpan volume tempat migrasi Anda.

Volume
Pilih volume sumber. Nantinya Anda harus memutuskan apakah Anda ingin memigrasikan seluruh volume atau subdirektori ke dalam berbagi file Azure target.

Pencadangan volume
Anda dapat memilih Pilih pencadangan volume untuk memilih cadangan tertentu untuk dipindahkan sebagai bagian dari pekerjaan ini. Selanjutnya, bagian khusus dalam artikel ini membahas prosesnya secara mendetail.

Target

Pilih langganan, akun penyimpanan, dan berbagi file Azure sebagai target pekerjaan migrasi ini.

Pemetaan direktori

Bagian khusus dalam artikel ini membahas semua detail yang relevan.

Memilih cadangan volume untuk migrasi

Ada aspek penting seputar cadangan yang perlu dimigrasikan:

Pekerjaan migrasi Anda hanya dapat memindahkan cadangan, bukan data dari volume aktif. Jadi, cadangan terbaru berada paling dekat dengan data aktif dan harus selalu ada dalam daftar cadangan yang dipindahkan dalam migrasi. Saat Anda membuka dialog pemilihan Cadangan, dialog tersebut dipilih secara default.
Pastikan cadangan terbaru Anda sudah mutakhir untuk menjaga nilai delta sekecil mungkin terhadap berbagi file aktif. Mungkin ada baiknya memicu dan menyelesaikan pencadangan volume lain secara manual sebelum membuat pekerjaan memigrasi. Delta kecil ke berbagi langsung meningkatkan pengalaman migrasi Anda. Jika delta ini bisa nol, artinya tidak ada lagi perubahan pada volume StorSimple yang terjadi setelah cadangan terbaru diambil dalam daftar Anda, maka cut-over pengguna akan disederhanakan dan dipercepat secara drastis.
Cadangan harus dikembalikan ke berbagi file Azure dari yang terlama ke terbaru. Cadangan lama tidak dapat "diurutkan ke" daftar cadangan pada berbagi file Azure setelah menjalankan pekerjaan migrasi. Oleh karena itu, Anda harus memastikan bahwa daftar pencadangan Anda selesai sebelum Anda membuat pekerjaan.
Daftar cadangan dalam pekerjaan ini tidak dapat dimodifikasi setelah pekerjaan dibuat, bahkan jika pekerjaan tidak pernah berjalan.
Untuk memilih cadangan, volume StorSimple yang ingin Anda migrasikan harus online.

Untuk memilih cadangan volume StorSimple bagi pekerjaan migrasi Anda, pilih Pilih cadangan volume pada formulir pembuatan pekerjaan.

Saat bilah pemilihan cadangan terbuka, bilah tersebut dipisahkan menjadi dua daftar. Dalam daftar pertama, semua cadangan yang tersedia akan ditampilkan. Anda dapat memperluas dan mempersempit rangkaian hasil dengan memfilter menggunakan rentang waktu tertentu. (lihat bagian berikutnya)

Cadangan yang dipilih akan ditampilkan sebagai abu-abu dan ditambahkan ke daftar kedua pada bagian bawah bilah. Daftar kedua menampilkan semua cadangan yang dipilih untuk proses migrasi. Cadangan yang dipilih karena kesalahan juga dapat dihapus lagi.

Perhatian

Anda harus memilih semua cadangan yang ingin dimigrasikan. Anda tidak dapat menambahkan cadangan lama nanti. Anda tidak dapat mengubah pekerjaan untuk mengubah pilihan Anda setelah pekerjaan dibuat.

Secara default, daftar difilter untuk menampilkan cadangan volume StorSimple dalam tujuh hari terakhir. Cadangan terbaru dipilih secara default, bahkan jika itu tidak terjadi dalam tujuh hari terakhir. Untuk backup yang lebih lama, gunakan filter rentang waktu di bagian atas bilah. Anda dapat memilih dari filter yang ada atau mengatur rentang waktu kustom untuk menyaring hanya cadangan yang diambil selama periode ini.

Perhatian

Memilih lebih dari 50 cadangan volume StorSimple tidak didukung. Pekerjaan dengan cadangan dalam jumlah besar mungkin gagal. Pastikan kebijakan retensi cadangan Anda tidak menghapus cadangan terpilih sebelum mendapat kesempatan untuk dimigrasikan!

Pemetaan direktori

Pemetaan direktori adalah opsional untuk pekerjaan migrasi Anda. Jika Anda membiarkan bagian tertentu kosong, semua file dan folder di akar volume StorSimple Anda akan dipindahkan ke akar berbagi file Azure target Anda. Dalam kebanyakan kasus, menyimpan seluruh konten volume dalam berbagi file Azure bukanlah pendekatan terbaik. Sering kali lebih baik untuk membagi konten volume di beberapa berbagi file Azure. Jika Anda belum membuat paket, lihat Memetakan volume StorSimple Anda ke berbagi file Azure terlebih dahulu.

Sebagai bagian dari rencana migrasi, Anda mungkin memutuskan bahwa folder pada volume StorSimple perlu dibagi di beberapa berbagi file Azure. Jika masalahnya demikian, Anda dapat menyelesaikan pemisahan tersebut dengan:

Menentukan beberapa tugas untuk memigrasikan folder pada satu volume. Masing-masing akan memiliki sumber volume StorSimple yang sama, tetapi berbagi file Azure yang berbeda sebagai target.
Menentukan dengan tepat folder mana dari volume StorSimple yang perlu dimigrasikan ke dalam berbagi file yang ditentukan dengan menggunakan bagian Pemetaan direktori dari formulir pembuatan pekerjaan dan mengikuti semantik pemetaan tertentu.

Penting

Jalur dan ekspresi pemetaan dalam formulir ini tidak dapat divalidasi saat formulir dikirim. Jika pemetaan ditentukan dengan salah, pekerjaan mungkin akan gagal sepenuhnya atau memberikan hasil yang tidak diinginkan. Dalam hal ini, biasanya yang terbaik adalah menghapus berbagi file Azure, membuatnya kembali, lalu memperbaiki pemetaan dalam pekerjaan migrasi baru untuk berbagi file. Menjalankan pekerjaan baru dengan pernyataan pemetaan yang tetap dapat memperbaiki folder yang dihilangkan dan membawanya ke berbagi file yang ada. Namun, hanya folder yang dihilangkan karena kesalahan pengejaan jalur yang dapat diatasi melalui cara ini.

Elemen semantik

Pemetaan ditampilkan dari kiri ke kanan: [\source path] > [\target path].

Karakter semantik	Makna
\	Indikator tingkat akar.
>	[Sumber] dan operator [pemetaan target].
\| atau KEMBALI (baris baru)	Pemisah dua instruksi pemetaan folder. Atau, Anda dapat menghilangkan karakter ini dan memilih Enter untuk mendapatkan ekspresi pemetaan berikutnya di barisnya sendiri.

Contoh

Memindahkan konten folder Data pengguna ke akar berbagi file target:

\User data > \

Memindahkan seluruh konten volume ke jalur baru pada berbagi file target:

\ > \Apps\HR tracker

Memindahkan konten folder sumber ke jalur baru pada berbagi file target:

\HR resumes-Backup > \Backups\HR\resumes

Mengurutkan beberapa lokasi sumber ke struktur direktori baru:

\HR\Candidate Tracker\v1.0 > \Apps\Candidate tracker
\HR\Candidates\Resumes > \HR\Candidates\New
\Archive\HR\Old Resumes > \HR\Candidates\Archived

Aturan semantik

Selalu tentukan jalur folder yang relatif terhadap tingkat akar.
Mulai setiap jalur folder dengan indikator tingkat akar "\".
Jangan masukkan huruf kandar.
Saat menentukan beberapa jalur, jalur sumber atau target tidak boleh tumpang tindih:
Contoh tumpang tindih jalur sumber tidak valid:
\folder\1> \folder
\folder\1\2 > \folder2
Contoh tumpang tindih jalur target tidak valid:
\folder > \
\folder2 > \
Folder sumber yang tidak ada diabaikan.
Struktur folder yang tidak ada pada target dibuat.
Seperti Windows, nama folder tidak sensitif terhadap huruf besar/kecil, tetapi bersifat kasus per kasus.

Catatan

Konten folder \System Volume Information dan $Recycle.Bin pada volume StorSimple Anda tidak akan disalin dalam migrasi.

Menjalankan pekerjaan migrasi

Pekerjaan migrasi Anda tercantum di bawah Definisi pekerjaan di sumber daya Manajer Data yang telah Anda sebarkan ke grup sumber daya. Dari daftar definisi pekerjaan, pilihlah pekerjaan yang ingin Anda jalankan.

Di bilah pekerjaan yang terbuka, Anda dapat melihat status pekerjaan Anda saat ini dan daftar cadangan yang telah Anda pilih. Daftar cadangan diurutkan berdasarkan yang tertua hingga terbaru dan akan dimigrasikan ke berbagi file Azure Anda dalam urutan ini.

Awalnya, pekerjaan migrasi akan memiliki status: Never ran.
Saat Anda siap, mulai pekerjaan migrasi. Pilih gambar untuk versi dengan resolusi yang lebih tinggi.
Ketika cadangan berhasil dimigrasikan, rekam jepret berbagi file Azure otomatis akan diambil. Tanggal pencadangan asli cadangan StorSimple Anda ditempatkan di bagian Komentar dari rekam jepret berbagi file Azure. Memanfaatkan bidang ini memungkinkan Anda untuk melihat kapan data awalnya dicadangkan dibandingkan dengan waktu rekam jepret berbagi file diambil.

Perhatian

Backup harus diproses dari yang tertua hingga yang terbaru. Setelah pekerjaan migrasi dibuat, Anda tidak dapat mengubah daftar cadangan volume StorSimple yang dipilih. Jangan memulai pekerjaan jika daftar Azure Backup tidak benar atau tidak lengkap. Hapus pekerjaan dan buat yang baru dengan cadangan yang benar dipilih. Untuk setiap cadangan yang dipilih, periksa jadwal retensi Anda. Cadangan mungkin dihapus oleh satu atau beberapa kebijakan retensi Anda sebelum mereka mendapat kesempatan untuk dimigrasikan!

Kesalahan per item

Pekerjaan migrasi memiliki dua kolom dalam daftar cadangan yang mencantumkan masalah apa pun yang mungkin terjadi selama salinan:

Menyalin kesalahan
Kolom ini mencantumkan file atau folder yang seharusnya disalin tetapi tidak. Kesalahan ini sering dapat dipulihkan. Saat cadangan mencantumkan masalah item di kolom ini, tinjau log salinan. Jika Anda perlu memigrasikan file-file ini, pilih Coba kembali cadangan. Opsi ini tersedia setelah pencadangan selesai diproses. Bagian Mengelola pekerjaan migrasi menjelaskan pilihan Anda secara lebih rinci.
File yang tidak didukung
Kolom ini mencantumkan file atau folder yang tidak dapat dimigrasikan. Azure Storage memiliki batasan dalam nama file, panjang jalur, dan jenis file yang saat ini atau secara logis tidak dapat disimpan dalam berbagi file Azure. Pekerjaan migrasi tidak akan dijeda untuk jenis kesalahan ini. Mencoba kembali migrasi cadangan tidak akan mengubah hasilnya. Saat cadangan mencantumkan masalah item di kolom ini, tinjau log salinan dan perhatikan. Jika masalah tersebut muncul di cadangan terakhir Anda dan Anda menemukan di log salinan bahwa kegagalan disebabkan oleh nama file, panjang jalur, atau masalah lain yang telah Anda pengaruhi, Anda mungkin ingin memperbaiki masalah dalam volume StorSimple langsung, mengambil cadangan volume StorSimple, dan membuat pekerjaan migrasi baru hanya dengan cadangan tersebut. Anda kemudian dapat memigrasikan namespace layanan yang diperbaiki ini dan itu akan menjadi versi terbaru / langsung dari berbagi file Azure. Ini adalah proses manual dan memakan waktu. Tinjau log salinan dengan hati-hati dan evaluasi apakah itu sepadan.

Log ini adalah file *.csv yang mencantumkan item namespace layanan yang berhasil dan item yang gagal disalin. Kesalahan dibagi lagi menjadi kategori yang dibahas sebelumnya. Dari lokasi file log, Anda dapat menemukan log untuk file yang gagal dengan mencari "gagal". Hasilnya berupa set log untuk file yang gagal disalin. Urutkan log ini berdasarkan ukuran. Mungkin ada log tambahan yang diproduksi pada ukuran 17 byte. Log tersebut kosong dan dapat diabaikan. Dengan pengurutan yang demikian, Anda dapat dengan mudah berfokus pada log yang memiliki konten.

Proses yang sama berlaku untuk file log yang mencatat item yang berhasil disalin.

Kelola pekerjaan migrasi

Pekerjaan migrasi memiliki status berikut:

Tidak pernah menjalankan
Pekerjaan baru yang telah ditentukan tetapi tidak pernah dijalankan.
Menunggu
Pekerjaan di status ini sedang menunggu sumber daya disediakan dalam layanan migrasi. Ini akan secara otomatis beralih ke status yang berbeda ketika siap.
Gagal
Pekerjaan yang gagal mengalami kesalahan fatal yang mencegahnya memproses lebih banyak cadangan. Pekerjaan tidak diharapkan untuk memasuki status ini. Permintaan dukungan adalah tindakan terbaik.
Dibatalkan / Membatalkan
Baik dan seluruh pekerjaan migrasi atau cadangan individu dalam pekerjaan dapat dibatalkan. Pencadangan yang dibatalkan tidak akan diproses, karena pekerjaan migrasi yang dibatalkan akan berhenti memproses cadangan. Berharap bahwa membatalkan pekerjaan akan memakan waktu lama. Ini tidak mencegah Anda dari menciptakan pekerjaan baru. Tindakan terbaik adalah membiarkan pekerjaan sepenuhnya tiba dalam status Dibatalkan . Anda dapat mengabaikan pekerjaan yang gagal/dibatalkan atau menghapusnya nanti. Anda tidak perlu menghapus pekerjaan sebelum menghapus sumber daya Pengelola Data di akhir migrasi StorSimple Anda.

Berjalan

Pekerjaan yang sedang berjalan saat ini sedang memproses cadangan. Lihat tabel di bagian bawah bilah untuk melihat cadangan mana yang saat ini sedang diproses dan mana yang mungkin sudah dimigrasikan.
Cadangan yang sudah dimigrasikan memiliki kolom dengan tautan ke log salinan. Jika cadangan melaporkan kesalahan, Anda harus meninjau log salinannya.

Dijeda

Pekerjaan migrasi dihentikan ketika ada keputusan yang diperlukan. Kondisi ini mengaktifkan dua tombol perintah di bagian atas blade:
Pilih Coba lagi pencadangan saat cadangan menunjukkan file yang seharusnya dipindahkan tetapi tidak (Salin kesalahan kolom).
Pilih Lewati cadangan saat cadangan hilang (dihapus oleh kebijakan sejak Anda membuat pekerjaan migrasi) atau saat cadangan rusak. Anda dapat menemukan informasi kesalahan terperinci di bilah yang terbuka saat Anda mengklik cadangan yang gagal.

Saat Anda melewati atau mencoba kembali cadangan saat ini, layanan migrasi akan membuat salinan bayangan baru di grup file Azure target Anda. Anda mungkin ingin menghapus yang sebelumnya nanti, karena kemungkinan tidak lengkap.

Selesai dan Selesai dengan peringatan

Pekerjaan migrasi terdaftar sebagai Selesai ketika semua cadangan dalam pekerjaan telah berhasil diproses.
Lengkap dengan peringatan adalah status yang terjadi ketika:

Sebuah cadangan mengalami masalah yang dapat dipulihkan. Cadangan ini ditandai sebagai keberhasilan parsial atau gagal.
Anda memutuskan untuk melanjutkan pekerjaan yang berhenti dengan melewatkan cadangan dengan masalah tersebut. (Anda memilih Lewati cadangan alih-alih mencoba kembali cadangan)

Jika pekerjaan migrasi selesai dengan peringatan, Anda harus selalu meninjau log salinan untuk cadangan yang relevan.

Menjalankan pekerjaan secara paralel

Anda kemungkinan akan memiliki beberapa volume StorSimple, masing-masing dengan berbagi mereka sendiri yang harus dimigrasikan ke berbagi file Azure. Sangat penting bahwa Anda memahami berapa banyak yang dapat Anda lakukan secara paralel. Ada batasan yang tidak ditegakkan pada pengalaman pengguna dan akan menurunkan atau menghambat migrasi lengkap jika pekerjaan dijalankan pada saat yang sama.

Tidak ada batasan dalam mendefinisikan pekerjaan migrasi. Anda dapat menentukan volume sumber StorSimple yang sama, berbagi file Azure yang sama, di seluruh appliance StorSimple yang sama atau berbeda. Namun, menjalankannya memiliki keterbatasan:

Hanya satu pekerjaan migrasi dengan volume sumber StorSimple yang sama yang dapat berjalan pada saat yang sama.
Hanya satu pekerjaan migrasi dengan target yang sama berbagi file azure dapat berjalan pada saat yang sama.
Sebelum memulai pekerjaan berikutnya, pastikan bahwa salah satu pekerjaan sebelumnya berada di copy stage dan menunjukkan kemajuan pemindahan file setidaknya selama 30 menit.
Anda dapat menjalankan hingga empat pekerjaan migrasi secara paralel per manajer perangkat StorSimple, selama Anda mematuhi aturan sebelumnya.

Ketika Anda mencoba untuk memulai pekerjaan migrasi, aturan sebelumnya diperiksa. Jika ada pekerjaan yang berjalan, Anda mungkin tidak dapat memulai pekerjaan baru. Anda akan menerima pemberitahuan yang mencantumkan nama pekerjaan yang sedang berjalan yang harus diselesaikan sebelum Anda dapat memulai pekerjaan baru.

Tip

Ada baiknya untuk secara teratur memeriksa pekerjaan migrasi Anda di tab Definisi pekerjaan sumber daya Data Manager Anda untuk melihat apakah salah satu dari mereka telah dijeda dan memerlukan input Anda untuk diselesaikan.

Ringkasan Fase 3

Pada akhir Fase 3, Anda setidaknya akan menjalankan salah satu pekerjaan migrasi dari volume StorSimple ke dalam berbagi file Azure. Dengan menjalankan Anda, Anda akan telah memigrasikan backup yang Anda tentukan ke dalam salinan bayangan berbagi file Azure. Sekarang Anda dapat berfokus pada penyiapan Azure File Sync untuk berbagi file (setelah pekerjaan migrasi berbagi file selesai) atau mengarahkan akses berbagi file untuk pekerja informasi dan aplikasi Anda ke berbagi file Azure.

Fase 4: Mengakses berbagi file Azure Anda

Ada dua strategi utama untuk mengakses berbagi file Azure Anda:

Azure File Sync: Menyebarkan Azure File Sync ke instans Windows Server lokal. Azure File Sync memiliki semua keuntungan dari tembolok lokal, seperti StorSimple.
Akses berbagi langsung: Menyebarkan akses berbagi langsung. Gunakan strategi ini jika skenario akses Anda untuk berbagi file Azure tertentu tidak akan mendapat manfaat dari penembolokan lokal, atau jika Anda tidak lagi memiliki kemampuan untuk menghosting instans Windows Server lokal. Di sini, pengguna dan aplikasi Anda akan terus mengakses berbagi file SMB melalui protokol SMB. Berbagi file ini tidak lagi berada di server lokal, tetapi langsung berada di cloud.

Anda seharusnya sudah memutuskan opsi terbaik bagi Anda di Fase 1 dari panduan ini.

Sisa bagian ini akan berfokus pada instruksi penyebaran.

Video ini mencakup:

Pendekatan untuk mengakses berbagi file Azure
Azure File Sync
Akses berbagi langsung
Menyebarkan Azure File Sync
Menyebarkan sumber daya cloud Azure File Sync
Menyebarkan instans Windows Server lokal
Menyiapkan instans Windows Server untuk Azure File Sync
Mengonfigurasi Azure File Sync pada instans Windows Server
Memantau sinkronisasi awal
Menguji Azure File Sync
Membuat berbagi SMB

Menyebarkan Azure File Sync

Saatnya untuk menyebarkan sebagian dari Azure File Sync.

Buat sumber daya cloud Azure File Sync.
Sebarkan agen Azure File Sync di server lokal Anda.
Daftarkan server dengan sumber daya cloud.

Jangan dahulu membuat grup sinkronisasi mana pun. Menyiapkan sinkronisasi dengan berbagi file Azure hanya boleh dilakukan setelah migrasi Anda ke berbagi file Azure telah selesai. Jika Anda mulai menggunakan Azure File Sync sebelum migrasi selesai, itu akan membuat migrasi Anda tidak perlu sulit karena Anda tidak akan dapat dengan mudah mengetahui kapan saatnya untuk memulai cut-over.

Menyebarkan sumber daya cloud Azure File Sync

Untuk menyelesaikan langkah ini, Anda memerlukan info masuk langganan Azure Anda.

Sumber daya inti yang akan dikonfigurasi untuk Sinkronisasi File Azure disebut Storage Sync Service. Disarankan agar Anda hanya menggunakan satu untuk semua server yang menyinkronkan kumpulan file yang sama sekarang atau di masa mendatang. Buat beberapa Storage Sync Service hanya jika Anda memiliki kumpulan server berbeda yang tidak boleh bertukar data. Misalnya, Anda mungkin memiliki server yang tidak boleh menyinkronkan berbagi file Azure yang sama. Jika tidak, menggunakan Storage Sync Service tunggal adalah praktik terbaik.

Pilih wilayah Azure untuk Storage Sync Service yang dekat dengan lokasi Anda. Semua sumber daya cloud lainnya harus disebarkan di wilayah yang sama. Untuk menyederhanakan manajemen, buat grup sumber daya baru di langganan Anda yang menampung sumber daya sinkronisasi dan penyimpanan.

Untuk informasi selengkapnya, lihat bagian tentang menyebarkan Storage Sync Service di artikel tentang menyebarkan Sinkronisasi File Azure. Ikuti hanya bagian artikel ini. Akan ada tautan ke bagian lain dari artikel di langkah-langkah selanjutnya.

Tip

Jika Anda ingin mengubah wilayah Azure tempat data Anda berada setelah migrasi selesai, silakan sebarkan Storage Sync Service di wilayah yang sama dengan akun penyimpanan target untuk migrasi ini.

Menyebarkan instans Windows Server lokal

Buat Windows Server 2019 (paling sedikit 2012R2) sebagai komputer virtual atau server fisik. Kluster failover Windows Server juga didukung. Jangan menggunakan kembali server yang berada pada StorSimple 8100 atau 8600.
Sediakan atau tambahkan penyimpanan yang terpasang secara langsung. Penyimpanan yang tersambung ke jaringan tidak didukung.

Praktik terbaiknya adalah memberikan instans Windows Server baru Anda jumlah penyimpanan yang sama atau lebih besar daripada appliance StorSimple 8100 atau 8600 Anda yang telah tersedia secara lokal untuk penembolokan. Anda akan menggunakan instans Windows Server dengan cara yang sama seperti Anda menggunakan appliance StorSimple. Jika memiliki jumlah penyimpanan yang sama dengan appliance, pengalaman penembolokan harus serupa, jika tidak sama. Anda dapat menambahkan atau menghapus penyimpanan dari instans Windows Server kapan saja. Kemampuan ini memungkinkan Anda untuk menskalakan ukuran volume lokal Anda dan jumlah penyimpanan lokal yang tersedia untuk penembolokan.

Menyiapkan instans Windows Server untuk sinkronisasi file

Di bagian ini, Anda memasang agen Azure File Sync pada instans Windows Server Anda.

Panduan penyebaran menjelaskan bahwa Anda perlu menonaktifkan Konfigurasi Keamanan Tingkat Tinggi Internet Explorer. Langkah keamanan ini tidak berlaku untuk Azure File Sync. Menonaktifkannya memungkinkan Anda mengautentikasi ke Azure tanpa masalah.

Buka PowerShell. Pasang modul PowerShell yang diperlukan dengan menggunakan perintah berikut. Pastikan untuk memasang modul lengkap dan penyedia NuGet ketika Anda diminta untuk melakukannya.

Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync

Jika Anda memiliki masalah menjangkau internet dari server Anda, sekarang saatnya untuk menyelesaikannya. Azure File Sync menggunakan koneksi jaringan yang tersedia ke internet. Mengharuskan server proxy untuk menjangkau internet juga didukung. Anda dapat mengonfigurasi proksi di seluruh komputer sekarang atau, selama penginstalan agen, tentukan proksi yang hanya akan digunakan oleh Azure File Sync.

Jika mengonfigurasi proxy berarti Anda perlu membuka firewall untuk server, pendekatan tersebut mungkin dapat diterima oleh Anda. Di akhir penginstalan server, setelah Anda menyelesaikan pendaftaran server, laporan konektivitas jaringan akan menunjukkan titik akhir URL yang tepat di Azure yang perlu dikomunikasikan dengan Azure File Sync untuk wilayah yang Anda pilih. Laporan ini juga memberi tahu Anda mengapa komunikasi diperlukan. Anda dapat menggunakan laporan untuk mengunci firewall di sekitar server ke URL tertentu.

Anda juga dapat mengambil pendekatan yang lebih konservatif ketika Anda tidak membuka firewall lebar-lebar. Sebagai gantinya, Anda dapat membatasi server untuk berkomunikasi dengan ruang nama DNS tingkat lebih tinggi. Untuk informasi selengkapnya, lihat Proksi Azure File Sync dan pengaturan firewall. Ikuti praktik terbaik jaringan Anda sendiri.

Di akhir wisaya pemasangan wisaya server, wisaya pendaftaran server akan terbuka. Daftarkan server ke sumber daya Azure Storage Sync Service Anda dari yang lebih lama.

Langkah-langkah ini dijelaskan secara lebih rinci dalam panduan penyebaran, yang mencakup modul PowerShell yang harus Anda pasang terlebih dahulu: Pemasangan agen Azure File Sync.

Gunakan agen terbaru. Anda dapat mengunduhnya dari Pusat Unduhan Microsoft: Azure File Sync Agent.

Setelah penginstalan dan pendaftaran server berhasil, Anda dapat mengonfirmasi bahwa Anda telah berhasil menyelesaikan langkah ini. Buka sumber daya Storage Sync Service di portal Microsoft Azure. Di menu sebelah kiri, buka Server terdaftar. Anda akan melihat server Anda tercantum di sana.

Mengonfigurasi Azure File Sync pada instans Windows Server

Instans Windows Server lokal Anda yang terdaftar harus siap dan terhubung ke internet untuk proses ini.

Penting

Migrasi StorSimple file dan folder Anda ke dalam berbagi file Azure harus diselesaikan sebelum Anda melanjutkan. Pastikan tidak ada lagi perubahan yang dilakukan pada berbagi file.

Langkah ini menyatukan semua sumber daya dan folder yang telah Anda siapkan di instans Windows Server Anda selama langkah sebelumnya.

Masuk ke portal Azure.
Temukan sumber daya Storage Sync Service Anda.
Buat grup sinkronisasi baru dalam sumber daya Storage Sync Service untuk setiap berbagi file Azure. Di terminologi Sinkronisasi File Azure, berbagi file Azure akan menjadi titik akhir cloud di topologi sinkronisasi yang Anda jelaskan dengan pembuatan grup sinkronisasi. Saat Anda membuat grup sinkronisasi, beri nama yang familier sehingga Anda mengenali kumpulan file mana yang disinkronkan di sana. Pastikan Anda mereferensikan berbagi file Azure dengan nama yang cocok.
Setelah Anda membuat grup sinkronisasi, baris untuk grup tersebut akan muncul dalam daftar grup sinkronisasi. Pilih nama (tautan) untuk menampilkan konten grup sinkronisasi. Anda akan melihat berbagi file Azure di Titik akhir Cloud.
Temukan tombol Tambahkan Titik Akhir Server. Folder di server lokal yang telah Anda provisikan akan menjadi jalur untuk titik akhir server ini.

Penting

Pastikan untuk mengaktifkan tingkatan cloud. Cloud tiering adalah fitur Azure File Sync yang memungkinkan server lokal memiliki kapasitas penyimpanan lebih sedikit daripada yang disimpan di cloud, tetapi memiliki namespace lengkap yang tersedia. Data yang menarik secara lokal juga di-cache secara lokal untuk performa cepat. Alasan lain untuk mengaktifkan tingkatan cloud pada langkah ini adalah bahwa kita tidak ingin menyinkronkan konten file pada tahap ini. Hanya namespace yang harus dipindahkan saat ini.

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.

Ringkasan Fase 4

Pada fase ini, Anda telah membuat dan menjalankan beberapa pekerjaan migrasi di Manajer Data StorSimple milik Anda. Pekerjaan tersebut telah memigrasikan file dan folder Anda ke berbagi file Azure. Anda juga telah menyebarkan Azure File Sync atau menyiapkan akun jaringan dan penyimpanan Anda untuk akses berbagi langsung.

Fase 5: Pemindahan pengguna

Dalam fase ini, Anda akan menyelesaikan migrasi:

Silakan rencanakan waktu henti Anda.
Ikuti perubahan apa pun yang dilakukan pengguna dan aplikasi Anda di sisi StorSimple saat pekerjaan migrasi di Fase 3 telah berlangsung.
Lakukan failover pada pengguna Anda ke instans Windows Server yang baru dengan Azure File Sync atau berbagi file Azure melalui akses berbagi langsung.

Video ini mencakup:

Langkah-langkah yang harus diambil sebelum cut-over beban kerja Anda
Mengeksekusi cut-over Anda
Langkah-langkah pasca-potong

Merencanakan waktu henti Anda

Pendekatan migrasi ini memerlukan waktu henti bagi pengguna dan aplikasi Anda. Tujuannya adalah untuk menjadikan waktu henti sesebentar mungkin. Pertimbangan berikut akan berlaku:

Tetap sediakan volume StorSimple Anda saat menjalankan pekerjaan migrasi Anda.
Setelah Anda selesai menjalankan pekerjaan migrasi data untuk berbagi file, saatnya menghapus akses pengguna (setidaknya akses tulis) dari volume atau berbagi file StorSimple. RoboCopy yang terakhir akan memperbarui (catch up) berbagi file Azure Anda. Kemudian Anda dapat memindahkan pengguna Anda. Tempat Anda menjalankan RoboCopy bergantung pada apakah Anda memilih untuk menggunakan Azure File Sync atau akses berbagi langsung. Bagian yang akan datang mencakup subjek tersebut.
Setelah RoboCopy menyelesaikan pembaruan (catch up), Anda siap untuk mengekspos lokasi baru kepada pengguna Anda dengan berbagi file Azure secara langsung atau berbagi file SMB pada instans Windows Server dengan Azure File Sync. Sering kali penyebaran DFS-N akan membantu mencapai pemindahan yang cepat dan efisien. Ini akan membuat alamat berbagi file Anda yang sudah ada tetap konsisten dan mengarah kembali ke lokasi baru yang berisi file dan folder Anda yang telah dimigrasikan.

Untuk data arsip, ini adalah pendekatan yang sepenuhnya layak untuk mengambil waktu henti pada volume StorSimple Anda (atau subfolder), ambil satu lagi cadangan volume StorSimple, migrasi, lalu buka tujuan migrasi untuk akses oleh pengguna dan aplikasi. Ini akan memberi Anda kebutuhan untuk mengejar RoboCopy. Namun, pendekatan ini datang dengan biaya jendela downtime berkepanjangan yang mungkin membentang hingga beberapa hari atau lebih tergantung pada jumlah file dan cadangan yang Anda butuhkan untuk bermigrasi. Ini mungkin hanya pilihan untuk beban kerja arsip yang dapat dilakukan tanpa menulis akses untuk jangka waktu yang lama.

Menentukan kapan namespace Anda telah sepenuhnya disinkronkan ke server Anda

Saat Anda menggunakan Azure File Sync untuk berbagi file Azure, penting untuk menentukan bahwa seluruh namespace layanan Anda telah selesai mengunduh ke server sebelum Anda memulai RoboCopy lokal. Waktu yang diperlukan untuk mengunduh namespace akan bergantung pada jumlah item di berbagi file Azure Anda. Ada dua metode untuk menentukan apakah namespace Anda telah sepenuhnya tiba di server.

Portal Azure

Anda dapat menggunakan portal Microsoft Azure untuk melihat kapan namespace Anda telah sepenuhnya tiba.

Masuk ke portal Microsoft Azure dan masuk ke grup sinkronisasi Anda. Periksa status grup sinkronisasi dan titik akhir server Anda.
Bagian yang menarik adalah pengunduhan. Jika titik akhir server baru disediakan, hal ini akan menampilkan Sinkronisasi awal yang menunjukkan namespace masih belum tiba sepenuhnya. Setelah status itu berubah kecuali jika berubah menjadi Sinkronisasi awal, namespace Anda akan terisi di server.

Anda sekarang dapat melanjutkan proses dengan RoboCopy lokal.

Pemantau Peristiwa Windows Server

Anda juga bisa menggunakan Pemantau Peristiwa pada instans Windows Server Anda untuk mengetahui kapan namespace telah sepenuhnya tiba.

Buka Pemantau Peristiwa, lalu buka Aplikasi dan Layanan.
Buka Microsoft\FileSync\Agent\Telemetry.
Cari kejadian terbaru 9102, yang sesuai dengan sesi sinkronisasi yang selesai.
Pilih Detail, lalu konfirmasikan bahwa Anda sedang melihat kejadian yang mana nilai SyncDirection adalah Unduh.
Untuk waktu saat namespace Anda telah selesai diunduh ke server, akan ada satu kejadian dengan Skenario, nilai FullGhostedSync, dan HResult = 0.
Jika melewatkan kejadian itu, Anda juga dapat mencari kejadian 9102 lainnya dengan SyncDirection = Unduh dan Skenario = "RegularSync". Jika Anda menemukan salah satu kejadian ini, hal itu juga menunjukkan bahwa namespace telah selesai diunduh dan sinkronisasi sedang berlangsung ke sesi sinkronisasi reguler, terlepas dari apakah ada sesuatu yang harus disinkronkan atau tidak saat ini.

RoboCopy akhir

Pada tahap ini, ada perbedaan antara instans Windows Server lokal Anda dan appliance StorSimple 8100 atau 8600.

Anda perlu mengikuti perubahan yang dihasilkan pengguna atau aplikasi di sisi StorSimple saat migrasi berlangsung.
Untuk kasus jika Anda menggunakan Azure File Sync: Appliance StorSimple memiliki tembolok yang terisi versus instans Windows Server hanya dengan namespace tanpa konten file yang disimpan secara lokal saat ini. RoboCopy akhir dapat membantu memulai tembolok Azure File Sync lokal Anda dengan menarik konten file yang ditembolokkan secara lokal sebanyak yang tersedia dan dapat sesuai di server Azure File Sync.
Beberapa file mungkin tertinggal dari pekerjaan migrasi karena karakter yang tidak valid. Jika demikian halnya, silakan salin file tersebut ke instans Windows Server yang diaktifkan oleh Azure File Sync. Nantinya, Anda dapat menyesuaikannya sehingga akan disinkronkan. Jika Anda tidak menggunakan Azure File Sync untuk berbagi tertentu, Anda lebih baik mengganti nama file dengan karakter yang tidak valid pada volume StorSimple. Kemudian jalankan RoboCopy langsung terhadap berbagi file Azure.

Peringatan

Robocopy di Windows Server 2019 mengalami masalah yang menyebabkan file berjenjang oleh Azure File Sync di server target dikodekan ulang dari sumber dan diunggah ulang ke Azure saat menggunakan /MIR fungsi . Sebaiknya jalankan Robocopy di Windows Server selain 2019, seperti Windows Server 2016.

Peringatan

Anda tidak boleh memulai RoboCopy sebelum server memiliki namespace untuk berbagi file Azure yang diunduh sepenuhnya. Untuk informasi selengkapnya, lihat Menentukan kapan namespace Anda telah sepenuhnya diunduh ke server Anda.

Anda hanya ingin menyalin file yang diubah setelah pekerjaan migrasi terakhir berlangsung dan file yang belum dipindahkan melalui pekerjaan ini sebelumnya. Anda dapat menyelesaikan masalah penyebab mereka tidak dapat bergerak di server setelah migrasi selesai. Untuk informasi selengkapnya, lihat Pemecahan Masalah Azure File Sync.

Terdapat beberapa parameter untuk RoboCopy. Contoh berikut menampilkan perintah penyelesaian dan daftar alasan untuk memilih parameter ini.

robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>

Mengalihkan	Makna
`/MT:n`	Memungkinkan Robocopy untuk menjalankan multiutas. Default untuk `n` adalah 8. Maksimum adalah 128 utas. Sementara jumlah utas yang tinggi membantu memenuhi bandwidth yang tersedia, itu tidak berarti migrasi Anda akan selalu lebih cepat dengan lebih banyak utas. Pengujian dengan Azure Files menunjukkan antara 8 dan 20 memperlihatkan kinerja yang seimbang untuk menjalankan salinan awal. Proses `/MIR` berikutnya secara progresif dipengaruhi oleh komputasi yang tersedia vs bandwidth jaringan yang tersedia. Untuk proses selanjutnya, cocokkan nilai jumlah utas Anda lebih dekat dengan jumlah inti prosesor dan jumlah utas per inti Anda. Pertimbangkan apakah core perlu dicadangkan untuk tugas lain yang mungkin dilakukan oleh server produksi. Pengujian dengan Azure Files telah menunjukkan bahwa hingga 64 utas menghasilkan performa yang baik, tetapi hanya jika prosesor Anda dapat membuatnya tetap hidup pada saat yang sama.
`/R:n`	Jumlah coba lagi maksimum untuk file yang gagal disalin pada upaya pertama. Robocopy akan mencoba `n` waktu sebelum file secara permanen gagal menjalankan salinan. Anda dapat mengoptimalkan kinerja yang Anda jalankan: Pilih nilai dua atau tiga jika Anda yakin masalah batas waktu menyebabkan kegagalan di masa lalu. Ini mungkin lebih umum melalui tautan WAN. Pilih tidak mencoba ulang atau nilai satu jika Anda yakin file gagal menyalin karena sedang digunakan secara aktif. Mencoba lagi beberapa detik kemudian mungkin tidak cukup waktu untuk status file yang digunakan untuk berubah. Pengguna atau aplikasi yang menahan file terbuka mungkin memerlukan waktu beberapa jam lebih lama. Dalam hal ini, menerima file tidak disalin dan menangkapnya di salah satu rencana Anda, Robocopy berjalan berikutnya, mungkin akhirnya berhasil dalam menyalin file dengan sukses. Hal itu membantu eksekusi saat ini untuk menyelesaikan lebih cepat tanpa diperpanjang oleh banyak percobaan ulang yang akhirnya berakhir di sebagian besar kegagalan salinan karena file masih terbuka melewati batas waktu percobaan ulang.
`/W:n`	Menentukan waktu tunggu Robocopy sebelum mencoba menyalin file yang tidak berhasil disalin selama upaya sebelumnya. `n` adalah jumlah detik untuk menunggu di antara coba lagi. `/W:n` sering digunakan bersama dengan `/R:n`.
`/B`	Menjalankan Robocopy dalam mode yang sama dengan yang akan digunakan aplikasi cadangan. Pengalih ini memungkinkan Robocopy memindahkan file yang izinnya tidak dimiliki pengguna saat ini. Sakelar cadangan bergantung pada menjalankan perintah Robocopy di konsol tinggi administrator atau jendela PowerShell. Jika Anda menggunakan Robocopy untuk Azure Files, pastikan Anda memasang berbagi file Azure menggunakan kunci akses akun penyimpanan vs. identitas domain. Jika tidak, pesan kesalahan mungkin tidak secara intuitif mengarahkan Anda ke resolusi masalah.
`/MIR`	(Mencerminkan sumber ke target.) Memungkinkan Robocopy menyalin hanya delta antara sumber serta target. Subdirektori kosong akan disalin. Item (file atau folder) yang telah berubah atau tidak ada pada target akan disalin. Item yang ada pada target tetapi tidak pada sumber akan dihapus menyeluruh (dihapus) dari target. Saat Anda menggunakan pengalih ini, cocokkan struktur folder sumber dan target. Pencocokan berarti menyalin dari tingkat sumber dan folder yang benar ke tingkat folder yang cocok pada target. Hanya dengan begitu salinan "catch up" bisa berhasil. Saat sumber dan target tidak cocok, penggunaan `/MIR` akan menyebabkan penghapusan dan penyalinan ulang dalam skala besar.
`/IT`	Memastikan fidelitas dipertahankan dalam skenario cermin tertentu. Misalnya, jika file mengalami perubahan ACL dan pembaruan atribut di antara dua proses Robocopy, file tersebut akan ditandai sebagai tersembunyi. Tanpa `/IT`, perubahan ACL mungkin terlewatkan oleh Robocopy dan tidak ditransfer ke lokasi target.
`/COPY:[copyflags]`	Fidelitas salinan file. Default: `/COPY:DAT`. Bendera salinan: `D`= Data, `A`= Atribut, `T`= Tanda waktu, `S`= Keamanan = ACL NTFS, `O`= Informasi pemilik, `U`= Informasi audit. Informasi audit tidak dapat disimpan dalam berbagi file Azure.
`/DCOPY:[copyflags]`	Fidelitas untuk salinan direktori. Default: `/DCOPY:DA`. Bendera salinan: `D`= Data, `A`= Atribut, `T`= Tanda waktu.
`/NP`	Menentukan bahwa perkembangan penyalinan untuk setiap file dan folder tidak akan ditampilkan. Menampilkan kemajuan secara signifikan menurunkan performa salinan.
`/NFL`	Menentukan bahwa nama file tidak dicatat. Meningkatkan performa salinan.
`/NDL`	Menentukan bahwa nama direktori tidak dicatat. Meningkatkan performa salinan.
`/XD`	Menentukan direktori yang akan dikecualikan. Saat menjalankan Robocopy pada akar volume, pertimbangkan untuk mengecualikan `System Volume 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.
`/LFSM`	Hanya untuk target dengan penyimpanan bertingkat. Tidak didukung ketika tujuan adalah berbagi SMB jarak jauh. Menentukan bahwa Robocopy beroperasi dalam "mode ruang kosong rendah." Sakelar ini hanya berguna untuk target dengan penyimpanan berjenjang yang mungkin kehabisan kapasitas lokal sebelum Robocopy selesai. Ini ditambahkan khusus untuk digunakan dengan target yang diaktifkan untuk tingkatan cloud Azure File Sync. Ini dapat digunakan secara terpisah dari Azure File Sync. Dalam mode ini, Robocopy akan berhenti sejenak setiap kali salinan file akan menyebabkan ruang bebas volume tujuan berada di bawah nilai "lantai". Nilai ini dapat ditentukan oleh bentuk `/LFSM:n` bendera. Parameter `n` ditentukan dalam basis 2: `nKB`, `nMB` atau `nGB`. `/LFSM`Jika ditentukan tanpa nilai lantai eksplisit, lantai diatur ke 10 persen dari ukuran volume tujuan. Mode ruang bebas rendah tidak kompatibel dengan `/MT`, `/EFSRAW`, atau `/ZB`. Dukungan untuk `/B` ditambahkan di Windows Server 2022. Silakan lihat bagian Windows Server 2022 dan RoboCopy LFSM di bawah ini untuk informasi selengkapnya, termasuk detail mengenai bug dan solusi terkait.
`/Z`	Gunakan 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.

Saat Anda mengonfigurasi lokasi sumber dan target untuk perintah RoboCopy, pastikan Anda meninjau struktur sumber dan target untuk memastikan kecocokannya. Jika Anda menggunakan fitur pemetaan direktori dari pekerjaan migrasi, struktur direktori akar Anda mungkin berbeda dari struktur volume StorSimple Anda. Jika masalahnya demikian, Anda mungkin memerlukan beberapa pekerjaan RoboCopy, satu untuk setiap subdirektori. Jika Anda tidak yakin apakah perintah akan berfungsi sesuai harapan, Anda dapat menggunakan parameter /L, yang akan mensimulasikan perintah tanpa benar-benar membuat perubahan apa pun.

Perintah RoboCopy ini menggunakan /MIR, sehingga tidak akan memindahkan file yang sama (file berjenjang, misalnya). Tetapi jika Anda salah mendapatkan jalur sumber dan target, /MIR hapus menyeluruh struktur direktori pada instans Windows Server atau berbagi file Azure yang tidak ada di jalur sumber StorSimple. Mereka harus mencocokkan pekerjaan RoboCopy dengan persis untuk mencapai tujuan yang dimaksudkan dengan tujuan memperbarui konten Anda yang dimigrasikan dengan perubahan terbaru yang dilakukan saat migrasi berlangsung.

Lihat file log RoboCopy untuk melihat apakah ada file yang tertinggal. Jika ada masalah, silakan perbaiki dan jalankan ulang perintah RoboCopy. Jangan melakukan deprovisi terhadap sumber daya StorSimple apa pun sebelum Anda memperbaiki masalah yang luar biasa untuk file atau folder yang Anda butuhkan.

Jika Anda tidak menggunakan Azure File Sync untuk menembolok berbagi file Azure tertentu yang dimaksud, namun memilih akses pembagian langsung:

Pasang berbagi file Azure Anda sebagai drive jaringan ke mesin Windows lokal.
Lakukan RoboCopy antara StorSimple Anda dan berbagi file Azure yang dipasang. Jika file tidak disalin, perbaiki namanya di sisi StorSimple untuk menghapus karakter yang invalid. Kemudian coba ulang RoboCopy. Perintah RoboCopy yang sebelumnya terdaftar dapat dijalankan beberapa kali tanpa menyebabkan pemanggilan kembali yang tidak diperlukan ke StorSimple.

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

Windows Server 2022 dan RoboCopy LFSM

Sakelar RoboCopy /LFSM dapat digunakan untuk menghindari kegagalan pekerjaan RoboCopy dengan kesalahan volume penuh. RoboCopy akan memberi jeda setiap kali salinan file menyebabkan ruang bebas volume penyedia tujuan berada di bawah nilai "dasar".

Gunakan RoboCopy dengan Windows Server 2022. Hanya ini versi RoboCopy yang berisi perbaikan bug dan fitur penting yang membuat sakelar kompatibel dengan bendera tambahan yang diperlukan di sebagian besar migrasi. Misalnya, kompatibilitas dengan bendera /B.

/B menjalankan RoboCopy dalam mode yang sama dengan yang akan digunakan aplikasi cadangan. Sakelar ini memungkinkan RoboCopy memindahkan file yang izinnya tidak dimiliki pengguna saat ini.

Biasanya, RoboCopy dapat dijalankan pada Sumber, Tujuan, atau komputer ketiga.

Penting

Jika Anda berniat menggunakan /LFSM, RoboCopy harus dijalankan di server Azure File Sync target Windows Server 2022.

Perhatikan juga bahwa dengan /LFSM Anda juga harus menggunakan jalur lokal untuk penyedia tujuan, bukan jalur UNC. Misalnya sebagai jalur penyedia tujuan Anda harus menggunakan E:\Foldername dan bukan jalur UNC seperti \\ServerName\FolderName.

Perhatian

Versi RoboCopy yang saat ini tersedia di Windows Server 2022 memiliki bug yang menyebabkan jeda dihitung sebagai jumlah kesalahan per file. Terapkan solusi berikut.

Bendera /R:2 /W:1 yang direkomendasikan meningkatkan peluang bahwa file gagal karena jeda yang diinduksi /LFSM. Dalam contoh ini, file yang tidak disalin setelah 3 jeda karena /LFSM menyebabkan jedanya, akan menyebabkan kesalahan sehingga RoboCopy menggagalkan file. Solusinya adalah dengan menggunakan nilai yang lebih tinggi untuk /R:n dan /W:n. Contoh yang baik adalah /R:10 /W:1800 (10 kali percobaan ulang selama 30 menit masing-masing). Ini harus memberikan waktu algoritma tingkat Azure File Sync untuk membuat ruang pada volume penyedia tujuan.

Bug ini telah diperbaiki tetapi perbaikan belum tersedia untuk umum. Lihat paragraf ini untuk pembaruan tentang ketersediaan perbaikan dan cara menyebarkannya.

Cut-ver pengguna

Jika Anda menggunakan Azure File Sync, Anda mungkin perlu membuat pembagian SMB pada instans Windows Server yang diaktifkan oleh Azure File Sync yang cocok dengan pembagian yang Anda miliki pada volume StorSimple. Anda dapat melakukan front-load pada langkah ini dan melakukannya lebih awal untuk mencegah kehilangan waktu di sini. Namun Anda harus memastikan bahwa sebelum titik ini, tidak ada yang memiliki akses untuk menyebabkan perubahan pada instans Windows Server.

Jika Anda memiliki penyebaran DFS-N, Anda dapat mengarahkan DFN-Namespaces ke lokasi folder server yang baru. Jika Anda tidak memiliki penyebaran DFS-N dan Anda membuka appliance 8100 atau 8600 Anda secara lokal melalui instans Windows Server, Anda dapat menghapus server tersebut dari domain. Kemudian gabungkan dengan domain instans Windows Server baru yang diaktifkan oleh Azure File Sync Anda. Selama proses itu, beri nama yang sama kepada server dan bagikan nama sebagai server lama sehingga pemindahan tetap transparan untuk pengguna, kebijakan grup, dan skrip Anda.

Pelajari lebih lanjut tentang DFS-N.

Fase 6: Deprovisi

Saat Anda melakukan deprovisi terhadap sumber daya, Anda akan kehilangan akses ke konfigurasi sumber daya tersebut dan datanya. Deprovisi tidak dapat dibatalkan. Jangan lanjutkan sampai Anda dapat mengonfirmasi bahwa:

Migrasi Anda telah selesai.
Tidak ada dependensi apa pun pada file, folder, atau cadangan volume StorSimple yang akan dibatalkan.

Sebelum memulai, praktik terbaiknya adalah mengamati penyebaran Azure File Sync baru Anda yang sedang diproduksi untuk sementara. Waktu itu memberi Anda kesempatan untuk memperbaiki masalah yang mungkin ditemui. Setelah Anda mengamati penerapan Azure Fi;e Sync setidaknya selama beberapa hari, Anda bisa mulai melakukan deprovisi sumber daya menggunakan urutan ini:

Deprovisi sumber daya Manajer Data StorSimple Anda melalui portal Microsoft Azure. Semua pekerjaan DTS Anda akan dihapus melalui hal tersebut. Anda tidak akan dapat mengambil log salinan dengan mudah. Jika penting untuk catatan Anda, ambil catatan tersebut sebelum Anda melakukan deprovisi.
Pastikan bahwa appliance fisik StorSimple Anda telah dimigrasikan, dan kemudian hapus pendaftarannya. Jika Anda tidak sepenuhnya yakin apakah mereka telah dimigrasikan, jangan lanjutkan proses. Jika Anda melakukan deprovisi sumber daya saat masih diperlukan, Anda tidak akan dapat memulihkan data atau konfigurasinya.
Secara opsional, Anda dapat terlebih dahulu melakukan deprovisi sumber daya volume StorSimple, yang akan membersihkan data pada appliance. Proses ini dapat memakan waktu beberapa hari dan tidak akan secara forensik nol data pada appliance. Jika hal ini penting bagi Anda, tangani disk zeroing secara terpisah dari proses deprovisi sumber daya sesuai dengan kebijakan Anda.
Jika tidak ada lagi perangkat terdaftar yang tersisa di StorSimple Device Manager, Anda dapat menghapus sumber daya Device Manager itu sendiri.
Sekarang saatnya menghapus akun penyimpanan StorSimple di Azure. Sekali lagi, hentikan dan konfirmasi bahwa migrasi Anda telah selesai dan tidak ada yang bergantung pada data ini sebelum Anda melanjutkan.
Cabut appliance StorSimple dari pusat data Anda secara fisik.
Jika Anda memiliki appliance StorSimple, Anda dapat untuk Mendaur Ulang PC. Jika perangkat Anda disewakan, informasikan kepada penyewa dan kembalikan perangkat sebagaimana mestinya.

Migrasi Anda telah selesai.

Catatan

Masih ada pertanyaan atau mengalami masalah?
Kami di sini untuk membantu: Alamat email dalam satu kata: Migrasi Azure Files di microsoft dot com

Pemecahan Masalah

Saat menggunakan layanan migrasi StorSimple Data Manager, seluruh pekerjaan migrasi atau file individual mungkin gagal dikarenakan berbagai alasan. Bagian keakuratan file memiliki detail lebih lanjut mengenai skenario yang didukung/tidak didukung. Tabel berikut ini mencantumkan kode kesalahan, detail kesalahan, dan jika memungkinkan, opsi mitigasi.

Kesalahan pada tingkat pekerjaan

Fase	Kesalahan	Detail/Mitigasi
Cadangan	Tidak bisa menemukan cadangan untuk parameter yang ditentukan	Cadangan yang dipilih untuk eksekusi pekerjaan tidak ditemukan saat melakukan "Estimasi" atau "Salin". Pastikan cadangan masih ada pada katalog cadangan StorSimple. Terkadang kebijakan retensi cadangan otomatis menghapus cadangan antara memilihnya untuk migrasi serta benar-benar menjalankan pekerjaan migrasi untuk cadangan ini. Pertimbangkan untuk menonaktifkan semua jadwal retensi cadangan sebelum memulai migrasi.
Estimasi Konfigurasi komputasi	Penginstalan kunci enkripsi telah gagal	Kunci Enkripsi Data Layanan Anda salah. Tinjau bagian kunci enkripsi pada artikel ini untuk detail selengkapnya dan bantu mengambil kunci yang benar.
	Kesalahan pada batch	Ada kemungkinan bahwa memulai semua infrastruktur internal yang diperlukan untuk melakukan migrasi mengalami masalah. Beberapa layanan lain terlibat di dalam proses ini. Masalah ini pada umumnya akan selesai dengan sendirinya ketika Anda mencoba menjalankan pekerjaan lagi.
	StorSimple Manager mengalami sebuah kesalahan internal. Tunggu beberapa menit lalu coba operasikan lagi. Jika masalah berlanjut, hubungi Dukungan Microsoft. (Kode galat: 1074161829)	Kesalahan generik ini memiliki beberapa penyebab, namun salah satu kemungkinannya adalah bahwa manajer perangkat StorSimple mencapai batas 50 appliance. Periksa apakah pekerjaan yang terakhir dijalankan di manajer perangkat tiba-tiba mulai gagal dengan kesalahan ini, yang akan menunjukkan bahwa hal tersebut adalah masalahnya. Mitigasinya adalah dengan cara menghapus appliance StorSimple 8001 offline yang dibuat dan digunakan oleh Layanan Data Manager. Anda bisa mengajukan tiket dukungan atau menghapusnya secara manual di portal. Pastikan untuk menghapus hanya appliance seri 8001 offline.
Mengestimasikan File	Pekerjaan volume kloning gagal	Kesalahan ini kemungkinan besar menandakan bahwa Anda menentukan cadangan yang entah rusak. Layanan migrasi tidak bisa memasang atau membacanya. Anda bisa mencoba cadangan secara manual atau membuka tiket dukungan.
	Tidak bisa melanjutkan karena volume dalam format non-NTFS	Hanya volume NTFS, non-dedupe yang diaktifkan dan dapat digunakan oleh layanan migrasi. Jika Anda memiliki volume yang diformat secara berbeda seperti ReFS atau format pihak ketiga, layanan migrasi tidak akan dapat memigrasikan volume ini. Harap lihat bagian batasan platform.
	Hubungi dukungan. Tidak ada partisi yang cocok pada disk	Disk StorSimple yang seharusnya memiliki volume yang ditentukan bagi migrasi tampaknya tidak memiliki partisi untuk volume tersebut. Hal itu tidak umum dan mungkin menandakan kerusakan atau kesalahan penyelarasan manajemen. Satu-satunya opsi untuk menyelidiki masalah ini lebih lanjut adalah mengajukan tiket dukungan.
	Timed out	Fase estimasi yang gagal dengan batas waktu biasanya merupakan masalah dengan appliance StorSimple, atau Microsoft Azure Backup Volume sumber menjadi lambat dan kadang-kadang bahkan rusak. Jika menjalankan kembali cadangan tidak berfungsi, Anda dapat mencoba mengajukan tiket dukungan.
	Tidak dapat menemukan file <path> Tidak dapat menemukan bagian dari path	Definisi pekerjaan memungkinkan Anda menyediakan sub-jalur sumber. Kesalahan ini akan ditampilkan ketika jalur tersebut tidak ada. Sebagai contoh: \Share1 > \Share\Share1 Dalam contoh ini Anda telah menentukan \Share1 sebagai sub-jalur di sumber, pemetaan ke sub-jalur lain dalam target. Namun, jalur sumber tidak ada (apakah salah eja?). Catatan: Windows mempertahankan huruf besar-kecil tetapi tidak tergantung pada huruf besar-kecil. Artinya, \Share1 dan \share1 setara. Selain itu: Jalur target yang tidak ada akan dibuat secara otomatis.
	Permintaan ini tidak diizinkan untuk melakukan operasi ini	Kesalahan ini menunjukkan kapan akun penyimpanan StorSimple sumber atau akun penyimpanan target dengan berbagi file Azure yang mengaktifkan pengaturan firewall. Anda harus mengizinkan lalu lintas melalui titik akhir publik serta tidak membatasinya dengan aturan firewall lebih lanjut. Jika tidak, Layanan Transformasi Data tidak akan dapat mengakses salah satu akun penyimpanan bahkan jika Anda mengizinkannya. Nonaktifkan aturan firewall apa pun lalu jalankan kembali pekerjaan.
Menyalin File	Kesalahan: Akun yang sedang diakses belum mendukung http	Nonaktifkan perutean internet pada akun penyimpanan target atau gunakan titik akhir perutean Microsoft.
	Berbagi yang ditentukan telah penuh	Jika target adalah berbagi file Azure premium, pastikan Anda telah menyediakan kapasitas yang memadai untuk berbagi. Provisi sementara yang berlebih adalah praktik yang umum. Jika target merupakan berbagi file Azure standar, periksa apakah berbagi file target mengaktifkan fitur "berbagi file besar". Penyimpanan standar akan berkembang seiring penggunaan berbagi. Namun, jika Anda menggunakan akun penyimpanan lama sebagai target, Anda mungkin mengalami batas berbagi sebesar 5 TiB. Anda perlu mengaktifkan fitur "Berbagi file besar" secara manual. Perbaiki batasan pada target lalu jalankan kembali pekerjaan.

Kesalahan pada tingkat item

Selama fase penyalinan eksekusi pekerjaan migrasi, item namespace layanan individual (file dan folder) mungkin mengalami kesalahan. Tabel berikut mencantumkan kesalahan yang paling umum terjadi dan memberikan opsi mitigasi jika memungkinkan.

Fase	Kesalahan	Mitigasi
Salinan	-2146233088 Server sedang sibuk.	Jalankan ulang pekerjaan apabila ada terlalu banyak kegagalan. Jika hanya terdapat sangat sedikit kesalahan, Anda dapat mencoba menjalankan pekerjaan lagi, tetapi sering kali salinan manual item yang gagal bisa lebih cepat. Kemudian lanjutkan migrasi dengan melompat guna memproses cadangan berikutnya.
	-2146233088 Operasi tidak dapat diselesaikan dalam waktu yang ditentukan.	Jalankan ulang pekerjaan apabila ada terlalu banyak kegagalan. Jika hanya terdapat sangat sedikit kesalahan, Anda dapat mencoba menjalankan pekerjaan lagi, tetapi sering kali salinan manual item yang gagal bisa lebih cepat. Kemudian lanjutkan migrasi dengan melompat guna memproses cadangan berikutnya.
	Waktu unggahan habis ataupun salinan tidak dimulai	Jalankan ulang pekerjaan apabila ada terlalu banyak kegagalan. Jika hanya terdapat sangat sedikit kesalahan, Anda dapat mencoba menjalankan pekerjaan lagi, tetapi sering kali salinan manual item yang gagal bisa lebih cepat. Kemudian lanjutkan migrasi dengan melompat guna memproses cadangan berikutnya.
	-2146233029 Operasi dibatalkan.	Jalankan ulang pekerjaan apabila ada terlalu banyak kegagalan. Jika hanya terdapat sangat sedikit kesalahan, Anda dapat mencoba menjalankan pekerjaan lagi, tetapi sering kali salinan manual item yang gagal bisa lebih cepat. Kemudian lanjutkan migrasi dengan melompat guna memproses cadangan berikutnya.
	1920 File tidak dapat diakses oleh sistem.	Hal ini adalah kesalahan yang umum ketika mesin migrasi mengalami titik pemisahan ulang, tautan, atau persimpangan. Mereka tidak didukung. Jenis file ini tidak bisa disalin. Tinjau bagian Batasan yang diketahui serta bagian Keakuratan file pada artikel ini.
	-2147024891 Akses ditolak	Hal ini adalah kesalahan untuk file yang dienkripsi dengan cara yang tidak dapat diakses pada disk. File yang dapat dibaca dari disk namun hanya memiliki konten terenkripsi tidak terpengaruh dan dapat disalin. Satu-satunya opsi Anda adalah dengan cara menyalinnya secara manual. Anda bisa menemukan item tersebut dengan memasang volume yang terpengaruh dan menjalankan perintah berikut: `get-childitem <path> [-Recurse] -Force -ErrorAction SilentlyContinue \| Where-Object {$_.Attributes -ge "Encrypted"} \| format-list fullname, attributes`
	Ini bukan FileTime Win32 yang valid. Nama parameter: fileTime	Di dalam hal ini, file dapat diakses tetapi tidak dapat dievaluasi untuk disalin karena tanda waktu yang bergantung pada mesin migrasi rusak atau ditulis oleh aplikasi dalam format yang salah. Tidak banyak hal yang dapat Anda lakukan, karena Anda tidak dapat mengubah tanda waktu dalam cadangan. Jika file ini sangat penting, mungkin pada versi terbaru (cadangan terakhir yang berisi file ini) Anda dapat menyalin file secara manual, memperbaiki tanda waktu, lalu memindahkannya ke berbagi file Azure target. Opsi ini bukan cara penskalaan yang paling baik, tetapi merupakan opsi untuk file yang penting di mana Anda ingin memiliki setidaknya satu versi yang dipertahankan pada target.
	-2146232798 Handel aman telah ditutup	Sering kali merupakan kesalahan sementara. Jalankan ulang pekerjaan apabila ada terlalu banyak kegagalan. Jika hanya terdapat sangat sedikit kesalahan, Anda dapat mencoba menjalankan pekerjaan lagi, tetapi sering kali salinan manual item yang gagal bisa lebih cepat. Kemudian lanjutkan migrasi dengan melompat guna memproses cadangan berikutnya.
	-2147024413 Kesalahan perangkat keras perangkat fatal	Hal ini merupakan kesalahan yang langka dan sebenarnya tidak dilaporkan untuk perangkat fisik, melainkan appliance virtual seri 8001 yang digunakan oleh layanan migrasi. Appliance mengalami masalah. File yang memiliki kesalahan ini tidak akan menghentikan migrasi melanjutkan ke cadangan berikutnya. Hal ini menyulitkan Anda untuk melakukan salinan manual atau mencoba kembali cadangan yang berisi file dengan kesalahan ini. Jika file yang tertinggal sangat penting atau terdapat sejumlah besar file, Anda mungkin perlu memulai migrasi semua cadangan lagi. Harap buka tiket dukungan untuk penyelidikan lebih lanjut.
Hapus (Pembersihan cermin)	Direktori yang ditentukan tidak berada dalam keadaan kosong.	Kesalahan ini terjadi ketika mode migrasi diatur ke cermin lalu proses yang menghapus item dari berbagi file Azure mengalami masalah yang mencegahnya menghapus item. Penghapusan hanya terjadi pada berbagi langsung, bukan dari rekam jepret sebelumnya. Penghapusan diperlukan karena file yang terpengaruh tidak berada dalam cadangan saat ini dan dengan demikian, harus dihapus dari berbagi langsung sebelum rekam jepret berikutnya. Terdapat dua opsi: Opsi 1: pasang berbagi file Azure target dan hapus file dengan kesalahan ini secara manual. Opsi 2: Anda dapat mengabaikan kesalahan ini dan melanjutkan pemrosesan cadangan berikutnya dengan harapan bahwa target tidak identik dengan sumber dan memiliki beberapa item tambahan yang tidak ada di cadangan StorSimple asli.
	Permintaan buruk	Kesalahan ini menunjukkan bahwa file sumber memiliki karakteristik tertentu yang tidak dapat disalin ke berbagi file Azure. Terutama mungkin ada karakter kontrol yang tidak terlihat dalam nama file atau 1 byte karakter byte ganda di dalam nama file atau jalur file. Anda bisa menggunakan log salinan untuk mendapatkan nama jalur, menyalin file ke lokasi sementara, mengganti nama jalur untuk menghapus karakter yang tidak didukung, lalu lakukan robocopy lagi ke berbagi file Azure. Anda kemudian bisa melanjutkan migrasi dengan melompat ke cadangan berikutnya untuk diproses.

Langkah berikutnya

Pahami fleksibilitas kebijakan tingkat cloud.
Aktifkan Azure Backup pada berbagi file Azure Anda untuk menjadwalkan snapshot dan menentukan jadwal penyimpanan pencadangan.
Jika Anda melihat di portal Microsoft Azure bahwa beberapa file tidak disinkronkan secara permanen, tinjau Panduan Pemecahan Masalah untuk mendapatkan langkah-langkah mengatasi masalah ini.

Migrasi StorSimple 8100 dan 8600 ke Azure File Sync

Fase 1: Persiapan migrasi

Inventaris

Ringkasan biaya migrasi

Akses berbagi langsung vs. Azure File Sync

Kunci enkripsi data layanan StorSimple

Mengubah kunci enkripsi data layanan

Langkah 1: Gunakan skrip Windows PowerShell untuk Mengotorisasi perangkat untuk mengubah kunci enkripsi data layanan

Perangkat mana yang dapat diotorisasi untuk mengubah kunci enkripsi data layanan?

Langkah 2: Menggunakan Windows PowerShell untuk StorSimple guna menginisiasi perubahan kunci enkripsi data layanan

Untuk menginisiasi perubahan kunci enkripsi data layanan

Langkah 3: Memperbarui kunci enkripsi data layanan pada perangkat StorSimple lain

Untuk memperbarui kunci enkripsi data layanan di perangkat fisik

Untuk memperbarui kunci enkripsi data layanan di semua appliance cloud 8010/8020

Pembatasan yang diketahui

Keakuratan file

Cadangan volume StorSimple

Memetakan volume StorSimple Anda yang sudah ada ke berbagi file Azure

Berbagi pengelompokan

Sinkronisasi volume

Pendekatan terstruktur untuk peta penyebaran

Skenario dan pertimbangan sinkronisasi file umum

Membuat tabel pemetaan

Jumlah akun penyimpanan

Pengaturan akun penyimpanan

Ringkasan Fase 1

Fase 2: Menyebarkan sumber daya penyimpanan dan migrasi Azure

Menyebarkan akun penyimpanan

Langganan

Grup sumber daya

Nama akun penyimpanan

Lokasi

Performa

Replikasi

Aktifkan berbagi file berkapasitas 100 TiB

Berbagi file Azure

Pengelola Data StorSimple

Azure File Sync

Ringkasan Fase 2

Fase 3: Membuat dan menjalankan pekerjaan migrasi

Sumber

Target

Pemetaan direktori

Memilih cadangan volume untuk migrasi

Pemetaan direktori

Elemen semantik

Contoh

Aturan semantik

Menjalankan pekerjaan migrasi

Kesalahan per item

Kelola pekerjaan migrasi

Menjalankan pekerjaan secara paralel

Ringkasan Fase 3

Fase 4: Mengakses berbagi file Azure Anda

Menyebarkan Azure File Sync

Menyebarkan sumber daya cloud Azure File Sync

Menyebarkan instans Windows Server lokal

Menyiapkan instans Windows Server untuk sinkronisasi file

Mengonfigurasi Azure File Sync pada instans Windows Server

Menyebarkan akses berbagi langsung

Ringkasan Fase 4

Fase 5: Pemindahan pengguna

Merencanakan waktu henti Anda

Menentukan kapan namespace Anda telah sepenuhnya disinkronkan ke server Anda

Portal Azure

Pemantau Peristiwa Windows Server

RoboCopy akhir

Memecahkan masalah dan melakukan pengoptimalan

Pertimbangan IOPS dan bandwidth

Kecepatan pemrosesan

Hindari pekerjaan yang tidak perlu

Windows Server 2022 dan RoboCopy LFSM

Cut-ver pengguna

Fase 6: Deprovisi

Pemecahan Masalah

Kesalahan pada tingkat pekerjaan

Kesalahan pada tingkat item

Langkah berikutnya

Sumber Daya Tambahan: