Как стать автором
Обновить

Комментарии 10

Ребят, если вы хотите кого-то тут заинтересовать, то писать надо по делу, а не тупые слоганы вешать.

Производительность? IOPS/Gb?
Latency?
Уровень избыточности?
Цена за Гб и за IOPS?

Пока всё написанное сильно напоминает убогую рекламу всяких «one button backup» на usb-sata дисках.
В будущем постараемся сделать статью про конкретную реализацию для проекта с цифрами на базе конкретных массивов.
Fluid Data — это просто концепция и идея, которая воплощается в различных решениях (equallogic, Compellent, NX, DX, FS и т.п. устройствах), на базе различных аппаратных и программных платформ. Т.е. статья — про идею, которая имеет различные реализации, а не про конкретное решение.
«Производительность? IOPS/Gb?
Latency?
Уровень избыточности?
Цена за Гб и за IOPS?»
Вопросы не несущие под собой никакого смысла без понимания характера нагрузки, объемов, требований, условий эксплуатации и многого другого.

Производительность в «тяжелых» решениях переваливает за 100K IOPS в зависимости от нагрузки (размер блока, % кэшхита, соотношение чтение/запись, наличие мирроринга, тип RAID, и т.д.).
Latency при 100% кэшхите — 3 милисекунды
Цена от 10K USD до 2,5M USD за массив

Как вы наверняка поняли, вопросы должны быть предметными, типа сколько IOPs и какая Latency будет в такой конфигурации, при таком типе нагрузки. Сколько это стоит и т.п.
Это мы постараемся осветить позднее, на примере конкретных реализаций.
Можно уточнить про «переваливает за»? Лично мне было бы интересно посмотреть на конфиг, который в разумный ценник способен дать что-то порядка 500 IOPS/Tb при latency <2мс.
Еще раз. Latency менее 2 мс — что кэшхит, т.к. даже SSD в сетевых устройствах дает latency ~4мс.
практически любой массив любого производителя легко будет давать вам и 10000 IOPS при Latency <2 мс, если вы будете грузить его нагрузкой со 100% кэшхитом.
При 100% рандоме (что так же в реальности встречается совсем редко) каждый шпиндель SATA будет давать порядка 120 IOPS, SAS/FC c дисками 15К — порядка 200 IOPS со шпинделя. Т.е. какого бы класса вы массив не купили — при 100% рандоме и 10HDD SAS15K больше 2000-2200 IOPS вы с него не снимете.

В отрасли все производители, как правило, оперируют параметром — сколько IOPS даст массив при Latency <30мс, и при таких условиях 100000 IOPS — это очень большой показатель.

Давайте так. скачайте с сайта Dell бесплатную утилиту DPACK. Она собирает статистику о том, какой ввод-вывод на вашей СХД, какими блоками, сколько кэшхитов, соотношение чтения-записи и т.п. Все безопасно и никакие ваши данные трогаться не будут.
Скачать можно тут:
content.dell.com/us/en/business/d/campaigns/dpack-downloads.aspx
Там же есть описание как инсталлировать и настраивать. Соберите отчет хотя бы за 4 часа, лучше за день и пришлите мне — mvorobyev (собака) dell.com — и мы предложим вам вариант который подойдет под вашу нагрузку с любым запасом по емкости или производительности под ваши нужды.
А можно просто исполняемый файл? Что я с этим VMware-Player-4.0.2-591240.i386.bundle делать должен?

По моим попугаям (fio по диску с размером 2Тб, 16 потоков на чтение, 16 на запись (независимо), random 4k) для одиночной виртуалки я получаю вот такое:

read: (groupid=0, jobs=1): err= 0: pid=25763
  read : io=1038MB, bw=16037KB/s, iops=4009, runt= 66306msec
    slat (usec): min=3, max=816, avg= 8.91, stdev=11.64
    clat (usec): min=37, max=287122, avg=3978.01, stdev=5858.45
    bw (KB/s) : min= 2784, max=23536, per=100.13%, avg=16057.19, stdev=3993.55
  cpu          : usr=1.92%, sys=5.53%, ctx=144550, majf=0, minf=136
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued r/w: total=265831/0, short=0/0
     lat (usec): 50=0.01%, 100=0.02%, 250=0.12%, 500=0.39%, 750=1.42%
     lat (usec): 1000=5.71%
     lat (msec): 2=38.96%, 4=28.63%, 10=14.20%, 20=9.71%, 50=0.69%
     lat (msec): 100=0.05%, 250=0.10%, 500=0.01%
write: (groupid=0, jobs=1): err= 0: pid=25765
  write: io=1426MB, bw=22025KB/s, iops=5506, runt= 66294msec
    slat (usec): min=3, max=907, avg= 8.99, stdev=14.87
    clat (usec): min=142, max=156462, avg=2892.95, stdev=3655.73
    bw (KB/s) : min= 6352, max=29728, per=100.24%, avg=22077.33, stdev=3797.21
  cpu          : usr=2.06%, sys=6.96%, ctx=174691, majf=0, minf=125
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued r/w: total=0/365032, short=0/0
     lat (usec): 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.14%
     lat (msec): 2=21.66%, 4=69.79%, 10=7.56%, 20=0.57%, 50=0.16%
     lat (msec): 100=0.03%, 250=0.08%


И да, мы используем flashcache для кеширования. Разумеется, там latency будет ниже, чем у магнитных дисков.

ЗЫ Если найдёте что-то приемлимое для запуска (linux x86/64), обращайтесь, будем смотреть и сравнивать.
ПО ссылке выше (content.dell.com/us/en/business/d/campaigns/dpack-downloads.aspx) вторая ссылка — клиент под линукс. :)
Вот конкретная ссылка на него
www.dell.com/support/drivers/us/en/555/DriverDetails?DriverId=5XF67
С его статистикой и репортом проще работать, чем руками эмулировать вашу нагрузку
ЗЫ каким образом SSD может дать latency больше 4мс, если запись занимает менее 1мс, а сетевой пинг 0.1мс? Про чтение с SSD можно и не говорить, надеюсь и так понятно.
Достаточно очереди переполнить :)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий