QUICコンバット（2）AWSはnginx（http3.0）+ upsync + consul（サーバークライアントモード）クラスターを構築します

以前のブログでは、http3をサポートするnginxをコンパイルする方法を紹介し、upsyncモジュールを追加しました。実稼働環境でQUICを検証するために、動的な負荷分散をサポートするようにawsにNginx + upsync + consulクラスターをセットアップしました。

領事紹介

Consulは、HashiCorp（かつてvgrantを開発した）が立ち上げたオープンソースツールです。go言語に基づいて開発され、軽量です。分散システムのサービス検出と構成を実現するために使用されます。
Consulには、KVストレージ、サービスの登録/検出、ヘルスチェック、HTTP + DNS API、WebUIなどの組み込み機能があります。
公式ウェブサイト：https：//www.consul.io/
ここに画像の説明を挿入
アーキテクチャの説明：

Consulクラスターは、Consul Agentノードで構成されています。クラスターには、サーバーとクライアントの2つの役割があります。
サーバーとクライアントは領事の2つの役割にすぎません。2つの役割に違いはありませんが、役割の分割です。
Consul Server：Consulクラスターのステータス情報を維持し、データの整合性を実現するために使用されます。複数のサーバーの中から、Raftプロトコルに基づいてリーダーが選出されます。複数のサーバーノードの領事データ情報は、強力な一貫性を維持します。ローカルエリアネットワーク内のローカルクライアントと通信し、WANを介して他のデータセンターと通信します。
Consul Client：独自の状態のみを維持し、HTTPおよびDNSインターフェース要求をサーバーに転送します。
Consulは複数のデータセンターをサポートしています。各データセンターでは、Consulクラスターのセットを各データセンターにインストールする必要があります。複数のデータセンターは、ゴシッププロトコルに基づいて通信します。

建設計画：

領事サーバーは、Tomcatサーバーの情報を格納します。
領事クライアントは、サーバーでヘルスチェックを実行し、サーバーの
nginx間隔に同期して、最新の領事サーバー構成情報を動的に取得し、nginxが動的な負荷分散を実現できるようにします。

AWSのデプロイプロセス

AWSを使用してインスタンスをデプロイしています。これは、vpcとインスタンスの構築プロセスの簡単な記録でもあります。

1. VPC、サブネット、ゲートウェイ、ルーティングテーブルの作成

VPCを作成し、IPv4CIDRを選択します
4つのサブネット、2つのパブリックサブネットと2つのプライベートサブネット（異なるアベイラビリティーゾーンに-DR用）を作成します：quic-subnet1、quic-subnet2、quic-internal1、quic-internal2
インターネットゲートウェイを作成し、対応するVPCに関連付けます。インターネットゲートウェイのルートをメインルートテーブルに追加してから、メインルートテーブルを対応するパブリックサブネットに関連付けます。
Elastic IPを作成した後、対応するNATゲートウェイ（quic-subnet1上）を作成し、ルーティングテーブル（ルートターゲットはnat）を作成して、プライベートサブネットに関連付けます

2.インスタンスを作成します

セキュリティグループを作成する
1）要塞
ホストが22ポートのSSHアクセスを開く2）nginx-quic
のセキュリティグループ3）tomcatクラスターのセキュリティグループ
4）consul-serverのセキュリティグループ
要塞ホストインスタンスを作成し、エラスティックIPを割り当てます（quic-subnet1上）
quic-nginx-upsync-1、quic-nginx-upsync-2、quic-tomcat-1、consul-server1、consul-server2のインスタンスをそれぞれ作成します
ネットワークロードバランサーとターゲットグループを作成します（quicが使用されているため、ロードバランサープロトコルはTCP_UDPです）

注：AWSが5つのエラスティックIPを申請した後、再度割り当てを申請すると、上限に達するように求められます。以前のエラスティックIPの関連付けを解除して、新しいインスタンスに割り当てる必要があります。

領事クラスターの展開

領事サーバー：172.33.36.48、172.33.63.50（ここでは2つだけ、実際には3サーバー+ 4クライアントをデプロイしました）
領事クライアント（および同じマシン上のTomcat）：172.33.35.141

wget https://releases.hashicorp.com/consul/1.7.5/consul_1.7.5_linux_amd64.zip
## sudo -i 切换到root用户下
unzip consul_0.7.5_linux_amd64.zip

領事サーバー172.33.36.48、172.33.63.50にそれぞれ構成ファイルを書き込みます

{
    "server": true,
    "ui": true,
    "data_dir": "/opt/consul_dir/data",
    "datacenter": "dc1",
    "node_name": "server1",
    "log_level": "info",
    "bind_addr": "172.33.36.48",
    "client_addr": "172.33.36.48",
    "retry_join": ["172.33.36.48","172.33.63.50"]
}

{
    "server": true,
    "ui": true,
    "data_dir": "/opt/consul_dir/data",
    "datacenter": "dc1",
    "node_name": "server2",
    "log_level": "info",
    "bind_addr": "172.33.63.50",
    "client_addr": "172.33.63.50",
    "retry_join": ["172.33.36.48","172.33.63.50"]
}

領事クライアント172.33.35.141に構成ファイルを書き込みます。他のクライアントを構築するときは、構成ファイルのbind_addrとclient_addrを対応するIPに変更するだけです。

{
    "server": false,
    "ui": true,
    "data_dir": "/opt/consul_dir/data",
    "datacenter": "dc1",
    "node_name": "client1",
    "log_level": "info",
    "bind_addr": "172.33.35.141",
    "client_addr": "172.33.35.141",
    "retry_join": ["172.33.36.48","172.33.63.50"],
    "service": {
	"id": "1",
	"name": "quic",
	"address": "172.33.35.141",
	"port": 8080,
        "check": {
          "id": "quic",
          "name": "HTTPAPI on port 8080",
          "http": "http://172.33.35.141:8080/quic/api/checkHealth",
          "interval": "10s",
          "timeout": "1s"
        }
    }
}

起動を容易にするために、2つのシェルスクリプトが記述されています

## consul server的启动脚本
#!/bin/sh
cd /opt
nohup ./consul agent -bootstrap-expect=1 -config-dir=/opt/consul_dir/server.json                        >> /opt/logs/consul.log 2>&1 &

## consul client的启动脚本

#!/bin/sh
cd /opt
nohup ./consul agent -config-dir=/opt/consul_dir/client.json  >> /opt/logs/consul.log 2>&1 &

ポートマッピングを通じて、領事の3つのノードが正常に開始され、リーダーがnginxアップストリームサービス情報を領事に追加するように選出されていることがわかります。
ここに画像の説明を挿入

linuxコマンドを使用してputリクエストを送信できます：
curl -X PUT http://172.33.36.48:8500/v1/kv/upstreams/quic/172.33.35.141:8080

リクエストが正常に送信されると、領事のWebインターフェイスで対応するサーバー情報を確認できます。
ここに画像の説明を挿入

Nginxをデプロイする

以前のブログでは、サーバーにnginxが正常にインストールされました（quicheおよびupsyncモジュールが追加されました）。nginxをインストールディレクトリ/ opt / serverの下にパッケージ化し、awsインスタンスの対応するディレクトリにデプロイするだけです。

最後に、nginxの構成ファイルを変更するだけで
済みます。次の構成ファイルはnginx.confのincludeを介して導入されるため、conf.dの構成ファイルを変更するだけで、元の構成ファイルの変更を回避できます。。

 server {
    
    
     listen       80;
     # nginx服务器的ip地址
     server_name  172.33.17.51;
     location / {
    
    
         root   html;
         index  index.html index.htm;
     }
 }
 include /opt/server/nginx/conf/conf.d/*.conf; 
 # another virtual host using mix of IP-, name-, and port-based configuration

quic.conf

upstream myserver {
    
    
     server 127.0.0.1:11111;
     #超时是6m 间隔是500m
     upsync 172.33.36.48:8500/v1/kv/upstreams/quic upsync_timeout=6m upsync_interval=500ms upsync_type=consul strong_dependency=off;
     upsync 172.33.63.50:8500/v1/kv/upstreams/quic upsync_timeout=6m upsync_interval=500ms upsync_type=consul strong_dependency=off;
	 #从consul拉取的上游服务器后持久化的位置
     upsync_dump_path /opt/data/consul/server.conf;
}

server {
    
    
    # Enable QUIC and HTTP/3.
    listen 443 quic reuseport;
    # Enable HTTP/2 (optional).
    listen 443 ssl http2;
    ssl_certificate /opt/ssl/fullchain.pem;
    ssl_certificate_key /opt/ssl/privkey.pem;
    # Enable all TLS versions (TLSv1.3 is required for QUIC).
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
    # Add Alt-Svc header to negotiate HTTP/3.
    add_header alt-svc 'h3-29=":443"; ma=86400';
    
    location /quic {
    
    
		proxy_pass http://myserver;
    }
}