Технологія PowerFlex: Налаштування високої доступності шлюзу спричиняє помилку 401 на REST-клієнтах

Клієнт REST API отримує "401: Неавторизована», коли працюють обидві служби Gateway/Apache.

Одним із прикладів клієнта REST API є шлак OpenStack. Ця проблема може спричинити збій певних операцій з об'ємом ScaleIO (map, unmap тощо) в OpenStack.

На кожні 10 успішних запитів REST API 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]

Це помилка в документі. Конфігурація workers.properties у цьому документі містить налаштування балансування навантаження між двома екземплярами Gateway (Tomcat), і для них встановлено lbfactor на 10 та 1. Це означає, що сервіс Apache направляє вхідні запити на два шлюзи у співвідношенні 10:1. Оскільки клієнт REST API отримує токен через один шлюз, а токени не розподіляються між шлюзами, запит, який надсилається до другого шлюзу з цим токеном, не вдається з 401.

Примітка: Якщо клієнт купує токен у шлюзі з lbfactor 1, відсоток відмов становить близько 91%.

Спосіб вирішення
проблемиВикористовуйте наступний файл 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

Ця конфігурація встановлює машину2 як основну, робочу1 як резервну. Ключові відмінності цієї конфігурації від документа полягають у наступному:

• worker.machine1.activation=disabled

• worker.machine2.redirect=machine1

• worker.machine#.lbfactor=1

При такій конфігурації:

• Коли обидва шлюзи запущені, всі запити спрямовуються до worker2, і 401 бути не повинно.
• Коли worker2 опускається, запити спрямовуються до працівника1. Клієнт REST отримує 401, і може знову увійти в сервіс REST API і продовжити.
• Коли worker2 повертається і mod_jk модуль виявляє це, він знову направляє запити до worker2, а клієнт REST отримує ще 401, але може знову увійти в сервіс RESET API і продовжити.

Примітка: Обидва сервіси Apache повинні мати однакові конфігурації у своїх workers.properties файл. Сервіси Apache також налаштовані як active-standby кластер, за keepalived, а також mod_jk модуль в сервісі Apache відповідає за направлення запитів REST API до служб Gateway, що базується на вищенаведеній конфігурації.

Це помилка в документації. Цю базу даних можна використовувати до виправлення документа.

Також можна покращити конфігурацію keepalive, оскільки вона може неправильно контролювати служби apache/httpd.

keepalived.conf використовує "killall -0 apache2" для "скрипту". Це повертає 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 , і none-zero, якщо вона зупинилася.