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

пятница, 8 июня 2012 г.

IBM DS3500/DCS3700: радикальные изменения

Как многие вероятно уже слышали, у IBM в этот понедельник прозвучало множество анонсов в области систем хранения. В той или иной степени были затронуты практически все линейки. В этой заметке я коснусь только лишь младших систем – DS3500 и DCS3700.

image

Большинство новинок носит принципиальный характер. Итак, новинки:

  • дисковые пулы (Dynamic Disk Pooling, DDP);
  • выделение дискового пространство по мере необходимости (Thin provisioning);
  • новая технология мгновенных снимков;
  • поддержка VAAI;
  • поддержка ALUA;
  • временные лицензии.

В чем плюсы, как это работает и что с этим всем делать? Попробуем пройтись по всем новинкам.

Динамические дисковые пулы.
Вместо привычных RAID массивов (Array) и томов на них (Volumes, LUNs), мы объединяем диски в большой пул и уже на этом пуле “нарезаем” тома нужного нам размера. Мы больше не привязаны к размерам конкретного массива, поэтому нам не нужно планировать массив так, чтобы наиболее эффективно его заполнить – все равно черпаем из “общего” котла. Нет ни выделенных дисков четности, ни выделенных hot-spare дисков.

image

Ну хорошо, схожие технологии мы видели и у других производителей, а в чем же отличие? Давайте посмотрим, как работает DDP. Каждый диск разбивается на 512МБ “дольки” (D-Piece) – см. рисунок ниже. Когда нам требуется выделить место из дискового пула для конкретного тома, система выбирает 10 таких “долек” с разных дисков (выбирает она так, чтобы выровнять занятый объем). Выбранные дольки объединяются в RAID-6 (8D+P+Q) и уже этот страйп (D-Stripe) размером 4ГБ и становится частью нашего тома с данными. D-Stripe для одного тома располагаются по разным дискам, обеспечивая, таким образом, распределение данных по всему пулу:

image

DDP не становятся заменой какой-либо технологии – можно использовать только один пул, можно использовать несколько пулов в одной системе, можно использовать и классические RAID-группы, и пулы вместе. Так как пулы по производительности все-таки ближе к RAID-6 и максимальную эффективность показывают на дисках NL SAS, то данные для приложений, критичных к скорости можно вынести, например, на отдельные RAID10.

В случае сбоя одного из дисков в пуле, происходит восстановление данных на оставшиеся диски. За счет того, что в восстановлении участвует большое число шпинделей, оно происходит с большей скоростью и оказывает меньшее влияние на производительность массива. Вместо выделенных hot-spare дисков резервируется соответствующее свободное место в пуле (примерно так, как это реализовано в HP EVA). Можно зарезервировать до 10 дисков (или до 20% объема пула). Вот как изменяется время восстановления в зависимости от числа дисков в пуле по сравнению с перестроением классического RAID6:

image

На 192х дисках различие превышает 5 раз! А при временах порядка 10 часов это весьма заметно. Не стоит забывать, что при восстановлении классического массива деградация производительности также весьма велика:

image

Хорошо видно, что во время ребилда диска в большом пуле, производительность приложений будет страдать заметно меньше (особенно если не ставить целью провести перестроение максимально быстро).

Конечно, раз уж речь зашла о производительности, то хочется сразу уточнить, а насколько такая новая технология “портит нам жизнь” в плане этой самой производительности? Результаты показывают, что максимально “страдают” операции случайной записи и последовательного чтения(~15%); случайное чтение же ухудшается всего на 6%, а последовательная запись даже улучшается. Такие эффекты заметны в “синтетических” тестах на 192х дисках в пуле. Если же количество дисков меньше, то и различие в производительности приближается к нулю.

Еще один замечательный плюс от DDP – возможность добавления дисков в пулы. Вы скажете что в RAID тоже можно добавить дисков? А сколько “за один раз”? А чем это чревато с точки зрения производительности? Вот именно – лучше этого на обычном массиве не делать. При добавлении же в пул новых дисков, происходит миграция незначительного числа “D-Piece” на новые диски, что не оказывает, в свою очередь, существенного влияния на производительность системы.

Таким образом, динамические пулы дают нам отличную замену для RAID6, позволяя объединить большое количество дисков, обеспечивая высокую производительность, простоту управления и высокую защищенность.

Thin provisioning.
Данная технология уже хорошо всем известна, но теперь она появилась и в младших СХД IBM. Причем появится и у тех, кто год назад стал владельцем системы DS3500. Единственное “но” – thin provisioning работает только на динамических томах! Поэтому “поиграть” на системе, не создав заранее дисковый пул, увы, не получится. Плюсы у thin provisioning очевидны – не нужно задумываться о точности выделения дискового пространства. Можно выделить немного больше, а по факту на дисках будет занято ровно столько, сколько данных было записано. На самом деле, с шагом 4ГБ конечно – выделение дискового пространства осуществляется в терминах D-stripe. Экономия от использования технологии thin provisioning может быть колоссальна – проверьте на своих системах, сколько незанятого места теряется впустую?

Новые мгновенные снимки.
Еще одна давно ожидаемая возможность. Долгие годы владельцы систем IBM DS3000/4000/5000 вынуждены были мучиться с восстановлением данных из снапшота (невозможно сделать операцию rollback, вернее возможно, но очень “некрасиво”). И вот, новых снапшотов можно сделать не просто заметно больше, но и можно быстро “откатиться” из снапшота на исходном томе. Также появляется возможность использовать группы консистентности, а это очень полезно, когда данные одного приложения находятся на различных дисках:

image

Rollback в рамках группы консистентности также работает! Несомненным плюсом стала оптимизация операций копирования исходных блоков в рамках технологии Copy-on-Write. Если раньше для каждого снимка происходило копирование исходного блока данных, то сейчас копия делается только единожды. Это существенно снижает эффект от деградации производительности при использовании мгновенных снимков. Падение производительности для “классических” CoW снимков может составлять десятки процентов. Сейчас эта проблема должна быть решена, что позволит использовать снимки и в более нагруженных средах.

Поддержка технологии VAAI.
Многие рассматривают VAAI исключительно как средство повышения производительности в среде VMware, но я бы скорее делал бы упор не на скорость выполнения отдельных операций (хотя это, без сомнения, приятно), а на разгрузку хоста от “лишней” работы и разгрузку сети хранения. Клонирование виртуальной машины с использованием VAAI может быть закончится и не на много быстрее, но зато канал ввода-вывода между сервером и СХД будет загружен в разы меньше и наше клонирование не окажет пагубного влияния на остальную инфраструктуру (особенно если мы используем 1Gbit iSCSI). В рамках VAAI поддерживается – блокировка экстентов в VMFS, write zeroes (write same) и extended copy (клонирование VM, Storage vMotion). Время выполнения операций с VAAI и без оного (кликабельно):

image

Поддержка ALUA.
Наверное многим доставляли проблемы active/passive пути? А потом еще приходилось вручную возвращать диски на “свои” контроллеры после каждого сбоя. Благодаря ALUA (Asymmetric Logical Unit Access) об этих неприятностях можно спокойно забыть. Чтобы было более понятно, пара картинок. Вот как работает multipath в DS3500 сегодня:

image

А вот как он будет работать в новой прошивке:

image

 

 

 

 

 

 

 

 

Наибольшие преимущества от ALUA заметны в кластерной среде, когда время failover при проблемах на контроллере играет критичную роль. Поддержка ALUA есть во всех ключевых операционных системах.

Временные лицензии.
До настоящего момента было очень сложно оценить “полезность” дополнительного функционала систем DS3500. Если мгновенные снимки можно было попробовать, то репликацию проверить было фактически невозможно. Решение о покупке (с бюджетом, сопоставим со стоимостью контроллерного модуля)  нужно было принимать на основе обещаний, книжек или еще чего-то там. Теперь можно будет установить временную лицензию на 90 дней и проверить работу в своей среде, со своими приложениями. Указанных 90 дней, в принципе, должно хватить не только чтобы проверить функционал, но и для того чтобы заказать постоянные ключи и дождаться их прихода.

Вот такие замечательные новинки были представлены IBM для систем начального уровня. Я, честно говоря, ожидал немного большего, но и это уже очень и очень хорошо. Развитие систем не останавливается – будут и другие новшества, но позднее. Все, о чем я написал, будет доступно в прошивке, которая анонсирована на 15 июня. По факту, скорее всего, скачать ее можно будет на несколько дней позднее, но шанс попробовать все возможности уже в этом месяце безусловно есть!

48 комментариев:

  1. Спасибо, Андрей.
    Ваще вкусняшка получается, прадва, два года ждать пришлось с момента выхода.
    Ты про Point-in-Time подробней расскажи. Я скрин из презентации выкладывал, но в детали не вдавался http://vmind.ru/2012/06/06/ibm-ds3500dcs3700-priobretayut-podderzhku-vaai-i-alua/

    ОтветитьУдалить
  2. Ну вот, не зря покупали Engenio, как видите ;)

    ОтветитьУдалить
    Ответы
    1. Ну, как минимум, не похоронили хорошие железки! :)

      Удалить
    2. Ну, знаете, целый пост первоклассных новинок, по справедливости не называется "похоронили", а называется "активно работали".
      Желаю вам не скрипеть зубами по этому поводу, а признать очевидное. :) Ресурсы NetApp (денежные и интелектуальные) после покупки Engenio дали ей очень большой толчок к развитию.

      Удалить
    3. Да нет, я ничуть не скриплю :) NetApp молодцы!
      Для меня только не очень понятно зачем _сейчас_ нужно было выпускать полку DS4486 с довольно странным расположением 48ми дисков, когда в собственных руках уже давно держат 60ти дисковую систему в стандартном SBB форм-факторе. Могли бы в нее свои IOM воткнуть - было бы заметно интереснее для "емких" решений. Да и максимальный размер стека сократился бы на 4U.

      Удалить
    4. 1. 4486 была готова еще в прошлом году.
      2. 4486 это все же крайне нишевое и немассовый продукт (в ней поддерживается пока ровно один тип дисков) для узкого сегмента.
      3. Engenio и собственно сам NetApp это, все же, как я понял, просто две разных компании под общим сейчас топ-руководством. Взаимопроникновения продуктов в них не предполагается.

      Удалить
    5. 1. Ну так и Engenio чай не два дня назад купили - уже больше года прошло :)
      2. Вот именно это меня и удивляет - зачем делать "нишевое" решение, когда в кармане лежит отличная полка на 60 дисков (и там поддерживается вовсе не один тип дисков). Кстати, по нашей практике, интерес к системам с большим количеством ёмких дисков постоянно растет, поэтому иметь возможность поставить 60 дисков по 3ТБ куда заманчивее, чем всего 48.
      3. Может быть со временем изменится подход. Зачем кормить Xyratex, когда есть свои решения? :)

      Удалить
  3. diz: А ALUA сообщает хосту, какой из путей - "прямой"?

    ОтветитьУдалить
    Ответы
    1. За это должен отвечать софт MPIO. Если он знает про ALUA, то умеет отличать оптимальные пути от не оптимальных.

      Удалить
  4. а как воспользоваться этими ништяками? обновил все фирмвари на DS3524, установил тип хостовой операционной системы VMWareTPGSALUA, установил все патчи на ESXi 4.1, и все-равно в vsphere-клиенте для хранилища указано Hardware acceleration Unknown!
    Какие теперь политики Path Selection/Storage Array Type использовать для VMware 4.1?
    Нашел только для последней версии всферы 5 - тип массива VMW_SATP_ALUA.

    ОтветитьУдалить
    Ответы
    1. ALUA включается посредством VMW_PSP_FIXED_AP, подробности: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1022030
      и http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1011340
      По поводу поддержки VAAI в 4.1 пока ответить не готов.

      Удалить
  5. Прошил два массива, один DS3512, второй 3524. В итоге на DS3524 после удачной прошивки получили ошибку Insufficient Cache Backup Device Capacity и соответственно Write-Back Caching Disabled. На логических устройствах соответственно все перешло в состояние:
    • Write cache: Enabled (currently suspended)
    • Write cache with mirroring: Enabled (currently suspended)
    Само интересное что с сайта IBM из загрузок новая прошивка убрана.

    Это официальное:
    http://www-947.ibm.com/support/entry/portal/docdisplay?brand=5000008&lndocid=MIGR-5090862

    Вообщем думаем как все это дело исправлять

    ОтветитьУдалить
    Ответы
    1. Могу только повторить свои слова:
      "Да, к сожалению, это случается. Именно поэтому мы не рекомендуем обновлять систему, находящуюся в продуктиве, сразу после выхода новых версий прошивки, а выждать пару-тройку недель.
      К счастью проблема не критичная (а ведь бывало) - "problem does not cause data access or data loss issues"
      Файл с прошивкой один на все системы DS3500-DCS3700-DS3950-DS5000, внутри все есть и для DS3500.
      Интересно то, что для DCS3700 такой проблемы нет, а контроллеры очень сильно похожи."

      Удалить
    2. также прошил 3512 и 3524, на первой Insufficient Cache Backup Device Capacity, на второй все нормально. разница между ними в моем случае была в том, что 3524 не имела никакой нагрузки

      Удалить
    3. А включение/выключение системы ситуацию не решило?

      Удалить
  6. все конечно хорошо, поддержку VAAI добавили, а где брать драйвера для vSphere 4.1 ?

    ОтветитьУдалить
    Ответы
    1. Подозреваю что только на странице с апдейтом до vSphere 5 :(

      Удалить
  7. Для DS5000 есть что-то новое?

    ОтветитьУдалить
  8. Тем временем, вышла прошивка версии 7.83.22.00, которая решает как возникавшие проблемы с обновлениями, так и еще некоторые исправления найденных проблем.

    ОтветитьУдалить
  9. При переходе на 7.83.22.00 уже нарезанные LUN с данными не теряются?Прочитал реадми к прошивке,там не увидел ответа.То что сначала backup - это понятно,но к чему готовится хотелось бы понять заранее.

    ОтветитьУдалить
    Ответы
    1. Потери данных быть не должно (и я не сталкивался с тем, чтобы она случалась).
      Но это конечно не отменяет регулярность создания резервных копий радивым администратором!

      Удалить
    2. Спасибо,обнадеживает.

      Удалить
    3. обновлял с десяток DS35** потери данных не было

      Удалить
  10. А если нужен том размером менее 2 Гб, как будет происходит выделеник D-piece-ов?

    ОтветитьУдалить
    Ответы
    1. А если нужен том размером 1МБ? :)
      Нужно выбирать пушку размером с воробья, за которым охотитесь.

      Удалить
    2. Простой пример - кворумный диск для кластера - размер 3 Гб, больше не НУЖНО, как в этом случае?
      Я не троллю :) я хочу понять.

      Удалить
    3. Ну и что? Будет занято 4ГБ полезного пространства. IBM денег за "лишний" 1ГБ не вернёт :) Хотите маленькие тома - используйте классические RAID-группы.

      Удалить
    4. Добрался до 3524, проверил, действительно при создании тома на 3Гб, недоступное место уменшилось на 4Гб

      Удалить
  11. т. е. доступное:)

    ОтветитьУдалить
  12. Добрый день. Хотелось бы узнать у тех кто уже стал использовать Dynamic Disk Pooling, насколько в реальности идет потеря производительности в сравнении с тем же 5м рейдом, проводил ли кто тестирование , да и вообще поделитесь своими впечатлениями

    Спасибо.

    ОтветитьУдалить
    Ответы
    1. Логичнее все-таки сравнивать с RAID6, а не RAID5.

      Удалить
    2. Хорошо, если сравнивать с традиционным RAID6. Еще интересно сравнение с HP EVA, там вроде что то подобное используется или я не прав...

      Удалить
    3. С традиционным RAID6 будут небольшие отличия (причем как в одну, так и в другую сторону), в зависимости от числа дисков и типа нагрузки. Данные приведены выше.
      С VRAID в HP EVA не очень хорошо сравнивать - там RAID-группы почти в классическом смысле через RSS сделаны. VRAID не делает wide stripe систему, а собирает в некое подобие LVM несколько рейдов.

      Удалить
  13. diz: Андрей, а откуда данные по потере производительности в DDP? Особенно интересно, с чем (как) именно сравнивали 192х-дисковый DDP. Впрямую же нельзя сравнить с R6, т.к. его на 192 диска не сделать.

    ОтветитьУдалить
    Ответы
    1. 2diz: У производителя есть соответствующий документ :) Сейчас по диагонали пересмотрел, там однозначно не написано как берется RIAD6, но подозреваю, что аналогичное количество групп по 10 дисков.

      Удалить
  14. Я тут сравнил свободное пространство и такой вот сюрприз получил: array RAID6 24x2T (43TB чистого пространства) дал мне 40TB свободного, а DDP на тех же дисках только 31TB. Неужели DDP такой прожорливый как в свое время RAID5 на трех-четырех дисках. Как это понимать?

    ОтветитьУдалить
    Ответы
    1. И в чем смысл делать RAID-группу из 24х дисков? Чтобы неделю ждать окончания ребилда или чтобы потерять данные из-за того, что во время ребилда все вообще умрет? Кроме того, что значит "в свое время RAID5"? Сейчас, что, RAID5 на 4 дисках стал более эффективен? А ведь именно такого размера RAID-группы активно используются во многих системах.
      Обратите внимание, что Disk Pool это не RAID6 из 100-500 дисков, а распределение сравнительно небольших (8D+2P) групп по всем дискам. И не стоит забывать про резервирование spare пространства.

      Удалить
    2. Я имею ввиду то время, когда RAID6 еще не родился.
      Смысла конечно немного в RAID6 из 24х дисков (если не ошибаюсь максимум 30), но два RAID6 из 12 каждый (где 4 из 20 работают на резервирование) предоставляют больше, чем один DDP из 24х, где зарезервировано 2 диска.
      Приведу конкретные значения для полных DS3512+EXP3012.
      Общее пространство 43.6TB. Preservation = 3.6TB (2 диска). Свободное пространство 31.3TB. Куда делись и чем заняты 8.7TB не понятно.

      Удалить
    3. Поясняю.
      "пенальти" у DDP - 20% (RIAD-6 8D+2P). То есть, "в среднем", эффективность будет 80% полезного объема.
      "Preservation" это аналог hot-spare диска, только резервируется емкость, а не конкретные диски.
      Теперь считаем получаемый объем:
      43.6ТБ * 0.8 - 2*43.6ТБ/24 = 31.2ТБ

      Удалить
    4. Спасибо.
      То есть в крайнем случае можно вообще не использовать Preservation, аналогично RAID6 без hot-spare. И при выходе из строя одного или двух дисков данные еще не потеряны поскольку для каждого D-Stripe должен отрабатывать свой RAID6. Так ли это?

      Удалить
    5. Да, все верно, можно и не использовать - каждый волен сам вложить свою голову в гильотину.

      Удалить
    6. Андрей , поясните еще про мультипассинг.

      Мне казалось , что старая модель работы не передавала данные через второй контроллер вообще. Т.е. данные текли через основной путь только. Как только происходил обрыв основного канала или падение контроллера, данные сразу перебрасывались на резервный контроллер , а он уже складывал IO на LUN. Верно?

      + 2ое по нынешнему мультипассингу - данные будут бегать по обоим каналам на один лун ? Невозможно без блокировок в ФС. Проясните , не очень понятно.

      Удалить
    7. Правильно казалось - путь через "пассивный" контроллер блокируется. "Сразу перебрасывались" это очень образно - не так уж и сразу конечно, но перебрасывались.
      Сейчас ввод-вывод может идти через любой контроллер. Блокировки файловой системы тут ни при чем. ФС находится на уровень выше, чем драйверы MPIO. И раньше никто не мешал слать запросы через 4 пути к одному контроллеру, теперь можно через оба контроллера (не нужно, но можно).

      Удалить
  15. + еще прошу пояснить по снэпшотам.

    В чем была проблема восстановления на системах DS3000?

    Я про роллбэк на IBM DS3000/4000/5000.

    + как работает группа консистенции на снэпшотах. Не очень понятно.

    Заранее спасибо!

    ОтветитьУдалить
    Ответы
    1. Дмитрий, проблема была в том, что rollback из снапшота не было вообще :) Ну или, если быть более точным, то его можно было организовать через volume copy, но это довольно извращенный путь для такой простой операции.

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

      Удалить
    2. diz:

      Это просто название слегка вводит в заблуждение. Группа консистентности не гарантирует консистентность. Она гарантирует одновременность :) снэпшотов. За консистентностью придется заняться интегрированием снэпшотов СХД с приложением. Это можно сделать например при помощи Tivoli FlashCopy manager, либо при помощи средств резервного копирования в сочитании с VDS\VSS провайдером.

      Удалить
  16. Спасибо , понял.

    Т.е. в любом случаем ПО для консистенции и автоматизации необходимо.

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.