Общая файловая система для серверов за балансировщиком нагрузки в стойке
Наше PHP-приложение состоит из единственного веб-сервера, который будет принимать файлы от клиентов и выполнять их анализ с интенсивным использованием процессора. Прямо сейчас анализ загрузки одного пользователя может занять 3 секунды для завершения и 100% загрузки ЦП. Это делает нашу систему емкостью 1/3 запросов в секунду.
Требование моей команды - увеличить пропускную способность без большого количества реинжиниринга кода. Возможным решением было бы настроить балансировщик нагрузки перед несколькими серверами, на которых запущено одно и то же приложение, и подключаться к общей БД. Проблема в том, что анализ выводит файлы на диск.
Балансировщик нагрузки увеличит емкость, но тогда файлы не будут доступны между серверами, поэтому последующие запросы клиентов могут завершиться сбоем. Мы размещены в Rackspace, есть ли способ настроить какое-то "общее" хранилище для всех серверов, без необходимости переписывать наш код персистентности файла? Текущий код опирается на простые fopens и т. Д. Какие у нас варианты?
4 ответа
GlusterFS обеспечит полный экспорт файловой системы POSIX, который можно подключить так же, как и большинство других локальных файловых систем. Он будет реплицироваться в заданной степени для избыточности, а в противном случае будет получать данные только по запросу. Пока каждый сервер настроен так, что созданные файлы имеют уникальные пути даже в скрытой ситуации, вы должны быть в очень хорошем положении.
Почему вы не монтируете Cloud Files на каждый сервер, используя CloudFuse?
Затем вы можете использовать облачные файлы в качестве общей файловой системы. Это не идеально для тяжелой работы ввода-вывода, но просто для произнесения и чтения иногда работает нормально, плюс вы можете затем подать файл из CDN
Если файлы никогда не попадают в БД, тогда да, вам нужна единая файловая система, используемая всеми веб-руководителями. Если файлы используются только во время пользовательского сеанса (сеанса, который загружает файл), вы можете использовать исходную ip или привязку к сеансу в балансировщике нагрузки, чтобы решить проблему без единой файловой системы.
Все балансировщики нагрузки поддерживают различные методы липкости. Балансировщик нагрузки F5 отличный, но в стойке также продается парча, которая стоит гораздо меньше.
Если вам нужно перейти к одной файловой системе, это потребует некоторой доработки, и есть несколько способов ее решения (например, одна из веб-глав может быть файловой системой, или сервером db, или новой выделенной системой, или облачная система хранения данных из стойки, AWS или другого).
НТН!
Какие последующие запросы понадобятся для доступа к файлу? Только один пользователь в этом сеансе входа в систему, один и тот же пользователь навсегда или кто-то еще? Если это один из первых двух вариантов, балансировщик нагрузки должен помочь.
Я считаю, что Rackspace предлагает сервис балансировки нагрузки на базе F5 BIG-IP. Постоянство сеанса (отправка пользователей обратно на один и тот же сервер для всего сеанса) должно быть вариантом в службе балансировки нагрузки. Я предполагаю, что вы говорите о HTTP-трафике, и в этом случае балансировщик нагрузки может внедрить файл cookie в сеанс и использовать его, чтобы убедиться, что клиент возвращается на тот же сервер, где находится его обработанный файл (файл cookie сеанса или время ограниченный).
Я не знаю, позволяет ли Rackspace клиентам использовать F5 iRules, но если они это сделают, вы даже сможете решить третий случай, если балансировщик нагрузки определит, на каком сервере размещается файл.