Хранение данных серверных приложений в общих файловых ресурсах
Каждый раз, работая с хранилищем данных Windows Server «8», я расплываюсь в улыбке, когда думаю, как много смогут сделать наши клиенты с помощью этих функций и о превосходном инжиниринге, реализовавшим их. Вне зависимости от того, используете ли вы блочную сеть хранения данных ( SAN ) или файловое решение, мы в равной степени уделяем пристальное внимание обоим типам организации хранилища данных. В этом блоге мы хотим сосредоточиться на усилиях по разработке файлового хранилища. Наши команды разработчиков вместе трудились над внесением новшеств по всему стеку хранения данных. WindowsServer «8» коренным образом изменяет наше понимание архитектуры хранения данных и решений для файловых хранилищ во всех областях: от способа сброса данных до технологий StorageSpaces** , ResilientFileSystem ( ReFS ) и усовершенствований в протоколе ServerMessageBlock ( SMB ), технологии ClusterSharedVolume ( CSV ) и поддержке устройств хранения с технологией SMI - S . В конечном итоге, WindowsServer «8» минимизирует затраты на обслуживание хранилищ данных, причем в некоторых случаях, весьма существенно. Если вы используете системы хранения данных, вы должны остановиться, выделить время на изучение хранилища данных WindowsServer «8» и переосмыслить то, что вы собираетесь делать дальше.
В этой статье мы рассмотрим новый сценарий использования WindowsServer «8»: хранилище серверных приложений на общих файловых ресурсах. Все это началось с одного простого вопроса: «Почему серверные приложения не могут использовать преимущества наших файловых серверов? » После этого программные менеджеры, разработчики и тестеры закатали рукава, разбили проблему на части и создали исчерпывающий набор функций, чтобы сделать это возможным. Вы можете загрузить бета-версию WindowsServer «8» и лично убедиться в этом.
Авторами данной статьи выступили Клаус Йоргенсен ( ClausJoergensen ) и Хосе Баррето ( JoseBarreto ), ведущие программные менеджеры команды FileServer .
История вопроса
Изначально файловый сервер Windows в основном использовался для хранения данных конечных пользователей. Типичные сценарии применения – общий файловый ресурс для дома и сетевое хранилище для совместного использования на работе. Файловый сервер Windows Server «8» представляет поддержку для серверных приложений, таких как Hyper-V и SQL Server, которые могут хранить рабочие данные на общих файловых ресурсах Windows. Например, пользователь может настроить виртуальную машину Hyper-V, чтобы ее конфигурационный файл, файлы VHD и файлы резервных копий (снимки) хранились на общем файловом ресурсе Windows. На следующем снимке экрана показана виртуальная машина, настроенная так, чтобы ее файл VHD располагался в сетевой папке Windows, с указанием пути Universal Naming Convention (UNC):
Создавая новые сценарии
Во время процесса планирования Windows Server «8» наши клиенты проявили особый интерес к возможности сохранения данных серверных приложений на общих файловых ресурсах Windows. Для многих клиентов из малого и среднего бизнеса это была возможная альтернатива инфраструктуре SAN, поскольку в этом случае они могли усилить новым функционалом инфраструктуру Ethernet и использовать стандартные серверы. Кроме того, когда созданы общие файловые ресурсы, клиентам будет проще ими управлять, поскольку им не надо будет реализовывать LUN или настраивать зоны. В дополнение к тому, что это более простая в реализации и управлении альтернатива SAN, новая возможность хранить данные серверных приложений позволяет крупных клиентам и хостерам получать больше гибкости при перемещении рабочих сред по датацентру без перенастройки хранилища данных. Если на данные указывает UNC-путь, доступ к ним с правильными административными правами можно получить из любой точки вычислительного центра.
Благодаря поддержке этого нового сценария, все клиенты получают дополнительный вариант файлового хранилища и могут выбирать между Fibre Channel, iSCSI SAN, общедоступными дисковыми массивами SAS или общими файловыми ресурсами, в зависимости от собственных предпочтений, бюджетов и требуемого функционала.
Расположение серверных хранилищ приложений в файловых ресурсах
Для того чтобы серверные приложения могли хранить свои рабочие данные на общих файловых ресурсах, есть два требования. Во-первых, серверная роль или приложение должны поддерживать эту функцию. Эта поддержка включает в себя обновление приложения для поддержки пути UNC (\\server\share\file.vhd) в его средствах установки и управления, а также полное тестирование приложения для использования в таком сценарии. В SQL Server 2008 R2 – это поддержка хранения пользовательских баз данных SQL в общем файловом ресурсе SMB. SQL Server 2012 добавляет поддержку системной базы данных SQL, а также настройку SQL Server как кластера. Как было показано на конференции BUILD, Windows Server «8» также добавляет поддержку хранения файлов виртуальных машин на общих файловых ресурсах SMB.
Во-вторых, файловый сервер сам по себе должен поддерживать возможность хранения данных серверными приложениями на общих файловых ресурсах. Во время исследования запросов клиентов к Windows Server «8» мы обнаружили следующие основные требования к поддержке файловым сервером функции хранения серверных приложений:
· Непрерывная доступность. Серверные приложения ожидают, что хранилище данных будет доступно всегда и не будет подвержено ошибкам ввода/вывода или непредвиденным закрытиям обработчиков файлов. Эти типы событий могут привести к сбою работы виртуальных машин, так как они не смогут записывать данные на диск или же использовать базу данных в оффлайн-режиме. Клиенты обычно развертывают аппаратное обеспечение с избыточностью, что выражается в использовании нескольких сетевых адаптеров, сетевых коммутаторов, и кластерных конфигураций Windows, чтобы смягчить последствия отключения аппаратных средств. Хотя подобные конфигурации позволяют файловому серверу быстро восстанавливаться после сбоя, это восстановление непрозрачно для приложения, виртуальные машины в таком случае должны быть перезапущены, а база данных снова выложена в онлайн. Решение файлового сервера на Windows Server «8» должно быть в состоянии быстро и прозрачно восстанавливаться после сбоев сети или узла, без простоя или необходимости вмешательства администратора.
· Производительность. Некоторые серверные роли, такие как Hyper-V и SQL Server, очень чувствительны к производительности хранилища данных, включая пропускную способность, задержку и количество операций ввода/вывода в секунду (IOPS). Также важно гарантировать, чтобы потребление ресурсов ЦП при доступе к хранилищу оставалось на минимальном уровне, отдавая максимум процессорного времени приложению. И наконец, серверные приложения часто используют способ доступа к данным, который сильно отличается от такового у пользовательских приложений. Там, где пользовательские приложения предпочитают считывать или записывать файл полностью, серверные приложения добавляют или обновляют существующие данные. Решение файлового сервера на Windows Server «8» должно предоставлять пропускную способность хранилища данных для серверных приложений, сравнимую с таковой у нескольких сетевых адаптеров 10Gbps Ethernet или адаптеров Infiniband и задержкой, значением IOPS и потреблением ресурсов ЦП, сравнимом с уровнем Fibre Channel.
· Масштабируемость. Конфигурации для кластера файлового сервера Windows часто развертываются по схемам вида «активный-пассивный», при которых, как минимум, один узел остается неиспользуемым. В качестве альтернативного решения можно привести конфигурацию с несколькими экземплярами файловых серверов в кластере. Она позволяет использовать всё аппаратное обеспечение кластера. Однако такая конфигурация требует дополнительного администрирования, и пропускная способность, доступная для организации общего доступа, по-прежнему ограничена пропускной способностью, доступной на узле, где на текущий момент находится файловый ресурс. Файловый сервер Windows Server «8» должен поддерживать конфигурации типа «активный-активный», при которых общий файловый ресурс может быть доступен с любого узла, увеличивая при этом максимальную пропускную способность до нескольких узлов кластера и упрощая администрирование.
· Защита данных. Другая ключевая возможность – создание связанных с приложением теневых копий данных для их резервирования. В Windows это обычно достигается за счет использования инфраструктуры Volume Shadow Copy Service (VSS). VSS, в ее текущем виде, поддерживает только локальные хранилища. Решение файлового сервера Windows Server «8» должно поддерживать связанные с приложением теневые копии посредством полной интеграции с VSS и минимальным влиянием на текущих клиентов, редакторов и провайдеров VSS.
Как можно видеть, это довольно большой список требований. Однако мы согласились, что для предоставления надежного, доступного и пригодного к эксплуатации файлового сервера с превосходной производительностью для хранилища данных серверных приложений мы должны удовлетворить всем этим требованиям.
Обзор функций
Поддержка возможности организации хранилища данных серверных приложений на файловом сервере в Windows Server «8» стало важным решением для команды разработчиков продукта. Несколько функций было представлено специально для того, чтобы гарантировать, что файловое хранилище может удовлетворить и превзойти требования, зачастую предъявляемые к блоковому хранилищу, не теряя при этом такие преимущества файлового хранилища, как простоту в управлении и экономическую эффективность. Это решение также потребовало разработки новой версии протокола SMB, который является основным протоколом Windows для работы с удаленным файлами. Новые функции включают в себя:
· Прозрачную отработку отказа SMB . Она позволяет администраторам выполнять обслуживание аппаратного или программного обеспечения узлов кластерного файлового сервера без прерывания процесса сохранения данных серверными приложениями на общих файловых ресурсах. Кроме того, если аппаратная или программная ошибка происходит на узле кластера, это функция позволяет клиентам SMB прозрачно переподключиться к другому узлу кластера без прерывания серверных приложений, которые хранят данные на общих файловых ресурсах. Это достигается независимо от типа операции, которая выполняется при возникновении ошибки. Для блочного хранилища это эквивалентно использованию дискового массива с несколькими контроллерами.
· Многоканальность SMB . Она позволяет одновременно использовать несколько соединений и сетевых интерфейсов с двумя главными преимуществами – увеличенная пропускная способность и отказоустойчивость . Например, если у вас есть по четыре интерфейса 10GbE на клиенте и сервере SMB, вы можете одновременно использовать их для достижения пропускной способности в 40 Гбит/с через четыре 10-гигабитных сетевых адаптера. Когда один из сетевых адаптеров или кабелей выходит из строя, ваш клиент SMB продолжает непрерывно использовать сеть, но уже с меньшей пропускной способностью. Интересно то, что это было достигнуто без дополнительных шагов во время настройки. Вам просто нужно настроить несколько сетевых интерфейсов, как это обычно и делается.
· SMBDirect . Одно из основных преимуществ блочного хранилища данных Fibre Channel – это возможность иметь низкие задержки и быструю передачу данных. Чтобы соответствовать этому в мире файловых серверов, SMB представляет поддержку сетевых адаптеров, имеющих функцию RDMA и способных функционировать на полной скорости с очень низкими задержками, использую при этом очень мало ресурсов ЦП. Применяя одну из трех технологий RDMA (Infiniband, iWARP или RoCE), клиент SMB обеспечивает малую загрузку ЦП, сравнимую с загрузкой при использовании Fibre Channel, и сохраняет процессорное время для основных рабочих задач, таких как Hyper-V или SQL Server. Плюс то, что такие сетевые интерфейсы обнаруживаются системой и функционируют без дополнительных шагов во время настройки SMB. Если RDMA-интерфейсы доступны, они будут использованы автоматически.
· Масштабирование SMB . Используя преимущества второй версии технологии Cluster Shared Volume (CSV), администраторы могут создавать общие файловые ресурсы, которые предоставляют одновременный доступ к файлам данных с прямым вводом/выводом на любом узле кластера файлового сервера. Это означает, что максимальная обслуживающая способность файла для данного общего файлового ресурса теперь ограничена не производительностью одного узла кластера, а совокупной пропускной способностью всего кластера. Кроме того, такая конфигурация вида «активный-активный» позволяет балансировать нагрузку между узлами кластера, перемещая клиентов файлового сервера без прерывания в предоставлении сервиса. И наконец, функция масштабирования SMB упрощает управление кластерными файловыми серверами и общими файловыми ресурсами.
· VSS для общих файловых ресурсов SMB . Возможность создавать связанные с приложениями снимки данных серверных приложений очень важна для резервного копирования. В Windows это достигается с помощью инфраструктуры Volume Shadow Copy Service (VSS). VSS для общих файловых ресурсов SMB расширяет инфраструктуру VSS для создания связанных с приложениями теневых копий данных, хранимых на удаленных файловых ресурсах SMB для резервирования и восстановления. Кроме того, VSS для общих файловых ресурсов SMB позволяет приложениям резервного копирования считывать зарезервированные данные напрямую из общих файловых ресурсов для теневых копий вместо того, чтобы вовлекать компьютер с серверным приложением в процесс передачи данных. Поскольку эта функция улучшает существующую инфраструктуру VSS, ее легко интегрировать в существующее резервирующее программное обеспечение, использующие VSS, и приложения, такие как Hyper-V.
· Наборы команд WindowsPowerShell для работы с SMB . Создание управляемых общих файловых ресурсов теперь возможно благодаря использованию либо нового графического интерфейса WindowsServerManager, поддерживающего кластерные файловые серверы и содержащего несколько профилей для создания общих файловых ресурсов SMB, либо новых наборов команд Windows PowerShell для SMB, которые используют знакомую инфраструктуру Windows PowerShell для командной строки и написания скриптов. Это полностью новый набор командлетов Windows PowerShell третьей версии создавался для управления общими файловыми ресурсами, правами доступа к этим ресурсам, отображением клиентов, конфигурацией сервера и клиента. Здесь есть также расширенный набор командлетов для мониторинга сессий, открытия файлов, установления соединений сетевых интерфейсов и многоканальных соединений. Эти наборы команд созданы на основе стандартных протоколов управления с использованием классов WMIv2, которые позволяют разработчикам на Windows и Linux создавать автоматизированные решения для конфигурирования и мониторинга файловых серверов.
· Счетчики производительности SMB . В мире серверов приложений производительность хранилища данных является главным критерием их оценки. Помня об этом, Windows Server «8» включает в себя счетчики производительности сервера и клиента, которые позволяют администраторам легко видеть ключевые показатели файлового хранилища, включая IOPS, задержки, длину очереди и пропускную способность. Эти счетчики соответствуют уже знакомым счетчикам производительности блочных хранилищ, позволяя легко улучшать возможности в управлении производительностью хранилищ данных для Windows Server.
· Производительность. Производительность также является ключевой характеристикой для SMB. В дополнение к увеличению максимального размера блока (MTU), используемого по умолчанию, большой объем работы был проделан над оптимизацией производительности для различных видов рабочих нагрузок, использующих операции с вводов/выводом как больших, так и малых объемов данных, с последовательным или случайным доступом. Эти оптимизации были разработаны посредством изучения типичных рабочих нагрузок, таких как обработка транзакций в реальном времени, долговременного хранения (data warehousing), виртуальных веб-серверов в частном облаке, инфраструктуры виртуальных рабочих столов и объединенных домашних папок. Эти исследования привели к внесению усовершенствований во многих областях операционной системы.
Давайте поближе посмотрим на прозрачную отработку отказа SMB. Эта функция требует следующего:
• Отработка отказа кластера выполняется Windows Server «8» при наличии, как минимум, двух узлов кластера и настроенной роли файлового сервера.
• Кластер должен пройти тест проверки в мастере «Validate a Configuration Wizard».
• Общих файловых ресурсов, созданных со свойством непрерывной доступности, которая является параметром, заданным по умолчанию для кластерных общих файловых ресурсов.
• Компьютеры, получающие доступ к кластерным общим файловым ресурсам, должны работать под управлением Windows 8 Consumer Preview или Windows Server «8».
Когда клиент SMB впервые подключается к общему файловому ресурсу, клиент определяет, установлено ли для него свойство непрерывной доступности. Если это так, то это означает, что данный общий файловый ресурс является кластерным и поддерживает прозрачную отработку отказов SMB. Когда клиент SMB впоследствии открывает файл на этом файловом ресурсе от имени приложения, он запрашивает постоянный файловый дескриптор. Когда SMB-сервер получает запрос на открытие файла с помощью постоянного дескриптора, SMB-сервер использует фильтр Resume Key, чтобы сохранить необходимую информацию о дескрипторе файла вместе с уникальным ключом (ключом возобновления), предоставляемым клиентом SMB, для обеспечения стабильности хранилища. Клиент SMB использует ключ возобновления для обращения к дескриптору во время операция восстановления после сбоя. Чтобы предотвратить потерю данных при их записи в нестабильный кэш, устойчивые дескрипторы файлов всегда открыты на запись.
Если отказ происходит на узле кластерного файлового сервера, к которому подключен клиент SMB, этот клиент пытается повторно подключиться к другому узлу сервера. Как только клиент SMB успешно переподключится к другому узлу в кластере, это клиент запускает возобновление операции с помощью ключа возобновления. Когда сервер SMB получает ключ возобновления, он обращается к фильтру Resume Key для восстановления дескриптора в то самое состояние, в котором он был до сбоя с полной поддержкой (клиент SMB, сервер SMB и фильтр Resume Key) операций, которые могут быть повторены, а также операций, которые повторить нельзя. Приложение, выполняющееся на компьютере с клиентом SMB, не испытывает никаких сбоев или ошибок во время этой операции. С точки зрения приложения это выглядит как остановка операции ввода/вывода на небольшой промежуток времени.
Очень важно сохранить количество остановов операций ввода/вывода во время отработки отказа на минимальном уровне. Так как SMB работает поверх TCP/IP, клиент SMB обычно полагается на значение тайм-аута TCP, чтобы определить возникновение сбоя узла кластерного файлового сервера. Однако использование тайм-аутов TCP может привести к возникновению очень длительных ожиданий операций ввода/вывода, так как каждый тайм-аут обычно составляет около 20 секунд. Функция SMB Witness была создана для быстрого восстановления после внеплановых сбоев, позволяя клиенту SMB не ждать окончания тайм-аута TCP. SMB Witness – это новая служба, которая устанавливается автоматически с функцией отказоустойчивой кластеризации. Когда клиент SMB первый раз подключает к узлу кластерного файлового сервера, он уведомляет об этом клиент SMB Witness, который запущен на том же самом компьютере. Клиент SMB Witness получает список членов кластера от службы SMB Witness, запущенной на этом узле кластерного файлового сервера. Клиент SMB Witness выбирает другого члена кластера и посылает запрос регистрации к службе SMB Witness на этом узле кластера.
Если незапланированный сбой возникает на узле кластерного файлового сервера, служба SMB Witness на другом участнике кластера получает уведомление от кластерной службы. Служба SMB Witness также уведомляет клиента SMB Witness, который в свою очередь уведомляет клиента SMB о сбое узла кластерного файлового сервера. После получения уведомления от SMB Witness, клиент SMB немедленно запускает переподключение к другому узлу кластерного файлового сервера, что значительно ускоряет процесс восстановления после незапланированных сбоев.
Режимы развертывания
При планировании разработки Windows Server «8» для реализации функции файлового хранилища для серверных приложений двумя основными областями использования этой функции были Hyper-V через SMB и SQL Server через SMB.
Например, при использовании Hyper-V файловое хранилище SMB теперь полностью поддерживается как автономными, так и кластерными конфигурациями Hyper-V. Фактически теперь возможно сконфигурировать кластер Hyper-V, используя только общие файловые ресурсы в качестве общего хранилища.
Для конфигурации файлового сервера есть три основных режима развертывания:
Даже учитывая то, что одноузловой или автономный файловый сервер не является высоконадежным, он является самым недорогим решением для файлового сервера. Hyper-V получает дополнительную гибкость общих хранилищ данных и позволяет вам кластеризировать узлы Hyper-V, используя это решение (хотя полученное решение нельзя назвать высоконадежным). Если проводить аналогии с блочным хранилищем, то это решение является эквивалентом массива блочных хранилищ данных с одним контроллером.
Двухузловой файловый сервер, как ожидается, будет наиболее распространенной конфигурацией файлового сервера, обеспечивающей непрерывную доступность (через прозрачную отработку отказов SMB) по низкой цене. Используя общедоступное хранилище Serial Attached SCSI (SAS) (простой массив дисков [JBOD] или дисковый массив SAS), это решение может масштабироваться до нескольких сотен дисков. Объединенное с несколькими серверами Hyper-V и сетевыми коммутаторами, это решение может использоваться для создания стоечного блока для частного облака. Оно является эквивалентом массива блочных хранилищ данных с двумя контроллерами.
Третий вариант, с большим числом файловых серверов, использующих Fiber Channel в качестве общего хранилища, доступен для больших конфигураций. Этот кластерный файловый сервер может применять функции масштабирования SMB и SMB Direct для создания инфраструктуры общедоступных хранилищ, обслуживающих десятки, если не сотни, узлов Hyper-V. В этом случае есть существенная экономия из-за ограничения соединений Fiber Channel с узлами файлового сервера при использовании 10GbE или InfiniBand для подключения компьютерных узлов Hyper-V к файловым серверам.
Заключение
Мы безумно рады новым возможностям использования файловых серверов для серверных приложений. Мы получаем весьма позитивные отклики от первых тестеров, как внутренних, так и внешних, согласившихся проверить эти сценарии и функции. Они разделяют наш энтузиазм относительно простоты использования, управляемости, масштабируемости и производительности этого решения.
Если вы хотите узнать больше по этой теме, у нас есть серия презентаций, проведенных во время конференции Build в сентябре 2011 года. Эти презентации доступны здесь и содержат несколько часов видео. Мы рекомендуем их вам для просмотра.
Клаус Йоргенсен (Claus Joergensen) и Хосе Баррето (Jose Barreto), ведущие программные менеджеры команды Windows File Server