infobox Mar 11 2015 at 13:47

Высокая доступность веб-сайта: георепликация файлов сайта с lsyncd

6 min

13K

Infobox corporate blog

Comments 23

DLag Mar 11 2015 at 15:01

lsyncd — это уже георепликация?
Надо ребятам новую шутку рассказать.

infobox Mar 11 2015 at 15:17

Да, это репликация. Репликация — механизм синхронизации содержимого нескольких копий объекта. Репликация — это процесс, под которым понимается копирование данных из одного источника на другой (или на множество других) и наоборот. Репликация данных подразумевает сохранение копии данных на нескольких устройствах хранения. Отличается от резервного копирования тем, что данные на устройствах хранения не являются неизменяемыми и обновляются.

DLag Mar 11 2015 at 15:25

Т.е. можно ждать статьи о локальной репликации с использованием cp? ))
На Хабре уже были статьи про lsyncd.
Поисками бы.

infobox Mar 11 2015 at 15:25

Это статья об обеспечении отказоустойчивости статического сайта, а не просто об lsyncd. Простые задачи надо решать просто.

DLag Mar 11 2015 at 15:27

А заголовке написано «георепликация файлов сайта с lsyncd».

infobox Mar 11 2015 at 15:29

Да, именно это и происходит для файлов сайта, размещенных в файловой системе. Есть разные подходы: можно использовать DRBD или GlusterFS/Ceph, но автор рассмотрел подход с lsyncd

DLag Mar 11 2015 at 15:34

Ну я же говорю, про lsyncd уже было.
habrahabr.ru/post/132098/

infobox Mar 11 2015 at 15:37

Если вы внимательно прочитаете статью — увидите, что даже в этой статье есть ссылка на указанную вами статью. Но эта статья про конкретный случай применения lsyncd, а не про «синхронизацию миллиарда файлов». Есть молоток, он практически одинаковый у всех. Но им можно как гвозди забивать так и стучать по стаместке. Это разные применения одного инструмента, которые объединяет то, что молотком можно стучать.

motienko Mar 11 2015 at 17:09

Вроде бы такие задачи давно уже решают с помощью nginx c proxy_store на обработчик 404 ошибки или даже просто proxy_cache. Ну и смешанная схема — proxy_store и периодический запуск rsync.

infobox Mar 11 2015 at 17:15

это как раз вaриант периодического запуска rsync. Сервер с nginx – это тоже точка отказа, надо несколько балансировщиков, а еще желательно с Virtual IP. Усложнять много куда можно, это еще будет рассматриваться в последующих статьях.

drunken Mar 11 2015 at 15:55

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

infobox Mar 11 2015 at 16:00

Вчера было установлено мажорное обновление облачной платформы до версии 6.0.1 (ранее была 5.5), что исправило многие проблемы и ускорило работы панели управления в разы. Продолжаем улучшать облако и исправлять найденные ошибки. Будем рады отзывам на feedback@infobox.ru.

Ingtar Mar 11 2015 at 21:55

Бегло просмотрел статью, но так и не понял, какую задачу вы решаете этим самым lsyncd?.. Просто синхронизируете файлы на двух машинах? В этом случае не имеются в виду файлы пользователей, базы, прочее? Просто «Hello, Word»?
У вас есть опыт такой «репликации» действительно нагруженного сайта, где фронты синхронизируются именно такой схемой?

infobox Mar 11 2015 at 22:25

Да, задача lsyncd держать файлы сайтов синхронизировано на нескольких машинах, когда целостность данных важна, но не критична. Рассматриваются только файлы сайта, базы надо реплицировать средствами БД. Под действительно нагруженным сайтом можно понимать разное. У нас есть живые пользователи, которые используют подобную схему, но если вы планируете использовать ее для нагруженного сайта — необходимо предварительное тестирование в любом случае. У нас каналы широкие, поэтому работать должно неплохо. Но для больших нагрузок рекомендуется придумывать более хитрую схему, в которой максимум реплицировать по внутренней сети дата-центра, а между регионами реже, и использовать горизонтальное масштабирование.

knutov Mar 12 2015 at 00:10

infobox, вы ведь в курсе как Lsyncd работает когда файлов сотни тысяч (и как при этом работает сервер)?

А это, например, обычная ситуация для простого сайта на битриксе с включенным кешем на диске.

wscms Mar 12 2015 at 01:43

Я думаю, что в курсе. Основная цель статьи выделена жирным

Закажите 2 подписки на InfoboxCloud в Москве и Амстердаме для создания геораспределенного решения.

infobox Mar 12 2015 at 08:37

Кеш на диске не надо реплицировать в другой регион.

mrThe Mar 12 2015 at 12:40

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

Я бы не доверил lsyncd синхронизацию бд, а вот синхронизация конфигов и ассетов — это как раз то, что он умеет лучше всего.

Pilat Mar 12 2015 at 15:52

У меня к lsyncd ещё одно замечание. Предположим, всё настроили. Обновили 100500 файлов — не важно сколько. И вроде пошёл процесс. Идёт неизвестно сколько, вторая система то-ли синхронизирована, то-ли нет, порядок обновления файлов, который выберет lsyncd непредсказуем. Время синхронизации тоже неизвестно — может соединение будет медленное или глючное. Может быть дынтсв почему-то возьмёт и зависнет. То есть полностью непредсказуем процесс реплицирования.

infobox Mar 12 2015 at 18:41

У lsyncd есть логи, можно проанализировать их при необходимости.

Pilat Mar 12 2015 at 19:03

И что? Это поможет решить описанные проблемы? Разве что понять, почему со счёта клиента улетел миллион рублей.

infobox Mar 12 2015 at 19:15

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

Pilat Mar 12 2015 at 20:16

Ну что-то им можно, конечно, синхронизировать, но «синхронизация конфигов и ассетов — это как раз то, что он умеет лучше всего» — это опасное преувеличение.