Показаны сообщения с ярлыком DS5000. Показать все сообщения
Показаны сообщения с ярлыком DS5000. Показать все сообщения

вторник, 26 апреля 2011 г.

IBM Storage Partitioning

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

image
Самая распространенная ошибка - мнение, что эта лицензия ограничивает каким-то образом число массивов или 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:

image

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

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

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

image

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

image

В нашем примере мы задействовали 3 Storage Partitions на кластер из двух серверов. Количество задействованных в нашей конфигурации Storage Partitions легко определить визуально в Storage Manager на закладке Mapping - для каждой задействованной лицензии на экране в закладке Mapping радом с сервером или группой серверов будет вот такой значок image.
Ограничение на использование 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 или больше.

Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

среда, 19 мая 2010 г.

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

Если используется одна система хранения, то управлять ей конечно несложно! А вот если их три или и того побольше? Как осуществлять мониторинг систем, чтобы не допускать ситуации, когда нагрузка становится фактически предельной, а жизнь пользователей становиться безрадостной? Если у вас используются системы IBM, то существует такой замечательный продукт как 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ти минут) получать следующие данные:

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

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

Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

понедельник, 18 января 2010 г.

Полезное чтиво про IBM DS4000/DS5000

IBM опубликовал сразу 4 драфта новых книжек про системы хранения среднего уровня (DS4000/DS5000), которые должны занять достойное место в подборке документации администраторов СХД:

По сравнению с тем, что уже можно было найти в “редбуках” ранее, собрана вместе информация по новым системам в линейке DS4000/DS5000 и подробно описаны все нововведения. Две последние работы довольно узко специализированы: в одной подробнейшим образом изложен механизм работы мгновенных снимков и клонирования (в т.ч. и между системами), а вторая посвящена виртуализации на базе VMware ESX/ESXi. В принципе, обе книги не содержат радикально новой информации (по крайней мере, я не увидел ничего, что не встречалось бы в выпущенной ранее документации), однако прочитать и держать под рукой эти материалы полезно. Тем же, кто впервые развертывает VMware на системах IBM DS4000/5000 читать просто необходимо – в соответствующей книге собран вместе обширный материал, который позволит гораздо лучше понять что и как делать. Не оставлен в стороне и вопрос выбора (и оптимизации) настроек дисковой системы для повышения производительности.

Наибольший же интерес, на мой взгляд, должны представлять первые две книги – изложенный материал позволяет гораздо лучше понять, как именно устроены дисковые системы IBM и как с ними нужно работать. Тем, кто впервые сталкивается с системами IBM, очень поможет описание термина “Storage Partitions”, который часто вызывает проблемы в понимании. Объясняется множество вопросов, которые могут возникнуть в процессе подбора конфигурации. Поэтому эти две книги полезны не только пользователям систем, но и пресейлам – правильно подобрать конфигурацию тоже бывает непросто. Отдельная глава посвящена RSM (Remote Support Manager), продукту который пока не слишком популярен на наших просторах, но ситуация должна постепенно меняться.

Администраторам будет интересно прочитать про процедуру обновления прошивок, конфигурацию коммутаторов и настройку СХД в связке с различными операционными системами (в т.ч. есть и пример настройки кластера Windows 2008 при загрузке с SAN). До недавнего момента в многочисленных книжках IBM встречалась рекомендация подключать контроллер A к одному коммутатору, а контроллер B – ко второму. Мне такая схема всегда казалась не очень правильной (хотя она и обеспечивала отказоустойчивость) так как при этой настройке, выход из строя коммутатора, обрыв кабеля от сервера к коммутатору или выход из строя адаптера в сервере гарантированно приводит к переносу LUN’а между контроллерами, что может вызвать проблемы производительности. Поэтому я всегда рекомендовал подключать каждый контроллер к каждому коммутатору и терпеливо объяснял свою позицию внимательным читателям документации. Сейчас же был приятно удивлен – теперь везде приводится рисунок с “правильным” подключением:

imageТакже очень полезной будет и глава по определению неисправностей и их устранению. Не секрет, что зачастую вопрос обслуживания ложится на хрупкие плечи системного администратора – либо по каким-то причинам не был куплен сервисный пакет, либо система находится далеко и времени на ожидание ответа от сервиса нет, да и много других причин может быть.

Можно найти и очень много подробных описаний по оптимизации настроек СХД для тех или иных приложений. Но отдельного упоминания заслуживает вопрос сайзинга, т.е. подбора конфигурации под имеющуюся (планируемую) нагрузку. Здесь и работа с монитором производительности в Storage Manager (Performance Monitor), и IBM Tivoli Storage Producivity Center for Disk. Детально объясняется работа с такой полезной утилитой для сайзинга как Disk Magic (впрочем, я не уверен что она доступна пользователям, но имеющие доступ на IBM Partnerworld могут ее оттуда скачать). Даже если доступа к утилите у Вас и нет, Вы можете собрать необходимые данные и отправить их интегратору, чтобы он провел для необходимый расчет и подобрал нужную конфигурацию, которая обеспечит должный “запас прочности”.

Так как упомянутые книги это пока только драфты, то читать их конечно нужно, но и следить за обновлениями тоже не помешает!

Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

вторник, 25 августа 2009 г.

IBM DS5020 приходит на смену “старичку” DS4700

Дисковая система IBM DS4700 уже несколько лет является боевой лошадкой для тех, кому нужна довольно производительная и расширяемая СХД среднего класса не с заоблачной ценой. Но вот и пора на покой – на смену приходит новый игрок – IBM DS5020. Анонс, традиционно, датирован вторником (сегодняшним числом).

imageЧто же нас ждет? Неожиданных новостей не будет – практически все уже видели у “старшего брата” – DS5100/5300. В базе система DS5020 оснащена 4мя портами FC 8Gbit (по два на каждый контроллер). При желании, можно дополнительно установить либо еще 4 порта FC 8Gbit, либо 4 порта iSCSI 1Gbit. Это избавляет нас от необходимости использовать отдельные (и требующие соответствующей настройки) iSCSI-гейты для подключения серверов, которым нет особой нужды в FC. Диски поддерживаются SATA (750GB и 1TB) , FC (146/300/450GB 15k) и FDE (с поддержкой шифрования – 146/300/450GB 15k). Поддержка SSD осталась в старшей серии, что наверное логично (в первую очередь из-за цены SSD – уж если есть бюджет на них, то и на DS5300 можно найти). В плане кэша также есть выбор – 2 или 4GB на систему. Т.е. хотя и разграничения по моделям и нет, но “болезненный” выбор необходимых опций при начальном заказе остался - дополнительные порты и расширение кэша доступны только при изначальном заказе, но не как апгрейд. Одно из новшеств DS5100/5300, перекочевавшее в DS5020, состоит в том, что защита кэш памяти не ограничивается установкой батарей, а при отключении питания происходит “сброс” содержимого кэша на флэш-память, что обеспечивает защиту кэша даже при долговременном отключении системы (или при неполной зарядке батарей). В контроллерной полке, как и в DS4700 можно установить до 16-ти дисков, а вся система расширяется до 112 дисков. Полки расширения используются новые EXP520, но и “старые” EXP810 также можно подключить (правда требуется соответствующая лицензия). Бэкэнд остался 4х гигабитным. Но исчезла лицензия, позволяющая смешивать в одной системе FC и SATA диски – теперь это можно делать совершенно спокойно (диски, как и прежде, можно “смешивать” по собственному желанию, без каких либо ограничений). Кроме того, добавление первой EXP520 не требует никаких лицензий. Лицензируется подключение дисков с 33 по 64го, при подключении более 64х дисков потребуется еще одна лицензия. Минимальное число Storage Partitions, как и прежде, 2 и расширяется до 128ми степенями двойки (4, 8, 16, 32, 64, 128). Вот собственно и все новости – внешне система практически не отличается от DS4700 (спереди только надписью, а сзади – небольшим внешним отличием контроллеров).

Основные характеристики по сравнению с DS4700 мало изменились: поддерживаются RAID1,3,5,10,6; в одной RAID-группе RAID10 можно использовать до 112 дисков, в остальных типах RAID – до 30ти дисков; поддерживаются такие возможности как создание мгновенных снимков (FlashCopy), клонов (VolumeCopy) и репликация на удаленный массив (Enhanced Remote Mirroring). Производительность системы заметно увеличена (результаты пока официально не опубликованы, но обещают до 50% прироста). Фактически, получили новую “рабочую лошадь” взамен старой.

А что же все-таки не получили, хотя было бы очень полезно? Есть и такое:

  • установка дополнительных портов по мере необходимости (EMC вон уже давно это умеет);
  • расширение кэша как апгрейд;
  • поддержка SSD – не больно и хотелось, а, положа руку на сердце, и не нужно (с технической точки зрения), но “толпа жаждет”;
  • расширение возможностей VolumeCopy и FlashCopy;
  • FCoE – хотя и тоже пока не актуально, но тоже было бы громким шагом.
Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!