PowerFlex: Konfiguration av gateway med hög tillgänglighet orsakar 401-fel på REST-klienter

REST API-klienten tar emot "401: Obehöriga" fel när båda Gateway-/Apache-tjänsterna körs.

Ett exempel på REST API-klient är OpenStack cinder. Det här problemet kan göra att vissa ScaleIO-volymåtgärder (map, unmap och så vidare) i OpenStack misslyckas.

För varje 10 lyckade REST API-begäranden misslyckas 1. Den primära Apache-tjänstens mod_jk.log visar till exempel:

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 visar: 

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]

Det här är ett fel i dokumentet. Konfigurationen workers.properties i det här dokumentet innehåller en belastningsutjämningsinställning mellan två Gateway-instanser (Tomcat) och lbfactor är inställd på 10 och 1 för dem. Det innebär att Apache-tjänsten dirigerar inkommande begäranden till de två gatewayerna i förhållandet 10:1. Eftersom REST API-klienten hämtar en token via en gateway och token inte delas mellan gatewayer, misslyckas en begäran som skickas till den andra gatewayen med denna token med 401.

Not: Om en klient hämtar en token från gatewayen med lbfactor 1 är felfrekvensen cirka 91 %.

Lösning
Använd följande workers.properties-fil i stället för filen i dokumentet. Detta ställer in de två gatewayerna i aktivt vänteläge:

** /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

Den här konfigurationen konfigurerar machine2 som primär, worker1 som vänteläge. De viktigaste skillnaderna mellan den här konfigurationen och dokumentet är:

• worker.machine1.activation=disabled

• worker.machine2.redirect=machine1

• worker.machine#.lbfactor=1

Med den här konfigurationen:

• När båda gatewayerna är igång dirigeras alla begäranden till worker2 och det bör inte finnas någon 401.
• När worker2 slutar fungera dirigeras förfrågningarna till worker1. REST-klienten tar emot en 401 och kan logga in igen på REST API-tjänsten och fortsätta.
• När worker2 kommer tillbaka och mod_jk-modulen identifierar det dirigerar den begäranden till worker2 igen och REST-klienten tar emot ytterligare 401 men kan logga in igen på RESET API-tjänsten och fortsätta.

Obs! Båda Apache-tjänsterna måste ha samma konfigurationer i sina workers.properties fil. Apache-tjänsterna är också konfigurerade som en active-standby kluster, av keepalived, och mod_jk modulen i Apache-tjänsten ansvarar för att dirigera REST API-begäranden till Gateway-tjänster, som baseras på ovanstående konfiguration.

Detta är ett dokumentationsfel. Denna KB kan användas innan dokumentet korrigeras.

Keepalive-konfigurationen kan också förbättras eftersom den kanske inte övervakar apache/httpd-tjänster korrekt.

keepalived.conf använder "killall -0 apache2" för "skriptet". Detta returnerar 0 (lyckades) om det finns någon process med "apache2" i namnet, till exempel "tail -f /var/log/apache2/mod_jk.log."

Om du vill övervaka apache2-tjänsten korrekt använder du "systemctl --no-pager status apache2" (Ubuntu) eller "systemctl status httpd" (CentOS/RedHat).

Kommandot som används som "script" måste returnera 0 om apache2/httpd-tjänsten körs, och inte noll om den har stoppats.