Nginx/Httpd ロードバランシング Tomcat 設定チュートリアル

前回のブログでは、Nginx と httpd を使用して、逆生成用のバックエンド Tomcat サービスを構成する方法について説明しました。復習については、https://www.jb51.net/article/191277.htm を参照してください。今日は、Nginx と httpd を使用して、負荷分散用の Tomcat クラスターを構成する方法と、注意すべき点について説明しましょう。前回のデモと構成はすべて、単一の Tomcat で構成および使用されていました。ただし、実稼働環境では、単一の Tomcat では大規模なアクセスをサポートできません。このとき、外部サービスを提供するために複数の Tomcat をクラスタ化することを検討する必要があります。外部サービスを提供するために複数の Tomcat をクラスタ化する場合、クライアント要求をスケジュールするためのスケジューラが必要です。よく使用されるスケジューラには、nginx、httpd、haproxy、lvs などがあります。これらのスケジューラを使用して Tomcat を負荷分散用に構成することと、他の Web サーバーを負荷分散用に構成することの間には、本質的な違いはありません。Tomcat を Web サーバーとして構成するだけで済みます。

1. 環境整備

docker を実行して、2 つの Tomcat コンテナをバックエンド Tomcat サーバーとして起動し、ストレージ ボリュームを使用して、2 つの Tomcat コンテナの Web ディレクトリをそれぞれ /tomcat/doc/tomcat1 ディレクトリと tomcat1 ディレクトリにマップします。

ヒント: 上記では tct1 と tc2 という 2 つの tomcat コンテナが実行されており、/usr/local/tomcat/webapps/myapp をホスト マシンの /tomcat/doc/tomcat1 と tomcat2 にマップしています。このようにして、Web スクリプトをホスト マシンのこのディレクトリに直接配置して、Web ページを tomcat のデフォルトの仮想ホストに展開することができます。

両方のコンテナのホームページファイルの内容を編集する

ヒント: 上記は、それぞれ tomcat1 と tomcat2 のテスト ホームページを提供します。

tomcat1とtomcat2を別々に配置して、対応するホームページにアクセスできるかどうかを確認します。

ヒント: tomcat1 と tomcat2 の両方にアクセスできることがわかります。つまり、バックエンドの tomcat 環境は準備ができています。次に、nginx を設定して負荷分散を行います。

2. Tomcatの負荷分散を行うためにnginxを設定する

ヒント: 上記の構成は、2 つの tomcat コンテナーを tcsevs グループにマージし、リバース プロキシ / を介してこのグループにアクセスします。この構成はデフォルトでポーリングされます。

検証: ホスト マシンのポート 80 にアクセスして、2 つのバックエンド Tomcat コンテナーによってそれぞれ提供されるホームページにアクセスできるかどうかを確認します。

nginx設定ファイルの構文形式を確認し、nginxを起動します

ホスト マシンのポート 80 にアクセスして、バックエンド Tomcat によって提供されるページにアクセスできるかどうかを確認します。

ヒント: ホストマシンのポート 80 にアクセスすると、バックエンドの Tomcat サーバーに正常にアクセスできることがわかります。また、デフォルトのポーリング スケジュールの効果も確認できます。ただし、ここで問題があります。同じユーザーがホストマシンのポート 80 にアクセスすると、応答結果のセッション ID が異なります。これは、nginx がユーザーのステータス情報を追跡しないことを意味します。その理由は、http リクエストがステートレスであるためです。サービスがユーザーのステータス情報を記録できるようにするために、nginx でソース IP に基づいてスケジュールを設定できます。これはどういう意味ですか? 同じソース IP アドレスの場合、nginx は同じバックエンド サーバーにリクエストをスケジュールするため、同じユーザー アクセスのステータス情報は常に同じバックエンド サーバーにスケジュールされます。

Nginxは送信元IPに基づいてセッションを維持する

ヒント: ip_hash と hash $remote_addr はどちらも、送信元 IP アドレスをハッシュし、その結果と合計の重みに対してモジュロ演算を実行することを表します。リクエストは、結果が当てはまるノードにディスパッチされます。これは何を意味するのでしょうか。上記のように、バックエンド サーバーが 2 つあり、それらの重みは両方とも 1 であるため、重みの合計は 2 です。ip_hash と hash $remote_addr は、クライアントの IP アドレスの最初の 3 つのセグメントに対してハッシュ演算を実行し、取得した値と重みの合計に対してモジュロ演算を実行します。明らかに、モジュロ バックエンドの結果は 0 または 1 のいずれかです。モジュロ演算後の結果が 1 の場合、nginx は内部の対応に基づいて、リクエストを tomcatB または tomcatA にディスパッチします。

テスト: niginx を再起動し、ホスト マシンのポート 80 にアクセスして、すべてのリクエストが同じバックエンド サーバーに送信されるかどうかを確認します。

ヒント：ホストマシンのポート80へのアクセスは、常に127.0.0.1のポート80にアクセスすると、Tomcatbに派遣されます。 NginxServerと同じLANであるため、もちろん、同じLANでリクエストが行われます。同じバックエンドサーバーにaTched。クライアントとバックエンドサーバーが結合してセッションバインディングを達成することはこの原則に基づいています。

httpdはTomcatの負荷分散を行います

httpd をロードバランサーとして使用する場合、httpd で proxy_http_module、proxy_module、proxy_balancer_module が有効になっているか確認する必要があります。ajp を使用する必要がある場合は、proxy_ajp_module モジュールが有効になっているか、また、スケジューリング アルゴリズムの 3 つのモジュール lbmethod_bybusyness_module、lbmethod_byrequests_module、lbmethod_bytraffic_module が有効になっているか確認する必要があります。スケジューリング アルゴリズムは、上記のモジュールのいずれかを有効にできます。http や ajp も同様です。必要な場合は有効にし、使用しない場合は問題ありません。

ヒント: 使用する必要があるすべてのモジュールが有効になっていることがわかります。

バックエンドのTomcatの負荷を分散するようにhttpdを設定する

: : : : : : : : : : : : : : :

nginxを停止し、httpd設定ファイルの構文を確認し、問題がなければhttpdを起動します。

httpdが提供するサービスにアクセスして、バックエンドのTomcatページにアクセスできるかどうかを確認します。

ヒント: nginx のアクセスと同様にポーリングが実現できることがわかります。

httpdはバックエンドのTomcatへのセッションを固定するためにクッキーを使用する

: : : : : : : : : : : : : : :

テスト: httpd の設定ファイルの構文を確認します。問題がなければ、httpd を再起動して httpd にアクセスし、どのような変更が行われるかを確認します。

curl を使用して httpd サーバーへの最初のアクセスをシミュレートし、応答ヘッダーに変更があるかどうかを確認します。

ヒント: httpd サーバーにアクセスすると、応答ヘッダーに追加の set-cookie ヘッダーがあり、このヘッダーの値は、以前に構成ファイルで構成した KEY と値であることがわかります。set-cookie ヘッダーは主に、ブラウザーが次の要求を行うときに使用され、set-cookie ヘッダーの値を cookie ヘッダーとともに送信してサーバーにアクセスします。これにより、サーバーは、どのクライアントが要求を送信したかを分析し、クライアント要求メッセージ内の cookie の値に応じて後続のサーバーをスケジュールする方法を判断できます。

ブラウザを使用して Web サイトにアクセスし、クライアントが最初のアクセスから設定された Cookie 値を使用して、後続のリクエストでサーバーをリクエストしているかどうかを確認します。

ヒント: ブラウザーが初めてアクセスすると、サーバーが応答ヘッダーに set-cookie ヘッダーを追加します。このヘッダーの値は ROUTEID で、これはバックエンド サーバーへの現在の応答のルートの値です。

ヒント: クライアントが、リクエスト ヘッダー クッキーに、前の set-cookie の値を保持していることがわかります。このとき、httpd はクライアント リクエストを受信すると、set stickysession で指定された KEY に基づいて、対応するリクエストをどのバックエンド サーバーに送信して応答するかを決定できます。このように、クライアントの cookie が変更されない限り、サーバーにアクセスするたびに、cookie ヘッダーの値を使用して、どのバックエンド サーバーに送信するかをサーバーに伝えます。

curlを使用して、サーバーにアクセスするためにCookieを送信するクライアント要求をシミュレートします。

ヒント: curl を使用してクライアント アクセスを模倣し、Cookie を運ぶと、応答ヘッダーで set-cookie ヘッダーが送信されず (ここでの set-cookie は、サーバー設定に関連するヘッダーを指します)、異なる ROUTEID を持つ Cookie を運ぶと、運ぶ ROUTEID の値に応じて、応答のために異なるバックエンド サーバーにディスパッチされます。httpd ロード バランシング プロキシ バックエンド tomcat に ajp を使用する構成方法は、http の構成方法と同じです。唯一の違いは、バックエンド サーバーの http プロトコルが ajp に変更され、バックエンド tomcat のポートが ajp プロトコルによってリッスンされるポートに変更されることです。デフォルトでは、tomcat ajp プロトコルはポート 8009 でリッスンします。

httpdバックエンド管理インターフェースページを構成する

ヒント: 上記の設定は、httpd 管理ページを起動し、それを uri /manager-page にバインドすることを意味します。uri /manager-page に対してプロキシは実行されず、rui は IP アドレス 192.168.0.232 のホストのみにアクセスを許可できます。サーバー自体を含む他のホストには権限がありません。

検証: 192.168.0.232 以外のホストを使用して 192.168.0.22/manager-page にアクセスし、アクセスできるかどうかを確認します。

ヒント: 192.168.0.22 を使用してアクセスすると、プロンプト 403 に権限がないことがわかります。

192.168.0.232 を使用してアクセスし、管理ページにアクセスできるかどうかを確認します。

ヒント: 通常、192.168.0.232 のブラウザを使用して httpd 管理ページにアクセスできます。

tomcat1の重みを動的に変更する

ヒント: このページではバックエンド サーバーのプロパティが動的に変更される可能性があるため、通常はアクセス制限が必要です。

Nginx/Httpd ロード バランシング tomcat 構成に関するこの記事はこれで終わりです。Nginx/Httpd ロード バランシング tomcat 構成に関するより関連性の高いコンテンツについては、123WORDPRESS.COM で以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後も 123WORDPRESS.COM をよろしくお願いいたします。