Подготовка к запуску vSAN: мониторинг и тестирование в попугаях.
Подготовка к запуску vSAN: мониторинг и тестирование в попугаях.
Когда знакомые и коллеги готовили первую часть статьи про vSAN, ряд вопросов был пропущен. Частично я восполнил это в отдельной статье про железо, и частично придется дописать.
Оглавление
1. Ссылки на материалы.. 1
2. Что нужно понимать. 2
3. Оптимизация OS + Switch. 3
4.1 О чем я забыл в ходе подготовки - Atto. 3
4.2 О чем я забыл в ходе подготовки – MS DiskSPD.. 4
4.3 О чем я забыл в ходе подготовки – разделение диска. 4
5. Что выяснилось в ходе тестов – по части ПО.. 4
6. Балансировка сетевой нагрузки (MPIO) 5
Route Based on Originating Virtual Port 5
Route Based on Physical NIC Load. 5
LAG/LACP. 5
Network Air Gaps. 6
7. RDMA и наблюдения за нагрузкой. 6
8. Глобальный сбор статистики. 7
9. Мониторинг. 7
1. Ссылки на материалы
Часть текста уже была в статье для другого сайта, когда одна из прошлых работ прикупала СХД
Подбор СХД для себя для начинающих. https://krw.gitbook.io/cb19/e-ekspluataciya/t-testirovanie/podbor-skhd-dlya-sebya-dlya-nachinayushikh.
Тестирование СХД https://krw.gitbook.io/cb19/e-ekspluataciya/t-testirovanie/testirovanie-skhd
Vmark, Planner, Login VSI и вот это все. https://krw.gitbook.io/cb19/virtualizaciya/pereezd-s-fiziki-2-ili-planner
Вторая часть - Intel Server Board S2600 и все вокруг
https://krw.gitbook.io/krw/sbornye-zametki/intel-server-board-s2600-i-vse-vokrug
Прочие материалы -
Enterprise Storage Synthetic Benchmarking Guide and Best Practices. Part 1. General Theory, Methods, and Approaches.
https://nkulikov.com/StorageBenchmarkPart1
Enterprise Storage Synthetic Benchmarking Guide and Best Practices. Part 2. Success Criteria and Benchmarking Parameters.
https://nkulikov.com/StorageBenchmarkPart2
Enterprise Storage Synthetic Benchmarking Guide and Best Practices. Part 3. Practical Illustration based on Benchmarking VMware vSAN Case.
https://nkulikov.com/StorageBenchmarkPart3
VMware HCI Bench и Nutanix XRay
https://habr.com/ru/company/cti/blog/497024/
Как выбрать СХД, не выстрелив себе в ногу
https://habr.com/ru/post/457956/
Understanding VMware ESXi Queuing and the FlashArray
https://www.codyhosterman.com/2017/02/understanding-vmware-esxi-queuing-and-the-flasharray/
IOPS, VDI, IOMETER — Часть 1
https://vgolovatyuk.ru/iops-vdi-iometer-1/
IOPS, VDI, IOMETER — Часть 6
https://vgolovatyuk.ru/iops-vdi-iometer-6/
2. Что нужно понимать
Нужно понимать многое, в частности, что SDS == жесткая привязка к сети. В случае СХД потеря сети = потеря доступа к данным. Вернули сеть – вернулся доступ, до того диски упадут в RO (read-only), система в APD (all path down) – неприятно, но переживаемо. Поймать Split brain без метро – сложно. В случае SDS сеть становится критически важна. Проверяйте отработку обновления / падения / обслуживания сети в ходе тестов и пилотного проекта. Отлаживайте связь с сетевым отделом.
3. Оптимизация OS + Switch
В Windows есть масса ручек и кнопочек, которые можно и нужно покрутить изнутри ОС, для оптимизации буферов. Не просто поставить PVSCSI, но и покрутить реестр. На физических свичах тоже иногда можно покрутить буфера / процесс обработки пакетов, не RDMA единым живы.
Прочитать:
Large-scale workloads with intensive I/O patterns might require queue depths significantly greater than Paravirtual SCSI default values (2053145)
https://kb.vmware.com/s/article/2053145
PVSCSI Controllers and Queue Depth – Accelerating performance for Oracle Workloads
https://blogs.vmware.com/apps/2020/09/pvscsi_queue_oracle_asm_disk.html
4.1 О чем я забыл в ходе подготовки - Atto
Я планировал обзорно-попугайное тестирование на основе Windows + Atto benchmark
https://www.atto.com/disk-benchmark/ , и первый тест так и сделал.
Что оказалось и что могло сэкономить время.
Систему и конфигурацию Atto benchmark можно и нужно было отладить заранее, потому что:
- Далеко не все конфигурации очередей, размера блока и размера файла имеет смысл проверять. Я остановился на размере блока от 4кб до 4 Мб, и очереди 32.
- Atto умеет сохранять конфигурацию «для теста» в пакетный файл, но в текущей (май 2022г) версии есть ошибка – конфигурация с выбранным размером блока сохраняется только после проведения теста. Сам файл конфигурации представляет из себя xml файл и его после сохранения надо поправить руками, или проверить что в нем все хорошо. Нам нужны параметры
<iosize1>4096</iosize1>, <iosize2>4194304</iosize2>, <filesize>34359738368</filesize>
Параметр <pattern>0</pattern> - не описан, а в конфигурации есть.
- Atto сохраняет результаты тестов в своих bmk файлах, внутри которых xml. Для 1-2 тестов эти данные еще можно обработать вручную, но представьте себе 10-20 VM, внутри которых 10-20 результатов теста, да еще в xml, да сделанных в разное время. Пришлось написать скрипт PS (скрипт 1), который брал шаблоны из одной папки, копировал их в другую, запускал Atto с этими шаблонами, ждал пока процессы закончатся, а результаты перегружал в новую папку с именем имя машины_дата. К нему же пришлось написать скрипт (скрипт 2), который эти папки перебирал, проводил сложение и вычитание, а результат выгружал в csv, потому что ставить готовый модуль для выгрузки в xls мне было лень.Только, повторюсь, это был xml, а с ним PS не очень дружит, поэтому мне за написанное стыдно – но оно работает.
4.2 О чем я забыл в ходе подготовки – MS DiskSPD
Вдохновленный статьями выше, я взял в руки MS diskspd
https://github.com/microsoft/diskspd
https://docs.microsoft.com/en-us/azure-stack/hci/manage/diskspd-overview
Он оперирует большим числом параметров, чем Atto – в частности, в нем есть не только очередь и блок, но и число потоков на файл, соотношение чтение/запись
DiskSPD отлично умеет запускаться из командной строки и PS, но ему надо и файлы предварительно создать, и полученную статистику выгрузить в лог-файл с уникальными именами, да и из этих лог-файлов неплохо было бы статистики надергать не руками. Первую задачу я решил (скрипт 3), вторую (скрипт 4) написал и доделываю обработку.
Все это можно было сделать до начала тестов.
4.3 О чем я забыл в ходе подготовки – разделение диска
Как известно, In a hybrid configuration, the cache device is utilized by vSAN as both a read cache (70%) and a write buffer (30%). In an all-flash configuration, 100% of the cache device is dedicated to write buffering.
Understanding vSAN Architecture: Disk Groups
https://blogs.vmware.com/virtualblocks/2019/04/18/vsan-disk-groups/
Поэтому, планируя размеры файлов для тестов, учитывайте разные сценарии, в том числе – сколько у вас будут совокупный кеш и как часто его будет пробивать и почему.
5. Что выяснилось в ходе тестов – по части ПО
Скрипт с Atto, ввиду GUI, запускается в пользовательском контексте (наверное, можно было и посмотреть и cli версию) и проблем с ним не возникло, да и программа тестирования там достаточно короткая (меньше 15 минут). У DiskSPD программа была длинней, и возникла мысль запускать DiskSPD не вручную или скриптом по сети (Enter-PSSession и поехали), а поставить в расписание.
Результаты выполнения того же самого скрипта, но по расписанию - упали вдвое. Почему так – я пока не понял, но тут все просто, Data collector в руки (Collector Sets > right-click User Defined > New > Data Collector Set > Create from a template.) и поехали. Читать:
https://www.sqlshack.com/sql-server-performance-monitoring-data-collector-part-2-set-up-and-usage/
6. Балансировка сетевой нагрузки (MPIO)
У ESXi при работе с FC - все просто – MPIO включено сразу же, осталось только конфигурацию BIOS поправить по руководству - Hardware P-States to Native Mode, Power.CStateMaxLatency – 0, VMW_SATP_ALUA/VMW_PSP_RR , VMW_SATP_DEFAULT_AA/VMW_PSP_RR, ANO (Active not optimal )
https://blogs.vmware.com/vsphere/2012/02/configuration-settings-for-alua-devices.html
и для round robin / io size поставить 1, то есть опять же не забыть прочитать руководство - и в прод:
[root@localhost:~] esxcli storage nmp psp roundrobin deviceconfig set --device=naa.620f17c10076c7a1010c217000000004 --iops=1 --type=iops
Взято тут- Huawei support
Для iSCSI настройка MPIO описана. Для NFS 3– не забывайте страдать, потому что LACP/LAG это всегда больно.
Для vSAN все очень .. странно. Открываем vsan-703-network-design-guide и начинаем читать главу 8 Load Balancing и главу 9 Advanced NIC Teaming.
И что получается:
Route Based on Originating Virtual Port
Все хорошо, но трафик пойдет по одному физическому порту.
Route Based on Physical NIC Load
Все хорошо, кроме того что конфигурация описана на странице 32, а реальные ограничения – 10 страницами ниже, стр 41. -
Since this is a single VMkernel NIC, there is no performance benefit to using Route based on physical load. Only one physical NIC is in use at any time. The other physical NIC is idle. – стр. 41. Что мешало написать это на странице 32?
LAG/LACP
Режим требует настройки со стороны свича, в случае некорректных настроек или рассыпания Multi-Chassis Link Aggregation (MLAG) / Virtual Switching System(VSS) / Multi-Chassis Link Aggregation (MC-LAG) – все перестает работать сразу. Не самый лучший вариант, учитывая что у Cisco Nexus был ряд больных мест. Конфигурация имеет серьезные ограничения «на потом» - см. руководство, Dynamic LACP и Static LACP – Route Based on IP Hash- Note vSAN over RDMA does not support this configuration.
Network Air Gaps
Очень интересный вариант. С одной стороны «не требует конфигурации на свичах», с другой – но если вы хотите по взрослому, то берите 4 карты или 2 по два порта. Собирайте два LAG, а уже два LAG кладите в Air Gaps, иначе возможны проблемы:
Network availability is not guaranteed with multiple vmknics in some asymmetric failures, such as one NIC failure on one host and another NIC failure on another host.
Выглядит это следующим образом: допустим у нас 10 хостов, по 2 сетевых порта. На одном порту vlan 5, на другом vlan 10. Выходит из строя 1 сетевой порт в vlan 5 – пока все нормально, НО обмен данными уже под вопросом. И тут выходит из строя порт в vlan 10 на другом сервере, и все – с точки зрения сети под вопросом весь кластер, оба хоста, поскольку обмен данными идет «все со всеми», а в такой конфигурации сразу начинают валиться ошибки.
То есть - vSAN does not implement port binding. This means that techniques such as multi-pathing are not available.
В балансировкой в этом режиме все очень, очень странно. Он странно описан в документации:
Load-balanced vSAN traffic across physical NICs is not guaranteed.
Но при этом же - Load balancing set to Route based on originating port ID
Термин originating port ID относится к виртуальной машине, но у vSAN нет виртуальной машины, закрепленной как сервис,
Сборка мини стенда не прояснила ничего. Собираем кластер, настраиваем Air gap по руководству, запускаем 3-4 виртуальные машины на хосте – и весь vsan трафик идет через первый интерфейс. Выключение VM, миграция – никакой разницы, все тот же интефейс. Выключаем vSAN на первом интерфейсе, включаем заново – трафик начинает ходить только через второй интерфейс, вне зависимости от состояния машин. Включаем обратно, оставляем, проходит пара часов под нагрузкой– трафик начинает балансироваться.
7. RDMA и наблюдения за нагрузкой
Не знаю, только ли на 7.0 U3 такая проблема, но Vmware из коробки, после включения RDMA на сети – перестает показывать статистику в GUI на сетевых интерфейсах. В vSAN performance часть статистики видна, но сетевая нагрузка не видна совсем. Но в esxtop она есть.
8. Глобальный сбор статистики
Для сбора глобальной статистики нагрузки во время тестов (кстати, это тоже надо было сделать до сборки лаборатории, и уж тем более придется делать на пилоте) необходимо настроить глубину хранения логов внутри VMware vCenter. Систему «как это собирается, классифицируется и хранится» писали люди с сложной судьбой и твердой жизненной позицией, в стране с богатым природным миром – от Gymnopilus liquiritiae до Erythroxylon.
Необходимо прочитать и понять, что и зачем было сделано через Data Collection Levels и как это хранится. После чего настроить согласно руководству и проверить, что настройки применились.
Настройка сбора статистики в VMware
https://vmind.ru/2012/07/16/nastrojka-sbora-statistiki-vmware-vcenter-5/
Data Collection Levels
Configuring Statistics Settings
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vcenter.configuration.doc/GUID-B2F91FDE-F7FC-46C4-91D0-7AD7E4CC87FC.html
9. Мониторинг
Как только мы говорим про мониторинг, тут же возникает мысль про красивые, но бесполезные графики. В моем случае я больше интересовался двумя вопросами – как меня система будет извещать о сбоях, и какая система и как будет мне писать письма заранее, что обратите внимание.
Что у нас есть:
Отправка сообщений из IPMI. Для дисков и каких-то серьезных сбоев годится, для сбора статистики по нагрузке – нет.
Отправка сообщений из Intel® Data Center Manager – наверное есть, но см. выше
Мониторинг самим vCenter – см. выше про глубину сбора логов. Конечно, можно его настроить на отправку событий в почту, а дальше?
К тому же, в нем нет информации по нагрузке на сеть при работе RDMA (или она так спрятана, что я не нашел).
Да, есть штатная статистика - About the vSAN Performance Service
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vsan-monitoring.doc/GUID-2BCD7AE8-7EE4-4258-B730-F8233918765C.html
У нас есть vSAN Performance Monitor
https://flings.vmware.com/vsan-performance-monitor в составе 3 конейнеров - Grafana + Influx + Telegraf
Инструкция к которому, правда, тоже индусами писана. Что в первой части, где «задайте пароль при установке" и ниже «но вообще он admin/vmware”. Что во второй части, где «скачайте и прикрепите корневой сертификат» - при том, что скачивается не сертификат, а zip файл, из которого надо:
вручную взять какой-то файл name.0 из папки Linux,
найти какой из этих сертификатов «корневой» - потому что если у вас, как у нормальных людей, есть корневой совсем корневой (вечно выключенный) и подкорневой subCA – то брать надо второй.
И дальше почитать логи контейнера, что же ему не нравится. В остальном инструкция более-менее сойдет.
Но может у нас есть нормальная система мониторинга, скажем PRTG ?
Не, ничего нет. https://kb.paessler.com/en/topic/85125-monitoring-dell-vxrail-vsan
Zabbix ? Шаблона на vSAN тоже нет, только ручками, через vpoller
https://sites.google.com/site/speccyfan/monitoring/zabbix/zabbix-vmware-datastore
Nagios? Можно конечно что-то найти.
Grafana + Influx + Telegraf + ELK ? Это можно, если вы любите, умеете и практикуете. Выше помянутый vSAN Performance Monitor как раз на первой тройке.
UPD. https://github.com/vmware/vsan-integration-for-prometheus
10. Дописано в последний момент из черновиков
Лимиты тестирования могут упираться в простое flow. Вот у вас миллион пакетов по 4 кбит – это 4 Гигабита трафика, и уже виден предел по реальной пропускной способности 10 гигабитного интерфейса с учетом задержек, интервалов, packet size и так далее. То есть iperf в UDP покажет и больше, а по факту в TCP что будет?
Latency. Сочетание vSAN + очереди – это то, что как раз наглядно показывает рост той самой latency, временами линейно, а временами не очень. В любом случае, любой синтетический тест – это только повод для начала разговора. Нужно понимать, что с одной стороны скорость дисковых операций, разумеется, влияет на реальное приложение, с другой – на приложение влияет еще масса всяких факторов в реальной среде, это и «шумные» соседи, и реальная производительность, и IOwait / Cpu wait / и прочие сочетания соседей, конфигурации VM и нагрузки на хост , и то как настроена, скажем, сама база данных – скажем, что с Memory-Optimized TempDB Metadata in SQL Server 2019
https://www.mssqltips.com/sqlservertip/6230/memoryoptimized-tempdb-metadata-in-sql-server-2019/
И это не говоря про оптимизацию памяти в самом приложении, как скажем резервирование памяти под процедуры в 1с.
Last updated