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-VMSwitchExternalPortIdve 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ı OkReplicaStatus 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

  1. [Kiracı] Kiracı sanal makinelerinde Windows Güvenlik Duvarı'nın trafiği engellemediğinden emin olun.
  2. [Kiracı] komutunu çalıştırarak ipconfigIP adreslerinin kiracı sanal makinesine atandığını denetleyin.
  3. [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

  1. [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 veya ping -c <compartment> komutunu çalıştırın Test-LogicalNetworkConnection
  2. [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.
  3. [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 .
  4. [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.
  5. [Hoster] HKLM/ içindeki Konak Kimliğinin, kiracı sanal makinelerini barındıran sunucu kaynaklarının Örnek Kimliği ile eşleşir.
  6. [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)

  1. 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.
  2. Ağ Denetleyicisi düğümü VM'lerinden birinde (tercihen birincil Ağ Denetleyicisi düğümü - Get-NetworkControllerReplica) PerfMon'da SDNSLBMPerfCounters'ı doğrulayın:
    1. Load Balancer (LB) altyapısı SLBM'ye bağlı mı? (SLBM LBEngine Yapılandırmaları Toplam > 0)
    2. SLBM en azından kendi uç noktalarını biliyor mu? (VIP Uç Noktaları Toplam>= 2)
    3. Hyper-V (DIP) konakları SLBM'ye bağlı mı? (BAĞLı HP istemcileri == sayı sunucuları)
    4. SLBM Muxes'e bağlı mı? (Muxes Connected == Muxes Healthy on SLBM == Muxes reporting healthy = # SLB Muxes VM'leri).
  3. Yapılandırılan BGP yönlendiricisinin SLB MUX ile başarıyla eşlendiğinden emin olun.
    1. Uzaktan Erişim ile RRAS kullanıyorsanız (bgp sanal makinesi):
      1. Get-BgpPeer bağlı olarak gösterilmelidir.
      2. Get-BgpRouteInformation SLBM self VIP için en az bir yol göstermelidir.
    2. BGP Eş olarak fiziksel Raf Üstü (ToR) anahtarı kullanıyorsanız belgelerinize bakın:
      1. Örneğin: # show bgp instance
  4. SLB Mux VM'sindeki PerfMon'da SlbMuxPerfCounters ve SLBMUX sayaçlarını doğrulayın.
  5. Yazılım Yük Dengeleyici Yöneticisi Kaynağı'nda yapılandırma durumunu ve VIP aralıklarını denetleyin.
    1. 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)
      1. 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
    2. 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)

  1. [Hoster] LoadBalancer kaynaklarının hata durumunda olup olmadığını denetleyin Debug-NetworkControllerConfigurationState . Ekteki Eylem öğeleri Tablosunu izleyerek azaltmayı deneyin.
    1. VIP uç noktasının mevcut olup olmadığını ve rotaları tanıtıp göstermediğini denetleyin.
    2. VIP uç noktası için kaç DIP uç noktasının keşfedildiğini denetleyin.
  2. [Kiracı] Load Balancer Kaynaklarının doğru belirtildiğini doğrulayın.
    1. 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.
  3. [Hoster] DIP uç noktaları bulunmazsa veya bağlı değilse:
    1. Ç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.

    2. HostIdHizmet kayıt defteri anahtarına nchostagent bakın (Ekteki başvuru HostNotConnected hata kodu), ilgili sunucu kaynağının örnek kimliğiyle (Get-NCServer |convertto-json -depth 8) eşleşir.

    3. 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.

  4. [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.

  1. 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.
  2. Olay Görüntüleyicisi'da Uygulama ve Hizmet Günlükleri>Microsoft>Windows>SlbMuxDriver>İzleme'ye gidin.
  3. 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