PowerFlex: Setup von Gateway-Hochverfügbarkeit verursacht 401-Fehler auf REST-Clients

Der REST-API-Client empfängt "401: Unauthorized"-Fehler, wenn beide Gateway-/Apache-Services ausgeführt werden.

Ein Beispiel für einen REST API-Client ist OpenStack Cinder. Dieses Problem kann dazu führen, dass bestimmte ScaleIO-Volume-Vorgänge (Zuordnung, Unmap usw.) in OpenStack fehlschlagen.

Von 10 erfolgreichen REST API-Anfragen schlägt 1 fehl. Die mod_jk.log des primären Apache-Dienstes zeigt beispielsweise Folgendes an:

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 zeigt Folgendes an: 

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]

Dies ist ein Fehler im Dokument. Die workers.properties-Konfiguration in diesem Dokument enthält ein Lastenausgleichs-Setup zwischen zwei Gateway (Tomcat)-Instanzen, für die der lb-Faktor auf 10 und 1 festgelegt ist. Das bedeutet, dass der Apache-Service eingehende Anforderungen im Verhältnis 10:1 an die beiden Gateways weiterleitet. Da der REST API-Client ein Token über ein Gateway abruft und Token nicht von Gateways gemeinsam genutzt werden, schlägt eine Anforderung, die mit diesem Token an das zweite Gateway gesendet wird, mit 401 fehl.

Anmerkung: Wenn ein Client ein Token vom Gateway mit dem Faktor 1 abruft, liegt die Fehlerrate bei etwa 91 %.

Problemumgehung
Verwenden Sie die folgende workers.properties-Datei anstelle der Datei im Dokument. Dadurch werden die beiden Gateways im Aktiv-Stand-by-Modus eingerichtet:

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

Diese Konfiguration richtet machine2 als primären und worker1 als Stand-by-Server ein. Die wichtigsten Unterschiede zwischen dieser Konfiguration und dem Dokument sind:

• worker.machine1.activation=disabled

• worker.machine2.redirect=machine1

• worker.machine#.lbfactor=1

Mit dieser Konfiguration:

• Wenn beide Gateways aktiv sind, werden alle Anfragen an worker2 weitergeleitet und es sollte keine 401 vorhanden sein.
• Wenn Worker2 ausfällt, werden die Anforderungen an Worker1 weitergeleitet. Der REST-Client empfängt eine 401 und kann sich erneut beim REST API-Service anmelden und fortfahren.
• Wenn worker2 zurückkommt und mod_jk Modul dies erkennt, leitet es Anforderungen erneut an worker2 weiter, und der REST-Client erhält einen weiteren 401, kann sich aber erneut beim RESET-API-Service anmelden und fortfahren.

Hinweis: Beide Apache-Services müssen die gleichen Konfigurationen in ihren workers.properties zu verwenden. Die Apache-Services sind auch als active-standby Cluster, um keepalivedUnd die mod_jk -Modul im Apache-Dienst ist für die Weiterleitung von REST-API-Anfragen an Gateway-Dienste verantwortlich, die auf der obigen Konfiguration basieren.

Dies ist ein Dokumentationsfehler. Dieser Wissensdatenbank-Artikel kann verwendet werden, bevor das Dokument korrigiert wird.

Die keepalived Konfiguration kann ebenfalls verbessert werden, da sie Apache/httpd-Dienste möglicherweise nicht korrekt überwacht.

Die keepalived.conf verwendet "killall -0 apache2" als "script". Dies gibt 0 (Erfolg) zurück, wenn ein Prozess mit "apache2" im Namen vorhanden ist, z. B. "tail -f /var/log/apache2/mod_jk.log."

Um den apache2-Service korrekt zu überwachen, verwenden Sie "systemctl --no-pager status apache2" (Ubuntu) oder "systemctl status httpd" (CentOS/RedHat).

Der als "script" verwendete Befehl muss 0 zurückgeben, wenn der apache2/httpd-Service ausgeführt wird, und none-zero, wenn er beendet wurde.