Компания
161,50
рейтинг
30 мая 2013 в 12:25

Разное → Обзор новой Violin — флеш-СХД, работающей со скоростью, близкой к DRAM


Производитель сделал три смелых маркетинговых заявления:
  • Системе всё равно, запись или чтение – скорость будет одинаковой.
  • При всём этом время отклика стабильно 250-500 микросекунд даже после месяца постоянной нагрузки.
  • Можно вынимать любые комплектующие «на горячую» — системе ничего не будет.

Для начала мы разбили пространство на несколько десятков виртуальных томов и запустили десяток приложений, делающих запись блоками по 4 килобайта в режиме 20/80 (80% записи). А затем продержали модуль под нагрузкой 5 дней. Выяснилось, что маркетинг соврал: скорость записи была очень далека от заявленной в презентации 1 мс и составляла в среднем всего 0,4 мс (при 40/60 дело доходило и до 0,25).

Затем при тест-драйве в офисе для IT-директоров у нас начались настоящие проблемы. Дело в том, что я в приглашении упомянул, что как-то во время демонстрации Disaster Recovery-решения мы вырубили стойку в ЦОДе «на живую», после чего просто не осталось шансов закончить мероприятие мирно. Аудитория ждала крови, и мне пришлось позвать сервис-инженера с отвёрткой.

При 450k IOPS я начал с вытаскивания двух вентиляторов. Это почти не впечатлило аудиторию, потому что хотелось добраться до одного из двух контроллеров и посмотреть, что Violin скажет на это. Минус два вентилятора заставили систему страшно зарычать (она автоматически ускорила остальные), поэтому дальше я услышал только что-то вроде «твою мать», когда инженер просто взял и выдернул один из двух контроллеров, и железка «просела» только на треть по скорости.

Осторожно, трафик: под катом схемы и скриншоты.

Чтобы рассказать что и как сработало при этом и откуда такие скорости, придётся начать издалека. Пролистывайте сразу к архитектуре системы, если хорошо представляете себе архитектуру современных флеш-СХД. Или оставайтесь здесь, если, как сказал представитель одного крупного хостинга, «я знаю что она быстрая, но даже не знаю, что она делает».

Введение


Давным-давно как таковых отдельных систем хранения данных не было: просто у сервера был жесткий диск, на который записывалась вся информация. Потом информации понадобилось писать всё больше и больше, и в результате выделились отдельные хранилища, создаваемые на магнитной ленте, массивах дисков и массивах флеш-дисков.

При этом скорость развития процессоров существенно превышала скорость развития накопителей. Дисковые массивы постепенно становились бутылочным горлышком. Учитывая аппаратные ограничения самой физики жестких дисков, производили начали собирать из них огромные быстрые RAID'ы с дополнительным резервированием и оптимизировать алгоритмы до непосредственно записи. Но всё равно выше головы не прыгнуть, и скорость принципиально не повышалась несколько лет.

Потом появились первые флеш-диски. Здесь очень интересный момент: учитывая текущую инфраструктуру, каждый флеш-диск был для всей архитектуры выше уровнем обычным жестким диском, просто с более высокой скоростью. То есть флеш-решения втыкались на место старых жестких дисков — и весь стек технологий до контроллера записи уже в коробке накопителя думал, что работает с обычным магнитным диском. А это сразу означало огромный overhead из совершенно ненужных для флеш-технологии операций: например, кэш СХД с его алгоритмами оптимизации совершенно не нужен и является просто лишней задержкой для данных (а даже при его отключении данные всё равно «пролетают» сквозь его микросхемы), классическая схема записи по секторам тоже приводила к совершенно лишним замедлением. При этом сами флеш-диски имели другую схему записи, что вело к тому, что приходилось делать работу трижды: прокидывать интерфейс от НЖМД до флеш, писать как на флеш и ещё при каждой записи работать с аналогом garbage collector'а. Сам подход не менялся с распространением SSD на рынке — всё те же проблемы с шиной, кэшем и алгоритмами записи.

В итоге в какой-то момент парни из Violin посмотрели на эту картину и задали себе простой вопрос: почему если флешовая микросхема памяти работает со скоростью более близкой к DRAM, чем к классическим HDD, да при этом энергонезависима, надо обязательно прикручивать её в существующую архитектуру СХД вместо классических дисков? Ответ был только в огромном устаревшем парке протоколов и обработчиков на низких уровнях. Проблема в том, что всю систему пришлось бы разрабатывать с нуля – а это означало серьёзные вложения средств и времени.

Инженеров Violin это не остановило, они заключили контракт с производителем флеш-памяти Toshiba, позволяющий получить доступ к архитектуре чипа. В результате через некоторое время удалось, проделав большую работу, создать серверное хранилище, которое выдавало огромные скорости доступа к информации при фантастически низком уровне задержек даже по сравнению с SSD.

Понадобилось избавиться от понятия диска как такового, чтобы убрать весь кусок стека, работавший по-старому. На выходе получилась штука, которую никак нельзя назвать флеш-диском: у нас на столе натуральные микросхемы, внешне больше похожие на DRAM.

Ограничения флеш-памяти


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

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

В-третьих, если удастся обойти первые два ограничения, возникнет третье: «бутылочным горлышком» может стать контроллер, который должен будет управлять всем этим хозяйством и готовить данные для чтения и записи.

Если не обходить эти ограничения, то обычный SSD даст всего 20-40 процентов прироста мощности. Если обходить — можно добиться просто фантастических чисел. Violin решили эти вопросы довольно интересно.

Посмотрим на архитектуру системы



Вот так выглядит вся система

В той области, которая обозначена как «flash memory fabric» вы можете разглядеть огромную кучу микросхем, на которые смотрят большие чёрные вентиляторы. Это и есть флеш-память, размещённая вот на таких платах:


Отдельный кирпичик флеш-фабрики.

На одном модуле 16 микросхем непосредственно флеш-памяти, несколько модулей DRAM и одна плата FPGA на один «кирпичик». Кирпичиков в фабрике максимум 64 штуки. Все операции с данными в пределах платы осуществляются локально на FPGA, что позволяет не загружать внешние контроллеры этими заботами.

Рядом с этими штуками стоят 4 Virtual RAID-контроллера, которые занимаются обеспечением целостности данных чётностью по алгоритму аналогичному RAID 3 4+1. По умолчанию контроллеры разбивают платы памяти на группы «ответственности» по 5, да и по 1 HotSpare на контроллер. Однако разбиение это в определенной степени «виртуально», одинаковый по скорости доступ каждого контроллера к каждому модулю всегда обеспечивается коммутационной структурой массива, т.е. как сказали бы мы для классической архитектуры СХД, back-end абсолютно честный active-active.

Механизмы обеспечения целостности сохранят данные даже при последовательном выходе из строя нескольких плат памяти, главное чтобы не «умерли» 2 плашки 1 RAID одновременно, ребилд на FLASH накопителях тоже идет на порядки быстрее. Правда есть особенность: при штатной замене система видит битый модуль и отключает питание на нём автоматически (или позволяет отключить питание любого модуля из интерфейса), затем модуль вытаскивается, затем ставится новый и активируется в интерфейсе. Что самое весёлое – всё можно менять «на горячую». Во время тестов мы создавали до сотни томов с разными приложениями, а затем вынимали последовательно 4 модуля с промежутком минут в 20 (один аварийно, три c предварительным отключением через интерфейс) – и всё работало как часы.

Специализированной защиты на случай отключения внешнего питания, типа батареек или суперконденсаторов в блоках питания на массиве не предусмотрено. Это не значит, что массив не защищен от внезапных перебоев в электросети: ему хватает запасенной в БП энергии, чтобы сбросить последнюю транзакцию на FLASH, причем хватает с большим запасом. После исчезновения тока система на остатках энергии может записать все данные на FLASH более 40 раз.

Теперь поднимемся ещё уровнем выше и посмотрим как, с точки зрения архитектуры, массив общается с внешним миром:


Архитектура системы


Итак, на входе есть данные от серверов, которые отправляют данные по стандартным интерфейсам SAN, позволяющим работать с внешним блоком на нужных скоростях и масштабироваться. Затем данные приходят в шлюзы, где полезная информация передаётся в транспортную инфраструктуру на основе PCIe х8 (ничего более медленное для работы с такими скоростями не подойдет в принципе, не обеспечит выдерживание нужного уровня задержек) и доставляются до vRAID контоллеров блоками по 4 КБ. После чего происходит вычисление четности и затем запись на 1 из пятерок планок памяти по 1 Кб на планку.

Транспортная инфраструктура (Virtual Matrix в терминологии Violin) полностью пассивна и управляется 2 дублированными модулями ACM. Эти модули – чисто управляющий элемент массива, они напрямую не связаны с логикой обработки данных, их функция чисто управляющая, они «рулят» электропитанием и следят за исправностью системы. Транспортная инфраструктура обеспечивает возможность связи всех-со-всеми в рамках корпуса Violin даже при выходе из строя части компонент, однако при этом не создает единой точки отказа, разве что пассивную плату можно таковой посчитать, но вероятность выхода её из строя не сильно отличается от, скажем, вероятности пожара в ЦОД.

Теперь самое интересно и сложное: что делать с ограничением флеш-технологии на запись? Решение в общем-то не сложное, но со слов разработчиков Violin эта простота стоила им доставила больше всего сложностей. Решается эта проблема предварительной очисткой ячеек, сразу после потери актуальности данных. Работает это следующим образом: как известно реальная сырая емкость каждого чипа FLASH памяти гораздо больше декларируемой, это делается для равномерной деградации ячеек вне зависимости от профиля нагрузки, таким образом на физическом уровне каждая запись на чип идет в новую ячейку, а старая помечается как доступная для записи. Старые данные при этом остаются там же где и были, поэтому весьма быстро мы приходим к состоянию, когда пустых ячеек не остается и нам приходится перед каждой записью чистить ячейку, как результат скорость катастрофически падает.


Вот так выглядит это т.н. «обрыв» на графиках производительности для SSD

Violin работает немного по другому, FPGA на каждом чипе отслеживает актуальность информации каждой ячейки и, если данные уже не нужны, специальный фоновый процесс под названием garbage collector очищает её. Таким образом, каждая запись всегда идет в пустую ячейку, что позволяет избежать просадки производительности и использовать чипы FLASH-памяти максимально эффективно не только на чтение, но и на запись.

Давайте пробежимся по архитектуре ещё раз:
  1. Контроллеры получают данные и транслируют их дальше.
  2. Модуль управления коммутирует по PCIe х8 все компоненты между собой и обеспечивает мониторинг и управление компонентами.
  3. Флеш-фабрика распределят данные по отдельным модулям и балансирует всё в соответствии с любыми пиками, плюс обеспечивает равномерность износа и резервирование внутренних путей.


Всё что можно реализовано аппаратно на чипах FPGA, то есть обеспечивается принципиально иной уровень скоростей взаимодействия и обработки, чем обычно.

Линейки железа


Теперь посмотрим ещё уровнем ниже на отдельную микросхему памяти. Дело в том, что есть две технологии записи на кристалл – SLC и MLC. SLC хранит 1 бит в каждой ячейке памяти, MLC – больше. В итоге получается так, что на одном и том же физическом кристалле SLC обеспечивает большую скорость и больший ресурс модуля, а MLC позволяет получить больше места.

При этом раньше зависимость была линейная – SLC давал в два раза меньше места при увеличении скорости в 2 раза. Однако, благодаря умному софту Violin (они потратили почти два года, чтобы покопаться в обработке данных на низком уровне) MLC отличается от SLC по скорости записи приблизительно на 50%. Ресурс MLC чипов так же повышен, по статистике Violin даже при предельной нагрузке на запись модули памяти проживут не меньше 4-5 лет.

Вот линейка нового поколения по зависимости объёма места и скорости работы:


А вот отличия в таблице:


Вот так это выглядит в ЦОДе:


По монтажу – все массивы в 3U корпусе, мощность – 2 блока по 480 ватт, тепловыделение — как у мощного 3 U сервера.

Интерфейс и администрирование




Статистика по IOPS на массиве, это максимальная нагрузка, которую смог создать 1 сервер IBM 3850X5


Тa же статистика, но мегабайты в секунду.


Просмотр параметров тома.

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


Здесь показана статистика по отдельному луну.


Защита «от дурака» в действии. Любые действия, могущие привести к прерыванию доступа или потере данных требуют дополнительного подтверждения.


Состояние портов массива.


Окошко общей статистики массива.


Окошко статистики по томам отдельно.


Интерфейс мониторинга аппаратных компонент системы.


Страничка управления томами.


Страничка мониторинга нагрузок на портах.


Главная страница мониторинга, полностью настраиваема, позволяет выводить наиболее нужную администратору, по его мнению, информацию по состоянию массива.

Эти железки в России


Как вообще появилась сама компания Violin? Как уже говорил, довольно просто – когда стало понятно, что мощностей SSD всё равно не хватает для решения современных задач, а размазывать приложения по куче дисков – не самая крутая идея, они заключили партнёрство с Toshiba и начали работать со своим софтом контроллеров на низком уровне, близко-близко к физике процессов. Собрали в 2005-м первые линейки систем, показали какие они крутые, получили различные премий в области IT и стали «стартапом года» в кремниевой долине, а затем перевернули мир систем хранения. В настоящее время многие ведущие производители серверных решений и ПО использовали решения Violin для раскрытия потенциала своих платформ в бенчмарках (TPC-C, VMmark и другие).

В Россию Violin пришли буквально только «вчера», и компания КРОК получила эксклюзивное годичное партнерство. Мы, в свою очередь, на текущий момент обеспечили локальные склады запчастей, обучили сервисных инженеров.

По внедрениям – было несколько десятков крупных интеграций железа прошлого поколения и несколько уже нового. Например, одна очень крупная компания формировала месячный билинг-отчет миллионам своих клиентов 72 часа, а стала формировать всего 22 часа. В VDI-решении удалось избежать простоя (ожидания) ответа от системы хранения за счет ультракороткого времени отклика, что позволило загрузить ядра так, что вместо старых 10 пользователей на ядро получилось 25 пользователей на ядро при аналогичной производительности, а это ещё экономия на лицензиях и вычислительном оборудовании.

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

И всё равно многие не верят в фантастические скорости флеш-систем, поэтому именно для Violin мы делаем не только тест-драйвы, где можно потыкать пальцем в железку, но и расчёты и пробные внедрения. Например, когда клиенту нужно было развернуть СХД инфраструктуру VDI на 1000 пользователей, при 50.000 IOPs, на 50Тб данных, рассматривалось два варианта: две СХД 7 х 200Гб Cache SSD 180 x 600Гб SAS против Violin 6212, 12Тб RAW = 7Тб Usable для «горячих» данных и 60 х 600Гб SAS 18 x 3Тб SATA для хранения «медленных» данных. Результат – экономия почти в два раза при повышении производительности от заявленных 50k IOPS до 200 000 IOPS.

Если интересно в деталях, как так получилось, могу просчитать решение вашей задачи с использованием флеш-СХД, пишите на vbolotnov@croc.ru. Я советую на всякий случай просто иметь такой проект и положить в стол – если вдруг понадобится резко ускориться, можно будет достать и показать расчёт.
Автор: @BoVados
КРОК
рейтинг 161,50

Комментарии (62)

  • +7
    Вечный цикл за пару секунд… Можно узнать хотя бы примерную стоимость для примеров, приведенных выше?
    • 0
      Цена высокая (ниже в комментариях, кажется, ошиблись на порядок), но при этом получается значительно дешевле в сравнении с mid-range и hi-end массивы с таким же уровнем IOPs построенными на базе большого количества дисков SAS 15000 обр/мин, и даже дешевле конфигураций, где аналогичная производительность получается путем различных «хитростей» в виде кеширования наиболее «горячей» информации на SSD. По состоянию месяц назад система обеспечивала самый дешевый IOPs в галактике. По конкретике — надо писать на почту, потому что вендор имеет гибкую политику скидок под конкретные проекты.
  • +1
    Раньше все хотели коробку сникерсов, а щас мечтают о такой штуке домой для торрентов )
    • +8
      Для торрентов вполне хватает HDD десятилетней давности.
      • +2
        Десятилетние хрустеть громко будут, думаю.
      • +1
        неа. у меня часто при количестве активных раздач больше 50 появляются проблемы со скачкой, торрент пишет, что диск загружен на 100%.
        Недавно вообще появились проблемы: невозможно одновременно качать насколько раздач и смотреть фильм с того же диска. Думаю что нужно собирать рейд 10.
        • 0
          Что у вас за канал? Что за диск? Может, фрагментирован очень сильно? Попробуйте qBittorrent, в нем есть кеш записи на диск, иногда очень полезен бывает.
          • 0
            Да нет, я думаю, диск просто медленный. У меня в машине остался с давних времён террабайтник IDEшный, какой-то из гриновых вестернов 5400-х — с ним примерно та же история (я на нём, собственно, только торренты и фильмы держу).
            • +2
              Ну не бывает настолько медленных дисков, если у вас канал не гигабит. Он у вас, наверное, очень сильно фрагментирован, и на поиск уходит больше времени, чем на чтение.
              • 0
                Битрейт у фильмов большой — процентов у 60-70 свыше 15 Мбит. Ну и фрагментация, понятное дело.
                • 0
                  Ну, предположим, у фильма пиковый битрейт 30 мегабит, это, грубо говоря, 4 мегабайта. Линейная скорость чтения плохого и старого винчестера в вакууме, скажем, 30 мегабайт в секунду. Винчестер должен быть крайне фрагментирован, чтобы не позволять смотреть фильм и качать / раздавать торренты одновременно. На деле, мне удавалось достичь скорости винчестера через сеть только на гигабитном канале. Линейная скорость чтения на моих винчестерах, в среднем, 80 мегабайт в секунду.
                  • +2
                    А, я допёр в чём дело. Он на одном шлейфе с крайне редко, но все же использующейся оптикой висит — если я еще не до конца забыл все, он в таком случае должен работать на UDMA-4, а это пик в 66.7 Мбит.
                    • 0
                      UDMA4 это 66 мегабайт в секунду, а не мегабит. Поэтому это не должно влиять.
                      Мне тоже кажется что дело в сильной фрагментации. Или какие-то беды есть на диске, на обработку которых тратится время.
                      • 0
                        Хм, таки-мегабайт? Значит, уже ничего не помню :)
                        А касательно диска — на замену, и вся недолга. В новой машине ему места с гарантией уже не будет — это такая переходная конфигурация получилась в сей раз.
                        • +1
                          Тут просто запомнить: IDE/PATA — параллельный интерфейс, поэтому скорости обычно в байтах.
                          На последовательных интерфейсам скорости, соотвественно, будут в битах (SATA/SAS, Network и т.п.).
                          • 0
                            Просто диск не может одновременно читать и писать из нескольких мест на пластине. скорость начинает катастрофически падать, когда головы мечутся по диску — вот это время когда головки находятся в движении между дорожками диска ооооочень сильно влияет на скорость чтения/записи, которая падает в разы. Этот же эффект я наблюдал на террабайтном винте при раздаче 50+ торрентов при 50+ пиров на каждом. тут или уменьшить количество раздач или терпеть падение скорости.
                            • 0
                              Совершенно верно. Головы при сильно фрагментации бегают намного больше.
                            • 0
                              Бороться с этим злом призван NCQ :)
                              • 0
                                Даже NCQ не поможет при чтении 60+ больших файлов одновременно с одного диска (та ситуация, когда кеш жесткого диска никак не спасает положение). Скорость упадет, чуть меньше чем без NCQ, но всё равно ощутимо.
                                • 0
                                  Согласен. Просто выше речь шла о торрентах, по идее, там должен неплохой выигрыш получиться.
          • 0
            Канал — 90 Мбит

            Хард — WD Green 1.5 Tb.

            Да надо бы посмотреть что там с фрагментацией.
          • 0
            Я тут намедни тестировал…
            Это CristalMark, тест конечно не лучший, но показательный.
            Это LSI Megaraid SAS 6Gb/s, но винты висят SATA и это RAID0 из 4х винтов

            * MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]

            Sequential Read: 599.443 MB/s
            Sequential Write: 555.758 MB/s
            Random Read 512KB: 54.962 MB/s
            Random Write 512KB: 170.105 MB/s
            Random Read 4KB (QD=1): 0.746 MB/s [ 182.2 IOPS]
            Random Write 4KB (QD=1): 7.986 MB/s [ 1949.6 IOPS]
            Random Read 4KB (QD=32): 5.261 MB/s [ 1284.5 IOPS]
            Random Write 4KB (QD=32): 7.961 MB/s [ 1943.6 IOPS]

            Test: 1000 MB [C: 0.4% (14.8/3721.3 GB)] (x5)
            Date: 2013/05/14 16:57:57
            OS: Windows Server 2008 R2 Server Standard Edition (full installation) SP1 [6.1 Build 7601] (x64)
            LSI RAID0 (4HDD+System)

            Самое занимательное это Random Read 4KB и Random Write 4KB а ведь торрент пишет мелкими рандомными блоками.
            Тут наверное может помочь только предварительное кеширование в пямять.
            А у вас железо то слабое, у самого подобное в качестве дом. сервера, и теже проблемы, особенно если в торренте много файлов.
            Но обычно потом разгоняется и забивает на всю 100мбит. Кстати а если по SMB качать файл с сервера то выдает 33Мб/сек.
            • 0
              При обычных условиях, блок меньше 64КБ в торренте сделать сложно. Для фильмов это обычно 2-8МБ.
              • 0
                Это блок который тянет с 1 пира или то что сбрасывает на диск? При нехватки памяти он будет постоянно сбрасывать на диск.
                • 0
                  Блок, который тянет с пира. qBittorrent., например, имеет встроенный кеш записи, да и, наверное, все клиенты на libtorrent имеют этот кеш, про другие не знаю.
        • –1
          Как правило, ширина интернет канала на порядки ниже пропускной способности диска, а значит диск не может являться фундаментальным ограничением.
          Просто увеличьте размер кэша (и на чтение и на запись) в вашем торрент-клиенте (uTorrent, например, позволяет это сделать)
  • +1
    Очень интересная железка! В одной Health Care Insurance Company, на такой железке крутили виртуальные машины для сотрудников, а их машины были лишь тонкими клиентами.

    Но такая штука и стоит не очень дешево: в один момент были разговоры прикупить такого монстра в компанию, фигурировала цифра в $40K за 6232, но так и не прикупили ;(
    • +3
      Я думаю, в цене вы ошиблись на один нолик. Порядка $40K стоит обычная СХД на SAS дисках, тот же экваллоджик или нетапп.
    • +3
      V-6616 может обойтись в $600K+, врядли линейка на MLC будет на порядок дешевле :)
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      При создании контейнера в системе резервируется место от 15 до 50% общей свободной ёмкости именно по этой причине. При этом процент выбирается исходя из профиля нагрузки, например 15% резерва для чтение/запись 80/20 и 50% для 0/100. Это, конечно, уменьшает доступное пространство, но главная задача таких систем – производительность, пусть и в угоду ёмкости.
  • +1
    Violin работает немного по другому, FPGA на каждом чипе отслеживает актуальность информации каждой ячейки и, если данные уже не нужны, специальный фоновый процесс под названием garbage collector очищает её. Таким образом, каждая запись всегда идет в пустую ячейку, что позволяет избежать просадки производительности и использовать чипы FLASH-памяти максимально эффективно не только на чтение, но и на запись.

    Разве не все современные SSD работают по такому же принципу? Встроенные сборщики мусора везде есть, ну и TRIM со стороны ОС.
    • 0
      Да, различные технологии ускорения записи есть и конкурентов, однако если посмотреть на аналитический график в посте, то вы увидите, что почти все решения страдают значительным «обрывом» производительности. Почему так происходит? Точного ответа я не знаю, но есть некоторые соображения. Во-первых, до недавнего времени дисковые СХД hi-end и mid-range класса garbage collecting-ом вообще не занимались, за редким исключением. Во-вторых, вероятно не все алгоритмы «одинаково полезны» — может конкуренты пожадничали с резервируемым пространством. В любом случае “write cliff” в SSD системах — это проблема, которая в большинстве систем не решена.
  • 0
    Какая красавица.
  • +1
    Очень интересно! До этого вживую сталкивался только с hp eva 4400 на fc -дисках и ibm storewize v7000 на дешевых sas дисках с кэшем ssd! По сравнению с ними — данная штука — взлетает! Впечатлен!
  • 0
    Вопрос разбирающимся, обычная бытовая SSD в домашнем компьютере тоже работает не оптимально из-за груза старых дисковых протоколов?
    • +1
      Да, да, и ещё как да!
      Но не совсем из-за груза, скажем так проблема в том что пользовательские файловые системы по большей части разрабатывались именно для ДИСКОВ, и контроллеры современных SSD делают из массива памяти диск, что само по себе не есть хорошо, тк там свои фишки…
      • 0
        А в этом направлении кто-нибудь уже продвинулся?
    • 0
      ОС общается с контроллером, в существенной мере точно так же, как если бы это был обычный жесткий диск, а контроллер уже обращается к чипу. Это решает большую часть проблем совместимости, добавляя естественно некоторый оверхед, но сам SSD при этом работает вполне себе нормально т.к. контроллер к нему обращается уже не используя никаких старых протоколов.
      Определенная проблема есть разве что в файловых системах, но её решать в ближайшие годы никто не будет т.к. незначительный выигрышь в производительности никак не стоит сломанной обратной совместимости.
  • 0
    Блин, интересное решение, надо будет заняться…
  • +2
    Судя по прайсам, в России V-6616 Violin Memory 16.3TB Performance Flash VIMMs4x vRAID Controllers, 1M IOPS будут стоить 578 399 $
    • 0
      А где вы прайс нашли, если не секрет? То есть я вижу цену на топпрайсе, но что-то сомневаюсь, что они по факту смогут продать.
  • +1
    > скорость записи была очень далека от заявленной в презентации 1 мс и составляла в среднем всего 0,4 мс

    Величины указаны в «мс» — это время одной операции, или все же, как у Вас указано, скорость записи?

    Получается, что операции в 2.5-4 раза быстрее обещанного вендором?
    • 0
      Вендор пишет 2 варианта: меньше 1 мс в общей презентации и до 0,25 в результатах синтетических тестов. Мы проверили насколько вторая ситуация чаще встречается на практике.
  • –4
    Раз количество циклов записи всё равно ограничено — то всё равно ерунда. Ждём мемристоры или что-то подобное.
    • +2
      Статистика по ДЦ показывает что современные шпинделя умирают от износа раньше чем на SSD энтерпрайз уровня заканчивается резерв по циклам записи.
      Мемристоры конечно дешевле и их не запускают на рынок ибо на ССД напилить можно больше, что является лишним доказательством заговора мирового капитализма.
      • –1
        Лично меня не очень заботит статистика по ДЦ, зато заботит статистика по домашним системам. Ну может быть и по мелким серверам.
        • +1
          Ну рассматриваемое в статье железо вроде совсем не для этой ниши )
        • 0
          Вы тогда темой ошиблись — эта штука не имеет совершенно ничего общего с малыми серверами или домашними системами. Лям иопсов — да в домашнем компе оперативка медленнее нагружена.
  • +2
    Давным-давно как таковых отдельных систем хранения данных не было: просто у сервера был жесткий диск, на который записывалась вся информация. Потом информации понадобилось писать всё больше и больше, и в результате выделились отдельные хранилища, создаваемые на магнитной ленте, массивах дисков и массивах флеш-дисков.
    Неприятно это писать, но исторически в 60-х годах все выглядело так же как и сейчас: Терминалы, вычислительные процессоры, хранилища данных превратились соответственно в тонкие клиенты, сервера и СХД. Ребрендинг. Есть замечательные документы по storage tiering от компании IBM описывающие характер хранения данных в смешанной системе хранения data cells + mag drums + mag tape (писать на диски придумали позже). Было ведь время когда к оперативной памяти (data cells: тогда были распространены ферриты) относились как к полноценному хранилищу, а не как к JAVA-помойке :( (Для олдфагов: bitsavers.trailing-edge.com/pdf/ibm/370/princOps/GA22-7000-4_370_Principles_Of_Operation_Sep75.pdf )
    А продукт супер: в сожалению дороже аналогов от oracle но будем надеяться что хотябы по иопсам Виолончель догонит старших братьев, а вот архитектурка хороша :) (Пятитысячник выжимает полтора мегайопса: www.oracle.com/us/043970.pdf, при том что он уже старенький старенький стал уже, но зато всего один юнит толщиной)
    • 0
      Пятитысячник при этом ёмкость имеет, мягко говоря, немного меньше.
      • 0
        Он (пятитысячник) пардон четыре года уже бегает по ДЦ и радует многих биржевиков бешенными иопсами. Назначение этих систем кэширование горячих данных. Тому кто сейчас соберет петабайтное ссд хранилище я искренне сочувствую, хотя дай ему бог здоровья.
        Я в общем не говорю что виолончель отстой, но могли бы и поднапрячься и обогнать одноюнитового ветерана сделанного но современным меркам уже из г-на и палок.
        Да и личный опыт показывает — сколько волка не корми — у слона всеравно толще. Как ни разгоняй внешнюю хранилку, а на PCI шине всеравно быстрей бегает.
        • 0
          Я о том, почему он дороже пятитысячника.
          • +1
            Этот факт тяжело не признать :)
            На самом деле пятитысячник давненько устарел, ибо с появлением сверхтяжелых сервачков с оперативой на 1-2 ТБ — задачи кэширования дурной инфы делаются на рамдисках или непосредственно в оперативе.
            пример сервачка прилагается, а то вдруг кто не в курсах: www.itcreations.com/show-server.asp?server_id=6516 или h10010.www1.hp.com/wwpc/us/en/sm/WF05a/15351-15351-3328412-241644-4222584-4231377.html?dnr=1
            • 0
              Ну терабайт ОЗУ нынче даже в BL685, например, можно впихнуть — были бы деньги ))
              • 0
                Для наглядности серваки годичной давности. Свежаки могут и поболе думаю.
  • +1
    Интересно, как принимается решение, к примеру, о внедрении VDI — что использует ынтырпрайз вместо классических десктопов и на каких объемах это становится выгодно? Может есть где-то в сети хороший пример расчетов? (Интересно будет сравнить выгоду по сравнению «переписать под web», хотя понятно, что не всегда применимо.)
  • 0
    Хочу домой двухтерабайтник такой.
  • 0
    скорость записи… 1 мс

    Я чего-то не понимаю, или массу теперь в джоулях взвешивать?
    • 0
      Может они там латенси иммели ввиду?
  • 0
    А есть результаты тестов при заполнении хранилища от 50 до 80-90%?

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

Самое читаемое Разное