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