Что HP думает о NetApp, и как все обстоит на самом деле. Часть 1
Пару недель назад мне в руки попал текст, подготовленный специалистами компании HP, продававшей систему HP 3Par, или как она сейчас называется, StoreServ 7000 против предложенного уже этому клиенту midrange NetApp. Документ относится к популярному в российском IT жанру “говнилок”, или, выражаясь интеллигентно – FUD (Fear, Uncertainity and Doubt). Как правило такие документы мне приходится встречать со стороны пресейл-инженеров компании EMC, но впервые мне попадается в полном виде текст от HP, этим он особенно интересен. HP, как компания, находится в довольно-таки привелигированном положении на рынке, в особенности на российском. Это большая, крайне авторитетная компания “полного стека”, которая может предложить своим клиентам полный спектр оборудования, от серверов и систем хранения, активное сетевое оборудование, до шкафов и UPS.
Тем печальнее, что за последних 10 лет отдел систем хранения в компании был в явном “загоне”. Обладая в начале 90-х передовой и в чем-то даже революционной системой хранения EVA (Enterprise Virtual Array), компания “почивала на лаврах” и допочивалась до того, что EVA на рынке катастрофически морально устарела. Весь мир стораджей ушел вперед, за новыми модными фичами, а HP как продавала в мидрендже – EVA, в high-end ребрендированный Hitachi USP, а в энтрилевеле – DotHill, так и продавала. ?? допродавалась до катастрофических результатов. Сегодня из компаний в External Storage Top5 только HP теряет объемы продаж, все остальные растут.
Вовремя (надеюсь) спохватившись, HP активно занялась обновлением своего стораджевого портфолио, традиционно “взяв под крыло” несколько небольших компаний с их интересными продуктами, таких как LeftHand и 3Par, и которым явно не хватало веса “продавиться” на рынок. Однако атмосфера долгого застоя в отделе стораджей все еще явно дает о себе знать. Для меня очень показательным стал разбор приведенного ниже документа, как на ладони демонстрирующего текущие проблемы HP StorageWorks как отдела компании: устарелость использованных при подготовке инженеров материалов, крайняя узость эрудиции в области современных технологий, а как результат – низкая компетенция, по крайней мере в анализе продуктов конкурентов (я хочу думать о людях лучше, и верю, что в своих новых системах инженеры HP разбираются куда лучше, чем демонстрируют на системах конкурентов).
Документ сравнительно свежий, написан 11.09.2012 года в программе, зарегистрированной на имя Владимир Коробейников, это человек, работающий на позиции storage presale в HP с 2006 года (эту информацию можно почерпнуть в свойствах файла), я не утверждаю, что текст писал именно он, но эти данные в файле имеются.
??так, давайте посмотрим, что по поводу NetApp FAS думает HP, и как все обстоит на самом деле, где пресейлы HP ошибаются, от незнания или преднамеренно, где и почему вводят этим документом его читающего потенциального покупателя в заблуждение, а также как намерены бороться за продажи своих систем против NetApp.
Я далее приведу практически весь этот обширный документ, разрывая оригинальный текст своими комментариями, но постараюсь ничего не пропускать, дабы не быть обвиненным в тенденциозном выдирании из контекста, поэтому получтся несколько длинно, и я был вынужден поделить его на несколько частей, но потерпите уж. Это будет интересно, на мой взгляд.
Документ, попавший ко мне в руки, начинается без всякой вводной части, и первым же пунктом ниже заголовка идет это:
1. Массивы НР Р10000 имеют лидирующие показатели производительности: согласно независимым тестам SPC-1 (имитирующим нагрузку бизнес приложений) максимальная производительность массива Р10000 (без использования SSD-дисков) составляет 450’212 IOPs (при времени отклика 13.7ms и утилизации емкости 80.5%).
При этом максимальная производительность по тестам SPC-1 для массивов NetApp составляет всего 250’040 IOPs (при времени отклика 3.35ms и утилизации емкости 44%) – более чем 1.8 в раз меньше по сравнению с НР. Тестирование проводилось на шести-контроллерном кластере FAS6240 (в котором было установлено 3ТБ Flash Cache). По поводу данных тестов кластера FAS6240 можно отметить следующее:
Вы поняли, должно быть, зачем я прошлый пост посвятил бессмысленности использования результатов бенчмарков для рекламирования достижений вендора. Разумный человек спросит, какое отношение имеют достижения болида Формулы-1 вашей “конюшни” на последнем Grand Prix к тому, что вы мне сейчас продаете в салоне? Вы же мне продаете не этот болид, а, допустим, семейный минивэн для поездок на дачу и в супермаркет по субботам, или городской седан для поездки на работу? Да даже если и спорткар, девчонок катать, все равно, где F1, и где мы сейчас? Какое отношение имеют рекорды F1 на треке к этому вот конкретно автомобилю? Но в IT эти незамысловатые трюки все еще пользуются спросом.
Трогательно также смотрится эпитет “всего” по отношению к четверти миллиона IOPS при менее 5 ms latency, но относящиеся к результату конкурента. ;)
Но, впрочим, оставим это глумление тут. Еще раз повторюсь, бенчмарки это рекорды, установленные специальными системами для установления этих рекордов, и, как правило, больше ни для чего. Вы же покупаете не эти рекордные машины, а совсем другие. Но, раз уж HP настаивает – давайте кратко сравним, сколько в его словах правды.
· NetApp утверждает, что их показатели производительности лучше, чем для массива НР, поскольку получены при существенно меньшем времени отклика. Однако если посмотреть данные тестов, то можно обнаружить, что при сопоставимом (чуть меньшем) времени отклика 3.29ms массив HP P10000 показывает также практически такую же, как и кластер FAS6240 производительность 225’080 IOPs. Но при этом очевидно, что низкое время отклика в кластере FAS6240 достигнуто исключительно благодаря применению Flash (SSD) кэш (в массивах P10000 при тестировании SSD не использовались).
Верно, все верно. Если мы приведем производительность в IOPS в этих двух тестах к одному уровню по latency, мы увидим следующее:
Для наглядности я сопоставил рядом два графика. Если кому-то захочется увидеть фактические цифры, сколько получилось у HP на уровне NetApp, их можно посмотреть в данных Full Disclosure report обоих систем.
Здесь мы видим, что при равном уровне достигнутого показателя по latency (при чуть выше чем 50% загрузки для HP, после чего задержки у них резко растут), сторадж HP достиг сравнимого (чуть меньше, но не суть) результата. ??ли, если временно не принимать в расчет latency, то в 1,8 раза выше по чисто IOPS-ам.
Хочу отдельно немного остановиться на том, почему вокруг низкого latency ломается столько копий в профессиональной среде, и чем он так важен. Например, Microsoft в best practices для MS SQL Server указывает:
On well-tuned I/O subsystems, ideal values would be:
1 ms for Log (ideally 1 ms on arrays with cache)
4 ms for Data on OLTP systems (ideally 10 ms or less)
Я не буду еще подробнее останавливаться на том, как связаны IOPS и Latency, и насколько низкая величина latency нужна для реальных задач, тех же баз данных, интересующихся отправлю к моим записям в этом блоге: Что такое IOPS? и Еще о тестировании Cluster-mode в SPC-1.
· NetApp не смог показать более высокую производительность (более 250k IOPs), хотя тестируемая конфигурация позволяла наращивать и FlashCache (в 2 раза), и кол-во жестких дисков (в 10 раз). Это означает, что контроллеры массива FAS6240 имеют ограниченную производительность и не позволяют наращивать производительность выше 250k IOPs (для 6 контроллеров).
Ну, оставим в стороне довольно легкомысленное и необъясненное никак утверждение HP про то, что “не смог”, “хотя тестируемая конфигурация позволяла наращивать”, как и дальнейший высосанный из пальца вывод. Не станем гадать на кофейной гуще, NetApp показал столько, сколько хотел, и достигнутым результатом доволен, раз уж этот результат был опубликован. (в комментариях к посту на theregister, dikrek, автор recoverymonkey.com указывает, что методика SPC-1 не запрещает ограничивать загрузку loadgenerators, например для достижения намеченного соотношения latency/IOPS, и утверждает, что целью было именно показать достигнутый latency на 250K IOPS, а вовсе не достичь потолка по IOPS невзирая на ухудшение latency). Возможно такая конфигурация и такой результат был показан и потому, что NetApp последовательно стремится тестировать не “зведолеты”-labqueen, не top-of-the-pops, а более или менее реальные, ориентированные на задачи, и фактически продаваемые их клиентам конфигурации. Давайте просто сравним то, что тестировал HP, и что тестировал NetApp.
Выполнявший тест SPC-1 сторадж HP имел: 8 контроллеров против 6 у NetApp, в 4,4 раза больше дисков (1920 SAS HDD) и в 3,5 раза выше цену (5.885.148 USD в ценах листпрайса, все данные – в Full Disclosure reports для обоих систем).
Какой поразительно несравнимый с величиной затрат результат! Заплатить в три с половиной раза больше денег и получить всего в 1,8 раза выше производительность, при существенно (примерно втрое) худших показателях latency! Эффективность? “Не, не слышал.” ;) Тут HP еще вспомнит про эффективность, погодите :)
Позволяла ли “тестируемая конфигурация наращивать”? Безусловно. Ведь там тестировался, в отличие от HP, даже не топовый сторадж, FAS6240 это даже не самый мощный контроллер в серии! Максмальная конфигурация для кластерной Data ONTAP – 8 контроллеров (в тесте было – 6), а Flash Cache даже на этом контроллере можно было бы увеличить в 6 раз, до 3TB, и в 12 раз с учетом возможности использовать Flash Pool. Да и дисков можно было поставить в три раза больше. Но – зачем?
“Обгони-ка сперва меньшого брата” (с) А.С.Пушкин ;) Так что я, в общем, понимаю лютый батхёрт HP на эту тему. ;)
· Важно также обратить внимание на утилизацию емкости в тестируемых конфигурациях: в кластере FAS6240 в тестах было использовано только 44% от установленной физической емкости, в массиве Р10000 – более 80%. То что NetApp тестировал свои массивы при менее чем на половину использовании установленных дисковых ресурсов еще раз подтверждает общеизвестный недостаток всех массивов NetApp – существенное падение производительности по мере роста степени утилизации дисковых ресурсов массива (см. ниже).
На мой взгляд, возможно инженеры HP со мною не согласятся, у них по очень многим вопросам альтернативное мнение, “подтвердить недостаток” может не отсутствие, а только лишь наличие данных, только явно и недвусмысленно проведенный компетентными людьми проверяемый и повторяемый независимо тест. Отсутствие же данных не может ничего “подтверждать”, просто, как выражаются, “по определению”, иначе получается пресловутое “- Видишь суслика? – Нет. – А он – есть!”. Видишь признаки существенного падения производительности? А оно есть! :)
Если же это не так, то было бы неплохо, если бы инженеры HP объяснили, почему, по их мнению, такое же “существенное падение” присуще, например, системам Hitachi или IBM, ведь они тоже используют в тестировании пространство на дисках существенно меньше имеющейся дисковой емкости? Вероятно они тоже имеют “общеизвестный недостаток”? :)
Все данные и описания тестов доступны на сайте SPC: http://www.storageperformance.org.
Действительно, давайте посмотрим на сайт SPC и приведенные там описания тестирования. Для NetApp там указана следующая схема распределения пространства дисков под данные бенчмарка:
Полная физическая емкость всех дисков системы (physical raw capacity) равна 193 386 GB.
Полный размер занятый данными бенчмарка, которые писались и читались: 71 522 GB
Было доступно, но не использовалось (все числа округлены тут до целых GB) : 70 482 GB
Разница между суммой второго и третьего и величиной raw capacity это RAID parity, spares и overhead-ы разных уровней.
Объем тестовых данных от полной физической емкости установленных дисков - 37%
Теперь то же самое посмотрим у HP:
Полная физическая емкость всех дисков системы (physical raw capacity): 572 736 GB
Полный размер занятый данными бенчмарка, которые писались и читались: 230 400 GB
Объем тестовых данных от полной физической емкости установленных дисков - 40%
Разница – 3%
Это, кстати, к вопросу про эффективность использования физической емкости установленных дисков. Откуда взялось 80% в подсчете HP? Ну, разумеется, они не учитывали занятое зеркальной копией RAID-10. При этом в самом тексте они утверждают, что считают “от установленной физической емкости”, что неправда, они считают не от “физической емкости”, а только от того, что осталось от нее после построения RAID, а это, для RAID-10 с его 50% RAID overhead, существенное лукавство.
Таким образом давайте подведем черту. Практически все компании, проводившие тесты своих стораджей по SPC-1, не заполняют тестовым массивом всю доступную usable-емкость дисков, фактически я нашел ровно один тест, где можно говорить о почти полной заполненности – это тест IBM DS3524, АКА NetApp E2600, там у единственного из просмотренных Unused storage ratio составило 6,68%. У почти всех же остальных оно составляет в районе 40%. Почему? Ответ простой. У ВСЕХ систем хранения падает производительность при высоком заполнении. У ВСЕХ. Составителям SPC-1 это известно, поэтому, чтобы получить результаты, приближенные к реальным (в реальной жизни очень мало кто эксплуатирует enterprise-сторадж заполненный “под горло”), они нормируют в условиях величину Unused storage ratio при запуске теста по уровню не хуже 45%. ??менно поэтому ВСЕ тестирующиеся стораджи оставляют примерно в районе 40% неиспользованного места. ?? в этом нет никакого злоумышления и “подтверждения падения производительности”. Если это можно сделать по условиям тестирования, и если это объективно улучшит показатели на тесте, и сделает их более реальными – это нужно сделать (не исключено, что у HP улучшилась бы их катастрофическая latency).
Пруфы: IBM Storvise V7000 – 38,98%. IBM XIV Gen3 – 42,30%. Hitachi VSP – 39,42%. Hitachi HUS150 – 40,03%. Oracle Sun ZFS 7420c – 40,70% Unused space ratio при прохождении теста SPC-1.
Кстати, хотите посмотреть на NetApp, заполненный на блочном тесте на 90%? Можно. :) Смотрите там же результаты SPC-1/E для FAS3270 с Flash Cache. Unused space ratio – 11,87%, это даже круче, чем у обсуждаемого HP 3Par (у него – 14,53%).
Позвольте на этом сеанс mythbusting-а считать оконченным :)
2. NetApp предлагает 2 варианта своих массивов: с одним и с двумя контроллерами. Модели с одним контроллером имеют несколько точек отказа (в одном контроллере ничего не дублируется, кэш-память не зеркалируется) и соответственно не могут рассматриваться как полноценное отказоустойчивое решение. Любые массивы НР среднего и старшего уровней имеют, как минимум, 2 контроллера и не имеют единой точки отказа.
Бохтымой, из каких пыльных закоулков вытащили это? У вас в HP там что, уже лет пять competitive материалы не обновлялись? 8-) Уже несколько лет как даже cluster-mode широко пошел в продакшн, а у HP все еще “NetApp предлагает 2 варианта: с одним и двумя контроллерами” :) НетАпп уже предлагает варианты с двумя и восемью. А также с четырьмя и шестью, десятью и двенадцатью и вполоть до двадцатьчетырьмя. :)
3. Для обеспечения отказоустойчивости необходимо использовать «кластеризацию» двух контроллеров. Кластер состоит из двух (и только из двух) контроллеров, при этом кластер не имеет общих ресурсов: каждый контроллер владеет своими дисками (и своими томами) и имеет свои метаданные – в итоге: отсутствует какая-либо балансировка нагрузки между контроллерами кластера. Кроме того, доступ к определенному тому или физическому диску возможен только через порты одного контроллера (т.е. два контроллера не могут работать в режиме active/active), что снижает производительность. При отказе одного контроллера для переподключения томов к другому контроллеру требуется существенно более длительный интервал времени (по сравнению с массивами, в которых доступ к любому тому возможен через порты всех контроллеров), что может привести к сбою приложений. В массивах НР Р10000 (V400 и V800), P9500, F200 и F400, Р6000, Р4000 все контроллеры работают в режиме active/active, разделяют доступ ко всем дискам и томам массива. В массивах НР Р10000 (V400 и V800), F200 и F400, Р4000 поддерживается автоматическая балансировка нагрузки между контроллерами массива. Что обеспечивает и более высокую надежность, и более высокую производительность массивов НР.
?? снова не так. Кластер имеет от двух до 8 для SAN и до 24 контроллеров для NAS-систем, и использует single namespace, что позволяет видеть пользовательскому приложению кластер как единую сущность. NetApp, ну пригласите вы уже парней из HP на семинар по своим стораджам, что вы смотрите на то как они публично позорятся?
4. Кэш на запись в системах NetApp удивительно маленький (для кэширования операций записи используется только NVRAM, а собственно кэш используется для кэширования операций чтения и для размещений там ОС ONTAP), на 1 контроллер: 256КБ (FAS2040) и 512КБ (FAS3140), 1024КБ (FAS3240). Однако реально на одном контроллере доступно будет для кэширования операций записи только половина NVRAM – из-за применяемой NetApp технологии кэширования. А в кластере (система с двумя контроллерами) из-за зеркалирования NVRAM между контроллерами доступный размер NVRAM сокращается еще в 2 раза. ??того, доступный NVRAM (кэширование операций записи) составит: 64КБ (FAS2040), 128КБ (FAS3140), 256КБ (FAS3240). В EVA4400, Р6300 и в Р2000 кэш для записи составляет 1МБ, в Р6500 – 2МБ! ?? это при том, что EVA4400 и Р2000 поддерживают максимум 96 дисков (Р6300 – 240 дисков, Р6500 – 450 дисков), а FAS3240 – 600 дисков!!!
Заодно и объясните им в чем разница между NVRAM и кэшем, да и как работает запись в WAFL. А то недостаток информации заменяется богатой фантазией, и сами видите что в итоге получается.
Три восклицательных знака это видимо свидетельство того, что человек не сдержался. :) Хороший пример FUD-а. Сперва показываем, как наш сторадж почти побивает NetApp в хайэнд-тестах, а спустя несколько абзацев говорим, о том, что “кэш у него маленький”. Внимательный человек обязательно спросит тут: “Ну как же так, вот у вас такой огромный кэш, а у них такой маленький, и WAFL с оверхедом, и блочный доступ эмулируется поверх NAS, почему же вы со своим огромным кэшем их и обогнали-то всего на ничего? Что-то тут не так, это же что получается? У них стораджи настолько эффективнее работают, чем у вас?” ;)
Ответ тут очевиден. Представление HP о том, как работает запись в NetApp не соответствует действительности, соответственно и весь вымысел, вокруг этого наверченный – пустое. Для того, чтобы понять, в чем тут дело, и как с таким маленьким кэшем на запись NetApp удается достигать таких высоких показателей IOPS на шпиндель, нужно начать с того, что разобраться и понять, как работает WAFL и RAID-DP на запись. ??бо, как известно многим, дело не в размере, а в умении им пользоваться ;)
5. Общеизвестны проблемы NetApp, связанные с низкой скоростью чтения, высокой степенью фрагментации файловой системы и с существенным падением производительности с течением времени (по мере увеличения процента утилизации дисковых ресурсов, т.е., по мере записи данных – такого оригинального эффекта нет ни у кого из конкурентов NetApp). Все эти проблемы связаны с оригинальной файловой системой WAFL (Write Anywhere File Layout), «оптимизированной» для выполнения операций записи (запись очередного блока данных выполняется на ближайший свободный к головке диска блок), что ведет к очень сильной фрагментации и снижению скорости чтения. Фрагментация приводит к тому, что по мере заполнения дискового пространства существенно падает скорость, как чтения, так и записи.
Чтобы убедиться в том, что производительность массива NetApp падает по мере записи данных в массив – достаточно провести простой тест с использованием IOmeter: писать в массив 1МБ блоки и каждый час измерять скорость чтения. Через 12 часов производительность массива снизится примерно в 2 раза.
Очередные “общеизвестные сведения” не подтверждаются практикой. Также опровергается это результатами sustainability test в тестировании SPC-1 (страница 28 в Full Disclosure report). После 60 минут ramp-up (“прогрева” кэша и стабилизации результатов), тестирование на протяжении 10 часов (600 минут) не показало сколь-нибудь значительного изменения результатов, показанных в тесте как для IOPS, так и для latency. Пруфы:
Кому верить, аудированному тесту, результаты которого в подробностях доступны на официальном вебсайте Storage Performance Counsil, или “тестированию” неизвестной конфигурации, незнамо как настроенной, анонимными специалистов в HP, в адрес которых ниже будет еще много слов об уровне их “знаний” о NetApp – решать вам.
NetApp предлагает самые разные решения данной проблемы: добавить диски, перейти на более старшие модели, использовать дорогую FlashCache или периодически выполнять дефрагментацию (reallocation scan) с помощью специальной утилиты, разработанной NetApp. К сожалению, эта утилита дефрагментации дает очень слабый эффект и, что самое неприятное, использовать эту утилиту придется регулярно и достаточно часто (NetApp рекомендует использовать утилиту дефрагментации ежедневно).
Хотелось бы увидеть ссылку на то, что NetApp предлагает. Так как я этой ссылки не вижу, предлагаю считать это собственным творчеством на эту тему слабоинформированных, как я показал выше, специалистов HP. Что такое у HP “утилита дефрагментации” непонятно, но по контексту догадываюсь, что имеется ввиду имеющаяся в Data ONTAP опция реаллокирования блоков по дисковому тому и aggregate. Строго говоря reallocate не является “дефрагментацией”, как это слово понимает массовый пользователь, привыкший к “бегающим квадратикам” со времен DOS, так что тут вновь неявное введение в заблуждение читателя.
О “фрагментации” и ее влиянии на производительность я писал в этом блоге многократно, приводил как теоретические мнения, так и практические выводы, как для рандомного, так и для секвентального доступа, наконец, собственными руками провел тест, показавший на недостижимо высоком в реальной жизни уровне фрагментации тестового файла (около 250 ТЫСЯЧ фрагментов на 16 TB, чтобы уж мало не показалось;), специально в течении получаса замешивавшегося специальной утилитой, совершенно малозначимый эффект (17%).
??нтересно отметить, что фрагментация приводит также к существенному падению производительности и FlashCache.
??нтересно, но нет подтверждений. Вновь “собственные источники компетентных инженеров HP”.
?? наконец, утилита дефрагментации не совместима с технологией дедупликации (см. ниже).
Правильный выбор слова – половина успеха в FUD. :) Под словами “несовместима” у составителя документа понимается то, что reallocate на дедуплицированных томах, просто по их природной фрагментированности “бай дизайн”, не имеет смысла и не используется. Разные логически последовательные блоки одного дедуплицированного файла или LUN просто конструктивно могут не лежать физически последовательно, принадлежа одновременно разным объектам на томе. То что если ZIP-ом пожать RAR и не получить выигрыш в месте на диске ведь не называется “ZIP не совместим с RAR”? А у HP вот – называется :)
Также нужно обратить внимание на то, что применение FlashCache (SSD диски) в первую очередь нацелено на борьбу с фрагментацией и низкой скоростью чтения.
Ответ отрицательный. :) ?? Flash Cache, и SSD в структуре Flash Pool нацелены НЕ на гипотетическую “борьбу с фрагментацией” и не менее гипотетической “низкой скоростью чтения”, которая не подтверждается результатами объективных публичных тестов, а для уменьшения latency, снижения числа необходимых для задачи физических “дисковых шпинделей”, и достижения заданной производительности на random, и, в конечном итоге, для улучшения показателей $/IOPS для системы.
На результаты можно посмотреть по уже приведенным ссылкам на сайтах с опубликованными результатами бенчмарков SPEC SFS2008 и SPC-1/E. Остальное – фантазии HP. Доверять ли их уровню знаний в вопросе – судить вам.
6. Массивы NetApp не поддерживают современную технологию автоматического перераспределения блоков данных между различными уровнями хранения (sub-LUN Tiering).
Это снова не так. NetApp использует куда более эффективную на практике технологию VST – Virtual Storage Tiering, которая делает то же самое, что и обычный Tiering: “автоматически распределяет блоки данных между различными уровнями хранения” просто в другой форме. Отдельно следует отметить, что VST как таковой у NetApp – бесплатен (денег стоят лишь платы Flash Cache или SSD в Flash Pool), а численно оценить эффективность работы Flash Cache на ваших задачах можно даже до покупки самого модуля кэширования, с помощью имеющегося в Data ONTAP средства Predictive Cache Statistics.
Наконец, следует отметить, что NetApp – единственный из производителей систем хранения с возможностью tiering-а, который опубликовал результаты измерения производительности со включенным tiering-ом. Что неудивительно, так как полученные результаты – отличные как для файлового (раз, два, три), так и для блочного (четыре) доступа. У меня есть нехорошее подозрение, относительно того, отчего остальные производители со своим tiering-ом как в рот воды набрали. ;)
Единственное, что могут обеспечить массивы NetApp – это использование FlashCache (SSD диски) в качестве промежуточного дополнительного буфера.
Подскажу: в технике промежуточный дополнительный буфер называется “кэш” (cache). ;) Это самый эффективный способ повысить быстродействие доступа к данным, будь это данные на системе хранения или же код программы в памяти, читаемого процессором. Метод кэширования данных для ускорения доступа к ним широко применяется в компьютерной индустрии с самого ее зарождения.
Впрочем, даже в таком простом утверждении HP сумело слажать. Дело в том, что у NetApp SSD диски могут использоваться как кэш, верно, но могут также и как хранилище, традиционным образом. Оба варианта доступны и поддерживаются, когда пользователю системы нужно именно SSD-как-диск, однако использование их как кэша обычно эффективнее.
7. Что касается поддержки Flash Cache – недавно появилась очень интересная информация: младшие модели массивов (FAS 3210, 3140, 2240) перестали поддерживать Flash Cache с выходом новой версии микрокода (или операционки, как угодно) ONTAP 8.1 (c предыдущими версиями все работает). NetApp объявил, что и в последующих версиях микрокода Flash Cache не будет поддерживаться на этих моделях, хотя его можно туда установить. Т.е., счастливые обладатели FAS 3210, 3140, 2240 должны либо навсегда остаться со старой версией ONTAP, либо отказаться от Flash Cache. ?? ничего, кстати, не гарантирует, что такая же история не постигнет и более счастливых обладателей других моделей FAS.
Она появилась не “недавно”, а более года назад, и примерно тогда же была урегулирована, выпуском специального “апдейта” Data ONTAP 8.1.1. FAS3140 не продается (End-of-Availability) уже около полутора лет и актуальной системой может считаться только у HP ;). Контроллер FAS3210 официально уходит из продажи в ноябре этого года (но, конечно, по-прежнему будет поддерживаться) и его продажи, как я знаю, практически отсутствуют, по ряду внутренних причин (с выходом 3220 он перестал быть интересен). На FAS2240 вообще никогда и не было Flash Cache (его там банально некуда поставить, эта модель не имеет слота расширения PCIe), там используется Flash Pool, и он, разумеется, доступен. Он и был, и есть. Связано обсуждаемое ограничение для некоторых младших моделей с тем, что эффективное использование Flash Cache требует значительных объемов памяти, которых на самых младших моделях недостаточно для работы с Flash Cache (они используют аналогичное решение с использованием SSD – Flash Pool). Вся новая линейка, актуальные FAS3200, разработана уже с учетом этих повысившихся требований, и данная проблема им не присуща, так что счастливые обладатели NetApp останутся счастливыми, что, впрочем, не скажешь о не настолько счастливых покупателях EVA. ;)
8. Низкая производительность массивов NetApp на операциях чтения приводит, в частности, к низкой скорости резервного копирования. Чтобы как-то решить проблему низкой скорости резервного копирования NetApp предлагает заказчикам использовать дополнительную весьма дорогую лицензию NDMP.
Чтобы как-то решить проблему недостатка знаний, их можно заменить фантазией и выдумками. :) Я не знаю где в HP взяли у NetApp мало того, что “дополнительную”, но еще и “весьма дорогую” лицензию NDMP, даже неловко возражать, что NDMP это протокол (Network Data Management Protocol), который присутствует во всех стораджах NetApp бесплатно. :)
9. Еще одна общеизвестная проблема производительности, также связанная с оригинальной файловой системой WAFL – при удалении больших файлов производительность дискового массива весьма заметно падает (на 20-30%).
Долго думал, как комментировать и реагировать ли вообще на вот такие вот “сведения”, приведенные без малейшей попытки их подтверждения. Я вот тут стараюсь, как вы заметили, почти любое свое опровержение подтверждаю пруфами и ссылками на материалы и официальные PDF-ы на сайте… Опровергать слухи дело вообще малопродуктивное, придумывать их “там” получается быстрее, чем я их тут буду опровергать. Мой читатель, что посоветуете? Вы-то должны знать, проблема-то, смотрите, “общеизвестная” ;). Могу лишь сказать, что я, понимая принципы работы WAFL, не вижу ни единой физической причины для массива NetApp так себя вести. Откровенно говоря и на практике с таким никогда не сталкивался. Видимо, это вымысел HP в чистом виде.
Но вообще, если серьезно, это FUD в классической его форме. Читает такой текст клиент, и думает: “Мамадарахая! Ты глянь! Проблема-то общеизвестная, написано! Одни мы, как лохи нестриженные сидим в тайге, ничо не знаем! ?? нам такое продать хотели! Спасибо добрым людям, открыли глаза.” Готово дела, Fear, Uncertainity and Doubt посеяны. :)
10. Wide Striping. Максимальный размер дисковой группы (RAID-группы) в массивах FAS – 30 дисков, при этом NetApp рекомендует использовать дисковые группы меньшего размера (16-18 дисков). ?? это существенно ограничивает максимальную производительность, которую можно получить на уровне одного логического тома (LUN) – в массивах NetApp отсутствует Wide Striping.
На самом деле не 30, а 28 для дисков SAS или FC, и 20 для SATA (легко доступный пруф на офсайте), ну, ошиблись, не поглядели на официальный сайт при написании текста, бывает. :)
Но тут все у HP куда хуже в другом. Господа пресейлы кажется вообще не имеют представления о том, как организовано хранение данных на дисках NetApp, и это, на мой взгляд, катастрофический фэйл. Ну как можно вообще начинать competitive, не зная того, что размер RAID-группы ВООБЩЕ никак не связан с тем, на скольки дисках лежат данные одного тома или LUN!? Парни, вы там вообще чего? FlexVol и Aggregates появились в 2004 году, вместе с Data ONTAP 7.0, а до вас это все еще не довели, что максимальный размер тома, размазанного поверх десятков RAID-групп, составляющих в Data ONTAP его aggregate, может достигать 100TB “одним писом”? ?? таки да, вы будете смеяться, но aggregate это вот и есть вайд страйпинг, вайдее не бывает!
В массивах НР Р10000 (V400 и V800), F200 и F400, Р6000, Р4000 размер дисковой группы не имеет ограничений по максимальному кол-ву дисков и это позволяет автоматически равномерно распределять нагрузку ввода/вывода между большим количеством дисков (Wide Striping) и за счет этого добиваться очень высокой производительности. Применение технологии Wide Striping идеально подходит для смешанной нагрузки (транзакционной и потоковой) и не требует дополнительной сложной настройки производительности.
Не специалист в HP, поэтому не могу прокомментировать. Догадываюсь, что под “дисковой группой” имеется ввиду НЕ RAID-группа (с трудом могу себе представить “неограниченную группу” в RAID-5), но что?
??рония ситуации состоит еще и в том, что, раз уж мы начали наше обсуждение с тестов SPC-1, в этом тестировании wide striping у HP как раз и не использовался, равно как не использовались и возможности load balancing между контроллерами, и даже thin provisioning, сама главная фича новых стораджей HP. Почему? Что-то с ними не так, раз вы не решились их показать на бенчмарке?
11. NetApp рекомендует использовать RAID-DP – что опять же приводит к снижению производительности записи (из-за двойной записи контрольных сумм). Кроме того, расчет контрольных сумм для RAID NetApp производит на программном уровне (программные модули в среде ONTAP), в НР Р10000 (V400 и V800), F200 и F400, Р6000 для этого используются специализированные микросхемы (ASIC) – что также обеспечивает дополнительный выигрыш в производительности для массивов НР.
О том, как на самом деле работает RAID-DP, почему он НЕ приводит к “снижению производительности записи”, о том, как происходит “расчет контрольных сумм” и почему дополнительный выигрыш не так велик, как представляется HP, хочу порекомендовать пресейлам HP хорошую статью уровня “для чайников”: RAID-4 / RAID-DP — превращаем недостатки в достоинства, опубликованный пару лет назад на Хабре в блоге компании NetApp.
12. Массивы NetApp не поддерживают широко применяемый RAID уровень 5.
Да, потому что мастдай. :) Надежность его на современных больших дисках не позволяет всерьез расчитывать на его использование сегодня для безотказного хранения данных.
Позиция NetApp в данном случае крайне проста. Несколько видов RAID существуют и используются в других системах хранения оттого, что они имеют свои достоинства, но одновременно с ними и недостатки. RAID-10 быстр и надежен, но заставляет отдать половину дисков под RAID protection, что делает его использование в сторадже крайне неэффективным с точки зрения сотношения raw/usable. RAID-5 быстр на чтение, и экономен, забирает всего один диск на группу, но чем дальше, тем ненадежнее, и страдает от write penalty, ухудшая параметры быстродействия системы при большом количестве раномной записи на том. RAID-6 очень надежен, но еще менее быстр, чем RAID-5. ??менно тот факт, что среди трех типов этих RAID нет абсолютного победителя без недостатков и заставляет мириться с неудобством использования разных типов RAID в IT-системе. Для одних данных нужнее скорость работы с ними, для других лучше выбрать надежность, а скоростью, уж так и быть, пожертвуем.
Однако используемый у NetApp тип RAID с двойной четностью – RAID-DP имеет преимущества всех трех перечисленных, но не имеет их недостатков. Он быстр как RAID-10 (см. результаты тестов), и одновременно надежен как RAID-6, расходуя на защиту данных всего два диска на длинную группу. Поэтому в NetApp фактически нет необходимости выбирать для использования объективно худшие варианты, если есть объективно лучший. Удивлены? Это оттого, что вы не читаете этот блог. :) Судите сами, ведь ВСЕ тесты, и SPC-1, с которого мы начали, проводятся NetApp с использованием на его дисках RAID-DP. ?? при этом он там достаточно быстр, чтобы побивать куда более дорогие системы с большим числом дисков в RAID-10. Очевидно, что в реальности RAID-DP не “приводит к снижению производительности записи (из-за двойной записи контрольных сумм).”, как ошибочно утверждает безмянный пресейл HP, а, по-видимому, даже наоборот.
Так что вновь я должен с огорчением признать, что пресейлы HP в данном случае, к сожалению, не имеют понятия о том, о чем они пишут текст, не разобравшись в элементарных принципах работы системы конкурента.
13. У NetApp крайне не эффективное и не удобное ПО управления: при конфигурировании кластера каждый из двух контроллеров нужно настраивать отдельно! Если кластеров несколько – это существенно усложняет настройку. Кроме того, у NetApp нет единого интерфейса управления: FilerView позволяет управлять только одним массивом, если требуется управление несколькими массивами нужно использовать System Manager, который работает только под Windows.
“Удобство” и “эффективность” в применении к ПО управления. это весьма субъективные понятия, позвольте вновь оставлю такие технические и подтвержденные ссылками на первоисточники высказывания без комментариев. Остальное же в процитированном абзаце уже устаревшие сведения. Сейчас уже есть и управление кластером в целом, и единый интерфейс управления имеется, и FilerView уже год как исчез из Data ONTAP. A System Manager, его сменивший, уже скоро два года, начиная с версии 2.0, как есть не только под Windows, но также и под Linux/Unix (и даже под Mac работает), текущая версия его, кстати, уже 3.0. Парни, обновляйте свои “бородатые” competitive-даташиты. :)
На этом я прерву на сегодня разбор, вторая половина документа – в следующем посте. Продолжение следует.
Я так понимаю у HP это нормальная практика убеждения клиента - несение бреда с уверенным видом. Был на их презентации по серверам - чуть не выгнали. Устав слушать явную неправду стал на каждый выдуманный аргумент громко говорить “ложь” и “не правда”. Чуть из зала не выгнали. Зато народ поддержал.
Евгений:
Толерантнее надо быть. Видите как я , почти даже удержался в рамках вежливости в тексте, хотя порой было сложно, и неделю текст вылеживался и смягчался, скажу честно, самые острые пассажи я из него вымарал. ;)
Спасибо! Подняли настроение в понедельник!
Dmitry:
Всегда пожалуйста, я еще в четверг подниму, второй частью марлезонского балета, заходите :)
Спасибо!
Читал с наслаждением, вспоминал свою эпопею с выбором, и попытками - оболгать и навязать.
HP очень переживает, что у них йух короткий, потому и старается внушить кастомерам, что у остальных еще короче.
Поржал…
По пункту №10 могу прокоментировать насчет HP EVA. Дисковой группой называется набор дисков. Крайне нежелательно смешивать диски разного размера, смешать диски разных типов нам просто не дадут. Поверх такой дисковой группы (действительно, ограниченной только количеством дисков) мы нарезаем луны. Каждый лун размазан по всем дискам одновременно.
??з плюсов - используются все диски, в том числе и хотспары. Можем держать различные типы нагрузки, если диски вытянут.
??з минусов:
- убогая система кэша. Приличный объем кэша съедается под ОС. Про флешкеш Ева пока не слышала;
- если какому-то луну приспичит выжрать всю полезную нагрузку случайной записью - он это сделает (разве что упрется в размер очереди к луну - http://vmind.ru/2013/03/12/myth-unlimited-vm-vmfs-datastore-vaai/);
- хотите независимый набор дисков? Ок, но дисковая группа размером от 8 дисков. ?? там будут свои отдельные хотспары, равные емкости двух дисков (в режиме single, четырех в режиме double).
Для меня, как постоянного читателя нет ничего нового. Про все эти FUD уже много раз тут было написано.
Очень хоорошо что все собрано в большой статье со ссылками на документацию. С еще большим удовольствием буду отправлять сюда пытливые умы.
Жаль только, что выбор обычно делают не те кто читают такие статьи и переходят по ссылкам для проверки фактов.
Обычно выбор делает человек который пообщался с пресейлом. В итоге кто наглее - тот лезет вперед. Как говорится чем более невероятная ложь - тем легче в нее поверить.
В общем жду второй части.
PS
По поводу неограниченного размера дисковой группы у HP.
Достоверных ссылок привести не могу, но есть статья на хабре http://habrahabr.ru/company/hp/blog/148353/
из которой я почерпнул некторые знания как этои vRaid работают внутри EVA.
“Для наглядности диски из разных полок поставлены в ряд. Схематически показан пример записи двух блоков данных по 8 МБ в RAID5 (4 блока данных и 1 блок четности) на примере EVA 4400.”
и иллюстрация:
http://habrastorage.org/storage2/714/e26/bb6/714e26bb6061d3e372eac6ebfe4ab7f7.jpg
Внимание вопрос! Сколько дисков одновременно используется для записи блока размером 8 Мб?
Роман, очень занятное чтиво :) спасибо! Вопрос а с размерами NVRAM ошибки нету?
2Павел: для записи блока размером 8 мегабайт используется 5 дисков. 4 диска с данными, один - четность. ??спользуемый размер блока на диске - 2Мб.
Основываюсь по памяти после прохождения курса по Еве. Если вопрос принципиален, могу поискать первоисточники.
В моем комментарии имелось в виду, что один LUN будет размазан по всем дискам. К примеру, у вас EVA 8400 и 200 дисков. VRAID0 размером 400 мб уже будет размазан по всем дискам.
Dima:
Там ошибка прежде всего с непониманием принципов работы NVRAM.
А так - да, формально пространство NVRAM поделено на два попеременно заполняющихся операциями bucket-а, пока один flush-ится, второй наполняется. Я с ходу не готов ответить, действительно ли зеркалируется NVRAM между контроллерами, строго говоря для share-nothing систем это не нужно.
Кстати интересно, что из официальных техспеков сейчас вообще убрали емкость NVRAM, к сожалению, заблуждение, что “NVRAM это кэш” слишком распространено, решили с этим бороться.
Про неограниченный размер дисковой группы улыбнуло. Классический прием подмены понятий.
С одной стороны да - можно в DG запихать и все 240 шпинделей (или сколько их там по максимуму у P6500 например..). А вот дальше есть одно маленькое но.. Внутри этой группы микрокод контроллеров автоматом делит эти диски на РЕАЛЬНЫЕ дисковые группы, размер которых то ли 8, то ли 16 дисков. Размазывание блоков идет за счет vRaid’ов, которые потом выдаются как луны :)
Найди два отличия от физ. и логической структуры распределения данных у нетапп?
Про active|active тоже посмеялся немало :))). В ЛЮБОМ массиве, хоть в самом распресамом хай-енде до каждого диска есть 2 или 4 HW-Path, соот-но какие-то из них обслуживаются контроллером-”владельцем” (да-да, понятие контроллера-оунера есть у всех). ?? значит есть preffered hw-pathы, а есть резервные пути.. Соот-но если в P10000 запросы к диску будут постоянно идти НЕ через контроллер-оунер (а в случае кривого распределения трафика между host-портами это реально), то рост латенси будет ощутимый (добавится порядка 2-4 мс на каждую операцию)..
Так что active-active - это вообще говнилка в квадрате со стороны любого вендора..
А можно почитать Ваш такой документ, где Вы сравниваете к примеру с EMC.
Антон:
К сожалению, у меня нет актуального текста-мнения EMC на данную тему. Обычно, тем не менее, существует общий набор FUD-тем, большая часть упомянута в недавнем посте тут: http://blog.aboutnetapp.ru/archives/1266
Там же много ссылок на посты за предшествующие 6 лет существования этого блога.
Ничего нового в этом списке не появляется уже давно (что, в общем, плюс в отношении NetApp;)
Роман, так все же про емкость NVRAM, гугл выдает следующие ссылки:
источник: https://communities.netapp.com/thread/11998
“Total NVRAM Active/Active:
FAS3210: 1GB
FAS3240: 2GB
FAS3270: 4GB”
источник: http://www.bull.com/catalogue/FAS_3220.pdf
“FAS3220 - 3.2 GB NVRAM”
Т.е. эти данные не верные? Просто когда выбирали СХД, тоже делали (в первую очередь для себя) всякие таблички со сравнением “а как у других вендоров СХД” и использовали эти данные :)
Dima:
Суть в том, что у “других вендоров” нет NVRAM, что с чем вы сравнивать хотите?
Еще раз, NVRAM - это не кэш (по крайней мере “не просто кэш”, хотя и тот и другой измеряются в мегабайтах), принцип их работы существенно разный, чобы их можно было сравнивать напрямую, и тем более просто по емкости доступной памяти.
2nikolay_a: оптимальный размер RSS - 8 дисков. Поверх этих восьми дисков организуется Raid5. А затем на все такие Raid5 мы делаем нулевой страйп (R5-R5-R5-R5-***-R5). Размер дисковой группы ограничен только архитектурой массива.
Жесть… что могу сказать… EMC не особо далеко ушли от HP - тот же булшит 100-летней давности толкают. Я уже просто перестал пытаться с ними спорить и пытаться им доказать, то что булшит толкают. Самое печальное то, что у кучи кастомеров в ушах куча EMCшного булшита… но как же приятно видеть как меняется взгляд людей, когда показываешь им нетапчик в работе, да ещё и в работе с каким нибудь софтом типо SnapDrive, который клепает терабайтые клоны за пару секунд и сразу подключает их к хосту… ухх..
Роман, привет!
Текст я еще не дочитал, но не могу удержаться от замечания - завуалированно оскорблять конкретного человека, пусть и работающего на конкурента, и называть его некомпетентным и малоэрудированным - непрофессионально. Одно дело - вендорные войны (я вот тоже в конкуренте NetApp работаю, если чо :) ), а другое дело - переход на личности.
Minus:
Привет. Хорошо бы все же дочитать, потому что конкретного человека я ни в чем не оскорбляю, и не обвиняю. ?? никакого конкретного человека я не называю некомпетентным и малоэрудированным, я называю так сотрудников HP вообще, да, но не какого-то конкретного человека, отметь. Единственное имя, мной упомянутое - извлечено из свойств вордовского документа, и показывает, что это подлинный документ, вышедший из HP, а не “снято на конспиративных квартирах врагами”. Я специально, в явном виде указываю, что: “я не утверждаю, что текст писал именно он, но эти данные в файле имеются.”, я утверждаю тут только это. Не нужно приписывать лишнего и “вчитывать” несушествующее.
Речь в данном случае не идет о закрытой информации о “личной жизни”, чтобы зто как-то оправдало бы охрану privacy. Упомянутая фамилия написана в свойства файла, профиль на LinkedIn открытый.
Вообще, искренне говоря, я не сторонник анонимок, и не считаю, что не подписывать такие тексты - правильно (хотяконечно, в данном случае это коллективное авторство и явная компиляция из разных кусков разных авторов, разных времен, это даже по манере текста видно).
Я сам всегда ясно указываю свое авторство, когда что-то пишу, и если я в чем-то неправ - комменты всегда открыты для любых указаний на мою неправоту.
Мне кажется, что писать и публиковать тексты, за которые потом стыдно указывать свою фамилию, это что-то неправильное. Да, это грязная игра, но твой личный выбор, играть в нее, или сказать: “не, чуваки, давайте без меня, я пас”. Просто не надо в жизни делать вещи, за которые потом будет стыдно, прости за резкость.
Рома, весь вендорный FUD пишется обычно не одним человеком, как ты правильно заметил. Точнее, сначала его пишет один, потом дорабатывает другой, и т.д. Так что вполне вероятно, что ты спалил (пусть и без нарушения прайваси) имя человека, который просто создал документ. :)
?? все компетитивы - обезличены как по вышеуказанной причине, так и из-за того, чтобы не переходить с уровня вендорных войн на уровень личных претензий. Ты же понимаешь, что статья “Почему VNX говно” от Hitachi и статья “Почему VNX говно” от пресейла А.Н. будет воспринята по-разному. В первом случае - как позиция вендора, во втором - как личная позиция А.Н. Поэтому и стараются максимально обезличивать такие тексты. Есть и еще одна причина - так бывает, что люди меняют работу с одного вендора на другого :) ?? никто не может предсказать реакцию заказчика, когда он видит у себя на столе два документа, которые созданы с разницей в полгода, но подписанные одним человеком из двух разных вендоров. Диссонанс, так сказать :)
Ну в общем, фиг с ним.
У тебя получилась отличная статья на тему “Как не надо писать FUD” :) Вообще, конечно, странно уже как минимум то, что обычно сравнения либо сугубо предметные, вроде VSP vs VMAX40k, либо сугубо абстрактные - “наши ASIC-и круче этих ваших WAFL-ов”. А тут - все в кучу, и в результате фейл :)
То Андрей Вахитов: все верно. А чем эта структура отличается от НетАпп? Только тем, что в отличие от HP НетАпп честно говорит - вот есть группа, потом аггрегат, потом луны (или тома). Не нужно подменять понятия и говорить что у НетАпп маленький размер дисковой группы, а вот у HP он огого какой большой
Николай, к слову, насчет owner controller. Это есть не у всех, точнее, у midrange Hitachi (HUS) есть понятие symmetric active/active и технология dynamic virtual controller, т.е. это не стандартный ALUA, который есть у остальных.
DG (дисковая группа) у HP = Aggregate (аггрегат) у НетАпп. А в документе сравнивается размер DG c размером RG (которая аналогична RSS у HP) у НетАпп. Непорядок однако..
Кстати, что самое интересное насчет размера RG, так это то, что для наиболее эффективной работы wide striping на дисковом пуле нужно, чтобы RG были как можно меньшей величины, чтобы одновременно распределить данные по максимальному количеству групп.
To Minus: не знаю какой-такой “symmetric active/active” есть у Hitachi и что это за зверь и с чем его едять. Я не пробовал. Но совершенно точно могу сказать, что попытки динамически перекидывать LUN между контроллерами для выравнивания и (или) балансировки нагрузки ни к чему хорошему не приводили. Это я наблюдал еще на старой доброй EVA 8k. Цифры в студию, с детальным описанием конфигурации HUS, характером нагрузки и графиками.. “На слово” я давно уже никому из вендоров не верю. Опыт знаете ли был печальный..
“Кстати, что самое интересное насчет размера RG, так это то, что для наиболее эффективной работы wide striping на дисковом пуле нужно, чтобы RG были как можно меньшей величины, чтобы одновременно распределить данные по максимальному количеству групп.” С этим спорить не буду, как и с тем, что кол-во дисков в этой самой RG обычно кратно 8.
Николай, я эти данные сообщил не для вступления в полемику, а просто для уточнения, что не везде используется классический ALUA. Для того, чтобы пояснить, как это работает, общения в комментариях. Поподробнее можно посмотреть вот тут (http://www.hds.com/assets/pdf/hitachi-white-paper-dynamic-virtual-controller-technology.pdf), если Роман не против наличия каких-либо ссылок в комментариях.
Могу сказать, что на старой доброй EVA 8k все работало по-другому.
Для того, чтобы приводить какие-то цифры, необходимо определить как минимум задачи и методику тестирования, а так же то, что является или не является результатом. В общем, в комментариях не обсудишь. Если вкратце - то, в частности, с использованием технологии не наблюдается значительного снижения производительности при работе с логическим устройством(LU) на массиве через контроллер, на данный момент не являющимся “хозяином” LU.
Поправка - часть моей фразы следует читать вот так - “Для того, чтобы пояснить, как это работает, общения в комментариях явно не достаточно”.
?? еще одно - под снижением производительности следует понимать преимущественно увеличение времени отклика операции ввода-вывода.
To minus: почитаю документ, спасибо за ссылку. именно чтобы понять как это работает. если это действительно ноу-хау от Хитачи - интересно. Но что-то мне подсказывает что это новые маркетинговые названия для старых фич якобы балансинга и т. п.. все, пошел читать :)
To Minus: “?? еще одно - под снижением производительности следует понимать преимущественно увеличение времени отклика операции ввода-вывода” - именно это я наблюдал и на EVA, и на Hitachi nc 55 (надеюсь не ошибся с названием, тестировали такой массив году в 2006, HDC тогда его двигало как универсальный сторадж, видимо предвестник платформы HUS) при динамической миграции LUN. Тайм-аут по всем операциям на LUN до 30 мс и выше, в зависимости от нагрузки. Это даже не латенси, это тупо блокировка на уровне scsi команд похоже работала.
Речь, как я понимаю, про NSC55. Там был обычный ALUA, то, о чем я говорил, появилось в районе 2008-2009 года на тогдашних системах AMS.
Возможно, спорить не буду.
Но спорить с тем, что понятие контроллер-оунер есть и у массивов линейки HUS, вы, надеюсь не будете? :_
Ммм, есть, так будет написано в консоли массива :) Но это несколько отличается от привычной схемы. Весь инженерный смысл схемы symmetric active/active - это фронты, которые принадлежат обоим контроллерам, и зеркалирование кэша на чтение-запись.
Гм.. читаю pdf, все больше убеждаюсь пока что этот механизм может стать таким головняком на нагруженном массиве, что мама не горюй. Если оунер меняется динамически, хост-порты якобы “общие”, то как я застрахуюсь от ситуации, когда у меня пошла пиковая нагрузка на определенный лун(ы)? Если я правильно понял, в этом случае такой лун будет постоянно мигрировать между контроллерами и для серверов он будет тупо недоступен? А если кроме всего прочего у меня на серверах имеется два FC порта и каким-либо образом реализована поддержка мультипасинга - то все.. Приложение будет висеть в режиме ожидания диска, т. к. HW-path к нему будет изменяться в цикле..
Поправьте меня если я не прав.
Как-то сумбурно написал, мысль не сформировалась окончательно. Но надеюсь смысл вопроса понятен?
Николай, я полагаю, Роман будет не очень рад, что мы тут обсуждаем что-то, отличное от NetApp :) Давайте перейдем в почту, если вы не против, я попробую прояснить ситуацию.
Не могли бы вы мне прислать письмо на minnus at outlook.com?
согласен. флуд закрываем.
Не-не, я все внимательно читаю, мне все комменты к блогу на почту сыпятся, мне тема active-active тоже интересна, потому что я пока не понимаю, как в случае полностью симметричного A-A можно обработать ситуацию когда на LUN, принадлежащий в равных правах двум контррллерам, вдруг рещили в один момент времени записать (изменить) один и тот же блок два хоста, вошедшие с разных портов рзных контроллеров. В кластерных FS для этого есть нода-арбитр, обрабатывающая в эксклюзивном режиме метаданные, но тут-то как?
Но тема, безусловно оффтопик, если продолжите в почте, может быть включите меня в cc:?
Роман, включим, конечно. Адрес твой старый, ник на мейл ру?
Я напишу о результатах переписки с Minus.
Вот что-то меня смущает в их механизме.. Не может лун принадлежать двум контроллерам одновременно. Видимо есть какая-то прослойка в микрокоде, которая пишет все данные на такие луны в какой-либо буфер, а потом кидает его на диск через один из контроллеров. Но как арбитрируются эти операции, как выбирается контроллер? По какому алгоритму данные скидываются из буфера на диски..?
Но вариант схемы с кластерной FS имеет право на существование - HUS ведь поддерживают и NFS и CIFS.. Но тогда чем это принципиально от НетАпа отличается?:) ?? задержки могут образовываться нехилые при высокой нагрузке, т. к. тут слабым звеном могут запросто стать сами контроллеры..
Николай, как раз сейчас пишу письмо. Нет, все не совсем так, как вы описываете, попробую пояснить в переписке.
Ок. Надеюсь вы не против опубликования результатов общения?
Здравствуйте,
Если Вы начали сравнивать NetApp и Hitachi Unified Storage, может обсудите non-disruptive upgrades и automatic deduplication. Будет очень интересно послушать.
Спасибо!
> reallocate на дефрагментированных томах, просто по их природной фрагментированности “бай дизайн”,
опечатка? не дедуплицированных?
Dmitry Morozovsky:
Поразительно, как на несколько сотен прочитавших, мало прочитавших внимательно. :) Поправлю счас.
IgorT:
Мы не начинали сравнивать, просто обсудили определенные особенности архитектуры массивов :)
А что именно Вас интересует в разрезе обозначенных вами тем? Если хотите что-то узнать или обсудить, то можно сделать это, например, связавшись со мной по почте, она есть тут выше в комментариях. Но если вкратце - то обновления без остановки есть и там и там, касательно дедубликации - мне не совсем ясен контекст фразы “automatic deduplication”.
Minus:
Скажем так, что о системах от Hitachi я знаю немного больше, чем о NetApp. В связи с этим и хотелось бы услышать мнение от людей, которые разбираются в системах от обоих производителей. ?? конкретно по этим 2 вопросам у меня и есть сомнения.
Почему то думал, что NepApp не позволяет делать обновления без перезагрузки.
По поводу “automatic deduplication” - точно знаю, что Hitachi ее делает в фоновом режиме и за ее реализацию отвечают отдельные микроконтроллеры, которые знают когда остановиться. За счет этого Hitachi обещает, что нет влияния на производительность и не нужен менеджмент со стороны админа СХД. Как именно реализован dedup у NetApp, не совсем в курсе. Хотелось бы подробностей. :)
Ложь HP про собственные массивы:
“В массивах НР Р10000 (V400 и V800), P9500, F200 и F400, Р6000, Р4000 все контроллеры работают в режиме active/active, разделяют доступ ко всем дискам и томам массива”
это не правда, в 3par НР Р10000 (V400 и V800) F200 и F400 диски имеют жестко закрепленных владельцев, если обращение к блоку данных идет не через контроллер-владелец и контроллер-backup, то принявший обращение контроллер становится прокси и передает данные контроллеру-владельцу по кластерной шине. Как и в NetApp. То что 3par объявляет все пути как active, не более чем внешняя иллюзия. Но в отличие от NetApp в 3par только 1/(количество контроллеров) запросов пойдут контроллеру-владельцу напрямую, остальные пойдут к нему-же но через кластерную шину.
“В массивах НР Р10000 (V400 и V800), F200 и F400, Р6000, Р4000 размер дисковой группы не имеет ограничений по максимальному кол-ву дисков и это позволяет автоматически равномерно распределять нагрузку ввода/вывода между большим количеством дисков (Wide Striping) и за счет этого добиваться очень высокой производительности.”
на самом деле в НР Р10000 (V400 и V800), F200 и F400 - 3par, ограничения следующие:
RAID 5/50 (от 2+1 до 8+1)
RAID 6 (4+2, 6+2, 8+2, 10+2, 14+2)
IgorT:
NetApp умеет non-disruptive upgrades. Делается это через cf takeover/giveback в HA-паре. По-моему, это умеет сейчас любой уважающий себя вендор :)
По поводу дедупликации. Дедупликация в файловых модулях HUS действительно по умолчанию функционирует в режиме, который позволяет запускать процесс дедупликации тогда, когда оказывается минимальное влияние на основные службы, плюс то, что процесс вынесен целиком на FPGA, дает минимальный оверхед на производительность. Однако, в случае NetApp также присутствуют механизмы уменьшения влияния процессов дедупликации на основные функции, плюс есть настройки, запускающие процесс в случае превышения определенного порога измененных данных на томе (в HUS реализована похожая схема). Поподробнее о дедупликации в NetApp Роман в этом блоге уже писал, если я не ошибаюсь.
Сергей:
Про Active/Active - это не ложь, это, скажем так, не совсем исчерпывающая информация. Контроллеры оба активны, так что это active/active HA-пара, однако, обработка запросов к одному и тому же тому работает именно так, как Вы сказали, и это называется ассиметричной системой доступа. Т.е. 3PAR - это asymmetric active/active массив, каким, к слову, является и NetApp. Со стороны хоста все пути будут видны как active, только те, которые ведут на “родной контроллер”, будут в состоянии Optimized, а остальные - Non-Optimized.
Сергей - перед тем как называть что-то ложью, почитали бы хотя бы 3PAR concept guide.
nikolay_a, Minus, Сергей
3PAR - это active/active массив как по фронтендам, так и по бекенду, в отличие от того же HUS и Netapp. В HUS всем LUN-ом владеет один контроллер (и имеет ограничение на макс. кол-во IOPS на LUN, проверено тестированием). Да, он проксирует доступ с минимальными оверхедами и балансирует LUN-ы довольно прозрачно для хостов, но производительность LUN-а всё равно завязана только на один контроллер.
В 3PAR LUN (VV в терминологии 3PAR) разбивается на кол-во частей, соответствующих кол-ву контроллеров, каждый контроллер работает со своей частью LUN-а, распараллеливая нагрузку. Наружу это видится, естественно, как единый том, с A/A доступом и рекомендованной multipath-policy round-robin. Конечно же, много запросов может попасть на контроллер, который не владеет данным LBA, но оверхед от проксирования - минимальный, близкий к нулевому, т.к. всё проксирование идёт через ASIC и высокоскоростные линки (а не через FC, как у нетаппа, если запрос придёт на непарный контроллер) и используется интересный когерентный кэш-менеджмент. ?? повторю - даже единичный том будет обрабатываться всеми контроллерами. Представим упрощённую ситуацию с тремя томами, каждый из которых требует 40% процессорной мощности одного контроллера, как они будут распределены по двум контроллерам HUS? Правильно, 2/1, соответственно, один контроллер будет загружен на 80% (что очень плохо), а второй - на 40%. В случае же 2-процессорного 3PAR-а каждый контроллер будет загружен на 60%, а в случае 4+ контроллеров - пропорционально меньше.
Роман, вы говорите о практически неограниченном агрегате, но можно ли создать один агрегат поверх нескольких контроллеров? Когда-то нельзя было, что сейчас?
Хм.
В 7400 дисковые полки закрепляются за парами контроллеров в случае 4-узловой системы, т.е. HA-пары соединены между собой интерконнектом. В случае распределения тома между всеми 4 контроллерами это, конечно, позитивно скажется на балансировке нагрузки и, косвенным образом, на производительности. Однако, возникает вопрос - что случается в случае потери половины массива? Т.е., если у нас есть два шасси, в которых сгруппированы попарно узлы, в случае потери одного из шасси мы теряем не просто половину массива, мы теряем все данные, так по сути мы потеряли половину LBA-адресов всех наших томов. Это действительно так? С этой точки зрения более “классическая” архитектура NetApp и тех же HUS выглядит более привлекательной - там-то ничего не потеряется.
Amazi:
Заставляете себя ждать ;)
> Сергей - перед тем как называть что-то ложью, почитали бы хотя бы 3PAR concept guide.
Я тоже не считаю, что это “эмоционально окрашенное” слово стоит использовать. Тут, конеычно не ложь. Но, скажем так: “не вся правда”.
> В 3PAR LUN (VV в терминологии 3PAR) разбивается на кол-во частей, соответствующих кол-ву контроллеров, каждый контроллер работает со своей частью LUN-а, распараллеливая нагрузку.
Правильно ли я понимаю, что в результате добавить еще два контроллера, к, допустим, системе 7400 изначально сконфигурированной и заполненной данными с двумя контроллерами, не является простым делом?
Ведь исходя из ваших слов, это потребует заново переразбить LUN-ы, разбитые для двух контроллеров?
Это не подначка, я правда хочу понять. Спасибо если разъясните.
> а не через FC, как у нетаппа
Поправлю: а у NetApp и не через FC, а через private 10G Ethernet в 3200, и через Infiniband в 6200.
> Роман, вы говорите о практически неограниченном агрегате, но можно ли создать один агрегат поверх нескольких контроллеров? Когда-то нельзя было, что сейчас?
Скажем так: это возможно теоретически, но решено было это не развивать и ограничить использование только теми, кто это, так получилось, что уже использует, мигрировав с Data ONTAP GX.
Дело в том, что работа с подобным aggregate потенциально вызывает серьезные проблемы с производительностью. Собственно про все это я уже писал, этой проблемой страдают по видимому все системы global filesystem, хороший пример - Isilon, и его результаты в SPECsfs, на которых видно, как нелинейно он масштабируется. Как и то, что хорошо это работает только на определенных workload (для Isilon - sequental read).
Так что вопрос стоит так: ??ли global filesystem с потенциальными проблемами с производительностью, или controller-bound volume (но global namespace, конечно), и нет проблем с производительностью и масштабированием. NetApp выбрал второе, и, как мне кажется, правильно.
Правильно ли я понимаю, что в результате добавить еще два контроллера, к, допустим, системе 7400 изначально сконфигурированной и заполненной данными с двумя контроллерами, не является простым делом?
Является простым:) Если будут добавлены контроллеры с дисковыми ресурсами, то можно оставить всё как было или перераспределить данные и по новым дискам/контроллерам. Делается это автономно и в бекграунде процедурой релевелинга (tunesys), входящей в базовую ОС.
2Minus потеря двух контроллеров - это уже вторая точка отказа, от которой практически никто не гарантирует защиту. В шасси - пассивный беклпейн. ?? что значит “потеряли”? Контроллеры поменяли, доступ восстановили. Потеря контроллеров из разных пар в 3PAR-е возможна без прекращения доступа к данным, но с доп. условиями (например, не с разницей менее времени, необходимого для перестроения кластера). Но если очень хочется, то можно создавать тома и только в рамках контроллера, делается элементарно, в этом и гибкость 3ПАР-а:)
и нет проблем с производительностью и масштабированием Как это нет?:) Один том не масштабируется же за рамки контроллера:)
>потеря двух контроллеров - это уже вторая точка отказа, от которой практически никто не гарантирует защиту
Что значит никто? :) HP позиционирует 3PAR как систему в том числе категории high-end, так что придется гарантировать. В качестве примера могу привести VSP - там может выйти из строя 3 из 4 VSD-пар (да и вообще 3/4 любых коммутируемых компонентов), и остановки доступа к данным не будет. В HUSVM каждый из двух контроллеров логически делится внутри пополам, итого 4 логических юнита, и можно потерять любые 2 без какого-либо влияния на данные.
А в 3PAR, получается, можно потерять только строго определенную “половину” массива (в случае 4 контроллеров), и при этом еще и произойдет полная остановка доступа к данным, т.е. нужно ждать пока заменят контроллер или контроллерную пару. Я, конечно, извиняюсь, но такого себе даже на рынке midrange в последнее время никто не позволяет. :)
Если же эту модную фичу не использовать, то 3PAR превращается в обычный ALUA массив, о чем и шла речь изначально. Самое смешное то, что вы сейчас делаете ровно то, что обычно делает HP в своих диалогах с заказчиками - сначала постулируете о какой-то супер-фиче, а когда заходит речь о значительных ограничениях (всякая мелочь, типа остановки доступа к данным при потере одного из двух контроллерных шасси), то возможность “создавать тома только в рамках контроллера” приводится как пример немерянной гибкости 3PAR :)
Minus не передёргивайте. Системы проектируются в расчёте на SPoF. В 3PAR-овском hi-end вообще единое шасси на 8 контроллеров, попробуйте его потерять:) ?? попробуйте в VSP потерять пару кэш-плат, массив сразу станет, две пары VSD из одной DKC - станет.
А в 3PAR, получается, можно потерять только строго определенную “половину” массива (в случае 4 контроллеров), и при этом еще и произойдет полная остановка доступа к данным, т.е. нужно ждать пока заменят контроллер или контроллерную пару.
А перечитать еще раз?
Minus так что будет, если в HUS VM потерять оба физических контроллера, как вы предлагаете сделать в 3ПАР?
Minus и при локализации томов на контроллер (что противоречит best practice, кстати), получим не ALUA массив, а frontend A/A, как у HUS. Как я уже говорил, оверхед при проксировании - минимальный.
??нтересно, откуда такая информация о VSP. Я могу вас уверить, что обе описанные ситуации не приводят к полной остановке массива, иначе грош цена такому high-end’у. Может, вы забыли упомянуть что-нибудь малозначимое, навроде того, что это были две единственные кэш-платы в массиве, да и в VSP было только две VSD-пары?
Про потерю строго определенной половины я, конечно, написал несколько не то. ??мел ввиду, что при потере тех самых контроллеров в одном шасси приведет к полной остановке массива. ВНЕЗАПНО.
О HUSVM, еще раз. Это двухконтроллерный массив, поэтому, конечно же, отключение обоих контроллеров приведет к его остановке. Однако, как я сказал, в нем может выйти из строя ЛЮБАЯ ПОЛОВ??НА - и все будет работать. А у 3PAR - почему-то нет.
Насчет frontend A/A - хост все пути увидит как optimized в обсуждаемом случае? ?? правильно ли я понимаю, что в этом случае “передать” том другому контроллеру затруднительно?
?? вот что еще интересно.
Если вы говорите о “frontend A/A, как у HUS”, то прямая аналогия возможна только в том случае, если у нас в кэше зеркалируются все операции, в том числе записи. То есть, другими словами, в случае 3PAR должен быть задействован механизм Persistent Cache. Но что делать бедным обладателям двух-контроллерных систем 3 PAR, ведь, как известно, Persistent Cache только “Supported on all quad-node and larger HP 3PAR arrays”. Получается, все те, у кого только два контроллера, обречены на “However, when a single controller fails, storage performance is not just cut in half. Instead, it drops an additional 20–30% as dual controller arrays go into “write-through” mode, suspending the use of write caching for data integrity reasons. ”
Это действительно так?
Ммм, не совсем верно сформулировал. Верно ли, что без механизма Persistent Cache двухконтроллерные системы 3PAR обречены на те самые 20-30% потери производительности при операциях не через “родной контроллер” в случае локализации томов отдельно на каждом контроллере по причине отсутствия механизмов зеркалирования всех операций в кэше обоих контроллеров?
2Minus если выпадает пара кэш-плат, массив теряет часть кэша с данными в нём. Помните же, что в отличие от 3PAR в VSP данные зеркалируются только в рамках пары плат. Что по-вашему он должен при этом делать?:) При этом, кстати, потребуется полный рестор, т.к. данные уже будут неконсистентны. Читайте документацию. Также почитайте, как и когда VSP выключает кэш на запись при воходе из строя одной кэш-платы и что такое Cache Persistence в 3PAR.
Любая половина из 2-х контроллеров - это сильно:) Что вы оцениваете как половину в 8-узловом 3ПАР-е и каким образом его единое для всех контроллеров шасси сможет выйти из строя? Какой это будет порядок ошибки? Еще раз повторю - более отсутствия SPoF никто из вендоров ничего не обещает (вроде, я не всех вендоров знаю).
В случае же слабосвязанных кластеров типа Нетаппа или Сторвайза - насколько заказчику будет легче, если он потеряет доступ к части данных, а не всем?:)
Еще раз - 3PAR использует не ALUA (точнее использует, но только для федеративной инфраструктуры, когда два массива на разных площадках видятся, как один), а обычный RR и в рамках одного массива все пути для него равнозначны. Передача тома другому контроллеру не имеет смысла, т.к. оверхед проксирования минимальный.
Minus как же вы выборочно читаете документацию и то, что я писал ранее. Persistent Cache в 4+ контроллерных системах позволяет после выхода из строя одного из контроллеров оставить весь оставшийся кэш доступным на зеркалированную запись и не имеет никакого отношения к проксированию (non-local access в терминологии 3PAR). ??ли вы хотите сказать, что в случае выхода из строя одного из контроллеров, HUS(VM) не выключает кэш на запись? Рисковые парни, до этого этим только ЕМС занималось, да и то крайне не рекомендовало включать данный режим.
Повторю в 3-й раз, если абоненту не приходит сообщение с первого:) Оверхед проксирования - на уровне нескольких процентов при максимально нагруженной системе. ?? снова повторю “локализации томов отдельно на каждом контроллере” - не бест практайс.
Ну вот мы и пришли к тому, что должна сдохнуть конкретная пара плат. Только вы забыли сказать, что при этом проблемы будут наблюдаться в пределах того DKC, где оно сдохло.
Еще раз, про половину. У нас получается какой-то сюрреалистичский разговор. Я вам говорю - если например в 3PAR 7400 умирает нафиг шасси с Node 0/1, то помирает все, так из-за того, что VV размазаны между контроллерами . А вы мне - а если вы отключите оба контроллера HUSVM, он же тоже помрет! Естественно, блин, помрет. Только в 3PAR и половину-то отключить нельзя, вот в чем дело.
Еще раз про ALUA. Ответьте, пожалуйста, всем жаждущим владельцам 2-контроллерных систем 3PAR - каковы будут потери производительности в случае операций записи через не-родной контроллер в случае локализации томов отдельно на каждом контроллере? Т.е укажите величину этого самого “минимального оверхеда проксирования”, когда заказчик не может использовать Persistent Cache, так как контроллеров у него два? ?? какая польза в этом случае от frontend A/A?
Ну а про “передача тома другому контроллеру не имеет смысла” - это классическое “это не те дроиды, которых вы ищете” :)
Amazi:
Давайте по порядку.
Вы сказали, что “при локализации томов на контроллер (что противоречит best practice, кстати), получим не ALUA массив, а frontend A/A, как у HUS.”
На что я вам резонно возражаю, что для того, чтобы “было как в HUS”, нужно зеркалировать между контроллерами все операции из кэша, то есть, нужно иметь механизм Persistent Cache, верно? ?? задаю резонный вопрос - как будет происходить проксирование в 2-контроллерных системах, можно с примером, что будет с блоком данных который идет от хоста на массив.
Когда я говорю про пару плат, то естественно имеются в виду парные кэш платы, а не какие-то там еще. Проблема будут array-wide, т.к. кэш - глобальный. Подумайте, что происходит, если пропала насовсем часть данных, которые были в кэше, да не записались на диск. Повторю - читайте ToO и MM. То же самое, что и в случае 3ПАР-овских контроллеров.
Вы понимаете, что такое SPoF? Как выход из строя 2 контроллеров относится к SPoF? Зачем отключать половину? Вы экстремал? Попробуйте отключить DKC (или как там она у HDS называется) в VSP:)
Я вам описал, что такое Persistent Cache и для чего он применяется, повторить еще раз?:)
Естественно, что в двухконтроллерной системе при рабочих обоих контроллерах кэш на запись зеркалируется. Как же иначе? Возможный оверхед я уже тоже указал.
А пример вам смогут показать на любом семинаре HP, приходите:) ??ли переходите в личку, чтобы не загромождать дискуссию Роман знает мой емейл либо можно в личку на хоботе.
Видимо, каждый из нас останется при своем мнении. :) Я до сих пор считаю что подход “У нас 4 контроллера, помереть могут два, но не любые” несколько странный.
Вообще, тема диалога зашла в глубокий оффтопик, так как блог все-таки про NetApp, а не про технологические преимущества 3PAR и Hitachi. Я предлагаю перейти на общение в почту - minnus at outlook.com. Конечно, если есть желание.
О! Консенсус! :)
Minus: Amazi:
Вы тут просто не начинайте какашками кидаться, а джентльменские разговоры-то всегда пожалуйста :)
Minus Представьте себе RAID10. Сколько дисков может помереть при сохранении доступа к данным при двухдисковом RAID10 (RAID1)? Правильно, половина. А если дисков таки больше, например, восемь? Теоретически-то половина, а практически - один:)
Давайте переведем дискуссию в почту, я свою выше написал :)
??нтересно было бы продолжить диалог, авось, оба что-то новое узнаем. :)
Minus: Amazi:
Если что - я тоже тут, если не против, то я бы тоже послушал.
Amazi: “читайте ToO и MM.”
дайте пожалуйста ссылки на документы, почитать.
Minus: Amazi:
Продолжайте, а… Очень уж интересно.
Немного про эктив/эктив. На рынке нет ни одного дискового массива эктив/эктив, т.к. под этим имеется ввиду одновременная запись в единый блок данных обоими контроллерами массива при арбитраже самим массивом. А вы все тут говорите об эктив/пэссив в чистом виде. То, что второй контроллер подхватывает работу первого, это все о том же. Единственное, что я видел - это GPRS от IBM , но это другая тема. Поправьте , если не прав.
Stormkiller:
Это зависит от того, что именно вы понимаете под работой “active/active” возможность одновременного доступа к одному блоку с разных контррллеров - это только одна из трактовок данного понятия. Можно, однако, считать, что “active/active” это просто одновременная работа двух контроллеров, не обязательно с записью в один блок данных. Вообще говоря, это тоже будет “active/active”, так что тут вопрос в терминологии и в определении термина, и определять его можно по разному, и в этом не будет никакой нечестности. Совсем не любой задаче жизненно нужно иметь одновременный доступ на запись с обоих контроллеров системы, поэтому такое ограничение термина мне кажется несколько надуманным.
2 AMAZI:
А по существу коллеги из HP могут ответь по вопросам поднятым Романом?
Odna Ptichka:
Так у меня тут фактически и нет вопросов, а, по существу, одни “ответы”, указывающие на плохой уровень знаний технологий и продуктов конкурента, с которым пресейлы этого вендора пытаются написать competitive-документ. Собственно задачей поста было привлечь внимание к этому факту, так как плохо разбирающиеся в теме люди, например потенциальные клиенты, которые в равной мере плохо знают что NetApp, что HP, могут все перечисленное принимать за правду, поэтому являются благодатной почвой для “заливания мозгов”.
??ли вы про мои вопросы об апгрейде и рестрайпе данных выше в комментариях? Ну, в общем, я получил ответ, поставил соответствующую пометку в личном списке.
Очень интересно читать такие дискуссии.
Но прочитав все вышеозвученное, я так и не понял в чем же преимущество подхода 3Par перед NetaApp и всеми другими не тру active/active массивами.
To Artur
Да ничем :) Нет полноценного актив-актив решения в случае железных стораджей. Ни у одного из вендоров. Полноценный актив-актив доступ на запись и чтение данных к одним и тем же блокам может быть только в случае cluster FS (GPFS, GFS, Lustre и т. п.). Все остальное - лишь попытки приблизится к этому. Воможно что 3PAR достаточно близко подошли к такой схеме, если верить утверждению Amazi о том, что данные в один лун могут писаться с 4-х контроллеров одновременно. Но я в этом почему-то не верю, т. к. реально данные пишутся из КЭША, общего для ПАРЫ контроллеров (если я правильно разобрался с терминологией 3PAR). Т. е. у 3PAR в случае конфигурации с 4-мя и 8-и контроллерами мы имеем слабосвязанный кластер между ПАРАМ?? контроллеров. Соот-но ни о каком реальном разделяемом (арбитрируемом) доступе к луну с 4-х контроллеров одновременно речи не идет.
To Romx
@Это зависит от того, что именно вы понимаете под работой “active/active”@ - я лично понимаю под этим полноценный арбитрируемый доступ к к одному НАБОРУ блоков (не не к одному блоку :))) с разных контроллеров (сколько бы их ни было в массиве) в один момент времени. Проще говоря, если я запросил выборку на 1 Тб данных из а этот запрос в идеале был бы распараллелен между любым кол-вом контроллеров и выдан мне за время N/кол-во контроллеров, а не за N.
Все остальное это не более чем относительно успешные (или не успешные) попытки выжать лишние мс и имеющегося решения. ?? зачастую эти попытки приводят к совершенно противоположным результатам у реальных заказчиков.
nikolay_a:
Позиция NetApp в данном вопросе прагматична. Если это “фича ради фичи”, или если это редко востребованная в реальных задачах возможность (и которую можно сравнительно просто решить каким-то иным, обходным путем), но которая приводит при ее реализации к существенному усложнению (читай - “удорожанию и непредсказуемости производительности”), то ну ее нафиг такую фичу. :)
Romx:
НетАпп хотя бы честен в своих обещаниях. А для России это большая редкость. Как сказал один хороший человек из московского представительства - “мы ж не бусы с зеркальцами папуасам впариваем”:)
А вот поведение пресейлов некоторых других вендоров (не буду показывать пальцем) именно так и выглядит.
nikolay_a:
Да , тут полностью поддержу.
Какая-то надуманная функция, никому не нужная. Если доступ к данным не параллелится , то ну ее и это не эктив эктив.
?? кстати “т. к. реально данные пишутся из КЭША, общего для ПАРЫ контроллеров (если я правильно разобрался с терминологией 3PAR” - тут тоже непонятно как идет арбитраж и пишутся ли данные в одну группу блоков данных ? Непонятно.
Пока читал про 3PAR - возник вопрос - чем же их конфигурация из, например, 4-х контроллеров отличается от нетапа с 4-мя контроллерами. Те же HA-пары, та же в общем-то логика обработки “чужих” данных. Лишний раз убедился, что хорошие инженеры работают и в 3PAR и в NetApp.
Жаль только что HP купила 3PAR. Печальный пример полного остутствия развития архитектуры EVA доставшегося от DEC (Compaq) наводит на грустные мысли о будущем 3PAR :(. Будут выжимать из чужих инженерных решений бабло по максимуму, а потом выкинут на помойку..
У продавцов HP 3Par наметилась печальная тенденция. Они теперь в ТЗ пытаются прописsdать поддержку active/active контроллеров и неприемлимость ALUA.
??нтересная дискуссия вышла. А по-моему active/active в том виде в котором есть(LUSTRE/GFS итд) - отлично работает. Кому надо тот использует эти кластерные ФС.
Artur,
Тенденция прописывать в любое ТЗ поддержку active-active объяснить легко, если знать как они работают. Дело в том, что у них есть внутренний документик (FRP) в котором прописаны все фичи массива, начиная со всякой базовой фигни вроде поддержки ОС и заканчивая тем как у них реализованы более сложные функции. Для 7400 у них там аж 58 пунктов. Поэтому чем больше “заточек” пресейл нусуёт в ТЗ - тем лучше. Тем больше вероятность что все не порежут.
К дискусии могу добавить только одно - 7400 может потерять два или даже три контроллера (главное не одновременно) и кеш не потеряется, т.к. при потере контроллера он перезеркалируется на другой, “живой” контроллер.