Синхронизация файлов между серверами в кластере

    Хостинг приложений с высокой нагрузкой и постоянно растущим трафиком требует дополнительной мощи и настроек для обработки большого потока запросов. Решением в данном случае может послужить добавление серверов в окружение для поддержки полноценного функционирования приложения.

    В результате вы сталкиваетесь с другой трудностью — более сложная установка по сравнению с использованием одного сервера. Основной проблемой является то, что такие приложения как WordPress, Drupal, Joomla, Liferay, Redmine и т.п. по умолчанию сохраняют все загружаемые файлы только на одном сервере и не синхронизируют их между серверами в кластере. Другими словами, только сервер, который обрабатывал запрос на загрузку файла, будет содержать новый контент.

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

    синхронизация файлов


    На данный момент это всего лишь временное решение, которое помогает автоматизировать синхронизацию контента на нескольких серверах приложений. В будущем (после обработки отзывов) мы собираемся интегрировать этот функционал в ядро системы Jelastic.

    Данное решение — это сочетание букмарклета и скрипта на стороне сервера. В основном серверный скрипт выполняется с помощью такой утилиты как lsyncd и крона.

    Lsyncd это легковесное решение для синхронизации серверов приложений. В сочетании с inotify lsyncd инициирует синхронизацию файлов только в случае обнаружения фактических изменений в системе. Как результат вы не тратите много ресурсов на выполнение синхронизации и уменьшаете нагрузку на CPU.

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

    Таким образом, данное решение максимально упрощает систему файловой синхронизации. Теперь давайте пошагово рассмотрим как это работает.

    В нашем примере мы будем использовать WordPress, развернутый в окружении с двумя серверами. Эта инструкция также полностью подходит для других PHP, Java или Ruby приложений, таких как Drupal, Joomla, Liferay, Redmine и другие.

    Установка Приложения


    1. Разверните WordPress приложение вручную или использовав наш JPS виджет для установки в один клик. Иструкцию и виджет вы можете найти в WordPress документе.

    2. Теперь давайте создадим кластер, увеличив количество серверов в окружении.

    сервер приложения

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

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

    3. Нажмите Открыть в браузере в настройках окружения.

    открыть в браузере

    4. Введите необходимую информацию для завершения установки WordPress.

    установить WordPress

    Тестирование загрузки файлов без синхронизации


    Давайте проверим обработку загруженных файлов сервером без включенной синхронизации.

    1. Пройдите в панель управления и внесите изменения: загрузите изображения или файлы, отредактируйте темы, и т.п. Как пример, мы загрузили одно изображение в раздел Media.

    загрузить картинку в WordPress

    2. Вернитесь в панель управления Jelastic и нажмите Конфигурация рядом с сервером.

    настройки сервера

    3. Перейдите в папку webroot > ROOT > wp-content.
    Там, на одном из серверов приложений появится новая папка uploads, в которой размещены добавленные файлы.

    загрузить файлы

    Папка для загрузки файлов зависит от приложения, которое вы хостите.

    Ниже представлен список таких папок для некоторых популярных приложений:
    WordPress: webroot/ROOT/wp-content
    Drupal: webroot/ROOT/sites
    Joomla: webroot/ROOT/images
    Liferay: webroot/home/liferay/data


    4. Обратите внимание, что на втором сервере папки uploads вовсе не существует.

    сервер без файлов

    Как мы видим, добавленные изображения размещаются только на сервере, который выполнял загрузку файла.

    Настройка синхронизации файлов


    А теперь давайте перейдем к решению проблемы синхронизации файлов в кластере.

    1. Первым делом, пройдите по ссылке на наш блог и перетяните букмарклет File synchronization на панель закладок вашего браузера как показано на рисунке ниже (букмарклет размещен в Apply File Synchronization параграфе).

    букмарклет для синхронизации

    2. Перейдите к панели управления Jelastic и запустите скрипт, нажав Синхронизация файлов на панели закладок.

    букмарклет

    3. В открывшемся окне выберите окружение с вашим приложением и отметьте папку (или несколько папок), которые необходимо синхронизировать. Нажмите Установить.

    настройка синхронизации

    Не выбирайте всю папку webroot, в таком случае синхронизация не сработает.

    4. Подождите немного (около 2 минут) для применения настроек. Первым делом на серверах появятся файлы install.sh и replication.tar и папка lsyncd.



    5. После этого проверьте папку webroot > ROOT > wp-content на всех серверах приложений.
    Как Вы видите, ранее загруженное изображение расположено в папке uploads на каждой ноде.

    файлы синхронизированы

    Всё довольно просто. Как результат, синхронизация будет срабатывать автоматически каждый раз, когда вы добавляете или меняете что-либо в вашем WordPress (или любом другом) приложении.

    Сохранение синхронизации при изменении топологии


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

    1. Нажмите Изменить топологию окружения.

    изменить топологию

    2. Добавьте дополнительные сервера и Примените изменения.

    добавить сервера

    3. Выполните пункты 2-4 из раздела Настройка синхронизации файлов, чтобы наладить внутренние процессы синхронизации.

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

    Проверка логов


    За процессом синхронизации можно следить с помощью логов.

    1. Перейдите в папку webroot/lsyncd/var/log.

    2. Состояние синхронизации можно увидеть в файлах lsyncd.log и lsyncd.status.

    логи

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

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

    Lead Research Engineer,
    Alexey Alexandrov
    Jelastic 40,97
    Jelastic DevOps PaaS для хостеров и ISV
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 22
      +2
      Когда было 4 сервера для раздачи контента, использовали lsyncd для синхронизации, но когда серверов стало больше, то дальнейшее использование lsyncd стало дорогим по причине излишней избыточности. В итоге перешли на glusterfs.
        0
        Хочется иметь максимально гибкое решение. В нашем конкретном случае lsyncd идеально подходит для нас.
        +2
        Если серваки физически в одном месте (ДЦ), то лучше конечно сразу параллельную ФС замутить в качестве бэкенда и не мучаться со всеми этими синхронизациями.
          0
          Параллельная FS в контейнерах не всегда отрабатывает так как хочется. Также есть некоторые другие ограничения в том числе и синхронизация между площадками.
            0
            Параллельную ФС в качестве бэкенда вполне можно смонтировать на хост, а уж в контейнер просто прокинуть. Если речь идет о OVZ/LXC, то это просто mount bind. Между площадками дело обстоит хуже, согласен.
              0
              в случае с джеластиком — это не вариант, контейнеры ведь катаются из одной железяки на другую, потому жесткая привязка к хардварной ноде — не очень хорошее решение
                0
                В том-то и суть параллельных ФСок — они общие на ВСЕХ железных узлах, как одная общая сетевая шара, к которой подключен весь кластер железок. Так что сделать ремаунт при переезде имхо не большая проблема. Ну или я что-то не знаю о этих контейнерах.
                  0
                  ок, а если у Вас 50 000 клиентов? вы будете монтировать 50 000 шар пользователей на каждую железную ноду? ;)
                  а если таких нод у вас сотен три, смысл с такого тогда решения?
                    0
                    Шара одна. На ней папки. Монтирование автоматом в хуке виртуальной машине. Ну очевидные же вещи, е-мое. Три сотни нод совершенно не пугают если рулить не вручную.
                      0
                      Даже если шара всего одна — не все так просто, как Вы думаете, как я писал выше — ноды катаются из одной железки на другую, а это значит, что для того, чтоб переехать ноду — нужно скачала отмонтировать шару, перед тем освободить все занятые файловые дескрипторы (внезапно, в контейнере ресурсы, которые примонтированы, уже используются и могут читаться/писаться), потом вернуть назад, зачитать процессом по новой, опять же, при переезде ноды из одной железки на другую — никто не хендлит управление ресурсами, состояние контейнера хибернейтся в одном месте и восстанавливается в другом, процесс никуда не пропадает и никто не разрывает связь процесса с ресурсом, который он использует, еще одна проблема в том, что не всегда так нужно, чтоб у нод была идентична вся файловая система, иногда надо делить вещи на те, которые должны отличаться (в случае кластера) и те, которые должны быть одинаковы, уверен, что как-то это таки можно решить, но, как видите, подводных камней немного больше чем кажется на первый взгляд
                        0
                        Честно говоря не пробовал юзкейс с частой миграцией. Оно там само ездит или по требованию пользователя? Вообще, если делать живую миграцию, то сам образ виртуалки должен на параллельной ФС жить.
          0
          А какие препятствия для того, чтобы сработать по такому алгоритму
          ноды 1,2,… собираются в панели управления в «виртуальный кластер», у которого диск, где лежат файлы приложения общий?
          Чтобы было, в общем-то, не важно, какая нода хочет вон тот /var/www/mycoolcms/uploaded/mysupercat.jpg, и для всех было бы одинаковое место?

          В принципе ведь можно на уровне контейнера монтировать том data вооон с того url, как это сейчас реализовано в некоторых публичных облаках, когда у меня есть блоб с обьектами, я обращаюсь к нему в пределах моего *.coolcloud.com и моей cms. в общем-то без разницы, с какого хоста (геореплика в ближайший к юзеру цод, прозрачно даже для ноды, запрашивающей обьект) брать обьект с того блоба.

          Объясните отставшему от прогресса хайлоадных проектов линукс-админу обычного офисного прокси, пожалуйста.
            0
            В версии джеластика 2.0 (пока только доступна очень ограниченому количеству людей) это и так можно делать, примонтировав свой ресурс через fuse по webdav, используя ssh доступ в контейнер, этот вариант немного будет отличаться от варианта, который предложил divanikus т.к. монтирование будет изнутри контейнера, а не mount bind из хардноды в контейнер.
              0
              а. я бы предпочел внутри виртуалки на эту тему не париться, если у меня туда полный доступ. если у меня туда вебморда для контейнера какого-нить вордпреса без shell/ftp доступа как на фермах вроде wordpress.com, тогда мне таки без разницы, что там внутри. абы сайт отзывался
            0
            Зачем хранить и синхронизировать загруженные файлы на серверах приложения? Ведь WordPress прекрасно работает с сетевыми и распределенными хранилищами файлов, вроде NFS, MogileFS и пр. :)
              0
              Распределенные файловые системы не подходят, если у вас приложение находится в разных дата центрах (выше уже обсуждали).
                0
                WordPress.com хостится в 3-х разных дата-центрах, и распределенные файловые системы вполне подходят :)
                  0
                  Они у вас географически разделены? Один в Азии, второй в Европе, Третий в США ?)
                    0
                    Дата-центры разделены, правда (пока) не в Азии и не в Европе, но сути это не меняет. К тому же есть ноды Anycast которые выполняют функцию CDN на трех континентах.
                      0
                      В случае с NFS, у вас отвалится сервер, и ваша информация станет недоступна. Это единая точка отказа. Также в случае географической распределенности жутко будет тормозить. Anycast солюшены нам не подходят, так как мы разработчики платформы, а не хостинг провайдеры.
            0
            Тоже столкнулся с проблемой синхронизации загруженных пользовательских файлов и для себя решил хранить их в BLOB в БД. Интересно мнение хабрасообщество по поводу минусов такого решения.

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

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