Nextcloud: отказоустойчивый деплой для средних компаний

[EVolans]

Можете взять HAproxy или Nginx. Я рассмотрю вариант с Nginx.

Traefik совсем не рассматриваете?

[Meklon]

Я вот тоже в его сторону смотрю. А есть плюсы? Я просто смотрю, что он скорее под контейнеризацию ориентирован, а не stateful VM традиционные.

[EVolans]

Не подскажу, я вот как раз один из тех самых «домашних пользователей» и о traefik услышал пару недель назад. Сам бы с удовольствием почитал их сравнение, плюсы и минусы.

[Silvarum]

Для домашнего пользования разницы в общем нет. Но если сравнивать по бесплатным версиям, то победителем будет на мой взгляд HAProxy.
По фичам бесплатный HAProxy уделывает бесплатные версии Nginx и traefik. Например, теперь у бесплатного traefik нет кластеризации и rate limiting, а у бесплатного Nginx помимо отсутствия кластеризации ещё очень погрызенная статистика, нет нормальных активных проверок доступности, интеграции с DNS и нет динамической подгрузки конфига. По скорости, даже в кубернетесах (HAProxy с 2.0 сильно ударились в контейнеризацию), в целом тоже выигрывает HAProxy.

[Meklon]

Сложный в конфигурации? Я все никак до него не доберусь.

[Silvarum]

Свой формат, но довольно лаконичный, на мой взгляд проще, чем Nginx. По-крайней мере с точки зрения именно балансировки логичнее что ли выглядит. А мануал у них можно чуть ли не в пример ставить, как надо писать документацию. C 2.0 ещё появился Dataplane API, чтобы конфиг на лету менять прям по API.
К примеру простые конфиги для HTTPS балансера (примеры из интернета):

Nginx

stream {
    upstream stream_backend {
         server backend1.example.com:12345;
         server backend2.example.com:12345;
         server backend3.example.com:12345;
    }

    server {
        listen                443 ssl;
        proxy_pass            stream_backend;

        ssl_certificate       /etc/ssl/certs/server.crt;
        ssl_certificate_key   /etc/ssl/certs/server.key;
        ssl_protocols         SSLv3 TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers           HIGH:!aNULL:!MD5;
        ssl_session_cache     shared:SSL:20m;
        ssl_session_timeout   4h;
        ssl_handshake_timeout 30s;
        #...
     }
}

vs

HAProxy

frontend www.example.com
    bind 10.0.0.3:443 ssl crt /etc/ssl/certs/mysite.pem
    default_backend example.com_web_servers

backend example.com_web_servers
    balance roundrobin
    server backend2 10.0.1.3:443 check maxconn 20 ssl
    server backend2 10.0.1.4:443 check maxconn 20 ssl

Своими руками делал на нем относительно сложную балансировку с разбором URL и заголовоков для выбора соответствующего бекенд сервера, логированием времени отклика по каждому URL, и динамической балансировкой нагрузки, базируясь на метриках вроде CPU и кол-ва текущих запросов от самих балансируемых серверов и динамическим включением новых серверов в балансировку. И всё это доступно в бесплатной версии. С таким набором фич, я даже не знаю, кто у них покупает enterprise версию, и на что они живут.

[Meklon]

Интересно. Надо попробовать. Меня ещё немного тревожит настраиваемость SSL со всеми плюшками, включая 0-RTT.
Ну и sticky session в каком-то виде.

[Silvarum]

0-RTT не трогал, не могу сказать, но по умолчанию выключен. Можно в принципе включить 0-RTT для конкретных безопасных запросов и выключить для остальных.
Co sticky session имел дела — довольно мощный движок, можно даже свои правила для таблиц соответствия делать, помимо стандартных Cookie или IP-Source. Причем эти таблицы он умеет синхронизировать между пирами в кластерном режиме.

[Meklon]

0-RTT напротив дает потенциальную уязвимость к атаке повторения) Но хорош. За sticky session спасибо, надо читать документацию.

[Silvarum]

Ну я и имею в виду включить 0-RTT для запросов, повторение которых не повлечет за собой каких-либо непредсказуемых последствий. Например, включить для главной страницы, но выключить для запроса на покупку товара.

[dlinyj]

Какая полезная, отличная статья! Спасибо большое!

[avg]

Если сессии хранить в redis, то ip_hash становится ненужным.

[Meklon]

Подожди, разве просто установить redis в качестве кеширующего достаточно?

[Doman]

Спасибо за статью, как раз решил попробовать nextcloud после известных новостей о Google Photo, и тоже задуался о High Availability. Пока что эксперементирую на домашнем сервере-ноутбуке (очень удобно — ИБП в виде аккумулятора уже в комплекте, 4G свисток обеспечивает резервный канал, места под HDD маловато, но мне 2TB пока хватает в RAID1), с перспективой разделения на два ноутбука в разных локациях.

Вы предлагаете запускать в Docker только сам nextcloud, а ведь было бы интересно поднять весь сетап (и база, и Redis, и nginx, и не упомянутый в статье мониторинг) в k8s для упрощения горизонтального масштабирования и оптимального fault tolerance. Пока что изучаю k8s операторы для БД (в тч и PostgreSQL, который nextcloud не рекомендует, но поддерживает), а также возможности для репликации стораджа. Ceph для домашнего сетапа выгляит избыточным, поэтому пока что смотрю или на обычную папку с синхронизацией или на minio-кластер.

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

[Meklon]

Автор вроде как и пишет, что если docker, то все сразу:

Docker-image — хороший вариант, особенно, если у вас часть инфраструктуры крутится уже на Kubernetes. Та же нода Redis, скорее всего уедет в кластер следом за application-серверами.

А вообще мне не нравится идея БД в Kubernetes. Очень много чего нецензурного слышал от коллег. Возможно, в радиусе меня его не умеют готовить просто. А вот остальные узлы довольно хорошо ложатся на stateless-конфигурации. Балансировка, приложение, in-memory cache по разным подам. Только вот в домашнем исполнении это не даст особой отказоустойчивости. Я думаю собирать подобие кластера между машинами у родителей и моим сервером. Но вот вопрос отклика остается открытым.

UPD За Minio спасибо. Надо подумать. Хотя плоское хранение объектное лишает простого варианта аварийного извлечения файлов напрямую из файловой системы хранилища.

[ProFfeSsoRr]

Так у Minio на диске структура обычная, ну точнее он её по сути прокидывает в S3, короче поставь — поймешь :)

[Meklon]

Уже интереснее. А синхронизировать между двумя-тремя домашними серверами есть смысл?

[ProFfeSsoRr]

Я для себя смысла не увидел (я в S3 бекапы складываю, т.к весь софт умеет в S3 протокол).

[luxter]

Вы упомянули об изучении возможностей репликации storage. А подскажите, пожалуйста, насчёт DRBD — насколько данное решение подошло бы в данном случае для базовой отказоустойчивости? CEPH мне кажется overhead, а с Minio не сталкивался (за него, кстати, спасибо — буду изучать).

[SlavikF]

NextCloud начинался как довольно несложный web app хранения файлов, а теперь вырос в огромного монстра, который хочет уметь всё.

Из личного опыта:
— При upgrade постоянно вылазиют проблемы, из-за который система становится нерабочей. Приходится вручную копаться в DB, конфигах… Их форум полон вопросами в стиле: запустил upgade и теперь ничего не работает, помогите!
— Прикрутить офисный app для редактирования документов — весьма нетривиальное занятие. Я правда работал не с Collabora, а с OnlyOffice. И оно даже заработало, но при первом же upgrade всё слетело, а починить я так и не осилил. Там взаимодействие контейнеров, настройки DNS, конфиги программ, конфиги веб-серверов в разных местах…
— NextCloud — весьма тормознутая система. Причём я ставил и на SSD, и Redis cache — но этот монстр никак не хочет шустро шевелится. Просмотр фотогалерей из браузера — в разы медленней, чем если просто сгрузить себе все полноразмерные (!) фото и смотреть локально. Генератор thumbnail может работать сутками и после него всё равно всё медленно.

В общем, чтобы управляться с этой системой надо быть админом 80-го уровня и тратить очень много времени.

[nikerossxp]

Давно пользуюсь этой штукой. Ни одной проблемы по обновлению. Стоит нативно, не из контейнера, и я прекрасно понимаю, что где и как собрано, а не юзаю пакет «мы собрали, кушайте».

[vvzvlad]

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

[Meklon]

Попробуй. У меня дома очень отзывчиво работает. Application, MariaDB, Redis на виртуальной машине на SSD, а контент монтируется через Samba.

[cccco]

Восстановление аналогично должно происходить из дампа БД и файлов за один и тот же период. В противном случае возможны потери данных, так как файл может лежать в хранилище, но не иметь метаданных в БД.

У NextCloud есть свой cli: occ, с помощью которого можно пробежать по папке пользователя и обновить файловый кеш в базе. Т.е. можно, например, закинуть файлы по scp/ftp/rsync, а потом синкануть файловую систему с базой, и закинутые файлы появятся в веб-интерфейсе.

[zhum]

А можно как-то перетащить данные с очень (лет 5 как) старой версии ownCloud на современный nextCloud? Я вот старую версию уже даже обновить не могу, а терять кучу данных и календарей десятка пользователей совсем не хочется.

[timurc]

Спасибо за статью. Использую для себя, но мне кажется, что Nextcloud слишком тяжелый будет для «средних компаний». Но redis улучшит все дело, конечно.

[Ul3ainee]

Спасибо за статью. occ вообще отличный инструмент, в том числе для использования в скриптах по крону. Для обновления самого NC из консоли есть ещё

sudo -uwww-data php /var/www/nextcloud/updater/updater.phar

с различными опциями (в т.ч. --no-interaction для самых смелых).