Bersiap untuk migrasi uji coba

Artikel ini berfokus pada persiapan tim dan pembuatan file yang diperlukan oleh Alat Migrasi Data.

Prasyarat

Selesaikan fase Validasi sebelum Anda mulai mempersiapkan migrasi uji coba.

Membuat pengaturan migrasi

Lakukan langkah-langkah berikut untuk menghasilkan spesifikasi migrasi dan file terkait untuk mengantre migrasi database koleksi Anda.

1. Jalankan perintah persiapan Alat Migrasi Data dengan parameter berikut:

   /collection:http://localhost:8080/tfs/DefaultCollection/ tenantDomainName:contoso.com /Region:CUS

   • Opsi nama domain penyewa adalah nama penyewa MICROSOFT Entra ID perusahaan Anda.
   • Perintah persiapan memerlukan akses internet. Jika Azure DevOps Server Anda tidak memiliki konektivitas internet, jalankan perintah dari komputer lain.
   • Istilah "wilayah organisasi" mengacu pada lokasi tempat Anda berencana untuk memigrasikan koleksi Anda ke Azure DevOps Services. Anda sebelumnya memilih wilayah dan merekam kode singkatnya. Gunakan kode ini dalam perintah siapkan.

2. Masuk dengan pengguna dari penyewa yang memiliki izin untuk membaca informasi tentang semua pengguna di penyewa ID Microsoft Entra.

Mengonfigurasi file spesifikasi migrasi

File spesifikasi migrasi adalah file JSON yang menginstruksikan Alat Migrasi Data cara melakukan tindakan berikut.

• Mengonfigurasi organisasi yang dimigrasikan
• Tentukan lokasi sumber
• Menyesuaikan migrasi

Banyak bidang diisi secara otomatis selama langkah persiapan tetapi Anda harus mengonfigurasi bidang berikut:

• Nama organisasi: Nama organisasi yang ingin Anda buat untuk memigrasikan data Anda.
• Lokasi: Cadangan database dan file migrasi Anda untuk diunggah ke kontainer penyimpanan Azure. Bidang ini menentukan kunci SAS yang digunakan oleh alat migrasi untuk menyambungkan dan membaca file sumber dengan aman dari kontainer penyimpanan Azure. Membuat kontainer penyimpanan dicakup nanti di Fase 5 dan menghasilkan kunci SAS tercakup dalam Fase 6 sebelum Anda mengantre migrasi baru.
• DACPAC: File yang mengemas database SQL koleksi Anda.
• Jenis migrasi: Jenis migrasi: Uji coba atau Eksekusi produksi.

Setiap file spesifikasi migrasi dimaksudkan untuk satu koleksi. Jika Anda mencoba menggunakan file spesifikasi migrasi yang dihasilkan untuk koleksi lain, migrasi tidak dimulai. Anda perlu menyiapkan uji coba untuk setiap koleksi yang ingin Anda migrasikan dan menggunakan file spesifikasi migrasi yang dihasilkan untuk mengantre migrasi.

Meninjau file log peta identitas

Log peta identitas sangat penting, sama pentingnya dengan data aktual yang Anda migrasikan. Saat Anda memeriksa file log, pahami bagaimana fungsi migrasi identitas dan potensi hasilnya. Saat Anda memigrasikan identitas, identitas dapat aktif atau historis. Identitas aktif dapat masuk ke Azure DevOps Services, sementara identitas historis tidak dapat. Layanan memutuskan jenis mana yang akan digunakan.

Catatan

Setelah identitas dimigrasikan sebagai identitas historis, tidak ada cara untuk mengonversinya menjadi identitas aktif.

Identitas aktif

Identitas aktif mengacu pada identitas pengguna di Azure DevOps Services pascamigrasi. Di Azure DevOps Services, identitas ini dilisensikan dan ditampilkan sebagai pengguna di organisasi. Identitas ditandai sebagai aktif di kolom Status Impor yang Diharapkan dalam file log peta identitas.

Identitas historis

Identitas historis dipetakan seperti di kolom Status Impor yang Diharapkan dalam file log peta identitas. Identitas tanpa entri baris dalam file juga menjadi historis. Contoh identitas tanpa entri baris mungkin adalah karyawan yang tidak lagi bekerja di perusahaan.

Tidak seperti identitas aktif, identitas historis:

• Tidak memiliki akses ke organisasi setelah migrasi.
• Tidak memiliki lisensi.
• Jangan muncul sebagai pengguna di organisasi. Semua yang berlanjut adalah gagasan nama identitas tersebut dalam organisasi, sehingga riwayatnya dapat dicari nanti. Kami menyarankan agar Anda menggunakan identitas historis untuk pengguna yang tidak lagi bekerja di perusahaan atau yang tidak memerlukan akses lebih lanjut ke organisasi.

Catatan

Setelah identitas bermigrasi sebagai historis, Anda tidak dapat membuatnya aktif.

Lisensi

Selama migrasi, lisensi ditetapkan secara otomatis untuk semua pengguna yang ditampilkan sebagai "aktif" di kolom Status Impor yang Diharapkan dari log pemetaan identitas. Jika penetapan lisensi otomatis salah, Anda dapat mengubahnya dengan mengedit "tingkat akses" dari satu atau beberapa pengguna setelah migrasi selesai.

Penugasan mungkin tidak selalu sempurna, jadi Anda memiliki hingga bulan pertama bulan berikutnya untuk menetapkan ulang lisensi sesuai kebutuhan. Jika pada bulan pertama bulan berikutnya Anda tidak menautkan langganan ke organisasi Anda dan membeli jumlah lisensi yang benar, semua lisensi masa tenggang Anda akan dicabut. Atau, jika penetapan otomatis menetapkan lebih banyak lisensi daripada yang Anda beli untuk bulan depan, maka kami tidak membebankan biaya kepada Anda untuk lisensi tambahan, tetapi kami mencabut semua lisensi yang belum dibayar.

Untuk menghindari kehilangan akses, kami sarankan Anda menautkan langganan dan membeli lisensi yang diperlukan sebelum bulan pertama, karena penagihan berjalan setiap bulan. Untuk semua eksekusi pengujian, lisensi gratis selama organisasi aktif.

Langganan Azure DevOps

Langganan Visual Studio tidak ditetapkan secara default untuk migrasi. Sebagai gantinya, pengguna dengan Langganan Visual Studio secara otomatis ditingkatkan untuk menggunakan lisensi tersebut. Jika organisasi kerja pengguna ditautkan dengan benar, Azure DevOps Services secara otomatis menerapkan manfaat langganan Visual Studio mereka pada migrasi pasca masuk pertama mereka.

Anda tidak perlu mengulangi migrasi uji coba jika pengguna tidak ditingkatkan secara otomatis untuk menggunakan Langganan Visual Studio mereka di Azure DevOps Services. Penautan Langganan Visual Studio adalah sesuatu yang terjadi di luar lingkup migrasi. Jika organisasi kerja ditautkan dengan benar sebelum atau sesudah migrasi, maka pengguna secara otomatis memiliki lisensi mereka yang ditingkatkan pada masuk berikutnya. Setelah ditingkatkan, kali berikutnya Anda memigrasikan pengguna secara otomatis ditingkatkan setelah masuk awal ke organisasi.

Membatasi akses ke IP Azure DevOps Services saja

• Opsi 1: Gunakan Tag Layanan
• Opsi 2: Gunakan Daftar IP

Batasi akses ke akun Azure Storage Anda hanya ke IP dari Azure DevOps Services. Anda dapat membatasi akses hanya dengan mengizinkan koneksi dari IP Azure DevOps Services yang terlibat dalam proses migrasi database pengumpulan. IP yang perlu diberikan akses ke akun penyimpanan Anda bergantung pada wilayah tempat Anda bermigrasi.

Opsi 1: Gunakan Tag Layanan

Anda dapat dengan mudah mengizinkan koneksi dari semua wilayah Layanan Azure DevOps dengan menambahkan azuredevops Tag Layanan ke grup keamanan jaringan atau firewall Anda baik melalui portal atau secara terprogram.

Opsi 2: Gunakan Daftar IP

IpList Gunakan perintah untuk mendapatkan daftar IP yang perlu diberikan akses untuk mengizinkan koneksi dari wilayah Azure DevOps Services tertentu.

Disertakan dalam dokumentasi bantuan adalah instruksi dan contoh untuk menjalankan Migrator dari instans Azure DevOps Server itu sendiri dan komputer jarak jauh. Jika Anda menjalankan perintah dari salah satu tingkat aplikasi instans Azure DevOps Server, perintah Anda harus memiliki struktur berikut:

Migrator IpList /collection:{CollectionURI} /tenantDomainName:{name} /region:{region} 

Anda dapat menambahkan daftar IP ke grup keamanan jaringan atau firewall Anda baik melalui portal atau secara terprogram.

Mengonfigurasi pengecualian firewall IP untuk SQL Azure

Bagian ini hanya berlaku untuk mengonfigurasi pengecualian firewall untuk SQL Azure. Untuk migrasi DACPAC, lihat Mengonfigurasi firewall Azure Storage dan jaringan virtual.

Alat Migrasi Data mengharuskan IP Layanan Azure DevOps dikonfigurasi untuk koneksi masuk hanya pada port 1433.

Lakukan langkah-langkah berikut untuk memberikan pengecualian untuk IP yang diperlukan yang ditangani di lapisan jaringan Azure untuk SQL Azure VM Anda.

1. Masuk ke portal Azure.
2. Buka SQL Azure VM Anda.
3. Di Pengaturan, pilih Penjaringan.
4. Pilih Tambahkan aturan port masuk.
5. Pilih Tingkat Lanjut untuk mengonfigurasi aturan port masuk untuk IP tertentu.
6. Di daftar drop-down Sumber, pilih Alamat IP, masukkan alamat IP yang perlu diberikan pengecualian, atur Rentang port tujuan ke 1433 dan, dalam kotak Nama, masukkan nama yang paling tepat menggambarkan pengecualian yang sedang Anda konfigurasi.

Bergantung pada aturan port masuk lainnya yang dikonfigurasi, Anda mungkin perlu mengubah prioritas default untuk pengecualian Layanan Azure DevOps, sehingga tidak diabaikan. Misalnya, jika Anda memiliki aturan "tolak pada semua koneksi masuk ke 1433" dengan prioritas yang lebih tinggi daripada pengecualian Azure DevOps Services Anda, Alat Migrasi Data mungkin tidak dapat membuat koneksi yang berhasil ke database Anda.

Ulangi penambahan aturan port masuk hingga semua IP Azure DevOps Services yang diperlukan diberikan pengecualian. Kehilangan satu IP dapat mengakibatkan migrasi Anda gagal dimulai.

Memigrasikan koleksi besar

Untuk database yang diperingatkan Alat Migrasi Data terlalu besar, pendekatan pengemasan data yang berbeda diperlukan untuk bermigrasi ke Azure DevOps Services. Jika Anda tidak yakin apakah koleksi Anda melebihi ambang ukuran, Anda harus menjalankan validasi Alat Migrasi Data pada koleksi. Validasi ini memungkinkan Anda mengetahui apakah Anda perlu menggunakan metode SQL Azure VM untuk migrasi.

Menentukan apakah Anda dapat mengurangi ukuran koleksi

Periksa untuk melihat apakah Anda dapat membersihkan data lama. Seiring waktu, koleksi dapat membangun data dalam volume besar. Pertumbuhan ini adalah bagian alami dari proses DevOps, tetapi Anda mungkin merasa tidak perlu menyimpan semua data. Beberapa contoh umum dari data yang tidak lagi relevan adalah ruang kerja yang lebih lama dan hasil build.

Alat Migrasi Data memindai koleksi Anda dan membandingkannya dengan batas yang disebutkan sebelumnya. Kemudian melaporkan apakah koleksi Anda memenuhi syarat untuk metode migrasi DACPAC atau SQL. Secara umum, idenya adalah bahwa jika koleksi Anda cukup kecil agar sesuai dengan batas DACPAC, Anda dapat menggunakan pendekatan DACPAC yang lebih cepat dan lebih sederhana. Namun, jika koleksi Anda terlalu besar, Anda perlu menggunakan metode migrasi SQL, yang melibatkan pengaturan SQL Azure VM dan memigrasikan database secara manual.

Batas ukuran

Batas saat ini adalah:

• Ukuran total database 150 GB (metadata database + blob) untuk DACPAC, jika Anda melebihi batas ini, maka Anda perlu melakukan metode migrasi SQL.
• Ukuran tabel individual 30 GB (metadata database + blob) untuk DACPAC, jika ada tabel tunggal yang melebihi batas ini, maka Anda perlu melakukan metode migrasi SQL.
• Ukuran metadata database 1.536 GB untuk metode migrasi SQL. Melebihi batas ini mengeluarkan peringatan, kami menyarankan agar Anda tetap berada di bawah ukuran ini agar migrasi berhasil.
• Ukuran metadata database 2.048 GB untuk metode migrasi SQL. Melebihi batas ini menghasilkan kesalahan, sehingga Anda tidak dapat melakukan migrasi.
• Tidak ada batasan untuk ukuran blob untuk metode migrasi SQL.

Ketika Anda membersihkan artefak yang lebih lama dan tidak lagi relevan, artefak tersebut dapat menghapus lebih banyak ruang daripada yang Anda harapkan, dan dapat menentukan apakah Anda menggunakan metode migrasi DACPAC atau komputer virtual Azure SQL.

Penting

Setelah menghapus data yang lebih lama, Anda tidak dapat memulihkannya kecuali Anda memulihkan cadangan koleksi yang lebih lama.

Jika Anda berada di bawah ambang DACPAC, ikuti instruksi untuk membuat DACPAC untuk migrasi. Jika Anda masih tidak bisa mendapatkan database di bawah ambang DACPAC, Anda perlu menyiapkan SQL Azure VM untuk bermigrasi ke Azure DevOps Services.

Menyiapkan SQL Azure VM untuk bermigrasi ke Azure DevOps Services

Lakukan langkah-langkah tingkat tinggi berikut untuk menyiapkan komputer virtual (VM) Azure SQL untuk bermigrasi ke Azure DevOps Services.

1. Menyiapkan SQL Azure VM
2. Mengonfigurasi pengecualian firewall IP
3. Memulihkan database Anda di VM
4. [Konfigurasikan koleksi Anda untuk migrasi
5. Mengonfigurasi file spesifikasi migrasi untuk menargetkan VM

Menyiapkan SQL Azure VM

Anda dapat menyiapkan SQL Azure VM dari portal Azure dengan cepat. Untuk informasi selengkapnya, lihat Menggunakan portal Azure untuk menyediakan komputer virtual Windows dengan SQL Server.

Performa komputer virtual Azure SQL Anda dan disk data terlampir berdampak signifikan pada performa migrasi. Untuk alasan ini, kami sangat menyarankan untuk melakukan tugas-tugas berikut:

• Pilih Ukuran VM pada tingkat D8s_v5_* atau yang lebih besar.
• Menggunakan disk terkelola.
• Lihat performa komputer virtual dan disk. Pastikan infrastruktur Anda dikonfigurasi sehingga IOPS VM (input/output per detik) dan IOPS penyimpanan tidak menjadi hambatan pada performa migrasi. Misalnya, pastikan jumlah disk data yang terpasang pada VM Anda cukup untuk mendukung IOPS dari VM.

Layanan Azure DevOps tersedia di beberapa wilayah Azure di seluruh dunia. Untuk memastikan bahwa migrasi berhasil dimulai, sangat penting untuk menempatkan data Anda di wilayah yang benar. Jika Anda menyiapkan SQL Azure VM di lokasi yang salah, migrasi gagal dimulai.

Penting

Azure VM memerlukan alamat IP publik.

Jika Anda menggunakan metode migrasi ini, buat VM Anda di wilayah yang didukung. Meskipun Layanan Azure DevOps tersedia di beberapa wilayah di Amerika Serikat (AS), hanya wilayah Amerika Serikat Pusat yang menerima organisasi baru. Anda tidak dapat memigrasikan data Anda ke wilayah AZURE AS lainnya sekarang.

Catatan

Pelanggan DACPAC harus berkonsultasi dengan tabel wilayah di bagian "Langkah 3: Unggah file DACPAC](migration-test-run.md#)". Panduan sebelumnya hanya untuk komputer virtual SQL Azure. Jika Anda adalah pelanggan DACPAC, lihat wilayah Azure yang didukung untuk migrasi.

Gunakan konfigurasi SQL Azure VM berikut:

• Konfigurasikan database sementara SQL untuk menggunakan drive selain drive C. Idealnya drive harus memiliki ruang kosong yang cukup; setidaknya setara dengan tabel terbesar database Anda.
• Jika database sumber Anda masih lebih dari 1 terabyte (TB) setelah Anda mengurangi ukurannya, Anda perlu melampirkan lebih banyak disk 1-TB dan menggabungkannya ke dalam satu partisi untuk memulihkan database Anda di VM.
• Jika database koleksi Anda berukuran lebih dari 1 TB, pertimbangkan untuk menggunakan SSD (hard drive solid state) untuk database sementara dan database koleksi. Selain itu, pertimbangkan untuk menggunakan VM yang lebih besar dengan 16 CPU virtual (vCPU) dan RAM 128 GB (gigabyte) (memori akses acak).

Memulihkan database Anda di VM

Setelah menyiapkan dan mengonfigurasi Azure VM, Anda perlu mengambil cadangan yang terlepas dari instans Azure DevOps Server ke Azure VM Anda. Database koleksi perlu dipulihkan pada instans SQL Anda dan tidak mengharuskan Azure DevOps Server diinstal pada VM.

Mengonfigurasi koleksi Anda untuk migrasi

Setelah database koleksi Anda dipulihkan di Azure VM Anda, konfigurasikan masuk SQL untuk memungkinkan Azure DevOps Services tersambung ke database untuk memigrasikan data. Rincian masuk ini hanya memungkinkan akses baca ke satu database.

1. Buka SQL Server Management Studio pada VM, lalu buka jendela kueri baru terhadap database yang akan dimigrasikan.

2. Atur pemulihan database menjadi sederhana:

   ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE;
   

3. Buat masuk SQL untuk database, dan tetapkan rincian masuk tersebut 'TFSEXECROLE', seperti contoh berikut.

   USE [<database name>] 
   CREATE LOGIN <pick a username> WITH PASSWORD = '<pick a password>' 
   CREATE USER <username> FOR LOGIN <username> WITH DEFAULT_SCHEMA=[dbo] 
   EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='<username>'
   

Lihat contoh perintah SQL berikut:

    ALTER DATABASE [Foo] SET RECOVERY SIMPLE; 
     
    USE [Foo] 
    CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikamimport1!' 
    CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo] 
    EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'

Penting

Aktifkan mode autentikasi SQL Server dan Windows di SQL Server Management Studio pada VM. Jika Anda tidak mengaktifkan mode autentikasi, migrasi gagal.

Mengonfigurasi file spesifikasi migrasi untuk menargetkan VM

Perbarui file spesifikasi migrasi untuk menyertakan informasi tentang cara menyambungkan ke instans SQL Server. Buka file spesifikasi migrasi Anda dan buat pembaruan berikut:

1. Hapus parameter DACPAC dari objek file sumber. Spesifikasi migrasi sebelum perubahan terlihat seperti contoh kode berikut.

   

   Spesifikasi migrasi setelah perubahan terlihat seperti contoh kode berikut.

   

2. Masukkan parameter yang diperlukan dan tambahkan objek properti berikut dalam objek sumber Anda dalam file spesifikasi.

   "Properties": 
   { 
       "ConnectionString": "Data Source={SQL Azure VM Public IP};Initial Catalog={Database Name};Integrated Security=False;User ID={SQL Login Username};Password={SQL Login Password};Encrypt=True;TrustServerCertificate=True"  
   }
   

Setelah Anda menerapkan perubahan, spesifikasi migrasi terlihat seperti contoh berikut.

Spesifikasi migrasi Anda sekarang dikonfigurasi untuk menggunakan SQL Azure VM untuk migrasi. Lanjutkan dengan langkah-langkah persiapan lainnya untuk migrasi. Setelah migrasi selesai, pastikan untuk menghapus masuk SQL atau memutar kata sandi. Microsoft tidak menyimpan informasi masuk setelah migrasi selesai.

Membuat Kontainer Azure Storage di pusat data yang dipilih

Menggunakan Alat Migrasi Data untuk Azure DevOps memerlukan kontainer Azure Storage di pusat data Azure yang sama dengan organisasi Azure DevOps Services akhir. Misalnya, jika Anda ingin organisasi Azure DevOps Services Anda dibuat di pusat data Central Amerika Serikat, buat kontainer Azure Storage di pusat data yang sama. Tindakan ini secara drastis mempercepat waktu yang diperlukan untuk memigrasikan database SQL, karena transfer terjadi dalam pusat data yang sama.

Untuk informasi selengkapnya, lihat Membuat akun penyimpanan.

Menyiapkan penagihan

Masa tenggang ditempatkan pada organisasi Azure DevOps Services yang baru dimigrasikan untuk memungkinkan tim Anda menyelesaikan langkah apa pun yang diperlukan dan memperbaiki penetapan lisensi. Jika Anda mengantisipasi bahwa Anda mungkin ingin membeli paket pengguna lagi, alur build atau penyebaran, layanan build yang dihosting, layanan uji beban yang dihosting, misalnya, kami sangat menyarankan agar Anda yakin bahwa Anda memiliki Langganan Azure yang siap untuk ditautkan ke organisasi yang dimigrasikan. Masa tenggang berakhir pada hari pertama bulan berikutnya setelah Anda menyelesaikan migrasi.

Kami mengingatkan Anda lagi dalam fase Pascamigrasi (tautan) saat Anda perlu melakukan penautan. Langkah persiapan ini lebih tentang memastikan bahwa Anda tahu Langganan Azure mana yang Anda gunakan di langkah selanjutnya. Untuk informasi selengkapnya, lihat Menyiapkan tagihan untuk organisasi Anda.

Langkah berikutnya

Melakukan migrasi uji coba

Artikel terkait

• Migrasi ke Layanan Azure DevOps
• Menyelesaikan tugas pascamigrasi