Key Management Service：Langkah 2: Lakukan migrasi

1. Tentukan apakah Anda memiliki sumber daya yang perlu dimigrasikan

1. Masuk ke konsol Key Management Service lama. Di panel navigasi sebelah kiri, klik Migration Tool.

2. Jika tombol Migrate tersedia, berarti terdapat kunci atau kredensial yang perlu dimigrasikan di wilayah saat ini.

   Penting

   Data ditampilkan berdasarkan wilayah. Pastikan untuk memeriksa data di semua wilayah agar tidak melewatkan sumber daya apa pun.

   

3. Klik angka pada kolom Unmigrated Keys, Migrated Keys, Unmigrated Credentials, dan Migrated Credentials untuk melihat ID kunci dan nama kredensial tertentu.

2. Prosedur migrasi

3. Operasi pasca-migrasi

1. Masuk ke konsol baru untuk melihat dan mengonfirmasi sumber daya yang dimigrasikan.

   • Kunci layanan

     1. Buka halaman Key Management dan pilih wilayah dari bilah menu atas.

     2. Klik tab Default Keys. Verifikasi bahwa kunci layanan Anda tercantum dan kolom Key Usage diatur ke Service Key.

   • Kunci master pelanggan

     1. Buka halaman Key Management dan pilih wilayah dari bilah menu atas.

     2. Klik tab Customer Master Keys dan verifikasi bahwa kunci master pelanggan yang dimigrasikan ditampilkan.

   • Kredensial

     1. Buka halaman Credential Management dan pilih wilayah dari bilah menu atas.

     2. Pilih instans KMS dan konfirmasi bahwa kredensial yang dimigrasikan tercantum.

2. Jika Anda menggunakan Terraform untuk mengelola sumber daya KMS, Anda harus memodifikasi konfigurasi Terraform. Untuk informasi selengkapnya, lihat Modify configurations after migration in a Terraform scenario.

4. Pemantauan migrasi

Untuk memastikan migrasi kunci berjalan lancar, dapat diamati, dan dapat dilacak, Anda harus memantau gerbang bersama dan gerbang khusus sebelum, selama, dan setelah migrasi. Anda dapat menggunakan CloudMonitor, Simple Log Service (SLS), dan ActionTrail untuk pemantauan komprehensif. Bagian berikut menjelaskan poin pengamatan utama dan tindakan yang direkomendasikan.

1. Sebelum migrasi: Amati dasbor gerbang bersama

   Sebelum migrasi kunci selesai dan sebelum Anda mengalihkan Endpoint klien, semua permintaan KMS masih diproses oleh gerbang bersama. Pada tahap ini, fokuslah pada stabilitas dan kinerja gerbang bersama.

   • Tujuan pengamatan: Pastikan migrasi tidak menyebabkan beban abnormal atau kesalahan pada gerbang bersama.

   • Metrik yang diamati:

     • Latensi permintaan: Periksa adanya peningkatan signifikan.

     • Distribusi kode kesalahan (seperti 4xx dan 5xx): Pastikan tidak ada lonjakan mendadak kesalahan abnormal.

     • Tren QPS/TPS: Bandingkan lalu lintas sebelum dan sesudah migrasi untuk memastikan konsistensi. Hal ini membantu mencegah lonjakan permintaan atau gangguan akibat operasi yang salah.

   • Cara melihat:

     • Metode 1: Masuk ke konsol baru. Di halaman Ikhtisar, periksa metrik seperti latensi permintaan dan kode kesalahan pada dasbor Shared Gateway.

     • Metode 2: Masuk ke konsol CloudMonitor. Di bagian Product Monitoring, cari Key Management Service (KMS) untuk melihat dasbor Shared Gateway.

   Catatan

   Catat metrik garis dasar sebelum migrasi sebagai referensi perbandingan.

2. Setelah migrasi: Amati dasbor gerbang bersama dan gerbang khusus secara bersamaan

   • Sebelum mengalihkan Endpoint: Lanjutkan mengamati gerbang bersama. Meskipun kunci telah dimigrasikan ke instans khusus, permintaan masih dialihkan melalui gerbang bersama hingga Anda mengalihkan Endpoint klien. Gerbang bersama meneruskan permintaan tersebut secara transparan ke instans khusus di backend.

   • Setelah mengalihkan Endpoint: Amati gerbang bersama dan gerbang khusus secara bersamaan. Setelah klien menyelesaikan pengalihan Endpoint, permintaan langsung mengakses instans khusus melalui gerbang khusus. Pada titik ini, Anda harus memantau kedua gerbang tersebut:

     Tipe Gateway	Poin pengamatan utama	Cara melihat
     Gerbang khusus	Kode kesalahan Perubahan latensi permintaan Apakah QPS memenuhi ekspektasi	CloudMonitor: Dasbor gerbang khusus KMS
     Gerbang bersama	Apakah permintaan dari layanan asli telah sepenuhnya dialihkan Apakah masih ada permintaan tersisa atau panggilan abnormal	Amati dasbor gerbang bersama untuk wilayah yang sesuai

     Catatan

     Kriteria untuk mengidentifikasi anomali:

     • Jika gerbang khusus melaporkan banyak kesalahan throttling, Anda mungkin perlu menyesuaikan tipe instans atau kebijakan throttling.

     • Jika gerbang bersama masih menerima permintaan dengan frekuensi tinggi, berarti beberapa klien belum menyelesaikan pengalihan Endpoint. Anda harus menyelidiki masalah tersebut.

3. Pengamatan tingkat log: Analisis log akses terperinci menggunakan SLS

   Untuk mencapai pelacakan permintaan yang lebih rinci dan diagnosis masalah, aktifkan fitur pengumpulan log berikut:

   • Log akses gerbang khusus:

     • Anda dapat membeli layanan tambahan analisis log untuk gerbang khusus guna mengirimkan log secara otomatis ke Simple Log Service (SLS).

     • Anda dapat melakukan kueri dan menganalisis log berdasarkan bidang-bidang seperti ID kunci, akun Alibaba Cloud, operasi API, dan kode status tanggapan.

   • Log akses terperinci gerbang bersama:

     • Aktifkan ActionTrail dan kirimkan jejak event ke Logstore SLS yang ditentukan.

     • Analisis perilaku permintaan tertentu dengan melakukan kueri berdasarkan kondisi-kondisi seperti EventName = "Decrypt" dan ResourceType = "KMS".

     • Gunakan bidang ErrorCode untuk menentukan penyebab kegagalan, seperti izin yang tidak mencukupi atau kunci yang tidak ada.

4. Strategi pemantauan yang direkomendasikan

   Fase	Fokus pemantauan	Alat
   Sebelum migrasi	Stabilitas gerbang bersama	Dasbor CloudMonitor
   Selama alih bencana	Tingkat keberhasilan permintaan, perubahan mendadak pada latensi	Pemantauan real-time + peringatan SLS
   Setelah migrasi	Status kesehatan gerbang khusus	Dasbor gerbang khusus + log SLS
   Sepanjang proses	Tren kode kesalahan abnormal	ActionTrail + analisis agregasi SLS