Глава 2. Функциональные особенности и конфигурация GFS2

Файловая система GFS2 предназначена для взаимодействия между вычислительными узлами в кластере и организации совместного доступа к хранилищу. Механизм блокирования, реализованный на уровне TCP/IP, предотвращает потерю данных при параллельном обращении к ресурсам.
В этой главе приведены рекомендации, которые помогут улучшить производительность GFS2.

Важно

Прежде всего убедитесь, что конфигурация комплекта Red Hat High Availability соответствует вашим требованиям. При необходимости проконсультируйтесь с представителем Red Hat.

2.1. Особенности форматирования

Далее приведены рекомендации по форматированию GFS2.

2.1.1. Размер: чем меньше, тем лучше

В основу GFS2 положена 64-разрядная архитектура, что теоретически позволяет создать файловую систему размером до 8 эксабайт. Но на сегодняшний день максимально поддерживаемый размер составляет 100 терабайт для 64-разрядной архитектуры и 16 терабайт для 32-разрядной.
При выборе размера файловой системы руководствуйтесь принципом: чем меньше, тем лучше. Таким образом, лучше создать 10 файловых систем размером 1 ТБ, чем одну размером 10 ТБ.
Преимущества небольших файловых систем:
  • Резервное копирование занимает меньше времени.
  • Меньше времени уходит на проверку fsck.gfs2.
  • fsck.gfs2 требует меньше памяти для своей работы.
Число групп ресурсов в небольших файловых системах невелико, поэтому издержки на их поддержку тоже снижаются.
Выберите такой размер файловой системы, чтобы она не была слишком большой, но и не переполнялась.

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

Начиная с Red Hat Enterprise Linux 6, команда mkfs.gfs2 автоматически подбирает размер блоков исходя из топологии устройства. 4 КБ должно быть достаточно, так как размер страниц памяти в Linux по умолчанию составляет именно 4 КБ. В отличие от других файловых систем, GFS2 использует буферы ядра размером 4 КБ, поэтому ядру не приходится выполнять лишнюю работу при взаимодействии с буфером.
Обычно не рекомендуется менять стандартный размер блоков, хотя в редких случаях это допустимо — например, чтобы повысить эффективность взаимодействия с хранилищем с большим числом очень маленьких файлов.

2.1.3. Число журналов

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

2.1.4. Размер журналов

Размер журналов можно определить на этапе форматирования с помощью mkfs.gfs2. По умолчанию будет выбрано 128 МБ, что вполне достаточно для большинства приложений.
Кому-то может показаться, что 128 МБ — слишком много, и вы захотите уменьшить размер до 32 или даже до 8 МБ. И хотя такое мнение имеет право на существование, уменьшение размера журналов может отрицательно сказаться на производительности. Аналогично другим файловым системам, GFS2 осуществляет запись метаданных в журнал, прежде чем они будут записаны на диск, что позволяет их восстановить в случае внезапного отключения системы. Это быстро заполнит 8 мегабайт в журнале, вследствие чего производительность пострадает, так как файловая система должна будет ожидать выполнения записи на диск.
Итак, рекомендуемый размер журналов составляет 128 МБ. Однако для небольших файловых систем (например, размером 5 ГБ), это может оказаться непрактично, и администратор сочтет целесообразным его уменьшить, в то время как для больших файловых систем увеличение размера (например, до 256 МБ) может улучшить производительность.

2.1.5. Группы ресурсов

При форматировании mkfs.gfs2 пространство разбивается на одинаковые секции — так называемые «группы ресурсов». Размер группы выбирается автоматически (от 32 МБ до 2 ГБ), но по желанию можно установить конкретный размер с помощью параметра -r.
Оптимальный размер зависит от того, насколько заполнена и как сильно фрагментирована будет файловая система.
Точный размер подбирается экспериментальным путем при тестировании кластера.
Если файловая система содержит большое число небольших групп, процесс выделения блоков будет занимать слишком много времени за счет перебора тысяч групп в ходе поиска свободных блоков. По мере заполнения файловой системы время поиска будет расти, что существенно снизит производительность.
И наоборот, наличие лишь нескольких групп большого размера может привести к частому состязанию узлов за ресурсы, что тоже негативно влияет на производительность. Так, например, если файловая система размером 10 ГБ разделена на 5 групп размером 2 ГБ, кластерные узлы будут конкурировать за доступ к ним гораздо чаще, чем в системе такого же размера, но с 320 группами по 32 МБ. Ситуация усугубляется по мере заполнения файловой системы, так как при поиске свободных блоков надо будет проверить несколько групп. Для борьбы с этой проблемой GFS2 использует два подхода:
  • Заполненные группы ресурсов будут исключаться из поиска до тех пор, пока хотя бы один блок в группе не освободится. Если вы не планируете удалять файлы, степень состязания за ресурсы снизится. Однако при частом удалении и новом распределении блоков в переполненной файловой системе это сильно снизит производительность.
  • При добавлении новых блоков в файл они будут помещены в ту же группу ресурсов, где расположен файл. Таким образом, операции перехода в файле будут выполняться быстрее за счет того, что блоки будут физически расположены близко друг к другу.
При самом неблагоприятном развитии событий узлы будут непрерывно состязаться за доступ к группе ресурсов — например, если все узлы в кластере пытаются создать файлы в одном каталоге.