Рейд-контроллеры и SSD

Блуждая по форуму сообщества VMware, я натолкнулся на интересный ликбез по работе рейд-контроллеров с SSD-дисками.

Umlyaut согласился на публикацию этого ликбеза на нашем блоге…

—

В современных (выпущенных в последние год-два) RAID-контроллерах есть такая фича, как SSD Guard (приписывается Интелу, но родом она с LSI, который ОЕМит для Интела вовсю давно).

Она работает примерно так: контроллер мониторит (SMARTом или SSD Guard Patrol`ом) состояние SSD-дисков массива и в случае обнаружения угрозы скорой кончины какого-либо из дисков переносит (на лету) инфу с потенциального покойничка на “запасной” SSD (который, есс-но, должен быть подключен к данному контроллеру).

Это своего рода аналог Hot Spare Drive, только срабатывает не после краша физ.диска массива, а до того.

Недостатком является то, что (как справедливо озвучивалось здесь и не только) “износ” ресурса носителей в RAID-массиве происходит практически равномерно – т.е. “зеркало” из SSD (либо “зеркальный” саб-юнит в R-10) имеет все шансы накрыться почти синхронно (да и в R-5 возможны залповые вылеты).

Отсюда присутствует необходимость держать для SSD Guard столько резервных SSD, сколько носителей мы хотим защитить – т.е. в пределе удвоить число SSD-дисков.

Да, ещё такой момент – один и тот же резервный SSD не может одновременно выступать как HSD и как “запасной аэродром” для SSD Guard – т.е. кроме удвоения к-ва SSD в массиве для SSD Guard нужно ещё предусмотреть “+1” для собственно HSD.

Eщё один недостаток SSD Guard – очень трудно придумать и реализовать “учения”. С HSD просто – дёрнул рабочий носитель тестового массива, контроллер заорал (плюнул варнингом по емейлу/смс/etc.) и начал ребилд. А вот как заставить контроллер запустить миграцию с имеющегося SSD на резервный… вот тут ХЗ…

Остаётся только уповать на то, что вендор данную фичу реализовал правильно и она не подведёт… Вопрос веры, тсзть…

Это что касательно отказоустойчивости…

А ещё контроллеры могут “знать” об SSD в разрезе такой фичи, как FastPath (или её аналогов у других вендоров). Она заставляет контроллер игнорировать геометрию физ.носителей (которую, в случае работы с обычными HDD, контроллер старается учитывать при распределении блоков данных на носителях). Вендор утверждает, что контроллер, которому не нужно “отвлекаться” на прикидку дискового обмена с учётом числа головок-цилиндров (отсутствующих у SSD), работает эффективнее. Возможно – сам не проверял.

Ещё одно “знание” контроллера об SSD – фича кеширования основного массива HDD на SSD – MaxIO/MaxCache (у Адаптека – оно же CacheCade у LSI).

Данные пишутся на HDD (и хранятся там же), но наиболее часто читаемые блоки массива (в объёме SSD-кеша) прозрачно копируются контроллером на SSD-кеш и читаются именно оттуда. Получаем сумасшедшую производительность на рэндомном чтении “горячих” данных, при этом повышается надёжность хранения инфы. Запись же идёт напрямую на харды (что в случае достаточного к-ва шпинделей может быть даже и сильно быстрее записи на SSD – если не брать совсем уж энтепрайзные SSD с конским ценником).

BTW, воодушевлённые успехом первого поколения SSD-кешей, вендоры забацали второе – с возможностью кеширования на SSD уже записи. Правда, подстраховались – если в режиме “read-only SSD-cache” в качестве кеширующего элемента можно использовать single-SSD или R0, то в режиме “read-write SSD-cache” – только R1 или R10.

Но есть один аспект, в котором RAID-контроллеры про SSD “не знают”.

Я про команду TRIM. Не припоминаю ни одной модели, умеющей транслировать данную команду от дискового драйвера ОС “вниз”, внутренним контроллерам флеша SSD-дисков. Это ощутимо сказывается на производительности при записи на “уже раз заполненные” диски. Что меня крайне удручает…

Нелишне будет вспомнить и о том, что VMware не поддерживает эту функцию в своих ОС.

Впрочем, ситуация с командой TRIM, реализованной лишь в W7/2008R2 и в некоторых линуксах, да и то на “просто HBA”, несколько смягчается дальнейшей эволюцией SSD в сторону “поумнения”.

Я имею ввиду появившийся в SSD некоторое время назад функционал BGC (Background Garbage Collection).

Смысл его, если вкратце – периодически самостоятельно (силами контроллера флеша, без внешних команд от ОС) стирать ячейки флеш-памяти с неактуальными уже блоками инфы с тем, чтобы потом не отвлекаться на их предварительное стирание при записи. Подобный сервис стал возможен благодаря тому, что запись на SSD устроена кардинально сложнее, нежели таковая на HDD – контроллер флеша сам “гоняет” инфу по ячейкам, “балансируя” износ и пр.

Впрочем, чтобы не загромождать эти “рэйдовые” заметки “фоновой инфой” об устройстве и работе SSD, с удовольствием отсылаю к чеканному материалу, наглядно и просто объясняющему данный аспект: http://nanogate.blogspot.com/2011/08/ssd.html

Сам же отмечу, что при наличии в эксплуатации RAID-массива из SSD с функцией BGC можно особо не переживать о неспособности какой-либо ОС сгенерить команду TRIM (равно как и о неспособности RAID-контроллера передать её “вниз” носителям).