В продолжении вчерашней темы мониторинга Zabbix небольшая заметка из практики, с которой столкнулся на днях. Я абсолютно всегда без исключения настраиваю мониторинг TLS сертификатов и делегирование доменов. Даже если кажется, что всё под контролем, уведомления рассылаются, сертификаты обновляются и т.д.
Был почтовый домен mail.example.com с сервером и на него же посадили веб интерфейс, что не очень удобно. Не рекомендую так делать. Делайте для него отдельный домен, типа webmail.example.com или как-то ещё. Я веб интерфейс перекинул на отдельный веб сервер, и для домена mail.example.com в настройках nginx сделал переадресацию на webmail.example.com, а чтобы продолжать обновлять сертификат оставил
Прилетает от мониторинга через пару недель оповещение, что через 10 дней сертификат для mail протухает. А должен обновиться раньше. Иду разбираться и не понимаю, в чём проблема. На вид всё сделано корректно, как я обычно делаю. Смотрю логи ошибок certbot и вижу, что проверка домена mail идёт не по https, а по http. Я честно говоря почему-то думал, что сначала проверка всегда идёт по https, и если там всё ОК, то этого достаточно. Оказывается нет. Не обращал на это внимание.
У меня получилось так, что по http шла сразу переадресация всех запросов mail -> webmail, а последний хостился на другом сервере, поэтому проверка не проходила. Поправил правила nginx. Оставил
Для https аналогично.
Без мониторинга очень часто протухают сертификаты. Сколько раз это видел даже у крупных компаний. Помню у Rebrain когда-то давно был анонс вебинара про мониторинг. Переходишь по ссылке, а там браузер даёт ошибку на протухший сертификат. Получилось забавно. Поправили сразу, но сам факт. Либо не было мониторинга, либо за ним никто не следил. На протухшие домены и сертификаты лучше всего делать повторяющие уведомления, которые будут раз в сутки прилетать, пока не продлишь.
#zabbix #мониторинг
Был почтовый домен mail.example.com с сервером и на него же посадили веб интерфейс, что не очень удобно. Не рекомендую так делать. Делайте для него отдельный домен, типа webmail.example.com или как-то ещё. Я веб интерфейс перекинул на отдельный веб сервер, и для домена mail.example.com в настройках nginx сделал переадресацию на webmail.example.com, а чтобы продолжать обновлять сертификат оставил
location /.well-known
без переадресации. Сделал и забыл. Прилетает от мониторинга через пару недель оповещение, что через 10 дней сертификат для mail протухает. А должен обновиться раньше. Иду разбираться и не понимаю, в чём проблема. На вид всё сделано корректно, как я обычно делаю. Смотрю логи ошибок certbot и вижу, что проверка домена mail идёт не по https, а по http. Я честно говоря почему-то думал, что сначала проверка всегда идёт по https, и если там всё ОК, то этого достаточно. Оказывается нет. Не обращал на это внимание.
У меня получилось так, что по http шла сразу переадресация всех запросов mail -> webmail, а последний хостился на другом сервере, поэтому проверка не проходила. Поправил правила nginx. Оставил
location /.well-known
и для http, и для https, чтобы в любом случае проверка домена проходила успешно. Что-то типа такого:server {
listen 80;
server_name mail.example.com;
location /.well-known {
root /var/www/mail.example.com;
}
location / {
return 301 https://webmail.example.com$request_uri;
}
}
Для https аналогично.
Без мониторинга очень часто протухают сертификаты. Сколько раз это видел даже у крупных компаний. Помню у Rebrain когда-то давно был анонс вебинара про мониторинг. Переходишь по ссылке, а там браузер даёт ошибку на протухший сертификат. Получилось забавно. Поправили сразу, но сам факт. Либо не было мониторинга, либо за ним никто не следил. На протухшие домены и сертификаты лучше всего делать повторяющие уведомления, которые будут раз в сутки прилетать, пока не продлишь.
#zabbix #мониторинг
Server Admin
Повторяющиеся уведомления в Zabbix
Настройка регулярных повторяющихся оповещений в системе мониторинга zabbix. Показано на конкретном примере с триггером.
2👍92👎4
Решил всё же после выхода Zabbix Server 7.2 обновить один из работающих серверов до этой версии. Давно собирался там порядок навести и нарисовать новые дашборды. Имеет смысл это сделать уже на свежей версии.
Сервер был версии 6.0 на ОС Debian 11. Первым делом обновил Debian 11 до 12. Всё прошло гладко. Debian хорошо обновляется с релиза на релиз. Не припоминаю серьёзных проблем с этим. Потом подключил репозиторий от Zabbix 7 и обновил его с 6.0 до 7.0. Процесс обновления в целом прошёл штатно, но на выходе я столкнулся с проблемой.
Это был старый сервер, который обновляется с релиза на релиз, с системы на систему с 4-й версии. А может и того раньше. Не помню точно. Он всегда работал под Apache. После обновления на 7.0 в веб интерфейсе пропал русский язык. В настройках он остался, но если в профиле выбрать русский язык и сохранить настройки, то ничего не менялось. Оставался английский.
Я немного погуглил, решения не нашёл. Несмотря на то, что все необходимые условия для появления русского языка выполнены, он не работал. Я не стал дальше решать вопрос, а просто заменил Apache на Nginx и Php-fpm. Русский язык появился. То есть проблема сидела где-то в настройках Apache и скорее всего php.
Дальше в пару шагов обновил 7.0 до 7.2:
Тут тоже столкнулся с ошибкой. В 7.2 веб интерфейс вынесли в новую директорию
❗️С версией сервера 7.2 не будут работать прокси 6.0. Для меня это было сюрпризом, так как в одном сегменте сети до сих пор работают Centos 7 и туда максимум можно поставить версию 6.0. С сервером 7.0 они нормально работали, а с 7.2 уже не хотят. Пришлось решать этот вопрос отдельной установкой туда более свежей системы.
Несмотря на то, что проделал довольно значительные обновления не только со сменой ветки программы, но и самой системы, прошло всё без особых сюрпризов. Потратил на всё про всё около двух часов. В комментариях к своим статьям по обновлению Zabbix постоянно встречаю различные ошибки у людей. То база не обновляется, то бэкенд остался старой версии. Сам с ними не сталкиваюсь. Если всё делать аккуратно с пониманием и проверкой того, что делаешь, то всё получается.
Перед обновлением сделал снепшот виртуалки и не забыл его удалить, когда убедился, что всё получилось и работает.
#zabbix
Сервер был версии 6.0 на ОС Debian 11. Первым делом обновил Debian 11 до 12. Всё прошло гладко. Debian хорошо обновляется с релиза на релиз. Не припоминаю серьёзных проблем с этим. Потом подключил репозиторий от Zabbix 7 и обновил его с 6.0 до 7.0. Процесс обновления в целом прошёл штатно, но на выходе я столкнулся с проблемой.
Это был старый сервер, который обновляется с релиза на релиз, с системы на систему с 4-й версии. А может и того раньше. Не помню точно. Он всегда работал под Apache. После обновления на 7.0 в веб интерфейсе пропал русский язык. В настройках он остался, но если в профиле выбрать русский язык и сохранить настройки, то ничего не менялось. Оставался английский.
Я немного погуглил, решения не нашёл. Несмотря на то, что все необходимые условия для появления русского языка выполнены, он не работал. Я не стал дальше решать вопрос, а просто заменил Apache на Nginx и Php-fpm. Русский язык появился. То есть проблема сидела где-то в настройках Apache и скорее всего php.
Дальше в пару шагов обновил 7.0 до 7.2:
# wget https://repo.zabbix.com/zabbix/7.2/release/debian/pool/main/z/zabbix-release/zabbix-release_latest_7.2+debian12_all.deb
# dpkg -i zabbix-release_latest_7.2+debian12_all.deb
# apt update
# apt upgrade
Тут тоже столкнулся с ошибкой. В 7.2 веб интерфейс вынесли в новую директорию
/usr/share/zabbix/ui
вместо прошлой /usr/share/zabbix
. Нужно поправить это в настройках nginx. Больше ничего менять не надо. Перезапускаем службу и тестируем новую версию 7.2.❗️С версией сервера 7.2 не будут работать прокси 6.0. Для меня это было сюрпризом, так как в одном сегменте сети до сих пор работают Centos 7 и туда максимум можно поставить версию 6.0. С сервером 7.0 они нормально работали, а с 7.2 уже не хотят. Пришлось решать этот вопрос отдельной установкой туда более свежей системы.
Несмотря на то, что проделал довольно значительные обновления не только со сменой ветки программы, но и самой системы, прошло всё без особых сюрпризов. Потратил на всё про всё около двух часов. В комментариях к своим статьям по обновлению Zabbix постоянно встречаю различные ошибки у людей. То база не обновляется, то бэкенд остался старой версии. Сам с ними не сталкиваюсь. Если всё делать аккуратно с пониманием и проверкой того, что делаешь, то всё получается.
Перед обновлением сделал снепшот виртуалки и не забыл его удалить, когда убедился, что всё получилось и работает.
#zabbix
1👍110👎3
Для рисования схем существует много различных программ. Причём этот вопрос хорошо закрывается полностью бесплатным ПО. Его можно разделить на 2 категории: ручное рисование и автоматическое на основе текстового описания. Сегодня речь пойдёт про ручное рисование.
Наиболее популярные инструменты - draw.io и excalidraw.com. Оба сервиса представляют собой веб приложение, которое можно в том числе развернуть у себя на веб сервере. Результатом работы в браузере будет обычный файл, который можно сохранить к себе на компьютер. Это удобно. Не нужно ничего устанавливать локально, но при этом все схемы у тебя всегда под рукой. Можно воспользоваться как своим сервисом, так и публичным.
Я одно время пользовался draw.io и думал, что ничего другого и не надо. Вроде всё и так есть. Потом кто-то посоветовал посмотреть excalidraw. Он мне понравился. Там по умолчанию нет специальных иконок и прочих красивостей, но на деле оказалось, что простыми прямоугольниками и прочими геометрическими фигурами со стрелками нарисовать схему быстрее и проще. И выглядит она нагляднее. Так что теперь рисую там. При желании туда тоже можно импортировать готовые наборы иконок, но я без них обхожусь.
Видел не раз в комментариях упоминание lucidchart. Про него есть подробное видео на ютубе на канале ADV-IT. Автор нарисовал для примера пару схем и показал процесс. Изначально думал, что это наподобие описанных выше программ, где так же есть open source версия, но нет. Lucidchart полностью коммерческий продукт с бесплатным тарифным планом, в котором основное ограничение - 60 объектов на схему. Сайт использует какую-то хитрую блокировку по странам, так что я не смог зарегистрироваться даже через американский VPN. Так что можно смело про него забыть. Lucidchart у меня год в закладках висел, ждал своего часа и вот дождался.
☝️ Вернусь ещё раз к draw и excalidraw и расскажу об одной особенности, которая может быть кому-то незнакома. Для этих сервисов есть плагины для популярной IDE - VSCode. С помощью этих плагинов вы можете хранить схемы в репозиториях и изменять их прямо в редакторе. После изменения схемы автоматически рендерятся в картинки. То есть для вас это редактируемые объекты, которые легко изменяются, а для тех, кто будет смотреть этот репозиторий, это будут статические png картинки. Вот тут подробно показано, как это работает:
▶️ Рисуем документацию прямо внутри IDE - excalidraw
Ну и отдельно перечислю бесплатные сервисы, где можно автоматически создавать блок схемы на основе описания с помощью кода:
◽️Graphviz - ветеран подобных сервисов, очень старый продукт, который развивается и использует по сей день.
◽️Mermaid - более современный сервис, много где имеет встроенную поддержку (GitLab, Gitea, Joplin, Notion и т.д.), наиболее популярный на сегодняшний день.
Таких движков для описания кода очень много. У них довольно высокий порог вхождения. Используется свой язык разметки, так что придётся немного поразбираться.
#схемы
Наиболее популярные инструменты - draw.io и excalidraw.com. Оба сервиса представляют собой веб приложение, которое можно в том числе развернуть у себя на веб сервере. Результатом работы в браузере будет обычный файл, который можно сохранить к себе на компьютер. Это удобно. Не нужно ничего устанавливать локально, но при этом все схемы у тебя всегда под рукой. Можно воспользоваться как своим сервисом, так и публичным.
Я одно время пользовался draw.io и думал, что ничего другого и не надо. Вроде всё и так есть. Потом кто-то посоветовал посмотреть excalidraw. Он мне понравился. Там по умолчанию нет специальных иконок и прочих красивостей, но на деле оказалось, что простыми прямоугольниками и прочими геометрическими фигурами со стрелками нарисовать схему быстрее и проще. И выглядит она нагляднее. Так что теперь рисую там. При желании туда тоже можно импортировать готовые наборы иконок, но я без них обхожусь.
Видел не раз в комментариях упоминание lucidchart. Про него есть подробное видео на ютубе на канале ADV-IT. Автор нарисовал для примера пару схем и показал процесс. Изначально думал, что это наподобие описанных выше программ, где так же есть open source версия, но нет. Lucidchart полностью коммерческий продукт с бесплатным тарифным планом, в котором основное ограничение - 60 объектов на схему. Сайт использует какую-то хитрую блокировку по странам, так что я не смог зарегистрироваться даже через американский VPN. Так что можно смело про него забыть. Lucidchart у меня год в закладках висел, ждал своего часа и вот дождался.
☝️ Вернусь ещё раз к draw и excalidraw и расскажу об одной особенности, которая может быть кому-то незнакома. Для этих сервисов есть плагины для популярной IDE - VSCode. С помощью этих плагинов вы можете хранить схемы в репозиториях и изменять их прямо в редакторе. После изменения схемы автоматически рендерятся в картинки. То есть для вас это редактируемые объекты, которые легко изменяются, а для тех, кто будет смотреть этот репозиторий, это будут статические png картинки. Вот тут подробно показано, как это работает:
▶️ Рисуем документацию прямо внутри IDE - excalidraw
Ну и отдельно перечислю бесплатные сервисы, где можно автоматически создавать блок схемы на основе описания с помощью кода:
◽️Graphviz - ветеран подобных сервисов, очень старый продукт, который развивается и использует по сей день.
◽️Mermaid - более современный сервис, много где имеет встроенную поддержку (GitLab, Gitea, Joplin, Notion и т.д.), наиболее популярный на сегодняшний день.
Таких движков для описания кода очень много. У них довольно высокий порог вхождения. Используется свой язык разметки, так что придётся немного поразбираться.
#схемы
👍121👎1
В ОС на базе Linux существуют несколько наиболее популярных программных решений для построения отказоустойчивого дискового хранилища, или по простому - софтовых рейдов:
◽️Mdadm
◽️LVM Raid
◽️ZFS
Про Mdadm рассказывать особо нечего. Это самый популярный программный рейд, которому сто лет в обед. Он очень прост в настройке и эксплуатации, про него масса статей с инструкциями. Я использую его повсеместно и проблем с ним никогда не знал. Много писал про него на канале.
Про ZFS тоже рассказывать большого смысла нет. Известная и проверенная временем технология. Я ещё на Freebsd её использовал и очень радовался, когда корень системы можно было поставить на ZFS. Она спокойно переживала аварийные выключения сервера, в отличие от UFS, которая была файловой системой по умолчанию и постоянно ломалась после аварийных отключений.
А вот про LVM Raid и информации немного, и практического применения я не видел. Мне не очень понятно, почему. Я немного поигрался с этим рейдом на тестах. Выглядит интересно. Сразу скажу, почему я решил обратить на него внимание. LVM Raid поддерживает технологию DM-integrity (device mapper integrity), с помощью которой можно контролировать целостность хранимой информации с помощью дополнительного хранения и проверки метаданных (checksum) файлов. Это то, что ZFS делает по умолчанию. Поясню, зачем это надо.
В современных дисках, как HDD, так и SSD, очень высокая плотность записи. Это делает сохранение заряда в ячейках менее надёжным и долговременным. Допустим, у вас на дисках долго хранится какой-то объём информации. В каких-то ячейках изменились записанные биты либо из-за ошибок при записи, либо возникли во время хранения. При этом диски полностью исправны и ошибок чтения нет. То есть технически всё в порядке. Но во время чтения вы можете получить битые файлы, которые при этом успешно прочитаются. Но информация будет разрушена.
При использовании Mdadm и поверх него ФС EXT4 или XFS, никакой защиты от подобных ошибок у вас не будет. Если не делать регулярное сопоставление записанных файлов с каким-то другим хранилищем таких же файлов, то о битых файлах вы не узнаете, пока явно не наткнётесь на них во время проверки. В LVM Raid с поддержкой DM-integrity часть хранилища выделяется под хранение метаданных файлов. Я не нашёл точно информации, сколько конкретно % от общего объёма тратится. Но там немного, не более 10%.
При использовании LVM Raid + DM-integrity вы узнаете о битых файлах при очередной проверке файлов с тем, что записано ранее в хранилище метаданных. Это происходит как минимум во время чтения. Я так понимаю, что процесс этот может происходить и в фоне, можно и принудительно запускать и смотреть результаты. CLI от LVM даёт такие возможности. При обнаружении повреждённых файлов, они будут автоматически восстановлены с других носителей в рейд массиве.
Хотел сделать заметку с примерами создания и управления LVM Raid, но сделаю это позже отдельной заметкой в виде готовой шпаргалки. Вводная теоретическая часть получилась слишком длинной.
Если кто-то использовал LVM Raid, поделитесь опытом и впечатлениями. Особенно интересно, если дополнительно включали DM-integrity. Без неё я не вижу смысла использовать рейд LVM, а не Mdadm. LVM хоть и даёт бОльшую гибкость в управлении. Например, можно на лету изменить уровень рейда, увеличить или уменьшить тома. Но на практике это не особо нужно. Mdadm проще и более предсказуем, интуитивен в управлении. Технически DM-integrity можно включить и для дисков в составе Mdadm, но там нет нативной поддержки, как в LVM. Битые файлы будут помечаться как ошибки чтения диска и Mdadm будет пытаться их синхронизировать с других дисков. Это тоже рабочий вариант, но не такой удобный в плане управления и отслеживания ошибок.
#lvm #raid
◽️Mdadm
◽️LVM Raid
◽️ZFS
Про Mdadm рассказывать особо нечего. Это самый популярный программный рейд, которому сто лет в обед. Он очень прост в настройке и эксплуатации, про него масса статей с инструкциями. Я использую его повсеместно и проблем с ним никогда не знал. Много писал про него на канале.
Про ZFS тоже рассказывать большого смысла нет. Известная и проверенная временем технология. Я ещё на Freebsd её использовал и очень радовался, когда корень системы можно было поставить на ZFS. Она спокойно переживала аварийные выключения сервера, в отличие от UFS, которая была файловой системой по умолчанию и постоянно ломалась после аварийных отключений.
А вот про LVM Raid и информации немного, и практического применения я не видел. Мне не очень понятно, почему. Я немного поигрался с этим рейдом на тестах. Выглядит интересно. Сразу скажу, почему я решил обратить на него внимание. LVM Raid поддерживает технологию DM-integrity (device mapper integrity), с помощью которой можно контролировать целостность хранимой информации с помощью дополнительного хранения и проверки метаданных (checksum) файлов. Это то, что ZFS делает по умолчанию. Поясню, зачем это надо.
В современных дисках, как HDD, так и SSD, очень высокая плотность записи. Это делает сохранение заряда в ячейках менее надёжным и долговременным. Допустим, у вас на дисках долго хранится какой-то объём информации. В каких-то ячейках изменились записанные биты либо из-за ошибок при записи, либо возникли во время хранения. При этом диски полностью исправны и ошибок чтения нет. То есть технически всё в порядке. Но во время чтения вы можете получить битые файлы, которые при этом успешно прочитаются. Но информация будет разрушена.
При использовании Mdadm и поверх него ФС EXT4 или XFS, никакой защиты от подобных ошибок у вас не будет. Если не делать регулярное сопоставление записанных файлов с каким-то другим хранилищем таких же файлов, то о битых файлах вы не узнаете, пока явно не наткнётесь на них во время проверки. В LVM Raid с поддержкой DM-integrity часть хранилища выделяется под хранение метаданных файлов. Я не нашёл точно информации, сколько конкретно % от общего объёма тратится. Но там немного, не более 10%.
При использовании LVM Raid + DM-integrity вы узнаете о битых файлах при очередной проверке файлов с тем, что записано ранее в хранилище метаданных. Это происходит как минимум во время чтения. Я так понимаю, что процесс этот может происходить и в фоне, можно и принудительно запускать и смотреть результаты. CLI от LVM даёт такие возможности. При обнаружении повреждённых файлов, они будут автоматически восстановлены с других носителей в рейд массиве.
Хотел сделать заметку с примерами создания и управления LVM Raid, но сделаю это позже отдельной заметкой в виде готовой шпаргалки. Вводная теоретическая часть получилась слишком длинной.
Если кто-то использовал LVM Raid, поделитесь опытом и впечатлениями. Особенно интересно, если дополнительно включали DM-integrity. Без неё я не вижу смысла использовать рейд LVM, а не Mdadm. LVM хоть и даёт бОльшую гибкость в управлении. Например, можно на лету изменить уровень рейда, увеличить или уменьшить тома. Но на практике это не особо нужно. Mdadm проще и более предсказуем, интуитивен в управлении. Технически DM-integrity можно включить и для дисков в составе Mdadm, но там нет нативной поддержки, как в LVM. Битые файлы будут помечаться как ошибки чтения диска и Mdadm будет пытаться их синхронизировать с других дисков. Это тоже рабочий вариант, но не такой удобный в плане управления и отслеживания ошибок.
#lvm #raid
2👍136👎3
⇨ Truenas Scale Electric Eel. Как же долго я тебя ждала
Вышло крупное обновление Trunas Scale - одно из лучших open source решений для NAS. Оказывается, в нём под капотом был Kebernetes 😱 В обновлении его заменили на Docker Compose. Содержательное видео по этому продукту.
⇨ OpenProject - Система для организации проектов. Обзор функций. Установка пакетов и docker
Обзор OpenProject - системы управления проектами с открытым исходным кодом. Популярная и функциональная система. Раньше про неё не слышал. Думаю, разверну и сделаю отдельную заметку.
⇨ Установка Speedtest Tracker на Synology
Обзор Speedtest Tracker для регулярной проверки и хранения результатов замеров скорости интернета. Не раз получал просьбы посоветовать что-то для регулярных замеров, чтобы был график и можно было отслеживать свой канал. Вот вариант решения задачи.
⇨ xPipe is a fantastic, amazing remote connection manager!
Обзор xPipe - менеджера для удалённых подключений. Я писал про него. Пользовался им некоторое время, но в итоге бросил. Докучали некоторые баги и его тормознутость. По виду и возможностям всё нравится, но на практике не зашло. Попробуйте, может вам понравится. Из особенностей - для подключений по SSH использует Windows Terminal. Лично мне это особенно нравилось.
⇨ What’s the better Git? // GitLab vs Gitea
Краткое сравнение GitLab и Gitea. Так то они сильно различаются. Не знаю, что сподвигло автора сравнить их в лоб. Наверное, тема популярная.
⇨ Self-host your own Git platform! // Gitea Tutorial
Вдогонку от этого же автора ролик про саму Gitea.
⇨ GitLab - Установка приватного GitLab Сервера с Ручной и Авто настройкой SSL + PASSWORD
Подробный урок по установке Gitlab. Рассмотрены и системные требования, и разные редакции и т.д. База для тех, кто не особо знаком с продуктом.
⇨ GitLab CI/CD - Полный DevOps Pipeline с НУЛЯ, Создание Docker Image и деплой в AWS ECS Fargate
Практический урок по созданию пайплайна в Gitlab. Он привязан к сервисам AWS. Пол урока создание там сущностей и раздача прав. Тем не менее показано всё наглядно для общего понимания, как это в принципе работает: разные ветки в git, ветвление деплоя в зависимости от ветки, переменные и т.д.
⇨ 7 Правил безопасности сервера
Автор рассмотрел некоторый набор правил для повышения безопасности сервера. Информация для новичков, набор тривиальный: не ходим под root, не используем пароль, прячем SSH порт и т.д.
⇨ PostgreSQL Clustering the Hard Way...
Тяжёлое для восприятия техническое видео на час по построению кластера на базе PostgreSQL. Смотреть имеет смысл, если вам актуальна эта тема. Кластер на базе Patroni.
⇨ Установка ONLYOFFICE в докер и связываем его с Nextcloud
Небольшая инструкция по настройке этой связки. Меня не раз спрашивали, как это настроить. Последний раз буквально неделю назад кто-то то ли в личку, то ли куда-то в комментарии писал.
⇨ SafeLine: A Feature-Rich WAF with a Catch (or Two)
Обзор open source self-hosted WAF. Не слышал про него ранее. Думаю, что попробую и напишу отдельную заметку.
⇨ Reubah: Optimize Your Images & Files Without Compromising Your Privacy
Функциональный open source продукт Rebuah для одиночной или пакетной обработки изображений. В целом ничего особенно, но выглядит аккуратно и удобно. Можно сразу перемотать на демонстрацию. Мне понравилось. В список программ для собственного применения записал.
⇨ The Perfect Home Server 2024 – 56TB, ECC, IPMI, Quiet & (kind of) Compact
Интересное описание сборки домашнего сервера с минимальным шумом с IPMI и ECC. Понравилась материнка из видео - gigabyte mc12-le0. К сожалению, не нашёл, где её у нас купить можно. На aliexpress тоже нету. У автора ролики очень хорошего качества. Огромное количество просмотров для такой узкой темы это подтверждают.
#видео
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Truenas Scale Electric Eel. Как же долго я тебя ждала
#nas, #opnsense, #truenas, #proxmox, #ubuntu
В этом ролике поговорим о ключевых изменениях в новой версии Truenas Scale 24.10. Посмотрим на новый dashboard, как расширить пулы, а самое главное пощупаем docker, который появился вместо kubernetes.
Можно…
В этом ролике поговорим о ключевых изменениях в новой версии Truenas Scale 24.10. Посмотрим на новый dashboard, как расширить пулы, а самое главное пощупаем docker, который появился вместо kubernetes.
Можно…
1👍73👎4
This media is not supported in your browser
VIEW IN TELEGRAM
Ты просыпаешься на пыльном чердаке.
Снаружи буря грохочет по старой черепице.
Во рту пересохло. Ноги болят.
Ты прикован наручниками к трубе, и твоя рука обожжена.
Перед тобой стоит женщина. Тесак в ее руке блестит в тусклом свете.
"Что, - спрашивает она, - ты готов сделать, чтобы сбежать?"
Неплохое начало для триллера? Так начинается текстовая обучающая игра по regex выражениям SLASH\ESCAPE. В данном случае нетрудно догадаться об ответе: "Всё, что угодно." В формате regex это будет
"Всё, что угодно? - говорит она, - сурово."
Ты видишь, как она замахивается тесаком, как раз вовремя, чтобы отскочить назад. Металл оставляет порез на щеке, а затем ударяется о трубу позади тебя.
Три пальца на левой руке горят огнём. Ты понимаешь, что произошло, только когда видишь, как они отскакивают от твоего ботинка.
Над вами от внезапного толчка что-то зашаталось. Вы слышите, как что-то сдвигается, и женщина перед вами исчезает под грудой мусора.
Ваша рука выскользнула из наручника.
Вы можете двигаться ВПРАВО или ВЛЕВО - в RegEx вы можете просто написать слово, которое хотите сопоставить, так что пишите свой выбор.
Ну и так далее. К каждому заданию есть подсказка, которая объясняет правильный ответ и рассказывает, где это может пригодиться.
Сделано прикольно и атмосферно. Не видел и не слышал раньше про эту игру. Увидел случайно в другой похожей игре: lost-at-sql. Там тоже свой необычный сюжет. Вы капитан подводной лодки SS.QL, у которой какие-то проблемы. Вам надо их решать посредством SQL запросов к базе данных аппарата. Сделано забавно, но про SQL и так последнее время было много заметок, поэтому не стал акцентировать внимание именно на ней. С regex игра больше понравилась.
🎮 ⇨ SLASH\ESCAPE
📱⇨ Lost at SQL
#regex #обучение #игра
Снаружи буря грохочет по старой черепице.
Во рту пересохло. Ноги болят.
Ты прикован наручниками к трубе, и твоя рука обожжена.
Перед тобой стоит женщина. Тесак в ее руке блестит в тусклом свете.
"Что, - спрашивает она, - ты готов сделать, чтобы сбежать?"
Неплохое начало для триллера? Так начинается текстовая обучающая игра по regex выражениям SLASH\ESCAPE. В данном случае нетрудно догадаться об ответе: "Всё, что угодно." В формате regex это будет
.*
"Всё, что угодно? - говорит она, - сурово."
Ты видишь, как она замахивается тесаком, как раз вовремя, чтобы отскочить назад. Металл оставляет порез на щеке, а затем ударяется о трубу позади тебя.
Три пальца на левой руке горят огнём. Ты понимаешь, что произошло, только когда видишь, как они отскакивают от твоего ботинка.
Над вами от внезапного толчка что-то зашаталось. Вы слышите, как что-то сдвигается, и женщина перед вами исчезает под грудой мусора.
Ваша рука выскользнула из наручника.
Вы можете двигаться ВПРАВО или ВЛЕВО - в RegEx вы можете просто написать слово, которое хотите сопоставить, так что пишите свой выбор.
Ну и так далее. К каждому заданию есть подсказка, которая объясняет правильный ответ и рассказывает, где это может пригодиться.
Сделано прикольно и атмосферно. Не видел и не слышал раньше про эту игру. Увидел случайно в другой похожей игре: lost-at-sql. Там тоже свой необычный сюжет. Вы капитан подводной лодки SS.QL, у которой какие-то проблемы. Вам надо их решать посредством SQL запросов к базе данных аппарата. Сделано забавно, но про SQL и так последнее время было много заметок, поэтому не стал акцентировать внимание именно на ней. С regex игра больше понравилась.
🎮 ⇨ SLASH\ESCAPE
📱⇨ Lost at SQL
#regex #обучение #игра
👍76👎11
Несмотря на то, что mdadm хоронят уже много лет, например, те же разработчики Proxmox, я успешно и повсеместно его использую. Он меня полностью устраивает в плане надёжности и предсказуемости. Берёшь любой бюджетный сервер на 2 или 4 SSD или NVME диска и собираешь RAID1 или RAID10, ставишь на все диски загрузчик и больше не переживаешь за выход из строя одного из дисков.
Я уже десятки раз заменял вышедшие из строя диски и никогда не имел с mdadm проблем (постучал по дереву). Буквально вчера утром получил уведомление с одного из серверов о выходе из строя диска (картинка с ошибкой и данными из мониторинга внизу) и вечером заказал замену у техподдержки дедика. В этот раз собрал практически все возможные проблемы, так что оформлю в короткую шпаргалку.
Вышел из строя диск
Я получил ошибку:
В данном случае в тексте ошибки присутствует uuid одного из разделов оставшегося диска
Чтобы исправить ошибку выше, надо вывести из состава массивов разделы диска
Так для всех массивов. В моём случае их было 3:
Теперь команда
После этого сервер можно выключить и написать в техподдержку, чтобы выполнили замену. Внимательно укажите серийный номер сбойного диска. У меня он всегда в Zabbix остаётся. Отдельно не веду каталог дисков. Просто настраиваю мониторинг. Обычно этого достаточно.
После того, как поддержка заменит диск и включит сервер, можно добавлять новый диск в массив. Проверяем его:
Убеждаемся, что диск подходящего размера и он чистый, без разметки. У меня на подобных серверах обычно mbr разметка, так как SSD диски не очень большие. Разделы с работающего диска на новый копирую так:
Скопировали с
Теперь добавляем разделы нового диска в массив:
Наблюдаем синхронизацию в режиме реального времени:
Один из массивов у меня был остановлен:
Не получалось к нему добавить недостающий раздел. Перед этим его пришлось запустить:
После этого благополучно добавил недостающий раздел:
Не знаю, с чем связано то, что иногда массивы останавливаются. Хорошо, что в данном случае это был не корневой или загрузочный раздел. Как-то раз у меня остановился корневой раздел. Пришлюсь грузиться с livecd, запускать массив и добавлять в него раздел. После этого нормально загрузилась система. Случается такое редко. Добавляет некоторую нервозность ко всему процессу замены диска. Всегда есть шанс, что понадобится livecd или доступ к консоли сервера.
После замены диска не забываем установить загрузчик на новый диск
Обязательно убедитесь, что ошибок нет. Если есть, сразу их решайте, не откладывайте на потом.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mdadm
Я уже десятки раз заменял вышедшие из строя диски и никогда не имел с mdadm проблем (постучал по дереву). Буквально вчера утром получил уведомление с одного из серверов о выходе из строя диска (картинка с ошибкой и данными из мониторинга внизу) и вечером заказал замену у техподдержки дедика. В этот раз собрал практически все возможные проблемы, так что оформлю в короткую шпаргалку.
Вышел из строя диск
/dev/sda
, который входит в состав RAID1 из двух дисков. Это первый диск, с которого грузился загрузчик. Перед заменой обязательно проверяем, что есть загрузчик на втором диске:# dpkg-reconfigure grub-pc
Я получил ошибку:
grub-pc: Running grub-install ...
Installing for i386-pc platform.
grub-install.real: error: disk `mduuid/fe51668460b267542c1d5c1adb4e7680' not found.
grub-install failure for /dev/sdb
В данном случае в тексте ошибки присутствует uuid одного из разделов оставшегося диска
/dev/sdb
, который входит в массив mdadm, который из-за выхода из строя диска /dev/sda
находится в состоянии Degraded. Я точно знал, что ранее на /dev/sdb
уже ставил загрузчик, но решил перестраховаться. Чтобы исправить ошибку выше, надо вывести из состава массивов разделы диска
/dev/sda
:# mdadm /dev/md126 --fail /dev/sda1
# mdadm /dev/md126 --remove /dev/sda1
Так для всех массивов. В моём случае их было 3:
/
, /boot
и swap
. Я swap никогда в раздел не выношу, храню в файле, но это был шаблон от хостера. Там такая разбивка по умолчанию. Теперь команда
dpkg-reconfigure grub-pc
отработала без ошибок, поставила загрузчик на /dev/sdb.После этого сервер можно выключить и написать в техподдержку, чтобы выполнили замену. Внимательно укажите серийный номер сбойного диска. У меня он всегда в Zabbix остаётся. Отдельно не веду каталог дисков. Просто настраиваю мониторинг. Обычно этого достаточно.
После того, как поддержка заменит диск и включит сервер, можно добавлять новый диск в массив. Проверяем его:
# smartctl -i /dev/sda
# fdisk -l | grep /dev/sda
Убеждаемся, что диск подходящего размера и он чистый, без разметки. У меня на подобных серверах обычно mbr разметка, так как SSD диски не очень большие. Разделы с работающего диска на новый копирую так:
# sfdisk -d /dev/sdb | sfdisk /dev/sda
Скопировали с
/dev/sdb
на /dev/sda
. Не перепутайте диски и не обнулите разметку старого диска. Убеждаемся, что разметка на /dev/sda
идентична /dev/sdb
:# fdisk -l
Теперь добавляем разделы нового диска в массив:
# mdadm --add /dev/md126 /dev/sda1
Наблюдаем синхронизацию в режиме реального времени:
# watch cat /proc/mdstat
Один из массивов у меня был остановлен:
md127 : inactive sdb3[1](S)
Не получалось к нему добавить недостающий раздел. Перед этим его пришлось запустить:
# mdadm --run /dev/md127
mdadm: started array /dev/md/installrescue:43
После этого благополучно добавил недостающий раздел:
# mdadm --add /dev/md127 /dev/sda3
mdadm: added /dev/sda3
Не знаю, с чем связано то, что иногда массивы останавливаются. Хорошо, что в данном случае это был не корневой или загрузочный раздел. Как-то раз у меня остановился корневой раздел. Пришлюсь грузиться с livecd, запускать массив и добавлять в него раздел. После этого нормально загрузилась система. Случается такое редко. Добавляет некоторую нервозность ко всему процессу замены диска. Всегда есть шанс, что понадобится livecd или доступ к консоли сервера.
После замены диска не забываем установить загрузчик на новый диск
/dev/sda
:# dpkg-reconfigure grub-pc
Обязательно убедитесь, что ошибок нет. Если есть, сразу их решайте, не откладывайте на потом.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mdadm
4👍287👎4
Когда собирал заметку про различные варианты рисования схем, в том числе на основе текстового описания, наткнулся на интересный и полезный проект kroki.io. Не стал его там упоминать, чтобы в одну кучу всё не сваливать. Решил написать отдельно.
Это open source проект, который есть в редакции self-managed, то есть можно развернуть у себя. Он объединяет в себе все доступные библиотеки open source движков для рисования графиков из текстового описания. На сайте есть форма, где можно выбрать из выпадающего списка желаемый движок диаграмм, посмотреть пример текстового описания и тут же графическое отображение.
Если вы подбираете себе подобный инструмент для рисования схем, то можете очень быстро выбрать и попробовать то, что вам понравится больше всего. Кто-то прям неслабо заморочился и объединил в одном месте 27 доступных движков, в том числе Mermaid, GraphViz, Excalidraw и другие.
Я, кстати, именно тут впервые увидел, что Excalidraw, оказывается, тоже может рисовать схемы на основе текстового описания. Изначально думал, что это только графический редактор. Язык у него не сказать, что простой. Немного посмотрел представленные примеры. Стало понятно, почему Mermaid такой популярный. С ним реально проще работать, чем с другими. Синтаксис наиболее простой и интуитивный.
На сайте kroki.io есть небольшая шпаргалка в виде pdf с картинками, где представлены различные форматы визуализаций и движки, с помощью которых они нарисованы. Можно быстро прикинуть, что вам больше всего подойдёт. Примеры:
◽️Схема сети - NwDiag
◽️Детали сетевого пакета - PacketDiag
◽️Схемы стоек - RackDiag
◽️Диаграммы из блоков - BlockDiag, Ditaa
◽️Столбчатая диаграмма - Vega-lite
и т.д.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#схемы
Это open source проект, который есть в редакции self-managed, то есть можно развернуть у себя. Он объединяет в себе все доступные библиотеки open source движков для рисования графиков из текстового описания. На сайте есть форма, где можно выбрать из выпадающего списка желаемый движок диаграмм, посмотреть пример текстового описания и тут же графическое отображение.
Если вы подбираете себе подобный инструмент для рисования схем, то можете очень быстро выбрать и попробовать то, что вам понравится больше всего. Кто-то прям неслабо заморочился и объединил в одном месте 27 доступных движков, в том числе Mermaid, GraphViz, Excalidraw и другие.
Я, кстати, именно тут впервые увидел, что Excalidraw, оказывается, тоже может рисовать схемы на основе текстового описания. Изначально думал, что это только графический редактор. Язык у него не сказать, что простой. Немного посмотрел представленные примеры. Стало понятно, почему Mermaid такой популярный. С ним реально проще работать, чем с другими. Синтаксис наиболее простой и интуитивный.
На сайте kroki.io есть небольшая шпаргалка в виде pdf с картинками, где представлены различные форматы визуализаций и движки, с помощью которых они нарисованы. Можно быстро прикинуть, что вам больше всего подойдёт. Примеры:
◽️Схема сети - NwDiag
◽️Детали сетевого пакета - PacketDiag
◽️Схемы стоек - RackDiag
◽️Диаграммы из блоков - BlockDiag, Ditaa
◽️Столбчатая диаграмма - Vega-lite
и т.д.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#схемы
1👍143👎5
Шпаргалка на тему создания LVM Raid. Создаём RAID1.
Проверяем:
Создаём файловую систему и монтируем:
Смотрим, что в итоге получилось:
Скопируем туда что-нибудь, дождёмся полной синхронизации и удалим один из дисков.
Диск отключил. Проверяю данные, всё на месте. То есть LV работает как и прежде. Проверяю статус:
Вижу, что одно устройство в статусе [unknown]. Добавляю в систему новый диск. Не тот же самый, что я отключил.
Вижу, что он подключился на
Удаляем вывалившийся диск:
Проверяем:
Устройства в статусе [unknown] больше нет. Добавляем в наш LV новый диск:
На все вопросы отвечаем утвердительно. Смотрим результат и наблюдаем за синхронизацией:
Пошла синхронизация, данные все на месте. Замена прошла без остановки системы. Диски убирал и добавлял наживую. В целом, ничего сложного. Вполне понятный и логичный набор команд. Один раз проверил, записал и воспроизвёл в случае выхода из строя диска.
Из особенностей LVM Raid - LV можно конвертировать налету в разные уровни рейдов, добавлять к ним диски. Можно из raid1 сделать raid5, добавить туда диски. Не думаю, что на практике это будет оправданно. А вот превратить raid1 в raid10 видится полезным. Было 2 диска, добавил ещё 2 и получил raid10. Для этого надо добавить 2 диска в VG и сконвертировать LV. Прямой конвертации из raid1 в raid10 нет. Нужно сначала сконвертировать в raid5, добавить туда 2 диска, дождаться синхронизации и сконвертировать в raid10:
На выходе получил из RAID1 ⇨ RAID10 без остановки и потери данных. Я по всем этим командам получал подсказки в консоли. Там и по размеру подсказки были, и по тому, что финальная конвертация проходит в 2 этапа, и что сначала надо в raid5_n сконвертировать.
Если делать с нуля RAID10, то команда простая. Сначала добавляем 4 одинаковых диска в VG, потом создаём LV:
А теперь ради чего всё это затевалось. LVM Raid умеет вести контроль целостности файлов на основе хэшей. Реализуется это на базе технологии DM Integrity. Включаем её во время создания LV:
Размер нужно будет вычислять опытным путём. Я сначала указал размер 100% и получил ошибку, что для моих 10G дисков нужно 150 MiB под метаданные. В итоге указал 9G.
Если в VG есть свободное место, то добавить raidintegrity можно к существующему тому:
При каждой операции чтения выполняется расчёт контрольной суммы файла. Если она не совпадает с сохранённой ранее, выполняется попытка восстановления файла из других копий в составе рейда.
Для каждого диска в составе LV с DM Integrity создаётся отдельный LV rimage для хранения метаданных. В нём можно посмотреть статистику по ошибкам:
Колонка IntegMismatches. Все события по DM Integrity будут в системном логе /var/log/syslog.
Всё, что я показал, подробно описано в руководстве по LVM от Red Hat.
#lvm #raid
# apt install lvm2
# pvcreate /dev/sdb /dev/sdc
# vgcreate vgroup /dev/sdb /dev/sdc
# lvcreate --type raid1 -l 100%FREE -n lvraid1 vgroup
Проверяем:
# lvs -o+segtype
Создаём файловую систему и монтируем:
# mkfs.ext4 /dev/vgroup/lvraid1
# mkdir /mnt/lvraid1
# mount /dev/vgroup/lvraid1 /mnt/lvraid1
Смотрим, что в итоге получилось:
# lsblk
Скопируем туда что-нибудь, дождёмся полной синхронизации и удалим один из дисков.
# cp -r /var/log/* /mnt/lvraid1/
Диск отключил. Проверяю данные, всё на месте. То есть LV работает как и прежде. Проверяю статус:
# lvs -a -o name,devices vgroup
Вижу, что одно устройство в статусе [unknown]. Добавляю в систему новый диск. Не тот же самый, что я отключил.
# lsblk
Вижу, что он подключился на
/dev/sdd
. Добавляю его в VG:# pvcreate /dev/sdd
# vgextend vgroup /dev/sdd
Удаляем вывалившийся диск:
# vgreduce --removemissing vgroup --force
Проверяем:
# lvs -a -o name,devices vgroup
Устройства в статусе [unknown] больше нет. Добавляем в наш LV новый диск:
# lvconvert --repair vgroup/lvraid1
# lvconvert -m1 vgroup/lvraid1 /dev/sdd
На все вопросы отвечаем утвердительно. Смотрим результат и наблюдаем за синхронизацией:
# lvs -a -o name,devices vgroup
# lvs -o+segtype
Пошла синхронизация, данные все на месте. Замена прошла без остановки системы. Диски убирал и добавлял наживую. В целом, ничего сложного. Вполне понятный и логичный набор команд. Один раз проверил, записал и воспроизвёл в случае выхода из строя диска.
Из особенностей LVM Raid - LV можно конвертировать налету в разные уровни рейдов, добавлять к ним диски. Можно из raid1 сделать raid5, добавить туда диски. Не думаю, что на практике это будет оправданно. А вот превратить raid1 в raid10 видится полезным. Было 2 диска, добавил ещё 2 и получил raid10. Для этого надо добавить 2 диска в VG и сконвертировать LV. Прямой конвертации из raid1 в raid10 нет. Нужно сначала сконвертировать в raid5, добавить туда 2 диска, дождаться синхронизации и сконвертировать в raid10:
# pvcreate /dev/sdc /dev/sde
# vgextend vgroup /dev/sdc /dev/sde
# lvconvert --type raid5_n vgroup/lvraid1
# lvresize -l5118 vgroup/lvraid1 # размер зависит от размера LV
# lvconvert --stripes 1 vgroup/lvraid1
# lvconvert --stripes 2 vgroup/lvraid1
# lvconvert --type raid10 vgroup/lvraid1
# lvconvert --type raid10 vgroup/lvraid1
На выходе получил из RAID1 ⇨ RAID10 без остановки и потери данных. Я по всем этим командам получал подсказки в консоли. Там и по размеру подсказки были, и по тому, что финальная конвертация проходит в 2 этапа, и что сначала надо в raid5_n сконвертировать.
Если делать с нуля RAID10, то команда простая. Сначала добавляем 4 одинаковых диска в VG, потом создаём LV:
# lvcreate --type raid10 -l 100%FREE -n lvraid10 vgroup
А теперь ради чего всё это затевалось. LVM Raid умеет вести контроль целостности файлов на основе хэшей. Реализуется это на базе технологии DM Integrity. Включаем её во время создания LV:
# lvcreate --type raid1 --raidintegrity y -L 9G -n lvraid1 vgroup
Размер нужно будет вычислять опытным путём. Я сначала указал размер 100% и получил ошибку, что для моих 10G дисков нужно 150 MiB под метаданные. В итоге указал 9G.
Если в VG есть свободное место, то добавить raidintegrity можно к существующему тому:
# lvconvert --raidintegrity y vgroup/lvraid1
При каждой операции чтения выполняется расчёт контрольной суммы файла. Если она не совпадает с сохранённой ранее, выполняется попытка восстановления файла из других копий в составе рейда.
Для каждого диска в составе LV с DM Integrity создаётся отдельный LV rimage для хранения метаданных. В нём можно посмотреть статистику по ошибкам:
# lvs -o+integritymismatches vgroup/lvraid1_rimage_0_imeta
Колонка IntegMismatches. Все события по DM Integrity будут в системном логе /var/log/syslog.
Всё, что я показал, подробно описано в руководстве по LVM от Red Hat.
#lvm #raid
2👍232👎3
Продолжу тему с LVM Raid, чтобы получить законченное решение, которое можно будет использовать в проде. Я хочу установить корень системы / на LVM Raid, чтобы в случае выхода из строя диска иметь полностью работающую систему.
Для этого взял виртуалку с Debian 12 и установил систему с ручным разбитием диска. Создал ровно один раздел /dev/sda1, на нём создал VG - vgroup и один LV - root на весь доступный объём. Больше не делал ничего. Раздел /boot не выносил отдельно. Всё только в корне. Grub уже давно умеет грузиться с LVM разделов.
Установил систему. Добавил туда ещё один диск
Пробую сконвертировать корневой раздел в RAID1:
Получаю ошибку:
Суть её в том, что при создании любого RAID необходимо создать отдельный малюсенький LV на 4 MiB для хранения метаданных массива. А я полностью весь VG во время установки отдал на LV root. Чтобы избежать этой ошибки, оставляйте во время установки немного места на VG.
Решить эту проблему не трудно. LV можно уменьшить вместе с ФС, если это ext4:
Команда сработает, только если раздел размонтирован. А у меня это корень системы, так что получил ошибку. Решение простое. Загрузился с SystemRescueCD и выполнил её там. Откусил кусочек от LV, теперь конвертирую в RAID1:
Всё проходит без ошибок. Загружаю систему, проверяю массив:
Всё в порядке, оба диска на месте. Ставлю загрузчик на второй диск sdb:
Теперь вынимаю первый диск sda, на который изначально ставилась система и перезагружаю её. Grub запускается со второго диска, а дальше вываливаюсь в initramfs. Система не грузится, пишет, что не видит диск
Находит VG vgroup, но ругается, что там нет sda. Логично, диск этот отключен. После этого выхожу из initramfs:
Так как LVM раздел активирован, грузится система со второго диска. То есть в целом всё в порядке. Система жива, загружается. Надо только разобраться с тем, чтобы initramfs автоматически активировал неактивный VG с raid1.
Как оказалось, проблема эта нередкая. Нашёл решение в интернете. Создаём файл
Пересобираем initramfs:
Перезагружаемся. Теперь загрузка работает нормально. Что с одним, что с двумя дисками.
Заменяем выключенный диск новым. Смотрим, какие диски есть в системе:
У меня с данными диск стал sda, новый sdb. Копирую на него разметку, добавляю в VG и LV с raid1:
Ставим загрузчик на новый диск:
Следим за синхронизацией:
Когда закончится, перезагружаем систему и убеждаемся, что всё работает.
Получилась готовая инструкция по установке системы на LVM Raid1 и по замене вышедшего из строя диска. В целом, всё примерно то же самое, что и в mdadm со своими нюансами. При случае попробую на каком-нибудь железном сервере вместо mdadm - LVM. На вид выглядит удобнее и функциональнее.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#lvm #raid
Для этого взял виртуалку с Debian 12 и установил систему с ручным разбитием диска. Создал ровно один раздел /dev/sda1, на нём создал VG - vgroup и один LV - root на весь доступный объём. Больше не делал ничего. Раздел /boot не выносил отдельно. Всё только в корне. Grub уже давно умеет грузиться с LVM разделов.
Установил систему. Добавил туда ещё один диск
/dev/sdb
. Скопировал на него разметку с sda и добавил его в VG:# sfdisk -d /dev/sda | sfdisk /dev/sdb
# pvcreate /dev/sdb1
# vgextend vgroup /dev/sdb1
Пробую сконвертировать корневой раздел в RAID1:
# lvconvert --type raid1 -m 1 vgroup/root
Получаю ошибку:
Insufficient free space: 1 extents needed, but only 0 available
Суть её в том, что при создании любого RAID необходимо создать отдельный малюсенький LV на 4 MiB для хранения метаданных массива. А я полностью весь VG во время установки отдал на LV root. Чтобы избежать этой ошибки, оставляйте во время установки немного места на VG.
Решить эту проблему не трудно. LV можно уменьшить вместе с ФС, если это ext4:
# lvreduce -l -1 --resizefs /dev/vgroup/root
Команда сработает, только если раздел размонтирован. А у меня это корень системы, так что получил ошибку. Решение простое. Загрузился с SystemRescueCD и выполнил её там. Откусил кусочек от LV, теперь конвертирую в RAID1:
# lvconvert --type raid1 -m 1 vgroup/root
Всё проходит без ошибок. Загружаю систему, проверяю массив:
# lvs -o+segtype
# lvs -a -o name,devices vgroup
Всё в порядке, оба диска на месте. Ставлю загрузчик на второй диск sdb:
# dpkg-reconfigure grub-pc
Теперь вынимаю первый диск sda, на который изначально ставилась система и перезагружаю её. Grub запускается со второго диска, а дальше вываливаюсь в initramfs. Система не грузится, пишет, что не видит диск
/dev/mapper/vgroup-root
. В консоли initramfs ввожу команду на активацию всех lvm томов:# vgchange -ay
Находит VG vgroup, но ругается, что там нет sda. Логично, диск этот отключен. После этого выхожу из initramfs:
# exit
Так как LVM раздел активирован, грузится система со второго диска. То есть в целом всё в порядке. Система жива, загружается. Надо только разобраться с тем, чтобы initramfs автоматически активировал неактивный VG с raid1.
Как оказалось, проблема эта нередкая. Нашёл решение в интернете. Создаём файл
/etc/initramfs-tools/scripts/local-top/forcelvm
следующего содержания: #!/bin/sh
PREREQ=""
prereqs()
{
echo "$PREREQ"
}
case $1 in
prereqs)
prereqs
exit 0
;;
esac
. /scripts/functions
lvm vgchange -ay
Пересобираем initramfs:
# chmod +x /etc/initramfs-tools/scripts/local-top/forcelvm
# update-initramfs -u -k all
Перезагружаемся. Теперь загрузка работает нормально. Что с одним, что с двумя дисками.
Заменяем выключенный диск новым. Смотрим, какие диски есть в системе:
# lsblk
У меня с данными диск стал sda, новый sdb. Копирую на него разметку, добавляю в VG и LV с raid1:
# sfdisk -d /dev/sda | sfdisk /dev/sdb
# pvcreate /dev/sdb1
# vgextend vgroup /dev/sdb1
# vgreduce --removemissing vgroup --force
# lvconvert --repair vgroup/root
# lvconvert -m1 vgroup/root /dev/sdb1
Ставим загрузчик на новый диск:
# dpkg-reconfigure grub-pc
Следим за синхронизацией:
# watch lvs -a
Когда закончится, перезагружаем систему и убеждаемся, что всё работает.
Получилась готовая инструкция по установке системы на LVM Raid1 и по замене вышедшего из строя диска. В целом, всё примерно то же самое, что и в mdadm со своими нюансами. При случае попробую на каком-нибудь железном сервере вместо mdadm - LVM. На вид выглядит удобнее и функциональнее.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#lvm #raid
3👍227👎4
В недавнем цикле статей по LVM в комментариях всплывали вопросы так называемого Bit Rot или битового гниения. Это когда на носитель записан бит 1 или 0, а со временем по разным причинам он поменял своё значение. В конечном счёте эти изменения ведут к тому, что нужный файл хоть и нормально прочитается, но окажется "битым". Причём подвержены этим ошибкам все типы устройств хранения - от лент и CD до современных SSD. Я проверял свои старые записанные CD диски. Многие из них хоть и прочитались, но часть данных была безвозвратно утеряна или повреждена.
Защита от этого явления начинается с того, что данные у вас должны храниться в нескольких экземплярах. Если экземпляр один, то даже если вы узнаете о том, что файл побился, вам это никак не поможет.
Проще всего следить за целостностью файлов с помощью подсчёта контрольных сумм по тем или иным алгоритмам (CRC, MD5, SHA1 и т.д.) Есть много бесплатного софта, который автоматически может это выполнять и сравнивать по расписанию. В Linux такой софт обычно используется для контроля за системными файлами, чтобы определять несанкционированное изменение. Пример - Afick, Tripwire. Если у вас лежат файлы, с ними никто не работает, но изменилась контрольная сумма, значит возникли проблемы. Необходимо то же самое проверить на другом хранилище этих же файлов и если там контрольная сумма не менялась, значит тот файл оригинальный и стоит его восстановить из этой копии.
Некоторые файловые системы выполняют такие проверки в автоматическом режиме. Это заложено в их архитектуру. Пример - ZFS, Btrfs, ReiserFS, Ceph. Все эти файловые системы могут не только контролировать изменения, но и выполнять автоматическое восстановление повреждённых файлов, если хранилища на их основе собраны с избыточностью данных. То есть каждый файл хранится как минимум в двух или более копиях, для каждой из которых посчитана и сохранена контрольная сумма.
Важно понимать, что подобный контроль - не бесплатная операция. Она занимает системные ресурсы, как процессора, так и диска. И чем больше нагрузка на диск, тем больше ресурсов нужно. Перечисленные выше ФС обладают не только функциональностью контроля хэшей, но и многими другими, которые не обязательно будут нужны, но ресурсы они потребляют. Плюс, в них могут быть свои ошибки с вероятностью возникновения выше, чем Bit Rot. И стоит не забывать, что даже если вы возьмёте хранилище с ZFS или Ceph с контролем целостности файлов, это не освобождает вас от хранения этих же файлов где-то ещё.
Есть и другой механизм защиты файлов в Linux на основе контроля целостности - DM-integrity. С его помощью можно блочное устройство превратить в устройство с контролем целостности. А дальше с ним можно работать как с обычным диском - создавать разделы, тома Mdadm или Lvm. В случае нарушения целостности файла такое устройство будет возвращать Input/output error. Mdadm или LVM будут пытаться автоматически восстановить файл из копии, если хранилище обладает избыточностью данных, то есть собран рейд соответствующего уровня.
Таким образом мне не понятны претензии к Mdadm, Lvm или обычным файловым системам типа Ext4 или Xfs. Следить за целостностью файлов - не их задача. Где-то это будет слишком накладно, а где-то вообще не нужно. Если вам это необходимо, возьмите отдельный инструмент. В основном это актуально для долговременных хранилищ с холодными архивами.
☝️ Самая надёжная защита от Bit Rot - множественные копии. И тут очень важно соблюдать один принцип. Делать копию надо не от копии, а от оригинала данных. У вас есть исходное хранилище с данными, где они регулярно меняются. С него вы снимаете первый бэкап. Второй бэкап для другого хранилища надо снимать не с первого бэкапа, а тоже с исходного сервера. Иначе вы на все зависимые сервера принесёте битые файлы с первого бэкапа.
❓Для меня остался открытым другой вопрос. А как вообще понять, что у нас в хранилище файлы исправны, откроются и прочитаются? Как проверить изначальный источник правды для всех остальных копий?
#backup
Защита от этого явления начинается с того, что данные у вас должны храниться в нескольких экземплярах. Если экземпляр один, то даже если вы узнаете о том, что файл побился, вам это никак не поможет.
Проще всего следить за целостностью файлов с помощью подсчёта контрольных сумм по тем или иным алгоритмам (CRC, MD5, SHA1 и т.д.) Есть много бесплатного софта, который автоматически может это выполнять и сравнивать по расписанию. В Linux такой софт обычно используется для контроля за системными файлами, чтобы определять несанкционированное изменение. Пример - Afick, Tripwire. Если у вас лежат файлы, с ними никто не работает, но изменилась контрольная сумма, значит возникли проблемы. Необходимо то же самое проверить на другом хранилище этих же файлов и если там контрольная сумма не менялась, значит тот файл оригинальный и стоит его восстановить из этой копии.
Некоторые файловые системы выполняют такие проверки в автоматическом режиме. Это заложено в их архитектуру. Пример - ZFS, Btrfs, ReiserFS, Ceph. Все эти файловые системы могут не только контролировать изменения, но и выполнять автоматическое восстановление повреждённых файлов, если хранилища на их основе собраны с избыточностью данных. То есть каждый файл хранится как минимум в двух или более копиях, для каждой из которых посчитана и сохранена контрольная сумма.
Важно понимать, что подобный контроль - не бесплатная операция. Она занимает системные ресурсы, как процессора, так и диска. И чем больше нагрузка на диск, тем больше ресурсов нужно. Перечисленные выше ФС обладают не только функциональностью контроля хэшей, но и многими другими, которые не обязательно будут нужны, но ресурсы они потребляют. Плюс, в них могут быть свои ошибки с вероятностью возникновения выше, чем Bit Rot. И стоит не забывать, что даже если вы возьмёте хранилище с ZFS или Ceph с контролем целостности файлов, это не освобождает вас от хранения этих же файлов где-то ещё.
Есть и другой механизм защиты файлов в Linux на основе контроля целостности - DM-integrity. С его помощью можно блочное устройство превратить в устройство с контролем целостности. А дальше с ним можно работать как с обычным диском - создавать разделы, тома Mdadm или Lvm. В случае нарушения целостности файла такое устройство будет возвращать Input/output error. Mdadm или LVM будут пытаться автоматически восстановить файл из копии, если хранилище обладает избыточностью данных, то есть собран рейд соответствующего уровня.
Таким образом мне не понятны претензии к Mdadm, Lvm или обычным файловым системам типа Ext4 или Xfs. Следить за целостностью файлов - не их задача. Где-то это будет слишком накладно, а где-то вообще не нужно. Если вам это необходимо, возьмите отдельный инструмент. В основном это актуально для долговременных хранилищ с холодными архивами.
☝️ Самая надёжная защита от Bit Rot - множественные копии. И тут очень важно соблюдать один принцип. Делать копию надо не от копии, а от оригинала данных. У вас есть исходное хранилище с данными, где они регулярно меняются. С него вы снимаете первый бэкап. Второй бэкап для другого хранилища надо снимать не с первого бэкапа, а тоже с исходного сервера. Иначе вы на все зависимые сервера принесёте битые файлы с первого бэкапа.
❓Для меня остался открытым другой вопрос. А как вообще понять, что у нас в хранилище файлы исправны, откроются и прочитаются? Как проверить изначальный источник правды для всех остальных копий?
#backup
👍107👎5
Давно не занимался настройкой времени на серверах. Сейчас в Debian по умолчанию запущена служба systemd-timesyncd. Там либо стандартные дебиановские сервера указаны, типа
А тут один внешний сервер стал в мониторинге мигать проблемами с синхронизацией. Просмотрел логи, увидел ошибку:
Почему-то иногда подвисают соединения и синхронизация не происходит. Решил для начала просто поменять набор серверов. Конфигурация timesyncd хранится в файле
И уже в него добавляем свои параметры. В данном случае я добавил несколько основных и один резервный сервер:
Перечитываем конфигурацию служб и перезапускаем timesyncd:
Проверяем общие настройки времени:
И конкретно статус синхронизации:
Видно, что он взял первый сервер из списка, который мы указали.
Посмотреть логи службы можно так:
☝️ Дам одну подсказу, если у вас вообще не синхронизируется время, нет соединения с внешними серверами. Такие соединения очень часто блокируют сами провайдеры, предоставляя свои внутренние сервера времени. Это делают специально, потому что протокол NTP, как и DNS очень часто используют для усиления DDOS атак. Так что если у вас не синхронизируется время на сервере с внешними источниками, задайте сразу вопрос провайдеру. Сэкономите кучу времени.
Это ограничение можно обойти различными способами. Например, использовать htpdate (
Замена серверов мне, кстати, в итоге не помогла. Всё равно часть запросов подвисают с ошибкой
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#systemd
0.debian.pool.ntp.org
, либо из шаблона хостера какие-то его или другие публичные сервера. Обычно всё это сразу работает и трогать не обязательно. Я даже подзабыл и названия служб, и расположение конфигураций.А тут один внешний сервер стал в мониторинге мигать проблемами с синхронизацией. Просмотрел логи, увидел ошибку:
systemd-timesyncd[308]: Timed out waiting for reply from 195.90.182.235:123 (0.debian.pool.ntp.org)
Почему-то иногда подвисают соединения и синхронизация не происходит. Решил для начала просто поменять набор серверов. Конфигурация timesyncd хранится в файле
/etc/systemd/timesyncd.conf
. Но трогать его не рекомендуется, а как это обычно бывает с systemd, создать отдельный каталог с корректирующей конфигурацией:# mkdir /etc/systemd/timesyncd.conf.d
# touch /etc/systemd/timesyncd.conf.d/timesyncd.conf
И уже в него добавляем свои параметры. В данном случае я добавил несколько основных и один резервный сервер:
NTP=0.ru.pool.ntp.org 1.ru.pool.ntp.org 2.ru.pool.ntp.org 3.ru.pool.ntp.org
FallbackNTP=ntp0.vniiftri.ru
Перечитываем конфигурацию служб и перезапускаем timesyncd:
# systemd daemon-reload
# systemctl restart systemd-timesyncd
Проверяем общие настройки времени:
# timedatectl
И конкретно статус синхронизации:
# timedatectl timesync-status
Server: 51.250.35.68 (0.ru.pool.ntp.org)
................................
Видно, что он взял первый сервер из списка, который мы указали.
Посмотреть логи службы можно так:
# journalctl -u systemd-timesyncd
☝️ Дам одну подсказу, если у вас вообще не синхронизируется время, нет соединения с внешними серверами. Такие соединения очень часто блокируют сами провайдеры, предоставляя свои внутренние сервера времени. Это делают специально, потому что протокол NTP, как и DNS очень часто используют для усиления DDOS атак. Так что если у вас не синхронизируется время на сервере с внешними источниками, задайте сразу вопрос провайдеру. Сэкономите кучу времени.
Это ограничение можно обойти различными способами. Например, использовать htpdate (
apt install htpdate
), которая берёт точное время по протоколу HTTP.Замена серверов мне, кстати, в итоге не помогла. Всё равно часть запросов подвисают с ошибкой
Timed out waiting for reply
. Случается это без какой-то системы, но время в итоге всё равно синхронизируется. Не знаю точно, с чем связано. Думаю, что это особенность пула pool.ntp.org. Надо использовать какие-то конкретные адреса.❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#systemd
4👍173👎4
Давно думал, что надо бы переходить на какие-то отечественные публичные серверы NTP и DNS. Идёт размежевание с западными странами и только вопрос времени, когда занавес окончательно опустится. Решение, судя по всему, уже принято и сейчас шаг за шагом прорабатывают технические моменты.
Я обычно для NTP использую сервера из pool.ntp.org, а для DNS - сервера Яндекса - 77.88.8.1 и 77.88.8.8. Откровенно говоря, я компанию Яндекс недолюбливаю по многим причинам. Сейчас не хочется это обсуждать, но по возможности стараюсь не использовать их сервисы, если есть альтернативы не хуже.
Вчера в комментариях один подписчик подсказал, что в крупных отечественных организациях идёт рекомендация на использование публичных сервисов от известной компании MSK-IX. Это компания - крупнейшая в стране точка обмена трафиком со своими дата-центрами и каналами связи. Думаю, это разумно и обоснованно. Вот их NTP сервер:
MSK-IX NTP server относится к высшему уровню точности (Stratum One Time Servers) в иерархической системе часовых уровней. В качестве эталонного сигнала времени используется сигнал глобальных спутниковых систем навигации ГЛОНАСС.
MSK-IX NTP Server реализован в виде группировки серверов, размещенных в Москве, Санкт-Петербурге, Екатеринбурге и Новосибирске. Применение сетевой технологии anycast обеспечивает высокую надежность и быстрый отклик системы на всей территории страны.
Я бы к нему в список добавил ещё один от ВНИИФТРИ:
Вот список DNS серверов:
Реплики сервера установлены в Москве и Санкт-Петербурге. Благодаря использованию технологий IP-anycast и кэширования пользовательских запросов, DNS-запросы пользователей направляются к ближайшей реплике по кратчайшему сетевому маршруту и обрабатываются с максимальной скоростью. Кроме того, применение технологии IP-anycast обеспечивает резервирование службы, повышает устойчивость к сетевым атакам и локальным авариям в сети Интернет.
Я себе сохранил эти сервера и теперь буду в настраиваемых системах использовать их.
#dns #ntp
Я обычно для NTP использую сервера из pool.ntp.org, а для DNS - сервера Яндекса - 77.88.8.1 и 77.88.8.8. Откровенно говоря, я компанию Яндекс недолюбливаю по многим причинам. Сейчас не хочется это обсуждать, но по возможности стараюсь не использовать их сервисы, если есть альтернативы не хуже.
Вчера в комментариях один подписчик подсказал, что в крупных отечественных организациях идёт рекомендация на использование публичных сервисов от известной компании MSK-IX. Это компания - крупнейшая в стране точка обмена трафиком со своими дата-центрами и каналами связи. Думаю, это разумно и обоснованно. Вот их NTP сервер:
ntp.msk-ix.ru
MSK-IX NTP server относится к высшему уровню точности (Stratum One Time Servers) в иерархической системе часовых уровней. В качестве эталонного сигнала времени используется сигнал глобальных спутниковых систем навигации ГЛОНАСС.
MSK-IX NTP Server реализован в виде группировки серверов, размещенных в Москве, Санкт-Петербурге, Екатеринбурге и Новосибирске. Применение сетевой технологии anycast обеспечивает высокую надежность и быстрый отклик системы на всей территории страны.
Я бы к нему в список добавил ещё один от ВНИИФТРИ:
ntp1.vniiftri.ru
Вот список DNS серверов:
dns.msk-ix.ru 62.76.76.62
dns2.msk-ix.ru 62.76.62.76
Реплики сервера установлены в Москве и Санкт-Петербурге. Благодаря использованию технологий IP-anycast и кэширования пользовательских запросов, DNS-запросы пользователей направляются к ближайшей реплике по кратчайшему сетевому маршруту и обрабатываются с максимальной скоростью. Кроме того, применение технологии IP-anycast обеспечивает резервирование службы, повышает устойчивость к сетевым атакам и локальным авариям в сети Интернет.
Я себе сохранил эти сервера и теперь буду в настраиваемых системах использовать их.
#dns #ntp
👍246👎25
В одной из старых заметок, где я обсуждал выбор рабочего ноутбука, поднимал вопрос док-станции. Я непременно хотел ноут с её поддержкой. На что получил много комментариев на тему того, что старые доки уже устарели и сейчас полно разнообразных от дешёвых до дорогих с разъёмом Type-C или Thunderbolt.
Я тогда не повёлся на это и купил ноут с обычной док-станцией, как и прошлые. К ней был отдельный блок питания повышенной мощности и со своим разъёмом. К ноуту он не подходил. В целом и не надо, так как он тяжёлый и использовался стационарно с док-станцией. Вот этот блок питания со временем перестал работать.
Я решил, что наверное уже старею, не принимаю новые современные и удобные технологии. Не стал покупать новый БП, а купил простенькие доки в разъём Type-C. Купил сразу два - домой и в офис.
Пользуюсь уже давно, несколько месяцев. Могу точно сказать, что старые здоровые док-станции намного удобнее, чем эти маленькие.
1️⃣ Во-первых, док станция чётко резервирует место на столе под ноут, которое больше ничем не занимается. Пришёл - поставил.
2️⃣ Во-вторых, док станция лучше организует подключение проводов. Она стационарная, тяжёлая, стоит в одном месте, провода не болтаются.
3️⃣ В-третьих, вставить ноут в док-станцию удобнее и быстрее, чем воткнуть этот маленький разъёмчик, который ещё и разбалтывается от ежедневных подключений. Плюс, отдельно ещё и питание подключаешь. Надо обязательно глазами посмотреть, куда тыкать эти провода, чтобы попасть в разъёмы. В док ноут встаёт вслепую. Не надо никуда целиться.
В общем, пользоваться можно, но классические док-станции во всю ширину ноутбуков всё равно удобнее. Следующий ноут буду так же с нормальной док-станцией покупать.
Если никогда не пользовались док-станцией, рекомендую попробовать. Актуально, когда ноут постоянно перемещается между стационарными рабочими местами с монитором, мышкой, клавиатурой и ethernet кабелем.
Ниже мои картинки. Старый док лежит просто так, достал для фото. Обычно он более аккуратно и удобно стоит, провода сразу под стол уходят.
#железо
Я тогда не повёлся на это и купил ноут с обычной док-станцией, как и прошлые. К ней был отдельный блок питания повышенной мощности и со своим разъёмом. К ноуту он не подходил. В целом и не надо, так как он тяжёлый и использовался стационарно с док-станцией. Вот этот блок питания со временем перестал работать.
Я решил, что наверное уже старею, не принимаю новые современные и удобные технологии. Не стал покупать новый БП, а купил простенькие доки в разъём Type-C. Купил сразу два - домой и в офис.
Пользуюсь уже давно, несколько месяцев. Могу точно сказать, что старые здоровые док-станции намного удобнее, чем эти маленькие.
В общем, пользоваться можно, но классические док-станции во всю ширину ноутбуков всё равно удобнее. Следующий ноут буду так же с нормальной док-станцией покупать.
Если никогда не пользовались док-станцией, рекомендую попробовать. Актуально, когда ноут постоянно перемещается между стационарными рабочими местами с монитором, мышкой, клавиатурой и ethernet кабелем.
Ниже мои картинки. Старый док лежит просто так, достал для фото. Обычно он более аккуратно и удобно стоит, провода сразу под стол уходят.
#железо
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍103👎29
В заметках про Bit Rot, которое приводит к повреждению файлов при долговременном хранении, не хватало информации о том, как вообще можно смоделировать ситуацию, чтобы проверить настроенное хранилище.
Воздействовать на физическом уровне на устройства - задача нетривиальная. Но мне кажется, что можно действовать по-другому и получить схожий результат. Показываю по шагам свой эксперимент.
1️⃣ Для ускорения проведения экспериментов предлагаю всё делать на маленьких разделах диска. Покажу на примере mdadm raid1:
2️⃣ Заполняем весь раздел файлом:
Команда остановится с ошибкой, как только на диске закончится место.
3️⃣ Вычисляем хэш файла:
4️⃣ Запишем что-нибудь напрямую на блочное устройство. Чтобы точно попасть в созданный файл, я и сделал его во весь объём раздела.
Записали 1 блок размером 10 байт, отступив от начала 10 МБ или 100 МБ. Не помню точно, считается этот отступ в байтах или в размере блока.
5️⃣ Ещё раз проверяем хэш:
На удивление, он остался тем же. Я ожидал, что изменится.
6️⃣ Запускаем проверку целостности данных в массиве и когда закончится, смотрим результат:
У нас 128 несинхронизированных секторов. Точную причину проблем не посмотреть, но мы в данном случае знаем, что причина в том, что мы напрямую изменили часть данных.
7️⃣ Запускаем исправление ошибок:
Ждём по логу ядра окончание ремонта и смотрим ещё раз на количество ошибок:
Проверяем исходный файл:
Хэш не поменялся.
Я проводил несколько подобных экспериментов, меняя разные участки на блочном устройстве. Не всегда один repair приводил к исчезновению ошибок синхронизации, но после 2-х, 3-х раз они пропадали. И хэш файла всё время был один и тот же. Но если я через dd писал напрямую в md0:
То хэш неизменно менялся. Этот способ изменения файлов реально их меняет, хэш становится другим.
То же самое пробовал делать с массивом с включённым dm-integrity. Как и ожидается, массив получает ошибку хэша в определённом секторе:
А вот дальше я сталкивался в разных экспериментах с разным результатом. Это может не приводить ни к каким ошибкам, возникающие на некоторое время ошибки синхронизации через несколько минут сами пропадают без запуска принудительной синхронизации через repair. Хэш файла не меняется.
Но один раз я получил ошибку чтения файла, а в логе было следующее:
И так далее по кругу. То есть сектор был определён как повреждённый. Шла попытка взять его с другого диска, но там он тоже был с изменённой checksum. Не знаю, с чем это связано. Как-будто мое изменение успело синхронизироваться на второй диск и блока с правильным хэшем просто не осталось. В итоге файл вообще перестал открываться (Input/output error), его хэш нельзя было посмотреть.
Методику для тестов я вам показал. Можете помучать свои хранилища перед внедрением в эксплуатацию.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mdadm #backup
Воздействовать на физическом уровне на устройства - задача нетривиальная. Но мне кажется, что можно действовать по-другому и получить схожий результат. Показываю по шагам свой эксперимент.
# apt-get install mdadm
# mdadm --create /dev/md0 -l 1 -n 2 /dev/sdb /dev/sdс
# mkfs.ext4 /dev/md0
# mount /dev/md0 /mnt
# dd if=/dev/urandom of=/mnt/testfile
Команда остановится с ошибкой, как только на диске закончится место.
# md5sum /mnt/testfile
4b1f1e62670849f08c975e9cab8cfd10 /mnt/testfile
# dd if=/dev/urandom of=/dev/sdb seek=10000000 count=1 bs=10 conv=notrunc
Записали 1 блок размером 10 байт, отступив от начала 10 МБ или 100 МБ. Не помню точно, считается этот отступ в байтах или в размере блока.
# md5sum /mnt/testfile
4b1f1e62670849f08c975e9cab8cfd10 /mnt/testfile
На удивление, он остался тем же. Я ожидал, что изменится.
# echo 'check' > /sys/block/md0/md/sync_action
# cat /sys/block/md0/md/mismatch_cnt
128
У нас 128 несинхронизированных секторов. Точную причину проблем не посмотреть, но мы в данном случае знаем, что причина в том, что мы напрямую изменили часть данных.
# echo 'repair' > /sys/block/md0/md/sync_action
Ждём по логу ядра окончание ремонта и смотрим ещё раз на количество ошибок:
# cat /sys/block/md0/md/mismatch_cnt
0
Проверяем исходный файл:
# md5sum /mnt/testfile
4b1f1e62670849f08c975e9cab8cfd10 /mnt/testfile
Хэш не поменялся.
Я проводил несколько подобных экспериментов, меняя разные участки на блочном устройстве. Не всегда один repair приводил к исчезновению ошибок синхронизации, но после 2-х, 3-х раз они пропадали. И хэш файла всё время был один и тот же. Но если я через dd писал напрямую в md0:
# dd if=/dev/urandom of=/dev/md0 seek=10000000 count=1 bs=10 conv=notrunc
То хэш неизменно менялся. Этот способ изменения файлов реально их меняет, хэш становится другим.
То же самое пробовал делать с массивом с включённым dm-integrity. Как и ожидается, массив получает ошибку хэша в определённом секторе:
device-mapper: integrity: dm-0: Checksum failed at sector 0xe88b8
А вот дальше я сталкивался в разных экспериментах с разным результатом. Это может не приводить ни к каким ошибкам, возникающие на некоторое время ошибки синхронизации через несколько минут сами пропадают без запуска принудительной синхронизации через repair. Хэш файла не меняется.
Но один раз я получил ошибку чтения файла, а в логе было следующее:
device-mapper: integrity: dm-0: Checksum failed at sector 0x2b4f8
md/raid1:md0: dm-0: rescheduling sector 175144
device-mapper: integrity: dm-0: Checksum failed at sector 0x2b4f8
device-mapper: integrity: dm-1: Checksum failed at sector 0x2b4f8
md/raid1:md0: redirecting sector 175144 to other mirror: dm-1
device-mapper: integrity: dm-1: Checksum failed at sector 0x2b4f8
И так далее по кругу. То есть сектор был определён как повреждённый. Шла попытка взять его с другого диска, но там он тоже был с изменённой checksum. Не знаю, с чем это связано. Как-будто мое изменение успело синхронизироваться на второй диск и блока с правильным хэшем просто не осталось. В итоге файл вообще перестал открываться (Input/output error), его хэш нельзя было посмотреть.
Методику для тестов я вам показал. Можете помучать свои хранилища перед внедрением в эксплуатацию.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mdadm #backup
Please open Telegram to view this post
VIEW IN TELEGRAM
👍120👎6
Картинка из раздела Sysadminhumor на Reddit, хотя вроде бы и не смешно. Заставила задуматься над тем, что всё в этом мире ходит по кругу. Сначала были мейнфреймы, их я не застал. Потом появились персональные компьютеры, с которыми я в 2000-х начинал работал. Далее стали появляться терминальные серверы, мне даже довелось повнедрять бездисковые станции, перемещаемые профили и рабочие места на терминальных серверах.
Потом всё это поехало в виртуальные машины, а они, соответственно, в облака. Со временем с виртуальными рабочими местами как-то подуспокоились. Все, кто хотел, попробовали или внедрили VDI. Уже не вижу, чтобы эту технологию как-то активно продвигали. В основном все работают за своими компьютерами и ноутбуками, но уже в веб приложениях. Хотя на днях ходил в Сбербанк. Там оператор меня полностью обслужил, используя только планшет. Обратил внимание, что экран монитора у него был выключен. Либо уснул, либо он компьютер не включает за ненадобностью.
И вот теперь технологический виток сделал круг и облачные технологии обратно переезжают на сервера в виде Azure Local. То есть это тот же облачный Azure, который можно развернуть у себя локально. Судя по всему рост облачных сервисов прекратился и Microsoft начали наполнять рынок опять локальными решениями, чтобы занять его.
Вот сама статья в Forbes:
⇨ Azure Local Brings The Power Of Cloud To On-Premises And Edge
Там одна вода. Судя по всему, это реклама.
Интересно, Azure Local можно будет запустить в виртуальных машинах на Azure или AWS? И будет ли аналог от AWS и GCP?
#разное
Потом всё это поехало в виртуальные машины, а они, соответственно, в облака. Со временем с виртуальными рабочими местами как-то подуспокоились. Все, кто хотел, попробовали или внедрили VDI. Уже не вижу, чтобы эту технологию как-то активно продвигали. В основном все работают за своими компьютерами и ноутбуками, но уже в веб приложениях. Хотя на днях ходил в Сбербанк. Там оператор меня полностью обслужил, используя только планшет. Обратил внимание, что экран монитора у него был выключен. Либо уснул, либо он компьютер не включает за ненадобностью.
И вот теперь технологический виток сделал круг и облачные технологии обратно переезжают на сервера в виде Azure Local. То есть это тот же облачный Azure, который можно развернуть у себя локально. Судя по всему рост облачных сервисов прекратился и Microsoft начали наполнять рынок опять локальными решениями, чтобы занять его.
Вот сама статья в Forbes:
⇨ Azure Local Brings The Power Of Cloud To On-Premises And Edge
Там одна вода. Судя по всему, это реклама.
Интересно, Azure Local можно будет запустить в виртуальных машинах на Azure или AWS? И будет ли аналог от AWS и GCP?
#разное
👍56👎3
Существует очень простой способ объединить несколько различных дисков в единый логический раздел. Речь идёт именно о логическом объединении. То есть у вас могут быть два абсолютно любых хранилища, смонтированных в разные разделы. Например,
Сразу поясню, где это может пригодиться.
🔹Видеосервер с записями камер. Можно объединить разнородные хранилища в единую точку монтирования и указать её в настройках видеосервера.
🔹У меня не раз бывали ситуации, когда мне нужно было объединить в единый раздел несколько raid1 или raid10. Для этого я их объединял с помощью LVM. Бывает так, что у вас есть сервер с 4-мя дисками, но при этом они одинаковые парами, например 2 по 2TB и 2 по 3TB. Вы делаете 2 зеркала mdadm, а потом поверх него пускаете LVM. Получаете 5TB в одном разделе. В некоторых случаях удобнее и безопаснее обойтись без LVM, а сделать логическое объединение.
🔹Сервер со статикой или кэшом, где не нужна отказоустойчивость. Можно просто расширять отдельными дисками, а веб серверу отдать единую точку монтирования, где будут видны все файлы.
🔹Сервер для бэкапов, где допустимо логическое объединение дисков. А для бэкапов это часто допустимо.
Работает всё это на базе mergerfs. Покажу сразу на практике. Допустим, у нас есть 2 диска sda и sdb по 20G. Создаём на них по одному разделу и монтируем в систему:
Создали, примонтировали, убедились, что всё работает. Устанавливаем mergerfs и создаём общий диск:
Я добавил к параметрам по умолчанию следующие:
◽️allow_other - позволяет пользователям видеть файловую систему, иначе увидит только root.
◽️category.create=mfs - политика распределения файлов по дискам в зависимости от наличия там свободного места, где больше места, туда пишем.
◽️moveonenospc=true - при сбое записи если, к примеру, на устройстве не осталось места или превышена квота, файл будет записан в другое место.
◽️minfreespace=1G - если на устройстве меньше 1G места, туда больше не пишем.
С такими настройками если записывать на общее хранилище одинаковые по размеру файлы, то они будут по очереди записываться на разные диски. Их можно будет напрямую увидеть в
В репозитории описаны все настройки и возможные политики записи. Они могут быть применены к каждому диску индивидуально. Например, какое-то хранилище может быть подключено только для чтения, на какое-то перестаём писать, когда там остаётся свободно 10G, записываем данные последовательно, заполняя диски по очереди и т.д.
Общее хранилище можно подключать через fstab или systemd-mount. Примеры есть в репозитории.
Полезный прикладной софт. Работает просто, решает конкретную задачу.
⇨ 🌐 Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#fileserver
/mnt/sda
и /mnt/sdb
. Вы можете объединить их в единый диск в новой точке монтирования /mnt/sdab
. Объём двух разделов суммируется в новой точке монтирования. При этом файлы будут писаться в зависимости от настроек в оба исходных диска, а /mnt/sdab
просто будет единое место, к которому можно обращаться для работы с файлами.Сразу поясню, где это может пригодиться.
🔹Видеосервер с записями камер. Можно объединить разнородные хранилища в единую точку монтирования и указать её в настройках видеосервера.
🔹У меня не раз бывали ситуации, когда мне нужно было объединить в единый раздел несколько raid1 или raid10. Для этого я их объединял с помощью LVM. Бывает так, что у вас есть сервер с 4-мя дисками, но при этом они одинаковые парами, например 2 по 2TB и 2 по 3TB. Вы делаете 2 зеркала mdadm, а потом поверх него пускаете LVM. Получаете 5TB в одном разделе. В некоторых случаях удобнее и безопаснее обойтись без LVM, а сделать логическое объединение.
🔹Сервер со статикой или кэшом, где не нужна отказоустойчивость. Можно просто расширять отдельными дисками, а веб серверу отдать единую точку монтирования, где будут видны все файлы.
🔹Сервер для бэкапов, где допустимо логическое объединение дисков. А для бэкапов это часто допустимо.
Работает всё это на базе mergerfs. Покажу сразу на практике. Допустим, у нас есть 2 диска sda и sdb по 20G. Создаём на них по одному разделу и монтируем в систему:
# cfdisk /dev/sda
# cfdisk /dev/sdb
# lsblk
# mkfs.ext4 /dev/sda1
# mkfs.ext4 /dev/sdb1
# mkdir /mnt/sda
# mkdir /mnt/sdb
# mount /dev/sda1 /mnt/sda
# mount /dev/sdb1 /mnt/sdb
# df -h
/dev/sda1 20G 24K 19G 1% /mnt/sda1
/dev/sdb1 20G 24K 19G 1% /mnt/sdb1
Создали, примонтировали, убедились, что всё работает. Устанавливаем mergerfs и создаём общий диск:
# apt install mergerfs
# mkdir /mnt/sdbc
# mergerfs -o defaults,allow_other,category.create=mfs,moveonenospc=true,minfreespace=1G /mnt/sda1:/mnt/sdb1 /mnt/sdab
# df -h | grep sdab
a1:b1 40G 48K 38G 1% /mnt/sdab
Я добавил к параметрам по умолчанию следующие:
◽️allow_other - позволяет пользователям видеть файловую систему, иначе увидит только root.
◽️category.create=mfs - политика распределения файлов по дискам в зависимости от наличия там свободного места, где больше места, туда пишем.
◽️moveonenospc=true - при сбое записи если, к примеру, на устройстве не осталось места или превышена квота, файл будет записан в другое место.
◽️minfreespace=1G - если на устройстве меньше 1G места, туда больше не пишем.
С такими настройками если записывать на общее хранилище одинаковые по размеру файлы, то они будут по очереди записываться на разные диски. Их можно будет напрямую увидеть в
/mnt/sda1
и /mnt/sdb1
. # dd if=/dev/zero of=/mnt/sdab/tempfile1 bs=1M count=1000
# dd if=/dev/zero of=/mnt/sdab/tempfile2 bs=1M count=1000
# ls /mnt/sdab
tempfile1 tempfile2
# ls /mnt/sda1
tempfile2
# ls /mnt/sdb1
tempfile1
В репозитории описаны все настройки и возможные политики записи. Они могут быть применены к каждому диску индивидуально. Например, какое-то хранилище может быть подключено только для чтения, на какое-то перестаём писать, когда там остаётся свободно 10G, записываем данные последовательно, заполняя диски по очереди и т.д.
Общее хранилище можно подключать через fstab или systemd-mount. Примеры есть в репозитории.
Полезный прикладной софт. Работает просто, решает конкретную задачу.
⇨ 🌐 Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#fileserver
1👍199👎3
Заметил на днях, что давно мне обновления в Windows 11 не прилетали. Зашёл в раздел обновлений, выполнил проверку. Ничего нового нет. Обратил внимание - висит предупреждение, что моя версия системы больше не поддерживается. Удивился. Винда лицензионная, никаких твиков, остановок служб не делал. Даже Defender в этой системе не отключал.
Версия системы - 22H2. Оказывается, у неё кончилась поддержка в октябре. Я особо не слежу за всеми этими движухами и с обновлениями не тороплюсь. Мне от системы надо, чтобы она просто работала. И желательно не беспокоила различными изменениями. Привык, что в рамках одной версии все сервис паки и обновления прилетают автоматически, когда приходит время. А тут почему-то этого не случилось, и я оказался с неподдерживаемой версией.
Полез в интернет. Оказывается, таких как я полно. По какой-то причине не всем приходят обновления на новые версии в рамках Windows 11. Вариантов решить эту проблему и обновиться много. Не буду все перечислять. Там и создание установочного диска, и правка локальных политик, и изменение настроек обновления.
Я сразу выбрал, как мне показалось, самый простой и надёжный вариант. Скачал Windows11InstallationAssistant.exe с сайта Microsoft и запустил. Какое-то время он качал файлы, а потом начал очень длительное обновление. Заставил меня понервничать. В какой-то момент обновление минут 30 висело на стадии 31% и не двигалось. Я уже прикидывал, как буду восстанавливать систему. Предварительно, само собой, сделал полный бэкап с помощью Veeam Agent for Windows. Я им постоянно пользуюсь, он бесплатный.
В итоге всё обошлось. Примерно за пару часов с момента запуска ассистента система полностью обновилась. И сразу начала отчёты в центр слать. Без перерыва шуршат два процесса:
- Windows Hello Security Process
- Служба индексации
Индексация через несколько часов прекратилась, а вот первая до сих пор грузит процессор и вынуждает гудеть вентиляторы ноута. Предстоит разбирательство с этой новой проблемой. Как говорится: "Не было печали, апдейтов накачали". Вот только не качать их варианта не было.
#windows
Версия системы - 22H2. Оказывается, у неё кончилась поддержка в октябре. Я особо не слежу за всеми этими движухами и с обновлениями не тороплюсь. Мне от системы надо, чтобы она просто работала. И желательно не беспокоила различными изменениями. Привык, что в рамках одной версии все сервис паки и обновления прилетают автоматически, когда приходит время. А тут почему-то этого не случилось, и я оказался с неподдерживаемой версией.
Полез в интернет. Оказывается, таких как я полно. По какой-то причине не всем приходят обновления на новые версии в рамках Windows 11. Вариантов решить эту проблему и обновиться много. Не буду все перечислять. Там и создание установочного диска, и правка локальных политик, и изменение настроек обновления.
Я сразу выбрал, как мне показалось, самый простой и надёжный вариант. Скачал Windows11InstallationAssistant.exe с сайта Microsoft и запустил. Какое-то время он качал файлы, а потом начал очень длительное обновление. Заставил меня понервничать. В какой-то момент обновление минут 30 висело на стадии 31% и не двигалось. Я уже прикидывал, как буду восстанавливать систему. Предварительно, само собой, сделал полный бэкап с помощью Veeam Agent for Windows. Я им постоянно пользуюсь, он бесплатный.
В итоге всё обошлось. Примерно за пару часов с момента запуска ассистента система полностью обновилась. И сразу начала отчёты в центр слать. Без перерыва шуршат два процесса:
- Windows Hello Security Process
- Служба индексации
Индексация через несколько часов прекратилась, а вот первая до сих пор грузит процессор и вынуждает гудеть вентиляторы ноута. Предстоит разбирательство с этой новой проблемой. Как говорится: "Не было печали, апдейтов накачали". Вот только не качать их варианта не было.
#windows
👍92👎17