Мультисерверное хранение файлов

[Albert22]

Всем привет
Есть один сайт, предполагается что пользователи будут хранить файлы, причём много. В этой связи возникает необходимость в нескольких серверах, ну или как минимум нескольких жёстких дисках для хранилища.
Сайт работает на PHP, поэтому создаю топик здесь, другого более подходящего раздела не нашёл.
Я, безусловно, имею кое-какие догадки и предположения, но подскажите, пожалуйста, как подобные вещи реализовываются максимально грамотно и эффективно? Начиная с определения сервера куда в данный момент лучше загружать, и заканчивая самим процессом отправки туда и сохранения файла.
Спасибо.

 

[venetu]

Обычно заливают на один upload-сервер, а потом уже с него сливают на один из download-серверов, в зависимости от загруженности.

Дело в том, что отдавать файлы и принимать их от юзера - слишком разные задачи, да и каналы на вход и выход могут существенно различаться. Очевидно же, что если у тебя тарифный пакет 10Mb на вход и 100 на выход - то в качестве upload-сервера он особо не подойдет.

В твоем же случае я бы порекомендовал держать все на одном серваке, в папках по несколько тысяч файлов. К тому времени, как сервака начнет нехватать, ты уже четко будешь знать, что именно его грузит и как и чем его можно освободить. Может у тебя там к 99% файлов будет по 1-2 обращения всего, зато оставшийся 1% будет забирать пол канала - тогда естественно надо городить подсчет скачиваний в риалтайме и оперативно уносить популярные файлы на отдельный сервак. А может наоборот, все примерно одинаково скачиваются, и тогда заливать и хранить файл можно будет просто на одном из следующих свободных серверов, рендомно и без всяких перекачек. Ситуации разные бывают. Еще делают для "больших" файлов отдельные сервера с особой конфигурацией, а для маленьких - отдельные. Короче заранее тебе никто не подскажет, да и ты сам не предугадаешь. Надо получить реальную нагрузку, а потом уж с ней справляться.

 

[admLoki]

Использовать S3/Cloud и не париться. По деньгам дешевле, и по мозготраху проще.

 

[venetu]

Использовать S3/Cloud и не париться. По деньгам дешевле, и по мозготраху проще.

Один терабайтный веник стоит чуть больше ста баксов. Срок эксплуатации у него - в среднем пару лет.

У амазона этот же терабайт стоит 1000Gb * $0.150 = 150 баксов в месяц, только за хранение.

Кроме того, чтобы закачать 1Tb на амазон, надо потратить 1000Gb * $0.100 = еще сто баксов.

Ну и наконец исходящий трафик, $0.170 per GB – first 10 TB / month.
Сложно сказать, сколько трафа генерит терабайтное файлохранилище, но в среднем думаю будет порядка нескольких терабайт. Итого еще 300-600 баксов в месяц.

И это повторяю, это амазоновский аналого для одного обычного веника, которых в стандартный 2U корпус можно смело напихать четыре.

 

[admLoki]

Один терабайтный веник стоит чуть больше ста баксов. Срок эксплуатации у него - в среднем пару лет.

У амазона этот же терабайт стоит 1000Gb * $0.150 = 150 баксов в месяц, только за хранение.

Кроме того, чтобы закачать 1Tb на амазон, надо потратить 1000Gb * $0.100 = еще сто баксов.

Ну и наконец исходящий трафик, $0.170 per GB – first 10 TB / month.
Сложно сказать, сколько трафа генерит терабайтное файлохранилище, но в среднем думаю будет порядка нескольких терабайт. Итого еще 300-600 баксов в месяц.

И это повторяю, это амазоновский аналого для одного обычного веника, которых в стандартный 2U корпус можно смело напихать четыре.

Я не уверен что ТС собирается хранить 1ТБ, однако не такие это уж и серьезные деньги.
Тем более что создание подобной distribute-сети может выйти бОльшие деньги, чем использование S3.
Мало того, разговор тут не про хранение файла на одном винте, а на хранении его на нескольких серверах. Под это S3 и подходит - вместо того чтобы платить на аренду/коллокейт нескольких серваков проще использовать сервисы амазона.

 

[Kloster]

Я не уверен что ТС собирается хранить 1ТБ, однако не такие это уж и серьезные деньги.
Тем более что создание подобной distribute-сети может выйти бОльшие деньги, чем использование S3.
Мало того, разговор тут не про хранение файла на одном винте, а на хранении его на нескольких серверах. Под это S3 и подходит - вместо того чтобы платить на аренду/коллокейт нескольких серваков проще использовать сервисы амазона.

Ребята, а можете подробнее рассказать, что амазон в этом плане предоставляет? Как это технически реализуется? Сервак туда файлы сам складывает? Впервые слышу об этой услуге, так что извините за глупый вопрос.

 

[admLoki]

Ребята, а можете подробнее рассказать, что амазон в этом плане предоставляет? Как это технически реализуется? Сервак туда файлы сам складывает? Впервые слышу об этой услуге, так что извините за глупый вопрос.

Амазон предоставляет cloud-storage - отказоустойчивое файловое хранилище.
Удобно использовать, т.к. есть удобоваримый API.

Добавлено через 1 минуту
Почитайте Для просмотра ссылки Войди или Зарегистрируйся

 

[Albert22]

Использовать S3/Cloud и не париться. По деньгам дешевле, и по мозготраху проще.

Спасибо, но этот вариант не подходит. Уже закупили серверные компы (одноюнитовые) и жёстких дисков по терабайту. А вопрос остаётся открытым.
Всё же, как это делается?
Смотрел на ВКонтакте — перед загрузкой в <form action=""> сразу прописан какой-то cs123, и файл непосредственно туда и уходит. Это самый подходящий вариант поскольку не нужно переливать с одного сервера на другой.

<form enctype="multipart/form-data" method="post" action="http://сs550.vkоntаktе.ru/uplоаd.рhр?асt=profile&mid=123456&hash=3c1976d177...&rhash=df83ed6771...&vk=" name="editPhoto" id="editPhoto">

Интересует как они с помощью хешей защищаются от подмены параметра mid (id юзера) — сессия ведь туда не передаётся. Хешируют его с "солью" и потом сверяют?

 

[admLoki]

Судя по всему, у вконтакта своя распределенная система.
Подобное можно написать. Принцип в том, что для сохранения используется самый малозагруженный сервер, а фронтенд самого приложения работает с файлом на серверах - генерирует ссылки и прочее.

 

[Albert22]

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

А может и сервера сами работают с файлом — обновляют инфу в БД, пережимают и т.д. Приложению передаётся только id файла.

И да, по-прежнему

Интересует как они с помощью хешей защищаются от подмены параметра mid (id юзера) — сессия ведь туда не передаётся. Хешируют его с "солью" и потом сверяют?

Этой проверки достаточно?