🎓Собеседование сисадмина. Выпуск #11: Распределенные хранилища (SDS, Ceph, Longhorn)

Привет, коллеги! Продолжаем наш марафон по технологиям 2026 года. В прошлом выпуске мы похоронили классические гипервизоры, но остался вопрос: где хранить данные этих тысяч виртуалок и контейнеров, если мы отказались от проприетарных СХД за десятки миллионов рублей?

В мире отечественных ARM-кластеров и жесткого импортозамещения мы перешли на SDS (Software-Defined Storage). Теперь хранилище — это не дорогая коробка с логотипом вендора, а софт, который объединяет диски обычных серверов в единое пространство.

Разберем три вопроса, которые покажут, понимаешь ли ты, как не потерять данные, когда в стойке одновременно «вылетят» два сервера.

❓ Вопрос 1: «В чем принципиальная разница между классическим SAN/NAS и Software-Defined Storage (SDS)?»

❌ Ответ новичка: «SDS — это когда много дисков в сети. Это дешевле, чем покупать готовый сервер от вендора».

✅ Ответ инженера:

Главное — абстракция. В SDS интеллект (контроллер, кэширование, дедупликация) перенесен из специализированного железа в софт, работающий на обычных узлах.

1. Масштабируемость: В SAN мы ограничены портами контроллера. В SDS (Ceph, Longhorn) мы просто добавляем новый ARM-узел в кластер, и емкость растет линейно.
2. Отказоустойчивость: В SDS данные размазаны по узлам. Выход из строя целого сервера для нас — штатная ситуация, а не катастрофа.
3. Vendor Lock-in: В 2026-м это критично. Мы не зависим от поставок конкретных запчастей, мы используем любые доступные NVMe накопители.

❓ Вопрос 2: «Что такое Replication Factor и Erasure Coding? Когда что выбирать?»

❌ Ответ новичка: «Репликация — это копии, а Erasure Coding — это как RAID, только сложнее».

✅ Ответ инженера:

Это два способа обеспечить выживание данных.

1. Replication (обычно x3): Мы храним три полные копии каждого блока на разных узлах.
Плюс: Максимальная производительность (чтение очень быстрое) и простота восстановления.
Минус: Огромные траты места (платим за 3 ТБ, получаем 1 ТБ полезного объема). Выбираем для БД и горячих виртуалках.

2. Erasure Coding (EC): Данные разбиваются на фрагменты + контрольные суммы (как в RAID 5/6), которые раскидываются по узлам.
Плюс: Экономия места (коэффициент может быть 1.5 вместо 3).
Минус: Высокая нагрузка на CPU и сеть при записи и восстановлении. Выбираем в 2026-м для холодных данных, архивов и бэкапов.

❓ Вопрос 3: «Как вы будете бороться с проблемой Split-brain в распределенном хранилище?»

❌ Ответ новичка: «Надо настроить мониторинг и быстро чинить сеть».

✅ Ответ инженера:

Мониторинг не лечит, он констатирует смерть. Проблема Split-brain (когда две части кластера думают, что они главные) решается на уровне кворума.

1. Нечетное количество узлов: Минимум 3 (лучше 5) мониторов/контроллеров.
2. Алгоритмы консенсуса: Использование Paxos или Raft. Система не позволит записать данные, если большинство узлов не подтвердило операцию.
3. Fencing: Принудительная изоляция (отключение питания или портов) узла, который ведет себя неадекватно, чтобы он не портил данные в общем сторадже.

---

Практический пример: Проверка здоровья Ceph-кластера

В 2026-м ты не кликаешь в веб-морде, ты смотришь статус через CLI, чтобы понимать реальную нагрузку на OSD (диски):

# Проверить общий статус здоровья
ceph health detail

# Посмотреть распределение данных и нагрузку на диски
ceph osd df tree

# Если видишь статус DEGRADED — проверяем, не идет ли сейчас Recovery (восстановление)
ceph -s

Вывод: Админ, который умеет настраивать Ceph или Longhorn на ARM-серверах, в 2026 году — это элита. Ты больше не зависишь от сервисных контрактов, ты сам строишь фундамент, на котором стоит весь бизнес.

Золотое правило: Данные стоят дороже железа. Всегда проверяй Recovery Traffic Limit, чтобы восстановление одного диска не «положило» всю сеть компании.

#собеседование_AF #sds #ceph #longhorn #storage #nvme #admin_future