Гиперскалярные, облачные и обычные ЦОДы используют СХД, образованные и управляемые с помощью программного обеспечения, которое управляет большими пулами SSD на множестве серверов. Согласованная производительность этих SSD критична для большинства современных приложений, таких как базы данных и онлайн-торговля, которые мигрировали в облачные системы. Предоставление HMS функций с помощью API, позволяет встраивать HMS-функциональность в стек СХД.
«Мы прислушались к просьбам наших клиентов, которым требуется не просто высокая производительность, а устойчиво высокая производительность”, – сказал Одед Илан, генеральный директор OCZ НИОКР в Израиле. «Наши новые SSD Saber HMS, совместно с прикладными библиотеками и API, впервые позволяют управлять большими пулами SSD на уровне ПО, превосходя ограничения в производительности, которые не возможно было превзойти без этой технологии.»
OCZ предоставляет референтный дизайн и демо-платформу, для демонстрации функционирования Saber HMS. OCZ так же предоставляет прикладные библиотеки и инструкции по программированию, для более простой интеграции технологии HMS в стек СХД и ПО различных OEM.
Накопители серии Saber 1000 SATA от OCZ первыми получили поддержку HMS и доступны в ёмкостях 480GB и 960GB в формате 2.5” x 7мм. Разработанные для чувствительных к цене, ориентированных на чтение, больших по размеру систем, Saber 1000 HMS обеспечивает стабильную производительность, требуемую центром обработки данных при стоимости, обеспечивающей скорый возврат инвестиций. При смещении фокуса в сторону высокого быстродействия при минимуме затрат, OCZ видит HMS в качестве следующего витка эволюции в дизайне СХД.
Более подробная информация по Saber 1000 HMS, в том числе и подробности всей линейки серверных SSD доступна на нашем сайте – www.ocz.com.
Спасибо за внимание, готовы ответить на ваши вопросы.
Наши предыдущие посты:
» Тестирование твердотельного накопителя OCZ Vector 180
» Тестирование по методике SNIA нового твердотельного накопителя OCZ Saber 1000 – для корпоративных пользователей
» SSD SATA против SSD PCI-E | часть первая: теоретическая
» SSD SATA против SSD PCI-E | Часть вторая: практическая
» SSD SATA против SSD PCI-E | Часть третья и финальная: серверная
Комментарии (10)
amarao
21.10.2015 03:09Что ж вы такую важную информацию на geektimes? Их давно ждали.
Алсо, «гиперскалярный цод» звучит как прибор «супер турбо плюс». В ухе что-то жужжит, но осмысленной речью не является.ComodoHacker
21.10.2015 09:47Не поделитесь ли ссылкой, объясняющей что это такое и почему их все ждали? А то эти горе-пиарщики не потрудились.
amarao
21.10.2015 13:33lwn.net/Articles/276025
lwn.net/Articles/518988
И ещё несколько статей было, которые вопрос обсуждали.
Выжимка вкратце: все очень не любят работать с чёрными ящиками с непредсказуемыми сложными свойствами и хотели бы видеть их в виде модулей для ОС.
Простейшее применение: учитывать приоритет дисковых операций при выполнении housekeeping'а (например, терпеть, когда идёт высокоприоритетное IO, и насрательски относиться к медленному низкоприоритетному bulk IO), учитывать содержимое буфферов ОС при выделении места (например, знать, что в буфере ещё -цать мегабайт и надо сразу идти новый блок выделять, а не переупорядочивать существующие) и т.д.
Другими словами, разрешить хорошим программистам написать это как надо, а не как получилось к дате запуска устройства.
ComodoHacker
21.10.2015 09:24А человеческим языком слабо написать? Зачем на Гиктаймс весь этот маркетинг булшит? Двойка вашему PR отделу.
Я бы может и купил эти ваши «Host Managed SSD», если бы вы потрудились объяснить, что это такое и что в них классного. Поиск выводит только на ваши пресс-релизы, похоже это термин вашего изобретения.
vasimv
Вот же достали маркетологи. Сделайте просто массив флэша, без навороченных контроллеров, файловые системы сами разберутся — какие им фоновые процессы нужны, как предохранять от wearout и тому подобное.
wild_one
Плюс.
Правда, пока еще flash-optimized и log structured файловые системы не слишком распространены, но это в большой степени — проблема «курицы и яйца». Рано или поздно все так и будет делаться.
blind_oracle
Некоторым не нужны файловые системы, а нужен блочный доступ. Да и ФС, работающих напрямую с быстрой NAND не так много, к сожалению. В основном, они используются в embedded.
vasimv
Современные файловые уже давно умеют предоставлять блочный доступ (volumes), причем с кучей дополнительных удобств, присущим работой с файлами (легкость переноса и копирования таких volumes, гибкость выделения пространства для него, версионность, снапшоты, сжатие-шифрование и прочее). Думаю, гораздо проще будет научить btrfs или zfs работе с флэшем (и получить большую надежность, прозрачность и скорость работы за счет небольшого расхода ресурсов процессора), чем ограниченный и медленный флеш-контроллер научить zfs-у.
blind_oracle
Умеют конечно, правда в энтерпрайзе такие решения (особенно btrfs) почти не используют.
ZFS на солярке ещё где-то как-то, но там с производительностью тоже свои проблемы (особенно если включить дедупликацию).
Только вот работать с NAND ни ZFS ни BTRFS не умеют. Умеют только достаточно маргинальные F2FS/SQUASHFS/UBIFS и т.п.
Поэтому востребованность прямого доступа к NAND достаточно низка, поэтому не стоит ждать таких решений от вендоров в обозримом будущем. По-моему нет даже какого-то унифицированного интерфейса для этого.
fshp