Расширяем доступное дисковое пространство VPS сервера (внешнее хранилище данных для NextCloud)

    Общий рейтинг статьи: 4 (проголосовало 1 )
    Опубликовано:  [просмотров 406]


    Наверное все системные администраторы и менеджеры проектов сталкивались с тарифами на виртуальные сервера, а именно с градацией на типы виртуализации KVM/OpenVZ (тут даже больше вариантов, но идея одна, а именно аппаратная виртуализация или контейнер).

    Тарифы на VPS вещь вообще довольно занятная и у вас обычно есть выбор или много доступного дискового пространства, но куцый проц и OpenVZ или приличные вычислительные ресурсы с KVM-виртуализацией, но 10-15 гб доступного места, а если вы хотите совместить эти параметры, то покупайте выделенный сервер, что для небольших проектов является явным перебором. 

    Сравнение цен на OpenVZ-хостинг в сравнении с KVM

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

    С дисковым пространством все еще интереснее и сейчас я расскажу как это устроено:

    • В системах контейнерной виртуализации, обычно используют так называемую Simfs (подробнее можно почитать тут https://openvz.org/Simfs_filesystem_for_Virtuozzo_7_Containers) и файлы вашей виртуальной машины просто лежат в отдельном каталоге как в случае в chroot (я про такой подход уже писал в статье "Запуск графических OpenGL приложений Linux в chroot-окружении"), естественно, что так хостеру и проще бэкапить и вы занимаете не 100% ресурсов своего тарифного плана, что позволяет втиснуть еще несколько лишних машин на хост.
    • В случае использования систем аппаратной виртуализации, хостеру приходится создавать образ диска с которым будет работать гипервизор и это будет один файл с которым система постоянно работает. Хотя можно создать так называемый расширяемый образ диска который будет увеличиваться в процессе наполнения вашей виртуальной машины данными, но он все равно будет больше чем Simfs и механизмы резервного копирования такого образа потребуют дополнительного дискового пространства для создания снимка файловой системы.

    Собственно, все по честному и в случае KVM хостер имеет больше накладных расходов и не может жульничать, поэтому ставит скажем так справедливую цену на ресурсы.

    Сегодня мы рассмотрим подключение дешевого хранилища на базе OpenVZ к полноценному KVM-хостингу и такой метод позволяет расширить дисковое пространство хранилища NextCloud с помощью "внешнего диска".

    Наверное, многие сейчас задаются вопросом, а почему не использовать штатные плагины позволяющие подключать дополнительные хранилища используя Google.Drive/Yandex.Диск/Amazon S3 и т.п.? 

    На это есть несколько причин:

    • Это в любом случае получится дороже
    • NextCloud мы используем именно по той причине, что это наше персональное хранилище и никакие "левые" провайдеры услуг туда не лезут
    • В плагинах используется Dav-протокол, а он заведомо медленнее чем монтирование sshfs-диска

    Расширение доступного дискового пространства NextCloud при помощи дешевого хранилища на базе OpenVZ неплохо себя зарекомендовало при построении облачного хранилища для довольно большой рабочей группы, но при настройке такого типа подключения внешнего хранилища необходимо обратить внимание на то, чтобы дешевая OpenVZ машина выступающая в качестве хранилища и полноценная KVM VPS находились у одного хостинг-провайдера и в одном дата-центре, а в противном случае задержки обработки данных при подключении сетевого хранилища на медленных каналах связи сведут все ваши старания на нет.

    И еще одна маленькая деталь:

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

    Как вы наверное поняли использовать мы будем sshfs о котором я уже начал писать в статье "Создание пользователя Linux с правом доступа только к SFTP без консольного входа в систему" и эта статья представляет собой ее логическое продолжение, но сегодня мы будем подключать созданное хранилище.

    Как обычно мы начнем с установки пакета для работы с sshfs:

    # aptitude install sshfs

    В целях обеспечения безопасности монтирование удаленного ресурса будет осуществляться от имени пользователя www-data и доступ к файлам удаленного сервера так же будет осуществляться от имени пользователя www-data. Проще говоря, необходимо "перелогиниться" в пользователя www-data и провести операцию монтирования удаленного сетевого ресурса командой:

    $ sshfs www-data@files.help-me-24.com:"/var/www/vhosts/files.help-me-24.com/" ./files

    Авторизация в нашем случае будет проходить "по ключу без использования паролей" и вот здесь и начинается самое интересное. Так как запись в /etc/passwd для пользователя www-data не содержит указания о его shell, то при попытке выполнения команды su www-data вы получите ошибку:

    This account is currently not available.

    До недавнего времени мне приходилось устанавливать shell для системных пользователей, что мягко говоря не безопасно, но недавно мне подсказали, что можно принудительно указать shell при использовании команды su и обойти это ограничение.

    # su www-data -s /bin/bash

    Следующим специфичным ограничением является работа с домашним каталогом пользователя www-data при создании ключа для доступа к сетевым ресурсом по ssh, а именно, типовая команда генерации ssh-ключа для пользователя www-data:

    $ ssh-keygen

    Заврешается ошибкой:

    Could not create directory '/var/www/.ssh': No such file or directory

    Это связано с ограничениями на корневую папку /var/www/ которая является домашним каталогом пользователя www-data и для обхода этого ограничения выполните следующие действия:

    # mkdir -p /var/www/.ssh/
    # chown www-data:www-data /var/www/.ssh/

    Теперь вы можете создать ssh-ключ, скопировать его на удаленный сервер и осуществить монтирование удаленного сетевого ресурса с правами пользователя www-data.

    $ ssh-keygen
    $ ssh-copy-id www-data@files.help-me-24.com
    $ sshfs www-data@files.help-me-24.com:"/var/www/vhosts/files.help-me-24.com/" ./files

    Так же обратите внимание, что каталог в который осуществляется монтирование должен быть доступен для записи, в противном случае вы получите ошибку:

    fusermount: failed to open /etc/fuse.conf: Permission denied
    fusermount: user has no write access to mountpoint /opt/web/files

    Мы с вами рассмотрели "временный режим монтирования сетевого ресурса", а теперь подумайте что станет с подключенным ресурсом если:

    • На момент монтирования ресурса удаленный сервер будет недоступен
    • Файловый сервер с которого примонтирован ресурс будет перезагружен

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

    В своей статье "Монтирование сетевых ресурсов в Linux" я рассматривал несколько способов монтирования сетевых ресурсов с использованием sshfs которые должны автоматически переподключать общий ресурс в случае падения и вы можете использовать любой из них.

    Я в свою очередь пошел максимально простым путем. Написал скрипт который проверяет доступность флагового-файла на удаленном ресурсе и в случае сбоя отмонтирует ресурс и пытается подключить его заново.

    Скрипт выглядит следующим образом:

    #!/bin/sh

    REMOTE_SHARE=www-data@files.help-me-24.com:/var/www/vhosts/files.help-me-24.com/
    MOUNT_POINT=/opt/web/files/
    MOUNT_BY_USER=www-data

    while true;
    do
    mount_status=`su $MOUNT_BY_USER -s /bin/sh -c "cat $MOUNT_POINT/mounted.dat"`
    if [ -z "$mount_status" ];
    then
    umount $MOUNT_POINT
    su $MOUNT_BY_USER -s /bin/sh -c "sshfs $REMOTE_SHARE $MOUNT_POINT"
    fi
    sleep 20
    done

    Скрипт выглядит хоть и не особо презентативно, зато работает железобетонно.

    Метод которым вы запустите его при старте сервера выберите сами, главное не забудьте отцепить его отдельным процессом при помощи оператора &.


    Связанные записи в блоге

    Обсуждение статьи

    Ваш комментарий: