Комментарии к записи: Что HP думает о NetApp, и как все обстоит на самом деле. Часть 1

Автор: litweg

litweg — Sun, 29 Sep 2013 20:12:03 +0000

Artur,
Тенденция прописывать в любое ТЗ поддержку active-active объяснить легко, если знать как они работают. Дело в том, что у них есть внутренний документик (FRP) в котором прописаны все фичи массива, начиная со всякой базовой фигни вроде поддержки ОС и заканчивая тем как у них реализованы более сложные функции. Для 7400 у них там аж 58 пунктов. Поэтому чем больше “заточек” пресейл нусуёт в ТЗ - тем лучше. Тем больше вероятность что все не порежут.

К дискусии могу добавить только одно - 7400 может потерять два или даже три контроллера (главное не одновременно) и кеш не потеряется, т.к. при потере контроллера он перезеркалируется на другой, “живой” контроллер.

Автор: zerg

zerg — Thu, 29 Aug 2013 10:59:02 +0000

??нтересная дискуссия вышла. А по-моему active/active в том виде в котором есть(LUSTRE/GFS итд) - отлично работает. Кому надо тот использует эти кластерные ФС.

Автор: Artur

Artur — Fri, 23 Aug 2013 06:05:53 +0000

У продавцов HP 3Par наметилась печальная тенденция. Они теперь в ТЗ пытаются прописsdать поддержку active/active контроллеров и неприемлимость ALUA.

Автор: nikolay_a

nikolay_a — Wed, 21 Aug 2013 14:28:59 +0000

Пока читал про 3PAR - возник вопрос - чем же их конфигурация из, например, 4-х контроллеров отличается от нетапа с 4-мя контроллерами. Те же HA-пары, та же в общем-то логика обработки “чужих” данных. Лишний раз убедился, что хорошие инженеры работают и в 3PAR и в NetApp.
Жаль только что HP купила 3PAR. Печальный пример полного остутствия развития архитектуры EVA доставшегося от DEC (Compaq) наводит на грустные мысли о будущем 3PAR :(. Будут выжимать из чужих инженерных решений бабло по максимуму, а потом выкинут на помойку..

Автор: Stormkiller

Stormkiller — Wed, 21 Aug 2013 13:37:22 +0000

nikolay_a:

Да , тут полностью поддержу.

Какая-то надуманная функция, никому не нужная. Если доступ к данным не параллелится , то ну ее и это не эктив эктив.

?? кстати “т. к. реально данные пишутся из КЭША, общего для ПАРЫ контроллеров (если я правильно разобрался с терминологией 3PAR” - тут тоже непонятно как идет арбитраж и пишутся ли данные в одну группу блоков данных ? Непонятно.

Автор: nikolay_a

nikolay_a — Wed, 21 Aug 2013 13:37:16 +0000

Romx:
НетАпп хотя бы честен в своих обещаниях. А для России это большая редкость. Как сказал один хороший человек из московского представительства - “мы ж не бусы с зеркальцами папуасам впариваем”:)
А вот поведение пресейлов некоторых других вендоров (не буду показывать пальцем) именно так и выглядит.

Автор: romx

romx — Wed, 21 Aug 2013 13:26:49 +0000

nikolay_a:
Позиция NetApp в данном вопросе прагматична. Если это “фича ради фичи”, или если это редко востребованная в реальных задачах возможность (и которую можно сравнительно просто решить каким-то иным, обходным путем), но которая приводит при ее реализации к существенному усложнению (читай - “удорожанию и непредсказуемости производительности”), то ну ее нафиг такую фичу. :)

Автор: nikolay_a

nikolay_a — Wed, 21 Aug 2013 13:20:04 +0000

To Artur
Да ничем :) Нет полноценного актив-актив решения в случае железных стораджей. Ни у одного из вендоров. Полноценный актив-актив доступ на запись и чтение данных к одним и тем же блокам может быть только в случае cluster FS (GPFS, GFS, Lustre и т. п.). Все остальное - лишь попытки приблизится к этому. Воможно что 3PAR достаточно близко подошли к такой схеме, если верить утверждению Amazi о том, что данные в один лун могут писаться с 4-х контроллеров одновременно. Но я в этом почему-то не верю, т. к. реально данные пишутся из КЭША, общего для ПАРЫ контроллеров (если я правильно разобрался с терминологией 3PAR). Т. е. у 3PAR в случае конфигурации с 4-мя и 8-и контроллерами мы имеем слабосвязанный кластер между ПАРАМ?? контроллеров. Соот-но ни о каком реальном разделяемом (арбитрируемом) доступе к луну с 4-х контроллеров одновременно речи не идет.
To Romx
@Это зависит от того, что именно вы понимаете под работой “active/active”@ - я лично понимаю под этим полноценный арбитрируемый доступ к к одному НАБОРУ блоков (не не к одному блоку :))) с разных контроллеров (сколько бы их ни было в массиве) в один момент времени. Проще говоря, если я запросил выборку на 1 Тб данных из а этот запрос в идеале был бы распараллелен между любым кол-вом контроллеров и выдан мне за время N/кол-во контроллеров, а не за N.
Все остальное это не более чем относительно успешные (или не успешные) попытки выжать лишние мс и имеющегося решения. ?? зачастую эти попытки приводят к совершенно противоположным результатам у реальных заказчиков.

Автор: Artur

Artur — Wed, 21 Aug 2013 11:50:41 +0000

Очень интересно читать такие дискуссии.
Но прочитав все вышеозвученное, я так и не понял в чем же преимущество подхода 3Par перед NetaApp и всеми другими не тру active/active массивами.

Автор: romx

romx — Tue, 20 Aug 2013 06:53:54 +0000

Odna Ptichka:

Так у меня тут фактически и нет вопросов, а, по существу, одни “ответы”, указывающие на плохой уровень знаний технологий и продуктов конкурента, с которым пресейлы этого вендора пытаются написать competitive-документ. Собственно задачей поста было привлечь внимание к этому факту, так как плохо разбирающиеся в теме люди, например потенциальные клиенты, которые в равной мере плохо знают что NetApp, что HP, могут все перечисленное принимать за правду, поэтому являются благодатной почвой для “заливания мозгов”.
??ли вы про мои вопросы об апгрейде и рестрайпе данных выше в комментариях? Ну, в общем, я получил ответ, поставил соответствующую пометку в личном списке.