Memigrasikan data secara offline ke Azure File Sync dengan Azure Data Box
Artikel migrasi ini adalah salah satu dari beberapa yang berlaku untuk kata kunci Azure File Sync dan Azure Data Box. Periksa apakah artikel ini berlaku untuk skenario Anda:
- Sumber data: Windows Server 2012 R2 atau yang lebih baru tempat Azure File Sync akan diinstal dan mengarah ke set file asli.
- Rute migrasi: Windows Server 2012 R2 atau terbaru ⇒ Data Box ⇒ berbagi Azure ⇒ sinkronkan dengan lokasi file asli Windows Server
- File penembolokan lokal: Ya, tujuan akhirnya adalah penyebaran Azure File Sync yang menyinkronkan file dari tempatnya sekarang.
Menggunakan Azure Data Box adalah jalur yang layak untuk memindahkan data massal dari Windows Server lokal Anda untuk memisahkan berbagi file Azure, lalu secara opsional, tambahkan Azure File Sync di server sumber asli.
Ada berbagai jalur migrasi yang tersedia untuk Anda, tetapi penting untuk mengikuti yang benar:
- Data Anda berada di Windows Server 2012 R2 atau yang lebih baru dan Anda berencana untuk menginstal AFS ke server tersebut dan menyinkronkan lokasi aslinya. Dalam skenario ini, Anda tidak ingin mengunggah semua file dan menggunakan Data Box sebagai gantinya, lalu menggunakan sinkronisasi file untuk perubahan yang sedang berlangsung. Jika ini adalah skenario Anda, maka artikel ini menjelaskan jalur migrasi Anda.
- Anda memiliki data pada sumber di mana Anda tidak akan atau tidak dapat menginstal AFS. Misalnya NAS (Network Attached Storage) atau server lainnya. Anda lebih suka membuat server baru yang kosong dan menggunakan Azure File Sync di server itu. Jika itu adalah skenario Anda, maka ini bukan panduan migrasi yang tepat untuk Anda. Lebih baik lihat: Memigrasikan dari NAS melalui Data Box ke Azure File Sync atau temukan panduan terbaik untuk skenario Anda di halaman gambaran umum migrasi.
- Untuk semua skenario lainnya, periksa tabel panduan migrasi berbagi file Azure. Halaman gambaran umum ini memberikan titik awal yang baik untuk semua skenario migrasi.
Gambaran umum migrasi
Proses migrasi terdiri dari beberapa fase. Anda perlu:
- Menyebarkan akun penyimpanan dan berbagi file.
- Menyebarkan satu atau beberapa perangkat Azure Data Box untuk memindahkan data dari Windows Server 2012 R2 atau yang lebih baru.
- Mengonfigurasi Azure File Sync dengan pengunggahan otoritatif.
Bagian yang berikut menjelaskan fase dari proses migrasi secara terperinci.
Tip
Jika Anda kembali ke artikel ini, gunakan navigasi di sisi kanan layar untuk beralih ke fase migrasi tempat Anda sebelumnya.
Fase 1: Tentukan berapa banyak berbagi {i>file
Dengan panduan migrasi ini, Anda harus terus menggunakan penyimpanan terpasang langsung (DAS) lokal yang berisi file Anda. Data Box akan diumpankan dari lokasi tersebut dan Azure File Sync juga akan disiapkan di lokasi yang sama. NAS (Network Attached Storage) tidak berfungsi dengan jalur migrasi ini.
Anda dapat menentukan sinkronisasi dengan menyiapkan grup sinkronisasi Azure File Sync yang masing-masing menentukan tempat set file disinkronkan. Setiap grup sinkronisasi memiliki setidaknya satu lokasi server, yang disebut titik akhir server dan satu berbagi file Azure, yang disebut titik akhir cloud.
Anda dapat menyinkronkan sub jalur dari satu set file ke setiap berbagi file Azure miliknya sendiri. Untuk melakukannya, perlu penyiapan beberapa grup sinkronisasi untuk mencakup satu set file sepenuhnya. Bagian selanjutnya menjelaskan pilihan Anda. Jika Anda perlu merestrukturisasi data Anda, Anda harus melakukannya sebagai langkah pertama. Sebelum melanjutkan dengan panduan ini, pesan Data Box atau sinkronisasi penyiapan.
Perhatian
Sebelum Anda memulai migrasi, keinginan jangka panjang Anda sangat penting untuk struktur file dan folder Anda. Hindari restrukturisasi folder yang tidak perlu selama migrasi. Restrukturisasi akan mengurangi efek positif menggunakan Azure Data Box untuk transportasi file awal dan massal ke 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.
Berbagi pengelompokan
Misalnya, jika departemen sumber daya manusia (SDM) Anda memiliki 15 pembagian, Anda mungkin mempertimbangkan untuk menyimpan semua data SDM dalam satu berbagi file Azure. Menyimpan beberapa pembagian lokal dalam satu berbagi file Azure tidak mencegah Anda membuat 15 pembagian SMB biasa pada instans Windows Server lokal Anda. Ini hanya berarti bahwa Anda mengatur folder akar dari 15 pembagian ini sebagai subfolder di bawah folder umum. Anda kemudian menyinkronkan folder umum ini ke berbagi file Azure. Dengan begitu, hanya satu berbagi file Azure di cloud yang diperlukan untuk grup berbagi lokal ini.
Sinkronisasi volume
Azure File Sync mendukung sinkronisasi akar volume ke berbagi file Azure. Jika Anda menyinkronkan akar volume, semua subfolder dan file akan masuk ke berbagi file Azure yang sama.
Menyinkronkan akar volume tidak selalu merupakan opsi terbaik. Ada manfaat untuk menyinkronkan beberapa lokasi. Misalnya, melakukannya membantu menjaga jumlah item lebih rendah per lingkup sinkronisasi. Kami menguji berbagi file Azure dan Azure File Sync dengan 100 juta item (file dan folder) per berbagi. Tetapi praktik terbaik adalah mencoba mempertahankan angka di bawah 20 juta atau 30 juta dalam satu bagian. Menyiapkan Azure File Sync dengan jumlah item yang lebih rendah tidak hanya bermanfaat untuk sinkronisasi file. Jumlah item yang lebih rendah juga menguntungkan skenario seperti ini:
- Pemindaian awal konten cloud dapat diselesaikan lebih cepat, yang pada gilirannya mengurangi penantian hingga ruang nama muncul di server yang diaktifkan untuk Azure File Sync.
- Pemulihan sisi cloud dari snapshot berbagi file Azure akan lebih cepat.
- Pemulihan bencana server lokal dapat mempercepat secara signifikan.
- Perubahan yang dilakukan secara langsung di berbagi file Azure (di luar sinkronisasi) dapat dideteksi dan disinkronkan lebih cepat.
Tip
Jika Anda tidak tahu berapa banyak file dan folder yang Anda miliki, lihat alat TreeSize dari JAM Software GmbH.
Pendekatan terstruktur untuk peta penyebaran
Sebelum Anda menerapkan penyimpanan cloud di langkah selanjutnya, penting untuk membuat peta antara folder lokal dan berbagi file Azure. Pemetaan ini akan menginformasikan berapa banyak dan sumber daya grup sinkronisasi mana dari Azure File Sync yang akan Anda provisikan. Grup sinkronisasi mengikat berbagi file Azure dan folder di server Anda bersama-sama dan membuat koneksi sinkronisasi.
Untuk memutuskan berapa banyak berbagi file Azure yang Anda butuhkan, tinjau batasan dan praktik terbaik berikut. Melakukannya akan membantu Anda mengoptimalkan peta Anda.
Server tempat agen Azure File Sync dipasang dapat disinkronkan dengan hingga 30 berbagi file Azure.
Berbagi file Azure disebarkan di akun penyimpanan. Pengaturan itu menjadikan akun penyimpanan sebagai target skala untuk angka performa seperti IOPS dan throughput.
Perhatikan batasan IOPS akun penyimpanan saat menyebarkan berbagi file Azure. Idealnya, Anda harus memetakan berbagi file 1:1 dengan akun penyimpanan. Namun, ini mungkin tidak selalu dimungkinkan karena berbagai batasan dan pembatasan, baik dari organisasi Anda maupun dari Azure. Ketika tidak mungkin hanya memiliki satu berbagi file yang disebarkan dalam satu akun penyimpanan, pertimbangkan berbagi mana yang akan sangat aktif dan berbagi mana yang akan kurang aktif untuk memastikan bahwa berbagi file terpanas tidak dimasukkan ke akun penyimpanan yang sama bersama-sama.
Jika Anda berencana untuk mengangkat aplikasi ke Azure yang akan menggunakan berbagi file Azure secara asli, Anda mungkin memerlukan lebih banyak performa dari berbagi file Azure Anda. Jika jenis penggunaan ini adalah kemungkinan, bahkan di masa depan, yang terbaik adalah membuat satu berbagi file Azure standar di akun penyimpanannya sendiri.
Ada batas 250 akun penyimpanan per langganan per wilayah Azure.
Tip
Mengingat informasi ini, sering kali perlu untuk mengelompokkan beberapa folder tingkat atas pada volume Anda ke direktori akar umum baru. Anda kemudian menyinkronkan direktori akar baru ini, dan semua folder yang Anda kelompokkan ke dalamnya, ke satu berbagi file Azure. Teknik ini memungkinkan Anda untuk tetap berada dalam batas 30 sinkronisasi berbagi file Azure per server.
Pengelompokan di bawah akar umum ini tidak memengaruhi akses ke data Anda. ACL Anda tetap seperti mereka. Anda hanya perlu menyesuaikan jalur berbagi apa pun (seperti berbagi SMB atau NFS) yang mungkin Anda miliki di folder server lokal yang sekarang Anda ubah menjadi akar umum. Tidak ada perubahan lain.
Penting
Vektor skala terpenting untuk Azure File Sync adalah jumlah item (file dan folder) yang perlu disinkronkan. Untuk mengetahui detailnya, tinjau target skala Azure File Sync.
Ini adalah praktik terbaik untuk menjaga jumlah item per lingkup sinkronisasi tetap rendah. Itu adalah faktor penting untuk dipertimbangkan dalam pemetaan folder Anda ke berbagi file Azure. Azure File Sync diuji dengan 100 juta item (file dan folder) per berbagi. Tetapi sering kali yang terbaik adalah menjaga jumlah item di bawah 20 juta atau 30 juta dalam berbagi tunggal. Pisahkan namespace Anda menjadi beberapa pembagian jika Anda mulai melebihi angka-angka ini. Anda dapat terus mengelompokkan beberapa berbagi lokal ke dalam berbagi file Azure yang sama jika Anda tetap berada di bawah angka-angka ini. Praktik ini akan memberi Anda ruang untuk berkembang.
Ada kemungkinan bahwa, dalam situasi Anda, himpunan folder dapat secara logis menyinkronkan ke berbagi file Azure yang sama (dengan menggunakan pendekatan folder akar umum baru yang disebutkan sebelumnya). Tetapi mungkin masih lebih baik untuk mengelompokkan kembali folder sehingga mereka menyinkronkan ke dua alih-alih satu berbagi file Azure. Anda dapat menggunakan pendekatan ini untuk menjaga jumlah file dan folder per berbagi file seimbang di seluruh server. Anda juga dapat membagi berbagi dan menyinkronkan di server lokal lainnya, menambahkan kemampuan untuk menyinkronkan dengan 30 lebih banyak berbagi file Azure per server tambahan.
Skenario dan pertimbangan sinkronisasi file umum
#
Skenario sinkronisasi
Didukung
Pertimbangan (atau batasan)
Solusi (atau solusi)
1
Server file dengan beberapa disk/volume dan beberapa berbagi ke berbagi file Azure target yang sama (konsolidasi)
No
Berbagi file Azure target (titik akhir cloud) hanya mendukung sinkronisasi dengan satu grup sinkronisasi.
Grup sinkronisasi hanya mendukung satu titik akhir server per server terdaftar.
1) Mulailah dengan menyinkronkan satu disk (volume akarnya) untuk menargetkan berbagi file Azure. Dimulai dengan disk/volume terbesar akan membantu persyaratan penyimpanan lokal. Konfigurasikan tingkatan cloud untuk menjenjangkan semua data ke cloud, sehingga mengosongkan ruang pada disk server file. Pindahkan data dari volume/berbagi lain ke volume saat ini yang sedang disinkronkan. Lanjutkan langkah satu per satu hingga semua data dijenjangkan ke cloud/dimigrasikan.
2) Targetkan satu volume akar (disk) pada satu waktu. Gunakan tingkatan cloud untuk menjenjangkan semua data untuk menargetkan berbagi file Azure. Hapus titik akhir server dari grup sinkronisasi, buat ulang titik akhir dengan volume/disk akar berikutnya, sinkronkan, dan ulangi prosesnya. Catatan: Penginstalan ulang agen mungkin diperlukan.
3) Merekomendasikan penggunaan beberapa berbagi file Azure target (akun penyimpanan yang sama atau berbeda berdasarkan persyaratan performa)
2
Server file dengan volume tunggal dan beberapa berbagi ke berbagi file Azure target yang sama (konsolidasi)
Ya
Tidak dapat memiliki beberapa titik akhir server per sinkronisasi server terdaftar ke berbagi file Azure target yang sama (sama seperti di atas)
Sinkronkan akar volume yang menyimpan beberapa berbagi atau folder tingkat atas. Lihat Berbagi konsep pengelompokan dan Sinkronisasi volume untuk informasi selengkapnya.
3
Server file dengan beberapa berbagi dan/atau volume ke beberapa berbagi file Azure di bawah akun penyimpanan tunggal (pemetaan berbagi 1:1)
Ya
Satu instans Windows Server (atau kluster) dapat menyinkronkan hingga 30 berbagi file Azure.
Akun penyimpanan adalah target skala untuk performa. IOPS dan throughput dibagikan di seluruh berbagi file.
Simpan jumlah item per grup sinkronisasi dalam 100 juta item (file dan folder) per berbagi. Idealnya yang terbaik adalah tinggal di bawah 20 atau 30 juta per saham.
1) Gunakan beberapa grup sinkronisasi (jumlah grup sinkronisasi = jumlah berbagi file Azure untuk disinkronkan).
2) Hanya 30 berbagi yang dapat disinkronkan dalam skenario ini pada satu waktu. Jika Anda memiliki lebih dari 30 berbagi di server file tersebut, gunakan Konsep pengelompokan Berbagi dan Sinkronisasi volume untuk mengurangi jumlah folder tingkat akar atau atas di sumbernya.
3) Gunakan server File Sync tambahan lokal dan pisahkan/pindahkan data ke server ini untuk mengatasi batasan pada server Windows sumber.
4
Server file dengan beberapa berbagi dan/atau volume ke beberapa berbagi file Azure di bawah akun penyimpanan yang berbeda (pemetaan berbagi 1:1)
Ya
Satu instans Windows Server (atau kluster) dapat menyinkronkan hingga 30 berbagi file Azure (akun penyimpanan yang sama atau berbeda).
Simpan jumlah item per grup sinkronisasi dalam 100 juta item (file dan folder) per berbagi. Idealnya yang terbaik adalah tinggal di bawah 20 atau 30 juta per saham.
Pendekatan yang sama seperti di atas
5
Beberapa server file dengan satu (volume akar atau berbagi) ke berbagi file Azure target yang sama (konsolidasi)
No
Grup sinkronisasi tidak dapat menggunakan titik akhir cloud (berbagi file Azure) yang sudah dikonfigurasi di grup sinkronisasi lain.
Meskipun grup sinkronisasi dapat memiliki titik akhir server di server file yang berbeda, file tidak dapat berbeda.
Ikuti panduan dalam Skenario # 1 di atas dengan pertimbangan tambahan untuk menargetkan satu server file pada satu waktu.
Membuat tabel pemetaan
Gunakan informasi sebelumnya untuk menentukan berapa banyak berbagi file Azure yang Anda butuhkan dan bagian mana dari data Anda yang sudah ada akan berakhir saat berbagi file Azure.
Buat tabel yang merekam pemikiran Anda sehingga Anda bisa merujuknya saat Anda perlu. Tetap terorganisir penting karena dapat dengan mudah kehilangan detail rencana pemetaan Anda saat Anda menyediakan banyak sumber daya Azure sekaligus. Unduh file Excel berikut ini untuk digunakan sebagai templat untuk membantu membuat pemetaan Anda.
Unduh templat pemetaan namespace layanan.
Fase 2: Sebar sumber daya penyimpanan Azure
Dalam fase ini, perhatikan tabel pemetaan dari Fase 1 dan gunakan untuk menyediakan jumlah akun penyimpanan Azure yang tepat dan berbagi file di dalamnya.
Berbagi file Azure disimpan di cloud di akun penyimpanan Azure.
Tingkat pertimbangan performa lainnya berlaku di sini.
Jika Anda memiliki berbagi yang sangat aktif (berbagi yang digunakan oleh banyak pengguna dan/atau aplikasi), dua berbagi file Azure mungkin mencapai batas performa akun penyimpanan.
Praktik terbaiknya adalah menyebarkan akun penyimpanan dengan masing-masing satu berbagi file.
Anda dapat mengumpulkan beberapa berbagi file Azure ke akun penyimpanan yang sama jika Anda memiliki berbagi file arsip atau Anda mengharapkan aktivitas harian yang rendah di dalamnya.
Pertimbangan ini lebih berlaku untuk akses cloud langsung (melalui Azure VM) daripada Azure File Sync. Jika Anda berencana untuk hanya menggunakan Azure File Sync pada pembagian ini, beberapa dapat dikelompokkan ke dalam satu akun penyimpanan Azure.
Jika Anda telah membuat daftar berbagi, Anda harus memetakannya masing-masing ke akun penyimpanan yang akan digunakan.
Pada fase sebelumnya, Anda menentukan jumlah berbagi yang sesuai. Pada langkah ini, Anda memiliki pemetaan akun penyimpanan untuk berbagi file. Sekarang sebarkan jumlah akun penyimpanan Azure yang tepat dengan jumlah berbagi file Azure yang sesuai di dalamnya.
Pastikan wilayah setiap akun penyimpanan Anda sama dan cocok dengan wilayah sumber Storage Sync Service yang telah Anda sebarkan.
Perhatian
Jika Anda membuat berbagi file Azure yang memiliki batas 100 TiB, berbagi ini hanya dapat menggunakan opsi penyimpanan redundan lokal atau redundansi penyimpanan redundan zona. Pertimbangkan kebutuhan redundansi penyimpanan Anda sebelum menggunakan berbagi file 100 TiB.
Secara default, berbagi file Azure tetap dibuat dengan batas 5 TiB. Ikuti langkah-langkah di Membuat berbagi file Azure untuk membuat berbagi file besar.
Pertimbangan lain saat Anda menyebarkan akun penyimpanan adalah redundansi Azure Storage. Lihat Opsi redundansi Azure Storage.
Nama-nama sumber daya Anda juga penting. Misalnya, jika Anda mengelompokkan beberapa berbagi file untuk departemen SDM ke dalam akun penyimpanan Azure, Anda harus memberi nama akun penyimpanan dengan tepat. Demikian pula, saat menamai berbagi file Azure, Anda harus menggunakan nama yang mirip dengan yang digunakan untuk rekan lokalnya.
Fase 3: Tentukan berapa banyak appliance Azure Data Box yang Anda butuhkan
Mulailah langkah ini hanya setelah Anda menyelesaikan fase sebelumnya. Sumber daya penyimpanan Azure Anda (akun penyimpanan dan berbagi file) harus dibuat saat ini. Saat Anda memesan Data Box, Anda perlu menentukan akun penyimpanan tempat Data Box memindahkan data.
Pada fase ini, Anda perlu memetakan hasil rencana migrasi dari fase sebelumnya ke batasan opsi Data Box yang tersedia. Pertimbangan ini akan membantu Anda membuat rencana untuk opsi Data Box mana yang harus dipilih dan berapa banyak yang dibutuhkan untuk memindahkan berbagi NAS Anda ke berbagi file Azure.
Untuk menentukan berapa banyak perangkat dan jenis yang dibutuhkan, pertimbangkan batasan penting ini:
- Appliance Azure Data Box apa pun dapat memindahkan data hingga ke 10 akun penyimpanan.
- Setiap opsi Data Box hadir dengan kapasitasnya sendiri yang dapat digunakan. Lihat Opsi Data Box.
Lihat rencana migrasi Anda untuk menemukan jumlah akun penyimpanan yang Anda putuskan untuk dibuat dan melihat berbaginya masing-masing. Lalu lihat ukuran dari setiap berbagi ini di NAS Anda. Menggabungkan informasi ini akan memungkinkan Anda mengoptimalkan dan memutuskan appliance mana harus mengirim data ke akun penyimpanan mana. Dua perangkat Data Box dapat memindahkan file ke akun penyimpanan yang sama, tetapi jangan pecah konten dari satu berbagi file ke dua Data Box.
Opsi Data Box
Untuk migrasi standar, pilih satu atau kombinasi dari opsi Data Box berikut ini:
- Data Box Disk.
Microsoft akan mengirimi Anda satu atau lima disk SSD yang memiliki kapasitas masing-masing 8 TiB, untuk total maksimum 40 TiB. Kapasitas yang dapat digunakan berkurang sekitar 20 persen karena enkripsi dan overhead sistem file. Untuk informasi lebih lanjut, lihat Dokumentasi Data Box Disk.
- Data Box.
Opsi ini adalah yang paling umum. Microsoft akan mengirimkan appliance{i>
Dokumentasi Data Box.
- Data Box Heavy.
Opsi ini menampilkan appliance{i>
Dokumentasi Data Box Heavy.
Catatan
Data Box dan Data Box Heavy hanya menyalin data melalui SMB yang didukung. Menyalin data melalui layanan salinan data tidak didukung karena tidak mempertahankan fidelitas file.
Fase 4: Salin file ke Data Box Anda
Saat Data Box tiba, Anda perlu menyiapkannya dengan konektivitas jaringan tak terbatas ke appliance NAS Anda. Ikuti dokumentasi penyiapan untuk jenis Data Box yang Anda pesan:
Alat salin Data Box mungkin tersedia tergantung pada jenis Data Box. Pada titik ini, kami tidak menyarankan alat itu untuk migrasi ke berbagi file Azure karena ia tidak menyalin file Anda ke Data Box dengan keakuratan penuh. Alih-alih, gunakan Robocopy.
Ketika Data Box Anda tiba, ia akan memiliki berbagi SMB yang telah disediakan sebelumnya untuk setiap akun penyimpanan yang Anda tentukan saat Anda memesannya.
- Jika file Anda pergi ke berbagi file Azure premium, akan ada satu berbagi SMB per akun penyimpanan “File storage” premium.
- Jika file Anda pergi ke akun penyimpanan standar, akan ada tiga berbagi SMB per akun penyimpanan standar (GPv1 dan GPv2). Hanya berbagi file yang berakhiran dengan
_AzFiles yang relevan untuk migrasi Anda. Abaikan segala berbagi blok dan blob halaman.
Ikuti langkah-langkah dalam dokumentasi Azure Data Box:
- Sambungkan ke Data Box.
- Salin data ke Data Box.
- Siapkan Data Box Anda untuk pengunggahan ke Azure.
Dokumentasi Data Box yang ditautkan menentukan perintah Robocopy. Perintah itu tidak cocok untuk mempertahankan keakuratan penuh file dan folder. Alih-alih, gunakan perintah ini:
robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
Mengalihkan
Makna
/MT:nMemungkinkan Robocopy untuk menjalankan multiutas. Default untuk n adalah 8. Maksimum adalah 128 utas. Sementara jumlah utas yang tinggi membantu memenuhi bandwidth yang tersedia, itu tidak berarti migrasi Anda akan selalu lebih cepat dengan lebih banyak utas. Pengujian dengan Azure Files menunjukkan antara 8 dan 20 memperlihatkan kinerja yang seimbang untuk menjalankan salinan awal. Proses /MIR berikutnya secara progresif dipengaruhi oleh komputasi yang tersedia vs bandwidth jaringan yang tersedia. Untuk proses selanjutnya, cocokkan nilai jumlah utas Anda lebih dekat dengan jumlah inti prosesor dan jumlah utas per inti Anda. Pertimbangkan apakah core perlu dicadangkan untuk tugas lain yang mungkin dilakukan oleh server produksi. Pengujian dengan Azure Files telah menunjukkan bahwa hingga 64 utas menghasilkan performa yang baik, tetapi hanya jika prosesor Anda dapat membuatnya tetap hidup pada saat yang sama.
/R:nJumlah coba lagi maksimum untuk file yang gagal disalin pada upaya pertama. Robocopy akan mencoba n waktu sebelum file secara permanen gagal menjalankan salinan. Anda dapat mengoptimalkan kinerja yang Anda jalankan: Pilih nilai dua atau tiga jika Anda yakin masalah batas waktu menyebabkan kegagalan di masa lalu. Ini mungkin lebih umum melalui tautan WAN. Pilih tidak mencoba ulang atau nilai satu jika Anda yakin file gagal menyalin karena sedang digunakan secara aktif. Mencoba lagi beberapa detik kemudian mungkin tidak cukup waktu untuk status file yang digunakan untuk berubah. Pengguna atau aplikasi yang menahan file terbuka mungkin memerlukan waktu beberapa jam lebih lama. Dalam hal ini, menerima file tidak disalin dan menangkapnya di salah satu rencana Anda, Robocopy berjalan berikutnya, mungkin akhirnya berhasil dalam menyalin file dengan sukses. Hal itu membantu eksekusi saat ini untuk menyelesaikan lebih cepat tanpa diperpanjang oleh banyak percobaan ulang yang akhirnya berakhir di sebagian besar kegagalan salinan karena file masih terbuka melewati batas waktu percobaan ulang.
/W:nMenentukan waktu tunggu Robocopy sebelum mencoba menyalin file yang tidak berhasil disalin selama upaya sebelumnya. n adalah jumlah detik untuk menunggu di antara coba lagi. /W:n sering digunakan bersama dengan /R:n.
/BMenjalankan Robocopy dalam mode yang sama dengan yang akan digunakan aplikasi cadangan. Pengalih ini memungkinkan Robocopy memindahkan file yang izinnya tidak dimiliki pengguna saat ini. Sakelar cadangan bergantung pada menjalankan perintah Robocopy di konsol tinggi administrator atau jendela PowerShell. Jika Anda menggunakan Robocopy untuk Azure Files, pastikan Anda memasang berbagi file Azure menggunakan kunci akses akun penyimpanan vs. identitas domain. Jika tidak, pesan kesalahan mungkin tidak secara intuitif mengarahkan Anda ke resolusi masalah.
/MIR(Mencerminkan sumber ke target.) Memungkinkan Robocopy menyalin hanya delta antara sumber serta target. Subdirektori kosong akan disalin. Item (file atau folder) yang telah berubah atau tidak ada pada target akan disalin. Item yang ada pada target tetapi tidak pada sumber akan dihapus menyeluruh (dihapus) dari target. Saat Anda menggunakan pengalih ini, cocokkan struktur folder sumber dan target. Pencocokan berarti menyalin dari tingkat sumber dan folder yang benar ke tingkat folder yang cocok pada target. Hanya dengan begitu salinan "catch up" bisa berhasil. Saat sumber dan target tidak cocok, penggunaan /MIR akan menyebabkan penghapusan dan penyalinan ulang dalam skala besar.
/ITMemastikan fidelitas dipertahankan dalam skenario cermin tertentu.
Misalnya, jika file mengalami perubahan ACL dan pembaruan atribut di antara dua proses Robocopy, file tersebut akan ditandai sebagai tersembunyi. Tanpa /IT, perubahan ACL mungkin terlewatkan oleh Robocopy dan tidak ditransfer ke lokasi target.
/COPY:[copyflags]Fidelitas salinan file. Default: /COPY:DAT. Bendera salinan: D= Data, A= Atribut, T= Tanda waktu, S= Keamanan = ACL NTFS, O= Informasi pemilik, U= Informasi audit. Informasi audit tidak dapat disimpan dalam berbagi file Azure.
/DCOPY:[copyflags]Fidelitas untuk salinan direktori. Default: /DCOPY:DA. Bendera salinan: D= Data, A= Atribut, T= Tanda waktu.
/NPMenentukan bahwa perkembangan penyalinan untuk setiap file dan folder tidak akan ditampilkan. Menampilkan kemajuan secara signifikan menurunkan performa salinan.
/NFLMenentukan bahwa nama file tidak dicatat. Meningkatkan performa salinan.
/NDLMenentukan bahwa nama direktori tidak dicatat. Meningkatkan performa salinan.
/XDMenentukan direktori yang akan dikecualikan. Saat menjalankan Robocopy pada akar volume, pertimbangkan untuk mengecualikan System Volume Informationfolder tersembunyi. Jika digunakan seperti yang dirancang, semua informasi di sana spesifik untuk volume yang tepat pada sistem yang tepat ini dan dapat dibangun kembali sesuai permintaan. Menyalin informasi ini tidak akan membantu di cloud atau ketika data pernah disalin kembali ke volume Windows lain. Meninggalkan konten ini di belakang tidak dianggap kehilangan data.
/UNILOG:<file name>Menulis status ke file log sebagai Unicode. (Menimpa log yang ada.)
/LHanya untuk file uji coba
yang hanya akan dicantumkan. Mereka tidak akan disalin, tidak dihapus, dan tidak waktu dicap. Sering digunakan dengan /TEE untuk keluaran konsol. Bendera dari skrip sampel, seperti /NP, /NFL, dan /NDL, mungkin perlu dihapus untuk mendapatkan hasil pengujian yang terdokumentasi dengan baik.
/LFSMHanya untuk target dengan penyimpanan bertingkat. Tidak didukung ketika tujuan adalah berbagi SMB jarak jauh.
Menentukan bahwa Robocopy beroperasi dalam "mode ruang kosong rendah." Sakelar ini hanya berguna untuk target dengan penyimpanan berjenjang yang mungkin kehabisan kapasitas lokal sebelum Robocopy selesai. Ini ditambahkan khusus untuk digunakan dengan target yang diaktifkan untuk tingkatan cloud Azure File Sync. Ini dapat digunakan secara terpisah dari Azure File Sync. Dalam mode ini, Robocopy akan berhenti sejenak setiap kali salinan file akan menyebabkan ruang bebas volume tujuan berada di bawah nilai "lantai". Nilai ini dapat ditentukan oleh bentuk /LFSM:n bendera. Parameter n ditentukan dalam basis 2: nKB, nMB atau nGB. /LFSMJika ditentukan tanpa nilai lantai eksplisit, lantai diatur ke 10 persen dari ukuran volume tujuan. Mode ruang bebas rendah tidak kompatibel dengan /MT, /EFSRAW, atau /ZB. Dukungan untuk /B ditambahkan di Windows Server 2022. Silakan lihat bagian Windows Server 2022 dan RoboCopy LFSM di bawah ini untuk informasi selengkapnya, termasuk detail mengenai bug dan solusi terkait.
/ZGunakan salin file dengan hati-hati
dalam mode hidupkan ulang. Pengalih ini hanya disarankan dalam lingkungan jaringan yang tidak stabil. Ini secara signifikan mengurangi performa salinan karena pengelogan ekstra.
/ZBGunakan dengan hati-hati
Menggunakan mode hidupkan ulang. Jika akses ditolak, opsi ini menggunakan mode pencadangan. Opsi ini secara signifikan mengurangi performa salinan karena titik pemeriksaan.
Penting
Sebaiknya gunakan Windows Server 2022. Saat menggunakan Windows Server 2019, pastikan pada tingkat patch terbaru atau setidaknya pembaruan OS KB5005103 terpasang. Ini berisi perbaikan penting untuk skenario Robocopy tertentu.
Fase 5: Sebarkan sumber daya cloud Azure File Sync
Sebelum Anda melanjutkan dengan panduan ini, tunggu sampai semua {i>file file
Untuk menyelesaikan langkah ini, Anda memerlukan info masuk langganan Azure Anda.
Sumber daya inti yang akan dikonfigurasi untuk Sinkronisasi File Azure disebut Storage Sync Service. Disarankan agar Anda hanya menggunakan satu untuk semua server yang menyinkronkan kumpulan file yang sama sekarang atau di masa mendatang. Buat beberapa Storage Sync Service hanya jika Anda memiliki kumpulan server berbeda yang tidak boleh bertukar data. Misalnya, Anda mungkin memiliki server yang tidak boleh menyinkronkan berbagi file Azure yang sama. Jika tidak, menggunakan Storage Sync Service tunggal adalah praktik terbaik.
Pilih wilayah Azure untuk Storage Sync Service yang dekat dengan lokasi Anda. Semua sumber daya cloud lainnya harus disebarkan di wilayah yang sama. Untuk menyederhanakan manajemen, buat grup sumber daya baru di langganan Anda yang menampung sumber daya sinkronisasi dan penyimpanan.
Untuk informasi selengkapnya, lihat bagian tentang menyebarkan Storage Sync Service di artikel tentang menyebarkan Sinkronisasi File Azure. Ikuti hanya bagian artikel ini. Akan ada tautan ke bagian lain dari artikel di langkah-langkah selanjutnya.
Fase 6: Sebarkan agen Azure File Sync
Di bagian ini, Anda memasang agen Azure File Sync pada instans Windows Server Anda.
Panduan penyebaran menjelaskan bahwa Anda perlu menonaktifkan Konfigurasi Keamanan Tingkat Tinggi Internet Explorer. Langkah keamanan ini tidak berlaku untuk Azure File Sync. Menonaktifkannya memungkinkan Anda mengautentikasi ke Azure tanpa masalah.
Buka PowerShell. Pasang modul PowerShell yang diperlukan dengan menggunakan perintah berikut. Pastikan untuk memasang modul lengkap dan penyedia NuGet ketika Anda diminta untuk melakukannya.
Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync
Jika Anda memiliki masalah menjangkau internet dari server Anda, sekarang saatnya untuk menyelesaikannya. Azure File Sync menggunakan koneksi jaringan yang tersedia ke internet. Mengharuskan server proxy untuk menjangkau internet juga didukung. Anda dapat mengonfigurasi proksi di seluruh komputer sekarang atau, selama penginstalan agen, tentukan proksi yang hanya akan digunakan oleh Azure File Sync.
Jika mengonfigurasi proxy berarti Anda perlu membuka firewall untuk server, pendekatan tersebut mungkin dapat diterima oleh Anda. Di akhir penginstalan server, setelah Anda menyelesaikan pendaftaran server, laporan konektivitas jaringan akan menunjukkan titik akhir URL yang tepat di Azure yang perlu dikomunikasikan dengan Azure File Sync untuk wilayah yang Anda pilih. Laporan ini juga memberi tahu Anda mengapa komunikasi diperlukan. Anda dapat menggunakan laporan untuk mengunci firewall di sekitar server ke URL tertentu.
Anda juga dapat mengambil pendekatan yang lebih konservatif ketika Anda tidak membuka firewall lebar-lebar. Sebagai gantinya, Anda dapat membatasi server untuk berkomunikasi dengan ruang nama DNS tingkat lebih tinggi. Untuk informasi selengkapnya, lihat Proksi Azure File Sync dan pengaturan firewall. Ikuti praktik terbaik jaringan Anda sendiri.
Di akhir wisaya pemasangan wisaya server, wisaya pendaftaran server akan terbuka. Daftarkan server ke sumber daya Azure Storage Sync Service Anda dari yang lebih lama.
Langkah-langkah ini dijelaskan secara lebih rinci dalam panduan penyebaran, yang mencakup modul PowerShell yang harus Anda pasang terlebih dahulu: Pemasangan agen Azure File Sync.
Gunakan agen terbaru. Anda dapat mengunduhnya dari Pusat Unduhan Microsoft: Azure File Sync Agent.
Setelah penginstalan dan pendaftaran server berhasil, Anda dapat mengonfirmasi bahwa Anda telah berhasil menyelesaikan langkah ini. Buka sumber daya Storage Sync Service di portal Microsoft Azure. Di menu sebelah kiri, buka Server terdaftar. Anda akan melihat server Anda tercantum di sana.
Fase 7: Konfigurasikan Azure File Sync di Windows Server yang sudah ada
Instans Windows Server lokal Anda yang terdaftar harus siap dan terhubung ke internet untuk proses ini.
Langkah ini menyatukan semua sumber daya dan folder yang telah Anda siapkan di instans Windows Server Anda selama langkah sebelumnya.
- Masuk ke portal Azure.
- Temukan sumber daya Storage Sync Service Anda.
- Buat grup sinkronisasi baru dalam sumber daya Storage Sync Service untuk setiap berbagi file Azure. Di terminologi Sinkronisasi File Azure, berbagi file Azure akan menjadi titik akhir cloud di topologi sinkronisasi yang Anda jelaskan dengan pembuatan grup sinkronisasi. Saat Anda membuat grup sinkronisasi, beri nama yang familier sehingga Anda mengenali kumpulan file mana yang disinkronkan di sana. Pastikan Anda mereferensikan berbagi file Azure dengan nama yang cocok.
- Setelah Anda membuat grup sinkronisasi, baris untuk grup tersebut akan muncul dalam daftar grup sinkronisasi. Pilih nama (tautan) untuk menampilkan konten grup sinkronisasi. Anda akan melihat berbagi file Azure di Titik akhir Cloud.
- Temukan tombol Tambahkan Titik Akhir Server. Folder di server lokal yang telah Anda provisikan akan menjadi jalur untuk titik akhir server ini.
Setelah Anda berada di wizard Buat titik akhir server, gunakan kotak centang yang disediakan di bawah jalur folder. Buat pilihan ini hanya jika Anda telah memasukkan jalur yang mengarah ke struktur file dan folder yang sama seperti yang dapat ditemukan di berbagi file Azure (tempat Data Box memindahkan file dan folder dalam namespace ini).
Jika ada ketidakcocokan hierarki folder, maka itu akan muncul sebagai perbedaan yang tidak dapat diselesaikan secara otomatis. Hindari ketidakcocokan atau investasi apa pun dalam proses Data Box karena tidak akan menghasilkan keuntungan apa pun bagi Anda. Semua data akan dihapus dalam berbagi file Azure. Semua data perlu diunggah dari server lokal. Struktur direktori harus cocok untuk mendapatkan keuntungan dari migrasi massal dengan Azure Data Box dan pembaruan lancar dari berbagi cloud dengan perubahan terbaru dari server.
Catatan
Dengan mengaktifkan kotak centang, Anda dapat mengatur mode Sinkronisasi awal ke Secara otoritatif menimpa file dan folder di berbagi file Azure dengan konten di jalur server ini. Opsi ini hanya tersedia untuk titik akhir server pertama dalam grup sinkronisasi.
Setelah Anda mengonfigurasi pengunggahan otoritatif untuk titik akhir server baru ini, Anda dapat mengaktifkan tingkatan cloud secara opsional.
Tingkatan {i>cloud cloudnamespace
Pelajari lebih lanjut dengan melihat gambaran umum tingkatan cloud atau lihat lebih dekat berbagai kebijakan tingkatan cloud yang dapat Anda gunakan untuk menyempurnakan apa yang di-cache / bertingkat di server lokal.
Selesaikan migrasi Anda
Setelah Anda membuat titik akhir {i>server
Untuk semua berbagi file Azure / lokasi server yang perlu Anda konfigurasikan untuk sinkronisasi, ulangi langkah-langkah untuk membuat grup sinkronisasi dan menambahkan folder server yang cocok sebagai titik akhir server. Anda menggunakan Azure Data Box untuk memindahkan file Anda ke beberapa berbagi file Azure. Migrasi Anda selesai setelah Anda membuat semua titik akhir server yang menghubungkan data lokal Anda ke berbagi file Azure ini.
Langkah berikutnya
Masih banyak lagi yang dapat ditemukan tentang berbagi {i>file dokumentasi berbagi file Azure jika sesuai.
Dengan panduan migrasi ini, Anda harus terus menggunakan penyimpanan terpasang langsung (DAS) lokal yang berisi file Anda. Data Box akan diumpankan dari lokasi tersebut dan Azure File Sync juga akan disiapkan di lokasi yang sama. NAS (Network Attached Storage) tidak berfungsi dengan jalur migrasi ini.
Anda dapat menentukan sinkronisasi dengan menyiapkan grup sinkronisasi Azure File Sync yang masing-masing menentukan tempat set file disinkronkan. Setiap grup sinkronisasi memiliki setidaknya satu lokasi server, yang disebut titik akhir server dan satu berbagi file Azure, yang disebut titik akhir cloud.
Anda dapat menyinkronkan sub jalur dari satu set file ke setiap berbagi file Azure miliknya sendiri. Untuk melakukannya, perlu penyiapan beberapa grup sinkronisasi untuk mencakup satu set file sepenuhnya. Bagian selanjutnya menjelaskan pilihan Anda. Jika Anda perlu merestrukturisasi data Anda, Anda harus melakukannya sebagai langkah pertama. Sebelum melanjutkan dengan panduan ini, pesan Data Box atau sinkronisasi penyiapan.
Perhatian
Sebelum Anda memulai migrasi, keinginan jangka panjang Anda sangat penting untuk struktur file dan folder Anda. Hindari restrukturisasi folder yang tidak perlu selama migrasi. Restrukturisasi akan mengurangi efek positif menggunakan Azure Data Box untuk transportasi file awal dan massal ke 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.
Berbagi pengelompokan
Misalnya, jika departemen sumber daya manusia (SDM) Anda memiliki 15 pembagian, Anda mungkin mempertimbangkan untuk menyimpan semua data SDM dalam satu berbagi file Azure. Menyimpan beberapa pembagian lokal dalam satu berbagi file Azure tidak mencegah Anda membuat 15 pembagian SMB biasa pada instans Windows Server lokal Anda. Ini hanya berarti bahwa Anda mengatur folder akar dari 15 pembagian ini sebagai subfolder di bawah folder umum. Anda kemudian menyinkronkan folder umum ini ke berbagi file Azure. Dengan begitu, hanya satu berbagi file Azure di cloud yang diperlukan untuk grup berbagi lokal ini.
Sinkronisasi volume
Azure File Sync mendukung sinkronisasi akar volume ke berbagi file Azure. Jika Anda menyinkronkan akar volume, semua subfolder dan file akan masuk ke berbagi file Azure yang sama.
Menyinkronkan akar volume tidak selalu merupakan opsi terbaik. Ada manfaat untuk menyinkronkan beberapa lokasi. Misalnya, melakukannya membantu menjaga jumlah item lebih rendah per lingkup sinkronisasi. Kami menguji berbagi file Azure dan Azure File Sync dengan 100 juta item (file dan folder) per berbagi. Tetapi praktik terbaik adalah mencoba mempertahankan angka di bawah 20 juta atau 30 juta dalam satu bagian. Menyiapkan Azure File Sync dengan jumlah item yang lebih rendah tidak hanya bermanfaat untuk sinkronisasi file. Jumlah item yang lebih rendah juga menguntungkan skenario seperti ini:
- Pemindaian awal konten cloud dapat diselesaikan lebih cepat, yang pada gilirannya mengurangi penantian hingga ruang nama muncul di server yang diaktifkan untuk Azure File Sync.
- Pemulihan sisi cloud dari snapshot berbagi file Azure akan lebih cepat.
- Pemulihan bencana server lokal dapat mempercepat secara signifikan.
- Perubahan yang dilakukan secara langsung di berbagi file Azure (di luar sinkronisasi) dapat dideteksi dan disinkronkan lebih cepat.
Tip
Jika Anda tidak tahu berapa banyak file dan folder yang Anda miliki, lihat alat TreeSize dari JAM Software GmbH.
Pendekatan terstruktur untuk peta penyebaran
Sebelum Anda menerapkan penyimpanan cloud di langkah selanjutnya, penting untuk membuat peta antara folder lokal dan berbagi file Azure. Pemetaan ini akan menginformasikan berapa banyak dan sumber daya grup sinkronisasi mana dari Azure File Sync yang akan Anda provisikan. Grup sinkronisasi mengikat berbagi file Azure dan folder di server Anda bersama-sama dan membuat koneksi sinkronisasi.
Untuk memutuskan berapa banyak berbagi file Azure yang Anda butuhkan, tinjau batasan dan praktik terbaik berikut. Melakukannya akan membantu Anda mengoptimalkan peta Anda.
Server tempat agen Azure File Sync dipasang dapat disinkronkan dengan hingga 30 berbagi file Azure.
Berbagi file Azure disebarkan di akun penyimpanan. Pengaturan itu menjadikan akun penyimpanan sebagai target skala untuk angka performa seperti IOPS dan throughput.
Perhatikan batasan IOPS akun penyimpanan saat menyebarkan berbagi file Azure. Idealnya, Anda harus memetakan berbagi file 1:1 dengan akun penyimpanan. Namun, ini mungkin tidak selalu dimungkinkan karena berbagai batasan dan pembatasan, baik dari organisasi Anda maupun dari Azure. Ketika tidak mungkin hanya memiliki satu berbagi file yang disebarkan dalam satu akun penyimpanan, pertimbangkan berbagi mana yang akan sangat aktif dan berbagi mana yang akan kurang aktif untuk memastikan bahwa berbagi file terpanas tidak dimasukkan ke akun penyimpanan yang sama bersama-sama.
Jika Anda berencana untuk mengangkat aplikasi ke Azure yang akan menggunakan berbagi file Azure secara asli, Anda mungkin memerlukan lebih banyak performa dari berbagi file Azure Anda. Jika jenis penggunaan ini adalah kemungkinan, bahkan di masa depan, yang terbaik adalah membuat satu berbagi file Azure standar di akun penyimpanannya sendiri.
Ada batas 250 akun penyimpanan per langganan per wilayah Azure.
Tip
Mengingat informasi ini, sering kali perlu untuk mengelompokkan beberapa folder tingkat atas pada volume Anda ke direktori akar umum baru. Anda kemudian menyinkronkan direktori akar baru ini, dan semua folder yang Anda kelompokkan ke dalamnya, ke satu berbagi file Azure. Teknik ini memungkinkan Anda untuk tetap berada dalam batas 30 sinkronisasi berbagi file Azure per server.
Pengelompokan di bawah akar umum ini tidak memengaruhi akses ke data Anda. ACL Anda tetap seperti mereka. Anda hanya perlu menyesuaikan jalur berbagi apa pun (seperti berbagi SMB atau NFS) yang mungkin Anda miliki di folder server lokal yang sekarang Anda ubah menjadi akar umum. Tidak ada perubahan lain.
Penting
Vektor skala terpenting untuk Azure File Sync adalah jumlah item (file dan folder) yang perlu disinkronkan. Untuk mengetahui detailnya, tinjau target skala Azure File Sync.
Ini adalah praktik terbaik untuk menjaga jumlah item per lingkup sinkronisasi tetap rendah. Itu adalah faktor penting untuk dipertimbangkan dalam pemetaan folder Anda ke berbagi file Azure. Azure File Sync diuji dengan 100 juta item (file dan folder) per berbagi. Tetapi sering kali yang terbaik adalah menjaga jumlah item di bawah 20 juta atau 30 juta dalam berbagi tunggal. Pisahkan namespace Anda menjadi beberapa pembagian jika Anda mulai melebihi angka-angka ini. Anda dapat terus mengelompokkan beberapa berbagi lokal ke dalam berbagi file Azure yang sama jika Anda tetap berada di bawah angka-angka ini. Praktik ini akan memberi Anda ruang untuk berkembang.
Ada kemungkinan bahwa, dalam situasi Anda, himpunan folder dapat secara logis menyinkronkan ke berbagi file Azure yang sama (dengan menggunakan pendekatan folder akar umum baru yang disebutkan sebelumnya). Tetapi mungkin masih lebih baik untuk mengelompokkan kembali folder sehingga mereka menyinkronkan ke dua alih-alih satu berbagi file Azure. Anda dapat menggunakan pendekatan ini untuk menjaga jumlah file dan folder per berbagi file seimbang di seluruh server. Anda juga dapat membagi berbagi dan menyinkronkan di server lokal lainnya, menambahkan kemampuan untuk menyinkronkan dengan 30 lebih banyak berbagi file Azure per server tambahan.
Skenario dan pertimbangan sinkronisasi file umum
| # | Skenario sinkronisasi | Didukung | Pertimbangan (atau batasan) | Solusi (atau solusi) |
|---|---|---|---|---|
| 1 | Server file dengan beberapa disk/volume dan beberapa berbagi ke berbagi file Azure target yang sama (konsolidasi) | No | Berbagi file Azure target (titik akhir cloud) hanya mendukung sinkronisasi dengan satu grup sinkronisasi. Grup sinkronisasi hanya mendukung satu titik akhir server per server terdaftar. |
1) Mulailah dengan menyinkronkan satu disk (volume akarnya) untuk menargetkan berbagi file Azure. Dimulai dengan disk/volume terbesar akan membantu persyaratan penyimpanan lokal. Konfigurasikan tingkatan cloud untuk menjenjangkan semua data ke cloud, sehingga mengosongkan ruang pada disk server file. Pindahkan data dari volume/berbagi lain ke volume saat ini yang sedang disinkronkan. Lanjutkan langkah satu per satu hingga semua data dijenjangkan ke cloud/dimigrasikan. 2) Targetkan satu volume akar (disk) pada satu waktu. Gunakan tingkatan cloud untuk menjenjangkan semua data untuk menargetkan berbagi file Azure. Hapus titik akhir server dari grup sinkronisasi, buat ulang titik akhir dengan volume/disk akar berikutnya, sinkronkan, dan ulangi prosesnya. Catatan: Penginstalan ulang agen mungkin diperlukan. 3) Merekomendasikan penggunaan beberapa berbagi file Azure target (akun penyimpanan yang sama atau berbeda berdasarkan persyaratan performa) |
| 2 | Server file dengan volume tunggal dan beberapa berbagi ke berbagi file Azure target yang sama (konsolidasi) | Ya | Tidak dapat memiliki beberapa titik akhir server per sinkronisasi server terdaftar ke berbagi file Azure target yang sama (sama seperti di atas) | Sinkronkan akar volume yang menyimpan beberapa berbagi atau folder tingkat atas. Lihat Berbagi konsep pengelompokan dan Sinkronisasi volume untuk informasi selengkapnya. |
| 3 | Server file dengan beberapa berbagi dan/atau volume ke beberapa berbagi file Azure di bawah akun penyimpanan tunggal (pemetaan berbagi 1:1) | Ya | Satu instans Windows Server (atau kluster) dapat menyinkronkan hingga 30 berbagi file Azure. Akun penyimpanan adalah target skala untuk performa. IOPS dan throughput dibagikan di seluruh berbagi file. Simpan jumlah item per grup sinkronisasi dalam 100 juta item (file dan folder) per berbagi. Idealnya yang terbaik adalah tinggal di bawah 20 atau 30 juta per saham. |
1) Gunakan beberapa grup sinkronisasi (jumlah grup sinkronisasi = jumlah berbagi file Azure untuk disinkronkan). 2) Hanya 30 berbagi yang dapat disinkronkan dalam skenario ini pada satu waktu. Jika Anda memiliki lebih dari 30 berbagi di server file tersebut, gunakan Konsep pengelompokan Berbagi dan Sinkronisasi volume untuk mengurangi jumlah folder tingkat akar atau atas di sumbernya. 3) Gunakan server File Sync tambahan lokal dan pisahkan/pindahkan data ke server ini untuk mengatasi batasan pada server Windows sumber. |
| 4 | Server file dengan beberapa berbagi dan/atau volume ke beberapa berbagi file Azure di bawah akun penyimpanan yang berbeda (pemetaan berbagi 1:1) | Ya | Satu instans Windows Server (atau kluster) dapat menyinkronkan hingga 30 berbagi file Azure (akun penyimpanan yang sama atau berbeda). Simpan jumlah item per grup sinkronisasi dalam 100 juta item (file dan folder) per berbagi. Idealnya yang terbaik adalah tinggal di bawah 20 atau 30 juta per saham. |
Pendekatan yang sama seperti di atas |
| 5 | Beberapa server file dengan satu (volume akar atau berbagi) ke berbagi file Azure target yang sama (konsolidasi) | No | Grup sinkronisasi tidak dapat menggunakan titik akhir cloud (berbagi file Azure) yang sudah dikonfigurasi di grup sinkronisasi lain. Meskipun grup sinkronisasi dapat memiliki titik akhir server di server file yang berbeda, file tidak dapat berbeda. |
Ikuti panduan dalam Skenario # 1 di atas dengan pertimbangan tambahan untuk menargetkan satu server file pada satu waktu. |
Membuat tabel pemetaan
Gunakan informasi sebelumnya untuk menentukan berapa banyak berbagi file Azure yang Anda butuhkan dan bagian mana dari data Anda yang sudah ada akan berakhir saat berbagi file Azure.
Buat tabel yang merekam pemikiran Anda sehingga Anda bisa merujuknya saat Anda perlu. Tetap terorganisir penting karena dapat dengan mudah kehilangan detail rencana pemetaan Anda saat Anda menyediakan banyak sumber daya Azure sekaligus. Unduh file Excel berikut ini untuk digunakan sebagai templat untuk membantu membuat pemetaan Anda.
|
|
Unduh templat pemetaan namespace layanan. |
Fase 2: Sebar sumber daya penyimpanan Azure
Dalam fase ini, perhatikan tabel pemetaan dari Fase 1 dan gunakan untuk menyediakan jumlah akun penyimpanan Azure yang tepat dan berbagi file di dalamnya.
Berbagi file Azure disimpan di cloud di akun penyimpanan Azure. Tingkat pertimbangan performa lainnya berlaku di sini.
Jika Anda memiliki berbagi yang sangat aktif (berbagi yang digunakan oleh banyak pengguna dan/atau aplikasi), dua berbagi file Azure mungkin mencapai batas performa akun penyimpanan.
Praktik terbaiknya adalah menyebarkan akun penyimpanan dengan masing-masing satu berbagi file. Anda dapat mengumpulkan beberapa berbagi file Azure ke akun penyimpanan yang sama jika Anda memiliki berbagi file arsip atau Anda mengharapkan aktivitas harian yang rendah di dalamnya.
Pertimbangan ini lebih berlaku untuk akses cloud langsung (melalui Azure VM) daripada Azure File Sync. Jika Anda berencana untuk hanya menggunakan Azure File Sync pada pembagian ini, beberapa dapat dikelompokkan ke dalam satu akun penyimpanan Azure.
Jika Anda telah membuat daftar berbagi, Anda harus memetakannya masing-masing ke akun penyimpanan yang akan digunakan.
Pada fase sebelumnya, Anda menentukan jumlah berbagi yang sesuai. Pada langkah ini, Anda memiliki pemetaan akun penyimpanan untuk berbagi file. Sekarang sebarkan jumlah akun penyimpanan Azure yang tepat dengan jumlah berbagi file Azure yang sesuai di dalamnya.
Pastikan wilayah setiap akun penyimpanan Anda sama dan cocok dengan wilayah sumber Storage Sync Service yang telah Anda sebarkan.
Perhatian
Jika Anda membuat berbagi file Azure yang memiliki batas 100 TiB, berbagi ini hanya dapat menggunakan opsi penyimpanan redundan lokal atau redundansi penyimpanan redundan zona. Pertimbangkan kebutuhan redundansi penyimpanan Anda sebelum menggunakan berbagi file 100 TiB.
Secara default, berbagi file Azure tetap dibuat dengan batas 5 TiB. Ikuti langkah-langkah di Membuat berbagi file Azure untuk membuat berbagi file besar.
Pertimbangan lain saat Anda menyebarkan akun penyimpanan adalah redundansi Azure Storage. Lihat Opsi redundansi Azure Storage.
Nama-nama sumber daya Anda juga penting. Misalnya, jika Anda mengelompokkan beberapa berbagi file untuk departemen SDM ke dalam akun penyimpanan Azure, Anda harus memberi nama akun penyimpanan dengan tepat. Demikian pula, saat menamai berbagi file Azure, Anda harus menggunakan nama yang mirip dengan yang digunakan untuk rekan lokalnya.
Fase 3: Tentukan berapa banyak appliance Azure Data Box yang Anda butuhkan
Mulailah langkah ini hanya setelah Anda menyelesaikan fase sebelumnya. Sumber daya penyimpanan Azure Anda (akun penyimpanan dan berbagi file) harus dibuat saat ini. Saat Anda memesan Data Box, Anda perlu menentukan akun penyimpanan tempat Data Box memindahkan data.
Pada fase ini, Anda perlu memetakan hasil rencana migrasi dari fase sebelumnya ke batasan opsi Data Box yang tersedia. Pertimbangan ini akan membantu Anda membuat rencana untuk opsi Data Box mana yang harus dipilih dan berapa banyak yang dibutuhkan untuk memindahkan berbagi NAS Anda ke berbagi file Azure.
Untuk menentukan berapa banyak perangkat dan jenis yang dibutuhkan, pertimbangkan batasan penting ini:
- Appliance Azure Data Box apa pun dapat memindahkan data hingga ke 10 akun penyimpanan.
- Setiap opsi Data Box hadir dengan kapasitasnya sendiri yang dapat digunakan. Lihat Opsi Data Box.
Lihat rencana migrasi Anda untuk menemukan jumlah akun penyimpanan yang Anda putuskan untuk dibuat dan melihat berbaginya masing-masing. Lalu lihat ukuran dari setiap berbagi ini di NAS Anda. Menggabungkan informasi ini akan memungkinkan Anda mengoptimalkan dan memutuskan appliance mana harus mengirim data ke akun penyimpanan mana. Dua perangkat Data Box dapat memindahkan file ke akun penyimpanan yang sama, tetapi jangan pecah konten dari satu berbagi file ke dua Data Box.
Opsi Data Box
Untuk migrasi standar, pilih satu atau kombinasi dari opsi Data Box berikut ini:
- Data Box Disk. Microsoft akan mengirimi Anda satu atau lima disk SSD yang memiliki kapasitas masing-masing 8 TiB, untuk total maksimum 40 TiB. Kapasitas yang dapat digunakan berkurang sekitar 20 persen karena enkripsi dan overhead sistem file. Untuk informasi lebih lanjut, lihat Dokumentasi Data Box Disk.
- Data Box.
Opsi ini adalah yang paling umum. Microsoft akan mengirimkan appliance{i>
- Data Box Heavy.
Opsi ini menampilkan appliance{i>
Catatan
Data Box dan Data Box Heavy hanya menyalin data melalui SMB yang didukung. Menyalin data melalui layanan salinan data tidak didukung karena tidak mempertahankan fidelitas file.
Fase 4: Salin file ke Data Box Anda
Saat Data Box tiba, Anda perlu menyiapkannya dengan konektivitas jaringan tak terbatas ke appliance NAS Anda. Ikuti dokumentasi penyiapan untuk jenis Data Box yang Anda pesan:
Alat salin Data Box mungkin tersedia tergantung pada jenis Data Box. Pada titik ini, kami tidak menyarankan alat itu untuk migrasi ke berbagi file Azure karena ia tidak menyalin file Anda ke Data Box dengan keakuratan penuh. Alih-alih, gunakan Robocopy.
Ketika Data Box Anda tiba, ia akan memiliki berbagi SMB yang telah disediakan sebelumnya untuk setiap akun penyimpanan yang Anda tentukan saat Anda memesannya.
- Jika file Anda pergi ke berbagi file Azure premium, akan ada satu berbagi SMB per akun penyimpanan “File storage” premium.
- Jika file Anda pergi ke akun penyimpanan standar, akan ada tiga berbagi SMB per akun penyimpanan standar (GPv1 dan GPv2). Hanya berbagi file yang berakhiran dengan
_AzFilesyang relevan untuk migrasi Anda. Abaikan segala berbagi blok dan blob halaman.
Ikuti langkah-langkah dalam dokumentasi Azure Data Box:
- Sambungkan ke Data Box.
- Salin data ke Data Box.
- Siapkan Data Box Anda untuk pengunggahan ke Azure.
Dokumentasi Data Box yang ditautkan menentukan perintah Robocopy. Perintah itu tidak cocok untuk mempertahankan keakuratan penuh file dan folder. Alih-alih, gunakan perintah ini:
robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
| Mengalihkan | Makna |
|---|---|
/MT:n |
Memungkinkan Robocopy untuk menjalankan multiutas. Default untuk n adalah 8. Maksimum adalah 128 utas. Sementara jumlah utas yang tinggi membantu memenuhi bandwidth yang tersedia, itu tidak berarti migrasi Anda akan selalu lebih cepat dengan lebih banyak utas. Pengujian dengan Azure Files menunjukkan antara 8 dan 20 memperlihatkan kinerja yang seimbang untuk menjalankan salinan awal. Proses /MIR berikutnya secara progresif dipengaruhi oleh komputasi yang tersedia vs bandwidth jaringan yang tersedia. Untuk proses selanjutnya, cocokkan nilai jumlah utas Anda lebih dekat dengan jumlah inti prosesor dan jumlah utas per inti Anda. Pertimbangkan apakah core perlu dicadangkan untuk tugas lain yang mungkin dilakukan oleh server produksi. Pengujian dengan Azure Files telah menunjukkan bahwa hingga 64 utas menghasilkan performa yang baik, tetapi hanya jika prosesor Anda dapat membuatnya tetap hidup pada saat yang sama. |
/R:n |
Jumlah coba lagi maksimum untuk file yang gagal disalin pada upaya pertama. Robocopy akan mencoba n waktu sebelum file secara permanen gagal menjalankan salinan. Anda dapat mengoptimalkan kinerja yang Anda jalankan: Pilih nilai dua atau tiga jika Anda yakin masalah batas waktu menyebabkan kegagalan di masa lalu. Ini mungkin lebih umum melalui tautan WAN. Pilih tidak mencoba ulang atau nilai satu jika Anda yakin file gagal menyalin karena sedang digunakan secara aktif. Mencoba lagi beberapa detik kemudian mungkin tidak cukup waktu untuk status file yang digunakan untuk berubah. Pengguna atau aplikasi yang menahan file terbuka mungkin memerlukan waktu beberapa jam lebih lama. Dalam hal ini, menerima file tidak disalin dan menangkapnya di salah satu rencana Anda, Robocopy berjalan berikutnya, mungkin akhirnya berhasil dalam menyalin file dengan sukses. Hal itu membantu eksekusi saat ini untuk menyelesaikan lebih cepat tanpa diperpanjang oleh banyak percobaan ulang yang akhirnya berakhir di sebagian besar kegagalan salinan karena file masih terbuka melewati batas waktu percobaan ulang. |
/W:n |
Menentukan waktu tunggu Robocopy sebelum mencoba menyalin file yang tidak berhasil disalin selama upaya sebelumnya. n adalah jumlah detik untuk menunggu di antara coba lagi. /W:n sering digunakan bersama dengan /R:n. |
/B |
Menjalankan Robocopy dalam mode yang sama dengan yang akan digunakan aplikasi cadangan. Pengalih ini memungkinkan Robocopy memindahkan file yang izinnya tidak dimiliki pengguna saat ini. Sakelar cadangan bergantung pada menjalankan perintah Robocopy di konsol tinggi administrator atau jendela PowerShell. Jika Anda menggunakan Robocopy untuk Azure Files, pastikan Anda memasang berbagi file Azure menggunakan kunci akses akun penyimpanan vs. identitas domain. Jika tidak, pesan kesalahan mungkin tidak secara intuitif mengarahkan Anda ke resolusi masalah. |
/MIR |
(Mencerminkan sumber ke target.) Memungkinkan Robocopy menyalin hanya delta antara sumber serta target. Subdirektori kosong akan disalin. Item (file atau folder) yang telah berubah atau tidak ada pada target akan disalin. Item yang ada pada target tetapi tidak pada sumber akan dihapus menyeluruh (dihapus) dari target. Saat Anda menggunakan pengalih ini, cocokkan struktur folder sumber dan target. Pencocokan berarti menyalin dari tingkat sumber dan folder yang benar ke tingkat folder yang cocok pada target. Hanya dengan begitu salinan "catch up" bisa berhasil. Saat sumber dan target tidak cocok, penggunaan /MIR akan menyebabkan penghapusan dan penyalinan ulang dalam skala besar. |
/IT |
Memastikan fidelitas dipertahankan dalam skenario cermin tertentu. Misalnya, jika file mengalami perubahan ACL dan pembaruan atribut di antara dua proses Robocopy, file tersebut akan ditandai sebagai tersembunyi. Tanpa /IT, perubahan ACL mungkin terlewatkan oleh Robocopy dan tidak ditransfer ke lokasi target. |
/COPY:[copyflags] |
Fidelitas salinan file. Default: /COPY:DAT. Bendera salinan: D= Data, A= Atribut, T= Tanda waktu, S= Keamanan = ACL NTFS, O= Informasi pemilik, U= Informasi audit. Informasi audit tidak dapat disimpan dalam berbagi file Azure. |
/DCOPY:[copyflags] |
Fidelitas untuk salinan direktori. Default: /DCOPY:DA. Bendera salinan: D= Data, A= Atribut, T= Tanda waktu. |
/NP |
Menentukan bahwa perkembangan penyalinan untuk setiap file dan folder tidak akan ditampilkan. Menampilkan kemajuan secara signifikan menurunkan performa salinan. |
/NFL |
Menentukan bahwa nama file tidak dicatat. Meningkatkan performa salinan. |
/NDL |
Menentukan bahwa nama direktori tidak dicatat. Meningkatkan performa salinan. |
/XD |
Menentukan direktori yang akan dikecualikan. Saat menjalankan Robocopy pada akar volume, pertimbangkan untuk mengecualikan System Volume Informationfolder tersembunyi. Jika digunakan seperti yang dirancang, semua informasi di sana spesifik untuk volume yang tepat pada sistem yang tepat ini dan dapat dibangun kembali sesuai permintaan. Menyalin informasi ini tidak akan membantu di cloud atau ketika data pernah disalin kembali ke volume Windows lain. Meninggalkan konten ini di belakang tidak dianggap kehilangan data. |
/UNILOG:<file name> |
Menulis status ke file log sebagai Unicode. (Menimpa log yang ada.) |
/L |
Hanya untuk file uji coba yang hanya akan dicantumkan. Mereka tidak akan disalin, tidak dihapus, dan tidak waktu dicap. Sering digunakan dengan /TEE untuk keluaran konsol. Bendera dari skrip sampel, seperti /NP, /NFL, dan /NDL, mungkin perlu dihapus untuk mendapatkan hasil pengujian yang terdokumentasi dengan baik. |
/LFSM |
Hanya untuk target dengan penyimpanan bertingkat. Tidak didukung ketika tujuan adalah berbagi SMB jarak jauh. Menentukan bahwa Robocopy beroperasi dalam "mode ruang kosong rendah." Sakelar ini hanya berguna untuk target dengan penyimpanan berjenjang yang mungkin kehabisan kapasitas lokal sebelum Robocopy selesai. Ini ditambahkan khusus untuk digunakan dengan target yang diaktifkan untuk tingkatan cloud Azure File Sync. Ini dapat digunakan secara terpisah dari Azure File Sync. Dalam mode ini, Robocopy akan berhenti sejenak setiap kali salinan file akan menyebabkan ruang bebas volume tujuan berada di bawah nilai "lantai". Nilai ini dapat ditentukan oleh bentuk /LFSM:n bendera. Parameter n ditentukan dalam basis 2: nKB, nMB atau nGB. /LFSMJika ditentukan tanpa nilai lantai eksplisit, lantai diatur ke 10 persen dari ukuran volume tujuan. Mode ruang bebas rendah tidak kompatibel dengan /MT, /EFSRAW, atau /ZB. Dukungan untuk /B ditambahkan di Windows Server 2022. Silakan lihat bagian Windows Server 2022 dan RoboCopy LFSM di bawah ini untuk informasi selengkapnya, termasuk detail mengenai bug dan solusi terkait. |
/Z |
Gunakan salin file dengan hati-hati dalam mode hidupkan ulang. Pengalih ini hanya disarankan dalam lingkungan jaringan yang tidak stabil. Ini secara signifikan mengurangi performa salinan karena pengelogan ekstra. |
/ZB |
Gunakan dengan hati-hati Menggunakan mode hidupkan ulang. Jika akses ditolak, opsi ini menggunakan mode pencadangan. Opsi ini secara signifikan mengurangi performa salinan karena titik pemeriksaan. |
Penting
Sebaiknya gunakan Windows Server 2022. Saat menggunakan Windows Server 2019, pastikan pada tingkat patch terbaru atau setidaknya pembaruan OS KB5005103 terpasang. Ini berisi perbaikan penting untuk skenario Robocopy tertentu.
Fase 5: Sebarkan sumber daya cloud Azure File Sync
Sebelum Anda melanjutkan dengan panduan ini, tunggu sampai semua {i>file
Untuk menyelesaikan langkah ini, Anda memerlukan info masuk langganan Azure Anda.
Sumber daya inti yang akan dikonfigurasi untuk Sinkronisasi File Azure disebut Storage Sync Service. Disarankan agar Anda hanya menggunakan satu untuk semua server yang menyinkronkan kumpulan file yang sama sekarang atau di masa mendatang. Buat beberapa Storage Sync Service hanya jika Anda memiliki kumpulan server berbeda yang tidak boleh bertukar data. Misalnya, Anda mungkin memiliki server yang tidak boleh menyinkronkan berbagi file Azure yang sama. Jika tidak, menggunakan Storage Sync Service tunggal adalah praktik terbaik.
Pilih wilayah Azure untuk Storage Sync Service yang dekat dengan lokasi Anda. Semua sumber daya cloud lainnya harus disebarkan di wilayah yang sama. Untuk menyederhanakan manajemen, buat grup sumber daya baru di langganan Anda yang menampung sumber daya sinkronisasi dan penyimpanan.
Untuk informasi selengkapnya, lihat bagian tentang menyebarkan Storage Sync Service di artikel tentang menyebarkan Sinkronisasi File Azure. Ikuti hanya bagian artikel ini. Akan ada tautan ke bagian lain dari artikel di langkah-langkah selanjutnya.
Fase 6: Sebarkan agen Azure File Sync
Di bagian ini, Anda memasang agen Azure File Sync pada instans Windows Server Anda.
Panduan penyebaran menjelaskan bahwa Anda perlu menonaktifkan Konfigurasi Keamanan Tingkat Tinggi Internet Explorer. Langkah keamanan ini tidak berlaku untuk Azure File Sync. Menonaktifkannya memungkinkan Anda mengautentikasi ke Azure tanpa masalah.
Buka PowerShell. Pasang modul PowerShell yang diperlukan dengan menggunakan perintah berikut. Pastikan untuk memasang modul lengkap dan penyedia NuGet ketika Anda diminta untuk melakukannya.
Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync
Jika Anda memiliki masalah menjangkau internet dari server Anda, sekarang saatnya untuk menyelesaikannya. Azure File Sync menggunakan koneksi jaringan yang tersedia ke internet. Mengharuskan server proxy untuk menjangkau internet juga didukung. Anda dapat mengonfigurasi proksi di seluruh komputer sekarang atau, selama penginstalan agen, tentukan proksi yang hanya akan digunakan oleh Azure File Sync.
Jika mengonfigurasi proxy berarti Anda perlu membuka firewall untuk server, pendekatan tersebut mungkin dapat diterima oleh Anda. Di akhir penginstalan server, setelah Anda menyelesaikan pendaftaran server, laporan konektivitas jaringan akan menunjukkan titik akhir URL yang tepat di Azure yang perlu dikomunikasikan dengan Azure File Sync untuk wilayah yang Anda pilih. Laporan ini juga memberi tahu Anda mengapa komunikasi diperlukan. Anda dapat menggunakan laporan untuk mengunci firewall di sekitar server ke URL tertentu.
Anda juga dapat mengambil pendekatan yang lebih konservatif ketika Anda tidak membuka firewall lebar-lebar. Sebagai gantinya, Anda dapat membatasi server untuk berkomunikasi dengan ruang nama DNS tingkat lebih tinggi. Untuk informasi selengkapnya, lihat Proksi Azure File Sync dan pengaturan firewall. Ikuti praktik terbaik jaringan Anda sendiri.
Di akhir wisaya pemasangan wisaya server, wisaya pendaftaran server akan terbuka. Daftarkan server ke sumber daya Azure Storage Sync Service Anda dari yang lebih lama.
Langkah-langkah ini dijelaskan secara lebih rinci dalam panduan penyebaran, yang mencakup modul PowerShell yang harus Anda pasang terlebih dahulu: Pemasangan agen Azure File Sync.
Gunakan agen terbaru. Anda dapat mengunduhnya dari Pusat Unduhan Microsoft: Azure File Sync Agent.
Setelah penginstalan dan pendaftaran server berhasil, Anda dapat mengonfirmasi bahwa Anda telah berhasil menyelesaikan langkah ini. Buka sumber daya Storage Sync Service di portal Microsoft Azure. Di menu sebelah kiri, buka Server terdaftar. Anda akan melihat server Anda tercantum di sana.
Fase 7: Konfigurasikan Azure File Sync di Windows Server yang sudah ada
Instans Windows Server lokal Anda yang terdaftar harus siap dan terhubung ke internet untuk proses ini.
Langkah ini menyatukan semua sumber daya dan folder yang telah Anda siapkan di instans Windows Server Anda selama langkah sebelumnya.
- Masuk ke portal Azure.
- Temukan sumber daya Storage Sync Service Anda.
- Buat grup sinkronisasi baru dalam sumber daya Storage Sync Service untuk setiap berbagi file Azure. Di terminologi Sinkronisasi File Azure, berbagi file Azure akan menjadi titik akhir cloud di topologi sinkronisasi yang Anda jelaskan dengan pembuatan grup sinkronisasi. Saat Anda membuat grup sinkronisasi, beri nama yang familier sehingga Anda mengenali kumpulan file mana yang disinkronkan di sana. Pastikan Anda mereferensikan berbagi file Azure dengan nama yang cocok.
- Setelah Anda membuat grup sinkronisasi, baris untuk grup tersebut akan muncul dalam daftar grup sinkronisasi. Pilih nama (tautan) untuk menampilkan konten grup sinkronisasi. Anda akan melihat berbagi file Azure di Titik akhir Cloud.
- Temukan tombol Tambahkan Titik Akhir Server. Folder di server lokal yang telah Anda provisikan akan menjadi jalur untuk titik akhir server ini.
Setelah Anda berada di wizard Buat titik akhir server, gunakan kotak centang yang disediakan di bawah jalur folder. Buat pilihan ini hanya jika Anda telah memasukkan jalur yang mengarah ke struktur file dan folder yang sama seperti yang dapat ditemukan di berbagi file Azure (tempat Data Box memindahkan file dan folder dalam namespace ini).
Jika ada ketidakcocokan hierarki folder, maka itu akan muncul sebagai perbedaan yang tidak dapat diselesaikan secara otomatis. Hindari ketidakcocokan atau investasi apa pun dalam proses Data Box karena tidak akan menghasilkan keuntungan apa pun bagi Anda. Semua data akan dihapus dalam berbagi file Azure. Semua data perlu diunggah dari server lokal. Struktur direktori harus cocok untuk mendapatkan keuntungan dari migrasi massal dengan Azure Data Box dan pembaruan lancar dari berbagi cloud dengan perubahan terbaru dari server.
Catatan
Dengan mengaktifkan kotak centang, Anda dapat mengatur mode Sinkronisasi awal ke Secara otoritatif menimpa file dan folder di berbagi file Azure dengan konten di jalur server ini. Opsi ini hanya tersedia untuk titik akhir server pertama dalam grup sinkronisasi.
Setelah Anda mengonfigurasi pengunggahan otoritatif untuk titik akhir server baru ini, Anda dapat mengaktifkan tingkatan cloud secara opsional.
Tingkatan {i>cloud
Pelajari lebih lanjut dengan melihat gambaran umum tingkatan cloud atau lihat lebih dekat berbagai kebijakan tingkatan cloud yang dapat Anda gunakan untuk menyempurnakan apa yang di-cache / bertingkat di server lokal.
Selesaikan migrasi Anda
Setelah Anda membuat titik akhir {i>server
Untuk semua berbagi file Azure / lokasi server yang perlu Anda konfigurasikan untuk sinkronisasi, ulangi langkah-langkah untuk membuat grup sinkronisasi dan menambahkan folder server yang cocok sebagai titik akhir server. Anda menggunakan Azure Data Box untuk memindahkan file Anda ke beberapa berbagi file Azure. Migrasi Anda selesai setelah Anda membuat semua titik akhir server yang menghubungkan data lokal Anda ke berbagi file Azure ini.
Langkah berikutnya
Masih banyak lagi yang dapat ditemukan tentang berbagi {i>file