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

вторник, 10 мая 2011 г.

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Гбит, а рассчитывая на ближайшую перспективу.
    image

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

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

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

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

вторник, 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!