Это разумный способ масштабирования Nginx для обслуживания статического контента?
Мне нужно настроить несколько VPS для обслуживания статического контента (много маленьких файлов). Я планирую использовать Nginx для этого и хотел бы настроить его так, чтобы мы могли относительно легко масштабироваться. Требования следующие:
- Много файлов (не менее сотен тысяч).
- Небольшие размеры файлов (менее 10 КБ).
- Файлы постоянно добавляются приложением на соседних серверах.
- Новые файлы должны быть немедленно доступны для всех серверов Nginx.
Мой текущий план:
- Имейте "главный" сервер с общим ресурсом NFS, содержащим все файлы.
- Приложение, создающее новые файлы, взаимодействует только с мастером.
- Имейте несколько серверов Nginx, монтирующих этот общий ресурс NFS.
- Балансировка нагрузки между экземплярами Nginx.
Одна очевидная проблема с этим заключается в том, что "главный" сервер является единственной точкой отказа (какое-либо решение для этого?). Есть ли другие потенциальные проблемы, которые я упустил из виду? Есть ли здесь элементы, которые не будут хорошо масштабироваться таким образом? Кто-нибудь предложил бы альтернативный подход?
Что касается требований к памяти, я предполагаю, что я должен дать каждому серверу Nginx как можно больше, чтобы горячие файлы могли быть кэшированы (ОС? Nginx?) И не должны постоянно запрашиваться из общего ресурса NFS.
Наконец, я сумасшедший, чтобы не использовать CDN?
4 ответа
NFS не масштабируется. Это добавляет задержку к каждому запросу и в конечном итоге станет слишком большим узким местом. У нас похожая проблема на работе, но с фотографиями (а значит, с файлами гораздо большего размера), и мы написали наше собственное программное обеспечение для их разделения и распространения. Для нескольких ГБ файлов, которые есть у вас, вы можете избежать загрузки, выполнив HTTP PUT для всех серверов и выполнив повторную синхронизацию, когда серверы отключены.
Или воспользуйтесь этим другим способом: иметь (набор) центральных серверов со всеми файлами и кэширующими обратными прокси-серверами (squid, pound, varnish), которые фактически обслуживают файлы для клиентов.
И ты не сумасшедший, чтобы не использовать CDN. Вы с ума сошли, если вы не исследуете, стоит ли это, хотя:-)
Используйте cachefilesd (и последнее ядро linux с cachefs) для кеширования файлов NFS на локальный жесткий диск. Таким образом, каждое чтение в nfs копирует файл в каталог /var/cache/fs, и оттуда будут доставляться следующие чтения, при этом ядро проверяет в nfs, является ли содержимое по-прежнему действительным.
Таким образом, вы можете иметь центральную NFS, но без потери производительности локальных файлов
Cachefilesd позаботится об очистке старых файлов, когда свободный размер /inode достигнет настроенного уровня, так что вы сможете обслуживать необычные данные из NFS и общие запросы с HD
После настройки используйте лак для доставки контента, он будет кэшировать наиболее часто используемые запросы, сохраняя тонну запросов в nginx/NFS.
Вот небольшая инструкция в кеше.
Ни у одного рабочего сервера не может быть единой точки отказа.
Поэтому вам нужно как минимум две машины в качестве балансировщиков нагрузки, вы можете использовать балансировщик нагрузки, такой как HAProxy. В нем есть все функции, которые вам могут понадобиться, проверьте этот пример архитектуры HAproxy. Фактическая нагрузка, с которой вы столкнетесь, - это "множество запросов на небольшие файлы" в системе хранения NFS.
Количество кэшей зависит от ваших ресурсов и запросов клиентов. HAProxy можно настроить для добавления или удаления серверов кеша.
Запрос файла NFS является самой сложной операцией, поэтому вам нужна форма кэширования на ваших "кеш" машинах.
Кеш-сервер имеет 3 уровня хранения, вы хотите, чтобы наиболее распространенные файлы были доступны локально, и желательно в оперативной памяти.
- NFS, безусловно, самый медленный. (ДИСТАНЦИОННЫЙ ПУЛЬТ)
- Локальное хранилище, быстро. (МЕСТНЫЙ)
- Рам, ультра быстро. (МЕСТНЫЙ)
Это можно решить с помощью nginx, squid или лака.
nginx может локально кэшировать файлы, используя SlowFs, это хороший медленный учебник по fs
Nginx с этой системой хранит файлы на диске локальной файловой системы и передает их оттуда. Вы можете использовать PURGE, чтобы удалить измененный файл из кэша. Это так же просто, как сделать запрос со словом "purge" в строке запроса.
Nginx с Slow FS использует оперативную память, предоставляемую ОС, увеличение оперативной памяти nginx, доступной операционной системе, улучшит среднюю скорость запроса. Однако, если ваше хранилище превышает размер оперативной памяти сервера, вам все равно необходимо кэшировать файлы в локальной файловой системе.
Nginx - это многофункциональный сервер, он не очень быстрый. По крайней мере, не так быстро, как статические серверы кэширования, такие как Squid или лак. Однако, если ваша проблема в NFS, то Nginx решает 90% проблемы.
Squid и Varnish очень быстрые и имеют apis для удаления файлов из кеша.
Squid использует RAM и локальную файловую систему для кэширования. Лак использует оперативную память для кэша.
Squid устарел, и большинство тестов показывают, что лак быстрее, чем squid, отправляющий статические файлы.
Однако, когда происходит сбой лака, кэш оперативной памяти теряется, и восстановление всего сервера может занять много времени. Поэтому сбой является большой проблемой для лака.
Squid лучше обрабатывает сбои, потому что он также использует диск локального хранилища и может перезагружать некоторый кеш оттуда вместо использования NFS.
Для оптимальной производительности, обслуживающей небольшие статические файлы, вы можете использовать Nginx и Squid OR Varnish.
Другие размеры файлов требуют другого подхода.
Я бы порекомендовал получить для этого один (потенциально выделенный) сервер вместо использования нескольких отдельных VPS-серверов и отдельных nginx экземпляры, связанные через nfs, Если вы думаете об использовании VPS и NFS, я не думаю, что ваши опасения по поводу масштабируемости оправданы.
nginx выполняет почти все свое кэширование через файловую систему компьютера, поэтому, если вы собираетесь использовать для этого nginx, вы должны убедиться, что у вас есть операционная система с отличной производительностью и кэшированием. Убедитесь, что у вашего ядра достаточно vnodes и т.п.
Если вы все еще думаете об отдельных машинах (мое предложение, как и выше, состоит в том, чтобы использовать одну машину с одним nginx), то, возможно, имеет смысл изучить varnish, Varnish выполняет все свое кэширование в виртуальной памяти, поэтому вам не придется беспокоиться о vnodes или неэффективности кэширования с небольшими файлами. Поскольку он использует виртуальную память, его кэш может быть таким же большим, как физическая память + подкачка.
Я очень рекомендую против кальмаров. Если вы хотите знать почему, просто посмотрите на презентацию лака, которая описывает, почему виртуальная память - лучший способ использовать прокси-сервер ускорения. Но лак только ускоряет, так что если вы используете один хост со статическими файлами и хорошим кэшированием файловой системы (например, FreeBSD), тогда nginx, вероятно, будет лучшим выбором (иначе, с лаком, вы получите тот же контент дважды кэшируется в нескольких местах).