Мой дом — моя крепость (Часть 2)

Продолжение

предыдущая часть (Часть 1)

Откуда ноги ростут…

Сегодня речь пойдет о серверах и их наполнении.

Сервер 1

В предыдущей части было упомянуто, что на первом сервере подняты три виртуальные машины и NFS сервер. В нем же установлены шесть двух терабайтных HDD для хранения всего подряд и два SSD в зеркале под систему. В качестве основной операционной системы используется Ubuntu 18.04 LTS. Используемая виртуализация QEMU-KVM . KVM (Kernel-based Virtual Machine) с гипервизором (VMM – Virtual Machine Manager). QEMU (Quick Emulator) – эмулятор различных устройств. Выбор очевиден — просто и доступно сразу из коробки в любом Linux дистрибутиве. Все физические сетевые соединения мостами соединенны с виртуальными машинами (VM в дальнейшем), а нативный Firewall блокирует все иные поползновения.

Первая VM это главный маршрутизатор. Операционная система — Mikrotik RouterOS.

Основной функционал:

• VLAN;
• DHCP для VLAN`ов ;
• DNS;
• Firewall, включая NAT, контроль «чужих» статических ip-адресов и массу других правил;
• Интеграция с Radius`ом;

Вторая VM — программная АТС на базе FusionPBX.

С появлением в доме АТС связанна отдельная история. Есть у меня очень близкий товарищ по сравнению с которым Остап Бендер (извините, ссылка на всякий случай, мало ли…), просто пацан. Так вот, как то раз он обратился ко мне с вопросом: «А можно сделать так, чтобы при звонке на мой мобильный телефон геолокация всегда показывала на то, что я нахожусь дома, вне зависимости от реального местонахождения?». Вопрос, показался мне интересным. Через пару дней был готов прототип из USB-хаба, двух GSM-модемов, флешки, Raspberry Pi и Asterisk. С тем же успехом вместо Raspberry Pi можно было использовать и, например, роутер D-Link DIR-320, но не захотелось заморачиваться. Увы «проект» оказался не востребованным, но не пропал даром.

Было принято решение, что в доме АТС не будет лишней. Конфигурация была расширена. GSM-каналов стало четыре, добавился шлюз для стационарного телефона и был подключен сервис Zadarma.com. Так же были установлены софтфоны на домашние компьютеры, мобильные телефоны и в головное устройство в автомобиль. Все это, достаточно, хорошо и долго работало, но в один прекрасный день во время грозы погибли оба шлюза (и не только) и, пока увы не восстановлено.

Третья VM на этом сервере это, собственно, сервер авторизации Radius (Remote Authentication in Dial-In User Service).

Очень долго собирался его развернуть, но как-то все время откладывал. И уже, только, когда дело дошло до Zabbix и Ansible (о них будет подробней, но позже), то и Radius пошел вместе с ними прицепом.

Сервер 2

Тут живут, исключительно, виртуальные машины:

• Windows XP, 7, 10 — для моделирования клиентских ситуаций и решения их проблем;
• Asterisk — для тестов;
• GitLab — система контроля версий, для разработки приложений и хранения конфигураций всего, что есть в системе;
• Shinobi — видеонаблюдение;
• Zabbix — система мониторинга;
• Ansible — централизованная система управления;
• RethinkDB — база данных реального времени для кратковременного хранения информации и формирования событий при ее изменении;
• PostgreSQL — реляционная база данных для долговременного хранения информации;
• dgHome — frontend системы управления Цифровым Домом;
• dgServ — backend системы управления Цифровым Домом;
• и еще несколько VM для изучения новых операционок, для экспериментов ребенка, ну и так по мелочи…

Самая интересная и функциональная, так это, связка из RethinkDB, PostgreSQL, dgServ и dgHome. Основная работа возложена на dgServ. Это API сервер созданный с использованием фреймворка FeatherJS . Основная мысль такова — отказ от постоянного опроса устройств с целью выяснения их состояния и создание единого управляющего интерфейса для них (и еще, наверное, выпендриться, что бы было не как у всех).

В общих чертах, это работает так. При срабатывании чего-нибудь, Мега отправляет http-запрос на сервер, он верифицирует полученное и логирует в оперативную базу данных (RethinkDB) из базы же берет перечень действий привязанных к данному событию и выполняет их, производя при этом логирование результата. И заключительное действие в этой итерации — снимок состояния всего устройства инициатора запроса с сохранением его в базу данных. В дальнейшем снимок может быть использован для восстановления при кратковременном отключении электропитания и(или) коррекции отображения состояния на frontend`e. В конце суток сервер производит перенос значимых данных из оперативной базы в долговременную на PostgreSQL. Это сильно упрощенное описание части алгоритма со стороны устройств.

С другой стороны технологическими устройствами можно управлять тремя методами. Через веб-интерфейс frontend`а, через API совместимый с API Меги, а по-сему можно использовать управляющие программы, умеющие работать с Мегой напрямую, и через расширенный API предоставляемый dgServ. Frontend связан с сервером посредством сокетов и подписан на те или иные изменения оперативной базы данных и по-этому любое изменение в ней мгновенно отображается в веб-интерфейсе.

Продолжение следует…