Настройка XFS/ext4 файловых систем для продакшен-серверов

Почему настройка XFS по умолчанию роняет запись на пиках

Продакшен-сервер с XFS «из коробки» держится ровно до первого серьёзного всплеска записи: ночное резервное копирование, переиндексация базы, распаковка архивов. В этот момент время отклика на запись растёт на порядок, приложение ловит ошибки по времени ожидания ввода-вывода, а по метрикам диск загружен не полностью — нагрузка уходит в ожидание, а не в полезную работу.

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

Журнал добавляет своё: размер буферов, порядок сброса, расположение на носителе. Когда через одну точку сброса идут и мелкие синхронные операции, и крупные последовательные, крупные ждут мелкие. Это и есть та деградация ввода-вывода, которую на графиках видно как «диск тормозит», хотя тормозит очередь операций записи, а не носитель.

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

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

Что даёт корректная разметка и параметры монтирования

Разметка тома и опции монтирования определяют три измеримые вещи: разброс времени отклика записи под пиком, объём операций, которые теряются при внезапном пропадании питания, и длительность возврата сервера в строй после сбоя. В актуальных сборках Red Hat XFS выбран по умолчанию, но умолчания рассчитаны на «среднюю» нагрузку — под задачу их уточняют. Ниже — то, что мы проверяем на каждом продакшен-узле до вывода в работу.

• Выравнивание начала тома и разделов по границам, которые понимает накопитель: уходит режим «чтение-правка-запись» на каждый блок, запись перестаёт быть в разы медленнее чтения, а отклик не зависит от позиции данных.
• Резерв под метаданные и размер inode при создании тома: место под них не заканчивается задолго до исчерпания самого тома — не приходится останавливать сервис и переносить данные.
• Журналирование файловой системы: после отключения питания восстанавливается согласованность метаданных, а восстановление сводится к переигровке последних транзакций — секунды вместо полной проверки тома на десятки минут.
• Объём и число буферов журнала: всплески записи в часы пик не выстраиваются в очередь — разброс времени отклика сужается, а не растёт ступенями.
• noatime или relatime в параметрах монтирования: снимает десятки тысяч лишних обновлений метаданных в сутки, накопитель не пишет то, что никто не читает.
• Очередь ввода-вывода под профиль нагрузки: при смешанном потоке ожидание записи сокращается, тяжёлый бэкап перестаёт задерживать транзакции.
• Регулярный fstrim и контроль заполнения: свободные блоки возвращаются накопителю, деградация записи не наступает внезапно.
• Конфигурация разметки и монтирования в репозитории: восстановление после сбоя сервера воспроизводимо, а не «по памяти инженера».

Сравнение подходов: вариант, применимость, ограничения

Ни одна файловая система не выигрывает «в общем» — сравнение имеет смысл только вместе с тем, как разложены данные по томам. XFS лучше держит параллельную запись и крупные файлы, ext4 предсказуемее на мелких операциях и проще в обслуживании. Ниже — четыре схемы разметки, между которыми реально выбирают, с честными ограничениями каждой.

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

Порядок работ: от аудита до передачи в эксплуатацию

Работы идут одним маршрутом: сначала — факты о хранилище, затем конфигурация и только после подтверждённых испытаний продакшен. Ни один параметр не берётся «как у всех»: он либо подтверждён профилем нагрузки, либо не применяется.

1. Аудит хранилища. Снимаем занятость томов, распределение размеров файлов, долю последовательной и случайной записи, пиковые окна. На выходе — профиль нагрузки вместо общих слов про «много мелких файлов».
2. Схема размещения данных. Раскладываем данные по томам и точкам монтирования: отдельно журналы и метаданные, отдельно горячая запись, отдельно архивы. Схема сразу показывает, какой раздел деградирует первым.
3. Расчёт параметров файловой системы. Под эту схему задаём размер блока, режим журналирования, лимиты inode и опции монтирования. Каждый пункт объясняем: что он даёт и чем мы за него платим.
4. Нагрузочные испытания диска. Прогоняем синтетику и повтор реального профиля: смотрим задержки и пропускную способность на длинном интервале, а не на всплеске в минуту.
5. Проверка отказоустойчивости. Имитируем отказ диска, обрыв, переполнение тома и потерю питания, затем — восстановление и проверку целостности. Фиксируем время простоя и объём данных, которые поднимаются из резерва.
6. Перевод в продакшен. Применяем поэтапно, с окном обслуживания и планом возврата: если метрики уходят за границы, откатываемся на прежнюю конфигурацию без потери данных.
7. Передача в эксплуатацию. Отдаём документацию, карту размещения, пороги мониторинга и регламент на типовые сбои; остаёмся на связи, пока ваша команда не проведёт первую плановую операцию сама.

Комплект документации, конфигураций и регламентов

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

• Конфигурация монтирования — рабочие файлы для каждого сервера с построчным пояснением опций: почему включён noatime, чем обоснован discard на накопителях, где осознанно оставлен режим журналирования по умолчанию.
• Схема разделов и томов — карта дисков, разделов и точек монтирования с выравниванием по границам блоков и зарезервированным местом под рост.
• Политики доступа к данным — владельцы и права на каталоги приложений и журналов, отдельные учётные записи сервисов вместо работы от суперпользователя.
• Инструкция по расширению тома — пошаговый порядок: добавить ёмкость, увеличить логический том, затем расширить файловую систему на ходу (xfs_growfs или resize2fs) без остановки сервиса.
• Регламент обслуживания сервера — периодичность контроля заполнения, пороги оповещений, окна плановых проверок целостности и порядок действий при сбое питания.
• Порядок восстановления — что делать при повреждении метаданных, как разворачивать из резервной копии и как убедиться, что данные целы после.
• Журнал изменений — каждая правка конфигурации с причиной и способом отката.

Кейс: устранение деградации записи на файловом сервере

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

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

Что изменили

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

Метрики до и после

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

Настройка XFS или ext4: что выбрать под текущую нагрузку?

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

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

XFS раскрывается на больших файлах и параллельной записи: раздельные группы размещения позволяют потокам писать в разные области тома, не упираясь в общий замок. Это видно на потоковых задачах — логи, резервные копии, медиа, базы с крупными блоками. Обратная сторона: массовое удаление мелких файлов идёт медленнее, а уменьшить том нельзя.

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

Технические сомнения: совместимость, риски и откат

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

Как откатываются изменения, если что-то пойдёт не так?

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

Что меняется для резервного копирования?

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

Как проверяете целостность данных после переноса?

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

Как начать: что уточнить и в каком порядке двигаться

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

• Профиль нагрузки: что пишет на диск чаще — база данных, журналы приложений, очереди сообщений, слой контейнеров; каково соотношение чтения и записи и есть ли всплески в отчётные часы.
• Аппаратный слой: локальные диски или сетевое хранилище, массив и уровень его отказоустойчивости, резерв по дискам под будущий рост.
• Текущее состояние: какая файловая система развёрнута, с какими параметрами монтирования и создания, какие правки делались вручную после установки и кем.
• Требования к данным: нужны ли снимки состояния, как часто снимается резервная копия и какое время восстановления считается приемлемым для сервиса.
• Окно работ: допустим ли перевод сервера в режим обслуживания, возможна ли миграция без остановки сервиса и кто подтверждает окно.
• Прогноз по объёму: как быстро прибавляются данные и планируется ли расширение раздела в обозримом будущем — от этого зависит запас по разметке.

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