- 2834
- 0
- FB2
- ru
- comp_osnet
Серверные технологии хранения данных в среде Windows® 2000 Windows® Server 2003
Введение
Гордон Мур (Gordon Moore), один из основателей компании Intel, однажды заметил, что плотность транзисторов на квадратный дюйм удваивается каждый год. Впоследствии скорость немного снизилась и удвоение стало происходить за полтора года. Если верить аналитикам, развитие индустрии систем хранения данных для предприятий все еще соответствует закону Мура.
Существует предположение, что в течение нескольких следующих лет будет сгенерировано больше данных, чем было создано за всю историю человечества! Не отвлекаясь на детали, можно согласиться, что серверы под управлением операционной системы Windows играют важную роль в индустрии систем хранения данных для предприятий. Таким образом, знание аспектов систем хранения данных на базе Windows оказывается крайне важным, и эта книга представляет собой скромную попытку предоставить необходимые сведения.
Понятия «Windows NT» и «семейство Windows Server» в данной книге равнозначны. Оба термина упоминаются при рассмотрении возможностей, которые доступны одновременно в операционных системах Windows NT 4.0, Windows 2000 и Windows Server 2003. В случае необходимости указывается определенная версия операционной системы, например Windows 2000 или Windows Server 2003.
Книга предназначена для читателей, хорошо знакомых с компьютерными системами и индустрией информационных технологий и желающих расширить познания в области систем хранения данных и архитектуры Windows NT, непосредственно связанной с подобными системами; Другими словами, в книге описываются корпоративные системы хранения данных, в то время как системам потребительского уровня уделяется гораздо меньше внимания. В книге делается попытка поддержать интересы специалистов по программному обеспечению, мало знакомых с технологиями хранения данных, и специалистов по системам хранения данных, которые стремятся получить дополнительные знания по архитектуре обработки и хранения данных в Windows NT.
Еще одна цель книги – донести до читателя мысль, что каждая новая версия операционной системы Windows NT привносит на рынок массу новых возможностей для корпоративных систем хранения данных.
Следует отметить ряд особенностей, касающихся содержания книги.
Удобное изложение информации.
Предоставление подробных сведений с соблюдением прав на интеллектуальную собственность. В книге рассматривается несколько инструментов для разработки программного обеспечения (SDK), которые доступны только после подписания соглашения о неразглашении (nondisclosure agreement – NDA). Таким образом, описание этих инструментов ограничено до информации, которая уже представлена в открытых источниках. Здесь выбран осторожный подход к этому вопросу и приводится только открытая информация, которая, впрочем, тщательно проработана, а к данным, трудным для понимания, добавлены необходимые объяснения.
Предоставление информации о следующих версиях операционных систем Windows NT, а не только устаревших сведений об уже выпущенных системах. Компания Microsoft намерена уделить серьезное внимание реализации поддержки корпоративных систем хранения данных в следующих версиях Windows NT. Безусловно, это несколько рискованный подход, так как планы могут измениться. Поэтому в книге всегда явно указывается, что та или иная описываемая технология относится к будущим версиям Windows NT.
Небольшое отступление. В книге описывается ряд возможностей, которые будут представлены в следующих версиях Windows NT. Компания Microsoft без устали твердит, что гарантированный метод получения информации о возможностях операционной системы – это знакомство с ней после выпуска финальной версии. Хотя такого рода информация широко обсуждается на выставках и семинарах, нет никакой гарантии, что эти возможности вообще появятся в финальной версии. Подобные предположения не должны становиться основой для конкретных планов.
Каждый читатель, который не понял всей серьезности этого предостережения, должен изучить (а не только прочитать) его еще раз.
В начале книги приводится обзор архитектуры Windows NT, включая подсистему ввода-вывода и архитектуру драйверов подсистемы хранения данных. В главе 1 делается попытка кратко изложить огромный объем информации, которая рассматривалась в серии книг Inside Windows NT (издательство Microsoft Press). Глава 1 предназначена для читателей, не имеющих достаточно свободного времени для чтения подобных книг.
В главе 2 описывается технология хранилищ данных, непосредственно подключенных к серверу (direct-attached storage), которая исторически была первой реализацией систем хранения данных.
В главе 3 рассматривается технология NAS (Network-Attached Storage – сетевое устройство хранения данных), которая стала следующим шагом на пути эволюции корпоративных систем хранения данных. Особое внимание уделяется стеку сетевых протоколов Windows NT.
В главе 4 описываются системы SAN (Storage Area Network – сети хранения данных) на основе технологии Fibre Channel. Эта технология продолжает развиваться и по-прежнему составляет конкуренцию таким новшествам, как iSCSI и InfiniBand.
В главе 5 освещаются базовые концепции резервного копирования и восстановления данных. Кроме того, затрагиваются вопросы, связанные с новой службой теневого копирования дисковых томов, которая впервые появилась в операционной системе Windows Server 2003.
В главе 6 рассматриваются файловые системы и виртуализация дисков в контексте Windows NT. Кроме того, описываются кластерные файловые системы.
Глава 7 посвящена управлению системами хранения данных как в рамках общих аспектов, так и в контексте Windows NT.
В главе 8 рассматриваются новые технологии хранения данных (особое внимание уделяется IP-хранилищам, которые являются попыткой связать воедино системы хранения данных и сети на базе протокола IP), а также технология InfiniBand.
В главе 9 описываются методы реализации отказоустойчивых служб (включая защиту и восстановление целостности данных, а также балансировку нагрузки) средствами Windows Server 2003 и Windows 2000 на основе многопортовых парных адаптеров локальной шины (НВА), установленных на серверах Windows NT. Кроме того, приводятся более простые методы обеспечения отказоустойчивости и повышения быстродействия систем, например массивы RAID.
Хотя глава 10 посвящена различным технологиям, она организована в соответствии с разными версиями Windows NT. Независимо от технологий хранения данных, которые рассматриваются в каждой конкретной главе, глава 10 основана на хронологическом порядке появления технологий в операционных системах Windows NT 4.0, Windows 2000, Windows Server 2003. Особое внимание уделяется ожидаемым функциям в следующих версиях Windows.
Надеюсь, книга вам понравится.
Отзывы и предложения присылайте по адресу: dilipnSniriva.com.
Дайлип С. Наик
Редмонд, Вашингтон
dilipn@niriva.com
Благодарности
Предприятие такого масштаба никогда не могло бы быть завершено в одиночку. Я искренне благодарен всем, кто помог мне в этой работе.
Моим редакторам Карен Гетман (Karen Gettman) и Эмили Фрей (Emily Prey). Они постоянно поддерживали мою веру в собственные силы, когда я стремился придерживаться графика и старался передать свои идеи в корректной и доступной форме.
Тому Кларку (Tom Clark), который очень помог при реализации идеи этой книги, а также оказал содействие в других вопросах.
Техническим рецензентам Джеймсу Андерсону (James Anderson), Элен Бек Гарднер (Ellen Beck Gardner), Роберту Грисволду (Robert Griswold), Барине Хаммонд (Varina Hammond),. Милану Мерхару (Milan Merhar), Бобу Сниду (Bob Snead) и Ричарду Вилеру (Richard Wheeler), которые опознали бриллиант в куске необработанной породы и помогали шлифовать его до тех пор, пока он не приобрел вид, вполне отвечающий своему назначению.
Редактору Лори МакГайр (Laurie McGuire).
Редактору тиражирования Стефани Гиберт (Stephanie Hiebert).
Джеффу Голднеру (Jeff Goldner) и Каран Мехра (Karan Mehra) из компании Microsoft, которые предоставили бесценную информацию.
И наконец, но не в последнюю очередь, моей семье: жене Варше (Varsha), которая несколько месяцев мирилась с моей работой за портативным компьютером IBM Thinkpad, сыну Нихару (Nihar) и дочери Рити (Riti), которые терпели странного папу, приносившего портативный компьютер на игры по футболу и бейсболу, а также на практические занятия.
Спасибо всем вам!
Ждем ваших отзывов!
Вы, уважаемый читатель, и есть главный критик и комментатор этой книги. Мы ценим ваше мнение и хотим знать, что было сделано нами правильно, что можно было сделать лучше и что еще вы хотели бы увидеть изданным нами. Нам интересно услышать и любые другие замечания, которые вам хотелось бы высказать в наш адрес.
Мы ждем ваших комментариев и надеемся на них. Вы можете прислать нам бумажное или электронное письмо либо просто посетить наш Web-сервер и оставить свои замечания там. Одним словом, любым удобным для вас способом дайте нам знать, нравится или нет вам эта книга, а также выскажите свое мнение о том, как сделать наши книги более интересными для вас.
Посылая письмо или сообщение, не забудьте указать название книги и ее авторов, а также ваш обратный адрес. Мы внимательно ознакомимся с вашим мнением и обязательно учтем его при отборе и подготовке к изданию следующих книг. Наши координаты:
E-mail:infoQwilliamspublishing.com
WWW:http://www.williamspublishing.com
Адреса для писем: из России:115419, Москва, а/я 783
из Украины:03150, Киев, а/я 152
Глава 1
Знакомство с Windows NT и драйверами устройств хранения данных
В этой главе рассматриваются драйверы устройств Windows NT, драйверы фильтрации и стек драйверов устройств хранения данных для семейства Windows Server. Приведенных сведений достаточно для того, чтобы познакомить неискушенного читателя с особенностями подсистемы ввода-вывода операционной системы Windows NT, а также структуры драйверов устройств хранения данных. Основное внимание уделяется ключевым понятиям, которые широко рассматриваются в книге, например групповому вводу-выводу (multipath I/O), функции SIS (Single Instance Storage) в службах удаленной установки (Remote Installation Services – RIS), точкам переопределения Windows NT (reparse points) и службам удаленного хранения Windows (Remote Storage Services – RSS).
Если быть более точным, то эта глава не предназначена для предоставления всей справочной информации, которая подготовит читателя к самостоятельному написанию драйверов устройств Windows NT. Точно так же глава не содержит полного описания самой операционной системы Windows NT. Читателю рекомендуется использовать справочные материалы, которое указаны в конце книги, чтобы получить достаточный объем знаний о структуре Windows NT для написания различных драйверов, включая драйвера системных фильтров.
Основное внимание в этой главе уделяется Windows NT и архитектуре драйверов в контексте устройств хранения данных. Возможности Windows NT и архитектура драйверов, которые не касаются устройств хранения, если и рассматриваются, то очень кратко.
В разделах 1.1 и 1.2 предоставлена терминология, которая будет часто использоваться на протяжении всей книги. В этих разделах приводятся такие термины, как режим ядра (kernel mode), пользовательский режим (user mode) и контекст процесса (process context). После вступительных разделов в главе рассматривается стек подсистемы хранения данных Windows, включая уровни файловых систем, управления томами, классов и портов. Кроме того, кратко рассматриваются драйверы фильтрации. В завершение приводится описание типичного запроса ввода-вывода, а также рассматривается обработка этого запроса на каждом из уровней стека ввода-вывода подсистемы хранения данных.
1.1 Режимы ядра и пользователя Windows
В этой книге регулярно используются термины режим ядра (kernel mode) и пользовательский режим (user mode). Перед определением этих терминов рассмотрим историю их происхождения.
Система Windows NT проектировалась, как переносимая операционная система, в которой весь код, зависимый от процессора и аппаратного обеспечения, изолирован в модуле, называемом уровнем аппаратных абстракций (hardware abstraction layer – HAL). Этот модуль рассматривается в разделе 1.3.1 далее в главе. Хотя Windows NT действительно раньше поддерживала несколько архитектур центральных процессоров, включая PowerPC и Alpha, современные версии Windows NT поддерживают только процессоры компании Intel и совместимые с ними модели (например, компании AMD). Некоторые базовые особенности архитектуры процессоров Intel рассматриваются далее в этом разделе, причем вместо описания всех возможностей архитектуры х86 затрагиваются лишь наиболее важные аспекты.
Архитектура Intel х86 поддерживает четыре режима работы: реальный[1], виртуальный х86, управления системой и защищенный.
В реальном режиме (real mode) каждый системный процесс имеет неограниченный доступ к первому мегабайту оперативной памяти. При загрузке процессор всегда запускается в реальном режиме. Процессор можно переключить в защищенный режим, установив соответствующий флаг в управляющем регистре; для обратного переключения флаг нужно сбросить. Реальный режим используется для инициализации Windows NT, однако переключение в защищенный режим происходит задолго до запуска приложений. В процессе развития семейства продуктов Windows NT роль реального режима становится все менее значимой. Как только процессор переключается в защищенный режим работы, Windows NT больше не переходит в реальный режим.
Виртуальный режим х86 (virtual х86 mode) предоставляет возможность выполнять несколько приложений реального режима, когда процессор работает в защищенном режиме. Операционная система Windows NT 4.0 поддерживает этот режим с помощью подсистемы NT Virtual DOS Machine
Рис. 1.1. Уровни привилегий архитектуры Intel х86
(NTVDM). Необходимость запуска приложений DOS под управлением Windows NT возникает все реже и реже, поэтому роль подсистемы NTVDM со временем становится все менее важной.
Защищенный режим (protected mode) представляет собой основной режим Windows NT. Он обладает четырьмя рабочими уровнями (рис. 1.1). Ha. уровне 0 (или кольце 0). который чаще всего называется режим ядра (kernel mode), доступны инструкции процессора и функции для обеспечения защиты памяти и работы с виртуальной памятью. Кроме того, на уровне 0 доступны привилегированные инструкции, например для управления регистрами процессора. Операционная система Windows NT не использует уровни (кольца) 1 и 2. Самый нижний уровень привилегий – уровень 3, или пользовательский режим (user mode). – обеспечивает наилучшую защиту, предотвращая доступ системных процессов к коду и памяти другого процесса.
Далее представлены некоторые функциональные возможности Windows NT для архитектуры х86.
Всей памятью можно управлять (выделять, считывать и записывать) посредством логических единиц, которые называются страницами. Дополни тельная информация приводится в разделе 1.3.3.6.
Каждая страница памяти имеет связанный с ней тег, который определяет возможность чтения или записи этой страницы, а также уровень привилегий, необходимых для чтения и записи. Эта возможность предназначена для защиты пользовательских процессов друг от друга и для защиты системных кода и данных от пользовательских процессов. Обратите внимание, что системный код, выполняемый в режиме ядра, не защищен от другого кода, который выполняется в режиме ядра.
■ Страницы памяти, которые содержат код (в отличие от данных), могут быть отмечены как предназначенные только для чтения пользовательскими процессами и кодом на уровне ядра.
Приложения, которые выполняются в пользовательском режиме, получают доступ к службам ядра Windows NT, вызывая специальные инструкции, допускающие управляемый переход в режим ядра и обратно в пользовательский режим, как только запрос в режиме ядра будет выполнен.
1.2 Процесс, контекст процесса и потоки
Процесс – это образ выполняемой программы в памяти. Процессу назначается область памяти до окончания его работы. Процесс может совместно использовать код (динамически подключаемые библиотеки) или данные (области совместно используемой памяти) с другим процессом. Процесс описывается объектом процесса, который поддерживается диспетчером объектов. В объекте процесса содержится информация о виртуальном адресном пространстве процесса, приоритете процесса, а также дескрипторы файлов и информация о выделении памяти. В объекте процесса хранятся и другие параметры, которые здесь не рассматриваются.
В Windows NT несколько процессов могут существовать одновременно; но только один процесс выполняется центральным процессором в определенный момент времени. Обратите внимание: драйверы вообще и драйверы систем хранения данных в частности не создают собственных процессов. Операционная система создает несколько процессов для своих нужд, а также определенные процессы в ответ на пользовательские команды, например когда пользователь запускает приложение, такое, как Microsoft Word или Microsoft Excel. Если драйвер вызывается во время работы процесса, считается, что он работает в контексте вызывающего процесса.
Контекст процесса можно обозначить как всю служебную информацию, необходимую для отслеживания работы процесса. К этой информации относятся виртуальная память процесса, значения регистров центрального процессора, различные дескрипторы файлов и объектов, а также различные маркеры безопасности, связанные с процессом. Контекст процесса исключительно важен, так как множество структур данных и ресурсов, таких, как дескрипторы файлов и указатели памяти, действительны только для данного процесса. Например, дескриптор файла, созданный в одном процессе, недействителен в другом процессе.
Поток – это структурная единица процесса; процесс может содержать один или несколько потоков. Поток совместно использует глобальные структуры данных и адресное пространство процесса, но при этом имеет собственные данные. Переключение между процессами – задача весьма трудоемкая, которая включает в себя сохранение состояния процессора в специальной структуре данных, зависящей от процесса, и-изменение регистров управления памятью и процессором. Переключение между потоками осуществляется намного быстрее, поскольку требует сохранения гораздо меньшего объема данных.
Каждый поток связан с объектом потока, поддерживаемым диспетчером объектов. Информация, которая содержится в объекте, включает в себя данные о первичном центральном процессоре в многопроцессорных системах, состояние потока (т.е. выполняется ли поток, или готов к выполнению, или заблокирован в процессе ввода-вывода), а также другие параметры потока.
Поток может работать в пользовательском режиме и в режиме ядра. Потоки в режиме ядра могут создаваться только структурами, работающими в этом режиме, например драйверами устройств, и они всегда выполняются в режиме ядра. Потоки пользовательского режима обычно выполняются именно в этом режиме, кроме тех случаев, когда это происходит в режиме ядра после запроса к службе Windows NT, как уже отмечалось в разделе 1.1.
1.3 Архитектура Windows NT
Операционная система Windows NT проектировалась как модульная, многоуровневая архитектура, поддерживающая расширения за счет добавление новых функций. Архитектура позволяет добавлять поддержку новых устройств и новых возможностей, например шифрующей файловой системы (EFS). Архитектура системы позволяет добавлять поддержку приложений, которые основаны на других операционных системах, например OS/2 или POSIX. Конечно, обе эти системы более важны с исторической точки зрения, но они являются хорошим примером мЬдульной расширяемой архитектуры.
На рис. 1.2 показана высокоуровневая архитектура Windows NT. Как уже отмечалось во вступительном разделе, термин Windows NT используется для описания всех версий операционной системы Windows, основанных на технологии NT. В это семейство входят Windows NT 3. x, Windows NT 4.0, Windows 2000,' Windows XP и Windows Server 2003.
Далее в этом разделе рассматриваются различные компоненты, показанные на рис. 1.2. Обратите внимание на линию, которая разделяет режим ядра и пользовательский режим. Важнейшие различия между этими режимами уже рассматривалась ранее в главе.
Рис. 1.2. Архитектура Windows NT
Режим ядра содержит все привилегированные процессы, которые выполняются на уровне 0 архитектуры Intel х86. Режим ядра Windows NT состоит из трех основных подсистем.
Уровень аппаратных абстракций?
Ядро Windows NT.
Выполняемый модуль Windows NT.
В следующих трех разделах эти компоненты рассматриваются более подробно.
Уровень аппаратных абстракций (Hardware Abstraction Layer – HAL) обеспечивает защиту данных за счет управления доступом к аппаратным ресурсам. Это единственный модуль операционной системы Windows NT, который содержит код, зависящий от аппаратного обеспечения (или от архитектуры процессора). Кроме того, для написания уровня аппаратных абстракций иногда применяется язык ассемблера. В целом уровень аппаратных абстракций предоставляет дополнительный уровень абстракции компонентам более
высокого уровня. Это позволяет создавать высокоуровневые компоненты, не зависящие от аппаратной архитектуры. Ниже описаны функциональные возможности, которые цредоставляет уровень аппаратных абстракций.
Интерфейс службы таймера, благодаря которому выполняемый модуль Windows NT абстрагируется от функций аппаратного обеспечения таймера нижнего уровня.
Поддержка ввода-вывода в контексте системной шины и прямого доступа к памяти (direct memory access – DMA). Уровень аппаратных абстракций выполняет трансляцию данных между внешней шиной и информацией об адресации Windows NT. Кроме того, предоставляется поддержка для информации о конфигурации шины.
Поддержка прерываний путем связывания (отображения) внешних прерываний с запросами прерываний (IRQ) Windows NT. Кроме того, предоставляется маскировка/демаскировка служб для прерываний.
Ядро Windows NT представляет собой следующий уровень после уровня аппаратных абстракций, который обеспечивает работу выполняемого модуля Windows NT (рассматривается в разделе 1.3.3) и других подсистем. Ядро системы выполняет следующие основные функции:
помощь в синхронизации данных;
планирование выполнения потоков и процессов;
управление прерываниями и исключениями;
восстановление системы после аварийных ситуаций, например после отказа питания.
Данные ядра всегда находятся в оперативной памяти и никогда не выгружаются на диск, как это происходит с пользовательскими приложениями. Данные ядра не могут быть вытеснены другими данными. Это значит, что выполнение кода ядра не может быть прервано ради другого кода, если только ядро не выполняет это самостоятельно. Ядро представляет собой объектно- ориентированную систему, в которой используется два класса объектов.
1. Объекты-диспетчеры, которые позволяют управлять потоками и процессами и применяются для синхронизации различных потоков/процессов. В число объектов-диспетчеров входят мьютекс-флаги (mutex – это сокращение от «mutual exclusion», т.е. взаимное исключение), семафоры (semaphore) и таймеры (timer). Мьютекс-флаги являются объектами синхронизации и используются для синхронизации данных между двумя компонентами.
2. Объекты управления, например асинхронные вызовы процедур (asynchronous procedure calls – АРС) и процедуры обслуживания прерываний (interrupt service routines – ISR), которые рассматриваются более подробно в разделах 1.5.1 и 1.5.3.
Выполняемый модуль (Windows NT Executive) обеспечивает работу ключевых функций, включая программные интерфейсы приложений (API), которые позволяют потокам из пользовательского режима в Windows NT взаимодействовать с ядром Windows NT для запроса на предоставление услуг. Как и ядро Windows NT, выполняемый модуль не может быть выгружен из памяти. Модуль управляет несколькими операциями, включая ввод-вы- вод данных, поддержку работы системы безопасности, межпроцессное взаимодействие, управление памятью и процессами, поддержку интерфейса Plug and Play, управление питанием, файловыми системами, объектами и графическими устройствами. Весь выполняемый модуль Windows NT размещен в одном файле – ntoskrnl. exe. Для выполнения задач модуля создается лишь несколько потоков. Обычно системный процесс из пользовательского режима запрашивает запуск службы, и модуль будет выполняться в контексте запросившего процесса. Примером потока, который создается выполняемым модулем, может служить поток сброса страниц на диск.
Выполняемый модуль Windows NT, в свою очередь, содержит следующие компоненты:
• диспетчер объектов;
• монитор ссылок безопасности;
• диспетчер процессов;
• подсистема Plug and Play;
• диспетчер энергопитания;
• диспетчер виртуальной памяти;
• диспетчер кэша.
Диспетчер объектов (Object Manager) Windows NT предоставляет свои услуги другим компонентам Windows NT, включая непосредственно выполняемый модуль (элементом которого диспетчер и является). Диспетчер объектов предоставляет службы для именования, создания, удаления, манипулирования и совместного использования объектов. Он активно сотрудничает с монитором ссылок безопасности, чтобы обеспечить соответствующий доступ к определенным объектам только пользователям и процессам с достаточными разрешениями. Соответствующий означает, что предоставляется доступ определенного типа, например доступ только для чтения. Каждый объект, созданный диспетчером объектов, имеет связанный с ним список управления доступом (access control list – ACL). На самом деле этот список представляет собой группу объектов, которые указывают разрешения, явно или неявно предоставленные пользователю или группе; кроме того, в список управления доступом могут входить объекты, ограничивающие права доступа для данного пользователя или группы.
Диспетчер объектов назначает дескриптор каждому созданному объекту. При этом обеспечивается уникальность дескрипторов и предоставляется возможность преобразования дескриптора в ссылку на уникальный объект. Но клиенты диспетчера объектов используют дескриптор в виде «непрозрачного» маркера без внутренней структуры. К объектам, с которыми работает диспетчер, относятся файлы, каталоги, порты, процессы, потоки, семафоры и объекты событий.
Монитор ссылок безопасности (Security Reference Monitor) заведует проверкой доступа и протоколированием ресурсов. Проверка доступа выполняется на самом низком уровне, включая не только предоставление доступа, но и определение его типа, например доступ только для чтения или доступ для чтения и записи. Функциональность подсистемы безопасности обеспечивается объектно-ориентированной структурой Windows NT. При предоставлении доступа к объекту монитор ссылок безопасности сравнивает список управления доступом, который связан с объектом, с маркером (token) безопасности процесса перед тем, как предоставить или запретить доступ. Списки управления доступом бывают двух типов: явно или неявно разрешающие или запрещающие доступ. Монитор ссылок безопасности активно используется другими подсистемами выполняемого модуля Windows NT, например диспетчером объектов.
Кроме того, монитор ссылок безопасности предоставляет приложениям пользовательского режима услуги, аналогичные описанным. Монитор обеспечивает возможность генерации маркеров (на уровне процесса), которые могут использоваться для проверки безопасности и разрешений доступа, а также для генерации журналов аудита.
Диспетчер процессов (Process Manager) обеспечивает создание и удаление процессов и потоков, а также управление ими. Диспетчер не поддерживает иерархию компонентов; например, отношения между процессами вида «родитель-потомок» не отслеживаются. Эта работа ложится на компонент, который создал процесс. По аналогии представьте диспетчер файлов, который предоставляет возможность создания файла, однако внедрением этого файла в структуру каталогов должен заниматься пользователь диспетчера файлов. Диспетчер процессов пользуется услугами как диспетчера объектов, так и подсистемы безопасности. Для каждого запущенного процесса передается, как минимум, два вызова диспетчеру процессов: первый вызов для создания процесса, второй – для создания потока в пределах процесса, так как каждый процесс должен содержать хотя бы один поток.
На рис. 1.2 управление питанием и подсистема Plug and Play схематически размещены в едином прямоугольнике, что сделано для упрощения структуры диаграммы. На самом же деле это различные подсистемы, хотя и тесно взаимодействующие друг с другом.
Термин Plug and Play используется для описания программно и аппа- ратно реализованных функциональных возможностей, которые позволяют Windows динамически распознавать аппаратное обеспечение и реализовать программную поддержку для корректной работы устройства. В частности, это программное обеспечение отвечает за выполнение следующих функций:
корректное определение аппаратного обеспечения;
корректное определение динамического подключения или отключения аппаратного обеспечения;
выделение и настройка ресурсов для работы аппаратного обеспечения;
поиск и загрузка драйверов устройств;
поддержка механизма уведомления, с помощью которого определяется появление и удаление аппаратного обеспечения; этот механизм может использоваться программным обеспечением как в режиме ядра, так и в пользовательском режиме.
Подсистема Plug and Play включает в себя компоненты пользовательского режима и режима ядра. Компонент пользовательского режима предоставляет приложениям метод управления аппаратными устройствами, включая механизмы регистрации, через которые приложения уведомляются о появлении и удалении устройств.
Подсистема Plug and Play играет очень важную роль в обнаружении устройств, присвоении устройствам идентификаторов, инициализации и добавлении/удалении устройств. В частности, Plug and Play отвечает за генерацию пакета запроса ввода-вывода (I/O request packet – IRP), который называется IRP_MN_QUERY_DEVICE_RELATIONSHIPS и передается драйверам шины. Этот пакет запроса ввода-вывода в презентациях Microsoft называется QDR. Пакет QDR применяется для перечисления устройств и создания стека устройств. Драйверы фильтрации иногда создаются для отслеживания функций QDR и исправления создаваемого списка устройств. В главе б рассматривается диспетчер разделов (Partition Manager), который обеспечивает подобные возможности в качестве драйвера фильтрации.
Диспетчер энергопитания (Power Manager) играет важную роль в предоставлении энергосберегающих функций, таких, как снижение оборотов вращения жестких дисков, накопителей для компакт-дисков и DVD, а также отключение питания мониторов и видеоадаптеров. Очевидно, что управление питанием гораздо важнее для портативных компьютеров, чем для серверов, но даже для серверов управление питанием применяется при обслуживании устройств, поддерживающих «горячую» замену, и при управлении устройствами резервного питания. Диспетчер энергопитания предоставляет интерфейс API для приложений более высокого уровня.
Диспетчер виртуальной памяти (Virtual Memory Manager – VMM) предоставляет функции управления памятью, благодаря которым процессы могут использовать объем памяти, превышающий размер физической памяти, установленной на компьютере. Запросы приложений на выделение памяти регистрируются диспетчером виртуальной памяти. Если осталось недостаточно памяти, диспетчер виртуальной памяти переместит страницы памяти на жесткий диск, чтобы предоставить место для нового приложения. Если приложение стремится получить доступ к странице, которая отсутствует в физической памяти, диспетчер виртуальной памяти освобождает пространство в памяти перед перемещением страниц с диска в физическую оперативную память. Этот метод получил название подкачки страниц (paging).
Область диска, которая используется для хранения страниц, не размещенных в физической памяти, называется файлом подкачки (swap file). Операционная система автоматически создает этот файл и обеспечивает его защиту. Администратор может изменять размер файла подкачки, который иногда называется страничным файлом, так как память перемещается в файл и из него страничными блоками.
В Windows NT 4.0 поддерживалось адресное пространство объемом 4 Гбайт, которое поровну распределялось между пользовательским режимом и режимом ядра. Верхние 2 Гбайт выделялись режиму ядра Windows NT, а нижние 2 Гбайт – пользовательскому режиму. В Windows 2000 Advanced Server параметры загрузки позволяют перераспределить адресное пространство, выделив 1 Гбайт режиму ядра и 3 Гбайт пользовательскому режиму. Приложения пользовательского режима следует переписать для использования дополнительного объема адресного пространства. Конечно, для 64-разрядной версии Windows NT подобного ограничения просто не существует.
Диспетчер виртуальной памяти предоставляет программные интерфейсы приложений для выделения и высвобождения памяти, а также для блокировки и разблокировки памяти. Функция блокировки памяти позволяет запретить выгрузку области памяти в файл подкачки. Эта функция зачастую ошибочно воспринимается в качестве запрета на изменение физического расположения участка памяти. Хоть это и справедливо для нынешних версий Windows NT, ситуация может измениться в будущих версиях Windows. Посредством описываемого API драйверы по мере необходимости запрашивают выгружаемую или невыгружаемую память.
Это неотъемлемый элемент подсистемы ввода-вывода, который работает в тесной связке с драйверами файловых систем и диспетчером виртуальной памяти. Диспетчер кэша Windows NT взаимодействует с файловой системой и ее драйверами. Подобный метод отличается от стратегии кэширования, свойственной Windows 95, которая предназначалась для взаимодействия непосредственно с дисковыми секторами. Диспетчер обслуживает все файловые системы, локальные и удаленные, с помощью единого кэша. Диспетчер кэша позволяет кэшировать несколько потоков данных из одного файла. Потоки данных относятся к возможностям файловой системы NT (NTFS) и рассматриваются в главе 6.
Весь процесс файлового ввода-вывода данных можно рассматривать как страничный ввод-вывод, что связано с особенностями взаимодействия диспетчера кэша и диспетчера виртуальной памяти. При запросе операции файлового ввода-вывода файловая система сначала обращается к диспетчеру кэша для получения необходимых данных. Если диспетчер кэша обнаруживает, что необходимые данные недоступны, запрос отправляется драйверу файловой системы для считывания данных. В результате получается замкнутый круг, так как файловая система запрашивает страницы у диспетчера кэша, а диспетчер кэша, в свою очередь, запрашивает страницы у файловой системы. Но при этом диспетчер кэша различными способами регистрирует ввод- вывод данных, в результате чего файловая система больше не пытается повторно получить кэшированные данные.
Подсистема ввода-вывода отвечает за обработку запросов ввода-вывода и проектировалась для выполнения перечисленных далее задач.
Обеспечение работы сверхпроизводительных операций ответного ввода- вывода для одно- и многопроцессорных компьютеров.
Предоставление асинхронного ввода-вывода. Синхронный ввод-вывод осуществляется, по сути, в виде асинхронного запроса ввода-вывода, пс!>сле которого следует блокирующее ожидание завершения операции ввода-вывода.
Поддержка нескольких файловых систем, в частности CDFS, NTFS и UDFS.
Предоставление модульной архитектуры, поддерживающей добавление новых файловых систем и устройств.
Предоставление устройствам (и их драйверам) возможности подключения и отключения «на лету», без Перезагрузки (эта функция реализована в Windows 2000 и более новых версиях Windows NT).
Предоставление расширенных возможностей, например кэширования и записи содержимого файлов в память (запись содержимого файла в указанной области памяти в адресном пространстве процесса). Для получения доступа или модификации содержимого файла приложение выполняет чтение и запись определенной области адресного пространства.
Защита ресурсов, которые совместно используются несколькими процессами.
Подсистема ввода-вывода имеет модульную структуру (как и все остальные компоненты Windows NT) и состоит из следующих компонентов:
программный интерфейс приложений ввода-вывода (I/O API);
диспетчер ввода-вывода;
драйверы файловых систем;
другие драйверы (например, драйверы клавиатуры и драйверы дисков).
Далее эти модули рассматриваются более подробно.
По сути, этот компонент включает функции диспетчера ввода-вывода, предназначенные для более высоких уровней Windows NT, а также компоненты режима ядра, выполняющие операции, связанные с диспетчером печати. Все имена функций программного интерфейса приложений ввода-вывода имеют вид IoXXXX, где ХХХХ – строка, после которой указывается список параметров. (Подробная информация приводится в программном инструментарии для разработки драйверов.) В качестве примера функций API можно привести:
интерфейс IoCreateDevice, предназначенный для создания новых объектов устройств (объекты устройств рассматриваются в разделе 1.4.2);
интерфейс IoCallDriver, предназначенный для отправки драйверу пакета запроса ввода-вывода (пакеты запроса ввода-вывода рассматриваются в разделе 1.4.3).
Это элемент выполняемого модуля Windows NT; свойственные ему функции перечислены ниже.
Создание пакетов. запроса ввода-вывода (IRP) и направление их соответствующему драйверу, а также перенаправление пакетов запроса ввода-вывода между драйверами.
Удаление и освобождение пакетов запроса ввода-вывода после завершения операции ввода-вывода.
Взаимодействие с диспетчером кэша и другими компонентами NT Executive.
Взаимодействие с диспетчером виртуальной памяти для предоставления файловым системам функций ввода-вывода с записью данных в память.
Мониторинг загруженных файловых систем и их вызов по требованию.
Предоставление поддержки синхронного и асинхронного ввода-вывода. Асинхронный ввод-вывод особенно важен для приложений хранения данных. Например, приложение резервного копирования может использовать асинхронный ввод-вывод для размещения в очереди нескольких запросов, что позволяет полностью загрузить устройство записи на ленту.
Управление буферами для операций ввода-вывода.
Операционная система предоставляет функции файловых систем с помощью драйверов режима ядра. Система Windows NT поставляется вместе с такими файловыми системами:
NTFS (файловая система NT);
UDFS (универсальная дисковая файловая система);
CDFS (файловая система компакт-дисков);
FAT (таблица размещения файлов).
Драйверы сетевых файловых систем рассматриваются в главе 3. Драйверы файловых систем реализуются средствами инструментария разработки драйверов Windows NT (Windows NT DDK) и дополнительного программного продукта, который предлагается компанией Microsoft – Windows NT Installable File System Kit. Этот инструментарий содержит документацию для различных программных интерфейсов приложений, которые понадобятся при создании драйверов файловой системы, а также пример кода, предназначенного для реализации файловых систем FAT и UDFS.
Драйверы файловой системы аналогичны другим драйверам, поскольку взаимодействуют с диспетчером ввода-вывода и IRP. Драйверы файловой системы являются логическими, так как не взаимодействуют непосредственно с аппаратным обеспечением; например, файловая система не делает различия между дисками с интерфейсом SCSI и с интерфейсом АТА (иногда называемым IDE). Тем не менее драйверы файловой системы отличаются от других драйверов. Некоторые из этих отличий приведены ниже.
Драйверы файловой системы всегда вызываются в контексте потока, запрашивающего операцию ввода-вывода.
Драйверы файловой системы активно взаимодействуют с диспетчером кэша и диспетчером виртуальной памяти, используя эти два компонента для буферизации данных. Например, файловая система использует услуги диспетчера кэша для кэширования метаданных файловой системы (это может быть расположение файлов и каталогов на диске), чтобы избежать повторных запросов одних и тех же метаданных.
Драйверы файловой системы являются единственными драйверами, которые обеспечивают работу методов ввода-вывода на основе IRP. Подобный метод называется быстрым вводом-выводом (Fast I/O) и представляет собой несколько входных точек драйвера. Диспетчер ввода-вывода вызывает эти точки для выполнения операций ввода-вывода, поскольку данные могут быть кэшированы и поэтому быстро обработаны. Драйвер файловой системы может завершить вызов неудачно, если это необходимо, а диспетчер ввода-вывода просто повторит тот же запрос ввода- вывода с помощью обычного пакета IRP.
Понятие драйверов фильтров файловых систем тесно связано с понятием драйверов файловых систем. Драйверы фильтрации файловых систем используются для реализации широкого диапазона различных технологий, например шифрованной файловой системы (EFS) и поддержки служб удаленного хранения (RSS).
Поскольку эта книга посвящена корпоративным системам хранения данных, на рис. 1.2 графическая подсистема демонстрируется в режиме ядра, хотя некоторая область подсистемы также представлена и в пользовательском режиме. В Windows 2000 для повышения производительности значительный объем кода графической подсистемы был перемещен из пользовательского режима в режим ядра. В данном случае к понятию «графическая подсистема» относится весь программный код, предназначенный для обработки оконного интерфейса и поддерживающий видеоустройства, сканеры, принтеры и т.д.
Это наиболее важный компонент Windows NT, особенно для программистов. На основе программного интерфейса Win32 создаются другие подсистемы, такие, как POSIX.
Программный интерфейс приложений Win32 можно разделить на три категории.
1. Обработка оконного интерфейса и API для сообщений оконного интерфейса реализованы в виде динамически подключаемой библиотеки user32. dll. Эта библиотека подключается приложениями, использующими интерфейсы, которые предоставляются этим файлом. При этом несколько приложений во время работы задействуют только одну копию библиотеки.
2. Графический API реализован в виде динамически подключаемой библиотеки gdi32. dll. В версиях Windows NT до Windows 2000 библиотека gdi32. dll являлась клиентом, подключаемым к серверному процессу Win32 (рассматривается далее), так как соответствующие функции были реализованы в серверном процессе. А сервер Win32, в свою очередь, вызывал компонент режима ядра для графической подсистемы. В Windows 2000 библиотека gdi32. dll вызывает этот компонент без посредников.
3. Базовые API, например функции открытия файла (CreateFile), чтения файла (ReadFile) и записи файла (WriteFile), реализованы в динамически подключаемой библиотеке, которая называется ntdll.dll. При необходимости эта библиотека делает вызовы к выполняемому модулю Windows в режиме ядра. Для этого библиотека использует одно из 256 прерываний, поддерживаемых архитектурой Intel х86. В частности, используется прерывание 46 (десятичный номер 46, шестнадцатеричный – 0х2Е). Обработчик прерывания[2] идентифицирует как запрошенный API (выполнив поиск по таблице), так и передаваемые ему параметры. Если все параметры прошли проверку, обработчик вызывает соответствующую подсистему выполняемого модуля Windows для выполнения запрошенной операции.
Приложения, написанные на основе API Win32 и других механизмов поддержки, рассматриваются в документации SDK. В некотором смысле даже подсистема POSIX представляет собой инструмент, разработанный для поддержки приложений UNIX. Хотя подсистема POSIX в настоящий момент существенной роли уже не играет, она все еще служит хорошим примером модульной и расширяемой архитектуры Windows NT.
1.4 Структуры данных, связанные с драйверами устройств Windows
Перед подробным рассмотрением драйверов устройств Windows NT стоит разобраться в некоторых важных структурах данных, которые используются этими драйверами. Каждый драйвер Windows, включая драйверы устройств хранения данных, должен взаимодействовать с тремя основными типами объектов: объектами драйверов, объектами устройств и пакетами запроса ввода- вывода (IRP). Эти объекты и рассматриваются в данном разделе.
Объект драйвера создается выполняемым модулем Windows NT при загрузке драйвера. Объект драйвера выделяется из невыгружаемой памяти. Он содержит важную информацию, например таблицу вызовов драйвера, которая, в свою очередь, содержит адреса для различных процедур драйвера. Каждый драйвер, даже если он управляет несколькими устройствами, представлен только одним объектом. Кроме того, когда драйвер обрабатывается несколькими ЦПУ в многопроцессорной системе Windows NT, в памяти присутствует только один объект драйвера. Хотя объект драйвера создается выполняемым модулем Windows NT, обязанность по внесению определенной информации, например адресов процедур в таблицу вызовов драйвера, возлагается на создателя драйвера. Это требование относится только к драйверам, которые экспортируют объект драйвера; таким образом, мини-драйверы, которые зависят от классов или портов объекта драйвера, не обязаны предоставлять описываемую информацию об объекте.
Объект устройства представляет собой физическое устройство ввода- вывода (т.е. шинный адаптер, диск или привод на магнитных лентах) или логическое устройство (например, драйвер антивирусного фильтра). Каждое устройство может быть представлено только одним объектом устройства. Объект устройства содержит указатель на объект драйвера, который управляет обработкой устройства. Кроме того, объект устройства описывает физические характеристики устройства, например наибольший объем ввода- вывода данных, выполняемый за одну операцию, или компонент, посредством которого выравнивается буфер, предоставляемый устройству.
Три типа объектов устройства имеют одинаковую структуру, однако различаются расширениями и методами использования. Эти объекты описаны ниже.
Объект физического устройства (physical device object – PDO) представляет собой устройство, подключенное к шине и обычно создается драйвером шины (драйверы шины рассматриваются в разделе 1.7.1). Объект физического устройства должен поддерживать связь с устройством. Такой объект должен хранить статус энергопитания устройства и идентификатор устройства, например идентификатор шины SCSI, целевой идентификатор SCSI и номер логической единицы (LUN) SCSI. Эти термины более подробно рассматриваются в главе 2. На данный момент достаточно сказать, что для уникальной идентификации устройства SCSI необходимо указать три значения: идентификатор шины, целевой идентификатор и идентификатор LUN.
Объект функционального устройства (functional device object – FDO) обычно создается драйвером класса или драйвером порта (драйверы классов и портов рассматриваются в разделах 1.7.2 и 1.7.3). Использование устройства требует наличия объекта функционального устройства. В качестве примера данных, которые содержатся в объекте функционального устройства, можно указать элементы архитектуры диска, например таблицу разделов диска или в контексте привода DVD информацию о регионе DVD.
Рис. 1.3. Архитектура объекта устройства Windows NT
3. Объект фильтра устройства (filter device object – DO) представляет собой устройство для драйвера фильтра.
На рис. 1.3 демонстрируются основные структурные элементы объекта драйвера.
К важным элементам объекта драйвера относится таблица вызовов. В ней определены различные стандартные функции, которые реализуются драйвером устройства. В зависимости от конкретной структуры драйвера, некоторые из этих функций должны быть реализованы в обязательном, а некоторые – в произвольном порядке. На рис. 1.3 показаны только функции Read, Write и DeviceIoControl, однако существует и множество других. Для получения дополнительной информации можно обратиться к инструментарию разработки драйверов Windows.
Устройства, функции которых реализуются с помощью драйвера, описываются посредством объектов устройств (PDO, FDO и DO). Все устройства представлены в связном списке. Заголовок связного списка хранится в объек-
те драйвера, что демонстрируется в нижней левой области рис. 1.3. Обратите внимание, что указатель на объект драйвера в объекте устройства позволяет просмотреть структуру данных, найти объект драйвера и вызвать соответствующую функцию по таблице вызовов.
Для взаимодействия с драйверами режима ядра многоуровневая операционная система Windows NT использует интерфейсы на основе пакетов данных. Пакеты, которые используются для связи с драйверами, называются пакетами запроса ввода-вывода (I/O request packets – IRP). К драйверу может подключаться другой драйвер или подсистема ввода-вывода.
Пакеты IRP выделяются в невыгружаемой памяти – важнейшем системном ресурсе. Пакеты запроса ввода-вывода выделяются и поддерживаются в очереди, связанной с определенным потоком. Операционная система Windows NT поддерживает готовность к работе некоторого количества пакетов IRP, размещенных в выделенном[3] списке, что позволяет после запроса быстро назначать пакеты драйверу или диспетчеру ввода-вывода.
На рис. 1.4 показано, что пакет запроса ввода-вывода имеет заголовок фиксированного размера и непостоянное количество элементов стека ввода- вывода. Элементы стека ввода-вывода представляют структуры данных для отдельных драйверов, которые будут обрабатывать IRP. Таким образом, каждый драйвер, который обрабатывает пакет запроса ввода-вывода, получает закрытую область данных в стеке пакета. При выделении и отправке пакета драйверу требуется формирование стека достаточного объема для каждого драйвера, который будет обрабатывать пакет. Если драйвер попытается получить доступ к несуществующему элементу стека IRP, это может привести к появлению ошибок в работе системы. Таким образом, пакет запроса ввода- вывода, который может использоваться для одной цепи стека драйвера, не всегда подходит для другой цепи этого стека.
На рис. 1.4 демонстрируется, что заголовок пакета запроса ввода-вывода содержит различные поля данных, перечисленные ниже.
Тип запроса (синхронный или асинхронный).
Тип операции запроса (операция страничного ввода-вывода или операция, выполняемая без промежуточного кэширования).
Указатель на буфер для операции ввода-вывода.
Рис. 1.4. Структура пакета запроса ввода-вывода
Статус блока ввода-вывода, который представляет состояние пакета запроса ввода-вывода. Этот статус меняется при обработке пакета различными драйверами.
Информация, необходимая для обработки отмены IRP в случае отмены операции ввода-вывода, указанной в пакете (например, после достижения тайм-аута или по команде пользователя, который решил, что операция выполняется слишком долго).
Указание области возникновения запроса ввода-вывода (в пользовательском режиме или режиме ядра).
Кроме того, на рис. 1.4 показано, что каждый элемент стека содержит информацию, относящуюся к конкретному драйверу. Ниже приведено несколько примеров информации, которая содержится в элементе стека.
Код основной функции (чтение, запись и операция по управлению устройством).
Код вторичной функции, который уточняет необходимое действие и применяется только вместе с соответствующим кодом основной функции.
Параметры функции, например параметры управления устройством.
Указатель на объект файла.
Структура пакета запроса ввода-вывода содержит элемент, указывающий на текущий элемент» стека пакета. Драйвер отвечает за изменение значения этого элемента перед передачей пакета следующему драйверу в цепочке драйверов. Каждый активный пакет запроса ввода-вывода размещается в очереди, связанной с потоком, который содержит пакеты запроса ввода-вывода, связанные с вводом-выводом, запрошенным этим потоком.
В ответ на полученные пакеты драйвер может создавать вторичные пакеты IRP, которые могут обрабатываться одновременно, имитируя параллельную обработку. Это позволяет ускорить обработку ввода-вывода данных. Конечно, в этом случае существуют определенные ограничения: например, операция записи на ленту не может быть разделена на несколько параллельных операций.
1.5 Структура драйвера устройства Windows
Все драйверы устройств Windows имеют одинаковую структуру. Каждый драйвер имеет объект драйвера, который создается диспетчером ввода-вывода при загрузке драйвера. В разделе 1.4 представлены структуры данных, которые относятся к драйверам устройств, в том числе и объекты драйверов. В этом разделе описываются процедуры, реализуемые драйвером, а также другие характеристики драйвера устройства хранения данных.
Драйвер устройства Windows реализует множество стандартных процедур, причем некоторые из них обязательны для выполнения, а некоторые – нет, что зависит от свойств драйвера. Ниже перечислены основные стандартные процедуры.
• Обязательная процедура инициализации, которая используется драйвером для подготовки рабочего окружения и собственной инициализации, а также для настройки объектов устройств (в том числе их подключения в соответствующие цепочки стека драйверов). Эта процедура вызывается диспетчером ввода-вывода при загрузке драйвера.
• Обязательный набор процедур диспетчеризации для обеспечения работы определенных функций, например чтения, записи, создания и закрытия файлов. Эти процедуры вызываются диспетчером ввода-вывода и получают в качестве параметра пакет запроса ввода-вывода.
• Необязательная процедура запуска (startup routine – StartIO), которая инициирует ввод-вывод данных на физическое устройство. Очевидно, что только драйверы, работающие непосредственно с физическими устройствами (это касается не всех драйверов такого типа), требуют наличия такой процедуры.
• Необязательная процедура обслуживания прерывания (interrupt service routine – ISR). Может использоваться драйверами, взаимодействующими с физическими устройствами. Процедуры обслуживания прерываний рассматриваются в разделе 1.5.1.
• Необязательный отложенный вызов процедуры' (deferred procedure call – DPC), который может использоваться драйвером для дополнительной обработки процедуры обслуживания прерывания. Отложенный вызов процедуры рассматривается в разделе 1.5.2.
• Необязательная процедура завершения, которая вызывается диспетчером ввода-вывода (в качестве механизма уведомления), когда драйвер более низкого уровня завершает обработку пакета запроса ввода-вывода. Поскольку вся операция ввода-вывода обрабатывается в качестве асинхронной, процедура завершения используется довольно часто, особенно в высокоуровневых драйверах, которые всегда обеспечивают обработку пакетов IRP более низкого уровня.
• Обязательная процедура выгрузки, которая вызывается диспетчером ввода-вывода для выгрузки драйвера.
• Необязательная процедура отмены (cancellation routine – CancellO), которая вызывается диспетчером ввода-вывода для отмены выполнения длительной операции.
• Обязательная процедура уведомления об отключении системы, которая вызывается диспетчером ввода-вывода для уведомления драйвера о необходимости быстрого завершения работы, когда пользователь обращается с запросом о завершении работы системы.
• Необязательная процедура протоколирования ошибок.
Обработка пакета запроса ввода-вывода совершается драйвером различными способами, в зависимости от структуры драйвера и запроса ввода-вы- вода в пакете. Ниже приведены некоторые примеры работы драйвера.
• Выполнение запрошенной операции и завершение обработки IRP.
• Выполнение элемента операции и передача IRP драйверу более низкого уровня.
• Обычная передача IRP драйверу более низкого уровня.
• Генерация нескольких пакетов IRP для драйвера более низкого уровня в ответ на получение одного пакета IRP. Например, в ответ на запрос об открытии файла, поступивший от драйвера NTFS, драйверу может потребоваться считать метаданные файла для поиска каталога и подкаталогов, в которых расположен необходимый файл.
Обычно драйверы получают доступ к своей области стека в пакете IRP, а также к области стека следующего драйвера. Самый нижний драйвер в цепочке стека получает доступ только к своему фрагменту стека в пакете IRP. Драйвер отвечает за изменение указателя в пакете IRP, который указывает на область стека, используемую следующим драйвером.
Обратите внимание, что один и тот же код драйвера может одновременно выполняться на разных центральных процессорах в одной системе Windows NT. Код драйвера должен обладать возможностью синхронизировать доступ к критическим данным кода, выполняемого на разных процессорах. Иногда повторное выполнение одного запроса может стать просто катастрофой, например при записи на магнитную ленту одних и тех же данных повторно.
Процедура обслуживания прерывания (interrupt service routine – ISR) обычно выполняется в ответ на получение прерывания от аппаратного устройства и может вытеснять любой код с более низким приоритетом. Процедура обслуживания прерывания должна использовать минимальное количество операций, чтобы центральный процессор имел свободные ресурсы для обслуживания других прерываний. Эта процедура собирает минимум необходимой информации и размещает в очереди вызов отложенной обработки (deffered processing call – DPC) для завершения обслуживания прерывания. Запуск вызова отложенной обработки не планируется на определенное время, т.е. вызов может быть запущен как немедленно, так и немного позднее, в зависимости от необходимости в другой обработке.
Для того чтобы обеспечить постоянную доступность процедуры обслуживания прерывания, процедуры никогда не выгружаются на жесткий диск. Процедура обслуживания прерывания может быть прервана процедурой обслуживания прерывания с более высоким приоритетом, но ее никогда нельзя вытеснить другим кодом, например вызовом отложенной обработки.
Процедура обслуживания прерывания обычно необходима драйверам, которые работают с аппаратным обеспечением, например с накопителем на магнитной ленте или жестким диском. Чаще всего, драйверы, которые обеспечивают работу некоторых программных функций, например драйверы файловой системы или фильтрации, не используют процедуру обслуживания прерывания.
При запуске от процедуры обслуживания прерывания требуется быстрое и эффективное выполнение поставленной задачи. Таким образом, процедура обслуживания прерывания проводит минимум операций и размещает в очереди запрос на вызов отложенной обработки, который используется для завершения оставшихся операций с низким уровнем приоритета (эти уровни обычно называются IRQ или IRQL). Вызов отложенной обработки может быть размещен в очереди не только из процедуры обработки прерывания. Запрос к очереди создает новый объект вызова отложенной обработки (средствами диспетчера объектов). После размещения в очереди создается аппаратный запрос на прерывание (IRQ level 2) для вызова отложенной обработки.
Ниже описаны некоторые важные свойства вызова отложенной обработки.
Вызов отложенной обработки может быть прерван другой процедурой обработки прерывания, однако никогда не может быть вытеснен кодом пользовательского режима.
Вызов отложенной обработки не должен приводить к ошибке обращения к странице, поэтому вся память, используемая вызовом отложенной обработки, должна быть заблокирована для выгрузки.
Вызов отложенной обработки не должен выполнять блокирующие действия, например блокирующий ввод-вывод.
Вызов отложенной обработки напоминает процедуру обработки прерывания, поскольку также должен выполняться быстро и эффективно. Для минимизации нагрузки на систему при планировании вызовов отложенной обработки Windows NT перед передачей управления DPC сохраняет минимальную информацию о состоянии. После завершения DPC восстановление состояния также занимает мало времени, так как при передаче управления сохранялся минимум информации. В результате DPC может выполняться в контексте произвольного процесса. Например, если программа Excel выполняется в виде процесса и запускает процедуру ввода-вывода, вызов отложенной обработки (если он потребуется) может запускаться в контексте процессов Word или PowerPoint (а не обязательно в контексте процесса Excel).
Каждый процесс имеет собственную очередь вызовов отложенной обработки. Таким образом, многопроцессорный компьютер с четырьмя центральными процессорами будет иметь четыре отдельных очереди DPC. Вызов отложенной обработки может иметь высокий, средний и низкий приоритет; по умолчанию присваивается средний приоритет. Драйвер может изменить значение приоритета. Вызов отложенной обработки
с высоким приоритетом размещается в начало очереди, a DPC с низким и средним приоритетом – в конец очереди.
Обычно вызов отложенной обработки выполняется на том же процессоре, что и процедура обслуживания прерывания, что можно изменить с помощью драйвера.
Если драйвер уже поместил DPC в очередь, следующий запрос на размещение DPC в очереди просто игнорируется. При выполнении DPC выясняется, существует ли несколько рабочих элементов, например, при многократной обработке прерываний, когда каждое прерывание требует наличия отдельного рабочего элемента.
Вызов отложенной обработки может быть размещен в очереди другого процессора, если очередь DPC текущего процессора превышает определенное значение. Ядро Windows NT периодически пытается выполнить вызов отложенной обработки, генерируя программные прерывания.
Вызов отложенной обработки не может быть выгружен на диск.
Асинхронный вызов процедуры (asynchronous procedure call – АРС) немного похож на вызов отложенной обработки, но существуют и заметные различия. Как и вызов отложенной обработки, АРС выполняется на уровне привилегий, превышающем уровень привилегий обычного кода. В отличие от вызова отложенной обработки, выполняемого в контексте произвольного процесса, асинхронный вызов процедуры всегда выполняется в контексте определенного процесса. Таким образом, асинхронный вызов процедуры требует больших затрат, чем вызов отложенной обработки, так как приходится сохранять и восстанавливать большее количество параметров. Читателю, знакомому с операционными системами UNIX, асинхронные вызовы процедур напомнят процедуры обработки сигналов UNIX.
Существует два типа АРС: вызов в режиме ядра и вызов в пользовательском режиме. Асинхронный вызов процедуры в режиме ядра связан с драйвером или другим кодом режима ядра и обычно используется для передачи данных, например для копирования данных из буфера ядра в пользовательский буфер. Помните, что пользовательский буфер должен быть доступен в контексте процесса, который владеет буфером.
Код пользовательского режима тоже может использовать асинхронный вызов процедур. Для этого необходим прикладной интерфейс программирования QueueUserAPC, который рассматривается в документации к набору Platform SDK. Асинхронные вызовы процедур в пользовательском режиме предоставляются только тогда, когда поток получает предупреждение, например при блокировании в результате вызова функций WaitForSingleObject или WaitForMultipleObject. Подробная информация об этих функциях доступна в документации Platform SDK. Достаточно сказать, что эти функции позволяют организовать синхронизацию потоков.
Асинхронный вызов процедуры может быть блокирующим, например для выполнения специального ввода-вывода. Вызовы помещаются в очередь, соответствующую потоку, т.е. существует несколько очередей асинхронных вызовов процедур.
1.6 Драйверы и буферы ввода-вывода
В этом разделе рассматриваются буферы ввода-вывода, которые уже упоминались ранее в главе. Драйверы используют буферы для осуществления ввода-вывода и управления им (IOCTL). Для этого драйверы посредством соответствующего объекта указывают предпочтительный способ ввода-вывода. Существует три поддерживаемых драйверами Windows NT типа ввода- вывода: буферизированный, прямой и небуферизированный. Эти методы рассматриваются в данном разделе.
Буферизированный ввод-вывод обычно используется для передачи меньших объемов данных, так как в процессе ввода-вывода участвуют операции копирования данных. После того как приложение отправило запрос на ввод- вывод, диспетчер ввода-вывода проверяет соответствие прав доступа приложения к предоставленному буферу ввода-вывода (соответствие прав доступа предполагает, что приложение имеет права на чтение и запись, а также имеет доступ к буферу необходимого размера, указанного в запросе на ввод- вывод). Диспетчер ввода-вывода выделяет буфер в невыгружаемой памяти и в случае запроса на запись копирует данные из буфера приложения в выделенный буфер. Этот буфер передается драйверу.
Драйвер не обязан заботиться о контексте потока, так как буфер находится в невыгружаемой памяти и действителен в контексте любого процесса или потока. Драйвер выполняет необходимую операцию ввода-вывода. Для операции чтения драйвер копирует данные в полученный буфер. Кроме того, драйвер может «предположить», что в контексте виртуального адресного пространства буфер будет непрерывным, но, как и в случае других буферов Windows NT, непрерывность буфера в виртуальном адресном пространстве не гарантирует непрерывности в физическом адресном пространстве.
На этом этапе драйвер завершает обработку IRP, и ответственность за копирование данных из невыгружаемого буфера в буфер приложения возлагается на диспетчер ввода-вывода. Эта операция копирования должна выполняться в контексте процесса, который отправил запрос на ввод-вывод. Кроме того, диспетчер ввода-вывода должен освобождать буфер, выделенный в невыгружаемой области памяти.
Прямой ввод-вывод (Direct I/O) несколько более запутан, чем буферизированный, однако намного эффективнее при выполнении операций ввода- вывода для больших массивов данных. Диспетчер ввода-вывода выполняет базовые проверки, например проверяет разрешения приложения на доступ к буферу посредством области ввода-вывода желательного объема. Буфер в памяти, независимый от процесса, описывается для драйвера средствами структуры данных, которая называется список дескрипторов памяти (memory descriptor list – MDL). Адрес буфера используется в качестве общесистемного виртуального адресного пространства.
Операционная система Windows NT предоставляет процедуры драйверов, которые позволяют получать доступ к различным полям списка дескрипторов памяти. Создателям драйверов рекомендуется использовать список дескрипторов памяти в качестве целостного элемента. Дополнительная информация по использованию процедур работы со списками дескрипторов памяти приводится в документации к инструментарию создания драйверов (DDK) Windows NT. Процедуры, описанные в DDK, предоставляют следующие возможности:
• блокирование и разблокирование буфера приложения;
• связывание заблокированного буфера с виртуальным адресом, который доступен из контекста любого потока;
• сбор информации, необходимой для выполнения операции ввода-вывода с прямым доступом к памяти в буфер или из него, который в действительности представляет собой последовательность потенциально несоседних физических страниц памяти.
Прямой ввод-вывод чаще всего используется в драйверах ввода-вывода, например драйверах управления дисками и приводами на магнитной ленте.
Этот тип ввода-вывода позволяет избавиться от генерирования дополнительных данных, что свойственно для буферизированного ввода-вывода (операций копирования данных и выделение/освобождение буфера) и прямого ввода-вывода (создания и уничтожения списка дескрипторов памяти), но за это приходится расплачиваться ограниченностью применения данного типа ввода-вывода. При небуферизированном вводе-выводе драйверу непосредственно передается адрес буфера запросившего приложения. Внимательный читатель быстро догадается, что, поскольку виртуальный адрес имеет смысл только в контексте определенного процесса или потока, драйвер должен вызываться в контексте запросившего приложения. Более того, драйвер должен выполнить операцию в этом же контексте (т.е. драйвер не может поместить запрос в очереди для последующего выполнения в произвольном контексте).
Это ограничение определяет ситуации использования данного метода ввода-вывода, который не применяется большинством драйверов, исключение составляют, например, драйверы файловой системы. Дело в том, что последние всегда вызываются в контексте процесса, который запрашивает операцию ввода-вывода. Кроме того, небуферизированный ввод-вывод поддерживает копирование между кэшем и буферами данных, так как управлять буферами (связывание адресов) не требуется.
Может сложиться неверное впечатление, что драйвер должен выбрать один из описанных способов вводагвывода и использовать только его. Драйвер, который выполняет операции управления вводом-выводом (IOCTL), может использовать один метод ввода-вывода для обработки обычных пакетов IRP и совершенно другой метод для операций управления вводом-выводом, которые определяются частным образом между драйвером и соответствующим приложением. Конечно, даже драйвер на нижних уровнях стека драйверов, который не имеет информации о контексте выполнения, не обязательно использует небуферизированный ввод-вывод в частных операциях управления вводом-выводом.
Поскольку здесь затронута тема частного управления вводом-выводом, стоит упомянуть, что компания Microsoft настойчиво советует не применять такой способ управления, особенно при наличии более приемлемой альтернативы. Основная проблема частного управления вводом-выводом заключается в сложности проверки «жизнеспособности» кода драйвера методом намеренной передачи некорректных буферов процедуре управления вводом-выводом, что делается для проверки работоспособности драйвера. Для передачи некорректного буфера необходимо иметь информацию о правильном размере буфера, выравнивании и граничных условиях, которые предполагаются в коде управления вводом-выводом, а для частных операций управления вводом- выводом эти параметры каждый раз имеют другие значения.
1.7 Иерархия драйверов систем хранения и типы драйверов
Как описывалось в предыдущем разделе, Windows NT основана на архитектуре, в которой драйверы формируют многоуровневую иерархию. Преимущество такой архитектуры состоит в расширяемости архитектуры и возможности добавления новых драйверов на любой уровень иерархической структуры. Таким образом, благодаря поуровневому размещению драйверов можно реализовать различные функциональные возможности. В контексте выполняемого модуля Windows NT все драйверы имеют аналогичную структуру, поэтому функции драйвера используются схожим образом вне зависимости от его типа.
В этом разделе представлен обзор стека драйверов устройств хранения Windows NT. Обратите внимание, что речь идет только о базовых, а не обо всех драйверах, связанных с подсистемой хранения данных. Например, драйверы, связанные со службами удаленного хранения (RSS), рассматриваются в главе 7.
На рис. 1.5 демонстрируется стек драйверов подсистемы хранения данных Windows NT. Обратите внимание: здесь представлена многоуровневая архитектура драйверов, однако в зависимости от ситуации те или иные уровни приобретают более важное значение. Ниже приведены примеры подобных ситуаций.
При вводе-выводе данных на физический диск, подключенный через интерфейс IDE или SCSI, необходимы уровни класса и порта, а также уровни файловой системы и управления томами. Все эти уровни рассматриваются далее в главе.
При вводе-выводе данных посредством накопителя на магнитной ленте уровни управления томами и файловой системы не требуются.
В следующих подразделах рассматриваются драйверы шины, порта, класса, управления томами, файловой системы и фильтрации, представленные на рис. 1.5.
Драйвер шины Windows NT предоставляет функции шины другим драйверам. Термин шина используется в универсальном смысле, обозначая любое виртуальное или физическое устройство, к которому подключаются другие устройства. Драйверы шины необходимы для поддержки процедур перебора, которые вызываются диспетчером Plug and Play для перечисления устройств, подключенных к шине. Кроме того, от драйверов шины требуется предоставление кода обработки РпР, а также пакетов IRP для управления энергопитанием. Компания Microsoft предоставляет драйверы ввода-вывода для всех физических шин персональных компьютеров (например, SCSI, PCI, 1394, USB), хотя независимые поставщики оборудования также могут по мере необходимости предоставлять собственные драйверы шин. Драйвер шины создает объект физического устройства (physical device object – PDO) для каждого устройства, указанного процедурой перечисления устройств.
Рис. 1.5. Стек драйверов хранения Windows NT
Драйвер порта реализует специфичные для устройства функциональные возможности и изолирует драйвер класса от влияния особенностей аппаратного обеспечения. Драйвер порта должен реализовать набор указанных функций для драйвера класса и может реализовать дополнительные возможности. Драйвер порта получает пакеты IRP и передает блоки запросов SCSI с встроенными блоками дескрипторов команд драйверу мини-порта, который динамически подключается к драйверу порта. Драйверы мини-портов не создают объектов устройств, а используют созданные драйверами порта. Как отмечалось в разделе 1.4.2, драйверы порта создают объект физического устройства, необходимый для взаимодействия с устройством.
В Windows NT предоставляются некоторые драйверы порта, включая SCSIPort и IEEE 1394. В свою очередь, Windows Server 2003 поставляется
с дополнительным драйвером порта, который называется Storport. На данный момент достаточно сказать, что драйвер SCSIPort используется для работы с устройствами SCSI-2 и более старыми устройствами, а драйвер Storport – с устройствами SCSI-3 и Fibre Channel. Дополнительная информация о драйвере Storport приводится в главе 2.
Драйверы порта, в свою очередь, содержат драйверы мини-портов, которые предоставляются независимыми поставщиками оборудования. Мини- порт обеспечивает функции уровня устройства, которые зависят от конкретного поставщика и не обеспечиваются драйвером порта. Драйверы мини-пор- та создаются с помощью инструментария разработки драйверов Windows NT.
Драйвер класса обеспечивает универсальную, не зависящую от устройства поддержку целого диапазона устройств. Драйвер класса зависит от драйверов мини-класса или мини-порта, которые предоставляют конкретные функции устройства. Драйверы класса хранения данных используются для работы с устройствами SCSI и устройствами, подключаемыми через другие интерфейсы. Ниже перечислены другие функции драйверов классов.
Создание объекта функционального устройства (FDO). Такой объект необходим для непосредственного использования устройства. В FDO могут содержаться такие данные, как структура организации диска (таблица разделов) или номер региона DVD.
Проверка действительности параметров IRP.
Повторная отправка запросов, обработка которых завершилась неудачно.
В частности, драйверы класса хранения данных выполняют описанные ниже операции.
Разбивка больших запросов чтения/записи (полученных с помощью IRP IRP_MJ_READ и IRP_MJ_WRITE) на меньшие множественные запросы, которые соответствуют возможностям физического адаптера шины.
Получение пакетов IRP и их трансляция в подходящие блоки запросов SCSI (SCSI request blocks – SRB), которые содержат встроенные блоки дескрипторов команд. После этого блоки запросов SCSI отправляются следующему драйверу в цепочке стека, который может оказаться драйвером фильтрации или драйвером порта. Блоки запросов SCSI при этом будут незавершенными, так как драйвер класса не заполняет информацию об адресации в блоке запроса SCSI и в этом зависит от драйвера более низкого уровня.
■ Участие в управлении питанием, добавление и удаление устройств, а также установка тайм-аута для ввода-вывода данных на устройства. Другими словами, драйверы класса устройств хранения активно принимают участие в реализации РпР и управлении энергопитанием.
Драйверы класса взаимодействуют с драйверами порта на следующем нижнем уровне стека хранения данных. Интерфейс между драйверами классов и драйверами порта формируется посредством частного интерфейса управления вводом-выводом, а также обмена блоками запросов SCSI. Некоторые элементы блоков запроса SCSI Используются только для интерфейса класса или интерфейса порта, а некоторые предназначены для использования драйвером порта.
К драйверам класса устройств хранения в Windows NT относятся, например, драйверы дисков, приводов компакт-дисков и накопителей на магнитной ленте; они могут работать с различными устройствами, в том числе подключенными к шинам SCSI, IDE, USB и 1394.
В контексте диспетчера ввода-вывода драйвер класса устройства хранения – это такой же драйвер, как и все остальные, поэтому он должен соответствовать определенным требованиям, например предоставлять процедуры инициализации ввода-вывода, выгрузки и завершения.
Драйверы класса устройства хранения обычно работают аналогично драйверам шины, перечисляя дочерние устройства. Хорошим примером может служить драйвер класса диска (disk. sys), который считывает таблицу разделов диска и создает объекты устройств для каждого найденного дискового раздела.
Некоторые драйвера класса определяют интерфейс драйвера мини-класса. Драйвер мини-класса, который обычно создается независимым поставщиком оборудования, представляет собой динамически подключаемую библиотеку режима ядра, которая взаимодействует с драйвером класса, предоставляемым Microsoft. Драйвер мини-класса регистрирует адаптеры аппаратного обеспечения с помощью драйвера класса, а последний, в свою очередь, создает объект устройства для каждого зарегистрированного адаптера. Драйвер мини-класса не содержит объектов устройств и использует объект устройства, который создается драйвером класса. Обычно драйвер мини-класса помогает вносить дополнительную информацию в блоки запросов SCSI, которые создаются драйвером класса. В качестве примера можно привести драйвер мини-класса для накопителя на магнитной ленте.
Интересно отметить, что Microsoft добавила в Windows 2000 новую библиотеку, которая называется ClassPnP. Эта библиотека реализует функциональные возможности РпР, общие для всех драйверов класса. При этом некоторые функции полностью реализуются драйвером класса. Для других функций драйвер, который использует библиотеку класса, должен предоставить процедуры обратного вызова, используемые драйвером класса при необходимости. Все драйверы класса, предоставляемые Microsoft (драйверы дисков, накопителей на магнитной ленте и драйверы приводов компакт-дисков), пользуются услугами библиотеки ClassPnP (она реализована в виде файла classpnp. sys). Та же ситуация сохранилась и в Windows XP/Windows Server 2003.
Описание различных уровней, показанных на рис. 1.5, все еще остается неполным. Однако немного отвлечемся перед обсуждением уровней управления томами и файловыми системами и рассмотрим дерево устройств, которое создается операционной системой. Знакомство с объектной моделью дерева устройств упрощает понимание тем, связанных с многопоточным вводом-выводом данных в отказоустойчивых устройствах хранения (см. главу 9) и с точками повторной обработки (см. главу 6). Поэтому имеет смысл рассмотреть данную тему сейчас, пока еще не забылась информация об объектах устройств, драйверах классов и портов, приведенная в предыдущих разделах.
Как уже отмечалось, технология РпР играет вареную роль в идентификации устройств. Интерфейс РпР загружает драйверы шины и инициирует обнаружение устройств, подключенных к этой шине. При обнаружении устройств РпР используется для загрузки соответствующих драйверов. В частности, перечисление устройств начинается с драйвера виртуальной (корневой) шины. Драйвер корневой шины отвечает за перечисление устаревших драйверов DOS и обычно используется для идентификации шин PCI. Драйверы, загруженные драйвером корневой шины, часто называют прошедшими корневое перечисление. К ним относится, например, драйвер шины МРIO (рассматривается в главе 9).
При загрузке драйверов и перечислении ими соответствующих устройств списки устройств передаются обратно интерфейсу РпР. При этом формируется дерево устройств, демонстрирующее схему их логического и физического взаимодействия. Обратите внимание, что РпР может только создать дерево; граф устройств не поддерживается. Таким образом, при использовании РпР дочерний узел может содержать только один родительский узел.
На рис. 1.6 в верхнем левом углу иллюстрируется несложная системная конфигурация – сервер Windows NT с одним адаптером шины и одним диском, подключенным к этому адаптеру. Другие периферийные устройства, которые обычно подключены к компьютерам под управлением Windows NT, на рисунке не показаны.
Рис. 1.6. Дерево драйверов устройств
На рис. 1.6 представлен подробный обзор лишь некоторых компонентов с рис. 1.5. В частности, на рис. 1.6 не показаны уровень управления томами и уровень файловых систем, в отличие от уровней драйверов классов и портов на рис. 1.5. Начиная с нижней правой области рис. 1.6, последовательность формирования дерева устройств выглядит так, как описано ниже.
Выполняемый модуль Windows NT (в частности, диспетчер РпР) создает объект физического устройства для драйвера шины PCI.
Драйвер шины PCI, в свою очередь, создает объект функционального устройства для шины PCI и подключает его к объекту физического устройства.
Кроме того, драйвер шины PCI идентифицирует (перечисляет) адаптеры и обнаруживает адаптер шины SCSI, после чего создает для него объект физического устройства. Чтобы не усложнять диаграмму на рис. 1.6, другие адаптеры, подключенные к шине PCI, в данный момент не рассматриваются.
Диспетчер РпР загружает драйвер SCSIPort и после инициализации последнего вызывает его через входную точку входа AddDevice. При этом
драйверу в качестве параметра передается объект физического устройства, созданный драйвером шины PCI. Драйвер SCSIPort создает объект функционального устройства для устройства шины. Драйвер порта подключает созданный объект функционального устройства к объекту физического устройства, созданному драйвером шины PCI.
Как уже отмечалось, драйвер может функционировать по-разному, и в данном случае драйвер SCSIPort действует в качестве драйвера шины, перечисляя устройства, которые подключены к шине SCSI. Драйвер обнаруживает диск и сообщает о нем диспетчеру РпР, который загружает драйвер класса диска (disk. sys). После инициализации драйвер класса диска вызывается через входную точку AddDevice и в качестве параметра получает объект физического устройства, который создается драйвером SCSI.
Драйвер класса диска создает объект функционального устройства для диска, подключенного к адаптеру шины, и подключает его к объекту физического устройства, созданному драйвером SCSIPort. На самом деле адаптер шины может быть подключен к промышленному коммутатору Fibre Channel, за счет чего адаптер главной шины перечислит намного больше устройств. В данном случае описываемая ситуация намеренно упрощена. Кроме того, стек устройств на этом не заканчивается. Дальнейшее обсуждение стека устройств, которое затрагивает уровни управления томами и файловых систем, приводится в следующем разделе.
Обратите внимание на взаимодействие двух драйверов для создания экземпляров таких логических устройств, как драйвер шины PCI и драйвер SCSIPort. Это вполне логично, так как устройство, с одной стороны, подключается к шине PCI, а с другой – обеспечивает работу интерфейса шины SCSI. Таким образом, одно устройство имеет характеристики как устройства PCI, так и устройства SCSI, поэтому оно должно обрабатываться одновременно драйвером шины PCI и драйвером SCSIPort.
На этом этапе можно вернуться к рис. 1.5 и рассмотреть уровень управления томами. Тома – это логические элементы, которые создаются, чтобы упростить управление устройствами хранения данных. Физические диски, которые подключаются через интерфейсы IDE или SCSI, могут быть логически разбиты на разделы (partitions). Раздел – это физически непрерывный набор секторов диска. Из разделов определенным образом формируется том. Такая комбинация разделов может предоставлять дополнительные возможности: например, несколько разделов могут быть объединены для создания тома, размер которого превышает размер каждого из физических дисков. Еще одним примером может быть создание зеркального тома на основе двух разделов, размер которых совпадает. Дисковые тома рассматриваются более подробно в главе 6. На данном этапе эта тема затрагивается для описания схемы управления томами в Windows NT с помощью драйвера программного устройства.
Рис. 1.7. Дерево объектов устройств для стека томов
В Windows 2000, Windows ХР и Windows Server 2003 поддерживается три различных диспетчера томов: FtDisk, Microsoft Logical Disk Manager и VERITAS Volume Manager. Все они подробно рассматриваются в главе 6. В данном случае в качестве примера будет использоваться базовый диспетчер томов Microsoft FtDisk Manager. Дерево устройств с другими диспетчерами томов также описано в главе 6. Дерево устройств на рис. 1.7 иллюстрирует системную конфигурацию с одним подключенным диском SCSI, содержащим два раздела, которые, в свою очередь, формируют один том.
Для понимания принципов работы диспетчеров томов рассмотрим рис. 1.7, начиная с нижнего правого угла. Подсистема РпР и драйверы шины PCI взаимодействуют для создания объектов физического и функционального устройств для шины PCI. После идентификации устройств, подключенных к шине PCI, драйвер шины PCI создает объект физического устройства для адаптера шины SCSI. Драйвер SCSIPort создает объект функционального устройства для адаптера шины SCSI. Затем драйвер SCSIPort и драйверы класса диска создают объект физического устройства и объект функционального устройства для одного диска, который подключен к шине SCSI. До этого момента на рис. 1.7 вкратце дублировалось содержимое рис. 1.6. -
Диспетчер разделов представляет собой драйвер фильтрации более высокого уровня (драйверы фильтрации рассматриваются в разделе 1.7.7), который регистрируется в подсистеме Windows NT РпР для Получения уведомлений о создании драйвером класса диска новых объектов устройств. Диспетчер разделов появился впервые в Windows 2000 и используется в Windows ХР и Windows Server 2003. Диспетчер разделов взаимодействует с диспетчерами томов (на рис. 1.7 это диспетчер FtDisk) с помощью частных интерфейсов и передает уведомление о создании устройства диспетчеру разделов. Обнаружив все дисковые разделы, которые формируют том, диспетчер тома создает объект устройства, представляющего данный том. Диспетчер разделов обеспечивает уведомление подсистемы РпР относительно удаления объекта устройства или раздела (например, при удалении раздела). Диспетчер разделов связывается с драйвером FtDisk для предоставления последнему информации о динамически добавляемых и удаляемых разделах.
На рис. 1.7, в отличие от предыдущих рисунков, впервые показан диспетчер разделов, который следит за пакетами IRP в процессе ввода-вывода и обеспечивает завершение их обработки. Обнаружив завершение обработки QDR(IRP_MN_QUERY_DEVICE_RELATI0NSHIPS), диспетчер разделов незаметно удаляет дополнительную информацию об обнаруженном устройстве – в данном случае это объект устройства для раздела 0, созданный драйвером класса диска disk. sys. Таким образом объект устройства раздела 0 никогда не обнаруживается подсистемой РпР. Именно поэтому объект устройства для раздела 0 закрашен не так, как все остальные объекты на рис. 1.7.
Диспетчер разделов передает информацию об обнаруженных объектах устройств зарегистрированным диспетчерам томов. На данный момент обсуждение будет ограничено одним диспетчером томов. В главе 6 рассматривается аналогичная ситуация, но уже при участии нескольких диспетчеров томов. Диспетчер томов проверяет устройства, представленные объектами устройств, которые «украдены» диспетчером разделов, и принимает или отвергает владение этими объектами устройств. В этом примере драйвер FtDisk подтверждает свое владение объектами устройств. Затем диспетчер FtDisk проверяет конфигурацию тома и устанавливает, что том сформирован посредством одного раздела, а также определяет владельца соответствующего раздела. На этом этапе драйвер FtDisk создаст объект устройства для тома (на рис. 1.7 он называется «том V01»), после чего можно будет монтировать файловую систему этого тома. Подробности монтирования файловой системы рассматриваются в главе 6.
Следует отметить, что здесь на самом деле рассматриваются два отдельных стека устройств. Один стек представляет логический компонент – том, а второй включает в себя физические устройства системы, например шину PCI, адаптер SCSI и жесткий диск. Диспетчер томов действует как мост между двумя стеками.
На рис. 1.7 драйвер FtDisk отправляет все обработанные пакеты IRP непосредственно драйверу класса диска. Конечно, драйвер FtDisk преобразует смещения относительно тома в смещения относительно диска перед отправкой пакетов IRP. Такие операции ввода-вывода показаны толстыми штриховыми линиями. Тонкие пунктирные линии отображают частный интерфейс между диспетчерами томов и разделов. Кроме того, драйвер FtDisk отправляет необработанные сообщения управления вводом-выводом непосредственно объекту устройства раздела. На рис. 1.7 это показано штрих-пунктирной линией.
Драйверы файловой системы представляют собой драйверы устройств Windows NT, которые реализуют возможности файловой системы. Хотя файловая система содержится на физическом носителе, например на компакт- диске или жестком диске, драйверы файловой системы рассматриваются в качестве логических, поскольку не используются для непосредственного управления аппаратным обеспечением. Драйверы файловых систем полагаются на драйверы портов и классов для обеспечения ввода-вывода данных на диск и с него. Драйвер файловой системы обычно получает пакет IRP для выполнения запроса и осуществляет одну из двух операций.
Заполняет следующий фрагмент стека пакета IRP необходимой информацией для завершения ввода-вывода. После этого пакет IRP отправляется драйверу класса.
Создает последовательность пакетов IRP для выполнения запрошенного ввода-вывода.
Драйвер файловой системы содержит метаданные на самом носителе. В метаданные входит информация о разрешениях доступа к файловой системе и таблица размещения файлов (расположение файлов на диске). Драйвер файловой системы получает пакет IRP, который указывает на определенную операцию по отношению к файлу, считывает необходимые метаданные и отправляет запрос IRP, который уже относится к блоку диска, а не к файлу. Операционная система поставляется с драйверами файловых систем NTFS, UDFS и FAT.
Создание драйвера файловой системы или драйверов фильтрации для файловых систем в Windows NT З. х; поначалу считали «черной магией». Впоследствии Microsoft предоставила инсталляционный инструментарий файловых систем (Installable File System Kit), который содержит необходимые заголовочные файлы, документацию и примеры создания файловых систем и драйверов фильтрации файловых систем.
Драйверы как файловых систем, так и фильтрации файловых систем должны обеспечивать поддержку пакетов IRP РпР, включая управление питанием, удаление носителя и самого устройства хранения (например, внешнего дисковода на гибких дисках, подключаемого к шине USB).
Драйверы фильтрации размещены выше других объектов устройств в иерархической структуре драйверов и выполняет предварительную и/или последующую обработку запросов ввода-вывода для модификации работы системы. Драйверы фильтрации обычно используются для выполнения перечисленных ниже задач.
Поддержка модульной структуры, например посредством драйвера фильтрации музыкальных компакт-дисков.
Добавление функциональных возможностей, например записи компакт- дисков на соответствующих устройствах.
Добавление функциональных возможностей файловой системе, например драйверов фильтрации для шифрования, точек повторной обработки и SIS – Single Instance Storage (рассматривается в главе 6).
Добавление функций шины. Например, в виде поддержки шины AGP или расширений ACPI BIOS.
Изменение процесса ввода-вывода для того, чтобы он соответствовал особенностям функционирования аппаратного обеспечения, например разбивка пакетов ввода-вывода на меньшие фрагменты.
Драйверы фильтрации всегда создают объект устройства, который подключен к объекту функционального устройства или к объекту физического устройства (эти объекты рассматриваются в разделе 1.4.2). Объект устройства необходим драйверу фильтрации для получения пакетов IRP и выполнения предварительной и/или последующей обработки запросов ввода-вывода.
Некоторые драйверы фильтрации создают вторичный объект устройства, который часто называется объектом управляющего устройства (control device object – CDO), так как он используется для отправки управляющей информации драйверу фильтрации с помощью соответствующего модуля управления. Драйверы фильтрации, которые подключаются к объекту функционального устройства, созданному драйвером класса, называются драйверами фильтрации верхнего уровня. В свою очередь, драйверы фильтрации, которые подключаются к объекту физического устройства, размещенному ниже в стеке и созданному драйвером порта, называются драйверами фильтрации нижнего уровня.
Драйверы фильтрации нижнего уровня отличаются более сложной структурой, чем драйверы верхнего уровня. К одной из технических проблем относится выбор сообщаемых ошибок,, а также операций ввода-вывода, ошибки которых сообщаются. Еще одна проблема – отсутствие готовых примеров драйверов нижнего уровня, поскольку все доступные примеры описывают драйверы верхнего уровня. Иногда (достаточно редко) драйверы нижнего уровня предоставляют функции протокольного преобразователя или функции, позволяющие обойти некоторые ограничения в работе аппаратного устройства.
Драйверы фильтрации существовали в Windows NT с момента появления ее первой коммерческой версии. Пакет Windows NT Installable File System Kit (http://www.microsoft.com/ddk/IFSKit) представляет собой неплохой справочник для разработчиков, в котором подробно документируется архитектура драйверов фильтрации.
Начиная с Windows 2000, в процесс загрузки драйверов фильтрации были внесены значительные изменения. Ранее дополнительная работа по проверке правильности загрузки драйвера ложилась на плечи создателя драйвера. Если драйвер загружался слишком рано, объект устройства, к которому должен подключиться драйвер, мог еще не существовать. Если драйвер загружался слишком поздно, устройство могло оказаться занятым другим драйвером; это приводило к тому, что драйвер фильтрации в стеке драйверов помещался выше, чем было необходимо. В Windows 2000 создатель драйвера указывает размещение драйвера выше или ниже определенного объекта физического устройства или объекта функционального устройства, а диспетчер Plug and Play загружает драйвер в подходящее время.
Похоже* что компания Microsoft чересчур упростила процесс создания драйвера фильтрации. Цепь стека драйверов стала чрезмерно «переполненной», что подразумевает проблемы с производительностью и загрузкой памяти (каждый пакет IRP должен содержать больше фрагментов стека, а пакеты IRP размещаются в невыгружаемой памяти). Достаточно посмотреть на список драйверов фильтрации, которые загружаются в операционной системе:
драйвер фильтрации шифрованной файловой системы;
драйвер фильтрации, используемый для управления иерархическим хранением и для служб удаленного хранения;
драйвер фильтрации SIS для служб удаленной установки (RIS);
драйверы фильтрации для точек повторной обработки от сторонних поставщиков;
драйверы фильтрации для антивирусного программного обеспечения.
С другой стороны, создание драйвера фильтрации бывает достаточно сложным. Представьте себе драйвер, который должен выполнять шифрование данных при записи на диск и дешифрацию при считывании. Все, что на самом деле необходимо драйверу, это доступ к буферам до их записи и после считывания. Но создатель драйвера не имеет возможности просто зарегистрировать функцию обратного вызова для быстрого выполнения необходимой функции и вынужден сталкиваться с различными трудностями, в частности с обработкой отмененных пакетов IRP.
1.8 Ввод-вывод типичного приложения хранения данных
Теперь соберем вместе все описываемые концепции и тщательным образом рассмотрим типичное приложение хранения данных. Это позволит разобраться с различными компонентами Windows NT, которые описывались ранее в главе, а также понять принципы их использования.
Рассматриваемое нами приложение будет просто считывать данные из файла. Файл размещен на томе, который управляется диспетчером томов FtDisk. Поскольку эта конфигурация идентична конфигурации, показанной на рис. 1.7, дерево объектов устройств не изменится. На рис. 1.8 представлена упрощенная версия дерева объектов устройств с рис. 1.7. Чтобы уменьшить объем предлагаемой информации, взаимодействие файловой системы с диспетчером кэша во внимание не принимается, т.е. предполагается, что файл не кэшируется.
Ниже описаны операции, которые приводятся на рис. 1.8.
Приложение, например резервного копирования, выдает запрос на чтение. 'После ряда стандартных проверок подсистема ввода-вывода перенаправляет запрос с помощью пакета IRP соответствующей файловой системе.
Файловая система определяет, что ей необходимо получить данные тома. Драйвер файловой системы создает пакет IRP с необходимыми параметрами, включая смещение в пределах тома, где должна быть выполнена операция чтения, и объем операции чтения. Кроме того, драйвер файловой системы указывает процедуру завершения ввода-вывода. После этого драйвер файловой системы отправляет пакет IRP диспетчеру томов.
Рис. 1.8. Операция чтения на томе
Диспетчер томов преобразует значение смещения тома в значение смещения на диске и заполняет соответствующий пакет IRP. Затем средствами диспетчера ввода-вывода пакет IRP отправляется драйверу класса диска.
После получения пакета IRP драйвер класса диска заполняет процедуру завершения в собственном элементе стека в пакете IRP. Обычно драйвер класса диска создает еще один пакет IRP (он называется ассоциированным) для выполнения ввода-вывода. Драйвер класса диска заполняет необходимую информацию в ассоциированном пакете IRP, указав блоки запросов SCSI для запроса чтения. Обратите внимание, что блок запроса SCSI представляет собой просто фрагмент данных пакета IRP, поэтому структура данных все еще остается пакетом IRP. После этого средствами диспетчера ввода-вывода драйвер класса диска отправляет пакет IRP драйверу порта.
Драйвер SCSIPort размещает пакет IRP в очереди, запрашивая некоторые операции у драйвера мини-порта, который управляет адаптером SCSI. На этом этапе пакет IRP отмечается как ожидающий выполнения и отправляется назад. Обычно диспетчер ввода-вывода обрабатывает пакет IRP в порядке, обратном только что описанному, т.е. после драйвера порта следует драйвер класса, затем диспетчер томов, а за ним файловая система. На каждом этапе пакет IRP отмечается как ожидающий выполнения. На определенном этапе ввод-вывод будет отправлен на физическое устройство средствами шины PCI.
В какой-то момент ввод-вывод будет завершен. Чтобы упростить описание, предположим, что операция ввода-вывода завершилась без ошибок. По завершении операции ввода-вывода генерируется программное прерывание.
Запускается процедура обслуживания прерывания, которая помещает в очереди вызов отложенной обработки для завершения обработки вво- да-вывода. После запуска вызова отложенной обработки драйвер SCSI- Port отмечает пакет IRP как завершенный и вызывает диспетчер ввода- вывода для дальнейшей обработки пакета. Диспетчер ввода-вывода обрабатывает пакет запроса ввода-вывода и вызывает процедуру завершения следующего драйвера в цепочке стека, т.е. драйвера класса диска.
Диспетчер ввода-вывода вызывает процедуру завершения драйвера класса диска. Процедура завершения выполняет необходимые операции обслуживания и вызывает диспетчер ввода-вывода для дальнейшей обработки пакета IRP. Диспетчер ввода-вывода переносит обработку на один уровень выше в цепочке стека драйверов. В данном случае к драйверу диспетчера томов FtDisk.
Вызывается процедура завершения драйвера FtDisk, которая выполняет собственную обработку. После завершения обработки вызывается диспетчер ввода-вывода, которому сообщается о завершении обработки пакета IRP. Диспетчер ввода-вывода переходит вверх по стеку и вызывает процедуру завершения следующего драйвера – драйвера файловой системы.
10. Вызывается процедура завершения драйвера файловой системы. После необходимого обслуживания вызывается диспетчер ввода-вывода, который планирует запуск асинхронного вызова процедуры. Асинхронный вызов запускается и копирует необходимые данные и код состояния в буфер пользовательского режима приложения резервного копирования. На этом этапе операцию ввода-вывода можно считать завершенной.
1.9 Сложности практической реализации
Стек ввода-вывода подсистемы хранения в семействе Windows Server описан в этой главе довольно подробно. Но помните, что стек подсистемы хранения не обслуживает устройства, поддерживающие несколько протоколов.
Чтобы повысить надежность и безопасность операционной системы Windows, компания Microsoft расширяет и улучшает методику сертификации и подписи драйверов. Поставщикам рекомендуется сертифицировать все обновления драйверов. Хорошим источником информации по этому вопросу может служить Web-узел компании Microsoft, в частности Web-страница по адресу: http://www.microsoft.com/hwdev/driver/drvsign. asp.
Резюме
Операционная система Windows NT проектировалась в качестве многоуровневой и расширяемой, особенно в контексте подсистем хранения и ввода-вывода данных. Создание драйвера соответствующего типа (например, драйвера мини-порта SCSIPort или мини-драйвера Storport) позволяет без проблем добавить поддержку нового устройства.
Драйвер фильтрации позволяет добавить новые функции для Windows NT. Компания Microsoft использовала подобный драйвер при создании приложения Hierarchical Storage Management.
В целом создание драйверов Windows NT требует серьезных знаний в этой области и доступа к подходящему программному инструментарию.
1
Глава 2. Серверные хранилища данных
Изначально системы хранения данных разрабатывались для мэйнфреймов и большинство из них были основаны на закрытых, частных технологиях. Для мини-компьютеров были созданы такие стандарты, как SCSI. С появлением персональных компьютеров серверные стандарты (SCSI и IDE) получили широкое распространенйе.
В этой главе рассматриваются системы хранения данных, подключенные к серверу (Direct Attached Storage – DAS), т.е. устройства, подключенные непосредственно к компьютеру под управлением Windows NT. В главе 1 описан стек ввода-вывода Windows NT в контексте подсистемы хранений данных. В этой главе внимание уделяется разработке стека ввода-вывода подсистемы хранения данных Windows NT для улучшения поддержки новых устройств Fibre Channel и SCSI. Подобные устройства воспринимаются Windows NT как подключенные непосредственно к компьютеру.
2.1 Интерфейс SCSI
Аббревиатура SCSI расшифровывается как Small Computer System Interface (интерфейс для малых компьютеров), что на данный момент кажется нелогичным, поскольку устройства SCSI обычно подключены к высокопроизводительным серверам и являются наилучшим выбором для использования в качестве подсистемы хранения для многопроцессорных центров хранения данных. Стандарты SCSI утверждаются техническим комитетом Т10 (http://www.tlO. org), подразделением Международного комитета INCITS (InterNational Committee for Information Technology Standards), который, в свою очередь, работает под эгидой Национального института стандартизации США (American National Standards Institute – ANSI; http://www. ansi.org).
Шина SCSI изначально разрабатывалась в качестве параллельной архитектуры отправки данных по 8- или 16-разрядной шине. Существовали и последовательные версии архитектуры SCSI, например SSA (Serial Storage Architecture) и 1394. До определенного времени эти архитектуры (особенно SSA) разрабатывались отдельно и лишь позднее были включены в проект стандарта SCSI-3. Оба стандарта – как SSA, так и 1394 – практически не используются на рынке корпоративных подсистем хранения данных, однако достаточно широко распространены на рынке потребительских устройств.
За годы своего существования стандарты SCSI были значительно усовершенствованы, появилось множество версий, которые различаются следующими параметрами:
ширина шины данных;
быстродействие шины данных;
количество устройств, которые могут быть подключены к одной шине;
электрические и механические характеристики шины;
максимальная длина шины;
тип архитектуры шины – последовательная или параллельная. Хотя SCSI исторически ассоциируется с параллельными шинами, компьютерная индустрия активно движется в сторону последовательной архитектуры, и стандарты SCSI не являются исключением.
Обратите внимание: SCSI представляет собой не единый стандарт, а определенный набор стандартов. В одних стандартах заложены механические и электрические характеристики, в других – наборы команд, которые должны быть реализованы устройствами. Эти стандарты реализуются и в других устройствах, например Fibre Channel.
В табл. 2.1 приведены различные стандарты SCSI и их характеристики.
Таблица 2.1. Стандарты и характеристики SCSI
Окончание табл. 2.1
Более старые стандарты, например SCSI-1, сегодня считаются морально устаревшими. Последний стандарт, SCSI-3, на самом деле представляет собой не единую спецификацию, а целое семейство спецификаций, развитие которых продолжается. Таким образом, SCSI следует рассматривать в качестве стандарта, определяющего набор команд и других спецификаций, относящихся к физической реализации этого интерфейса. Очевидно, что определенный стандарт можно взять в качестве основы для реализации нового носителя. Примером может служить тенденция к реализации набора команд SCSI для Fibre Channel и SSA. На данный момент к самым популярным устройствам относятся Ultra SCSI и SCSI-3.
Важным параметром считается баланс между расстоянием от устройства до адаптера шины и количеством устройств SCSI, которые можно подключить к шине. Чем больше количество устройств, подключенных к шине, тем
короче должна быть шина. Меньшее количество устройств позволяет удлинить шину. Кроме того, максимальная длина шины зависит от ее электрических характеристик. Обратите внимание, что эти рассуждения касаются исключительно интерфейса SCSI. Новые реализации, например iSCSI (см. главу 8), в значительной степени отменяют старые ограничения на расстояние, поскольку могут передавать команды и результаты их выполнения на большие расстояния, используя транспортный протокол IP.ч
Устройства SCSI последовательно подключаются к контроллеру. Каждое устройство, подключенное к шине, получает уникальный идентификатор. Идентификаторы SCSI не назначаются произвольно, так как используются для определения относительного приоритета устройства при конкуренции за пропускную способность шины данных между устройствами.
Устройства SCSI обратно совместимы друг с другом, а некоторые даже могут работать в нескольких режимах SCSI. Но в работе более новых устройств под управлением более старого контроллера существуют свои проблемы, которые выходят за пределы тем, рассматриваемых в этой книге. Те, кого интересует описание этих проблем, могут обратиться к списку литературы, приведенному в конце книги.
Высокая производительность устройства хранения данных не гарантирует аналогичной производительности и достаточной пропускной способности сервера. При оценке сервера важно анализировать скорость и пропускную способность не только подсистемы хранения данных, но внутренних шин сервера. Большинство высокопроизводительных серверов используют одновременно несколько адаптеров SCSI, которые подключены к разным шинам PCI. При такой конфигурации шина PCI не станет «узким местом» в общей производительности системы.
Для проведения необходимых операций ввода-вывода одно устройство, подключенное к шине SCSI, будет работать как инициатор, а другое – как целевое устройство. Например, на сервере под управлением Windows NT контроллер SCSI будет инициатором, а жесткий диск или накопитель на магнитной ленте – целевым устройством.
Хотя подобное использование устройства кажется необычным, большинство адаптеров шины SCSI поддерживают обе роли (в зависимости от того, реализована ли подобная функций в прошивке адаптера шины). Контроллер iSCSI относится к устройствам, одновременно представляющим собой как целевое устройство, так и инициатор. Компьютер может быть целевым устройством при экспорте локальных дисков и инициатором при использовании дисков удаленного контроллера iSCSI.
Инициатор отправляет команду целевому устройству, которое выполняет запрошенные операции, отправляя по завершении работы соответствующий ответ. Целевое устройство SCSI остается пассивным до получения команды от инициатора. После получения команды целевое устройство принимает на себя управление шиной перед ответом на команду, например перед отправкой запрошенных данных. Инициатор и все остальные устройства на общей шине совместно определяют хозяина шины.
При загрузке сервера Windows NT контроллер SCSI, который часто называют контроллером шины (об этом речь идет далее), выдает соответствующую команду каждому подключенному к шине и обнаруженному устройству SCSI. Это команда Report LUNs, благодаря которой целевое устройство возвращает список номеров логических элементов, управляемых устройством. (Логические элементы описываются в разделе 2.5.)
Не менее важными являются и команды Reserve/Release. При наличии нескольких инициаторов одному из них может потребоваться исключительный доступ к целевому устройству. Хорошим примером может служить получение эксклюзивного доступа к накопителю на магнитной ленте. Если два инициатора будут поочередно записывать данные на магнитную ленту, последняя будет содержать бесполезную информацию. Команды Reserve и Release позволяют обеспечить управление доступом.
Существует два типа команд интерфейса SCSI Reserve и Release. Один называется непостоянным резервированием, поскольку сброс параметров целевого устройства приводит к аннулированию резервирования. Другой тип – постоянным резервированием, поскольку резервирование сохраняется и после сброса параметров целевого устройства. Сброс параметров может потребоваться, если устройство-инициатор столкнется с проблемами после операции резервирования. Еще одна команда (стороннее резервирование) позволяет инициатору зарезервировать целевое устройство для другого устройства. Отмена резервирований должна осуществляться устройством, выполнившим их ранее, или же устройством, на правах которого выполнялось стороннее резервирование.
Команда Extended Сору позволяет инициатору отправить целевому устройству SCSI команду на копирование данных между двумя наборами устройств SCSI. Устройства, между которыми копируются данные, могут (не обязательно) отличаться от устройства, которое получило и обрабатывает команду Extended Сору. Дочерняя команда Receive Copy Results собирает сведения о завершении выполнения команды Extended Сору. Полученный результат может использоваться для определения характера выявленных ошибок команды Extended Сору.
В стандарте SCSI-3 определено и множество дополнительных команд, которые включают в себя блочно-ориентированные и графические команды, а также команды модификатора.
Операционная система Windows NT требует от приложений использованиясквозного интерфейса SCSI, с помощью которого команды передаются устройствам SCSI. На самом деле интерфейс задействуется и для отправки команд устройствам Fibre Channel, которые поддерживают такой же набор команд SCSI. Приложения используют программный интерфейс DeviceloControl с параметром IoControlCode, равным IOCTL_SCSI_PASS_ THROUGH или IOCTL_SCSI_PASS_THROUGH_DIRECT. В первую очередь приложению требуется получить дескриптор файла для устройства SCSI посредством функции CreateFile. Начиная с Windows 2000, компания Microsoft усилила схему безопасности, требуя от приложений указывать тип доступа (чтение/запись) в параметрах функции CreateFile и позволяя только ограниченному количеству учетных записей осуществлять запись. Таким образом, функция CreateFile вернет сообщение об ошибке для всех пользователей, которым системный администратор не разрешил запись данных.
Хотя этот интерфейс вполне работоспособен, при детальном рассмотрении архитектура кажется не вполне целостной. С одной стороны, в операционной системе реализован принцип «владею всем, что вижу» по отношению к таким ресурсам, как жесткие диски. С другой стороны, Windows даже не воспринимает резервирования и освобождения устройства хранения данных прикладным приложением. В рамках более эффективной архитектуры приложение будет запрашивать у операционной системы разрешение на проведение необходимой операции, после чего система будет или отказывать, если запрос не может быть выполнен, или выполнять запрошенную операцию, возвращая приложению соответствующие служебные данные. Будет ли развитие Windows двигаться в этом направлении, можно только догадываться.
2.2 Интерфейсы IDE, EIDE и АТА
Устройства с интерфейсом IDE являются самыми распространенными устройствами хранения данных в мире персональных компьютеров, особенно в потребительском сегменте рынка. Аббревиатура IDE расшифровывается как Integrated Drive Electronics (встроенный интерфейс накопителей). В свою очередь, АТА означает AT Attached, где под AT подразумевается классическая модель компьютера IBM PC AT. Обе аббревиатуры указывают на один и тот же стандарт подключения жестких дисков. Основная идея этого интерфейса заключается в интеграции контроллера в жесткий диск, благодаря чему IDE и называется встроенным интерфейсом. В стандарте IDE/АТА описаны характеристики 16-разрядной шины.
Стандарт IDE/АТА, как и. SCSI, пережил несколько модификаций. В оригинальном стандарте описывалось использование режима программируемого ввода-вывода (programmed input/output – РЮ), в котором центральный процессор играет важную роль при каждой операции ввода-вывода данных. В более поздних стандартах перешли к использованию прямого доступа к памяти (direct memory access – DMA), при котором ввод-вывод данных выполняется без участия центрального процессора.
Кабель IDE/АТА поддерживает подключение двух накопителей. Один из них является ведущим (master), а второй – ведомым (slave). В любой момент времени только один из дисков может быть активен. Более новый стандарт EIDE (Extended IDE) поддерживает четыре накопителя, так как один контроллер EIDE выступает в роли двух контроллеров IDE. Многозадачная операционная система, например Windows NT, может использовать возможности контроллера EIDE для одновременной передачи двух команд ввода- вывода на два «канала» IDE.
Ниже описаны особенности каждого из стандартов АТА.
АТА-1 требует использования программируемого, режима ввода-вывода.
АТА-2 был представлен институтом ANSI в 1996 году. В нем описано использование быстрых режимов РЮ и допускается применение прямого доступа к памяти (DMA). Кроме того, стандарт АТА-2 позволяет использовать технологию Plug and Play с помощью команды идентификации накопителя, возвращающей информацию о структурных особенностях диска.
АТА-3 был представлен в 1997 году и может рассматриваться в качестве минимальной модернизации стандарта АТА-2 для повышения надежности в быстрых режимах передачи данных. Главной особенностью стандарта АТА-3 стала поддержка технологии самоконтроля, анализа и отчетности SMART, отвечающей за контроль состояния жестких дисков. Технология SMART поддерживается накопителями SCSI и IDE.
В ATA-4/ATAPI была введена поддержка таких новых устройств, как дисководы для компакт-дисков и накопители Jazz. Аббревитура ATAPI расшифровывается как AT Attachment Packet Interface. В этом стандарте также описана поддержка Ultra DMA, позволяющая передавать данные с удвоенной скоростью по сравнению с обычным режимом DMA.
Устройства АТА по-прежнему развиваются и постепенно сокращают отрыв в производительности и надежности от устройств SCSI, пытаясь удерживать свое преимущество в цене. При нынешнем увеличении надежности аппаратного обеспечения и появлении специализированного программного обеспечения (например, программных массивов RAID, которые рассматриваются в главе 9) интерфейс АТА со временем может сыграть более важную роль в промышленных системах хранения данных. Однако обсуждение подобных перспектив выходит за рамки данной книги.
2.3 Модель мини-драйвера IDE
В архитектуре Windows Server 2003 поддерживается новая модель мини- драйвера IDE, которая должна заменить существующую модель драйвера IDE. Новый драйвер порта, предоставляемый Microsoft, работает быстрее, обслуживает несколько каналов и позволяет отказаться от разделения канальных интерфейсов и интерфейсов управления. Новая модель драйвера предоставляет более широкие возможности поставщикам жестких дисков; например, драйвер мини-порта от поставщика может изменить значение тайм- аута запросов и выбрать режим (DMA или РЮ) для каждого конкретного запроса. Компания Microsoft считает, что в перспективе устройства АТА будут играть более важную роль, поэтому продолжает развивать модель драйвера АТА. Будем надеяться, что в новых изданиях этой книги появятся дополнительные подробности, которые станут известными в процессе развития новых моделей драйверов.
2.4 Развитие адаптеров шин (НВА)
Изначально такие устройства хранения данных, как жесткие диски и накопители на магнитной ленте, подключались непосредственно к серверу. Единицы хранения размещались непосредственно в сервере или внешних отсеках, подключаемых к серверу с помощью контроллера ввода-вывода. Последний представлял собой плату расширения или модуль системной платы. Со временем для описания контроллеров начал использоваться термин адаптер шины (host bus adapter – НВА, т.е. адаптер, который подключен к шине ввода-вы- вода).
На рис. 2.1 демонстрируется сервер с платой контроллера ввода-вывода и несколькими устройствами, подключенными к контроллеру по шине SCSI. Хранилище данных, подключенное к серверу, – это неплохой вариант для небольших изолированных локальных сетей (например, для локальных сетей определенного отдела компании), однако подобные решения крайне плохо масштабируются. К одной из очевидных проблем относится количество единиц хранения, которые могут быть использованы при таком подключении.
Рис. 2.1. Хранилище SCSI, подключенное к серверу
Рис. 2.2. Интеллектуальная подсистема хранения данных
Еще одна проблема – наличие лишь одной шины SCSI для выполнения всех операций ввода-вывода.
Следующим этапом в развитии индустрии хранения данных была разработка подсистем хранения с собственными контроллерами ввода-вывода (рис. 2.2).
Представленная на рис. 2.2 подсистема хранения данных обладает дополнительными функциональными возможностями, что привело к переосмыслению некоторых терминов. Система на рис. 2.1 имеет только один контроллер ввода-вывода, который подключен к серверу. Система на рис. 2.2 содержит два контроллера, что потенциально может привести к путанице при указании
контроллера. Если существуют также дополнительные подсистемы хранения данных с собственными контроллерами, все может стать еще более запутанным. В связи с этим и была принята терминология, в которой контроллер, подключенный к серверу, называется адаптером шины. Адаптер шины может обеспечивать подключение к шине SCSI, IDE или интерфейсу Fibre Channel.
2.5 Логические единицы хранения (LUN)
Единицы хранения, которые расположены в схеме, приведенной рис. 2.2, за контроллером подсистемы хранения, должны поддерживать определенный метод адресации. Эти единицы называются LUN (logical unit number). В контексте приложений хранения данных или Windows NT три отдельных идентификатора взаимодействуют друг с другом для уникального определения каждой LUN. Обратите внимание, что в литературе, посвященной стандарту SCSI, используется выражение «определение LUN для целевого устройства SCSI», однако я предпочитаю выражение «для идентификатора SCSI», поскольку устройство SCSI может быть как целевым, так и инициатором. Это различие станет еще более очевидным при распространении интерфейса iSCSI, где устройство SCSI может быть инициатором в одном случае и целевым устройством – в другом.
Команда SCSI отправляется устройству, которое уникально идентифицируется тремя параметрами.
Шина SCSI (адаптер шины может поддерживать несколько шин или на сервере Windows NT может быть установлено несколько адаптеров шин). Операционная система Windows NT поддерживает до восьми шин для одного адаптера шины.
Идентификатор устройства SCSI на шине. Операционная система Windows NT поддерживает до 128 идентификаторов SCSI для одной шины.
Идентификатор SCSI LUN. Операционная система Windows NT SP4 и более поздние версии Windows NT поддерживают до 254 идентификаторов LUN на один идентификатор SCSI. Иногда возможность поддержки такого большого количества идентификаторов LUN обозначается термином Large LUN support (расширенная поддержка LUN). Предыдущие версии Windows NT поддерживали до восьми идентификаторов LUN на один идентификатор SCSI. Стандарт SCSI-2 поддерживает до восьми LUN на идентификатор SCSI. В свою очередь, в стандарте SCSI-3 описана поддержка 64-разрядного значения, указывающего количество LUN на идентификатор SCSI, но конкретное количество зависит от типа устройства.
Поддержка такого большого количества единиц LUN (более восьми) зависит от драйвера адаптера шины, а также от устройств SCSI, которые должны обработать команду Report LUNs (SCSI). Более новые драйверы поддерживают по умолчанию более восьми LUN. Более старые драйверы могут вообще не поддерживать такой идентификатор, как LUN, или же потребуют изменений в системном реестре Windows NT. Операционная система Windows NT обнаруживает наличие таких устройств, отправляя команду Report LUNs на каждое устройство с идентификатором LUN, равным 0. Для активизации в Windows NT поддержки большого количества единиц LUN устройство должно правильно обрабатывать команду Report LUNs.
2.6 Драйвер Storport
В главе 1 рассматривается стек ввода-вывода Windows NT, в том числе один из важных его компонентов – драйвер SCSIPort (разработанный в Microsoft). Этот драйвер взаимодействует с драйвером мини-порта, создаваемым поставщиком конкретного устройства и предназначенным для обслуживания последнего. До выхода Windows Server 2003 устройства хранения данных различного типа, например более старые жесткие диски SCSI, новые устройства SCSI-3 и Fibre Channel, использовали специфичный для устройства драйвер мини-порта, который подключался к драйверу SCSIPort. Этот сценарий имел несколько недостатков.
В описываемой модели подразумевается, что устройства Fibre Channel имеют возможности, сопоставимые с аналогичными функциями устройств SCSI, что не имеет под собой реальной основы.
Драйвер SCSIPort использовал однопоточную модель, не поддерживая полнодуплексный режим. Это означает, что одни запросы не могли выполняться, пока в очереди находились другие запросы, и наоборот. При обслуживании прерывания драйвер мини-порта не мог принимать новые запросы и сообщать о завершении уже выполненного запроса. Использование Windows на многопроцессорных компьютерах делало эту проблему еще более актуальной.
Драйвер порта содержал информацию, которая не отправлялась драйверу мини-порта, что требовало от последнего самостоятельного сбора необходимых сведений с помощью нескольких запросов. В частности, это было характерно для работы со списками разборки/сборки[4].
Рис. 2.3. Драйвер Storport в иерархии драйверов Windows Server 2003
■ Не удовлетворенные таким положением вещей, поставщики устройств Fibre Channel решили проигнорировать драйвер SCSIPort (созданный компанией Microsoft) и реализовали комплексные драйверы (обеспечивающие возможности как драйвера порта, так и драйвера мини-порта) или собственные драйверы портов и мини-портов. Поскольку этот процесс был основан на инженерном анализе функций драйвера порта, полученные драйверы в лучшем случае работали с минимальным количеством проблем. Зачастую возникали ситуации, при которых два устройства от разных поставщиков не могли одновременно работать на компьютере под управлением Windows NT.
В Windows Server 2003 компания Microsoft представила новую модель драйвера с поддержкой драйвера порта Storport (рис. 2.3). Драйвер Storport предназначен для использования поставщиками более новых устройств SCSI-3 и Fibre Channel. Таким образом, Microsoft намерена постепенно прекратить поддержку драйвера SCSIPort, который, хотя и не удален из Windows, предназначен для использования только вместе с более старыми устройствами хранения данных.
На данном этапе поставщикам адаптеров шины предлагается создавать драйверы мини-портов, которые должны подключаться к драйверу Storport, а не к SCSIPort. Чтобы упростить процесс перехода, Microsoft сделала драйвер Storport обратно совместимым с моделью SCSIPort. Это значит, что поставщики, не желающие затрачивать время и силы, могут воспользоваться
некоторыми (но не всеми) преимуществами новой модели драйверов. Для максимального использования возможностей новой модели драйверов поставщикам требуется выполнить больше работы, чем обычная перекомпиляция и сборка с другой библиотекой.
Новая архитектура обеспечивает значительный прирост производительности, который достигается несколькими методами.
Новая модель драйверов поддерживает полнодуплексный режим, при котором новый запрос может быть помещен в очередь драйвера одновременно с выполнением операций ввода-вывода. Новая модель поддерживает использование прерываний для выполнения большего объема работы драйвером мини-порта, созданным поставщиком. Обратите внимание, что эта эффективность достигается за счет усложнения структуры драйвера мини-порта, так как от него требуется поддержка синхронизации. Драйверы мини-портов SCSIPort поддерживали только полудуплексный режим и работали не так эффективно, однако поддержка синхронизации не обеспечивалась (поскольку эта обязанность была возложена на драйвер порта).
Новая модель минимизирует количество вызовов между драйверами порта и мини-порта. Например, в старой модели драйвер мини-порта осуществлял несколько вызовов драйвера SCSIPort для получения списков разборки/сборки.
Кроме повышения быстродействия, модель Storport обеспечивает ряд Других преимуществ.
Модель Storport улучшает взаимодействие между драйверами порта и мини-порта. В модели SCSIPort драйверу порта не разрешалось сообщать о занятости устройства. В свою очередь, модель Storport позволяет драйверу мини-порта передавать драйверу Storport команды на приостановку и возобновление передачи данных, а также сообщать о занятости адаптера.
В новой архитектуре реализован сложный механизм управления ошибками. Драйвер SCSIPort просто пытался повторно инициировать шину, что требует немало ресурсов и нарушает стабильность работы системы. При соответствующей поддержке драйвера мини-порта от независимых поставщиков аппаратного обеспечения модель Storport позволяет аннулировать параметры конкретной логической единицы, устройства и только в крайнем случае – самой шины. Еще одним улучшением в механизме обработки ошибок является расширение списка ошибок, который поддерживается драйвером порта. Модель Storport позволяет обрабатывать сообщения об ошибках, которые выдают более новые устройства SCSI-3, в то время как драйвер SCSIPort маскировал такие ошибки в более старый тип ошибок, поддерживаемых драйвером.
Рис. 2.4. Работа с очередью запросов в модели Storport
Все новые возможности имеют минимальный шанс нарушить нормальную работу системы, гак как модель Storport обратно совместима с SCSIPort. Поставщики могут просто перекомпилировать и скомпоновать старый код с библиотекой драйвера Storport, (вместо библиотеки драйвера SCSIPort), не затрачивая усилий на перенос кода на другую платформу. Это позволит использовать новую модель, хотя и не предоставит всех преимуществ, доступных при полноценном переносе.
Новая архитектура предоставляет интерфейс, отменяющий необходимость создания «виртуального устройства» (ghost device). Модель SCSI не позволяет приложению запрашивать функции без монтирования модуля мини-порта. В свою очередь, модель Storport не требует создания виртуального устройства, поддерживая запрос функций даже без монтирования этого модуля.
Кроме всего прочего, в новой архитектуре улучшен интерфейс с целью обеспечить соответствие требованиям поставщиков систем хранения данных высокого уровня. Особенно это касается поставщиков систем RAID и Fibre Channel. Например, старая модель SCSIPort поддерживала ограниченный набор возможностей по управлению'очередью запросов. Новые устройства, в свою очередь, требуют расширенного управления очередью. Модель Storport поддерживает использование 254 запросов на каждую логическую единицу каждого адаптера. Максимальное количество запросов на адаптер ограничено только количеством логических единиц, поддерживаемых адаптером (рис. 2.4).
Еще одно преимущество иерархической структуры в модели Storport заключается в Етличии интерфейса управления для конфигурации и управления высокоуровневыми устройствами хранения данных. Этот интерфейс
основан на инструментарии управления Windows (Windows Management Instrumentation – WMI). Интерфейс используется другими элементами Windows, например интерфейсом управления для командной строки. Технология WMI рассматривается в главе 7. Интерфейс управления WMI поддерживает четыре различных класса WMI.
Класс адаптера шины. На компьютере может быть установлено несколько таких адаптеров и для каждого из них создается экземпляр такого класса.
Класс каналй. Каждый адаптер может иметь один или несколько каналов, которые соединяют адаптер с его физическими дисками.
Класс массива дисков. Каждый канал может иметь один или несколько массивов дисков или не иметь таковых вообще.
Класс физического диска. Каждый адаптер может иметь один или несколько подключенных физических дисков или не иметь таковых вообще.
2.7 Сложности практической реализации
В новой модели драйверов Storport оптимизированы функции ввода-вы- вода и общая производительность системы управления. Однако системный администратор и менеджеры по закупкам в информационных отделах компаний должны знать, что новая модель драйверов Storport доступна только в Windows Server 2003. Тем же, кто сделал ставку на платформу Windows, рекомендуется ознакомиться с планами поставщика оборудования по переходу к модели Storport и наравне с этим проанализировать поддержку устройств конкретного поставщика в Windows 2000, включая подробности реализации драйвера.
Особое внимание необходимо обратить на параметры пропускной способности системы при использовании модели драйверов SCSIPort (которая скоро станет устаревшей), если эта модель поддерживается поставщиком. Кроме того, стоит обратить внимание на наличие продукции поставщика, в которой вообще не используется модель драйверов SCSIPort. Следует проверить наличие сертификации и поддержки частного драйвера всеми заинтересованными сторонами. Наконец, нужно узнать о возможности «безболезненного» перехода с текущей технологии для Windows 2000 к модели драйверов Storport в Windows Server 2003.
Резюме
Стандарт SCSI развивается уже много лет и на данный момент превратился в группу стандартов. Стандарты SCSI значительно изменились в контексте
увеличения скорости передачи данных. Пользователям требуется компромисс между количеством устройств, которые подключены к шине, и длиной шины. Кроме того, в процессе развития стандартов SCSI возникли новые команды, например Extended Сору.
Интерфейсы ATA/IDE также не отстают и продолжают развиваться, благодаря чему возрастает их надежность и производительность.
Маскировка LUN в Windows NT может выполняться драйвером адаптера шины, который предоставляется производителем.
В Windows Server 2003 внедрена новая модель драйверов Storport, предназначенная для замены старой модели SCSIPort. Более новый драйвер Storport ориентирован на поддержку высокопроизводительных интеллектуальных устройств SCSI-3 и Fibre Channel. По сравнению с драйвером SCSI- Port драйвер Storport обеспечивает повышенное быстродействие, расширенные функции по управлению и обработке ошибок. Поставщики устройств могут максимально использовать возможности Storport, переписав драйверы для использования новой модели. И даже обычная перекомпоновка драйвера с библиотекой новой модели Storport дает возможность задействовать некоторые из функций Storport.
Индустрия хранилищ данных развивается от серверов с непосредственно подключенными устройствами в сторону архитектуры клиент/сервер, в которой применяется несколько серверов в локальной сети. При таком подходе одни серверы предназначены для приложений, управляющих базами данных, а другие выделяются исключительно для хранения данных. Выделенные серверы для хранения данных и называются хранилищами, подключенными к сети (NAS), чему посвящена следующая глава.
Глава 3. Сетевые хранилища данных
В предыдущей «главе описаны хранилища данных, подключаемые к серверу. Вне зависимости от размещения устройств (внутри сервера или во внешних стойках), только один сервер имеет к ним доступ. В этой главе рассматривается следующее поколение систем хранения данных: хранилища, подключенные к сети (Network Attached Storage – NAS).
Сначала обратимся к истории N AS, после чего рассмотрим стек сетевых протоколов семейства операционных систем Windows Server и архитектуру файловых систем CIFS (Common Internet File System) и NFS (Network File System). Далее вкратце обсуждаются технические аспекты, связанные с необходимостью обслуживания клиентских систем, работающих под управлением различных операционных систем с отличающимися файловыми системами. И в завершение описывается роль Windows в реализации устройств NAS.
3.1 Появление NAS
После появления серверных хранилищ данных по разным причинам возникла необходимость установки нескольких серверов с непосредственно подключенными к ним устройствами хранения данных. Доступ к хранилищам осуществлялся с помощью сетевой файловой системы (обычно в середине 1980-х годов для этого использовалась NFS). Возникновение и развитие архитектуры клиент/сервер, в частности мэйнфреймов и клиентских терминалов, привело к всеобщей реализации данной архитектуры в коммерческих приложениях уровня предприятия. -
Устройства хранения данных оставались достаточно дорогими, а потребность в объемах хранимых данных постоянно возрастала. Возможность установки большего количества устройств ограничивалась количеством жестких дисков, подключаемых к одному серверу (обычно поддерживалось семь или восемь адресов, причем адаптеру шины также требовался один из адресов; развитие стандарта SCSI привело к отмене этого ограничения). В результате приходилось устанавливать множество однотипных серверов. Наконец, операции ввода-вывода были ограничены пропускной способностью шины ввода- вывода. Только установка большего количества серверов позволяло снизить нагрузку на шину каждого сервера.
Производители воспользовались сложившейся ситуацией и приступили к развитию концепции сетевых хранилищ данных. Как отмечает Том Кларк (Tom Clark) в книге Designing Storage Area Networks, NAS представляет собой скорее маркетинговый, чем технический термин. Устройства NAS разрабатывались как простые в использовании, управлении и развертывании. Кроме того, устройства NAS представлялись в качестве специализированных устройств хранения данных, обеспечивающих оптимальную пропускную способность операций ввода-вывода. Хотя в некоторых случаях это соответствовало истине, т.е. операционные системы NAS были максимально упрощены, чаще всего NAS оказывались обычными, минимально «замаскированными» серверами общего назначения. ДаЖсе терминустройство NAS Указывает на специализированное устройство, а не на обычный сервер, к которому подключено множество устройств хранения данных[5].
Устройство NAS включает в себя серверное программное обеспечение, которое работает под управлением определенной операционной системы. Более того, стек программного обеспечения NAS основан на стандартной серверной файловой системе с добавлением стека ввода-вывода, основанного на коде сетевого сервера, стеках сетевого протокола и сетевой файловой системы (рис. 3.1). Последняя предоставляет такие возможности распределенной файловой системы, как кэширование и синхронизация. Три дополнительных элемента на рис. 3.1 обозначены серым цветом.
В целом сетевые особенности устройства NAS показаны на рис. 3.1 слева, а стек локальной файловой системь! и подсистемы хранения – справа. Чтобы упростить изложение, рассмотрим только стек протоколов TCP/IP, хотя иногда применяются другие сетевые протоколы, такие, как UDP/IP или устаревший Netware IPX/SPX.
На рис. 3.1 программное обеспечение сервера NAS отправляет запрос ожидания TCP/IP и ожидает входящего запроса от клиента. После того как клиент отправит запрос, ожидание сервера завершается и начинается сеанс TCP/IP. Как только сеанс TCP/IP будет установлен, клиент может пройти аутентификацию и отправить запрос на открытие, чтение или запись файлов по протоколам CIFS/SMB или NES (эти протоколы рассматриваются далее в главе). Как только программное обеспечение NAS получает запрос на ввод- вывод данных файла, сервер NAS использует локальную файловую систему для выполнения операции ввода-вывода. Результат операции (считанные данные или статус после записи) отправляется клиенту с помощью сетевой файловой системы и стека протоколов сетевого устройства.
Рис. 3.1. Стек ввода-вывода устройства NAS
Производители устройств NAS придерживаются разных стратегий при разработке операционных и файловых систем, применяемых в устройствах NAS:
использование стандартной операционной системы, например Windows NT или UNIX;
разработка собственных операционной и файловой систем, например Network Appliance;
приобретение операционной и файловой систем у другого производителя.
3.2 Сетевой стек Windows NT
Разобраться в особенностях стека сетевого ввода-вывода Windows NT важно по нескольким причинам. Клиент Windows NT использует стек сетевого ввода-вывода для получения доступа к ресурсам, которые находятся под управлением сервера, а также для передачи данных. Кроме того, при использовании сетевого хранилища часто возникает ситуация, когда один сервер получает доступ к ресурсам, которыми управляет другой сервер. Хорошим примером будет Wob-сервер под управлением Windows NT, который для ответа на запрос клиента запрашивает базу данных, размещенную на отдельном сервере SQL под управлением Windows NT. Web-сервер получает доступ к серверу SQL средствами стека сетевого ввода-вывода Windows NT.
Рис. 3.2. Сетевой стек Windows NT
На рис. 3.2 показан стек сетевого ввода-вывода Windows NT. В разделах 3.2.1–3.2.6 рассматриваются различные компоненты, представленные на рис. 3.2 снизу вверх (а также стек ввода-вывода).
Сетевой платой обычно управляет драйвер, совместимый со спецификацией NDIS (Network Driver Interface Specification). Она представляет собой интерфейс, обеспечивающий взаимодействие драйверов сетевой платы со стеком сетевых протоколов более высокого уровня. Следующий уровень – это стек TCP/IP. Термин TCP/IP используется для описания всех компонентов, которые задействованы в передаче данных по сети, например IP, DHCP или TCP. К следующему уровню относится интерфейс транспортного драйвера.
Уровнем выше над стеком сетевых протоколов TCP/IP находится интерфейс транспортного драйвера (Transport Driver Interface – TDI). Этот высокопроизводительный интерфейс режима ядра предназначен для сетевых приложений, которым требуется запрос и получение услуг сетевых транспортных
протоколов. Интерфейс TDI реализован в виде библиотеки, к которой подключаются драйверы режима ядра; он позволяет осуществлять связь по сети и пытается сократить количество операций копирования данных, например между буфером приложения и буфером сетевого транспортного протокола.
В частности, TDI позволяет приложениям регистрировать функции обратного вызова. Когда приложение получает пакет с данными, вызывается указанная функция обратного вызова. Процедура обратного вызова может просто просматривать пакет с данными, особенно если он небольшой, и сообщать, что обработка пакета завершена (после чего он будет отмечен как успешно доставленный). Если необходимо, клиент может копировать пакет в буфер для последующей обработки.
На следующем уровне находится подсистема буферизации перенаправленных дисков (Redirected Drive Buffering Subsystem – RDBSS), которая отвечает за предоставление кода буферизации всем перенаправителям (redirectors). Подсистема обеспечивает полноценное взаимодействие с диспетчером кэша Windows NT для всех сетевых файловых систем. Подсистема RDBSS впервые появилась в Windows 2000; до этого момента всем сетевым файловым системам требовался полноценный драйвер, который обеспечивал взаимодействие с операционной системой.
Эти устройства обеспечивают работу функций, относящихся к конкретной сетевой файловой системе или протоколу и пользуются услугами RDBSS для обработки рутинных операций взаимодействия с Windows NT. В Windows 2000 и Windows ХР предоставляется несколько мини-перенаправителей.
Мини-перенаправителем CIFS оснащены Windows 2000, Windows ХР и Windows Server 2003. В более ранних версий Windows NT был реа- лизван монолитный перенаправитель. Код RDBSS, общий для всех мини-перенаправителей, реализовался независимо каждым поставщиком. Технология CIFS более подробно рассматривается в разделе 3.3.
Мини-перенаправитель WebDAV (Web Distributed Authoring and Ver- sioning) поддерживает протокол HTTP 1.1 и расширения WebDAV для чтения и записи документов Web. Он предоставляет возможности, позволяющие назначать буквы дисков серверу независимо от протокола доступа к последнему. Назначение поддерживается как для серверов HTTP, так и для серверов CIFS. Корпоративные брандмауэры обычно разрешают прохождение пакетов HTTP и зачастую блокируют запросы/ответы протокола CIFS. Таким образом, мини-перенаправитель WebDAV обеспечивает доступ к серверам HTTP через брандмауэры, блокирующие пакеты CIFS. Поскольку стандарты XML и HTTP играют все большую роль, важность мини-перенаправителя WebDAV со временем будет увеличиваться. Обратите внимание, что WebDAV представляет собой исключительно клиент-серверный протокол, не поддерживающий взаимодействие между серверами.
Система Windows NT Services for UNIX (SFU) поставляется с мини- перенаправителем, поддерживающим протокол NFS. Файловая система NFS рассматривается в разделе 3.4.
В Windows поддерживается универсальное соглашение об именовании (Universal Naming Convention – UNC), необходимое для получения доступа к удаленным файлам. Поддержка UNC своими корнями уходит во времена MS DOS 3.3, которая существовала задолго до создания Windows NT. Имена UNC позволяют приложениям указывать файлы согласно их расположению на сервере и общем ресурсе (помните, что на одном сервере может существовать несколько общих ресурсов). Формат имен UNC выглядит следующим образом:
\\ИмяСервера\Ресурс\Подкаталог1\...\ПодкаталогN\ИмяФайла
Поддержка UNC в разных версиях Windows различается следующими параметрами:
максимальная длина пути UNC;
максимальная длина каждого элемента пути UNC, например длина имени подкаталога;
максимальная длина имени сервера.
Для предоставления приложениям и утилитам возможности использования сетевых ресурсов с помощью путей UNC компания Microsoft создала поставщика множественных имен UNC (Multiple UNC Provider).
Поскольку Windows NT поддерживает несколько сетевых файловых систем, MUP работает как маршрутизатор, перенаправляя запросы нужной сетевой файловой системе, или же как мини-перенаправитель, который поддерживает конкретную сетевую файловую систему. Маршрутизация выполняется одним из двух способов.
1. Проверяется кэш MUP, чтобы узнать, осуществлялось ли ранее подключение к серверу. В этом случае используется мини-перенаправитель, который применялся при последнем подключении.
2. По порядку опрашивается каждый мини-перенаправитель для подключений UNC, которые отсутствуют в кэше.
Маршрутизатор множественных поставщиков (Multi-Provider Router – MPR) предоставляет функции, аналогичные MUP, перенаправляя запросы приложений соответствующему мини-перенаправителю, однако существует два отличия.
Код MPR работает в пользовательском режиме, а не в режиме ядра.
Маршрутизатор MPR предназначен для приложений, не использующих пути UNC, например для приложений, применяющих WinlNet API (термин WinlNet расшифровывается, как Windows Internet). Это программный интерфейс приложений, который предоставляет дополнительный уровень абстракции для программ, использующих стандартные протоколы Internet – HTTP, FTP и Gopher.
Маршрутизатор MPR представляет собой динамически подключаемую библиотеку с удобным интерфейсом от компании Microsoft. Интерфейс этой библиотеки используется поставщиками устройств для создания мини-пере- направителей, причем библиотека устанавливается при установке перенапра- вителя.
Мини-перенаправитель CIFS в Windows 2000 поддерживает функцию клиентского кэширования, которая позволяет кэшировать файлы локально на компьютере клиента. Кэшироваться могут как файлы документов (например, файлы Microsoft Word или Excel), так и выполняемые файлы (например, файлы приложений из пакета Microsoft Office). Кэширование инициируется одним из двух способов.
Пользователь явно запрашивает кэширование.
Мини-перенаправитель инициирует кэширование при открытии файла.
Кэширование на стороне клиента обеспечивает достаточную производительность и масштабируемость системы. Клиент может продолжать работу даже после отключения от сервера (например, при отказе в работе сервера или при нарушении работы сети). Нагрузка на сервер снижается, и один сервер может обслуживать большее количество клиентов. Клиентские приложения работают быстрее, так как получение файла с локального диска осуществляется быстрее, чем по сети.
Кэширование возможно не для всех файлов – только для тех файлов общего ресурса, которые явно отмечены (администратором сервера) как разрешенные для кэширования. Эта информация передается мини-перенаправи- телю CIFS в ответном пакете SMB (Server Message Block). При этом протокол SMB модифицирован для доставки клиенту информации о возможности кэширования файлов, а также о типе кэширования, выполняемого клиентом. Допускается три типа кэширования.
Общие ресурсы, в которых разрешено кэширование только документов.
Общие ресурсы, в которых разрешено кэширование только программ.
Общие ресурсы, в которых кэширование запрещено.
На данный момент только клиенты CIFS от компании Microsoft поддерживают клиентское кэширование. Клиентские приложения других производителей также кэшируют файлы, но только при наличии активного подключения к серверу и только файлы, открытые клиентом на сервере. Клиентское кэширование, реализованное в Windows, позволяет кэшировать файлы даже при отключении от сервера. Кроме того, поддерживается кэширование ранее открытых файлов, которые закрыты в текущий момент. Кэшированные файлы остаются доступными для клиента, даже если он отключен от сервера.
Технология клиентского кэширования в Windows 2000 проектировалась для предоставления соответствующих функций приложениям Windows, для которых кэширование происходит совершенно незаметно. Хотя кэширование должно быть незаметным и для пользователей, им все же придется вмешиваться в процесс синхронизации данных и обработки ошибок при клиентском кэшировании. Другими словами, если несколько клиентов вносят конфликтующие между собой изменения в один документ в собственных кэшах, пользователю выдается сообщение о программном конфликте, причем решить проблему пользователь должен самостоятельно.
Можно выделить ряд компонентов, которые совместно предоставляют клиентам необходимые функции.
Мини-перенаправитель CIFS.
Программный интерфейс приложений, который предоставляется мини- перенаправителем CIFS и связанными с ним компонентами пользовательского режима. Этот интерфейс позволяет приложениям использовать предоставляемые возможности и управлять ими.
Компоненты пользовательского режима, которые получают данные с сервера и записывают их в локальный кэшированный файл.
Локальная база данных, которая отслеживает данные, кэшированные локально, и их текущее состояние. В этой базе данных создаются записи для каждого общего ресурса, к которому подключается клиент, (ресурс должен быть отмечен, как допускающий кэширование) и для каждого поддерживающего кэширование файла, который открывается клиентом. Кроме того, записи создаются для всех каталогов, которые размещены между файлом и корнем общего ресурса. Для каждой записи, созданной в базе данных, параметры безопасности пользователя и гостевого пользователя клиентской системы копируются с сервера CIFS. База данных работает в качестве файловой системы для файлов, кэшированных на локальном компьютере.
При первом кэшировании файл программы отмечается как разреженный и локальная копия постепенно заполняется данными параллельно с тем, как приложение запрашивает их с сервера. При кэшировании файл документа •также отмечается в виде разреженного. Все команды записи передаются сначала документу удаленной системы, после чего записываются в локальной кэшированной копии. Программа-агент, работающая в пользовательском режиме, постепенно копирует данные с удаленного общего ресурса в локальную кэшированную версию документа. После полного копирования файла флаг разреженности снимается и файл может использоваться вместо копии, хранящейся на сервере.
Если несколько клиентов кэшируют документы и редактируют их в автономном режиме, возникает необходимость в поддержке последовательности (когерентности) данных между различными клиентами. Одно из простых решений заключается в запрете на редактирование кэшированных копий документа. Однако компания Microsoft не пошла на такое ограничение и сделала возможным редактирование автономных документов.
Изменения файла, внесенные в автономном режиме, сохраняются и синхронизируются. В случае конфликта в процессе синхронизации пользователь получает уведомление и запрос на решение конфликта.
3.3 Технологии CIFS и SMB
Общий протокол доступа к файлам Internet (Common Internet File System – CIFS) своим происхождением обязан технологии блока серверных сообщений (Server Message Block – SMB), которая впервые появилась в MS DOS 3.3. В стандарте SMB описан протокол отправки команд файловой системы (открыть файл, считать, записать, блокировать и закрыть) от клиента к файловому серверу.
Перед обсуждением технических подробностей технологий CIFS и SMB необходимо выяснить основные различия между ними. Изначально существовала только технология SMB, которая использовалась в качестве клиент-сер- верного файлового протокола в мире персональных компьютеров. В середине 1980-х годов компания Microsoft дала своей реализации протокола SMB название CIFS и начала позиционировать CIFS в качестве прямого конкурента стандартов WebNFS и NFS. Компания Microsoft предоставила ознакомительный документ RFC на рассмотрение группе IETF (Internet Engineering Task Force)[6], и впоследствии срок действия документа истек без попыток превратить RFC в одну из спецификаций IETF.
Независимые от компании Microsoft поставщики устройств NAS приступили к разработке спецификации CIFS и организовали несколько мероприятий для популяризации CIFS. Ассоциация SNIA (Storage Networking Industry Association) взяла на себя задачу публикации CIFS. Компания Microsoft также выпустила спецификацию CIFS (она называлась Common Internet Filesys- tem Access Protocol), распространявшуюся бесплатно (ссылка на спецификацию находится в списке основных источников информации, приведенном в конце книги).
В похожих друг на друга спецификациях SNIA CIFS и CIFS от компании Microsoft описывается протокол, используемый клиентами Windows NT 4.0 для получения доступа к ресурсам серверов Windows NT. В обеих спецификациях не рассматривается протокол SMB, который применяется в новых версиях Windows (например, не затрагивается клиентское кэширование, которое поддерживается в Windows 2000 и описано в разделе 3.2.6). Кроме того, в спецификациях не описаны все протоколы взаимодействия между серверами. Новый стандарт SMB, не относящийся к бесплатным спецификациям, описан в соответствующей спецификации, которая за определенную плату распространяется компанией Microsoft, что стало возможным благодаря судебным решениям Европейского Союза и правительства США. Дополнительная информация доступна в статье «Microsoft Settlement Program: Communications Protocol Program» на Web-узле компании Microsoft по адресу: http://www.microsoft.com/legal/protocols.
Таким образом, компания Microsoft вновь стала называть свою реализацию описываемой технологии блоком SMB. По сути, SMB от Microsoft – это закрытый протокол, представляющий собой расширенную версию индустриального стандарта CIFS.
Кроме того, следует обратить внимание на историческую связь между SMB/CIFS и NetBIOS. Программный интерфейс NetBIOS (уровень сеанса в модели OSI) на данный момент безнадежно устарел. Интерфейс реализует уровень абстракции, который позволяет приложениям работать с различными транспортными протоколами, например TCP/IP, NetWare или уже забытым протоколом XNS (Xerox Network System). Необходимость в программном интерфейсе приложений, который предоставляет возможность создания приложений, не зависящих от сетевого протокола, существует и поныне. Однако в настоящий момент для этого обычно используется интерфейс сокетов, в частности в мире Windows – интерфейс Winsock.
Компания Microsoft использовала NetBIOS для преобразования имен (преобразования имени сервера в сетевой адрес), но сейчас для этого предназначена стандартная служба DNS.
Изначально Microsoft не использовала TCP/IP в качестве транспортного протокола, что кардинально изменилось со временем, однако поддержка NetBIOS продолжала присутствовать. Тем не менее роль NetBIOS постоянно уменьшалась. После назначения порта TCP/IP для файловых серверов SMB зависимость от NetBIOS была полностью «излечена», по крайней мере в контексте базового протокола. Но ситуация оставалась запутанной, так как некоторым вторичным службам клиентов и серверов Windows все равно требовался протокол NetBIOS. Хорошим примером будет объявление серверами о своем присутствии в сети и предоставление списка доступных служб, а также передача этих объявлений клиентам другими серверами. Со временем службы были переделаны и NetBIOS был полностью снят со счетов с выходом Windows 2000.
Наконец, наследие SMB можно заметить в каждом запросе CIFS, поскольку каждый запрос и ответ должны начинаться со значение «OxFF», после чего следуют такие символы ASCII, как «SMB».
К сожалению, точного определения стандарта CIFS не существует. Различные типы протоколов SMB называются диалектами. Вот несколько возможных вариантов:
применяемый клиентами DOS и Windows 3. x;
используемый при подключении к серверам, не работающим под управлением Windows;
■ применяемый клиентами под управлением Windows NT.
Чаще всего клиент отправляет серверу запрос на установку сеанса и передает список всех поддерживаемых вариантов протокола. Сервер выбирает наиболее функциональный вариант и отправляет клиенту соответствующий запрос. В зависимости от протокола, о котором «договорились» клиент и сервер, некоторые запросы и соответствующие им ответы могут быть недопустимыми. Согласованный вариант протокола не определяет однозначно фактическую реализацию функций протокола, что вносит еще большую путаницу; для указания поддержки определенных функций некоторые флаги могут быть установлены или сброшены. Другими словами, даже при выборе протокола существуют различные варианты предоставляемых функций: например, один из флагов может указывать на наличие поддержки длинных имен файлов.
Как описано в документе RFC компании Microsoft (по правилам IETF на данный момент он уже устарел), протокол CIFS обеспечивает взаимодействие клиента и сервера для доступа к файлам и управления ими. Такие функции, как объявление о наличии в сети доступных принтеров и серверов, выходят за рамки возможностей протокола CIFS.
Организация SNIA продолжает работу над спецификацией CIFS. Кроме того, SNIA проводит ежегодную конференцию, посвященную CIFS, и организует другие мероприятия, на которых обсуждаются вопросы взаимодействия систем по протоколу CIFS.
Спецификация SMB стала стандартом с 1992 года (X/Open CAE Specification С209) и описывает SMB как протокол для обеспечения взаимодействия между компьютерами под управлением DOS, Windows, OS/2 и UNIX.
Запросы и ответы CIFS имеют четкую, понятную структуру. Поля пакетов SMB также стандартизированы, и отличия зависят от выбранной, разновидности CIFS и функций, поддерживаемых как клиентом, так и сервером.
В табл. 3.1 приведена общая структура пакета SMB. Обратите внимание, что показаны только общие элементы для всех вариантов SMB. Подробности строения каждого варианта пакета SMB выходят за пределы тематики этой книги.
Некоторые поля в табл. 3.1 требуют более полного описания. Поле команды имеет размер в один байт и описывает тип запроса. Сервер копирует это значение в ответ, что позволяет клиенту анализировать последний. Спецификация CIFS содержит значения и определения для этого поля. Описанные команды позволяют выполнять такие операции, как открытие файла, чтение, запись и блокирование определенного диапазона файла. Все эти операции выполняются в качестве ответа на запрос приложения.
Кроме того, запросы клиента CIFS (и связанные с ними ответы сервера) инициируются кодом перенаправителя без явного вмешательства приложения. Примерами будут кэширование и оппортунистическая блокировка (opportunistic locking), которые рассматриваются в разделе 3.3.5. В спецификациях CIFS RFC и SNIA, а также Open Group определены значения и семантика кода команды CIFS размером в 1 байт.
Таблица 3.1. Структура заголовка SMB
Окончание табл. 3.1
Помните, что новые значения и семантика полей могут появиться без предупреждения с выходом новых версий Windows, так как протокол CIFS продолжает развиваться.
Существует несколько команд для выполнения одинаковых базовых операций; например, для открытия, чтения и записи существует несколько раз-
личных команд. Некоторые команды уже не применяются, а в ряде случаев могут использоваться альтернативные команды, в зависимости от выбранного диалекта протокола.
Далее представлены примеры функций, описанных в поле команды.
Выбор типа SMB.
Установка сеанса связи.
Переход по каталогам и перечисление файлов и каталогов.
Открытие, создание, закрытие или удаление файлов.
Блокировка и разблокировка определенных фрагментов файла.
Операции печати.
Уведомления об изменении файлов и каталогов.
Транзакции, при которых указываются данные, параметры и операции. Сервер CIFS выполняет запрошенную операцию и возвращает результат – данные и параметры. Примерами транзакций могут служить ссылки в распределенной файловой системе и управление расширенными атрибутами.
В табл. 3.2 представлены функции поля Flags (флаги) из 3.1.
Таблица 3.2. Семантика поля Flags
В поле Flag2 из табл. 3.1 описано еще больше необязательных функций. Значения этого поля приведены в табл. 3.3.
Поле Заполнение/подпись изначально представляло собой последовательность «холостых» байт. Со временем значение этого поля изменилось. Поле заполнения теперь может включать в себя следующие элементы:
Таблица 3.3. Семантика поля Flags2
2 байта идентификатора процесса, что позволяет указывать 32-разрядные идентификаторы процесса;
8 байт для хранения подписи пакета SMB, если эта функция активизирована (см. описание поля Flags2 в табл. 3.3 и в разделе 3.3.3);
2 неиспользуемых байта.
Протокол CIFS обеспечивает безопасность средствами сервера. Администратор может отключить систему встроенной безопасности CIFS, в чем ед-
ва ли появится необходимость, поэтому система безопасности включена по умолчанию.
В старых вариантах CIFS допускается отправка незашифрованного текстового пароля от клиента к серверу, что категорически не рекомендуется. Протокол CIFS допускает защиту ресурсов сервера с помощью паролей отдельных пользователей (это называется безопасностью на уровне пользователя). Для обеспечения обратной совместимости серверы CIFS поддерживают защиту общего ресурса на базе пароля, одинакового для всех пользователей. Поскольку ресурс будет предоставлен в общее пользование,– этот метод называется безопасностью на уровне ресурса. Использовать механизм безопасности на уровне ресурса не рекомендуется, и в Windows 2000 Server эта система отсутствует. Первый пакет SMB, который отправляется серверу клиентом, называется SMB_NEG0TIATE_PR0T0C0L. Пакет применяется для выбора типа CIFS. В ответ на запрос SMB_NEG0TIATE_PR0T0C0L сервер сообщает об используемом механизме безопасности (уровень пользователя или ресурса).
Начиная с Windows NT4 SP3 и Windows 2000, компания Microsoft предоставила возможность размещения в пакетах SMB цифровой подписи. Сервер может быть настроен на обязательное требование цифровой подписи от клиента; в противном случае клиенту будет запрещен доступ к ресурсам. Использование цифровой подписи отражается на производительности как сервера, так и клиента, но это цена, которую приходится платить за безопасность. Обратите внимание, что подписывание и проверка имеют двунаправленную природу, т.е. клиент подписывает отправляемые запросы, сервер проверяет подпись клиента и подписывает отправляемые ответы, после чего клиент проверяет подпись сервера. Подпись пакета SMB хранится в поле Заполнение/подпись (см. табл. 3.1).
Ответ на запрос SMB_NEG0TIATE_PR0T0C0L используется для предоставления клиенту информации о поддержке сервером подписывания пакетов SMB и о необходимости обязательного подписывания пакетов SMB.
Протокол CIFS позволяет определять уровень безопасности при взаимодействии серверов и клиентов. Сервер может быть настроен на отказ в обслуживании клиентов, которые предлагают слишком низкий уровень безопасности.
Протокол CIFS предоставляет механизмы аутентификации, необходимые серверу для аутентификации клиента. Кроме того, предоставляются методы аутентификации сервера клиентом. В базовом уровне аутентификации клиент сообщает имя пользователя и незашифрованный пароль. По очевидным причинам такой подход нежелателен. Более того, сервер можно настроить на отказ в обслуживании клиентов, которые отправляют пароли в незашифрованном виде.
Аутентификация может выполняться с помощью технологии, которая называется протокол запрос/ответ (challenge/response protocol). При отправке клиентом пакета SMB_NEGOTIATE_PROTOCOL для выбора типа CIFS флаг в ответе сервера указывает на возможность использования протокола запрос/ответ. Если сервер поддерживает этот протокол, в ответе сервера предоставляется 8-байтовый запрос. Запрос – это случайное значение с очень низкой вероятностью повторной генерации. И клиент и сервер формируют ключ из пароля пользователя. После этого запрос шифруется с помощью ключа и алгоритма DES (Data Encryption Standart). Клиент отправляет запрос серверу, а сервер сравнивает ответ с собственным подсчитанным значением. Если два значения совпадают, клиент доказывает знание пароля и подтверждает свою аутентичность.
Кроме того, протокол CIFS поддерживает систему расширенной безопасности (можете и не надеяться, что читатель, который догадается об указании на поддержку расширенной безопасности в ответе сервера на запрос SMB_NEG0TIATE_PR0T0C0L, получит награду). Механизм расширенной безопасности предоставляет возможность поддержки произвольного протокола аутентификации в рамках протокола CIFS. При выборе расширенной безопасности первый двоичный объект безопасности предоставляется в ответе на запрос SMB_NEG0TIATE_PR0T0C0L. Двоичные объекты безопасности не обрабатываются протоколом CIFS. В этом он полагается на механизмы клиента и сервера, предназначенные для генерации и обработки двоичных объектов. Последующие двоичные объекты безопасности могут передаваться с данными SMB.
Использование механизма расширенной безопасности позволило Microsoft обеспечить поддержку протокола Kerberos в Windows 2000 и более поздних версиях. Реализация Kerberos в Windows 2000 является примером использования закрытых элементов. Например, некоторые поля мандатов Kerberos применяются для передачи информации о группах, в которые входит клиент. Реализация Kerberos от Microsoft допускает взаимную аутентификацию, когда не только сервер проводит аутентификацию клиента, но и наоборот, клиент аутентифицирует сервер.
Компания Microsoft предлагает еще один способ установки сеанса связи между клиентом и сервером, который называется Netlogon. При этом используются данные о компьютере (а не о пользователе). Протокол Netlogon необходим для установки безопасного сеанса RPC и имеет намного больше возможностей, так как поддерживает маркеры доступа пользователей, которые не поддерживаются при регистрации средствами протокола CIFS. Обычно Netlogon используется для связи между серверами (один сервер выступает в роли клиента другого сервера). В ныне устаревшем документе RFC от Microsoft протокол Netlogon не описан.
Наконец, сервер CIFS не обязательно должен обеспечивать работу механизма аутентификации. Протокол CIFS поддерживает сквозную аутентификацию, когда сервер получает запрос у другого сервера, передает этот запрос клиенту и возвращает ответ клиента серверу аутентификации. При этом, если сервер аутентификации отвечает положительно, клиенту предоставляется доступ- к запрошенным ресурсам. Этот механизм известен как сквозная аутентификация.
Протокол CIFS обладает различными возможностями по оптимизации взаимодействия между клиентом и сервером. Эти возможности рассматриваются в разделах 3.3.5.1 и 3.3.5.2.
Протокол CIFS позволяет формировать последовательность взаимно зависящих друг от друга запросов, поэтому оптимизация этих операций позволяет завершить выполнение запроса за одно обращение к серверу. Эта функция называется AndX; Файловая система NFS версии 4 обеспечивает подобную функцию в виде процедуры COMPOUND. Примером может быть отправка запросов OpenAndRead или WriteAndClose серверу CIFS. При этом вместо отправки отдельных двух запросов, например Open, а затем Read, и получения двух ответов отправляется один запрос OpenAndRead и получается один ответ. Это имеет особое значение в том случае, когда время обращения запрос/ответ слишком велико.
Протокол CIFS поддерживает такую технологию оптимизации производительности, как оппортунистическая блокировка (opportunistic locking, или oplock). Существует две основные причины для использования оппортунистической блокировки.
Первая заключается в блокировке файла и инициализации его локального кэширования. Когда условие блокировки больше не может поддерживаться, протокол допускает определенную задержку, в течение которой клиент должен очистить кэш. Блокировка и разблокировка выполняются незаметно для приложения с помощью механизмов CIFS клиентской и серверной систем. При этом для повышения производительности модификации приложения не требуется.
Представьте себе приложение, которое открывает файл на сетевом сервере для чтения и записи и записывает в файл 128-байтовые записи. Без оппортунистической блокировки каждая запись размером 128 байт потребует передачи данных по сети. Использование oplock позволяет локально кэшировать файл на клиентской системе и объединять несколько операций записи в одну, которая приводит к передаче данных по сети. Например, предположим, что клиент использует буферы размером 4096 и последовательно записывает в файл по 128 байт. Первый буфер будет содержать данные 32 операций записи (4096/128 = 32), и все данные 32 записей будут переданы по сети одним запросом на запись в файл. Если операция записи не может быть кэширова- на, по сети будет передаваться 32 операции записи (а не одна, как при кэшировании). Сокращение количества операций записи с 32 до одной приводит к значительному снижению нагрузки на сеть и существенному повышению производительности.
Вторым назначением оппортунистической блокировки является расширение условий, при которых подобная блокировка возможна. При использовании oplock можно увеличить эффективность кэширования. Расширение условий, при которых возможна оппортунистическая блокировка, предоставляет несколько дополнительных преимуществ. Предположим, что экземпляр приложения открывает файл (на сетевом сервере) для чтения и записи. При этом запрашивается и предоставляется оппортунистическая блокировка. Программный код клиента может кэшировать операции записи в файле. Предположим, что другой экземпляр того же приложения запущен на другом клиенте. Одним из выходов из подобной ситуации будет снятие оппортунистической блокировки и использование сетевого ввода-вывода для передачи запросов на запись в файл от обоих приложений. Еще одним способом будет снятие оппортунистической блокировки в тот момент, когда второй экземпляр приложения попытается выполнить операцию записи. Очень часто приложения вообще не выполняют операции записи.
При изменении условий сервер отправляет уведомление клиенту о снятии оппортунистической блокировки. В качестве примера ситуации, когда сервер отправляет уведомление о снятии оппортунистической блокировки, можно указать запрос на доступ к файлу или запись данных в файл другим клиентом. Сервер обеспечивает очистку данных состояния сервера (включая закрытие сеанса клиента), если клиент не отвечает на запрос о снятии оппортунистической блокировки. Клиент запрашивает oplock только в случае необходимости; например, если приложение запрашивает открытие файла для эксклюзивного доступа, запрос оппортунистической блокировки просто не имеет смысла.
Оппортунистические блокировки реализуются в трех вариантах:
Рис. 3.3. Последовательность операций при эксклюзивной оппортунистической блокировке
эксклюзивная оппортунистическая блокировка;
пакетная оппортунистическая блокировка;
оппортунистическая блокировка второго уровня.
Далее эти сценарии описываются более подробно.
Этот вариант блокировки запрашивается мини-перенаправителем CIFS, когда приложение открывает файл для чтения или записи. Сервер предоставляет оппортунистическую блокировку, если файл еще не открыт другим клиентом. Последовательность операций показана на рис. 3.3.
Для начала первый клиент отправляет запрос на открытие файла, запрашивая эксклюзивную оппортунистическую блокировку. Сервер выполняет необходимую проверку и предоставляет ее. Первый клиент начинает кэширование файла, выполняя операции упреждающего чтения и отложенной записи. Через некоторое время другой клиент, например клиент 2 (на рис. 3.3 не показан), отправляет серверу запрос на открытие того же файла. Сервер
отмечает, что клиент 1 владеет эксклюзивной оппортунистической блокировкой для запрошенного файла, и отправляет уведомление о снятии блокировки клиенту 1. Клиент 1 очищает буферы данных, отправляя необходимые запросы на запись и на блокировку файла. Как только данные состояния файла будут записаны, клиент 1 сообщает серверу, что обработка уведомления о снятии оппортунистической блокировки завершена. На этом этапе сервер отправляет ответ клиенту 2, позволяя ему открыть файл. Клиент 1 продолжает работу с файлом, не проводя при этом локального кэширования. В данном случае предполагается, что клиент 1 открыл файл в режиме, допускающем открытие файла другими клиентами.
Очень часто клиенты открывают файл в режиме чтения/записи и ничего не записывают в файл до его закрытия. Оппортунистическая блокировка второго уровня проектировалась для обеспечения совместного использования и кэширования файлов в такой ситуации. Эксклюзивная оппортунистическая блокировка и пакетная оппортунистическая блокировка (она рассматривается в следующем разделе) всегда предоставляются по запросу клиента. Но оппортунистическая блокировка второго уровня никогда не запрашивается клиентом. Клиент начинает с запроса эксклюзивной оппортунистической блокировки. Если такая блокировка предоставляется, сервер при выполнении определенных условий (они описаны далее) может понизить эксклюзивную оппортунистическую блокировку до блокировки второго уровня.
Обратимся к рис. 3.4. Клиент 1 начинает работу с запроса эксклюзивной оппортунистической блокировки и приступает к локальному кэшированию файла. В частности, клиент 1 проводит упреждающее чтение и локально кэширует блокируемые данные. Помните, что в данном случае клиент не собирается записывать данные в файл. На определенном этапе клиент 2 (он не показан на рис. 3.4) запрашивает доступ к этому же файлу. Сервер отправляет клиенту 1 уведомление с требованием понизить эксклюзивную оппортунистическую блокировку до блокировки второго уровня. Клиент аннулирует блокировки и сообщает, что обработка уведомления завершена. Далее серь вер отправляет клиенту 2 сообщение об успешном открытии файла и предоставляет клиенту оппортунистическую блокировку второго уровня. В данном случае предполагается, что клиент 1, открывая файл, сообщил серверу, что другие клиенты также могут получить доступ к файлу.
При использовании оппортунистической блокировки второго уровня, клиентам запрещено буферизировать блокируемые данные. Преимущество этой схемы заключается в упрощенной когерентности данных на стороне сервера, в то время как клиент будет кэшировать считываемые данные, что позволяет сократить объем информации, передаваемой по сети. Как только один из клиентов выдает запрос на запись, сервер снимает оппортунистическую блокировку второго уровня, после чего блокировок вообще не остается. Поскольку ни один из клиентов не буферизирует блокируемые данные при наличии блокировок второго уровня, успешная операция записи означает, что запись выполнялась в область файла, не заблокированную другими клиентами. После снятия оппортунистической блокировки второго уровня клиентам запрещается буферизировать считанные данные.
Рис. 3.4. Оппортунистическая блокировка второго уровня
Этот вариант блокировки используется для оптимизации быстродействия при обработке командных файлов. Командный процессор обычно открывает файл, ищет необходимую строку, считывает ее, закрывает файл и обрабатывает прочитанную строку средствами интерпретатора командной строки. После этого файл открывается снова, в нем находится следующая строка, файл закрывается, и следующая строка обрабатывается интерпретатором командной строки. Этот цикл выполняется, пока все строки в командном файле не закончатся.
Рис. 3.5. Пакетная оппортунистическая блокировка
На рис. 3.5 приведена последовательность операций. Клиент 1 открывает командный файл и запрашивает пакетную оппортунистическую блокировку. Предположим, что сервер предоставляет пакетную блокировку, так как больше никто не выполняет запись данных в файл. Клиент 1 ищет в файле определенную строку и осуществляет операцию чтения. Интерпретатор выполняет прочитанную строку. Затем файл закрывается. Мини-перенапра- витель CIFS не выполняет никаких действий при получении запроса на закрытие файла (т.е. выполняется операция отложенного закрытия). Интерпретатор командной строки открывает файл, но мини-перенаправитель CIFS не выполняет операцию открытия, а просто отменяет размещенную в очереди операцию отложенного закрытия файла. Когда интерпретатор командной строки выполняет операции поиска и чтения строки, мини-перенаправитель CIFS отправляет запросы на поиск и чтение.
В результате сокращается объем данных, передаваемых по сети (выполняется меньше запросов на открытие и закрытие файла). Кроме того, оптимизируется использование ресурсов сервера, так как от сервера не требуется немедленной обработки запроса на закрытие файла с последующим его повторным открытием.
3.4 Сетевая файловая система
Файловая система CIFS доминирует на рынке сетевых файловых систем для платформы Windows. На платформе UNIX основной является сетевая файловая система (Network File System – NFS). Кроме того, NFS считается первой широко распространенной файловой системой, что произошло еще в середине 1980-х годов. Однако, несмотря на некоторые общие функциональные возможности CIFS и NFS (это сетевые файловые системы, позволяющие клиентам получать доступ к ресурсам серверов), эти системы имеют совершенно различные архитектурные особенности. С выходом NFS версии 4 некоторые различия были пересмотрены.
Протокол CIFS сохраняет сервисные данные, относящиеся к каждому клиенту. До версии 3 файловая система NFS не сохраняла статус клиента, что изменилось в версии 4.
Клиент NFS не «договаривается» с сервером NFS об установлении сеанса. Меры безопасности предпринимаются для всего сеанса или каждой операции обмена данными между клиентом и сервером. Реализация последнего варианта чрезмерно дорогостоящая, поэтому NFS возлагает задачу обеспечения безопасности на клиента. Сервер «предполагает», что идентификаторы пользователя на клиентских и серверной системах совпадают (а клиент проверил личность пользователя перед тем, как дать ему зарегистрироваться под указанным идентификатором). Кроме того, NFS обеспечивает определенный уровень безопасности, контролируя список файловых систем, которые может монтировать клиент. Каждый раз, когда клиент CIFS открывает файл, получает дескриптор файла (т.е. сервисные данные, которые должен сохранять сервер) и использует его для проведения операций чтения или записи на стороне клиента, сервер NFS запрашивает ^сервер, который возвращает дескриптор файла. Этот дескриптор файла обрабатывается клиентами, поддерживающими стандарты NFS 3 и NFS 2. Клиент кэширует полученный дескриптор файла и ожидает, что дескриптор всегда будет указывать на один и тот же файл.
Для тех, кто знаком с UNIX, можно отметить, что дескриптор файла обычно состоит изномера inode (inode number), счетчика поколения inode (inode generation count) и идентификатора файла, который связан с разделом диска. Достаточно сказать, что inode представляет собой исключительно важную структуру данных, которая используется в файловых системах UNIX. Для удаления дескрипторов, кэшированных клиентами, хранится достаточный объем информации, необходимой, если соответствующий дескриптору файл изменился и дескриптор должен указывать на другой файл. Например, если файл удален и на его место скопирован файл с таким же именем, счетчик поколения inode будет изменен и кэшированный клиентом до- скриптор файла окажется недействительным. Файловая система NFS 4 имеет отличия в реализации, которые рассматриваются в разделе 3.4.2.
Некоторые клиенты NFS проводят кэширование на стороне клиента, храня данные на дисках, что напоминает кэширование в CIFS. Также некоторые клиенты NFS меняют значение тайм-аутов в зависимости от времени отклика сервера. Чем медленнее отзывается сервер, тем больше значение тайм-аута, и наоборот.
Файловая система NFS проектировалась, как независящая от транспорта и изначально использовала транспортный протокол UDP. Различные типы NFS могут использовать протокол TCP и другие протоколы.
В разделах 3.4.1 и 3.4.2 рассматриваются особенности файловых систем NFS 3 и NFS 4. Информация, приведенная в этой книге, не заменит ряд отличных изданий, которые представлены в списке источников информации в конце книги.
Файловая система NFS 3 позволяет увеличить быстродействие, особенно для больших файлов, разрешая клиенту и серверу динамически выбирать максимальный объем данных, которые передаются в одном логическом элементе пакета при записи или чтении. В файловой системе NFS 2 на размер пакета накладывалось ограничение в 8 Кбайт. Другими словами, клиент мог отправить максимум 8 Кбайт в запросе на запись, а сервер – максимум 8 Кбайт в ответе на запрос чтения. Кроме того, в NFS 3 переопределены смещения в файлах и размеры данных. Теперь это 64-разрядные значения, вместо 32-разрядных в NFS 2.
Далее представлены некоторые особенности NFS 3.
В дескрипторах файлов 6 NFS 3 указан переменный размер; их максимальных размер составляет 64 бит.
Файловая система NFS 3 позволяет клиентам и серверам выбирать максимальный размер имен файлов и каталогов.
В NFS 3 определяется список ошибок, которые сервер может возвращать клиентам. Сервер должен вернуть одну из определенных ошибок или не возвращать ошибку вообще.
В NFS 3 серверу разрешено кэшировать данные, которые клиент отправил вместе с запросом на запись. Сервер может кэшировать данные и отправлять клиенту ответ на запрос еще до того, как данные будут записаны на диск. Также добавлена команда COMMIT, которая позволяет клиенту убедиться, что все отправленные данные были записаны на
диск. Это дает возможность соблюсти баланс между повышением производительности и сохранением целостности данных.
В NFS 3 сокращено количество операций запрос/ответ между клиентом и сервером. Для этого данные об атрибутах файла отправляются вместе с первоначальным запросом. В NFS 2 от клиента требовалось получение имен файлов и дескриптора для каждого файла, только после этого передавались атрибуты файла.
В NFS 4 полностью пересмотрены основополагающие принципы и реализовано много функций, характерных для CIFS, что весьма расстроило некоторых апологетов NFS. Если посмотреть на историю сетевых файловых систем, то можно увидеть, что NFS получила широкое распространение. Файловая система SMB разрабатывалась с учетом сильных и слабых сторон NFS и теперь, по крайней мере в среде клиентов, CIFS/SMB распространены больше, a NFS развивается, учитывая все недостатки и преимущества CIFS/SMB. Ниже рассматриваются возможности, которые были добавлены в NFS 4 для повышения быстродействия и безопасности, а также для улучшения взаимодействия с CIFS.
В NFS 4 появился запрос COMPOUND, который позволяет запаковывать несколько запросов в один запрос и несколько ответов в один ответ. Это нововведение предназначено для повышения производительности за счет снижения нагрузки на сеть и сокращения задержек при передаче запросов и ответов по сети. Если это несколько напоминает функцию CIFS AndX SMB (см. раздел 3.3.5.1), то, возможно, дело не в обычном совпадении.
Сетевая файловая система версии 4 заимствовала некоторые возможности у WebNFS, созданной компанией Sun. В частности, в NFS 4 некоторые вторичные протоколы поддерживаются в базовой спецификации, что делает NFS более подходящей для применения вместе с брандмауэрами. В NFS 3 и более ранних версиях использовался специальный протокол для монтирования общего ресурса сервера в дерево локальной файловой системы. Поскольку служба протокола монтирования не имела назначенного порта TCP или UDP, клиент сначала отправлял запрос службе отображения портов (portmapper daemon), предоставляющей номер порта, посредством которого ожидает запросов служба монтирования. Таким образом, кроме NFS, в процессе принимали участие протоколы монтирования и отображения портов. Более того, так как служба монтирования могла использовать произвольный порт, настройка брандмауэра весьма усложнялась. В NFS 4 протоколы монтирования и отображения портов были исключены. Кроме того, блокирование было включено в базовую спецификацию протокола NFS, а протокол NLM (Network Lock Manager), который применялся в более ранних версиях NFS, окончательно устарел.
Файловая система NFS 4 требует использования транспортного протокола, который предоставляет возможность обнаружения «заторов» в сети. Это значит, что клиенты и серверы NFS постепенно будут переходить к протоколу TCP вместо UDP, который обычно используется вместе с NFS 3.
В NFS 2 и NFS 3 допускалось использование набора символов U. S. ASCII или ISO Latin 1. Это приводило к возникновению проблем, когда клиент, использующий один набор символов, создавал файл и к этому файлу получал доступ клиент с другим набором символов. В NFS 4 используется набор символов UTF. -8, который поддерживает компактное сжатие 16- и 32-разрядных символов для их передачи по сети. Кроме того, набор символов UTF-8 содержит достаточный объем информации, чтобы избежать проблем при создании файла посредством одного набора символов и получении доступа к файлу с другим набором.
Файловая система NFS 4 требует от клиента отдельной обработки дескрипторов файлов. В NFS 3 клиент мог кэшировать дескриптор в качестве объекта, в то время как сервер заботился о том, чтобы дескриптор всегда указывал на файл. В NFS 4 определены два типа файловых дескрипторов. Один называется постоянные дескрипторы файлов и обладает возможностями дескрипторов файлов из NFS 3. Второй – временные дескрипторы файлов – предполагает истечение срока действия дескриптора после определенного промежутка времени или события. Это функция для серверов, файловые системы которых (например, NTFS) не могут обеспечить постоянного соответствия между отображаемыми файлами и дескрипторами.
В NFS 4 добавлена поддержка операций OPEN и CLOSE, семантика которых допускает взаимодействие с клиентами CIFS. Команда OPEN создает данные состояния на сервере.
Поддержка запроса OPEN в NFS 4 позволяет клиенту осуществлять запрос на открытие файла, структура которого будет аналогична запросам на открытие приложений Windows. Также поддерживается выбор совместного использования файла с другими клиентами или эксклюзивный доступ к файлу.)
Файловая система NFS 4 позволяет усилить безопасность хранимых данных. В частности, в NFS 4 добавлена поддержка большего количества атрибутов файла. К одному из этих атрибутов относится список управления доступом (ACL) в стиле Windows NT. Это позволяет улучшить взаимодействие между файловыми системами и укрепить структуру безопасности.
В то время как в NFS 2 и NFS 3 использование возможностей системы безопасности только рекомендовалось, в NFS 4 это стало обязательным. Файловая система NFS 4 требует реализации механизма безопасности с помощью интерфейса RPCSEC_GSS (Generic Security Services) в общем и протоколов Kerberos 5/LIPKEY в частности. Обратите внимание, что RPCSEC_GSS просто выполняет роль интерфейса API и транспортного механизма для меток и данных, связанных с безопасностью. Файловая система NFS 4 позволяет использовать несколько, схем аутентификации и обеспечения безопасности, а также дает возможность выбрать подходящую схему для клиентов и серверов.
Уделим некоторое внимание изучению технологии LIPKEY, использующей комбинацию симметричного и асимметричного шифрования. Клиент шифрует данные о пользователе и пароль, применяя случайно сгенерированный ключ размером 128 бит. Шифрование выполняется с помощью симметричного алгоритма, т.е. для дешифрации должен использоваться тот же ключ. Поскольку серверу необходим этот ключ для дешифрации сообщения, случайно сгенерированный ключ должен быть отправлен серверу. Клиент шифрует ключ (который генерируется случайно) с помощью открытого ключа сервера. Сервер дешифрует данные своим закрытым ключом, извлекает симметричный ключ и дешифрует данные о пользователе и пароль.
Клиенты могут аутентифицировать серверы по серверному сертификату, а для проверки сертификата используются службы сертификационного центра. Одним из популярных методов взлома является перехват «чужих» пакетов данных с их последующей отправкой через некоторый временной промежуток. При использовании Kerberos файловая система NFS добавляет в каждый пакет временную метку. Сервер записывает недавно полученные временные метки и сравнивает их с временными метками новых пакетов RPC. Если временные метки пакетов старше, чем полученные сервером ранее, сервер игнорирует полученные пакеты.
3.5 Проблемы доступа при использовании нескольких протоколов
Несколько компаний стали предлагать системы, в которых одновременно реализована поддержка CIFS, NFS и других клиентов сетевых файловых систем. Поставщики проделали немалую работу, пытаясь преодолеть технические проблемы, которые возникают из-за потенциального использования клиентами различных операционных и файловых систем. Обратите внимание, что проблемы возникают не с самими данными, а с метаданными файлов. Простым тестом на наличие подобных проблем будет копирование файла с сервера на клиент и обратно на сервер (или наоборот). После размещения файла в первоначальном ресурсе метаданные должны содержать базовые значения, т.е. права доступа к файлу и временные метки не должны измениться. Если это не соответствует истине, то проблема обнаружена.
Далее представлены примеры некоторых возможных технических проблем.
В различных операционных системах используются разные методы для отслеживания разрешений доступа пользователей и групп.
В различных операционных и файловых системах существует разная семантика открытия и блокировки файлов.
Соглашения по именованию файлов обрабатываются разными способами. Различные файловые системы по-разному представляют максимальный размер имени файла, значение регистра в имени файла и набор символов, допустимый в именах.
Данные и их структура различаются в различных файловых системах; например, одни файловые системы отслеживают две временные метки, в то время как другие – три метки (время последнего доступа к файлу, последней модификации и создания файла). Даже если обе файловые системы отслеживают две временные метки, единицы измерения могут отличаться. Еще одним примером служат единицы измерения смещений в файлах. В некоторых файловых системах поддерживаются 32- разрядные смещения, а в некоторых – 16- или 64-разрядные.
Проблемы с адресацией отображаемых блокировок. Сервер CIFS принудительно поддерживает блокировку: если один клиент заблокировал область файла, то любая операция записи в эту область файла со стороны другого клиента приведет к возникновению ошибки. Однако принудительная блокировка не поддерживается серверами NFS. Поэтому необходимо выбрать, будет ли блокировка поддерживаться принудительно, что приведет к отправке сообщения об ошибке клиенту NFS.
3.6 Windows и NAS
Компания Microsoft предлагает приобрести коммерческий пакет SAK (Server Appliance Kit). Он предназначен для производителей аппаратного обеспечения, которым требуется создать приложения для хранилищ данных, подключаемых к сети. Пакет SAK – это просто версия Windows, имеющая модульную структуру, а также набор средств программной разработки. Модульная структура версии Windows позволяет производителю выбрать (в пределах разумного) компоненты Windows, которые должны быть включены в готовое приложение. Таким образом, предоставляется возможность убрать из Windows все компоненты, которые не требуются для поддержки стека сетевых протоколов, файлового сервера и локального стека подсистемы хранения данных. Программные средства разработки позволяют производителям оборудования создавать собственные инструменты администрирования и распространять их вместе с аппаратными комплексами.
Кроме того, в состав SAK входят компоненты, не поставляемые с обычными серверными версиями Windows. Хорошим примером будет инфраструктура обеспечения надежности, которая следит за драйверами на предмет утечки памяти и незаметно перезапускает критические компоненты, если в этом возникает необходимость. Несколько поставщиков предлагают устройства NAS, работающие под управлением Windows NT. Одно из преимуществ использования Windows NT для организации NAS заключается в сокращении стоимости и временных затрат на создание готового решения. Компания Microsoft предоставляет стеки протоколов CIFS и NFS. Возможно, одно из главных преимуществ использования Windows в подобных системах – это доступность всех новейших функций SMB и отсутствие необходимости в обратном проектировании и дополнительной разработке.
Следующим преимуществом является возможность модификации программных решений посредством SAK. В состав SAK входят компоненты управления (в частности, удаленного управления) и компоненты защиты данных (например, функции для создания «моментальных снимков» образа диска). (Описание технологии моментальных снимков и сферы их применения приводится в главе 5.)
Некоторые производители аппаратного обеспечения разработали свои решения NAS, не используя пакет SAK. Доступно несколько альтернативных стеков протоколов CIFS и NFS. Феномен открытого исходного кода набирает популярность, и, если есть возможность потратить дополнительные ресурсы, использование исходного кода, допускающего внесение изменений, имеет ряд преимуществ. Например, доступность открытого исходного кода позволяет максимально сократить накладные расходы на уровне операционной систе
мы. Маркетинговое исследование этих подходов не является предметом нашего обсуждения.
3.7 Система Microsoft Exchange 2000 и NAS
Популярная корпоративная система обмена мгновенными сообщениями Microsoft Exchange 2000 представляет собой один из главных продуктов в семействе BackOffice от компании Microsoft. Архитектура Exchange 2000 значительно отличается от Exchange 5.5. Хотя в Microsoft Exchange 2000 было включено множество новых возможностей, не обошлось и без недостатков; один из них состоит в том, что эту систему нельзя использовать совместно с устройствами хранения NAS. В данной книге рассматриваются те компоненты Exchange 2000, которые имеют практическое значение.
На рис. 3.6 показан элемент архитектуры Microsoft Exchange 2000. Обратите внимание, что в данном случае рассматриваются только отдельные компоненты системы Exchange 2000, полное описание которой выходит за рамки книги. Протокольное ядро, показанное на рис. 3.6, предоставляет серверные функции для таких почтовых протоколов, как IMAP, РОРЗ и SMTP. Ядро Exchange Store (ESE) основано на базе данных Jet и используется для хранения и извлечения различных объектов, которые и формируют сообщение электронной почты. Файловая система ExIFS (Exchange Installable File System) предоставляет важные функции, описанные ниже.
■ Исключительно эффективный механизм межпроцессного взаимодействия для ESE и протокольного ядра Exchange.
Рис. 3.6. Архитектура подсистемы хранения Microsoft Exchange 2000
Рис. 3.7. Система Microsoft Exchange 2000 при использовании локального хранилища и хранилища NAS
Межпротокольный кэш файловых дескрипторов Windows NT. Дескриптор, созданный одним протоколом (например, POP), может использоваться другим протоколом (например, DAV).
Функции для обеспечения минимального преобразования данных, например хранение сообщений в базовом формате MIME.
Хотя ExIFS и предоставляет необходимые возможности, с точки зрения поставщиков решений NAS, эта файловая система является причиной основных проблем. В частности, при использовании NAS для хранилища Exchange драйвер ExIFS исключается из маршрута ввода-вывода данных (рис. 3.7).
Обратите внимание, что запросы Exchange Store или протокольного ядра Exchange к локальным файлам проходят через стек протоколов, изображенный в левой части диаграммы. Например, запрос на чтение проходит от Exchange Store к ExIFS, оттуда к NTFS, драйверу класса диска и драйверу порта. Но если запрос требует обращения к файлу, который хранится на устройстве NAS, то драйвер ExIFS находится вне маршрута ввода-вывода, поэтому запросы проходят через сетевой стек, изображенный в правой части диаграммы. Таким образом, запрос от Exchange Store будет направлен к пе- ренаправителю CIFS, оттуда в стек протоколов TCP/IP и к сетевой карте. Драйвер ExIFS в этом маршруте отсутствует.
Обратите внимание: архитектурные особенности, представленные на рис. 3.6 и рис. 3.7, относятся только к Microsoft Exchange 2000 и не имеют никакого отношения к Microsoft Exchange 5.5.
3.8 Сложности практической реализации
Начиная с Windows 2000, компания Microsoft предоставляет новую модель мини-драйвера, которая позволяет независимым поставщикам создавать сетевые файловые системы. От поставщиков требуется создать мини-драйвер, который поддерживает особенности протокола выбранной сетевой файловой системы. Общие для всех сетевых файловых систем возможности (взаимодействие с Windows и диспетчером кэша) обеспечиваются библиотекой драйвера. Компания Microsoft предоставляет мини-драйверы для файловых систем CIFS, NFS и WebDAV.
На данный момент CIFS де-факто является индустриальным стандартом для обеспечения взаимодействия между клиентами и серверами Windows. Файловая система CIFS реализована на различных платформах, поддерживающих сетевые файловые системы. Компания Microsoft, как и ассоциация SNIA (Storage Networking Industry Association), предоставляет бесплатную спецификацию CIFS. В обоих спецификациях CIFS рассматривается более старый протокол, реализованный в Windows NT 4.0. Кроме того, Microsoft за определенную плату предоставляет спецификации протокола SMB, который используется в более новых версиях Windows NT.
Компания Microsoft вступила в конкурентную борьбу с поставщиками решений NAS, построенных на платформах, отличных от Windows. Со своей стороны Microsoft предоставляет поставщикам устройств модифицированную версию операционной системы Windows. Время покажет, насколько успешной окажется эта стратегия, но на данный момент компании Microsoft удалось занять заметную нишу рынка операционных систем для решений NAS.
Программный продукт Microsoft Exchange 2000 не работает с устройствами NAS. Ожидается, что со временем компания Microsoft предложит версию этого продукта, которая поддерживает хранение данных на базе программы SQL Server. Учитывая, что новая версия SQL все еще не появилась в продаже, гарантировать сроки появления новых версий этих продуктов невозможно. Предпримет ли Microsoft шаги, необходимые для решения проблемы взаимодействия Microsoft Exchange 2000 и NAS? Помните о реальных сроках выхода продуктов на рынок и регулярных их переносах. Несмотря на то что Microsoft Exchange 2000 уже давно доступен на рынке, множество клиентов продолжают использовать Microsoft Exchange 5.5.
3.9 Резюме
Сетевое хранилище данных (NAS) – это промышленный термин, которым описывается определенный класс устройств, включающих в себя жесткие диски, адаптер сетевого интерфейса и центральный процессор, обрабатывающий данные протокола файлового сервера. Устройства NAS обычно настраиваются на максимальную производительность (с помощью специально настроенных операционных систем) и предоставляют удобные возможности для администрирования. При этом проблема администрирования устройств хранения данных превращается в более понятную проблему – администрирование сервера.
Обычно к устройствам NAS обращаются клиентские системы. Обратите внимание: в данном случаеклиент – термин относительный. Клиентом устройства NAS может быть сервер баз данных. Клиенты используют протоколы CIFS/SMB или NFS. Первый, как правило, применяется клиентами, работающими под управлением Windows. Протокол NFS, в свою очередь, предназначен для клиентов на базе UNIX. Спецификации протокола CIFS разрабатываются компанией Microsoft и организацией SNIA. В этих спецификациях рассматриваются реализации протокола, которые характерны для Windows NT 4.0. Лицензия на протокол SMB для Windows 2000 и Windows Server 2003 предоставляется Microsoft за определенную плату.
Устройства NAS, которые одновременно обслуживают клиентов NFS и CIFS/SMB, характеризуются наличием серьезных проблем при обеспечении взаимодействия клиентов и сохранении метаданных файлов.
Глава 4 Сети хранения данных на базе интерфейса Fibre Channel
Эту главу можно рассматривать как введение в сети хранения данных (storage area network – SAN) в общем и в сети хранения данных на базе интерфейса Fibre1 Channel в частности. Хотя сети хранения данных могут создаваться и на основе технологий, отличных от Fibre Channel, большинство из них будут использовать Fibre Channel еще достаточно долгое время. Именно поэтому интерфейсу Fibre Channel уделяется в этой главе основное внимание. Сети хранения данных, основанные на других технологиях, например iSCSI, рассматриваются в главе 8.
Интерфейс Fibre Channel – это технология межсистемного взаимодействия, которая объединяет в себе возможности высокоскоростного ввода-вывода и сетевого обмена данными. Когда эта книга готовилась к печати, сети хранения данных на основе Fibre Channel обеспечивали быстродействие
Гбит/с; кроме того, растет количество сетей, поддерживающих скорость
Гбит/с.
В терминологии Fibre Channel устройства называются узлами (nodes). Это весьма напоминает узлы в терминологии сетей IP. Узел Fibre Channel может иметь несколько портов, как и узел IP, который зачастую получает несколько адресов IP. Разница между ними в том, что порт Fibre Channel представляет собой физический элемент, а порт IP – логический. Каждый узел Fibre Channel имеет уникальное 64-разрядное имя WWN (World Wide Name), которое назначается производителем. Это напоминает уникальные адреса MAC, которые назначаются производителями сетевым адаптерам Ethernet. Каждый порт сети хранения данных на базе кольца с разделением доступа Fibre Channel имеет 8-битовый адрес, а порт в коммутируемой связной архитектуре – 24-битовый. При подключении кольца с разделяемым доступом (arbitrated loop) к коммутатору связной архитектуры (fabric switch),
Написание Fiber было заменено на Fibre, чтобы указать, что технология Fibre Channel может использовать медные и оптические носители.
коммутатор представляет 8-битовый адрес в виде 24-битового. Оба идентификатора порта назначаются динамически. Концепция портов и различные их типы обсуждаются в разделе 4.5.
Сфера применения Fibre Channel рассматривается в следующем разделе, после чего технология SAN сравнивается с NAS (см. главу 3). В этой главе сначала описываются принципы технологии Fibre Channel, затем внимание акцентируется на протоколах нижнего уровня и наконец рассматриваются различные элементы (включая устройства), из которых и создаются системы SAN на базе интерфейса Fibre Channel.
4.1 Сферы применения технологии Fibre Channel
В технологии Fibre Channel предпринята попытка объединить лучшее из двух миров – каналов передачи данных и сетей. Термин канал впервые стал использоваться в мире мэйнфреймов и описывал структурированный механизм передачи данных. В большинстве случаев передача данных выполняется между компьютерной системой и периферийным устройством, например жестким диском или накопителем на магнитной ленте. К таковым каналам относятся интерфейсы SCSI (Small Computer System Interface) и HIPPI (High- Performance Parallel Interface). Работа каналов обычно реализуются средствами аппаратного обеспечения.
По сравнению с каналом сеть представляет собой более универсальный механизм для передачи данных, который, однако, менее структурирован. Кроме того, сеть может работать на значительно большем расстоянии и подключаться к большему количеству устройств, чем канал. В отличие от каналов, сети в основном реализуются средствами программного, а не аппаратного уровня.
Один из подходов в объединении систем хранения данных и сетей заключается в том, что сеть становится ключевым элементом, к которому добавляются новые возможности с одновременной компенсацией недостатков подобного подхода. Речь идет о технологии хранения данных на базе протокола IP (см. главу 8).
Другой подход состоит в использовании центрального хранилища данных (канальная система) и расширения существующих технологических функций. На базе этого метода создавалась технология Fibre Channel. Одно из основных преимуществ Fibre Channel по сравнению с IP Storage заключается в разработке продуктов Fibre Channel уже в течение 10 лет, в то время как решения для IP Storage появились сравнительно недавно.
Учитывая, что Fibre Channel основана на структуре каналов, стоит рассмотреть недостатки другой известной технологии – SCSI.
Максимальная скорость передачи данных – 80 Мбайт/с (впоследствии скорость возросла до 320 Мбайт/с, но уже после появления технологии Fibre Channel), чего явно недостаточно для хранилищ данных большого объема.
Адаптер поддерживает только 16 устройств.
Преимущество, которое одновременно является и недостатком, – обратная совместимость. Стандарт SCSI развивался много лет, и производители устройств смогли обеспечить обратную совместимость для нескольких поколений устройств. Но администратор должен следить, чтобы к шине не подключались устройства предыдущих поколений, поскольку шина автоматически перейдет в режим, поддерживающий работу самого старого устройства.
Поддерживается длина кабелей, составляющая несколько десятков метров. Этого недостаточно для создания обычных, а тем более географически распределенных кластеров.
Существуют и другие альтернативы SCSI, например SSA (Serial Storage Architecture), которые еще находятся в рамках архитектуры Intel или вообще представляют собой открытый стандарт.
4.2 Сравнение SAN и NAS
В главе 3 рассматривается технология NAS: Прежде чем знакомиться с архитектурой сетей хранения данных на базе Fibre Channel, следует провести сравнение принципов создания хранилищ. В табл. 4.1 описываются различия и общие черты этих технологий.
Таблица 4.1. Сравнение технологий NAS и SAN
Окончание табл. 4–1
4.3 Преимущества Fibre Channel
Рассмотрим преимущества использования SAN на базе Fibre Channel. Хотя возможности, описанные в разделах 4.3.1–4.3.7, все еще широко применяются, не забывайте, что такая ситуация может измениться в любой момент, так как технологический прогресс не стоит на месте..
Сети хранения данных обладают способностью к масштабированию в аспекте объема и скорости передачи данных. Можно добавить коммутатор и расширить кольцо отдела до магистрали, которая каскадом соединяет иерархии коммутаторов. Конечно, сети IP также поддерживают масштабирование, что является основной причиной такого быстрого развития технологии IP Storage (см. главу 8).
При корректной настройке и управлении SAN предоставляет налучшие возможности обоих вариантов построения хранилищ данных: хранилище отделено от сервера приложений и в то же время обеспечивает защиту и целостность данных. Например, можно разделить данные отделов, которые физически будут находиться в одном пуле устройств хранения данных.
Сети хранения данных позволяют консолидировать устройства хранения, оптимизировать их использование и управление. Речь идет о том, что дублировать данные, которые размещены вне инфраструктуры SAN, нет необходимости. Еще одним преимуществом является возможность распределения хранилищ. Это позволяет избежать ситуации, когда у одного сервера объем хранилища избыточен, а второму серверу объема не хватает. Эффективное распределение объема хранилища позволяет сократить накладные расходы, связанные с добавлением устройств хранения к определенному серверу. Например, если управление дисками проводится централизованно, хранилище одного сервера может быть передано в использование другому серверу, которому не хватает свободного дискового пространства. Еще одним примером может служить хранилище, необходимое для создания «моментального снимка» в процессе резервного копирования. В классической схеме каждый сервер имеет для этих целей собственный жесткий диск. В технологии SAN все серверы совместно используют несколько дисков для создания временных моментальных снимков.
Сети хранения данных позволяют защитить инвестиции в устаревшие устройства, например в устройства хранения SCSI, или, с ультрасовременной точки зрения, в кольцевые концентраторы. Устройства-мосты, которые обеспечивают взаимодействие между старыми устройствами и интерфейсом Fibre Channel, часто являются основой для поддержки устаревших устройств. Конечно, такая схема позволяет использовать далеко не все устаревшие устройства.
Сети хранения данных предоставляют доступ к большему количеству устройств. Кольцо с разделяемым доступом поддерживает теоретический максимум, равный 127 портам (обычно подключается до 15 устройств, а значительные задержки в работе возникают после подключения 50 устройств).
Сеть хранения данных на основе связной архитектуры теоретически поддерживает около 15 млн. (224) портов.
Сети хранения данных позволяют размещать устройства хранения гораздо дальше от узлов (серверов и рабочих станций), чем другие интерфейсы. Шина SCSI поддерживает расстояния порядка десятков метров, a Fibre Channel – десятков километров.
Интерфейс Fibre Channel позволяет использовать совершенно новые функции. Один из примеров – резервное копирование данных без использования локальной сети, когда резервная копия передается по сети хранения данных, а локальная сеть остается свободной для запросов клиентов и серверов к устройствам хранения. Еще одним примером является перенос данных между двумя подсистемами хранения без участия сервера. Кроме того, файловые системы SAN (они рассматриваются в главе 6) позволяют нескольким серверам получить одновременный доступ к одним и тем же томам.
4.4 Топологии Fibre Channel
В разделах 4.4.1–4.4.3 рассматриваются различные топологии подключения устройств, которые формируют сеть хранения данных на базе Fibre Channel. Топологии «точка-точка» (point to point), кольцо с разделяемым доступом (arbitrated loop) и коммутируемая связная архитектура (switched fabric) перечислены в порядке возрастания их сложности.
Технология Fibre Channel поддерживает подключение по топологии «точка-точка». В этом случае сервер обычно подключается к выделенной подсистеме хранения, причем данные не используются совместно. На рис. 4.1 показана сеть, построенная на основе этой топологии.
Для реализации топологии «точка-точка», как минимум, необходим сервер, адаптер Fibre Channel (адаптер шины) и устройство хранения (например, жесткий диск или накопитель на магнитной ленте), оснащенное интерфейсом Fibre Channel.
Рис. 4.1. Топология «точка-точка»
Кольцо – это схема логического подключения устройств, при котором данные передаются по логически замкнутому контуру. В кольце с разделением доступа (arbitrated loop) протокол описывает порядок, в котором узел получает разрешение на передачу данных. Кольцо Fibre Channel с разделением доступа (Fibre Channel arbitrated loop – FC-AL) может быть реализовано на базе различных устройств хранения (жестких дисков, накопителей на магнитной ленте), серверов, адаптеров шины и устройств для их подключения. В качестве устройств подключения могут выступать концентраторы или коммутаторы Fibre Channel (см. раздел 4.7.4). На данный момент достаточно указать, что устройства подключения играют важную роль в организации инфраструктуры кольца, в его работе и управлении им.
На рис. 4.2 показан пример кольца Fibre Channel с разделением доступа. Конфигурация аналогична физической звезде и логическому кольцу, используемым в локальных сетях на базе технологии Token Ring. Кроме того, как и в сетях Token Ring, данные перемещаются по кольцу в одном направлении. Но, в отличие от Token Ring, устройство может запросить право на передачу данных, а не ждать получения пустого маркера от коммутатора.
Команды Fibre Channel поддерживают согласование и доступ к кольцу для передачи данных. Кроме того, предоставляются команды для назначения адресов портов кольца с разделением доступа (arbitrated-lo, op port addresses – AL-PA) различным узлам кольца. Каждый узел в управляемом кольце Fibre Channel имеет контур для собственного отключения от кольца и сохранения непрерывности кольца в случае ошибки.
Кольца Fibre Channel с разделением доступа могут адресовать до 127 портов, в частности типа NL (дополнительная информация приводится в разделе 4.5), что обусловлено методом указания адреса AL-PA. Один из этих портов зарезервирован для подключения к коммутатору связной архитектуры (см. раздел 4.7.4.3). Остальные 126 портов доступны для предоставления узлам. Практика показывает, что типичные кольца с разделением доступа содержат до 12 узлов, а после подключения 50 узлов производительность падает до такой степени, что имеет смысл перейти на коммутатор связной архитектуры. Кольца с разделяемым доступом позволяют использовать все преимущества Fibre Channel при значительно меньших денежных затратах. Однако стоимость коммутаторов Fibre Channel стремительно снижается, поэтому применение коммутируемых связных архитектур становится все более предпочтительным.
В разделах 4.4.2.1–4.4.2.3 описываются важные концепции, связанные с кольцом Fibre Channel с разделяемым доступом: инициализация кольца, управление кольцом и различные типы колец (закрытые и открытые кольца).
Протокол инициализации кольца Fibre Channel обладает четко определенной структурой. Инициализация выполняется в таких случаях:
при первой установке и запуске кольца;
при подключении нового устройства;
при отключении или перезапуске существующего устройства.
Кольца инициализируются с помощью специальных управляющих кадров. В процессе инициализации выполняются описанные ниже действия.
На время до следующей инициализации выбирается хозяин кольца (loop master). Одной из наиболее важных задач хозяина кольца является назначение адресов различным портам в кольце.
Выполняется назначение адресов в кольце. Значения адресов, присвоенных устройствам, используются для решения конфликтов, когда несколько устройств пытаются одновременно передавать данные. Коммутаторы связных архитектуры имеют наибольший приоритет; они могут выбрать любой произвольный адрес. Портам разрешается получать адрес, который использовался ранее.
Если через один порт организуется передача данных на другой порт, сначала следует выяснить владельца кольца. Для этого порт отправляет специальный кадр, который называется ARB primitive. В этом кадре содержится адрес порта, который намерен получить управление над кольцом. При получении портом кадр ARB primitive передается дальше, если порт не собирается передавать данные. Если порт-получатель намерен сам передавать данные, он сравнивает адрес из ARB primitive с собственным адресом. Если у получателя адрес имеет меньшее значение (больший приоритет), то кадр отправляется дальше, но содержит адрес данного порта. В противном случае кадр ARB primitive отправляется дальше с неизменным адресом. Через некоторое время порт получает кадр ARB primitive со своим адресом обратно. Именно на этом этапе порт получает управление кольцом.
Порт, который выиграл управление кольцом, отправляет кадр 0PN primitive тому порту, которому нужно передать данные. Этот кадр передается дальше промежуточными портами, пока не достигнет целевого порта. Порт отвечает другим кадром ARB primitive, после получения которого портом-инициатором может начинаться сеанс передачи данных. После завершения отправки данных порт-инициатор отправляет кадр CLS primitive. Однако целевой порт может продолжать отправку кадров для завершения сеанса передачи данных, а порт-инициатор должен быть готов принять эти кадры даже после отправки CLS primitive. После завершения отправки кадров целевой порт может ответить на кадр CLS primitive собственным кадром CLS primitive. На этом этапе кольцо готово к началу следующего сеанса передачи данных.
В стандарте Fibre Channel описан необязательный алгоритм предотвращения ситуации, когда устройства с низким приоритетом никогда не получают доступ к кольцу из-за устройств с высоким приоритетом. Этот необязательный алгоритм запрещает устройствам с высоким приоритетом получать
кольцо в управление сразу после завершения сеанса связи, пока возможность передачи данных не появится у устройств с низким приоритетом.
Закрытое кольцо представляет собой изолированное кольцо Fibre Channel с разделением доступа (кольцо не подключено к связной архитектуре, которая рассматривается в разделе 4.4.3). Открытое кольцо – это кольцо с разделением доступа, подключенное к связной архитектуре через коммутатор. В данном случае обеспечение совместимости зависит непосредственно от коммутатора, как описано ниже.
Коммутатор связной архитектуры должен обеспечивать уникальность адресов в пределах кольца и связной архитектуры, а также заменять трехбайтовые адреса в связной архитектуре на однобайтовые адреса в пределах кольца. Этот процесс обычно называется подменой адресов.
и От коммутатора связной архитектуры требуется, чтобы подключенные к ней устройства в пределах кольца с разделением доступа выглядели как подключенные к кольцу.
Обнаружение устройств необходимо для поддержки передачи данных в рамках общей и частной транспортной инфраструктуры. Устройства Fibre Channel, поддерживающие связную архитектуру, самостоятельно регистрируются на сервере SNS– Simple Name Server (см. раздел 4.4.3.1), однако устройства Fibre Channel для кольца с разделением доступа не поддерживают такую возможность. На коммутатор возлагается задача по обнаружению каждого устройства в кольце Fibre Channel и добавлению характеристик устройства на SNS. Это необходимо для устройств Fibre Channel, поддерживающих работу в рамках связной архитектуры.
В топологии коммутируемой связной архитектуры Fibre Channel (Fibre Channel switched-fabric) каждое устройство имеет логическое подключение к любому другому устройству. Обратите внимание на слово логическое. Обеспечение физического подключения устройств по топологии «каждый с каждым» потребовало бы огромных затрат, так как для N устройств необходимо N2 портов и физических подключений. В реальности каждое устройство подключается к коммутатору, а коммутатор поддерживает логические подключения между всеми своими портами.
На рис. 4.3 показан простейший вариант топологии коммутируемой связной архитектуры Fibre Channel. Несколько узлов (устройств хранения и компьютерных систем) подключены к коммутатору Fibre Channel. Коммутатор – это высокоскоростное устройство, которое обеспечивает подключение по схеме «каждый с каждым» и обрабатывает несколько одновременных подключений. Кроме того, коммутатор поддерживает такие службы, как Fabric Login (см. раздел 4.4.3.6). Коммутаторы могут быть подключены каскадно (в виде иерархии) или в виде сети, что позволяет формировать более сложные конфигурации. Очень часто строится трехуровневая иерархия, на самом нижнем уровне которой размещены кольца с разделением доступа Fibre Channel (FC-AL), подключенные к малопроизводительным коммутаторам. Эти коммутаторы, в свою очередь, подключаются к высокоскоростным коммутаторам, обеспечивающим максимально возможную пропускную способность.
Рис. 4.3. Топология коммутируемой-связной архитектуры Fibre Channel
Несколько коммутаторов могут быть соединены друг с другом. В топологии связной архитектуры используется 3-байтовый идентификатор (24 бит) для уникальной идентификации каждого устройства, что теоретически допускает подключение по схеме «точка-точка» для 224 устройств (примерно 15 млн.). Конечно, на практике сети хранения данных включают в себя намного меньше устройств.
Поскольку количество потенциальных устройств может быть достаточно большим, от сетей хранения данных на базе Fibre Channel требуется предоставление служб по управлению адресами, а также дополнительных служб; в противном случае ручное управление сетями хранения данных было бы невозможным. Учитывая, что обеспечение взаимодействия Fibre Channel и протоколов верхнего уровня (например, SCSI) проводится самими узлами, а адресное пространство весьма велико, динамическое управление адресами на инфраструктурном уровне будет обязательным (не требуя ручной настройки).
Топология связной архитектуры реализуется на основе коммутатора связной архитектуры (см. раздел 4.4.3.5). Кроме предоставления подключений «точка-точка», коммутатор предоставляет такие службы, как SNS (Simple Name Server), RSCN (Registered State Change Notification), FAN (Fabric Address Notification), Broadcast Server IP-FC, Principal Switch и Fabric Login. Эти службы кратко рассматриваются в разделах 4.4.3.1–4.4.3.6. Обратите внимание, что службы основаны на модели клиент/сервер. Серверный компонент реализован в виде коммутатора связной архитектуры, а клиентский компонент представляет собой такие устройства, как адаптеры шины и контроллеры RAID.
Этот сервер представляет собой базу данных коммутатора связной архитектуры. База данных отслеживает два типа информации.
Имя устройства и информация об адреде.
Поддерживаемые протоколы высокого уровня.
Сервер SNS позволяет инициатору сеанса связи, например адаптеру шины сервера, делать запрос к службе имен и получать список доступных устройств хранения данных. Это обеспечивает автоматическое управление адресами, что имеет особое значение, поскольку адресное пространство сетей хранения данных поддерживает до 15 млн. адресов. 1
При инициализации устройство связной архитектуры отправляет базовый пакет регистрации (в терминологии Fibre Channel он называется FLOGI) на известный адрес OxFFFFFE. Запрос на регистрацию вместо адреса заполняется нулевым значением, что обозначает запрос адреса.
Как только устройство подключается к коммутатору, инициируется другой базовый запрос (PLOGI), отправляемый серверу SNS, который имеет фиксированный адрес OxFFFFFC. Устройство отправляет соответствующую информацию, например адрес в формате WWN (World Wide Name), тип порта, адрес коммутатора, протоколы верхнего уровня (SCSI), которые поддерживаются устройством, и другие служебные параметры.
Некоторые устройства не отправляют SNS всю информацию о себе. Отдельные модели коммутаторов отправляют устройствам запросы целевого определения и обновляют значения соответствующих полей в базе данных SNS.
Служба RSCN (Registered State Change Notification) позволяет устройству регистрироваться для получения уведомлений о подключении к коммутатору или отключении от него других устройств. Например, сервер может зарегистрироваться для получения уведомлений при подключении к коммутатору или отключении от него связной архитектуры устройств хранения. Таким образом, RSCN дополняет сервер SNS: сервер позволяет компоненту Fibre Channel (например, узлу) обнаруживать другие компоненты (например, единицы хранения). В то же время служба RSCN позволяет узлу (компоненту Fibre Channel) регистрироваться для получения уведомлений об изменениях в составе компонентов Fibre Channel.
Пакеты RSCN могут прерывать передачу данных. Кадры RSCN используются получателем для обновления собственных таблиц маршрутизации. Некоторые поставщики предоставляют возможности по остановке широковещательного распространения пакетов RSCN на уровне коммутатора. Хотя это полезная функция, существует опасность, что из-за неправильной настройки кадр RSCN никогда не достигнет устройства, которое должно его получить.
Служба FAN (Fabric Address Notification) обеспечивает ликвидность транзакций, выполняемых устройствами. Обычно это необходимо в том случае, когда инициализация кольца прерывает активную передачу данных между двумя компонентами Fibre Channel.
Интерфейс Fibre Channel поддерживает протоколы более высокого уровня, требования для реализации которых должны быть выполнены. К одному из таких протоколов относится IP. Так как в рамках сетей IP поддерживается вторичный протокол ARP (Address Resolution Protocol), посредством которого устройства отправляют широковещательные запросы, этот же протокол должен поддерживаться и устройствами Fibre Channel.
При использовании в сети хранения данных на основе Fibre Channel нескольких коммутаторов связной архитектуры необходим протокол выбора одного из коммутаторов в качестве главного коммутатора (principal switch). Выбранный главный коммутатор будет работать как коммутатор с адресом
OxFFFFFE и обеспечивать уникальность адресов устройств в сети хранения данных на основе Fibre Channel.
Устройства связной архитектуры всегда стремятся воспользоваться службой Fabric Login. Для этого на фиксированный адрес OxFFFFFE отправляется специальный кадр FLOGI. Кадр FLOGI содержит адрес отправляющего устройства, который устанавливается в нулевое значение, если пакет используется для запроса нового адреса.
Служба Fabric Login позволяет выполнять следующие задачи:
получение информации о параметрах связной архитектуры, например списков поддерживаемых служб;
назначение адресов;
инициализация буфера для контроля передачи данных.
4.5 Типы портов Fibre Channel
В стандарте Fibre Channel определено несколько типов портов, зависящих от топологии сети хранения данных и от устройства, к которому относится порт. Различные типы портов представлены в табл. 4.2.
Окончание табл. 4.2
Чтобы облегчить жизнь администраторам сетей хранения данных, поставщики устройств обычно предоставляют порты с автоматическим конфигурированием. Такое конфигурирование проводится следующим образом.
1. Порт пытается инициироваться как порт кольца (FL). Если инициализация проходит успешно, порт настраивается как порт FL.
Если инициализация кольца завершается неудачно, делается попытка инициализации в виде порта Е; таким образом, проверяется возможность подключения к сети на базе связной архитектуры.
Если инициализация в виде порта Е завершается неудачно, порт пытается активизировать службу Fabric Login. Если регистрация выполняется
успешно, порт иницируется как порт F.
Не стоит рассчитывать, что все поставщики устройств устанавливают на них динамически конфигурируемые порты, которые могут работать вместо любого порта. Такая возможность встроена лишь в некоторые устройства. Это позволяет переконфигурировать порты без перезагрузки или отключения питания. Остальные устройства для получения определенного типа порта требуют замены прошивки или установки платы расширения, что может потребовать выключения питания.
4.6 Протокол Fibre Channel
В общем контексте Fibre Channel – это набор стандартов, разработанных в Национальном институте стандартизации США. Интерфейс Fibre Channel предоставляет высокопроизводительное последовательное подключение между хостом и единицами хранения, а также между самими единицами хранения. Стандарт позволяет обеспечить высокоскоростную передачу данных в сетях с топологией «точка-точка» и кольцо. Более того, Fibre Channel предоставляет все эти возможности вместе с проверкой ошибок.
В стандарте Fibre Channel определено пять функциональных уровней: от FC-0 до FC-4. Уровни рассматриваются в разделах 4.6.1–4.6.5. Обратите внимание, что по практическим соображениям уровни FC-0, FC-1 и FC-2 реализуются аппаратно.
Определяет физические характеристики интерфейса и носителя. В частности, посредством FC-0 определяются спецификации уровней сигналов, носителя и получателей/отправителей. Уровень FC-0 позволяет использовать несколько интерфейсов, что дает возможность выбирать разные скорости передачи данных и различные передающие среды. В качестве примера физической передающей среды можно привести медный провод, одномодовый и мно- гомодовый кабели. Скорость передачи варьируется от 12,5 до 106,25 Мбайт/с.
Те, кто знаком с семиуровневой сетевой моделью ISO OSI[7], могут заметить, что FC-0 соответствует седьмому уровню модели ISO OSI.
Определяет схемы кодирования и декодирования данных, сигналов и специальных символов, а также управление ошибками. Кроме того, уровень FC-1 отвечает за обслуживание лйЬий связи.
Уровень FC-1 использует схему кодирования, которая называется 8В/10В. Схема проектировалась для того, чтобы обеспечить следующее:
эффективную синхронизацию данных;
расширенное обнаружение ошибок;
эффективное обнаружение управляющих символов;
упрощенное проектирование аппаратного обеспечения приемников/передатчиков.
Схема кодирования 8В/10В преобразует каждые 8 бит в два возможных значения, объемом 10 бит. Эти 10 бит используются в виде Ann. m, где А – значение К для индикации команды или D для индикации данных; гш – десятичное значения последних пяти битов байта; М – десятичное значение первых трех битов байта.
Два возможных значения появляются потому, что посредством спецификации выбирается одно из значений для кодирования данных при их передаче на базе недавней истории передачи. Это необходимо для того, чтобы обеспечить минимальное количество переходов состояния (между 0 и 1), что повысит эффективность передачи. Недавняя история передачи называется динамическим рассогласованием.
Как уже отмечалось, все данные кодируются с помощью 10 бит. Некоторые неиспользованные 10-битовые символы (в контексте данных) применяются для отделения фреймов и сигналов, включая сигналы о готовности порта для принятия данных, а также другие типы сигналов. Основное внимание уделяется обнаружению и исправлению ошибок на этапе передачи. Данные Fibre Channel всегда передаются группами по 4 байта, которые называются словами передачи (transmission words).
Определяет передачу данных от одного узла к другому, т.е. непосредственно транспортный механизм. Уровень FC-2 формирует кадры, определяет классы обслуживания и службы регистрации связной архитектуры или портов. Этот уровень можно представить в качестве аналога уровню MAC (Media Access Control) в модели ISO OS1.
Рис. 4.4. Иерархия передачи данных Fibre Channel
Уровень FC-2 определяет:
иерархию передачи данных Fibre Channel, которая включает в себя упорядоченные множества, кадры, последовательности и обмены;
управление потоком Fibre Channel;
протоколы FC-2;
классы обслуживания FC-2.
Эти компоненты рассматриваются в разделах 4.6.3.1 4.6.3.7, но перед этим следует выяснить, как соединяются различные структурные элементы иерархии.
В Fibre Channel данные передаются с помощью кадров (frame). Кадр представляет собой эквивалент пакета TCP/IP. Кадры создаются из упорядоченных множеств и символов данных. Несколько кадров группируются вместе и формируют последовательность, а несколько последовательностей формируют обмен (exchange). Это демонстрируется на рис. 4.4.
В разделах 4.6.3.1–4.6.3.4 все эти компоненты рассматриваются более подробно.
Упорядоченные множества – это структуры последовательной передачи данных объемом 4 байта, которые представляют собой специальные символы или сигналы линии связи. Далее приведены примеры подобных множеств.
Разделители кадров SOF (Start Of Frame) и EOF (End Of Frame), которые являются аналогами пакетов SOF и EOF в сетях Ethernet. В отличие от Ethernet, в Fibre Channel определено несколько вариантов SOF и EOF, поскольку уровнем FC-1 используется схема кодирования, формирующая несколько представлений для каждого передаваемого символа.
Два базовых сигнала для указания состояния порта.
Idle – указание, что порт готов для передачи или приема данных.
Receiver Ready – указание, что буфер интерфейса (устройства взаимодействия) готов для приема данных.
Базовая последовательность. Простое упорядоченное множество, которое регулярно передается для указания особого статуса порта. К особым статусам относятся:
Not Operational (NOS) – используется только в сетях с топологией «точка-точка» или в связной архитектуре (но не в кольце с разделением доступа) для указания на отказ в работе линии связи или появление определенной ошибки;
Offline (OLS) – передается во время инициализации порта или при получении базового статуса NOS; таким образом, в ответ на NOS порт отправляет ответ OLS;
Link Reset (LR) – используется для указания на необходимость повторной инициализации линии связи;
Link Reset Response (LS) – используется для указания, что данные LR получены и обработаны.
Как пакет IP является базовым элементом протокола Internet (IP), так ■ и кадр представляет собой основной структурный элемент интерфейса Fibre Channel. Существует три типа кадров.
1. Кадры управления линией связи (link control frames), используемые для отправки команды управления линией связи.
Рис. 4.5. Заголовок кадра Fibre Channel
Кадры данных линии связи (link data frames), используемые для отправки данных, необходимых для управления линией связи.
Кадры данных устройства (device data frames), которые содержат данные для протоколов более высокого уровня, например данные, считанные с жесткого диска.
На рис. 4.5 показан заголовок кадра Fibre Channel. Кадр проектировался для передачи 2048 байт данных и необйзательного заголовка размером 64 байт. Подобный размер кадра позволяет передавать за один раз большой объем данных с минимальными накладными расходами (около 1,5%). Однако при этом другому узлу придется ждать, пока завершится передача большого кадра, что подразумевает увеличение задержек в передаче. Сравним это с протоколом ATM (Asynchronous Transfer Mode), где кадр имеет размер 53 байт и накладные расходы протокола составляют около 10%. Это позволяет снизить задержки, но время передачи определенного объема данных возрастает.
Каждый кадр начинается и заканчивается специальным ограничителем, как и в других сетевых протоколах. Это SOF и EOF соответственно. Каждый кадр имеет заголовок, выполняющий несколько функций. Одна из них – это предоставление адресов назначения и источника для обеспечения коммута-
дии данных. Еще одна задача состоит в переносе информации для управления линией связи, включая управление самой передачей.
Другие поля заголовка кадра Fibre Channel рассматриваются ниже.
Поле Destination_Id используется для маршрутизации кадра. В топологиях «точка-точка» и кольцо с разделением доступа маршрутизация может проходить обычным образом, что не относится к топологии коммутируемой связной архитектуры. Поле Source_Id предназначено для передачи сообщений об ошибках и для предотвращения циклов данных при маршрутизации.
Поля R_CTL и Туре используются для сортировки различных кадров уровня FC-4 по их прибытию в точку назначения. Таким образом, эти поля указывают, содержит ли прибывший кадр данные интерфейса SCSI, протокола IP или другие данные. Значения поля Туре описываются в табл. 4.3.
Поле R_CTL используется для указания содержимого кадра. Кадр может содержать данные или информацию для управления линией связи; в последнем случае кадры могут быть запрошенными и незапрошенными.
Таблица 4.3. Значения поля Туре в кадрах Fibre Channel
Поле F_CTL используется для описания информации кадра, например первой или последней последовательности.
Поле DF_CTL указывает на присутствие или отсутствие необязательных заголовков.
Поля SEQ_Id и SEQ_CNT уникально идентифицируют счетчик последовательности обмена (см. раздел 4.6.3.3).
Поле 0X_Id (идентификатор обмена источника) используется для связывания кадра с определенным обменом исходного порта.
Доле RX_Id (идентификатор обмена ответчика) используется для связывания кадра с определенным обменом отвечающего порта.
Поле Relative Offset идентифицирует относительное смещение первого байта основного содержания кадра от базового адреса.
Последовательность представляет собой набор кадров, которые передаются из одной точки в другую. Для исправления возможных ошибок каждый кадр содержит уникальный счетчик последовательности. Исправление ошибок осуществляется протоколом более высокого уровня, обычно на уровне FC-4. Обратите внимание, что все кадры в последовательности передаются в одном направлении (а не в обоих одновременно). На рис. 4.4 показано, как кадры, последовательности и обмены взаимодействуют друг с другом.
Несколько последовательностей составляют обмен (exchange). Обмены представляют собой последовательности двусторонних направлений; т.е. в обмен входят последовательности данных, передающихся в разных направлениях, хотя каждая последовательность передается только в одном направлении. При каждом обмене только одна последовательность может быть активна в текущий момент времени. Но, так как одновременно могут быть активны несколько обменов, различные последовательности из этих обменов также могут быть активны одновременно.
Каждый обмен выполняет одну функцию, например реализует команду SCSI Read.
Конечные узлы Fibre Channel взаимодействуют непосредственно друг с другом и не создают сеансовых подключений к промежуточным узлам.
Устройства не «подозревают» о коммутаторе связной архитектуры и концентраторе. Конечно, при этом коммутаторы и концентраторы обмениваются пакетами управления потоком с этими устройствами.
Механизм управления потоком требует, чтобы передающий порт не отправлял кадры быстрее, чем принимающий порт может их обработать. Порты Fibre Channel имеют буфера для временного хранения кадров и последующей их обработки. Под обработкой подразумевается отправка кадра на другой порт или передача кадра протоколу более высокого уровня. Схема управления потоком, которая используется в Fibre Channel, очень напоминает протокол плавающего окна в TCP/IP. Размер окна, представляющий собой количество кадров, которые можно отправить без подтверждения их приема, устанавливается сторонами обмена заранее. При этом согласованное значение не может быть изменено. Для каждого отправленного кадра размер окна уменьшается на единицу, а для каждого подтвержденного кадра – увеличивается на единицу. Управление потоком может осуществляться одним из двух способов: «точка-точка» или «буфер-буфер». При этом требуется совместное использование обоих методов.
Управление потоком по схеме «точка-точка» осуществляется между двумя конечными точками: источником данных (например, сервером) и получателем данных (например, жестким диском). Управление потоком «точка- точка» проводится между двумя портами типа N (между ними могут находиться промежуточные узлы). Два порта типа N регистрируют друг друга, в процессе чего каждый порт выделяет для себя определенное количество буферов у другого порта. Это количество называется резервированием буфера. Отправитель может отправлять количество кадров, не превышающее это значение. Получатель отправляет кадр АСК (позитивное подтверждение) для каждого успешно полученного и обработанного кадра, а отправитель при получении кадра АСК может увеличить значение резервирования (credit count) на единицу для каждого полученного кадра АСК. Получатель может подтвердить успешное получение нескольких кадров или даже целой последовательности и получатель должен будет, не ожидая подтверждения для каждого кадра в отдельности, увеличить количество кадров, которое можно отправлять.
Управление потоком по схеме «буфер-буфер» выполняется между двумя соседними узлами, которые представляют собой промежуточные узлы или находятся между конечным и промежуточным узлом. Таким образом, управление потоком от буфера к буферу выполняется между портами типа N или между портом F и портом N. Кале уже отмечалось, порты обменивают-г ся данными, указывающими на количество буферов, зарезервированных для каждого узла. Эти значения могут отличаться, например один порт может выделить два буфера, а второй – четыре буфера. Получение кадра подтверждается кадром Receiver Ready, а не кадром АСК как в управлении потоком «точка-точка».
В стандартах Fibre Channel определены протоколы для управления передачей данных и линией связи. Кроме того, описаны дополнительные стандарты для поддержки протоколов более высокого уровня, применяемых на уровне FC-4. Эти протоколы описаны ниже.
Протокол Fabric Login, который определяет обмен параметрами между портом и коммутатором связной архитектуры. Протокол и служба Fabric Login более подробно описываются в разделе 4.4.3.6.
Протокол Port Login, требующий, чтобы независимо от топологии («точка-точка», кольцо с разделением доступа или коммутируемая связная архитектура) два порта проводили взаимную регистрацию перед подключением друг к другу. Взаимная регистрация выполняется с помощью специального кадра PL0GI. С помощью протокола Port Login обеспечивается использование двух важных функций.
Возможность получения информации о порте N, на котором выполняется регистрация. К такой информации относится описание классов обслуживания, поддерживаемых портом N.
Инициализация буфера резервирования для управления потоком «точка-точка». Обратите внимание, что в контексте прямого подключения управление потоком «точка-точка» ничем не отличается от управления потоком «буфер-буфер».
Протокол Data Transfer, определяющий, как данные протокола верхнего уровня (уровня FC-4) передаются с помощью схем управления потоком, описанных в разделе 4.6.3.5.
Протокол Arbitrated Loop, который определяет методы инициализации и управления кольцом.
Интерфейс Fibre Channel проектировался для обеспечения различных способов передачи данных. Ряд служб отличается такими характеристиками:
тип сервисного подключения, т.е. аналогично TCP или без установки подключения, как в UDP;
поддержка многоабонентской доставки (multicast);
поддержка уведомления о доставке или невыполненной доставке;
поддержка гарантированной доставки кадров в том же порядке, в котором они были отправлены;
тип предоставляемых служб, например резервирование пропускной способности для соединения, если служба ориентирована на соединение;
тип механизмов управления потоком данных.
Для предоставления широкого диапазона вариантов передачи данных, определено неколько классов обслуживания.
Тип Class 1 определяет выделенное подключение, подобное подключению TCP/IP. Как и в TCP, Class 1 гарантирует, что кадры доставляются в той же последовательности, в которой они были отправлены. Тип Class 1 используется при передаче больших объемов данных, когда время, потраченное на установку соединения, на порядок меньше времени, необходимого для передачи данных.
Тип Class 2 определяет обслуживание без подключения (по аналогии с дейтаграммами), при котором кадры потенциально могут быть доставлены не в той последовательности, в которой они отправлялись (что подразумевает смену последовательности кадров протоколом более высокого уровня). Как и в случае использования сетевых протоколов, обслуживание Class 2 имеет смысл тогда, когда объем передаваемых данных достаточно мал и накладные расходы на установку соединения сравнимы с расходами на передачу самих данных. Получатель кадра Class 2 должен'отправить подтверждение при получении кадра.
Тип Class 3 также подразумевает обслуживание без установки подключения. Основное отличие от Class 2 состоит в том, что подтверждать успешное получение кадра нет необходимости. Это сравнимо с дейтаграммами IP, метод использования которых иногда в шутку называется «отправь и молись».
Тип Class 4, который также называется Intermix, является необязательным классом обслуживания. Класс гарантирует определенную пропускную способность кадрам Class 1, а оставшаяся пропускная способность используется для кадров Class 2 и Class 3;
Тип Class 6 представляет собой однонаправленное, ориентированное на подключение обслуживание с предоставлением возможности многоабонентской доставки (Class 5 зарезервирован).
В табл. 4.4 собрана вся информация о классах обслуживания Fibre Channel.
Обратите внимание, что большинство поставщиков поддерживают классы 1, 2 и 3. В то же время некоторые поставщики поддерживают только классы, не ориентированные на соединение (Class 2 и Class 3).
Определяет общие службы, включая службы по управлению и общему транспортному механизму. Уровень FC-3 – общий для всех портов узла. Уровни FC-1, FC-2 и FC-4 реализованы отдельно для каждого порта. В этой схеме поддерживается использование разными портами различной конфигурации (рис. 4.6). Например, один порт может передавать данные SCSI, а другой в это же время будет передавать данные ATM.
Кроме того, обратите внимание, что уровни FC-0, FC-1 и FC-2 относятся к различным портам, а уровень FC-3 относится к узлу. Верхний уровень FC-4 также относится к порту. На рис. 4.6 показан узел с четырьмя портами и двумя протоколами верхнего уровня – SCSI и IP. Если бы узел поддерживал больше протоколов верхнего уровня, на диаграмме присутствовали бы дополнительные блоки FC-4.
Далее представлены некоторые функции, реализованные на уровне FC-3.
Транкинг (trunking) или канальное уплотнение (striping), при котором параллельные линии связи и порты «сворачиваются» для обеспечения большей пропускной способности между узлами.
Многоабонентская доставка, при которой единая передача данных может быть направлена одновременно к нескольким портам. Реализуется посредством службы регистрации на коммутаторе связной архитектуры, с помощью которой узлы регистрируются и отменяют регистрацию для многоабонентской доставки. Доставка в этом случае очень похожа на режим групповой отправки (multicast) в IP. Обратите внимание: многоабонентская доставка может осуществляться на все порты коммутато-
pa связной архитектуры, т.е. может использоваться как широковещание (broadcast).
Свободный поиск (hunting), при котором несколько портов используют одинаковый псевдоним. Это похоже на объединение нескольких телефонных линий компании под одним номером, когда звонок на этот номер перенаправляется на одну из свободных линий. Очевидным преимуществом такой схемы будет повышение вероятности получить свободный порт.
Компания Brocade одна из многих реализует функцию транкинга в своих продуктах, хотя функция получила названия ISL (Inter Switch Link) Trunking. Называние подчеркивает высокую производительность коммутаторов Brocade, которые предназначены для подключения к другим коммутаторам, а не к серверам и устройствам хранения данных. Обратите внимание, что тран- кинг поддерживается и другими поставщиками.
Определяет связывание протоколов верхнего уровня с Fibre Channel. Вот эти протоколы (со временем будет реализована поддержка и других протоколов):
SCSI;
IP;
IPI (Intelligent Peripheral Interface);
HIPPI (High-Performance Parallel Interface);
IEEE 802.2;
SBCCS (Single-Byte Command Code Sets);
AAL5 (ATM Adaptation Layer);
FC-LE (Link Encapsulation).
Обратите внимание: одна линия связи Fibre Channel может одновременно передавать пакета данных нескольких протоколов верхнего уровня.
4.7 Структурные элементы SAN
В разделах 4.4 и 4.6 приведен обзор топологий и протокола Fibre Channel. Теперь рассмотрим различные устройства и компоненты, которые используются для создания сетей хранения данных Fibre Channel. К основным структурным элементам SAN относятся:
адаптеры шины;
кабели Fibre Channel;
разъемы;
устройства подключения, в число которых входят концентраторы, коммутаторы и коммутаторы связной архитектуры.
Все эти элементы рассматриваются в разделах 4.7.1–4.7.4. Обратите внимание, что все адресуемые компоненты в пределах сети хранения данных на основе Fibre Channel имеют уникальные имена WWN (World Wide Names), которые представляют собой аналоги уникальных адресов MAC. Имя WWN в спецификации Fibre Channel – это 64-разрядное число, записываемое в виде XX: XX: XX: XX: XX: XX: XX: XX. Институт IEEE назначает каждому производителю определенный диапазон адресов. Производитель отвечает за уникальное выделение назначенных адресов.
Адаптер шцны (host bus adapter – НВА) подключается к компьютеру и обеспечивает взаимодействие с устройствами хранения данных. В мире персональных компьютеров под управлением Windows адаптеры шины обычно подключаются к шине PCI и могут предоставлять подключение для устройств IDE, SCSI и Fibre Channel. Адаптеры шины работают под управлением драйвера устройства, т.е. драйвера мини-порта SCSIPort или Storport.
При инициализации порт адаптера шины регистрируется на коммутаторе связной архитектуры (если таковой доступен) и регистрирует хранящиеся на нем атрибуты. Атрибуты доступны приложениям с помощью API от производителя коммутатора или адаптера шины. Ассоциация SNIA (Storage Networking Industry Association) работает над стандартизированным API, поддерживающим различные API производителей.
Для сети хранения данных, к которой выдвигаются серьезные требования по отказоустойчивости, некоторые производители адаптеров шины предоставляют дополнительные возможности, например автоматическое переключение на другой адаптер шины при отказе в работе основного. Эти функции, а также дополнительная архитектура рассматриваются в главе 9.
В кольце с разделением доступа только два устройства могут одновременно осуществлять прием и передачу данных. Предположим, что одно из них – это адаптер шины, подключенный к узлу и получающий данные от устройства хранения. Но, если этот адаптер подключен к сети хранения данных на основе коммутируемой связной архитектуры, он может одновременно отправлять несколько запросов на чтение нескольким устройствам хранения.
Ответы на эти запросы могут приходить в любом порядке. Обычно коммутатор связной архитектуры предоставляет службу циклического обслуживания для портов, что еще более усложняет задачу адаптера шины; в этом случае порядок поступления пакетов окажется таким, что каждый следующий пакет будет приходить от другого источника.
Адаптеры шины позволяют решить эту проблему одним из двух способов. Первая стратегия, которая называется сохранить и отсортировать, подразумевает хранение данных в памяти узла с последующей сортировкой буферов за счет центрального процессора. Очевидно, что это неэффективный подход с точки зрения центрального процессора и общая нагрузка связана с переключением контекста каждые несколько десятков микросекунд. Другая стратегия – на лету – подразумевает использование дополнительной системной логики и микросхем на самом адаптере шины, что позволяет осуществлять переключение контекста без использования циклов центрального процессора. Обычно время между переключениями контекста при использовании такой стратегии составляет несколько секунд.
Как отмечается в разделе 4.6.3.5, понятие резервирование буфера определено, как часть стандарта Fibre Channel. Одно резервирование позволяет отправить один кадр Fibre Channel. Перед отправкой следующего кадра отправитель должен получить сигнал Receiver Ready. Для эффективного использования канала Fibre Channel необходимо одновременно передавать несколько кадров, что потребует несколько резервирований, следовательно, понадобится больший объем памяти для принятия кадров. Некоторые адаптеры шины имеют четыре буфера размером 1 Кбайт и два буфера по 2 Кбайт, хотя на некоторых высокоуровневых адаптерах устанавливается 128 и 256 Кбайт для резервирования буфера. Обратите внимание, что для этой памяти обычно требуется два порта; т.е. когда одна область памяти принимает данные от SAN Fibre Channel, остальные области памяти могут передавать данные шине PCI узла.
Кроме того, адаптеры шины играют роль в обеспечении -отказоустойчивости и в архитектуре с аварийным восстановлением данных, в которой предоставляется несколько маршрутов ввода-вывода к одному устройству хранения данных. Эти технологии рассматриваются в главе 9.
В Windows NT и Windows 2000 адаптеры Fibre Channel рассматриваются как устройства SCSI, а драйверы создаются в виде драйверов мини-портов SCSI. Как отмечается в главе 2, проблема состоит в том, что драйвер SCSIPort устарел и не поддерживает возможности, предоставляемые новыми устройствами SCSI, не говоря уже об устройствах Fibre Channel. Поэтому в Windows
Server 2003 была введена новая модель драйвера Storport, которая должна заменить модель SCSIPort, особенно для устройств SCSI-3 и Fibre Channel. Обратите внимание, что диски Fibre Channel используются Windows в качестве DAS-устройств, что обеспечивается уровнем абстракции, предоставляемым драйверами SCSIPort и Storport.
Иногда необходима повышенная производительность и надежность, даже за счет увеличения стоимости готового решения. В таких случаях сервер подключается к двухпортовым дискам через несколько адаптеров шины и несколько независимых сетей хранения данных Fibre Channel. Основная идея – исключить единую точку отказа в работе сети. Кроме того, в те моменты, когда система работает нормально, несколько маршрутов могут использоваться для балансировки нагрузки и повышения производительности. Дополнительная информация, включая методы, с помощью которых поставщики оборудования и компания Microsoft создают многомаршрутные системы, приводится в главе 9.
В основном используется два типа кабелей: оптические и медные. Ниже перечислены основные преимущества и недостатки кабелей.
Медные кабели дешевле оптических.
Оптические кабели поддерживают более высокие скорости передачи данных по сравнению с медными кабелями.
Медный кабель может использоваться на меньшем расстоянии, до 30 метров. При этом оптический кабель может использоваться на расстоянии до 2 километров (многомодовый кабель) или до 10 километров (одномодовый кабель).
Медный кабель более восприимчив к электромагнитным помехам и взаимному влиянию других кабелей.
Оптические данные обычно должны быть преобразованы в электрические сигналы для передачи через коммутатор и обратно в оптическую форму для дальнейшей передачи.
Существует только один тип медного кабеля, в отличие от оптического, который представлен двумя видами: многомодовым и одномодовым.
На коротких дистанциях используется многомодовый кабель, который имеет сердцевину диаметром 50 или 62,5 микрона (микрон – микрометр, или одна миллионная часть метра.) Световая волна, которая используется в многомодовом кабеле, имеет длину 780 нанометров, что не поддерживается в одномодовых кабелях. Для больших расстояний предназначен одномодовый кабель, диаметр сердцевины которого составляет 9 микрон. В одномодовом кабеле используется световой луч с длиной волны в 1300 нанометров. Несмотря на тематику этой главы (интерфейс Fibre Channel), стоит упомянуть, что такие кабели могут использоваться для построения сетей на основе других интерфейсов, например Gigabit Ethernet.
Поскольку интерфейсом Fibre Channel поддерживается несколько типов кабелей (и технологий передачи данных), устройства (например, адаптеры шины, устройства взаимодействия и хранения данных) выпускаются с разъемами, которые поддерживают подключение к передающей среде, что делается для снижения общих затрат. Существует несколько видов разъемов, предназначенных для различных передающих сред и интерфейсов[8].
■ Конверторы интерфейса Gigabit (Gigabit interface converters – GBIC) поддерживают последовательную и параллельную трансляцию передаваемых данных. Конверторы GBIC предоставляют возможность «горячего» подключения, т.е. включение/выключение GBIC не влияет на работу других портов. Конверторами используется 20-битовый параллельный интерфейс.
Модули линий Gigabit (Gigabit link modules – GLM) предоставляют функции, аналогичные GBIC, но для своей установки требуют отключения устройства. С другой стороны, они несколько дешевле, чем GBIC.
Адаптеры интерфейса носителя (Media Interface Adapters) используются для преобразования сигналов между медным и оптическим носителем и наоборот. Адаптеры интерфейса носителя обычно используются в адаптерах шины, но могут применяться и на коммутаторах и концентраторах.
Адаптеры малого формфйктора (Small Form Factor Adapters – SFF) позволяют размещать большее количество разъемов различных интерфейсов на плате определенного размера.
Устройства взаимодействия соединяют между собой компоненты сетей хранения данных. К ним относятся различные устройства, начиная от дешевых концентраторов Fibre Channel и заканчивая дорогими, высокопроизводительными и управляемыми коммутаторами связной архитектуры. Эти устройства рассматриваются в разделах 4.7.4.1–4.7.4.3.
Концентраторы FC-AL представляют собой бюджетный вариант для подключения нескольких узлов Fibre Channel (устройств хранения данных, серверов, компьютерных систем, других концентраторов и коммутаторов) в кольцевую конфигурацию. Обычно в концентраторах предоставляется от 8 до 16 портов. Концентратор может поддерживать различные среды передачи, например медные или оптические.
Концентраторы Fibre Channel – это пассивные устройства, т.е. любое другое устройство в кольце не может обнаружить их присутствия. Концентраторы обеспечивают следующие возможности:
внутренние соединения, которые позволяют любому порту подключаться к любому другому порту;
возможность обхода порта, к которому подключено неправильно работающее устройство.
Самая большая проблема в работе портов связана с тем, что в текущий момент времени они могут поддерживать только одно подключение Fibre Channel. На рис. 4.7 показано, что, если порт 1 получил управление для установки сеанса с портом 8, ни один другой порт не сможет передавать данные, пока установленный сеанс не завершится.
Концентраторы могут быть подключены к коммутаторам связной архитектуры Fibre Channel (они рассматриваются в разделе 4.7.4.3) без модификации. Кроме того, можно создавать каскад концентраторов, соединив два концентратора кабелем.
Концентраторы FC-AL занимают лидирующее положение на рынке Fibre Channel, но в процессе снижения стоимости коммутаторы связной архитектуры Fibre Channel становятся все более популярными.
Концентраторы FC-AL создаются такими компаниями, как Gadzoox Networks, Emulex и Brocade.
Самое значительное преимущество коммутаторов FC-AL
перед концентраторами состоит в одновременной поддержке нескольких подключений, тогда как концентраторы поддерживают только одно подключение в текущий момент времени (рис. 4.8).
Рис. 4.7. Концентратор Fibre Channel
Рис. 4.8. Коммутатор Fibre Channel
Возможность одновременной поддержки нескольких подключений связана с определенными сложностями. Устройства, подключенные к коммутатору кольца, даже не «подозревают» о своей роли. Коммутаторы кольца участвуют как в передаче данных, так и в адресации кольца. Ниже приводится дополнительная информация по этому вопросу, а также рассматривается роль коммутаторов в сетях хранения данных и методы, с помощью которых поставщики добавляют новые функции к своим продуктам.
Сервер, который намерен получить доступ к устройству хранения данных, должен отправить арбитражный запрос на управление кольцом. В нормальном кольце FC-AL на базе концентратора каждое устройство получает
арбитражный пакет до его возвращения адаптеру шины сервера, благодаря чему сервер получает контроль над кольцом. Коммутатор кольца отправит ответ об успешном получении управления немедленно, не отправляя запросы другим узлам. На этом этапе адаптер шины отправит базовый пакет Open, предназначенный для порта устройства хранения, который будет передан коммутатором кольца. Если порт в это время не выполняет передачи данных, особых проблем не должно возникнуть. В противном случае возможно появление конфликтных ситуаций. Для решения этой проблемы коммутатор кольца должен предоставить буфера для временного хранения кадров, предназначенных для порта 7. Некоторые поставщики коммутаторов предоставляют для этих целей 32 буфера на каждый порт.
Концентраторы FC-AL не играют роли в назначении адресов устройствам, а только передают базовые кадры адресов по кольцу. То же можно сказать и о большинстве коммутаторов. Однако некоторые устройства могут настаивать на получении определенного адреса. Некоторые концентраторы имеют возможность управлять порядком инициализации портов, что позволяет определенному порту инициализироваться первому, после чего устройство будет подключено к требующемуся порту.
Протокол FC-AL требует повторной инициализации кольца при подключении, отключении или повторной инициализации устройства. Такая инициализация кольца может привести к нарушению существующей связи между другими двумя устройствами. Некоторые производители коммутаторов предоставляют возможность выборочно экранировать и передавать пакеты LIP (Loop Initialization Primitives). Эта операция предназначена для минимизации проблем, сокращения времени повторной инициализации кольца и по возможности сохранения существующих сеансов передачи данных. В то же время необходимо обеспечить уникальность адресов устройств.
Если все устройства принимают участие в повторной инициализации кольца, дублирования адресов не происходит, так как устройства «защищают» свои адреса. Но, если некоторые устройства не принимают участия в повторной инициализации кольца, необходимо предотвратить назначение уже распределенных адресов устройствам, принимающим участие в повторной инициализации кольца. Уникальность адресов обеспечивается дополнительной логикой коммутатора кольца. При добавлении устройства хранения пакет LIP должен быть отправлен на сервер, однако LIP не требуется передавать устройствам хранения, которые никогда не устанавливают связь с другими устройствами хранения данных.
Некоторые устройства хранения могут устанавливать связь непосредственно с другими устройствами хранения, что используется для резервного копирования данных. Дополнительная информация об операциях копирования приводится в главе 5.
Если все устройства в кольце «знают» о связной архитектуре, коммутатор кольца передает обычным образом необходимые кадры, например кадры Fabric Login. Если устройства в кольце не поддерживают связную архитектуру, коммутатор кольца должен самостоятельно выполнять достаточно большой объем работы.
Коммутаторы кольца некоторых поставщиков не поддерживают каскадирование. Кроме того, некоторым коммутаторам кольца требуется обновление прошивки перед подключением к коммутаторам связной архитектуры. Ряд коммутаторов следует модернизировать для полной поддержки связной архитектуры перед их подключением к SAN.
Коммутаторы FC-AL производятся такими компаниями, как Brocade, McDATA, Gadzoox Networks, Vixel и QLogic.
Коммутаторы связной архитектуры Fibre Channel (Fibre Channel Fabric Switches – FC-SW) обеспечивают несколько выскоскоростных сеансов связи одновременно со всеми устройствами. На данный момент основные коммутаторы поддерживают быстродействие порядка 1 Гбит/с, в то время как скорость в 2 Гбит/с также перестает быть диковинкой. В основном коммутаторы связной архитектуры в пересчете на один порт стоят дороже, чем концентраторы и коммутаторы FC-AL, но они предоставляют намного больше функциональных возможностей.
Коммутаторы связной архитектуры более эффективны в сравнении с концентраторами и коммутаторами FC-AL. Например, коммутаторы предоставляют специальные службы, описанные выше, обеспечивают управление потоком с помощью базовых пакетов управления, а также, что гораздо важнее, некоторые коммутаторы способны эмулировать функции FC-AL для обеспечения обратной совместимости с более старыми устройствами.
Некоторые коммутаторы связной архитектуры поддерживают маршрутизацию без буферизации. Суть ее в том, что при получении заголовка кадра коммутатор быстро находит заголовок точки назначения, пока кадр все еще принимается. Преимущество такого подхода – снижение задержек при доставке кадра и отсутствие необходимости хранения содержимого кадра в памяти буфера. А недостаток заключается в немедленной передаче всех кадров, включая поврежденные.
Коммутаторы связной архитектуры играют важную роль в безопасности сетей хранения данных на основе Fibre Channel, что описывается более подробно в главе 7.
В табл. 4.5 приведены функциональные возможности и различия между тремя типами устройств Fibre Channel.
Как в этой главе, так и во всей книге термины мосты (bridges) и маршрутизаторы (routers) не относятся к традиционным мостам Ethernet и маршрутизаторам IP. В данном случае под мостами и маршрутизаторами подразумеваются устройства для Fibre Channel, а не для сетевых протоколов 2-го и 3-го уровней.
Мосты –■ это устройства, обеспечивающие взаимодействие между Fibre Channel и устаревшими протоколами, например SCSI. Мосты Fibre Channel- SCSI позволяют сохранить существующие инвестиции в устройства хранения SCSI. Такие мосты поддерживают интерфейсы SCSI и Fibre Channel и преобразуют данные двух протоколов. Таким образом, новый сервер с установленным адаптером шины Fibre Channel может получить доступ к существующим устройствам хранения SCSI. Мосты предоставляют интерфейс между параллельной шиной SCSI и интерфейсом Fibre Channel. Маршрутизаторы обладают аналогичными возможностями, но для нескольких шин SCSI и интерфейсов Fibre Channel. Маршрутизаторы систем хранения данных, или «интеллектуальные» мосты, предоставляют такие дополнительные возможности, как маскировка и отображение LUN, а также поддерживают команды SCSI Extended Сору. В качестве устройств, передающих данные, маршрутизаторы применяют команды Extended Сору для использования библиотеками хранения, что позволяет копировать данные между указанным целевым устройством и подключенной библиотекой. Эта функция также называется независимым резервным копированием (без сервера).
В качестве примера производителей маршрутизаторов и мостов можно привести такие компании, как Crossroads Systems, Chaparral Network Storage, Advanced Digital Information Corporation (ADIC после приобретения Path- light) и MTI.
4.8 Методы управления Fibre Channel
В предыдущих разделах рассматривались аппаратные элементы, формирующие сети хранения данных. В работе SAN также участвует немало различных программ, в основном предназначенных для управления, обеспечения безопасности, резервного копирования и восстановления данных. В разделах 4.8.1 и 4.8.2 рассматривается ряд концепций, необходимых для управления SAN и обеспечения безопасности данных. По сути, эти концепции предоставляют собой «сердце» SAN.
В ситуации, когда одна сеть содержит несколько компьютеров и единиц хранения данных, желательно ограничить влияние некоторых компьютеров (в терминологии Fibre Channel они называются узлами) до определенных подсистем хранения и некоторых единиц в рамках этих подсистем. Это имеет особый смысл в том случае, когда узел работает под управлением Windows NT, которая требует монтирования каждого обнаруженного устройства. С другой стороны, у UNIX есть таблица монтирования, благодаря чему монтируются только устройства, непосредственно указанные в таблице. Даже при использовании узлов под управлением UNIX желательно ограничить доступ из соображений обеспечения безопасности и для снижения вероятности повреждения данных. Доступ может быть ограничен тремя различными типами функций отображения и зонирования.
Базовая функция, реализованная в рамках узла; возможно, средствами программного драйвера адаптера шины.
Функция коммутатора.
Функция на уровне подсистемы хранения данных.
Термин зонирование связан с коммутаторами. Зонирование позволяет одним портам коммутатора подключаться только к заранее определенным портам. В некоторых случаях зонирование может ограничивать распространение управляющих кадров Fibre Channel; например, при появлении в кольце нового устройства хранения можно ограничить распространение кадра LIP среди других устройств.
С функциональной точки зрения зонирование дает возможность некоему компьютеру непосредственно подключаться к определенной подсистеме хранения данных. Недостаток такого подхода состоит в предоставлении всех ресурсов SAN для одного компьютера, который обычно не в состоянии полностью их использовать. В частности, зонирование не позволяет совместно загружать канал доступа сети или применять ресурсы подсистемы хранения данных.
Рис. 4.9. Зонирование SAN
Зонирование можно воспринимать в качестве аналога конфигурирования порта IP для маршрутизатора с поддержкой брандмауэра. Еще одним примером может быть настройка виртуальных локальных сетей (VLAN) в существующей физической локальной сети. В виртуальной локальной сети только некоторые устройства «видят» друг друга, даже если в той же физической локальной сети находятся и другие устройства. Точно так же зонирование ограничивает возможности компонентов SAN (особенно инициаторов), предоставляя ограниченные данные об определенных единицах хранения и возможность доступа к ним, даже если в этой же физической сети хранения данных размещены и другие устройства хранения.
На рис. 4.9 демонстрируется концепция зонирования. Сеть хранения данных имеет три сервера и три единицы хранения. Различными оттенками указываются разные зоны.
Имена LUN могут совместно использоваться программным обеспечением файловой системы SAN. В этом программном обеспечении один или несколько серверов работают как серверы метаданных. Программное обеспечение устанавливается на клиентском компьютере (на компьютере, который желает получить доступ к файлам в сети хранения данных) и на сервере метаданных. Метаданные предоставляют клиентскому компьютеру информацию для отображения логического смещения в файле на физический номер блока указанного устройства. Это позволяет клиентскому компьютеру непосредственно получать доступ к файлу через SAN, без переноса данных через сервер. При достаточно грамотной организации обычные разрешения для файлов на
клиентском компьютере будут относиться и к файлам, хранящимся удаленно, что не требует от администратора дополнительных действий по настройке разрешений на совместный доступ к файлам.
Можно определить несколько зон, причем один узел имеет возможность входить в несколько зон одновременно; таким образом, некоторые зоны будут перекрываться. Зонирование выполняется несколькими способами.
Зонирование по номеру порта. Преимущество такого подхода – эффективность. Если устройство, подключенное к порту, заменено другим устройством, повторная настройка не потребуется.
Зонирование по имени WWN. Осуществляется путем указания имен WWN, которые входят в одну зону. Некоторые WWN могут быть указаны в нескольких зонах. Преимущество состоит в безопасности, которая, однако, достигается за счет эффективности. Изменения в конфигурации могут потребовать перезагрузки сервера.
Программное зонирование. Проводится средствами сервера имен (программного обеспечения), который выполняется на коммутаторе. Для программного зонирования могут использоваться номера портов, WWN или комбинация этих параметров. Сервер имен содержит базу данных, в которой хранятся WWN, номера портов и идентификаторы зон.
Аппаратное зонирование. Осуществляется с помощью таблицы маршрутизации, которая хранится на коммутаторе. Аппаратное зонирование выполняется на основе WWN и не принимает во внимание номера портов.
Ресурсы хранения могут быть «разделены» на несколько вложенных единиц (субъединиц), которые называются номером логического устройства (logical unit number – LUN). Стандарт SCSI-2 поддерживает до 64 LUN на одно устройство.
С функциональной точки зрения маскировка LUN позволяет определенному компьютеру получить доступ к конкретной субъединице на некой системе хранения данных. Однако гораздо важнее то, что с помощью этого способа можно запретить доступ к определенным LUN для некоторых компьютеров или серверов. Маскировка LUN дает возможность совместно использовать ресурсы хранилищ данных и (неявно) пропускную способность сети, однако непосредственно LUN совместно использоваться не может. Для совместного использования одного LUN несколькими компьютерами необходима файловая система с дополнительными возможностями, которая описана в главе 6.
Маскировка LUN необходима для гарантирования целостности данных в среде SAN. Обратите внимание: маскировка LUN – это средство обеспечения безопасности на уровне дисков, но не обязательно на уровне файлов. В последнем случае (на уровне файлов) потребуется дополнительное программное обеспечение.
Маскировка LUN предоставляет дополнительные возможности, в частности номера LUN могут быть переназначены другим компьютерам. Существует несколько способов обеспечения маскировки LUN. Каждый способ обладает своими достоинствами и недостатками. Обычно, маскировка выполняется средствами:
аппаратного обеспечения адаптера шины;
аппаратного обеспечения коммутатора Fibre Channel;
аппаратного обеспечения устройства хранения Fibre Channel;
программного обеспечения узла.
Эти варианты рассматриваются в разделах 4.8.2.1–4.8.2.4.
В BIOS адаптера шины осуществляется маскировка всех LUN, которые не отображены в таблице BIOS адаптера шины. Таким образом, узел (с установленным адаптером шины) попросту не «замечает» существования LUN, которые он и не должен «видеть».
Недостаток такого метода состоит в необходимости проведения корректной настройки; кроме того, метод не обязателен к применению. Все системы, адаптеры шины которых настроены неправильно или не поддерживают описываемую функцию, могут получить доступ к тем LUN, к которым доступ на самом деле нежелателен. Еще одна проблема заключается в сложности динамического управления и перенастройки подобных систем.
Коммутаторами Fibre Channel зонирование проводится достаточно просто. Входящий пакет передается или не передается дальше, что зависит от адресов исходного порта и порта назначения. Маскировка LUN возлагает дополнительную нагрузку на коммутаторы Fibre Channel, поскольку коммутатору приходится проверять первые 64 байта каждого пакета данных. Это приводит к снижению производительности большинства коммутаторов Fibre Channel, поэтому описываемая функция обычно не реализуется.
Этот метод маскировки LUN является принудительным для подключенных узлов или требует от узла минимального участия. Маскировка LUN реализуется контроллером подсистемы хранения данных или маршрутизатором (с помощью соответствующей прошивки). Эти устройства настроены на поддержку таблицы имен WWN адаптера шины, отображённых на номера LUN, к которым им (контроллеру или маршрутизатору) разрешен доступ. Значительное преимущество такого подхода заключается в формировании конфигурации, независимой от промежуточных коммутаторов или концентраторов.
Недостаток метода заключается в закрытой реализации этой технологии каждым поставщиком и сложности создания единой консоли управления для перенастройки или даже получения информации о текущих параметрах, хотя каждый поставщик предоставляет интерфейсы для управления связками WWN-LUN.
К поставщикам систем, поддерживающим эту технологию, относятся Crossroads Systems, EMC, Dot Hill и HP (в продуктах Storage Works). Поставщики присваивают реализации технологии собственные названия; например, компания Crossroads называет это Access Controls, а компания HP в продуктах StorageWorks выбрала название Selective Storage Presentation.
Маскировка LUN выполняется. программным обеспечением узла, в частности кодом драйвера устройства. Код должен работать в режиме ядра, так как основная идея заключается в том, чтобы предотвратить доступ операционной системы к LUN, а операционная система сделает'это еще до запуска первого приложения пользовательского режима.
Такая маскировка может выполняться в виде функции операционной системы или вне системы. За неимением конкретного решения от Microsoft некоторые поставщики добавили необходимый код в драйвер адаптеров шины. Обычно драйвер выдает команду Report LUNs каждому устройству, подключенному к шине, и перед предоставлением списка LUN системе Windows NT драйвер «вырезает» LUN из списка на основе дополнительно запрошенных данных (например, информации системного реестра Windows NT), таким образом «скрывая» некоторые LUN от Windows.
Основная проблема такого метода – необязательная настройка, а следовательно, необходимость частичного участия узла в процессе маскировки LUN. Это означает, что компьютеры, не имеющие модифицированного драйвера адаптера шины, не принимают участия в маскировке LUN. Кроме того, присутствуют и проблемы масштабирования, так как в особенно больших сетях хранения данных сложно настроить каждый сервер и каждый адаптер шины сервера. Что касается преимуществ, то LUN может эффективно использоваться несколькими серверами.
Описываемая функция реализуется в продуктах компаний Emulex, Dell и JNI.
На данный момент существует информация, что Microsoft работает над реализацией возможностей маскировки LUN в драйвере порта. Тем не менее такая возможность отсутствует в Windows Server 2003. Преимущество использования драйвера порта состоит в постоянном присутствии драйвера. порта в памяти, поэтому время, в течение которого компьютер не будет принимать участие в маскировке LUN, существенно снижается. Вероятность загрузки неправильного драйвера порта намного ниже, чем вероятность загрузки неправильного драйвера порта и мини-порта. Судя по предварительным прогнозам, если описываемая функция будет реализована в Windows, администратор получит возможность самостоятельно определять и изменять список LUN, видимых для сервера; при этом список может быть изменен временно. В последнем случае изменения не будут сохраняться после перезагрузки сервера.
4.9 Обеспечение взаимодействия устройств Fibre Channel
Призыв «Покупатель, берегись!» хорошо описывает состояние взаимодействия устройств в мире Fibre Channel.
Можно сказать, что большинство проблем во взаимодействии конфигураций FC-AL связаны с устройствами хранения, адаптерами шины, коммутаторами FC-AL и поставщиками маршрутизаторов. Поставщики устройств проводят серьезное тестирование своих продуктов, но, хотя теоретически взаимодействие с другими устройствам и должно быть гарантировано, на практике для получения результата требуется немало дополнительного тестирования и настроек различных параметров. Рекомендуется использовать конфигурации, которые были протестированы поставщиком или продавцом готовых решений SAN.
Наибольшая проблема состоит в отсутствии гарантированного соответствия промышленным стандартам. Более того, даже соответствие стандартам также не обеспечивает 100%-ного взаимодействия.
Поставщики готовых решений, такие, как IBM, HP и EMC» создают лаборатории для тестирования взаимодействия различных устройств и проводят собственную сертификацию. До определенной степени другие поставщики поступают аналогично. Рекомендуется использовать именно такие сертифицированные решения, что позволяет избежать проблем, часто возникающих при добавлении новых, не сертифицированных поставщиком устройств.
Хотя немало сетей хранения данных на основе Fibre Channel обеспечивают быстродействие 1 Гбит/с, в последнее время в продаже появились устройства, поддерживающие скорость 2 Гбит/с. Новые устройства – новые проблемы. В стандартах, которым следуют производители, поддерживается скорость 2 Гбит/с, однако устройства автоматически переходят на скорость 1 Гбит/с, если на этой скорости работают другие устройства в сети. Дело в том, что сети хранения данных на базе Fibre ^ Channel должны работать на скорости самого медленного устройства в сети. Таким образом, даже единственное устройство, работающее на скорости 1 Гбит/с, заставит всю сеть хранения данных работать на этом уровне быстродействия.
4.10 Сложности практической реализации
Сети хранения данных на основе Fibre Channel эмулируют прямое подключение устройства хранения данных к серверу, даже если устройство на самом деле подключено через коммутатор. Таким образом, в контексте Windows доступ к устройствам Fibre Channel осуществляется с помощью драйверов SCSIPort или Storport, описанных в главе 2. Таким образом, особенности работы с хранилищем, подключенным непосредственно к серверу (DAS), имеют отношение и к SAN.
Новая модель драйверов Storport предоставляет массу функциональных возможностей, включая оптимизацию ввода-вывода и управление пропускной способностью сети, однако системные администраторы и ответственные лица в информационных отделах компаний должны обратить внимание на тот факт, что модель драйверов Storport поддерживается исключительно в Windows Server 2003. Принявшим решение об использовании платформы Windows стоит изучить планы поставщика устройств хранения данных относительно перехода на модель Storport. В то же время необходимо обратить внимание на реализацию поддержки этих устройств на базе платформы Windows 2000, включая подробности реализации драйвера устройства. Это особенно важно для определения адекватности пропускной способности устаревающей модели драйверов SCSIPort, если поставщик будет продолжать ее применение. Кроме того, необходимо узнать, предоставляет ли поставщик собственную архитектуру SAN, без модели драйверов SCSIPort, а также сертифицировано ли это решение и поддерживается ли оно всеми заинтересованными сторонами. Наконец, обратите внимание на планы поставщика по переходу на модель драйверов Storport для Windows Server 2003.
Маскировка LUN на данный момент не поддерживается в продаваемых версиях Windows, причем выпуск Windows Server 2003 не изменил ситуации. Прежде чем приобретать новое программное и аппаратное обеспечение, выясните, какую технологию использует поставщик для реализации маскировки LUN и насколько она подходит для работы в среде Windows.
4.11 Резюме
Сети хранения данных 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.
Исторически сложилось так, что серверные приложения запускались только в рабочее время. Операции резервного копирования соответственно выполнялись в нерабочее время, т.е. ночью, когда работу приложений можно остановить, не оказывая влияния на пользователей. Как только работа приложения прекращена, сервер можно отключить от сети и провести резервное копирование данных. С этим подходом связаны две проблемы.
Значительное увеличение объема данных усложняет завершение резервного копирования в выделенный период времени. Как ни странно, но запись на магнитную ленту в контексте как затрачиваемых машино- часов, так и времени обслуживающего персонала весьма неэффективна. Необходимо найти ленту, вставить ее в накопитель и перемотать на нужную позицию. Как только позиция будет найдена, запись данных на ленту будет проводиться намного медленнее, чем на жесткий диск. Интерфейсы жестких дисков поддерживают запись со скоростью на порядок больше 80 Мбайт/с, а самые быстрые накопители на магнитной ленте поддерживают максимальную скорость передачи 30 Мбайт/с. Для управления несколькими накопителями могут использоваться роботизированные библиотеки, которые весьма недешевы и помогают сократить затраты времени только на поиск и загрузку ленты. Такие библиотеки не в состоянии увеличить скорость чтения данных или их записи на ленту.
Вторая проблема заключает в том, что все больше приложений, а также создаваемые, управляемые и модифицированные ими данные рассматриваются как важные, если не критические, для выживания компании в конкурентной среде. Это означает, что время, в течение которого можно отключить сервер от сети для резервного копирования, сокращается.
Потребители используют все больше корпоративных приложений, которые очень редко, если это вообще возможно, разрешено останавливать для резервного копирования. По этой причине каждый поставщик приложений предоставляет API для резервного копирования и восстановления файлов с данными приложения. Хотя создание таких API выглядит весьма оптимистично, на самом деле ситуация только ухудшилась.
На рис. 5.1 представлена проблема поддержки все увеличивающегося количества API для резервного копирования и восстановления данных. Как видите, потребители обычно используют несколько приложений, и очень часто применяется несколько версий одного и того же приложения. Каждый поставщик систем резервного копирования должен создавать программный код, использующий API, предоставленный для каждого корпоративного приложения. Поскольку многие поставщики приложений отдельно лицензируют агенты резервного копирования для различных приложений, сам процесс отслеживания лицензий на программное обеспечение и их стоимости может вызвать смятение у менеджера отдела информационных технологий. Более того, следует учесть развертывание инфраструктуры, обучение персонала и четкое выполнение инструкций, необходимых для эффективного резервного копирования.
Еще одна проблема при выполнении резервного копирования связана с тем, что процесс занимает значительное время. Если устройство записи на магнитную ленту поддерживает запись со скоростью 10 Гбайт/мин, резервное копирование диска объемом в 100 Гбайт займет 10 мин. В течение этих 10 мин приложения будут получать доступ к диску и вносить изменения в данные, записанные на диске. Существует три подхода к обеспечению целостности резервной копии.
1. Запрет приложениям доступа к диску в процессе резервного копирования. Блокирование одновременного доступа пользователей к диску во время резервного копирования было достаточно распространенным на раннем этапе использования персональных компьютеров, когда работа в режиме 24x7 не практиковалась. Резервное копирование выполнялось в периоды пониженной нагрузки, например в ночные часы. Теперь этот подход не всегда возможен, и тому есть ряд причин.
Рис. 5.1. Экспоненциальное увеличение количества API для резервного копирования
В требованиях к работоспособности системы часто указан режим работы 24x7, поэтому более подходящего времени для резервного копирования попросту не существует.
Объем данных, которые необходимо разместить в резервной копии, возрастает, как и время активного использования этих данных, поэтому окна резервного копирования не всегда хватает для завершения операции копирования.
2. Резервное копирование данных, в то время когда приложения получают доступ к диску, пропуская открытые файлы. Проблема заключается в том, что в процессе резервного копирования работают только действительно важные приложения, поэтому при таком подходе крайне необходимые данные могут не попасть в резервную копию!
3. Разделение ввода-вывода, инициированного приложением резервного копирования, и ввода-вывода, инициированного другими приложениями. Поставщики программ резервного копирования частично смоделировали ряд функций операционной системы. В частности, их программы зависят от возможности различать источники ввода-вывода. Однако такой метод вполне может оказаться бесполезным. Программы резервного копирования обычно в той или иной мере используют недокументированные возможности операционной системы, которые могут измениться с выходом новой версии. Кроме того, требуется достаточно большой объем свободного дискового пространства. Еще один вариант заключается в обработке каждого файла в отдельности или всех файлов одновременно.
Для резервного копирования открытых файлов с одновременным сохранением целостности резервной копии данных также используется три подхода.
Первый подход – перенос записи приложений во вторичную область хранения, что позволяет приложению резервного копирования делать резервную копию всех файлов. Такой подход должен работать выборочно; например, запись в файл подкачки будет разрешена, а запись в файлы данных приложений должна откладываться или размещаться в предварительно определенном вторичном кэше (он часто называется вторичным хранилищем), что позволяет обеспечить целостное резервное копирование данных. Ввод-вывод данных во вторичную область хранения также должен осуществляться особым образом, в зависимости от того, выполняется ли он приложением для резервного копирования или другой программой. Как только приложение для резервного копирования завершит работу, данные из вторичного хранилища должны быть скопированы поверх обычных файлов.
Второй подход – копирование данных при их записи приложением резервного копирования. Как только приложение резервного копирования открывает файл, другим приложениям будет по-прежнему разрешена в него запись. Для того чтобы старые и новые данные не смешались, перезаписываемые данные копируются во вторичное хранилище. Если обычные приложения запрашивают эти данные, операция чтения обрабатывается базовыми драйверами файловой системы Windows. По запросу приложения резервного копирования данные извлекаются из хранилища. Компания St. Bernard Software реализовала такой подход в своих системах для резервного копирования открытых файлов.
Обратите внимание на уровни драйверов, показанные на рис. 5.2 (подробное описание драйверов Windows, объектов устройств и т.д. приводится в главе 1). Драйверы фильтрации файловой системы размещены над драйвером файловой системы NT (NTFS), который, в свою очередь, расположен над драйвером фильтрации диска. Последний находится над драйвером класса диска, ниже которого находятся и другие драйверы (см. главу 1), однако в данном случае они нас не интересуют. Как только приложение открывает файл, NTFS (в ответ на запрос приложения) отправляет последовательность команд для чтения метаданных (расположение файла на диске) и отправляет запросы на чтение и запись логических блоков, где хранится этот файл.
Рис. 5.2. Драйверы фильтрации Windows NT
Драйвер фильтрации верхнего уровня (он расположен над файловой системой) показан на рис. 5.2. Расположение этого драйвера идеально подходит для перехвата выполняемых над файлами операций и перенаправления вызовов, если это необходимо для решения проблемы резервного копирования открытых файлов. Компания Microsoft предлагает набор Windows Installable File System (IFS), в котором представлена информация, необходимая для написания подобного драйвера фильтрации. Разработчики программ резервного копирования могут решить проблему на более низком уровне; например, уровень образа обычно требует создания драйвера фильтрации нижнего уровня (он находится над драйвером класса диска), что показано на рис. 5.2.
Операции ввода-вывода (см. рис. 5.2) выполняются на уровне файловой системы, что показано стрелкой, обозначенной цифрой 1. Драйвер NTFS управляет отображением данных файла на дисковые блоки; операции ввода-вывода выполняются на уровне дисковых блоков, что показано стрелкой, обозначенной цифрой 2. Компания Microsoft предоставляет драйвер фильтрации diskperf. sys, который входит в набор разработки Windows Driver Development Kit (DDK). Несколько поставщиков систем резервного копирования использовали набор DDK для создания программ, с помощью которых выполняется моментальный снимок данных.
Третий подход – создание моментального снимка данных и резервное копирование этого снимка в то время, когда приложения будут продолжать использовать оригинальный том. Моментальный снимок может быть создан с помощью различных программных и аппаратных решений, которые Microsoft предлагает в качестве базовой стратегии в Windows Server 2003.
5.3 Классификация типов резервного копирования
Существуют различные схемы резервного копирования, которые применяются, например, в центре хранения данных. Стоит отметить, что различные категории резервного копирования могут использоваться совместно. Резервное копирование классифицируется следующим образом:
на базе архитектуры;
на основе функциональных возможностей;
на базе сетевой инфраструктуры.
Рассмотрим каждый тип классификации подробнее.
Один из типов классификации резервного копирования основан на архитектуре. Резервное копирование зависит от объектов, к которым оно применяется, и от того, насколько приложение резервного копирования поддерживает подобные объекты. Доступные архитектурные типы резервного копирования описаны в разделах 5.3.1.1–5.3.1.3.
В этом случае приложение резервного копирования работает с блоками данных. Обычно подобная схема резервного копирования требует прекращения доступа к копируемым данным со стороны всех приложений на сервере. Приложение получает доступ к жесткому диску независимо от его внутренней структуры, после чего выполняет операции чтения/записи на уровне логических блоков.>
Преимущество такого типа резервного копирования состоит в быстродействии операций резервного копирования и восстановления данных, что особенно важно для восстановления данных после критических сбоев в работе систем. Недостаток заключается в том, что существует запрет на доступ к диску со стороны приложений и даже операционной системы. Еще один недостаток – это копирование излишнего количества неиспользуемых логических блоков с резервной копии при резервировании диска с разрешенными файлами. Некоторые приложения резервного копирования предоставляют соответствующую программную логику, необходимую для обнаружения и пропуска неиспользованных логических блоков. Такие резервные копии называются разреженными копиями дискового образа.
Наконец, довольно сложно получить только определенный файл или несколько файлов, в отличйе от восстановления всех данных на диске. Для этого программное обеспечение резервного копирования должно обработать метаданные файловой системы, сохраненные на магнитной ленте, и вычислить расположение на ленте необходимого файла. Некоторые программы позволяют восстанавливать определенные файлы из резервной копии на уровне образа, однако лишь для некоторых операционных систем. Другие приложения пытаются оптимизировать восстановление файла из резервной копии уровня образа, записывая на ленту метаданные файла, например таблицу расположения файлов для файловой системы FAT16.
Версия NTFS, которая поставляется вместе с Windows 2000, уже содержит все метаданные в файлах, например битовую карту, которая соответствует расположению логических блоков. Программа восстановления данных находит необходимые метаданные, из которых рассчитывает расположение на магнитной ленте каждого необходимого логического блока требующегося файла. После этого лента прокручивается, в одном направлении и все необходимые участки считываются в процессе перемотки, что позволяет получить все данные для восстановления файла. Лента не перематывается в обоих направлениях, поэтому сокращается не только время восстановления, но и срок жизни ленты. К описываемым приложениям резервного копирования относится, например, программа Legato Celestra.
Обратите внимание, что иногда выбор метода резервного копирования ограничен. Если база данных использует чистый дисковый том без файловой системы, то выбирать приходится только между резервной копией на уровне образа и резервной копией на уровне приложения (такой тип резервного копирования рассматривается в разделе 5.3.1.3).
В этом типе резервного копирования программа резервирования пользуется услугами операционной и файловой систем. Одно из преимуществ заключается в эффективности восстановления конкретного файла или набора файлов. Еще одно преимущество состоит в возможности одновременного доступа к файлам со стороны операционной системы и приложений, когда проводится резервное копирование.
Не обошлось здесь, впрочем, и без недостатков. Резервное копирование выполняется дольше, особенно по сравнению с резервным копированием на уровне образа. Если проводится копирование большого количества небольших файлов, нагрузка на операционную и файловую систему при доступе к метаданным каталогов может оказаться значительной. Кроме того, существует проблема открытых файлов, которая, была описана ранее.
Еще один недостаток связан с безопасностью. Эта проблема возникает вне зависимости от метода создания резервной копии (на уровне образа или файла) и заключается в том, что резервное копирование выполняется на правах учетной записи администратора или оператора резервного копирования, а не пользователя. Это единственный способ восстановить файлы различных пользователей в ходе одной операции восстановления. Необходимым условием является корректная настройка метаданных файлов, например списков управления доступом и данных о владельцах файлов. Решение проблемы требует поддержки со стороны API файловой и операционной систем, что необходимо для настройки метаданных при восстановлении данных из резервной копии. Кроме того, приложение резервного копирования и восстановления должно корректно использовать предоставленные возможности.
В этом случае резервное копирование и восстановление данных выполняется на уровне приложения, например Microsoft SQL Server или Microsoft Exchange.. Резервное копирование проводится с помощью API, предоставленного приложением. В данном случае резервная копия состоит из набора файлов и объектов, которые формируют состояние системы на определенный момент времени. Основная проблема заключается в том, что операции резервного копирования и восстановления тесно связаны с приложением. Если с выходом нового приложения изменится API или функции уже существующего API, администратору придется переходить к новой версии программы резервирования.
Приложения используют чистый диск без файловой системы или записывают на него огромный файл, в котором размещены собственные метаданные приложения. В качестве примера подобного приложения можно указать Microsoft Exchange. В Windows ХР и Windows Server 2003 поддерживаются важные функции NTFS, благодаря которым возможно восстановление таких файлов. Файл восстанавливаемся логическими блоками и в конце маркируется новой функцией Win32 API, которая называется SetFileValidData.
Еще один метод классификации приложений резервного копирования заключается в классификация на базе функций, предоставляемых в процессе резервного копирования. Обратите внимание, что обычно в центрах хранения данных используется, как минимум, два, а чаще всего все типы резервирования, описанные ниже, а именно: полное, дифференциальное и инкрементное.
При полном резервном копировании (full backup) полный набор файлов или объектов, а также связанные с ними метаданные копируются на носитель резервной копии. Преимущество состоит в том, что используется только один набор носителей для восстановления в случае отказа в работе системы. Недостаток заключается во времени копирования, так как копируются все данные. Полное резервное копирование часто выполняется на уровне дискового образа или на уровне блоков.
При дифференциальном резервном копировании (differential backup) архивируются все изменения, которые произошли с момента последнего полного резервного копирования. Так как дифференциальные резервные копии могут создаваться на уровне образа или на уровне файлов, этот набор изменений будет представлять собой набор изменившихся дисковых блоков (для резервной копии на уровне образа) или набор изменившихся файлов (для резервной копии на уровне файлов). Основное преимущество дифференциального резервного копирования состоит в значительном уменьшении времени копирования по сравнению с полным резервным копированием. С другой стороны, восстановление после сбоя занимает больше времени. Восстановление после сбоя потребует проведения двух операций по восстановлению данных. В ходе первой будут восстанавливаться данные из полной резервной копии, а во время второй – данные из дифференциальной резервной копии.
При использовании недорогих подсистем хранения данных дифференциальное резервное копирование на уровне файлов применяется в тех случаях, когда приложения создают множество небольших файлов и после создания полной резервной копии меняют некоторые файлы. В то же время такое резервное копирование не применяется, если жесткий диск используется приложениями управления базами данных, которые постоянно вносят небольшие изменения в огромные файлы баз данных. Таким образом, при резервировании на уровне файла будет создана копия целого файла. Примером такой программы служит Microsoft Exchange, которая постоянно стремится вносить небольшие изменения в огромные файлы баз данных.
При использовании старших моделей подсистем хранения данных дифференциальное резервное копирование на уровне образа можно использовать в любой ситуации, включая резервное копирование файлов приложений баз данных. Причина такой эффективности состоит в хранении большого объема метаданных, которые позволяют быстро определить изменившиеся с момента резервного копирования дисковые блоки. Таким образом, будет проведено резервное копирование только изменившихся дисковых блоков, а большое количество не изменившихся дисковых блоков не будут скопированы. Даже несмотря на более высокую эффективность резервного копирования при использовании старших моделей подсистем хранения данных, остается необходимость в использовании API, который позволит начать резервирование в определенный момент времени и продолжить ввод-вывод данных после завершения резервного копирования. Метод работы старшей модели подсистемы хранения заключается в сокращении операций ввода-вывода данных, которые должны быть остановлены при резервном копировании.
При инкрементном резервном копировании (incremental backup) архивируются только изменения с момента последнего полного или дифференциального резервного копирования. Очевидно, что этот вид резервного копирования требует меньше времени, так как на резервный носитель не копируются файлы, которые не изменились с момента создания последней полной или добавочной резервной копии. Недостатком этого метода является длительность операции восстановления после сбоя, так как оно выполняется с помощью набора из нескольких носителей, соответствующих последней полной резервной копии и нескольким добавочным резервным копиям.
В случае отсутствия старших моделей подсистемы хранения добавочное резервное копирование выполняется при изменении или добавлении различных наборов файлов. При использовании старших моделей подсистемы хранения может применяться добавочное резервное копирование на основе блоков, так как в этом случае доступен достаточный объем метаданных для идентификации изменившихся блоков.
Один из способов классификации резервного копирования основан на сетевой топологии и ее влиянии на выбор наилучшего метода резервирования подключенных узлов. Типы резервного копирования, зависящие от сетевой инфраструктуры (резервирование DAS, NAS, SAN, не зависящее от локальной сети и от сервера) рассматриваются в разделах 5.3.3.1–5.3.3.4.
Эта старейшая разновидность резервного копирования возникла- во времена, когда устройства хранения подключались непосредственно к серверу. Несмотря на развитие сетевых устройств хранения, резервирование DAS остается достаточно популярным для копирования данных, размещенных на серверах Windows. Схема резервирования DAS представлена на рис. 5.3. / Преимуществом резервирования DAS является простота его использования. Приложение на сервере считывает данные с соответствующего дйсково- го тома и записывает их на магнитную ленту. Однако резервирование DAS имеет ряд недостатков.
Использование нескольких накопителей на магнитной ленте (по одному на каждый сервер, нуждающийся в резервном копировании), что требует существенных финансовых затрат. Другими словами, совместное использование одного накопителя несколькими серверами практически невозможно.
Высокая общая стоимость владения (ТСО), так как для резервного копирования с помощью нескольких накопителей на магнитной ленте требуется иметь в штате несколько администраторов.
Хранение нескольких лент может привести к путанице.
Поскольку данные на нескольких серверах часто дублируются, но не синхронизированы, одинаковые данные переносятся и на ленту, поэтому хранение похожих данных на нескольких лентах может привести к путанице.
Рис. 5.3. Резервирование DAS
Наконец, но не в последнюю очередь, сервер должен обрабатывать запросы чтения/записи данных между диском и накопителем на магнитной ленте.
Как отмечалось в главе 3, эра хранилищ DAS закончилась с появлением систем типа клиент/сервер, когда клиенты и серверы стали совместно использовать ресурсы локальной сети. Это позволило сформировать архитектуру, в которой к накопителю на магнитной ленте, подключенному к серверу, получают доступ несколько сетевых серверов.
На рис. 5.4 показан типичный сценарий резервирования NAS. В левой области диаграммы указано несколько серверов. Это могут быть серверы приложений или файловые серверы и серверы печати. В правой области находится сервер резервного копирования и подключенный к нему накопитель на магнитной ленте. Этот накопитель может использоваться для резервного копирования информации с нескольких серверов приложений, файловых серверов и серверов печати. Таким образом, резервирование NAS позволяет совместно использовать накопитель на магнитной ленте для резервного копирования данных нескольких серверов, что приводит к снижению общих затрат.
Резервированию NAS свойственны некоторые недостатки.
Операция резервного копирования отражается на пропускной способности локальной сети, что зачастую требует сегментации LAN для перенаправления потоков резервного копирования в отдельный сетевой сегмент.
Время работы узлов увеличивается. Другими словами, возрастает время, в течение которого серверы должны быть доступны для обслуживания пользовательских запросов и транзакций. Кроме того, увеличивается объем данных, хранящихся на сервере, что требует большего времени на резервирование этих данных.
Рис. 5.4. Схема резервирования NAS
Учитывая актуальность описанных проблем, обеспечение эффективности резервного копирования становится единственным критерием при проектировании сетей и определении точного количества необходимых устройств резервирования.
Развитие сетей хранения данных привело к появлению новых концепций резервного копирования. Новые возможности основаны та том, что сеть хранения данных может обеспечить достаточную пропускную способность между любыми двумя устройствами и, в зависимости от топологии, способна предоставить одновременную связь с малыми задержками между несколькими парами устройств. С другой стороны, использование топологии кольца Fibre Channel с количеством устройств больше 30 не дает возможности создавать несколько соединений с высокой пропускной способностью и малыми задержками, так как общая пропускная способность кольца будет совместно разделена между всеми подключенными устройствами.
На рис. 5.5 представлена архитектура типичного приложения SAN для резервного копирования. Обратите внимание на мост Fibre Channel. Большинство накопителей на магнитной ленте не поддерживают интерфейс Fibre Channel (они используют параллельный интерфейс SCSI), поэтому для подключения таких устройств понадобится мост. На рис. 5.5 серверы Windows NT подключены одновременно к локальной сети и к сети хранения данных.
Топология резервного копирования (см. рис. 5.5) имеет ряд преимуществ.
■ Накопитель на магнитной ленте может находиться довольно далеко от сервера, данные которого резервируются. Такие накопители обычно оснащены интерфейсом SCSI, хотя в последнее время всё чаще появляются накопители с интерфейсом Fibre Channel. Это означает, что их можно подключать только к одной шине SCSI, в результате чего усложняется совместное использование накопителя несколькими серверами. Сети хранения данных на основе Fibre Channel благодаря поддержке различных устройств позволяют успешно решать проблемы совместного использования. Обратите внимание: при этом все равно требуется метод, обеспечивающий корректный доступ к накопителю на магнитной ленте с использованием соответствующих разрешений. Примеры подобных методов представлены ниже.
Рис. 5.5. Резервное копирование средствами сети хр&нения данных
Метод зонирования позволяет в определенный момент времени получить доступ к накопителю на магнитной ленте одному серверу. Проблема заключается в обеспечении соответствия серверов требованиям зонирования. Кроме того, необходимо обеспечить корректное использование сменщика лент или накопителя с поддержкой нескольких кассет.
Следующий метод – использование таких команд интерфейса SCSI, как Reserve и Release.
Метод подключения накопителя на магнитной ленте к серверу позволяет получить совместный доступ к устройству посредством специального программного обеспечения сервера. Совместное использование накопителя на магнитной ленте является весьма привлекательным решением, поскольку накопители – довольно дорогие устройства. К описанным накопителям относится, например, устройство Tivoli от компании IBM.
■ Технология резервного копирования без локальной сети получила свое название потому, что передача данных выполняется за пределами локальной сети средствами SAN. Это снижает нагрузку на локальную сеть, благодаря чему приложения не страдают от снижения пропускной способности сети при резервировании данных.
Резервное копирование без локальной сети позволяет более эффективно использовать ресурсы с помощью совместного использования накопителей на магнитной ленте.
Резервное копирование и восстановление данных без локальной сети более устойчиво к ошибкам, поскольку резервирование может проводиться несколькими устройствами одновременно, если одно устройство отказало в работе. Аналогичным образом несколько устройств могут использоваться при восстановлении данных, что позволяет эффективнее планировать использование ресурсов.
Наконец, операции резервного копирования и восстановления завершаются значительно быстрее, так как сети хранения данных обеспечивают более высокую скорость передачи данных.
Такое резервное копирование иногда называют резервным копированием без сервера или даже сторонним копированием. Обратите внимание, что резервное копирование, не зависящее от сервера, обычно представляет собой резервирование, не зависящее от локальной сети, что избавляет от необходимости перемещать данные с определенного узла. Идея такого способа резервного копирования состоит в применении команды SCSI Extended Copy.
В основе резервного копирования, не зависящего от сервера, лежит инициатива ассоциации SNIA, которая была реализована в командах SCSI Extended Сору, утвержденных комитетом INCITS, а точнее, техническим подкомитетом Т10 (документ ANSI INCITS.351:2001, SCSI Primary Commands-2). Обратите внимание: в стандарте SCSI уже описывалась поддержка команд копирования, однако ранее для использования команд требовалось подключение всех устройств SCSI к одной шине (с тех пор команда Сору считается устаревшей; более подробная информация представлена на Web-узле http: //www.110. org). Команда Extended Copy добавляет такие дополнительные возможности, как использование источника и пункта назначения данных через различные шины SCSI. При этом в полной мере сохраняется адресация, поддерживаемая синтаксисом команды.
В резервном копировании, не зависящем от сервера, сервер резервирования может обрабатывать другие запросы, пока данные копируются с помощью агента перемещения данных. Данные переносятся непосредственно от источника данных в точку назначения, а именно в резервный носитель (вместо копирования из источника на сервер резервного копирования с последующим переносом на резервный носитель).
Рис. 5.6. Резервное копирование, не зависящее от сервера
Осознавая преимущества резервного копирования, не зависящего от сервера, не следует забывать, что восстановление данных представляет собой совершенно другую проблему. Операции восстановления, не зависящие от сервера, остаются крайне редким явлением. Резервные копии, созданные с помощью этой технологии, очень часто восстанавливаются традиционными методами, в которых подразумевается использование сервера с неким программным обеспечением для резервного копирования и восстановления данных.
Принцип резервного копирования, не зависящего от сервера, демонстрируется на рис. 5.6. Для упрощения схемы на рисунке показано минимальное количество компонентов, необходимых для иллюстрации резервного копирования. На практике сети хранения данных имеют более сложную структуру. На рис. 5.6 показан сервер под управлением Windows, подключенный к коммутатору Fibre Channel с помощью адаптера шины Fibre Channel. Кроме того, используется маршрутизатор Fibre Channel-K-SCSI, к которому подключается накопитель на магнитной ленте с интерфейсом SCSI и дисковые устройства. Дисковые и ленточные устройства не обязательно должны подключаться к одному маршрутизатору.
Приложение сервера резервного копирования на сервере Windows находит агента перемещения данных на маршрутизаторе с помощью технологии Plug and Play. Приложение резервного копирования определяет дополнительную информацию о резервировании (идентификатор дискового устройства, начальный логический блок, объем копируемых данных и т.д.). Программное обеспечение сервера резервирования изначально передает последовательность команд накопителю на магнитной ленте для резервирования устройства и монтирования необходимого носителя. Далее программное обеспечение сервера резервного копирования передает команду Extended Сору агенту перемещения данных, который выполняется на маршрутизаторе. Агент координирует перенос необходимых данных. По завершении копирования агент возвращает сервисную информацию программе резервирования, выполняемой на сервере Windows.
В процессе резервного копирования, не зависящего от сервера, важную роль играют несколько компонентов, включая источник и точку назначения данных, агент перемещения и сервер резервного копирования.
Источник данных – это устройство, содержащее данные, для которых необходимо создать резервную копию. Обычно выполняется резервное копирование целого тома или дискового раздела. К источнику данных должен получать доступ непосредственно агент перемещения данных (о нем идет речь несколько ниже). Это означает, что устройства хранения, подключенные к серверу, не могут быть источниками данных для резервного копирования, не зависящего от сервера, так как прямая адресация вне сервера невозможна.
Точка назначения данных обычно представляет собой накопитель на магнитной ленте, на который записываются данные. В качестве устройства может выступать диск, если резервное копирование выполняется на диск, а не на ленту. Ленточные устройства обычно подключены к порту связной архитектуры, чтобы избежать повреждения данных, передаваемых на ленту, в случае отказа других частей сети хранения данных. Например, если накопитель на магнитной ленте подключен к кольцу Fibre Channel с разделением доступа, ошибка в работе другого устройства или подключение/отключение устройства от кольца может привести к остановке записи данных и повторной инициализации кольца, что нарушит целостность данных, записываемых на ленту.
Агент перемещения данных обычно встраивается в маршрутизатор с помощью прошивки, так как он должен обрабатывать команду SCSI Extended Сору, которая отправляется маршрутизатору в виде пакета Fibre Channel. Коммутаторы и концентраторы, обрабатывающие только заголовок кадра Fibre Channel, не совсем подходят для поддержки работы агента перемещения данных, однако в будущем это может измениться.
Агент перемещения данных активизируется после получения инструкций от сервера резервного копирования. Большинство накопителей на магнитной ленте, подключенных к SAN, представляют собой устройства SCSI. Поэтому требуется наличие маршрутизатора, который поддерживает преобразование пакетов между интерфейсами Fibre Channel и SCSI. На данный момент все чаще появляются накопители на магнитной ленте с интерфейсом Fibre Channel, а некоторые компании, например Exabyte, предоставляют прошивки для подобных накопителей, добавляющие функции агента перемещения данных. Кроме того, базовые библиотеки накопителей на магнитной ленте с интерфейсом Fibre Channel обычно имеют встроенные маршрутизаторы Fibre Channel-SCSI, что позволяет библиотеке использовать собственный агент перемещения данных. Обратите внимание, что агент может быть реализован в программном обеспечении младшей рабочей станции или даже сервера. Компании Crossroads, Pathlight (теперь ADIC) и Chaparral предоставляют маршрутизаторы со встроенными в прошивку агентами перемещения данных. Сеть хранения данных может иметь несколько агентов от нескольких производителей, что не мешает агентам сосуществовать в одной сети.
Конечно, для того чтобы агент перемещения данных можно было использовать, его нужно найти (с помощью команды SCSI Report LUNs) и обеспечить должную адресацию (посредством имени WWN) с сервера резервного копирования. Кроме того, агент может проводить два резервных копирования одновременно. Например, один сеанс копирования может проводиться на географически удаленный зеркальный ресурс, однако для этого сервер резервирования должен передать две команды.
Сервер резервного копирования отвечает за все команды и управление операциями. Перечислим еще раз все основные обязанности сервера резервирования.
Программное обеспечение сервера обеспечивает доступность накопителя на магнитной ленте, применяя соответствующие команды SCSI Reserve и Release.
Монтирование носителя для резервного копирования.
Определение точного адреса источника данных и размещения данных в логических блоках, а также объема данных для резервирования.
Получив всю необходимую информацию, сервер отправляет команду Extended Сору агенту перемещения данных. Затем агент отправляет последовательность команд Read источнику данных и записывает информацию в точке назначения.
Компании Computer Associates, CommVault, LEGATO и VERITAS предоставляют программы для резервирования, не зависящего от сервера. Поставщики маршрутизаторов с функциями резервного копирования, не зависящего от сервера, постоянно сотрудничают с компаниями – разработчиками программного обеспечения, чтобы сделать возможной совместимость своих продуктов. Дело в том, что для поддержки базовых команд SCSI Extended Copy производителями применяются различные команды.
Обратите внимание: несмотря на достаточно зрелый возраст технологии резервирования, не зависящей от сервера, поддержка восстановления, не зависящего от сервера, со стороны производителей крайне ограниченна.
В многочисленных рекламных материалах и маркетинговой литературе утверждается, что конкретный метод внедрения технологии резервного копирования, не зависящего от'сервера, совместим с Windows 2000. Рассмотрим эту концепцию более подробно. Далее описывается каждый из четырех компонентов, формирующих резервирование, не зависящее от сервера: источник данных, точка назначения данных, программное обеспечение сервера резервирования и агент перемещения данных.
В большинстве случаев агент перемещения данных, работающий вне сервера Windows NT, не может адресовать данные, хранящиеся на сервере Windows NT. Адаптеры шины, подключенные к серверу Windows NT, обычно работают, как инициаторы и не отвечают на команды Report LUNs. Если сервер Windows NT использует устройство хранения за пределами сервера, например массив RAID, подключенный к коммутатору Fibre Channel, то это устройство будет доступно агенту перемещения. Поэтому вместо утверждений о том, что устройство хранения, используемое Windows NT, не может быть источником данных для резервирования, не зависящего от сервера, следует уточнить, что источником данных не может быть устройство хранения, которое является внутренним для сервера Windows NT.
Использование внутреннего хранилища Windows NT в качестве точки назначения данных также невозможно, так как точка назначения тоже должна быть доступна агенту перемещения данных для адресаций.
Выполнение программы резервирования на компьютере под управлением Windows представляет собой неплохой вариант. Адаптер шины, подключенный к серверу Windows, может выдать последовательность команд Report LUNs каждому устройству (LUN 0), которое будет обнаружено. Затем программа резервирования просматривает все видимые устройства и логические единицы, после чего выясняет, какие из них могут выступать в роли агента стороннего копирования. Некоторые программы сообщают о дополнительных LUN, которые необходимы при выдаче команд Extended Сору. Множество программ резервирования, которые используют дополнительные LUN, проходят через процесс обнаружения устройств для проверки функций агента перемещения данных.
Промежуточный интерфейс SCSI (IOCTL) в Windows NT может использоваться для передачи команды Extended Сору агенту перемещения данных (команда передается с сервера резервного копирования под управлением Windows NT). Операционная система Windows NT не имеет встроенной поддержки агентов перемещения; технология Plug dnd Play позволяет обнаружить агент, но для регистрации последнего в системном реестре необходимы дополнительные драйверы.
Остается последний вопрос: можно ли запустить программное обеспечение агента перемещения данных на сервере или рабочей станции под управлением Windows NT? Одним из преимуществ такого решения является то, что агент перемещения сможет адресовать устройства хранения, «видимые» для сервера Windows, а также получать к ним доступ. Но сервер резервного копирования, размещенный вне Windows NT, не сможет обнаружить устройства хранения, подключенные к компьютеру с агентом перемещения данных. Агент должен иметь возможность работать в качестве инициатора и целевого устройства для команд SCSI. Поскольку адаптер шины, подключенный к компьютеру под управлением Windows NT, редко выполняет роль целевого устройства, команда Extended Сору может не дойти до агента перемещения данных.
Обратите внимание: в Windows NT для выдачи команд SCSI приложения используют промежуточный интерфейс (DeviceloControl с параметром IoControlCode, равным IOCTOL_SCSI_PASS__THROUGH или IOCTL_SCSI_PASS_ THROUGH_DIRECT).
5.4 Утилита резервного копирования Windows 2000
В составе Windows 2000 поставляется программа резервного копирования, которая на самом деле представляет собой облегченную версию программы VERITAS Backup Exec. Встроенная утилита резервного копирования интегрирована с другими компонентами операционной системы, например с шифрованной файловой системой и интерфейсом управления иерархическим хранилищем. Утилита резервного копирования поддерживает резервное копирование и восстановление EFS в Windows 2000. Более подробная информация представлена в главе 6. Кроме того, утилита поддерживает работу с менеджером RSM – Removable Storage Manager (см. главу 7). Менеджер предоставляет поддержку операций, необходимых для резервного копирования:
инвентаризацию носителей, загруженных в библиотеку ленточных библиотек;
загрузку и извлечение носителей из ленточных библиотек;
предоставление безопасного доступа и обеспечение целостности данных на смонтированном носителе;
выполнение обслуживающих функций для управления носителями и ленточной библиотекой, например очистка ленточного привода или библиотеки носителей.
Полнофункциональные утилиты резервного копирования предоставляют возможности, которые не поддерживаются описываемой утилитой Windows 2000. Вот некоторые из этих возможностей:
агенты резервного копирования для приложений уровня предприятия, например серверов SQL и IIS;
поддержка резервного копирования открытых файлов;
повышенное быстродействие;
централизованное управление, включая централизованную базу данных с каталогом и управляющим программным обеспечением для всех устройств и каталогов резервного копирования;
поддержка команды Extended Сору и агентов перемещения данных других поставщиков.
Обратите внимание, что утилита резервного копирования в Windows Server 2003 поддерживает копирование открытых файлов, так как резервирование выполняется на основе моментальных снимков.
5.5 Технологии создания моментальных снимков тома
Моментальный снимок (snapshot) – это целостная копия состояния тома в определенный момент времени. Под целостностью в данном случае подразумевается возможность для приложений обработать данные, хранящиеся в снимке; например, сервер Microsoft Exchange воспринимает данные как действительное хранилище Exchange, а сервер Microsoft SQL – как реальную базу данных SQL. Рассматриваемый в этом случае набор данных в дальнейшем будет именоваться логическим томом.
Моментальные снимки набирают популярность и используются по ряду различных причин.
Резервное копирование клонированного тома, созданного с помощью технологии моментального снимка, в то время пока основной том используется приложениями. Именно для этого компания Microsoft создала службу теневого копирования томов в Windows ХР. Служба (в определенный момент времени) используется для создания образа оригинального тома (при наличии свободного дискового пространства). Этот образ применяется затем для операций резервного копирования.
Создание образа активных данных, в котором поддерживается поиск.
Создание образа активных данных для тестирования новой версии приложения в «реальном» окружении.
Создание образа активных данных для последующего восстановления системы после сбоев в работе.
Как же создается моментальный снимок тома? Для этого существует несколько способов, каждый из которых представляет собой вариант дублирования операций записи. Единственное отличие между ними состоит в том, где именно проводится дублирование. Существует четыре возможных уровня.
Уровень аппаратного обеспечения. Первый очевидный способ создания моментального снимка тома заключается в зеркальном отражении тома на уровне аппаратного обеспечения с последующим разделением зеркала. При использовании простого аппаратного обеспечения и программных томов, каждая операция записи преобразуется в две операции: для оригинального тома и для зеркала. Этот подход требует большого объема ресурсов, так как обе операции записи должны быть завершены до отправки результата записи. Кроме того, необходимо обеспечить обработку ошибок записи. Преимуществом такого подхода, несмотря на требовательность к ресурсам, является значительная скорость разбития зеркала для создания моментального снимка тома. Высокая скорость и надежность зеркального отражения с помощью аппаратного обеспечения связана с определенными накладными расходами: основную часть составляет стоимость жестких дисков для дублирования записи. При использовании дорогих подсистем хранения для каждой дорожки хранится большой объем метаданных, так как вместо разделения самих записей, после разбивки зеркала записи отслеживаются через метаданные. Более того, дорогие подсистемы хранения не задерживают зеркальные записи, так как записи считаются завершенными, как только необходимые данные попадают в кэш подсистемы хранения.
Уровень над файловой системой. Второй способ создания моментального снимка тома в операционных системах семейства Windows Server заключается в создании драйвера фильтрации файловой системы, который размещен над драйвером файловой системы, например NTFS или FAT. Драйвер фильтрации файловой системы дублирует каждый пакет IRP (пакет запроса ввода-вывода), который передается драйверу файловой системы. Этот процесс довольно сложен и не может использовать преимущества технологии моментальных снимков, которая предоставляется аппаратным обеспечением. В качестве примера программ, внедряющих фильтры над NTFS, можно указать Open File Manager компании St. Bernard, Vinca (теперь LEGATO) Open File Manager и Open File Agent компании Cheyenne. Обратите внимание, что не каждая программа поддерживает технологию моментальных снимков.
Рис. 5.7. Моментальные снимки по методу копирования при записи
Уровень непосредственно файловой системы. Переместившись ниже по стеку драйверов, можно реализовать третий способ создания моментальных снимков на уровне файловой системы, такой, как WAFL (Write Anywhere File Layout) и Linux SnapFS. Очевидно, что в данном случае речь не идет о Windows NT. Создание файловой системы – достаточно сложный процесс, а создание технологии моментальных снимков на уровне файловой системы еще больше его усложняет. В результате файловые системы, реализованные в Windows NT, не поддерживают моментальных снимков.
Уровень ниже файловой системы. Четвертый способ – использование драйвера фильтрации ниже файловой системы для реализации технологии копирования при записи. Основная идея состоит в том, чтобы логические блоки, в которые приложение вносит изменения, сначала записывались во вторичное хранилище и только потом – на жесткие диски. Этот принцип демонстрируется на рис. 5.7. Описываемая технология также называется дифференциальным моментальным снимком, поскольку сохраняются только измененные файлы (полное зеркальное отражение тома не проводится).
5.6 Служба теневого копирования томов в Windows ХР и Windows Server 2003
В Windows ХР и Windows Server 2003 компания Microsoft реализовала службу теневого копирования. Таким образом, предоставляется инфраструктура, позволяющая создавать целостные копии дисковых томов в заранее определенный момент времени. По юридическим причинам Microsoft решила назвать эту технологию теневым копированием томов (volume shadow copy), что на самом деле не отличается от более популярного термина – моментальные снимки. Служба теневого копирования томов реализована в драйвере, который называется volsnap. sys и находится ниже уровня файловой системы.
Компания Microsoft предоставляет инструментарий разработки программного обеспечения для теневого копирования томов, реализуемый на базе договора о неразглашении. Набор SDK в основном предназначен для представителей трех обширных аудиторий.
Независимые поставщики программного обеспечения, предназначенного для теневого копирования томов, включая Microsoft Exchange, SQL Server, Oracle, SAP, Sybase и др.
Независимые поставщики программного обеспечения, разрабатывающие приложения резервного копирования и управления подсистемами хранения. Такие поставщики могут создавать программное обеспечение для отправки запросов службе теневого копирования томов.
Независимые поставщики программного и аппаратного обеспечения, предназначенного для резервного копирования, восстановления после ошибок и обеспечения целостности данных. В качестве примера можно привести компании VERITAS, EMC и их конкурентов в этой отрасли. Такие поставщики разрабатывают программное обеспечение для предоставления моментальных снимков.
Если приложение не имеет кода, поддерживающего службу моментальных снимков, данные приложения все равно будут скопированы с сохранением целостности, как в том Случае, если файловая система не может штатным образом завершить свою работу. Если приложение содержит код для поддержки службы моментальных снимков, от приложения ожидается поддержка службы и в операциях восстановления данных. Приложение выдает некоторые данные (например, какие файлы необходимо копировать, а также методологию резервного копирования и восстановления) при запросе резервного копирования. От приложения также ожидается обработка этих данных, когда потребуется операция восстановления.
Рис. 5.8. Архитектура теневого копирования томов
Резервное копирование и восстановление данных, реализованное в операционных системах Windows, не всегда работает со стопроцентной надежностью. Новая служба моментальных снимков позволяет достичь максимальной надежности, поддерживая более сложные сценарии, которые до этого момента были недоступны в Windows.
Архитектура теневого копирования томов в Windows ХР и Windows Server 2003 включает в себя четыре типа модулей (рис. 5.8).
Модули записи.
Модули запроса.
Служба теневого копирования томов.
Поставщики.
Эти модули подробно рассматриваются в разделах 5.6.1–5.6.4.
В контексте различных модулей, формирующих службу моментальных снимков, второй поставщик моментальных снимков снабжен компонентом для режима ядра, который отсутствует у первого поставщика. Служба поставщика моментальных снимков на рис. 5.8 выделена серым цветом, что подчеркивает предоставление компанией Microsoft функции, которую остальные поставщики программного обеспечения не пожелали предоставлять в виде службы. Кроме того, Microsoft предлагает и другие компоненты, но их функциональность ограничена определенным приложением или набором опреде-
ленных функций; таким образом, от поставщиков ожидается создание компонентов средствами SDK.
Модули записи и поставщики должны внедрить отдельного внепроцесс- ного поставщика СОМ, как описано в SDK[9], для теневого копирования томов. Поставщики обычно реализуются в виде «конечного автомата». Автомат переходит из одного состояния в другое при получении события, сгенерированного службой теневого копирования. Поставщик получит событие (сгенерированное службой теневого копирования), однако тип события зависит от текущего статуса поставщика и от наличия ошибок в работе. Другими словами, поставщик ожидает получения предпочтительного события, которое позволит ему перейти в следующее нормальное состояние. В случае ошибки поставщик получит событие, которое отличается от ожидаемого. Тем не менее такое событие также может быть обработано поставщиком.
Инфраструктура теневого копирования в Windows ХР и Windows Server 2003 предоставляет базовые функции, необходимые для управления подсистемой хранения данных, включая следующие:
определение момента времени, в который должен создаваться моментальный снимок;
предоставление служб синхронизации для приложений, баз данных, операционных систем и файловых систем для чистки кэшированных данных, приостановки записи, создания моментальных снимков и предоставления уведомлений приложениям, базам данных и элементам операционных систем о возможности продолжения нормального режима работы;
предоставление. единого API, который может использоваться во время операций резервного копирования и восстановления;
предоставление общей платформы для управления моментальными снимками.
Инфраструктура теневого копирования Microsoft поддерживает обработку набора томов, для которых моментальный снимок должен быть сделан как для одного тома. Если одна операция завершится неудачно, неудача постигнет и все другие операции. Кроме того, инфраструктура теневого копирования Microsoft выдает запрос (поставщику моментального снимка) на удаление моментального снимка, когда запрашивающее приложение завершило его обработку. Если необходимо, чтобы моментальный снимок оставался доступным для последующего использования, поставщик моментальных снимков или запрашивающее приложение должны предоставить необходимые функции. Независимые поставщики программного обеспечения разрабатывают приложения, которые на основе архитектуры теневого копирования создают и каталогизируют несколько моментальных снимков, а также управляют ими; такие программы не поставляются в комплекте с Windows Server 2003.
Модули записи моментальных снимков представляют собой приложения, которые записывают данные. К модулям записи относятся программы Microsoft Exchange, Microsoft SQL Server 2000, SAP и Oracle. Компания Microsoft и независимые поставщики программного обеспечения разрабатывают системы, поддерживающие запись моментальных снимков. При этом модули записи моментальных снимков должны быть реализованы с помощью набора SDK. В частности, модули записи получают от службы моментальных снимков два события, в результате чего приложения прекращают запись данных на диск, а также отдельное событие, позволяющее продолжить запись (это событие указывает на успешное создание моментального снимка). Существуют и другие события, которые может генерировать служба создания моментальных снимков. Дополнительная информация об этих событиях доступна в наборе SDK. Так как приложения могут определять целостность получаемых данных, операции сохранения должны проводиться достаточно быстро.
Необходимо также отметить одно важное преимущество архитектуры службы теневого копирования томов по сравнению с традиционными механизмами создания моментальных снимков, основанными на аппаратных решениях. При использовании в Windows 2000 и более ранних версиях традиционных механизмов аппаратное обеспечение не имело возможности «узнать» состояние приложений, программного обеспечения операционной системы и содержимого кэша. Это означает, что целостность заметного процента моментальных снимков нарушена. Более того, единственным способом определения целостности моментального снимка был запуск проверки целостности в конкретном приложении, на что уходило несколько часов.
В то же время при использовании архитектуры теневого копирования томов можно не только аннулировать содержимое кэша и приостановить one- рации записи, но и проверить целостность снимка за несколько минут. Как только приложениям выдается событие продолжения записи, служба теневого копирования томов запрашивает у приложений сведения об успешной задержке записи между событиями остановки и продолжения записи. Если один из модулей записи не смог остановить запись данных на диск после прихода соответствующего события, создание моментального снимка можно считать неудачным.
От модулей записи моментальных снимков ожидаются данные, необходимые для резервного копирования и восстановления. К ним относятся, например, список файлов, которые требуется скопировать или исключить из процесса копирования, а также группа объектов, которые должны обрабатываться в виде единого набора. Такие данные сохраняются службой создания моментальных снимков в документе метаданных модуля записи, который имеет формат XML. Модули записи могут использовать документ для хранения других необходимых данных. При восстановлении данных приложение предоставляет набор данных записавшему приложению, которое и проводит операцию восстановления.
Компания Microsoft объявила, что будет предоставлять модули записи для программ SQL Server 2000 и Exchange, а также других компонентов Windows Server. Компания сотрудничает с независимыми поставщиками программного обеспечения для разработки модулей записи к другим приложениям, включая службу каталогов Active Directory.
Обычно модуль запроса – это приложение резервного копирования, которое запрашивает создание моментального снимка с помощью соответствующего вызова API, направленного к службе теневого копирования томов от Microsoft. Такая модель значительно упрощает решение некоторых проблем для создателя программы резервного копирования. Программе более не придется решать сложную задачу поиска копируемых данных или определять файлы журналов приложений, которым требуется специальная обработка.
Соответствующий модуль записи (например, Microsoft SQL Server) отвечает за создание набора файлов, которые будут включены в резервную копию. Операция восстановления также намного упрощается, поскольку приложение восстановления не должно искать данные и определять, какие файлы передавать API приложения (например, Exchange или SQL). Приложение передает набор данных модулю записи (приложению) и предоставляет ему возможность выполнить операцию восстановления.
Созданная компанией Microsoft служба теневого копирования томов Windows NT координирует деятельность всех компонентов создания моментальных снимков. В частности, служба предоставляет описанные ниже возможности.
Единый интерфейс для приложений резервного копирования или модулей запроса создания моментальных снимков. Ранее приложения резервного копирования должны были работать с несколькими API от нескольких приложений.
Единый интерфейс для создания, управления и удаления целостных моментальных снимков томов или теневых томов.
Единый интерфейс, который позволяет различным приложениям и поставщикам моментальных снимков регистрироваться и удалять регистрацию модулей записи и поставщиков моментальных снимков.
Синхронизация и координация различных компонентов для создания, удаления и перемещения моментальных снимков, а также для резервного копирования и восстановления. Служба расставляет приоритеты поставщиков моментальных снимков таким образом: аппаратные поставщики имеют наивысший приоритет, затем идут программные поставщики, а самым низким приоритетом обладают поставщики, которые по умолчанию предоставляются Microsoft.
Независимые поставщики программного обеспечения могут не беспокоиться о необходимости создания службы теневого копирования томов. Службу, предоставленную компанией Microsoft, можно воспринимать, как планировщик печати (spooler). На компьютере должен быть один планировщик печати. Некоторые производители (например, создатели поставщиков) должны написать эквивалент драйвера печати, в то время как остальным достаточно создать приложение печати.
Поставщики моментальных снимков должны разрабатываться независимыми компаниями для создания, удаления и управления моментальными снимками. Как отмечалось ранее в главе, поставщики моментальных снимков должны быть созданы в виде внепроцессных поставщиков СОМ средствами соответствующего набора SDK.
Поставщик может иметь компонент, работающий в режиме ядра, например драйвер фильтрации, который расположен между файловой системой и диспетчером логических дисков (logical disk manager – LDM). При необходимости функции режима ядра могут быть реализованы в аппаратном обеспечении. Обратите внимание, что даже аппаратный поставщик будет использовать остальные возможности инфраструктуры, например определение временной точки, синхронизацию ввода-вывода и платформу для создания приложений управления подсистемой хранения, включая резервное копирование/восстановление данных и приложения управления моментальными снимками.
Одним из примеров поставщика моментальных снимков служит драйвер volsnap. sys, который предоставляется в Windows ХР и ожидается в Windows Server 2003. Этот поставщик использует технологию копирования при записи для создания минимального необходимого набора данных во вторичном хранилище, чтобы воссоздать том с определенной временной точки. При этом должен быть доступен достаточный объем свободного дискового пространства. Поставщик может обрабатывать тома NTFS, FAT32 и тома без файловой системы в Windows Server 2003. Однако поставщик может создавать моментальные снимки, предназначенные только для чтения, и для каждого тома создается только один моментальный снимок. Это ограничение самого поставщика, а не инфраструктуры, на базе которой он создан. Независимые производители программного и аппаратного обеспечения при желании могут предоставлять более широкие возможности.
Полное описание всех событий, которые получает поставщик моментальных снимков, приводится в документации SDK. Далее рассматривается два наиболее важных события.
PreCommitSnapshot. При получении этого события поставщик должен начать выполнение всех операций ввода-вывода, которые занимают довольно много времени, например синхронизацию зеркала.
Commit Snapshot. С получением этого события поставщик уведомляется о том, что служба моментальных снимков завершит работу через 10 секунд. Таким образом, быстродействие поставщика должно быть достаточно высоким. Более того, пока создание моментального снимка не будет завершено, Windows NT не будет выполнять операции записи на том, для которого создается моментальный снимок. Это значит, что поставщик не должен выполнять операции ввода-вывода с этим томом, а если такая операция выполнена, то она не должна завершаться до тех пор, пока создание моментального снимка не будет завершено или прервано.
Поставщики моментальных снимков должны предоставлять определенные функции, а также возможности, выходящие за рамки обязательных. Ниже описаны обязательные функции.
Поставщики отвечают за поиск хранилища, необходимого для создания моментального снимка. Инфраструктура Microsoft не обеспечивает подобной возможности.
Поставщик должен монтировать моментальный снимок в другом пространстве имен й не в виде отдельного тома. Внимательно рассмотрев архитектуру Windows ХР, можно отметить, что поставщик моментальных снимков от компании Microsoft монтирует их с использованием адреса \Device\HarddiskSnapshotX.
Хотя модификации подсистемы ввода-вывода Windows NT не обязательно относятся к окружению моментальных снимков, следует обратить внимание, что для создания целостных и надежных моментальных снимков в определенный момент времени требуются значительные доработки файловой системы, стека ввода-вывода и драйверов фильтрации файловой системы. В частности, компания Microsoft добавила два вызова управления вводом: выводом (IOCTL), которые должны быть реализованы во всех файловых системах и драйверах фильтрации файловых систем.
Вызов IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES, который должен входить в последовательность и обрабатываться. Включение в последовательность позволяет обрабатывать вызов драйверам более низкого уровня. Обработка заключается в очистке и удержании всех метаданных файловой системы. Как только все данные будут сброшены, до завершения работы пакетов IRP, предназначенных для аннулирования данных и метаданных, другие запросы на запись выдаваться не должны.
Вызов IOCTL_VOLSNAP_RELEASE_WRITES также должен обрабатываться и включаться в последовательность. Этот вызов указывает на успешное завершение создания моментального снимка или. на прерывание операции создания моментального снимка.
Некоторые компоненты Windows NT также были модифицированы для вызова указанных IOCTL в соответствующие моменты времени. Хотя компания Microsoft уже модифицировала файловую систему и драйвер фильтрации файловой системы для предоставления соответствующей функции, от драйверов фильтрации независимых производителей^ программного обеспечения ожидается то же самое.
В разделе 5.8 рассматривается промышленный стандарт NDMP (Network Data Management Protocol – сетевой протокол управления данными). Но перед обсуждением этой темы следует рассмотреть взаимосвязь между службой теневого копирования томов Windows ХР/Windows Server 2003 и протоколом NDMP. Служба теневого копирования используется для клонирования данных, которые необходимо скопировать на резервный носитель, в то время как NDMP применяется для переноса данных с клонированного образа на магнитную ленту или другой резервный носитель.
5.7 Устройства NAS под управлением Windows и моментальные снимки
Компания Microsoft предоставляет версию Windows NT, которую иногда называют Embedded NT (встроенная NT), однако обычно она известна как Server Appliance Kit, или SAK. Эта система основана на ядре Windows 2000, которая не содержит службы теневого копирования томов. Для производителей аппаратного обеспечения, использующих SAK при разработке устройств NAS, компания Microsoft лицензировала технологию создания моментальных снимков и добавила ее в SAK. В последнем случае для создания моментальных снимков используется технология PSM (Persistent Storage Management) от компании Columbia Data Products. В этом разделе приводится краткое описание архитектуры и функций PSM.
Архитектура PSM представлена на рис. 5.9. Модуль PSM включает в себя компонент пользовательского режима, который обеспечивает управление моментальными снимками, включая запуск и планирование снимка. Моментальные снимки создаются с помощью драйверов фильтрации PSM, которые расположены над драйвером класса диска.
Архитектура PSM предоставляет возможность создания нескольких моментальных снимков, а также средства для их управления. Моментальные снимки можно создавать по расписанию, а более старые снимки могут быть сохранены или перезаписаны. Кроме того, старые снимки можно монтировать для использования при резервном копировании или для других целей. С каждым моментальным снимком связана информация о дате и временной отметке.
5.8 Протокол NDMP
В основе протокола NDMP лежит инициатива компаний Network Appliance и Intelliguard (теперь подразделение компании LEGATO). Он предназначался для предоставления дополнительных возможностей приложениям резервного копирования и восстановления данных, а именно:
■ возможность сократить или, как минимум, изолировать зависящие от операционной системы элементы программного обеспечения для резервного копирования и восстановления; функции приложений предлагалось разделить на модульной основе;
Рис. 5.9. Архитектура Persistent Storage Manager
стандартизированные способы связи между модулями;
возможность разделить перенос данных и команд на отдельные каналы или даже сети;
интеграция программного обеспечения от разных производителей.
На данный момент NDMP позиционируется как открытый стандарт для выполнения операций резервного копирования и восстановления в среде NAS. Протокол постоянно развивается и в будущем может обеспечить преобразование копируемых данных стороннего ресурса в данные протокола NDMP.
Протокол NDMP может использоваться в различных сетевых средах, например Ethernet, Gigabit Ethernet, Fibre Channel. Главным условием является использование IP (Internet Protocol) в качестве транспортного протокола. Сервер NDMP и агенты используют протокол IP, а сервер NDMP выдает необходимые команды SCSI блочного уровня.
Протокол NDMP ориентирован на устройства NAS и определяет метод резервного копирования и восстановления данных с устройства, например
системы NAS, на которой сложно установить агент резервного копирования. При отсутствии NDMP данные копируются с общего диска по протоколам CIFS и NFS.
Протокол NDMP имеет ряд преимуществ.
Интерфейсы предоставляются производителями, которые имеют доступ к ядру системы.
Интерфейсы стандартизированы и позволяют использовать Plug and Play для модулей разных производителей.
Протокол NDMP может сократить использование пропускной способности сети, обеспечивая передачу данных непосредственно между первичным и вторичным носителями, не требуя отправки данных сначала на сервер резервного копирования, а затем на вторичный носитель.
Протокол NDMP совмещает в себе лучшие качества обоих «миров», так как поддерживает удаленное управление через сеанс управления NDMP, а данные могут передаваться локально через сеансы данных NDMP.
Посредством протокола NDMP определяется стандартизированный способ разбивки операций резервного копирования и восстановления на несколько томов, с учетом того, что каждый производитель предоставляет отдельные модули. Протокол NDMP включает в себя следующие компоненты:
агент перемещения данных;
службы NDMP;
сеансы NDMP.
Рассмотрим эти компоненты подробнее.
Агент перемещения данных (data mover agent – DMA) представляет собой основное приложение резервного копирования. Он устанавливает сеансы NDMP с поставщиком услуг NDMP (рассматривается далее) и управляет последовательностью действий, необходимых для настройки операции резервного копирования или восстановления. Кроме того, иногда агент перемещения данных называетсяклиентом NDMP.
Протокол NDMP поддерживает службы, которые могут выступать в роли абонентов или генераторов и позволяют одному устройству быть и абонентом и генератором потоков данных. Протоколом NDMP версии 5 поддерживается три типа служб.
Служба данных взаимодействует с первичным устройством хранения (например, с устройством NAS). Эта служба работает с томом или файловой системой, которая копируется на резервный носитель или восстанавливается.
Служба магнитных накопителей взаимодействует со вторичным устройством хранения, как правило, накопителем на магнитной ленте.
Служба трансляции выполняет преобразование данных, включая мультиплексирование нескольких потоков данных в один поток и наоборот.
Службы NDMP взаимодействуют друг с другом с помощью интерфейсов NDMP. В результате устанавливается сеанс NDMP, который называется управляющим сеансом, если используется для получения управления над операцией резервного копирования или восстановления, либо сеансом данных, если используется для передачи файловой системы или данных тома (включая метаданные). Между каждой службой NDMP и агентом перемещения данных существует только один сеанс. Сеансы управления всегда создаются на основе протокола TCP/IP; потоки данных могут передаваться по протоколу TCP/IP или по сетям хранения данных. Даже несмотря на возможность передачи данных по сетям хранения данных, использование протокола TCP/IP для сеансов управления требует наличия локальной сети. Потоки данных могут проходить между агентом перемещения данных и службой NDMP или непосредственно между двумя службами NDMP.
Агент перемещения данных и службы могут быть распределены на два или более компьютеров. На рис. 5.10 показан NDMP и работа двух компьютеров. Агент перемещения данных NDMP связывается с сервером NDMP и управляет перемещением данных с первичного на вторичный носитель. Сеансы данных устанавливаются между сервером NDMP, источником данных и точкой назначения данных.
На рис. 5.11 представлена концептуальная реализация протокола NDMP в Windows NT. Агент перемещения данных NDMP устанавливает два сеанса управления NDMP, по одному с каждым сервером NDMP. Данные передаются непосредственно между двумя серверами NDMP, а не «перетаскиваются» с одного сервера NDMP к агенту перемещения данных NDMP и оттуда к другому серверу NDMP.
Рис. 5.10. Архитектура NDMP
Рис. 5.11. Концептуальная реализация NDMP в Windows NT
5.9 Сложности практической реализации
Дорогостоящие подсистемы хранения, которые могут отслеживать метаданные для каждого сектора, позволяют намного эффективнее выполнять операции резервного копирования и восстановления, так как изменения отслеживаются очень точно и операции резервного копирования затрагивают изменившиеся данные.
Для обеспечения целостности моментального снимка в контексте приложения важно, чтобы операционная система (включая файловые системы) и приложение принимали участие в чистке кэша и временной приостановке операций записи на время создания моментального снимка. Служба теневого копирования томов, которая поставляется в составе Windows Server 2003, обеспечивает поддержку со стороны операционной системы и файловых систем, а также делает доступной архитектуру поддержки со стороны приложений. Эта архитектура используется такими важными приложениями, как Microsoft Exchange и Microsoft SQL Server.
Остается подождать и посмотреть, как остальные поставщики программного обеспечения будут поддерживать архитектуру теневого копирования томов.
5.10 Резюме
Операции резервного копирования эволюционировали с точки зрения требований пользователей и технологий, применяемых для резервирования данных. В последнее время требуется все более частое резервирование информации, причем без нарушения доступа приложений к диску. Операции резервного копирования прошли путь от изолированного резервного копирования до резервного копирования, выполняемого по локальной сети и в сетях хранения данных. Одной из проблем, решение которой требовалось от приложений резервного копирования, было копирование открытых файлов, доступ к которым осуществляется работающими приложениями.
Кроме того, приложения для резервного копирования должны обрабатывать множество API, специфических для различных версий приложений и операционных систем. Еще одна тенденция состоит в резервировании «с диска на диск» с помощью операции создания моментального снимка. Резервное копирование на магнитную ленту превращается во вторичную операцию, которая подразумевает копирование данных с моментального снимка тома.
Служба теневого копирования томов Windows предоставляет эффективный способ создания моментальных снимков. Архитектура содержит все необходимые компоненты, включая основные приложения, например базы данных и серверы передачи сообщений, которые принимают участие в создании моментальных снимков. Компания Microsoft только предоставляет инфраструктуру для создания моментальных снимков. Производители программного обеспечения могут использовать эту инфраструктуру для генерации приложений, поддерживающих создание нескольких моментальных снимков и управление ими.
Созданный моментальный снимок можно использовать для резервного копирования данных. Чтобы выполнить резервирование, можно воспользоваться стандартным протоколом, например NDMP.
Глава 6 Файловые системы
Файловая система обеспечивает работу важнейших функций; основные из них перечислены ниже.
Поддержка целостности данных и предоставление пользователю необходимых возможностей для создания, удаления, чтения и записи файлов.
Предоставление высокой пропускной способности и производительности с сохранением устойчивости к ошибкам файловой системы и аппаратного обеспечения.
Поддержка различных устройств, например жестких дисков и сменных дисков, у каждого из которых разные объемы и производительность.
Предоставление уровня абстракции, позволяющего изолировать приложения от физических характеристик устройства хранения и конкретного местоположения необходимых данных на физическом носителе. Приложения обрабатывают файлы в качестве линейной последовательности байтов и существуют в рамках этой последовательности, произвольно проводя чтение и запись данных.
Предоставление уровня абстракции, который позволяет приложениям организовывать файлы в иерархии, например в каталоги, содержащие файлы и другие каталоги. На практике иерархия – сугубо логическая структура, поддерживаемая файловой системой, так как все данные размещены в случайных кластерах диска.
Предоставление уровня безопасности для данных; например, файловая система NTFS принудительно требует проверки прав доступа к определенным ресурсам, например файлам, каталогам и томам.
Поддержка параллельного доступа, т.е. работы нескольких пользователей и обработки одновременных запросов на ввод-вывод от каждого пользователя. Кроме того, предоставляется служба индексирования и блокировок, которая позволяет операции ввода-вывода от какого-либо пользователя получить в исключительное владение определенный файл или область файла. Кроме того, файловая система должна восстанавливаться после отказов в работе приложений, которые приняли во владение такие ресурсы файловой системы, как блокированный фрагмент файла.
Файловые системы существуют не сами по себе, а размещены на каких- либо носителях. Хотя оптические носители (компакт-диски и DVD) также имеют файловые системы, в этой книге рассматриваются корпоративные подсистемы хранения данных на базе Windows, которые обычно основаны на жестких дисках. Таким образом, основное внимание в этой главе уделяется организации работы жестких дисков в Windows NT. В первой части главы объясняются такие понятия, как базовые и динамические диски Windows NT, их взаимодействие с разделами и томами.
После этого обсуждаются особенности работы NTFS, рассматриваются важные внутренние структуры данных, например главная таблица файлов (MFT), а также такие функции, как сжатие данных, журнал изменений, отслеживание связей, точки повторной обработки и шифрованная файловая система (EFS).
В последней части главы описываются файловые системы, применяемые в сетях хранения данных, их преимущества и. технические проблемы, возникающие при создании файловой системы для сети хранения данных. Кроме того, представлены технологии некоторых конкретных производителей.
6.1 Диски, разделы и тома
Термин диск используется при описании такого физического носителя, как накопитель IDE или SCSI, а также сменных носителей, например накопителей USB, компакт-дисков и DVD. Логически диск состоит из кластеров, которые характеризуются размером, например 512, 1024, 4096 байт. Термин диск всегда используется при ссылке на физический объект, который можно увидеть и взять в руки. С другой стороны, термины раздел и том, которые описываются в следующих абзацах, представляют собой логические концепции.
В контексте администрирования некоторые диски (но не все)[10] могут быть разделены на несколько логических областей, которые называются разделами (partitions). Каждый раздел может содержать указанный объем данных, и это значение представляет собой интегральное количество кластерных единиц. Например, диск объемом 80 Гбайт может быть разбит на два раздела, один из которых предназначен для установки файловой системы и системных утилит, а второй – для хранения пользовательских данных. Еще одна причина выделения небольшого раздела на корпоративных сервера^ связана с установкой диагностических утилит.
Рис. 6.1. Диски, разделы и тома
Том (volume) – это набор, состоящий из одного или нескольких разделов. Комбинация разделов может быть подобрана для обеспечения быстродействия, объема, целостности данных или сочетания этих параметров. Например, два раздела могут быть объединены для создания тома большего объема или два раздела одинакового размера могут составлять единый зеркальный том, в котором данные дублируются на каждый из разделов. Такие методы комбинации разделов рассматриваются в главе 9, посвященной массивам RAID. Обратите внимание: комбинирование разделов имеет ряд особенностей, которые зависят от типа диска и версии Windows; более подробно они рассматриваются далее.
Если быть точным, то файловые системы размещены на томах. Тома, как уже отмечалось, включают в себя один или несколько дисковых разделов. Дисковые разделы – это логические элементы физического диска. На рис. 6.1 приведена многоуровневая структура. Сверху представлен уровень файловой системы, ниже уровень томов, еще ниже – уровень дисковых разделов.
На рис. 6.1 показана схема NTFS тома V1, который, в свою очередь, состоит из разделов D1-P1 и D2-P2. Кроме того, NTFS установлена на томе V2, который создан из зеркальных разделов D1-P2 и D2-P1 (при этом разделы должны быть одинакового размера). Для обозначения другого метода формирования тома V2 связь между томом и разделами показана штрих- пунктирной линией. Файловая система FAT установлена на томе V3, который состоит из одного раздела D3-P1. Диск D1 разбит на два раздела: D1-P1 и D1-P2. Диск D2 также разбит на два раздела: D2-P1 и D2-P2. Диск D3 имеет только один раздел – D3-P1. Обратите внимание, что рис. 6.1 приведен в качестве примера и не описывает всех возможных способов создания томов.
Учитывая базовые идеи, лежащие в основе файловых систем, можно обратиться к деталям. В частности, описанию раздела как набора дисковых кластеров не хватает ряда важных подробностей, например: каким образом операционная система собирает данные на нескольких разделах, существующих на определенном диске, и в каком месте начинается и заканчивается определенный раздел. Ответы на эти вопросы требуют более подробного описания, которое приводиться в разделах 6.1.1 и 6.1.2. Кроме того, разделы на базовых дисках иногда в шутку называют «жесткими» разделами, а разделы на динамических дисках – «мягкими» (об этом речь идет далее в главе). Эти названия отражают неизменность размера жестких разделов (их невозможно увеличить или уменьшить) и возможность изменения размера мягких разделов, даже если они активно используются в текущий момент времени.
Следует упомянуть еще одну особенность. В этой книге рассматривается иерархия, в которой диски делятся на разделы, а разделы составляют тома. Но в некоторых книгах термины том и раздел взаимозаменяемы, особенно если предполагается, что том состоит из одного раздела. Более того, в некоторых книгах взаимозаменяемыми являются термины раздел и диск. Читая эту книгу, помните о трехуровневой иерархии: физические диски делятся на логические элементы, которые называются разделами, а разделы, в свою очередь, определенным образом формируют другие логические элементы, которые называются томами. Файловая система. всегда взаимодействует непосредственно с томами.
Идея разделения рабочего пространства дисков существует уже довольно давно. Термин базовый диск (basic disk) впервые появился в Windows 2000 и описывал диски, в которых для предоставления информации о разбивке диска на логические разделы применялись устаревшие технологии DOS.
Первый физический сектор на каждом диске – как базовый, так и динамический – имеет важнейшее значение. Этот сектор содержит структуру данных, которая называется главной загрузочной записью (Master Boot Record – MBR) и предоставляет информацию об организации диска, а также участвует в загрузке компьютера. Независимо от операционной системы, запись MBR одинакова для всех персональных компьютеров. Она может иметь размер до 512 байт и включает в себя четыре элемента.
1. Программа загрузки, которая имеет размер до 442 байт. Этот код отвечает за сканирование таблицы разделов (описывается ниже), поиск начального сектора загрузочного раздела, загрузку содержимого раздела в оперативную память и передачу управления этому коду, размещенному в памяти.
Уникальный номер размером 4 байт, который называется сигнатурой диска. Сигнатура всегда расположена со смещением 0x01В8 (с начала сектора) и используется в качестве индекса в системном реестре для сохранения и получения информации о диске.
Таблица разделов, которая может содержать до четырех записей. Первая запись всегда расположена со смещением 0x01 BE. Каждая запись имеет размер ровно 16 байт. Один из описанных в таблице разделов отмечен как активный. С этого раздела загружается операционная система. Первый сектор каждого раздела называется загрузочным сектором тома (volume boot sector – VBS) и по своей структуре напоминает MBR. Разница между ними заключается в том, что запись MBR одна на весь диск, а загрузочный сектор существует у каждого тома. Таким образом, один физический диск может иметь несколько загрузочных секторов тома. Каждый загрузочный сектор диска содержит информацию о томе, например размер, количество секторов и метку. Кроме того, загрузочный сектор тома содержит код загрузки операционной системы, который загружается кодом раздела MBR.
Маркер завершения MBR, который всегда равен 0х55АА.
Обратите внимание: раздел MBR может содержать записи только о четырех разделах, т.е. диск можно разбить максимум на четыре раздела. Для предоставления большего количества разделов один из четырех разделов можно преобразовать (получив тем самым расширенный раздел). Такой раздел может содержать собственную таблицу разделов. Описываемое разделение таблиц разделов теоретически может продолжаться до бесконечности.
Базовые диски в полной мере поддерживаются в Windows 2000, Windows ХР и Windows Server 2003. Хотя эта поддержка необходима, она не лишена определенных недостатков.
Одна из проблем состоит в том, что упомянутые системы не поддерживают создания сложных томов на основе разделов базовых дисков. Под термином сложный том подразумевается том, состоящий из нескольких разделов различных базовых дисков. Примером служит том, состоящий из двух разделов различных базовых дисков для получения единого тома большего объема. В Windows NT 4.0 такие тома называются составными (spanned). Операционные системы Windows 2000 и Windows Server 2003 поддерживают уже существующие составные тома на основе базовых дисков, однако создание новых составных томов на основе базовых дисков не поддерживается.
Устаревшие составные тома, которые создавались в более ранних версиях Windows NT (до Windows 2000), могут быть импортированы в Windows 2000, Windows ХР и Windows Server 2003.
Базовые диски обладают определенными недостатками. Например, они весьма чувствительны к повреждению первого сектора, который содержит запись MBR. Только аппаратные (а не программные) массивы RAID позволяют обойти это ограничение. Массивы RAID рассматриваются в главе 9. Данные записи MBR не дублируются в программных системах RAID, и для этого есть свои причины: если система загружается и получает доступ к записи MBR, драйвер' программного решения RAID еще не загружен, поэтому не сможет помочь в решении проблем с повреждением записи MBR.
Еще один недостаток базовых дисков – необходимость перезагружать компьютер при изменении конфигурации разделов.
Операционная система Windows 2000 ввела в обиход концепцию динамических дисков (dynamic disks). Динамические диски предназначены для преодоления недостатков базовых дисков.
Динамические диски можно перенастраивать «на лету», даже когда приложения (и файловые системы) получают доступ к диску. Сервер не требует перезагрузки для того, чтобы новая конфигурация динамического диска была активизирована для системы. Тома динамических дисков могут быть перенастроены без нарушения обращений к тому или перезагрузки операционной системы. Кроме того, динамические диски более устойчивы к отказам в работе, чем базовые диски, так как важная конфигурационная информация дублируется и копируется на другие физические диски, входящие в дисковую группу.
Как показано на рис. 6.2, а, каждый динамический диск поддерживает базу данных объемом 1 Мбайт; речь идет о базе данных диспетчера логических дисков (logical disk manager – LDM). Чтобы предотвратить повреждение данных (например, вследствие работы устаревшей утилиты или в результате вмешательства другой операционной системы), все динамические диски содержат запись MBR, как и базовые диски. Для динамических дисков, которые не содержат файлов операционной системы, запись MBR создается так, чтобы охватить один раздел, занимающий весь физический диск.
Вспомним понятия загрузочного (boot) и системного (system) разделов в Windows NT[11]. Загрузочный раздел содержит файлы операционной системы, например каталог WinNT. Системный раздел содержит загрузочный код. Поскольку загрузочный код Windows NT не поддерживает динамических томов, запись MBR иногда (когда диск содержит системный раздел) создается таким образом, чтобы был обнаружен один раздел и загрузочный код был бы доступен для обнаружения и запуска.
Рис. 6.2. Разбивка динамических дисков (а); база данных диспетчера логических дисков, зеркально отраженная в пределах дисковой группы (б)
Динамические диски организованы в группы, но диспетчер логических дисков поддерживает только одну дисковую группу. Имя дисковой группы, принятой по умолчанию (и единственной поддерживаемой), создается с помощью добавления значения dgO в конец имени компьютера. Как показано на рис. 6.2, б, эта база данных содержит информацию обо всех динамических дисках в пределах группы, что предоставляет возможность защиты данных. Здесь показано два диска, входящих в дисковую группу, хотя их может быть и больше. База данных содержит не только данные об организации дисков, но и подробную информацию о монтировании томов, т.е. о букве диска или о каталоге, в котором монтируются тома на данном диске.
Другими словами, вся служебная информация динамического диска размещена на самом диске, поэтому их иногда называют дисками с самоописанием. В то же время информация о монтировании (букве диска) для базовых дисков хранится в реестре системы.
Хотя динамические диски обладают массой преимуществ для семейства Windows NT, они не лишены некоторых недостатков. Основные из них описаны ниже.
Динамические диски не поддерживаются другими операционными системами (отличающимися от Windows 2000 и более поздних версий). Необходимость в считывании таких дисков может возникать в том случае, когда диски подключаются к компьютерам под управлением другой операционной системы или к коммутатору связной архитектуры, взаимодействующему с сервером. Другие операционные системы могут получить доступ к диску средствами Windows 2000, подключаясь к общему ресурсу сервера Windows 2000.
Динамические диски не поддерживаются некоторыми портативными компьютерами и сменными носителями, например дисками Iomega Jazz или сменными жесткими дисками с интерфейсом 1394/USB.
Система Microsoft Cluster Server не поддерживает динамические диски, подключенные к совместно используемой кластером шине SCSI, если не установлен менеджер VERITAS Volume Manager. Можно сделать предположение, что для этого существуют причины как технического, так и юридического характера. Достаточно вспомнить, что только диспетчер Volume Manager компании VERITAS поддерживает несколько дисковых групп. Кластеры часто используются в режиме «активный- активный». Если рассмотреть наиболее простую схему кластера, включающего в себя два узла, типичным решением будет разделение дисковых ресурсов на две группы и назначение каждой группы отдельному узлу. Если работа одного узла будет нарушена, дисковая группа этого узла перейдет под управление другого узла. Таким образом, требуется наличие двух дисковых групп, а значит, поставляемый в комплекте с системой диспетчер логических дисков (LDM), поддерживающий только одну дисковую группу, не сможет справиться с описанной ситуацией.
Единственный способ преобразования динамического диска в базовый состоит в резервном копировании данных, переформатировании диска и обратном восстановлении информации.
Технология динамических дисков все еще развивается. В частности, поскольку такие важные системные компоненты, как загрузочный код, не поддерживают динамических дисков, некоторые функции старых разделов по-прежнему реализованы в Windows.
Операционные системы Windows 2000 и Windows Server 2003 поддерживают как базовые диски, так и преобразование базовых дисков в динамические. Тем не менее преобразование имеет некоторые особенности, поэтому перед ним желательно провести резервное копирование, удалить все данные и разделы с диска, преобразовать «пустой» диск в динамический, реорганизовать диск и восстановить данные из резервной копии. Если выполнить обычное преобразование базового диска в динамический, не все преимущества динамических дисков могут оказаться доступными; например, если динамический диск создан на основе базового, динамическое изменение размеров разделов может оказаться недоступным.
6.2 Тома и диспетчеры томов
Как уже отмечалось, том – это логический компонент, включающий в себя дисковые разделы. Эти разделы могут быть реализованы на динамических или базовых дисках. Тома в семействе Windows Server внедряются с помощью драйвера устройства, который называется диспетчер томов. Диспетчеры томов и их место в стеке подсистемы хранения данных рассматриваются в главе 1. В этом разделе основное внимание уделяется возможностям томов в операционных системах, появившихся после Windows 2000; в частности, рассматриваются три диспетчера томов.
Диспетчер FtDisk, предоставляемый в Windows 2000 и Windows Server 2003. В Windows NT 4.0 драйвер FtDisk загружался только по требованию, поскольку работал исключительно с расширенными функциями томов^ нацример обеспечением устойчивости к ошибкам. B. Windows 2000 FtDisk драйвер загружается по умолчанию, поскольку обрабатывает все тома базовых дисков.
Диспетчер LDM (Logical Disk Manager), который предоставляется в Windows 2000 и Windows Server 2003.
Диспетчер LVM (VERITAS Logical Volume Manager), предлагаемый компанией VERITAS в качестве платной системы; LVM расширяет базовые возможности LDM.
*
Эти диспетчеры томов обеспечивают перечисленные ниже возможности.
Виртуализация подсистемы хранения данных; при этом файловая система абстрагйруется от физического диска, на котором она размещена. Кроме того, диспетчер томов может объединять несколько разделов нескольких дисков в один большой том.
Защита данных путем обеспечения их избыточности (с помощью одной из технологий массива RAID, рассматриваемых в главе 9) или посредством их сохранения вместе с контрольной суммой.
Повышение производительности с помощью хранения данных в формате, поддерживающем эффективное извлечение информации.
В табл. 6.1 приведены возможности каждого диспетчера томов в Windows 2000 и Windows Server 2003.
Таблица 6.1. Возможности диспетчеров томов
Диспетчеры LDM и LVM рассматриваются в контексте схожих параметров, однако каждый из них реализован на базе четырех разных драйверов, обладающих различными возможностями. Таким образом достигается уменьшение размера программного кода и упрощается обработка стандартных процедур. Эти драйверы описаны далее.
1. Драйвер DMConfig может читать и обновлять базу данных LDM. При изменении конфигурации он отражает изменения в копии базы данных, которая находится в оперативной памяти. Соответствующий драйвер LVM называется VxConfig.
Драйвер DMIO (dmio. sys) является аналогом диспетчера FtDisk и реализует возможности диспетчера томов для стандартных операций чтения и записи данных, размещенных на дисковых разделах. Кроме того, DMIO создает объекты устройств томов. Этот драйвер имеет меньший размер, поскольку не содержит кода для чтения и записи базы данных LDM или обработки LDM в дисковом формате. Соответствующий драйвер LVM называется VxIO.
Драйвер DMBoot (dmboot. sys) поддерживает только считывание базы данных LDM. Он загружается только после того, как драйвер DMLoad (dmload. sys) обнаружит более одного динамического диска. Оба драйвера используются только в процессе загрузки. Соответствующие драйверы LVM называются VxBoot и VxLoad.
При преобразовании базового диска в динамический все старые компоненты преобразуются в новые (табл. 6.2).
Таблица 6.2. Терминология томов в Windows NT 4.0 и Windows 2000
* Массивам RAID посвящена глава 9.
В Windows 2000 методы управления томами были существенно изменены. Например, Windows 2000 не только аннулирует ограничение в 26 томов, но и позволяет динамически добавлять/удалять тома, не перезагружая систему. Для реализации таких изменений в управлении томами были введены два новых компонента – диспетчер разделов и диспетчер монтирования. Новые возможности по управлению томами, а также эти два диспетчера описаны в разделах 6.2.1–6.2.4.
Диспетчер разделов – это драйвер в Windows 2000 и Windows Server 2003. Он представляет собой драйвер фильтрации верхнего уровня (драйверы фильтрации рассматриваются в главе 1), который регистрируется в подсистеме Windows NT Plug and Play и запрашивает уведомление о создании новых объектов устройств в драйвере класса диска.
Диспетчер разделов взаимодействует с диспетчерами томов посредством закрытого интерфейса и передает диспетчерам томов уведомления о создании устройств. Как только диспетчер томов обнаруживает, что доступны все разделы, формирующие том, он создает объект устройства, представляющий том. Кроме того, диспетчер разделов уведомляет подсистему РпР об удалении объекта устройства или раздела (например, когда выполняется удаление раздела). Диспетчер разделов сообщает диспетчерам томов о динамическом создании и удалении разделов. Более подробно он рассматривается в разделах 6.2.3 и 6.2.4.
Диспетчер монтирования – это драйвер, который появился в Windows 2000 и доступен в Windows Server 2003 и Windows ХР. Диспетчер монтирования Windows NT (mountggr. sys) предоставляет возможности для управления хранилищем данных на базе томов. К этим возможностям относятся:
монтирование томов;
размонтирование томов;
отслеживание точек монтирования томов и букв дисков в файле базы данных, который называется: $MountMgrRemoteDatabase и находится в корневом каталоге каждого тома NTFS;
создание и удаление пространств имен (и их ассоциаций), которые делают тома доступными для приложений пользовательского режима.
Неудивительно, что диспетчер монтирования зависит от подсистемы Plug and Play, так как требует уведомлений о событиях, которые соответствуют активизации и отключению тома. При монтировании тома диспетчер монтирования «консультируется» с соответствующим диспетчером тома через закрытый интерфейс. Если том расположен на базовом диске, применяется диспетчер томов FtDisk, который обращается к системному реестру для предоставления соответствующей буквы диска. Если том находится на динамическом диске, используется диспетчер томов LDM, который обращается к данным точки монтирования, содержащимся в базе данных LDM динамического дис. ка.
Диспетчер монтирования поддерживает базу данных (уникальных) идентификаторов томов, которые встречались диспетчеру ранее, а также путь или букву диска, назначаемую смонтированному ранее тому. Как только диспетчер монтирования получает уведомление о появлении тома и диспетчер томов не в состоянии предложить точку монтирования, диспетчер монтирования обращается к базе данных и пытается воспользоваться той же буквой диска или путем монтирования, которые использовались при последнем монтировании тома. Если для этого тома в базе данных не содержится информации или точка монтирования уже занята, диспетчер монтирования назначает диску новую точку монтирования. При отключении устройства диспетчер монтирования также отвечает за размонтирование тома. Но запись о точке монтирования из базы данных не удаляется.
Диспетчер монтирования отвечает, за назначение букв дисков томам на базовых дисках (но только тех, которые появились после запуска системы). Диспетчер монтирования назначает буквы диска начиная с буквы С: в соответствии с приоритетами. Устойчивые к ошибкам (устаревшие) наборы томов[12] Windows NT 4.0 имеют наивысший приоритет, после чего следует основной раздел на фиксированном диске и сменные диски (Jazz, USB). После сменных дисков буквы назначаются накопителям на компакт-дисках. Как только все эти устройства получают буквы дисков начиная с А:, буквы назначаются томам на гибких дисках. Накопители на компакт-дисках получают буквы начиная с D:.
Диспетчер монтирования сохраняет назначенные буквы дисков в системном реестре, обеспечивая их неизменность, т.е. при изменении конфигурации системы каждому тому будет назначена буква, которая назначалась ранее. Диспетчер монтирования не поддерживает принудительную защиту буквы диска, если соответствующий раздел отключается. Таким образом, если разделу назначается буква диска, и он отключается, эта же буква диска может быть назначена другому разделу, который активизируется первым[13].
Операциями диспетчера монтирования можно управлять из командной строки с помощью утилиты mountvol. exe. В Windows Server 2003 возможности диспетчера монтирования были обновлены, поэтому приложения могут отказаться от монтирования томов, которые ранее никогда не монтировались в этой системе. Это слабая попытка обеспечить функции таблицы монтирования UNIX. Смысл нововведения – избежать возможного повреждения тома, если он становится доступен Windows по ошибке.
Разобравшись с функциями томов, рассмотрим, как тома обрабатываются в стеке ввода-вывода устройств хранения данных. В этом разделе представлена информация о стеке ввода-вывода для томов базовых дисков, а в разделе 6.2.4 – для томов динамических дисков.
В главе 1 описано дерево устройств для простого тома базового диска, где том состоит из одного раздела. Обратите внимание, что диспетчер томов FtDisk поддерживает устаревшие тома, созданные из нескольких разделов. Программный код для поддержки томов с несколькими разделами так и остался в диспетчере томов FtDisk, но, начиная с. Windows 2000, возможность создания тома с несколькими разделами на основе базовых дисков более недоступна.
Обратите внимание на рис. 6.3. Начиная с нижнего правого угла схемы, отображается взаимодействие подсистемы РпР и драйверов шины PCI для создания объектов физического и функционального устройств для шины PCI. После этого драйвер шины PCI перечисляет устройства, подключенные к шине PCI, и создает объект физического устройства для адаптера шины SCSI. Драйвер SCSIPort создает объект функционального устройства для адаптера SCSI. Затем драйвер SCSIPort создает объект физического устройства для одного диска, подключенного к системе, а драйвер класса диска создает объект функционального устройства для этого диска.
Диспетчер разделов следит за проходящими пакетами IRP и обеспечивает правильный путь ввода-вывода для завершения обработки пакетов. Как только диспетчер разделов отмечает завершение обработки запроса IRP_MN_ QUERY_DEVICE_RELATIONSHIPS, он незаметно удаляет все данные об обнаруженных устройствах (дисках). В данном случае речь идет об объектах устройств для двух разделов – 0 и 1, которые создаются драйвером класса диска disk. sys. Таким образом, объекты устройств для разделов 0 и 1 никогда не обнаруживаются подсистемой РпР. Именно поэтому объекты для разделов 0 и 1 обозначены цветом, отличным от цвета остальных объектов устройств (см. рис. 6.3).
Диспетчер разделов передает подробную информацию об обнаруженных объектах устройств зарегистрированным диспетчерам томов. Как только диспетчер тома завершает процедуру инициализации, он регистрируется в подсистеме ввода-вывода. Диспетчер разделов вызывает каждый диспетчер томов по очереди, передавая им информацию об объектах устройств дисков, перехваченных в запросе IRP_MN_QUERY_DEVICE_RELATIONSHIPS. Диспетчеры томов проверяют объекты дисковых устройств, перехваченные диспетчером разделов и принимают или отвергают свои права владения этими объектами. Диспетчер FtDisk принимает права владения всеми томами, от которых отказываются остальные диспетчеры томов.
Рис. 6.3. Дерево объектов устройств для устаревшего составного тома на базовом диске
В примере, показанном на рис. 6.3, драйвер FtDisk становится владельцем устройств объектов. После этого диспетчер FtDisk проверяет конфигурацию тома и определяет, что том состоит из двух разделов, которые диспетчер принимает во владение. На этом этапе диспетчер FtDisk создает объект устройства для представления тома (который на рис. 6.3 называетсяТом V01). Затем для тома может быть смонтирована файловая система.
Стоит упомянуть, что в данном случае используется два отдельных стека устройств. Один стек представляет собой логический элемент – том; второй стек содержит физические устройства системы, например шипу PCI, адаптер шины SCSI и дисковый привод. Диспетчер томов выступает в роли моста между этими двумя стеками.
На рис. 6.3 драйвер FtDisk отправляет все распознанные запросы IRP непосредственно драйверу класса диска. Конечно, драйвер FtDisk перед отправкой пакета проводит преобразование смещений относительно тома в смещения относительно диска. Кроме того, запросы управления вводом-выводом, которые не воспринимаются драйвером FtDisk, отправляются разделу О или 1, в зависимости от назначения запроса.
Рассмотрим подробнее дерево устройств для томов динамических дисков, которое отличается рядом параметров от дерева устройств для томов на базовых дисках. На рис. 6.4 показано дерево устройств для томов на динамических дисках.
Чтобы не усложнять пример, представим, что рассматриваемый том исключительно программный и находится на динамическом диске. Динамический диск не содержит системного или загрузочного раздела операционной системы, т.е. в записи MBR динамического диска указано, что диск имеет один раздел, занимающий весь свободный объем. Конечно, последний мегабайт жесткого диска содержит базу данных диспетчера томов LDM.
Рис. 6.4. Дерево устройств для тома на динамическом диске
На рис. 6.4 представлены два отдельных дерева объектов, которые читателю уже знакомы: дерево физических объектов (справа), дерево логических объектов (слева) и диспетчер логических дисков (LDM), соединяющий оба дерева. Начиная с нижнего правого угла, на рис. 6.4 представлена пары объект физического устройства-объект функционального устройства для шины PCI. Выше можно заметить пару «объект физического устройства-объект функционального устройства» для шины SCSI. В этом примере к системе подключены два динамических диска. На следующем уровне показана пара «объект физического устройства-объект функционального устройства» для двух физических дисков, установленных в системе. Диспетчер разделов расположен над объектами функциональных устройств, созданными драйвером класса диска.
Диспетчер разделов регистрирует процедуру завершения для всех обрабатываемых им пакетов IRP. В процедуре завершения особое внимание уделяется пакетам IRP_MN_QUERY_DEVICE_RELATIONSHIPS и ожидаются сообщения о создании объектов устройств дисков. Драйвер класса диска, работая как драйвер шины, создает объекты устройств для описания одного раздела, который представляет Динамический диск. Диспетчер разделов передает эту информацию об объектах устройств дисков зарегистрированным диспетчерам томов. В этом примере показан единственный диспетчер томов – LDM, который загружается как логический драйвер с корневым перечислением. В данном контексте диспетчер LDM примет на себя ответственность за объекты устройств дисков. Предположим, что нужный том сформирован из двух дисков. Диспетчер томов LDM проверяет конфигурацию тома и, как только владение всеми объектами разделов будет подтверждено, создает объект устройства, представляющий том, который в этом примере называется Том V01.
Диспетчер томов LDM перенаправляет ввод-вывод от объекта тома к одному из дисков, который содержит необходимые данные. Обратите внимание, что два объекта разделов – раздел 0 для диска 1 и раздел 0 для диска 2 – никогда не передаются подсистеме РпР, поэтому они не связаны с другими объектами.
6.3 Пространство имен устройств
Данное пространство имен развилось за несколько лет существования Windows NT. Для обеспечения обратной совместимости новое пространство имен объединяется со старым пространством с помощью символических ссылок. Кроме того, драйверы режима ядра создают пространство имен в режиме ядра, используя возможности диспетчера объектов. Приложения пользовательского режима воспринимают другие пространства имен, взаимодействующие друг с другом посредством символических ссылок. Иногда разобраться с хитростями пространств имен не так-то просто. В этом разделе делается скромная попытка перечислить наиболее важные для подсистемы хранения имена устройств.
Драйвер класса диска создает объекты устройств для представления каждого физического диска. Эти объекты имеют название \device\harddiskX, где X – число, начинающееся с нуля и увеличивающееся для каждого найденного жесткого диска.
Кроме того, драйвер класса диска создает объект устройства для каждого найденного основного раздела. Драйвер класса диска использует функцию IoReadPartitionTable диспетчера ввода-вывода для поиска всех основных разделов на диске. Такие основные разделы называются \device\harddiskX \partitionY, где X – номер диска, а У – номер основного раздела, расположенного на этом физическом диске. Диспетчер ввода-вывода создает символьную ссылку в формате \??\PhysicalDriveX, где X – число больше нуля, отображаемое на ссылку \device\harddiskX\partitionY.
Диспетчер томов LDM создает объект для каждого поддерживаемого тома. Эти объекты устройств имеют имена в формате \Device\HarddiskVolumes \PhysicalDmVolumes\BlockVolumeX, где X – идентификатор, который назначается тому диспетчером томов. Это устройство режима ядра соотносится с устройством Win32, которое создается диспетчером монтирования и имеет вид \??\Volume [GUID], где GUID – глобально уникальный идентификатор. Диспетчер томов также создает символьную ссылку в формате \Device\HarddiskDmVolumes\ComputerNameDgOWolumeY для каждого тома и соотносит ссылки с определенными устройствами в каталоге PhysicalVolumes При этом значение ComputerName заменяется фактическим именем компьютера, a Y – идентификатором тома.
Для предоставления прямого доступа к тому диспетчер томов LDM создает объект для каждого поддерживаемого тома. Этот объект устройства имеет имя в формате \Device\HarddiskDmVolumes\PhysicalDmVolumes\RawVolumeX.
Обратите внимание, что в данном разделе не описываются все возможные имена устройств и их форматы. Любознательным читателям рекомендуется
запустить утилиты управления дисками и томами с графическим интерфейсом и обратить внимание на предоставляемые ими сведения.
6.4 Другие файловые системы
Операционная система Windows NT обеспечивает поддержку различных файловых систем. Основной, обладающей полным спектром возможностей файловой системой является NTFS. Компания Microsoft утверждает, что в ныне устаревшую файловую систему FAT новые функции вноситься не будут. Кроме NTFS и FAT (которые рассматриваются далее в главе), операционная система поддерживает и другие файловые системы.
Файловая система CDFS, совместимая со стандартом ISO 9660 и предназначенная для ввода-вывода данных на дисководы для компакт-дисков.
Файловая система UDF (Universal Disk Format), разработанная ассоциацией OSTA. Поддержка UDF была впервые реализована в Windows 2000. Эта файловая система – наследник CDFS, поддерживающий DVD. В Windows 2000 предоставляется поддержка только чтения, а в Windows ХР – как чтения, так и записи данных.
Обратите внимание, что один экземпляр операционной системы может одновременно использовать несколько файловых систем. Более того, компьютер под управлением Windows может иметь несколько томов и вовсе не обязательно, чтобы все тома имели одинаковую файловую систему.
Операционная система Windows 2000 поддерживает обновленную версию FAT (File Allocation Table). Следует отметить ряд особенностей FAT.
Существует две версии файловой системы FAT – FAT 16 с 16-разрядными указателями и FAT32 с 32-разрядными указателями.
Файловая система FAT16 поддерживает тома размером дй 4 Гбайт при условии применения кластеров размером 64 Кбайт. Файловая система FAT32 поддерживает разделы размером до 32 Гбайт при условии применения кластеров размером 16 Кбайт.
Корневой каталог может содержать не более 512 записей.
Сжатие и механизмы безопасности не поддерживаются.
6.5 Файловая система NTFS
Эта файловая система проектировалась специально для Windows NT. С момента первого появления NTFS в нее вносилось несколько модификаций, но основная архитектура оставалась неизменной. Файловых систем FAT и HPFS (High-Performance File System), поддерживаемых Microsoft в момент появления NTFS, было явно недостаточно для удовлетворения потребностей Windows NT.
Файловая система FAT не предоставляет необходимого уровня безопасности файлов и объектов.
Файловая система FAT не поддерживает возможностей по обработке вместительных жестких дисков, доступных в настоящий момент. (Вспомните, что изначально FAT проектировалась для использования на дисках объемом 1 Мбайт.)
Как FAT, так и HPFS не поддерживают транзакций, которые необходимы для обеспечения надежности данных и их восстановления после отказов в работе системы.
Файловая система NTFS предоставляет различные возможности, которые перечислены ниже и подробно описываются далее в главе.
Поддержка транзакций в NTFS обеспечивает регистрацию всех изменений метаданных файловой системы в специальном журнале, который поддерживает восстановление в случае неисправности.
Все данные, включая метаданные системы, хранятся в файлах.
NTFS и программные интерфейсы приложений Win32 поддерживают использование 64-разрядных указателей для структур данных файлов.
NTFS поддерживает имена файлов длиной до 255 символов и кодировку Unicode.
Структуры данных поддерживают быстрое перемещение и поиск в каталогах. '
Файловая система поддерживает сжатие и разреженные файлы.
Начиная с Windows 2000 поддерживается шифрованная файловая система (EFS).
Файловая система обеспечивает устойчивость к отказам, например к появлению поврежденных кластеров на диске или перераспределению секторов.
NTFS не имеет ограничения на длину имен 8.3, которое было характерно для MS DOS. Кроме того, обеспечивается совместимость с именами
файлов POSIX, включая точки и пробелы в начале имени. Тем не менее иногда при использовании имен, не соответствующих стандарту 8.3, возникают проблемы. Основной их причиной могут быть утилиты, не поддерживающие длинных имен, которые не соответствуют стандарту 8.3. Отдельные имена файлов NTFS могут иметь размер до 255 символов, а полный путь к файлу не должен превышать 32 767 символов.
■ В NTFS используются 64-разрядные указатели файлов и теоретически может поддерживаться размер файла 264 байт.
В NTFS поддерживается несколько потоков данных для одного файла. Поток можно открыть с помощью функции Win32 API CreateFile, а имя потока в виде: ИмяПотока может быть добавлено к имени файла, например Filel: Stream25. Потоки поддерживают запись, чтение и независимую от других открытых потоков блокировку. Операционная система Windows NT для серверов Macintosh использует эту функцию при поддержке клиентов Мае, на которых файл имеет две «ветви»: ветвь данных и ветвь ресурсов.
Обратите внимание, что, хотя NTFS и поддерживает несколько потоков, множеству утилит и программ об этом ничего не известно. Таким образом, о файле, содержащем 1024 байт в обычном неименованном потоке и 1 Мбайт данных в именованном потоке, команда dir сообщит, как о файле размером 1024 байт (команда dir не поддерживает многопоточность). При копировании файлов с несколькими потоками с раздела NTFS в FAT копируется только неименованный поток, принятый по умолчанию. Данные из остальных потоков считаются потерянными.
В табл. 6.3 сравниваются FAT и NTFS.
Таблица 6.3. Сравнение файловых систем, поддерживаемых Windows NT
Окончание табл. 6.3
Файловая система организует все содержимое диска в виде файлов, включая не только пользовательские файлы, но и файлы, содержащие метаданные, которые относятся к файловой системе. В этом разделе рассматриваются файлы, которые NTFS использует для внутренней, организации функционирования.
Главная файловая таблица (Master File Table – MFT; $Mft) всегда представляет собой первый файл тома NTFS. Она содержит множество записей и, как минимум, одну запись для каждого файла и каталога тома, включая запись для самой MFT. Каждая запись в MFT может иметь размер 1024–4096 Кбайт, в зависимости от размера тома, на котором размещена файловая система. Для файлов с несколькими атрибутами или чрезмерной фрагментацией может потребоваться несколько записей в MFT. Таблица MFT хранится в начале тома.
Производительность системы существенно повышается, если записи MFT хранятся в соседних кластерах диска, т.е. когда MFT не фрагментирована и занимает непрерывную область диска. Для выполнения этого условия NTFS резервирует область, которая называетсязоной MFT, в начале тома или раздела и стремится не использовать эту область ни для чего, кроме хранения записей MFT. Первые файлы и каталоги записываются сразу после MFT. Около 12% тома зарезервировано для зоны MFT. Начиная с Windows NT 4.0 SP4, в реестр добавлена специальная запись, которая позволяет управлять размером зоны MFT. Эта запись может иметь значения в диапазоне от 1 до 4, указывая размер зоны MFT от минимального (1) -до максимального (4). Программа дефрагментации указывает текущий размер зоны MFT.
Первые 24 записи в MFT зарезервированы. Некоторые записи меняют свое назначение с выходом новой версии операционной системы, как это произошло с выходом Windows 2000. В табл. 6.4 описаны различные системные файлы NTFS, которые также известны как файлы метаданных.
Таблица 6.4. Системные файлы NTFS
* Знак доллара ($) перед именем файла означает, что это файл метаданных
Файл $MftMirr содержит зеркальную копию первых 16 записей MFT и представляет собой метод обеспечения целостности тома, даже если секторы MFT окажутся поврежденными. Файл $MftMirr хранится в середине тома. Более объемные тома могут иметь более одного зеркала MFT.
Файл журнала $LogFile используется для восстановления после отказов в работе системы или возникновения неожиданных ситуаций. NTFS поддерживает транзакции и протоколирование: сначала в журнал заносятся все изменения системных метаданных и только затем проводятся изменения. Файл журнала содержит информацию для отмены и повтора операций, которая используется для восстановления после отказов в работе системы и поддержки целостности файловой системы.
Обратите внимание: метаданных из файла журнала транзакций достаточно лишь для поддержки целостности файловой системы, например для обеспечения правильной маркировки кластеров: или как свободных, или принадлежащих определенному файлу. Содержимое этих кластеров – пользовательские данные – в журнале не отслеживается. После фиксирования транзакции и изменения метаданных запись о завершении операции заносится в файл журнала.
Все операции с файлом журнала выполняются средствами службы файлового журнала NTFS, которая предоставляет собой набор процедур драйвера NTFS. Для хранения файла журнала в NTFS используется циклический буфер. В начале буфера содержится указатель на область в самом буфере, в которой должен начаться процесс восстановления. Этот указатель в файле журнала сохраняется дважды (избыточно), чтобы обеспечить возможность восстановления в том случае, если одна из областей файла журнала окажется поврежденной.
Файл $Volume содержит имя тома, дату и временную метку (указывающую на время создания тома), информацию о версии NTFS и дополнительный бит, используемый для проверки правильности завершения работы системы. Кроме того, этот бит проверяется при загрузке системы для определения необходимости запуска утилиты CHKDSK.
Файл $AttrDef содержит все атрибуты, которые поддерживаются на данном томе. Для каждого атрибута указывается различная информация, например имя атрибута, тип атрибута, минимальная и максимальная длина.
Корневой каталог также обладает большим значением. Все операции поиска файлов и каталогов должны начинаться с корневого каталога, если они не кэшированы во время предыдущих операций поиска.
Файл $Bitmap представляет каждый кластер диска, на котором находится том. Каждый бит указывает занятость одного кластера диска.
Файл $Boot предназначен для хранения и защиты кода загрузчика, который всегда размещен в фиксированной области, удаленной от начала тома. При форматировании тома с использованием NTFS утилита форматирования проверяет, владеет ли файл $Boot кластерами, в которые помещен код загрузчика. Таким образом, код загрузчика защищен от перезаписи другими данными.
Файл $BadClus содержит записи для каждого поврежденного кластера на диске. Этот файл обновляется динамически; т.е. для каждого динамически обнаруженного поврежденного кластера в файл добавляется новая запись.
Файл $Secure впервые появился в Windows 2000. Файловая система NTFS поддерживает механизмы безопасности для каждого файла и каталога. До выхода Windows 2000 данные о безопасности хранились в каждой записи для файла и каталога в MFT. Поскольку множество файлов и каталогов «имели одинаковую информацию о правах доступа, такая информация часто 'дублировалась. Например, если у пользователя есть право доступа на чтение и запуск 100 файлов, формирую