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

Пулы носителей приложений (Application) . Создаются программными приложениями в целях группирования и отслеживания носителей. В Windows Server 2003 для Backup и Remote Storage поддерживаются свои пулы носителей.
Системные пулы носителей (System) . Создаются и управляются с помощью RSM и включают следующие пулы носителей: Неопознанные (Unrecognized), Свободные (Free) и Импортированные (Import).

Носители можно перемещать из одного пула носителей в другой, и это всегда осуществляется с помощью RSM. Пул носителей может содержать носители или другие пулы носителей, но не может одновременно содержать носители и другие пулы; это либо одноуровневая структура, либо иерархическая структура. Например, пул типа Free может содержать пулы носителей для каждого типа носителей, но не может содержать иерархическую структуру пулов носителей типа Free.

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

Пулы неопознанных носителей

Пулы неопознанных носителей (Unrecognized) содержат носители, которые не может распознать RSM. Обычно это совершенно пустой носитель, который еще не получил свой идентификатор от RSM (это происходит при вставке носителя в библиотеку). Но если носитель содержит идентификатор, который не может прочитать или "понять" RSM, то он тоже включается в пул Unrecognized. Носители, находящиеся в пуле Unrecognized, не включаются в список базы данных RSM и поэтому недоступны для приложений.

Пулы свободных носителей

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

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

Пулы импортированных носителей

Пулы импортированных носителей (Import) содержат носители, которые опознаны как носители допустимого типа, но не используются службой RSM. Обычно носитель оказываются в пуле Import, когда он переносится из одной системы RSM в другую систему RSM той же организации. Вы можете перемещать носители из пула Import в пул Free или в пул Application.

Идентификация носителей

Чтобы отслеживать носители и поддерживать данные их описи, RSM идентифицирует каждую единицу носителей. Имеется два способа идентификации: записываемый на носитель идентификатор (on-media identifier) и штрих-код (barcode).

Идентификация на носителях

Идентификаторы на носителях записываются электронным способом при первой установке носителя в библиотеку. Этот идентификатор имеет две части.

Тип метки .Идентифицирует формат, используемый для записи данных. Этот формат зависит от типа носителя.
Идентификатор метки .Уникальный идентификатор для конкретного диска или ленты.

Идентификация с помощью штрих-кода

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

Форматы носителей

Чтобы работать с записываемыми на носитель идентификаторами, RSM использует MLL (Media Label Library – библиотека меток носителей) . Библиотека MLL – это DLL, которая используется для интерпретации формата метки носителя, записанной каким-либо приложением. RSM поддерживает форматы FAT, NTFS и CDFS для дисковых носителей и MTF (Microsoft Tape Format) для ленточных носителей. RSM может различать, какое приложение записало метку носителя, путем проверки в зарегистрированных библиотеках MLL. Разработчики приложений, в которых используются другие форматы носителей, должны предоставлять соответствующие MLL.

Состояния носителей

Состояние носителя – это текущее рабочее состояние ленты или диска. RSM использует для оценки текущего состояния записываемый идентификатор или штрих-код. Состояния носителей определяются на двух уровнях: физическое состояние (Physical state) и состояние "сторон" (Side state).

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

Таблица 7.1.

Физическое состояние	Описание
Idle (Простаивает)	Носитель отсоединен (находится в слоте хранения [автоматизированного устройства] или физически находится вне устройства, то есть на хранении).
In Use (Используется)	RSM в данный момент перемещает носитель.
Loaded (Загружен)	Носитель смонтирован на приводе и доступен для чтения или записи данных.
Mounted (Смонтирован)	Носитель находится на приводе, но еще не доступен для чтения или записи данных.
Unloaded (Выгружен)	Носитель был демонтирован, и находится в состоянии ожидания, пока кто-либо не удалит его физически из

Состояние сторон – это состояние стороны (сторон), где сохраняются данные. Каждый тип носителя имеет одну или две стороны. Например, магнитооптические диски имеют две стороны, а ленты имеют одну сторону. RSM отслеживает стороны носителей, как это описано в табл. 7.2 .

Администратор может задавать максимум количества "захватов" сторон, чтобы ограничить количество захватов и освобождений носителя приложением. RSM проверяет каждый раз этот счетчик при освобождении какой-либо стороны, и когда достигается максимум, сторона выводится из эксплуатации. Это средство позволяет администраторам запрещать использование носителей сверх нормального срока службы (что особенно важно для лент).

Таблица 7.2. Отслеживание сторон службой RSM

Состояние стороны	Описание
Allocated (Занята)	Данная сторона зарезервирована каким-либо приложением и недоступна для любого другого приложения.
Available (Доступна)	Данная сторона доступна для использования любым приложением.
Completed (Заполнена)	Данная сторона заполнена до конца.
Decommissioned (Выведена из использования)	Сторона стала недоступна для использования,поскольку достигла своего максимума по количеству "захватов" (см. выше описание этого максимума).
Imported (Импортирована)	Тип метки данной стороны опознан. Идентификатор метки не опознан.

Incompatible (Несовместима)	Тип носителя несовместим с данной библиотекой, и его следует удалить.
Reserved (Зарезервирована)	Данная сторона доступна только определенному приложению. Это состояние относится к двусторонним носителям, когда одна сторона уже захвачена этим приложением.
Unprepared (Не подготовлена)	Сторона помещена в пул свободных носителей (типа Free), но еще не получила метку свободного носителя.
Unrecognized (Не опознана)	RSM не может опознать тип и идентификатор метки данной стороны.

Управление пулами носителей

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

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

Вы можете создать пул носителей для определенного приложения как новый пул верхнего уровня или как пул внутри существующего пула приложений (но не внутри системных пулов типа Free [Свободные], Import [Импортированные] или Unrecognized [Неопознанные]).

Для создания пула носителей верхнего уровня щелкните правой кнопкой на объекте Media Pools (Пулы носителей) в дереве консоли и выберите в контекстном меню пункт Create Media Pool (Создать пул носителей). Для создания пула носителей внутри существующего пула приложения щелкните правой кнопкой на этом пуле и выберите в контекстном меню пункт Create Media Pool.

Сконфигурируйте новый пул носителей в диалоговом окне Create a New Media Pool Properties, см. рис. 7.8 .

Сконфигурируйте вкладку General диалогового окна свойств пула носителей следующим образом.

Рис. 7.8.

Введите имя нового пула носителей.
Введите описание (дополнительно).
В секции Media Information (Информация о носителях) укажите, что этот пул должен содержать либо другие пулы носителей (вариант Contains other media pools), либо реальные носители (вариант Contains media of type).
Введите тип носителей в случае второго варианта.
Задайте следующие опции захвата, возврата и перераспределения носителей в секции Allocation/ Deallocation policy.
- Установите флажок Draw media from Free media pool, чтобы данный пул автоматически получал носители из пула свободных носителей (Free), когда в нем не остается незанятых носителей. Не устанавливайте этот флажок, если вы хотите перемещать носители из пула Free в этот пул вручную (используя оснастку RSM).
- Установите флажок Return media to Free media pool, чтобы данный пул автоматически возвращал носитель в пул свободных носителей, если этот носитель уже не нужен приложению. Не устанавливайте этот флажок, если вы хотите перемещать носители в пул Free вручную.
- Установите флажок Limit Reallocations (Ограничить количество перераспределений) и введите значение, ограничивающее количество захватов носителей другими пулами носителей.

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

Удаление пула носителей

Вы можете удалить пул носителей типа Application только из оснастки Removable Storage . Раскройте дерево консоли, чтобы представить пулы носителей, щелкните правой кнопкой на пуле носителей типа Application, который хотите удалить, и выберите в контекстном меню пункт Delete. Вы должны будете подтвердить это удаление.

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

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

Перемещение носителя в другой пул носителей

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

Если при создании и конфигурировании пула носителей вы не установили флажки автоматического перемещения носителей Draw media from Free media pool и Return media to the Free media pool (см. выше), то должны использовать этот ручной метод для перемещения носителей.

Очистка библиотек

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

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

Откройте оснастку RSM.
В дереве консоли раскройте объект Libraries до уровня \Соответствующая библиотека\Drives .
В правой панели щелкните правой кнопкой на соответствующем устройстве и выберите в контекстном меню пункт Mark As Clean (Пометить как чистое).

Чтобы выполнить очистку в автоматизированной библиотеке, щелкните правой кнопкой на соответствующей библиотеке и выберите в контекстном меню пункт Cleaner Management (Управление очисткой). Мастер Cleaner Management Wizard проведет вас через соответствующие шаги (включая инструкции по вставке чистящего картриджа).

Технология Storage Spaces в Windows 8

Storage Spaces или Дисковые пространства — новая технология хранения данных, призванная предотвратить потерю данных и обеспечить удобство хранения больших объемов информации. Технология серверная и принцип ее работы подобен принципу работы RAID-массивов, однако есть существенные отличия, позволяющие использовать ее в клиентских операционных системах.

Суть работы Storage Spaces состоит в следующем: жесткие диски, подключенные к компьютеру, можно объединить в один или несколько пулов хранения. Каждым пулом можно управлять как единым объектом, хотя он и состоит из нескольких дисков. И в отличие от технологии RAID (где все диски должны быть строго идентичны) Storage Spaces позволяет объединять в пулы диски разных объемов и типов, причем как внутренние (SATA), так и внешние (напр. USB). Диски можно смешивать в разных сочетаниях, а для расширения пула хранения достаточно подключить новый диск и добавить его к пулу.

На основе пула создаются виртуальные области — дисковые пространства, с помощью которых и происходит доступ к пулу из файловой системы. В одном пуле можно создать несколько дисковых пространств. Если сравнивать Storage Spaces с привычными вещами, то пул хранения — это физический диск, на котором можно создать одну или несколько логических областей, или дисковых пространств. Дисковые пространства интегрируются с Windows Explorer и отображаются в нем как обычные диски, так что доступ к ним можно получить как и к любому диску в системе, с обычной буквой диска.

Для сохранности данных Storage Spaces использует зеркалирование, гарантируя создание как минимум двух копий данных, каждая на отдельном диске, чтобы предотвратить потерю данных в случае поломки жесткого диска. При желании эту функцию можно настроить и так, чтобы хранить данные на трех разных физических дисках. Storage Spaces также поддерживает контроль четности (аналог RAID-5), позволяя создать две разных копии данных; при этом требуется наличие трех физических дисков — два для данных и третий для хранения контрольных сумм.

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

Практическое использование Storage Spaces

Управление дисковыми пространствами и пулами находится в Панели управления, на вкладке «Дисковые пространства».

Storage Spaces показывает доступные диски (все кроме загрузочного и системного разделов) и предупреждает, что при добавлении в пул форматированных дисков они будут переформатированы и все данные на них будут уничтожены без возможности восстановления. Выбираем диски и жмем кнопку «Создать пул».

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

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

Двухстороннее зеркало — информация распределена по двум дискам. На каждом диске хранится полная копия данных и при выходе одного диска из строя информация не будет потеряна. Емкость при этом составляет половину от общей емкости дисков;

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

Четность — данные пишутся на разные диски вместе со сведениями о четности. При выходе из строя одного диска данные можно восстановить, используя контрольную сумму. Емкость равна 2/3 от общей емкости дисков в пуле. Для этого режима необходимо не меньше трех дисков.

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

Задав параметры жмем на кнопку «Создать дисковое пространство» и ждем, пока мастер подготовит и отформатирует пространство.

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

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

В общем Storage Spaces довольно интересная технология, позволяющая защитить важные данные от потери. Правда доступна она будет скорее всего только в редакции Windows 8 Enterprise.

18.01.2013 Роберт Митчелл

Пользовательский интерфейс Storage Spaces and Pools реализован в программе Storage Spaces панели управления (в Windows 8) и в Server Manager (в Server 2012); также можно использовать команды PowerShell (в обеих операционных системах). По большей части эта статья относится к интерфейсу Server Manager. Версия клиента Windows 8 упрощена и заметно отличается по внешнему виду. Однако базовая технология везде одинаковая.

Новые версии Windows располагают расширенными возможностями хранения данных. В Windows Server 2012 и Windows 8 появилась функция под названием Storage Spaces and Pools, обеспечивающая пользователям ряд новых возможностей, в том числе:

метод построения виртуальных хранилищ данных;
функциональность RAID, ранее доступная только в дорогостоящем оборудовании;
тонкая подготовка;
управление с использованием сценариев через PowerShell;
избыточные копии данных, которые можно применять для устранения неполадок файловой системы;
интеграция с общими томами кластера (CSV).

Поддерживаемые хранилища данных

Storage Spaces and Pools можно разместить на разнообразных аппаратных средствах. Поддерживаемые типы шин: Universal Serial Bus (USB), Serial ATA (SATA) и Serial Attached SCSI (SAS).

Storage Spaces and Pools можно использовать в сочетании с логическими устройствами (LUN) через канал Fibre Channel или iSCSI, однако такая конфигурация не поддерживается. Пользователям высокоуровневых решений хранения данных следует обратиться к соответствующим поставщикам, чтобы в полном объеме задействовать имеющуюся функциональность. Компонент Storage Spaces and Pools ориентирован на менее дорогостоящие решения, чтобы предоставить функциональность, недоступную иными способами.

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

Пул - просто логическая группа физических дисков, а дисковое пространство (storage space) - виртуальный диск, который можно использовать как физический. Поэтому создание дискового пространства с помощью Storage Spaces and Pools - двухэтапный процесс. Сначала создается пул; затем выделяется дисковое пространство, именуемое виртуальным диском в Windows Server. Не путайте виртуальные диски Storage Spaces and Pools с файлами Virtual Hard Disk (VHD) или VHDX. Термины похожи, но сами компоненты не имеют между собой ничего общего.

С помощью интерфейса Server Manager можно создать работоспособный пул. Отправной точкой становится пул по умолчанию, называемый исходным пулом, представляющий собой просто список физических дисков, присоединенных к компьютеру, которые могут быть объединены в пул. Исходный пул не считается работоспособным. Мастер запрашивает имя пула и добавляемые физические диски. Созданный пул отображается в интерфейсе Server Manager. Обратите внимание, что хотя в Windows можно сформировать множество пулов, не рекомендуется создавать больше четырех. Для выполнения этой же операции предназначен сценарий PowerShell из трех строк:

$stsubsys = (Get-StorageSubsystem) $physd = (Get-PhysicalDisk PhysicalDisk1, PhysicalDisk2, PhysicalDisk3, PhysicalDisk4) New-StoragePool -FriendlyName MyPool1 -StorageSubsystemFriendlyName $stsubs.FriendlyName -PhysicalDisks $physd

Подготовив пул, можно создать виртуальный диск (называемый дисковым пространством в Windows 8). Мастер запрашивает имя пула хранения, имя виртуального диска, тип структуры хранилища, тип подготовки (тонкая или фиксированная) и размер виртуального диска. Подробнее это будет рассмотрено в следующем разделе, но после завершения работы мастера вы увидите виртуальный диск, показанный на приведенном экране. Для выполнения этой же операции предназначен следующий сценарий PowerShell:

New-VirtualDisk -StoragePoolFriendlyName MyPool1 -FriendlyName MyVirtualDisk -ResiliencySettingName Mirror -UseMaximumSize

Данный виртуальный диск можно использовать точно так же, как физический. Его можно настроить как раздел Master Boot Record (MBR) или GUID Partition Table (GPT).

Правила выбора

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

Структура. Структура хранилища - это всего лишь тип RAID, который предстоит использовать. Можно выбрать Simple (RAID 0 или чередующийся набор без контроля четности), Mirror (RAID 1) или Parity (RAID 5 или чередующийся набор с контролем четности). Можно создать простой набор из одного или нескольких физических дисков пула. Для наборов с контролем четности требуется не менее трех дисков в пуле. Наконец, зеркальные наборы можно создать с использованием не менее двух физических дисков для двустороннего зеркалирования и не менее пяти физических дисков для трехстороннего зеркалирования.

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

Размер виртуального диска. Размер виртуального диска зависит от выбранного типа подготовки, структуры хранилища и размера используемых физических дисков. Если планируется создать всего один виртуальный диск в пуле, можно просто выбрать параметр Maximum size (максимальный размер). Обратите внимание, что параметр Maximum size затенен, если выбрана тонкая подготовка.

Дополнительные сведения о тонкой подготовке

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

Преимущество тонкой подготовки - гибкость дискового пространства. Если вам нужен виртуальный диск на 10 Тбайт, не обязательно заранее обеспечивать для него физическое пространство. Можно подготовить тонкий виртуальный диск размером 10 Тбайт и добавлять физические диски по мере надобности. Эффективность этого подхода еще более повышается благодаря усовершенствованиям NTFS, обеспечивающим восстановление пространства после удаления или оптимизации файлов. Windows также оптимизирована для более эффективной работы с решениями хранения данных высокого уровня, располагающих функциями тонкой подготовки. В частности, это возможность задействовать неиспользуемые сектора, как это делает Storage Spaces and Pools.

Принципы архитектуры

Рассмотрим, что происходит во внутренних механизмах, чтобы получить описанные результаты. На рисунке 1 показан стек хранилища Windows. Драйвер SSP (SpacePort.sys) подключается непосредственно выше Partition Manager (Partmgr.sys). Когда в пул вводится физический диск, на нем создается раздел и физический диск скрывается из интерфейса пользователя. На следующем шаге из пула вырезается виртуальный диск, затем этот виртуальный диск вновь представляется в интерфейсе пользователя как логический диск. Физические диски по-прежнему видны в диспетчере устройств, но новое устройство Microsoft Storage Space Device также указано для каждого созданного виртуального диска.

На рисунке 2 показано, как будут выглядеть разделы на физических дисках (как унаследованные MBR-диски, так и диски с использованием схемы GPT.) Небольшая область раздела будет выделена для хранения метаданных для Storage Spaces and Pools. Основная часть раздела будет использоваться для хранения данных файлов. После того, как создан виртуальный диск, его можно настроить как MBR или GPT, а затем использовать как обычный физический диск. Его можно представить в формате NTFS или новой системы Resilient File System (ReFS) компании Microsoft.

Дополнительные параметры

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

Доступ к большинству углубленных настроек можно получить через команду PowerShell под названием New-VirtualDisk. Интерес представляют элементы NumberOfColumns (указывает число создаваемых столбцов), NumberOfDataCopies (указывает число создаваемых копий данных) и ResiliencySettingName (указывает имя требуемого параметра устойчивости - например, Simple, Mirror или Parity).

Число столбцов. На рисунке 3 показана диаграмма, состоящая из трех дисков. Диски делятся на блоки. При чередовании между дисками можно выполнять запись на каждый диск одновременно. В технологии RAID этот метод известен как чередующийся набор без контроля четности. Приблизительно это и происходит на виртуальном диске с «простой» структурой.

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

Элемент, используемый для управления столбцами - NumberOfColumns. Ниже приводится пример ручного управления этим элементом и элементом ResiliencySettingName. Следующая команда формирует виртуальный диск с тремя столбцами:

New-VirtualDisk -FriendlyName NewVDisk -StoragePoolFriendlyName MyPool -NumberOfColumns 3 -ResiliencySettingName simple -UseMaximumSize

Рисунок 3. Простая структура

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

* Простое пространство с единственной копией.

* Зеркальные пространства с двумя или тремя копиями.

* Пространства с контролем четности имеют всего одну копию.

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

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

Можно использовать элемент New-VirtualDisk (NumberOfDataCopies), чтобы задать число копий данных. В качестве примера взгляните на следующую команду PowerShell, которая создает двухстороннее зеркальное пространство с шестью столбцами, как на рисунке 6.

New-VirtualDisk -FriendlyName NewVDisk -StoragePoolFriendlyName MyPool -NumberOfColumns 6 -NumberOfDataCopies 2 -ResiliencySettingName mirror -UseMaximumSize

Дополнительные сведения о столбцах

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

Рисунок 7. Два простых пространства

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

* если пространство создано с помощью интерфейса пользователя, максимальное число столбцов - восемь;

* при использовании команды New-VirtualDisk можно установить значение NumberOfColumns больше восьми;

* в пространствах с контролем четности больше восьми столбцов (даже при использовании PowerShell).

Добавление пространства

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

Рисунок 8. Одно простое пространство, созданное с двумя физическими дисками

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

Работая с зеркальными пространствами, необходимо принимать во внимание как число столбцов, так и число копий данных. Например, двухстороннее зеркало, созданное с использованием четырех физических дисков, будет выглядеть так, как показано на рисунке 9. NumberOfDataCopies равен 2, и NumberOfColumns равен 2. Число дисков, необходимое для расширения этого виртуального диска вычисляется по следующей формуле:

NumberOfDataCopies * NumberOfColumns 2 * 2 = 4

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

Рисунок 10. Четыре физических диска, расширяющих тестовое пространство

Определение числа копий данных и столбцов

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

Get-VirtualDisk -FriendlyName MyVirtualDisk | ft FriendlyName, NumberOfColumns, NumberOfDataCopies ReFS на зеркале

· Отметим дополнительное преимущество зеркал Storage Spaces and Pools. В данной статье уже упоминалось о новой файловой системе Microsoft, ReFS. В случае порчи файлов или метаданных в ReFS операционная система может использовать избыточную копию с другой стороны зеркала для устранения ошибок. Это возможно отчасти благодаря контрольным суммам как данных, так и метаданных в ReFS.

Мощная функциональность хранения данных

Благодаря Storage Spaces and Pools в распоряжение обладателей систем хранения данных начального и среднего уровня предоставляется функциональность, которая в противном случае была бы недоступна. Ее легко настроить; возможна углубленная настройка для желающих задействовать дополнительные параметры, а файловая система ReFS приобретает дополнительную устойчивость. Storage Spaces and Pools обеспечивает тонкую подготовку, и как большинство компонентов Server 2012 и Windows 8, может управляться сценариями с использованием PowerShell. Думаю, это будет самое востребованное из всех новшеств Windows, относящихся к хранению данных.

DPandMe 26 мая 2015 в 17:16

Суп из SAN. Строим виртуальный SAN на платформе Windows Server 2012 R2

Виртуализация

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

Дисклеймер: заранее прощу прощения у специалистов по SAN и благородного хабрасообщества за некоторые вольности и упрощения, допущенные мной при подготовке материала. Он рассчитан на тех, кто пока еще не знаком с технологиями хранения данных, заложенными в Windows Server 2012 R2, а также тех, кто не имеет возможности развернуть у себя полноценную сеть хранения данных на базе FC или iSCSI.

С чего же начать? Рискну предположить, что для решения проблемы отказоустойчивости требуется две вещи:

Хороший план.
Деньги (смета).

Строго говоря, есть еще и третий пункт – «прямые руки», но его обсуждение выходит за рамки данной статьи.

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

Высокая доступность (High Availability, HA) - способность минимизировать как запланированные, так и незапланированные простои. То есть, мы (читай - заказчик) заранее соглашаемся с тем, что в случае сбоя, понадобится некоторое разумное время для переключения на резервное оборудование и запуск на нем «упавших» сервисов. Разрыв соединения при этом неизбежен. Типичный пример: кластер Hyper-V.

Отказоустойчивовсть (Fault Tolerance, FT) - способность сохранять работоспособность в случае отказа одного или нескольких компонентов. Это когда сбой произошел, но никто, кроме админа, его не заметил. Или, когда мы отключаем один из узлов, чтобы провести на нем плановое обслуживание (например, установку обновлений), а второй узел в это время берет на себя всю нагрузку. Соединение не рвется, приложения доступны, только немного увеличивается время отклика. Типичный пример: RAID 1-го уровня.

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

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

В контексте данной статьи будем обсуждать только один из трех пунктов, а именно, отказоустойчивость. Справедливости ради, надо отметить, что реальная необходимость в ней возникает не часто. В самом деле, большинство заказчиков вполне готовы мириться с небольшими, прописанными в SLA, простоями в обмен на существенную экономию денежных средств за счет отказа от непомерно дорогих «сверхнадежных» решений. К примеру, если у пользователей на несколько минут подвиснет Excel, это не станет большой проблемой для бизнеса – скорее поводом немного размяться и выпить кофе. Однако, есть и такие сервисы, которые крайне чувствительны даже к небольшому разрыву сетевого соединения. Например, СУБД и гипервизоры. Если Hyper-V потеряет связь со своими виртуальными жесткими дисками, на которых запущены виртуальные машины, это может привести к печальным последствиям. Также и SQL - внезапная потеря сервером своих баз может надолго занять интересным делом DB-админа.

Итак, мы решили, что будем строить отказоустойчивое решение. Другими словами, необходимо убрать возможные точки отказа на всех существующих уровнях: серверном, сетевом и уровне хранения данных. Чем это достигается? Конечно, дублированием всего, чего только можно: серверов, сетевых интерфейсов, каналов передачи данных и, конечно, дисковой подсистемы. Тут перед нашими глазами встает светлый образ SAN. Действительно, что может быть лучше для обеспечения отказоустойчивости, чем старый добрый аппаратный FC SAN? Так-то оно так… Только есть у этого решения один убийственный недостаток. Цена. Стоимость подобной системы начинается с семизначных чисел. А верхний предел практически не ограничен. Поэтому, ее нельзя просто взять и купить – как минимум, придется забюджетировать.

Кроме того, закупая дорогущее железо, мы попадаем в серьезную зависимость от вендора, поскольку совместимость с его оборудованием сторонних производителей далеко не гарантируется. Ну и масштабирование таких систем может потребовать значительных временных затрат. Ведь дорогие комплектующие никто на складе не держит – их надо заказывать и ждать неделями, а то и месяцами. А босс требует «здесь и сейчас». И чтобы все работало «как часы». И чтобы с минимальными затратами!

Где же выход? Неужели светлым мечтам о SAN-е не суждено сбыться? Подождите… А что вообще такое SAN? По сути, это просто способ разделения ресурсов высокопроизводительных устройств хранения данных между серверами на блочном уровне. Когда-то давно классические файберные сети SAN были практически безальтернативной технологией там, где требовалась исключительная производительность, отказоустойчивость и масштабируемость. Скорость FC на порядок превышала типичный Ethernet с его 100 Mb/s.

Но со временем появились сетевые адаптеры 1 и 10 Gbit Ethernet, возникли программные и аппаратные технологии увеличения пропускной способности сети (NIC teaming, сжатие данных и т.д.), что несколько снизило преимущества FC и привело к взрывному росту популярности интерфейса iSCSI. Что касается отказоустойчивости и масштабируемости, то и тут случился прогресс. К примеру, появились варианты реализации SAN на базе хранилищ с интерфейсом SAS, который, вообще говоря, изначально предназначался для прямого подключения хранилища к серверу – DAS. Дело в том, что интерфейс SAS, помимо высоких скоростей (6-12 Gbit/s), обладает еще одним существенным преимуществом – очень малыми задержками (latency). Это весьма важно для высоконагруженных хостов, вроде Hyper-V.

А что у нас есть, кроме SAN? А кроме SAN есть только NAS. Если сравнивать SAN и NAS, то главным отличием первого от второго является работа на блочном уровне. Хост-система может создавать на SAN логические разделы, форматировать их и использовать как обычные локальные жесткие диски. NAS же работает на уровне файловой системы и использует протоколы передачи файлов, такие как SMB или CIFS. Поэтому NAS, конечно, дешево и просто, но о-о-очень медленно. А потому, для высоконагруженных продакшн-систем бесперспективно.

А нельзя ли как-то совместить высокую скорость и надежность SAN с простотой реализации и доступностью NAS? Что, если часть функционала SAN попробовать реализовать программно? Видимо как-то-так рассуждали инженеры одной скромной компании из Рэдмонда, когда готовили к выходу на рынок свою новую технологию. В итоге, у них действительно получилось нечто, по формальным признакам напоминающее SAN. Но при этом в несколько раз дешевле. Нам предлагают использовать весьма недорогие и доступные комплектующие для приготовления изысканного блюда под названием «Scale-Out File Server», т.е. масштабируемый файловый сервер. Слово «масштабируемый», на мой взгляд, не совсем точно отражает суть, поскольку, в первую очередь, сервер получился отказоустойчивым.

Итак, сегодня будем готовить «Суп из SAN» на основе технологий Microsoft Windows Server 2012 R2.
В качестве ингредиентов, нам понадобятся:

серверы без дисков (только небольшие «зеркала» под систему) - 2 шт.;
недорогая дисковая полка JBOD с двумя SAS интерфейсами – 1 шт.;
HDD SAS – не менее 10 шт. (лучше – больше);
SSD SAS – хотя бы 2 шт.;
сетевые адаптеры 1-10 GBit (лучше – с поддержкой RDMA) – 2-4 шт.;

В качестве приправы, будем использовать рекомендованный набор специй: Storage Spaces, Tiering, SMB Direct, SMB Multichannel, CSV. Время приготовления: 1-1,5 часа при наличии опыта или 1-2 дня без такового.

Немного теории

В Windows Server 2012 и Windows 8 появилась интересная технология под названием «Дисковые пространства» (Storage Spaces). Предназначена она для абстрагирования от физического уровня дисковой подсистемы. По сути - это драйвер операционной системы, расположенный после менеджера разделов и перед менеджером томов, который позволяет виртуализировать блочное хранилище, скрывая его от операционной системы. Достигается это группировкой физических дисков в пулы и созданием на основе пулов виртуальных дисков (LUN-ов в терминологии SAN). Таким образом, все приложения будут иметь дело именно с виртуальными дисками, даже не подозревая, из чего они состоят. Но постойте… Опять виртуальные диски? Ведь эта технология под именем «динамических дисков» была реализована Microsoft (точнее, лицензирована у Veritas) аж в 2000 г. - в составе Windows 2000! Опять нам пытаются всучить залежалый товар?

Все не так просто… В отличие от динамических дисков, дисковые пространства - технология гораздо более умная, в чем мы убедимся позже. А пока уточним термины:

Пулы носителей (Storage Pools) - коллекция физических дисков, которая позволяет объединять диски, гибко увеличивать емкость и делегировать администрирование.

Дисковые пространства (Storage Spaces) - виртуальные диски, созданные из свободного пространства в пуле носителей. К атрибутам дисковых пространств относятся уровень устойчивости, уровни хранилища, фиксированная подготовка и точный административный контроль.

Кластеризованные дисковые пространства (Clustered Storage Spaces) – те же дисковые пространства, размещенные на общем хранилище - то, что нам надо!

Как создать виртуальный диск? В нашем случае, для начала, нужно объединить в пул физические SAS диски - HDD и SSD. Вообще говоря, объединять в пулы можно диски с разными интерфейсами: SATA, SCSI и даже USB. Но для развертывания отказоустойчивого кластера (Scale-Out File Server) подходят только диски с интерфейсом SAS. Объединение дисков в пул не представляет каких-либо сложностей и делается с помощью мастера буквально в два клика. Разумеется, на объединяемых дисках не должно быть никаких разделов, либо их придется удалить. Объединив диски в пулы, мы их сгруппируем. Но еще надо объяснить операционной системе, что с ними делать дальше. Теперь можно создать из дискового пула виртуальный жесткий диск (LUN). Технология Storage Spaces позволяет создавать 3 варианта виртуальных жестких дисков, подобных RAID-уровням:

Simple (аналог RAID0) – рекомендуется только для тестов;
Mirroring (аналог RAID1) – рекомендуется для рабочих нагрузок;
Parity (аналог RAID5) – рекомендуется для формирования разделов с архивами данных.

Как и в аппаратных RAID, можно оставить один или два диска в горячем резерве (Hot Spare). Перечисленные возможности представлены в графическом интерфейсе по умолчанию. Однако, если этого мало, с помощью командлетов PowerShell можно получить и более хитрые комбинации, соответствующие, к примеру, RAID уровня 10.

Позвольте, скажет читатель, если это программный RAID, он ведь должен работать медленнее аппаратного! И будет совершенно прав. Да, медленнее. Но насколько? Тут все не так однозначно. Во-первых, как показывает практика, скорость дисков легко компенсируется их количеством. Поэтому, разница в производительности будет тем менее заметна, чем больше дисков мы объединим в пул. Для промышленного применения рекомендуется использовать от 12 дисков. Во-вторых, в Windows Server 2012 R2 появилась одна замечательная фича: объединение в один пул дисков SSD и HDD с формированием т.н. «гибридного пула» (Tiered Storage). В этом случае система сама будет отслеживать и перемещать на быстрые SSD диски наиболее часто используемые данные (помните я говорил, что система умная!). Причем, перемещение «горячих» данных на SSD происходит поблочно, а не на уровне файлов. Более того, с помощью командлетов PowerShell можно явно указать, какие файлы необходимо разместить на SSD, а какие - на HDD. И в-третьих, Storage Spaces поддерживают т.н. «кэш обратной записи» (WriteBack Cache). При кратковременных всплесках операций записи система перехватывает данные и размещает их в специальной области на SSD. Таким образом сглаживается падение производительности при внезапных пиковых нагрузках. Все вместе - большое кол-во дисков, гибридный пул и кэш обратной записи – способно существенно поднять быстродействие системы, сведя к минимуму негативный эффект от программного RAID. Что касается экономии свободного места на дисках, то в Storage Spaces поддерживается такая привычная для SAN технология, как Thin Provisioning – для более экономного распределения дисковых ресурсов. Справедливости ради, заметим, что пока она несовместима с гибридным пулом – придется выбрать что-нибудь одно.

Итак, средствами Storage Spaces мы можем обеспечить отказоустойчивость на уровне СХД. Теперь поднимемся на уровень выше. Серверы необходимо объединить в кластер. Эта возможность появилась у Microsoft уже достаточно давно. Однако, ранее такой кластер можно было назвать лишь высокодоступным (вспоминаем терминологию). И только с выходом Windows Server 2012 появилась возможность сделать его по-настоящему отказоустойчивым. Называется эта фича «Scale-Out File Server». Тут будет уместно напомнить, что файловые кластеры могут работать в одном из двух режимов:

«Active - Passive»; отработка отказа с прерыванием сервиса – failover.
«Active - Active»; прозрачная отработка отказа – transparent failover.

В первом случае только один из узлов активный – именно с ним происходит обмен данными, а второй находится в ожидании. В случае отказа первого узла, второй принимает на себя всю нагрузку. Однако, при этом происходит неизбежный разрыв соединения и прерывание в работе сервиса. Именно по такому принципу работает файловый кластер в Windows Server 2008 R2. Во втором случае оба узла активны и способны одновременно принимать данные от клиентов. В случае отказа одного из узлов, потери SMB-сессии не происходит, соответственно, работа приложений не прерывается. Эта технология появилась только в версии Windows Server 2012.

Но чтобы такая одновременная работа с хранилищем стала возможной, потребовалась очередная технология под названием Cluster Shared Volume (CSV). Если не вдаваться в подробности, это логический том, специальным образом подготовленный для одновременной работы с несколькими узлами в составе кластера.

А что на сетевом уровне? Здесь у Microsoft припасено сразу несколько приятных сюрпризов. Первый – это SMB Direct поверх технологии RDMA. Если говорить упрощенно, это технология прямого доступа к памяти через сетевой интерфейс, без накладных расходов на использование центрального процессора. При включении данной фичи сетевые адаптеры фактически начинают работать на скорости интерфейса, обеспечивая высокую пропускную способность и чрезвычайно быстрый отклик на сетевые запросы, что дает огромный выигрыш в производительности для таких рабочих нагрузок, как Hyper-V и SQL Server. Скажем так, работа с удаленным файловым сервером становится похожа на работу с локальным хранилищем. И хотя сетевые адаптеры с поддержкой RDMA пока еще достаточно дороги, их стоимость непрерывно снижается (на момент написания данной статьи составляет около 20 т.р.).

Второй сюрприз называется SMB Multichannel. Если на потребителе нагрузки (например, SQL Server) и на принимающей стороне (файловый кластер) установлено по два сетевых адаптера, то между клиентом и сервером создается многоканальное SMB-подключение. Это означает, что если, к примеру, по сети копируется файл и в процессе копирования что-то происходит с одним из сетевых адаптеров, это не приводит к прерыванию процесса – файл продолжает копироваться, как ни в чем не бывало. Чтобы убедиться в наличии SMB Multichannel, запустите командлет PowerShell: Get-SmbMultichannelConnection. Вы увидите, что-то вроде этого:

Как видно, соединение установлено при помощи сразу двух сетевых интерфейсов.

Наконец, в протоколе SMB 3.0 проведена оптимизация работы балансировки нагрузки между узлами. Как раз для конфигурации Scale-Out File Server.

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

Подготовительные работы

Итак, берем дисковую полку в режиме JBOD. Набиваем ее дисками, хотя бы два из которых должны быть SSD. У корзины должно быть два SAS-экспандера, по два разъема на каждом. Через них подключаем корзину к двум серверам, желательно одинаковым. Для этой цели вполне подойдут простые одноюнитовые серверы. На серверах в качестве контроллеров устанавливаем обычные SAS HBA.

Далее по пунктам:

Устанавливаем на каждый сервер ОС Windows Server 2012 R2.
Настраиваем сетевые подключения, устанавливаем обновления, вводим серверы в домен.
Добавляем роль Файловый сервер на каждом сервере.
На одном из серверов открываем консоль Диспетчер отказоустойчивости кластеров.
С помощью мастера создаем стандартный кластер с отработкой отказа (Failover Cluster).
Создаем новый пул: Хранилище -> Пулы -> Создать новый пул.
Добавляем в пул SSD и HDD диски, при необходимости указываем параметры доступа.
Создаем виртуальный диск: Пул –> правый клик –> Новый виртуальный диск.
С помощью мастера задаем тип дисковой подсистемы (Mirror).
C помощью мастера создаем том на диске, присваиваем букву, форматируем в NTFS.
Создаем общий кластерный том (CSV): Выбираем нужный диск -> Добавить в общие тома кластера.
Задаем роль: Роли -> Настроить роль -> Файловый сервер -> Масштабируемый файловый сервер.
Чтобы не ждать, сбрасываем кэш распознавателя DNS (ipconfig /flushdns).
Выбираем роль -> Добавить общий файловый ресурс -> Общий ресурс SMB –> Профиль приложений.
Указываем расположение общего ресурса, даем ему название.

Все. Конечным итогом наших усилий стало создание файловой шары, расположенной по стандартному UNC-пути, типа: \\ScaleOutFS\Share. Теперь можем размещать на ней критические файловые ресурсы, такие как виртуальные жесткие диски Hyper-V или базы данных SQL сервера. Таким образом, мы получили готовую сеть хранения данных. Принципиальное отличие ее от традиционных SAN состоит в том, что для подключения используется протокол SMB 3.0, а не какой-то из блочных протоколов (iSCSI/FC), что в определенном смысле является даже преимуществом. У кого-то может возникнуть желание развернуть роль Hyper-V прямо на кластерном сервере, разместив виртуальные диски на общем хранилище. Придется огорчить. К сожалению, такая конфигурация пока не поддерживается. Для ролей Hyper-V и SQL Server необходимо поднимать отдельные серверы, которые будут работать с нашей СХД по SMB-протоколу.

Осталось подвести итоги…

Отказоустойчивость

Обеспечивается на всех уровнях: хранения данных, серверов, сетевого взаимодействия.

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

Будет зависеть от нескольких факторов. В типичном случае сопоставима с производительностью решений на базе iSCSI. А в случае задействования всех имеющихся возможностей, включая технологию RDMA, пропускная способность СХД окажется даже выше, чем при FC-подключении (до 56 GBit/s).

Масштабируемость

На уровне дисковой подсистемы обеспечивается простым добавлением дисков или каскадированием хранилищ JBOD. На уровне серверов – добавлением узлов в кластер. На сетевом уровне – добавлением сетевых адаптеров, объединением их в группы (NIC teaming) или заменой их на другие, с большей пропускной способностью.

Безопасность

Дисковые пулы можно контролировать с помощью списков контроля доступа (ACL), а также делегировать полномочия администраторам. Управление хранилищами может быть полностью интегрировано с ADDS.

Стоимость

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

А как же недостатки? Разумеется, они тоже имеются. К примеру, СХД и серверы нельзя разнести на значительное расстояние, как в случае FC или iSCSI. Нельзя выстроить сложную топологию. Коммутаторы SAS – пока еще редкость. Кроме того, SAS не поддерживает аппаратную репликацию – ее придется реализовывать программными средствами. Поэтому, описанная выше концепция – не панацея, а всего лишь альтернатива традиционным СХД. Если у вас уже есть развернутый аппаратный SAN, это ни коим образом не повод от него отказываться. Железо должно отрабатывать вложенные в него деньги. Но если вы пока еще только задумываетесь об архитектуре будущей системы хранения данных, имеет смысл рассмотреть и данный вариант, как вполне обоснованный с инженерной и экономической точек зрения. Ну и напоследок хотелось бы отметить, что «суп из SAN» можно сварить не только на технологиях Microsoft. Если у вас имеется хранилище с интерфейсом iSCSI, можете воспользоваться такими продуктами, как StarWind iSCSI SAN, VMware Virtual SAN, Openfiler, FreeNAS, Open-E DSS V6 и т.п.

Приятного аппетита!
При подготовке статьи были использованы материалы портала

В области систем хранения. В той или иной степени были затронуты практически все линейки. В этой заметке я коснусь только лишь младших систем – DS3500 и DCS3700.

Большинство носит принципиальный характер. Итак, новинки:

дисковые пулы (Dynamic Disk Pooling, DDP);

выделение дискового пространство по мере необходимости (Thin provisioning);

новая технология мгновенных снимков;

поддержка VAAI;

поддержка ALUA;

временные лицензии.

В чем плюсы, как это работает и что с этим всем делать? Попробуем пройтись по всем новинкам.

Динамические дисковые пулы.
Вместо привычных RAID массивов (Array) и томов на них (Volumes, LUNs), мы объединяем диски в большой пул и уже на этом пуле “нарезаем” тома нужного нам размера. Мы больше не привязаны к размерам конкретного массива, поэтому нам не нужно планировать массив так, чтобы наиболее эффективно его заполнить – все равно черпаем из “общего” котла. Нет ни выделенных дисков четности, ни выделенных hot-spare дисков.

Ну хорошо, схожие технологии мы видели и у других производителей, а в чем же отличие? Давайте посмотрим, как работает DDP. Каждый диск разбивается на 512МБ “дольки” (D-Piece) – см. рисунок ниже. Когда нам требуется выделить место из дискового пула для конкретного тома, система выбирает 10 таких “долек” с разных дисков (выбирает она так, чтобы выровнять занятый объем). Выбранные дольки объединяются в RAID-6 (8D+P+Q) и уже этот страйп (D-Stripe) размером 4ГБ и становится частью нашего тома с данными. D-Stripe для одного тома располагаются по разным дискам, обеспечивая, таким образом, распределение данных по всему пулу:

DDP не становятся заменой какой-либо технологии – можно использовать только один пул, можно использовать несколько пулов в одной системе, можно использовать и классические RAID-группы, и пулы вместе. Так как пулы по производительности все-таки ближе к RAID-6 и максимальную эффективность показывают на дисках NL SAS, то данные для приложений, критичных к скорости можно вынести, например, на отдельные RAID10.

В случае сбоя одного из дисков в пуле, происходит восстановление данных на оставшиеся диски. За счет того, что в восстановлении участвует большое число шпинделей, оно происходит с большей скоростью и оказывает меньшее влияние на производительность массива. Вместо выделенных hot-spare дисков резервируется соответствующее свободное место в пуле (примерно так, как это реализовано в HP EVA). Можно зарезервировать до 10 дисков (или до 20% объема пула). Вот как изменяется время восстановления в зависимости от числа дисков в пуле по сравнению с перестроением классического RAID6:

На 192х дисках различие превышает 5 раз! А при временах порядка 10 часов это весьма заметно. Не стоит забывать, что при восстановлении классического массива деградация производительности также весьма велика:

Хорошо видно, что во время ребилда диска в большом пуле, производительность приложений будет страдать заметно меньше (особенно если не ставить целью провести перестроение максимально быстро).

Конечно, раз уж речь зашла о производительности, то хочется сразу уточнить, а насколько такая новая технология “портит нам жизнь” в плане этой самой производительности? Результаты показывают, что максимально “страдают” операции случайной записи и последовательного чтения(~15%); случайное чтение же ухудшается всего на 6%, а последовательная запись даже улучшается. Такие эффекты заметны в “синтетических” тестах на 192х дисках в пуле. Если же количество дисков меньше, то и различие в производительности приближается к нулю.

Еще один замечательный плюс от DDP – возможность добавления дисков в пулы. Вы скажете что в RAID тоже можно добавить дисков? А сколько “за один раз”? А чем это чревато с точки зрения производительности? Вот именно – лучше этого на обычном массиве не делать. При добавлении же в пул новых дисков, происходит миграция незначительного числа “D-Piece” на новые диски, что не оказывает, в свою очередь, существенного влияния на производительность системы.

Таким образом, динамические пулы дают нам отличную замену для RAID6, позволяя объединить большое количество дисков, обеспечивая высокую производительность, простоту управления и высокую защищенность.

Thin provisioning.
Данная технология уже хорошо всем известна, но теперь она появилась и в младших СХД IBM. Причем появится и у тех, кто год назад стал владельцем системы DS3500. Единственное “но” – thin provisioning работает только на динамических томах! Поэтому “поиграть” на системе, не создав заранее дисковый пул, увы, не получится. Плюсы у thin provisioning очевидны – не нужно задумываться о точности выделения дискового пространства. Можно выделить немного больше, а по факту на дисках будет занято ровно столько, сколько данных было записано. На самом деле, с шагом 4ГБ конечно – выделение дискового пространства осуществляется в терминах D-stripe. Экономия от использования технологии thin provisioning может быть колоссальна – проверьте на своих системах, сколько незанятого места теряется впустую?

Новые мгновенные снимки.
Еще одна давно ожидаемая возможность. Долгие годы владельцы систем IBM DS3000/4000/5000 вынуждены были мучиться с восстановлением данных из снапшота (невозможно сделать операцию rollback, вернее возможно, но очень “некрасиво”). И вот, новых снапшотов можно сделать не просто заметно больше, но и можно быстро “откатиться” из снапшота на исходном томе. Также появляется возможность использовать группы консистентности, а это очень полезно, когда данные одного приложения находятся на различных дисках:

Rollback в рамках группы консистентности также работает! Несомненным плюсом стала оптимизация операций копирования исходных блоков в рамках технологии Copy-on-Write. Если раньше для каждого снимка происходило копирование исходного блока данных, то сейчас копия делается только единожды. Это существенно снижает эффект от деградации производительности при использовании мгновенных снимков. Падение производительности для “классических” CoW снимков может составлять десятки процентов. Сейчас эта проблема должна быть решена, что позволит использовать снимки и в более нагруженных средах.

Поддержка технологии VAAI.
Многие рассматривают VAAI исключительно как средство повышения производительности в среде VMware, но я бы скорее делал бы упор не на скорость выполнения отдельных операций (хотя это, без сомнения, приятно), а на разгрузку хоста от “лишней” работы и разгрузку сети хранения. Клонирование виртуальной машины с использованием VAAI может быть закончится и не на много быстрее, но зато канал ввода-вывода между сервером и СХД будет загружен в разы меньше и наше клонирование не окажет пагубного влияния на остальную инфраструктуру (особенно если мы используем 1Gbit iSCSI). В рамках VAAI поддерживается – блокировка экстентов в VMFS, write zeroes (write same) и extended copy (клонирование VM, Storage vMotion). Время выполнения операций с VAAI и без оного (кликабельно):

Поддержка ALUA.
Наверное многим доставляли проблемы active/passive пути? А потом еще приходилось вручную возвращать диски на “свои” контроллеры после каждого сбоя. Благодаря ALUA (Asymmetric Logical Unit Access) об этих неприятностях можно спокойно забыть. Чтобы было более понятно, пара картинок. Вот как работает multipath в DS3500 сегодня:

А вот как он будет работать в новой прошивке:

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

Временные лицензии.
До настоящего момента было очень сложно оценить “полезность” дополнительного функционала систем DS3500. Если мгновенные снимки можно было попробовать, то репликацию проверить было фактически невозможно. Решение о покупке (с бюджетом, сопоставим со стоимостью контроллерного модуля) нужно было принимать на основе обещаний, книжек или еще чего-то там. Теперь можно будет установить временную лицензию на 90 дней и проверить работу в своей среде, со своими приложениями. Указанных 90 дней, в принципе, должно хватить не только чтобы проверить функционал, но и для того чтобы заказать постоянные ключи и дождаться их прихода.

Вот такие замечательные новинки были представлены IBM для систем начального уровня. Я, честно говоря, ожидал немного большего, но и это уже очень и очень хорошо. Развитие систем не останавливается – будут и другие новшества, но позднее. Все, о чем я написал, будет доступно в прошивке, которая анонсирована на 15 июня. По факту, скорее всего, скачать ее можно будет на несколько дней позднее, но шанс попробовать все возможности уже в этом месяце безусловно есть!