- Штурман, приборы! — 36! - Сколько 36? - А что с приборами? Примерно так сегодня выглядит большинство синтетических тестов СХД.
Почему это? До сравнительно недавнего времени большинство систем хранения были плоскими и имели единый доступ.
Что это значит? Общее доступное дисковое пространство собиралось из дисков с одинаковыми характеристиками.
Например 300 15к дисков.
И производительность была одинаковой по всему пространству.
С появлением технологии многоуровневого хранения системы хранения стали неплоскими — производительность варьируется в пределах одного и того же дискового пространства.
Причем оно не просто меняется, но и непредсказуемо, в зависимости от алгоритмов и возможностей конкретной модели СХД.
И все было бы не так интересно, если бы не появились гиперконвергентные системы с локализацией данных.
Помимо неравномерности самого дискового пространства, существует еще и неравномерность доступа к нему — в зависимости от того, находится ли одна из копий данных на локальных дисках узла или к ней необходимо обращаться по сети.
Обычные синтетические тесты терпят неудачу; цифры от этих нагрузок потеряли практический смысл.
Единственный способ серьезно оценить пригодность системы – это пилотная установка с передачей продукта.
Но что делать, если передача продукта не одобрена службами безопасности или просто требует слишком много времени/трудозатрат. Есть ли способ оценить? Давайте представим, что мы продуктивная нагрузка и нагрузим весь гиперконвергентный кластер.
Смело вычеркивайте «100% рандом по всему объему» — этот тест не покажет ровным счетом ничего, кроме производительности самых нижних дисков.
Те.
150–300 IOPS на узел (2–4 SATA).
Что для этого требуется? 1. Минимум 1 машина с генератором нагрузки на узел.
2. Загрузите профили рядом с изделием.
Для массовых рабочих нагрузок типа VDI необходимо создать представительное количество машин.
В идеале, конечно, полноценные, но так как большинство демо-систем — это 3-4 ноды, то запускать 3000-4000 ВМ на них конечно нет возможности.
В мои руки попал кластер Nutanix NX-3460G4, но тест применим к любой платформе, доступной на рынке.
Более того, те же тесты можно провести и для классических систем хранения; технология никак не меняется.
В качестве генератора нагрузки я использовал FIO под управлением CentOS 7. Загрузить профили из Нутаникс XRay 2.2 .
Почему CentOS? Под рукой оказался дистрибутив, можно использовать любой другой линукс на свой вкус.
Делаем несколько шаблонов ВМ для разных типов нагрузки.
1. Управление FIO — 1 виртуальный ЦП, 2 ГБ ОЗУ, 20 ГБ ОС.
2. БД — 1 виртуальный ЦП, 2 ГБ ОЗУ, 20 ГБ ОС, 2*2 ГБ журнала, 4*28 ГБ данных.
3. VDI — 1 виртуальный ЦП, 2 ГБ ОЗУ, 20 ГБ ОС, 10 ГБ данных.
Создаем управляющее ФИО.
Устанавливаем CentOS в минимальной установке на диск 20Гб, остальное оставляем в покое.
После минимальной установки CentOS установите FIO. # ням, установи wget # wget dl.fedoraproject.org/pub/epel/testing/7/x86_64/Packages/f/fio-3.1-1.el7.x86_64.rpm # ням установи fio-3.1-1.el7.x86_64.rpm То же самое повторяем и для машин схемы нагрузки.
И прописываем для них ФИО в автозагрузке.
Создать файл /etc/systemd/system/fio.service
# systemctl демон-перезагрузка # systemctl включить fio.service # systemctl запустить fio.service # брандмауэр-cmd --zone=public --permanent --add-port=8765/tcp Инфраструктура готова.[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
Теперь нам нужен груз.
Давайте создадим список серверов FIO.
10.52.8.2 — 10.52.9.146
Для этого удобно использовать Excel. 
Загружаем этот список в управляющую машину.
Также загружаем на него конфигурационные файлы FIO. 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 для проверки правильности настроек и первоначального прогрева дисков.
На управляющей виртуальной машине # фио --клиент vdi.cfg Через 2-3 минуты можно нажать Ctrl-C, иначе FIO выполнит полный цикл из конфига — 2 часа.
Теперь подготовим сайт к массовому развертыванию VDI-нагрузок.
Я создал полностью непересекающуюся сеть с IPAM — гипервизор AHV перехватывает DHCP и сам выдаёт адреса.
Поскольку AHV выдает адреса не по порядку, мы сделаем пул именно такого размера, как запланированная нагрузка — 400 ВМ (по 100 на хост).
Мы создаем машины VDI с нагрузкой 400. 
В принципе, просто создать сразу 400 машин — это уже интересная проверка любой системы.
Как справился с задачей наш уже немолодой кластер Nutanix?
2 минуты.
Я считаю, что это отличный результат. Теперь включаем машины.
На Nutanix CVM # acli vm.on fio-vdi-* Что ж, настало время включить полный газ! С управлением ФИО # 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 Казалось бы, все идет хорошо.
Каждая система работает хорошо, и нет никаких признаков неисправности.
Давайте создадим себе проблемы! 
Теперь посмотрим, как система будет перестраиваться под нагрузкой и как это изменит производительность.
Особое внимание обратите на «умные» системы, которые затягивают перестройку и восстановление отказоустойчивости на час и более.
Нет, но что не так? А что, если в этом нет ничего страшного, просто подумай, что узел развязался.
Но красивые цифры останутся в тестах.
Если вы не читаете мелкий шрифт в глубине документации.
Nutanix начинает процесс восстановления автоматически через 30 секунд после того, как CVM становится недоступным.
Даже если это законная операция, например перезагрузка во время обновления.
Используя это простое руководство, вы можете попытаться понять, подходит ли вам система, предлагаемая поставщиком/интегратором.
Или, конечно, вы можете просто скачать Nutanix XRay, который сделает все это автоматически с красивой графикой для платформ Nutanix AHV и VMware! :) Особая благодарность за вашу помощь r0g3r Теги: #Виртуализация #Системное администрирование #Хранение данных #Облачные вычисления #хранилище #SAN #HCI #fio #Nutanix
-
Подключение Электродвигателя К Arduino
19 Oct, 24 -
"Взлом" Smartdeblur 2.2
19 Oct, 24
