company_banner

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

  • Tutorial


Есть очень крутой комбайн для совместного ведения проектов, LDAP-авторизацией, синхронизацией файлов с версионированием и чем-то вроде корпоративного мессенджера с видеоконференциями, которые прикрутили в последних версиях. Да, я про Nextcloud. С одной стороны, я сторонник Unix-way и четкого дробления приложений по отдельным функциям. С другой — этот продукт более чем устойчив, работает много лет в нескольких проектах без особых проблем и дополнительные свистелки особо не мешают ему работать. Если очень хочется, то туда можно прикрутить практически любую дичь. Коммьюнити живое и вполне допиливает различные плагины, которые доступны как отдельные приложения.

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

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

Что нужно компаниям?


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

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

В частности, по моему опыту, в Nextcloud востребовано несколько функций среди небольших компаний:

  1. Предоставление доступов к общим каталогам и синхронизация.
  2. Киллер-фича с предоставлением доступа вовне в рамках федерации. Можно интегрироваться с аналогичным продуктом у коллег и другой компании.
  3. Предоставление доступов вовне по прямой ссылке. Очень помогает, если вы, например, работаете в полиграфии и надо обмениваться с клиентами большими объемами тяжелых данных.
  4. Редактор документов Collabora, который выполняется на стороне сервера и работает как фронтенд к LibreOffice.
  5. Чаты и видеозвонки. Немного спорная, не совсем стабильная функция, но она есть и работает. В последней версии ее уже стабилизировали.

Строим архитектуру


К сожалению, в последних версиях документация по корпоративному внедрению Nextcloud доступна только для владельцев платной подписки. Впрочем, в качестве референса можно взять более старые мануалы, которые до сих пор в открытом доступе.


Типовой вариант для домашнего использования и единичных инсталляций.

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


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

Основные компоненты системы:

  • 1 Балансировщик. Можете взять HAproxy или Nginx. Я рассмотрю вариант с Nginx.
  • 2-4 штуки Application server (web-server). Сама инсталляция Nextcloud с основным кодом на php.
  • 2 БД. В стандартной рекомендованной конфигурации это MariaDB.
  • NFS-хранилище.
  • Redis для кеширования запросов к БД

Балансировщик


В данной архитектуре у вас будет меньше точек отказа. Основная точка отказа — это балансировщик нагрузки. В случае его недоступности пользователи не смогут достучаться до сервиса. К счастью, его конфигурация того же nginx довольно проста, как мы рассмотрим дальше, а нагрузку он держит без особых проблем. Большинство аварий на балансировщике решается рестартом демона, всей ноды целиком или развертыванием из бэкапа. Не будет лишним иметь настроенный холодный резерв в другой локации с ручным переключением трафика на него в DNS.

Обратите внимание, что балансировщик также является точкой терминирования SSL/TLS для ваших клиентов, а общение с бэкендом может идти как по HTTP для доверенных внутренних сетей, так и с дополнительным HTTPS, если трафик до application-сервера идет по общим недоверенным каналам.

База данных


Типовое решение — MySQL/MariaDB в кластерном исполнении в master-slave репликации. При этом у вас активна только одна БД, а вторая работает в режиме горячего резерва на случай аварийного отказа основной или при проведении плановых работ. Можно рассмотреть и вариант с балансировкой нагрузки, но она технически сложнее. При использовании MariaDB Galera Cluster с вариантом master-master репликации нужно использовать нечетное количество нод, но не менее трех. Таким образом минимизируется риск split-brain ситуаций, при рассечении связности между нодами.

Storage


Любое оптимальное для вас решение, которое предоставляет NFS-протокол. В случае высоких нагрузок можно рассмотреть IBM Elastic Storage или Ceph. Также возможно использование S3-совместимого объектного хранилища, но это скорее вариант для особо крупных инсталляций.

HDD или SSD


В принципе, для средних по размеру инсталляций вполне достаточно использования только HDD. Узким участком тут будут iops при чтении из БД, что сильно сказывается на отзывчивости системы, но, при наличии Redis, который кеширует все в RAM, это не будет особой проблемой. Так же часть кеша будет лежать в memcached на application-серверах. Тем не менее, я бы рекомендовал, по возможности, размещать application-сервера на SSD. Веб-интерфейс становится намного отзывчивее по ощущениям. При этом та же синхронизация файлов на десктопных клиентах будет работать примерно так же, как и при использовании HDD для этих узлов.

Скорость синхронизации и отдачи файлов будет определяться уже производительностью вашего NFS-хранилища.

Конфигурируем балансировщик


В качестве примера я приведу простой в базовой конфигурации и эффективный nginx. Да, различные дополнительные failover-плюшки у него доступны только в платной версии, но даже в базовом варианте он отлично выполняет свою задачу. Учтите, что балансировка типа round robin или random нам не подходит, так как application-сервера хранят кеши для конкретных клиентов.
К счастью, это решается использованием метода ip_hash. В таком случае сессии пользователя будут закреплены за конкретным бэкендом, к которому будут направляться все запросы со стороны пользователя. Этот момент описан в документации:
Задаёт для группы метод балансировки нагрузки, при котором запросы распределяются по серверам на основе IP-адресов клиентов. В качестве ключа для хэширования используются первые три октета IPv4-адреса клиента или IPv6-адрес клиента целиком. Метод гарантирует, что запросы одного и того же клиента будут всегда передаваться на один и тот же сервер. Если же этот сервер будет считаться недоступным, то запросы этого клиента будут передаваться на другой сервер. С большой долей вероятности это также будет один и тот же сервер.

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

В конфигурационном файле nginx это описывается следующим образом:

upstream backend {
    ip_hash;

    server backend1_nextcloud.example.com;
    server backend2_nextcloud.example.com;
    server backend3_nextcloud.example.com;
    server backend4_nextcloud.example.com;
}

В этом случае нагрузка будет по возможности равномерно распределяться между application-cерверами, хотя из-за привязки клиента к конкретной сессии могут возникать перекосы нагрузки. Для небольших и средних инсталляций этим можно пренебречь. Если у вас бэкенды разные по мощности, то можно задать вес каждого из них. Тогда балансировщик будет стараться распределять нагрузку пропорционально заданным весам:

upstream backend {
    ip_hash;

    server backend1_nextcloud.example.com weight=3;
    server backend2_nextcloud.example.com;
    server backend3_nextcloud.example.com;
}

В приведенном примере из 5 пришедших запросов 3 уйдут на backend1, 1 на backend2 и 1 на backend3.

В случае, если один из application-серверов откажет, nginx попробует переадресовать запрос следующему серверу из списка бэкендов.

Конфигурируем БД


Подробно Master-Slave конфигурацию можно посмотреть в основной документации.

Разберем несколько ключевых моментов. Для начала создаем пользователя для репликации данных:

create user 'replicant'@'%' identified by 'replicant_password';
grant replication slave on *.* to replicant;
flush privileges;

Затем правим конфиг мастера:

sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf 

В районе блока «Logging and Replication» вносим нужные правки:

[mysqld]
log-bin         = /var/log/mysql/master-bin
log-bin-index   = /var/log/mysql/master-bin.index
binlog_format   = mixed
server-id       = 01
replicate-do-db = nextcloud
bind-address = 192.168.0.6

На Slave конфигурируем конфиг:

sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf 

В районе блока «Logging and Replication» вносим нужные правки:

    [mysqld]
    server-id       = 02
    relay-log-index = /var/log/mysql/slave-relay-bin.index
    relay-log       = /var/log/mysql/slave-relay-bin
    replicate-do-db = nextcloud
    read-only = 1
    bind-address    = 192.168.0.7

Перезапускаем оба сервера:

sudo systemctl restart mariadb

Далее надо будет скопировать БД на Slave.
На Master выполняем для начала выполняем блокировку таблиц:

flush tables with read lock;

А затем смотрим статус:


    MariaDB [(none)]> show master status;
    +-------------------+----------+--------------+------------------+
    | File              | Position | Binlog_Do_DB | Binlog_Ignore_DB |
    +-------------------+----------+--------------+------------------+
    | master-bin.000001 |      772 |              |                  |
    +-------------------+----------+--------------+------------------+
    1 row in set (0.000 sec)

Не выходим из консоли БД, иначе блокировки снимутся!
Нам понадобится отсюда master_log_file и master_log_pos для конфигурации Slave.
Делаем дамп и снимаем блокировки:


sudo mysqldump -u root nextcloud > nextcloud.sql


    > unlock tables;
    > exit;

Затем на Slave импортируем дамп и рестартуем демон:


sudo mysqldump -u root nextcloud < nextcloud.sql
sudo systemctl restart mariadb

После этого в консоли настраиваем репликацию:


    MariaDB [(none)]> change master 'master01' to     
    master_host='192.168.0.6',     
    master_user='replicant',     
    master_password='replicant_password',     
    master_port=3306,     
    master_log_file='master-bin.000001',     
    master_log_pos=772,     
    master_connect_retry=10,     
    master_use_gtid=slave_pos;

Запускаем и проверяем:


> start slave 'master01';
show slave 'master01' status\G;

В ответе не должно быть ошибок и два пункта укажут на успешность процедуры:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Деплоим Application ноды


Есть несколько вариантов деплоя:

  1. snap
  2. docker-image
  3. ручное обновление

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

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

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

Если у вас нет инфраструктуры для этого, то ручное обновление и развертывание из tar.gz вполне удобно и контролируемо.

Не забудьте, что на application-сервера вам потребуется установить веб-сервер для обработки входящих запросов. Я бы рекомендовал связку из nginx + php-fpm7.4. С последними версиями php-fmp ощутимо выросло быстродействие и отзывчивость.

Конфигурирование SSL/TLS


Однозначно стоит рассчитывать на TLS 1.3, если вы делаете новую инсталляцию и нет проблем с пакетами nginx, которые зависят от свежести системного openssl. В частности, 0-RTT и другие плюшки позволяют временами ощутимо ускорить повторное подключение клиентов за счет кеширования. Безопасность также выше за счет выпиливания устаревших протоколов.

Приведу актуальный конфиг для nginx application-сервера, который находится общается с балансировщиком по TLS:

Конфиг nginx
upstream php-handler {
 server unix:/var/run/php/php7.4-fpm.sock;
}

server {
    listen 80;
    server_name backend1_nextcloud.example.com;
    # enforce https
    root /var/www/nextcloud/;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    ssl_early_data on;
#    listen [::]:443 ssl http2;
    server_name backend1_nextcloud.example.com;

    # Path to the root of your installation
    root /var/www/nextcloud/;
    # Log path
    access_log /var/log/nginx/nextcloud.nginx-access.log;
    error_log /var/log/nginx/nextcloud.nginx-error.log;
    ### SSL CONFIGURATION ###
        ssl_certificate /etc/letsencrypt/live/backend1_nextcloud.example.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/backend1_nextcloud.example.com/privkey.pem;
        ssl_trusted_certificate /etc/letsencrypt/live/backend1_nextcloud.example.com/fullchain.pem;
        ssl_dhparam /etc/ssl/certs/dhparam.pem;

        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_prefer_server_ciphers on;
        #ssl_ciphers "EECDH+AESGCM:EECDH+CHACHA20:EECDH+AES256:!AES128";
        ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POL>
        ssl_session_cache shared:SSL:50m;
        ssl_session_timeout 5m;

        ssl_stapling on;
        ssl_stapling_verify on;
        resolver 8.8.4.4 8.8.8.8;

        add_header Strict-Transport-Security 'max-age=63072000; includeSubDomains; preload' always;
### КОНЕЦ КОНФИГУРАЦИИ SSL ###

    # Add headers to serve security related headers
    # Before enabling Strict-Transport-Security headers please read into this
    # topic first.
    # add_header Strict-Transport-Security "max-age=15768000;
    # includeSubDomains; preload;";
    #
    # WARNING: Only add the preload option once you read about
    # the consequences in https://hstspreload.org/. This option
    # will add the domain to a hardcoded list that is shipped
    # in all major browsers and getting removed from this list
    # could take several months.
    add_header Referrer-Policy "no-referrer" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Download-Options "noopen" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Permitted-Cross-Domain-Policies "none" always;
    add_header X-Robots-Tag "none" always;
    add_header X-XSS-Protection "1; mode=block" always;

    # Remove X-Powered-By, which is an information leak
    fastcgi_hide_header X-Powered-By;

    location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }

    # The following 2 rules are only needed for the user_webfinger app.
    # Uncomment it if you're planning to use this app.
    #rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
    #rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json
    # last;

    location = /.well-known/carddav {
      return 301 $scheme://$host/remote.php/dav;
    }
    location = /.well-known/caldav {
      return 301 $scheme://$host/remote.php/dav;
    }

    # set max upload size
    client_max_body_size 512M;
    fastcgi_buffers 64 4K;

    # Enable gzip but do not remove ETag headers
    gzip on;
    gzip_vary on;
    gzip_comp_level 4;
    gzip_min_length 256;
    gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
    gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fon>

    # Uncomment if your server is build with the ngx_pagespeed module
    # This module is currently not supported.
    #pagespeed off;

    location / {
        rewrite ^ /index.php;
    }

    location ~ ^\/(?:build|tests|config|lib|3rdparty|templates|data)\/ {
        deny all;
    }
location ~ ^\/(?:\.|autotest|occ|issue|indie|db_|console) {
        deny all;
    }

    location ~ ^\/(?:index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+)\.php(?:$|\/) {
        fastcgi_split_path_info ^(.+?\.php)(\/.*|)$;
        set $path_info $fastcgi_path_info;
        try_files $fastcgi_script_name =404;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $path_info;
        fastcgi_param HTTPS on;
        # Avoid sending the security headers twice
        fastcgi_param modHeadersAvailable true;
        # Enable pretty urls
        fastcgi_param front_controller_active true;
        fastcgi_pass php-handler;
        fastcgi_intercept_errors on;
        fastcgi_request_buffering off;
    }

    location ~ ^\/(?:updater|oc[ms]-provider)(?:$|\/) {
        try_files $uri/ =404;
        index index.php;
    }

    # Adding the cache control header for js, css and map files
    # Make sure it is BELOW the PHP block
    location ~ \.(?:css|js|woff2?|svg|gif|map)$ {
        try_files $uri /index.php$request_uri;
        add_header Cache-Control "public, max-age=15778463";
        # Add headers to serve security related headers (It is intended to
        # have those duplicated to the ones above)
        # Before enabling Strict-Transport-Security headers please read into
        # this topic first.
        #add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;
        #
        # WARNING: Only add the preload option once you read about
        # the consequences in https://hstspreload.org/. This option
        # will add the domain to a hardcoded list that is shipped
        # in all major browsers and getting removed from this list
        # could take several months.
        add_header Referrer-Policy "no-referrer" always;
        add_header X-Content-Type-Options "nosniff" always;
        add_header X-Download-Options "noopen" always;
        add_header X-Frame-Options "SAMEORIGIN" always;
        add_header X-Permitted-Cross-Domain-Policies "none" always;
        add_header X-Robots-Tag "none" always;
        add_header X-XSS-Protection "1; mode=block" always;

        # Optional: Don't log access to assets
        access_log off;
    }

    location ~ \.(?:png|html|ttf|ico|jpg|jpeg|bcmap)$ {
        try_files $uri /index.php$request_uri;
        # Optional: Don't log access to other assets
        access_log off;
    }
}

Регламентное обслуживание


Не забудьте, что в промышленном окружении требуется обеспечить минимальный и нулевой простой сервиса при обновлении или тем более резервном копировании. Ключевая сложность тут — зависимость состояния метаданных в БД и самих файлов, которые доступны через NFS или объектное хранилище.

При обновлении application-серверов на новую минорную версию особых проблем не возникает. Но кластер все равно надо переводить в mainenance mode для обновления структуры БД.
Выключаем балансировщик в момент наименьшей нагрузки и приступаем к обновлению.

После этого выполняем на нем процесс ручного обновления из скачанного tar.gz, с сохранением конфигурационного файла config.php. Обновление через веб на крупных инсталляциях — очень плохая идея!
Выполняем обновление через командную строку:

sudo -u www-data php /var/www/nextcloud/occ upgrade

После этого включаем балансировщик и подаем трафик на обновленный сервер. Для этого выводим все необновленные application-сервера из балансировки:

upstream backend {
    ip_hash;

    server backend1_nextcloud.example.com;
    server backend2_nextcloud.example.com down;
    server backend3_nextcloud.example.com down;
    server backend4_nextcloud.example.com down;
}

Остальные ноды постепенно обновляем и вводим в строй. При этом occ upgrade уже выполнять не нужно! Нужно только заменить php-файлы и сохранить конфигурацию.

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



RUVDS.com
VDS/VPS-хостинг. Скидка 10% по коду HABR

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

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

    Traefik совсем не рассматриваете?
      +3
      Я вот тоже в его сторону смотрю. А есть плюсы? Я просто смотрю, что он скорее под контейнеризацию ориентирован, а не stateful VM традиционные.
        +1
        Не подскажу, я вот как раз один из тех самых «домашних пользователей» и о traefik услышал пару недель назад. Сам бы с удовольствием почитал их сравнение, плюсы и минусы.
          +1
          Для домашнего пользования разницы в общем нет. Но если сравнивать по бесплатным версиям, то победителем будет на мой взгляд HAProxy.
          По фичам бесплатный HAProxy уделывает бесплатные версии Nginx и traefik. Например, теперь у бесплатного traefik нет кластеризации и rate limiting, а у бесплатного Nginx помимо отсутствия кластеризации ещё очень погрызенная статистика, нет нормальных активных проверок доступности, интеграции с DNS и нет динамической подгрузки конфига. По скорости, даже в кубернетесах (HAProxy с 2.0 сильно ударились в контейнеризацию), в целом тоже выигрывает HAProxy.
            0
            Сложный в конфигурации? Я все никак до него не доберусь.
              0
              Свой формат, но довольно лаконичный, на мой взгляд проще, чем 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 версию, и на что они живут.
                0

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

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

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

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

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

          Все это конечно overengineering, но если если уж делать отказоустойчивое решение, то надо идти до конца. Если знаете хорошие истончики информации или есть советы по этой теме, то делитесь обязаельно. Чувствую, скоро все сервисы придется селфхостить, хочется нащупать оптимальный и надежный рецепт.
            0
            Автор вроде как и пишет, что если docker, то все сразу:
            Docker-image — хороший вариант, особенно, если у вас часть инфраструктуры крутится уже на Kubernetes. Та же нода Redis, скорее всего уедет в кластер следом за application-серверами.


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

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

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

                  0
                  Я для себя смысла не увидел (я в S3 бекапы складываю, т.к весь софт умеет в S3 протокол).
              0
              Вы упомянули об изучении возможностей репликации storage. А подскажите, пожалуйста, насчёт DRBD — насколько данное решение подошло бы в данном случае для базовой отказоустойчивости? CEPH мне кажется overhead, а с Minio не сталкивался (за него, кстати, спасибо — буду изучать).
              +1
              NextCloud начинался как довольно несложный web app хранения файлов, а теперь вырос в огромного монстра, который хочет уметь всё.

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

              В общем, чтобы управляться с этой системой надо быть админом 80-го уровня и тратить очень много времени.
                0
                Давно пользуюсь этой штукой. Ни одной проблемы по обновлению. Стоит нативно, не из контейнера, и я прекрасно понимаю, что где и как собрано, а не юзаю пакет «мы собрали, кушайте».
                  –1
                  Похоже, вы отговорили меня устанавливать его локально. Пока что пользуюсь им от провайдера, и это получается дешевле и лучше, чем облако для файлов от яндекса/мейла/етс
                    +1
                    Попробуй. У меня дома очень отзывчиво работает. Application, MariaDB, Redis на виртуальной машине на SSD, а контент монтируется через Samba.
                  0
                  Восстановление аналогично должно происходить из дампа БД и файлов за один и тот же период. В противном случае возможны потери данных, так как файл может лежать в хранилище, но не иметь метаданных в БД.

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

                    0
                    А можно как-то перетащить данные с очень (лет 5 как) старой версии ownCloud на современный nextCloud? Я вот старую версию уже даже обновить не могу, а терять кучу данных и календарей десятка пользователей совсем не хочется.
                    0
                    Спасибо за статью. Использую для себя, но мне кажется, что Nextcloud слишком тяжелый будет для «средних компаний». Но redis улучшит все дело, конечно.
                      0
                      Спасибо за статью. occ вообще отличный инструмент, в том числе для использования в скриптах по крону. Для обновления самого NC из консоли есть ещё
                      sudo -uwww-data php /var/www/nextcloud/updater/updater.phar
                      с различными опциями (в т.ч. --no-interaction для самых смелых).

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

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