Методы повышения отказоустойчивости файловых ресурсов общего доступа

Джон Сэвилл (jsavill@windowsitpro.com) — директор по технической инфраструктуре компании Geniant, имеет сертификаты CISSP, Security and Messaging MCSE для Windows Server 2003 и звание MVP

Какие функции Windows Server вы считаете самыми важными? Вряд ли службы общего доступа к файлам окажутся в первой пятерке. Однако отношение к ним может измениться с выходом Windows Server 2012. . Я покажу, как объединить эти компоненты в среде файловых служб для самой высокой рабочей нагрузки, в том числе для размещения баз данных Microsoft SQL Server и виртуальных машин Hyper-V.

Файловые службы в отказоустойчивом кластере

Прежде чем перейти к рассмотрению новых возможностей, стоит дать краткое описание принципов работы файловых служб в отказоустойчивом кластере, обеспечивающем высокий уровень доступности файловых серверов и, в частности, файловых ресурсов общего доступа. Отказоустойчивый кластер Server 2012 может состоять из 64 серверов (в Windows Server 2008 R2 число серверов не превышало 16) с установленным компонентом Failover Clustering, настроенных на совместный доступ к общему набору хранилищ и служб.

Службы, определенные в кластере, можно перемещать между серверами (или узлами) кластера. Они состоят из различных ресурсов, в том числе IP-адреса, имени сети, хранилища и собственно службы, например файлового сервера, сервера печати, виртуальных машин, сервера почтовых ящиков Microsoft Exchange Server и т.д. Службы можно перемещать между узлами в кластере по расписанию или при неожиданных происшествиях, таких как отказ сервера. В последнем случае службы, работающие на отказавшем сервере, автоматически перераспределяются между остальными узлами кластера.

На рисунке 1 показаны кластер с четырьмя узлами и общий ресурс файлового сервера. Файловый сервер предоставляет единственный файловый ресурс, содержимое которого хранится в LUN в формате NTFS. LUN — это блок пространства из общего хранилища, с которым могут устанавливать связь все узлы кластера. Файловый сервер, а, следовательно, и файловый ресурс общего доступа, первоначально подключается к сети с третьего узла кластера. Этот узел также подключает LUN, содержащий контент файлового сервера. При отказе файловый сервер перемещается на четвертый узел, который тоже подключает LUN, необходимый для предоставления общего контента. LUN должен быть подключен любым узлом, предоставляющим файловый сервер, соответствующий контенту, так как NTFS — файловая система, к которой не могут одновременно обращаться несколько узлов. Поэтому если файловый сервер перемещается на другой узел, то LUN также необходимо переместить между узлами. В каждый момент времени файловый сервер подключается к сети только одним узлом.

Рисунок 1. Простой отказоустойчивый кластер со службой, перемещаемой между узлами

SMB Transparent Failover

В предыдущем примере показаны проблемы, возникающие при использовании файлового ресурса общего доступа, перемещенного между узлами кластера в плановом и неплановом сценариях. Прежде всего, если файл в файловом ресурсе общего доступа используется приложением, то, как правило, формируются дескрипторы, обеспечивающие доступ приложения к файлу и, возможно, блокирующие файл, чтобы помешать другому приложению произвести операцию записи. Кроме того, дескриптор определяет способ доступа к данным и, в частности, возможность буферизовать данные на файловом сервере, что способствует увеличению производительности. В Server 2008 R2 и предыдущих версиях любые дескрипторы и блокировки терялись при перемещении файлового сервера на другой узел. Как правило, эта особенность не доставляет хлопот пользователям, работающим с документами Microsoft Word. Но совсем другое дело, если это база данных, используемая SQL Server.

Вторая проблема связана со временем, необходимым клиенту файлового сервера, чтобы определить факт недоступности файлового сервера и начать принимать меры для восстановления работоспособности. Если ориентироваться на тайм-аут TCP/IP, то обычно возникают перерывы длительностью около 40 секунд, что неприемлемо для серверного приложения, сохраняющего данные в файловых ресурсах общего доступа. На эти 40 секунд приостанавливаются все действия, требующие обмена файлами с общим ресурсом (это явление известно как brownout). Для успешной работы SMB необходимо устранить эти препятствия. Для серверных приложений, таких как SQL Server и Hyper-V, работающих с файловыми ресурсами общего доступа, неприемлема потеря дескрипторов данных и 40-секундные паузы при вводе-выводе.

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

Повышение доступности общих файловых ресурсов. В SMB Transparent Failover соединено несколько изменений конфигурации и новых технологий. Одно из преимуществ, традиционно предоставляемых клиентам файловых серверов — буферизация операций записи данных на диск. Этот элемент ускоряет подтверждение запросов записи клиентов, так как файловый сервер кэширует операцию записи в энергозависимой памяти (в результате данные теряются при отключении электропитания сервера) и сообщает клиентам, что данные записаны. Клиенты могут продолжать работу, а сервер выполняет запись оптимальным способом. Некоторые приложения всегда открывают дескрипторы с отключенным кэшированием, используя атрибут FILE_FLAG_WRITE_THROUGH при создании дескриптора. Таким образом, данные всегда записываются на диск перед получением подтверждения и минуют энергозависимый кэш. По умолчанию SMB Transparent Failover активирует режим FILE_FLAG_WRITE_THROUGH для всех созданных дескрипторов, исключая обращения к кэшу в энергозависимой памяти. Из-за отказа от кэша может снизиться производительность, но небольшое снижение быстродействия — приемлемая цена за гарантированную целостность данных.

Второе изменение, связанное с SMB Transparent Failover, — способ управления дескрипторами файлов со стороны операционной системы. Дескрипторы файлов обычно хранятся в памяти файлового сервера. Однако если узел вышел из строя и файловый сервер перемещается на другой узел кластера, дескрипторы будут потеряны — неприятная перспектива для пользователей приложений. Наряду с сохранением состояния дескриптора в памяти, SMB Transparent Failover архивирует состояние дескриптора в базе данных Resume Key Database, в папке System Volume Information диска, на котором расположен файл и на который ссылается дескриптор. Благодаря хранению информации дескриптора на диске удается поддержать состояние дескриптора при перемещении файлового сервера между узлами кластера. Но доступ к диску происходит в несколько раз медленнее, чем к памяти, поэтому рабочие нагрузки с большим количеством метаданных, такие как создание, удаление, переименование, расширение, открытие и закрытие файлов, связаны с дополнительными операциями ввода-вывода в базе данных Resume Key Database. В результате уменьшается доступность ресурсов ввода-вывода при обычной работе с дисками. Но и в этом случае компромисс приемлем, чтобы гарантировать сохранность дескрипторов при перемещении файловых серверов между узлами. Аргументы в пользу компромисса можно найти во врезке «Фактор производительности».

Минимизация остановок в работе (brownout). Чтобы преодолеть второе препятствие и сократить время, необходимое клиенту SMB для обнаружения отказа TCP-соединения, действия кластера должны быть опережающими. Кластер должен оповестить клиентов SMB, которые подключаются к файловому ресурсу общего доступа всякий раз, когда файловый хост-сервер перемещается на другой узел. В результате можно быстро выполнить повторное подключение клиента. Новая функция SMB Witness действует приблизительно следующим образом.

Клиент SMB: «Я хочу подключиться к этому файловому ресурсу общего доступа на ServerA.»

SMB ServerA: «Oк, подключение установлено. Этот файловый ресурс общего доступа размещен на кластере; сообщите своему процессу SMB Witness».

SMB Witness клиента: «Превосходно! Дайте информацию обо всех узлах в кластере».

SMB ServerA: «Вот список всех узлов в кластере: ServerA, ServerB, ServerC. ..»

SMB Witness клиента: «Привет, ServerB. Я подключаюсь к данному файловому ресурсу общего доступа с использованием данного IP-адреса на ServerA. Я хочу зарегистрироваться у вас, чтобы получить сообщение в случае сбоя ServerA или перемещения файлового сервера».

SMB ServerB: «Хорошо. Дам знать».

Если после таких переговоров с этим файловым сервером в кластере что-то случится, клиент SMB быстро получит извещение через процесс SMB Witness и сможет подключиться заново гораздо быстрее, чем при использовании тайм-аута TCP/IP. Вероятное время обнаружения и реагирования на сбой или перемещение файлового сервера — от 5 до 7 секунд вместо 40.

Чтобы включить SMB Transparent Failover, не нужно предпринимать никаких действий. При использовании Failover Cluster Manager, Server Manager или Windows PowerShell для создания файлового ресурса общего доступа на файловом сервере в кластере в среде Server 2012, SMB Transparent Failover на общем ресурсе включается по умолчанию. Обратите внимание, что этого не происходит при создании общего ресурса с использованием Explorer или команды Net Share; оба способа несовместимы с SMB Transparent Failover. Клиенты Windows 8 и Server 2012, совместимые с SMB 3.0, задействуют возможности SMB Witness и откроют сеансы для использования дескрипторов сквозной записи (на диск).

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

PS C:\> get-smbwitnessclient | select clientname, fileservernodename, witnessnodename
clientname fileservernodename witnessnodename
— ------------------ ---------------
savdalwks08 WIN8FC01 WIN8FC02

Как видно, вывод показывает имя клиентского компьютера (savdalwks08), файлового сервера, к которому подключен клиент (Win8FC01), и узла, на котором он зарегистрирован для оповещений (свидетель, Win8FC02). Другой вариант — применить команду PowerShell Get-SmbOpenFile и взглянуть на свойство ContinuouslyAvailable.

Чтобы просмотреть список всех созданных администратором общих ресурсов и определить, настроены ли они на непрерывную доступность, используйте следующий программный код PowerShell:

PS C:\> Get-SmbShare | Where {$_.Scoped -eq «true» -and $_.Special -ne «True»} | Sort ClusterType | Format-Table Name, ScopeName, ClusterType, ContinuouslyAvailable, Path
Name ScopeName ClusterType ContinuouslyAvailable Path
— --------- — --------------------- ----
NonCSVData WIN8FSTRAD Traditional True E:\Shares\NonCSVData
DataCSV WIN8FSSCOUT ScaleOut True C:\ClusterStorage\Vo...
SMB Scale-Out

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

Рассмотрим компанию, которой нужно сделать общедоступным один том NTFS и при этом требуется обеспечить высокую доступность общего ресурса. В этом случае в кластере должно быть по крайней мере два узла, но только один узел действительно предоставляет общий ресурс. Чтобы избежать ситуации активный/пассивный, в которой один узел бездействует, администраторы хранилища делят LUN на два, создают два тома NTFS (один на каждом LUN), а затем создают два файловых сервера в кластере, каждый с собственным общим ресурсом. Благодаря такой организации каждый узел предоставляет один общий ресурс и размещает общий ресурс другого узла во время отказа. В итоге оба узла работают, но хранилище поделено таким способом, который не всегда удобен для компании. Кроме того, если разделить контент неправильно, трафик на одном из ресурсов будет больше, чем на другом, что может привести к дисбалансу и необходимости переместить данные. Такова ситуация с двумя узлами. Теперь представьте, что у вас четыре узла, как показано на рисунке 2, или восемь узлов; просто чтобы задействовать все узлы кластера, потребуется множество отдельных LUN, томов NTFS и общих ресурсов.

Рисунок 2. Необходимый компромисс с традиционными файловыми серверами в кластере

Причина в том, что тома NTFS не подлежат общему доступу и не могут использоваться несколькими узлами одновременно. Проблема была частично решена в Server 2008 R2 с появлением общих томов кластера (CSV). В сущности, CSV позволяет выполнять чтение и запись на один LUN формата NTFS одновременно из всех узлов кластера через хитроумный механизм. Общие тома кластера в Server 2008 R2 предназначались только для хранения виртуальных машин Hyper-V, функционирующих на узлах Hyper-V в кластере, содержащем общие тома кластера.

В Server 2012 использование CSV распространено на новый тип файлового сервера в кластере, а именно SMB Scale-Out. Тип файлового сервера — Scale-Out или традиционный (то есть существующая модель файлового сервера) выбирается при его создании. Создавая новый файловый сервер типа Scale-Out, необходимо создать общие ресурсы в папках на томах CSV. В Server 2012 тип файловой системы CSV-совместимых томов NTFS объявлен как CSVFS вместо NTFS. В действительности файловая система по-прежнему NTFS, но благодаря изменению обозначения проще отличить тома на CSV-совместимых дисках (то есть CSVFS) от несовместимых (то есть NTFS). Помните, что CSV доступен всем узлам кластера одновременно, поэтому созданный общий ресурс может быть предоставлен всем узлам кластера, и все узлы могут обращаться к контенту. При создании файлового сервера Scale-Out IP-адрес указывать не нужно. Используются IP-адреса для интерфейсов, настроенные для клиентского доступа на узлах кластера; все узлы обеспечивают обслуживание.

Другая возможность — использовать SMB Transparent Failover для перемещения клиентов с одного узла, который предоставляет файловый сервер Scale-Out, на другой, без перерыва в доступе. Например, требуется перевести узел в режим обслуживания. Следующая команда перемещает определенный SMB-клиент с одного узла на другой; эту команду можно без труда выполнить с помощью PowerShell для всех клиентов, использующих определенный узел в кластере.

Прежде всего, я определил, какой сервер используется SMB-клиентом (мы уже применяли эту команду ранее):

PS C:\> get-smbwitnessclient | select clientname, fileservernodename, witnessnodename
clientname fileservernodename witnessnodename
— ------------------ ---------------
savdalwks08 WIN8FC01 WIN8FC02

Теперь этот клиент перемещается на другой сервер:

PS C:\> Move-SmbWitnessClient -ClientName savdalwks08 -DestinationNode Win8FC02

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

PS C:\> get-smbwitnessclient | select clientname, fileservernodename, witnessnodename
clientname fileservernodename witnessnodename
— ------------------ ---------------
savdalwks08 WIN8FC02 WIN8FC01

Что означает этот результат? Взгляните вновь на рисунок 2. Теперь можно создать единственный крупный LUN, который и был нужен, с одним томом NTFS, совместно используемым всеми четырьмя узлами. Компания Microsoft поддерживает до восьми узлов, предоставляющих один файловый сервер SMB Scale-Out. Таким образом, упрощается управление, устраняется необходимость связывать многочисленные отдельные LUN, общие ресурсы и IP-адреса с каждым файловым сервером. Так почему же по-прежнему существуют файловые серверы традиционного типа? Зачем они нужны?

Как отмечалось выше, CSV выполняет сложные действия, чтобы обеспечить возможность вести запись и чтение на одном томе NTFS со всех узлов кластера одновременно. Один из самых удачных приемов — запись метаданных на тома NTFS, что является самой большой проблемой при использовании одного тома NTFS одновременно несколькими компьютерами. Попытка записи метаданных двумя серверами сразу, скорее всего, приведет к порче данных. При использовании CSV эта проблема решается благодаря наличию узла координатора для каждого диска CSV. Этот узел подключает диск локально и выполняет все действия с метаданными от имени других узлов кластера, которые посылают команды записи метаданных через сеть кластера координатору. Другие узлы могут напрямую обращаться к диску для обычных операций ввода-вывода данных. Такое перенаправление метаданных по сети может вызвать задержки в операциях. Поэтому файловый сервер SMB Scale-Out предназначается для важных рабочих нагрузок сервера приложений, таких как SQL Server и Hyper-V, которые ориентированы на ввод-вывод данных и выполняют очень немного действий с метаданными. Если сравнить характеристики ввода-вывода серверного приложения с потребностями типичного сотрудника, использующего документы Microsoft Office, то выяснится, что его действия на 60-70 % состоят из операций с метаданными. Они связаны с перенаправлением очень большого количества данных. Это не значит, что в такой ситуации файловый сервер SMB Scale-Out неприменим или будет функционировать плохо (при правильных архитектурных решениях), но эти обстоятельства определенно нужно учитывать. В настоящее время файловый сервер Scale-Out рекомендуется только для серверных приложений, таких как SQL Server и Hyper-V.

Существует еще одна причина, по которой файловый сервер Scale-Out малопригоден для хранения документов Office и других пользовательских данных. Платформа файлового сервера Windows широко используется благодаря таким возможностям, как квоты, блокировка файлов, классификация файлов, BranchCache и дедупликация данных (в Server 2012). Ни одной из этих функций нет в файловом сервере Scale-Out, но серверным приложениям они не нужны.

Объединяя файловый сервер Scale-Out с функцией SMB Transparent Failover (реализованной для традиционных и SMB Scale-Out файловых серверов), вы получаете платформу файловых служб, на которой несколько серверов обращаются к одному общему ресурсу. В результате достигается очень высокая масштабируемость для клиентов и недоступная ранее гибкость. Технология Scale-Out ориентирована в основном на рабочие нагрузки SQL Server и Hyper-V, но со временем будут протестированы и рекомендованы и другие типы рабочих нагрузок, а у потребителей появится много новых вариантов хранения данных и ИТ-архитектур.