Share via

Bermigrasi dari Linux ke penyebaran cloud hibrid dengan Azure File Sync

  • Artikel

Artikel migrasi ini adalah salah satu dari beberapa yang melibatkan kata kunci NFS dan Azure File Sync. Periksa apakah artikel ini berlaku untuk skenario Anda:

  • Sumber data: Network Attached Storage (NAS)
  • Rute migrasi: Server Linux dengan SAMBA ⇒ Windows Server 2012R2 atau versi lebih baru ⇒ sinkronkan dengan berbagi Azure
  • File penembolokan di lokasi: Ya, tujuan akhirnya adalah penyebaran Azure File Sync.

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

Azure File Sync berfungsi pada instans Windows Server dengan penyimpanan terpasang langsung (DAS). Ini tidak mendukung sinkronisasi ke dan dari klien Linux, atau berbagi Blok Pesan Server (SMB) jarak jauh, atau berbagi Sistem File Jaringan (NFS).

Akibatnya, mengubah layanan file Anda menjadi penyebaran hibrid membuat migrasi ke Windows Server diperlukan. Artikel ini memandu Anda melalui perencanaan dan pelaksanaan migrasi semacam itu.

Berlaku untuk

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

Tujuan migrasi

Tujuannya adalah untuk memindahkan berbagi yang Anda miliki di server Linux Samba Anda ke instans Windows Server. Kemudian gunakan Azure File Sync untuk penyebaran cloud hibrid. Migrasi ini harus dilakukan dengan cara yang menjamin integritas data produksi dan ketersediaan selama migrasi. Yang disebut belakangan mengharuskan menekan downtime seminimum mungkin sehingga dapat cocok atau sedikit melebihi jendela pemeliharaan reguler.

Gambaran umum migrasi

Seperti yang telah disebutkan dalam artikel gambaran umum migrasi Azure Files, Anda harus menggunakan alat dan pendekatan penyalinan yang benar. Server Linux Samba Anda mengekspos berbagi SMB langsung di jaringan lokal Anda. Robocopy yang diintegrasikan ke dalam Windows Server adalah cara terbaik untuk memindahkan file Anda dalam skenario migrasi ini.

Jika Anda tidak menjalankan Samba di server Linux dan ingin memigrasikan folder ke penyebaran hibrid di Windows Server, Anda dapat menggunakan alat penyalinan Linux alih-alih Robocopy. Waspadai kemampuan fidelitas alat penyalinan Anda. Tinjau bagian dasar-dasar migrasi di artikel gambaran umum migrasi untuk mempelajari apa yang harus di cari di alat penyalinan.

Fase 1: Mengidentifikasi berapa banyak berbagi file Azure yang dibutuhkan

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

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

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

Berbagi pengelompokan

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

Sinkronisasi volume

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

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

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

Tip

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

Pendekatan terstruktur untuk peta penyebaran

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

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

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

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

    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

Diagram yang menunjukkan contoh tabel pemetaan. Unduh file tersebut untuk menjalankan dan menggunakan konten gambar ini.

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

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


Ikon excel yang mengatur konteks unduhan. Unduh templat pemetaan namespace layanan.

Fase 2: Menyediakan instans Windows Server yang sesuai di lokasi

  • Buat instans Windows Server 2022 sebagai komputer virtual atau server fisik. Windows Server 2012 R2 adalah persyaratan minimum. Kluster failover Windows Server juga didukung.

  • Sediakan atau tambahkan penyimpanan terpasang langsung (DAS). Penyimpanan terlampir jaringan (NAS) tidak didukung.

    Jumlah penyimpanan yang Anda sediakan bisa lebih kecil dari yang Anda gunakan saat ini di server Linux Samba jika Anda menggunakan fitur cloud tiering Azure File Sync.

Jumlah penyimpanan yang Anda provisikan bisa lebih kecil dari yang saat ini Anda gunakan di server Linux Samba Anda. Pilihan konfigurasi ini mengharuskan Anda juga menggunakan fitur tingkatan cloud Azure File Sync. Namun, ketika Anda menyalin file dari ruang server Linux Samba yang lebih besar ke volume Windows Server yang lebih kecil di fase selanjutnya, Anda harus bekerja dalam kelompok:

  1. Memindahkan sekumpulan file yang sesuai ke dalam disk.
  2. Biarkan Sinkronisasi File dan tingkatan cloud terlibat.
  3. Ketika lebih banyak ruang kosong dibuat pada volume, lanjutkan dengan kumpulan file berikutnya. Atau tinjau perintah RoboCopy di bagian RoboCopy mendatang untuk penggunaan sakelar /LFSM baru. Menggunakan /LFSM dapat secara signifikan menyederhanakan pekerjaan RoboCopy Anda, tetapi tidak kompatibel dengan beberapa sakelar RoboCopy lainnya yang mungkin Anda andalkan.

Anda dapat menghindari pendekatan pengelompokan ini dengan menyediakan ruang yang setara pada instans Windows Server yang ditempati file Anda di server Linux Samba. Pertimbangkan untuk mengaktifkan deduplikasi di Windows. Jika Anda tidak ingin secara permanen melakukan penyimpanan dalam jumlah besar ini ke instans Windows Server, Anda dapat mengurangi ukuran volume setelah migrasi dan sebelum menyesuaikan kebijakan cloud tiering. Hal tersebut membuat cache lokal yang lebih kecil dari berbagi file Azure Anda.

Konfigurasi sumber daya (komputasi dan RAM) instans Windows Server yang Anda terapkan sebagian besar bergantung pada jumlah item (file dan folder) yang akan Anda sinkronkan. Sebaiknya Anda menyelaraskan dengan konfigurasi kinerja lebih tinggi jika Anda memiliki masalah apa pun.

Pelajari cara mengukur instans Windows Server berdasarkan jumlah item (file dan folder) yang perlu Anda sinkronkan.

Catatan

Artikel yang ditautkan sebelumnya menyajikan tabel dengan rentang untuk memori server (RAM). Anda dapat mengarahkan ke jumlah yang lebih kecil untuk server Anda, tetapi diperkirakan bahwa sinkronisasi awal dapat memakan waktu lebih lama secara signifikan.

Fase 3: Menyebarkan sumber daya cloud 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.

Fase 4: Menyebarkan 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 5: Menyebarkan 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 6: Mengonfigurasi Azure File Sync pada penyebaran Windows Server

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.

  1. Masuk ke portal Azure.
  2. Temukan sumber daya Storage Sync Service Anda.
  3. 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.
  4. 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.
  5. Temukan tombol Tambahkan Titik Akhir Server. Folder di server lokal yang telah Anda provisikan akan menjadi jalur untuk titik akhir server ini.

Penting

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 kinerja akses cepat. Cloud tiering adalah fitur opsional untuk setiap titik akhir server Azure File Sync.

Peringatan

Jika Anda menyediakan lebih sedikit penyimpanan pada volume Windows Server daripada data yang digunakan di server Linux Samba, maka cloud tiering adalah wajib. Jika Anda tidak mengaktifkan tingkatan cloud, server Anda tidak akan mengosongkan ruang untuk menyimpan semua file. Atur kebijakan tingkatan Anda, sementara untuk migrasi, ke ruang kosong 99 persen untuk volume. Pastikan untuk kembali ke pengaturan cloud tiering Anda setelah migrasi selesai dan atur kebijakan ke tingkat yang lebih berguna untuk jangka panjang.

Ulangi langkah pembuatan grup sinkronisasi dan penambahan folder server yang cocok sebagai titik akhir server untuk semua berbagi file Azure dan lokasi server yang perlu dikonfigurasi untuk sinkronisasi.

Setelah Anda membuat semua titik akhir server, sinkronisasi berfungsi. Anda dapat membuat file pengujian dan melihatnya disinkronkan dari lokasi server Anda ke berbagi file Azure yang terhubung (seperti yang dijelaskan oleh titik akhir cloud di grup sinkronisasi).

Kedua lokasi, folder server dan berbagi file Azure, sebaliknya kosong dan menunggu data. Pada langkah berikutnya, Anda akan mulai menyalin file ke instans Windows Server untuk Azure File Sync guna memindahkannya ke cloud. Jika Anda telah mengaktifkan cloud tiering, server kemudian akan mulai mengurutkan file jika Anda kehabisan kapasitas pada volume lokal.

Fase 7: Robocopy

Pendekatan migrasi dasar adalah menggunakan Robocopy untuk menyalin file dan menggunakan Azure File Sync untuk melakukan sinkronisasi.

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

  1. Identifikasi lokasi pertama di server Linux Samba Anda.
  2. Identifikasi folder yang cocok pada instans Windows Server yang sudah memiliki Azure File Sync yang dikonfigurasi di dalamnya.
  3. Mulai penyalinan menggunakan Robocopy.

Perintah Robocopy berikut akan menyalin file dari penyimpanan server Linux Samba ke folder target Windows Server Anda. Windows Server akan menyinkronkannya ke berbagi file Azure.

Jika Anda memprovisikan lebih sedikit penyimpanan pada instans Windows Server daripada yang diambil file Anda di server Linux Samba, maka Anda telah mengonfigurasi tingkatan cloud. Saat volume Windows Server lokal penuh, cloud tiering akan dimulai dan mengurutkan file yang telah berhasil disinkronkan. Cloud tiering akan menghasilkan ruang yang cukup untuk melanjutkan penyalinan dari server Linux Samba. Pemeriksaan cloud tiering satu jam sekali untuk melihat apa yang telah disinkronkan dan untuk mengosongkan ruang disk untuk mencapai kebijakan 99 persen ruang kosong untuk volume.

Robocopy mungkin memindahkan file lebih cepat daripada yang dapat Anda sinkronkan ke cloud dan tingkat secara lokal yang menyebabkan Anda kehabisan ruang disk lokal. Robocopy kemudian akan gagal. Sebaiknya Anda bekerja melalui berbagi dalam urutan untuk mencegah masalah. Misalnya, pertimbangkan untuk tidak memulai pekerjaan Robocopy untuk semua berbagi secara bersamaan. Atau pertimbangkan untuk memindahkan berbagi yang sesuai dengan jumlah ruang kosong saat ini di instans Windows Server. Jika pekerjaan Robocopy gagal, Anda selalu dapat menjalankan kembali perintah selama Anda menggunakan opsi cermin/bersihkan berikut:

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

Fase 8: Peralihan pengguna

Saat Anda menjalankan perintah Robocopy untuk pertama kalinya, pengguna dan aplikasi Anda masih mengakses file di server Linux Samba dan berpotensi mengubahnya. Robocopy mungkin telah memproses direktori dan berpindah ke direktori berikutnya, lalu pengguna di lokasi sumber (Linux) menambahkan, mengubah, atau menghapus file yang sekarang tidak akan diproses dalam proses Robocopy saat ini. Perilaku ini diharapkan.

Proses pertama adalah tentang memindahkan sebagian besar data ke instans Windows Server Anda dan ke cloud melalui Azure File Sync. Penyalinan pertama ini dapat memakan waktu lama, tergantung pada:

  • Bandwidth unduhan Anda.
  • Bandwidth unggahan.
  • Kecepatan jaringan lokal dan jumlah seberapa optimal jumlah alur Robocopy yang cocok dengannya.
  • Jumlah item (file dan folder) yang perlu diproses oleh Robocopy dan Azure File Sync.

Setelah proses awal selesai, jalankan kembali perintah tersebut.

Ini selesai lebih cepat untuk kedua kalinya karena hanya perlu mengangkut perubahan yang terjadi sejak eksekusi terakhir. Selama eksekusi kedua ini, perubahan baru masih dapat terakumulasi.

Ulangi proses ini sampai Anda puas bahwa jumlah waktu yang diperlukan untuk menyelesaikan operasi Robocopy untuk lokasi tertentu berada dalam batas waktu henti yang dapat diterima.

Jika Anda menganggap waktu henti dapat diterima dan Anda siap untuk membuat lokasi Linux offline, Anda dapat mengubah ACL pada root berbagi sehingga pengguna tidak dapat lagi mengakses lokasi tersebut. Atau Anda dapat mengambil langkah lain yang sesuai yang mencegah perubahan konten dalam folder ini di server Linux Anda.

Jalankan satu putaran Robocopy terakhir. Ini akan mengambil perubahan apa pun yang mungkin terlewatkan. Berapa lama langkah terakhir ini bergantung pada kecepatan pemindaian Robocopy. Anda dapat memperkirakan waktu (yang sebanding dengan downtime Anda) dengan mengukur berapa lama run sebelumnya berjalan.

Buat berbagi di folder Windows Server dan kemungkinan sesuaikan penyebaran DFS-N Anda untuk mengarahkannya ke sana. Pastikan untuk mengatur izin tingkat berbagi yang sama seperti pada berbagi SMB server Linux Samba Anda. Jika Anda menggunakan pengguna lokal di server Linux Samba, Anda perlu membuat ulang pengguna ini sebagai pengguna lokal Windows Server. Anda juga perlu memetakan SID yang sudah ada yang dipindahkan Robocopy ke instans Windows Server ke SID pengguna lokal Windows Server baru Anda. Jika Anda menggunakan akun Direktori Aktif dan ACL, Robocopy akan memindahkannya apa adanya dan tidak diperlukan tindakan lebih lanjut.

Anda telah selesai memigrasikan berbagi atau grup berbagi ke root atau volume yang sama (bergantung pada pemetaan Anda dari Fase 1).

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

Peringatan

Setelah Anda memindahkan semua data dari server Linux Samba ke instans Server Windows dan migrasi Anda selesai, kembali ke semua grup sinkronisasi di portal Microsoft Azure. Sesuaikan persentase ruang kosong untuk volume cloud tiering ke sesuatu yang lebih cocok untuk penggunaan cache, seperti 20 persen.

Kebijakan untuk ruang kosong dalam volume cloud tiering bertindak pada tingkat volume dengan kemungkinan beberapa titik akhir server yang disinkronkan darinya. Jika Anda lupa menyesuaikan ruang kosong bahkan pada satu titik akhir server, sinkronisasi akan terus menerapkan aturan yang paling ketat dan berupaya untuk menjaga 99 persen ruang disk kosong. Cache lokal mungkin tidak berfungsi seperti yang Anda harapkan. Kinerja mungkin dapat diterima jika tujuan Anda adalah memiliki namespace untuk volume yang hanya berisi data arsip yang jarang diakses dan Anda memesan sisa ruang penyimpanan untuk skenario lain.

Pecahkan masalah

Masalah yang paling umum adalah bahwa perintah Robocopy gagal dengan Volume penuh di sisi Windows Server. Cloud tiering bertindak sekali setiap jam untuk mengevakuasi konten dari disk Windows Server lokal yang telah disinkronkan. Tujuannya adalah untuk mencapai ruang kosong 99 persen pada volume.

Biarkan kemajuan sinkronisasi dan cloud tiering mengosongkan ruang disk. Anda dapat mengamatinya di File Explorer di Windows Server.

Ketika instans Windows Server Anda memiliki kapasitas yang tersedia cukup, menjalankan kembali perintah akan menyelesaikan masalah. Tidak ada yang rusak ketika Anda masuk ke situasi ini dan Anda dapat melanjutkan dengan percaya diri. Ketidaknyamanan menjalankan perintah lagi adalah satu-satunya konsekuensi.

Periksa tautan di bagian berikut untuk memecahkan masalah Azure File Sync.

Langkah berikutnya

Artikel berikut ini berisi opsi tingkat lanjut, praktik terbaik, dan bantuan pemecahan masalah untuk Azure File Sync.