PowerFlex: Oppsett med høy tilgjengelighet for gateway forårsaker 401-feil på REST-klienter
Summary: REST API-klienten mottar "401: Uautorisert" feil når begge Gateway/Apache-tjenestene kjører.
Symptoms
REST API-klienten mottar "401: Uautorisert" feil når begge Gateway/Apache-tjenestene kjører.
Et eksempel på REST API-klient er OpenStack-cinder. Dette problemet kan føre til at visse ScaleIO-volumoperasjoner (map, unmap og så videre) i OpenStack mislykkes.
For hver 10 vellykkede REST API-forespørsler, mislykkes 1. For eksempel viser mod_jk.log til den primære Apache-tjenesten:
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 viser:
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
Dette er en feil i dokumentet. Workers.properties-konfigurasjonen i dette dokumentet inneholder et belastningsbalanserende oppsett mellom to gatewayforekomster (Tomcat), og lbfactor er satt til 10 og 1 for dem. Dette betyr at Apache-tjenesten dirigerer innkommende forespørsler til de to gatewayene i forholdet 10:1. Siden REST API-klienten henter et token via én gateway, og tokener ikke deles mellom gatewayer, mislykkes en forespørsel som sendes til den andre gatewayen med dette tokenet med 401.
Notat: Hvis en klient kjøper et token fra gatewayen med lbfaktor 1, er feilraten omtrent 91 %.
Resolution
Løsning
Bruk følgende workers.properties-fil i stedet for filen i dokumentet. Dette setter opp de to gatewayene i aktiv ventemodus:
** /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
Denne konfigurasjonen konfigurerer maskin2 som primær, arbeider1 som ventemodus. De viktigste forskjellene mellom denne konfigurasjonen og dokumentet er:
-
worker.machine1.activation=disabled
worker.machine2.redirect=machine1
-
worker.machine#.lbfactor=1
lbfactors oppsett hvis det ikke er nødvendig for begge arbeidere.
Med denne konfigurasjonen:
- Når begge gatewayene er oppe, sendes alle forespørsler til worker2, og det skal ikke være noen 401.
- Når arbeider 2 går ned, sendes forespørslene til arbeider1. REST-klienten mottar en 401, og kan logge på REST API-tjenesten på nytt og fortsette.
- Når arbeider2 kommer tilbake og modulen mod_jk oppdager den, sender den forespørsler til arbeider2 på nytt, og REST-klienten mottar ytterligere 401, men kan logge på igjen på RESET API-tjenesten og fortsette.
Merk: Begge Apache-tjenestene må ha de samme konfigurasjonene i workers.properties fil. Apache-tjenestene er også satt opp som en active-standby klynge, etter keepalived, og mod_jk modulen i Apache-tjenesten er ansvarlig for å dirigere REST API-forespørsler til gateway-tjenester, som er basert på konfigurasjonen ovenfor.
Dette er en dokumentasjonsfeil. Denne KB-en kan brukes før dokumentet rettes.
Additional Information
KeepAlived-konfigurasjonen kan også forbedres, da den kanskje ikke overvåker apache/httpd-tjenester riktig.
Keepalived.conf bruker "killall -0 apache2" for "skriptet." Dette returnerer 0 (vellykket) hvis det er en prosess med "apache2" i navnet, for eksempel "tail -f /var/log/apache2/mod_jk.log."
For å overvåke apache2-tjenesten på riktig måte, bruk "systemctl --no-pager status apache2" (Ubuntu), eller "systemctl status httpd" (CentOS / RedHat).
Kommandoen som brukes som "script" må returnere 0 hvis apache2/httpd-tjenesten kjører, og ingen null, hvis den har stoppet.