Глава 2. Реализация решений хранения

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

При его правильном применении, некий сектор диска является частью дорожки (track). Каждая пластина некоторого дискового устройства подразделяется на круговые дорожки, а каждая дорожка подразделяется на секторы, как это показано на Рисунке 2-1. Исторически жёсткие диски используют секторы с размером 512- байт, хотя новые диски Расширенного формата (Advanced Format) используют секторы с размеров 4 096- байт. Данный размер сектора создаётся самим производителем такого диска; он не может быть изменён.

Однако, вы можете изменить размер своего единица распределения (allocation unit) тома диска, который иногда неправильно называют сектором. Единица распределения является термином Windows, однако она также обычно называется блоком или кластером. Единица распределения является самым малым дисковым пространством, который компьютер может выделить при сохранении файла. Например, сохранение 10- килобайтного файла на некотором диске с единицей распределения размером в 4 килобайта требует трёх единиц распределения, или 12 килобайт. Единицы размещения не могут расщепляться между файлами, так что это означает, что 2 килобайта пространства хранения теряется бесполезно, что называется пространством зазора (slack space).

Вы выбираете размер единицы распределения некоторого тома при его форматировании, как как это показано на Рисунке 2-2. Выбирая размер единицы распределения для некоторой нагрузки является компромиссом между пространством зазора и эффективностью диска. Обычно вы выбираете некий размер единицы распределения на основании значения среднего размера имеющихся файлов, которые вы намереваетесь записывать на данном томе. Если вы выбираете больший размер единицы распределения, все маленькие файлы, которые вы сохраняете на таком томе берут на себя больше объёма расходуемого впустую пространства.

Например, сохранение упоминавшегося ранее 10 кБ файла на томе с 4 кБ размером единицы распределения теряет 2 кБ. Если том имеет 64 кБ размер единицы распределения, потребуется только одна единица распределения, однако 54 кБ пространства будет утрачено впустую. Умножьте это на тысячи файлов и вы получите в конце концов существенную часть своего тома.

С другой стороны, если вы сохраняете 1- мегабайтный файл на томе с 4 кБ рамером единицы распределения, потребуются 250 единиц распределения. Если такой том применяет 64 кБ размер единицы распределения, данному файлу понадобится 16 единиц распределения. Для доступа к такому файлу диск должен выполнять поиск и чтение каждой единицы распределения индивидуально. Поиск и чтение 250 единиц распределения по своей природе менее эффективны чем поиск и чтение 16 единиц распределения, поэтому такой диск работает лучше.

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

Диски растут так быстро, что наличие разницы между размерами единиц размещения не имеют слишком большого значения. Для обычного тома среднее значение пространства зазора на файл является половиной от размера единицы распределения. Например, на томе с 4 кБ размером единицы распределения, размер пространства зазора в среднем составляет 2 кБ на файл. Для тома с 64 кБ размером единицы распределения, размер пространства зазора в среднем составляет 32 кБ на файл.Если вы храните 10 000 файлов на каждом из томов, потраченное впустую пространство составляет 20 МБ на томе с 4 кБ и 312 МБ для тома 64 кБ. Для диска, имеющего 2 ТБ или более, потеря 300 МБ не столь большое дело, в особенности, когда вы получаете лучшую эффективность при такой сделке.

Это не означает, однако, что при форматировании всех свои дисков с использованием максимального размера единицы распределения в 64 кБ вы получаете драматическое улучшение в производительности. Размер единицы распределения по умолчанию для тома NTFS до 16 ТБ составляет 4 096 байт, или 4 кБ, и это обычно отвечает требованиям системного дика. Однако, если у вас имеются тома, на которых вы храните по большей части большие файлы или видео, расширение его размера единицы распределения улучшит производительность.

Устройства жёстких дисков имеют таблицу разделов которая снабжает имеющуюся операционную систему местоположениями разделов на этом диске. Первоначальная таблица разделов MBR (master boot record, Главной загрузочной записи) была введена в 1983. Она всё ещё поддерживается Windows и всё ещё применяется во многих компьютерах. Таблица разделов MBR, однако, имеет изъяны, именно поэтому в конце 1990х была создана GPT ( GUID partition table).

Когда вы добавляете новый жёсткий диск в компьютер под управлением Windows Server 2016, вашим первым шагом после установки аппаратного средства является инициализация данного диска. Когда вы запускаете оснастку Управления диском (Disk Management), этот инструмент определяет такой новый диск и предоставляет блок Диалога инициализации (Initialize Disk), как это показано на Рисунке 2-3.

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

 

Ограничения MBR

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

Стиль разделов диска MBR поддерживает тома размером до 2 ТБ и до 4 первичных разделов. Ограничение размера обусловлено максимальным размером в 32- бита для записей такого раздела в секторе загрузки MBR. На момент разработки стиля MBR, сама идея жёсткого диска в 2 ТБ была просто фантастической, однако сегодня они являются банальностью, что делает это ограничение главным препятствием.

Наличие предела в четыре раздела также является некоторым неудобством. Начиная с PC DOS 3.3 в 1987, если вам хочется иметь более четырёх разделов на диске с MBR, вам придётся создать три первичных раздела и сделать четвёртый раздел расширенным. Затем вы можете создавать множество логических дисков в таком расширенном разделе, что отображается Vol4, Vol5 и Vol6 на Рисунке 2-4. Именно такой обходной приём присутствует в стиле разделов MBR до наших дней.

 

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

Стиль таблицы разделов GUID имеет такое название по той причине, что каждый такой раздел имеет Глобально уникальный идентификатор (GUID) GPT является частью UEFI (Unified Extensible Firmware Interface, Унифицированного расширяемого микропрограммного интерфейса) разработанного Intel в конце 1990х для замены освящённого временем стандарта микропрограмм (firmware) BIOS (Basic Input/Output System).

GPT отличается от MBR тем, что информация о разделах сохраняется во многих местах в разных местах данного диска, сопровождаемые информацией CRC (cyclical redundancy check), которая предоставляет возможность обнаружения разрушений в такой таблице разделов и восстановить эти данные из другого места. Это делает такой стиль разбиения на разделы GPT более устойчивым чем MBR.

Что ещё более важно, диски GPT больше не ограничены 2 ТБ, как в случае дисков MBR. Стиль разделов GPT поддерживает тома до 18 эксабайт (1 эксабайт = 1 миллиарду гигабайт или 2⁶⁰байт).

GPT также свободен от ограничения MBR в четыре {первичных} раздела. Спецификация GPT допускает неограниченное число разделов, однако имеющаяся в наличии реализация Windows ограничивает такое число разделов до 128 на диск. Таким образом, существует возможность создания диска с шестью разделами, как это показано на Рисунке 2-5.

 

Выбор стиля разделов

В случае, если архитектура вашего компьютера не поддерживает загрузочный раздел на основе EFI (Extensible Firmware Interface, Расширяемый микропрограммный интерфейс), возможность загрузки с какого- то диска GPT отсутствует. Если это имет место, Системный диск должен быть диском MBR и вы можете применять GPT только на отдельных дисках без возможности загрузки, применяемых для хранения данных.

Вплоть до Windows Server 2008 и Windows Vistaвсе компьютеры Windows на основе x86- использовали исключительно единственный стиль разделов MBR. Компьютеры на основе x64 платформ могли применять либо MBR, либо GPT стиль разбиения диска в случае, если GPT диск был не загрузочным.

Теперь, когда жёсткие дисковые устройства более 2 ТБ легко доступны, выбор стиля более критичен, чем когда- либо. Когда вы инициализируете диск с применением обычной оснастки Управления дисками (Disk Management), MBR является стилем разделов по умолчанию, поскольку он всегда присутствует. Вы также можете применить эту оснастку для преобразований какого- либо диска между стилями разбиения MBR и GPT, хотя вы можете выполнять это только на дисках, которые не имеют разделов или томов, созданных на них.

Когда вы используете для инициализации диска в Windows Server 2016 Диспетчер сервера (Server Manager), он применяет стиль разделов GPT, будь то диск физический или виртуальный. Диспетчер сервера не имеет управляющей поддержки MBR, хотя он на самом деле отображает такой стиль разделов в мозаике Дисков.

Таблица 2-1 сравнивает некоторые характеристики стилей разделов MBR и GPT

Таблица 2-1 Сравнение стилей разделов MBR и GPT

Master Boot Record (MBR)	GUID partition table (GPT)
Поддерживает до четырёх первичных разделов или три первичных раздела и один расширенный раздел с неограниченным числом логических дисков в расширенном разделе.	Поддерживает до 128 первичных разделов {Прим. пер.: В Windows}
Поддерживает тома до 2 терабайт	Поддерживает тома до 18 эксабайт
Скрытые (не входящие в разделы) секторы хранят критичные для платформы операции	Критичные для платформ операции хранятся в разделах
Таблица разделов MBR не поддерживает репликацию и CRC (cyclical redundancy checks)	Данная таблица разделов предоставляет репликацию и CRC, что увеличивает её надёжность

{Прим. пер.: При наличии в системе большого числа дисков настоятельно рекомендуем рассмотреть возможность их пометки. Причём как физической при помощи перманентного маркера или стикеров, так и внутренней, в секторах самого диска, подробнее в разделе Пометка дисков нашего перевода вышедшей в 2016 году книги "Мастерство FreeBSD: ZFS для профессионалов." Майкла В. Лукаса и Аллана Джуда}

 

Загрузка с дисков GPT

Основная проблема совместимости в имеющихся стилях разделов состоит в их способности к загрузке с диска GPT. Windows может выполнять загрузку с некоторого диска GPT только если такой компьютер имеет микропрограмму (firmware) UEFI и если он работает под управлением 64- битной версии Windows. Серверы должны исполняться, по крайней мере, под управлением Windows Server 2008, а рабочие станции, по крайней мере, должны работать под управлением Windows Vista.

На сегодняшнем рынке почти все представленные сервера имеют микропрограммы UEFI, а Windows Server 2016 доступен только в 64- битной версии. Если вы работаете с более старым оборудованием, вам придётся удостовериться что этот компьютер является UEFI- совместимым, прежде чем вы сможете загрузить его с диска GPT.

Если вы не можете загрузиться с диска GPT, вы всё ещё можете применять MBR в качестве своего стиля разбиения на загрузочном диске и GPT для всех других жёстких дисков в своём компьютере. GPT является существенным если ваши прочие диски имеют размер, превышающий 2 ТБ.

В Windows Server 2016 Hyper-V, виртуальные машины 1 поколения (Generation 1) эмулируют загрузку микропрограмм BIOS и должны грузиться с виртуального диска MBR. Вы можете создать дополнительные виртуальные диски GPT в точности так же как на физическом компьютере. Однако, когда вы создаёте ВМ 2 поколения (Generation 2), микропрогаммами являются UEFI и загрузочные диски применяют стиль разделов GPT. Вы можете создавать дополнительные виртуальные диски применяя как GPT, так и MBR стили разбиения, хотя и не существует убедительной причины использовать MBR.

Hyper-V основывается на формате Виртуального жёсткого диска (VHD, Virtual Hard Disk) для для хранения данных виртуального диска в файле, который можно легко перемещать с одного компьютера на другой. Вы можете создавать новые файлы VHD на некотором компьютере, исполняющем Hyper-V при помощи мастера Нового виртуального жёсткого диска (New Virtual Hard Disk), однако их также можно создавать и использовать также на компьютерах, которые не исполняют роль Hyper-V.

Windows Server 2016 поддерживает два типа образов виртуальных жёстких дисков, отличающихся своими расширениями имени файла и они таковы:

 

Создание файлов VHD и VHDX при помощи Диспетчера сервера

Оснастка Windows Server 2016 позволяет вам создавать файлы VHD и VHDX и монтировать их в вашем компьютере. Как только файл VHD или VHDX смонтирован, вы можете воспринимать его как некий жёсткий диск и использовать для хранения данных. Процесс размонтирования VHD или VHDX упаковывает сохранённые данные в некий файл, поэтому вы можете копировать его или перемещать в случае такой необходимости.

Чтобы создать VHD в Диспетчере дисков (Disk Management) воспользуйтесь следующей процедурой.

После создания и подключения VHD или VHDX, он появляется как не инициализированный диск в оснастке Диспетчера дисков и в Диспетчере сервера. Применив любой из инструментов вы можете инициализировать такой диск и создать на нём том, в точности так же, как если бы это был некий физический диск. После сохранения данных этого тома вы можете отсоединить (detach) этот VHD или VHDX и переместить его в другое расположение или смонтировать в некоторой виртуальной машине Hyper-V.

 

Создание файлов VHD и VHDX при помощи Windows PowerShell

Чтобы создать VHD или VHDX через Windows PowerShell вы применяете cmdlet New-VHD, который включён в состав модуля Hyper-V. Этот модуль устанавливается как часть свойств Инструментов управления Hyper-V (Hyper-V Management Tools). Если у вас отсутствует установленным в данной системе Hyper-V, вы можете добавить только эти инструменты PowerShell при помощи следующей команды:

install-windowsfeature -name hyper-v-powershell
 	   

Данный модуль содержит cmdlet-ы, которые позволяют вам просматривать, создавать, монтировать, объединять, а также изменять размеры VHD. Чтобы создать новый VHD вы можете воспользоваться cmdlet New-VHD, как это делает следующий пример:

new-vhd -path c:\data\disk1.vhdx -sizebytes 10gb
 	   

Данный пример команды создаёт 10 гигабайтный диск VHD с названием Disk1 в папке c:\data. Чтобы настроить другие свойства VHD вы можете воспользоваться любым из следующих параметров:

Чтобы создать некий VHD и подготовить его для использования при помощи одной команды вы можете соединить cmdlet New-VHD с другим cmdlet, применив символ конвейера, как это сделано в следующем примере:

new-vhd -path c:\data\disk1.vhdx -sizebytes 256gb -dynamic | mount-vhd -passthru | initialize-disk -passthru | new-partition -driveletter x -usemaximumsize | format-volume -filesystem ntfs -filesystemlabel data1 -confirm:$false -force
 	   

Данная команда создаёт новый 256 гигабайтный динамический файл VHDX в папке c:\data, монтирует этот диск, инициализирует его, создаёт некий раздел используя буквенное устройство X и, в самом конце, форматирует этот раздел применяя файловую систему NTFS. По завершению данной команды ваш новый VHD будет готов принимать данные.

одно из преимуществ файлов VHD и VHDX состоит в том, что вы можете легко перемещать их на любую систему. Кроме того, вы можете монтировать некий файл VHD и VHDX на физической или виртуальной машине и осуществлять доступ к нему через её файловую систему, применяя стандартный буквенный диск. Монтирование файла образа предоставляет вам полные возможности чтения/ записи, делая для вас возможным доступ к отдельным файлам или всему каталогу по мере необходимости.

Для монтирования файла VHD и VHDX вы можете применять оснастку Диспетчера дисков (Disk Management), либо cmdlet-ы Windows PowerShell.

 

Монтирование VHD и VHDX при помощи Диспетчера сервера

Вы можете выполнять монтирование и обратную процедуру существующего файла VHD или VHDX пр и помощи оснастки Диспетчера дисков (Disk Management), который использует вместо этого термины Присоединения и Отключения (Attach и Detach). Для монтирования некоторого файла примените следующую последовательность:

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

Когда вы завершаете использование данног диска, вы можете избрать его и выбрать Отключение (Detach) VHD в меню действий (Action). Все изменения, которые вы выполнили с этим диском и его содержимым сохраняются обратно в первоначальном файле VHD или VHDX.

 

Монтирование VHD и VHDX при помощи Windows PowerShell

Существует два cmdlets PowerShell, которые вы можете применять для монтирования неких существующих файлов VHD или VHDX. Их синтаксис аналогичен, но не идентичен. Cmdlet Mount-DiskImage является частью модуля Storage и он обнаруживается на всех компьютерах под управлением Windows Server 2016. Cmdlet Mount-VHD, является частью модуля Hyper-V и он доступен в системах, которые имеют установленными инструменты управления Hyper-V.

Для монтирования VHD или VHDX файла при помощи Cmdlet Mount-DiskImage, воспользуйтесь следующим синтаксисом:

mount-diskimage -imagepath filename
 	   

Для размонтирования ранее смонтированного образа вы можете воспользоваться cmdlet Dismount-DiskImage с тем же самым параметром пути образа.

Чтобы смонтировать файл VHD или VHDX при помощи cmdlet Mount-VHD, воспользуйтесь следующим синтаксисом:

mount-vhd -path filename
 	   

Для размонтирования ранее образа вы можете применять cmdlet Dismount-VHD с тем же самым параметром пути образа.

Вот примеры командной строки для этих двух cmdlet:

mount-diskimage -imagepath c:\temp\diskimage.vhdx
mount-vhd -path c:\temp\diskimage.vhdx
 	   

Для организации и хранения данных или программ на жёстком диске вы должны установить некую файловую систему, структуру поверх дискового устройства, которая позволяет вам хранить информацию на вашем компьютере. Вы устанавливаете файловые системы форматируя том на таком жёстком диске, как это показано на Рисунке 2-9. В Windows Server 2016 доступно пять файловых систем, однако для применения в современном сервере подходят только NTFS и ReFS.

NTFS был файловой системой по умолчанию для операционных систем Windows Server начиная с редакции 1993 Windows NT 3.1. Самым основным преимуществом NTFS над файловыми системами FAT является замена возможности авторизации пользовательского доступа к файлам и папкам при помощи полномочий, хранимых в Cписках избирательного управления доступом (DACL,, discretionary access control lists).

NTFS также предоставляет длинные имена файлов и большие размеры файлов и томов в сравнении с FAT. Максимальный размер для тома NTFS, применяющего по умолчанию размер единицы распределения (allocation unit) 4 кБ составляет 16 ТБ; при максимальном значении единицы распределения 64 кБ, максимальный размер тома равен 256 ТБ.

В дополнение к этим возможностям, NTFS также содержит следующие дополнительные свойства:

ReFS (Resilient File System) является новой файловой системой, введённой в Windows Server 2012 R2, которая предлагает практически неограниченные размеры файла и тома, а также увеличивает надёжность, которая устраняет необходимость в инструментах проверок на ошибки, таких как Chkdsk.exe. Максимальный размер тома ReFS составляет 2⁸⁰, или 1 ёотабайт. Максимальный размер файла составляет 16 эксабайт (или один миллион терабайт), что намного превосходит все технологии хранения предоставляемые в настоящее время. Однако опять же, кто ожидал разговоров о терабайтных дисках всего несколько лет назад?

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

Возможности обнаружения ошибок и восстановления ReFS делают её особенно полезной в пулах Пространств хранения (Storage Spaces). В пулах хранения, которые применяют зеркалирование или пространство контрольных сумм (parity space), разрушенный файл в томе ReFS может восстанавливаться автоматически с использование дублирующего зеркала или данных контрольных сумм. В виртуальных дисках Hyper-V ReFS реализует контрольные точки и резервные копии в виде системных операций метаданных, что увеличивает их скорость и эффективность.

ReFS применяет те же самые системные полномочия, что и NTFS и полностью совместима с существующими ACL. Однако, ReFS не поддерживает свойства NTFS такие как сжатие файлов, EFS (Encrypted File System) и дисковое квотирование. Диски ReFS также не могут читаться операционными системами старше Windows Server 2012 R2 и Windows 8.

Улучшения ReFS в Windows Server 2016 и, особенно, его улучшения при использовании в Hyper-V, приводят Microsoft в состояние, что она в настоящее время является более предпочтительным томом данных для операционной системы. Системные диски, требующия сжатия, шифрования и прочих свойств, доступных только NTFS, должны продолжать применение этой файловой системы, однако все остальные могут получать преимущества от предоставляемой ReFS эластичности.

Совместно используемые папки сервера позволяют сетевым пользователям осуществлять доступ к ним. После того, как вы инициализировали, подготовили раздел и отформатировали свои диски на файловом сервере, вы должны создать совместные ресурсы (share), чтобы пользователи имели возможность доступа к этим дыскам в данной сетевой среде.

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

Если вы назначены Создающим владельцем (Creator Owner) некоторой папки, вы можете выставить её в совместный доступ в Windows Server 2016, кликнув правой кнопкой по этой папке в любом окне Проводника (File Explorer), выбрав Share With (Разделять с) и затем Specific People (Определённый персонал) в контекстном меню и следовать инструкциям в блоке диалога Совместного использования файла (Sharing File), как это показано на Рисунке 2-10.

Такой метод создания совместных ресурсов предоставляет упрощённый интерфейс, который содержит только ограниченные элементы управления, такие как права доступа к данному совместному ресурсу.

Если вы не являетесь Создающим владельцем (Creator Owner) данной папки, вы можете вместо этого осуществить доступ к закладке Совместного использования (Sharing) таблицы Свойств (Properties) данной папки. Кликнув по кнопке Share в этой закладке вы запустите тот же самый блок диалога Совместного использования файлов (File Sharing), однако кликнув по кнопке Расширенного совместного использования (Advanced Sharing) и выбрав флаговый блок Разделять эту папку (Share This Folder), вы отобразите блок диалога, показанный на Рисунке 2-11. Нажатие на кнопку Прав доступа (Permissions) в блоке диалога Расширенного совместного использования (Advanced Sharing) предоставляет вам больше возможностей управления правами доступа к совместному ресурсу через стандартную инфраструктуру безопасности Windows.

Однако, чтобы получить управление над всеми имеющимися совместными ресурсами ваших дисков и ваших серверов с тем, чтобы можно было осуществлять полный контроль над их свойствами, воспользуйтесь страницей Служб файлов и хранилищ (File And Storage Services) в Диспетчере сервера.

Winddows Server 2016 поддерживает два типа папок совместных ресурсов:

Когда вы устанавливаете Windows Server 2016, программа установки инсталлирует службу роли Пространств хранения (Storage Spaces) в вашей роли Файлов и Пространств хранения (File and Storage Services ). Для создания в Диспетчере сервера совместно используемых папок SMB, однако, вы должны вначале установить службу роли Файлового сервера (File Server). Когда вы создаёте вашу первую совместно используемую папку при помощи Проводника (File Explorer), ваша система автоматически устанавливает такую службу роли Файлового сервера.

Чтобы создать совместный ресурс NFS, вы должны установить службу роли Сервера для NFS. Для установки любой из этих служб роли, вы можете воспользоваться мастером Добавления ролей и служб (Add Roles And Features) в Диспетчере сервера, либо cmdlet Install-WindowsFeature в Windows PowerShell, как это показано в приводимых ниже командах:

install-windowsfeature -name fs-fileserver
install-windowsfeature -name fs-nfs-service
 	   

 

Создание совместного ресурса SMB

Для создания совместного ресурса SMB воспользуйтесь следующей процедурой.

Вы можете использовать данную мозаику для управления совместным ресурсом кликая по нему правой кнопкой и открывая его таблицу Свойств (Properties), или кликнув Остановить совместное использование (Stop Sharing). Таблица Свойств (Properties) для некоторого совместного ресурса в Диспетчере сервера (см. Рисунок 2-16) предоставляет доступ к тому же самому управлению, которое можно обнаружить в Определении полномочий (Specify Permissions) страницы Установок управления доступом и настройки совместного ресурса (To Control Access and Configure Share Settings) в мастере Нового совместного ресурса (New Share).

 

Создание совместного ресурса NFS

Чтобы создать некий совместный ресурс NFS при помощи Диспетчера сервера примените следующую последовательность действий:

 

Создание совместных ресурсов с расширенными свойствами

Когда вы выбираете профиль Совместного ресурса SMB с расширениями (SMB Share-Advanced) или Совместного ресурса NFS с расширениями (NFS Share-Advanced), появляются две дополнительные страницы в мастере Нового совместного ресурса (New Share). Первой является страница Определения свойств управления папкой (Specify Folder Management Properties) как это показано на Рисунке 2-19, в которой вы можете выбрать значения свойств Использования папки (Folder Usage) для данного совместного ресурса. Эти значения идентифицируют тип хранимых данных в совместно применяемой папке. Вы можете использовать их для настройки правил классификации в своём Диспетчере ресурсов Файлового сервера (FSRM, File Server Resource Manager) который выполняет действия над файлами основываясь на их свойств классификации. Вы также можете определить адреса электронной почты владельца данной папки или администратора, которые будут получать уведомления когда пользователи получают отказ в доступе к данному совместному ресурсу.

Второй добавленной страницей является страница Применения квоты к папке или тому (Apply A Quota To A Folder Or Volume), в которой вы можете выбрать некую квоту для её применения в данному совместному ресурсу из списка предварительно определённых шаблонов квот. Для получения более гранулированного управления квотами вам необходимо применять FSRM.

 

Настройка прав доступа совместных ресурсов

В системах Windows совместно используемые папки имеют свою собственную систему полномочий, которая совершенно независима от самой NTFS и прочих системных полномочий. Чтобы пользователи сетевой среды получили доступ к совместному ресурсу в файловом сервере, администратор должен предоставить им соответствующие права доступа к совместному ресурсу. По умолчанию, особая сущность Everyone получает полномочия совместного ресурса Allow Read для всех новых полномочий, которые вы создаёте при помощи Проводника (File Explorer). В совместных ресурсах, создаваемых вами при помощи Диспетчера сервера, особая сущность Everyone получает полномочия совместного ресурса Allow Full Control.

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

Когда вы создаёте совместный ресурс SMB при помощи Диспетчера сервера, вы можете воспользоваться страницей Определения полномочий для управления доступом (Specify Permissions To Control Access) для настройки и полномочий NTFS, и полномочий совместного ресурса для данной совместно используемой папки. Когда вы нажимаете на Персонализацию полномочий (Customize Permissions), открывается блок диалога установок Расширенной безопасности для данной совместно используемой папки. Закладка Полномочия (Permissions), которая выбирается по умолчанию, отображает полномочия самой NTFS. Для настройки же полномочий самого совместного ресурса для данной папки выберите закладку Share (Совместного ресурса), как это показано на Рисунке 2-20.

Нажатие на кнопку Добавить (Add) открывает блок диалога Элемента прав доступа (Permission Entry) для данной папки, в котором вы выбираете правообладателя (principal) - пользователя или группу для получения этих полномочий - а также сами полномочия, которые вы хотите предоставить этому правообладателю.

Система полномочий совместных ресурсов Windows относительно проста и имеет всего три права доступа. Эти права доступа и предоставляемые ими возможности для пользователей перечислены в Таблице 2-2.

Таблица 2-2 Права доступа к совместному ресурсу и их функции

Master Boot Record (MBR)	GUID partition table (GPT)
Full Control	Изменять полномочия файла Получать право владения (ownership) файлами Выполнять все задачи, связанные с полномочиями Change
Change	Создавать папки Добавлять файлы в папки Изменять данные в файлах Добавлять (Append) данные к файлам Изменять атрибуты файлов Удалять папки и файлы Выполнять все действия разрешённые полномочиями Read
Read	Отображать имена папок, файлов, файловые данные и атрибуты Исполнять программные файлы Осуществлять доступ к прочим папкам внутри данной совместно используемой папки

При назначении полномочий совместным ресурсам вы также должны знать, что они не комбинируются как это происходит в случае полномочий NTFS. Если вы предоставляете пользователю с именем Alice полномочия Allow Read и Allow Change на совместный ресурс в виде папки C:\Documents\Alice, а позже запрещаете (Deny) её все три права доступа к папке совместного ресурса C:\Documents, полномочия Deny не дают ей возможности доступа к файлам сквозь совместный ресурс C:\Documents, включая всё то, что содержится в её папке C:\Documents\Alice. Однако, она всё ещё может осуществлять доступ к своим файлам через свой совместный ресурс C:\Documents\Alice благодаря её полномочиям Allow .... Другими словами, её совместный ресурс C:\Documents\Alice не наследует полномочия Deny от совместного ресурса C:\Documents.

Когда вы создаёте совместный ресурс NFS при помощи мастера Нового совместного ресурса (New Share) в Диспетчере сервера, страница Определения полномочий управления доступом (Specify Permissions To Control Access) предоставляет доступ только к самим полномочиям NTFS. Это обусловлено тем, что вы уже настроили полномочия данного совместного ресурса для рассматриваемого совместного NFS в странице Определения полномочий Совместного ресурса (Specify The Share Permissions) в данном мастере.

Для тех, кто предпочитает работать из командной строки, Windows Server 2016 содержит модуль Windows PowerShell с названием SmbShare, которым вы можете пользоваться для создания совместно используемых папок и управления ими. Чтобы создать новый совместный ресурс вы применяете cmdlet New-SmbShare со следующим базовым синтаксисом:

new-smbshare –name sharename -path pathname [-fullaccess groupname] [-readaccess groupname] [-changeaccess groupname] [-noaccess groupname]
 	   

Например, чтобы создать новый совместный ресурс с названием Data в папке C:\Docs с полномочиями Allow Full Control предоставляемыми особой сущности Everyone, воспользуйтесь следующей командой:

new-smbshare –name data -path c:\docs -fullaccess everyone
 	   

Помимо доступа к параметрам перечисленным здесь, существуют прочие параметры, которые вы можете включать в свою командную строку для реализации свойств, доступных в мастере Нового Совместного ресурса (New Share), включающие:

 

Управление сеансами

Когда вы создали совместный ресурс, безразлично каким образом, вы можете осуществлять его мониторинг и управление им при помощи cmdlet PowerShell. Например, выполнение cmdlet Get-SmbSession отображает все текущие сеансы клиентов, которые подключены к данному совместному ресурсу сервера, как это показано на Рисунке 2-21.

С применением информации из этого перечня вы можете завершить определённый сеанс посредством cmdlet Close-SmbSession, как это делается в примере ниже, который применяет sessionid для определения того сеанса, который следует закрыть.

close-smbsession -sessionid 154618822713
 	   

По умолчанию cmdlet выдаёт предупреждение, запрашивая у вас подтверждение на то, что вы хотите прервать данный сеанс, как это показано на Рисунке 2-22. Добавление параметра Force в данную командную строку избавляет вас от него. На компьютере клиента не высвечивается предупреждения и закрытие такого сеанса может вызвать потерю результатов работы происходящей в настоящее время в клиенте.

Вы можете закрывать сеансы на основании другой информации в выводе Get-SmbSession, что демонстрируют следующие примеры.

close-smbsession -clientcomputername 10.0.0.11
close-smbsession -clientusername adatum\Administrator
 	   

В дополнение к перечислению сеансов вы можете также применять cmdlet Get-SmbOpenFile для отображения тех файлов, которые в настоящий момент используют данные клиенты, осуществляющие в настоящий момент доступ, как это показано на Рисунке 2-23.

Чтобы волевым решением закрыть некоторый открытый файл, вы можете применить cmdlet Close-SmbOpenFile, как в примере ниже:

close-smbopenfile -fileid 154618822961
 	   

 

Удаление совместного ресурса

Для полного уничтожения некоторого совместного ресурса, включая все его сеансы, вы можете воспользоваться cmdlet Remove-SmbShare, определяя имя такого совместного ресурса в командной строке, как в приводимом примере:

remove-smbshare -name data
 	   

Вы можете настроить атрибуты данного совместного ресурса после его создания и при помощи Диспетчера сервера и из PowerShell, но вы также в любой момент после его создания также можете изменить настройки установок некоторого совместного ресурса применив прочие cmdlet из модуля SmbShare PowerShell.

 

Настройка прав доступа совместного ресурса

Вы можете изменять права доступа к совместному данному ресурсу для конкретного разделяемого ресурса применяя следующие cmdlet-ы^

 

Настройка установок сервера SMB

Модуль PowerShell SmbShare в Windows Server 2012 ввёл в обиход cmdlet Set-SmbServerConfiguration, который даёт возможность администраторам настраивать многие лежащие в основе настройки для реализации имеющегося сервера SMB. Чтобы отобразить все имеющиеся в настоящий момент у данного сервера настройки установок, выполните cmdlet Get-SmbServerConfiguration, как это показано на Рисунке 2-25.

Например, вы можете определить какая версия протокола SMB данного сервера должна применяться выполнив команды подобные следующим:

set-SmbServerConfiguration -enablesmb1protocol $false
set-SmbServerConfiguration -enablesmb2protocol $false
 	   

Windows Server 2016 применяет SMB версии 3, однако предыдущие версии доступны для поддержки клиентов с более низким уровнем. Отметим, что не существует отдельного параметра для включения SMB версии 3 самой по себе, потому что версия 3 не может работать без версии 2.

SMB версий 2 и 3 предоставляют множество свойств, которые могут улучшать производительность данного протокола, включая шифрование данных и многоканальную агрегацию связей. Отключение SMB версии 1 посредством первой команды будет гарантировать, что ваши клиенты применяют самые последние версии SMB и получают преимущества от новых свойств. В SMB версии 1 нет никакой нужды, только если у вас нет клиентов, исполняющих Windows XP или более ранние версии.

Самый последний пример отключает SMB версий 2 и 3, оставляя данный сервер применяющим только первоначальную версию SMB 1. Такой запрет ряда расширенных возможностей SMB может оказаться временно полезным для целей обнаружения неисправностей.

Когда ваш сервер исполняет SMB версии 3, вы можете включить шифрование сеанса для всего сервера или для определённого совместного ресурса в данном сервере, воспользовавшись такими командами:

set-smbserverconfiguration -encryptdata $true
set-smbserverconfiguration -name data -encryptdata $true
 	   

Когда шифрование включено, поведение такого сервера по умолчанию состоит в отклонении соединения от любого клиента, который не поддерживает шифрование SMB версии 3. Вы можете изменить это поведение при помощи такой команды:

set-SmbServerConfiguration -rejectunencryptedaccess $false
 	   

Существуют десятки других параметров, которые вы можете применять при помощи cmdlet Set-SmbServerConfiguration. Чтобы отобразить их и их свойства, выполните следующую команду:

get-help set-smbserverconfiguration -detailed
 	   

 

Настройка установок клиента SMB

В точности так же как вы можете настраивать установки сервера SMB при помощи Windows PowerShell, вы можете настраивать и установки клиента SMB. Выполнение cmdlet Get-SmbClientConfiguration отображает перечень всех доступных настроек, как это показано на Рисунке 2-26.

Как и в случае с параметрами настройки сервера SMB, большая часть этих установок не требует изменения при обычном использовании. Однако, если вы изучаете расширения в самых новых версиях SMB, вы можете пожелать временно запретить определённые свойства для целей тестирования.

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

Многоканальный SMB включён по умолчанию; если ваши компьютеры снабжены его поддержкой, он присутствует. Однако, если вы не уверены будет ли эта функция работать в вашей системе, вы можете проверить её запретив многоканальность, воспользовавшись такой командой:

set-smbclientconfiguration -enablemultichannel $false
 	   

Если ваши соединения SMB замедлятся из- за этой команды, это означает что многоканальность работала и вы можете включит её снова, поменяв $false на $true. Если же в производительности SMB нет изменений при запрете многоканальности, имеются какие- то проблемы, которые вы должны обнаружить.

Windows Server 2016 использует полномочия для управления доступом ко всем файлам и папкам NTFS, совместным ресурсам, ключам реестра, а также объектам AD DS. Каждое из таких прав доступа системы целиком не зависит от остальных, однако применяемые вами для управления ими интерфейсы похожи.

Чтобы сохранить некое право доступа, каждый элемент имеет некий список управления доступом (ACL, access control list). ACL является собранием индивидуальных назначений прав доступа, имеющих название записей управления доступом (ACE, access control entries). Каждый ACE состоит из правообладателей безопасности (security principal, имени конкретного пользователя, группы или компьютера, которым предоставляется данное право) и определённых полномочий, назначаемых этому правообладателю безопасности. Когда вы управляете правами доступа в любой системе полномочий Windows Server 2016, вы можете создавть и изменять такие ACE в ACL.

Критически важно понимать, что во всех операционных системах Windows полномочия хранятся как часть конкретного защищённого элемента, а не в безопасности правообладателя который получает этот доступ. Например, когда вы предоставляете пользователю право NTFS необходимое для доступа к некоторому файлу, создаваемая вами ACE сохраняется в ACL этого файла; она не является частью пользовательской учётной записи. Вы можете переместить этот файл на некий другой диск NTFS, а его права доступа уйдут вместе с ним.

Чтобы управлять полномочиями в Windows Server 2016 вы пользуетесь закладкой в таблице Свойств (Properties) защищаемого элемента, как это показано на Рисунке 2-27, с правообладателями безопасности, перечисленными в верху и правами, связанными с ними внизу. Права доступа к совместным ресурсам обычно находятся в закладке Прав доступа Совместного ресурса (Share Permissions), а полномочия NTFS располагаются в закладке Безопасности (Security). Все системы прав доступа Windows используют одни и те же основные интерфейсы, хотя сами полномочия видоизменяются. Диспетчер сервера также поддерживает доступ к полномочиям NTFS и совместных ресурсов, применяя слегка отличающийся интерфейс.

В системе прав доступа NTFS, которую также поддерживает ReFS, вовлечённые в процесс правообладатели безопасности являются пользователями или группами, на которых Windows ссылается с применением термина идентификаторов безопасности (SID, security identifiers). Когда пользователь пытается получить доступ к файлу или папке NTFS, система считывает маркер доступа к безопасности (security access token), который содержит конкретный SID для данного учётной записи пользователя и всех групп, к которым относится данный пользователь. Затем система сравнивает эти SID с теми, что хрантся в ACE данного файла или папки чтобы определить какие права должен иметь данный пользователь. Этот процесс имеет название авторизации.

 

Базовые и расширенные права доступа

Системы полномочий в Windows Server 2016 не являются похожими на ключ для закрытия, который предоставляет либо полный доступ или же никакого доступа совсем. Полномочия Windows разработаны для того чтобы предоставлять гранулированность, давая вам возможность предоставлять определённую градацию доступа доступа правообладателям безопасности. Например, вы можете применять полномочия NTFS для управления не только тем, кто имеет доступ к некоторой электронной таблице, но также и степенью доступа. Вы можете предоставить Ralph полномочия на чтение и изменение этой таблицы, в то время как Alice может только читать её, а Ed не может её видеть вовсе.

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

Чтобы сделать эту систему более управляемой, Windows предоставляет предварительно настроенные комбинации, которые удобны для большей части обычных сценариев управления доступом. Когда вы открываете таблицу Свойств (Properties) для элемента системы и просматриваете его закладку Безопасности (Security), те права доступа, которые вы видите имеют название базовых полномочий. Базовые полномочия являются комбинацией расширенных полномочий (advanced), которые предоставляют наиболее гранулированный контроль над каждым элементом.

Вся система полномочий NTFS имеет 14 расширенных полномочий которые вы можете назначать каким- либо папке или файлу. Однако, Она также имеет шесть базовых полномочий, которые являются различными комбинациями из этих 14 расширенных полномочий. Вы можете выбирать работу либо с базовыми, либо с расширенными полномочиями, и даже назначать оба типа полномочий в одном ACE для создания индивидуальных комбинаций. Однако, большинство пользователей работает только с базовыми полномочиями. Многие администраторы изредка, почти никогда, работают напрямую с расширенными полномочиями.

Если вы обнаружили потребность работать с расширенными полномочиями напрямую, Windows предоставляет вам такую возможность. Когда вы кликаете по кнопке Advanced в своей закладке Безопасности (Security) таблицы Свойств (Properties) любого файла или папки, вы можете получить доступ к ACE для выбора элементов системы напрямую, воспользовавшись блоком диалога Настроек расширенной безопасности, как это показано на Рисунке 2-28. Диспетчер сервера предоставляет доступ к тому же самому блоку диалога через таблицу Свойств некоторого совместного ресурса.

 

Разрешение и запрет прав доступа

Когда вы назначаете полномочия некоторому системному элементу, вы, по- существу, создаёте новый ACE в имеющемся ACL элемента. Существует два типа ACE: Allow и Deny (Разрешить и запретить). Это делает возможным их применение к задачам управления полномочиями в двух направлениях:

Большинство администраторов предпочитают подход Добавления, так как по умолчанию Windows пытается ограничить доступ к важным системным элементам отказывая в правах доступа. При тщательно разработанной иерархии полномочий применение Deny полномочий часто вообще не требуется. Внигие администраторы неодобрительно смотрят в отношении его использования, так как объединение Allow и Deny полномочий в одной и той же иерархии часто может может делать затруднительным определение реальных полномочий для определённого системного элемента.

 

Наследование прав доступа

Самым важным принципом в управлении полномочиями состоит в том, что полномочия имеют тенденцию распространяться по некоторой иерархии. Это называется наследованием полномочий. Наследование полномочий означает, что родительский элемент передаёт свои полномочия вниз своим подчинённым элементам. Например, когда вы предоставляете Alice Allow полномочия на корень диска D, все папки и подчинённые папки на таком диске D наследуют эти полномочия и Alice может осуществлять к ним доступ.

Принцип наследования чрезвычайно упрощает весь процесс предоставления полномочий. Без его наличия вам бы пришлось предоставлять правообладателю безопасности индивидуальные Allow полномочия для каждого файла, совместного ресурса, объекта и ключа к которым они должны иметь доступ. При наличии наследования вы можете предоставлять доступ ко всей файловой системе создав один набор Allow полномочий.

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

При некоторых обстоятельствах вы можете захотеть предотвратить некоторым подчинённым элементам наследовать полномочия от их родителей. Вы можете сделать это двумя способами:

 

Понимание результирующего доступа

Правообладатель безопасности может получать полномочия многими способами, поэтому для администратора важно понимать как эти полномочия взаимодействуют. Объединение Allow полномочий и Deny полномочий, которые некий правообладатель безопасности получает для данного системного элемента, будь они получены в явном виде, унаследованы или получены участием в некоторой группе, называется результирующим доступом Effective Access для данного элемента. Так как правообладатель безопасности может получать права из такого большого числа источников, могут возникать конфликты таких полномочий, поэтому существуют правила того, как комбинировать эти полномочия для организации результирующего доступа. Эти правила таковы:

Конечно, прежде чем проверить и оценить все возможные источники полномочий, вы можете просто открыть блок диалога Настроек расширенной безопасности и кликнуть по закладке Результирующего доступа (Effective Access). В данной закладке вы можете выбрать некоторого пользователя, группу или устройство и просмотреть результирующий доступ при наличии, либо без него воздействия, оказываемого определённой группой, как это показано на Рисунке 2-29.

 

Назначение базовых прав доступа NTFS

Большинство администраторов сервера практически исключительно работают с базовыми полномочиями NTFS, так как большая часть распространённых задач управления доступом не требуют от них работу напрямую с расширенными полномочиями. Таблица 2-3 перечисляет эти базовые полномочия, которые вы можете назначать файлам или папкам NTFS и те возможности, которые они могут предоставить своим обладателям.

Таблица 2-3 Базовые права доступа NTFS

Стандартные {базовые} полномочия	Когда применяются к папке, позволяют правообладателю безопасности:	Когда применяются к файлу, позволяют правообладателю безопасности:
Full control	Изменять полномочия данной папки Получать право владения (ownership) данной папкой Удалять вложенные папки и файлы, содержащиеся в этой папке Выполнять все действия, связанные со всеми прочими полномочиями папки NTFS	Изменять полномочия данного файла Получать право владения (ownership) данным файлом Выполнять все действия, связанные со всеми прочими полномочиями папки NTFS
Modify	Удалять данную папку Выполнять все действия, связанные с полномочиями Write, а также Read и Execute	Изменять данный файл Удалять данный файл Выполнять все действия, связанные с полномочиями Write, а также Read и Execute
Read и Execute	Перемещаться по ограниченным папкам для достижения прочих файлов и папок Выполнять все действия, связанные с полномочиями Read, а также List Folder Contents	Выполнять все действия, связанные с полномочиями Read Выполнять приложения
List Folder Contents	Просматривать имена всех файлов и вложенных папок, содержащихся в данной папке	Не применяется
Read	Просматривать имена всех файлов и вложенных папок, содержащихся в данной папке Просматривать владельцев, права доступа и атрибуты данной папки	Читать содержимое данного файла Просматривать владельцев, права доступа и атрибуты данного файла
Write	Создавать новые файлы и вложенных папки внутри данной папки Изменять атрибуты данной папки Просматривать владельцев и права доступа данной папки	Переписывать данный файл Изменять атрибуты данного файла Просматривать владельцев и права доступа данного файла

Чтобы назначить базовые полномочия NTFS некоторой совместно используемой папке, все опции, по существу, являются теми же самыми как и в случае полномочий совместного ресурса. Вы можете открыть таблицу Свойств (Properties) этой папки и выбрать закладку Безопасность (Security), либо открыть таблицу Свойств (Properties) некоторого совместного ресурса в Диспетчере сервера, как это происходит в следующей процедуре.

 

Назначение расширенных прав доступа NTFS

В Windows Server 2016 имеющийся интерфейс для управления расширенными правами доступа встроен в тот же самый интерфейс, который вы применяли для управления базовыми полномочиями. В блоке диалога Элемента полномочий (Permission Entry) нажатие на ссылку Отобразить расширенные полномочия (Show Advanced Permissions) изменяет перечень базовых полномочий на перечень расширенных полномочий. Затем вы можете назначать расширенные полномочия в любой комбинации в точности так же, как если бы это были базовые полномочия.

Таблица 2-4 перечисляет все расширенные полномочия, которые вы можете назначать файлам или папкам NTFS, а также те возможности, которые они могут предоставить своим обладателям.

Таблица 2-4 Расширенные права доступа NTFS

Расширенные полномочия	Функции
Full control	Полномочие полного управления разрешает или запрещает правообладателю безопасности все остальные расширенные полномочия.
Traverse folder/ Execute File	Право перемещения по папке (Traverse folder) позволяет или запрещает правообладателю безопасности возможность перемещения по папкам, на которые у него нет полномочий для доступа с тем, чтобы они могли достигать файлы или папки, на которые у них имеются полномочия для доступа и они смогли достигнуть тех файлов и папок, на которые у них имеются права на доступ. Это полномочие применяется только к папке. Полномочие Исполнения файла (Execute File) позволяет или запрещает правообладателю безопасности возможность выполнять файл программы. Это полномочие применяется только к файлу.
List Folder/ Read Data	Право Просмотра папки (List Folder) позволяет или запрещает правообладателю безопасности возможность просматривать имена всех файлов и вложенных папок, содержащихся в некоторой папке. Это полномочие применяется только к папке. Полномочие Чтения данных (Read Data) позволяет или запрещает правообладателю безопасности возможность просмотра содержимого некоторого файла. Это полномочие применяется только к файлу.
Read Attributes	Позволяет или запрещает правообладателю безопасности возможность просмотра атрибутов NTFS некоторого файла или папки.
Read Extended Attributes	Позволяет или запрещает правообладателю безопасности возможность просмотра расширенных атрибутов NTFS некоторого файла или папки.
Create Files/ Write Data	Право Создания файлов (Create Files) позволяет или запрещает правообладателю безопасности возможность создавать файлы внутри данной папки. Это полномочие применяется только к папке. Полномочие Записи данных (Write Data) позволяет или запрещает правообладателю безопасности возможность изменять данный файла или переписывать существующее содержание. Это полномочие применяется только к файлу.
Create Folders/ Append Data	Право Создания папок (Create Folders) позволяет или запрещает правообладателю безопасности возможность создавать вложенные папки внутри некоторой папки. Это полномочие применяется только к папке. Полномочие Добавления данных (Append Data) позволяет или запрещает правообладателю безопасности возможность добавлять данные в конец данного файла, однако не изменять, не удалять и не переписывать существующие данные в этом файле. Это полномочие применяется только к файлам.
Write Attributes	Позволяет или запрещает правообладателю безопасности возможность изменять атрибуты NTFS некоторого файла или папки.
Write Extended Attributes	Позволяет или запрещает правообладателю безопасности возможность изменять расширенные атрибуты NTFS некоторого файла или папки.
Delete Subfolders and Files	Позволяет или запрещает правообладателю безопасности возможность удалять вложенные папки и файлы, причём даже если право Delete не было предоставлено на такую вложенную папку или файл.
Delete	Позволяет или запрещает правообладателю безопасности возможность удалять данную папку или файл.
Read Permissions	Позволяет или запрещает правообладателю безопасности возможность чтения полномочий для данного файла или папки.
Change Permissions	Позволяет или запрещает правообладателю безопасности возможность изменения полномочий для данного файла или папки.
Take Ownership	Позволяет или запрещает правообладателю безопасности возможность получения прав владельца для данного файла или папки.
Synchronize	Позволяет или запрещает различным потокам (thread) многопоточности, многопроцессорным программам ожидание при обработке для данного файла или папки и выполнить синхронизацию с другим потоком, который должен подать сигнал об этом.

 

Понимание владельца ресурса

Так как вы изучили систему полномочий NTFS, вы можете представить себе, что она имеет возможность заблокировать некий файл или папку - то есть назначить некоторую комбинацию прав, которые совсем запретят доступ к ним, оставив эти файл или папку недоступными. На самом деле так и есть.

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

Каждый файл или папка на диске NTFS имеют владельца (owner), причём такой владелец всегда может изменять все полномочия на такой файл или папку, даже если этот владелец не имеет никаких полномочий на него или её. По умолчанию владельцем некоторых файла или папки является та учётная запись пользователя, которая создала их. Однако, любой обладатель учётной записи расширенных полномочий Получения права владения (Take Ownership), либо базового полномочия Полного контроля (Full Control) может получить право владения на данный файл или папку.

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

Другой целью наличия владельца файла или папки является вычисление квот диска. Когда вы устанавливаете квоты, определяющие максимальный объём диска, который могут потреблять конкретные пользователи, Windows вычисляет текущее потребление диска неким пользователем, складывая все размеры всех файлов и папок, которыми владеет данный пользователь.

Чтобы изменить владельца некоторого файла или папки, вы должны открыть закладку Результирующего доступа (Effective Access) в блоке диалога Установок расширенной безопасности и выбрать ссылку Изменить (Change) в настройках Владелец (Owner).

Windows Server 2016 содержит разнообразие современных технологий хранения, которые администраторы могут применять для снабжения серверов массивными объёмами пространств хранения, причём как внутри так и снаружи вашего компьютера. Эти технологии также предоставляют различные механизмы устойчивости к отказам, которые могут поддерживать доступность данных в случае отказов оборудования и возникновения прочих чрезвычайных ситуаций.

Windows Server 2016 включает в свой состав технологию виртуализацию диска называемую Пространствами хранения (Storage Spaces), которая позволяет некоторому серверу объединять имеющиеся пространства хранения от индивидуальных физических дисков и выделять это пространство для создания виртуальных дисков любого пространства , поддерживаемого данным оборудованием. Такой тип виртуализации является свойством, которое очень часто имеется в технологиях SAN (Storage Area Network, Сети хранения данных) и NAS (Network attached storage, Сетевом устройстве хранения данных), которые требуют значительных вложений средств в специализированное оборудование и административные навыки. Пространства хранения предоставляют аналогичные возможности, применяя стандартные подключаемые напрямую дисковые устройства или всего лишь внешние массивы JBOD (just-a-bunch-of-disks, простые массивы дисков).

Пространства хранения используют невыделенное дисковое пространство на дисках сервера для создания пулов хранения. пул хранения (storage pool) может прозрачно охватывать множество дисков, предоставляя накопленные ресурсы хранения, которые вы можете расширять или уменьшать по мере необходимости путём добавления или удаления их из этого пула. Используя пространство в таком пуле, вы можете создавать виртуальные диски (virtual disks) любого размера.

После создания виртуального диска вы можете создавать в нём тома в точности так же, как если бы это был физический диск. Диспетчер сервера (Server Manager) предоставляет инструменты, которые необходимы для создания пулов и виртуальных дисков хранения и управления ими, а также самой возможности создавать тома и совместные ресурсы файловой системы с некоторыми ограничениями.

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

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

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

Виртуальные диски могут также динамично выделяться (thinly provisioned), что означает, что вы определяете максимальный размер для такого диска, однако он стартует с малого размера и растёт по мере добавления в него данных. Таким образом вы можете создавать некий виртуальный диск с максимальным размером, превышающим доступное вам доступное пространство хранения.

Например, если вы планируете выделить максимально 10 ТБ для своих файлов базы данных, вы можете создать динамический (thin) 10 ТБ виртуальный диск, даже если у вас имеется только пул хранения размером 2 ТБ. Все использующие такой диск приложения будут нормально работать, постепенно добавляя данные, пока весь пул хранения почти не заполнится, причём в определённый момент эта система предупредит вас добавить дополнительное пространство для имеющегося пула. Затем вы можете установить дополнительные физические хранилища и добавить их в этот пул, постепенно наращивая его, пока он не сможет поддерживать все требующиеся 10 ТБ имеющимися в наличии дисками.

 

Создание виртуального диска

Чтобы создать простой виртуальный диск, воспользуйтесь следующей последовательностью:

Когда у вас имеется некий виртуальный диск, вы можете кликнуть правой кнопкой по немув мозаике Виртуальных дисков и выбрать Новый том (New Volume) для запуска мастера Нового тома. Начиная с этого места весь процесс создания тома идентичен тому, когда мы создавали его на физическом диске.

 

Отказоустойчивость в пространствах хранения

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

Самым существенным в отказоустойчивости является прямая избыточность. Если одна копия некоторого файла становится недоступной из- за ошибки диска или отказа, другая копия всегда включена, готова встать на место вышедшей из строя почти моментально. Когда вы создаёте некий виртуальный диск в пуле хранения, имеющаяся в вашем мастере страница Выбора схемы хранения (Select The Storage Layout) предлагает следующие три варианта:

Когда вы выбираете вариант Зеркала (Mirror), в данный мастер добавляется страница Настройки установок устойчивости (Configure The Resiliency Settings), как это показано на Рисунке 2-36. Вариант Двухходового Зеркала (Two-Way Mirror) требует два физических диска и предоставляет защиту при отказе одного диска. Вариант Трёхходового Зеркала (Three-Way Mirror) требует трёх физических дисков и предоставляет защиту при отказе двух дисков.

Выбор варианта Контрольной суммы (Parity) в странице Выбора схемы хранения не требует никаких дополнитльных настроек. Однако, если ваш пул хранения не содержит достаточного количества дисков для поддержки этой схемы, ваш мастер отобразит ошибку и заставит вас выбрать дугой вариант.

Другим способом предоставления отказоустойчивости в Пространствах хранения является назначение одного или более физических дисков в пуле хранения в качестве резерва горячей замены. Горячим резервом hot spare является некий диск, который является частью всего пула, однако его пространство не используется, пока не происходит некий отказ диска. Чтобы назначить некий диск в горячий резерв при создании пула хранения, вы изменяете его настройку по умолчанию в странице Выбора физических дисков для пула хранения (Select Physical Disks For The Storage Pool) со значения Automatic на Hot Spare, как это показано на Рисунке 2-37.

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

 

Расширение пулов хранения

Одним из основных преимуществ простанств хранения (Storage Spaces) является то, что вы можете расширять некий пул хранения в любое время, добавляя физические диски. Такие диски могут быть новыми, которые вы установили в свой сервер, или его массив хранения, лбо вы можете изменять цель использования существующих дисков, удаляя на них любые тома. Когда вы добавляете физический диск в существующий пул хранения, в него просто добавляется новое пространство. Если вы создали некий пул, который больше чем имеющееся доступным физическое пространство, доступное в этом компьютере, такое пространство на добавляемых дисках осуществляет такую компенсацию имеющейся разницы.

Чтобы расширить существующий пул хранения, воспользуйтесь следующей процедурой.

Многоуровневое хранилище (Tiered storage) в Windows Server 2016 является некоторой функцией Пространств хранения (Storage Spaces), которая предоставляет администраторам возможность использовать свои более высокопроизводительные устройства хранения для их наиболее часто применяемых файлов. Чтобы воспользоваться многоуровневым хранением в Windows Server 2016, вы создаёте некий пул хранения, который содержить и твердотельные диски (SSD) и стандартные жёсткие диски (HDD). SSD являются более быстрыми в сравнении с HDD, однако они и более дорогостоящие. затем вы создаёте некий виртуальный диск, который содержит пространство обоих типов дисков. Когда пользователь начинает сохранять свои данные на таком виртуальном диске, его система прозрачно копирует наиболее часто используемые файлы с имеющихся HDD на SSD, тем самы обеспечивая улучшение времени доступа к таким файлам.

Когда вы создаёте некий виртуальный диск в Диспетчере сервера при помощи мастера Нового виртуального диска (New Virtual Disk), страница Определения имени виртуального диска содержит флаговую кнопку Создания множества уровней на данном виртуальном диске (Create Storage Tiers On This Virtual Disk). Данная флаговая кнопка доступна только когда данный пул хранения содержит оба типа физических дисков, и SSD, и HDD. Вы также должны иметь достаточное число физических дисков каждого типа для поддержки той схемы, которую вы собираетесь использовать при создании данный виртуальный диск. Например, чтобы создать многоуровневый виртуальный диск со схемой из двух дисков в зеркале, у вас должно быть, как минимум, должны быть доступными два SSD и два HDD диска/ {Прим. пер.: см. таблицу, поясняющую все поддерживаемые конфигурации в Непосредственно подключаемых пространствах хранения и соответствующее поведение кэширования в нашем переводе 2го издания книги "Практический опыт Hyper-V 2016" Бенедикта Бергера и Ромейна Серре. А вот ссылка, с которой вы можете начать дальнейший просмотр применения многоуровневого хранения в Пространствах хранения: http://technet.microsoft.com/en-us/library/dn387076.aspx#bkmk_tiers. Также рекомендуем ознакомиться с нашими переводами Руководства по вопросам проектирования программно определяемого хранилища и разделом Пространства хранения и множество уровней книги "Hyper-V 2016 Практический опыт".}

Выберите флаговую кнопку изменения своей страницы Определения размера данного виртуального диска (Specify The Size Of The Virtual Disk) в исполняющемся мастере, как это показано на Рисунке 2-39. Вместо определения всего объёма под данный виртуальный диск, вы определяете выделяемые размеры для Быстрого уровня (Faster Tier) и Стандартного уровня (Standard Tier).

После того как данный виртуальный диск начал применяться, администратор может применять cmdlet Set-FileStorageTier для указания определённому файлу одного или другого уровня с тем, чтобы он всегда был доступен для определённого типа диска.

SAN (Storage Area Network, Сети хранения данных) являются технологией, которую используют предприятия для развёртывания ресурсов хранения и поддержки этого хранилища доступным для других присоединённых устройств. На своём самом базовом уровне, SAN является просто сетевой средой, выделенной исключительно для высокоскоростного соединения между серверами и устройствами хранения. Вместо установки установки дисковых устройств в сервер или использования напрямую подключаемых дисковых полок, SAN сосотоит из одного или более дисковых массивов, снабжённых адаптерами сетевого интерфейса, которые подключаются к серверам с применением сетевых кабелей на стадартных витых парах, либо воблоконной оптике.

Самые ранние SAN применяли последовательную технологию сетевой среды с названием Fibre Channel. Сетевые среды Fibre Channel предоставляют исключительную производительность SAN, однако является дорогостоящей и требующей специальных навыков в установке и сопровождении, что делает её относительно редкой практически везде, за исключением самых больших корпоративных установок. iSCSI (Internet Small Computer System Interface, произносится ай-сказзи), является альтернативной технологией Сети хранения данных, которая позволяет серверам и устройствам хранения выполнять обмен SCSI с применением стандартной сетевой среды IP вместо выделенной сетевой среды Fibre Channel. Это делает iSCSI намного более экономичным и практичным решением, размещая технологию SAN внутри основного диапазона установк малого и среднего размера.

Так как iSCSI пименяет стандартную IP сетевую среду для своей функциональности нижнего уровня, вы можете использовать те же самые кабели, сетевые адаптеры, коммутаторы и маршрутизаторы для SAN, которые вы применяете для локальных (LAN) и глобальных (WAN) сетей без каких либо изменений. Вы просто подключаете свои серверы и устройства хранения в существующую сетевую среду Ethernet или строите новую, используя широко доступные компоненты с более низкой стоимостью.

Благодаря своим относительно низкой стоимости и простоте, iSCSI стала доминирующей в индустрии SAN. Добавление широкой поддержки iSCSI в Windows Server 2016 и прочие операционные системы повлекло за собой появление многих продуктов устройств хранения iSCSI в широком диапазоне ценовых предложений. Несмотря на то, что SAN требует больших разовых затрат средств и времени, технология теперь доступна и скромнаым организациям.

 

Инициаторы и таргеты

Взаимодействие iSCSI основывается на двух элементах: инициаторах и таргетах. инициатор iSCSI называется именно так, потому что он инициирует весь процесс взаимодействия SCSI, при этом является аппаратным или программнум устройством, работающим в компьютере, который осуществляет доступ к имеющимся устройствам хранения в данной SAN. В сетевой среде iSCSI инициатор выполняет роль хост- адаптера, который обычно реализует применение SCSI для подключения устройств хранения к некоторому компьютеру. Данный инициатор получает запросы ввода/ вывода от своей операционной системы и отправляет их в виде команд SCSI специальным устройствам хранения в данной SAN.

Инициатор на основе аппаратного решения обычно имеет вид хост-бас адаптера (HBA, host bus adapter), некоторой платы расширения, которая содержит общую функциональность хост адаптера SCSI и сетевого адвптера гигибитного Ethernet в одном устройстве. Аппаратные инициаторы разгружают некотороую обработку SCSI из главного процессора ввашего компьютера.

Инициатор также может быть программно реализованным, например, как модуль Инициатора iSCSI, входящий в состав Windows Server 2016. При использовании программного инициатора, ваш компьютер соединяется с имеющимися устройствами хранения при помощи стандарнтых сетевых адаптеров Ethernet.

Второй половиной имеющегося уравнения iSCSI является таргет iSCSI, который интегрируется в устройство хранения, такое как дисковый массив или компьютер. Такой таргет получает команды SCSI от своего инициатора и пересылает их на устройство хранения, которое представлено LUN (logical unit number, номером логического устройствва). LUN, по существу, является адресом, который устройсва SCSI применяют для идентификации определённых устройств хранения. Отдельный LUN может представлять целый жёсткий диск, часть некоторого диска, либо часть дискового массива. Таким образом, отдельный компьютер или дисковый массив могут иметь множество LUN, мредставленное множеством таргетов.

Дисковые массивы с поддержкой iSCSI имеют таргеты, реализованные на своём уровне микропрограмм (firmware), автоматически делая различные тома в таком массиве доступными инициаторам iSCSI в имеющейся сетевой среде. Также возможна программная реализация для таргетов ISCSI в виде службы или демона, который делает весь диск или его частьв некотором компьютере доступным инициаторам.

Windows Server 2016 содержит таргет iSCSI в виде службы роли Сервера таргета iSCSI (iSCSI Target Server), части роли Служб файлов и хранилищ (File and Storage Services). Применяя возможности iSCSI инициатора и таргета в Windows Server 2016, вы можете назначать некий диск из одного сервера в качестве таргета, а затем осуществлять к нему доступ используя имеющийся в другом компьютере инициатор. На более практичном уровне, вы также можете приобрести некий дисковый массив с интегрированным таргетом iSCSI, подключить его в свою сетевую среду и позволить компьютерам Windows осуществлять доступ к нему через их инициаторы.

 

Создание таргета iSCSI

Чтобы создать некий таргет iSCSI в Windows Server 2016, вы должны вначале установить службу роли Сервера таргета iSCSI ( iSCSI Target Server), воспользовавшись мастером Добавления ролей и служб в Диспетчере сервера, как это показано на Рисунке 2-40, или выполнив следующую команду в окне Windows PowerShell с полномочиями администратора:

install-windowsfeature -name fs-iscsitarget-server -installmanagementtools
 	   

Когда вы установите эту службу роли, вы можете продолжить демонстрацию применения iSCSI, создав некий виртуальный диск iSCSI и какой- то таргет iSCSI, используя пространство на одном из дисков компьютера, как это описано в приводимой ниже процедуре.

 

Применение инициатора iSCSI

Когда доступен некий таргет iSCSI - созданный вами в некотором скервере или встроенный в аппаратное устрйство - вы можете подключиться к нему и осуществлять доступ к его хранилищу воспользовавшись имеющимся в Windows Server 2016 инициатором iSCSI. В отличие от Сервера таргета iSCSI (iSCSI Target Server), инициатор iSCSI устанавливается по умолчанию в Windows Server 2016; вам ничего не требуется устанавливать.

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

Раз уж данный инициатор соединён с имеющимся таргетом, вы можете открыть консоль Диспетчера дисков (Disk Management) и увидеть, что данный созданный вами на компьютере таргета виртуальный диск iSCSI теперь находится в списке, как это показано на Рисунке 2-47.

Так как этот виртуальный диск был только что создан, он появляется в консоли Диспетчера дисков как Отключённый (Offline) и Не инициализированный (Uninitialized). Чтобы воспользоваться этим диском, вы должны перевести его во включённое состояние , проинициализировать, а затем создать некий том на нём, в точности так же, как если бы он был вашим локальным диском.

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

После того как таргеты и инициаторы iSCSI заняли свои места, основной остающейся во взаимодействии iSCSI проблемой становится то, как эти двое могут найти друг друга. iSNS (Internet Storage Name Service, Интернет служба имён хранилищ) делает это возможным через регистрацию наличия инициаторов и таргетов в сетевой среде и ответы на запросы от клиентов iSNS. Windows Server 2016 содержит в виде свойства некую реализацию iSNS, которая может предоставлять службу идентификации всей сетевой среде.

iSNS состоит из следующих четырёх основных компонентов:

Чтобы создать некий сервер iSNS в Windows Server 2016, вы должны установить необходимое свойство iSNS при помощи мастера Добавления роли и свойств (Add Roles And Features) или следующей командой PowerShell:

install-WindowsFeature -name isns
 	   

После установки данного сервера iSNS он автоматически регистрирует все доступные в вашей сетевой среде таргеты iSCSI, однако вы должны регистрировать инициаторы iSCSI вручную при помощи приводимой ниже последовательности:

После добавления вашего сервера iSNS в ваших инициаторах iSCSI они регистрируются в базе данных iSCSI. Когда вы выбираете в Диспетчере Сервера Средства (Tools), Сервер iSNS, появляется таблица Свойств сервера iSNS (iSNS Server Properties) как это показано на Рисунке 2-49, перечисляющая все зарегистрированные вами инициаторы iSCSI.

Первоначально концепция SAN именовала отдельную сетевую среду, выделенную под обмен с хранилищем. Уже подключённые к локальной сетевой среде (LAN) сервера должны были иметь дополнительный сетевой адаптер для подключения к SAN, чтобы предоставлять им доступ к обособленным устройствам хранения. Одной из важнейших инноваций iSCSI является её возможность применять стандартную сетевую среду Ethernet для взаимодействия между инициаторами и таргетами. Fibre Channel теперь также имеет стандарт FCoE (Fiber Channel over Ethernet) для работы с этим протоколом в стандартной сетевой среде. Это, однако, порождает некий вопрос. Если существует возможность обработки обмена SAN в стандартной сетевой среде Ethernet, почему бы вам просто не применять ту, что уже находится в распоряжении, и не обрабатывать совместно обмен SAN и LAN?

Причина, по которой это не является лучшей идеей, состоит в том способе, которым Ethernet управляет доступом в своей сетевой среде. Ethernet является протоколом с "потерями", что означает, что столкновения пакетов являются ожидаемыми событиями. Исполняющийся в LAN обмен TCP/IP имеет обнаружение ошибок и механизмы их исправления для обработки утраченных пакетов, являющихся результатом таких столкновений. Протоколы SAN являются более привередливыми к утрате пакетов и обычно требуют непрерывного потока обмена для эффективной работы.

результат состоит в том, что обмены SAN и LAN плохо работают вместе пока нет размещённого механизма, гарантирующего что каждый из них получит ту пропускную способность, которая ему требуется постоянно. Именно в этом месте в игру вступает объединение сетей центра данных. DCB (Datacenter bridging, Объединение сетей центра данных мостами) является последовательностью стандартов, опубликованных IEEE (Institute of Electrical and Electronics Engineers), которые определяют механизмы для контроля потока и управления полосой пропускания в сетевой среде с множеством типов обмена. Windows Server 2016 содержит реализацию DCB, которая позволяет администраторам выделять определённое значение полосы пропускания различным видам обмена в имеющейся сетевой среде. В результате получается то, что называется конвергентной сетевой средой. Выделяя некое значение в процентах общей пропускной способности сети обмену iSCSI, например, SAN продолжает работать надлежащим образом, даже когда LAN интенсивно используется.

Windows Server 2016 содержит Объединение сетей центра данных (DCB) в виде свойства, которое вы можете установить обычным образом, воспользовавшись в Диспетчере сервера мастером Добавлением ролей и свойств (Add Roles And Features) или cmdlet Install-WindowsFeature в PowerShell. Однако, применение DCB в вашей сетевой среде помимо программного обеспечения требует специального оборудования.

Чтобы сервер мог применять DCB, вы должны иметь CNA (converged network adapter, конвергентный сетевой адаптер, который поддерживает стандарты DCB). CNA является объединённым устройством, которое содержит стандартные сетевые возможности Ethernet плюс HBA (host bus adapter) SAN с поддержкой iSCSI, FCoE или комбинацией типов SAN. Ваши устройства хранения также должны поддерживать DCB, также как и все коммутаторы, соединяющие ваши устройства воедино.

Реализация DCB в Windows Server 2016 содержит модуль PowerShell с названием DcbQos, который включает cmdlets, позволяющие вам настраивать CNA в вашем сервере, как это описывается в следующих разделах.

 

Настройка DCBX Willing bit

DCBX Willing является функцией одного бита в имеющемся стандарте DCB, которая управляет источником применяемых конфигурационных настроек CNA. DCBX является механизмом, при помощи которого каждое устройство DCB в сетевой среде может распространять свои установленные настройки на остальные устройства. По умолчанию бит DCBX Willing в CNA установлен в значение True, что делает возможным для ваших устройств хранения или коммутаторов изменять его настройки. Изменение значения этого бита в False позволяет CNA получать только локальные установочные настройки, а именно те, которые вы создаёте при помощи cmdlet DcbQos в PowerShell.

Чтобы установить бит DCBX Willing в значение False, вы можете воспользоваться cmdlet Set-NetQoSbcdxSetting, как в примере ниже:

set-netqosdcbxsetting -willing 0
 	   

Когда CNA находится под вашим управлением, вы можете настроить его на работу в соответствии с вашей спецификацией.

 

Создание классов обмена

Классы обмена (Traffic classes) являются тем, как вы разделяете все типы обмена в своей конвергентной сетевой среде. По умолчанию существует единственный класс обмена, который получает 100 процентов от всей полосы пропускания вашей сетевой среды и все восемь уровней приоритета. Вы можете создать до семи дополнительных классов обмена, до общего числа восемь, хотя вы должны удостовериться, что все прочие устройства DCB в вашей сетевой среде способны распознавать так много.

Чтобы создать новый класс обмена, вы применяете cmdlet New-NetQosTrafficClass, как в примере ниже:

new-netqostrafficclass -name "smb class" -priority 2 -bandwidthpercentage 60 -algorithm ets
 	   

В данном примере вы создаёте новый класс обмена для обмена SMB, использующий 60 процентов от общей полосы пропускания сетевой среды с приоритетом 2. Параметр Algorithm определяет применение одного из двух алгоритмов выбора обмена, задающихся стандартом DCB, EBS или Strict.

 

Создание политик QoS

Политики QoS (quality of service, Уровня качества обслуживания) определяют какой тип обмена какому классу назначается. Чтобы создать некую политику QoS, вы пользуетесь cmdlet New-NetQosTrafficClass, как в примере ниже:

new-netqospolicy -name "smb policy" -smb -priorityvalue8021action 2
 	   

В данном примере параметр smb фильтрует весь обмен на основе TCP (Traffic Control Protocol) и UDP (User Datagram Protocol) порта 445, который является известным портом для обмена SMB. Данный cmdlet принимает следующие параметры фильтрации:

Помимо этих предварительно определённых фильтров, вы также можете идентифицировать тип обмена другими способами, используя такие параметры:

 

Включение Управления потоком на основе приоритетов (PFC)

PFC (IPriority-based Flow Control, Управление потоком на основе приоритетов) как это определено одним из основных стандартов DCB является методом организации сетевого обмена для предоставления обмена данных без потерь. Обычно вы должны включать PFC для обмена хранилищ которые чувствительны к потере пакетов.

Чтобы включить PFC для определённого приоритета обмена вы пользуетесь cmdlet Enable-NetQosFlowControl, как в примере ниже:

enable-netqosflowcontrol -priority 3
 	   

Ввод/ вывод со множеством путей (MPIO) является свойством Windows Server 2016, которое позволяет некоторому серверу подключаться к iSCSI, Fibre Channel или Serial Attached SCSI (SAS) устройствам SAN таким образом, чтобы иметь возможность перехода на альтернативный путь в случае отказа соединения.

Для реализации ввода/ вывода со множеством путей у вас должны иметься следующие компоненты:

Когда у вас имеется установленным свойство Множества путей ввода/ вывода, вы можете получить доступ в таблицу Свойств MPIO выбрав в Диспетчере сервера Средства (Tools) | MPIO. По умолчанию появляется закладка Устройств MPIO, как это показано на Рисунке 2-50.

В блоке диалога Устройств (Devices) возникает единственный Microsoft DSM. Чтобы добавить DSM, поставляемый производителем вашего оборудования, выберите закладку Установки DSM, как это показано на Рисунке 2-51, отыщите местоположение файла INF, поставляемого с данным DCM и кликните Установить (Install). Данный метод применим только в DSM, которые не поддерживаются своим собственным программным обеспечением установки. {Прим. пер.: в разделе Установка драйвера принтера для применения с перенаправлением в нашем переводе Книга рецептов Windows Server 2016 Джордана Краузе вы можете найти рецепт, описывающий установку драйвера в том числе из пакета инсталляции поставщика средствами Windows.}

Закладка Обнаружения множества путей, показанная на Рисунке 2-52, отображает устройства для которых MPIO обнаружил множество путей в имеющейся сетевой среде. По умолчанию iSCSI устройства не появляются в данной закладке, однако вы можете включить их, выбрав флаговую кнопку Добавления поддержки для устройств iSCSI (Add Support For iSCSI Devices).

 

Определение устройств

Windows Server 2016 полагается на PnP (Plug and Play) для определения и идентификации устройств хранения к которым подключается конкретный сервер. В отсутствие множества путей ввода/ вывода сервер с двумя сетевыми интерфейсами подключаемый к одиночному устройству хранения наблюдал бы PnP как два устройства хранения.

При установленном MPIO, всякий раз, когда PnP определяет новое устройство хранения, имеющийся драйвер MPIO сканирует имеющиеся в наличии DSM для обнаружения того, который соответствует данному устройству. Когда DSM утверждает данное устройство, драйвер MPIO проверяет, что данное устройство активно и готово к данным. Когда PnP определяет то же самое устройство вновь при использовании другого сетевого интерфейса, имеющиеся драйвер MPIO и DSM идентифицируют его в качестве такового и создают группу с множеством путей, которая получает адрес с применением уникального идентификатора. {Прим. пер.: с подробностями процесса можно ознакомиться на примере Настройки множественности путей в ZFS в нашем переводе Книги ZFS для профессионалов Майкла В. Лукаса и Аллана Джуда 2016г.}

 

Политики DSM

Помимо отказоустойчивости, ввод/ вывод со множеством путей могут также поддерживать балансировку нагрузки, при которой запросы хранилища применяют различные пути к имеющемуся устройству SAN для минимизации перегрузок сетевого обмена. Microsoft DSM поддерживает следующие политики:

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

Реплика хранения поддерживает два виде репликации: синхронную и асинхронную.

Реплика хранения разработана для функционирования в следующих трёх основных сценариях:

Хотя существует большое число приложений для репликации данных, те не менее SR разработана для предоставления возможностей отказоустойчивости в случае возникновения отказа некоторого оборудования или другого чрезвычайного происшествия. Путём репликации ваших данных в другое помещение, другое здание, или другой город, вы можете легко переместить свою рабочую нагрузку в другое место после, или даже до возникновения катастрофического события. В случае неотвратимой катастрофы, такой как приближающийся ураган, некая организация со своими данными, реплицированными на некий сервер или узел, или кластер в другом городе подготовлена к переходу на такую реплику за несколько минут до предупреждения.

Репликация SR является однонаправленной, от обозначенного тома источника к некоторому тому получателя. Когда вы создаёте риплицируемое сотрудничество между ними, SR осуществляет размонтирование участвующего в процессе тома получателя, а также его буквенного устройства или точки монтирования. Такой том получателя следовательно не доступен пользователям пока он вовлечён в процесс реплицируемого сотрудничества (replication partnership). В случае возникновения отказа (или при проверке), а также когда вам необходимо осуществить доступ к репликации, вы удаляете такое сотрудничество и данный том получателя становится доступным снова.

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

Репликации, выполняемые Репликой хранения разработаны для улучшения инструментария Windows, которым администраторы должны были применять в прошлом, такой как Репликация Распределённой файловой системы (DFS, Distributed File System), которая основана на файлах и исключительно асинхронная. SR применяет для своего взаимодействия SMB версии 3, который предоставляет такие свойства, как многоканальная агрегация связей, шифрование данных, а также цифровую подпись. Репликации также имеют блочную основу, не файловую, как в случае Репликации DFS. Благодаря этому не существует проблем с утратой данных в реплике по причине наличия открытых файлы, которые не могут быть доступными в процессе репликации.

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

Реализация Реплик хранения в вашей сетевой среде требует тщательного планирования и выполнения массы предварительных требований. Создание реплицируемого сотрудничества (replication partnership) по существу всего лишь исполнение cmdlet PowerShell (New-SRPartnership), однако оно происходит в конце всей процедуры.

Реплика хранения является свойством Windows, которое доступно только в редакции Datacenteer Windows Server 2016. Вы устанавливаете это свойство при помощи мастера Добавления ролей и свойств Диспетчера сервера или выполнив следующую команду PowerShell:

install-windowsfeature -name storage-replica, fs-fileserver -includemanagementtools -restart
 	   

Следующий шаг состоит в подготовке вашей инфраструктуры хранения для репликации. Индивидуальные задачи для этой части вашей процедуры изменяются в зависимости от того используете ли вы сценарий сервер-к-серверу, кластер-к-кластеру или растяжимого кластера. После того, как вы настроите инфраструктуру хранения своего сервера или кластера, все три сценария перейдут к тестированию и репликации топологии и созданию SR сотрудничества между серверами.

 

Подготовка инфраструктуры хранения

Для применения SR те сервера, которые будут работать как партнёры по репликации, будь то они отдельным сервером, или входят в состав кластера, должны исполняться под управлением редакции Datacenter Windows Server 2016. Два гигабайта оперативной памяти в каждом сервере являются железным минимумом; рекомендуется иметь по крайней мере четыре гигабайта. Кроме того, вся инфраструктура должна быть настроена следующим образом:

 

Проверка топологии SR

В составе PowerShell cmdlet, включаемых в состав SR имеется один с названием TestSRTopology, который выполняет различные проверки предварительных требований и производительности на обоих серверах, которые становятся партнёрами по репликации и в их сетевом соединении и создаёт некий HTML отчёт содержащий все результаты.

Данный cmdlet получает параметры, определяющие имена серверов, которые становятся партнёрами источника и получателя в репликации, те тома, которые подлежат репликации, продолжительность тестирования и местоположение для результирующего отчёта, как в следующем примере:

test-srtopology -sourcecomputername servera -sourcevolumename f: -sourcelogvolumename e: -destinationcomputername serverb -destinationvolumename f: -destinationlogvolumename e: -durationinminutes 30 -resultpath c:temp
 	   

Данный cmdlet вначале проверяет удовлетворяют ли сами сервера и имеющиеся подсистемы хранения требованиям для SR, как это показано на Рисунке 2-56.

Затем данный cmdlet выполняет тестирование производительности на протяжении того интервала времени, который вы задали в его командной строке. Идеальным способом для выполнения этого теста является тот, при котором сервер источника находится при рабочей нагрузке. Данный тест производит измерение производительности синхронизации между заданных источника и получателя для определения того, достаточна ли пропускная способность для синхронной репликации и представляет результаты в виде графика, как это показано на Рисунке 2-57.

 

Настройка кластеризации

После настройки всех партнёров репликации вы можете приступить обычным образом к реализации своего кластерного решения для сценария кластер-к-кластеру или растяжимого кластера. Затем вы настраиваете каждый кластер так, чтобы они имели полный доступ друг к другу, применяя cmdlet Grant-SRAccess, как это делается в примере ниже:

grant-sraccess -computername servera -cluster clustera
grant-sraccess -computername serverb -cluster clusterb
 	   

Для сценария растяжимого кластера вы создаёте такой кластер и делаете его реплицируемый диск источника неким совместно используемым в кластере томом (CSV, cluster shared volume) при помощи cmdlet Add-ClusterSharedVolume. Вы также можете сделать это и создать реплицируемое содружество при помощи консоли Диспетчера отказоустойчивого кластера.

 

Создание SR сотрудничества

Допустим, что ваши серверы и инфраструктура хранения прошли проверку Test-SRTopology, и ваш(и) кластер(ы) готовы к использованию, тогда вы можете приступить к установлению реального реплицируемого партнёрства между имеющимися серверами источника и получателя. Вы выполняете это посредством cmdlet New-SRPartnership, причём большая часть параметров та же самая, что и для Test-SRTopology, как в следующем примере:

new-srpartnership -sourcecomputername servera -sourcergname group1 -sourcevolumename f: -sourcelogvolumename e: -destinationcomputername serverb -destinationrgname group2 -destinationvolumename f: -destinationlogvolumename e:
 	   

Когда вы создали данное сотрудничество, начинается начальная синхронизация, которая может занять некое продолжительное время, зависящее от имеющегося размера ваших томов. Чтобы наблюдать за процессом исполнения вы можете воспользоваться cmdlet Get-WinEvent, для проверки событий журнала со следующими кодами: 5015, 5002, 5004, 1237, 5001 и 2200, как это показано на Рисунке 2-58.

Вы также можете отображать состояние данного сотрудничества при помощи cmdlet Get-SRGroup, как это показано на Рисунке 2-59.

Когда данное сотрудничество синхронизации готово, вы можете переключиться к отработке отказа, воспользовавшись cmdlet Set-SRPartnership для замены ролей источника и получателя, как в приведённом ниже примере. Это сделает тома получателя доступными к использованию вновь.

set-srpartnership -newsourcecomputername serverb -sourcergname group2 -destinationcomputername servera -destinationrgname group1
 	   

Дедупликация данных является службой роли в Windows Server 2016, которая сохраняет пространство хранения в томе NTFS путём определения избыточных данных и сохранения единственной копии таких данных вместо наличия множества копий. Это является основным базовым принципом работы для многих продуктов сжатия данных, однако Дедупликация данных (Data Duplication) улучшена многими другими технологиями работающими на уровне тома, а не на уровне файлов.

Чтобы применять дедупликацию данных на своих томах, вы должны в начале установить службу роли Дедупрликации данных (Data Deduplication), которая является чстью роли Служб файлов и хранилищ (File and Storage Services). Вы можете сделать это при помощи мастера Добавления ролей и свойств (Add Roles And Features) или воспользовавшись cmdlet Install-WindowsFeature в PowerShell следующим образом:

install-windowsfeature -name fs-data-deduplication
 	   

После установки Дедупликации данных вы управляете ею из Диспетчера сервера или при помощи cmdlet PowerShell.

 

Настройка дедупликации при помощи Диспетчера сервера

Для применения дедупликации данных вы должны включит её на определённых томах. Для выполнения этого в Диспетчере сервера воспользуйтесь следующей последовательностью:

 

Настройка дедупликации при помощи PowerShell

Чтобы включить дедупликацию для некоторого тома с использованием PowerShell, вы применяете cmdlet Enable-DedupVolume, как это сделано в примере ниже:

enable-dedupvolume -volume "e:" -usagetype default
 	   

Функции данных параметров таковы:

enable-dedupvolume -volume "\\?\volume{26a21bda-a627-11d7-9931-806e6f6e6963}" -usagetype backup
 	   

Дедупликация данных оптимизирует некоторый том выбирая те файлы, которые являются претендентами на оптимизацию, выхватывая их во фрагменты переменного размера и сканируя их на предмет их уникальности. Являющийся уникальным фрагмент копируется в отдельную область диска, называемую хранилищем фрагментов (chunk store) и замещается в своём первоначальном расположении специальным тегом с названием точки повторного разбора (reparse point), отправляющую к новому расположению этого фрагмента. Если фрагмент идентичен уже существующему в этом хранилище, данная система заменяет её на точку повторного разбора и удаляет первоначальный фрагмент.

Этот подход к дедупликации присутствует продолжительное время, однако многие прочие продукты применяют его для индивидуальных файлов. Дедупликация данных в Windows Server 2016 работает во всём томе, не только в одном файле за раз. Тем самым, вместо наличия некоторой копии того же самого фрагмента во всех файлах, имеется только одна копия для всего тома. В случае технологии в более ранних версиях Windows Server с названием Хранилища единственного экземпляра (SIS, Single Instance Store), которая замещала дедупликацию данных, том сопровождал единственную копию всего файла вместо множества дубликатов. Фрагменты, обычно будучи по размеру меньше файлов, имеют гораздо больше шансов быть дублированными в этом томе, что предоставляет большее соотношение сжатия.

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

Если приложение или пользователь осуществляют изменение данного файла, система записывает его обратно на данный том в стандартном виде без оптимизации. Данный файл остаётся не оптимизированным, пока не наступит время следующего задания оптимизации. Такое обусловленное рабочей нагрузкой накопление файлов без оптимизации имеет название мешалки (смесителя, churn). Заложенная в самой природе самой системы обработка после записи предотвращает любые задержки или взаимодействия с записями в данный том.

Дедупликация данных также выполняет и другую работу в промежутках между оптимизациями. Сборка мусора (garbage collection) является термином для задания, который просматривает хранилище фрагментов на предмет тех фрагментов, которые больше не имеют связанных с ним точек повторного разбора, как правило, из- за изменения или удаления файлов. Интегрированная очистка (Integrity scrubbing) является заданием, которое осуществляет поиск повреждений или разрушений в имеющемся хранилище фрагментов, замещающим утраченные данные данными зеркалировния или контрольных сумм. Наконец, удаление оптимизации unoptimization является заданием, которое восстаналивает все оптимизированные файлы на данном томе до их первоначальных состояний, запрещая для этого тома выполнение Дедупликаци данных.

 

Оптимизация соотношений

Объем пространства хранения освобождаемый данным приложением дедупликации данных на томе зависит от множества факторов, включая формат самих файлов и природы порождаемых этими данных рабочих нагрузок. Обычно продукты сжатия на основе файлов исполняемые двоичные файлы могут сжиматься до 80 процентов, а также образы растрового изображения способны сжиматься до 80 процентов. Если вы применяете процесс дедупликации данных к отдельному файлу, скорее всего, результат будет аналогичным.

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

В качестве примера возьмём том, кторый содержит множество файлов образов VHD Hyper-V, причём все они содержат установленную гостевую операционную систему Windows 10 применяемую командой разработчиков программного обеспечения. Так как содержимое этих файлов VHD весьма схоже, будет существовать великое множество идентичных фрагментов. Microsoft оценивает сохранение пространства для томов, содержащих файлы образов как значения составляющие от 80 до 95 процентов. Таким образом, почти полный том, содержащий 1 ТБ данных может быть уменьшен до 100 ГБ или даже менее того, высвобождая 900 ГБ вновь создаваемог свободного пространства.

Это пример наилучшего практическго применения. Некий том в файловом сервере обычно содержащийт смесь файлов пользователей может оптимизироваться на 50 - 60 процентов.

 

Оценка нагрузок

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

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

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

Дедупликация данных содержит Инструментарий оценки сохранения дедупликацией данных (Data Deduplication Savings Evaluation Tool, Ddpeval.exe), который может применяться для проверки некоторого тома на предмет того, какой объём хранилища может быть сохранён в результате оптимизации. Ddpeval является интсрументом командной строки, который вы исполняете определив буквенное устройство для оценки. Общий результат определяет какой объём сохранения вы можете ожидать на выбранном наборе данных, как это показано на Рисунке 2-62.

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

После того, как вы установили дедупликацию данных и включили её на томах, мозаика Тома (Volumes) в Диспетчере сервера изменяется для отображения колонок Соотношения дедупликации (Deduplication Rate) и Сохраняемого дедупликацией (Deduplication Savings), как это показано на Рисунке 2-63. Соотношение дедупликации определяет процентное соотношение дискового пространства первоначальных файлов к занимаемому ими пространству после очистки, а Сохраняемое дедупликацией определяет объём очищенного дискового пространства в гигабайтах.

Вы также можете осуществлять мониторинг самого процесса дедупликации применяя PowerShell с cmdlet Get-DedupStatus. Когда вы исполняете этот cmdlet сам по себе, он отображает всего несколько статистических данных. Чтобы просмотреть всё отображаемое им, как это показано на Рисунке 2-64, перенаправьте его вывод в cmdlet Format-List следующим образом:

get-dedupostatus | format-list
 	   

Нулевое значение LastOptimizationResult обозначает успешность данной операции. Если после начальной дедупликации задание начинает показывать неудачу, это обычно происходит из -за того, что данный процесс дедупликации не имеет достаточного времени для сохранения всех создаваемых данной рабочей нагрузкой изменений (называемых мешалкой, churn). Вам может понадобиться увеличить продолжительность заданий дедупликации, или предназначенный им приоритет, чтобы разрешить данную проблему.

Для обзора истории заданий дедупликации некоторого сервера вы можете просматривать журналы событий Windows. События Дедупликации данных размещаются в контейнере Applications and Services Logs\Windows\Deduplication\Operational.

Резервные копирования на жёсткие диски, подобное тому, которое выполняет Сервер резервного копирования Windows (Windows Server Backup) являются особенно хорошими претендентами для оптимизации, так как создаваемые программным обеспечение снимки имеют тенденцию очень слабо отличаться друг от друга. Если вы осуществляете полное резервное копирование какого- то сервера каждую неделю, например, только небольшой процент данных сервера скорее всего будет изменяться каждую неделю и дедупликация данных может прекратить всю такую избыточность.

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

Вариант использования виртуального сервера резервного копирования (Virtualized Backup Server) специально разработан для работы с резервными копиями программных решений подобных Диспетчеру защиты данных Системного центра Microsoft (DPM, Microsoft System Center Data Protection Manager), в котором программное обеспечение резервного копирования исполняется под управлением виртуальной машины Hyper-V и сохраняет свои резервные копии в файлах VHD или VHDX на томах с включённой дедупликацией данных.

Так как задание резервного копирования может создавать относительно большой объём новых данных, настройки оптимизации для сценария резервного копирования отличаются от настроек для прочих предварительных установок, а именно в том, что они включают обсуждающийся процесс оптимизации для его работы с высоким приоритетом на данном сервере. Администраторы должны наблюдать за заданиями оптимизации на постоянной основе чтобы гарантировать что они остаются с таким более высоким соотношением мешалки (churn) чем обычно присутствует в обычных файловых серверах.

В этом мысленном эксперименте продемонстрируйте свои навыки и знания тем, обсуждавшихся в данной главе. Вы можете найти на этот опыт в следующем разделе.

Вы работаете в службе технической поддержки Contoso Corp., в качестве подрядчика, и пользователь с именем Ральф запросил доступ к файлам для Alamo, нового секретного проекта. Файлы данного проекта Alamo хранятся в соместно используемой папке в рабочей группе файлового сервера Windows Server 2016, который закрыт в безопасном подземном оборудовании хранения данных. После проверки что Ральф имеет соответствующий доступ к закрытой информации для данного проекта вы создаёте новую группу в этом файловом сервере с названием ALAMO_USERS и добавляете учётную запись пользователя Ralf в эту группу. Затем вы добавляете группу ALAMO_USERS в список управления доступом (ACL) для папки Alamo в этом файловом сервере и назначаете этой группе следующие права доступа NTFS:

Через какое- то время Ральф обращается к вам и говорит что он имеет доступ к папке Alamo и читает все файлы, котоые там хранятся, однако он не может сохранять изменения обратно на этот сервер. Что скорее всего вызывает эту проблему?

Данный раздел содержит решение мысленного эксперимента.

Ральф скорее всего не имеет достаточных полномочий на совместно используемый раздел для доступа на чтение/ запись к файлам Alamo. По умолчанию, когда вы открываете для совместного использования некую папку в сервере робочей группы (workgroup) при помощи Проводника (File Explorer), специальная сущность Everyone получает только права доступа Read к совместному ресурсу. После того как вы предоставите группе ALAMO_USER права совмесного ресурса Allow Full Control, Ральф должен получить возможность сохранять свои изменения во всех файлах Alamo.