Azure sanal makineleri için TCP/IP performans ayarlaması

2025-04-21

Bu makalede yaygın TCP/IP performans ayarlama teknikleri ve Bunları Azure'da çalışan sanal makineler için kullanırken dikkate almanız gereken bazı konular ele alınmaktadır. Tekniklere temel bir genel bakış sağlar ve sanal makinelerin nasıl ayarlanabileceğini keşfeder.

Yaygın TCP/IP ayarlama teknikleri

MTU, parçalanma ve büyük gönderme yükü

MTU

Maksimum iletim birimi (MTU), ağ arabirimi üzerinden gönderilebilen bayt cinsinden belirtilen en büyük boyut çerçevesidir (paket artı ağ erişim üst bilgileri). MTU yapılandırılabilir bir ayardır. Azure VM'lerinde kullanılan varsayılan MTU ve genelde çoğu ağ cihazında varsayılan ayar 1.500 bayttır.

Parçalanma

Parçalanma, bir ağ arabiriminin MTU'sunu aşan bir paket gönderildiğinde oluşur. TCP/IP yığını, paketi arabirimin MTU'suna uygun daha küçük parçalara (parçalara) ayırır. Parçalanma IP katmanında gerçekleşir ve temel alınan protokolden (TCP gibi) bağımsızdır. 1.500 MTU'ya sahip bir ağ arabirimi üzerinden 2.000 baytlık bir paket gönderildiğinde, paket bir 1.500 baytlık pakete ve bir 500 baytlık pakete ayrılır.

Kaynak ve hedef arasındaki yoldaki ağ cihazları, MTU'dan fazla paketleri bırakabilir veya paketi daha küçük parçalara ayırabilir.

IP paketinde Parçalama Yok biti

Parçalanmama (DF) biti, IP protokolü başlığındaki bir bayraktır. DF biti, gönderen ile alıcı arasındaki yoldaki ağ cihazlarının paketi parçalanmaması gerektiğini belirtir. Bu bit birçok nedenden dolayı ayarlanabilir. (Bir örnek için bu makalenin "Yol MTU Bulma" bölümüne bakın.) Bir ağ cihazı Fragment Etme biti ayarlanmış bir paket aldığında ve bu paket cihazın arayüz MTU'sunu aştığında, standart davranış cihazın paketi bırakmasıdır. Cihaz, paketin özgün kaynağına bir ICMP Parçalanması Gerekiyor iletisi gönderir.

Parçalanmanın performans etkileri

Parçalanmanın performansa olumsuz etkileri olabilir. Performans üzerindeki etkinin ana nedenlerinden biri, paketlerin parçalanması ve yeniden bir araya başlatılmasının CPU/bellek etkisidir. Bir ağ cihazının bir paketi parçalaması gerektiğinde parçalanma gerçekleştirmek için CPU/bellek kaynaklarını ayırması gerekir.

Paket yeniden birleştirildiğinde de aynı şey olur. Ağ cihazının, özgün pakette yeniden birleştirebilmesi için tüm parçaları alınana kadar depolaması gerekir.

Azure ve parçalanma

Azure, Hızlandırılmış Ağ ile parçalanmış paketleri işlemez. Bir VM parçalanmış bir paket aldığında, hızlandırılmamış yol bunu işler. Sonuç olarak, parçalanmış paketler Hızlandırılmış Ağ'ın düşük gecikme süresi, düşük değişim ve saniye başına daha yüksek paketler gibi avantajlarını kaçırmaktadır. Bu nedenle mümkünse parçalanmayı önlemenizi öneririz.

Azure, varsayılan olarak VM'ye gelen parçalanmış paketleri sıra dışı bırakır; bu da paketlerin kaynak uç noktadan iletim dizisiyle eşleşmediği anlamına gelir. Paketler İnternet üzerinden veya diğer büyük WAN'lar üzerinden hareket ettiğinde bu sorun oluşabilir.

MTU'yu ayarla

VM'nizin trafiği için MTU'ları artırarak iç Sanal Ağ aktarım hızını geliştirebilirsiniz. Ancak, VM farklı bir MTU'ya sahip Sanal Ağ dışındaki hedeflerle iletişim kurarsa parçalanma oluşabilir ve performansı düşürebilir.

Azure VM'lerinde MTU'ları ayarlama hakkında daha fazla bilgi için bkz. Azure'daki sanal makineler için En Fazla İletim Birimini (MTU) Yapılandırma.

Büyük gönderme yükü

Büyük gönderme yükü (LSO), paketlerin segmentasyonunu Ethernet bağdaştırıcısına boşaltarak ağ performansını artırabilir. LSO etkinleştirildiğinde, TCP/IP yığını büyük bir TCP paketi oluşturur ve iletmeden önce segmentasyon için ethernet bağdaştırıcısına gönderir. LSO'nun avantajı, CPU'nun paketleri MTU'ya uygun boyutlara ayırmasını ve bu işlemi Ethernet arabirimi donanımına boşaltmasını sağlar. LSO'nun avantajları hakkında daha fazla bilgi edinmek için bkz . Büyük gönderme yükünü destekleme.

LSO etkinleştirildiğinde, Azure müşterileri paket yakalamaları sırasında büyük çerçeve boyutları fark edebilir. Bu büyük çerçeve boyutları, bazı müşterilerin parçalanma meydana geldiğini veya büyük bir MTU'nun kullanılmadığını varsaymasına neden olabilir. LSO ile ethernet bağdaştırıcısı, daha büyük bir TCP paketi oluşturmak için TCP/IP yığınına daha büyük bir maksimum kesim boyutu (MSS) tanıtabilir. Ethernet bağdaştırıcısı daha sonra tüm bu ayrıştırılmamış çerçeveyi MTU'suna göre daha küçük çerçevelere böler ve bu da VM üzerinde gerçekleştirilen bir paket yakalama işleminde görünür.

TCP MSS pencere ölçeklendirme ve PMTUD

TCP maksimum segment boyutu

TCP en büyük segment boyutu (MSS), TCP paketlerinin parçalanmasından kaçınan TCP segmentlerinin boyutunu sınırlayan bir ayardır. İşletim sistemleri genellikle MSS'yi ayarlamak için bu formülü kullanır:

MSS = MTU - (IP header size + TCP header size)

IP üst bilgisi ve TCP üst bilgisi 20 bayt veya toplam 40 bayttır. MTU'sı 1.500 olan bir arabirimin MSS'i 1.460'tır. MSS yapılandırılabilir.

Bu ayar, bir kaynak ile hedef arasında bir TCP oturumu ayarlandığında, TCP üç aşamalı el sıkışması sırasında kabul edilir. Her iki taraf da bir MSS değeri gönderir ve ikisinin alt kısmı TCP bağlantısı için kullanılır.

MSS değerini belirleyen tek faktörlerin kaynak ve hedefin MTU'ları olmadığını unutmayın. Azure VPN Gateway de dahil olmak üzere VPN ağ geçitleri gibi aracı ağ cihazları, en iyi ağ performansını sağlamak için MTU'nun kaynak ve hedeflerinden bağımsız olarak ayarlanmasını sağlayabilir.

Yol MTU Bulma

MSS üzerinde bir anlaşma olabilir, ancak bu, kullanılabilecek gerçek MSS'yi göstermeyebilir. Kaynak ile hedef arasındaki yoldaki diğer ağ cihazları, kaynak ve hedeften daha düşük bir MTU değerine sahip olabilir. Bu durumda, MTU'sunun paketten küçük olduğu cihaz paketi bırakır. Cihaz, MTU'sunu içeren bir ICMP Parçalanması Gerekiyor (Tür 3, Kod 4) iletisini geri gönderir. Bu ICMP iletisi, kaynak konağın Yol MTU'sunu uygun şekilde azaltmasını sağlar. İşleme Yol MTU Bulma (PMTUD) adı verilir.

PMTUD işlemi, verimsizliği nedeniyle ağ performansını azaltır. Bir ağ yolunun MTU's u aşıldığında paketlerin daha düşük bir MSS ile yeniden iletilmesi gerekir. Ağ güvenlik duvarı ICMP Parçalanması Gerekiyor iletisini engelliyorsa, gönderen MSS'yi düşürme gereksiniminin farkına varamaz ve paketi defalarca yeniden gönderir. Bu nedenle Azure VM MTU'sunun artırılmasını önermiyoruz.

VPN ve MTU

Kapsülleme gerçekleştiren VM'ler kullanıyorsanız (IPsec VPN'leri gibi), paket boyutu ve MTU ile ilgili dikkat edilmesi gereken başka noktalar da vardır. VPN'ler paketlere daha fazla üst bilgi ekler. Eklenen üst bilgiler paket boyutunu artırır ve daha küçük bir MSS gerektirir.

Azure için TCP MSS bağlamasını 1.350 bayt ve tünel arabirimi MTU'sını 1.400 olarak ayarlamanızı öneririz. Daha fazla bilgi için VPN cihazları ve IPsec/IKE parametreleri sayfasına bakın.

Gecikme süresi, gidiş dönüş süresi ve TCP penceresi ölçeklendirme

Gecikme süresi ve gidiş dönüş süresi

Işık hızı, fiber optik ağ üzerinden ağ gecikme süresini belirler. İki ağ cihazı arasındaki gidiş dönüş süresi (RTT), TCP ağ aktarım hızını yönetir.

Rota	Mesafe	Tek yönlü zaman	RTT
New York'tan San Francisco'ya	4.148 km	21 ms	42 ms
New York-Londra	5,585 km	28 ms	56 ms
New York - Sidney	15.993 km	80 ms	160 ms

Bu tabloda iki konum arasındaki düz çizgi uzaklığı gösterilmektedir. Ağlarda mesafe genellikle düz çizgi uzaklığından daha uzundur. Aşağıda, ışık hızına göre idare edilen en düşük RTT'yi hesaplamak için basit bir formül bulabilirsiniz:

minimum RTT = 2 * (Distance in kilometers / Speed of propagation)

Yayma hızı için 200 kullanabilirsiniz. Yayma hızı, ışığın 1 milisaniye içinde hareket eden kilometre cinsinden uzaklığıdır.

Örnek olarak New York'ı San Francisco'ya götürelim. Düz hat mesafesi 4.148 km'dir. Bu değeri denkleme girmek, aşağıdaki denklemi verir:

Minimum RTT = 2 * (4,148 / 200)

Denklemin çıkışı milisaniye cinsindendir.

En iyi ağ performansını elde etmek istiyorsanız, mantıksal seçenek aralarında en kısa mesafe olan hedefleri seçmektir. Ayrıca, trafiğin yolunu iyileştirmek ve gecikme süresini azaltmak için sanal ağınızı tasarlamanız gerekir. Daha fazla bilgi için bu makalenin "Ağ tasarımında dikkat edilmesi gerekenler" bölümüne bakın.

TCP'de gecikme süresi ve gidiş dönüş süresi etkileri

Gidiş dönüş süresinin maksimum TCP aktarım hızı üzerinde doğrudan etkisi vardır. TCP protokolünde pencere boyutu , gönderenin alıcıdan onay alması gerekmeden önce TCP bağlantısı üzerinden gönderilebilen maksimum trafik miktarıdır. TCP MSS 1.460 ve TCP pencere boyutu 65.535 olarak ayarlandıysa, gönderen alıcıdan bildirim almadan önce 45 paket gönderebilir. Gönderen onay almazsa verileri yeniden gönderir. Formül şudur:

TCP window size / TCP MSS = packets sent

Bu örnekte, 65.535 / 1.460 45'e yuvarlanmış.

TCP aktarım hızını etkileyen RTT'nin nedeni, verilerin güvenilir bir şekilde teslim edilmesini sağlayan bir mekanizma olan bu "bildirim bekleniyor" durumudur. Gönderen ne kadar uzun süre onay beklerse, daha fazla veri göndermeden önce beklemesi o kadar uzun sürer.

Tek bir TCP bağlantısının en yüksek aktarım hızını hesaplamaya yönelik formül aşağıdadır:

Window size / (RTT latency in milliseconds / 1,000) = maximum bytes/second

Bu tabloda tek bir TCP bağlantısının en yüksek megabayt/saniye aktarım hızı gösterilmektedir. (Okunabilirlik için ölçü birimi için megabayt kullanılır.)

TCP pencere boyutu (bayt)	RTT gecikme süresi (ms)	Maksimum megabayt/saniye aktarım hızı	Maksimum megabit/saniye aktarım hızı
65,535	1	65.54	524.29
65,535	30	2.18	17.48
65,535	60	1.09	8.74
65,535	90	0.73	5,83
65,535	120	0.55	4.37

Paketler kaybolursa, gönderen gönderdiği verileri yeniden gönderirken TCP bağlantısının en yüksek aktarım hızı azalır.

TCP penceresi ölçeklendirme

TCP penceresi ölçeklendirme, bildirim gerekmeden önce daha fazla veri gönderilmesine izin vermek için TCP pencere boyutunu dinamik olarak artıran bir tekniktir. Önceki örnekte, bir bildirim gerekmeden önce 45 paket gönderilecekti. Bildirim gerekmeden önce gönderilebilen paket sayısını artırırsanız, gönderenin onay bekleme sayısını azaltmış olursunuz.

Bu tabloda şu ilişkiler gösterilmektedir:

TCP pencere boyutu (bayt)	RTT gecikme süresi (ms)	Maksimum megabayt/saniye aktarım hızı	Maksimum megabit/saniye aktarım hızı
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

Ancak TCP pencere boyutu için TCP üst bilgi değeri yalnızca 2 bayt uzunluğundadır ve bu da alma penceresi için en yüksek değerin 65.535 olduğu anlamına gelir. En büyük pencere boyutunu artırmak için bir TCP penceresi ölçek faktörü kullanıma sunulmuştur.

Ölçek faktörü aynı zamanda bir işletim sisteminde yapılandırabileceğiniz bir ayardır. Ölçek faktörlerini kullanarak TCP pencere boyutunu hesaplama formülü aşağıdadır:

TCP window size = TCP window size in bytes * (2^scale factor)

3 pencere ölçek faktörü ve 65.535 pencere boyutu hesaplaması aşağıdadır:

65,535 * (2^3) = 524,280 bytes

14 ölçekleme faktörü, TCP penceresi boyutunun 14 olmasına (izin verilen en yüksek kaydırma) neden olur. TCP pencere boyutu 1.073.725.440 bayttır (8,5 gigabit).

TCP penceresi ölçeklendirme desteği

Windows, farklı bağlantı türleri için farklı ölçeklendirme faktörleri ayarlayabilir. (Bağlantı sınıfları veri merkezi, internet vb. içerir.) Pencere ölçeklendirme bağlantı türünü görüntülemek için PowerShell komutunu kullanırsınız Get-NetTCPConnection :

Get-NetTCPConnection

Her sınıfın Get-NetTCPSetting değerlerini görüntülemek için PowerShell komutunu kullanabilirsiniz:

Get-NetTCPSetting

PowerShell komutunu kullanarak Windows'ta ilk TCP pencere boyutunu ve TCP ölçeklendirme faktörünü Set-NetTCPSetting ayarlayabilirsiniz. Daha fazla bilgi için bkz . Set-NetTCPSetting.

Set-NetTCPSetting

Aşağıdaki değerler AutoTuningLevel için etkili TCP ayarlarıdır.

OtoAyarlamaSeviyesi	Ölçeklendirme faktörü	Ölçekleme çarpanı	Formül: en büyük pencere boyutunu hesaplama
Devre dışı	Hiçbiri	Hiçbiri	Pencere boyutu
Kısıtlı	4	2^4	Pencere boyutu * (2^4)
Yüksek oranda kısıtlanmış	2	2^2	Pencere boyutu * (2^2)
Sıradan	8	2^8	Pencere boyutu * (2^8)
Deneysel	14	2^14	Pencere boyutu * (2^14)

Bu ayarların TCP performansını etkileme olasılığı en yüksektir, ancak İnternet'te Azure'ın denetimi dışında birçok başka faktörün de TCP performansını etkileyebileceğini unutmayın.

Hızlandırılmış ağ ve alıcı tarafı ölçeklendirme

Hızlandırılmış ağ

Sanal makine ağ işlevleri geçmişte hem konuk VM'de hem de hiper yöneticide/konakta YOĞUN CPU kullanır. Ana bilgisayar CPU, tüm sanal ağ kapsüllemesi ve kapsülden çıkarma dahil olmak üzere, ana bilgisayar üzerinden geçen tüm paketleri yazılımda işler. Sunucudan ne kadar çok trafik geçerse, CPU yükü o kadar yüksek olur. Eğer sunucu CPU'su, ağ aktarım hızını ve gecikme süresini etkileyen diğer işlemlerle meşgul ise. Azure, hızlandırılmış ağ ile ilgili bu sorunu giderir.

Hızlandırılmış ağ, Azure'ın programlanabilir donanımı ve SR-IOV gibi teknolojiler aracılığıyla tutarlı ultra düşük ağ gecikme süresi sağlar. Hızlandırılmış ağ, Azure yazılım tanımlı ağ yığınının büyük bir kısmını CPU'lardan alıp FPGA tabanlı SmartNIC'lere taşır. Bu değişiklik, son kullanıcı uygulamalarının VM'ye daha az yük getiren işlem döngülerini geri kazanmasını sağlar ve gecikme süresinde değişim ve tutarsızlık azalır. Başka bir deyişle performans daha belirleyici olabilir.

Hızlandırılmış ağ, konuk VM'nin konağı atlamasına ve bir konağın SmartNIC'iyle doğrudan veri yolu oluşturmasına izin vererek performansı artırır. Hızlandırılmış ağ oluşturmanın bazı avantajları şunlardır:

Daha düşük gecikme süresi /saniye başına daha yüksek paketler (pps): Sanal anahtarın veri yolundan kaldırılması, paketlerin ilke işleme için konakta harcadığı süreyi ortadan kaldırır ve VM'de işlenebilen paket sayısını artırır.
Azaltılmış değişim: Sanal anahtar işleme, uygulanması gereken ilke miktarına ve işlemi yapan CPU'nun iş yüküne bağlıdır. Politikaların donanımda uygulanması, paketleri doğrudan VM'ye teslim ederek bu değişkenliği ortadan kaldırır; aynı zamanda konaktan VM'ye iletişimi ve tüm yazılım kesintileri ile bağlam değişikliklerini de ortadan kaldırır.
Daha az CPU kullanımı: Konaktaki sanal anahtarın atlanması, ağ trafiğini işlemek için daha az CPU kullanımına neden olur.

Hızlandırılmış ağ kullanmak için, bunu geçerli her VM'de açıkça etkinleştirmeniz gerekir. Yönergeler için bkz . Hızlandırılmış Ağ ile Linux sanal makinesi oluşturma .

Alma Tarafı Ölçekleme

Alma tarafı ölçeklendirme (RSS), çok işlemcili bir sistemde birden çok CPU'ya alma işlemini dağıtarak ağ trafiğinin alınmasını daha verimli bir şekilde dağıtan bir ağ sürücüsü teknolojisidir. Basit bir ifadeyle RSS, sistemin yalnızca bir cpu yerine tüm kullanılabilir CPU'ları kullandığından daha fazla alınan trafiği işlemesine olanak tanır. RSS hakkında daha teknik bir tartışma için bkz. Yan ölçeklendirmeyi almaya giriş.

Vm'de hızlandırılmış ağ etkinleştirildiğinde en iyi performansı elde etmek için RSS'yi etkinleştirmeniz gerekir. RSS, hızlandırılmış ağ kullanmayan VM'lerde de avantajlar sağlayabilir. RSS'nin etkinleştirilip etkinleştirilmediğini belirlemeye ve etkinleştirmeye genel bakış için bkz. Azure sanal makineleri için ağ aktarım hızını iyileştirme.

TCP TIME_WAIT ve TIME_WAIT suikastı

TCP TIME_WAIT, ağ ve uygulama performansını etkileyen bir diğer yaygın ayardır. Meşgul VM'ler genellikle istemci veya sunucu olarak birçok yuvayı açar ve kapatır. Normal TCP işlemleri sırasında yuva genellikle TIME_WAIT durumuna girer ve uzun süre orada kalır. Bu durum, soket kapanmadan önce kalan verilerin teslim edilmesini sağlar. Sonuç olarak, TCP/IP yığınları genellikle istemcinin TCP SYN paketini sessizce bırakarak yuvanın yeniden kullanılmasını engeller.

Bir soketin ne kadar süreyle TIME_WAIT durumunda kalacağını yapılandırabilirsiniz. Süre 30 saniye ile 240 saniye arasında değişebilir. Soketler sınırlı bir kaynaktır ve kullanılabilirlikleri yapılandırılabilir. Genellikle, herhangi bir zamanda yaklaşık 30.000 yuva kullanılabilir. Sistem tüm kullanılabilir yuvaları kullanıyorsa veya istemciler ve sunucular eşleşmeyen TIME_WAIT ayarları kullanıyorsa, VM hala TIME_WAIT durumda olan bir yuvayı yeniden kullanmaya çalışabilir. Bu gibi durumlarda, TCP SYN paketleri sessizce bırakıldığından yeni bağlantılar başarısız olur.

Giden yuvalar için bağlantı noktası aralığı değeri, bir işletim sisteminin TCP/IP yığını içinde yapılandırılabilir. TCP TIME_WAIT ayarları ve yuva yeniden kullanımı için de aynı şey geçerlidir. Bu sayıların değiştirilmesi ölçeklenebilirliği geliştirebilir. Ancak, duruma bağlı olarak, bu değişiklikler birlikte çalışabilirlik sorunlarına neden olabilir. Bu değerleri değiştirirseniz dikkatli olmanız gerekir.

Bu ölçeklendirme sınırlamasını çözmek için "TIME_WAIT assassination" yöntemini kullanabilirsiniz. TIME_WAIT suikastı, yeni bağlantının IP paketindeki sıra numarasının önceki bağlantıdan gelen son paketin sıra numarasını aşması gibi bazı durumlarda soketin yeniden kullanılmasına olanak tanır. Bu durumda, işletim sistemi yeni bağlantının kurulmasına izin verir (yeni SYN/ACK'yi kabul eder) ve TIME_WAIT durumda olan önceki bağlantıyı kapatmaya zorlar. Bu özellik Azure'daki Windows VM'lerinde desteklenir. Diğer VM'lerdeki destek hakkında bilgi edinmek için işletim sistemi satıcısına başvurun.

TCP TIME_WAIT ayarlarını ve kaynak bağlantı noktası aralığını yapılandırma hakkında bilgi edinmek için bkz. Ağ performansını geliştirmek için değiştirilebilen ayarlar.

Performansı etkileyebilecek sanal ağ faktörleri

VM maksimum giden aktarım hızı

Azure, her biri farklı performans özelliklerine sahip çeşitli VM boyutları ve türleri sağlar. Bu özelliklerden biri, saniyede megabit (Mb/sn) cinsinden ölçülen ağ aktarım hızıdır (veya bant genişliği). Sanal makineler paylaşılan donanımda barındırıldığından, ağ kapasitesinin aynı donanım kullanılarak sanal makineler arasında adil bir şekilde paylaşılması gerekir. Daha büyük sanal makinelere daha küçük sanal makinelerden daha fazla bant genişliği ayrılır.

Her sanal makineye ayrılan ağ bant genişliği, sanal makineden gelen çıkış (giden) trafiğine göre ölçülür. Sanal makineden çıkan tüm ağ trafiği, hedef ne olursa olsun ayrılan sınıra doğru sayılır. Bir sanal makinenin 1.000 Mb/sn sınırı varsa, bu sınır giden trafiğin aynı sanal ağdaki veya Azure dışındaki başka bir sanal makineyi hedefleyip hedeflemeyeceğini belirler.

Giriş doğrudan ölçülmez veya sınırlanmaz. Ancak, sanal makinenin gelen verileri işleme becerisini etkileyebilecek CPU ve depolama sınırları gibi başka faktörler de vardır.

Hızlandırılmış ağ, gecikme süresi, aktarım hızı ve CPU kullanımı dahil olmak üzere ağ performansını geliştirmek için tasarlanmıştır. Hızlandırılmış ağ, bir sanal makinenin aktarım hızını geliştirebilir, ancak bunu yalnızca sanal makinenin ayrılmış bant genişliğine kadar yapabilir.

Azure sanal makinelerine en az bir ağ arabirimi eklenmiştir. Birkaç tane olabilir. Sanal makineye ayrılan bant genişliği, makineye bağlı tüm ağ arabirimleri genelinde giden trafiğin toplamıdır. Başka bir deyişle bant genişliği, makineye bağlı ağ arabirimi sayısına bakılmaksızın sanal makine başına ayrılır.

Beklenen giden aktarım hızı ve her VM boyutu tarafından desteklenen ağ arabirimlerinin sayısı , Azure'daki Windows sanal makineleri için boyutlar bölümünde ayrıntılı olarak yer alır. En yüksek aktarım hızını görmek için Genel amaçlı gibi bir tür seçin ve sonuç sayfasında boyut serisiyle ilgili bölümü bulun (örneğin, "Dv2 serisi"). Her seri için, son sütunda "En Fazla NIC / Beklenen ağ bant genişliği (Mb/sn)" başlıklı ağ belirtimleri sağlayan bir tablo vardır.

Aktarım hızı sınırı sanal makine için geçerlidir. Aktarım hızı şu faktörlerden etkilenmez:

Ağ arabirimi sayısı: Bant genişliği sınırı, sanal makineden gelen tüm giden trafiğin toplamına uygulanır.
Hızlandırılmış ağ: Bu özellik yayımlanan sınıra ulaşmada yardımcı olabilir ancak sınırı değiştirmez.
Trafik hedefi: Tüm hedefler giden sınıra dahil edilir.
Protokol: Tüm protokoller üzerindeki tüm giden trafik sınıra dahil edilir.

Daha fazla bilgi için bkz. Sanal makine ağ bant genişliği.

Linux Sanal Makineleri (VM) İyileştirme

Modern Linux çekirdekleri, bazen belirli iş yükleri için gerekli olan tutarlılık ve performans elde edilmesine yardımcı olabilecek özelliklere sahiptir.

Daha fazla bilgi için bkz . Azure VM'lerinde ağ bant genişliğini iyileştirme

İnternet performansıyla ilgili dikkat edilmesi gerekenler

Bu makalede açıklandığı gibi, İnternet'te ve Azure denetiminin dışındaki faktörler ağ performansını etkileyebilir. Bu faktörlerden bazıları şunlardır:

Gecikme süresi: İki uç nokta arasındaki gidiş dönüş süresi, ara ağlardaki sorunlardan, "en kısa" mesafe yolunu almayan trafikten ve en iyi olmayan eşleme yollarından etkilenir.
Paket kaybı: Paket kaybına ağ tıkanıklığı, fiziksel yol sorunları ve yetersiz performansa sahip ağ cihazları neden olur.
MTU boyutu/Parçalanma: Yol boyunca parçalanma, verilerin ulaşmasında veya paketlerde sıra dışı gelen paketlerde gecikmelere yol açabilir ve bu da paketlerin teslimini etkileyebilir.

Traceroute, kaynak cihaz ile hedef cihaz arasındaki her ağ yolu boyunca ağ performansı özelliklerini (paket kaybı ve gecikme süresi gibi) ölçmek için iyi bir araçtır.

Ağ tasarımıyla ilgili dikkat edilmesi gerekenler

Bu makalenin önceki bölümlerinde ele alınan konuların yanı sıra, sanal ağın topolojisi ağın performansını etkileyebilir. Örneğin, trafiği küresel olarak tek bir merkezli sanal ağına geri taşıyan merkez-uç tasarımı, genel ağ performansını etkileyen ağ gecikmesine neden olur.

Ağ trafiğinin geçtiği ağ cihazlarının sayısı da genel gecikme süresini etkileyebilir. Merkez-uç tasarımında trafik, İnternet'e geçmeden önce uç ağ sanal gereci ve merkez sanal gereci üzerinden geçerse, ağ sanal gereçleri biraz gecikmeye neden olur.

Azure bölgeleri, sanal ağlar ve gecikme süresi

Azure bölgeleri, genel bir coğrafi bölgede bulunan birden çok veri merkezinden oluşur. Bu veri merkezleri fiziksel olarak yan yana olmayabilir. Bazı durumlarda, 10 kilometreye kadar ayrılırlar. Sanal ağ, Azure fiziksel veri merkezi ağının üzerindeki mantıksal bir katmandır. Sanal ağ, veri merkezinde belirli bir ağ topolojisi anlamına gelmez.

Örneğin, aynı sanal ağda ve alt ağda bulunan iki VM farklı raflarda, satırlarda ve hatta veri merkezlerinde olabilir. Fiber optik kabloyla metrelerce veya kilometrelerce ayrılabilirler. Bu varyasyon, farklı VM'ler arasında değişken gecikme süresi (birkaç milisaniye fark) ortaya çıkabilir.

VM'lerin coğrafi yerleşimi ve iki VM arasındaki olası gecikme süresi, kullanılabilirlik kümelerinin, yakınlık yerleştirme gruplarının ve kullanılabilirlik alanlarının yapılandırmasından etkilenir. Ancak bir bölgedeki veri merkezleri arasındaki mesafe bölgeye özgüdür ve öncelikle bölgedeki veri merkezi topolojisi tarafından etkilenir.

Kaynak NAT port tükenmesi

Azure'daki bir dağıtım, genel İnternet üzerinden ve/veya genel IP alanında Azure dışındaki uç noktalarla iletişim kurabilir. Bir örnek bir giden bağlantı başlattığında, Azure özel IP adresini bir genel IP adresiyle dinamik olarak eşler. Azure bu eşlemeyi oluşturduğunda, giden akışın dönüş trafiği de akışın kaynaklandığı özel IP adresine ulaşabilir.

Her giden bağlantı için Azure Load Balancer'ın bu eşlemeyi belirli bir süre boyunca koruması gerekir. Azure'ın çok kiracılı yapısıyla, her VM için her dışa yönlendirilmiş akış için bu eşlemenin sürdürülmesi kaynak yoğun olabilir. Bu nedenle, Azure Sanal Ağ'ın yapılandırmasına bağlı olarak belirlenen sınırlar vardır. Veya, daha doğru bir şekilde ifade etmek gerekirse, bir Azure VM herhangi bir anda yalnızca bazı giden bağlantılar kurabilir. Bu sınırlara ulaşıldığında VM daha fazla giden bağlantı yapmaz.

Ancak bu davranış yapılandırılabilir. SNAT ve SNAT bağlantı noktası tükenmesi hakkında daha fazla bilgi için bu makaleye bakın.

Azure'da ağ performansını ölçme

Bu makaledeki performans üst düzeylerinin çoğu, iki VM arasındaki ağ gecikme süresi / gidiş dönüş süresi (RTT) ile ilgilidir. Bu bölümde gecikme süresini/RTT'yi test etme ve TCP performansını ve VM ağ performansını test etme hakkında bazı öneriler sağlanmaktadır. Bu bölümde açıklanan teknikleri kullanarak daha önce açıklanan TCP/IP ve ağ değerlerini ayarlayabilir ve performans testini yapabilirsiniz. Daha önce sağlanan hesaplamalara gecikme süresi, MTU, MSS ve pencere boyutu değerlerini girin ve teorik maksimum değerleri test sırasında gözlemlenen gerçek değerlerle karşılaştırın.

Gidiş dönüş süresini ve paket kaybını ölçme

TCP performansı büyük ölçüde RTT ve paket Kaybına dayanır. Windows ve Linux'ta kullanılabilen PING yardımcı programı, RTT ve paket kaybını ölçmenin en kolay yolunu sağlar. PING çıkışı, kaynak ve hedef arasındaki en düşük/en yüksek/ortalama gecikme süresini gösterir. Paket kaybını gösterir. PING varsayılan olarak ICMP protokolunu kullanır. TCP RTT'yi test etmek için PsPing kullanabilirsiniz. Daha fazla bilgi için bkz. PsPing.

ICMP ve TCP ping'leri hızlandırılmış ağ veri yolu ölçmez. Veri yolu ölçmek için bu makaledeki Latte ve SockPerf hakkında bilgi edinin.

Sanal makinenin gerçek bant genişliğini ölçme

Azure VM'lerinin bant genişliğini doğru bir şekilde ölçmek için bu kılavuzu izleyin.

Diğer senaryoları test etme hakkında daha fazla bilgi için şu makalelere bakın:

Verimsiz TCP davranışlarını algılama

Paket yakalamalarında Azure müşterileri, ağ performansı sorunlarını gösterebilecek TCP bayraklarına (SACK, DUP ACK, RETRANSMIT ve FAST RETRANSMIT) sahip TCP paketlerini görebilir. Bu paketler özellikle paket kaybından kaynaklanan ağ verimsizliklerini gösterir. Ancak paket kaybı, Azure performans sorunlarından kaynaklı olmayabilir. Performans sorunları uygulama, işletim sistemi veya Doğrudan Azure platformuyla ilgili olmayan diğer sorunların sonucu olabilir.

Ayrıca, ağ üzerinde bazı yeniden iletim ve yinelenen ACK'lerin normal olduğunu unutmayın. TCP protokolleri güvenilir olacak şekilde oluşturulmuş. Paket yakalamadaki bu TCP paketlerinin kanıtı, aşırı olmadığı sürece sistemik bir ağ sorununa işaret etmez.

Yine de bu paket türleri, bu makalenin diğer bölümlerinde açıklanan nedenlerle TCP aktarım hızının en yüksek performansa ulaşmadığının göstergesidir.

Sonraki adımlar

Azure VM'leri için TCP/IP performansı ayarlama hakkında bilgi edindiğinize göre , sanal ağları planlamaya yönelik diğer faktörleri incelemeyi göz önünde bulundurun. Ayrıca sanal ağları bağlama ve yapılandırma hakkında daha fazla bilgi edinebilirsiniz.