Масштабирование загрузки больших файлов?

Это не плохая архитектура ( squid является популярным обратным прокси-сервером), однако, если вы ожидаете экспоненциального роста, сеть доставки контента может быть лучшим решением - вы платите только за контент, который вам нужен, пропускная способность мгновенно масштабируется (вам не нужно масштабировать больше серверов), а потоковая передача привязывается к серверам как можно ближе к клиенту, обеспечивая им максимальную скорость передачи. Однако я никогда не пробовал это с файлами 1 ГБ, и стоимость может быть непомерно высокой.

В этом случае торрент-технологию можно рассматривать как p2p CDN, и поэтому некоторые из этих провайдеров могут быть подходящими в качестве торрент-семен для вашего контента, снижая ваши общие затраты на пропускную способность и (возможно) увеличивая скорость, хотя это зависит от ваших пользователей.

Мой вопрос: как вы узнаете, что с самого начала вы - IO? Мне кажется странным, что ваши диски не справляются с загрузками по HTTP (при условии, что здесь дело обстоит именно так, а не по HTTPS).

Если у вас большая пользовательская база, то, как указали другие, решение CDN кажется применимым. Мы используем Аками для распределения нагрузки. Предполагается, что эти файлы передаются через PI (общедоступный Интернет), а не какое-либо внутреннее решение только в коммутируемой сети 100 МБ или 1000 МБ.

Возможно ли, что вы воспринимаете медленную загрузку как проблему с дисковым вводом-выводом, когда это может быть проблемой пропускной способности Интернета? (опять же, если предположить, что это сайт, ориентированный на PI).

Существует много способов увеличить дисковый ввод-вывод - вы можете использовать SAN или RAID; оба обеспечивают некоторый уровень кэширования. Я не могу представить себе какое-либо интернет-соединение, которое могло бы опередить емкость одного SAN HBA или Dual SAN HBA (объединенного), работающего со скоростью 2 Гбит / с /hba, или локального хранилища через RAID с поддержкой кэша, подключенной через шину PCI-E.

Говорим ли мы о подключенных Gig-E клиентах к одному и тому же подключенному серверу?

Если вы в данный момент этого не делаете, возможно, стоит изучить возможность доставки файлов по выбору через bittorrent, чтобы снизить нагрузку на ваши серверы и на P2P-сеть.

В каких системах хранения у вас есть ваши данные? И можно ли его разбить?

Наличие внутренних серверов в физически разных сетях SAN, каждая из которых имеет подмножество данных, служит для обращения к прокси-серверам переднего плана, физически разбрызгивая ваши данные и в то же время позволяя логически адресовать их тем же извне.

Nginx отлично справляется с потреблением памяти и обслуживанием статических файлов, поскольку может выгружаться в ядро ​​с помощью sendfile (). Lighttpd также следует посмотреть, но я слышал, что он менее стабилен (относительно потребления памяти), но не использовал его.

Внешние серверы могут разделять запросы на внутренних серверах по пути или шаблонам (Nginx имеет отличную поддержку регулярных выражений.) И даже могут перенаправлять в разные центры обработки данных, если вам это нужно. DNS round robin также может быть полезен.

Я успешно использовал Nginx для обратного прокси-сервера в качестве отказоустойчивого между медленно синхронизируемыми наборами данных. Он проверил бы файл и, если бы он не существовал, запросил бы внутренний сервер через http. Позже он будет синхронизирован с внешними машинами и будет работать нормально.

Убедитесь, что все, что вы делаете, вы отслеживаете статистику по всем направлениям. Память, время ожидания, пропускная способность, задержка, среднее время запроса и т. Д. Без наблюдения за тем, что вы делаете, снимаете в темноте.

Одна возможная архитектура, которую я видел, использует nginx в качестве внешнего интерфейса и поддерживается несколькими экземплярами Varnish. Был также рассмотрен вопрос о добавлении к этой арке первичного лака второго уровня (т. Е. Лак вытягивается из основного лака).

Помимо этого, вы должны рассмотреть возможность использования CDN, как уже упоминали другие. В зависимости от того, что вы обслуживаете (медиа?), Существуют некоторые специализированные CDN, которые больше ориентированы на доставку больших файлов, таких как BitGravity.

То, что вы пытаетесь масштабировать здесь, это ваш IO.

Использование кеширующего прокси-сервера, такого как squid или varnish, позволяет заполнить кэш-память для увеличения количества шпинделей без репликации файлов с низким / неиспользуемым объемом в вашем архиве. Устройства CDN делают это и для вас. Эти файлы носители? Устройства CDN также могут выполнять потоковую передачу для вас.

Получают ли пользователи сбои при загрузке файлов и часто повторяют попытки загрузки? Высокая частота повторных попыток значительно увеличит ваши потребности в вводе-выводе.

Есть ли у вас контроль над тем, как файлы выбираются? менеджер загрузок может извлекать каждый файл отдельными порциями, тем самым разделяя запрос на несколько апачей с течением времени (хотя они также могут загружаться параллельно, насыщая ваш интернет-канал).

В качестве примера "опыта" я только когда-либо бывал в средах, в которых все эти данные помещаются на NAS (в частности, в netapp) и используют apache с NFS для доставки файлов (хотя было много файлов меньшего размера, а не 1 ГБ). Мы также использовали CDN в качестве кеширующего прокси для потоковой передачи видео.

Мы используем MogileFS для избыточного хранения наших файлов (избыточность и масштабируемость при наличии каждого файла на нескольких серверах), но при этом пользовательский доступ проходит через CDN для скорости и... ну, еще большей масштабируемости.

Мы используем меньший CDN, PantherExpress - их цена хорошая, а набор функций просто великолепен. Limelight Networks и EdgeCast также дали нам хорошие цены, когда мы ходили по магазинам.

Мне понравилось, что PantherExpress предоставит вам хорошую техническую документацию по их функциям, и вы получите все функции, которые они имеют, по одной цене, а не за небольшую дополнительную плату за это и еще несколько дополнительных денег за это.