Windows Server yazılım tanımlı ağ yığını sorunlarını giderme
Bu kılavuz, yaygın Yazılım Tanımlı Ağ (SDN) hatalarını ve hata senaryolarını inceler ve kullanılabilir tanılama araçlarını kullanan bir sorun giderme iş akışını özetler. SDN hakkında daha fazla bilgi için bkz . Yazılım Tanımlı Ağ.
Şunlar için geçerlidir: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, sürüm 21H2 ve 20H2
Hata türleri
Aşağıdaki liste, pazar içi üretim dağıtımlarından Windows Server 2012 R2'de Hyper-V Ağ Sanallaştırma (HNVv1) ile en sık görülen sorun sınıfını temsil eder ve yeni Yazılım Tanımlı Ağ (SDN) Yığını ile Windows Server 2016 HNVv2'de görülen sorunların aynı türleriyle birçok şekilde çakışır.
Hataların çoğu küçük bir sınıf kümesine sınıflandırılabilir:
Geçersiz veya desteklenmeyen yapılandırma
Kullanıcı NorthBound API'sini yanlış veya geçersiz ilkeyle çağırır.
İlke uygulamasında hata
Ağ Denetleyicisi'nden ilke bir Hyper-V Konağına teslim edilmedi, gecikmeli veya tüm Hyper-V konaklarında güncel değil (örneğin, Dinamik Geçişten sonra).
Yapılandırma kayma veya yazılım hatası
Bırakılan paketlere neden olan veri yolu sorunları.
NIC donanımı / sürücüleri veya alt ağ dokusuyla ilgili dış hata
Yanlış davranan görev yükleri (VMQ gibi) veya yanlış yapılandırılmış alt katman ağ dokusu (MTU gibi)
Bu sorun giderme kılavuzu bu hata kategorilerinin her birini inceler ve hatayı tanımlamak ve düzeltmek için en iyi yöntemleri ve tanılama araçlarını önerir.
Tanılama araçları
Bu tür hataların her biri için sorun giderme iş akışlarını tartışmadan önce kullanılabilir tanılama araçlarını inceleyelim.
Ağ Denetleyicisi (denetim yolu) tanılama araçlarını kullanmak için önce özelliği yüklemeniz RSAT-NetworkController
ve modülü içeri aktarmanız NetworkControllerDiagnostics
gerekir:
Add-WindowsFeature RSAT-NetworkController -IncludeManagementTools
Import-Module NetworkControllerDiagnostics
HNV Tanılama (veri yolu) tanılama araçlarını kullanmak için modülü içeri aktarmanız HNVDiagnostics
gerekir:
# Assumes RSAT-NetworkController feature has already been installed
Import-Module hnvdiagnostics
Ağ denetleyicisi tanılamaları
Bu cmdlet'ler Ağ Denetleyicisi Tanılama cmdlet'indeki TechNet'te belgelenmiştir. Ağ Denetleyicisi düğümleri arasındaki ve Ağ Denetleyicisi ile Hyper-V konaklarında çalışan NC Ana Bilgisayar Aracıları arasındaki denetim yolundaki ağ ilkesi tutarlılığıyla ilgili sorunları belirlemeye yardımcı olur.
ve Get-NetworkControllerReplica
cmdlet'leri Debug-ServiceFabricNodeStatus
Ağ Denetleyicisi düğümü sanal makinelerinden birinden çalıştırılmalıdır. Diğer tüm NC Tanılama cmdlet'leri, Ağ Denetleyicisi'ne bağlantısı olan ve Ağ Denetleyicisi Yönetimi güvenlik grubunda (Kerberos) bulunan veya Ağ Denetleyicisi'ni yönetmek için X.509 sertifikasına erişimi olan herhangi bir konaktan çalıştırılabilir.
Hyper-V konak tanılaması
Bu cmdlet'ler, Hyper-V Ağ Sanallaştırma (HNV) Tanılama cmdlet'indeki TechNet'te belgelenmiştir. Kiracı sanal makineleri (Doğu/Batı) ile SLB VIP (Kuzey/Güney) üzerinden giriş trafiği arasındaki veri yolundaki sorunları belirlemeye yardımcı olur.
Debug-VirtualMachineQueueOperation
, , Get-CustomerRoute
, Get-PACAMapping
, Get-ProviderAddress
, Get-VMNetworkAdapterPortId
, , Get-VMSwitchExternalPortId
ve Test-EncapOverheadSettings
tüm Hyper-V konaklarından çalıştırılabilir yerel testlerdir. Diğer cmdlet'ler Ağ Denetleyicisi aracılığıyla veri yolu testlerini çağırır ve bu nedenle yukarıda açıklandığı gibi Ağ Denetleyicisi'ne erişmesi gerekir.
GitHub
Microsoft/SDN GitHub Deposu,bu yerleşik cmdlet'lerin üzerine inşa edilen birçok örnek betik ve iş akışına sahiptir. Özellikle tanılama betikleri Tanılama klasöründe bulunabilir. Çekme İstekleri göndererek bu betiklere katkıda bulunmamıza yardımcı olun.
İş akışları ve kılavuzlarla ilgili sorunları giderme
[Hoster] Sistem durumunu doğrulama
Ağ Denetleyicisi kaynaklarının birkaçında Yapılandırma Durumu adlı ekli bir kaynak vardır. Yapılandırma durumu, ağ denetleyicisinin yapılandırması ile Hyper-V konaklarında gerçek (çalışan) durum arasındaki tutarlılık dahil olmak üzere sistem durumu hakkında bilgi sağlar.
Yapılandırma durumunu denetlemek için, Ağ Denetleyicisi bağlantısı olan herhangi bir Hyper-V konağından aşağıdakileri çalıştırın.
Not
Parametresinin NetworkController
değeri, Ağ Denetleyicisi için oluşturulan X.509 >sertifikasının konu adına göre FQDN veya IP adresi olmalıdır.
Parametresi yalnızca Credential
ağ denetleyicisi Kerberos kimlik doğrulamasını kullanıyorsa belirtilmelidir (VMM dağıtımlarında tipiktir). Kimlik bilgisi, Ağ Denetleyicisi Yönetimi Güvenlik Grubu'nda yer alan bir kullanıcı için olmalıdır.
Debug-NetworkControllerConfigurationState -NetworkController <FQDN or NC IP> [-Credential <PS Credential>]
# Healthy State Example - no status reported
$cred = Get-Credential
Debug-NetworkControllerConfigurationState -NetworkController 10.127.132.211 -Credential $cred
Fetching ResourceType: accessControlLists
Fetching ResourceType: servers
Fetching ResourceType: virtualNetworks
Fetching ResourceType: networkInterfaces
Fetching ResourceType: virtualGateways
Fetching ResourceType: loadbalancerMuxes
Fetching ResourceType: Gateways
Aşağıda örnek bir Yapılandırma Durumu iletisi gösterilmiştir:
Fetching ResourceType: servers
---------------------------------------------------------------------------------------------------------
ResourcePath: https://10.127.132.211/Networking/v1/servers/4c4c4544-0056-4b10-8058-b8c04f395931
Status: Warning
Source: SoftwareLoadBalancerManager
Code: HostNotConnectedToController
Message: Host is not Connected.
----------------------------------------------------------------------------------------------------------
Not
Sistemde, SLB Mux Transit VM NIC için Ağ Arabirimi kaynaklarının "Sanal Anahtar - Ana Bilgisayar Denetleyiciye Bağlı Değil" hatasıyla Hata durumunda olduğu bir hata var. VM NIC kaynağındaki IP yapılandırması Aktarım Mantıksal Ağı'nın IP Havuzundan bir IP Adresi olarak ayarlandıysa, bu hata güvenle yoksayılabilir.
Sistemde Ağ Geçidi HNV Sağlayıcısı VM NIC'leri için Ağ Arabirimi kaynaklarının "Sanal Anahtar - PortBlocked" hatasıyla Hata durumunda olduğu ikinci bir hata vardır. VM NIC kaynağındaki IP yapılandırması null olarak ayarlandıysa (tasarım gereği) bu hata da güvenle yoksayılabilir.
Aşağıdaki tabloda, gözlemlenen yapılandırma durumuna göre yapılması gereken hata kodları, iletiler ve izleme eylemlerinin listesi gösterilmektedir.
Kod | İleti | Eylem |
---|---|---|
Bilinmiyor | Bilinmeyen hata | |
HostUnreachable | Konak makineye ulaşılamıyor | Ağ Denetleyicisi ile Konak arasındaki Yönetim ağ bağlantısını denetleyin |
PAIpAddressExhausted | PA IP adresleri tükendi | HNV Sağlayıcısı mantıksal alt ağdaki IP Havuzu Boyutunu Artırma |
PAMacAddressExhausted | PA Mac adresleri tükendi | Mac Havuzu Aralığını Artırma |
PAAddressConfigurationFailure | PA adresleri konağa alınamadı | Ağ Denetleyicisi ile Konak arasındaki Yönetim ağ bağlantısını denetleyin. |
CertificateNotTrusted | Sertifika güvenilir değil | Konakla iletişim için kullanılan sertifikaları düzeltin. |
CertificateNotAuthorized | Sertifika yetkilendirilmedi | Konakla iletişim için kullanılan sertifikaları düzeltin. |
PolicyConfigurationFailureOnVfp | VFP ilkelerini yapılandırma hatası | Bu bir çalışma zamanı hatasıdır. Kesin bir geçici çözüm yoktur. Günlükleri toplayın. |
PolicyConfigurationFailure | İletişim hatalarından veya NetworkController'daki diğer hatalardan dolayı ana bilgisayarlara ilke gönderme hatası. | Kesin bir eylem yok. Bunun nedeni Ağ Denetleyicisi modüllerindeki hedef durumu işleme hatasıdır. Günlükleri toplayın. |
HostNotConnectedToController | Ana Bilgisayar henüz Ağ Denetleyicisine bağlı değil | Bağlantı Noktası Profili konağa uygulanmadı veya ana bilgisayara Ağ Denetleyicisi'nden erişilemiyor. HostID kayıt defteri anahtarının sunucu kaynağının Örnek Kimliği ile eşleşdiğini doğrulayın |
MultipleVfpEnabledSwitches | Konakta birden çok VFp etkin Anahtar var | Ağ Denetleyicisi Ana Bilgisayar Aracısı VFP uzantısı etkinleştirilmiş olarak yalnızca bir vSwitch'i desteklediğinden anahtarlardan birini silin |
PolicyConfigurationFailure | Sertifika hataları veya bağlantı hataları nedeniyle vmNic için sanal ağ ilkeleri gönderılamadı | Düzgün sertifikaların dağıtılıp dağıtılmadığını denetleyin (Sertifika konu adı konağın FQDN'sine uygun olmalıdır). Ayrıca Ağ Denetleyicisi ile konak bağlantısını doğrulayın |
PolicyConfigurationFailure | Sertifika hataları veya bağlantı hataları nedeniyle vmNic için vSwitch ilkeleri gönderılamadı | Düzgün sertifikaların dağıtılıp dağıtılmadığını denetleyin (Sertifika konu adı konağın FQDN'sine uygun olmalıdır). Ayrıca Ağ Denetleyicisi ile konak bağlantısını doğrulayın |
PolicyConfigurationFailure | Sertifika hataları veya bağlantı hataları nedeniyle bir VmNic için Güvenlik Duvarı ilkeleri gönderilemedi | Düzgün sertifikaların dağıtılıp dağıtılmadığını denetleyin (Sertifika konu adı konağın FQDN'sine uygun olmalıdır). Ayrıca Ağ Denetleyicisi ile konak bağlantısını doğrulayın |
DistributedRouterConfigurationFailure | Ana bilgisayar vNic'inde Dağıtılmış yönlendirici ayarları yapılandırılamadı | TCPIP yığını hatası. Bu hatanın bildirildiği sunucuda PA ve DR Ana Bilgisayar vNIC'lerinin temizlenmesi gerekebilir |
DhcpAddressAllocationFailure | VMNic için DHCP adresi ayırma işlemi başarısız oldu | Statik IP adresi özniteliğinin NIC kaynağında yapılandırılıp yapılandırılmamış olduğunu denetleyin |
CertificateNotTrusted CertificateNotAuthorized |
Ağ veya sertifika hataları nedeniyle Mux'a bağlanılamadı | Hata iletisi kodunda sağlanan sayısal kodu denetleyin: Bu, winsock hata koduna karşılık gelir. Sertifika hataları ayrıntılıdır (örneğin sertifika doğrulanamıyor, sertifika yetkilendirilmedi vb.) |
HostUnreachable | MUX iyi durumda değil (Yaygın durum BGPRouter bağlantısının kesilmesidir) | RRAS (BGP sanal makinesi) veya Raf Üstü (ToR) anahtarındaki BGP eşlemesine ulaşılamıyor veya başarıyla eşlenmiyor. Hem Yazılım Yük Dengeleyici Çoklayıcı kaynağında hem de BGP eşlemesinde (ToR veya RRAS sanal makinesi) BGP ayarlarını denetleyin |
HostNotConnectedToController | SLB ana bilgisayar aracısı bağlı değil | SLB Ana Bilgisayar Aracısı hizmetinin çalışıp çalışmadığını denetleyin; SLBM'nin (NC) konak aracısı tarafından sunulan sertifikayı reddetmesi durumunda durum bilgisinin incelikli bilgiler göstermesinin nedenlerinden dolayı SLB konak aracısı günlüklerine (otomatik çalıştırma) bakın |
Bağlantı Noktası Engellendi | VFP bağlantı noktası, sanal ağ /ACL ilkelerinin olmaması nedeniyle engellendi | İlkelerin yapılandırılmamasına neden olabilecek başka hatalar olup olmadığını denetleyin. |
Aşırı yüklü | Loadbalancer MUX aşırı yüklenmiş | MUX ile ilgili performans sorunu |
RoutePublicationFailure | Loadbalancer MUX bir BGP yönlendiricisine bağlı değil | MUX'un BGP yönlendiricileriyle bağlantısı olup olmadığını ve BGP eşlemesinin doğru ayarlanıp ayarlanmadığını denetleyin |
VirtualServerUnreachable | Loadbalancer MUX SLB yöneticisine bağlı değil | SLBM ile MUX arasındaki bağlantıyı denetleme |
QosConfigurationFailure | QOS ilkeleri yapılandırılamadı | QOS ayırması kullanılıyorsa tüm VM'ler için yeterli bant genişliğinin kullanılabilir olup olmadığını görün |
Ağ denetleyicisi ile Hyper-V Konağı (NC Ana Bilgisayar Aracısı hizmeti) arasındaki ağ bağlantısını denetleyin
netstat
NC Konak Aracısı ile Ağ Denetleyicisi düğümleri ile Hyper-V Konağındaki bir LISTENING
yuva arasında üç ESTABLISHED
bağlantı olduğunu doğrulamak için aşağıdaki komutu çalıştırın.
- Hyper-V Konağındaki (NC Ana Bilgisayar Aracısı Hizmeti) TCP:6640 bağlantı noktasında DINLEME
- 6640 numaralı bağlantı noktası üzerindeki Hyper-V ana bilgisayar IP'sinden kısa ömürlü bağlantı noktalarındaki NC düğümü IP'sine iki kurulan bağlantı (> 32000)
- Kısa süreli bağlantı noktasında Hyper-V konağının IP adresinden Ağ Denetleyicisi REST IP adresine 6640 numaralı bağlantı noktası üzerinden kurulan bir bağlantı mevcut
Not
Bir Hyper-V konağı üzerinde, söz konusu konakta dağıtılmış kiracı sanal makineleri yoksa, yalnızca iki kurulan bağlantı olabilir.
netstat -anp tcp |findstr 6640
# Successful output
TCP 0.0.0.0:6640 0.0.0.0:0 LISTENING
TCP 10.127.132.153:6640 10.127.132.213:50095 ESTABLISHED
TCP 10.127.132.153:6640 10.127.132.214:62514 ESTABLISHED
TCP 10.127.132.153:50023 10.127.132.211:6640 ESTABLISHED
Konak aracısı hizmetlerini denetleme
Ağ denetleyicisi, Hyper-V konaklarındaki iki konak aracısı hizmetiyle iletişim kurar: SLB Konak Aracısı ve NC Konak Aracısı. Bu hizmetlerden biri veya her ikisi de çalışmıyor olabilir. Durumlarını denetleyin ve çalışmıyorsa yeniden başlatın.
Get-Service SlbHostAgent
Get-Service NcHostAgent
# (Re)start requires -Force flag
Start-Service NcHostAgent -Force
Start-Service SlbHostAgent -Force
Ağ denetleyicisinin durumunu denetleme
Üç ESTABLISHED
bağlantı yoksa veya Ağ Denetleyicisi yanıt vermiyor gibi görünüyorsa, aşağıdaki cmdlet'leri kullanarak tüm düğümlerin ve hizmet modüllerinin çalışır durumda olup olmadığını denetleyin.
# Prints a DIFF state (status is automatically updated if state is changed) of a particular service module replica
Debug-ServiceFabricNodeStatus [-ServiceTypeName] <Service Module>
Ağ denetleyicisi hizmet modülleri şunlardır:
- ControllerService
- ApiService
- SlbManagerService
- ServiceInsertion
- FirewallService
- VSwitchService
- GatewayManager
- FnmService
- HelperService
- UpdateService
olup olmadığını ve HealthState
olup olmadığını Ok
ReplicaStatus
Ready
denetleyin.
Çok düğümlü bir Ağ Denetleyicisi ile üretim dağıtımında, her hizmetin hangi düğümde birincil olduğunu ve tek tek çoğaltma durumunu de de kontrol edebilirsiniz.
Get-NetworkControllerReplica
# Sample Output for the API service module
Replicas for service: ApiService
ReplicaRole : Primary
NodeName : SA18N30NC3.sa18.nttest.microsoft.com
ReplicaStatus : Ready
Çoğaltma Durumunun her hizmet için Hazır olup olmadığını denetleyin.
Ağ denetleyicisi ile her Hyper-V konağı arasında karşılık gelen HostID'leri ve sertifikaları denetleyin
Hyper-V Konağında, HostID'nin Ağ Denetleyicisi'nde bir sunucu kaynağının Örnek Kimliğine karşılık geldiğini denetlemek için aşağıdaki cmdlet'leri çalıştırın
Get-ItemProperty "hklm:\system\currentcontrolset\services\nchostagent\parameters" -Name HostId |fl HostId
HostId : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**
Get-NetworkControllerServer -ConnectionUri $uri |where { $_.InstanceId -eq "162cd2c8-08d4-4298-8cb4-10c2977e3cfe"}
Tags :
ResourceRef : /servers/4c4c4544-0056-4a10-8059-b8c04f395931
InstanceId : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**
Etag : W/"50f89b08-215c-495d-8505-0776baab9cb3"
ResourceMetadata : Microsoft.Windows.NetworkController.ResourceMetadata
ResourceId : 4c4c4544-0056-4a10-8059-b8c04f395931
Properties : Microsoft.Windows.NetworkController.ServerProperties
Düzeltme
SDNExpress betikleri veya el ile dağıtım kullanıyorsanız, kayıt defterindeki HostId anahtarını sunucu kaynağının Örnek Kimliğiyle eşleşecek şekilde güncelleştirin. Hyper-V konağında (fiziksel sunucu) Ağ Denetleyicisi Konak Aracısını yeniden başlatın VMM kullanıyorsanız, HYPER-V Sunucusunu VMM'den silin ve HostId kayıt defteri anahtarını kaldırın. Ardından sunucuyu VMM aracılığıyla yeniden ekleyin.
Hyper-V Konağı (NC Konak Aracısı hizmeti) ile Ağ Denetleyicisi düğümleri arasındaki (SouthBound) iletişim için Hyper-V konağı tarafından kullanılan X.509 sertifikalarının parmak izlerinin (konak adı sertifikanın Konu Adı olacaktır) aynı olup olmadığını denetleyin. Ayrıca Ağ Denetleyicisi'nin REST sertifikasının konu adına CN=<FQDN or IP>
sahip olup olmadığını denetleyin.
# On Hyper-V Host
dir cert:\\localmachine\my
Thumbprint Subject
---------- -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9 CN=SA18n30-4.sa18.nttest.microsoft.com
...
dir cert:\\localmachine\root
Thumbprint Subject
---------- -------
30674C020268AA4E40FD6817BA6966531FB9ADA4 CN=10.127.132.211 **# NC REST IP ADDRESS**
# On Network Controller Node VM
dir cert:\\localmachine\root
Thumbprint Subject
---------- -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9 CN=SA18n30-4.sa18.nttest.microsoft.com
30674C020268AA4E40FD6817BA6966531FB9ADA4 CN=10.127.132.211 **# NC REST IP ADDRESS**
...
Konu adının beklenen (konak adı veya NC REST FQDN veya IP) olduğundan, sertifikanın süresinin henüz dolmadığından ve sertifika zincirindeki tüm sertifika yetkililerinin güvenilen kök yetkiliye dahil olduğundan emin olmak için her sertifikanın aşağıdaki parametrelerini de de kontrol edebilirsiniz.
- Konu Adı
- Bitiş Tarihi
- Kök Yetkili tarafından güvenilen
Hyper-V konağında aynı konu adına sahip birden çok sertifika varsa, Ağ Denetleyicisi Ana Bilgisayar Aracısı ağ denetleyicisine sunmak için rastgele bir sertifika seçer. Bu, Ağ Denetleyicisi tarafından bilinen sunucu kaynağının parmak iziyle eşleşmeyebilir. Bu durumda, Hyper-V konağında aynı konu adına sahip sertifikalardan birini silin ve ardından Ağ Denetleyicisi Ana Bilgisayar Aracısı hizmetini yeniden başlatın. Bağlantı yine de yapılamıyorsa, Hyper-V Konağı'nda aynı konu adına sahip diğer sertifikayı silin ve VMM'de ilgili sunucu kaynağını silin. Ardından, yeni bir X.509 sertifikası oluşturacak ve Hyper-V konağına yükleyecek olan VMM'de sunucu kaynağını yeniden oluşturun.
SLB yapılandırma durumunu denetleme
SLB Yapılandırma Durumu, cmdlet'in çıkışının Debug-NetworkController
bir parçası olarak belirlenebilir. Bu cmdlet ayrıca JSON dosyalarındaki geçerli Ağ Denetleyicisi kaynakları kümesini, her Hyper-V konağından (sunucu) tüm IP yapılandırmalarını ve Konak Aracısı veritabanı tablolarından yerel ağ ilkesinin çıkışını alır.
Varsayılan olarak daha fazla izleme toplanır. İzlemeleri toplamamak için parametresini -IncludeTraces:$false
ekleyin.
Debug-NetworkController -NetworkController <FQDN or IP> [-Credential <PS Credential>] [-IncludeTraces:$false]
# Don't collect traces
$cred = Get-Credential
Debug-NetworkController -NetworkController 10.127.132.211 -Credential $cred -IncludeTraces:$false
Transcript started, output file is C:\NCDiagnostics.log
Collecting Diagnostics data from NC Nodes
Not
Varsayılan çıkış konumu working_directory>\NCDiagnostics\ dizini olacaktır<. Varsayılan çıkış dizini parametresi kullanılarak -OutputDirectory
değiştirilebilir.
SLB Yapılandırma Durumu bilgileri bu dizindeki diagnostics-slbstateResults.Json dosyasında bulunabilir.
Bu JSON dosyası aşağıdaki bölümlere ayrılabilir:
- Kumaş
- SlbmVips - Bu bölümde, Ağ Denetleyicisi tarafından SLB Muxes ve SLB Konak Aracıları arasında yapılandırma ve sistem durumunu koordine etmek için kullanılan SLB Yöneticisi VIP adresinin IP adresi listelenir.
- MuxState - Bu bölüm dağıtılan her SLB Mux için bir değer listeleyecek ve mux'un durumunu verir
- Yönlendirici Yapılandırması - Bu bölümde Yukarı Akış Yönlendiricisinin (BGP Eş) Otonom Sistem Numarası (ASN), Aktarım IP Adresi ve Kimliği listelenecektir. Ayrıca SLB Muxes ASN ve Aktarım IP'sini de listeler.
- Bağlı Ana Bilgisayar Bilgileri - Bu bölümde, yük dengeli iş yüklerini çalıştırmak için kullanılabilen tüm Hyper-V konaklarının Yönetim IP adresi listelenir.
- Vip Aralıkları - Bu bölümde genel ve özel VIP IP havuzu aralıkları listelenecektir. SLBM VIP, bu aralıklardan birinden ayrılmış IP olarak dahil edilir.
- Mux Yolları - Bu bölüm, dağıtılan her SLB Mux için bir değer listeler ve bu belirli mux için tüm Yol Tanıtımlarını içerir.
- Kiracı
- VipConsolidatedState - Bu bölümde, tanıtılan yol ön eki, Hyper-V Konağı ve DIP uç noktaları dahil olmak üzere her Kiracı VIP'si için bağlantı durumu listelenecektir.
Not
SLB Durumu, Microsoft SDN GitHub deposunda bulunan DumpSlbRestState betiği kullanılarak doğrudan doğrulanabilir.
Ağ geçidi doğrulaması
Ağ denetleyicisinden:
Get-NetworkControllerLogicalNetwork
Get-NetworkControllerPublicIPAddress
Get-NetworkControllerGatewayPool
Get-NetworkControllerGateway
Get-NetworkControllerVirtualGateway
Get-NetworkControllerNetworkInterface
Ağ geçidi VM'sinden:
Ipconfig /allcompartments /all
Get-NetRoute -IncludeAllCompartments -AddressFamily
Get-NetBgpRouter
Get-NetBgpRouter | Get-BgpPeer
Get-NetBgpRouter | Get-BgpRouteInformation
Rafın üstünden (ToR) anahtar:
sh ip bgp summary (for 3rd party BGP Routers)
Windows BGP yönlendiricisi:
Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation
Bunlara ek olarak, şimdiye kadar gördüğümüz sorunlardan (özellikle SDNExpress tabanlı dağıtımlarda), Kiracı Bölmesi'nin GW VM'lerinde yapılandırılmamasının en yaygın nedeni, FabricConfig.psd1'deki GW Kapasitesinin, kiracı üyelerinin TenantConfig.psd1'deki Ağ Bağlantıları'na (S2S Tünelleri) atamaya çalıştıklarıyla karşılaştırıldığında daha az olması gibi görünüyor. Bu, aşağıdaki cmdlet'lerin çıkışları karşılaştırılarak kolayca denetlenebilir:
PS > (Get-NetworkControllerGatewayPool -ConnectionUri $uri).properties.Capacity
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").properties.OutboundKiloBitsPerSecond
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").property
[Hoster] Veri Düzlemi Doğrulama
Ağ Denetleyicisi dağıtıldıktan, kiracı sanal ağları ve alt ağları oluşturulduktan ve sanal alt ağlara VM'ler eklendikten sonra, kiracı bağlantısını denetlemek için konakçı tarafından ek doku düzeyi testleri gerçekleştirilebilir.
HNV sağlayıcısı mantıksal ağ bağlantısını denetleme
Hyper-V konağında çalışan ilk konuk VM bir kiracı sanal ağına bağlandıktan sonra, Ağ Denetleyicisi Hyper-V Konağına iki HNV Sağlayıcısı IP Adresi (PA IP Adresleri) atar. Bu IP'ler HNV Sağlayıcısı mantıksal ağının IP Havuzundan gelir ve Ağ Denetleyicisi tarafından yönetilir. Bu iki HNV IP Adresinin ne olduğunu öğrenmek için:
PS > Get-ProviderAddress
# Sample Output
ProviderAddress : 10.10.182.66
MAC Address : 40-1D-D8-B7-1C-04
Subnet Mask : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN : VLAN11
ProviderAddress : 10.10.182.67
MAC Address : 40-1D-D8-B7-1C-05
Subnet Mask : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN : VLAN11
Bu HNV Sağlayıcısı IP Adresleri (PA IP'leri), ayrı bir TCPIP ağ bölmesinde oluşturulan Ethernet Bağdaştırıcılarına atanır ve VLANX bağdaştırıcı adına sahiptir; burada X, HNV Sağlayıcısı (aktarım) mantıksal ağına atanan VLAN'dır.
HNV Sağlayıcısı mantıksal ağını kullanan iki Hyper-V ana bilgisayarı arasındaki bağlantı, Y'nin PAhostVNICs'in oluşturulduğu TCPIP ağ bölmesi olduğu ek bölme (-c Y) parametresine sahip bir ping ile yapılabilir. Bu bölme aşağıdakiler yürütülerek belirlenebilir:
C:\> ipconfig /allcompartments /all
<snip> ...
==============================================================================
Network Information for *Compartment 3*
==============================================================================
Host Name . . . . . . . . . . . . : SA18n30-2
<snip> ...
Ethernet adapter VLAN11:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-04
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::5937:a365:d135:2899%39(Preferred)
IPv4 Address. . . . . . . . . . . : 10.10.182.66(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.128
Default Gateway . . . . . . . . . : 10.10.182.1
NetBIOS over Tcpip. . . . . . . . : Disabled
Ethernet adapter VLAN11:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-05
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::28b3:1ab1:d9d9:19ec%44(Preferred)
IPv4 Address. . . . . . . . . . . : 10.10.182.67(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.128
Default Gateway . . . . . . . . . : 10.10.182.1
NetBIOS over Tcpip. . . . . . . . : Disabled
*Ethernet adapter vEthernet (PAhostVNic):*
<snip> ...
Not
PA Konağı vNIC Bağdaştırıcıları veri yolunda kullanılmaz ve bu nedenle "vEthernet (PAhostVNic) bağdaştırıcısına" atanmış bir IP'ye sahip değildir.
Örneğin, Hyper-V konakları 1 ve 2'nin HNV Sağlayıcısı (PA) IP Adreslerine sahip olduğunu varsayalım:
Hyper-V Konağı | PA IP Adresi 1 | PA IP Adresi 2 |
---|---|---|
Ana Bilgisayar 1 | 10.10.182.64 | 10.10.182.65 |
Ana Bilgisayar 2 | 10.10.182.66 | 10.10.182.67 |
HNV Sağlayıcısı mantıksal ağ bağlantısını denetlemek için aşağıdaki komutu kullanarak ikisi arasında ping işlemi yapabilirsiniz.
# Ping the first PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.64
# Ping the second PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.64
# Ping the first PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.65
# Ping the second PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.65
Düzeltme
HNV Sağlayıcısı ping'i işe yaramazsa VLAN yapılandırması da dahil olmak üzere fiziksel ağ bağlantınızı denetleyin. Her Hyper-V konağındaki fiziksel NIC'ler, belirli bir VLAN atanmamış gövde modunda olmalıdır. Yönetim Konağı vNIC'sinin Yönetim Mantıksal Ağı'nın VLAN'sına yalıtılmış olması gerekir.
PS C:\> Get-NetAdapter "Ethernet 4" |fl
Name : Ethernet 4
InterfaceDescription : <NIC> Ethernet Adapter
InterfaceIndex : 2
MacAddress : F4-52-14-55-BC-21
MediaType : 802.3
PhysicalMediaType : 802.3
InterfaceOperationalStatus : Up
AdminStatus : Up
LinkSpeed(Gbps) : 10
MediaConnectionState : Connected
ConnectorPresent : True
*VlanID : 0*
DriverInformation : Driver Date 2016-08-28 Version 5.25.12665.0 NDIS 6.60
# VMM uses the older PowerShell cmdlet <Verb>-VMNetworkAdapterVlan to set VLAN isolation
PS C:\> Get-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName <Mgmt>
VMName VMNetworkAdapterName Mode VlanList
------ -------------------- ---- --------
<snip> ...
Mgmt Access 7
<snip> ...
# SDNExpress deployments use the newer PowerShell cmdlet <Verb>-VMNetworkAdapterIsolation to set VLAN isolation
PS C:\> Get-VMNetworkAdapterIsolation -ManagementOS
<snip> ...
IsolationMode : Vlan
AllowUntaggedTraffic : False
DefaultIsolationID : 7
MultiTenantStack : Off
ParentAdapter : VMInternalNetworkAdapter, Name = 'Mgmt'
IsTemplate : True
CimSession : CimSession: .
ComputerName : SA18N30-2
IsDeleted : False
<snip> ...
HNV sağlayıcısı mantıksal ağında MTU ve jumbo çerçeve desteğini denetleyin
HNV Sağlayıcısı mantıksal ağdaki bir diğer yaygın sorun, fiziksel ağ bağlantı noktalarının ve/veya Ethernet kartının VXLAN (veya NVGRE) kapsüllemesinden kaynaklanan yükü işlemek için yapılandırılmış yeterince büyük bir MTU'ya sahip olmadığıdır.
Not
Bazı Ethernet kartları ve sürücüleri, Ağ Denetleyicisi Konak Aracısı tarafından otomatik olarak 160 değerine ayarlanacak yeni *EncapOverhead
anahtar sözcüğü destekler. Daha sonra bu değer, tanıtılan MTU olarak toplaması kullanılan *JumboPacket anahtar sözcüğüne eklenir.
Örneğin, *EncapOverhead
= 160 ve *JumboPacket
= 1514 => MTU = 1674B
# Check whether or not your Ethernet card and driver support *EncapOverhead
PS C:\ > Test-EncapOverheadSettings
Verifying Physical Nic : <NIC> Ethernet Adapter #2
Physical Nic <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is 160
Verifying Physical Nic : <NIC> Ethernet Adapter
Physical Nic <NIC> Ethernet Adapter can support SDN traffic. Encapoverhead value set on the nic is 160
HNV Sağlayıcısı mantıksal ağının uçtan uca daha büyük MTU boyutunu destekleyip desteklemediğini test etmek için cmdlet'ini Test-LogicalNetworkSupportsJumboPacket
kullanın:
# Get credentials for both source host and destination host (or use the same credential if in the same domain)
$sourcehostcred = Get-Credential
$desthostcred = Get-Credential
# Use the Management IP Address or FQDN of the Source and Destination Hyper-V hosts
Test-LogicalNetworkSupportsJumboPacket -SourceHost sa18n30-2 -DestinationHost sa18n30-3 -SourceHostCreds $sourcehostcred -DestinationHostCreds $desthostcred
# Failure Results
SourceCompartment : 3
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1632
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1472
Checking if physical nics support jumbo packets on host
Physical Nic <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is 160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.
Checking if physical nics support jumbo packets on host
Physical Nic <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is 160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.
Düzeltme
- Fiziksel anahtar bağlantı noktalarındaki MTU boyutunu en az 1674B olacak şekilde ayarlayın (14B Ethernet üst bilgisi ve treyler dahil)
- NIC kartınız EncapOverhead anahtar sözcüğünü desteklemiyorsa JumboPacket anahtar sözcüğünü en az 1674B olacak şekilde ayarlayın
Kiracı VM NIC bağlantısını denetleme
Konuk VM'ye atanan her VM NIC'sinin özel Müşteri Adresi (CA) ile HNV Sağlayıcı Adresi (PA) alanı arasında bir CA-PA eşlemesi vardır. Bu eşlemeler her Hyper-V konağındaki OVSDB sunucu tablolarında tutulur ve aşağıdaki cmdlet yürütülerek bulunabilir.
# Get all known PA-CA Mappings from this particular Hyper-V Host
PS > Get-PACAMapping
CA IP Address CA MAC Address Virtual Subnet ID PA IP Address
------------- -------------- ----------------- -------------
10.254.254.2 00-1D-D8-B7-1C-43 4115 10.10.182.67
10.254.254.3 00-1D-D8-B7-1C-43 4115 10.10.182.67
192.168.1.5 00-1D-D8-B7-1C-07 4114 10.10.182.65
10.254.254.1 40-1D-D8-B7-1C-06 4115 10.10.182.66
192.168.1.1 40-1D-D8-B7-1C-06 4114 10.10.182.66
192.168.1.4 00-1D-D8-B7-1C-05 4114 10.10.182.66
Not
Beklediğiniz CA-PA eşlemeleri belirli bir kiracı VM için çıkış değilse, lütfen cmdlet'ini kullanarak Get-NetworkControllerNetworkInterface
Ağ Denetleyicisi'nde VM NIC ve IP Yapılandırma kaynaklarını denetleyin. Ayrıca, NC Konak Aracısı ile Ağ Denetleyicisi düğümleri arasında kurulan bağlantıları denetleyin.
Bu bilgilerle, artık cmdlet'i kullanılarak Test-VirtualNetworkConnection
Ağ Denetleyicisi'nden Konakçı tarafından bir kiracı VM ping'i başlatılabilir.
Belirli sorun giderme senaryoları
Aşağıdaki bölümlerde belirli senaryolarda sorun gidermeye yönelik yönergeler sağlanmaktadır.
İki kiracı sanal makinesi arasında ağ bağlantısı yok
- [Kiracı] Kiracı sanal makinelerinde Windows Güvenlik Duvarı'nın trafiği engellemediğinden emin olun.
- [Kiracı] komutunu çalıştırarak
ipconfig
IP adreslerinin kiracı sanal makinesine atandığını denetleyin. - [Hoster] Söz konusu iki kiracı sanal makinesi arasındaki bağlantıyı doğrulamak için Hyper-V konağından komutunu çalıştırın
Test-VirtualNetworkConnection
.
Not
VSID, Sanal Alt Ağ Kimliği'ne başvurur. VXLAN söz konusu olduğunda, bu VXLAN Ağ Tanımlayıcısı 'dır (VNI). Cmdlet'ini Get-PACAMapping
çalıştırarak bu değeri bulabilirsiniz.
Örnek
$password = ConvertTo-SecureString -String "password" -AsPlainText -Force
$cred = New-Object pscredential -ArgumentList (".\administrator", $password)
Her ikisi de Sanal Alt Ağa (VSID) 4114 bağlı 192.168.1.5'in DinleyiciCA IP'sine 10.127.132.153 mgmt IP'sine sahip "sa18n30-2.sa18.nttest.microsoft.com" Ana Bilgisayarında SenderCA IP'sinin 192.168.1.4 olduğu "Yeşil Web VM 1" arasında CA ping'i oluşturun.
Test-VirtualNetworkConnection -OperationId 27 -HostName sa18n30-2.sa18.nttest.microsoft.com -MgmtIp 10.127.132.153 -Creds $cred -VMName "Green Web VM 1" -VMNetworkAdapterName "Green Web VM 1" -SenderCAIP 192.168.1.4 -SenderVSID 4114 -ListenerCAIP 192.168.1.5 -ListenerVSID 4114
Test-VirtualNetworkConnection at command pipeline position 1
Starting CA-space ping test
Starting trace session
Ping to 192.168.1.5 succeeded from address 192.168.1.4
Rtt = 0 ms
CA Routing Information:
Local IP: 192.168.1.4
Local VSID: 4114
Remote IP: 192.168.1.5
Remote VSID: 4114
Distributed Router Local IP: 192.168.1.1
Distributed Router Local MAC: 40-1D-D8-B7-1C-06
Local CA MAC: 00-1D-D8-B7-1C-05
Remote CA MAC: 00-1D-D8-B7-1C-07
Next Hop CA MAC Address: 00-1D-D8-B7-1C-07
PA Routing Information:
Local PA IP: 10.10.182.66
Remote PA IP: 10.10.182.65
<snip> ...
[Kiracı] Sanal alt ağda veya VM ağ arabirimlerinde trafiği engelleyecek dağıtılmış güvenlik duvarı ilkesi olup olmadığını denetleyin.
sa18.nttest.microsoft.com etki alanındaki sa18n30nc'deki tanıtım ortamında bulunan Ağ Denetleyicisi REST API'sini sorgulayın.
$uri = "https://sa18n30nc.sa18.nttest.microsoft.com"
Get-NetworkControllerAccessControlList -ConnectionUri $uri
Bu ACL'ye başvuran IP yapılandırmasına ve sanal alt ağlara bakın
- [Hoster] Söz konusu iki kiracı sanal makinesini barındıran her iki Hyper-V konağında da çalıştırın
Get-ProviderAddress
ve ardından HNV Sağlayıcısı mantıksal ağındaki bağlantıyı doğrulamak için Hyper-V konağından veyaping -c <compartment>
komutunu çalıştırınTest-LogicalNetworkConnection
- [Hoster] Hyper-V konaklarında ve Hyper-V Konakları arasındaki Katman 2 anahtarlama cihazlarında MTU ayarlarının doğru olduğundan emin olun. Söz konusu tüm Hyper-V konaklarında çalıştırın
Test-EncapOverheadValue
. Ayrıca, aralarındaki tüm Katman 2 anahtarlarının en fazla 160 baytlık ek yükü hesaba katmak için MTU'nun en az 1674 bayt olarak ayarlandığını denetleyin. - [Hoster] PA IP Adresleri yoksa ve/veya CA Bağlantısı bozuksa, ağ ilkesinin alındığından emin olun. Katman sanal ağları oluşturmak için gereken kapsülleme kurallarının ve CA-PA eşlemelerinin doğru şekilde oluşturulup oluşturulmamış olduğunu görmek için komutunu çalıştırın
Get-PACAMapping
. - [Hoster] Ağ Denetleyicisi Konak Aracısı'nın Ağ Denetleyicisi'ne bağlı olup olmadığını denetleyin. Bunu yapmak için
netstat -anp tcp |findstr 6640
komutunu çalıştırın. - [Hoster] HKLM/ içindeki Konak Kimliğinin, kiracı sanal makinelerini barındıran sunucu kaynaklarının Örnek Kimliği ile eşleşir.
- [Hoster] Bağlantı Noktası Profili Kimliğinin, kiracı sanal makinelerinin VM Ağ Arabirimlerinin Örnek Kimliği ile eşleşir olup olmadığını denetleyin.
Günlüğe kaydetme, izleme ve gelişmiş tanılama
Aşağıdaki bölümlerde gelişmiş tanılama, günlüğe kaydetme ve izleme hakkında bilgi sağlanır.
Ağ denetleyicisi merkezi günlüğü
Ağ Denetleyicisi hata ayıklayıcı günlüklerini otomatik olarak toplayabilir ve merkezi bir konumda depolayabilir. Günlük toplama, Ağ Denetleyicisi'ni ilk kez veya daha sonra dağıttığınızda etkinleştirilebilir. Günlükler Ağ Denetleyicisi'nden ve Ağ Denetleyicisi tarafından yönetilen ağ öğelerinden toplanır: konak makineler, yazılım yük dengeleyiciler (SLB) ve ağ geçidi makineleri.
Bu günlükler Ağ Denetleyicisi kümesi, Ağ Denetleyicisi uygulaması, ağ geçidi günlükleri, SLB, sanal ağ ve dağıtılmış güvenlik duvarı için hata ayıklama günlüklerini içerir. Ağ Denetleyicisi'ne yeni bir konak/SLB/ağ geçidi eklendiğinde, bu makinelerde günlüğe kaydetme başlatılır. Benzer şekilde, bir konak/SLB/ağ geçidi Ağ Denetleyicisi'nden kaldırıldığında bu makinelerde günlük kaydı durdurulur.
Günlü kaydını etkinleştir
Cmdlet'ini kullanarak Ağ Denetleyicisi kümesini yüklediğinizde günlüğe Install-NetworkControllerCluster
kaydetme otomatik olarak etkinleştirilir. Varsayılan olarak, günlükler %systemdrive%\SDNDiagnostics konumundaki Ağ Denetleyicisi düğümlerinde yerel olarak toplanır. Bu konumu uzak dosya paylaşımı (yerel değil) olarak değiştirmeniz önerilir.
Ağ Denetleyicisi küme günlükleri %programData%\Windows Fabric\log\Traces konumunda depolanır. Bunun da uzak bir dosya paylaşımı olması önerisini kullanarak parametresiyle DiagnosticLogLocation
günlük koleksiyonu için merkezi bir konum belirtebilirsiniz.
Bu konuma erişimi kısıtlamak istiyorsanız, erişim kimlik bilgilerini parametresiyle LogLocationCredential
sağlayabilirsiniz. Günlük konumuna erişmek için kimlik bilgilerini sağlarsanız, Ağ Denetleyicisi düğümlerinde yerel olarak depolanan kimlik bilgilerini şifrelemek için kullanılan parametresini de sağlamanız CredentialEncryptionCertificate
gerekir.
Varsayılan ayarlarla, merkezi konumda en az 75 GB boş alan ve üç düğümlü bir Ağ Denetleyicisi kümesi için yerel düğümlerde (merkezi konum kullanmıyorsa) 25 GB boş alanınız olması önerilir.
Günlük ayarlarını değiştirme
İstediğiniz zaman cmdlet'ini Set-NetworkControllerDiagnostic
kullanarak günlük ayarlarını değiştirebilirsiniz. Aşağıdaki ayarlar değiştirilebilir:
Merkezi günlük konumu.
parametresiyle
DiagnosticLogLocation
tüm günlükleri depolamak için konumu değiştirebilirsiniz.Günlük konumuna erişmek için kimlik bilgileri.
Parametresiyle
LogLocationCredential
günlük konumuna erişmek için kimlik bilgilerini değiştirebilirsiniz.Yerel günlüğe gitme.
Günlükleri depolamak için merkezi bir konum sağladıysanız, parametresiyle
UseLocalLogLocation
Ağ Denetleyicisi düğümlerinde yerel olarak günlüğe kaydetmeye geri dönebilirsiniz (büyük disk alanı gereksinimleri nedeniyle önerilmez).Günlüğe kaydetme kapsamı.
Varsayılan olarak tüm günlükler toplanır. Kapsamı yalnızca Ağ Denetleyicisi küme günlüklerini toplayacak şekilde değiştirebilirsiniz.
Günlük düzeyi.
Varsayılan günlük düzeyi Bilgi düzeyidir. Hata, Uyarı veya Ayrıntılı olarak değiştirebilirsiniz.
Günlük Eskime süresi.
Günlükler dairesel bir şekilde depolanır. İster yerel günlük ister merkezi günlük kaydı kullanın, varsayılan olarak üç günlük kaydınız vardır. Bu zaman sınırını parametresiyle
LogTimeLimitInDays
değiştirebilirsiniz.Günlük Eskime boyutu.
Varsayılan olarak, merkezi günlük kullanıyorsanız en fazla 75 GB günlük verisine ve yerel günlük kullanıyorsanız 25 GB'a sahip olursunuz. Bu sınırı parametresiyle
LogSizeLimitInMBs
değiştirebilirsiniz.
Günlükleri ve izlemeleri toplama
VMM dağıtımları varsayılan olarak Ağ Denetleyicisi için merkezi günlüğü kullanır. Bu günlükler için dosya paylaşımı konumu, Ağ Denetleyicisi hizmet şablonu dağıtılırken belirtilir.
Bir dosya konumu belirtilmemişse, C:\Windows\tracing\SDNDiagnostics altında kaydedilen günlüklerle her Ağ Denetleyicisi düğümünde yerel günlükler kullanılır. Bu günlükler aşağıdaki hiyerarşi kullanılarak kaydedilir:
- CrashDumps
- NCApplicationCrashDumps
- NCApplicationLogs
- PerfCounters
- SDNDiagnostics
- İzlemeler
Ağ Denetleyicisi (Azure) Service Fabric kullanır. Bazı sorunları giderirken Service Fabric günlükleri gerekebilir. Bu günlükler her Ağ Denetleyicisi düğümünde C:\ProgramData\Microsoft\Service Fabric konumunda bulunabilir.
Bir kullanıcı cmdlet'ini Debug-NetworkController
çalıştırdıysa, ağ denetleyicisindeki bir sunucu kaynağıyla belirtilen her Hyper-V konağında daha fazla günlük bulunur. Bu günlükler (ve etkinse izlemeler) C:\NCDiagnostics altında tutulur.
SLB tanılaması
SLBM doku hataları (Barındırma hizmeti sağlayıcısı eylemleri)
- Yazılım Yük Dengeleyici Yöneticisi'nin (SLBM) çalıştığını ve düzenleme katmanlarının birbiriyle konuşabildiğini denetleyin: SLBM -> SLB Mux ve SLBM -> SLB Konak Aracıları. Ağ Denetleyicisi REST Uç Noktasına erişimi olan herhangi bir düğümden DumpSlbRestState komutunu çalıştırın.
- Ağ Denetleyicisi düğümü VM'lerinden birinde (tercihen birincil Ağ Denetleyicisi düğümü -
Get-NetworkControllerReplica
) PerfMon'da SDNSLBMPerfCounters'ı doğrulayın:- Load Balancer (LB) altyapısı SLBM'ye bağlı mı? (SLBM LBEngine Yapılandırmaları Toplam > 0)
- SLBM en azından kendi uç noktalarını biliyor mu? (VIP Uç Noktaları Toplam>= 2)
- Hyper-V (DIP) konakları SLBM'ye bağlı mı? (BAĞLı HP istemcileri == sayı sunucuları)
- SLBM Muxes'e bağlı mı? (Muxes Connected == Muxes Healthy on SLBM == Muxes reporting healthy = # SLB Muxes VM'leri).
- Yapılandırılan BGP yönlendiricisinin SLB MUX ile başarıyla eşlendiğinden emin olun.
- Uzaktan Erişim ile RRAS kullanıyorsanız (bgp sanal makinesi):
Get-BgpPeer
bağlı olarak gösterilmelidir.Get-BgpRouteInformation
SLBM self VIP için en az bir yol göstermelidir.
- BGP Eş olarak fiziksel Raf Üstü (ToR) anahtarı kullanıyorsanız belgelerinize bakın:
- Örneğin:
# show bgp instance
- Örneğin:
- Uzaktan Erişim ile RRAS kullanıyorsanız (bgp sanal makinesi):
- SLB Mux VM'sindeki PerfMon'da SlbMuxPerfCounters ve SLBMUX sayaçlarını doğrulayın.
- Yazılım Yük Dengeleyici Yöneticisi Kaynağı'nda yapılandırma durumunu ve VIP aralıklarını denetleyin.
Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8
(IP Havuzlarındaki VIP aralıklarını denetleyin ve SLBM self-VIP (LoadBalanacerManagerIPAddress) ve kiracıya yönelik VIP'lerin bu aralıklar içinde olduğundan emin olun)Get-NetworkControllerIpPool -NetworkId "<Public/Private VIP Logical Network Resource ID>" -SubnetId "<Public/Private VIP Logical Subnet Resource ID>" -ResourceId "\<IP Pool Resource Id>" -ConnectionUri $uri |convertto-json -depth 8
Debug-NetworkControllerConfigurationState -
Yukarıdaki denetimlerden herhangi biri başarısız olursa kiracı SLB durumu da hata modunda olur.
Düzeltme
Sunulan aşağıdaki tanılama bilgilerine dayanarak aşağıdakileri düzeltin:
- SLB Çoğullayıcılarının bağlı olduğundan emin olun
- Sertifika sorunlarını düzeltme
- Ağ bağlantısı sorunlarını düzeltme
- BGP eşleme bilgilerinin başarıyla yapılandırıldığından emin olun
- Kayıt defterindeki Ana Bilgisayar Kimliğinin Sunucu Kaynağındaki Sunucu Örneği Kimliği ile eşleştiğinden emin olun (HostNotConnected hata kodu için eke başvurun)
- Günlükleri toplama
SLBM kiracı hataları (Barındırma hizmeti sağlayıcısı ve kiracı eylemleri)
- [Hoster] LoadBalancer kaynaklarının hata durumunda olup olmadığını denetleyin
Debug-NetworkControllerConfigurationState
. Ekteki Eylem öğeleri Tablosunu izleyerek azaltmayı deneyin.- VIP uç noktasının mevcut olup olmadığını ve rotaları tanıtıp göstermediğini denetleyin.
- VIP uç noktası için kaç DIP uç noktasının keşfedildiğini denetleyin.
- [Kiracı] Load Balancer Kaynaklarının doğru belirtildiğini doğrulayın.
- SLBM'de kayıtlı DIP uç noktalarının LoadBalancer Arka Uç Adres havuzu IP yapılandırmalarına karşılık gelen kiracı sanal makinelerini barındırdığını doğrulayın.
- [Hoster] DIP uç noktaları bulunmazsa veya bağlı değilse:
Çek
Debug-NetworkControllerConfigurationState
NC ve SLB Konak Aracısı'nın kullanarak
netstat -anp tcp |findstr 6640)
Ağ Denetleyicisi Olay Düzenleyicisi'ne başarıyla bağlandığını doğrulayın.HostId
Hizmet kayıt defteri anahtarınanchostagent
bakın (Ekteki başvuruHostNotConnected
hata kodu), ilgili sunucu kaynağının örnek kimliğiyle (Get-NCServer |convertto-json -depth 8
) eşleşir.Sanal makine bağlantı noktası için bağlantı noktası profili kimliğini, ilgili sanal makine NIC kaynağının Örnek kimliğiyle eşleşir.
- [Barındırma sağlayıcısı] Günlükleri toplayın.
SLB Mux izleme
Yazılım Yük Dengeleyici Muxes'ten alınan bilgiler Olay Görüntüleyicisi aracılığıyla da belirlenebilir.
- Olay Görüntüleyicisi Görünüm menüsünün altında Analiz ve Hata Ayıklama Günlüklerini Göster'i seçin.
- Olay Görüntüleyicisi'da Uygulama ve Hizmet Günlükleri>Microsoft>Windows>SlbMuxDriver>İzleme'ye gidin.
- Sağ tıklayın ve Günlüğü Etkinleştir'i seçin.
Not
Sorunu yeniden oluşturmaya çalışırken bu günlüğü yalnızca kısa bir süre için etkinleştirmeniz önerilir.
VFP ve vSwitch izleme
Kiracı sanal ağına bağlı bir konuk VM'yi barındıran herhangi bir Hyper-V konağından, sorunların nerede olabileceğini belirlemek için bir VFP izlemesi toplayabilirsiniz.
netsh trace start provider=Microsoft-Windows-Hyper-V-VfpExt overwrite=yes tracefile=vfp.etl report=disable provider=Microsoft-Windows-Hyper-V-VmSwitch
netsh trace stop
netsh trace convert .\vfp.etl ov=yes