Совсем недавно были анонсированы новые системы хранения 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% скидку на железо, зато теперь в лидерах рейтинга.
В 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 на новый уровень
- большой вопрос.
Сегодня – вольный перевод заметки про V3700 известного блоггера из IBM - Barry Whyte.
Часто можно слышать вопрос, является ли система V3700 настоящей active/active или active/passive? Подоплека вопроса в том, что в свойствах логического диска (volume, vdisk, LUN) всегда указан “preferred” контроллер:
Однако, этот параметр нужен вовсе не для того чтобы указать единственный “активный” контроллер, а для оптимизации нагрузки на систему (распределению между контроллерами). При создании нескольких томов они чередующимся образом распределяются между контроллерами, а дальше в дело вступает драйвер multipath на уровне сервера. Если драйвер на сервере поддерживает ALUA, то такое указание “активного” контроллера позволит, при наличии нескольких томов, распределить нагрузку между контроллерами. Трафик “от” и “к” каждому конкретному тому будет идти через его “preferred” контроллер, а если томов много, то оба контроллера будут загружены примерно одинаково (конечно в отдельных случаях может потребоваться ручное перераспределение). Если же драйвер не поддерживает ALUA, то будет использоваться режим round-robin (чередование путей) и все контроллеры также будут равномерно загружены. В этом случае, (с точки зрения сервера) нет разницы, какой контроллер “preferred” – оба будут получать трафик со стороны хоста.
Для всех СХД IBM, построенных на базе микрокода SVC (SVC, V7000, V3700, V3500) реализовано такое поведение при получении запроса от хоста:
запросы на чтение обрабатываются тем контроллером, на который пришел запрос;
успешность запроса на запись подтверждается (ACK) тем контроллером, на который пришел запрос. Разумеется, это происходит только после зеркалирования записываемого блока в кэш второго контроллера. Затем уже “preferred” контроллер осуществляет непосредственный сброс кэша на диски.
На основании вышесказанного можно с полной уверенностью утверждать, что все перечисленные СХД являются настоящими active/active СХД.
На этой неделе в 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 – обращайтесь к нам и наши инженеры помогут подобрать систему с необходимыми характеристиками для ваших задач. Мы можем проанализировать имеющуюся нагрузку на дисковую подсистему (и не только) и поможем правильно выбрать систему, чтобы она оправдала все ожидания!
К сожалению времени катастрофически мало, поэтому руки не всегда доходят вовремя написать про свершившееся.
В очередных октябрьских анонсах IBM было объявлено о целом ряде интересных новинок. Прежде всего, это разумеется “приставка” для уже весьма популярной системы Storwize V7000, превращающая ее из обычной блочной системы хранения в Unified систему. Термин ставший в последнее время крайне модным, поэтому ну уж никак нельзя было без этого обойтись. По сути это два обычных x86 сервера (x3650M3), добавленные к системе V7000.
На серверах установлена версия SONAS 1.3 (также анонсирована). Благодаря тому что именно в этой версии SONAS можно отказаться от выделенных станций управления, никакого дополнительного оборудования не потребуется. Напомню, что SONAS это “большой-большой” NAS, в изначальном варианте позиционирующийся нишей выше файлеров NetApp (там где нужны очень высокие скорости и очень большие объемы). V7000U это “младший” брат большого SONAS, который состоит только из двух узлов, но в программной части отличий нет. В основе решения лежит кластерная файловая система IBM GPFS. В качестве интерконнекта между файловыми модулями используется два гигабитных интерфейса (в “большом” SONAS – Infiniband). Доступ к файловым ресурсам может быть как через 1GbE интерфейсы, так и через 10GbE. Поддерживаются протоколы CIFS, NFS, HTTP(s), FTP, SCP. Все управление (как блочными ресурсами, так и файловыми) остается централизованным и осуществляется из уже ставшего привычным интерфейса:
Поддерживаются все стандартные возможности SONAS – репликация, мгновенные снимки, внешний антивирус и т.п.
С анонсом V7000 Unified, линейка систем хранения IBM становится еще более внятной и все более “made by IBM”. Очевидно что основными конкурентами будут EMC с системами VNX и “средние” файлеры NetApp. В некотором смысле это ответ NetApp, которые в свое время исключили поддержку SVC в своих виртуализаторах (V-Filer), а поддержки V7000 в качестве блочного устройства там и не было. Конечно, и у тех, и у других систем есть свои преимущества и свои недостатки, но V7000U займет среди них достойное место.
Анонсы на этом не закончились. Для V7000 и SVC обновилась версия ПО до 6.3. Теперь для Global Mirror (асинхронной репликации) можно дополнительно задавать RPO. В этом случае репликация будет работать через периодические снапшоты и потенциально позволит сократить требования к каналу связи. Также объявлено о возможности репликации между SVC и V7000. Для SVC сняли ограничение на отсутствие хопов между узлами SVC в stretch cluster конфигурации. Теперь узлы можно разнести на расстояние до 300км (стоит конечно помнить про снижение латентности при удалении узлов друг от друга). В V7000 появилась поддержка дисков 3TB NL SAS, SSD 200GB и 400GB.
Опубликован драфт (насколько я помню в открытом доступе его ранее не было) ред-бука, посвященного новой midrange системе хранения и “виртуализатору” в одном лице – IBM V7000. Вопросов про нее задают довольно много, поэтому книжка вероятно будет пользоваться популярностью. Рассказывается там буквально про все – начиная от формальных маркетинговых характеристик и заканчивая траблшутингом.
Уж не знаю чем так в IBM надоели вторничные анонсы, но похоже что теперь нам придется привыкать к новостям в четверг. В прошлый, например, было объявлено столько всего что теряюсь за что взяться вначале. Даже выстроить порядок по значимости довольно проблематично, поэтому пойду в случайном порядке :)
SAN Volume Controller (SVC)обновился до версии 6.1. Речь конечно идет не про железную часть SVC, а про программный код. Прежде всего, в новой версии будет доступна технология Easy Tier, которая уже некоторое время присутствует во флагмане – high end системе DS8700. Easy Tier автоматически размещает блоки данных, к которым доступ осуществляется наиболее частно, на более быстрых носителях (например, SSD дисках). Т.е. сам LUN может быть размещен частично на SSD, частично на SAS и частично на SATA дисках. Благодаря Easy Tier можно существенно повысить производительность дисковой системы без переноса всего LUN на более дорогие носители:
Также добавилась поддержка VMware vSphere 4.1 и очередной порции дисковый систем как самой же IBM, так и от других компаний. Еще одно заметное изменение - радикально переделан пользовательский интерфейс. Хотя и старый был вполне логичен, но разобраться с ним было далеко не просто (особенно если до этого опыта работы с различными СХД было мало), но теперь внешний вид переняли у XIV. А надо заметить, что найти GUI проще и понятнее чем в XIV практически невозможно (на мой взгляд).
Заодно с интерфейсом поменялись и некоторые термины. Вместо сложного “vDisk to host mapping” остался просто “Host mapping”, вместо “Space-efficient” – уже привычный всем “Thin provisioning”, вместо “Virtual Disk (VDisk)” – гораздо более привычный пользователям СХД “Volume”, ну а вместо “Managed Disk (MDisk) group” – “Storage pool”. Небольшой ложкой дегтя для пользователей SVC с внутренними дисками SSD (а такая возможность для узлов CF8 появилась почти год как тому назад) будет необходимость немного подождать – внутренние SSD не поддерживаются в релизе 6.1. Их поддержка вновь появится, но немного позднее. Впрочем, это не должно сказаться на основной массе установленных систем.
Storwize V7000. Вот и сказано новое слово в системах IBM класса midrange. Вопреки многим подозрениям не имеет никакого отношения к приобретенной ранее компании Storwize и ее продуктам по компрессии данных в реальном времени. Более того, чтобы избежать путаницы бывшие Storwize получат новые названия, так как Storwize больше, по мнению IBM, подходит для системы хранения. (Очень интересный подход к приобретению компании – с одной стороны, приобрели ради конкретных технологий и продуктов, а с другой – нашли удачное применение старому названию. Можно сказать двойная отдача :) ). Что же это за зверь такой – V7000? Система эта уже гораздо более IBM чем широко известные DS3000/DS5000/Nxxx (первые две это OEM LSI, а N-серия тоже “чужая” и является OEM-ом NetApp). До недавнего момента IBM мог похвастаться полностью своими системами только в верхнем сегменте – DS8000, XIV (которая правда разработана вне IBM и уже потом куплена ). Ну и еще есть конечно очень сильный продукт – SAN Volume Controller. Но SVC является в чистом виде “виртуализатором”, т.е. не содержит жестких дисков (есть маленькое исключение в виде SSD, но про него пока забудем) и занимается исключительно обработкой потоков данных между серверами и СХД. А что если совместить SVC и небольшую дисковую систему? Такое решение зрело уже давно и именно оно нашло воплощение в продукте под названием Storwize V7000, который является комбинацией возможностей SVC (по большей части) и DS8000 (довольно скромный вклад). Очень хорошая иллюстрация нашлась здесь:
Зеленый цвет соответствует коду, привнесенному от SVC 5й версии; голубой – новые возможности, появившиеся и в SVC 6.1, и в V7000 (разумеется, всё что касается дисков и блоков питания относится только к V7000).
Для новой системы сразу появляется два типичных сценария внедрения:
новая система V7000 с относительно небольшим числом дисков и дальнейший рост за счет подключения внешних систем
плановое вытеснение уже установленной СХД на второй план за счет виртуализации
В случае с обычной версией SVC, оба таких сценария потребуют покупки сразу двух продуктов – непосредственно SVC и дисковой системы. Такой подход далеко не всегда находит понимание в “высших” сферах. А теперь достаточно приобрести V7000 и можно будет как использовать ее внутренние диски, так и подключать внешние системы хранения.
Так что же представляет собой V7000? Как и в случае с DS3500, доступны два базовых варианта – 2U система с 12ю дисками 3.5’’ и 2U с 24мя дисками 2.5’’. Поддерживаются диски SSD, SAS, Near Line SAS. На текущий момент можно подключать до 120 дисков, но уже ко второму кварталу 2011г. обещают увеличить число поддерживаемых дисков вдвое – до 240. Полки расширения также двух типов – 2U 12x3.5’’ и 24x2.5’’, подключаются через SAS 6Gbit. Контроллерный модуль содержит два контроллера, по 8ГБ кэша в каждом (правда, правильнее будет наверное сказать не кэша, а памяти). Каждый контроллер имеет по 4 порта FC 8Gbit и по 2 порта iSCSI 1Gbit. Внешние дисковые системы (для последующей виртуализации) подключаются через FC порты, т.е. порты на контроллере в принципе идентичны имеющимся в узлах SVC CF8. “Железо”, как я подозреваю, выпускается тем же самым производителем, который делает модули для систем XIV. Подключение полок расширения делается несколько иначе чем в остальных системах IBM. Вместо ставшего привычным подключения “сверху-вниз, снизу-вверх”, в V7000 полки подключаются последовательно. С одной стороны, это гораздо проще, с другой – чуть опаснее, так как полный отказ полки “в середине” приведет к отказу всех следующих за ней дисков. Справедливости ради стоит отметить, что такой печальный вариант развития событий крайне маловероятен в силу отсутствия незадублированных активных компонентов внутри полки. Кроме того, большинство других производителей не стесняются использовать такой способ подключения в системах с гораздо большим числом дисков. Для “внутренних” дисков поддерживается RAID 0, 1, 5, 6 и 10. Остальные возможности пришли из SVC – это выделение дискового пространства по требованию (thin provisioning), зеркалирование диртуальных дисков (VDisk mirroring), поддержка FlashCopy и RemoteCopy. Как и в новой версии SVC 6.1, поддерживается технология Easy Tier. Добавив всего несколько SSD в конфигурацию V7000 можно радикально увеличить производительность системы. А благодаря возможностям виртуализации, благодаря Easy Tier можно увеличить производительность томов, которые сейчас размещены на уже имеющихся дисковых системах. Удивительная по удобству использования графическая оболочка в V7000 пришла из систем IBM XIV.
Про остальные анонсы наверное чуть позднее – и без того получился слишком длинный пост.
Еще один уверенный шаг EMC в сторону концепции IT as a Service сделан. Под брызги шампанского и бурные овации на EMC World 2010 анонсирован VPLEX. Выбранное имя конечно не удивляет – сейчас продукт, в названии которого не будет буквы “V”, могут представить только аутсайдеры (даже если к виртуализации никакого отношения продукт и не имеет, а здесь-то как раз виртуализация на месте). Прозвучали и громкие слова “Storage federation”. VPLEX преподносится как таблетка от всех проблем, связанных со сложностью администрирования разрозненных “островков” систем хранения. Казалось бы, что нового? Все это уже давно есть и у IBM (SVC), и у HDS (USP-V), и даже у самой EMC (Invista) – системы виртуализации СХД уже не первый год на рынке. Но ключевой особенностью VPLEX является возможность объединять не только СХД, расположенные на одной площадке, но и системы территориально распределенные (в перспективе – на сколь угодно большие расстояния). Можно сказать, что VPLEX это вертикально и горизонтально масштабируемая система виртуализации СХД, позволяющая использовать глобальный (распределенный) кэш. В основу продукта положены технологии приобретенные вместе с компанией Yotta Yotta. Вполне логично, что VPLEX эффектно подается в связке с VMware vMotion как решение, позволяющее беспрепятственно перемещать нагрузку между датацентрами и, тем самым, обеспечивающее максимальную гибкость и подкупающую простоту администрирования. Идея произвольным образом “двигать” сервисы между площадками если смотреть “сверху” конечно импонирует (по крайней мере, до того как надо будет закопаться в детали). Привлекательно выглядит возможность передвигать ресурсоемкие сервисы по часовым поясам в зависимости от стоимости вычислительных ресурсов в данное время суток. Звучит красиво, ничего не скажешь!
Но, как и всегда, есть несколько “но”. В настоящее время VPLEX поставляется только в двух вариантах – VPLEX Local (для работы на одном сайте) и VPLEX Metro (для объединения двух площадок, расстояние между которыми позволяет использовать синхронную репликацию, т.е. до 100км). В первом случае решение ничем не отличается от любой другой системы виртуализации СХД, во втором конечно есть отличия, но и здесь конкурентам есть что предложить. Справедливости ради нужно сказать, что в перспективе EMC обещает еще две версии VPLEX – Global, для объединения двух площадок на расстоянии более 100км (асинхронная репликация) и VPLEX Geo, который уже позволит объединять несколько датацентров на произвольном расстоянии друг от друга. Все это, однако, ждет нас не раньше 2011 года. Кроме того, функционал VPLEX в плане виртуализации также довольно ограничен на текущий момент – поддерживаемые “чужие” СХД (IBM, HDS) можно пересчитать на пальцах одной руки (список конечно планируют еще расширять); нет поддержки ни thin provisioning, ни мгновенных снимков – если это необходимо, то придется пользоваться функционалом СХД. Собственно, из-за этого скорее всего и не было объявлено о смерти Invista. Картина становится несколько мрачнее – в настоящий момент VPLEX для большинства не принесет долгожданной простоты управления, а скорее добавит сложностей. Нужно будет не только научиться управлять VPLEXом, но и продолжать следить за виртуализированными СХД и, возможно, гораздо аккуратнее заниматься выделением пространства, так как теперь между СХД и серверами окажется новое устройство, которое будет усложнять представление данных.
Что же за устройство скрывается за красивым названием VPLEX? Минимальный модуль (VPLEX Engine) состоит из двух кастомизированных x86 серверов (каждый отдельно называется Director), упакованных в одно шасси высотой 4U. Каждый director оснащен двумя 4х ядерными процессорами, 32ГБ памяти и имеет 16 дисков и 16 хостовых портов FibreChannel 8Gbit. Разумеется в комплекте обязательным образом идет еще и SPS (ИБП). Максимум в кластер для увеличения производительности можно объединить до 4х Engine (получается 8 директоров). Друг с другом директоры общаются через выделенные FC порты (помимо упомянутых выше 32х штук), для чего используются отдельные коммутаторы. На каждом директоре присутствует по 2 порта для взаимодействия внутри кластера и 2 порта для взаимодействия с удаленными комплексами. В максимальной набивке комплекс VPLEX выглядит примерно как на картинке справа. Помимо 4х узлов и двух коммутаторов в стойке также размещается управляющий сервер, через который собственно и происходит вся работа с VPLEX. Из 32ГБ памяти каждого директора, в качестве кэша используется около 20ГБ, таким образом, на каждой площадке можно получить до 160ГБ кэша. Кэш используется только для чтения: при получении запроса VPLEX проверяет наличие данных у себя в кэше, если данных там нет, то проверяется глобальный кэш (память остальных узлов) и только если данных не оказывается и там, делается запрос на чтение с дисков. Вся запись ведется “сквозным” образом, т.е. подтверждение хосту об успешном завершении отправляется только после того как VPLEX получит соответствующее подтверждение от всех дисковых систем, участвующих в записи блока данных. Так как VPLEX это по сути своей система виртуализации СХД, то выделение LUNов хостам делается через VPLEX (хотя конечно можно и просто “пробрасывать” LUN с дисковой системы без изменения). В общем случае, картина примерно такая: LUNы, созданные на дисковой системе, отдается во владение VPLEXу, на них создается один или несколько экстентов (extent) произвольного размера, затем эти extent объединяются в девайсы (devices), на которых можно уже создать виртуальные тома (virtual volume) и уже эти самые virtual volume можно раздавать хостам. На первый взгляд немного запутано, но практически все системы виртуализации так и работают. Каждый комплекс VPLEX может раздавать хостам до 8000 LUNов.
Итак, анонс прошел, фанфары прозвучали, что в сухом остатке? Отношение неоднозначное. Сказать, что EMC “стрельнули” уникальным продуктом я не могу. Вот если бы все это было реализовано на базе VMAX, это было бы действительно “круто”! Концептуально предложенное решение мне, впрочем, и так нравится. Но вот что не нравится: отсутствие кэша на запись, отсутствие таких функций как thin rpovisioning, снимки, клоны и т.п. Сейчас можно говорить лишь только об озвученном плане на будущее развитие. План радужный, но насколько он будет воплощен в жизнь остается под вопросом. А пока заказчикам остается выслушивать истории про Storage Federation и IT as a Service ну и конечно про Cloud Computing. Впрочем, если вдруг прямо сейчас нужно взять и начать строить (именно начать) пресловутое облако, то возможности VPLEX могут оказаться востребованы. Для двух площадок можно даже обойтись и без VMware SRM, продолжая обеспечивать высокий уровень доступности сервисов. Так что заказчики на VPLEX безусловно найдутся, но сможет ли он серьезно потеснить IBM SVC (или хотя бы HDS) на рынке систем виртуализации – большой вопрос. И на сегодняшний день мой прогноз – в ближайший год шансов очень и очень мало.
Сегодня конечно надо писать про POWER7 или в крайнем случае про Itanium, но об этом и так напишут без меня. Единственное что мне в этом анонсе интересно, будет ли реакция оракла в виде изменения коэффициентов при расчете лицензий. Мне же сегодня хочется вспомнить про опубликованные на прошлой неделе результаты тестирования дисковых систем.
Про выход EMC из тени и возврат в тесты sfs2008 (впервые с 2007го года) с Celerra Gateway NS-G8 и Symmetrix V-Max, набитой SSD, не написал еще только самый ленивый приверженец нетапа. При всей нелюбви EMC к синтетическим тестам, заход с публикацией тестов действительно довольно странный – и ладно бы результат был бы рекордным, так нет, ни флагман хай-энда V-Max, ни использование SSD (EFD) дисков не дали забраться на пьедестал почета. Впереди оказались и NetApp, и BlueArc, и Exanet…
А вот про IBM с его результатами тестов SPC-1 для DS8700 остался как-то в тени. Что же тут такого? Удивляет, что с момента выхода DS8700 прошел уже не один месяц и, если результаты появились только сейчас (и это при всей любви IBM к публикации результатов всевозможных тестов), то в чем причина такой задержки? Может быть система оказалась слабее, чем HDS USP-V, которая занимала первое место в SPC-1 среди хай-энда уже более двух лет? (Да, у IBM был результат и выше, но он был у SVC в связке с несколькими DS4700) Или все дело в том, что радикального преимущества можно было достичь только на числе дисков, большем нежели в USP-V (а там их было 1024)? И потребовалось добавить SVC, чтобы объединить две системы DS8700 и получить в сумме 2048 дисков. Все это нам, простым людям, узнать наверное не получится, но давайте посмотрим на результаты:
HDS USP-V
IBM DS8700 + 4xSVC
IBM DS8700 + 6xSVC
SPC-1 IOPS
200 245.73
315 043
380 489.3
$/SPC-1 IOPS
17.61
22.65
18.83
С одной стороны, критики SPC как инструмента для сравнения вроде бы правы и увеличение числа дисков в два раза дает почти в два раза лучший результат. С другой стороны, апологеты SPC тоже с виду правы, так как могут сказать, что качественное улучшение платформы (увеличение числа узлов SVC) при неизменном числе дисков может дать существенный прирост (в данном случае - примерно 20%). Но давайте взглянем немного более внимательно на результаты тестов:
В табличку мы добавили время отклика при 80, 90 и 100% нагрузки, а также информацию по числу дисков и их утилизации (%, который составляет размер ASU от общего пространства). Что изменилось? На мой взгляд, приведенные результаты свидетельствуют только о том, что добавление 2х узлов к 4х узловому кластеру SVC было вынужденным действием. “Дури” у DS8700 оказалось столько, что 4х узлов просто было недостаточно. Два дополнительные узла проблему решили и “бутылочное горло” пропало и, как следствие, снизилось время отклика. Попутно хочется обратить внимание на еще один немаловажный параметр – размер ASU. Конечно после учета всевозможных расходов на метаданные, спаре-диски и зеркалирование размер “полезной” емкости будет меньше 50%, но вот насколько меньше? В случае с HDS объем ASU составлял 17%, а в случае с IBM – 32%, а это почти в два раза выше. Почему это важно? Достаточно взять в руки iometer и потестировать любой массив, варьируя размер тестируемой области. Типичный график зависимости IOPS от используемого дискового пространства на рисунке:
Таким образом, размещая данные в начальных областях дисков можно заметно повысить свой рейтинг в тестах. Какой можно сделать вывод? Боюсь что никакого толкового сделать нельзя. Хороша ли HDS USP-V? Безусловно! Результаты отличные (особенно учитывая то, что им уже более двух лет). Может быть плоха IBM DS8700? Конечно нет! SVC скорее всего все-таки был нужен именно для того, чтобы иметь возможность использовать 2048 дисков, а не для повышения производительности.
И в свете всего вышесказанного, мне не совсем понятно как IBM преподносит свой хай-энд в тестах и почему именно такая конфигурация была выбрана для тестирования:
Почему не взяли 8 узлов SVC? (неужели больше не было никакого эффекта?)
Почему не использовали SSD диски в DS8700? (может быть из-за ограничения на число дисков?)
Почему даже в SVC не использовались SSD? Объем кэша в двух DS8700 суммарно в три раза больше, чем у USP-V, но в расчете на размер ASU получается все-таки меньше и дополнительное кэширование должно было дать эффект (или все-таки нет?).
Вполне вероятно, что со временем последуют другие, более интересные результаты, которые прояснят ситуацию. Время покажет. Но относиться к результатам SPC (да и другой синтетики) нужно очень и очень аккуратно. Так как даже если считать, что сам тест предполагает воспроизводимость результатов и объективную методику тестирования, нужно признать что трактовка результатов (в первую очередь из-за огромного числа варьируемых параметров) вызывает больше споров и сомнений, нежели понимания общей картины.
IBM опубликовал сразу 4 драфта новых книжек про системы хранения среднего уровня (DS4000/DS5000), которые должны занять достойное место в подборке документации администраторов СХД:
По сравнению с тем, что уже можно было найти в “редбуках” ранее, собрана вместе информация по новым системам в линейке DS4000/DS5000 и подробно описаны все нововведения. Две последние работы довольно узко специализированы: в одной подробнейшим образом изложен механизм работы мгновенных снимков и клонирования (в т.ч. и между системами), а вторая посвящена виртуализации на базе VMware ESX/ESXi. В принципе, обе книги не содержат радикально новой информации (по крайней мере, я не увидел ничего, что не встречалось бы в выпущенной ранее документации), однако прочитать и держать под рукой эти материалы полезно. Тем же, кто впервые развертывает VMware на системах IBM DS4000/5000 читать просто необходимо – в соответствующей книге собран вместе обширный материал, который позволит гораздо лучше понять что и как делать. Не оставлен в стороне и вопрос выбора (и оптимизации) настроек дисковой системы для повышения производительности.
Наибольший же интерес, на мой взгляд, должны представлять первые две книги – изложенный материал позволяет гораздо лучше понять, как именно устроены дисковые системы IBM и как с ними нужно работать. Тем, кто впервые сталкивается с системами IBM, очень поможет описание термина “Storage Partitions”, который часто вызывает проблемы в понимании. Объясняется множество вопросов, которые могут возникнуть в процессе подбора конфигурации. Поэтому эти две книги полезны не только пользователям систем, но и пресейлам – правильно подобрать конфигурацию тоже бывает непросто. Отдельная глава посвящена RSM (Remote Support Manager), продукту который пока не слишком популярен на наших просторах, но ситуация должна постепенно меняться.
Администраторам будет интересно прочитать про процедуру обновления прошивок, конфигурацию коммутаторов и настройку СХД в связке с различными операционными системами (в т.ч. есть и пример настройки кластера Windows 2008 при загрузке с SAN). До недавнего момента в многочисленных книжках IBM встречалась рекомендация подключать контроллер A к одному коммутатору, а контроллер B – ко второму. Мне такая схема всегда казалась не очень правильной (хотя она и обеспечивала отказоустойчивость) так как при этой настройке, выход из строя коммутатора, обрыв кабеля от сервера к коммутатору или выход из строя адаптера в сервере гарантированно приводит к переносу LUN’а между контроллерами, что может вызвать проблемы производительности. Поэтому я всегда рекомендовал подключать каждый контроллер к каждому коммутатору и терпеливо объяснял свою позицию внимательным читателям документации. Сейчас же был приятно удивлен – теперь везде приводится рисунок с “правильным” подключением:
Также очень полезной будет и глава по определению неисправностей и их устранению. Не секрет, что зачастую вопрос обслуживания ложится на хрупкие плечи системного администратора – либо по каким-то причинам не был куплен сервисный пакет, либо система находится далеко и времени на ожидание ответа от сервиса нет, да и много других причин может быть.
Можно найти и очень много подробных описаний по оптимизации настроек СХД для тех или иных приложений. Но отдельного упоминания заслуживает вопрос сайзинга, т.е. подбора конфигурации под имеющуюся (планируемую) нагрузку. Здесь и работа с монитором производительности в Storage Manager (Performance Monitor), и IBM Tivoli Storage Producivity Center for Disk. Детально объясняется работа с такой полезной утилитой для сайзинга как Disk Magic (впрочем, я не уверен что она доступна пользователям, но имеющие доступ на IBM Partnerworld могут ее оттуда скачать). Даже если доступа к утилите у Вас и нет, Вы можете собрать необходимые данные и отправить их интегратору, чтобы он провел для необходимый расчет и подобрал нужную конфигурацию, которая обеспечит должный “запас прочности”.
Так как упомянутые книги это пока только драфты, то читать их конечно нужно, но и следить за обновлениями тоже не помешает!
Уже довольно давно IBM предлагает (и надо заметить небезуспешно) свою систему виртуализации СХД – SAN Volume Controller (SVC). Писать про SVC можно много, но сейчас не об этом. Так как внедрение системы виртуализации СХД это своего рода радикальное изменение в инфраструктуре (хотя оно и может быть реализовано практически полностью прозрачно), то решиться на этот шаг не всегда просто. Именно поэтому уже больше года, если не ошибаюсь, была выпущена версия “для неуверенных”, т.е. решение, которое имело ограниченный функционал, но зато гораздо более бюджетное. В отличие от старшего собрата Entry Edition лицензируется по числу жестких дисков которые входят в виртуализуемый объем. Ограничение на момент выпуска составляло не более 60 дисков для кластера SVC. С одной стороны, этого вполне достаточно, чтобы развернуться “в полный рост” с системой начального уровня и организовать репликацию на удаленную площадку, но любое сравнительно серьезное расширение требует перехода на полную версию SVC. Да, этот переход не требует покупки нового железа, но все равно “бьет” по карману.
С выпуском версии SVC 5.1 и нового поколения железной части (на базе серверов x3550M2) возможности Entry Edition существенным образом расширились – поддерживается уже до 250 дисков (а это вполне себе серьезная система получается). Но на этом приятные новости не закончились – теперь совершенно бесплатно доступна лицензия на FlashCopy! А это уже серьезное подспорье, например в развертывании системы резервного копирования, – в частности Exchange 2010 можно будет бэкапить только через VSS (а VSS, в свою очередь, замечательно интегрируется с FlashCopy посредством Tivoli Storage FlashCopy Manager). Единственное о чем следует помнить – не нужно перебарщивать с лицензиями на FlashCopy – они конечно в базе (с годом поддержки) бесплатны, но дополнительная поддержка стоит денег и, если известно, что снимки нужно делать не со всего объема, то на дальнейшей поддержке можно немного сэкономить.
Все эти изменения в SVC Entry Edition делают его приобретение весьма заманчивым. Особенно если в хозяйстве уже есть какая-то “старая” система хранения и хочется не только добавить еще одну систему, но и унифицировать управление.