Ключевые слова:nfs, lustre, gfs, (найти похожие документы)
From: Lynz <http://red-hat-moscow-times.blogspot.com>;
Date: Mon, 14 Jan 2007 14:31:37 +0000 (UTC)
Subject: Обзор сетевых файловыз систем nfs, lustre и gfs
Оригинал: http://red-hat-moscow-times.blogspot.com/2007/11/blog-post.html
Введение
Идея сетевых файловых систем далеко не нова. Далеко не нова - это
значит, что первые реализации файловых систем, внешних по отношению к
физическим ЭВМ, появилась в начале 80х - это файловые системы для
VAX-VMS кластеров. Эту идею развивали многие компании, в результате
чего мы по сути имеем несколько фундаментальных концептов разделяемых
файловых систем, не говоря уже о количестве конкретных реализаций
данных концептов. Фундаментальные концепты включают сетевые файловые
системы (NFS), параллельные файловые системы (Lustre) и симметричные
блочно-разделяемые файловые системы (GFS и иже с ними).
Сетевые файловые системы (NFS)
Сетевая файловая система (NFS) - достаточно простое, дешевое и
привычное в мире Unix решение для организации разделяемых данных.
Спецификации (как и многие реализации) NFS имеют прямое отношение к
SUN Microsystems. Всего существует 4 различных спецификации протокола
NFS, хотя первая его версия так и не вышла в свет, оставшись навсегда
во внутренних тестовых лабораториях SUN. Поэтому наш обзор мы начнем с
NFSv2. Напомним, что это концепт удаленной файловой системы,
предоставляющей доступ на файловом уровне.
NFSv2
Спецификация NFSv2, выпущенная в далеком 1989 году, полагалась
исключительно на UDP в качестве транспортного протокола. Это позволяло
создать достаточно простой сервер, который не имел внутреннего
состояния (Stateless), что, соответственно, не давало никаких гарантий
транзакционности файловых операций (например потому, что файловые
операции могли выполняться сервером в порядке дохождения пакетов,
который, вообще говоря, может отличаться от порядка операций,
задуманного клиентом). Файловые блокировки также были реализованы вне
основного протокола, что существенно ограничивало производительность.
В частности, многие реализации просто начинали poll'ить
заблокированный файл, создавая паразитный трафик и ненужную нагрузку
на сервер. Добавим сюда абсолютное отсутствие аутентификации клиента
на сервере (мы же не полагаемся на IP-адрес, как на данные
аутентификации, правда?) и предположение об однородном пространстве
соответствий пользователей и их идентификаторов, что принято было
обеспечивать с помощью, мягко говоря, не самого безопасного протокола
- NIS, и мы поймем, насколько эта версия NFS слаба и незащищена.
Итого, из плюсов системы можно отметить только:
1. Простоту реализации и развертывания
2. Абсолютную индифферентность "сервера-без-состояния" к
происходящему в сети. Например, клиент запросто мог
перезагрузиться и продолжить запись в файл как ни в чем ни бывало.
Зато из недостатков:
1. Фактическое отсутствие контроля доступа и шифрования информации.
2. Необходимость использования в "доверенной сети".
3. Необходимость централизации пользовательской информации.
4. Отсутствие транзакционности.
5. Отсутствие поддержки блокировок.
6. Поддержка исключительно синхронных операций записи.
NFSv3
Спецификация NFSv3 вышла в чуть менее далеком 95м, хотя, наверное, это
знаменательное событие было несколько оттенено запуском Windows 95 =).
В новой (по тем временам) спецификации было 4 фундаментальных
преимущества перед версией v2. Вот они:
1. Возможность использовать TCP в качестве транспортного протокола.
2. Возможность использовать 64-битные размеры и смещения в файлах,
что позволяло использовать большие файлы (более 4Гб).
3. Поддержка асинхронного ввода-вывода.
4. Реализация файловых блокировок в протоколе.
Остальные фундаментальные недостатки, вроде абсолютного отсутствия
аутентификации и необходимости использовать централизованный сервис
предоставления пользовательской информации, никуда не делись.
NFSv4 aka текущая версия
Данная спецификация была разработана в 2000 году и пересмотрена в
2003. В то время спецификация уже вышла из-под контроля SUN (как в
свое время сделали немало других спецификаций, например, спецификации
Java). Из принципиальных улучшений стоит отметить:
1. Поддержку аутентификации хостов и пользователей (например,
средствами Kerberos).
2. Поддержку шифрования информации.
3. Поддержку "продвинутых" методов клиентского кэширования.
В спецификации есть дополнительно много мелких улучшений (со списком
можно ознакомиться в RFC3530).
Из общих недостатков подобных решений стоит отметить крайне неважную
масштабируемость. Например, использовать NFS в качестве файловой
системы для кластеров СУБД по крайней мере наивно. Для каждой задачи
есть свой инструмент, поэтому мы перейдем к другой крайности -
параллельным файловым системам.
Параллельные файловые системы (Lustre)
Авторы утверждают, что название этой файловой системы произошло от
смешения слов Linux и cluster, хотя лично нам аналогия с люстрой
кажется несколько более очевидной. Это файловая система обладает
максимальной производительностью, масштабируемостью и является
наиболее успешным примером файловой системы, которая, например,
используется в MPP-системах, таких как вычислительные кластера. Это
байт-ориентированная файловая система. Принцип устройства файловой
системы достаточно комплексен, так что рекомендую читать более одного
раза =). Базовых компонент три:
1. Сервер метаданных (возможно с активным/пассивным резервированием).
Данный сервис отвечает за метаданные, такие как структура
директорий, атрибуты и имена файлов, а также указывает на
положение "объектов", составляющих файл, на экземплярах следующей
компоненты.
2. Сервер хранения. Это сервер, к которому может быть подключено
несколько "целей хранения", или, если по простому, блочных
устройств. В настоящее время на этих блочных устройствах
используется несколько видоизмененная файловая система ext3 для
хранения объектов. Типичная конфигурация сервера хранения
предусматривает наличие от 2-х до 8-ми "целей", каждая объемом до
8 Тб. Общий объем файловой системы равен сумме объемов целей, ее
составляющих.
3. Клиент. Без особых комментариев. Клиент находит необходимый ему
файл (а точнее, объекты его составляющие), пользуясь сервером
метаданных. Затем блокирует определенный диапазон смещений внутри
файла и обращается к серверам хранения, которые непосредственно
модифицируют данные на своих "дисках".
При подобной инфраструктуре выдерживается также следующее правило:
если файл влезает в один "объект", то этот объект хранится на одном
сервере, в противном случае производится stripping файла между
несколькими серверами, что, во-первых, позволяет избежать ограничений
объема единичных устройств, и, во-вторых, разнести нагрузку.
Подобный концепт обеспечивает наилучшую масштабируемость и
производительность, за что Lustre снискала немалую популярность в
научном мире (Lustre используется в 30 из top 50 суперкомпьютеров).
Однако для бизнеса это решение не очень подходит, потому что требует
солидного количества аппаратуры для работы, а значит - излишне
громоздко для типичных бизнес-задач, вроде кластера СУБД. Для подобных
задач остроумные люди придумали симметричные разделяемые (кластерные)
файловые системы с доступом к устройству хранения на блочном уровне.
Симметричные ФС с разделяемым диском (GFS, GFS2...)
Подобные файловые системы характеризуются отсутствием функционального
разделения узлов с одной стороны, и достаточно высокой
производительностью - с другой. Принцип действия данных систем
следующий:
* Могут использоваться любые протоколы доступа к разделяемому
блочному устройству, будь то стандартные (FC, iSCSI) или
софтверные линуксоспецифичные (GNBD). Естественно, каждый из
методов обладает своими преимуществами и недостатками.
* Должны использоваться кластерные службы, в частности, cman (задача
- обеспечение функционирования распределенного менеджера
блокировок), fence (задача - "отсечение" некорректно работающих
узлов от данных и восстановление).
* Для управления хранилищем данных обычно используется CLVM,
кластерный вариант управления логическими томами от Red Hat.
Принцип действия, за исключением блокировок, тот же самый, что был
описан в предыдущих постах для LVM.
* Используется журналирование метаданных и данных, что обеспечивает,
соответственно, целостность файловой системы/даных.
Общий алгоритм работы выглядит следующим образом:
* Каждый узел занимает свой индивидуальный журнал.
* Информация о блокировках распределена между узлами. В нормальном
положении все узлы в курсе всех блокировок.
* Узлы открывают файлы и работают с данными. При этом клиенты
осуществляют прямой параллельный доступ к ФС, работая с данными на
блочном уровне.
* ФС поддерживает изменение размеров (только в большую сторону) без
отключения.
В случае отказа одного из услов происходит горячее восстановление по
следующему алгоритму:
1. Узел "убивается" (fence). Обычно это осуществляется физическим
отключением питания, используя какие-либо сетевые устройства (APC,
HP iLO,...).
2. Один из узлов в кластере завершает свои операции и освобождает
свой журнал, забирая себе журнал сбойного узла.
3. Операции по журналу сбойного узла откатываются/завершаются и
система продолжает функционировать как ни в чем ни бывало.
При всем при этом производительность решения с параллельной
симметричной блочной ФС выше, чем у NFS, не требуя при этом того
колчества доп. аппаратуры, которое используется в Lustre. GFS давно
стала привычной технологией для решения бизнес-задач, вроде
организации кластеров СУБД, благодаря некоторым расширениям POSIX,
которые предоставляет GFS, как-то:
* Direct I/O - синхронный режим записи на диск для определенных
файлов.
* Freeze/Unfreeze - возможность приостановить работу с FS (корректно
"подвесив" системные вызовы на прочих узлав) с одного узла
(например, для нужд обслуживания).
* CDPN (Context Depending Path Names - контекстно-зависимые пути к
файлам), позволяющий хранить данные, специфичные для узла, на
общей файловой системе.
К сожалению, первая версия GFS не была лишена недостатков. К числу их
можно отнести:
1. Хранение журналов "рядом" с файловой системой, а не на ней. Это
приводило к ситуации, в которой нельзя было увеличить количество
журналов, не уменьшив объем файловой системы (что, напомним,
делать онлайн нельзя), либо не увеличив размер логического тома.
2. Отсутствие поддержки хранения информации SELinux (контекстов
файлов).
3. Падение производительности при работе с большим количеством мелких
файлов.
Эти недостатки были исправлены в этом году с выпуском версии GFS2.
Резюме.
В Linux наблюдается огромное разнообразие (многие считают его
избытком) поддерживаемых файловых систем, локальных и сетевых. Причем
в отношении сетевых ФС в полной мере справедливо правило UNIX: каждый
инструмент решает свою четко очерченную задачу. В этом плане сетевые
файловые системы (NFS) удобно использовать для небольшого количества
клиентов и интенсивного ввода/вывода, GFS - для интенсивных задач
ввода/вывода в масштабах типичного бизнес-кластера, а Lustre - для
MPP-систем.
Сетевая файловая система (NFS) - достаточно простое, дешевое и привычное в мире Unix решение для организации разделяемых данных. Спецификации (как и многие реализации) NFS имеют прямое отношение к SUN Microsystems. Всего существует 4 различных спецификации протокола NFS, хотя первая его версия так и не вышла в свет, оставшись навсегда во внутренних тестовых лабораториях SUN. Поэтому наш обзор мы начнем с NFSv2. Напомним, что это концепт удаленной файловой системы, предоставляющей доступ на файловом уровне. NFSv2 Спецификация NFSv2, выпущенная в далеком 1989 году, полагалась исключительно на UDP в качестве транспортного протокола. Это позволяло создать достаточно простой сервер, который не имел внутреннего состояния (Stateless), что, соответственно, не давало никаких гарантий транзакционности файловых операций (например потому, что файловые операции могли выполняться сервером в порядке дохождения пакетов, который, вообще говоря, может отличаться от порядка операций, задуманного клиентом). Файловые блокировки также были реализованы вне основного протокола, что существенно ограничивало производительность. В частности, многие реализации просто начинали poll'ить заблокированный файл, создавая паразитный трафик и ненужную нагрузку на сервер. Добавим сюда абсолютное отсутствие аутентификации клиента на сервере (мы же не полагаемся на IP-адрес, как на данные аутентификации, правда?) и предположение об однородном пространстве соответствий пользователей и их идентификаторов, что принято было обеспечивать с помощью, мягко говоря, не самого безопасного протокола - NIS, и мы поймем, насколько эта версия NFS слаба и незащищена. Итого, из плюсов системы можно отметить только: 1. Простоту реализации и развертывания 2. Абсолютную индифферентность "сервера-без-состояния" к происходящему в сети. Например, клиент запросто мог перезагрузиться и продолжить запись в файл как ни в чем ни бывало. Зато из недостатков: 1. Фактическое отсутствие контроля доступа и шифрования информации. 2. Необходимость использования в "доверенной сети". 3. Необходимость централизации пользовательской информации. 4. Отсутствие транзакционности. 5. Отсутствие поддержки блокировок. 6. Поддержка исключительно синхронных операций записи. NFSv3 Спецификация NFSv3 вышла в чуть менее далеком 95м, хотя, наверное, это знаменательное событие было несколько оттенено запуском Windows 95 =). В новой (по тем временам) спецификации было 4 фундаментальных преимущества перед версией v2. Вот они: 1. Возможность использовать TCP в качестве транспортного протокола. 2. Возможность использовать 64-битные размеры и смещения в файлах, что позволяло использовать большие файлы (более 4Гб). 3. Поддержка асинхронного ввода-вывода. 4. Реализация файловых блокировок в протоколе. Остальные фундаментальные недостатки, вроде абсолютного отсутствия аутентификации и необходимости использовать централизованный сервис предоставления пользовательской информации, никуда не делись. NFSv4 aka текущая версия Данная спецификация была разработана в 2000 году и пересмотрена в 2003. В то время спецификация уже вышла из-под контроля SUN (как в свое время сделали немало других спецификаций, например, спецификации Java). Из принципиальных улучшений стоит отметить: 1. Поддержку аутентификации хостов и пользователей (например, средствами Kerberos). 2. Поддержку шифрования информации. 3. Поддержку "продвинутых" методов клиентского кэширования. В спецификации есть дополнительно много мелких улучшений (со списком можно ознакомиться в RFC3530). Из общих недостатков подобных решений стоит отметить крайне неважную масштабируемость. Например, использовать NFS в качестве файловой системы для кластеров СУБД по крайней мере наивно. Для каждой задачи есть свой инструмент, поэтому мы перейдем к другой крайности - параллельным файловым системам. Параллельные файловые системы (Lustre)
Авторы утверждают, что название этой файловой системы произошло от смешения слов Linux и cluster, хотя лично нам аналогия с люстрой кажется несколько более очевидной. Это файловая система обладает максимальной производительностью, масштабируемостью и является наиболее успешным примером файловой системы, которая, например, используется в MPP-системах, таких как вычислительные кластера. Это байт-ориентированная файловая система. Принцип устройства файловой системы достаточно комплексен, так что рекомендую читать более одного раза =). Базовых компонент три: 1. Сервер метаданных (возможно с активным/пассивным резервированием). Данный сервис отвечает за метаданные, такие как структура директорий, атрибуты и имена файлов, а также указывает на положение "объектов", составляющих файл, на экземплярах следующей компоненты. 2. Сервер хранения. Это сервер, к которому может быть подключено несколько "целей хранения", или, если по простому, блочных устройств. В настоящее время на этих блочных устройствах используется несколько видоизмененная файловая система ext3 для хранения объектов. Типичная конфигурация сервера хранения предусматривает наличие от 2-х до 8-ми "целей", каждая объемом до 8 Тб. Общий объем файловой системы равен сумме объемов целей, ее составляющих. 3. Клиент. Без особых комментариев. Клиент находит необходимый ему файл (а точнее, объекты его составляющие), пользуясь сервером метаданных. Затем блокирует определенный диапазон смещений внутри файла и обращается к серверам хранения, которые непосредственно модифицируют данные на своих "дисках". При подобной инфраструктуре выдерживается также следующее правило: если файл влезает в один "объект", то этот объект хранится на одном сервере, в противном случае производится stripping файла между несколькими серверами, что, во-первых, позволяет избежать ограничений объема единичных устройств, и, во-вторых, разнести нагрузку. Подобный концепт обеспечивает наилучшую масштабируемость и производительность, за что Lustre снискала немалую популярность в научном мире (Lustre используется в 30 из top 50 суперкомпьютеров). Однако для бизнеса это решение не очень подходит, потому что требует солидного количества аппаратуры для работы, а значит - излишне громоздко для типичных бизнес-задач, вроде кластера СУБД. Для подобных задач остроумные люди придумали симметричные разделяемые (кластерные) файловые системы с доступом к устройству хранения на блочном уровне. Симметричные ФС с разделяемым диском (GFS, GFS2...)
Подобные файловые системы характеризуются отсутствием функционального разделения узлов с одной стороны, и достаточно высокой производительностью - с другой. Принцип действия данных систем следующий: * Могут использоваться любые протоколы доступа к разделяемому блочному устройству, будь то стандартные (FC, iSCSI) или софтверные линуксоспецифичные (GNBD). Естественно, каждый из методов обладает своими преимуществами и недостатками. * Должны использоваться кластерные службы, в частности, cman (задача - обеспечение функционирования распределенного менеджера блокировок), fence (задача - "отсечение" некорректно работающих узлов от данных и восстановление). * Для управления хранилищем данных обычно используется CLVM, кластерный вариант управления логическими томами от Red Hat. Принцип действия, за исключением блокировок, тот же самый, что был описан в предыдущих постах для LVM. * Используется журналирование метаданных и данных, что обеспечивает, соответственно, целостность файловой системы/даных. Общий алгоритм работы выглядит следующим образом: * Каждый узел занимает свой индивидуальный журнал. * Информация о блокировках распределена между узлами. В нормальном положении все узлы в курсе всех блокировок. * Узлы открывают файлы и работают с данными. При этом клиенты осуществляют прямой параллельный доступ к ФС, работая с данными на блочном уровне. * ФС поддерживает изменение размеров (только в большую сторону) без отключения. В случае отказа одного из услов происходит горячее восстановление по следующему алгоритму: 1. Узел "убивается" (fence). Обычно это осуществляется физическим отключением питания, используя какие-либо сетевые устройства (APC, HP iLO,...). 2. Один из узлов в кластере завершает свои операции и освобождает свой журнал, забирая себе журнал сбойного узла. 3. Операции по журналу сбойного узла откатываются/завершаются и система продолжает функционировать как ни в чем ни бывало. При всем при этом производительность решения с параллельной симметричной блочной ФС выше, чем у NFS, не требуя при этом того колчества доп. аппаратуры, которое используется в Lustre. GFS давно стала привычной технологией для решения бизнес-задач, вроде организации кластеров СУБД, благодаря некоторым расширениям POSIX, которые предоставляет GFS, как-то: * Direct I/O - синхронный режим записи на диск для определенных файлов. * Freeze/Unfreeze - возможность приостановить работу с FS (корректно "подвесив" системные вызовы на прочих узлав) с одного узла (например, для нужд обслуживания). * CDPN (Context Depending Path Names - контекстно-зависимые пути к файлам), позволяющий хранить данные, специфичные для узла, на общей файловой системе. К сожалению, первая версия GFS не была лишена недостатков. К числу их можно отнести: 1. Хранение журналов "рядом" с файловой системой, а не на ней. Это приводило к ситуации, в которой нельзя было увеличить количество журналов, не уменьшив объем файловой системы (что, напомним, делать онлайн нельзя), либо не увеличив размер логического тома. 2. Отсутствие поддержки хранения информации SELinux (контекстов файлов). 3. Падение производительности при работе с большим количеством мелких файлов. Эти недостатки были исправлены в этом году с выпуском версии GFS2. Резюме. В Linux наблюдается огромное разнообразие (многие считают его избытком) поддерживаемых файловых систем, локальных и сетевых. Причем в отношении сетевых ФС в полной мере справедливо правило UNIX: каждый инструмент решает свою четко очерченную задачу. В этом плане сетевые файловые системы (NFS) удобно использовать для небольшого количества клиентов и интенсивного ввода/вывода, GFS - для интенсивных задач ввода/вывода в масштабах типичного бизнес-кластера, а Lustre - для MPP-систем.
