Небольшая заметка, которая у кого-то вызовет непонимание, как автор мог такого не знать. По факту не знал за столько лет работы с различной техникой.

Некоторое время назад я купил домой ИБП Ippon Kirpich 1050. Нормальный бесперебойник для дома. Рабочий комп минут 20 от него проработал. Мне столько не надо, я сразу выключаю, как только свет пропал, оставил себе попроще старый. Подключил к Кирпичу кучу всего - NAS, сервак с PVE, свитч с камерами, роутер, оптический модем. Всё нормально.

Последнее время дома основательно перетряхиваю всё своё IT хозяйство. Под это дело решил таки приобрести сервер под условно продовые свои потребности - immich, frigate, zabbix, loki, opencode и некоторые другие виртуалки, в том числе тестовые. Мне есть, куда его поставить, и где он не будет мешать своим шумом. Взял б.у. платформу Supermicro на DDR4. Набил её памятью, sas sff дисками, поставил контроллер для проброса дисков напрямую в систему.

Платформа старая, комплектующие все серверные, поэтому их можно относительно дёшево купить на Авито, что я и сделал. К примеру, планка памяти 32GB DDR4 ECC REG стоит 9300, а диск HDD SAS 2,5 1,2TB hgst 10K - 3900. Купил комплектухи по потребностям. Мне хватило 128 GB памяти.

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

Подумал, что с ИБП проблемы. Поменял батарею. У меня была новая запасная. картина та же. Что самое интересное, софт для диагностики и управления стоит на сервере, нормально видит ИБП. Заходишь туда, нажимаешь тест батареи, сервак вырубается, тест не проходит.

Расстроился, подумал, что брак. Попробовал обратно вернуть его на прошлую нагрузку. На удивление, там всё нормально. Тут то я и заподозрил, что чего-то не понимаю. Пошёл разбираться.

Оказывается, серверные блоки питания отличаются от десктопных (кто бы мог подумать 🙄) тем, что там применяется технология с активным корректором коэффициента мощности (Active PFC). У этой технологии свои требования к выходному напряжению, а Kirpich - линейно-интерактивный ИБП, который этим требованиям не соответствует. Для этого нужен онлайн ИБП.

То, что ИБП отличаются, я знаю. Но вся моя практика такова, что в серверную всегда покупались серверные ИБП, а для десктопов - десктопные. И они никогда не пересекались. Впервые это пересечение произошло у меня дома и я узнал про эту несовместимость. На работе мне в голову не приходило питать сервера от интерактивных ИБП.

В общем, пришлось в очередной раз раскошелиться и заказать онлайн ИБП. Взял самый дешман за 14 000, поэтому не пишу, какой именно. Сначала получу, попробую, если всё будет ок, то расскажу. Уже и так поистратился на это всё, жаль стало денег на нормальный онлайн ИБП. Они от 30 000 стоят.

"Век живи, век учись".

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#железо

У устройств Synology есть особый тип дисковых пулов под названием Synology Hybrid RAID (SHR). С его помощью можно создавать отказоустойчивое хранилище из дисков разного объёма. Сами они описывают его вот так:

Synology Hybrid RAID (SHR) - это автоматизированная система управления RAID от компании Synology. SHR позволяет пользователям создавать гибкие решения для хранения данных с оптимизированной емкостью и производительностью.

SHR основана на системе управления Linux RAID и предназначена для ускорения и упрощения развертывания системы хранения по сравнению с классическими системами RAID. Это делает его особенно подходящим для пользователей, которые не знакомы с технологией RAID.

Мне всегда было интересно посмотреть реализацию. Покажу на простом примере, как это работает. Допустим, у вас есть 3 диска 2ТБ и 3 диска 3ТБ. Вы хотите сделать хранилище, которое без потери данных переживёт отказ одного или двух дисков. В классических моделях RAID у вас только один вариант - отрезать от дисков 3ТБ по 1ТБ, превратив их в 2ТБ диски и собрать RAID 5 или 6 из всех дисков.

Synology предлагает ничего не отрезать и использовать весь объём дисков. Я недавно настраивал Xpenology, поэтому смог посмотреть, как они это делают. Там на самом деле одновременно всё просто и всё сложно. Synology точно так же отрезает от дисков в 3ТБ куски по 1ТБ и создаёт RAID5 с помощью всё того же MDADM, который уже лет 10 хоронят, но он живее всех живых, потому что это максимально простая и надёжная софтовая реализация отказоустойчивых хранилищ.

Из оставшихся трёх отрезков в 1ТБ от трехтерабайтных дисков опять же с помощью MDADM собирают отдельный RAID5 из трёх дисков. В итоге мы имеем:

▪️RAID5 из шести дисков с разделами по 2ТБ
▪️RAID5 из трёх дисков с разделами в 1ТБ

И потом оба эти раздела объединяются в общий Volume Group (VG) с помощью LVM. А дальше создаётся либо один логический том на всю ёмкость, либо несколько. Всё это делается через веб панель. От пользователя реализация скрыта. Он в конце сможет выбрать файловую систему: ext4 или btrfs.

Контроль целостности файлов реализуется через возможности btrfs. Что интересно, разработчики Synology не стали использовать возможности btrfs по созданию raid, а доверились проверенному mdadm.

Я многократно слышал мнение, что mdadm устарел и подлежит замене более современными решениями, потому что у него нет контроля целостности. Не согласен с этим мнением и неоднократно об этом писал и приводил примеры. Контроль за содержимым - не задача устройства хранения, коим является mdadm. Он решает ровно одну задачу - создание отказоустойчивых, надёжных массивов. А за файлами можно следить другими инструментами - btrfs, ceph, linux dm-integrity или множеством реализаций на уровне контроля за файлами.

Подход Synology не нов и не уникален. Я ещё лет 10 назад делал подобное на железном контроллере, который позволял делить диски. Точно так же отрезал куски от больших дисков и объединял их в отдельные массивы. Основной объём дисков объединял в RAID10 для горячих данных, а отрезанные куски в RAID1 для холодного хранения.

Посмотрев на всё это, не стал в Xpenology объединять разные диски. У меня как раз было 3 по 2ТБ и 4 по 3 ТБ. Сделал два пула, объединив одинаковые диски (на скрине внизу, как это выглядит на уровне системы). В целом, всё это вполне надёжно, но не знаю, насколько хорошо все ситуации обыграли инженеры Synology. Не хочется в случае ошибок получить проблемы на таком огромном пуле с разными дисками. Решил не усложнять.

Вообще, мне нравится Synology как раз тем, что ничего особо не выдумывает, а использует проверенные линуксовые решения. Да и под капотом там обычный Linux. У меня как-то были проблемы с одиночным диском, перестал определяться в Synology, слетела таблица разделов. Я без проблем подкцепил диск к обычной системе с Linux, восстановил таблицу и забрал оттуда данные. Писал об этом статью в своё время.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#fileserver

Среди бесплатных серверов с реализацией протокола S3 долгое время безоговорочным лидером был MinIO. Он был простой, функциональный, с открытым исходным кодом. Для базовых задач self-hosted размещения все брали его и не забивали себе голову. Разработчики сначала урезали возможности бесплатной версии, а потом и вовсе перестали её разрабатывать и поддерживать. И теперь однозначного лидера нет, и что выбирать - не понятно.

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

🔹Первое, что приходит на ум - Ceph. Это мощное, зрелое, кластерное решение от трёх узлов и до десятков, а возможно и сотен. Хотя можно и на один узел развернуть. Там есть в том числе S3, но сравнить его с MinIO язык не поворачивается. Это разного масштаба и архитектуры системы.

🔹SeaweedFS - относительно старый для этой ниши продукт. Я про него слышал ещё лет 5 назад как альтернативу MinIO. Он вполне стабильный и зрелый. По функциональности не уступает MinIO. Есть много статей с внедрением SeaweedFS в крупных компаниях, либо с его использованием как основы для своего самописного решения. Можно без особых опасений брать и пользоваться, но есть одно НО. Это фактически продукт одного человека. Будет ли кто-нибудь дальше поддерживать этот проект, если автору в какой-то момент всё это надоест - неизвестно.

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

🔹Garage - более зрелый продукт по сравнению с RustFS. Пишется небольшой французской компанией с 2020 года. Тоже, кстати, на Rust. Легко разворачивается, настраивается как для маленького проекта на одной ноде, так и в небольшой кластер из нескольких. Есть веб интерфейс для управления, оператор для кубера, поддерживается фактор репликации, сжатие, дедупликация. То есть выглядит всё это как простое стабильное решение с базовой функциональностью для этой задачи. Мне показалось это на текущий момент оптимальное решения для замены MinIO.

Отдельно отмечу то, что тоже рассматривал, но не стал включать в список, так как показалось не очень актуальным. Но может кому-то приглянётся:
- S3 на базе Vitastor.
- Zenko CloudServer, Vitastor его использует, про cloudserver я ранее писал заметку.
- s4core - свежий проект навайбкоденный одним человеком, по описанию всё красиво, на практике не понятно, как будет работать, отзывов не нашёл.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#s3

😑 Дешевле - не значит выгоднее. Почему выбор по цене в итоге обходится дороже?

Когда выбирают серверы, обычно сравнивают железо: ядра, память, диски, цена за стойку. Инструменты управления уходят на второй план — и зря. Именно они определяют, сколько часов админ потратит на обслуживание в ближайшие 3–5 лет.

✔️На сайте сравнили сервера Dell и Supermicro.

Спешим поделиться их отличиями в:
ℹ️ Прошивках и BIOS
ℹ️ Телеметрии и интеграции
ℹ️ Конфигах и масштабах
ℹ️ Безопасности

✨ Позаботьтесь о вашем сисадмине сегодня, чтобы он не уволился завтра

🖥 Полное сравнение с цифрами и таблицами — читайте у нас на сайте

Реклама. ООО "ИТЕЛОН". ИНН 7701527528. erid: 2W5zFJ7Xv4q

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

Капец, по вашей инструкции сбросил настройки на заводские и всё пинги не получаю от маршрутизатора! Спасибо за отличную статью и микротик говно для задротов с хвостиками, заваленными джинсами с кучей корманов и пивными животами! Маршрутизатор не советую, берите zyxel с keenetic os! Всё для людей сделано!

По-моему любой роутер после сброса настроек на заводские теряет в том числе и сетевые настройки. Это как бы база. Неужели в Зухеле по-другому?

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#юмор #mikrotik

🔝 ТОП постов за прошедший месяц июнь. Все самые популярные публикации по месяцам можно почитать со соответствующему хэштэгу #топ. Отдельно можно посмотреть ТОП за прошлые года: 2023 и 2024 и 2025.

Пользуясь случаем, хочу попросить проголосовать за мой канал, так как это открывает некоторые дополнительные возможности по настройке: https://t.me/boost/srv_admin.

В этот раз в топ по реакциям (отрицательным) попала рекламная публикация. Это вообще первый раз за всю историю ведения канала (9 лет). Обычно рекламу проматывают и не реагируют на неё. Для тех, кто не совсем понимает эту кухню немного поясню, как на деле выглядит публикация рекламы.

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

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

📌 Больше всего пересылок:
◽️5 полезных настроек Proxmox (323)
◽️PatchMon для контроля за обновлениями (225)
◽️Обновление сертификатов Microsoft в UEFI (218)
◽️Обновление BIOS в Supermicro (213)

📌 Больше всего комментариев:
◽️Реалии найма в IT (292)
◽️Let's Encrypt следует ссанкциям США (166)
◽️Переезд серверной и отказ оборудования (97)
◽️ExplorerPatcher для Windows 11 (88)

📌 Больше всего реакций:
◽️Проблемы с запуском KeePass (221)
◽️Помехи с сигналом в Ethernet от наводок 380В (216)
◽️Обновление BIOS в Supermicro (205)

📌 Больше всего просмотров:
◽️Прикол в настройке Asterisk (10260)
◽️Let's Encrypt следует ссанкциям США (10135)
◽️Настройка Fwknop (9115)

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#топ

Небольшой практический совет для тех, кто собирает или планирует собирать логи Docker контейнеров в Loki. У меня был подробный цикл заметок по этой теме:

1️⃣ Установка, настройка Loki, сбор логов Docker контейнеров
2️⃣ Сбор системных логов Linux (syslog и journald) с помощью Alloy
3️⃣ Сбор логов Postfix и пример создания дашборда для них
4️⃣ Сбор журналов Windows.
5️⃣ Приём логов Syslog с помощью Vector
6️⃣ Отключение сбора статистки в Alloy

Также есть общая статья со всеми этими темами. Мне нравится эта система. Я её сейчас постоянно использую. Скорее всего больше не буду настраивать ELK, так как для моих задач мне Loki хватает, хотя она и менее функциональная, но проще в настройке и меньше требует ресурсов.

Во время изучения Loki собирал логи с помощью встроенного плагина докер - grafana/loki-docker-driver. Он удобен в первую очередь тем, что можно в каждом конкретном контейнере указать, что логи отправляются в Loki. Примерно так:

  logging:
   driver: loki
   options:
    loki-url: "http://192.168.137.30:3100/loki/api/v1/push"
    loki-retries: 2
    loki-max-backoff: 800ms
    loki-timeout: 1s
    keep-file: "true"
    mode: "non-blocking"

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

Но у такого подхода есть существенные минусы, с которыми я столкнулся:

1️⃣ Сам по себе драйвер - отдельная сущность. И если в нём будут ошибки, то у вас не запустятся контейнеры, которые от него зависят. И я эти ошибки ловил. Не всегда и не везде, но иногда было так, что этот драйвер по какой-то причине не запускался. Причём быстро выяснить причину не удавалось. Просто не запускался автоматически loki.sock после перезагрузки хоста. Лечилось ручным запуском. Причина была не в том, что Loki недоступен.

2️⃣ За плагином надо отдельно следить и обновлять. Причём обновление требует перезапуска самой службы Docker со всеми вытекающими последствиями в виде остановки или перезапуска контейнеров в зависимости от их настроек. Это если у вас не включен параметр live-restore. С ним контейнеры не будут перезапускаться вместе со службой. По умолчанию этот параметр не активен. С ним есть свои нюансы.

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

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#docker #logs #loki #совет

Синхронизация двух разнесённых хранилищ с файлами - нетривиальная задача, особенно если они состоят из десятков и сотен тысяч файлов. Сделать копию данных и регулярно синхронизировать - полдела. Нужно ещё как-то их сравнивать, чтобы убедиться в том, что данные в обоих местах идентичны. Мало того, что при передаче данные могут повредиться, так они ещё и со временем могут протухать из-за bit rot (битовое гниение на хранилищах) или silent corruption (повреждения из-за памяти, контроллеров, неисправных кабелей и т.д.)

С bit rot я лично сталкивался, так что это не гипотетическая ситуация. Хотя в моём случае это не приводило к каким-то проблемам, так как протухали очень старые данные, которые по сути никому уже и не нужны, а хранятся просто так, на всякий случай. Но где-то это может быть критично.

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

Такой подход не страхует от повреждения файлов во время передачи. Хотя сетевые протоколы содержат собственные механизмы контроля целостности, файлы могут повредиться, например, из-за неисправной памяти, контроллеров или других аппаратных сбоев. Даже если ваше хранилище защищено от bit rot, гарантировать поступление точной копии файла оно не может. Нужны дополнительные проверки.

Rsync, как и некоторые другие подобные программы, могут сверять контрольные суммы файлов. Но это очень длительный процесс, если хранилище большое. В момент передачи данных делать это нецелесообразно. Процесс может растянуться на дни. Не так давно я в локальной сети сравнил два хранилища объёмом в 1ТБ, где хранятся ~100 тыс. файлов. У меня процесс длился в районе 20-ти часов.

Подсчитывать контрольные суммы для сравнения логичнее локально и отдельно от передачи, разнеся эти процессы по времени. Если синхронизация выполняется раз в день, то сравнение можно делать раз в неделю/месяц. Для этого есть много различных программ. Я недавно увидел анонс одной из них - precizer, поэтому и решил написать об этой теме. Ранее мне был знаком скрипт bitrot, который делает примерно то же самое, но не так изящно.

Precizer для максимального быстродействия написана на чистом Си, компилируется в одиночный бинарник, проста в использовании. Производительность в основном зависит от работы дисковой подсистемы, так как файлы приходится полностью читать. Обычно это узкое место. Результаты анализа файлов хранит в SQLite. Если её прервать, а потом запустить снова, она продолжит работу, не потеряв всё то, что сделала ранее. Это отличный инструмент для фоновой проверки хранилищ по расписанию.

Работает примерно так:

# precizer --progress --database=share1.db /mnt/share1
# precizer --progress --database=share2.db /mnt/share2
# precizer --compare share1.db share2.db

В базах share1.db и share2.db хранится относительный путь файла, его хэш SHA512 и метаданные (размер, ctime и mtime). Последующие запуски для обновления базы выполняются с ключом --update, чтобы заново не пересчитывать хэши к неизменившимся файлам.

Решений подобной задачи может быть несколько. Передача и сравнение файлов - только одно из них. Можно передавать снепшоты файловых систем, или систем хранения, если они это поддерживают. Например, снепшоты zfs или lvm и потом их сравнивать. Можно хранить данные в формате чанков, как это делает, к примеру, restic или borg и делать проверки на уровне чанков. Итоговое решение нужно выбирать по месту в зависимости от того, какая архитектура хранения и бэкапов используется. Уровень файлов имеет свои недостатки, но удобен, так как вы в случае чего сразу имеете живую копию данных, которую сможете использовать без преобразования или каких-то ещё дополнительных действий.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#backup

Смотрю иногда ютуб канал Будни сантехника. Не знаю зачем, просто нравится. Кое-что полезное узнал - как правильно наматывать фум ленту и сантехническую нить, как канализацию правильно делать и т.д. Живущим в частном доме эта информация не лишняя, особенно если у них всё на полипропилене 😁.

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

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

Я давно знаю эту свою проблему. Разучился отдыхать. Надо заново учиться. Всё время в делах, заботах, что-то делаю, придумываю, планирую и т.д. Это не сказать, что плохо, но уже крайность, от которой надо уходить обратно в сторону нормы. Как минимум для сохранения здоровья. Часто ночами засиживаюсь, настраивая что-то в своей серверной. Прикиньте, каким надо быть фанатом, чтобы весь день настраивать сервера на работе, а перед сном - у себя дома.

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

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#мысли

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

Для разгона решил закончить свою старую тему с ИБП, так как лично для меня она получилась поучительной. Напомню, для тех, кто не читал прошлую публикацию. Я подключил сервер, у которого блок питания с Active PFC к линейно-интерактивному ИБП. В итоге при переходе на батареи сервер аварийно выключался и не мог стартовать при работе от батарей, уходил в циклическую перезагрузку.

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

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

Я в итоге и купил (за 13700 р.) один из таких, практически самый дешёвый - FinePower MIX ONLINE 1000VA, он же DEXP MIX ONLINE 1000VA. Он же и под другими брендами продаётся, но внешний вид у них у всех один и тот же. Я его уже настроил, протестировал. Работает нормально. Выбрал именно его, потому что дешёвый, и потому что не увидел каких-то явно плохих отзывов. В целом у всех он работает нормально. Проблема лично у меня возникла с софтом под Linux. У меня не получилось его завести, хотя я видел отзывы, когда у людей получалось. В зависимости от бренда, под которым он продаётся, у него может быть разная прошивка и протокол обмена данными. У меня ни через NUT, ни через его родной софт под Linux, он не заработал.

Немного помучался и завёл всё через виртуальную машину на винде. У меня он всё равно к гипервизору подключен. Там софт нормально работает. Он тушит по SSH гипервизор. Мою супермикру этот ИБП держит в районе 15-20 минут. Если верить его дисплею, то нагрузка обычно ~150Вт. Для моих задач этого ИБП достаточно. Рекомендовать его не буду из-за кривого софта, но за эти деньги другой не купить. Плюс, он шумит вентилятором, но мне не критично, так как стоит в нежилом помещении. Если бы не этот вентилятор, то был бы отличный вариант для домашнего онлайн ИБП для компьютера под виндой.

В итоге сервер работает от этого онлайн ИБП, а остальные компьютеры - от линейно-интерактивных. И всё в порядке. То есть проблемы в явном виде с этим ИБП не было. Он просто не совместим с конкретным сервером, как и большинство его собратьев такого же типа.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#железо

Есть разные способы автоматической доставки необходимых пакетов софта на целевые сервера: ansible или аналоги, bash, в частности с помощью bashible, cloud-init, различные ci/cd системы со своими агентами. Во всех этих системах первое, что приходит в голову, сформировать список необходимых пакетов и передавать его на установку. В случае необходимости, список можно менять.

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

В зависимости от ситуации, можно использовать тот или иной подход. У каждого есть как свои плюсы, так и минусы. Например, если список пакетов хранится в ansible и часто меняется, придётся постоянно обновлять список в переменной и пушить эти изменения в репозиторий. Если они несущественны и не требуют отдельного учёта, проще менять мета-пакет, не затрагивая код ролей или плейбуков. Например, если вы ведёте набор софта для настройки рабочей станции на Linux. Там будет масса всего для установки. Удобно всё это завернуть в один мета-пакет workstation и менять именно его.

Мета-пакеты во всю представлены в стандартных репозиториях. Самый популярный мета-пакет - linux-image-amd64, который обновляет ядро. Посмотреть его состав можно так:

# apt show linux-image-amd64
.....
Description: Linux for 64-bit PCs (meta-package)
.....

Набор инструментов build-essential, оболочки gnome, xfce4, kde - это всё тоже мета-пакеты. Узнал о них совершенно случайно не так давно. Сколько лет настраиваю линуксы, всегда пакеты по одному ставил, храня списки в переменных.

Собрать свой мета-пакет очень просто. Покажу на примере мета пакета deb-base с набором программ, которые я обычно ставлю на все сервера:

# mkdir -p ~/deb-base/DEBIAN
# nano ~/deb-base/DEBIAN/control

Package: deb-base
Version: 1.0
Architecture: all
Maintainer: Vladimir <root@serveradmin.ru>
Depends: sudo, curl, wget, htop, rsync, unattended-upgrades, net-tools, lsof, iftop
Description: Base Debian server configuration

# dpkg-deb --build deb-base

Получил на выходе мета-пакет deb-base.deb, у которого в зависимостях sudo, curl, wget, htop, rsync, unattended-upgrades, net-tools, lsof, iftop. При установке мета-пакета они все будут установлены:

# apt install ./deb-base.deb

Причём эти пакеты устанавливаются по-отдельности, их можно как обычно посмотреть через dpkg:

# dpkg -l | grep iftop

В случае необходимости любой из установленных пакетов можно удалить как обычно через apt. Если изменить список пакетов и версию в файле control, пересобрать мета-пакет и запустить:

# apt upgrade ./deb-base.deb

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

Работают мета-пакеты просто и прозрачно, используя для создания встроенный в deb дистрибутивы менеджер пакетов dpkg. Есть и другие инструменты для этого, но этот проще всего.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#linux