Про тестирование и дисков, и систем хранении написаны сотни статей, и ничего нового вы тут не увидите, проходите мимо.
Тестирование локальных дисков и систем хранения данных: подводные камни. Часть 1 - общая
Тестирование локальных дисков и систем хранения данных: подводные камни. Часть 2 - виртуализация
Тестирование локальных дисков и систем хранения данных: подводные камни. Часть 3 – цифры и итоги
Зачем я прогнал эти тесты?
Конечно, во славу сатаны и для слез Греты. Одна из систем на текущей работе оперирует с несколькими базами данных – там и MS SQL, и Postgre, и MySQL, и, по моему, где-то был SQL Lite. Объемы небольшие – 25, 30 терабайт на базу. Не было задач для Tibero и Oracle RAC. Firebird на этой работе нет. На Oracle нет денег, на MS SQL еле выбили бюджет.
Система считает кое-какую аналитику, в связи с этим вычитывает из базы, которая еще не data lake или data warehouse, но что-то такое между этим. DWH тоже есть.
Проблема, которую соседи из DBA решают – что так медленно считается. Сейчас отчет генерируется 5-6 часов, это не устраивает бизнес, это не устраивает заказчиков, внутренних и внешних.
Точнее, бизнес это не устраивает настолько, что он был готов выделить большой бюджет с июля (финансовый год начинается 1 июля, если кто-то не в курсе), маленький "прямо сейчас", и выделить (списать) время на тесты.
С чем приходится иметь дело.
Это легаси поверх легаси. Сделано когда-то давно, в 2016-2017 годах, в режиме «надо вчера, берем сначал укропу, потом кошачью жопу». Поэтому, "надо было быстро", был взят MS Hyper-V, а не Broadcom ESXi. И не Nutanix Acropolis, который тоже KVM. Можно было взять Huawei FusionSphere, но не взяли.
Тут кто-то спросит, почему не KVM, не Xen. Хорошо, если не спросит про bhyve. Очевидно, спрашивающий не имеет ни малейшего представления о том, как тупил, и как отставал в развитии ванильный KVM в те годы, особенно под нагрузкой. Да и сейчас не лучше, взять что планировщик, что сбор событий для мониторинга.
Это легаси, и люди, которые это делали, уже уволились. Поэтому всплывает и совершенно очевидное «просто забыли», и не очень очевидное.
На первом месте по оценке дисковой подсистемы, конечно, идут Microsoft DiskSPD и ATTO Disk Benchmark for Windows.
Оба очень неудобны, потому что:
Microsoft DiskSPD хорошо настраивается, воспроизводится, можно немного покодить и сделать хоть пакетное задание, хоть чего, но результаты выгружаются в никак не структурированный текстовый файл. Можно (GPT мне сделал за 5 минут, я бы провозился час) парсер эти логов в csv \ excel, но с xml иметь дело было бы проще.
ATTO Disk Benchmark поддерживает пакетные задания, дает воспроизводимые и вполне совпадающие с DiskSPD результаты, но максимальный размер тестируемого файла – 32 Гб.
На серверах по 1.5 Тб памяти, столько можно закешировать. 1.5 по современным меркам мало, сервера старые. На новых будут брать по 3 Тб, или что-то около того, не помню спецификацию. Я просил 6 Тб, почему-то решили скроить и на этом тоже, или не нашли в продаже модули по 512 Гб не помню. На новых материнских платах по 24 слота памяти. Если ставить модули 256 Гб, те же HPE P07654-B21, можно поставить 6144 Гб.
Очень жаль, что по размерности в сервера не лезут платы расширения типа BC61MRTC Huawei 12 slot memory riser board for huawei fusion server rh5885h v3. PN 03022SPP. Были у коллег такие, очень полезное решение.
Разумеется, есть FIO, и под линуксы я его люблю, не умею, но практикую.
Дальше возникают Nutanix XRay и VDbench \ HCIBench. Первое – оболочка для Fio, второе – имитатор рабочей нагрузки, а мне надо другое, такое как SQLIOSim и, особенно, HammerDB
Проблема со статьями и описаниями.
Проблема в том, что все вокруг забито CEO калом. Может попасться, цитата с одной помойки, причем из копроблога:
В тестирование лучше не лезть, если:
вы хотите с помощью синтетики имитировать поведение сложного приложения (например, базы данных);
Бред написан, хотя откуда там алмазы. Как раз имитация «сложного поведения как получится», это одна из задач нагрузочного тестирования. Вместе с выявлением узких мест по стеку под нагрузкой, как и умение найти, и наблюдать эти места, с нужной частотой и нужной реакцией - To strive, to seek, to find, как говорили древние.
Такого бреда в копроблогах полно. Впрочем, кому-то и GUI над DiskSPD в виде Crystalmark сойдет, а кто-то тестирует скорость путем копирования файла. Это (тестирование копированием) еще не самый плохой вариант, если вы хотите прикинуть скорость копировать.
Прочие проблемные места: Железо на уровне BIOS.
В BIOS современных серверов есть два десятка настроек, отвечающих за скорости, из которых важнейшими для нас являются кино и цирк* «зеленый» режим работы, все эти performance mode, авторазгон, NUMA и C2-C6 state. И, иногда, MWAIT, если вы работаете с виртуализацией. Не стоит забывать и о режиме работы PCIe, особенно если вы используете нормальные современные SSD, включенные через NVME. Как же я скучаю по оптанам, как они работали.
Особенно, если у вас PCIe линий мало, или стоят райзеры во фронт панелях, это придется учитывать.
Прочие проблемные места и выбор нужного железа: power-loss protection.
Просто процитирую: some enterprise drives that should work, is not recognized as devices with power-loss protection, and that means Storage Spaces will only send synchronous writes to the devices, and not use the internal buffer in the device, and that will degrade performance a lot on most drives.
Выбор нужного железа: прошивка.
У Micron выложена «последняя нужная версия прошивки для вашего SSD NVME», и две утилиты – для GUI (убогая) и CLI (топ за свои деньги).
У Kioxa ничего такого не нашел. Утилита есть, узнать про существование случайно взятой KIOXIA CD8P-R Series (2.5-inch) можно, спецификация есть, на странице KIOXIA Ecosystem Member: Vmware (не MS) есть какие-то списки, но чтобы найти, что для Model:KPM6XVUG1T60 есть прошивка 0102, и для KPM6XRUG960G серии PM6 есть прошивка 0102, надо очень постараться.
Список совместимости на Windows Server Catalog сделан плохо, но он хотя бы есть, и в нем:
KIOXIA Corporation, DapuStor Corporation, Huawei Technologies Co., Ltd. (внезапно), Infrasky Solutions – кто это? По маркировке это Intel), primeLine Solutions GmbH, Intel Corporation (с оптанами), Samsung Electronics CO., LTD. (с дисками HPE MZXL515THALA-00H3 MPK76H5Q и похожими), Sandisk Technologies, Inc. , SK Hynix, Western Digital Technologies, Inc.
Размер кластера файловой системы, и выбор между ReFS и NTFS.
ReFS прекрасная система, только работает не то чтобы уж очень экстравагантно, но весьма специфично, тем более для случая с SQL. И есть нюанс, про который ниже.
Режим работы parity для Storage space и storage space direct, плюс кеширование и работа с числом колонок (NumberOfColumns) делают очень, очень больно. Особенно если у вас Allocation Unit Size (FS cluster size) – 4 кб, по умолчанию. А все почему? Потому что я не читал статью Storage Spaces and Slow Parity Performance.
Как же у автора статьи Storage Spaces and Slow Parity Performance все просто. Берем три диска, делаем -Interleave 32KB, делаем 3 колонки, делаем 64Кб NTFS, и готово. Stripe size 96 Кб, data size 64 Кб, 64 Кб записи кладется на два блока данных как 1:1, охапка дров и плов готов.
Вот бы мне перед тестами прочитать про AutoWriteCacheSize и Interleave для New-VirtualDisk.
попробую посчитать:
$ntfs_aus = ($number_of_columns - 1) * $interleave
Но ntfs_aus можно выбрать только из ряда 4,8,16,32,64 – и при этом, поскольку дальше мы идем в виртуализацию с ее vhdx с выбором его выбором LogicalSectorSizeBytes и PhysicalSectorSizeBytes между 512 и 4096, в любом сочетании, и учитывая как с этим Даталайн похлебал двумя руками с Read-Modify-Write.
Для 4 колонок – то есть, 4 дисков, и блока 4к, это будет решением уравнения
4к = (4-1) *х – но 4096 на 3 не очень делится.
Для 6 колонок, соответственно:
4к = (6-1) *х, но 4096 и на 5 не очень делится.
Остается что-то типа
64к = (5-1) *х, и тогда получаем 64/4 – interleave по 16к, NTFS 64k.
Но, оперируя на гипервизоре с NTFS 64k с дисками LogicalSectorSizeBytes \ PhysicalSectorSizeBytes 4096, получим блоки по 4к на диски с разметкой 64к, и привет Read-Modify-Write. Это что, получается надо ставить 5 колонок, и interleave в 1к ? Выглядит дико, как будет работать, если будет работать – не понятно. Про бекапы в таком случае лучше не забывать.
В сегодня лет до меня в очередной раз дошел термин full stripe, что еще раз говорит не только о пользе чтения, но и пользе записи написания текста.
Потому что MS SQL пишет страницы данных – и это 64 Кб. Windows пишет блоками по, кажется, 4 кб. Linux – 8 кб, Postgre вроде тоже 8, но MySQL - 16 KB.
ESXi – 32 Кб (если вы зачем-то отдали диски через iSCSI или NFS).
Внизу все равно физические диски – или очень старые с их 512 \ 512e, или новые, 4k. Причем еще надо посмотреть, что там для SAS SSD и SAS NVME, какая там разметка (если этот термин вообще применим к SSD).
И, наконец, Mirror-accelerated parity, MAP
Чудовищно недооцененный режим работы для storage space и S2D , storage space direct
Идея простая, пишем данные на зеркало, потом в фоновом режиме переносим. Проблема в том, что он плохо документирован, настраивается только из poweshell, дефолтные настройки неудобные и кривые, и в целом командная строка и пресет к нему ориентирован на то, чтобы иметь два дисковых пула, HDD и SSD. Этакий tiering, хотя это он и есть. Сейчас кругом SAS SSD и NVME SSD, но никаких изменений не внесено. Есть и есть, но не развивается.
Но при этом в одной статье пишут про StorageBusCache для MAP, а в другой -
Storage Bus Layer (SBL) cache isn't supported in single server configuration. All flat single storage type configurations (for example all-NVMe or all-SSD) is the only supported storage type for single server.
Вот с этим грузом знаний мы постараемся долететь до второй части.
ETCD Performance and Optimization. Оригинал от Matteo Olivi and Mike Spreitzer утерян где-то в IBM, но остался в виде статьи Storage speed suitable for etcd? Let's ask fio в инернетах.
Оригинал был тут https://www.ibm.com/blogs/bluemix/2019/04/using-fio-to-tell-whether-your-storage-is-fast-enough-for-etcd/. Есть перевод от Фланта - Как с fio проверить диски на достаточную производительность для etcd
Тестирование производительности гиперконвергентных систем и SDS своими руками.
Облако на Microsoft Hyper-V, часть 3: хранилище Storage Spaces в части Read-Modify-Write
Ссылок нет, потому что не хватало еще ссылаться на оптимизационные помойки
SQL Hammer (everything is a nail) . Примечание от рецензента: из РФ ссылка не работает, поэтому начинать лучше тут, github - shutdownhook.
Примечание от рецензента: не раскрыта тема LRC (local reconstruction codes) и Parallel Failure Rebuild
LRC Erasure Coding in Windows Storage Spaces (2013 Storage Developer Conference.) Наконец раскрывают тему Рида, Соломона и Галуа, на странице 21.
* важнейшими для нас являются кино и цирк
Перефраз цитаты Луначарского:
Владимир Ильич несколько раз мне указывал на то, что из всех областей искусств наибольшее государственное значение в настоящий момент может и должно иметь кино
