• Кому стоит пользоваться BeeGFS?

Всем, кто заинтересован в быстром, гибком и простом управлении хранением данных. Как правило, это относится к кластерам HPC, но BeeGFS была спроектирована так, чтобы хорошо работать и при небольших развертываниях, таких как группа рабочих станций или даже гетерогенных систем с разными аппаратными архитектурами.

• Подходит ли BeeGFS для производственного использования?

Да, абсолютно! BeeGFS не является доказательством концепции или научным воплощением. BeeGFS был разработан для производственного использования с самого начала и в настоящее время используется в производстве на тысячах площадок по всему миру. ThinkParQ, дочерняя компания из Fraunhofer, была специально создана ключевыми людьми, стоящими за BeeGFS, для предоставления профессиональной поддержки и услуг для BeeGFS в сотрудничестве с международными партнерами по разработке решений «под ключ».

• Каковы минимальные системные требования для запуска BeeGFS?

В настоящее время для Linux на архитектурах x86, x86_64 и PowerPC/Cell доступны родные клиентские и серверные компоненты BeeGFS. В целом, все компоненты BeeGFS могут работать на одной машине с одним центральным процессором, одним жестким диском и менее 1 ГБ оперативной памяти. Но это, вероятно, не то, что вы хотите сделать на практике, поэтому вот некоторые рекомендации по настройке аппаратного обеспечения:

Сервер хранения:

Сервер хранения должен иметь не менее 4 ГБ оперативной памяти, чтобы иметь достаточно памяти для кэширования и буферов подключения клиентов. 1 ГБ оперативной памяти на каждый подключенный диск, как правило, является хорошим выбором в зависимости от фактического типа диска и количества клиентов файловой системы. Если вы используете традиционные жесткие диски SATA (т.е. не SSD или быстрые диски SAS), то, как правило, вы захотите использовать RAID с не менее чем 8 дисками на сервер. Несмотря на то, что задачи сервера хранения обычно не очень ресурсоемкие, буферные кэши Linux могут создавать высокую нагрузку на процессор при использовании быстрых RAID-массивов, поэтому часто бывает полезно иметь здесь быстрый процессор для обеспечения высокой пропускной способности, особенно в высокоскоростных сетях. Следите за балансом между количеством дисков (в системе в целом и на сервер), пропускной способностью сетевого соединения и количеством клиентов файловой системы. (Например, в зависимости от варианта использования, нет смысла использовать более 12 жестких дисков на сервер, если серверы оснащены только 10-гигабийтным межсетевым соединением).

Сервер метаданных:

Если вы работаете в основном с большими файлами, то для сервера метаданных не так уж и много работы, и вы, возможно, просто захотите запустить его на тех же машинах, которые работают в качестве серверов хранения, и на тех же разделах жесткого диска. На кластерах с очень разными типами рабочих нагрузок вы все равно можете захотеть запустить демон сервера метаданных на машинах сервера хранения (чтобы иметь большое количество серверов метаданных без дополнительных затрат на выделенные машины), но для метаданных следует использовать выделенные диски на ваших серверах хранения. Поскольку серверы метаданных делают много случайного доступа к дискам (т.е. они читают и записывают много маленьких файлов), это может оказать значительное влияние на производительность хранилища и доступ к метаданным, если оба диска расположены на одних и тех же дисках. Мы также часто видим на практике, что RAID-контроллеры имеют проблемы с производительностью при управлении различными типами томов RAID для метаданных и серверов хранения, поэтому, возможно, вам захочется иметь метаданные на отдельном RAID-контроллере. Вы также можете захотеть использовать выделенный сетевой интерфейс для метаданных, поскольку потоковые сетевые передачи могут влиять на задержку доступа к метаданным на сетевом уровне. Использование процессора на серверах метаданных может быть высоким, если у вас есть большое количество клиентов, имеющих дело со многими (небольшими) файлами. Поэтому убедитесь, что вы используете быстрый процессор и быстрые диски (обычно SSD), чтобы гарантировать низкую задержку доступа к метаданным. Количество пространства, необходимого для метаданных, в сравнении с общей емкостью хранилища зависит от фактического использования (т.е. от общего количества файлов, которые нужно хранить). Для файловой системы пространство, необходимое для метаданных, обычно составляет от 0,3% до 0,5% от общей емкости хранилища, но иногда и это тоже слишком много.

Клиент: Так как клиентские компоненты BeeGFS рассчитаны на очень малый вес, нет никаких специальных требований к оперативной памяти или процессору.

Менеджмент сервер:

Демон управления использует только минимальное количество циклов процессора и памяти. Необходимое дисковое пространство составляет около 1 Мб, а потребление памяти минимально. Пропускная способность сети, созданная даемоном управления, тоже очень низкая. Доступ к демону управления не имеет значения для производительности файловой системы. Просто запустите этого демона на любом из серверов хранения/метаданных или на хозяине кластера. Тем не менее, если демон управления настроен на использование RDMA для связи (по умолчанию: TCP), потребление памяти может стать ощутимым на больших кластерах, потому что каждое отдельное соединение потребует несколько мегабайт памяти.

• Какие типы сетей поддерживает BeeGFS?

BeeGFS поддерживает все сети на основе TCP/IP и родной дл файловой системы протокол InfiniBand (на основе OFED ibverbs), который также включает в себя Omni-Path и RDMA через Converged Ethernet (RoCE). Серверы и клиенты могут одновременно обрабатывать запросы от/к различным сетям (например, ваши серверы могут быть оснащены Infiniband и Ethernet-соединениями, а некоторые клиенты соединяются через собственный InfiniBand, в то время как другие клиенты соединяются через TCP/Ethernet). Клиенты с несколькими путями подключения (например, InfiniBand и Ethernet или несколькими Ethernet-портами) также могут осуществлять обход отказа сети в случае отказа основного пути подключения.

• Могу ли я получить BeeGFS бесплатно?

Да, BeeGFS можно скачать и использовать бесплатно без каких-либо ограничений.

• Нужна ли мне SAN или какое-либо общее хранилище для работы BeeGFS?

Нет, BeeGFS не является файловой системой сети хранения данных (SAN) и не полагается на общий доступ к хранилищу. Типичные аппаратные конфигурации для BeeGFS состоят из нескольких серверов с внутренним (или внешним не разделяемым) RAID-массивом.

• Обеспечивает ли BeeGFS высокую доступность?

Начиная с версии 2012.10, BeeGFS обеспечивает дополнительную избыточность метаданных и содержимого файлов (репликация). В серии 2015.03 эта концепция была расширена дополнительными функциями высокой доступности для прозрачного обхода отказа.

Кроме того, вы также можете реализовать обход отказа с активными парами серверов, основанными на общем хранилище и внешних инструментах, таких как Heartbeat или Pacemaker. Это позволит получить доступ к существующим данным в случае отказа машины, хотя BeeGFS использует кэширование записи на серверах, поэтому холодные обходы отказа могут быть не полностью прозрачны для работающих приложений. Чтобы настроить активные/активные пары с обходом отказа на основе внешних утилит, вам нужно будет запустить новый экземпляр вышедшего из строя демона на другой машине, так чтобы два экземпляра одного и того же демона работали на одной машине (используя разные порты сетевого протокола), когда одна машина выйдет из строя. Чтобы экземпляр BeeGFS даемона обхода отказа выглядел как оригинальный демон, вам также нужно будет переместить IP адреса на машину обхода отказа и убедиться, что экземпляр даемона обхода отказа использует тот же самый NodeID на узле обхода отказа. (Смотрите раздел «Конфигурация и настройка» на этой странице для информации о том, как вручную определить NodeID вместо того, чтобы использовать имя хоста в качестве NodeID). Обратите внимание, что вики содержит больше подробностей на эту тему.

• Является ли BeeGFS проектом с открытым исходным кодом?

Да

• Что означает аббревиатура FhGFS?

FhGFS — это старое название BeeGFS, которое теперь называется в честь милых и занятых животных, которые работают вместе как рой и выполняют свою важную работу, по большей части незаметно на заднем плане.

FhG: Немецкое название Общества Фраунгофера — Fraunhofer Gesellschaft, его официальная аббревиатура — FhG. FS: FS — сокращение от File System.

Примечание: Так как значение буквы G в FhGFS не всегда очевидно, некоторые люди начали называть FhGFS Fraunhofer Global File System или Fraunhofer GFS, а иногда даже просто Fraunhofer.

• Как BeeGFS распределяет метаданные?

BeeGFS распределяет метаданные по каждому каталогу. Это означает, что каждый каталог в вашей файловой системе может управляться различным сервером метаданных. Когда создается новый каталог, система автоматически выбирает один из доступных серверов метаданных, чтобы обеспечить ответственность за файлы внутри этого каталога. Новые подкаталоги этой директории могут быть назначены другим серверам метаданных, поэтому нагрузка распределяется между всеми доступными серверами метаданных.

• Как создавать резервные копии метаданных?

Поскольку расширенные атрибуты обычно не копируются по умолчанию многими инструментами резервного копирования, вот три различных способа резервного копирования метаданных, которые хранятся в расширенных атрибутах. Однако следует помнить, что это всего лишь примеры. Другие инструменты, такие как rsync, также имеют опции сохранения расширенных атрибутов и жестких ссылок, и поэтому их можно использовать для резервного копирования метаданных BeeGFS.

Обратите внимание, что начиная с версии 2012.10, метаданные BeeGFS также используют жесткие ссылки в базовой файловой системе. Важно, чтобы эти жесткие ссылки сохранялись при резервном копировании и восстановлении метаданных.

Метод 1: Использование GNU tar без поддержки расширенных атрибутов Более старые версии GNU tar не поддерживали расширенные атрибуты, поэтому требуется два шага резервного копирования метаданных с помощью tar и getfattr.

Резервное копирование данных:

$ cd /path/to/beegfs/meta_parent_dir
$ tar czvf /path/to/archive/meta.tar.gz metadir/
$ getfattr -R -d -P metadir/ > /path/to/archive/e

Восстановление бэкапа:

$ cd /path/to/beegfs/meta_parent_dir
$ tar xvf /path/archive/meta.tar.gz 
$ setfattr --restore=/path/to/archive/ea.bak

Метод 2: Использование GNU tar с поддержкой расширенных атрибутов Последние версии tar GNU поддерживают расширенные атрибуты, версии RHEL6 tar исправлены для поддержки резервного копирования расширенных атрибутов. На RHEL следует использовать, по крайней мере, версии tar-1.23-7.el6 (RHEL6.3). Более ранние версии RHEL tar имеют серьезную ошибку, которая сделает невозможным восстановление резервных копий.

Резервное копирование данных:

$ cd /path/to/beegfs/meta_parent_dir
$ tar czvf /path/to/archive/meta.tar.gz metadir/ --xattrs

Восстановление бэкапа:

$ cd /path/to/beegfs/meta_parent_dir
$ tar xvf /path/to/archive/meta.tar.gz --xattrs

Метод 3: Использование star (http://freecode.com/projects/star) star — это альтернатива GNU tar, которая поддерживает резервное копирование расширенных атрибутов. Резервное копирование данных:

$ cd /path/to/beegfs/meta_parent_dir
$ star czv artype=exustar -xattr -f /path/to/archive/meta.tar.gz metadir/ 

Восстановление бэкапа:

$ cd /path/to/beegfs/meta_parent_dir
$ star xzv -xattr -f /path/to/archive/meta.tar.gz metadir/

Если вы выполняете резервное копирование, например, еженедельно во время доступа пользователей к файловой системе BeeGFS, вам следует запустить beegfs-fsck после этого, чтобы устранить любые несоответствия. Если вы запускаете резервное копирование для перемещения метаданных на другую машину или на разные диски, рекомендуется остановить службы BeeGFS перед запуском резервного копирования, чтобы избежать несогласованности в файлах метаданных, которые изменяются во время запуска резервного копирования.

Дополнительные примечания: Чтобы сократить общее время выполнения, вы можете использовать инструмент резервного копирования в сочетании с другими инструментами, такими как «xargs» (см. параметр «—max-procs») или «GNU parallel», для параллельного запуска нескольких процессов, каждый из которых находится в подмножестве структуры каталогов. Чтобы удостовериться в том, что EAs были зарезервированы, рекомендуется проверить, что вышеприведенные команды работают в вашей среде. Этот тест можно выполнить с помощью поддиректории (например, metadir/inodes/1D/4F/), чтобы проверить, работает ли резервное копирование и восстановление этой директории. Восстановленные данные должны быть протестированы с помощью ‘getfattr -d metadir/inodes/1D/4F/some_file’, чтобы проверить, не содержат ли эти файлы расширенные атрибуты BeeGFS. Счетчик жестких ссылок файла метаданных можно проверить с помощью утилиты stat (например, stat metadir/dentries/…/some_file), которая покажет счетчик ссылок больше 1, если файл имеет жесткие ссылки.

• Как добавить новый узел хранения или узел метаданных?

Добавление нового узла в BeeGFS очень просто и не требует остановки работы. Вам просто необходимо выполнить следующие шаги. Пожалуйста, прочитайте всю процедуру перед тем, как предпринимать какие-либо действия.

Во-первых, убедитесь, что в файле /etc/beegfs/beegfs-mgmtd.conf следующие свойства установлены на «true», чтобы служба управления могла добавлять новые узлы и цели в систему. Подробная документация по этим свойствам находится в нижней части файла.

sysAllowNewServers = true

sysAllowNewTargets = true

Если вы измените эти свойства, вам необходимо перезапустите службу управления после этого.

$ service beegfs-mgmtd restart

После этого установите пакеты BeeGFS на новом узле и настройте службы, как описано в процедуре установки.

Теперь запустите службу.

$ service beegfs-storage start

Теперь используйте команду beegfs-check-servers, чтобы перечислить узлы сервера в вашей системе и проверить, есть ли в списке ваш новый узел. Если нет, проверьте лог-файлы добавленной службы и службы управления на предмет сообщений об ошибках, указывающих на невозможность добавления узла.

$ less /var/log/beegfs-mgmtd.log
$ less /var/log/beegfs-meta.log
$ less /var/log/beegfs-storage.log

Установите свойства управления обратно в false, чтобы предотвратить случайные регистрации новых узлов и целей в вашей системе. Перезапустите службу управления после этого.

sysAllowNewServers = false

sysAllowNewTargets = false

• Как добавить новую цель хранения?

Добавление нового целевого хранилища в BeeGFS очень просто и не требует остановки работы. Вам необходимо выполнить следующие шаги. Пожалуйста, прочитайте всю процедуру перед тем, как предпринять какие-либо действия. Во-первых, убедитесь, что в файле /etc/beegfs/beegfs-mgmtd.conf следующее свойство установлено в true, чтобы служба управления могла добавлять новые цели в систему. Подробная документация по этому свойству находится в нижней части файла.

sysAllowNewTargets = true

Если вы измените свойство, перезапустите службу управления после этого.

$ service beegfs-mgmtd restart

После этого добавьте цель хранилища на сервер хранения, как описано в процедуре установки.

Теперь перезапустите службу хранения.

$ service beegfs-storage restart

Далее, используйте команду beegfs-df, чтобы перечислить все узлы и цели в вашей системе и проверить, есть ли в списке ваша новая цель. Если нет, проверьте лог-файлы добавленной службы и службы управления на предмет сообщений об ошибках, указывающих на то, что узел не может быть добавлен.

$ less /var/log/beegfs-mgmtd.log
$ less /var/log/beegfs-storage.log

Верните свойство управления обратно в состояние false, чтобы предотвратить случайные регистрации новых целей в вашей системе. Перезапустите службу управления после этого.

sysAllowNewTargets = false

• Как переместить цель хранения на другой сервер?

Пожалуйста, прочитайте всю процедуру, прежде чем предпринимать какие-либо действия. Во-первых, мы предполагаем наличие времени простоя, чтобы перенести объект хранения на новый сервер!

Отредактируйте файл /etc/beegfs/beegfs-storage.conf на текущей машине и удалите путь к перемещаемой цели хранения из разделенного запятыми списка каталогов целей хранения, заданного опцией storeStorageDirectory. Если служба настроена на работу в multi-mode режиме, будьте внимательны при использовании конфигурационного файла и каталога нужного экземпляра.

Остановите сервис хранения на текущем оборудовании и отмонтируйте целевое устройство хранения данных.

$ service beegfs-storage stop
$ umount /data/mydisk

Запустите службу хранения после этого, если у нее есть другие цели для хранения. Если вам не нужна работающая на машине служба хранения, удалите ее.

$ service beegfs-storage start

Проверьте, установлен ли сервис хранения на новой машине. Если нет, пожалуйста, установите его. Не запускайте сервис на данном этапе. Если служба хранения уже установлена на новой машине сервера и до перемещения у вас было несколько экземпляров службы, запущенных на разных машинах, а теперь вы хотите, чтобы на одной машине работало 2 экземпляра службы, каждый из которых использует свой ID узла, настройте службу на работу в multi-mode режиме.

Если вы не возражаете против того, чтобы цель хранения ассоциировалась с ID узла, используемого новым сервером, вам не нужно настраивать службу хранения на работу в multi-mode режиме. Позже, на следующем шаге этой процедуры, вы сможете просто добавить цели хранилища к существующему экземпляру службы хранения. Настройте службу на multi-mode режим только в том случае, если вы действительно хотите, чтобы перемещенная цель хранилища была связана с предыдущим ID узла.

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

В противном случае, если целевое устройство хранения нельзя переместить или подключить к новой машине, скопируйте данные из резервной копии (или с устройства, смонтированного в другом месте) на устройство хранения на новой машине.

Затем отредактируйте файл /etc/beegfs/beegfs-storage.conf на новой машине и добавьте путь перемещенного целевого устройства хранения в разделенный запятыми список каталогов целевого устройства хранения, заданный опцией storeStorageDirectory. Если служба настроена на работу в многорежимном режиме, будьте внимательны при использовании конфигурационного файла и каталога нужного экземпляра.

Убедитесь, что в служебном каталоге содержится правильный файл nodeID. Если вы перемещаете целевой каталог хранилища на машину, на которой уже запущена служба хранения и эта служба не находится в multi-mode режиме, удалите все файлы, имена которых соответствуют шаблонам nodeID и NodeID, расположенным в перемещаемом целевом каталоге хранилища. Это заставит службу хранения заново создать эти файлы с ID узла, используемым существующим демоном службы хранения.

В любом другом случае, убедитесь, что nodeID файлового узла существует в каталоге службы и что он содержит ID, который демон службы хранения должен использовать для идентификации себя со службой управления. Если файл не существует, просто создайте его с тем же содержимым файла originalNodeID.

Запустите или перезапустите службу хранения.

$ service beegfs-storage restart

Проверьте, правильно ли работает цель. Проверьте, не содержат ли лог-файлы сообщений об ошибках.

$ less /var/log/beegfs-mgmtd.log
$ less /var/log/beegfs-meta.log
$ less /var/log/beegfs-storage.log
$ less /var/log/beegfs-client.log

Просмотрите список всех целей хранения в вашей системе и убедитесь, что перемещенный объект отображается в режиме онлайн.

$ beegfs-ctl --listtargets --longnodes --state

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

$ beegfs-ctl --removenode <NodeID>

• Как переместить цель метаданных на другой сервер?

Для перемещения цели метаданных на другую машину выполните следующие шаги. Пожалуйста, прочитайте всю процедуру, прежде чем предпринимать какие-либо действия. В этом описании основное внимание уделяется переносу устройства хранения с одного сервера на другой, но можно использовать резервную копию. Если вы собираетесь переместить цель метаданных с помощью резервного копирования, ознакомьтесь с инструкциями по резервному копированию метаданных. Во-первых, мы предлагаем остановить сервер, чтобы перенести цель метаданных на новый сервер!

Остановите службу метаданных на текущей машине и отмонтируйте целевое устройство для метаданных. Если служба настроена на работу в multi-mode режиме, будьте внимательны, чтобы остановить нужный экземпляр.

$ service beegfs-meta stop
$ umount /data/ssd

Если вам не нужен сервис метаданных, работающая на текущей машине, удалите его.

Проверьте, можно ли переместить или подключить целевое устройство с метаданными к новой машине. Если да, смонтируйте его в каталог новой машины и убедитесь, что оно настроено на монтирование во время загрузки.

В противном случае, если целевое устройство с метаданными не может быть перемещено или подключено к новой машине, скопируйте данные из резервной копии (или с устройства, смонтированного в другом месте) на устройство хранения на новой машине.

Проверьте, установлена ли служба метаданных на новой машине. Если нет, установите ее. Если служба метаданных уже установлена на новой машине, настройте ее на работу в multi-mode режиме. Не запускайте службу на данном этапе.

Затем отредактируйте файл /etc/beegfs/beegfs-meta.conf на новой машине и добавьте путь к перемещенной цели метаданных в опцию storeStorageDirectory. Если служба настроена на работу в multi-mode режиме, будьте внимательны при использовании конфигурационного файла и каталога нужного экземпляра.

Убедитесь, что nodeID существует в каталоге службы и что он содержит ID, который демон службы метаданных должен использовать для идентификации себя со службой управления. Если файл не существует, просто создайте его с тем же содержимым файла originalNodeID.

Запустите или перезапустите службу метаданных.

$ service beegfs-meta restart

Проверьте, правильно ли работает цель. Проверьте, не содержат ли лог-файлы сообщений об ошибках.

$ less /var/log/beegfs-mgmtd.log
$ less /var/log/beegfs-meta.log
$ less /var/log/beegfs-storage.log
$ less /var/log/beegfs-client.log

Перечислите все узлы метаданных вашей системы и проверьте, появляется ли перемещенный узел в сети.

$ beegfs-ctl —listnodes —nodetype=meta —reachable

• Как перенести службу управления на другой сервер?

Для перемещения службы управления на другую машину выполните следующие шаги. Пожалуйста, прочитайте всю процедуру, прежде чем предпринимать какие-либо действия. Во-первых, мы предлагаем переместить объект управления на новый сервер!

Остановите службу управления на текущем компьютере. Если служба настроена на работу в multi-mode режиме, будьте внимательны, чтобы остановить нужный экземпляр.

$ service beegfs-mgmtd stop
$ umount /data/ssd

Если вам не нужна служба управления, работающая на текущей машине, удалите ее.

Проверьте, можно ли переместить или подключить к новой машине запоминающее устройство, на котором находится директория управления. Если да, то размонтируйте его, переместите, смонтируйте в каталог на новой машине и убедитесь, что оно настроено на монтирование во время загрузки. Каталог управления определяется опцией storeMgmtdDirectory в файле /etc/beegfs/beegfs-mgmtd.conf.

В противном случае, если устройство не может быть перемещено или подключено к новой машине, скопируйте каталог управления из резервной копии (или с устройства, смонтированного где-нибудь еще) в раздел новой машины.

Проверьте, установлена ли уже служба управления на новой машине. Если нет, установите ее. Не запускайте службу на данном этапе. Если служба управления уже установлена на новой машине сервера, настройте работу службы в multi-mode режиме.

Затем отредактируйте файл /etc/beegfs/beegfs-mgmtd.conf на новой машине и установите параметр storeMgmtdDirectory в путь к каталогу службы управления. Если служба настроена на работу в multi-mode режиме, будьте внимательны при использовании конфигурационного файла и каталога нужного экземпляра.

Убедитесь, что файл nodeID существует в каталоге службы и что он содержит идентификатор, который демон службы управления должен использовать для самоидентификации. Если файл не существует, просто создайте его с тем же содержимым файла originalNodeID.

Если новая машина имеет другое имя хоста, отредактируйте файл конфигурации друг друга BeeGFS-службы, запущенной в вашей системе, которые связаны с этой службой управления, и запишите новое имя хоста в качестве значения опции sysMgmtdHost.

Убедитесь, что новая машина доступна с других серверов BeeGFS, особенно если вы используете опции конфигурации клиента connInterfacesFile или connNetFilterFile для ограничения того, какие сетевые интерфейсы могут использоваться службами BeeGFS. Его IP-адрес может быть изменен свободно, потому что BeeGFS не хранит записи о таких адресах.

Запустите или перезапустите службу управления.

$ service beegfs-mgmtd restart

Проверьте, правильно ли работает цель. Проверьте, не содержат ли лог-файлы сообщений об ошибках.

$ less /var/log/beegfs-mgmtd.log
$ less /var/log/beegfs-meta.log
$ less /var/log/beegfs-storage.log
$ less /var/log/beegfs-client.log

Перечислите все узлы системы управления и проверьте, появляется ли перемещенный узел в сети.

$ beegfs-ctl --listnodes --nodetype=mgmt --reachable

• Могу ли я экспортировать BeeGFS через Samba/CIFS для подключения хостов Windows?

Да, можете. Пожалуйста, выполните следующие шаги. Настройте клиентский хост BeeGFS на сервер Samba. Убедитесь, что вы используете, по крайней мере: BeeGFS 2015.03-r12, который содержит оптимизации для Samba, и Samba 4.2, которая содержит оптимизации для BeeGFS.

Добавьте определение ресурса в файл /etc/samba/smb.conf для точки монтирования BeeGFS, как показано в примере ниже. Для получения дополнительной информации об этих опциях обратитесь к документации по Samba.

[beegfs]
comment = BeeGFS file system
public = yes
path = /mnt/beegfs
browsable = yes
writable = yes
read only = no

Перезапустите службу samba-сервера. Теперь у вас должен быть доступ к файловой системе BeeGFS с клиента Samba.

В случае, если вы настраиваете кластер Samba, выполните следующие дополнительные шаги.

Добавьте следующие определения в файл /etc/samba/smb.conf.

[global]
...
clustering = yes
netbios name = BeeGFS *
clustering = yes
...
idmap config * : backend = autorid
idmap config * : range = 1000000-1999999
...
vfs objects = fileid
fileid:algorithm = fsid
​
[BeeGFS]
...
strict locking = yes
kernel oplocks = yes
blocking locks = yes
mmap = no

При настройке CTDB менеджера кластера добавьте следующие параметры в файл /etc/default/ctdb.

CTDB_RECOVERY_LOCK=/mnt/beegfs/.ctdb/reclock
CTDB_NODES=/etc/ctdb/nodes
CTDB_PUBLIC_ADDRESSES=/etc/ctdb/public_addresses
CTDB_MANAGES_SAMBA=yes
CTDB_SERVICE_SMB=smbd
CTDB_SERVICE_NMB=nmbd

Для версий Samba > 4.8 опция блокировки восстановления CTDP_RECOVERY_LOCK переносится в /etc/samba/smb.conf, где должна быть добавлена следующая запись:

[cluster]
recovery lock = /mnt/beegfs/.ctdb/reclock

Включите глобальный файл и добавьте блокировки в BeeGFS, изменив следующие опции в файле конфигурации клиента BeeGFS /etc/beegfs/beegfs-client.conf.

tuneUseGlobalAppendLocks = true
tuneUseGlobalFileLocks = true

Настройте файлы /etc/ctdb/nodes и /etc/ctdb/public_adresses в соответствии с окружением.

Подсказки

Рассмотрим возможность экспорта BeeGFS через NFS, которая обычно имеет лучшую производительность, чем Samba и поддерживается последними версиями Windows.

Если вы используете Windows Samba клиентов, подумайте о добавлении опции, чувствительной к регистру = true к определению ресурса, приведенному выше, чтобы сделать BeeGFS экспорт чувствительным к регистру. Эта настройка положительно влияет на производительность клиента, так как поиск без учета регистра выполняет меньше системных вызовов экспортируемой файловой системы.

Другим способом улучшения производительности Windows клиентов, но сохранения регистронезависимости BeeGFS для имен файлов ASCII, является хранение метаданных BeeGFS в регистронезависимом XFS разделе, отформатированном с помощью команды mkfs.xfs с опцией -n version=ci, как показано в примере ниже. Это позволяет установить опцию Samba, чувствительную к регистру = true, как предлагалось выше, чтобы Samba выполняла меньше syscalls в экспортируемой файловой системе. Однако это означает, что все имена файлов не зависят от регистра, даже для клиентов Linux.

$ mkfs.xfs -d su=128k,sw=8 -l version=2,su=128k -isize=512 -n version=ci /dev/sdx -f

• Могу ли я экспортировать BeeGFS через NFS?

Да, можете. Начиная с релиза 2014.01, BeeGFS поддерживает экспорт NFS-серверов ядра Linux. Для предыдущей версии рекомендуется использовать unfs3 для экспорта BeeGFS через NFS 3.

Для обслуживания файлов через NFS, настройте клиентский хост BeeGFS в качестве сервера NFS и реэкспортируйте точку монтирования клиента BeeGFS через NFS. На системе NFS-сервера установите следующую опцию beegfs-client.conf, чтобы убедиться, что атрибуты файлов обновлялись также и по дополнительным кодовым путям, таким как NFS-сервер:

tuneRefreshOnGetAttr = true

Пример экспорта NFSv4 для сервера ядра NFS в файле /etc/exports:

/mnt/beegfs      *(rw,async,fsid=0,crossmnt,no_subtree_check,no_root_squash)

Пример монтирования NFSv4:

$ mount -t nfs -overs=4 myserver:/ /mnt/beegfs_via_nfs/

Перед запуском ядра NFS-сервера и подключением клиента NFS отключите аренду файлов NFSv4, чтобы убедиться, что NFS не держит файлы открытыми после того, как они были фактически закрыты приложением:

$ sysctl -w fs.leases-enable=0

Чтобы аренда файлов NFSv4 также постоянно отключалась после перезагрузки сервера, добавьте следующую строку в /etc/sysctl.conf:

fs.leases-enable = 0

Убедитесь, что NFS-сервер запущен после клиента BeeGFS. Если вы используете systemd, добавить этот файл в /etc/systemd/system/multi-user.target.wants/beegfs-client.service:

Before=nfs-server.service

и запустить:

 systemctl daemon-reload

Важные примечания

Ядро NFSv3 имеет некоторые ограничения, которые не позволяют BeeGFS поддерживать его. Например, клиенты NFS обмениваются cookies с серверами для идентификации файлов, когда они больше не находятся в кэше сервера. Максимальный размер таких куки-файлов в NFS 3 слишком мал для кодирования входной информации поиска BeeGFS. В NFS 4 максимальный размер куки-файлов был увеличен, что позволило BeeGFS использовать куки-файлы NFS. Хотя экспорт ядра NFS 3 может иногда работать в вашей системе, в конечном счете, он может не работать, как только используются cookies (т.е. когда NFS сервер начинает выгружать записи из своего кэша, и информация о cookies необходима для поиска.) Поэтому убедитесь, что вы используете ядро NFS версии 4.

Хорошей идеей является ограничение версий протокола NFS, используемых в вашей системе, как описано в разделе A4 документации по NFS. Лучший способ сделать это — добавить определение RPCMOUNTDOPTS=»—no-nfs-version 3″ в файл /etc/sysconfig/nfs, который читается скриптом /etc/rc.d/init.d/nfs.

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

• Имеет ли BeeGFS ограничение на максимальное количество групп на пользователя?

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

• Поддерживает ли BeeGFS hardlinks?

В BeeGFS v7 и более ранних версиях, hardlinks поддерживаются только в каталоге, а не в других директориях.

• Поддерживает ли BeeGFS MPI-IO?

Да, BeeGFS поддерживает MPI-IO. Для использования MPI-IO на BeeGFS не требуется никаких специальных действий, это будет просто работать из коробки.

• Где я могу найти информацию о том, почему установка BeeGFS на базе Admon дает сбой?

Если вы попытались установить BeeGFS с помощью графического интерфейса администрирования и мониторинга, есть два средства журналирования, которые могут дать полезную информацию: Журнал установки на сервере: Вы можете прочитать его, выбрав «Installation» -> «Installation Log File» в графическом интерфейсе. Лог-файл Java GUI: Этот лог-файл хранится в каталоге «.beegfs внутри вашего домашнего каталога (beegfs-admon-gui.log).

• Мы не используем один из дистрибутивов, для которых вы предоставляете пакеты. Что мы можем сделать, чтобы попробовать BeeGFS?

Если вам нужны двоичные файлы и вы не можете установить доступные BeeGFS rpm или deb-пакеты напрямую, вы можете попробовать скачать rpm-пакеты для Suse или Red Hat и распаковать их с помощью rpm2cpio и cpio (rpm2cpio packname | cpio -i).

Или вы можете просто собрать BeeGFS из исходных текстов: Source

• Нужно ли мне быть » root «, чтобы запустить BeeGFS?

Да и нет. Вам не нужен корневой доступ для запуска серверов, так как это все процессы в пользовательском пространстве (конечно, вам нужно изменить конфигурационные файлы, чтобы хранить данные файловой системы и файлы журналов в местах, где у вас есть доступ на запись). Клиент — это модуль ядра. Для загрузки модуля и монтирования файловой системы обычно требуется наличие привилегий root. В качестве альтернативы можно также дать права на выполнение соответствующих команд для не root-пользователей через /etc/sudoers.

• Возможно ли запускать серверы хранения и клиентов на одной машине?

Да, возможно. Вам не нужны выделенные хосты для какого-либо сервиса в BeeGFS. Например, можно иметь один хост, на котором одновременно работают демон управления, сервер метаданных, сервер хранения и клиент.

• Возможно ли запустить несколько экземпляров службы BeeGFS на одной машине?

Да, возможно. Пожалуйста, ознакомьтесь с разделом MultiMode для получения подробной информации.

Если Вы используете BeeGFS версии 7 или новее и Ваша система использует systemd, шаблоны сервисов используются для управления в нескольких случаях. Init-скрипты не используются при установке systemd.

Начиная с версии 2012.10, стандартные init-скрипты службы BeeGFS (/etc/init.d/beegfs-XY) могут управлять несколькими экземплярами одного демона на машине. Чтобы включить поддержку этого, обратитесь к комментарию к MULTI_MODE в файле /etc/default/beegfs-XY.

Для MultiMode режима вам нужно будет создать отдельный конфигурационный файл для другого экземпляра даемона, используя различные сетевые порты, другой каталог хранения, другой лог-файл и так далее. Если второй даемон на машине должен стать частью одного и того же экземпляра файловой системы (т.е. он регистрируется на том же даемоне управления, что и первый демон на этой машине), то вам также нужно будет вручную задать другой NodeID для второго демона. (Смотрите раздел «Конфигурация и настройка» на этой странице для информации о том, как вручную установить NodeID).

Для клиента также доступен MultiMode режим, но файл конфигурации монтирования клиента (/etc/beegfs/beegfs-mounts.conf) также позволяет указать несколько точек монтирования без включенного MultiMode режима, добавив одну или несколько дополнительных строк точки монтирования и соответствующий файл конфигурации клиента. (Замечание: Убедитесь, что в разных клиентских конфигурационных файлах указаны разные клиентские порты).

Скрипт BeeGFS-on-demand (/opt/beegfs/sbin/beegfs-ondemand-v2) из пакета beegfs-utils является еще одним возможным способом запуска отдельного экземпляра BeeGFS, особенно для кластеров или в облачных средах.

• Возможно ли, чтобы службы BeeGFS и FhGFS работали на одних и тех же машинах?

Да, возможно. Это особенно полезно в сценариях обновления, где новая система должна некоторое время сосуществовать со старой системой.

Каждая версия будет работать как отдельный экземпляр файловой системы, и их соответствующие службы не смогут взаимодействовать друг с другом. Они будут иметь различные конфигурационные файлы (расположенные в /etc/fhgfs и /etc/beegfs), различные сценарии запуска (например: /etc/init.d/fhgfs-client и /etc/init.d/beegfs-client), различные команды (например: fhgfs-ctl и beegfs-ctl), и, конечно, должны быть смонтированы клиентами по разным путям (по умолчанию: /mnt/fhgfs и /mnt/beegfs).

После установки пакетов новой версии убедитесь, что порты, используемые службами одного экземпляра, отличаются от портов, используемых службами другого экземпляра. Эти порты определены в верхней части конфигурационного файла каждого сервиса. Например, в файле /etc/beegfs/beegfs-client.conf вам придется изменить опции connClientPortUDP и connHelperdPortTCP, чтобы предотвратить попытки beegfs-client и beegfs-helperd использовать те же порты, что и fhgfs-client и fhgfs-helperd.

Альтернативно, вместо того, чтобы менять каждый порт по отдельности, вы можете использовать опцию connPortShift, чтобы сдвинуть все порты, определенные в конфигурационном файле одновременно, в соответствии с заданным значением.

Обратите внимание, что установка новой версии не требует остановки сервисов старой версии. Таким образом, простой не требуется.

• Нужно ли мне специальное ядро Linux для BeeGFS?

Клиентские модули BeeGFS до версии 7.1 требуют как минимум ядро версии 2.6.18, кроме этого, BeeGFS не нуждается в специальном ядре: Клиентские модули ядра были разработаны без патчей (так что вам не нужно применять патчи ядра и даже не нужно перезагружаться для установки и запуска клиента BeeGFS), а серверные компоненты BeeGFS работают как демоны пользовательского пространства, так что они не зависят от версии ядра.

Начиная с версии BeeGFS 7.2, вводится новая политика поддержки ядра. Мы поддерживаем только последние ядра LTS, а также те, которые поставляются с официальными дистрибутивами, которые мы поддерживаем (это RHEL/CentOS, SLES, Debian и Ubuntu). Это даёт несколько преимуществ:

Значительно урезанный список ядер позволяет команде разработчиков сосредоточиться на поддерживаемых ядрах и убедиться, что они действительно работают. В отличие от предыдущих случаев, каждый из них может быть тщательно протестирован. Множество условного кода в модуле ядра может быть удалено, что повышает качество кода и облегчает сопровождение. Мы можем поставлять модуль как бинарный, так что весь процесс компиляции-on-startup может закончиться. Это также означает, что вам больше не придётся устанавливать пакеты разработки. Менеджер пакетов заботится о зависимостях, автоматически выбирает нужную версию и гарантирует, что вы никогда не нарушите работу клиента, обновив что-нибудь до неподдерживаемой версии (например, ядро).

В случае, если вы хотите использовать другое ядро, мы предоставляем набор инструментов, чтобы скомпилировать его самостоятельно. Однако самостоятельно скомпилированные ядра нами не поддерживаются.

• Нужна ли BeeGFS синхронизация времени между разными машинами?

Да, время всех клиентских и серверных машин BeeGFS должно быть синхронизировано по разным причинам, например, для обеспечения последовательных временных меток изменения файлов и для последовательной генерации ID. Убедитесь, что все серверные часы установлены на правильное время и дату (например, с date или ntpdate) перед запуском сервисов BeeGFS. Такой сервис, как ntp, может затем использоваться для синхронизации часов всех машин.

• Как обновить службу BeeGFS до более новой минорной версии?

Для обновления сервиса BeeGFS в рамках мажорного релиза до более новой минорной версии, например, с 6.2 до 6.3, необходимо всего два шага. (1) Обновление службы BeeGFS (рекомендуемый способ — это обновление с помощью менеджера пакетов вашего дистрибутива linux), (2) Перезапустите службу BeeGFS. Если у вас включено buddy mirroring, мы рекомендуем использовать следующую последовательность, чтобы избежать ненужных обходов отказа или повторной синхронизации (выполнение шагов (2) — (4) быстро один за другим, но не одновременно): (1) Обновите пакет на обоих узлах, (2) остановить демона на первичном узле, (3) перезапустите демона на вторичном узле, (4) запустить демона на первичном узле. Всегда полезно взглянуть на файл изменений перед обновлением. В пределах одной основной версии BeeGFS, различные второстепенные версии могут использоваться вместе в системе BeeGFS. Хотя нет необходимости в простое, рекомендуется перезапускать службу, когда нагрузка не очень высока.

• Могу ли я выполнить обновление непосредственно с версии 2014.01 до версии 6.x?

Пропущенные мажорные релизы не проходят тщательного тестирования, поэтому мы рекомендуем сначала обновиться до релиза 2015.03. Но не волнуйтесь, промежуточный шаг обновления прост. После обновления служб beegfs-mgmtd, beegfs-meta, beegfs-storage (и опционального beegfs-admon) до релиза 2015.03 обновите также пакеты BeeGFS одного клиентского узла до релиза 2015.03 (beegfs-client, beegfs-helperd, beegfs-utils). Затем проверьте на этом клиентском узле, что следующие команды возвращают ожидаемый результат без каких-либо сообщений об ошибках:

$ beegfs-check-servers
$ beegfs-df
$ beegfs-ctl --listtargets --state --nodetype=meta
$ beegfs-ctl --listtargets --state --nodetype=storage

Теперь вы можете остановить службы BeeGFS и перейти к обновлению до версии 6.x (остальные клиентские узлы могут быть обновлены непосредственно с версии 2014.01 до версии v6).

• Почему я получаю ошибку ‘Access denied’ на клиенте даже с правильными разрешениями?

Пожалуйста, проверьте, включен ли SELinux на клиентской машине. Если он включен, отключение должно решить вашу проблему. SELinux можно отключить, установив SELINUX=disabled в файле конфигурации /etc/selinux/config. После этого, возможно, вам понадобится перезагрузить ваш клиент, чтобы новая настройка вступила в силу.

• Как настроить BeeGFS на использование ACL?

В BeeGFS списки контроля доступа (ACL) хранятся в виде расширенных атрибутов файлов метаданных. Поэтому вам нужно убедиться, что расширенные атрибуты включены в базовые файловые системы служб метаданных. Например, в файловой системе ext4 опции, используемые для монтирования устройств хранения, должны включать user_xattr. Тем не менее, в последних дистрибутивах Linux этот параметр устанавливается по умолчанию при монтировании файловых систем, поддерживающих расширенные атрибуты.

Кроме того, на клиентских узлах необходимо запускать ядро Linux версии 3.1 или выше. Средства внедрения ACL, необходимые BeeGFS, не поддерживаются более старыми версиями ядра.

После этого убедитесь, что используете, по крайней мере, BeeGFS версии 2015.03-r13, которая полностью поддерживает ACL. Затем отредактируйте файл конфигурации метаданных (/etc/beegfs/beegfs-meta.conf) и проверьте, установлены ли следующие опции в true.

storeUseExtendedAttribs = true
storeClientXAttrs       = true
storeClientACLs         = true

По умолчанию опция storeUseExtendedAttribs установлена в true во время установки. Этот параметр можно изменить только перед первым запуском службы, в то время как параметры storeClientXAttrs и storeClientACLs также могут быть включены позже.

Затем отредактируйте файл конфигурации клиента (/etc/beegfs/beegfs-client.conf) и проверьте, установлено ли значение true для следующих опций.

sysXAttrsEnabled = true
sysACLsEnabled   = true  

При изменении конфигурационных файлов не забудьте после этого перезапустить соответствующие службы.

• Сколько дискового пространства требуется для метаданных?

Это зависит от таких вещей, как средний размер файла, который у вас есть, или от того, сколько файлов вы хотите создать в общей сложности.

В общем, мы рекомендуем иметь от 0,3% до 0,5% от общего объема памяти для метаданных. Однако это число основано на собранной статистике файловых систем на разных кластерных сайтах и, таким образом, может подходить, а может и не подходить для вашего случая. Иногда это также слишком много, поэтому, возможно, вы захотите начать с меньшего объема метаданных и просто быть готовым добавить больше объема метаданных, если он действительно понадобится позже.

Как правило, 500 ГБ емкости метаданных достаточно для примерно 150 миллионов файлов, если базовое хранилище метаданных отформатировано с помощью ext4 в соответствии с рекомендациями руководства по настройке сервера метаданных: Настройка сервера метаданных

Если говорить точнее, для каждого файла, который создает пользователь, на одном из серверов метаданных создается один файл метаданных. Для каждой создаваемой пользователем директории на одном из серверов метаданных создаются две директории и два файла метаданных.

Для файловых метаданных, если базовая файловая система локального сервера метаданных (например, ext4) отформатирована в соответствии с нашими рекомендациями с большими inodes (например, «mkfs.ext4 -I 512», как описано а разделе: Metadata Server Tuning), то метаданные BeeGFS в качестве расширенного атрибута полностью вписываются в inode базовой локальной файловой системы и не используют никакого дополнительного дискового пространства. Если базовая файловая система метаданных сервера не отформатирована с большими inodes, то базовая локальная файловая система должна выделить полный блок (обычно 4KB) для хранения информации о метаданных BeeGFS в дополнение к использованию одного inode.

Списки контроля доступа (ACL) и пользовательские расширенные атрибуты также хранятся как расширенные атрибуты в соответствующих файлах метаданных и, таким образом, добавляются в требуемое дисковое пространство, в зависимости от того, вписываются ли они все еще в узел или требуется выделить новый блок.

Для каждой директории в базовой локальной файловой системе используется один блок содержимого inode и один блок содержимого директории (обычно 4KB) до тех пор, пока в директории не будет столько подзаписей, что базовая файловая система не выделит другой блок содержимого директории. Сколько записей помещается в один блок, зависит от таких вещей, как длина имени файла пользователя, но обычно в один блок директории помещается более 10 записей. Таким образом, если пользователь создает, например, много каталогов, внутри которых находится только один файл, это значительно увеличивает используемое количество узлов и дискового пространства в базовой локальной файловой системе по сравнению с тем случаем, когда такое же количество файлов хранится в меньшем количестве каталогов.

Обратите внимание, что в то время как ext4 обычно рекомендуется для хранения метаданных из-за ее преимуществ в производительности при работе с метаданными BeeGFS по сравнению с другими локальными файловыми системами Linux, xfs имеет преимущество использования динамического числа inodes, что означает, что новые inodes могут создаваться при условии наличия свободного дискового пространства. ext4, с другой стороны, основана на статическом числе максимальное число inodes, которое определяется при форматировании файловой системы с помощью mkfs (например, «mkfs.ext4 -i <number>>»). Таким образом, с ext4 может случиться так, что у вас останется место на диске, но закончатся доступные коды, или наоборот. Используйте «df -ih», чтобы увидеть информацию о доступных inodes для смонтированных файловых систем.

• Сообщение об ошибке BeeGFS 6.18 и RHEL 7.5 (CentOS, SL): Не каталог

Если BeeGFS 6.18 используется на ядре linux, которое начинается с 3.10.0-862, то вы увидите эту ошибку при выполнении %ls%. В этом случае, пожалуйста, обновите версию до последней.

• Клиент BeeGFS версии 6.18 или 7.0 не собирается с драйверами Mellanox OFED 4.3. Что я могу сделать?

Есть патч для этой проблемы, и, нажав сюда вы можете увидеть, как получить и применить этот патч.

• Клиент BeeGFS версии 7.1.2 не собирается с драйверами Mellanox OFED 4.5. Что я могу сделать?

Есть патч для этой проблемы, и, нажав здесь, вы можете увидеть, как получить и применить этот патч.

• Как настроить и использовать клиентский пакет DKMS?

Пожалуйста, ознакомьтесь с документацией по клиентской DKMS для получения более подробной информации.

• Как удалить узел из существующей файловой системы?

Используйте инструмент BeeGFS Control Tool beegfs-ctl (содержащийся в пакете beegfs-utils), если вам необходимо удалить сервер из файловой системы:

$ beegfs-ctl --removenode --nodetype=meta <nodeID>      (for a metadata node)
$ beegfs-ctl --removenode --nodetype=storage <nodeID>   (for a storage node)

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

• Возможно ли освободить объект хранения перед удалением?

Инструмент beegfs-ctl имеет режим, называемый «миграция», который позволяет переместить все файлы с определенной цели хранилища на другие цели хранилища. (Это работает только для целей хранения, а не для целей метаданных).

$ beegfs-ctl --migrate --help

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

Можно запустить несколько невзаимодействующих экземпляров «beegfs-ctl —migrate» на одном и том же клиенте (или разных клиентах) для разных деревьев каталогов, например, один экземпляр для /mnt/beegfs/subdir1 и другой экземпляр для /mnt/beegfs/subdir2.

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

• Могу ли я настроить аутентификацию на основе соединения?

Да, с помощью опции «connAuthFile«, которая может быть установлена в конфигурационных файлах служб BeeGFS. Эта опция определяет pre-shared secret и запросы принимаются только от соединений, которые могут предоставлять pre-shared secret. В этой опции вы можете задать путь к файлу, который может быть любого типа.

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

Создание файла, содержащего pre-shared secret:

$ vi /etc/beegfs/connauthfile
$ cat /etc/beegfs/connauthfile
test_secret

Передайте файл на все хосты в кластере (mgmtd, meta, storage, client, admon, mon).

Отредактируйте все конфигурационные файлы всех сервисов, которые вы в данный момент используете (включая хелперд admon/mon) на всех хостах в кластере и сконфигурируйте «connAuthFile=/etc/beegfs/connauth file» с абсолютным путем/фильмом к файлу, который содержит shared secret

перезапустите службы:

$ systemctl restart beegfs-mgmtd.service
$ systemctl restart beegfs-meta.service
$ systemctl restart beegfs-storage.service
$ systemctl restart beegfs-client.service

После того, как все службы корректно перезапустили, ни один клиент без разделяемого секретного файла не сможет подключиться к кластеру.

Без shared secret mgmtd запишет в логи следующее:

(4) May13 14:49:33 StreamLis [StreamLis] >> Accepted new connection from 192.168.133.7:36082 [SockFD: 32]
(3) May13 14:49:33 DirectWorker1 [Work (process incoming data)] >> Rejecting message from unauthenticated peer: 192.168.133.7:36082
(3) May13 14:49:33 DirectWorker1 [Work (process incoming data)] >> Problem encountered during processing of a message. Disconnecting: 192.168.133.7:36082

• Я провел кое-какие тестирования и хочу начать все сначала. Есть ли простой способ удалить все остатки данных из старой файловой системы?

Чтобы вернуть вашу установку в полностью чистую файловую систему, вы можете выполнить следующие шаги:

Остановить все клиенты и серверы (через графический интерфейс Admon или через /etc/init.d/beegfs-X stop).

Удалить каталоги данных серверов метаданных, серверов хранения и демона управления (это каталоги с именем «store…Directory» в соответствующих файлах конфигурации /etc/beegfs/beegfs-X.conf).

Запустить все сервера и клиентов снова

• У моих хостов есть более одного сетевого интерфейса. Есть ли способ настроить BeeGFS на использование только определенных интерфейсов или определенных сетей?

Да, есть две различные настройки, которые могут быть использованы для этого: В конфигурационном файле каждой службы есть опция под названием connNetFilterFile. Она может быть использована для активации фильтрации на основе диапазона IP-адресов. Эта настройка разрешает попытки исходящих соединений службы BeeGFS только с набором указанных IP-адресов, что полезно, если клиент (или другая служба) не должен пытаться подключиться к определенным IP-адресам экспортируемого интерфейса другого узла, например, потому, что некоторые IP-адреса интерфейса могут быть недоступны из текущей сети или предназначены только для внутреннего использования.

В конфигурационном файле каждой службы есть опция, называемая ConnInterfacesFile. Указав здесь файл со списком интерфейсов (по одному на строку), вы можете контролировать, какие интерфейсы служба BeeGFS регистрирует на демоне управления и в каком порядке их следует пробовать во время попыток подключения другими узлами. Например, если на вашем узле есть eth0 и eth1, но вы добавляете только eth1 в файл интерфейсов, то другие серверы/клиенты не будут знать, что для этого сервера есть другой интерфейс, и, следовательно, не будут пытаться соединиться с другим интерфейсом.

• Возможно ли принудительно установить определенный ID узла или целевой ID для серверов BeeGFS?

Короткий ответ: Да. Используйте соответствующий скрипт настройки каждой службы для ручного определения ID: $ /opt/beegfs/sbin/beegfs-setup-XY (Добавьте аргумент «-h» для справки и примеров использования).

Длинный ответ: Прежде всего, вы должны знать, что BeeGFS использует 2 различных типа идентификаторов для узла сервера.

Идентификатор узла на основе строки. По умолчанию для этого используется имя хоста. Цифровой ID. По умолчанию этот ID последовательно генерируется демоном управления в релизах 2015.x и выше (и случайно генерируется в релизах 2014.x). Цифровые идентификаторы представляют собой 16-битные значения в диапазоне 1..65535.

Идентификатор узла на основе строк наиболее важен для пользователя/администратора, так как именно этот идентификатор вы увидите в лог-сообщениях для удобной идентификации серверов. Но внутри BeeGFS использует числовые ID, в основном потому, что их можно использовать более эффективно.

Каждый демон сервера BeeGFS при запуске проверяет наличие специальных файлов в своей директории хранения. Чтобы заставить определенные ID вместо того, чтобы они генерировались автоматически, вы должны создать эти специальные файлы перед первым запуском демон сервера BeeGFS. Имена этих специальных файлов:

nodeID: string-based node ID

nodeNumID: numeric node ID

targetID: string-based target ID (only for storage server targets)

targetNumID: numeric target ID (only for storage server targets)

Пример: Предположим, вы хотите установить строковый ID узла вашего первого сервера хранения в «storage01», а цифровой ID в «1». Первый сервер хранения также предоставляет первый целевой узел хранения, поэтому вы хотите установить строковый целевой ID на «target01», а цифровой целевой ID на «1». (Каталог storeStorageDirectory в файле /etc/beegfs/beegfs-storage.conf для этого примера установлен в /mnt/myraid/beegfs_storage). Чтобы заставить эти идентификаторы работать, вы должны использовать команды, приведенные ниже, перед первым запуском демона beegfs-storage:

$ echo storage01 > /mnt/myraid/beegfs_storage/nodeID
$ echo 1 > /mnt/myraid/beegfs_storage/nodeNumID
$ echo target01 > /mnt/myraid/beegfs_storage/targetID
$ echo 1 > /mnt/myraid/beegfs_storage/targetNumID

Настройки ID могут быть подтверждены проверкой лог-файла сервера (/var/log/beegfs-storage.log) после запуска демона. Или запросив сервер управления:

$ beegfs-ctl --listnodes --nodetype=storage
$ beegfs-ctl --listtargets --longnodes

Важные примечания: Эти идентификаторы являются неотъемлемой частью всех поисковых систем BeeGFS. Не меняйте идентификаторы после первого запуска демона (иначе BeeGFS не сможет получить данные, сохраненные на основе старого идентификатора). Идентификатор должен быть уникальным только в своем классе. Поэтому демон сервера метаданных и демон сервера хранения могут иметь один и тот же ID узла, но два сервера метаданных (или два сервера хранения) могут не использовать один и тот же ID. Цифровые идентификаторы были введены в серию релизов 2012.10. До этого существовали только строковые ID. Строковые и цифровые идентификаторы тесно связаны друг с другом. Изменить строковый идентификатор при использовании старого цифрового идентификатора невозможно.

• Что нужно делать, когда имя хоста сервера изменилось?

Сценарий: ‘имя хоста’ или ‘$HOSTNAME’ сообщают другое имя, чем во время установки BeeGFS, а серверы BeeGFS отказываются запускаться. Журналы сообщают об изменении имени узла, поэтому запуск был отклонён.

Обратите внимание, что по умолчанию ID узла генерируется на основе имени хоста сервера. Так как ID не могут быть изменены, смотрите здесь информацию о том, как вручную вернуть ваш ID к предыдущему значению: «Можно ли принудительно установить определенный ID узла или целевой ID для серверов BeeGFS?».

• Мой клиент отказывается подключаться из-за «unknown storage target».

Сценарий: При тестировании BeeGFS вы удалили каталог хранилища сервера хранения, но сохранили каталог хранилища сервера управления. Теперь клиент BeeGFS отказывается монтировать и печатает ошибку о неизвестном объекте хранения в лог-файл.

Что случилось с файловой системой: Когда вы запускаете нового демона beegfs-storage с заданным каталогом хранения, демон инициализирует этот каталог, присваивая ID этому целевому пути хранения и регистрируя этот целевой ID на сервере управления. Когда вы удаляете эту директорию, сервер хранилища при следующем запуске создает новую директорию с новым ID и также регистрирует этот ID на сервере управления. (Так как сервер хранения не может знать, что случилось со старой директорией и могли ли вы просто переместить данные на другую машину, поэтому ему нужен новый ID).

Когда клиент начинает, он выполняет проверку на корректность, опрашивая все зарегистрированные ID цели с сервера управления и проверяя, все ли они доступны. Если вы удалили каталог хранилища, то эта проверка не пройдет, и клиент откажется монтировать файловую систему. (Замечание: Эта проверка корректности может быть отключена).

Теперь у вас есть два альтернативных варианта…

Решение А: Просто удалите каталоги хранения всех сервисов BeeGFS, чтобы начать с чистой новой файловой системы:

1) Остановить все серверные демоны BeeGFS, т.е. beegfs-mgmtd, beegfs-meta, beegfs-storage: $ /etc/init.d/beegfs-… stop (или используйте графический интерфейс Admon).

1) Delete («rm -rf«) все каталоги хранения. Пути к каталогам серверного хранилища можно посмотреть в конфигурационных файлах сервера:

storeMgmtdDirectory in config file /etc/beegfs/beegfs-mgmtd.conf

storeMetaDirectory in config file /etc/beegfs/beegfs-meta.conf

storeStorageDirectory in config file /etc/beegfs/beegfs-storage.conf

3) Перезапустите демонов («/etc/init.d/beegfs-… start» или используйте GUI).

Теперь у вас новая файловая система без каких-либо ранее зарегистрированных идентификаторов.

Решение B: Отмените регистрацию недействительного идентификатора цели с сервера управления:

Для этого вы сначала используете инструмент beegfs-ctl (инструмент является частью пакета beegfs-utils на клиенте), чтобы перечислить зарегистрированные целевые ID:

$ beegfs-ctl —listtargets —longnodes

Затем проверьте содержимое файла «targetNumID» в вашем каталоге хранения на сервере хранения, чтобы узнать, какой целевой идентификатор является текущим, который вы хотите сохранить. Для всех остальных целевых ID из списка, которые назначены этому серверу хранения, но больше недействительны, используйте эту команду, чтобы отменить их регистрацию у демона управления:

$ beegfs-ctl —removetarget

После этого ваш клиент больше не будет жаловаться на недостающие объекты хранения.

Замечание: В конфигурационных файлах сервера есть возможность запретить инициализацию новых каталогов хранения и регистрацию новых серверов или целей, которые не устанавливаются по умолчанию, но должны быть установлены для производственных сред. Смотрите параметры storeAllowFirstRunInit и sysAllowNewServers.

• Что происходит, когда я удаляю файл, который все еще используется процессом?

Когда файл удаляется, пока он еще открыт процессом, его inode временно перемещается в распоряжение директории на узле метаданных. Аналогичным образом, его части данных перемещаются в каталоги с одинаковым именем на целевом хранилище. Позже, когда файл закрывается, его inode и chunks окончательно стираются. Таким образом, нормально видеть файлы в каталогах утилизации до тех пор, пока процессы продолжают держать их открытыми.

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

$ beegfs-ctl  --disposeunused --printstats --dispose

Если утилизационный файл не может быть удален из-за того, что он все еще используется каким-либо процессом, вы увидите сообщение:

[1-573EC7CC-C] File still in use

Не о чем беспокоиться. Просто подождите окончания процесса, и этот утилизационный файл будет удален. Если вы хотите идентифицировать такой процесс, выполните следующую команду на клиентских узлах:

$ lsof | grep "(deleted)"

В случае прерывания процесса, ядро Linux автоматически закроет все файлы, которые использовались в процессе, а клиентский модуль BeeGFS продолжит попытки отправить операцию закрытия на сервер метаданных. Клиент сделает это также в том случае, если сеть была отключена в момент завершения операции.

В случае сбоя или перезагрузки клиентского узла, файлы утилизации будут удалены сервером метаданных примерно через 30 минут, когда клиентский узел будет помечен как мертвый(недоступный).

• Возможно ли отключить использование сервисов RDMA от BeeGFS для конкретного сетевого интерфейса?

Да, возможно. Используйте опцию connTcpOnlyFilterFile, чтобы установить путь к текстовому файлу, который указывает IP подсети, в которых RDMA должна быть отключена для исходящей связи. Добавьте опцию в файл конфигурации сервера демона или клиента следующим образом:

connTcpOnlyFilterFile = /etc/beegfs/tcp-only-interfaces.conf

Эта опция работает аналогично опции connNetFilterFile. Вам нужно добавить по одной подсети на строку в бесклассовой нотации (например, 192.168.10.0/24).

• Можно ли предотвратить создание новых файлов на определенных объектах хранения?

Да, вы можете сделать это, заставив BeeGFS предположить, что на определенном объекте хранения не осталось места. Исходя из этого, целевое хранилище будет перемещено в аварийный пул, где оно не будет использоваться для новых файлов, в то время как другие целевые хранилища все еще доступны в обычном или малом пуле. Для этого можно создать файл под названием «free_space.override» с содержащимся в нем номером, представляющим собой объем свободного пространства, поэтому обычно он равен нулю.

Если целевой каталог вашего хранилища (storeStorageDirectory в beegfs-storage.conf), например, /mnt/myraid/beegfs_storage, то вы будете делать так:

$ echo 0 > /mnt/myraid/beegfs_storage/free_space.override

Обновление информации займет несколько минут. Проверить назначение пула целевого хранилища можно, посмотрев на соответствующий столбец вывода инструмента «beegfs-df«. Когда позже вы захотите восстановить все в нормальном состоянии, вы можете просто удалить файл «free_space.override«. Все это можно сделать во время работы, без перезапуска каких-либо служб.

• Что делать, когда на моем beegfs-storage появляется сообщение о слишком большом количестве открытых файлов?

Обычно это происходит, когда пользовательское приложение сливает открытые файлы, например, оно создает много файлов и забывает их close() из-за ошибки в приложении. (Обратите внимание, что открытые файлы будут автоматически закрыты ядром при завершении работы приложения, так что эта проблема обычно временная).

Существуют ограничения для каждого процесса и общесистемные ограничения (учитывающие все процессы на машине), чтобы контролировать, сколько файлов может быть открыто одновременно на хосте.

Чтобы избежать открытия приложениями слишком большого количества файлов одновременно и убедиться в том, что такие проблемы приложения не влияют на работу серверов, имеет смысл уменьшить лимит на процесс для обычных приложений обычных пользователей до разумно низкого значения, например, до 1024 с помощью настройки «nofile» в «/etc/security/limits.conf«.

Если вашим приложениям действительно необходимо открывать много файлов одновременно и вам нужно поднять лимит в сервисе beegfs-storage, вот, как это сделать:

Вы можете проверить текущий лимит на максимальное количество открытых файлов через файловую систему «/proc», например, для запуска на машине процессов beegfs-storage:

$ for i in `pidof beegfs-storage`; do cat /proc/$i/limits | grep open; done
Max open files            50000             50000             files

Процессы beegfs-storage и beegfs-meta могут попытаться увеличить собственные лимиты через конфигурационную опцию «tuneProcessFDLimit», но это будет зависеть от жёстких лимитов, которые были определены для системы. Если служба beegfs-storage не сможет увеличить собственные ограничения, то она выведет строку сообщения в свой лог-файл («/var/log/beegfs-storage.log«). Установите в файле «/etc/beegfs/beegfs-storage.conf» следующее, чтобы служба beegfs-storage попыталась увеличить собственный лимит до 10 миллионов файлов:

tuneProcessFDLimit=10000000

Вы можете увеличить общесистемные лимиты (лимиты, которые учитывают количество всех процессов) до 20 миллионов во время выполнения, используя следующие команды:

$ sysctl -w fs.file-max=20000000
fs.file-max = 20000000
$ sysctl -w fs.nr_open=20000000
fs.nr_open = 20000000

Сделайте изменения постоянными при перезагрузке, добавив следующие строки в «/etc/sysctl.conf» (или соответствующий файл в поддиректории «/etc/sysctl.d»):

fs.file-max = 20000000
fs.nr_open = 20000000

Добавьте следующую строку в «/etc/security/limits.conf» (или соответствующий файл в поддиректории «/etc/security/limits.d«), чтобы увеличить лимит для каждого процесса до 10 миллионов. Если этот сервер используется не только для BeeGFS, но и для других приложений, вы можете установить его только для процессов, принадлежащих root.

*                -      nofile          10000000

Теперь вам нужно закрыть вашу текущую оболочку и снова открыть новую оболочку в системе, чтобы новые настройки были эффективны. Затем вы можете перезапустить процесс beegfs-storage из новой оболочки и посмотреть на его лимиты:

$ for i in `pidof beegfs-storage`; do cat /proc/$i/limits | grep open; done Max open files            10000000             10000000             files

• Как узнать, к какому файлу относится тот или иной раздел хранилища? (V6.x)

В некоторых случаях может понадобиться выяснить, к какому файловому пути относится конкретная часть хранилища, например, если в сообщении журнала появляется идентификатор части (идентификатор записи). Эту информацию можно получить, выполнив команды, приведенные ниже, чтобы просканировать все файлы в BeeGFS, выгрузить их пути и идентификаторы блоков в текстовый файл, а затем выполнить поиск информации, связанной с идентификатором блока. $ find /mnt/beegfs -type f | beegfs-ctl —getentryinfo —verbose — > /tmp/entryinfo.txt $ grep -B 11 «5C-58DD2BB9-2» /tmp/entryinfo.txt Другой способ сделать это — использовать сторонний инструмент, такой как beegfs-chunk-map, для создания базы данных, сопоставляющей chunk IDs с путями к файлам.

• Как влияет на BeeGFS Spectra и Meltdown?

Если включены исправления, которые были созданы для устранения этих уязвимостей безопасности, то это влияет на рабочую нагрузку. У нас есть дополнительная информация. Названия Meltdown и Spectre относятся к уязвимостям безопасности, вызванным тем, как процессоры реализовали спекулятивное исполнение. Поэтому в январе 2018 года ядра Linux получили обновления с исправлениями для частичного отключения этой технологии повышения производительности за счет снижения производительности оборудования. Когда патчи для предотвращения атак Meltdown или Spectre активны на сервере BeeGFS или клиенте BeeGFS, они влияют на производительность BeeGFS, подобно любой другой файловой системе или syscalls из приложений в целом (такие syscalls включают в себя не только общеизвестные операции чтения файлов read() или write(), но и коммуникационные операции, такие как send(), recv(), и другие). В общедоступном списке рассылки beegfs-user, результаты бенчмарков с патчами и без них, были поделены на группы, для сравнения производительности с включенной и не включенной функцией предотвращения атак. В зависимости от среды, патчи безопасности могут быть отключены, для повышения производительности: На полностью изолированных кластерах, которые работают только с доверенными приложениями, эти патчи могут быть отключены на всех клиентах и серверах BeeGFS. На менее изолированных системах, где BeeGFS-серверы используются только для обслуживания клиентов BeeGFS, и нет общего входа на BeeGFS-серверы от пользователей, не являющихся доверенными системными администраторами, эти патчи можно отключить только на серверах BeeGFS. Более подробная информация о технических характеристиках и способах отключения защиты от атак для повышения производительности систем Red Hat и SUSE представлена здесь: redhat suse