NGINX Plus

F5 BIG-IP LTMからNGINX Plusへのロードバランサー構成の移行

※本記事はNGINX,Inc.のブログ記事「Migrating Load Balancer Configuration from F5 BIG-IP LTM to NGINX Plus」を和訳した内容となります。
【URL】
https://docs.nginx.com/nginx/deployment-guides/f5-configuration-migrating-nginx-plus/

NGINX Plusなら、従来のハードウェアベースのアプリケーション デリバリー コントローラー(以下ADCと表記)を柔軟に置き換えられます。NGINX Plusは、ベアメタル、仮想マシン、コンテナ、オンプレミスに、パブリック/プライベート/ハイブリッドクラウドなど、およそどこにでもインストール可能な小さなソフトウェア・パッケージですが、旧来のADCと同レベルのアプリケーション配信、高可用性、そしてセキュリティーを実現します。このガイドでは、F5 BIG-IPローカルトラフィックマネージャ(以下LTMと表記)の設定を、NGINX Plusソフトウェア・アプリケーション配信プラットフォームに移行する方法を説明し、迅速な移行を実現するのに、最も一般的に使われている機能と設定をお伝えします。

 

NGINX PlusとBIG-IP LTMはどちらも、完全なリバースプロキシとロードバランサーとして機能するため、クライアントはアプリケーションとしてロードバランサーを認識し、バックエンドサーバーはクライアントとしてロードバランサーを認識します。これにより、トラフィックの優れた制御ときめ細かな取り扱いが可能になります。このガイドでは、基本的な負荷分散に重点を置いています。レイヤ7ロジックとスクリプトを使用した設定の拡張については、NGINXブログのレイヤ7ロジックの移行(英語)に関する記事を参照してください。コンテンツの切り替えやリクエストのルーティング、書き換え、リダイレクトなどの機能について取り上げています。

 

  • コミュニティ版NGINXとNGINX Plusについて
  • NGINX Plusデプロイメント・シナリオ
  • 前提条件
  • BIG-IP LTMのネットワーク概念をNGINX Plusにマッピングする
  • F5 BIG-IP LTMロードバランサー設定からNGINX Plusへの変換
    • 仮想サーバー
    • SSL / TLSオフロード(ターミネーションおよびプロキシ)
    • セッションの永続性
    • Keepalive接続
    • モニター(ヘルスチェック)
  • 変換されたロードバランサー構成のまとめ

コミュニティ版のNGINXとNGINX Plusについて

コミュニティ版のNGINXは、オープンソースのWebサーバー、リバースプロキシ、およびロードバランサーで、近年そのスケーラビリティにより普及してきています。当初、C10K問題(クライアント1万台問題:単一のWebサーバー上で10,000の同時接続を処理することができない問題)を解決するために作られましたが、その機能と性能で、多くの高性能サイトが頼る解決策となっています。今や、NGINXは世界で最もアクセスされている10万ウェブサイトの大部分で利用されています。(英語)

NGINX Plusは、コミュニティ版NGINXの商用サポート版です。完全なソフトウェア・ロードバランサー兼アプリケーション配信プラットフォームで、大規模なウェブアプリケーションの構築には欠かせない多くのエンタープライズ対応機能があり、コミュニティ版NGINXの能力を拡張しています。

 

 

NGINX Plusデプロイメント・シナリオ

構造的に言えば、NGINX Plusは設置場所と機能の点で、従来のADCとは異なります。一般的なハードウェアベースのADCは、通常ネットワークエッジに配置され、すべてのアプリケーショントラフィックのフロントドア・エントリーポイントとして機能します。ネットワークに入ってくるトラフィックの100%を処理するという大きな負担を想定して、大規模なハードウェアADCがパブリックDMZとプライベートDMZにまたいで置かれることは珍しくありません。またこの環境下で、ADCがすべてのアプリケーション(セキュリティー、可用性、最適化、認証など)トラフィックにかかわる、すべての機能を担っていることもよくありますが、これには非常に大きく強力なハードウェアアプライアンスが必要になります。このモデルの欠点は、ADCが常にネットワークの「フロントドア」に固定されてしまっていることです。

 

インフラストラクチャーの更新や、アプリケーション配信に取り組む時、多くの企業がハードウェアのエッジに置かれたADCの機能を削ぎ落とし、より分散したアプリケーションモデルに移行しています。旧来のハードウェアADCはすでにネットワークエッジに位置しているため、すべての入力トラフィック管理を引き続き処理し、アプリケーショントラフィックを種類ごとに適切なNGINX Plusインスタンスに誘導できます。NGINX Plusは各アプリケーションタイプのトラフィックを処理して、オンプレミスでもオフプレミスでもネットワーク全体に対し、アプリケーション中心のロードバランシングと高可用性を実現します。NGINX Plusはアプリケーションの近くに配置され、各アプリケーションタイプに固有のすべてのトラフィックを管理できます。

NGINX PlusはBIG-IP LTMの後ろで稼働し、アプリケーショントラフィックを処理します

また、ネットワークエッジに固定された、ハードウェアADCアプライアンスを完全にNGINX Plusに置き換え、そこで同レベルのアプリケーション配信を実現した企業もあります。


NGINX Plus
でハードウェアADCを完全に置き換え、ネットワークに入るすべてのトラフィックを処理することができます

前提条件

このガイドは、F5 BIG-IP LTMの概念とCLI設定コマンドを知っていることを前提としています。基本的なNGINXソフトウェアの概念とディレクティブの知識に役立ちます。各ドキュメンテーションへのリンクは以下の通りですが、そのガイドではNGINX Plusについて詳細な説明はしていません。

 

F5 BIG-IP LTMのネットワーク概念をNGINX Plusにマッピングする

ネットワーク・アーキテクチャー

F5 BIG-IP LTMネットワーキングとロードバランサーの設定をNGINX Plusに移行するとき、F5のコンセプトやコマンドを、NGINX Plusの構文に直接変換してみたくなるかもしれません。しかし、大概は不満な結果に陥ります。理由としては、この2製品はどのようにネットワークやアプリケーショントラフィックを捉え、処理するかという点で、いくつかの領域であまり一致していないからです。相違点を理解し、移行を行う際にはその点を覚えておくことが重要です。

 

F5は、ネットワークを2つの部分に分割します。つまり、管理ネットワーク(管理プレーンまたは制御プレーンと呼ばれます)とアプリケーショントラフィック・ネットワークデータプレーンと呼ばれます)です。従来のアーキテクチャーでは、管理ネットワークはトラフィックネットワークから分離され、別の内部ネットワークを介してアクセス可能であり、アプリケーションネットワークは公衆ネットワーク(または別のアプリケーションネットワーク)に接続されます。これには、2種類のトラフィックのそれぞれに別々のネットワーク構成が必要です。

 

BIG-IP LTMアプライアンスはデュアルプロキシ環境であり、データプレーントラフィックも2つの異なるネットワークに分かれていることを意味します。つまり、クライアントリクエストがBIG-IP LTMに入ってくるクライアント側のネットワークと、リクエストがアプリケーションサーバーに送信されるサーバー側のネットワークです。BIG-IP LTMには通常、各ネットワークを処理するために2つのネットワークインターフェースカード(以下NICと表記)が必要です。

 

しかし、BIG-IP LTMのアプライアンスで、データプレーンをシングルスタックプロキシアーキテクチャに結合し、1つのNIC上にクライアントとサーバーのネットワークをまとめることは可能です。これは、トラフィックがBIG-IP LTMデータプレーンに入り、同じ仮想NICを介して出てくるクラウド環境では、非常に典型的なアーキテクチャーです。ネットワーク・アーキテクチャーにかかわらず、ロードバランシングと同じ基本原理が適用され、以下で説明する構成はどちらのアーキテクチャーレイアウトでも機能します。

 

NGINX Plusは、以下の2つの似たアーキテクチャーで機能することができます。ホストデバイスで使用可能な1つのNICに複数のIPサブネット(「/(プレフィックス)」 または「VLAN」で分割)をバインドする方法か、複数のNICをインストールし、それぞれを固有のクライアントおよびサーバーネットワークに使う、または複数のクライアントネットワークと複数のサーバー側のネットワークをインストールする方法です。これは本質的に、BIG-IP LTMアプライアンスがどのように機能するかと同じです。通常、仮想NICにトランク接続またはバインドできる複数のNICが搭載されています。

 

ネットワーキングの概念の定義

基本的なF5 BIG-IP LTMネットワーク構成では、管理およびデータプレーンのIPアドレスを指定するだけで済みますが、BIG-IP LTMアプライアンスを含むより複雑なネットワーク環境を管理するには、いくつかの追加の概念が必要です。これらのコンセプトはすべて

簡単に簡略化が出来、NGINX Plusインスタンスにマッピングできます。BIG-IP LTMの主なネットワーキング概念で、NGINX Plusと関連するものは以下のとおりです。

 

  • Self IPアドレス– 特定のVLAN上の着信クライアント側データプレーントラフィックをlistenするプライマリインターフェース。これは、そのVLANまたはVLANグループに関連付けられた特定のNIC上の特定のIPアドレスまたはサブネットです。

 

NGINX Plusでは、Self IPアドレスがプライマリホストインターフェースに最も直接的にマップしますが、これはNGINX Plusがトラフィックプレーンのアプリケーションデータを管理するために使われるものです。一般的には、NGINX Plusは管理とデータトラフィック制御に基盤となるOSネットワーキングを利用しているため、Self IPアドレスはNGINX Plusデプロイメントで必要な概念ではありません。

 

  • 管理IPアドレス:ポートペア– BIG-IP LTMアプライアンスのIPアドレス:ポートの組み合わせは、GUIに加え、またはリモートSSHアクセスを介して管理するために使用されます。NGINX Plusに相当するのは、LinuxホストのIPアドレスで、通常はプライマリホストインターフェースです。アプリケーショントラフィックからリモートアクセスを分離する必要がある場合は、NGINX Plusが実行されているLinuxホストへの管理アクセスに別々のIPアドレスやNICを使用することは可能ですが、必須ではありません。

 

  • 仮想サーバー– BIG-IP LTMが、負荷分散されたアプリケーションのパブリック送信先IPアドレスとして使用するIPアドレス:ポートの組み合わせ。これは、例えばフロントエンド・アプリケーションのドメイン名と関連付けられている仮想サーバーのIPアドレス部分と、サービスに関連付けられているポート(HTTPアプリケーションの場合はポート80など)です。このアドレスは、クライアントリクエストと、フェールオーバーの際にはプライマリデバイスからセカンダリデバイスへのシフトを処理します。

 

NGINX Plusの仮想サーバーは、serverブロックを使用して設定されます。serverブロック内のlistenディレクティブは、クライアントトラフィックのIPアドレスとポートを指定します。

 

  • プールノードリスト– プールは、それぞれが同じアプリケーションまたはサービスをホストするバックエンドノードの集合であり、相互に入ってくる接続の負荷分散が行われます。プールは仮想サーバーに割り当てられているため、新しいリクエストが仮想サーバーに入ってくると、BIG-IP LTMは使用するバックエンドアプリケーションを認識できます。さらに、BIG-IP LTMはノードリストという用語で、異なるサービスの配列を指しますが、これはすべて同じトラフィックプロトコルを使用し、同じIPアドレスでホストされているが、異なるポート番号でlistenするものです(たとえば、168.10.10:8100,192.168.10.10:8200、および192.168.10.10:8300で3つのHTTPサービスなど)。

NGINX Plusは、BIG-IP LTMプールおよびノー​​ドリストの概念を、upstream構成ブロックに表示することで記述を統一しました。またそこで、バックエンドサーバーのグループにトラフィックを転送する、仮想サーバーのロードバランシングとセッションパーシスタンス(永続性)の方法も定義しています。NGINX Plusはノードリストの概念を必要としません。標準的なupstreamブロック設定は、同一IPアドレス上の複数サービスにとても簡単に対応できるためです。

 

これらのネットワーキングの概念に加えて、BIG-IP LTMからNGINX Plus に移行する際、考慮すべき2つの重要な技術カテゴリがあります。

 

  • iRules– iRulesは、独自のイベント駆動型のコンテンツスイッチング、およびトラフィック操作エンジン(TCLベース)で、BIG-IP LTMがデータプレーントラフィックのあらゆる面を制御するのに使います。iRulesは仮想サーバーに接続されており、URIに基づいたプールの選択、ヘッダーの挿入、JSESSIONIDとの親和性の確立など、あらゆるタイプのコンテンツの切り替えに必要です。iRulesはイベント駆動型で、新しいHTTPリクエストが仮想サーバーに送信されたり、サーバーがクライアントに応答を送信したりといった特定の基準が満たされたときに、新しい接続に対して起動するよう設定されています。

 

NGINX Plusは、コンテンツの切り替えやHTTPセッションの操作をネイティブに処理するため、ほとんどのコンテキストベースのiRulesとヘッダー操作などのHTTPトランザクションを処理するものを明示的に移行する必要はありません。ほとんどのコンテキストベースのiRulesは、serverおよびlocationブロックに変換することができ、NGINX Plusディレクティブおよびコンフィグレーションブロックで複製できない、より複雑なiRulesは、LuaまたはJavaScriptモジュールで実装できます。iRulesをNGINX Plusのコンテンツルールに変換する方法についての詳細は、NGINXブログのF5 iRulesおよびCitrixポリシーからNGINXおよびNGINX Plusへのレイヤ7ロジックの移行(英語)を参照してください。

 

  • 高可用性(ハイアベイラビリティ)– 概念的には、BIG-IP LTMとNGINX Plusは同じようにハイアベイラビリティ(以下HAと表記)を実現します。Active-Passiveロードバランサーの各組み合わせは、現在アクティブなインスタンスにマップされるフローティング “仮想” IPアドレス(以下VIPと表記)を共有します。アクティブなインスタンスに障害が発生すると、パッシブなインスタンスが肩代わりし、VIPを引き継ぎます。

 

BIG-IP LTMは、組み込まれたHAの仕組みを使い、フェールオーバーを行います。

 

オンプレミス構成では、NGINX Plusは別のソフトウェア・パッケージであるnginx-HA-keepalivedを使って、 VIPとNGINX Plusサーバーのアクティブ-パッシブのペアのフェールオーバープロセスを処理します。このパッケージはVIPを処理するVRRPプロトコルを実装しています。nginx-ha-keepalivedパッケージでは、限られたActive-Activeシナリオも可能です。

 

以下のように、クラウド環境でのNGINX Plusの高可用性ソリューションもあります。

 

(英語)

 

F5 BIG-IP LTMロードバランサー構成からNGINX Plusへの変換

 

 

F5 BIG-IP LTMには3つの設定方法があります。

  • GUI
  • CLI(カスタムのオンボックス トラフィック管理シェル[TMSH]ツール)
  • iControl API

 

最終的に、GUIまたはAPIを介して行うすべての変更はTMSH CLIコマンドに変換されるため、このガイドではTMSH CLIコマンドを使用します。また、(tmos.ltm)ロケーションからデバイスを設定していると仮定して、すべてのTMSHコマンドから、汎用コマンド変数であるltmを省略しています。

 

NGINX Plusを使用すると、設定は簡単なテキストファイルに保存されます。このファイルには、従来のオンボックスツールや設定管理、AnsibleChefPuppetなどのオーケストレーションツールを使って、直接アクセスまたは管理できます。

 

このガイドの例では、仮想サーバーを識別するのにIPアドレスだけを使っていますが、リクエストを処理する適切なserverブロックを選択する際、NGINX Plusは、listenするIPアドレスとポートの組み合わせに加え、Hostヘッダーを使用することもできます。ブロックにserver_nameディレクティブを含めて、Hostヘッダー内で一致する値を指定します。

 

server_nameディレクティブへのパラメーターのリストには、複数のホスト名、ワイルドカード、および正規表現を含めることができます。NGINX Plus の1つのserverブロックに、複数のserver_nameディレクティブと複数のリスニングIPアドレスとポートの組み合わせを含めることが可能です。IPアドレスの代わりにHost、およびserver_nameディレクティブを使う方法については、nginx.orgのサーバー名の項目をご覧ください。

 

注:このガイドのすべてのIPアドレスとオブジェクト名(upstreamブロック、仮想サーバー、プールなど)は単なる例ですので、代わりに、BIG-IP LTM設定の値を入力してください。

 

仮想サーバー

上記のように、仮想サーバーはBIG-IP LTMとNGINX Plus のプライマリーリスナーですが、それらを定義するための構成構文は全く異なります。ここでは、192.168.10.10の仮想サーバーがポート80でHTTPトラフィックをlistenし、test_pool上流グループにリストされている2つのバックエンドアプリケーションサーバー間で着信トラフィックを配信します。

 

BIG-IP LTM

#create pool test_pool members add {10.10.10.10:80 10.10.10.20:80}

#create virtual test_virtual { destination 192.168.10.10:80 pool test_pool source-address-translation { type automap } ip-protocol tcp profiles add { http } }

#save sys config

 

NGINX Plus

http {

upstream test_pool {

server 10.10.10.10:80;

server 10.10.10.20:80;

}

 

server {

listen 192.168.10.10:80;

location / {

proxy_pass http://test_pool;

}

#…

}

}

 

ディレクティブのドキュメント(英語):listenlocationproxy_passserver(仮想)server(アップストリーム)upstream

 

SSL / TLSオフロード(ターミネーションおよびプロキシ)

 

SSL/ TLSターミネーションの処理は、ADCロードバランサーの一般的な使用例です。F5 BIG-IP LTMは独自のSSL / TLS実装をしています。NGINX Plusはシステムライブラリに依存しているため、OpenSSLのバージョンはOSによって規定されています。BIG-IP LTMでは、各SSL / TLSキーと証明書の組合せでのプロファイルを仮想サーバーに対して発行(クライアント着信/発信のトラフィックを暗号化するためのクライアントプロファイルか 、バックエンドのトラフィックを暗号化するためのサーバープロファイルのいずれか、または両方)されています。NGINX Plusでは、ssl_certificateおよび、 ssl_certificate_keyディレクティブは仮想サーバーのserverブロックに含まれています。

 

ロードバランサーインスタンス上でSSL / TLSトラフィック処理を行ったり、ターミネーションやプロキシするには、以下の2つの方法があります。

 

  • SSL / TLSターミネーションを用いたロードバランサーとクライアントでは暗号化されたHTTPSセッションで通信します。銀行のオンライン取引サイトのような、セキュアなアプリケーションがSSL / TLS証明書でクライアントの暗号化を行うのと同じ方法です。ロードバランサーは、クライアントメッセージを復号化した後(安全な接続を実質的に終了する)、平文(暗号化されていない)のHTTP接続を介してメッセージをバックエンドサーバーに転送します。逆方向では、ロードバランサーはクライアントに送信する前にサーバー応答を暗号化します。SSL / TLSターミネーションは、ロードバランサーとバックエンドサーバーがセキュリティー保護されたネットワーク上にある場合、すなわち外部のエージェントが平文のバックエンドトラフィックを傍受して読み取る危険性がなく、またアップストリームアプリケーションのパフォーマンスが最優先の場合には良い選択肢です。
  • SSL / TLSプロキシアーキテクチャーでは、ロードバランサーはターミネーションモデルと同じように、クライアント側トラフィックを復号化します。ただその後、バックエンドサーバーに転送する前に再暗号化します。これは、サーバー側のネットワークが安全でない場合、またはバックエンドサーバーがSSL / TLSの暗号化・復号化に伴うコンピューティング負荷を処理できる場合には適しています。

 

BIG-IP LTM

  • SSL / TLSのターミネーションとプロキシ:SSL / TLS仮想サーバーとプールメンバーの作成

# create pool ssl_test_pool members add { 10.10.10.10:443 10.10.10.20:443 }

# create virtual test_ssl_virtual { destination 192.168.10.10:443 pool ssl_test_pool source-address-translation { type automap } ip-protocol tcp profiles add { http } }

# save /sys config

 

  • SSL / TLSターミネーション:クライアントSSL / TLSプロファイルの作成

 

  • # create profile client-ssl test_ssl_client_profile cert test.crt key test.key
  • # modify virtual test_ssl_virtual profiles add { test_ssl_client_profile }
  • # save /sys config

 

  • SSL / TLSプロキシ:サーバーSSL / TLSプロファイルの作成

 

# create profile server-ssl test_ssl_server_profile cert test.crt key test.key

# modify virtual test_ssl_virtual profiles add { test_ssl_server_profile }

# save /sys config

 

NGINX Plus

  • SSL / TLSターミネーション

upstream ssl_test_pool {

server 10.10.10.10:443;

server 10.10.10.20:443;

}

 

server {

listen 192.168.10.10:443 ssl;

ssl_certificate     /etc/nginx/ssl/test.crt;

ssl_certificate_key /etc/nginx/ssl/test.key;

 

location / {

proxy_pass http://ssl_test_pool;

}

}

 

  • SSL / TLSプロキシ

upstream ssl_test_pool {

server 10.10.10.10:443;

}

 

server {

listen 192.168.10.10:443 ssl;

ssl_certificate     /etc/nginx/ssl/test.crt;

ssl_certificate_key /etc/nginx/ssl/test.key;

 

location / {

proxy_pass https://ssl_test_pool;

proxy_ssl_certificate /etc/nginx/ssl/client.pem;

proxy_ssl_certificate_key /etc/nginx/ssl/client.key;

proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

proxy_ssl_ciphers HIGH:!aNULL:!MD5;

proxy_ssl_trusted_certificate /etc/nginx/ssl/trusted_ca_cert.crt;

proxy_ssl_verify on;

proxy_ssl_verify_depth 2;

}

}

 

ディレクティブのドキュメント(英語):listenlocationproxy_passproxy_ssl*server(仮想)server(アップストリーム)ssl_certificateおよびssl_certificate_keyupstream

 

セッション・パーシステンス(永続性)

F5 BIG-IP LTMとNGINX Plus は、アップストリームサーバー(BIG-IP LTMプールまたはNGINX Plus upstreamブロック)で、いずれもセッション永続性(親和性とも呼ばれます)を似たような方法で処理し、同等レベルの設定ができます。どちらも複数の形態のパーシステンスをサポートします。セッション・パーシステンスは、セッション状態を保持するアプリケーションには重要で、継続的デリバリーの用途に役立ちます 。

Cookieベースのセッション・パーシステンス

アプリケーションと互換性がある場合、NGINX Plusのフェールオーバーを簡単に設定して処理する方法の1つに、スティッキークッキーがあります。これはBIG-IP LTMのCookie Insertメソッドと同じように機能します。つまり、ロードバランサーはサーバーを表すクッキーを作成し、クライアントは各リクエストにクッキーを含め、ロードバランサー自体からセッショントラッキングを効果的に負荷軽減します 。

 

  • BIG-IP LTM:HTTP クッキー・パーシステンス

# create persistence cookie test_bigip_cookie cookie-name BIGIP_COOKIE_PERSIST expiration 1:0:0

# modify virtual test_virtual { persist replace-all-with { test_bigip_cookie } }

# save /sys config

 

  • BIG-IP LTM:HTTPSクッキー・パーシステンス

# create persistence cookie test_bigip_cookie cookie-name BIGIP_COOKIE_PERSIST expiration 1:0:0

# modify virtual test_ssl_virtual { persist replace-all-with { test_bigip_cookie } }

# save /sys config

 

 

  • NGINX Plus:HTTP クッキー・パーシステンス

upstream test_pool {

server 10.10.10.10:80;

server 10.10.10.20:80;

sticky cookie mysession expires=1h;

}

 

  • NGINX Plus:HTTPS クッキー・パーシステンス

upstream ssl_test_pool {

server 10.10.10.10:443;

server 10.10.10.20:443;

sticky cookie mysession expires=1h;

}

 

ディレクティブのドキュメント(英語):serversticky cookieupstream

送信元IPアドレスベースのセッション・パーシステンス

セッション・パーシステンスの別の形態は、リクエストパケットに記録されている送信元IPアドレス(リクエストしているクライアントのIPアドレス)に基づいています。ロードバランサーはリクエストごとにIPアドレスでハッシュを計算し、そのハッシュに関連付けられているバックエンドサーバーにリクエストを送信します。特定のIPアドレスのハッシュは常に同じなので、同じハッシュのリクエストはすべて同じサーバーに送られます。(NGINX Plusの実装の詳細については、ブログでNGINX Plusの負荷分散手法選択する(英語)を参照してください)。

 

  • BIG-IP LTM

#modify virtual test_virtual {persist replace-all-with {source_addr}}

#save / sys設定

  • NGINX Plus

upstream test_pool {

ip_hash;

server 10.10.10.10:80;

server 10.10.10.20:80;

}

ディレクティブのドキュメント(英語):ip_hashserverupstream

 

トークンベースのセッション・パーシステンス

セッション・パーシステンスのもう1つの方法は、バックエンドサーバーがセッション内で生成するCookieやjsessionidといった他のトークンを利用します。Jsessionidの作成や追跡を管理するために、NGINX Plusは特定のバックエンドサーバーとCookie値を照合してメモリー内にテーブルを作成します。

 

  • BIG-IP LTM

BIG-IP LTMは、高度なiRuleを作成しない限り、学習した(またはユニバーサルな)パーシステンスプロファイルをネイティブでサポートしていませんので、本ドキュメントでは対象としません。

 

  • NGINX Plus

upstream test_pool {

server 10.10.10.10:80;

server 10.10.10.20:80;

sticky learn create=$upstream_cookie_jsessionid

lookup=$cookie_jsessionid

zone=client_sessions:1m;

}

ディレクティブのドキュメント(英語):serversticky learnupstream

 

keepalive接続

通常、別のHTTPセッションが作成され、接続ごとに破棄されます。Webサーバーから少量のコンテンツを要求するなど、短時間の接続では問題無いかもしれませんが、長時間の接続ではとても非効率になりえます。セッションや接続を絶え間なく作成・破棄していると、アプリケーションサーバーとクライアントの両方に負荷が掛かってページの読み込みが遅くなり、Webサイトやアプリケーションのパフォーマンスに対する全体的な印象が損なわれる可能性があります。ロードバランサーに対し、セッション用の接続を開いたままにするよう指示するHTTP keepalive接続は、Webページをより高速にロードするためには必要なパフォーマンス機能です。

 

BIG-IP LTM

# modify virtual test_virtual profiles add { oneconnect }

# modify virtual test_ssl_virtual profiles add { oneconnect }

# save /sys config

 

NGINX Plus

upstream test_pool {

server 10.10.10.10:80;

server 10.10.10.20:80;

keepalive 32;

}

ディレクティブのドキュメント(英語):keepaliveserverupstream

モニター(ヘルスチェック)

F5 BIG-IP LTMはモニターという用語で、サーバーが正常に機能していることを確認するプロセスを指しますが、NGINX Plusではヘルスチェックという用語を使います。BIG-IP LTM構成では、モニターはプールに直接関連付けられ、プール内の各ノードに割り当てられますが、NGINX Plusではlocationブロックにヘルスチェックを配置します。

 

以下のBIG-IP LTM createコマンドに対するInterval引数は、5秒ごとにサーバーをチェックするようにBIG-IP LTMを設定します。これはNGINX Plusの初期設定でのチェック頻度に相当します。NGINX Plusは、intervalおよびfailsパラメーターを使用してタイムアウト機能を実装するため、BIG-IP LTM timeoutパラメーターは必要ありません。

注:このBIG-IP LTM設定はHTTP用です。HTTPSの場合は、createとmodifyコマンドの両方でtest_ssl_monitorをtest_monitorに置き換えてください。同じNGINX Plus設定は、HTTPとHTTPSの両方で機能します。

 

BIG-IP LTM

# create monitor http test_monitor defaults-from http send “GET /index.html HTTP/1.0\r\n\r\n” interval 5 timeout 20

# modify pool test_pool monitor test_monitor

# save /sys config

NGINX Plus

upstream test_pool {

# …

zone test_pool_zone 64k;

}

 

server {

# …

location / {

proxy_pass http://test_pool;

health_check interval=5 fails=2;

}

}

ディレクティブのドキュメント(英語):health_checklocationproxy_passserverupstreamzone

 

変換されたロードバランサー構成のまとめ

ここでは、構成要素をまとめて基本的なF5 BIG-IP LTM環境を構築するために必要な構成と

NGINX Plusに移行するための同じ設定方法の詳細を記載します。

 

BIG-IP LTM

# create pool test_pool members add { 10.10.10.10:80 10.10.10.20:80 }

# create virtual test_virtual { destination 192.168.10.10:80 pool test_pool source-address-translation { type automap } ip-protocol tcp profiles add { http } }

# create pool ssl_test_pool members add { 10.10.10.10:443 10.10.10.20:443 }

# create virtual test_ssl_virtual { destination 192.168.10.10:443 pool ssl_test_pool source-address-translation { type automap } ip-protocol tcp profiles add { http } }

# create profile client-ssl test_ssl_client_profile cert test.crt key test.key

# modify virtual test_ssl_virtual profiles add { test_ssl_client_profile }

# create profile server-ssl test_ssl_server_profile cert test.crt key test.key

# modify virtual test_ssl_virtual profiles add { test_ssl_server_profile }

# create persistence cookie test_bigip_cookie cookie-name BIGIP_COOKIE_PERSIST expiration 1:0:0

# modify virtual test_virtual { persist replace-all-with { test_bigip_cookie } }

# modify virtual test_ssl_virtual { persist replace-all-with { test_bigip_cookie } }

# modify virtual test_virtual profiles add { oneconnect }

# modify virtual test_ssl_virtual profiles add { oneconnect }

# create monitor http test_monitor defaults-from http send “GET /index.html HTTP/1.0\r\n\r\n” interval 5 timeout 20

# modify pool test_pool monitor test_monitor

# create monitor https test_ssl_monitor defaults-from https send “GET /index.html HTTP/1.0\r\n\r\n” interval 5 timeout 20

# modify pool ssl_test_pool monitor test_ssl_monitor

# save /sys config

 

 

NGINX Plus

以下の構成には、これまで説明していなかった3つの追加ディレクティブが含まれています。トラフィックを

プロキシするときは、これらを追加することがベストプラクティスです。

 

  • proxy_set_headerHost $hostディレクティブは、クライアントから受信したHostヘッダーがリクエストとともにバックエンドサーバーに送信されるようにします。
  • proxy_http_versionディレクティブは、バックエンドサーバーへの接続用にHTTPバージョンを1に設定します。
  • proxy_set_header Connection “”ディレクティブは、NGINX Plusがアップストリームサーバーへの暗号化されたkeepalive接続を維持できるように、Connectionヘッダーをクリアします。

 

また、最後のserverブロックでライブアクティビティのモニタリングも可能にしています。ライブアクティビティのモニタリングは、NGINX Plus APIモジュールで実装される、NGINX Plus限定の機能です。APIがレポートする幅広い統計情報は、組み込みダッシュボードに表示され、JSON形式のメッセージを理解するすべてのアプリケーションパフォーマンス管理(APM)または監視ツールにエクスポートすることができます。ロギングとモニタリングの詳細については、「NGINX Plus管理者ガイド」(英語)を参照してください。

 

upstream test_pool {

zone test_pool_zone 64k;

server 10.10.10.10:80;

server 10.10.10.20:80;

sticky cookie mysession expires=1h;

keepalive 32;

}

 

upstream ssl_test_pool {

zone ssl_test_pool_zone 64k;

server 10.10.10.10:443;

server 10.10.10.20:443;

sticky cookie mysession expires=1h;

keepalive 32;

}

 

server {

listen 192.168.10.10:80 default_server;

proxy_set_header Host $host;

 

location / {

proxy_pass http://test_pool;

health_check;

proxy_http_version 1.1;

}

 

location ~ /favicon.ico {

root /usr/share/nginx/images;

}

}

 

server {

listen 192.168.10.10:443 ssl default_server;

ssl_certificate     test.crt;

ssl_certificate_key test.key;

proxy_set_header    Host $host;

 

location / {

proxy_pass https://ssl_test_pool;

proxy_http_version 1.1;

proxy_set_header Connection “”;

health_check;

}

 

location ~ /favicon.ico {

root /usr/share/nginx/images;

}

}

 

server {

listen 8080;

status_zone status-page;

root /usr/share/nginx/html;

 

location /api {

api write=on;

# directives controlling access, such as ‘allow’ and ‘deny’

}

 

location = /dashboard.html {

root /usr/share/nginx/html;

}

 

# Redirect requests made to the old (pre-R14) dashboard

location = /status.html {

return 301 /dashboard.html;

}

 

location ~ /favicon.ico {

root /usr/share/nginx/images;

}

}

改訂履歴

  • バージョン2(2018年4月) – 高可用性とNGINX Plus APIに関する情報(NGINX Plus R13、NGINX Open Source 1.13.4)
  • バージョン1(2017年2月) – イニシャル・バージョン(NGINX Plus R11、NGINXオープンソース11.5)

ホワイトペーパー「ロードバランシングをソフトウェアに切り替える 5つの理由」

現代のITインフラ担当者は、ベアメタル、クラウド、コンテナなど様々な環境が混在する中、急激なトラフィックの増加やアプリケーションの迅速な展開といったWebサービスの課題に頭を悩ませています。Webの先進的な企業では、ハードウェアベースのアプリケーション デリバリー コントローラー(ADC)から、ソフトウェアベースのWebサーバーやロードバランサー、キャッシュサーバーに移行することでこの課題を解決しています。


現代のITシステムが求める高い柔軟性やスピード、コストパフォーマンスを満たすには、ソフトウェアが圧倒的に優位です。 このebookでは、IT責任者、ネットワーク担当者、アプリケーション開発者が、ハードウェアADCからソフトウェアソリューションに移行することで得られるメリットと優位性、ビジネスへの影響について、以下の5つの観点から解説します。


■目次■

1. 機能や性能を損なうことなくコストを劇的に削減します 

2. DevOpsへの移行にはソフトウェアベースのアプリケーションデリバリーが必要です

3. 1つのADCソリューションで、ベアメタル、クラウド、コンテナなど、どこにでも展開します 

4. アプリケーションへのニーズの変化に素早く対応します 

5. 性能に対して、意図的に制限を課したり、契約で制限を設けたりすることはありません


ダウンロード

コメントを残す

*