У меня есть веб-сайт, который получает около 7 тысяч запросов в секунду на сервере nginx. Этот сервер обрабатывает перезапись на сервер Apache, а также напрямую обслуживает статические файлы, изображения и т. Д. Статические файлы - это самая большая часть, около 5k запросов.
При обновлении архитектуры я думаю об использовании центрального файлового сервера, который экспортирует каталог, содержащий эти статические файлы, через NFS. К этим файлам не будет доступа для записи, поэтому каталог можно будет смонтировать на машине nginx только для чтения. Меня больше всего беспокоит:
Достаточно ли быстр NFS для этого? Есть ли ограничение на количество запросов, которые может обработать NFS? Есть ли какие-то «обязательные» варианты, когда вы идете по этому пути?
Бонус: есть ли другие альтернативы этой настройке, кроме NFS?
Спасибо!
я использую cachefilesd (и недавнее ядро Linux с cachefs) для кэширования файлов NFS на локальный жесткий диск. Таким образом, каждое чтение в nfs будет копировать файл в каталог / var / cache / fs, и следующие чтения будут доставляться оттуда, при этом ядро проверяет в nfs, является ли содержимое все еще действительным.
Таким образом, у вас может быть центральная NFS, но без потери производительности локальных файлов.
Cachefilesd позаботится об очистке старых файлов, когда свободный размер / индексные дескрипторы достигнут настроенного уровня, чтобы вы могли обслуживать необычные данные из NFS и общие запросы с HD.
Конечно, можно также использовать лак для кеширования наиболее распространенных запросов и уберечь nginx / NFS от обслуживания.
Вот это небольшой файл кеша
Устанавливая центральный сервер NFS, вы вводите единую точку отказа в своем проекте. Уже одно это должно стать препятствием для сделки. В противном случае NFS может быть достаточно быстрой для такой нагрузки. Критическими факторами будут наличие достаточного количества ОЗУ для кэширования файлов, межсоединений с низкой задержкой (Gig-E или лучше) и настройки (меньше, чем в предыдущем случае).
Вам также следует настоятельно рассмотреть возможность использования rsync или аналогичного инструмента для хранения локальных копий обновлений статических файлов на каждом отдельном веб-сервере. Другим вариантом может быть SAN или резервный сервер NFS (оба варианта будут намного сложнее и дороже, чем идея rsync).
Скорость зависит от многих факторов:
Ограничение числа открытых файлов через NFS - это ограничение операционной системы хоста. Например, FreeBSD имеет множество различных параметров настройки для поддержки большой количество открытых файлов, но это зависит от объема оперативной памяти на вашем сервере.
Альтернативой центральному файловому серверу является использование синхронизации / репликации между вашими веб-серверами (как предлагает Крис С.). rsync или DRBD могут быть отличным и экономичным выбором.
Я бы посоветовал не использовать NFS, если вы не добавили туда кеширование. Кеш nginx лучше, чем ничего, но Varnish лучше.
С учетом сказанного, если ваша нагрузка изменится на более динамический контент, чем статический, станет более важным обслуживать файлы приложений с локального диска.
Если вы устанавливаете NFS, убедитесь, что у вас есть избыточность.