ИТ-технологии для профессионалов

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

вторник, 30 октября 2012 г.

IBM: очередная эпоха СХД подходит к концу

Век систем хранения, использующих Fibre Channel диски в качестве бэкенда, неумолимо подходит к концу. Один из немногих оставшихся оплотов практически пал - IBM с 29го января 2013 года снимает с продаж долго служившие верой и правдой системы хранения серии DS5100 и DS5300. Линейка DS5000 долгое время являлась “топовым” решением для MidRange СХД – расширенный функционал, высокая производительность и хорошая масштабируемость давали на это полное право. Однако, все меняется и сейчас, используя кластеризованную систему Storwize V7000 можно получить не только 960 дисков, но и заметно более интересные программные возможности. Владельцам DS5000 расстраиваться не стоит – системы действительно очень приличные, а дисковые полки для апгрейда с продаж не снимаются и остаются доступными к заказу.

Но кому нужно беспокоится, так это владельцам систем DS4000 (а такие еще есть и СХД эти встречаются у заказчиков часто) – дисковые полки для них (EXP810) снимаются с продаж уже в декабре этого года. Так что, если стоит задача продлить жизнь системе – пора принимать решение и быстрее делать заказ.

Если нужно увеличить емкость или продлить сервисную поддержку на СХД серии DS4700/DS4800 или IBM DS5100/DS5300 – обращайтесь к нам сейчас, не дожидаясь окончания гарантии!

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

вторник, 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 или больше.

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

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

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

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

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

Если у вас используются системы 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-ти минут) получать следующие данные:

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

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

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



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

понедельник, 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 могут ее оттуда скачать). Даже если доступа к утилите у Вас и нет, Вы можете собрать необходимые данные и отправить их интегратору, чтобы он провел для необходимый расчет и подобрал нужную конфигурацию, которая обеспечит должный “запас прочности”.

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

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

вторник, 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 – хотя и тоже пока не актуально, но тоже было бы громким шагом.
Читать дальше ...

четверг, 16 июля 2009 г.

Как перешивать DS4000/5000

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

Итак, сперва что нам понадобиться:

  1. Убедиться, что с системой ничего не взаимодействует. Т.е. на контроллерах нет рабочей IO.
  2. Запастись спец переходником для конкретной системы (DS) который будет конечным «хвостиком».
  3. Лучше использовать встроенный COM порт компьютера, а не USB переходник.
  4. Обратить внимание, что на некоторых ноутбуках некорректно работает “Break”. Использовать экранную клавиатуру либо внешнюю USB, если это так.
  5. Убедиться, что в системе есть нормальный клиент терминала с возможностью передачи данных Xmodem.

Теперь сама процедура:

  1. Выключить питание на БП системы тумблерами, убедиться, что все лампочки погасли. Если есть полки отключить питание на них. Подождать 20 секунд.
  2. Изъять исправно работающий контроллер (если оба плохие, то изымаем контроллер B, поскольку сначала придется восстановить один контроллер из двух).
  3. Изъять все внешние полки расширения. Достаточно отключить их от контроллеров на головном модуле.
  4. Изъять все диски из 0 полки (для 4700 или другой системы со встроенными в контроллер дисками).
  5. Скоммутировать кабель RS232, настроить подключение как написано ниже (настройки терминала). Могут быть сложности с высокой скоростью, но имеет смысл выставить хотя бы 54 600 т.к. на 9600 прошивка будет литься очень долго.
  6. Теперь когда в системе нет дисков и включен 1 контроллер из двух, включить питание в обоих БП тумблерами.
  7. Ждем когда начнут появляться какие либо знаки в консоли, либо не дожидаясь, интенсивно жмем BREAK в терминале (для hyperterm – комбинация ctrl+break).
  8. В итоге система должна перестать выводить “крокозябы” и на англ языке предложит нажать BREAK для установки baud rate. Жмем BREAK.
  9. Когда система попросит нажать пробел в течении 5 сек, не тормозим и жмем пробел.
  10. Начинаем жать ESC. Фича в том, что по доке IBM, ESC надо жать после спец приглашения, в актуальных прошивках этого приглашения нету!! ESC нужно жать, когда система предлагает что то вроде «press S for service menu …» или наподобие. Если не получается поймать момент когда нужно нажать ESC, нужно повторять нажатия space и BREAK до того состояния чтобы появилось сообщение «press S for service menu …» . Ну а уже тогда – ESC.
  11. Система должна вывести приглашение для ввода пароля куда вписываем “******”. После этого система любезно предложит шелл с приглашением #. Если пароль не подходит с вероятностью 99% мы логинемся не туда – решение перезагрузиться либо см п.10 выше.
  12. Пишем в шелле – sysReboot и далее два раза пробел. Если не открылось системное меню - жмем Ctrl+B.
  13. В меню выбираем пункт 2 (что-то там про transfer file). Затем с помощью X-Modem отправляем файл прошивки скаченный с сайта IBM. Процесс займет минимум 30 минут.
  14. В конце терминал должен явно написать, что все передано успешно и показать 5-6 разных строк состояния по очереди приходящих к 100%.
  15. После окончания инициализации прошивки - система напишет, что все «completed sucsesfully» и выйдет в загрузочное меню. Перезагружаемся. Контроллер успешно перешит, если поломаны оба – делаем туже процедуру и на втором и смотрим п.16; если был поломан только один контроллер смотрим п. 17.
  16. После того как на обоих контроллерах одинаковые прошивки, которые корректно работают, выключаем систему и собираем её в штатном режиме с дисками и полками.
  17. Если в системе тока 1 контроллер был дохлый – изымаем его после успешной зашивки, вставляем в систему диски и второй контроллер и стартуем (подаем питание) всю систему. После успешной загрузки системы с дисками на одном контроллере (который был ОК) вставляем прошитый только что из консоли и убеждаемся, что все работает нормально.

 

УВАГА !!

Если загрузиться с дисками 6-ой версии прошивки контроллера и контроллерами 7-ой версии информация скорее всего потеряется.
Если загрузиться с дисками 7-ой версии прошивки контроллера и контроллерами 6-ой версии информация скорее всего потеряется.

 

Настройки терминала

Скорость 9600 – 115 200
Биты –8
Четность – нет
Стоповые – 1
Управление потоком – аппаратное либо Xor/Xoff

 

Пароль на Shell
Я его не стал публиковать, инженеры IBM Вам его легко подскажут в случае необходимости.

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