Эффективное управление хранением данных может оказаться единственным, что защитит вашу компанию от катастрофы.
СЕТЕВЫЕ OC ЗАБОТЯТСЯ О ХРАНЕНИИ ДАННЫХ
Что есть на полке для NT и NetWare
Если бы вы отвечали за хранение данных в офисе, находящемся на двадцать четвертом этаже небоскреба в деловой части Чикаго, то сколько времени вы бы посвятили планированию защиты от наводнения? Не очень-то много, говорите? Подумайте еще раз.
13 апреля 1992 года строительная бригада проделала дыру сквозь дно реки Чикаго в систему туннелей, проходящую под Чикаго. Ворвавшийся в туннели поток затопил трансформаторы, находящиеся в подземельях города; трансформаторы перегорели, прекратив подачу электроэнергии. В конечном итоге все это привело к эвакуации нескольких зданий.
"У компаний было 80 минут на эвакуацию", - вспоминает Джим Гаст, архитектор программного обеспечения в Novell, работавший в то время неподалеку в компании Palindrome, которая разработала одну из первых сетевых систем иерархического хранения данных (HSM).
Ремонт туннелей занял несколько дней. Аварийным командам пришлось откачивать воду из подвалов с осторожностью, иначе здания могли обрушиться. В результате большая часть делового Чикаго была закрыта на две или три недели.
Если бы такое случилось с вашей компанией, как быстро вы смогли бы сделать данные доступными для пользователей? Ответ зависит от того, насколько продумана ваша система хранения данных. Хорошая стратегия хранения данных учитывает множество факторов, влияющих на надежность и производительность сети, включая планирование восстановления после аварий.
ШАГАЯ ВПЕРЕД
Гаст выделяет семь этапов разработки стратегии хранения данных. На практике некоторые этапы будут, скорее всего, выполняться параллельно, а сам семиступенчатый процесс имеет непрерывный характер.
Первым логичным шагом в разработке стратегии хранения данных является исследование имеющейся среды хранения данных. Под управлением какой серверной операционной системы осуществляется хранение критических данных - Unix, NT или NetWare? Есть ли на клиентах - Windows, Mac или Unix - важные данные? Как данные распределены между этими различными средами? Находятся ли критические данные в основном в среде NetWare, а кое-что хранится в Unix, или все обстоит иначе?
При определении местонахождения критических данных компании вы должны также обратить внимание на емкость ресурсов в этих средах. Благодаря такому исследованию вы сможете понять, какие секторы сети располагают в избытке ресурсами для хранения данных, а какие нет. Обратите внимание и на то, насколько хорошо эти секторы оборудованы средствами резервирования, защиты от сбоев и защиты данных.
Следующим шагом, после того как вы получили статическую картину среды хранения данных, будет сбор статистики о том, насколько используются ресурсы хранения данных, насколько хорошо работает система хранения и в каком направлении она развивается. Где наиболее интенсивно потребляются данные? Возможно, тысячи файлов, к которым обращаются крайне редко, хранятся на отказоустойчивых высокопроизводительных серверах. В этом случае естественным решением станет перенос таких файлов на оптическую библиотеку, где стоимость хранения ниже, хотя при этом скорость доступа невысока. Данные, к которым никто не обращался в течение последних четырех недель, лучше хранить в оптической библиотеке, а серверам найти более достойное применение.
Еще одна статистика, которую необходимо собрать, - это рост объема данных. Она пригодится для определения тех мест, где объем данных растет быстрее всего. Например, может оказаться, что, хотя многие данные хранятся на NetWare, накопление данных идет более быстрыми темпами на сервере баз данных под NT и сервере Web под Unix. И несмотря на то, что NT и Unix хранят меньшую часть ваших данных, они могут потребовать особого внимания, как потенциальные кризисные места хранения данных.
Сбор статистики о быстроте предоставления услуг, равно как и о тенденциях изменения производительности, может дать весьма полезные результаты. Проверяя эти цифры, вы можете обнаружить, что в некоторых секторах, например, доступ к данным недопустимо медленный. Или вы можете увидеть, что из-за увеличивающегося числа обращений производительность в скором времени окажется недостаточной.
На этапе исследования и сбора статистики составьте список потенциальных проблем. Этот список станет хорошей исходной точкой для оценки риска, определение которого составляет третий этап в разработке стратегии управления хранением данных. Составив список потенциальных проблем, вы сможете расставить приоритеты, основываясь на возможных последствиях и потерях в случае наступления каждой из них, а затем поочередно заняться решением всех существующих проблем, начиная, разумеется, с наиболее критических.
Предположим, во время вашего исследования вы обнаружили, что сервер Web был изначально сконфигурирован как экспериментальный сервер без обеспечения защиты от сбоев. Теперь же сервер Web стал критическим корпоративным ресурсом. В этом случае его следует поместить в начало вашего списка и убедиться в том, что он может гарантированно работать семь дней в неделю. Если же вы обнаружите, например, группу критических серверов, недостаточно защищенных от взломщиков, то высший приоритет получит проблема защиты этих серверов.
Резервное копирование - основа защиты данных от потерь. Планирование резервного копирования начинается с вопроса, насколько защищенной вы хотите сделать среду хранения данных с учетом того, что безопасность стоит денег. Общепринятым стандартом является копирование каждого файла на два различных комплекта носителей - один должен храниться под рукой для быстрого доступа, а другой - где-нибудь в удаленном хранилище для восстановления после аварий.
Износ резервных носителей также может представлять потенциальную проблему. Не забывайте про средний срок жизни ваших резервных носителей. Данные следует переносить на новые носители задолго до того, как старые носители окажутся опасно изношенными или начнут разрушаться, что сделает невозможным считывание хранящейся на них информации. Время от времени проверяйте носители - вдруг они изнашиваются быстрее, чем ожидалось. Одна компания столкнулась с тем, что файлы невозможно считать с лент всего лишь двухлетней давности. Выяснилось, что уборщица выключала кондиционеры на выходные, в результате ленты размагнитились из-за жары и влажности.
После того как вы обследовали среду хранения данных, оценили ее производительность и определили вероятные проблемы, можно приступать к четвертому этапу - тестированию продуктов, отвечающих вашим требованиям к хранению данных. (Обзор будущих функций управления хранением данных в NT и NetWare см. во врезке "Что есть на полке для NT и NetWare".)
Одним из основных критериев выбора продукта является наличие централизованного администрирования хранением данных. Возможность работать со всеми своими ресурсами хранения данных как с единой системой почти всегда позволяет повысить его эффективность. Например, направление всех серьезных предупредительных и аварийных сообщений на одну точку управления, такую как консоль SNMP, позволит сократить число людей, необходимых для постоянного наблюдения за всеми системами хранения данных. Если, к примеру, диск в массиве RAID, находящемся в удаленном офисе, выйдет из строя, то центральный администратор может сразу же отдать распоряжения об его замене, в то время как местный администратор может не заметить сбоя или не воспримет проблему всерьез, так как она не оказывает немедленного воздействия на работу офиса.
Централизованное управление позволяет также соотносить аварийные сообщения от различных типов сетевого оборудования, что облегчает определение проблем в системе хранения данных на фоне других происшествий в администрируемой сети. Вдобавок центральный администратор может типизировать стандартные ситуации и разработать общесистемную базу знаний. Например, в конце финансового года бухгалтерия регулярно испытывает огромную потребность в дисковом пространстве. В то же время отдел маркетинга работает в "полтора человека" из-за того, что большинство сотрудников принимают участие в ежегодной выставке. Зная эти типичные ситуации, он мог бы так модифицировать работу системы хранения данных, чтобы бухгалтерия одалживала на этот период времени некоторое дисковое пространство у маркетинга.
Однако централизация - далеко не универсальная политика. Скопление всех данных на небольшом количестве серверов может оказаться не лучшей идеей, хотя это, вероятно, уменьшит работу администратора. Например, перемещение файлов NFS с сервера Unix на сервер NetWare или NT означает, что резервному копированию подлежит одной системой меньше и на одну операционную систему меньше придется обслуживать - и то и другое будет явным преимуществом для администратора. Однако вы должны задаться вопросом, в какой мере производительность и защита данных подвергаются риску из-за такой консолидации.
Пятый этап планирования хранения данных состоит в выработке мер по восстановлению после аварии. Определите, какие данные непременно должны быть в порядке для поддержания бизнеса. Например, компании, владеющей несколькими ресторанами, необходимо знать, какие продукты надо грузить в машины каждый день, чтобы рестораны могли работать. А компании рассылки заказов по почте не обойтись без доступа к текущим заказам - без этого клиенты не могут быть уверены в том, что их заказы получены и будут выполнены. Схема восстановления должна учитывать тот факт, что эти данные нужны в первую очередь.
Самого по себе плана недостаточно, вы должны проверить его действенность - этап номер шесть. Если у вас есть резервный центр, временно изолируйте его и убедитесь в том, что он может выполнять ключевые функции полностью самостоятельно. Если вы используете резервные ленты, восстановите записанную информацию в экспериментальной сети. Как много времени это заняло? Предположим, что на восстановление ушло 11 часов, а вы запланировали, что компания должна возобновить деятельность через три часа после катастрофы. Тогда вам надо что-то менять. Все ли ваши приложения работают нормально? Очень часто якобы полные резервные копии на самом деле не содержат таких критически важных компонентов, как файлы .DLL или конфигурационные файлы, находящиеся на рабочих станциях. Убедитесь, что вы на самом деле можете выполнять критические функции, от которых зависит жизнедеятельность компании, - выписывание счетов, например, или выдачу нарядов на погрузку машин.
Седьмой, завершающий этап планирования хранения данных - разработка плана поддержания непрерывности бизнеса. Согласно статистике, после катастрофы бизнес сокращается на 50% только потому, что клиенты предпочитают обратиться к кому-нибудь еще. Планирование непрерывности может включать в себя меры по удержанию клиентов или страхование на случай потери бизнеса при катастрофе.
Многие из описанных задач, такие как контроль производительности системы и сбор статистики о росте объемов данных, должны производиться на постоянной основе. Кроме того, по мере роста компании и ее реорганизации вы должны регулярно проводить проверку принятых мер, поскольку те, что срабатывали несколько месяцев назад, могут отказать завтра.
СУЖАЮЩИЕСЯ ОКНА
Когда дело доходит до резервного копирования и архивирования данных, выбор стратегии определяется двумя факторами: свободное для резервного копирования время ("окно резервирования") и максимально допустимое время восстановления резервных копий файлов.
Самым легким и надежным решением будет резервирование в нерабочие часы, когда сеть не используется и доступ к данным не осуществляется. Причина в том, что резервирование может вызвать замедление работы системы, увеличивая и нагрузку на систему, и сетевой трафик. Так что проведение резервного копирования в рабочее время чревато снижением производительности сети.
Другая причина проведения резервного копирования в нерабочее время в том, что копирование данных, которыми в этот момент пользуются, - дело достаточно рискованное. По соображениям целостности данных, программы резервного копирования обычно предусматривают, что любые транзакции, записанные в файл во время резервного копирования, либо полностью включаются в резервную копию, либо полностью исключаются.
Чтобы этого добиться, программа резервного копирования блокирует каждый копируемый файл, так что никакая другая программа не сможет произвести в него запись во время этого процесса. Но программа резервного копирования не способна заблокировать файл, когда другая программа уже имеет разрешение на запись в него. Многие программы резервного копирования выдают предупредительное сообщение и пропускают этот файл, если они не могут гарантировать его беспроблемного копирования.
Однако в сегодняшней производственной среде резервное копирование данных во внерабочее время - непростая задача. К несчастью, компьютерные системы компаний все чаще продолжают использоваться и по окончании рабочего дня. Виной тому и пользователи, работающие на дому, и мобильные пользователи, и пользователи, находящиеся в другой временной зоне. В то же время объем данных, подлежащих резервному копированию, продолжает расти. Соответственно, окно резервирования сузилось до такой степени, что многие устройства резервного копирования не в состоянии справиться со стоящей перед ними задачей.
Если окно резервирования сузилось (но не исчезло), наиболее очевидным решением будет применение более быстрого устройства резервного копирования. Выбор достаточно широк, а с учетом новых разработок он может просто привести в замешательство. Исторически 8-миллиметровые накопители Exabyte обеспечивают самые быстрые решения резервного копирования, но и стоят они дороже. Если вы готовы удовлетвориться меньшей скоростью, то 4-миллиметровые устройства DAT имеют неплохое соотношение цена/производительность.
Пока на рынке эти типы устройств продолжают оставаться наиболее популярными, однако в 1995 году Quantum предложила новый полудюймовый формат: DLT (Digital Linear Tape). DLT напрямую конкурирует с 8-миллиметровыми решениями по скорости и максимальной емкости. Вдобавок ленты DLT физически надежнее DAT или 8-миллиметровой ленты.
По словам Джима Хэмилтона, аналитика из консалтинговой фирмы Freeman Associates, специализирующейся на средствах хранения данных, обороты продаж DLT вырастут в 1997 году на 50-60% по сравнению с 1996 годом. Он также подчеркнул, что с 1995 по 1997 годы обороты продаж DLT приблизительно удвоились.
Однако ленточные технологии имеют одну скрытую проблему: нехватка высококачественных носителей. "Носители DLT, например, - говорит аналитик-исследователь консалтинговой фирмы Gartner Group Патриция Адамс, - производятся в недостаточном количестве".
В апреле 1996 года Sony анонсировала ленточные устройства серии SDX, основанные на технологии AIT (Advanced Intelligent Tape), 8-миллиметровой технологии с иным, чем у Exabyte, форматом. По сравнению с Exabyte SDХ имеет некоторые технические преимущества, например возможность большее число раз использовать одну и ту же ленту и применять устройства половинной высоты.
Есть еще одно решение нестандартного формата на основе 8-миллиметровой ленты - ленточная подсистема IBM MagStar MP (Multi Purpose), представленная в конце 1996 года. Однако, по словам Хэмилтона, MagStar до сих пор продается в основном преданным пользователям IBM, в частности пользователям AIX.
Среди новых продуктов один объявлен в марте этого года компанией Storage Technology и Imation, дочерней компанией 3М. Новый продукт под кодовым названием Eagle, появление которого ожидается в начале 1998 года, рекламируется под лозунгом обеспечения производительности и надежности мэйнфреймов в мире Windows NT и Unix.
Хотя к настоящему времени Storage Technology не предоставила никакой технической информации, согласно различным источникам, Eagle может обеспечить скорость передачи вдвое большую, нежели DLT. "Каждые 10 лет отрасль проходит через смену ленточных технологий, и, по крайней мере на бумаге, таковой является Eagle", - говорит Ник Аллен, вице-президент и руководитель исследований в Gartner Group.
Помимо выбора ленточной технологии вам, возможно, имеет смысл присмотреться к ленточным библиотекам или устройствам хранения данных на нескольких лентах. Большее количество лент дает большую общую емкость. Некоторые ленточные библиотеки содержат несколько накопителей (в том числе разных типов), способных работать параллельно, обеспечивая тем самым большую пропускную способность, чем любое одиночное устройство. Вы можете найти библиотеки, которые поддерживают 8-миллиметровые, 4-миллиметровые и DAT-технологии.
Одна из тенденций в технологии ленточных библиотек заключается в том, что эти продукты, изначально разработанные для централизованных сред, теперь адаптируются к потребностям сетевых серверов NT и Unix. Например, библиотека StorageTek TimberWolf 9740 предназначена для применения в офисе и поддерживает DLT вдобавок к полудюймовым форматам, таким как 3480 и 3490 (StorageTek, подразделение Storage Technology, традиционно предлагает библиотеки для центров обработки данных).
При выборе ленточной библиотеки ее общую производительность следует подбирать с учетом окна резервирования. Полная емкость библиотеки (количество слотов, умноженное на емкость одной ленты) должна соответствовать общей емкости, необходимой для HSM или резервного копирования. Кроме того, решение должно учитывать возможность расширения и стоимость наряду с соображениями надежности и поддержки.
С ПРОГРАММНОЙ СТОРОНЫ
Куда важнее оборудования для резервного копирования специальное ПО, поскольку оно обеспечивает пользовательский интерфейс для управления процессом резервного копирования, позволяя создавать расписание процедуры копирования, выделять квоты для пользователей, устанавливать ограничения для времени хранения данных на носителе и т. д. Программы резервного копирования включают в себя и драйверы для конкретных устройств (таких как стримеры и ленточные библиотеки) и под конкретные ОС и сетевые ОС.
Помимо поддержки нужных стримеров, библиотек и серверных операционных систем программа резервного копирования должна иметь агенты для конкретных клиентских мест, информацию с которых вы хотите копировать, а также агенты для баз данных и почтовых систем. Было бы хорошо, если бы программа имела антивирусных и "ускоряющих" агентов, управляющих взаимодействием клиента с сервером резервного копирования.
Другая, весьма желательная, характеристика - чередующие клиентские агенты, которые позволяют производить копирование более одного клиентского места за раз. Программа резервного копирования, имеющая чередующих клиентских агентов, мультиплексирует данные от нескольких клиентов в единый поток, повышая общую производительность.
Чтобы справиться с проблемой открытых файлов, исключаемых обычно из процесса копирования, некоторые программы резервного копирования или их расширения могут эффективно копировать открытые файлы и создавать копию, не мешая проводимым над оригиналом операциям. Вы можете занести эту характеристику в свой список.
Еще одно различие заключается в том, копируют ли программы образ всего диска или производят пофайловое копирование. Программы копирования образа записывают том побитно, пофайловые программы копируют данные файлами. Последние работают на уровне ОС, в то время как первые - на уровне дискового интерфейса. Из-за того, что они работают на уровне операционной системы, программы пофайлового резервного копирования в целом медленнее своих "образных" соперников.
Традиционно копирование образов не так гибко, как копирование файлов, поскольку в этом случае восстанавливать придется весь том (включая местоположение плохих блоков на копируемом диске!), даже если вы хотите восстановить всего один файл. Кроме того, такое восстановление возможно обычно только на машине, идентичной оригинальной.
Однако многие из сегодняшних продуктов копирования образов способны производить пофайловое восстановление, потому что данный процесс осуществляется на более высоком интеллектуальном уровне, чем процесс копирования (в частности, последний, в отличие от первого, не воспринимает каталоги). Резервную ленту можно смонтировать в качестве диска, считать каталог с ленты и ограничиться при резервировании нужными файлами.
Инкрементное пофайловое копирование может оказаться быстрее копирования образов, когда большие файлы или большое количество файлов меняются не часто. В этом случае вы просто копируете изменившиеся файлы вместо всего тома, значительно сокращая тем самым объем копируемых данных. Это также позволяет вам эффективно организовать процесс копирования, запланировав, например, инкрементное копирование на рабочие дни и полное копирование на выходные.
ПО резервного копирования может отслеживать, какие файлы на каких ленточных накопителях находятся. Некоторые программные продукты управляют и последовательностью ротации лент, что гарантирует вам наличие необходимого количества копий каждого файла за определенный период времени.
ПОДВЕДЕНИЕ БАЛАНСА
Хотя истории вроде наводнения 1992 г. в Чикаго могут сделать процесс управления хранением данных весьма захватывающим, обычно он немногим интересней, чем уплата страховых взносов, но также необходим. Весь фокус в том, как определить нужный именно вам тип страховки и что вы можете себе позволить.
Цель заключается в нахождении приемлемого уровня защиты, реализация которого позволит увеличить продуктивность (избавляя от необходимости переделывать работу, например, при потере файла) и избежать участи тех 50% компаний, чья деятельность прекращается из-за потери большей части данных.
Майк Гурвиц - независимый автор и консультант. С ним можно связаться по адресу: mhurwitz@attmail.com.
СЕТЕВЫЕ OC ЗАБОТЯТСЯ О ХРАНЕНИИ ДАННЫХ
Что есть на полке для NT и NetWare
В своем продолжающемся споре за первенство и Novell и Microsoft планируют включить тиражирование данных и другие возможности управления хранением данных в грядущие версии сетевой ОС. Например, Microsoft представила Microsoft Distributed File System (DFS) для NT 4.0. По заявлениям компании, надмножество этих функций будет включено в NT 5.0.
DFS включает ряд функций защиты от сбоев в файловую систему, увеличивая заодно производительность системы. Например, в DFS вы можете создать несколько копий общего каталога, доступного только на чтение. Таким образом, пользователи могут получить доступ к любой копии разделяемого каталога, а это позволяет равномерно распределить нагрузку на сервер и увеличить производительность. Если одна из копий по какой-либо причине становится недоступна, запросы на доступ к этому ресурсу автоматически перенаправляются к другой копии.
Другие планируемые функции - встроенные возможности иерархического хранения данных (HSM); индексирование как содержимого, так и свойств файлов, благодаря чему поиск нужного файла намного облегчается, и задание квот на использование диска, предотвращающее засорение пользователями дискового пространства.
Когда Active Directory - глобальная служба каталогов, обещанная Microsoft, - появится в NT 5.0, она будет работать с информацией DFS. В свою очередь DFS будет использовать информацию службы каталогов для интеллектуального выбора реплик. Active Directory предназначается также для укрепления защиты от сбоев за счет хранения и тиражирования информации о структуре DFS.
В настоящее время Novell предлагает службу Novell Replication Service, поддерживающую пофайловое копирование в средах NetWare и IntranetWare. Между тем Novell работает над усовершенствованием службы Novell Storage Services (NSS) и преобразованием ее в инфраструктуру распределенной файловой системы в NetWare и IntranetWare.
По словам архитектора программного обеспечения Novell Джима Гаста, продукт будет обеспечивать автоматическое прозрачное перенаправление к реплике, если основные данные станут недоступны. Эта версия NSS под кодовым названием NSS(D) будет также содержать новую систему HSM, так что редко используемые копии будут перемещаться на более дешевые носители.
Согласно официальной информации, будущие версии включат в себя распределенную файловую систему, поддерживающую виртуальные тома. Файловая система под кодовым именем NSS(V) должна увеличить эффективность системы HSM за счет поблочной, а не пофайловой миграции данных. NSS(V) позволит вам открыть файл в том виде, в каком он был в конкретный момент времени в прошлом.