>70 миллионов объектов спокойно и неторопясь двигаются. А зачем их двигать срочно?
я неправильно выразился — заставьте свифт синкнуть такое количество объектов внутренними средствами — получите rsync которого убил oom и вставшее хранилище
>Насчёт «заплатить», давайте я задам вам другой вопрос: цены EMC в сравнении с рынком object storage'ей? Скажем, в перспективе >пятилетней аммортизации на объёмах в, допустим, 500 Тб. Поскольку за трафик и так и так платить, будем считать, что «обязательного» >трафика там только на «закачал/скачал» (то есть по 500Тб).
я вам тут так отвечу — купить и использовать ECS будет дешевле процентов на 70 в 5-ти летней перспективе на такой объем чем собирать и поддерживать самостоятельно
Попробуйте переместить в свифте 70 миллионов объектов с ноды на ноду и вопросы отпадут ;)
Ceph — чудо а не продукт, но вот librados часто не дает работать.
Это не вопрос почему EMC, а вопрос «почему я должен заплатить?» — ответ на него всегда один — хотите держать команду которая будет вам пилить хранилище — держите, разумеется не забудьте учесть все риски которые с этим связаны, а как человек который покушал на создании такого рода продуктов, я вам скажу что их будет в разы больше чем при покупке готового хранилища.
Можно вечно пилить на коленке, это очень круто и весело, но увы результат не так хорошо работает как хотелось бы.
>Таким образом, есть некий алгоритм «равномерного распределения». Который может учитывать количество lun'ов, их размер, ещё какие-то особенности, возможно, резервирования и т.д. И всё это может чуть-чуть вести себя не так, как ожидает клиент. И клиент не может понять, почему было принято то или иное решение.
клиент всегда может понять почему было принято то или иное решение, потому что компания EMC всегда с радостью может это объяснять клиенту
>Более эффективные IT-отделы стараются обладать достаточной компетенцией для того, чтобы получать ответ «что не так» или «что нужно поправить» без привлечения всей цепочки из уровней поддержки (а первым в этой цепочке становится персонал заказчика, который без понимания «нутра» не может адекватно сформулировать проблему)
ИТ отделы делятся на 2 типа — тех кто реализует все самостоятельно из простых элементов и тех кто покупает сложные элементы у компаний на них специализирующихся, оба варианта вообщем-то жизнеспособны и вопрос их эффективности не так однозначен
Идея такая — вы собираете все массивы в некую виртуальную сущность (по сути на практике только группа которая существует внутри ViPR, то есть траффик он через себя никак не гоняет, только управляет), в которую объединены массивы целиком либо кусками (определенные порты и пулы дисков), и вот внутри этой группы система старается распределить утилизацию емкости максимально равномерно между физическими сущностями
Это очень хорошее замечание и очень хороший повод для холивара. Попытаюсь остановить его во избежании. Суть в том что Controller — это не конструктор для оркестрации а средство для решения определенного рода задач которые не решаются большим количеством разных способов, потому что технологии с которыми оно работает являются жестко стандартизированными, другими словами нарезать лун на массиве EMC VNX или IBM DS можно грубо говоря только определенной командой, что исключает ошибку, также как и создать зону на SAN коммутаторе можно только одним способом. Другими словами EMC гарантирует решение определенного рода задач определенным документированным набором способов и не более того.
К сожалению ваша деятельность не и нет отношения к управлению продуктом.
я неправильно выразился — заставьте свифт синкнуть такое количество объектов внутренними средствами — получите rsync которого убил oom и вставшее хранилище
>Насчёт «заплатить», давайте я задам вам другой вопрос: цены EMC в сравнении с рынком object storage'ей? Скажем, в перспективе >пятилетней аммортизации на объёмах в, допустим, 500 Тб. Поскольку за трафик и так и так платить, будем считать, что «обязательного» >трафика там только на «закачал/скачал» (то есть по 500Тб).
я вам тут так отвечу — купить и использовать ECS будет дешевле процентов на 70 в 5-ти летней перспективе на такой объем чем собирать и поддерживать самостоятельно
Ceph — чудо а не продукт, но вот librados часто не дает работать.
Это не вопрос почему EMC, а вопрос «почему я должен заплатить?» — ответ на него всегда один — хотите держать команду которая будет вам пилить хранилище — держите, разумеется не забудьте учесть все риски которые с этим связаны, а как человек который покушал на создании такого рода продуктов, я вам скажу что их будет в разы больше чем при покупке готового хранилища.
Можно вечно пилить на коленке, это очень круто и весело, но увы результат не так хорошо работает как хотелось бы.
клиент всегда может понять почему было принято то или иное решение, потому что компания EMC всегда с радостью может это объяснять клиенту
>Более эффективные IT-отделы стараются обладать достаточной компетенцией для того, чтобы получать ответ «что не так» или «что нужно поправить» без привлечения всей цепочки из уровней поддержки (а первым в этой цепочке становится персонал заказчика, который без понимания «нутра» не может адекватно сформулировать проблему)
ИТ отделы делятся на 2 типа — тех кто реализует все самостоятельно из простых элементов и тех кто покупает сложные элементы у компаний на них специализирующихся, оба варианта вообщем-то жизнеспособны и вопрос их эффективности не так однозначен