company_banner

Тестирование NetApp E2700

    Testing NetApp E2700

    Мне давно не попадался на тесты массив начального уровня, способный пропустить через один контроллер до 1.5 Гб/сек при потоковой нагрузке. NetApp E2700 как раз справился с этой задачей. В июне я провёл Unboxing NetApp E2700. И теперь готов поделиться с вами результатами тестирования этой системы хранения данных. Ниже привожу результаты нагрузочных тестов и получившиеся количественные показатели производительности массива NetApp E-Series 2700 (IOps, Throughput, Latency).

    Конфигурация дискового массива следующая:

    Конфигурация дискового массива NetApp E2700

    Схема подключения массива к серверу:

    Схема подключения массива NetApp E2700 к серверу

    И конфигурация тестового сервера:

    Конфигурация тестового сервера

    Методика проведения тестирования


    В качестве генератора нагрузки я использую FIO benchmark, как самый «true» benchmark под Linux. Я хочу получить данные по средней скорости (bandwith, Mb/s) и усредненным задержкам (latency, ms) при следующих типах нагрузки:
    1. 100% последовательное чтение, блоками по 256 kb, 512 Kb и 1024 Kb;
    2. 100% последовательная запись, блоками по 256 kb, 512 Kb и 1024 Kb;
    3. Смешанные последовательные чтение/запись (50/50), блоками по 256 kb, 512 Kb и 1024 Kb;
    4. 100% случайное чтение, блоками по 4 kb, 8 Kb и 16 Kb;
    5. 100% случайная запись, блоками по 4 kb, 8 Kb и 16 Kb;
    6. Смешанные случайные чтение/запись (50/50), блоками по 256 kb, 512 Kb и 1024 Kb;

    При этом я буду использовать два LUN с массива, каждый размером по 1 Тб, которые доступны на уровне сервера как RAW устройства: sdb и sdc.

    Важным моментом моих тестов является сравнение производительности различных уровней RAID, которые поддерживает массив. Поэтому я буду поочередно подавать нагрузку на LUN, созданные на: DDP, RAID6, RAID10. И Dynamic Disk Pool и Volume Groups я буду создавать на базе всех 24 дисков.

    Для того чтобы не ставить результаты в зависимость от алгоритма работы пресловутого «Linux memory cache», я использую именно блочные устройства, без организации поверх них файловой системы. Безусловно, это не самая стандартная конфигурация для потоковых приложений, но мне важно понять, на что способен именно массив. Хотя, забегая вперед, скажу, что при использовании в паттерне нагрузки FIO параметров direct=1 и buffered=0 работа (запись) с файлами на уровне EXT4 показывает почти одинаковые результаты с блочными устройствами по bandwith. При этом показатели latency при работе с файловой системой выше на 15-20 процентов, чем при работе с raw devices
    Паттерн нагрузки для FIO сконфигурирован следующим образом:

    [global]
    description=seq-reads
    ioengine=libaio
    bs= см. выше
    direct=1
    buffered=0
    rw=[write, read, rw, randwrite, randread, randrw]
    runtime=900
    thread

    [sdb]
    filename=/dev/sdc
    iodepth=см. ниже

    [sdc]
    filename=/dev/sdb
    iodepth=см. ниже


    Если я правильно понял, man по fio, параметр iodepth, определяет количество независимых потоков, работающих с диском одновременно. Соответственно, в конфигурации я получаю количество потоков равное X*2 (4, 8, 16).

    В результате набор тестов у меня получился следующий:

    Набор тестов для NetApp E2700

    С методиками разобрались, паттерны определили, даем нагрузку. Для облегчения труда админа можно нарезать набор паттернов FIO в виде отдельных файлов, в которых будут меняться значения двух параметров – bs и iodepth. Потом можно написать скрипт, который в двойном цикле (меняем значения двух параметров) выполнит прогон всех наших паттернов с сохранением нужных нам показателей в отдельные файлы.

    Да, чуть не забыл пару моментов. На уровне массива я конфигурировал параметры кэша следующим образом:
    • для потоковой записи я выключал кэш на чтение;
    • для потокового чтения, выключал, соответственно, кэш на запись, и не использовал алгоритм dynamic read prefetch;
    • для смешанных операций чтения и записи активировал кэш полностью.

    На уровне Linux я менял штатный планировщик I/O на noop при потоковых операциях и на deadline при рандомных. Кроме этого, для грамотной балансировки трафика на уровне HBA я установил multipath-драйвер от NetApp, MPP/RDAC. Результаты его работы меня приятно удивили, балансировка потока данных между портами HBA выполнялась почти 50-на-50, чего я никогда не наблюдал ни у Qlogic, ни у штатного linux multipathd.

    SANTricity имеет ряд настроечных параметров (я уже писал выше, например, про управление кешированием данных на уровне тома). Еще один потенциально интересный параметр это Segment Size, который можно задавать и изменять на уровне тома. Segment Size – это блок, который контроллер записывает на один диск (данные внутри сегмента записываются блоками по 512 байт). Если я использую DDP, то размер этого параметра для всех томов, созданных в пуле, одинаков, (128k) и изменить его нельзя.

    Для томов, создаваемых на базе VolumeGroup, я могу выбирать преднастроенные шаблоны нагрузки для тома (FileSystem, Database, Multimedia). Кроме этого, я могу выбрать размер SegmentSize самостоятельно в диапазоне от 32 Кб до 512 Кб.

    Выбор преднастроенных шаблонов нагрузки для тома, созданного на базе VolumeGroup

    Вообще для встроенных Volume I/O characteristics type размер Segment Size не отличается особой разнообразностью:
    • Для паттерна File system = 128 Kb;
    • Для паттерна Database = 128 Kb;
    • Для паттерна Multimedia = 256 Kb.

    Я не изменял предлагаемый по умолчанию при создании тома паттерн (File system) для того, чтобы Segment Size для томов, создаваемых на DDP и на обычной VolumeGroup, был одинаковым.

    Безусловно, я поиграл с размером Segment Size, чтобы понять, как он влияет на производительность операций записи (для примера). Результаты вполне стандартные:
    • При самом малом размере, SS = 32 Кб, я получаю более высокие показатели производительности при операциях с небольшим размером блоков;
    • При самом большом размере, SS = 1024 Кб, я получаю более высокие показатели производительности при операциях с большим размером блоков;
    • Если я выравниваю размер SS и размер блока, которым оперирует FIO, то результаты получаются еще лучше;
    • Есть одно «но». Я обратил внимание, что при потоковой записи большими блоками и SS = 1024 Кб значения latency получаются выше, чем при размере SS = 128 Кб или 256 Кб.

    Итого, полезность этого параметра очевидна, и если мы предполагаем, что у нас будет много рандомных операций, то имеет смысл задать его равным 32 Кб (если, конечно, мы не используем DDP). Для потоковых операций я не вижу смысла задавать значение SS по максимуму, т.к. кардинального прироста скорости передачи данных я не наблюдал, а показатели latency могут быть критичными для приложения.

    Результаты (оценка и сравнение результатов)


    Результаты тестов по DDP

    Результаты тестов по DDP для NetApp E2700

    Результаты тестов на RAID6

    Результаты тестов на RAID6 для NetApp E2700

    Результаты тестов на RAID10

    Результаты тестов на RAID10 для NetApp E2700

    Оценка результатов


    1. Первый момент, на который я сразу обратил внимание, это 0% использования кэша на чтение при любом паттерне (и даже при полностью выключенном кэше на запись). С чем это было связано, понять так и не удалось, но результаты по операциям чтения проседали по сравнению с операциями записи ощутимо. Возможно, это связано с одноконтроллерной конфигурацией тестового массива, так как кэш на чтение должен зеркалироваться между двумя контроллерами.
    2. Второй момент, это достаточно низкие показатели по рандомным операциям. Объясняется это тем, что размер Segment Size (как я писал выше) по умолчанию использовался равным 128 Кб. Для небольших размеров блоков такой размер SS не подходит. Для проверки я запускал рандомную нагрузку на томах в RAID6 и RAID10 с SS = 32 Кб. Результаты получались гораздо более интересными. Но в случае с DDP мы не имеем возможности менять размер SS, поэтому рандомная нагрузка на DDP противопоказана.
    3. Если сравнивать производительность DDP, RAID6 и RAID10 при размере SS = 128 Кб, то можно отследить следующие закономерности:

    • В целом большой разницы между тремя разными логическими представлениями блоков не выявлено;
    • RAID10 стабильнее держит нагрузку, даже смешанную, выдавая при этом лучшие показатели latency, но проигрывает в скорости потоковой записи и чтения RAID6 и DDP;
    • RAID6 и DDP при рандомных операциях при увеличении размера блока показывают лучшие значения latency и IOps. Скорее всего, это связанно с размером SS (см. выше). Однако RAID10 не показал такого эффекта;
    • Как я уже написал выше, рандомная нагрузка для DDP противопоказана, во всяком случае при размерах блоков меньше 32 Кб.


    Выводы


    Мне давно не попадался на тесты массив начального уровня, способный пропустить через один контроллер до 1.5 Гб/сек при потоковой нагрузке. Можно предположить, что двухконтроллерная конфигурация сможет обработать до 3 Гб/сек. А это поток данных до 24 Гбит/сек.

    Конечно, тесты, использованные нами, являются синтетическими. Но показанные результаты очень неплохие. Как и предполагалось, массив слабо держит смешанную нагрузку при рандомных операциях, но чудес не бывает :-).

    В плане юзабилити и возможностей оптимизации настроек под конкретный шаблон нагрузки для массива начального уровня E2700 показал себя на высоте. SANTricity имеет понятный и достаточно простой интерфейс, минимум глюков и тормозов. Нет излишних настроек значений, которые зачастую не понятны (вспоминаю управляющий интерфейс IBM DS 4500 — это было что-то)). В целом все на твердую «4».
    CloudMTS
    Виртуальная инфраструктура IaaS

    Comments 30

      +1
      В сервере Dell PowerEdge R620 не 4 процессора, а два. Может, имелся в виду Dell PowerEdge R920?
        0
        Нет, имелся в виду Dell PowerEdge R620. Опечатался. Спасибо за замечание.
        +2
        У вас параметры FIO в одну строчку слепились :-)
          0
          Поправили, спасибо.
          0
          Зеркалирование кэша на чтение? ЧУДО, чудо!!!
            0
            Один контроллер. Зачем тогда вообще такой «массив»? Подключить к серверу JBOD будет дешевле, а по функционалу — не сильно хуже.
              0
              Мм. Может из поста это не очевидно, но:
              1. Речь идет о тестовой конфигурации.
              2. Вы не поверите, но такие «массивы» есть и они работатют:)
              Насчет JBOD:
              1. Немного странно слышать про «функционал» по отношению к JBOD корзине.
              2. Безусловно, вам никто не мешает покупать JBOD, и да, он, естественно, дешевле, Америку вы не открыли). Не очень понятно правда, какое отношение ваш комментарий имеет к теме поста.
                0
                Прошу простить меня за неочевидность и непоследовательность. Исправляюсь)
                Тесты отличные, работа проделана немалая, за что нельзя не поблагодарить. Спасибо вам )
                Теперь касательно моего комментария. Да, я отлично осведомлен о том, что такие конфигурации имеют место быть во многих IT-средах.
                Просто смысла в такой конфигурации мне видится мало. Ок, я могу консолидированно держать данные на таком устройстве. Даже вот какая-никакая производительность присустсвует. Но это все перечеркивает выход из строя мозгов девайса. Я не смею вас просить проделать те же тесты в нормальной двух-контроллерной конфигурации, обеспечивающей бОльшую отказоустойчивость и надежность хранимых данных.
                Потом и делаю не совсем очевидное сравнение с JBOD. Толку от такого одноконтроллероного массива столько же, сколько от JBOD, какую бы производительность он не давал.
                Ничего личного, просто мнение.
                  0
                  Нет проблем)
                  Конечно в продакшн имеет смысл ставить двухконтроллерную конфигурацию. И я думаю что цена вопроса будет не намного выше (если вообще выше)).
                  Мы тестировали то, что прислали, а прислали, к сожалению, одноконтроллерную конфигурацию.
              0
              Архивы держать на этом массиве — нормально. Оракловая база или несколько десятков виртуальных машин не выживут, тормоза будут адские.
                0
                Я бы не стал делать столь решительных выводов. Обратите внимание на абзац про Segment Size. Очевидно, что для рандомной нагрузки небольшими блоками нужно уменьшать размер SS и размещать тома на RAID10. А также на то, что в одноконтрольной конфигурации кэш, очевидно, работает в нештатном режиме. По логике при наличии двух контроллеров информация в кэше должна зеркалироваться. Может из-за этого в нашей тестовой конфигурации кэш на чтение не работал. Хотя это только предположение…
                Но безусловно нагруженную SQL базу лучше размещать на E54xx или E55xx — эта линейка гораздо лучше держит рандомную нагрузку. А вот небольшую виртуальную инфраструктуру — до 40-50 VM в двухконтроллерной конфигурации, я думаю, 2700 потянет. Но, опять же, это зависит от задач, которые будут запускаться на виртуалках.
                0
                For All
                Еще раз хочу подчеркнуть — линейка массивов E-Series предоставляет возможности для адаптации массивов под конкретный шаблон нагрузки. Это может быть как потоковая нагрузка, так и рандомная. И массивы будут отрабатывать эту нагрузку без проблем (с учетом возможностей каждой модели конечно.)
                А вот смешанная нагрузка — например, когда одновременно идет рандомное чтение и потоковая запись — противопоказана. Особенно на младших моделях, таких как протестированный E2700.
                  0
                  У вас в описании «Методики тестирования», в п.6 опечатка, видимо.
                  Последовательная запись/чтение блоками маленького размера (4 КБ, например), не имеет практической пользы?
                    0
                    Так вообще мало кто пишет в real-life. Навскидку приходит в голову только redo-log базы данных, но, обычно, если я правильно помню, он там аггрегируется на уровне приложения в более крупные блоки, а вообще сейчас, если нужна высокая производительность на последовательной записи, надо смотреть на All-Flash системы.
                      0
                      Я бы вообще сказал, что если интересует СХД не с целью хранить редко используемую информацию, то нет причин смотреть на механические диски вообще. У кого нет в линейке all-flash СХД, те пытаются продавать классические СХД, набитые только SSD-дисками, причем текущий уровень скидок дает повод предположить, что просели продажи как СХД на механических дисках, так и СХД вообще. Известный вендор из трех букв недавно предлагал скидку в районе 50% от розничной цены и был очень расстроен, что мы предпочли не их решение…
                        0
                        Я бы вообще сказал, что если интересует СХД не с целью хранить редко используемую информацию, то нет причин смотреть на механические диски вообще.

                        Если у вас количество денег стремится к бесконечности, или вы их добываете в негораниченном количестве из недр воздуха — безусловно так. Увы, на рынке теперь считают деньги, и сверхприбыли это скорее исключение, чем повседневность.

                        причем текущий уровень скидок дает повод предположить, что просели продажи как СХД на механических дисках, так и СХД вообще.

                        Ежегодные отчеты IDC с вами не согласны, хотя, конечно, сумасшедших покупателей на рынке все меньше, и они все тщательнее считают, что они получат за свои деньги.

                        Известный вендор из трех букв недавно предлагал скидку в районе 50% от розничной цены

                        Вы правда считаете, что 50% от листпрайса — это большая скидка? 45% это стандартная скидка для топового партнера, и это значит, что от нее еще только начинаются индивидуальная скидка на хороший/нужный проект. Лично видел скидку в 75%, и это не на какие-то суперпупер системы, а на вполне себе серийную модель.
                          0
                          Если у вас количество денег стремится к бесконечности, или вы их добываете в негораниченном количестве из недр воздуха — безусловно так. Увы, на рынке теперь считают деньги, и сверхприбыли это скорее исключение, чем повседневность.

                          Я очень сочувствую тем, у кого нет денег на all-flash СХД, они еще пожалеют о том, что сэкономили. Ну, конечно, если у них не архив советских фильмов времен начала перестройки на этой СХД лежать будет.
                          Ежегодные отчеты IDC с вами не согласны, хотя, конечно, сумасшедших покупателей на рынке все меньше, и они все тщательнее считают, что они получат за свои деньги.

                          У нас уже есть 3 mid-range СХД и перед покупкой еще одной мы протестировали модели из текущих линеек 4 ведущих игроков на рынке. И решили, что четвертый раз мы в это наступать не будем.
                          Лично видел скидку в 75%, и это не на какие-то суперпупер системы, а на вполне себе серийную модель.

                          Вы продаете или покупаете? Если продаете — можем поговорить о сотрудничестве.
                            0
                            Я очень сочувствую тем, у кого нет денег на all-flash СХД

                            Ну людям, которые знают, как оптимально тратить деньги не надо сочувствовать.
                            Топить печь долларовыми банкнотами может и круто (горят хорошо, жарко), но не особо продуктивно.
                            Есть отдельные области, где all-flash нужен, это бесспорно. Это примерно несколько процентов, сомневаюсь что больше 10. Есть остальные области, где выгоды от него не окупают вложений. Грамотный архитектор это все понимает, и не топит печь баксами, даже если они и хорошо горят.
                            Класть на flash логи базы — разумно, так как это напрямую влияет на общую производительность. Класть на нее cold data, которые составляют 80-90% объема данных — неразумно, так как им все равно на чем лежать, хоть на SATA.

                            Вообще говоря, я убежден, что для массового потребителя, который не NASDAQ и не NYSE, оптималны к использованию системы кэширования во flash, типа NetApp VST (Flash Cache и Flash Pool), а вовсе не кранилища в нем. Результат «на вложенный доллар» — оптимален.
                              0
                              промазал, ниже ответил
                    0
                    Класть на flash логи базы — разумно, так как это напрямую влияет на общую производительность. Класть на нее cold data, которые составляют 80-90% объема данных — неразумно, так как им все равно на чем лежать, хоть на SATA.

                    Это надо понимать так, что во всех на свете базах cold data — 80-90%? Я, наверное, не самый грамотный архитектор, но мне важнее, что некоторые бизнес-процессы теперь вместо дней занимают десятки минут, а аналитики не мешают онлайну (да, я знаю, что принято разделять аналитику и онлайн, но тут уже от нас, как конечных пользователей, мало что зависит).
                      +1
                      Это надо понимать так, что во всех на свете базах 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/
                        0
                        Вы не поняли, я знаю, какой у меня процент 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 минут на новом.
                          0
                          Да, и кстати, кроме RamSan/IBM и Violin/HP есть и другие производители all-flash СХД. И цены у них значительно интереснее.
                            +1
                            Вы не поняли, я знаю, какой у меня процент 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-х, времен третьего Пентиума вроде? :)
                              0
                              И какой он у вас? Просто интересно.

                              Около 40%.
                              FAS2240-2 это самая младшая система линейки, это, фактически entry level

                              Вы правда считаете, что по каждой закупке весь список оборудования я сам выбираю? Менеджер NetApp по нашим характеристикам нагрузки посоветовал эту модель, мы убедились, что это лажа, выбрали другого вендора. Нам пофигу, нас выбранный вариант устраивает, NetApp остался без денег.
                              EVA4400 и Sun M4000- это даже не смешно. Это ж какие-то системы из начала 2000-х

                              Вы правда думаете, что такие железки покупаются на 2-3 года, а потом — в утиль? Посмотрите сколько стоит аналогичная текущая линейка железа у Оракла, а их не 1 штука закупается, еще горячая замена, тестовые базы и т.д.
                                0
                                Вы правда думаете, что такие железки покупаются на 2-3 года, а потом — в утиль?

                                Я правда думаю, что система семилетней давности, не только не продающаяся, но уже даже End Of Life, не может считаться показательной и сравнения с ней не могут приводится в качестве доказательства преимущества.

                                Вы берете дисковую систему семилетней давности, и сервер уже несуществующей компании примерно того же возраста, и сравниваете их, нет, не с современной дисковой системой, и современным же сервером. Кто бы удивлялся, что выигрыш будет большой. Но вот будет ли он настолько большой при сравнении с современными дисковыми системами? Вот тут у меня обоснованные сомнения.

                                Менеджер NetApp по нашим характеристикам нагрузки посоветовал эту модель, мы убедились, что это лажа,

                                Настраивали — сами, или помогал кто знающий?
                                  0
                                  Мы сравнивали в т.ч. с HP 3Par 7200, EMC VNX5200, да, они побыстрее, чем Eva, но даже не вдвое при сравнимом количестве дисков, раза в полтора от силы. NetApp настраивал их специалист, визитка вот под рукой лежит, почти целый день у нас просидел…
                                    +1
                                    Мы сравнивали в т.ч. с HP 3Par 7200, EMC VNX5200

                                    Ну так про это и речь. Вы сравнили MSA2040 с EVA6500 и предсказуемо выяснили, что entry-level система с вдвое более слабыми процессорами, с в два раза меньшей емкостью кэша и вдвое дешевле по цене работает медленнее. Ну, ОК, тоже мне научное открытие :)
                                      0
                                      Вы сравнили MSA2040 с EVA6500
                                      не перевирайте мои слова.
                                        +1
                                        Я просто объясняю разницу между NetApp FAS2240-2 и EMC VNX5200 и HP 3Par 7200. Она вот такая. Первое это entry-level трехлетней давности линейки со своим уровнем производительности и ограничениями, а вторые два — мидрендж из новейших линеек.

                      Only users with full accounts can post comments. Log in, please.