Для лиги лени: ничего нового, просто запускаю DiskSPD
Про тестирование и дисков и систем хранении написаны сотни статей, и ничего нового вы тут не увидите, проходите мимо.
Тестирование локальных дисков и систем хранения данных: подводные камни. Часть 2 - виртуализация
Тестирование локальных дисков и систем хранения данных: подводные камни. Часть 3 – цифры и предварительные итоги
Тестирование локальных дисков и систем хранения данных: подводные камни. Часть 4. Ребилд и прочие ситуации «ой пропали диски».
Время тестирования. Оно имеет значение – поскольку речь про Windows, а в нем сама операционная система постоянно что-то кеширует. Прогрев кеша, попадание в него, вот это все – это вроде надо учитывать, но не понятно как.
Размер блоков. С этим интересно – поскольку для механических дисков разметка 512 \ 512e \ 520 \ 528 \ 4096 еще имела какой-то смысл. Для Optane или TLC \ QLC SSD, этот вопрос мне не понятен – все равно все сначала данные попадают в оперативную память SSD модуля.
Нагрузка при расчете parity. Для Storage space контрольные суммы вычисляет процессор, а он вовсе не оптимизирован под такие задачи – так что, используя диски с четностью, учитывайте и нагрузки на CPU.
Тестовые нагрузки при параллельном исполнении – будут исполняться где угодно. Это или баг, или фича планировщика, но планировщик CPU иногда балансирует нагрузку по тестовым потокам крайне странно.
Начну опять снизу. Когда мы создаем дисковый пул, через New-StoragePool, то у нас есть параметры:
LogicalSectorSizeDefault - 512 и 4096
MediaTypeDefault - HDD, SSD, SCM
WriteCacheSizeDefault
AutoWriteCacheSize
Причем последний параметр работает как-то не очевидно.
Следующий не очевидный момент – это работа storage bus cache из статьи Tutorial: Enable storage bus cache with Storage Spaces on standalone servers. Во первых, для storage bus cache нужен ReFS, во вторых: This feature requires your server to have the Failover Clustering feature installed, but your server can't be a part of a Failover Cluster.
Следом мы создаем новый том New-Volume, и уже там определяем
ResiliencySettingName
FileSystem
WriteCacheSize
ReadCacheSize
NumberOfColumns – этот параметр самый интересный, показывает:
Specifies the number of columns to use when creating the volume on a Windows Storage subsystem. Columns represent the number of underlying physical disks across which one stripe of data for a volume is written.
Кажется, что параметров даже слишком много, особенно в части кеширования.
Но не расстраивайтесь, в GUI ничего этого нет.
В остатке после всей пирамиды:
Дисковый пул и сами диски (SAS SSD и SAS NVME), разметка дисков и оперативная память.
Создаваемый поверх пула диск и его кеширование и разметка.
Создаваемый поверх диска том, и его кеширование и разметка.
И это только то, с чем будет работать даже не ОС гипервизора.
Hyper-V – это гипервизор типа 1.5. То есть, существует сам гипервизор, который грузится до загрузки операционной системы, со всеми своими minroot, VMQ, Dynamic VMMQ (d.VMMQ).
И, только после загрузки гипервизора, в первый раздел, грузится Windows Server. Иногда это приводит к комичным ситуациям – управляющая операционная система мертва, а все остальные виртуальные машины работают до перезагрузки. Сам не видел, а коллеги в российском филиале на бета-тесте русской версии ловили. Какой-то статистики набрать не удалось, но помогало удаление всех антивирусов, и переустановка на английскую редакцию. После декабрьских патчей не встречалось.
Отдельные особенности при создании дисков для виртуальных машин.
Командлет New-VHD предлагает параметры:
LogicalSectorSizeBytes
PhysicalSectorSizeBytes
С вариантами 512 и 4096 байт для обоих параметров.
При создании из GUI – диск создается с параметрами по умолчанию, и это не всегда хорошо, потому что создается он с PhysicalSectorSizeBytes = 512 и LogicalSectorSizeBytes = 4096, то есть с разметкой 512е
К чему это приводит? К тому, что гостевая ОС видит этот диск как .. как-то.
И поверх этой разметки делает NTFS, ReFS, EXT3, zFS или ZFS, Btrfs и так далее, со своим размером кластера. Для NTFS - 4KB и далее, в зависимости от размера диска, для Ext3 – 1,2,4 (иногда 8), Ext34 по умолчанию - 4 KiB. И так далее.
Что происходит в цепочке: Блок прилетает на файловую систему гостевой ОС. Гостевая ОС его транслирует в блоки по 512 байт и передает по цепочке ниже. Ниже живут блоки по 4096 байт, и каждый блок надо считать целиком, поменять в нем 512 байт, и записать обратно. Read-Modify-Write в ее лучшем виде.
Но что, если ниже у вас решили создать тома не по 16 терабайт, максимальный размер для NTFS с кластером 4096, а создали сразу на все деньги, все 20 терабайт? Получите блоки по 8 Кб, и не болейте.
Поэтому что надо делать? Смотреть надо, что делаете.
Дальше ситуация будет еще интереснее, потому что Microsoft рекомендует для MS SQL размер кластера в 64к, и такими блоками и будет писать на тот том, где лежит база данных. 64 килобайта, побитые на блоки по 4, побитые на блоки по 512, побитые ..
А, да. Там еще свое кеширование имеется.
Получаем цепочку:
Уровень приложения внутри VM и размер страниц, которыми оперирует приложение.
Файловая система внутри VM
Логическая разметка виртуального тома
Физическая разметка виртуального тома
Файловая система на гипервизоре
Логическая разметка тома на гипервизоре
Физическая разметка тома на гипервизоре
и, если у вас все это еще и по сети – размеры блоков FC, и файловая система на томах, отданных с системы хранения данных. Сдается мне, не от хорошей жизни и ИИ на одном вендоре систем хранения только недавно ушли от лозунга «640 16 Тб должно хватить всем», а на другом вендоре нужно при создании тома выбирать, под что сделана оптимизация тома – раздел Planning Storage Resources, параграф Application Type, с текстом:
Each preset application type has a default application request size, 32 KB for Oracle_OLAP and SQL_Server_OLAP, and 8 KB for the remaining types.
The application type of a LUN cannot be changed after being set.
Inconsistency between LUN application types and actual I/O models may decrease LUN performance.
Наконец-то цифры. Но это не точно
