У устройств 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

📑 От метрик к прогнозированию: как бизнес и ИИ меняют мониторинг

Сегодня мониторинг — больше чем техническая задача. Этот инструмент напрямую влияет на успех бизнеса. Но как не потеряться в потоке данных и предсказать сбои до их появления?

Приглашаем на вебинар, где ответим на этот вопрос и покажем, как выглядит новый стандарт наблюдаемости.

📅 9 июля | 11:00 (по Мск)

В программе вебинара

⏺ Эволюция инструментов: расскажем, почему старые подходы не работают и как выбрать современное решение.
⏺ Бизнес-драйверы: обсудим, как бизнес-задачи определяют тренды развития мониторинга.
⏺ Эпоха ИИ: покажем, как ИИ помогает автоматизировать процессы и анализировать данные.
⏺ «Астра Мониторинг»: продемонстрируем решение, которое позволяет не просто видеть, а предвидеть.
Приходите, чтобы узнать, как сделать ваши ИТ-системы прозрачными, управляемыми и надежными.

🔗 Зарегистрироваться на вебинар

Реклама, ООО "РусБИТех-Астра", ИНН 7726388700

Среди бесплатных серверов с реализацией протокола 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://xn--r1a.website/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 😩

#топ

Десять CLI, SDK и Terraform-провайдеров — из одной OpenAPI-спецификации?

21 июля в 17:00 в новом выпуске реалити-проекта «Создавая облако» от MWS Cloud Platform технический руководитель платформы Дмитрий Новиков покажет, как устроена внутренняя кухня автоматизации облака.

Что будет в эфире:

• тотальный dogfooding: почему внутренние команды работают теми же инструментами, что и клиенты;
• как устроен декларативный API: манифест → reconcile → desired state;
• пять инструментов автоматизации — UI, CLI, Terraform, Golang SDK и Packer, — зачем нужен каждый;
• как один кодогенератор из единой спецификации кормит десять артефактов;
• почему Packer остаётся осознанным исключением и пишется руками.

Выпуск будет интересен backend-разработчикам, DevOps- и SRE-инженерам, platform-инженерам, техническим лидам и архитекторам.

➡️ Зарегистрироваться

Небольшой практический совет для тех, кто собирает или планирует собирать логи 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 😩

#мысли