J'ai une ip load balancing next gen avec:
- un certificat ssl actif
- frontend http port 443 ssl hsts
- backend http port 443 en round robin
- 5 server links port 80 sonde activé ssl désactivé
- 5 serveurs web
La sonde sur la backend est configuré en tcp et tout marche correctement.
Je souhaite passer la sonde en http pour sonder une page index.php dispo sur l'ip des serveurs (http://123.456.789.123) : si php ne marche plus sur mes serveurs pour x raisons, la sonde se mettrait en erreur et le serveur serait sorti des serveurs dispo, ce que je ne peut pas faire avec une sonde tcp.
Quand je mets la sonde en http sur le backend, j'ai direct une erreur 503, alors que la page sondée est dispo sur http://123.456.789.123 et https://123.456.789.123 (sur https avec un certificat auto-signé).
Quelqu'un a deja réussi a configurer quelque chose comme ca ?
C'est pas possible de sonder les serveurs sur le port 80 meme si le backend écoute le port 443 ?
Offres Réseaux - Sonde http IPLB Nextgen
Related questions
- IP LB : Création infra multi DC
7922 
25.12.2017 14:32
- VRACK + proxmox-pfsense = TCP impossible
7724 05.09.2018 15:16
- Routage - Vpn IPsec + vrack + public cloud + serveur dédié
7474 04.06.2017 10:02
- IPLB Graphiques
7184 15.03.2018 17:23
- IP LB NextGen Multi DC
7157 10.02.2017 09:42
- Firewall compatible ipv6
6535 13.03.2017 11:12
- Nbr de règles sur le parefeu OVH
6334 22.11.2019 08:36
- Iplb http 503 pour 100% des requetes
6334 11.01.2018 16:51
- Activer firewall
6257 29.11.2022 08:08
Bonjour,
Le probe HTTP effectue un GET sur la racine du serveur web, et attend un code retour 2XX. Pouvez vous m'indiquer l'ip de votre IP LoadBalancing, afin que de vérifier la configuration de la probe HTTP ?
Concernant le port de monitoring différent du port du serveur, c'est une fonctionnalité en cours de développement, qui sera disponible rapidement.
Bonjour @ArnaudJ
L'IPLB : 137.74.125.187
Un serveur probé : 149.202.217.143
Le serveur sondé renvoi bien 200 mais lorsque je passe en sonde http au lieu de tcp, la sonde le voit en defaut
Rectificatif, la probe HTTP effectue un HEAD et non un GET. Votre serveur nginx met trop de temps à répondre à ce HEAD, votre IP LoadBalancing pense donc que le serveur est indisponible.
@ArnaudJ Quand je fais des requettes sur http://149.202.217.143 du serveur en head, j'ai des reponses en moins de 50ms en http.
En https c'est pareil, mais mon client http me dit qu'il peut pas vérifier l'identité du serveur. Ca doit etre du au fait que le certificat que j'utilise pour répondre sur https://149.202.217.143 est un certificat auto signé je pense.
Comment faire pour valider ce certificat du coté du backend IPLB ?
De mon coté le test dépasse la minute, depuis le réseau OVH et depuis d'autres réseaux :
> curl -X HEAD -s -w "%{time_total}\n" -o /dev/null http://149.202.217.143
> 65.064
@ArnaudJ J'ai modifié mon code pour renvoyer le statut 204, et maintenant la requette curl marche bien.
Par contre en basculant la sonde du backend en http, j'ai bien Error 503: Backend unavailable
```bash
curl -X HEAD -s -w "%{time_total}\n" -o /dev/null https://149.202.217.143
0,069
curl -X HEAD -s -w "%{time_total}\n" -o /dev/null http://149.202.217.143
0,052
```
Effectivement le test est bon en curl, mais je viens de constater que de notre coté le patch pour utiliser le HEAD n'est pas encore en production.
J'ai donc re-activé le check http sur votre backend (vous pouvez le valider par l'API), et j'ai surchargé le paramètre de configuration pour utiliser un GET /, comme votre demande initiale, en attendant que le patch soit prêt de notre coté.
Désolé pour le désagrément occasionné.
@ArnaudJ merci !