Комментарии 133
А кэширование горячего контента сделали или файла идет с диска?
Да, кэширование на ssd'шках, по мере роста нагрузки будет подбираться эффективные параметры работы кэш-серверов.
Хм. Только щас заметил — разные объемы прокачки. Щас перепроверю что залил в селектел.
Забавно. Идентичный набор файлов а сервис видит разный объем файлов.
Не идентичный, на наших серверах не хватает пары иконок.
Цены более чем вкусные. Всегда радуюсь читая новости от вашей компании :)
Нууу, рубль за Гиг трафа это еще не предел мечтаний…
Нагруженный проект я бы не стал на таких условиях размещать.
Если кому не хватит перечисленных промо-кодов, отдаю свой: Z2AYPAO2AL.
Их проблематично добавить в эту табличку, т.к. у них используется иная система биллинга (дополнительно оплачиваются все запросы)
Расскажите лучше как именно всё у вас работает. Используете весь комплекс Open-Stack или только Swift? Форкали ли его под свои задачи?
Зачем весь стек OpenStack? Только swift. Модифицировать оригинальный код не пришлось (пока :-)), а о деталях устройства будет рассказано отдельно.
Ну например nova для динамического управления виртуальными машинами в облаке :)
Просто знакомые ребята из компании N используют swift в своём облачном хранилище и упираются во многие недоработки, в результате сейчас пилят свой форк.
Лично я не очень в восторге от кода swift и периодически хотелось (и приходилось) его пилить, но в результате наше решение обходится без модификаций их кода. Причем заложена возможность поменять бекэнд хранилища (swift) на что-то другое если очень уж захочется :-)

А облачные ВМ у нас построены не на OpenStack.
НЛО прилетело и опубликовало эту надпись здесь
А при чем тут это? В статье написано «Максимальный размер файла 3Гб». Нигде с таким ограничением при работе с S3 я не сталкивался.
Вы бы еще поправили цены, так как у S3 есть Reduced Redundancy Storage который по цене получается 2.8 руб за 1 гигабайт.
А почему я тыкаю в «Хранилище» и попадаю в «Данные плательщика»?

Что нужно для заказа услуги?
Такаю на «Потребление» или «Баланс» и перекидывает в «Данные плательщика».
Остальные пункты работают.
О, после создания хранилища у меня тоже перекидывает.
А до создания все работало нормально — я тыкал.
Радует возможность доступа по FTP. Такое хранилище хорошо подходит для хранения бекапов сайтов/БД/почты и т.д…
На сколько понимаю, трафик между облаком и хранилищем учитывается как исходящий в облаке?
Сейчас да, идея не учитывать этот трафик была, но пока технически так не сделать.
Задам вопрос по-другому. У меня у вас облачный аккаунт, крупный. Некоторые архивы больше 5Гб. На нем стоит ISPmanager. Как это все подружить с вашим Storage? Без бубна и такой-то матери?
К сожалению известные мне простые консольные утилиты не позволяют этого сделать. Но можно использовать родную swift'овскую утилиту swift написанную на python, только для автоматизации всё равно придется написать свой скрипт бекапа.
НЛО прилетело и опубликовало эту надпись здесь
При создании архива делите его на тома меньшего размера, очевидно же =)
Хм, а теперь меньше 100 рублей через Qiwi уже нельзя зачислить?

Или для всех методов оплаты это не деньги, теперь?
Люто бешено плюсую. Надеюсь при минимальной цене качество не пострадает! :)
Какова задержка между хранилищем и облаком?

Возможно ли создать несколько контейнеров? Если да, то каково максимальное их кол-во?
Между облаком и хранилищем пинг минимальный, а скорость максимальная, т.к. оборудование размещается в пределах одного ДЦ.

Количество контейнеров не лимитируется, создавайте сколько нужно.
Задержка (ping) <1ms. Да, можно создавать несколько контейнеров, а вам сколько надо? =)
Эм… И как мне по стандартному договору узнать гарантированную надежность и работоспособность вашего сервиса? У Amazon я её точно знаю — 99,99% для RRS и 99.999999999% для обычного стораджа.
Вы же понимаете, что эти цифры не имеют физической силы и даже у Amazon'а может все рухнуть на день-два, чтобы они там не писали у себя в SLA. В SLA более важны пункты о размере компенсаций/неустойки, в этом плане мы всегда идем на встречу клиентам, и в случае неполадок с нашей стороны, обязательно выплачиваем компенсации клиентам.
Вы не правы. Я говорю как активный потребитель услуг S3. Мы храним на S3 несколько десятков терабайт данных клиентов (мы работаем в b2b сегменте), при этом для нас важно насколько эти данные в сохранности — Amazon в данном случае сохранность и доступность гарантирует. Ни о каких компенсациях в случае потерь (про недоступность мы не говорим) говорить не имеет смысла, так как финансовые потери, что понесем мы и наши клиенты, а так же репутационные потери вы при всем желании не сможете компенсировать. Идти и предлагать руководству переход с S3 на Selectel со словами «Они обещают если, что, всё компенсировать» как вы понимаете не серьезно.
а в чем гарантии амазона-то? в кусочке текста на сайте где написано что они не упадут? а что Вы будете делать когда упадут?
Тут штука не в гарантиях, а в аргументах для начальства)
У Амазона есть определенная репутация, которой он рискует в случае нарушения заявленных в SLA гарантий. Это очень серьезный риск.
Кстати любимый всеми DropBox хранит все данные как раз на серверах Амазона. Для вас это что-нибудь значит? ;)
Меня мало волнует репутация амазона, я никому не доверяю, и делаю бэкапы даже сверх-надежных вещей, которые «в принципе не могут упасть», как например облако селектела со злополучным багом в линуксе, или факап гугла с потерей данных пользователей почты.

Однако когда оно упадет, мне будет намного удобнее стрясти компенсацию с селектела, например (не дай бог конечно), чем сидеть, держась за голову, и говорить «ну зато у них репутация пострадала».
Мне больше нечего вам сказать, суть моего комментария вы не уловили.
Сравнение тарифов не полное, но не буду рекламировать себя и конкурентов.
Есть цены более вкусные.
Скорее бы технические подробности! Особенно интересно, почему выбрали именно swift (а не, например, elliptics.) Никакой скрытой рекламы* Используйте elliptics, elliptics лучше всех, ура-ура-ура. Я уже рекомендовал вам использовать elliptics?
А вам известны компании которые предоставляют услуги облачного хранения на базе elliptics? Сам проект то интересен, но у swift уже много коммерческих пользователей и стабильное api которое много кто поддерживает, например битрикс :-))
Я возвращаюсь с cloudconf'а — де-факто swift можно считать установившимся стандартом. Он всех устраивает по функционалу и причин «почему не он» (именно в рамках object storage) никто привести не может.

То есть к реализации претензии могут быть — а к модели работы и API?
Убедили. Интересно было, насколько решение осознанное: сравнивали ли, проводили ли нагрузочное тестирование, что-нибудь ещё.
НЛО прилетело и опубликовало эту надпись здесь
Я может что то делаю не так, но у меня через curlftpfs если копировать папку с облака на первый проход пишет не возможно создать файл, а сам создает папки и файлы по 0б, а на второй пишет IO ошибка и файл заливает и всё ок.

cp -v -R {source} {dest}
ООК. строчка с википедии от curlftpfs не юзабельна, там зачемто utf-8
Проблемы с привязыванием домена:

1) Медленно обновляются кеши dns-кеши: с момента добавления записи до момента, когда стало можно привязать, у меня прошло около двух часов.

2) Если указать fqdn (с точкой), то без точки работать не будет:
static.new.gvsmirnov.ru/Duke_Wave.png — 403
static.new.gvsmirnov.ru./Duke_Wave.png — 200
(Сейчас 403 нет, т.к. в качестве временного workaround привязал и без точки)
Тоже столкнулся с первой проблемой. У меня уже 6 часов прошло, панель все еще не дает привязать домен к контейнеру. В итоге файлы с облака недоступны пользователям сайта.
А зачем вы даете пользователям ссылки на файлы которые еще не доступны?
Обновление ДНС действительно может занимать много времени (особенно если вы меняете запись, а не задаете новую), но на это, как вы понимаете, мы никак не можем повлиять — так уж ДНС устроен.

Сама проверка на соответствие ДНС записи необходима как защита от «угона» чужих доменов. Поэтому пока запись не добавите и тайаут кэша ДНС не пройдет привязка домена не будет выполнена.

Если вы переносите свои данные к нам, то было бы логично сначала потестить на новом домене (тогда и проблем с кэшированием ДНС не будет), а потом перевести на основной. Учитывая что мы позволяем привязывать несколько доменов к одному контейнеру такой сценарий не создаст проблем для пользователей вашего сайта.
Обновление данных (в том числе всех параметров внутри веб-панели) может происходить с задержкой до 5-10 минут.
Счетчики скачиваний да, запаздывают на какие-то секунды, максимум минуты.
А вот на вкладке «Потребление» все по нулям спустя почти сутки.
Тестовые объемы скачиваний были небольшие — но на пару копеек там вроде как должно было набежать.
В биллинге есть порог списание средств, если действительно потребление было маленьким списание могло не произойти. Но если вам кажется что поведение системы не правильно обратитесь в тех.поддержку.
В Opera 11.64 через веб-интерфейс выбираю «Создать каталог», но высвечивает: «Ошибка передачи файла в хранилище» и создается файл с тем именем которое вводилось для папки.
К сожалению, в опере так и не заработало создание папок и файлов (перемещение, копирование и удаление работают). Постараемся пофиксить, пока попробуйте любой другой браузер или фтп клиент.
Кхм…
Насчет нецелевого использования облака оно может и верно, но по цене облако чуток но дешевле получается: 0.64-0.74 против 0.8.
Опять таки это сужает область применения хранилища. Довод про 3-х кратное резервирование конечно хорош, но после неприятной истории с Amazon панацеей я это не считаю, да и насколько помню, облаку тоже гарантировали что-то подобное.
Тариф на хранение данных такой же как и в облаке на дисках, а трафик в два раза дешевле. Откуда вы взяли числа 0.64-0.74?
Облако:
Сеть: отправлено (исходящий трафик): 64 копейки за гигабайт
Диск: прочитанный/записанный объем: 10 копеек за гигабайт

Хранилище
Сеть (исходящий трафик): 0.8 руб. за Гб

Внимание вопрос, с чего вы взяли, что трафик в 2 раза дешевле? Написано же 0.8.
А почему вы сравниватие стоимость хранения в сторадже и стоимость прочитаного/записанного объема данных системой в облаке?
Стоимость хранения на сторадже и хранение данных на виртуальной машине в облаке равны.
Исходящий трафик чуть дороже, но вы совершенно ничего не платите за входящий…
Я не сравниваю стоимость хранения. Стоимость хранения, на текущий момент, одинаковая.

Почему не учитываю входящий трафик? Я за него и так не плачу. Точнее, объем GET запросов даже меньше, чем объем «мусора» идущего со стороны интернета.

То есть в сумме, хранилище получается хоть немного но дороже. А где выгода? Надо же и стоимость миграции учитывать тоже…
Признаюсь, мне хранилище импонирует, но при его использовании я потеряю от 12 до 37%. И меня это печалит.
Удивляюсь я с ваших расчетов, но больше всего мне интересна причина, по которой вы не учитываете стоимость таких ресурсов как оперативная память, процессорное время и стоимость всех операций ввода/вывода.

Есть 5Гб контента, надо раздать 1Тб.

Хранилище за месяц:
Закачать 5Гб — бесплатно
Раздать 1Тб — 800 рублей
Хранение — 16.20 рублей
Итого: 816.20 рублей

Берем виртуалку со средним количеством оперативной памяти равной 256Мб(достаточно для раздачи статики):
Расчет за месяц:
Оперативная память — 105рублей
Закачать 5Гб контента — 1.30 рублей
Раздать 1Тб контента — 740 рублей
Хранение — 16.20 рублей
Получается примерно 862.5 и это еще без учета стоимости всех операций ввода вывода…
Все зависит от методики подсчета. Если хранить и отдавать допустим ISO и отдавать чем-нибудь «толстым» апачем, допустим, то да, ваши расчеты имеют право быть.

Насчет 256Мб для статики вы усложняете. Достаточно 64 и будет работать, но у вас 128 это минимум. Плюсуем сюда еще такую штуку как архивы. Информация хранится в архивах, отдается распакованной. Плюс забор файлов не рандомный, то есть 128Мб еще и на небольшой кеш хватает.

Так проценты и накапливаются.
Зачем?
Нет, если вам интересно, то 12-37% это при решении задачи через API и ухищрения.

При решении «в лоб» все гораздо скучнее получается. Как я говорил, в моем случае информация в виде архивов хранится, поэтому хранимый объем был бы разный для облака и для хранилища и разница достигала бы 3-4 раза минимум
А тут вы сами понимаете, хранилище для моей задачи совсем невыгодным становится.

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

Я всего лишь указал на факт, что облако, при прямых руках, хоть на 5-15к но дешевле. А для случаев с возможностью хранения сжатого контента так и еще больше. После чего озвучил мысль, что с текущими тарифами, хранилище, продукт сугубо специфичный и переместив статику на него сильно не сэкономишь.
P.S. Надо бы запретить сотрудникам фирмы выставлять оценки в блоге этой же фирмы. А то прям не хабр а рекламная площадка получается. :-)
А как вы думаете для чего компании заводят корпоративные блоги?
В данном случае для хаброэффекта и создания положительного впечатления. Но хабр это не личный сайт, а так сказать общественный и заниматься на нем откровенным кликерством некрасиво.
У меня
0.98 — для сервера
1.50 — для CDN

Уважаемый amarao, судя по сообщению silverqh0st, static — это сервер, так что ваши результаты подтверждают, а не опровергают сообщение.
Да, вы правы.
Какой-то несколько странный CDN, если он медленнее обычного nginx'a.
Попробуйте повторить операцию 10 раз.
У меня с пятого раза вот такие данные.
для st
real    0m 0.02s
user    0m 0.00s
sys     0m 0.02s


для static
real    0m 0.02s
user    0m 0.00s
sys     0m 0.01s

Минимальный результат из 10-ка:

$ time wget st.solnyshko.dn.ua/image/cache/data/2012-04-19/6914-500x500.jpg -O /dev/null -o /dev/null

real 0m0.485s
user 0m0.000s
sys 0m0.004s

в тоже время обычный nginx:

$ time wget static.solnyshko.dn.ua/image/cache/data/2012-04-19/6914-500x500.jpg -O /dev/null -o /dev/null

real 0m0.342s
user 0m0.000s
sys 0m0.004s
Пардон.
Не те данные вставил.
st
real 0m 0.21s
user 0m 0.01s
sys 0m 0.07s

static

real 0m 0.23s
user 0m 0.01s
sys 0m 0.06s
Тест главной страницы с использование CDN:
image
Url теста: tools.pingdom.com/fpt/#!/hED0GHvG1/solnyshko.dn.ua

И с использованием nginx:
image
Url теста: tools.pingdom.com/fpt/#!/iRsSl92yr/solnyshko.dn.ua

Наглядное сравнение и, на мой взгляд, достаточно показательное.
Знаете, раздачу с nginx можно считать как эталон, т.к. он тупо отдаёт локальный файл не выполняя вообще никаких дополнительных действий. А хранилище устроено значительно сложнее и для отдачи файла требуется выполнить ряд промежуточных действий на каждый запрос, поэтому в любом случае оно будет несколько медленнее, вопрос лишь в том на сколько (решение этого вопроса как раз уже наша работа).

Упреждая вопрос «за зачем тогда хранилище если оно чуток да медленней локального nginx?»: дело в размере и цене :-) Вероятно вы получите выигрыш в стоимости при хранении и раздачи большого объема данных для вашего сайта, чем если бы вы хранили и раздавали тот же контент с вашего хостинга. Плюс не надо задумываться о том сколько хостер предоставляет вам дискового пространства и бэкапить эти данные тоже не нужно.
При пинге в 500мс сеть влияет на результат куда больше, чем работа отдающей системы. У меня с FB отдаётся за 500мс, с solnyshko.dn.ua около 100мс.
В табличке указана стоимость хранения 3 р. за 1 Гб в месяц.
На сайте написано: 4.5 р. за 1 Тб в час.
Считаем: (4.5 / 1024) * 24 * 30 = 3.1640625 р. за 1 Гб в месяц.
Или я не так посчитал?
Цены конечно приятные и за размещение, и за трафик, но есть ли какие нибудь гарантии, что через какое то время вы не поднимите их резко вверх до уровня своих конкурентов?

При текущих ценах это все очень интересно и перспективно.
Цены взяты не с потолка и уже отработаны на облачных серверах.
что-то не могу примонтировать с помощью CloudFuse.

> Unable to authenticate.

что надо писать в качестве username и api_key?
имя и пароль на вкладке «Техническая информация» не подходят сюда.
Еще вопрос, кол-во файлов в одной папке ограничено?
Например не более 65 тыс файлов на одну папку.
Имхо, вы сильно раньше начнёте ощущать тормоза, так зачем экспериментировать? :)
Если пользователям выдавать прямые ссылки на файлы, кол-во файлов рядом не должно сказываться на скорость отдачи, разве не так?

Не ограничено, по сути хранилище объектное, папки там это просто виртуальные объекты. Если я не прав, пусть меня поправят коллеги.
У вас есть ограничение в 5 доменов, это 5 доменов на контейнер или на все доступные контейнеры?
Планируется ли снять ограничение 5 ГБ на один файл при загрузке через FTP? Сразу можно было под бекапы использовать.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.