All Products
Search
Document Center

Alibaba Cloud Service Mesh:Pemulihan bencana tingkat wilayah dengan ASM dan GTM

Last Updated:Jun 21, 2026

Kegagalan tingkat wilayah merupakan gangguan ekstrem yang dapat mengganggu layanan cloud Anda. Saat hal ini terjadi, layanan di salah satu zona ketersediaannya berisiko mengalami kegagalan koneksi, kehilangan data, dan ketidaktersediaan workload. Service Mesh (ASM) memungkinkan Anda men-deploy gerbang masuk ASM di kluster Kubernetes atau Elastic Container Instance (ECI) sebagai titik masuk trafik terpadu untuk aplikasi Anda. Setiap kluster memiliki alamat IP independen untuk gerbang masuknya. Ketika satu wilayah mengalami kegagalan, alamat IP yang bermasalah akan dihapus, dan seluruh trafik dialihkan ke wilayah yang sehat untuk pemulihan bencana tingkat wilayah.

Arsitektur pemulihan bencana

Bagian ini menjelaskan arsitektur pemulihan bencana dua wilayah dan dua kluster untuk menangani kegagalan tingkat wilayah:

  1. Buat arsitektur lapisan kontrol multi-master dengan men-deploy satu kluster Kubernetes di masing-masing dari dua wilayah tersebut. Deploy layanan cloud-native yang identik di kedua kluster. Layanan tersebut saling memanggil menggunakan nama domain kluster Kubernetes.

    Catatan

    Lapisan kontrol multi-master memastikan latensi push untuk proxy mesh di setiap wilayah dapat diprediksi dan siap produksi. Arsitektur ini juga menyediakan ketersediaan tinggi lapisan kontrol untuk pemulihan bencana saat terjadi kegagalan tingkat wilayah.

  2. Deploy gerbang ASM di setiap kluster dan konfigurasikan agar mengekspos alamat IP publik atau nama domain melalui Classic Load Balancer (CLB) atau Network Load Balancer (NLB). Kemudian, gunakan Alibaba Cloud DNS dan Global Traffic Manager (GTM) untuk melakukan resolusi nama domain ke kedua alamat IP tersebut.

  3. Saat terjadi kegagalan tingkat wilayah, layanan di wilayah yang sehat tidak terpengaruh. Global Traffic Manager (GTM) secara otomatis menghapus alamat IP wilayah yang bermasalah dari pool resolusi DNS dan mengarahkan seluruh trafik ke gerbang ASM di wilayah yang sehat.

Selama lonjakan trafik, konfigurasikan fitur-fitur berikut untuk mengoptimalkan pengalihan trafik setelah kegagalan regional:

  1. Aktifkan HPA untuk gerbang ASM agar secara otomatis menambah jumlah instans dan menangani lonjakan trafik.

    Catatan

    Fitur HPA hanya tersedia pada edisi Enterprise dan Ultimate ASM.

  2. Konfigurasikan pembatasan kecepatan untuk gerbang ASM atau layanan kritis di dalam kluster. Fitur pembatasan kecepatan lokal ASM mencegah lonjakan trafik membebani layanan kluster Anda, sehingga menghindari crash layanan di wilayah yang sehat akibat perpindahan trafik besar-besaran.

  3. (Opsional) Konfigurasikan pemantauan metrik dan alert untuk fitur pembatasan kecepatan ASM. Hal ini memungkinkan Anda mengamati event secara real time, mendeteksi kegagalan dengan cepat, dan segera melakukan scaling workload di wilayah yang sehat.

Alur kerja pemulihan bencana

Pemulihan bencana lintas wilayah didukung untuk semua jenis kluster. Tutorial ini menggunakan kluster ACK yang dikelola untuk menunjukkan proses pembuatan kluster dan instans ASM, menyelesaikan konfigurasi pemulihan bencana, serta menjalankan simulasi kegagalan.

Konfigurasi pemulihan bencana

Tutorial ini menggunakan gerbang masuk tipe CLB sebagai contoh. Untuk informasi lebih lanjut tentang cara mengintegrasikan gerbang masuk tipe NLB dengan GTM, lihat Menghubungkan nama domain bisnis ke GTM.

Langkah 1: Siapkan lapisan kontrol multi-master

  1. Di dua wilayah berbeda, buat dua kluster bernama cluster-1 dan cluster-2, lalu aktifkan Expose API server with EIP. Untuk informasi lebih lanjut, lihat Membuat kluster ACK yang dikelola.

  2. Di wilayah yang sama dengan kluster tersebut, buat dua instans Service Mesh, yaitu mesh-1 dan mesh-2. Tambahkan cluster-1 dan cluster-2 ke instans ASM masing-masing untuk membangun service mesh dengan lapisan kontrol multi-master. Untuk informasi lebih lanjut, lihat Langkah 1 dan Langkah 2 dalam Menerapkan pemulihan bencana multi-kluster menggunakan arsitektur lapisan kontrol multi-master ASM.

Langkah 2: Deploy gerbang masuk dan aplikasi

  1. Di kedua instans ASM, buat gerbang masuk ASM bernama ingressgateway. Untuk informasi lebih lanjut, lihat Membuat gerbang masuk.

  2. Di kluster cluster-1 dan cluster-2, deploy aplikasi sampel Bookinfo. Untuk informasi lebih lanjut, lihat Men-deploy aplikasi di kluster yang terkait dengan instans ASM.

  3. Di kedua instans ASM, buat resource Gateway dan layanan virtual untuk menggunakan gerbang ASM sebagai titik masuk trafik bagi aplikasi Bookinfo. Untuk informasi lebih lanjut, lihat Menggunakan resource Istio untuk mengarahkan trafik berdasarkan versi.

  4. Aktifkan retensi trafik lokal-kluster secara global untuk kedua instans ASM. Untuk informasi lebih lanjut, lihat Mengaktifkan fitur retensi trafik lokal-kluster di tingkat global.

    Catatan

    Dalam skenario pemulihan bencana tingkat wilayah, trafik harus tetap berada dalam satu kluster saja. Secara default, jika dua atau lebih kluster Kubernetes ditambahkan ke instans service mesh yang sama, mekanisme load balancing mesh dapat mengarahkan panggilan ke layanan di kluster pasangan. Dengan mengaktifkan retensi trafik lokal-kluster, permintaan untuk suatu layanan tetap berada di dalam klusternya sendiri dan mencegah panggilan lintas kluster.

(Opsional) Langkah 3: Verifikasi status layanan

  1. Dapatkan alamat IP publik dari kedua gerbang ASM. Anda akan menggunakan alamat ini untuk memverifikasi status layanan dan mengonfigurasi GTM nanti. Untuk informasi lebih lanjut, lihat Mendapatkan alamat gerbang masuk.

  2. Gunakan file kubeconfig untuk kluster cluster-1 dan cluster-2 untuk melihat nama Pod layanan reviews.

    kubectl get pod| grep reviews

    Output yang diharapkan:

    reviews-v1-5d99dxxxxx-xxxxx       2/2     Running   0          3d17h
    reviews-v2-69fbbxxxxx-xxxxx       2/2     Running   0          3d17h
    reviews-v3-8c44xxxxx-xxxxx        2/2     Running   0          3d17h
  3. Di bilah alamat browser Anda, masukkan http://{IP_address_of_mesh-1_ingress_gateway}/productpage dan http://{IP_address_of_mesh-2_ingress_gateway}/productpage secara bergantian. Refresh halaman sebanyak 10 kali untuk mengakses aplikasi Bookinfo.

    Setiap kali Anda merefresh halaman, versi berbeda dari layanan reviews (v1, v2, atau v3) akan ditampilkan. Ketiga versi layanan reviews di kedua kluster sesuai dengan nama Pod pada output langkah sebelumnya. Hal ini menunjukkan bahwa layanan berjalan sesuai harapan dan fitur retensi trafik lokal-kluster berfungsi dengan baik.

    Versi layanan tersebut memiliki tampilan yang berbeda: versi reviews-v1 tidak menampilkan rating bintang, versi reviews-v2 menampilkan rating bintang hitam, dan versi reviews-v3 menampilkan rating bintang merah.

Langkah 4: Konfigurasi GTM

Gunakan dua alamat IP publik yang telah Anda peroleh sebagai alamat IP masuk trafik untuk aplikasi dan konfigurasikan load balancing aktif-aktif serta pemulihan bencana di GTM. Untuk informasi lebih lanjut, lihat Cara GTM menerapkan load balancing aktif-aktif dan pemulihan bencana.

Setelah konfigurasi selesai, pengaturannya akan mirip dengan gambar berikut:

image

(Opsional) Langkah 5: Konfigurasi pembatasan kecepatan lokal dan observabilitas

  1. Gunakan konten YAML berikut untuk mengonfigurasi aturan pembatasan kecepatan lokal untuk mesh-1 dan mesh-2. Untuk informasi lebih lanjut, lihat Mengonfigurasi pembatasan kecepatan lokal untuk gerbang masuk.

    apiVersion: istio.alibabacloud.com/v1beta1
    kind: ASMLocalRateLimiter
    metadata:
      name: ingressgateway
      namespace: istio-system
    spec:
      configs:
        - limit:
            fill_interval:
              seconds: 1
            quota: 100
          match:
            vhost:
              name: '*'
              port: 80
              route:
                name_match: gw-to-productage
      isGateway: true
      workloadSelector:
        labels:
          istio: ingressgateway
  2. Konfigurasikan pengumpulan metrik dan alert untuk pembatasan kecepatan lokal di kedua instans ASM. Untuk informasi lebih lanjut, lihat Mengonfigurasi pengumpulan metrik dan alert untuk pembatasan kecepatan lokal.

Simulasi kegagalan

Simulasi ini menggunakan tool fortio untuk menjalankan uji beban pada aplikasi sampel, mensimulasikan akses dari pengguna eksternal. Selama uji beban berlangsung, hapus workload gerbang masuk secara manual untuk mensimulasikan kegagalan regional dan amati failover pemulihan bencana.

  1. Jalankan perintah berikut untuk memulai uji beban selama lima menit pada aplikasi sampel. Ganti nama domain dalam perintah dengan nama domain yang telah Anda konfigurasi di GTM.

    fortio load -jitter=False  -c 1 -qps 100 -t 300s -keepalive=False -a http://{your_domain_name}/productpage
  2. Selama uji beban berjalan, simulasi kegagalan regional di cluster-2.

    1. Masuk ke Konsol ACK. Di panel navigasi kiri, klik Clusters.

    2. Di halaman Clusters, klik nama kluster Anda. Di panel navigasi kiri, klik Workloads > Deployments.

    3. Dari daftar drop-down Namespace, pilih istio-system.

    4. Di daftar workload, temukan istio-ingressgateway. Di kolom Actions, klik More > Delete.

  3. Tunggu hingga uji beban selesai. Output yang diharapkan adalah sebagai berikut:

    # range, mid point, percentile, count
    >= -261.054 <= -0.0693516 , -130.561 , 100.00, 3899
    # target 50% -130.595
    WARNING 100.00% of sleep were falling behind
    Aggregated Function Time : count 3899 avg 0.076910055 +/- 0.02867 min 0.062074583 max 1.079674 sum 299.872304
    # range, mid point, percentile, count
    >= 0.0620746 <= 0.07 , 0.0660373 , 19.34, 754
    > 0.07 <= 0.08 , 0.075 , 71.94, 2051
    > 0.08 <= 0.09 , 0.085 , 96.08, 941
    > 0.09 <= 0.1 , 0.095 , 99.23, 123
    > 0.1 <= 0.12 , 0.11 , 99.62, 15
    > 0.12 <= 0.14 , 0.13 , 99.82, 8
    > 0.14 <= 0.16 , 0.15 , 99.92, 4
    > 1 <= 1.07967 , 1.03984 , 100.00, 3
    # target 50% 0.0758289
    # target 75% 0.0812673
    # target 90% 0.0874825
    # target 99% 0.0992691
    # target 99.9% 0.155505
    Error cases : count 527 avg 0.074144883 +/- 0.07572 min 0.062074583 max 1.079674 sum 39.0743532
    # range, mid point, percentile, count
    >= 0.0620746 <= 0.07 , 0.0660373 , 82.54, 435
    > 0.07 <= 0.08 , 0.075 , 96.58, 74
    > 0.08 <= 0.09 , 0.085 , 99.05, 13
    > 0.09 <= 0.1 , 0.095 , 99.24, 1
    > 0.12 <= 0.14 , 0.13 , 99.43, 1
    > 1 <= 1.07967 , 1.03984 , 100.00, 3
    # target 50% 0.0668682
    # target 75% 0.0692741
    # target 90% 0.0753108
    # target 99% 0.0897923
    # target 99.9% 1.06568
    # Socket and IP used for each connection:
    [0] 3900 socket used, resolved to [39.XXX.XXX.160:80 (3373), 106.XXX.XXX.73:80 (527)], connection timing : count 3900 avg 0.038202153 +/- 0.03097 min 0.027057 max 1.07747175 sum 148.988395
    Connection time histogram (s) : count 3900 avg 0.038202153 +/- 0.03097 min 0.027057 max 1.07747175 sum 148.988395
    # range, mid point, percentile, count
    >= 0.027057 <= 0.03 , 0.0285285 , 13.28, 518
    > 0.03 <= 0.035 , 0.0325 , 62.79, 1931
    > 0.035 <= 0.04 , 0.0375 , 83.95, 825
    > 0.04 <= 0.045 , 0.0425 , 86.13, 85
    > 0.045 <= 0.05 , 0.0475 , 86.18, 2
    > 0.05 <= 0.06 , 0.055 , 86.28, 4
    > 0.06 <= 0.07 , 0.065 , 98.03, 458
    > 0.07 <= 0.08 , 0.075 , 99.77, 68
    > 0.08 <= 0.09 , 0.085 , 99.92, 6
    > 1 <= 1.07747 , 1.03874 , 100.00, 3
    # target 50% 0.0337079
    # target 75% 0.0378848
    # target 90% 0.0631659
    # target 99% 0.0755882
    # target 99.9% 0.0885
    Sockets used: 3900 (for perfect keepalive, would be 1)
    Uniform: false, Jitter: false, Catchup allowed: true
    IP addresses distribution:
    39.XXX.XXX.160:80: 3373
    106.XXX.XXX.73:80: 527
    Code  -1 : 527 (13.5 %)
    Code 200 : 3372 (86.5 %)
    Response Header Sizes : count 3899 avg 178.19851 +/- 70.45 min 0 max 207 sum 694796
    Response Body/Total Sizes : count 3899 avg 4477.7081 +/- 1822 min 0 max 5501 sum 17458584
    All done 3899 calls (plus 1 warmup) 76.910 ms avg, 13.0 qps

    Output tersebut menunjukkan bahwa meskipun beberapa permintaan gagal selama simulasi kegagalan regional, sebagian besar permintaan berhasil. Hal ini membuktikan bahwa kombinasi ASM dan GTM secara efektif menyediakan pemulihan bencana untuk kegagalan regional.

  4. Di konsol GTM, periksa status nama domain akses. Alamat IP untuk cluster-2 ditampilkan sebagai tidak tersedia.

    image

    Anda juga dapat mengonfigurasi alert untuk diberi tahu saat alamat IP menjadi tidak tersedia, sehingga Anda dapat menghapusnya secara manual. Untuk informasi lebih lanjut, lihat Mengonfigurasi alert.