Хранение данных серверных приложений в общих файловых ресурсах

Каждый раз, когда я работаю с хранилищем данных Windows Server "8", я расплываюсь в широкой улыбке, когда думаю о том, как много смогут сделать наши клиенты с помощью функций, создание которых являет собой превосходную инженерную работу. Вне зависимости от того, используете ли вы блочную сеть хранения данных (SAN) или файловое решение, мы в равной степени уделяем свое пристальное внимание на оба этих типа организации хранилища данных. В этом блоге мы хотим сосредоточиться на наших усилиях в разработке файлового хранилища. Наших команды разработчиков вместе работали над внесением новшеств по всему стеку хранения данных. От способа очистки данных до функции Storage Spaces, Resilient File System (ReFS) и усовершенствований в протоколе Server Message Block (SMB) и технологии Cluster Shared Volume (CSV), поддержке устройств хранения с технологией SMI-S - Windows Server "8" коренным образом изменяет наше понимание архитектуры хранения данных и решений для файловых хранилищ. В конечном итоге, Windows Server "8" минимизирует затраты на обслуживание хранилищ данных, причем в некоторых случаях, весьма существенно. Если вы используете системы хранения данных, вы должны остановиться, выделить время на изучение хранилища данных Windows Server "8" и переосмыслить то, что вы будете делать дальше.

В этой статье мы рассмотрим новый сценарий использования Windows Server "8": хранилище серверных приложений в общих файловых ресурсах. Все это началось одного простого вопроса: "Почему серверные приложения не могут использовать преимущества наших файловых серверов?". После этого программные менеджеры, разработчики и тестеры закатали рукава, разбили проблему на части и создали исчерпывающий набор функций, чтобы сделать это возможным. Вы можете загрузить бета-версию и лично в этом убедиться.

Авторами данной статьи выступили Клаус Йоргенсен (Claus Joergensen) и Хосе Баррето (Jose Barreto), ведущие программные менеджеры нашей команды File Server.


Изначально файловый сервер 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 продолжает непрерывно использовать сеть, но уже с меньше пропускной способностью. Лучше всего то, что это было достигнуто без необходимости исполнения дополнительных шагов во время настройки. Вам просто нужно настроить несколько сетевых интерфейсов, как это обычно и делается.
  
• SMB Direct: одно из основных преимуществ блочного хранилища данных 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.
  
• Наборы команды Windows PowerShell для работы с SMB: создание управляемых общих файловых ресурсов теперь возможно благодаря использованию либо нового графического интерфейса Windows Server Manager, поддерживающего кластерные файловые серверы и содержащего несколько профилей для создания общих файловых ресурсов 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 и сетевыми коммутаторами, это решение может использоваться для создания стоечного блока для решения частного облака. Оно является эквивалентом массива блочных хранилищ данных с двумя контроллерами.
  
  Третий вариант, с большим числом файловых серверов, использующих Fibre Channel в качестве общего хранилища, доступен для больших конфигураций. Этот кластерный файловый сервер может использовать функции масштабирования SMB и SMB Direct для создания инфраструктуры общедоступных хранилищ, обслуживающих десятки, если не сотни, узлов Hyper-V. В этом случае есть существенная экономия каналов Fiber Channel до узлов файлового сервера при использовании 10GbE или InfiniBand для подключения компьютерных узлов Hyper-V к файловым серверам.

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

Если вы хотите узнать больше по этой теме, у нас есть серия презентаций, проведенных во время конференции Build в сентябре 2011 года. Эти презентации доступны здесь и содержат несколько часов видео. Мы рекомендуем их вам для просмотра.

Клаус Йоргенсен (Claus Joergensen) и Хосе Баррето (Jose Barreto),
ведущие программные менеджеры команды Windows File Server


Источник: http://blogs.technet.com/windowsserver
Перевод: Dazila