PowerFlex: La configuración de la alta disponibilidad de gateway provoca errores 401 en los clientes REST
Summary: El cliente de la API REST recibe "401: "No autorizado" cuando se ejecutan ambos servicios de Gateway/Apache.
Symptoms
El cliente de la API REST recibe "401: "No autorizado" cuando se ejecutan ambos servicios de Gateway/Apache.
Un ejemplo de cliente de API REST es OpenStack Cinder. Este problema puede hacer que ciertas operaciones de volumen de ScaleIO (asignar, anular mapeo, etc.) en OpenStack fallen.
Por cada 10 solicitudes correctas de la API REST, 1 falla. Por ejemplo, el mod_jk.log del servicio Apache primario muestra lo siguiente:
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 muestra lo siguiente:
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 es un error en el documento. La configuración workers.properties de este documento contiene una configuración de balanceo de carga entre dos instancias de Gateway (Tomcat) y el lbfactor se establece en 10 y 1 para ellas. Esto significa que el servicio Apache dirige las solicitudes entrantes a los dos gateways en una proporción de 10:1. Dado que el cliente de la API REST adquiere un token a través de un gateway y los tokens no se comparten entre gateways, una solicitud que se envía al segundo gateway con este token falla con 401.
Nota: Si un cliente adquiere un token de Gateway con lbfactor 1, la tasa de fallas es de aproximadamente el 91 %.
Resolution
Solución alternativa
Utilice el siguiente archivo workers.properties en lugar del archivo del documento. Esto configura las dos gateways en modo activo-en espera:
** /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
Esta configuración configura machine2 como el principal y worker1 como el en espera. Las diferencias clave entre esta configuración y el documento son las siguientes:
-
worker.machine1.activation=disabled
worker.machine2.redirect=machine1
-
worker.machine#.lbfactor=1
lbfactors configuración si no es necesaria para ambos trabajadores.
Con esta configuración:
- Cuando ambas gateways están activas, todas las solicitudes se dirigen a worker2 y no debe haber ningún error 401.
- Cuando worker2 deja de funcionar, las solicitudes se dirigen a worker1. El cliente REST recibe un error 401 y puede volver a iniciar sesión en el servicio de API REST y continuar.
- Cuando worker2 regresa y mod_jk módulo lo detecta, dirige las solicitudes a worker2 nuevamente y el cliente REST recibe otro 401, pero puede iniciar sesión nuevamente en el servicio RESET API y continuar.
Nota: Ambos servicios de Apache deben tener las mismas configuraciones en sus workers.properties de NetWorker. Los servicios de Apache también se configuran como un active-standby clúster, por keepalivedy el mod_jk El módulo en el servicio Apache es responsable de dirigir las solicitudes de API REST a los servicios de gateway, según la configuración anterior.
Este es un error de documentación. Este artículo de la base de conocimientos se puede utilizar antes de que se corrija el documento.
Additional Information
La configuración keepalived también se puede mejorar, ya que es posible que no supervise correctamente los servicios apache/httpd.
keepalived.conf usa "killall -0 apache2" para el "script". Esto devuelve 0 (éxito) si hay algún proceso con "apache2" en el nombre, como "tail -f /var/log/apache2/mod_jk.log."
Para monitorear correctamente el servicio apache2 , utilice "systemctl --no-pager status apache2" (Ubuntu) o "systemctl status httpd" (CentOS/RedHat).
El comando utilizado como "script" debe devolver 0 si el servicio apache2/httpd se está ejecutando, y none-zero, si se ha detenido.