Масштабирование веб-серверов, подключенных к NFS, и онлайн-хранилища файлов
Итак, несколько месяцев назад мой босс бросил мне вызов, «что нам нужно для масштабирования до X клиентов за достаточно короткий период времени». своего рода сценарии, что-то вроде инженерной задачи, но, конечно, больше клиентов означает больший доход.
Итак, сейчас у нас есть установка, аналогичная приведенной ниже. Резервные балансировщики нагрузки, обслуживающие данные с двух веб-серверов (сеансы совместно используются через memcache), и двух полностью резервных серверных файловых серверов. У каждого файлового сервера есть весь шабанг, массив RAID6 на дисках, диск с горячим пространством, двойные контроллеры рейда, двойные сетевые адаптеры, многопутевый режим yada yada yada.
Дизайн, который я считаю надежным, обеспечивает высокую доступность без единой точки отказа. Высокая производительность за счет разделения нагрузки на несколько веб-серверов, высокая масштабируемость в том смысле, что мы должны иметь возможность просто добавлять все больше и больше машин по горизонтали для масштабирования для все большего количества клиентов. Основным узким местом является объем хранилища, который может вместить каждый файловый сервер, и количество места, выделенного каждому клиенту. Эта часть будет масштабироваться быстрее, чем остальная часть системы. Маршрут «Пулы» FileServer / Client был выбран потому, что он масштабируется по горизонтали и дешевле, чем сказать «хорошо, нам нужно купить еще БОЛЬШЕ SAN».
Так что все это очень просто, все больше и больше онлайн-хранилищ означает все больше и больше монтирований NFS. И здесь в игру вступают мои предположения. Я хочу убедиться, что я устранил все потенциальные проблемы в этом дизайне, прежде чем что-то делать. Я считаю, что до тех пор, пока каждая часть этой головоломки должным образом отслеживается, ее можно контролировать, но сначала я хотел получить другие мнения, возможно, от людей, которые уже проходили этот путь раньше.
Я знаю несколько ключевых проблем, за которыми нужно будет следить.
- Горячие точки на файловых серверах или определенных машинах, работающих с большей нагрузкой, чем остальная часть пула.
- Полоса пропускания и внутренняя коммутация. Поскольку между веб-серверами и устройствами NFS будет много разговоров, необходимо наличие высококачественного коммутатора с высокой пропускной способностью коммутационной фабрики.
Неизвестные проблемы ...
- NFS монтируется на веб-серверах, Будут ли какие-либо проблемы с тем, что на каждом веб-сервере будет открыто 2 ... 5 ... 10 ... 100 монтирований NFS в любой момент времени? Есть ли способ сделать это проще или удобнее? Может NFS Proxy какой-то? (это создало бы внутреннее горлышко бутылки, что заставляет меня хмуриться). Я подумал о распределенной файловой системе, и веб-серверы просто смонтируют ее, однако кажется, что несобственнические, POSIX-совместимые, расширяемые без простоев, внутренне избыточные файловые системы либо слишком незрелы для производственной работы, либо чрезмерно дороги, либо действительно хорошо скрывается от Google.
Дайте мне знать, что вы думаете, и если вы увидите какие-либо предложения и оптимизации, мы будем очень признательны.
((Поскольку это открытый вопрос, на который нет одного конкретного «правильного ответа», вопрос - это Wiki сообщества))
В 90% случаев хостинга, с которыми вы столкнетесь, у вас будет гораздо больше веб-серверов, чем серверов хранения, что немного меняет структуру вашей сети. Вы будете запускать серверы хранения парами, так как многие первичные / первичные файловые серверы не поддерживают больше, чем зеркальную репликацию. Большие серверы NFS, скорее всего, будут обрабатывать около десятка веб-серверов, если у вас магистраль 10g. Ваши соединительные линии будут виртуальными, поскольку вы будете запускать веб-локальную сеть на одном vlan, сеть хранения на отдельном vlan, gigE для веб-локальной сети, 10g для локальной сети хранения в зависимости от бюджета. Вы упоминаете два основных сервера хранения, а затем упоминаете подключения NFS, которые в некоторой степени исключают. Действительно ли они работают без общего доступа или это установка с двумя головками / двумя полками / одним фкалом?
Запустите ваши балансировщики нагрузки в режиме двойного основного, чтобы сократить время переключения и увеличить потенциальную пропускную способность. Не используйте более 40% их емкости, чтобы у вас было достаточно запасных на случай отказа.
Вам также необходимо учитывать кластеры MySQL / PostgreSQL / Cassandra / etc - они не особенно любят монтирование NFS.
Lefthand Networks имеет продукт с распределенной файловой системой. GlusterFS довольно зрелая и будет работать в зависимости от вашей рабочей нагрузки. MogileFS / Hadoop - еще одна возможность. Также обратите внимание на Ceph, GFS и OCFS.
Что касается количества подключений, вы подключите каждый сервер NFS один или, возможно, два раза на каждый веб-сервер. Десятки монтировок не будут чем-то неслыханным, но в конечном итоге вы можете разделить свои веб-кластеры, чтобы избавиться от сотен монтировок. Hadoop может представить себя в вашей сети как единую глобальную файловую систему в распределенной сети.
Как вы реплицируете данные по узлам хранения? Я предполагаю, что у вас есть Apache, обслуживающий ваш веб-контент из того же каталога на узлах хранения ...
Мы работаем над созданием чего-то похожего, но я довольно разочарован, пытаясь найти способ репликации данных без задержек между узлами хранения.
Идеи?
Вы можете подумать о написании собственной системы каталогов для хеширования файлов в разные кластеры файловой системы и использовать http / https для передачи файлов с отдельных серверов. Таким образом, масштабирование сводится к добавлению дополнительных «веб-серверов», и вам не нужно беспокоиться о том, что каждый сервер поддерживает соединение со всеми возможными серверами хранения. Это немного менее эффективно, но значительно упрощает настройку. Поскольку вы поддерживаете карту расположения файловой системы и можете хранить данные в двух или более отдельных парах файловых серверов, вы можете просто выполнить внутренний HTTP-запрос для получения файла / файлов по запросу. Ваши пары будут разделены как физически, так и топологически сети, так что потеря всей стойки не приведет к потере обоих модулей вашей пары. Это позволит вам использовать системы, которые не требуют такой большой конфигурации программного обеспечения из коробки, но потребуют от вас написания большего количества кода для управления вашей распределенной файловой системой.
SuperMicro и несколько других производителей делают шасси 4U (SC847), которые обрабатывают 36 3,5-дюймовых внешних накопителей / дисков с горячей заменой. В сочетании с FreeBSD / OpenSolaris вы можете использовать ZFS (что было бы очень полезно, если вы собираетесь использовать стандартные диски).
Поскольку вы выполняете резервное копирование данных, действительно ли необходимо иметь совместимую с posix серверную часть, которая поддерживает блокировку кластера? Могут ли клиенты конкурировать за доступ к одному и тому же файлу? В противном случае подойдет любая распределенная файловая система, которая поддерживает все как единое монтирование. В то время как наши резервные копии внутренне rsync с исходных машин, клиентские запросы на копии файлов из резервных копий обслуживаются с помощью http.
GlusterFS, MogileFS или HDFS также предоставят вам одну точку монтирования для каждого из веб-серверов. Это позволит вам получить доступ к данным более традиционным способом, но вы потеряете некоторые из «функций» posix.
Чтобы объяснить, почему в приведенном выше проекте больше файловых серверов, чем веб-серверов, система, о которой Grufftech (я работаю с ним), представляет собой онлайн-службу резервного копирования как для потребителей, так и для предприятий (резервное копирование настольных компьютеров и серверов).
Как сказал Кармавхор, наличие большего количества файловых серверов, чем веб-серверов, звучит довольно нестандартно. Не могли бы вы немного подробнее объяснить использование?
Из ваших рисунков Visio и вашего описания я не могу понять, где у вас нет единой точки отказа, когда дело касается файлов. Мне кажется, что каждый сервер NFS имеет собственное подмножество файлов?
Вам, вероятно, следует подумать о создании «толстых» (то есть очень тяжелых) файловых серверов с тоннами оперативной памяти и использования на ней какой-то кластеризованной или зеркальной файловой системы, начиная с 2-х серверов NFS и затем масштабируясь с шагом 2. Возможно http://www.drbd.org/ мог бы работать на вас?
Пример:
NFSA_1 <--> NFSA_2 NFSB_1 <--> NFSB_2