Ağ performansı sorunlarını giderme

Genel Bakış

Azure, şirket içi ağınızı Azure'a bağlamak için kararlı ve hızlı bir yol sağlar. Siteler Arası VPN ve ExpressRoute, büyük ve küçük müşteriler tarafından Azure’da işlerini yürütmek için başarıyla kullanılır. Ancak performans beklentilerinizi veya önceki deneyiminizi karşılamadığında ne olur? Bu makale, belirli ortamınızı test etme ve temellendirme yönteminizi standartlaştırmanıza yardımcı olabilir.

İ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 bakmanın yolları hakkında bazı öneriler de sağlanır. 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). Konaklardan biri Windows Server veya Masaüstü, diğeri Windows veya Linux olabilir.

Ağ bileşenleri

Sorun gidermeyi araştırmadan önce bazı yaygın terimleri ve bileşenleri tartışalım. Bu tartışma, Azure'da bağlantıya olanak tanıyan uçtan uca zincirdeki her bir bileşeni düşünmemizi 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 ele alalım:

• Sanal Makine - Sunucuda birden çok NIC olabilir. Statik yolların, varsayılan yolların ve İşletim Sistemi ayarlarının trafiği düşündüğünüz gibi gönderdiğinden ve 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 kullanmanızı öneririz.

• 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, hangisinin ve bu alt ağ ile ilişkili kuralları bildiğinizden emin olun.

• Alt ağ NSG - NIC'de olduğu gibi NSG'ler de alt ağa uygulanabilir. NSG kural kümesinin geçirmeye çalıştığınız trafik için uygun olduğundan emin olun. NIC'ye gelen trafik için önce alt ağ NSG, ardından NIC NSG uygulanır. Vm'den giden trafik olduğunda, önce NIC NSG uygulanır, ardından Alt Ağ NSG'si uygulanır.

• Alt ağ UDR - Kullanıcı Tanımlı Yollar trafiği bir ara atlamaya (güvenlik duvarı veya yük dengeleyici gibi) yönlendirebilir. Trafiğiniz için bir UDR olup olmadığını bildiğinizden emin olun. Öyleyse, nereye gittiğini ve sonraki atlamanın trafiğinize ne yapacağını anlayın. Örneğin, bir güvenlik duvarı biraz trafik geçirebilir ve aynı iki konak arasındaki 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şleme (ExpressRoute) veya VPN etkinleştirildikten sonra, trafik yollarının nasıl veya nasıl yönlendirildiğini etkileyebilecek çok 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ını bilmeniz gerekir. Bağlantı ağırlığı, bağlantı tercihini etkiler ve trafiğinizin izlediği yolu belirler.

• Yol Filtresi (Gösterilmiyor) - ExpressRoute aracılığıyla Microsoft Eşlemesi kullanılırken bir yol filtresi gereklidir. Herhangi bir yol almıyorsanız, yol filtresinin yapılandırılıp yapılandırılmadığını ve bağlantı hattına doğru 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ılarla ilgili birçok atlama, cihaz ve şirket vardır ve bu da sorun gidermeyi zorlaştırabilir. Aradaki atlamaları araştırmadan önce hem Azure'ı hem de şirket ağlarınızı ekleyebilirsiniz.

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/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 uygunudur. Bu yaklaşım, üçünün sorun yönlendirme etki alanını belirlemeye yardımcı olabilir. Daha sonra sorun gidermenizi belirli bir ortama odaklayabilirsiniz.

Araçlar

Ağ sorunlarının çoğu ping ve traceroute gibi temel araçlar kullanılarak analiz edilebilir ve yalıtılabilir. Wireshark gibi araçları kullanarak paket analizi kadar derine gitmeniz çok nadirdir.

Sorun gidermeye yardımcı olmak için Azure Bağlan ivity Toolkit (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 dizinle baş ederek "yüklenir".

Bu araçlar ve yöntemler, yükleyip kullanabileceğiniz bir PowerShell modülüne (AzureCT) sarmalanmıştır.

AzureCT - Azure Bağlan ivity Araç Seti

AzureCT PowerShell modülü iki bileşenden oluşur Kullanılabilirlik Testi ve Performans Testi. Bu belge yalnızca Performans testiyle ilgilidir, bu nedenle bu PowerShell modülündeki iki Bağlantı Performansı komutuna odaklanalım.

Performans testi için bu araç setini kullanmanın üç temel adımı vardır.

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

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

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

2. Destekleyici uygulamaları yükleyin.

   Install-LinkPerformance
   

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

3. Performans testini çalıştırın.

   İlk olarak, uzak konakta iPerf'i sunucu modunda yüklemeniz ve çalıştırmanız gerekir. Ayrıca uzak ana bilgisayarı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 konak Windows ise AzureCT'yi yükleyin ve Install-LinkPerformance komutunu çalıştırın. Komut, iPerf'i sunucu modunda başarıyla başlatmak için gereken iPerf ve güvenlik duvarı kurallarını ayarlar.

   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 etmeye yardımcı olmak için bir dizi eşzamanlı yük ve gecikme testi çalıştırır.

4. Testlerin çıkışını gözden geçirin.

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

   

   Tüm iPerf ve PSPing testlerinin ayrıntılı sonuçları, "C:\ACTTools" konumundaki AzureCT araçları dizinindeki tek tek metin dosyalarında yer alır.

Sorun giderme

Performans testi size beklenen sonuçları vermiyorsa, neden aşamalı bir adım adım işlem olması gerektiğini anlayarak. Yoldaki bileşenlerin sayısı göz önünde bulundurulduğunda sistematik bir yaklaşım, gezinmekten daha hızlı bir çözüm yolu sağlar. Sistemli olarak sorun gidererek, gereksiz testlerin birden çok kez yapılmasını önleyebilirsiniz.

Dekont

Buradaki senaryo bir performans sorunudur, bağlantı sorunu değildir. Azure ağına bağlantı sorununu yalıtmak için ExpressRotue bağlantısını doğrulama makalesini izleyin.

İlk olarak, varsayımlarınızı sorgula. Beklentiniz makul mü? Örneğin, 1 Gb/sn ExpressRoute bağlantı hattınız ve 100 ms gecikmeniz varsa. Yüksek gecikme süresi bağlantıları üzerinden TCP'nin performans özellikleri göz önünde bulundurulduğunda 1 Gb/sn'lik trafiğin tamamını beklemek mantıklı değildir. Performans varsayımları hakkında daha fazla bilgi için Başvurular bölümüne bakın.

Ardından, yönlendirme etki alanları arasındaki kenarlardan başlamanızı ve sorunu tek bir ana yönlendirme etki alanıyla yalıtmaya çalışmanızı öneririz. Kurumsal Ağ, WAN veya Azure Ağı'nda başlayabilirsiniz. Kişiler genellikle yoldaki "kara kutuyu" suçlar. Siyah kutuyu suçlamak kolaydır ancak çözünürlüğü önemli ölçüde geciktirebilir. Özellikle sorun, sorunu düzeltmek için değişiklik yapabileceğiniz bir alandaysa. Hizmet sağlayıcınıza veya ISS'nize teslim etmeden önce durum tespitinizi yaptığınızdan emin olun.

Sorunu içeren ana yönlendirme etki alanını belirledikten sonra, söz konusu alanın diyagramını oluşturmanız gerekir. Bir diyagram çizdiğinizde, sorunu yöntemsel olarak çalıştırabilir ve yalıtabilirsiniz. Test noktalarını planlayabilir ve alanları temizledikçe haritayı güncelleştirebilir veya test ilerledikçe daha derine inebilirsiniz.

Artık bir diyagramınız olduğuna göre ağı segmentlere bölmeye ve sorunu daraltmaya başlayın. Nerede çalıştığını ve nerede çalışmadığını öğrenin. Sorunlu bileşene yalıtmak için test noktalarınızı taşımaya devam edin.

Ayrıca OSI modelinin diğer katmanlarına da bakmayı unutmayın. Ağ ve katman 1 - 3 'e (Fiziksel, Veri ve Ağ katmanları) odaklanmak kolaydır, ancak sorunlar uygulama katmanındaki Katman 7'de de olabilir. Açık fikirli olun ve varsayımları doğrulayın.

Gelişmiş ExpressRoute sorunlarını giderme

Bulutun kenarının gerçekte nerede olduğundan emin değilseniz Azure bileşenlerini yalıtma zor olabilir. ExpressRoute kullanıldığında uç, Microsoft Enterprise Edge (MSEE) adlı bir ağ bileşenidir. ExpressRoute kullanırken MSEE, Microsoft'un ağına ilk ve Microsoft ağından ayrılırken son atlama noktasıdır. Sanal ağ geçidinizle ExpressRoute bağlantı hattı arasında bir bağlantı nesnesi oluşturduğunuzda, aslında MSEE ile bağlantı kurarsınız. Azure ağ sorununu yalıtmak için trafiğin hangi yönde önemli olduğuna bağlı olarak MSEE'yi ilk veya son atlama olarak tanıma. Sorunun Azure'da mı yoksa WAN'da mı yoksa şirket ağında mı daha aşağı akışta olduğunu hangi yönün doğru olduğunu bilmek.

Dekont

MSEE'nin Azure bulutunda olmadığına dikkat edin. ExpressRoute aslında Azure'da olmayan Microsoft ağının kenarındadır. ExpressRoute'u bir MSEE'ye bağladıktan sonra Microsoft'un ağına bağlanırsınız; buradan Microsoft 365 (Microsoft Eşleme ile) veya Azure (Özel ve/veya Microsoft Eşleme ile) gibi bulut hizmetlerinden herhangi birine gidebilirsiniz.

Aynı ExpressRoute bağlantı hattına iki sanal ağ bağlıysa, Sorunu Azure'da yalıtmak için bir dizi test yapabilirsiniz.

Test planı

1. VM1 ile VM2 arasında Get-LinkPerformance testini çalıştırın. Bu test, sorunun yerel olup olmadığıyla ilgili içgörü sağlar. Bu 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 varsayarsak, VM1 ile VM3 arasında Get-LinkPerformance testini çalıştırın. Bu test, Microsoft ağı üzerinden MSEE'ye ve Azure'a geri bağlantı alıştırması sağlar. Bu test kabul edilebilir gecikme süresi ve bant genişliği sonuçları üretirse Azure ağını iyi olarak işaretleyebilirsiniz.

3. Azure elendiğinde, şirket ağınızda benzer bir dizi test yapabilirsiniz. Bu da iyi sınanırsa, WAN bağlantınızı tanılamak için hizmet sağlayıcınızla veya ISS'nizle çalışma zamanı geldi. Örnek: Bu testi iki şube ofisi arasında veya masanızla bir veri merkezi sunucusu arasında çalıştırın. Neleri test ettiğinize bağlı olarak, bu yolu kullanabilen sunucular ve istemci bilgisayarlar gibi uç noktaları bulun.

Önemli

Her test için, testi çalıştırdığınız günün saatini işaretlemeniz ve sonuçları ortak bir konuma kaydetmeniz kritik önem taşır. Sonuçta elde edilen verileri test çalıştırmaları arasında karşılaştırabilmeniz ve verilerde "delikler" olmaması için her test çalıştırmasının aynı çıkışı olmalıdır. AzureCT'yi sorun giderme için kullanmanın birincil nedeni, birden çok testte tutarlılıktır. Büyü, tam olarak çalıştırdığımız yük senaryolarında değildir, ancak bunun yerine her testten tutarlı bir test ve veri çıkışı elde ettiğimiz gerçektir. Daha sonra sorunun düzensiz olduğunu fark ederseniz, saati kaydetmek ve her seferinde tutarlı verilere sahip olmak özellikle yararlıdır. Önceden veri toplama konusunda dikkatli olun ve aynı senaryoları saatlerce yeniden test etmekten kaçınacaksınız.

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

Sorunu ne kadar çok yalıtırsanız çözüm o kadar hızlı bulunabilir. Bazen sorun giderme adımlarınızda daha fazla ilerleyemezsiniz. Örneğin, avrupa üzerinden atlayıp giden hizmet sağlayıcınızın bağlantısını görürsünüz, ancak yolun tamamının Asya'da kalmasını beklersiniz. Bu noktada yardım için biriyle etkileşim kurmalısınız. Sorabileceğiniz kişiler, sorunu yalıtdığınız yönlendirme etki alanına bağlıdır. Bunu daha da iyi olacak belirli bir bileşene daraltabiliyorsanız.

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ını gidermek için iyi bir uygulama, test sonuçlarınızı Hizmet Sağlayıcınızla veya ISS'nizle paylaşmaktır, bu da işlerinde onlara yardımcı olabilir. Test sonuçlarınız, önceden yaptığınız görevlerin aynısını tekrar yapmaktan da kaçınabilir. Ancak, sonuçlarınızı kendileri denetlemek isteyebilirler. Bu, güven ilkesine dayanır, ancak doğrulayın.

Azure'da, sorunu mümkün olduğunca ayrıntılı bir şekilde yalıtdıktan sonra Azure Ağ Belgelerini gözden geçirmenin ve gerekirse bir destek bileti açmanın zamanı geldi.

Başvurular

Gecikme/bant genişliği beklentileri

Bahşiş

Test ettiğiniz uç noktalar arasındaki coğrafi gecikme süresi (mil veya kilometre), gecikme süresinin açık ara en büyük bileşenidir. Ekipman gecikme süresi (fiziksel ve sanal bileşenler, atlama sayısı vb.) olsa da, WAN bağlantılarıyla ilgilenirken coğrafyanın genel gecikme süresinin en büyük bileşeni olduğu kanıtlanmıştır. Ayrıca, mesafenin düz hat veya yol haritası uzaklığı değil fiber çalıştırmanın uzaklığı olduğunu unutmayın. Bu uzaklığı herhangi bir doğrulukla elde etmek inanılmaz zordur. Sonuç olarak, genellikle internet üzerinde bir şehir uzaklığı hesaplayıcısı kullanırız ve bu yöntemin büyük ölçüde yanlış bir ölçü olduğunu, ancak genel bir beklentiyi belirlemek için yeterli olduğunu biliyoruz.

Örneğin, Abd'de Seattle, Washington'da bir ExpressRoute kurulumu aldık. Aşağıdaki tabloda çeşitli Azure konumlarında test ettiğimiz gecikme süresi ve bant genişliği gösterilmektedir. Testin her bir ucu arasındaki coğrafi uzaklığı tahmin ettik.

Test kurulumu:

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

• Özel Eşleme etkin olarak tanımlanan konumda 10 Gb/sn Premium ExpressRoute bağlantı hattı.

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

• Sanal ağda Windows Server 2016 çalıştıran bir DS5v2 VM. Sanal makine, AzureCT'nin yüklü olduğu varsayılan Azure görüntüsünden (iyileştirme veya özelleştirme olmadan) oluşturulan etki alanına katılmadı.

• 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 test için veri akışı, yük şirket içi fiziksel sunucudan (Seattle'daki iPerf istemcisi) Azure VM'ye (listelenen Azure bölgesindeki iPerf sunucusu) akmıştı.

• "Gecikme süresi" sütun verileri Yük Yok testinden (iPerf çalıştırılmadan tcp gecikme testi) alınır.

• "En Yüksek Bant Genişliği" sütun verileri, 1 Mb pencere boyutuna sahip 16 TCP akış yük testinden alınır.

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

Önemli

Bu sayılar yalnızca genel başvuru içindir. 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ıları ağındaki koşullar her zaman farklı yollar üzerinden trafik gönderebilir, bu nedenle gecikme süresi ve bant genişliği etkilenebilir. Genel olarak, bu değişikliklerin etkileri önemli farklılıklara neden olmaz.

ExpressRoute Konum	Azure Bölge	Tahmini Mesafe (km)	Gecikme süresi	1 Oturum Bant genişliği	En Büyük Bant genişliği
Seattle	Batı ABD 2	191 km	5 ms	262,0 Mbit/sn	3,74 Gbit/sn
Seattle	Batı ABD	1.094 km	18 ms	82,3 Mbit/sn	3,70 Gbit/sn
Seattle	Orta ABD	2.357 km	40 ms	38,8 Mbit/sn	2,55 Gbit/sn
Seattle	Orta Güney ABD	2.877 km	51 ms	30,6 Mbit/sn	2,49 Gbit/sn
Seattle	Orta Kuzey ABD	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	Doğu ABD	3.699 km	74 ms	21,1 Mbit/sn	1,78 Gbit/sn
Seattle	Doğu Japonya	7.705 km	106 ms	14,6 Mbit/sn	1,22 Gbit/sn
Seattle	Güney Birleşik Krallık	7.708 km	146 ms	10,6 Mbit/sn	896 Mbit/sn
Seattle	Batı Avrupa	7.834 km	153 ms	10,2 Mbit/sn	761 Mbit/sn
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	Güney Hindistan	12.918 km	202 ms	7,7 Mbit/sn	634 Mbit/sn

* Brezilya'ya gecikme süresi, düz çizgi mesafesinin fiber çalışma uzaklığından önemli ölçüde farklı olduğu iyi bir örnektir. Beklenen gecikme süresi 160 ms,ancak aslında 189 ms olur. Gecikme süresindeki fark, bir yerde bir ağ sorunu olduğunu gösteriyor gibi görünebilir. Ama gerçek şu ki, fiber çizgi Brezilya'ya düz bir çizgide gitmez. Bu nedenle, Seattle'dan Brezilya'ya gitmek için fazladan 1.000 km veya daha fazla seyahat beklemeniz gerekir.

Dekont

Bu sayıların dikkate alınması gerekirken, PowerShell aracılığıyla Windows'ta IPERF tabanlı AzureCT kullanılarak test edilmiştir. Bu senaryoda IPERF, Ölçeklendirme Faktörü için varsayılan Windows TCP seçeneklerine uygun değildir ve TCP Penceresi boyutu için çok daha düşük bir Shift Sayısı kullanır. Burada gösterilen sayılar varsayılan IPERF değerleri kullanılarak gerçekleştirildi ve yalnızca genel başvuru içindir. Anahtar ve büyük bir TCP Penceresi boyutu ile -w IPERF komutlarını ayarlayarak, uzun mesafelerde daha iyi aktarım hızı elde edilebilir ve bu da önemli ölçüde daha iyi aktarım hızı rakamları gösterir. Ayrıca ExpressRoute'un tam bant genişliğini kullandığından emin olmak için, bilgi işlem kapasitesinin maksimum bağlantı performansına ulaşabildiğinden ve tek bir VM'nin işleme kapasitesiyle sınırlı olmadığından emin olmak için IPERF'yi birden çok makineden çok iş parçacıklı seçeneği aynı anda çalıştırmak idealdir. Windows'ta en iyi Iperf sonuçlarını almak için "Set-NetTCPSetting -AutoTuningLevelLocal Experimental" komutunu kullanın. Değişiklik yapmadan önce lütfen kuruluş ilkelerinizi denetleyin.

Sonraki adımlar

• Azure Bağlan ivity Araç Seti'ni indirme
• Bağlantı performansı testi yönergelerini izleyin