Для тех, кто еще не знаком с объектным хранилищем данный Swift OpenStack, общая информация о структуре и алгоритмах уже была приведена в нашем блоге: habrahabr.ru/company/mirantis_openstack/blog/176195/, habrahabr.ru/company/mirantis_openstack/blog/176455/.
Если вы уже имеете представление о Swift для OpenStack, то вы знаете, насколько этот проект динамичный и гибкий, постоянно меняющийся и вбирающий в себя только лучшее: шифрование, кодирование с прямой коррекцией ошибок, и другие обновления во многих направлениях разработки. Главной особенностью релиза Swift 1.9.0. является поддержка глобальной кластеризации . Это означает, что он предоставляет возможность распределения одного кластера среди некоторого набора рассредоточенных между собой элементов и связанных сетью с высокой задержкой.
Для того, чтобы увидеть реальное поведение нового свойства, вам потребуются инструменты тестирования, которые смогут достоверно воспроизвести требуемый объем работы. Объектные хранилища данных отличаются от остальных тем, что вместо древесной иерархии для хранения объектов используются невложенные наборы контейнеров и уникальные токены для их нахождения. Итак, для тестирования объектного хранилища данных необходим специальный инструмент — тот, который будет работать с запросами Swift, следуя определенным предписаниям. И тут нам на помощь приходит ssbench и swift-bench — инструменты для тестирования производительности Swift, разработанные SwiftStack.
Итак, с выходом нового релиза появляется необходимость узнать, как нововведения повлияли (регионы — новый уровень в кольце для размещения информации, репликация сети, новые свойства чтения и записи) на производительность.
Оценка новых особенностей
Давайте пробежимся по новым свойствам. Регионы — новый топовый уровень в кольце, группирующий зоны. Более подробно узнать об этой структуре и алгоритме вы можете здесь. Этот уровень поддерживает географическую распределенность кластеров, позволяет класть реплики в многочисленные физические регионы, поддерживая локализацию прокси-сервера (proxy affinity). Проще говоря, прокси-сервер будет в первую очередь использовать локальный регион, а с помощью репликации объекты поступят на остальные регионы.
Инструментарий
Тестирование производительности для одной виртуальной машины с установленной Swift-All-In-One (SAIO) проводилось с помощью swift-bench. Этот инструмент является частью самого проекта и позволяет легко собирать необходимую информацию для стандартной конфигурации. Для тестирования составного кластера использовался ssbench, так как он позволяет задать более специфическую нагрузку. ssbench также является open-sourced проектом, созданным SwiftStack, но при этом не является частью проекта Swift.
Цель
Главной задачей при использовании swift-bench и ssbench было изучение того, как изменения повлияли на среднее количество запросов в секунду, обрабатываемых объектным хранилищем.
Структура
ssbench использует message queue протокол для управления и извлечения информации. Сценарий описывается в файле формата JSON. В зависимости от внесенных конфигураций могут быть проведены разные типы тестирования производительности: нагрузочное, тестирование стабильности и другие.
Рассмотрим пример сценарий, в котором используется 3 класса файлов tiny, small, medium различающиеся по размеру. «initial_files» задает количество файлов определенного типа. «crud_profile» распределяет количество выполняемых операций для каждого запроса в процентах, учитывая что сумма всех значений в crud_profile — это 100% от общего количества операций в «operation_count». Для примера, «crud_profile»: [3, 4, 2, 2] означает что из всего количества запросов, создание объекта займет 27%, чтение — 36%, обновление и удаление — по 18%. Для максимального количества параллельных клиентов «user_count» будет создано количество контейнеров «container_count», в имени которых будет префикс со строкой из «container_base». При этом «container_concurrency» определяет количество клиентов для создания контейнеров.
Рассмотрим пример сценария:
{
«name»: «Medium test scenario»,
«sizes»: [{ # описываем типы файлов
«name»: «tiny»,
«size_min»: 1000, #диапазон размера объекта в байтах
«size_max»: 16000
}, {
«name»: «small»,
«size_min»: 100000,
«size_max»: 200000
}, {
«name»: «medium»,
«size_min»: 1000000,
«size_max»: 2000000
}],
«initial_files»: { #количество объектов заданного типа
«tiny»: 20,
«small»: 20,
«medium»: 2
},
«operation_count»: 100, #количество запросов
«crud_profile»: [3, 4, 2, 2], #распределение запросов среди CREATE, READ, UPDATE и DELETE
«user_count»: 5,
«container_base»: «ssbench»,
«container_count»: 100,
«container_concurrency»: 10
}
ssbench поддерживает авторизацию v 1.0 и v 2.0, что означает, что вы можете его использовать как компонент OpenStack, так и отдельное объектное хранилище.
Результаты
ssbench выдает результаты в двух форматах. Первый вариант — это подробная статистика с информацией по задержке, по обработанному количеству операций в секунду и общее количество обработанных запросов. Второй вариант — CSV таблица для создания гистограмм, содержащая количество запросов, обработанных в каждую секунду.
Далее будет пример отчета ssbench, который был выполнен на виртуальной машине с производительностью:
RAM: 2GB
VCPU: 1
Timing cached reads: 5432.52 MB/sec
Timing buffered disk reads: 57, 91 MB/sec
Методология
Применяя данные инструменты для тестирования производительности, у вас будет возможность оценить разные варианты развертывания объектного хранилища данных Swift и выбрать подходящий именно вам.
Сравнение колец
Итак, если вы хотите посмотреть на результаты при разном наборе регионов, количестве девайсов и копий объектов, мы предлагаем такой вариант:
•Сгрупировать 4 девайса в одном регионе с 4 зонами и 3 репликами
•Сгрупировать 4 девайса в одном регионе с 2 зонами и 3 репликами
•Сгрупировать 4 девайса в одном регионе с 1 зоной и 3 репликами
•Сгрупировать 4 девайса в двух регионах с 4 зонами и 2 репликами
Мы сравнили показатели для релиза Swift 1.9.0 по мере его формирования с конечным мастером:
| commit | name | region | zone | PUTS | GETS | DEL |
| dec517e3497df25cff70f99bd6888739d410d771 | Drop cache after fsync | 1 | 4 | 26.4/s | 107.8 | 32 |
| 13347af64cc976020e343f0fd3767f09e26598de | Merge «Improve swift's keystoneauth ACL support» | 1 | 4 | 35.1 | 116.8 | 32.9 |
| 151313ba8c6612183f6a733edbcbc311b3360949 | master swift 1.9.0 | 1 | 4 | 45.3 | 133.1 | 44.2 |
| 151313ba8c6612183f6a733edbcbc311b3360949 | master swift 1.9.0 | 1 | 2 | 49.1 | 160.3 | 51.3 |
| 151313ba8c6612183f6a733edbcbc311b3360949 | master swift 1.9.0 | 1 | 1 | 42.3 | 175.3 | 40 |
| 151313ba8c6612183f6a733edbcbc311b3360949 | master swift 1.9.0 | 2 | 4 | 54.3 | 109.8 | 49.7 |
Proxy affinity
Сравнение количества выполненных запросов при включении и выключении прокси аффинити:
-Сгруппированы 4 девайса в одном регионе с 4 зонами и 3 репликами
| Disable | Enable | |
| PUTS | 45,3 | 7,2 |
| GETS | 133,1 | 160,3 |
| DEL | 44.2 | 55,2 |
— Сгруппированы 4 девайса в одном регионе с 2 зонами и 3 репликами
| Disable | Enable | |
| PUTS | 49,1 | 3,8 |
| GETS | 160,3 | 157 |
| DEL | 51,3 | 57,8 |
-Сгруппированы 4 девайса в одном регионе с 1 зоной и 3 репликами
| Disable | Enable | |
| PUTS | 42,3 | 55,3 |
| GETS | 175,3 | 160,3 |
| DEL | 40 | 55,2 |
-Сгруппированы 4 девайса в двух регионах с 4 зоной и 2 репликам
| Disable | Enable | |
| PUTS | 54,3 | 3,4 |
| GETS | 109,8 | 136 |
| DEL | 49,7 | 49 |
Как вы заметили, количество обработанных GET запросов возрастает, тогда как PUT падает. Это произошла потому что в настройках прокси для записи были указаны 2 параметра: региона и зона, а значит только 1 девайс будет подходить под это правило. В то время как для чтения был указан только регион, а значит и все девайсы этого региона стали локальными для чтения.
Пропускная способность
Другой метод тестирования производительности — сравнение результатов при увеличении количества рабочих процессов в ssbench. В следующем примере каждый worker создает запросы от 12 user:
Идея такого сценария — постепенное наращивание количества клиентов, до тех пор пока производительность не начнет падать, что означает, что мы достигли предела параллелизации в кластере.
Другие методы
Для оценки результатов на составном кластере, мы разделили 9 девайсов на 3 региона. Один мастер собирает данные по всем worker, запущенных на отдельных хостах и создающие запросы от 20 пользователей. Сценарий содержит такие параметры как: работа со 100 контейнеров, 100 файлов размеров 512 MB.
| ID_run | r1-01 | r1-02 | r1-03 | r2-01 | r2-02 | r2-03 | r3-01 | r3-02 | r3-03 |
| 1 | master | worker | worker | ||||||
| 2 | master | worker | worker | ||||||
| 3 | master | worker | worker | ||||||
| 4 | master | worker | worker | ||||||
| 5 | master | worker | worker | worker | |||||
| 6 | master | worker | worker | worker | |||||
| 7 | master | worker | worker | worker | worker |
Мы использовали такое распределение, что бы собрать информацию по регионам.
•В первом случае используется только локальный регион
•Во втором и третьем используется один нелокальный регион
•В четвертом случае используются два нелокальных региона
•В случаях 5-7 идет увеличение количества worker
На шаге 6 мы сталкиваемся с лимитом кластера и производительность начинает падать.
Заключение
Данное исследование позволяет нам твердо сказать, что релиз Swift 1.9.0 это рывок на встречу увеличения производительности вашего хранилища.
Здесь были представлены некоторые методы тестирования производительности, которыми мы пользуемся для исследования и создания продуктов.
Если вам будет интересно создать свое тестовое окружение, воспользуйтесь следующими ссылками:
•ssbench GitHub: github.com/swiftstack/ssbench
•ssbench SwiftStack blog: swiftstack.com/blog/2013/04/18/openstack-summit-benchmarking-swift/
•Swift 1.9.0 in blog: lists.openstack.org/pipermail/openstack-dev/2013-July/011221.html
•Swift 1.9.0 info: launchpad.net/swift/+milestone/1.9.0
Автор: Mirantis_OpenStack
