Penerapan Cepat dengan Mengkloning Instans - Server Load Balancer

Dalam skenario seperti penerapan lingkungan yang cepat, pemulihan bencana, dan migrasi konfigurasi, gunakan fitur kloning instans Application Load Balancer (ALB) untuk membuat instans baru yang identik atau mirip dengan instans sumber secara cepat, sehingga meningkatkan efisiensi penerapan dan mengurangi kompleksitas operasional.

Kloning instans ALB

Fitur kloning instans mereplikasi konfigurasi instans ALB yang sudah ada, termasuk komponen utama seperti listeners, server groups, forwarding rules, dan health checks. Hal ini menghindari proses rekonfigurasi manual yang membosankan dan memastikan bahwa instans baru memiliki konfigurasi yang identik atau mirip dengan instans sumber. Fitur ini sangat berguna untuk pemulihan bencana dan migrasi konfigurasi.

Fitur utama

Replikasi cepat: Kloning instans ALB yang sudah ada hanya dalam satu klik melalui proses otomatis yang didukung oleh Resource Orchestration Service (ROS). Proses cepat ini meningkatkan efisiensi penerapan dan mengurangi kompleksitas operasional.
Konsistensi konfigurasi: Memastikan instans baru memiliki konfigurasi yang identik atau mirip dengan instans sumber, sehingga mencegah kesalahan konfigurasi.
Penerapan fleksibel: Terapkan instans hasil kloning di wilayah atau zona berbeda untuk kebutuhan kompleks seperti ekspansi bisnis multi-wilayah dan failover pemulihan bencana.

Kasus penggunaan

Migrasi lingkungan: Kloning konfigurasi lingkungan pengujian ke lingkungan pra-produksi atau produksi untuk memastikan konsistensi lintas lingkungan dan mempercepat rilis fitur.
Pemulihan bencana: Saat terjadi kegagalan layanan, gunakan kloning instans untuk segera menerapkan sumber daya load balancing cadangan, sehingga meningkatkan kelangsungan bisnis dan ketersediaan tinggi.
Migrasi konfigurasi: Migrasikan konfigurasi instans yang sudah ada ke instans baru, misalnya untuk peningkatan versi atau penyesuaian arsitektur, agar tidak perlu melakukan konfigurasi manual berulang.

Batasan

Instans ALB tujuan dan instans ALB sumber harus memiliki edisi yang sama.
Instans ALB Ingress tidak dapat dikloning.
Instans ALB dengan proteksi modifikasi yang diaktifkan tidak dapat dikloning.
Jika instans ALB sumber ditambahkan ke instans Internet Shared Bandwidth, instans ALB hasil kloning tidak akan ditambahkan secara otomatis ke instans Internet Shared Bandwidth tersebut. Anda dapat secara manual menambahkan instans tersebut pada halaman detailnya.
Jika Anda mengkloning instans ALB non-upgrade, instans ALB upgrade akan dibuat secara default. Untuk informasi lebih lanjut, lihat Perbedaan antara instans ALB non-upgrade dan upgrade.

Contoh

Sebuah perusahaan menerapkan fitur baru di lingkungan pengujian dan menggunakan instans ALB untuk load balancing. Instans ALB dikonfigurasi dengan aturan pengalihan untuk mengarahkan permintaan HTTP ke HTTPS dan menggunakan nama domain kustom untuk menyediakan layanan pengujian. Saat klien pengujian mengakses nama domain www.example.com, DNS melakukan resolusi nama domain tersebut ke instans ALB berdasarkan Rekaman CNAME. Instans ALB kemudian meneruskan trafik ke ECS01 dan ECS02 untuk diproses berdasarkan aturan pengalihan.

Setelah fitur tersebut lolos pengujian penerimaan, Anda harus memigrasikan konfigurasi instans ALB ke lingkungan produksi. Konfigurasi manual instans ALB memakan waktu lama dan dapat menyebabkan ketidakkonsistenan konfigurasi yang berdampak pada operasi bisnis, terutama di lingkungan produksi dengan trafik tinggi.

Untuk mengatasi masalah ini, perusahaan memutuskan menggunakan fitur kloning instans untuk mereplikasi konfigurasi ALB dari lingkungan pengujian ke lingkungan produksi secara cepat. Dengan menggunakan fitur ini, perusahaan berhasil menerapkan instans ALB di lingkungan produksi dengan cepat, memastikan peluncuran dan operasi stabil fitur baru.

Prasyarat

Instans ALB sumber harus dikonfigurasi dengan listeners, server backend, dan Rekaman CNAME. Instans tersebut juga harus dapat diakses untuk pengujian melalui nama domain kustom www.example.com. Untuk informasi lebih lanjut, lihat Gunakan ALB untuk menyeimbangkan beban layanan IPv4.
- Instans ALB sumber memiliki listener HTTP dan listener HTTPS. Listener HTTP dikonfigurasi dengan aturan pengalihan untuk mengarahkan permintaan HTTP ke HTTPS.
- Layanan diterapkan pada server backend ECS01 dan ECS02 dari instans ALB sumber.
  Dokumen ini menggunakan Alibaba Cloud Linux 3 sebagai sistem operasi dan menggunakan Nginx untuk mengonfigurasi layanan HTTP 80.
  Contoh: Terapkan layanan pengujian pada ECS01
```
yum install -y nginx
systemctl start nginx.service
cd /usr/share/nginx/html/
echo "Hello World ! This is ECS01." > index.html
```
Siapkan server backend untuk instans ALB tujuan hasil kloning jika diperlukan:
- Jika instans ALB tujuan berada di Virtual Private Cloud (VPC) yang sama dengan instans ALB sumber, server backend ECS01 dan ECS02 dari instans ALB sumber juga dapat digunakan sebagai server backend untuk instans ALB tujuan.
- Jika instans ALB tujuan tidak berada di Virtual Private Cloud (VPC) yang sama dengan instans ALB sumber, siapkan server backend ECS03 dan ECS04 di VPC tujuan dan terapkan layanan pada server tersebut.
Siapkan server untuk mensimulasikan klien: ECS-A digunakan untuk menguji trafik sebelum migrasi, dan ECS-B digunakan untuk memverifikasi akses trafik selama migrasi. Kedua server harus memiliki akses jaringan publik. Dokumen ini menggunakan Alibaba Cloud Linux 3 sebagai sistem operasi.
Jika Anda sudah memiliki server pengujian, Anda tidak perlu membuat ECS-A dan ECS-B.

Prosedur

Langkah 1: Kloning instans ALB sumber

Pada bilah navigasi atas Konsol ALB, pilih wilayah instans ALB sumber.
Pada halaman Instances, temukan instans yang akan dikloning. Pada kolom Actions, pilih > Clone Instance.
Pada kotak dialog Clone Instance, konfigurasikan parameter untuk instans ALB tujuan, lalu klik Next.
Secara default, parameter instans ALB tujuan sama dengan instans ALB sumber. Pada contoh ini, ubah Region for the Clone dari Jerman (Frankfurt) menjadi AS (Silicon Valley), ubah VPC dari VPC1 default ke VPC2 tujuan, serta pilih zona dan vSwitch tujuan yang sesuai. Anda dapat mempertahankan nilai default untuk parameter lainnya atau mengubahnya sesuai kebutuhan.
Jika instans hasil kloning bertipe jaringan publik dan wilayah tujuan merupakan wilayah tempat ALB mendukung Anycast EIP, Anda juga harus memilih IP Type (EIP atau Anycast EIP) dan mengalokasikan alamat IP publik tipe yang sesuai di zona yang dipilih.
Pada langkah Preview and Confirm, konfirmasi informasi dan biaya untuk instans ALB tujuan, lalu klik Clone.
Konfirmasi hasil kloning.
Saat kloning selesai, Anda dapat membandingkan data bisnis instans ALB tujuan hasil kloning dengan instans ALB sumber.
Kloning instans disediakan oleh Resource Orchestration Service (ROS). Selama proses kloning, Anda dapat login ke Konsol ROS untuk melihat progresnya.
Tambahkan server backend ECS03 dan ECS04 ke server group instans ALB tujuan.

Langkah 2: Uji trafik

Untuk memastikan instans ALB tujuan dapat terhubung ke layanan backend, jika layanan backend Anda memiliki kebijakan akses seperti iptables atau perangkat lunak keamanan pihak ketiga lainnya, tambahkan Blok CIDR vSwitch instans ALB ke daftar izin (allowlist).

Lakukan koneksi jarak jauh ke server pengujian ECS-A.
Jalankan perintah berikut untuk mengubah file hosts.
```
sudo vi /etc/hosts
```
Pada file hosts, tambahkan Elastic IP Address (EIP) dan nama domain instans ALB tujuan. Setelah mengubah file, simpan perubahan dan keluar.
```
47.251.XX.XX www.example.com
```
Jalankan perintah berikut untuk menguji pengalihan trafik instans ALB tujuan.
```
curl -v -L www.example.com
```
Output berikut dikembalikan, yang menunjukkan bahwa permintaan HTTP berhasil dialihkan ke HTTPS dan server yang merespons adalah ECS03.
Jalankan perintah lagi. Server yang merespons berubah menjadi ECS04.

Langkah 3: Migrasikan trafik ke instans tujuan

Peringatan

Sebelum migrasi trafik, bandingkan konfigurasi aturan pengalihan instans ALB sumber dan tujuan untuk memastikan keduanya menyediakan kemampuan yang identik. Pastikan semua konfigurasi telah lolos pengujian penerimaan untuk menghindari dampak tak terduga pada bisnis selama migrasi.
Lakukan migrasi trafik ALB selama jam sepi.

Rekaman CNAME dikonfigurasi untuk instans ALB sumber. Setelah Anda memverifikasi konfigurasi instans ALB tujuan, Anda dapat memigrasikan trafik dari instans ALB sumber ke instans ALB tujuan sesuai kebutuhan.

Dokumen ini menggunakan fitur kebijakan perutean berbobot dari Alibaba Cloud DNS sebagai contoh. Dengan menyesuaikan rasio bobot secara dinamis antara instans ALB sumber dan tujuan, trafik DNS secara bertahap dimigrasikan dari instans sumber ke instans baru.

Bagian 1: Tambahkan Rekaman CNAME

Pada panel navigasi kiri, pilih ALB > Instances. Pada halaman Instances, salin nama DNS instans ALB yang telah dibuat.
Ikuti langkah-langkah berikut untuk menambahkan Rekaman CNAME.
1. Pada Konsol Alibaba Cloud DNS, temukan nama domain tujuan dan klik Settings pada kolom Actions.
  Untuk domain yang tidak terdaftar di Alibaba Cloud, Anda harus terlebih dahulu menambahkan domain ke Konsol Alibaba Cloud DNS sebelum dapat mengonfigurasi pengaturan DNS.
2. Pada halaman Settings, klik Add Record, konfigurasikan Rekaman CNAME, lalu klik OK.
  Pada contoh ini, Record Type diatur ke CNAME, dan Record Value diatur ke nama DNS instans ALB tujuan. Anda dapat mempertahankan nilai default untuk parameter rekaman DNS lainnya atau mengubahnya sesuai kebutuhan.
3. Pada kotak dialog Change Resource Record Confirmation, konfirmasi informasi DNS dan klik OK.

Bagian 2: Atur bobot dan mulai rilis canary

Pada halaman Settings, temukan Rekaman CNAME yang ditambahkan di Bagian 1. Klik panah tarik-turun di samping Modify, lalu klik Edit Record Set.
Pada panel Edit Record, di bawah Record Values, atur bobot untuk rekaman DNS instans ALB sumber dan tujuan. Atur bobot rekaman DNS instans ALB sumber ke 100 dan bobot rekaman DNS instans ALB tujuan ke 0.
Anda hanya dapat mengaktifkan kebijakan perutean berbobot jika terdapat beberapa rekaman A, CNAME, atau AAAA untuk hostname dan jalur DNS yang sama di bawah nama domain tersebut.
Jika Anda tidak mengamati dampak pada bisnis, secara bertahap kurangi bobot rekaman DNS instans ALB sumber dan tingkatkan bobot rekaman DNS instans ALB tujuan.
Lakukan koneksi jarak jauh ke server pengujian ECS-B dan jalankan perintah dig beberapa kali untuk memverifikasi efek migrasi trafik.
```
dig www.example.com
```
Gambar berikut menunjukkan outputnya. Dengan menjalankan perintah beberapa kali, Anda dapat mengamati bahwa permintaan didistribusikan ke instans ALB sumber atau tujuan berdasarkan bobot masing-masing.

(Opsional) Bagian 3: Selesaikan migrasi trafik

Berdasarkan hasil verifikasi migrasi trafik, secara bertahap kurangi bobot rekaman DNS instans ALB sumber hingga 0 dan tingkatkan bobot rekaman DNS instans ALB tujuan hingga 100. Hal ini menyelesaikan migrasi trafik dari instans ALB sumber ke instans ALB tujuan.

Setelah semua koneksi persisten ke instans ALB sumber ditutup dan tidak ada trafik baru yang diarahkan ke instans tersebut, Anda dapat memantau instans tersebut selama periode tertentu, lalu release instans tersebut sesuai skenario bisnis Anda.

Dokumen terkait

Setelah mengkloning instans ALB, Anda dapat menggunakan log akses ALB untuk memantau beban pada instans tujuan dan memecahkan masalah terkait.
Jika Anda perlu memigrasikan pendengar CLB Layer-7 ke ALB:
- Migrasi satu-klik pendengar CLB Layer-7 ke ALB
- Migrasi manual pendengar CLB Layer-7 ke ALB
Anda dapat memilih kebijakan manajemen trafik DNS sesuai kebutuhan:
- kebijakan perutean berbobot: Mendistribusikan trafik DNS secara round-robin berbobot berdasarkan bobot yang dikonfigurasi, mengembalikan nilai rekaman yang sesuai saat menerima permintaan kueri.
- Resolusi DNS Cerdas: Mengembalikan hasil DNS berdasarkan lokasi geografis dan ISP pengguna untuk mengurangi latensi resolusi dan meningkatkan kecepatan akses website. Jalur yang didukung mencakup ISP, ISP/provinsi, luar daratan Tiongkok, benua, dan jalur kustom.
- Global Traffic Manager (GTM): Menerapkan akses terdekat, load balancing untuk trafik konkurensi tinggi, dan pengalihan trafik berdasarkan hasil pemeriksaan kesehatan. Hal ini memungkinkan Anda membangun layanan aktif-aktif dan pemulihan bencana lintas wilayah secara fleksibel.