PowerFlex : La configuration haute disponibilité de la passerelle provoque des erreurs 401 sur les clients REST
Summary: Le client API REST reçoit le message « 401 : « Non autorisé » lorsque les deux services Gateway/Apache sont en cours d’exécution.
Symptoms
Le client API REST reçoit le message « 401 : « Non autorisé » lorsque les deux services Gateway/Apache sont en cours d’exécution.
OpenStack Cinder est un exemple de client API REST. Ce problème peut entraîner l’échec de certaines opérations de volume ScaleIO (mappage, annulation du mappage, etc.) dans OpenStack.
Pour 10 demandes d’API REST réussies, 1 échoue. Par exemple, le mod_jk.log du service Apache principal affiche les éléments suivants :
tail -f /var/log/apache2/mod_jk.log | grep ") status"
[6496:139877463439104] [debug] ajp_unmarshal_response::jk_ajp_common.c (739): (machine2) status = 200
[6497:139877295294208] [debug] ajp_unmarshal_response::jk_ajp_common.c (739): (machine2) status = 200
[6497:139877270116096] [debug] ajp_unmarshal_response::jk_ajp_common.c (739): (machine2) status = 200
[6496:139877429868288] [debug] ajp_unmarshal_response::jk_ajp_common.c (739): (machine1) status = 401 <---
[6497:139877219759872] [debug] ajp_unmarshal_response::jk_ajp_common.c (739): (machine2) status = 200
[6496:139877303686912] [debug] ajp_unmarshal_response::jk_ajp_common.c (739): (machine2) status = 200
[6497:139877228152576] [debug] ajp_unmarshal_response::jk_ajp_common.c (739): (machine2) status = 200
/var/log/nova/nova-compute.log shows :
2017-04-05 11:20:36.090 38186 ERROR nova.compute.manager [instance: 20e1036d-daf0-49b9-a228-07a1c48b882d] File "/usr/lib/python2.7/site-packages/os_brick/initiator/connector.py", line 1980, in connect_volume 2017-04-05 11:20:36.090 38186 ERROR nova.compute.manager [instance: 20e1036d-daf0-49b9-a228-07a1c48b882d] self.volume_id = self._get_volume_id() 2017-04-05 11:20:36.090 38186 ERROR nova.compute.manager [instance: 20e1036d-daf0-49b9-a228-07a1c48b882d] File "/usr/lib/python2.7/site-packages/os_brick/initiator/connector.py", line 1879, in _get_volume_id 2017-04-05 11:20:36.090 38186 ERROR nova.compute.manager [instance: 20e1036d-daf0-49b9-a228-07a1c48b882d] raise exception.BrickException(message=msg) 2017-04-05 11:20:36.090 38186 ERROR nova.compute.manager [instance: 20e1036d-daf0-49b9-a228-07a1c48b882d] BrickException: Error getting volume id from name oGXMByctQWesXL8PPKiyBQ==: Unauthorized 2017-04-05 11:20:36.090 38186 ERROR nova.compute.manager [instance: 20e1036d-daf0-49b9-a228-07a1c48b882d]
Cause
Il s’agit d’une erreur dans le document. La configuration workers.properties de ce document contient une configuration d’équilibrage de charge entre deux instances de passerelle (Tomcat), et lbfactor est défini sur 10 et 1 pour ces instances. Cela signifie que le service Apache dirige les demandes entrantes vers les deux passerelles à un taux de 10:1. Étant donné que le client API REST acquiert un jeton via une passerelle et que les jetons ne sont pas partagés entre les passerelles, une demande envoyée à la deuxième passerelle avec ce jeton échoue avec 401.
Note: Si un client acquiert un jeton auprès de la passerelle avec lbfactor 1, le taux d’échec est d’environ 91 %.
Resolution
Solution de contournement
Utilisez le fichier workers.properties suivant à la place du fichier du document. Cela permet de configurer les deux passerelles en mode actif/passif :
** /etc/apache2/workers.properties ***
worker.list=balance1
worker.machine1.type=ajp13
worker.machine1.host=<ip of GW 1>
worker.machine1.port=8009
worker.machine1.lbfactor=1
worker.machine1.activation=disabled
worker.machine2.type=ajp13
worker.machine2.host=<ip of GW 2>
worker.machine2.port=8009
worker.machine2.lbfactor=1
worker.machine2.redirect=machine1
worker.balance1.type=lb
worker.balance1.balance_workers=machine1,machine2
Cette configuration configure machine2 en tant que disque principal, worker1 en tant que disque de secours. Les principales différences entre cette configuration et le document sont les suivantes :
-
worker.machine1.activation=disabled
worker.machine2.redirect=machine1
-
worker.machine#.lbfactor=1
lbfactors Configuration si elle n’est pas nécessaire pour les deux collaborateurs.
Avec cette configuration :
- Lorsque les deux passerelles sont opérationnelles, toutes les demandes sont dirigées vers worker2, et il ne doit pas y avoir de 401.
- Lorsque worker2 tombe en panne, les demandes sont dirigées vers worker1. Le client REST reçoit un signal 401. Il peut se reconnecter au service de l’API REST et continuer.
- Lorsque worker2 revient et que mod_jk module le détecte, il redirige les demandes vers worker2, et le client REST reçoit un autre 401, mais peut se reconnecter au service API RESET et continuer.
Remarque : Les deux services Apache doivent avoir les mêmes configurations dans leur workers.properties . Les services Apache sont également configurés en tant que active-standby grappe, par keepalived, et l' mod_jk Le module du service Apache est chargé de diriger les demandes d’API REST vers les services de passerelle, en fonction de la configuration ci-dessus.
Il s’agit d’une erreur de documentation. Cet article de la base de connaissances peut être utilisé avant la correction du document.
Additional Information
La configuration keepaalive peut également être améliorée, car elle peut ne pas surveiller correctement les services apache/httpd .
Le fichier keepalived.conf utilise « killall -0 apache2 » pour le « script ». Cela renvoie 0 (réussite) s’il existe un processus dont le nom contient « apache2 », tel que «tail -f /var/log/apache2/mod_jk.log."
Pour surveiller correctement le service apache2 , utilisez « systemctl --no-pager status apache2 » (Ubuntu) ou « systemctl status httpd » (CentOS/RedHat).
La commande utilisée en tant que « script » doit retourner 0 si le service apache2/httpd est en cours d’exécution, et none-zero s’il s’est arrêté.