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

完了

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

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

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

  1. Azure Cloud Shell で、リソース グループ名を設定します。

    export RESOURCEGROUP=learn-ts-loadbalancer-rg
    
  2. src/scripts フォルダーにアクセスします。

    cd ~/load-balancer/src/scripts
    
  3. 次のコマンドを実行して、ロード バランサー、ネットワーク、および仮想マシンを再構成します。 このスクリプトによって、後で診断と修正を行ういくつかの問題を導入します。

    bash reconfigure.sh
    
  4. 次のコマンドを実行して、src/stresstest フォルダーに移動します。

    cd ~/load-balancer/src/stresstest
    
  5. <ip address> をロード バランサーの IP アドレスに置き換えて、ストレス テストを再実行します。 このアドレスを覚えていない場合は、src/scripts/findip.sh スクリプトをもう一度実行してください。

    dotnet run <ip address>
    

    この場合、アプリによって出力は生成されず、最終的にタイムアウトして "Error sending request to Load Balancer: The operation was canceled (ロード バランサーへの要求の送信でエラーが発生しました: 操作は取り消されました)" というメッセージが表示されることがあります。Enter キーを押してアプリケーションを停止します。

  6. Azure portal で、[ダッシュボード]>[dashboard-learn-ts-loadbalancer] を選択します。

  7. 正常性プローブの状態とデータ パスの可用性を示すダッシュボードを確認します。 時間の範囲を過去 30 分に変更することが必要になる場合があります。 次のグラフのように、両方のメトリックがゼロまで下降します。

    Screenshot that shows the health probe status and data path availability is in an unhealthy state.

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

問題を診断して修正する

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

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

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

  1. Cloud Shell に戻ります。

  2. ジャンプ ボックス仮想マシンの IP アドレスを取得するには、次のコマンドを実行します。

    bash ~/load-balancer/src/scripts/jumpboxip.sh
    
  3. 次のコマンドを実行して、初期セットアップ スクリプトの実行時に作成したパスワードを取得します。 次の手順で使用するために、このパスワードをコピーします。

    cd ~/load-balancer/src/scripts
    cat passwd.txt
    
  4. 前のコマンド出力の IP アドレスとパスワードを使ってジャンプ ボックスにサインインします。 別のユーザー名を使用した場合は、azureuser を置き換えます。

    ssh azureuser@<jump box ip address>
    
  5. ジャンプ ボックスで次のコマンドを実行して、retailappvm1 仮想マシンが実行されているかどうかをテストします。

    ping retailappvm1 -c 10
    

    retailappvm1 仮想マシンが応答し、実行されていることが示されます。 次の手順では、この仮想マシンで Web アプリが実行されているかどうかを確認します。

  6. 次のコマンドを実行して、HTTP GET 要求を retailappvm1 仮想マシンに送信します。

    curl -v http://retailappvm1
    

    ここでも、このコマンドは正常に実行されます。

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

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

  1. Azure portal で、"モニター" を検索します。

  2. [Monitor - Overview](モニター - 概要) ページで、[Service Health] を選択します。

    Screenshot that shows Service Health option selected from the left-hand side menu.

  3. [リソース正常性] を選択します。

  4. [リソースの種類] ボックスで、[ロード バランサー] を選択します。 リソースの一覧で、[retailapplb] を選択します。

    Screenshot of the Service Health - Resource health page that shows the retailapplb selected.

  5. ロード バランサーの正常性が評価されるまで数分待ちます。

  6. [正常性の履歴] で最上位のイベントを展開し、推奨される手順を確認します。 これらの手順では、ロード バランサーの VIP (ルーティング規則) エンドポイントと DIP (正常性プローブ) エンドポイントを確認することが推奨されています。

    Screenshot of the Resource health page that shows health history including date, number of health events, status, description, and recommended steps.

  7. learn-ts-loadbalancer-rg リソース グループに移動し、[retailapplb] を選択します。

  8. [負荷分散規則]>[retailapprule] を選択します。 この規則では、フロントエンド IP アドレスのポート 80 で TCP トラフィックを受信し、バックエンド プール内の選択された仮想マシン上のポート 80 に送信します。 正常性プローブによって使用されるポートは疑わしいと思われますが、この構成は正しいようです。 現在、これはポート 85 に設定されています。

    Screenshot of the **retailapprule** page that shows the health probe is using port 85.

  9. [retailapprule] ページを閉じます。

  10. [正常性プローブ]>[retailapphealthprobe] を選択します。

  11. [ポート] を 85 から 80 に戻し、[保存] を選択します。

    Screenshot of the **retailapphealthprobe** page that shows the port number updated to 80.

  12. 数分待ちます。

  13. Azure portal の左側にあるメニューで、[ダッシュボード] を選択します。

  14. ダッシュボードで、正常性プローブの状態メトリックデータ パスの可用性メトリックを示すグラフを選択します。 データ パスの可用性メトリックは 100 まで上昇しますが、正常性プローブの状態メトリックは 50 前後に留まります。 ロード バランサーから少なくとも 1 つの仮想マシンへのパスが使用できるようになりましたが、仮想マシンの 50% のみが正常と示されています。

    Screenshot of the Health Probe Status and Data Path Availability chart where the Data Path Availability is at 100 but Health Probe Status hovers around 50.

    このグラフを選択して、Load Balancer のメトリック ページに移動します。 このページでは、グラフを更新し、特定の期間にズームインすることができます。

  15. Cloud Shell で次のコマンドを実行して、ジャンプ ボックスを閉じます。

    exit
    
  16. ロード バランサーの IP アドレスを使用して、ストレス テスト アプリケーションを再実行します。

    cd ~/load-balancer/src/stresstest
    dotnet run <ip address>
    

    以前と同様に、テストは失敗します。 現在は、ロード バランサーから少なくとも 1 つの仮想マシンへのパスがありますが、このパスは、仮想ネットワークの外部で実行されているクライアントからは機能しません。 Enter キーを押して、ストレス テスト アプリを停止します。

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

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

  1. Azure portal で、learn-ts-loadbalancer-rg リソース グループに移動します。

  2. retailappnsg ネットワーク セキュリティ グループを選択します。 このセキュリティ グループにより、仮想ネットワークを介して許可されるトラフィックが決定されます。

  3. [受信セキュリティ規則] を選択します。 仮想ネットワーク内で実行されているロード バランサーからの受信トラフィックを許可する規則はありますが、ポート 80 を介して仮想ネットワークの外部から送信されるトラフィックを許可する規則はありません。

  4. [追加] を選択します。 [受信セキュリティ規則の追加] ウィンドウが表示されます。

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

    プロパティ
    source [任意]
    ソース ポート範囲 *
    宛先 Any
    サービス Custom
    宛先ポート範囲 80
    Protocol TCP
    アクション Allow
    優先度 100
    名前 Port_80
    説明 HTTP ポート
  6. Cloud Shell で、ロード バランサーの IP アドレスを使用して、ストレス テスト アプリケーションをもう一度実行します。

    cd ~/load-balancer/src/stresstest
    dotnet run <ip address>
    

    これでアプリケーションが実行されるようになりましたが、得られるのは retailappvm1 仮想マシンからの応答のみです。 アプリケーションが 2 分から 3 分間実行されるようにします。 Enter キーを押してそれを停止します。

  7. Azure portal で、ダッシュボードに移動します。

  8. 平均パケット数メトリックのグラフを選択します。 ストレス テスト アプリケーションの最新の実行のピーク時の値に注意してください。 この値は、両方の仮想マシンが使用可能だったときに前に記録された値の少なくとも 2 倍である必要があります。 現在、機能しているシステムはありますが、動作している仮想マシンが過負荷になる危険性があります。

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

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

  1. Cloud Shell で、前のコマンド出力の IP アドレスとパスワードを使ってジャンプ ボックスにサインインします

    ssh azureuser@<jump box ip address>
    
  2. appretailvm2 仮想マシンに対して、ping を実行してみます。

    ping retailappvm2 -c 10
    

    仮想マシンで応答に失敗し、ping コマンドによって 100% のパケット損失が報告されています。 retailappvm2 仮想マシンが実行されていないか、ネットワークに問題があります。

  3. Azure portal で、learn-ts-loadbalancer-rg リソース グループに移動します。

  4. retailappvm2 仮想マシンを選択します。

  5. [概要] ページには、仮想マシンが停止したことが示されます。 [開始] を選択し、マシンの実行が開始されるまで待ちます。

    Screenshot that shows the Overview page for the *retailappvm2* virtual machine with the start button highlighted.

  6. ジャンプ ボックスに接続されている Cloud Shell に戻り、ping コマンドを繰り返します。

    ping retailappvm2 -c 10
    

    今度は、ping 操作に成功するはずです。

  7. retailappvm2 仮想マシンで実行されているアプリケーションが応答するかどうかをテストします。

    wget retailappvm2
    

    このコマンドはタイムアウトになります。アプリケーションが実行されていないか、ネットワークに問題がある可能性があります。 Ctrl + C キーを押してコマンドを停止します。

  8. ジャンプ ボックスで、retailappvm2 仮想マシンにサインインします。 メッセージが表示されたら、前に指定したものと同じパスワードを入力します。

    ssh azureuser@retailappvm2
    
  9. 次のコマンドを実行して、この仮想マシンでアプリケーションをテストします。

    wget retailappvm2
    

    コマンドは正常に実行され、応答を含む index.html ファイルが作成されるはずです。

  10. この index.html ファイルを調べます。

    cat index.html
    

    ファイルには、この仮想マシンが予期したとおりに応答したことを示すメッセージの retailappvm2 が含まれているはずです。

  11. retailappvm2 仮想マシンへの接続を閉じます。

    exit
    
  12. ジャンプ ボックスへの接続を閉じます。

    exit
    

    retailappvm2 仮想マシンが稼働し、アプリは実行されていますが、仮想マシンの外部からアプリに接続することはできません。 この問題はネットワークの問題を示しています。

  13. Azure portal で、learn-ts-loadbalancer-rg リソース グループに移動します。

  14. retailappnicvm2nsg ネットワーク セキュリティ グループを選択します。

  15. [受信セキュリティ規則] を選択します。

    ネットワーク セキュリティ グループには、TCP プロトコルを使用して外部のすべてのトラフィックをブロックする受信規則があります。 この規則の優先順位番号は、ポート 80 を開く規則よりも低いため、優先されます。

    Screenshot that shows the inbound security rules for the NSG.

  16. retailappvnetnsgrulevm2denyall 規則を選び、優先度を 300 に変更してから、[保存] を選択します。

    Screenshot showing the edit page for the inbound rule.

  17. 2 分待ってから、[ダッシュボード] に移動します。

  18. Health Probe Status (正常性プローブ状態) メトリックを示すグラフを選択します。 このメトリックの値は 100 に上がるはずです。 場合によっては、グラフを数回更新する必要があります。

    Screenshot showing the Health Probe Status for the load balancer.

  19. Cloud Shell に切り替え、ロード バランサーの IP アドレスを使用して、stresstest アプリケーションをもう一度実行します。

    cd ~/load-balancer/src/stresstest
    dotnet run <ip address>
    

    これで、retailappvm1retailappvm2 からのメッセージが表示されるはずです。 システムへの完全な接続を復元しました。

  20. Enter キーを押してアプリケーションを停止します。

まとめ

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

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

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