PowerFlex: La configurazione di Gateway High Availability causa errori 401 sui client REST
Summary: Il client API REST riceve il messaggio "401: Non autorizzato" quando entrambi i servizi Gateway/Apache sono in esecuzione.
Symptoms
Il client API REST riceve il messaggio "401: Non autorizzato" quando entrambi i servizi Gateway/Apache sono in esecuzione.
Un esempio di client API REST è OpenStack Cinder. Questo problema potrebbe causare l'esito negativo di alcune operazioni del volume ScaleIO (mappa, annullamento del mapping e così via) in OpenStack.
Per ogni 10 richieste API REST riuscite, 1 ha esito negativo. Ad esempio, la mod_jk.log del servizio Apache primario mostra:
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 mostra:
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
Si tratta di un errore nel documento. La configurazione workers.properties in questo documento contiene un'installazione di bilanciamento del carico tra due istanze di Gateway (Tomcat) e lbfactor è impostato su 10 e 1 per queste. Ciò significa che il servizio Apache indirizza le richieste in entrata ai due gateway con un rapporto 10:1. Poiché il client API REST acquisisce un token tramite un gateway e i token non vengono condivisi tra i gateway, una richiesta inviata al secondo gateway con questo token ha esito negativo con 401.
Nota: Se un client acquisisce un token dal gateway con lbfactor 1, la percentuale di errori è di circa il 91%.
Resolution
Soluzione alternativa
Utilizzare il seguente file workers.properties anziché il file nel documento. In questo modo i due gateway vengono impostati in modalità active-standby:
** /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
Questa configurazione imposta machine2 come primario, worker1 come standby. Le differenze principali tra questa configurazione e il documento sono le seguenti:
-
worker.machine1.activation=disabled
worker.machine2.redirect=machine1
-
worker.machine#.lbfactor=1
lbfactors configurazione se non richiesta per entrambi i ruoli di lavoro.
Con questa configurazione:
- Quando entrambi i gateway sono attivi, tutte le richieste vengono indirizzate a worker2 e non deve essere presente alcun 401.
- Quando worker2 diventa inattivo, le richieste vengono indirizzate a worker1. Il client REST riceve un errore 401 e può accedere nuovamente al servizio API REST e continuare.
- Quando worker2 torna e mod_jk modulo lo rileva, indirizza nuovamente le richieste a worker2 e il client REST riceve un altro 401, ma può accedere nuovamente al servizio API RESET e continuare.
Nota: Entrambi i servizi Apache devono avere le stesse configurazioni nel proprio workers.properties di NetWorker. I servizi Apache sono configurati anche come active-standby cluster, per keepalivedE la mod_jk nel servizio Apache è responsabile dell'indirizzamento delle richieste API REST ai servizi gateway, in base alla configurazione precedente.
Si tratta di un errore di documentazione. Questo articolo della KB può essere utilizzato prima di correggere il documento.
Additional Information
Anche la configurazione di keepalived può essere migliorata in quanto potrebbe non monitorare correttamente i servizi apache/httpd .
Il file keepalived.conf usa "killall -0 apache2" per lo "script". Questo restituisce 0 (successo) se è presente un processo con "apache2" nel nome, ad esempio "tail -f /var/log/apache2/mod_jk.log."
Per monitorare correttamente il servizio apache2 , utilizzare "systemctl --no-pager status apache2" (Ubuntu) o "systemctl status httpd" (CentOS/RedHat).
Il comando usato come "script" deve restituire 0 se il servizio apache2/httpd è in esecuzione, e none-zero, se è stato arrestato.