Глава 9. Управление хранилищем

Windows Server 2022 предоставляет некий диапазон функциональных возможностей, которые делают возможным доступ к широкому разнообразию хранилищ и устройств хранения. Windows поддерживает шпиндельные диски, USB- накопители, а также устройства SSD (включая NVMe SSD).

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

В наши дни большинство ПК пользуются GPT типами дисков для жёстких устройств и SSD. GPT более устойчива к ошибкам и допускает тома крупнее чем 2ТБ. Более старый тип дисков MBR, обычно применяется в 32- битных ПК, более старых ПК и удаляемых устройствах, таких как карты памяти и внешние дисковые устройства.

Для хорошего обсуждения основных отличий этих двух механизмов отсылаем вас к https://www.howtogeek.com/193669/whats-the-difference-between-gptand-mbr-when-partitioning-a-drive/. {Прим. пер.: также рекомендуем наш перевод Практика загрузки. Изучение процесса загрузки Linux, Windows и Unix Йогеша Бабара.}

После созданния тома, вы затем можете отформатировать свой том диска. Windows поддерживает пять файловых систем, которые вы можете применять: ReFS, NTFS, exFAT, UDF и FAT32. За подробностями относительно четырёх последних отсылаем вас к https://docs.microsoft.com/windows/desktop/fileio/filesystem-functionality-comparison. Файловая систем ReFS является наиболее последней и основывается на NTFS, однако утратила некоторые функциональные возможности, которые могут требоваться файловому серверу (она не обладает шифрованием файлов). Преимуществом файловой системы ReFS является автоматическая проверка целостности. Для сопоставления файловых систем ReFS и NTFS ознакомьтесь с https://www.iperiusbackup.net/en/refs-vs-ntfs-differences-and-performance-comparison-when-to-use/. Разбиение на разделы и форматирование томов вы изучите в рецепте Управление физическими дисками и томами.

Тома NTFS (и ReFS) позволяют вам создавать ACL (access control lists, списки контроля доступа), которые управляют доступом к файлам и папкам, хранящимся в томах Windows. Управление ACL до некоторой степени мудрёно и PowerShell сам по себе не обладает богатой поддержкой для управления ACL и наследованием ACL. Для управления ACL в томах NTFS, как вы обнаружите в рецепте Управление полномочиями файла и папки NTFS из Главы 10, Управление совместными данными, вы можете выгрузить модуль стороннего разработчика, NTFSSecurity.

Реплика хранения это функциональная возможность Windows Server (только в редакции Datacenter), которая создаёт некий диск в удалённых системах и заставляет Windows отслеживать такую реплику в актуальном состоянии. В рецепте Управление Репликой хранения вы создадите некое партнёрство репликации между двумя хостами и разрешите Windows Server поддерживать такую реплику в современном состоянии.

Пространства хранения это технология, предоставляемая Microsoft в Windows и Windows Server, которая способна оказывать содействие в защите от отказов дисковых устройств. На практике, Пространства хранения предоставляют программно определяемый RAID, с которым вы разберётесь в рецепте Развёртывание Storage Spaces.

Windows Server 2022 требует компьютер с по крайней мере одним дисковым устройством (в большинстве случаев это ваше устройство C:\). Вы можете подключать дисковое устройство через различные типы шин, такие как IDE, SATA, SAS или USB {а также различные среды обмена данными с протоколом Fibre Channel или PCIe через протокол NVMe}. Прежде чем вы сможете воспользоваться диском в Windows, вам требуется проинициализировать его и создать тома или разделы.

Вы можете применять две схемы разбиения на разделы: более старый формат MBR и более современный GPT. Схема MBR, впервые предложенная для PC DOS 2 в 1983, обладает рядом ограничений. Например, самые большие разделы, поддерживаемые в MBS это только 2ТБ. А создание более четырёх разделов требует от вас создать некий расширенный раздел и создавать дополнительные разделы внутри такого расширенного раздела. Схема GPT допускает намного большие устройства (пределы на разделы выставляются ОС) и вплоть до 128 разделов на устройство. Обычно вы применяете для Windows Server разбиение на разделы GPT.

В этой главе вы пользуетесь восемью новыми виртуальными дисковыми устройствами в своём сервере SRV1 и создаёте/ применяете новые тома/ разделы на этих дисках. В начале данного рецепта вы добавляете все восемь виртуальных дисков в свою ВМ SRV1. В самом этом рецепте вы пользуетесь только двумя первыми из этих новых дисков.

В этом рецепте применяется SRV1, присоединённый к вашему домену Reskit.Org, в котором у вас установлены PowerShell 7 и VS Code. Вы также пользуетесь SRV2 и должны обладать подключённым DC1.

Все рецепты в данной главе пользуются восемью дополнительными виртуальными дисками. Вы можете исполнить приводимый ниже сценарий в своём хосте Hyper-V для добавления таких новых дисков в ВМ SRV1 и SRV2:

# 0. Add new disks to the SRV1, SRV2 VMs
# Run on VM host
# 0.1 Turning off the VMs
Get-VM -Name SRV1, SRV2 | Stop-VM -Force
# 0.2 Getting Path for hard disks for SRV1, SRV2
$Path1   = Get-VMHardDiskDrive -VMName SRV1
$Path2   = Get-VMHardDiskDrive -VMName SRV2
$VMPath1 = Split-Path -Parent $Path1.Path 
$VMPath2 = Split-Path -Parent $Path2.Path 
# 0.3 Creating 8 disks to SRV1/2 for storage chapter
0..7 | ForEach-Object {
  New-VHD -Path $VMPath1\SRV1-D$_.vhdx -SizeBytes 64gb -Dynamic | Out-Null
  New-VHD -Path $VMPath2\SRV2-D$_.vhdx -SizeBytes 64gb -Dynamic | Out-Null
}
# 0.4 Adding disks to SRV1, SRV2
0..7 | ForEach-Object {
  $DHT1 = @{
    VMName           = 'SRV1'
    Path             = "$VMPath1\SRV1-D$_.vhdx" 
    ControllerType   = 'SCSI'
    ControllerNumber = 0 
  }
  $DHT2 = @{
    VMName           = 'SRV2' 
    Path             =  "$VMPath2\SRV2-D$_.vhdx"
    ControllerType   = 'SCSI' 
    ControllerNumber =  0
  }
  Add-VMHardDiskDrive $DHT1
  Add-VMHardDiskDrive $DHT2
}  
# 0.5 Checking VM disks for SRV1, SRV2
Get-VMHardDiskDrive -VMName SRV1 | Format-Table
Get-VMHardDiskDrive -VMName SRV2 | Format-Table
# 0.6 Restarting VMs
Start-VM -VMname SRV1
Start-VM -VMName SRV2
		

После того как вы создали необходимые восемь новых дисков для своих двух ВМ, вы можете приступить к данному рецепту в SRV1.

На Шаге 1 вы пользуетесь командлетом Get-Disk для получения самого первого виртуального диска в своей ВМ SRV1, одного из ваших восьми ранее добавленных дисков. Вывод этого шага выглядит следующим образом:

На Шаге 2 вы инициализируете этот диск (диск номер 1), что не производит вывод. Затем, на Шаге 3 вы просматриваете все имеющиеся диски в SRV1, при этом вывод выглядит так:

На Шаге 4 вы пользуетесь командой Get-Volume для получения доступных в SRV1 томов со следующим выводом:

На Шаге 5 вы создаёте новый том и форматируете его файловой системой NTFS. Вот как выглядит вывод на этом шаге:

На Шаге 6 вы инициализируете диск 2 и создаёте раздел в 32ГБ с устройством S:. Вот вывод с этого шага:

На Шаге 7 вы создаёте второй раздел в диске 2 с приводимым ниже выводом:

На Шаге 8 вы форматируете вновь созданные устройства S: и T:. Вы применяете для своего устройства S: файловую систему NTFS, а для устройства T: FAT32 со следующим выводом:

На Шаге 9 вы просматриваете все доступные в SRV1 разделы, вот вывод этого:

На Шаге 10 вы просматриваете тома в SRV1 при помощи команды Get-Volume с подобным следующему выводом:

На заключительном шаге этого рецепта, Шаге 11, вы просматриваете все диски в SRV1 со следующим выводом:

В Windows (Windows 10 и Windows Server 2022), вы создаёте используемые устройства данных при помощи либо команд New-Volume, либо New-Partition. Командлет New-Volume, показанный на Шаге 5, создаёт некий раздел на предписанном диске, форматирует этот раздел файловой системой и снабжает его меткой и буквой устройства. На Шаге 6 вы инициализируете свой диск при помощи форматирования MBR и создаёте новый раздел в этом диске. На Шаге 7 вы создаёте второй раздел и форматируете два раздела на Шаге 8.

На Шаге 10 вы просматриваете имеющиеся в SRV1 тома. Обратите внимание, что на Шаге 8 вы определили метку тома для тома T: с буквами из нижнего и верхнего регистров. Тем не менее, Windows преобразовывает такое дружественное название во все символы верхнего регистра при создании этого раздела. Такова архитектура.

Для применения устройства "диск", будь то шпиндельный диск, устройство CD/DVD или твердотельное устройство, вам следует отформатировать это устройство/ диск некой файловой системой. В Windows, дополнительно к тому что вам дозволяется определять какую файловую систему применять, вы можете также предоставить своему разделу букву устройства и метку файловой системы при форматировании такого устройства.

В большинстве случаев в качестве файловой системы для своего выбора вы пользуетесь NTFS. Она устойчива к отказам и надёжна, а также предоставляет действенный контроль доступом, и к тому же предоставляет шифрование и сжатие. ReFS может быть хорошим выбором для некоторых специализированных рабочих нагрузок, в особенности в неком физическом хосте Hyper-V, в котором вы можете применять файловую систему ReFS на применяемых вами дисках для содержания устройств виртуальных дисков ваших ВМ. Для взаимодействия с такими вещами как видео или простыми камерами, вам может потребоваться применять файловые системы FAT, FAT32 или exFAT.

Для получения дополнительных сведений относительно различий между файловыми системами NTFS, FAT, FAT32 и ExFAT отсылаем вас к https://medium.com/hetman-software/the-difference-between-ntfs-fat-fat32-and-exfat-file-systems-ec5172c60ccd. А для получения дополнительных сведений про файловую систему ReFS обратитесь к https://docs.microsoft.com/windows-server/storage/refs/refs-overview.

В этом рецепте применяется SRV1, присоединённый к домену хост из домена Reskit.Org, в котором вы имеете установленными PowerShell 7 и VS Code. У вас также имеется включённым DC1. В рецепте Управление физическими дисками и томами вы добавили восемь виртуальных дисков в свою ВМ SRV1 и использовали первые два. В этом рецепте вы пользуетесь третьим из этих дисков.

На Шаге 1 вы получаете первый не используемый диск из SRV1 и сохраняем его в своей переменной $Disk. Этот шаг не производит вывод. На Шаге 2 вы просматриваете свой объект диска со следующим выводом:

На Шаге 3 вы просматриваете имеющиеся в диске 3 разделы. Так как в этом устройстве нет никаких разделов (пока ещё), этот шаг не производит вывод.

На Шаге 4 вы создаёте в диске 3 четыре раздела. Первые три занимают по 15ГБ каждый, при этом четвёртый занимает всё остающееся пространство с этого диска. Вот вывод с этого шага:

На Шаге 5 вы форматируете все разделы на доске 3 с применением трёх различных файловых систем. Это включает в себя и попытку создания форматирования для W: с файловой системой FAT, что вырабатывает некую ошибку, поскольку самый большой размер, который вы можете применять с FAT это 4ГБ. Вот вывод с этого шага:

На Шаге 6 для получения всех дисков томов из SRV1 вы пользуетесь командой Get-Volume, которая выглядит подобным образом:

На Шаге 5 вы попытались отформатировать раздел W: при помощи файловой системы FAT. Вы создали этот раздел с размером в 15ГБ, что слишком много для FAT, следовательно вы наблюдаете сообщение об ошибке. Прочие три раздела были успешно отформатированы. Обратите внимание, что дружественное название для раздела Y: переведено в верхний регистр, хотя вы предоставляли дружественное название с символами из верхнего и нижнего регистров. Format-Volume преобразовывает это название во все символы верхнего регистра при форматировании этого раздела с файловой системой FAT32.

Одно из новшеств PowerShell, которое скоро полюбят все профессионалы ИТ это поставщики PowerShell. Поставщик это некий компонент, который предоставляет доступ к специализированным хранилищам данных для более простого управления. Такой поставщик пользуется данными, появляющимися в неком устройстве с путём, аналогичным тому, который вы применяете для доступа к файлам в файловых хранилищах.

PowerShell 7.1 выпускается со следующим поставщиками:

С помощью поставщиков PowerShell у вас нет необходимости наборов командлетов для каждого лежащего в основе хранилища данных. Вы можете воспользоваться Get-Item или Get-ChildItem с любым из поставщиков для возврата специфичных для поставщика сведений, как вы сможете обнаружить это в данном рецепте.

Прочие приложения способны добавлять поставщиков для заданного хоста. Например, модуль администрирования IIS создаёт устройство IIS:. А когда у вас имеется ваше собственное хранилище данных, вы также можете создавать поставщиков. Модуль SHiPS, доступный из Галереи PowerShell позволяет вам собирать некого поставщика при помощи PowerShell. В качестве некого примера возможностей платформы SHiPS, вы можете воспользоваться примером поставщика из модуля CimPSDrive. Этот модуль содержит некого поставщика для репозитория CIM. Для получения дополнительных сведений относительно платформы SHiPS обращайтесь к https://github.com/PowerShell/SHiPS/tree/development/docs. Дополнительные подробности по поставщику CimPSDrive можно найти в https://github.com/PowerShell/CimPSDrive.

Этот рецепт применяет SRV1, присоединённый к домену хост в вашем домене Reskit.Org. Вы должны обладать установленным AD в этом хосте и настроить его согласно предыдущим рецептам из Главы 5, Изучаем .NET и из Главы 6, Управляем Active Directory. Вы пользовались этим сервером в предыдущих рецептах этой главы.

На Шаге 1 для возврата загруженных в настоящий момент времени в SRV1 поставщиков вы пользуетесь Get-PSProvider с подобным следующему выводом:

Вы можете создавать устройство поставщика PowerShell внутри любого из поставщиков (при помощи New-PSDrive). Чтобы просмотреть все устройства, которые были определены в SRV1 воспользуйтесь поставщиком Registry, на Шаге 2 вы применяете команду Get-PSDrive с подобным такому выводом:

На Шаге 3 вы пользуетесь поставщиком Реестра и его устройством HKLM: для получения подробностей текущей версии Windows с подобным следующему выводом:

На Шаге 4 для получения и отображения зарегистрированного владельца SRV1 вы применяете командлет Get-ItemProperty. В предположении что вы пользовались упоминавшемся в предисловии этой книги сценариями построения Reskit, ваш вывод на этом шаге выглядит так:

По умолчанию, устройство Alias: содержит все синонимы, которые вы определяете внутри некого сеанса PowerShell. На Шаге 5 вы выполняете выборку счётчика всех синонимов в своём устройстве Alias: с подобным приводимому ниже выводом:

Вы можете применять устройство Alias: для обнаружения синонимов конкретной команды. На Шаге 6 вы обнаруживаете все синонимы, определённые для командлета Remove-Item . Вот вывод с этого шага:

На Шаге 7 вы пользуетесь поставщиком Environment Variable для подсчёта значения числа определённых в настоящий момент времени переменных среды с подобным такому выводом:

На Шаге 8 для получения значения переменной среды, удерживающей название папки установки Windows (обычно C:\Windows, но могут быть варианты), вы применяете устройство ENV:. Вот как выглядит вывод на этом шаге:

На Шаге 9 вы выявляете устройства поставщиков FileSystem. Эти устройства, отображаемые в приводимом ниже выводе, содержат все устройства (разделы/ тома), которые вы создали в предыдущих рецептах и это выглядит так:

Всякий поставщик позволяет вам определять home drive. Когда вы установите такое домашнее устройство, вы можете пользоваться командой Set-Location и определять путь "~" для перемещения в такое домашнее устройство. Вы настраиваете такое домашнее устройство для поставщика своей файловой системы в файле $Profile, который устанавливали в Главе 1, Установка и конфигурирование PowerShell 7. На Шаге 10 вы получаете значение домашнего устройства для своего поставщика FileSystem. Вывод на этом шаге выглядит примерно так:

На Шаге 11 вы удаляете все модули и затем получаете значение счётчика функций в своём устройстве Function: со следующим выводом:

На Шаге 12 вы создаёте простую функцию, что не приводит к выводу. На Шаге 13 вы повторно проверяете своё устройство Function: для обнаружения своей новой функции. Вот вывод с этого шага:

На Шаге 14 вы просматриваете определение для функции Get-HelloWorld, содержащееся в вашем устройстве Function: . Вот что вы обнаружите в выводе:

На Шаге 15 вы получаете и подсчитываете число переменных, доступных в вашем устройстве Variable:. Вывод выглядит как- то так:

На Шаге 11 и на Шаге 13 вы создали две переменные ($Functions и $Functions2). На Шаге 16, определяя путь с символом подстановки, вы отыскиваете для переменных из своего устройства Variable: те, которые начинаются с "Function" с подобным приводимому ниже выводом:

На Шаге 17 вы получаете сертификат из хранилища доверенных издателей вашего текущего пользователя с подобным следующему выводом:

Служба WinRM реализует удалённый доступ PowerShell. Вы настраиваете стороны клиента и сервера WinRM обновляя элементы в своём устройстве WSMan:. Вы можете просмотреть значения портов, применяемых службами WSMan клиента и WSMan сервера в вашем хосте SRV1, как это показано на Шаге 18. Вот наш вывод:

На Шаге 19 вы настраиваете WinRM доверять всякому хосту через установку элемента TrustedHosts в вашем устройстве WSMan:. На этом шаге нет никакого вывода.

На Шаге 20 вы устанавливаете модули SHiPS и CimPSDrive, что не приводит к выводу. Затем, на Шаге 21 вы импортируете модуль CimPSDrive и создаёте устройство, что выглядит так:

На Шаге 22 вы пользуетесь устройством CIM: для просмотра подробностей BIOS вашей системы через WMI. Получаемый вывод отображается примерно так:

На Шаге 4 вы пользуетесь поставщиком реестра для возврата зарегистрированного владельца этой системы. Это значение было установлено при установке Windows. Если вы пользовались сценариями сборки Resource Kit с GitHub, автоматический файл XML предоставляет имя пользователя и организацию. Естественно, вы можете изменять это в своём XML впоследствии.

На Шаге 11 вы проверяете устройство Function: PowerShell. Это устройство содержит запись для каждой функции внутри вашего сеанса PowerShell. Поскольку PowerShell не обладает командой Remove-Function для удаления функции из вашего сеанса PowerShell, вы удаляете её запись (Remove-Item -Path Function:<function to remove>).

На Шаге 17 вы просматриваете доверенные сертификаты корневого CA в хранилище сертификатов своей локальной машины. Эти корневые сертификаты сопровождаются Microsoft в качестве части Microsoft Root Certifcate Program, которая поддерживает распространение корневых сертификатов, позволяя пользователям доверять продуктам Microsoft. С дополнительными сведениями об этой программе вы можете ознакомиться здесь.

На Шаге 19 вы настраиваете значение элемента WinRM TrustedHosts в "*". Это означает, что всякий раз когда PowerShell договаривается о неком удалённом соединении с удалённым хостом, он доверяет машине такого удалённого хоста, тому кем она является с её слов. а не самозванцу. Это имеет воздействие на безопасность - вам следует быть внимательным когда вы изменяете эту настройку.

Инфраструктура SHiPS, которую вы устанавливаете на Шаге 20, это некий модуль, который способствует вам при разработке некого поставщика. Эта инфраструктура, как вы можете обнаружить в данном рецепте, доступна из Галереи PowerShell или с GitHub. Для более подробного ознакомления с инфраструктурой SHiPS обращайтесь к https://4sysops.com/archives/create-a-custom-powershell-provider/. Эта инфраструктура может оказаться полезной вам для создания новых поставщиков для раскрытия данных в своей организации.

Storage Replica (SR, Реплика хранения) это функциональная возможность Windows Server 2022, которая реплицирует тома хранения в другие системы. SR доступна только в редакции Datacenter Windows Server 2022. При помощи SR вы реплицируете все имеющиеся файлы в одном томе, например, устройства F: на диск в другом хосте, например, SRV2. После настройки партнёрства Реплики хранения, по мере того как вы обновляете своё устройство F:, Windows автоматически обновляет его целевое устройство в SRV2, хотя вы не можете видеть эти файлы пока Windows реплицирует такой том (с SRV1 на SRV2). Некое партнёрство Реплики хранения также требует внутреннего журналирования устройств в хостах источника и получателя. Реплика хранения полезна для сопровождения полной реплики одного или более дисков, обычно для восстановления после сбоев.

Вы исполняете этот рецепт в SRV1, присоединённом к домену хосту в вашем домене Reskit.Org, причём после добавления и настройки дополнительных виртуальных дисков в этом хосте. Вы должны обладать установленными PowerShell 7 и VS Code в этом хосте. Данный рецепт в явном виде применяет то устройство F:, которое вы создали ранее в SRV1 в рецепте Управление физическими дисками и томами плюс некое новое устройство, G:, которое вы создали в диске с номером 2 (и в соответствующих дисках в SRV1).

На Шаге 1 вы получаете и отображаете номер диска для содержащего том F: диска в SRV1. Получаемый вывод выглядит так:

На Шаге 2 вы создаёте том F:, что отображается следующим образом:

На Шаге 3 вы создаёте содержимое в F: из SRV1, создавая 100 папок и добавляя 100 файлов в каждую из таких папок. Этот шаг не производит вывод. На Шаге 4 вы пользуетесь Measure-Object для подсчёта значения числа файлов и папок в устройстве F: из SRV1, что выглядит как- то так:

На Шаге 5 вы изучаете устройство F: в SRV2 со следующим отображением:

На Шаге 6 вы добавляете в SRV1 функциональность Реплики хранения, не производя вывод в консоль. На Шаге 7 вы добавляете функциональную возможность Реплики хранения в SRV2 с приводимым ниже выводом:

Вам требуется перезапустить SRV2 для завершения инсталляции Реплики хранения, что вы выполняете на Шаге 8. На Шаге 9 вы перезапускаете SRV1, что заканчивает весь процесс установки Реплики хранения в обоих хостах.

После перезапуска SRV2 (и SRV1), на Шаге 10 вы создаёте в SRV1 новый том. Этот том должен содержать файлы внутреннего журналирования Реплики хранения. Вот вывод того что происходит:

На Шаге 11 вы создаёте том G: в SRV2 со следующим выводом:

На Шаге 12 вы просматриваете тома в SRV1 с подобным следующему выводом:

На Шаге 13 вы просматриваете тома в SRV2 с подобным приводимому ниже выводом:

На Шаге 14 вы создаёте некую группу реплики Реплики хранения для репликации всех своих файлов с устройства F: из SRV1 в устройство F: из SRV2, при этом применяя устройство G: в обоих хоста для ведения внутренних журналов Реплики хранения. Вот вывод с этого шага:

На Шаге 15 вы повторно проверяете тома в SRV2, что выглядит так:

На Шаге 16 вы переворачиваете свою репликацию - все файлы из SRV2 теперь реплицируются в SRV1. Этот шаг не создаёт никакого вывода. На Шаге 17 вы повторно просматриваете своё партнёрство Реплики хранения с подобным следующему выводом:

На Шаге 18 вы просматриваете свои файлы в устройстве F: из SRV2, что выглядит подобно следующему:

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

На Шаге 9 вы удалённо перезапускаете SRV2. Если это первый раз когда вы удалённо перезапускаете SRV2 при помощи PowerShell, вы можете обнаружить, что эта команда никогда не возвращается даже когда SRV2 очевидно поднят и работает. Просто уничтожьте свою текущую консоль PowerShell (или закройте VS Code) и для продолжения этого рецепта откройте новую консоль.

После создания партнёрства Реплики хранения, репликации с SRV1 в SRV2, на Шаге 16 вы переворачиваете свою репликацию. Прежде чем вы перевернёте эту репликацию, вам следует убедиться что ваша изначальная репликация завершилась. В зависимости от размера реплицируемого тома, это может оказаться достаточно продолжительным. Для проверки состояния своей изначальной репликации вы можете воспользоваться командой (Get-SRGroup).Replicas.ReplicationStatus.

Пространства хранения (Storage Spaces) это технология в Windows 10 и Windows Server, которая реализует программно определяемый RAID. Вы можете добавить множество физических устройств в своё сервер или рабочую станцию и создавать отказоустойчивые тома в своём хосте. Дополнительно ознакомиться с Пространствами хранения в https://docs.microsoft.com/windows-server/storage/storage-spaces/overview.

Вы можете применять Пространства хранения в отдельном хосте или сервере для защиты от неожиданных отказов дисковых устройств. Вам стоит обратить внимание на то, что Пространства хранения выделяется из Storage Spaces Direct (также сокращаемого как S2D). S2D позволяет вам создавать некую виртуальную SAN со множеством хостов, предоставляющих SMB3 доступ к горизонтально масштабируемому файловому серверу.

Вы выполняете этот рецепт в SRV1, присоединённом к домену хосту в вашем домене Reskit.Org . Вам также потребуется DC1, Контроллер домена для вашего домена Reskit.Org . Этот рецепт применяет пять виртуальных дисков, которые вы добавили в SRV1 в самом начале рецепта Управление физическими дисками и томами.

На Шаге 1 вы изучаете доступные из SRV1 диски в начале данного рецепта:

На Шаге 2 вы применяете командлет New-StoragePool для создания нового пула хранения с использованием найденных на предыдущем шаге пяти дисков. Вывод выглядит примерно так:

На Шаге 3 вы создаёте новое Пространство хранения с названием Mirror1. Это Пространство хранения в действительности некий виртуальный диск внутри пула хранения. Вывод на этом шаге выглядит следующим образом:

На Шаге 4 вы создаёте диск с тройным зеркалированием с названием Mirror2 с приводимым ниже выводом:

На Шаге 5 в Пространстве хранения Mirror1 вы создаёте новый том, что выглядит следующим образом:

На Шаге 6 вы создаёте новый том внутри Пространства хранения с тройным зеркалированием, Mirror2, что отображается так:

На заключительном шаге этого рецепта, на Шаге 7 , при помощи команды Get-Volume вы просматриваете все доступные в SRV2 тома с приводимым ниже выводом:

На Шаге 5 и на Шаге 6 вы создаёте в SRV1 два новых устройства. Первым выступает устройство E:, которое вы создале в неком наборе зеркала, Mirror1, в вторым устройством является H:, диск созданный в Пространстве хранения с тройным зеркалированием. То устройство, которое вы создали в Mirror1 допускает утрату одного диска, в то время как устройство H:, созданное в Mirror2 может выдерживать отказы двух дисков и всё ещё предоставлять полный доступ к вашим сведениям.