15 Май 2013

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

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

Расскажу про проведенное сравнение систем хранения данных на реальной задаче.

Один из интеграторов предлагал в проект IBM Storwize v7000, мы предлагали систему NetApp FAS 3240A.
Заказчик решил проверить обе системы на реальной нагрузке, выделить своих специалистов для настройки прикладного ПО на площадках обоих интеграторов, чтобы гарантировать идентичность настроек.
Нагрузка была выбрана такая, с которой текущая система заказчика справлялась плохо. Тестирование заключалось в размещении на СХД базы данных заказчика объемом около 180 Гигабайт и выполнении в ней скрипта, который проводил 140000 транзакций с реальными данными, сильно нагружающих дисковую подсистему. Затем полученные данные аппроксимировались до значения – количество транзакций в час.

Раунд 1:

Конфигурация интегратора 1:
Сервер – IBM x3050X5, 4 x процессора Intel Xeon 4870 2,4GHz, 512GB RAM, 2 x интерфейса FC 8G
IBM Storwize v7000 (24 диска 600GB 10k) RAID 10, 1 LUN – конфигурация ориентировочная, потому что так и не сознались до конца что там было :)
Время которое понадобилось на настройку неизвестно.

минимальное время исполнения скрипта – 840 секунд (600000 транзакций в час)

Наша конфигурация:

Сервер – Fujitsu RX600, 4 x процессора Intel Xeon 7550 2,0GHz, 256GB RAM, 2 x интерфейса FC 4G
NetApp FAS 3210 (1 контроллер, 24 диска 450GB 15k) RAID-DP (21+2), 1 LUN
На настройку понадобилось около 40 минут, из них большую часть времени ставился Linux на сервер.

минимальное время исполнения скрипта – 315 секунд (1600000 транзакций в час)

Преимущество очевидно, к тому же заказчику предлагалась не FAS 3210, а FAS 3240 которая существенно быстрее.

Далее началось интересное, интегратор 1 вместе с IBM попросил матч-реванш :)
Мотивируя это тем, что настройки и сайзинг были проведены некорректно…
Ну нам то что, хоть 10 раз. К тому же в лабораторию приехала система FAS 3240 c FlashCache.

Раунд 2:

Конфигурация интегратора 1:
Сервер – IBM x3050X5, 4 x процессора Intel E7 4870 2,4GHz, 512GB RAM, 2 x интерфейса FC 8G
IBM Storwize v7000 (48 дисков 600GB 10k) RAID 0, 1 LUN
На настройку и тестирование понадобилось больше 2х дней с участием инженеров из IBM, судя по затраченному времени, пришлось прибегнуть к помощи магии и какой-то матери. RAID0 это вообще за гранью добра и зла :)

минимальное время исполнения скрипта – 240 секунд (2100000 транзакций в час)

существенно лучше чем было, правда такую конфигурацию нельзя в продуктиве использовать…

Наша конфигурация:

Сервер – HP DL980, 4 x процессора Intel E7 2860 2,26GHz, 128GB RAM, 2 x интерфейса FC 4G
NetApp FAS 3240A (512GB FlashCache, 39 дисков 600GB 10k) 2хRAID-DP (19+2)+(19+2), 1 LUN.
На настройку понадобилось около 50 минут, включая установку СХД в стойку и настройку Linux на сервере.

минимальное время исполнения скрипта – 153 секунды (~3300000 транзакций в час). Уперлись в процессоры сервера, в пике загрузка системы хранения не превысила 50%

Поменяв сервер, можно было бы еще улучшить результат.

Преимущество систем NetApp было очевидным. И прогнозируемым, т.к. скрипт генерировал поток транзакций с Commit в конце, получалась случайная запись по всему объему базы данных крайне неприятная для любой СХД кроме NetApp.