ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: прозрачное проксирование с AWS S3



On Apr 4, 2013, at 1:13 PM, denis <denis@xxxxxxxxxxxxxxxx> wrote:

> 04.04.2013 15:04, Anatoly Mikhailov пишет:
>> Добрый день,
>> 
>> появилась бизнес-задача организовать контролируемую доставку файлов
>> с S3, разумеется, nginx будет заниматься проверкой условий и отдавать
>> файл при их соблюдении. Заодно у нас появится возможность использовать
>> SPDY для файлов с S3.
>> 
>> пока нашел вариант с X-Accel-Redirect 
>> (http://kovyrin.net/2010/07/24/nginx-fu-x-accel-redirect-remote/)
>> с отключенным proxy_max_temp_file_size и proxy_hide_header 
>> Content-Disposition.
>> 
>> вопрос - использует ли кто данный подход и как правильно организовать 
>> прозрачное проксирование?
> А какой смысл? У меня есть в планах чуть другая система: запрошенный файл 
> качаем с S3, кладём локально и в дальнейшем он будет отдаваться только 
> локально. Но нужно такое чуть для другого: если у нас произошел полный отказ 
> сервера, разворачиваем ядро сайта на новом месте + конфиги, и система сама 
> будет качать нужные файлы из резервного хранилища, а остатки потом докачать в 
> фоне с минимальным приоритетом.
> 
> У вас получается, что файл будет каждый раз закачиваться с S3 на машину и 
> отдаваться, то есть трафик до амазона, трафик до юзера, нагрузка на сервер 
> даже больше, лаг отдачи (для файлов более 1мб может быть очень заметно). 
> Лучше тогда запустить инстанс в амазоне, который будет этот файл читать почти 
> как локальный, и уже напрямую отдавать (на поддомене может висеть). Плюс там 
> же можно отдавать через безопасные линки.

Смысл следующий, S3 - это не standalone сервер, а нормальное высокодоступное и 
отказоустойчивое распределенное файловое хранилище,
поэтому мы используем его по назначению без лишних абстракций, сейчас задача - 
скрыть URL как это делает CNAME, но у нас HTTPS,
поэтому CNAME отдается с невалидным сертификатом, что само по себе очевидно.

У вас хорошая идея, но в нашем случае кэширование - это не та задача, которую 
мы решаем, у нас данные, что называется горячие,
поэтому cache hit rate будет невысоким, а overhead лишним, так как придется 
очищать локальный кэш.

Насколько мне известно, входящий и/или (надо уточнить про и/или) исходящий 
трафик внутри AWS бесплатный, и сервера у нас в тех
же зонах, что и S3 корзины, поэтому я не вижу проблем со скоростью доступа к 
файлам, мы даже уберем буфер, чтобы отдавать напрямую

Анатолий

> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@xxxxxxxxx
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.