ServerAdmin.ru | Linux | DevOps

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

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





upstream app {
 server 127.0.0.1:8000;
}
.....
  location /app/ {
.....
    proxy_pass http://app/;
.....
  }

Сервис с дефолтными настройками запускается на http://localhost:8000. Пробую напрямую, всё работает. Через Nginx - никак, 502 ошибка, в логах стандартно - (111: Connection refused) while connecting to upstream. Думаю, что за ерунда. Напрямую же отвечает, почему через Nginx - нет. Ещё и приложение никаких своих логов не даёт, не понятно, что не так.

Разобрался чисто интуитивно. Вспомнил, что 127.0.0.1 и localhost - это не одно и то же. Первый - адрес ipv4, а localhost на современных дистрибутивах резолвится в ipv6 (::1).

Попадались на таком нюансе? Я уже не первый раз. Кстати, не понимаю, для чего localhost перевели на ipv6. В чём смысл? Даже не то, что перевели. В /etc/hosts оставили оба адреса, и ipv4, и ipv6, но по современным RFC адреса v6 имеют приоритет над v4. Поэтому теперь localhost по умолчанию отвечает с адреса ::1, а не 127.0.0.1. Это можно вручную изменить, убрав запись с ::1 из /etc/hosts. Я одно время это делал, потом перестал. Нет смысла бороться с ветряными мельницами. Надо привыкать.

#linux #ошибка

Сегодня у нас очередная пятница, так что можно поговорить на отвлечённые темы. Затрону одну из любимых ваших тематик - обсуждение мониторов 😁. Они неизменно вызывают повышенную активность - просмотры, обсуждения, критику. Я и сам люблю поглазеть на чужие рабочие места, подсмотреть там что-то интересное.

У меня рабочее место получилось не похоже на всё то, что я где-либо видел. Я сейчас закончил преобразования и остановился на том варианте, что получился. Меня он устраивает, поэтому можно поделиться. Для наглядности записал небольшое видео (смотреть внизу).

Пару лет назад я купил себе монитор 🖥 27'' AOC Q27G2S/EU 2К с частотой 165 Гц. Уже имея приличный опыт работы за ним могу сказать, что как по мне - это оптимальный вариант монитора для типовой работы в браузере и терминале. Я имею ввиду диагональ и разрешение. Всё умещается, всё влезает на масштабе 125%, глаза не устают.

В какой-то момент стало не хватать одного монитора для некоторых задач. Стал подумывать купить второй такой же. Это было бы удобно. Но в продаже уже не нашёл. Подумал немного и решил купить 4К монитор, раз уж одинаковые всё равно не получалось сделать. Место у меня позволяет, поэтому задумал увеличить ещё и диагональ. В итоге взял 🖥 4К 31.5" AOC U32G4U с частотой 160 Гц.

Раньше не придавал внимания частоте, не считал её значимой характеристикой, так как в активные игры, типа шутеров, не играю. Но после того, как поработал на 165 Гц, меньше уже не хотелось. Разница хоть и явно не заметна, но ощущается. С разрешением 4К и диагональю 31.5" это был самый дешёвый монитор с такой частотой, поэтому его и взял. Ну и в целом он мне нравится, похож на предыдущий.

Какого-то ВАУ эффекта или большого удобства от 4К монитора я не увидел. Больше всего понравилось то, что теперь по высоте места хватает и можно убрать панель инструментов Windows вниз, а вкладки браузера - вверх. Последнее время у меня панель была справа, а вкладки слева. Размера экрана теперь достаточно, чтобы расположить рабочие окна по центру, отступив и сверху, и снизу.

С масштабом в 150% против 125% в 2К места на мониторе стало не намного больше. Картинка плюс-минус такая же. Я не могу сказать, что прям шрифты какие-то более гладкие или что-то ещё, что я часто слышал от тех, кто советует брать 4К. У меня оба монитора теперь перед глазами, я могу сравнить. Да, 4К чуть лучше, но он и дороже. Если бюджет ограничен и надо два монитора, я бы лучше купил 2 хороших 2К монитора, нежели 2 похуже, но 4К.

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

Из того, что ещё хотелось бы добавить - заменить стоящий рядом обычный стол на стол с подъёмным механизмом. Для разминки и разгрузки уставших от сидения мышц хотел бы иногда что-то делать стоя, смотря в окно. Оно как раз у меня напротив. От сидения весь день в своей рабочей станции у меня устаёт попа. Раньше на обычных креслах спина или шея уставали, а сейчас мягкое место. Стараюсь 5-7 км в день для разминки ходить.

#железо

Небольшая рекомендация по теме Zabbix. У них есть партнёр - initMAX. Это довольно популярная компания в своей области. Они много всего сделали полезного для Zabbix. Регулярно выступают на Zabbix Summit, пишут инструкции и различные дополнения для Zabbix. Расскажу о наиболее полезных вещах, про которые знаю.

1️⃣ Репозиторий с шаблонами. Тут много хороших шаблонов. Несмотря на то, что шаблонов для Zabbix в целом немало, но все они разного качества. У initMAX они обычно неплохие. Например, я пользуюсь их шаблоном для Synology.

2️⃣ Zabbix MCP Server и Zabbix AI Skills. Качественная обвязка для работы с Zabbix с помощью LLM. Команда Zabbix обещала свой MCP сервер выпустить вместе с релизом 8.0, но я пока ещё не видел информации о нём. Этот MCP сервер наиболее качественный и популярный, особенно в связке со скилами. Всё никак руки не доходят поплотнее поработать с этим. Не придумаю задачу, которую было бы удобно решать с ИИ. Я Zabbix неплохо знаю и обычно довольно быстро там что-то меняю или нахожу. А для деплоя и без MCP всё пишется агентами. Не представляю, где меня ИИ в этих задачах может ускорить. Основная проблема - спам уведомлений из-за некачественных или неоткалиброванных шаблонов. В своих шаблонах я и так знаю, где и что надо подкрутить.

Если используете в работе с Zabbix ИИ и MCP, расскажите, какие задачи с ними решаете.

3️⃣ Каталог расширений. Это набор как платных, так и бесплатных модулей для Zabbix, которые меняют или дополняют основную функциональность. Покажу на конкретном примере.

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

У initMAX есть бесплатный модуль, который это исправляет. Ставится так:





# wget https://repo.initmax.com/zabbix/release/initmax-release-latest_all.deb
# dpkg -i initmax-release-latest_all.deb
# apt update && apt install zabbix-module-hidewidgetheader

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

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

#zabbix

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

Смысл в том, что все виртуальные блочные устройства ZFS на одной физической машине объединяются в общий пул потоков ZVOL. И если у вас 2 пула - один на быстрых NVME, а второй - на медленных HDD, запросы к ним будут сливаться в общий поток. При нагрузке на пул с HDD и выстраивании очереди запросов к нему, в эту же очередь встают и запросы на пулы с остальными дисками. В итоге, сильно нагрузив ZVOL на одном медленном пуле, вы получаете задержки с ZVOL на других, более быстрых пулах.

На практике это выглядит так. Ночью вы запускаете бэкап большой ВМ, виртуальный диск которой находится в ZVOL на медленном HDD-пуле. При интенсивном чтении этого диска рабочие потоки ZVOL могут оказаться заняты, из-за чего увеличиваются задержки запросов к виртуальным дискам на NVMe, хотя сами NVMe практически не загружены.

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

Другое дело, что я в таких схемах не использую ZFS. Под рабочей нагрузкой мне не нужны возможности ZFS, как и для локальных бэкапов. Поэтому лично я с такой проблемой не сталкивался. ZFS обычно ставлю на бэкап серверы с кучей дисков. Там я вижу использование этой ФС оправданной и полезной. В остальных случаях, если не нужны снэпшоты именно в реализации ZFS, не вижу смысла её использовать.

Автор решил проблему в лоб самым простым и очевидным способом - вынес NVME диски на LVM-thin, отделив их от общего пула потоков ZFS. Это сразу решило проблему узкого горлышка.

Я немного поспрашивал ИИ на эту тему. Он подтвердил, что это архитектурная особенность ZFS, которую он увидел в исходниках. Там же есть и комментарии разработчиков на этот счёт:

We can have up to zvol_threads concurrent i/o's being processed for all zvols on the system. This is typically a vast improvement over the zvol_request_sync=1 behavior of one i/o at a time per zvol. However, an even better design would be for zvol_request() to initiate the zio directly, and then be notified by the zio_done callback, which would call END_IO().

Каким-то образом обыграть эту ситуацию можно, меняя параметры:
zvol_request_sync = 0 или 1
◽️ 0 - асинхронная обработка через общий пул потоков ZVOL.
◽️ 1 - обработка непосредственно в контексте вызывающего потока, без передачи в общий пул ZVOL.

Казалось бы, второй вариант решает проблему конкуренции между пулами. Но разработчики предупреждают, что такая схема может существенно ухудшить параллелизм и производительность i/o. Поэтому использовать её без тестирования не стоит.

Можно увеличить кол-во потоков zvol_threads, но всё равно нет гарантии, что все эти потоки не будут заняты медленным пулом.

Ещё вариант - изменить механизм очереди - zvol_use_blk_mq = 1. Но тут надо тестировать на практике, потому что потоки будут по-прежнему в одном общем пуле, изменится распределение. Не факт, что при нагрузке на медленный пул, запросы к быстрому не будут вставать в очередь.

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

В общем, как я всегда говорил и говорю, ZFS - нишевая файловая система под конкретные задачи и потребности. У неё много возможностей, нюансов и настроек. Ставить её по умолчанию, как ФС общего назначения, не стоит. Преимущества вам могут оказаться не нужны, а все особенности и недостатки вы по умолчанию потянете за собой.

#pve #zfs

Рассказываю про небольшой трюк, который я лично на днях проделал для решения небольшой задачи. Есть одиночная VPS на Debian 12. Задача - обновить её до 13-й версии и попутно обновить версию PHP. Задача довольно простая, но всё равно потенциально опасная. Наживую такие обновления делать не рекомендую. Там бывают проблемы с зависимостями, на разрешение которых уходит некоторое время. Я сталкивался не раз.

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

Но в данном случае это одиночная арендованная VPS без какой-либо обвязки вокруг. С неё даже образ нормально не снять. Я поступил следующим образом. Создал у себя в тестовом контуре VM и добавил к ней второй диск такого же размера, как у VPS. С этой VM сделал следующее:





# ssh -T root@1.2.3.4 'dd if=/dev/sda bs=16M status=none' | dd of=/dev/sdb bs=16M iflag=fullblock status=progress conv=fsync

Прямо наживую запустил посекторное копирование удалённого диска sda на свой локальный sdb. В моём случае диск был 60 ГБ, нормально скопировался примерно за час без единого разрыва. При этом на сервере был запущен сервер MySQL.

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

У этой виртуалки отключил основной диск, а sdb, на который залил копию VPS, сделал загрузочным. После этого успешно загрузился в полной копии VPS. Система ругнулась при запуске, что у неё повреждена файловая система, что ожидаемо. Запустил fsck -y, потом перезагрузил систему. Она при загрузке запустила ещё раз проверку диска, все ошибки исправила, и я получил полностью рабочую копию своей VPS. Даже базу данных не пришлось перезаливать. СУБД запустилась в режиме innodb_force_recovery. Мне этого было достаточно, хотя какие-то таблицы и побились. Я только поменял IP адрес, поправил файрвол под реалии своего тестового контура и отладил обновление.

Выполнил всё, что мне было нужно. Там возникли проблемы. Убедился, что исправил все ошибки, записал команды и воспроизвёл на VPS.

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

Основное преимущество этого способа - не надо останавливать исходную машину вообще. И не надо ставить дополнительное ПО. К примеру, сюда можно было бы установить Veeam Agent for Linux и снять образ с его помощью. Но для разовых задач не хочется ничего лишнего устанавливать. Задача решена и без этого.

#linux