Bagikan melalui

Ketersediaan tinggi dan penyeimbangan beban konektor dan aplikasi jaringan privat Anda

  • Artikel

Artikel ini menjelaskan cara kerja distribusi lalu lintas dengan penyebaran proksi aplikasi Anda. Pelajari bagaimana lalu lintas didistribusikan di antara pengguna dan konektor, bersama dengan tips untuk mengoptimalkan performa konektor. Pelajari bagaimana arus lalu lintas antara konektor dan server aplikasi back-end, dengan rekomendasi untuk penyeimbangan beban di antara beberapa server back-end.

Distribusi lalu lintas di seluruh konektor

Konektor membangun koneksi mereka berdasarkan prinsip-prinsip untuk ketersediaan tinggi. Tidak ada jaminan bahwa lalu lintas didistribusikan secara merata di seluruh konektor dan tidak ada afinitas sesi. Namun, penggunaan bervariasi dan permintaan dikirim secara acak ke instans layanan proksi aplikasi. Akibatnya, lalu lintas biasanya didistribusikan hampir merata di seluruh konektor. Diagram dan langkah-langkah menggambarkan bagaimana koneksi dibuat antara pengguna dan konektor.

Diagram memperlihatkan koneksi antara pengguna dan konektor

  1. Pengguna di perangkat klien mencoba mengakses aplikasi lokal yang diterbitkan melalui proksi aplikasi.
  2. Permintaan melewati Azure Load Balancer untuk menentukan instans layanan proksi aplikasi mana yang harus mengambil permintaan. Terdapat puluhan instans yang tersedia untuk menerima permintaan untuk semua lalu lintas di wilayah tersebut. Metode ini membantu mendistribusikan lalu lintas secara merata di seluruh instans layanan.
  3. Permintaan dikirim ke Service Bus.
  4. Service Bus memberi sinyal ke konektor yang tersedia. Konektor kemudian mengambil permintaan dari Service Bus.
    • Pada langkah 2, permintaan masuk ke instans layanan proksi aplikasi yang berbeda, sehingga koneksi lebih mungkin dibuat dengan konektor yang berbeda. Akibatnya, konektor hampir merata digunakan dalam grup.
  5. Konektor meneruskan permintaan ke server back-end aplikasi. Kemudian aplikasi mengirim respons kembali ke konektor.
  6. Konektor menyelesaikan respons dengan membuka koneksi keluar ke instans layanan dari mana permintaan datang. Maka sambungan ini segera ditutup. Secara default, setiap konektor dibatasi hingga 200 koneksi keluar bersamaan.
  7. Respons kemudian diteruskan kembali ke klien dari instans layanan.
  8. Permintaan berikutnya dari koneksi yang sama mengulangi langkah-langkahnya.

Aplikasi sering memiliki banyak sumber daya dan membuka beberapa koneksi saat dimuat. Setiap koneksi melewati langkah-langkah untuk dialokasikan ke instans layanan. Jika koneksi tidak dipasangkan dengan konektor, pilih konektor baru yang tersedia.

Praktik terbaik untuk ketersediaan konektor yang tinggi

  • Karena cara lalu lintas didistribusikan di antara konektor untuk ketersediaan tinggi, penting untuk selalu memiliki setidaknya dua konektor dalam kelompok konektor. Tiga konektor lebih disukai untuk menyediakan buffer tambahan di antara konektor. Untuk menentukan jumlah konektor yang Anda butuhkan, ikuti dokumentasi perencanaan kapasitas.

  • Tempatkan konektor pada koneksi keluar yang berbeda untuk menghindari satu titik kegagalan. Jika konektor menggunakan koneksi keluar yang sama, masalah jaringan dengan koneksi akan memengaruhi semua konektor yang menggunakannya.

  • Hindari memaksa konektor untuk memulai ulang saat tersambung ke aplikasi produksi. Melakukannya dapat berdampak negatif pada distribusi lalu lintas di seluruh konektor. Memulai ulang konektor menyebabkan lebih banyak konektor tidak tersedia dan memaksa koneksi ke konektor yang tersedia yang tersisa. Hasilnya adalah penggunaan konektor yang tidak merata pada awalnya.

  • Hindari semua bentuk inspeksi sebaris pada komunikasi Keamanan Lapisan Transportasi (TLS) keluar antara konektor dan Azure. Jenis inspeksi inline ini menyebabkan degradasi pada aliran komunikasi.

  • Pastikan agar pembaruan otomatis tetap berjalan untuk konektor Anda. Jika layanan Updater konektor jaringan privat berjalan, konektor Anda akan diperbarui secara otomatis dan menerima peningkatan terbaru. Jika Anda tidak melihat layanan Updater Konektor di server, Anda perlu menginstal ulang konektor untuk mendapatkan pembaruan apa pun.

Arus lalu lintas antara konektor dan server aplikasi back-end

Area kunci lain di mana ketersediaan tinggi adalah faktor adalah koneksi antara konektor dan server back-end. Saat aplikasi diterbitkan melalui proksi aplikasi Microsoft Entra, lalu lintas dari pengguna ke aplikasi mengalir melalui tiga hop:

  1. Pengguna terhubung ke titik akhir publik layanan proksi aplikasi Microsoft Entra di Azure. Koneksi dibuat antara alamat IP klien asal (publik) klien dan alamat IP titik akhir proksi aplikasi.
  2. Konektor jaringan privat menarik permintaan HTTP klien dari Layanan proksi aplikasi.
  3. Konektor jaringan privat terhubung ke aplikasi target. Konektor menggunakan alamat IP sendiri untuk membuat koneksi.

Diagram pengguna yang terhubung ke aplikasi melalui proksi aplikasi

Pertimbangan kolom header X-Forwarded-For

Dalam beberapa situasi (seperti audit, penyeimbangan beban, dan sebagainya), berbagi alamat IP asal klien eksternal dengan lingkungan lokal adalah persyaratan. Untuk mengatasi persyaratan, konektor jaringan privat Microsoft Entra menambahkan bidang header X-Forwarded-For dengan alamat IP klien asal (publik) ke permintaan HTTP. Perangkat jaringan yang sesuai (load balancer, firewall) atau server web atau aplikasi back-end kemudian dapat membaca dan menggunakan informasi.

Praktik terbaik untuk penyeimbangan beban di antara beberapa server aplikasi

Penyeimbangan beban penting ketika grup konektor yang ditetapkan ke aplikasi proksi aplikasi memiliki dua konektor atau lebih. Penyeimbangan beban juga penting saat Anda menjalankan aplikasi web back-end di beberapa server.

Skenario 1: Aplikasi back-end tidak memerlukan persistensi sesi

Skenario paling sederhana adalah di mana aplikasi web back-end tidak memerlukan lengket sesi (kegigihan sesi). Instans aplikasi back-end menangani permintaan pengguna di farm server. Anda dapat menggunakan load balancer lapisan 4 dan mengonfigurasinya tanpa afinitas. Beberapa opsi termasuk Microsoft Network Load Balancing dan Azure Load Balancer atau load balancer dari vendor lain. Atau, konfigurasikan strategi Sistem Nama Domain (DNS) round-robin.

Skenario 2: Aplikasi back-end membutuhkan kegigihan sesi

Dalam skenario ini, aplikasi web back-end membutuhkan ketekunan sesi (kegigihan sesi) selama sesi terautentikasi. Instans aplikasi back-end menangani permintaan pengguna. Permintaan Thee berjalan pada server yang sama di farm server. Skenario ini bisa lebih rumit karena klien biasanya membuat beberapa koneksi ke layanan proksi aplikasi. Permintaan atas koneksi yang berbeda mungkin tiba di konektor dan server yang berbeda di peternakan. Karena setiap konektor menggunakan alamat IP sendiri untuk komunikasi ini, load balancer tidak dapat memastikan lengket sesi berdasarkan alamat IP konektor. Afinitas IP sumber juga tidak dapat digunakan. Berikut adalah beberapa opsi untuk skenario 2:

  • Opsi 1: Mendasarkan kegigihan sesi pada cookie sesi yang ditetapkan oleh load balancer. Opsi ini direkomendasikan karena memungkinkan beban untuk tersebar lebih merata di antara server back-end. Ini membutuhkan load balancer lapisan 7 dengan kemampuan ini dan yang dapat menangani lalu lintas HTTP dan mengakhiri koneksi TLS. Anda dapat menggunakan Azure Application Gateway (Session Affinity) atau load balancer dari vendor lain.

  • Opsi 2: Mendasarkan kegigihan sesi pada kolom header X-Forwarded-For. Opsi ini memerlukan load balancer lapisan 7 dengan kemampuan ini dan yang dapat menangani lalu lintas HTTP dan mengakhiri koneksi TLS.

  • Opsi 3: Konfigurasikan aplikasi back-end agar tidak memerlukan kegigihan sesi.

Untuk memahami persyaratan penyeimbangan beban aplikasi back-end, lihat dokumentasi vendor perangkat lunak Anda.

Langkah berikutnya