gpfs что это такое
Выбор распределенной файловой системы для Linux. Пару слов о Ceph и остальных
Существует несколько десятков файловых систем, все из них предоставляют пользовательские интерфейсы для хранения данных. Каждая из систем хороша по-своему. Однако, в наш век высоких нагрузок и петабайтов данных для обработки, оказалось довольно непросто подыскать то, что нужно, стоит лишь задуматься о распределенных данных, распределенных нагрузках, множественном монтировании rw и о прочих кластерных прелестях.
Задача: организовать распределенное файловое хранилище
— без самосборных ядер, модулей, патчей,
— с возможностью множественного монтирования в режиме rw,
— POSIX совместимость,
— отказоустойчивость,
— совместимость с уже использующимися технологиями,
— разумный overhead по I/O операциям по сравнению с локальными файловыми системами,
— простота конфигурации, обслуживания и администрирования.
В работе мы используем Proxmox и контейнерную виртуализацию OpenVZ. Это удобно, это летает, у этого решения больше плюсов, чем у аналогичных продуктов. По крайней мере для наших проектов и в наших реалиях.
Сам storage везде монтируется по FC.
OCFS2
У нас был успешный опыт использования данной файловой системы, решили сначала попробовать ее. Proxmox с недавнего времени перешел на редхатовское ядро, в нем поддержка ocfs2 выключена. Модуль в ядре есть, но на форумах openvz и proxmox не рекомендуют его задействовать. Мы попробовали и пересобрали ядро. Модуль версии 1.5.0, кластер из 4 железных машин на базе debian squeeze, proxmox 2.0beta3, ядро 2.6.32-6-pve. Для тестов использовался stress. Проблемы за несколько лет остались те же самые. Все завелось, настройка данной связки занимает полчаса от силы. Однако, под нагрузкой кластер может самопроизвольно развалиться, что ведет к тотальному kernel panic на всех серверах сразу. За сутки тестов машины перезагружались в общей сложности пять раз. Это лечится, но доводить такую систему до работоспособного состояния довольно тяжело. Пришлось также пересобирать ядро и включать ocfs2. Минус.
Хоть ядро и редхатовское, модуль по умолчанию включен, завестись мы и здесь так и не смогли. Все дело в proxmox, которые со второй версии придумали свой кластер с шахматами и поэтессами для хранения своих конфигов. Там cman, corosync и прочие пакеты из gfs2-tools, только все пересобранные специально для pve. Оснастка для gfs2, таким образом, из пакетов просто так не ставится, так как предлагает сначала снести весь proxmox, что мы сделать не могли. За три часа зависимости удалось победить, но все опять закончилось kernel panic. Попытка приспособить пакеты для proxmox для решения наших проблем успехом не увенчалась, после двух часов было принято решение отказаться от этой идеи.
Остановились пока на ней.
POSIX совместимая, высокая скорость работы, отличная масштабируемость, несколько смелых и интересных подходов в реализации.
Файловая система состоит из следующих компонентов: 
1. Клиенты. Пользователи данных.
2. Сервера метаданных. Кэшируют и синхронизируют распределенные метаданные. С помощью метаданных клиент в любой промежуток времени знает, где находятся нужные ему данные. Также сервера метаданных выполняют распределение новых данных.
3. Кластер хранения объектов. Здесь в виде объектов хранятся как данные, так и метаданные.
4. Кластерные мониторы. Осуществляют мониторинг здоровья всей системы в целом.
Фактический файловый ввод/вывод происходит между клиентом и кластером хранения объектов. Таким образом, управление высокоуровневыми функциями POSIX (открытие, закрытие и переименование) осуществляется с помощью серверов метаданных, а управление обычными функциями POSIX (чтение и запись) осуществляется непосредственно через кластер хранения объектов.
Любых компонентов может быть несколько, в зависимости от стоящих перед администратором задач.
Файловая система может быть подключена как напрямую, с помощью модуля ядра, так через FUSE. С точки зрения пользователя, файловая система Ceph является прозрачной. Они просто имеют доступ к огромной системе хранения данных и не осведомлены об используемых для этого серверах метаданных, мониторах и отдельных устройствах, составляющих массивный пул системы хранения данных. Пользователи просто видят точку монтирования, в которой могут быть выполнены стандартные операции файлового ввода / вывода. С точки зрения администратора имеется возможность прозрачно расширить кластер, добавив сколько угодно необходимых компонентов, мониторов, хранилищ, серверов метаданных.
Разработчики гордо называют Ceph экосистемой.
GPFS, Lustre и прочие файловые системы, а также надстройки, мы не рассматривали в этот раз, они либо очень сложны в настройке, либо не развиваются, либо не подходят по заданию.
Конфигурация и тестирование
Конфигурация стандартная, все взято из Ceph wiki. В целом файловая система оставила приятные впечатления. Собран массив 2Тб, пополам из SAS и SATA дисков (экспорт блочных устройств по FC), партиции в ext3.
Ceph storage примонтирован внутрь 12-и виртуальных машин на 4 hardware nodes, осуществляется чтение-запись со всех точек монтирования. Четвертые сутки стресс-тестов проходят нормально, I/O выдается в среднем 75 мб/с. на запись по пику.
Прошу всех заинтересованных, а также всех сочувствующих, в личку. Тема очень интересная, ищем единомышленников, чтобы обсудить возникшие проблемы и найти способы их решения.
Распределенные файловые системы. Технологический обзор. Продуктовый обзор
Файловая система (file system) — это способ организации, хранения и именования данных на носителях информации в компьютерах. Файловые системы используются также в другом электронном оборудовании: в цифровых фотоаппаратах и диктофонах, в мобильных телефонах, и т. п.
Распределенные файловые системы (distributed file system) работают сразу на многих компьютерах (серверах) с репликацией для защиты от сбоев. Иногда «распределенными» также называют сетевые файловые системы, тем самым показывая, что распределенные файловые системы имеют больше возможностей, чем обычная передача данных по сети. Носители СХД, связанные с распределенными файловыми системами, могут (и даже должны) быть распределены между многими компьютерными системами.
Определения
Существует также понятие «кластерная файловая система». Различия между всеми этими терминами (сетевая, распределенная, кластерная) немного расплывчаты. Поэтому сначала нужно определить, что такое сетевая, кластерная и распределенная система.
С таким определением, например, NFSv3 можно отнести к сетевой файловой системе (network file system). GFS2 – это кластерная файловая система. GlusterFS – это распределенная файловая система. NFSv4, в свою очередь, это некий гибрид между сетевой файловой системой, но с поддержкой нескольких серверов, внедренных в нее.
Сумятицу иногда вносит то, что иногда вкладывается разный смысл в понятие «распределенный» (distributed). Здесь надо понимать, что «распределенность» должна присутствовать не только между серверами (тогда это кластер) в локальной сети, но также и между местоположениями этих серверов в глобальной сети (WAN), со всеми присущими ей особенностями. А именно: большими задержками и низкой надежностью соединений.
Распределенные (в таком определении) файловые системы состоят из нескольких географически разнесенных серверов, соединенных по модели sharing nothing, где каждый активный сервер имеет собственную СХД. Кроме того, распределенные файловые системы делятся на два типа: параллельные системы (Parallel file systems) и полностью параллельные файловые системы (Fully parallel file systems).
Так называются системы, которые предоставляют параллельный доступ к их серверам хранения для каждого клиента. Это позволяет устранить «узкие места» одного сервера по всем параметрам: IOPS, полоса, ограничения вычислительной способности процессора и кэш-памяти. Такие системы используются в высокопроизводительных компьютерных системах и бизнес-приложениях, например, в информационных системах фондовых бирж, Примеры: pNFS, Lustre.
Сравнение между сетевой и распределенной файловой системой на примере Lustre (источник: https://www.atipa.com/lustre-parallel-storage)
Полностью параллельными такие системы называются в том случае, когда не только данные, но и метаданные (различные индексы и пр.), также распределяются параллельно между всеми клиентами. Примеры таких систем – OrangeFS и Ceph.
Соотношения между сетевыми системами (Network), кластерными системами (Cluster), распределенными (Distributed), а также параллельными (Parallel) и полностью параллельными системами (Fully parallel) могут быть представлены следующим образом.
Соотношения между видами и типами распределенных (distributed file system) файловых систем (источник: lvee.org/en/abstracts/33)
С какой целью создавались распределенные файловые системы и какие задачи они решают
Во-первых, как уже указывалось, они нужны для защиты от сбоев и облегчения масштабирования СХД. Большое значение имеет API (Application Programming Interface), который они обеспечивают. Это значит, что каждое приложение, скрипт или библиотека стандартных подпрограмм, написанные в течение последних нескольких десятков лет, могут использовать распределенную файловую систему без коррекций их кода, без процедур импорта и экспорта данных. Даже такие решения, как SQL, не могут сравниться с универсальностью и простотой API распределенных файловых систем.
Во-вторых, распределенные файловые системы стали настолько популярными, что, используя их, мы иногда этого и не замечаем. Например, стриминг фильмов с сайта популярных видеохостингов (того же YouTube) почти всегда делается через распределенные файловые системы.
При производстве анимационных фильмов модели сцен и рендерные части в процессе производства почти всегда централизованно хранятся в распределенной файловой системе.
Виртуальные «блочные устройства» в облаке на самом деле часто являются файлами в распределенной файловой системе.
Системы распределенных вычислений в крупных научных лабораториях, таких как ЦЕРН, часто состоящие из более чем 100 тысяч процессоров, используют распределенные файловые системы для хранения данных экспериментов и результатов их обработки.
Можно сказать, что распределенные файловые системы – это то, как сегодня хранятся большинство данных, особенно «неструктурированных», которые используются при анализе «больших данных» (Big Data). Без этих систем провайдерам было бы очень сложно предоставлять различные онлайновые и медиауслуги.
Как пример можно было бы привести неудачу широко рекламировавшейся в свое время услуги «интернет-телевидения» (IPTV). Для того, чтобы ей воспользоваться, нужно было провести ряд сетевых настроек, которые любому IT-шнику могут показаться элементарными (например, «маска подсети» и пр.), но для простого обывателя они являлись отпугивающим фактором, несмотря на возможность смотреть «100 фильмов за 100 рублей в месяц». В результате эта услуга, что называется, «не пошла». Распределенные файловые системы с удобным интерфейсом как раз и помогают решить эти проблемы. Пример – любой популярный видеохостинг, либо пакет онлайн-телевидения от интернет-провайдера (например, «ОнЛайм» от Ростелекома).
Для различных предприятий и организаций распределенные файловые системы помогут решить проблемы управления данными и снизить стоимость хранения данных.
Распределенные файловые системы – кто они?
Учитывая сказанное выше об определениях, к распределенным файловым системам различные источники относят много систем, причем разные источники могут давать разные непересекающиеся списки. Ниже приведен неполный список из разных источников.
Продуктовый обзор
ZFS, IBM GPFS (Spectrum Scale), Ceph, Lustre
Файловая система ZFS была разработана в 2001 году в компании Sun Microsystems, приобретенной компанией Oracle в 2010 году. Аббревиатура ZFS означала «Zettabyte File System» (файловая система для объемов зеттабайт). Однако в настоящее время ZFS может хранить данные много большего объема.
Эта система проектировалась с очень большим запасом по параметрам, на основе совершенно справедливого прогноза огромного роста данных, подлежащих хранению в распределенных системах в будущем.
ZFS от Oracle и открытая система OpenZFS пошли разными путями, с тех пор, как Oracle закрыл проект OpenSolaris. OpenZFS — это общий проект, объединяющий разработчиков и компаний, которые используют файловую систему ZFS и работают над ее совершенствованием, чтобы сделать ZFS более широко используемым продуктом с открытым исходным кодом.
Некоторые теоретические пределы параметров, заложенные при проектировании ZFS:
Функции ZFS
ZFS обладает рядом полезных функций:
Хранение в пулах (Pooled storage)
В отличие от большинства файловых систем, ZFS объединяет функции файловой системы и менеджера томов (volume manager). Это означает, что ZFS может создавать файловую систему, которая будет простираться по многим группам накопителей ZVOL или пулам. Более того, можно добавлять емкость в пул простым добавлением нового накопителя. ZFS сама выполнит партицию и форматирование нового накопителя.
Пулы хранения в ZFS
В пулах можно легко создавать файловые системы (области хранения данных) для каждого приложения и предмета использования.
Копирование при записи (Copy-on-write)
В большинстве файловых систем при перезаписи данных на то же физическое место носителя ранее записанные там данные теряются навсегда. В ZFS новая информация пишется в новый блок. После окончания записи метаданные в файловой системе обновляются, указывая на местоположение нового блока. При этом, если в процессе записи информации с системой что-то происходит, старые данные будут сохранены. Это означает, что не нужно запускать проверку системы после аварии.
Снапшоты (Snapshots)
Copy-on-write закладывает основу для другой функции ZFS: моментальных снимков системы (снапшотов). ZFS использует для отслеживания изменений в системе.
Снапшот содержит оригинальную версию файловой системы, и в «живой» файловой системе присутствуют только изменения, которые были сделаны с момента последнего снапшота. Никакого дополнительного пространства не используется. Когда новые данные записываются в «живую» систему, выделяются новые блоки для сохранения этих данных.
Если файл удаляется, то ссылка на него в снапшоте тоже удаляется. Поэтому снапшоты в основном предназначены для отслеживания изменений в файлах, а не для добавления или создания файлов.
Снапшоты могут устанавливаться в режим read-only (только чтение), чтобы восстановить прежнюю версию файла. Также можно сделать откат «живой» системы на предыдущий снапшот. При этом будут потеряны только те изменения, которые были сделаны после момента этого снапшота.
Верификация целостности данных и автоматическое восстановление данных
При любой записи данных в ZFS создается контрольная сумма (checksum). При считывании данных, происходит сверка с этой контрольной суммой. Если проверка показывает расхождение с контрольной суммой, то ZFS устраняет ошибку считывания.
В традиционных файловых системах данные не могут быть восстановлены, если повреждение данных затрагивает область контрольной суммы. В ZFS данные и контрольная сумма физически разделены и данные могут быть восстановлены из блока высокого уровня.
Верификация целостности и автоматическое восстановление данных в ZFS
RAID-Z
ZFS может создавать RAID-массивы без необходимости использования дополнительного программного или аппаратного обеспечения. Поэтому неудивительно, что ZFS имеет собственный вариант RAID: RAID-Z.
RAID-Z представляет собой вариант RAID-5, котором предусмотрены средства преодоления ошибки write hole error, присущей RAID-5, когда данные и информация о паритете становятся не соответствующими друг другу после случайного перезапуска системы.
RAID-Z имеет три уровня: RAID-Z1, в котором нужно по крайней мере два диска для хранения и один для паритета; RAID-Z2, который требует по крайней мере двух дисков для хранения и двух для паритета; RAID-Z3 требует по крайней мере двух дисков для хранения и трех для паритета.
Добавление дисков в пул RAID-Z делается попарно.
Автоматическая замена на запасной диск (Hot spare)
В пуле хранения, сконфигурированном с запасным диском, отказавший диск автоматически заменяется запасным.
Автоматическая замена дисков при отказе
Один и тот же диск может быть запасным для нескольких пулов сразу.
При создании ZFS преследовалась цель сделать их «последним словом» в файловых системах. Во времена, когда большинство файловых систем были 64-битными, создатели ZFS решили, что лучше сразу заложить адресное пространство на 128 бит для будущего развития. Это означает, что ZFS имеет емкость в 16 миллиардов раз большую емкость, чем 32- или 64-битные системы. Создатель ZFS Джефф Бонвик (Jeff Bonwick), характеризуя величину этой емкости, сказал, что система в полной конфигурации с такой емкостью потребует для электропитания энергию, достаточную, чтобы вскипятить все океаны в мире.
IBM Spectrum Scale
Объем создаваемых, хранимых и анализируемых данных в мире возрастает экспоненциально. Часто требуется анализировать информацию быстрее конкурентов, причем в условиях роста собственной IT-инфраструктуры.
Файловая система в СХД организации должна поддерживать как большие данные (Big Data), так и традиционные приложения. IBM Spectrum Scale™ решает широкий спектр задач, и представляет собой высокопроизводительное решение для управления данными со встроенными функциями архивирования и аналитики.
IBM Spectrum Scale – это универсальная программно-конфигурируемая система хранения корпоративного класса, которая работает со многими типами носителей и автоматически переводит данные с уровня на уровень в зависимости от частоты их использования, обеспечивая отказоустойчивость, масштабируемость и управляемость.
Это решение, созданное на основе файловой системы IBM General Parallel File System (GPFS), способно масштабировать емкость и производительность для аналитических систем, репозиториев контента и других задач.
Когнитивные механизмы IBM умеют распределять данные среди различных устройств хранения, тем самым оптимизируя использование доступной емкости, упрощая администрирование и обеспечивая высокую производительность. IBM Spectrum Scale поддерживает глобального пространства имен с универсальным доступом, которое объединяет современные средства для работы с файлами, размещенных в сетевых файловых системах (NFS), блочные хранилища и серверы со встроенными хранилищами данных большого объема. Файловая система IBM Spectrum Scale может использоваться для работы с файлами (POSIX, NFS, CIFS), объектами (S3, SWIFT) и распределенной файловой системой Hadoop (HDFS) при решении задач анализа больших данных на месте хранения.
Задачи и возможности IBM Spectrum Scale.
Свойства IBM Spectrum Scale
Хорошая масштабируемость, которая позволяет обеспечивать максимальную пропускную способность и минимальные задержки при доступе.
Аналитика с учетом данных, позволяющая автоматически переносить данные на оптимальный уровень хранения (флеш, диск, кластер, лента), что позволяет до 90 % снизить расходы на архивирование данных.
Автоматическое размещение данных по уровням в файловой системе IBM Spectrum Scale
Распределенность, то есть возможность доступа к данным из любого места, ускоряет работу приложений по всему миру, за счет технологии распределенного кэширования и активного управления файлами.
Безопасность данных, технологии идентификация, шифрования, защиты Erasure Coding и репликации позволяют достичь соответствия регулятивным требованиям.
Универсальность, единое решение для управления масштабируемым хранилищем данных, обеспечивающее унификацию виртуализации, поддержки аналитических сред, обработки файлов и объектов.
Прозрачные политики хранения делают возможным сжатие и многоуровневое хранение данных на ленточных накопителях или в облаке, с целью сокращения расходов. Размещение данных с учетом места их использования уменьшает задержки и увеличивает производительность работы с данными.
Интеллектуальное кэширование данных, технология Active File Management (AFM) распространяет глобальное пространство имен Spectrum Scale за пределы географических границ, обеспечивая высокую производительность при чтении и записи данных и автоматическое управление пространством имен. Данные записываются или изменяются локально и в других местах эти данные получают с минимальной задержкой.
Графический интерфейс IBM Spectrum Scale GUI обеспечивает простое администрирование объемов данных уровня петабайт различных типов: файловых, объектных или блочных.
IBM Spectrum Scale – это хорошо зарекомендовавшее себя масштабируемое решение по администрированию данных, которое ранее называлось GPFS (General Parallel File System). Начиная с версии 4.1, это решение называется Spectrum Scale. Однако версии до 4.1 будут поддерживаться под старым названием GPFS.
Основные характеристики
Применения
Spectrum Scale используется уже более 15 лет во многих отраслях экономики во всем мире, и в таких областях, требовательных к объему и производительности обработки данных, как:
Функциональные возможности
Основные компоненты системы
Три NSD, определенные как диски tiebreaker disk для кворумных узлов (источник: IBM)
Три редакции Spectrum Scale
Есть три разных редакции (Edition) Spectrum Scale:
GPFS. Часть 1. Создание GPFS кластера
После одной из моих последних статьей на хабре про серверную оптимизацию мне прислали множество вопросов про распределенные файловые системы. И теперь я нашел в себе силы и возможности написать про замечательную кластерную файловую систему GPFS.
Создание кластера GPFS
Делится на следующие этапы:
Лицензирование в GPFS достаточно непростое. В версии 3.3 наконец-то сделали разделение между серверной и клиентской частью, и теперь за «клиента» можно платить меньше. Для клиентской и серверной части назначается разное количество Processor Value Units, и стоят эти PVU для клиентской и серверной частей по-разному. Подсчитать PVU для вашего кластера вы можете здесь. Более подробную информацию и part number gpfs можно получить из следующего документа. Купить GPFS можно у любого авторизованного реселлера IBM.
Тут всё просто. Покупаем, устанавливаем на все ноды, которые планируют использовать GPFS.
Создание кластера (mmcrcluster)
Связываем все ноды так, чтобы каждая нода имела беспарольный доступ к любой другой, включая и саму себя :). Далее инициализируем сам кластер.
Тюнинг параметров GPFS (mmchconfig)
Увеличиваем лимиты, включаем использование InfiniBand verbs и т.д. и т.п.
Запуск GPFS (mmstartup)
Благодаря тому, что все ноды имеют доступ на все остальные, большую часть работы они выполняют сами, будь то добавление сервиса в автозагрузку или же настройка fstab’а.
Создание NSD — Network Shared Disk (mmcrnsd)
Так как я использую топологию с Directly Connected дисками, то я не могу использовать tiebreaker-диск. Поэтому просто экспортирую все диски которые есть в системах, разделив их на 3 Failre-группы.
Создание файловой системы поверх NSD (mmcrfs)
При создании файловой системы можно указывать множество различных параметров, которые в дальнейшем будут влиять на быстродействие и отказоустойчивость системы.
Монтирование GPFS (mmmount)
Всё готово, монтируем файловую систему и можно начинать работать.
Структура нашего обучающего миникластера
У нас будет 3 Failover-группы:
1 — DataAndMetadata — Данные и Метаданные (primary):
диски gpfs00.edu.scalaxy.local и gpfs01.edu.scalaxy.local
2 — DataAndMetadata — Данные и Метаданные (backup):
диски gpfs03.edu.scalaxy.local и gpfs04.edu.scalaxy.local
3 — DescOnly — Реплика дескриптора (aka system descriptor) GPFS. Тут не хранятся ни данные, ни метаданные, диск предназначен только для сохранения quorum’а в случае потери основной реплики дескриптора:
диск gpfs02.edu.scalaxy.local
Далее создадим файл с нодами и их ролями:
# cat >gpfs.nodes
gpfs00.edu.scalaxy.local:quorum-manager:
gpfs01.edu.scalaxy.local:quorum-manager:
gpfs02.edu.scalaxy.local:quorum-client:
gpfs03.edu.scalaxy.local:client:
gpfs04.edu.scalaxy.local:client:
EOF
manager | client — Indicates whether a node is part of the node pool from which file system managers and token managers can be selected. The default is client.
quorum | nonquorum — Indicates whether a node is counted as a quorum node. The default is nonquorum.
gpfs00.edu.scalaxy.local и gpfs01.edu.scalaxy.local у нас будут участвовать в выборах manager’а (quorum-нод)
gpfs02.edu.scalaxy.local будет хранить реплику дескриптора GPFS
gpfs03.edu.scalaxy.local и gpfs04.edu.scalaxy.local будут клиентами, которые читают/пишут на GPFS
-N gpfs.nodes — имя файла с нодами (также можно передать разделённый запятыми список)
-p gpfs00.edu.scalaxy.local — primary-нода, на которой хранится конфигурация кластера
-s gpfs01.edu.scalaxy.local — secondary-нода, на которой хранится конфигурация кластера
-r /usr/bin/ssh — бинарник для удалённого выполнения команд на удалённом сервере
-R /usr/bin/scp — бинарник для безопасного копирования файлов на удалённый сервер
-C gpfs-cluster — имя для будущего кластера
-A — автоматически запускать на нодах gpfs-демон
Primary / Secondary ноды хорошо описаны в man’е:
It is suggested that you specify a secondary GPFS cluster configuration server to prevent the loss of configuration data in the event your primary GPFS cluster configuration server goes down. When the GPFS daemon starts up, at least one of the two GPFS cluster configuration servers must be accessible.
If your primary GPFS cluster configuration server fails and you have not designated a secondary server, the GPFS cluster configuration files are inaccessible, and any GPFS administration commands that are issued fail. File system mounts or daemon startups also fail if no GPFS cluster configuration server is available.
На основном кластере применяется примерно такой тюнинг для GPFS (подробнее):
У mmchconfig есть опция -I которая говорит ему применить параметры, но не сохранять их на диск. Весьма полезна при тестах, а также рискованных операциях.
maxFilesToCache — количество файлов для кэширования. Лучше выставлять сразу максимальное значение — 1000000.
maxMBpS — ограничение GPFS на ввод-вывод с одной ноды. Лучше выключить, выставив очень большое значение.
pagepool — на нодах с дисками отдается вся память, оставляя
verbsPorts — имя HCA и номер порта для использования verbs — только при наличии InfiniBand. Можно указывать сразу несколько портов через пробел, тогда GPFS создаст несколько RDMA-коннектов.
verbsRdma — enable — только при наличии InfiniBand, иначе disable.
worker1Threads — количество запросов, обслуживаемых одновременно. Максимум 500 для 64 битных систем.
nsdthreadsperdisk — недокументированный параметр, определяет количество потоков, обслуживающих каждый диск.
Менее употребляемые параметры:
cipherList — GPFS может шифровать данные при их передаче и безопасно аутентифицировать ноды.
pagepoolMaxPhysMemPct — максимальный процент памяти который может быть выделен под PagePool.
Теперь небольшое лирическое отступление — в GPFS документация делится две части:
Официальная (aka external documented) — это та, что выкладывается в интернете и в man’ах.
Неофициальная (aka internal documented) — та, что написана в комментариях в shell-скриптах mm* (да-да, почти все команды gpfs это shell скрипты. По сути, 99% команд, лишь обертки к низкоуровневым сишным прожкам, которые являются лишь интерфейсом к функциям демона mmfsd. Весь функционал в демоне.)
Про internal документацию написано следующее: configuration parameters to be used only under the direction of IBM service
Но мы не из робких, так что можно смело искать всякие крутилки в /usr/lpp/mmfs/bin/mmchconfig и тестировать их в работе.
Итак, после того как мы создали ноды, можно дистанционно на всех машинах запустить gpfs (заметьте, что большинство команд я выполняю на машине gpfs00, а они, в свою очередь, применяются на всём кластере):
-a — отвечает за поднятие GPFS на всех нодах.
Далее выставляем нодам нужный тип лицензий.
Одна часть у нас будет серверами:
Создание NSD — Network Shared Disk
Теперь создаём файл с описанием дисков и их содержимого:
Формат файла таков:
DiskName — для Unix-систем — имя блочного устройства.
ServerList — список серверов, с которых доступен этот диск. Можно указать до восьми серверов, из которых будет выбран первый работоспособный. В нашем случае, где не используется SAN, это всего один сервер — тот, к которому подключён этот диск. Если не указать ничего, то GPFS будет считать, что диск доступен всем нодам кластера.
DiskUsage — dataAndMetadata|dataOnly|metadataOnly|descOnly варианты говорят сами за себя, да и в мануале более подробное объяснение, разве что у descOnly, который я описывал выше.
FailureGroup — группа, к которой принадлежит диск. GPFS использует эту информацию, раскладывая данные и метаданные так, чтобы при единичном отказе обе реплики не погибли. То есть, например, диски, подключённые к одному контроллеру, к одному серверу или находящиеся в одном датацентре, принадлежат одной Failure-группе.
DesiredName — имя, которое мы хотим присвоить nsd. Должно попадать под регексп /[A-Za-Z0-9_]+/. По дефолту — gpfsNNnsd, где NN — целое, положительное, уникальное среди других nsd число.
StoragePool — имя Storage Pool’а, которое потом без изменений передаётся на mmcrfs.
Таже рекомендую прочитать более подробно о mmcrnsd
-v no — не проверять, является ли диск уже отформатированым NSD (определяется это по второму сектору диска, где обычно хранится NSD volume ID)
Создание FS поверх NSD
После удачного завершения mmcrnsd файл gpfs.disks модифицируется для дальнейшего использования командой mmcrfs:
Далее идёт команда mmcrfs, к ней нужно отнестись весьма серьёзно, ибо она имеет множество параметров, каждый из которых влияет как на функциональность, так и на производительность GPFS, а после её создания изменить часть из них будет уже нереально.
Подробнее о некоторых параметрах mmcrfs:
-A — автомонтирование GPFS при загрузке сервера. automount монтирует GPFS при первом обращении (на Linux, на Windows аналогично yes).
-B — размер блока — это минимальная единица аллокации GPFS. Он может быть равен 16 KB, 64 KB, 128 KB, 256 KB (default), 512 KB, 1 MB, 2 MB или 4 MB. Минимальный размер файла на диске это 1/32 размера блока. Также, размер блока является максимальным размером read/write request’а.
Рекомендуют подстраивать размер блока под размер strip’а на raid’е или же под размеры буферов приложений.
Документация предлагает использовать больший размер блока для увеличения производительности sequential read and write, а маленький для small random read and write и metadata-intensive-сценариев.
В pagepool данные кешируются также блоками, то есть, при увеличении размера блока, желательно также поднять размер пула.
Размер блока не может превышать maxblocksize, который по умолчанию равен 1MB. Изменить maxblocksize можно командой mmchconfig.
-D — схема блокировок. Если GPFS планирует отдаваться через nfs4 или samba, то нужно использовать nfs4, если GPFS будет отдаваться по NFS3 или же не будет экспортироваться никак, то лучше использовать posix.
-j — метод выделения блоков для файла. Для больших инсталляций лучше использовать scatter, для маленьких cluster. Подробнее в мануале.
-L — размер логфайла. Варьируется от 256kb до 16MB. Стоит поднимать на высоконагруженых файловых системах и при большом количестве метаданных.
-N NumInodes[:NumInodesToPreallocate] — количество inodes. Поддерживаются суффиксы, i.e. 10M
-r DefaultDataReplicas — количество реплик для данных файла по умолчанию. Не может быть больше, чем MaxDataReplicas. По умолчанию значение равно «1».
-R MaxDataReplicas — максимальное количество реплик, которое можно задать через mmchattr
-E no — не выполнять realtime-обновление mtime-файлов (чаще всего это не нужно)
-S yes — запретить обновление atime. При включении функции gpfs_stat(), gpfs_fstat(), stat() и fstat() отдают atime равное ctime.
-T /gpfs-storage — точка монтирования, по-умолчанию DefaultMountDir/Device, DefaultMountDir = /gpfs
Если при создании файловой системы вы не включили автомаунт, то придётся примонтировать его вручную (подробнее).
Вот, в принципе, и все, что я хотел рассказать о настройке GPFS. На днях я планирую написать продолжение этой статьи, в которой будет рассказано про эксплуатацию GPFS-кластера.