Openstack широко используется в качестве платформы IaaS с открытым исходным кодом. Служба идентификации Openstack представляет собой компонент, основанный на централизованном подходе с использованием токенов. Она включает Memcached — KV-хранилище в памяти, которое используется для кэширования. Запросы на проверку концентрируются на централизованном сервере по мере увеличения количества токенов, зашифрованных различными способами. В этой статье мы предлагаем сервис идентификации для Openstack, основанный на алгоритме Practical Byzantine Fault Tolerance (PBFT), который может улучшить производительность и снизить число уявимостей за счет применения подхода с использованием PBFT блокчейна.

В ходе эксперимента, проведенного с использованием Apache JMeter, было установлено, что задержка в сервисе идентификации OpenStack на блокчейне PBFT меньше аналогичных показателей стандартного сервиса идентификации OpenStack более чем на 33,99% и 72,57% соответственно при использовании 500 и 1000 различных зашифрованных токенов.

1. Введение

OpenStack представляет собой одну из ведущих открытых платформ инфраструктуры как сервиса (IaaS). Он состоит из нод, с такими ролями как контроллеры и вычислительные узлы. На вычислительных узлах могут быть запущены такие компоненты как Keystone, Nova, Cinder, Neutron и другие компоненты OpenStack. Эти компоненты отвечают за аутентификацию и авторизацию, интегрируются через Keystone, который представляет собой службу идентификации.

Служба идентификации OpenStack - Keystone, представляет собой компонент централизованной архитектуры, предоставляющий возможность идентификации на основе токенов. Это необходимо для обработки запросов на проверку подлинности и авторизацию между компонентами OpenStack. Keystone сохраняет токены в базу данных MySQL, и предоставляет сервис идентификации для API-запросов между сервисами OpenStack используя Memcached - системы кэширования объектов в памяти для кеширования токенов.

Однако Keystone, будучи централизованным компонентом, использующим базу данных в качестве бэкенда, страдает из-за проблемы снижения производительности по мере увеличения количества токенов, сохраненных в централизованном хранилище, а также из-за того, что запросы на проверку токенов для каждого сервиса OpenStack концентрируются на этом хранилище, несмотря на использование Memcached. Memcached представляет собой хранилище для кэширования в памяти, при этом данные теряются при его остановке.

Блокчейн, как децентрализованный подход, может быть использован для создания службы идентификации, содержащей копию данных для обеспечения возможности распределения запросов. Было проведено несколько исследований по аутентификации на основе блокчейна в облачной платформе Интернета вещей (IoT) и по цифровому профилю на основе блокчейна, защищающему личную информацию. Однако до сих пор не проводились исследования по децентрализованному подходу на основе блокчейна в области кеширования и дублирования данных, производительности и безопасности для службы идентификации Openstack, который является платформой IaaS.

Технология может управляться участниками общественных групп, консорциумов/сообществе или быть частным блокчейном. Алгоритм PBFT обеспечивает безопасность, что означает достижение кворума среди узлов с одинаковым весом. Этот алгоритм разработан как асинхронный для обеспечения эффективности транзакций. При этом в некоторой степени страдает доступность, что означает, что кворум должен быть достигнут среди всех узлов при отсутствии проблем. Публичные блокчейны испытывают трудности с эффективными транзакциями из-за перегрузки алгоритма консенсуса.

В этом материале исследуется служба идентификации OpenStack на основе PBFT, построенный на частном блокчейне для обеспечения эффективности транзакций. При этом использовался алгоритм PBFT, разработанный для обеспечения эффективности транзакций. Сервис идентификации на основе PBFT-блокчейна, рассмотренный в данном материале представляет собой PBFT-кеш (PBc) построенный на базе PBFT-фреймворка. Предложенный метод может улучшить производительность службы идентификации OpenStack за счет децентрализации запросов на проверку токенов ко всем пирам PBc-сети. А также это может сократить число уязвимостей т.к. база данных токенов, хранится на всех пирах PBc.

Статья состоит из нескольких частей: в разделе 2 описываются, сравниваются и сопоставляются методы; в разделе 3 представлены экспериментальные конфигурации и результаты, в том числе анализ и обсуждение результатов; и в разделе 4 — заключение.

2. Материалы и методы

2.1. Служба идентификации OpenStack

Компоненты OpenStack отправляют зашифрованный токен в Keystone вместе с запросами на идентификацию. Keystone возвращает расшифрованное значение токена обратно компонентам OpenStack. В этот момент расшифрованное значение токена кэшируется в Memcached сервиса Keystone, и впоследствии оно извлекается из него без необходимости расшифровывания. Схема №1 иллюстрирует процесс работы службы идентификации OpenStack в отношении узла API OpenStack с одним из основных компонентов Openstack - Nova. Рабочая процедура Keystone, являющейся службой идентификации OpenStack, описана в пунктах ⓐ–ⓓ.

ⓐ nova-api на нодеOpenStack получает сообщение с API-запросом от API Gateway.

ⓑ nova-api на вычислительном узле OpenStack устанавливает значение, являющееся зачением заголовка X-Auth-Token доставленного сообщения запроса и преобразует его в SHA-256 в качестве значения ключа. После этого проверяет соответствующее значение ключа в Memcached сервиса Keystone. Если оно существует, токен проверяется с использованием значения, сохраненного в Memcached сервиса Keystone. Если значения ключа нет, процесс переходит к фазе ⓒ.

ⓒ nova-api на ноде OpenStack запрашивает значение X-Auth-Token у Keystone, который является службой идентификации OpenStack. Keystone предоставляет токен для значения X-Auth-Token. Затем nova-api валидирует токен, используя полученный X-Auth-Token, сохраняет хэшированное значение на этапе ⓑ в качестве ключа и полученный X-Auth-Token в качестве значения в Memcached Keystone.

ⓓ После завершения проверки токена сообщение запроса передается в nova-conductor узла контроллера OpenStack и в nova-compute вычислительного узла.

2.2 Служба идентификации OpenStack на основе блокчейна PBFT

2.2.1 Фреймворк блокчейна PBFT

Предложенный в данной работе фреймворк блокчейна PBFT обновляет RocksDB, которая является бекендом для версии 5.17.2 путем форка Hyperledger Fabric 0.6 и реализует фреймворк блокчейна PBFT на языке  Go  версии 1.11.1. Пиры фреймворка блокчейна PBFT состоят из непроверяющих (non-validating peers) пиров, проверяющих (validating peers) пиров и лидера, избранного из числа проверяющих пиров. Проверяющая сеть фреймворка блокчейна PBFT состоит из проверяющих пиpов и лидера. Они участвуют в консенсусе, но исключают непроверяющие пиры, не участвующие в процессе.

Процедуры создания блоков на основе алгоритма PBFT описаны в пунктах ⓐ–ⓓ:

• ⓐ Поступление запросов. После того, как проверяющая сеть получает запросы от клиента, она собирает соответствующие запросы и формирует из них блок (запрос).

• ⓑ Распространение блока. Лидер передает блок проверяющим пиpам (pre-prepare).

• ⓒ Подтверждение получения блока. Пиры информируют других пиpов о получении блока (prepare).

• ⓓ Валидация и фиксация блока. В случае, если более двух третей пиpов получают блок, он валидируется, и результат распространяется среди пиpов (commit).

Можно подтвердить, что путь от пункта ⓐ до пункта ⓓ идентичен процессу создания блока на основе существующего алгоритма PBFT.

2.2.2 Служба идентификации OpenStack на основе блокчейна PBFT

Рисунок 2 показывает архитектуру Службы Идентификации OpenStack на основе блокчейна PBFT относительно PBc-пира узла API, реализованного на основе фреймворка блокчейна PBFT. Он модифицирован для службы идентификации OpenStack c Nova в качестве примера, одного из основных компонентов.

Способ доставки расшифрованного значения токена путем передачи зашифрованного токена в Keystone идентичен. Но есть одно отличие: доставленное значение токена сохраняется в базе данных токенов PBc-пира узла API, а не в Memcached Keystone. Каждый из PBc-пиров в сети пиров синхронизируется с другими. База данных токенов реплицируется среди всех PBc-пиров, что позволяет уменьшить риски в области безопасности.

Рабочие процедуры службы идентификации OpenStack на основе блокчейна PBFT описаны в пунктах ⓐ–ⓓ:

ⓐ Получение запроса. nova-api получает сообщение с API-запросом от API Gateway.

ⓑ Хеширование и проверка в базе данных токенов. nova-api хэширует X-Auth-Token заголовка доставленного сообщения запроса с помощью SHA-256 и использует его как значение ключа. После этого запрашивает соответствующее значение ключа в базе данных токенов PBc-пира на узле API. Если значение существует, токен проверяется с использованием сохраненных данных в собственной базе. Если значения ключа нет, процесс переходит к фазе ⓒ.

ⓒ Запрос к Keystone и валидация токена. nova-api узла API OpenStack запрашивает значение X-Auth-Token у Keystone. Keystone доставляет токен для значения X-Auth-Token. Затем nova-api валидирует токен, используя X-Auth-Token, и сохраняет хэшированное значение на этапе ⓑ как ключ. Полученный X-Auth-Token сохраняется как значение в базе данных токенов PBc-пира на узле API. Это делается вместо сохранения в Memcached Keystone.

ⓓ Передача запроса на выполнение. После завершения проверки токена  сообщение запроса передается в nova-conductor узла контроллера OpenStack и в nova-compute вычислительного узла.

Валидация производится с использованием значения, захэшированного из значения X-Auth-Token как ключа, и значения, доставленного из Keystone. Все запросы проверяют токен таким же образом, как существующая служба идентификации OpenStack.

3. Результаты и обсуждения

3.1 Экспериментальная настройка

В эксперименте использовали контроллер и вычислительный узел, аналогичные реальной среде, с узлом API и генератором нагрузки, работающим с  API-запросами. Это видно из рисунка №3. В узле контроллера настроен HAProxy, служащий API-шлюзом, а также развернуты 4 узла API. Запросы, которые мы создали в ходе эксперимента, распределяются и обрабатываются на 4 узлах API.

Состав аппаратного и программного обеспечения, представленный на рис. 3, показан в таблице 1. Аналогично среде, в которой генерируются реальные запросы, эксперимент проводился путем выборки процедуры работы с токеном, фактически созданной в Nova. Для использования по-разному зашифрованных токенов и генерации различных запросов. На рисунке 4 приведен пример запроса с использованием Nova.

Запрос выполняет операцию с использованием Apache JMeter версии 5.1.1 на генераторе нагрузки. HTTP GET запрос «GET http://controller_Node:8774/v2.1/servers» отправляется на API-шлюз. Порт 8774 HTTP GET запроса используется nova-api. Экспериментальный сценарий описан в пунктах ⓐ–ⓔ.

ⓐ Запросы, созданные с различными зашифрованными токенами, отправляются в узел контроллера, который служит API-шлюзом, с интервалом в 1 секунду.

ⓑ Переданные запросы распространяются на 4 Узла API через HAProxy узла контроллера.

ⓒ Каждый Узел API проверяет зашифрованный токен принятого запроса.

ⓓ Если токен ранее был расшифрован, он используется немедленно. В противном случае запрос на дешифровку токена отправляется в Keystone.

ⓔ Если расшифрованный токен, полученный через Keystone, был подтвержден как корректный, запрос обрабатывается, и затем формируется ответ.

Экспериментальные значения в зависимости от количества используемых токенов для эксперимента представлены в таблице 2.

3.2 Результаты эксперимента

Мы использовали запросы из рисунка №4 и таблицы №1 в количестве 1, 10, 100 и 1 000, как следует из таблицы №2. Результаты эксперимента на 100 000 запросов по аналогичному сценарию представлены на рисунке №5. Черная линия обозначает службу идентификации OpenStack, а красная — службу идентификации OpenStack на основе блокчейна PBFT.

Рисунок №5 подтверждает результаты эксперимента. Разницы в задержке между службой идентификации OpenStack и службой идентификации OpenStack на основе блокчейна PBFT не наблюдалось при количестве различным образом зашифрованных токенов от одного до десяти. Однако служба идентификации OpenStack на основе блокчейна PBFT показала снижение средней задержки примерно на 6% по сравнению с службой идентификации OpenStack при 100 токенах. При 500 токенах средняя задержка службы идентификации OpenStack на основе блокчейна PBFT снизилась примерно на 33,99% по сравнению с службой идентификации OpenStack, а при количестве токенов 1 000 снижение составило примерно 72,57%. Более того, мы подтвердили, что служба идентификации OpenStack на основе блокчейна PBFT обеспечивала низкую задержку и стабильный сервис независимо от количества различным образом расшифрованных токенов. Таблица №3 демонстрирует экспериментальные результаты, отраженные на рисунке №5.

Распределение задержек службы идентификации OpenStack для 100 000 запросов при количестве токенов T = 1 000 показано на рисунке №6. Распределение задержек службы идентификации OpenStack на основе блокчейна PBFT для 100 000 запросов при количестве токенов 1 000 представлено на Рисунке №7. Это может свидетельствовать, что существующая служба идентификации OpenStack показывает распределение задержки примерно 337,66 мс в среднем для 100 000 запросов при количестве различным образом зашифрованных токенов 1 000. Это наглядно продемонстрировано на рисунке №6.

Служба идентификации OpenStack на основе блокчейна PBFT продемонстрировала распределение задержки, аналогичное службе идентификации OpenStack до приблизительно 5 000 запросов из-за процесса дешифровки токенов. Однако после валидации токенов из базы данных каждого PBc-пира распределение задержки составило примерно 92,61 мс в среднем для 100 000 запросов при 1 000 токенах. Удалось подтвердить, что служба идентификации OpenStack на основе блокчейна PBFT снизила среднюю задержку примерно на 72,57% по сравнению со службой идентификации OpenStack, а также продемонстрировала стабильное распределение задержки.

3.3 Анализ результатов

На рисунке №8 показана загрузка CPU на уровне пользователей узлов API 1, 2, 3 и 4 при отправке 100 000 запросов в зависимости от количества токенов.

В случае Узла API 1, который имеет менее производительную конфигурацию, загрузка CPU была выше, чем у Узлов API 2, 3 и 4. Однако при количестве токенов 500 началось снижение, что подтверждает значительное уменьшение загрузки CPU при количестве токенов 1 000. Анализ состояний TCP-сокетов узла контроллера показан на Рисунке №9. Можно считать подтвержденным, что количество сокетов в состоянии TIME_WAIT начало увеличиваться при 100 токенах. Оно выросло примерно на 35 и более в среднем при 500 токенах, а также увеличилось примерно на 70 и более при 1 000 токенах. Для 100 000 запросов рост количества соединений в состоянии TIME_WAIT с увеличением числа различных зашифрованных токенов было вызвано увеличенным временем отклика. Это связано с тем, что запросы на валидацию токенов концентрировались на узле контроллера, являющегося API-шлюзом службы идентификации OpenStack. В результате удалось подтвердить, что задержка резко возросла с увеличением количества токенов: это показано черной линией на Рисунке №5.

На рисунке №10 представлена загрузка процессора узлов API 1, 2, 3 и 4 службы идентификации OpenStack, использующей технологию блокчейн PBFT. Данные были получены в процессе отправки 100 000 запросов. Они зависят от количества различных зашифрованных токенов, указанных в таблице №2.

В случае узла API 1 с непроизводительной конфигурацией мы подтвердили, что его загрузка CPU была выше, чем у Узлов API 2, 3 и 4. Однако узлы 1, 2, 3 и 4 использовали CPU постоянно, независимо от количества токенов. Анализ состояний TCP сокетов узла контроллера показан на рисунке №11. Число соединений TCP в статусе TIME_WAIT начало увеличиваться при 500 токенах, но это был процесс обработки многочисленных запросов (в эксперименте мы сгенерировали до 100 000 запросов). Также удалось подтвердить, что оно увеличилось примерно на 8 при 500 токенах и примерно на 14 при 1 000 токенах.

При отправке 100 000 запросов количество соединений в состоянии TIME_WAIT увеличивалось равномерно, вне зависимости от количества зашифрованных токенов в службе идентификации на основе блокчейна PBFT. Это связано с тем, что обработкой запросов на валидацию токенов занимались PBc-пиры, а не узел контроллера. В результате задержка оставалась стабильной, независимо от количества токенов, что обозначено красной линией на рисунке №5. Обработка запросов проходила без сбоев. Сравнение количества соединений в TIME_WAIT для 100 000 запросов в зависимости от числа токенов между традиционной службой идентификации OpenStack и службой идентификации на базе блокчейна PBFT представлено на рисунке №12.

Средние значения количества TCP-соединений в состоянииTIME_WAIT для службы идентификации OpenStack и службы идентификации на основе блокчейна PBFT представлены на рисунке №12 и суммированы в таблице №4. Сравнение показало, что служба идентификации на базе блокчейна PBFT демонстрирует более стабильное распределение соединений в статусе TIME_WAIT. Благодаря децентрализованному хранилищу данных на основе блокчейна и репликации базы данных токенов между всеми PBc-пирами, а также валидации токенов на каждом узле API, она обеспечивала равномерную обработку запросов в зависимости от количества каждого вида токенов независимо от общего числа.

 4. Заключение

Служба идентификации OpenStack (Keystone) является реализацией централизованного подхода, использующей токены и использующей Memcached для кэширования — хранилища ключ-значения в памяти. Когда количество зашифрованных токенов возрастает, запросы на их проверку концентрируются на центральном сервере. Это приводит к потере данных большого количества токенов в Memcached при перезагрузке. В альтернативной службе идентификации OpenStack на базе блокчейна PBFT база данных токенов хранится на каждом PBc-пире пиринговой сети. Используется децентрализованный подход с синхронизацией между всеми PBc-пирами. Запросы на проверку токенов могут обрабатываться на каждом PBc-пире, кроме первоначального запроса на дешифровку. Это значительно повышает производительность службы за счет распределения нагрузки на все PBc-пиры и снижает риски в области безопасности, поскольку данные токенов хранятся у всех узлов.

Результаты экспериментов с использованием Apache JMeter версии 5.1.1 показали, что задержка запросов снизилась на 33,99% при 500 токенах и на 72,57% при 1 000 токенах. Более того, благодаря репликации базы данных токенов на всех PBc-пирах, риск безопасностизначительно уменьшается. Будущие исследования могут сосредоточиться на дальнейшей оптимизации производительности блокчейн-фреймворка PBFT.

Благодарность

Это исследование было проведено при поддержке Министерства образования, науки и техники Южной Кореи в рамках программы инновационного развития кадров для местной программы поддержки интеллектуализации, курируемой Институтом планирования и оценки информационно-коммуникационных технологий.