Comments 98
Я от серверов далек. Поэтому —
нифига себе — цены. Это чтож получается, может оказаться, что когда mail.ru раздовал в облаке терабайты — каждый пользователь в минус тыщу баксов получился?
нифига себе — цены. Это чтож получается, может оказаться, что когда mail.ru раздовал в облаке терабайты — каждый пользователь в минус тыщу баксов получился?
Во-первых, это цена по прайсу. В реальности обычно применяется либо объёмная, либо иная скидка.
Во-вторых, это очень низкая цена, если сравнивать с ценой сырого места при покупке новой СХД Enterprise-уровня. В-третьих, привыкайте — чем быстрее что-то работает, тем дороже стоит. Вот, посмотрите на коробочку: habrahabr.ru/company/croc/blog/214139/ и habrahabr.ru/company/croc/blog/220319/
Во-вторых, это очень низкая цена, если сравнивать с ценой сырого места при покупке новой СХД Enterprise-уровня. В-третьих, привыкайте — чем быстрее что-то работает, тем дороже стоит. Вот, посмотрите на коробочку: habrahabr.ru/company/croc/blog/214139/ и habrahabr.ru/company/croc/blog/220319/
В mail.ru почти наверняка используется открытое ПО и собственные разработки, а это продукт для коммерческих (не ИТ) компаний и корпораций.
В mail.ru скорее всего бесплатный глюстр или еще что.
Точно $1572/Тб сырой (т.е. емкости носителей в серверах)?
Т.е. за лицензию на каждый 1U сервер с 4-я 2Тб дисками нужно будет заплатить $6288?
Т.е. за лицензию на каждый 1U сервер с 4-я 2Тб дисками нужно будет заплатить $6288?
Ceph тут мне кажется более бюджетным. В простом варианте использование бесплатно.
Коммерческая поддержка 24*7 стоит $13500/в год за 64Тб ёмкости.
Т.е. некритичные данные вроде тестировщиков и разработчиков можно располагать просто бесплатно.
При использовании для важных данных их поддержка получается заметно дешевле, чем ScaleIO.
Коммерческая поддержка 24*7 стоит $13500/в год за 64Тб ёмкости.
Т.е. некритичные данные вроде тестировщиков и разработчиков можно располагать просто бесплатно.
При использовании для важных данных их поддержка получается заметно дешевле, чем ScaleIO.
Я не знаком с Ceph настолько, насколько это необходимо для полноценного сравнения. Навскидку могу сказать следующее: Ceph нельзя установить на Windows. В нем нельзя ограничить скорость клиентам. Я не знаком с качеством поддержки RHEL для данного продукта. Есть у них круглосуточное дежурство или нужно писать письма в комьюнити? В некоторых случаях Ceph, возможно, будет более оправдан, чем ScaleIO, но нужно смотреть под конкретную задачу.
Кстати да — интересно было бы посмотреть на сравнение — чем за свою стоимость ScaleIO лучше/хуже бесплатного ceph или ceph с коммерческой поддержкой. Вот ваш коллега AlBelyaev пишет что Крок внедряет и ceph в том числе habrahabr.ru/company/croc/blog/244085/
Заголовок спойлера
Тот же Ceph может стать отличной альтернативой для небольших офисов и может работать прямо на самих гипервизорах, если поставить в них побольше дисков. Таким образом можно соединить гипервихзор с СХД и существенно сэкономить на оборудовании. Но, конечно же, это все требует достаточно тонкой первоначальной настройки и сайзинга. В большой инсталляции может стать основой хранения данных, причем по скорости сравнимой с mid-range, hi-end массивами при правильной настройке. Не даром ведь их используют многие крупные провайдеры облачных услуг.
Да, у Ceph есть enterprise-поддержка: www.inktank.com/enterprise/
0.01$/Gb/month — довольно демократичные деньги за 24/7, как мне кажется.
0.01$/Gb/month — довольно демократичные деньги за 24/7, как мне кажется.
В списках совместимых/поддерживаемых клиентов только линукс. А бизнесу нужна, допустим, вмварь.
Как раз это не проблема. Блочные устройства легко экспортируются через iSCSI или SAN. А дальше — дело техники.
Смеешься что-ли? Да это основная проблема для бизнеса в европе/сша. Ни кто не купит поддержку, если нет в списке совместимости твоей платформы. А значит ни кто не даст добро и на использование самого продукта.
Если есть деньги — пусть покупают. А мне на данный момент нравится Ceph. У него хороший потенциал.
Денег дофига. Но не купят.
Бизнесу нужен не «потенциал», бизнесу нужно «работает». А вот с «работает» у ceph — беда.
Думаете просто так что ли, при всем его «потенциале» в продакшне о ceph говорят считаные единицы. Спросите у teraflops, сколько они у себя в Performix пилили ceph для продакшна.
Думаете просто так что ли, при всем его «потенциале» в продакшне о ceph говорят считаные единицы. Спросите у teraflops, сколько они у себя в Performix пилили ceph для продакшна.
Вот нашел пост от Перформикс про Ceph: habrahabr.ru/company/performix/blog/218065/
Статья довольно в оптимистичном ключе. Не знаю, конечно, как сейчас у них.
Откуда вы взяли информацию о том, что «с «работает» у ceph — беда»? Можно какие-то конкретные источники? Мне действительно интересно, потому что мы у себя тоже хотим его внедрить в том или ином виде. Пока что я не видел каких-то блокирующих outstanding issues у Ceph, наоборот многие компании продвигают эту технологию, например Fujitsu Eternus CD10000, не говоря уже о Red Hat Storage Cluster и SuSe Storage.
Статья довольно в оптимистичном ключе. Не знаю, конечно, как сейчас у них.
Откуда вы взяли информацию о том, что «с «работает» у ceph — беда»? Можно какие-то конкретные источники? Мне действительно интересно, потому что мы у себя тоже хотим его внедрить в том или ином виде. Пока что я не видел каких-то блокирующих outstanding issues у Ceph, наоборот многие компании продвигают эту технологию, например Fujitsu Eternus CD10000, не говоря уже о Red Hat Storage Cluster и SuSe Storage.
«Два года назад Ceph подкупил нас своими впечатляющими возможностями. Хотя многие из них на тот момент работали совсем не идеально, мы приняли решение строить облако именно на нем. В последующие месяцы мы столкнулись с рядом проблем, доставивших нам немало неприятных минут.
Например, сразу после публичного релиза год назад мы обнаружили, что перестроение кластера влияет на его отзывчивость больше, чем хотелось бы. Или что определенный вид операций приводит к существенному увеличению латенси последующих операций. Или что в определенных (к счастью, редких) условиях клиентская виртуальная машина может намертво зависнуть на I/O. „
Вы не у меня спрашивайте, вы у него спрашивайте. :-|
Если для вас баги сразу после резиза и два года на багфикс это — “оптимистично», то я завидую оптимизму вашего руководства, дающего деньги на такое.
Например, сразу после публичного релиза год назад мы обнаружили, что перестроение кластера влияет на его отзывчивость больше, чем хотелось бы. Или что определенный вид операций приводит к существенному увеличению латенси последующих операций. Или что в определенных (к счастью, редких) условиях клиентская виртуальная машина может намертво зависнуть на I/O. „
Вы не у меня спрашивайте, вы у него спрашивайте. :-|
Если для вас баги сразу после резиза и два года на багфикс это — “оптимистично», то я завидую оптимизму вашего руководства, дающего деньги на такое.
Вы так рассказываете, как будто вендорские решения идеальны. Баги есть везде и везде они доставляют «немало неприятных минут/дней/месяцев». В случае тру продакшн систем решений приходится порой ждать по полгода.
Считаю данный спор лишенным смысла. Все всем и так понятно.
Считаю данный спор лишенным смысла. Все всем и так понятно.
Не додумываейте за меня то, что я не говорил, иначе спор и правда лишается смысла.
Но в случае «вендорского решения» ваши риски страхуются тем, что за баги несет персональную ответственность не абстрактное «сообщество», а конеретные люди в конкретной компании, которым вы платите деньги за поддержку, и имеете право требовать решения вашей проблемы. И вы знаете, что проблемой, когда она возникнет, будут заниматься профессионалы высокого класса, а не поставившие систему неделю назад, как в случае, когда с багой столкнетесь лично вы. Для бизнеса такое страхование рисков очень важно, именно поэтому бизнес и выбирает RedHat, а не, допустим, CentOS (не хочу говорить, что _никогда_ не выбирает CentOS, специально уточняю для желающих «повычитывать» из моих слов, я лишь говорю почему берут RedHat, когда «есть такой же точно CentOS»).
Но в случае «вендорского решения» ваши риски страхуются тем, что за баги несет персональную ответственность не абстрактное «сообщество», а конеретные люди в конкретной компании, которым вы платите деньги за поддержку, и имеете право требовать решения вашей проблемы. И вы знаете, что проблемой, когда она возникнет, будут заниматься профессионалы высокого класса, а не поставившие систему неделю назад, как в случае, когда с багой столкнетесь лично вы. Для бизнеса такое страхование рисков очень важно, именно поэтому бизнес и выбирает RedHat, а не, допустим, CentOS (не хочу говорить, что _никогда_ не выбирает CentOS, специально уточняю для желающих «повычитывать» из моих слов, я лишь говорю почему берут RedHat, когда «есть такой же точно CentOS»).
Так купите поддержку ceph и получите её прямо от разработчиков продукта. В чём противоречие?
Знаю я эту ответственность, пока не купишь премьер поддержку ответы будут вида обновите/перезагрузите/переустановите или «это баг, исправавим когда-нибудь».
Кстати, у EMC софтовая поддержка такая же бесполезная, как у VMware или всё же получше?
Кстати, у EMC софтовая поддержка такая же бесполезная, как у VMware или всё же получше?
Я когда вижу такую реакцию у представителей корпоративно-внедренческого сектора — сразу вспоминаю классическую цепочку Отрицание-Гнев-Торг-Депрессия-Принятие :) В общем, чтобы не было этих спекуляций про 2 года багов в продакшене, даю хронологию:
Это май 2012, когда мы начали разработку.
Это февраль 2013, когда мы выкатили это на публику.
Это до сентября 2014, когда мы эти баги окончательно устранили.
Итого да, 6-8 месяцев мы фиксили проблемы (скачки латенси при перестроениях), которые вскрылись лишь на реальной нагрузке. Доставили ли они нам неприятностей? Да. Были ли они фатальны в наших условиях? Нет. Не жалеем ли мы о выборе? Точно нет, достаточно сравнить функциональность и цены у нас и тех, кто выбрал «надежные решения от серьезных вендоров».
Это кстати все было 2 версии назад (релиз bobtail), сейчас мы используем версию ceph dumpling, в которой все эти проблемы решены и все стабильно работает «из коробки», приятно осознавать, что и мы чуть-чуть приложили к этому руку тоже.
Недавно узнал про один российский банк, который перевез инфраструктуру в Ceph ;)
Два года назад Ceph подкупил нас своими впечатляющими возможностями
Это май 2012, когда мы начали разработку.
Например, сразу после публичного релиза год назад мы обнаружили, что перестроение кластера влияет на его отзывчивость больше, чем хотелось бы
Это февраль 2013, когда мы выкатили это на публику.
В последующие месяцы мы столкнулись с рядом проблем, доставивших нам немало неприятных минут
Это до сентября 2014, когда мы эти баги окончательно устранили.
Итого да, 6-8 месяцев мы фиксили проблемы (скачки латенси при перестроениях), которые вскрылись лишь на реальной нагрузке. Доставили ли они нам неприятностей? Да. Были ли они фатальны в наших условиях? Нет. Не жалеем ли мы о выборе? Точно нет, достаточно сравнить функциональность и цены у нас и тех, кто выбрал «надежные решения от серьезных вендоров».
Это кстати все было 2 версии назад (релиз bobtail), сейчас мы используем версию ceph dumpling, в которой все эти проблемы решены и все стабильно работает «из коробки», приятно осознавать, что и мы чуть-чуть приложили к этому руку тоже.
Недавно узнал про один российский банк, который перевез инфраструктуру в Ceph ;)
Для ScaleIO сырое место — это объем исходного диска, видный в операционной системе (тот, который софт может использовать). Если у нас есть 4 2Тб диска, собранные в R5 (хотя для дисков таких размеров я предпочитаю R6), то мы получаем 3*4=14 Тб сырого места, что будет стоить 18864 $. Дальше нужно учесть скидку, которая зависит в том числе и от объема купленного места.
Угу, мы оба ошились. Я случайно посчитал 4ТБ вместо 12, а вы 14 вместо 6.
Если 4 диска по 2Тб, то это всё же получается в сумме 8Тб, с учетом RAID5 — 6ТБ.
Т.е. правильная стоимость за 4 диска по 2Тб в RAID5 получается $9432.
Никак на бюджетное антикризисное решение не похоже.
Если 4 диска по 2Тб, то это всё же получается в сумме 8Тб, с учетом RAID5 — 6ТБ.
Т.е. правильная стоимость за 4 диска по 2Тб в RAID5 получается $9432.
Никак на бюджетное антикризисное решение не похоже.
UFO just landed and posted this here
У меня такое ощущение, что это и есть Ceph под низом. Веб-морда по крайней мере очень похожа. Да и в целом подход.
я думаю для вас не секрет такой проект, как ceph? вы сравнивали их? какие плюсу у вашего решения, кроме саппорта?
> Не спешите выкидывать старые серверы
"… сделайте это не торопясь, с удовольствием".
Да, если ценность информации равна нулю, то можно ее хранить на устройствах с падающей надежностью и без поддержки. Но у многих другая ситуация.
"… сделайте это не торопясь, с удовольствием".
Да, если ценность информации равна нулю, то можно ее хранить на устройствах с падающей надежностью и без поддержки. Но у многих другая ситуация.
> то можно ее хранить на устройствах с падающей надежностью
Сетевая распределенная фс как раз делает надежность одного узла не критичной.
Вышедший узел заменяется на современный.
Следовательно вместо покупки 10 новых сразу, вы используете старые на убой, и покупаете новые только по фактическому выходу, а не по мифическим «3 годам в работе».
Сетевая распределенная фс как раз делает надежность одного узла не критичной.
Вышедший узел заменяется на современный.
Следовательно вместо покупки 10 новых сразу, вы используете старые на убой, и покупаете новые только по фактическому выходу, а не по мифическим «3 годам в работе».
Станет ли вас греть эти теоретические знания, когда у вас посыпятся диски один за другим (см. широкоизвестный обзор google на счет уровня надежности дисков после 3 лет эксплуатации), группами (такое многие видели), или будут отваливаться узлы целиком, потому что в новом обновлении драйверов ваш контроллер уже не поддерживается, и потому не тестировался.
О, я много могу забавного рассказать, за годы эксплуатации большого парка много повидать пришлось.
В общем, хозяин-барин, но мое мнение, что старому железу место на свалке (истории), и уж точно не стоит на этом хосписе городить хранение сколь-нибудь ценных данных.
О, я много могу забавного рассказать, за годы эксплуатации большого парка много повидать пришлось.
В общем, хозяин-барин, но мое мнение, что старому железу место на свалке (истории), и уж точно не стоит на этом хосписе городить хранение сколь-нибудь ценных данных.
> или будут отваливаться узлы целиком
Все вышеописанные случаи равняются этому.
Выводим узел, ремонтируем или заменяем, вводим обратно.
Когда количество выходов из строя растет — ставим новые. Сохраняем инвестиции, что не потребовалось покупать сразу целую новую инфраструктуру. У которой количество отказов совсем не обязательно будет меньше. (про пик отказов первого месяца работы помним?)
> в новом обновлении драйверов ваш контроллер уже не поддерживается
По этому в обзоре собрана конфигурация с половиной винды, половиной линукса. Даже такое ее не убъет. На самом деле я вообще не вижу смысла обновлять ось на сторадж нодах в san сети.
> старому железу место на свалке (истории), и уж точно не стоит на этом хосписе городить хранение сколь-нибудь ценных данных.
Я таки и не увидел, в чем же разница между старым и новым железом для сетевой распределенной файловой системы.
Все вышеописанные случаи равняются этому.
Выводим узел, ремонтируем или заменяем, вводим обратно.
Когда количество выходов из строя растет — ставим новые. Сохраняем инвестиции, что не потребовалось покупать сразу целую новую инфраструктуру. У которой количество отказов совсем не обязательно будет меньше. (про пик отказов первого месяца работы помним?)
> в новом обновлении драйверов ваш контроллер уже не поддерживается
По этому в обзоре собрана конфигурация с половиной винды, половиной линукса. Даже такое ее не убъет. На самом деле я вообще не вижу смысла обновлять ось на сторадж нодах в san сети.
> старому железу место на свалке (истории), и уж точно не стоит на этом хосписе городить хранение сколь-нибудь ценных данных.
Я таки и не увидел, в чем же разница между старым и новым железом для сетевой распределенной файловой системы.
Вся причина в том, что вы — «теоретик», а я — практик. Лет 10 назад я тоже таким был, верил в сказки вендоров, например, и во всемогуший Линукс, да благословит его Аллах и приветствует. А сейчас — стал старше, опыта прибавилось, и в красивые рассказки я уже не верю.
А в то, что у дисков после 3-4 лет эксплуатации AFR возрастает втрое-впятеро, это как минимум, уже не просто верю, я это знаю. Но, как известно, чужие ошибки никого не учат.
А в то, что у дисков после 3-4 лет эксплуатации AFR возрастает втрое-впятеро, это как минимум, уже не просто верю, я это знаю. Но, как известно, чужие ошибки никого не учат.
Переход на личности — очень ок. Как еще доказать свою т.з., как не назвав оппонента школотой?
Вторая попытка будет?
Вторая попытка будет?
Я не вижу тут предмета спора, извините. Для меня принципиально нерешаемая проблема с (не)надежностью лишает обсуждаемое решение самого предмета спора.
Я ж не спорю, наверное есть спрос и на такое «хоронилище данных», но автор явно не указывает на проблемы, вводя в заблуждение таких теоретиков с их фантазиями про «надежную сетевую распределенную фс».
Я ж не спорю, наверное есть спрос и на такое «хоронилище данных», но автор явно не указывает на проблемы, вводя в заблуждение таких теоретиков с их фантазиями про «надежную сетевую распределенную фс».
широкоизвестный обзор google на счет уровня надежности дисков после 3 лет эксплуатациигде бы почитать?
Полновесный SAN с новым железом будет стоить как этот софт. Очень странная ценовая политика.
Только entry level san, который на серьезную нагрузку не поставишь.
Можно подумать всякий старый хлам кто-то будет ставить под серьёзную нагрузку
Чем старый хлам отличается от нового хлама?
Износом, более низкой производительностью, отсутствием гарантии, это навскидку если не вдаваться в то, почему вы вообще используете словосочетание «новый хлам»
> Износом
И… На что это влияет?
> более низкой производительностью
Производительностью чего именно?
> отсутствием гарантии
Что меняется от наличия гарантии?
> почему вы вообще используете словосочетание «новый хлам»
Потому, что с т.з. построения sds на базе ndfs — все выглядит в другом свете. И новые ноды будут покупаться примерно такими же, как старые, ибо большой проц, куча памяти, быстрые диски там не нужны, там нужна минимальная цена за ноду.
И… На что это влияет?
> более низкой производительностью
Производительностью чего именно?
> отсутствием гарантии
Что меняется от наличия гарантии?
> почему вы вообще используете словосочетание «новый хлам»
Потому, что с т.з. построения sds на базе ndfs — все выглядит в другом свете. И новые ноды будут покупаться примерно такими же, как старые, ибо большой проц, куча памяти, быстрые диски там не нужны, там нужна минимальная цена за ноду.
>И… На что это влияет?
Очевидно, количество инцидентов выхода из строя компонентов стореджа будет выше. Непредсказуемо выше.
>Производительностью чего именно?
Количество IOPS харда 10-летней давности может вполне быть раз в 10 меньше современного. То есть SAN на старом хламе будет занимать еще и в 10 раз больше места, потреблять в 10 раз больше электричества, иметь непомерные требования к системе охлаждения серверной
Очевидно, количество инцидентов выхода из строя компонентов стореджа будет выше. Непредсказуемо выше.
>Производительностью чего именно?
Количество IOPS харда 10-летней давности может вполне быть раз в 10 меньше современного. То есть SAN на старом хламе будет занимать еще и в 10 раз больше места, потреблять в 10 раз больше электричества, иметь непомерные требования к системе охлаждения серверной
> Очевидно, количество инцидентов выхода из строя компонентов стореджа будет выше. Непредсказуемо выше.
При условии, что выход одного хоста не влияет на производительность и не сильно уменьшает избыточность — нас это может совсем не волновать.
> Количество IOPS харда 10-летней давности может вполне быть раз в 10 меньше
Нет, за 10 лет производительность хардов не менялась.
> То есть SAN на старом хламе будет занимать еще и в 10 раз больше места,
С чего вдруг?
Или у нас за десять лет 3.5 дюймовые диски уменьшились в линейных размерах в 10 раз?
В конце концов, ни кто не мешает в старые сервера поставить свежие диски, это относительно копеерчная операция.
> потреблять в 10 раз больше электричества, иметь непомерные требования к системе охлаждения серверной
Тут соглашусь только частично.
Миграция с хостов xeon e5XXX на xeon e5-2640v2 сэкономила нам примерно 25% потребления и охлаждения, при той же нагрузке. Разница поколений 3-4 года. Как раз то, что считается «старым» и подлежит списанию.
25% потребления может оказаться допустимым, особенно для небольших компаний с собственными серверными, где нет недостатка в подводе.
При условии, что выход одного хоста не влияет на производительность и не сильно уменьшает избыточность — нас это может совсем не волновать.
> Количество IOPS харда 10-летней давности может вполне быть раз в 10 меньше
Нет, за 10 лет производительность хардов не менялась.
> То есть SAN на старом хламе будет занимать еще и в 10 раз больше места,
С чего вдруг?
Или у нас за десять лет 3.5 дюймовые диски уменьшились в линейных размерах в 10 раз?
В конце концов, ни кто не мешает в старые сервера поставить свежие диски, это относительно копеерчная операция.
> потреблять в 10 раз больше электричества, иметь непомерные требования к системе охлаждения серверной
Тут соглашусь только частично.
Миграция с хостов xeon e5XXX на xeon e5-2640v2 сэкономила нам примерно 25% потребления и охлаждения, при той же нагрузке. Разница поколений 3-4 года. Как раз то, что считается «старым» и подлежит списанию.
25% потребления может оказаться допустимым, особенно для небольших компаний с собственными серверными, где нет недостатка в подводе.
>Нет, за 10 лет производительность хардов не менялась.
SSD сильно быстрее. У механики как минимум скорость последовательного чтения сильно увеличилась (если объём большой). SAS 12 думаете просто так на харды ставят?
SSD сильно быстрее. У механики как минимум скорость последовательного чтения сильно увеличилась (если объём большой). SAS 12 думаете просто так на харды ставят?
> SSD сильно быстрее.
Речь про ssd в серверах. которые на выброс явно не идет.
> У механики как минимум скорость последовательного чтения сильно увеличилась
Никому не нужна линейная скорость. Стор оценивается исключительно по iops, которые для механики не менялись уже очень давно.
> SAS 12 думаете просто так на харды ставят?
На харды — просто так.
Основным узким горлом, ради чего развивают sas — линк между контроллером и экспандером. И, частично, из-за ssd. Механическим дискам до лимитов sas еще как до луны.
Речь про ssd в серверах. которые на выброс явно не идет.
> У механики как минимум скорость последовательного чтения сильно увеличилась
Никому не нужна линейная скорость. Стор оценивается исключительно по iops, которые для механики не менялись уже очень давно.
> SAS 12 думаете просто так на харды ставят?
На харды — просто так.
Основным узким горлом, ради чего развивают sas — линк между контроллером и экспандером. И, частично, из-за ssd. Механическим дискам до лимитов sas еще как до луны.
>Речь про ssd в серверах
Речь о том, что новое производительнее старого, а не о сравнение механики 137GB 2004 vs 2014 годов
Речь о том, что новое производительнее старого, а не о сравнение механики 137GB 2004 vs 2014 годов
> Речь о том, что новое производительнее старого
А я говорю о том, что производительность проца, памяти, сети не важна, ты в любом случае упрешься в скорость конечных шпинделей.
И сетевая распределенная система — способ получить скорость всех дисков в стойке, не важно в каком сервере они стоят, а хорошая избыточность — позволяет не переживать о выходе половины серверов из строя.
А я говорю о том, что производительность проца, памяти, сети не важна, ты в любом случае упрешься в скорость конечных шпинделей.
И сетевая распределенная система — способ получить скорость всех дисков в стойке, не важно в каком сервере они стоят, а хорошая избыточность — позволяет не переживать о выходе половины серверов из строя.
>Никому не нужна линейная скорость
нам нужна.
нам нужна.
Видео-монтаж?
Я давно не видел корпоративных заказчиков, которым бы нужен был линейный трансфер. 95% это виртуализация, oltp, веб и т.п. где бутылочное горло это iops.
Я давно не видел корпоративных заказчиков, которым бы нужен был линейный трансфер. 95% это виртуализация, oltp, веб и т.п. где бутылочное горло это iops.
Виртуалки надо куда-то бакапить
Не смешите, scaleio и прочие distributed fs, это оверкилл для баккапа.
Ленточная библиотека будет в эн раз дешевле, удобнее и надежнее.
Ну или баккап для бедных — обычные серваки набитые большими nl-sas дисками с софтрейдом.
Ленточная библиотека будет в эн раз дешевле, удобнее и надежнее.
Ну или баккап для бедных — обычные серваки набитые большими nl-sas дисками с софтрейдом.
Да, у нас бакап для бедных, хотя RAID и аппаратный. Про дешевизну и удобство ленты — это только в рекламных листовках, на деле выходит или очень дорого (лицензии, резервные приводы, vault, регулярная чистка приводов, профилактическая перемотка, задержки на доступ к данным и прочие радости) или неудобно, или не надёжно, или и то и другое.
И да, современный механический диск имеет многократно больший объём чем старый, что важно всем, кроме юзеров scaleio (правда приятная схема лицензирования — за объем?)
И да, современный механический диск имеет многократно больший объём чем старый, что важно всем, кроме юзеров scaleio (правда приятная схема лицензирования — за объем?)
> Да, у нас бакап для бедных, хотя RAID и аппаратный.
У нас есть анналогичные: на 2u платформу запросто влезает 24+ Tb, под zfs с компрессией влезает до 40+ Tb реальных данных.
> Про дешевизну и удобство ленты — это только в рекламных листовках
В трех компаниях разного размера стояли что-то типа от msl4048, msl2024. Впечатления хорошие, себя оправдывали.
> или неудобно, или не надёжно, или и то и другое.
Что-то тут не так. Их бы ни кто не брал, если бы все это было правдой.
> современный механический диск имеет многократно больший объём чем старый, что важно всем
В типичных серверах, которые мы выкидываем (на 3-4 год эксплуатации) стоят 450gb 15k sas. В типичных серверах устанавливаемых сейчас стоят 600gb 15k sas. Не тут «многократно большего» объема. Не так давно появились 900gb 15k, но еще не стали типовым решением.
У нас есть анналогичные: на 2u платформу запросто влезает 24+ Tb, под zfs с компрессией влезает до 40+ Tb реальных данных.
> Про дешевизну и удобство ленты — это только в рекламных листовках
В трех компаниях разного размера стояли что-то типа от msl4048, msl2024. Впечатления хорошие, себя оправдывали.
> или неудобно, или не надёжно, или и то и другое.
Что-то тут не так. Их бы ни кто не брал, если бы все это было правдой.
> современный механический диск имеет многократно больший объём чем старый, что важно всем
В типичных серверах, которые мы выкидываем (на 3-4 год эксплуатации) стоят 450gb 15k sas. В типичных серверах устанавливаемых сейчас стоят 600gb 15k sas. Не тут «многократно большего» объема. Не так давно появились 900gb 15k, но еще не стали типовым решением.
>Что-то тут не так. Их бы ни кто не брал, если бы все это было правдой.
Всё так. Юзеры библиотек делятся на 2 категории: на тех, которых развели на их покупку (и они еще тупо не столкнулись со всеми их прелестями) и на тех, кто по закону обязан хранить резервные копии много-много лет (это единственное внятное оправдание этого ахтунга).
Всё так. Юзеры библиотек делятся на 2 категории: на тех, которых развели на их покупку (и они еще тупо не столкнулись со всеми их прелестями) и на тех, кто по закону обязан хранить резервные копии много-много лет (это единственное внятное оправдание этого ахтунга).
Не, не так.
Есть куча мест, где библиотека оптимальное решение, начиная с какого-то порога хранимых данных.
Например msl4048 с приводами lto-6 вмещает 300tb данных.
Анналогичное хранилище на 4tb винтах будет стоить в несколько раз дороже и занимать целую стойку, постоянно жрать электричество и холодный воздух.
Есть куча мест, где библиотека оптимальное решение, начиная с какого-то порога хранимых данных.
Например msl4048 с приводами lto-6 вмещает 300tb данных.
Анналогичное хранилище на 4tb винтах будет стоить в несколько раз дороже и занимать целую стойку, постоянно жрать электричество и холодный воздух.
У нас была msl4048. Правда с LTO3. Места не хватало, в том числе из-за не рационального использования лент при большом количестве различных политик удержания. Так же была постоянная конкуренция за привода: копируются два сервера с маленькой скоростью, в 10 раз медленнее чем привода позволяют — остальные 50 серваков стоят в очереди, окно резервного копирования сильно растягивается. Захотел в это время что-то восстановить — не-а, жди, все привода заняты. Освободился привод, думаешь — щас восстановлю — не-а, на ленту содержащую архив сейчас в соседнем приводе пишется еще другой архив. Захотел раскидать ленты по разным политикам чтоб такого не было — получи нерациональное использование суммарного объема лент. Так что заменили библиотеку на рейд массив из 2 полок с SATA дисками и радуемся. Места хватает и прогнозируется просто, про конкуренцию за ресурсы забыли, волосы стали гладкими и шелковистыми
Ну, если вы помещались на lto3, то понятно, почему современные диски удобнее.
Остальные претензии скорее к баккап софту, неоптимально использующему драйвы и очереди, чем собственно к библиотеке. Медленная скорость — проблема сети, мы библиотеки ставили в san сеть (обычно fc8), все сервера и полки успевали за окно.
Остальные претензии скорее к баккап софту, неоптимально использующему драйвы и очереди, чем собственно к библиотеке. Медленная скорость — проблема сети, мы библиотеки ставили в san сеть (обычно fc8), все сервера и полки успевали за окно.
Tier 1 пул всё равно оставлются на дисках, даже если не брать в расчёт RTO, то хотя бы ради возможности подмонтировать ВМ прямо из бекапа.
Есть _небольшое_ число мест, где библиотека оптимальное решение. Во всех остальных случаях это сегодня бессмысленное legacy.
Человек ниже все правильно перечислил.
> Анналогичное хранилище на 4tb винтах будет стоить в несколько раз дороже и занимать целую стойку,
Оно будет занимать 4U.
Например NetApp E5560 на 60 дисков 6TB NL-SAS.
И насччет «дороже» тоже очень спорно. Особенно если считать правильно и все вместе.
Человек ниже все правильно перечислил.
> Анналогичное хранилище на 4tb винтах будет стоить в несколько раз дороже и занимать целую стойку,
Оно будет занимать 4U.
Например NetApp E5560 на 60 дисков 6TB NL-SAS.
И насччет «дороже» тоже очень спорно. Особенно если считать правильно и все вместе.
> Например NetApp E5560 на 60 дисков 6TB NL-SAS.
Сравним:
Цена — стоимость только 60 дисков (берем самые дешевые sas 4tb в nix.ru) 900 т.р. (нетап даст ставить не свои диски?) Плюс цена нетапа.
Емкость — сырая емкость 240 тб. доступная будет порядка 200, это на треть меньше.
Потребление — 1.5 киловатта постоянно.
msl4048:
Цена — 800т.р. за библиотеку с 2 драйвами, 240 т.р. за 48 лент.
Потребление — 300 ватт в пике.
Итого я вижу большую цену за меньшую емкость. Разница не сильно критичная, но уже заметная.
Сравним:
Цена — стоимость только 60 дисков (берем самые дешевые sas 4tb в nix.ru) 900 т.р. (нетап даст ставить не свои диски?) Плюс цена нетапа.
Емкость — сырая емкость 240 тб. доступная будет порядка 200, это на треть меньше.
Потребление — 1.5 киловатта постоянно.
msl4048:
Цена — 800т.р. за библиотеку с 2 драйвами, 240 т.р. за 48 лент.
Потребление — 300 ватт в пике.
Итого я вижу большую цену за меньшую емкость. Разница не сильно критичная, но уже заметная.
Ха! У Нетапа пустой ящик стоит от 100 килобаксов, хотя штука действительно хорошая.
Специально для вас уточнил, что считать нужно правильно, а не только то, что вам хочется посчитать, потому что как в воду глядел ;)
Давайте ваши выкладки, иначе «знаю, но не скажу» получается.
У меня есть цены по прайслисту IBM, а у вас? И если кто-то может купить её за 30% от прайса, это совсем не показатель. Обычная компания из SME будет рада скидке в 30% от него.
IBM DCS3860
Один SSD на SAS 12 стоит как крыло от самолёта, при этом не все задачи упираются в IOPS, часто нужно много места при сравнительно небольшой нагрузке (тот же Exchange).
>Что меняется от наличия гарантии?
Повышается стоимость замены компонентов (гарантийное оборудование меняется бесплатно)
Повышается стоимость замены компонентов (гарантийное оборудование меняется бесплатно)
Для этого вам компонент купить нужно. Либо в начале эксплуатации (и с этого момента какое-то время будет течь гарантийный срок и, соответственно, будет бесплатная замена) либо в случае выхода из строя старого компонента (но в этом случае у вас будет какое-то время до выхода его из строя, т.е. вы заплатите что-то гораздо позже и, таким образом, сохраните часть инвестиций). Единственный минус в сохранении старого железа — потеря стандартизованности в результате эксплуатации одинакового железа. Это повышает стоимость владения. Насколько сильно — это вопрос.
> Для этого вам компонент купить нужно.
В счет зарплаты heathen, котрый придумал такой подход. А если heathen не нравится, что в счет его зарплаты покупают запчасти, то почему это должен считать нормальным владелец бизнеса? Потому что «закапывать» деньги в запчасти это, по сути, покупать их в зарплату этого самого владельца бизнеса, переводить активы в пассивы, отнимая их и средств, на которые компания может развиваться.
Это круто придумывать такое, когда деньги «дядины», но почему-то таких людей страшно удивляет, почему «дяди» при этом не в восторге от такого подхода.
В счет зарплаты heathen, котрый придумал такой подход. А если heathen не нравится, что в счет его зарплаты покупают запчасти, то почему это должен считать нормальным владелец бизнеса? Потому что «закапывать» деньги в запчасти это, по сути, покупать их в зарплату этого самого владельца бизнеса, переводить активы в пассивы, отнимая их и средств, на которые компания может развиваться.
Это круто придумывать такое, когда деньги «дядины», но почему-то таких людей страшно удивляет, почему «дяди» при этом не в восторге от такого подхода.
Вы совсем не вчитываетесь в то, что написано? Еще раз, более разжёвано:
Поиграем в Капитана Очевидность: чтобы получить гарантию, вам нужно компонент вначале купить. Вы можете купить полку, сервер, диск — не важно. Предположим, что вы купили несколько стоек с оборудованием, скажем, сто серверов за миллион долларов. В этот момент начинает течь гарантийный срок. Через какое-то время он заканчивается и, согласно вашей и ls1 логике, необходимо это оборудование выбросить и приобрести другое, выложив еще один миллион долларов. Само собой, это оборудование себя уже окупило, но владельцы бизнеса не любят выкладывать деньги тогда, когда этого можно избежать. Вместо того, чтобы оборудование выбрасывать, можно оставить его работать в сегментах, где присутствует множественное резервирование. Само собой, рано или поздно старое оборудование будет выходить из строя и понадобится покупать новое — на которое, так же само собой, начнёт течь новая гарантия. Но в этом случае не придётся тратить разом значительную сумму на полную замену, можно будет затраты растянуть. Вышел из строя сервер — заплатили десять тысяч долларов за новый. Вышел следующий — заплатили еще десять.
Прежде, чем пытаться быть саркастичным, стоит открыть хотя бы популярные книжки по экономике и финансам и почитать — для общего развития. Чтобы знать, что такое ROI или хотя бы временная стоимость денег и чем миллион долларов сегодня отличается от миллиона долларов через полгода. Для справки я вам могу сказать, что они на текущий момент будут отличаться как минимум на $34 521 — это та сумма, которую можно гарантированно получить, если эти деньги сейчас положить в банк из первой двадцатки крупнейших банков в стране.
Да, кстати, я являюсь владельцем бизнеса, причём в моём бизнесе нет ни копейки денег «дяди», «тёти», «родителей» и т.д. И как владелец бизнеса и консультант по ИТ-системам наших заказчиков я скажу, что резервные запчасти предусматриваются всегда, если проект хоть сколько-нибудь масштабен. И на сотню серверов хотя бы 1 сервер должен быть в холодном резерве, на тысячу дисков — 5-10 штук тоже. Потому что гарантированное время ремонта в 8 часов в контракте на расширенную гарантию 24\7 — это иногда слишком долго.
Имеет смысл так же добавить, что на сегодня практически все крупные вендоры продают пакеты пост-гарантийного обслуживания за достаточно вменяемые деньги, и срок гарантии можно продлить до 5 (а в некоторых случаях и больше) лет, но это принципиального значения в разрезе данной темы не имеет. Всё это делается ради одной цели — чтобы сделать разрыв между крупными вложениями средств как можно более значительным, а по возможности — избежать его полностью.
Поиграем в Капитана Очевидность: чтобы получить гарантию, вам нужно компонент вначале купить. Вы можете купить полку, сервер, диск — не важно. Предположим, что вы купили несколько стоек с оборудованием, скажем, сто серверов за миллион долларов. В этот момент начинает течь гарантийный срок. Через какое-то время он заканчивается и, согласно вашей и ls1 логике, необходимо это оборудование выбросить и приобрести другое, выложив еще один миллион долларов. Само собой, это оборудование себя уже окупило, но владельцы бизнеса не любят выкладывать деньги тогда, когда этого можно избежать. Вместо того, чтобы оборудование выбрасывать, можно оставить его работать в сегментах, где присутствует множественное резервирование. Само собой, рано или поздно старое оборудование будет выходить из строя и понадобится покупать новое — на которое, так же само собой, начнёт течь новая гарантия. Но в этом случае не придётся тратить разом значительную сумму на полную замену, можно будет затраты растянуть. Вышел из строя сервер — заплатили десять тысяч долларов за новый. Вышел следующий — заплатили еще десять.
Прежде, чем пытаться быть саркастичным, стоит открыть хотя бы популярные книжки по экономике и финансам и почитать — для общего развития. Чтобы знать, что такое ROI или хотя бы временная стоимость денег и чем миллион долларов сегодня отличается от миллиона долларов через полгода. Для справки я вам могу сказать, что они на текущий момент будут отличаться как минимум на $34 521 — это та сумма, которую можно гарантированно получить, если эти деньги сейчас положить в банк из первой двадцатки крупнейших банков в стране.
Да, кстати, я являюсь владельцем бизнеса, причём в моём бизнесе нет ни копейки денег «дяди», «тёти», «родителей» и т.д. И как владелец бизнеса и консультант по ИТ-системам наших заказчиков я скажу, что резервные запчасти предусматриваются всегда, если проект хоть сколько-нибудь масштабен. И на сотню серверов хотя бы 1 сервер должен быть в холодном резерве, на тысячу дисков — 5-10 штук тоже. Потому что гарантированное время ремонта в 8 часов в контракте на расширенную гарантию 24\7 — это иногда слишком долго.
Имеет смысл так же добавить, что на сегодня практически все крупные вендоры продают пакеты пост-гарантийного обслуживания за достаточно вменяемые деньги, и срок гарантии можно продлить до 5 (а в некоторых случаях и больше) лет, но это принципиального значения в разрезе данной темы не имеет. Всё это делается ради одной цели — чтобы сделать разрыв между крупными вложениями средств как можно более значительным, а по возможности — избежать его полностью.
Отказо- и катастрофоустойчивость чем будете обеспечивать за те же деньги?
Ходили слухи, что ScaleIO может заменить VSAN, очень хотелось бы почитать сравнение после выхода vSphere 6.0.
Вопросы энергопотребления/тепловыделения и занимаего пространства старого барахла не рассмотрены. А это порой важнее стоимости.
При позиционировании ScaleIO как «вторая жизнь старых серверов» почему-то упускается из виду то, что при ребилде нагрузка на диски возрастает. Вероятность выхода из строя оставшихся в живых дисков (помним, сервера «старые», хотя это справедливо для любой СХД в принципе) возрастает многократно. Это навскидку. Не говоря о нагрузке на «межсерверное» сетевое взаимодействие при ребилде. Так что, честно говоря — с такими ценами к тому же — непонятно зачем.
> при ребилде нагрузка на диски возрастает.
Ребилд от нормальной работы практически не отличается.
> Вероятность выхода из строя оставшихся в живых дисков возрастает многократно.
Просто надо правильно понимать какую идею вкладывают в использование старых серверов.
Ни кто не говорит что они будут работать вечно. Это способ не покупать десятки новых серверов прямо сейчас, а запустить структуру стороджа на том, что уже есть. Двухкратная избыточность позволяет спокойно относится к выходу целого хоста из строя, покупая новое железо только по фактической поломке старого. Постепенно, естетсвенно, все будет заменено, но нет больших единовременных затрат.
Ребилд от нормальной работы практически не отличается.
> Вероятность выхода из строя оставшихся в живых дисков возрастает многократно.
Просто надо правильно понимать какую идею вкладывают в использование старых серверов.
Ни кто не говорит что они будут работать вечно. Это способ не покупать десятки новых серверов прямо сейчас, а запустить структуру стороджа на том, что уже есть. Двухкратная избыточность позволяет спокойно относится к выходу целого хоста из строя, покупая новое железо только по фактической поломке старого. Постепенно, естетсвенно, все будет заменено, но нет больших единовременных затрат.
> Ребилд от нормальной работы практически не отличается.
Как сертифицированный инженер EMC я, без теоретических выкладок, просто даже исходя из опыта работы с хранилками (более 3х лет) — позволю себе не согласиться. При ребилде нагрузка на дисковую группу в целом и на отдельные диски в частности — возрастает. Аксиома вообще-то ))
> но нет больших единовременных затрат.
При таком ценнике на ScaleIO — спорное утверждение :)
Считаю, что ScaleIO — маркетинго-нишевой продукт. Возможно, подготовка к «гиперконвергентному» продукту, обкатка софта :)
Как сертифицированный инженер EMC я, без теоретических выкладок, просто даже исходя из опыта работы с хранилками (более 3х лет) — позволю себе не согласиться. При ребилде нагрузка на дисковую группу в целом и на отдельные диски в частности — возрастает. Аксиома вообще-то ))
> но нет больших единовременных затрат.
При таком ценнике на ScaleIO — спорное утверждение :)
Считаю, что ScaleIO — маркетинго-нишевой продукт. Возможно, подготовка к «гиперконвергентному» продукту, обкатка софта :)
> При ребилде нагрузка на дисковую группу в целом и на отдельные диски в частности — возрастает. Аксиома вообще-то
В классическом рейде — да. Тут не совсем вариант классческого рейда. Например теоретически есть возможность, скажем, для ребилда читать одну половину зеркала, а для пользователей вторую.
Далее речь в комментарии выше идет о «нагрузке, которая приводит к выходу из строя», я вот не вижу прямой зависимости между нагрузкой и частотой выхода из строя. Что нагруженые сторы, что резервные и баккапные — в среднем мы меняем диск раз в 2-3 месяца из каждой сотни.
> При таком ценнике на ScaleIO — спорное утверждение :)
Да, если нет скидки за объем, то не очень дешево.
> Возможно, подготовка к «гиперконвергентному» продукту, обкатка софта :)
Угу, последние год-два идет активный анонс сетевых распредененных систем: vsan, nutanix, storvisor, scaleio и т.п. Кажется индустрия созрела для таких решений, и в ближайшем времени будет трендом, как минимум для систем виртуализации.
В классическом рейде — да. Тут не совсем вариант классческого рейда. Например теоретически есть возможность, скажем, для ребилда читать одну половину зеркала, а для пользователей вторую.
Далее речь в комментарии выше идет о «нагрузке, которая приводит к выходу из строя», я вот не вижу прямой зависимости между нагрузкой и частотой выхода из строя. Что нагруженые сторы, что резервные и баккапные — в среднем мы меняем диск раз в 2-3 месяца из каждой сотни.
> При таком ценнике на ScaleIO — спорное утверждение :)
Да, если нет скидки за объем, то не очень дешево.
> Возможно, подготовка к «гиперконвергентному» продукту, обкатка софта :)
Угу, последние год-два идет активный анонс сетевых распредененных систем: vsan, nutanix, storvisor, scaleio и т.п. Кажется индустрия созрела для таких решений, и в ближайшем времени будет трендом, как минимум для систем виртуализации.
Есть еще бесплатный аналог Lustre. Я лично не пробовал, но мои знакомые довольны его использованием, а то 1500$ за терабайт по нынешним временам уж очень дорого!
+ еще стоимость железа на котором эти терабайты работают
да, в данном случае оно старое и уже было куплено, но вложения в него уже сделаны + железо вполне можно продать: и место на складе занимать не будет и совесть спокойна (что не выкинули, а оно продолжает работать). К вырученным деньгам добавить те же $1500/Тб и думаю вполне можно купить новое, более эффективное хранилище.
да, в данном случае оно старое и уже было куплено, но вложения в него уже сделаны + железо вполне можно продать: и место на складе занимать не будет и совесть спокойна (что не выкинули, а оно продолжает работать). К вырученным деньгам добавить те же $1500/Тб и думаю вполне можно купить новое, более эффективное хранилище.
Да, эти сервера как выразился автор «старого поколения», это возможно 15К винты по 36 (пусть даже 150) Гигов, которые жрут уйму энергии в расчете терабайт на киловат. Да, они быстрые, но как привел автор, что из этого всего нужно сделать архив, то лучше купить современные винты по 6 терабайт и ТСО будет феноменально низким по сравнению с винтами по 36 или 150 Гигов.
Скоро будет бесплатно ;-)
29 мая обещают выпустить бесплатную версию ScaleIO:
virtualgeek.typepad.com/virtual_geek/2015/05/emc-day-3-scaleio-unleashed-for-the-world.html
virtualgeek.typepad.com/virtual_geek/2015/05/emc-day-3-scaleio-unleashed-for-the-world.html
Sign up to leave a comment.
Не спешите выкидывать старые серверы, из них можно собрать быструю Ethernet-СХД за час