Про то, как диски протухли и испортили всю СХД, и почему в Unity такое не случится

rackspace_data_centre_sydney

Вот реальная история, которую рассказал мне товарищ, которому нет оснований не доверять. Случилось это у одного его заказчика. Есть у того в облачном ЦОДе большой дисковый массив, набитый дисками почти под завязку. Покупали СХД, как обычно с запасом, а опытный администратор, ёмкость раздал не всю сразу, а пару дисковых полок (а может и больше) прикопал...  оставил несконфигурированными. И вышло так, что про эти полки забыли то ли на год, то ли на два.

Может быть система наша оказалась очень эффективной, а может потому что данные росли не так быстро как ожидалось. Но, скорее всего, еще и потому, что несконфигурированные диски не показываются в общей полезной ёмкости СХД и не попадают в отчеты. А то, что не измеряется как бы и не существует вовсе.

Долго ли, коротко ли так было, но админ однажды увидел свободные диски (а может он уже давно их видел, просто никто не спрашивал). Короче, решил админ эти диски использовать по назначению.

Так как современные массивы, особенно в облачных ЦОДах, используют эластичные дисковые пулы, где вся емкость дисков виртуализована, то логично новые диски добавить в один из таких пулов, и перемешать их гигабайты с теми, что уже доступны для пользователей.

Так как администратор наш человек опытный, то он знал, что диски долго простоявшие без дела могут «закиснуть», то он не стал включать их все в пул разом, а оставил некоторое количество на замену вышедших из строя. Хороший оставил запас, причём.

И вот, включил он расширение гибридного пула, добавив в него стоявшие ранее без дела диски, и стал смотреть.

Пул ведь расширяется как? Сначала новая ёмкость логически конфигурируется, потом данные пула начинают по ней распределяться, чтобы новое распределение данных и нагрузка на диски были равномерным. То есть, новые диски в итоге получают нагрузку и утилизацию наравне со старыми.
Но перед этим, в процессе ребалансировки,  общая нагрузка на диски особенно высокая. Так что вероятность выхода из строя отдельных дисков в целом выше.

И вот один диск вышел из строя. Включилась одна горячая замена. Время ребилда под нагрузкой, как обычно, большое. Вышел из строя второй диск. Еще одна «хот спара» подключилась. Полёт нормальный.

В принципе, виртуальный пул состоит из RAID сетов , поэтому выход из строя двух дисков не обязательно приводит к потере данных. Поэтому ребилд просто продолжился, но уже на 2 диска горячей замены.

Один диск отребилдился успешно, но следом за этим вышел из строя третий.. А затем четвертый, пятый и ещё сколько-то. В итоге, массив не успел. Вышло из строя два или три диска в одном из сетов, что привело к потере доступа к данным на уровне всего большого виртуального пула.

Приложения рухнули. Массив фактически стал неработоспособен. Произошло это потому, что пул является единым логическим пространством на котором нарезаются тома, а неустранимый сбой на уровне пула приводит к сбою всех лежащих на нем томов. При этом ещё оставался неизрасходованный запас дисков горячей замены.

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

Законный вопрос — почему диски испортились, а массив об этом ничего не знал? Есть же внутренние процессы фонового сканирования целостности данных, есть внутренние контрольные суммы, проактивное обнаружение сбоев.  Есть то они есть, но как оказалось, дело все в том, что они сканируют только ту емкость, которая сконфигурирована хоть как-то. Это должна быть емкость дисков включенных в пулы, либо назначенных под горячую замену. А диски, которые просто «стоят» массив может вообще отключить. Была такая в свое время модная технология энэргосбережения — spin down. Сейчас от нее, похоже везде отказались, но сам принцип «не гонять» в пустую диски, которые не сконфигурированы — видимо еще не до конца был изжит к тому времени, когда эта невезучая система хранения приобреталась.

История эта, к счастью, закончилась хорошо, потому что наш сервис смог при помощи спец средств довести ребилд до конца и восстановить доступ к данным. Но седых волос у причастных прибавилось.

Чтобы такое не случалось в ваших массивах — конфигурируйте все инсталлированные диски. Это им точно не повредит. Допустим у вас есть в резерве диски, которые пока не задействованы в пулах.

Создайте простейшую RAID группу или пул. Создайте на ней просто большой пустой LUN, чтобы массив его проверял в фоновом режиме, и все будет хорошо. Альтернатива — сделайте из свободных дисков диски горячей замены. Их массив тоже будет проверять, и неожиданностей сильно поубавится.

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

Надо сказать, что в новых массивах EMC  Unity виртуальные пулы являются единственно возможной архитектурой хранения данных. При этом все незадействанные диски автоматически назначаются под глобальную горячую замену. И давно нужно было так сделать.

Про то, как диски протухли и испортили всю СХД, и почему в Unity такое не случится: Один комментарий

  1. Тут наверно стоило уточнить, что указанная проблема так же не актуальна и для VNX2. Где все Unbound диски так же являются потенциальными HS.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s