Мы (я имею в виду Джеффа) изучаем возможность использования потребительских MLC SSD-дисков в нашем центре данных резервного копирования.
Мы хотим снизить затраты и увеличить полезное пространство - поэтому Intel X25-E стоит около 700 долларов каждый и имеет емкость 64 ГБ.
Мы думаем о том, чтобы купить некоторые из более дешевых SSD, которые предлагают большую емкость по более низкой цене. Мой босс не считает, что потратить около 5 КБ на диски на серверах, выходящих из центра резервного копирования, стоит вложенных средств.
Эти диски будут использоваться в RAID-массиве с 6 дисками на Lenovo RD120. RAID-контроллер - Adaptec 8k (переименованный в Lenovo).
Насколько опасен такой подход и что можно сделать, чтобы уменьшить эти опасности?
Несколько мыслей;
Удачи - только не надо жарить их писанками :)
Я нашел эту ссылку, в которой есть интересный и тщательный анализ MLC и SLC SSD на серверах
На мой взгляд, использование массива MLC flash SSD для корпоративного приложения, по крайней мере, без использования (заявленных) эффектов уменьшения износа такой технологии, как Easyco MFT, похоже на прыжок с самолета без парашюта.
Обратите внимание, что некоторые поставщики SSD MLC утверждают, что их диски достаточно "предприимчивы" чтобы выжить пишет:
SandForce стремится стать первой компанией с контроллером, поддерживающим многоуровневые флеш-чипы ячеек для твердотельных накопителей, используемых в серверах. Благодаря использованию микросхем MLC, SF-1500 открывает путь к снижению стоимости и увеличению плотности накопителей, необходимых производителям серверов. На сегодняшний день в флеш-накопителях для серверов используются одноуровневые флеш-чипы. Это связано с тем, что долговечность и надежность микросхем MLC обычно не соответствует требованиям серверов.
Есть дальнейший анализ этих претензий. в AnandTech.
Кроме того, теперь Intel официально заявила, что SLC может быть излишним на серверах в 90% случаев:
«Мы считали, что требуется SLC [одноуровневая ячейка], но в ходе исследований с Microsoft и даже с Seagate мы обнаружили, что эти ресурсоемкие приложения на самом деле не пишут так много, как думали», - сказал Уинслоу. «Девяносто процентов приложений центра обработки данных могут использовать этот накопитель MLC [многоуровневые ячейки]».
... за последний год или около того поставщики пришли к выводу, что, используя специальное программное обеспечение в контроллерах накопителей, они могут повысить надежность и отказоустойчивость своих MLC SSD потребительского класса до такой степени, что предприятия приняли их за высокопроизводительные серверы центров обработки данных и массивы хранения. Производители SSD начали использовать термин eMLC (enterprise MLC) NAND flash для описания этих SSD.
«С точки зрения объема, мы действительно видим, что существуют действительно высокопроизводительные вычислительные среды с высокой интенсивностью записи, которым все еще может потребоваться SLC, но это входит в 10% лучших требований даже к корпоративным центрам обработки данных», - сказал Уинслоу.
Intel кормит эти верхние 10% рынка корпоративных центров обработки данных через свое совместное предприятие с Hitachi Global Storage Technologies. Hitachi производит линейку SSD400S с последовательным подключением SCSI SSD со скоростью 6 Гбит / с. пропускная способность - вдвое больше, чем у твердотельных накопителей SATA на базе MLC.
Intel, даже для своих серверов SSD-накопителей, имеет перешел с SLC на MLC с очень большим объемом "избыточного выделения ресурсов" с новой серией Intel SSD 710. На этих дисках для внутреннего резервирования выделяется до 20% общей памяти:
Производительность не является главным приоритетом для SSD 710. Вместо этого Intel стремится обеспечить долговечность на уровне SLC по разумной цене за счет использования более дешевой eMLC HET NAND. SSD 710 также поддерживает настраиваемое пользователем избыточное выделение ресурсов (20%), что значительно увеличивает срок службы накопителя. Гарантия на SSD 710 составляет 3 года или до тех пор, пока индикатор износа не достигнет определенного уровня, в зависимости от того, что наступит раньше. Это первый раз, когда мы видим такое ограничение гарантии SSD.
Всегда основывайте подобные вещи на фактах, а не на предположениях. В этом случае собрать факты просто: запишите долгосрочные профили чтения / записи IOPS ваших производственных систем, а затем выясните, с чем вы можете жить в сценарии аварийного восстановления. Вы должны использовать что-то вроде 99-го процентиля в качестве меры. Делать не используйте средние значения при измерении пропускной способности операций ввода-вывода в секунду - значения имеют только пики! Затем вам необходимо купить необходимую емкость и количество операций ввода-вывода в секунду для вашего сайта аварийного восстановления. SSD могут быть лучшим способом сделать это, а может и нет.
Так, например, если вашим производственным приложениям требуется 7500 операций ввода-вывода в секунду на 99-м процентиле, вы можете решить, что сможете выжить с 5000 операций ввода-вывода в секунду в случае аварии. Но это как минимум 25 дисков по 15 КБ, необходимых прямо на вашем сайте аварийного восстановления, поэтому SSD может быть лучшим выбором, если ваши потребности в емкости невелики (похоже, что они есть). Но если вы измеряете только то, что вы выполняете 400 операций ввода-вывода в секунду в производственной среде, просто купите 6 дисков SATA, сэкономьте немного денег и используйте дополнительное пространство для хранения дополнительных снимков резервных копий на сайте аварийного восстановления. Вы также можете разделить операции чтения и записи в своем сборе данных, чтобы выяснить, как долго твердотельные накопители, не относящиеся к корпоративному, будут работать для вашей рабочей нагрузки, в зависимости от их характеристик.
Также помните, что системы аварийного восстановления могут иметь меньшую память, чем производственная, а это означает, что требуется больше операций ввода-вывода в секунду (больше подкачки и меньше кеша файловой системы).
Даже если MLS SSD прослужит всего один год, через несколько лет замена будет намного дешевле. Сможете ли вы справиться с необходимостью замены твердотельного накопителя MLS, когда он окажется в нужном месте?
Технический документ о различиях между SLC и MLC от SuperTalent обеспечивает выносливость MLC и 10-ю часть срока службы SLC SSD, но есть вероятность, что MLS SSD переживут оборудование, в которое вы их вставляете. Я не уверен, насколько надежны эти статистические данные / факты от SuperTalent.
Если предположить, что вы получаете аналогичный уровень поддержки от поставщика твердотельных накопителей MLC, то более низкая цена делает попытку.
Поскольку исходный вопрос действительно интересен, но все ответы довольно старые, я хотел бы дать обновленный ответ.
По состоянию на 2020 год современные потребительские твердотельные накопители (или, по крайней мере, от ведущих брендов) очень надежны. Сбой контроллера встречается довольно редко, и они правильно учитывают барьеры записи / синхронизации / сброса / FUA, что означает хорошие вещи для надежности данных. Несмотря на то, что они используют вспышку TLC, они обладают неплохой выносливостью.
Однако при использовании микросхем TLC размер их флеш-страницы и время программирования намного выше, чем у старых дисков SLC или MLC. Это означает, что их частный кэш DRAM критический для достижения хорошей производительности записи. Отключение этого кеша нанесет ущерб любым операциям ввода-вывода в операциях записи TLC (или даже MLC, хотя и с меньшим воздействием). Более того, любой шаблон записи, который эффективно обходит функцию комбинирования записи кэша DRAM (то есть: небольшие синхронные записи, выполняемые рабочей нагрузкой, богатой fsync), обязательно приведет к очень низкой производительности. В то же время усиление записи резко возрастет, SSD изнашивается намного быстрее, чем ожидалось.
Практический пример: у моего ноутбука OEM-вариант Samsung 960 EVO - быстрый SSD M.2. Когда он забивается случайными записями, он обеспечивает отличные IOP, если только с помощью fsync пишет: в этом случае он хорош только для ~ 300 IOP (измерено с fio), что сильно отличается от более 100 тыс. операций ввода-вывода в секунду без принудительной синхронизации.
Дело в том, что многие корпоративные рабочие нагрузки (например, базы данных, виртуальные машины и т. Д.) fsync тяжелые, неблагоприятные для потребительских SSD. Конечно, если ваша рабочая нагрузка ориентирована на чтение, это не применимо; однако, если вы используете что-то вроде PostgreSQL на потребительских SSD, результаты могут ввести вас в заблуждение.
Еще одна вещь, которую следует учитывать, - это возможное использование RAID-контроллера с BBU (или защищенным от потери мощности) кешем обратной записи. Большинство таких контроллеров отключают частный кеш SSD DRAM, что приводит к гораздо более низкой производительности, чем ожидалось. Некоторые контроллеры поддерживают повторное включение, но не все из них передают необходимую синхронизацию / барьер / FUA, чтобы получить надежное хранилище данных на потребительских SSD.
Например, старые контроллеры PERC (например: 6 / i) объявили себя как сквозная запись устройств, эффективно сообщая ОС не выдает сброс кеша на всех. Потребительский SSD, подключенный к такому контроллеру, может быть ненадежным. если его кеш не отключен (или контроллер, использующий дополнительные недокументированный уход), что означает низкую производительность.
Не все контроллеры ведут себя подобным образом - например, более новые контроллеры PERC H710 + объявляют себя как обратная запись устройств, позволяя ОС при необходимости выполнять очистку кеша. Контроллер может игнорировать эти сбросы, если на подключенных дисках не включен кэш: в последнем случае они должен передать необходимую синхронизацию / сброс.
Однако все это связано с контроллером (и прошивкой); являясь черными ящиками HW RAID-контроллеров, нельзя быть уверенным в их специфическом поведении и надеяться только на лучшее. Стоит отметить, что реализация RAID с открытым исходным кодом (например, Linux MDRAID и зеркалирование ZFS / ZRAID) гораздо более управляема и, как правило, намного лучше при извлечении производительности из потребительских SSD. По этой причине я использую программный RAID с открытым исходным кодом, когда это возможно, особенно при использовании потребительских SSD.
SSD корпоративного уровня с кэш-памятью обратной записи, защищенной от потери мощности, не подвержены всем этим проблемам: имея энергонезависимый кэш, они могут игнорировать запросы синхронизации / сброса, обеспечивая очень высокую производительность и низкое усиление записи независимо от HW RAID-контроллеров. Учитывая, насколько низкие цены на твердотельные накопители SATA корпоративного уровня в настоящее время, я часто не вижу смысла в использовании потребительских твердотельных накопителей на загруженных серверах (если предполагаемая рабочая нагрузка не ориентирована на чтение или иным образом с недостаточным fsync).
Если оставить в стороне проблему количества записей (или доказать, что твердотельные накопители потребительского уровня могут с этим справиться), я думаю, что твердотельные накопители - это хорошая вещь, которую можно добавить в среду корпоративного уровня. Вероятно, вы будете использовать SSD в RAID-массиве. RAID5 или RAID6. Проблема в том, что после сбоя одного диска массив становится все более уязвимым. И время его восстановления сильно зависит от объема массива. Восстановление массива в несколько ТБ может занять несколько дней при постоянном доступе. В случае твердотельных накопителей RAID-массивы будут: а) неизбежно будут меньше, б) время восстановления резко сократится.
Вам нужно просто подсчитать количество ежедневных операций записи, которые у вас есть с вашей текущей настройкой, и сравнить это с тем, что производитель гарантирует, что их SSD-диски могут выдержать. Корпорация Intel, кажется, наиболее открыта по этому поводу - например, взгляните на их основные спецификации SSD-накопителей: http://www.intel.com/design/flash/nand/mainstream/technicaldocuments.htm
В разделе 3.5 (в частности, 3.5.4) документа со спецификациями говорится, что ваш диск гарантированно прослужит не менее 5 лет при 20 ГБ операций записи в день. Я предполагаю, что это рассчитывается при использовании всей емкости диска и отсутствии выделения свободного места для записи самостоятельно.
Также интересны данные об использовании распространенных SSD в корпоративной среде.
Пару лет назад я развернул пару SLC-дисков емкостью 32 ГБ в качестве буфера для какого-то ужасно плохо спроектированного приложения, которое мы использовали.
Приложение выполняло 90% небольших операций записи (<4k) и работало постоянно (24/7) со скоростью 14kw / s один раз на SSD-дисках. Был настроен RAID 1, все было радужно, латентность была низкой!
Однако примерно через месяц и первый диск был упакован буквально в течение 3 часов, второй диск тоже умер. В конце концов, RAID 1 - не такой уж хороший план :)
Я бы согласился с другими плакатами о каком-то RAID 6, если ничто другое не распределяет эти записи по большему количеству дисков.
Теперь имейте в виду, что это было пару лет назад, и сейчас эти вещи намного надежнее, и у вас может не быть аналогичного профиля ввода-вывода.
Приложение было модернизировано, однако в качестве временной остановки, которая может помочь вам, а может и не помочь, мы создали большой оперативный диск, создали несколько сценариев для восстановления / резервного копирования оперативного диска и взяли на себя потерю данных в течение часа или около того. /время восстановления.
Опять же, ваш жизненный цикл ваших данных может быть другим.