Защита кэш памяти дискового контроллера при потере питания сервером
Обновлено: 07.07.2024
Я планирую приобрести сервер (Dell PowerEdge R740) с твердотельными накопителями в RAID 10, и мои приоритеты - производительность записи и целостность данных. Это будет работать под управлением Linux. SSD имеют кэши записи с защитой от потери питания.
Похоже, это мои варианты RAID:
- PERC H330 (без кеша), программный RAID (сквозной)
- PERC H330 (без кеша), аппаратный RAID (сквозная запись)
- PERC H730P (кеш 2 Гб NV), аппаратный RAID (сквозная запись)
- PERC H740P (кэш 8 Гб NV), аппаратный RAID (сквозная запись)
- Есть ли какая-либо из этих конфигураций под угрозой потери данных или повреждения при потере питания?
- Какую конфигурацию мне ожидать, чтобы иметь лучшую производительность записи?
- Есть ли какие-либо другие преимущества кеша NV, которые я не рассматривал?
При использовании с твердотельными накопителями без кэша записи, защищенного от потери энергии, NVCACHE контроллера RAID крайне важен для получения хорошей производительности.
Однако, поскольку вы используете твердотельные накопители с кэшем записи, защищенным от потери мощности, производительность не должна сильно различаться между различными вариантами. С другой стороны, есть и другие факторы, которые следует учитывать:
- с аппаратным RAID-массивом зачастую проще определить и заменить неисправный диск: контроллер четко помечает поврежденный диск (например, желтым светом), и заменить его обычно так же просто, как вытащить старый диск / вставить новый. В программном RAID-решении вам необходимо ввести соответствующие команды для идентификации и замены неисправного диска;
- аппаратный RAID представляет BIOS для загрузки на одном томе, а программный RAID показывает различные компоненты устройства;
- с помощью правильного контроллера (то есть: H730 или H740) и дисков (SAS 4Kn) вы можете очень легко включить расширенное поле целостности данных (T10 / T13);
- аппаратный RAID запускает непрозрачный двоичный двоичный объект, над которым у вас нет контроля;
- Программный RAID для Linux гораздо более гибкий, чем любой аппаратный RAID, который я когда-либо использовал.
Тем не менее, при такой настройке я настоятельно рекомендую вам рассмотреть возможность использования ZFS в Linux: защищенные от потери данных кэши записи означают, что вы можете работать без выделенного устройства ZIL, а дополнительные функции ZFS (сжатие, контрольная сумма и т. Д.) Могут быть очень полезными ,
В: Что такое RAID и зачем он нужен? Какой RAID лучше использовать?
О: Ответу на этот вопрос посвящен раздел [ RAID ].
В: Можно ли использовать в RAID массиве диски разного размера?
О: Да. можно. Но, при этом, используемая емкость у ВСЕХ дисков будет равна емкости наименьшего диска.
Из этого следует, что добавлять в уже существующий RAID массив можно только диски такого же или большего размера.
В: Можно ли использовать в RAID массиве диски разных производителей?
О: Да, можно. Но при этом надо иметь ввиду, что точные размеры дисков одинаковой емкости (36/73/146. ГБ) у разных производителей могут отличаться на несколько килобайт. Когда вы создаете новый RAID массив, на это можно не обращать внимание, но если вы добавляете диски к уже существующему массиву (например, меняете вышедший из строя диск), то важно, чтобы новый диск был больше чем старые, или точно такого же размера.
В: Что такое Write Through и Write Back?
О: Это способ записи данных, полученных RAID контроллером, на дисковый массив. По другому эти способы еще называются так: прямая запись ( Write Through ) и отложенная запись ( Write Back ). Какой из этих способов будет использоваться определяется в BIOS-е контроллера (либо при создании массива, либо позднее).
- Write Through - данные записываются непосредственно на дисковый массив. Т.е. как только данные получены, они сразу же записываются на диски и после этого контроллер подает сигнал управляющей ОС о завершении операции.
- Write Back - данные записываются сначала в кэш , и только потом (либо по мере заполнения кэш -а, либо в моменты минимальной загрузки дисковой системы) из кэш -а на диски. При этом, сигнал о завершении операции записи передается управляющей ОС сразу же по получении данных кэш -ем контроллера.
Избежать описанной проблемы можно или с помощью установки на RAID контроллер BBU (см. ниже), или посредством подключения всего сервера через источник бесперебойного питания (UPS) с функцией программируемого выключения.
Кстати, некоторые RAID контроллеры не позволяют включить функцию Write Back без установленного BBU .
В: Что такое BBU и зачем он нужен?
О: BBU (Battery Backup Unit ) необходим для предотвращения потери данных находящихся в кэш -е RAID контроллера и еще не записанных на диск (отложенная запись - "write-back caching"), в случае аварийного выключения компьютерной системы.
Существуют три разновидности BBU :
- Просто BBU : это аккумулятор, который обеспечивает резервное питание кэша через RAID контроллер.
- Переносимые (Transportable) BBU (tBBU): это аккумулятор, который размещен непосредственно на модуле кэш и питает его независимо от RAID контроллера. В случае выхода из строя RAID контроллера, это позволяет перенести данные, сохраненные в кэш -е, на резервный контроллер и уже на нем завершить операцию записи данных. : основная идея заключается в следующем: в случае сбоя питания RAID контроллер копирует содержимое кэш -а в энергонезависимую память (например, в случае с технологией Adaptec »Zero-Maintenance Cache Protection - на NAND флэш накопитель). Питание, необходимое для завершения этого процесса, обеспечивается встроенным супер-конденсатором. После восстановления питания, данные из флэш памяти копируются обратно в кэш контроллера.
В: Что такое Hot Spare (Hotspare)?
О: Hot Spare - (Резервная Замена Дисководов ("Горячее резервирование")) - Одна из наиболее важных особенностей, которую обеспечивает RAID контроллер, с целью достичь безостановочное обслуживание с высокой степенью отказоустойчивости. В случае выхода из строя диска, восстанавливающая операция будет выполнена RAID контроллером автоматически, если выполняются оба из следующих условий:
- Имеется "резервный" диск идентичного объема, подключенный к тому же контроллеру и назначенный в качестве резервного, именно он и называется Hotspare ;
- Отказавший диск входит в состав избыточной дисковой системы, например RAID 1 , RAID 3 , RAID 5 или RAID 0+1 .
Обратите внимание: резервирование позволяет восстановить данные, находившиеся на неисправном диске, если все диски подключены к одному и тому же RAID контроллеру.
"Резервный" диск может быть создан одним из двух способов:
- Когда пользователь выполняет утилиту разметки, все диски, которые подключены к контроллеру, но не сконфигурированы в любую из групп дисководов, будут автоматически помечены как "резервные" ( Hotspare ) диски (автоматический способ поддерживается далеко не всеми контроллерами).
- Диск может также быть помечен как резервный ( Hotspare ), при помощи соответствующей утилиты RAID контроллера.
В течение процесса автоматического восстановления система продолжает нормально функционировать, однако производительность системы может слегка ухудшиться.
Для того, что бы использовать восстанавливающую особенность резервирования, Вы должны всегда иметь резервный диск ( Hotspare ) в вашей системе. В случае сбоя дисковода, резервный дисковод автоматически заменит неисправный диск, и данные будут восстановлены. После этого, системный администратор может отключить и удалить неисправный диск, заменить его новым диском и сделать этот новый диск резервным.
В этом разделе использованы материалы с сайта "3dnews".
В: Что такое Copyback Hot Spare?
О: Copyback Hot Spare это функция RAID контроллера, которая позволяет пользователям закрепить физическое расположение диска "горячего резерва" ( Hot Spare ), что позволяет улучшить управляемость системы.
В: Что такое JBOD?
О: JBOD (Just a Bunch of Disks) это способ подключить диски к RAID контроллеру не создавая на них никакого RAID . Каждый из дисков доступен так же, как если бы он был подключен к обычному адаптеру. Эта конфигурация применяется когда необходимо иметь несколько независимых дисков, но не обеспечивает ни повышения скорости, ни отказоустойчивости.
В: Что такое размер страйпа (stripe size)?
О: размер страйпа ( stripe size ) определяет объем данных записываемых за одну операцию ввода/вывода. размер страйпа задается в момент конфигурирования RAID массива и не может быть изменен позднее без переинициализации всего массива. Больший размер страйпа обеспечивает прирост производительности при работе с большими последовательными файлами (например, видео), меньший - обеспечивает большую эффективность в случае работы с большим количеством небольших файлов.
В: Нужно ли заниматься архивированием данных в случае использования RAID?
О: Конечно да! RAID это вовсе не замена архивированию, основное его назначение это повышение скорости и надежности доступа к данным в нормальном режиме работы. Но только регулярное архивирование данных гарантировано обеспечит их сохранность при любых отказах оборудования, пожарах, потопах и прочих неприятностях.
Батарейка для raid контроллера позволяющая сохранить информацию находящуюся в кеш памяти на момент экстренного отключения питания.
Информация сохраняется несколько суток.
(обычно 2 дня)
Батарейка для raid контроллера позволяющая сохранить информацию находящуюся в кеш памяти на момент экстренного отключения питания.
Это так и есть?
Т.е. данные в кеше (SDRAM), если не ошибаюсь, будут сохранятся день-два и ,
после восстановления питания, будут записаны?
Проведем мысленный эксперимент:
во время активной записи отключаем корзину от контроллера,
выключаем питание,
подключаем корзину,
включаем питание,
online на винты, если выпали.
получаем date in consistency?
Это пробовали продеоать, или так производитель пишет (где)?.
С уважением,
Артём Макаров
К сожалению при описаном вами эксперименте данные будут потеряны, т.к. до штатного для BBU события poweroff произойдёт событие RAID offline, соответственно буфферизировать данные нет смысла. Встретил одно утверждение, что у адаптековских рэйд контроллеров кэш включается только если установлена батарейка (несмотря на включение в биосе). Отсутствие кэширования я у них уже замечал, а вот батарейку ставить не додумывался. Кто-нибудь знает? setar писал(а): To Артём:
К сожалению при описаном вами эксперименте данные будут потеряны, т.к. до штатного для BBU события poweroff произойдёт событие RAID offline, соответственно буфферизировать данные нет смысла.
(новый эксперимент2) если SCSI подсистема (шина, корзина) в порядке, делаем poweroff. Данные будут записаны после воостановления питания (предполагаем, что диски в offline не выскочили).
Это где-то документировано у производителя? (ссылочка есть?)
(новый эксперимент3) - reset компу - сохранятся данные, или тут тоже все будет потеряно?
Случай практический. Сервер FreeBSD находится далеко, физически недоступен. Залочил систему IPFW. По SSH не войти. Единственый способ - позвать кого нибудь reset нажать.
(Правда есть средство отключить в ядре проверку клавы и клаву на ходу втыкать, а потом ctrl-alt-del)
art писал(а): (новый эксперимент2) если SCSI подсистема (шина, корзина) в порядке, делаем poweroff. Данные будут записаны после воостановления питания (предполагаем, что диски в offline не выскочили).Это где-то документировано у производителя? (ссылочка есть?) Данные сохранятся.
Ссылочку поищу и поже вставлю в этот пост.
(новый эксперимент3) - reset компу - сохранятся данные, или тут тоже все будет потеряно?
Случай практический. Сервер FreeBSD находится далеко, физически недоступен. Залочил систему IPFW. По SSH не войти. Единственый способ - позвать кого нибудь reset нажать.
(Правда есть средство отключить в ядре проверку клавы и клаву на ходу втыкать, а потом ctrl-alt-del) даные тоже сохранятся, и вот почитайте по поводу управления сервером на аппаратном уровне: плата расширения IPMI
Еще некоторые соображения по поводу батарейки.
Часто раздаются возгласы - "у меня UPS!". Так вот - не всегда он Вам поможет. Птому как - юпсы тоже летят, летят блоки питания, выдергиваются кабели. Бывает это редко, зато очень метко.
Что при этом произойдет.
1. Операционка уверена, что данные записаны, а на самом деле они того. В этом случае будут повреждены записываемые файлы, а Вы об этом даже не узнаете. А если и узнаете, то сделать ничего не сможете. Как крайний случай - повреждение файловой системы. Это еще похлеще будет. Структура NTFS то может быть и восстановится (а может быть и нет, т.к. при интенсивонй нагрузке потерянных кластеров может быть очень много), но вот данные.
2. Рассинхронизация (инконсистентность) массива. Дело в том, что сам контроллер будет думать, что он все записал, а на самом деле. В результате данные в информационных блоках и парити не будут совпадать. До некоторой степени это может быть вылечено consystensy check'ом (кстати далеко не все знают что это такое), но опять таки - далеко не всегда, смотря какая нагрузка и сколько сбойных блоков. А если при этом еще и реальные бэд блоки на винтах есть, дело вообще кончится очень печально. В таких случаях нередко происходит просто развал массива со всеми вытекающими.
Так что не стоит полагаться на авось и экономить на спичках - батарейка стоит как правило порядка полутора сотен баксов, что несравнимо со стоимостью сервера, и, тем более, данных.
Дополнение в свете новых технологий
На большинстве современных аппаратных контроллеров устанавливаются не аккумуляторы, а суперконденсаторы и флэш - для той же цели.
Преимущества:
1. Срок жизни не ограничен 1-2 годами, как в случае аккумулятора. Кондера хватает на весь жизненный цикл сервера.
2. Предельная температура значительно выше (у BBU обычно 40 градусов, что иногда непросто обеспечить).
3. Кондер позволяет сбрасывать содержимое кэша на флэшку сразу же, а не дописывать при последующем включении (в случае BBU нужно успеть включить сервер в течение 2-3 дней после потери питания).
Рассмотрим несколько различных вариантов построения дисковой подсистемы сервера с целью сравнения их по цене и быстродействию. В качестве величины полезной емкости дискового хранилища выберем значение 10TB. Во всех вариантах предполагается использование аппаратного RAID-контроллера с кэш-памятью 2GB.
Бюджетный вариант – два жестких диска 3,5" объемом 10TB с интерфейсом SATA и скоростью вращения шпинделя 7200 об./мин., объединенных в массив RAID1. Быстродействие такого массива не превысит 500 операций в секунду (IOPS) при чтении и 250 IOPS при записи. Дополнительный плюс этого решения – возможность кратного увеличения емкости хранилища за счет добавления новых дисков в свободные отсеки дисковой корзины сервера.
Производительный вариант – 12 HDD 2,5" 10’000RPM емкостью 1,8TB в RAID10 (RAID5 или RAID50 в два раза медленнее на операциях записи). Здесь мы получим на чтении около 5’000 IOPS, а на записи 2’500 IOPS - в 10 раз больше по сравнению с первым вариантом. Однако и обойдутся эти диски примерно в шесть раз дороже.
Максимальное быстродействие обеспечит массив RAID10 из SSD-накопителей, например, 12 штук Intel DC S4600 1,9TB. Производительность такого массива составит 800’000 IOPS на операциях чтения и 400’000 IOPS на операциях записи, то есть быстрее второго варианта в 160 раз, но дороже по сравнению с ним в 4 раза, а с первым вариантом – в 24 раза. Выбор SSD-накопителей большего размера даст примерно такие же цифры по стоимости и немного ниже – по производительности.
В общем, чем дороже, тем быстрее. И даже скорость обгоняет цену.
Прирост производительности на 3 порядка, который обеспечивают твердотельные накопители, является чрезвычайно привлекательным, однако на хранилищах такого объема обходится слишком дорого.
К счастью, существует менее затратная технология, которая может обеспечить производительность того же порядка, что и обычный массив из SDD-накопителей. Она основана на использовании SSD-накопителей в качестве кэш-памяти дисковой подсистемы.
Идея SSD-кэширования основана на концепции «горячих» данных.
Обычно серверные приложения активно работают лишь с небольшой частью данных, хранящихся в дисковой подсистеме сервера. Например, на сервере 1С транзакции осуществляются в основном с данными текущего операционного периода, а большинство запросов к серверу веб-хостинга обращается, как правило, к наиболее популярным страницам сайта.
Таким образом, в дисковой подсистеме сервера имеются блоки данных, к которым контроллер обращается значительно чаще, чем к другим блокам. Такие «горячие» блоки контроллер, поддерживающий технологию SSD-кэширования, хранит в кэш-памяти на SSD-накопителях. Запись и чтение этих блоков с SSD выполняются гораздо быстрее, чем чтение и запись с жестких дисков.
Понятно, что разделение данных на «горячие» и «холодные» достаточно условно. Однако как показывает практика, использование для кэширования «горячих» данных даже пары SSD-накопителей небольшого объема, объединенных в массив RAID1, дает очень большой прирост производительности дисковой подсистемы.
Технология SSD-кэширования применяется как для операций чтения, так для операций записи.
Алгоритм SSD-кэширования реализуется контроллером, он довольно простой и не требует от администратора никаких усилий по настройке и сопровождению. Суть алгоритма в следующем.
Когда сервер посылает контроллеру запрос на чтение блока данных, контроллер проверяет, находится ли данный блок в SSD-кэш.
Если да, контроллер читает блок из SSD-кэш.
Если нет, контроллер читает блок с жестких дисков и записывает копию этого блока в SSD-кэш. При следующем запросе на чтение данного блока, он будет считываться из SSD-кэш.
Когда сервер посылает контроллеру запрос на запись блока данных, контроллер проверяет, находится ли данный блок в SSD-кэш.
Если да, контроллер записывает данный блок в SSD-кэш.
Если нет, контроллер записывает данный блок на жесткие диски и в SSD-кэш. При следующем запросе на запись данного блока, он будет записываться только в SSD-кэш.
Что произойдет, если при очередном запросе на запись блока, которого нет в SSD-кэш, там для него не окажется свободного места? В этом случае самый «старый» по времени обращения блок в SSD-кэш будет записан на жесткий диск, а его место займет «новый» блок.
Таким образом, через некоторое время после начала эксплуатации сервера с использованием технологии SSD-кэширования кэш-память на SSD будет в основном содержать блоки данных, к которым приложения сервера обращаются чаще.
Если SSD-кэширование планируется использовать только для чтения, в качестве кэш-памяти на SSD можно использовать одиночный SSD-накопитель или массив RAID0 из SSD-накопителей, поскольку SSD-кэш будет хранить только копии блоков данных, хранящихся на жестких дисках.
Если SSD-кэширование планируется использовать для чтения и записи, то «горячие» данные будут храниться только в кэш-памяти на SSD. В этом случае необходимо обеспечить резервирование таких данных, для чего использовать в качестве кэш-памяти два или более SSD-накопителей, объединенных в RAID-массив с избыточностью, например, RAID1 или RAID10.
Давайте посмотрим, как технология SSD-кэширования работает на практике, а заодно сравним эффективность ее реализации на контроллерах двух разных производителей – Adaptec и LSI.
Тестирование
Основной дисковый массив: RAID10 из шести HDD SATA 3,5" 1TB. Полезный объем массива 2,7TB.
SSD-кэш: RAID1 из двух SSD Intel DC S4600 240GB. Полезный объем массива 223GB.
В качестве «горячих» данных мы использовали первые 20 миллионов секторов, то есть 9,5GB, основного массива RAID10. Выбранный небольшой объем «горячих» данных принципиально ничего не меняет, но позволяет значительно сократить время тестирования.
Тестируемые контроллеры: Adaptec SmartRAID 3152-8i и BROADCOM MegaRAID 9361-8i (LSI).
Нагрузка на дисковую подсистему создавалась при помощи утилиты iometer. Параметры нагрузки: размер блока 4K, случайный доступ, глубина очереди 256. Мы выбрали большую глубину очереди, чтобы сравнивать максимальные показатели производительности, не обращая внимания на время задержки.
Производительность дисковой подсистемы фиксировались при помощи системного монитора Windows.
Adaptec (Microsemi) SmartRAID 3152-8i с технологией maxCache 4.0
Этот контроллер по умолчанию поддерживает технологию SSD-кэширования maxCache 4.0 и имеет 2GB собственной кэш-памяти c защитой от потери питания в комплекте.
При создании основного массива RAID10 мы использовали установки контроллера по умолчанию.
Массив RAID1 кэш-памяти на SSD был установлен в режим Write-Back, чтобы включить SSD-кэширование на чтение и запись. При установке режима Write-Through все данные будут записываться на жесткий диск, поэтому мы получим ускорение только на операциях чтения.
Красная линия – производительность дисковой подсистемы на операциях записи.
В первый момент наблюдается резкий всплеск производительности до значения 100’000 IOPS – данные записываются в кэш контроллера, который работает со скоростью оперативной памяти.
После заполнения кэш производительность падает до обычной скорости массива жестких дисков (примерно 2’000 IOPS). В это время блоки данных записываются на жесткие диски, поскольку этих блоков в кэш-памяти на SSD еще нет и контроллер не считает их «горячими». Копия данных записывается в SSD-кэш.
Постепенно все больше блоков записывается повторно, такие блоки уже есть в SSD-кэш, поэтому контроллер считает их «горячими» и записывает только на SSD. Производительность операций записи при этом достигает 40’000 IOPS и стабилизируется на этой отметке. Поскольку в SSD-кэш данные защищены (RAID1), нет необходимости перезаписывать их в основной массив.
Отметим, кстати, что заявленная производителем скорость записи для используемых нами здесь SSD-накопителей Intel DC S4600 240GB составляет как раз 38’000 IOPS. Поскольку мы записываем один и тот же набор данных на каждый накопитель из зеркальной пары массива RAID1, можно сказать, что SSD-накопители работают на максимально возможной для себя скорости.
Синяя линия – производительность дисковой подсистемы на операциях чтения. Левый участок – чтение данных из массива жестких дисков со скоростью примерно 2’000 IOPS, в кэш-памяти на SSD пока нет «горячих» данных. Одновременно с чтением блоков жестких дисков выполняется их копирование в кэш-память на SSD. Постепенно скорость чтения немного растет, поскольку начинают «попадаться» блоки, ранее считанные в SSD-кэш.
После записи в SSD-кэш всех «горячих» данных их чтение выполняется оттуда со скоростью более 90’000 IOPS (второй синий участок).
Фиолетовая линия – комбинированная нагрузка (50% чтение, 50% запись). Все операции выполняются только c «горячими» данными на SSD. Производительность в районе 60’000 IOPS.
Контроллер Adaptec SmartRAID 3152-8i отлично справится с организацией SSD-кэширования. Поскольку контроллер уже включает поддержку maxCache 4.0 и защиту кэш-памяти, необходимо приобрести только SSD-накопители. Контроллер удобен и прост в настройке, установки по умолчанию обеспечивают максимальный уровень защиты данных.
Видео с записью тестирования Adaptec maxCache 4.0:
LSI (BROADCOM) MegaRAID 9361-8i
Этот контроллер поддерживает технологию SSD-кэширования CacheCade 2.0. Для ее использования необходимо приобрести лицензию стоимостью около 20’000 рублей.
Защита кэш-памяти не входит в комплект поставки, но по результатам тестирования мы выяснили, что для получения максимальных показателей производительности кэш контроллера лучше использовать в режиме Write-Through, который не требует защиты кэш.
Установки контроллера для основного массива: кэш контроллера в режиме Write-Through; режимы чтения Direct IO, No Read Ahead.
Кэш-память на SSD-накопителях (массив RAID1) в режиме Write-Back для кэширования операций чтения и записи.
Картина тестирования (здесь диапазон вертикальной шкалы в два раза больше, чем у Adaptec):
Последовательность тестирования такая же, картина похожая, но производительность CacheCade 2.0 несколько выше, чем maxCache.
На операциях записи «горячих» данных мы получили производительность почти 60’000 IOPS против 40’000 у Adaptec, на операциях чтения – почти 120’000 IOPS против 90’000 IOPS, на комбинированной нагрузке – 70’000 IOPS против 60’000 IOPS.
Здесь нет «всплеска» производительности в начальный момент тестирования операций записи, поскольку кэш контроллера работает в режиме Write-Through и не используется при записи данных на диски.
У контроллера LSI более сложная настройка параметров, требующая понимания принципов его работы. Для использования SSD-кэширования не требуется обязательное наличие защиты кэш-памяти контроллера. В отличие от Adaptec возможно использование SSD-кэш для обслуживания сразу нескольких RAID-массивов. Более высокая производительность по сравнению с контроллерами Adaptec. Требуется покупка дополнительной лицензии CacheCade.
Видео с записью тестирования LSI CacheCade 2.0:
Заключение
Дополним нашу табличку. При сравнении цен учтем, что для массива в 10TB желательна кэш-память большей емкости. Цифры производительности возьмем из нашего тестирования.
Несколько рекомендаций
При кэшировании записи всегда используйте в качестве SSD-кэш массивы с избыточностью (RAID1 или RAID10).
Рекомендуемый объем SDD-кэш - 5-10% от емкости основной дисковой подсистемы.
Для SSD-кэш используйте только серверные SSD-накопители. Они имеют дополнительную «невидимую» область размером около 20% от заявленного объема. Эта резервная область используется для внутренних операций дефрагментации и «сборки мусора», благодаря чему производительность таких накопителей на операциях записи не падает даже при 100% их заполнении. Кроме того, наличие резервной области экономит ресурс накопителя.
Ресурс SSD-накопителей для кэш-памяти должен соответствовать нагрузке на подсистему хранения сервера по объему записываемых данных. Ресурс накопителя обычно определяется параметром DWPD (Drive Writes Per Day) – сколько раз в день можно полностью перезаписать накопитель на протяжении 5 лет. Накопители с ресурсом 3 DWPD и более обычно будут подходящим выбором. Измерить реальную нагрузку на дисковую подсистему можно при помощи системного монитора.
В случае, если возникнет необходимость перенести все данные из кэш-памяти на SSD-накопителях на основной массив, нужно переключить режим работы SSD-кэш с Write-Back на Write-Through и подождать пока данные полностью не перепишутся на жесткие диски. По окончании этой процедуры, но не ранее, контроллер «позволит» удалить том SSD-кэширования.
Читайте также: