Архив

Публикации с меткой ‘Хранение данных’

Выбраковка жестких дисков как способ избежать потери данных

28 апреля 2010

Новые технологии как новая обувь: требуют себя обкатать, "разносить". Особенно хорошо это проявляется в случае с системами хранения данных, в частности, с жесткими дисками. HDD — тот компонент системы, с которым я во все времена общался на "Вы". Когда существующие объемы дисковых хранилищ переставали удовлетворять мои потребности, я не спешил приобретать новые, топовые, максимально вместительные диски, а следовал правилу "шаг назад — два вперед". В основе этого принципа лежит учеба на чужих ошибках.

Когда-то жесткий диск объемом 80 Гбайт считался очень большим. Высокого качества DVD-рипы редко занимали объем больше 700 Мбайт, а значит 80-Гбайтного диска хватило бы на сотню таких рипов. Потом технологии изготовления HDD резко пошли вперед. Появились диски на 160 Гбайт, чуть погодя на 250, еще чуть позже — на 320. За ними 400, 500, 750, 1 Тб, 1.5 Тб, 2 Тб… И все это в крошечный промежуток времени, всего 2-3 года. Однако технология хранения данных принципиально не менялась, росла лишь плотность записи (байт на кв. мм). И чем она была выше, тем менее надежным и отказоустойчивым становился жесткий диск.

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

hdd-01

Теперь впишите в одну строку текст с высотой в половину клеточки в 2 ряда. Чтение уже затруднительно.

hdd-02

Впишите текст в треть клеточки в 3 ряда. Прочесть становится очень сложно.

hdd-03

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

Поэтому 4 года назад нужду в 160-Гбайтном увеличении дискового пространства я решал покупкой 2 HDD на 80 Гбайт. Когда топами стали 250, я перешел на 160-Гбайтники. За время смены "объемопоколений" жестких дисков собиралась статистика отказов старших моделей, технологии обкатывались, и каждый вендор успевал менять/добавлять линейку дисков. Скажем, серию AS у Seagate дополнила сперва серия ES, а к ней позже добавилась еще и ES.2. Стоит ли говорить, что моим первым 250-Гбайтным диском стал ES, когда уже вовсю продавались AS’ы на 500 Гбайт?…
Отсюда результат: меня не тронула повальная смертность в конце 90-х — начале 2000-х винчестеров Fujitsu (которые в то время были очень популярны за счет дешевизны и доступности), я только слышал об эпидемии отказов IBM DTLA, меня не накрыли ужасы кривой прошивки Seagate’ов годовалой давности, хотя их у меня в эксплуатации… хм, пара сотен.

 

Есть и еще одно правило, соблюдение которого помогает мне обеспечить сохранность данных: не доверять жестким дискам, находящимся в эксплуатации менее 6 месяцев, важную информацию. Буквально это значит следующее. Сейчас на рынке распространены HDD объемом 2 Тбайт. Помня о правиле #1, я покупаю только 1-Гбайтные диски. Однако, едва их купив, я не бросаюсь сломя голову переносить на них слепок из моих важнейших данных, а ставлю в систему в качестве временных хранилищ и обязательно под высокой нагрузкой. Если жесткий диск выдержал 6 месяцев активной эксплуатации, то он может быть переведен в разряд надежных и ему можно доверить что-то действительно важное. Кстати говоря, по статистике, которую собирает Google в своих датацентрах, наибольшее число отказов приходится именно на новые, 1-3-месячные жесткие диски.

Таким образом осуществляется выбраковка по двум критериям:
1) статистические данные об отказах данных модели/линейки/ряда определенного вендора (которые собираются другими пользователями, купившими новые жесткие диски раньше меня);
2) отсутствие врожденных или приобретенных в ходе транспортировки и/или неправильной эксплуатации дефектов, приводящих к скорому отказу.

Что мы имеем в результате? Лишний редут защиты информации. Он не отменяет прочие правила хранения данных, такие как RAID-массивы, резервное копирование, правильную эксплуатацию, но неплохо дополняет их.

Default ,

PST’ц.

21 марта 2010

По статистике, самая популярная программа для работы с электронной почтой — это MS Outlook. Хорошо, когда пользователи используют Outlook только как интерфейс для работы с почтой, хранящейся на сервере Exchange (то бишь подключаются через MAPI). И плохо, когда Outlook выступает в роли POP3-загрузчика и хранилища данных. Oulook хранит почтовые сообщения в собственном формате, в PST-файле. Механизм хранения данных в PST несовершенен, и его использование — это своего рода гарант возникновения проблем.

Целостность PST-файлов часто нарушается, особенно если речь идет о больших файлах (от 1 Гбайт). Достаточно случайного выключения компьютера во время сеанса загрузки Outlook’ом почты. Если такое произойдет, то испорченный PST-файл не всегда удается восстановить даже с помощью специализированных утилит. Частичная потеря данных практически неизбежна.

PST-файлы, мало того, что ненадежны, так еще и небезопасны. Большинство антивирусов не могут удалять вредоносное ПО из PST-файлов. Некоторые могут, но их неделикатный способ обращения с файлом также может привести к нарушению его целостности. Хищение PST-файлов — тоже не редкость. Благо, для его копирования на съемный носитель не нужно знать пароль от учетной записи пользователя на почтовом сервере, достаточно получить доступ к вашему компьютеру. PST можно импортировать в Outlook на другой компьютер, и вся хранившаяся в нем переписка предстанет как на ладони.

Запоминаем: PST — это плохо!

Default ,

Создание отказоустойчивого корпоративного файл-сервера на базе DFS

13 февраля 2010

В большинстве организаций, даже прошедших путь оптимизации бизнес-процессов и автоматизации документооборота, до сих пор активно используются файловые серверы, служащие хранилищами важной корпоративной информации. Системный администратор, ответственный за сохранность данных на файл-серверах, должен позаботиться не только о развертывании надежной системы резервного копирования, но и о максимальном сокращении времени простоев. Я рассмотрю самый что ни на есть частный случай: организацию, размещенную в разных корпусах гипотетического делового центра, с сетью филиалов.

Итак, исходные данные: головной офис с размещением сотрудников в двух разных корпусах, один филиал. Файл-серверы установлены в обоих корпусах головного офиса и в филиале. Между корпусами лежит оптика, с филиалом установлен VPN-канал из первого корпуса головного офиса.

Задача: обеспечить гипотетическому сотруднику максимальную доступность данных вне зависимости от его местонахождения.

Для решения данной задачи мы будем использовать технологию компании Microsoft, метко названную Distributed File System (DFS). DFS была разработана для упрощения доступа к данным и управления ими. В Windows Server 2003 R2 к ней был добавлен механизм репликации, получивший вполне прогнозируемое название DFSR (Distributed File System Replication). Если вкратце описать схему работы DFS, то это будет выглядеть примерно так:

dfs-schema

На рисунке условно изображены 3 файл-сервера, каждый из которых служит хранилищем разных общих директорий. Сервер DFS образует корень из этих директорий и открывает к ним общий доступ под именем Summary Data. Клиенты, в свою очередь, имея необходимость использовать данные со всех трех серверов, обращаются только к DFS, который обеспечивает им централизованный доступ к нужным ресурсам. Вполне логично: ни к чему пользователю помнить UNC-пути к отдельно взятым файл-серверам, он должен везде и всегда иметь привычную, удобную рабочую среду.

Вернемся к нашей задаче. Пока наша схема сети выглядит примерно так:

start-schema

Для наведения порядка в этом бедламе нам потребуется установить службы DFS на серверах. В Windows 2003 это делается через оснастку Add/Remove Windows Components:

dfs-01

В Windows 2008 – через мастер добавления ролей:

dfs-02

После установки служб DFS, запускаем оснастку Distributed File System. Она работает в стандартной среде MMC, слева в меню жмем правой кнопкой мыши (далее – ПКМ) единственный пункт и выбираем New Root. Запустится мастер настройки корня DFS. Он может быть доменным, либо изолированным:

dfs-03

Выбираем доменный, после чего выбираем домен, в котором будет размещено дерево логических имен DFS:

dfs-04

После этого нам останется только выбрать сервер, на котором будет размещен корень…

dfs-05

…и мы приступим непосредственно к его созданию:

dfs-06

Свой корень я назову Corporate FS (сокращение от Corporate File Server) и помещу его в директорию C:Corporate FS

dfs-07

Корень готов. Приступим к присоединению к нему файл-серверов и установке реплик. На корневом DFS-сервере я создал на диске C: общую директорию Main Office Documents с данными, на сервере SRV2 – такую же, но пустую, и на сервере SRV3 директорию Branch Office Documents, тоже с данными.

Теперь жмем на наш корень ПКМ и выбираем New Link. Первым линком будет наш общий ресурс Main Office Documents:

dfs-08

Аналогично добавляем \Srv3Branch Office Documents. В конце концов мы получаем следующую DFS-структуру:

dfs-09

Чуть позже мы ее протестируем. Но пока мы еще не решили задачу резервирования данных. Я продемонстрирую простейшую схему репликации: данные из общей папки с SRV1 будут копироваться на SRV2. Полную репликацию всех сетевых ресурсов и корня DFS рассматривать не будем, так как настраивается она аналогичным образом. Одного примера будет вполне достаточно.

Жмем ПКМ на линк Main Office Documents и выбираем New Target. В появшившемся диалоговом окне выбираем сетевой ресурс с таким же именем на SRV2, ставим галочку в чекбоксе Add this target to the replication set и жмем Ок:

dfs-10

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

dfs-11

Оставляем по умолчанию и жмем Next. На следующем шаге нам будет предложено выбрать топологию репликации. Вариантов всего 4:

Ring (кольцо) – реплика будет обмениваться информацией с двумя соседними;

Hub and spoke (звезда) — выделяется основная реплика, с которой обмениваются информацией все остальные;

Full mesh (полносвязная сеть) — все реплики обмениваются информацией друг с другом;

Custom (пользовательская) – каждая пара реплик настраивается вручную.

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

dfs-12

 

Для наглядной проверки репликации я создал на сервере SRV1 в C:Main Office Documents несколько папок и файлов:

dfs-13

По умолчанию репликация происходит раз в 15 минут. По прошествии этого времени данные благополучно появились без моего вмешательства и на SRV2:

dfs-14

Можно выполнить принудительную репликацию командой:

ntfrsutl poll /now ИМЯ-РЕПЛИЦИРУЕМОГО-СЕРВЕРА

Осталось опубликовать DFS в Active Directory и протестировать его доступность. Для публикации кликаем ПКМ по корню DFS, выбираем Properties и в открывшемся окне переходим на вкладку Publish:

dfs-15

Обратите внимание: так как наш корень DFS доменный, а не изолированный, при обращении к нему может использоваться конструкция UNC только с названием домена, без уточнения имени сервера. Кстати говоря, DFS с точки зрения клиентской ОС – не более чем обычная общая папка, то есть доступна по UNC и может быть подмонтирована как сетевой диск. Нажимаем Ок.

В качестве тестера может выступить любой доменный клиент. Я воспользуюсь сервером SRV3:

dfs-16

 

dfs-17

В корне Corporate FS, как и предполагалось, ссылки на файл-серверы головного офиса и филиала. Впрочем, по ссылкам мы попадаем туда же, куда и задумывали. Система работает, алиллуйя.

Итак, что же дает нам DFS?

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

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

3. Балансировку нагрузки. В основном, на сетевые интерфейсы.

4. Прозрачность соответствия логического представления данных и их физического расположения. Сотрудник из офиса деревни Ольховка Кировской области может работать с файл-сервером, расположенном на Барбадосе, также, как если бы он стоял у него в соседнем кабинете. Впрочем, сотрудник наверняка и так в этом будет уверен, глядя на DFS.

Айс, не правда ли?

Default , , , ,

Настройка объема дискового пространства в Windows Vista для хранения точек восстановления системы

20 апреля 2009

Волею Microsoft, в Vista отсутствуют графические средства для настройки службы восстановления системы. Особенно неприятно то, что нельзя очевидными методами настроить объем дискового пространства для хранения точек восстановления системы. А они имеют свойство плодиться и разбухать, пожирая столь ценные гигабайты, которые можно было бы отвести под хранение другой, полезной с точки зрения пользователя, информации. Однако существует средство командной строки, позволяющее довольно гибко манипулировать со службой восстановления, — Утилита теневого копирования тома. Вызов справки по ней осуществляется командой:

vssadmin

Справка поведает вам, как управлять теневым копированием. Рассмотрим конкретный, типовой пример. Итак, перед нами стоит задача отвести под резервные копии тома C: 20 гигабайт и хранить их на томе D:. Для решения такой задачи служит команда:

vssadmin resize shadowstorage /for=c: /on=d: /maxsize=20GB

Параметры и их значения вопросов не вызывают: resize shadowstorage переназначает объем дискового пространства для резервных копий, for определяет том, копии которого будем создавать, on назначает том для хранения резервных копий, maxsize — это максимальный объем для всех резервных копий. maxsize не может быть меньше 300 Мбайт, значение этого параметра может иметь суффиксы KB, MB, GB, TB и т. д.

Default , ,

Тестируем жесткие диски

18 апреля 2009

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

Регулярные медосмотры можно проводить с помощью замечательной утилиты, написанной программистами из Японии, — CrystalDiskInfo. Она умеет делиться с пользователем подробной статистикой по времени работы диска, числом включений/выключений, показаниями температурных датчиков, информацией о версии прошивки и пр. В случае, если показания S.M.A.R.T. заставляют ее насторожиться, программа сразу выдает пользователю уведомление о том, что жесткий диск уже не столь хорош, как раньше (естественно, указывается причина), и, возможно, требует замены.

На скриншоте сразу на 3 дисках из 4 были обнаружены переназначенные сектора (это нечитаемые/незаписываемые сектора, которые система помечает как сбойные, и им на замену назначает некоторый объем памяти из буфера. Их большое количество — верный признак того, что HDD пора менять).CrystalDiskInfo 2.5

CrystalDiskInfo абсолютно бесплатна и не требует установки. Скачать ее можно здесь.

Default , , ,

Монтируем VHD в Windows Server 2008 R2 / Windows 7

17 апреля 2009

Похоже, Microsoft всерьез взялась за виртуализацию. Чем еще объяснить тот факт, что в последних ОС линейки Windows появилась возможность интеграции VHD в дисковую подсистему ОС?

Для монтирования виртуального диска необходимо войти в оснастку Computer Management, в меню слева развернуть список Storage, кликнуть правой кнопкой мыши на Disk Management и выполнить команду Attach VHD. В открывшемся диалоговом окне необходимо указать файл, в котором хранится VHD и нажать ОК. Подмонтированный диск тут же станет виден в оснастке Disk Management. Выполнением команды Detach VHD от диска можно будет избавиться.

 Между прочим, эта приятная мелочь способна серьезно облегчить жизнь системному администратору.

Default , ,

Конвертация FAT32 в NTFS без потери данных

17 апреля 2009

Процедура многократно испытывалась под Windows XP. Выполняем команду

C:> convert X: /fs:ntfs

где X: — имя диска.

Default ,

Как максимально продлить срок службы жесткого диска

17 апреля 2009

Для этого необходимо придерживаться некоторых несложных правил эксплуатации:

1. Обеспечить качественное питание. То есть установить достаточно мощный блок питания надежного производителя.
2. Обеспечить хороший контакт с питающим шнуром как жесткого диска, так и материнской платы.
3. Обеспечить стабильный температурный режим. Возможно, установить дополнительное охлаждение.
4. Использовать качественные шлейфы без лишних изгибов и скруток.
5. Обеспечить отсутствие источников вибраций вблизи от устройства.
6. Воздержаться от частых демонтажа и переноски устройства.
7. Обеспечить отсутствие частых включений/выключений питания диска.

Default

Почему реальный объем жесткого диска меньше заявленного производителем?

17 апреля 2009

Потому что маркетологи указывают объем HDD, исходя из того, что в 1-м гигабайте 1000 мегабайт, в то время как там их аж 1024.

Default , ,