IBM Storwize V7000 + Real-time Compression. 1C SQL, Exchange

[gs]

ССД дадут гарантированный эффект, а вот всякие навороты где-то лечат, а где-то калечат. Потому их (наворотов) использование имеет смысл, если лобовой метод неэффективен или дорог.

[gs]

Во время иракской войны слышал по телеку одну историю (возможно байка конечно).
Американцы сбросили на главную иракскую телевышку супертехнологичную электромагнитную бомбу весом несколько тонн. Башня вырубилась на сутки, пока иракцы не притащили ЗИП.
Журналист задался вопросом - а как быстро восстановилось бы вещание после падения обычной бомбы такого калибра?

[gs]

Может и вообще V3700 с турбокнопкой хватило бы...

[AlexZ]

А если так поставить задачу. Синтетический тест. СХД SW V7000
Условия.
1. СХД ничем не загружена.
2. Воображаемые тестовые тома созданы на SSD IO группе.

Последовательное (случайное) чтение файла базы данных в 40Гб (размер блока, к примеру, классические 8кб), расположенного на
а. обычном томе.
б. на томе с компрессией.

Что будет быстрее? На сколько (ваши прогнозы)? Обоснуйте почему? Может кто-то проводил такой эксперимент?

[KLIM_SPb]

Том с компрессией будет быстрее, т.к. сжатие происходит на лету. Следовательно вы меньший объем пишите и читаете с дисков. НО для такой маленькой базы смысла в компрессии нет. Т.к. лицензия стоит денег, на объеме хранения вы не сэкономите, особого прироста производительности не будет.
Если очень нужно очень быструю хранилку, то Flash Storage.

[gs]

Уфф!
Вам "быстрее" или чтобы задача решалась?
8 SSD'шек с большой вероятностью загрузят контроллер по самые уши и без всякой компрессии. Но остается вопрос, о котором Вы почему-то не хотите думать - а куда девать все эти иопсы? У Вас всего лишь три сервера - пусть не самых слабых, но это далеко не целевая аудитория для стораджей такого масштаба...

[AlexZ]

У нас есть такие производственные задачи, когда явно видно, что дисковая система не способна отдать больше, чем может переработать процессор.
У меня была на тесте SW3700. В ней было два SSD диска по 200Гб, объединенных в зеркало, и восемь HDD 600Гб 10К. На обейх io группах былы созданы обычные (generic) тома.

На линейном чтении блоками 4к
SSD 40Мб (10000 iops)
HDD (R10 8 дисков) 41Мб
HDD (R5 8 дисков) 43Мб
HDD (R0 8 дисков) 40Мб
Текущая продакшн система HDD (RS2BL080 R10 8 дисков) 80Мб

На случайном чтении блоками 4к
SSD (stroke 137Gb) 2500 iops
HDD (R10 8 дисков) (stroke 550Gb) 175 iops
HDD (R5 8 дисков) (stroke 550Gb) 178-5500 iops
HDD (R0 8 дисков) (stroke 550Gb) 180 iops
Текущая продакшн система HDD (RS2BL080 R10 8 дисков)
(stroke 512Gb) 178 iops, (stroke 40Gb) 203 iops, (stroke 1Gb) 242 iops

ВЫВОД: в ряде задач, где важна скорость последовательного чтения, мы ощутим деградацию производительности, даже используя SSD накопители.

Обьясните, почему на синтетических однопоточных тестах хранилки выдают гораздо меньший результат, чем классические raid-контроллеры с тем же массивом дисков?

[AlexZ]

Уфф!
Вам "быстрее" или чтобы задача решалась?
8 SSD'шек с большой вероятностью загрузят контроллер по самые уши и без всякой компрессии. Но остается вопрос, о котором Вы почему-то не хотите думать - а куда девать все эти иопсы? У Вас всего лишь три сервера - пусть не самых слабых, но это далеко не целевая аудитория для стораджей такого масштаба...

желательно, чтобы после покупки хранилища, задачи решались не дольше, чем сейчас, а желательно быстрее.

[AlexZ]

Еще проще.
SW3700 + Сервер.
База данных лежит на хранилке.
Расчет себестоимости занимает в полтора раза больше времени в сравнении с вариантом, когда таже база данных лежит на локальных дисках того же сервера.

[gs]

Я не очень понял что и чем Вы мерили. И зачем. Ибо 200 иопс - это рандом перфоманс одного сас винта.
В общем, все приведенные цифры совершенно не актуальны для реальной задачи.

Для линейного чтения ССД вообще-то без надобности, винты читают тоже очень быстро.
Кстати при линейной записи система с компрессией явно будет в пролете.

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

[Stranger03]

Обьясните, почему на синтетических однопоточных тестах хранилки выдают гораздо меньший результат, чем классические raid-контроллеры с тем же массивом дисков?

Потому что в отличие от обычных РАИД-контроллеров массивы тратят свои ресурсы для синхронизации контроллеров и прочих внутренних задач. Впрочем, если вы возьмете ту же IBM FlashSystem, то нагрузки на систему вы не ощутите совсем. Ибо она выдает столько иопсов, что переварить не сможет почти ни один современный сервер.

[Stranger03]

Еще проще.
SW3700 + Сервер.
База данных лежит на хранилке.
Расчет себестоимости занимает в полтора раза больше времени в сравнении с вариантом, когда таже база данных лежит на локальных дисках того же сервера.

При одинаковом кол-ве дисков так и будет. Поставьте в 3700 48-мь САС в 10-ку, тогда будет ощутимо.

[AlexZ]

Я не очень понял что и чем Вы мерили. И зачем. Ибо 200 иопс - это рандом перфоманс одного сас винта.
В общем, все приведенные цифры совершенно не актуальны для реальной задачи.

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

Каким образом заставить её работать быстрее?
Первый вариант, как я понял, увеличить количество шпинделей.
Есть другие?

[gs]

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


Правда остается вопрос - не было ли косяков при настройке системы...

[gs]

Есть еще FC адаптеры с бортовым кэшем - правда вопрос компатибилити еще...