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.

9 Март 2012

Сравнение систем хранения данных

storwizeЕсть такой сайт http://www.storageperformance.org, где проводят независимое тестирование систем хранения данных. Я периодически им пользуюсь для того, чтобы понять, как та или иная система хранения ведет себя в реальности и сколько в состоянии выдать IOPS. Тест называется SPC-1, симулирует OLTP-подобную нагрузку.

SPC Benchmark 1 (SPC-1)
SPC-1 consists of a single workload designed to demonstrate the performance of a storage subsystem while performing the typical functions of business critical applications. Those applications are characterized by predominately random I/O operations and require both queries as well as update operations. Examples of those types of applications include OLTP, database operations, and mail server implementations.

Но сравниваю я не абсолютный показатель (сколько IOPS система выдала максимально), а относительный – сколько IOPS приходится на 1 диск. Данное значение, по моему мнению, характеризует эффективность работы всей системы в целом, т.к. производители стремятся предоставить максимально сбалансированную конфигурацию (все хотят высокий результат).

Вот таблица сравнения (здесь представлены только системы прошедшие тест последней версии SPC-1 v1.12)

Name IOPS Drives IOPS per drive Drive type SSD cache, Gb RAID type $/IOPS
TEXAS MEMORY SYSTEMS RAMSAN-630 400503,26 20 20025,16 SSD RAID5 $1.05
HUAWEI SYMANTEC OCEANSPACETM DORADO2100 100051,99 24 4168,83 SSD RAID10 $0.90
HP P6500 ENTERPRISE VIRTUAL ARRAY 20003,03 8 2500,38 SSD RAID10 $6.55
HP STORAGEWORKS 6400 ENTERPRISE VIRTUAL ARRAY 16741,16 8 2092,65 SSD RAID10 $7.28
NETAPP FAS3270A 68034,63 120 566,96 SAS 15k 1024,00 RAIDDP $7.48
ORACLE SUN ZFS STORAGE 7420C APPLIANCE 137066,2 280 489,52 SAS 15k 4680,00 RAID10 $2.99
HUAWEI SYMANTEC OCEANSPACETM S6800T 150061,17 368 407,77 SAS 15k RAID10 $3.08
HUAWEI SYMANTEC OCEANSPACETM S5600T 102471,66 252 406,63 SAS 15k RAID10 $2.73
XIOTECH EMPRISETM 5000 8102,46 20 405,12 SAS 15k RAID10 $5.08
HUAWEI SYMANTEC OCEANSPACE S2600 16995,54 48 354,07 SAS 15k RAID10
XIOTECH EMPRISETM 5000 6962,4 20 348,12 FC 15k RAID10 $3.05
IBM SYSTEM STORAGE DS8700 RELEASE 5.1 32998,24 96 343,73 SATA 7.2k 2336,00 RAID10 $47.92
XIOTECH EMPRISETM 5000 12603,65 40 315,09 SAS 10k RAID10 $6.70
IBM SYSTEM STORAGE® DS3524 EXPRESS 14797,26 48 308,28 SAS 10k RAID10 $3.26
XIOTECH EMPRISETM 5000 6065,96 20 303,30 FC 15k RAID10 $9.55
FUJITSU STORAGE SYSTEMS ETERNUS DX80 S2 34995,02 117 299,10 SAS 15k RAID10 $2.25
HUAWEI SYMANTEC OCEANSPACETM S8100 (4-NODE) 160057,09 576 277,88 FC 15k RAID10
IBM SYSTEM STORAGE SAN VOLUME CONTROLLER V6.2 WITH IBM STORWIZE® V7000 DISK STORAGE 520043,99 1920 270,86 SAS 15k RAID10 $6.92
HUAWEI SYMANTEC OCEANSPACETM S8100 (8-NODE) 300062,04 1152 260,47 FC 15k RAID10
HUAWEI SYMANTEC OCEANSPACE S5600 34002,2 132 257,59 FC 15k RAID10
SGI® INFINITESTORAGE 5000-SP 24555,54 96 255,79 SAS 10k RAID10 $3.61
IBM SYSTEM STORAGE® DS3524 EXPRESS TURBO 24449,27 96 254,68 SAS 10k RAID10 $3.90
SUN STORAGE 6780 ARRAY (8 GB) 62261,8 256 243,21 FC 15k RAID10 $6.89
IBM STORWIZE® V7000 DUAL 56510,85 240 235,46 SAS 15k, FC 15k RAID10 $7.24
INFORTREND ESVA F60 180488,53 768 235,01 SAS 15k RAID10 $5.12
HP P10000 3PAR V800 STORAGE SYSTEM 450212,66 1920 234,49 FC 15k RAID10 $6.59
FUJITSU STORAGE SYSTEMS ETERNUS DX440 97498,25 416 234,37 SAS 15k RAID10 $5.51
HITACHI VIRTUAL STORAGE PLATFORM (VSP) 269506,69 1152 233,95 SAS 15k RAID10 $8.18
PILLAR AXIOM 600 SERIES 3 70102,27 312 224,69 SAS 15k RAID10 $7.32
IBM STORWIZE® V7000 53014,29 240 220,89 SAS 10k RAID10 $7.52
FUJITSU STORAGE SYSTEMS ETERNUS DX8400 171736,84 912 188,31 SAS 15k RAID10 $8.39

Итак что мы видим:

  • SSD эффективны если их правильно использовать (не как диски), если нужна выделенная СХД под базу данных до 10-15Тб, то специализированная SSD СХД – лучший выбор
  • рекорды в абсолютных цифрах, практически всегда означают лишь большое количество дисков в системе
  • использование SSD в качестве кеш-памяти, сильно увеличивает эффективность использования дисков
  • в тестах только 2 системы НЕ используют RAID10 (это TMS RAMSAN-630 и NetApp FAS3270A) и обе являются лидерами по эффективности

Стоит помнить, что характер нагрузки в тесте, может кардинально отличаться от характера нагрузки в вашей системе. Но эффективность использования дисков будет более/менее коррелировать с тестами, подтверждено на практике.

Подробности можете почитать на сайте Storage Performance Council
http://www.storageperformance.org/results/benchmark_results_spc1

12 Февраль 2012

Не верь глазам своим

Был недавно на семинаре про IBM Storwize v7000, очень понравилось, докладчик был в теме и бодро отвечал на вопросы, респект ему.
Речь зашла о Thin-provisioned volumes и я вспомнил, что в случае использования этого типа томов, в документации есть упоминание о влиянии на производительность. В ответ на мою ремарку, докладчик заверил меня, что ничего подобного там нет и все замечательно. Я пообещал прислать ссылку на документ и номер страницы… с этого все и началось.

Читаем документ Implementing the IBM Storwize V7000 6.3, дата публикации 07.02.2012
http://www.redbooks.ibm.com/abstracts/sg247938.html
Глава 1.5.10 Thin-provisioned volumes. Страница 24 (42 в pdf)

v7000_new

и правда, никаких упоминаний… ну думаю приснилось, начинаю писать письмо докладчику семинара, о том что он был прав, а я неправ и посыпать голову пеплом.
Но тут приходит мысль: я то читал документацию в старой редакции, может просто вырезали???

Нашел первую версию документа от декабря 2010 года
http://www.scribd.com/doc/46884001/Sg247938-Implementing-the-IBM-Storwize-V7000#outer_page_40
Глава 1.4.9 Thin-provisioned volumes. Страница 22 (40 в pdf)

v7000_old

Вот и текст о котором я говорил на семинаре:
(далее перевод блока в сером прямоугольнике)

Примечание:
Thin-provisioned volumes требуют дополнительных операций ввода/вывода для чтения и записи метаданных на внутренние диски или внешний дисковый массив, которые также будут вносить дополнительную нагрузку на узлы IBM Storwize V7000. Поэтому мы не рекомендуем использовать этот вид томов для высокопроизводительных приложений, или любых нагрузок с большим числом I/O операций записи.

Ну ладно, в начале 2011 года, документ был в статусе Draft и должен был быть отредактирован, возможно в указанном блоке приведена непроверенная информация.

Версия май 2011, текст присутствует
http://www.scribd.com/priyank_saxena_1/d/62006953-sg247938#outer_page_43

Значит это не ошибка, текст был до недавнего времени, прошел несколько редакций и он соответствует действительности.
Возможно дело в версиях системного ПО?
Может быть в версии системного ПО 6.3 (последняя версия документа) полностью переписали механизм работы тонких дисков, по сравнению с 6.1?

Смотрим release notes версий 6.1-6.3

http://download4.boulder.ibm.com/sar/CMA/SDA/02oke/1/V7000_61010_release_note.txt
ftp://ftp.hddtech.ibm.com/san/sanvc/V6.1.0.2/release_note/V7000_6102_release_note.txt
http://delivery04.dhe.ibm.com/sar/CMA/SDA/02usd/1/V7000_6204_release_note.txt
http://delivery04.dhe.ibm.com/sar/CMA/SDA/02z3z/0/V7000_6301_release_note.txt

никаких упоминаний о переписанном механизме Thin-provisioned volumes.
Получается, что вырезали упоминание о существенной технической детали, просто так?
Нет, ну конечно с точки зрения маркетинга, все логично. А то как-то неудобно получалось рассказывать про невероятные преимущества Thin-provisioned volumes, тем кто читал документацию…

P.S: я одинаково хорошо отношусь ко всем производителям систем хранения данных и руками и ногами за честную конкуренцию. Какие-то из моделей я считаю более продвинутыми, какие-то менее… все зависит от тех условий в которых предполагается использовать ту или иную железку и что хочет от нее заказчик… панацеи не бывает. Я руками и ногами за честную конкуренцию, ведь она – двигатель прогресса технологий.
Но вот что мне действительно не нравится, так это маркетинговый туман, который все чаще и чаще проскакивает у многих вендоров. Когда слабые стороны выдаются за сильные или замалчиваются, когда покупатель прямо вводится в заблуждение относительно возможностей той или иной системы. Но это как правило в маркетинговых материалах, интеграторы и опытные покупатели знают: хочешь знать правду – читай техническую документацию admin guide, install guide, configuration guide, release notes и т.п. там хоть и “мелким шрифтом”, но пишут все как есть и этому можно доверять.
А теперь представим, что в угоду продажам, будут писаться не только маркетинговые материалы, но и техническая документация. И про подводные камни, которые могут ждать потребителя при использовании какой-либо возможности системы там не будет ни слова (чтобы не портить маркетинговый фон). И интегратор обязательно захочет использовать широко разрекламированную возможность системы на благо клиента, а клиент может быть сильно разочарован результатом, и все недовольство будут направлено в первую очередь против интегратора который предложил, продал, настроил в соответствии с технической документацией… а оно не так хорошо работает как написано, финиш, ущерб репутации интегратора.
Честно говоря я думал что это невозможно… до сих пор…
(постараюсь узнать в IBM как так получилось и надеюсь, что это просто недоразумение)

11 Ноябрь 2011

ruteched 2011

Вернулся с Tech∙Ed Russia 2011, реально понравилось.

15 Октябрь 2011

Как найти человека в ИТ команду.

Давно собирался написать по этому поводу, т.к. периодически просят побеседовать с кандидатом на работу в какую-нибудь компанию, да и самому приходится иногда набирать сотрудников.

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

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

OK. Мы написали нормальные требования и у нас есть несколько подходящих кандидатов. Как же узнать кто из них нам больше подходит?
Это конечно прозвучит странно, но положитесь прежде всего на свою интуицию, если вам кажется “что-то тут не так”, думайте, возьмите паузу, проверьте лишний раз. Если интуиция молчит :) то можно собеседовать по существу.
Смотрите прежде всего на общую адекватность человека, и на желание работать. Желание работать можно легко распознать по тому как человек будет рассказывать вам о том чем он занимался раньше, отвечать на вопросы и т.п. Если кандидата интересно слушать, это хороший знак. Конечно задайте вопросы по технологиям из резюме, но не спрашивайте, что-то узко специализированное глубокое, задавайте вопросы по базовым понятиям той или иной технологии, так вы поймете что реально знает человек несмотря на стресс, который у него конечно будет в момент интервью. Помните, для детальной проверки у вас есть испытательный срок.

Следуя этим простым правилам, мне до сих пор удается набирать нормальных сотрудников. Чего и вам желаю.

Blogroll

    about NetApp Блог о технологиях NetApp
    IT-community Сообщество специалистов по технологиям Microsoft
    Linux-HA Бюджетный высокодоступный кластер на Linux
    NetApp Производитель лучших по моему мнению СХД
    Opennet Тусовка фанатов Open-Source
    VMware The best виртуализация (проверено)

Meta