В октябре 2014 года компания Microsoft выпустила первую общедоступную ознакомительную техническую версию для следующего поколения Windows Server. На конференции TechEd Europe Бен Армстронг (http://blogs.msdn.com/b/virtual_pc_guy/), главный менеджер программ в группе Hyper-V, рассказал о двух новых компонентах в следующей версии Windows Server Hyper-V. В мае на конференции Ignite представители Microsoft официально объявили о Windows Server 2016, System Center 2016 и Hyper-V Server 2016. В данной статье приводится краткий обзор некоторых новых компонентов Windows Server 2016 Hyper-V.
Nano Server
Представители компании объявили о готовности Nano Server, следующего сервера «облачной» платформы, на котором можно запускать Hyper-V (см. экран 1). Разумеется, запуск возможен и внутри виртуальных машин Hyper-V.
.jpg) |
| Экран 1. Nano Server |
Операции VHDX с ускорением ReFS
Попытка создать файл VHDX фиксированного размера в Windows Server 2012 R2 или более ранних версиях может занять много времени, так как необходимо записать нулевые блоки в хранилище. При наличии ODX эта операция может быть выполнена хранилищем. В Windows Server 2016, если файл VHDX фиксированного размера создается на томе ReFS, работу можно возложить на ReFS, что позволит создать VHDX очень быстро. Этот прием действует и с объединяемыми файлами VHDX, что очень удобно для резервного копирования и контрольных точек.
Вложенная виртуализация. Windows Server 2016 Hyper-V позволяет запускать серверы Hyper-V в виртуальных машинах Hyper-V. Это очень удобная функция, особенно для обучения пользователей или демонстрации Hyper-V.
Новый формат Shared VHDX
В Windows Server 2012 R2 были реализованы общие виртуальные диски Shared VHDX. С помощью этой функции можно присоединить виртуальный диск (VHDX) к нескольким виртуальным машинам для построения гостевых кластеров. Но в Windows Server 2012 R2 отсутствовали некоторые возможности, такие как резервное копирование файлов Shared VHDX на основе узлов и изменение размеров файлов Shared VDHX в сети. В Windows Server 2016 Hyper-V разработчики Microsoft постарались устранить пробелы, добавив следующие элементы:
- резервное копирование файлов Shared VHDX;
- изменение размеров файлов Shared VDHX в сети;
- изменения в графическом интерфейсе, направленные на повышение удобства использования;
- файлы Shared VHDX — новый тип виртуального жесткого диска, файлы vhds.
Защита ресурсов узла
Эта функция заимствована из Microsoft Azure; она защищает ресурсы узла Hyper-V от виртуальных машин, которые пытаются атаковать структуру, например формируя высокие рабочие нагрузки для процессора. Защита ресурсов узла динамически идентифицирует виртуальные машины, которые ведут себя «не по правилам», и уменьшает выделяемые им ресурсы.
Виртуальный модуль доверия TPM. Windows Server 2016 Hyper-V позволяет дополнить виртуальную машину виртуальным платформенным модулем Virtual TPM для шифрования виртуальной машины с использованием Windows Server Bitlocker. Это дает возможность надежно защитить содержимое виртуальной машины, особенно при размещении виртуальных машин в «облаке».
Безопасная загрузка Linux
В Windows Server 2012 R2 появились виртуальные машины нового поколения Generation 2, в которых можно использовать функции безопасной загрузки для виртуальных машин с операционными системами Windows 8 или Windows Server 2012 и более новыми версиями. В Hyper-V Server 2016 предусмотрен режим безопасной загрузки для виртуальных машин Linux.
Защищенные виртуальные машины Shielded VM
Защищенные виртуальные машины Shielded VM могут функционировать только в структурах, назначенных владельцами виртуальных машин. Защищенные виртуальные машины должны быть зашифрованы с использованием Bitlocker (или другого решения), чтобы гарантировать запуск виртуальной машины только уполномоченными владельцами. Для этого требуется, чтобы присутствовали другие части стека Microsoft Windows Server, такие как служба защиты узла Host Guardian Service или доверенный платформенный модуль (TPM).
Расширенный кластер Hyper-V с компонентом Storage Replica
В версии Windows Server 2016 встроенный компонент Storage Replica позволит организовать репликацию хранилища. Кроме того, его можно использовать для файловых серверов и хранилища виртуальной машины. С помощью этой функции Windows Server можно организовать репликацию в файлы типа CSV внутри одного кластера или в другой кластер.
Устойчивость хранилища виртуальной машины
В Windows Server 2012 R2 и более поздних версиях отказоустойчивая кластеризация в основном предназначалась для защиты приложений, а для виртуальных машин Hyper-V были предусмотрены лишь простейшие механизмы. В большинстве случаев этого бывает достаточно. Но иногда, например при кратких отключениях сети, отказоустойчивая кластеризация может вызывать проблемы. Однако благодаря устойчивости хранилища виртуальной машины в Windows Server 2016 Hyper-V отключения структуры хранилища больше не приводят к сбоям виртуальных машин. При возникновении неполадок в структуре хранилища работа виртуальных машин приостанавливается, а затем автоматически возобновляется. В Windows Server 2012 R2 при потере виртуальной машиной связи с хранилищем на протяжении более 60 секунд происходил сбой виртуальной машины. В Windows Server 2016 Hyper-V виртуальная машина приостанавливается до тех пор, пока связь с хранилищем не будет восстановлена. Если хранилище остается недоступным слишком долго, можно переключиться на резервный ресурс (см. экран 2).
.jpg) |
| Экран 2. Устойчивость хранилища виртуальной машины |
Устойчивость кластера виртуальной машины
Как и устойчивость хранилища, устойчивость кластера поможет избежать неприятностей при кратких отказах узла или сети. Благодаря устойчивости кластера виртуальной машины для Windows Server 2016 Hyper-V виртуальные машины продолжают работать, даже если узел больше не является членом кластера. Это обеспечивает устойчивость при временных ошибках, а узлы, подверженные таким ошибкам, отправляются в карантин. Поэтому, если узел выводится из кластера, то виртуальные машины на данном узле поддерживаются в активном состоянии, пока узел не вернется в кластер. Если узел кластера не будет восстановлен через четыре минуты, то виртуальные машины переводятся на другой узел Hyper-V. Но если узел слишком часто отправляется в карантин, Hyper-V и отказоустойчивый кластер автоматически выполняют динамическую миграцию виртуальных машин с этого узла на другой, когда узел возвращается в рабочее состояние.
PowerShell Direct
Это уникальное новшество. В Windows Server 2012 R2 Hyper-V можно было копировать файлы в виртуальные машины без сетевой связи с использованием VMBus. В Windows Server 2016 можно задействовать PowerShell Direct для запуска команд PowerShell в виртуальной машине с помощью VMBus.
Изменения в настройках виртуальной машины
В Windows Server 2016 Hyper-V изменятся файлы настроек виртуальной машины (см. экран 3). Сегодня файлы настроек виртуальной машины Hyper-V имеют формат xml. Раньше вы могли открыть файл, проверить и изменить настройки виртуальной машины внутри него (хотя этот подход никогда не поддерживался Microsoft). По мере того как рабочие нагрузки становятся виртуальными, все большее значение приобретают масштабирование и производительность. В следующей версии Hyper-V формат файла настроек виртуальной машины будет изменен с xml на двоичный. Новый двоичный формат обеспечит более эффективную производительность. Кроме того, применяется устойчивое протоколирование изменений в файлах настроек, чтобы защитить виртуальные машины от повреждения.
.jpg) |
| Экран 3. Изменения в настройках виртуальной машины |
Новые расширения файлов:
- VMCX (Virtual Machine Configuration) — заменяет. xml-файл;
- VMRS (Virtual Machine Runtime State) — заменяет. bin- и. vsv-файл.
Контрольные точки (моментальные снимки) производственных виртуальных машин
Контрольные точки виртуальных машин (в предыдущих версиях — моментальные снимки виртуальных машин) были отличным решением, позволяющим получить состояние виртуальной машины и сохранить его. Если внести изменения и какие-то из них окажутся неудачными, то легко вернуться к моменту создания контрольной точки. Этот механизм не предназначался для производственных целей из-за несовместимости со многими приложениями. Теперь ситуация изменилась: Microsoft обеспечивает его полную поддержку в производственной среде (см. экран 4). Сегодня для создания производственной контрольной точки вместо сохраненного состояния используется VSS. Это означает, что восстановление контрольной точки — то же самое, что восстановление системы из резервной копии. С точки зрения пользователя, все осталось как прежде. Производственные контрольные точки включены по умолчанию, но при необходимости можно вернуться к прежним методам. Все же при использовании контрольных точек возникают некоторые проблемы, например рост файла avhdx.
.jpg) |
| Экран 4. Контрольные точки производственных виртуальных машин |
Hyper-V Replica и «горячее» подключение VHDX
Hyper-V Replica — одно из наиболее примечательных новшеств Windows Server 2012 Hyper-V. В Windows Server 2012 и Windows Server 2012 R2 Hyper-V, если выполнить «горячее» подключение VHDX-файла к виртуальной машине, репликация завершалась неудачей. В Hyper-V 2016 новый виртуальный жесткий диск, добавляемый к реплицируемой виртуальной машине, автоматически подключается к нереплицированному набору. Таким образом, репликация продолжается, а затем можно обновить этот набор в сети с помощью PowerShell. Виртуальная машина автоматически синхронизируется, и работа продолжается без сбоев. Команда для этого следующая:
Set-VMreplication "VMName" -ReplicatedDisks (Get-VMHardDiskDrive "VMName")
«Горячее» подключение или удаление памяти виртуальной машины
В Windows Server 2012 R2 Hyper-V можно было уменьшить минимальную память и увеличить максимальную память работающей виртуальной машины, которая использовала динамическую память. В Windows Server 2016 Hyper-V можно увеличивать и уменьшать память, назначенную работающим виртуальным машинам, даже если в них используется статическая память (см. экран 5).
.jpg) |
| Экран 5. «Горячее» подключение или удаление памяти виртуальной машины |
«Горячее» подключение или удаление виртуальных сетевых адаптеров
Отсутствие этой возможности сторонники VMware во всем мире использовали против Hyper-V, хотя мне нечасто приходилось видеть, чтобы мои клиенты прибегали к ней. Впрочем, всегда очень полезно иметь возможность «горячего» подключения и удаления сетевых адаптеров из виртуальных машин (см. экран 6).
.jpg) |
| Экран 6. «Горячее» подключение или удаление виртуальных сетевых адаптеров |
Идентификация виртуальных сетевых адаптеров
Эта функция важнее, чем «горячее» подключение или удаление виртуальных сетевых адаптеров. Для автоматизации полезно идентифицировать различные сетевые адаптеры. Для узлов Hyper-V предусмотрены различные решения, такие как согласованное именование устройств (CDN) с использованием PowerShell и других средств для идентификации сетевых адаптеров. Но для виртуальных машин подходящее решение отсутствует. Благодаря функции идентификации виртуальных сетевых адаптеров этот недостаток будет исправлен (см. экран 7). Вы можете присвоить имена отдельным виртуальным сетевым адаптерам в настройках виртуальной машины и увидеть те же имена внутри гостевой виртуальной машины. Команда PowerShell на узле Hyper-V выглядит так:
Add-VMNetworkAdapter -VMName “TestVM" -SwitchName "Virtual Switch" -Name "Fred" -Passthru | Set-VMNetworkAdapter -DeviceNaming on
.jpg) |
| Экран 7. Идентификация виртуальных сетевых адаптеров |
Команда PowerShell на гостевой машине следующая:
Get-NetAdapterAdvancedProperty
|?{$_.DisplayName -eq "Hyper-V
Network Adapter Name"} | select Name,
DisplayValue
Изменения в диспетчере Hyper-V
У многих пользователей, которые начинают работать с Hyper-V после перехода с VMware или других платформ, возникают трудности при освоении диспетчера Hyper-V. В следующей версии появится ряд улучшений, заметно облегчающих работу.
- Подключение диспетчера Hyper-V выполняется через WinRM, а не через WMI.
- Альтернативные учетные данные (на сервере и клиенте необходимо включить CredSSP).
- Подключение к узлам Hyper-V через IP-адрес.
- Управление Windows Server 2012 Hyper-V, Windows Server 2012 R2 Hyper-V и следующей версией Hyper-V из новой консоли.
Новшества в управлении электропитанием
Компания Microsoft обновила модель управления электропитанием гипервизора, реализовав новые режимы управления питанием (см. экран 8). Это одна из причин, почему я использовал ознакомительную техническую версию Windows 10 на своем Surface Pro 3. Surface Pro 3 — устройство, пригодное для режима ожидания с подключением, но если установить Hyper-V на Windows 8.1, то режим ожидания с подключением прекращает работать. В следующей версии Hyper-V режим ожидания с подключением будет работоспособен.
.jpg) |
| Экран 8. Новшества в управлении электропитанием |
Последовательное обновление кластера
Благодаря этому новшеству наконец можно обновить кластер Hyper-V с Windows Server 2012 R2 Hyper-V до следующей версии Hyper-V без новых аппаратных средств, простоя и с возможностью безопасной отмены изменений при необходимости. В Windows Server 2012 R2 нам приходилось создавать новый кластер Hyper-V при работающем старом кластере Hyper-V и переносить кластер Hyper-V с помощью мастера миграции кластеров или механизма динамической миграции. Теперь мы можем запускать узлы Windows Server 2012 R2 Hyper-V и следующую версию Hyper-V в одном кластере Hyper-V (см. экран 9).
.jpg) |
| Экран 9. Последовательное обновление кластера |
Усовершенствованный процесс обновления виртуальной машины
В целях поддержки последовательного обновления кластера разработчикам Microsoft пришлось внести некоторые изменения в процесс обновления виртуальной машины (см. экран 10). В текущих версиях Hyper-V виртуальные машины автоматически обновлялись до новой версии, то есть если виртуальная машина перемещена на новый узел Hyper-V, то вернуть ее назад не удастся. В смешанной схеме кластера такой подход неприменим. В следующей версии Hyper-V виртуальные машины не обновляются автоматически. Обновление виртуальной машины — операция, выполняемая вручную, отдельная от обновления узла Hyper-V. Это позволяет вернуть виртуальные машины на предшествующую версию Hyper-V, пока они не будут обновлены вручную.
.jpg) |
| Экран 10. Процесс обновления виртуальной машины |
Новые способы обновления драйверов виртуальной машины (служб интеграции)
С момента выхода Windows Server 2012 R2 Hyper-V драйверы виртуальной машины (службы интеграции) обновлялись с каждым новым выпуском узла, и требовалось, чтобы версия драйвера виртуальной машины соответствовала версии узла. Когда начался выпуск новых служб интеграции Hyper-V, требовалось обновить узел Hyper-V; после этого можно было обновить драйверы виртуальной машины внутри виртуальной машины. В Windows Server 2016 Hyper-V обновления драйвера ВМ производятся через службу Windows Update. Из этого следует, что в соответствии служб интеграции виртуальной машины версии узла теперь необходимости нет; достаточно иметь новейшую версию служб интеграции.
Безопасная загрузка Linux
Компания Microsoft активно реализует поддержку операционных систем Linux, в частности динамической памяти и других функций. В Hyper-V vNext обеспечена безопасная загрузка Linux, в том числе Ubuntu 14.04 (и более поздних версий) и SUSE Linux Enterprise Server 12. Код PowerShell для включения безопасной загрузки Linux:
Set-VMFirmware "Ubuntu" -SecureBootTemplate MicrosoftUEFICertificateAuthority
Качество обслуживания распределенного хранилища
В Windows Server 2012 R2 Hyper-V можно ограничить максимальное число операций ввода-вывода для отдельного виртуального жесткого диска. Это очень удобная функция. Все работает прекрасно, если запускать виртуальную машину на одном узле Hyper-V, но если несколько узлов Hyper-V с несколькими виртуальными машинами работают с одним хранилищем, то узлу Hyper-V неизвестно, что ему приходится конкурировать с другими серверами за операции ввода-вывода и пропускную способность хранилища. Например, минимальный порог операций ввода-вывода применим только на одиночных серверах Hyper-V. В очередном выпуске Hyper-V и Windows Server появилось много нового. Наряду с масштабируемым файловым сервером и дисковыми пространствами вводится резервирование числа операций ввода-вывода и совместный лимит для группы виртуальных машин или жестких дисков. Такие интеллектуальные функции, разработанные в подразделении Microsoft Research, обеспечивают ряд интересных возможностей, особенно для поставщиков услуг и крупных компаний.
Вычислительная устойчивость виртуальных машин
Разработчики Microsoft постоянно повышают устойчивость виртуальной машины, особенно при аппаратных отказах. Один из новых компонентов — VM Compute Resiliency. Благодаря ему виртуальные машины могут выполняться на узле, даже если узел кластера недоступен для других узлов в кластере. Например, в Windows Server 2012 R2, если служба кластера не может обратиться к узлу в кластере в течение 30 секунд, происходит переключение всех виртуальных машин на другой узел. Если то же самое происходит в Windows Server vNext Hyper-V, узел переходит в изолированный режим на четыре минуты (значение по умолчанию), и если затем узел возвращается в нормальный режим, все виртуальные машины будут работать. В противном случае виртуальные машины переключаются на другой узел. Если узел выходит из изолированного режима, чтобы выполнять кластерную службу, он будет направлен в карантин, и все виртуальные машины с этого узла перемещаются на другой узел. Это поможет обеспечить выполнение рабочих нагрузок даже в случае аппаратных и сетевых сбоев (см. экран 11).
.jpg) |
| Экран 11. Вычислительная устойчивость виртуальных машин |
Совершенствование механизма резервного копирования Hyper-V
ИТ-специалистам хорошо известно, что резервное копирование всегда сопряжено с целым рядом проблем. И задача не упрощается при использовании виртуальных машин на системах Storage System. В следующей версии Hyper-V Server применяется совершенно новая архитектура для повышения надежности, масштабируемости и производительности резервного копирования виртуальных машин. Произошли три важных архитектурных изменения.
- Резервное копирование виртуальных машин отделено от резервного копирования базового хранилища.
- Устранена зависимость базовой функциональности резервного копирования от моментальных снимков аппаратных средств. Однако можно воспользоваться преимуществами аппаратных средств.
- Введено встроенное отслеживание изменений для резервного копирования виртуальных машин.
RemoteFX
Усовершенствован компонент Windows Server 2016 RemoteFX, который теперь совместим с API-интерфейсами OpenGL 4.4 и OpenCL 1.1. Кроме того, можно использовать виртуальную оперативную память VRAM, которая наконец-то стала настраиваемой.
Управление кластером Hyper-V
Возможно, вам никогда не придется воспользоваться этими функциями, но рассматриваемые изменения — большой шаг вперед в области автоматизации и разработки. Если вы когда-нибудь применяли WMI к кластеру Hyper-V, то для получения полной информации вам приходилось делать это на каждом узле Hyper-V в кластере. В следующей версии Hyper-V наконец-то можно применить WMI к кластеру Hyper-V, и картина будет точно такая же, как с одним узлом Hyper-V. Таким образом, вы получите всю информацию обо всех узлах в кластере.
Это лишь краткий обзор некоторых функций следующей версии Windows Server 2016 Hyper-V, выпуск которой запланирован на 2016 год. Список новшеств наверняка значительно расширится, прежде чем компания Microsoft официально выпустит следующую версию Hyper-V, и, конечно, изменения коснутся и компонентов, о которых рассказано в данной статье.
Что такое Storage Spaces Direct?
Storage Spaces Direct — новый компонент в Windows Server 2016. Это расширение программного обеспечения, определяющего систему хранения Windows Server; оно усиливает технологию пространств хранения Storage Space на узлах в кластере одним из двух способов: использование внутренних по отношению к узлам в кластере дисков или прямое присоединение к узлам в кластере через какое-либо физическое устройство.
Storage Spaces агрегирует локальные по отношению к узлам кластера диски, активируя создание пула хранения Storage Pool, состоящего из этих дисков. Затем создаются виртуальные диски в пуле хранения Storage Pool кластера, и этот пул впоследствии может использоваться в качестве общего тома кластера Cluster Shared Volume (CSV) для первоначального хранения виртуальных машин Hyper-V, запускаемых на форматированных ReFS-томах.
Пример вы можете увидеть на рисунке: система хранения данных может быть внутренней или JBOD, присоединенной через SAS. Обратите внимание, что могут применяться системы хранения данных на HDD и SSD, и диски будут разделены на уровни так, чтобы самые часто используемые блоки располагались на дисках SSD, дающих очень высокую производительность, тогда как другие данные хранились бы на дисках HDD, обладающих отличной вместимостью.
.jpg) |
| Рисунок. Архитектура Storage Spaces Direct |
Виртуальные диски, созданные в пуле хранения Storage Pool кластера, являются общими томами кластера Cluster Shared Volumes, которые могут использоваться кластером локально или будут доступны другим серверам через службу масштабируемого файлового сервера Scale-out File Server (SoFS). Данные хранятся в расширениях по 1 Гбайт, а эти расширения размещаются на различных узлах для обеспечения того типа отказоустойчивости, настройки которого заданы.
Например, если зеркалирование используется с диском, имеющим отказоустойчивость 2, то это означает, что существует три копии данных: для каждого расширения данных в 1 Гбайт существуют две копии этих данных на двух других узлах в кластере. Данные реплицируются при помощи технологии Storage Spaces по шине хранилища Software Storage Bus, которая управляет SMB 3 и также дает возможность всем узлам в кластере видеть локальное хранилище на каждом узле. Пул Storage Spaces и механизм виртуального диска располагаются на самом верху Software Storage Bus. Обратите внимание, что диски, присоединенные напрямую к узлу, а не через физическое устройство, помещаются в «программное ограждение», что делает все диски управляемыми единообразно.
Процесс создания среды Storage Spaces Direct несложен. Единственная особенность — это активация Storage Spaces Direct в кластере для использования локального хранилища:
(Get-Cluster).DASModeEnabled=1
Обратите внимание: кластер задействует или технологию Storage Spaces Direct, или реальное совместно используемое хранилище, такое как сеть хранения данных SAN, или реально подключаемое совместно используемое физическое устройство. То есть они исключают друг друга.
Подробную информацию об этом можно найти в статье на Microsoft Technet (technet.microsoft.com/en-us/library/mt126109.aspx). Данная статья включает пошаговый разбор сценария PowerShell для настройки первого развертывания Storage Spaces Direct.
Обратите внимание: если вы задаете параметры настройки в виртуальных машинах, убедитесь, что все диски подсоединены к контроллеру SCSI. Кроме того, в Windows Server 2016 больше не создаются отдельные уровни для дисков HDD и SSD. Storage Spaces формирует виртуальные гибридные драйверы для всего хранилища, а затем автоматически выполняет распределение по уровням. Вот команда, которая приведена в статье на Technet:
Get-StoragePool StorSpaceDirectPool | Get-PhysicalDisk |? MediaType -eq SSD | Set-PhysicalDisk -Usage Journal
Она настраивает Storage Pool на использование диска SSD для журнала Storage Spaces и данных журнала, и пул хранения изначально не пишет все данные на SSD. После создания новых виртуальных гибридных драйверов данные сначала пишутся на SSD, а затем перемещаются.
Главная особенность этой технологии заключается в том, что она дает возможность задействовать локально доступное хранилище узла в качестве совместно используемого хранилища кластера. Защита от сбоя диска или узла активируется через репликацию хранимых данных. На экране А представлен пример того, что мы видим после создания экземпляра Storage Space Direct. Я создал этот экземпляр на четырехузловом кластере, и у каждого узла есть два локальных диска, которые были использованы в пуле.
.jpg) |
| Экран А. Пулы хранения Storage Space Direct |
Ниже приведен использованный код на PowerShell. Поскольку у меня 8 дисков, я могу использовать их по 2 для Storage Pool. Проделав это один раз, я создал том и отформатировал его в ReFS, а впоследствии сделал его общим томом кластера:
#Enable Storage Spaces Direct
(Get-Cluster).DASModeEnabled=1
#Check number of disks that can be made part of the pool
(Get-StorageSubSystem -Name savtstfcspcdir.savilltech.net
| Get-PhysicalDisk).Count
#See if there are disks that cannot be pooled
Get-StorageSubSystem -Name savtstfcspcdir.savilltech.net
| Get-PhysicalDisk |? CanPool -ne $true
#Create the pool
New-StoragePool -StorageSubSystemName
savtstfcspcdir.savilltech.net -FriendlyName
StorSpaceDirectPool -WriteCacheSizeDefault 0 `
-FaultDomainAwarenessDefault StorageScaleUnit
-ProvisioningTypeDefault Fixed
-ResiliencySettingNameDefault Mirror `
-PhysicalDisk (Get-StorageSubSystem
-Name savtstfcspcdir.savilltech.net | Get-PhysicalDisk)
#Initially data goes to SSD then tiering sends to HDD.
Gives a little amount of space on SSD for journal and log
#The Storage Spaces Direct layer will do inline tiering anyway
so don't have to tell to it to split anymore
Get-StoragePool StorSpaceDirectPool | Get-PhysicalDisk |?
MediaType -eq SSD | Set-PhysicalDisk -Usage Journal
#Create virtual disks
New-VirtualDisk -StoragePoolFriendlyName stor* -Size 80 GB
-NumberOfDataCopies 3-NumberOfColumns
2-FriendlyName testspace `
-ResiliencySettingName Mirror -ProvisioningType Fixed
-FaultDomainAwareness StorageScaleUnit -WriteCacheSize 0
Get-VirtualDisk -FriendlyName testspace | fl *