Azure Load Balancerの挙動の確認 – Azure Application Gatewayと比較して –

こんにちは。技術部の髙岡です。
以前、L7ロードバランサーのAzure Application Gatewayに関するブログを書きましたが、L4ロードバランサーのAzure Load Balancerを検証する機会がありました。
Azure Application Gatewayとの違いを意識して、Azure Load Balancerの挙動を検証してわかったことを説明します。

両者の比較

比較項目 Azure
Load Balancer
Azure
Application Gateway
NAT DNATのみ SNATとDNAT
負荷分散、
セッションアフィニティ
の元ネタ
既定では5種類のハッシュ
・ソース IP
・接続元ポート
・接続先 IP
・接続先ポート
・プロトコル
cookie
SSLオフロード 不可能
※L4なので
可能
ポータルGUIでの初期構築 可能 可能
仮想マシンの可用性セット 必要 不要
課金 無償版と有償版あり 有償版のみ

NATについての補足
Azure Load BalancerはDNATのみでSNATしないので、負荷分散対象の仮想マシンには、ソースIPがクライアントIPのままで接続します。したがって、Azureのセキュリティグループでインターネット側からHTTPやHTTPSの接続許可が必要です。
一方、Azure Application GatewayはSNATするので、インターネット側からの接続許可は不要です。

Azure Load Balancerが向いてるケース

  • 無償がいい。
  • セッションアフィニティはバックエンドシステム側で行うため、ロードバランサー側では不要である。

Azure Application Gatewayが向いているケース

  • クライアントのソースIPが単一IPにNATされるので、複数クライアントからの接続でもソースIPがバックエンドのサーバからは単一のクライアントと見えてしまい、ソースIPでクライアントを識別することができない。したがって、負荷分散やセッションアフィニティは、ソースIPでなくcookieベースとする必要がある。
  • SSLオフロードが必要である。

検証環境の構成と構築

検証環境の構成図です。

検証環境の構成図

  • Azure Load BalancerはSSLオフロードしないので、Azure Application Gatewayと異なり、ロードバランサーでの証明書の設定が不要です。
  • Azure Load Balancerはコマンドでも構築できますが、AzureポータルからGUIで作成することも可能です。Azure Application Gatewayの場合は作成コマンドが完了するまで20分程かかりましたが、Azure Load Balancerの場合は、GUIで作成ボタンを押してから作成完了するまで1分もかかりませんでした。

その他の細かい構築手順の説明は割愛します。マイクロソフトが公開している手順が参考になります。

Azure Load Balancerを構築する前に実施しておくべき作業を書いておきます。

  • バックエンドのWebサーバにhttps接続環境作成
  • 今回はApacheを導入しました。

  • Webサーバ用の秘密鍵とサーバ証明書作成
  • 今回はApacheを使うので、pem形式で作成しました。

構築に関する補足事項を書いておきます。

  • DNSサーバにロードバランサーのCNAMEを登録する必要がある。
  • Azure Load Balancerのフロントエンド側には、Public IPが割り当てられています。
    FQDNのホスト名は指定できるものの、FQDNのドメイン部分は修正することができません。IPアドレスもデフォルトでは可変です。

    検証環境での例

    IPアドレス:40.74.70.107
    FQDN:lb-takaoka-pub.japanwest.cloudapp.azure.com

    このFQDNは、ユーザに提供するURLとしては不適切なので、実運用を考慮すると、適切な名称を決めてDNSにCNAMEレコードを登録する必要があります。
    今回の検証では、ユーザ向けのURLとして、

    https://websvlb.siostest02.com/index.html

    を使うことにしましたので、「lb-takaoka-pub.japanwest.cloudapp.azure.com」のCNAMEとして、「websvlb.siostest02.com」をDNSに登録しました

    尚、Public IPを固定IPとして設定することもできます。
    その場合は、DNSにCNAMEでなく、固定IPとFQDNをセットにしたAレコードを登録することによって、ユーザ向けのURLを構成することが可能です。

  • バックエンドの仮想マシンは可用性セットが必要
    バックエンドの仮想マシンは可用性セットで構成されている必要があります。
    尚、Azure Application Gatewayの場合は、可用性セットは不要です。

ロードバランサーの本質的な機能の確認

ロードバランサーの本質的な機能であるNATを、Azure Application Gatewayの検証時と同様にパケットキャプチャで確認してみました。

NATの確認
このようなフローでパケットが流れていくと想定しています。

パケットフロー図2

戻りの経路(赤線)に着目してください。
Azure Application GatewayのようにSNATしないので、戻り時にはロードバランサーを経由しません。

クライアントとWebサーバ側でパケットキャプチャを取得してNATされているかを確認します。

クライアントからcurlコマンド実行
# curl --verbose https://websvlb.siostest02.com/index.html --cacert ./websvapgw.crt
クライアントからCURLコマンド実行

websvlb01側に配置したhtmlコンテンツが表示されましたので、websvlb01側に振られたことがわかります。

クライアント側のパケットキャプチャ
クライアント側のパケットキャプチャ

Sourceが「192.168.10.154:40174(クライアント)」Destinationが「40.74.70.107:443(Load Balancerのフロントエンド側)」でパケットを送信し、戻りは逆であることがわかります。

websvlb01側のパケットキャプチャ
# tcpdump -nn port not 22 and not udp and port 443 and not host 168.63.129.16

websvlb01側のパケットキャプチャ
Sourceが「126.235.235.217:46095」Destinationが「10.10.0.6:443(websvlb01)」で、ロードバランサーがDNATしたパケットをwebsvlb01が受信しており、戻りは逆であることがわかります。
※本当はSourceが「192.168.10.154:40174」である方が、NATがDNATのみでSNATされていないことがわかりやすいのですが、検証環境でクライアントがインターネットに出る前にSNATされてしまう環境なので、このIPでキャプチャされてしまいました。

もし、SNATされていれば、Sourceはロードバランサー側のバックエンド側のIPに変換されていた筈ですが、ロードバランサーがSNATしていないことがわかります。

蛇足ですが、上記のtcpdumpコマンドで「168.63.129.16」というIPを除外している理由を補足します。
このIPは、ロードバランサー側のプローブが使用しているIPで、Azureが各種の目的で使用する共通のIPのようです。
パケットキャプチャを見るのに邪魔なので、除外しました。

IP アドレス 168.63.129.16 について
https://blogs.technet.microsoft.com/jpaztech/2016/04/01/about-168-63-129-16/

ご覧いただきありがとうございます! この投稿は役に立ちましたか? 役に立った 役に立たなかった

Be the first to comment

コメント投稿

Your email address will not be published.


*