Готовим Matrix в домашних условиях

    Началось все с небольшого эксперимента по установке сервера обмена сообщениями Synapse на смартфоне с операционной системой Ubuntu Touch, а закончилось созданием маленького домашнего дата-центра на 5 ARM мини-серверах (Raspberry Pi и ODROID-XU4), основная функция которых — обеспечение работы системы обмена сообщениями / звонками по протоколу Matrix и WebRTS для 10 пользователей.

    Matrix — это открытый протокол мгновенного обмена сообщениями (базирующийся на децентрализованных серверах), который позволяет пользователям осуществлять обмен текстовыми сообщениями и файлами, выполнять голосовые и видео звонки, создавать чат-каналы и т.п.

    Наиболее известный клиент для сети Matrix — Riot.im, реализован в виде мобильного, web или десктопного приложения. По функциональности не уступает клиентам современных мессенджеров Slack / Telegram / WhatsApp.

    Итак, после установки на смартфон (сервером сложно пользоваться, когда он находится у тебя в кармане и все время меняет свой адрес и метод подключения — WiFi / 3G / 4G), следующим этапом был перенос системы на один Raspberry Pi. Фрон-энд — реализация сервера Synapse на Python, бэк-энд — база данных PostgreSQL из стандартного дистрибутива Raspbian for Raspberry Pi.

    Подключение к интернет — через port forwarding (порт 8448) на домашнем vDSL модеме со статическим внешним IP адресом.

    Все работало, но иногда со «скрипом» — периодически возникали задержки — подключение клиентов занимало несколько секунд, тайм-ауты при подключении к сторонним каналам / комнатам matrix.org.

    После переноса базы данных PostgreSQL на второй Raspberry Pi производительность заметно улучшилась, но все равно иногда возникала 100% загрузка одного из ядер процессора в течение нескольких минут (на стороне фронт-энда).

    Для улучшения ситуации фронт-энд был перенесен на безвентиляторный ODROID-XU4 (8 ARM ядер, 2 Gb оперативной памяти, цена сервера — $59), а затем и база данных PostgreSQL была перенесена на второй ODROID-XU4.



    Добавились USB Ethernet свитч ($20) для связи серверов по витой паре, внешний USB диск на 2 Tb, а также 6-портовая USB зарядка для питания 3-х Raspberry Pi и Ethernet свитча.
    Освободившиеся Raspberry Pi были сконвертированы: firewall для обеспечения DMZ, сервер Zabbix для мониторинга, сервер hot standby для базы данных PostgreSQL (находится в другой комнате). Еще один Raspberry Pi c модулем доступа к мобильному интернету был добавлен для получения второго канала связи через 4G модуль для Raspberry Pi.

    Кроме этого, был добавлен источник бесперебойного питания UPS.

    В процессе монтажа система выглядела вот так (размещена внутри электрокамина):



    Размер базы данных бэк-энда Synapse вырос за полгода на ~ 325 Mb:



    Размер базы данных системы мониторинга Zabbix вырос до 1.25 Gb и скоро стабилизируется:



    Загрузка внешней сети (график за 7 дней):



    Загрузка внутренней сети (график за 7 дней):



    График нагрузки на фронт-энде за 3 дня:



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

    Все вышесказанное можно реализовать на недорогих VPS в любом датацентре, но если это работает стабильно дома, то почему бы не сделать это на домашнем оборудовании?
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 30

      +1
      Хотелось бы подробнее узнать про развертывание и настройку софта
        0
        Да и вообще полноцнный обзор протокола и всего вокруг, а то упоминать-то упоминают, а хорошего сравнения с аналогами не помню.
          0
          Пользовался только инструкциями Github, которые находятся в репозитории сервера Synapse (ссылка в начале статьи). Гораздо сложнее было настроить Zabbix, агентов, плагин для мониторинга PostgreSQL и дисков, оповещение о сбоях / проблемах на email / смартфон и т.п. Также несколько раз пришлось переключаться на standby базу PostgreSQL во время миграции с одного мини-сервера на другой.
          0
          Хмм, а есть возможность сделать по такому же принципу домашнее облако? Чтобы все не в гугл-майкрософт бакапилось, а в свою облачную сеть?
            +1
            Nextcloud/owncloud в помощь. Для Raspberry вполне по силам потянуть облако на несколько пользователей, если подключите внешний hdd
              0
              На малинке запустится, конечно, но работать Nextcloud/owncloud будeт крайне медленно. Попробуйте, например, синхронизировать тысячи полторы мелких файлов. Лично у меня папка с 2тыс файлами, общим объемом 700 Мб синхронизировалась около 7,5 часов.
                0
                Я думаю, если подключить малинку по ethernet, и добавить usb-hdd, побыстрее будет. Хотя надо тестировать и замерять, конечно. Вряд ли кому-то будет интересна статья на эту тему?
                  +2
                  У меня на таком же ODROID как у автора сейчас крутится nextcloud, ~18k файлов, 14 гигабайт, всё абсолютно плавно работает. Жёсткий диск по USB3, сеть по Ethernet
                  • НЛО прилетело и опубликовало эту надпись здесь
                      0

                      У nextcloud работа с файлами в т.ч и синхронизация очень затратная по ресурсам вещь. На домашнем сервере с core2quad в контейнере при синхронизации веб интерфейс тормозил нещадно. Потом настроил redis, стало вполне терпимо.

                        0

                        Для файлопомойки лучше уж Seafile — он гораздо шустрее работает и экономнее по ресурсам в разы

                          0
                          Для файлопомойки лучше ssh, что у меня и настроено. Клиенты есть под все платформы. Хотелось сделать свое облако и посмотреть как оно будет работать в условиях близким к боевым))
                        0
                        Это нормально. Я не создаю 2000 новых файлов каждые 7 часов. А начальная синхронизация пусть хоть месяц фоном идет.
                    • НЛО прилетело и опубликовало эту надпись здесь
                        0
                        Если цель стоит именно в «облачности», то бишь распределенном хранилище, то можно поглядеть на ту же syncthing — «облако» клепается буквально на коленке. Я как-то писал на эту тему статью.

                        Если важна синхронизация всяких аутглюков, контактов и иже с ним то, как выше заметили, owncloud/nextcloud.
                        0
                        Не смотрели в сторону j3455/j4105?
                        Причем есть как готовые платформы (nuc-и, brix-ы и т.д.), так и mini-ITX платы.
                        Из видимых плюсов — расширяемость в плане объема памяти и подключения устройств SATA и PCI-E.
                        И энергопотребление, подозреваю, должно быть меньше, чем у пары XU4…
                          0
                          Нет, не смотрел. Я думаю что 5 устройств на Intel все-таки будут дороже. Все что описано, конечно можно реализовать на одном десктопном компьютере / ноутбуке. В моем случае хотелось, чтобы при выходе из строя любой железки ее функциональность можно было бы перенести на оставшиеся — обеспечить отказоустойчивость.
                            0

                            Мне кажется один самый дешёвый полноценный комп это всё потянул бы гораздо шустрее, чем несколько Малинок, и по деньгам возможно даже дешевле. Тут же огромные потери в производительноти идут когда БД на отдельном компе по сети да еще и через usb, usb-винт вместо sata и т.п.

                              0

                              Ну а для отказоустойчивости — второй такой же комп (или можно даже послабее, ту же Малинку чтобы зеркалить базу и файло) с зеркалом всего. По деньгам за полноценный комп аля целерон j3455 с 4 гигами оперативы можно тысяч в 5 рублей уложиться (без винтов считал)

                                0
                                Наверное придется так и сделать, если начнутся проблемы с производительностью. Пока этого нет — бесшумные мало потребляющие электричество железки мне больше нравятся. Спасибо за комментарии!
                          0
                          Немного личного опыта: 3 года назад повелся на статью на хабре которая восхваляла матрикс, и мы переползли на него с джаббера в нашей сервисе чатика с поиском людей, поимев огромные проблемы с производительностью.
                          В момент анализа лично я анализировал только апи которое мне приглянулось как для разработчика клиента, а вот наш серверный человек\все вместе не протестировали производительность, что сильно аукнулось.

                          не думаю что дела с производительностью сейчас обстоят лучше, но 1.5 года уже не слежу за матриксом.
                          PS: моб клиенты 1.5/3 года назад были жутко деревянные и кривые, ни в какое сравнение с телеграмом не шли.
                            0
                            Платформа сейчас активно развивается, выходят обновления не реже чем раз в месяц. За 3 года многое улучшилось. Как видно, даже такие слабые мини-серверы не нагружены, проблем с производительностью в данный момент нет.
                              +1
                              для 10 людей проблем и не будет, просто даже на небольшом скейле до 100 человек онлайн какой-нибудь ejabberd будет на порядок(и) эффективнее про cpu/ram, понятно что протоколы различаются, просто матрикс был чудовищно неэффективен.
                              Особенно будет заметно если люди создают кучу чатов 1 на 1, а не сидят в глобальных.
                                +1

                                Жаббер только передаёт сообщения от одного клиента к другому (как почтовый сервер), матрикс хранит всё у себя и проверяет через dag, отсюда и повышенные требования к ресурсам. Да и на жаббере чтобы настроить аттач картинок, групповые чаты с оффлайн-сообщениями и историей на сервере, видео и аудио звонки — придётся знатно помучаться ;( я вот это так и ниасилил, поэтому Матрикс для меня оказался отличным решением всех проблем прям из коробки! И причём 100 человек держал нормально, жора ресурсов не заметил, пока не стал заходить в комнаты аля Matrix HQ где 10 тыщ человек с сотен разных серверов и все спамят мессагами постоянно, но тут и жаббер-сервер наверное бы тоже завыл.

                                  0
                                  Понятно что у матрикса возможности шире, но мой поинт в том что имплементация была достаточно наивная, на питоне c blocking IO, если это же апи реализовать
                                  более аккуратно и с non blocking IO было бы на порядки лучше.
                                  > И причём 100 человек держал нормально
                                  держал 100 человек которые активно взаимодействовали с апи и держали лонг пул соединения? у нас были уже большие проблемы с перформансом с кучей чатов 1 на 1 на отдельной машине без федерации к matrix.org
                            0
                            И сколько оно стоило по железу, если не секрет? Интересно сравнить с моим домашним «кластером» на 2x Celeron J3455 с Proxmox и Chep.
                              +1
                              Цены всем известны, Raspberry Pi — $35, ODROID-XU4 — $59. Здесь смысл в количестве устройств, на двух устройствах сложно организовать отказоустойчивую систему.
                                0
                                но на J3455 можно ведь организовать полноценный рэйд, а у вас как с этой частью отказоустойчивости?
                                  0
                                  Настроен hot standby базы + бэкапы базы + экспорт базы + отдельно делаются резервные копии фронтенда. Основная база передает логи на standby, т.е. имеется вторая база, которая синхронизируется с основной базой, задержка составляет менее секунды. Один раз (спустя примерно месяц после запуска системы), когда файлы основной базы были на MicroSD карте (а не как сейчас, на подключенном внешнем USB диске), начались ошибки в файловой системе, часть файлов основной рабочей базы данных было повреждено.
                                  Активация standby базы и переключение фронтенда на эту базу позволило быстро и без потерь пережить инцидент — все данные были в целости и сохранности в standby базе.
                                  Проявился инцидент (кроме ошибок в логах) следующим образом — 2 пользователя не могли получить сообщение от третьего пользователя — транзакция не могла завершиться commit'ом в базе. Еще раз прочувствовал мощь standby — в standby базу попадают только завершенные транзакции — standby база сохранила свою целостность несмотря на серьезный сбой основной базы.
                                    0
                                    Наличие SATA на х86 мат. платах было одним из факторов из-за которого я решил не связаваться с arm. Так же к плюсам можно отнести: наличие pci-e (добавить еще один RAID/HBA или сетевуху) и рашриряемую аж до 16 Гб память. Хотя в итоге стоить оно будет где-то 2.5 раза дороже чем ODROID-XU4 или PINE64. Конкретно у меня с отказоустойчивостью все не очень, система скорее на поиграть: посмотрелть как работает VM Live migration, поставить kubernetes и т.д… Важных данных я там не храню.

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое