Comments 30
В сервере Dell PowerEdge R620 не 4 процессора, а два. Может, имелся в виду Dell PowerEdge R920?
У вас параметры FIO в одну строчку слепились :-)
Зеркалирование кэша на чтение? ЧУДО, чудо!!!
Один контроллер. Зачем тогда вообще такой «массив»? Подключить к серверу JBOD будет дешевле, а по функционалу — не сильно хуже.
Мм. Может из поста это не очевидно, но:
1. Речь идет о тестовой конфигурации.
2. Вы не поверите, но такие «массивы» есть и они работатют:)
Насчет JBOD:
1. Немного странно слышать про «функционал» по отношению к JBOD корзине.
2. Безусловно, вам никто не мешает покупать JBOD, и да, он, естественно, дешевле, Америку вы не открыли). Не очень понятно правда, какое отношение ваш комментарий имеет к теме поста.
1. Речь идет о тестовой конфигурации.
2. Вы не поверите, но такие «массивы» есть и они работатют:)
Насчет JBOD:
1. Немного странно слышать про «функционал» по отношению к JBOD корзине.
2. Безусловно, вам никто не мешает покупать JBOD, и да, он, естественно, дешевле, Америку вы не открыли). Не очень понятно правда, какое отношение ваш комментарий имеет к теме поста.
Прошу простить меня за неочевидность и непоследовательность. Исправляюсь)
Тесты отличные, работа проделана немалая, за что нельзя не поблагодарить. Спасибо вам )
Теперь касательно моего комментария. Да, я отлично осведомлен о том, что такие конфигурации имеют место быть во многих IT-средах.
Просто смысла в такой конфигурации мне видится мало. Ок, я могу консолидированно держать данные на таком устройстве. Даже вот какая-никакая производительность присустсвует. Но это все перечеркивает выход из строя мозгов девайса. Я не смею вас просить проделать те же тесты в нормальной двух-контроллерной конфигурации, обеспечивающей бОльшую отказоустойчивость и надежность хранимых данных.
Потом и делаю не совсем очевидное сравнение с JBOD. Толку от такого одноконтроллероного массива столько же, сколько от JBOD, какую бы производительность он не давал.
Ничего личного, просто мнение.
Тесты отличные, работа проделана немалая, за что нельзя не поблагодарить. Спасибо вам )
Теперь касательно моего комментария. Да, я отлично осведомлен о том, что такие конфигурации имеют место быть во многих IT-средах.
Просто смысла в такой конфигурации мне видится мало. Ок, я могу консолидированно держать данные на таком устройстве. Даже вот какая-никакая производительность присустсвует. Но это все перечеркивает выход из строя мозгов девайса. Я не смею вас просить проделать те же тесты в нормальной двух-контроллерной конфигурации, обеспечивающей бОльшую отказоустойчивость и надежность хранимых данных.
Потом и делаю не совсем очевидное сравнение с JBOD. Толку от такого одноконтроллероного массива столько же, сколько от JBOD, какую бы производительность он не давал.
Ничего личного, просто мнение.
Архивы держать на этом массиве — нормально. Оракловая база или несколько десятков виртуальных машин не выживут, тормоза будут адские.
Я бы не стал делать столь решительных выводов. Обратите внимание на абзац про Segment Size. Очевидно, что для рандомной нагрузки небольшими блоками нужно уменьшать размер SS и размещать тома на RAID10. А также на то, что в одноконтрольной конфигурации кэш, очевидно, работает в нештатном режиме. По логике при наличии двух контроллеров информация в кэше должна зеркалироваться. Может из-за этого в нашей тестовой конфигурации кэш на чтение не работал. Хотя это только предположение…
Но безусловно нагруженную SQL базу лучше размещать на E54xx или E55xx — эта линейка гораздо лучше держит рандомную нагрузку. А вот небольшую виртуальную инфраструктуру — до 40-50 VM в двухконтроллерной конфигурации, я думаю, 2700 потянет. Но, опять же, это зависит от задач, которые будут запускаться на виртуалках.
Но безусловно нагруженную SQL базу лучше размещать на E54xx или E55xx — эта линейка гораздо лучше держит рандомную нагрузку. А вот небольшую виртуальную инфраструктуру — до 40-50 VM в двухконтроллерной конфигурации, я думаю, 2700 потянет. Но, опять же, это зависит от задач, которые будут запускаться на виртуалках.
For All
Еще раз хочу подчеркнуть — линейка массивов E-Series предоставляет возможности для адаптации массивов под конкретный шаблон нагрузки. Это может быть как потоковая нагрузка, так и рандомная. И массивы будут отрабатывать эту нагрузку без проблем (с учетом возможностей каждой модели конечно.)
А вот смешанная нагрузка — например, когда одновременно идет рандомное чтение и потоковая запись — противопоказана. Особенно на младших моделях, таких как протестированный E2700.
Еще раз хочу подчеркнуть — линейка массивов E-Series предоставляет возможности для адаптации массивов под конкретный шаблон нагрузки. Это может быть как потоковая нагрузка, так и рандомная. И массивы будут отрабатывать эту нагрузку без проблем (с учетом возможностей каждой модели конечно.)
А вот смешанная нагрузка — например, когда одновременно идет рандомное чтение и потоковая запись — противопоказана. Особенно на младших моделях, таких как протестированный E2700.
У вас в описании «Методики тестирования», в п.6 опечатка, видимо.
Последовательная запись/чтение блоками маленького размера (4 КБ, например), не имеет практической пользы?
Последовательная запись/чтение блоками маленького размера (4 КБ, например), не имеет практической пользы?
Так вообще мало кто пишет в real-life. Навскидку приходит в голову только redo-log базы данных, но, обычно, если я правильно помню, он там аггрегируется на уровне приложения в более крупные блоки, а вообще сейчас, если нужна высокая производительность на последовательной записи, надо смотреть на All-Flash системы.
Я бы вообще сказал, что если интересует СХД не с целью хранить редко используемую информацию, то нет причин смотреть на механические диски вообще. У кого нет в линейке all-flash СХД, те пытаются продавать классические СХД, набитые только SSD-дисками, причем текущий уровень скидок дает повод предположить, что просели продажи как СХД на механических дисках, так и СХД вообще. Известный вендор из трех букв недавно предлагал скидку в районе 50% от розничной цены и был очень расстроен, что мы предпочли не их решение…
Я бы вообще сказал, что если интересует СХД не с целью хранить редко используемую информацию, то нет причин смотреть на механические диски вообще.
Если у вас количество денег стремится к бесконечности, или вы их добываете в негораниченном количестве из
причем текущий уровень скидок дает повод предположить, что просели продажи как СХД на механических дисках, так и СХД вообще.
Ежегодные отчеты IDC с вами не согласны, хотя, конечно, сумасшедших покупателей на рынке все меньше, и они все тщательнее считают, что они получат за свои деньги.
Известный вендор из трех букв недавно предлагал скидку в районе 50% от розничной цены
Вы правда считаете, что 50% от листпрайса — это большая скидка? 45% это стандартная скидка для топового партнера, и это значит, что от нее еще только начинаются индивидуальная скидка на хороший/нужный проект. Лично видел скидку в 75%, и это не на какие-то суперпупер системы, а на вполне себе серийную модель.
Если у вас количество денег стремится к бесконечности, или вы их добываете в негораниченном количестве из недр воздуха — безусловно так. Увы, на рынке теперь считают деньги, и сверхприбыли это скорее исключение, чем повседневность.
Я очень сочувствую тем, у кого нет денег на all-flash СХД, они еще пожалеют о том, что сэкономили. Ну, конечно, если у них не архив советских фильмов времен начала перестройки на этой СХД лежать будет.
Ежегодные отчеты IDC с вами не согласны, хотя, конечно, сумасшедших покупателей на рынке все меньше, и они все тщательнее считают, что они получат за свои деньги.
У нас уже есть 3 mid-range СХД и перед покупкой еще одной мы протестировали модели из текущих линеек 4 ведущих игроков на рынке. И решили, что четвертый раз мы в это наступать не будем.
Лично видел скидку в 75%, и это не на какие-то суперпупер системы, а на вполне себе серийную модель.
Вы продаете или покупаете? Если продаете — можем поговорить о сотрудничестве.
Я очень сочувствую тем, у кого нет денег на all-flash СХД
Ну людям, которые знают, как оптимально тратить деньги не надо сочувствовать.
Топить печь долларовыми банкнотами может и круто (горят хорошо, жарко), но не особо продуктивно.
Есть отдельные области, где all-flash нужен, это бесспорно. Это примерно несколько процентов, сомневаюсь что больше 10. Есть остальные области, где выгоды от него не окупают вложений. Грамотный архитектор это все понимает, и не топит печь баксами, даже если они и хорошо горят.
Класть на flash логи базы — разумно, так как это напрямую влияет на общую производительность. Класть на нее cold data, которые составляют 80-90% объема данных — неразумно, так как им все равно на чем лежать, хоть на SATA.
Вообще говоря, я убежден, что для массового потребителя, который не NASDAQ и не NYSE, оптималны к использованию системы кэширования во flash, типа NetApp VST (Flash Cache и Flash Pool), а вовсе не кранилища в нем. Результат «на вложенный доллар» — оптимален.
Класть на flash логи базы — разумно, так как это напрямую влияет на общую производительность. Класть на нее cold data, которые составляют 80-90% объема данных — неразумно, так как им все равно на чем лежать, хоть на SATA.
Это надо понимать так, что во всех на свете базах cold data — 80-90%? Я, наверное, не самый грамотный архитектор, но мне важнее, что некоторые бизнес-процессы теперь вместо дней занимают десятки минут, а аналитики не мешают онлайну (да, я знаю, что принято разделять аналитику и онлайн, но тут уже от нас, как конечных пользователей, мало что зависит).
Это надо понимать так, что во всех на свете базах cold data — 80-90%? Я, наверное, не самый грамотный архитектор
Как архитектор, это вы должны ответить, каков процент соотношения workload к total size, и объем cold data в вашем конкретном случае, а у вас, видите, даже нет на это ответа, хотя вы уже хотите All-Flash. Не слишком профессионально, как мне кажется.
Не спорю, All-Flash сегодня — горячая тема, они дорогие, вендорам их продавать интересно с маржинальной точки зрения, поэтому маркетинг их активно продавливает, но ориентироваться только на маркетинговое давление… Не слишком-то дальновидно, не так ли?
но мне важнее, что некоторые бизнес-процессы теперь вместо дней занимают десятки минут,
Мы опять возвращаемся к вопросу эффективности.
Допустим есть классическая система. На ней время выполнения, для простоты — 1 час, а ее цена X.
Есть две других системы, на первой время выполнения — 20 минут, а цена — 2X, а у второй — 15 минут, а цена — 10X.
Далее вопрос в том, насколько выигрыш 5 минут, то есть около 8%, стоит пятикратного увеличения цены.
В каких-то случаях — да, наверное. В каких-то — нет. Не заьывайте, что «скорость» существует не сама по себе, а только как способ удовлетворить бизнес-нужды. Если для бизнеса 8% улучшения скорости обработки не являются критичными, то, наверное, не стоит за них переплачивать, и первая система, формально не такая быстрая, но существенно дешевле, будет для бизнеса более выгодной.
Это ведь известная ситуация, что, начиная с определенного момента, каждая ступенька увеличения быстродействия, например, обходится все дороже и дороже. И тут бизнес должен сказать свое слово, что для него уже достаточно, и пора остановиться «топить печь банкнотами».
Если вы еще не смотрели на Flash Cache в той или иной форме, (у NetApp он так и называется, у EMC это FASTcache, у IBM вроде что-то тоже было такое), то советую глянуть. Вот тут на хабре что-то дажн было на эту тему: habrahabr.ru/company/netapp/blog/115345/
Вы не поняли, я знаю, какой у меня процент cold data. И мы провели тестирование всех своих бизнес-процессов на демо-системах, предоставленных основными производителями СХД, в т.ч. и NetApp. И реализация Flash Cache конкретно в модели 2240-2 нас не впечатлила. Совсем.
Что же касается увеличения эффективности в процентах, то эффект от замены СХД вот такой:
Тест / Новый сервер + старая СХД / Новый сервер + all-flash СХД
1 / +75% / +475%
2 / +175% / +1150 %
3 / +123 % / +5000%
и т.д.
Реально, отчет, который выполнялся 25 часов на старом железе (Sun Enterprise M4000 + HP Eva 4400), начал работать за 9 минут на новом.
Что же касается увеличения эффективности в процентах, то эффект от замены СХД вот такой:
Тест / Новый сервер + старая СХД / Новый сервер + all-flash СХД
1 / +75% / +475%
2 / +175% / +1150 %
3 / +123 % / +5000%
и т.д.
Реально, отчет, который выполнялся 25 часов на старом железе (Sun Enterprise M4000 + HP Eva 4400), начал работать за 9 минут на новом.
Да, и кстати, кроме RamSan/IBM и Violin/HP есть и другие производители all-flash СХД. И цены у них значительно интереснее.
Вы не поняли, я знаю, какой у меня процент cold data.
И какой он у вас? Просто интересно.
И реализация Flash Cache конкретно в модели 2240-2 нас не впечатлила. Совсем.
FAS2240-2 это самая младшая система линейки, это, фактически entry level. К тому же на ней нет Flash Cache, там есть Flash Pool, а это примерно то же, да все же не то.
Если вы имеете задачи под midrange, как вы говорили выше, то вам надо брать нетапповский midrange, то есть FAS8020 или 8040. Но брать entry-level, причем самую младшую модель, грузить ее задачей ей не по силам, и делать выводы по ней о технологи вообще — это, снова, выглядит не очень профессионально, извините.
Реально, отчет, который выполнялся 25 часов на старом железе (Sun Enterprise M4000 + HP Eva 4400), начал работать за 9 минут на новом.
Вы меня, кажется, не понимаете. Я не отрицаю, что all-flash быстро работают. Я говорю только о том, что ездить можно не только на Ferrari. :)
И в ряде случаев, для подавляющего большинства (а вы пока никак не показали, что вы — не это большинство) all-flash являются избыточной и неэффективной тратой денег, просто потому что есть более экономически обоснованные варианты.
Многие ездят на машинах. Некоторые даже в принципе имеют возможность купить Ferrari. Но покупают другие машины. Почему?
25 часов на старом железе (Sun Enterprise M4000 + HP Eva 4400),
EVA4400 и Sun M4000- это даже не смешно. Это ж какие-то системы из начала 2000-х, времен третьего Пентиума вроде? :)
И какой он у вас? Просто интересно.
Около 40%.
FAS2240-2 это самая младшая система линейки, это, фактически entry level
Вы правда считаете, что по каждой закупке весь список оборудования я сам выбираю? Менеджер NetApp по нашим характеристикам нагрузки посоветовал эту модель, мы убедились, что это лажа, выбрали другого вендора. Нам пофигу, нас выбранный вариант устраивает, NetApp остался без денег.
EVA4400 и Sun M4000- это даже не смешно. Это ж какие-то системы из начала 2000-х
Вы правда думаете, что такие железки покупаются на 2-3 года, а потом — в утиль? Посмотрите сколько стоит аналогичная текущая линейка железа у Оракла, а их не 1 штука закупается, еще горячая замена, тестовые базы и т.д.
Вы правда думаете, что такие железки покупаются на 2-3 года, а потом — в утиль?
Я правда думаю, что система семилетней давности, не только не продающаяся, но уже даже End Of Life, не может считаться показательной и сравнения с ней не могут приводится в качестве доказательства преимущества.
Вы берете дисковую систему семилетней давности, и сервер уже несуществующей компании примерно того же возраста, и сравниваете их, нет, не с современной дисковой системой, и современным же сервером. Кто бы удивлялся, что выигрыш будет большой. Но вот будет ли он настолько большой при сравнении с современными дисковыми системами? Вот тут у меня обоснованные сомнения.
Менеджер NetApp по нашим характеристикам нагрузки посоветовал эту модель, мы убедились, что это лажа,
Настраивали — сами, или помогал кто знающий?
Мы сравнивали в т.ч. с HP 3Par 7200, EMC VNX5200, да, они побыстрее, чем Eva, но даже не вдвое при сравнимом количестве дисков, раза в полтора от силы. NetApp настраивал их специалист, визитка вот под рукой лежит, почти целый день у нас просидел…
Мы сравнивали в т.ч. с HP 3Par 7200, EMC VNX5200
Ну так про это и речь. Вы сравнили MSA2040 с EVA6500 и предсказуемо выяснили, что entry-level система с вдвое более слабыми процессорами, с в два раза меньшей емкостью кэша и вдвое дешевле по цене работает медленнее. Ну, ОК, тоже мне научное открытие :)
Sign up to leave a comment.
Тестирование NetApp E2700