Как поднять файловый сервер на windows server 2012

Обновлено: 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. Провести живой тест работы сервиса с компьютера пользователя.

Опубликовано
⏰ 05.07.2019

Приветствую Вас, уважаемые читатели. Сегодня у нас тема: «Файловый сервер Windows server 2012-16». Мы добавим необходимую роль, и рассмотрим функционал файлового сервера.

Установка Файлового сервера в Windows server 2012-2016

• Заходим в диспетчер сервера, и на панели мониторинга кликаем по «Добавить роли и компоненты».

Окно-памятка мастера установки.

• Жмём «Далее».

Выбор типа установки.

• Нам нужна «Установка ролей и компонентов».
• Жмём «Далее».

Выбор целевого сервера.

• Выбираем нужный сервер, или виртуальный жёсткий диск, из списка.
• Жмём «Далее».

Выбор ролей сервера.

• Выбираем в списке «Диспетчер ресурсов файлового сервера».

• Открывается окно, с необходимыми к установке компонентами.
• Жмём «Добавить компоненты».

• В окне выбора компонентов, жмём «Далее».

Подтверждение установки компонентов.

• Проверяем выбранные параметры, если всё верно, жмём «Установить».

• Закрываем окно по окончании установки.

• Заходим в средства администрирования.

• Выбираем «Диспетчер ресурсов файлового сервера».

Радел «Квоты».

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

• Квоты можно создать на своё усмотрение, либо воспользовавшись, одним из шаблонов.

Раздел «Управление блокировкой файлов».

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

Раздел «Управление ресурсами хранилища».

• Тут можно автоматизировать процесс управления хранилищем.

Раздел «Управление классификацией».

• Тут можно настроить классификацию файлов, для более удобной работы с ними.

Раздел «Задачи управления файлами».

• Тут можно создать задачи для работы с файлами.

Сегодня мы рассмотрели тему: «Файловый сервер Windows server 2012-16». Добавили роль, и сделали краткий обзор функционала.

Надеюсь статья была вам полезна. До встречи в новых статьях.

✍

С уважением, Андрей Бондаренко.

---

Видео на тему «Файловый сервер Windows server 2012»:

Видео на тему «Файловый сервер Windows server 2016»:

✧✧✧

Поблагодарить автора за полезную статью:

WMZ-кошелёк = Z667041230317

---

✧ Рубрика «Windows server»

✧ Комментарии: нет

---

Похожие записи

---

Дата: 06.02.2015 Автор Admin

В данной статье я расскажу как настроить отказоустойчивый файловый сервер на Windows Server 2012 R2 в домене Active Directory   Первым делом убедитесь что сервер введен в домен Active Directory, далее установите роли DFS и файлового сервера

Выберите следующие роли и установите их.

Далее создайте структуру папок на отдельном диске.

Теперь включим общий доступ.

Выберите «расширенная настройка»

Далее выберите «Разрешения» и установите права как на скриншоте.

Теперь нам нужно создать структуру прав для наших каталогов в Active Directory.

Для начала рассмотрим из чего состоит наша файловая структура.

Теперь на ее основе создадим в Active Directory OU — File Sharing

Переходим в консоль пользователи и компьютеры, и создаем OU

Аналогичным путем создадим структуру наших папок

Теперь создадим комплекты прав.

Начнем мы с верхних папок.

Создадим 2-е локальные группы с правами RW и RO , и 2-е глобальные группы с правами RW и RO, и одну локальную L группу для листинга.

Разберем почему именно так.

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

Локальные группы назначаются на папки. Их членами являются глобальные группы.

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

Рассмотрим на практике, создадим комплект прав для папки Office_Files.

Создадим 2-е глобальные группы :

GD-Office_Files-RO

GD-Office_Files-RW

Создадим локальные группы:

LD-Office_Files-RO

LD-Office_Files-RW

LD-Office_Files-L

Глобальные группы входят в локальные

Теперь настроим права на папке.

Откройте свойство папки и выберите вкладку безопасность

Добавьте созданные локальные группы

Расставьте права на чтение и запись

Теперь нажмите кнопку «Дополнительно»

Теперь нужно установить права на листинг

Выберите L группу и нажмите изменить

Теперь установите параметры как на скриншоте ниже

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

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

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

Также отключите наследование прав от корневого каталога диска.

По аналогии настроим права на каталог Moscow.

Создадим группы:

GD-Moscow-RO

GD-Moscow-RW

LD-Moscow-RO

LD-Moscow-RW

LD-Moscow-L

В Active Directory это должно выглядеть так:

Теперь настроим права на папку:

Настроим листинг.

Теперь настроим нижний каталог — HR.

Создаем группы по аналогии.

GD-MoscowHR-RO

GD-MoscowHR-RW

LD-MoscowHR-RO

LD-MoscowHR-RW

Должно получится так

Теперь добавим группы GD-MoscowHR-RO и GD-MoscowHR-RW в группу LD-Moscow-L

Это нужно для того чтобы пользователи у которых нет прав на папку Moscow могли попасть во вложенную папку HR.

При этом открывать файлы в папке Moscow они не смогут.

Настроим права на папку.

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

Теперь добавим пространство имен.

Откроем консоль DFS и создадим пространство имен.

Указываем наш сервер.

Указываем название пути DFS.

Включаем режим 2008.

Создаем пространство.

Теперь создадим папку.

Далее указываем путь к папке. Путь можно посмотреть тут, выбрав «open share».

Создаем папку.

Теперь по данному пути — \test.comofficeOffice Мы видим нашу общую папку.

Теперь если добавить пользователя в группу GD-MoscowHR-RW, он сможет попасть в папку HR, но не сможет открывать или редактировать файлы в папке Moscow.

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

Если мы добавим пользователя в группу GD-Moscow-RW, он будет иметь доступ на всю папку Moscow, на чтение и запись.

Если мы добавим пользователя в группу GD-Office_Files-RW, он получит доступ ко всем каталогам.

Теперь рассмотрим настройку ABE.

Создайте следующую структуру в Active Directory.

Откройте общий доступ к папке.

Настройте права на папках.

И так далее.

Теперь создайте папку в DFS.

Должно получится так.

Теперь включим ABE.

В диспетчере сервера откройте «Файловые службы» — «Общие ресурсы».

Выберите каталог IT, и нажмите свойства.

Далее выбираем параметры, и включаем функцию — «Перечисление на основе доступа».

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

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

Для примера дадим пользователю support права на папку Support (добавим его в группу — GD-IT-Support-RW)

Теперь перейдем по пути — \test.comofficeIT

Как видите пользователь видит только папку Support.

Если мы добавим его в группу GD-IT-NetAdm-RO , то у него появится папка Network administrators с правами на чтение.

На этом настройка ABE закончена.

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

Перейдем в оснастку — Диспетчер ресурсов файлового сервера.

Настроим квоты.

Настроим мягкую квоту для папки Office_Files.

Настроим жесткую квоту для папки Support.

Теперь настроим блокировку файлов для папки Office_Files.

Выберем типы файлов, которые мы будем блокировать.

Настроим отправку сообщений по электронной почте.

Включим журнал.

Включим отчеты.

Учтите, без SMTP сервера отправка отчетов работать не будет.

Если вы хотите изменить группы файлов, то это можно сделать тут:

Создадим задачу управления файлами.

Представим что у нас есть папка Exchange. в которой пользователи обмениваются файлами.

Нам нужно сделать так, чтобы раз в период данная папка очищалась, а удаленные данные перемещались в папку Temp

Создаем задачу.

Задаем имя задачи.

Задаем путь и область.

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

Задаем срок действия папки.

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

Задаем условие.

Настраиваем расписание.

Готово!

Теперь перейдем к настройке репликации.

Настройте сервер реплику (роли и доступы), введите его в домен.

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

Назовем ее Office_Files, она будет репликой папки — Office_Files с основного файлового сервера.

Переходим на основной файловый сервер, и открываем консоль DFS.

Выбираем пространство имен, которое хотим реплицировать, и выбираем пункт «Добавить конечный объект папки».

Указываем общую папку со 2-го сервера.

На вопрос о создании группы репликации отвечаем — да.

Оставляем заполненное по-умолчанию.

Проверяем что указаны 2-а наших сервера, основной и резервный.

Указываем основной сервер.

Выбираем топологию — полная сетка.

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

Проверяем все, и выбираем — создать.

Если все прошло успешно, то вы увидите это:

Для отказоустойчивости добавим пространство имен для отображения, на 2-м нашем сервере.

И выберем наше пространство имен.

Должно получится так.

Теперь добавьте 2-й в «серверы пространства имен» на основном сервере.

Теперь пространство имен будет доступно на 2-х серверах.

Также обратите внимание, что настройки диспетчера ресурсов файлового сервера, настройки ABE, не реплицируются на 2-й сервер.

Настройку данного сервера нужно будет производить заново.

Также помните, что DFS репликация файлов работает по принципу — кто последний тот и прав.

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

А предыдущий файл будет сохранен в папке DfsrPrivateConflictandDeleted на сервере разрешившем проблему.

На этом все!  Удачной настройки!

Постоянно доступные общие файловые ресурсы, 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, хранить свои данные на файловых ресурсах с высоким уровнем доступности, предоставляя новые возможности для хранения данных критически важных приложений.

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

Реализация служб DFS в Windows Server 2012 отличается от предыдущих версиях Windows. В первую очередь отметим, что технологии DFS в Windows Server 2012 реализованы в виде двух отдельных, независимых друг от друга служб — DFS Namespaces и DFS Replication , включенных в роль файлового сервера (File and Storage Services).

• DFS Namespaces (DFSN или DFS-N) – пространство имен DFS. Позволяет объединять в единую логическую структуру общие папки, расположенные на различных серверах организации. Каждое пространство имен для пользователя выглядит как единая сетевая папка с подкаталогами. Реальная структура данного пространства имен DFS является скрытой от пользователя, и может включать в себя различные сетевые папки, расположенные на различных серверах и сайтах.
• DFS Replication (DFSR или DFS-R) — служба DFS репликации. Позволяет организовать эффективную службу репликации каталогов (в том числе включенных в пространство имен DFS) между различными серверами и сайтами AD. Данная служба для репликации использует специальный алгоритм удаленного разностного сжатия – RDC- remote differential compression. Благодаря RDC, которая отслеживает изменения в файлах, при репликации копируются не файлы целиком (как в случае с FRS репликацией), а только их блочные изменения.

Установка служб DFS в Windows Server 2012

Установить службы DFS можно с помощью консоли Server Manager или же при помощи Windows PowerShell.

Как мы уже говорили, службы DFS являются элементами роли Files and Storage Services:

Но проще и быстрее установить все DFS службы и консоль управления DFS с помощью PowerShell:

Install-WindowsFeature FS-DFS-Namespace, FS-DFS-Replication, RSAT-DFS-Mgmt-Con

Совет. Естественно, службы и консоль управления DFS можно установить и по отдельности.

, где FS-DFS-Namespace – служба DFS Namespaces

FS-DFS-Replication – служба репликации DFS Replication

RSAT-DFS-Mgmt-Con– mmc консоль управления службами DFS — DFS Management Tools (также входит в состав Remote Server Administration Tools для Windows 10)

Настройка пространства имен DFS в Windows Server 2012

Перейдем к описанию процедуры настройки пространство имен DFS, для чего необходимо открыть панель управления DFS Management tool.

Создадим новое пространство имен (New Namespace).

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

Затем следует указать имя создаваемого пространства имен DFS и перейти в расширенные настройки (Edit Settings).

Здесь следует указать имя пространства имен DFS и права доступа к данному каталогу. Обычно рекомендуется указать, что доступ к сетевой папке разрешен Всем (Everyone), в этом случае права доступа проверяются на уровне файловой системы NTFS.

Далее мастер предложит указать тип создаваемого пространства имен. Это может быть Domain-based namespace (доменное пространство имен) или Stand-alone namespace (отдельное пространство имен). Domain-based namespace обладает ряд преимуществ, но для его работы нужен, собственно домен Active Directory и права администратора домена (либо наличие делегированных прав на создание доменных пространств имен DFS).

После окончания работы мастера в ветке Namespaces консоли управления DFS появится созданное нами новое пространство имен DFS. Чтобы пользователи при доступе к DFS каталогам видели только те каталоги, к которым у них имеется доступ, включим для данного пространства DFS Access-Based Enumeration (подробнее о данной технологии в статье Access-Based Enumeration в Windows). Для этого откройте окно свойств созданного пространства имен.

И на вкладке Advanced включите опцию Enable access-based enumeration for this namespace.

Чтобы посмотреть содержимое нового пространства DFS, просто наберите в окне проводника UNC путь: \имя_домена_или_сервераDFS

Добавление дополнительного DFS сервера

В доменное пространство имен DFS можно добавить дополнительный сервер (пункт меню Add Namespace Server), который его будет поддерживать. Делается это для увеличения доступности пространства имен DFS и позволяет разместить сервер пространства имен в том же сайте, в котором находится пользователи.

Примечание. Отдельно стоящие пространства имен DFS поддерживают только один сервер.

Добавление нового каталога в существующее пространство имен DFS

Теперь нужно добавить новый сетевой каталог в иерархию созданного нами пространства имен DFS. Нажмите кнопку Add Folder Target.

Укажите наименование каталога в DFS пространстве и его реальное местоположение на существующем файловом сервере (Folder targets).

Настройка DFS-репликации на Windows Server 2012

Технология репликации DFS-R предназначена для организации отказоустойчивости пространства имен DFS и балансировки нагрузки между серверами. DFS-R автоматически балансирует трафик между репликами в зависимости от их загрузки и в случае недоступности одного из серверов перенаправляет клиентов на другой сервер-реплику. Но прежде, чем говорить о DFS репликации и ее настройке в Windows Server 2012перечислим основные системные требования и ограничения:

• Служба DFS Replication должна быть установлена на всех серверах, которые планируется включить в группу репликации
• Все сервера в группе репликации должны находиться в одном лесу AD
• Уровень леса Active Directory должен быть как минимум Windows Server 2003 R2 (при установке первого домена контроллера на Windows Server 2012 схема обновляется автоматически).
• Функциональный уровень домена — как минимум Windows Server 2008
• Необходимо убедиться, что антивирусное обеспечение на файловых серверах совместимо с технологией репликации DFS
• Реплицируемые каталоги должны располагаться на томах с файловой системой NTFS (файловые системы ReFS и FAT не поддерживаются). Также не поддерживается репликация данных, хранящихся на on Cluster Shared Volumes

В консоли DFS Managment выберите нужный вам DFS Namespace и щелкните ПКМ по каталогу, для которого необходимо создать реплику и выберите пункт Add Folder Target.

И укажите полный (UNC) путь к сетевому каталогу другого сервера, в котором и будет храниться реплика.

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

Запускается мастер настройки репликации. Проверяем имя группы репликации и каталог.

Указываем первичный (Primary) сервер. Именно этот сервер будет источником данных при инициальной (первичной) репликации.

Затем выбираем тип топологии (соединения) между членами группы репликации. В нашем примере выбираем Full Mesh (все со всеми).

И, наконец, указываем расписание репликации и параметры bandwidth throttling – ограничение доступной для репликации полосы пропускания.

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

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

В Windows Server 2012 появилась технология SMB Scale-Out, позволяющая создавать масштабируемые файловые кластера — Scale-Out File Server (SOFS). SOFS представляет из себя новый тип файлового кластера, работающего в режиме Active-Active. В этом режиме все узлы кластера могут одновременно обрабатывать запросы SMB-клиентов на подключение к файловым шарам.

Принцип работы Scale-Out File Server

Для подключения к стандартному кластеру клиент использует специальную точку подключения Client Access Point (CAP). CAP является кластерным ресурсом и состоит из сетевого имени (Network Name, NN) и одного (или нескольких) уникальных IP-адресов. Также файловый кластер может включать в себя ресурсы типа Storage и File Server.

При соответствующей настройке CAP регистрируется в DNSWINS. Вот так в DNS выглядит обычная точка клиентского доступа (CAP) двухузлового файлового кластера.

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

SOFS использует другой подход для работы с клиентами. Для этого используется ресурсы распределенного сетевого имени (Distributed Network Name, DNN) и Scale-Out File Server. Ресурсы IP-адреса и хранилища не используются.

Группа ресурсов Scale-Out File Server запускается на одном из узлов кластера, который называется лидером (Leader). Все остальные узлы содержат копии (клоны) группы ресурсов. Клоны управляются лидером, который следит за порядком их запуска и остановки, а также отслеживает их состояние. Группа ресурсов SOFS не выключается, пока доступен хоть один клон. Лидер может быть перенесен на любой из узлов кластера, его перемещение никак не скажется на доступность файловых шар.

Хотя SOFS и не использует IP-адрес в качестве кластерного ресурса, DNN зависит от адресов каждого узла кластера. DNN регистрируется в DNS, используя IP-адреса сетевых интерфейсов всех узлов кластера, на которых обрабатываются клиентские подключения. Вот так в DNS выглядит запись DNN для двухузлового кластера SOFS.

DNN отвечает за отслеживание состояния узлов кластера и обновление информации в DNS:

• Каждые 24 часа, либо при запуске DNN;
• В случае добавления или удаления узлов кластера;
• При изменении IP-адреса;
• При добавлении или удаления IP-адреса из сети кластера.

Для распределения подключений к узлам кластера в DNS используется round-robin. SMB-клиент получает полный список адресов, связанных с DNN, и затем пытается подключиться, используя по очереди первые восемь адресов из списка. Попытки происходят с интервалом в 1 секунду до тех пор, пока не произойдет подключение.

Таким образом, в отличие от обычного кластера, в котором все клиенты подключаются к одному узлу (режим Active-Passive), при использовании кластера SOFS клиентские подключения равномерно распределяются между всеми узлами кластера (режим Active-Active).

Работа Scale-Out File Server базируется на нескольких новых технологиях, о которых стоит упомянуть.

Cluster Shared Volume (CSVv2)

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

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

Технология CSV появилась еще в Windows Server 2008 R2, однако тогда общие тома CSV можно было задействовать исключительно для роли Hyper-V. Начиная со второй версии (CSVv2) в Windows Server 2012 эти ограничения сняты и можно использовать CSV-тома для роли отказоустойчивого файлового сервера. То есть мы можем сконфигурировать кластер с одним или несколькими томами CSV, поднять на нем роль Scale-Out File Server и в рамках этой роли создать на CSV необходимое количество файловых шар, одновременный доступ к которым будет возможен с любого из узлов кластера.

SMB Transparent Failover

Для созданных таким образом шар будет поддерживаться технология SMB Transparent Failover, реализованная в SMB 3.0. Суть этой технологии в том, чтобы обеспечить прозрачное переключение SMB-клиентов на другой узел кластера в случае отказа текущего узла.

При отработке отказа в обычном файловом кластере в том же Windows Server 2008 R2 существовало 2 основных проблемы. Во первых, при переключении на другой узел клиенту необходимо было определить факт недоступности текущего узла и осуществить подключение к работающему узлу. Эта процедура занимает некоторое время (порядка 40 секунд), в течение которого приостанавливались все операции с файлами. И во вторых, при переключении сбрасывались все файловые дескрипторы и блокировки. Как правило, это не причиняло особых проблем при работе с обычными пользовательскими файлами (документами, изображениями и т.п.), но для серверных приложений типа SQL Server подобный подход недопустим.

SMB Transparent Failover решает обе проблемы и обеспечивает непрерывную доступность общих файловых ресурсов для клиентов SMB 3.0. Для этого в SMB 3.0 используются компоненты SMB Witness и Resume Key Filter.

При подключении к общей шаре SMB-клиент проверяет, установлен ли для нее признак непрерывной доступности (Continuous availability), и если да — то открывает файл от имени приложения,  запрашивает у SMB-сервера дескриптор файла и предоставляет уникальный ключ (resume key). SMB-сервер извлекает и предоставляет клиенту необходимые данные, а информацию о дескрипторе файла и клиентский ключ сохраняет на диске, используя фильтр Resume Key.

При переключении (плановом или внеплановом) на другой узел кластера SMB-клиент пытается завершить операцию, начатую на предыдущем узле, используя свой resume key. Сервер, получив resume key, обращается к фильтру Resume Key и восстанавливает состояние дескриптора файла на момент, предшествующий сбою. При этом приложение на клиенте никак не участвует в этом процессе и испытывает лишь небольшую задержку в операциях ввода-вывода.

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

Как только на узле кластера, к которому подключен SMB-клиент, происходит сбой, служба кластера оповещает о нем Witness-сервис альтернативного узла, который сразу-же передает сообщение Witness-клиенту. Соответственно клиент SMB, получив извещение от Witness-клиента, немедленно начинает процедуру подключения к другому узлу кластера. Подобный подход позволяет значительно уменьшить время простоя (примерно с 40 до 7-10 секунд).

Надо сказать, что поскольку SOFS использует возможности протокола SMB 3.0, то для использования всех преимуществ SOFS необходим клиент с поддержкой этого протокола. На данный момент это операционные системы Windows 8Server 2012 и более новые. Хотя подключиться к шарам на файловом сервере SOFS смогут и другие клиенты, но прозрачная отработка отказа (Transparent failover) для них не будет доступна.

На этом закончим теоретическую часть и приступим к практике.

Для создания двухузлового файлового сервера с ролью Scale-Out File Server я использую два сервера SRV3 и SRV4 под управлением Windows Server 2012 R2. Оба сервера подключены к общему хранилищу iSCSI, на котором под нужды кластера выделены 2 LUNа — один под том CSV, второй под кворумный диск. Оба сервера являются членами домена Active Directory.

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

Установка службы Failover Clustering

Открываем Server Manager, запускаем мастер добавления ролей и в разделе «Features» отмечаем пункт Failover Clustering. Эту процедуру необходимо проделать на всех серверах, которые планируется добавлять в кластер.

То же самое можно проделать и с помощью PowerShell. Следующая команда установит фичу Failover Clustering вместе со средствами управления:

Install-WindowsFeature -Name Failover-Clustering –IncludeManagementTools

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

Для создания кластера нам потребуется оснастка Failover Cluster Manager. Открыть ее можно из Server Manager, выбрав соответствующий пункт в меню Tools.

Перед тем, как создавать кластер, проведем валидацию его узлов, т.е. проверку всех компонентов кластера (серверов, сети и хранилища) на соответствие необходимым требованиям. Для запуска валидации в оснастке Failover Cluster Manager перейдем на пункт «Validate Configuration».

Запускается мастер проверки конфигурации. На первом экране читаем полезную информацию и жмем Next.

Выбираем сервера, которые будут проходить проверку.

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

Смотрим список тестов и жмем Next, запуская проверку.

Тестов довольно много, так что проверка занимает некоторое время. Процесс проверки отображается в окне мастера валидации.

По результатам проверки будет выведен отчет. Если при проверке были обнаружены некритичные ошибки, то в отчете будет предупреждение (желтый треугольник), серьезные ошибки будут отмечены красным крестом. С предупреждениями стоит ознакомиться, но можно их проигнорировать, ошибки же необходимо исправить перед созданием кластера.

Поскольку наш кластер успешно прошел валидацию, то отмечаем чекбокс Create the cluster now using the validated nodes (Создать кластер немедленно используя проверенные узлы) и жмем Finish.

Запускается мастер создания кластера. Жмем Next

Вводим имя кластера и IP-адрес, по которому кластер будет доступен в сети.

Примечание. Начиная с Windows Server 2012 IP-адрес кластера можно назначать через DHCP, но я предпочитаю назначать кластерам статический адрес.

Дальше переходим на страницу подтверждения, смотрим настройки и если все верно, то запускаем создание кластера кнопкой Next. Обратите внимание на чекбокс Add all eligible storage to the cluster (Добавить все подходящие хранилища в кластер). Если он отмечен (а по умолчанию это так), то мастер автоматически добавит в кластер и сконфигурирует все найденные общие диски.

По завершении мастер выдаст страницу с информацией о параметрах нового кластера.

Также провести валидацию и создать кластер можно с помощью PowerShell, следующими командами:

Test-Cluster -Node SRV3,SRV4
New-Cluster -Name Cluster1 -Node SRV3,SRV4 -StaticAddress 192.168.0.100

Настройка диска-свидетеля

При создании кластера по умолчанию используется модель кворума с диском-свидетелем (Disk Witness), при этом диск-свидетель выбирается автоматически, и иногда не тот, который нужен. Для того, чтобы проверить настройки дисков, открываем раздел Storage -> Disks. Диск-свидетель обозначен как Disk Witness in Quorum. Как видите, в нашем случае в качестве свидетеля выбран не тот диск, который я изначально планировал.

Для изменения настроек кворума кликаем правой кнопкой мыши на имени кластера и переходим на пункт меню More Actions -> Configure Cluster Quorum Settings.

В мастере настройки выбираем пункт Select the quorum witness.

Затем выбираем Configure a disk witness.

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

Проверяем получившиеся настройки и жмем Next, подтверждая изменения.

Также перенастроить диски можно из PowerShell. Сначала выясняем, кто является кворумным диском-свидетелем:

Get-ClusterQuorum -Cluster Cluster1

и меняем его на другой:

Set-ClusterQuorum -Cluster Cluster1 -DiskWitness ″Cluster Disk 2″

 Создание CSV

В отличие от Server 2008 R2 в Server 2012 общие кластерные тома (CSV) включены по умолчанию, требуется только выбрать хранилище. Чтобы активировать CSV на выбранном диске, кликаем по нему правой кнопкой и выбираем Add to Cluster Shared Volumes. После этого поле Assigned to этого диска изменится с Available Storage на Cluster Shared Volume.

Общие кластерные тома монтируются к системному диску как папки, так что на каждом из узлов кластера появится папка C:ClusterStorageVolume1.

И снова PowerShell. Для создания CSV-тома выполним команду:

Add-ClusterSharedVolume -Cluster Cluster1 -Name ″Cluster Disk 1″

Ну а для удаления, соответственно:

Remove-ClusterSharedVolume -Cluster Cluster1 -Name ″Cluster Disk 1″

В результате получаем вот такую картину — первый диск используется как CSV-том, а второй как диск-свидетель.

Установка роли Scale-Out File Server

Перед созданием Scale-Out File Server убедитесь, что на всех узлах кластера установлена роль File Server.

Затем в Failover Cluster Manager переходим в раздел Configure и жмем Configure Role.

Выбираем из списка доступных ролей File Server.

Затем выбираем тип файлового сервера Scale-Out File Server for application data.

Вводим имя, по которому сервер будет доступен для клиентов.

Подтверждаем настройки

и смотрим результат. А в результате у нас получился отказоустойчивый файловый сервер с именем FileSRV1.

Поднять роль SOFS-сервера из PowerShell можно командой:

Add-ClusterScaleOutFileServerRole -Cluster Cluster1 -Name FileSRV1

Создание файловой шары

Ну и последний пункт — это создание файловой шары со свойством непрерывной доступности (Continuous availability). Для этого переходим в раздел «Roles», кликаем правой клавишей на нужной роли и в открывшемся контекстном меню выбираем пункт «Add File Share».

Выбираем из списка тип SMB Share — Applications

указываем расположение файловой шары на выбранном сервере

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

Затем смотрим, отмечен ли в свойствах шары пункт «Enable continuous avalability».

Раздаем необходимые разрешения.

Проверяем получившиеся параметры и жмем «Create». Обратите внимание, что в свойствах шары указано Scale-Out file share.

Заключение

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

Во первых, SOFS не поддерживает протокол NFS, а также роли  Distributed File System Replication (DFS-R) и File Server Resource Manager (FSRM). То есть для файловых шар нельзя задействовать файловые квоты, классификацию файлов и прочие полезности.

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

И наоборот, идеальной для SOFS является ситуация, когда файлы постоянно открыты и в них производится большое количество операций ввода-вывода, как в случае с файлами баз данных SQL Server или виртуальными дисками Hyper-V.

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

Системное администрирование, Хранение данных, Виртуализация

---

Рекомендация: подборка платных и бесплатных курсов системных администраторов — https://katalog-kursov.ru/

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