Scale-Out File Server в Windows Server 2012
В 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 регистрируется в DNS\WINS. Вот так в 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 8\Server 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:\ClusterStorage\Volume1.
И снова 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.