| RAM |
В редких случаях может случаях может менять значение |
Использовать “серверную” ECC память с корректировкой ошибок |
Часто потребляет больше энергии, поддерживается серверными CPU типа Xeon и AMD Pro |
| HDD |
Выход диска из строя |
RAID контроллер, программный RAID, бэкапирование, кластерные ФС
Мониторинг SMART
Иметь запасной диск, который может или руками или автоматически добавляться в RAID массив в случае выхода из строя основного диска |
Часто используется либо MIRROR/RAID 10 с 2мя дисками в зеркале или RAID5,6/RAIDz с “размазанной” избыточностью
Надо понимать, что RAID это не серебряная пуля, выход из строя диска в массиве это все равно нештатная ситуация и массив будет в состоянии деградации с потенциальным падением производительности, а для RAID5/RAIDz1 выход второго диска полностью похоронит данные в массиве, поэтому считается, что если у вас HDD из одной серии и RAID 5 массив ушел в аварию, то надо бежать пересобирать массив, иначе, под повышенной нагрузкой начнут выходить из строя остальные диски |
| Аппаратный RAID |
Может использовать свои форматы и сигнаруты на дисках, другой RAID контроллер может не собрать массив от чужого контроллера |
Использовать популярные контроллеры или программный RAID |
На Ali есть куча контроллеров в IT прошивкой, которая пробрасывает все диски в сыром виде, а уже условный TrueNAS собирает из них программный RAID массив |
| Блок питания |
Выход из строя |
Серверные решения часто имеют 2 БП, подключаемые к 2м независимым линиям питания |
У меня был Barebone сервер с SFP БП, который грелся, гудел и выходил из строя по причине плохой схемотехники, после очередного ремонта выкинул и перевел питание на ноутбучные блоки питания, они тоже выходят из строя, но поменять быстрее |
| Материнская плата и компоненты |
Выход из строя компонентов |
Использовать серверные решения, с упором на надежность, если бытовые, то популярные варианты, которые можно легко заменить. Плата с распаяным ноутбучным процом или x99 подобные на зеоне являются не лучным решением |
Желательно не привязываться к железу, а если привязка нужна, то использовать виртуализацию (именно QEMU, а не LXC), например, тот же 1С сервер нормально переживает перенос виртуалки на другой хост, PVE имеет функционал маппинга устройств на разных хостах
Серверное железо надежное, конечно, но сервер, которому 20 лет все равно остается 20 летним сервером |
| Система охлаждения |
Мини ПК, особенно дешевые типа GMKTec G3 имеют ноутбучную систему охлаждения и не могут долго работать под нагрузкой |
Использовать серверные решения или нормальную дискретную систему охлаждения на mini ITX/ATX/E-ATX платах
Можно рассмотреть безвентиляторные варианты, но надо понимать, что мощность будет ограничена и дешевые системы могут не справляться с нагрузкой |
Миники сейчас очень популярны, но минус в системе охлаждения, с свои регулярно продуваю т.к. забиваются пылью, а воздухозаборник очень маленький
По безвентиляторным вариантм, сам взял себе на N4000 миник, но там производительность очень малая. На N100 есть вроде неплохие варианты, но я видел отзывы, что некоторые миники все равно перегреваются и через 20 минут отваливается сеть, народ колхозит сверку 120 вертушку |
| Виртруалки и сервисы |
Неправильное конфигурирование, падение при обновлении, смерть сервера, взлом и просто смерть виртуалки |
Бэкапирование |
Я для дома выработал следующие правила
1. Конфигурация находится в GIT, секреты в Vault, провижининг в Ansible, раскатываем и обновляем при помощи CI/CD
2. Бэкапируем виртуалку или контейнер на другой сервер, чтобы можно было восстановить образом
3. Внутри виртуалки пользовательские файлы бэкапируем отдельно, они занимают меньше места и надежней, т.к. бэкап работающей виртуалки не самая хорошая идея
4. Данные на NAS переносим на другой диск по типу холожного бэкапа с хранением диска на полке
5. Данные на ZFS NAS обмазываем снепшотами, тем самым защищаемся от случайного удаления или изменения
6. GIT и некоторые части NAS бэкапируем в облако, например, зеркалируем репозиториии на gitlab.com/github.com
7. TrueNAS или PBS в виртуалке проще восстановить из бэкапа, нежели, развернутые на хосте
8. Для оборудования или DIY решения или менеджеры конфигураций с бэкапом конфигов, для node-red проекты с git репозиторием |
| Система в целом |
Сервер упал и упали сервисы |
Кластеризация, поднимаем несколько инстансов сервиса на разных серверах, используем оркестрацию типа K8S, храним данные на стороннем SAN/NAS |
Несколько мелких серверов надежнее 1 мощного, в идеале иметь сервера без дисков для вычислительных ресурсов и отдельный SAN, который будет отдавать диски VM, но это дорого и SAN тоже может выйти из строя |
| Бэкап |
Потеря данных бэкапа |
Придерживаемся принципа 3-2-1 |
3 копии данных (основные плюс две резервные), хранение копий на 2 разных типах носителей (например, внутренний HDD и внешний SSD) и сохранение 1 копии данных за пределами основной площадки, например, в облаке |
| Железо |
Выход из строя с простоем на время замены |
В идеале, иметь N+1 или файловеринг, т.е. запасной БП, запасной роутер, запасную материнку, запасные диски |
Читать обзоры и отзывы по железу, в идеале иметь или прямую замену или какой-то вариант для того, чтобы переждать |
| Несколько систем |
Влияние одной системы на другую |
В идеале иметь резервирование мощностей или разделение систем |
Я пришел к тому, что критически важные сервисы должны быть на выделенном железе, путь в ввиде виртуалки, но выделенное железо, т.к.
1. Крутить роутер, менеджер паролей и т.д. рядом с тестовым CI/CD и сервисами не очень хорошая идея, например, у меня Home-Assistant c 4ГБ оперативки ловил OOM при сборке EspHome проекта, в итоге я ESPhome перенес на мини ПК, а сборка большого angular приложения может съест все ресурсы
2. В хоум лабе часто что-то меняется, на то она и хоум лаба, я считаю, что во время установки google coral или ковыряния видеокора не должны ломаться критически важные сервисы
3. Чем меньше зависимостей, тем лучше. У меня миник мониторингом, волтом, аутентификацией не имеет внешних дисков, не использует NAS, не имеет доп. оборудования |
| Система питания |
Выход из строя в случае потери питания или простая недоступность |
Использовать
1. ИБП
2. Централизованное питания, например, POE
3. Мини ИБП, например, что-то типа такого
4. RAID контроллеры со встроенными батареями |
Тоже важная тема, я стараюсь уйти от 100500 БП и перейти к единой слаботочной сети.
Идеальная схема:
1. БП в зеркале, на 24В
2. Батарейный lifepo4 ИБП
3. PDU или другой механизм мониторинга потребления
4. Питание устройств или от 24В если могут или через DC-DC преобразователи
5. ИБП на 220В для компьютера |
