Хочу сделать предостережение, основанное на личном опыте. Делал рядовое обновление сервера, которое требовало перезагрузку. Сервер далеко, в необслуживаемой серверной. То есть там никого нет вечером, кто смог бы хоть что-то сделать. Как обычно, время выбрал позднее, так как на сервере полезная нагрузка. Его активно используют люди в течении рабочего дня. И кто бы мог подумать, что сервер не выйдет из перезагрузки.
Нет проблем. Сервер Supermicro, там IPMI, сейчас посмотрим консоль и поймем, в чём там дело. И тут начинаются танцы. Сервер старый, версия BMC древняя. Для подключения к консоли нужна java какой-то старой версии. Апплет не запускается, так как блочится настройками безопасности из-за отсутствия сертификата и актуальной версии TLS. В общем, мрак. Думаю тем, кто используют старые Supermicro, хорошо знакома эта тема. Я давно их не покупаю. Если брать б.у., то предпочту Dell. Там BMC удобный.
Проблемы в итоге решил, подключился и всё сделал. А мораль тут такова – перед перезагрузкой сервера, проверьте, есть ли у вас доступ к консоли, так что для меня reboot – это всегда потенциальная возможность потерять доступ к серверу. Обязательно проверяю бэкапы перед этим и доступ к консоли сервера. И всегда держу в голове схему, что я буду делать, если сервер не поднимется. А после установки обновления это не такая уж и большая редкость. Я столько всяких историй проходил. Было много примеров, некоторые описывал в статьях:
◽️Yum после обновления упал с ошибкой и не пересобрал initramfs под новое ядро. Спасла загрузка на старом.
◽️У сервера уменьшили на лету размер корневого раздела. После перезагрузки grub его потерял.
◽️Как-то раз просто на всякий случай зашёл в админку хостера проверить, есть ли доступ к консоли. А её не оказалось, просто чёрный экран. Через техподдержку решили вопрос. Был глюк.
◽️У GRUB2 как-то раз вышло обновление, которое приводило к невозможности загрузки.
◽️Как-то раз сервер с большим диском запустил проверку файловой системы во время загрузки. Длилась она пару часов. Останавливать не решился, сидел и ждал, чем закончится. Причём счетчика времени не было. Думал уже что всё, данным кирдык.
◽️Один хостер с арендным сервером высылал доступ к консоли по VNC в момент оформления. Заказчик благополучно всё это где-то потерял, а когда нужно было срочно подключиться, пришлось искать и восстанавливать эти доступы через тех. поддержку. А для этого ещё и VPN настраивать надо было.
Это только то, что бегло вспомнил. Были и другие истории. Если сталкивались с чем-то подобным, то поделитесь своими инцидентами. Можно будет подборку сделать. Мне кажется, их может много набраться.
#совет
Нет проблем. Сервер Supermicro, там IPMI, сейчас посмотрим консоль и поймем, в чём там дело. И тут начинаются танцы. Сервер старый, версия BMC древняя. Для подключения к консоли нужна java какой-то старой версии. Апплет не запускается, так как блочится настройками безопасности из-за отсутствия сертификата и актуальной версии TLS. В общем, мрак. Думаю тем, кто используют старые Supermicro, хорошо знакома эта тема. Я давно их не покупаю. Если брать б.у., то предпочту Dell. Там BMC удобный.
Проблемы в итоге решил, подключился и всё сделал. А мораль тут такова – перед перезагрузкой сервера, проверьте, есть ли у вас доступ к консоли, так что для меня reboot – это всегда потенциальная возможность потерять доступ к серверу. Обязательно проверяю бэкапы перед этим и доступ к консоли сервера. И всегда держу в голове схему, что я буду делать, если сервер не поднимется. А после установки обновления это не такая уж и большая редкость. Я столько всяких историй проходил. Было много примеров, некоторые описывал в статьях:
◽️Yum после обновления упал с ошибкой и не пересобрал initramfs под новое ядро. Спасла загрузка на старом.
◽️У сервера уменьшили на лету размер корневого раздела. После перезагрузки grub его потерял.
◽️Как-то раз просто на всякий случай зашёл в админку хостера проверить, есть ли доступ к консоли. А её не оказалось, просто чёрный экран. Через техподдержку решили вопрос. Был глюк.
◽️У GRUB2 как-то раз вышло обновление, которое приводило к невозможности загрузки.
◽️Как-то раз сервер с большим диском запустил проверку файловой системы во время загрузки. Длилась она пару часов. Останавливать не решился, сидел и ждал, чем закончится. Причём счетчика времени не было. Думал уже что всё, данным кирдык.
◽️Один хостер с арендным сервером высылал доступ к консоли по VNC в момент оформления. Заказчик благополучно всё это где-то потерял, а когда нужно было срочно подключиться, пришлось искать и восстанавливать эти доступы через тех. поддержку. А для этого ещё и VPN настраивать надо было.
Это только то, что бегло вспомнил. Были и другие истории. Если сталкивались с чем-то подобным, то поделитесь своими инцидентами. Можно будет подборку сделать. Мне кажется, их может много набраться.
#совет
Server Admin
Kernel panic not syncing: VFS: Unable to mount root fs |...
Решение проблемы, когда сервер не загружается и показывает ошибку Kernel panic not syncing: VFS: Unable to mount root fs.
К одной из старых заметок про панель панель управления сервером поступил комментарий в ВК про незнакомую мне панель Homarr. Автор её похвалил. Глянул быстро в github, там очень мало звёзд. Думаю, какая-то новая непопулярная панель, незаслуживающая пока внимания. Подобных проектов много.
Зацепился взгляд за забавный слоган, который раньше не доводилось встречать: Easy and fast app management - No YAML / JSON configurations are involved. Обычно конфигурации в этих форматах преподносятся как удобство и унификация, а тут всё наоборот. Отсутствие этих форматов преподносится как преимущество и упрощение управления. В общем, решил панель посмотреть.
Итак, что такое Homarr? Это web страница с виджетами, которые через встроенные интеграции показывают различную информацию от поддерживаемых сервисов, либо допускают управление ими. Например, виртуалками Proxmox, контейнерами Docker. Можно просто смотреть статус различных сервисов: устройств в Home Assistent, блокировок в Pi-Hole или Adguard, загрузки в торрент клиентах, состояние медиасерверов и т.д. Также туда можно какие-то RSS ленты выводить, погоду, часы, ссылки и т.д. Есть виджеты для простого мониторинга – доступность хостов, коды HTTP ответов.
По описанию понятна сфера применения – управление личным хозяйством в домашней лаборатории. На работе подобные панели ставить не стоит. Хотя, если у вас в управлении небольшой бизнес, который вы обслуживаете в одно лицо, то почему и нет, если вам так будет удобнее. С другой стороны, там есть API, а следовательно возможность автоматизировать создание виджетов, например, со ссылками на веб ресурсы, где будет автоматически проверяться код ответа. Если у вас проект с набором отдельных веб-ресурсов, можно быстро собирать дашборд со статусом. Зелёный виджет – всё ОК, красный – проблемы. Плюс, я знаю, что некоторые люди делают такие дашборды со ссылками на внутренние ресурсы компании для пользователей.
Homarr поставляет в преднастроенном контейнере Docker, так что разворачивается в пару действий. Потом всё управление только через веб интерфейс. Никаких конфигураций и консоли. Про запуск не буду рассказывать, чтобы не загромождать заметку тем, что есть в документации.
📌 Особенности Homarr:
▪️Как я уже сказал, всё управление через веб интерфейс.
▪️Есть аутентификация пользователей, в том числе из LDAP.
▪️Можно создавать публичные панели, доступные без аутентификации.
▪️У пользователя может быть несколько разных панелей.
▪️Есть тёмная светлая тема, русский язык.
▪️Можно добавлять свои иконки для сервисов.
▪️Проект живой с большим, активным сообществом, постоянные обновления.
▪️Есть API.
Аналоги:
- Dashy
- Heimdall
- Homepage
Heimdall я пользовался немного, но забросил. Лично у меня нет потребности в подобных панелях. У меня всё подобное в Zabbix + Grafana живёт. Но я просто умею их настраивать. Чтобы всякие разные визуализации и интеграции делать надо хорошо во всём этом разбираться. А в подобной панели доступная функциональность настраивается мышкой в веб интерфейсе за вечер, но в пределах возможных интеграций.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#dashboard
Зацепился взгляд за забавный слоган, который раньше не доводилось встречать: Easy and fast app management - No YAML / JSON configurations are involved. Обычно конфигурации в этих форматах преподносятся как удобство и унификация, а тут всё наоборот. Отсутствие этих форматов преподносится как преимущество и упрощение управления. В общем, решил панель посмотреть.
Итак, что такое Homarr? Это web страница с виджетами, которые через встроенные интеграции показывают различную информацию от поддерживаемых сервисов, либо допускают управление ими. Например, виртуалками Proxmox, контейнерами Docker. Можно просто смотреть статус различных сервисов: устройств в Home Assistent, блокировок в Pi-Hole или Adguard, загрузки в торрент клиентах, состояние медиасерверов и т.д. Также туда можно какие-то RSS ленты выводить, погоду, часы, ссылки и т.д. Есть виджеты для простого мониторинга – доступность хостов, коды HTTP ответов.
По описанию понятна сфера применения – управление личным хозяйством в домашней лаборатории. На работе подобные панели ставить не стоит. Хотя, если у вас в управлении небольшой бизнес, который вы обслуживаете в одно лицо, то почему и нет, если вам так будет удобнее. С другой стороны, там есть API, а следовательно возможность автоматизировать создание виджетов, например, со ссылками на веб ресурсы, где будет автоматически проверяться код ответа. Если у вас проект с набором отдельных веб-ресурсов, можно быстро собирать дашборд со статусом. Зелёный виджет – всё ОК, красный – проблемы. Плюс, я знаю, что некоторые люди делают такие дашборды со ссылками на внутренние ресурсы компании для пользователей.
Homarr поставляет в преднастроенном контейнере Docker, так что разворачивается в пару действий. Потом всё управление только через веб интерфейс. Никаких конфигураций и консоли. Про запуск не буду рассказывать, чтобы не загромождать заметку тем, что есть в документации.
📌 Особенности Homarr:
▪️Как я уже сказал, всё управление через веб интерфейс.
▪️Есть аутентификация пользователей, в том числе из LDAP.
▪️Можно создавать публичные панели, доступные без аутентификации.
▪️У пользователя может быть несколько разных панелей.
▪️Есть тёмная светлая тема, русский язык.
▪️Можно добавлять свои иконки для сервисов.
▪️Проект живой с большим, активным сообществом, постоянные обновления.
▪️Есть API.
Аналоги:
- Dashy
- Heimdall
- Homepage
Heimdall я пользовался немного, но забросил. Лично у меня нет потребности в подобных панелях. У меня всё подобное в Zabbix + Grafana живёт. Но я просто умею их настраивать. Чтобы всякие разные визуализации и интеграции делать надо хорошо во всём этом разбираться. А в подобной панели доступная функциональность настраивается мышкой в веб интерфейсе за вечер, но в пределах возможных интеграций.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#dashboard
Хочу сделать дополнение по мотивам заметки про УПС и проблемы с электричеством. Тема живая получилась. Смотрю, многие сталкивались со схожими проблемами. Сразу забыл написать, а сейчас вспомнил. У меня был необычный опыт в своё время, которым хочу поделиться. Кому-то возможно поможет, если придётся с похожей проблемой столкнуться.
На одном производстве была серверная стойка. В результате серьёзных проблем поблизости надолго обесточили. Речь шла о недели, поэтому решили стойку и остальных потребителей запитать от генераторов. Заранее к подобному не готовились, поэтому набрали обычных генераторов, которые вдвоём-троём таскать можно. Условно бытовые.
От этих генераторов наотрез отказывались работать УПСы, как серверные, так и обычные. Пищат, как-будто тока в сети нет, и не включаются. При этом если включить сервер или обычный комп, то всё работает. Вообще все приборы нормально работали от генераторов, кроме УПСов. На тот момент ни электрик местный, ни я не могли понять, что не так. Пытался как-то разобраться через поиск в инете, но конкретики не нашёл. Не понятно было, что и как надо исправить.
Пришлось принять решение запустить всё напрямую. Очень боялся за сервера, но на практике с ними ничего не случилось. Всю неделю благополучно отработали от генератора. Когда вернули электричество, переключил на УПС.
Уже позже было любопытно разобраться в этой теме. Поспрашивал электриков, плюс где-то обсуждение на форуме видел. Дело в качестве синуса, или частоты, которую выдаёт генератор. В УПСах чётко прописаны требования по частоте к току в сети. Если частота плавает, синус кривой, то он не запустится. А от бытовых генераторов синус как раз и кривой. То есть выходные параметры электрического тока от генератора не соответствуют требованиям УПСов, поэтому они не включаются.
У большинства электроприборов таких жестких требований к току нет, поэтому они работают. И хотя формально в характеристиках выходного тока генератора и входного тока УПСа могут быть полные совпадения, на деле обычный генератор синус даёт кривой.
Один из наиболее доступных и простых способов решения проблемы – повесить на генератор какую-то постоянную стабильную нагрузку. Например, обогреватель на 1-2 кВт·ч. Это не обязательно, но может помочь выровнять частоту.
На некоторых УПСах отдельно предусмотрена поддержка генераторов. Там есть режим работы от генератора. Шансы того, что УПС заработает от генератора, повышаются, но всё равно не являются стопроцентными. Сам генератор может быть банально хреновым. Если где-то у вас есть для подстраховки генератор и используются УПСы, то лучше заранее проверить, будут ли они от него работать.
Эта проблема, кстати, актуальна и для загородных домов, где часто есть генератор в резерве, а дома некоторая критичная нагрузка, типа насоса или котла, запитана от УПСов.
#железо
На одном производстве была серверная стойка. В результате серьёзных проблем поблизости надолго обесточили. Речь шла о недели, поэтому решили стойку и остальных потребителей запитать от генераторов. Заранее к подобному не готовились, поэтому набрали обычных генераторов, которые вдвоём-троём таскать можно. Условно бытовые.
От этих генераторов наотрез отказывались работать УПСы, как серверные, так и обычные. Пищат, как-будто тока в сети нет, и не включаются. При этом если включить сервер или обычный комп, то всё работает. Вообще все приборы нормально работали от генераторов, кроме УПСов. На тот момент ни электрик местный, ни я не могли понять, что не так. Пытался как-то разобраться через поиск в инете, но конкретики не нашёл. Не понятно было, что и как надо исправить.
Пришлось принять решение запустить всё напрямую. Очень боялся за сервера, но на практике с ними ничего не случилось. Всю неделю благополучно отработали от генератора. Когда вернули электричество, переключил на УПС.
Уже позже было любопытно разобраться в этой теме. Поспрашивал электриков, плюс где-то обсуждение на форуме видел. Дело в качестве синуса, или частоты, которую выдаёт генератор. В УПСах чётко прописаны требования по частоте к току в сети. Если частота плавает, синус кривой, то он не запустится. А от бытовых генераторов синус как раз и кривой. То есть выходные параметры электрического тока от генератора не соответствуют требованиям УПСов, поэтому они не включаются.
У большинства электроприборов таких жестких требований к току нет, поэтому они работают. И хотя формально в характеристиках выходного тока генератора и входного тока УПСа могут быть полные совпадения, на деле обычный генератор синус даёт кривой.
Один из наиболее доступных и простых способов решения проблемы – повесить на генератор какую-то постоянную стабильную нагрузку. Например, обогреватель на 1-2 кВт·ч. Это не обязательно, но может помочь выровнять частоту.
На некоторых УПСах отдельно предусмотрена поддержка генераторов. Там есть режим работы от генератора. Шансы того, что УПС заработает от генератора, повышаются, но всё равно не являются стопроцентными. Сам генератор может быть банально хреновым. Если где-то у вас есть для подстраховки генератор и используются УПСы, то лучше заранее проверить, будут ли они от него работать.
Эта проблема, кстати, актуальна и для загородных домов, где часто есть генератор в резерве, а дома некоторая критичная нагрузка, типа насоса или котла, запитана от УПСов.
#железо
Давно не было заметок на тему систем мониторинга, потому что всё более-менее известное и удобное я обозревал ранее. В этот раз попался интересный проект, про который я даже не слышал, не то, что не видел. Упоминание было в пятничной подборке видео, где был обзор на Beszel. Это очень простой и легковесный мониторинг для одного или группы хостов. Поддерживает Linux, FreeBSD, MacOS. Он отлично дополнит подборку легковесных мониторингов для одиночного сервера, хотя поддерживает через агенты сбор метрик и с других серверов.
Сразу перечислю основные особенности:
▪️Простой и легковесный мониторинг, написанный на Go.
▪️После установки сразу готов к работе, не требует особой настройки.
▪️Собирает только базовые метрики: доступность хоста, загрузка процессора, памяти, дисков, сетевой трафик, доступные метрики с сенсоров платформы. Плюс всё то же самое, только для Docker контейнеров.
▪️Собирает информацию через агентов на удалённых серверах. Агенты в виде бинарника или Docker контейнера. Подключается к агентам, сам ходит на хосты за информацией.
▪️Поддерживает различные провайдеры для аутентификации.
▪️Умеет сам себя бэкапить локально или на S3.
▪️Имеет REST API.
▪️Приложение построено на базе фреймворка pocketbase.io. Состояние хранится в SQLite.
Как и было сказано, Beszel очень прост в установке. Состоит из одного бинарника. Запустить можно как напрямую, так и через Docker. Если использовать бинарник, надо будет юнит для systemd писать, поэтому проще в Docker запустить:
Можно идти по IP адресу на порт 8090 и создавать учётную запись. Есть русский язык, причём перевод нормальный. У меня он включился по умолчанию, переключить на английский желания не возникло.
На главной странице можно сразу же добавить сервер для мониторинга. Нажимаете соответствующую кнопку, указываете имя и IP адрес сервера и получаете команду для установки либо через бинарник, либо через Docker. После установки агента, сразу начинается сбор метрик.
Для каждого сервера можно включить свои уведомления или использовать глобальные. Настраиваются в пару кликов, очень наглядно. Отправляться могут как по SMTP, так и через популярные мессенджеры. Под капотом там вебхуки через проект Shoutrrr со своим синтаксисом мессенджеров. Например, для Telegram строка с настройкой уведомлений выглядит так:
Пример уведомлений в Telegram есть внизу на картинке.
Мониторинг реально легковесный. Я запустил на чистой системе, добавил 3 хоста. Нагрузка болталась в районе 0-1% CPU и 56372K памяти. Посмотрел так:
Настройка очень простая. Вообще никуда не заглядывал. Сходу всё настроил, оповещения работают, протестировал. И на недоступность хоста, и на потребление ресурсов. В целом, всё понравилось. Очень простой и лёгкий в настройке мониторинг. Выглядит симпатично. Можно пользоваться как для одиночного сервера, так и для нескольких.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#мониторинг
Сразу перечислю основные особенности:
▪️Простой и легковесный мониторинг, написанный на Go.
▪️После установки сразу готов к работе, не требует особой настройки.
▪️Собирает только базовые метрики: доступность хоста, загрузка процессора, памяти, дисков, сетевой трафик, доступные метрики с сенсоров платформы. Плюс всё то же самое, только для Docker контейнеров.
▪️Собирает информацию через агентов на удалённых серверах. Агенты в виде бинарника или Docker контейнера. Подключается к агентам, сам ходит на хосты за информацией.
▪️Поддерживает различные провайдеры для аутентификации.
▪️Умеет сам себя бэкапить локально или на S3.
▪️Имеет REST API.
▪️Приложение построено на базе фреймворка pocketbase.io. Состояние хранится в SQLite.
Как и было сказано, Beszel очень прост в установке. Состоит из одного бинарника. Запустить можно как напрямую, так и через Docker. Если использовать бинарник, надо будет юнит для systemd писать, поэтому проще в Docker запустить:
# mkdir -p ./beszel_data && \# docker run -d --name beszel --restart=unless-stopped \ -v ./beszel_data:/beszel_data -p 8090:8090 henrygd/beszelМожно идти по IP адресу на порт 8090 и создавать учётную запись. Есть русский язык, причём перевод нормальный. У меня он включился по умолчанию, переключить на английский желания не возникло.
На главной странице можно сразу же добавить сервер для мониторинга. Нажимаете соответствующую кнопку, указываете имя и IP адрес сервера и получаете команду для установки либо через бинарник, либо через Docker. После установки агента, сразу начинается сбор метрик.
Для каждого сервера можно включить свои уведомления или использовать глобальные. Настраиваются в пару кликов, очень наглядно. Отправляться могут как по SMTP, так и через популярные мессенджеры. Под капотом там вебхуки через проект Shoutrrr со своим синтаксисом мессенджеров. Например, для Telegram строка с настройкой уведомлений выглядит так:
telegram://token@telegram?chats=@channel-1[,chat-id-1,...]Пример уведомлений в Telegram есть внизу на картинке.
Мониторинг реально легковесный. Я запустил на чистой системе, добавил 3 хоста. Нагрузка болталась в районе 0-1% CPU и 56372K памяти. Посмотрел так:
# pmap 25017 -dНастройка очень простая. Вообще никуда не заглядывал. Сходу всё настроил, оповещения работают, протестировал. И на недоступность хоста, и на потребление ресурсов. В целом, всё понравилось. Очень простой и лёгкий в настройке мониторинг. Выглядит симпатично. Можно пользоваться как для одиночного сервера, так и для нескольких.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#мониторинг
Совет-предостережение насчёт systemd, монтирования дисков и некоторых облачных провайдеров. Ситуация, с которой сталкивался сам, а потом встречал ещё не раз. Если не ошибаюсь, последний раз такой механизм видел у хостера Linode.
В Linux есть служба systemd-mount, о которой я уже ранее писал. Хостер может её использовать для автоматического подключения сетевых дисков с разными параметрами. В целом это удобно и для него, и для пользователя. У меня был подключен в точку монтирования один такой диск. Я решил увеличить его в объёме и выбрать более производительный.
Подключил новый диск к серверу, стал копировать информацию. Находясь в консоли Linux сам размонтировал старый диск, который надо отключить и в его точку монтирования подключил новый диск с уже скопированными данными.
Иду в панель управления хостера и отключаю старый диск от сервера. Напоминаю, что в системе я его предварительно уже отмонтировал. Диск как-то подозрительно долго не отключался. Сходил в системный лог сервера посмотреть, отключился ли диск. И увидел там неожиданную информацию.
Идут постоянные попытки от systemd отмонтировать раздел, к которому подмонтирован уже НОВЫЙ диск. То есть у него записано где-то (я нашел в /run/systemd/generator), что к этой точке монтирования подключен старый диск. Софт хостера по управлению ресурсами просит systemd отключить старый диск от его точки монтирования, хотя по факту она уже занята другим диском.
Я в итоге не пострадал, так как приложение активно писало на диск и не дало его отмонтировать. Диск удалился без размонтирования. В таких случаях лучше новые диски монтировать в другие точки монтирования, а у приложений менять путь к рабочей директории. Это хоть и более хлопотно, но надёжнее, чем разбираться с тем, как хостинг монтирует и отключает диски.
Не смотрел, как в российских облаках хостеры монтируют сетевые диски в виртуалки. Если кто-то сталкивался, подскажите, эта тема актуальна для них, или там такого в принципе нет. Используется что-то другое, или диски только подключаются, но не монтируются автоматически.
В Linux есть служба systemd-mount, о которой я уже ранее писал. Хостер может её использовать для автоматического подключения сетевых дисков с разными параметрами. В целом это удобно и для него, и для пользователя. У меня был подключен в точку монтирования один такой диск. Я решил увеличить его в объёме и выбрать более производительный.
Подключил новый диск к серверу, стал копировать информацию. Находясь в консоли Linux сам размонтировал старый диск, который надо отключить и в его точку монтирования подключил новый диск с уже скопированными данными.
Иду в панель управления хостера и отключаю старый диск от сервера. Напоминаю, что в системе я его предварительно уже отмонтировал. Диск как-то подозрительно долго не отключался. Сходил в системный лог сервера посмотреть, отключился ли диск. И увидел там неожиданную информацию.
Идут постоянные попытки от systemd отмонтировать раздел, к которому подмонтирован уже НОВЫЙ диск. То есть у него записано где-то (я нашел в /run/systemd/generator), что к этой точке монтирования подключен старый диск. Софт хостера по управлению ресурсами просит systemd отключить старый диск от его точки монтирования, хотя по факту она уже занята другим диском.
Я в итоге не пострадал, так как приложение активно писало на диск и не дало его отмонтировать. Диск удалился без размонтирования. В таких случаях лучше новые диски монтировать в другие точки монтирования, а у приложений менять путь к рабочей директории. Это хоть и более хлопотно, но надёжнее, чем разбираться с тем, как хостинг монтирует и отключает диски.
Не смотрел, как в российских облаках хостеры монтируют сетевые диски в виртуалки. Если кто-то сталкивался, подскажите, эта тема актуальна для них, или там такого в принципе нет. Используется что-то другое, или диски только подключаются, но не монтируются автоматически.
Вчера была рассылка от Mikrotik. Я последнее время их игнорирую, так как продукция явно потеряла былую популярность в России в первую очередь из-за цен. Хотя близких аналогов нет, всё равно Микротики уже не так популярны. Но мимо вчерашней новости не смог пройти мимо, потому что она меня удивила.
Компания выпустила свой сервер - RouterOS enterprise Data Server со следующими характеристиками:
◽️20 слотов под U.2 NVMe диски, с поддежкой M.2
◽️сетевые порты: 2×100G QSFP28, 4×25G SFP28, 4×10G SFP+, 2×10G Ethernet
◽️16-core 2 GHz ARM CPU + 32GB DDR4 RAM
Внутри, как и ожидается – RouterOS в редакции Special ROSE edition с поддержкой в том числе технологии NVMe-TCP для экспорта дисков другим серверам. Это помимо традиционных SMB, NFS, iSCSI.
Компания позиционирует свой сервер как очень быстрое локальное хранилище под нагрузку, запущенную в контейнерах, которые RouterOS 7 поддерживает уже сейчас. В описании явно указаны примеры применения: MinIO, Nextcloud, Shinobi, Frigate и другие.
Неожиданная новинка. Цена всего $1950, что намекает на сегмент малого и среднего бизнеса. И при этом такие скорости, которые там особо не нужны.
Что думаете по поводу этих серверов? Мне кажется, зря они в сервера подались. Лучше бы на сетевых устройствах сконцентрировались, починили баги RouterOS 7, запустили бы наконец Long Term ветку. Представляю, сколько вылезет багов в системе на этом сервере, особенно в работе контейнеров под нагрузкой. Там инструментов для диагностики почти нет, работать с ними неудобно. Я бы не стал.
#mikrotik
Компания выпустила свой сервер - RouterOS enterprise Data Server со следующими характеристиками:
◽️20 слотов под U.2 NVMe диски, с поддежкой M.2
◽️сетевые порты: 2×100G QSFP28, 4×25G SFP28, 4×10G SFP+, 2×10G Ethernet
◽️16-core 2 GHz ARM CPU + 32GB DDR4 RAM
Внутри, как и ожидается – RouterOS в редакции Special ROSE edition с поддержкой в том числе технологии NVMe-TCP для экспорта дисков другим серверам. Это помимо традиционных SMB, NFS, iSCSI.
Компания позиционирует свой сервер как очень быстрое локальное хранилище под нагрузку, запущенную в контейнерах, которые RouterOS 7 поддерживает уже сейчас. В описании явно указаны примеры применения: MinIO, Nextcloud, Shinobi, Frigate и другие.
Неожиданная новинка. Цена всего $1950, что намекает на сегмент малого и среднего бизнеса. И при этом такие скорости, которые там особо не нужны.
Что думаете по поводу этих серверов? Мне кажется, зря они в сервера подались. Лучше бы на сетевых устройствах сконцентрировались, починили баги RouterOS 7, запустили бы наконец Long Term ветку. Представляю, сколько вылезет багов в системе на этом сервере, особенно в работе контейнеров под нагрузкой. Там инструментов для диагностики почти нет, работать с ними неудобно. Я бы не стал.
#mikrotik
This media is not supported in your browser
VIEW IN TELEGRAM
Типичная ситуация, которую я видел много раз. По какой-то причине некоторые руководители считают, что можно уволить сисадмина, не взять сразу на его место кого-нибудь, и оно само как-то будет работать. А потом что-то начинает ломаться.
Звонят сисадмину, но он почему-то не хочет помогать. Нанимают нового, но он ничего не знает, потому что никто не передал дела. Я так пришёл в одну компанию, где сисадмин уволился пару месяцев назад и там его помощник выживал, как мог. Но у него ни доступов, ни понимания, как тут всё работает, не было. Ни желания что-то делать за свою зарплату и должность помощника. Благо хоть учётки у директора были. Админа не стал дёргать, во всём без него разобрался.
Иногда мне пишут люди и просят помочь с какой-то проблемой, потому что сисадмин уволился и никто не знает, что делать. Я не берусь за такие задачи, обычно сразу отказываю. Не хочу связываться с такими делами. Это гарантированно бесконечные поиски информации и подводные камни в решении проблем.
Видео отсюда: https://www.youtube.com/shorts/8ooaojqQ70w
Прикольный, кстати, канал. Вроде ничего особенного, но некоторые вещи забавные.
#юмор (чёрный)
Звонят сисадмину, но он почему-то не хочет помогать. Нанимают нового, но он ничего не знает, потому что никто не передал дела. Я так пришёл в одну компанию, где сисадмин уволился пару месяцев назад и там его помощник выживал, как мог. Но у него ни доступов, ни понимания, как тут всё работает, не было. Ни желания что-то делать за свою зарплату и должность помощника. Благо хоть учётки у директора были. Админа не стал дёргать, во всём без него разобрался.
Иногда мне пишут люди и просят помочь с какой-то проблемой, потому что сисадмин уволился и никто не знает, что делать. Я не берусь за такие задачи, обычно сразу отказываю. Не хочу связываться с такими делами. Это гарантированно бесконечные поиски информации и подводные камни в решении проблем.
Видео отсюда: https://www.youtube.com/shorts/8ooaojqQ70w
Прикольный, кстати, канал. Вроде ничего особенного, но некоторые вещи забавные.
#юмор (чёрный)
Протокол НТТРv3, или как ещё называют эту версию QUIC, появился довольно давно. Практические реализации появились ещё в 2020-м году. Я всё как-то мимо него проходил, не погружался и не настраивал. На прошлой неделе вышло видео:
▶️ Ускоряем HTTP/3: DNS-записи HTTPS
В настройке HTTPv3 ничего сложного нет, так что решил разобраться, попробовать и дальше уже включать по умолчанию. Никаких технических преград сейчас к этому нет.
Для работы HTTP версии 3 нужно выполнить несколько шагов.
1️⃣ В настройке веб сервера включить его поддержку. В Nginx/Angie это делается следующим образом. Добавляем уже к существующим параметрам виртуального хоста с HTTPS следующие настройки:
Обращаю внимание на важный момент. В пакетах Angie из репозиториев разработчиков модуль http_v3_module включён по умолчанию. Не проверял его наличие в пакетах с Nginx. DeepSeek посоветовал вручную собрать Nginx с параметром
И второй момент. Я изначально add_header добавил не в корневой location, а в параметры сервера, где добавляются другие заголовки. HTTPv3 не заработал. Долго выяснял, в чём дело. Думал, это формальность. Я обычно всегда заголовки ко всему серверу применяю, а не location. Но тут, судя по всему, это имеет принципиальное значение.
2️⃣ Открываем на файрволе порт 443 UDP, так как QUIC работает по UDP. Я сначала тоже забыл это сделать. У меня по умолчанию всё, что не надо, закрыто, поэтому ничего не заработало. Быстро сообразил, что надо открыть UDP порт.
Этих настроек уже достаточно, чтобы HTTPv3 заработал, но не с первого запроса. По умолчанию браузер обращается по v2 и только после того, как придёт настроенный заголовок, переходит на v3. А первые несколько запросов улетают по v2.
Чтобы это исправить, придумана новая DNS запись типа HTTPS. Браузер, при обращении к сайту, ищет A запись и параллельно запрашивает HTTPS. Если она есть и там указано, что сайт поддерживает работу HTTPv3, он сразу обращается по v3.
Не все DNS хостинги поддерживают этот тип записи. Например, DNS от Яндекса не позволяет создать эту запись. Я в итоге от него отказался. Бесплатный DNS хостинг есть у Selectel. Причём недавно они выпустили новую версию этого хостинга и всем предлагают туда перейти. Мне как-то лень переносить было, и так всё работает. Но старая версия DNS хостинга не поддерживает эти записи. Пришлось перейти на новую. Там без проблем создал HTTPS запись. Выглядит она примерно так:
1 - приоритет
. - основное доменное имя, аналог serveradmin.ru
alpn="h3,h2" - указание на поддержку версии HTTPv3 и HTTPv2
3️⃣ Таким образом, третий пункт – добавление DNS записи типа HTTPS.
После этого сайт с первого запроса стал работать по протоколу третьей версии.
В настройке нет никаких проблем, можно прямо сейчас использовать новую версию протокола. К тому же это максимально безопасно, так как современные браузеры всегда делают попытку открыть сайт и по v2. Если вы где-то ошибётесь в настройке, то v3 просто не заработает. Я в этом убедился на практике. Когда что-то было не так, сайт работал как и прежде. И только после того, как всё сделал правильно, заработал HTTPv3.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#webserver #angie
▶️ Ускоряем HTTP/3: DNS-записи HTTPS
В настройке HTTPv3 ничего сложного нет, так что решил разобраться, попробовать и дальше уже включать по умолчанию. Никаких технических преград сейчас к этому нет.
Для работы HTTP версии 3 нужно выполнить несколько шагов.
1️⃣ В настройке веб сервера включить его поддержку. В Nginx/Angie это делается следующим образом. Добавляем уже к существующим параметрам виртуального хоста с HTTPS следующие настройки:
listen 443 quic reuseport;http3 on;location / { add_header Alt-Svc 'h3=":443"; ma=86400';}Обращаю внимание на важный момент. В пакетах Angie из репозиториев разработчиков модуль http_v3_module включён по умолчанию. Не проверял его наличие в пакетах с Nginx. DeepSeek посоветовал вручную собрать Nginx с параметром
--with-http_v3_module. И второй момент. Я изначально add_header добавил не в корневой location, а в параметры сервера, где добавляются другие заголовки. HTTPv3 не заработал. Долго выяснял, в чём дело. Думал, это формальность. Я обычно всегда заголовки ко всему серверу применяю, а не location. Но тут, судя по всему, это имеет принципиальное значение.
2️⃣ Открываем на файрволе порт 443 UDP, так как QUIC работает по UDP. Я сначала тоже забыл это сделать. У меня по умолчанию всё, что не надо, закрыто, поэтому ничего не заработало. Быстро сообразил, что надо открыть UDP порт.
Этих настроек уже достаточно, чтобы HTTPv3 заработал, но не с первого запроса. По умолчанию браузер обращается по v2 и только после того, как придёт настроенный заголовок, переходит на v3. А первые несколько запросов улетают по v2.
Чтобы это исправить, придумана новая DNS запись типа HTTPS. Браузер, при обращении к сайту, ищет A запись и параллельно запрашивает HTTPS. Если она есть и там указано, что сайт поддерживает работу HTTPv3, он сразу обращается по v3.
Не все DNS хостинги поддерживают этот тип записи. Например, DNS от Яндекса не позволяет создать эту запись. Я в итоге от него отказался. Бесплатный DNS хостинг есть у Selectel. Причём недавно они выпустили новую версию этого хостинга и всем предлагают туда перейти. Мне как-то лень переносить было, и так всё работает. Но старая версия DNS хостинга не поддерживает эти записи. Пришлось перейти на новую. Там без проблем создал HTTPS запись. Выглядит она примерно так:
# dig serveradmin.ru HTTPSserveradmin.ru. 3600 IN HTTPS 1 . alpn="h3,h2"1 - приоритет
. - основное доменное имя, аналог serveradmin.ru
alpn="h3,h2" - указание на поддержку версии HTTPv3 и HTTPv2
3️⃣ Таким образом, третий пункт – добавление DNS записи типа HTTPS.
После этого сайт с первого запроса стал работать по протоколу третьей версии.
В настройке нет никаких проблем, можно прямо сейчас использовать новую версию протокола. К тому же это максимально безопасно, так как современные браузеры всегда делают попытку открыть сайт и по v2. Если вы где-то ошибётесь в настройке, то v3 просто не заработает. Я в этом убедился на практике. Когда что-то было не так, сайт работал как и прежде. И только после того, как всё сделал правильно, заработал HTTPv3.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#webserver #angie
В своей деятельности нередко приходится вносить изменения в стандартные юниты systemd. Я не буду писать длинное руководство со всеми командами и параметрами. Их всё равно не запомнишь все. А 1-2 момента можно выхватить и сразу начать применять. Вот такими моментами и поделюсь, которые когда-то не знал, увидел, запомнил и применяю.
Покажу на примере службы Nginx, установленной из пакета в стандартном репозитории. По умолчанию служба автоматически не поднимется, если по какой-то причине завершится. Вот это и исправим, добавив принудительный автозапуск.
1️⃣ Раньше я шёл в
Содержимое юнита прилетит в консоль. Удобно, и никуда ходить не надо. Простая вещь, но узнал я о ней относительно недавно. Там сразу и путь видно, где лежит файл с настройками, если захочется его посмотреть напрямую.
2️⃣ Теперь добавляем изменение. Можно создать директорию
Открывается текстовый редактор по умолчанию. Вносим изменение:
Сохраняем. Конфигурация автоматически применяется. Теперь если набрать:
То мы увидим и исходную конфигурацию и файл
Не зная про команду
3️⃣ Расскажу про ещё один нюанс, который иногда забываю, потом разбираюсь, почему не работает, и вспоминаю, в чём проблема. Если добавляется новый параметр, то никаких нюансов нет, просто указываете его и всё. Если же параметры в
Переписали параметры запуска, которые в основном юните выглядят так:
Обнулять надо не все параметры. Не помню точно, какие нужно, а какие нет. Точно знаю, что всё, что относится к Exec надо обнулять, переменные окружения, если хотите полностью все переопределить, пользователей, наверняка что-то ещё. Если какие-то добавленные изменения не работают, просто обнулите их перед переопределением.
Рекомендую не добавлять эту статью в закладки, а сразу попробовать то, что тут описано, если не знакомы с этими командами. Это реально удобно. Вряд ли кто-то специально проходит курсы по systemd или изучает все её команды. Зачастую всё знать не нужно, лишнее быстро забывается, в итоге только время тратишь. А такую мелочь где-то выхватишь, запомнишь и потом используешь. Я поэтому любою смотреть, как другие в терминале работают. Постоянно что-то новое узнаешь и обогащаешь свой опыт.
#systemd
Покажу на примере службы Nginx, установленной из пакета в стандартном репозитории. По умолчанию служба автоматически не поднимется, если по какой-то причине завершится. Вот это и исправим, добавив принудительный автозапуск.
/etc/systemd/system/multi-user.target.wants, искал юнит nginx и смотрел, какие там установлены параметры. А можно сделать вот так:# systemctl cat nginx.serviceСодержимое юнита прилетит в консоль. Удобно, и никуда ходить не надо. Простая вещь, но узнал я о ней относительно недавно. Там сразу и путь видно, где лежит файл с настройками, если захочется его посмотреть напрямую.
/etc/systemd/system/nginx.service.d и туда положить конфигурацию override.conf с перекрывающими или дополнительными параметрами. Так давно не делаю, потому что помню команду:# systemctl edit nginx.serviceОткрывается текстовый редактор по умолчанию. Вносим изменение:
[Service]Restart=alwaysRestartSec=5sСохраняем. Конфигурация автоматически применяется. Теперь если набрать:
# systemctl cat nginx.serviceТо мы увидим и исходную конфигурацию и файл
/etc/systemd/system/nginx.service.d/override.conf, который был создан автоматически после команды edit. Не зная про команду
cat, я каждый раз вручную проверял override.conf и исходный юнит. Просто не довелось о ней услышать или где-то увидеть.override.conf перекрывают такие же в основном юните, например ExecStart и некоторые другие, то значение нужно сначала обнулить, а потом записать новое значение. Например:ExecStart=ExecStart=/usr/sbin/nginx -g 'daemon off; master_process off;'Переписали параметры запуска, которые в основном юните выглядят так:
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'Обнулять надо не все параметры. Не помню точно, какие нужно, а какие нет. Точно знаю, что всё, что относится к Exec надо обнулять, переменные окружения, если хотите полностью все переопределить, пользователей, наверняка что-то ещё. Если какие-то добавленные изменения не работают, просто обнулите их перед переопределением.
Рекомендую не добавлять эту статью в закладки, а сразу попробовать то, что тут описано, если не знакомы с этими командами. Это реально удобно. Вряд ли кто-то специально проходит курсы по systemd или изучает все её команды. Зачастую всё знать не нужно, лишнее быстро забывается, в итоге только время тратишь. А такую мелочь где-то выхватишь, запомнишь и потом используешь. Я поэтому любою смотреть, как другие в терминале работают. Постоянно что-то новое узнаешь и обогащаешь свой опыт.
#systemd
Please open Telegram to view this post
VIEW IN TELEGRAM
С момента первого моего упоминания сервиса axiom.co, продолжаю его использовать. Вновь пишу о нём, чтобы рассказать тем, кто не видел эту информацию. Очень простой в настройке и удобный в использовании для хранения и анализа логов веб сервера. Я пользуюсь полностью бесплатным тарифом, который не требует никаких подтверждений и персональных данных. Аутентификация через учётку на github. При этом позволяет хранить 500GB логов в месяц. Мне этого за глаза.
Про настройку и использование я уже писал ранее. По настройке с тех пор ничего не поменялось. Для отправки используется Vector (иногда падает, надо мониторить и переподнимать), у него встроенная интеграция с axiom.
Axiom условно можно назвать аналогом ELK, только сильно урезанным в плане функциональности. Из-за этого его особо не надо изучать. Отправляешь туда логи, заходишь и мышкой создаёшь нужные дашборды, запросы, отчёты. С ELK так не получится. В новых версиях даже заходить не хочется в виджеты и дашборды. Каждый раз, как первый раз, приходится вспоминать, как тут что-то сделать и построить нужную визуализацию.
Например, я позавчера включил на сайте протокол HTTPv3. Решил сходить посмотреть, сколько запросов по этому протоколу выполняется. Сбор логов настроен по указанной выше ссылке. В веб интерфейсе axiom иду в раздел Query и мышкой в конструкторе строю запрос: Dataset = serveradmin.ru, Where != http_version, Summarize count(), group by http_version.
И получил график растущего использования HTTPv3. Протокол используется.
Или вот ещё пример. Посмотрим, по каким url на запросы выходят 404 коды ответов. Dataset = serveradmin.ru, Where status =~ "404", Summarize count(), group by url.
Думаю, идея понятна. В сервисе ничего такого особенного нет, чего нельзя было бы сделать где-то в другом месте. То же самое можно сделать в ELK, Graylog, Loki, Goaccess. Но тут всё бесплатно, ничего настраивать не надо. Просто оправляем логи и пользуемся. Разумеется, если у вас там ничего секретного нет. А то уже предвижу комментарии на тему того, что я свои секретные логи веб сервера никому показывать не могу. Если не можете, то не используйте облачные сервисы. Тут всё очевидно. Наверняка они эти данные как-то используют, иначе откуда такая щедрость.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#logs #webserver
Про настройку и использование я уже писал ранее. По настройке с тех пор ничего не поменялось. Для отправки используется Vector (иногда падает, надо мониторить и переподнимать), у него встроенная интеграция с axiom.
Axiom условно можно назвать аналогом ELK, только сильно урезанным в плане функциональности. Из-за этого его особо не надо изучать. Отправляешь туда логи, заходишь и мышкой создаёшь нужные дашборды, запросы, отчёты. С ELK так не получится. В новых версиях даже заходить не хочется в виджеты и дашборды. Каждый раз, как первый раз, приходится вспоминать, как тут что-то сделать и построить нужную визуализацию.
Например, я позавчера включил на сайте протокол HTTPv3. Решил сходить посмотреть, сколько запросов по этому протоколу выполняется. Сбор логов настроен по указанной выше ссылке. В веб интерфейсе axiom иду в раздел Query и мышкой в конструкторе строю запрос: Dataset = serveradmin.ru, Where != http_version, Summarize count(), group by http_version.
['serveradmin.ru']| where isnotempty(http_version)| summarize count() by bin_auto(_time), http_versionИ получил график растущего использования HTTPv3. Протокол используется.
Или вот ещё пример. Посмотрим, по каким url на запросы выходят 404 коды ответов. Dataset = serveradmin.ru, Where status =~ "404", Summarize count(), group by url.
['serveradmin.ru']| where status =~ "404"| summarize count() by bin_auto(_time), urlДумаю, идея понятна. В сервисе ничего такого особенного нет, чего нельзя было бы сделать где-то в другом месте. То же самое можно сделать в ELK, Graylog, Loki, Goaccess. Но тут всё бесплатно, ничего настраивать не надо. Просто оправляем логи и пользуемся. Разумеется, если у вас там ничего секретного нет. А то уже предвижу комментарии на тему того, что я свои секретные логи веб сервера никому показывать не могу. Если не можете, то не используйте облачные сервисы. Тут всё очевидно. Наверняка они эти данные как-то используют, иначе откуда такая щедрость.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#logs #webserver