問題タブ [azure-load-balancer]

Service Fabric クラスターを Azure にデプロイする際に問題が発生し、IPv4 と IPv6 の両方のトラフィックを処理します。

Service Fabric クラスターと通信する iOS および Android 上のモバイル クライアントを持つアプリケーションを開発しています。通信は、HTTP トラフィックと TCP ソケット通信の両方で構成されます。Apple に App Store でアプリを受け入れてもらうには、IPv6 をサポートする必要があります。

Azure へのデプロイに ARM テンプレートを使用しています。これは、ポータルが仮想マシン スケール セットの IPv6 構成を使用したロード バランサーの構成をサポートしていないように見えるためです (参照: url )。リンク先のページには、プライベート IPv6 アドレスを VM スケール セットにデプロイできないなど、IPv6 サポートに対するその他の制限も記載されています。ただし、このページによると、プライベート IPv6 を VM スケール セットに割り当てる可能性はプレビューで利用できます (ただし、これは 2017 年 7 月 14 日に最終更新されました)。

この質問では、これを可能な限り一般的に保ち、このチュートリアルにあるテンプレートに基づいて ARM テンプレートを作成しようとしました。テンプレートは「template_original.json」と呼ばれ、 ここからダウンロードできます。これは、簡単にするためにセキュリティのないサービス ファブリック クラスターの基本的なテンプレートです。

この投稿の最後に、変更された ARM テンプレート全体をリンクしますが、主な変更部分を最初に強調します。

ロード バランサーに関連付けられているパブリック IPv4 および IPv6 アドレス。これらは、それぞれのバックエンド プールに関連付けられています。

それぞれのパブリック IP アドレス (IPv4 と IPv6 の両方) でのフロントエンド ポートの負荷分散規則。これは合計で 4 つのルールになり、フロント エンド ポートごとに 2 つになります。ここでは、HTTP 用にポート 80 を追加し、ソケット接続用にポート 5607 を追加しました。 IPv6 ポート 80 のバックエンド ポートを 8081 に、IPv6 ポート 8507 を 8517 に更新したことに注意してください。

また、負荷分散ルールごとに 1 つのプローブを追加しましたが、わかりやすくするためにここでは省略しました。

VM スケール セットの apiVerison は、前述のプレビュー ソリューションの推奨に従って "2017-03-30" に設定されています。ネットワーク インターフェイス構成も、推奨事項に従って構成されます。

このテンプレートを使用すると、Azure に正常にデプロイできます。IPv4 を使用したクラスターとの通信は期待どおりに機能しますが、IPv6 トラフィックをまったく通過させることができません。これは、ポート 80 (HTTP) と 5607 (ソケット) の両方で同じです。

Azure portal でロード バランサーのバックエンド プールのリストを表示すると、次の情報メッセージが表示されますが、これに関する情報を見つけることができませんでした。これが何らかの形で何かに影響するかどうかはわかりませんか?

ロード バランサのエラー メッセージ

IPv6 でトラフィックを通過できない理由がわかりません。テンプレートに何か見落としがあるのでしょうか、それとも私の側に何かエラーがあるのでしょうか? 追加情報が必要な場合は、遠慮なくお尋ねください。

ARM テンプレート全体を次に示します。長さと投稿の長さの制限により、私はそれを埋め込んでいませんが、完全な ARM テンプレート (更新済み) への Pastebin リンクを次に示します。

アップデート

IPv6 接続のデバッグに関する情報。ポート 80 の IPv6 トラフィックをバックエンド ポート 8081 に転送するように ARM テンプレートを少し変更してみました。したがって、IPv4 は 80=>80、IPv6 は 80=>8081 です。ARM テンプレートが更新されました (前のセクションのリンクを参照)。

ポート 80 で、ステートレス Web サーバーとして Kestrel を実行しています。ServiceManifest.xml に次のエントリがあります。

Kestrel でどのアドレスをリッスンすればよいか、具体的には少しわかりません。FabricRuntime.GetNodeContext().IPAddressOrFQDN を使用すると、常に IPv4 アドレスが返されます。これが現在の開始方法です。これをデバッグするために、私は現在、すべての IPv6 アドレスを把握しており、そのアドレスを使用するポート 8081 のハードコーディングされたハックを取得しています。Fort ポート 80 は IPAddress.IPv6Any を使用しますが、これは常に FabricRuntime.GetNodeContext().IPAddressOrFQDN によって返される IPv4 アドレスにデフォルト設定されます。

ノードの 1 つの Service Fabric Explorer に表示されるエンドポイントを次に示します。

ソケット リスナーに関しても、IPv6 がバックエンド ポート 8507 ではなく 8517 に転送されるように変更しました。同様に、Kestrel Web サーバーと同様に、ソケット リスナーは、適切なポートを持つそれぞれのアドレスで 2 つのリッスン インスタンスを開きます。

この情報が少しでもお役に立てば幸いです。