Отказоустойчивость в СХД Qsan

Сегодня в IT-инфраструктуре, с повсеместным использованием виртуализации, системы хранения данных являются ядром, хранящим все виртуальные машины. Отказ этого узла способен полностью остановить работу вычислительного центра. Хотя немалая часть серверного оборудования имеет отказоустойчивость в той или иной форме «по умолчанию», именно из-за особой роли СХД в рамках дата-центра к ней предъявляют повышенные требования в плане «живучести».

Наиболее эффективным методом обеспечения отказоустойчивости в IT является использование нескольких экземпляров оборудования и ПО (в простейшем случае – дублирование). Конечно же СХД можно целиком задублировать. И для disaster recovery именно такой подход и используется. Но далеко не всем компаниям такое решение по карману. Речь даже не только об удвоенной стоимости оборудования, но и о прочих затратах по организации подобного решения и его дальнейшей поддержке.

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

Модули охлаждения

Очень часто в СХД с корпусами 2U-3U используется комбинированные модули, объединяющие в себе блоки питания и вентиляторы. С одной стороны, это удобно, т.к. обслуживать нужно только один блок. С другой, если выйдет из строя система охлаждения, может принудительно быть отключен блок питания во избежание перегрева. И вроде возникнет не самая критическая ситуация, но добавлять уязвимости СХД явно не стоит.

Охлаждение в СХД Qsan организовано в виде отдельных модулей с «горячей» заменой, независимых от блоков питания. Собственно, в блоках питания присутствуют свои вентиляторы, предназначенные для обдува самих БП. Модуль охлаждения вмещает в себя два независимых вентилятора, которые страхуют друг друга. Таких модулей в СХД два: справа и слева – для эффективного обдува всех компонентов. Если происходит отказ одного из вентиляторов, все остальные автоматически увеличивают свои обороты с целью компенсировать образовавшийся недостаток воздушного потока. Именно поэтому неисправность вентилятора не влечет за собой опасность перегрева всего устройства

Топология подключения полок расширения

Классическая схема подключения полок расширения к СХД подразумевает собой топологию, именуемую каскадом. В этом случае соответствующие контроллеры полки и СХД соединяются между собой единственным SAS кабелем. Итого получается 2 кабеля на двухконтроллерную систему. Если требуется подключить вторую, то она подключается таким же способом к первой полке. И так далее. Плюсом данной топологии является простота реализации в оборудовании. А минусом будет некоторая уязвимость перед внезапным разрывом SAS цепи из-за перекрестного выхода из строя несоединенных между собой контроллеров СХД и полки или из-за обесточивания одной из полок расширения в середине цепи. Результатом будет потеря доступа к части накопителей и возможный развал RAID группы, если она «размазана» по нескольким корпусам.

От перекрестного выхода из строя контроллеров у Qsan имеется защита в виде внутренней логической связи контроллеров через бэкплейн СХД. Т.е. контроллер СХД видит не только контроллер JBOD, непосредственно подключенный к нему, но и контроллер «соседа» через специальный линк в бэкплейне. В результате, если произойдет такая ситуация и никто физически не будет выдергивать SAS кабели между СХД и полкой, то доступ ко всем накопителям будет сохранен.

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

Если хочется более сильной защиты, то можно строить конфигурации масштабнее, используя, например, топологию дерева. Либо еще усложнить за счет комбинации упомянутых топологий. Это возможно благодаря большому количеству SAS разъемов на устройствах (2 у каждого контроллера СХД и 5 у каждого контроллера JBOD) с автоматическим определением режимов работы вход/выход. Главное, чтобы сам администратор не запутался. А уж СХД сумеет правильно настроить конфигурацию.

Fast rebuild

Наличие в системе резервных дисков «горячей» замены (hot spare) существенно повышает надежность хранения информации. Однако, просто факт выделения подобных дисков еще не означает абсолютной защиты. Дело в том, что процесс восстановления (ребилд) достаточно трудоемкий и зачастую продолжительный по времени. Трудоемкость возникает из-за непрекращающегося доступа к основным данным. Т.е. система наряду с текущей работой еще и должна копировать данные на новый диск. А продолжительность ребилда напрямую зависит от емкости накопителя и его скоростных характеристик. Поскольку система ничего не знает о реальном занятом пространстве на дисках, она в процессе ребилда просто копирует всё: блок за блоком.

В результате восстановление современного диска большой емкости в 10+ТБ при серьезной нагрузке на СХД срок может легко составить неделю и более. Также следует иметь в виду тот факт, что во время ребилда значительно повышается вероятность отказа других накопителей из-за повышенной нагрузки на них. А это уже может представлять серьезную опасность в случае использования, например, RAID5.

В качестве решения данной проблемы многие разработчики СХД озаботились ускорением процесса восстановления. Для этого могут применяться разные подходы, но суть одна – копирование при ребилде только реально занятых блоков. Не остался в стороне от этой проблемы и Qsan. В СХД этого вендора при активированной опции Fast Rebuild система ведет трекинг используемых для записи блоков, тем самым имея возможность в случае отказа диска копировать на новый накопитель только их.

Опция Fast Rebuild не включена по умолчанию при создании новых томов, т.к. ее использование имеет влияние на производительность, особенно при операциях random write, потому что:

1. Необходимо вести трекинг записи в блоки;
2. При ребилде не происходит пересчет контрольных сумм для незанятого пространства, поэтому при новой записи в эту область требуется сначала «инициализировать» его.

Поэтому не рекомендуется использовать Fast Rebuild для томов, например, с высоконагруженными базами данных или в системах видеонаблюдения, где том все равно в итоге будет заполнен на 100%. А вот для файловых или почтовых серверов данная опция будет как раз очень полезна.

Вместо заключения

Каждый производитель СХД подразумевает, что его устройства надежны. И если нет фатальных просчетов при разработке устройств и невероятной тяги к экономии в процессе их производства и тестирования, то в целом можно согласиться с вендором. Однако нужно понимать:

• базовая отказоустойчивость СХД – это прежде всего способ продолжать иметь доступ к данным в случае отказа какого-либо компонента(ов);
• дополнительные опции по части отказоустойчивости (вроде тех, что описаны выше) – это исключение некоторых вариантов неисправностей и повышение ваших шансов иметь доступ к данным;
• 100% надежности, увы, не бывает. Но, чтобы максимально приблизиться к ней, большинство вменяемых вендоров СХД (и Qsan в их числе) прилагают максимум усилий для непрерывного совершенствования своих продуктов как в аппаратной, так и в программной части.

При этом также не стоит забывать, что никакая абсолютная надёжность СХД не отменяет наличия резервных копий, четких и отрепетированных планов по восстановлению в случае аварии и оперативной технической поддержки вендора.

Ссылка на источник: Отказоустойчивость в СХД Qsan/Skilline corporate blog