BeeGFS Documentation

Используемые в документе термины:

MPI — Message Passing Interface — это специфический API, который реализуют производители кластеров для того, чтобы можно было легко переносить программы с кластера на кластер не изменяя ни байта исходного кода(!). Параллельная программа должна эффективно использовать вычислительные мощности и коммуникационную среду.

RDMA — Remote Direct Memory Access — аппаратное решение для обеспечения прямого доступа к оперативной памяти другого компьютера при помощи высокоскоростной сети. Такой доступ позволяет получить доступ к данным, хранящимся в удалённой системе без привлечения средств операционных систем обоих компьютеров. Является методом пересылки данных с высокой пропускной способностью и низкой задержкой сигнала, и особенно полезен в больших параллельных вычислительных кластерах.

RDMA через Converged Ethernet (RoCE) — это сетевой протокол, позволяющий удаленный прямой доступ к памяти (RDMA) через сеть Ethernet. Путем инкапсуляции транспортного пакета IB (InfiniBand) через Ethernet. Существует две версии RoCE, RoCE v1 и RoCE v2. RoCE v1 является протоколом канального уровня Ethernet и, следовательно, обеспечивает связь между любыми двумя узлами в одном широковещательном домене Ethernet. RoCE v2 — это протокол Интернет-уровня, который означает, что пакеты RoCE v2 могут маршрутизироваться. Хотя протокол RoCE обладает преимуществами характеристик конвергентной сети Ethernet, он также может использоваться в традиционной или не конвергентной сети Ethernet.

Omni-Path (Omni-Path Architecture, OPA) — это высокопроизводительная архитектура коммуникации, разработанная и принадлежащая Intel. Нацелена на низкую задержку обмена данными, низкое энергопотребление и высокую пропускную способность.

POSIX ( Portable Operating System Interface — переносимый интерфейс операционных систем) — набор стандартов, описывающих интерфейсы между операционной системой и прикладной программой (системный API), библиотеку языка C и набор приложений и их интерфейсов. Стандарт создан для обеспечения совместимости различных UNIX-подобных операционных систем и переносимости прикладных программ на уровне исходного кода, но может быть использован и для не-Unix систем.

Network File System (NFS) — это протокол распределенной файловой системы, изначально разработанный компанией Sun Microsystems (Sun), позволяющий пользователю на клиентском компьютере получать доступ к файлам по компьютерной сети так же, как и к локальному хранилищу. NFS построена на системе Open Network Computing Remote Procedure Call (ONC RPC).

SMB (Server Message Block) — сетевой протокол прикладного уровня для удалённого доступа к файлам, принтерам и другим сетевым ресурсам, а также для межпроцессного взаимодействия.

HDFS (Hadoop Distributed File System) — файловая система, предназначенная для хранения файлов больших размеров, поблочно распределённых между узлами вычислительного кластера. Все блоки в HDFS (кроме последнего блока файла) имеют одинаковый размер, и каждый блок может быть размещён на нескольких узлах, размер блока и коэффициент репликации (количество узлов, на которых должен быть размещён каждый блок) определяются в настройках на уровне файла. Благодаря репликации обеспечивается устойчивость распределённой системы к отказам отдельных узлов. Файлы в HDFS могут быть записаны лишь однажды (модификация не поддерживается), а запись в файл в одно время может вести только один процесс. Организация файлов в пространстве имён — традиционная иерархическая: есть корневой каталог, поддерживается вложение каталогов, в одном каталоге могут располагаться и файлы, и другие каталоги.

rsync (remote synchronization) — программа для UNIX-подобных систем, которая эффективно выполняет синхронизацию файлов и каталогов в двух местах (необязательно локальных) с минимизированием трафика, используя кодирование данных при необходимости. Rsync может копировать или отображать содержимое каталога и копировать файлы, опционально используя сжатие и рекурсию. Rsync передаёт только изменения файлов, что отражается на производительности программы.

inode (индексный дескриптор) — это структура данных в традиционных для ОС UNIX файловых системах (ФС), таких как UFS, ext4. В этой структуре хранится метаинформация о стандартных файлах, каталогах или других объектах файловой системы, кроме непосредственно данных и имен. При создании файловой системы создаются также и структуры данных, содержащие информацию о файлах. Каждый файл имеет свой индексный дескриптор, идентифицируемый по уникальному номеру (часто называемому ‘i-номером’ или ‘инодом’), в файловой системе, в которой располагается сам файл. Индексные дескрипторы хранят информацию о файлах, такую как принадлежность владельцу (пользователю и группе), режим доступа (чтение, запись, запуск на выполнение) и тип файла. Существует определённое число индексных дескрипторов, которое указывает максимальное количество файлов, допускаемое определённой файловой системой. Обычно при создании файловой системы примерно 1 % её объёма выделяется под индексные дескрипторы.

BBU (Battery Backup Unit) — Элемент питания, являющийся частью RAID — контроллера, который защищает кэш контроллера от потери данных при сбоях питания. Обычно кэш контроллера является устройством ОЗУ, в котором данные хранятся только при наличии питания.

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

NUMA (Non-Uniform Memory Access — «неравномерный доступ к памяти» или Non-Uniform Memory Architecture — «Архитектура с неравномерной памятью») — схема реализации компьютерной памяти, используемая в мультипроцессорных системах, когда время доступа к памяти определяется её расположением по отношению к процессору.

SSD (solid-state drive твердотельный накопитель) — компьютерное энергонезависимое не механическое запоминающее устройство на основе микросхем памяти, альтернатива HDD. Кроме микросхем памяти, SSD содержит управляющий контроллер. Наиболее распространённый вид твердотельных накопителей использует для хранения информации флеш-память типа NAND, однако существуют варианты, в которых накопитель создаётся на базе DRAM-памяти, снабжённой дополнительным источником питания.

NVM Express (NVMe, NVMHCI — Non-Volatile Memory Host Controller Interface Specification) — спецификация на протоколы доступа к твердотельным накопителям (SSD), подключённым по шине PCI Express. «NVM» в названии спецификации обозначает энергонезависимую память, в качестве которой в SSD повсеместно используется флеш-память типа NAND. Логический интерфейс NVM Express был разработан с нуля, основные цели — получение низких задержек и эффективное использование высокого параллелизма твердотельных накопителей за счёт применения нового набора команд и механизма обработки очередей, оптимизированного для работы с современными многоядерными процессорами.

ARP (Address Resolution Protocol — протокол определения адреса) — протокол в компьютерных сетях, предназначенный для определения MAC-адреса по IP-адресу другого компьютера.

NDP (Neighbor Discovery Protocol — Протокол обнаружения соседей) — протокол из набора протоколов TCP/IP, используемый совместно с IPv6. Он работает на сетевом уровне Модели Интернета и ответственен за автонастройку адреса конечных и промежуточных точек сети, обнаружения других узлов на линии, определения адреса других узлов канального уровня, обнаружение конфликта адресов, поиск доступных маршрутизаторов и DNS-серверов, определения префикса адреса и поддержки доступности информации о путях к другим активным соседним узлам.

О файловой системе

Это параллельная кластерная файловая система, то есть файлы распределяются на нескольких узлах кластера (допустимо и наличие единственного узла для всех служб файловой системы) для максимизации производительности чтения/записи и масштабируемости файловой системы. Тот факт, что она кластеризованная, указывает на то, что эти узлы сервера совместно работают над созданием единой файловой системы, которая может быть одновременно смонтирована и доступна другим узлам сервера (клиентам). Основная идея в том, что клиенты могли видеть и использовать эту распределенную файловую систему так же, как и локальные файловые системы, такие как NTFS, XFS, ext4 и прочие POSIX совместимые. Есть четыре основных требуемых компонента: управление, хранение, метаданные и клиентский сервис. Они работают на широком спектре поддерживаемых дистрибутивов Linux. Эти сервисы взаимодействуют через любую сеть, поддерживающую TCP/IP или RDMA, включая InfiniBand (IB), Omni-Path (OPA) и RDMA по Converged Ethernet (RoCE). Сервис BeeGFS (управление, хранение и метаданные) является демоном пользовательского пространства, в то время как клиент является родным модулем ядра (без патча). Все компоненты могут быть установлены или обновлены без перезагрузки, так же вы можете запустить любую комбинацию сервисов на одном узле, включая все. По умолчанию клиенты монтируют файловую систему BeeGFS в файле /mnt/beegfs, хотя при желании это можно изменить. После запроса службы управления BeeGFS для получения подробной информации о топологии, клиенты взаимодействуют напрямую с узлами хранения и метаданных для облегчения ввода/вывода данных пользователем. Для достижения максимальной производительности рекомендуется использовать встроенный клиент BeeGFS для всех узлов, имеющих доступ к файловой системе BeeGFS. Клиент BeeGFS предоставляет обычную точку монтирования, поэтому приложения могут получить доступ к файловой системе BeeGFS напрямую, без необходимости специальных модификаций. Вы также можете экспортировать точку монтирования BeeGFS, используя NFS или Samba, или в качестве замены HDFS. Файловой системой можно управлять с помощью beegfs-ctl инструмента командной строки, включенного в пакет beegfs-utils. Эта утилита должна быть запущена с клиентского узла, автоматически устанавливается вместе с клиентской службой. Встроенная справка доступна путем добавления -help к любой команде. В этот пакет также входит программа проверки файловой системы BeeGFS beegfs-fsck, которая используется для проверки и корректировки согласованности файловой системы (консистентность). BeeGFS сервисы устанавливаются с помощью выбранного менеджера пакетов после добавления BeeGFS репозиториев (так же можно собрать Beegfs из исходных текстов). Конфигурационные файлы для всех сервисов BeeGFS можно найти в файле /etc/beegfs/beegfs-*.conf. Лог-файлы расположены в /var/log/beegfs-*.log, а архивы хранятся в виде beegfs- * .log.old- * . BeeGFS скрипты и двоичные файлы находятся в /opt/beegfs/, а службы BeeGFS управляются как systemd юниты. Несмотря на то, что BeeGFS в целом хорошо работает из коробки, доступны огромные возможности настройки и конфигурирования для максимизации производительности для заданной рабочей нагрузки или среды.

Services

Management service

Это служба управления BeeGFS. Эту службу можно рассматривать как реестр и контролирующий элемент для всех других служб, задействованных в файловой системе. Единственная требуемая настройка службы — это то, где служба хранит свои данные. Она хранит только информацию о других узлах в кластере, поэтому потребляет минимальное дисковое пространство (100KB в общих случаях), а доступ к данным не является критичным для производительности. На самом деле, эта служба настолько легка, что зачастую, ее размещают совместно с другой службой одного узла кластера, обычно на сервере метаданных. У вас будет только одна служба управления для каждого кластера BeeGFS, а IP-адрес этого узла будет использоваться как часть настройки всех остальных служб BeeGFS.

Storage service

Это сервис объектного хранения. Каждая служба хранения BeeGFS требует одну или несколько целей хранения, которые блокируют устройства с POSIX-совместимой файловой системой. Для каждого развертывания BeeGFS понадобится одна или несколько служб хранения. служба хранения хранит распределенное содержимое пользовательских файлов, файлы с блоками данных (data chunk). Файлы данных для каждого пользовательского файла разделены полосами (stripes) по всем или подмножеству целей хранения в файловой системе BeeGFS. Для гибкости BeeGFS позволяет задать шаблон полос (stripes) в заданной директории, который управляет размером и количеством блоков, а также выбором целей хранения, используемых для новых файлов в директории.

Metadata service

Каждая служба метаданных требует одну цель метаданных, которая является просто блочным устройством с файловой системой, POSIX совместимой. Понадобится одна или несколько служб метаданных для каждой установки BeeGFS.Требования к емкости хранения метаданных BeeGFS малы — обычно от 0,3% до 0,7% от общей емкости хранилища. Однако это зависит от количества каталогов и файловых записей в файловой системе. В документации указано, что 500 ГБ емкости метаданных подходит примерно для 150 000 000 файлов при использовании ext4 на основной цели метаданных. Служба метаданных хранит данные, описывающие структуру и содержание файловой системы. Так же включает в себя отслеживание каталогов в файловой системе и файловых записей в каждом каталоге. Служба также отвечает за хранение атрибутов каталогов и файлов, таких как владелец, размер, время изменения/обновления или создания, а также фактическое расположение пользовательских частей файла данных на объектах хранения. Пока не происходит операций открытия/закрытия файлов служба метаданных не участвует в доступе к данным, что помогает избежать момента делающего доступ к метаданным узким местом в производительности. Еще одним преимуществом является то, что метаданные распределяются по директориям. Это означает, что при создании каталога BeeGFS выбирает сервер метаданных для этого каталога и содержащихся в нем файлов, но подкаталоги могут быть назначены другим серверам метаданных, балансируя нагрузку и емкость метаданных между доступными серверами. Эта стратегия решает проблемы производительности и масштабируемости.

Client service

Это клиентская служба BeeGFS, которая осуществляет нативную запись в интерфейсе виртуальной файловой системы ядра Linux. Для простоты, исходный код модуля ядра входит в состав клиента и компиляция происходит автоматически. При обновлении ядра или BeeGFS-клиента никакого ручного вмешательства не требуется. Необходимо убедиться, что установленная версия пакета kernel-devel совпадает с текущей версией ядра (при несоответствии возникнут серьезные проблемы). Клиент также включает в себя помощника по использованию пространства пользователя для работы с журналом и разрешением имен хостов.

NTP

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

Нюансы установки

BeeGFS позволяет запускать любую комбинацию служб файловой системы (включая службу клиента и службу хранения/метаданных) на одной машине, однако для достижения максимальной производительности и балансировки нагрузки лучше разместить их на разных машинах. Демоны управления и администрирования практически не снижают производительность устройства на котором запущены и поэтому обычно не запускаются на выделенных машинах.
Для установки актуальной версии BeeGFS под вашу ОС, можно посетить сайт Link где расположена информация о пакетах и репозиториях.
BeeGFS 7.1 и выше поддерживает (RDMA). Для включения поддержки удалённого прямого доступа к памяти (RDMA) на основе OFED ibverbs API, необходимо установить дополнительный пакет libbeegfs-ib. BeeGFS автоматически включит RDMA при запуске, если соответствующее оборудование и драйверы присутствуют.
Актуальный туториал по установке BeegFS Link2
Разработчики настоятельно рекомендуют настроить решение для резервного копирования, например, rsync, чтобы сделать резервную копию цели управления (/beegfs/mgmtd/) в безопасное внешнее хранилище.
BeeGFS содержит некоторые опции безопасности, которые возможно, захотите установить после завершения первоначальной настройки файловой системы:storeAllowFirstRunInit=false запрещает запуск демона, если каталог хранилища пуст, например, из-за неправильного монтирования соответствующего тома RAID.sysAllowNewServers=false в beegfs-mgmtd.conf запрещает регистрацию новых серверов (например, чтобы убедиться, что новый сервер не был случайно зарегистрирован в производственной среде). sysMountSanityCheckMS может быть использован для того, чтобы позволить клиенту отказаться от установки файловой системы, если не все серверы доступны. (Обычно вы хотите отключить эту опцию для клиентов, которые работают вместе с демонами сервера на одной машине).
Без проверки подлинности на основе соединения, BeeGFS позволяет любой машине, которая может подключиться к вашим серверам, смонтировать вашу BeeGFS . Чтобы противодействовать этому, вы можете включить опцию connAuthFile. Опция connAuthFile может быть установлена в конфигурационных файлах служб BeeGFS. Эта опция определяет pre-shared secret и запросы принимаются только от соединений, которые могут предоставлять pre-shared secret . В этой опции вы можете задать путь к файлу, который может быть любого типа. Обратите внимание, что без аутентификации на основе соединений можно монтировать экземпляр BeeGFS с любой машины, которая может подключаться к вашим серверам. Так как BeeGFS полагается на аутентификацию пользователя с клиентской стороны, то корневой пользователь на любой машине рассматривается BeeGFS как пользователь root, а по расширению их файлы принадлежат root на всех машинах, на которых смонтирована одна и та же BeeGFS. Это может вызвать повышение привилегий. Поэтому разработчики рекомендуют включать аутентификацию на основе соединения в каждом случае, когда администратор не имеет полного контроля над сетью и всеми клиентскими машинами.
Версия пакета kernel-devel BeeGFD должна совпадать с текущей версией ядра ОС, или у вас возникнут серьезные проблемы.
Есть так же достаточно подробные описания пакета BeeGFS на вики arch linux Link3

Basic Configuration

Managment service

Managment service должен знать, где хранить свои данные. Служба будет хранить только некоторую информацию об узле, например, данные о подключении, поэтому ей не потребуется много места для хранения, а доступ к данным не является критичным с точки зрения производительности. Таким образом, эта служба обычно не работает на выделенной машине. Копирование стандартной конфигурации в текущую установку BeeGFS:

$ /opt/beegfs/sbin/beegfs-setup-mgmtd -p /data/beegfs/beegfs_mgmtd

Metadata service

Metadata service должен знать, где хранить свои данные и где запущена служба управления. Обычно на разных машинах работает несколько служб метаданных. В качестве опции можно также определить пользовательский ID службы метаданных (ID 1..65535). Копирование стандартной конфигурации в текущую установку BeeGFS:

$ /opt/beegfs/sbin/beegfs-setup-meta -p /data/beegfs/beegfs_meta -s 2 -m node01

Storage service

Storage service должен знать, где он может хранить свои данные и как связаться с сервером управления. Обычно у вас есть несколько служб хранения, работающих на разных машинах, и/или несколько целей хранения (например, несколько томов RAID).В качестве опции можно также определить пользовательский числовой ID службы хранения и числовой целевой ID хранилища (оба в диапазоне 1…65535). Копирование стандартной конфигурации в текущую установку BeeGFS:

$ /opt/beegfs/sbin/beegfs-setup-storage -p /mnt/myraid1/beegfs_storage -s 3 -i 301 -m node01

Добавление второго storage target на текущей машине:

$ /opt/beegfs/sbin/beegfs-setup-storage -p /mnt/myraid2/beegfs_storage -s 3 -i 302

Client

Client должен знать где находится managment service вашего кластера. $ /opt/beegfs/sbin/beegfs-setup-client -m node01 Каталог монтирования клиента определяется в отдельном файле конфигурации. Этот файл будет использоваться сценарием запуска службы beegfs-client. По умолчанию BeeGFS будет смонтирован в /mnt/beegfs. Таким образом,редактируя этот файл, можно изменить каталог монтирования файловой системы у клиента:

$ vim /etc/beegfs/beegfs-mounts.conf

Services startup

sBeeGFS-сервисы могут быть запущены в произвольном порядке с помощью соответствующих служебных скриптов init.d или systemctl. Все службы создают лог-файлы (/var/log/beegfs-….).$ ssh root@node01 systemctl start beegfs-mgmtd
$ ssh root@node02 systemctl start beegfs-meta
$ ssh root@node03 systemctl start beegfs-storage
$ ssh root@node04 systemctl start beegfs-helperd
$ ssh root@node04 systemctl start beegfs-client
$ ssh root@node05 systemctl start beegfs-admon
Будьте осторожны с монтированием файловой системы, клиенты BeeGFS проверяют вменяемость монтирования и отменяют операцию монтирования, если серверы недоступны. Если вы хотите монтировать даже недоступные серверы, установите sysMountSanityCheckMS=0 в файле /etc/beegfs/beegfs-client.conf.
После первоначальной конфигурации и запуска сервисов, необходимо обязательно проверить связность файловой системы:$ beegfs-ctl —listnodes —nodetype=meta —nicdetails
$ beegfs-ctl —listnodes —nodetype=storage —nicdetails
$ beegfs-ctl —listnodes —nodetype=client —nicdetails
$ beegfs-net # Displays connections the client is actually using
$ beegfs-check-servers # Displays possible connectivity of the services
$ beegfs-df # Displays free space and inodes of storage and metadata targetsПосле этого обязательно проверьте ваши лог-файлы (/var/log/beegfs-X.log).
Далее нужно убедиться, что интерфейсы перечислены в нужном порядке(т.е. основной интерфейс должен быть указан первым в выводе beegfs-ctl —listnodes), и что вы видите только те интерфейсы, которые вы хотите, чтобы BeeGFS использовал.
Обратите внимание, что клиенты BeeGFS устанавливают соединения только тогда, когда это необходимо, а также прекращают простаивающие соединения, поэтому вы можете, например, не видеть соединения сервера метаданных в beegfs-net до тех пор, пока не выполните операцию с метаданными на клиентском подключении, например, ls.

Advanced configuration

Общие методы настройки BeeGFS

Опции конфигурации исполнения могут быть запрошены и изменены с помощью BeeGFS Control Tool (команда beegfs-ctl на клиентских узлах). Этот инструмент является частью пакета beegfs-utils.
Инструмент beegfs-ctl читает файл beegfs-client.conf из места по умолчанию, если он существует. Хотя утилита также может быть использована без конфигурационного файла клиента, обычно гораздо удобнее использовать ее, когда такая базовая конфигурация клиента существует на соответствующей машине. Так же это позволит при необходимости сделать копию конфигурационных файлов для переноса или восстановления.
На клиенте с активным BeeGFS монтированием можно также запросить несколько параметров конфигурации через записи procfs /proc/fs/beegfs.
В пакете beegfs-utils также есть несколько удобных вспомогательных сценариев (например, /usr/bin/beegfs-net для отображения текущих клиентских соединений), которые либо вызывают beegfs-ctl внутренне, либо читают выходные данные из /proc/fs/beegfs.
Статические параметры конфигурации могут быть установлены путем редактирования соответствующих конфигурационных файлов /etc/beegfs/beegfs-X.conf. При установке системы с GUI обычно не редактируют конфигурационные файлы на узлах напрямую,но можно менять настройки через GUI или модифицировать файлы шаблонов в /opt/beegfs/setup/confs на узле — демон Admon, а затем Admon распространит конфигурации на узлах файловой системы.Storage service tuningОптимальные настройки зависят от конкретного аппаратного обеспечения и сценариев использования файловой системы, поэтому необходимо использовать базовые настройки только в качестве отправной точки для настройки. Такие бенчмарки как IOR, IOZone, StorageBench помогут определить оптимальные настройки для ваших серверов хранения BeeGFS путем экспериментов и редактирования конфигурации. Пакет BeeGFS имеет встроенные инструменты тестирования системы хранения — StorageBench и сети NetBench.StorageBench
- Этот тест измеряет потоковую пропускную способность базовой файловой системы и устройств, не зависящую от производительности сети. Для имитации клиентского ввода-вывода, этот тест генерирует рабочие пакеты чтения/записи локально на серверах без взаимодействия с клиентом. Обратите внимание, что без сетевого взаимодействия, чередование файлов не может быть смоделировано, поэтому результаты бенчмарка сравнимы с клиентским IO с отключенной чередованием (т.е. одна цель на файл).Возможно проводить тестирование только определенных целей или всех целей вместе. С помощью инструмента beegfs-ctl запускается и контролируется тест хранилища.
- Следующий пример запускает бенчмарк записи на всех целевых серверах хранения BeeGFS с размером блока ввода-вывода 512 КБ, используя 10 потоков (т.е. имитированных клиентских потоков) на каждую целевую аудиторию, каждый из которых записывает 200 ГБ данных в свой файл:
$ beegfs-ctl —storagebench —alltargets —write —blocksize=512K —size=200G —threads=10Чтобы запросить статус/результат бенчмарка всех целей, выполните команду:$ beegfs-ctl —storagebench —alltargets —statusВы можете использовать команду Watch для повтора запроса с заданным интервалом в секундах:$ watch -n 5 beegfs-ctl —storagebench —alltargets —statusСгенерированные файлы не будут автоматически удалены после завершения тестирования. Нужно будет удалить их командой (затирает данные на файловой системе):$ beegfs-ctl —storagebench —alltargets —cleanupПодробная информация о бенчмарке хранилища и его настройках доступна в справке к beegfs-ctl:$ beegfs-ctl —storagebench —helpNetBench modeПредназначен для сравнительного анализа потоковой пропускной способности сети. В этом режиме запросы на запись и чтение передаются по сети от клиента к серверам хранения, как это делает BeeGFS во время нормальной работы (т.е. при отключенном режиме netbench). Разница заключается в том, что при включенном режиме netbench серверы отбрасывают полученные запросы на запись вместо фактической передачи полученных данных в базовую файловую систему (и именно для запросов на чтение — в этом случае клиентам будут посылаться только буферы памяти вместо фактического чтения из базовой файловой системы на серверах). Таким образом, этот режим помогает обнаружить медленные сетевые соединения и может быть использован для проверки максимальной пропускной способности сети между клиентами и серверами хранения, так как пропускная способность в этом режиме не зависит от дисков, лежащих в основе. Для тестирования пропускной способности потоков можно использовать любой инструмент, который записывает данные в точку монтирования BeeGFS, например, dd или IOR. (Обратите внимание, что из-за того, что операции записи отбрасываются на серверах, записанные файлы после записи продолжают иметь длину 0, поэтому нормально, что некоторые утилиты могут напечатать предупреждение о неожиданном размере файла или о том, что данные испорчены). Все остальные операции, такие как создание и удаление ссылок, будут нормально работать с включенным режимом netbench, затрагиваются только операции записи и чтения. Режим Netbench включается через конфигурацию времени выполнения клиента в /proc/fs/beegfs. Следующая команда включит режим netbench для конкретного клиента, на котором он выполняется (другие клиенты на это не влияют). Перемонтирование клиента не требуется и отключит режим netbench.$ echo 1 > /proc/fs/beegfs/<clientID>/netbench_modeВажно не забыть отключить режим netbench после выполнения эталонного тестирования для повторного включения нормального чтения и записи в файловую систему. Это можно сделать следующей командой:$ echo 0 > /proc/fs/beegfs/<clientID>/netbench_modeОбратите внимание, что эта команда повлияет только на клиента, на котором она выполняется. Если вы включили режим netbench на нескольких клиентах, придется выполнить эту команду на всех этих клиентах.External Benchmarking ToolsBeeGFS так же отлично работает и с другими утилитами тестирования производительности, официальная документация рекомендует следующие утилиты:IORIOR является бенчмарком для измерения производительности одного или нескольких клиентов с одним или несколькими процессами на клиента. IOR основан на MPI для распределенного исполнения. Он может быть использован для измерения потоковой пропускной способности или небольшой произвольной производительности ввода-вывода (IOPS). Необходимо, установить пакет beegfs-client-devel перед сборкой, чтобы включить поддержку BeeGFS в этом бенчмарке. Настройка количества процессов ${NUM_PROCS} зависит от количества клиентов для тестирования и количества процессов на клиента. Размер блока ${BLOCK_SIZE} можно вычислить с помощью ((3 * RAM_SIZE_PER_STORAGE_SERVER * NUM_STORAGE_SERVERS) / ${NUM_PROCS}). Benchmark многопоточной пропускной способности:$ mpirun -hostfile /tmp/nodefile —map-by node -np ${NUM_PROCS} /usr/bin/IOR -wr -i5 -t2m -b ${BLOCK_SIZE} -g -F -e
-o /mnt/beegfs/test.ior

  
  Benchmark пропускной способности общего доступа к файлам:
  
  ```bash
$ mpirun -hostfile /tmp/nodefile --map-by node -np ${NUM_PROCS} /usr/bin/IOR -wr -i5 -t1200k -b ${BLOCK_SIZE} -g -e
  -o /mnt/beegfs/test.ior

В данном тесте выбрано 1200k как пример для размера передачи, который не выровнен по размеру BeeGFS chunksize, что бы проанализировать производительность не оптимального размера данных.

IOPS Benchmark

$ mpirun -hostfile /tmp/nodefile --map-by node -np ${NUM_PROCS} /usr/bin/IOR -w -i5 -t4k -b ${BLOCK_SIZE} -F -z -g
-o /mnt/beegfs/test.ior

Параметры настройки BeeGFS

-O beegfsNumTargets= <Число> Количество целей хранения для чередования -О beegfsChunkSize= <Число> размер чанка, в байтах. Принимает k=кило, M=мега, G=гига

mpirun Параметры -hostfile $PATH (файл с именами хостов клиентов/серверов для бенчмаркинга) -np $N (количество процессов)

Параметры IOR -w (записать тест) -r (читать тест) -i $N (повторы) -t $N (размер перевода, для dd — размер блока) -b $N (размер блока, объем данных для процесса) -g (используйте барьеры между открытием, написанием/чтением и закрытием). -e (выполняйте fsync при закрытой записи POSIX, убедитесь, что чтение только начинается — все записи сделаны). -o $PATH (путь к файлу для теста). -F (по одному файлу на процесс) -z (случайный доступ к файлу)

mdtest

mdtest — это бенчмарк для метаданных, который нуждается в MPI для распределенного исполнения. Его можно использовать для измерения таких значений, как создание файлов в секунду или операции статистики в секунду одного процесса или нескольких процессов. Значение для количества процессов ${NUM_PROCS} зависит от количества тестируемых клиентов и количества процессов на одного клиента. Количество директорий можно рассчитать как ${NUM_DIRS} = (параметр -b ^ параметр -z). Общее количество файлов всегда должно быть больше 1 000 000, поэтому ${FILES_PER_DIR} рассчитывается как ${FILES_PER_DIR}. = (1000000 / ${NUM_DIRS} / ${NUM_PROCS}).

Создание файла бенчмарка и параметры запуска:

$ mpirun -hostfile /tmp/nodefile --map-by node -np ${NUM_PROCS} mdtest -C -T -r -F -d /mnt/beegfs/mdtest -i 3 -I ${FILES_PER_DIR} -z 2 -b 8 -L -u

Параметры mdtest -С (создать тест) -T (выполнять тесты на соответствие) -r (выполнить удаленные тесты) -F (выполнять только файловые тесты) -d $PATH (путь к тестовому каталогу) -i $N (итерации) -I $N (количество файлов в каталоге) -z $N (глубина структуры каталога) -b $N (сколько подкаталогов нужно создать на каталог более высокого уровня «-z») -L (использовать уровень листа дерева для файловых тестов) -u (каждая задача получает свою рабочую директорию).

Storage Server Tuning

Оптимальные настройки зависят от конкретного аппаратного обеспечения и сценариев использования, поэтому Вы должны использовать эти настройки только в качестве отправной точки для настройки. Такие инструменты бенчмаркинга, как IOR, IOZone или StorageBench, NetBench и другие помогут вам определить оптимальные настройки для ваших серверов хранения BeeGFS. Некоторые из предложенных настроек не являются постоянными и будут возвращены после следующей перезагрузки. Для того, чтобы они оставались постоянными, вы можете добавить соответствующие команды в /etc/rc.local, как показано в примере ниже, использовать /etc/sysctl.conf или создать правила udev для их автоматического повторного применения при загрузке машины.

echo 5 > /proc/sys/vm/dirty_background_ratio
echo 20 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/vfs_cache_pressure
echo 262144 > /proc/sys/vm/min_free_kbytes
echo 1 > /proc/sys/vm/zone_reclaim_mode

echo always > /sys/kernel/mm/transparent_hugepage/enabled
echo always > /sys/kernel/mm/transparent_hugepage/defrag

devices=(sda sdb)
for dev in "${devices[@]}"
do
  echo deadline > /sys/block/${dev}/queue/scheduler
  echo 4096 > /sys/block/${dev}/queue/nr_requests
  echo 4096 > /sys/block/${dev}/queue/read_ahead_kb
  echo 256 > /sys/block/${dev}/queue/max_sectors_kb
done

Аппаратный RAID

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

Настройка пропускной способности сервера хранения данных

Служба хранения BeeGFS может использовать любые стандартные файловые системы Linux. Тем не менее, XFS является рекомендуемой файловой системой для дисковых разделов целевого хранилища, поскольку она очень хорошо масштабируется для RAID-массивов и, как правило, обеспечивает более высокую устойчивую пропускную способность записи на быстрых носителях по сравнению с альтернативными файловыми системами. В последних версиях ядра Linux были сделаны значительные улучшения в производительности потоковой передачи данных ext4, но XFS по-прежнему является лучшим выбором. Настройки ядра Linux по умолчанию, скорее, оптимизированы для сценариев с одним диском с низкой параллельностью ввода-вывода, так что есть различные настройки, которые должны быть настроены, чтобы получить максимальную производительность из ваших серверов хранения данных.

Создание RAID-оптимизированной файловой системы.

Выравнивание без раздела

Часто используемой и очень простой альтернативой выравниванию разделов является создание файловой системы непосредственно на устройстве хранения без каких-либо разделов. Для этого достаточно использовать mkfs без номера раздела, например, для XFS:

$ mkfs.xfs /dev/sdb

Таким образом, вы легко избежите смещения, которое вводится таблицей разделов.

Выравнивание с разделом

накладных расходов при операциях чтения-изменения-записи и включить внутреннюю оптимизацию RAID-массива XFS или ext4.
Обратите внимание, что если вы используете другие программные слои, такие как LVM, на RAID-массиве, они также могут ввести другое смещение и, следовательно, должны быть приняты во внимание для правильного выравнивания.

Выравнивание разделов — проверка текущего Выравнивания

Обратите внимание на разделы GPT: Пример ниже основан на fdisk, который не совместим с таблицами разделов GPT. Для разделов GPT используйте, например, parted или gdisk.

Если вы уже создали раздел на диске, вы можете проверить его выравнивание с помощью следующей команды:

$ fdisk -lu /dev/sdc

Disk /dev/sdc: 599.9 GB, 599999905792 bytes
255 heads, 63 sectors/track, 72945 cylinders, total 1171874816 sectors
Units = sectors of 1 * 512 = 512 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1              63  1171861424   585930681   83  Linux

Как видно выше, начало раздела в настоящее время находится в позиции 63*512 байт, что не подходит для нашего случая использования.

Выравнивание разделов — Создание выровненного раздела

Обратите внимание на разделы GPT: Пример ниже основан на fdisk, который не совместим с таблицами разделов GPT. Для создания выровненных разделов GPT используйте parted, например

$ parted /dev/sdc mklabel gpt
$ parted --align=opt /dev/sdc unit KiB mkpart pri $((9*64)) 100%

Если у вас уже есть раздел на устройстве, сначала удалите его:

$ fdisk /dev/sdc

Command (m for help): d
Selected partition 1

Command (m for help): w
The partition table has been altered!

Как было сказано, мы хотим выровнять с 9*64KB. Мы будем использовать аргументы fdisk -H 8 -S 16 для ручного указания (логического) количества голов и секторов. Эти аргументы позволяют нам создать раздел, который будет выровнен по 64Кб или любой, кратный 64Кб.
Наши настройки основаны на 64КБ цилиндрах, и мы хотим, чтобы наш раздел начинался сразу после первого набора полос (9 цилиндров), поэтому мы установим первый цилиндр на 10.

$ fdisk -H 8 -S 16 /dev/sdc

The number of cylinders for this disk is set to 9155272.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-9155272, default 1): 10
Last cylinder or +size or +sizeM or +sizeK (10-9155272, default 9155272): 
Using default value 9155272

Command (m for help): w
The partition table has been altered!

Если вы хотите проверить новое выравнивание:

$ fdisk -l /dev/sdc

Disk /dev/sdc: 599.9 GB, 599999905792 bytes
8 heads, 16 sectors/track, 9155272 cylinders
Units = cylinders of 128 * 512 = 65536 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1              10     9155272   585936832   83  Linux

Выше видно, что раздел начинается с цилиндра 10 и цилиндры имеют размер 64KB. Теперь пришло время создать файловую систему на новом разделе.

XFS и ext4 позволяют указать настройки RAID. Это позволяет файловой системе оптимизировать доступ на чтение и запись для выравнивания RAID-массива, например, фиксируя данные как полные наборы полос для максимальной пропускной способности. Эти настройки могут быть сделаны во время создания файловой системы или, в случае XFS, также позже во время монтирования. Обратите внимание, что эти оптимизации RAID могут значительно повысить производительность, но только в том случае, если ваш раздел выровнен правильно или вы избегаете выравнивания, создавая xfs на устройстве без разделов. Для создания новой файловой системы XFS используйте 9 дисков (где число 9 не включает число дисков RAID-5 или RAID-6 с четностью) и 64 КБ:

$ mkfs.xfs -d su=64k,sw=9 -l version=2,su=64k /dev/sdc1

Если ваши данные хранятся на томе RAID-5 или RAID-6, возможно, вы захотите поместить журнал файловой системы на отдельный том RAID-1, из-за накладных расходов на чтение-изменение-запись RAID-5 и RAID-6. В то время как BeeGFS использует выделенные сервисы метаданных для управления глобальными метаданными, производительность метаданных базовой файловой системы на серверах хранения все еще имеет значение для таких операций, как создание файлов, удаление, мелкое чтение/запись и т.е. Последние версии XFS (аналогичная работа ведется для ext4) позволяют встраивать данные в inodes. Чтобы избежать необходимости в дополнительных блоках и соответствующих дорогостоящих дополнительных дисках, ищущих каталоги. Для того, чтобы использовать это эффективно, необходимо увеличить размер входного кода до 512 байт или больше. В примере ниже показана команда создания раздела XFS с большими inodes на 8 дисках (где число 8 не включает число дисков четности RAID-5 или RAID-6) и размером чанка 128 КБ:

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

Опции монтирования

Включение времени доступа к последнему файлу неэффективно, поскольку файловая система должна обновлять метку времени путем записи данных на диск даже в тех случаях, когда пользователь только читает содержимое файла или когда содержимое файла уже было кэшировано в памяти и доступ к диску не требовался бы вообще. Если вашим пользователям не требуется последнее время доступа, стоит отключить их, добавив noatime к параметрам монтирования. Увеличение количества log buffers, logbufs, logbsize их размера в опциях монтирования лог-файлов позволяет XFS в целом более эффективно обрабатывать и запрашивать отложенные операции с файлами и каталогами.
Также существует несколько вариантов монтирования XFS, которые предназначены для дальнейшей оптимизации потоковой производительности на RAID-массивах, таких как largeio, inode64 и swalloc. Если вы используете XFS и хотите добиться оптимальной пропускной способности потоковой записи, вы также можете добавить опцию монтирования allocsize=131072k, чтобы снизить риск фрагментации для больших файлов. Пожалуйста, учтите, что эта настройка может существенно повлиять на использование временного пространства в системах с большим количеством операций параллельной записи и создания.
Если ваш RAID-контроллер имеет батарейный модуль резервного копирования (BBU) или аналогичную технологию для защиты содержимого кэша от потери питания, добавление опции монтирования nobarrier для XFS или ext4 может значительно увеличить пропускную способность. Обязательно отключите отдельные внутренние кэши подключенных дисков в настройках контроллера, так как они не защищены батареей RAID-контроллера. В примере ниже показана команда для монтирования раздела XFS тома RAID на сервере с батареей RAIDконтроллера. $ mount -noatime,nodiratime,logbufs=8,logbsize=256k,largeio,inode64,swalloc,allocsize=131072k /dev/sdX <mountpoint>

IO Scheduler

Сначала необходимо установить соответствующий планировщик IO Scheduler для файловых серверов:

$ echo deadline > /sys/block/sdX/queue/scheduler

Теперь нужно предоставить IO Scheduler больше возможностей, увеличив количество планируемых запросов:

$ echo 4096 > /sys/block/sdX/queue/nr_requests

Для повышения пропускной способности при последовательном чтении увеличьте максимальный объем считываемых данных. Фактический объем считываемых данных является адаптивным, поэтому использование высокого значения здесь не повредит производительности для малого случайного доступа.

$ echo 4096 > /sys/block/sdX/queue/read_ahead_kb

Virtual Memory Settings

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

$ echo 5 > /proc/sys/vm/dirty_background_ratio
$ echo 10 > /proc/sys/vm/dirty_ratio

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

$ echo 1 > /proc/sys/vm/dirty_background_ratio
$ echo 75 > /proc/sys/vm/dirty_ratio

Назначение чуть более высокого приоритета для кэширования inode помогает избежать поиска диска для загрузки inode:

$ echo 50 > /proc/sys/vm/vfs_cache_pressure

Буферизация данных файловой системы требует частого выделения памяти. Увеличение объема резервируемой памяти ядра позволит быстрее и надежнее выделять память в критических ситуациях. Поднимите соответствующее значение до 64 Мб, если у вас меньше 8 Гб памяти, в противном случае поднимите его как минимум до 256 Мб:

$ echo 262144 > /proc/sys/vm/min_free_kbytes

Transparent huge pages могут привести к снижению производительности при высокой нагрузке из-за частой смены областей кэш-памяти файловой системы. Для версий RHEL 5.x, RHEL 6.x и производных рекомендуется отключить поддержку transparent huge pages по умолчанию, если только огромные страницы не являются явными, запрашиваемыми приложением через madvise():

$ echo madvise > /sys/kernel/mm/redhat_transparent_hugepage/enabled
$ echo madvise > /sys/kernel/mm/redhat_transparent_hugepage/defrag

RHEL 7.x и другие дистрибутивы, рекомендуется включить Transparent huge pages:

$ echo always > /sys/kernel/mm/transparent_hugepage/enabled
$ echo always > /sys/kernel/mm/transparent_hugepage/defrag

Controller Settings

Оптимальная производительность для аппаратных RAID-систем часто зависит от того, как большие операции ввода-вывода отправляются на устройство (за одну большую операцию). Стоит обратится к производителю RAID контроллера для получения соответствующего оптимального размера /sys/block/sdX/max_sectors_kb. Хорошо, если этот размер можно увеличить, чтобы он как минимум соответствовал размеру набора полосок RAID (т.е. chunk_size x number_of_disks):

$ echo 1024 > /sys/block/sdX/queue/max_sectors_kb

Кроме того, высокие значения sg_tablesize (/sys/класс/scsi_host/…/sg_tablesize) рекомендуются для больших IO. Эти значения зависят от версии прошивки контроллера, версии ядра и настроек драйвера.

ZFS (программный RAID)

Программные RAID требуют больше вычислительной мощности, чем традиционные системы с RAID-контроллерами, особенно если включены такие функции, как сжатие данных и контрольные суммы. Поэтому использование ZFS в качестве базовой файловой системы хранения данных потребует больше мощности процессора и оперативной памяти, чем более традиционная установка BeeGFS с аппаратным RAID. Это также повысит важность отключения таких функций, как изменение частоты процессора. Также рекомендуется быть осторожными с опциями, включенными в ZFS, например, такая функция, как дедупликация, использует много ресурсов и может оказать значительное влияние на производительность. Также следует помнить, что такая функция, как сжатие, может испортить результат теста потоковой передачи данных — IOR. Еще одним важным фактором, влияющим на производительность таких систем, является используемая версия пакетов ZFS. На момент написания статьи, последняя версия 0.7.1 все еще имела некоторые проблемы с производительностью. В наших внутренних тестах самая высокая пропускная способность была отмечена в версии 0.6.5.11.

Установка параметров модуля ZFS

После загрузки модуля ZFS установите параметры модуля, перед созданием любого пула ZFS. Необходимо увеличить максимальный размер блоков данных, которые впоследствии могут быть определены для каждого пула хранения ZFS. Это можно сделать, установив новое значение параметра zfs_max_recordsize, в байтах, следующим образом. В зависимости от загруженности вашей системы, вы можете захотеть установить различные размеры записей для ZFSпулов, поэтому повышение этого лимита даст вам больше возможностей настройки в дальнейшем.

$ echo 4194304 > /sys/module/zfs/parameters/zfs_max_recordsize

IO Scheduler

Установите планировщик ввода-вывода, используемый ZFS. Хорошими вариантами являются как Noop, так и deadline, реализующие простые алгоритмы планирования, так как демон хранилища запускается Controller Settings ZFS (программный RAID) Установка параметров модуля ZFS IO Scheduler одним пользователем Linux:

$ echo deadline > /sys/module/zfs/parameters/zfs_vdev_scheduler

Read Chunk Size

Данные считываются ZFS в чанках данных определённого объёма. Увеличение такого размера может ускорить операции чтения.

$ echo 1310720 > /sys/module/zfs/parameters/zfs_read_chunk_size

Data Prefetch

При обработке запроса на чтение ZFS может предсказать, какие дополнительные данные могут быть запрошены будущими запросами на чтение, и использовать возможность прочитать эти данные заранее, так чтобы при необходимости они уже были найдены в памяти. Эта опция отключена по умолчанию в некоторых релизах ZFS. Установите этот параметр в 0, чтобы активировать предварительную выборку данных, если вы используете вращающиеся диски. Установите значение 1, чтобы отключить эту опцию, если вы используете флэш-устройства, такие как SSD.

$ echo 0 > /sys/module/zfs/parameters/zfs_prefetch_disable

Агрегация данных и его лимитирование

ZFS способна агрегировать небольшие операции ввода-вывода, которые обрабатывают соседние или перекрывающиеся данные, в более крупные операции, чтобы уменьшить количество операций ввода-вывода. Опция zfs_vdev_aggregation_limit устанавливает максимальное количество данных, которое может быть агрегировано, прежде чем операция ввода-вывода будет выполнена на диске.

$ echo 262144 > /sys/module/zfs/parameters/zfs_vdev_aggregation_limit

Создание пулов ZFS для целей хранения данных.

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

$ zpool create -m /data/storage001 storage001 raidz2 sda sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl

RAID-Z2 — рекомендуемый тип пула, так как он обеспечивает хороший баланс между безопасностью данных, накладными расходами на хранение и производительностью по сравнению с пулами с одной (зеркальной) и с тремя (тройной) паритетами. Идеальное количество устройств в каждом пуле зависит от шаблонов ввода-вывода, которые более распространены в системе. В большинстве случаев 12 дисков — это размер пула, который дает наилучшие результаты в плане производительности.

Выравнивание разделов

Список устройств, составляющих пул хранилища, должен содержать целые блочные устройства, чтобы ZFS могла создавать разделы диска с оптимальным выравниванием. Более того, включение в этот список разделов, отформатированных с другими файловыми системами, такими как XFS и ext4, вводит в систему ненужный дополнительный программный уровень со значительными накладными расходами на производительность.

Журнальные устройства

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

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

$ zpool add storage001 log mirror sdx sdy

По умолчанию ZIL обрабатывает только синхронные (не кэшированные) операции записи. Поэтому, так как служба хранения BeeGFS в основном выполняет асинхронные (не кэшированные) операции записи, ZIL с нестандартными настройками будет использоваться BeeGFS только тогда, когда приложения вызывают fsync(), аналогично поведению приложений, имеющих прямой доступ к файловой системе ZFS. Так как большинство приложений редко используют этот syscall с функцией fsync(), ZIL обычно довольно мал по сравнению с кэшем чтения флэш-памяти.

Команда, приведенная ниже, может изменить такое поведение, заставив все операции записи проходить через ZIL. Однако во многих случаях это может привести к снижению производительности, например, когда скорость потоковой записи ZIL ниже скорости потоковой записи в RAID-массиве бэкэнда, поэтому данная настройка не рекомендуется.

$ zfs sync=always

Так как ZIL обычно довольно мал, типичным выбором является использование в качестве ZIL только небольшого раздела флэш-устройства и использование большей части флэш-устройства в качестве читающего кэша.

Кэширующие устройства

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

$ zpool add storage001 cache sdz

Размер блоков

ZFS запрашивает блочные устройства, чтобы узнать размер их секторов, которые будут использоваться в качестве размера блоков vdevs, составляющих пул хранилища. К сожалению, некоторые блочные устройства сообщают неверный размер сектора, в результате чего пул хранилища будет использовать неверный размер блока. Для исправления этого необходимо установить свойство ZFS ashift=9, если у вас 512-байтных дисков секторов, или ashift=12, если у вас 4 КБ дисков секторов. (Используйте ashift=12, если вы не уверены в размере блока).

$ zpool create -o ashift=12 -m /data/storage001 storage001 raidz2 sda sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl

Настройка ZFS пула для цели хранения

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

$ zpool create -f -O compression=off -O recordsize=4M -o ashift=12 -O atime=off -O xattr=off
-m /data/storage001 storage001 raidz2 sda sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl log sdm

Сжатие данных

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

$ zfs set compression=off storage001

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

$ zfs set compression=lz4 storage001

Размер записи

Размер записи — это единица измерения, которую ZFS проверяет, вычисляя контрольные суммы. Большие блоки данных могут уменьшить частоту, с которой вычисляются контрольные суммы, и ускорить операции записи. С другой стороны, такие блоки данных считываются каждый раз при выполнении над ними операции записи. В сценариях, когда размер блока значительно превышает объем данных, обрабатываемых операциями записи, это может негативно сказаться на производительности.

$ zfs set recordsize=4m storage001

Дедупликация

Дедупликация (dedup) — это экономящая место функция, которая работает, сохраняя одну копию нескольких идентичных файлов, хранящихся в файловой системе ZFS. Эта функция оказывает значительное влияние на производительность и должна быть отключена, если в системе достаточно места для хранения.

$ zfs set dedup=off storage001

Неиспользуемые атрибуты

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

$ zfs set atime=off storage001
$ zfs set xattr=off storage001

System BIOS & Power Saving

Для того, чтобы ядро Linux могло корректно определять свойства системы и включать соответствующие оптимизации (например, для систем NUMA), очень важно поддерживать BIOS вашей системы в актуальном состоянии.
Функция динамического масштабирования тактовой частоты процессора для экономии электроэнергии, которая обычно включена по умолчанию, оказывает большое влияние на задержку. Поэтому рекомендуется отключать динамическое масштабирование частоты процессора. В идеале это делается в машинном BIOS, где часто встречаются общие настройки типа Optimize for performance (Оптимизировать для производительности).
Если масштабирование частоты не отключено в машинном BIOS, то последние поколения процессоров Intel требуют добавления в командную строку загрузки ядра параметра intel_pstate=disable, который обычно задается в файле конфигурации системного загрузчика grub. После изменения этого параметра машина должна быть перезагружена.

Если драйвер Intel pstate отключен или неприменим к системе, то масштабирование частоты может быть изменено во время выполнения, например, через:

$ echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor >/dev/null

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

$ cat /proc/cpuinfo

Настройка параллелизма

Worker Threads

Серверы хранения, серверы метаданных и клиенты позволяют контролировать количество рабочих потоков, устанавливая значение tuneNumWorkers (в /etc/beegfs/beegfs-X.conf). В целом, большее количество рабочих потоков позволяет добиться большего параллелизма (например, сервер будет параллельно работать с большим количеством клиентских запросов). Но большее количество сотрудников также приводит к более активному параллельному доступу к дискам, поэтому, особенно на серверах хранения данных, идеальное количество сотрудников может зависеть от количества используемых вами дисков.

Metadata service tuning

Общие примечания

Здесь представлены некоторые советы и рекомендации по улучшению производительности серверов метаданных BeeGFS. Как обычно, оптимальные настройки зависят от вашего конкретного аппаратного обеспечения и сценариев использования, поэтому вы должны использовать эти настройки только в качестве отправной точки для ваших усилий по настройке. Такие инструменты бенчмаркинга, как mdtest, помогут вам определить лучшие настройки для ваших серверов метаданных BeeGFS.
Некоторые из предложенных здесь настроек не являются постоянными и будут возвращены после следующей перезагрузки. Для того, чтобы они оставались постоянными, вы можете добавить соответствующие команды в /etc/rc.local, как показано в примере ниже, использовать /etc/sysctl.conf или создать правила udev для их автоматического повторного применения при загрузке машины.

echo 5 > /proc/sys/vm/dirty_background_ratio
echo 20 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/vfs_cache_pressure
echo 262144 > /proc/sys/vm/min_free_kbytes
echo 1 > /proc/sys/vm/zone_reclaim_mode

echo always > /sys/kernel/mm/transparent_hugepage/enabled
echo always > /sys/kernel/mm/transparent_hugepage/defrag

devices=(sda sdb)
for dev in "${devices[@]}"
do
  echo deadline > /sys/block/${dev}/queue/scheduler
  echo 128 > /sys/block/${dev}/queue/nr_requests
  echo 128 > /sys/block/${dev}/queue/read_ahead_kb
  echo 256 > /sys/block/${dev}/queue/max_sectors_kb
done

Вот некоторые общие рекомендации, которые следует рассмотреть. Доступ к метаданным обычно состоит из множества небольших случайных чтений и записей. Поскольку малые объемы случайной записи неэффективны на RAID-5 и RAID-6 (из-за накладных расходов, связанных с чтением-изменением-записью), обычно рекомендуется хранить метаданные на томах RAID-1 или RAID-10.
Как и в случае с объектами хранения, разделы должны быть выровнены по полосам. Знакомитесь с руководством по выравниванию разделов, описано выше.

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

Расширенные атрибуты (EA)

Метаданные BeeGFS хранятся в виде расширенных атрибутов (EA) в базовой файловой системе для оптимальной производительности. Для каждого файла, который создается пользователем, будет создан один файл метаданных. Об использовании расширенных атрибутов: файлы метаданных BeeGFS имеют размер 0 байт (т.е. нет обычного содержимого файла). Доступ к расширенным атрибутам возможен с помощью инструмента getfattr. Если inode базовой файловой системы достаточно большие, то EA могут быть инкапсулированы в inode базовой файловой системы. В этом случае дополнительные блоки данных больше не понадобятся, а использование диска с метаданными будет сокращено. При встраивании EA в inode задержки доступа уменьшаются, так как поиск дополнительных блоков данных больше не требуется. Для резервного копирования метаданных не забудьте установить соответствующие опции для включения расширенных атрибутов, поскольку некоторые инструменты не поддерживают копирование советников или не копируют EA по умолчанию.

Аппаратный RAID

Выравнивание разделов и настройки RAID в локальной файловой системе

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

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

Настройка пропускной способности сервера метаданных

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

Опции форматирования

При форматировании раздела ext4 важно включить опции, которые минимизируют время доступа к большим каталогам (-Odir_index), создавать большие inodes, позволяющие хранить метаданные BeeGFS в виде расширенных атрибутов непосредственно внутри inodes для максимальной производительности (-I 512), резервировать достаточное количество inodes (-i 2048), а также использовать большой журнал (-J size=400):

$ mkfs.ext4 -i 2048 -I 512 -J size=400 -Odir_index,filetype /dev/sdX

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

По мере увеличения размера метаданных с увеличением количества целей на файл, следует использовать -I 1024, если вы планируете использовать по умолчанию более 4 целей на файл, или если вы планируете использовать ACL или хранить расширенные атрибуты на стороне клиента.

В связи с тем, что ext4 имеет фиксированное количество доступных inodes, возможно исчерпание доступных inodes, даже если доступно свободное место на диске. Таким образом, важно тщательно выбирать количество inodes в соответствии с вашими потребностями, если ваш диск с метаданными мал. Вы можете проверить количество доступных inodes, используя df -ih после форматирования. Если вам нужно избежать такого ограничения, используйте другую файловую систему (например, xfs) вместо ext4.

По умолчанию ext4 не позволяет процессам пользовательского пространства хранить расширенные атрибуты (EA). Если демон beegfs-meta настроен на использование EA, то базовая файловая система должна быть смонтирована с помощью опции user_xattr. Эта опция также может постоянно храниться в суперблоке:

$ tune2fs -o user_xattr /dev/sdX

(некоторые дистрибутивы linux предоставляют только старую версию tune2fs, которая пока не может обрабатывать опцию -o user_xattr‘ Новая версия может быть доступна под именем tune4fs).

В системах, где ожидается наличие каталогов с большим количеством записей (более 10 миллионов), опция large_dir должна быть указана вместе с dir_index. Эта опция увеличивает емкость индекса каталогов и доступна в ядре Linux 4.13 или новее. Тем не менее, наличие большого количества записей в одном каталоге не является хорошей практикой с точки зрения производительности. Поэтому следует рекомендовать конечным пользователям распространять свои файлы по нескольким подкаталогам, даже если используется опция large_dir.

Опции монтирования

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

Если ваш RAID-контроллер имеет батарейный модуль резервного копирования (BBU) или аналогичную технологию для защиты содержимого кэша от потери питания, добавление опции монтирования nobarrier для XFS или ext4 может значительно увеличить пропускную способность. Обязательно отключите отдельные внутренние кеша подключенных дисков в настройках контроллера, так как они не защищены батареей RAID-контроллера.

В приведенной ниже команде показаны типичные варианты монтирования для серверов метаданных BeeGFS с батареей RAID-контроллера:

$ mount - noatime,nodiratime /dev/sdX <mountpoint>

IO Scheduler

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

$ echo deadline > /sys/block/sdX/queue/scheduler

Чтобы избежать задержек, количество планируемых запросов не должно быть слишком большим, значение по умолчанию в linux, равное 128, является приемлемым.

$ echo 128 > /sys/block/sdX/queue/nr_requests

При настройке серверов метаданных следует помнить, что зачастую речь идет не столько о пропускной способности, сколько о задержке, а также о некоторой степени корректности: Вероятно, на вашем кластере есть также несколько интерактивных пользователей, которые хотят видеть результаты своих ls и других команд в приемлемое время, поэтому вам следует попробовать поработать над этим. Это означает, например, что вы, вероятно, не захотите устанавливать высокое значение для /sys/block/sdX/iosched/read_expire на серверах метаданных, чтобы убедиться, что пользователи не будут слишком долго ждать завершения своих операций.

Virtual Memory Settings

Transparent huge pages могут привести к снижению производительности при высокой нагрузке и даже к проблемам со стабильностью на различных типах систем. Для RHEL 5.x, 6.x и производных настоятельно рекомендуется отключать transparent huge pages, если только приложение не запросило огромные страницы в явном виде через madvise:

$ echo madvise > /sys/kernel/mm/redhat_transparent_hugepage/enabled
$ echo madvise > /sys/kernel/mm/redhat_transparent_hugepage/defrag

Для RHEL 7.x и других дистрибутивов рекомендуется включить прозрачные огромные страницы:

$ echo always > /sys/kernel/mm/transparent_hugepage/enabled
$ echo always > /sys/kernel/mm/transparent_hugepage/defrag

ZFS (программный RAID)

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

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

Другим важным фактором, влияющим на производительность в таких системах, является используемая версия пакетов ZFS. На момент написания статьи в последней версии 0.7.1 все еще оставались некоторые проблемы с производительностью. В наших внутренних тестах самая высокая пропускная способность была отмечена в версии 0.6.5.11.

Настройка параметров модуля ZFS

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

Планировщик ввода-вывода

Установите планировщик ввода-вывода, используемый ZFS. Как Noop, так и deadline, реализующие простые алгоритмы планирования, являются хорошими вариантами, так как демон метаданных запускается одним пользователем Linux.

$ echo deadline > /sys/module/zfs/parameters/zfs_vdev_scheduler

Агрегация данных и его лимитирование

$ echo 262144 > /sys/module/zfs/parameters/zfs_vdev_aggregation_limit

Создание пулов ZFS для целей метаданных

$ zpool create -m /data/meta001 meta001 mirror sda sdb

Защита данных

Типы пулов RAID-Z не рекомендуются для целей метаданных из-за влияния обновлений четности на производительность. Рекомендуемый тип является зеркальным, если только безопасность данных не считается более важной, чем производительность метаданных. В этом случае следует использовать RAID-Z1.

Выравнивание разделов

Настройка пулов ZFS для целей метаданных

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

$ zpool create -f -O compression=lz4 -O atime=off -O xattr=sa -m /data/meta001 meta001 mirror sda sdb

Сжатие данных

$ zfs set compression=lz4 meta001

Расширенные атрибуты

Как объяснялось ранее, метаданные BeeGFS хранятся в виде расширенных атрибутов файлов, поэтому эта функция должна быть включена следующим образом. Пожалуйста, обратите внимание, что опция xattr должна быть установлена на sa, а не включена по умолчанию. Механизм по умолчанию хранит расширенные атрибуты как отдельные скрытые файлы. Механизм sa встраивает их в сами файлы, к которым они принадлежат, что делает управление расширенными атрибутами намного более эффективным.

$ zfs set xattr=sa meta001

Дедупликация

$ zfs set dedup=off storage001

Неиспользуемые атрибуты

Служба хранения BeeGFS не обновляет время доступа. Таким образом, это свойство может быть отключено в ZFS-пулах следующим образом.

$ zfs set atime=off meta001

System BIOS & Power Saving

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

Функция динамического масштабирования тактовой частоты процессора для экономии электроэнергии, которая обычно включена по умолчанию, оказывает большое влияние на задержку. Поэтому рекомендуется отключать динамическое масштабирование частоты процессора. В идеале это делается в машинном BIOS, где часто встречаются общие настройки типа Optimize for performance (Оптимизировать для производительности).

Если масштабирование частоты не отключено в машинном BIOS, то при последних поколениях Intel CPU в командную строку загрузки ядра необходимо добавить параметр intel_pstate=disable, который обычно задается в файле конфигурации системного загрузчика grub. После изменения этого параметра машина должна быть перезагружена.

$ echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor >/dev/null

$ cat /proc/cpuinfo

Настройка параллелизма

Worker Threads

Серверы хранения, серверы метаданных и клиенты позволяют контролировать количество рабочих потоков, устанавливая значение tuneNumWorkers (в /etc/beegfs/beegfs-X.conf). В целом, большее количество рабочих потоков позволяет добиться большего параллелизма (например, сервер будет параллельно работать с большим количеством клиентских запросов). Для небольших кластеров в диапазоне 100-200 вычислительных узлов необходимо в beegfs-meta.conf установить как минимум tuneNumWorkers=64. Для больших кластеров больше подходит tuneNumWorkers=128.

Параллельные сетевые запросы

Каждый сервер метаданных устанавливает несколько соединений с каждым из других серверов для обеспечения большего параллелизма на сетевом уровне, имея несколько запросов в работе к одному и тому же серверу. Опция настройки connMaxInternodeNum в /etc/beegfs/beegfs-meta.conf может быть использована для настройки количества одновременных подключений.

Client service tuning

Настройка параллельных сетевых запросов

Каждый клиент BeeGFS устанавливает несколько сетевых соединений к одному серверу, что позволяет клиенту иметь несколько активных сетевых запросов к этому серверу.
Количество подключений с конкретного клиента к одному серверу можно настроить, установив значение connMaxInternodeNum в файле /etc/beegfs/beegfs-client.conf.
Увеличение числа подключений может повысить производительность и скорость реагирования для определенных рабочих нагрузок.
При увеличении значения чрезвычайно важно помнить о результирующем использовании оперативной памяти для сетевых буферов на серверах, особенно для Infiniband и более крупных кластеров. Обязательно прочитайте комментарии для connMaxInternodeNum и connRDMABufSize в beegfs-client.conf, чтобы узнать больше об использовании оперативной памяти на сервере. Обратите внимание, что connRDMABufSize должен быть целым числом, кратным 4 KiB.
На вычислительном узле обычно нет смысла устанавливать это число выше, чем количество ядер процессора. На узле входа в кластер установка этого значения выше, чем количество ядер процессора, может помочь улучшить отзывчивость, когда активны несколько пользователей.
Клиенты BeeGFS устанавливают соединения только тогда, когда они необходимы (и завершают их после некоторого времени простоя). Используйте команду beegfs-net на клиенте, чтобы увидеть количество текущих соединений с каждым из серверов.
beegfs-net содержится в пакете beegfs-utils. Общее пространство, используемое буферами (connRDMABufSize x connRDMABufNum) должно быть больше или равно размеру фрагмента данных, чтобы сообщения, передаваемые между клиентом и серверами хранения, не нужно было разбивать, чтобы уместиться в доступных буферах. Настройки RDMA по умолчанию (connRDMABufSize = 64 КБ, connRDMABufNum = 12) подойдут для размера чанка по умолчанию 512 КБ. Если задать размер чанка 1 МБ и размер буфера 64 КБ, то количество буферов должно быть не менее 1 МБ / 64 КБ + 4 дополнительных буClient service tuning Настройка параллельных сетевых запросов Каждый клиент BeeGFS устанавливает несколько сетевых соединений к одному серверу, что позволяет клиенту иметь несколько активных сетевых запросов к этому серверу.Количество подключений с конкретного клиента к одному серверу можно настроить, установив значение connMaxInternodeNum в файле /etc/beegfs/beegfs-client.conf.Увеличение числа подключений может повысить производительность и скорость реагирования для определенных рабочих нагрузок.При увеличении значения чрезвычайно важно помнить о результирующем использовании оперативной памяти для сетевых буферов на серверах, особенно для Infiniband и более крупных кластеров. Обязательно прочитайте комментарии для connMaxInternodeNum и connRDMABufSize в beegfs-client.conf, чтобы узнать больше об использовании оперативной памяти на сервере. Обратите внимание, что connRDMABufSize должен быть целым числом, кратным 4 KiB.На вычислительном узле обычно нет смысла устанавливать это число выше, чем количество ядер процессора. На узле входа в кластер установка этого значения выше, чем количество ядер процессора, может помочь улучшить отзывчивость, когда активны несколько пользователей.Клиенты BeeGFS устанавливают соединения только тогда, когда они необходимы (и завершают их после некоторого времени простоя). Используйте команду beegfs-net на клиенте, чтобы увидеть количество текущих соединений с каждым из серверов.beegfs-net содержится в пакете beegfs-utils. Общее пространство, используемое буферами (connRDMABufSize x connRDMABufNum) должно быть больше или равно размеру фрагмента данных, чтобы сообщения, передаваемые между клиентом и серверами хранения, не нужно было разбивать, чтобы уместиться в доступных буферах. Настройки RDMA по умолчанию (connRDMABufSize = 64 КБ, connRDMABufNum = 12) подойдут для размера чанка по умолчанию 512 КБ. Если задать размер чанка 1 МБ и размер буфера 64 КБ, то количество буферов должно быть не менее 1 МБ / 64 КБ + 4 дополнительных буфера для протокола, то есть 20 в данном примере.Remote fsync Клиенты BeeGFS имеют возможность конфигурирования для управления поведением, когда пользовательское приложение вызывает fsync(). Опция называется tuneRemoteFSync в файле /etc/beegfs/beegfs-client.conf.Клиент может либо принудительно зафиксировать эти данные на дисках сервера с помощью функции fsync() (=> tuneRemoteFSync=true), либо только удостфера для протокола, то есть 20 в данном примере.

Remote fsync

Клиенты BeeGFS имеют возможность конфигурирования для управления поведением, когда пользовательское приложение вызывает fsync(). Опция называется tuneRemoteFSync в файле /etc/beegfs/beegfs-client.conf.
Клиент может либо принудительно зафиксировать эти данные на дисках сервера с помощью функции fsync() (=> tuneRemoteFSync=true), либо только удостовериться, что данные передаются в серверный кэш (=> tuneRemoteFSync=false). Отключение удаленной fsync может значительно уменьшить поиск диска и таким образом улучшить производительность для приложений, которые используют много вызовов fsync().

Отключить locate/mlocate/updatedb

Некоторые дистрибутивы Linux по умолчанию устанавливают утилиту locate, которая сканирует все файловые системы один раз в день для создания базы данных существующих файлов. В кластере вы, конечно, не захотите, чтобы все ваши вычислительные узлы сканировали всю файловую систему BeeGFS каждый день. Либо отключите эту службу, если она вам не нужна, либо отредактируйте файл /etc/updatedb.conf, чтобы убедиться, что тип файловой системы «beegfs» содержится в списке PRUNEFS, а ваша BeeGFS точка монтирования находится в списке PRUNEPATHS.

Native Infiniband / RoCE / Omni-Path Support (RDMA)

Поддержка RDMA для Infiniband, RoCE (RDMA через Converged Ethernet) и Omni-Path в BeeGFS основана на Open Fabrics Enterprise Distribution ibverbs API (http://www.openfabrics.org).

Клиенты

Чтобы включить RDMA, модули клиентского ядра BeeGFS должны быть скомпилированы с поддержкой Infiniband. Поддержка Infiniband клиента включается установкой соответствующей опции buildArgs в файле автосборки клиента (/etc/beegfs/beegfs-client-autobuild.conf). Этот файл также содержит более подробную информацию о значениях, которые необходимо установить, чтобы включить поддержку Infiniband.

Серверы

До BeeGFS v7.0: Коммуникационная библиотека BeeGFS OpenTk (libbeegfs-opentk.so) для сервисов пользовательского пространства поставляется с предустановленной поддержкой Infiniband и без нее. Вы можете использовать следующую команду, чтобы включить версию общей библиотеки с родной поддержкой Infiniband:

$ beegfs-setup-rdma

(эта команда автоматически выполняется после установки пакета beegfs-opentk-lib).

BeeGFS v7.1 и новее: Нужно установить пакет libbeegfs-ib. После этого BeeGFS автоматически включит поддержку RDMA, если установлено аппаратное обеспечение и драйверы.

Проверка подключения Infiniband

Во время выполнения программы вы можете проверить, были ли обнаружены ваши IB-устройства с помощью онлайн-конфигуратора BeeGFS. В режиме инструмента LISTNODES будет показан список всех зарегистрированных сервисов и их сконфигурированных сетевых интерфейсов в порядке предпочтений. Слово RDMA будет добавлено к интерфейсам, которые включены для родного Infiniband протокола. Используйте следующую команду, чтобы перечислить службы и их доступные сетевые интерфейсы:

$ beegfs-ctl --listnodes --nodetype=storage --details
$ beegfs-ctl --listnodes --nodetype=meta --details
$ beegfs-ctl --listnodes --nodetype=client --details

Чтобы проверить, соединяются ли клиенты с серверами через RDMA или они возвращаются к TCP из-за проблем с конфигурацией, используйте следующую команду, чтобы просмClient service tuning Настройка параллельных сетевых запросов Каждый клиент BeeGFS устанавливает несколько сетевых соединений к одному серверу, что позволяет клиенту иметь несколько активных сетевых запросов к этому серверу.

Количество подключений с конкретного клиента к одному серверу можно настроить, установив значение connMaxInternodeNum в файле /etc/beegfs/beegfs-client.conf.

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

При увеличении значения чрезвычайно важно помнить о результирующем использовании оперативной памяти для сетевых буферов на серверах, особенно для Infiniband и более крупных кластеров. Обязательно прочитайте комментарии для connMaxInternodeNum и connRDMABufSize в beegfs-client.conf, чтобы узнать больше об использовании оперативной памяти на сервере. Обратите внимание, что connRDMABufSize должен быть целым числом, кратным 4 KiB.

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

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

beegfs-net содержится в пакете beegfs-utils. Общее пространство, используемое буферами (connRDMABufSize x connRDMABufNum) должно быть больше или равно размеру фрагмента данных, чтобы сообщения, передаваемые между клиентом и серверами хранения, не нужно было разбивать, чтобы уместиться в доступных буферах. Настройки RDMA по умолчанию (connRDMABufSize = 64 КБ, connRDMABufNum = 12) подойдут для размера чанка по умолчанию 512 КБ. Если задать размер чанка 1 МБ и размер буфера 64 КБ, то количество буферов должно быть не менее 1 МБ / 64 КБ + 4 дополнительных буClient service tuning Настройка параллельных сетевых запросов Каждый клиент BeeGFS устанавливает несколько сетевых соединений к одному серверу, что позволяет клиенту иметь несколько активных сетевых запросов к этому серверу.

beegfs-net содержится в пакете beegfs-utils. Общее пространство, используемое буферами (connRDMABufSize x connRDMABufNum) должно быть больше или равно размеру фрагмента данных, чтобы сообщения, передаваемые между клиентом и серверами хранения, не нужно было разбивать, чтобы уместиться в доступных буферах. Настройки RDMA по умолчанию (connRDMABufSize = 64 КБ, connRDMABufNum = 12) подойдут для размера чанка по умолчанию 512 КБ. Если задать размер чанка 1 МБ и размер буфера 64 КБ, то количество буферов должно быть не менее 1 МБ / 64 КБ + 4 дополнительных буфера для протокола, то есть 20 в данном примере.

Remote fsync Клиенты BeeGFS имеют возможность конфигурирования для управления поведением, когда пользовательское приложение вызывает fsync(). Опция называется tuneRemoteFSync в файле /etc/beegfs/beegfs-client.conf.

Клиент может либо принудительно зафиксировать эти данные на дисках сервера с помощью функции fsync() (=> tuneRemoteFSync=true), либо только удостфера для протокола, то есть 20 в данном примере.

Клиент может либо принудительно зафиксировать эти данные на дисках сервера с помощью функции fsync() (=> tuneRemoteFSync=true), либо только удостовериться, что данные передаются в серверный кэш (=> tuneRemoteFSync=false). Отключение удаленной fsync может значительно уменьшить поиск диска и таким образом улучшить производительность для приложений, которые используют много вызовов fsync().

Отключить locate/mlocate/updatedb Некоторые дистрибутивы Linux по умолчанию устанавливают утилиту locate, которая сканирует все файловые системы один раз в день для создания базы данных существующих файлов. В кластере вы, конечно, не захотите, чтобы все ваши вычислительные узлы сканировали всю файловую систему BeeGFS каждый день. Либо отключите эту службу, если она вам не нужна, либо отредактируйте файл /etc/updatedb.conf, чтобы убедиться, что тип файловой системы «beegfs» содержится в списке PRUNEFS, а ваша BeeGFS точка монтирования находится в списке PRUNEPATHS.

Native Infiniband / RoCE / Omni-Path Support (RDMA) Поддержка RDMA для Infiniband, RoCE (RDMA через Converged Ethernet) и Omni-Path в BeeGFS основана на Open Fabrics Enterprise Distribution ibverbs API (http://www.openfabrics.org).

Клиенты Чтобы включить RDMA, модули клиентского ядра BeeGFS должны быть скомпилированы с поддержкой Infiniband. Поддержка Infiniband клиента включается установкой соответствующей опции buildArgs в файле автосборки клиента (/etc/beegfs/beegfs-client-autobuild.conf). Этот файл также содержит более подробную информацию о значениях, которые необходимо установить, чтобы включить поддержку Infiniband.

Серверы До BeeGFS v7.0: Коммуникационная библиотека BeeGFS OpenTk (libbeegfs-opentk.so) для сервисов пользовательского пространства поставляется с предустановленной поддержкой Infiniband и без нее. Вы можете использовать следующую команду, чтобы включить версию общей библиотеки с родной поддержкой Infiniband:

$ beegfs-setup-rdma (эта команда автоматически выполняется после установки пакета beegfs-opentk-lib).отреть список установленных соединений на клиенте:

$ beegfs-net

(Обратите внимание, что данная команда считывает информацию из /proc/fs/beegfs/<clientID>/X_nodes).

В дополнение к вышеприведенным командам в лог-файлах также содержится информация об установленных соединениях и сбоях в соединениях (если вы используете, по крайней мере, logLevel=3). В каталоге /var/log/beegfs-X.log на клиентах и серверах.

Общие настройки настройки настройки Infiniband

Замечание: Типичным источником проблем является работа службы ibacm (/etc/init.d/ibacm) на устройствах. Эта служба вызывает попытки RDMA-соединений и должна быть отключена на всех узлах.

Внимание!: Ядро RHEL 3.10.0-327 ввело новый эвристический подход к безопасности, который привел к несовместимости с тем, как службы BeeGFS обрабатывают соединения RDMA. Эта проблема была решена в BeeGFS 2015.03-r16. Пожалуйста, убедитесь, что вы используете совместимый выпуск.

Параметры RDMA-соединения на стороне клиента/сервера в файле /etc/beegfs/beegfs-client.conf следующие

connRDMABufSize Максимальный размер буфера (в байтах), который будет передаваться по сети.
Несколько буферов (определяемых коннектором ConnRDMABufNum) передаются параллельно на одно соединение.
connRDMABufSize должен быть целым числом, кратным 4 KiB.
Клиент должен выделить этот буфер как физически непрерывные страницы.
Слишком большие значения (>64КиБ) могут привести к ошибкам в распределении страниц.
connRDMABufNum Количество доступных буферов, которые могут быть в пути для одного соединения.
connMaxInternodeNum Количество параллельных подключений, которые клиент может установить к каждому из серверов.
Соединения устанавливаются только при необходимости, а также отбрасываются, когда они простаивают некоторое время.

Примечание:

Использование оперативной памяти на одно соединение: connRDMABufSize x connRDMABufNum x 2
Помните о максимальном использовании оперативной памяти на сервере при увеличении этих значений: connRDMABufSize x connRDMABufNum x 2 x connMaxInternodeNum x number_of_clients
connMaxInternodeNum — это общий параметр настройки сети в (клиентском) файле конфигурации Максимальное количество одновременных подключений к одному узлу.

Intel/QLogic TrueScale Infiniband Tuning

Настройте параметры буфера RDMA в файле /etc/beegfs/beegfs-client.conf.
Увеличить размер коннектора connRDMABufSize до 65536 (64КиБ).
Сократите connRDMABufNum до 12
Установить дополнительный пакет libipathverbs.
Модуль ib_qib должен быть настроен, по крайней мере, на стороне сервера.
В /etc/modprobe.conf или /etc/modprobe.d/ib_qib.conf опции ib_qib singleport=1 krcvqs=4 rcvhdrcnt=4096
Замечание: Оптимальное значение krcvqs=<значение> зависит от количества ядер процессора. Это значение резервирует заданное количество очередей получения для ibverbs.
Пожалуйста, ознакомьтесь с примечаниями к выпуску Intel/QLogic OFED для получения более подробной информации.

На больших кластерах вам может потребоваться адаптировать параметры на серверах, чтобы позволить принимать большее количество входящих RDMA-соединений, например:

Опции драйвера:

lkey_table_size=18, max_qp_wrs=131072, max_qps=131072, qp_table_size=2048

Число сопоставлений:

echo 1000000 > /proc/sys/vm/max_map_count

(используйте sysctl, чтобы сделать это изменение постоянным)

Обработчики файлов:

ulimit -n 262144

(используйте /etc/security/limits, чтобы сделать это изменение постоянным)

Intel Omni-Path Architecture (OPA) Tuning

Настройте параметры буфера RDMA в файле /etc/beegfs/beegfs-client.conf.
Увеличьте размер connRDMABufSize to 65536 (64KiB)
Сократить connRDMABufNum до 12
Intel Omni-Path предоставляет режим под названием «Ускоренное RDMA» для повышения производительности большого объема передач, который по умолчанию выключен. Информацию о том, как включить этот режим, см. в главе «Руководство по настройке производительности Intel Omni-Path» «Ускоренное разрешение на возврат в случае отказа».

Mellanox Infiniband Tuning

На больших кластерах может понадобиться установить опции драйвера log_mtts_per_seg и log_num_mtt mlx, чтобы разрешить большее количество RDMA-соединений. Эта опция обычно устанавливается в файле /etc/modprobe.d/mlx4_core.conf.
Для Mellanox DDR/QDR/FDR: Настройки по умолчанию connRDMABufSize/connRDMABufNum хороши.
Для Mellanox EDR: Увеличить размер connRDMABufSize до 32768 (32КиБ). Сократить connRDMABufNum до 22

Дополнительные примечания

В кластере с поддержкой RDMA некоторые BeeGFS-коммуникации (особенно связь со службой управления, которая не является критичной с точки зрения производительности) используют TCP/IP и UDP/IP-передачу. На некоторых системах «подключенный» режим IP-over-IB IniniBand и Omni-Path по умолчанию не работает хорошо и приводит к ложным срабатываниям. В этом случае следует попробовать переключить режим IPoIB на «datagram» на всех хостах:

$ echo datagram > /sys/class/net/ibX/mode

Ethernet & IP Network Tuning

Настройки Ethernet и TCP

Настройка сети может быть применена к клиентам и серверам. Часто она основана на настройке общих параметров TCP. Наиболее важные настройки здесь включают в себя масштабирование окна TCP, размеры буфера и метки времени. Эти настройки могут быть изменены путем записи в файлы в /proc/sys/net/ipv4 или с помощью sysctl. Провайдеры сетевого оборудования обычно размещают список рекомендуемых настроек на своих сайтах.
Ваш дистрибутив также может поставляться с различными реализациями TCP, которые обеспечивают лучшую оптимизацию для высокоскоростных сетей, чем стандартная реализация TCP.
Для Ethernet также очень важно включить управление потоком на сетевых картах (например, с помощью ethtool) и на коммутаторе. Также необходимо отключить настройки управления широковещательным или штормовым режимом на Ethernet-коммутаторе, чтобы они не мешали высокоскоростным параллельным потоковым файлам.
В некоторых сетях Ethernet TSO (TCP segmentation offload — разгрузка сегментации) и GSO (generic segmentation offload — разгрузка общей сегментации) также могут вызывать проблемы с параллельными файловыми потоками, такие как значительное снижение пропускной способности. Оба они могут быть отключены с помощью ethtool, но их следует отключать только в том случае, если вы убедились, что они вызывают проблемы.
Активация jumbo-фреймов — это еще одна конфигурация, которую следует учитывать в сетях Ethernet. Она увеличивает объем данных, передаваемых каждым Ethernet-кадром, и, следовательно, помогает BeeGFS достичь более высокой пропускной способности. Однако такая конфигурация требует, чтобы все элементы маршрутов между службами BeeGFS (т.е. коммутаторы, маршрутизаторы, сетевые карты) были сконфигурированы так, чтобы принимать большие кадры.

Neighbor Table Sizes для разрешения адресов (ARP)

В сетях с большим количеством интерфейсов размеры таблиц соседних устройств по умолчанию для поиска ARP (Address Resolution Protocol) обычно слишком малы, что приводит к ошибке «Neighbour table overflow». Это особенно актуально для службы управления BeeGFS, которая взаимодействует со всеми другими службами BeeGFS и в таких случаях отключается из-за критической ошибки связи, которая не позволяет ей корректно контролировать зарегистрированные сервисы BeeGFS.

Чтобы предотвратить системную ошибку Neighbour table overflow, поднимите пороговое значение net.ipv4.neigh.default.gc_thresh1 в файле /etc/sysctl.conf (или используйте инструмент sysctl). Значение по умолчанию 128 должно быть увеличено, если система имеет более 128 интерфейсов, которые могут быть использованы BeeGFS. Например, система состоит из 129 узлов с 1 сетевым интерфейсом (IP-адресом) каждый, или 65 узлов с 2 интерфейсами каждый, или 43 узлов с 3 интерфейсами.

Другими словами, значение gc_tresh1 должно быть больше, чем количество всех IP-адресов, используемых BeeGFS. Таким образом, если у вас 200 клиентов с 2 IP-адресами каждый и 10 серверов с 3 IP-адресами каждый, то значение gc_thresh1 должно быть не менее 200 * 2 + 10 * 3 = 460. Поскольку также может существовать связь между BeeGFS хостами и другими машинами из сети или интернета, было бы неплохо округлить значение, например, до 512 в этом примере.

Кроме того, следует также увеличить другие пороговые значения gc_thresh. Вы можете удвоить их, например, установив gc_thresh2=1024 и gc_thresh3=2048.

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

Брандмауэры / Трафик UDP-датаграмм / Трансляция сетевых адресов (NAT)

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

$ beegfs-ctl --listnodes --nodetype=management --nicdetails

Все службы BeeGFS используют фиксированные TCP/UDP порты. Единственным исключением являются утилиты beegfs-ctl и beegfs-fsck, которые также используют UDP, но должны использовать случайный UDP-порт (потому что должно быть возможно, что произвольное количество экземпляров утилиты beegfs-ctl может быть запущено одновременно на одной машине).
В общем, не обязательно, чтобы beegfs-ctl мог запускаться на вычислительных узлах, но это полезно для пользователей, если это возможно, например, для проверки статистики (beegfs-ctl —userstats) или для запроса инфEthernet & IP Network Tuning Настройки Ethernet и TCP Настройка сети может быть применена к клиентам и серверам. Часто она основана на настройке общих параметров TCP. Наиболее важные настройки здесь включают в себя масштабирование окна TCP, размеры буфера и метки времени. Эти настройки могут быть изменены путем записи в файлы в /proc/sys/net/ipv4 или с помощью sysctl. Провайдеры сетевого оборудования обычно размещают список рекомендуемых настроек на своих сайтах.Ваш дистрибутив также может поставляться с различными реализациями TCP, которые обеспечивают лучшую оптимизацию для высокоскоростных сетей, чем стандартная реализация TCP.Для Ethernet также очень важно включить управление потоком на сетевых картах (например, с помощью ethtool) и на коммутаторе. Также необходимо отключить настройки управления широковещательным или штормовым режимом на Ethernet-коммутаторе, чтобы они не мешали высокоскоростным параллельным потоковым файлам.В некоторых сетях Ethernet TSO (TCP segmentation offload — разгрузка сегментации) и GSO (generic segmentation offload — разгрузка общей сегментации) также могут вызывать проблемы с параллельными файловыми потоками, такие как значительное снижение пропускной способности. Оба они могут быть отключены с помощью ethtool, но их следует отключать только в том случае, если вы убедились, что они вызывают проблемы.Активация jumbo-фреймов — это еще одна конфигурация, которую следует учитывать в сетях Ethernet. Она увеличивает объем данных, передаваемых каждым Ethernet-кадром, и, следовательно, помогает BeeGFS достичь более высокой пропускной способности. Однако такая конфигурация требует, чтобы все элементы маршрутов между службами BeeGFS (т.е. коммутаторы, маршрутизаторы, сетевые карты) были сконфигурированы так, чтобы принимать большие кадры.Neighbor Table Sizes для разрешения адресов (ARP) В сетях с большим количеством интерфейсов размеры таблиц соседних устройств по умолчанию для поиска ARP (Address Resolution Protocol) обычно слишком малы, что приводит к ошибке «Neighbour table overflow». Это особенно актуально для службы управления BeeGFS, которая взаимодействует со всеми другими службами BeeGFS и в таких случаях отключается из-за критической ошибки связи, которая не позволяет ей корректно контролировать зарегистрированные сервисы BeeGFS.Чтобы предотвратить системную ошибку Neighbour table overflow, поднимите пороговое значение net.ipv4.neigh.default.gc_thresh1 в файле /etc/sysctl.conf (или используйте инструмент sysctl). Значение по умолчанию 128 должно быть увеличено, если система имеет более 128 интерфейсов, которые могут быть использованы BeeGFS. Например, система состоит из 129 узлов с 1 сетевым интерфейсом (IP-адресом) каждый, или 65 узлов с 2 интерфейсами каждый, или 43 узлов с 3 интерфейсами.Другими словами, значение gc_tresh1 должно быть больше, чем количество всех IP-адресов, используемых BeeGFS. Таким образом, если у вас 200 клиентов с 2 IP-адресами каждый и 10 серверов с 3 IP-адресами каждый, то значение gc_thresh1 должно быть не менее 200 * 2 + 10 * 3 = 460. Поскольку также может существовать связь между BeeGFS хостами и другими машинами из сети или интернета, было бы неплохо округлить значение, например, до 512 в этом примере.Кроме того, следует также увеличить другие пороговые значения gc_thresh. Вы можете удвоить их, например, установив gc_thresh2=1024 и gc_thresh3=2048.Наконец, так как эта проблема затрагивает любой процесс, который взаимодействует со слишком большим количеством хостов, вы можете захотеть увеличить эти пороговые значения и на других машинах, а не только на машине, на которой запущена beegfs-mgmtd.Брандмауэры / Трафик UDP-датаграмм / Трансляция сетевых адресов (NAT) TCP-соединения устанавливаются только между клиентами и серверами или между серверами, но никогда не устанавливаются между сервером и клиентом.UDP-пакеты обмениваются между всеми серверами в обоих направлениях и между серверами и клиентами в обоих направлениях.UDP-датаграммы должны иметь возможность путешествовать от серверов к клиентам без отправки какой-либо датаграммы от клиента к серверу в первую очередь. Убедитесь, что этот вид трафика не блокируется, используя клиентов за NAT или установив правила брандмауэра, которые блокируют эту связь.TCP и UDP порты, используемые службами, можно найти в соответствующих конфигурационных файлах (/etc/beegfs/beegfs…conf) или запросив службу управления, например, для портов службы управления: $ beegfs-ctl —listnodes —nodetype=management —nicdetails Все службы BeeGFS используют фиксированные TCP/UDP порты. Единственным исключением являются утилиты beegfs-ctl и beegfs-fsck, которые также используют UDP, но должны использовать случайный UDP-порт (потому что должно быть возможно, что произвольное количество экземпляров утилиты beegfs-ctl может быть запущено одновременно на одной машине).В общем, не обязательно, чтобы beegfs-ctl мог запускаться на вычислительных узлах, но это полезно для пользователей, если это возможно, например, для проверки статистики (beegfs-ctl —userstats) или для запроса информации о квотах (beegfs-ctl —getquota).

Это номера UDP и TCP портов по умолчанию служб BeeGFS:

Management service (beegfs-mgmtd): 8008 Metadata service (beegfs-meta): 8005 Storage service (beegfs-storage): 8003 Client service (beegfs-client): 8004

По умолчанию, клиент также устанавливает TCP соединения со службой поддержки пользователей (beegfs-helperd) на той же машине для DNS поиска и протоколирования на TCP порту 8006.
В общем, не требуется, чтобы все службы BeeGFS одного типа использовали один и тот же TCP или UPD порт, например, могут быть некоторые службы метаданных, использующие порт 8005, в то время как другие службы метаданных, подключающиеся к той же службе управления и, таким образом, являющиеся частью одного и того же пространства имён файловой системы, могут использовать разные порты. Однако по умолчанию все службы одного и того же типа используют один и тот же порт.

Striping

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

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

Следующая команда покажет вам текущие настройки stripe в корневом каталоге для монтирования BeeGFS (в данном случае /mnt/beegfs):

$ beegfs-ctl --getentryinfo /mnt/beegfs

Используйте режим setpattern , чтобы применить новые настройки чередования к каталогу (в данном случае «чередовEthernet & IP Network Tuning Настройки Ethernet и TCP Настройка сети может быть применена к клиентам и серверам. Часто она основана на настройке общих параметров TCP. Наиболее важные настройки здесь включают в себя масштабирование окна TCP, размеры буфера и метки времени. Эти настройки могут быть изменены путем записи в файлы в /proc/sys/net/ipv4 или с помощью sysctl. Провайдеры сетевого оборудования обычно размещают список рекомендуемых настроек на своих сайтах.

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

Для Ethernet также очень важно включить управление потоком на сетевых картах (например, с помощью ethtool) и на коммутаторе. Также необходимо отключить настройки управления широковещательным или штормовым режимом на Ethernet-коммутаторе, чтобы они не мешали высокоскоростным параллельным потоковым файлам.

В некоторых сетях Ethernet TSO (TCP segmentation offload — разгрузка сегментации) и GSO (generic segmentation offload — разгрузка общей сегментации) также могут вызывать проблемы с параллельными файловыми потоками, такие как значительное снижение пропускной способности. Оба они могут быть отключены с помощью ethtool, но их следует отключать только в том случае, если вы убедились, что они вызывают проблемы.

Активация jumbo-фреймов — это еще одна конфигурация, которую следует учитывать в сетях Ethernet. Она увеличивает объем данных, передаваемых каждым Ethernet-кадром, и, следовательно, помогает BeeGFS достичь более высокой пропускной способности. Однако такая конфигурация требует, чтобы все элементы маршрутов между службами BeeGFS (т.е. коммутаторы, маршрутизаторы, сетевые карты) были сконфигурированы так, чтобы принимать большие кадры.

Neighbor Table Sizes для разрешения адресов (ARP) В сетях с большим количеством интерфейсов размеры таблиц соседних устройств по умолчанию для поиска ARP (Address Resolution Protocol) обычно слишком малы, что приводит к ошибке «Neighbour table overflow». Это особенно актуально для службы управления BeeGFS, которая взаимодействует со всеми другими службами BeeGFS и в таких случаях отключается из-за критической ошибки связи, которая не позволяет ей корректно контролировать зарегистрированные сервисы BeeGFS.

Чтобы предотвратить системную ошибку Neighbour table overflow, поднимите пороговое значение net.ipv4.neigh.default.gc_thresh1 в файле /etc/sysctl.conf (или используйте инструмент sysctl). Значение по умолчанию 128 должно быть увеличено, если система имеет более 128 интерфейсов, которые могут быть использованы BeeGFS. Например, система состоит из 129 узлов с 1 сетевым интерфейсом (IP-адресом) каждый, или 65 узлов с 2 интерфейсами каждый, или 43 узлов с 3 интерфейсами.

Другими словами, значение gc_tresh1 должно быть больше, чем количество всех IP-адресов, используемых BeeGFS. Таким образом, если у вас 200 клиентов с 2 IP-адресами каждый и 10 серверов с 3 IP-адресами каждый, то значение gc_thresh1 должно быть не менее 200 * 2 + 10 * 3 = 460. Поскольку также может существовать связь между BeeGFS хостами и другими машинами из сети или интернета, было бы неплохо округлить значение, например, до 512 в этом примере.

Кроме того, следует также увеличить другие пороговые значения gc_thresh. Вы можете удвоить их, например, установив gc_thresh2=1024 и gc_thresh3=2048.

Брандмауэры / Трафик UDP-датаграмм / Трансляция сетевых адресов (NAT) TCP-соединения устанавливаются только между клиентами и серверами или между серверами, но никогда не устанавливаются между сервером и клиентом.

UDP-пакеты обмениваются между всеми серверами в обоих направлениях и между серверами и клиентами в обоих направлениях.

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

TCP и UDP порты, используемые службами, можно найти в соответствующих конфигурационных файлах (/etc/beegfs/beegfs…conf) или запросив службу управления, например, для портов службы управления:

$ beegfs-ctl —listnodes —nodetype=management —nicdetails Все службы BeeGFS используют фиксированные TCP/UDP порты. Единственным исключением являются утилиты beegfs-ctl и beegfs-fsck, которые также используют UDP, но должны использовать случайный UDP-порт (потому что должно быть возможно, что произвольное количество экземпляров утилиты beegfs-ctl может быть запущено одновременно на одной машине).

В общем, не обязательно, чтобы beegfs-ctl мог запускаться на вычислительных узлах, но это полезно для пользователей, если это возможно, например, для проверки статистики (beegfs-ctl —userstats) или для запроса информации о квотах (beegfs-ctl —getquota).

Это номера UDP и TCP портов по умолчанию служб BeeGFS:

Management service (beegfs-mgmtd): 8008 Metadata service (beegfs-meta): 8005 Storage service (beegfs-storage): 8003 Client service (beegfs-client): 8004

По умолчанию, клиент также устанавливает TCP соединения со службой поддержки пользователей (beegfs-helperd) на той же машине для DNS поиска и протоколирования на TCP порту 8006.

В общем, не требуется, чтобы все службы BeeGFS одного типа использовали один и тот же TCP или UPD порт, например, могут быть некоторые службы метаданных, использующие порт 8005, в то время как другие службы метаданных, подключающиеся к той же службе управления и, таким образом, являющиеся частью одного и того же пространства имён файловой системы, могут использовать разные порты. Однако по умолчанию все службы одного и того же типа используют один и тот же порт.

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

Следующая команда покажет вам текущие настройки stripe в корневом каталоге для монтирования BeeGFS (в данном случае /mnt/beegfs):

$ beegfs-ctl —getentryinfo /mnt/beegfs Используйте режим setpattern , чтобы применить новые настройки чередования к каталогу (в данном случае «чередование файлов на 4-х запоминающих устройствах с размером фрагмента 1 Мб»):

$ beegfs-ctl --setpattern --numtargets=4 --chunksize=1m /mnt/beegfs

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

Влияние на сетевую связь

Размер блока данных влияет на связь между клиентом и серверами хранения несколькими способами.

Когда процесс записывает данные в файл, расположенный на BeeGFS, клиент определяет цели хранилища, которые содержат блоки данных, которые будут изменены (путем запроса серверов метаданных), и посылает сообщения об изменении на серверы хранения, содержащие измененные данные. Максимальный размер таких сообщений определяется размером фрагментов данных в файле. Если вы определите chunksize=1m, то максимальным размером каждого сообщения будет 1 MB. Если объем данных, записанных в файл, больше максимального размера сообщения, то на серверы потребуется отправить больше сообщений, что может привести к потере производительности. Таким образом, небольшое увеличение размера фрагмента до нескольких мегабайт приводит к уменьшению количества сообщений, и это может положительно сказаться на производительности даже в системе с одним объектом.

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

Также необходимо учитывать настройки кэш-памяти файлов. Когда клиент использует буферизованный кэш (tuneFileCacheType = buffered), он использует буфер файлового кэша размером 512 КБ для накопления изменений на тех же данных. Эти данные посылаются на серверы только тогда, когда данные за пределами этого буфера необходимы клиенту. Таким образом, чем больше этот буфер, тем меньше связь между клиентом и серверами. Вы должны установить размер этого буфера кратным размеру фрагмента данных. Например, добавление tuneFileCacheBufSize = 2097152 в конфигурационный файл клиента BeeGFS увеличит размер буфера файлового кэша до 2 МБ.

BeeGFS Buddy Mirroring™

Общие заметки о зеркалировании.

Начиная с версии 2012.10, BeeGFS обеспечивает поддержку зеркалирования метаданных и содержимого хранимого на storage target. Возможности зеркалирования интегрированы в обычные службы BeeGFS, так что нет необходимости в отдельных службах или сторонних инструментах. Оба типа зеркалирования (зеркалирование метаданных и зеркалирование storage target) могут использоваться независимо друг от друга.
В релизах 2015.03 встроенное зеркалирование было расширено дополнительными функциями высокой доступности содержимого файлов.
Начиная с BeeGFS v6.0, зеркалирование метаданных также было расширено функциями высокой доступности.
Хранение и зеркалирование метаданных с высокой доступностью основано на так называемых buddy groups (группа приятелей). В целом, buddy groups — это пара двух целей, которые внутренне управляют репликацией данных между собой. Подход, основанный на buddy groups, позволяет половине всех серверов в системе выйти из строя, в то время как все данные все еще доступны. Эта технология также может быть использована для размещения buddies в различных местах для обеспечения безотказной работы в случае критических сбоев или катастроф — можно размещать buddies в разных стойках и разных серверных.

Buddy mirroring также может быть использован с нечетным количеством серверов хранения. Это работает, потому что buddy groups BeeGFS состоят из отдельных целей хранения, независимо от их назначения серверам, как показано на следующем примере с 3 серверами и 2 целями хранения на сервер. В общем случае, buddy groups по хранению может состоять даже из двух целей, которые подключены к одному и тому же серверу.

Обратите внимание, что это невозможно с серверами метаданных, так как в BeeGFS нет целей метаданных. Четное количество серверов метаданных необходимо для того, чтобы каждый сервер метаданных мог принадлежать к buddy group.

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

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

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

Обход отказа buddy group может произойти только в том случае, если запущена и доступна служба BeeGFS Management. Это означает, что обход отказа не произойдёт, если узел с сервисом beegfs-mgmtd выйдет из строя. Поэтому рекомендуется, чтобы служба beegfs-mgmtd работала на отдельной машине. Однако для работы службы beegfs-mgmtd не обязательно иметь выделенный сервер.

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

Включение и выключение зеркалирования

По умолчанию зеркалирование отключено для нового экземпляра файловой системы. Оба типа зеркалирования могут быть включены с помощью утилиты командной строки beegfs-ctl. (Утилита beegfs-ctl содержится в пакете beegfs-utils и обычно запускается с клиентского узла).

Перед включением зеркалирования метаданных или хранилищ необходимо определить buddy groups, так как они являются основой для зеркалирования. Дополнительная информация о том, как определить buddy groups и управлять ими в разделе: «Management of Mirror Buddy Groups«.

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

Параметры зеркалирования каталога будут применяться к новым записям файлов и будут происходить по новым подкаталогам. Например, если зеркалирование метаданных разрешено для каталога /mnt/beegfs/mydir1, то в новом подкаталоге /mnt/beegfs/mydir1/mydir2 также будет автоматически разрешено зеркалирование метаданных.

После включения зеркалирования метаданных для файловой системы с помощью команды beegfs-ctl —mirrormd, по умолчанию будут зеркалироваться метаданные корневого каталога. Следовательно, во вновь создаваемых каталогах под корнем также будет включено зеркалирование метаданных. Можно исключить новые папки из зеркалирования метаданных, создав их с помощью команды beegfs-ctl —createdir —nomirror. Подробнее о зеркалировании метаданных в разделе «Metadata Buddy Mirroring«.

Чтобы включить зеркалирование содержимого файлов для определенного каталога, обратитесь к встроенной справке инструмента beegfs-ctl. (Не забудьте сначала определить buddy groups).

 $ beegfs-ctl --setpattern --buddymirror --help

Зеркалирование содержимого файла может быть отключено после этого с помощью режима beegfs-ctl —setpattern без опции —buddymirror. Однако, файлы, которые уже были созданы при включенной опции зеркалирования, останутся зеркалированными.

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

 $ beegfs-ctl --getentryinfo /mnt/beegfs/mydir/myfile

Для проверки состояния целевого объекта хранения используйте:

 $ beegfs-ctl --listtargets --nodetype=storage --state

Если в вашей системе определены buddy mirror groups, вы можете установить шаблон полос, чтобы использовать buddy groups в качестве целей полос, а не отдельных целей хранения. Для этого добавьте в команду опцию —buddymirror, как показано ниже. В данном конкретном примере данные будут разбиты на полосы между 4 buddy groups с размером фрагмента 1 МБ.

$ beegfs-ctl --setpattern --numtargets=4 --chunksize=1m --buddymirror /mnt/beegfs

В BeeGFS версии 7+ эта опция была заменена на —pattern=buddymirror.

Восстановление метаданных и хранение целевых данных после сбоев

Если объект хранения или сервер метаданных недоступен, то он помечается как автономный и не получает обновлений данных. Обычно, когда цель или сервер перерегистрируется, он автоматически синхронизируется с оставшимся зеркалом в buddy group (self-healing). Однако, в некоторых случаях может понадобиться запустить процесс синхронизации вручную. Для получения дополнительной информации о том, как это сделать и как контролировать синхронизацию, смотрите раздел Resynchronization of Storage Targets and Metadata Servers.

Management of Mirror Buddy Groups

Общие примечания

Начиная с релиза 2015.03, BeeGFS поддерживает зеркалирование данных между buddy groups. Если вы вообще не знаете об этой возможности, пожалуйста, сначала прочитайте раздел BeeGFS Buddy Mirroring.

В BeeGFS 6.0 было введено зеркалирование метаданных.

Обозначения для mirror buddy groups — это числовые ID, так же как и числовые ID объектов(целей) хранения. Обратите внимание, что идентификаторы buddy group не конфликтуют с целевыми ID, т.е. они не должны отличаться от идентификаторов целей хранения.

Существует два различных способа определения buddy groups. Они могут быть определены вручную или вы можете BeeGFS создаст их автоматически.

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

Определение buddy groups автоматически

Автоматическое создание групп друзей может быть сделано beegfs-ctl, отдельно для метаданных и для серверов хранения:

 $ beegfs-ctl --addmirrorgroup --automatic --nodetype=meta

 $ beegfs-ctl --addmirrorgroup --automatic --nodetype=storage

Для получения более подробной информации о доступных параметрах обратитесь к справке beegfs-ctl:

 $ beegfs-ctl --addmirrorgroup --help

Определение Buddy Groups вручную

Ручное определение mirror buddy groups может быть полезно, если вы хотите установить пользовательские идентификаторы групп, или если вы хотите убедиться, что buddy находятся в разных областях отказа (например, в разных стойках или разных серверных). Определение mirror buddy groups вручную выполняется с помощью инструмента beegfs-ctl. Используя следующую команду, вы можете создать группу приятелей с ID 100, состоящую из целей 1 и 2:

 $ beegfs-ctl --addmirrorgroup --nodetype=storage --primary=1 --secondary=2 --groupid=100

Для получения более подробной информации о доступных параметрах обратитесь к справке beegfs-ctl:

 $ beegfs-ctl --addmirrorgroup --help

При создании mirror buddy groups для метаданных вручную, и одна из них содержит корневую директорию, необходимо установить эту группу как первичную.

Список объявленных Mirror Buddy Groups

Настроенные Mirror Buddy Groups могут быть указаны с помощью beegfs-ctl (не забудьте указать тип узла):

 $ beegfs-ctl --listmirrorgroups --nodetype=storage

 $ beegfs-ctl --listmirrorgroups --nodetype=meta

Также можно перечислить mirror buddy groups наряду с другой информацией о цели:

 $ beegfs-ctl --listtargets --mirrorgroups

Для получения более подробной информации о доступных параметрах обратитесь к справке beegfs-ctl:

 $ beegfs-ctl --listtargets --help

Define Stripe Pattern

После указания storage buddy mirror groups в вашей системе, вы должны определить stripe pattern данных, который будет использовать эта группа.

Нюансы of Storage Mirroring

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

Setting states of active storage targets

При ручном изменении состояния целевого хранилища с GOOD на NEEDS_RESYNC клиенты, обращающиеся к файлам в период распространения, «видят» различные версии глобального состояния.

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

Администратор устанавливает состояние активной storage target, которая является secondary для buddy group, на NEEDS_RESYNC с помощью beegfs-ctl —startresync. Состояние переносится на primary для buddy group. Primary больше не будет передавать записанные данные на secondary. Клиент записывает данные в файл, находящийся в buddy group. Данные не передаются на secondary. Другой клиент считывает данные из файла. Если клиент пытается прочитать данные из primary, потеря данных не происходит. Если клиент пытается читать из secondary, что возможно без проблем в стабильной системе, он получит несвежие данные.

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

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

Fsync может вызвать отказ без изменения параметра состояния целей NEEDS_RESYNC.

Когда fsync настроена на распространение на серверах хранения, запуск fsync на серверах хранения, при ошибка во время fsync система окажется в непредсказуемом состоянии, если ошибка произошла на secondary сервере buddy group.

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

Если отказ произошел до обнаружения ошибки, автоматический resync с новым primary (старым secondary, который вышел из строя) на новый secondary (старый primary) может привести к потере данных.

Activating Metadata Mirroring

После определения зеркальных групп метаданных, вы должны активировать medatada mirroring.

После того, как buddy groups сервера метаданных были определены, зеркалирование метаданных может быть активировано в файловой системе.

Важные примечания: При применении команды beegfs-ctl —mirrormd нельзя монтировать клиентов. Этого можно достичь, предварительно остановив службу beegfs-client и запустив ее снова после успешного выполнения команды beegfs-ctl —mirrormd. Кроме того, после этого, перезапустите сервис beegfs-meta на всех узлах.

Для активного зеркалирования метаданных используйте инструмент beegfs-ctl:

 $ beegfs-ctl --mirrormd

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

Процесс запуска зеркаирования в уже работающей системе заключается в следующем: остановить всех клиентов, выполнить beegfs-ctl —mirrormd, перезапустить все серверы метаданных, а затем перезапустить всех клиентов. Для получения более подробной информации о доступных параметрах обратитесь к справке beegfs-ctl:

 $ beegfs-ctl --mirrormd --help

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

Новые файлы и каталоги, созданные внутри каталога с активным зеркалированием метаданных, также будут активированы. Могут возникнуть ситуации, когда желательно отключить зеркалирование метаданных для части файловых систем. Это дает небольшой прирост мощности Каталог без зеркалирования метаданных может быть создан с помощью beegfs-ctl:

 $ beegfs-ctl --createdir --nomirror <name>

Информацию о дополнительных параметрах командной строки см. в справке beegfs-ctl:

 $ beegfs-ctl --createdir --help

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

Миграция существующих метаданных

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

 $ cp -a <directory> <mirrored-dir>

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

Target and Node States (Reachability & Consistency)

В выпуске 2015.03 BeeGFS представляет состояние reachability и consistency для узлов метаданных и целей хранения. Эти состояния важны для механизмов высокой доступности в BeeGFS.

Отображение целевых состояний

Состояния достижимости и согласованности могут быть отображены с помощью режима «—listtargets» инструмента beegfs-ctl:

 $ beegfs-ctl --listtargets --nodetype=storage --state
 $ beegfs-ctl --listtargets --nodetype=meta --state

Дополнительную информацию о доступных параметрах см. во встроенной справке:

 $ beegfs-ctl --listtargets --help

Описание доступных состояний

Состояние доступности используется для описания того, может ли система получить доступ к цели. Оно контролируется службой управления. Это состояние является важной частью buddy mirroring, так как обход отказа target в buddy mirror group основан на состоянии достижимости primary target.

Определяются следующие состояния достижимости:

Online: Цель или узел достижима.

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

Offline: Цель недоступна. Если это primary target mirror buddy group, обход отказа будет выдан немедленно при переходе цели в автономное состояние.

Описание состояний согласованности

Состояние согласованности описывает состояние данных на целевом узле хранения или узле метаданных.

Определяются следующие состояния согласованности:

Good: Согласованность(Консистентность) данных считается хорошей.

Needs resync: Это состояние согласованности применяется только к secondary targets или узлам mirror buddy group. Данные на целевом узле или узле считаются несинхронизированными (например, потому что они были в автономном режиме) и нуждаются в повторной синхронизации.

Resyncing: Данные на target или node считаются несинхронизированными, и выполняется попытка повторной синхронизации.

Bad: Данные на target или node считаются несинхронизированными, и попытка повторной синхронизации не увенчалась успехом. Пожалуйста, просмотрите лог-файлы для получения дополнительной информации о том, почему это состояние было выбрано.

Resynchronization of Storage Targets and Metadata Servers

Автоматическая ресинхронизация

В общем случае, если secondary target или сервер считаются несинхронизированными, они автоматически устанавливаются в состояние согласованности, которое требует повторной синхронизации.

Процесс resynchronization storage target для самоисцеления координируется первичным primary target. Стандартный процесс пытается избежать ненужной передачи файлов. Поэтому primary target экономит время последней успешной связи со secondary target. По умолчанию ресинхронизируются только те файлы, которые были изменены после этой метки времени. Чтобы избежать потери кэшированных данных, будет добавлено короткое время порога безопасности (определенное sysResyncSafetyThresholdMins в beegfs-storage.conf).

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

Resynchronization в ручном режиме

В некоторых случаях может оказаться полезным или даже необходимым вручную инициировать ресинхронизацию storage target или сервера метаданных. Одним из таких случаев является вариант, когда — система хранения на вторичной цели, которая повреждена до невозможности восстановления. В этом сценарии все данные этой цели могут быть потеряны, и новую цель необходимо поднять со старым идентификатором цели. Тогда автоматической повторной синхронизации будет недостаточно, поскольку она будет учитывать только файлы после последнего успешного взаимодействия целей. Другой случай ручного переопределения синхронизации — это когда fsck локальной файловой системы (например, xfs_repair) удалил старые файлы.

Инструмент beegfs-ctl может использоваться для ручной установки цели хранения или сервера метаданных в состояние необходимости resync. Обратите внимание, что это не вызывает повторной синхронизации немедленно, а только информирует демона управления о новом состоянии. Затем процесс повторной синхронизации будет запущен primary этой buddy group через несколько мгновений.

Как уже говорилось, primary target экономит время последнего успешного общения со secondary target. Без дополнительных параметров эта временная метка будет использоваться для максимально возможного сокращения времени ресинхронизации. Но можно также переопределить эту метку времени, чтобы ресинхронизировать более длительное время или чтобы ресинхронизировать все в случае, описанном выше.

Дополнительную информацию о доступных параметрах см. в справке beegfs-ctl:

 $ beegfs-ctl --startresync --help

Если ресинхронизация уже запущена, и вы хотите прервать ее и начать заново, вы можете сделать это, передав параметр —restart в beegfs-ctl. Если вы этого не сделаете, то текущий процесс будет запущен и ваш запрос будет проигнорирован. Это особенно полезно, если система запустила автоматическую ресинхронизацию после того, как вторичная цель снова стала доступна, но вы знаете, что подход, основанный на отметках времени, не достаточен. Например, это может произойти, если ваша полная базовая файловая система сломалась до того, как вторичная цель была запущена, т.е. цель полностью пуста и нуждается в полной синхронизации. Обратите внимание, что перезапуск запущенной ресинхронизации возможен только для целей хранения, поскольку серверы метаданных никогда не выполняют частичную ресинхронизацию.

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

 $ beegfs-ctl --startresync --nodetype=storage --targetid=X --timestamp=0 --restart

Отображение тнформации о Resynchronization

Инструмент командной строки beegfs-ctl может использоваться для отображения информации о текущем процессе ресинхронизации.

Дополнительную информацию о доступных параметрах см. во встроенной справке beegfs-ctl:

 $ beegfs-ctl --resyncstats --help

Кэширование

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

Буферизованный режим обычно обеспечивает более высокую пропускную способность потока по сравнению с родным режимом кэширования. Буферизованный режим кэширует только несколько сотен килобайт файла, в то время как «родной» режим способен кэшировать несколько гигабайт, динамически адаптируясь к объему доступной клиентской оперативной памяти. Нативный режим работает и отмечен как экспериментальный. Если вы включите его, знайте, что это может привести к проблемам.

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

Тип кэша может быть установлен в конфигурационном файле клиента (/etc/beegfs/beegfs-client.conf).

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

ЦКП "Биоинформатика"

Основное меню

Меню

BeeGFS Documentation

Используемые в документе термины:

О файловой системе

Services

Management service

Storage service

Metadata service

Client service

NTP

Нюансы установки

Basic Configuration

Managment service

Metadata service

Storage service

Client

Services startup

Advanced configuration

Общие методы настройки BeeGFS

IOPS Benchmark

mdtest

Рекомендации по порядку тестирования:

Storage Server Tuning

Рекомендации по работе с рейдами.

Аппаратный RAID

Настройка пропускной способности сервера хранения данных

Создание RAID-оптимизированной файловой системы.

Выравнивание без раздела

Выравнивание с разделом

Выравнивание разделов — проверка текущего Выравнивания

Выравнивание разделов — Создание выровненного раздела

Опции монтирования

IO Scheduler

Virtual Memory Settings

Controller Settings

ZFS (программный RAID)

Установка параметров модуля ZFS

IO Scheduler

Read Chunk Size

Data Prefetch

Агрегация данных и его лимитирование

Создание пулов ZFS для целей хранения данных.

Выравнивание разделов

Журнальные устройства

Кэширующие устройства

Размер блоков

Настройка ZFS пула для цели хранения

Сжатие данных

Размер записи

Дедупликация

Неиспользуемые атрибуты

System BIOS & Power Saving

Настройка параллелизма

Metadata service tuning

Общие примечания

Расширенные атрибуты (EA)

Аппаратный RAID

Выравнивание разделов и настройки RAID в локальной файловой системе

Настройка пропускной способности сервера метаданных

Опции форматирования

Опции монтирования

IO Scheduler

Virtual Memory Settings

ZFS (программный RAID)

Настройка параметров модуля ZFS

Планировщик ввода-вывода

Агрегация данных и его лимитирование

Создание пулов ZFS для целей метаданных

Защита данных

Выравнивание разделов

Настройка пулов ZFS для целей метаданных

Сжатие данных

Расширенные атрибуты

Дедупликация

Неиспользуемые атрибуты

System BIOS & Power Saving

Настройка параллелизма

Параллельные сетевые запросы