Pull to refresh

Comments 10

А теперь расскажите, почему надо EMC, когда есть уже opensource'ные лидеры рынка (swift, ceph)?
Попробуйте переместить в свифте 70 миллионов объектов с ноды на ноду и вопросы отпадут ;)
Ceph — чудо а не продукт, но вот librados часто не дает работать.

Это не вопрос почему EMC, а вопрос «почему я должен заплатить?» — ответ на него всегда один — хотите держать команду которая будет вам пилить хранилище — держите, разумеется не забудьте учесть все риски которые с этим связаны, а как человек который покушал на создании такого рода продуктов, я вам скажу что их будет в разы больше чем при покупке готового хранилища.

Можно вечно пилить на коленке, это очень круто и весело, но увы результат не так хорошо работает как хотелось бы.
70 миллионов объектов спокойно и неторопясь двигаются. А зачем их двигать срочно? радос — то ещё развлечение, я говорю про чистый object storage, без закосов под FS.

Насчёт «заплатить», давайте я задам вам другой вопрос: цены EMC в сравнении с рынком object storage'ей? Скажем, в перспективе пятилетней аммортизации на объёмах в, допустим, 500 Тб. Поскольку за трафик и так и так платить, будем считать, что «обязательного» трафика там только на «закачал/скачал» (то есть по 500Тб).
>70 миллионов объектов спокойно и неторопясь двигаются. А зачем их двигать срочно?

я неправильно выразился — заставьте свифт синкнуть такое количество объектов внутренними средствами — получите rsync которого убил oom и вставшее хранилище

>Насчёт «заплатить», давайте я задам вам другой вопрос: цены EMC в сравнении с рынком object storage'ей? Скажем, в перспективе >пятилетней аммортизации на объёмах в, допустим, 500 Тб. Поскольку за трафик и так и так платить, будем считать, что «обязательного» >трафика там только на «закачал/скачал» (то есть по 500Тб).

я вам тут так отвечу — купить и использовать ECS будет дешевле процентов на 70 в 5-ти летней перспективе на такой объем чем собирать и поддерживать самостоятельно
Я аж удивлился и пошёл уточнить у местного swift-гуру. Swift 70 миллионов объектов спокойно будет перемещено с ноды на ноду, штука за штукой. Без экстрима вида «70 миллионов объектов засунуть rsync'у в командную строку». Не слишком быстро, но точно и спокойно. У нас подобные штуки ползают и никого не смущают.

По второму вопросу вы уходите от ответа. Я не спросил «в сравнении с inhouse», я спросил «как соотносятся цены EMC и публичных провайдеров на объём в 500Тб в год». У вас же есть GPL цены? Вот давайте их и сравнивать. Понятно, что EMC традионно закладывается на всякие «дисконты» в 50-80% от GPL'я, но и поставщики на 500Тб почешут в голове и цену срежут, так что давайте нос-в-нос.

Берём цены rackspace'а (как источника swift'а в этом мире), берём цены EMC, и в бой.
Вы предлагаете автору сделать некорректное сравнение. ECS — это комплексное решение. Оно для тех, чей бизнес перерос определенные рамки, либо для тех, кто не содержит собственного штата IT-специалистов.

Ceph нужно сравнивать с software-only решениями. У EMC такое решение есть. Оно называется ScaleIO.

ScaleIO vs. Ceph:

image
Судя по переписке, просили сравнить swift c описанным ECS, а Вы в качестве контраргумента публикуете снимок с экрана о сравнении ScaleIO c Ceph. Хотя, раз уж опубликовали картинку, то киньте еще и ссылку на эти тесты — какая конфигурация железа, нагрузка и т.п. А то у EMC Isilon картинки тоже были красивыми, а у заказчиков и на независимых тестах storageperformance.org показывала низкую производительность.
Я отвечаю на прямой вопрос автора, изложенный в первом комменте.

Сравниваю со ScaleIO, потому что это сравнение «soft vs. soft», а не «soft vs. appliance». Сравнивать «soft vs. appliance», во-первых, тяжело, т.к. непонятно, каким образом выдержать одинаковость железных конфигураций. Во-вторых, не имеет особого смысла, т.к. soft не имеет основных характеристик, ради которых вообще делается appliance.

Картинку я сделал на конференции. Искать что-то дополнительно у меня времени нет. DSN — не моя тема. Но если у вас есть интерес, вы можете нагуглить какие-нибудь дебаты по этому поводу. У меня в данный момент такого интереса нет.

Хотя если у вас есть данные по поводу того, как Исилон у какого-то заказчика, по вашему утверждению, показывал низкую производительность, я бы с удовольствием на них взглянул. Потому что это моя тема.
«Кроме того, поддержка работоспособности как оборудования, так и Open Source-решений целиком и полностью ложится на самих пользователей.» — если на оборудование поставить Open Source решение типа OpenStack, то оборудование не «слетит» с поддержки производителя. А что касается софта, то помимо бесплатной поддержки сообществом разработчиков, поддержку на тот же OpenStack можно приобрести у Red Hat, HP и других вендоров.
Привлекательность таких систем в их распределённости и автоматической репликацией между зонами, регионами и т.д. Однако, это всё-таки банальная свалка «ключ-значение». Хранение метаданных хотя и допустимо, например в Ceph, но бесполезно, потому что поиска по метаданным нет. Можно велосипедить разные миддлвари для подхвата метаданных и сохранения их в отдельной или той же базе, но тогда встанет проблема репликации и синхронизации соответствия «метаданные-значение». В общем, имхо, пока это не очень нужно.
Sign up to leave a comment.