演習 - 受信ネットワーク接続を特定して解決する - Training

40 分

このシナリオでは、ネットワーク構成に変更が加えられました。あなたは、バックエンドプール内の仮想マシンが正常性プローブに応答していないというアラートを受信しています。ここで、これらのエラーの原因を診断し、修正する必要があります。

この演習では、スクリプトを使って環境を再構成し、正常性プローブの障害を発生させます。このモジュールで学習したスキルを使って、負荷分散された HTTP サービスを完全な動作に戻します。

ロードバランサーを再構成して再テストする

Azure Cloud Shell で、リソースグループ名を設定します。
```
export RESOURCEGROUP=learn-ts-loadbalancer-rg
```
src/scripts フォルダーにアクセスします。
```
cd ~/load-balancer/src/scripts
```
次のコマンドを実行して、ロードバランサー、ネットワーク、および仮想マシンを再構成します。このスクリプトによって、後で診断と修正を行ういくつかの問題を導入します。
```
bash reconfigure.sh
```
次のコマンドを実行して、src/stresstest フォルダーに移動します。
```
cd ~/load-balancer/src/stresstest
```
<ip address> をロードバランサーの IP アドレスに置き換えて、ストレステストを再実行します。このアドレスを覚えていない場合は、src/scripts/findip.sh スクリプトをもう一度実行してください。
```
dotnet run <ip address>
```
この場合、アプリによって出力は生成されず、最終的にタイムアウトして "Error sending request to Load Balancer: The operation was canceled (ロードバランサーへの要求の送信でエラーが発生しました: 操作は取り消されました)" というメッセージが表示されることがあります。Enter キーを押してアプリケーションを停止します。
Azure portal で、[ダッシュボード]>[dashboard-learn-ts-loadbalancer] を選択します。
正常性プローブの状態とデータパスの可用性を示すダッシュボードを確認します。時間の範囲を過去 30 分に変更することが必要になる場合があります。次のグラフのように、両方のメトリックがゼロまで下降します。

このグラフは、仮想マシンがロードバランサーからの正常性プローブ要求に応答していないことを示しています。そのため、異常としてマークされています。クライアントと、これらの仮想マシンで実行されているアプリケーションとの間で使用できるデータパスがありません。

問題を診断して修正する

最初の手順では、仮想マシンが実行されていることを確認します。一度に 1 つずつ仮想マシンを確認し、問題を解決してみましょう。まず appretailvm1 を確認してから、 appretailvm2 を確認します。

appretailvm1 仮想マシンをテストする

同じサブネット上の他の仮想マシンのみが使用できるプライベートアドレスを持つため、appretailvm1 または appretailvm2 仮想マシンに対して直接 ping を行うことはできません。まず、パブリック IP アドレスを持つ、同じサブネット内にあるジャンプボックスに接続します。その後、そこから仮想マシンに ping を実行します。

Cloud Shell に戻ります。
ジャンプボックス仮想マシンの IP アドレスを取得するには、次のコマンドを実行します。
```
bash ~/load-balancer/src/scripts/jumpboxip.sh
```
次のコマンドを実行して、初期セットアップスクリプトの実行時に作成したパスワードを取得します。次の手順で使用するために、このパスワードをコピーします。
```
cd ~/load-balancer/src/scripts
cat passwd.txt
```
前のコマンド出力の IP アドレスとパスワードを使ってジャンプボックスにサインインします。別のユーザー名を使用した場合は、azureuser を置き換えます。
```
ssh azureuser@<jump box ip address>
```
ジャンプボックスで次のコマンドを実行して、retailappvm1 仮想マシンが実行されているかどうかをテストします。
```
ping retailappvm1 -c 10
```
retailappvm1 仮想マシンが応答し、実行されていることが示されます。次の手順では、この仮想マシンで Web アプリが実行されているかどうかを確認します。
次のコマンドを実行して、HTTP GET 要求を retailappvm1 仮想マシンに送信します。
```
curl -v http://retailappvm1
```
ここでも、このコマンドは正常に実行されます。

正常性プローブとルーティング規則を確認する

retailappvm1 仮想マシンが起動し、その仮想マシンでアプリケーションが実行されています。ロードバランサーとバックエンドプール内の仮想マシンとの間に問題が発生しています。

Azure portal で、"モニター" を検索します。
[Monitor - Overview](モニター - 概要) ページで、[Service Health] を選択します。
[リソース正常性] を選択します。
[リソースの種類] ボックスで、[ロードバランサー] を選択します。リソースの一覧で、[retailapplb] を選択します。
ロードバランサーの正常性が評価されるまで数分待ちます。
[正常性の履歴] で最上位のイベントを展開し、推奨される手順を確認します。これらの手順では、ロードバランサーの VIP (ルーティング規則) エンドポイントと DIP (正常性プローブ) エンドポイントを確認することが推奨されています。
learn-ts-loadbalancer-rg リソースグループに移動し、[retailapplb] を選択します。
[負荷分散規則]>[retailapprule] を選択します。この規則では、フロントエンド IP アドレスのポート 80 で TCP トラフィックを受信し、バックエンドプール内の選択された仮想マシン上のポート 80 に送信します。正常性プローブによって使用されるポートは疑わしいと思われますが、この構成は正しいようです。現在、これはポート 85 に設定されています。
[retailapprule] ページを閉じます。
[正常性プローブ]>[retailapphealthprobe] を選択します。
[ポート] を 85 から 80 に戻し、[保存] を選択します。
数分待ちます。
Azure portal の左側にあるメニューで、[ダッシュボード] を選択します。
ダッシュボードで、正常性プローブの状態メトリックデータパスの可用性メトリックを示すグラフを選択します。 データパスの可用性メトリックは 100 まで上昇しますが、正常性プローブの状態メトリックは 50 前後に留まります。ロードバランサーから少なくとも 1 つの仮想マシンへのパスが使用できるようになりましたが、仮想マシンの 50% のみが正常と示されています。

このグラフを選択して、Load Balancer のメトリックページに移動します。このページでは、グラフを更新し、特定の期間にズームインすることができます。
Cloud Shell で次のコマンドを実行して、ジャンプボックスを閉じます。
```
exit
```
ロードバランサーの IP アドレスを使用して、ストレステストアプリケーションを再実行します。
```
cd ~/load-balancer/src/stresstest
dotnet run <ip address>
```
以前と同様に、テストは失敗します。現在は、ロードバランサーから少なくとも 1 つの仮想マシンへのパスがありますが、このパスは、仮想ネットワークの外部で実行されているクライアントからは機能しません。 Enter キーを押して、ストレステストアプリを停止します。

サブネットの NSG ルールを確認する

この問題は、外部トラフィックをブロックしているネットワークセキュリティ規則が原因である可能性があります。

Azure portal で、learn-ts-loadbalancer-rg リソースグループに移動します。
retailappnsg ネットワークセキュリティグループを選択します。このセキュリティグループにより、仮想ネットワークを介して許可されるトラフィックが決定されます。
[受信セキュリティ規則] を選択します。仮想ネットワーク内で実行されているロードバランサーからの受信トラフィックを許可する規則はありますが、ポート 80 を介して仮想ネットワークの外部から送信されるトラフィックを許可する規則はありません。
[追加] を選択します。 [受信セキュリティ規則の追加] ウィンドウが表示されます。

次の設定を入力してから、[追加] を選択します。

プロパティ	値
source	[任意]
ソースポート範囲	*
宛先	Any
サービス	Custom
宛先ポート範囲	80
Protocol	TCP
アクション	Allow
優先度	100
名前	Port_80
説明	HTTP ポート

Cloud Shell で、ロードバランサーの IP アドレスを使用して、ストレステストアプリケーションをもう一度実行します。
```
cd ~/load-balancer/src/stresstest
dotnet run <ip address>
```
これでアプリケーションが実行されるようになりましたが、得られるのは retailappvm1 仮想マシンからの応答のみです。アプリケーションが 2 分から 3 分間実行されるようにします。 Enter キーを押してそれを停止します。
Azure portal で、ダッシュボードに移動します。
平均パケット数メトリックのグラフを選択します。ストレステストアプリケーションの最新の実行のピーク時の値に注意してください。この値は、両方の仮想マシンが使用可能だったときに前に記録された値の少なくとも 2 倍である必要があります。現在、機能しているシステムはありますが、動作している仮想マシンが過負荷になる危険性があります。

appretailvm2 仮想マシンをテストする

appretailvm2 仮想マシンで要求が正しく処理されていない可能性があるようです。この仮想マシンが稼働しているかどうかと、Load Balancer を接続できるかどうかを確認する必要があります。

Cloud Shell で、前のコマンド出力の IP アドレスとパスワードを使ってジャンプボックスにサインインします
```
ssh azureuser@<jump box ip address>
```
appretailvm2 仮想マシンに対して、ping を実行してみます。
```
ping retailappvm2 -c 10
```
仮想マシンで応答に失敗し、ping コマンドによって 100% のパケット損失が報告されています。 retailappvm2 仮想マシンが実行されていないか、ネットワークに問題があります。
Azure portal で、learn-ts-loadbalancer-rg リソースグループに移動します。
retailappvm2 仮想マシンを選択します。
[概要] ページには、仮想マシンが停止したことが示されます。 [開始] を選択し、マシンの実行が開始されるまで待ちます。
ジャンプボックスに接続されている Cloud Shell に戻り、ping コマンドを繰り返します。
```
ping retailappvm2 -c 10
```
今度は、ping 操作に成功するはずです。
retailappvm2 仮想マシンで実行されているアプリケーションが応答するかどうかをテストします。
```
wget retailappvm2
```
このコマンドはタイムアウトになります。アプリケーションが実行されていないか、ネットワークに問題がある可能性があります。 Ctrl + C キーを押してコマンドを停止します。
ジャンプボックスで、retailappvm2 仮想マシンにサインインします。メッセージが表示されたら、前に指定したものと同じパスワードを入力します。
```
ssh azureuser@retailappvm2
```
次のコマンドを実行して、この仮想マシンでアプリケーションをテストします。
```
wget retailappvm2
```
コマンドは正常に実行され、応答を含む index.html ファイルが作成されるはずです。
この index.html ファイルを調べます。
```
cat index.html
```
ファイルには、この仮想マシンが予期したとおりに応答したことを示すメッセージの retailappvm2 が含まれているはずです。
retailappvm2 仮想マシンへの接続を閉じます。
```
exit
```
ジャンプボックスへの接続を閉じます。
```
exit
```
retailappvm2 仮想マシンが稼働し、アプリは実行されていますが、仮想マシンの外部からアプリに接続することはできません。この問題はネットワークの問題を示しています。
Azure portal で、learn-ts-loadbalancer-rg リソースグループに移動します。
retailappnicvm2nsg ネットワークセキュリティグループを選択します。
[受信セキュリティ規則] を選択します。

ネットワークセキュリティグループには、TCP プロトコルを使用して外部のすべてのトラフィックをブロックする受信規則があります。この規則の優先順位番号は、ポート 80 を開く規則よりも低いため、優先されます。
retailappvnetnsgrulevm2denyall 規則を選び、優先度を 300 に変更してから、[保存] を選択します。
2 分待ってから、[ダッシュボード] に移動します。
Health Probe Status (正常性プローブ状態) メトリックを示すグラフを選択します。このメトリックの値は 100 に上がるはずです。場合によっては、グラフを数回更新する必要があります。
Cloud Shell に切り替え、ロードバランサーの IP アドレスを使用して、stresstest アプリケーションをもう一度実行します。
```
cd ~/load-balancer/src/stresstest
dotnet run <ip address>
```
これで、retailappvm1 と retailappvm2 からのメッセージが表示されるはずです。システムへの完全な接続を復元しました。
Enter キーを押してアプリケーションを停止します。

まとめ

この演習の冒頭に、仮想マシンがロードバランサーからの正常性プローブ要求に応答していないことを確認しました。プローブとデータパスに関する組み合わされた問題を見つけて解決しました。

ロードバランサー規則の retailapprule では、正常性プローブで使用されるポートが、80 ではなく、85 を使用するように誤って構成されていました。ポート 80 を使用するように規則を更新しました。
ネットワークセキュリティグループの retailappnsg に、ポート 80 でトラフィックを許可する受信セキュリティ規則がありませんでした。そのため、ネットワークセキュリティグループでは正常性プローブがブロックされました。ポート 80 でトラフィックを許可するように受信セキュリティ規則を追加しました。
VM retailappvm2 を調べ、停止したことを確認しました。 VM を再起動しました。
VM retailappvm2 を起動し、アプリが実行されていることを確認した後、アプリに接続できませんでした。ネットワークセキュリティグループには、TCP プロトコルのすべてのネットワークトラフィックをブロックする受信規則がありました。この "すべて拒否" という規則は、ポート 80 へのトラフィックを許可する受信セキュリティ規則よりも優先されました。 "すべて拒否" 規則の優先度を変更し、ポート 80 規則よりも高くなるようにしました。この変更により、TCP に対してポート 80 での受信ネットワークトラフィックが許可されました。

負荷分散された HTTP サービスを完全な操作に戻しました。

続行

演習 - 受信ネットワーク接続を特定して解決する

ロード バランサーを再構成して再テストする