Одна из таких систем — Scale out File Services, сочетающая кластерную файловую систему и масштабируемые интерфейсы доступа к данным.
Tрадиционные системы сетевого хранения данных обладают рядом недостатков, главный из которых — ограничение по объемам данных, вынуждающее при достижении предела производительности или емкости базы переходить на более мощную аппаратную платформу. Очевидно, что подобное вертикальное масштабирование (scale-up) можно продолжать до тех пор, пока не будут исчерпаны возможности наиболее мощных существующих систем хранения, при этом расходы на такое масштабирование будут весьма велики.
Рассмотрим, к примеру, популярную сегодня область хранения и предоставления медиаконтента. Обычно заказчикам из этой области требуется, чтобы чтение и запись данных в систему хранения производились со скоростью не ниже 10 Гбайт/с, а доступ к одному файлу на чтение и запись мог осуществляться одновременно из множества приложений, запущенных на разных серверах вещания. Даже самые продвинутые сетевые системы хранения не справляются с такими нагрузками: их производительность ограничена пропускной способностью сетевой подсистемы и числом дисков, между которыми распределяются блоки требуемого файла.
Для обеспечения таких требований к производительности сетевое хранилище должно уметь распределять все файлы между максимально возможным числом дисков, контроллеров и узлов системы хранения, так как скорость ввода/вывода каждого отдельно взятого компонента значительно ниже требуемой (рис. 1).
Это означает увеличение объема существующей системы хранения, что не может проходить безгранично. Другой широко распространенный подход заключается в разделении файлов по различным системам хранения в зависимости от их назначения, что увеличивает сложность администрирования, добавляет новые пространства имен, и в результате ресурсы в таких системах распределяются не оптимально.
Альтернативным решением является построение кластерных систем для доступа к данным (рис. 2). В этом случае пользователю предоставляется доступ к одному виртуальному узлу, за которым скрывается кластерная система хранения. Такой подход называют горизонтальным масштабированием (scale-out), позволяющим обойти ограничения обычных систем хранения.
Решение Scale out File Services (SoFS) корпорации IBM, построенное на базе продуктов категории Open Source и собственных уникальных технологий, принадлежит к такому классу систем.
Сетевые файловые системы
Широкое распространение сетей привело к тому, что задачи предприятия стали распределяться между отделами и филиалами. Серверы приложений, базы данных и файловые серверы накапливают необходимые данные на присоединенных дисках, ленточных накопителях и в других локальных устройствах хранения. Приложения в этом случае работают со своими данными и взаимодействуют через протоколы высокого уровня.
Такой подход имеет ряд очевидных недостатков: неоптимальное расходование дискового пространства, отсутствие единой политики работы с данными, сложности администрирования и масштабирования систем хранения, разнообразие используемых систем и протоколов. Для обращения к данным, расположенным на других узлах, необходимо использовать протоколы и интерфейсы, которые предоставляет расположенное на узле приложение.
От этих проблем избавляют сетевые системы хранения и сетевые файловые системы, в которых данные размещаются в выделенном хранилище и имеют единый интерфейс доступа. Это может быть взаимодействие на канальном, или сетевом уровне (Fibre Channel или iSCSI), или же на уровне приложений (NFS или CIFS). В этом случае серверный узел предоставляет данные для всех приложений сети.
Серверный узел в таком решении становится узким местом – нагрузка и требования к надежности сервера растут вместе с объемом и ценностью данных, а развертывание нескольких сетевых серверов хранения возвращает нас к предыдущему подходу со всеми сложностями администрирования. Для преодоления этих недостатков были созданы распределенные файловые системы, данные в которых разделены между различными системами хранения, а доступ к ним осуществляется через любой из серверов хранения (см. рис. 2), которые в свою очередь объединены в отказоустойчивый кластер.
Данные могут находиться в одном месте, что значительно облегчает администрирование и масштабирование системы, тогда как нагрузка от обращения к данным распределяется между множеством узлов кластера. Яркий пример такой распределенной файловой системы – IBM General Parallel File System (GPFS).
GPFS
Файловая система GPFS разрабатывалась для больших кластерных систем, которые могут включать в себя множество дисковых массивов. При этом в рамках одной файловой системы можно комбинировать как целые дисковые массивы с RAID, так и отдельные диски кластерных узлов. Основные особенности GPFS таковы.
Кластерный характер. Файловая система предоставляет всем узлам кластера (до 1000 и более узлов) единое пространство имен и единый интерфейс управления.
Разделяемые диски. Все узлы имеют одновременный доступ на чтение и запись ко всем группам блочных устройств хранения (например, RAID-массивам, подключенным через Fibre Channel).
Параллельность. Осуществляется одновременный доступ к данным и метаданным на различных дисках с разных узлов кластера.
Благодаря одновременному параллельному доступу к дискам, подключенным к кластеру GPFS, производительность файловой системы растет пропорционально ее объему – данные «размазываются»
по всем дискам. Таким образом, блоки одного файла распространяются по всем узлам кластера, что позволяет объединить производительность всех подключенных систем хранения и достигнуть скорости передачи данных, измеряемой сотнями гигабайтов в секунду.
GPFS реализует интерфейс файловой системы, совместимый с POSIX, так что любые приложения или файловые серверы, запущенные на узлах кластера, обращаются к данным на когерентной файловой системе, аналогичной локальной файловой системе. На данный момент GPFS поддерживается в ОС Linux и IBM AIX и с ограничениями в Windows.
Особенность кластерной файловой системы GPFS состоит в том, что в ней нет выделенного сервера для метаданных. Метаданные хранятся вместе с данными на разделяемых дисках. Узлы GPFS-кластера непосредственно обращаются к метаданным, синхронизируя свою работу с помощью менеджера блокировок GPFS, который также управляет целостностью кэша, чтобы обновление данных и метаданных могло происходить одновременно на множестве узлов.
GPFS содержит ряд архитектурных решений, обеспечивающих высокую надежность и отказоустойчивость. Если в обычных системах хранения отказоустойчивость реализуется на аппаратном уровне (технология RAID, дублирование контроллеров и т.п.), то в GPFS имеется собственная репликация блоков, которая может использоваться вместо или в дополнение к RAID. Для того чтобы реагировать на отказ узла кластера, файловая система хранит журнал всех изменений метаданных на разделяемых дисках. Когда узел кластера выходит из строя, он первым делом ограждается от разделяемых дисков для предотвращения возможности некорректной записи. После этого один из оставшихся узлов обновляет данные согласно журналу, чтобы восстановить все прерванные файловые операции.
В GPFS всего три разделяемых сервиса: конфигурации, блокировок, кворума и квот, все они могут работать на любом узле кластера.
Все команды по администрированию системы (например, добавление и удаление узлов, балансировка данных с добавлением новой системы хранения и т.п.) выполняются на лету, без остановки кластера. Длительные операции, такие как повторная балансировка, могут быть запущены повторно после прерывания. То же касается и обновления программного обеспечения – GPFS позволяет устанавливать обновления без остановки работы кластера. Для управления жизненным циклом данных в GPFS используется система политик, существуют средства репликации данных и кросс-монтирования между удаленными филиалами предприятия.
SoFS
Возможности GPFS нашли применение в кластерной системе хранения данных SoFS, включающей в себя весь стек системы хранения – от аппаратуры до сервисов, обеспечивающих доступ к файлам по распространенным протоколам, таким как CIFS, NFS или FTP. Компоненты решения представлены на рис. 3.
В основе SoFS лежит параллельная файловая система GPFS. На каждом узле кластера устанавливается экземпляр операционной системы Red Hat Linux Enterprise Server, файловой системы GPFS, средства управления данными Tivoli TSM и HSM, средства администрирования, набор файловых серверов и сервисов доступа к данным. Данные располагаются в единой системе хранения, которая подключается ко всем узлам кластера через Fibre Channel или аналогичным образом.
Единое глобальное пространство имен в системе хранения SoFS достигается за счет технологий виртуализации и перенаправления данных, реализованных в GPFS-кластере. Каждый узел в кластере имеет доступ ко всем блокам данных одновременно и может заменить любой другой узел кластера в случае его неисправности. Таким образом, конечные приложения, обращаясь к файловому серверу на каком-то конкретном узле кластера, работают виртуально со всем массивом данных. Благодаря тому что GPFS обеспечивает доступ к единой файловой системе, такие простые файловые службы, как FTP и HTTP, могут предоставлять кластерный доступ к данным.
SoFS базируется на масштабируемой кластерной технологии, которая учитывает семантику используемых сетевых протоколов доступа к данным и обеспечивает минимальное время восстановления работы системы для клиентской стороны при очень большой скорости доступа. Эти технологии были разработаны корпорацией IBM, и некоторые из них доступны сейчас на условиях лицензий Open Source. Так, IBM принимает участие в проекте Samba –файлового сервера для Windows-сетей с открытым кодом, реализующего протоколы CIFS и SMB. Эта разработка, собственно, и легла в основу решения SoFS. Главная задача сервера Samba – преобразование семантики CIFS-протокола (производного от Windows API по работе с файлами) к семантике POSIX-совместимых файловых систем. Для такого корректного преобразования серверу приходится поддерживать несколько баз данных с информацией об открытых файлах, используемых ресурсах, блокировках, пользователях и т.п. Обычная версия Samba, не предназначенная для кластерных систем, использует легковесную базу данных trivial database (TDB) для хранения такой информации. База данных реализуется в виде локального файла, к которому обращаются все процессы файлового сервера, координируя свою работу.
В случае кластерной файловой системы вроде GPFS такая база данных уже не может быть реализована в виде простого файла, расположенного на разделяемом пространстве, – скорость работы базы данных (а значит, и всех файловых операций) очень низка: для кластера из двух узлов скорость падает в 10-100 раз по сравнению с одиночным узлом. Очевидно, что ни о каком масштабировании не может идти и речи. Результатом исследований участников проекта Samba и разработчиков IBM стало создание кластерного хранилища для метаданных сервера – cluster trivial database (CTDB, ctdb.samba.org). Эта система реализует распределенную базу данных, используя протокол обмена сообщениями между серверами в кластере вместо одного общего файла. Результатом этого сотрудничества стало появление кластерной версии Samba, которая запускается на всех узлах кластера SoFS и обеспечивает прозрачный доступ к данным через любой узел кластера из операционных систем семейства Windows.
Протокол NFS, в отличие от CIFS, менее требователен к сохранению состояния сервера, что лучше подходит для кластерной реализации. Семантика блокировок файлов в NFS также значительно отличается от принятой в CIFS, поэтому файловый сервер NFS подвергся лишь небольшим доработкам, чтобы обеспечить высокопроизводительный параллельный доступ к данным, поддержку списков доступа и др.
Важной особенностью SoFS является то, что CTDB используется для реализации межпротокольных блокировок. Таким образом, блокировки файлов на уровне различных протоколов и на уровне операционной системы находятся в соответствии, что гарантирует корректное состояние файлов при одновременном доступе по нескольким протоколам (CIFS, NFS, FTP или HTTP).
Жизненный цикл данных
С помощью GPFS можно объединять множество систем хранения разного класса и скорости в единую виртуальную файловую систему. Так, например, для интеграции ленточных систем хранения и прозрачной миграции данных с дисков используются продукты IBM Tivoli Storage Manager (TSM) и Tivoli Hierarchical Storage Manager (HSM). Это дает возможность комбинировать дисковые и ленточные накопители в требуемом соотношении, включая автоматическую миграцию данных.
На рис. 4 слева показан типичный набор систем NAS с применением индивидуального управления емкостью. Очевидно, что в этом случае средняя утилизация хранилищ будет достаточно низка, а время обращения к большей части данных в среднем будет превышать несколько месяцев.
С другой стороны, используя кластерную систему SoFS, можно настроить несколько уровней хранения данных разной стоимости (включая ленты) и организовать автоматическую миграцию данных между ними в зависимости от частоты обращения к данным и других параметров. Это позволяет значительно повысить степень утилизации и сократить затраты на управление данными. GPFS в связке
с продуктами Tivoli TSM и HSM позволяет настраивать такие политики автоматической миграции данных.
Репликация
Еще одна важная функциональность SoFS и GPFS – возможность репликации данных между несколькими кластерными системами хранения. В SoFS существует несколько возможностей организации доступа к данным из других развернутых кластерных систем. GPFS позволяет организовать кросс-кластерное монтирование – прозрачный доступ к разделам других кластерных систем. Такой подход возможен при достаточной пропускной способности канала связи. Альтернативным решением является синхронная репликация. В этом случае данные систем хранения регулярно синхронизируются (например, раз в сутки), обеспечивая когерентность данных.
В следующей версии решения SoFS планируется реализовать асинхронную репликацию между хранилищами. Это позволит сократить служебный трафик между филиалами компании, а также значительно уменьшить время расхождения между версиями данных в хранилищах.
Аппаратная платформа
Решение SoFS включает в себя стек аппаратного обеспечения IBM. Узлы кластера строятся на базе лезвий IBM BladeCenter или серверов IBM System x. Между собой узлы кластера связываются посредством сетевого интерфейса в 1 Гбит/c или 10 Гбит/с – этой скорости достаточно, чтобы обеспечить нормальную работу кластера GPFS.
Один из узлов кластера SoFS отводится под задачи администрирования и управление кластером, тогда как общее число узлов в кластере задает необходимый уровень производительности системы. Практика использования SoFS показывает, что один узел может гарантировать скорость в несколько сотен мегабайтов в секунду при наличии нескольких адаптеров Fibre Channel и внешних сетевых портов в 10 Гбит/с. Сейчас максимальная конфигурация SoFS насчитывает 20 узлов, но нет никакой принципиальной сложности в создании кластеров большего размера.
В качестве системы хранения поддерживаются системы IBM System Storage DS различных серий. Как правило, системы хранения подключаются к кластеру через Fibre Channel, но возможно также применение гигабитной сети и InfiniBand. Объем системы хранения ограничен только физическим пространством ЦОД, самая большая на данный момент установленная SoFS-система имеет объем 3 петабайт.
Интерфейс администрирования
На рис. 3 представлены основные компоненты решения SoFS: кластерные узлы, распределенная файловая система GPFS, кластерные версии файловых серверов, реализующих сетевые протоколы (CIFS, NFS и др.), коммуникационное оборудование. При желании такие системы можно было бы собрать из представленных компонентов, как часто делают при проектировании суперкомпьютеров и других высокопроизводительных систем. Однако администрирование таких уникальных систем стало бы отдельной сложной задачей, требующей высококвалифицированных специалистов в ряде областей. Применение подобных масштабируемых систем хранения в корпоративных или государственных информационных системах, в таких областях как связь, цифровое телевидение, фармацевтика, подразумевает куда более низкие требования к администрированию. Похожие проблемы возникают при использовании классических сетевых систем хранения: при росте объема данных приходится добавлять новые устройства хранения и распределять данные между ними (например, по отделам или задачам), что в свою очередь повышает расходы на поддержку и администрирование таких систем. Поэтому управление такой сложной инфраструктурой должно осуществляться через единый интерфейс, аналогичный используемому в сетевых системах хранения или маршрутизаторах.
Интерфейс администрирования SoFS разрабатывался именно из таких соображений и потому не уступает классическим сетевым систем хранения. С помощью простого Web-интерфейса можно управлять кластерной системой хранения как на уровне добавления новых узлов или дисковых подсистем, так и на уровне файловых служб и экспорта данных. Можно увидеть статистику использования системы и нагрузку на отдельные ее компоненты, задать ограничения по пользователям и квотирование данных, сформировать необходимые отчеты.
Алексей Федосеев (alexey_fedoseev@ru.ibm.com) – специалист по решениям на Linux компании IBM (Москва).
