Настраиваем высоко-доступный сервер FTP в существующем файловом кластере на базе Windows Server 2012 R2 Failover Cluster (без выделенного диска под роль FTP)

Возникла необходимость в развёртывании сервера FTP с анонимной авторизацией для внутренних задач в локальной сети. И чтобы не плодить лишние сущности, то есть не разворачивать дополнительный сервер исключительно под эту задачу, возникло желание использовать существующие файловые сервера. В нашем случае файловый сервис реализован на базе двух серверов состоящих в кластере Failover Cluster на Windows Server 2012 R2 и использующих общее дисковое хранилище. Решение предлагаемое Microsoft для кластеризации FTP на базе Failover Cluster в статье KB974603 - How to configure FTP for IIS 7.0 or higher in a Windows Server 2008 or Windows Server 2012 failover cluster нам в чистом виде не подошло, так как оно предполагает наличие выделенного общего кластерного диска, а в нашей ситуации вся доступная ёмкость общего дискового хранилища в кластере уже была отдана под роль файлового сервиса. Статья The Admin's Window - Configuring highly available FTP server on a Windows Server 2008 failover cluster (without FTP dedicated storage) натолкнула на размышления о том, как можно обойти эту ситуацию.

В этой статье описан метод небольшого изменения существующей кластерной конфигурации таким образом, чтобы можно было для роли сервера высоко-доступного FTP использовать кластерную группу ресурсов (в том числе и общую дисковую емкость) существующего файлового кластера. Несмотря на то, что указанной статье без малого три года и речь в ней шла о Windows Server 2008/2008 R2 и IIS 7, мы решили попробовать реализовать данный сценарий на Windows Server 2012 R2, добавив в предложенную реализацию функционал общей конфигурации IIS как описано в KB974603. Однако после развертывания и тестирования такой конфигурации стало понятно, что в ней тоже есть свои недостатки. В дальнейшем после некоторых экспериментов получилось собрать такую конфигурацию, при которой на узлах существующего файлового кластера для кластерного экземпляра службы FTP используется отдельная кластерная группа ресурсов. При этом IIS на узлах кластера использует общую конфигурацию (IIS Shared Configuration), а корневая папка высоко-доступного FTP-узла указывает также на сетевой каталог в файловом кластере. Для наглядности приведу получившуюся конфигурацию в схематичном виде:

В соответствии с этой схемой весь процесс настройки высоко-доступного сервера FTP в существующем файловом кластере на базе Windows Server 2012 R2 Failover Cluster будет состоять из следующих шагов:

1. Подготавливаем инфраструктуру
2. Устанавливаем роль веб-сервера IIS на всех узлах кластера
3. Создаём в файловом кластере общую папку для файлов IIS Shared Configuration
4. Настраиваем общую конфигурацию IIS на всех узлах кластера
5. Создаём в файловом кластере общую папку для корневого каталога будущего FTP-узла
6. Создаём и настраиваем FTP-узел
   6.1. Создаём новый FTP-узел
   6.2. Создаём отдельный пул приложений IIS для FTP-узла
   6.3. Изменяем учетную запись анонимного доступа к FTP-узлу
   6.4. Проверяем доступность FTP-узла с разных серверов
7. Настраиваем высокую доступность для службы FTP
8. Настраиваем FTP Site Binding
9. Включаем в файловом кластере дисковую квоту для корневого каталога FTP-узла
10. Проверяем работу FTP-клиентом на скорость и порт Passive-режима

1. Подготовка инфраструктуры

В отдельном OU в домене создадим учетную запись компьютера с именем, которое мы планируем использовать в дальнейшем для создания кластерного ресурса FTP. Эта учетная запись будет использоваться в качестве Cluster Name Object (CNO). После создания учетной записи нам необходимо будет её выключить, чтобы служба кластеризации смогла использовать этот объект. В соответствии с нашей схемой для экземпляра кластера Failover Cluster уже используется учетная запись KOM-AD01-FSFC01, и мы создадим и отключим учетную запись KOM-AD01-FSFTP – для будущей кластеризованной службы FTP Server, которая будет работать на базе этого кластера.

В свойствах безопасности учетной записи KOM-AD01-FSFTP добавляем полные разрешения для учетной записи KOM-AD01-FSFC01, чтобы служба кластера могла беспрепятственно сконфигурировать CNO службы FTP. Доступ предоставим как на сам объект, так и на его дочерние объекты.

Далее создадим в домене две служебные учетные записи пользователей:

1) s-FTP-SVCFG – Учётная запись будет использоваться для доступа служб IIS с узлов кластера (с серверов KOM-AD01-FS03 и KOM-AD01-FS04) к специальной сетевой папке, в которой будут размещаться файлы общей конфигурации IIS Shared Configuration. Эта же учетная запись будет использоваться для пула приложений IIS, на котором будет работать FTP-узел.
2) s-FTP-IUSR - Учетная запись будет использоваться для доступа к специальной сетевой папке, которая будет выступать в качестве корневой для размещения контента FTP-узла (в качестве замены встроенного локального идентификатора безопасности IUSR используемого для анонимной авторизации).

 

2. Устанавливаем роль веб-сервера IIS на всех узлах кластера

Через оснастку Server Manager устанавливаем компоненты роли Web Server на оба сервера.

Оставляем включенные по умолчанию компоненты при выборе установки роли Web Server и добавляем необходимую для нашей задачи компоненту FTP Service

Первоначальное желание максимально минимизировать установку IIS с экспериментами по установке отдельно лишь службы FTP Service (без установки предлагаемых по умолчанию компонент IIS) показали то, что в результате такой установки полноценно управлять конфигурацией IIS/FTP в оснастке IIS Manager не представляется возможным. Именно поэтому мы и оставляем к установке предложенные по умолчанию компоненты IIS.

 

3. Создаём общую папку для файлов IIS Shared Configuration

Создадим в нашем файловом кластере KOM-AD01-FSCL01 общую папку и предоставим созданной ранее учетной записи s-FTP-SVCFG полный доступ к этой папке на уровне свойств общего доступа…

Для порядка внутри этой сетевой папки создадим подкаталог с именем будущего FTP-кластера и предоставим учетной записи s-FTP-SVCFG полные права на этот каталог на уровне NTFS…

Так как этот подкаталог будет содержать конфигурационные файлы, критичные для работы IIS, и соответственно серверов в целом, отключим наследование разрешений NTFS с каталога верхнего уровня, чтобы в итоге к данным каталога имели доступ только Администраторы сервера, Учетная запись SYSTEM (например для возможности корректного бэкапа) и наша сервисная учетная запись s-FTP-SVCFG.

4. Настраиваем общую конфигурацию IIS на всех узлах кластера

Для того чтобы оба узла кластера использовали единые настройки конфигурации IIS включим и настроим функционал IIS Shared Configuration. Нам необходимо, чтобы роль Web Server была свеже-установленной на обоих серверах и не имела каких-то сконфигурированных и работающий веб-узлов. Начать настройку можно с любого из серверов. В нашем примере мы начнём общей конфигурации IIS настройку с сервера KOM-AD01-FS03. Откроем оснастку IIS Manager, перейдём в дереве навигации на уровень сервера и в разделе настроек Management выберем пункт Shared Configuration 

Первым делом нам нужно будет создать базовые файлы конфигурации в общей папке, которую мы создали на предыдущем этапе, то есть выгрузить с текущего узла текущие настройки IIS. Для этого воспользуемся действием Export Configuration 

В открывшейся диалоговой форме укажем путь к соответствующей сетевой папке а в качестве Connect As можем указать учетную запись s-FTP-SVCFG, заодно тем самым мы проверим корректность настроенного нами ранее доступа к этой папке для этой учетной записи. Два раза введём пароль Encryption Keys, который нужен для того, чтобы зашифровать имеющиеся в настройках IIS данные параметров безопасности (например сохранённые учетные записи). Запомним этот пароль, так как он потребуется нам в дальнейшем при подключении серверов IIS к создаваемым файлам этой общей конфигурации. 

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

Теперь созданные файлы общей конфигурации IIS нужно подключить к обоим серверам. Начнём здесь же, на сервере KOM-AD01-FS03, в оснастке IIS Manager в свойствах Shared Configuration включаем опцию использования общей конфигурации – Enable shared configuration, указываем путь к соответствующей общей папке и учетную запись от имени которой будет происходить подключение к этой папке - s-FTP-SVCFG 

После нажатия Apply нас попросят ввести пароль шифрования, который был задан в процессе экспорта конфигурации …

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

То же самое повторяем на втором сервере - KOM-AD01-FS04. При этом, как вы наверно уже поняли, экспорт выполнять не нужно, так как второй сервер сразу подключается к уже созданной сетевой конфигурации IIS. Поэтому на втором сервере достаточно включить опцию Enable shared configuration, указать путь размещения конфигурационных файлов и учетную запись, от имени которой будет произведено это подключение по аналогии с тем, как это было сделано на первом сервере.

 

5. Создаём общую папку корневого каталога будущего FTP-узла

Создадим в нашем файловом кластере KOM-AD01-FSCL01 ещё одну сетевую папку, которая будет выступать в качестве корневого каталога для будущего FTP-узла. На уровне сетевого доступа предоставим к этой папке полный доступ для учетной записи s-FTP-IUSR и доступ на чтение для учетной записи s-FTP-SVCFG

Для порядка внутри этой сетевой папки создадим подкаталог с именем будущего FTP-кластера. Соответственно на уровне прав доступа NTFS доступа предоставим к этой папке полный доступ для учетной записи s-FTP-IUSR и доступ на чтение для учетной записи s-FTP-SVCFG

Позже мы вернёмся к дополнительной настройке данной сетевой папки в файловом кластере.

 

6. Создаём и настраиваем FTP-узел

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

6.1. Создаём новый FTP-узел

Открываем оснастку IIS Manager, в дереве навигации Connections выбираем Sites > Add FTP Site… В открывшейся диалоговой форме создания нового FTP-узла вводим его имя и путь к корневой папке, в которой будет размещаться файловый контент. В качестве корневой папки FTP-узла указываем созданный ранее подкаталог в соответствующей сетевой папке.

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

Далее нам будет предложено выбрать режим аутентификации для нашего FTP-узла и настроить основное правило доступа к корню узла. Опять же при необходимости позднее можно будет настроить разрешения на запись на отдельные подпапки создаваемые в корне.

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

6.2. Создаём отдельный пул приложений IIS для FTP-узла

Создадим новый отдельный пул приложений IIS (Application Pools > Add Application Pool…) и зададим ему созвучное FTP-узлу имя..

В свойствах созданного пула приложений укажем для его выполнения учетную запись s-FTP-SVCFG (выбираем созданный пул приложений и изменяем Advanced Settings > Identity > Custom account)

Теперь созданный пул приложений нужно назначить нашему FTP-узлу. Выбираем FTP-узел и вызываем окно базовых настроек узла (Sites > Имя FTP-узла > Basic Settings…)

В открывшейся диалоговой форме базовых настроек выбираем только что созданный нами Application pool и нажимаем Test Settings чтобы проверить то, что учетная запись пула приложений может получить доступ на чтение корневой папки FTP-узла (Physical path) 

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

 

6.3. Изменяем учетную запись анонимного доступа к FTP-узлу

Так как корневой каталог нашего FTP-узла расположен в сетевой папке, нам нужно изменить учетные данные от имени которых FTP-клиенты будут обращаться к этой папке. Для этого откроем свойства Anonymous Authentication в Sites > Имя FTP-узла > FTP Authentication, вызовем пункт меню Edit и заменим используемое по умолчанию значение IUSR на учетную запись s-FTP-IUSR, которой мы ранее предоставили полный доступ к этой самой папке

6.4. Проверяем доступность FTP-узла с разных серверов

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

Однако перед тем, как проверить доступность только что созданного и настроенного FTP-узла (по отдельности на каждом сервере), нам нужно обратить внимание ещё на пару моментов:

1) Убедиться в том, что при добавлении роли Web Server на оба сервера в Windows Firewall были автоматически добавлены и включены правила, разрешающие подключения к службе Microsoft FTP Service в режиме Active и Passive…

Если так получилось, что по какой-то причине этих правил нет или вообще используется какой-то сторонний брандмауэр, то можно создать необходимые правила самостоятельно используя материалы изложенные в статьях IIS.net - Configuring FTP Firewall Settings in IIS 7 и OSzone.net - Контекст командной строки Netsh advfirewall

2) Выполнить на обоих серверах перезапуск службы Microsoft FTP Service (FTPSVC). Это необходимо для того, чтобы служба перечитала настройки выполненные нами в IIS. Практическое хождение по граблям показало то, что !в некоторых случаях! при реконфигурации настроек FTP в IIS при использовании общей конфигурации, для вступления их в силу порой не помогает ни перезапуск узла в консоли IIS Manager, ни даже перезапуск сервера IIS, а спасает именно перезапуск самой службы Microsoft FTP Service на на всех узлах, использующих общую конфигурацию IIS.

Теперь можно проверить доступность FTP-узла по отдельности на каждом сервере. Например, доступность FTP-узла с сервера KOM-AD01-FS03 проверим с помощью утилиты командной строки ftp, а с сервера KOM-AD01-FS04 с помощью Windows Explorer…

Если результат проверок положительный, то можно переходить к процессу создания FTP-кластера.

 

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

Из ранее упомянутой статьи KB974603 скопируем содержимое скрипта для создания кластерной роли FTP в IIS в файл с именем Clusftp7.vbs и на обоих серверах разместим этот файл в расположение
%systemroot%\System32\Inetsrv\Clusftp7.vbs
Читатели нашего блога также могут загрузить копию скрипта по ссылке.
Теперь на основе этого скрипта нам нужно создать новую кластерную роль. Для этого на любом из серверов в оснастке Failover Cluster Manager выбираем кластер KOM-AD01-FSFC01 > Roles > Configure Role…

В открывшемся мастере добавления кластерных ролей выбираем добавление роли на основе универсального сценария - Generic Script

Затем указываем путь размещения скрипта (напомню, что он должен быть идентичен на всех узлах кластера) - %systemroot%\System32\Inetsrv\Clusftp7.vbs

На шаге Client Access Point указываем имя будущего кластерного экземпляра FTP и его IP-адрес. Именно эти данные в дальнейшем будут использовать FTP-клиенты для подключения к высоко доступному FTP-серверу.

Нажимаем Next, и после того, как мастер проверит доступность учетной записи KOM-AD01-FSFTP в домене, нам будет предложено выбрать общие диски для новой роли… Исходя из первоначальных условий нашей задачи у нас таких дисков нет, и поэтому мы просто переходим к следующему шагу мастера…

Далее мастер выполнит создание новой кластерной роли и покажет нам статус выполнения задачи.

Далее в оснастке Failover Cluster Manager на вкладке управления кластерными ролями проверим состояние вновь созданной роли и просмотрим ресурсы этой роли…

Небольшое замечание относительно использования универсального сценария. Если вы планируете создание нескольких FTP-сайтов, то для них всех согласно KB974603 можно использовать один и тот же скрипт в том случае, если скрипт используется без модификаций. В случае же если скрипт каким-то образом модифицируется под определённый FTP-сайт, то для других сайтов возможно потребуется добавление отдельной роли с копией скрипта с изменением его имени, например Clftp7-2.vbs для второго сайта, Clftp7-3.vbs – для третьего и т.п.

При создании кластерной роли должна быть выполнена автоматическая регистрация указанного имени FTP-кластера в DNS. Проверим доступность созданного кластерного ресурса заодно убедившись в том, что имя без проблем разрешается в IP-адрес, то есть динамическая регистрация имени Client Access Point в DNS прошла успешно. Ну и сразу же проверяем доступность нашего кластеризованного FTP-узла.

8. Настраиваем Site Binding для ограничения TCP-прослушивателей

Если наши сервера имеют несколько сетевых адаптеров, которые используются для разных служб и приложений, то возможно имеет смысл подумать о дополнительных мерах безопасности на сетевой уровне. Ранее, в процессе создания FTP-узла в качестве Binding IP Address мы указали значение All Unassigned. Это значит что TCP-прослушиватель поднимаемый на серверах службой FTP Service будет принимать соединения на порт FTP-узла (в нашем случае это порт TCP 21) на всех сетевых интерфейсах сервера. Поэтому для повышения уровня безопасности в целом мы можем ограничить Binding лишь IP адресом, отвечающим за нашу кластерную роль. Для этого в оснастке IIS Manager выберем наш FTP-узел > Edit Bindings и вместо значения * выберем из ниспадающего списка IP адрес нашей кластерной роли FTP.

После этого настройки должны вступить в силу сразу после их сохранения. Если этого не произошло, то можно попробовать выполнить перезапуск службы Microsoft FTP Service. В результате, несмотря на то, что TCP-прослушиватель создается не совсем так как я предполагал (не на отдельном выделенном IP)..

…тесты показывают, что служба FTP по-честному отвечает на удалённые клиентские запросы только согласно настроенным правилам Binding. То есть, например, при попытке обратиться к интерфейсам серверов по отдельности, в соединении будет отказано…

При этом соединение с IP адресом указанным в Binding будет работать как ни в чём не бывало. 

 

9. Включаем дисковую квоту для корневого каталога FTP-узла

Если сетевая папка, используемая в качестве корневого каталога нашего FTP-узла, расположена на одном логическом дисковом томе, что и папки используемые для других приложений, нам следует подумать о том, как можно повысить меры безопасности в плане использования дисковых ресурсов. Этот вопрос может быть особенно актуален на фоне того, что мы используем анонимную авторизацию на FTP-узле, и теоретически любой FTP-клиент может переполнить всё доступное дисковое пространство на кластерном диске файлового кластера. Чтобы избежать такой ситуации воспользуемся механизмом управления дисковыми квотами из компоненты File Server Resource Manager в составе серверной роли File and Storage Services. В оснастке Server Manager переключимся на управление ролью File and Storage Services и выберем пункт Shares. В окне SHARES выберем общую сетевую папку, которую мы назначили в качестве корневой для контента нашего FTP-узла и переключимся в окно QUOTA чтобы настроить дисковую квоту…

Из списка доступных к назначению шаблонов квот выберем шаблон, который мы ранее подготовили через консоль File Server Resource Manager (fsrm.msc). В нашем случае папке назначен шаблон с жёстким ограничением дискового пространства в 20GB с оповещением администратора на email при достижении 95% квоты.

Чтобы быстро проверить применение наложенной квоты, достаточно включить в IIS Manager в свойствах нашего FTP-узла отображение клиентам доступного свободного места в корневой папке через Sites > Название FTP-узла >  FTP Directory Browsing … включить опцию Available bytes

После этого FTP-клиентам станет доступна информация о свободном пространстве с учетом наложенной квоты…

10. Проверяем работу FTP-клиентом на скорость и порт Passive-режима

Теперь всё что нам остается сделать, это всесторонне протестировать наш высоко-доступный FTP-сервер. Так как встроенными в Windows средствами мы уже проделали эту процедуру, воспользуемся сторонним FTP-клиентом FileZilla 3.7.4.1, как одним из наиболее функциональных. Одной из приятных функций данного клиента является возможность восстановления соединения и повторная передача файла при временной недоступности FTP-сервера, например в момент перехода по отказу кластерной роли с одного узла кластера на другой…

Во время передачи файлов на FTP мы можем видеть текущую скорость передачи в MiB/s. В верхней части приложения нам доступен подробный лог выполняемого соединения. В частности в данном случае мы видим, что соединение установлено в режиме Passive, а также можем понять какой порт из диапазона динамически назначаемых (при режиме Passive) используется для передачи данных - значение (10,160,0,125,202,206) говорит о том, что на стороне сервера для канала передачи данных используется порт 51918. При значении ответа от FTP-сервера вида (h1,h2,h3,h4,p1,p2) параметры h1,h2,h3,h4 определяют IP адрес сервера, а PASV port определяется по формуле (p1 * 256) + p2. Подсчет номера порта может оказаться полезным в случае, если вы вырешили ограничить диапазон динамических TCP портов, используемых в  режиме Passive. Это ограничение настраивается в IIS Manager в свойствах группы настроек FTP > пункт FTP Firewall Support > параметр Data Channel Port Range

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

Дополнительные источники информации:

IIS.net - Configuring FTP Firewall Settings in IIS 7
IIS.net - How Do I Configure FTP Security in IIS?