Маскировка LUN на данный момент не поддерживается в продаваемых версиях Windows, причем выпуск Windows Server 2003 не изменил ситуации. Прежде чем приобретать новое программное и аппаратное обеспечение, выясните, какую технологию использует поставщик для реализации маскировки LUN и насколько она подходит для работы в среде Windows.
Сети хранения данных Fibre Channel составляют существенную часть корпоративных подсистем хранения данных. Технология Fibre Channel может внедряться в виде недорогих конфигураций на основе кольца или на базе набирающей популярность топологии коммутируемой связной архитектуры.
Операционная система Windows Server 2003 поддерживает устройства Fibre Channel с помощью драйвера Storport, предоставляемого поставщиком аппаратного обеспечения. Поставщик вместо этого может предоставить ми- ни-драйвер порта SCSI, но в таком случае преимущества драйвера Storport (например, повышенная производительность и обработка ошибок) окажутся недоступными для пользователей. Операционная система Windows 2000 и предыдущие ее версии поддерживают устройства Fibre Channel посредством мини-драйвера SCSIPort, предоставляемого поставщиками аппаратного обеспечения.
Несмотря на то что Windows NT поддерживает технологию маскировки LUN и зонирования, базовая поддержка маскировки LUN в Windows NT отсутствует. Маскировка LUN в Windows NT может быть реализована в драйвере от поставщика аппаратного обеспечения.
Глава 5 Технологии резервного копирования и восстановления данных
Резервное копирование – это процесс создания когерентной (непротиворечивой) копии данных. Резервное копирование становится все более важным на фоне значительного увеличения объема данных в компьютерной индустрии. Некоторые исследования показывают, что в ближайшие несколько лет будет создано больше данных, чем за всю историю человечества! Очень интересно сравнить увеличение емкости подсистем хранения данных с более известным ростом плотности транзисторов в электронных компонентах. Закон Мура гласит, что количество транзисторов на единицу площади электронных микросхем удваивается каждые 18 месяцев. Аналитики предполагают, что рост объемов подсистем хранения данных намного обгоняет закон Мура и объемы хранилищ удваиваются значительно быстрее, чем за 18 месяцев.
Исторически сложилось, что для резервного копирования данных используются накопители на магнитной ленте. Изначально лента считалась более дешевым носителем, чем жесткие диски. Впоследствии возникло мнение, что самыми дешевыми являются оптические носители, но по ряду причин это мнение не нашло практической реализации. Хотя для резервного копирования в основном применяется магнитная лента, обычные жесткие диски также стали популярным средством первичного резервного копирования и зеркального отражения систем. Эта тенденция связана со снижением цен на жесткие диски, что сокращает преимущество накопителей на магнитной ленте в стоимости. Еще одна причина использования жестких дисков – более высокое быстродействие, что приводит к снижению времени обслуживания серверных приложений.
Обратите внимание: и жесткие диски, и ленточные приводы в качестве носителей для резервного копирования обладают определенными преимуществами и недостатками. Несмотря на недостатки, и тот и другой носитель будут использоваться в дальнейшем. Накопители на магнитной ленте обладают высокой емкостью, кассеты можно легко переносить в отдельно расположенный архив или использовать для восстановления после сбоев в работе. После создания первоначальной копии данных на жестком диске вторичное резервное копирование зачастую выполняется с помощью магнитной ленты.
В этой главе рассматриваются технические трудности, которые необходимо преодолеть для обеспечения своевременного резервного копирования и восстановления данных. Здесь также приводится классификация методов восстановления и резервного копирования. Кроме того, описываются возможности Windows Server 2003 по созданию «моментальных снимков» (служба теневого копирования томов) и по работе с сетевым протоколом управления данными (Network Data Management Protocol – NDMP), а также видение компании Microsoft относительно управления подсистемами хранения данных, что будет реализовано в следующих версиях Windows.
5.1 Причины резервного копирования й восстановления данных
Резервное копирование проводится по ряду причин, которые обычно оправдывают инвестиции, вложенные в соответствующее оборудование. Основная цель создания резервных копий – это обеспечение гарантированной доступности данных. Чем важнее постоянный доступ к данным, тем больше инвестиций потребуется. Например, одна из популярных методик резервного копирования заключается в зеркальном копировании дисков, при котором каждая операция записи дублируется для второго диска, что гарантирует доступность данных при отказе в работе первого диска.
Кроме того, архивирование данных проводится для выполнения различных корпоративных требований, при которых данные не должны быть обязательно доступными мгновенно, но могут быть затребованы позднее. В таких случаях доступность данных должна быть обеспечена в течение разумного периода времени, который измеряется в часах, днях или неделях.
Резервные копии иногда используются для перемещения данных, например при создании удаленного центра хранения данных в другом географическом регионе. Такой же причиной будет перенос данных на новое аппаратное обеспечение или, что случается реже, на другую серверную платформу.
5.2 Проблемы при резервном копировании
Перед подробным обсуждением различных способов резервного копирования и восстановления желательно разобраться в проблемах, которые необходимо решить для получения требующегося результата. Далее перечислены основные проблемы.
Сокращение промежутка времени, который называется окном резервного копирования, в течение которого должна быть завершена операция резервного копирования.
Постоянно увеличивающееся количество программных интерфейсов приложений (API), которые должны поддерживаться приложениями резервного копирования.
Невозможность резервного копирования файлов, которые открыты и активно используются приложениями.
Более подробно эти проблемы рассматриваются в разделах 5.2.1–5.2.3.
5.2.1 Время, затрачиваемое на резервное копирование
Исторически сложилось так, что серверные приложения запускались только в рабочее время. Операции резервного копирования соответственно выполнялись в нерабочее время, т.е. ночью, когда работу приложений можно остановить, не оказывая влияния на пользователей. Как только работа приложения прекращена, сервер можно отключить от сети и провести резервное копирование данных. С этим подходом связаны две проблемы.
Значительное увеличение объема данных усложняет завершение резервного копирования в выделенный период времени. Как ни странно, но запись на магнитную ленту в контексте как затрачиваемых машино- часов, так и времени обслуживающего персонала весьма неэффективна. Необходимо найти ленту, вставить ее в накопитель и перемотать на нужную позицию. Как только позиция будет найдена, запись данных на ленту будет проводиться намного медленнее, чем на жесткий диск. Интерфейсы жестких дисков поддерживают запись со скоростью на порядок больше 80 Мбайт/с, а самые быстрые накопители на магнитной ленте поддерживают максимальную скорость передачи 30 Мбайт/с. Для управления несколькими накопителями могут использоваться роботизированные библиотеки, которые весьма недешевы и помогают сократить затраты времени только на поиск и загрузку ленты. Такие библиотеки не в состоянии увеличить скорость чтения данных или их записи на ленту.
Вторая проблема заключает в том, что все больше приложений, а также создаваемые, управляемые и модифицированные ими данные рассматриваются как важные, если не критические, для выживания компании в конкурентной среде. Это означает, что время, в течение которого можно отключить сервер от сети для резервного копирования, сокращается.
5.2.2 Увеличение количества программных интерфейсов приложений
Потребители используют все больше корпоративных приложений, которые очень редко, если это вообще возможно, разрешено останавливать для резервного копирования. По этой причине каждый поставщик приложений предоставляет API для резервного копирования и восстановления файлов с данными приложения. Хотя создание таких API выглядит весьма оптимистично, на самом деле ситуация только ухудшилась.
На рис. 5.1 представлена проблема поддержки все увеличивающегося количества API для резервного копирования и восстановления данных. Как видите, потребители обычно используют несколько приложений, и очень часто применяется несколько версий одного и того же приложения. Каждый поставщик систем резервного копирования должен создавать программный код, использующий API, предоставленный для каждого корпоративного приложения. Поскольку многие поставщики приложений отдельно лицензируют агенты резервного копирования для различных приложений, сам процесс отслеживания лицензий на программное обеспечение и их стоимости может вызвать смятение у менеджера отдела информационных технологий. Более того, следует учесть развертывание инфраструктуры, обучение персонала и четкое выполнение инструкций, необходимых для эффективного резервного копирования.
