Тихая революция: флеш-память в дата-центрах

    Флеш-память уже производит в ЦОДах революцию: перенос данных на flash — следующий шаг в развитии многих централизованных ИТ-систем. Да, она довольно дорогая, обладает своими особенностями — и все же сегодня вопрос для администраторов ЦОДов уже не в том, использовать флеш-память или нет, а в том, как и когда это делать.



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

    Ниже – советы, как определить, пора ли переходить на эту технологию или еще нет.

    Начнем с простых фактов



    • Флеш-память очень дорога. Да, стоимость хранения гигабайта информации на флеш-дисках и флешовых СХД в разы дороже в сравнении с механическими HDD. Однако для приложений, которые создают нагрузку на СХД в тысячи IOPS и чувствительны ко времени отклика дисковой подсистемы, она становится дешевле и при этом надежнее (разумеется, такие приложения следует размещать на специализированных СХД, а не на одном SSD-диске или PCI-e карте, для которых заявляется теоретическая производительность в сотни тысяч IOPS).
    • Флеш-память ненадежна. Многие до сих пор считают технологию «сыроватой» и приписывают современным флеш-накопителям проблемы первых прототипов. В составе SSD-дисков, а тем более, в специализированных СХД, современная флеш-память показывает показатели надежности выше, чем HDD. Более того, я считаю, что любая СХД, на которой работают серьезные сервисы, должна находиться на поддержке поставщика или производителя. В таком случае выход из строя HDD или SSD вас вообще не волнует, его замена — это рутинная процедура службы поддержки. Многие современные СХД умеют сами сообщать о сбое в сервисный центр. Зачастую быстрее, чем вы сами обнаружите отказ, вам уже звонят договариваться о времени визита.
    • Число циклов записи ограничено. Это правда, сейчас — SLC это примерно 100 000 циклов перезаписи, MLC — 10 000. Проблема решается равномерной загрузкой блоков, и это обеспечивает контроллер. Нельзя, чтобы на одном участке было только чтение, а на другом постоянные изменения. Механизм, отвечающий за это, называется wear leveling (контроль равномерности износа). Так, у систем Violin Memory этот алгоритм равномерно «изнашивает» все пространство СХД целиком. В других системах за wear leveling отвечает контроллер каждого SSD, что менее эффективно. При этом часть пространства флеш-памяти (до 30%) резервируется на перенос (remap) таких изношенных блоков. Если предположить, что база данных будет писать на систему емкостью 10Тб круглосуточно и 365 дней в году 25000 IOPS блоками 4Кб (примерно 100 Мбайт/сек) то 1% SLC-системы износится за 3 года и 4 месяца, 1 % MLC-массива – за 4 месяца.
    • Флеш-память подходит для чтения, но не очень хороша для записи. Это связано с механизмом обработки записи. Для того, что произвести запись в ячейку, ее надо предварительно очистить. Стирание происходит не с одной ячейкой, а с целым блоком, в котором объединяются от 64 до 128 и больше Кб. И пока идет процесс стирания, все остальные операции останавливаются на довольно большой срок, измеряемый миллисекундами. Учитывая, что блок обычно больше, чем требуется для транзакции, очень многое зависит от «прошивки» и алгоритмов работы контроллера. Если диск один, то процесс действительно медленный. Но ситуация меняется если объем системы хранения — большой. Тогда контролеры могут перераспределить нагрузку так, что эффект блокирования системы перед записью не будет сильно влиять на работу системы, и она сможет давать практически такую же производительность на запись, как и на чтение. Если группировать записи и последовательно писать их в ячейку, потребуется гораздо меньше стираний.
    • Ошибки растут с увеличением количества циклов чтения на блок. Да, это факт. Как и предыдущие проблемы, вопрос решается контроллером. Прежде всего, он должен выводить из эксплуатации отжившие ячейки. Но даже если этот механизм вдруг дал сбой, никто не отменял защиту RAID, которая работает на контроллерах СХД или сервера.
    • Скорость падает по мере заполнения носителя. Да, производительность идеальна, когда память почти не использована, но по мере перезаписывания данных остаются блоки, где часть ячеек содержит нужные данные, а часть нет. Контроллер начинает процесс «сбора мусора» (garbage collection), перенося нужные данные с недозаполненных ячеек и стирая их по диску. Чтобы понять истинную скорость диска на 400 Гб, потребуется записать на него хотя бы 1 Тб в разных транзакциях, чтобы получить практические данные. Вот иллюстрация двух графиков. Само собой, чем больше объем данных на СХД, тем больше пространство для маневра и сглаживания этого эффекта.




    График пропускной способности на запись PCI-e флеш-карты и внешней флешовой СХД Violin VMA3205

    Для чего использовать?



    Корпоративные приложения

    Это первый хороший вариант использования. Флеш-память улучшает два ключевых показателя, которые важны для руководства и конечных пользователей ИТ-систем: доступность приложений и их производительность. Флеш-память выступит во все красе если соблюдены два условия:
    1. Достаточно нагруженное приложение. Большой Oracle, SAP, CRM, ERP, корпоративные порталы – отличные кандидаты.
    2. Использование внешней СХД с дублированными контроллерами и подключениями серверов.


    С другой стороны, некоторые считают переход на флеш-память панацеей от всех бед. Это не так, но средство действительно эффективно для увеличения производительности корпоративных приложений, действительно позволяет добиться этого наименьшей ценой по сравнению с другими решениями, которые есть на рынке. Перед принятием решения надо смотреть на загрузку конкретно вашей системы. Как показывает моя практика, в 70-80% случаев проблема со скоростью работы приложения или напрямую связана с низкой скоростью дисковой подсистемы, или ситуация может быть серьезно улучшена ускорением дисков.

    Кстати, такое решение может быть неочевидным. Например, когда система показывает, что CPU занят на 100%, не надо автоматически полагать, что проблема будет решена добавлением CPU. Надо копнуть на уровень глубже и посмотреть, чем занят процессор. Часто он занят ожиданием ввода-вывода (IOWAIT). Ускоряя дисковую систему можно разгрузить CPU и решить проблему.

    Для того чтобы понять, есть проблема с дисковой подсистемой или нет, надо построить график времени отклика дисковой подсистемы. В каждой ОС есть свои средства, которые позволяют легко это сделать – perfmon, iostat, sar, nmon и прочие.

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



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

    Виртуализация

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

    При попытке сложить сотни машин в ЦОД на одно большое хранилище (где часто возможно только вертикальное масштабирование, а не установка еще десятка таких же), оно часто становится местом, определяющим скорость всей системы. Это очень заметно в проектах по виртуализации рабочих станций: часто возникают проблемы в начале рабочего дня, когда все заходят, в обед и в конце дня. Если раньше компьютер загружался 5 минут, а теперь 15, причем при этом пользователю еще и говорят, что это самая прогрессивная технология, становится понятно его неудовольствие. Причем недовольно и начальство: были потрачены десятки и сотни тысяч долларов, а, судя по виду, стало только хуже. Тут вы опять можете выступить в роли доброго волшебника.

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

    Популярная технология оптимизации при переходе на СХД называется «золотой образ». Например, когда нужно 1000 компьютеров с Windows 7, не надо устанавливать 1000 дистрибутивов и занимать несколько терабайт файлами операционной системы. Система виртуализации создаст один так называемый «золотой образ» операционной системы. При этом все пользователи будут читать с него, а на их виртуальных машинах будут храниться только файлы, отличные от тех, что хранятся в образе. Понятно, что при этом на небольшой объем дискового пространства обрушивается огромное количество операций чтения. В случае, если эталонный образ как-то серьезно меняется (ставятся патчи, например), происходит обновление тысячи рабочих станций. Конечно, это тоже даст огромную нагрузку на СХД. Флеш-память помогает переживать такие моменты относительно легко и без вынужденных пауз в рабочем процессе.

    Экономия: бонусы



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

    Кроме того, большинство корпоративного софта типа Oracle, SAP, VMware и так далее лицензируется либо по физическим процессорам, либо по их ядрам. Соответственно, заказчик, масштабируясь горизонтально, платит несколько десятков тысяч за процессор (в high-end серверах цены именно такие), а потом платит еще больше за софт. А вот за ускорение своей СХД, которое даст не меньший эффект, платить производителям софта ничего не надо.

    Резюме



    Если у вас есть высоконагруженная система – сделайте анализ того, насколько ей хватает существующей СХД. Если оптимизировать хранение информации нужно — обязательно стоит хотя бы попробовать флеш-хранилище. С флешем, как и с любой новой технологией, связана куча суеверий, неуверенность относительно того, подходит решение или нет плюс вполне понятный консерватизм. Решить можно чаще всего только на практике. Просто попробуйте: попросите флешовую систему или несколько SSD-дисков в ваш массив на тест у дружественного вендора или системного интегратора, посчитайте результат и оцените, насколько вам это реально требуется.

    В ближайшее время к нам приезжает демо-массив Violin Memory, сейчас уже выстраивается небольшая очередь. Если вам это интересно (и у вас есть задачи, требующие большой мощности СХД), можно писать мне на dd@croc.ru.
    КРОК
    152,00
    №1 по ИТ-услугам в России
    Поделиться публикацией

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

      +4
      Первая фотография напомнила кадр с бортовым компьютером из «Космической Одиссеи».
        0
        Согласен, что-то есть ) Это Violin Memory V6000, по-своему, очень красивая штука.
        +2
        Если есть возможность загрузить флеш-хранилище работой (то есть обеспечить постоянные операции чтения-записи), его содержание обходится заметно дешевле содержания массива HDD, плюс вы получаете кучу дополнительных бонусов.
        Но ведь именно при постоянных операциях чтения и записи быстрее всего накапливается износ, приводящий сперва к торможению, а затем и к неработоспособности? Конечно, если к тому времени всё будет на гарантии у производителя — тогда и пёс с ним…
          0
          Возможно, имелось ввиду, что износ механических частей HDD в данном случае будет быстрее сказываться, нежели износ флеш-памяти.
            0
            Ну так от этого же есть и wear leveling и RAID1 и «отложенная запись». А ещё, для ускорения записи формируется большой (вероятно, равный размеру стираемого блока) блок данных из нескольких операций записи, когда это возможно. Где-то у меня валяется презенташка с конференции Ampro по встраиваемым системам, там и про industrial-флешки было, как раз эти механизмы описывались )
              +1
              Флешовые СХД действительно лучше всего отрабатывают вложенные деньги под нагрузкой — чем она выше, тем ниже стоимость каждой транзакции. Про износ я упоминал, обычные HDD при аналогичных условиях ломаются куда чаще чем модули флеш-памяти.
              0
              БД Eve online на такой системе, прекрасно работает.
                0
                Если предположить, что база данных будет писать на систему емкостью 10Тб круглосуточно и 365 дней в году 25000 IOPS блоками 4Кб (примерно 100 Мбайт/сек) то 1% SLC-системы износится за 3 года и 4 месяца, 1 % MLC-массива – за 4 месяца.

                Если перезапись идет блоками грубо по 128 ячеек 4КБ со скоростью 25000 IOPS, то получается 25000*128*4КБ=~12.2 ГБ\с, разве нет?
                  0
                  //На автомате отправил не дописав.//
                  В сутки соответственно 1 ПБ\с. SLC массив на 10 ТБ износится на 1% за ~10 Дней
                    0
                    Очепятка конечно же:
                    В сутки соответственно 1 ПБ
                    0
                    Предполагается что в одной ячейке 128Кб а не 128 х 4Кб, хотя тут по разному у разных производителей.
                    Мой расчет подразумевает последовательную запись – в лог-файлы и архивные логи.
                    Вообще, считать такие вещи теоретически – дело довольно неблагодарное, я лишь привел пример. Ресурс флеш-памяти разный у разных производителей и даже у одного производителя в рамках одной партии, обычно выше заявляемого. Профиль нагрузки тоже в реальности трудно предсказуем. Если обратиться к фактам, та же Violin Memory на свои SLC-массивы дает гарантию 5 лет, время жизни декларирует 10 лет и 8000 Петабайт записей.
                      0
                      Если обратиться к фактам, та же Violin Memory на свои SLC-массивы дает гарантию 5 лет, время жизни декларирует 10 лет и 8000 Петабайт записей.

                      При этом объем массива с такими «гарантиями» чему равен?
                        0
                        8000 Петабайт на 120Тб, на 12Тб — 800 Петабайт.
                    +1
                    Графики ни о чем. Укажите пожалуйста единицы измерения на перво графике, и легенды на обеих графиках.
                      0
                      Первый график – зависимость количества записей (IOPS) от времени.
                      Второй – зависимость времени отклика дисковой подсистемы (мс) от времени суток.
                        0
                        В первом графике не понятна логика зависимости. Почему от времени старта? К нему невозможно привязаться, т.к. на разных платформах будут разные цифры.
                        Во втором тоже не ясно почему от времени суток? Разве есть такая зависимость?
                        Цветовая палитра как-то расшифровывается?
                          0
                          Всё же написано в статье:
                          — в первом случае, скорость падает по мере заполнения памяти данными, стартовала запись на пустом массиве и в процессе заполнялась. «Да, производительность идеальна, когда память почти не использована, но по мере перезаписывания данных остаются блоки, где часть ячеек содержит нужные данные, а часть нет.»;
                          — во втором случае речь идёт о банковской процессинговой системе, соответственно от времени суток зависит нагрузка на систему, создаваемая пользователями. «При такой скорости СХД ей работалось довольно плохо, особенно когда люди заходили в банкоматы после работы, либо когда система подводила итоги дня:»
                      +4
                      Я бы хотел поинтересоваться, полюбопытствовать даже, от лица полнейших чайников данной сферы.
                      Места по-идее такие сервера должны занимать намного меньше? Или наоборот?
                      Охлаждение таким системам требуется в том же обьеме что и классическим, или флеш-памяти охлаждение вообще не нужно?

                        +1
                        и места меньше занимает и охлаждать проще будет
                          +1
                          Вопрос действительно важный, с учетом того что все больше заказчиков арендуют ЦОДы и экономия стойкомест выражается в реальных деньгах. Места флешовые СХД занимают в разы меньше. Как пример от одного западного заказчика – 6 юнитов вместо 150 и в шесть раз меньшее энергопотребление.

                          0
                          purestorage.com
                            0
                            Доброе утро!
                            Я давольно давно мучаюсь с СХД, но для себя я вывел на мой взгляд отличную формулу бустродействие/надежность/цена. В своем ЦОДе мы использовали когерентную систему кеширования — т.е. у нас система хранения middle range (IBM DS5100), на ней много разных драйвов, от SATA до SAS (15k), а вот перед ней стоит аппаратный кеш который нам дает на 100Тб (raid space) 128 гб read cache и 16 Гб write cache.
                            Подобная схема нам позволяет приземлять от машин 130 тыс. IOPS, не большой объем но все же работает все отлично! Кстати забыл добавить на контроллере СХД стоит 4г кеша и на каждой полке по 1г. Но тут надо понимать, решение крайне дорогое в части обслуживания, а именно в обеспечение питания и охлаждения. У нас норматив по работе машин 30 минут, по работе СХД 2 часа, чтобы все кеши опустить на диски.
                              +1
                              Картина сравнения безымянной PCI-E карты и целого стораджа полностью бессмысленна. Сравнили бы ещё с USB-флешкой, блин.

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

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