Облака, белокрылые лошадки

[vitus_wagner]

А не подскажет ли кто правильное облачное хранилище данных?

Требования такие

1. Чтобы много и дешево. Не менее чем 100Гб и цена заметно меньше чем у дешевых виртуалок (каковые по-моему уже до $5/мес упали).
2. Чтобы никаких специальных клиентов - чтобы заливать туда файлы можно было по стандарным протоколам - webdav, ftp, smb, rsync (достаточно любого одного из)
3. Чтобы файлы оттуда можно было раздать по http всему свету, но не как в яндексе, а чтобы если там лежит index.html, то введя ссылку на него в браузер, можно было бы увидеть этот html так, как автор его задумал, и все относительные ссылки бы работали. (собственнно, ровно этим меня не устраивае яндекс - он пытается как-то сам делать thumbnail-ы моих фотографий а html-и предлагает скачать вместо того, чтобы в браузере показывать.

Comments

[amarao-san.livejournal.com]

Добавь в "стандартные протоколы" swift'овый. У большинства операторов есть ftp к свифту, но это всегда "через жопу". python-swiftclient есть в дистрибутивах и весь из себя опенсорсный, и он вменяемый (в отличие от ftp-эмуляции).

Основная проблема эмуляции в том, что крупные файлы должны резаться на куски, и лучше, если это делает клиентский софт (swiftclient это делает прозрачно), чем если прослойка на стороне оператора.

Если swiftclient устроит, то искать по swift storage. Белый пушистый опенсорсный стандартный.

Но никакого фэнсервиса в стиле thumb. Положил файлы - они лежат и раздаются.

[vitus_wagner]

Что-то то, что там гугль мне находит какие-то совершенно недетские цены имеет. Вроде 4 цента за гигабайт в месяц плюс 9 центов за гиг траффика.
И за такие деньги трахаться с кривыми клиентами.

Задачи хостить большие файлы у меня нет. Если оно конечно 20Мб большим не считает.

[amarao-san.livejournal.com]

"Большие файлы" - это больше 5Гб. Провайдер может поставить другой лимит, но дефолтный для swift'а - 5.

В конторе, где я работаю, 3 евроцента за гигабайт и 3 цента за гиг трафика.

А какие цены ожидаются?

(Насчёт "кривых клиентов" - ты это зря, swift куда более прямой чем средней руки ftp-сервер, особенно на corner cases, типа "странные буквы в именах", "500000 файлов в каталоге" и других местах с неожиданностями, кроме того, оно там опенсорс насквозь, с open governance и т.д.).

[vitus_wagner]

Ожидается - "дешевле чем VDS у хетцера". Причем желательно не менее чем вдвое. А то может оказаться дешевле просто сапгрейдить конфигурацию VDS.
Надо бы, конечно оценить траффик. Я его никогда посчитать не пытался.

[amarao-san.livejournal.com]

Ну, тут вопрос избыточности. У нас тут чешут голову на тему двух копий данных в swift'е вместо трёх, но сцыкотно, ибо рассказывать клиенту что "потеря данных это нормально" как то не очень.

Вопрос цены сильно зависит от объёма. На любом арендованном сервере ты не будешь использовать весь объём (хочу посмотреть на "нормальную" работу линукса при 0 места). В принципе, если есть желание "админить", то VDS'ки не перебить, потому что там хостер точно знает, что большая часть места не используется и может сильно демпинговать. В объектных хранилищах оплачивается что положили (то есть то что оплачивается, точно занято).

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

[vitus_wagner]

Вот я как раз и уперся в работу при 0 места. И нужно либо то, что занимает это место куда-то спихнуть, либо место расширить. К сожалению, overselling такой overselling, и, хотя у меня там по идее еще несколько мегабайт места есть, периодически случается что postfix письмо в спул положить не может.

[amarao-san.livejournal.com]

смонтировать pool на tmpfs?

[vitus_wagner]

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

[amarao-san.livejournal.com]

Только не loopback'ом, а kpartx'ом. losetup очень неадекватен во многих вопросах. kpartx (почти то же самое, что losetup, только через device mapper) куда более 'production ready'.

Кстати, и losetup, и kpartx требует "настоящего рута" и в openvz/lcx работать не будут.

[vitus_wagner]

Свифт может быть и прямой. Но клиенты - кривые. Ставлю пакет python-swift, а он тащит за собой стопятьсот прочих питоновских модулей. Люди, которые для командно-строчного клиента к сетевому протоколу нуждаются в 34 модулях, не входящих в стандартную поставку python, пишут кривой софт. Вот по определению. Ибо не может такого быть чтобы в наше время из 34 опенсурсных библиотек все были прямыми и не просто прямыми, а не порождающими кривизны при совместном использовании.

[amarao-san.livejournal.com]

Цена за универсальность. Openstack не выделяет отдельно клиента, то есть они все используют стандартную базу для приложений, в том числе и для клиентов.

[vitus_wagner]

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

[avnik.livejournal.com]

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

[amarao-san.livejournal.com]

В текущем опыте использования - не конфликтуют. Они же вообще в дистрибутиве, не? Какие такие конфликты в Дебиане?

[vitus_wagner]

Разнообразные. Мейнтейнеры пакетов тоже не гекаторхейры - протестировать на возможные конфликты все декартово произведение 40000x40000

[amarao-san.livejournal.com]

Ок, я с опенстеком работаю достаточно давно и я ни разу не натыкался на проблемы в системе из-за библиотек openstack'а. Они могут между собой посраться, если разные версии ставишь (например, python-glance 2013.2 и python-glanclient 2015.1 вместе не встанут), но чтобы на работу других приложений влияло - ни разу не наблюдал.

[tretiy3.livejournal.com]

у гугла как раз самый дешевый вариант. по обычному файлу они с амазоном вровень - 3 цента за Гб (только дисковое место, без трафика). а вот по "медленным" файлам они амазон вздули месяц назад: за 1 цент теперь можно купить гигабайт, который доступен через 3 с (https://cloud.google.com/storage-nearline/).
до сих пор, заливал все в amazon glacier. там тоже 1 цент, но доступ через 4 часа. ну и мне не особо нужно, конечно - просто все валю туда и привет. на пенсии буду разбираться.
а сейчас призадумался. 3 секунды - не так плохо, если речь про фоточки и видео.
у амазона, правда, вся инфраструктура выглядит ну оч толково. у них, например, можно лить не сразу в гласиер, а в s3 по 3 цента, но передавать lifecycle, по которому он эти файлы через месяц, скажем, спрячет в гласиер. доступ у них можно настроить гораздо гибче. интеграция с другими сервисами - супер.
но 1 цент за 3 секунды - оч манит. можно придумать смотрелку фото/видео, которая 3 секунды может замести под ковер тихонечко, мне кажется.
думаю про гугол, в общем.

[inkelyad.livejournal.com]

Хм. Amazon S3? Протокол у них, правда, свой, но по сегодняшним временам уже можно стандартным считать. Ну и index.html придется держать на своем сервере - серверные мощности у них как-то дороговаты.

[vitus_wagner]

Ну если index.html на своем сервере держать, так и яндекс сгодится. Я уже выяснил как через его REST API получить прямые ссылки. Осталось скриптик наваять, и можно разгрести гигабайт 60 из 75, которые у меня сейчас заняты на vds.

[viklequick.livejournal.com]

Статику я на s3 как раз держу, очень удобно.

Вообще тут два варианта есть из коробки.

Первый - это сконфигурировать поддомен указывающий на S3 endpoint и всю статику туда положить. В основном сайте указать в явном виде нечто вроде https://assets.foo.bar/where/image/being/located/cool.jpg ничего больше не менять.

Второй - наоборот, сконфигурировать статический веб сайт прямо в s3, включая index.html и прочее. А на динамику прописать редиректы на vds-ку. При заливке рекомендую обратить внимание на правильный content-type для javascript, и про permissions не забыть.

Я собственно применяю оба варианта в зависимости от задач.

При синхронизации контента еще нало обратить внимание вот на что. Амазон не любит заливку файлов поштучно и может врубать троттлинг, что неприятно. Да и с стагигабайтными файлами могут быть проблемы. Зато он предоставляет bulk upload, так называемый TransferClient. Пользоваться надо им, он сразу заливает целый каталог в один присест. Это быстрее и удобнее.

[Шаманов Алексей (from livejournal.com)]

А смонтировать yandex.disk через webdav с помощью wdfs/davfs2 на локальную машину и раздавать данные своим сервером - не вариант?

[vitus_wagner]

Не вариант. davfs очень агрессивно кэширует. Набежит какой-нибудь googlebot мои фотки индексировать, и забъет dav-овским кэшом все место.

[rblaze.livejournal.com]

Они позволяют хостить статику прямо из S3, я так сайт держу.

[phd_ru]

Много, дёшево и удобно! Классика! :-D

Витус, ты ещё слова «быстро» и «качественно» забыл. :-P

[vitus_wagner]

А вот "быстро" мне как ни странно, не обязательно. У меня туда уползут данные, которые кем-то скачиваются раз в год.

[angry-elf.livejournal.com]

Дешевле хецнера по цене за мегабайт хранилища плюс трафик - очень сложно найти будет.

Мы ушли на одном из сервисов в S3, только потому, что там много терабайт, а трафика практически нету. В итоге получается дешевле немножко, плюс не нужно держать и управлять несколькими серверами (мы не влазим ни в одну конфигурацию, включая 15-дисковый SX290).