PowerFlex: Konfiguracja bramy wysokiej dostępności powoduje błędy 401 na klientach REST
Summary: Klient interfejsu API REST otrzymuje komunikat "401: Unauthorized, gdy obie usługi Gateway/Apache są uruchomione.
Symptoms
Klient interfejsu API REST otrzymuje komunikat "401: Unauthorized, gdy obie usługi Gateway/Apache są uruchomione.
Jednym z przykładów klienta REST API jest OpenStack Cinder. Ten problem może spowodować niepowodzenie niektórych operacji woluminów ScaleIO (mapowanie, usuwanie mapowania itd.) w OpenStack.
Każde 10 udanych żądań interfejsu API REST kończy się niepowodzeniem. Na przykład mod_jk.log podstawowej usługi Apache pokazuje:
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 pokazuje:
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
Jest to błąd w dokumencie. Konfiguracja workers.properties w tym dokumencie zawiera konfigurację równoważenia obciążenia między dwoma wystąpieniami bramy (Tomcat), a lbfactor jest ustawiona na 10 i 1 dla nich. Oznacza to, że usługa Apache kieruje żądania przychodzące do dwóch bram w stosunku 10:1. Ponieważ klient interfejsu API REST uzyskuje token za pośrednictwem jednej bramy, a tokeny nie są współużytkowane między bramami, żądanie wysyłane do drugiej bramy z tym tokenem kończy się niepowodzeniem z błędem 401.
Nuta: Jeśli klient uzyska token z bramy z lbfactor 1, wskaźnik awaryjności wynosi około 91%.
Resolution
Obejście problemu
Użyj następującego pliku workers.properties zamiast pliku w dokumencie. Spowoduje to skonfigurowanie dwóch bramek w trybie aktywnego czuwania:
** /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
Ta konfiguracja konfiguruje machine2 jako podstawowy, worker1 jako rezerwowy. Kluczowe różnice między tą konfiguracją a dokumentem są następujące:
-
worker.machine1.activation=disabled
worker.machine2.redirect=machine1
-
worker.machine#.lbfactor=1
lbfactors konfiguracja, jeśli nie jest wymagana dla obu procesów roboczych.
W przypadku tej konfiguracji:
- Gdy obie bramy są włączone, wszystkie żądania są kierowane do worker2 i nie powinno być 401.
- Gdy proces roboczy 2 ulegnie awarii, żądania są kierowane do pracownika 1. Klient REST otrzymuje błąd 401 i może zalogować się ponownie do usługi REST API i kontynuować.
- Gdy element worker2 wróci i mod_jk module go wykryje, ponownie kieruje żądania do worker2, a klient REST otrzyma kolejny błąd 401, ale może zalogować się ponownie do usługi interfejsu API RESET i kontynuować.
Uwaga: Obie usługi Apache muszą mieć takie same konfiguracje w swoich workers.properties programu NetWorker. Usługi Apache są również skonfigurowane jako active-standby klaster, przez keepalived, a także mod_jk w usłudze Apache odpowiada za kierowanie żądań REST API do usług Gateway, czyli w oparciu o powyższą konfigurację.
Jest to błąd w dokumentacji. Z tej bazy wiedzy można korzystać przed korektą dokumentu.
Additional Information
Konfigurację keepalived można również poprawić, ponieważ może ona nie monitorować poprawnie usług apache/httpd.
Plik keepalived.conf używa "killall -0 apache2" dla "skryptu". Zwraca to 0 (sukces), jeśli istnieje jakikolwiek proces z "apache2" w nazwie, taki jak "tail -f /var/log/apache2/mod_jk.log."
Aby poprawnie monitorować usługę apache2 , użyj polecenia "systemctl --no-pager status apache2" (Ubuntu) lub "systemctl status httpd" (CentOS/RedHat).
Polecenie użyte jako "script" musi zwrócić wartość 0, jeśli usługa apache2/httpd jest uruchomiona, i none-zero, jeśli została zatrzymana.