Назад | Перейти на главную страницу

Распространение террабайтных файлов среди общественности с веб-сервера

Нам нужно создать веб-сайт, который сделает общедоступными два или три больших файла - файлы будут размером 1 или 2 террабайта каждый. Хотя они будут общедоступными, на практике я ожидаю, что только относительно небольшое количество ученых захочет их загрузить. Как лучше всего допустить это?

Я быстро поговорил с провайдером веб-хостинга (rackspace), и они предложили гибридное решение.

Для меня это звучало нормально, но я относительно мало знаю об администрировании серверов. Имеет ли это смысл?

Заранее спасибо, Марк

Есть люди с опытом обслуживания вещей, подобных тому, о чем вы просите.

Если вы работаете в центре НАСА, вам необходимо получить разрешение на использование одноранговой сети; это касается как сервера, так и пользователей, поэтому доступ к данным только через p2p может сделать их фактически недоступными для некоторых ученых (если они не захотят пройти через это).

Лично, когда люди запрашивают большие объемы наших данных (это изображения и кубы данных, при этом размер большинства файлов меньше 100 МБ), если он меньше нескольких ГБ, у меня есть несколько CGI, которые будут генерировать tarball / zip-архивы на лету. Мы подумывали написать собственный менеджер загрузок, но я думаю о том, чтобы сделать его более общим и написать BagIt интерфейс для обслуживания незаполненных пакетов и клиент для заполнения пакетов и их проверки.

Для данных того размера, о котором вы говорите, люди отправляют нам жесткие диски по почте, мы их форматируем и отправляем обратно. Скорее всего, им понадобится дисковое пространство для хранения, когда они загрузят его, а это происходит всего несколько раз в год, поэтому для нас это более эффективно, чем платить за дополнительную пропускную способность. (Вчера мы только что получили отгрузку из 7 дисков емкостью 2 ТБ для тех, кто хочет получить полные данные для двух приборов, данные которых мы архивируем здесь).

... и я также стараюсь не создавать файлы размером более 2 ГБ ... они становятся слишком громоздкими, и вы начинаете сталкиваться с проблемами со старыми ОС и файловыми системами.

...

И если у кого-то есть рекомендации по ограничению пропускной способности и подключению к определенному IP-адресу в Apache, я был бы благодарен - каждые несколько дней я получаю от кого-то из Китая, открывающего все доступные подключения, чтобы вытащить данные из наших систем. Я видел более 800 за раз. (брандмауэрами управляет другой отдел, и они блокируют IP-адреса, но не дросселируют)

...

Вы также можете спросить на Информатика науки о Земле и космосе список рассылки - даже если это не ваша область, мы все заинтересованы в вопросах распространения данных.

Один или два терабайтных файла?

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

Терабайтные файлы, как в тебибайте, 1024 гигибайта, по HTTP? Не делай этого.

Я бы посоветовал изучить, какие платформы (операционные системы) используют ожидаемые потребители этих файлов. Если это Windows, то бесплатный 7-молния может сжать файл и разделить полученный выходной файл на несколько файлов меньшего размера (скажем, размером 3,9 ГиБ). В Unix GNU TAR может сделать то же самое; или вы можете снова использовать 7-Zip, но у большинства пользователей Unix он может не быть установлен.

Эти файлы меньшего размера можно затем передать и распаковать в месте назначения. Если часть файла будет повреждена во время передачи, то только эта один файл меньшего размера необходимо будет повторно загрузить. И если загрузка файла займет несколько дней, пользователь может выключить свой компьютер, когда файл меньшего размера будет полностью загружен, и возобновить загрузку оставшихся файлов позже. Наконец, использование сжатого архива дает вам встроенную проверку ошибок.

Обратной стороной является то, что во время сжатия и распаковки пользователи освобождают место на жестких дисках, что примерно в 2 раза превышает размер файла.

Вы можете использовать простой FTP или HTTP для передачи файлов меньшего размера. Я бы выбрал FTP, но менее технически подкованные пользователи могут не иметь FTP-клиента и тогда предпочтут HTTP. Было бы неплохо написать FAQ или список распространенных проблем - старые файловые системы и программы FTP часто не могут обрабатывать файлы размером более 4 гигибайт (32-битные заголовки).

Редактировать: +1 за предложение Джо Х. подключить файлы к сети. Отправка жестких дисков по почте / курьером происходит быстрее и дешевле, чем передача через Интернет, если только все участники большой Интернет-трубы.

Я согласен с предложениями sneakernet (или mabye postmailnet?). Отправка жесткого диска (или двух) по почте может быть намного быстрее и дешевле.

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

в этом случае лучшим решением будет первая отправка на физическом носителе, а затем просто загрузка различий.

Для этого есть несколько очевидных предложений:

  • опубликуйте различия, возможно, используя rdiff для создания двоичных файлов исправлений. минусы: если пользователь не обновляется каждый раз, то должен применить все пропущенные патчи, чтобы наверстать упущенное. если вы не публикуете отличия от n-1, n-2, n-3 и т. д.
  • предложите своим пользователям использовать rsync, таким образом не имеет значения, если пользователь не обновлен. минусы: ваш сервер должен поддерживать rsync.
  • используйте zsync (мой любимый): вы публикуете как свои огромные файлы, так и файл «подписи» для каждого из них. клиент загружает файл подписи, вычисляет, что ему нужно, и загружает только эти части из большого файла (используя HTTP range заголовки для частичных загрузок). минусы: сайт szync кажется устаревшим, вам придется его протестировать самостоятельно.

Мягкий фактор, который следует учитывать, - это как ограничить загрузку. Я бы порекомендовал вам иметь страницу со знаком, которая дает им ключ, необходимый для ее загрузки, и этот ключ действителен в течение x дней. Вы можете позволить им загрузить его снова после второй регистрации и т. Д., Но мы надеемся, что это предотвратит использование людьми его в качестве файла для тестовой загрузки или чего-то подобного.

Если есть два многих ключа одновременно, у вас может быть очередь, это будет контролировать количество одновременных загрузок.

Я помню, что веб-сайт НАСА использовал что-то подобное для больших изображений синих мраморов некоторое время назад (возможно, все еще используется).

Кроме того, если вы не используете решение torret, я бы разбил файл на кусочки по 1 ГБ. Я думаю, что это то, что Akami делает для больших загрузок Microsoft. Они делают это автоматически, но поскольку это ученые, вы, вероятно, можете получить инструкции, как к ним присоединиться.

Вам понадобится CDN, предлагающая как элементы управления доступом пользователей, так и менеджер загрузки / загрузки на основе Java.

Это исправит три вещи;

  • Они будут размещать ваш контент глобально и из нескольких устойчивых точек - это будет лучше обслуживать ваших клиентов.
  • Клиенты должны будут настроить учетные записи перед загрузкой, это дает вам возможность отслеживать и гарантирует, что люди не тратят пропускную способность, начиная загрузки, которые они не собираются завершать.
  • Java-клиент, поддерживающий несколько ОС, будет использовать обычно менее надежный протокол HTTP в пакетах, чтобы заполнить полную загрузку и иметь дело с усеченными суб-передачами - обычно я ненавижу такие вещи (думаю, загрузчик adode), но они имеют свое место для переводов такой большой.

Так что поговорите с большими CDN (Akamai и т. Д.) И попросите об этом хорошо.