Comments 22
Когда было 4 сервера для раздачи контента, использовали lsyncd для синхронизации, но когда серверов стало больше, то дальнейшее использование lsyncd стало дорогим по причине излишней избыточности. В итоге перешли на glusterfs.
Если серваки физически в одном месте (ДЦ), то лучше конечно сразу параллельную ФС замутить в качестве бэкенда и не мучаться со всеми этими синхронизациями.
Параллельная FS в контейнерах не всегда отрабатывает так как хочется. Также есть некоторые другие ограничения в том числе и синхронизация между площадками.
Параллельную ФС в качестве бэкенда вполне можно смонтировать на хост, а уж в контейнер просто прокинуть. Если речь идет о OVZ/LXC, то это просто mount bind. Между площадками дело обстоит хуже, согласен.
в случае с джеластиком — это не вариант, контейнеры ведь катаются из одной железяки на другую, потому жесткая привязка к хардварной ноде — не очень хорошее решение
В том-то и суть параллельных ФСок — они общие на ВСЕХ железных узлах, как одная общая сетевая шара, к которой подключен весь кластер железок. Так что сделать ремаунт при переезде имхо не большая проблема. Ну или я что-то не знаю о этих контейнерах.
ок, а если у Вас 50 000 клиентов? вы будете монтировать 50 000 шар пользователей на каждую железную ноду? ;)
а если таких нод у вас сотен три, смысл с такого тогда решения?
а если таких нод у вас сотен три, смысл с такого тогда решения?
Шара одна. На ней папки. Монтирование автоматом в хуке виртуальной машине. Ну очевидные же вещи, е-мое. Три сотни нод совершенно не пугают если рулить не вручную.
Даже если шара всего одна — не все так просто, как Вы думаете, как я писал выше — ноды катаются из одной железки на другую, а это значит, что для того, чтоб переехать ноду — нужно скачала отмонтировать шару, перед тем освободить все занятые файловые дескрипторы (внезапно, в контейнере ресурсы, которые примонтированы, уже используются и могут читаться/писаться), потом вернуть назад, зачитать процессом по новой, опять же, при переезде ноды из одной железки на другую — никто не хендлит управление ресурсами, состояние контейнера хибернейтся в одном месте и восстанавливается в другом, процесс никуда не пропадает и никто не разрывает связь процесса с ресурсом, который он использует, еще одна проблема в том, что не всегда так нужно, чтоб у нод была идентична вся файловая система, иногда надо делить вещи на те, которые должны отличаться (в случае кластера) и те, которые должны быть одинаковы, уверен, что как-то это таки можно решить, но, как видите, подводных камней немного больше чем кажется на первый взгляд
А какие препятствия для того, чтобы сработать по такому алгоритму
ноды 1,2,… собираются в панели управления в «виртуальный кластер», у которого диск, где лежат файлы приложения общий?
Чтобы было, в общем-то, не важно, какая нода хочет вон тот /var/www/mycoolcms/uploaded/mysupercat.jpg, и для всех было бы одинаковое место?
В принципе ведь можно на уровне контейнера монтировать том data вооон с того url, как это сейчас реализовано в некоторых публичных облаках, когда у меня есть блоб с обьектами, я обращаюсь к нему в пределах моего *.coolcloud.com и моей cms. в общем-то без разницы, с какого хоста (геореплика в ближайший к юзеру цод, прозрачно даже для ноды, запрашивающей обьект) брать обьект с того блоба.
Объясните отставшему от прогресса хайлоадных проектов линукс-админу обычного офисного прокси, пожалуйста.
ноды 1,2,… собираются в панели управления в «виртуальный кластер», у которого диск, где лежат файлы приложения общий?
Чтобы было, в общем-то, не важно, какая нода хочет вон тот /var/www/mycoolcms/uploaded/mysupercat.jpg, и для всех было бы одинаковое место?
В принципе ведь можно на уровне контейнера монтировать том data вооон с того url, как это сейчас реализовано в некоторых публичных облаках, когда у меня есть блоб с обьектами, я обращаюсь к нему в пределах моего *.coolcloud.com и моей cms. в общем-то без разницы, с какого хоста (геореплика в ближайший к юзеру цод, прозрачно даже для ноды, запрашивающей обьект) брать обьект с того блоба.
Объясните отставшему от прогресса хайлоадных проектов линукс-админу обычного офисного прокси, пожалуйста.
В версии джеластика 2.0 (пока только доступна очень ограниченому количеству людей) это и так можно делать, примонтировав свой ресурс через fuse по webdav, используя ssh доступ в контейнер, этот вариант немного будет отличаться от варианта, который предложил divanikus т.к. монтирование будет изнутри контейнера, а не mount bind из хардноды в контейнер.
Зачем хранить и синхронизировать загруженные файлы на серверах приложения? Ведь WordPress прекрасно работает с сетевыми и распределенными хранилищами файлов, вроде NFS, MogileFS и пр. :)
Распределенные файловые системы не подходят, если у вас приложение находится в разных дата центрах (выше уже обсуждали).
WordPress.com хостится в 3-х разных дата-центрах, и распределенные файловые системы вполне подходят :)
Тоже столкнулся с проблемой синхронизации загруженных пользовательских файлов и для себя решил хранить их в BLOB в БД. Интересно мнение хабрасообщество по поводу минусов такого решения.
Sign up to leave a comment.
Синхронизация файлов между серверами в кластере