Azure sanal makineleri için TCP/IP performans ayarlaması
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ğlayacak ve bunların nasıl ayarlanabileceğini keşfedecektir.
Yaygın TCP/IP ayarlama teknikleri
MTU, parçalanma ve büyük gönderme yükü
MTU
Maksimum iletim birimi (MTU), bir ağ arabirimi üzerinden gönderilebilen bayt cinsinden belirtilen en büyük boyut çerçevesidir (paket). MTU yapılandırılabilir bir ayardır. Azure VM'lerinde kullanılan varsayılan MTU ve genel olarak ç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) böler. 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 bölünecektir.
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çalanma biti
Parçalanma (DF) biti, IP protokolü üst bilgisindeki 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ı Parçalama bit kümesine sahip bir paket aldığında ve bu paket cihazın MTU arabirimini 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 olumsuz performans etkileri olabilir. Performans üzerindeki etkinin temel nedenlerinden biri, paketlerin parçalanması ve yeniden bir araya bağlanması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ı 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'daki parçalanmış paketler Hızlandırılmış Ağ tarafından işlenmez. Bir VM parçalanmış bir paket aldığında hızlandırılmamış yol üzerinden işlenir. Bu, parçalanmış paketlerin Hızlandırılmış Ağ (daha düşük gecikme süresi, düşük gecikme süresi ve saniye başına daha yüksek paketler) avantajlarından yararlanacağı anlamına gelir. Bu nedenle mümkünse parçalanmayı önlemenizi öneririz.
Varsayılan olarak, Azure sıra parçalarını, yani vm'ye kaynak uç noktadan iletildiği sırada gelmeyen parçalanmış paketleri bırakır. Paketler İnternet veya diğer büyük WAN'ler üzerinden iletildiğinde bu durum oluşabilir. Bazı durumlarda sıra dışı parça yeniden sıralama etkinleştirilebilir. Bir uygulama bunu gerektiriyorsa bir destek olayı açın.
MTU'da ayarlama
Müşterilerin VM NIC'lerinde MTU'ları artırmasını önermiyoruz. VM'nin benzer bir MTU kümesine sahip Sanal Ağ olmayan hedeflerle iletişim kurması gerekiyorsa parçalanma meydana gelir ve bu da performansı düşürür.
Büyük gönderme yükü
Büyük gönderme boşaltması (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 donanımda gerçekleştirilen Ethernet arabirimine boşaltabilmesidir. 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ı gerçekleştirdiklerinde büyük çerçeve boyutları görebilir. Bu büyük çerçeve boyutları, bazı müşterilerin parçalanmanın oluştuğunu veya büyük bir MTU'nun kullanılmadığında kullanıldığını düşünmesine 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. Bu kesimsiz çerçevenin tamamı daha sonra Ethernet bağdaştırıcısına iletilir ve VM'de gerçekleştirilen paket yakalama işleminde görünür. Ancak paket, Ethernet bağdaştırıcısının MTU'suna göre Ethernet bağdaştırıcısı tarafından çok daha küçük çerçevelere bölünecektir.
TCP MSS penceresi ölçeklendirme ve PMTUD
TCP en büyük kesim boyutu
TCP en büyük kesim boyutu (MSS), TCP paketlerinin parçalanmasından kaçınan TCP kesimlerinin 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. Bu nedenle, 1.500 MTU'ya sahip bir arabirimde 1.460 MSS olacaktır. Ancak MSS yapılandırılabilir.
Bu ayar, bir kaynak ile hedef arasında tcp oturumu ayarlandığında TCP üç yönlü el sıkışması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 anlaşması yapılır, ancak kullanılabilecek gerçek MSS'yi göstermeyebilir. Bunun nedeni, kaynak ve hedef arasındaki yoldaki diğer ağ cihazlarının kaynak ve hedeften daha düşük bir MTU değerine sahip olmasıdır. 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 verimsizdir ve ağ performansını etkiler. Ağ yolunun MTU'sunu aşan paketler gönderildiğinde, paketlerin daha düşük bir MSS ile yeniden iletilmesi gerekir. Gönderen ICMP Parçalanması Gerekiyor iletisini almazsa, yoldaki bir ağ güvenlik duvarı (genellikle PMTUD kara deliği olarak adlandırılır) nedeniyle gönderen, MSS'yi düşürmesi gerektiğini bilmez ve paketi sürekli olarak yeniden gönderir. Bu nedenle Azure VM MTU'nun 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 bazı ek noktalar vardır. VPN'ler paketlere daha fazla üst bilgi ekler ve bu da 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
Ağ gecikme süresi, fiber optik ağ üzerindeki ışık hızına tabidir. TCP'nin ağ aktarım hızı da iki ağ cihazı arasındaki gidiş dönüş süresine (RTT) etkili bir şekilde tabidir.
| Rota | Mesafe | Tek yönlü zaman | RTT |
|---|---|---|---|
| New York -San Francisco | 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. Bu mesafe, kilometre cinsinden, ışık 1 milisaniye içinde hareket ediyor.
Örnek olarak New York'ı San Francisco'ya götürelim. Düz hat mesafesi 4.148 km'dir. Bu değeri denkleme taktığımızda şunları elde ederiz:
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 onay 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ış.
RtT'nin TCP aktarım hızını etkilemesine neden olan, verilerin güvenilir bir şekilde teslim edilmesini sağlayan bir mekanizma olan bu "onay 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 | .73 | 5,83 |
| 65,535 | 120 | 55. | 4.37 |
Paketler kaybolursa, gönderen daha önce 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, bir onay gerekmeden önce daha fazla veri gönderilmesine izin vermek için TCP pencere boyutunu dinamik olarak artıran bir tekniktir. Önceki örnekte, bir onay gerekli olmadan önce 45 paket gönderilecekti. Bir onay gerekmeden önce gönderilebilen paket sayısını artırırsanız, gönderenin onay bekleme sayısını azaltırsınız ve bu da TCP en yüksek aktarım hızını artırır.
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çek faktörü, TCP penceresi boyutunun 14 olmasına (izin verilen en yüksek uzaklık) neden olur. TCP pencere boyutu 1.073.725.440 bayt (8,5 gigabit) olacaktır.
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
Bunlar için AutoTuningLevelgeçerli TCP ayarlarıdır:
| AutoTuningLevel | Ölçeklendirme faktörü | Çarpanı ölçeklendirme | 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) |
| Normal | 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 alma tarafı ölçeklendirmesi
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 kullanmıştır. Konak üzerinden geçen her paket, tüm sanal ağ kapsüllemesi ve kapsüllemesi dahil olmak üzere konak CPU'sunun yazılımlarında işlenir. Dolayısıyla konak üzerinden geçen trafik ne kadar fazla olursa CPU yükü de o kadar yüksek olur. Konak CPU'sunun diğer işlemlerle meşgul olması, ağ aktarım hızını ve gecikme süresini de etkiler. 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 ve FPGA tabanlı SmartNIC'lere taşır. Bu değişiklik, son kullanıcı uygulamalarının işlem döngülerini geri kazanmasını sağlar ve bu da VM'ye daha az yük getirir ve gecikme süresindeki değişim ve tutarsızlıkları düşürü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. İlke zorlamasının donanıma boşaltılması, paketleri doğrudan VM'ye teslim ederek bu değişkenliği ortadan kaldırır ve konaktan VM'ye iletişimi ve tüm yazılım kesintileri ile bağlam anahtarlarını 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çeklendirme
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. İstemci olarak veya sunucu olarak (Kaynak IP:Kaynak Bağlantı Noktası + Hedef IP:Hedef Bağlantı Noktası) birçok yuvayı açan ve kapatan meşgul VM'lerde, TCP'nin normal işlemi sırasında, belirli bir yuva uzun süre TIME_WAIT durumunda olabilir. TIME_WAIT durumu, yuvayı kapatmadan önce ek verilerin teslim edilmesine izin vermek için tasarlanmıştır. Bu nedenle TCP/IP yığınları genellikle istemcinin TCP SYN paketini sessizce bırakarak yuvanın yeniden kullanılmasını engeller.
Yuvanın TIME_WAIT miktarı yapılandırılabilir. 30 saniye ile 240 saniye arasında değişebilir. Yuvalar sonlu bir kaynaktır ve herhangi bir zamanda kullanılabilecek yuva sayısı yapılandırılabilir. (Kullanılabilir yuva sayısı genellikle yaklaşık 30.000'dir.) Kullanılabilir yuvalar kullanılırsa veya istemciler ve sunucular TIME_WAIT ayarlarıyla eşleşmediyse ve vm yuvayı TIME_WAIT durumunda yeniden yüklemeye çalışırsa, 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 genellikle 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ı gidermek için TIME_WAIT suikastı kullanabilirsiniz. TIME_WAIT suikastı, yeni bağlantının IP paketindeki sıra numarasının önceki bağlantıdaki son paketin sıra numarasını aşması gibi bazı durumlarda yuvanın 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. Örneğin, 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 tarifeli veya sınırlı değildir. 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 doğru sayılır.
Protokol: Tüm protokoller üzerindeki tüm giden trafik sınıra doğru sayılır.
Daha fazla bilgi için bkz . Sanal makine ağ bant genişliği.
İ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 hedef 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 etkilenebilir.
Paket kaybı: Paket kaybına ağ tıkanıklığı, fiziksel yol sorunları ve yetersiz performansa sahip ağ cihazları neden olabilir.
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 genel olarak tek merkezli bir sanal ağa geri aktaran merkez-uç tasarımı, ağ gecikme süresini getirir ve bu da genel ağ performansını etkiler.
Ağ trafiğinin geçtiği ağ cihazlarının sayısı da genel gecikme süresini etkileyebilir. Örneğin 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 gecikmeye neden olabilir.
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. Bunlar fiber optik kablonun ayaklarıyla veya kilometreler boyu fiber optik kabloyla ayrılabilir. 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 ve Kullanılabilirlik Alanları yapılandırmasından etkilenebilir. 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 bağlantı noktası 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 giden akış için bu eşlemenin sürdürülmesi yoğun kaynak kullanabilir. Bu nedenle Azure Sanal Ağ yapılandırmasına göre ayarlanan ve temel alan sınırlar vardır. Veya bir Azure VM'sinin belirli bir zamanda yalnızca belirli sayıda giden bağlantı oluşturabileceğini söylemek gerekir. Bu sınırlara ulaşıldığında VM daha fazla giden bağlantı kuramaz.
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 sınırlarından bazıları 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. Gecikme süresi, MTU, MSS ve pencere boyutu değerlerini daha önce sağlanan hesaplamalara takabilir ve teorik maksimum değerleri test sırasında gözlemlediğiniz gerçek değerlerle karşılaştırabilirsiniz.
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 çıktısı, kaynak ve hedef arasındaki en düşük/en yüksek/ortalama gecikme süresini gösterir. Ayrıca paket kaybını da 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.
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 ayrıntı 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 sorunlarının, işletim sistemi sorunlarının 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ı planlama konusunda dikkat edilmesi gereken diğer noktalar hakkında bilgi edinmek veya sanal ağları bağlama ve yapılandırma hakkında daha fazla bilgi edinmek isteyebilirsiniz.