Übung: Identifizieren und Auflösen der eingehenden Netzwerkkonnektivität

40 Minuten

In unserem Szenario wurde eine Änderung an der Netzwerkkonfiguration vorgenommen. Sie erhalten Warnungen, dass virtuelle VMs im Back-End-Pool nicht auf Integritätstests reagieren. Nun müssen Sie die Ursache dieser Ausfälle diagnostizieren und sie beheben.

In dieser Übung verwenden Sie ein Skript, um die Umgebung neu zu konfigurieren und Ausfälle bei Integritätstests zu verursachen. Sie verwenden die in diesem Modul gewonnenen Fähigkeiten, um den HTTP-Dienst mit Lastenausgleich wieder vollständig funktionsfähig zu machen.

Neukonfigurieren des Lastenausgleichs und erneutes Testen

Legen Sie in Azure Cloud Shell den Namen für die Ressourcengruppe fest.
```
export RESOURCEGROUP=learn-ts-loadbalancer-rg
```
Wechseln Sie zum Ordner src/scripts.
```
cd ~/load-balancer/src/scripts
```
Führen Sie den folgenden Befehl aus, um den Lastenausgleich, das Netzwerk und die virtuellen Computer neu zu konfigurieren. Dieses Skript führt zu einigen Problemen, die Sie diagnostizieren und beheben werden.
```
bash reconfigure.sh
```
Führen Sie die folgenden Befehle aus, um zum Ordner src/stresstest zu wechseln.
```
cd ~/load-balancer/src/stresstest
```
Führen Sie den Belastungstest noch mal aus, wobei Sie <ip address> durch die IP-Adresse des Lastenausgleichs ersetzen. Wenn Sie sich nicht mehr an diese Adresse erinnern können, führen Sie das Skript src/scripts/findip.sh noch mal aus.
```
dotnet run <ip address>
```
Dieses Mal generiert die App keine Ausgabe, und es kann zu einem Timeout mit folgender Meldung kommen: „Fehler beim Senden der Anforderung an Lastenausgleich: Der Vorgang wurde abgebrochen.“ Drücken Sie die EINGABETASTE, um die Anwendung zu beenden.
Wählen Sie im Azure-Portal Dashboard>dashboard-learn-ts-loadbalancer aus.
Überprüfen Sie das Dashboard, das den Status des Integritätstests sowie die Verfügbarkeit des Datenpfads anzeigt. Möglicherweise müssen Sie den Zeitbereich anpassen, sodass dieser die letzten 30 Minuten umfasst. Es sollte ein Diagramm wie folgendes angezeigt werden, bei dem beide Metriken auf 0 gefallen sind.

Dieses Diagramm zeigt, dass die virtuellen Computer nicht auf Integritätstestanforderungen des Lastenausgleichs reagieren. Sie wurden daher als fehlerhaft gekennzeichnet. Zwischen einem Client und der Anwendung, die auf diesen virtuellen Computern ausgeführt wird, steht kein Datenpfad zur Verfügung.

Diagnostizieren und Beheben von Fehlern

Als ersten Schritt vergewissern Sie sich, dass die virtuellen Computer ausgeführt werden. Beheben Sie nun die Fehler jeweils pro virtuellen Computer. Sehen Sie sich zunächst appretailvm1 an. Später kümmern Sie sich um appretailvm2.

Testen des virtuellen Computers „appretailvm1“

Sie können die virtuellen Computer appretailvm1 und appretailvm2 nicht direkt pingen, da sie über private Adressen verfügen, die nur für andere virtuelle Computer im selben Subnetz verfügbar sind. Stellen Sie zuerst eine Verbindung mit der Jumpbox her, die eine öffentliche IP-Adresse hat und sich im selben Subnetz befindet. Dann können Sie die virtuellen Computer von dort aus pingen.

Wechseln Sie wieder zu Cloud Shell.
Führen Sie die folgenden Befehle aus, um die IP-Adresse des virtuellen Jumpbox-Computers abzurufen.
```
bash ~/load-balancer/src/scripts/jumpboxip.sh
```
Führen Sie den folgenden Befehl aus, um das Kennwort abzurufen, das Sie beim Ausführen des ursprünglichen Setupskripts erstellt haben. Kopieren Sie dieses Kennwort für den nächsten Schritt.
```
cd ~/load-balancer/src/scripts
cat passwd.txt
```
Melden Sie sich mit der IP-Adresse und dem Kennwort aus den vorherigen Befehlen bei der Jumpbox an. Ersetzen Sie azureuser durch den entsprechenden Benutzernamen, falls Sie einen anderen verwendet haben.
```
ssh azureuser@<jump box ip address>
```
Führen Sie auf der Jumpbox den folgenden Befehl aus, um zu testen, ob der virtuelle Computer retailappvm1 ausgeführt wird.
```
ping retailappvm1 -c 10
```
Der virtuelle Computer „retailappvm1“ sollte antworten und angeben, dass er ausgeführt wird. Der nächste Schritt besteht darin, zu bestimmen, ob die Web-App auf diesem virtuellen Computer ausgeführt wird.
Führen Sie den folgenden Befehl aus, um eine HTTP-GET-Anforderung an den virtuellen Computer „retailappvm1“ zu senden.
```
curl -v http://retailappvm1
```
Dieser Befehl sollte ebenfalls erfolgreich sein.

Überprüfen von Integritätstests und Routingregeln

Der virtuelle Computer retailappvm1 läuft, und die Anwendung wird auf diesem virtuellen Computer ausgeführt. Es muss ein Problem zwischen dem Lastenausgleich und den virtuellen Computern im Back-End-Pool vorliegen.

Suchen Sie im Azure-Portal nach Monitor.
Klicken Sie auf der Seite Monitor – Übersicht auf Service Health.
Klicken Sie auf Ressourcenintegrität.
Wählen Sie im Feld Ressourcentyp die Option Lastenausgleichaus. Wählen Sie in der Liste der Ressourcen retailapplb aus.
Warten Sie einige Minuten, bis die Integrität des Lastenausgleichs ausgewertet wurde.
Erweitern Sie unter Integritätsverlauf das oberste Ereignis, und prüfen Sie die empfohlenen Schritte. In den Schritten wird empfohlen, dass Sie die VIP- und DIP-Endpunkte (Routingregel bzw. Integritätstest) im Lastenausgleich überprüfen.
Navigieren Sie zur Ressourcengruppe learn-ts-loadbalancer-rg, und klicken Sie auf retailapplb.
Klicken Sie auf Lastenausgleichsregeln>retailapprule. Diese Regel empfängt TCP-Datenverkehr an Port 80 der Front-End-IP-Adresse und sendet diesen an Port 80 auf dem ausgewählten virtuellen Computer im Back-End-Pool. Diese Konfiguration scheint korrekt zu sein, obwohl der vom Integritätstest verwendete Port verdächtig aussieht. Er ist zurzeit auf Port 85 festgelegt.
Schließen Sie die Seite retailapprule.
Klicken Sie auf Integritätstests>retailapphealthprobe.
Ändern Sie den Port von 85 zurück in 80, und klicken Sie dann auf Speichern.
Warten Sie ein paar Minuten.
Klicken Sie im Menü auf der linken Seite des Azure-Portals auf Dashboard.
Wählen Sie auf dem Dashboard das Diagramm aus, das den Status des Integritätstests sowie die Metriken zur Verfügbarkeit des Datenpfads anzeigt. Die Metrik Data Path Availability (Verfügbarkeit des Datenpfads) sollte auf 100 steigen, die Metrik Health Probe Status (Status des Integritätstests) sollte jedoch bei etwa 50 stehen. Es ist nun ein Pfad vom Lastenausgleich zu mindestens einem virtuellen Computer verfügbar, jedoch werden nur 50 Prozent der virtuellen Computer als fehlerfrei angezeigt.

Klicken Sie auf das Diagramm, um zur Seite „Metriken“ für den Lastenausgleich zu wechseln. Auf dieser Seite können Sie das Diagramm aktualisieren und einen bestimmten Zeitraum vergrößern.
Führen Sie in Cloud Shell den folgenden Befehl aus, um die Jumpbox zu verlassen.
```
exit
```
Führen Sie die Belastungstestanwendung unter Verwendung der IP-Adresse des Lastenausgleichs noch mal aus.
```
cd ~/load-balancer/src/stresstest
dotnet run <ip address>
```
Wie zuvor tritt beim Test wieder ein Fehler auf. Es gibt nun einen Pfad vom Lastenausgleich zu mindestens einem virtuellen Computer. Dieser Pfad funktioniert jedoch nicht von einem Client aus, der außerhalb des virtuellen Netzwerks ausgeführt wird. Drücken Sie die Eingabetaste, um die Belastungstest-App zu beenden.

Überprüfen der NSG-Regeln für das Subnetz

Die Ursache für das Problem könnte eine Netzwerksicherheitsregel sein, die externen Datenverkehr blockiert.

Navigieren Sie im Azure-Portal zur Ressourcengruppe learn-ts-loadbalancer-rg.
Wählen Sie die Netzwerksicherheitsgruppe retailappnsg aus. Diese Sicherheitsgruppe bestimmt, welcher Datenverkehr im virtuellen Netzwerk zugelassen wird.
Klicken Sie auf Eingangssicherheitsregeln. Es gibt zwar eine Regel, die eingehenden Datenverkehr vom Lastenausgleich zulässt, jedoch keine, die Datenverkehr von außerhalb des virtuellen Netzwerks durch Port 80 zulässt.
Wählen Sie Hinzufügen. Der Bereich Eingangssicherheitsregel hinzufügen wird angezeigt.

Geben Sie die folgenden Einstellungen ein, und klicken Sie dann auf Hinzufügen.

Eigenschaft	Value
`Source`	Alle
Source port ranges	*
Destination	Any
Dienst	Benutzerdefiniert
Zielportbereiche	80
Protokoll	TCP
Aktion	Allow
Priority	100
Name	Port_80
Beschreibung	HTTP-Port

Führen Sie in Cloud Shell die Belastungstestanwendung unter Verwendung der IP-Adresse des Lastenausgleichs noch mal aus.
```
cd ~/load-balancer/src/stresstest
dotnet run <ip address>
```
Die Anwendung wird jetzt ausgeführt, Sie erhalten jedoch nur eine Antwort von der VM retailappvm1. Führen Sie die Anwendung zwei oder drei Minuten lang aus. Drücken Sie die Eingabetaste, um sie zu beenden.
Navigieren Sie im Azure-Portal zum Dashboard.
Wählen Sie das Diagramm für die Metrik für die durchschnittliche Paketanzahl aus. Beachten Sie den Höchstwert für die letzte Ausführung der Belastungstestanwendung. Dieser Wert sollte mindestens doppelt so hoch sein wie der zuvor aufgezeichnete Wert, als beide VMs verfügbar waren. Obwohl Sie nun über ein funktionierendes System verfügen, besteht die Gefahr, die funktionierende VM zu überladen.

Testen der VM „appretailvm2“

Die VM appretailvm2 verarbeitet Anforderungen anscheinend nicht ordnungsgemäß. Sie müssen überprüfen, ob diese VM fehlerfrei ist, und ob Load Balancer eine Verbindung dazu herstellen kann.

Melden Sie sich in Cloud Shell mit der IP-Adresse und dem Kennwort aus den vorherigen Befehlen bei der Jumpbox an.
```
ssh azureuser@<jump box ip address>
```
Versuchen Sie, die VM appretailvm2 anzupingen.
```
ping retailappvm2 -c 10
```
Die VM antwortet nicht, und der Pingbefehl meldet einen 100-prozentigen Paketverlust. Entweder wird die VM retailappvm2 nicht ausgeführt, oder es gibt ein Netzwerkproblem.
Navigieren Sie im Azure-Portal zur Ressourcengruppe learn-ts-loadbalancer-rg.
Wählen Sie die VM retailappvm2 aus.
Auf der Seite Übersicht sehen Sie, dass die VM angehalten wurde. Klicken Sie auf Starten, und warten Sie, bis die VM ausgeführt wird.
Navigieren Sie zurück zur Cloud Shell-Instanz, die mit der Jumpbox verbunden ist, und führen Sie den Pingbefehl noch mal aus.
```
ping retailappvm2 -c 10
```
Dieses Mal sollten die Pingvorgänge erfolgreich sein.
Testen Sie, ob die auf der VM retailappvm2 ausgeführte Anwendung antwortet.
```
wget retailappvm2
```
Der Befehl führt zu einem Timeout. Entweder wird die Anwendung nicht ausgeführt, oder es gibt ein Netzwerkproblem. Drücken Sie STRG+C, um den Befehl zu beenden.
Melden Sie sich in der Jumpbox bei der VM retailappvm2 an. Geben Sie das Kennwort ein, das Sie zuvor festgelegt haben, wenn Sie dazu aufgefordert werden.
```
ssh azureuser@retailappvm2
```
Führen Sie den folgenden Befehl aus, um die Anwendung auf dieser VM zu testen.
```
wget retailappvm2
```
Der Befehl sollte erfolgreich sein und die Datei index.html erstellen, die die Antwort enthält.
Sehen Sie sich diese index.html-Datei an.
```
cat index.html
```
Die Datei sollte die Meldung retailappvm2 enthalten, die zeigt, dass diese VM erwartungsgemäß geantwortet hat.
Trennen Sie die Verbindung zur VM retailappvm2.
```
exit
```
Trennen Sie die Verbindung zur Jumpbox.
```
exit
```
Die VM retailappvm2 ist einsatzbereit, und die App wird ausgeführt, Sie können jedoch von außerhalb der VM keine Verbindung zur App herstellen. Dieses Problem deutet auf ein Netzwerkproblem hin.
Navigieren Sie im Azure-Portal zur Ressourcengruppe learn-ts-loadbalancer-rg.
Wählen Sie die Netzwerksicherheitsgruppe retailappnicvm2nsg aus.
Klicken Sie auf Eingangssicherheitsregeln.

Für die Netzwerksicherheitsgruppe gilt eine Eingangssicherheitsregel, die allen externen Datenverkehr blockiert, für den das TCP-Protokoll verwendet wird. Diese Regel hat einen niedrigeren Prioritätswert als die Regel, die Port 80 öffnet, sodass sie Vorrang hat.
Wählen Sie die Regel retailappvnetnsgrulevm2denyall aus, ändern Sie die Priorität auf 300, und klicken Sie dann auf Speichern.
Warten Sie zwei Minuten, und navigieren Sie dann zum Dashboard.
Wählen Sie das Diagramm aus, das die Metrik Health Probe Status (Status des Integritätstests) zeigt. Der Wert dieser Metrik sollte auf 100 ansteigen. Möglicherweise müssen Sie das Diagramm einige Male aktualisieren.
Wechseln Sie zu Cloud Shell, und führen Sie die stresstest-Anwendung unter Verwendung der IP-Adresse der Load Balancer-Instanz noch mal aus.
```
cd ~/load-balancer/src/stresstest
dotnet run <ip address>
```
Nun sollten Meldungen von retailappvm1 und retailappvm2 angezeigt werden. Sie haben die volle Konnektivität für das System wiederhergestellt.
Drücken Sie die EINGABETASTE, um die Anwendung zu beenden.

Zusammenfassung

Zu Beginn dieser Übung haben Sie gesehen, dass die VMs nicht auf Integritätstestanforderungen der Load Balancer-Instanz geantwortet haben. Sie haben festgestellt, dass eine Kombination aus Test- und Datenpfadproblemen vorlag, und diese behoben:

In der Lastenausgleichsregel retailapprule war der vom Integritätstest verwendete Port fehlerhaft konfiguriert, sodass 85 anstelle von 80 verwendet wurde. Sie haben die Regel aktualisiert, sodass jetzt Port 80 verwendet wird.
Für die Netzwerksicherheitsgruppe retailappnsg gab es keine Eingangssicherheitsregel, die Datenverkehr für Port 80 zuließ. Die Netzwerksicherheitsgruppe hat also den Integritätstest blockiert. Sie haben eine Eingangssicherheitsregel hinzugefügt, sodass Datenverkehr auf Port 80 zulässig ist.
Sie haben die VM retailappvm2 überprüft und festgestellt, dass sie angehalten wurde. Sie haben die VM neu gestartet.
Nachdem Sie die VM retailappvm2 gestartet und festgestellt haben, dass die App ausgeführt wird, konnten Sie keine Verbindung zur App herstellen. Für die Netzwerksicherheitsgruppe galt eine Eingangsregel, die allen Netzwerkdatenverkehr für das TCP-Protokoll blockierte. Eine „Alle ablehnen“-Regel hatte Vorrang vor einer Eingangssicherheitsregel, die Datenverkehr zu Port 80 zuließ. Sie haben die Priorität dieser „Alle ablehnen“-Regel so geändert, dass sie höher als die der Regel für Port 80 war. Durch diese Änderung wurde eingehender Netzwerkdatenverkehr für Port 80 für das TCP-Protokoll zugelassen.

Sie haben dafür gesorgt, dass der HTTP-Dienst mit Lastenausgleich wieder ordnungsgemäß funktioniert.

Weiter