Что такое SSD Guard

Обновлено 21.06.2017

Добрый день уважаемые подписчики и гости блога, продолжаем с вами изучать технологии систем хранения данных, и сегодня нам с вами необходимо разобрать вот такую вот вещь. В современных (выпущенных в последние год-два) 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 — контроллер флеша сам «гоняет» инфу по ячейкам, «балансируя» износ и пр.