Облако на Microsoft Hyper-V, часть 3: хранилище Storage Spaces

    Часть 1: знакомство с панелью управления
    Часть 2: развертывание Exchange Server
    Часть 3: хранилище Storage Spaces

    Продолжаем серию статей о виртуальной инфраструктуре на Microsoft Hyper-V.
    Сегодня расскажем, как устроено хранилище на базе Storage Spaces и с какими сложностями мы столкнулись при его построении.

    Содержание
    Архитектура хранилища
    Проблема производительности хранилища на Storage Spaces
    Что впереди: Storage Spaces Direct



    Архитектура хранилища


    Самой сложной задачей при создании облака Cloud-V оказалось создание быстрого программно-определяемой СХД на базе Microsoft Storage Spaces.

    В основе хранилища — кластер на базе двух серверов Dell PowerEdge 730 с подключенным к ним дисковым массивом Dell PowerVault 3060e.


    Архитектура Storage Spaces.

    Вместо традиционной сети хранения SAN мы построили конвергентную локальную сеть с пропускной способностью 40 Гбит. В кластере развернули роль Scale-out-file server с поддержкой компонентов SMB Direct и SMB Multichannel.

    SMB Multichannel позволяет балансировать подключения узлов вычислительного кластера к ресурсам хранилища при наличии нескольких сетевых адаптеров на сервере. Мы использовали сетевые адаптеры Mellanox ConnectX-3 Pro 40GbE, поддерживающие функцию ROCE (RDMA over Converged Ethernet).

    Компонент SMB Direct использует ROCE для прямого доступа к памяти удаленного сервера, что снижает сетевые задержки. Приложения с одного узла обращаются непосредственно к памяти приложений на другом узле, минуя сетевой стэк операционной системы. В результате существенно ускоряется передача данных между узлами.


    Взаимодействие приложения и дискового хранилища: без RDMA (слева) и с RDMA (справа).

    Высокая производительность программно-определяемой СХД Storage Spaces достигается за счет использования разного типа дисков (SATA, SAS, SSD). Фактически у нас получилось многоуровневое хранилище, данные в котором распределяются по разным типам дисков в зависимости от интенсивности использования. Storage Spaces фильтрует данные и отправляет редко используемые на нижний уровень (HDD), а “горячие” данные – на быстрые SSD-диски на верхнем уровне. Такой тип хранилища позволяет более эффективно использовать ресурсы.


    Запись и фильтрация данных в многоуровневом хранилище.

    Проблема производительности хранилища на Storage Spaces


    Чтобы получить такое умное хранилище и заставить его работать, нам пришлось повоевать. Проблема, с которой мы столкнулись, – низкая скорость обработки данных. Показатели записи SSD-дисков не превышали 100 Мбит/сек, что в 10 раз ниже необходимых для нормальной производительности. Проблема появилась сразу же при развертывании ВМ из шаблона: одна ВМ размером 10 Гб разворачивалась 30–40 минут, развертывание двух ВМ занимало порядка двух часов.

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

    Мы продолжили искать проблему на самом нижнем уровне архитектуры и стали анализировать процесс обмена данными драйвера ОС с диском, а именно: чтение и запись секторов на диск. Существует два определения сектора: логический и физический. Логическим сектором оперирует драйвер операционной системы, физическим – непосредственно контроллер жесткого диска. В данное время жесткие диски делятся на три типа по соотношению размера логический/физический сектор:

    • 512 Native – логический 512, физический 512;
    • 512е – логический 512, физический 4096;
    • 4096 Native – логический 4096, физический 4096.

    Когда в пуле находятся диски одного типа, никаких проблем с создаваемым CSV-томом и располагающимися на нем файлами виртуальных жестких дисков нет. Проблемы начинаются, когда в пуле объединены диски разного типа. В нашем случае пул содержал 512 Native (SATA) и 512е (SSD) диски. Логично думать, что CSV-том будет создан с логическим сектором 512 байт. В реальности оказалось, что для вновь создаваемых ВМ разработчики установили по умолчанию создание CSV-тома с логическим сектором 4096.

    В итоге получалась следующая картина:


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

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


    Процесс записи 512-байтного сектора на носитель с 4096-байтным сектором.

    Мы нашли два пути решения проблемы:

    1. Пересоздание существующих виртуальных жестких дисков с размером логического сектора 4К. В итоге этот вариант нам не подошел, так как не все компоненты архитектуры поддерживают виртуальные диски, расположенные на томах с сектором 4096.

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



    Что впереди: Storage Spaces Direct


    В рамках Windows Server 2016 вышла обновленная версия Storage Spaces – Storage Spaces Direct. Как обещает вендор, в новом решении устранены проблемы текущей реализации программно-определяемой СХД и есть новые возможности:

    • Многопоточная дедупликация, которая позволяет выделять определенные ядра процессора на процесс дедупликации. В Storage Space сейчас доступна только однопоточная дедупликация на базе одного ядра процессора. Дедупликация в реальном времени невозможна, а сам процесс занимает много времени.

    • Ребалансировка. Все данные можно перераспределять по томам. Это позволяет добиться большей производительности дисковой подсистемы. В Storage Space при добавлении новых жестких дисков в пул данные начнут попадать на добавленные жесткие диски только после заполнения изначально выделенных дисков.

    • Различные варианты масштабирования. В Storage Spaces масштабирование происходит только путем добавления новых дисковых полок, что дорого и неудобно.

    Мы уже начали экспериментировать со Storage Spaces Direct и в ближайшее время расскажем о первых впечатлениях. Задавайте вопросы в комментариях.

    Автор: Сергей Груздов
    • +4
    • 10,9k
    • 9

    DataLine

    97,53

    Экосистема на базе дата-центров TIER III

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

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

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

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

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

        Желаем удачи с тестированием S2D. Своими результатами обязательно поделимся в блоге, следите за новостями.
          0
          Да, я не совсем правильно выразился: разумеется Storage Spaces поддерживает SATA-диски, но не в варианте Scale-Out файлового сервера, когда одной или несколькими JBOD-полками управляют 2 и более контроллеров. JBOD-полка должна быть именно SAS`овская и никак иначе. Если сервер один и SS используется в качестве простого «программного RAID`а», то да, диски могут быть любыми. Ссылка на технет: https://technet.microsoft.com/en-us/library/hh831739(v=ws.11).aspx
          0
          После получения практического опыта, было бы интересно услышать сравнение с vSAN и Starwind, Datacore.
          Ну и приглашаю вас помочь в заполнении сравнения SDS продуктов. Думаю многим будет интересно.
            0
            Очень много вопросов возникает по поводу найденной вами проблемы и методики тестирования.
            Проблема, с которой мы столкнулись, – низкая скорость обработки данных. Показатели записи 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 обращались? Они подтвердили ваши выводы?
              0
              Виталий, я тоже подтверждаю результаты, которые получились у инженеров Dataline, хотя в нашем случае разница была не столь значительная: SSD Tier, VHDX созданный со секторами по умолчанию — порядка 300 Мбайт/с на запись в тесте diskspd, после создания нового VHDX с секторами 512/512 — порядка 1200 МБайт/с в таком же тесте. К сожалению, сейчас не могу воспроизвести всё повторно и показать повторные логи, но на неделе может быть получится, если это действительно вызывает такие сомнения.

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

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

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


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

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

            Самое читаемое