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

[DLag]

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

[infobox]

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

[DLag]

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

[infobox]

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

[DLag]

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

[infobox]

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

[DLag]

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

[infobox]

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

[motienko]

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

[infobox]

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

[drunken]

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

[infobox]

Вчера было установлено мажорное обновление облачной платформы до версии 6.0.1 (ранее была 5.5), что исправило многие проблемы и ускорило работы панели управления в разы. Продолжаем улучшать облако и исправлять найденные ошибки. Будем рады отзывам на [e-mail].

[Ingtar]

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

[infobox]

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

[knutov]

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

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

[wscms]

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

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

[infobox]

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

[mrThe]

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

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

[Pilat]

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

[infobox]

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

[Pilat]

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

[infobox]

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

[Pilat]

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