Азбука сисадмина 2:Простые способы обеспечения сохранности пользовательских данных

Для начинающих администраторов малых ЛВС
1. Всё может сломаться
2. Всё, что может сломаться,
когда-нибудь ломается

3. Причём происходит это именно тогда,
когда этого меньше всего хочется

Мёрфи


И если нам платят за минимизацию последствий мелких неприятностей, средних проблем и крупных катастроф, то надо быть к ним готовыми постоянно.

Принципы работы с аппаратным обеспечением на примитивном уровне рассмотрены в предыдущей статье, сегодня речь пойдёт об информации, ради хранения, обработки и передачи которой и покупаются компьютеры.

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

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

Копирование информации на сменные носители для однократной записи

На настоящий момент доступно всем без исключения. Самый распространённый на сегодня вариант — DVD диски и соответствующий привод. Стоит недорого, есть повсеместно, использовать просто. Все уже знают, что фотографии ребёнка после копирования на жёсткий диск компьютера лучше сразу же прожечь на болваночку, а лучше на две, и вторую отнести, к примеру, отдельно живущим родственникам или в арендуемую сейфовую ячейку в банке. Если (не дай Бог!) случится пожар, то диск на полке компьютерного стола сгорит так же успешно, как и винчестер в рядом стоящем ПК. Да и без пожара со временем носитель может испортиться, а в случае наличия двух экземпляров вероятность одновременной потери данных меньше. Не говоря уже о том, что при применении специальных методов снять исходную информацию намного проще (и будет она полнее) с двух испорченных дисков с аналогичным содержимым, чем с одного. А фотографии ребёнка годовалой давности не купить ни за какие деньги, хотя вот дом и тем более новый ПК купить можно. Не то чтобы легко, но всё же. А информация — как любовь и здоровье, к деньгам все эти категории практически не имеют отношения. Но при своевременных затратах с одинаковым успехом все три вещи можно сберечь. Причём в основном не денежных затратах, а умственных и душевных. И информацию сберечь проще всего.

Так и в небольшой фирме — арендовать банковскую ячейку и время от времени (чем чаще, тем лучше) отвозить туда архивы не очень сложно и затратно, но весьма эффективно.

Инвентаризация как путь к порядку

Прежде чем заняться сохранением чего-либо, надо понять, что сохранять. Для этого нужно провести полную инвентаризацию используемых в работе данных и их классификацию по нескольким параметрам.

То, что могут знать лишь двое, и то не всегда

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

Общие данные основных рабочих программ

Тут всё совсем не на много проще, если вообще проще. Меняются они ежеминутно, архивироваться должны каждодневно минимум, а лучше и не по разу. Это как правило серверные задачи, т.е. построенные по распределённой архитектуре «клиент-сервер», где данные хранятся на сервере, а клиентские части приложения осуществляют только запросы-транзакции к ним. Только это и даёт надежду на правильную организацию процесса резервирования. Если часть сведений хранится у секретарши, часть у кладовщика, а основные у менеджера — беды не избежать.

Пользовательские критичные для производственного процесса данные

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

То, что почти не меняется

К примеру, корпоративный веб-сайт класса «визитка», рекламные материалы, информация для партнёров. Учредительные и сопутствующие документы, лицензии, разрешения, учебная литература, должностные инструкции и тому подобное. Как правило, это общедоступная информация, и её надо архивировать изредка, по мере обновления. Точнее даже сказать, что она должна появляться сначала в архиве, а потом выкладываться в общедоступное место. Тут проще всего, главное не забывать её размножать и редкие обновления тут же сохранять. Также прямой и светлый путь на сервер, в отдельную папку.

Те самые фильмы и музыка

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

Кстати о фильмах. Учитывая среднюю загруженность пользовательского ПК рабочими данными примерно в 5-10 Гб, и среднюю ёмкость диска современного офисного ПК в 80-120 Гб можно на каждой машине создать некое пространство на 50-100 Гб для хранения фильмов, музыки и резервных копий. Это может быть как скрытая от пользователя партиция, так и просто папка с ограниченным доступом. Конечно же не у каждого сотрудника можно заводить такие ресурсы. Централизованно управлять ими не обязательно, надо просто продумать права доступа в первую очередь и не забывать об их каталогизации.

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

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

Результатом инвентаризации должна стать агрегация на сервере всей важной информации, подлежащей защите.

11 сентября 2001 года погибло вместе с башнями WTC много данных — в них находились в основном офисы и филиалы крупнейших компаний, и те, у кого всё хранилось только локально, потом сильно об этом пожалели. На рынке после той катастрофы наблюдался взрывной рост спроса на услуги онлайновых служб удалённого распределённого хранения информации. Гром грянул — и сразу мусульман видно.

Защита основного места размещения информации

Есть простые, не очень дорогие и эффективные средства минимизации вероятности сбоев ПК, ведущих к разрушению информации. Самые важные — защита по питанию и резервирование жёстких дисков.

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

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

По возрастающей степени сложности и затратности это выглядит так:

  1. Два диска в RAID 1 средствами ОС (RAID 0 — это не RAID! Что отчётливо видно из его названия ;-)
  2. То же на простейшем контроллере, без собственного процессора для обсчёта логики массива
  3. Минимум четыре (лучше пять-семь по соображениям минимизации потерь дискового пространства и увеличения скорости работы) диска в RAID 5 с обязательным выделением одного в горячий резерв (Hot Spare) для немедленного пересчёта массива в случае отказа, на качественном контроллере со своей памятью и резервной батарейкой для корректного завершения работы при пропадании питания, что делает возможным включение кэширования записи
  4. Выделенное сетевое хранилище со своей системой обработки данных и высокой надёжностью вплоть до RAID 60 с несколькими резервными дисками
  5. Минимум пара таких хранилищ на территориально разнесённых площадках со скоростными резервированными каналами связи между всеми ними, и вроде пока ничего надёжнее ещё не придумали :-)

В нашем случае целесообразно рассматривать два первых варианта. Почему не стоит использовать RAID 5 без «правильного» контроллера? Да потому, что в RAID 1, «зеркале», каждый из двух дисков несёт на себе в явном виде всю необходимую информацию, которую можно снять с него на большом количестве других машин. А вот снять информацию с дисков RAID 5 при сбое к примеру контроллера — задача не тривиальная и не очень дешёвая.

Вообще же зеркалирование данных возможно и на критичных для производственного процесса клиентских машинах, но на серверах — обязательно.

Near Line Storage

NLS — термин и технология из серверного мира, но ничего особенно сложного в ней нет. Речь идёт всего лишь о том же зеркалировании данных, но не в пределах одного системного блока, а на другой компьютер. В примитивном варианте это выглядит как хранение файлов Лёши ещё и у Саши, а особенно важных — третьей копии у Маши. И соответственно Сашиных у Лёши. Если немного оптимизировать эту схему, то можно придумать механизм, который бы поборол человеческую забывчивость и лень и автоматически выполнял бы эти процедуры в определённое время. В принципе, в таком варианте уже значительно повышается устойчивость системы к потерям информации. Наряду с ручным самостоятельным копированием на оптический носитель (или флэш-диск) это главный способ защиты пользовательских данных, не имеющих глобального значения для компании и потому не дублированных на сервере.

Конечно же при наличии возможности лучше полностью дублировать все пользовательские файлы (кроме медийных) на сервере, или просто их там и держать, включая профайлы. Заодно такой подход сильно упрощает администрирование домена. Но это не дешёвое решение, такой сервер должен быть весьма мощным и содержать большой объём дисковой памяти с быстрым доступом. Кроме того, пропускная способность сети, и прежде всего концентратора, должна быть достаточной для обеспечения доступа к документам и профайлам без ущерба для скорости работы в основной серверной базе (базах) данных.

Если пойти немного дальше от уровня пользователя, то в серверной возможны две реализации такого подхода. Возможно полное дублирование критичной машины, когда на полностью настроенную, но не обслуживающую запросы пользователей её копию периодически сбрасывается вся важная информация с рабочего сервера. Если он не должен работать круглосуточно, то ночью полная копия (при остановленном как правило рабочем процессе и серверной программе) и возможно в обеденный перерыв частичная. В это же время выполняются другие регламентные работы. При полном отказе основного сервера поднять вчерашнюю копию при правильной организации процесса займёт не более часа. Если же обращения к нему идут круглосуточно, то решение проблемы сложнее и дороже, и в сегодняшнюю тему не укладывается. Кстати даже Microsoft позволяет при наличии одной лицензии на серверную ОС устанавливать ещё одну её копию на сервер резерва, правда «холодного», т. е. который постоянно выключен. А то, что мы рассмотрели ранее — это «горячий резерв» с функциями сетевого хранилища.

Второй подход — выделение именно хранилища, к которому пользователи не обращаются, а информация собирается на нём по его запросу через специальную программу, к примеру производства EMC, и её агентов на станциях, где находятся архивируемые данные.

Кажется, что это всё сложно и дорого, на самом деле напомню ещё раз — в вопросе сохранности информации нет понятия «дорогое решение», есть понятие соответствия цены решения уровню предоставляемой надёжности и сервиса.

Раньше для резервного копирования и архивного хранения чаще всего использовались ленточные накопители, с кассетами с магнитной лентой и автоподатчиками. Используются и сейчас из-за большой ёмкости кассет, но всё реже и реже, в связи с удешевлением решений на базе жёстких дисков. Библиотеки на основе оптических носителей всегда были скорее экзотикой, чем массовым товаром.

Итак, сейчас в основном применяются просто серверы с большим дисковым пространством. Надёжные комплектующие, мощные блоки питания, хороший SATA/SAS контроллер на пять-десять каналов, те самые пять-десять дисков в RAID 5, не быстрые, но ёмкие. В принципе, количество дисков на один сервер может быть достаточно большим, но это уже дорого за счёт специализированных корпусов и блоков питания, да и контроллеры с большим количеством каналов недёшевы (вот SCSI поддерживает до 14 устройств, а на SATA портов меньше обычно). А десяток дисков можно разместить в стандартном корпусе 2-3U, и остальные комплектующие использовать массовые, если такой термин применим к рынку серверных комплектующих.

А вот самое главное — подходящая под задачу и правильно настроенная программа для реализации этой задачи. Диапазон здесь очень широк, от встроенных средств операционной системы (слабо), через самописные скрипты (почти всегда достаточно при должной квалификации автора) до мощных специализированных пакетов, предоставляющих максимально гибкие и удобные инструменты, но весьма не дешёвых.

На каком уровне реализации системы «близкого копирования» остановиться в аппаратном и программном обеспечении, решать надо исходя из оценочной стоимости информации и простоя в работе в данном конкретном случае, но по-хорошему хотя бы в самом примитивном варианте она должна присутствовать.

Архивное хранение

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

Итак, информация у нас куда-то раз в сутки копируется, там она пожимается архиватором (или наоборот, сначала пожимается, потом складывается). В идеале это второй сервер, настроенный так, что в случае сбоя основного он сможет быстро и легко принять на себя все его функции. Там хранится ежедневный архив к примеру за неделю. Всё это по достижении объёма сменного носителя или чаще копируется на два таких носителя, из которых один убирается в специально отведённый шкаф, а второй отвозится в сейфовую ячейку. И происходит это всё с максимально возможной степенью автоматизации.

Вот тогда системный администратор может особо не переживать за сохранность данных и непрерывность рабочего процесса. А обеспечение этих двух задач является его первейшей служебной обязанностью.

Далее рассмотрим, как ни странно, выстраивание взаимоотношений с руководством и персоналом.

Данный материал можно и нужно критиковать в конференции, НО только предметно и конструктивно. По результатам обсуждения он может быть переработан и дополнен.

Продолжение следует…




29 июля 2007 Г.

2:

1.
2. , ,
-

3. ,

̸


, , .

, , , .

— . . . , — , , , . , , .

, . , , , . , , . , . , .

. — DVD . , , . , , , , , . ( !) , , . , . , ( ) , . , . , . — , . . , . .

— ( , ) , .

-, , . .

, ,

. . , . - . , , . ( ;-) .

, . , , . , .. «-», , - . . , , — .

, , . , , . , . , . , , . , .

,

, - «», , . , , , , . , , , . , , . , . , .

, . , , , . , , . . , , . , , , . , , .

. 5-10 , 80-120 50-100 , . , . . , .

, DVD, , , . , , . , , , . , . , .

. , . . — .

, .

11 2001 WTC — , , , . . — .

, , . — .

UPS . , , . . UPS , .

, . RAID, . , , . , , .

:

  1. RAID 1 (RAID 0 — RAID! ;-)
  2. ,
  3. ( - ) RAID 5 (Hot Spare) , ,
  4. RAID 60
  5. , :-)

. RAID 5 «» ? , RAID 1, «», , . RAID 5 — .

, — .

Near Line Storage

NLS — , . , , . ˸ , — . ˸. , , . , . ( -) , .

( ) , , . . , . , , , () .

, . , , . , ( ) . . . , , . Microsoft , «», . . . , — « » .

— , , , EMC, , .

, , — « », .

, . - , , . , .

, . , , SATA/SAS - , - RAID 5, , . , , , ( SCSI 14 , SATA ). 2-3U, , .

. , (), ( ) , , .

« » , , - .

, , . , . . , , - . , .

, - , ( , , ). , , . . , , . .

. .

, , .

, . .