«452 4.3.1 Insufficient system storage»: добавляем том store2

Учебный центр в Подольске, 21 рабочее место, май 2019 года. В среду в 14:20 сервер перестал принимать почту, а узнали они об этом только в четверг вечером — потому что отправители получали временную ошибку и молча повторяли попытки. Разбираю, как освободить место, ничего не удаляя, и как правильно завести второй том хранения.

У этой аварии есть свойство, которое делает её особенно неприятной. Она тихая.

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

А отправители в этот момент получают от вашего сервера ответ: 452 4.3.1 Insufficient system storage. Это временная ошибка. Их серверы не сообщают ничего своим пользователям, а просто ставят письмо в очередь и повторяют попытку — час, три часа, шесть. Пять суток по умолчанию. И только через пять суток человеку на той стороне падает уведомление, что письмо вам не доставлено.

То есть о своей аварии вы узнаёте от третьих лиц. Через день, а иногда через неделю. Именно так это было в Подольске.

Учебный центр дополнительного профобразования, 21 рабочее место: методисты, четыре преподавателя, приёмная комиссия, бухгалтерия. Рассылают слушателям методички, принимают курсовые работы и сканы документов — то есть переписка у них тяжёлая, с вложениями по 10–30 мегабайт.

Zimbra 8.8.12 Open Source, CentOS 7, виртуальная машина на локальном хосте. Один виртуальный диск на 500 гигабайт, разбитый на корень и отдельный раздел под /opt.

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

[zimbra@mail ~]$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/mapper/cl-root   45G   19G   26G  43% /
/dev/mapper/cl-opt   450G  447G   96M 100% /opt
tmpfs                7.8G     0  7.8G   0% /dev/shm

[zimbra@mail ~]$ tail -3 /var/log/maillog
postfix/smtpd[21883]: NOQUEUE: reject: RCPT from mail-lf1-f47.google.com[209.85.167.47]:
 452 4.3.1 Insufficient system storage; from=<...> to=<priem@centre.ru>

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

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

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

Странно, но первую четверть часа я потратил зря — и виновата в этом моя же привычка.

Формулировка «письма к нам не доходят» плюс учебный центр с курсовыми работами сложились у меня в версию про переполненный ящик приёмной комиссии. Логика была такая: ящик набрал квоту, письма к нему копятся в очереди, отправители получают отлуп. Я даже начал смотреть квоты:

[zimbra@mail ~]$ zmprov gqu mail.centre.ru | sort -k3 -n -r | head -5
# колонки: аккаунт, квота, использовано — в байтах
priem@centre.ru       21474836480   18327451136
metod@centre.ru       10737418240    9914372096
buh@centre.ru          5368709120    2201936384

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

Это мелкая ошибка, но она показательна. Текст 452 4.3.1 Insufficient system storage буквально говорит: у системы кончилось хранилище. Не у ящика. У системы. Я потерял пятнадцать минут на версию, которую опровергала строчка, лежавшая у меня перед глазами.

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

Три команды под пользователем zimbra. Ничего не меняют, выполняются мгновенно.

# свободное место и свободные inode
df -h
df -i

# из чего складывается занятое
du -sh /opt/zimbra/store /opt/zimbra/index /opt/zimbra/db \
       /opt/zimbra/log /opt/zimbra/backup /opt/zimbra/data 2>/dev/null

# какие тома хранения заведены и какой сейчас пишущий
zmvolume -l

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

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

В Подольске я нашёл 62 гигабайта, не тронув ни одного письма. Разбивка получилась поучительной:

# посмотреть, что вообще занимает место, крупными кусками
du -h --max-depth=2 /opt/zimbra | sort -rh | head -25

# логи старше 30 дней
find /opt/zimbra/log -name "*.log.*" -mtime +30 -ls

# копии на том же разделе, что и оригинал — главная находка
ls -lh /opt/zimbra/backup/sessions/ | head

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

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

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

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

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

Ситуации, когда расширение недоступно, встречаются регулярно:

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

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

В Подольске мы поступили так: неделю прожили на освобождённых 62 гигабайтах, за это время купили и поставили в хост два диска на 2 терабайта, собрали на них отдельное хранилище, отдали виртуалке второй диск на терабайт и завели его как второй том.

Порядок действий такой. Сначала обычная работа с диском в системе, потом — одна команда Zimbra.

# 1. Разметить новый диск и создать файловую систему
fdisk /dev/sdb
mkfs.xfs /dev/sdb1

# 2. Точка монтирования именно внутри дерева Zimbra
mkdir -p /opt/zimbra/store2
echo "/dev/sdb1  /opt/zimbra/store2  xfs  defaults  0 0" >> /etc/fstab
mount -a

# 3. Владелец обязателен, иначе Zimbra не сможет туда писать
chown zimbra:zimbra /opt/zimbra/store2
chmod 755 /opt/zimbra/store2
df -h /opt/zimbra/store2

Дальше под пользователем zimbra:

# посмотреть, что есть сейчас
zmvolume -l

# добавить новый том хранения сообщений
zmvolume -a -n store2 -t primaryMessage -p /opt/zimbra/store2

# сделать его текущим — вся новая почта пойдёт сюда
zmvolume -l                 # смотрим присвоенный id
zmvolume -sc -id 3

# контроль
zmvolume -dc

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

Что происходит после переключения: старая почта остаётся физически в /opt/zimbra/store, и Zimbra продолжает её оттуда читать. Новые письма ложатся в /opt/zimbra/store2. Пользователи не замечают ничего — для них почта как была единой, так и осталась. Перемещать старое никуда не нужно.

Отдельно про индекс

Полнотекстовый индекс живёт на своём томе, не на том же, где письма. Место под него считается отдельно, и это регулярно забывают: расширили хранилище писем, обрадовались, а через месяц уткнулись в переполнение индексного раздела. В Подольске индекс занимал 38 гигабайт, а собственно писем на разделе было 347 гигабайт (447 занятых минус 62 гигабайта не-почты и минус сам индекс) — почти 11 процентов, и это типичное соотношение.

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

Мы перенесли содержимое, убедились, что писем на старом томе не осталось, и я попробовал его удалить. Получил вот это:

zimbra@mail:~$ zmvolume -d -id 1
Cannot delete volume! The volume is in use.

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

Правильный порядок при выводе тома из эксплуатации:

1. Убедиться, что том не назначен текущим ни для сообщений, ни для индекса.
2. Проверить, какие ящики ещё ссылаются на него — и по письмам, и по индексу.
3. Перевести их на новый том и дождаться, пока миграция реально закончится.
4. И только потом удалять запись о томе.

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

В итоге мы старый том не удалили вообще. Оставили как есть — он пустой, он никому не мешает, и удалять его ради красоты списка не стоило ни минуты риска.

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

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

Цифры по этому случаю:

• Приём почты не работал 29 часов 45 минут, с 14:20 среды до 20:05 четверга: позвонили в 17:40, пятнадцать минут я потратил на ложную версию, уборка заняла 2 часа 10 минут.
• Задержано 238 писем, потеряно 0 — самому старому было чуть больше суток при пятисуточном сроке.
• Из них 9 писем — заявки на обучение от организаций, где в тендерных условиях стоял срок ответа.
• Аварийная уборка: 2 часа 10 минут, освобождено 62 ГБ.
• Заведение второго тома через неделю: 1 час 40 минут, из них 50 минут — разметка и копирование.
• Счёт за обе работы: 21 000 рублей.
• Два диска на 2 ТБ в 2019 году: около 34 000 рублей.

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

Где эта работа перестаёт быть простой

Команды я привёл целиком, и на здоровом сервере всё занимает полтора часа. Осложняется оно в трёх местах.

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

Когда причина не в объёме писем. Раздел бывает забит копиями, карантином, логами, следами старых обновлений — как в Подольске, где 62 из 447 гигабайт вообще не были почтой. Расширять диск, не разобравшись в структуре занятого, — значит покупать место под мусор.

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

Если хотите понять, сколько вам осталось до этой аварии, пришлите мне три вещи: вывод df -h, вывод du по каталогам Zimbra из блока выше и вывод zmvolume -l. За день отвечу, сколько месяцев у вас в запасе, из чего реально состоит занятое место и что дешевле — убраться, расширить раздел или завести второй том.

Письма, которые отправители не смогли доставить, потеряются?

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

Можно ли просто удалить старую почту, чтобы освободить место?

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

Сколько свободного места должно быть у Zimbra в норме?

Я держу планку в 20 процентов свободного и начинаю нервничать на десяти. Причина не в красоте цифры: серверу нужно место под временные файлы при обработке крупных вложений, под рост базы, под переиндексацию ящика, под очередь при всплеске почты. На сервере с пятью процентами свободного любая нештатная ситуация превращается в аварию. И отдельно считайте прирост в месяц: 7 гигабайт в месяц при 60 свободных — это не «60 гигабайт запаса», это восемь месяцев, и планировать расширение надо на седьмом, а не на девятом.

Что будет со старой почтой после переключения на новый том?

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

Почему нельзя было заранее это заметить?

Можно и нужно было. Заполнение диска — единственная авария из моей практики, которая предупреждает о себе месяцами. Нужен один-единственный datapoint: свободное место на разделе с Zimbra, снимаемое раз в сутки и отправляемое человеку при пороге в 85 процентов. Это пять минут настройки в любой системе мониторинга и даже одна строка в планировщике, если мониторинга нет вовсе. В учебном центре не было ни того, ни другого, поэтому сервер молча дошёл до 447 гигабайт из 450 и встал посреди рабочего дня в среду.