В настоящее время мы доставляем большие (1 ГБ +) файлы через один сервер Apache, но наш сервер Apache сильно ограничен дисковым вводом-выводом, и нам необходимо масштабировать.
Моя первая идея заключалась в том, чтобы просто продублировать этот сервер Apache, однако наша файловая библиотека слишком велика, чтобы просто горизонтально масштабировать сервер Apache в N раз.
Итак, моя следующая идея заключалась в том, чтобы иметь два Apache (высокодоступных) в бэкэнде, каждый с отдельной копией всей нашей библиотеки ... затем N обратных прокси-серверов впереди, где N увеличивается по мере роста потребностей в доставке. Каждый обратный прокси-сервер очень тяжелый для оперативной памяти и имеет максимально возможное количество шпинделей на ГБ. Внутренние серверы Apache являются более «архивными» и имеют меньшее количество гигабайт.
Это хорошая архитектура? Есть ли лучший способ справиться с этим?
Это неплохая архитектура (Кальмар является популярным обратным прокси), однако, если вы ожидаете экспоненциального роста, Сеть доставки контента может быть лучшим решением - вы платите только за тот контент, который вам нужен, пропускная способность мгновенно масштабируется (вам не нужно масштабировать больше серверов), а потоковая передача привязана к серверам как можно ближе к клиенту, обеспечивая максимальную передачу скорости. Однако я никогда не пробовал это с файлами размером 1 ГБ, а стоимость может быть непомерно высокой.
В этом случае торрент-технологию можно рассматривать как p2p CDN, и поэтому некоторые из эти поставщики могут быть подходящими в качестве торрент-семян для вашего контента, снижая общие затраты на пропускную способность и (возможно) увеличивая скорость, хотя это зависит от ваших читателей.
Мой вопрос: как узнать, что вы должны начать с IO? Мне просто кажется странным, что ваши диски не успевают за загрузками по HTTP (при условии, что это имеет место здесь, а не HTTPS).
Если у вас большая база пользователей, то решение CDN кажется применимым, как указывали другие. Мы используем Akami для распределения нагрузки. Предполагается, что вы обслуживаете эти файлы через PI (общедоступный Интернет), а не какое-то внутреннее размещенное решение только в коммутируемой сети 100 или 1000 МБ.
Возможно ли, что вы воспринимаете медленные загрузки как проблему с дисковым вводом-выводом, тогда как вместо этого это может быть проблема с пропускной способностью Интернета? (опять же, предполагая, что это сайт, ориентированный на PI).
Есть много способов увеличить объем дискового ввода-вывода - вы можете использовать SAN или RAID; оба обеспечивают некоторый уровень кеширования. Я не могу придумать какое-либо подключение к Интернету, которое превосходило бы емкость одного SAN HBA или Dual SAN HBA (объединенных), работающих на скорости 2 Гбит / с / гба, или локального хранилища через RAID с поддержкой кеширования, подключенного через шину PCI-E.
Мы говорим о клиентах, подключенных Gig-E к одному и тому же подключенному серверу?
Если вы в настоящее время этого не делаете, возможно, стоит изучить возможность доставки файлов через BitTorrent, чтобы снять часть нагрузки с ваших серверов и перенести ее в сеть P2P.
Одна возможная архитектура, которую я видел, использует nginx в качестве внешнего интерфейса и поддерживается несколькими экземплярами Varnish. Также рассматривалось вопрос о добавлении основного лака второго уровня к этой арке (т. Е. Лак стекает с основного лака).
Помимо этого, вам следует рассмотреть возможность использования CDN, как уже упоминали другие. В зависимости от того, что вы обслуживаете (медиа?), Есть несколько специализированных сетей CDN, которые больше ориентированы на доставку больших файлов, таких как BitGravity.
Здесь вы пытаетесь масштабировать свой ввод-вывод.
Использование кэширующего прокси, такого как squid или varnish, - это способ заполнить кеш для увеличения числа шпинделей без репликации мало / неиспользуемых файлов в вашем архиве. Устройства CDN тоже делают это за вас. Эти файлы носители? Устройства CDN также могут выполнять потоковую передачу за вас.
У пользователей возникают сбои при загрузке файлов и часто ли они повторяют попытку загрузки? Высокая частота повторных попыток значительно увеличит ваши потребности в вводе-выводе.
Есть ли у вас какой-либо контроль над извлечением файлов? менеджер загрузок может получать каждый файл отдельными кусками, тем самым разделяя запрос по нескольким apache с течением времени (хотя они также могут загружать параллельно, насыщая ваш интернет-канал).
Для справки по опыту: я когда-либо был только в средах, которые помещают все эти данные на NAS (в частности, netapp) и используют apache с NFS для доставки файлов (хотя было много файлов меньшего размера, а не 1 ГБ). Мы также использовали CDN в качестве кэширующего прокси для потоковой передачи видео.
В каких системах хранения хранятся ваши данные? И можно ли его разбить?
Наличие внутренних серверов в физически разных SAN, каждый из которых имеет подмножество данных, служащих для обратных прокси-серверов переднего плана, физически извергнет ваши данные и все же позволит логически адресовать их извне.
Nginx очень хорошо с потребление памяти и статический файл, который может выгружать ядро, используя Отправить файл(). Lighttpd также следует посмотреть, но я слышал, что он менее стабилен (из-за потребления памяти), но не использовал его.
Внешние серверы могут разделять запросы на внутренних серверах по пути или шаблонам (Nginx имеет отличную поддержку регулярных выражений) и даже могут перенаправлять в разные центры обработки данных, если вам это необходимо. Также может быть полезен циклический перебор DNS.
Я успешно использовал Nginx для обратного прокси-сервера в качестве средства защиты при медленной синхронизации наборов данных. Он проверит наличие файла и, если он не существует, запросит внутренний сервер через http. Позже он будет синхронизирован с интерфейсными машинами и будет работать нормально.
Убедитесь, что чем бы вы ни занимались, вы следите за статистикой по всем направлениям. Память, время ожидания io, пропускная способность, задержка, среднее время запроса и т. Д. Все, что вы делаете, без контроля - это снимать в темноте.
Что мы делаем, так это используем МогилеFS для избыточного хранения наших файлов (избыточность и масштабируемость за счет размещения каждого файла на нескольких серверах), но чтобы пользовательский доступ проходил через CDN для скорости и ... ну, большей масштабируемости.
Мы используем CDN меньшего размера, PantherExpress - их цена хорошая, а набор функций просто отличный. Limelight Networks и EdgeCast также дали нам хорошие ценовые предложения, когда мы были в магазине.
Мне понравилось, что PantherExpress предоставляет вам хорошую техническую документацию по своим функциям, и вы получаете все функции, которые у них есть, по одной цене, а не за небольшие дополнительные деньги за это и еще несколько дополнительных денег за это.