Как стать автором
Обновить

Комментарии 9

Спасибо, что поделились полезным опытом! Жалко, что маловато просмотров и совсем нет комментариев, хотя тема, на мой взгляд, интересная и перспективная.

Обратите внимание, что у вас в статье явно закралась ошибка: классический Storage Spaces, что в 2012R2, что в 2016 не умеет работать с SATA и NVMe дисками — только (NL-)SAS. Эта фича появляется только в Storage Spaces Direct, так что лучше исправить текст, дабы не вводить людей в заблуждение.

Сейчас у себя в компании тестируем S2D, правда на относительно старом оборудовании и с 10 gbe сетью без поддержки RDMA — пока не удаётся заставить работать систему с нормальной скоростью при использовании SSD дисков в качестве кэша и со стабильно высокой скоростью при использовании горячего/холодного тира и ReFS.

Интересно почитать, какие у вас возникли трудности при тестировании S2D и как вы с ними боролись. Подписался на блог, жду новых статей :)
PSVITAmins, спасибо за комментарий и интерес к статье.

NVM-диски, действительно не поддерживаются Storage Spaces, но о них мы и не говорим. А с SATA-дисками Storage Spaces работать умеет :-)

Желаем удачи с тестированием S2D. Своими результатами обязательно поделимся в блоге, следите за новостями.
Да, я не совсем правильно выразился: разумеется Storage Spaces поддерживает SATA-диски, но не в варианте Scale-Out файлового сервера, когда одной или несколькими JBOD-полками управляют 2 и более контроллеров. JBOD-полка должна быть именно SAS`овская и никак иначе. Если сервер один и SS используется в качестве простого «программного RAID`а», то да, диски могут быть любыми. Ссылка на технет: https://technet.microsoft.com/en-us/library/hh831739(v=ws.11).aspx
После получения практического опыта, было бы интересно услышать сравнение с vSAN и Starwind, Datacore.
Ну и приглашаю вас помочь в заполнении сравнения SDS продуктов. Думаю многим будет интересно.
Очень много вопросов возникает по поводу найденной вами проблемы и методики тестирования.
Проблема, с которой мы столкнулись, – низкая скорость обработки данных. Показатели записи SSD-дисков не превышали 100 Мбит/сек, что в 10 раз ниже необходимых для нормальной производительности. Проблема появилась сразу же при развертывании ВМ из шаблона: одна ВМ размером 10 Гб разворачивалась 30–40 минут, развертывание двух ВМ занимало порядка двух часов.

Уже тут вопрос — как разворачивали? Если через WDS изнутри виртуальной машины, то не в эмулируемый ли сетевой адаптер упёрлись? Если же просто шло копирование файла .vhdx из библиотеки (например, средствами SCVMM), то к чему вся дальнейшая теория о том, как диск виден изнутри виртуальной машины?

Подозрение пало на прошивку дисков: дефолтная не поддерживала одновременный доступ с разных нод кластера. После обновления прошивки развертывание нескольких ВМ перестало приводить к такому сильному падению производительности. Однако все происходило по-прежнему долго.

Если не секрет, что за модель SSD? И что за прошивка такая «дефолтная»? Заводская при наличии у производителя обновлённой? То есть вы строили систему, не обновив предварительно все прошивки до текущих? Не говоря уже о проблемах старых прошивок как таковых, вас техподдержка Dell бы завернула, случись что, попросив сначала обновить прошивку, а потом приходить. Если с остальными компонентами та же проблема, то всё исследование нужно начинать сначала.

Что до одновременного доступа с разных узлов кластера, как именно это влияло на производительность при развёртывании одной-двух машин? Даже если был redirected I/O с одного из узлов, такого падения быть не должно было на 40-гигабитной сети, а уж реально задействовать балансировку нагрузки на SoFS в вашей задаче можно только в очень специфическом случае: одновременное копирование двух .vhdx на два отдельных CSV, каждый из которых покрывает все условные «шпиндели» системы.

Cluster Validation Wizard что говорил по поводу дисковой подсистемы?

Схема взаимодействия. Физический сектор учитывается только на уровне контроллера жесткого диска.

Схема неверна. В верхней части должно быть:
Virtual Disk 512e (512/4096) — диски виртуальных машин

Виртуальные машины видят .vhdx диски, созданные с параметрами по умолчанию, как 512e и соответственно оптимизируют запись. Старые .vhd диски по умолчанию эмулируют 512n.

Вот как выглядит .vhdx файл:
> get-vhd… |fl *sector*
LogicalSectorSize: 512
PhysicalSectorSize: 4096

А вот вид изнутри виртуальной машины:
> get-disk|fl *sector*
LogicalSectorSize: 512
PhysicalSectorSize: 4096


Кстати, что после всех изменений показывают ваши виртуальные машины? Если вы не пересоздавали все .vhdx с ручным указанием размера физического сектора, то они всё так же считают, что у них физический сектор 4kB и производят RMW при записи одиночных 512 байт.

Это привело к выполнению политики Read-Modify-Write: чтение сектора 4К в кэш, правка необходимых 512 байт, запись 4К обратно на диск. Как следствие, к катастрофическому падению производительности дисковой подсистемы во время записи в 8 раз.

Не совсем понятно, как такое может произойти на реальной нагрузке.

Первый вопрос: откуда возьмутся случайные 512-байтовые записи (кроме специально настроенного синтетического теста)? Начиная с Windows Server 2012 все структуры .vhdx выровнены по 4kB (именно поэтому они и представляются виртуальной машине по умолчанию как 512e, а vhd представлялись как 512n). Операционная система внутри VM знает, что физический сектор — 4kB. NTFS использует кластер минимум 4kB. Файлы, как правило, много больше 4kB. Даже SQL Server получает от системы информацию, что физический сектор — 4kB и выравнивает запись по границе 4kB.

Если идёт запись блока большого размера, он передаётся вниз через подсистемы ввода-вывода блоками до 64kB. Такие примерно блоки и отсылаются в самый низ — на физические носители, плюс NCQ позволяет ещё более оптимизировать запись.
Чтобы в этом убедиться, достаточно для CSV посмотреть в Performance Monitor следующую метрику: Physical Disk -> Avg. Disk Bytes/Write. К сожалению, она высчитывает среднее арифметическое, включая в него и 0 при простое, но чем ближе загрузка к 100%, тем более отчётливо показатель приближается к 64kB.

Вообще говоря, физический сектор размером 4kB это условная, фальшивая цифра для SSD: реально минимальный блок перезаписи на SSD может достигать нескольких мегабайт, потому все контроллеры внутри используют что-то вроде WAFL и 3.5kB дополнительных данных их ничуть не затормозят.

Таким образом, для того, чтобы вызвать RMW в виртуальной машине, нужно записать одиночные 512 байт, и ничего вокруг не писать, иначе, при последовательной записи, максимум произойдут RMW операции для первого и последнего физического сектора, и то, при условии ошибки выравнивания, которые может только само приложение создать, так как и файловая система, и .vhdx выровнены по границе 4kB или больше. Более того, данный физический сектор не должен быть нигде закэширован, то есть виртуальная машина не должна была его до этого читать. Честно говоря, мне сложно представить нагрузку, при которой эти дополнительные операции как-либо заметно ухудшат производительность.

В таблице ниже показаны значения скорости до и после внедрения этого решения. В случае “после” проверка проводилась одновременным запуском тестирования DiskSpd на 15 виртуальных машинах.

Хотелось бы увидеть подробности методики тестирования. Настораживает уже сама формулировка, которая подразумевает, что тестирование «до» и «после» проводилось по различным методикам.
Были ли виртуальные диски, на которых производилось тестирование, pinned к hot tier? Что показывал непосредственно перед тестированием Get-FileStorageTier для этих файлов? Если они не были принудительно помещены (с обязательной оптимизацией после Set-FileStorageTier) в hot tier, то тестировалась «погода на Марсе» — во время первого и второго тестирования они могли быть полностью или частично в hot или cold tier, да ещё влияние оказывало соотношение объёма Storage Spaces Write Cache (по умолчанию — 1GB) с объёмом записываемой информации, а также скорость пополнения Storage Spaces Write Cache и скорости его сброса. Ну и, конечно же, настройки тестирования — если тестировалась случайная запись 512-байтовыми блоками при отключенном кэше, то такой нереальный access pattern мог немного просадить производительность. Но даже при таких настройках что-то не верится в 8-кратную разницу. Намного больше похоже на 8-кратную разницу (возможно, несколько сглаженную кэшем) между скоростью доступа к данным, лежавшим в cold tier и данным, перемещённым в hot tier после того, как их только что туда-сюда скопировали.

Не обижайтесь, но заявления вида «инженеры Microsoft, разработавшие новую систему и протестировавшие её перед релизом сверху донизу, а также все, кто не первый год её эксплуатируют, ошиблись, а я, первый раз взяв её в эксплуатацию, сразу нашёл ошибку и сам её исправил» воспринимаются с очень большой долей скептицизма. Нужно очень тщательно обосновать свои выводы.

В интернете я нашёл только одну статью с аналогичной вашей проблемой, в комментариях к которой пишут, что воспроизвести её не смогли.

В в Microsoft обращались? Они подтвердили ваши выводы?
Виталий, я тоже подтверждаю результаты, которые получились у инженеров Dataline, хотя в нашем случае разница была не столь значительная: SSD Tier, VHDX созданный со секторами по умолчанию — порядка 300 Мбайт/с на запись в тесте diskspd, после создания нового VHDX с секторами 512/512 — порядка 1200 МБайт/с в таком же тесте. К сожалению, сейчас не могу воспроизвести всё повторно и показать повторные логи, но на неделе может быть получится, если это действительно вызывает такие сомнения.

Также об этой проблеме очень часто упоминает Алексей Кибкало на своих курсах по Hyper-V, системах хранения, кластеризации и не только.
Подождите, это разные вещи: вы переделали .vhdx в эмуляцию 512n. В такой конфигурации RMW если и будет, то внутри SSD. Автор же просто перенёс образы туда и обратно, пересоздав volume, об изменении размера эмулируемого физического сектора речь не шла.

И раз уж вы говорите о «таком же тесте», не могли бы вы показать настройки теста (и подтвердить, что тестируемые файлы были «Completely on tier» перед тестом)? Как я писал выше, случайная 512-байтовая запись с отключенным кэшем, действительно, должна показывать снижение скорости записи на диски 512e, но это нереалистичный pattern нагрузки.
VitalKoshalew, параметры теста брались из статьи на технете, размер блока 8К:

c:\diskspd\amd64fre\diskspd.exe -r -w30 -d600 -W300 -b8K -t8 –o15 -h -L -Z1M -c64G C:\test1.dat


Не буду утверждать, что я точно прав и тестировал всё по фэн-шую, если получится перепроверить и поделиться развёрнутым и аргументированным результатом — обязательно это сделаю. Было это уже больше полугода назад, возможно ещё пришлось поменять размер блока на самом CSV-томе, не только на VHDX файле. Сделать новый том с дефолтными настройками боюсь уже не смогу — весь объём отдан под рабочую нагрузку.
VitalKoshalew, отвечаем на вопросы в данной ветке комментариев.

Уже тут вопрос — как разворачивали? Если через WDS изнутри виртуальной машины, то не в эмулируемый ли сетевой адаптер упёрлись? Если же просто шло копирование файла .vhdx из библиотеки (например, средствами SCVMM), то к чему вся дальнейшая теория о том, как диск виден изнутри виртуальной машины?

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

Если не секрет, что за модель SSD? И что за прошивка такая «дефолтная»? Заводская при наличии у производителя обновлённой? То есть вы строили систему, не обновив предварительно все прошивки до текущих? Не говоря уже о проблемах старых прошивок как таковых, вас техподдержка Dell бы завернула, случись что, попросив сначала обновить прошивку, а потом приходить. Если с остальными компонентами та же проблема, то всё исследование нужно начинать сначала.

На момент возникновения проблемы у вендора не было новой прошивки, но у производителя SSD она была. Взвесив все за и против, мы решили перейти на нее.

Что до одновременного доступа с разных узлов кластера, как именно это влияло на производительность при развёртывании одной-двух машин? Даже если был redirected I/O с одного из узлов, такого падения быть не должно было на 40-гигабитной сети, а уж реально задействовать балансировку нагрузки на SoFS в вашей задаче можно только в очень специфическом случае: одновременное копирование двух .vhdx на два отдельных CSV, каждый из которых покрывает все условные «шпиндели» системы.

Влияло именно multipoint connection – одновременная работа с дисками двух нод SOFS. Страдала в конечном итоге запись на физические диски.

Схема неверна. В верхней части должно быть:
Virtual Disk 512e (512/4096) — диски виртуальных машин

Виртуальные машины видят .vhdx диски, созданные с параметрами по умолчанию, как 512e и соответственно оптимизируют запись. Старые .vhd диски по умолчанию эмулируют 512n.

Вот как выглядит .vhdx файл:
> get-vhd… |fl *sector*
LogicalSectorSize: 512
PhysicalSectorSize: 4096

А вот вид изнутри виртуальной машины:
> get-disk|fl *sector*
LogicalSectorSize: 512
PhysicalSectorSize: 4096

Кстати, что после всех изменений показывают ваши виртуальные машины? Если вы не пересоздавали все .vhdx с ручным указанием размера физического сектора, то они всё так же считают, что у них физический сектор 4kB и производят RMW при записи одиночных 512 байт.

Вы несколько невнимательно читаете: подсистема ввода-вывода СХД (а не внутри ВМ) начинает учитывать физический сектор ТОЛЬКО в самом низу этой схемы. Все остальные слои оперируют с логическим сектором.

Кстати, что после всех изменений показывают ваши виртуальные машины? Если вы не пересоздавали все .vhdx с ручным указанием размера физического сектора, то они всё так же считают, что у них физический сектор 4kB и производят RMW при записи одиночных 512 байт.
Это привело к выполнению политики Read-Modify-Write: чтение сектора 4К в кэш, правка необходимых 512 байт, запись 4К обратно на диск. Как следствие, к катастрофическому падению производительности дисковой подсистемы во время записи в 8 раз.

Не совсем понятно, как такое может произойти на реальной нагрузке.

Смотрите ответы выше и ниже.

Первый вопрос: откуда возьмутся случайные 512-байтовые записи (кроме специально настроенного синтетического теста)? Начиная с Windows Server 2012 все структуры .vhdx выровнены по 4kB (именно поэтому они и представляются виртуальной машине по умолчанию как 512e, а vhd представлялись как 512n). Операционная система внутри VM знает, что физический сектор — 4kB. NTFS использует кластер минимум 4kB. Файлы, как правило, много больше 4kB. Даже SQL Server получает от системы информацию, что физический сектор — 4kB и выравнивает запись по границе 4kB.

Если идёт запись блока большого размера, он передаётся вниз через подсистемы ввода-вывода блоками до 64kB. Такие примерно блоки и отсылаются в самый низ — на физические носители, плюс NCQ позволяет ещё более оптимизировать запись.
Чтобы в этом убедиться, достаточно для CSV посмотреть в Performance Monitor следующую метрику: Physical Disk -> Avg. Disk Bytes/Write. К сожалению, она высчитывает среднее арифметическое, включая в него и 0 при простое, но чем ближе загрузка к 100%, тем более отчётливо показатель приближается к 64kB.

Вообще говоря, физический сектор размером 4kB это условная, фальшивая цифра для SSD: реально минимальный блок перезаписи на SSD может достигать нескольких мегабайт, потому все контроллеры внутри используют что-то вроде WAFL и 3.5kB дополнительных данных их ничуть не затормозят.

Таким образом, для того, чтобы вызвать RMW в виртуальной машине, нужно записать одиночные 512 байт, и ничего вокруг не писать, иначе, при последовательной записи, максимум произойдут RMW операции для первого и последнего физического сектора, и то, при условии ошибки выравнивания, которые может только само приложение создать, так как и файловая система, и .vhdx выровнены по границе 4kB или больше. Более того, данный физический сектор не должен быть нигде закэширован, то есть виртуальная машина не должна была его до этого читать. Честно говоря, мне сложно представить нагрузку, при которой эти дополнительные операции как-либо заметно ухудшат производительность.

Давайте отделим мух от котлет: обмен данными с устройствами типа «жесткий диск» (неважно физическими или виртуальными) в конечном итоге сводится к обмену секторами. Здесь все проблемы вызывал виртуальный CSV том – именно на участке файл виртуального диска -> CSV том и работает RMW.

В таблице ниже показаны значения скорости до и после внедрения этого решения. В случае “после” проверка проводилась одновременным запуском тестирования DiskSpd на 15 виртуальных машинах.

Хотелось бы увидеть подробности методики тестирования. Настораживает уже сама формулировка, которая подразумевает, что тестирование «до» и «после» проводилось по различным методикам.
Были ли виртуальные диски, на которых производилось тестирование, pinned к hot tier? Что показывал непосредственно перед тестированием Get-FileStorageTier для этих файлов? Если они не были принудительно помещены (с обязательной оптимизацией после Set-FileStorageTier) в hot tier, то тестировалась «погода на Марсе» — во время первого и второго тестирования они могли быть полностью или частично в hot или cold tier, да ещё влияние оказывало соотношение объёма Storage Spaces Write Cache (по умолчанию — 1GB) с объёмом записываемой информации, а также скорость пополнения Storage Spaces Write Cache и скорости его сброса. Ну и, конечно же, настройки тестирования — если тестировалась случайная запись 512-байтовыми блоками при отключенном кэше, то такой нереальный access pattern мог немного просадить производительность. Но даже при таких настройках что-то не верится в 8-кратную разницу. Намного больше похоже на 8-кратную разницу (возможно, несколько сглаженную кэшем) между скоростью доступа к данным, лежавшим в cold tier и данным, перемещённым в hot tier после того, как их только что туда-сюда скопировали.

Storage Spaces Write Cache используется только для операций случайной записи, вся остальная запись идет через SSD тир. Холодные данные потом перемещаются на медленный уровень. Даже если убрать SSD тир, сделать однородный пул из 512е SATA/SAS дисков, проблема все равно останется. Цифра 8 взялась не случайно – это подтверждено тестами.

Не обижайтесь, но заявления вида «инженеры Microsoft, разработавшие новую систему и протестировавшие её перед релизом сверху донизу, а также все, кто не первый год её эксплуатируют, ошиблись, а я, первый раз взяв её в эксплуатацию, сразу нашёл ошибку и сам её исправил» воспринимаются с очень большой долей скептицизма. Нужно очень тщательно обосновать свои выводы.

Обижаться не на что :-) Если оно было действительно «протестировано перед релизом сверху донизу», то в России были бы еще сервис-провайдеры, использующие Storage Spaces для своего публичного облака.

В интернете я нашёл только одну статью с аналогичной вашей проблемой, в комментариях к которой пишут, что воспроизвести её не смогли.

В Microsoft обращались? Они подтвердили ваши выводы?

Обращались в Premier Support, месяц общались со специалистами до третьей линии. Проблему в итоге решили сами. По поводу подтверждения выводов – принцип работы дисков никак не соотносится с решениями Microsoft (за исключением момента с созданием по умолчанию CSV тома с логическим секторов в 4К на основе дисков 512n и 512e). По поводу ссылки и комментариев – не смогли воспроизвести, потому что и SSD, и SATA диски были 512n.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий