Bagikan melalui

Memigrasikan instans API Management yang disuntikkan VNet yang dihosting di platform stv1 ke stv2

  • Artikel

BERLAKU UNTUK: Pengembang | Premi

Artikel ini menyediakan langkah-langkah untuk memigrasikan instans API Management yang dihosting pada stv1 platform komputasi di tempat ke stv2 platform saat instans disuntikkan (disebarkan) di VNet eksternal atau internal . Cari tahu apakah Anda perlu melakukan ini.

Catatan

Baru pada bulan Agustus 2024: Untuk membantu Anda memigrasikan instans yang disuntikkan VNet, kami telah meningkatkan opsi migrasi di portal! Anda sekarang dapat memigrasikan instans Anda di tempat dan menyimpan subnet dan alamat IP yang sama.

Untuk instans yang disuntikkan VNet, Anda memiliki opsi migrasi berikut:

  • Opsi 1: Pertahankan subnet yang sama - Migrasikan instans di tempat dan pertahankan konfigurasi subnet instans yang ada. Anda dapat memilih apakah alamat VIP asli instans API Management dipertahankan (disarankan) atau apakah alamat VIP baru akan dibuat.

  • Opsi 2: Ubah ke subnet baru - Migrasikan instans Anda dengan menentukan subnet yang berbeda di VNet yang sama atau berbeda. Setelah migrasi, secara opsional migrasi kembali ke subnet asli instans. Proses migrasi mengubah alamat VIP instans. Setelah migrasi, Anda perlu memperbarui dependensi jaringan apa pun termasuk DNS, aturan firewall, dan VNet untuk menggunakan alamat VIP baru.

Jika Anda perlu memigrasikan API Management yang disuntikkan non-VNnet yang dihosting di stv1 platform, lihat Memigrasikan instans API Management yang disuntikkan non-VNet ke platform stv2.

Penting

Dukungan untuk instans API Management yang dihosting stv1 di platform sedang dihentikan. Di Azure global, tanggal penghentian adalah 31 Agustus 2024. Di Azure Government dan di Azure yang dioperasikan oleh 21Vianet (Azure di Tiongkok), tanggal penghentian adalah 24 Februari 2025. Jika Anda memiliki instans yang dihosting di stv1 platform, migrasikan ke stv2 platform sebelum tanggal pensiun untuk menghindari gangguan layanan.

Perhatian

  • Memigrasikan instans API Management Anda ke stv2 platform adalah operasi yang berjalan lama.
  • Migrasi ke stv2 tidak dapat dibatalkan.

Apa yang terjadi selama migrasi?

Migrasi platform API Management dari stv1 ke stv2 melibatkan pembaruan komputasi yang mendasar saja dan tidak berdampak pada konfigurasi layanan/API yang bertahan di lapisan penyimpanan.

  • Proses peningkatan melibatkan pembuatan komputasi baru secara paralel dengan komputasi lama, yang dapat memakan waktu hingga 45 menit. Rencanakan waktu yang lebih lama untuk penyebaran multi-wilayah dan dalam skenario yang melibatkan perubahan subnet lebih dari sekali.
  • Status API Management di portal Azure akan diperbarui.
  • Untuk opsi migrasi tertentu, Anda dapat memilih untuk mempertahankan alamat VIP atau VIP publik baru akan dibuat.
  • Untuk skenario migrasi saat alamat VIP baru dibuat:
    • Azure mengelola migrasi.
    • DNS gateway masih menunjuk ke komputasi lama jika domain kustom sedang digunakan.
    • Jika DNS kustom tidak digunakan, gateway dan portal DNS segera mengarah ke komputasi baru.
    • Untuk instans dalam mode VNet internal, pelanggan mengelola DNS, sehingga entri DNS terus menunjuk ke komputasi lama hingga diperbarui oleh pelanggan.
    • Ini adalah DNS yang menunjuk ke komputasi baru atau lama dan karenanya tidak ada waktu henti ke API.
    • Perubahan diperlukan pada aturan firewall Anda, jika ada, untuk memungkinkan subnet komputasi baru mencapai backend.
    • Setelah migrasi berhasil, komputasi lama secara otomatis dinonaktifkan setelah beberapa saat. Saat mengubah ke subnet baru menggunakan bilah migrasi Platform di portal, Anda dapat mengaktifkan pengaturan migrasi untuk mempertahankan gateway lama selama 48 jam. Opsi penundaan 48 jam hanya tersedia untuk layanan yang disuntikkan VNet.

Prasyarat

Prasyarat lain khusus untuk opsi migrasi di bagian berikut.

Opsi 1: Migrasi dan pertahankan subnet yang sama

Anda dapat memigrasikan instans API Management ke stv2 platform yang menyimpan konfigurasi subnet yang ada, yang menyederhanakan migrasi Anda. Anda dapat bermigrasi menggunakan bilah migrasi Platform di portal Azure atau Migrasi ke REST API Stv2.

Prasyarat

  • Grup keamanan jaringan harus dilampirkan ke setiap subnet, dan aturan NSG untuk API Management pada stv2 platform harus dikonfigurasi. Berikut ini adalah pengaturan konektivitas minimum:

    • Keluar ke Azure Storage melalui port 443
    • Keluar ke Azure SQL melalui port 1433
    • Keluar ke Azure Key Vault melalui port 443
    • Masuk dari Azure Load Balancer melalui port 6390
    • Masuk dari tag layanan ApiManagement melalui port 3443
    • Masuk melalui port 80/443 untuk klien yang memanggil layanan API Management
    • Subnet harus mengaktifkan titik akhir layanan untuk Azure Storage, Azure SQL, dan Azure Key Vault

  • Ruang alamat setiap subnet yang ada harus cukup besar untuk menghosting salinan layanan yang ada secara berdampingan dengan layanan yang ada selama migrasi.

  • Pertimbangan jaringan lainnya:

    • Nonaktifkan aturan skala otomatis apa pun yang dikonfigurasi untuk instans API Management yang disebarkan di subnet. Aturan skala otomatis dapat mengganggu proses migrasi.
    • Jika Anda memiliki beberapa instans API Management di subnet yang sama, migrasikan setiap instans secara berurutan. Kami menyarankan agar Anda segera memigrasikan semua instans di subnet untuk menghindari potensi masalah dengan instans yang dihosting di platform yang berbeda di subnet yang sama.

Opsi alamat IP publik - migrasi subnet yang sama

Anda dapat memilih apakah alamat VIP asli instans API Management dipertahankan (disarankan) atau apakah alamat VIP baru akan dibuat.

  • Pertahankan alamat IP virtual - Jika Anda mempertahankan alamat VIP dalam VNet dalam mode eksternal, permintaan API dapat tetap responsif selama migrasi (lihat Waktu henti yang diharapkan); untuk VNet dalam mode internal, waktu henti sementara diharapkan. Konfigurasi infrastruktur (seperti domain kustom, lokasi, dan sertifikat CA) akan dikunci selama 45 menit. Tidak diperlukan konfigurasi lebih lanjut setelah migrasi.

    Dengan opsi ini, komputasi stv1 dihapus secara permanen setelah migrasi selesai. Tidak ada opsi untuk mempertahankannya sementara.

    Gambar berikut menunjukkan gambaran umum tingkat tinggi tentang apa yang terjadi ketika alamat IP dipertahankan.

    Diagram migrasi di tempat ke subnet yang sama dan mempertahankan alamat IP.

  • Alamat IP virtual baru - Jika Anda memilih opsi ini, API Management menghasilkan alamat VIP baru untuk instans Anda. Permintaan API tetap responsif selama migrasi. Konfigurasi infrastruktur (seperti domain kustom, lokasi, dan sertifikat CA) akan dikunci selama 30 menit. Setelah migrasi, Anda harus memperbarui dependensi jaringan apa pun termasuk DNS, aturan firewall, dan VNet untuk menggunakan alamat VIP baru.

    Dengan opsi ini, stv1 komputasi dipertahankan untuk jangka waktu singkat secara default setelah migrasi selesai sehingga Anda dapat memvalidasi instans yang dimigrasikan dan mengonfirmasi konfigurasi jaringan dan DNS.

    Gambar berikut menunjukkan gambaran umum tingkat tinggi tentang apa yang terjadi ketika alamat IP baru dihasilkan.

    Diagram migrasi di tempat ke subnet yang sama dan menghasilkan alamat IP baru.

Alamat IP yang dibuat sebelumnya untuk migrasi

Untuk instans API Management yang dapat dijangkau oleh alamat IP publik, API Management telah membuat alamat IP publik untuk proses migrasi. Temukan alamat IP yang dibuat sebelumnya di output JSON dari properti instans API Management Anda. Di bawah customProperties, alamat IP yang dibuat sebelumnya adalah nilai Microsoft.WindowsAzure.ApiManagement.Stv2MigrationPreCreatedIps properti . Untuk penyebaran multi-wilayah, nilainya adalah daftar alamat IP yang dipisahkan koma yang dibuat sebelumnya.

Gunakan alamat IP (atau alamat) yang dibuat sebelumnya untuk membantu Anda mengelola proses migrasi:

  • Saat Anda memigrasikan dan mempertahankan alamat VIP, alamat IP yang dibuat sebelumnya ditetapkan untuk sementara ke penyebaran baru stv2 , sebelum alamat IP asli ditetapkan ke stv2 penyebaran. Jika Anda memiliki aturan firewall yang membatasi akses ke instans API Management, misalnya, Anda dapat menambahkan alamat IP yang dibuat sebelumnya ke daftar yang diizinkan untuk mempertahankan kelangsungan akses klien selama migrasi. Setelah migrasi selesai, Anda dapat menghapus alamat IP yang dibuat sebelumnya dari daftar yang diizinkan.
  • Saat Anda memigrasikan dan menghasilkan alamat VIP baru, alamat IP yang dibuat sebelumnya ditetapkan ke penyebaran baru stv2 selama migrasi dan bertahan setelah migrasi selesai. Gunakan alamat IP yang dibuat sebelumnya untuk memperbarui dependensi jaringan Anda, seperti aturan DNS dan firewall, untuk menunjuk ke alamat IP baru.

Waktu henti dan retensi komputasi yang diharapkan

Saat memigrasikan instans yang disuntikkan VNet dan menjaga konfigurasi subnet yang sama, minimal atau tanpa waktu henti untuk gateway API diharapkan. Tabel berikut ini meringkas waktu henti dan stv1 retensi komputasi yang diharapkan untuk setiap skenario migrasi saat menyimpan subnet yang sama:

Mode VNet Opsi IP publik Waktu henti yang diharapkan stv1 retensi komputasi
Eksternal Mempertahankan VIP Tidak ada waktu henti; lalu lintas dilayani pada alamat IP sementara hingga 20 menit selama migrasi ke penyebaran baru stv2 Tidak ada retensi
Eksternal VIP baru Tidak ada waktu henti Dipertahankan secara default selama 15 menit untuk memungkinkan Anda memperbarui dependensi jaringan
Internal Mempertahankan VIP Waktu henti selama sekitar 20 menit selama migrasi sementara alamat IP yang ada ditetapkan ke penyebaran baru stv2 . Tidak ada retensi
Internal VIP baru Tidak ada waktu henti Dipertahankan secara default selama 15 menit untuk memungkinkan Anda memperbarui dependensi jaringan; dapat diperpanjang hingga 48 jam saat menggunakan portal

Langkah-langkah migrasi - pertahankan subnet yang sama

  1. Di Portal Microsoft Azure, navigasikan ke instans API Management Anda.
  2. Di menu sebelah kiri, di bawah Pengaturan, pilih Migrasi platform.
  3. Di bawah Pilih opsi migrasi, pilih Pertahankan subnet yang sama.
  4. Di bawah opsi Pilih alamat IP, pilih salah satu dari dua opsi alamat IP.

    Catatan

    Jika VNet Anda berada dalam mode eksternal, perhatikan alamat IP publik yang dibuat sebelumnya untuk proses migrasi. Gunakan alamat ini untuk mengonfigurasi konektivitas jaringan untuk instans yang dimigrasikan.

  5. (Misalnya disuntikkan dalam mode internal dan bermigrasi ke VIP baru) Di bawah Pilih skenario yang selaras dengan persyaratan Anda, pilih salah satu dari dua opsi, tergantung pada apakah Anda ingin mempertahankan komputasi asli stv1 untuk periode setelah migrasi.
  6. Pilih Verifikasi untuk menjalankan pemeriksaan otomatis pada subnet. Jika masalah terdeteksi, sesuaikan konfigurasi subnet Anda dan jalankan pemeriksaan lagi. Untuk dependensi jaringan lain, seperti aturan DNS dan firewall, periksa secara manual.
  7. Konfirmasikan bahwa Anda ingin bermigrasi, dan pilih Mulai migrasi. Status instans API Management Anda berubah menjadi Pembaruan. Proses migrasi membutuhkan waktu sekitar 45 menit untuk diselesaikan. Saat status berubah menjadi Online, migrasi selesai.

Opsi 2: Migrasi dan ubah ke subnet baru

Dengan menggunakan portal Azure, Anda dapat memigrasikan instans dengan menentukan subnet yang berbeda di VNet yang sama atau berbeda. Setelah migrasi, secara opsional migrasi kembali ke subnet asli instans.

Gambar berikut menunjukkan gambaran umum tingkat tinggi tentang apa yang terjadi selama migrasi ke subnet baru.

Diagram migrasi di tempat ke subnet baru.

Prasyarat

  • Subnet baru di jaringan virtual saat ini, di setiap wilayah tempat instans API Management disebarkan. (Atau, siapkan subnet di jaringan virtual yang berbeda di wilayah dan langganan yang sama dengan instans API Management Anda). Grup keamanan jaringan harus dilampirkan ke setiap subnet, dan aturan NSG untuk API Management pada stv2 platform harus dikonfigurasi.

  • (Opsional) Sumber daya alamat IPv4 publik SKU Standar baru di wilayah dan langganan yang sama dengan instans API Management Anda. Untuk detailnya, lihat Prasyarat untuk koneksi jaringan.

Penting

  • Mulai Mei 2024, sumber daya alamat IP publik tidak lagi diperlukan saat menyebarkan (menyuntikkan) instans API Management di VNet dalam mode internal atau memigrasikan konfigurasi VNet internal ke subnet baru. Dalam mode VNet eksternal, menentukan alamat IP publik bersifat opsional; jika Anda tidak menyediakannya, alamat IP publik yang dikelola Azure secara otomatis dikonfigurasi dan digunakan untuk lalu lintas API runtime. Hanya berikan alamat IP publik jika Anda ingin memiliki dan mengontrol alamat IP publik yang digunakan untuk komunikasi masuk atau keluar ke internet.
  • Saat ini, jika Anda mengaktifkan redundansi zona untuk instans API Management di VNet baik dalam mode internal atau mode eksternal, Anda harus menentukan alamat IP publik baru.

Langkah-langkah migrasi - ubah ke subnet baru

  1. Di Portal Microsoft Azure, navigasikan ke instans API Management Anda.

  2. Di menu sebelah kiri, di bawah Pengaturan, pilih Migrasi platform.

  3. Di bawah Opsi pilih migrasi, pilih Ubah ke subnet baru.

  4. Di bawah Pilih skenario yang selaras dengan persyaratan Anda, pilih salah satu dari dua opsi, tergantung pada apakah Anda ingin mempertahankan komputasi asli stv1 untuk periode setelah migrasi.

    Cuplikan layar opsi untuk mempertahankan komputasi stv1 di portal.

  5. Di bawah Tentukan pengaturan migrasi untuk setiap lokasi:

    1. Pilih lokasi untuk dimigrasikan.
    2. Pilih Jaringan virtual, Subnet, dan alamat IP Publik opsional yang ingin Anda migrasikan.

    Cuplikan layar memilih pengaturan migrasi jaringan di portal.

  6. Di bawah Verifikasi bahwa subnet Anda memenuhi persyaratan migrasi, pilih Verifikasi untuk menjalankan pemeriksaan otomatis pada subnet. Jika masalah terdeteksi, sesuaikan konfigurasi subnet Anda dan jalankan pemeriksaan lagi. Untuk dependensi jaringan lain, seperti aturan DNS dan firewall, periksa secara manual.

  7. Konfirmasikan bahwa Anda ingin bermigrasi, dan pilih Migrasi. Status instans API Management Anda berubah menjadi Pembaruan. Proses migrasi membutuhkan waktu sekitar 45 menit untuk diselesaikan. Saat status berubah menjadi Online, migrasi selesai.

Jika instans API Management Anda disebarkan di beberapa wilayah, ulangi langkah-langkah sebelumnya untuk terus memigrasikan pengaturan VNet untuk lokasi instans Anda yang tersisa.

(Opsional) Migrasi kembali ke subnet asli

Jika Anda memigrasikan dan mengubah ke subnet baru, secara opsional migrasi kembali ke subnet asli yang Anda gunakan di setiap wilayah. Untuk melakukannya, perbarui konfigurasi VNet lagi, kali ini menentukan VNet dan subnet asli di setiap wilayah. Seperti dalam migrasi sebelumnya, harapkan operasi yang berjalan lama, dan harapkan alamat VIP berubah.

Gambar berikut menunjukkan gambaran umum tingkat tinggi tentang apa yang terjadi selama migrasi kembali ke subnet asli.

Diagram migrasi di tempat kembali ke subnet asli.

Penting

Jika VNet dan subnet dikunci (karena instans API Management berbasis platform lainnya stv1 disebarkan di sana) atau grup sumber daya tempat VNet asli disebarkan memiliki kunci sumber daya, pastikan untuk menghapus kunci sebelum bermigrasi kembali ke subnet asli. Tunggu hingga penghapusan kunci selesai sebelum mencoba migrasi ke subnet asli. Pelajari selengkapnya.

Prasyarat tambahan

  • Subnet asli yang tidak terkunci, di setiap wilayah tempat instans API Management disebarkan. Grup keamanan jaringan harus dilampirkan ke subnet, dan aturan NSG untuk API Management harus dikonfigurasi.

  • (Opsional) Sumber daya alamat IPv4 publik SKU Standar baru di wilayah dan langganan yang sama dengan instans API Management Anda.

    Penting

    • Mulai Mei 2024, sumber daya alamat IP publik tidak lagi diperlukan saat menyebarkan (menyuntikkan) instans API Management di VNet dalam mode internal atau memigrasikan konfigurasi VNet internal ke subnet baru. Dalam mode VNet eksternal, menentukan alamat IP publik bersifat opsional; jika Anda tidak menyediakannya, alamat IP publik yang dikelola Azure secara otomatis dikonfigurasi dan digunakan untuk lalu lintas API runtime. Hanya berikan alamat IP publik jika Anda ingin memiliki dan mengontrol alamat IP publik yang digunakan untuk komunikasi masuk atau keluar ke internet.
    • Saat ini, jika Anda mengaktifkan redundansi zona untuk instans API Management di VNet baik dalam mode internal atau mode eksternal, Anda harus menentukan alamat IP publik baru.

Memperbarui konfigurasi VNet

  1. Di portal, navigasikan ke VNet asli Anda.
  2. Di menu sebelah kiri, pilih Subnet, lalu subnet asli.
  3. Verifikasi bahwa alamat IP asli dirilis oleh API Management. Di bawah IP yang tersedia, perhatikan jumlah alamat IP yang tersedia di subnet. Semua alamat (kecuali untuk alamat cadangan Azure) harus tersedia. Jika perlu, tunggu hingga alamat IP dirilis.
  4. Navigasi ke instans API Management Anda.
  5. Di menu sebelah kiri, di bawah Jaringan, pilih Jaringan virtual.
  6. Pilih koneksi jaringan di lokasi yang ingin Anda perbarui.
  7. Pilih jaringan dan subnet VNet asli. Secara opsional pilih IP publik baru. Pilih Terapkan.
  8. Jika instans API Management Anda disebarkan di beberapa wilayah, lanjutkan mengonfigurasi pengaturan VNet untuk lokasi instans Anda yang tersisa.
  9. Di bilah navigasi atas, pilih Simpan.

Setelah Anda memperbarui konfigurasi VNet, status instans API Management Anda berubah menjadi Pembaruan. Proses migrasi membutuhkan waktu sekitar 45 menit untuk diselesaikan. Saat status berubah menjadi Online, migrasi selesai.

Verifikasi migrasi

Untuk memverifikasi bahwa migrasi berhasil, saat status berubah menjadi Online, periksa versi platform instans API Management Anda. Setelah migrasi berhasil, nilainya adalah stv2 atau stv2.1.

Konfirmasi pengaturan sebelum gateway lama dibersihkan

Untuk skenario di mana gateway lama untuk sementara dipertahankan setelah migrasi, komputasi lama dan baru yang dibuat selama migrasi berdampingan untuk waktu yang singkat, sekitar 15 menit, yang dapat Anda gunakan untuk memvalidasi penyebaran dan bahwa aplikasi Anda berfungsi seperti yang diharapkan. Untuk skenario tertentu, Anda dapat secara opsional memperpanjang periode retensi menjadi 48 jam melalui pengaturan portal.

  • Selama jendela ini, gateway lama dan baru online dan melayani lalu lintas. Anda tidak ditagih selama waktu ini.
  • Gunakan jendela ini untuk memperbarui dependensi jaringan apa pun termasuk DNS, aturan firewall, dan VNet untuk menggunakan alamat VIP dan ruang alamat subnet baru.
  • Selain itu, periksa status jaringan instans yang diperbarui untuk memastikan konektivitas instans ke dependensinya. Di portal, di menu sebelah kiri, pada Penyebaran dan infrastruktur, pilih Jaringan>Status jaringan. Jika diperlukan, perbarui pengaturan seperti UDR dan aturan NSG.
  • Setelah jendela, gateway lama dinonaktifkan dan gateway baru adalah satu-satunya yang melayani lalu lintas.

Kembalikan secara otomatis jika migrasi gagal

Jika ada kegagalan selama proses migrasi, instans akan secara otomatis kembali ke stv1 platform. Jika migrasi berhasil diselesaikan (versi platform instans ditampilkan sebagai stv2 atau stv2.1 dan status sebagai Online), Anda tidak dapat kembali ke stv1 platform.

Untuk bantuan jika migrasi gagal, hubungi dukungan Azure.

Jika Anda memerlukan kemampuan untuk kembali secara manual, rekomendasinya adalah menyebarkan instans baru stv2 secara berdampingan dengan instans API Management asli Anda.

Bantuan dan dukungan

Kami di sini untuk membantu Anda bermigrasi ke stv2 platform dengan gangguan minimal pada layanan Anda.

Jika Anda memiliki pertanyaan, dapatkan jawaban cepat dari pakar komunitas di Microsoft Q&A. Jika Anda memiliki rencana dukungan dan memerlukan bantuan teknis, buat permintaan dukungan.

  1. Untuk Ringkasan, tulis deskripsi masalah Anda, misalnya, "penghentian stv1".
  2. Di Jenis masalah, pilih Teknis.
  3. Di Langganan, pilih langganan Anda.
  4. Di Layanan, pilih Layanan saya, lalu pilih Layanan API Management.
  5. Di Sumber daya, pilih sumber daya Azure tempat Anda membuat permintaan dukungan.
  6. Untuk Jenis masalah, pilih Administrasi dan Manajemen.
  7. Untuk Subjenis masalah, pilih Peningkatan, Penskalaan, atau Perubahan SKU.

Tanya jawab umum

  • Informasi apa yang kita butuhkan untuk memilih jalur migrasi?

    • Apa mode jaringan instans API Management?
    • Apakah domain kustom dikonfigurasi?
    • Apakah firewall terlibat?
    • Setiap dependensi yang diketahui diambil oleh hulu/hilir pada IP yang terlibat?
    • Apakah penyebaran multi-wilayah?
    • Dapatkah kita memodifikasi instans yang ada atau diperlukan penyiapan paralel?
    • Bisakah ada waktu henti?
    • Dapatkah migrasi dilakukan dalam jam nonbusiness?

  • Apa saja prasyarat untuk migrasi?

    Untuk instans yang disuntikkan VNet, lihat prasyarat untuk opsi untuk bermigrasi dan menyimpan subnet yang sama atau untuk bermigrasi dan mengubah ke subnet baru.

  • Apakah migrasi akan menyebabkan waktu henti?

    Saat memigrasikan instans yang disuntikkan VNet dan menjaga konfigurasi subnet yang sama, minimal atau tanpa waktu henti untuk gateway API diharapkan. Lihat tabel ringkasan dalam Waktu henti yang diharapkan.

    Saat bermigrasi dan mengubah ke alamat VIP baru, seharusnya tidak ada waktu henti jika nama host default sedang digunakan. Sangat penting bahwa semua dependensi jaringan diurus di muka, agar API yang terkena dampak berfungsi. Namun, jika domain kustom sedang digunakan, domain kustom akan menunjuk ke komputasi yang dibersihkan hingga diperbarui yang dapat menyebabkan waktu henti. Atau, untuk opsi migrasi tertentu, aktifkan pengaturan migrasi untuk mempertahankan gateway lama selama 48 jam. Memiliki komputasi lama dan baru yang hidup berdampingan akan memfasilitasi validasi, dan kemudian Anda dapat memperbarui entri DNS kustom sesuai keinginan.

  • Lalu lintasku terowongan paksa melalui firewall. Perubahan apa yang diperlukan?

    • Pertama-tama, pastikan bahwa subnet yang Anda gunakan untuk migrasi mempertahankan konfigurasi berikut (subnet tersebut harus sudah dikonfigurasi jika Anda bermigrasi dan menyimpan subnet Anda saat ini):
      • Aktifkan titik akhir layanan seperti yang dijelaskan di sini
      • UDR (rute yang ditentukan pengguna) memiliki hop dari tag layanan ApiManagement yang diatur ke "Internet" dan tidak hanya ke alamat firewall Anda
    • Persyaratan untuk konfigurasi NSG untuk stv2 tetap sama baik Anda memiliki firewall atau tidak; pastikan subnet baru Anda memilikinya
    • Aturan firewall yang mengacu pada rentang alamat IP instans API Management saat ini harus diperbarui untuk menggunakan rentang alamat IP subnet baru Anda.

  • Dapatkah kehilangan data atau konfigurasi terjadi oleh/selama migrasi?

    stv1 untuk stv2 migrasi melibatkan pembaruan platform komputasi saja dan lapisan penyimpanan internal tidak diubah. Oleh karena itu semua konfigurasi aman selama proses migrasi. Ini termasuk identitas terkelola yang ditetapkan sistem, yang jika diaktifkan dipertahankan.

  • Cara mengonfirmasi bahwa migrasi selesai dan berhasil

    Migrasi dianggap selesai dan berhasil ketika status di halaman Gambaran Umum berbunyi Online bersama dengan versi platform baik stv2 atau stv2.1. Verifikasi juga bahwa status jaringan di bilah Jaringan menunjukkan warna hijau untuk semua konektivitas yang diperlukan.

  • Dapatkah saya melakukan migrasi menggunakan portal?

    Ya, instans yang disuntikkan VNet dapat dimigrasikan dengan menggunakan bilah migrasi Platform.

  • Dapatkah saya mempertahankan alamat IP instans?

    Ya, bilah migrasi Platform di portal dan REST API memiliki opsi untuk mempertahankan alamat IP.

  • Apakah ada jalur migrasi tanpa memodifikasi instans yang ada?

    Ya, Anda memerlukan migrasi berdampingan. Itu berarti Anda membuat instans API Management baru secara paralel dengan instans Anda saat ini dan menyalin konfigurasi ke instans baru.

  • Apa yang terjadi jika migrasi gagal?

    Jika instans API Management Anda tidak menampilkan versi platform sebagai stv2 atau stv2.1 dan status sebagai Online setelah Anda memulai migrasi, mungkin gagal. Layanan Anda secara otomatis digulung balik ke instans lama dan tidak ada perubahan yang dilakukan.

  • Fungsionalitas apa yang tidak tersedia selama migrasi?

    Permintaan API tetap responsif selama migrasi. Konfigurasi infrastruktur (seperti domain kustom, lokasi, dan sertifikat CA) dikunci selama 30 menit.

  • Berapa lama migrasi akan berlangsung?

    Durasi yang diharapkan untuk migrasi ke konfigurasi VNet baru adalah sekitar 45 menit. Indikator untuk memeriksa apakah migrasi sudah dilakukan adalah memeriksa apakah Status instans Anda kembali ke Online dan tidak Memperbarui. Rencanakan waktu yang lebih lama untuk penyebaran multi-wilayah dan dalam skenario yang melibatkan perubahan subnet lebih dari sekali.

  • Apakah ada cara untuk memvalidasi konfigurasi VNet sebelum mencoba migrasi?

    Jika Anda berencana untuk mengubah subnet selama migrasi, Anda dapat menyebarkan instans API Management baru dengan sumber daya alamat IP VNet, subnet, dan (opsional) yang akan Anda gunakan untuk migrasi aktual. Navigasi ke halaman Status jaringan setelah penyebaran selesai, dan verifikasi apakah setiap status konektivitas titik akhir berwarna hijau. Jika ya, Anda dapat menghapus instans API Management baru ini dan melanjutkan migrasi nyata dengan layanan asli stv1yang dihosting.

  • Dapatkah saya mengembalikan migrasi jika diperlukan?

    Jika ada kegagalan selama proses migrasi, instans akan secara otomatis kembali ke stv1 platform. Namun, setelah layanan berhasil bermigrasi, Anda tidak dapat kembali ke stv1 platform.

  • Apakah ada perubahan yang diperlukan di zona DNS domain/privat kustom?

    Dengan instans yang disuntikkan VNet dalam mode internal dan mengubah ke VIP baru, Anda harus memperbarui zona DNS privat ke alamat IP VNet baru yang diperoleh setelah migrasi. Perhatikan juga untuk memperbarui zona DNS non-Azure (misalnya, server DNS lokal Anda yang menunjuk ke alamat IP privat API Management). Namun, dalam mode eksternal, proses migrasi akan secara otomatis memperbarui domain default jika digunakan.

  • Instans stv1 saya disebarkan ke beberapa wilayah Azure (multi-wilayah). Bagaimana cara meningkatkan ke stv2?

    Penyebaran multi-wilayah mencakup lebih banyak gateway terkelola yang disebarkan di lokasi lain. Saat bermigrasi menggunakan bilah migrasi Platform di portal, Anda memigrasikan setiap lokasi secara terpisah. Rest API Migrasi ke Stv2 memigrasikan semua lokasi dalam satu panggilan. Instans dianggap dimigrasikan ke platform baru hanya ketika semua lokasi dimigrasikan. Semua gateway regional terus beroperasi secara normal sepanjang proses migrasi.

  • Dapatkah saya meningkatkan instans stv1 saya ke subnet yang sama?

    Ya, gunakan bilah migrasi Platform di portal, atau gunakan Rest API Migrasi ke stv2.

  • Bisakah saya menguji gateway baru di subnet baru sebelum mengalihkan lalu lintas langsung?

    • Saat Anda bermigrasi ke subnet baru, secara default gateway terkelola lama dan baru berdampingan selama 15 menit, yang merupakan jendela waktu kecil untuk memvalidasi penyebaran. Anda dapat mengaktifkan pengaturan migrasi untuk mempertahankan gateway lama selama 48 jam. Perubahan ini membuat gateway terkelola lama dan baru tetap aktif untuk menerima lalu lintas dan memfasilitasi validasi.
    • Proses migrasi secara otomatis memperbarui nama domain default, dan jika digunakan, lalu lintas akan segera dirutekan ke gateway baru.
    • Jika nama domain kustom sedang digunakan, rekaman DNS terkait mungkin perlu diperbarui dengan alamat IP baru jika tidak menggunakan CNAME. Pelanggan dapat memperbarui file host mereka ke IP API Management baru dan memvalidasi instans sebelum beralih. Selama proses validasi ini, gateway lama terus melayani lalu lintas langsung.

  • Apakah ada pertimbangan saat menggunakan nama domain default di subnet baru?

    Instans yang menggunakan nama DNS default dalam mode eksternal memiliki DNS yang diupdasikan secara otomatis oleh proses migrasi. Selain itu, titik akhir manajemen, yang selalu menggunakan nama domain default, secara otomatis diperbarui oleh proses migrasi. Karena pengalihan terjadi segera pada migrasi yang berhasil, instans baru mulai segera menerima lalu lintas, dan sangat penting bahwa pembatasan/dependensi jaringan ditangani terlebih dahulu untuk menghindari API yang terkena dampak tidak tersedia.

  • Apa yang harus kita pertimbangkan untuk gateway yang dihost sendiri?

    Anda tidak perlu melakukan apa pun di gateway yang dihost sendiri. Anda hanya perlu memigrasikan instans API Management yang berjalan di Azure yang terpengaruh oleh stv1 penghentian platform. Perhatikan bahwa mungkin ada IP baru untuk titik akhir Konfigurasi instans API Management, dan batasan jaringan apa pun yang disematkan ke IP harus diperbarui.

  • Bagaimana portal pengembang terpengaruh oleh migrasi?

    Tidak ada dampak pada portal pengembang. Jika domain kustom digunakan, catatan DNS harus diperbarui dengan IP yang efektif, pascamigrasi. Namun, jika domain default sedang digunakan, domain tersebut secara otomatis diperbarui pada migrasi yang berhasil. Tidak ada waktu henti untuk portal pengembang selama migrasi.

  • Apakah ada dampak pada biaya setelah kami bermigrasi ke stv2?

    Model penagihan tetap sama untuk stv2 dan tidak akan ada biaya lagi yang dikeluarkan selama dan setelah migrasi.

  • Izin RBAC apa yang diperlukan untuk migrasi stv1 ke stv2?

    Pengguna/proses yang melakukan migrasi akan memerlukan akses tulis ke instans API Management. Selain itu, dua izin berikut diperlukan:

    • Microsoft.Network/virtualNetworks/subnets/gabung/tindakan
    • Microsoft.Network/publicIPAddresses/gabung/tindakan

Konten terkait