Le blog précédent a présenté comment compiler nginx qui prend en charge http3 et ajouté le module upsync. Afin de vérifier QUIC dans un environnement de production, j'ai configuré un cluster Nginx + upsync + consul dans aws pour prendre en charge l'équilibrage de charge dynamique.
introduction du consul
Consul est un outil open source lancé par HashiCorp (qui a développé vgrant). Développé sur la base du langage go et léger, il est utilisé pour réaliser la découverte de services et la configuration de systèmes distribués.
Consul dispose de fonctions intégrées telles que le stockage KV, l'enregistrement / découverte de service, la vérification de l'état, l'API HTTP + DNS et l'interface utilisateur Web.
Site officiel: https://www.consul.io/
Description de l'architecture:
- Le cluster Consul est composé de nœuds Consul Agent. Il existe deux rôles dans le cluster: Serveur et Client.
- Serveur et Client ne sont que deux rôles de Consul, il n'y a pas de différence entre les deux, mais la division des rôles.
- Serveur Consul: utilisé pour conserver les informations d'état du cluster Consul et assurer la cohérence des données. Parmi plusieurs serveurs, un leader est élu sur la base du protocole Raft. Les informations de données de consul sur plusieurs nœuds de serveur maintiennent une forte cohérence. Communiquez avec les clients locaux du réseau local et communiquez avec d'autres centres de données via le WAN.
Consul Client: ne conserve que son propre état et transmet les requêtes d'interface HTTP et DNS au serveur. - Consul prend en charge plusieurs centres de données. Chaque centre de données nécessite l'installation d'un ensemble de clusters Consul dans chaque centre de données. Plusieurs centres de données communiquent selon le protocole de potins.
Plan de construction:
Le serveur consul stocke les informations du serveur tomcat. Le
client consul est chargé d'effectuer les vérifications de l'état du serveur et de se synchroniser avec l'
intervalle nginx du serveur pour obtenir dynamiquement les dernières informations de configuration du serveur consul, afin que nginx puisse réaliser un équilibrage de charge dynamique.
Processus de déploiement AWS
J'utilise AWS pour déployer l'instance, voici également un simple enregistrement du processus de construction du vpc et de l'instance
1. Création de VPC, sous-réseau, passerelle, table de routage
- Créer un VPC, sélectionnez CIDR IPv4
- Créez quatre sous-réseaux, deux sous-réseaux publics et deux sous-réseaux privés (dans différentes zones de disponibilité pour DR): quic-subnet1, quic-subnet2, quic-internal1, quic-internal2
- Créez une passerelle Internet et associez-la au VPC correspondant; ajoutez la route de la passerelle Internet dans la table de routage principale, puis associez la table de routage principale au sous-réseau public correspondant
- Après avoir créé l'ip élastique, créez la passerelle NAT correspondante (sur quic-subnet1), créez la table de routage (la cible de la route est nat) et associez-la au sous-réseau privé
2. Créez une instance
-
Créer un groupe de sécurité
1) L'
hôte bastion ouvre l'accès SSH à 22 ports 2) Le groupe de sécurité de nginx-quic
3) Le groupe de sécurité du cluster tomcat
4) Le groupe de sécurité de consul-server
-
Créez une instance d'hôte bastion et attribuez une adresse IP élastique (sur quic-subnet1)
-
Créer des instances de quic-nginx-upsync-1, quic-nginx-upsync-2, quic-tomcat-1, consul-server1, consul-server2 respectivement
-
Créez un équilibreur de charge réseau et un groupe cible (étant donné que quic est utilisé, le protocole d'équilibrage de charge est TCP_UDP)
Remarque: une fois qu'AWS a demandé 5 adresses IP élastiques, si vous postulez à nouveau pour l'attribution, vous serez invité à atteindre la limite supérieure. Vous devez dissocier les adresses IP élastiques précédentes et les attribuer à la nouvelle instance.
Déploiement du cluster Consul
serveur consul: 172.33.36.48, 172.33.63.50 (ici je n'ai déployé que deux, en fait 3 serveurs + 4 clients)
client consul (et tomcat sur la même machine): 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
Ecrire les fichiers de configuration sur le serveur consul 172.33.36.48, 172.33.63.50 respectivement
{
"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"]
}
Écrivez le fichier de configuration sur le client consul 172.33.35.141. Lors de la construction d'autres clients, modifiez simplement le bind_addr et le client_addr dans le fichier de configuration à l'adresse IP correspondante.
{
"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"
}
}
}
Afin de faciliter le démarrage, deux scripts shell sont écrits
## 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 &
Grâce au mappage de port, vous pouvez voir que les trois nœuds de consul sont démarrés normalement et que le chef est également élu pour
ajouter les informations de service en amont nginx à consul
Nous pouvons utiliser la commande linux pour envoyer une requête put:
curl -X PUT http://172.33.36.48:8500/v1/kv/upstreams/quic/172.33.35.141:8080
Une fois la demande envoyée avec succès, vous pouvez voir les informations de serveur correspondantes sur l'interface Web du consul
Déployer Nginx
Le blog précédent a installé avec succès nginx sur mon serveur (des modules quiche et upsync ont été ajoutés). Empaquetez simplement le nginx sous le répertoire d'installation / opt / server et déployez-le dans le répertoire correspondant de l'instance aws.
Enfin, il suffit de modifier le fichier de configuration de nginx. Les
fichiers de configuration suivants sont introduits via include dans nginx.conf, de sorte que nous n'avons besoin que de modifier le fichier de configuration dans conf.d, afin d'éviter de modifier le fichier de configuration d'origine .
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;
}
}
Ensuite, sbin/nginx -c conf/nginx.conflancez nginx via la commande
Liez le nom de domaine à l'équilibreur de charge correspondant
Enfin, tant que le nom de domaine est lié à l'équilibreur de charge correspondant, nous pouvons accéder à l'API correspondante via le nom de domaine
La vérification du protocole quic pour demander une URL réussie a été écrite dans le blog précédent. Si vous en avez besoin, vous pouvez vous référer au blog
QUIC combat réel (1) Deploy NGINX qui prend en charge HTTP3 via Quiche
Problèmes rencontrés lors du déploiement:
Au début, mon bind_addr et mon client_addr ont écrit 127.0.0.1 et le message d'erreur suivant est apparu en conséquence. Besoin de changer l'adresse IP de bind_addr en IP intranet du serveur consul pour interagir avec d'autres nœuds
Matériel de référence:
Encyclopédie des paramètres de configuration du consul, explication détaillée, résumé