У нас есть несколько веб-серверов Linux за аппаратным балансировщиком нагрузки, которые обслуживают один веб-сайт.
Возникла необходимость для посетителей загружать файлы. Обычно файлы имеют размер 300-700 КБ, и мы ожидаем, что их будет около 1 миллиона. Однако это создает очевидную проблему: если пользователь загружает файл на сервер, обрабатывающий его запрос, как мы можем синхронизировать все серверы?
Задержка должна быть минимальной, поэтому использование чего-то вроде rsync по заданному расписанию на самом деле не вариант. Также не должно быть единой точки отказа, поэтому NFS не будет подходящим, если он не будет объединен с DRBD для создания отказоустойчивого сервера NFS.
Я изучал общие / кластерные файловые системы (GlusterFS, MogileFS, OCFS2 и GFS), но у меня нет опыта в этом, поэтому я не уверен, как они работают в производственной среде с точки зрения производительности и надежности.
Я приветствую любые советы относительно того, как лучше всего решить эту проблему.
Большое спасибо
GFS2 / OCFS2 через DRBD позволяет паре серверов использовать двойной первичный сервер в качестве кластерного хранилища. Ваши веб-интерфейсы будут использовать эту общую пару. У вас может быть несколько головок, совместно использующих один подключенный к FC носитель, используя либо, либо можно использовать NFS, чтобы иметь единую общую файловую систему, используемую каждым из веб-интерфейсов. Если вы используете NFS с DRBD, помните, что вы можете запускать это только в основном / дополнительном режиме из-за отсутствия блокировок кластера. Это может снизить вашу потенциальную пропускную способность вдвое.
GlusterFS больше похож на то, что вы ищете. У него будут некоторые уникальные особенности, то есть файл, запрошенный на узле, у которого его еще нет, поиск метаданных говорит, что он есть, он передается с одного из реплицированных узлов и затем обслуживается. Первый запрос на узле будет иметь некоторое отставание в зависимости от размера файла.
OpenAFS - это еще одна возможность. У вас есть общее хранилище, каждый локальный ресурс имеет локальный пул недавно использованных элементов. Если механизм хранения выходит из строя, ваши локальные пулы ресурсов продолжают работать.
HDFS Hadoop - еще одна альтернатива, которая просто «работает». Немного сложно настроить, но он также будет соответствовать вашим требованиям. При использовании распределенной файловой системы у вас будет много дублированного контента.
Еще один «грязный» метод - запускать кеши на каждом из ваших веб-интерфейсов, которые извлекают статический / загруженный контент с одного компьютера и используют Varnish на каждом из интерфейсов для поддержки кэшированной в оперативной памяти версии вашей единственной копии. Если ваша единственная машина выйдет из строя, Varnish будет кэшировать существующие элементы до льготного периода, новые элементы будут потеряны.
Во многом это будет зависеть от того, насколько надежный бэкэнд вам нужен. Распределенные файловые системы, в которых ваши локальные машины являются реплицирующим узлом, вероятно, будут иметь преимущество в скорости, поскольку они не требуют сетевых операций для получения данных, но с дешевыми картами gigE и 10G вы, вероятно, не испытаете значительной задержки .
Все кластерные файловые системы имеют одну центральную слабость: если определенный процент систем отключается, то вся файловая система становится бесполезной, но узлы, которые все еще работают, могут не справиться с этим должным образом.
Например, предположим, что у вас есть 30 серверов в стойке и вы хотите совместно использовать их локальное пространство. Вы создаете кластерную файловую систему и даже строите ее так, что если только один узел выходит из строя, данные реплицируются на достаточное количество других узлов, так что проблем не возникает. Все идет нормально. Затем умирает карта в коммутаторе Ethernet. Этот коммутатор соединяет все узлы в вашем кластере. Карта отключает связь с 15 из 30 ваших узлов. Вам нужно задать себе следующие вопросы:
Подумайте на пару шагов вперед и что система будет делать в случае отказа любой основной компонент, включая сетевые или силовые кабели.
Теперь вы готовы к кластерной файловой системе и к миллиону новых жаргонных слов, которых вы раньше не знали.
Мы используем либо NFS из боксов NetApp, либо тома OCFS2 из FC LUN, я не знаю, являются ли они лучшими вариантами, но они работают для нас годами. Безусловно, оба работают совершенно адекватно, хотя я лично предпочитаю OCFS2, а не FC LUN, поскольку на самом деле я больше разбираюсь в хранилищах. Я полагаю, это действительно сводится к тому, какая инфраструктура общего хранилища у вас уже есть и удобна.