1. nginxの基本概念

1.1 nginxの概要

Nginx (「エンジン

1.2 WebサーバーとしてのNginx

Nginx は静的ページの Web サーバーとして使用でき、Perl、php などの CGI プロトコルの動的言語もサポートします。ただし、Java はサポートされていません。Javaプログラムはtomcatと連携して初めて完成します。Nginx はパフォーマンスの最適化のために特別に開発されました。パフォーマンスが最も重要な考慮事項です。その実装は効率を非常に重視しており、高負荷のテストに耐えることができます。レポートによると、最大 50,000 の同時接続をサポートできます。https://lnmp.org/nginx.html

1.3 エージェントとは何ですか?

プロキシ (ネットワークプロキシとも呼ばれます) は、ある端末 (通常はクライアント) がこのサービスを通じて別の端末 (通常はサーバー) と間接的に接続できるようにする特別なネットワークサービスです。たとえば、ゲートウェイやルーターなどの一部のネットワークデバイスにはネットワークプロキシ機能があります。プロキシサービスは、ネットワーク端末のプライバシーやセキュリティの確保に役立ち、ネットワーク攻撃をある程度防ぐことができます (プロキシを介して実際のサーバー/クライアントを隠すことができるため)。

1.3 プロキシサーバー

左右のコンピュータが通信する場合、中央のコンピュータを経由して転送する必要があり、中央のコンピュータがプロキシサーバーになります。
詳細なプロセス: クライアントは、まずプロキシサーバーが使用するプロキシプロトコルに従ってプロキシサーバーとの接続を作成し、次にプロトコル要求に従ってターゲットサーバーへの接続を作成するか、ターゲットサーバーの指定されたリソース (ファイルなど) を取得します。ターゲットサーバー。

1.3 フォワードプロキシ

シナリオ: たとえば、Web サイトにアクセスしたいが、直接アクセスできない場合は、サービスを提供するプロキシサーバーを見つけ、プロキシサーバーを通じて Web サイトをリクエストします。この Web サイトの場合、サーバーがその Web サイトにアクセスしたことだけが認識され、ユーザーがその Web サイトにアクセスしたことは認識されません。
概念: フォワードプロキシは、クライアントおよびオリジナルサーバーの前に位置するサーバーであり、オリジナルサーバーからコンテンツを取得するために、クライアントがプロキシにリクエストを送信し、ターゲット (オリジナルサーバー) を指定すると、プロキシはコンテンツを転送します。元のサーバーにリクエストを送信してコンテンツを取得すると、コンテンツがクライアントに返され、クライアントはフォワードプロキシを使用できるようになります。
要件: 指定された Web サイトにアクセスするには、クライアント上でプロキシサーバーを構成する必要があります。

ここに画像の説明を挿入します

1.4 リバースプロキシ

リバースプロキシ。実際には、クライアントはプロキシにアクセスするための構成を必要としないため、クライアントはプロキシを認識しません。要求をリバースプロキシサーバーに送信するだけでよく、リバースプロキシサーバーは取得するターゲットサーバーを選択します。データがクライアントに返されると、リバースプロキシサーバーとターゲットサーバーは外部に対して1 つのサーバーとなり、プロキシサーバーのアドレスは公開され、実際のサーバーの IP アドレスは隠蔽されます。

1.5 負荷分散

モノリシックアーキテクチャモデル: クライアントは複数のリクエストをサーバーに送信し、サーバーはリクエストを処理します。そのうちのいくつかはデータベースと対話する必要がある場合があります。サーバーが処理を完了すると、結果がクライアントに返されます。
短所: このアーキテクチャモデルは、比較的単純で同時リクエストが比較的少なく、コストも低い初期のシステムに適しています。しかし、情報量が増加し続け、アクセスとデータの量が急速に増加し、システムビジネスが複雑になるにつれて、このアーキテクチャでは、クライアントの要求に対するサーバーの応答がますます遅くなります。サーバーを直接クラッシュさせるのは簡単です。これは明らかにサーバーのパフォーマンスのボトルネックによって引き起こされる問題ですが、この状況を解決するにはどうすればよいでしょうか?
解決策 1 (推奨されません) :この問題を解決するには、CPU の実行周波数を上げる、メモリを増やすなど、サーバー構成をアップグレードしてマシンの物理的なパフォーマンスを向上させます。ハードウェアの性能向上では、増大する需要に対応できなくなります。最も明白な例は、Tmall のダブルイレブンの日に、特定の売れ筋商品への瞬間的なアクセス数が非常に多かったため、上記のシステムアーキテクチャと同様の既存のトップレベルの物理構成にマシンを追加することは不可能です。 . ニーズに応えます。じゃあ何をすればいいの？
解決策 2 (推奨) : 上記の分析では、問題を解決するためにサーバーの物理構成を増やす方法を削除しました。つまり、問題を解決する垂直的な方法は機能しません。サーバーの数を増やす場合はどうでしょうか。水平に？このときクラスタという概念が登場し、サーバ1台では解決できないため、サーバを増やして各サーバにリクエストを分散させることを将原先请求集中到单个服务器上的情况改为将请求分发到多个服务器上，将负载分发到不同的服务器ロードバランシングと呼びます。

1.6 動きと静の分離

通常の方法: 静的リソースと動的リソースの両方を Tomact サーバーにデプロイする欠点: 静的リソースと動的リソースの両方を要求すると Tomact サーバーにアクセスするため、Tomact へのアクセス圧力が増加します。
動的ページと静的ページの分離: Web サイトの解析速度を高速化するために、動的ページと静的ページを異なるサーバーで解析して、解析速度を高速化できます。単一サーバーの負荷を軽減します。

2. nginx のインストール、一般的なコマンドと設定ファイル

2.1 liunx システムに nginx をインストールする

インストール環境と手順の詳細については、「Nginx Basics + Advanced (2022 Edition) - Section 2 Section 3」を参照してください。

2.2 nginxの共通コマンド

インストール環境と手順の詳細については、「Nginx Basics + Advanced (2022 Edition) - Section 3」を参照してください。

2.3 nginx設定ファイル

2.3.1 nginx設定ファイルの場所

cd /usr/local/nginx/conf/nginx.conf

ここに画像の説明を挿入します

2.3.2 設定ファイルの内容

nginx 設定ファイルは 3 つの部分で構成されます
コメントを削除すると、情報は次のようになります。

#第一部分：全局块
#从配置文件开始到 events 块之间的内容，主要会设置一些影响 nginx 服务器整体运行的配置指令，主要包括配置运行 Nginx 服务器的用户（组）、允许生成的 worker process 数，进程 PID 存放路径、日志存放路径和类型以及配置文件的引入等。
worker_processes  1; #这是 Nginx 服务器并发处理服务的关键配置，worker_processes 值越大，可以支持的并发处理量也越多，但是会受到硬件、软件等设备的制约


#第二部分：events 块
#events 块涉及的指令主要影响 Nginx 服务器与用户的网络连接，常用的设置包括是否开启对多 work process 下的网络连接进行序列化，是否允许同时接收多个网络连接，选取哪种事件驱动模型来处理连接请求，每个 word process 可以同时支持的最大连接数等。
events {
    
    
    worker_connections  1024;# 支持的最大连接数为 1024.
}


#第三部分：http 块
#这算是 Nginx 服务器配置中最频繁的部分，代理、缓存和日志定义等绝大多数功能和第三方模块的配置都在这里。
#需要注意的是：http 块也可以包括 http 全局块、server 块。
http {
    
    
 # http 全局块
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;

    keepalive_timeout  65;


 # server 块
    server {
    
    
        listen       80;
        server_name  localhost;

        location / {
    
    
            root   html;
            index  index.html index.htm;
        }


        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
    
    
            root   html;
        }

    }

}

2.3.3 設定ファイル-その3: httpブロックの詳細説明

各構成の意味は、Nginx のさまざまなアプリケーションシナリオの構成を指します。


http {
    
    
 # http 全局块
 # http 全局块配置的指令包括文件引入、MIME-TYPE 定义、日志自定义、连接超时时间、单链接请求数上限等。
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;

    keepalive_timeout  65;


 # server 块
 # 这块和虚拟主机有密切关系，虚拟主机从用户角度看，和一台独立的硬件主机是完全一样的，该技术的产生是为了节省互联网服务器硬件成本。
 # 每个 http 块可以包括多个 server 块，而每个 server 块就相当于一个虚拟主机。
 # 而每个 server 块也分为全局 server 块，以及可以同时包含多个 locaton 块。
    server {
    
    
    #全局 server 块
    #最常见的配置是本虚拟机主机的监听配置和本虚拟主机的名称或 IP 配置。
        listen       80;
        server_name  localhost;

    #locaton 块
    #这块的主要作用是基于 Nginx 服务器接收到的请求字符串（例如 server_name/uri-string），对虚拟主机名称（也可以是 IP 别名）之外的字符串（例如 前面的 /uri-string）进行匹配，对特定的请求进行处理。地址定向、数据缓存和应答控制等功能，还有许多第三方模块的配置也在这里进行。
        location / {
    
    
            root   html;
            index  index.html index.htm;
        }


        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
    
    
            root   html;
        }

    }

}

3. Nginxの各種アプリケーションシナリオの構成

3.1 nginx 構成例 1-リバースプロキシ

3.1.1 リバースプロキシ - 例 1

1) 効果を達成する

ブラウザを開き、ブラウザのアドレスバーにアドレスを入力しwww.123.com、liunx システムの Tomcat メインページにジャンプします。

2) 準備作業

デフォルトのポート 8080 を使用して、Tomcat を liunx システムにインストールします
。手順:

Tomcat インストールファイルを liunx システムに配置し ( cd /usr/src)、解凍します
( tar -xvf apache-tomcat-7.0.70.tar.gz)
Tomact を起動するには、jdk 環境に依存する必要があります (通常、システムには jdk が付属しています)。
Tomcatのbinディレクトリに入ります
cd apache-tomcat-7.0.70/
cd bin
./startup.shTomcatサーバーを起動する

3) 外部アクセスに開かれたポート

ここで使用される最初の方法はファイアウォールを直接オフにするため、この方法は無視されます。

#开放端口号
firewall-cmd --add-port=8080/tcp --permanent

#重启防火墙
firewall-cmd –reload

#查看已经开放的端口号
firewall-cmd --list-all

4) Windows システムのブラウザを通じて Tomcat サーバーにアクセスします。

http://192.168.10.31:8080/

5) アクセスプロセスの分析

127.0.0.1 は仮想マシンのローカル IP アドレスを表します

6) 具体的な構成

最初のステップは、Windows システムのホストファイル内でドメイン名と IP の間の対応関係を構成することです。
192.168.10.31 www.123.com
2 番目のステップは、nginx でリクエスト転送を構成することです (リバースプロキシ構成)。

server_name  192.168.10.31;

proxy_pass http://127.0.0.1:8080;

ここに画像の説明を挿入します

nginx を再起動して有効にします。systemctl reload nginx

7) 最終テスト

www.123.com

3.1.2 リバースプロキシ - 例 2

1) 効果を達成する

nginx リバースプロキシを使用して、アクセスパスに基づいて異なるポート上のサービスにジャンプします。
nginxのリスニングポートは9001です
http://192.168.10.31:9001/edu/ にアクセスし、127.0.0.1:8080 に直接ジャンプします。
http://192.168.10.31:9001/vod/ にアクセスし、127.0.0.1:8081 に直接ジャンプします。

2) 準備作業

2 つの Tomcat サーバーを準備します。1 つはポート 8080 で、もう 1 つはポート 8081 です。
- 2つのディレクトリを作成します
  mkdir 8080、mkdir 8081
- 2 つのタムをこれら 2 つのディレクトリにそれぞれアップロードします
- 以前にテストしたタスクを閉じます
  找到进程：ps -ef | grep 'tomcat'
  杀死进程：kill -9 23754
- tomactを2つのディレクトリにそれぞれ解凍します
  tar -xvf apache-tomcat-7.0.70.tar.gz
- ポート番号を変更する
  Tomact のデフォルトのポート番号は 8080 なので、2 番目のポート番号を 8081 に変更する必要があります。
- 2つのTomactをそれぞれ起動して
  cd apache-tomcat-7.0.70/
  cd bin
  ./startup.shTomcatサーバーを起動します
- 2 つの toamct がインストールされ、正常に起動されるかどうかをテストします。
  http://192.168.10.31:8080/
  http://192.168.10.31:8081/
フォルダーとテストページを作成する
- プロジェクトは webapps ディレクトリにデプロイされるため、このディレクトリにファイルとフォルダーを作成する必要があります。
- 最初のディレクトリにディレクトリとページを/usr/src/tomact8080/apache-tomcat-7.0.70/webapps/作成します。ページの内容:アクセステスト:edua.html
  
  <h1>8080!!!</h1>
  
  http://192.168.10.31:8080/edu/a.html
- 同様に、 2 番目のディレクトリにディレクトリとページを/usr/src/tomact8081/apache-tomcat-7.0.70/webapps/作成します。ページの内容:アクセステスト:vodb.html
  
  <h1>8081!!!</h1>
  
  http://192.168.10.31:8081/vod/b.html

3) 具体的な構成

nginx 構成ファイルを見つけて、リバースプロキシを構成します。

  #nginx配置反向代理-实例2
    server {
    
    
        listen       9001;
        server_name  192.168.10.31;

        location ~ /edu/ {
    
     #正则表达式写法：表示当路径中有edu就转发到对应的地址8080中去
            proxy_pass http://127.0.0.1:8080;
        }
        
        location ~ /vod/ {
    
     #正则表达式写法：表示当路径中有edu就转发到对应的地址8081中去
            proxy_pass http://127.0.0.1:8081;
        }


        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
    
    
            root   html;
        }

    }

外部アクセス用にポート番号 9001 8080 8081 を開き
、ファイアウォールを直接閉じます。
nginx を再起動して有効にします。systemctl reload nginx

4) 最終テスト

http://192.168.10.31:9001/edu/ にアクセスし、127.0.0.1:8080 に直接ジャンプします。
http://192.168.10.31:9001/vod/ にアクセスし、127.0.0.1:8081 に直接ジャンプします。

5) 位置指示の説明

このディレクティブは、URL を照合するために使用されます。
構文は次のとおりです。
- =: 正規表現なしで URI の前に使用される場合、リクエスト文字列は URI と厳密に一致する必要があります。一致に
  成功すると、検索は停止し、リクエストはすぐに処理されます。
- ~: URI に正規表現が含まれており、大文字と小文字が区別されることを示すために使用されます。
- ~*: URI に正規表現が含まれており、大文字と小文字が区別されないことを示すために使用されます。
- ^~: 正規表現のない URI に使用される前に、Nginx サーバーは、識別子 URI とリクエスト文字列の間の一致度が最も高い場所を見つけて、すぐにその場所を使用してリクエストを処理する必要があります。通常の URI と location ブロック内のリクエストの文字列照合。
- 注意：如果 uri 包含正则表达式，则必须要有 ~ 或者 ~* 标识

3.2 nginx 構成例 2 負荷分散

3.2.1 導入効果

ブラウザのアドレスバーにアドレスを入力しhttp://192.168.10.31:8010/edu/a.html、負荷分散効果、平均ポート 8080 および 8081

3.2.2 準備

Tomcat サーバーを 2 台用意します (8080 と 8081)。
- 省略 - リバースプロキシインスタンス 2 ですでに準備されています
2 つの Tomcat の webapps ディレクトリに、edu という名前のフォルダを作成し、テスト用に edu フォルダ内にページ a.html を作成します。
- edu ディレクトリと .html ファイルは 8080 ファイルディレクトリに作成されています。必要な作業は 8081 フォルダに edu ディレクトリと .html ファイルを作成することだけです。ディレクトリの作成:
  edu
  
  ファイルの作成: a.html
  ファイルの内容:<h1>8081!!!</h1>

3.2.3 nginx 設定ファイルでロードバランシングを設定する

    #负载均衡服务的名字，里面列出负载tomact服务器的列表
    upstream myserver {
    
    
      server 192.168.10.31:8080;
      server 192.168.10.31:8081;
    }
    
  #nginx配置负载均衡
    server {
    
    
        listen       8010;
        server_name  192.168.10.31;

        location / {
    
    
            root   html;
            proxy_pass http://myserver;  #加上负载均衡服务的名字
            index  index.html index.htm;
        }


        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
    
    
            root   html;
        }

    }

ここに画像の説明を挿入します

nginx を再起動して有効にします。systemctl reload nginx
テスト: http://192.168.10.31:8010/edu/a.html 最初に送信されたリクエストは 8081 を返し、2 回目は 8080 を返し、3 回目は 8081 を返し、デフォルトの負荷分散が行われていることを示していることがわかります。は投票戦略です。

3.2.4 nginx によるサーバーポリシーの割り当て

1 つ目のポーリング ( 默认)
では、各リクエストが時系列に 1 つずつ異なるバックエンドサーバーに割り当てられ、バックエンドサーバーがダウンした場合には自動的に排除されます。
2 番目のタイプの重みの
重みは、重みがデフォルトで 1 になることを意味します。重みが大きいほど、より多くのクライアントが割り当てられます。

    #负载均衡-权重，之后在location中引入服务
    upstream myserver01{
    
    
      server 192.168.10.31:8080 weight=10;
      server 192.168.10.31:8081 weight=20;
    }

3 番目のタイプの ip_hash は、
リクエストごとにアクセスされた IP のハッシュ結果に従って割り当てられるため、各訪問者はバックエンドサーバーにアクセスできます。

    #负载均衡-ip_hash，之后在location中引入服务
    upstream myserver02 {
    
    
      ip_hash;
      server 192.168.10.31:8080;
      server 192.168.10.31:8081;
    }

4 番目のフェア (サードパーティ) は、
バックエンドサーバーの応答時間に基づいてリクエストを割り当て、応答時間の短いリクエストを優先します。

    #负载均衡-fair，之后在location中引入服务
    upstream myserver03 {
    
    
      server 192.168.10.31:8080;
      server 192.168.10.31:8081;
      fair;
    }

3.3 nginx 構成例 3-動的および静的分離

3.3.1 概念の詳細な説明

Nginxの動的・静的分離とは、単に動的リクエストと静的リクエストを分離するという意味であり、単に動的ページと静的ページを物理的に分離するという意味では理解できません。厳密に言えば、動的リクエストと静的リクエストは分けるべきですが、静的ページの処理にはNginxを使用し、動的ページの処理にはTomcatを使用すると理解できます。現在の実装の観点から、動的分離と静的分離は次の 2 つのタイプに大別できます。

1 つは、単純に静的ファイルを個別のドメイン名に分離し、独立したサーバーに配置する方法です。これは、現在の。

もう 1 つの方法は、動的ファイルと静的ファイルを混合して一緒に公開し、nginx を介して分離することです。

異なる要求転送を実装するには、場所を通じて異なるサフィックス名を指定します。Expires パラメーターを設定すると、ブラウザーのキャッシュ有効期限を設定し、サーバーとの以前のリクエストとトラフィックを減らすことができます。Expires の具体的な定義は、リソースの有効期限を設定することです。つまり、検証のためにサーバーにアクセスする必要がなく、ブラウザ自体を通じて有効期限が切れているかどうかを直接確認できるため、追加のトラフィックが発生することはありません。生成された。この方法は、頻繁に変更されないリソースに最適です。(ファイルが頻繁に更新される場合、キャッシュに Expires を使用することはお勧めできません。) ここでは 3d を設定します。これは、この 3 日以内にこの URL にアクセスすると、リクエストを送信してファイルの最終更新時刻を比較することを意味します。変更がない場合はキャッシュされません。サーバーから取得すると、ステータスコード 304 が返されます。変更があった場合は、再度サーバーから直接ダウンロードすると、ステータスコード 200 が返されます。
ここに画像の説明を挿入します

3.3.2 準備

注: このテストは、静的ファイルを個別のドメイン名に分割し、テストのために独立したサーバーに配置するという最初の方法に従います。
liunx システムでアクセスできるように静的リソースを準備します。ルートディレクトリにフォルダー data を作成し、データディレクトリの下に www、image という 2 つのディレクトリを作成します。wwwディレクトリに .html ファイルを
作成します。ファイルの内容はイメージ内にあります。画像を挿入します a2.jpg

<h1>test html!!!</h1>

3.3.3 具体的な構成

  #nginx配置动静分离
    server {
    
    
        listen       8020;
        server_name  192.168.10.31;

        location /www/ {
    
    
            root   /data/;
            index  index.html index.htm;
        }
        
        location /image/ {
    
    
            root   /data/;
            autoindex   on; 
        }


        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
    
    
            root   html;
        }

    }

ここに画像の説明を挿入します

nginx を再起動して有効にします。systemctl reload nginx

3.3.4 最終テスト

ブラウザにアドレスを入力します。http://192.168.10.31:8020/www/a.html
ブラウザにアドレスを入力します。http://192.168.10.31:8020/image/
- 設定ファイルで設定されているためautoindex on;、現在のフォルダーの内容を一覧表示することになります。
ブラウザにアドレスを入力します。http://192.168.10.31:8020/image/a2.jpg

3.4 nginx 構成の高可用性クラスター

3.4.1 nginx の高可用性とは何ですか?

単一の nginx の問題:
高可用性: メインサーバー nginx がダウンすると、自動的にバックアップ nginx サーバーに切り替わり、バックアップサーバーがリクエストを分散します。
- どちらの nginx サーバーもソフトウェアを使用しますkeepalived, ルーティングと同様. これは、現在の nginx サーバーがまだ生きているかどうかを検出するスクリプトを使用します. アクセスされると、ダウンしている場合は別のバックアップ nginx サーバーに切り替えてアクセスします.
- 外部アクセスは仮想 IP であり、2 つの nginx サーバーにバインドする必要があります。
- プロセス: まず、メインサーバーは仮想 IP にバインドされます。メイン nginx サーバーがダウンしていることを keepalived が検出すると、仮想 IP はバックアップ nginx サーバーにバインドされます。私たちは全員、仮想 IP を介してアクセスします。

3.4.2 高可用性を構成するための準備

2 つのサーバー 192.168.10.31 と 192.168.10.32 が必要です
2台のサーバーにnginxをインストールする
- 2 番目の仮想マシンを直接クローンし、IP とホスト名を変更します (nginx01、nginx02)。
両方のサーバーにキープアライブをインストールします
- yum コマンドを使用してインストールします。yum install keepalived –y
- インストール後、etc に keepalived ディレクトリが生成されます。このディレクトリ内に設定ファイル keepalived.conf があります。
  cd /etc/keepalived/
2 つの Linux インストールが成功したかどうかをテストします。2
つの nginx 構成ファイルを変更します。

有効にするために nginx を再起動します:systemctl reload nginx
にアクセスしてください: http://192.168.10.31:8030/、http://192.168.10.32:8030/

3.4.3 完全な高可用性構成 (マスター/スレーブ構成)

1) /etc/keepalived/keepalivec.conf 設定ファイルを変更します。
cd /etc/keepalived/

最初のnginx:

global_defs {
    
    
   notification_email {
    
    
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
     notification_email_from Alexandre.Cassen@firewall.loc
     smtp_server 192.168.10.31
     smtp_connect_timeout 30
     router_id LVS_DEVEL
}

vrrp_script chk_http_port {
    
    

   script "/usr/local/src/nginx_check.sh"  #检测脚本的路径
   
   interval 2    #（检测脚本执行的间隔）
   
   weight 2
}

vrrp_instance VI_1 {
    
    
   state MASTER # 备份服务器上将 MASTER 改为 BACKUP 
   interface ens33 //网卡
   virtual_router_id 51 # 主、备机的 virtual_router_id 必须相同
   priority 100 # 主、备机取不同的优先级，主机值较大，备份机值较小
   advert_int 1
   authentication {
    
    
       auth_type PASS
       auth_pass 1111
   }
   virtual_ipaddress {
    
    
       192.168.17.50 // VRRP H 虚拟地址
   }
}

2 番目の nginx:

global_defs {
    
    
   notification_email {
    
    
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
     notification_email_from Alexandre.Cassen@firewall.loc
     smtp_server 192.168.10.32
     smtp_connect_timeout 30
     router_id LVS_DEVEL
}

vrrp_script chk_http_port {
    
    

   script "/usr/local/src/nginx_check.sh"  #检测脚本的路径
   
   interval 2    #（检测脚本执行的间隔）
   
   weight 2
}

vrrp_instance VI_1 {
    
    
   state BACKUP # 备份服务器上将 MASTER 改为 BACKUP 
   interface ens33 //网卡
   virtual_router_id 51 # 主、备机的 virtual_router_id 必须相同
   priority 90 # 主、备机取不同的优先级，主机值较大，备份机值较小
   advert_int 1
   authentication {
    
    
       auth_type PASS
       auth_pass 1111
   }
   virtual_ipaddress {
    
    
       192.168.17.50 // VRRP H 虚拟地址
   }
}

2) /usr/local/src に検出スクリプトを追加します。
cd /usr/local/src

第一局と第二局で追加された台本内容は同じです

#!/bin/bash
A=`ps -C nginx –no-header |wc -l`
if [ $A -eq 0 ];then
	 /usr/local/nginx/sbin/nginx
	 sleep 2
	 if [ `ps -C nginx --no-header |wc -l` -eq 0 ];then
		killall keepalived
	 fi
fi

3) 両方のサーバーで nginx と keepalived を起動します。

クローン仮想マシンであるため、2 つの nginx がすでに起動されているため、2 つの keepalived を起動するだけで済みます。

#常用命令
启动 nginx：./nginx
启动 keepalived：systemctl start keepalived.service
停止 keepalived：systemctl stop keepalived.service 
重启 keepalived：systemctl restart keepalived.service 
查看 keepalived状态：systemctl status keepalived.service 




#案例测试步骤，在任意目录下进行启动
systemctl start keepalived.service

#查看keepalived进程是否启动成功
ps -ef | grep keepalived

ここに画像の説明を挿入します

3.4.4 最終テスト

知らせ：

最初の仮想マシンの IP:192.168.10.31
2 番目の仮想マシンの IP:192.168.10.32
仮想アドレス IP:192.168.10.50
nginx クラスターをテストするためのポート番号は 8030 です

テスト：

ブラウザのアドレスバーに仮想IPアドレスを入力します。192.168.10.50:8030
メインサーバー (192.168.10.31) で nginx と keepalived を停止し、「192.168.10.50:8030」と入力します。最初の nginx サーバーがダウンした後でも、引き続き正常にアクセスできることがわかります。コマンドを使用すると、次のことがわかります。仮想 IP が元のバインドされたものから変更されていることip a、1 つの nginx が 2 番目の nginx サーバーにバインドするように切り替えられ、構成が成功したことを示します。

#停止 keepalived（任意目录）
systemctl stop keepalived.service 

# nginx停止服务（任意目录）
systemctl stop nginx.service

ここに画像の説明を挿入します

3.4.5 高可用性設定ファイルの詳細説明

設定ファイル

#全局配置
global_defs {
    
    
   notification_email {
    
    
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
     notification_email_from Alexandre.Cassen@firewall.loc
     smtp_server 192.168.10.31
     smtp_connect_timeout 30
     router_id LVS_DEVEL #通过服务器的名字访问到主机vi /etc/hosts（我没配置也可以访问）
}

#脚本配置
vrrp_script chk_http_port {
    
    

   script "/usr/local/src/nginx_check.sh"  #检测脚本的路径
   
   interval 2    #（检测脚本执行的间隔，每隔2秒脚本执行一次）
   
   weight -20 #权重 当脚本中的条件成立，那把当前主机的权重降低20
}

#虚拟ip配置
vrrp_instance VI_1 {
    
    
   state MASTER # 备份服务器上将 MASTER 改为 BACKUP （当前服务器是主服务器还是备份服务器）
   interface ens33 //网卡（ifconfig 查看）
   virtual_router_id 51 # 主、备机的 virtual_router_id 必须相同（唯一标识）
   priority 100 # 主、备机取不同的优先级，主机值较大，备份机值较小
   advert_int 1 #每隔1秒检测一次服务器是否还活着（默认1s）
   authentication {
    
     #权限校验方式
       auth_type PASS #类型为：密码
       auth_pass 1111 #密码值：1111
   }
   virtual_ipaddress {
    
    #设置虚拟ip，可以设置多个
       192.168.10.50 // VRRP H 虚拟地址
   }
}

構成router_id LVS_DEVEL 、サーバー名を介してホストにアクセスしますvi /etc/hosts（構成しなくてもアクセスできます）
ネットワークカードを表示するifconfig

3.4.6 スクリプトファイルの詳細説明

#!/bin/bash
A=`ps -C nginx –no-header |wc -l`
if [ $A -eq 0 ];then
	 /usr/local/nginx/sbin/nginx #（nginx启动脚本的位置）
	 sleep 2
	 #如果主服务器挂掉，从服务器替代主服务器
	 if [ `ps -C nginx --no-header |wc -l` -eq 0 ];then
		   killall keepalived
	 fi
fi

4. Nginxの原理

4.1 マスターとワーカーの関係

Linux が起動すると、2 つのプロセス (マスターとワーカー) が存在します。

#查看nginx进程（nginx已经启动）
ps -ef | grep nginx

関係: nginx が起動すると、メインプロセスマスターがワーカースレッドワーカーにタスクを割り当て、ワーカースレッドワーカーが特定のタスクを実行します。
複数のワーカーが存在する場合があります。

4.2 労働者の働き方

nginx の最も基本的な実行プロセス: クライアントが nginx のマスター (管理者に相当) にリクエストを送信し、管理者マスターがワーカーにタスクを割り当て、ワーカーは競合メカニズムを通じてタスクを取得し、リバースプロキシなどを実行します。操作を行い、最後に特定の操作をtomactで完了します。

4.3 1 つのマスターと複数のワーカーの利点は何ですか?

./nginx -s reload を使用して、構成 (ホットデプロイメントなど) を再ロードできます。
- nginx の変更された構成を有効にする前に、nginx を再起動して停止する必要はなく、ホットデプロイメントには 1 つのマスターと複数のワーカーが便利です。
- 例: 現在 4 人のワーカーがいます。現在のタスクは最初のワーカーと競合しています。この時点で、コマンドを使用して構成を再ロードします。その後、最初のワーカーは変更されずに処理を続行しますが、他の 3 人は変更されません。変更します。ワーカーがリロードします。新しいリクエストがある場合、最初のワーカーはタスクが含まれているため競合せず、他の 3 人のワーカーがタスクを実行するために競合します (この時点で 3 人のワーカーはリロードされています)。最初のワーカーは次のことを行う必要があります。実行後にリロードして最新の構成を取得する必要があります。
まず、各ワーカーは独立したプロセスであり、ロックする必要がないため、ロックによるオーバーヘッドが排除され、同時にプログラミング時や問題発見時に非常に便利になります。第 2 に、ワーカーの 1 つに問題が発生した場合、他のワーカーは引き続き独立して競合し、サービスを中断することなくリクエストプロセスを実行します。

4.4 ワーカーは何人設定するのが適切ですか?

Nginx は、redis と同様に、IO 多重化メカニズム( 如果安装到了windows系统中就没有了io 多路复用机制) を採用しています。各ワーカーは独立したプロセスですが、各プロセスにはメインスレッドが 1 つだけあります。リクエストが数千ある場合でも、非同期かつノンブロッキングな方法で処理されます。のリクエストは問題ありません。各ワーカースレッドは CPU のパフォーマンスを最大化できます。したがって、ワーカーの数はサーバー上の CPU の数と同じであることが最も適切です。設定が小さすぎると CPU が無駄になり、設定しすぎると CPU がコンテキストを頻繁に切り替えて損失が発生します。
nginx設定ファイルnginx.configで設定します

# 默认为1，表示开启一个业务进程（一般一个cpu内核对应一个业务进程）
worker_processes 1;

4.5 接続数 worker_connection

接続数の概念: 各ワーカープロセスによって確立できる接続の最大数を表します。
質問 1 : リクエストを送信するにはワーカーの接続が何回必要ですか?
- 答え: 2 または 4
- 説明: 静的リソースにアクセスするリクエストが送信されると、ワーカーは nginx を通じて静的リソースサーバーを指し、リクエストを返します (2 つの接続を占有します)。ワーカー自体は Java をサポートしていないため、データベースにクエリを実行する場合は Tomact を使用する必要があるため、Tomact にリクエストを送信し続ける必要があり、Tomact はリクエストを返します (4 つの接続を占有します)。
質問 2 : nginx にはマスターと 4 つのワーカーがあります。各ワーカーは最大 1024 の接続をサポートします。サポートされる同時実行の最大数はどれくらいですか?
- 通常の静的リソースの同時静的アクセスの最大数は次のとおりです:worker_connections *worker_processes /2
  説明: (各ワーカーがサポートする接続の最大数 * ワーカーの合計数) /2
  静的リソースにアクセスする場合、各ワーカーは 2 つの接続を占有します。。
- リバースプロキシとして HTTP を使用する場合、同時実行の最大数は、worker_connections * worker_processes/4 である必要があります。
  説明: (各ワーカーがサポートする接続の最大数 * ワーカーの合計数)/4
  リバースプロキシは tomact を使用するため、各ワーカーは 4 つの接続を占有します。

1. nginxの基本概念

1.1 nginxの概要

1.2 WebサーバーとしてのNginx

1.3 エージェントとは何ですか?

1.3 プロキシサーバー

1.3 フォワードプロキシ

1.4 リバースプロキシ

1.5 負荷分散

1.6 動きと静の分離

2. nginx のインストール、一般的なコマンドと設定ファイル

2.1 liunx システムに nginx をインストールする

2.2 nginxの共通コマンド

2.3 nginx設定ファイル

2.3.1 nginx設定ファイルの場所

2.3.2 設定ファイルの内容

2.3.3 設定ファイル-その3: httpブロックの詳細説明

3. Nginxの各種アプリケーションシナリオの構成

3.1 nginx 構成例 1-リバースプロキシ

3.1.1 リバースプロキシ - 例 1

1) 効果を達成する

2) 準備作業

3) 外部アクセスに開かれたポート

4) Windows システムのブラウザを通じて Tomcat サーバーにアクセスします。

5) アクセスプロセスの分析

6) 具体的な構成

7) 最終テスト

3.1.2 リバースプロキシ - 例 2

1) 効果を達成する

2) 準備作業

3) 具体的な構成

4) 最終テスト

5) 位置指示の説明

3.2 nginx 構成例 2 負荷分散

3.2.1 導入効果

3.2.2 準備

3.2.3 nginx 設定ファイルでロード バランシングを設定する

3.2.4 nginx によるサーバー ポリシーの割り当て

3.3 nginx 構成例 3-動的および静的分離

3.3.1 概念の詳細な説明

3.3.2 準備

3.3.3 具体的な構成

3.3.4 最終テスト

3.4 nginx 構成の高可用性クラスター

3.4.1 nginx の高可用性とは何ですか?

3.4.2 高可用性を構成するための準備

3.4.3 完全な高可用性構成 (マスター/スレーブ構成)

3.4.4 最終テスト

3.4.5 高可用性設定ファイルの詳細説明

3.4.6 スクリプトファイルの詳細説明

4. Nginxの原理

4.1 マスターとワーカーの関係

4.2 労働者の働き方

4.3 1 つのマスターと複数のワーカーの利点は何ですか?

4.4 ワーカーは何人設定するのが適切ですか?

4.5 接続数 worker_connection

おすすめ

3.2.3 nginx 設定ファイルでロードバランシングを設定する

3.2.4 nginx によるサーバーポリシーの割り当て