Ağ performansı sorunlarını giderme

Özet

Azure, şirket içi ağınızı Azure bağlamak için kararlı ve hızlı bir yol sağlar. Her büyüklükteki müşteriler, işlerini Azure'da çalıştırmak için Siteden Siteye VPN ve ExpressRoute gibi yöntemleri kullanır. Ancak performans beklentilerinizi veya önceki deneyiminizi karşılamadığında ne olur? Bu makale, ortamınızı test ve temellendirme yönteminizi standartlaştırmanıza yardımcı olur.

İki konak arasındaki ağ gecikme süresini ve bant genişliğini kolayca ve tutarlı bir şekilde test etmeyi öğreneceksiniz. Ayrıca sorun noktalarını yalıtmaya yardımcı olmak için Azure ağına bakma yolları hakkında öneriler alırsınız. Ele alınan PowerShell betiği ve araçları için ağda iki ana bilgisayar gerekir (bağlantının her iki ucunda da test edilir). Bir konağın Windows Server veya Masaüstü olması, diğer konağın Windows veya Linux olması gerekir.

Ağ bileşenleri

Sorun gidermeyi araştırmadan önce bazı yaygın terimleri ve bileşenleri tartışalım. Bu tartışma, uçtan uca zincirdeki ve Azure bağlantı sağlayan her bileşeni düşünmenizi sağlar.

En yüksek düzeyde üç ana ağ yönlendirme etki alanı vardır:

• Azure ağı (mavi bulut)
• İnternet veya WAN (yeşil bulut)
• Kurumsal Ağ (turuncu bulut)

Diyagrama sağdan sola doğru baktığımızda her bileşeni kısaca inceleyelim:

• Sanal Makine - Sunucuda birden çok NIC olabilir. Statik yolların, varsayılan yolların ve işletim sistemi ayarlarının trafiği beklediğiniz gibi gönderip aldığından emin olun. Ayrıca, her VM SKU'su bir bant genişliği kısıtlaması içerir. Daha küçük bir VM SKU'su kullanıyorsanız trafiğiniz NIC'nin kullanabileceği bant genişliğiyle sınırlıdır. VM'de yeterli bant genişliği sağlamak için test için DS5v2 kullanın.

• NIC - Söz konusu NIC'ye atanan özel IP'yi bildiğinizden emin olun.

• NIC NSG - NIC düzeyinde belirli NSG'ler uygulanmış olabilir. NSG kural kümesinin geçirmeye çalıştığınız trafik için uygun olduğundan emin olun. Örneğin, test trafiğinin geçmesine izin vermek için iPerf için 5201, RDP için 3389 veya SSH için 22 bağlantı noktalarının açık olduğundan emin olun.

• Sanal Ağ Alt Ağı - NIC belirli bir alt ağa atanır. Hangi alt ağ ve bu alt ağ ile ilişkili kuralları bildiğinizden emin olun.

• Alt ağ NSG'leri - NIC'de olduğu gibi alt ağ düzeyinde de NSG'ler uygulayabilirsiniz. NSG kural kümesinin geçirmeye çalıştığınız trafik için uygun olduğundan emin olun. NIC'e gelen trafik için önce alt ağ NSG, sonra NIC NSG uygulanır. Trafik VM'den dışarıya doğru gittiğinde önce NIC NSG uygulanır, ardından Alt Ağ NSG uygulanır.

• Alt Ağ UDR - Kullanıcı Tanımlı Rotalar, trafiği güvenlik duvarı veya yük dengeleyici gibi bir ara sıçrama noktasına yönlendirebilir. Trafiğiniz için bir UDR olup olmadığını bildiğinizden emin olun. Eğer öyleyse, nereye yönlendiğini ve sonraki atlamanın trafiğinizi nasıl etkilediğini anlayın. Örneğin, bir güvenlik duvarı, aynı iki host arasındaki bazı trafiği geçirebilir ve diğer trafiği reddedebilir.

• Ağ geçidi alt ağı / NSG / UDR - VM alt ağı gibi ağ geçidi alt ağına da NSG'ler ve UDR'ler olabilir. Orada olup olmadığını ve trafiğinizde ne gibi etkileri olduğunu bildiğinizden emin olun.

• VNet Gateway (ExpressRoute) - Eşlenme (ExpressRoute) veya VPN etkinleştirildikten sonra, trafiğin yönlendirilip yönlendirilmediğini veya nasıl yönlendirildiğini etkileyebilecek pek fazla ayar yoktur. Birden çok ExpressRoute bağlantı hattına veya VPN tüneline bağlı bir sanal ağ geçidiniz varsa, bağlantı ağırlığı ayarlarına dikkat edin. Bağlantı ağırlığı, bağlantı tercihini etkiler ve trafiğinizin izlediği yolu belirler.

• Route Filtresi (Gösterilmiyor) - ExpressRoute aracılığıyla Microsoft Eşleme kullanılırken yol filtresi gereklidir. Eğer herhangi bir rota almıyorsanız, rota filtresinin düzgün bir şekilde yapılandırılıp yapılandırılmadığını ve devreye doğru olarak uygulanıp uygulanmadığını denetleyin.

Bu noktada, bağlantının WAN bölümündesiniz. Bu yönlendirme etki alanı hizmet sağlayıcınız, şirket WAN'ınız veya İnternet olabilir. Bu bağlantılarda birçok ara bağlantı, cihaz ve şirket yer alır; bu da sorun gidermeyi zorlaştırabilir. Ara atlamaları araştırmadan önce hem Azure hem de kurumsal ağlarınızı dışlamalısınız.

Yukarıdaki diyagramda, en soldaki şirket ağınızdır. Şirketinizin boyutuna bağlı olarak, bu yönlendirme etki alanı sizinle WAN arasında birkaç ağ cihazı veya bir kampüs veya kurumsal ağdaki birden çok cihaz katmanı olabilir.

Bu üç farklı üst düzey ağ ortamlarının karmaşıklığı göz önünde bulundurulduğunda, genellikle kenarlardan başlayıp performansın nerede iyi olduğunu ve nerede düşeceğini göstermeye çalışmak en uygun seçenektir. Bu yaklaşım, üçünün sorun yönlendirme etki alanını belirlemeye yardımcı olabilir. Daha sonra sorun gidermenizi belirli bir ortama odaklayabilirsiniz.

Tools

Ping ve traceroute gibi temel araçları kullanarak ağ sorunlarının çoğunu analiz edebilir ve yalıtabilirsiniz. Wireshark gibi araçları kullanarak paket analizi kadar derine gitmeniz çok nadirdir.

Sorun gidermeye yardımcı olmak için Azure Bağlantı Araç Seti (AzureCT), bu araçlardan bazılarını kolay bir pakete koymak için geliştirilmiştir. Performans testi için iPerf ve PSPing gibi araçlar size ağınız hakkında bilgi sağlayabilir. iPerf, temel performans testleri için yaygın olarak kullanılan bir araçtır ve kullanımı oldukça kolaydır. PSPing, SysInternals tarafından geliştirilen bir ping aracıdır. PSPing, uzak bir ana bilgisayara ulaşmak için hem ICMP hem de TCP ping işlemleri gerçekleştirebilir. Bu araçların her ikisi de basittir ve yalnızca dosyaları konak üzerindeki bir dizine kopyalayarak "yüklenir".

Bu araçları ve yöntemleri sarmalayan bir PowerShell modülü (AzureCT) kullanabilirsiniz.

AzureCT - Azure Bağlantı Araç Seti

AzureCT PowerShell modülü iki bileşen içerir: Availability Testing ve Performance Testing. Bu makalede Performans Testi, özellikle de bu PowerShell modülündeki iki Bağlantı Performansı komutu ele alınır.

Performans Testi için bu araç setini kullanmak için şu üç temel adımı izleyin:

1. PowerShell Modülünü yükleme

   (new-object Net.WebClient).DownloadString("https://aka.ms/AzureCT") | Invoke-Expression
   

   Bu komut PowerShell modülünü yerel olarak indirir ve yükler.

2. Destekleyici Uygulamaları Yükleme

   Install-LinkPerformance
   

   Bu AzureCT komutu, iPerf ve PSPing'i yeni bir dizin C:\ACTTools yükler ve ICMP ve bağlantı noktası 5201 (iPerf) trafiğine izin vermek için Windows Güvenlik Duvarı bağlantı noktalarını açar.

3. Performans Testini Çalıştırma

   İlk olarak, uzak ana bilgisayarda iPerf'i sunucu modunda yükleyin ve çalıştırın. Uzak konağın 3389 (Windows için RDP) veya 22 (Linux için SSH) üzerinde dinlediğinden ve iPerf için 5201 numaralı bağlantı noktasında trafiğe izin olduğundan emin olun. Uzak ana bilgisayar Windows ise, AzureCT'yi yükleyin ve iPerf'i kurmak ve gerekli güvenlik duvarı kurallarını yapılandırmak için Install-LinkPerformance komutunu çalıştırın.

   Uzak makine hazır olduğunda yerel makinede PowerShell'i açın ve testi başlatın:

   Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10
   

   Bu komut, ağ bağlantınızın bant genişliği kapasitesini ve gecikme süresini tahmin etmek için bir dizi eşzamanlı yük ve gecikme testi çalıştırır.

4. Test Çıkışını Gözden Geçirme

   PowerShell çıkış biçimi şuna benzer:

   

   Tüm iPerf ve PSPing testlerinin ayrıntılı sonuçları, C:\ACTTools konumundaki AzureCT araçları dizininde ayrı metin dosyalarına kaydedilir.

Performans sorunlarını giderme

Performans testi sonuçları beklediğiniz gibi değilse, sorunu belirlemek için sistematik bir yaklaşım izleyin. Yoldaki bileşen sayısı göz önüne alındığında, adım adım bir işlem rastgele testten daha etkilidir.

Uyarı

Bu senaryo bir performans sorunudur, bağlantı sorunu değildir. Azure ağıyla bağlantı sorunlarını yalıtmak için bkz. ExpressRoute bağlantısını doğrulama.

1. Varsayımlarınıza meydan okuma

   Beklentilerinizin makul olduğundan emin olun. Örneğin, 1 Gb/sn ExpressRoute bağlantı hattı ve 100 ms gecikme süresiyle, yüksek gecikmeli bağlantılar üzerinden TCP'nin performans özellikleri nedeniyle 1 Gb/sn'lik trafiğin tam olarak beklenmesi gerçekçi değildir. Performans varsayımları hakkında daha fazla bilgi için Başvurular bölümüne bakın.

2. Ağın kenarından başlayın

   Yönlendirme etki alanları arasındaki kenarlardan başlayın ve sorunu tek bir ana yönlendirme etki alanıyla yalıtmaya çalışın. Bu varsayım çözümü geciktirebileceği için, kapsamlı bir araştırma yapmadan yolda "kara kutuyu" suçlamaktan kaçının.

3. Diyagram oluşturma

   Sorunu yöntemsel olarak çalışmak ve yalıtmak için söz konusu alanın diyagramını çizin. Test noktalarını planlayın ve alanları temizledikçe veya daha derine indikçe haritayı güncelleştirin.

4. Böl ve fethet

   Ağı segmentlere ayırma ve sorunu daraltma. Nerede çalıştığını ve nerede çalışmadığını belirleyin. Sorunlu bileşeni yalıtmak için test noktalarınızı taşımaya devam edin.

5. Tüm OSI katmanlarını göz önünde bulundurun

   Ağ ve 1-3 katmanlarına (Fiziksel, Veri ve Ağ katmanları) odaklanmak yaygın olsa da, sorunların Katman 7'de (Uygulama katmanı) da oluşabileceğini unutmayın. Açık fikirli olun ve tüm varsayımları doğrulayın.

Gelişmiş ExpressRoute sorunlarını giderme

Bulutun kenarının nerede olduğundan emin değilseniz Azure bileşenleri yalıtma zor olabilir. ExpressRoute ile uç nokta, Microsoft Enterprise Edge (MSEE) adlı bir ağ bileşenidir. MSEE, Microsoft'un ağına ilk giriş noktası ve çıkarken son atlama noktasıdır. Sanal ağ geçidinizle ExpressRoute bağlantı hattı arasında bir bağlantı oluşturduğunuzda, MSEE'ye bağlanırsınız. MSEE'yi ilk veya son atlama olarak tanımak, Azure ağ sorununu yalıtma açısından çok önemlidir. Trafik yönünü bilmek, sorunun WAN veya şirket ağında Azure veya daha aşağı akışta olup olmadığını belirlemenize yardımcı olur.

Uyarı

MSEE, Azure bulutta değildir. ExpressRoute, Azure değil, Microsoft ağının kenarındadır. ExpressRoute ile bir MSEE'ye bağlandıktan sonra, Microsoft'un ağına bağlanırsınız ve bu da Microsoft 365 (Microsoft Eşlemeleri ile) veya Azure (Özel ve/veya Microsoft Eşlemeleri ile) gibi bulut hizmetlerine erişmenizi sağlar.

İki sanal ağ aynı ExpressRoute bağlantı hattına bağlıysa, Azure'da sorunu izole etmek için testler gerçekleştirilebilir.

Test planı

1. VM1 ile VM2 arasında Get-LinkPerformance testini çalıştırın. Bu test, sorunun yerel olup olmadığına ilişkin içgörü sağlar. Test kabul edilebilir gecikme süresi ve bant genişliği sonuçları üretirse, yerel sanal ağı iyi olarak işaretleyebilirsiniz.

2. Yerel sanal ağ trafiğinin iyi olduğunu varsayarak VM1 ile VM3 arasında Get-LinkPerformance testini çalıştırın. Bu test, Microsoft ağı üzerinden MSEE'ye kadar olan bağlantıyı test eder ve Azure'a geri döner. Test kabul edilebilir gecikme süresi ve bant genişliği sonuçları üretirse, Azure ağı iyi olarak işaretleyebilirsiniz.

3. Azure hariç tutulursa, şirket ağınızda benzer testler yapın. Bu testler de iyiyse, WAN bağlantınızı tanılamak için hizmet sağlayıcınızla veya ISS'nizle birlikte çalışın. Örneğin, testleri iki şube ofisi arasında veya masanızla bir veri merkezi sunucusu arasında çalıştırın. Test ettiğiniz yolu kullanabilen sunucular ve istemci bilgisayarlar gibi uç noktaları bulun.

Önemli

Her test için günün saatini işaretleyin ve sonuçları ortak bir konuma kaydedin. Tutarlı veri karşılaştırması için her test çalıştırması aynı çıktıya sahip olmalıdır. Birden çok testte tutarlılık, sorun giderme için AzureCT kullanmanın birincil nedenidir. Anahtar, her seferinde tutarlı test ve veri çıkışı almaktır. Sorunun düzensiz olması durumunda saati kaydetmek ve tutarlı verilere sahip olmak özellikle yararlıdır. Aynı senaryoları saatlerce yeniden test etmekten kaçınmak için veri toplama konusunda dikkatli olun.

Sorun yalıtılmış, şimdi ne olacak?

Sorunu ne kadar çok yalıtırsanız, o kadar hızlı bir çözüm bulabilirsiniz. Bazen sorun giderme konusunda daha fazla ilerleyemezsiniz. Örneğin, Asya'da kalmasını beklediğiniz zaman hizmet sağlayıcınız genelinde bağlantının Avrupa üzerinden atlayıp geçtiğini görebilirsiniz. Bu noktada, sorunu yalıttığınız yönlendirme etki alanına göre yardım alabileceğiniz biriyle bağlantı kurun. Belirli bir bileşene daraltmak daha da iyidir.

Kurumsal ağ sorunları için, iç BT departmanınız veya hizmet sağlayıcınız cihaz yapılandırması veya donanım onarımı konusunda yardımcı olabilir.

WAN sorunları için test sonuçlarınızı hizmet sağlayıcınızla veya ISS'nizle paylaşarak işlerinde yardımcı olun ve yedekli görevlerden kaçının. Güven ama doğrula ilkesine dayanarak sonuçlarınızı doğrulamak isteyebilirler.

Azure sorunları için, sorunu mümkün olduğunca ayrıntılı bir şekilde yalıtdıktan sonra Azure Ağ Belgeleri'ni gözden geçirin ve gerekirse destek bileti açın.

Kaynaklar

Gecikme süresi ve bant genişliği beklentileri

Tavsiye

Uç noktalar arasındaki coğrafi uzaklık, gecikme süresindeki en büyük faktördür. Ekipman kaynaklı gecikme de (fiziksel ve sanal bileşenler, atlama sayısı ve diğer etkenler) rol oynasa da, asıl belirleyici etken düz çizgi mesafesi değil, fiber hattın uzunluğudur. Bu mesafeyi doğru bir şekilde ölçmek zordur, bu nedenle kaba bir tahmin için şehir uzaklığı hesaplayıcısını kullanın.

Örneğin, Seattle, Washington, ABD'de bir ExpressRoute ayarlarsınız. Aşağıdaki tabloda, çeşitli Azure konumlarında test yaparken gözlemlediğiniz gecikme süresi ve bant genişliği ile tahmini uzaklıklar gösterilmektedir.

Test kurulumu:

• ExpressRoute bağlantı hattına bağlı 10 Gb/sn NIC ile Windows Server 2016 çalıştıran bir fiziksel sunucu.

• Özel Eşlemenin etkinleştirildiği 10 Gbps Premium ExpressRoute devresi.

• Belirtilen bölgede UltraPerformance ağ geçidine sahip Azure bir sanal ağ.

• AzureCT'nin yüklü olduğu varsayılan Azure görüntüsünü kullanarak sanal ağda Windows Server 2016 çalıştıran bir DS5v2 VM.

• Tüm testler, altı test çalıştırmasının her biri için 5 dakikalık yük testi ile AzureCT Get-LinkPerformance komutunu kullanır. Örneğin:

  Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300
  

• Her testin veri akışı şirket içi sunucudan (Seattle'daki iPerf istemcisi) Azure VM'ye (listelenen Azure bölgedeki iPerf sunucusu) kadardır.

• "Gecikme Süresi" sütunu Yük Yok testinden (iPerf çalıştırılmadan TCP gecikme testi) verileri gösterir.

• "En Yüksek Bant Genişliği" sütunu, 1 Mb pencere boyutuna sahip 16 TCP akış yük testinden verileri gösterir.

Gecikme süresi ve bant genişliği sonuçları

Önemli

Bu sayıları yalnızca genel başvuru için kullanın. Gecikme süresini etkileyen birçok faktör vardır ve bu değerler zaman içinde genel olarak tutarlı olsa da, Azure veya hizmet sağlayıcısının ağındaki koşullar değişebilir ve bu da gecikme süresini ve bant genişliğini etkiler. Genellikle bu değişiklikler önemli farklılıklara neden olmaz.

ExpressRoute Konumu	Azure Bölgesi	Tahmini Mesafe (km)	Gecikme	1 Oturum Bant Genişliği	En Fazla Bant Genişliği
Seattle	Batı ABD 2	191 km	5 ms	262,0 Mbit/sn	3,74 Gbit/sn
Seattle	West US	1.094 km	18 ms	82,3 Mbit/sn	3,70 Gbit/sn
Seattle	Central US	2.357 km	40 ms	38,8 Mbit/sn	2,55 Gbit/sn
Seattle	ABD'nin Güney Merkez Bölgesi	2.877 km	51 ms	30,6 Mbit/sn	2,49 Gbit/sn
Seattle	ABD'nin Kuzey Orta Bölgesi	2.792 km	55 ms	27,7 Mbit/sn	2,19 Gbit/sn
Seattle	Doğu ABD 2	3.769 km	73 ms	21,3 Mbit/sn	1,79 Gbit/sn
Seattle	East US	3.699 km	74 ms	21,1 Mbit/sn	1,78 Gbit/sn
Seattle	Japonya Doğu	7.705 km	106 ms	14,6 Mbit/sn	1,22 Gbit/sn
Seattle	UK South	7.708 km	146 ms	10,6 Mbit/sn	896 Mbit/sn
Seattle	West Europe	7.834 km	153 ms	10,2 Mbit/sn	761 Mbit/s
Seattle	Doğu Avustralya	12.484 km	165 ms	9,4 Mbit/sn	794 Mbit/sn
Seattle	Güneydoğu Asya	12.989 km	170 ms	9,2 Mbit/sn	756 Mbit/sn
Seattle	Güney Brezilya *	10.930 km	189 ms	8,2 Mbit/sn	699 Mbit/sn
Seattle	South India	12.918 km	202 ms	7,7 Mbit/sn	634 Mbit/sn

Brezilya'ya yönelik gecikme süresi, fiber kablo mesafesinin düz çizgi mesafesinden önemli ölçüde farklılık gösterdiği bir örnektir. Beklenen gecikme süresi yaklaşık 160 ms'dir, ancak fiber rotanın uzun olması nedeniyle aslında 189 ms'dir.

Uyarı

AzureCT, PowerShell aracılığıyla Windows'de iPerf kullanarak bu sayıları test eder. iPerf, Ölçeklendirme Faktörü için varsayılan Windows TCP seçeneklerini dikkate almaz ve TCP pencere boyutu için daha düşük bir kaydırma sayısı kullanır. iPerf komutlarında -w seçeneğini ve daha büyük bir TCP pencere boyutunu kullanarak daha yüksek verim elde edebilirsiniz. iPerf'i birden çok makineden çok iş parçacıklı modda çalıştırmak, maksimum bağlantı performansına ulaşmanıza da yardımcı olabilir. Windows en iyi iPerf sonuçlarını almak için Set-NetTCPSetting -AutoTuningLevelLocal Experimental kullanın. Değişiklik yapmadan önce kuruluş ilkelerinizi denetleyin.

Sonraki Adımlar

• Azure Bağlantı Araç Seti'ni İndirin
• link performans testi yönergelerini izleyin