Не все High end массивы одинаково полезны …...• DS8000 –...
Transcript of Не все 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
Disk total KB/s IBMPART2_daily_fnmon - 05/12/2012
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
Disk Read KB/s Disk Write KB/s IO/sec
Disk total KB/s IBMPART1_daily_fnmon - 05/12/2012
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
Disk Read KB/s Disk Write KB/s IO/sec
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
Dec 08, 2012 interval i/o MB/sec bytes read resp resp resp
rate 1024**2 i/o pct time max stddev
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
Dec 08, 2012 interval i/o MB/sec bytes read resp resp resp
rate 1024**2 i/o pct time max stddev
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
Dec 04, 2012 interval i/o MB/sec bytes read resp resp resp
rate 1024**2 i/o pct time max stddev
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
Dec 04, 2012 interval i/o MB/sec bytes read resp resp resp
rate 1024**2 i/o pct time max stddev
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 в России и СНГ