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

[Balintrue]

Хотелось бы подробнее узнать про развертывание и настройку софта

[worldmind]

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

[tm3]

Пользовался только инструкциями Github, которые находятся в репозитории сервера Synapse (ссылка в начале статьи). Гораздо сложнее было настроить Zabbix, агентов, плагин для мониторинга PostgreSQL и дисков, оповещение о сбоях / проблемах на email / смартфон и т.п. Также несколько раз пришлось переключаться на standby базу PostgreSQL во время миграции с одного мини-сервера на другой.

[DGN]

Хмм, а есть возможность сделать по такому же принципу домашнее облако? Чтобы все не в гугл-майкрософт бакапилось, а в свою облачную сеть?

[censor2005]

Nextcloud/owncloud в помощь. Для Raspberry вполне по силам потянуть облако на несколько пользователей, если подключите внешний hdd

[sawser]

На малинке запустится, конечно, но работать Nextcloud/owncloud будeт крайне медленно. Попробуйте, например, синхронизировать тысячи полторы мелких файлов. Лично у меня папка с 2тыс файлами, общим объемом 700 Мб синхронизировалась около 7,5 часов.

[censor2005]

Я думаю, если подключить малинку по ethernet, и добавить usb-hdd, побыстрее будет. Хотя надо тестировать и замерять, конечно. Вряд ли кому-то будет интересна статья на эту тему?

[overmind88]

У меня на таком же ODROID как у автора сейчас крутится nextcloud, ~18k файлов, 14 гигабайт, всё абсолютно плавно работает. Жёсткий диск по USB3, сеть по Ethernet

[einhander]

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

[Murz]

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

[einhander]

Для файлопомойки лучше ssh, что у меня и настроено. Клиенты есть под все платформы. Хотелось сделать свое облако и посмотреть как оно будет работать в условиях близким к боевым))

[DGN]

Это нормально. Я не создаю 2000 новых файлов каждые 7 часов. А начальная синхронизация пусть хоть месяц фоном идет.

[mtex]

Если цель стоит именно в «облачности», то бишь распределенном хранилище, то можно поглядеть на ту же syncthing — «облако» клепается буквально на коленке. Я как-то писал на эту тему статью.

Если важна синхронизация всяких аутглюков, контактов и иже с ним то, как выше заметили, owncloud/nextcloud.

[KYuri]

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

[tm3]

Нет, не смотрел. Я думаю что 5 устройств на Intel все-таки будут дороже. Все что описано, конечно можно реализовать на одном десктопном компьютере / ноутбуке. В моем случае хотелось, чтобы при выходе из строя любой железки ее функциональность можно было бы перенести на оставшиеся — обеспечить отказоустойчивость.

[Murz]

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

[Murz]

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

[tm3]

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

[Karloid]

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

не думаю что дела с производительностью сейчас обстоят лучше, но 1.5 года уже не слежу за матриксом.
PS: моб клиенты 1.5/3 года назад были жутко деревянные и кривые, ни в какое сравнение с телеграмом не шли.

[tm3]

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

[Karloid]

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

[Murz]

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

[Karloid]

Понятно что у матрикса возможности шире, но мой поинт в том что имплементация была достаточно наивная, на питоне c blocking IO, если это же апи реализовать
более аккуратно и с non blocking IO было бы на порядки лучше.
> И причём 100 человек держал нормально
держал 100 человек которые активно взаимодействовали с апи и держали лонг пул соединения? у нас были уже большие проблемы с перформансом с кучей чатов 1 на 1 на отдельной машине без федерации к matrix.org

[swiing]

И сколько оно стоило по железу, если не секрет? Интересно сравнить с моим домашним «кластером» на 2x Celeron J3455 с Proxmox и Chep.

[tm3]

Цены всем известны, Raspberry Pi — $35, ODROID-XU4 — $59. Здесь смысл в количестве устройств, на двух устройствах сложно организовать отказоустойчивую систему.

[Gizmich]

но на J3455 можно ведь организовать полноценный рэйд, а у вас как с этой частью отказоустойчивости?

[tm3]

Настроен hot standby базы + бэкапы базы + экспорт базы + отдельно делаются резервные копии фронтенда. Основная база передает логи на standby, т.е. имеется вторая база, которая синхронизируется с основной базой, задержка составляет менее секунды. Один раз (спустя примерно месяц после запуска системы), когда файлы основной базы были на MicroSD карте (а не как сейчас, на подключенном внешнем USB диске), начались ошибки в файловой системе, часть файлов основной рабочей базы данных было повреждено.
Активация standby базы и переключение фронтенда на эту базу позволило быстро и без потерь пережить инцидент — все данные были в целости и сохранности в standby базе.
Проявился инцидент (кроме ошибок в логах) следующим образом — 2 пользователя не могли получить сообщение от третьего пользователя — транзакция не могла завершиться commit'ом в базе. Еще раз прочувствовал мощь standby — в standby базу попадают только завершенные транзакции — standby база сохранила свою целостность несмотря на серьезный сбой основной базы.

[swiing]

Наличие SATA на х86 мат. платах было одним из факторов из-за которого я решил не связаваться с arm. Так же к плюсам можно отнести: наличие pci-e (добавить еще один RAID/HBA или сетевуху) и рашриряемую аж до 16 Гб память. Хотя в итоге стоить оно будет где-то 2.5 раза дороже чем ODROID-XU4 или PINE64. Конкретно у меня с отказоустойчивостью все не очень, система скорее на поиграть: посмотрелть как работает VM Live migration, поставить kubernetes и т.д… Важных данных я там не храню.