Несколько дней назад (по большей части от любопытства) занимался реанимацией IBM DS4500. На всякий случай – с 2003 до 2006го года это была старшая система класса midrange у IBM. Потом на смену ей пришла DS4800, а с год назад и DS5100/DS5300, а пациент все работал и работал на благо … ну наверняка на чьё-то благо он все-таки работал. Только вот в какой-то момент ему стало тошно от такой жизни и решил он уйти на покой вместе со всеми данными. Сказал, что и дисков он своих знать не хочет, и с контроллерами у него не все ладно (да на всякий случай от одного сразу и открестился). И пришлось вокруг старичка попрыгать разве что не с бубном. По счастью, завести эту DS4500 удалось (конечно не без какой-то там матери, но главное при помощи девственно чистого файберного диска, лежавшего в загашнике). После “оживления” оказалось, что и контроллеры оба замечательно себя ощущают, и диски все живы, и даже данные оказались на своих местах. Но повозиться пришлось изрядно, а одна из основных причин состояла на мой взгляд в том, что прошивка на системе стояла чуть ли не та, с которой она вышла с завода. Сама по себе, возникшая проблема со старой прошивкой связана скорее всего не была, но вот будь она (прошивка) поновее, решение проблем потребовало бы в несколько раз меньше времени. Поэтому решил я дать несколько рекомендаций для тех, кто администрирует различные системы хранения:
Как правило, производитель рекомендует определенную версию прошивки для каждой системы (разумеется, со временем рекомендуемая версия меняется). Не стоит пренебрегать этим! Даже если проблем с системой нет, раз в пол-года проверяйте актуальные рекомендации и просматривайте список изменений. Даже если Вы не будете обновлять систему, Вы хотя бы будете знать какие проблемы были исправлены (вполне возможно что Вы уже с этими проблемами сталкивались, но не соотнесли их с СХД) – предупрежден, значит вооружен!
Самую последнюю прошивку, которая вышла “вот только вчера ночью”, устанавливать можно лишь в том случае, когда в системе есть серьезные проблемы, которые мешают ее нормальной эксплуатации! Прошивать “продуктив”, чтобы проверить “ту самую фишку”, которую только что анонсировали, не стоит – проблемы, которые могут возникнуть, сильно омрачат Вашу радость от мизерных улучшение. Если все-таки нужны новые возможности, то оптимальный путь – дождаться следующего обновления и, если не было найдено критических ошибок, доведите версию ПО до предыдущей.
Убедитесь, что фоновые процедуры проверки работают – в противном случае можете оказаться лицом к лицу с “вылетевшим” вторым (третьим) диском при перестроении массива. Чем это грозит наверное можно даже и не упоминать.
Регулярно проверяйте состояние батарей, защищающих кэш. Заранее озаботьтесь заказом новых. Помните, что при выходе батареи из строя, большинство СХД отключают кэш записи. После этого производительность может снизиться в нескольких раз. Конечно есть ненулевой шанс найти батарейку “живьем” в Москве или другом городе, но если система Ваша не новая (а тем более, если она уже снята с производства), батарейка эта наверняка провалялась на складе не один год. Так что нашли-то Вы ее “живьем”, а вот по факту она окажется “трупом”. Лучше прождать два-три месяца (в наших реалиях), но получить батарею, которая прослужит хотя бы пару лет.
Следите за состоянием массива даже если он находится на вторых (третьих или четвертых) ролях. Потому как по закону подлости на нем обязательно окажутся данные, которые есть в единственном экземпляре (“вот только вчера записали, а сегодня хотели бэкап сделать”) и которые ни в коем случае нельзя потерять. Только вот массив-то уже месяц был в критическом состоянии, а сегодня его совсем медным тазом прикрыло.
Ну и два главных совета:
Постарайтесь, чтобы слова “О, а у нас оказывается есть СХД!” звучали не только тогда, когда эта СХД сломалась!
Если есть финансовая возможность продлевать сервисное обслуживание, то этим Вы существенно облегчите себе жизнь! А если такой возможности вроде бы и нет, то постарайтесь аргументировать для людей, выделяющих финансы, необходимость этого продления – в случае возникновения проблем в системе без сервиса, решать эти проблемы придется скорее всего Вам самому.
Глупый вопрос, не правда ли? Особенно глупо звучит, если Вы вдруг пропустили начало 90х годов прошлого века в России. Зато сейчас заканчивается первое десятилетие уже этого века, а все чаще приходится слышать не менее странную фразу: “зачем бэкап делать, если я уже RAID настроил?”. И звучит это, к сожалению, чаще всего не в момент создания системы, а уже в тот момент, когда данные надо спасать, причем спасать далеко не традиционными способами. И чем дороже был куплен RAID-контроллер, тем больше возмущение – “Я потратил такие деньги на контроллер, я разве похож на Рокфеллера, чтобы еще и резервную копию делать?! Все пропало! Производители сговорились! Нет справедливости на свете! Ведь я купил контроллер как раз для того, чтобы защитить свои данные!” Как Вы понимаете, речь идет главным образом о “домашних” пользователях, но иногда и в малом бизнесе наблюдаются подобные проблемы.
И возмущение это могло бы быть справедливым, если бы только хоть один производитель RAID-контроллеров позиционировал свой продукт как замену резервному копированию. Так для чего же тогда нужен RAID? Может ли он обеспечить защиту данных? Ответ, как это обычно и бывает, не так однозначен: может, но только в некоторых случаях. В каких? Очень просто - RAID (кроме RAID-0) обеспечит доступность данных при выходе из строя одного или более (например, двух в случае RAID-6) дисков. Вот собственно и вся защита, которую теоретически может Вам обеспечить аппаратный или программный RAID. Не больше! Обратите внимание на слово “доступность” – именно это главная задача, т.е. целю является не защита данных вообще, а минимизация возможных простоев. А могут ли данные на RAID-массиве “пропасть”? Конечно могут! И вариантов здесь очень много, вот лишь несколько примеров:
Программная ошибка - самый простой случай и никак не зависит от наличия RAID.
Ошибка пользователя – не менее редкий (а скорее более распространенный) вариант.
Поломка сразу двух дисков в RAID-5 (либо трех в RAID-6). Скажете, что это маловероятно? Вовсе нет – если используются диски большого объема, то вероятность повторного сбоя во время перестроения (rebuild) массива при выходе одного из дисков заметно возрастает. Кроме того, возможна банальная проблема с блоком питания, который просто “убьет” электронику в нескольких дисках.
“Накопившиеся” логические ошибки на массиве. Откуда они берутся? На аппаратных RAID-контроллерах обычно есть кэш, который может значительно увеличить производительность дисковой операций записи. Но если кэш на запись никак не защищен, то неожиданная перезагрузка системы приведет потере данных в кэше контроллера. Если эта перезагрузка произошла, когда данные просто “ждали” в кэше, то будет ошибка на уровне файловой системы. А вот если в момент перезагрузки данные из кэша уже записывались на диски, то часть данных может оказаться записанными, а часть – нет. И теперь уже ошибки есть не только на уровне файловой системы, но и на уровне самого RAID-массива, так как неизвестно какая часть страйпа записана, а какая –нет. Для “отлова” таких ошибок большинство производителей предлагают соответствующие процедуры (consistency check), но кто ими пользуется пока гром не грянул? Защитить себя от этих проблем можно и батарейкой (BBU), конденсаторами с флэш-памятью или отключением кэша на запись. Но первое стоит денег, а второе - производительности.
Кэш есть не только на контроллере, но и на самих дисках. И операции записи кэшируются и на самих дисках. Всегда рекомендуется этот кэш выключать, но для SATA дисков и слабеньких контроллеров это радикально снижает производительность дисковой подсистемы. И те, кто не желает получить медленную систему все-таки оставляют этот кэш включенным. Что может случиться? Правильно, как и несколькими строками выше, перезагрузка может повлечь за собой потерю данных в кэше. И даже если контроллер думает, что с массивом все нормально, но на самом диске данные будут записаны совсем не те, которые нужны. И если этот сбой произошел на блоке с четностью, то до тех пор пока с массивом все нормально, данные будут доступны, а как только этот блок будет использован для восстановления (после сбоя совсем другого диска), в восстановленных данных будет “мусор”.
Контроллер взаимодействует с дисками, которые могут “отвечать” на команды контроллера с различными задержками (например, когда диск пытается сделать remap сбойного сектора). И контроллер может не дождаться ответа и отправит диск “на покой”. А что будет если это уже второй диск в RAID5? Правильно – данным можно сказать “прощай”. Да, конечно, диски из списков совместимости такими проблемами страдают крайне редко, но вот часто ли домашний пользователь смотрит на эти пресловутые списки? К сожалению нет, гораздо чаще голосование происходит либо рублем, либо в пользу “любимой” марки.
Выше я перечислил только самые распространенные случаи, все это может накладываться друг на друга и число потенциальных проблем вырастает как снежный ком. Если в момент какого-то из сбоев происходит еще и “рисковая” операция с массивом (например добавление диска в массив), то вероятность успешного восстановления данных “своими руками” (я уже даже не говорю про средства самого контроллера) стремительно приближается к нулю. Что мы, увы, очень часто наблюдаем (правда со стороны).
Так может быть, скажете Вы, RAID контроллеры это “зло” и средство для обогащения жадных производителей? Столько ужасов рассказано, может быть RAID дома и не нужен вовсе? Когда же имеет смысл его использовать?
Если нужно повысить скорость работы дисковой подсистемы (когда производительности одного диска мало). Если хобби это обработка видео или “игры” с виртуальными машинами, то почему бы и нет?
Компьютер – часть домашнего офиса и там хранится коммерчески важная информация. Вам ведь нужно обеспечить защиту данных до того, как будет сделана резервная копия.
Жалко времени на переустановку системы в случае выхода из строя диска. Вполне логично, особенно если компьютер это не полигон для испытаний и еженедельная переустановка Windows не входит в воскресное расписание.
Хранятся большие объемы данных в оперативном доступе и нет никакого желания восстанавливать их в случае сбоя диска.
О чем же нужно помнить, если решили упростить себе жизнь, используя RAID?
Использование любого RAID, установка BBU, отключение кэшей, регулярные проверки – ничто не гарантирует сохранность данных, если нет проверенной резервной копии.
Копии важных данных должны храниться на разных носителях и очень желательно, чтобы один из этих носителей не был бы доступен для записи.
А ниже несколько рекомендаций на случай, если все-таки хочется наплевать на все то, что было сказано выше, и сделать по-своему:
Создавая RAID-массив, записывайте все настройки (порядок дисков, размер страйпа и т.п.). Записывайте даже если Вы просто приняли все предлагаемые значения. Фактическое значение этого самого “default” для разных версий прошивки (firmware) аппаратного контроллера может отличаться. Разумеется не нужно хранить эти данные в текстовом файле на самом массиве – не пожалейте листа бумаги.
Поддерживайте актуальную версию прошивок и драйверов. Хотя и не нужно бросаться грудью на амбразуры и устанавливать новую прошивку в день ее выхода – если у Вас сейчас нет проблем, подождите с недельку-другую, может быть именно с ней возникнут проблемы и она будет вскоре заменена.
Используйте все доступные средства мониторинга. Если о случившемся сбое Вы узнали не из сообщения об ошибке в почте, а из того что система уже не загружается, зачастую уже поздно бывает что-то спасать.
Делайте регулярную проверку целостности данных.
Сделайте копию хотя бы самых-самых важных данных, например на DVD диски.
Если планируете что-то изменить в конфигурации массива (добавить диски, изменить уровень RAID и т.п.), перечитайте еще раз пункт №5 (а лучше все это сообщение). Если изменение прошло успешно, вспомните про пункт №1 и измените соответствующие записи.
Для аппаратных контроллеров диски выбирайте не по цене или общему впечатлению о бренде, а из списков совместимости для данного контроллера.
Если что-то сломалось, прежде всего скопируйте самые важные данные, а уже потом занимайтесь самолечением.
Если сломалось все так, что данные уже недоступны, не делайте резких движений и обратитесь к профессионалам. Найти таковых не представляет особенных проблем – даже если Вы находитесь вдали от двух столиц, общение можно свести к пересылке по почте и телефонному общению. Поверьте, почтовые затраты померкнут на фоне стоимости работ по восстановлению. Если есть возможность, сделайте посекторную копию всех дисков и экспериментируйте уже “на кошках”.
Все это конечно не оградит Вас от потери данных, но поможет заметно снизить риск этих потерь и вполне возможно сделает чуть ниже стоимость работ по восстановлению (если все-таки час “Х” настанет). Еще раз: будьте готовы к тому, что для восстановления данных нужно будет обратиться в специализированные организации. И не удивляйтесь когда стоимость работ окажется в несколько раз выше цены дисков и контроллера вместе взятых. Если же такие траты Вам не по плечу, то задумайтесь еще раз о резервном копировании тех данных, которые не хотите терять. И мойте руки с мылом, а в чай кладите сахар.
