Ssd кэш windows server — Ваш верный помощник с OS Windows

SSD-диски все еще дороги. Цена на них постепенно понижается, но на единицу хранения они пока еще не могут конкурировать с традиционными HDD. Последние, кстати, вовсе не собираются сдавать свои позиции. И дело не только во все увеличивающихся объемах хранения и снижающейся стоимостью записи на HDD. Традиционные HDD обеспечивают куда большую надежность хранения данных на протяжении длительного времени и существенно большую износостойкость в плане записи. И эти свойства HDD появились не вчера, их планомерно развивали в течение десятилетий. К надежности хранения данных на HDD можно привести множество примеров, когда в различных НИИ и замшелых банках все еще используются жесткие диски выпущенные десятки лет тому назад. И при этом они полностью сохранили свою работоспособность. Кстати, ленточные накопители тоже остались у дел, в тех же банках, финансовых компаниях, замшелых НИИ. Магнитные ленты отлично выполняют функции по архивному хранению информации, например, резервных копий и по самой минимальной стоимости при высочайшей надежности.

Но есть у HDD и неоспоримые недостатки. Это все, что связано со временем доступа и вообще скоростью чтения и записи данных. Конечно, HDD почти что космические ракеты, если сравнить их с решениями на магнитной ленте, но скорости HDD, в нынешних реалиях, все равно недостаточно. По сути, это самый медленный компонент современного ПК. Именно по этой причине на свет появились SSD. Они лишены механической части и соответственно недостатков, связанных со временем доступа и скоростями чтения/записи. В SSD все эти операции происходят «мгновенно» и с максимально доступной производительностью.

А можно ли совместить достоинства HDD и SSD дабы нивелировать их недостатки? Как оказывается можно. Еще до появления SSD обычные HDD уже оснащались крупными буферами из оперативной памяти для ускорения операций чтения-записи. Данная технология помогала лишь отчасти, в основном для операций связанных с записью данных, либо на очень медленных компьютерах, где интерфейс не мог переварить поставляемый жестким диском объем данных. Чуть позже появились комбинации, когда HDD дооснащался еще и небольшим встроенным SSD. SSD-часть в этом случае использовалась как SSD-кэш. Большой популярности подобные решения не нашли, так как объемы SSD встраивались небольшие, а износу они подвергались существенному. Но производители пошли дальше.

На сцену вышла концепция, декларирующая ранжирование данных на дисковом массиве по важности быстрого доступа к ним. Ведь какие-то фотографии с позапрошлогоднего отпуска, можно вполне себе хранить хоть на ленте, а вот файл динамичной игры должен подгружать как можно быстрее. В этой стезе засветилась корпорация Intel, разработавшая совместно с Micron новый вид памяти для твердотельных дисков. Для конечного потребителя новинка предстала под торговой маркой Optane и предназначалась как раз для ускорения операций ввода-вывода традиционных HDD. Иначе работала как «умный» SSD-кэш. Да, кстати, объемы Optane-дисков, как правило, были небольшими, а стоимость соответствовала амбициям электронных гигантов.

Но технологии не стоят на месте, а неумолимо приближаются к технологической сингулярности. Усилиями многих производителей SSD-диски становятся все дешевле и быстрее. И вот в некоторых компьютерах есть только просто SSD-диск и больше ничего. Но, а в мощных рабочих станциях, игровых ПК, да и в большинстве ПК, что стоят на производствах, в офисах и просто по домам разнокалиберных граждан, по-прежнему присутствуют HDD. И вроде бы компьютеры не старые, вполне рабочие, но дисковая подсистема основанная на HDD оставляет желать лучшего, а выкинуть вполне еще рабочий HDD на терабайт, ну просто, рука не поднимается. Но и тут есть решение. Можно использовать технологию по созданию автоматических tiered drives (или иерархичных дисков, лучшего русскоязычного термина я не подобрал). В основе технологии tiered drives лежит объединение быстрых, но небольших SSD-дисков, и медленных, но надежных и объемных HDD-дисков, в один виртуальный пул, тем самым устраняя недостатки каждой из технологий хранения данных.

Автоматичность в случае с tiered drivers означает, что система сама, самостоятельно, без всякого AI, SMS и регистраций, будет определять, какие данные следует помещать на быструю часть (SSD), а какие разумнее оставить на HDD. В некоторых реализациях можно дополнительно «привязывать» те или иные файлы к быстрой части виртуального пула или медленного. Кроме того, некоторые производители дополнительно оснащают свои программные решения по организации tiered drives еще и дополнительным кэшем в оперативной памяти, для еще большей производительности. Но, прежде чем перейти к разбору программным продуктов «без SMS и регистраций», необходимо разобраться в отличиях между SSD-cache, RAID-массивами и tiered drives.

SSD-cache – простой механизм по прозрачному кэшированию данных на быстром SSD-диске перед их записью на медленный HDD-диск, либо аналогичное кэширование данных при чтении. Все зависит от реализации. Технология интересная, но особого признания не нашла в силу очень узкой специализации. Небольшое количество данных она запишет быстро, а вот с чем покрупнее никакого преимущества уже не будет.

RAID-массив — механизм объединения нескольких физических дисков в единый пул. Способ объединения зависит от потребности, но в основном используется в промышленных системах хранения данных, где требуется высокая надежность хранения и низкий процент отказов с нулевым простоем. Как правило в массив объединяются одинаковые по характеристикам диски.

Tiered drive — механизм разделения данных на требующих и не требующих быстрого доступа с соответствующим местом хранения на SSD или HDD.

AMD StoreMI

Мое первое знакомство с tiered drives началось с AMD StoreMI. Еще с первой версии, перелицованной enmotus FuzeDrive. Перейдя с Intel на платформу AMD, я с удовольствием обнаружил, что весь мой парк старых HDD можно безболезненно использовать с моим новым ПК, а заодно и ускорить их до самого доступного максимума при помощи освободившихся SATA SSD (а основными рабочими дисками у меня стали NVME PCI накопители).

Первая версия StoreMI имела существенные ограничения, так, например, можно было использовать для создания tiered drive SSD размером не более 256 Гб. Хорошо, что у меня был именно такой диск. Система tiered drive собралась оперативно, скорость работы с HDD выросла до адекватных показаний, все бегало и приятно урчало. Но локальный праздник жизни был омрачен двумя факторами:

Система падала из-за StoreMI при высокой нагрузке. Например, при копировании данных с HDD на tiered drive от StoreMI.
Спустя некоторое время AMD убрала StoreMI первой версии из открытого доступа, а никакой замены не предложила. Другими словами, если вам потребовалось восстановить систему, в которой присутствует tiered drive StoreMI, то все данные вы потеряете на этом диске, так как подключиться к нему никак.

В качестве дополнительного удобства я несколько раз получал заблокированный tiered drive, так как StoreMI не могла проверить свою лицензию. Ну и полностью отсутствующая поддержка по продукту означала, что использовать его можно только на свой страх и риск. Из плюсов, что были в первой версии StoreMI, можно отметить лишь наличие дополнительно кэша в оперативной памяти, что несколько ускоряло работу всей связки.

Чуть позже AMD выпустила вторую версию StoreMI уже без всяких ограничений на объемы дисков и прочей ереси в виде лицензий. Вторая версия оказалась несовместимой с первой. Провести апгрейд — нельзя. По всей видимости это связано с тем, что вторая версия StoreMI уже была написана без специалистов enmotus. Интерфейс хоть и стал чуть более лицеприятным, но все также отдавал Delphi.

Вторую версию StoreMI я установил на свой второй компьютер, первую установить я на него не успел, апгрейд закончился позже, чем появилась обновленная StoreMI. Установку удалось завершить далеко не с первой попытки. Пришлось ждать около полугода, пока появятся исправления и StoreMI наконец-то заработает и на моем втором ПК.

Вообще, драйвера дисковых подсистем штука до крайности важная. Они не должны содержать никаких ошибок, а их код должен быть «вылизан» программистами и тестировщиками до последнего байта. Ведь малейшая, даже самая крохотная ошибка в программном обеспечении дисковой подсистемы способна привести к краху ценных данных. Ваших данных. И именно по этой причине, мы меняем программное обеспечение как перчатки, но все еще продолжаем работать с файловыми системами, разработанными в прошлом веке. Лучше оставаться на проверенной системе, хоть и чуть медленнее, чем терять свои данные.

Но вернемся к StoreMI второй версии. Через некоторое время использования я с удивлением заметил, что некоторые фотографии, которые я синхронизирую с компьютером оказываются испорченными. Хотя на всех других устройствах они открываются и читаются без особых проблем. Фотографии, как не трудно догадаться, хранятся как раз на диске StoreMI. Дабы отвести напрасные мысли о ненадежности второй версии StoreMI, я решил переустановить Windows.

Но, после первой же перезагрузки после установки второй версии StoreMI (и даже без создания tiered drive) моя установка Windows становилась полностью неработоспособной. UEFI (BIOS) напрочь отказывался видеть загрузочный диск, а инсталляционная утилита Windows не обнаруживала никаких признаков установленной операционки для восстановления. Проведя подряд 7 переустановок операционной системы, я окончательно убедился, что проблема как раз в StoreMI от AMD.

В общем, пришлось идти, искать альтернативу. Ведь к хорошему быстро привыкаешь.

enmotus FuzeDrive

Естественным первым порывом стало желание посмотреть на родную утилиту для организации tiered drives от производителя первой версии StoreMI. Ведь она худо, но все же продолжала работать, тянуть мой домашний комп.

Неоспоримым преимуществом FuzeDrive является наличие RAM-кэша, который дополнительно ускоряет операции записи в системе. Данные сначала записываются в быструю оперативную память, а потом уже отправляются на tiered-диск по мере возможности. Но мой опыт работы с первой версией StoreMI, проблемы с лицензией и аварийные остановки операционные системы при высокой нагрузке на дисковую подсистему несколько охладили мой пыл в отношении FuzeDrive. Пошли искать альтернативу дальше.

ROMEX PrimoCache

Альтернативой FuzeDrive для Windows можно считать PrimoCache от ROMEX. Утилита PrimoCache — применяется как продвинутое решение для кэширования данных при чтении или записи с медленных устройств. В качестве быстрых устройств, используемых для кэширования, в PrimoCache можно применять ОЗУ, SSD-диск и даже Flash-диски. Кстати, в Windows уже есть технология по ускорению медленных накопителей за счет использования кэширования на USB Flash-дисках. Но решение ReadyBoost, опять же, не стало популярным. Ускорение за счет USB-флешки медленного HDD, установленного в медленном компьютере, обычно приводило к еще большим тормозам, так как на обработку данных с Flash-дисков тратились дополнительные ресурсы, которых и так было мало.

Но вернемся к PromiCache. Тут следует учитывать, что это именно кэш, т.к. данные всегда проходят через «быстрое» устройство.

Благодаря такому активному кэшированию при помощи PrimoCache можно получать фантастические скорости общения с жестким диском. Еще одним преимуществом PrimoCache можно считать отсутствие необходимости в переносе данных с «медленного» носителя перед включением его кэширования. Т.е. установка утилиты — максимально безопасна. Кстати, PrimoCache можно скачать на попробовать, в приложении присутствует «триальный» период.

К сожалению, никакой функции по ранжированию данных по иерархии хранения в PrimoCache нет, поэтому ее не следует рассматривать как прямого конкурента StoreMI или FuzeDrive.

При дальнейшем исследовании можно обнаружить, что на рынке присутствует некоторое количество RAM-cache утилит, предоставляющих примерно один и тот же сервис под разными названиями. Не будем их всех перечислять, а перейдем сразу к герою настоящей статьи, а именно…

Служба Storage Spaces появилась в Windows Server 2012 как способ объединения физических дисков в единые пулы, на основе которых могут быть организованы виртуальные диски. Данная же технология мигрировала с Windows Server 2012 и на Windows 8.

Изначально в Storage Spaces были доступны следующие варианты объединения:

Simple — дисковое пространство всех дисков объединяется в одно.
Two-way mirror — обычное зеркалирование данных по дискам, всего хранится две копии.
Three-way mirror — усиленное зеркалирование данных по дискам, всего хранится три копии.

Получался эдакий аналог программного RAID встроенного в операционную систему. Позже, с выходом Windows Server 2012 R2 появились дополнительные виды объединения дисков:

Parity — хранение данных с избыточной информацией необходимой для восстановления. Данные «размазываются» сразу по нескольким дискам и в случае выхода из строя части дисков, данные все равно можно будет восстановить благодаря избыточности.
Tiered — как раз интересующий нас случай с поддержкой иерархического хранения и сегрегации данных на быстрые и медленные носители.

Состояние дисковой подсистемы после создания Tiered Drive из двух дисков

Последняя редакция также была перенесена в десктопные решения. Создание и управление пулами дисков и виртуальными дисками под Windows 10 (Widows 8 рассматривать уже не будем по причине старости) доступно через апплет (оснастку) Storage Spaces, либо через команды в среде Windows PowerShell. К сожалению, в оснастке Storage Spaces доступны все варианты создания объединения, за исключением Tiered. Он доступен только через команды в PowerShell.

Как выглядит созданный виртуальный диск в оснастке Disk Management

Как работает механизм сегрегации данных в tiered варианте объединения? Новые данные обычно записываются на HDD, а затем, если к ним часто и много обращаются, то перемещаются уже на SSD. Если же системе требуется записать большое количество небольших и случайных изменений данных, то такие изменения записываются в первую очередь на SSD (используется механизм кэширования на SSD), с последующим перенесением на HDD если это необходимо. Все перемещения между слоями (иерархиями) дисков происходят либо автоматически (если такая опция была выбрана при создании пула дисков), либо во время обслуживания виртуального диска (та самая дефрагментация), либо командами через PowerShell.

Можно ли добавлять диски к пулу после его создания? Да, можно. Причем проделать эту процедуру можно уже в оснастке Storage Spaces. В целом Windows позволяет добавлять в пул более, чем достаточное количество дисков. Общее пространство можно разделять между различными виртуальными дисками. Виртуальные диски можно делать даже больше, чем есть физического места для хранения. В случае исчерпания свободного места на диске он переводится в режим Read Only до тех пор, пока не будет добавлен новый диск в пул дисков.

При использовании хранения данных одновременно на нескольких дисках увеличивается вероятность потери данных по причине выхода из строя накопителя или сразу нескольких. Опытные системные администраторы сразу же упомя́нут, что ценные данные вообще-то нужно периодически резервировать на сменных носителях (те самые магнитные ленты) и хранить их в отдельном помещении или лучше здании (городе, стране и т.п.). Но можно попробовать поднять надежность хранения данных и в случае использования tiered disk при использовании Storage spaces. Во-первых, совершенно никто не мешает организовать аппаратное зеркалирование на уровне UEFI (BIOS) и включать в пул дисков уже зеркалированные диски. Во-вторых, согласно документации от Microsoft, создав пул из hdd и sdd (и соответственно tiered drive) у нас есть возможность создавать на его основе и так называемые вложенные (nested) виды объединения, которые уже могут зеркалироваться или иметь избыточность. Однако, данное действие имеет смысл только при наличии действительно достаточного количества физических дисков для организации зеркалирования или избыточности.

Кстати, даже при использовании обычного tiered объединения некоторые диски можно исключать из пула для их замены (однако, для их замены они должны быть настроены в системе как извлекаемые (hot swap)).

Итак, для добавления своего tiered пула в Windows 10 можно воспользоваться либо командами в PowerShell (в документации Microsoft достаточно подробно описана пошаговая процедура создания tiered drive через PowerShell), либо воспользоваться скриптами win10-storage-spaces от freemansoft специально предназначенными для автоматизации создания Tiered Storage.

Возможность создания Nested Drives на свободном месте Storage Spaces

Процедура использования скриптов достаточно проста, требуется подредактировать скрипт создания пула, изменить наименование пула и виртуального диска, подумать над буквой, которая будет назначена виртуальному диску. Затем освободить диски от разделов и запустить скрипт создания. Он автоматически добавит в пул все свободные от разделов диски, исправит неверные или отсутствующие идентификаторы у HDD-дисков, создаст один виртуальный диск по всему размеру всех подключенных дисков.

Если вдруг, по каким-то причинам, касающимся безопасности, скрипт не будет исполняться, то необходимо изменить настройки безопасности для скриптов и запустить процедуру заново.

После создания пула им уже можно управлять через оснастку Storage Spaces. Например, в пул можно добавить еще дисков. Однако, если изначально у нас создавался tiered пул на двух дисках (т.е. сформирован Simple пул), то его нельзя будет переконвертировать в Two-way Mirror пул, хотя можно будет организовать Nested Two-way Mirror диск при создании нового виртуального диска.

Storage Spaces после добавления в пул еше одного SSD и проведения оптимизации

При добавлении нового физического диска в пул система сразу предлагает провести оптимизацию. Я добавил к системе еще один 120 Гб SSD-диск (к уже добавленному 240 Гб SSD и 1 Тб HDD) и после оптимизации я получил загрузку в 74% 240 Гб SSD и 50% от 120 Гб SSD. Таким образом, на обоих SSD осталось примерно поровну не назначенного в пул места. И именно это место я могу использовать в качестве пространства для создания нового Storage Space (по сути, это и есть виртуальный диск).

После добавления нового диска и оптимизации можно провести изменение размера виртуального диска. Осуществить эту операцию через оснастку Storage Spaces нельзя, система возвращает ошибку. Дело в том, что легкого способа увеличить размер виртуального диска не существует. Проблема кроется в том, как организуются пулы в Storage Spaces. Все дело в так называемом Number of Columns, а именно в количестве физических дисков, на которых физически располагается виртуальный диск. И для успешного изменения размера виртуального диска необходимо добавить в пул количество диско равное Number of Columns. Звучит немного странно, но таковы ограничения. Однако, в моем случае, Tiered disk создался с пустым количеством Columns, т.к. у меня, при создании пула был только один SSD и один HDD. В общем и целом, мне не удалось увеличить размер общего пула после добавления дополнительного SSD-диска в пул. Тем не менее, оба диска работают в пуле совместно. О проблемах с увеличением или уменьшением места в Storage Pool сообщают пользователи и серверных операционных систем. Не помогает в том числе и ручное создание пулов с несколькими разнокалиберными дисками. Так что экспериментировать со Storage Spaces еще есть куда.

Данные по работе виртуального диска (отображается производительность моего SSD-диска)

Для измерения полученного результата можно воспользоваться как обычными средствами типа Crystal Disk Mark или же использоваться специализированное средство от Microsoft DiskSpd. Disk Mark, как и положено будет давать результаты с SSD-диска, так как он первым воспринимает удар синтетической цифровой стихии, а DiskSpd дает более интересный результат, но его нужно еще правильно интерпретировать.

Полезные ссылки:

Intel Optane
RAID
AMD StoreMI
enmotus FuzeDrive
Delphi
ROMEX PrimoCache
Статья на Habr об использовании Storage Spaces
Storage Spaces на Microsoft Docs
Описание утилиты DiskSpd и ее репозиторий на GitHub
Использование DiskSpd
Скрипты win10-storage-spaces
Страница на GitHub Joe Freeman-а, автора скриптов по автоматизации
Оригинальная запись блога Nils Schimmelmann-а, который провел изыскания по включение tiered pool в Win10
Настройка политики запуска скриптов в PowerShell
Использование tiering на LVM под Linux при помощи LVM-Cache
Storage Spaces: Understanding Storage Pool Expansion
Cannot Extend Simple Virtual Disk in Windows Server 2012 R2
Storage Spaces: Understanding Storage Pool Expansion
ReadyBoost

Источник

On Windows Server 2012 and 2012 R2, you can create virtual disks from multiple hard disks to increase the security of your data and the performance of your file server.

To do this, refer to our previous tutorial : Windows Server 2012/2012 R2 — Create storage spaces to improve the performance and/or security of your file server

Since Windows Server 2012 R2, you also have the option of using SSDs (faster hard disks) to increase the performance of your file server.
However, you will not create a SSD-only storage, but rather a kind of SSHD.

In summary, Windows Server will analyze the use of stored files to transparently and automatically move frequently used files to the SSD defined as «faster hard drive».

New storage pool
New virtual disk
New volume

1. New storage pool

To begin, create a storage pool.

Specify a name for this pool (hard disks group).

Choose the physical disks to place in this storage pool.

Note : as you can see in the picture below, we have 1 SSD, as well as 2 hard drives (which are currently detected as «Unknown»).

Click Create.

After the pool is created, select the «Create a virtual disk when the wizard closes» check box and click Close.

2. New virtual disk

To create a virtual disk on this storage pool, select your storage pool and click Next.

If Windows Server didn’t correctly detect the type of SSD / HDD used for your pool, the «Create storage levels on this virtual disk» check box will be grayed out.
In this case, close this wizard and use the commands proposed later in this tutorial.

To fix this problem, you will need to use some PowerShell commands.

To start, list the hard drives of your server :

PowerShell

Get-PhysicalDisk

In our case, this command shows us 4 disks :

the hard disk where Windows is installed : PhysicalDisk1 (60 GB)
the 120 GB SSD (119.25 GB)
2 standard hard drives of 500 GB (499.25 GB)

Plain Text

FriendlyName        CanPool             OperationalStatus   HealthStatus        Usage                              Size
------------        -------             -----------------   ------------        -----                              ----
PhysicalDisk2       False               OK                  Healthy             Auto-Select                   499.25 GB
PhysicalDisk1       False               OK                  Healthy             Auto-Select                       60 GB
PhysicalDisk0       False               OK                  Healthy             Auto-Select                   119.25 GB
PhysicalDisk3       False               OK                  Healthy             Auto-Select                   499.25 GB

Then, check how Windows Server recognizes your disks.

PowerShell

Get-PhysicalDisk | ft FriendlyName, MediaType

In our case, Windows Server correctly recognizes our SSD, but doesn’t recognize the type of our hard drives.
So, the «MediaType» displayed is «UnSpecified».

Plain Text

FriendlyName                                                MediaType
------------                                                ---------
PhysicalDisk2                                               UnSpecified
PhysicalDisk1                                               UnSpecified
PhysicalDisk0                                               SSD
PhysicalDisk3                                               UnSpecified

To solve the problem, simply set the pool hard drives as conventional hard drives.
In our case, we will use the «PhysicalDisk2» and «PhysicalDisk3» hard disks for our storage pool.

Note: If no error is displayed, it’s good.
Otherwise, verify that the disks are in a storage pool.

PowerShell

Get-PhysicalDisk PhysicalDisk2 | Set-PhysicalDisk -MediaType HDD
Get-PhysicalDisk PhysicalDisk3 | Set-PhysicalDisk -MediaType HDD

To verify that the changes have been made, you can use this command :

PowerShell

Get-PhysicalDisk | ft FriendlyName, MediaType

As expected, we find our 2 hard drives (2 and 3), as well as our SSD (0).

Plain Text

FriendlyName                                                MediaType
------------                                                ---------
PhysicalDisk2                                               HDD
PhysicalDisk1                                               UnSpecified
PhysicalDisk0                                               SSD
PhysicalDisk3                                               HDD

In the server manager, click on the «refresh» icon at the top.
Then, you will see that you have 2 hard disks and 1 SSD in the «Physical disks» list.

Now, restart the wizard by clicking «Tasks -> New Virtual Disk» in the «Virtual Disks» section.

Enter a name for your virtual disk and check the «Create storage tiers on this virtual disk» box.

Select the «Simple» storage layout.

As stated by the wizard, the storage levels (so the cache system on an SSD) require a fixed allocation.
Click Next.

Specify the size:

for SSD cache
for the data to be stored on the classic hard disk

In total, you will get a single virtual disk whose size will be the sum of the sizes.
However, the larger the size for the SSD, the more Windows Server will be able to move frequently used files to that drive.

The wizard displays a summary of the configuration of your virtual disk.

Leave the «Create a volume when the wizard closes» box and click Close.

3. New volume

To be able to store data on your virtual disk, you must partition it.
For that, we will create a volume on this one.

Leave the size indicated, and then click Next.

Click Create.

Your virtual disk is ready to use.
Click on «Volumes» (on the left).

As you can see, we have a virtual disk with a volume of 210 GB accessible with the «E» letter.

In computer, you will find your 210GB partition with the «E» letter.

Источник

В статьях про СХД из «конспекта админа» практически не рассматривались технологии софтовой организации дискового массива. Кроме того, за кадром остался целый пласт относительно дешевых сценариев ускорения хранилищ с помощью твердотельных дисков.

Поэтому в этой статье рассмотрю три неплохих варианта использования SSD-дисков для ускорения подсистемы хранения.

Почему просто не собрать массив из SSD – немного теории и рассуждений на тему

Чаще всего твердотельные накопители рассматривают просто как альтернативу HDD, с большей пропускной способностью и IOPS. Однако, такая замена «в лоб» часто стоит слишком дорого (брендовые диски HP, например, стоят от $2 000), и в проект возвращаются привычные накопители SAS. Как вариант, быстрые диски просто используются точечно.

В частности, удобным выглядит использование SSD для системного раздела или для раздела с базами данных – с конкретным выигрышем в производительности можно ознакомится в соответствующих материалах. Из этих же сравнений видно, что при использовании обычных HDD узким местом является производительность диска, а в случае SSD сдерживать будет уже интерфейс. Поэтому замена одного лишь диска не всегда даст такую же отдачу, как комплексный апгрейд.

В серверах используют SSD с интерфейсом SATA, либо более производительные SAS и PCI-E. Большинство представленных на рынке серверных SSD с интерфейсом SAS продаются под брендами HP, Dell и IBM. К слову, даже в брендовых серверах можно использовать диски OEM-производителей Toshiba, HGST (Hitachi) и других, которые позволяют сделать апгрейд максимально дешевым при схожих характеристиках.

С широким распространением SSD был разработан отдельный протокол доступа к дискам, подключенным к шине PCI-E – NVM Express (NVMe). Протокол разработан с нуля и значительно превосходит своими возможностями привычные SCSI и AHCI. С NVMe обычно работают твердотельные диски с интерфейсами PCI-E, U.2 (SFF-8639) и некоторые M.2, которые быстрее обычных SSD более чем вдвое. Технология относительно новая, но со временем она обязательно займет свое место в самых быстрых дисковых системах.

Немного про DWPD и влияние этой характеристики на выбор конкретной модели.

При выборе твердотельных дисков с интерфейсом SATA следует обращать внимание на параметр DWPD, который определяет долговечность диска. DWPD (Drive Writes Per Day) – это допустимое количество циклов перезаписи всего диска в сутки на протяжении гарантийного периода. Иногда встречается альтернативная характеристика TBW/PBW (TeraBytes Written, PetaBytes Written) – это заявленный объем записи на диск на протяжении гарантийного периода. В SSD для домашнего использования показатель DWPD может быть меньше единицы, в так называемых «серверных» SSD — 10 и более.

Такая разница возникает из-за разных типов памяти:

SLC NAND. Самый простой тип – в каждой ячейке памяти хранится один бит информации. Поэтому такие диски надежны и обладают хорошей производительностью. Но приходится использовать больше ячеек памяти, что негативно влияет на стоимость;
MLC NAND. В каждой ячейке хранится уже два бита информации – самый популярный тип памяти.
eMLC NAND. То же самое что и MLC, но повышена устойчивость к перезаписи благодаря более дорогим и качественным чипам.
TLC NAND. В каждой ячейке хранится по три бита информации – диск максимально дешев в производстве, но обладает наименьшими производительностью и долговечностью. Чтобы компенсировать потери по скорости, для внутреннего кэша часто используется память SLC.

Таким образом, при точечной замене обычных дисков твердотельными логично использовать MLC-модели в RAID 1, что даст отличную скорость при том же уровне надежности.

Считается, что использование RAID совместно с SSD – не лучшая идея. Теория основывается на том, что SSD в RAID изнашиваются синхронно и в определенный момент могут выйти из строя все диски разом, особенно при ребилде массива. Однако, с HDD ситуация точно такая же. Разве что, испорченные блоки магнитной поверхности не дадут даже прочитать информацию, в отличие от SSD.

По-прежнему высокая стоимость твердотельных накопителей заставляет задуматься об альтернативном их использовании, помимо точечной замены или использования СХД на базе одних лишь SSD.

Расширяем кэш RAID-контроллера

От размера и скорости кэша RAID-контроллера зависит скорость работы массива в целом. Расширить этот кэш можно с помощью SSD. Технология напоминает решение Smart Response от Intel.

При использовании подобного кэша данные, которые используются чаще, хранятся на кэширующих SSD, с которых производится чтение или дальнейшая запись на обычный HDD. Режимов работы обычно два, аналогично привычному RAID: write-back и write-through.

В случае write-through ускоряется только чтение, а при write-back – чтение и запись.

Подробнее об этих параметрах вы можете прочитать под спойлером.

При настройке кэша write-through запись проводится как в кэш, так и на основной массив. Это не влияет на операции записи, но ускоряет чтение. К тому же, перебои питания или всей системы для целостности данных уже не так страшны;
Настройка write-back позволяет записывать данные сразу в кэш, что ускоряет операции чтения и записи. В RAID-контроллерах эту опцию можно включить только при использовании специальной страхующей энергонезависимую память батарейки, либо при использовании флэш-памяти. Если же применять в качестве кэша отдельный SSD, то проблема с питанием уже не стоит.

Для работы обычно требуется специальная лицензия или аппаратный ключ. Вот конкретные названия технологии у популярных на рынке производителей:

LSI (Broadcom) MegaRAID CacheCade. Позволяет использовать до 32 SSD под кэш, суммарным размером не более 512 ГБ, поддерживается RAID из кэширующих дисков. Есть несколько видов аппаратных и программных ключей, стоимость составляет около 20 000 р;
Microsemi Adaptec MaxCache. Позволяет использовать до 8 SSD в кэше в любой конфигурации RAID. Отдельно лицензию покупать не нужно, кэш поддерживается в адаптерах серии Q;
HPE SmartCache в серверах ProLiant восьмого и девятого поколения. Актуальная стоимость доступна по запросу.

Схема работы SSD-кэша предельно проста – часто используемые данные перемещаются или копируются на SSD для оперативного доступа, а менее популярная информация остается на HDD. Как итог, скорость работы с повторяющимися данными значительно возрастает.

В качестве иллюстрации работы RAID-кэша на базе SSD можно привести следующие графики:

StorageReview – сравнение производительности разных массивов при работе с базой данных: использованы обычные диски и их альтернатива на базе LSI CacheCade.

Но если есть аппаратная реализация, то наверняка существует и программный аналог за меньшие деньги.

Быстрый кэш без контроллера

Помимо программного RAID существует и программный SSD-кэш. В Windows Server 2012 появилась интересная технология Storage Spaces, которая позволяет собирать RAID-массивы из любых доступных дисков. Накопители объединяются в пулы, на которых уже размещаются тома данных – схема напоминает большинство аппаратных систем хранения. Из полезных возможностей Storage Spaces можно выделить многоярусное хранение (Storage Tiers) и кэш записи (write-back cache).

Storage Tiers позволяет создавать один пул из HDD и SSD, где более востребованные данные хранятся на SSD. Рекомендованное соотношение количества SSD к HDD 1:4-1:6. При проектировании стоит учитывать и возможность зеркалирования или четности (аналоги RAID-1 и RAID-5), так как в каждой части зеркала должно быть одинаковое количество обычных дисков и SSD.

Кэш записи в Storage Spaces ничем не отличается от обычного write-back в RAID-массивах. Только здесь необходимый объем «откусывается» от SSD и по умолчанию составляет один гигабайт.

Общая схема работы выглядит так:

При записи на чистый диск данные сохраняются на SSD;
Когда SSD заполнены, данные пишутся в write-back кэш, который записывается на HDD;
Если кэш переполнен, запись ведется напрямую на HDD;
В процессе работы данные реорганизуются так, чтобы «горячая» информация хранилась на SSD, а “холодная” – на HDD.

Если рассматривать другие операционные системы, то технологий доступно еще больше. Например, в GNU\Linux есть bcache, EnhanceIO, dm-cache и lvmcache, L2ARC в ZFS, Cache Tiering и Cache Pool в Cephs.

Если говорить о программном ускорении дисковой системы, то интересным вариантом выглядит использование для этих целей оперативной памяти. Существует ряд приложений, позволяющих «откусить» часть RAM под кэш – например PrimoCache. Подобные решения, помимо ускорения работы, помогут и продлить жизнь SSD. Главное предусмотреть защиту от проблем с питанием и не размещать в таких разделах слишком важные данные.

Итого

Файловые и веб-серверы хорошо работают с кэшем на SSD, а для размещения производственной базы данных приоритетнее RAID-массив из обычных дисков под данные и отдельное SSD-зеркало под журналы транзакций. Остальные сценарии работы с данными требуют более творческого подхода и знания специфики использования.

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

Заодно расскажите, что думаете о RAM-дисках – только ли это just for fun технология, на ваш взгляд?

Источник

Disclaimer: This article talks about Windows Server 2016 TP5. Although it doesn’t seem like this feature will change in the final version, there are, also, no guarantees that it won’t.

Windows Server 2016 Datacenter Edition introduces Storage Spaces Direct (S2D), which enables building highly available and scalable storage systems with local storage. Storage Spaces Direct is an evolution of Storage Spaces, which means that it is an extension of the existing software defined storage stack for Windows Server. Storage Spaces Direct leverages SMB3 for all east-west traffic, including SMB Direct and SMB Multichannel, for low latency and high throughput storage.

If you have already used Storage Spaces in Windows Server 2012, it is important to realize that both the caching and storage tiering work very differently in S2D. Unlike Storage Spaces in Windows Server 2012, the cache is independent of the storage pool and volumes; in fact the system manages it automatically.

How Storage Spaces Tiering works in Windows Server 2012 R2

In Windows Server 2012 R2, you can only define SSD and HDD as Capacity Tiers. Essentially, this means that the SSD Tier is part of your total pool capacity.

A scheduled task, then, runs periodically to optimize the placement of data in the storage tiers. In essence, this moves the most frequently accessed (hot) data up into the SSDs and least frequently accessed (cold) data to the HDDs.

Windows Server 2012 R2 Tiering Scheduled Task

How Storage Spaces Direct Tiering works in Windows Server 2016

Storage tiering is now done in real-time and is used for both the way data is written, as well as the media the data is written to.

With the introduction of the NVMe SSD, this model does not work as well; the downside being is that you usually have (NVMe + SSD + HDD) and with the previous model you were unable to differentiate between NVMe and SSD.

In Storage Spaces Direct, the Capacity Tier is split in two: Performance and Capacity.

The Performance Tier is part of the Capacity Tier and it is optimized for IO performance (hot data) while the rest of the Capacity Tier is optimized for Storage Efficiency (cold data).

This provides much more flexibility, as you can create volumes consisting only of performance tier, which provide highest IO performance and is backed by fast flash storage (cheapest IOPS). You can create volumes consisting only of capacity tier, which provides the best storage efficiency and is backed by hard drives (cheapest capacity). And you can create volumes consisting of both performance and capacity, that automatically keep the hottest data on flash storage and the coldest data on hard drive storage.

SSD + HDD

In a simple scenario where you have just SSD and HDD, Storage Spaces Direct does not put your SSD in your capacity tier. Instead, your HDDs will be your Capacity Tier and the SSDs will be your Caching Tier. This means that Hot Cold Data will be in your Performance Capacity Tier and the Cold Data will be in the rest of the Capacity Tier.

Storage Spaces Direct Tiering with SSD and HDD

NVMe + SSD + HDD

When you have NVMe in your storage configuration, Storage Spaces Direct automatically uses the NVMe device for the Caching Tier and the SSDs and HDDs for the Capacity Tier. While the NVMe is used for caching, the SSDs (in the Performance Capacity Tier) will contain the Hot Data and the HDDs will contain the Cold Data.

Storage Spaces Direct Tiering with NVMe, SSD and HDD

If you are interested in reading more about Storage Spaces Direct, I suggest you read Claus’ Technet Blog Posts on this topic.

Источник

Storage Spaces в Windows Server 2012 R2

Storage Spaces — технология виртуализации дискового пространства, которая впервые появилась в Microsoft Windows Server 2012. Storage Spaces является дальнейшим развитием механизма управления динамическими дисками в Windows. Основой является широко применяемая в решениях различных вендоров концепция дисковых пулов: отдельные физические диски сервера объединяются в один или несколько пулов, на базе которых создаются тома с различными уровнями производительности и отказоустойчивости. Использование Storage Spaces вместо аппаратного RAID-контроллера имеет ряд преимуществ и недостатков, которые будут подробно рассмотрены ниже.

Термины

Storage pool (пул хранения) — набор физических дисков. В одном пуле могут находится диски, отличающиеся по объёму, производительности и интерфейсу подключения.
Virtual disk (виртуальный диск) — термин для определения логический том в Storage Spaces. Для создания виртуального диска используется ёмкость выбранного дискового пула. При этом доступны несколько вариантов отказоустойчивости (их можно комбинировать в пределах одного пула), большинство из которых являются аналогами традиционных RAID-массивов различных уровней.
- Simple (простой) — аналог RAID-0. Поток данных разбивается на страйпы (по умолчанию размером в 256КиБ), которые распределяются по дискам в пуле. Виртуальный диск simple обеспечивает оптимальное использование ёмкости дисков и является самым производительным, но не предполагает никакой отказоустойчивости.
- Mirror (зеркальный): для каждого страйпа в зеркальном виртуальном диске записывается дополнительно одна (двойное зеркало, 2-way mirror) или две (тройное зеркало, 3-way mirror) копии. Аналогом в плане использования ёмкости дисков для двойного зеркала является RAID-10 (или 1E для нечётного числа дисков). Зеркальный ВД защищён от потери одного или двух дисков соответственно.
- Parity (виртуальный диск с контролем чётности): запись страйпов на диски чередуется с записью контрольной суммы. В Windows Server 2012 R2 появились диски с двойной чётностью (dual parity), в которых дополнительно пишется вторая контрольная сумма. Как и аналогичные RAID-5 и RAID-6 ВД с контролем чётности допускают потерю одного или двух дисков соответственно и обеспечивают минимальную потерю дискового пространства (-1 или -2 диска соответственно). Традиционным недостатком любых реализаций томов с контрольными суммами является низкая производительность на запись из-за необходимости модификации всего полного страйпа вместе с контрольными суммами. Отсутствие фиксированного размещения страйпов в Storage Spaces и RAM-кэша на контроллере (используются обычные HBA) усугубляет данную проблему, сравнение производительности ВД single parity и dual parity с RAID-5 и RAID-6 будет ниже.
В Windows Server 2012 R2 появился функционал enclosure awareness: при размещении страйпов учитывается размещение дисков по различным дисковым полкам (SAS JBOD’ам) для получения отказоустойчивости на уровне дисковых полок. Например, ВД с двойным зеркалированием (2-way mirror), размещенный на трёх дисковых полках, допускает потерю одной дисковой полки целиком.
Параллельность распределения страйпов в виртуальном диске определяется числом т.н. столбцов (columns). Для получения максимальной производительности число столбцов для виртуальных дисков с уровнем отказоустойчивости simple и parity должно соответствовать количеству физических дисков, но в настройках по умолчанию максимальное число столбцов, например, для simple равно 8. Это связано с особенностями механизма расширения ёмкости пула: для оптимального использования ёмкости число добавляемых дисков должно соответствовать максимальному числу столбцов, которое используется виртуальными дисками, а для зеркальных дисков — числу столбцов * числу копий страйпа (2 для 2-way mirror, 3 для 3-way mirror).
Storage tiers (ярусное хранение данных). В Windows Server 2012 R2 появилась поддержка 2-ярусного (SSD и HDD) размещения данных на виртуальных дисках Storage Spaces. Приоретизация доступа к быстрому ярусу из SSD возможна путём управления ёмкостью (при создании ВД указываются комбинация объёмов SSD и HDD ярусов) либо на файловом уровне: необходимый файл можно привязать к SSD-ярусу для обеспечения гарантированной производительнности.
Write-back cache (кэш на запись). Для компенсации низкой производительности на случайную запись небольшая часть SSD в пуле используется для кэширования записи. При этом оставшаяся часть ёмкости SSD может быть использована для ярусного хранения.

Ограничения

Количество дисков и ёмкость:

До 240 дисков одном пуле (в Windows Server 2012R2, ранее — до 160-ти), но пулов может быть несколько.
До 80-ти дисков в кластеризованном пуле, до 4-х пулов на кластер.
До 64-х виртуальных дисков в одном пуле.
Общая ёмкость пула — до 480ТиБ.

Столбцы и количество дисков в ВД:

Тип ВД	Минимальное число столбцов	Соотношение столбцы/диски	Минимальное число дисков	Максимальное число столбцов
Simple (простой)	1	1:1	1	—
Two-way mirror (двойное зеркало)	1	1:2	2	—
Three-way mirror (тройное зеркало)	1	1:3	5	—
Single parity (одиночная чётность)	3	1:1	3	8
Dual parity (двойная чётность)	7	1:1	7	17

Прочее

Виртуальный диск Storage Spaces не может использоваться в качестве загрузочного.
Для Storage Spaces можно использовать только диски с интерфейсами SAS, SATA и USB. Тома, презентуемые RAID-контроллерами; тома iSCSI, FC и прочие не поддерживаются.

Требования при использовании в кластере

Нельзя использовать «тонкие» диски, допускается только фиксированное выделение ёмкости (fixed provisioning).
Минимальное количество дисков для двойного зеркала — 3, для тройного зеркала — 5.
В кластере можно использовать ВД с Parity, но только начиная с Windows Storage Server 2012 R2
Используемые диски — только SAS с поддержкой SPC (SCSI persistent reservation). Многие ранние SAS-диски не поддердивают SPC. Аналогичное требование существует и для LSI Syncro CS.

Storage Spaces в кластерах

Одна из самых востребованных возможностей Storage Spaces — использование в failover-кластере Windows. Архитектура решения предельно проста: требуются диски SAS (см. дополнительные требования к дискам и организации томов), SAS JBOD (дисковая полка) с двумя SAS-экспандерами и минимум двумя разъемами для подключения к каждому из экспандеров (для двухузлового кластера). На серверах в качестве контроллеров используются обычные SAS HBA. Мы рекомендуем LSI (любые SAS2 и SAS3 HBA с внешними портами, например LSI 9207-8e), но можно использовать и Adaptec серий 6H и 7H.

Минимальной конфигурация выглядит так: два сервера, в каждом из них двухпортовый SAS HBA с подключением к 2-экспандерному SAS JBOD’у на базе корпуса Supermicro и SAS диски.

Для использования в качестве SAS JBOD’а можно использовать любой корпус Supermicro с двумя экспандерами (E26 или E2C в наименовании для SAS2 и SAS3 соответственно). Каждый экспандер в корпусах Supermicro имеет минимум два разъема x4 SAS (SFF-8087 или SFF-8643), которые можно использовать в качестве входов. При наличии третьего разъема его можно использовать для каскадирования (подключения дополнительных дисковых полок) или для построения топологии с тремя узлами в кластере.

Существуют варианты в одном корпусе, т.н. Cluster-in-a-box (CiB): готовые комплекты SSG-6037B-CIB032 и SSG-2027B-CIB020H на базе Supermicro Storage Bridge Bay с предустановленным Windows Storage Server 2012 R2 Standard, которые отлично подходят для построения отказоустойчивых файловых и/или iSCSI серверов:

Производительность

Решение на базе Storage Spaces может масштабироваться до более чем миллиона IOPS при использовании SSD и зеркальных томов. Но производительность на запись в Parity и Dual Parity по-прежнему оставляет желать лучшего, и такие конфигурации без write-back кэша на SSD подходят лишь для узкого круга задач с преимущественной нагрузкой на чтение.

Всестороннее исследование производительности Storage Spaces в разных конфигурациях было проведено компанией Fujitsu. В нашей тестовой лаборатории мы повторили некоторые из этих тестов, дополнив измерение IOPS и пропускной способности значениями средней и максимальной задержек.

Условия тестирования

Два процессора E5640
8GB RAM
Системная плата Supermicro X8DTL-iF
Контроллер Adaptec 6805 (тесты с аппаратным RAID), кэш на чтение включен, кэш на запись включен
Контроллер LSI 9211-8i (тесты со Storage Spaces, прошивка P19 IT
Диски HGST HUA723030ALA640 (3ТБ 7200об/мин SATA3): 12шт для тестов RAID-10 vs Storage Spaces 2-way mirror и 13шт для тестов RAID-6 vs Storage Spaces dual parity
2шт SSD Intel 710 100ГБ для тестов с tiering’ом и write-back кэшом
Microsoft Windows Server 2012 R2 Standard
Для генерации нагрузки применялся FIO версии 2.1.12

Для тестирования использовался скрипт, реализующий серию 60-секундных раундов нагрузки с различными шаблонами и варьированием глубины очереди. Для определения окна установившегося состояния используется та же методика, что и в нашем пакете для тестирования SSD, разработанного в соответсвии со спецификацией SNIA Solid State Storage Performance Test Specification Enterprise v1.1. Для всех замеров использовался тестовый файл объёмом 100ГиБ, кроме тестов с ярусным хранением, где использовался файл объёмом 32ГиБ.

Для наглядности использовались шаблоны аналогичные использованным в тестах от Fujitsu:

Шаблон	Доступ	Чтение	Запись	Размер блока, КиБ
File copy	случайный	50%	50%	64
File server	случайный	67%	33%	64
Database	случайный	67%	33%	8
Streaming	последовательный	100%	0%	64
Restore	последовательный	0%	100%	64

Результаты

RAID-10 vs Storage Spaces 2-way mirror

Сравнивались: RAID-10 из 12-ти дисков на контроллере Adaptec 6805, 2-way mirror из 12-ти дисков (6 столбцов), 2-way mirror из 12-ти дисков с 2ГиБ write-back кэшом на двух SSD Intel 710 и ярусным хранением — SSD-tier’ом из тех же объёмом в 40ГБ (40ГБ SSD + 200ГБ HDD).

Шаблоны Database (IOPS), File copy, File Server (пропускная способность). Для шаблона Database используется логарифмическая шкала. По графикам видно, что 2-way mirror заметно уступает в производительности традиционному аппаратному RAID-10: в два с лишним раза на шаблонах Database и File copy, примерно в 1,5 раза на шаблоне File Server. Выравнивание результатов с ростом глубины очереди больше 16-ти нельзя рассматривать с точки зрения практического использования из-за неприемлемого роста задержек (графики ниже). Серьезный рост производительности обеспечивает использование SSD в качесте кэша на запись и быстрого яруса. Всего пара даже устаревших на сегодняшний день Intel 710 поднимает производительность на случайном доступе малыми блоками на порядок. Есть смысл использовать такое сочетание не только для OLTP, но и для нагруженных файловых серверов.

Шаблоны Database, File copy, File Server: средняя задержка. Никаких сюрпризов: Storage Spaces проигрывает, но естественно вырывается вперёд при добавлении SSD.

Шаблоны Database, File copy, File Server: максимальная задержка. При более высокой средней задержке Storage Spaces демонстрирует более стабильные значения — максимумы при небольшой глубине очереди меньше на шаблонах Database и File copy.

Шаблоны Streaming, Restore: пропускная способность. Зеркальный Storage Spaces не уступает аппаратному RAID при последовательном чтении, но существенно уступает при последовательной записи (шаблон Restore). Рост при запредельных значениях глубины очереди (>64) имеет значение только в синтетических тестах из-за большого значения задержки. Использование SSD в данном случае оказывается бесполезным из-за последовательного доступа и соотношения числа HDD и SSD. Обычные HDD, тем более в количестве 12-ти штук, отлично справляются с последовательной нагрузкой и оказываются существенно быстрее пары SSD.

Шаблоны Streaming, Restore: средняя задержка.

Шаблоны Streaming, Restore: максимальная задержка. Появляется хоть какая-то польза от SSD в виде стабилизации значения задержки..

RAID-6 vs Storage Spaces dual parity

Сравнивались: RAID-6 из 13-ти дисков на контроллере Adaptec 6805 и Dual Parity из 13-ти дисков (13 столбцов). К сожалению, у нас не оказалось минимально требуемого для использования в таком пуле количества SSD аналогичных использованным в первой серии тестов — для Dual Parity их нужно минимум три. Но соответствующее сравнение производительности с SSD tier’ом и кэшированием записи есть в вышеупомянутом исследовании Fujitsu.

Шаблоны Database (IOPS), File copy, File Server (пропускная способность). Storage Spaces с Dual Parity существенно отстаёт от аппаратного RAID во всех сценариях со случайным доступом. Это не удивительно с учётом того, что в распоряжении Adaptec 6805 есть 512МБ RAM-кэша, что позволяет существенно оптимизировать неудобный для RAID-6 доступ на случайную запись. Среди тестов, проведённых Fujitsu, есть вариант «RAID-6 8xHDD против Dual Parity 8xHDD + 1ГБ WB кэша на 3xSSD» — на всех трёх шаблонах производительность при добавлении WB-кэша на SSD не уступает аппаратному RAID, причём без использования ярусного хранения.

Шаблоны Database, File copy, File Server: средняя задержка.

Шаблоны Database, File copy, File Server: максимальная задержка. Ситуация аналогична предыдущей серии тестов с зеркальным Storage Spaces. При более высокой средней задержке Storage Spaces демонстрирует более стабильные значения — максимумы при небольшой глубине очереди меньше на шаблонах Database и File copy.

Шаблоны Streaming, Restore: пропускная способность. Dual Parity хорошо справляется с чтением, но с последовательной записью наблюдается давно известная катастрофическая ситуация с отставанием более чем на порядок. Использование даже большого по объёму write-back кэша (можно выделить диски целиком, присвоив диску Usage=Journal) на нескольких SSD может на какое-то время компенсировать относительно кратковременные нагрузки на запись, но при непрерывной записи (например, при использовании в системе видеонаблюдения) кэш рано или поздно будет заполнен.

Шаблоны Streaming, Restore: средняя задержка. Для шаблона Restore используется логарифмическая шкала.

Шаблоны Streaming, Restore: максимальная задержка (логарифмическая шкала).

Преимущества и недостатки Storage Spaces

Преимущества

Снижение затрат на оборудование.
Для простых проектов с одиночным сервером: SAS HBA или чипсетный контроллер вместо аппаратного RAID-контроллера; возможность использовать недорогие диски SATA, формально не совместимые с аппаратными RAID (например, WD Red) вместо дисков nearline класса.

Для проектов с одиночной неотказоустойчивой СХД и большими требованиями к плотности размщениния дисков можно использовать такие платформы (72 диска в 4U, до 432ТБ сырой ёмкости при использовании 6ТБ дисков):

Картинка с сайта: www.truesystem.ru

Для кластерных решений: простые дисковые полки (SAS JBOD’ы) вместо дорогостоящих СХД.
Высокая производительность. Решение на базе Storage Spaces и SSD легко масштабируется по пропускной способности и IOPS путём добавления дисковых полок и HBA вплоть до нескольких миллионов IOPS и десятков ГБ/с. Сравнительно невысокая производительность обычных HDD может быть компенсирована применением ярусного хранения с размещением «горячих» данных на SSD и/или использованием SSD для кэширования операций записи.
Использование tiering’а (ярусного хранения) в сочетании с кэширование записи на SSD в Storage Spaces в большинстве случаев работает эффективнее, обходится дешевле и имеет большие пределы масштабирования в сравнении с реализацией SSD кэша на аппаратных RAID-контроллерах (например, LSI CacheCade или Adaptec MaxCache).
Гибкое использование дискового пространства. В Storage Spaces можно комбинировать на одной дисковой группе (в одном пуле) тома с любым уровнем отказоустойчивости, при добавлении в пул SSD — с любым соотношением ёмкости между HDD- и SSD-ярусами и/или ёмкостью write-back кэша.
Для всех видов томов, за исключением использования в кластере, томов с ярусным хранением и томов Dual Parity поддерживается Thin Provisiong (тонкое выделение ресурсов) — это позволяет выделять ёмкость только по мере реального использования.

Недостатки

Низкая производительность на запись при использовании обычных HDD, особенно в Parity и Dual Parity
Определенный тип нагрузки на запись (случайный доступ небольшими блоками, сосредоточенный в определённой области) может быть легко компенсирован добавлением SSD в качестве быстрого яруса и кэша на запись. Но продолжительную линейную нагрузку на запись компенсировать не получится, так что рекомендовать использование Storage Spaces, например, для видеонаоблюдения нельзя.

Для бюджетных кластерных решений под Windows (с похожей архитектурой на базе SAS JBOD) с высокой нагрузкой на запись мы советуем использовать вместо Storage Spaces специальные RAID-контроллеры LSI Syncro CS.
Ограниченное масштабирование кластера. Для использования Storage Spaces в кластере необходим совместный доступ к дискам через дисковую полку с двумя SAS-экспандерами (SAS JBOD). SAS JBOD не является отдельной самостоятельной СХД, поэтому кластер с использованием Storage Spaces может состоять максимум из 4-х узлов (необходим специальный SAS JBOD с 4-мя входами на каждый экспандер), а в типовых конфигурациях с SAS JBOD Supermicro — максимом из 3-х узлов (или 2-х при необходимости подключать дополнительные JBOD’ы каскадом).

Советы по оптимальному использованию Storage Spaces

При использовании в кластере используйте только SAS HDD и SSD, избегайте использования SATA дисков с дополнительными интерпозерами.
При создании виртульных дисков учитывайте число т.н. столбцов. Данный параметр может очень сильно влиять на производительность. Нестандартное число столбцов можно задать только при использовании PowerShell. Использование большего числа столбцов повышает производительность, но накладывает ограничение на добавление дисков в пул.
Пример (виртуальный диск Dual Parity, 13 столбцов, 1000ГиБ, Fixed Provisioning):

New-VirtualDisk -StoragePoolFriendlyName Pool1 -FriendlyName VD02 -ResiliencySettingName Parity -NumberOfColumns 13 -PhysicalDiskRedundancy 2 -Size 1000GB -ProvisioningType Fixed
Избегайте использования виртуальных дисков Parity и Dual Parity при наличии большой нагрузки на запись и/или случайного доступа малыми блоками.
Одним из самых востребованных на сегодня решений является небольшой 2-узловой кластер для Hyper-V. Из-за конкурентного обращения нескольких ВМ достаточно высокий процент нагрузки на дисковую подсистему будет состоять из случайного доступа. При расчёте дисковой подсистемы планируйте использование зеркальных виртуальных дисков (2-way mirror — стандартное двойное зеркалирование, для особых сценариев можно использовать тройное), производительность Parity и Dual Parity будет достаточно только для архивных данных. Планируйте использование минимум двух SSD для tiering’а и кэширования записи.
Избегайте добавления дисков с разной производительностью (например, HDD 7200 и 10000 об/мин) в общий пул либо создавайте виртуальные диски только из HDD с одинаковой производительностью, выбирая их вручную в GUI или через параметр -PhysicalDisksToUse при создании через PowerShell. Диски SSD должны быть либо вынесены в отдельный пул, либо использоваться совместно с HDD только в качестве быстрого яруса и/или write-back кэша.

Ссылки

Часто задаваемые вопросы по Storage Spaces
Обзор Storage Spaces
Storage Cmdlets in Windows PowerShell
Пример PowerShell скрипта для создания пула, ярусов и ВД
Deploy Clustered Storage Spaces
Корпуса Supermicro с SAS-экспандерами
White Paper: Fujitsu Server PRIMERGY Windows Server 2012 R2 Storage Spaces Performance
Storage Spaces — Designing for Performance

Источник