Настройка сетевого хранилища windows server 2012 r2

Обновлено: 05.10.2020
Опубликовано: 2016 год или раньше

В качестве примера используется Windows Server 2012 R2 (2016, 2019). Инструкция разбита на несколько шагов и представляет из себя полный цикл настройки файлового хранилища для использования в малых и средних компаниях.

Выбор оборудования и подготовка сервера
Установка Windows и настройка системы
Базовые настройки файлового сервера
Тюнинг файлового сервера или профессиональные советы
Настройка средств обслуживания
Тестирование

Шаг 1. Выбор оборудования и подготовка сервера

В качестве сервера, желательно, выбрать профессиональное оборудование. Системные требования для файлового сервера не высокие:

• Процессор может быть самый простой;
• Оперативная память также не сильно используется;
• Дисковая система — самый основной компонент. Ее объем зависит от специфики бизнеса. Примерная формула — не менее 15 Гб на пользователя и не менее 1 Тб на сервер. До 50 пользователей можно рассматривать диски SATA, после — SAS или SSD.

Например, для компании в 300 пользователей подойдет сервер с процессором Xeon E3, 8 Гб ОЗУ и 5 Тб дискового пространства на дисках SAS 10K.

Дополнительные требования

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

Подробнее о выборе оборудования читайте статью Как выбрать сервер.

Шаг 2. Установка Windows и настройка системы

Установка системы

На этом шаге все стандартно, за исключением одного нюанса: разбивая во время установки Windows жесткий диск, стараемся выделить небольшую часть (70 — 120 Гб) для системы и все остальное под данные. Если выделить много дискового пространства для системного раздела, увеличится время его обслуживания и фрагментация, что негативно скажется на производительности и надежности системы в целом.

Настройка системы

1. Проверяем правильность настройки времени и часового пояса;
2. Задаем понятное имя для сервера и, при необходимости, вводим его в домен;
3. Если сервер не подключен напрямую к сети Интернет, стоит отключить брандмауэр;
4. Для удаленного администрирования, включаем удаленный рабочий стол;
5. Устанавливаем все обновления системы.

Шаг 3. Базовые настройки файлового сервера

Это стандартные действия, которые выполняются при настройке обычного файлового сервера.

Установка роли и вспомогательных компонентов

Как правило, данная роль устанавливается вместе с Windows. Остается только это проверить и доустановить компоненты, которые нужны для полноценной эксплуатации сервиса.

Открываем Диспетчер серверов. Он может быть запущен из панели быстрого запуска.

Нажимаем Управление — Добавить роли и компоненты.

В открывшемся окне оставляем Установка ролей и компонентов и нажимаем Далее.

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

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

• Службы хранения;
• Файловый сервер;

Если данные службы не установлены, выбираем их и нажимаем Далее.

В окне Выбор компонентов просто нажимаем Далее.

Откроется окно Подтверждение установки компонентов. Нажимаем Установить и после окончания процесса перезагружаем сервер.

Настройка шары (общей папки)

Создаем первую папку, которую хотим предоставить в общее использование. Затем кликаем по ней правой кнопкой мыши и нажимаем Свойства:

В открывшемся окне переходим на вкладку Доступ и нажимаем Расширенная настройка:

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

Предоставляем полный доступ всем пользователям:

* конечно же, мы не будем давать доступ всем пользователям, но для этого есть вкладка безопасность (см. ниже).

Нажимаем OK и еще раз OK.

Теперь переходим на вкладку Безопасность и нажимаем Дополнительно:

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

Нажимаем OK и Изменить. 

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

Совет: старайтесь управлять правами на ресурсы только при помощи групп. Даже если доступ необходимо предоставить только одному человеку!

Теперь нажимаем OK два раза. Папка настроена для общего использования и в нашем примере доступна по сетевому пути \fs1Общая папка.

Шаг 4. Тюнинг файлового сервера или профессиональные советы

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

DFS

С самого начала стоит создавать общие папки в пространстве имен DFS. На это есть две основные причины:

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

Как создать и настроить DFS читайте в статьях Как установить и настроить DFS и Как установить и настроить DFS с помощью Powershell.

Теневые копии

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

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

Аудит

Аудит позволит вести протокол доступа к данным — понять, кто и когда удалил важные данные или внес в них изменения.

О том, как настроить данную возможность читайте статью Как включить аудит доступа к файлам Windows. 

Анализатор соответствия рекомендациям

В диспетчер управления серверами Windows встроен инструмент для проверки конфигурации сервера — анализатор соответствия рекомендациям. Чтобы им воспользоваться переходим в диспетчере в Локальный сервер:

Находим раздел «Анализатор соответствия рекомендациям» и справа кликаем по ЗАДАЧИ — Начать проверку BPA:

Рассмотрим решения некоторых рекомендаций.

1. Для XXX должно быть задано рекомендованное значение.

Это набор однотипных рекомендаций, для выполнения которых нужно обратить внимание на описание и задать значение параметро, которое в нем указано. Например, для CachedOpenLimit в описании проблемы есть описание решения — «Задайте для CachedOpenLimit рекомендуемое значение 5». Чтобы это сделать, открываем Powershell от администратора и вводим команду:

Set-SmbServerConfiguration -CachedOpenLimit 5

* мы задаем параметру CachedOpenLimit значение 5, как это и рекомендовано анализатором.

На запрос, уверены ли мы, что хотим выполнить команду, отвечаем утвердительно.

Остальные параметры задаем аналогичными действиями.

2. Файл Srv.sys должен быть настроен на запуск по требованию.

В командной строке от имени администратора вводим:

sc config srv start= demand

3. Создание коротких имен файлов должно быть отключено.

В командной строке от имени администратора вводим:

fsutil 8dot3name set 1

Шаг 5. Настройка средств обслуживания

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

Резервное копирование

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

Мониторинг

Мониторить стоит:

1. Сетевую доступность сервера;
2. Свободное дисковое пространство;
3. Состояние жестких дисков.

Шаг 6. Тестирование

Тестирование состоит из 3-х основных действий:

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

Продолжая тему создания систем высокой доступности, в данном материале мы рассмотрим настройку iSCSI-хранилищ в современной версии серверных ОС от Microsoft. Мы не будем повторяться и снова обсуждать общие вопросы, поэтому, если вы только начинаете работать с iSCSI, то настоятельно рекомендуем ознакомиться с вступительной частью к нашему предыдущему материалу.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Широкое распространение виртуализации и потребности в создании отказоустойчивых систем даже при небольших внедрениях заставили компанию Microsoft пересмотреть свое отношение к доступным из коробки ролям Windows Server и политике лицензирования. Если раньше iSCSI Target предлагался только в редакции Windows Storage Server, то начиная с Server 2008 R2 он стал доступен в виде отдельно устанавливаемого компонента, а с выходом Windows Server 2012 закономерно стал частью ОС.

Для установки роли Cервера цели iSCSI запустите Мастер добавления ролей и компонентов, затем последовательно разверните пункты Файловые службы и службы хранилища — Файловый службы и службы iSCSI и укажите одноименную роль.

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

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

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

Следующим шагом укажите имя и размер создаваемого диска. Windows Server 2012 поддерживает новый формат виртуальных дисков — VHDX, а также динамически расширяемые диски. Если доступные ранее диски фиксированного размера резервировали дисковое пространство хранилища сразу при создании, то динамически расширяемые диски увеличивают размер согласно реально записанным в них данным. Это позволяет существенно экономить дисковое пространство хранилища, нарезая виртуальные диски с запасом.

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

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

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

Затем потребуется указать инициаторы, которым будет разрешен доступ к этой цели. IQN инициатора можно посмотреть на клиенте, для этого откройте Панель управления — Администрирование — Инициатор iSCSI, на вопрос об автоматическом запуске службы ответьте утвердительно.

IQN ткущего инициатора можно посмотреть на закладке Конфигурация:

Но можно поступить проще, перейдите на закладку Конечные объекты и выполните Быстрое подключение к Cерверу цели, подключиться по понятным причинам не получится, но IQN инициализатора останется в кэше сервера.

Вернемся на сервер и нажав кнопку Добавить выберем IQN инициатора из кэша, для современных систем вы также можете получить IQN инициатора выполнив подключение к нему по IP-адресу или имени хоста:

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

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

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Internet Small Computer System Interface (iSCSI) — это протокол передачи данных, предназначенный для обмена данными между серверами и системами хранения данных (Storage Area Network, SAN). iSCSI представляет из себя комбинацию протокола SCSI и стека протоколов TCP/IP и предназначен для передачи блоков данных через сети Ethernet. Управляющие команды SCSI передаются внутри IP-пакетов, а протокол TCP обеспечивает управление потоком и надежность передачи данных.

При использовании iSCSI данные между сервером и системой хранения передаются блоками, в необработанном виде. Это позволяет использовать SAN практически так же, как если бы они были подключены к серверу напрямую, а не по сети. Хост-система может создавать на SAN логические разделы, форматировать их и использовать как обычные локальные жесткие  диски. В этом заключается основное отличие SAN от сетевых хранилищ (Network Area Storage, NAS), которые работают на уровне файловой системы и используют протоколы передачи файлов, такие как SMB или CIFS.

Технология iSCSI была разработана как более дешевая альтернатива Fibre Channel (FC). Системы на базе iSCSI поддерживают стандартные протоколы и могут быть построены на базе любой существующей сетевой инфраструктуры, поддерживающей протокол IP. Для работы iSCSI может использовать самые обычные сетевые устройства (коммутаторы, маршрутизаторы, сетевые адаптеры и т.п), тогда как для FC требуются специальные HBA-адаптеры, оптические кабеля и прочее дорогостоящее оборудование.

Архитектура iSCSI является клиент-серверной и включает в себя следующие компоненты:

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

iSCSI Target — серверный компонент, слушающий клиентские запросы и обеспечивающий установку соединения между клиентом и сервером iSCSI. Кроме того, таргет связан с виртуальными дисками iSCSI, и после установки соединения все виртуальные диски, связанные с этим таргетом, становятся доступны через инициатор. В качестве iSCSI Target может выступать как специализированная СХД, так и обычный Windows сервер с установленной ролью iSCSI Target.

Виртуальные диски iSCSI — используются для разбиения дискового пространства на логические разделы (Logical Unit Number, LUN). В Windows Server 2012 iSCSI LUN представляют из себя обычные виртуальные диски формата VHDVHDX. Кстати, в Windows Server 2012 для iSCSI поддерживался только формат VHD, что ставило ограничение в 2ТБ на максимальный размер LUN. В Windows Server 2012 R2 используется формат VHDX, что позволяет создавать LUN-ы размером до 64ТБ.

А теперь остановимся и уточним некоторые моменты:

• На каждом iSCSI сервере может быть один или несколько iSCSI Target;
• Каждый iSCSI Target может быть подключен к одному или нескольким виртуальным дискам;
• Каждый iSCSI Target может обслуживать одно или несколько подключений от iSCSI Initiator;
• В свою очередь, каждый iSCSI Initiator может подключаться к одному или нескольким iSCSI Target и, следовательно, к одному или нескольким виртуальным дискам.

Кроме того, в Windows Server 2012 поддерживается loopback-конфигурация, в которой и Target и Initiator могут находиться на одном и том же сервере.

В операционных системах Microsoft поддержка iSCSI появилась довольно давно. Первая версия Microsoft iSCSI Initiator устанавливалась в качестве отдельного компонента в Windows 2000, Windows XP SP2 и Windows Server 2003 SP1, а начиная с Windows Server 2008 и Vista iSCSI Initiator был встроен в операционную систему.

Что касается iSCSI Target, то изначально он входил в специальную версию серверной ОС Windows Data Storage Server 2003, которая была предназначена для построения систем хранения и поставлялась только в предустановленом виде. Однако с 2011 года компонент Microsoft iSCSI Software Target 3.3 стал доступен для загрузки и установки на Windows Server 2008R2, а в Windows Server 2012 он полностью интегрирован в систему и устанавливается в качестве роли сервера.

На этом закончим теоретическую часть и приступим к практике. Для настройки возьмем самый простой вариант, в качестве подопытных используем два сервера с установленной Windows Server 2012 R2: SRV2 для роли iSCSI Target и SRV3 для iSCSI Initiator.

Запуск службы iSCSI Initiator

Для начала проверим состояние службы инициатора на SRV3. Для этого открываем Server Manager и в меню «Tools» выбираем пункт «iSCSI Initiator».

Как видите, по умолчанию служба не запущена. Нажав на «Yes» в диалоговом окне, мы стартуем службу iSCSI Initiator и поставим ее в режим автоматического запуска.

Затем в окне свойств переходим на вкладку «Configuration» и запоминаем значение IQN, оно пригодится нам при настройке сервера.

IQN (iSCSI qualified name) — это уникальный идентификатор, назначаемый для каждого iSCSI Target и Initiator. IQN формируется из даты (месяц и год) регистрации домена, официального имени домена, написанного в обратном порядке и любого произвольного имени, например имени сервера. Получается примерно так: iqn:1991-05.com.microsoft:srv3.contoso.com

Стартовать сервис iSCSI Initiator и установить режим его запуска можно и из консоли PowerShell, следующими командами:

Start-Service msiscsi
Set-Service msiscsi -StartupType automatic

Установка роли iSCSI Target Server

Теперь перейдем на SRV2 и приступим к настройке серверной части. Первое, что нам надо сделать — это установить на сервер роль iSCSI Target. Открываем Server Manager, переходим по ссылке «Add roles and features»

И выбираем роль «iSCSI Target Server», которая находится в разделе File and Storage ServicesFile and iSCSI Services.

Либо воспользуемся командой PowerShell:

Install-WindowsFeature -Name FS-iSCSITarget-Server

Подготовка диска

Теперь подготовим физический диск, который будет использоваться для хранения виртуальных iSCSI дисков. Специально для этой цели к серверу подключен новый жесткий диск размером 120Гб.  На данный момент диск неактивен (Offline). Для его активации в Server Manager переходим в раздел File and Storage Services -> Disks, кликаем на диске и переводим его в Online.

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

Выбираем физический диск, на котором будет создаваться том

указываем размер тома

и выбираем букву диска.

Затем выбираем для диска файловую систему, размер сектора и указываем метку тома. Здесь напомню, что виртуальные диски iSCSI можно создавать только на томах NTFS, новая файловая система ReFS (Resilient File System) не поддерживается.

Смотрим суммарную информацию, и если все правильно, то жмем «Create», запуская создание тома.

Те же действия можно проделать с помощью PowerShell. Находим нужный диск:

Get-Disk | where {$_.OperationalStatus -eq ″Offline″}

Переводим его в online:

Set-Disk -Number 1 -IsOffline $false

Инициализируем:

Initialize-Disk -Number 1

Создаем раздел:

New-Partition -DiskNumber 1 -UseMaximumSize -DriveLetter D

И форматируем его в NTFS:

Format-Volume -DriveLetter D -FileSystem NTFS -NewFileSystemLabel ″iSCSI Storage″

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

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

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

Даем диску имя и описание.

Указываем размер виртуального диска и его тип. Выбирать можно из трех вариантов:

• Fixed size (фиксированного размера) — создаваемый диск сразу занимает весь выделенный объем. Это наиболее производительный, но наименее экономичный вариант;
• Dynamically expanding (динамически расширяемый) — изначально создается диск минимального размера, который затем динамически изменяется в зависимости от количества записанных на него данных. Наилучший вариант в плане использования дискового пространства;
• Differencing (разностный) — в этом варианте нужно указать расположение родительского диска, с которым будет связан создаваемый диск. Разностный диск может быть как фиксированным, так и динамическим, в зависимости от типа родителя.  У этого типа дисков есть свои преимущества, но использовать их для iSCSI лично я особого смысла не вижу.

Теперь нужно указать iSCSI Target, к которому будет подключен данный диск. Поскольку на сервере не создано ни одного таргета, выбираем «New iSCSI target».

Даем таргету имя и описание.

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

При выборе серверов можно воспользоваться двумя способами. Если инициатор находится на Windows Server 2012 или Windows 8, то можно просто нажать «Browse» и выбрать нужный сервер из списка. Для более старых систем надо вручную ввести идентификатор сервера. В качестве идентификатора можно указать IQN инициатора, DNS имя или IP-адрес сервера, либо MAC-адрес сетевого адаптера.

Идем дальше. На следующей странице можно настроить аутентификацию по протоколу CHAP между серверами. CHAP (Challenge Handshake Authentication Protocol) — это протокол для проверки подлинности партнера по подключению, основанный на использовании общего пароля или секрета. Для iSCSI можно задействовать как одностороннюю, так и двухстороннюю (reverse) проверку подлинности CHAP.

Проверяем правильность настроек и запускаем создание диска.

Попробуем сделать все то же с помощью PowerShell. Создадим еще один виртуальный iSCSI диск на 20ГБ командой:

New-IscsiVirtualDisk -Path D:iSCSIVirtualDisksiSCSI2.vhdx

Обратите внимание, что по умолчанию создается динамический диск, для создания VHD фиксированного размера надо воспользоваться ключом -UseFixed.

Теперь создаем второй iSCSI Target c именем iscsi-target-2 и в качестве сервера доступа укажем IQN SRV3:

New-IscsiServerTarget -TargetName iscsi-target-2 -InitiatorIds ″IQN:iqn.1991-05.com.microsoft:srv3.contoso.com″

И проверим результат командой:

Get-IscsiServerTarget | fl TargetName, LunMappings

Подключение

Возвращаемся на SRV3, открываем окно свойств инициатора, переходим на вкладку Discovery и жмем кнопку Discover Portal.

Вводим имя или IP-адрес портала и жмем ОК.

По умолчанию iSCSI использует все доступные IP-адреса, и если вы хотите, чтобы трафик iSCSI шел только через определенный сетевой интерфейс, то надо перейти в расширенные настройки и в поле «Connect using» указать нужный IP.

Теперь переходим на вкладку Targets, где должны отобразиться все доступные для подключения iSCSI Target. Выбираем нужный таргет и жмем «Connect».

Не забудьте отметить чекбокс «Add this connection to the list of Favorite Targets», который обеспечивает автоматическое подключение к таргету при выключении или перезагрузке машины.

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

То же самое можно выполнить с помощью PowerShell. Выводим список доступных таргетов:

Get-IscsiTarget | fl

И подключаемся к нужному:

Connect-IscsiTarget -NodeAddress ″iqn.1995-05.com.microsoft:srv2-iscsi-target-2-target″ -IsPersistent $true

Ключ -IsPersistent $true обеспечивает автоматическое подключение при выключении или перезагрузке.

Ну и для отключения можно воспользоваться командой Disconnect-IscsiTarge, вот так:

Disconnect-IscsiTarget -NodeAddress ″iqn.1995-05.com.microsoft:srv2-iscsi-target-2-target″ -Confirm:$false

Заключение

На этом настройка завершена. Как я говорил, это самый простой, базовый вариант настройки хранилища. В iSCSI имеется еще много интересных возможностей. Например, можно использовать службу имен iSCSI (iSNS) для простоты управления, многопутевой ввод-вывод (MPIO) для обеспечения отказоустойчивости, а для безопасности настроить аутентификацию по протоколу CHAP и шифрование трафика с помощью IPSec. О некоторых из этих фич я планирую написать в следующих статьях.

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

• Развертывать iSCSI желательно в быстрой сети, не ниже Gigabit Ethernet;
• Сетевой трафик iSCSI рекомендуется отделить от остального трафика и вынести в отдельную сеть, например с помощью VLAN или физического разделения на подсети;
• Для обеспечения высокой доступности на сетевом уровне необходимо использовать технологию MPIO, либо сеансы с несколькими подключениями (MCS). Объединение сетевых адаптеров (NIC Teaming) для подключения к устройствам хранения iSCSI не поддерживается;
• При использовании технологии Storage Spaces можно хранить виртуальные диски iSCSI на Storage Spaces, но нельзя использовать LUN-ы iSCSI для создания Storage Spaces;
• Для хранения виртуальных дисков iSCSI нельзя использовать общие кластерные тома CSV (Cluster Shared Volume).

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

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

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

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

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

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

Высокая доступность (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.

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

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

Все. Конечным итогом наших усилий стало создание файловой шары, расположенной по стандартному UNC-пути, типа: \ScaleOutFSShare. Теперь можем размещать на ней критические файловые ресурсы, такие как виртуальные жесткие диски 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 и т.п.

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

Арсен Азгальдов, dpandme@gmail.com

iSCSI — это сетевой протокол для работы с системами хранения данных (СХД). Он позволяет взаимодействовать по сети с различными системами хранения данных. В упрощенном виде она состоит из следующих частей:

• iSCSI-target (таргет) — это ресурс, к которому осуществляется доступ посредством протокола iscsi
• iSCSI-initiator (инициатор) — это хост который инициирует (устанавливает) iSCSI-соединение
• IQN (iSCSI Qualified Name) — это полный уникальный идентификатор устройства iSCSI, однозначно определяющий данное устройство (есть и у таргета и у инициатора)

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

Не является исключением и ОС Windows, где компоненты iSCSI являются дополнительными компонентами системы.

Установка iSCSI-таргета.

Для создания таргета нам необходимо через мастер добавления ролей и компонентов диспетчера серверов добавить роль “Сервер цели iSCSI” из раздела “Файловые службы и службы хранилища”.

Для этого необходимо нажать комбинацию клавиш Win-R и в командную строку ввести compmgmt.msc.

Далее запустить мастер установки ролей и компонентов нажав кнопку “добавить роли и компоненты”.

Откроется страница приветствия. Можно просто нажать “Вперед”, а также поставить галочку “Пропускать эту страницу по умолчанию”, если вы не хотите постоянно видеть эту страницу при запуске мастера установки ролей и компонентов, так как эта страница чисто информационная.

После этого, ОС задаст уточняющий вопрос.Выберем установку ролей и компонентов.

Укажем на какие сервера устанавливать роли и компоненты. Выберем интересующий нас сервер и нажмем далее.

Выбираем необходимые из списка ролей сервера. Надо раскрыть Файловые службы и поставить галочку “Сервер цели iSCSI”.

Установка дополнительных компонентов — добавляем нажатием соответствующей кнопки.

После этого выбранная роль отметится галочкой и можно переходить к следующему этапу нажатием кнопки “Далее”.

Установку компонентов можно пропустить, так как они нам в данный момент не нужны, нажав кнопку далее.

После этого, предупреждение о готовности роли к установке. Нажимаем “Установить”. Можно также поставить галочку “Автоматический перезапуск конечного сервера, если требуется” чтобы не перезапускать сервер вручную. Следует иметь ввиду, что нажатие этой галочки перезапускает конечный сервер после установки без дополнительных предупреждений, поэтому используйте ее с осторожностью.

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

Заходим последовательно в “Диспетчер серверов”-”Файловые службы и службы хранилища”-”Тома”-”Диски”.

Выбираем на каком томе будет храниться наш таргет и в контекстном меню пустого тома выбираем “Создать виртуальный диск iSCSI”.

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

Задаем имя и по желанию описание нашего диска и жмем далее.

Вводим размер диска и определяем как будет выделяться под него пространство — сразу или динамически. Доступный размер под iSCSI-диск показан в самом верху.

Определяем создавать ли новый таргет или присоединить диск к существующему (если они есть).

Задаем имя и описание нового таргета.

Выбираем инициаторы которым можно подключаться к данному таргету (может быть переопределено) посредством кнопки “добавить”. Можно добавить инициаторы через поиск, выбрать из кеша, если ранее инициаторы уже подключались или задать вручную через IQN, DNS-имя, ip или mac-адрес. Как минимум один инициатор должен быть задан. Введем например IQN вручную.

Нам стала доступна кнопка далее.

Можно включить дополнительную проверку подлинности если это необходимо (например таргет публикуется в сети интернет).

На последнем шаге выводится сводная информация по таргету. Проверяем и нажимаем “Создать”.

Начнется процесс создания таргета.

После этого можно подключаться к данному таргету инициатором, заданным на этапе создания.

На этом настройка хранилища iSCSI на Windows Server 2012R2 окончена. В нашей базе знаний вы найдёте ещё множество статей посвящённых различным аспектам работы в Windows, а если вы ищете надежный виртуальный сервер под управлением Windows, обратите внимания на нашу услугу — Аренда виртуального сервера Windows.

Постоянно доступные общие файловые ресурсы, Continuously Available File Shares (CAFS), – это новая технология, появившаяся в системе Windows Server 2012. На базовом уровне технология CAFS в системе Server 2012 расширяет возможности Windows по совместной работе с файлами с помощью кластерной технологии Server 2012. Механизмы CAFS используют преимущества новых функций протокола Server Message Block (SMB) 3.0, повышающих доступность общих ресурсов системы Windows Server, используемых для хранения документов и поддержки приложений. В число новых возможностей технологии SMB 3.0, позволяющих задействовать ресурсы CAFS, входят механизмы SMB Scale-Out, SMB Direct и SMB Multichannel.

Технология CAFS призвана решить проблемы, возникающие в ранних версиях файловых серверов высокой доступности, построенных на основе отказоустойчивых кластеров Windows Server. Предыдущие версии обеспечивали высокую доступность общих ресурсов, но были подвержены перерывам в работе и кратковременным потерям подключений в случаях отказа узла. Такие кратковременные сбои, как правило, допустимы в работе офисных приложений (например, Microsoft Office), часто выполняющих операции открытия и закрытия файлов, так как эти приложения могут повторно подключиться к ресурсу и сохранить изменения после отработки отказа. Однако подобные сбои недопустимы в работе таких приложений, как Hyper-V или SQL Server, которые держат файлы открытыми на протяжении длительного времени. В таких схемах сбой может привести к потере данных. До появления системы Server 2012 компания Microsoft не поддерживала установку серверов Hyper-V или SQL Server на общие ресурсы. Обеспечение поддержки приложений было одной из основных задач Microsoft при разработке технологии CAFS. Хотя вы можете использовать механизмы CAFS просто для предоставления клиентского доступа к общим ресурсам, реальной задачей данной технологии является поддержка серверных приложений. Технология CAFS дает возможность использовать преимущества недорогих механизмов хранения системы Windows Server применительно к критически важным приложениям. Технология CAFS обеспечивает непрерывный доступ к общим ресурсам, снижая время простоя практически до нуля.

Выберите решение

Существует два подхода к созданию ресурса CAFS.

• Файловый сервер общего назначения. Это очень похожая на поддержку файлового сервера с высокой доступностью в системе Windows Server 2008 R2, наиболее распространенная реализация технологии CAFS на файловом сервере, которая обеспечивает поддержку размещения общих ресурсов на отказоустойчивом кластере. Технология CAFS повышает доступность и производительность данной схемы, благодаря новому высокопроизводительному механизму клиентского доступа SMB 3.0.
• Масштабируемый файловый сервер. Реализация масштабируемого файлового сервера – это новая возможность технологии CAFS, предназначенная для обеспечения поддержки таких приложений как Hyper-V и SQL Server без простоя в работе. Данная реализация ограничена четырьмя серверами.

Обзор архитектуры CAFS приведен на рисунке.

Рисунок. Архитектура CAFS

Одной из ключевых технологий, сделавшей возможным использование ресурсов CAFS, является поддержка механизмов SMB Transparent Failover системой Server 2012. Механизмы SMB Transparent Failover позволяют службам файлового сервера выполнять аварийное переключение на резервный узел кластера, благодаря чему приложения, имеющие открытые файлы на файловом сервере, не заметят обрывов в подключениях. Технология CAFS обеспечивает нулевой простой в работе приложений как при плановом обслуживании, так и при незапланированных отказах.

Соответствие требованиям

Поскольку технология CAFS использует механизмы SMB 3.0 системы Server 2012, наличие операционной системы Server 2012 является обязательным требованием. Технология поддерживается в обеих редакциях, Server 2012 Standard и Server 2012 Datacenter. В редакциях Essentials или Foundation технология CAFS не поддерживается.

Кроме того, для использования технологии CAFS необходимо наличие отказоустойчивого кластера Server 2012. Это означает, что у вас должен быть настроен кластер Server 2012 как минимум из двух узлов. Отказоустойчивые серверы Server 2012 поддерживают до 64 узлов. Вы можете найти пошаговые инструкции по настройке отказоустойчивого кластера в моей статье «Windows Server 2012: Building a Two-Node Failover Cluster» (опубликованной в Windows IT Pro/RE № за 2012 год).

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

В отказоустойчивом кластере из двух узлов на кластерном хранилище должны быть настроены как минимум два различных тома LUN. На одном томе хранятся общие файлы. Этот том должен быть настроен в качестве общего тома кластера cluster shared volume (CSV). Другой том будет работать в качестве диска-свидетеля. В большинстве решений используется большее количество томов.

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

Наконец, для использования преимуществ нового механизма SMB Transparent Failover на компьютерах с клиентом SMB должны быть установлены операционные системы Windows 8 или Server 2012. Когда клиент SMB 3.0 подключается к ресурсу CAFS, он уведомляет службу-свидетеля кластера. Кластер назначает узел, который будет свидетелем для данного подключения. Узел-свидетель отвечает за переключение клиента на новый хост-сервер в случае остановки в работе службы, не вынуждая клиента дожидаться, пока пройдет время отклика протокола TCP.

Создание ресурсов CAFS общего назначения

Для настройки ресурса CAFS откройте мастер Failover Cluster Manager на любом из узлов кластера. Затем щелкните мышью на узле Roles в панели навигации. Как показано на экране 1, в окне Roles отображаются установленные роли.

Экран 1. Мастер Failover Cluster Manager

Кластер может поддерживать несколько ролей и обеспечивает высокий уровень доступности для каждой из них. На экране 1 мы видим настроенную виртуальную машину с высоким уровнем доступности. Для создания нового ресурса CAFS общего назначения щелкните мышью по ссылке Configure Role…, отмеченной в окне Actions. Будет запущен мастер High Availability Wizard, показанный на экране 2.

Экран 2. Мастер High Availability Wizard

Прокручивайте список ролей до тех пор, пока не увидите роль файлового сервера. Роль файлового сервера поддерживает ресурсы CAFS обоих типов: общего назначения и масштабируемых приложений. Выберите роль File Server и щелкните мышью на кнопке Next, чтобы перейти к экрану выбора типа ресурса CAFS, см. экран 3.

Экран 3. Окно выбора типа ресурса CAFS

Диалоговое окно File Server Type позволяет выбрать, какой сервер необходимо создать: файловый сервер общего назначения (File Server for general use) или масштабируемый файловый сервер для данных приложений (Scale-Out File Server for application data). Роль «общего назначения» может быть использована для настройки как общих папок на основе механизма Windows SMB, так и общих папок на основе NFS. Ресурсы CAFS общего назначения также поддерживают устранение дублирования данных, репликацию DFS и шифрование данных. Щелкните мышью на кнопке Next, чтобы продолжить создание ресурса CAFS общего назначения. На экране появится диалоговое окно Client Access Point, показанное на экране 4.

Экран 4. Окно Client Access Point

Для создания нового ресурса CAFS общего назначения необходимо указать имя сервера, которое клиенты будут использовать при обращении к ресурсу CAFS. Это имя будет зарегистрировано в DNS, и клиенты будут указывать его по аналогии с именем сервера. Кроме того, ресурсу CAFS общего назначения также необходим IP-адрес. На экране 4 я присвоил службе имя CAFS-Gen (для ресурса CFAS общего назначения) и статический IP-адрес 192.168.100.177. Щелкнув кнопку Next, вы сможете выбрать кластерное хранилище для ресурса CAFS.

Диалоговое окно Select Storage, показанное на экране 5, позволяет выбрать хранилище для ресурса CAFS общего назначения.

Экран 5. Окно Select Storage

Хранилище должно быть доступно для служб кластера. Другими словами, оно должно быть в списке узлов хранения кластера и должно быть отмечено как доступное хранилище. Вы не можете использовать предварительно назначенные общие тома кластера CSV для создания ресурса CAFS общего назначения. В данном примере я мог задействовать три различных диска, и выбрал Cluster Disk 5, потому что изначально готовил это хранилище под размещение ресурса CAFS (экран 5). Однако вы можете выбрать любой из доступных дисков кластера. Щелкнув мышью на кнопке Next, вы перейдете к экрану Confirmation. На нем можно подтвердить выбранные настройки или вернуться к диалоговым окнам мастера High Availability Wizard и внести изменения. Если все параметры вас устраивают, щелкните мышью на кнопке Next экрана Confirmation и перейдите к окну Configure High Availability, которое отображает прогресс настройки ресурса CAFS. По окончании настройки вы увидите экран Summary. Щелчок мышью на кнопке Finish экрана Summary закроет мастер High Availability Wizard и вернет вас в окно Failover Cluster Manager, показанное на экране 6.

Экран 6. Создание постоянно доступной общей файловой папки

Следующим шагом после создания роли CAFS будет создание постоянно доступной общей файловой папки, использующей данную роль. На экране 6 видно, что роль CAFS-Gen активно работает и использует роль файлового сервера. Для добавления новой постоянно доступной общей файловой папки выберите ссылку Add File Share в окне, которое вы видите в правой части экрана 6. Вы увидите диалоговое окно Task Progress, которое отображает процесс получения информации с сервера. Сразу по завершении на экране появится диалоговое окно New Share Wizard, которое вы видите на экране 7.

Экран 7. Окно New Share Wizard

Первым делом мастер New Share Wizard спросит, какой тип ресурса CAFS вы хотите создать. Вы можете выбрать ресурс CAFS одного из двух типов: SMB или NFS. Режим SMB Share—Quick активирует создание ресурса CAFS общего назначения. Режим SMB Share—Applications отвечает за создание высоконадежного общего ресурса приложений для таких систем как Hyper-V или SQL Server. Создание масштабируемых ресурсов CAFS для приложений я рассматриваю ниже. Для создания ресурса CAFS общего назначения выберите режим SMB Share—Quick и щелкните кнопку Next. Мастер New Share Wizard отобразит диалоговое окно Share Location, показанное на экране 8.

Экран 8. Окно Share Location

Имя роли CAFS отображается в поле Server Name. На экране 8 мы видим имя роли CAFS-Gen, которую я создал ранее, и ее состояние – online. Вы может выбрать размещение общего ресурса с помощью полей в нижней части экрана. В данном примере по умолчанию был выбран диск G (экран 8). Если вы хотите использовать другой диск, то можете ввести альтернативный путь в поле Type a custom path, расположенном внизу экрана. В этом примере я оставляю предложенный по умолчанию диск G и нажимаю кнопку Next для перехода к диалоговому окну Share Name, показанному на экране 9.

Экран 9. Имя общего ресурса

Диалоговое окно Share Name позволяет вам ввести имя общего файлового ресурса. Для простоты я использовал для ресурса CAFS то же имя, что и для службы, CAFS-Gen (экран 9), но это не обязательно. Вы можете дать общей папке любое корректное имя SMB. В центре экрана мы видим локальный и удаленный пути к ресурсу CAFS. Локальный путь в данном примере — G:SharesCAFS-Gen. Сетевые системы будут обращаться к общей папке по пути \CAFS-genCAFS-Gen. Щелкнув мышью по кнопке Next, вы откроете диалоговое окно настройки общего ресурса Configure, показанное на экране 10.

Экран 10. Окно настройки общего ресурса

Диалоговое окно настройки общего ресурса Configure позволяет контролировать процесс обработки ресурса сервером. Чтобы сделать файловый ресурс постоянно доступным, требуется установить флаг Enable continuous availability. Этот параметр активируется по умолчанию. Параметр Enable access-based enumeration управляет возможностью просмотра файлов и папок пользователями без привилегий. Этот параметр выключен по умолчанию. Параметр Allow caching of share разрешает доступ к ресурсу для пользователей, работающих автономно, посредством технологии BranchCache. И наконец, параметр Encrypt data access позволяет обезопасить удаленный доступ к файлам путем шифрования данных, передаваемых ресурсу и извлекаемых из него. Этот параметр по умолчанию отключен. Щелкнув мышью по кнопке Next, вы откроете диалоговое окно Permissions, показанное на экране 11.

Экран 11. Назначение общему ресурсу разрешений

По умолчанию ресурс CAFS создается с привилегиями Full Control, предоставленными группе Everyone. В большинстве решений вы, скорее всего, захотите изменить настройку прав доступа. В данном примере я соглашаюсь с правами доступа, заданными по умолчанию. Щелкнув мышью на кнопке Next, вы перейдете к диалоговому окну Confirmation, где сможете просмотреть сводку действий, выполненных на предыдущих экранах мастера New Share Wizard. Вы можете щелкнуть мышью по кнопке Previous, чтобы вернуться к этим экранам и изменить любые параметры. Нажатие мышью кнопки Create в диалоговом окне Confirmations приведет к созданию ресурса CAFS и настройке прав доступа для общей папки. После того, как ресурс CAFS будет создан, мы сможете обратиться к нему, как к любой общей файловой папке. На экране 12 показано, как подключиться к общему ресурсу, введя в проводнике Windows Explorer имена сервера и общей папки – \cafs-genCAFS-Gen.

Экран 12. Подключение к общему ресурсу

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

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

Основная задача ресурсов CAFS — обеспечить высокий уровень доступности приложений, хранящих данные в общих файловых папках. В прошлом компания Microsoft не предоставляла поддержку такого типа для приложений, подобных системе SQL Server, хранящих свои базы данных на общих файловых ресурсах. Ситуация изменилась с выпуском платформы Server 2012, поддерживающей технологию CAFS. Настройка масштабируемых ресурсов CAFS отличается от настройки ресурсов CAFS общего назначения. Однако для создания масштабируемого решения используется тот же мастер High Availability Wizard. Чтобы создать новый ресурс CAFS для поддержки масштабируемых приложений, выберите ссылку Configure Role… в окне Actions оснастки Failover Cluster Manager (см. экран 1). Далее в диалоговом окне Select Role выберите роль File Server (см. экран 2). Эти два шага такие же, как при создании ресурса CAFS общего назначения. Однако, как показано на экране 13, в диалоговом окне File Server Type необходимо выбрать режим Scale-Out File Server for application data.

Экран 13. Выбор режима масштабирования ресурсов

Механизм масштабируемого файлового сервера разработан для приложений, которые оставляют свои файлы открытыми на продолжительное время. Щелкнув мышью кнопку Next, вы перейдете к диалоговому окну Client Access Point, показанному на экране 14.

Экран 14. Окно Client Access Point

Диалоговое окно Client Access Point позволяет вам задать имя для роли CAFS. Я назвал масштабируемый ресурс CAFS именем CAFS-Apps (экран 14). Это серверное имя, которое клиентские приложения используют при обращении к общему ресурсу. Щелкнув мышью кнопку Next, вы перейдете на экран Confirmation, где можно подтвердить выбранные решения или вернуться назад к окнам High Availability Wizard и внести изменения. Если все верно, щелкните мышью на кнопке Next экрана Confirmation, чтобы перейти к диалоговому окну Configure High Availability, который отображает прогресс настройки ресурса CAFS. По завершении процесса настройки вы увидите экран Summary. Щелчок мышью на кнопке Finish на экране Summary приведет к закрытию мастера High Availability Wizard и вернет вас к оснастке Failover Cluster Manager.

Следующий шаг — добавление общей файловой папки к CAFS-серверу масштабируемых приложений. Чтобы создать новый файловый ресурс для роли CAFS, выберите ссылку Add File Share из окна Actions, по аналогии с созданием файловой папки общего назначения на экране 6. Щелкните мышью по ссылке Add File Share для масштабируемого ресурса CAFS, чтобы запустить мастер New Share Wizard, показанный на экране 15.

Экран 15. Выбор профиля для общего ресурса

Для создания масштабируемого ресурса CAFS из диалогового окна Select Profile выделите профиль SMB Share—Applications в списке File share profile, после чего щелкните мышью кнопку Next, чтобы перейти к диалоговому окну Share Location, показанному на экране 16.

Экран 16. Выбор файлового сервера масштабируемых приложений

В поле Server в верхней части диалогового окна отображаются два файловых сервера CAFS, созданных ранее. Для добавления ресурса CAFS к файловому серверу масштабируемых приложений выберите файловый сервер CAFS-APPS с описанием Scale-Out File Server в столбце Cluster Role. После этого выберите том CSV, на котором вы хотите создать общий ресурс CAFS. В этом примере доступно два созданных общих ресурса кластера. В качестве места размещения нового ресурса CAFS я выбрал том C:ClusterStorageVolume1. При желании вы можете вручную ввести путь и к другому тому CSV. После выбора тома CSV нажмите кнопку Next для перехода к экрану Share Name, показанному на экране 17.

Экран 17. Указание имени для файлового ресурса

Диалоговое окно Share Name позволяет назначить имя для файлового ресурса. Ресурсу CAFS для масштабируемых приложений я присвоил имя HyperV-CAFS (экран 17). В центре экрана мы видим локальный и удаленные пути к ресурсу CAFS. Локальный путь в данном примере — C:ClusterStorageVolume1SharesHyperV-CAFS. Удаленные обращения к общей папке будут выполняться с использованием сетевого имени \cafs-appsHyperV-CAFS. Щелкните мышью на кнопке Next, чтобы перейти к диалоговому окну Configure, см. экран 18.

Экран 18. Диалоговое окно Configure

При создании масштабируемого ресурса CAFS флаг Enable continuous availability устанавливается по умолчанию.

Параметры Enable access-based enumeration и Allow caching of share отключены, вы не можете выбрать их. Единственный дополнительный параметр, который вы можете выбрать — Encrypt data access. Я оставил без изменений настройки, предложенные по умолчанию (экран 18). Щелкните кнопку Next, чтобы перейти к диалоговому окну Specify permissions to control access, показанному на экране 19.

Экран 19. Разрешения для масштабируемого ресурса CAFS

Как и ресурс CAFS общего назначения, масштабируемый ресурс CAFS создается с привилегиями Full Control, предоставленными группе Everyone, — и эти права доступа вы, скорее всего, захотите изменить. Я согласился с привилегиями, предложенными по умолчанию, нажал кнопку Next, открывающую диалоговое окно Confirmation, в котором вы можете просмотреть сводку по действиям, выполненным в предыдущих диалоговых окнах мастера New Share Wizard. Вы можете щелкнуть мышью кнопку Previous, чтобы вернуться назад и изменить любой из параметров. Нажатие кнопки Create в окне Confirmations приведет к созданию масштабируемого ресурса CAFS и настройке заданных прав доступа. После того, как ресурс создан, к нему можно подключиться локально, используя путь C:ClusterStorageVolume1SharesHyperV-CAFS, или удаленно, используя путь \cafs-appsHyperV-CAFS. Новый ресурс CAFS теперь виден в точке подключения тома CSV (экран 20).

Экран 20. Новый ресурс CAFS

Теперь вы можете наполнить ресурс виртуальными машинами Hyper-V, данными SQL Server, а также файлами журналов и данными приложений других типов.

Повышение доступности файлов

В данной статье я показал, как можно использовать ресурсы CAFS для повышения уровня доступности и гибкости элементов существующей инфраструктуры. Технология CAFS обеспечивает более высокую доступность файловых ресурсов общего назначения, а также позволяет серверным приложениям, таким как SQL Server и Hyper-V, хранить свои данные на файловых ресурсах с высоким уровнем доступности, предоставляя новые возможности для хранения данных критически важных приложений.