Нужен вклад, и если кто-то преодолел эту проблему с помощью решения, в котором он уверен.
Хотите настроить отказоустойчивую веб-среду. Таким образом, установка - это несколько узлов за балансировщиком нагрузки. Теперь веб-разработчики могут использовать ssh на одном сервере для редактирования кода и тому подобного.
Я думаю о glusterfs, но установка файловой системы glusterfs в качестве корня документа приводит к уменьшению количества страниц, которые может обслуживать веб-сервер, примерно на 20-30%. Я ожидаю этого, потому что я использую только Ethernet, а не инфибанду или что-то подобное.
Итак, я думал об использовании glusterfs + inotify. Итак, у меня запущен скрипт inotify, который отслеживает изменения в docroot и gluster, а также выполняет rsync для этого файла / каталога, который изменяется. Таким образом, apache может работать с локального диска, а не с gluster, но дает эффект, что он обслуживается через кластерную файловую систему.
Моя единственная проблема с этим заключается в том, что мне нужно запустить 2 сценария inotify и для количества файлов, которое мы запускаем, чтобы добавить всех наблюдателей inotify, которые я использовал бы для них обоих около 700 мегабайт ОЗУ.
Итак, у кого-нибудь есть советы или указатели?
Спасибо!
РЕДАКТИРОВАТЬ
Думайте об этом как о веб-хостинге. Клиенты ssh на 1 сервер, но файлы, которые они создают / редактируют / удаляют, находятся на всех других узлах
Обратное также должно быть правдой. Если веб-сервер создает файлы, они также должны быть на всех узлах.
Так что это вызывает прямой rsync, поскольку он слишком медленный.
Прочтите комментарий @Zypher. Читайте его снова и снова, пока не поймете мудрость этих слов, не увидите свет и не прогоните своих разработчиков с рабочих серверов в подходящую песочницу.
Можешь одолжить мою заостренную палку. :-)
Перефразируя ваш вопрос в этом свете: «Как сохранить согласованность кода на моих веб-серверах?».
Ответ: кукольный (или Повар), радость, или любую из множества замечательных систем конфигурации / развертывания.
Эти инструменты дают вам гораздо более простой способ достижения вашей цели, занимают намного меньше ОЗУ / ЦП и могут быть настроены так, чтобы гарантировать согласованность на всех ваших узлах.
Эта часть ответа удалена на основании редактирования исходного вопроса.
На самом деле есть только одно решение для вас, о котором я могу думать, и это SAN (или устройство NAS, обслуживающее файлы через NFS).
Причина, по которой я предлагаю этот путь, заключается в том, что вам нужно, чтобы файлы, созданные каждым из серверов, были доступны всем остальным. Выполнение массивной N-сторонней синхронизации станет громоздким и медленным. Централизация SAN обеспечит лучшую производительность, хорошую избыточность (SAN довольно надежны, если вы не удешевите) и возможность легко масштабироваться по мере роста ваших потребностей.
У него есть и недостатки: если вы не создадите пару зеркальных, избыточных сетей SAN с избыточной структурой, вы создадите единую точку отказа. Сети SAN также недешевы, а избыточность только увеличивает расходы.
Обратите внимание: ничто из этого не устраняет необходимость держать разработчиков подальше от производственной коробки, если вы не гарантируете, что они никогда не позвонят вам, когда что-то сломают. По крайней мере, ты должен быть настоятельно рекомендую что они арендуют у вас среду разработки (очевидно, с разумной прибылью - что-то, чтобы помочь оплатить стоимость SAN ...)
Ого, у меня есть воспоминания о прошлой работе, где GFS использовалась для точного обоснования, которое вы описываете. Сценарий: более 2000 клиентов запускают свои приложения в нескольких крупномасштабных облаках.
По сути, вы не можете делать то, что думаете, что хотите. Вы не можете получить кластерную или сетевую файловую систему, которая будет работать со скоростью, близкой к скорости локальной файловой системы. Позвольте мне подчеркнуть это на секунду: НЕ МОЖЕТ. Если вы думаете, что можете, вы обманываете себя. Если кто-то другой говорит, что может, он лжет. Это простая математика: скорость диска + контроллер ввода-вывода + задержка сети + кластерный фу должен быть больше, чем скорость диска + IO контроллера.
Теперь перейдем к причинам, по которым вы можете это построить, и почему то, что вы хотите делать, бесполезно:
Теперь, когда я был отрицательно на экране или около того, что жестяная банка вы делаете? Что ж, это в основном сводится к оказанию помощи вашим клиентам на индивидуальном уровне.
Вы не можете создать универсальную хостинговую инфраструктуру для безграничных масштабов. Это то, что пытался сделать мой бывший работодатель, любивший GFS, и, судя по всему, тогда это не сработало, и я уверен, что это невозможно сделать с помощью доступных в настоящее время технологий разработки и эксплуатации.
Вместо этого уделите немного времени оценке требований ваших клиентов и помогите им найти решение, отвечающее их требованиям. Вам не обязательно проводить полный анализ каждого клиента; после первых нескольких вы (надеюсь) начнете замечать появление шаблонов, которые направят вас к ряду «стандартных» решений. Он принимает следующий вид: «Хорошо, у вас есть требования F, P и Aleph-1, поэтому вам лучше всего выбрать решение ZZ-23-plural-Z-alpha» - и вот наш исчерпывающий набор документации по развертыванию этого решения. , а наши цены на индивидуальные консультации по этому решению, если вы не можете реализовать его самостоятельно, указаны внизу ".
Что касается подробностей, их слишком много, чтобы перечислить, но я дам вам несколько советов: