69. Азы обслуживания системы.

"Уж сколько раз твердили миру..."

(C) Крылов.

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

Мониторинг.

Наверняка среднестатистическому пользователю хочется чтобы его система работала по принципу "сделал и забыл". Т.е. настроил что-то один раз и дальше там происходит какая-то магия, благодаря которой всё само работает. В идеале - да, но в реальном мире случаются разные поломки оборудования, изменения в программах и компонентах влияющие на работу других вещей, и т.д. Поэтому крайне важно периодически поглядывать на системный журнал (лог) и проверять есть ли в нём какие-то сообщения об ошибках или предупреждения. Это относится как к самой системе управления умным домом (например Home Assistant), так и платформе и инфраструктуре на которой она работает (например Proxmox).

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

Для Proxmox же, в первую очередь крайне важно настроить оповещения по электронной почте. О том, как это сделать - ранее уже была дана подробная инструкция.

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

Ну и так же стоит не забывать про периодическую проверку логов.

Мониторинг позволяет знать что происходит то или иное событие и своевременно на него среагировать.

Бэкапы.

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

Про это есть отдельная подробная статья. Подытожить её можно следующим образом:

1. Бэкапов много не бывает. Необходимо создавать копию хотя бы раз в сутки и хранить хотя бы 3-5 последних копии. Есть случаи когда люди делают бэкапы каждые 2-3 часа.

2. Бэкап должен создаваться на отдельный физический диск, не на тот же, на котором находятся виртуалки или стоит система.

3. Крайне рекомендуется копировать созданный бэкап на ещё один физический носитель (другой компьютер, файловый сервер, флэшку)

4. Включить оповещения (см. выше о мониторинге). Совсем не обязательно настраивать уведомления об успешно выполненном резервном копировании, они рано или поздно "замылят глаз". Гораздо важнее знать если что-то пошло не так. Однако для проверки работы, стоит включить разово все типы уведомлений, чтобы убедиться что в автономном режиме всё работает как задумывалось.

5. Опционально можно включить оповещения об успешном выполнении пункта 3.

6. Важно иметь копию в другом географическом месте, не в том где находится сам сервер или диски с копией. Имея рабочее подключение к Интернет это сделать не сложно. Не обязательно (хотя и можно) копировать в облако весь образ виртуальной машины, даже копия конфигурации (как в этой статье) поможет сэкономить время на развёртывании новой системы, в случае если другие возможности не будут доступны.

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

7. Параноидальный режим. Использование Raid массивов параллельно с бэкапами. Требует специфичного оборудования, делает всю систему гораздо дороже, но и кратно повышает надёжность и отказоустойчивость.

8. Хардкор режим. Использование кластера. Это когда 2 и более гипервизора синхронизируют виртуалки между собой. Если один вдруг падает, то автоматически включается та же виртуалка на втором. Время простоя без виртуалки - несколько секунд. Пока проходят восстановительные работы на первом хосте, все системы работают со второго. Потом синхронизируются обратно.

9. Параноидальный хардкор. Каждый хост в кластере имеет 2 рэйд массива дисков (для системы и для бэкапов).

10. Свой ЦОД (центр обработки данных - datacenter). Кластер, каждый хост в котором содержит отдельный рэйд массив для системы, отдельный для виртуальных машин. Так же присутствует отдельный физический сервер резервного копирования (само собой тоже на рэйде). Сами бэкапы складываются  на сетевое хранилище тоже построенное на рэйде с дублирующим копированием на носитель подключенной к другой электрической линии. Все устройства работают через дублирующие  ЮПСы (ИБП).

Резервное питание.

Раз уж были упомянуты Источники Бесперебойного Питания, то и мимо этой темы нельзя спокойно пройти мимо.

Всё что касается этого вопроса описано в статье на нашем сайте.

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

Нейминг и адресация.

Т.к. домашняя сеть вся в наших руках, то кому как не нам управлять раздачей и присвоением адресов внутри неё?

Важно поделить имеющиеся устройства на типы и раздавать адреса соответственно их типу. 

Только в качестве примера:

• все физические проводные устройства - с 10 по 19 в четвёртом октете.
• все физические беспроводные устройства не имеющие отношения к умному дому: с 20 по 29 в четвёртом октете.
• все виртуальные машины: с 30 по 39 в четвёртом октете.
• все контейнеры  с 50 по 59 в четвёртом октете.

Об октетах можно узнать из статьи о домашних сетях.

Т.к. все контейнеры и виртуальные машины тоже управляются тем же человеком, то и их номера тоже можно привести в порядок (с помощью клонирования или восстановления в новую виртуалку из бэкапа).

Например:

• все виртуальные машины: с 300 номера.
• шаблоны контейнеров - с 400.
• все контейнеры  с 500 номера.
• шаблоны виртуалок - с 600.

Это как минимум упрощает идентификацию и поиск устройств в сети по их IP-адресам. Во-вторых, это позволяет создавать логические группы устройств по их функциям и назначениям.

Очень важно выделить пул хотя бы в 50 адресов для свободного использования.

Итог.

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

В готовых системах (Tuya, Xiaomi Home, Ewelink, Ikea и т.д.) всё это выполняют специалисты управляющие теми самыми облачными серверами, где-то далеко. Можно конечно довериться им и использовать готовые решения, не ломая себе голову лишними проблемами и знаниями. Но будет ли ваш умный дом при таком управлении именно вашим умным домом?