Koneksi keluar (Klasik)

  • Artikel

Azure menyediakan konektivitas keluar untuk penyebaran pelanggan melalui beberapa mekanisme yang berbeda. Artikel ini menjelaskan apa skenarionya, kapan skenario tersebut diterapkan, cara kerjanya, dan cara mengelolanya.

Catatan

Artikel ini hanya membahas penyebaran Klasik. Tinjau Koneksi keluar untuk semua skenario penyebaran Resource Manager di Azure.

Penyebaran di Azure dapat berkomunikasi dengan titik akhir di luar Azure di ruang alamat IP publik. Saat instans memulai alur keluar ke tujuan di ruang alamat IP publik, Azure secara dinamis memetakan alamat IP privat ke alamat IP publik. Setelah pemetaan ini dibuat, lalu lintas kembali untuk alur asal keluar ini juga dapat mencapai alamat IP privat tempat alur berasal.

Azure menggunakan terjemahan alamat jaringan sumber (SNAT) untuk melakukan fungsi ini. Saat beberapa alamat IP privat menyamar di belakang satu alamat IP publik, Azure menggunakan terjemahan alamat port (PAT) untuk menyamarkan alamat IP privat. Port Ephemeral digunakan untuk PAT dan dialokasikan sebelumnya berdasarkan ukuran kumpulan.

Ada beberapa skenario keluar. Anda dapat menggabungkan skenario ini sesuai kebutuhan. Tinjau dengan cermat untuk memahami kemampuan, batasan, dan pola saat berlaku untuk model penyebaran dan skenario aplikasi Anda. Tinjau panduan untuk mengelola skenario ini.

Ringkasan skenario

Azure menyediakan tiga metode berbeda untuk mencapai penyebaran Klasik konektivitas keluar. Tidak semua penyebaran Klasik memiliki ketiga skenario yang tersedia untuk mereka:

Skenario Metode Protokol IP Deskripsi Peran Pekerja Web IaaS
1. VM dengan alamat IP Publik Tingkat Instans SNAT, port masquerading tidak digunakan TCP, UDP, ICMP, ESP Azure menggunakan KOMPUTER Virtual yang ditetapkan IP publik. Instans memiliki semua port sementara yang tersedia. Tidak Ya
2. titik akhir publik dengan beban seimbang SNAT dengan port masquerading (PAT) ke titik akhir publik TCP, UDP Azure berbagi titik akhir publik alamat IP publik dengan beberapa titik akhir privat. Azure menggunakan port ephemeral dari titik akhir publik untuk PAT. Ya Ya
3. VM mandiri SNAT dengan port masquerading (PAT) TCP, UDP Azure secara otomatis menunjuk alamat IP publik untuk SNAT, berbagi alamat IP publik ini dengan seluruh penyebaran, dan menggunakan port ephemeral dari alamat IP titik akhir publik untuk PAT. Ini adalah skenario fallback untuk skenario sebelumnya. Kami tidak merekomendasikannya jika Anda memerlukan visibilitas dan kontrol. Ya Ya

Ini adalah subset fungsionalitas koneksi keluar yang tersedia untuk penyebaran Resource Manager di Azure.

Penyebaran yang berbeda di Klasik memiliki fungsionalitas yang berbeda:

Penyebaran klasik Fungsionalitas tersedia
Komputer Virtual skenario 1, 2, atau 3
Peran Pekerja Web hanya skenario 2, 3

Strategi mitigasi juga memiliki perbedaan yang sama.

Algoritma yang digunakan untuk melakukan pra-alokasi port sementara untuk PAT untuk penyebaran klasik sama dengan untuk penyebaran sumber daya Azure Resource Manager.

Skenario 1: VM dengan alamat IP Publik Tingkat Instans

Dalam skenario ini, VM memiliki IP Publik Tingkat Instans (ILPIP) yang ditetapkan untuknya. Sejauh menyangkut koneksi keluar, tidak masalah apakah VM memiliki titik akhir yang seimbang beban atau tidak. Skenario ini lebih diutamakan daripada yang lain. Saat ILPIP digunakan, VM menggunakan ILPIP untuk semua alur keluar.

IP publik yang ditetapkan ke VM adalah hubungan 1:1 (bukan 1:banyak) dan diimplementasikan sebagai NAT 1:1 tanpa status. Port masquerading (PAT) tidak digunakan, dan VM memiliki semua port ephemeral yang tersedia untuk digunakan.

Jika aplikasi Anda memulai banyak alur keluar dan Anda mengalami kelelahan port SNAT, pertimbangkan untuk menetapkan ILPIP untuk mengurangi batasan SNAT. Tinjau Mengelola kelelahan SNAT secara keseluruhan.

Skenario 2: Titik akhir publik dengan beban seimbang

Dalam skenario ini, Peran VM atau Pekerja Web dikaitkan dengan alamat IP publik melalui titik akhir yang seimbang. VM tidak memiliki alamat IP publik yang ditetapkan untuknya.

Saat VM dengan beban seimbang membuat alur keluar, Azure menerjemahkan alamat IP sumber privat dari alur keluar ke alamat IP publik titik akhir publik yang seimbang. Azure menggunakan SNAT untuk melakukan fungsi ini. Azure juga menggunakan PAT untuk menyanggah beberapa alamat IP privat di belakang alamat IP publik.

Port Ephemeral dari frontend alamat IP publik load balancer digunakan untuk membedakan alur individu yang berasal dari VM. SNAT secara dinamis menggunakan port sementara yang telah dialokasikan sebelumnya saat aliran keluar dibuat. Dalam konteks ini, port sementara yang digunakan untuk SNAT disebut port SNAT.

Port SNAT telah dialokasikan sebelumnya seperti yang dijelaskan di bagian Memahami SNAT dan PAT . Mereka adalah sumber daya terbatas yang dapat habis. Penting untuk memahami bagaimana mereka dikonsumsi. Untuk memahami cara merancang konsumsi ini dan mengurangi seperlunya, tinjau Mengelola kelelahan SNAT.

Ketika ada beberapa titik akhir seimbang beban publik , salah satu alamat IP publik ini adalah kandidat untuk alur keluar, dan satu dipilih secara acak.

Skenario 3: Tidak ada alamat IP publik yang terkait

Dalam skenario ini, VM atau Web Worker ROle bukan bagian dari titik akhir publik yang seimbang. Dan dalam kasus VM, tidak memiliki alamat ILPIP yang ditetapkan untuk itu. Saat VM membuat alur keluar, Azure menerjemahkan alamat IP sumber privat dari alur keluar ke alamat IP sumber publik. Alamat IP publik yang digunakan untuk alur keluar ini tidak dapat dikonfigurasi dan tidak dihitung terhadap batas sumber daya IP publik langganan. Azure secara otomatis mengalokasikan alamat ini.

Azure menggunakan SNAT dengan port masquerading (PAT) untuk melakukan fungsi ini. Skenario ini mirip dengan skenario 2, kecuali tidak ada kontrol atas alamat IP yang digunakan. Ini adalah skenario fallback ketika skenario 1 dan 2 tidak ada. Kami tidak merekomendasikan skenario ini jika Anda ingin mengontrol alamat keluar. Jika koneksi keluar adalah bagian penting dari aplikasi Anda, Anda harus memilih skenario lain.

Port SNAT telah dialokasikan sebelumnya seperti yang dijelaskan di bagian Memahami SNAT dan PAT . Jumlah VM atau Peran Pekerja Web yang berbagi alamat IP publik menentukan jumlah port sementara yang telah dialokasikan sebelumnya. Penting untuk memahami bagaimana mereka dikonsumsi. Untuk memahami cara merancang konsumsi ini dan mengurangi seperlunya, tinjau Mengelola kelelahan SNAT.

Memahami SNAT dan PAT

Port menyamarkan SNAT (PAT)

Saat penyebaran membuat koneksi keluar, setiap sumber koneksi keluar ditulis ulang. Sumber ditulis ulang dari ruang alamat IP privat ke IP publik yang terkait dengan penyebaran (berdasarkan skenario yang dijelaskan di atas). Di ruang alamat IP publik, 5 tuple alur (alamat IP sumber, port sumber, protokol transportasi IP, alamat IP tujuan, port tujuan) harus unik.

Port Ephemeral (port SNAT) digunakan untuk mencapai hal ini setelah menulis ulang alamat IP sumber privat, karena beberapa alur berasal dari satu alamat IP publik.

Satu port SNAT dikonsumsi per alur ke satu alamat IP tujuan, port, dan protokol. Untuk beberapa alur ke alamat IP tujuan, port, dan protokol yang sama, setiap alur menggunakan satu port SNAT. Ini memastikan bahwa alur unik ketika berasal dari alamat IP publik yang sama dan pergi ke alamat IP tujuan, port, dan protokol yang sama.

Beberapa alur, masing-masing ke alamat IP tujuan, port, dan protokol yang berbeda, berbagi satu port SNAT. Alamat IP tujuan, port, dan protokol membuat alur menjadi unik tanpa perlu port sumber tambahan untuk membedakan alur di ruang alamat IP publik.

Ketika sumber daya port SNAT habis, aliran keluar gagal sampai aliran saat ini melepaskan port SNAT. Load Balancer mengklaim kembali port SNAT saat alur ditutup dan menggunakan batas waktu menganggur 4 menit untuk mengklaim kembali port SNAT dari aliran diam.

Agar pola mengurangi kondisi yang biasanya menyebabkan kelelahan port SNAT, tinjau bagian Mengelola SNAT .

Pra-alokasi port Ephemeral untuk port masquerading SNAT (PAT)

Azure menggunakan algoritma untuk menentukan jumlah port SNAT yang telah dialokasikan sebelumnya yang tersedia berdasarkan ukuran kumpulan backend saat menggunakan port masquerading SNAT (PAT). Port SNAT adalah port ephemeral yang tersedia untuk alamat sumber IP publik tertentu.

Azure melakukan pra-alokasi port SNAT saat instans disebarkan berdasarkan berapa banyak VM atau instans Peran Pekerja Web yang berbagi alamat IP publik tertentu. Saat alur keluar dibuat, PAT secara dinamis mengonsumsi (hingga batas yang telah dialokasikan sebelumnya) dan melepaskan port ini saat alur ditutup atau batas waktu diam terjadi.

Tabel berikut ini memperlihatkan praalokasi port SNAT untuk tingkat ukuran kumpulan backend:

Instans Port SNAT yang dialokasikan sebelumnya per instans
1-50 1\.024
51-100 512
101-200 256
201-400 128

Ingat bahwa jumlah port SNAT yang tersedia tidak diterjemahkan langsung ke jumlah alur. Satu port SNAT dapat digunakan kembali untuk beberapa tujuan unik. Port dikonsumsi hanya jika perlu membuat alur unik. Untuk panduan desain dan mitigasi, lihat bagian tentang cara mengelola sumber daya yang habis ini dan bagian yang menjelaskan PAT.

Mengubah ukuran penyebaran Anda dapat memengaruhi beberapa alur yang Anda tetapkan. Jika ukuran kumpulan backend meningkat dan transisi ke tingkat berikutnya, setengah dari port SNAT Anda yang telah dialokasikan direklamasi selama transisi ke tingkat kumpulan backend berikutnya yang lebih besar. Alur yang terkait dengan port SNAT yang diklaim kembali akan kehabisan waktu dan harus dibuat ulang. Jika alur baru dicoba, alur akan segera berhasil selama port yang telah dialokasikan tersedia.

Jika ukuran penyebaran berkurang dan transisi ke tingkat yang lebih rendah, jumlah port SNAT yang tersedia akan meningkat. Dalam hal ini, port SNAT yang dialokasikan yang ada dan alurnya masing-masing tidak terpengaruh.

Jika layanan awan disebarkan ulang atau diubah, infrastruktur dapat melaporkan kumpulan backend untuk sementara hingga dua kali lebih besar dari aktual dan Azure pada gilirannya akan melakukan praalokasi port SNAT yang lebih sedikit per instans dari yang diharapkan. Ini dapat meningkatkan probabilitas kelelahan port SNAT untuk sementara waktu. Akhirnya ukuran kumpulan akan beralih ke ukuran aktual dan Azure akan secara otomatis meningkatkan port SNAT yang telah dialokasikan ke angka yang diharapkan sesuai tabel di atas. Perilaku ini dirancang dan tidak dapat dikonfigurasi.

Alokasi port SNAT khusus protokol transportasi IP (TCP dan UDP dipertahankan secara terpisah) dan dirilis dalam kondisi berikut:

Rilis port TCP SNAT

  • Jika server/klien mengirim FIN/ACK, port SNAT akan dirilis setelah 240 detik.
  • Jika RST terlihat, port SNAT akan dirilis setelah 15 detik.
  • batas waktu menganggur telah tercapai

Rilis port UDP SNAT

  • batas waktu menganggur telah tercapai

Penyelesaian masalah

Bagian ini dimaksudkan untuk membantu mengurangi kelelahan SNAT dan skenario lain yang dapat terjadi dengan koneksi keluar di Azure.

Kelelahan port Azure SNAT (PAT)

Port sementara yang digunakan untuk PAT adalah sumber daya yang habis, seperti yang dijelaskan dalam tidak ada IP publik yang terkait dan titik akhir yang seimbang beban publik.

Jika Anda tahu bahwa Anda memulai banyak koneksi TCP atau UDP keluar ke alamat IP dan port tujuan yang sama, dan Anda mengamati koneksi keluar yang gagal atau disarankan oleh dukungan bahwa Anda melelahkan port SNAT (port sementara yang telah ditetapkan yang digunakan oleh PAT), Anda memiliki beberapa opsi mitigasi umum. Tinjau opsi ini dan putuskan apa yang tersedia dan terbaik untuk skenario Anda. Ada kemungkinan bahwa satu atau beberapa dapat membantu mengelola skenario ini.

Jika Anda mengalami kesulitan memahami perilaku koneksi keluar, Anda dapat menggunakan statistik tumpukan IP (netstat). Or it can be helpful to observe connection behaviors by using packet captures.

Mengubah aplikasi untuk menggunakan kembali koneksi

Anda dapat mengurangi permintaan untuk port sementara yang digunakan untuk SNAT dengan menggunakan kembali koneksi di aplikasi Anda. Ini terutama berlaku untuk protokol seperti HTTP/1.1, di mana penggunaan kembali koneksi adalah default. Dan protokol lain yang menggunakan HTTP sebagai transportasi mereka (misalnya, REST) dapat memperoleh manfaat secara nyata.

Penggunaan kembali selalu lebih baik daripada koneksi TCP atom individu untuk setiap permintaan. Penggunaan kembali menghasilkan transaksi TCP yang lebih berkinerja dan sangat efisien.

Mengubah aplikasi untuk menggunakan kumpulan koneksi

Anda dapat menggunakan skema pooling koneksi di aplikasi Anda, di mana permintaan didistribusikan secara internal di serangkaian koneksi tetap (masing-masing menggunakan kembali jika memungkinkan). Skema ini membatasi jumlah port sementara yang digunakan dan menciptakan lingkungan yang lebih dapat diprediksi. Skema ini juga dapat meningkatkan throughput permintaan dengan memungkinkan beberapa operasi simultan ketika satu koneksi memblokir pada balasan operasi.

Kumpulan koneksi mungkin sudah ada dalam kerangka kerja yang Anda gunakan untuk mengembangkan aplikasi atau pengaturan konfigurasi untuk aplikasi Anda. Anda dapat menggabungkan kumpulan koneksi dengan koneksi digunakan kembali. Beberapa permintaan Anda kemudian mengkonsumsi jumlah port yang tetap dan dapat diprediksi ke alamat IP dan port tujuan yang sama. Permintaan ini juga mendapat manfaat dari penggunaan transaksi TCP yang efisien mengurangi latensi dan pemanfaatan sumber daya. Transaksi UDP juga dapat memberikan manfaat, karena mengelola jumlah aliran UDP pada gilirannya dapat menghindari kondisi knalpot dan mengelola pemanfaatan pelabuhan SNAT.

Mengubah aplikasi untuk menggunakan logika coba lagi yang tidak terlalu agresif

Ketika port sementara yang telah dilokasi sebelumnya yang digunakan untuk PAT habis atau kegagalan aplikasi terjadi, upaya agresif atau brute force tanpa pembusukan dan logika backoff menyebabkan kelelahan terjadi atau bertahan. Anda dapat mengurangi permintaan untuk port sementara dengan menggunakan logika coba lagi yang kurang agresif.

Port sementara memiliki batas waktu menganggur 4 menit (tidak dapat disesuaikan). Jika retries terlalu agresif, kelelahan tidak memiliki kesempatan untuk membersihkan sendiri. Oleh karena itu, mempertimbangkan bagaimana - dan seberapa sering - aplikasi Anda mencoba kembali transaksi adalah bagian penting dari desain.

Menetapkan IP Publik Tingkat Instans ke setiap VM

Menetapkan ILPIP mengubah skenario Anda menjadi IP Publik Tingkat Instans ke VM. Semua port sementara IP publik yang digunakan untuk setiap VM tersedia untuk VM. (Dibandingkan dengan skenario di mana port sementara DARI IP publik dibagikan dengan semua VM yang terkait dengan penyebaran masing-masing.) Ada trade-off yang perlu dipertimbangkan, seperti dampak potensial dari mengizinkan sejumlah besar alamat IP individu.

Catatan

Opsi ini tidak tersedia untuk peran pekerja web.

Gunakan keepalive untuk mengatur ulang batas waktu habis siaga keluar

Koneksi keluar memiliki batas waktu menganggur 4 menit. Batas waktu ini tidak dapat disesuaikan. Namun, Anda dapat menggunakan transportasi (misalnya, keepalives TCP) atau keepalives lapisan aplikasi untuk menyegarkan aliran diam dan mengatur ulang batas waktu menganggur ini jika perlu. Tanyakan kepada pemasok perangkat lunak paket apa pun tentang apakah ini didukung atau cara mengaktifkannya. Umumnya hanya satu sisi yang perlu menghasilkan keepalives untuk mengatur ulang batas waktu menganggur.

Menemukan IP publik yang digunakan VM

Ada banyak cara untuk menentukan alamat IP sumber publik dari koneksi keluar. OpenDNS menyediakan layanan yang dapat menunjukkan alamat IP publik VM Anda.

Dengan menggunakan perintah nslookup, Anda bisa mengirim kueri DNS untuk nama myip.opendns.com ke pemecah masalah OpenDNS. Layanan tersebut mengembalikan alamat IP sumber yang digunakan untuk mengirim kueri. Saat Anda menjalankan kueri berikut dari komputer virtual Anda, responsnya adalah IP publik yang digunakan untuk komputer virtual tersebut:

nslookup myip.opendns.com resolver1.opendns.com

Langkah berikutnya

  • Pelajari selengkapnya tentang Load Balancer digunakan dalam penyebaran Resource Manager.
  • Pelajari mode tentang skenario koneksi keluar yang tersedia dalam penyebaran Resource Manager.