 |
Резервное копирование
Думается, нет никакой необходимости говорить о пользе применения систем резервного копирования. Как говорится, "уж сколько раз твердили миру": резервные копии - это спасательный круг, способный пригодиться в самых разных ситуациях. Тем не менее сплошь и рядом встречаются пользователи (как персональные, так и корпоративные), которые пренебрегают резервным копированием. А зря! Если система вместе с данными по какой-то причине "рухнет" (например, если труба отопления лопнет аккурат над сервером), потери могут оказаться катастрофическими для пользователя.
Специалисты считают, что интервал времени между процедурами сохранения данных следует определять исходя из следующих соображений. Если вы, например, готовы пожертвовать неделей работы - копируйте данные раз в неделю, сутками - раз в сутки, часом - раз в час. Многие корпоративные клиенты осуществляют резервное копирование раз в сутки, находя таким образом компромисс между суммарной стоимостью систем резервного копирования и убытками, которые может понести фирма в случае потери данных. Есть технологии, позволяющие очень быстро производить резервное копирование огромных объемов данных, но они достаточно дороги, их установка целесообразна в основном на крупных предприятиях.
Когда речь заходит о системах резервного копирования, первый вопрос, как правило, звучит так: на какие носители лучше всего копировать? На сегодняшний день ответ практически однозначен: на магнитную ленту. Да-да, на старую добрую стримерную ленту. Естественно, не на ту же самую, что использовалась в популярных некогда стримерах Jumbo. Нынешние технологии ушли далеко вперед. Последние из получивших широкое распространение ленты DLT (Digital Linear Tape) способны хранить до 70 Гбайт данных, обеспечивая при этом обмен данными со скоростью 5 Мбайт/с (всю ленту целиком можно записать за два часа). По словам менеджера компании "Интерпроком ЛАН" Александра Николаева, специализирующегося на средствах СУБД, ленты DLT обладают высокой надежностью и износостойкостью, что обусловлено отсутствием непосредственного контакта с головкой чтения/записи данных - лента проносится рядом с головкой, не касаясь ее. Стоят такие ленты примерно 120 долл. Кроме них активно используются также 4- и 8-миллиметровые ленты емкостью до 24 и до 50 Гбайт соответственно по цене от 20-30 до 100 долл.
Поклонники хранения данных на сменных дисковых накопителях могут спросить: позвольте, а как же магнитооптика, чем она хуже стримерных лент? Имеющиеся в продаже магнитооптические накопители имеют гораздо меньшую емкость (диски производства Hewlett-Packard вмещают 2,6 Гбайт; Mitsubishi - 4,6 Гбайт), но стоят при этом соответственно от 75 и 90 долл. и выше. Нельзя не заметить, что 4,6 Мбайт - это совсем не много по нынешним меркам, такую емкость имеют один-два современных жестких диска. По мнению Николаева, производить резервное копирование данных на магнитооптические диски имеет смысл только на предприятиях с относительно небольшими объемами данных.
Впрочем, использование однокассетных стримерных устройств также оправданно только для сохранения данных лишь небольших серверов, да и то при условии, что предприятие готово платить оператору, который время от времени меняет ленты. Чтобы хранить копии дисковой памяти крупных серверов и дисковых массивов, требуются "библиотекари" стримерных лент - роботизированные устройства хранения, способные производить доступ к одной из нескольких стримерных кассет (при этом осуществляется поиск нужных лент и их замена в стримерном модуле). Внутри роботизированных библиотек, как правило, применяются стандартные стримеры в OEM-исполнении, разработанные компаниями Sony, Hewlett-Packard, Quantum и другими. Сами роботизированные библиотеки магнитных лент выпускаются Hewlett-Packard, IBM, Fujitsu, Hitachi, StorageTek, ADIC, EMASS, Sutmyn и рядом других компаний. Наши собеседники Александр Николаев, представляющий "Интерпроком ЛАН", и эксперт компании "ТехноСерв А/С" Андрей Гершельман из всего спектра выпускаемых ныне роботизированных библиотек стримерных лент выделили продукцию двух производителей - ADIC и StorageTek; специалисты считают, что именно эти устройства на сегодня оптимальны для создания систем резервного копирования.
Роботизированные библиотеки очень удобны для резервного копирования как сверхбольших (десятков и сотен гигабайт), так и средних (нескольких десятков Гбайт) объемов данных. В последнем случае корпоративные системы копирования можно довольно легко настроить на недельный цикл резервирования данных, например так, что на каждой вставленной в устройство ленте будет храниться информация за определенный день недели.
Программые компоненты для систем резервного копирования поcтавляют компании IBM, Hewlett-Packard, Computer Associates, Seagate, Legato Systems и ряд других. Имеются решения для Windows NT, NetWare, Unix-систем, мэйнфреймов. В числе основных функций, которые выполняют программные системы, резервное копирование по расписанию, поддержка гетерогенных сетевых сред (как правило, она производится с помощью программных агентов), разнообразных ленточных, магнитооптических и дисковых устройств, возможность интеграции с различными СУБД, желательно также наличие средств централизованного управления и администрирования. По мере роста корпоративных систем большое значение стало придаваться удаленному копированию данных с сетевых серверов и дисковых массивов в единый ленточных архив. Естественно, при этом ПО должно обеспечивать высокую скорость процесса копирования данных, в противном случае операция станет неэффективной. В мощных системах для обслуживания стримерных лент имеется возможность параллельного копирования данных сразу на несколько лент, а также функция буферизации данных с использованием жесткого диска, встроенного в стримерное устройство.
Очень важно, чтобы программные системы для резервного копирования могли работать со множеством вычислительных и сетевых платформ и, кроме того, поддерживали устройства от различных производителей. Это позволит обеспечить гибкость и масштабируемость систем резервного копирования в целом, экономя немалые средства в процессе совершенствования корпоративной информационной системы.
Здорово облегчают жизнь системным администраторам функции восстановления серверов. Нарушение нормальной работы серверов - дело вполне обыденное. В случае сбоя сервера перед его администратором встает непростая задача - как можно быстрее вернуть его в работоспособное состояние. Если нарушения в структуре сервера оказываются достаточно серьезными (например, в случае выхода из строя операционной или файловой системы), администратору приходится, как правило, сначала заново восстанавливать операционную систему и лишь затем копировать на сервер все остальные файлы. В случае если сервер не снабжен системой резервного копирования или эта система занимается только сохранением данных, оставляя без внимания конфигурацию сервера, требуется также установка и настройка всех необходимых приложений. В результате колоссальные простои и, как следствие, финансовые потери. В идеале было бы правильно восстанавливать весь сервер целиком автоматически, начиная с операционной системы и заканчивая файлами данных. Примерно так действует, например, система ARCserve компании Computer Assiciates. С пары дискет загружается ядро операционной системы и системы восстановления, после чего дальнейшее копирование данных производится автоматически.
Структура корпоративной системы резервного копирования может быть различной. Если серверов и дисковых массивов немного, можно оборудовать их отдельными системами копирования данных. Правда, стоить такое решение будет довольно дорого, поэтому для систем с большим числом серверов оно вряд ли приемлемо. Альтернативой данному решению может служить удаленное копирование данных. В этом случае информация стекается к централизованному серверу резервного копирования, который обслуживает сразу множество корпоративных серверов. Такое решение гораздо экономичнее, но и оно небезупречно: если сервер резервного копирования выйдет из строя, то вся работа по сохранению и восстановлению данных приостановится.
Там, где стоимость данных очень велика, следует с особой ответственностью подходить к проблеме резервного копирования. В этом случае специалисты настоятельно рекомендуют по возможности хранить ленты в разных помещениях, лучше всего даже не в тех зданиях, где производится копирование. В случае пожара, прорыва канализационных труб, взрыва газа или какой-нибудь еще неприятности, в результате которой серверы и дисковые массивы будут надолго выведены из строя, хранимые отдельно резервные копии помогут восстановить данные на другие устройства.
Если резервное копирование требуется осуществлять практически непрерывно, можно последовать советам компании EMC, которая предлагает установить в двух удаленных друг от друга помещениях два дисковых массива, соединить их высокоскоростным каналом связи и производить удаленное зеркалирование данных. В случае выхода из строя одного из массивов его функции немедленно возьмет на себя другое аналогичное устройство. При желании логический канал связи можно время от времени разрывать, производить на одном из массивов копирование на ленты, после чего восстанавливать связь и синхронизировать данные путем тиражирования. Недостатком подобного решения является высокая цена, тем не менее если совокупная стоимость информации и работ по ее восстановлению достаточно велика, то подобные конфигурации наверняка оправдают себя в первой же критической ситуации.
Как рассказал нам Николаев, отечественные клиенты на первых порах обычно используют для резервного копирования магнитооптические накопители. (Этот факт вызывает удивление западных маркетологов, так как там применение магнитооптики для этих целей можно рассматривать скорее как исключение, нежели как правило.) Затем по мере роста объемов данных заказчики переходят к стримерам и ленточным автоподатчикам. По словам главного менеджера по сетевым продуктам компании "Интерпроком ЛАН" Александра Клебанова, спрос на системы резервного копирования непрерывно растет. Объем продаж компанией программных компонентов с каждым годом удваивается - в настоящее время он достиг 100 лицензий в месяц, в основном для NetWare и NT. Рынок больших решений тоже развивается, но достаточно медленно. Компания "ТехноСерв А/С", например, продала несколько мощных роботизированных стримерных систем.
Системы иерархической памяти
Иерархия памяти для компьютерных систем - дело привычное. Регистры процессора, внутренняя и/или внешняя кэш-память, оперативная память и жесткие диски имеются практически на любом современном компьютере. Получили распространение и дисковые массивы, в частности поддерживающие RAID-технологию. Однако системы иерархической памяти для хранения редко используемых данных пока что в России еще в диковинку, правда, в последнее время интерес к ним значительно вырос.
По данным проведенных IDC исследований, 80% хранимых на компьютере данных ни разу не использовались в пределах по крайней мере месяца, 60% - в течение года. Так стоит ли тратить не столь уж дешевую память жестких дисков на редко используемые данные? Вероятно, нет. Но и совсем их удалять из системы тоже, как правило, не хочется - а вдруг пригодятся?
В данном случае оптимальным решением могут считаться системы иерархической памяти, позволяющие вытеснять редко используемые файлы на менее скоростные, но более дешевые носители - прежде всего на стримерные ленты и магнитооптические диски (при этом речь идет, конечно, о файлах данных; не следует перемещать на носители более низкого уровня файлы, необходимые для нормальной работы операционной системы и приложений). Программные компоненты систем иерархической памяти обеспечивают при этом прозрачность доступа: файлы, вытесненные на вторичные носители, видны пользователям точно так же, как и обычные. Основное отличие при работе с файлами в том, что при первом обращении к вытесненным на другие носители файлам доступ потребует больше времени (как правило, не более одной-двух минут), чем обычно.
Такая организация хранения данных особенно полезна там, где сотрудникам для выполнения текущей работы необходим относительно небольшой набор файлов, например в корпоративных системах электронного документооборота. Другая перспективная сфера применения - библиотеки мультимедийных данных. Как известно, многие аудио- и видеофайлы очень громоздки - вряд ли стоит все эти данные хранить на жестких дисках. Гораздо дешевле использовать жесткие диски в качестве буферной памяти, а файлы разместить в библиотеках оптических или магнитооптических дисков.
Требования к ПО для создания систем иерархической памяти сходны с теми, что предъявляются по отношению к системам резервного копирования: поддержка гетерогенных сетевых сред и различных программно-аппаратных платформ, разнообразных ленточных, магнито-оптических и дисковых устройств, возможность относительно безболезненного перехода от одного оборудования к другому и наличие средств централизованного управления и администрирования. Сходство не случайно, так как в принципе системы резервного копирования - не что иное, как один из вариантов систем иерархической памяти. Также не случаен и выбор компаний, предлагающих программные решения для создания таких систем. Как бы то ни было, рынок делят между собой одни и те же компании - IBM, Hewlett-Packard, Computer Associates, Seagate, Legato Systems, Veritas и несколько других.
В системах иерархической памяти применяется, как правило, двухуровневая, реже - трехуровневая архитектура: данные с жестких дисков переносятся на менее скоростные устройства прямого доступа (например, на магнитооптические диски, иногда - на магнитные ленты), а затем на еще менее скоростные, как правило ленточные накопители. Пользователи крупных корпоративных систем могут предъявить еще одно требование к системам иерархической памяти - наличие распределенной архитектуры. Корпоративный заказчик наверняка захочет использовать свое оборудование и программные системы максимально эффективно. В этом случае данные с файловых серверов будут стекаться на один или несколько массивов носителей более низкого уровня.
Хранилища данных
Об этой концепции довольно много говорят представители практически всех ведущих поставщиков СУБД. Напомним кратко, что в ее основе - идея создания централизованной и всеобъемлющей корпоративной базы данных, основное предназначение которой - информационное обеспечение систем поддержки принятия решений, адресованных руководителям предприятий. По меткому выражению технического менеджера российского представительства компании Sybase Бориса Крутова, хранилище данных - это корпоративная версия истины.
По замыслу автора идеи создания хранилищ данных Билла Инмона, лежащая в основе таких систем база данных должна отвечать ряду требований. Во-первых, ориентироваться на предметную область, а не на специфику приложений, которые будут работать с этими данными. Структура данных в хранилище должна отражать точку зрения корпоративного пользователя на совокупность информации, с которой ему приходится иметь дело в своей повседневной практике. В хранилище следует помещать исчерпывающий набор данных, причем именно тех, которые могут пригодиться в процессе принятия решений (в частности, вряд ли имеет смысл держать в хранилище данных электронные макеты рекламных буклетов или письма, поступившие от партнеров и клиентов).
Во-вторых, хранилище должно содержать интегрированную информацию, полученную на основе данных, поступивших в систему из множества источников. Причем интеграция - это не сваливание данных из разных источников в одну кучу, а их объединение с приведением к единому синтаксическому и семантическому виду (это можно и нужно делать, так как в таблицах, полученных из разных систем-источников, часто встречаются поля, именуемые по-разному и определенные на разных доменах, но означающие одно и то же). Необходимо проводить проверки на непротиворечивость, целостность данных и т. д.
В-третьих, база данных хранилища должна быть оптимизирована для выполнения прежде всего операций поиска и чтения данных. Данные, пройдя предварительную обработку и попав однажды в хранилище, остаются там на долгие годы, причем внесение каких-либо изменений в данные (кроме добавления, конечно) не предполагается - хранилище должно содержать детализированную информацию о деятельности корпорации, накапливаемую годами, возможно - десятилетиями. В четвертых, и само оборудование, на котором предполагается хранить данные, должно быть надежным, так как хранилище данных будет использоваться в течение по меньшей мере 5-10 лет.
Непосредственно на основании "постулатов" концепции хранилищ данных можно построить схему их встраивания в корпоративную информационную систему. По одну сторону от хранилищ данных остаются различные источники информации, в качестве которых обычно выступают системы оперативной обработки транзакций (On-Line Transaction Processing, OLTP). По другую - приложения-потребители - прежде всего системы оперативной аналитической обработки данных (On-Line Analytical Processing, OLAP).
Система поставщиков информации может быть несколько, данные в них, вероятнее всего, будут храниться в разных форматах. Необходимо привести их к единому виду, согласовать между собой, разрешить возможные противоречия между данными из разных источников, после чего загрузить в хранилище данных, обеспечив при этом минимальную избыточность (обычно это достигается путем приведения данных к третьей нормальной форме). Для этого нужно каким-то образом описать структуры данных, которые поступают из различных источников, и определить процедуры их автоматического преобразования. Это делается с помощью средств работы с метаданными, поставляемых как производителями СУБД (Oracle, Sybase, NCR, IBM и др.), так и компаниями, специализирующимися на создании различных инструментальных средств (Platinum Technology, SAS Institute, Business Objects и др.) Многие из этих средств позволяют создавать репозитарии метаданных, облегчая тем самым повторное использование описаний структур данных и процедур их обработки. Заметим, что этап подготовки данных, пожалуй, самый трудоемкий.
Функционирование собственно хранилища данных обеспечивается на основе СУБД компаний Oracle, Informix, Sybase, NCR, IBM и ряда других. Поскольку хранилище данных выполняет довольно специфический набор операций (выборку и добавление записей в сверхбольших массивах данных), рекомендуется подобрать конфигурации СУБД, ориентированные на поддержку мультипроцессорных платформ, а также распараллеливание и оптимизацию конкретных операций (прежде всего поиска).
Потребителями информации, содержащейся в хранилище данных, являются в основном OLAP-системы. В отличие от OLTP-систем, в которых запросы к базам данных чаще всего оказываются фиксированными, системы аналитической обработки оперируют в основном произвольными, причем часто весьма сложными запросами. Для оптимизации работы как хранилищ данных, так и OLAP-систем создаются так называемые витрины (или киоски) данных (Data Marts) - базы данных, содержащие достаточно большую, но неполную выборку из хранилища данных, создаваемую специально для конкретных аналитических приложений (как правило, чтобы проанализировать отдельные стороны деятельности предприятия, полная выборка не требуется). Витрины данных могут быть реализованы в виде отдельных серверов СУБД, в виде наборов таблиц внутри основной СУБД хранилища данных или как виртуальные таблицы-представления (Views) внутри хранилища. Для создания витрин данных, естественно, существует специальный инструментарий, его разрабатывают Oracle, Sybase, NCR, IBM, Platinum Technology, SAS Institute, Business Objects и др.
По словам Лисянского, различают четыре схемы использования витрин данных. Первая схема представляет собой особый случай, когда информация попадает из источников данных прямо в витрины, минуя хранилище. Витрины данных в этом случае никак друг от друга не зависят, собирая и обрабатывая информацию так, как им заблагорассудится. Минусы такого подхода очевидны: это прежде всего недостаточно качественная подготовка данных, сложность администрирования и доступа к данным, собираемым на других витринах.
Вторая схема предполагает, что витрины данных реализуются в виде таблиц или представлений в хранилище данных, а не отдельных серверов. Это весьма удобная для пользователей схема, но она, во-первых, предъявляет повышенные требования к мощности оборудования, обслуживающего хранилище данных, во-вторых, предполагает наличие высокоскоростной сетевой магистрали, связывающей хранилище с машинами пользователей. Применение этой схемы внутри распределенной корпоративной сети может оказаться затруднительным.
Согласно третьей схеме, витрины данных создаются в виде отдельных баз данных, актуальность которых поддерживается путем репликации. Пользовательские аналитические приложения не имеют доступа к самому хранилищу и работают только с витринами, а сами витрины оперируют лишь с теми данными, которые в них уже загружены, не производя дополнительных запросов к хранилищу. В данном случае сильно затруднен доступ к данным, которые не попадают на витрину данных, однако значительно снимается нагрузка на само хранилище данных. Еще одно важное преимущество: в случае непродолжительного сбоя хранилища данных пользовательские аналитические приложения смогут продолжать нормально работать.
Четвертая схема может рассматриваться как усовершенствованный аналог предыдущей. Исключение составляет тот случай, когда для получения ответа на запрос оказывается недостаточно данных, хранимых на витрине; при этом запрос либо его часть могут быть переданы в хранилище. Естественно, все перечисленные схемы могут сочетаться в различных комбинациях. Окончательный выбор схемы зависит от потребностей конкретных аналитических задач пользователей.
Андрей Сахаров, консультант российского представительства Oracle по OLAP-системам и системам хранилищ данных, рассказал еще об одном элементе корпоративной системы принятия решений - так называемых складах оперативных данных. Обычно склады оперативных данных представляют собой своего рода промежуточную ступеньку на пути к хранилищу данных (в этом смысле рассмотренная нами первая схема организации хранилища данных может рассматриваться как набор складов оперативных данных, выполняющих роль витрин). Так же, как и витрины данных, они создаются в расчете на использование конкретными аналитическими приложениями, но при этом содержат оперативные данные из различных источников, еще не попавшие в хранилище. Информация в таких складах может быть недостаточно достоверной, согласованной, синхронизированной, и тем не менее, если аналитические задачи требуют доступа к оперативным данным, он будет получен. Относительно хранилища склад оперативных данных обычно рассматривается как еще один источник информации.
Реализация хранилищ данных представляет собой довольно сложную технологическую операцию. Впрочем, это естественно: когда приходится оперировать сотнями гигабайтов и терабайтами данных, любая мелочь может существенно сказаться на производительности системы в целом. Хранилища данных обычно строятся следующим образом. Для сбора и предварительной обработки данных от систем-источников выделяют один или несколько относительно небольших серверов на базе Unix или NT. Прямо на этих серверах либо на одном из корпоративных массивов накопителей хранится репозитарий метаданных. В качестве сервера СУБД хранилища данных выбираются мэйнфреймы или мощные Unix-компьютеры. Собственно данные хранятся в массивах дисковых накопителей, соединенных с сервером СУБД с помощью высокопроизводительной шины (SCSI, Fibre Channel, Gigabit Ethernet, ATM). Для реализации витрин данных применяют машины на базе Unix или NT с собственными массивами накопителей.
Эксперт компании "ТехноСерв А/С" Андрей Гершельман считает, что вовсе не обязательно выделять каждому компьютеру - серверу СУБД хранилища или витрины данных - отдельный дисковый массив. В принципе достаточно иметь единый массив, доступ к которому будет у всех компьютеров, работающих непосредственно с хранилищем данных. Это очень удобно - можно легко перераспределять ресурсы памяти в зависимости от потребностей, продиктованных работой аналитических приложений. Правда, необходимо предварительно убедиться в том, что данный дисковый массив можно подключать к высокопроизводительной сети, и при этом поддерживается взаимодействие с серверами различных платформ. Дисковые массивы такого типа выпускают несколько компаний - IBM, EMC, HDS, Amdahl, NCR, Hewlett-Packard, DEC, Sun, Siemens. По данным прошлогодних исследований IDC, в секторах продукции для мэйнфреймов и Unix-серверов лидирует EMC (компания удерживает соответственно 48% и 18% рынка).
Опрошенные нами эксперты предлагают в целом схожие методологии создания хранилищ данных (в частности, описание методики, к которой практическим путем пришли специалисты компании "Терн", очень напоминает то, что предлагают сотрудники NCR; по крайней мере, рассказы менеджера по проектам компании "Терн" Ильи Гусева и инженера NCR Константина Лисянского оказались очень похожими). Построение хранилища данных выглядит как интерактивный циклический процесс. Выбираются ключевые аналитические проблемы, определяется круг источников, из которых можно получить необходимые для анализа данные, и набор структур, в которые эти данные следует преобразовывать, рождаются системы сбора и обработки данных, затем создаются и начинают наполняться хранилище и витрины данных. После того как пущена в строй первая очередь системы, возникает новый круг проблем, и все повторяется.
В настоящее время в России реализуется не так много проектов по созданию хранилищ данных. По словам Лисянского, NCR ведет всего один проект, его заказчик - банковская структура. Oracle вместе с партнерами занимается несколькими десятками проектов, среди клиентов преобладают банки, но есть также государственные учреждения и телекоммуникационные компании. Sybase также ведет несколько десятков проектов. По нескольку проектов приходится на "ТехноСерв А/С" и "Терн". По словам директора по продажам компании "Контраст" Вадима Аниськина, проекты по созданию хранилищ данных с помощью инструментария Platinum Technology в России пока не реализуются; это объясняется тем, что инструментарий появился на российском рынке совсем недавно.
Инфоцентрические вычисления
Заместитель председателя совета компании "ТехноСерв А/С" Леонид Винокуров и эксперт компании Андрей Гершельман рассказали нам о новом типе архитектуры корпоративных сетей, на которую по мере роста объемов данных начали переходить западные компании. Эта архитектура появилась как альтернатива ставшему традиционным разделению сетей на серверную и клиентскую часть. Издавна так повелось в компьютерном мире, что в центре информационных систем были вычислительные ресурсы - сначала мэйнфреймы, затем серверы других платформ. Для обеспечения удобства доступа к ресурсам сети и ускорения обмена данными серверы корпоративной сети начали объединять с помощью высокопроизводительной магистрали. Топология корпоративной сети стала похожа на ромашку: в центре - кольцо из наиболее мощных серверов сети, к нему подключены малые серверы и рабочие станции. Данные хранились на различных серверах или на подключенных к ним дисковых массивах.
Но пришло время, когда такая архитектура была признана неудобной. Объемы данных разрослись до фантастических размеров, а приложения стали активно использовать данные на нескольких серверах. Оказалось, что в таких условиях архитектура клиент-сервер обходится слишком дорого. Мало того что приходится постоянно наращивать пропускную способность сети, снова и снова покупать и ставить на обслуживание множество дисковых массивов, подключаемых к отдельным серверам. Возникает еще одна проблема - как эффективно использовать те массивы, которые уже имеются? В частности, каким образом перераспределять данные, если на одном сервере дефицит дисковой памяти, а на другом она используется едва наполовину? Из одного массива диски вытаскивать, а в другой вставлять? Это не всегда реально - может не хватить свободных отсеков, чтобы поставить еще один диск. Переключать массивы? Это грозит длительными простоями.
В конце концов был предложен следующий метод: объединить устройства хранения данных - мощные массивы накопителей в еще одно кольцо, связанное высокоскоростной сетью, и именно его поставить в центр корпоративной системы. К кольцу данных можно подключить кольцо серверов, а уже к нему - всевозможные рабочие станции. На Западе такую архитектуру окрестили "сетями памяти" (Storage Area Networks, SAN; это название, очевидно, появилось по аналогии с ранее бытовавшими терминами LAN и WAN). Что дает такая организация памяти? Прежде всего она обеспечивает гибкость в управлении памятью и эффективность ее использования. Память можно легко распределять между серверами, между задачами и пользователями сети (а если необходимо - и перераспределять), производить "зеркальное" дублирование данных на нескольких массивах, перемещать данные, минуя сеть и т. д. Недостаток такого подхода в необходимости применения мощных дисковых массивов, по сути представляющих собой специализированные компьютеры, предназначенные для выполнения операций с дисками. Некоторое неудобство может вызвать и изоляция устройств памяти внутри серверного кольца - это создает дополнительную, причем не всегда оправданную нагрузку на серверы.
Альтернативой SAN с ее изоляцией устройств хранения данных от локальной сети является архитектура с использованием памяти, подключаемой непосредственно к локальной сети (Network Attached Storage). В этом случае возможен прямой доступ к устройствам хранения памяти, минуя серверное кольцо. Здесь также обеспечивается гибкость управления дисковой памятью, но за прямой доступ к памяти приходится платить - значительно возрастает нагрузка на сеть.
Еще один вариант организации сетевой памяти связан с концепцией интеллектуального сервера памяти (Intelligent Storage Server). Здесь доступ к данным обеспечивает выделенный сервер, к которому может быть подключено несколько массивов накопителей. Естественно, в этом случае возрастают требования к производительности как сети, так и адаптеров устройств, посредством которых подключаются массивы накопителей, но зато данное решение позволяет сэкономить на покупке новых, более интеллектуальных массивов (или по крайней мере сгладить трудности перехода к ним), если ранее уже было закуплено несколько массивов попроще.