Penyetelan performa TCP/IP untuk Azure VM
Artikel ini membahas teknik penyetelan performa TCP/IP umum dan beberapa hal yang perlu dipertimbangkan ketika Anda menggunakannya untuk komputer virtual yang berjalan di Azure. Artikel ini akan memberi ringkasan dasar tentang tekniknya dan mengeksplorasi cara agar dapat disetel.
Teknik penyetelan TCP/IP umum
MTU, fragmentasi, dan offload pengiriman besar
MTU
Unit transmisi maksimum (MTU) adalah bingkai ukuran (paket) terbesar, yang ditentukan dalam byte, yang dapat dikirim melalui antarmuka jaringan. MTU adalah pengaturan yang dapat dikonfigurasi. MTU default yang digunakan pada Azure VM, dan pengaturan default pada sebagian besar perangkat jaringan secara global, adalah 1.500 byte.
Fragmentasi
Fragmentasi terjadi ketika paket yang dikirim melebihi MTU antarmuka jaringan. Tumpukan TCP/IP akan memecah paket menjadi potongan-potongan kecil (fragmen) yang sesuai dengan MTU antarmuka. Fragmentasi terjadi pada lapisan IP dan bersifat independen dari protokol yang mendasarinya (seperti TCP). Jika paket 2.000 byte dikirim melalui antarmuka jaringan dengan MTU 1.500, paket tersebut akan dipecah menjadi satu paket berukuran 1.500 byte dan satu paket berukuran 500 byte.
Perangkat jaringan dalam jalur antara sumber dan tujuan dapat menghilangkan paket yang melebihi MTU atau memecah paket menjadi potongan-potongan yang lebih kecil.
Bit Don’t Fragment dalam paket IP
Bit Don’t Fragment (DF) adalah bendera pada header protokol IP. Bit DF menunjukkan bahwa perangkat jaringan yang ada di jalur antara pengirim dan penerima tidak boleh memecah paket. Bit ini dapat diatur karena berbagai alasan. (Lihat bagian "Path MTU Discovery" di artikel ini misalnya.) Ketika perangkat jaringan menerima paket dengan set bit Don’t Fragment, dan paket tersebut melebihi MTU antarmuka perangkat, perilaku standarnya adalah perangkat menghilangkan paket. Perangkat mengirim pesan ICMP Fragmentation Needed kembali ke sumber asli paket.
Implikasi performa fragmentasi
Fragmentasi dapat memiliki implikasi performa negatif. Salah satu alasan utama efek terhadap performa adalah dampak CPU/memori dari fragmentasi dan penyusunan kembali paket. Ketika perangkat jaringan perlu memecah paket, perangkat harus mengalokasikan sumber daya CPU/memori untuk melakukan fragmentasi.
Hal yang sama terjadi ketika paket disusun kembali. Perangkat jaringan harus menyimpan semua fragmen hingga diterima sehingga dapat menyusunnya kembali ke dalam paket asli.
Azure dan fragmentasi
Paket terfragmentasi di Azure tidak diproses oleh Accelerated Networking. Ketika VM menerima paket terfragmentasi, VM akan diproses melalui jalur yang tidak dipercepat. Ini berarti paket terfragmentasi tidak akan mendapatkan manfaat Jaringan Dipercepat (latensi yang lebih rendah, berkurangnya jitter, dan paket yang lebih tinggi per detik). Untuk alasan ini, sebaiknya hindari fragmentasi jika memungkinkan.
Secara default, Azure akan keluar dari fragmen pesanan, yaitu paket terfragmentasi yang tidak tiba di VM dalam urutan pengiriman dari titik akhir sumber. Ini mungkin terjadi ketika paket ditransmisikan melalui internet atau WAN besar lainnya. Penyortiran ulang fragmen di luar urutan dapat diaktifkan dalam beberapa kasus. Jika aplikasi memerlukan ini, buka kasus dukungan.
Menyetel MTU
Kami tidak menyarankan pelanggan meningkatkan MTU pada NIC VM. Jika VM perlu berkomunikasi dengan tujuan yang tidak berada di Virtual Network yang memiliki set MTU serupa, fragmentasi kemungkinan akan terjadi yang akan mengurangi performa.
Offload pengiriman besar
Offload pengiriman besar (LSO) dapat meningkatkan performa jaringan dengan membongkar (offloading) segmentasi paket ke adaptor Ethernet. Jika LSO diaktifkan, tumpukan TCP/IP membuat paket TCP besar dan mengirimkannya ke adaptor Ethernet untuk segmentasi sebelum meneruskannya. Keuntungan LSO adalah dapat membebaskan CPU dari segmentasi paket ke dalam ukuran yang sesuai dengan MTU dan offload yang memproses ke antarmuka Ethernet di mana ia dilakukan dalam suatu perangkat keras. Untuk mempelajari selengkapnya tentang keuntungan LSO, lihat Mendukung offload pengiriman besar.
Jika LSO diaktifkan, pelanggan Azure mungkin melihat ukuran bingkai yang besar saat melakukan penangkapan paket. Ukuran bingkai yang besar ini mungkin menyebabkan beberapa pelanggan berpikir fragmentasi sedang terjadi atau bahwa MTU besar sedang digunakan, padahal nyatanya tidak. Dengan LSO, adaptor Ethernet dapat mengiklankan ukuran segmen maksimum (MSS) yang lebih besar ke tumpukan TCP/IP untuk membuat paket TCP yang lebih besar. Seluruh bingkai non-tersegmentasi ini kemudian diteruskan ke adaptor Ethernet dan akan terlihat dalam penangkapan paket yang dilakukan di VM. Tetapi paket akan dipecah menjadi banyak bingkai yang lebih kecil oleh adaptor Ethernet, menurut MTU adaptor Ethernet.
Penskalaan jendela TCP MSS dan PMTUD
Ukuran segmen maksimum TCP
Ukuran segmen maksimum TCP (MSS) adalah pengaturan yang membatasi ukuran segmen TCP, yang menghindari fragmentasi paket TCP. Sistem operasi biasanya akan menggunakan rumus ini untuk mengatur MSS:
MSS = MTU - (IP header size + TCP header size)
Header IP dan header TCP masing-masing adalah 20 byte, atau total 40 byte. Jadi, antarmuka dengan MTU 1.500 akan memiliki MSS 1.460. Namun MSS dapat dikonfigurasi.
Pengaturan ini disepakati dalam handshake tiga arah TCP ketika sesi TCP disiapkan antara sumber dan tujuan. Keduanya mengirimkan nilai MSS, dan bagian bawah keduanya digunakan untuk koneksi TCP.
Perlu diingat bahwa MTU sumber dan tujuan bukan satu-satunya faktor yang menentukan nilai MSS. Perangkat jaringan perantara, seperti VPN gateway, termasuk Azure VPN Gateway, dapat menyesuaikan MTU secara terpisah dari sumber dan tujuan untuk memastikan performa jaringan yang optimal.
Penemuan MTU jalur
MSS dinegosiasikan, tetapi mungkin tidak menunjukkan MSS aktual yang dapat digunakan. Ini karena perangkat jaringan lain dalam jalur antara sumber dan tujuan mungkin memiliki nilai MTU yang lebih rendah daripada sumber dan tujuan. Dalam hal ini, perangkat yang MTU-nya lebih kecil dari paket akan menghilangkan paket. Perangkat akan mengirim kembali pesan ICMP Fragmentation Needed (Jenis 3, Kode 4) yang berisi MTU-nya. Pesan ICMP ini memungkinkan host sumber untuk mengurangi Path MTU dengan tepat. Proses tersebut bernama Path MTU Discovery (PMTUD).
Proses PMTUD tidak efisien dan mempengaruhi performa jaringan. Ketika paket yang dikirim melebihi MTU jalur jaringan, paket perlu ditransmisi ulang dengan MSS yang lebih rendah. Jika pengirim tidak menerima pesan ICMP Fragmentation Needed, mungkin disebabkan oleh firewall jaringan dalam jalur (biasa disebut sebagai lubang hitam PMTUD), pengirim tidak tahu perlu bahwa MSS harus diturunkan dan akan terus mentransmisikan ulang paket. Inilah sebabnya mengapa kami tidak merekomendasikan peningkatan MTU Azure VM.
VPN dan MTU
Jika Anda menggunakan VM yang melakukan enkapsulasi (seperti VPN IPsec), ada beberapa pertimbangan tambahan mengenai ukuran paket dan MTU. VPN menambahkan lebih banyak header ke paket, yang meningkatkan ukuran paket dan memerlukan MSS yang lebih kecil.
Untuk Azure, kami sarankan agar Anda mengatur penjepitan MSS TCP ke 1.350 byte dan MTU antarmuka terowongan ke 1.400. Untuk informasi selengkapnya, lihat halaman perangkat VPN dan parameter IPSec/IKE.
Latensi, waktu round-trip, dan penskalaan jendela TCP
Latensi dan waktu round-trip
Latensi jaringan diatur oleh kecepatan cahaya melalui jaringan optik fiber. Throughput jaringan TCP juga secara efektif diatur oleh waktu round-trip (RTT) antara dua perangkat jaringan.
| Rute | Jarak | Waktu satu arah | RTT |
|---|---|---|---|
| New York ke San Francisco | 4.148 km | 21 mdtk | 42 mdtk |
| New York ke London | 5.585 km | 28 mdtk | 56 mdtk |
| New York ke Sydney | 15.993 km | 80 mdtk | 160 mdtk |
Tabel ini menunjukkan jarak garis lurus antara dua lokasi. Dalam jaringan, jarak biasanya lebih panjang dari jarak garis lurus. Berikut adalah rumus sederhana untuk menghitung RTT minimum sebagaimana yang diatur oleh kecepatan cahaya:
minimum RTT = 2 * (Distance in kilometers / Speed of propagation)
Anda dapat menggunakan 200 untuk kecepatan perambatan. Ini adalah jarak, dalam kilometer, yang ditempuh cahaya dalam 1 milidetik.
Mari kita ambil New York ke San Francisco sebagai contoh. Jarak garis lurusnya adalah 4.148 km. Masukkan nilai tersebut ke dalam persamaan, kita dapatkan berikut ini:
Minimum RTT = 2 * (4,148 / 200)
Hasil persamaan dalam milidetik.
Jika Anda ingin mendapatkan performa jaringan terbaik, opsi logisnya adalah memilih tujuan dengan jarak terpendek di antaranya. Anda juga harus merancang jaringan virtual Anda untuk mengoptimalkan jalur lalu lintas dan mengurangi latensi. Untuk informasi selengkapnya, lihat bagian "Pertimbangan desain jaringan" di artikel ini.
Efek latensi dan waktu round-trip pada TCP
Waktu round-trip memiliki efek langsung pada throughput TCP maksimum. Dalam protokol TCP, ukuran jendela adalah jumlah maksimum lalu lintas yang dapat dikirim melalui koneksi TCP sebelum pengirim perlu menerima pengakuan dari penerima. Jika MSS TCP diatur menjadi 1.460 dan ukuran jendela TCP diatur menjadi 65.535, pengirim dapat mengirimkan 45 paket sebelum pengirim harus menerima pengakuan dari penerima. Jika pengirim tidak mendapatkan pengakuan, pengirim akan mengirimkan ulang data. Berikut rumusnya:
TCP window size / TCP MSS = packets sent
Dalam contoh ini, 65.535 / 1.460 dibulatkan menjadi 45.
Status "menunggu pengakuan" ini, suatu mekanisme untuk memastikan pengiriman data yang andal, adalah hal yang menyebabkan RTT mempengaruhi throughput TCP. Semakin lama pengirim menunggu pengakuan, semakin lama ia perlu menunggu sebelum mengirim lebih banyak data.
Berikut adalah rumus untuk menghitung throughput maksimum dari satu koneksi TCP:
Window size / (RTT latency in milliseconds / 1,000) = maximum bytes/second
Tabel ini menunjukkan throughput megabyte/per detik maksimum dari satu koneksi TCP. (Untuk keterbacaan, megabyte digunakan untuk satuan pengukuran.)
| Ukuran jendela TCP (byte) | Latensi RTT (mdtk) | Throughput megabyte/detik maksimum | Throughput megabit/detik maksimum |
|---|---|---|---|
| 65.535 | 1 | 65,54 | 524,29 |
| 65.535 | 30 | 2,18 | 17,48 |
| 65.535 | 60 | 1,09 | 8,74 |
| 65.535 | 90 | ,73 | 5,83 |
| 65.535 | 120 | ,55 | 4.37 |
Jika paket hilang, throughput maksimum koneksi TCP akan dikurangi sementara pengirim mengirimkan ulang data yang telah dikirim.
Penskalaan jendela TCP
Penskalaan jendela TCP adalah teknik yang secara dinamis meningkatkan ukuran jendela TCP untuk memungkinkan lebih banyak data dikirim sebelum pengakuan diperlukan. Dalam contoh sebelumnya, 45 paket akan dikirim sebelum pengakuan diperlukan. Jika Anda meningkatkan jumlah paket yang dapat dikirim sebelum pengakuan diperlukan, Anda mengurangi frekuensi pengirim menunggu pengakuan, yang meningkatkan throughput maksimum TCP.
Tabel ini menggambarkan hubungan tersebut:
| Ukuran jendela TCP (byte) | Latensi RTT (mdtk) | Throughput megabyte/detik maksimum | Throughput megabit/detik maksimum |
|---|---|---|---|
| 65.535 | 30 | 2,18 | 17,48 |
| 131.070 | 30 | 4.37 | 34,95 |
| 262.140 | 30 | 8,74 | 69,91 |
| 524.280 | 30 | 17,48 | 139,81 |
Tetapi nilai header TCP untuk ukuran jendela TCP hanya sepanjang 2 byte, yang berarti nilai maksimum untuk jendela penerima adalah 65.535. Untuk meningkatkan ukuran jendela maksimum, diperkenalkan faktor skala jendela TCP.
Faktor skala juga merupakan pengaturan yang dapat Anda konfigurasi dalam sistem operasi. Berikut adalah rumus untuk menghitung ukuran jendela TCP menggunakan faktor skala:
TCP window size = TCP window size in bytes * (2^scale factor)
Berikut perhitungan untuk faktor skala jendela 3 dan ukuran jendela 65.535:
65,535 * (2^3) = 524,280 bytes
Faktor skala 14 menghasilkan ukuran jendela TCP sebesar 14 (offset maksimum yang diizinkan). Ukuran jendela TCP akan sebesar 1.073.725.440 byte (8,5 gigabit).
Dukungan untuk penskalaan jendela TCP
Windows dapat mengatur faktor penskalaan yang berbeda untuk berbagai tipe koneksi. (Kelas koneksi termasuk pusat data, internet, dan sebagainya.) Anda menggunakan perintah PowerShell Get-NetTCPConnection untuk melihat tipe koneksi penskalaan jendela:
Get-NetTCPConnection
Anda dapat menggunakan perintah Get-NetTCPSetting PowerShell untuk menampilkan nilai setiap kelas:
Get-NetTCPSetting
Anda dapat mengatur ukuran jendela TCP awal dan faktor penskalaan TCP di Windows menggunakan perintah PowerShell Set-NetTCPSetting. Untuk informasi selengkapnya, lihat Set-NetTCPSetting.
Set-NetTCPSetting
Ini adalah pengaturan TCP yang efektif untuk AutoTuningLevel:
| AutoTuningLevel | Faktor penskalaan | Pengali penskalaan | Rumus untuk menghitung ukuran jendela maksimum |
|---|---|---|---|
| Nonaktif | Tidak ada | Tidak ada | Ukuran jendela |
| Terbatas | 4 | 2^4 | Ukuran jendela * (2^4) |
| Sangat dibatasi | 2 | 2^2 | Ukuran jendela * (2^2) |
| Normal | 8 | 2^8 | Ukuran jendela * (2^8) |
| Eksperimental | 14 | 2^14 | Ukuran jendela * (2^14) |
Pengaturan ini cenderung memengaruhi performa TCP, tetapi perlu diingat bahwa banyak faktor lain di internet, di luar kendali Azure, juga dapat memengaruhi performa TCP.
Jaringan yang dipercepat dan receive side scaling
Jaringan yang dipercepat
Fungsi jaringan komputer virtual secara historis telah CPU intensif pada VM tamu dan hypervisor/host. Setiap paket yang transit melalui host diproses dalam perangkat lunak oleh CPU host, termasuk semua enkapsulasi dan dekapsulasi jaringan virtual. Sehingga semakin banyak lalu lintas yang melewati host, semakin tinggi beban CPU. Dan jika CPU host sibuk dengan operasi lain, hal tersebut juga akan memengaruhi throughput dan latensi jaringan. Azure mengatasi masalah ini dengan jaringan yang dipercepat.
Jaringan yang dipercepat memberikan latensi jaringan sangat rendah (ultralow) yang konsisten melalui perangkat keras Azure yang dapat diprogram secara in-house dan teknologi seperti SR-IOV. Jaringan yang dipercepat memindahkan sebagian besar tumpukan jaringan yang ditentukan perangkat lunak Azure dari CPU dan ke SmartNIC berbasis FPGA. Perubahan ini memungkinkan aplikasi pengguna akhir untuk mengklaim kembali siklus komputasi, yang menempatkan lebih sedikit beban pada VM, mengurangi jitter dan ketidakkonsistenan latensi. Dengan kata lain, performa dapat lebih deterministik.
Jaringan yang dipercepat meningkatkan performa dengan mengizinkan tamu VM untuk melewati host dan membuat datapath secara langsung dengan SmartNIC host. Berikut adalah beberapa keuntungan dari jaringan yang dipercepat:
Latensi yang lebih rendah / paket per detik (pps) yang lebih tinggi : Penghapusan pengalihan virtual dari datapath menghilangkan waktu yang digunakan paket dalam host untuk pemrosesan kebijakan dan meningkatkan jumlah paket yang dapat diproses dalam VM.
Berkurangnya jitter: Pemrosesan pengalihan virtual tergantung pada jumlah kebijakan yang perlu diterapkan dan beban kerja CPU yang melakukan pemrosesan. Offloading penegakan kebijakan ke perangkat keras menghapuskan variabilitas tersebut dengan mengirimkan paket secara langsung ke VM, menghilangkan komunikasi host-ke-VM dan semua interupsi perangkat lunak dan pengalihan konteks.
Penurunan utilisasi CPU: Melewati sakelar virtual di host menyebabkan lebih sedikit utilisasi CPU untuk memproses lalu lintas jaringan.
Untuk menggunakan jaringan yang dipercepat, Anda perlu mengaktifkannya secara eksplisit pada setiap VM yang berlaku. Lihat Membuat komputer virtual Linux dengan Jaringan yang Dipercepat untuk petunjuknya.
Receive side scaling
Receive side scaling (RSS) adalah teknologi driver jaringan yang mendistribusikan penerimaan lalu lintas jaringan secara lebih efisien dengan mendistribusikan pemrosesan penerimaan di beberapa CPU dalam sistem multiprosesor. Sederhananya, RSS memungkinkan sistem untuk memproses lebih banyak lalu lintas yang diterima karena menggunakan semua CPU yang tersedia, bukan hanya satu. Untuk diskusi yang lebih teknis tentang RSS, lihat Pengenalan receive side scaling.
Untuk mendapatkan performa terbaik saat jaringan yang dipercepat diaktifkan pada VM, Anda perlu mengaktifkan RSS. RSS juga dapat memberikan keuntungan pada VM yang tidak menggunakan jaringan yang dipercepat. Untuk ringkasan tentang cara menentukan apakah RSS diaktifkan dan cara mengaktifkannya, lihat Mengoptimalkan throughput jaringan untuk komputer virtual Azure.
TCP TIME_WAIT dan penghentian TIME_WAIT
TCP TIME_WAIT adalah pengaturan umum lain yang memengaruhi performa jaringan dan aplikasi. Pada VM sibuk yang membuka dan menutup banyak soket, baik sebagai klien atau sebagai server (IP Sumber:Port Sumber + IP Tujuan:Port Tujuan), selama operasi normal TCP, soket yang ditentukan dapat berakhir dalam status TIME_WAIT untuk waktu yang lama. Status TIME_WAIT ini dimaksudkan untuk mengizinkan data tambahan apa pun dikirimkan pada soket sebelum menutupnya. Sehingga tumpukan TCP/IP umumnya mencegah penggunaan kembali soket dengan diam-diam menghilangkan paket SYN TCP klien.
Jumlah waktu soket berada di TIME_WAIT dapat dikonfigurasi. Waktu dapat berkisar antara 30 detik hingga 240 detik. Soket merupakan sumber daya terbatas, dan jumlah soket yang dapat digunakan pada waktu tertentu dapat dikonfigurasi. (Jumlah soket yang tersedia biasanya sekitar 30.000.) Jika soket yang tersedia digunakan, atau jika klien dan server memiliki pengaturan TIME_WAIT yang tidak cocok, dan VM mencoba menggunakan kembali soket dalam status TIME_WAIT, koneksi baru akan gagal karena paket SYN TCP diam-diam hilang.
Nilai untuk rentang port untuk soket keluar biasanya dapat dikonfigurasi dalam tumpukan TCP/IP dari sistem operasi. Hal yang sama berlaku untuk TCP TIME_WAIT pengaturan dan penggunaan kembali soket. Mengubah angka-angka ini dapat berpotensi meningkatkan skalabilitas. Tapi, tergantung pada situasinya, perubahan ini dapat menyebabkan masalah interoperabilitas. Anda harus berhati-hati jika mengubah nilai-nilai ini.
Anda dapat menggunakan penghentian TIME_WAIT untuk mengatasi batasan penskalaan ini. Penghentian TIME_WAIT ini memungkinkan soket untuk digunakan kembali dalam situasi tertentu, seperti ketika nomor urutan dalam paket IP koneksi baru melebihi jumlah urutan paket terakhir dari koneksi sebelumnya. Dalam hal ini, sistem operasi akan mengizinkan koneksi baru untuk dibuat (akan menerima SYN/ACK baru) dan memaksa menutup koneksi sebelumnya yang berada dalam status TIME_WAIT. Kemampuan ini didukung pada VM Windows di Azure. Untuk mempelajari tentang dukungan di VM lain, tanyakan kepada vendor OS.
Untuk mempelajari tentang konfigurasi pengaturan TCP TIME_WAIT dan rentang port sumber, lihat Pengaturan yang dapat dimodifikasi untuk meningkatkan performa jaringan.
Faktor jaringan virtual yang dapat memengaruhi performa
Throughput keluar maksimum VM
Azure menyediakan berbagai ukuran dan jenis VM, masing-masing dengan perpaduan kemampuan performa yang berbeda. Salah satu kemampuan ini adalah throughput jaringan (atau bandwidth), yang diukur dalam megabit per detik (Mbps). Karena komputer virtual dihosting pada perangkat keras bersama, kapasitas jaringan perlu dibagi secara adil di antara komputer virtual menggunakan perangkat keras yang sama. Komputer virtual yang lebih besar diberi alokasi lebih banyak bandwidth daripada komputer virtual yang lebih kecil.
Bandwidth jaringan yang dialokasikan untuk setiap komputer virtual diukur pada lalu lintas keluar (outbound) dari komputer virtual. Semua lalu lintas jaringan yang meninggalkan komputer virtual dihitung menuju batas yang dialokasikan, apa pun tujuannya. Misalnya, jika komputer virtual memiliki batas 1.000-Mbps, batas tersebut berlaku baik apakah lalu lintas keluar ditujukan untuk komputer virtual lain dalam jaringan virtual yang sama atau yang di luar Azure.
Ingress tidak diukur atau dibatasi secara langsung. Tetapi ada faktor lain, seperti batas CPU dan penyimpanan, yang dapat memengaruhi kemampuan komputer virtual untuk memproses data masuk.
Jaringan yang dipercepat dirancang untuk meningkatkan performa jaringan, termasuk latensi, throughput, dan utilisasi CPU. Jaringan yang dipercepat dapat meningkatkan throughput komputer virtual, tetapi hanya dapat melakukannya hingga bandwidth yang dialokasikan untuk komputer virtual tersebut.
Komputer virtual Azure memiliki setidaknya satu antarmuka jaringan yang melekat padanya. Mungkin ada beberapa. Bandwidth yang dialokasikan untuk komputer virtual adalah jumlah semua lalu lintas keluar di seluruh antarmuka jaringan yang melekat pada komputer. Dengan kata lain, bandwidth dialokasikan berbasis per-komputer virtual, terlepas dari berapa banyak antarmuka jaringan yang melekat pada komputer.
Throughput keluar yang diharapkan dan jumlah antarmuka jaringan yang didukung oleh setiap ukuran VM dirinci dalam Ukuran untuk komputer virtual Windows di Azure. Untuk melihat throughput maksimum, pilih jenis, seperti Tujuan umum, lalu temukan bagian tentang seri ukuran pada halaman yang dihasilkan (misalnya, "Dv2-series"). Untuk setiap seri, ada tabel yang menyediakan spesifikasi jaringan di kolom terakhir, yang berjudul "Max NICs / Expected network bandwidth (Mbps)."
Batas throughput berlaku untuk komputer virtual. Throughput tidak terpengaruh oleh faktor-faktor ini:
Jumlah antarmuka jaringan: Batas bandwidth berlaku untuk jumlah semua lalu lintas keluar dari komputer virtual.
Jaringan yang dipercepat:Meskipun fitur ini dapat membantu mencapai batas yang dipublikasikan, fitur ini tidak mengubah batas.
Tujuan lalu lintas: Semua tujuan dihitung mendekati batas keluar.
Protokol: Semua lalu lintas keluar di semua protokol dihitung menuju batas.
Untuk informasi selengkapnya, lihat Bandwidth jaringan komputer virtual.
Pertimbangan performa internet
Seperti yang dibahas di seluruh artikel ini, faktor mengenai internet dan di luar kontrol Azure dapat memengaruhi performa jaringan. Berikut adalah beberapa faktor tersebut:
Latensi: Waktu round-trip antara dua tujuan dapat dipengaruhi oleh masalah pada jaringan perantara, oleh lalu lintas yang tidak mengambil jalur jarak "terpendek", dan oleh jalur peering suboptimal.
Kehilangan paket:Kehilangan paket dapat disebabkan oleh kemacetan jaringan, masalah jalur fisik, dan perangkat jaringan yang berperforma rendah.
Fragmentasi/Ukuran MTU:Fragmentasi di sepanjang jalur dapat menyebabkan penundaan datangnya data atau dalam paket yang tiba di luar urutan, yang dapat memengaruhi pengiriman paket.
Traceroute adalah alat yang baik untuk mengukur karakteristik performa jaringan (seperti kehilangan dan latensi paket) di sepanjang setiap jalur jaringan antara perangkat sumber dan perangkat tujuan.
Pertimbangan desain jaringan
Seiring dengan pertimbangan yang dibahas sebelumnya dalam artikel ini, topologi jaringan virtual dapat memengaruhi performa jaringan. Misalnya, desain hub-and-spoke yang melakukan backhaul lalu lintas secara global ke jaringan virtual satu hub akan memperkenalkan latensi jaringan, yang akan memengaruhi performa jaringan secara keseluruhan.
Jumlah perangkat jaringan yang dilalui lalu lintas jaringan juga dapat memengaruhi latensi keseluruhan. Misalnya, dalam desain hub-and-spoke, jika lalu lintas melewati appliance virtual jaringan spoke dan appliance virtual hub sebelum transit ke internet, appliance virtual jaringan dapat menyebabkan latensi.
Wilayah Azure, jaringan virtual, dan latensi
Wilayah Azure terdiri dari beberapa pusat data yang ada dalam area geografis umum. Pusat data ini mungkin tidak bersebelahan secara fisik. Dalam beberapa kasus pusat data terpisah sejauh 10 kilometer. Jaringan virtual adalah overlay logis di atas jaringan pusat data fisik Azure. Jaringan virtual tidak menyiratkan topologi jaringan tertentu apa pun dalam pusat data.
Misalnya, dua VM yang berada dalam jaringan virtual dan subnet yang sama mungkin berada di rak, baris, atau bahkan pusat data yang berbeda. Ini dapat terpisah sejauh berdasarkan kaki kabel fiber optik atau berdasarkan kilometer kabel fiber optik. Variasi ini dapat menyebabkan latensi variabel (selisih beberapa milidetik) di antara VM yang berbeda.
Penempatan geografis VM, dan potensi latensi yang dihasilkan antara dua VM, dapat dipengaruhi oleh konfigurasi set ketersediaan dan Zona Ketersediaan. Tetapi jarak antara pusat data di suatu wilayah tergolong spesifik wilayah dan terutama dipengaruhi oleh topologi pusat data di wilayah tersebut.
Kelelahan port NAT sumber
Penyebaran di Azure dapat berkomunikasi dengan titik akhir di luar Azure pada internet publik dan/atau di ruang IP publik. Saat instans memulai koneksi keluar, Azure secara dinamis memetakan alamat IP pribadi ke alamat IP publik. Setelah Azure membuat pemetaan ini, lalu lintas balik untuk alur asal keluar juga dapat mencapai alamat IP pribadi tempat aliran berasal.
Untuk setiap koneksi keluar, Azure Load Balancer perlu mempertahankan pemetaan ini selama beberapa periode waktu. Dengan sifat multitenant Azure, mempertahankan pemetaan ini untuk setiap alur keluar untuk setiap VM dapat bersifat sumber daya intensif. Sehingga ada batasan yang ditetapkan dan didasarkan pada konfigurasi Azure Virtual Network. Atau lebih tepatnya, VM Azure hanya dapat membuat sejumlah koneksi keluar pada waktu tertentu. Jika batas ini tercapai, VM tidak akan dapat membuat lebih banyak koneksi keluar.
Tapi perilaku ini dapat dikonfigurasi. Untuk informasi selengkapnya tentang kelelahan port SNAT dan SNAT, lihat artikel ini.
Mengukur performa jaringan di Azure
Sejumlah performa maksimal dalam artikel ini terkait dengan latensi jaringan/waktu round-trip (RTT) antara dua VM. Bagian ini memberikan beberapa saran tentang cara menguji latensi/RTT dan cara menguji performa TCP dan performa jaringan VM. Anda dapat menyetel dan menguji performa TCP/IP dan nilai jaringan yang dibahas sebelumnya menggunakan teknik yang dijelaskan di bagian ini. Anda dapat menyambungkan nilai latensi, MTU, MSS, dan ukuran jendela ke dalam perhitungan yang disediakan sebelumnya dan membandingkan maksimum teoritis dengan nilai aktual yang diamati selama pengujian.
Mengukur waktu round-trip dan kehilangan paket
Performa TCP sangat bergantung pada RTT dan Kehilangan paket. Utilitas PING yang tersedia di Windows dan Linux menyediakan cara termudah untuk mengukur RTT dan kehilangan paket. Output PING akan menunjukkan latensi minimum/maksimum/rata-rata antara sumber dengan tujuan. Output juga akan menunjukkan kehilangan paket. PING menggunakan protokol ICMP secara default. Anda dapat menggunakan PsPing untuk menguji TCP RTT. Untuk informasi selengkapnya, lihat PsPing.
Mengukur bandwidth aktual dari komputer virtual
Untuk mengukur bandwidth VM Azure secara akurat, ikuti panduan ini.
Untuk detail selengkapnya tentang menguji skenario lain, lihat artikel berikut ini:
Mendeteksi perilaku TCP yang tidak efisien
Dalam penangkapan paket, pelanggan Azure mungkin melihat paket TCP dengan bendera TCP (SACK, DUP ACK, RETRANSMIT, dan FAST RETRANSMIT) yang dapat menunjukkan masalah performa jaringan. Paket-paket ini secara khusus menunjukkan inefisiensi jaringan yang diakibatkan oleh kehilangan paket. Tetapi kehilangan paket tidak selalu disebabkan karena masalah performa Azure. Masalah performa dapat menjadi akibat dari masalah aplikasi, masalah sistem operasi, atau masalah lain yang mungkin tidak terkait langsung dengan platform Azure.
Selain itu, perlu diingat bahwa beberapa transmisi ulang dan duplikat ACK normal pada jaringan. Protokol TCP dibangun agar dapat diandalkan. Bukti paket TCP ini dalam penangkapan paket tidak selalu menunjukkan masalah jaringan sistemik, kecuali apabila berlebihan.
Namun, jenis paket ini merupakan indikasi bahwa throughput TCP tidak mencapai performa maksimumnya, karena alasan yang dibahas di bagian lain pada artikel ini.
Langkah berikutnya
Kini setelah mempelajari tentang penyetelan performa TCP/IP untuk VM Azure, Anda mungkin ingin membaca tentang pertimbangan lain untuk merencanakan jaringan virtual atau mempelajari selengkapnya tentang menghubungkan dan mengonfigurasi jaringan virtual.