NginxロードバランサーからZEVENET ADCへの移行

投稿日: 22 年 2022 月 XNUMX 日

概要

アプリケーションの複数のインスタンス間での負荷分散は、過負荷と待機時間を減らし、静的リソースをキャッシュすることで配信を増やすことでパフォーマンスを向上させる優れた方法です。

Nginx は Web サービスで大きな目的を果たしますが、プラットフォームには多くの複雑さがあります。 トラフィックが増加するにつれて、セキュリティを犠牲にすることなくレイヤー 4 とレイヤー 7 のトラフィックの負荷を分散することが難しくなります。 このため、アクセスしやすい UI を通じてビジネス アプリケーションを制御できる、より高度な機能を備えたロード バランサーが必要です。

この記事では、Nginxロードバランサー構成をZEVENET ADCに転送する方法について説明します.

必須条件

このガイドに従うには、次のベンチマークを満たしていることを確認してください。

  1. ZEVENET アプライアンスのインスタンスは、ワークステーションまたはクラウド プラットフォームにインストールする必要があります。 評価をリクエストする インスタンスがまだインストールされていない場合。
  2. Web パネルにアクセスできる必要があります。 そうでない場合は、このクイックに従ってください インストールガイド.
  3. Nginx はあなたにとって簡単なものですが、その負荷分散機能には満足していません。 したがって、介入するにはZEVENETが必要です。
  4. 仮想サーバーは、トラフィックをバックエンド サーバーに分散するために不可欠です。 まだ作成していない場合は、このガイドに従ってください レイヤー 4 およびレイヤー 7 仮想サーバー (ファーム) の作成

基本概念

上流の： アップストリーム ディレクティブは、Web アプリケーションをホストするサーバーのクラスターを定義します。 通常、upstream は http コンテキスト内で定義されます。 ZEVENET ADCでは、 サービス セクションには、ホスト サーバーを管理するためのバックエンド サブセクションが含まれます。

聞く： listen オプションは、Nginx が Web からの受信トラフィックをリッスンするポートを定義します。 ZEVENETは 仮想ポート を介して着信トラフィックをリッスンする 牧場.

場所： location コンテキストを使用すると、HTML ファイルからデータを取得するためのディレクトリに関する指示を与えることができます。

プロキシパス: このディレクティブは、プロキシされたサーバーの場所を指定するときに使用されます。 通常、場所は 値 アップストリーム ディレクティブに割り当てられます。 ZEVENETの同様の概念は 牧場. ここで、バックエンド サーバーを含むサービスに接続する IP アドレスとポートを定義します。

サーバ： このディレクティブは、ipv4 または ipv6 形式の IP アドレスを使用して、アプリケーションをホストするサーバーを指定します。 サーバーブロックは、あなたが定義する場所です 場所 指令、 リスナー、 そしてその include 指令。 ZEVENETでサーバーを定義できます バックエンド のセクションから無料でダウンロードできます。

ssl_ciphers および ssl_protocols: ssl_ciphers および ssl_protocol ディレクティブは、接続を最も強力なまたは最新の SSL/TLS バージョンに制限するときに使用されます。 これらのプロトコルの一部には、TLSV1 と TLSV2 が含まれます。 nginx のデフォルトの暗号は HIGH:!aNULL:!MD5. 暗号を使用し、ZEVENET で SSL プロトコルをカスタマイズするには、HTTPS リスナーを使用する必要があります。 アクセス HTTPSパラメータ そのファームのグローバル設定内。

構成例: スティッキー セッションの有効化

セッション持続性 (スティッキー セッションとも呼ばれます) は、クライアントからの要求がセッション中にクラスター内の同じサーバーに送信されるようにするために、負荷分散で使用される手法です。 これは、状態を維持したり、ファイルやデータなどのリソースをセッション全体でクライアントが利用できるようにするためによく使用されます。 セッション永続性を実装するには、Cookie や IP アドレス アフィニティの使用など、いくつかの方法があります。 使用される方法は、アプリケーションの特定の要件と負荷分散アーキテクチャによって異なります。

Nginx の構成

Nginx には主に、セッションの永続性を有効にする XNUMX つの方法があります。つまり、 ハッシュIP 負荷分散方法との使用 スティッキークッキー.

ハッシュ_ip: hash_ip ロード バランシング メソッドは、宛先 IP アドレスと送信元 IP アドレスを取得し、それらを使用して、確立された接続の一意の ID を形成します。

upstream backendServers {
	hash_ip;
	server 192.168.0.112;
	server 192.168.0.115;
}

粘着クッキー: を定義することでスティッキー Cookie を使用することもできます。 スティッキークッキー アップストリーム コンテキスト内のオプション。

upstream backendServers {
	server 192.168.0.112;
	server 192.168.0.116;
	sticky cookie zensessionid expires=2h domain=.example.com path="/";
}

ゼンセッションID Cookie とそれに関連付けられたサーバーを一意に識別します。 上記の構成から、Cookie 有効期限が切れます 2時です。

ZEVENET構成

ZEVENET ロード バランサの使用時に Cookie の永続性を有効にするには:

  1. 　 LSLB>農場 をクリックして、 編集 http ファームのアイコン。
  2. に移動します サービス タブ。
  3. に到達するまでスクロールします。 持続性 のセクションから無料でダウンロードできます。
  4. クライアントの IP アドレスを使用して持続性を有効にするには、持続性を選択します IP: クライアント 住所。

    5. oracle_jd_edwards_load_balancing_farm

  5. Cookie を使用してセッションの永続性を有効にするには、手順 4 を無視してそのままにしておきます。 固執 フィールド 持続性なし.
  6. をオンにする クッキーインサート ボタンをクリックして、 名, ドメイン, path、および生存時間(TTL） すぐに。
  7. をクリックして設定を更新します。 お申し込み ボタン。

構成例: リダイレクト ルールの作成

リダイレクト ルールは、Web ページを別の Web ページに自動的にリダイレクトするために使用されます。 これは、Web サイトの構造やコンテンツが変更された場合、またはページが新しい場所に移動した場合によく使用されます。 リダイレクト ルールを使用して、ユーザーと検索エンジンを正しいページに誘導し、リンク切れを防ぐことができます。 301 リダイレクト、302 リダイレクト、メタ リフレッシュ リダイレクトなど、使用できるリダイレクトにはいくつかの種類があります。 使用されるリダイレクトのタイプは、Web サイトの特定のニーズとリダイレクトの理由によって異なります。

Nginx の構成

リダイレクト ルールを作成するには、サーバーまたは場所のコンテキスト内で return ディレクティブを宣言します。 return ディレクティブは、ユーザーをある URL から別の URL にリダイレクトする場合、またはセキュリティで保護されていないチャネルからセキュリティで保護されたサーバーにリダイレクトする場合に使用されます。
Nginx リダイレクト ルールは、次の構文に従います。

return ( 301 | 302 | 303 | 307 ) redirect-url;

セキュリティで保護されていない http からセキュリティで保護された https の場所にユーザーをリダイレクトする場合の設定例を次に示します。

server {
# Redirect users to HTTPS
listen      80;
server_name test.zevenet.com www.test.zevenet.com;
return      301 https://www.test.zevenet.com$request_uri;
}

$request_uri オプションを使用すると、パスが変更された場合でも、同じドメインのすべての http トラフィックが安全な https にリダイレクトされます。

ZEVENET構成

ZEVENET ADCで同様の結果を達成するには.

  1. XNUMX つのファームが実行されていることを確認します。 HTTP and HTTPS. についてはこちらの記事を参照 レイヤー 4 およびレイヤー ロード ファームの作成方法
  2. 　 LSLB >>ファーム をクリックして 編集 https ファームのアイコン。
  3. 動画内で サービス タブをクリックし、設定済みのサービスを開いて編集します。 何もない場合は、 新サービス ボタンをクリックして作成します。
  4. に到達するまでスクロールします。 リダイレクト セクションとトグルオン リダイレクトを有効にする.

    5. oracle_jd_edwards_load_balancing_farm

  5. リダイレクトの種類を選択 追加、リダイレクト コード 301 リダイレクト先の完全な URL を記述します。 この例では、 http://10.0.0.18
  6. をクリックして構成を更新します。 お申し込み ボタン。

こちらもご覧ください:

構成例: ヘッダー ルールの書き換え

HTTP ヘッダーは、ホストとクライアントがリクエストのクエリ以外の追加情報を共有するために不可欠です。 これらのヘッダーにより、クライアントは好みの言語でリソースにアクセスしたり、デバイス用に最適化された Web ページにアクセスしたりできます。 Web サーバーは、この情報を使用して、Cookie ヘッダーを使用してクライアントに提供する情報の種類を最適化する場合があります。

残念ながら、多くの応答ヘッダーを使用すると、ハッカーが悪用の試みに使用する可能性のある多くの機密情報が明らかになる可能性があります。 そのため、信頼できないヘッダーを削除するか、一部のコンテンツを変更することが不可欠です。 これにより、クロスサイト スクリプティングなどの悪意のある攻撃を防ぐことができます。 X-XSS-保護.

Nginx の構成

Nginx は、ヘッダーを変更および追加するための 2 つのディレクティブを提供します。 これらには以下が含まれます ヘッダーの追加 and more_set_headers. これらのロケーション ヘッダーは、ロケーション ブロック内で使用します。

を使用した構成例 ヘッダーの追加 nginxで。

location / {
	...
	add_header Server “serverName”;
	...
}

more_set_headers は Nginx にネイティブにインストールされていないため、ユーザーは通常、nginx をコンパイルする前にこのプラグインを手動でインストールします。

を使用した構成例 more_set_headers.

location /{
        ...
	more_set_headers Server “serverName”;
        ...
}

ZEVENET構成

  1. まず、に行く LSLB>>農場 を選択します HTTP ルールを設定したい農場。
  2. 下 グローバル 設定で、 詳細設定 タブでを確認できます。
  3. 以内 詳細設定、 を選択 有効にします 内のオプション ロケーションヘッダーを書き換える ルール。

    4. oracle_jd_edwards_load_balancing_farm

  4. をクリックして構成を更新します。 お申し込み ボタン。
  5. ヘッダー セクションまでスクロールし、 ルールを作成 ボタン。
  6. 以内 種類 ドロップダウン オプションから、アプリケーションに適したものを選択します。 この例では、 応答：ヘッダーを追加.

    7. oracle_jd_edwards_load_balancing_farm

  7. 値を変更するヘッダーを入力します。 この例では、次の値を変更します。 サーバー ヘッダ。
  8. をクリックして構成を保存します。 お申し込み ボタン。
  9. 再起動 構成を有効にするためのファーム。

その他のリソース

Let's encrypt プログラムを使用して、SSL 証明書を自動生成します。
ZEVENET ADCによるデータリンク/アップリンク負荷分散。
ZEVENET ADCによるDNS負荷分散。
DDoS 攻撃からの保護。
ZEVENET ADC でのアプリケーション、ヘルス、およびネットワークの監視。
ウェブ アプリケーション ファイアウォールの構成。
ロード バランサーの SSL 証明書を構成します。

上の共有：

GNU Free Documentation Licenseの条項に基づくドキュメンテーション。

この記事は役に立ちましたか？

はい いいえ

関連記事