|
Хранение информации — это процесс поддержания исходной информации в виде, обеспечивающем выдачу данных но запросам конечных пользователей в установленные сроки. Процесс храпе¬ния связан с необходимостью накопления и долговременного хра¬нения данных, необходимостью комплектации первичных данных до их обработки, обеспечением их актуальности, целостности безопасности, доступности. Хранение информации осуществляется на машинных носителях в виде информационным массивов, где данные располагаются по установленному в процессе проектирования группировочному признаку. Хранение информации в на¬стоящее время реализуется при использовании концепций базы данных и хранилища данных (ХД).
База данных представляет собой совокупность взаимосвязанных данных, используемых несколькими пользователями и храня¬щихся с регулируемой избыточностью. Хранимые данные не за¬висят от программ пользователей, а для их модификации приме¬няется общий управляющий метод реализуемый системой управления базой данных на основании запросов пользователей. База данных вместе с СУБД образуют так называемый банк дан¬ных. В содержательном плане банк данных — это система, пред¬ставляющая определенные услуги по хранению и поиску данных определенной группе пользователей по определенной тематике.
Хранилище данных — это база, хранящая данные, агрегирован¬ные по многим измерениям.
Наряду с термином «хранилище данных» используют также равноценные термины: Dala Warehouse, «склад данных». «инфор¬мационное хранилище». Основное отличие ХД от БД — агрегиро¬вание данных. Данные из ХД никогда не удаляются, а его пополнение происходит путем формирования новых агрегатов данных зависящих от старых. Доступ к ХД осуществляется на основе многомерного куба или гиперкуба, координаты осей которого являются по сути индексами, указывающими точное положение информации в хранилище.
Любая современная СУБД предоставляет пользователю средства резервного копирования, позволяющие восстанавливать базу данных в случае ее разрушения. Резервное копирование — периодически выполняемая процедура получения копии базы данных и ее файла журнала (а также, возможно, программ) на носителе, хранящемся отдельно от системы. Обычно резервные копии базы данных (и ее файла журнала) создаются с некоторой установленной периодичностью в местах, обеспеченных необходимой защитой. В случае аварийного отказа резервная копия и зафиксированная в файле журнала оперативная информация используются для восстановления базы данных до последнего согласованного состояния [44, 8].
Процедура создания и обслуживания файла журнала, содержащего сведения обо всех изменениях, внесенных в базу данных с момента создания последней резервной копий, и предназначенного для обеспечения эффективного восстановления системы в случае ее отказа, называется процедурой ведения системного журнала БД. Средства оперативного обслуживания системного журнала также предоставляет СУБД пользователю. Если в отказавшей системе функция ведения системного журнала не использовалась, то базу данных можно будет восстановить только до того состояния, которое было зафиксировано в последней созданной резервной копии. Все изменения, внесенные в базу данных после создания последней резервной копии, будут потеряны.
Основной проблемой восстановления работоспособности ЛВС после отказа является восстановление хранимых данных. Отказ многих аппаратных компонентов ЛВС (процессора, памяти, контроллеров, внешних устройств, телекоммуникационного оборудования и самой сетей передачи данных), как правило, нарушает целостность хранимых данных. Поэтому подготовка к восстановлению данных является важнейшим элементом планов работ по восстановлению работоспособности ИС. Такая подготовка включает в себя:
• изготовление резервных копий данных (резервное копирование);
• тренировки персонала по восстановлению данных;
• хранение резервных копий.
Резервное копирование следует осуществлять настолько часто, насколько допустима потеря части данных после их восстановления из последней резервной копии; например, если резервное копирование осуществляется один раз в сутки, то средний потерянный объем изменений данных — это изменения, сделанные за 12 ч работы ИС, а в худшем варианте — за все 24 ч. Резервное копирование может быть длительным процессом. Во время изготовления резервной копии работать с БД нельзя. Поэтому для резервного копирования следует принимать все возможные меры, снижающие время изготовления копии:
а) уменьшать объем копируемых данных;
б) повышать производительность оборудования, на котором изготавливаются копии;
в) использовать ПО, которое позволяет изменять данные, не затрагивающие целостность резервной копии (например, уже полностью скопированные).
Тренировки персонала должны быть регулярными, обеспечивающими автоматизацию навыков администраторов по восстановлению данных. Дело в том, что восстановление данных может занимать часы и требовать от администратора действий, выполняемых в строго определенной последовательности. Нарушение такой последовательности может приводить к повторению процедуры восстановления с ее начала, снова вызывая простой ИС.
Хранение резервных копий зависит от вида носителей. Например, магнитные носители следует хранить в размагниченном металлическом сейфе (шкафу), а оптические диски можно хранить в любом непрозрачном контейнере. При использовании трех копий еще одна копия хранится в том же здании, где будет происходить восстановление данных, но в помещении, отдаленном от того помещения, где эксплуатируется ИС. На любых носителях обычно изготавливаются не менее двух резервных копий (как правило, три), одна из которых хранится в помещении, в котором предстоит восстановление данных, а другая — в другом здании, желательно не ближе 10... 15 км (на случай стихийного бедствия или теракта).
До недавнего времени хранение данных было лишь малой частью компьютерной инфраструктуры на предприятиях. По мере роста объемов и ценности увеличивалась и значимость данных, а их хранение стало одной из важнейших составляющих современного центра обработки данных. Если в самом начале XXI в. объемы средств, вкладываемых в системы хранения данных, примерно соответствовали объемам средств, тратившихся на сами серверы, то в настоящее время объем средств, вкладываемых в системы хранения данных, существенно превысил аналогичный объем для серверов (примерно 15% против 85%). Правда, теперь к стоимости самого оборудования прибавляется стоимость средств для управления данными.
Можно сказать, что хранение данных стало ключевым ресурсом современных информационных технологий, и важность этого ресурса постоянно растет.
Фундаментальные правила резервного копирования данных.
Резервное копирование, в отличие от других видов копирования данных (зеркалирование, снэпшоты и репликация данных), является стратегическим компонентом защиты данных [8]. Поэтому независимо от используемой технологии резервного копирования необходимо придерживаться определенных правил, выполнение которых облегчает проведение резервного копирования, причем, как показывает практика, соблюдать их требуется неукоснительно и комплексно. Это позволит выполнять резервное копирование без каких-либо затруднений, укладываясь в выделенное временное окно. Итак, при организации и (или) оптимизации существующей системы резервного копирования необходимо соблюдать следующие правила:
1. Предварительное планирование. Все компоненты инфраструктуры резервного копирования должны учитываться в процессе планирования, а все приложения, серверы и тенденции увеличения емкости первичных хранилищ данных не должны оставаться без внимания. Правильное планирование позволяет составить более полное представление о потребностях и особенностях работы приложений с точки зрения защиты данных. Приложения баз данных, где присутствуют разделенные «зеркала» (копии данных на других компьютерах) и приложения, работающие в файловой среде, в которой нет дополнительной защиты данных, требуют разных стратегий и подходов к резервному копированию. Аналогично большое корпоративное приложение, развернутое на нескольких серверах и предполагающее сложную взаимозависимость данных для обеспечения последующего восстановления, будет требовать соответствующей синхронизации резервного копирования [62].
2. Установление жизненного цикла и календаря операций. Эффективная работа системы резервного копирования требует ежедневного выполнения определенных заданий. Однако есть не менее важные задания, которые выполняются еженедельно, ежемесячно, ежеквартально и ежегодно. Задания с коротким циклом большей степени являются тактическими, а задания с большим циклом — стратегическими. В среде эффективного резервного копирования все задания должны быть задокументированы и выполняться согласно расписанию, причем ежедневно должны решаться следующие задачи:
• мониторинг заданий и отчеты о сбоях и успешном выполнении;
• анализ и разрешение проблем;
• манипуляции с лентами и управление библиотекой;
• расписание выполнения заданий.
Еженедельные и ежемесячные задания включают в себя:
• анализ производительности;
• тенденции изменения объемов и планирование этих изменений;
• рассмотрение и анализ методики резервного копирования;
• проверку возможности восстановления;
• планирование развития архитектуры.
Документируя эти задания, необходимо убедиться, что они выполняются в полном соответствии с расписанием.
3. Ежедневный обзор логов процесса резервного копирования. Это необходимая ежедневная задача. Затраченное на это время, в конечном счете, приведет к надежно работающей системе резервного копирования. Проблемы при резервном копировании, как правило, возникают лавинообразно. Один-единственный сбой может повлечь за собой целую последовательность, на первый взгляд, даже не связанных между собой событий. Например, задание резервного копирования может либо «зависнуть», либо не запуститься из-за того, что нужный привод магнитных лент не был освобожден предыдущим заданием. Это предшествующее задание сохраняло сервер приложений, на котором одновременно шел незапланированный ресурсоемкий процесс. Выполнение данного процесса не позволило закончить резервное копирование в установленный расписанием срок. Ответственный системный администратор своевременно не информировал администратора резервного копирования, чтобы он мог внести соответствующие изменения в расписание процессов. Для того чтобы определить, является ли некоторое состояние причиной или следствием чего-то другого, может потребоваться немало опыта и усилий, а сам процесс будет напоминать детективное расследование. Естественно, для успешного решения возникающих проблем необходима согласованная работа системных, сетевых администраторов и администраторов баз данных.
4. Защита базы данных резервного копирования или каталога. Все приложения резервного копирования ведут свою базу данных или каталог, необходимые для последующего восстановления сохраненных данных. Ясно, что потеря каталога влечет за собой потерю сохраненных данных. Хотя некоторые приложения резервного копирования имеют механизмы корректного чтения лент и индексов, для восстановления этого может оказаться недостаточно. Более того, каталог должен рассматриваться как критически важное приложение баз данных. Желательно иметь его зеркальную копию или, по крайней мере, хранить в RAID-системе (Redundant Array of Intelligent/Independent Drives). RAID-системы автоматически дублируют все хранящиеся данные и ведут мониторинг локальных сбоев, что делает систему более устойчивой. Кроме того, желательно убедиться в том, что каталог сохраняется согласно расписанию и без ошибок.
5. Ежедневное определение временного окна резервного копирования. Ошибки, связанные с временным окном резервного копирования, не оставляют соответствующих сообщений в отчетах, так как на самом деле это нормальный и успешно завершившийся процесс резервного копирования. Поэтому часто проблема остается незамеченной. Если задания начинают приближаться или выходить за пределы отведенного временного окна, это является признаком приближения к предельной емкости системы или наличия «узких мест» в производительности. Своевременное обнаружение таких признаков может избавить от последующих более крупных сбоев системы.
6. Локализация и сохранение «внешних» систем и томов. ПО резервного копирования предоставляет отчеты о ежедневных сессиях резервного копирования, куда включается информация только об известных ему серверах. Рассматривать только их и полагаться только на них рискованно. «Внешние» (например, купленные) системы, которые участвуют в работе, но не включены в схему резервного копирования, оказываются вне поля зрения ИТ-подразделения и некоторое время могут работать с собственным резервным копированием. Но рано или поздно возможен сбой, приводящий к потере данных. Тогда специалисты ИТ-подразделения получают запрос восстановления данных на системе, о которой им ничего не известно. Как правило, такие системы попадают в поле зрения ИТ-служб слишком поздно. Решение этой проблемы может оказаться трудоемким и займет много времени. Потребуются регулярный просмотр и мапирование (определение соответствия) новых сетевых адресов, фильтрация не связанных с задачей адресов, идентификация местоположения и владельцев таких узлов и внесение соответствующих изменений в политику резервного копирования.
7. Максимально возможная централизация и автоматизация резервного копирования. Ключом к успешной защите данных является их целостность. Проблема «внешних» систем является хорошим примером нарушения целостности данных, возникающим из-за нецентрализованного управления резервным копированием. Нередко операции резервного копирования для Windows- и Unix-серверов происходят независимо. Помимо того что это неэффективно, подобная организация предполагает разные наборы процедур и разные стратегии резервного копирования для разных платформ. По географическим соображениям функции резервного копирования могут быть действительно распределены по удаленным офисам, но, принимая во внимание качество современных коммуникаций, выгода от такой децентрализации небольшая.
По мере увеличения сложности инфраструктуры резервного копирования для выполнения повторяющихся операций желательно применять средства автоматизации. Рассмотрим, например, трудоемкую задачу ежедневного изучения журналов (логов) выполнения операций. Автоматизация позволит генерировать сигналы тревоги при появлении в них заранее определенных ошибок и избавит персонал от утомительной рутинной работы по их поиску в соответствующих журналах (логах).
8. Создание и поддержка отчетов об открытых проблемах. Оценка качества резервного копирования поможет улучшить его инфраструктуру. Например, наличие журнала открытых (нерешенных на данный момент) проблем может способствовать оптимизации процесса резервного копирования. В любом случае отчеты, детализирующие открытые проблемы, будут указывать частоту и количество появления новых и закрытия старых проблем, что, в свою очередь, многое говорит об общем состоянии системы резервного копирования. Простой отчет о тенденциях с соответствующими данными может открыть фундаментальные проблемы и помочь выработать их решение.
9. Резервное копирование должно быть включено в процесс контроля изменений системы. Среда резервного копирования по своей природе достаточно динамична. Изменение системы резервного копирования тоже происходит динамично. Резервное копирование должно входить в процесс стратегического планирования, а на операционном уровне — стать частью процесса контроля изменений системы. Происходит много непредусмотренных перебоев резервного копирования по вине коммутационной топологии сетей хранения данных, или в связи с изменениями в зонировании, или в связи с появлением «узких мест», возникающих в результате изменения конфигурации системы резервирования данных. Они могут и должны быть устранены. Если в инфраструктуре резервного копирования необходимо наличие ежемесячного перерыва для проведения апгрейдов или регламентных тестов, то такое временное окно не должно пересекаться с аналогичным перерывом в работе остальных систем. При внесении изменений в систему существует повышенная потребность в восстановлении данных, когда файлы сохраняются, а новые устанавливаются. Если инфраструктура резервного копирования остановлена для планового обслуживания, то данные не смогут быть восстановлены в нужное время. Инфраструктура резервного копирования — это производственная система, как одно из важнейших используемых приложений требующая поддержки и внимания ничуть не меньше остальной производственной среды.
Категории резервируемых данных. Обычно резервное копирование выполняется для того, чтобы можно было восстанавливать либо отдельные файлы, либо целиком файловые системы. Первый вариант позволяет удовлетворить типичный запрос на восстановление файла, когда пользователь случайно удаляет файл и просит восстановить его из последней копии. Второй вариант спасает, когда «рушится» вся система. Данные, которые обрабатываются и хранятся в типичной компьютерной системе, подразделяются на две категории: к первой категории относятся данные, которые практически никогда не изменяются; ко второй категории относятся постоянно изменяемые данные. Поскольку резервная копия — это снимок, копируемый в определенный момент времени, то чем чаще данные меняются, тем чаще следует выполнять их резервное копирование.
Например, данные, представляющие ОС, обычно меняются только во время обновлений, установки исправлений ошибок и каких-либо изменений в соответствии с задачами пользователя. Сам процесс установки ОС довольно прост, а применение исправлений и процедуры настройки хорошо документированы и легко воспроизводимы. Поэтому вместо резервирования ОС можно в \ случае аварии просто переустановить ее, используя дистрибутивную копию. Однако если есть хоть малейшее сомнение в том, что при новой установке удастся полностью воссоздать окружение изначальной системы, лучше выполнить резервное копирование ОС, хотя делать его можно гораздо реже, чем резервную копию полезных данных.
Резервные копии ОС также могут пригодиться, когда потребуется восстановить всего несколько системных файлов (например, в случае ошибочного удаления). Похожая ситуация складывается с данными, представляющими прикладное ПО, которые меняются либо при установке, либо при обновлении, либо при удалении программ.
Другой вид данных — данные приложений. Они меняются так же часто, как часто запускаются связанные с ними приложения. В зависимости от определенного приложения это может означать, что изменения происходят ежесекундно или один раз в квартал — по-видимому, так же часто нужно производить их резервное копирование. Наконец, данные пользователей постоянно меняются в соответствии с характером работы организации.
Определив эти и другие категории данных, администратор отдела резервирования данных должен хорошо представить себе, какие резервные копии необходимо делать, чтобы защитить данные пользователей. При этом нужно иметь в виду, что большинство программ резервного копирования работает с данными на уровне каталога или файловой системы. Другими словами, структура каталогов системы предприятия влияет на то, как будет выполняться резервное копирование. Поэтому следует выбирать оптимальную структуру каталогов в новой системе и группировать файлы и каталоги в соответствии с их предназначением.
Типы резервного копирования. Чтобы правильно настроить резервное копирование, необходимо знать, что существуют три типа резервного копирования: полные, добавочные и разностные копии.
Полная копия — это копия, при которой на резервном носителе сохраняется каждый файл, подлежащий резервированию. Если копируемые данные никогда не меняются, то все создаваемые полные копии будут одинаковыми. Это объясняется тем фактом, что при создании полной копии не проверяется, был ли файл изменен со времени последнего копирования, и, таким образом, на носитель записываются все файлы независимо от того, были они изменены или нет. Именно по этой причине полные копии не делаются постоянно — все файлы уже записаны на резервный носитель. Ежедневное копирование 100 Гбайт данных, когда возможно, изменяются только 10 Мбайт, противоречит здравому смыслу, поэтому в данном случае будет применен механизм добавочных копий.
При создании добавочных копий файла сначала проверяется время изменения файла и сравнивается со временем последнего копирования. Если время изменения более раннее, значит, файл не был изменен после последнего копирования и в этот раз его можно пропустить. С другой стороны, если дата изменения файла более поздняя, чем дата последнего копирования, значит, файл был изменен и его следует включить в резервную копию.
Добавочные копии используются в сочетании с регулярными полными копиями (например, полные копии делаются еженедельно, а добавочные — ежедневно). Основное преимущество добавочных копий заключается в том, что они выполняются гораздо быстрее, чем полные; основной недостаток — в том, что для восстановления нужного файла может потребоваться просматривать несколько добавочных копий, пока он не будет найден. При восстановлении всей файловой системы необходимо восстановить последнюю полную копию и все последующие добавочные копии. Именно с целью исключить необходимость восстановления всех копий по очереди был разработан разностный метод резервного копирования данных.
Разностные копии похожи на добавочные тем, что они включают в себя только измененные файлы. Разностные копии являются накопительными: файл, измененный однажды, будет включаться во все последующие разностные копии (имеется в виду до следующей полной копии). Это значит, что каждая разностная копия содержит все файлы, измененные со времени последней полной копии, что позволяет выполнить полное восстановление, восстановив только последнюю полную и последнюю разностную копии.
Стратегия резервного копирования с разностными копиями обычно похожа на стратегию с добавочными копиями: за одним периодическим полным циклом копирования следуют несколько более частых разностных циклов. Эффект такого использования разностных копий заключается в том, что со временем разностные копии немного вырастут (если в интервале времени между полными копиями меняются разные файлы). Таким образом, разностные копии находятся где-то между добавочными и полными копиями с точки зрения использования резервных носителей и скорости копирования, а также быстроты восстановления файла или всей файловой системы (так как приходится просматривать (восстанавливать) меньше копий).
Резервный носитель. В настоящее время на практике в качестве резервных носителей используются магнитная лента и магнитный диск. Несомненными преимуществами магнитных лент являются их невысокая стоимость и достаточно большой объем. Однако последовательный доступ к ленточному накопителю часто приводит к недопустимым временным затратам, идущим на поиск требуемого файла из резервного архива. Что касается накопителей на магнитных дисках, то в прошлом они никогда не использовались в качестве резервного носителя. Однако в настоящее время цена хранения данных на дисках упала до такой отметки, когда хранение резервных копий на дисках имеет большое практическое значение. Главной причиной для использования дисков в качестве резервных носителей является то, что они — самые быстрые из существующих носителей данных.
Сама по себе сеть не может являться резервным носителем, но в сочетании с технологиями хранения она может оказаться очень полезной. Например, если взять высокоскоростное сетевое подключение к удаленному центру данных с дисковыми хранилищами большого объема, то можно получить хороший вариант резервирования данных.
Архитектуры систем хранения данных. Совершенствование сетевых технологий сопровождалось развитием инфраструктуры систем хранения данных. При изменении требований к этим системам улучшались и технологии записи и чтения магнитных лент, для которых резервное копирование, архивирование и иерархическое хранение данных в настоящее время являются основными областями применения. Развитие технологии хранения данных привело к упрощению организации совместного пользования устройствами, увеличению пропускной способности соединений, оптимизации поддержки работоспособности и лучшему масштабированию. В настоящее время известны следующие виды архитектур хранения данных:
прямое подключение системы хранения данных к серверу — Direct Attached Storage (DAS), показанное на рис. 4.1, а;
подключение автономной системы хранения данных к сети — Network Attached Storage (NAS), показанное на рис. 4.2;
инфраструктура блочного хранения данных, построенная на базе высокоскоростной сети — Storage Area Network (SAN), показанная на рис. 4.3, 4.4.
Целостность данных в системе прямого подключения к серверу (DAS) обеспечивается известной технологией RAID. Однако такое Решение подойдет для ограниченного числа рабочих станций. Действительно, совместное использование конечных вычислительных ресурсов ограничивает количество одновременно подключенных машин к серверу числом портов в устройстве хранения, причем сервер оказывается перегруженным функциями работы с файлами.
Рис. 4.1. Варианты DAS-архитектур с одним (а) и парком [б] серверов
Рис. 4.2. Минимальная NAS-архитектура хранения данных
Рис. 4.3. Первая минималь- Рис. 4.4. Современная минимальная
ная SAN-архитектура SAN-архитектура хранения данных
хранения данных
Кроме того, вынесение хранения данных за пределы компьютеров на сервер не является гарантией их полной защищенности и постоянной доступности по той причине, что в случае «падения» сервера данные становятся недоступными.
Частично проблемы производительности могут быть решены парком серверов (например, разделенные по типу обрабатываемых запросов), каждый из которых нагружает отдельное устройство хранения, как это показано на рис. 4.1, б. Однако и у этой схемы начинаются трудности, когда возникает необходимость разделять данные между серверами или объем занимаемой памяти оказывается неравномерным.
Очевидно, что в таких условиях DAS не отвечает требованиям масштабируемости и отказоустойчивости. По этой причине были предложены другие варианты архитектур хранения данных: NAS и SAN [46].
NAS-технология, в отличие от DAS-схемы, созданная в соответствии с концепцией выделенного файл-сервера, снимает нагрузку с универсального сервера, что повышает его производительность при работе с приложениями.
Основное конструктивное отличие NAS-серверов от универсальных серверов заключается в том, что в NAS-серверах есть только системный блок (файл-сервер) и множество «расшаренных» папок для доступа клиентов. NAS — это всего лишь устройство для файлового обмена в IP-сети. Минимальная конфигурация HAS показана на рис. 4.2.
Характерной особенностью NAS-серверов является также их независимость от ОС и работа под управлением ОС, оптимизированных для работы с файлами в сетевом окружении. Многие современные NAS-серверы работают со встроенными ОС MS Windows, Unix, Linux или собственной ОС от производителя. Взаимодействие NAS-сервера с ЛВС осуществляется через стандартные сетевые протоколы. Технология NAS кроме обеспечения заметного снижения загрузки сервера приложений, простоты установки и эксплуатации обладает следующими преимуществами по сравнению с технологией DAS:
позволяет гибко распределять ресурсы дисковой системы и устройств резервного копирования, добавляя эти ресурсы туда, где они наиболее необходимы, причем общий объем доступной информации может достигать многих терабайт;
данные с NAS-сервера можно всегда скопировать на магнитную ленту стриммера, подключенного к NAS;
реализует совместный доступ к данным с множества платформ, работающих под управлением различных ОС (Windows, Linux, Unix, NetWare и MacOS), причем функционирование NAS-сервера не зависит напрямую от сервера ЛВС и установленной на нем ОС;
в NAS-серверах применяется специализированная ОС, оптимизированная для обработки и передачи данных, что обеспечивает высокую производительность и надежность их работы;
возможность доступа к данным NAS-сервера при отключенном (или отказавшем) основном сервере.
Недостатком технологии NAS является так называемый конфликт сетевого трафика. При применении технологии NAS локальная сеть используется как для обмена данными между серверами приложений и устройствами хранения, так и для передачи пользовательского трафика на рабочие станции. Хотя NAS-СеРверы и освобождают системные ресурсы серверов ЛВС от задач управления хранением, но не разгружают полностью сетевой трафик, так как обмен данными между серверами приложений(или клиентскими ПК) и NAS-серверами осуществляется в той же ЛВС. Это ведет к тому, что высокая нагрузка на сеть с ограниченной пропускной способностью может существенно увеличить время отклика.
SAN является высокоскоростной коммутируемой сетью передачи данных, которая позволяет соединить серверы, рабочие станции, дисковые массивы и ленточные библиотеки в единую систему. Соединение происходит по протоколу Fibre Channel, который обеспечивает оптимизированный и быстрый обмен данными между элементами сети на расстоянии от нескольких метров до сотен километров.
Первая SAN-архитектура была предложена в конце 1980 гг. В качестве коммутирующего устройства она использовала хаб, как показано на рис. 4.3. Принцип ее работы был аналогичен методу CSMA/CA: каждый раз, когда какой-либо узел собирался выполнить операцию ввода-вывода, он посылал блокирующий пакет, оповещая всех о начале передачи. Когда пакет возвращался отправителю, узел получал полный доступ для проведения операции. По окончанию операции все узлы оповещались об освобождении канала и процедура повторялась. Однако ближайшее рассмотрение данной архитектуры показывает, что она кроме проблемы с пропускной способностью, аналогичной архитектуре DAS, имеет еще одну: в каждый момент времени только один клиент может выполнять операцию ввода-вывода. Кроме того, использование 8-битной адресации в этой архитектуре накладывало ограничение на количество устройств в сети — 127, что не"позволяло ей конкурировать с архитектурой DAS.
В настоящее время на смену первой архитектуры SAN пришла архитектура FC (Fibre Channal), показанная на рис. 4.4, которая вместо хаба использует несколько коммутаторов, поэтому данные предаются здесь не по разделяемому каналу, а по индивидуальным каналам. Как и в сети Ethernet, на базе этих коммутаторов можно построить множество топологий.
Основные преимущества архитектуры FC:
общий объем памяти может расти не только за счет увеличения емкости существующих блоков памяти (storage), но и за счет добавления новых;
каждый хост может работать с любым устройством хранения, а не только со своим, как в случае с DAS;
сервер имеет несколько «путей» получения данных, поэтому при правильно построенной топологии, даже после выхода из строя одного из коммутаторов, система остается работоспособной;
система позволяет разграничивать доступ серверов к ресурсам;
в основном решена проблема с пропускной способностью, так как операции резервного копирования не оказывают влияния на всю сеть.
Еще одно преимущество SAN-архитектуры — она позволяет построить множество различных решений в зависимости от задачи. Например, если установить на один из серверов специальную ОС, то можно реализовать gateway-реализацию NAS-архитектуры со всеми ее дополнительными преимуществами, перечисленными ранее. Таким образом, в рамках решения для одного предприятия могут сочетаться и DAS-, и NAS- и SAN-архитектурные решения резервного хранения данных.
Недостатком SAN-архитектуры является ее высокая цена, поэтому она еще мало распространена за пределами ведущих предприятий [47].
Принципы работы и компоненты хранилищ данных
Хранилища данных — это процесс сбора, отсеивания и предварительной обработки данных в целях представления результирующей информации пользователям для статистического анализа и аналитических отчетов. Автор концепции ХД, Ральф Кинболл, описывал его как «место, где люди могут получить доступ к своим данным». Он же сформулировал основные требования к хранилищам данных:
поддержка высокой скорости получения данных из хранилища;
поддержка внутренней непротиворечивости данных;
возможность получения и сравнения данных;
наличие удобных утилит просмотра данных хранилища;
полнота и достоверность хранимых данных;
поддержка качественного процесса пополнения данных.
Часто всем перечисленным требованиям удовлетворить не удается, поэтому для реализации ХД используют несколько продуктов: одни продукты — это средства хранения данных, другие — средства их извлечения и просмотра, третьи — средства пополнения ХД. Типичное ХД, как правило, отличается от реляционной БД по трем позициям:
обычная БД помогает пользователям только изменять данные, тогда как ХД предназначены для принятия решений;
обычная БД подвержена постоянным изменениям с заданной периодичностью (ежечасно, ежедневно, ежемесячно), причем пополнение данными происходит без изменения прежней информации, находящейся уже в хранилище;
обычная БД чаще всего является источником данных попадающих в хранилище, кроме того, ХД может пополняться за счет внешних источников.
Принципы построения ХД. Информация, которая загружается в хранилище, должна интегрироваться в целостную структуру, от-: вечающую целям анализа данных. При этом минимизируются несоответствия между данными из различных ОС — в ХД данные именуются и выражаются единым образом. Данные в ХД интегрированы на множестве уровней: на уровне ключа, атрибута, на описательном, структурном уровнях и т. д.
Хранилища можно рассматривать как набор моментальных снимков состояния данных — можно восстановить картинку на любой момент времени. Атрибут времени всегда явно присутствует в структурах данных хранилища.
Попав однажды в ХД, данные уже никогда не изменяются, а только пополняются новыми данными. Новые данные по мере поступления обобщаются с уже накопленной информацией в ХД.
Основные компоненты ХД. Использование технологии ХД предполагает наличие в системе следующих компонентов:
источники данных;
реляционное хранилище;
средства переноса и трансформации данных;
средства доступа и анализа данных;
OLAP-хранилища;
метаданные.
Данные из различных источников собираются, очищаются, интегрируются и помещаются в реляционное хранилище, где они уже доступны для анализа средствами построения отчетов. Затем данные подготавливаются с использованием средств переноса и трансформации данных для OLAP-анализа, который реализуется применением средств доступа и анализа данных. При этом они могут быть загружены в специальную базу данных (OLAP-хранилища) или оставаться в реляционном хранилище.
Важнейшим элементом хранилища являются метаданные, т.е. данные о структуре, размещении, трансформации данных, которые используются любыми процессами хранилища. Метаданные включают в себя каталог хранилища и правила преобразования данных при загрузке их из внешних БД. Метаданные могут быть востребованы для различных целей (например, для извлечения и загрузки данных, обслуживании хранилища и запросов). Метаданные для различных процессов могут иметь различную структуру, т.е. для одного и того же элемента данных могут существовать несколько вариантов метаданных.
Хранилища данных являются структурированными. Они содержат базовые данные, которые образуют единый источник для обработки данных во всех системах поддержки принятия решений. Элементарные данные, присутствующие в хранилище, могут быть представлены в различной форме. ХД очень велики, поскольку содержат интегрированные и детализированные данные.
Эти характеристики являются общими для всех ХД. Несмотря на то что хранилища обладают общими свойствами, разные типы хранилищ имеют свои индивидуальные особенности.
Для работы с ХД используются специальные СУБД, к которым предъявляются следующие требования:
высокая производительность загрузки данных;
возможность обработки данных на уровне загрузки;
наличие средств управления качеством данных;
высокая производительность запросов;
широкая масштабируемость по размеру и количеству пользователей;
возможность организации сети хранилищ данных;
наличие средств администрации хранилищ данных;
поддержка интегрированного многомерного анализа;
расширенный набор функциональных средств запросов.
Хранилище данных — это компьютерная система, главной целью разработки которой является информационное обеспечение компьютерной поддержки принятия решений по всем или основным видам деятельности организации.
OLAP-технология анализа данных
OLAP (OnLine Analytical Processing) — это технология комплексного многомерного анализа данных. В 1993 г. эта технология была описана Эдгером Коддом, который связал ее с концепцией ХД. Назначение систем класса OLAP — предоставить пользователям гибкий, интуитивно понятный и простой доступ к данным в ХД. Наличие такого доступа позволяет отказаться от использования предопределенных отчетов, делает пользователей независящими от администраторов баз данных и программистов. В основе концепции OLAP лежит принцип многомерного представления данных. Данные представляются в виде многомерного куба, причем пользователь может быстро свернуть или развернуть данные по любому измерению этого куба.
Для построения ХД используется СУБД — MS SQL-сервер, которая удовлетворяет всем перечисленным ранее требованиям, начиная от высокой производительности и заканчивая расширенным набором функциональных средств запросов пользователей к ХД.
OLAP — это совокупность концепций, принципов и требований, лежащих в основе программных продуктов, облегчающих пользователям доступ к данным. Кубы OLAP представляют собой по сути метаотчеты, разрезая которые по измерениям, пользователь фактически получает интересующие его обычные двумерные отчеты. Преимущества кубов очевидны — данные необходимо запросить из реляционной СУБД всего один раз — при построении куба. Самих отчетов в ХД по сути дела не существует — они формируются «на лету» и материализуются в виде файла на компьютере вызвавшего этот отчет пользователя, который может просто просмотреть его на своем ПК, после чего удалить и (или) распечатать.
В хранилище данных информация хранится в измерениях и процессах. Измерение — это объект анализа, который может характеризоваться свойствами, присущими только ему и имеет уникальный идентификатор. Процесс представляет собой звезду, в центре которой хранятся факты, а лучи являются измерениями. Рассмотрим сказанное на примере. Пусть в ХД присутствуют данные только по процессу «Сделка», который содержит измерения: «И1 — номер клиента», «И2 — состояние сделки», «ИЗ — причина отказа», «И4 — менеджер, курирующий сделку», «И5 — дата сделки». Дополнительными и з м е р е н и я м и являются: «И6 — источник информации, способствующий сделке», «И7 — номер покупаемого товара», «И8—номер региона» и «И9 — сфера деятельности клиента». Кроме того, в ХД присутствуют следующие факты: «Ф1 — объем сделки» и «Ф2 — сумма сделки».
Если бы в ХД по «Сделке» присутствовали только три измерения, например «номер клиента», «дата сделки» и «состояние сделки, причем каждое измерение содержало бы только по два значения («объем» (О) и «сумма» (С)), то графически OLAP-куб такого хранилища можно было бы представить в виде обычного куба, показанного на рис. 4.5. В нашем случае не три измерения, а девять, причем по каждому из них количество «координат» — переменное число. Изобразить такой куб на плоскости можно, показав его проекцию из 9-го измерения, однако наглядность такой проекции будет нулевая. Более нагляден куб в виде графа, показанного на рис. 4.6. В данном случае ХД представляется двумя «звездами» с центрами соответственно в вершинах «Объем» и «Сумма» сделки. «Плоский» или двумерный отчет «Дата/Состояние», который построит OLAP-модуль по запросу пользователя, представляет табл. 4.1.
Рис. 4.5 Пример OLAP-куба
Перечислим основные требования, предъявляемые к программным продуктам, реализующим OLAP-технологию обработки данных в ХД.
Рис. 4.6. Модель OLAP-куба в виде двудольного графа
Таблица 4.1
Дата Состояние
Открыта Успех
02.12 25/19 2/2
03.12 80/50 100/60
1. Fast (быстрый). Это свойство означает, что система должна обеспечивать ответ на запрос пользователя в среднем за 5 с; при этом большинство запросов обрабатываются в пределах 1 с, а самые сложные запросы должны обрабатываться в пределах 20 с. Недавние исследования показали, что пользователь начинает сомневаться в успешности запроса, если он занимает более 30 с.
2. Analysis (аналитический). Система должна справляться с любым логическим и статистическим анализом, характерным для бизнес-приложений, и обеспечивает сохранение результатов в виде, доступном для конечного пользователя. Средства анализа могут включать в себя процедуры анализа временных рядов, распределения затрат, конверсии валют, моделирования изменешг организационных структур и некоторые другие.
3. Shared (разделяемый). Система должна предоставлять широ кие возможности разграничения доступа к данным с одновременной работы многих пользователей.
4. Multidimensional (многомерный). Система должна обеспечивать концептуально многомерное представление данных, включая полную поддержку множественных иерархий.
5. Information (информация). Мощность различных программных продуктов характеризуется количеством обрабатываемых входных данных. Разные OLAP-системы имеют разную мощность: передовые OLAP-решения могут оперировать в 1 000 раз большим количеством данных по сравнению с самыми маломощными OLAP-системами. При выборе OLAP-инструмента следует учитывать целый ряд факторов, включая дублирование данных, требуемую оперативную память, объем дискового пространства, эксплуатационные показатели, интеграцию с информационными хранилищами и т. п.
В настоящее время в мире разработано множество программных продуктов, реализующих OLAP-технологии. Чтобы легче было в них ориентироваться, используют классификации OLAP-продуктов: по способу хранения данных для анализа и по месту нахождения OLAP-машины.
|
