PowerFlex. Настройка высокой доступности шлюза приводит к ошибке 401 на клиентах REST
Summary: Клиент REST API получает сообщение «401: Unauthorized» при запущенных сервисах Gateway/Apache.
Symptoms
Клиент REST API получает сообщение «401: Unauthorized» при запущенных сервисах Gateway/Apache.
Одним из примеров клиента REST API является OpenStack cinder. Эта проблема может привести к сбою некоторых операций тома ScaleIO (map, unmap и т. д.) в OpenStack.
Из каждых 10 успешных запросов API REST 1 завершается сбоем. Например, mod_jk.log службы Primary Apache показывает:
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 показывает:
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
Это ошибка в документе. Конфигурация workers.properties в этом документе содержит настройку балансировки нагрузки между двумя экземплярами шлюза (Tomcat), для которых lbfactor установлено значение 10 и 1. Это означает, что служба Apache направляет входящие запросы на два шлюза в соотношении 10:1. Так как клиент REST API получает маркер через один шлюз, а маркеры не используются шлюзами, запрос, отправленный на второй шлюз с этим маркером, завершается сбоем с кодом 401.
Заметка: Если клиент получает токен от шлюза с lbfactor 1, частота сбоев составляет около 91%.
Resolution
Временное решение
Используйте следующий файл workers.properties вместо файла в документе. При этом два шлюза будут переведены в режим ожидания «активный-резервный»:
** /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
В этой конфигурации machine2 устанавливается в качестве основного, а worker1 в качестве резервного. Основные различия между этой конфигурацией и документом:
-
worker.machine1.activation=disabled
worker.machine2.redirect=machine1
-
worker.machine#.lbfactor=1
lbfactors Установка, если она не требуется для обоих рабочих ролей.
В этой конфигурации:
- Когда оба шлюза работают, все запросы направляются worker2, и не должно быть 401.
- Когда worker2 выходит из строя, запросы направляются worker1. Клиент REST получает код 401 и может снова войти в службу API REST и продолжить работу.
- Когда worker2 возвращается и модуль mod_jk обнаруживает его, он снова направляет запросы worker2, и REST-клиент получает еще один 401, но может снова войти в службу RESET API и продолжить работу.
Примечание. Обе службы Apache должны иметь одинаковые конфигурации в своих workers.properties . Сервисы Apache также настроены как active-standby кластер, по keepalived, а mod_jk module в сервисе Apache отвечает за направление запросов REST API к сервисам шлюза, что основано на вышеуказанной конфигурации.
Это ошибка документации. Эту статью базы знаний можно использовать до исправления документа.
Additional Information
Конфигурация keepalived также может быть улучшена, так как она может неправильно отслеживать службы apache/httpd.
keepalived.conf использует "killall -0 apache2" в качестве "script". Это возвращает 0 (успешно), если есть какой-либо процесс с "apache2" в имени, например "tail -f /var/log/apache2/mod_jk.log."
Для правильного мониторинга службы apache2 используйте команду systemctl --no-pager status apache2" (Ubuntu) или "systemctl status httpd" (CentOS/RedHat).
Команда, используемая в качестве "script", должна возвращать 0, если сервис apache2/httpd запущен, и ненулевое, если он остановлен.