СХД начального уровня от Lenovo - S2200 и S3200

Компания Lenovo недавно представила две новые дисковые системы S2200 и S3200. Рассчитаны они, прежде всего, на малый бизнес. Конкуренция на этом рынке довольно активная - среди наиболее активных игроков HP с системами MSA, Dell с MD3, NetApp E2700 и FAS2500, EMC VNXe, IBM V3700 и целый ряд B-брендов.

Если посмотреть на характеристики объявленных новинок, то мы увидим классическую архитектуру двухконтроллерного массива, который масштабируется вертикально (за счет добавления дисковых полок). Для S2200 максимальное количество дисков составляет 96 (контроллерный модуль и 3 полки по 24 диска), для S3200 максимум можно подключить 192 диска (контроллерный модуль и 7 полок по 24 диска). Если использовать полки с дисками 3.5" (по 12 дисков на полку), то максимальное число дисков будет 48 и 96, соответственно.

Технические подробности, сравнение систем друг с другом, а также с аналогом от HP - в полной версии статьи по ссылке.

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

Новый лидер от HP - 3PAR 20000

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

На прошедшей конференции HP Discover была объявлена новая high-end система HP 3PAR 20000 (модель 20800 поддерживает и ssd, и обычные диски, а модель 20850 - только ssd). По сравнению с 3PAR 10000, изменений довольно много (в ознаменование этого и номер модели поменялся в 2 раза), система стала не только заметно производительнее, а также избавилась от рудиментарного fibre channel в качестве интерконнекта между контроллерами и дисковыми полками. С учетом того, что "десятитысячник" уже давно просился на покой, я даже немного удивлен, что этот анонс произошел сейчас, а не в прошлом году.

Некоторые подробности про две новые системы по ссылке.

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

Data Ontap 8.3 GA - новости и изменения

Я совсем недавно уже писал про одно из нововведений в cDOT 8.3 - поддержку MetroCluster, но считаю нужным упомянуть и другие возможности, которые пользователи получат в новой версии. Список изменений весьма обширен - более 40 из 90 страниц отведены перечислению именно новых возможностей.

Что первым бросается в глаза? Конечно система управления - теперь System Manager интегрирован в Data ONTAP! Больше не нужно устанавливать на компьютер приложение, мучаться с версиями Java - достаточно открыть браузер, набрать адрес и после этого мы получаем полноценную систему управления (на HTML5). Уверен, это это придется по душе очень многим админам!

Еще одна приятная возможность для администратора - можно сильно упростить жизнь за счет использования 'network subnet'. Вместо того, чтобы назначать каждому логическому интерфейсу (LIF) конкретный адрес, администратор назначает пул адресов для широковещательного домена (broadcast domain). А уже при создании LIF, ему присваивается адрес из пула. Такой подход может быть крайне удобен в больших и часто меняющихся инфраструктурах. 

Использование IP Spaces для изоляции SVM - еще одна возможность для построения развитой инфраструктуры. IP Spaces позволяют получать доступ к кластеру из несвязанных подсетей - даже если клиенты имеют одинаковые адреса:

В данном случае, клиенты в IPSpace A физически отделены от клиентов IPSpace B, но работают с одним кластером. Эта возможность актуальна для компаний, которые предоставляют системы NetApp в аренду "по кусочкам".

Миграция LUN - администратор должен был очень внимательно подходить к процессу планирования системы с самого начала - если уж создали LUN, то перемещать его потом даже внутри системы будет не слишком просто и потребуется остановить доступ к данным. Теперь можно спокойно перемещать LUN внутри SVM без прерывания доступа к данным. Миграция происходит совершенно прозрачно для пользователя и работающих приложений. Далеко не всегда можно заранее спланировать рост нагрузки и требования, поэтому возможность онлайн миграции крайне важна для обеспечения эффективности.

В больших конфигурациях, можно получить слишком большое количество путей от хоста до LUN - это является проблемой управления, но может влиять и на производительность. Для того, чтобы поддержать число путей в рамках разумных границ, теперь используется технология Selective LUN Mapping (SLM) - хост видит только нужные пути до системы, а лишние спрятаны (но могут быть включены при необходимости. Коллеги писали об этом совсем недавно (есть примеры команд).

Автоматизация процесса обновления ПО. Еще одна "крутая фишка". В самых разных ситуациях я сталкивался с тем, что система работает, на ней наблюдаются какие-то проблемы (не критичные, но малоприятные). Спрашиваешь, а почему не обновить на новый микрокод - там же есть исправление как раз вашей проблемы? "Мы бы с удовольствием, но для нас очень проблематично выделить время на обновление и столкнуться с угрозой остановки сервиса. Кроме того, это очень сложная процедура." И это длится год за годом!  Теперь такая проблема больше не должна волновать - администратору достаточно всего трех команд, чтобы запустить процесс обновления:

cluster image package get
cluster image validate
cluster image update 

После этого система начнет процесс обновления (все происходит онлайн - данные доступны, пользователи ничего не замечают). Контролировать процесс можно командой:

cluster image show-update-progress

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

Обновлять систему стало легко, но так ли просто обновить несколько кластеров сразу на нескольких площадках, объединенных в единую инфраструктуру? Далеко не факт. Но если мы используем репликацию (Snap Mirror), то для ее  нормального функционирования нужно было поддерживать одинаковые версии и всегда обновлять сначала "получателя" данных. В случае, если репликация идет в обе стороны, приходится останавливать SnapMirror на время апгрейда. Теперь у нас есть version-flexible SnapMirror, благодаря которому можно спокойно обновлять любой из узлов без остановки репликации. Еще одна задача администрирования решена! Для поддержки распределенной отказоустойчивый инфраструктуры это очень важное нововведение.

Раз уж затронули SnapMirror, то теперь при передаче данных используется компрессия, что позволяет снижать нагрузку на сеть и каналы связи. Не могу сдержаться - FalconStor NSS умел так делать еще лет 10 тому назад! :) В любом случае, это еще один плюс в копилку.

У заказчиков, использующих SnapVault появлиась возможность восстанавливать данные на уровне отдельных файлов (технология On-Demand Data Management). Данные доступны пользователю сразу и он может с ними работать, пока происходит копирование на основную систему.

Перейдем к производительности и эффективности хранения.

Больше не записываем нули на диски! Для томов с включенной дедупликацией, в онлайне находятся блоки из одних нулей и они не записываются на диски (Inline zero write detection and elimination). В VMware, например, мы создаем eager zeroed диски, чтобы обеспечить неизменный уровень производительности, но из-за архитектуры WAFL, нам нет нужды записывать нули на диски. Кроме того, существуют и другие специфические задачи, когда за счет исключения нулевых блоков, мы получаем заметный прирост производительности.

Еще одно направление оптимизации - All-Flash Optimized personality.  Для All-Flash систем мы отказываемся от всех алгоритмов по оптимизации работы с обычными дисками, так как все это бесполезно для SSD дисков. Как следствие, производительность системы возрастает, а там, где борьба идет за микросекунду, любая оптимизация может быть критичной. AFF personality доступна только для FAS80xx и не позволяет использовать обычные диски - только SSD.

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

Следить за производительностью стало удобнее - собирать статистику можно уже не на уровне агрегата, а на уровне отдельного тома (qos statistics volume show).

Что касается эффективности, то самая большая проблема в младших системах (с небольшим числом дисков) это объяснить заказчику, куда делось все то дисковое пространство, за которое он заплатил. Для каждого контроллера отдельные диски выделим под root (рекомендуется RAID-DP) плюс еще пара дисков в резерв (spare). И вот, в самой младшей системе от 12 дисков осталось 2 под данные.

Да, конечно, можно немного "поколдовать" и улучшить ситуацию (здесь RAID4, там один spare диск) - в результате, что-то подходящее можно собрать. Но, во-первых, это нужно делать руками (и игнорировать предупреждения системы), а, во-вторых, даже в этом случае, мы получаем не слишком-то большой объем. Поэтому систему из 12 дисков сложно использовать как active-active, так как на одном из контроллеров будет всегда слишком мало дисков. Наконец-то, в Data ONTAP 8.3 появилось решение - Advanced Disk Partitioning (ADP).  После метрокластера, мне кажется, это вторая по значимости новость - можно на одних и тех же физических дисках размещать два агрегата - для root и для данных. Причем, для root мы можем собрать RAID-DP и два spare "блока", а для данных  один резервный блок. Теперь конфигураций с 12ю дисками можно уже пользоваться "из коробки" - полезного пространства стало гораздо больше.

И даже для системы с 12 дисками можно использовать active-active режим работы (полезная емкость конечно ниже, но мы можем делить нагрузку между контроллерами):

ADP очень хорошо работает и для AFF конфигураций - стоимость SSD дисков довольно высока и "выбрасывать" их на создание рутового агрегата довольно расточительно. Благодаря ADP, AFF система будет показывать лучшую экономику, при сравнении с конкурентами, чем ранее.

И третьим плюсом от ADP является оптимизация нагрузки на SSD диски в FashPool - на одних и тех же дисках можно создать агрегаты для каждого из контроллеров. Широкий страйпинг позволит обеспечить лучшую производительность системы.

Advanced Disk Partitioning можно использовать на младших системах (22хх) для совмещения root и data агрегатов на одних дисках, всех AFF конфигурациях и для всех систем в FlashPool.

В версии 8.3 также существенно увеличен максимальный объем FlashPool - рост в 4 раза:

FAS8080 EX	144 TiB
FAS8060	72 TiB
FAS8040	48 TiB
FAS8020	24 TiB
FAS25xx	16 TiB

Я кратко описал только часть тех новых возможностей, которые стали доступны после выхода версии 8.3 Data ONTAP. Кто-то конечно мог уже попробовать и оценить многие из перечисленных возможностей, обновившись еще на 8.3 RC1 версию, но сейчас, когда GA уже здесь, можно планировать апгрейд и тем, кто не решался использовать ранние версии. Безусловно, очень важно внимательно изучить документацию перед апгрейдом - всегда есть нюансы.

Почитать на тему:

Clustered Data ONTAP 8.3 Release Notes
Clustered Data ONTAP 8.3 Network Management Guide
Clustered Data ONTAP 8.3 SAN Administration Guide
Clustered Data ONTAP 8.3 Physical Storage Management Guide

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

Sandisk выходит на новые рынки

Компания Sandisk, которая всем хорошо известена как производитель флешек и SSD дисков, на днях представила свои новые продукты, предназначенные на этот раз вовсе не для домашнего использования. Новинками являются внешние системы хранения InfiniFlash IF100, IF500 и IF700.

И первое, то бросается в глаза, это конечно прекрасный дизайн передней панели системы InfiniFlash IF100:

Разве может быть что-то круче? Разве что только новый IBM z13.

IF100 это не только самостоятельный продукт, но и исходный блок для систем IF500 и IF700. Фактически IF100 это просто JBOF (Just a Bunch Of Flash) - никакого интеллекта, только мощь, только объем. Всего в 3U размещается половина петабайта (512ТБ или 256ТБ - на выбор)! Помимо фантастической плотности, неоспоримым преимуществом является  потребляемая мощность - меньше 0.5кВт. Вот уж точно отличная возможность экономить на счетах за электричество! Система InfiniFlash построена на 64 картах с Flash памятью проприетарного формата, каждая карта имеет объем 8ТБ и является энергонезависимой (выключения питания не страшны).

Система имеет 8 независимых SAS портов для подключения серверов. Традиционно для внешних систем, зарезервированы основные компоненты, такие как вентиляторы и блоки питания. Все основные компоненты могут быть заменены без отключения системы (горячая замена). Однако, что касается самой flash памяти, то никаких средств резервирования нет - только горячая замена отдельных модулей. Пользователь должен сам заботиться о том, чтобы в случае сбоя одной карты или всего JBOF, данные не пропали. 

Так как IF100 предназначен прежде всего для Hadoop, такое “пренебрежение” отказоустойчивостью оправдано, но есть и одно "но". Производитель декларирует стоимость порядка 1$ за ГБ. Но, если мы будем защищать данные стандартными средствами, нам потребуется 3 копии, а это уже будет 3$ за ГБ. Звучит конечно не так страшно, но давайте вспомним, что у нас каждая система имеет объем 512ТБ, а это уже 1.5 миллиона $. Как говорил крот в небезызвестном мультфильме, “а в год получается не так уж и мало”. 

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

Давайте посмотрим на производительность. Декларируется величина не ниже 780.000 IOPs (данных о времени отклика не приводится - только “меньше 1мс"), хотя в некоторых материалах я видел и другие цифры - до 1 миллиона IOPs (возможно такие значения достигаются в каких-то "хитрых" тестах). С одной стороны, это довольно хороший результат, но, с другой стороны, если мы опять учтем объем системы, то величина совсем не такая уж и фантастическая - меньше 2IOPs  на ГБ. Для обычного SSD можно получить в разы и десятки раз более высокие показатели. При этом, номинальный трансфер составляет 7ГБ/сек и это тоже далеко не чудеса производительности - на рынке есть системы, которые показывают результаты лучше.

Если к JBOF IF100 добавить интеллекта, то получится уже IF500 - внутри нее работает InfiniFlash Operating System (OS), которая позволяет строить горизонтально расширяемую систему. IF500 уже полноценная СХД, которая обеспечивает унифицированный доступ (блочный, файловый, объектный - все на базе Ceph), а кроме того включает традиционные “enterprise” возможности - мгновенные снимки, репликацию и thin provisioning. В комплект IF500, помимо JBOF IF100, входит и пара серверов, на которых выполняется InfiniFlash OS.

Также анонсирована система IF700, которая нацелена скорее на классические бизнес-приложения и включает SanDisk ION Accelerator, для создания высокопроизводительной системы с блочным доступом (от 128ТБ до 512ТБ). Защита данных, как и в IF100, вновь отдается на откуп прикладному приложению. 

Что ж, очень интересное начало! Big data рынок растущий и новые решения будут востребованы. Некоторый скепсис вызывает производительность - здесь я вижу только одну причину странных величин производительности в расчете на объем: в первом поколении систем старались сделать работающую систему с минимально достаточными для узкой задачи параметрами (hadoop). А когда (и если) получится преодолеть системные ограничения новой платформы, начать более активно выводить InfiniFlash и на другие рынки. Пока мне действительно сложно представить новое детище Sandisk где-то вне big data.

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

IBM FlashSystem 900 и V9000

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

 

В основе архитектуры 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ТБ. Важно помнить, что смешивать модули разного объема в одной системе нельзя, поэтому стоит аккуратнее просчитывать необходимые перспективы расширения.

Для подключения СХД к серверам можно использовать различные интерфейсы:

• 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 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% скидку на железо, зато теперь в лидерах рейтинга.

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

VMware Virual Volumes (VVols)

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

Наверняка, за прошедшее с момента первого упоминания время, все не по одному разу слышали что VVols это хорошо, удобно и круто. Но почему?

Подход VMware к развитию инфраструктуры виртуализации понятен - "виртуальный" администратор (он, конечно вполне реальный, но занимается только виртуализацией) должен иметь возможность максимально просто, удобно и без привлечения других сотрудников разворачивать необходимые бизнесу сервисы. И основной упор должен быть именно на "без привлечения других" - именно это чаще всего и будет "бутылочным горлышком" в скорости развертывания. А следовательно, участие администраторов, отвечающих за системы хранения и сетевую инфраструктуру, должно быть минимальным - желательно ограничиться только начальной настройкой.

Можно конечно все функции управления "загнать" в vCenter с помощью плагинов, тогда управлять всем оборудованием можно будет из "одного окна". Это вполне удобно, когда у нас небольшая (и сравнительно простая инфраструктура), но как только появляется несколько систем хранения, знаний специалиста по VMware может оказаться недостаточно и, хотя настроить все можно из одной консоли, но занимаются этим снова разные сотрудники.

Помимо того, чтобы упростить развертывание (и обслуживание) виртуальных машин, стоит еще и задача не вносить в гипервизор излишний функционал, который утяжеляет и усложняет работу. Часть функционала дисковых систем можно благодаря VAAI (vStorage APIs for Array Integration). В частности, поддержка Clone Blocks/Full Copy/XCOPY примитива позволяет копировать данные на уровне СХД, не передавая их гипервизору и обратно на массив. Несмотря на все плюсы, VAAI не дает существенных преимуществ как в момент непосредственного развертывания виртуальных машин, так и не слишком помогает в управлении жизненным циклом системы в разрезе конкретных виртуальных машин.

Что сейчас происходит при создании виртуальной машины? Администратор выбирает подходящий datastore - не только исходя из свободного объема, но и в зависимости от того, какая нагрузка будет на виртуальной машине, насколько уже сейчас нагружен тот или иной datastore, а также он должен принимать во внимание поддерживаемый функционал системы хранения. Если датастор еще не создан, то мы обращаемся к администраторам СХД, которые создают LUN, настраивают доступ к хостам. Не исключено, что придется также вносить изменения в сеть хранения (зонирование). После развертывания виртуальной машины, нам нужно следить за производительностью дисковой системы. Можно настраивать QoS на разных уровнях и, скорее всего, также потребуется привлечь администратора СХД.

Можно было бы предположить экстремальное решение - создать достаточно большое число LUNов и распределить по ним виртуальные машины. Ведь чем больше будет число созданных LUN, тем большую гибкость мы получаем! Идеальная ситуация - создать по одному LUN для каждой виртуальной машины, тогда мы можем очень гибко управлять ими. С другой стороны, повышается overprovisioning и управлять системой с большим числом разделов - это настоящий ад для администратора! Да и ESXi имеет ограничение на число подключаемых LUN, что тоже требуется учитывать при планировании системы.

Таким образом, требовалось создать такое решение, которое бы позволило:

• снять нагрузку с администраторов СХД (создал раздел из SSD дисков, раздел из SAS дисков и раздел из NL SAS дисков - и дальше пусть специалисты по виртуализации сами с ними разбираются)
• обеспечить максимальную гибкость для управления каждой из виртуальных машин
• автоматизировать большинство операциq
• не перегружать гипервизор (ESXi) и систему управления (vCenter) аппаратно-зависимыми модулями
• получить унифицированное решение, которое не "привязано" к конкретным системам хранения

Виртуальные разделы (Virtual Volumes, VVols) и были предложены в качестве такого решения. По сути своей, VVol это еще один уровень абстракции, который отделяет систему хранения данных от гипервизора. Давайте в этом разрезе и посмотрим на основные компоненты решения.

Прежде всего, сам виртуальный раздел Virtual Volume (VVol) - это своего рода контейнер, в котором хранится информация, необходимая виртуальной машине - это может быть конфигурация, swap или непосредственно данные, которые мы привыкли обычно видеть в vmdk файле. Любой элемент виртуальной машины, который ранее требовал создания файла в vmfs (или nfs), теперь является отдельным виртуальным томом. Каждая виртуальная машина включает несколько VVols, количество которых меняется, в зависимости от состояния машины (наличия снимков и т.п.):

• 1 VVol для конфигурации виртуальной машины (метаданные - .vmx файл, дескрипторы виртуальных дисков, логи и т.п.)
• 1 VVol для каждого виртуального диска (.vmdk)
• 1 VVol для swap (если используется)
• 1 VVol для снапшота каждого диска + 1 VVol для снимка памяти

VVol это только некий виртуальный контейнер - это не LUN (по крайней мере, он им не обязан быть) и не точка монтирования NFS - реализация VVol на уровне системы хранения остается в руках производителя СХД. Для гипервизора же это просто абстрактный объект с данными, с которыми можно работать по SCSI протоколу, как и с любыми другими данными, находящимися в vmdk файле.

Первое, что нам нужно - научиться создавать и управлять виртуальными томами. Управлять созданием и размещением VVols должен не каждый отдельный хост ESXi, а сервер управления vCenter Server, поэтому слой управления (control plane) логично отделить от канала передачи данных (data plane). Кроме того, система управления виртуальными томами может быть реализована каждым производителем систем хранения по-своему, т.е. она должна быть "вне" vCenter Server. Этот программный компонент, обеспечивающий управление виртуальными томами, носит название VASA Provider. В его задачи входит в том числе предоставление информации о топологии и текущем состоянии СХД, а также о поддерживаемых возможностях системы хранения. Посредством vSphere APIs for Storage Awareness (VASA) данные передаются в vCenter Server и хосты ESXi. VASA Provider может быть реализован как “внутри" системы хранения (HP 3Par), так и в виде отдельной виртуальной машины (NetApp FAS). 

Следующей задачей является обеспечение доступа гипервизора (ESXi) к данным, которые находятся внутри VVol. С одной стороны, есть изначально реализованный механизм DataStore, с которым все привыкли работать. С другой стороны, у нас есть множество VVols, которые можно сгруппировать по используемым возможностям системы хранения. Например, одни тома могут быть созданы на дисках SAS и для них настроена аппаратная репликация, другие тома созданы на дисках SSD и для них репликация не используется. Логично объединить такие VVol в группы (Storage Containers) -  это еще один важный термин в новой системе. По своим параметрам Storage Container очень напоминает уже привычный LUN или раздел NFS - там хранятся данные наших виртуальных машин.  Однако, Storage Container отличается тем, что он не является жестко ограниченным ресурсом (как LUN), а представляет собой пулл “грязного” (raw) дискового пространства, на котором можно создать нужные VVols. VASA Provider сообщает всю необходимую информацию серверу vCenter и хостам ESXi. Хост ESXi не может получить доступ к Storage Container через SCSI команды или NFS RPC - вся информация передается только через VASA провайдер. Когда мы хотим создать VVol для виртуальной машины, мы должны сначала подключить новый DataStore, для которого vCenter "предложит" нам (если мы конечно все правильно настроили) предварительно созданный Storage Container. За создание Storage Container отвечает администратор системы хранения, скорее всего, он их создаст несколько (зачем - чуть позже). Всю остальную работу по распределению ресурсов уже берет на себя vCenter и аднимистратор виртуальной инфраструктуры.

Как же хост может получить доступ к данным в VVol? Чтобы реализация в гипервизоре не зависела от реализации VVol в системе хранения, нужен универсальный механизм реализации канала передачи данных. Protocol Endpoint (PE) является своего рода proxy для перенаправления операций ввода-вывода от гипервизора на конкретный VVol. PE это либо специальный LUN (если VVol находится на СХД, подключенной через блочный протокол), либо точка монтирование NFS (если VVol находится на NFS системе хранения). Один PE может служить прокси для множества виртуальных томов.

Обратите внимание, что уже это существенно упрощает администрирование - нам достаточно подключить только один LUN на сервер ESXi, чтобы получить возможность управлять множеством VVols. Protocol Endpoint поддерживает multipath для блочных протоколов, но для NFS поддержки multipath пока нет (как нет и поддержки NFS v4.1). Для NFS отказоустойчивость можно реализовать за счет увеличения числа PE для данного Storage Container. Хотя PE может отвечать только за одну систему хранения, но на одной СХД мы можем создать столько PE, сколько нам необходимо, при этом подразумевается, что каждый PE обеспечивает доступ ко всем Storage Container на данной системе хранения, хотя это и не является обязательным требованием.

Так как количество используемых Protocol Endpoint существенно меньше, чем количество подключаемых LUN (до перехода к использованию VVol), технически мы можем подключить к нашей инфраструктуре заметно больше дисковых ресурсов, что может быть актуально в свете повышения максимального количества хостов в кластере vSphere 6.

Все перечисленные компоненты (VVol, Storage Container, VASA Provider, Protocol Endpoint) обеспечивают управление виртуальными томами и доступ к данным на них. С их помощью мы можем упростить задачу распределения пространства на СХД для виртуальной инфраструктуры.

Какие еще плюсы мы можем получить от нового уровня абстракции? Благодаря VASA Provider, мы знаем о поддерживаемых возможностях системы хранения данных для VVols, размещенных на тех или иных Storage Containers, а значит мы можем использовать эту информацию при размещении новых VVols. Создавая Storage Container, администратор системы хранения фактически определяет Storage Capability - те возможности СХД , о которых VASA Provider сообщает серверу vCenter. Они могут включать в себя такие параметры как: уровень RAID, поддержку thin provisioning, тип используемых дисков, поддержку zero detect, аппаратную поддержку снапшотов и т.д. Все эти атрибуты затем могут быть использованы администратором виртуальной инфраструктуры для определения политик - Storage Policies. При создании виртуальных машин, администратор выбирает, какую политику применить для размещения дисковых ресурсов. В ходе жизненного цикла виртуальной машины также учитываются назначенные политики. Все это и составляет систему управления виртуальными машинами на базе политик (Storage Policy Based Management, SPBM). 

Итак, как выглядит процесс "запуска" системы для использования VVols:

• настраиваем VASA Provider (либо интегрирован в СХД, либо отдельная виртуальная машина)
• администратор СХД выделяет ресурсы (Storage Containers) на системе хранения
• ищем существующие Protocol EndPoint (создаются вместе с Storage Container или VASA Provider делает это автоматически для нас)
• создаем новые DataStore для созданных Storage Containers
• настраиваем политики (Storage Policies)
• создаем новую вирутальную машину

Конечно, VVol на начальном этапе развития не лишены определенных недостатков. Пока еще:

• нет поддержки NFS v4.1
• нет поддержки Storage DRS
• нет поддержки Site Recovery Manager (SRM)

Суммируем плюсы от испльзования VVols:

• Единая терминология, независимо от способа подключения СХД
• Возможность делегировать СХД  выполнение многих операций над дисками виртуальной машины
• Возможность предоставлять сервисы СХД на уровне отдельной виртуальной машины
• Управление ресурсами на основе политик
• Легкость администрирования

Все это, безусловно, начинает играть роль, когда у нас появляется достаточно сложная инфраструктура. Начинать "играть" в VVols, имея одну систему хранения с одним типом дисков и 3-4 сервера, на мой взгляд, можно только для самообразования. Практической пользы вы, уверен, на такой конфигурации не увидите.

Ключевые термины и сокращения:

• Virtual Volume (VVol) - виртуальный раздел/том
• VASA Provider - реализация слоя управления для VVol
• vSphere APIs for Storage Awareness (VASA) - программный интерфейс для унификации взаимодействия с СХД
• Storage Container - контейнер, в котором создаются VVols
• Protocol Endpoint (PE) - прокси для доступа к самим данным
• Storage Capability - поддерживаемые возможности СХД, которые можно использовать в создаваемых политиках
• Storage Policies - политики, назначаемые виртуальным машинам, на основе которых происходит выбор подходящих дисковых ресурсов
• Storage Policy Based Management (SPBM) - управление ресурсами хранения на основе политик

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

IBM потратит ярд на системы хранения

В IBM заявили, что готовы в ближайшие 5 лет вложить миллиард $ на разработку Software Defined Storage нового поколения. Инвестиции будут направлены на R&D в области облачных и объектных систем хранения, а также интеграцию с открытыми технологиями (OpenStack).

Если уже представители IBM заявляют, что "traditional storage is inefficient in today’s world", наверное действительно пришла пора перемен. Пока, уж не знаю зачем, решили переименовать все (почти все) системы хранения. Конечно, теперь все поймут, какая IBM супер-современная компания! :)

Встречайте - IBM Spectrum. На сегодняшний день это единственное изменение, которое случилось с IBM System Storage по случаю смены парадигмы.

Хотя, я все-таки немного сгустил краски - в IBM решили наконец превратить XIV в программную платформу. Если бы этот шаг был сделан через год после выпуска Gen3, вот это был бы настоящий взрыв! А сейчас этим уже почти никого не удивишь, тем не менее, вот он - Spectrum Accelerate.

Остальные "новинки":

Spectrum Virtualize = San Volume Controller (SVC)

Spectrum Scale = General Parallel File System (GPFS)

Spectrum Archive = Linear Tape File System (LTFS)

Spectrum Control = Storage Insights

Spectrum Protect = Tivoli Storage Manager

Нового названия не нашлось для старичка DS8000, хотя он самый что ни на есть Software Defined Storage еще с незапамятных времен. Также почему-то в стороне остались All Flash массивы (Flash System).

За программной реализацией XIV, на мой взгляд, есть реальная сила, но будет ли этого достаточно, чтобы вытянуть весь Spectrum на новый уровень - большой вопрос.

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

ASIC или процессор + софт?

Сразу две интересные заметки появились от ведущих производителей систем хранения - NetApp и  HP:

Better RAID Through Software: An In-Depth Look at the NetApp Firmware Parity Engine for E/EF-Series Systems

The 3PAR ASIC

Первая статья описывает текущую ситуацию в системах NetApp E-series (бывший LSI/Engenio). После многолетнего использования ASIC для расчета контрольных сумм, сейчас нагрузка по расчету данных для RAID перенесена в центральный процессор. С одной стороны, это конечно упрощает дизайн системы, кроме того, мы все прекрасно знаем, что производительность современных процессоров сделала огромный рывок (и продолжает "рвать" :) Поэтому многие компании спокойно используют программные решения (стоит упомянуть в первую очередь конечно различные реализации Software Defined Storage).

С другой стороны, в NetApp столкнулись с проблемой производительности (СХД может создать поток, превышающий возможности процессора). Можно говорить что это большой плюс ситем NetApp - загрузить процессор это тоже достижение! Справедливости ради нужно сказать, что в NetApp используется не совсем программное решение,  а аппаратные возможности процессоров Intel (Crystal Beach 3 DMA). Так вот, оказалось, что на больших нагрузках, процессор не может обработать весь поток, который могут обеспечить остальные компоненты СХД. Для дальнейшего повышения производительности, в новых версиях микрокода происходит автоматическое переключение на программный режим расчета контрольных сумм, что позволяет повысить интегральную производительность системы. Все управление процессом заложено в микрокод и "подкрутить" что-то своими руками не получится.

Новые возможности микрокода доступны в системах E5400/5500 и EF540/550 - остальные по-прежнему используют RoC чипы для расчета контрольных сумм.

С другой стороны баррикад, в HP продолжают восхвалять свой ASIC, использующийся в системах 3PAR. Безусловно, "заточенный" под определенные операции чип, можно снять множество головных болей с архитектора СХД. Здесь и предсказуемая производительность (в силу узкой специфичности чипа), реализация определенного функционала "в железе" (в 3PAR это, в первую очередь, thin provisioning), разгрузка центрального процессора для других задач (впрочем, это спорный аргумент - все зависит от качества кода "других задач").  

Есть ли уже победитель или стоит подождать? Пока на рынке остается целый ряд успешных решений, использующих специализированные процессоры, говорить о победе "commodity" процессоров еще рано. Однако, не за горами день, когда производительности стандартного чипа будет вполне достаточно. Intel ведет активную работу в этом направлении и явно не собирается останавливаться. Активное продвижение SDS на рынок систем хранения только способствует тому, что в один прекрасный момент вести разработку СХД со "своим" чипом будет слишком дорого.

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

Пополнение у СХД начального уровня IBM–Storwize V3700

На этой неделе в IBM сделали еще один шаг к созданию целостной линейки систем хранения данных. Была анонсирована система хранения IBM Storwize V3700, которая, как явно следует из названия, является более бюджетным вариантом Storwize V7000. Действительно, V7000 или V7000 Unified далеко не всегда могут попасть “в бюджет” заказчику, хотя их функционал и идеально вписывается в проект. Поэтому выпуск более бюджетного варианта является отличным ходом!

Давайте посмотрим, что именно IBM предлагает заказчикам V3700:

• Красивый :) интерфейс! Он уже стал привычным для владельцев таких СХД как V7000, SVC или XIV, теперь можно им пользоваться в системе с ценой меньше 20k$. Интерфейс удобный (если нет желания работать в CLI), если никогда не встречали его раньше, посмотрите ролик в этом посте.
• Виртуализация внутреннего дискового пространства. Вместо традиционных RAID-групп используются дисковые пулы.
• Выделение дискового пространства по мере необходимости – thin provisioning. (Когда же будет доступна рекламация дискового пространства?)
• Функционал FlashCopy в том варианте, в котором он есть в “старших” системах. До 64х снимков на систему.
• Производительность – по формальным показателям V3700 опережает DS3500 (хотя и отстает по максимальному объему дискового пространства).
• Миграция данных с имеющихся систем хранения (по FC). Миграция возможна только в одну сторону – для миграции данных с V3700 куда-нибудь еще придется использовать сторонние средства. Хотя, кто же захочет мигрировать данные на другую систему?!
• Поддержка до 120 дисков 2.5” или до 60 дисков 3.5”. К контроллерной полке можно подключить до 4х полок расширения. И контроллерный модуль и дисковая полка занимают в стойке 2U и поддерживают либо 12 дисков 3.5”, либо 24 диска 2.5”. Миксовать полки можно в любой последовательности.
• Поддержка 4х портов 1Gbit iSCSI “в базе” (по 2 порта на контроллер).
• Дополнительно можно установить в каждый контроллер интерфейсную плату. Это может быть либо 4 порта 1Gbit iSCSI, либо 2 порта 10Gbit iSCSI/FCoE, либо 4 порта 8Gbit FC. Разумеется в оба контроллера нужно устанавливать одинаковые платы.
• Возможность апгрейда кэш памяти – вместо “стандартных” 4GB на контроллер можно поставить 8GB (16GB на систему хранения).

Кстати, обратите внимание, что SAS порты имеют интерфейс mini SAS HD:

Но, помимо стандартных возможностей, есть и перспективы, о которых также было объявлено. Чего стоит ожидать от V3700 в некоторой перспективе (не факт, что все это действительно случится – это только “statement of direction”):

• Поддержка SAS подключения к серверам. Самое интересное, что данная поддержка будет включаться бесплатным апгрейдом микрокода. Сами SAS порты уже есть на контроллере (см. картинку выше) – только один из них используется для подключения дисковых полок, а остальные в настоящее время не задействованы.
• Поддержка Easy Tier – динамическая миграция “горячих” блоков данных с обычных дисков на SSD для повышения производительности системы.
• Поддержка репликации на удаленную СХД. Действительно, сегодня без этого даже система начального уровня выглядит “недоделанной”! Будет ли поддержка репликации на V7000 или на SVC пока не известно, но это стало бы дополнительным плюсом при выборе V3700.
• Поддержка до 2040 снимков (FlashCopy) на систему.

Но ведь не может же быть все так прекрасно? Наверняка же есть какой-то подвох и V3700 не умеет что-то очень важное и нужное? Конечно, система начального уровня не может обладать всеми возможностями старших братьев, иначе она и не стоила бы дешевле.

Чего же IBM НЕ предлагает владельцам V3700?

• Компрессия – если хочется компрессии, то потребуется либо отдельный appliance (и они у IBM конечно есть), либо V7000 или SVC.
• Виртуализация сторонних СХД. Хотя миграция и поддерживается, но виртуализации в V3700 не будет. Если хочется расти, то можно подключить V3700 к V7000 или SVC.
• Объединение систем в кластер.
• Поддержка NAS – unified системы не ожидается.

Критичны ли эти “не” для малого бизнеса, в котором V3700 будет первой системой хранения данных? Интерес может представлять unified и компрессия, но обе эти возможности далеко не бесплатны, поэтому я не уверен, что они стали бы популярны в связке с V3700.

Система, на мой взгляд, получилась очень интересная, особенно когда все планы по расширению функционала будут реализованы!

Интерфейс V3700 в действии

V3700 доступна к заказу с 23.11.2012 – обращайтесь к нам и наши инженеры помогут подобрать систему с необходимыми характеристиками для ваших задач. Мы можем проанализировать имеющуюся нагрузку на дисковую подсистему (и не только) и поможем правильно выбрать систему, чтобы она оправдала все ожидания!

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

К прочтению…

Встретил на днях довольно интересую и весьма подробную статью про перспективы различных типов дисков (с точки зрения сотрудника HDS): http://blogs.hds.com/claus/2011/09/putting-hdd-product-trends-into-perspective-a-subsystem-view.html

Ian Vogelesang крайне скрупулёзно описывает актуальные тенденции использования тех или иных типов дисков в мире систем хранения, а также делится своими мыслями относительно ближайших перспектив. Конечно, недавняя близость к HGST и текущее положение в HDS, накладывает некоторый, впрочем очень и очень слабозаметный, отпечаток. Пиши этот текст сотрудник Seagate, акценты наверное были бы немного иные, но общая мысль скорее всего осталась бы прежней. Существуют и иные точки зрения на перспективы развития – кто-то утверждает, что наступит торжество внутренней оптимизации (FAST, EasyTier, Dynamic Tiering…) и будет только два вида дисков - SSD и большие-большие NL SAS (SATA). Хотя идея красивая, мне такие горизонты кажутся слишком туманными. Как минимум, такое решение не универсально и подойдет далеко не всем.

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

IBM Storage Partitioning

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

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

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

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

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

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

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

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

HDS: новый герой

Вчера случилось то, чего все уже давно ждали. Как мы все знаем, SAS диски крепко обосновались в системах хранения начального и среднего класса, но оставался последний оплот дисков с интерфейсом Fibre Channel – системы Hi-End. Но вчера и этот бастион пал – HDS анонсировали новый флагман Hi-End класса VSP (Virtual Storage Platform).  И конечно же, смена интерфейса бэкэнда вовсе не является основной особенностью новой системы. Сменилось многое. Да по большому счету, можно сказать что сменилось практически всё (ну разве что кроме преемственности функционала). Попробую хотя бы частично пробежаться по списку:

• 
  
  (сразу бросается в глаза) шкаф стал стандартным (19’’), хотя конечно в “свой” шкаф систему не поставить
• 
  
  Дисков стало больше (до 2048шт). В ряд можно поставить 6 шкафов, в 2х из них контроллерный модуль займет 14U и еще 26 юнитов останется под диски, а 4 шкафа – только для дисков. 2048 дисков можно поставить только с использованием 2.5’’ SFF дисков (да-да, поддерживаются и такие!). Если используются 3.5’’ диски, то максимальная набивка уже только 1280 дисков.
• 
  
  Теперь можнонужно использовать однофазное питание (на USP-V и более ранних требовалось 3 фазы)
• 
  
  Поддержка до 96 портов FCoE (правда немного позднее), а заодно отказались от поддержки ESCON интерфейса (кто-то его еще использует?).
• 
  
  Максимальный объем кэша увеличен до 1ТБ(!)
• 
  
  Защита кэша посредством записи на флэшку, а значит уже не требуется такое огромное количество батарей, которое было привычным всем владельцам монолитных систем.
• 
  
  Появилась нормальная поддержка SSD дисков (см. следующий пункт).
• 
  
  Вместе с SSD появилась и технология автоматической миграции данных между уровнями хранения (Page Level Tiering).
• 
  
  Анонсирована поддержка инициатив VMware в области хранения (VAAI).
• 
  
  Поддержка VMotion Anyware посредством Hitachi Dinamic Link Manager.
• 
  
  Поддержка шифрования на уровне BED (XTS-AES 256).

Уверен, что забыл еще про что-нибудь упомянуть. Но даже этот список показывает, что работа была проделана большая.

Основные изменения коснулись архитектуры системы, которая является уже пятым поколением. Из каких же частей состоит система?

VSP может состоять либо из одного контроллерного шасси (не контроллера, а именно шасси), либо из двух (в разных шкафах).

Шасси соединяются по PCI-E (правда первого поколения) шине и образуют единый комплекс. Все компоненты внутри одного шасси также связаны через PCI-E. Связь обеспечивается посредством Grid Switch, коих может быть либо 2, либо 4 на одно шасси. “Мозгом” являются модули VSD (Virtual Storage Director) – именно они занимаются всей работой с томами, обеспечивают thin provisioning, tiering и т.д. В отличие от конкурентных решений, не требуется обеспечивать высокоскоростной линк между VSD – каждый том в данный момент времени может управляться только одним VSD. Уже никого не удивить наличием процессоров x86 внутри системы. И VSP не является исключением – выполнение задач общего назначения отданы именно процессорам Intel (quad core Xeon). Диски подключаются к BackEnd Director (BED), на каждом из которых по два порта 4lane SAS 6Gbit. Т.е. в максимальной набивке можно получить до 64х линков 6Gbit SAS (48GB/sec). Причем приобретать систему вместе с дисками (и соответственно BED модулями) вовсе не обязательно (ведь все помнят, что уже USP-V умеет виртуализировать внешние системы хранения) – можно использовать и имеющиеся СХД, подключая их через VSP. Хосты подключаются к модулям FrontEnd Director (FED), каждый из которых поддерживает до 12ти портов 8Gbit FC (или FICON). Позднее должны появиться 4х портовые FED модули FCoE. Вот здесь уже стандартными процессорами не обошлись и на помощь пришли специализированные двуядерные процессоры собственного производства Hitachi (data accelerator ASIC). Именно они занимаются непосредственной обработкой критических к латентности данных. Последним в списке значатся Data Cache Directors – модули с кэш памятью (до 4шт в шасси), каждый может иметь объем от 32 до 128ГБ. На каждом из модулей расположен flash SSD для хранения кэша при отключении питания. Кэш записи зеркалируется попарно между двумя модулями (прочитанные же блоки всегда кэшируются только в одном экземпляре). Еще одна особенность в организации памяти заключается в том как защищена служебная память в VSD модулях. Она уже не зеркалируется между директорами, как в прежних системах, но зато резервная копия всегда сохраняется в паре кэш модулей (это не зеркалирование, а именно резервная копия, оптимизированная для быстрого восстановления). А так как память в кэш модулях, в свою очередь, уже зеркалируется между ними, то получается троекратная защита служебных данных- бэкап на паре Cache Director + хранение на flash памяти (как и любая другая записываемая в кэш информация). Такой подход позволяет еще больше “развязать” VSD модули друг от друга. Физически в контроллерном шасси все модули, к которым могут подключаться кабели, выведены на заднюю сторону шкафа:

А с фронта можно получить доступ к VSD и кэш-модулям:

Еще несколько слов про возможности динамической балансировки между уровнями хранения.  Как и в случае thin provisioning, все операции по миграции делаются блоками в 42МБ. На мой взгляд – многовато. Уровни хранения можно выбирать любые – SSD/SAS/SATA или SAS/SATA или SSD/SATA. Но новые данные всегда сначала попадают на самый “быстрый” уровень хранения и, уже если они больше нужны, то постепенно сдвигаются на “медленный” уровень. В первом релизе page level tiering нет поддержки RADI10, также не поддерживаются внешние системы хранения – можно использовать только внутренние диски. Ну и поддержки mainframe тоже нет (планируется позднее).

Ко всем этим замечательным возможностям добавляется еще переписанная система управления, которая стала заметно симпатичнее и функциональнее. Контроль доступа на базе ролей (RBAC) также поможет упростить жизнь при администрировании VSP.

Ну и справедливости ради, стоит заметить что HP (как OEM партнер HDS) также анонсировали систему StorageWorks P9500. Говорят, что принимали непосредственное участие в разработке. Как видно, постепенно названия продуктов сводятся к единой базе – уже есть P2000 и P4000, теперь P9500. И остался еще изрядный промежуток для продуктов 3PAR (поглощение на днях как раз завершилось).

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

О вреде вибрации в дисковой системе

В блоге у Robin Harris углядел ссылку на очень интересную статью за авторством Julian Turner о влиянии вибраций на производительность жестких дисков. Все наверняка помнят разошедшийся по интернету ролик, где было отчетливо показано, как обычным криком можно изменить производительность дисковой системы SUN. Джулиан же провел более аккуратные с научной точки зрения тесты и результаты действительно впечатляют – максимальное наблюдаемое различие в производительности операций случайного чтения достигает 246% (!), а операций записи – до 88% (при наличии естественных вибраций и их максимальном гашении) . Кроме того, не нужно забывать что увеличение латентности (которое как раз и наблюдается при наличии вибраций), является одной из причин “вылета” дисков из RAID-массивов. Использование дисков 2.5” может существенно снизить эффект, а уж про SSD и говорить не нужно – им вообще все равно.

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

Как избежать проблем с СХД (хотя бы отчасти)

Несколько дней назад (по большей части от любопытства) занимался реанимацией IBM DS4500. На всякий случай – с 2003 до 2006го года это была старшая система класса midrange у IBM. Потом на смену ей пришла DS4800, а с год назад и DS5100/DS5300, а пациент все работал и работал на благо … ну наверняка на чьё-то благо он все-таки работал. Только вот в какой-то момент ему стало тошно от такой жизни и решил он уйти на покой вместе со всеми данными. Сказал, что и дисков он своих знать не хочет, и с контроллерами у него не все ладно (да на всякий случай от одного сразу и открестился). И пришлось вокруг старичка попрыгать разве что не с бубном. По счастью, завести эту DS4500 удалось (конечно не без какой-то там матери, но главное при помощи девственно чистого файберного диска, лежавшего в загашнике). После “оживления” оказалось, что и контроллеры оба замечательно себя ощущают, и диски все живы, и даже данные оказались на своих местах. Но повозиться пришлось изрядно, а одна из основных причин состояла на мой взгляд в том, что прошивка на системе стояла чуть ли не та, с которой она вышла с завода. Сама по себе, возникшая проблема со старой прошивкой связана скорее всего не была, но вот будь она (прошивка) поновее, решение проблем потребовало бы в несколько раз меньше времени. Поэтому решил я дать несколько рекомендаций для тех, кто администрирует различные системы хранения:

• Как правило, производитель рекомендует определенную версию прошивки для каждой системы (разумеется, со временем рекомендуемая версия меняется). Не стоит пренебрегать этим! Даже если проблем с системой нет, раз в пол-года проверяйте актуальные рекомендации и просматривайте список изменений. Даже если Вы не будете обновлять систему, Вы хотя бы будете знать какие проблемы были исправлены (вполне возможно что Вы уже с этими проблемами сталкивались, но не соотнесли их с СХД) – предупрежден, значит вооружен!
• Самую последнюю прошивку, которая вышла “вот только вчера ночью”, устанавливать можно лишь в том случае, когда в системе есть серьезные проблемы, которые мешают ее нормальной эксплуатации! Прошивать “продуктив”, чтобы проверить “ту самую фишку”, которую только что анонсировали, не стоит – проблемы, которые могут возникнуть, сильно омрачат Вашу радость от мизерных улучшение. Если все-таки нужны новые возможности, то оптимальный путь – дождаться следующего обновления и, если не было найдено критических ошибок, доведите версию ПО до предыдущей.
• Убедитесь, что фоновые процедуры проверки работают – в противном случае можете оказаться лицом к лицу с “вылетевшим”  вторым (третьим) диском при перестроении массива. Чем это грозит наверное можно даже и не упоминать.
• Регулярно проверяйте состояние батарей, защищающих кэш. Заранее озаботьтесь заказом новых. Помните, что при выходе батареи из строя, большинство СХД отключают кэш записи. После этого производительность может снизиться в нескольких раз. Конечно есть ненулевой шанс найти батарейку “живьем” в Москве или другом городе, но если система Ваша не новая (а тем более, если она уже снята с производства), батарейка эта наверняка провалялась на складе не один год. Так что нашли-то Вы ее “живьем”, а вот по факту она окажется “трупом”.  Лучше прождать два-три месяца (в наших реалиях), но получить батарею, которая прослужит хотя бы пару лет.
• Следите за состоянием массива даже если он находится на вторых (третьих или четвертых) ролях. Потому как по закону подлости на нем обязательно окажутся данные, которые есть в единственном экземпляре (“вот только вчера записали, а сегодня хотели бэкап сделать”) и которые ни в коем случае нельзя потерять. Только вот массив-то уже месяц был в критическом состоянии, а сегодня его совсем медным тазом прикрыло.

Ну и два главных совета:

1. Постарайтесь, чтобы слова “О, а у нас оказывается есть СХД!” звучали не только тогда, когда эта СХД сломалась!
2. Если есть финансовая возможность продлевать сервисное обслуживание, то этим Вы существенно облегчите себе жизнь! А если такой возможности вроде бы и нет, то постарайтесь аргументировать для людей, выделяющих финансы, необходимость этого продления – в случае возникновения проблем в системе без сервиса, решать эти проблемы придется скорее всего Вам самому.

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