PowerFlex: A configuração de alta disponibilidade do gateway causa erros 401 em clients REST
Summary: O client da API REST recebe "401: Erro "Unauthorized" quando ambos os serviços Gateway/Apache estão em execução.
Symptoms
O client da API REST recebe "401: Erro "Unauthorized" quando ambos os serviços Gateway/Apache estão em execução.
Um exemplo de client da API REST é o OpenStack Cinder. Esse problema pode fazer com que certas operações de volume do ScaleIO (mapear, desmapear e assim por diante) no OpenStack falhem.
Para cada 10 solicitações bem-sucedidas da API REST, 1 falha. Por exemplo, o mod_jk.log do serviço Apache primário 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
Este é um erro no documento. A configuração worker.properties neste documento contém uma configuração de balanceamento de carga entre duas instâncias de gateway (Tomcat), e o lbfactor é definido como 10 e 1 para elas. Isso significa que o serviço Apache direciona as solicitações recebidas para os dois gateways em uma proporção de 10:1. Como o client da API REST adquire um token por meio de um gateway e os tokens não são compartilhados entre gateways, uma solicitação enviada ao segundo gateway com esse token falha com 401.
Nota: Se um client adquirir um token do gateway com lbfactor 1, a taxa de falha será de cerca de 91%.
Resolution
Solução
alternativaUse o seguinte arquivo worker.properties em vez do arquivo no documento. Isso configura os dois gateways no modo ativo-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
Essa configuração define a máquina2 como a principal, a worker1 como a espera. As principais diferenças entre essa configuração e o documento são:
-
worker.machine1.activation=disabled
worker.machine2.redirect=machine1
-
worker.machine#.lbfactor=1
lbfactors a configuração, caso não seja necessária para ambos os trabalhadores.
Com esta configuração:
- Quando ambos os gateways estão ativos, todas as solicitações são direcionadas para o worker2, e não deve haver 401.
- Quando o worker2 fica inativo, as solicitações são direcionadas ao worker1. O client REST recebe um 401 e pode fazer log-in novamente no serviço da API REST e continuar.
- Quando o worker2 volta e mod_jk módulo o detecta, ele direciona as solicitações para o worker2 novamente, e o client REST recebe outro 401, mas pode fazer login novamente no serviço RESET API e continuar.
Nota: Ambos os serviços Apache devem ter as mesmas configurações em seus workers.properties . Os serviços Apache também são configurados como um active-standby cluster, por keepalived, e o mod_jk módulo no serviço Apache é responsável por direcionar as solicitações da API REST para os serviços de gateway, com base na configuração acima.
Este é um erro de documentação. Este artigo da KB pode ser usado antes que o documento seja corrigido.
Additional Information
A configuração keepalived também pode ser melhorada, pois pode não monitorar os serviços apache/httpd corretamente.
O keepalived.conf usa "killall -0 apache2" para o "script". Isso retorna 0 (sucesso) se houver algum processo com "apache2" no nome, como "tail -f /var/log/apache2/mod_jk.log."
Para monitorar corretamente o serviço apache2 , use "systemctl --no-pager status apache2" (Ubuntu) ou "systemctl status httpd" (CentOS/RedHat).
O comando usado como "script" deve retornar 0 se o serviço apache2/httpd estiver em execução e nenhum zero, se tiver sido interrompido.