IBM DS3500: новые возможности

По случаю Дня Победы (и наверное не только по этому случаю), в IBM анонсировали целый ряд существенных улучшений в и без того популярных системах серии DS3500 – DS3512 и DS3524. На самом деле, 9го мая были и другие (зачастую не менее значимые) анонсы в области систем хранения IBM, но про них в другой раз. Так что же теперь еще есть в DS3500?

• Самое заметное нововведение – в два раза увеличено количество поддерживаемых дисков. Теперь в одной DS3500 может быть до 192 жестких дисков SAS и/или NL SAS. Для этого потребуется докупить соответствующий ключ активации. Тем самым, можно получить до 384ТБ raw ёмкости на систему при использовании 3.5" NL SAS дисков 2ТБ и до 192ТБ raw ёмкости на систему при использовании 2.5" NL SAS дисков 1ТБ (которые, кстати, также были анонсированы 9го мая).
• Поддерживается до 128 Storage Partitions, а также до 256 томов на каждую “partition”. Суммарное же количество поддерживаемых томов увеличено до 512 на систему.
• Дополнительная опция позволит создавать до 16 пар томов (вместо 8ми, которые были доступны ранее) при использовании Remote Mirroring (синхронная и асинхронная репликация).
• Для тех, у кого активированы FlashCopy и/или VolumeCopy получат поддержку до 256 копий на систему (количество копий на том остается без изменений). Более того, теперь нет никакой необходимости приобретать ключи активации для FlashCopy upgrade и VolumeCopy upgrade – достаточно Base версии чтобы получить максимум возможностей.
• Поддерживается подключение к хостам через SAS коммутатор (ранее более 4х хостов можно было подключить только по FC или iSCSI). Сами коммутаторы через IBM не поставляются пока, но зато они есть у LSI. Совместимость, как обычно, проверяется через SSIC.
• Для тех, кто заинтересован в использовании iSCSI, но 1Гбит интерфейсы не устраивают по производительности, есть приятная новость – анонсированы интерфейсные платы с портами 10Гбит. В результате, можно получить по два 10Гбит порта на контроллер (4x10Гбит на двухконтроллерную систему). Примечательно, что используются не привычные SFP+ порты, а RJ45. Так как порты на новых картах могут работать и на 10Гбит, и на 1Гбит, можно смело использовать эти интерфейсные платы даже без инфраструктуры 10Гбит, а рассчитывая на ближайшую перспективу.
  

Помимо “железных” возможностей, появились улучшения и в плане управления системой:

• Для периодического создания мгновенных снимков вместо скриптов (в определенных случаях) можно использовать расписание, настраиваемое через GUI в DS Storage Manager (также его можно настроить и в CLI).
• Теперь вовсе необязательно при создании VolumeCopy вручную делать FlashCopy, чтобы обеспечить непрерывный доступ к исходному тому – опция “Online VolumeCopy” позволит автоматизировать процесс и соответствующий снимок будет создан в системе без участия администратора.
• Но наиболее интересная для меня новость – улучшения в Performance Monitor, который теперь научился показывать не только realtime результаты, но и накопленные за период значения (до 7ми дней):
  Это позволит нам существенно упростить жизнь при поиске потенциальных проблем и при анализе производительности системы.

Сейчас, благодаря этим новшествам, системы DS3500 стали еще привлекательнее для пользователей и способны занять не только нишу начального уровня, но и составляют серьезную конкуренцию системам класса MidRange. Осталось только дождаться поддержки SSD!

Читать дальше ...

IBM Storage Partitioning

Все, кто хотя бы раз сталкивался с системами хранения IBM, наверняка знает (или хоты бы хоть раз встречал) термин "Storage Partitions". Но зачастую даже те, кто с системой уже работал, не всегда правильно понимают его смысл. Поэтому сегодня несколько слов про эти самые "партиции".
Для всех систем DS3000/4000/5000 всегда при заказе присутствует некоторое количество Storage Partitions (от двух и более). Даже если явно в спецификации такой позиции нет, значит есть некоторое их количество, которое включено в системе по умолчанию. Я буду использовать термин лицензия (как и в англоязычном варианте, хотя правильнее наверное говорить про "активируемая кодом опция", так как это не право пользования, а именно активация).

Самая распространенная ошибка - мнение, что эта лицензия ограничивает каким-то образом число массивов или LUNов, которые можно создать. Это конечно же не так! Но давайте по порядку.
Обычно система хранения используется для подключения сразу нескольких серверов. Если это различные серверы, например Windows с MS SQL и Linux c Oracle, то каждый сервер должен иметь доступ только к своим дискам (LUN) на системе хранения. Можно конечно не монтировать "чужие" диски на серверах, можно в настройках FC адаптеров серверов отключать доступ к "чужим" дискам, некоторые коммутаторы также позволяют "фильтровать" LUNы для серверов. Все эти методы имеют существенный недостаток - любая ошибка в настройках или любое неосторожное действие с "чужим" LUN может полностью уничтожить данные на этом томе. Кроме того, "своими" для одного сервера будут нужны например LUN 0 и 3, для другого 1, 7 и 2, а для третьего - 4, 5 и 6. В некоторых операционных системах из-за этого (номера LUN идут не подряд и начинаются не с нуля) могут возникнуть проблемы.
Напрашивается логичное и правильное решение - использовать так называемый LUN mapping (с данными термином путаницы меньше и его практически всегда трактуют правильно). Суть состоит в том, что для каждого сервера создается список wwn портов HBA и ему сопоставляется список LUN, которые будут доступны для данного сервера. Для каждого сервера теперь LUN могут начинаться с 0 и идти подряд. Более того, теперь никакие настройки на сервере не нужны - сервер всегда видит свои и только свои LUN.
Так что же такое Storage Partitions? А это и есть то количество сопоставлений, которые можно сделать на данной системе хранения. Т.е. если мы будем подключать к системе хранения 3 независимых сервера, то нам достаточно 3х Storage partitions:

Почему именно независимых серверов? Очень просто: если нужно подключить два (или 3, или  10) сервера в кластер, так чтобы они имели доступ к одним и тем же дискам на СХД, то задействована будет только одна Storage Partition. Таким образом, говорить что на 10 серверов нужно именно 10 Storage Partitions не всегда правильно. На снимке – настройки Mapping для кластера из двух серверов, которые имеют доступ к одним и тем же дискам:

Как видим, для этого требуется только одна Storage partition:

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

В этом случае для кластера из N серверов потребуется уже N+1 Storage Partitions. N активаций задействуется для предоставления загрузочного диска каждому из серверов и еще одна требуется для доступа к "общим" дискам.

В нашем примере мы задействовали 3 Storage Partitions на кластер из двух серверов. Количество задействованных в нашей конфигурации Storage Partitions легко определить визуально в Storage Manager на закладке Mapping - для каждой задействованной лицензии на экране в закладке Mapping радом с сервером или группой серверов будет вот такой значок .
Ограничение на использование SP жесткое, т.е. задействовать больше лицензий, чем было куплено, нельзя и необходимо при планировании учитывать этот параметр, заказывая по мере необходимости дополнительные лицензии.
Максимальное число Storage Partitions для разных систем различно, более того, иногда максимум увеличивается с очередной новой прошивкой, но оно достаточно большое, чтобы вероятность его достижения была весьма мала – например для DS5300 можно активировать 512 partitions, а для DS3500 – 64 (и уже совсем скоро будет еще больше).
Если система была изначально заказана с 4мя Storage Partitions, а скоро нужно будет 6, ничего страшного - достаточно просто заказать активацию дополнительных SP. Правда есть одна тонкость: активация поставляется в бумажном виде и в большинстве случаев придется ждать эту бумагу два месяца, поэтому озаботится желательно заранее, а не за два дня до установки новых серверов. На СХД могут быть активированы только 2, 4, 8, 16, 32, 64, 128… Storage Partitions, поэтому если для реализации проекта необходимо будет 11 Storage Partitions, то заказать нужно 16 или больше.

Читать дальше ...

Управлять СХД – просто!

Если используется одна система хранения, то управлять ей конечно несложно! 

А вот если их три или и того побольше? — Как осуществлять мониторинг систем, чтобы не допускать ситуации, когда нагрузка становится фактически предельной, а жизнь пользователей становиться безрадостной? 

Если у вас используются системы IBM, то существует такой замечательный продукт как Tivoli Storage Productivity Center (TPC). 

Tivoli Storage Productivity Center (TPC)

По сути это даже не один продукт, а несколько разных: TPC Basic Edition, TPC for Data, TPC for Disk, TPC for Replication, TPC Standard Edition. 

TPC for Disk как раз позволяет следить за состоянием СХД и их производительностью, а также получать алерты и всевозможные отчеты. 

Проблема в том, что для СХД начального и среднего уровня цена TPC for Disk была до недавнего момента явно высокая (учитывая тот факт, что лицензируется весь объем дискового пространства). 

И вот, совсем недавно (14-го мая) была анонсирована еще одна версия: TPC for Disk MidRange Edition (TPC for Disk MRE). 

Отличие ее от “старшего” брата состоит в том, что, во-первых, поддерживаются только системы DS3000/4000/5000, а во-вторых, (и это, на мой взгляд, основное) лицензирование осуществляется по устройствам. Т.е. фактически нужно просто сложить количество контроллерных и дисковых полок и умножить результат на стоимость лицензии. 

Цена лицензии

В большинстве случаев цена получается ниже примерно в два раза (а если используются SATA диски большого объема, то разница в цене может быть и в несколько раз). В результате, можно централизованно (с интервалом до 5-ти минут) получать следующие данные:

• производительность контроллеров (число операций ввода-ввывода)
• производительность контроллеров (скорость передачи данных)
• процент попадания в кэш
• производительность отдельных портов контроллеров

Качество предоставления сервисов

Проактивный мониторинг состояния и производительности позволяет существенно упростить управление инфраструктурой, а главное – дает возможность повысить качество предоставления сервисов.

Читать дальше ...

DS3000 GUI vs CLI

Не секрет что системы IBM DS3000, DS4000, DS5000 производятся компанией LSI по заказу IBM, при этом прошивки систем очень похожи друг на друга. Они имеют схожую нумерацию версий, одинаковый синтаксис командной строки, управляются одним и тем же продуктом - IBM DS Storage Manager.

Системы DS4000 и DS5000 практически идентичны, с точки зрения функционала доступного из GUI DS Storage Manager. Они отличаются только эскизами самих систем (все-таки, внешне они разные) и количественными характеристиками. Другое дело отличия в GUI DS3000 и старших систем, так получается, что часть функционала имеющегося в системах DS3000 недоступна из GUI, при этом его можно задействовать через командную строку. С моей точки зрения там есть действительно нужные команды, которые могут серьезно облегчить жизнь инженеру обслуживающему данные системы. К примеру, команда расширения LUN, альтернатива ей из GUI нету.

Я думаю, что все функции не включены в GUI системы DS3000 по маркетинговым соображениям. Видимо с точки зрения IBM, если вам требуется что-то большее чем просто дисковая емкость, следует покупать системы старшего уровня

Я не буду перечислять все команды, которые доступны в системе, их можно найти в хелпе к DS Storage Manager, я же отмечу только то, что однозначно полезно знать и чем я сам неоднократно пользовался.

Самый простой способ инициировать выполнение скрипта системой – открыть DS staroge manager, щелкунть по требуемой системе правой клавишей и выбрать из контекстного меню “Execute Script”. В открывшемся окне пишем код и жмем по необходимости Verify или Execute.

Теперь непосредственно сами команды:

1. Добавление дисков к уже существующему массиву можно выполнить из GUI но добавлять можно только по одному диску (по два для RAID10), через консоль же можно добавлять по два диска и для RAID 5/6. Учитывая то, что каждый шаг расширения может достигать нескольких часов, консоль в случае расширения RAID 5/6 уменьшит количество итераций в 2 раза.

Синтаксис:
set array [tst] addDrives=(0,9 0,10);
здесь “tst” имя array, диски адресуются по принципу «номер полки запятая номер диска», между дисками ставится пробел.

2. Если у Вас на Array находится несколько LUN и Вы удаляете не последний на его месте образуется «пусто место». Это пустое место будет доступно для того чтобы сделать на его месте один или несколько LUN, но если вы хотите использовать это место для создания большого луна, тоесть использовать его вместе с другим пустым местом – ничего не получится. Поскольку можно создать LUN только на пустом месте идущем «одним куском». Помогает вынести все свободное место в конец массива команда дефрагментации. В GUI её нет.

Синтаксис:
start array [tst] defragment;
здесь “tst” имя array

3. После создания LUN зачастую оказывается, что места было мало и необходимо предоставить больший объем. В GUI DS3000 не умеют расширять LUN, то есть предполагается, что мы создаем новый LUN, копируем на него данные и потом меняем старый на новый LUN. Понятно что такая процедура очень сложна и требует на одной системе места и под старый LUN и под новый, либо стороннего дискового пространства. Ну и в момент переноса данные будут недоступны по понятным причинам. В консоли же есть штатная команда для расширения, процесс займет какое-то время (в зависимости от размера LUN), но работа с данными не будет прервана и после окончания ОС просто обнаружит пустое место на диске (так будет в ОС Windows 2003/2008).

Синтаксис:
set logicalDrive ["tstlun"] addCapacity= 1 GB;
Здесь “testlun” имя LUN, вместо GB могут быть MB. Не забудьте пробел после цифры.

4. Можно изменить размер сегмента LUN. Целесообразность – тема отдельная, но в GUI этой функции нету.

Синтаксис:
set logicalDrive ["tstlun"] segmentSize = 256;
Здесь “testlun” имя LUN, цифра размер сегмента в kb.

5. В системе можно изменить настройки кэширования для отдельного LUN. Чтобы понять что отвечает за что – нужно читать Redbook.

Синтаксис:
set logicalDrive ["tstlun"] cacheFlushModifier=cacheFlushModifierValue cacheWithoutBatteryEnabled=(TRUE | FALSE) mirrorCacheEnabled=(TRUE | FALSE) readCacheEnabled=(TRUE | FALSE) writeCacheEnabled=(TRUE | FALSE) cacheReadPrefetch=(TRUE | FALSE);
Здесь “testlun” имя LUN, варианты представлены в скобках.

6. Можно изменить размер блока КЭШа. С моей точки зрения надо ставить 16 kb.

Синтаксис:
set storageSubsystem cacheBlockSize=16;

7. Можно изменить настройки работы КЭШа.

Синтаксис:
set storageSubsystem cacheFlushStart=80 cacheFlushStop=80;
Для понимание что это – Redbook. Best Practice – 80 оба значения.

8. Можно снять с системы результаты производительности. С моей точки зрения результаты могут быть чрезвычайно полезны.

Синтаксис:
set session performanceMonitorInterval=10 performanceMonitorIterations=10;
save storageSubsystem performanceStats file="C:\perf.txt";
Здесь в первой строке мы задаем время снятия изменений (одной итерации) и количество этих итераций. Во второй строке мы стартуем процесс снятия результатов и указываем, куда сохранять результаты.

9. Можно посмотреть статус текущей операции и процент её выполнение. В GUI система показывает, что она просто “Operation in prgoress” через CLI можно еще и получить точную информацию о проценте выполнения.

Синтаксис:
show logicalDrive[tstlun] actionProgress;
Здесь “testlun” имя LUN. Также можно использовать для создания скриптов где требуется дождаться что система свободна.

Информация по теме:
http://www.redbooks.ibm.com/abstracts/sg247065.html - RedBook IBM System Storage DS3000: Introduction and Implementation Guide

ftp://ftp.software.ibm.com/systems/support/bladecenter/gc52127502.pdf - IBM System Storage DS3000, DS4000, and DS5000 Command Line Interface and Script Commands Programming Guide

Читать дальше ...

IBM DS3400 размер блока массива R10 и размер блока кэша системы

Вопрос который меня давно интересовал – как в цифрах будет влиять изменение размера сегмента райда на производительность на разных размерах блока нагрузки.

Что такое вообще размер сегмента, segment size в терминологии IBM? В DS3000/4000 это размер данных, который должен быть записан на диск или прочитан с диска, перед тем, как система продолжит запись/чтение на следующий диск.

Учитывая, что тест IOmeter делается на RAW пространстве фрагментации файлов нету и получается, что при тесте на запись, на каждый диск должно попасть количество данных равное размеру сегмента райда перед тем как начнется запись на следующий диск. Такая же ситуация будет происходить и с чтением.

В чистой теории максимальная производительность достигается тогда, когда размер страйпа диска максимально приближен к размеру IO которым система создающая нагрузку взаимодействует с самой системой. С другой стороны все рекомендации производителей дисковых систем сводятся к тому, что нужно выбирать размер страйпа для массива по умолчанию, что фактически означает прямую зависимость оптимизации кода прошивки контроллера под конкретный размер страйпа массива. В 3400 системе по умолчанию это 128кб, для медиа контента (большие файлы) предлагается блок 256кб. Вообще размер этого самого страйпа может меняться шагами 16-32-64-128-256-512 кб.

В руководстве IBM дает только 2 принципиальных рекомендации по размеру сегмента:
1. Для маленького IO размер сегмента массива должен быть равен или больше, чем размер IO.
2. Размер IO не обязательно должен совпадать с размером сегмента для достижения максимальной производительности.

Около полугода назад я ставил тест при повышении размера страйпа с 32 до 512 кб и замерами производительности и был изрядно удивлен тем, что на любом типе нагрузки максимальная скорость достигалась на размере сегмента 128 или 256 кб, даже на самых маленьких размерах IO. Сейчас я проделывал туже операцию на DS3400 сконцентрировавшись на 2-х размерах сегмента: 128кб (по умолчанию) и 256кб (предлагается системой для медиа нагрузки). Также я менял размер блока кэша системы с 4кб (по умолчанию) на 16кб, это максимальное значение для данной системы.

Управление размером кэша производится на уровне всей системы целиком и в DS3400 делается из консольной строки.

Тесты проводились на 2-х контроллерной системе DS3400 подключенной через FC свитч к 1 портовому FC HBA на сервере который создавал рабочую нагрузку. В каждом контроллере системы стоит по 512МБ кэша. Ниже представлены диаграммы на которых видно влияние тех или иных настроек на производительность системы.

Последовательное чтение

Из результатов видно, что изменяемые характеристики не имею сильного влияния на производительность, ясно видно что система быстро доходит до порога 400 мб/сек, ограничения сервера с одним HBA адаптером и перестает расти. На меньших скоростях видно, что в точке, где размер IO совпадает с размером блока кэша достигает повышение производительности относительно соседних результатов.

Последовательная запись

На графиках ясно виден результат рекомендации IBM “сегмент больше или равен IO” только сильнее это видно не на сегменте массива, а на размере блока кэша. Наглядно видно насколько выше результаты система дает, когда работает с кэшем нежели чем с дисковой емкостью. Наилучший результат получается в случае кэш-16кб, сегмент 256кб.

Случайное чтение

Также, как и в последовательном чтении, видно, что изменяемые настройки практически не влияют на производительность системы. можно отметить что в конфигурации 16кб кэш блок, 256кб сегмент система быстрее всего доходит до потолка интерфейса в 400МБ, при этом не теряя в производительности на маленьком блоке.

Случайная запись

Видно, что на маленьком блоке IO значения практически не влияют на IOPS, а на большом чуть быстрее оказывается 16кб блок кэша, 256кб размер сегмента.

Смешанная нагрузка (33% чтение), 100% случайная

В смешанной нагрузке запись, как более медленная операция, всегда тянет за собой и чтение, таким образом результаты получаются очень похожи на тест с полностью случайной записью. Видно что на маленьком блоке IO скорость работы систем одинаковая, при большом блоке IO – системы с размером сегмента массива чуть выигрывают.

Какие можно сделать выводы?

1. я думаю что в любом случае стоит ставить размер блока кэша системы в 16кб. Поскольку система DS3000 не обладает таким уж быстрым контроллером и не предполагает того, что на неё будут падать десятки тысячи мелких IO в секунду от какой нибудь высоконагруженной БД, кэш будет использоваться нерационально не так уж и часто. Синтетические тесты показывают, что и на маленьком размере блока система не проседает. Изменение размера блока  кэша на DS3000 делается командой “set storageSubsystem cacheBlockSize= XX KB;”, где ХХ – размер нового блока. Процедура выполняется мгновенно и применяется ко всей системе.

2. Скорее всего рационально использовать размер сегмента не в 128Кб, по умолчанию, а в 256кб. Я думаю что при реальной нагрузке это как минимум не снизит производительность работы, но вероятно и повысит её в определенных ситуациях. Скорее всего размер сегмента в 128кб по умолчанию сложился исторически с ранних версий прошивок системы.
Изменение размера сегмента для уже созданного луна возможно из командной строки, командой “set logicalDrive  ["logicalDriveName"] segmentSize= XX KB ;”, нужно учитывать, что процедура выполняется тем медленее, чем больше размер LUN’а к которой она применяется и чем больше система нагружена, процесс запросто может идти несколько часов. При этом процедура не отменяема и относится к монопольным, и если к примеру в момент перестройки понадобиться переконфигурить еще что ни будь, это не удастся сделать до окончания изменения размера сегмента. Процедура не прерывает доступ к информации в момент своей работы.

Книжка по теме:
http://www.redbooks.ibm.com/abstracts/sg246363.html?Open - DS4000 Best Practices and Performance Tuning Guide

Читать дальше ...