FlashCache. Как использовать Flash в СХД НЕ как SSD?

    image

    Использование Flash-памяти для современных систем хранения стало уже почти повседневным делом, понятие SSD — Solid-State Disk, широко вошло в практику энтерпрайз-систем хранения и серверов. Более того, для многих понятия Flash и SSD стали едва ли не синонимами. Однако, NetApp не был бы собой, если бы не нашел для использования Flash лучший, свой собственный способ его использования.
    Как же можно использовать Flash для системы хранения, но НЕ в виде SSD?


    Начну, пожалуй, с определения того, что такое SSD.
    SSD или Solid-State Disk (дословно: «Твердотельный диск», диск без движущихся, механических частей) это способ представить для OS пространство энергонезависимой памяти по технологии Flash как виртуальный, эмулированный жесткий диск.

    Наиболее традиционным видом «non-volatile memory», то есть энергонезависимой памяти, для OS и приложений являются «жесткие диски», HDD. С жесткими дисками умеют работать все OS, поэтому вполне естественно было бы, для упрощения работы и укорочения «пути на стол потребителя», не городить для каждой OS поддержку какой-то своей архитектуры использования Flash, а на самой Flash-memory сэмулировать простой и понятный для драйвера любой OS псевдо-«жесткий диск», и работать в дальнейшем с ней как с жестким диском.

    Плюсы такого подхода — это просто. Это позволяет использовать уже существующие драйвера в любой OS и не городить специфическую поддержку для каждой из них.
    Минусы — эмуляция это все же эмуляция. Ряд особенностей Flash бывает достаточно непросто использовать и учитывать, работая с ним как с «диском». Пример — достаточно непростая организация перезаписи байта данных в Flash.

    NetApp выбрал для использования Flash свой особый путь. Он использует Flash-memory не в виде эмулированного «диска» (storage), а непосредственно как память (memory).

    image

    Ни для кого не секрет, что в хранимых на дисках данных значительную часть занимают данные, к которым редко обращаются. В англоязычной литературе их принято называть «cold data», и, по оценке, объем cold data в общем объеме хранения может достигать 80%. То есть к примерно к 80% хранимых данных приложения обращаются сравнительно редко. Это значит, что примерно 80% денег, которые мы потратили на все еще очень дорогие SSD, потрачены зря, и не дают нам никакой фактической отдачи.

    Cold-данные, которые лежат на SSD, могли бы точно также лежать на дешевых SATA, все равно они в данный момент лежат без движения. Оттого, что он лежат и занимают место на супердорогих SSD, наша система в целом быстрее работать не будет, ведь преимущество SSD проявляется лишь в момент обращения к данным, а «просто лежать» данные могут на любом диске. Зато мы теряем это место для тех активных данных, которые, будучи размещенными на SSD, дали бы прирост производительности. «Холодные данные» это классическая «собака на сене». И сами возможности SSD не используют, и другим, нуждающимся, не дают.

    Казалось бы в чем проблема? Определи «холодные» данные, отдели их, и храни их на отдельном хранилище.
    Но беда в том, что в эти 80% в каждый момент времени попадают разные данные. Данные в базе о проводках за прошлый квартал, весь следующий квартал будут лежать нетронутыми и «холодными», однако в период подготовки годового отчета они снова станут очень даже «горячими».

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

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

    Использовав Flash не в качестве storage, а в качестве memory, NetApp очень элегантно решила проблему cold data.

    Все вы, уверен, знаете, о принципах работы RAM-кэша в современных системах хранения данных.
    Кэш — это промежуточное оперативное хранилище данных в быстрой RAM.
    Если клиент запрашивает блок данных из хранилища, то он читается и при этом попадает в кэш.
    image

    Если далее к этому блоку снова будет обращение, то он отдастся клиенту не с медленных дисков, а из быстрого кэша. Если к этому блоку долгое время не будет обращения, то он автоматически вытеснится из кэша, а на его место будет использовано более востребованным блоком.
    image

    Таким образом мы видим, что данные в кэше это всегда, «по определению», 100% hot data!

    Теперь давайте представим, что мы используем flash не как диск, а как память, как некоторого рода «кэш второго уровня», дополнительное пространство. Обычно у нас в системе хранения есть сравнительно медленное дисковое пространство, и значительно более быстрый RAM-кэш. Увы, мы не можем бесконечно увеличивать размеры RAM-кэша. Это, по меньшей мере, очень дорого. Однако если у нас есть довольно емкая, пусть и не такая быстрая как DDR DRAM память Flash, мы можем ее поставить «кэшем второго уровня» к уже имеющемуся RAM-кэшу.

    Теперь механизм кэша работает следующим образом: данные попадают в RAM-кэш (обычно его размер, в зависимости от типа и мощности контроллера составляет от 1 до 96GB), и находятся там, пока не, будут вытеснены более актуальными данными. Вытесняясь из RAM-кэша, они не удаляются, а переносятся в Flash-кэш (размером, обычно, в зависимости от мощности контроллера, его типа и количества возможных модулей, от 256GB до 4TB). Там закэшированные блоки находятся до тех пор, пока они не «устареют», в свою очередь, и не будут вытеснены актуальными данными. И только тогда считывание пойдет с дисков. Но пока эти данные находятся во FlashCache, чтение их происходит примерно в 10 раз быстрее чем с дисков!
    image

    image

    * Обратите внимание, что картинки взяты из руководства по использованию FlashCache, и там он называется PAM — Performance Acceleration Module, это его «старое» и «внутреннее» название, то есть «PAM» это не «RAM».

    Каковы же результаты использования FlashCache? Насколько заявленная эффективность показывает себя на практике?
    Для сравнения производительности NetApp участвует в программе тестирования с помощью стандартного и широко принятого индустрией теста SPECsfs. Это тест «сетевых файловых систем», то есть NAS, по протоколам NFS и CIFS, результаты которых легко экстраполировать и на другие задачи.

    В качестве эталонной системы взята midrange модель FAS3140 с 224 дисками FC (это 16 полок по 14 дисков в каждой, полный 48U-шкаф дисков FC!).
    Не секрет, что очень часто в систему высокой производительности по вводу-выводу, при ее конфигурировании, вынуждены ставить много дисков (у нас принято выражаться «дисковых шпинделей» — disk spindles). И очень часто именно производительность в IOPS, а не емкость хранения, диктует количество используемых системой дисков. Много дисков в такой системе это вынужденная мера обеспечения высокого быстродействия ввода-вывода.

    Вы видите, что такая система показала на тесте SPECsfs2008 CIFS 55476 спекмарковских «попугаев» по производительности ввода-вывода.

    Возьмем теперь такую же систему, но теперь с платой FlashCache внутри, но на этот раз всего с 56 такими же дисками FC (это всего 4 полки дисков, в четыре раза меньше дисковых «шпинделей», обычно определяющих производительность в IOPS)
    Мы видим, что для системы, стоящей (суммарно диски, полки, плюс FlashCache) на 54% дешевле, при том же уровне производительности в «попугаях» достигнут заметно меньший уровень задержек, а за счет меньшего количества дисков на 67% улучшились показатели энергопотребления и занимаемого системой места в стойке.

    image

    Но и это еще не все. Третья система содержит вместо FC-дисков 96 дисков SATA, обычно характеризующиеся невысокой производительностью в IOPS, и снова FlashCache.
    Мы видим, что даже с использованием сравнительно «небыстрых» SATA на 1TB, наша система показывает все те же показатели быстродействия, обеспечив при этом на 50% больше доступной емкости, чем система на дисках FC без FlashCache, и на 66% меньше энергопотребление, при примерно равном уровне задержек.

    Практический результат получается настолько мощный и убедительный, что NetApp продала своим клиентам петабайт флэша в виде FlashCache, всего через полгода после объявления этого продукта, и, насколько я знаю, объемы продаж продолжают расти (NetApp даже утверждает что сегодня они являются вторым по объемам продавцом Flash-памяти в мире, после Apple, с их iPod/iPad/iPhone).

    Но FlashCache не работал бы так эффективно, если бы не (вновь!) возможности лежащей ниже, под ним структуры WAFL. Помните, рассказывая про WAFL, а затем про те или иные «фишки» систем хранения NetApp я несколько раз повторил уже, что WAFL это самый «фундамент», основа всего того, что умеет NetApp.
    Что же «сыграло» в данном случае?

    Те, кто всерьез и глубоко занимается перспективами использования SSD в производительных приложениях уже знает одну, крайне неприятную особенность Flash как технологии — очень низкую производительность на случайной записи (random write).
    Почти всегда, когда заходит речь о производительности SSD, производители показывают грандиозные результаты случайного чтения, однако почти всегда так или иначе обходят стороной вопрос производительности случайной записи мелкими блоками, а ведь это, в типичной рабочей нагрузке, примерно 30% всех операций.

    Это показатели по IOPS у популярного высокопроизводительного enterprise-class SSD FusionIO
    image

    А это — табличка по производительности в IOPS для популярного Intel X25M, «спрятанная» в документации «для партнеров». Обратите внимание на выделенное и подчеркнутое.
    image

    Такие «сюрпризы» встречаются почти у любого SSD, любого производителя.
    Связано это с непростой процедурой записи в ячейку Flash, организованных в блоки. Для (пере)записи даже небольшого блока, надо полностью стереть и записать снова всю содержащую его «страницу» Flash. Операция эта небыстрая и сама по себе, даже если не брать во внимание ограниченность этих циклов.

    Как же в данном случае «играет» WAFL?
    Дело в том, что в системах NetApp, использующих WAFL, которая «оптимизирована на запись», а если подробнее, то записи, как я уже рассказывал, пишутся длинными последовательными «страйпами», а за счет того, что такая схема позволяет не держать записи в кэше, а записывать их непосредственно на диски, на максимально возможной для этих дисков скорости, кэш в системах NetApp практически не используется на запись. Соответственно не используется на запись и FlashCache, сильно упрощается и алгоритмическая часть, и решается проблема с низкой производительностью Flash на запись. Flash в данном случае вообще не используется на запись, записи прямиком, через буфер RAM, идут на диски, держать их в кэше просто не нужно, то есть мы используем Flash только в самом эффективно работающем у него режиме — random read (иногда наполняя его новыми данными, взамен выбывших, с помощью также неплохо переживаемой им операцией sequental write).

    Таким образом, нетрудно видеть, что использовав Flash «как память» в виде кэша, мы автоматически храним в ней только активные, горячие данные, те данные, повышение скорости доступа к которым по настоящему дает выгоду использования, и устраняем проблемы с низкой производительностью и конечностью ресурса записи во Flash.
    Да FlashCache тоже недешев. Но вы гарантированно используете в дело потраченные на него деньги, все, а не только 20%. И это именно то, что называет NetApp «эффективностью хранения».

    Подробнее и на русском о FlashCache, можно почитать в технической библиотеке компании Netwell, публикующей переводы на русский язык официальных технических руководств NetApp.

    Идея использовать Flash-память более эффективным и «прямым» способом, чем просто эмулировать на ней «жесткие диски», по моему наблюдению распространяется в индустрии все шире. В ряду занявшихся этим направлением и практичный Adaptec, представивший свой MaxIQ, и CacheZilla в ZFS, и Microsoft Research, опубликовавший интересную научную работу Speeding Up Cloud/Server Applications Using Flash Memory (краткий обзор в виде презентации )

    На фотографии в начале статьи — установка FlashCache (некоторое время он назывался PAM-II — Performance Acceleration Module, Generation 2, был еще PAM-I, на DRAM, и использовавшийся для кэширования метаданных NAS )
    NetApp
    Компания
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 65

      0
      Интересно в домашних условиях кто-нибудь ее пробовал использовать?
        +3
        Подобный, но упрощенный алгоритм используется в Seagate Momentus XT там 4Гб ssd. Он туда кешит часто используемые файлы.
          +2
          Если под «ее» вы понимаете FlashCache, то это просто невозможно, это компонент стораджа, и его внутренней OS.
          Но если как сам принцип, то отчего нет, я же привел в конце примеры с Adaptec MaxIQ и ZFS Cachezilla.

          Но тут еще раз отмечу, что важну роль играет отсутствие random-записи в flash, на котором он обычно поразительно неэффективен.
            0
            Я имел ввиду систему вобщем, а не FlashCache в частности.
            +3
            Зачем??? Поставьте небольшой SSD под систему и программы и он у вас 100 лет проживёт. Вот тут я раздаю хабровчанам утилитку для оценки жизни SSD — бесплатно. Запускаете, мониторите систему несколько дней — получаете результат. Пользователи linux'a и Mac'a могут ввести значения записей вручную на сайте и получить примерную калькуляцию.
              0
              Осталось совсем немного подождать — Intel уже выпускают новый чипсет с поддержкой подобной технологии — www.iguides.ru/forum/showthread.php?t=19955
                0
                Но только разница в том, что Intel еще только выпускают, а NetApp уже продал несколько десятков тысяч систем c FlashCache за два с половиной года, это значит, что основное количество проблем с ними уже решено, а вот что будет у Intel — я бы не был столь оптимистичен, считая, что сразу после выхода он будет готов в продакшен.
                  0
                  Я рад за NetApp и их продажи. Вы наверное упустили из виду, что стоимость решения NetApp — тысячи долларов, что недоступно рядовому владельцу компьютера. А Intel выпускают чипсет для нас с вами, который будет вполне доступен.
                    0
                    А почему вы решили, что я говорю о «рядовых владельцах компьютеров»?
                      0
                      Если вы не заметили, в этой ветке обсуждений поднялся вопрос именно об использовании новой технологии для домашних компьютеров. Поэтому я и оставил сслыку на новость о сокром выпуске подобной технологии от Intel.

                      К чему вы вообще начали сравнивать решения NetApp и Intel, я просто не понимаю.
              0
              Интересно а какова стоимость этой штуки по сравнению с обычным DDR? ИМХО, сегодня проще взять и воткнуть 16Gb памяти. Или взять нормальный железный raid (если нужно работать с большими объемами) с приличным кешем и воткнуть в него обычные небольшие и очень дешевые диски, организовав raid-10, например…
                0
                Стоимость существенна, но значительно ниже, чем у сравнимого по результатам быстродействия количества жестких дисков (а в том числе не забывайте про энергопортебление и охлаждение всей кухни).

                Примеры там выше в тексте приведены, когда сравнимое быстродействие получается на в 4 раза меньшем количестве дисков (при этом еще и на 54% дешевле, даже без учета электричества и охлаждения).

                > Или взять нормальный железный raid

                  +1
                  > Или взять нормальный железный raid

                  Что такое «нормальный железный raid», и чем он отличается от «ненормального»? ;)
                    –1
                    Например, наличием кеша.
                      0
                      Любая система хранения имеет кэш. Вопрос в его размере и в том, что происходит, если нужные данные в него не помещаются.
                      Сейчас DRAM примерно вдесятеро дороже эквивалентного объема на Flash.
                        0
                        Не все raid'ы оснащены собственным кешем.

                        А вообще раньше были в продаже подобные штуки:
                        www.directcanada.com/products/?sku=11830DR4758&vpn=GC-RAMDISK&manufacture=GIGABYTE

                        Это PCI плата со слотами для DDR — в системе выглядит как SATA диск. Плата стоит совсем немного, а памяти такой навалом можно либо бесплатно нарыть, либо купить за сущие копейки. Поставить таких плат во все слоты и выдать эти ram-диски под системный кеш.

                          0
                          Ну ОК, уговорили. Рассчитайте, пожалуйста, сколько будет стоить ваше решение, емкостью, ну давайте, для простоты, равное емкости самого маленького FlashCache — 256GB.
                          Также не забудьте и то, что такую емкость должна поддерживать OS, а также то, что она должна быть энергонезависимой.
                            0
                            Зачем ей быть энергонезависимой если это под кэш?
                              0
                              Но кэш-то у вас должен будет работать на запись и чтение, значит потеря данных в кэше, не попавших на диски, недопустима.

                              В случае FlashCache (к слову сказать FlashCache энергонезависим, так как flash) он не используется под запись потому что под ним WAFL, которой вследствие ее механизма работы кэш на запись не нужен, для любой другой файловой системы кэш на запись необходим, если мы только не делаем какой-то узкоспециальный продукт для read-only данных.

                              К тому же я сильно сомневаюсь, что «любая OS» сможет простым образом использовать такой RAM-SATA (как это происходит в случае FlashCache, который абсолютно прозрачен для операций системы и данных), значит поверх придется городить еще какую-то приблуду для автоматического tiering-а данных на него, о проблемах с этим связанных я уже тоже писал, частью в посте, частью в комментах ниже про EMC FAST.
                  +2
                  >SSD или Solid-State Disk (дословно: «Твердотельный диск»)

                  На самом деле расшифровка Solid-state drive т.к. ничего круглого подобного диску в них не имеется:)
                    0
                    По этому поводу существуют разные мнения, одно из них озвучено выше, второе — вами. В принципе ваша поправка несущественна.
                      0
                      В принципе, его поправка существенна и правильна. SSD расшифровывается именно как solid state drive, или, по-вашему, HDD — hard disk disk?
                        0
                        И она сильно меняет то, что написано дальше?
                          –1
                          Нет. Но общее качество статьи понижается. Так сложно исправить вместо того чтоб спорить на счет незначительности ошибки?
                      0
                      Замечание верно, но в слове «Disk» круглого не подразумевается. Вот если бы «Disc» написал, то 100% ошибка.
                      0
                      Ну, это прикольно, что скорость выросла и задержки уменьшились. Но зачем хвастаться тем, что «на 67% улучшились показатели энергопотребления и занимаемого системой места в стойке.» при том, что система дала 16 Тб дискового пространства вместо 64 Тб в исходной. В чем заслуга то?
                        +2
                        Тем, что за электричество потребляемое системой, и кондиционерами нужно платить. Иногда это бывают довольно существенные затраты. В рядовом датацентре затраты на охлаждение сегодня составляют примерно половину от общего его энергопотребления, то есть кондиционеры в нем потребляют столько же, сколько вся «IT-активка». Снизить этот процент было бы весьма заманчиво, так как отливается во вполне полновесных долларах экономии бюджета.
                        В арендованных же датацентрах расчет аренды идет из занятых «юнитов» в стойках, и уменьшение их количества также снижает затраты на эксплуатацию, подчас весьма существенно.

                        Выше же я уже писал, что емкость сегодня уже не главный параметр при выборе количества дисков, главный — быстродействие. Именно ради быстродействия берется так много дисков, а не потому, что нужно столько места. В сегодняшних системах хранения очень часто емкость дисков заполнена едва ли на 10% (и это еще одна проблема снижения эффективности традиционных систем), а много дисков покупаются ради IOPS.

                        Если же важна именно емкость, то можно взять диски SATA, с ними, с использованием FlashCache, можно достичь того же быстродействия, но получить больше емкости, об этом третий пример. К сожалению на имеющейся у меня картинке рассматривалась другая система, FAS3160, под NFS, поэтому я не стал ее включать в пост, но смысл результата тот же.

                          –1
                          Капец, вот это пропасть непонимания. Давайте рассмотрим приведенный Вами в статье пример.

                          В исходной системе было 64 Тб дискового пространства. Пусть на каждый ТБ приходилось х ватт питания — т.е. всего 64х. В полученной системе мы имеем 16 Тб дискового пространства и «на 67% сниженное энергопотребление» — т.е. 64х*0,33=21,12х общего потребления. И того энергопотребление на 1 Тб пространства увеличилось на 21,12 / 16 = 1,32х — это на 32%!

                          Я верю в эту классную технологию, но у Вас в статье какие-то не вяжущиеся с логикой цифры.
                            0
                            Вы забыли как минимум то, что электричество потребляют и тепло выделяют еще собственно сами дисковые полки, в которых установлены эти диски, там в них много чего, там два 15-портовых FC-коммутатора в них встроены, через которые FC-диски видятся, два redundant блока питания, два интерфейсных модуля FC, в каждой полке.

                            Хотите я вам все данные из техспек по ним запощу, проверите?
                              0
                              Ну не о том я, не о том, ну почему же Вы меня не слышите?
                              Уменьшение дискового массива в 4 раза (с 64 ТБ до 16 Тб) в любом случае повлекло бы за собой снижение количества полок и энергопотребления. И не важно FlashCache при этом используется или нет — все равно 16 Тб это в 4 раза меньше потребления, чем 64 Тб (т.е. на 75%). Я верю в цифру «на 67% меньше энергопотребление». Но это не преимущество FlashCache, а просто голый факт, основанный на том, что 64 Тб в 4 раза больше чем 16 Тб. А FlashCache даёт просто кеширование и минимизацию задержек, кушая при этом своих 75-67=8% питания.
                                +1
                                > И не важно FlashCache при этом используется или нет

                                Что значит «не важно», если именно за счет использования FlashCache это и было достигнуто без падения производительности?

                                Да, дисков стало меньше, а производительность, ради которой этих дисков взяли много — не упала, вот в чем вся суть-то!

                                То ли вы не умеете объяснить понятно, чего вы хотите, то ли я вообще тупой :)
                                  –1
                                  Ладно, пойдем другим путем.
                                  Имелась исходная система с 64 Тб дисков. Имелась новая система на FlashCache с 16 Тб дисков, которая кушала на 67% меньше энергии (т.е. 33% от базовой). Допустим, мы бы захотели увеличить количество винтов в системе на FlashCache до 64 Тб. При этом её потребление составит 33%*4=132% от базовой.

                                  Да, я понимаю, что будет выше производительность, это ясно, это круто. Но писать в статье об энергоэффективности системы — по меньшей мере странно, ибо жрет она на 32% больше стандартных систем. Писать о высокой производительности И энергоэффективности решения нельзя. Можно писать о высокой производительности ЦЕНОЙ энергоэффективности.

                                  Вот и все, что я хотел сказать.
                                    +2
                                    Нет, вы не с той стороны подходите.

                                    Имелась исходная система, дающая 55 тысяч IOPS.
                                    Для того, чтобы получить такие результаты, нам, идя традиционным путем, надо взять 224 диска FC, то есть 16 дисковых полок по 14 дисков.
                                    Потому что именно дисковые шпиндели в традиционных системах определяют производительность в IOPS. В наших требованиях — обеспечить 55000 IOPS при максимум 4ms latency, остальное уже детали, а это — первичный критерий.
                                    Емкость — это уже вторичное. Обычно база занимает сравнительно незначительный доступный объем таких систем.
                                    Она больше чем кэш, но меньше, чем суммарная емкость дисков. Допустим она размером 1TB вся. Но при этом вынь и положь 55000 IOPS на 4ms при работе с ней.
                                    Именно поэтому дисков столько много. Не потому, что нам надо на них много хранить, а потому что IOPS.

                                    На этом этапе еще понятна ситуация?

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

                                    Но если у нас есть FlashCache, мы можем подойти по другому. Мы можем взять куда меньше дисков, все равно 1TB базы у нас на них поместится. А необходимую производительность обеспечить с помощью FlashCache.

                                    Дисков стало меньше, полок стало меньше, потребление электричества уменьшилось, вся система стала дешевле (так как дисковых шпинделей и полок стало в 4 раза меньше) — но производительность, наш главный критерий для системы, не упала!

                                    Понятно-ли в таком варианте о чем речь?
                                      0
                                      Нет, ну если наш главный критерий одна только производительность, то Вы, конечно же, правы. Но я просто еще ни разу не встречал таких систем, где на размеры дискового массива было плевать абсолютно и между 1 Тб, 16 Тб и 64 Тб не было для заказчика никакой разницы. Обычно задача ставится в виде «обеспечить Х ТБ при скорости Y и latency Z».
                                        0
                                        А если нужна и емкость тоже, то тогда третий описанный вариант. Вместо 224 дисков FC ставим FlashCache и 93 емких, но медленных диска SATA, и получаем опять ту же высокую производительность (за счет FlashCache), и одновременно большую на 50% емкость и меньшую на 56% цену (за счет SATA).

                                        И опять не теряем производительность, получая те же 55 тысяч (рисунок в комментах).
                                          0
                                          Забили меня. Сдаюсь. :)
                                            0
                                            На запись то скорость теперь 93х«SATA disk IOPS» (скажем 93х80=7440, 80 IOPS это оптимистично, может и до 30 IOPS быть), а не 224x«FC IOPS» (скажем 224х150=33600).
                                            Если у нас была OLTP база 66%/33% read/write и 11,2k (33,6k / 3) IOPS и были этими 33% writes то мы в пролете: 11200>>2480 (7440/3, если кэш не разогрет или ну вот плохое случилось идут запросы на отсутствующие в кэше данные и мы читаем все с дисков), 11200>7440 (идеальный случай когда все данные в кэше и 7440 IOPS мы 100% задействуем на write IOPS).
                                            Поправьте если все запутал :).
                                              0
                                              Ну строго говоря там не IOPS, а спекмарковские «попугаи», я уж там так, для упрощения речи, сформулировал. За подробностями смотрите в описании тестов.
                                              Строго говоря, на результат это не влияет, единицы одинаковые во всех трех случаях.

                                              Но неправы в свою очередь и вы. Ситуация с записями в WAFL совсем иная.
                                                0
                                                Я не придираюсь к тестам, там все понятно.

                                                Мой пример конечно к этим тестам не относится — они NASовые для клиентского доступа по NFS и CIFS (не SAN и не vmdk на NFS например).

                                                Что значит «иная»? Проблемы с raid penalty для RAID-6 решены, прироста IOPS это само по себе не дает.

                                                Как говорит Recovery Monkey «There is no magic»: диски есть диски и больше чем теоретически возможно IOPS они не обслужат.

                                                Попробую другой пример привести: если у нас было 33,6k IOPS при 100% writes (random, так конечно не бывает, просто для примера), перенесли все это с 224 FC на 93 SATA, стало 11,2k IOPS. Это не та же производительность на запись и FlashCache тут не поможет никак.
                          0
                          Я так понял, кэш используется на запись тоже. Проясните тогда, как защищены данные в Flash, пока они не сброшены на жесткие диски, где наверное RAIDы и все такое. Как обеспечивается безопасность новых записанных данных от сбоя Flash Cache?
                          Это еще один уровень со своим RAID?
                            0
                            FlashCache НЕ используется на запись. Только на чтение.

                            Системный кэш, в RAM, не используется на запись (вернее используется иным, чем обычно, образом, и преимущественно только на чтение).
                            Записываемые операции попадают в так называемый NVRAM (я о нем рассказывал, когда писал про WAFL), и NVRAM хранит в свой памяти с батарейкой операции между двумя «сбросами» на диски.
                            Данные в нем не хранятся продолжительное время, а каждые несколько секунд сбрасываются (flush) на диски.
                            Каждый flush завершается записью в файловую систему WAFL специальной отметки — consistency point, запись CP это «атомарная» процедура, она или есть, или ее нет. То есть данные пишем-пишем-пишем, и последним действием записываем CP. Затем, если она завершилась удачно, то очищаем относящуюся к этой порции страницу в памяти NVRAM.
                            Если CP есть, то валидны относящиеся к ней блоки записанных данных, если CP записать не удалось (например сбой питания или core dump), то остается валидной предыдущая CP. При этом неуспешно записанные данные в NVRAM не очищаются, а хранятся «под батарейкой». А записанные данные на дисках всегда консистентны.
                            Когда система поднялась, она обнаруживает неудачный flush, и начинает сброс его заново, с самого начала, после чего переставляет на новое состояние данных на дисках CP. До той поры записываемая порция находится в NVRAM.

                            Рекомендую, если интересны механизмы подробнее, сходить в статью про WAFL (ссылка на нее есть в посте), а там есть ссылка на перевод статьи об устройстве WAFL.

                            > Как обеспечивается безопасность новых записанных данных от сбоя Flash Cache?

                            Только чтение. Запись на WAFL практически нет необходимости кэшировать традиционным способом, в non-flushable RAM, (за подробностями снова в статью про WAFL), она и так идет практически на предельно возможной скорости, кэширование ее не ускорит, а алгоритмически сильно усложнит.
                            Кроме того, каждый сектор (512b) в WAFL дополнительно защищен CRC (8b, суммарно каждый сектор на дисках занимает 520b), это сквозная защита, до выхода байтов из стораджа.
                              0
                              Тогда акценты в статье расставлены неверно, сбивают с толку.
                              Как раз при чтении начала статьи у меня было убеждение, что идет речь лишь о кэше на чтение. Но ни слова об этом явно не сказано.
                              Затем вдруг была поднята проблема random write на flash. Опять не прямо, явно, а коссвенно поднят вопрос записи. Стал думать, что все-таки запись проходит через FlashCache.
                              Теперь Ваш коммментарий возвращает к версии «только на чтение».

                              Тогда мой вопрос собственно снят.

                              PS. И статья, и комментарий могли бы быть гораздо короче. Как раз сложнее читать длинные абзацы для того, чтобы найти простую суть.
                                0
                                Специально нужный фрагмент поста:

                                «Как же в данном случае «играет» WAFL?
                                Дело в том, что в системах NetApp, использующих WAFL, которая «оптимизирована на запись», а если подробнее, то записи, как я уже рассказывал, пишутся длинными последовательными «страйпами», а за счет того, что такая схема позволяет не держать записи в кэше, а записывать их непосредственно на диски, на максимально возможной для этих дисков скорости, кэш в системах NetApp практически не используется на запись. [b]Соответственно не используется на запись и FlashCache[/b], сильно упрощается и алгоритмическая часть, и решается проблема с низкой производительностью Flash на запись. [b]Flash в данном случае вообще не используется на запись[/b], записи прямиком, через буфер RAM, идут на диски, держать их в кэше просто не нужно, то есть мы используем Flash только в самом эффективно работающем у него режиме — random read»
                                  0
                                  Спасибо, я абсолютно согласен, что пропустил текст.

                                  Я лишь попытался объяснить «почему». Сейчас текст слишком большой. И как оказывается нагружен в том числе и информацией не относящейся к заголовку: «FlashCache».
                                  Вместо того, чтобы в начале статьи сказать «Flash Cache — чудо-кэш только для для чтения. Запись через него не проходит», Вы предпочли добавить пять абзацев про WAFL, упомянули проблемы write для flash, и только где-то внутри можно было найти заветные слова. Явно перегруз лишней инфомрацией.

                                  Было бы мило видеть в начале статьи лаконично сформулированные выделенные плюсы/минусы/назначения/. Любой из этих элементов сейчас надо вычитывать.
                                  Общее впечатление: воды больше, чем нужно. Можно короче без потери смысла.

                                  Хотя, это ИМХО. Думаю, что кому-то нравится.
                                    0
                                    Никогда не понимал прелести твиттера :)
                                  0
                                  Специально нужный фрагмент поста:

                                  «Как же в данном случае «играет» WAFL?
                                  Дело в том, что в системах NetApp, использующих WAFL, которая «оптимизирована на запись», а если подробнее, то записи, как я уже рассказывал, пишутся длинными последовательными «страйпами», а за счет того, что такая схема позволяет не держать записи в кэше, а записывать их непосредственно на диски, на максимально возможной для этих дисков скорости, кэш в системах NetApp практически не используется на запись. Соответственно не используется на запись и FlashCache[, сильно упрощается и алгоритмическая часть, и решается проблема с низкой производительностью Flash на запись. Flash в данном случае вообще не используется на запись, записи прямиком, через буфер RAM, идут на диски, держать их в кэше просто не нужно, то есть мы используем Flash только в самом эффективно работающем у него режиме — random read»
                              0
                              Подобное так же используется в ZFS, и например, в адаптеках с приставкой E.

                              Очень елегантное решение — SSD в продакшне пока кроме как на кеш использовать стрёмно.

                              Жду-не дождусь когда для венды что-то такое придумают
                                0
                                Я написал о аналогичных решениях у других в последнем абзаце текста.
                                Но проблема еще уйти от использования random write в кэше, и если для ZFS это решается тем, что они используют те же принципы, что реализованы в WAFL у NetApp, то вот с другими системами будет сложнее.

                                Что же касается Windows, то разве поставив в Windows-сервер Adaptec с MaxIQ вы не добьетесь того, что хотели? (Я, к сожалению, довольно поверхностно знаю продукты Adaptec).

                                Опять же, NetApp, как производитель внешних, сетевых хранилищ, считает, что эта задача решается покупкой внешнего, сетевого хранилища, а не локальными дисками в каждом сервере.
                                  0
                                  адаптек с этой фичей во-первых очень дорогие, во-вторых поддержка на уровне FS завсегда круче, сами понимаете.
                                0
                                вот здесь в комментариях отметили недостаточный ресурс SSD для использования в качестве кеша.
                                  +1
                                  «Ресурс SSD» это количество циклов перезаписи.
                                  Вы пропустили тот момент, что FlashCache — это кэш чтения. Записей в него сравнительно немного, только в момент заполнения его, причем делается это большими фрагментами, в sequental по характеру. Это совсем нестрашно :)
                                  –2
                                  гражданин трак опят маркитасит. :D
                                    0
                                    Уважаемый track.
                                    1. Перемещение по «уровням хранения» автоматически есть у EMC.
                                    2. Аналог FlashCache технологии есть как минимум у EMC и IBM, причем у последней бесплатно (лицензия бесплатно). Только они использую SSD в исполнении дисков, а не плат. В чем преимущества технологии FlashCache от NetApp перед конкурентами?
                                    0
                                    Ну давайте по-порядку:

                                    1. Китайская притча говорит, что у мастера Чжень Лун такое кунг-фу, что он может сражаться один против 30 воинов голыми руками. А у мастера Ли Бо — такое кунг-фу, что он никогда не попадет в ситуацию, когда приходится сражаться с 30 воинами голыми руками :)

                                    EMC сперва использует SSD, а потом решает проблемы, вызванные этим использованием с помощью отдельного продукта — FAST. А NetApp просто не имеет этих проблем в принципе, так как не использует Flash в виде SSD, поэтому и FAST как средство tiered storage им не нужен.
                                    Именно поэтому NetApp и говорит о FlashCache и системах с их использованием как о virtual tiered storage — хранилище с виртуальными «уровнями».

                                    FAST постепенно улучшается (в v1 он был никуда не годен, говорят, в v2 уже получше, хотя по прежнему неидеален, сложен и с довольно высокими «накладными расходами», например оперирует «чанками» размером 1GB, против 4KB у NetApp), но NetApp с FlashCache в принципе не имеет тех проблем, которые нужно решать с помощью FAST.
                                    Что выбрать — решать вам. Если у вас EMC, то выбора нет, конечно. Если не ограничиваться EMC, то есть варианты :)

                                    2. Если под аналогом у IBM вы называете их N-series, то это тоже NetApp, IBM N-series это системы производства NetApp, продаваемые по OEM-соглашению. Разумеется они имеют все те же решения, что и «оригинальный NetApp», то есть тот же FlashCache. У IBM «своего» сейчас в стораджах — только DS8000 по-моему, все остальное с большей или меньшей степенью стороннее.

                                    > причем у последней бесплатно (лицензия бесплатно).

                                    FlashCache тоже бесплатен как лицензия, денег стоит только собственно сама физическая плата, соответствующий компонент в OS — FlexScale — встроен и бесплатен.

                                    > В чем преимущества технологии FlashCache от NetApp перед конкурентами?

                                    О преимуществах перед FAST я написал выше. Преимущества перед FASTcache, если вкратце, то большая достижимая емкость на системах верхнего уровня (до 8TB против 2TB), и лучшая производительность на flash в целом (пока демонстрируемые результаты на SSD, если рассмотреть их повнимательнее далеки от того, чтобы произвести впечатление, см. например разбор у recoverymonkey: раз и два.) То есть проблемы с производительностью на SSD у EMC на «системном уровне».
                                      0
                                      >Если под аналогом у IBM вы называете их N-series, то это тоже NetApp
                                      нет, я под аналогом называю IBM Storwize V7000. от представителей слышал, что это их разработка.
                                        0
                                        А, вы про Easy Tier. Я, увы, невеликий спец по конкурирующим решениям, я предпочитаю хорошо знать продукты одной компании, чем, одинаково плохо — всех. :)

                                        Но основное возражение прежнее. Существуют два подхода: первый создать проблему неверным архитектурным решением (с точки зрения NetApp неверным, конечно же), а затем отдельным продуктом ее решать.
                                        Второй — изначально, на уровне архитектуры системы не иметь этой проблемы в принципе.

                                        Также обратите внимание, что Easy Tier это сравнительно молодой продукт, с которым еще нет достаточного опыта применения, малоизвестны его «узкие места» и слабости, в том время, как NetApp FlashCache продается уже около двух с половиной лет, и очень широко распространен, применяется и работает уже в тысячах стораджей компании у ее клиентов, хорошо протестирован и «пробенчмаркен».
                                      0
                                      У Netapp есть несколько проблем
                                      1. Они НЕ умеют использовать SSD под запись и пишут, что оно какбэ и не надо, имхо бред, якобы у WAFL и так все хорошо с записью, но скорость записи на HDD, никак не сравнится со скоростью записи на флэши.
                                      2. Такое преимущество как 8 Тб FlashCache — довольно наигранное, во-первых контроллеры mid-range СХД не прожрут такие IOPS, во-вторых, если даже брать что это 8Tb — незеркалируются, получается, при цене около 10K$ за 256Gb — 640K$, что неоправданно для mid-range СХД.
                                        0
                                        > Они НЕ умеют использовать SSD под запись

                                        Вы считаете, что постоянно писать на устройства, имеющие конечный ресурс на запись — это разумно?

                                        > и пишут, что оно какбэ и не надо, имхо бред, якобы у WAFL и так все хорошо с записью, но скорость записи на HDD, никак не сравнится со скоростью записи на флэши.

                                        Почитайте тут:
                                        blog.aboutnetapp.ru/archives/936
                                        в особенности вторую половину статьи.

                                        > 2. Такое преимущество как 8 Тб FlashCache — довольно наигранное, во-первых контроллеры mid-range СХД не прожрут такие IOPS

                                        Конечно не прожрут, тем более, что 8TB в них и не поставить, это только для 6200, hi-end, и вот для последних это весьма нужно.
                                        0
                                        Учитывая реальный ресурс при постоянно работающей СХД около 5 лет — вполне.
                                        Прочитал статью, она очень отдает «хьюлеттовщиной», то есть доводы все ну ооочень сомнительно для обычного человека, для инженера-стораджиста так вообще не доводы.
                                        Ну что значит «По контрасту, если вы покупаете 256GB Flash Cache, вы можете использовать под кэширование и ускорение работы с данными все 256GB, сто процентов от затраченных на них денег,» а если погорит PAM-плата — останетесь без кэша?
                                        Так можно и под FAST брать не 3, а 2 диска — причем появляется отказоустойчивость, а то что рекомендовано 3 флэша, так любой адекватный заказчик и возьмет 3 драйва, потому что данные уж куда важнее цены лишнего диска.
                                        Опять же WAFL — это «надстройка» над классическим блочным уровнем, которая имеет свои плюсы так и минусы, атк как создание доп слоя создает свои задержки.

                                        Ну и последнее, вы же сами знаете отличие Hi-End от mid-range — отсутсвие влияния на продакшен при выходе любой из компонент, 6200 никак не Hi, даже 3Par со своими 4-х контроллерными системами не зовет себя Hi-endом. Вот вылетит контроллер на 6200 груженной под 1000 дисков и что???
                                          0
                                          > Ну что значит «По контрасту, если вы покупаете 256GB Flash Cache, вы можете использовать под кэширование и ускорение работы с данными все 256GB, сто процентов от затраченных на них денег,»

                                          Вы сейчас кого цитируете? У меня в статье этой фразы нет.

                                          > а если погорит PAM-плата — останетесь без кэша?

                                          Не без кэша, а без Flash Cache, основной кэш в памяти работает по прежнему. Данные при выходе из строя Flash Cache не теряются, потому что кэш — только на чтение.

                                          Если погорит плата — то происходит кластерный файловер, и клиенты переводятся на другой контроллер, на котором плата не погорела. Сама же плата доставляется курьерской службой со склада в режиме NBD Onsite, либо же, при наличии соответствующего уровня поддержки (до 50 км от сервисного склада), 4h 24x7.

                                          > Так можно и под FAST брать не 3, а 2 диска — причем появляется отказоустойчивость, а то что рекомендовано 3 флэша, так любой адекватный заказчик и возьмет 3 драйва, потому что данные уж куда важнее цены лишнего диска.

                                          Не вполне почем о чем вы, и к чему это. Переформулируйте.

                                          > Опять же WAFL — это «надстройка» над классическим блочным уровнем, которая имеет свои плюсы так и минусы, атк как создание доп слоя создает свои задержки.

                                          Это не вполне так.
                                          Снова непонятно, что это, в процитированом виде, доказывает.

                                          > Ну и последнее, вы же сами знаете отличие Hi-End от mid-range

                                          Я знаю минимум три разных «определения» что такое hi-end. :)
                                          Строго говоря, Hi-end это только лишь уровень производительности и уровень обеспечиваемого SLA.

                                          > Вот вылетит контроллер на 6200 груженной под 1000 дисков и что???

                                          Произойдет кластерный файловер, данные останутся доступны. При правильно сайзенной системе сохранится и гарантированный уровень производительности.
                                          0
                                          Существует ли возможность оценить потенциальную эффективность от установки Flash Cache ДО его приобретения? Если ли способ измерить объем читаемых со стораджа данных, которые могли бы принести пользу при их кэшировании на Flash Cache?

                                          Боюсь, как бы не получилось так, что на флэшке будет данных храниться не более чем в RAM кэше контроллеров…
                                            0
                                            Да, такая возможность есть, она называется Predictive Cache Statistics (PCS). Посмотрите документ media.netapp.com/documents/tr-3801.pdf
                                              0
                                              Еще интересно тут:
                                              ctistrategy.com/2009/02/27/netapp-cache-pcs/
                                                0
                                                супер! спасибо!

                                                еще вопрос: существует ли возможность теста Flash Cache неделю-две?
                                                предполагаю, что на уровне партнера это решается скорее всего?

                                                hot-add Flash Cache возможен — это понятно, а возможно ли убрать и выключить Flash Cache из СХД, где он уже работает без даунтайма?

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

                                            Самое читаемое