Назад | Перейти на главную страницу

Резервирование файловой системы + скорость

Нужен вклад, и если кто-то преодолел эту проблему с помощью решения, в котором он уверен.

Хотите настроить отказоустойчивую веб-среду. Таким образом, установка - это несколько узлов за балансировщиком нагрузки. Теперь веб-разработчики могут использовать 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 контроллера.

Теперь перейдем к причинам, по которым вы можете это построить, и почему то, что вы хотите делать, бесполезно:

  • Простота развертывания: Нелегко развернуть на одной машине и автоматически запускать везде, потому что - получите это - это не одна машина, на которой вы развертываете. Конечно, вы можете подумать, что удобно копировать только один экземпляр кода, но есть множество вещей, которые нужно делать для каждого сервера приложений в различных ситуациях. Во многих случаях, с которыми мне лично приходилось иметь дело, установка на общую файловую систему в конечном итоге усложняла процесс развертывания, чем он мог бы быть. Правильный ответ на вопрос «как выполнить развертывание на нескольких машинах» - «автоматизировать развертывание».
  • Кластеризация для надежности: Для меня это почти шутка. Современное оборудование настолько надежно, а технологии кластеризации настолько ненадежны, что кластеризация (особенно кластеризация файловых систем) УВЕЛИЧЕНИЕ ваше время простоя. У меня достаточно данных для официального документа по этой теме. Некоторые люди скажут: «У меня EMC SAN уже четыре года работает без перебоев в производстве», но сколько они заплатили за такую ​​надежность? Я никогда не слышал, чтобы кто-то мог получить такую ​​надежность менее чем за 7 цифр (на основе совокупной стоимости владения), и там тоже было много затрат на экспертизу. Тот факт, что вы задаете этот вопрос, говорит о том, что не обладаете этим опытом, и держу пари, что вы тоже не собираетесь записывать семизначные суммы.
  • Кластеризация по мощности: Это восходит к моим начальным утверждениям - любая кластерная файловая система работает медленнее, чем локальная. Попытка добиться высокой производительности из кластерной или сетевой файловой системы - безнадежная причина. Это сведет вас с ума (это определенно помогло мне).

Теперь, когда я был отрицательно на экране или около того, что жестяная банка вы делаете? Что ж, это в основном сводится к оказанию помощи вашим клиентам на индивидуальном уровне.

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

Вместо этого уделите немного времени оценке требований ваших клиентов и помогите им найти решение, отвечающее их требованиям. Вам не обязательно проводить полный анализ каждого клиента; после первых нескольких вы (надеюсь) начнете замечать появление шаблонов, которые направят вас к ряду «стандартных» решений. Он принимает следующий вид: «Хорошо, у вас есть требования F, P и Aleph-1, поэтому вам лучше всего выбрать решение ZZ-23-plural-Z-alpha» - и вот наш исчерпывающий набор документации по развертыванию этого решения. , а наши цены на индивидуальные консультации по этому решению, если вы не можете реализовать его самостоятельно, указаны внизу ".

Что касается подробностей, их слишком много, чтобы перечислить, но я дам вам несколько советов:

  • Разверните код на каждом сервере приложений индивидуально.
  • Если вам действительно нужно использовать общие динамические ресурсы, используйте NFS. Это глупо просто, и у него самый низкий уровень поломки. Обратите внимание, что я сказал, что поделился АКТИВЫ - не код, не конфигурация, не логи, а только предоставленные заказчиком активы.
  • Однако NFS не масштабируется вечно (несмотря на пропаганду NetApp); в какой-то момент вашим клиентам нужно будет перейти на что-то другое (пример чего я дано раньше), и вы можете помочь им перейти к более масштабируемому решению с хорошей документацией и другой готовой помощью.
  • Если вы думаете, что это может быть бизнес по принципу «пустил и забыл», вы ошибаетесь. У вас есть стандартный веб-хостинг (со всеми достоинствами - низкие эксплуатационные расходы - и недостатками - без наценки - что подразумевается) и специализированный веб-хостинг (что вы и пытаетесь сделать), и последнее требует высоких затрат (но с соответственно высокой маржой).