Не все high end массивы одинаково полезны …...• ds8000 –...

Кирилл Гудков, технический специалист отдела систем хранения данных IBM в России и СНГ

Не все High-end массивы одинаково

полезны - разбор одного

нагрузочного тестирования

Зачем тестироваться?

• Disk Magic и похожие средства позволяют

моделировать нагрузки на СХД согласно

заданным параметрам

• Часто нужна проверка работы комплекса с

профилем нагрузки конкретного ПО

• Типы тестирований:

– PoC – Proof of concept

– Benchmarking – нагрузочное тестирование

Важные аспекты при подготовке

тестирования

• Определение целей и задач тестирование

• Формирование команды, включая

специалистов заказчика по ОС и СУБД

• Подготовка тестового примера однозначно

интерпретируемого

• Подготовка и проверка способа генерации

нагрузки (наиболее популярные – HP

LoadRunner и Oracle RAT)

• Четкое планирование этапов и сроков

Задачи тестирования для одного

заказчика

• Проверить работу СХД под несколько

разноплановых задач, которые будут

выполняться одновременно (OLTP, отчеты,

резервное копирование)

• Проверить эффективность механизма

автоматического переноса горячих блоков

(EasyTier = ET)

• Проверить эффективность QoS СХД

• Подготовить отчет по проведенным тестам и

их результатам

Схема тестового стенда

21

System Storage

21

System Storage

MGMT

SERVICE

Active CP

USB

MGMT

SERVICE

Active CP

USB

20 * 8GB 32 * 8GB

IBM Power P795

4 partitions

11 Cores 32 GB RAM

Brocade Switch

IBM Storage DS8870352 DDM 15k 300GB

32 DDM SSD 400GB

8 Fiberchannels cards 8 ports 8GB/s

352DDM/8=44 RANK

Особенности тестовой конфигурации

• КЭШ СХД 1ТБ

• КЭШ СХД 256 ГБ

• Испытаны следующии конфигурации и

технологии:

– Общие пулы для всех типов нагрузки

– EasyTier (ET)

– IO Priority Manager (QoS)

IO priority manager • Тестировалось влияние IO priority manager для

управления нагрузкой с 3 AIX LPAR (Все LPAR c 4

hdisk (в пулах СХД 300ГБ x15K)

• Нагрузка для LPAR генировалась Vdbench с

одинаковым профилем

• Vdbench стартовал последовательно с 2 мин

интервалом для LPAR

• QoS применялся одновременно для всех томов

• Измерения проводились на каждом LPAR и на уровне

физических дисков СХД

• Профиль нагрузки:

– 80/20 с блоком 16К/8К с горячей областью 1 ТБ из 5 ТБ тома

Disk total KB/s IBMPART3_daily_fnmon - 05/12/2012

0

100

200

300

400

500

600

700

800

900

1000

16:3

0

16:3

5

16:4

0

16:4

5

16:5

0

16:5

5

17:0

0

17:0

5

17:1

0

Th

ou

san

ds

KB

/sec

0

10000

20000

30000

40000

50000

60000

70000

IO/s

ec

Disk Read KB/s Disk Write KB/s IO/sec

Изменение Параметров

IO priority manager


0

100

200

300

400

500

600

16:3

0

16:3

5

16:4

0

16:4

5

16:5

0

16:5

5

17:0

0

17:0

5

17:1

0

Th

ou

san

ds

KB

/sec

0

5000

10000

15000

20000

25000

30000

35000

40000

IO/s

ec



0

100

200

300

400

500

600

700

800

16:3

0

16:3

5

16:4

0

16:4

5

16:5

0

16:5

5

17:0

0

17:0

5

17:1

0

Th

ou

san

ds

KB

/sec

0

10000

20000

30000

40000

50000

60000

IO/s

ec


Easy Tier • Тестировалось использование технологии IBM Easy Tier

при разнородных нагрузках

• Измерялась производительность по 3-м разным

профилям нагрузки в 3 LPAR

• Данные были размещены на 60% дисков СХД (1 ТБ кэш)

• Проанализирован HeatMap

• Нагрузка генерировалась инструментом vdbench cо

следующими профилями:

1. OLTP профиль 70/30 c блоком16K/8K

2. Эмуляция работы аналитических приложений 95/5 c блоком 16K/8K

3. Эмуляция нагрузки при создании резервной копии

БД 100% запись с блоком 1МБ

Heat MAP(Карта распределение горячих областей томов СХД)

Эффективность ET для OLTP – на 30% (28 RANK) меньшем

количестве дисков результаты близки по IOPS к 44 RANK

09:54:35.013 Starting RD=run1; I/O rate: 250000; elapsed=2700; For loops: seekpct=100.0

Dec 13, 2012 interval i/o MB/sec bytes read resp resp resp

rate 1024**2 i/o pct time max stddev

10:39:35.266 avg_2-540 97932.92 1377.20 14745.00 80.00 5.02 1397.61 7.18

Синий график

указывает на

случайный тип

нагрузки

Красный – на

Перенос горячих

областей на SSD

1ТБ vs 256 ГБ кэша СХД 11:50:49.012 Starting RD=run1; I/O rate: 25000; elapsed=1200; For loops: iorate=25000 seekpct=100.0



12:10:49.374 avg_2-240 25002.39 351.59 14745 80.00 1.593 295.296 2.272

12:10:51.012 Starting RD=run1; I/O rate: 100000; elapsed=1200; For loops: iorate=100000 seekpct=100.0



12:30:51.230 avg_2-240 99981.60 1406.01 14745 80.00 2.478 353.539 3.898

==============================================================

14:31:05.015 Starting RD=run1; I/O rate: 25000; elapsed=1200; For loops: iorate=25000 seekpct=100.0



14:51:05.304 avg_2-240 24995.38 351.50 14745 80.00 2.388 293.562 2.833

14:51:07.011 Starting RD=run1; I/O rate: 100000; elapsed=1200; For loops: iorate=100000 seekpct=100



15:11:07.384 avg_2-240 97643.64 1373.14 14745 80.00 5.126 421.780 4.815

Выводы по результатам

тестирования • 1 ТБ кэш памяти позволяет сэкономит 1 – 3

мсек времени отклика (эффективный

алгоритм управления кэш памятью СХД)

• ЕТ эффективен и в некоторых случаях

позволяет уменьшить footprint

• IO priority manager – быстр, прост

эффективен

• DS8000 – мощный и надежный массив!!!

Спасибо! Кирилл Гудков, технический специалист отдела систем

хранения данных IBM в России и СНГ

Не все high end массивы одинаково полезны …...• ds8000 –...

Documents