Совсем недавно были анонсированы новые системы хранения 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% скидку на железо, зато теперь в лидерах рейтинга.
Ian Vogelesang крайне скрупулёзно описывает актуальные тенденции использования тех или иных типов дисков в мире систем хранения, а также делится своими мыслями относительно ближайших перспектив. Конечно, недавняя близость к HGST и текущее положение в HDS, накладывает некоторый, впрочем очень и очень слабозаметный, отпечаток. Пиши этот текст сотрудник Seagate, акценты наверное были бы немного иные, но общая мысль скорее всего осталась бы прежней. Существуют и иные точки зрения на перспективы развития – кто-то утверждает, что наступит торжество внутренней оптимизации (FAST, EasyTier, Dynamic Tiering…) и будет только два вида дисков - SSD и большие-большие NL SAS (SATA). Хотя идея красивая, мне такие горизонты кажутся слишком туманными. Как минимум, такое решение не универсально и подойдет далеко не всем.
Массовое поглощение производителей систем хранения данных идет полным ходом. Большие игроки стремятся собрать наиболее полный пакет решений под свою марку, чтобы иметь возможность конкурировать на всех фронтах. Сначала DataDomain, потом 3PAR, в ноябре было объявлено о намерениях EMC по приобретению Isilon. Несколько дней назад Dell заявил о предварительной договоренности с Compellent. Я уже не вспоминаю более ранние истории с XIV, Exadata, EqualLogic и другими. Если XIV, EqualLogic, DataDomain и 3PAR сразу нашли свою нишу у покупателей, то Exadata исчезла и про продукт ничего не слышно. Может быть и будет какое-то продолжение, но столь длительное “молчание” не добавит очков и без того очень нишевому продукту. А кто же остается? DDN, Panasas, Pillar, Xiotech, да наверное больше и назвать некого. Думаю, что к кому-нибудь из них уже приглядываются потенциальные покупатели. Из покупателей пока “самым голодным” должен быть все тот же Dell, существенную долю в продажах пока еще составляют системы EMC – EqualLogic хорошие системы, но могут “играть” только в нижнем сегменте. С приобретением Compellent, возможностей по продаже собственных систем хранения у Dell существенно прибавится. А может быть следующим покупателем будет Oracle? От перепродаж HDS уже отказались, может быть пора и от LSI отказаться, а вместо этого прикупить что-то себе?
Вчера случилось то, чего все уже давно ждали. Как мы все знаем, 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 (поглощение на днях как раз завершилось).
Еще один уверенный шаг 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 (да и другой синтетики) нужно очень и очень аккуратно. Так как даже если считать, что сам тест предполагает воспроизводимость результатов и объективную методику тестирования, нужно признать что трактовка результатов (в первую очередь из-за огромного числа варьируемых параметров) вызывает больше споров и сомнений, нежели понимания общей картины.
Меня уже давно занимает вопрос, как нормально можно перевести термин "thin provisioning"? Вроде бы вполне понятно, что именно он означает, но найти нормальный русскоязычный эквивалент проблематично. Выделение дискового пространства по требованию? Звучит сравнительно понятно (хотя и не отражает всего смысла, так как неплохо бы добавить еще "небольшими блоками"), но вместо двух слов получили уже пять, а это уже, пожалуй, перебор. Более короткий вариант я лично придумать не могу, поэтому лучше буду использовать англоязычный вариант.
В HDS пошли другим путем и придумали свой собственный термин "Dynamic Provisioning". С 3го августа Dynamic Provisioning будет доступен для систем серии AMS2000. Какие возможности получает пользователь и как это работает?
Для начала, "как работает". Используя новые возможности, можно объединить несколько RAID-групп в один пул (HDP Pool) и уже из этого пула выделять луны (HDP Volume, Virtual LUN) для серверов. При этом, суммарный объем соозданных Virtual LUN может превышать доступный физически объем. По мере того как очередные блоки данных записываются на LUN, происходит динамическое расширение Virtual LUN. Пространство для Virtual LUN выделяется из HDP Pool блоками (chunk) по 1ГБ (поэтому "thin" это конечно довольно громко сказано). Система осуществляет распределение этих блоков между RAID-группами, входящими в HDP Pool: сначала выделяется chunk размером 1ГБ на первой RAID-групппе (для каждого из Virtual LUN), а когда он будет полностью заполнен, выделяется 1ГБ chunk на второй RAID-группе и т.д. Каждый chunk состоит из 32х страниц по 32МБ, но в данном случае это скорее логическое разделение, так как выделяется все равно пространство минимум в 1ГБ.
Что декларируется? Конечно же, прежде всего, эффективное использование дискового пространства! Разумеется, это большой плюс (особенно когда нет четкого представления, какова динамика роста требований к объему). За счет динамического выделения дискового пространства можно избежать довольно неприятных ситуаций с тем, что нужно создать новый том, а места уже нет, хотя имеющееся дисковое пространство используется неэффективно. Мониторинг используемых ресурсов позволяет заранее спланировать приобретение дополнительных дисков. Кроме того, обещается рост производительности системы за распределения Virtual LUN по многим RAID-группам в рамках HDP Pool (а кто же откажется от такого плюса?).
А есть ли минусы? Ну как же без них! Во-первых, (как я понял) для Virtual LUN можно использовать только ShadowImage, а TrueCopy и Snapshot на текущий момент не работают. Во-вторых, несмотря на то, что заявляется об увеличении производительности за счет распределения Virtual LUN по нескольким RAID-группам, эффект от такого распределения будет очень сильно зависеть от локализации запросов к LUN - так как распределение делается блоками по 1ГБ (если запросы идут к участку данных объемом менее 1ГБ, мы с высокой вероятность будем использовать только одну RAID-группу и уж точно не более двух). Да, мы имеем возможность распределить много LUNов по многим RAID-группам (и это может дать положительный эффект), но вот если, по стечению обстоятельств, запросы будут приходиться на одну RAID-группу, то эффект может быть сильно отрицательный (а вероятность получить именно такую ситуацию при 1ГБ блоке, как минимум, не нулевая). В-третьих, если для систем USP/USP-V есть возможность исключить "пустые" блоки (zero page reclaim), то для AMS2000 такой возможности нет. Помимо перечисленного нужно помнить, что Dymanic Provisioning эффективен не для всех файловых систем (например, для ext2/ext3 эффективность будет сравнительно небольшой, а для UFS использовать HDP вообще нет смысла).
Итог обычен - выбирая решение, нужно не только слушать дифирамбы продавца, но и помнить про технические особенности, а также про то, для чего именно Вам нужен тот или иной продукт.
Постепенно до всех "доходит" необходимость наличия конфигураций СХД с большой плотностью расположения дисков. Вот и HDS выпустила для систем AMS2000 "сверхплотную" полку расширения (High Density Storage Expansion Tray).
В полке вертикально располагается до 48-ми дисков. Конечно же работает hot-swap (для этого полка с дисками вытаскивается на ходу из стойки, это дает доступ для замены как дисков, так и ENC модулей). Диски другие (вернее диски-то те же самые, но салазки другие), соответственно из обычной полки в "плотную" переставить нельзя. Полка логически (с точки зрения контроллера) представляет собой две отдельные системы по 24 диска. Из этого следуют определенные ограничения на максимальное число "плотных" полок: одна для системы AMS2100 и три для AMS2300. Несложно подсчитать, что попытки увеличения чила полок сверх указанного числа приведут к тому, что максимальное число дисков на SAS канал (60шт) будет превышено. Смешивать новые и классические полки можно без проблем, как и смешивать диски их этих полок в одном массиве.
Помимо этого, анонсированы 8Гбит FC порты в AMS2300/2500, а также версия специальная AMS2500DC под постоянный ток и сертифицированная по NEBS Level-3.
Все мы помним, с каким шумом HDS в прошлом году вернулись к тестам SPC со своими high-end системами USP-V. Результат был показан отличный, но это была единственная система, которая все-таки не так часто поставляется. А вот буквально вчера отметились еще и с MidRange массивами:
Результаты впечатляют: флагман IBM DS5300 был оставлен позади паровоза (AMS2500), правда в AMS2500 было на 30 с лишним % больше дисков, что разумеется дает предсказуемый эффект в данном тесте.
Результаты SPC конечно спорны (в плане применимости к реальным задачам), но про это нечасто вспоминают, когда нужно махать флагами. :)