» » » Тестирование производительности гиперконвергентных систем и SDS своими руками

 

Тестирование производительности гиперконвергентных систем и SDS своими руками

Автор: admin от 4-02-2018, 16:50, посмотрело: 45

— Штурман, приборы!

— 36!

— Что 36?

— А что приборы?



Примерно так на сегодня выглядит большинство синтетических тестов систем хранения данных. Почему так?



До относительно недавнего времени большинство СХД были плоскими с равномерным доступом. Что это означает?



Общее доступное дисковое пространство было собрано из дисков с одинаковыми характеристиками. Например 300 дисков 15k. И производительность была одинаковой по всему пространству. С появлением технологии многоуровневого хранения, СХД стали неплоскими — производительность различается внутри одного дискового пространства. Причем не просто различается, а еще и непредсказуемо, в зависимости от алгоритмов и возможностей конкретной модели СХД.



И все было бы не так интересно, не появись гиперконвергентные системы с локализацией данных. Помимо неравномерности самого дискового пространства появляется еще и неравномерность доступа к нему — в зависимости от того, на локальных дисках узла лежит одна из копий данных или за ней необходимо обращаться по сети.



Привычные синтетические тесты резко дают маху, цифры от этих нагрузок потеряли практический смысл. Единственный способ всерьез оценить подходит ли система — это пилотная инсталляция с перенесением продуктива. Но что делать, если на перенос продуктива не дает добро безопасность или это просто слишком долго / трудоемко. Есть ли способ оценки?

Nutanix XRay 2.2. Почему CentOS? Был дистрибутив под рукой, можно использовать любой другой Linux по вкусу.



Делаем несколько шаблонов ВМ под разный тип нагрузки.



1. Управляющая FIO — 1 vCPU, 2GB RAM, 20GB OS

2. DB — 1 vCPU, 2GB RAM, 20GB OS, 2*2 GB Log, 4*28 GB Data

3. VDI — 1 vCPU, 2GB RAM, 20GB OS, 10 GB Data



Создаем управляющую FIO. Ставим CentOS в минимальной установке на 20GB диск, остальные не трогаем.



После минимальной установки CentOS ставим FIO

# yum install wget

# wget dl.fedoraproject.org/pub/epel/testing/7/x86_64/Packages/f/fio-3.1-1.el7.x86_64.rpm

# yum install fio-3.1-1.el7.x86_64.rpm



Повторяем то же самое для машин шаблонов нагрузки. И прописываем FIO в автозагрузку на них.

Создаем файл /etc/systemd/system/fio.service



[Unit]
Description=FIO server
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/fio --server
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target


# systemctl daemon-reload

# systemctl enable fio.service

# systemctl start fio.service

# firewall-cmd --zone=public --permanent --add-port=8765/tcp



Инфраструктура готова. Теперь нужна нагрузка.

Создадим список серверов FIO.

10.52.8.2 — 10.52.9.146



Удобно использовать для этого Excel.



Тестирование производительности гиперконвергентных систем и SDS своими руками



Загружаем этот список на управляющую машину. На нее же загружаем конфиг-файлы FIO c нагрузкой.

fio-vdi.cfg



[global]
ioengine=libaio
direct=1
norandommap
time_based
group_reporting
disk_util=0
continue_on_error=all
rate_process=poisson
runtime=3600

[vdi-read]
filename=/dev/sdb
bssplit=8k/90:32k/10,8k/90:32k/10
size=8G
rw=randread
rate_iops=13
iodepth=8
percentage_random=80

[vdi-write]
filename=/dev/sdb
bs=32k
size=2G
offset=8G
rw=randwrite
rate_iops=10
percentage_random=20</code>

[b]fio-oltp.cfg[/b]
<code>[global]
ioengine=libaio
direct=1
time_based
norandommap
group_reporting
disk_util=0
continue_on_error=all
rate_process=poisson
runtime=10000

[db-oltp1]
bssplit=8k/90:32k/10,8k/90:32k/10
size=28G
filename=/dev/sdd
rw=randrw
iodepth=8
rate_iops=500,500

[db-oltp2]
bssplit=8k/90:32k/10,8k/90:32k/10
size=28G
filename=/dev/sde
rw=randrw
iodepth=8
rate_iops=500,500

[db-oltp3]
bssplit=8k/90:32k/10,8k/90:32k/10
size=28G
filename=/dev/sdf
rw=randrw
iodepth=8
rate_iops=500,500

[db-oltp4]
bssplit=8k/90:32k/10,8k/90:32k/10
size=28G
filename=/dev/sdg
rw=randrw
iodepth=8
rate_iops=500,500

[db-log1]
bs=32k
size=2G
filename=/dev/sdb
rw=randwrite
percentage_random=10
iodepth=1
iodepth_batch=1
rate_iops=100

[db-log2]
bs=32k
size=2G
filename=/dev/sdc
rw=randwrite
percentage_random=10
iodepth=1
iodepth_batch=1
rate_iops=100


Запустим FIO в для проверки правильности настроек и первичного прогрева дисков.



На управляющей ВМ



# fio --client vdi.cfg



Минуты через 2-3 можно нажать Ctrl-C, иначе FIO отработает полный цикл из конфига — 2 часа.



Теперь подготовим площадку под массовое развертывание VDI нагрузки. Я создал совершенно непересекающуюся сеть с IPAM — гипервизор AHV перехватывает DHCP и выдает адреса сам.



Тестирование производительности гиперконвергентных систем и SDS своими руками



Поскольку AHV выдает адреса не по порядку, сделаем пул размером ровно под планируемую нагрузку — 400 ВМ (по 100 на хост).



Тестирование производительности гиперконвергентных систем и SDS своими руками



Создаем нагрузочные 400 машин VDI.



Тестирование производительности гиперконвергентных систем и SDS своими руками



Тестирование производительности гиперконвергентных систем и SDS своими руками



В принципе только создание сразу 400 машин уже интересный тест любой системы.

Как у нас справился немолодой уже кластер Nutanix?



Тестирование производительности гиперконвергентных систем и SDS своими руками



2 минуты. Мне кажется, отличный результат.



Теперь включаем машины.



На Nutanix CVM

# acli vm.on fio-vdi-*



Ну и теперь самое время врубить полный газ!

С управляющей FIO

# fio --client vdi.list vdi.cfg



Примерно так ваша СХД будет себя чувствовать под 400 ВМ со средней офисной VDI нагрузкой.



Так же в статье указаны профили для средней OLTP и DSS БД. Их, конечно не по 400, но штук 6-8 можно запустить и попробовать. Например для 8 OLTP и 2 DSS нам потребуется 10 машин из тех, что имеют по 6 дополнительных дисков.



С двух терминалов сразу



1. # fio --client oltp.list fio-oltp.cfg

2. # fio --client dss.list fio-dss.cfg



Казалось бы, все идет хорошо. Каждая система показывает себя неплохо, и ничего не предвещает беды. Сделаем беду сами!



Тестирование производительности гиперконвергентных систем и SDS своими руками



Теперь наблюдаем как под нагрузкой система будет перестраиваться и как это изменит показатели. Особое внимание обратите на «умные» системы, которые откладывают перестроение и восстановление отказоустойчивости на час и более. Не, ну а что такого? А вдруг это ничего страшного нет, подумаешь узел вылетел. Зато на тестах красивые цифры останутся. Если не читать то, что мелким шрифтом в глубинах документации.



Nutanix начинает процесс восстановления автоматически, через 30 секунд после недоступности CVM. Даже если это легитимная операция как например перезагрузка при обновлении.



При помощи подобного нехитрого руководства можно попробовать — а подходит ли вам предлагаемая вендором / интегратором система.



Ну или конечно, вы можете просто скачать Nutanix XRay, которая сделает все это в автоматическом режиме с красивыми графиками для платформ Nutanix AHV и VMware! :)



Отдельная благодарность за помощь r0g3r

Источник: Хабрахабр

Категория: Программирование » Game Development

Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

Добавление комментария

Имя:*
E-Mail:
Комментарий:
Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
Введите два слова, показанных на изображении: *