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

пятница, 6 марта 2015 г.

IBM FlashSystem - что за RAID внутри?






Раз я упомянул анонс новых систем  IBM FlashSystem 900 и V9000, то наверное стоит немного уделить внимания уникальной “фишке” этих систем - реализации отказоустойчивости.

В  FlashSystem используется RAID5 для защиты от сбоя всего модуля MicroLatency, но это далеко не единственная технология, обеспечивающая отказоустойчивость:
  • RAID5 защищает систему от сбоя модуля. В зависимости от числа модулей, конфигурация массива вальируется от 2D+1P+1HS, до 10D+1P+1HS. В системе всегда только один RAID массив для модулей, поэтому объем всех модулей должен быть одинаковым
  • RAID5 внутри каждого модуля защищает от сбоя отдельного чипа
  • Variable Stripe RAID внутри каждого модуля защищает от частичного сбоя чипов NAND
  • ECC на уровне чипа защищают от битовых и блочных ошибок
Кроме того, как и в любых системах на базе flash, присутствует зарезервированное пространство, которое используется когда очередная ячейка выходит из строя.

Совместное использование двух уровней RAID ("внутри” отдельных модулей и между всеми модулями) и носит фирменное название 2D RAID (two-dimensional RAID).

Благодаря такой многоуровневой защите можно минимизировать возникновение ошибок, приводящих к необходимости менять целый модуль MicroLatency. Кроме того, сохраняется возможность использовать RAID5 (а не RAID6) и не сталкиваться с повышенными рисками множественных ошибок (хотя объем самих модулей может достигать 5.7ТБ).   

Технология RAID “внутри” модуля MicroLatency была запатентована еще компанией TMS (где и родились предшественники нынешних FlashSystem -  тогда они назывались RamSAN) и носит название Variable Stripe RAID (VSR). Она позволяет не просто обеспечить отказоустойчивость при большинстве частичных сбоев внутри модуля, но и позволяет  большой срок службы модуля, а это, в свою очередь, снижает  стоимость, так как  не нужно закладывать дополнительные расходы на “лишние" замены в гарантийный срок.

Каждый MicroLatency модуль имеет внутри несколько чипов Flash и 4 FPGA контроллера, которые и реализуют VSR. Каждый из этих контроллеров, в свою очередь, “отвечает” не более чем за 20 чипов. Но RAID внутри модуля построен не на уровне чипов, а на уровне слоя (plane) в отдельных чипах (по 16 слоев в каждом чипе). Все это позволяет спокойно пережить сбой до 256 блоков перед тем как весь слой будет считаться сбойным. Чтобы модуль все-таки вышел из строя необходимо, как минимум:
  • признать сбойными  64 слоя
  • сбой 4 чипов в модуле целиком
Таким образом, разработчики FlashSystem постарались сделать все возможное, чтобы продлить жизнь отдельного модуля MicroLatency и обеспечить отказоустойчивость.

Отличительной особенностью VSR является:
  • RAID защищает не отдельный чип, а только слой чипа. Это позволяет гораздо эффективнее использовать модули, не производя лишних замен и перестроений массивов;
  • страйп не фиксирован в размере - в зависимости от состояния слоев, он может быть не в стандартной конфигурации 9D+1P, а 8D+1P, 7D+1P или 6D+1P.
Именно вариативный размер страйпа позволяет максимизировать объем полезного пространства в модуле, не “отбраковывая” рабочие части остальных чипов. Давайте посмотрим как это работает. В случае, когда мы используем обычный RAID-массив (пусть даже и на уровне слоя микросхемы), сбой в любом из слоев приведет к тому, что нам будет нужно исключить все такие же (еще рабочие!) слои остальных чипов, чтобы сохранить архитектуру массива:
Сбой на обычном RAID массиве

При использовании Variable Stripe RAID, нам достаточно перестроить страйп на меньшем количестве элементов:

Сбой в массиве Variabe Stripe RAID
Т.е. мы потеряем только малую часть одного чипа и не потеряем в скорости для имеющихся данных. Так как сбои чаще всего происходят не на уровне всей микросхемы, а на уровне отдельных блоков, мы получаем прекрасную возможность избежать лишних перестроений массивов, “отбрасывания” целых чипов из-за сбоя в одном слое и, разумеется, гораздо быстрее можем исправить проблему, так как в перестроении участвует лишь очень малая часть данных.

Кроме того, VSR работает “внутри” каждого модуля, не требуя для восстановления "перекачки" данных к центральному процессору или  FPGA, отвечающему за RAID на уровне системы. А это, в свою очередь, позволяет избежать деградации производительности при перестроении массивов, что для All Flash систем, где мы ожидаем получить гарантированный уровень производительности, очень важно.

И вот только в том случае, когда исчерпаны все “внутренние” ресурсы MicroLatency модуля по обеспечению отказоустойчивости, система использует RAID5 между модулями и задействует spare модуль для перестроения массива.

Что почитать:
IBM Redbooks про FlashSystem

Патент TMS на технологию VSR - здесь все очень подробно про VSR
Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

вторник, 3 марта 2015 г.

IBM FlashSystem 900 и V9000

Совсем недавно были анонсированы новые системы хранения All Flash Array от IBM - FlashSystem 900 и V9000. Странно, но, как я уже писал, линейка FlashSystem не попала в “программу переименования за миллиард”, хотя интегрированная система FlashSystem V9000 вот уж точно должна была бы стать частью портфеля Spectrum.

IBM FlashSystem 900 

В основе архитектуры IBM FlashSystem лежит идея о минимизации задержек на всем пути от внешнего интерфейса до чипа flash-памяти, на котором непосредственно и хранятся данные. Именно это позволяет получить очень хорошие результаты по производительности. Важно отметить, что когда мы говорим о производительности AllFlash систем, оценивать нужно не количество IOPs - их набрать не так уж и сложно, а в первую очередь о как можно низкой задержке (latency). Хорошим результатом можно считать результат меньше 1мс, но борьба уже идет за 500мкс и ниже.

В то время как многие другие производители активно используют стандартные процессоры в “ядре” своих СХД, IBM для FlashSystem продолжает выдерживать “железный” подход ("hardware only datapath”), когда вместо программного кода (пусть даже на разновидности  real time OS) активно используются FPGA и кастомизированные компоненты.

Примечательно, что в системе используются не стандартные SSD диски, а специальные модули (MicroLatency Modules), это позволяет избежать “лишних” интерфейсов, а следовательно и лишних задержек. В 900й серии использование таких модулей позволяет обеспечить латентность 90мкс на запись и 155мкс на чтение. При этом объем одного такого модуля может достигать 5.7ТБ В прошлой серии (840) использовались eMLC (enterprise multi-level cell) чипы, в новой же системе перешли на использование более дешевых, но усовершенствованных MLC чипов от Micron (IBM Enhanced MLC). Смешно, но здесь машина IBM по созданию акронимов нашла на камень - не так уж просто будет объяснить клиентам чем eMLC отличается от E-MLC, поэтому наверное решили “Enhanced” в названии оставить без сокращений. :)

Хотя FlashSystem 900 и имеет фиксированную конфигурацию (только один модуль), но обладает необходимыми возможностями, для того, чтобы использовать систему для tier-1 приложений:
  • обновление микрокода без остановки (не требуется даже снижать нагрузку)
  • возможность заменить на ходу любой из компонентов системы
  • избыточность всех компонентов
  • шифрование данных (AES-XTS 256) без потери производительности
Полезная емкость системы варьируется в зависимости от объема и количества используемых MicroLatency модулей. Минимальный полезный объем - 2.4ТБ, а максимальный - 57ТБ. Важно помнить, что смешивать модули разного объема в одной системе нельзя, поэтому стоит аккуратнее просчитывать необходимые перспективы расширения.
IBM FlashSystem 900 back

Для подключения СХД к серверам можно использовать различные интерфейсы:
  • Fibre Channel (FC) - 8*16Gbit  или 16*8Gbit 
  • Fibre Channel over Ethernet (FCoE) - 16*10Gbit
  • iSCSI - 16*10Gbit
  • Infiniband - 8*40Gbit (QDR)
Все интерфейсные карты в системе должны быть одинаковыми и “смешивать” протоколы в рамках одной системы нельзя.

Декларируется, что FlashSystem 900  может обеспечить до 1.1 миллиона случайных операций чтения 4КБ блоков и до 10ГБ/сек поток на чтение данных. Для операций записи (100% random) - 600.000 IOPs и 4.5ГБ/сек.

Результатом гонки за минимизацией задержек стало полное отсутствие таких привычных для систем энтерпрайз-класса "фишек" как мгновенные снимки, репликация, компрессия, thin provisioning. Если какие-то из этих возможностей действительно необходимы, то у заказчика есть два пути: подключить FlashSystem 900 к своей системе виртуализации СХД (это  может быть например SVC или V7000), либо приобрести уже интегрированную систему FlashSystem V9000. 


IBM FlashSystem V9000
По сути это своего рода гибрид из IBM SVC и FlashSystem 900, но это именно гибрид, а не просто две системы объединенные общей фронтальной заглушкой, как могло бы показаться с первого взгляда. Если мы подключаем FlashSystem к SVC, то мы должны управлять двумя системами, в то время как для V9000 мы имеем единую систему управления.

Во-первых V9000 позволяет расширяться как “вертикально” - добавив до 4х storage enclosures (до 57ТБ каждый), так и “горизонтально” - доведя количество контроллеров V9000 с двух до восьми (4 системы V9000 в кластере). Такое расширение позволит получить до 456ТБ полезного пространства исключительно на Flash. А если учесть возможности RealTime Compression, то мы получим уже 2.2ПБ полезной емкости. И это всего в 34U - достаточно одного(!) серверного шкафа, чтобы вместить весь этот ураган производительности и обеспечить такой объем. Но и это еще не все - можно использовать V9000 и как обычный виртуализатор СХД - все-таки это и SVC тоже, а значит можно к нему подключить имеющиеся системы и использовать на них такие возможности как thin provisioning, снапшоты и многие другие. 

Кроме того, поддерживается репликация между V9000 и системами SVC, V7000 - можно строить катастрофоустойчивые решения на базе AllFlash системы IBM. По понятным причинам (полку с Flash модулями нельзя поделить между площадками) не поддерживается конфигурация распределенного кластера (streched cluster).

Конечно, программная “прослойка” между FlashSystem и серверами не обходится даром, поэтому мы вынуждены заплатить латентностью, но плата эта не так уж велика - мы все равно получаем 200мкс на чтение, а это действительно очень мало. Кроме того, за счет использования "горизонтального” масштабирования мы можем получить до 2.5 миллионов IOPs  и поток до 19.2ГБ/сек (блоками по 128КБ). А за счет поддержки QoS в V9000 можно гарантировать приложениям требуемый уровень производительности дисковой системы.

Таким образом, FlashSystem 900 нацелена на тех заказчиков, которым нужна экстремально высокая производительность и они готовы пожертвовать программным функционалом систем enterprise-уровня (но хотят сохранить enterprise уровень отказоустойчивости и управляемости). Интегрированная система FlashSystem V9000 ориентирована на заказчиков, которым требуется не только производительность, но и возможность расширить систему, получить богатый программный функционал и возможность защитить данные с помощью репликации. Кроме того, V9000 может быть интересна тем, кто еще не имеет enterprise СХД в своем ЦОД, рассматривает возможности консолидации своих дисковых систем за счет виртуализации.

С нетерпением жду результатов SPC - IBM любит эти тесты. Как раз недавно неожиданно отметились HDS со своей системой VSP G1000, показав отличный результат в 2М IOPs при цене 1$ за IOPs. Вот только чтобы достигнуть цену в 1$ за IOPs пришлось дать почти 60% скидку на железо, зато теперь в лидерах рейтинга.
Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!