В предыдущих главах рассматривалась архитектура Windows в рамках определенных возможностей подсистемы хранения данных. Эта глава предназначена для профессионалов, использующих подсистемы хранения в повседневной работе и желающих получить информацию об их функциях в разных версиях Windows.

Кроме того, в здесь приводятся некоторые прогнозы, которые могут оправдаться в ближайшем будущем. Предполагается, что обсуждаемые возможности будут включены в определенную версию Windows, однако нет никакой гарантии, что прогнозы совпадут с реальностью[22]. Читатель должен помнить об этом, когда будет принимать решения на основе информации, предоставленной в книге.

В этой главе обсуждаются возможности подсистемы хранения в контексте разных версий Windows, однако процесс выпуска новых версий делает такое обсуждение несколько запутанным. Зачастую ключевые функции разрабатываются для определенной версии Windows NT, однако после разработки становятся доступными и для более ранних версий. В таком случае функции рассматриваются в контексте именно новой версии Windows NT.

Операционная система Windows NT 4.0 используется в основном как файловый сервер и сервер печати, а также в качестве платформы для приложений. Кроме того, эта версия Windows обладает рядом возможностей, позволяющих работать в сетях хранения данных. Тем не менее по сравнению с Windows NT 4.0 в Windows 2000 были существенно улучшены подсистемы хранения данных.

Возможности Windows NT 4.0 и их взаимосвязь с подсистемой хранения рассматриваются в разделах 10.1.1–10.1.4.

В Windows NT 4.0 Service Pack 5 стала доступна поддержка функции Large LUNs, позволяющей использовать до 255 LUN на одно устройство SCSI. До пакета обновлений Service Pack 5 в Windows NT поддерживалось только восемь LUN на одной целевое устройство.

Операционная система Windows NT 4.0 отлично справлялась с управлением хранилищами, подключенными к сети, так как могла выступать в роли файлового сервера и сервера печати для различных клиентов. К ним относятся клиенты Windows, использующие протокол совместного доступа к сетевым ресурсам SMB или CIFS, клиенты UNIX, применяющие протокол NFS, клиенты NetWare и Macintosh.

В Windows NT 4.0 были предоставлены API для дефрагментации, которые позволяли независимым производителям программного обеспечения создавать приложения дефрагментации для современных и будущих версий Windows NT. Эти интерфейсы создавались Microsoft в тесном сотрудничестве с самими производителями, что позволило удовлетворить практически все требования последних.

Распределенная файловая система (DFS) позволяет администраторам создавать иерархию именования, отражающую корпоративную организационную структуру, благодаря чему пользователям не нужно отслеживать имена серверов и расположение файлов. Кроме того, распределенная файловая система поддерживает гетерогенную операционную среду, в которой могут участвовать серверы, работающие под управлением операционных систем, отличных от Windows. Другими словами, DFS предоставляет возможность организации и управления сетевыми ресурсами, подобно тому как файловая система позволяет организовывать файлы и управлять ими.

Клиенты, работающие под управлением Windows, обращаются к распределенной файловой системе по протоколу CIFS, но как только клиент получает ссылку на сервер, где фактически хранится необходимый файл, он может подключаться к серверу по любому другому протоколу, например NFS или NCP (Network Control Protocol). Это означает, что единственный сервер под управлением Windows NT, исполняющий роль сервера DFS, может расширить преимущества распределенной файловой системы и на другие гетерогенные серверы. Распределенная файловая система использует функции службы репликации файлов. Данные о связывании физического расположения с логическим путем к файлу обрабатываются клиентом и сохраняются в системном реестре.

Распределенная файловая система обладает следующими преимуществами:

обеспечение эффективного администрирования, так как ресурсы сервера могут быть перенесены без нарушения пользовательского доступа; пользователи могут получать доступ к ресурсу, перенаправленному администратором на другой сервер или на другой ресурс сервера;

пользователям предоставляется уровень абстракции, в котором не требуется отслеживать физическое расположение необходимых файлов.

Наиболее заметное улучшение Windows 2000 связано с возможностью использования платформы Windows NT в среде SAN и NAS. В разделах 10.2.1–10.2.13 рассматриваются улучшенные возможности подсистемы хранения в Windows 2000.

Операционная система Windows 2000 оптимизирует доступ к единицам хранения, а именно:

значительно уменьшает количество ситуаций, в которых после изменения конфигурации единицы хранения требуется перезагрузка операционной системы, например при добавлении, удалении, увеличении или уменьшении томов;

значительно увеличивает количество поддерживаемых единиц хранения.

Операционная система Windows NT 4.0 требовала перезагрузки перед получением доступа к новому устройству хранения (в терминологии подсистем хранения оно называется целевым устройством). Подсистема РпР Windows 2000 поддерживает динамическое добавление и удаление целевых устройств подсистемы хранения. Драйвер шины сообщает о событии, которое называется BusChangeDetected, а операционная система отвечает на это последовательностью действий, которая включает в себя повторное сканирование всех устройств, подключенных к шине. Тем не менее к новому устройству возможен доступ со стороны операционной системы и драйверов без перезагрузки. Кроме того, Windows не требует повторной инициализации шины подсистемы хранения (например, SCSI или Fibre Channel), что занимает немало времени. Таким образом, добавление нового целевого устройства или динамическое предоставление нового LUN для существующего целевого устройства не потребует повторной инициализации шины.

Однако Windows NT (включая Windows 2000) все еще принимает на себя владение всеми обнаруженными LUN. В настоящий момент Microsoft разрабатывает технологию, позволяющую администратору указывать доступные или недоступные LUN для Windows NT. Это даст возможность сделать LUN видимыми для Windows NT (и невидимыми для приложений), причем Windows не будет использовать эти единицы, что поможет избежать возможного повреждения данных LUN.

Операционная система Windows 2000 поддерживает значительно улучшенную схему подключения устройств хранения, которая позволяет адресовать до 128 целевых устройств (идентификаторов SCSI) и до 255 LUN на одно целевое устройств. Для сравнения: Windows NT 4.0 поддерживает только восемь целевых устройств и по восемь LUN на одно целевое устройство. Операционная система Windows NT 4.0 Service Pack 5 поддерживает 255 целевых устройств и восемь LUN на одно целевое устройство.

В Windows 2000 была представлена новая концепция динамических дисков. Термин динамический диск указывает на логическую архитектуру физического диска. Физический диск остается базовым диском с таблицей разделов, которая использовалась в Windows NT 4.0, пока не будет явно преобразован в динамический диск. Иными словами, динамические диски – это физические диски с другим форматом таблицы разделов, который допускает динамическое увеличение и уменьшение размера разделов. Новая таблица разделов с поддержкой избыточности обеспечивает доступность при повреждении кластеров основной копии. Более подробная информация по этой теме приводится в главе 6.

Динамические диски распознаются только в Windows 2000 и более поздних версиях Windows NT. Они хранят таблицу разделов старого формата, чтобы защитить данные от повреждения при просмотре раздела в Windows NT 4.0 или другой операционной системе, если она поддерживает только старый формат таблицы разделов. Однако такая таблица содержит лишь одну запись, указывающую на использование всего объема диска. Таблица разделов старого формата не отражает логической организации диска.

В Windows 2000 добавлены два новых компонента режима ядра. Диспетчер монтирования (Mount Manager) обрабатывает операции монтирования для базовых и динамических дисков, включая назначение букв дискам. Диспетчер разделов (Partition Manager) обрабатывает операции подсистемы РпР, а также операции управления питанием и взаимодействия с интерфейсом WMI, связанные с дисковыми разделами. Комбинация этих подсистем режима ядра позволяет использовать в одной системе одновременно два диспетчера томов. Одним из них является старый драйвер FtDisk, который в определенном смысле можно считать «классическим» диспетчером томов. Второй – это принятый по умолчанию диспетчер LDM (Logical Disk Manager), который поставляется в составе Windows 2000, или LVM (Logical Volume Manager), который предоставляется компанией VERITAS.

Наряду с улучшениями в подсистеме РпР управление дисками обрело ряд новых возможностей.

Динамическое увеличение и уменьшение размера томов без останова и перезагрузки операционной системы. Приложениям не запрещен доступ к томам во время динамического изменения размера последних.

Тома могут монтироваться и размонтироваться «на лету». Конечно, размонтированный том недоступен, однако системе не требуется перезагрузка после отключения или добавления тома.

Тома могут быть перенастроены с одного класса RAID на другой класс без перезагрузки операционной системы. Допустима настройка, разбивка и повторная сборка массивов RAID 0, RAID 1 и RAID 5.

Поддерживаются устаревшие тома, включая те, которые используют массив RAID с помощью старого диспетчера томов FtDisk.

Динамические диски содержат всю необходимую информацию для описания структуры диска, т.е. все метаданные хранятся на самом диске. В Windows NT 4.0 часть метаданных хранилась в системном реестре. Это означает, что Windows 2000 допускает перенос динамических дисков между различными компьютерами без дополнительной настройки.

Для управления дисками доступны утилиты как с графическим интерфейсом, так и поддерживающие командную строку.

Добавлены новые API, которые позволяют создавать приложения управления томами. В качестве примера можно привести интерфейс для перечисления всех томов (FindFirstVolume для первого тома, FindNextVolume для следующего тома и FindVolumeClose для завершения перечисления и освобождения связанных с ним ресурсов). Функция GetVolumelnformation возвращает информацию о томе, включая поддержку томом точек повторной обработки (см. раздел 10.2.10).

Распределенная файловая система (DFS) впервые появилась в Windows NT 4.0. Она позволяет администратору эффективно управлять ресурсами сети и предоставляет пользователям возможность работать с названиями ресурсов и каталогов, которые отражают действительное рабочее окружение. При этом не требуется знать физическую структуру сети для доступа к данным. Например, пользователи компании могут получать доступ к ресурсу \\Моя_Компания\Накладные для загрузки всех файлов и каталогов, которые относятся к бухгалтерии, для чего им не придется задумываться об имени физического сервера и названиях его ресурсов.

В Windows 2000 распределенная файловая система была существенно модифицирована.

Повышенная надежность и отказоустойчивость. В Windows 2000 предоставляется поддержка кластеров для DFS, что исключает отказ файловой системы при неисправности сервера, выполняющего роль корня файловой системы. Для этого DFS интегрирована в инфраструктуру Active Directory, поэтому данные топологии DFS хранятся в базе данных Active Directory. Более того, изменения топологии DFS вступают в силу без остановки и перезапуска службы DFS. Распределенная файловая система взаимодействует со службой репликации файлов Windows 2000 для дублирования изменений в репликах DFS.

Оптимизация администрирования. Теперь для администрирования распределенной файловой системы предоставляется оснастка ММС. Кроме того, DFS поддерживает больше конфигурационных параметров, например допускается указание времени, в течение которого будет кэшироваться запись DFS. Распределенная файловая система в Windows 2000 интегрирована в службу каталогов Active Directory, благодаря чему системный администратор получает больше возможностей по управлению DFS.

Повышение производительности. Клиенты под управлением Windows 2000 выбирают копии DFS, которые находятся в пределах локального сайта, а не случайные копии, возможно находящиеся в удаленных сайтах. Если в локальном сайте доступно несколько копий DFS, клиенты Windows 2000 выбирают копии случайным образом. Клиенты под управлением Windows NT 4.0 выполняют значительно больше операций при доступе к DFS. Еще более старые клиенты DFS вообще о ней не «подозревают» и стремятся преобразовать путь, предполагая, что он содержит действительное имя сервера. Только после неудачной попытки подключиться к несуществующему серверу клиент использует службы драйвера df s. sys для преобразования пути. Клиенты Windows 2000 изначально поддерживают использование пути DFS и задействуют драйвер dfs. sys для преобразования пути к файлу.

Балансировка нагрузки. Так как несколько серверов зачастую содержат один и тот же набор файлов, клиент может получить доступ к любому из серверов, в то время как несколько клиентов имеют возможность получить доступ к одному и тому же файлу, хранящемуся на различных серверах.

Операционная система Windows 2000 позволяет администратору отметить общие ресурсы сервера как содержащие кэшируемые файлы. Файлы такого ресурса (например, данные и выполняемые файлы программ или динамически подключаемые библиотеки) загружаются на клиентские компьютеры и сохраняются локально. Такая загрузка выполняется при первом открытии файла. Неоткрываемые файлы на клиентские компьютеры не загружаются. Синхронизация файлов осуществляется в фоновом режиме либо при регистрации или завершении сеанса пользователя. Если синхронизация приводит к конфликту (когда локальные изменения конфликтуют с изменениями на сервере), он решается при содействии пользователя. Основные преимущества кэшируемых файлов таковы:

повышение производительности, так как чтение с локального диска выполняется намного быстрее, чем считывание файла по сети;

увеличение отказоустойчивости, так как пользователь может продолжать работу на клиентском компьютере даже при отказе в работе сервера;

возможность отключения от сети и работы в автономном режиме.

Администратор может установить следующие параметры автономных папок:

ручное кэширование документов, когда администратор явно указывает файлы документов, которые могут кэшироваться пользователями;

автоматическое кэширование документов, когда все файлы документов, открытых пользователем, автоматически кэшируются на локальном компьютере;

автоматическое кэширование файлов программ, при котором кэшируются выполняемые файлы и файлы динамически подключаемых библиотек.

В Windows 2000 была представлена двунаправленная служба репликации файлов (FRS), использующая журнал изменений NTFS для обнаружения измененных файлов и каталогов. Служба репликации файлов активно за- действуется Active Directory. Кроме того, FRS применяется распределенной файловой системой для создания нескольких копий файлов и метаданных на нескольких серверах, что позволяет обеспечивать балансировку нагрузки и отказоустойчивость.

В Windows 2000 Server предоставляется встроенная служба индексации и связанные с ней утилиты.

ОкноНайти файлы и папки (Find Files or Folders) предоставляет доступ к возможностям службы индексации.

Служба индексации может индексировать содержимое файлов и атрибуты файлов, включая указанные пользователем.

Служба индексации поддерживает индексацию автономных данных, которыми управляют службы удаленного хранилища (RSS).

На томах с NTFS служба индексации использует журнал изменений для отслеживания изменений с момента последнего запуска.

Служба индексации использует возможность массовой проверки списков управления доступом и возвращает только те файлы, которые разрешено просматривать пользователю, выполняющему поиск. Файлы, к которым пользователю доступ запрещен, служба индексации из результатов поиска удаляет.

Служба индексации поддерживает тома с файловой системой FAT, однако снижение эффективности при этом неизбежно, так как в FAT не поддерживается журнал изменений.

Операционная система Windows 2000 может создавать собственные тома NTFS. Ранее для этого требовалось создавать раздел FAT, который впоследствии преобразовывался в раздел NTFS. Обратите внимание на взаимозаменяемое использование терминов раздел и том. Как отмечается в главе б, разделы и тома относятся к одной логической концепции с несколько разными особенностями. В частности, том, в отличие от раздела, поддерживает динамическое изменение размера.

С выходом Windows 2000 в файловую систему были внесены определенные улучшения. Хотя основные модификации относятся к NTFS, Windows 2000 поддерживает расширенные возможности файловых систем для оптических носителей, а также для «ветерана» FAT. Компания Microsoft заявила, что в дальнейшем FAT будет лишь поддерживаться и новых модификаций не предвидится. Улучшения NTFS настолько существенны, что заслужили более подробного описания (см. раздел 10.2.9).

Операционная система Windows 2000 поддерживает файловую систему FAT32. Это первая версия Windows NT, работающая с FAT32, поскольку до этого FAT32 была реализована только на платформе Windows 9х. В FAT32 поддерживаются тома размером до 2 Тбайт с максимальным размером файла, равным 4 Гбайт. Из соображений производительности, утилиты для работы с файловыми системами ограничивают размер тома FAT до 32 Гбайт, что, впрочем, относится к возможностям утилит, а не самой файловой системы. В FAT32 реализован меньший размер кластера диска, что позволяет более эффективно использовать дисковое пространство.

Файловые системы оптических носителей

Операционная система Windows NT 4.0 поддерживала файловую систему CDFS (CD-ROM File System), что также справедливо и для Windows 2000. В Windows 2000 появилась поддержка файловой системы UDF (Universal Disk Format), разработанной ассоциацией OSTA (Optical Storage Technology Association).

Файловая система NTFS с выходом Windows 2000 претерпела значительные изменения, в том числе касающиеся дисковой структуры NTFS. Как только Windows 2000 в первый раз монтирует устаревший раздел с NTFS (устаревший, т.е. созданный средствами более ранней версии Windows NT), файловая система подвергается незаметному для пользователя преобразованию. Преобразование выполняется весьма эффективно, и время преобразования не зависит от размера раздела. Операционная система Windows NT 4.0 SP4 и более поздние версии Windows NT поддерживают новую версию NTFS.

Реализация этих возможностей потребовала изменения дисковой структуры NTFS. Для существующих томов дисковая структура меняется при первом монтировании в Windows 2000. Для системного тома эта операция выполняется при модернизации Windows NT 4.0 до Windows 2000.

Компания Microsoft провела немало тестирований Windows 2000 и NTFS в вычислительной среде корпоративного уровня предприятия.

Максимальный размер файла, который использовался при тестировании, составляет 2^44–64 Кбайт, что составляет примерно 16 Тбайт. С другой стороны, максимальный теоретический размер файла составляет 2^64–1 байт, что примерно равно 17 Эбайт.

Максимальное количество файлов на одном томе при тестировании составило 34 миллиона. С другой стороны, теоретический предел составляет 232–1, т.е. примерно 4 миллиарда.

Операционная система Windows 2000 впервые предоставляет поддержку базовых наборов свойств – определенных пользователем метаданных, связанных с файлом. Эти метаданные могут индексироваться службой индексации Windows 2000 Server. Например, можно указать автора документа или предполагаемую аудиторию документа. Затем пользователи могут осуществлять поиск документа, воспользовавшись значениями указанных тегов или метаданных. Файловая система NTFS обрабатывает файлы в качестве наборов пар «атрибут-значение». Определенные пользователем свойства сохраняются в дополнительных атрибутах файла.

Операционная система Windows NT отслеживает учетные записи пользователей по уникальному идентификатору безопасности (SID). Файловая система NTFS в Windows 2000 может сканировать том и определять все файлы, которые принадлежат определенному идентификатору безопасности. Этот процесс намного упрощает администрирование; например, при увольнении работника сканирование по идентификатору безопасности позволяет быстро обнаружить и удалить принадлежащие ему файлы.

Файловая система NTFS в Windows NT 4.0 сохраняла списки управления доступом (ACL) отдельно для каждого файла и каталога. Если пользователю принадлежало 50 файлов, идентичные списки управления доступом потенциально могли сохраняться 50 раз, по одному разу в каждом файле. Файловая система NTFS в Windows 2000 сохраняет списки управления доступом в каталоге и проводит индексацию этих списков. Другими словами, в описанном случае список управления доступом будет, сохранен один раз, а каждый из 50 файлов получит «указатель», который дает возможность определить необходимый список управления доступом.

Описанный метод позволяет обеспечить массовую проверку списков управления доступом службой индексирования. Если пользователь осуществляет поиск файлов, служба индексирования создает список файлов. Перед возвратом списка пользователю проводится проверка ACL и удаление из списка всех файлов, к которым пользователь не имеет доступа. Таким образом, пользователь получит список только тех файлов, на доступ к которым у него есть разрешение.

Массовая проверка списков управления доступом может применяться и в других случаях. Например, для определения действий, которые пользователь может выполнять с указанным набором файлов.

Файловая система NTFS отслеживает все вносимые изменения по двум причинам.

Для восстановления целостности данных в случае неисправностей в работе, что обеспечивается занесением в журнал информации обо всех операциях перед их выполнением.

Для предоставления приложениям информации об изменившихся файлах и каталогах.

В журнале изменений записываются только модификации, внесенные в файловую систему. Информации из журнала недостаточно для отмены выполненной операции. Файл журнала изменений «выживает» на протяжении нескольких перезагрузок операционной системы. Если этот файл окажется переполненным или удаленным, приложения смогут определить, что некоторая информация об изменениях будет потеряна. Затем приложения проводят, например, повторное сканирование всех необходимых файлов и каталогов. Описанный механизм имеет особое значение для приложений репликации и резервного копирования.

Файловая система NTFS в Windows NT всегда предоставлялась с поддержкой нескольких потоков данных на один файл. Примером приложения, поддерживающего многопоточный ввод-вывод, служит программный сервер Windows NT Macintosh. До появления Windows 2000 не существовало способа переименования потока данных после его создания. Можно было создать новый файл с новым именованным потоком данных и скопировать в него содержимое старого файла, однако такой подход недостаточно эффективен. Файловая система NTFS в Windows 2000 предоставляет специальный интерфейс, который позволяет приложениям переименовывать существующие именованные потоки данных.

Операционная система Windows 2000 позволяет отслеживать ссылки. Это могут быть ярлыки файлов или объекты OLE, в частности документы Excel или PowerPoint, включенные в другой файл, например в документ Word. Приложение может отслеживать ссылки, даже если документ – источник ссылки перемещается различными способами, например:

документ переносится в рамках того же тома на компьютере под управлением Windows NT;

документ переносится между томами одного и того же компьютера под управлением Windows NT;

документ переносится с одного компьютера под управлением Windows NT на другой компьютер под управлением Windows NT в рамках одного домена;

весь том, содержащий документ, переносится с одного на другой компьютер под управлением Windows NT в рамках одного домена;

переименовывается сервер под управлением Windows NT с монтированным томом, который содержит документ;

¦ переименовывается общий сетевой ресурс сервера под управлением Windows NT, который содержит документ;

¦ переименовывается документ;

ш выполняется любая комбинация описанных действий.

– Каждый файл в Windows 2000 (и более поздних версиях Windows NT) может иметь (но не обязательно) уникальный идентификатор объекта. Для отслеживания файла приложение ссылается на него по уникальному идентификатору. Если ссылка на файл не может быть найдена, на помощь вызывается служба отслеживания ссылок пользовательского режима (служба вызывается Windows NT). Служба стремится найти файл с помощью идентификатора объекта методом «проб и ошибок», обрабатывая все описанные выше сценарии.

В Windows NT 3.51 была реализована функция сжатия файловой системы. Предполагалось, что будут сжиматься файлы, содержащие большие диапазоны, состоящие из одних нулей. Но сжатие и распаковка занимали определенное время, и сжатые данные все равно занимали некий объем жесткого диска. Рассмотрим файл, который имеет логический размер 1 Гбайт, но содержит только 4 Кбайт данных в начале файла и 4 Кбайт данных – в конце. В Windows 2000 такой файл, если его отметить в качестве разреженного, будет занимать всего 8 Кбайт дискового пространства (при соответствующем размере дискового кластера).

Файловая система NTFS упорядочивает внутренние структуры данных для распознавания отсутствующих блоков и при получении от приложения запроса на чтение данных из этих блоков и заполняет нулями буфер приложения. Приложение даже не «догадывается», что файл обладает определенными свойствами, и проводит с ним обычные операции чтения/записи. Разреженные файлы обладают атрибутом, управляемым пользователем, который может быть установлен для индикации разреженности файла. Приложения при этом работают обычным образом, однако система функционирует менее эффективно, так как определенное, время затрачивается на возврат нулей для данных, которые находятся в невыделенных блоках файла. Приложения, обрабатывающие атрибут разреженного файла, могут пропускать операцию чтения невыделенных кластеров файла.

Функция перечисления файлов и каталогов (например, FindFirst и FindNext) возвращает флаг FILE_ATTRIBUTE_SPARSE_FILE. Функции Win32 API BackupRead, BackupWrite, CopyFile и MoveFile обновлены для работы с разреженными файлами (например, функция CopyFile сохраняет разреженное состояние файла и не выполняет операции чтения и записи, которые преобразуют файла в неразреженное состояние).

Отслеживание и управление дисковыми квотами реализованы в NTFS, которая предоставляется в Windows 2000. Дисковые квоты отслеживаются для пользователей и для томов. При этом системный администратор может:

отключить эту функцию;

использовать ее для отслеживания объемов дискового пространства;

задействовать ее для отслеживания и принудительного применения политик, которые ограничивают объем дискового пространства, выделенного пользователю.

Дисковые квоты отслеживаются на основе идентификатора безопасности пользователя (SID). Этот уникальный идентификатор назначается каждому пользователю, зарегистрированному на компьютере под управлением Windows NT (в качестве пользователя может выступать другой компьютер или системная учетная запись – по сути, тот же пользователь с набором привилегий, отличных от набора привилегий для стандартного пользователя). Каждый файл и каталог содержит идентификатор безопасности своего владельца. Дисковые квоты указываются для каждого тома, а утилиты администрирования позволяют реплицировать политику квот на другие тома.

Как уже неоднократно отмечалось, Windows 2000 позволяет возвращать список файлов, принадлежащих определенному пользователю. Эта функция предоставляет собой элемент технологии отслеживания дисковых квот, так как при отслеживании квот вычисляется общий объем дискового пространства, которое выделено определенному пользователю на хранение его файлов.

В файловой системе NTFS для Windows 2000 уменьшено количество случаев, требующих запуска утилиты CHKDSK, что намного сокращает время работы данной утилиты. Будет уместным вспомнить выражение «конечный результат может отличаться от продемонстрированного», так как реальные результаты зависят от размера тома и типа повреждения. Для томов, содержащих миллионы файлов, утилита CHKDSK может работать быстрее на порядок.

В Windows 2000 предоставляется утилита дефрагментации, которая на самом деле является «облегченной» версией утилиты DiskKeeper от компании Executive Software. Как и в Windows NT 4.0, в Windows 2000 поддерживаются специальные API дефрагментации. Встроенная утилита дефрагментации обладает определенными ограничениями, которые не свойственны большинству полноценных приложений дефрагментации, например:

встроенная утилита не может дефрагментировать главную таблицу файлов NTFS (MFT) или файл подкачки;

встроенная утилита не может дефрагментировать каталоги;

встроенная утилита не поддерживает систему Microsoft Cluster Server.

Появление точек повторной обработки (reparse points) значительно усовершенствовало архитектуру файловой системы NTFS и подсистемы ввода- вывода Windows NT. Обратите внимание, что реализация точек повторной обработки потребовала изменения подсистемы ввода-вывода и NTFS. Возможности точек можно внедрить и в другие файловые системы, отличные от NTFS. Кроме того, точки повторной обработки обеспечивают работу следующих важнейших функций Windows:

символьные ссылки;

точки соединения каталогов;

точки монтирования томов;

служба SIS (Single Instance Storage);

служба удаленного хранения HSM (Hierarchical Storage Management).

Все эти возможности рассматриваются в разделах 10.2.10.1–10.2.10.4.

Точки повторной обработки – это объект каталога или файла NTFS. Точка может быть создана, удалена или изменена приложением, использующим Win32 API в целом и функции CreateFile, ReadFile, WriteFile в частности. Вспомните, что Win32 API предоставляет приложениям возможность создавать и менять определенные пользователем атрибуты файла или каталога. Поэтому точки повторной обработки можно представить в виде определенного пользователем атрибута, который обрабатывается специальным образом. Такая обработка включает в себя обеспечение уникальности элементов объекта атрибута и обработку в подсистеме ввода-вывода. Независимые разработчики программного обеспечения обычно создают следующие приложения:

утилиты пользовательского режима для создания, управления и удаления точек повторной обработки;

драйверы фильтрации файловой системы, реализующие возможности точек повторной обработки.

Рис. 10.1. Структура тега точки повторной обработки

Каждая точка повторной обработки состоит из тега и объекта данных. Тег – это уникальное 32-разрядное число, назначаемое непосредственно Microsoft. Независимые производители могут запросить назначение специального тега. На рис. 10.1 показана структура тега повторной обработки, включая следующие элементы:

бит (М), который указывает, что тег принадлежит драйверу устройства от Microsoft;

бит (L), который указывает на значительные задержки при получении драйвером первого байта данных; в качестве примера моэкно указать службу HSM, при использовании которой получение данных с неинтерактивного носителя может осуществляться достаточно долго;

бит (N), который указывает, что файл или каталог представляют собой ссылку/перенаправление на другой файл или каталог;

зарезервированные биты;

фактическое 16-разрядное значение тега.

Объект данных точки повторной обработки может иметь размер до 16 Кбайт. Файловая система NTFS обеспечивает предоставление этого объекта данных драйверу устройства, созданному производителем. Объект данных предоставляется в процессе использования тбчки повторной обработки в подсистеме ввода-вывода.

На рис. 10.2 рассматривается последовательность рабочих операций и реализация точек повторной обработки. Предполагается, что пользователь обладает необходимыми привилегиями для выполнения запрошенной операции. Кроме того, на рис. 10.2 показан только драйвер фильтрации файловой системы, что позволяет сконцентрироваться исключительно на точках повторной обработки.

Рис. 10.2. Использование точки повторной обработки

Как показано на рис. 10.2, для реализации возможностей точки повторной обработки применяется несколько этапов.

1. Средствами подсистемы Win32 приложение отправляет запрос на открытие файла.

После проверок подсистема Win32 отправляет запрос выполняемому модулю Windows NT.

Диспетчер ввода-вывода Windows NT создает пакет IRP (IRP_MJ_0PEN) и отправляет его NTFS. Пакет IRP перехватывается драйвером точки повторной обработки в файловой системе.

Драйвер фильтрации перехватывает пакет IRP, определяет процедуру завершения, которая будет вызвана после завершения обработки пакета IRP, и средствами диспетчера ввода-вывода отправляет пакет IRP драйверу NTFS.

Пакет IRP достигает файловой системы, которая обрабатывает пакет IRP_MJ_0PEN, находит необходимый файл или каталог и отмечает ассоциированный с ними тег точки повторной обработки. Затем NTFS помещает тег и данные повторной обработки в пакет IRP и неудачно завершает обработку пакета IRP со специальным кодом ошибки.

Далее подсистема ввода-вывода вызывает каждый драйвер фильтрации (по одному за раз), который зарегистрировал процедуру завершения

для этого пакета IRP. Процедурой завершения каждого драйвера фильтрации рассматривается код ошибки и тег повторной обработки в пакете IRP. Если драйвер не распознает тег как собственный, он вызывает диспетчер ввода-вывода, который должен вызвать процедуру завершения следующего драйвера. Предположим, что один из драйверов распознал тег точки повторной обработки. После этого драйвер может использовать данные точки для повторной отправки пакета IRP, измененного в соответствии с данными, предоставленными точкой повторной обработки; например, перед повторной отправкой пакета IRP может быть изменен путь к файлу.

7. Файловая система NTFS завершает обработку повторно отправленного пакета IRP. Типичным примером может служить изменение пути и успешное завершение запроса. Диспетчер ввода-вывода завершает запрос на открытие файла, после чего через процедуры завершения может быть вызван каждый драйвер фильтрации файловой системы. Наконец обработка пакета IRP завершается, и приложение получает дескриптор файла.

Если ни один драйвер фильтрации не распознает тег точки повторной обработки, запрос на открытие файла или каталога завершается неудачно.

Одним приложениям требуются сведения о наличии точек повторной обработки, в то время как другим они совершенно не нужны. К последним, например, относятся приложения Microsoft Office, поэтому при открытии документа Word, PowerPoint или Excel функции точки повторной обработки, которая перенаправляет запрос на открытие на другой том, во внимание не принимаются. Тем не менее некоторым приложениям, которые рекурсивно просматривают дерево каталогов, требуются сведения о возможности создания зацикленных путей. Приложения могут аннулировать функции точек повторной обработки, передав соответствующие параметры (FILE_OPEN_REPARSE_POINT) 1 в запросах CreateFile, DeleteFile и RemoveDir. Именно таким образом можно создавать, удалять и модифицировать точки повторной обработки. Функция GetVolumelnf ormation возвращает флаг FILE_SUPPORTS_REPARSE_POINTS. Функции FindFirstFile и FindNextFile возвращают флаг FILE_ATTRIBUTE_ REPARSE_POINT для указания на наличие точки повторной обработки.

Все точки повторной обработки тома NTFS индексируются в файле, который называется $Index и находится в каталоге \$Extend. Таким образом, приложение может быстро обнаружить все точки повторной обработки, которые существуют на томе.

Следует подчеркнуть, что в этом разделе описываются точки повторной обработки, которые являются неотъемлемой частью NTFS. Хотя файловая система FAT не поддерживает точки повторной обработки, независимые производители программного обеспечения или компания Microsoft могут создать другую файловую систему, которая будет отличаться от NTFS и поддерживать точки повторной обработки. Это весьма нетривиальная задача, но стоит обратить внимание, что точки повторной обработки должны быть реализованы в трех областях.

Файловая система, например NTFS.

Подсистема ввода-вывода и набор функций Win32 API.

Утилиты и инструменты.

Очевидно, что Microsoft выполнила'необходимый объем работ во всех трех областях и высока вероятность, что новая файловая система (в случае ее появления) также будет поддерживать точки повторной обработки.

В разделах 10.2.10.1–10.2.10.4 рассматриваются конкретные сферы применения точек повторной обработки.

В Windows NT 4.0 для монтирования томов требовалось использование буквы диска. Это ограничивало количество томов (всего можно было монтировать до 26 томов), которые могли использоваться в системе. В Windows 2000 разрешено монтирование тома без использования буквы диска. Но существуют и ограничения:

том может монтироваться только на локальный каталог, т.е. том не может быть смонтирован на сетевой ресурс;

том может быть смонтирован только на пустой каталог;

пустой каталог должен размещаться в томе NTFS (на данный момент только NTFS поддерживает точки повторной обработки).

Приложения, которые получают доступ к каталогу, содержащему точку монтирования, не «замечают» ничего особенного, если только приложение специально не запрашивает информацию о каталоге.

Были добавлены и модифицированы API, которые предоставляют приложениям поддержку точек монтирования томов. Функция GetVolumelnformation с помощью флага показывает, поддерживает ли том точки монтирования. Функции FindFirstVolumeMountPoint и FindNextVolumeMountPoint используются для поиска точек монтирования томов. Функция FindVolumeMountPointClose применяется для освобождения ресурсов, задействованных функциями FindFirstVolumeMountPoint и FindNextVolumeMountPoint. И наконец, функция GetVolumeNameForMountPoint возвращает имя тома, в который преобразуется точка монтирования.

Точки соединения каталогов тесно связаны с точками монтирования томов. Различие между ними заключается в том, что точки монтирования томов связывают каталог с новым томом, а точки соединения каталогов связывают каталог с каталогом на этом же локальном томе. Точки соединения каталогов могут создаваться с помощью утилиты linkd. exe, которая предоставляется в составе пакета Resource Kit.

Служба SIS (Single Instance Storage) позволяет значительно снизить объем дискового пространства, которое требуется для хранения дублированных файлов. При этом дублированные файлы заменяются специальной ссылкой. Служба SIS используется совместно со службами удаленной установки (RIS), которые делают возможной загрузку Windows NT с сетевого ресурса.

Используя службы удаленной установки, администратор может создать несколько образов, например образ для бухгалтерии, конструкторского отдела и т.д. Каждый образ содержит множество файлов, дублирующих файлы из других образов. Но простого использования ссылки в данном случае будет недостаточно. Если администратор внесет изменения в один из файлов, все остальные образы, имеющие ссылку на этот файл, также будут содержать изменения. Именно в этом случае пригодится SIS.

Служба SIS вместо дублированного файла использует разреженный файл, для которого не выделено дисковое пространство и создана точка повторной обработки. Эта точка содержит достаточно информации для поиска необходимой резервной копии файла (если дублировано четыре файла, один файл остается как резервная копия, а остальные три файла превращаются в разреженные с точкой повторной обработки). Размер'разреженного файла будет совпадать с размером оригинального файла. Когда приложение открывает разреженный файл, драйвер фильтрации перехватывает запрос на открытие файла, открывает резервную копию файла и передает дескриптор файла вызывающему приложению. После этого ввод-вывод осуществляется с помощью резервной копии файла.

Удаленное хранилище (remote storage) – это служба управления хранилищем, которая предоставляет возможности прямого переноса файлов между интерактивным (например, жестким диском) и неинтерактивным (например, магнитной лентой) носителем. При переносе файла на неинтерактивный носитель на жестком диске остается так называемый «файл-заглушка». Благодаря точке повторной обработки NTFS файл отмечается, как особый, а также указывается точное местонахождение оригинального файла на неинтерактивном носителе. Службы удаленного хранилища (Remote Storage Services – RSS) зачастую называют службами управления иерархическим хранилищем (Hierarchical Storage Management), поскольку они взаимодействуют с двумя уровнями хранения данных.

Администратор может настроить специальные системные политики, например указать объем дискового пространства, который должен оставаться свободным, и типы файлов, которые должны обрабатываться RSS. Службы RSS периодически проверяют дисковое пространство на предмет соответствия установленной администратором политике. Кроме того, проводится поиск файлов, доступ к которым не осуществлялся некоторое время (обычно 30 дней). Эти файлы периодически копируются на магнитную ленту, причем их базовые версии остаются на жестком диске и с помощью точки повторной обработки отмечаются, как предварительно перемещенные. Как только дисковое пространство сокращается до указанного в политике объема, RSS удаляет файлы с диска и вносит изменения в точку повторной обработки, указывая, что файл теперь полностью перемещен на неинтерактивный носитель.

Службы RSS не поддерживают скрытые, системные, шифрованные или разреженные файлы, а также файлы, которые обладают расширенными атрибутами. Службы RSS тесно интегрированы с другими компонентами операционной системы.

Службы RSS взаимодействуют со службой индексации.

Службы RSS используют планировщик заданий Windows 2000 для планирования заданий по резервному копированию.

Программа резервного копирования Windows распознает перемещенные на неинтерактивный носитель файлы и не пытается восстановить такие файлы на диск только для их резервного копирования.

Службы RSS также интегрированы с системой безопасности NTFS; например, RSS вызывает файл с неинтерактивного носителя только в том случае, когда пользователю разрешен доступ к этому файлу.

ПрограммаПроводник (Windows Explorer) также взаимодействует с RSS. Перемещенные файлы отмечаются специальной пиктограммой.

Журнал изменений NTFS взаимодействует с RSS, поэтому для выделения перемещенных между носителями файлов используется специальный флаг. Приложение может использовать этот флаг для определения того, что файл не изменился.

Рис. 10.3. Архитектура HSM и RSM

На рис. 10.3 показана схема RSS и архитектура управления сменными носителями (Removable Storage Management – RSM). Приложение HSM использует программный интерфейс приложений RSM (см. раздел 10.2.11). Служба RSM – это подсистема пользовательского режима, обладающая собственной базой данных для отслеживания носителей и устройств.

Служба управления сменными носителями (RSM) позволяет приложениям управлять всеми сменными носителями в корпоративной сети, вне зависимости от типа сменного носителя. Интерактивные носители обычно находятся в различных устройствах, включая магазины, ленточные автоматы и роботизированные библиотеки. Неинтерактивные носители, как правило, лежат на полке.

На рис. 10.4 показана архитектура и преимущества службы управления сменными носителями. Приложение работает с единственным интерфейсом, который предоставляется RSM. Сама RSM взаимодействует с интерфейсами новых и временно подключаемых устройств.

Рис. 10.4. Управление сменными носителями

В службе RSM используется концепция пула носителей (media pool) для организации и управления носителями. Пул носителей представляет собой набор носителей. Пул может быть двух типов: системный пул и пул приложений. Системный пул (system pool) содержит носители, предназначенные для системных задач, а также нераспознанные или неназначенные носители. Системный пул делится на следующие категории:

свободный пул содержит носители, не используемые в данный момент и доступные для назначения;

пул импорта содержит только что добавленные распознанные носители; носители в пуле импорта могут находиться под управлением приложений и переноситься в пул приложений, если приложению понадобится использовать данный носитель, или в свободный пул, если приложение определит, что носитель более не требуется;

нераспознанный пул содержит новые носители, которые не были распознаны; как и в случае пула импорта, приложение может принять решение о перемещении носителя в пул приложения или в свободный пул.

Пул приложения содержит носители, созданные приложениями резервного копирования и удаленного хранилища.

В Windows 2000 была впервые представлена шифрованная файловая система (Encrypting File System – EFS), которая на самом деле является службой, размещенной уровнем выше NTFS. Эта служба обеспечивает шифрование данных перед их записью на диск и дешифрование после чтения, но перед передачей данных запросившему приложению. Кроме того, EFS реализует систему управления ключами, необходимыми для шифрации, а также клю-

чами восстановления, которые позволяют авторизованному объекту (кроме владельца файла) восстанавливать данные из файлов.

Данные шифруются симметричным шифром (в частности, одной из разновидностей DES), и случайно сгенерированный ключ, использованный для симметричного шифрования, записывается в файл после шифрования асимметричным шифром с помощью открытого ключа пользователя. Для обеспечения возможности по восстановлению файла (например, когда работник увольняется и отказывается сотрудничать) случайно сгенерированный ключ симметричного шифра также шифруется открытым ключом авторизованного объекта и записывается в файл.

Шифрованные файлы не могут быть сжаты, т.е. файл может быть или сжат или зашифрован – третьего не дано. Шифрованная файловая система обеспечивает сохранение шифрования, даже если доступ к диску будет осуществляться в обход NTFS и ее механизмов безопасности. Шифрованная файловая система может использоваться для файлов или для каталогов.

Дополнительная информация о шифрованной файловой системе приводится в главе 6.

Одна из проблем, долгое время мешавшая корректной работе Windows, была связана с повреждением и заменой системных файлов. Производители приложений обычно заменяли системные файлы Windows своими собственными или более новыми версиями. Такая практика в лучшем случае приводит к проблемам при управлении системой, а в худшем – к снижению ее надежности. Начиная с Windows 2000 компания Microsoft реализовала механизм защиты системных файлов (System File Protection – SFP).

Благодаря SFP определенные системные файлы защищены с помощью фонового механизма. Список контролируемых файлов сохраняется в папке кэша. Там же хранятся копии и других файлов. Если файл недоступен, он загружается с носителя (установочного компакт-диска Windows). Фоновый процесс вычисляет сигнатуру файла и сравнивает ее с сигнатурой файла, сохраненного в кэше. Если сигнатуры не совпадают, файл обновляется с помощью котированной копии. Утилиты установки пакетов обновлений и оперативных исправлений содержат специальный код, который позволяет обновлять как кэшированную, так и обычную копию файла.

В Windows Server 2003 сохранены сильные стороны предыдущих версий Windows NT и добавлены собственные возможности, относящиеся к подсисте-

Рис. 10.5. Возможности подсистемы хранения данных в Windows Server 2003 и будущих версиях

ме хранения данных. Чтобы проиллюстрировать объем работы, выполненный разработчиками Microsoft, обратите внимание на рис. 10.5.

Незакрашенные прямоугольники на рис. 10.5 демонстрируют возможности подсистемы хранения Windows Server 2003, рассматриваемые в этой главе. Закрашенные прямоугольники показывают компоненты, которые с высокой долей вероятности появятся в будущих версиях Windows Server. Конкретная версия будущей операционной системы еще не известна. Судя по сложившимся традициям Microsoft, возможно несколько вариантов.

Поставка вместе со следующей основной версией Windows NT (на данный момент она имеет кодовое наименование Microsoft Longhorn и будет выпущена в 2005 году).

Поставка в составе пакета Windows Resource Kit или пакета обновлений (Service Pack).

Поставка в виде обновления, доступного для загрузки с Web-узла Microsoft (например, через службу Windows Update).

Поставка через независимых производителей аппаратного и программного обеспечения; например, Microsoft предоставит соответствующий программный пакет партнерам, которые используют его в собственных системах.

Как отмечается в главе 1, Windows NT предоставляет уровень драйверов устройств, который позволяет достичь эффективного и масштабируемого ввода-вывода.

Дополнительная информация о стеке ввода-вывода Windows и всех его уровнях подробно описана в главе 1. Достаточно сказать, что одним из этих уровней является уровень драйверов порта. Драйвер порта отвечает за получение запросов ввода-вывода от верхних уровней, подготовку блоков команд SCSI и передачу запросов непосредственно устройству. Драйверы порта отвечают за хранение информации, которая позволяет осуществлять взаимодействие с устройством. Создавая блоки команд SCSI и обрабатывая результаты их выполнения, драйверы порта используют службы драйвера мини-порта, который создается производителем устройства.

До выхода Windows Server 2003 компания Microsoft предоставляла драйвер SCSIPort и оставляла производителям возможность создавать драйвер мини-порта SCSIPort, отвечающий за поддержку устройств Fibre Channel и SCSI. Отдельный установочный образ Windows NT мог содержать несколько драйверов мини-порта от различных производителей. Драйвер SCSIPort перенаправлял запросы соответствующему драйверу мини-порта.

При использовании этого подхода возникал ряд проблем.

В описываемой модели предполагается, что устройства Fibre Channel обладают возможностями, аналогичными функциям устройств SCSI, однако это не соответствует действительности, как и то, что новые устройства SCSI-3 подобны более старым устройствам SCSI.

Чтобы упростить задачу создания драйвера мини-порта, драйвер SCSIPort поддерживает однопоточную, а не дуплексную модель ввода- вывода. Это не позволяет системе достичь необходимой и возможной скорости обмена данными.

Драйвер порта содержал определенную информацию, которая не передавалась драйверу мини-порта, чтр требовало от него получения этих данных с помощью нескольких вызовов. В частности, это относится к спискам сборки/разборки.

Не желая мириться с ограничениями стандартной модели, производители устройств Fibre Channel создавали единый драйвер, в котором объединялись функции драйверов порта и мини-порта, или заменяли драйвер порта собственным драйвером. Поскольку этот процесс требовал тщательного анализа функций драйвера порта, такие попытки в лучшем, случае работали не совсем стабильно. Кроме того, ситуация еще более усложнялась, если возникала необходимость запустить драйвер мини-порта от одного производителя вместе с драйвером порта от другого производителя.

В Windows Server 2003 предоставлена новая модель драйверов Storport. Теперь от производителей адаптеров шины (НВА) ожидается создание драйвера мини-порта, который подключается к драйверу Storport, а не к драйверу SCSIPort. Чтобы минимизировать усилия по созданию новых драйверов, компания Microsoft сохранила обратную совместимость между моделями Storport и SCSIPort. Это позволяет производителям использовать некоторые (но не все) преимущества новой модели. Чтобы использовать все преимущества, производители должны заново переписать драйвер мини-порта, а не просто выполнить перекомпиляцию и подключить новую библиотеку.

Новая архитектура обладает перечисленными ниже преимуществами.

Модель Storport обеспечивает более высокую производительность за счет полнодуплексного ввода-вывода. Недостаток этого подхода состоит в том, что драйверу мини-порта требуется обрабатывать процедуру выполнения. Таким образом, высокое быстродействие достигается за счет повышенной сложности всей модели.

Модель Storport оптимизирует интерфейс между драйвером порта и драйвером мини-порта. Например, новый интерфейс позволяет драйверу мини-порта собирать информацию о списках сборки/разборки за один вызов, а не с помощью нескольких вызовов в цикле. Списки сборки/разборки – это универсальный термин,. описывающий ситуацию, когда ввод-вывод выполняется в несколько отдельных (и несмежных) буферов одновременно.

Модель Storport позволяет интерфейсу соответствовать запросам производителей высокоуровневых подсистем хранения, в частности производителей устройств RAID и Fibre Channel. Например, старая модель драйверов SCSIPort предоставляла слишком мало возможностей по управлению очередью, в то время как новым устройствам требуются более развитые механизмы управления. Модель Storport поддерживает до 254 запросов к одной логической единице адаптера. Максимальное количество запросов к адаптеру ограничивается только количеством логических единиц, подключенных к этому адаптеру.

Модель Storport поддерживает многоуровневую иерархию сброса для восстановления после ошибок. В старой модели при появлении ошибки выполнялось обнуление данных шины (что нарушало работу других устройств и приложений). В новой модели проводится минимально возможное обнуление (сначала LUN, затем целевое устройство и лишь в качестве последнего средства – обнуление шины).

Новая модель поддерживает отдельный расширенный интерфейс управления.

ш Новая модель предоставляет интерфейс, который не требует создания «фантомного» устройства. Модель SCSIPort не позволяла приложениям опрашивать возможности устройства без его монтирования. Поэтому производители создали фантомное устройство для ответа на определенные запросы. Модель Storport не требует создания фантомного устройства, поддерживая опрос даже без монтирования и подключения объекта мини-порта.

Все эти возможности предоставляются максимально незаметно благодаря обратной совместимости с моделью драйверов SCSIPort. Производители могут просто перекомпилировать существующий драйвер и подключить новую библиотеку. Это позволит работать с новой моделью драйверов, но не даст использовать полный спектр возможностей модели Storport. Устаревшие устройства SCSI могут продолжать работать, используя старый драйвер SCSIPort.

Более подробная информация по этой теме представлена в главе 2.

В Windows Server 2003 впервые представлена служба теневого копирования томов и связанная с ней инфраструктура. Теневые копии томов также называют «моментальными снимками» томов. Различная терминология используется для обеспечения сохранности прав на интеллектуальную собственность. Архитектура теневого копирования показана на рис. 10.6. Она включает в себя компоненты четырех типов, три из которых существуют в нескольких экземплярах.

Служба теневого копирования томов.

Модули записи теневого копирования.

Модули запроса теневого копирования.

Поставщики моментальных снимков.

Служба теневого копирования позволяет создавать целостные копии данных, действительные на определенный момент времени, и имеет ряд особенностей.

Рис. 10.6. Служба теневого копирования томов

Служба теневого копирования томов создана компанией Microsoft и предоставляет API приложениям резервного копирования, позволяющий запросить создание моментального снимка. Служба обеспечивает задержку операций ввода-вывода, обнуление кэшей и приостановку ввода-вывода системы и приложений, что позволяет создать копию тома в определенный момент времени.

Модули записи теневого копирования – это приложения, например Microsoft SQL Server или Microsoft Exchange, имеющие специальный код для интеграции в службу теневого копирования. Желательно, чтобы все приложения, включая базы данных и приложения планирования ресурсов уровня предприятия, предоставляли поставщика записи теневого копирования для интеграции со службой создания моментальных снимков. Компания Microsoft предоставляет такие модули для Active Directory, SQL Server и Microsoft Exchange.

Модули запроса теневого копирования – это приложения резервного копирования или приложения, которые инициируют создание копии тома, например копии данных для тестирования. Одни из этих модулей создаются компанией Microsoft, другие – независимыми разработчиками программного обеспечения. Приложения резервного копирования, которые предоставляются в Windows Server 2003, также являются модулями запроса теневого копирования.

Поставщики моментальных снимков – это компоненты, которые фактически создают моментальный снимок или копию тома. Компания Microsoft предоставляет поставщика, принятого по умолчанию, который создает копию тома с помощью метода копирования при записи. Ожидается, что производители систем хранения будут создавать собственных поставщиков для создания моментальных снимков. Архитектура допускает использование различных схем для создания моментального снимка, включая разбивку зеркала на аппаратном уровне.

Обратите внимание, что инфраструктура, разработанная Microsoft, позволяет создавать только один моментальный снимок. Тем не менее она соответствует требованиям независимых производителей программного обеспечения, так как предоставляет возможность управления несколькими моментальными снимками и позволяет монтировать моментальные снимки только для чтения.

Дополнительная информация о службе теневого копирования томов приведена в главе 5. Набор SDK для службы теневого копирования томов доступен от компании Microsoft при условии подписания соглашения о неразглашении.

Служба виртуального диска (Virtual Disk Service – VDS) представляет собой интерфейс управления, интегрированный в Windows Server 2003 и предназначенный для предоставления уровня абстракции при виртуализации дисков независимо от ресурса виртуализации.

Перед описанием архитектурных особенностей VDS стоит рассмотреть причины появления этой службы. Основным мотивом была необходимость в предоставлении администратору возможности автоматизированного и ручного управления следующими операциями:

формирование тома хранилища, создание на его основе массива RAID 5 объемом не менее 10 Гбайт;

формирование тома хранилища, увеличение его объема до 10 Гбайт и создания простого тома без возможностей массива RAID.

Другими словами, администратор должен иметь возможность выделять хранилище под моментальные снимки, резервировать снимок и освобождать хранилище, возвращая его в пул свободных хранилищ. Служба виртуального диска предоставляет метод выполнения этих задач независимо от уровня виртуализации и применяемого аппаратного обеспечения, а также различных вариантов подключения устройств хранения.

Рис. 10.7. Служба виртуального диска

На рис. 10.7 показана архитектура службы виртуального диска. Закрашенные прямоугольники представляют компоненты, созданные компанией Microsoft и поставляемые в составе операционной системы. Ожидается, что независимые производители аппаратного обеспечения будут создавать аппаратных поставщиков VDS. Служба виртуального диска предоставляет уровень абстракции, что позволяет создавать приложения управления на основе единого интерфейса, вне зависимости от характеристик аппаратного обеспечения на нижних уровнях. Кроме того, VDS дает возможность не вносить изменения в программное обеспечения управляющих приложений, даже если после выхода приложения будет выпущено новое аппаратное обеспечение. Производители аппаратного обеспечения для хранилищ данных могут быть уверены, что их новые системы будут должным образом инициализированы и получат управление посредством VDS.

Компания Microsoft предоставляет двух поставщиков VDS, которые работают с базовыми и динамическими дисками (базовые и динамические диски рассматриваются в главе 6).

Ожидается, что производители аппаратного обеспечения хранилищ также будут создавать поставщиков VDS. Каждый поставщик – это сервер СОМ, вызываемый VDS. От аппаратных поставщиков ожидается реализация следующих функций:

обнаружение LUN;

создание, уничтожение и другие операции по управлению LUN;

создание объектов СОМ для LUN, контроллеров хранилища, накопителей и даже самих поставщиков;

удаленный доступ, обеспечивающий запуск управляющего приложения на рабочей станции и связь этого приложения со службой виртуального диска, работающей на сервере.

На данный момент интерфейсы, необходимые для создания поставщиков, передаются компанией Microsoft после подписания соглашения о неразглашении. Дополнительная информация о службе виртуального диска приведена в главе 7.

Групповой ввод-вывод необходим для обеспечения надежности серверов под управлением семейства Windows NT. Он был впервые представлен в Windows Server 2003 и доступен в Windows 2000 после установки пакета обновлений SP2 и более поздних версий пакетов обновлений. Компания Microsoft предлагает инструментарий разработки для группового ввода-выво- да производителям компьютеров и независимым поставщикам аппаратного/программного обеспечения, которые могут использовать этот инструментарий для создания собственных систем, предназначенных для конечных пользователей. Ниже приведены характеристики этих систем.

Поддерживаются Windows 2000 и Windows Server 2003.

Достаточно сложная архитектура включает в себя три драйвера от Microsoft и один мини-драйвер, созданный производителем.

Предоставляется возможность сохранения целостности данных, восстановления целостности и балансировки нагрузки. Кроме того, для одной единицы хранения поддерживается до 32 маршрутов.

Архитектура основана на уведомлениях РпР и не требует статического определения конфигураций.

Архитектура совместима с Microsoft Cluster Server.

В функции созданного производителем мини-драйвера (Device Specific Module – DSM) входит следующее:

идентификация различных маршрутов к одной единице хранения;

назначение начального маршрута (с использованием балансировки нагрузки, предпочтительного маршрута или с помощью другого алгоритма);

принятие решения о необходимости повтора ввода-вывода, если возникла ошибка;

принятие решения о выполнении операции сохранения целостности данных, при которой выбирается альтернативный маршрут;

определение условий, при которых следует выполнить операцию восстановления целостности;

выполнение инициализации, сйецифичной для устройства;

обработка команд выборки, например Reserve и Release, а также принятие решения об отправке команд по всем маршрутам или по одному из них.

Групповой ввод-вывод рассматривается в главе 9.

В Windows 2000 ряд инструментов управления используются как в командной строке, так и помощью графического интерфейса. В Windows Server 2003 эта тенденция сохранилась и несколько утилит командной строки позволяют выполнять следующие операции:

управлять возможностями файловой системы, включая дефрагмента- цию;

управлять службой теневого копирования томов;

управлять томами;

управлять службами удаленного хранилища.

Кроме того, в Windows Server 2003 для предоставления информации о производительности и управлении системой активно используется интерфейс WMI. Все больше подсистем операционной системы модифицируются для предоставления информации управляющим приложениям через интерфейс WMI. Примерами таких подсистем являются драйверы Storport, служба теневого копирования томов и распределенная файловая система.

Читателям, знакомым с UNIX, давно известно, что в Windows отсутствует эквивалент таблицы монтирования UNIX. Таким образом, Windows стремится монтировать каждый обнаруженный том. Если файловая система тома не распознается, владение томом принимает на себя «чистая» файловая система. Перед подключением сервера под управлением Windows к сети хранения данных администратору следует внимательно настроить маскировку LUN, зонирование и другие методы управления, чтобы сервер под управлением Windows воспринимал только единицы хранилища, доступ к которым разрешен (и принадлежащие этому серверу). В Windows Server 2003 эта ситуация изменилась.

Компания Microsoft изменила драйвер диспетчера монтирования (он рассматривается в главе 6), улучшив поддержку среды SAN. В частности, драйвер диспетчера монтирования может быть настроен на монтирование только тех томов, которые монтировались ранее, тогда как все новые тома будут игнорироваться. Самый простой способ управления параметрами конфигурации – использование утилиты командной строки mountvol.

В Windows Server 2003 существует ряд возможностей, которые позволяют независимым производителям программного обеспечения создавать эффективные приложения для управления хранилищами в йреде SAN. Некоторые из них описаны далее.

ш Можно монтировать тома только для чтения.

Приложения могут использовать новые API, которые вместе со службой теневого копирования томов позволяют приложениям выполнять чтение указанного моментального снимка тома. Таким образом, независимые производители аппаратного обеспечения имеют возможность создавать приложения, использующие многоуровневые зеркала и проверяющие целостность данных.

Новый API позволяет приложениям указывать действительную длину файла. Таким образом, независимые производители программного обеспечения могут создавать распределенную файловую систему, а также приложения резервного копирования и восстановления, записывающие копии уровня блоков на диск и затем устанавливающие действительную длину файла.

Администраторы могут управлять томами с использованием привилегий безопасности более низкого уровня.

Добавлены новые интерфейсы, которые позволяют создателям драйверов фильтрации увеличивать функциональность управления. Создатели драйверов фильтрации файловых систем могут также использовать улучшенное управление «кучей» памяти (heap) и процедуры управления объектами устройств, а также новые процедуры управления безопасностью. Кроме того, предоставляются новые интерфейсы управления томами.

В Windows Server 2003 в файловую систему NTFS были внесены существенные изменения:

производительность NTFS выросла на 10–15%;

значительно расширились возможности API, отвечающего за дефраг- ментацию;

NTFS стала поддерживать монтирование томов в режиме только для чтения;

усилены списки управления доступом, принятые по умолчанию, что позволило обеспечить большую безопасность.

В Windows Server 2003 используется интерфейс дефрагментации, который поддерживается подсистемой ввода-вывода Windows в целом и NTFS в частности. Вот некоторые из улучшений системы дефрагментации:

поддерживается дефрагментация главной таблицы файлов NTFS (MFT), перемещение записей MFT, даже если файл, соответствующий записи в MFT, открыт другим приложением;

шифрованные файлы могут дефрагментироваться без открытия и чтения, что позволяет усилить безопасность;

несжатые файлы дефрагментируются по границе дисковых кластеров, а не по границе страницы памяти;

файловая система NTFS поддерживает дефрагментацию файлов, даже если размер кластера превышает 4 Кбайт;

файловая система NTFS поддерживает дефрагментацию не только неименованных потоков данных, но и точек повторной обработки и атрибутов файлов.

Шифрованная файловая система была впервые представлена в Windows 2000 и существенно улучшена в Windows Server 2003. Далее описываются основные нововведения.

В Windows Server 2003 с помощью EFS поддерживается доступ нескольких пользователей к одному файлу. Шифрованная файловая система применяет симметричный алгоритм шифрования (один и тот же ключ используется для шифрации и дешифрации); симметричный ключ шифруется асимметричным ключом. В частности, симметричный ключ шифруется открытым ключом пользователя и сохраняется в том же файле. В Windows Server 2003 допускается хранение в файле нескольких копий симметричного ключа, зашифрованных открытыми ключами различных пользователей.

Поддерживается полная проверка по списку отозванных пользовательских сертификатов. Это позволяет ограничить доступ тем пользователям, которые ранее имели доступ к файлам.

Поддерживается большее количество алгоритмов шифрования. Для этого применяются поставщики служб шифрования.

Допустимо сквозное шифрование поверх WebDAV. В Windows 2000 перед передачей по сети через интерфейс WebDAV содержимое файлов расшифровывалось. В Windows Server 2003 дешифрация проводится локально на клиенте.

Допускается. хранение в зашифрованном виде автономных файлов. В Windows 2000 шифрование кэша автономных файлов не поддерживалось.

Шифрованные файлы могут сохраняться в Web-папке.

Системой управления иерархическим хранилищем (HSM), поддерживаемой службами RSS в Windows 2000, в качестве вторичного носителя допускалось использование только накопителя на магнитной ленте (служба RSM в Windows 2000 поддерживает и другие носители, например оптические накопители, ленточные магазины и автоматы). В Windows Server 2003 предоставляется поддержка и других носителей для HSM.

Операционные системы Windows ХР и Windows Server 2003 оптимизированы для сокращения времени их загрузки. Считывая файлы с диска загрузчик (ntldr) использует по одной операции ввода-вывода на файл. Кроме того, операционная система перекрывает ввод-вывод данных на диск инициализацией устройств, а также откладывает инициализацию системных процессов и служб, которые не важны в процессе загрузки.

Повышению. надежности Windows 2000 способствовало сокращение количества ситуаций, при которых необходим запуск утилиты CHKDSK. Кроме того, сокращено время, необходимое CHKDSK для завершения работы. Эта же тенденция сохранилась и в Windows Server 20,03. Во время проведения теста с тремя миллионами файлов завершение работы утилиты CHKDSK на сервере под управлением Windows Server 2003 заняло в 12 раз меньше времени, чем на сервере под управлением Windows 2000.

В Windows ХР тесты производительности ввода-вывода показали, что скорость обмена данными с дисками SCSI намного ниже аналогичных показателей в Windows 2000. И это связано с очень интересной проблемой.

Операционная система и производители жестких дисков поддерживают функции кэширования для повышения производительности и пропускной способности подсистемы ввода-вывода. В Windows NT существует диспетчер кэша, который предоставляет эти функции всем файловыми системам. Кроме того, некоторые жесткие диски также обеспечены быстродействующей кэш-памятью. Хотя кэширование и позволяет повысить быстродействие, данные записываются в кэш, а не на носитель. Если данные не будут вовремя перенесены из кэша на носитель, они могут быть потеряны. Чтобы предоставить приложениям возможность управлять кэшем, Windows NT поддерживает описанные ниже операции.

Приложение может указать параметр FILE_FLAG_WRITE_THROUGH при вызове функции CreateFile; это говорит о запрете завершения операции записи до записи данных на диск. От драйверов Windows NT ожидается передача этой функции устройствам хранения с помощью флага SCSI Force Unit Access (FUA). С помощью флага FUA, определенного в стандартах SCSI, кэширование отключается для отдельных операций ввода-вывода.

Приложение может указать параметр FILE_FLAG_N0_BUFFERING при вызове функции CreateFile, что указывает на запрет кэширования на уровне файловой системы.

¦ Приложение может использовать функцию FlushFileBuf f ers для сброса всех данных открытого дескриптора файла из системного кэша и отправки жесткому диску сигнала о необходимости обнуления собственного кэша. Обратите внимание: вопреки названию функции, сбрасываются все данные, находящиеся в кэше жесткого диска.

Проблема заключается в том, что операционная система некорректно обрабатывала запросы приложений на отказ от кэширования и Windows Server 2003 стала первой системой семейства Windows, которая полноценно работает с запросами сквозной записи. Это означает, что показатели производительности Windows NT 4.0 и Windows 2000 были искусственно завышены. Кроме того, некоторые администраторы применяли утилиту настройки от производителя хранилища данных, которая позволяла отключать кэш накопителя. Но в этом случае существуют и другие сложности, описанные далее.

В Windows ХР ошибка исправлена для базовых, но не для динамических дисков. Таким образом, некоторое время складывалось впечатление, что компания Microsoft не спешила в полной мере поддерживать динамические диски. Концепция базовых и динамических дисков, описывающая запись на диск информации о логической структуре диска, рассматривается в главе 6.

В некоторых книгах издательства Microsoft Press авторам приложений некорректно рекомендовалось использовать флаг FILE_FLAG_WRITE_ THROUGH функции CreateFile в тех случаях, когда требовалась более высокая производительность. Компания Microsoft пообещала исправить собственные приложения, утилиты и инструменты, удалив флаг FILE_ FLAG_WRITE_THR0UGH для достижения максимальной эффективности. Кроме того, предполагалось создать уровень совместимости приложений, позволяющий должным образом работать тем приложениям, которые еще не были модифицированы для удаления параметра FILE_FLAG_ WRITE. THROUGH.

Для повышения надежности Windows Server 2003 использован механизм восстановления после критических отказов в работе. В частности, сервер может быть восстановлен после отказа в работе диска в одно действие, которое приведет к восстановлению всей информации операционной системы и системных данных. Автоматическое восстановление системы основано на службе теневого копирования томов и требует наличия дисковода для гибких дисков.

Впервые распределенная файловая система стала доступна в Windows NT 4.0 и была заметно модифицирована в Windows 2000. В Windows Server 2003 она также была несколько усовершенствована.

Реализована поддержка распределенной файловой системой нескольких корней. Это означает, что компания может объединить различные ресурсы в общее пространство имен, при этом сохраняя несколько пространств имен для обеспечения безопасности и упрощения администрирования. Эта возможность будет особенно востребована в больших корпорациях, организационная структура которых состоит из нескольких подразделений (например, компания – разработчик программного обеспечения может поставлять как обычные клиентские программы, так и системы для обеспечения безопасности). Кроме того, новые возможности DFS понадобятся после приобретёния компании другой корпорацией, причем после слияния предполагается раздельное администрирование корпоративных ресурсов двух компаний.

Улучшена репликация файлов.

Улучшена балансировка нагрузки.

Пользователи могут выбирать серверы, которые физически расположены ближе, что позволяет повысить производительность.

Серверы и клиенты под управлением Windows 2000 предоставляли различные способы подключений, в том числе поддержку систем CIFS, NFS, NetWare и Macintosh. В Windows Server 2003 добавлен клиент WebDAV (Web Distributed Authoring and Versioning). Это стандартный протокол, который позволяет использовать HTTP в качестве основного транспортного механизма. Например, пользователь, получающий файл Excel с сервера, может не подозревать об использовании протокола CIFS, но для этой же цели можно применять и протокол WebDAV.

В Windows Server 2003, как и в Windows ХР, создателям драйверов предоставляется расширенный инструментарий. Кроме того, ужесточена процедура тестирования и проверки на соответствие стандартам Windows, что сделало драйверы более надежными. Создатели драйверов не только получают расширенный инструментарий и дополнительную информацию, но и доступ к обратной связи, что позволяет отлаживать существующие драйверы и создавать новые версии.

Ассоциация SNIA определила API на языке С, который позволяет приложениям управления хранилищем администрировать адаптеры шины Fibre Channel. Этот интерфейс поддерживает запрос и назначение параметров конфигурации адаптера шины, а также измерение параметров производительности адаптера.

Хотя Microsoft и члены ассоциации SNIA поддерживают одинаковый API адаптера шины, используемые подходы несколько различаются. Архитектура, предложенная SNIA (рис. 10.8), включает три обязательных компонента.

Рис. 10.8. Программный интерфейс адаптера шины от ассоциации SNIA

Универсальная динамически подключаемая библиотека API адаптера шины, поддерживаемая SNIA. В ней предоставляется стандартный интерфейс для приложений управления. На нижнем уровне библиотека взаимодействует с различными библиотеками, созданными производителями устройств.

Динамически подключаемая библиотека от производителя адаптера, которая подключается к DLL программного интерфейса адаптера шины. Библиотека от производителя предоставляет информацию для управления и взаимодействует с драйвером производителя посредством закрытых вызовов управления вводом-выводом.

Драйвер устройства, созданный производителем для данного адаптера шины.

Хотя такой подход обладает определенными преимуществами, компания Microsoft отмечает некоторые связанные с ним проблемы.

¦ Невозможно эффективно управлять распространением и учетом версий динамически подключаемых библиотек. Это еще один пример ситуации, когда несколько приложений устанавливают собственные библиотеки, потенциально перезаписывая библиотеки, установленные другими приложениями.

ш Производитель адаптера шины должен создать не только драйвер устройства и закрытый интерфейс управления вводом-выводом для этого драйвера, но и собственную динамически подключаемую библиотеку, а также внести определенные изменения в библиотеку – оболочку

адаптера шины, чтобы предоставить необходимые интерфейсы созданной DLL.

Тестирование и сертификация драйверов производителей, в которых используются закрытые вызовы управления вводом-выводом, представляет собой исключительно сложный процесс; например, как можно проверить, что некорректные параметры вызова управления вводом-выводом не приведут к переполнению буфера?

Архитектура на первый взгляд выглядит расширяемой, но при более детальном рассмотрении очевидно, что производители адаптеров шины всегда будут «догонять» разработчиков приложений управления, добавляя код, который работает с расширениями, характерными для определенного производителя.

Не поддерживается связь и управление в режиме ядра. В архитектуре SNIA требуется, чтобы приложение управления ожидало момента полной работоспособности подсистемы пользовательского режима Windows NT. Но для некоторых операций управления, например для маскировки LUN, необходимо наличие драйвера в режиме ядра, который будет выполнять определенные действия в процессе загрузки операционной системы еще до того, как будет запущена подсистема пользовательского режима.

Компания Microsoft предлагает несколько иной метод, который демонстрируется на рис. 10.9 и описан ниже.

Рис. 10.9. Программный интерфейс адаптера шины от компании Microsoft

Универсальная динамически подключаемая библиотека программного интерфейса приложений для адаптера шины от ассоциации SNIA. Эта DLL предоставляет интерфейс для приложений управления более высокого уровня. На более низком уровне библиотека подключается к интерфейсу WMI, который представляет собой реализацию модели CIM (Common Information Model) от Microsoft. Как уже отмечалось, CIM – это объектно-ориентированная модель управления, принятая ассоциацией SNIA и рабочей группой DMTF.

Драйвер устройства для адаптера шины, созданный производителем; этот драйвер реализует интерфейс WMI и предоставляет интерфейс управления и настройки в репозитории WMI. Поскольку WMI является двунаправленным интерфейсом, драйвер обеспечивает поддержку функций пакетов IRP для WMI, что позволяет приложению управления устанавливать конфигурационные параметры драйвера.

Динамически подключаемая библиотека, которая осуществляет преобразование данных между интерфейсом WMI и API адаптера шины от SNIA.

Метод Microsoft обладает определенными преимуществами.

Все представленные интерфейсы стандартизированы, тогда как при использовании схемы SNIA интерфейс между универсальной библиотекой НВА API и библиотекой производителя закрыт и определяется производителем. Метод Microsoft соответствует общепринятой модели CIM.

Поддержка расширяемости, так как производитель может расширить класс WMI или определить новый класс и поместить в нем управляющую информацию. В данном случае также прослеживается соответствие модели CIM.

Основным преимуществом является возможность использования модели CIM или API адаптера шины от ассоциации SNIA. Если приложение использует API адаптера шины от SNIA, оно может работать без изменений, так как код WMI драйвера и DLL от Microsoft преобразуют информацию WMI в данные API адаптера шины от SNIA.

Описанная архитектура позволяет компоненту режима ядра опрашивать драйвер производителя и выполнять управляющие действия.

Обратите внимание, что интерфейсы WMI, необходимые для создания драйвера адаптера шины, предоставляются в Windows 2000.

Существует разновидность Windows Server 2003 для 64-разрядных процессоров, которая поддерживает промышленный стандарт EFI (Extensible

Firmware Interface). Этот стандарт стал заменой устаревших программ BIOS, которые до сих пор используются в индустрии персональных компьютеров.

Стандартом EFI определяется таблица разделов GUID (GUID Partition Table – GPT). Точная структура таблицы GUID (Globally Unique Identifier – глобально-уникальный идентификатор) рассматривается в главе 16 спецификации EFI, которая доступна по адресу: http://developer. intel. com/technology/efi/download.htm.

Диск с GPT может иметь до 264 логических блоков. В спецификации EFI используется термин логический блок (logical block) для описания того, что обычно называется дисковым кластером (disk cluster) – наименьшей единицей выделения дискового пространства. Поскольку в EFI указывается размер логического блока, равный 512 байт, максимальный размер диска составляет 18 Эбайт. Диск с GPT может иметь любое количество разделов, как и динамический диск. Кроме того, наравне с динамическими дисками, диск GPT обладает самоописанием, т.е. сведения о логической структуре диска размещены на самом диске. Диски GPT хранят информацию о разделах избыточным образом, что позволяет добиться устойчивости к ошибкам. В то время как диски GPT являются промышленным стандартом, динамические диски Windows 2000 – стандарт закрытый. Правда, по сравнению с компьютерами, использующими BIOS, выпущено сравнительно мало компьютеров, поддерживающих стандарт EFI.

Чтобы сохранить от повреждения данные на диске GPT при подключении к устаревшим системам, на диске содержится главная загрузочная запись (MBR), описывающая весь диск. Таким образом, компьютер на основе BIOS получит сведения о разбивке диска на разделы.

Загрузочные диски GPT имеют новый тип раздела, который называется системный раздел EFI (EFI System Partition – ESP). Этот раздел содержит файлы, необходимые для загрузки операционной системы, например ntldr, hal. dll, boot. txt и драйверы. Раздел ESP может располагаться на диске GPT или MBR, как указано в спецификации EFI. Операционная система Windows Server 2003 для 64-разрядных процессоров требует, чтобы раздел ESP находился на диске GPT.

Кроме того, существует еще один тип раздела –зарезервированный раздел Microsoft (Microsoft Reserved Partition – MSR). Диски GPT запрещают использование скрытых секторов, поэтому для компонентов, которые раньше использовали скрытые секторы, предназначен раздел MSR. Он создается при первой разбивке диска у производителя компьютера или при установке Windows Server 2003. На дисках объемом менее 16 Гбайт раздел MSR не превышает 32 Мбайт. Для дисков объемом более 16 Гбайт используется раздел MSR, объем которого составляет 128 Мбайт.

Следует подчеркнуть, что реализация спецификации EFI cMntel предлагается только для компьютеров с 64-разрядной архитектурой центрального процессора. Хотя стандартом и не запрещено создание 32-разрядной версии EFI, таковой не существует. Таким образом, реализация кода нижнего уровня и кода загрузки Windows для 32- и 64-разрядной платформ будет иметь существенные отличия.

Версия Windows Server 2003 для 64-разрядной архитектуры должна загружаться с диска GPT, причем доступ к старым дискам сохраняется (однако загрузка с них не поддерживается). В Windows Server 2003 для 32-разрядной архитектуры используются диски формата MBR.

Не желая почивать на лаврах после внесения в семейство Windows NT описанных возможностей по работе с подсистемами хранения, компания Microsoft разрабатывает новые технологии для следующей после Windows Server 2003 системы. В частности, речь идет о модификации стека iSCSI и дальнейшем усовершенствовании инфраструктуры управления хранилищем.

Эта служба уже рассматривалась ранее; в ней реализована попытка предоставить единый интерфейс для управления коммутаторами связной архитектуры. Такой интерфейс не должен зависеть от производителя коммутатора, модели коммутатора и его возможностей.

Рассмотрим последовательность действий системного администратора для проведения резервного копирования.

Создание тома (может потребоваться управление дисками или массивами RAID).

Обеспечение доступности тома для механизма создания моментальных снимков (может потребоваться перенастройка зонирования).

Создание моментального снимка.

Том с моментальным снимком делается доступным для сервера резервного копирования.

Проведение резервное копирования.

Возвращение снимка в пул свободных ресурсов хранилища, для чего может также потребоваться дополнительная настройка коммутатора и LUN.

Обычно все происходит таким образом: администратор хранилища выполняет часть действий вручную, запускает программное обеспечение, выполняет еще несколько ручных операций, запускает другое программное обеспечение и т.д.

Служба виртуализации связной архитектуры при использовании с VDS (см. раздел 10.3.3) позволяет полностью автоматизировать эти задачи. Служба виртуализации не имеет обозначенной даты выпуска, и Microsoft по-преж- нему не дает сведений на эту тему.

Операционная система Windows NT исключительно «агрессивно» реализует поддержку подсистемы хранения, монтируя диск сразу после его обнаружения. С каждого обнаруженного диска считывается таблица разделов, после чего монтируются найденные файловые системы. При такой схеме вероятность повреждения данных достаточно велика.

Во время работы над этой книгой функциямаскировки LUN поддерживалась сторонними производителями аппаратного и программного обеспечения, но отсутствовала в Windows. Одной из проблем, связанных с использованием этих функций, является возможное отключение загрузки соответствующего драйвера или утилиты стороннего производителя, когда операционная система загружается в безопасном режиме. Таким образом, вероятность повреждения данных все равно остается. Маскировка LUN поддерживается и аппаратным обеспечением, например массивами RAID или коммутаторами Fibre Channel, однако возможность программного управления отсутствует. Обычно аппаратное обеспечение предоставляется с графической утилитой управления, которую можно запускать удаленно.

В будущих версиях Windows NT ожидается реализация маскировки LUN в рамках стека драйверов Microsoft, в частности в драйвере Storport.

Что касается заявлений с последней торговой конференции (WinHEC), от Microsoft ожидается предоставление следующих возможностей:

вызовы управления вводом-выводом, которые позволят приложениям управлять маскировкой LUN;

список включения, настраиваемый вызовами управления вводом-выводом (IOCTL); должен содержать устройства, которые будут предоставляться приложениям;

¦ возможность обхода маскировки LUN[23].

Во время подготовки этой книги к печати появилась информация, что Microsoft работает над реализацией маскировки LUN в драйвере порта. Преимущество переноса такой функции в драйвер порта состоит в обязательной загрузке драйвера, что значительно сокращает возможность обхода маскировки LUN. Вероятность загрузки некорректного драйвера порта намного ниже вероятности загрузки некорректного драйвера мини-порта.

Не следует предполагать, что все производители аппаратного обеспечения предоставляют одинаковые возможности по динамической конфигурации любого типа порта. Одни устройства обладают встроенными функциями по переконфигурированию портов «на лету», без перезагрузки и отключения питания, в то время как другим для этого требуется модернизация прошивки или замена платы расширения для определенного порта, что может потребовать отключения питания.

Протокол iSCSI стал попыткой реализации блочного хранилища поверх существующей централизованной сетевой инфраструктуры. Хотя от iSCSI не ожидается такой производительности, как от других технологий взаимодействия с хранилищами данных, например Fibre Channel, основное внимание уделяется системам, которым не требуется высокая производительность и понадобится существующая сетевая инфраструктура. Ожидается создание аппаратных ускорителей для стека протоколов TCP/IP, в которых накладные расходы на обработку определенных протоколов переносятся с центрального процессора сервера на специальное аппаратное обеспечение сетевой карты, что будет только способствовать распространению протокола iSCSI.

Компания Microsoft дала понять, что ведется активная реализация протокола iSCSI, которая со временем станет доступной в Windows NT. Определенной даты не сообщалось; предположительно поддержка iSCSI будет обеспечена до выхода Windows Longhorn в 2005 году.

На рис. 10.10 представлена архитектура реализации протокола iSCSI в Windows NT. Инициатор iSCSI реализован в виде драйвера мини-порта, который может работать как под управлением драйвера SCSIPort, так и под управлением драйвера Storport.

Рис. 10.10. Архитектура протокола iSCSI в Windows NT

Библиотека обнаружения динамически отслеживает все изменения и работает как единый репозиторий для всех LUN, обнаруженных любым способом, включая уведомления клиента или порта службой iSNS (Internet Storage Name Service). Библиотека обнаружения предоставляет API для приложений управления, который может использоваться для обнаружения новых LUN и, если возможно, регистрации в обнаруженной LUN.

Планы Microsoft по реализации протокола iSCSI включают несколько пунктов.

Основное внимание будет уделяться реализации протокола iSCSI в Windows Server 2003. Ожидается, что iSCSI будет доступен в Windows 2000 и Windows ХР.

Будет предоставлен код для сервера и клиента iSNS.

В качестве основного механизма защиты будет использоваться протокол IPSec.

Особое внимание получит реализация инициатора iSCSI. На данный момент не существует-планов по реализации целевого устройства iSCSI для Windows NT.

Передача информации между библиотекой обнаружения и инициатором iSCSI будет осуществляться с помощью интерфейса WMI.

Кроме того, драйвер порта предоставляет маршрут взаимодействия с ми- ни-портом НСА, а также диспетчерами InfiniBand, например диспетчерами подсетей и подключений. Диспетчер подсети отвечает за управление топологией связной архитектуры через программирование коммутаторов и установку атрибутов НСА. Кроме того, диспетчер подсети предоставляет точку соединения политик управления, связанных с управлением доступом, производительностью и устойчивостью к ошибкам (групповой ввод-вывод). Диспетчер подключений реализует возможности InfiniBand, ориентированные на подключения, а также основанные на политиках методы сохранения целостности данных.

Групповой ввод-вывод данных поддерживается в Windows 2000 и Windows Server 2003. Компания Microsoft предоставляет производителям инструментарий разработки, поэтому готовые системы доступны только у определенных компаний. Ожидается, что Microsoft внедрит поддержку группового ввода- вывода и для сменных носителей (на данный момент поддерживаются только жесткие диски). Поэтому часть прямоугольника группового ввода-вывода на рис. 10.5 закрашена другим цветом.

Компания Microsoft признала необходимость добавления некоторых возможностей, но никак не обозначила намерения по их реализации. В этом разделе рассматривается ряд технологий и делается попытка прогноза их дальнейшего развития.

Операционная система Windows 2000 поддерживает загрузку через SAN, но в этом процессе существует множество «подводных камней». Компания Microsoft обеспечивает ограниченную поддержку загрузки через SAN. В частности, существуют описанные ниже проблемы.'

Все используемое программное и аппаратное обеспечение должно быть совместимо с Windows 2000.

Невозможно использовать кольцо Fibre Channel с разделением доступа (Fibre Channel Arbitrated Loop – FC-AL), так как в ядро Windows NT

не вносились изменения, позволяющие обрабатывать значительные задержки среды FC-AL при повторной инициализации кольца.

Операционная система Windows 2000 требует эксклюзивного доступа к LUN, с которого проводится загрузка. Соответствующая маскировка выполняется на коммутаторе или через управление адаптерами шины.

Поставщик оборудования сети SAN должен принимать участие в процессе планирования и гарантировать поддержку в случае возникновения каких-либо проблем.

Рекомендуется держать файл подкачки на локально^ жестком диске.

Практически все системы требуют отключения группового ввода-вывода в процессе загрузки.

Поддержка загрузки через SAN в операционной системе имеет множество преимуществ. В частности, уменьшится задержка передачи данных в сети. Использование протокола iSCSI позволит выполнять удаленную загрузку по сети хранения данных с помощью платы Gigabit Ethernet. Кроме того, неплохо бы иметь возможность маскировки LUN на ранних этапах загрузки операционной системы.

Модель драйверов Windows NT построена на принципах модульности и использует несколько уровней, что позволяет задействовать любые необходимые драйвера. Возможно, модель слишком успешно реализует поставленную задачу. Обычный сервер под управлением Windows 2000 применяет около десятка драйверов между приложением и физическим устройством. Рассмотрим набор драйверов в стеке:

драйвер мини-порта Storport или SCSIPort;

драйвер порта Storport или SCSIPort;

драйвер класса диска;

драйвер LDM, который на самом деле включает в себя несколько драйверов;

драйвер diskperf;

драйвер фильтрации антивирусного сканера;

драйвер файловой системы;

драйвер фильтрации файловой системы, который также может состоять из нескольких драйверов, например драйверы фильтрации точек повторной обработки удаленного хранилища, SIS, символьных ссылок и EFS.

Возможно, исправить ситуацию поможет добавление функций одного драйвера в другой. В Windows ХР предоставлен ограниченный механизм обратного вызова для драйверов фильтрации. Остается лишь наблюдать за развитием этой тенденции.

Набор разработки для систем группового ввода-вывода не поддерживает работу с iSCSI. С расширением сферы применения iSCSI существует вероятность, что Microsoft предоставит отказоустойчивые и высокопроизводительные модули поддержки iSCSI.

Компания Microsoft намерена превратить Windows в полноценную платформу для организации хранилищ данных. Возможности новых версий Windows NT ясно подчеркивают эту тенденцию. Безусловно, Microsoft будет играть важную роль в индустрии корпоративных систем хранения данных.

Менеджерам компаний, принимающим решения о закупках, стоит обратить внимание на возможности, связанные только с Windows Server 2003 и Windows 2000. Поэтому следует внимательно просмотреть планы независимых производителей аппаратного и программного обеспечения по поддержке этих операционных систем.

С развитием платформы Windows NT существенно улучшалась поддержка подсистем хранения данных. Операционные системы Windows NT 4.0 и Windows 2000 предоставляли все больше средств для обеспечения надежности, масштабируемости и отказоустойчивости. Операционная система Windows Server 2003 предлагает новые возможности по обеспечению отказоустойчивости (групповой ввод-вывод), производительности (модель драйверов Storport) и управлению (служба виртуального диска, поддержка приложений и диспетчер монтирования SAN, интерфейс управления на основе командной строки). После выхода Windows Server 2003 компания Microsoft планирует добавить расширенную поддержку протокола iSCSI в линии операционных систем Windows NT.

Примечания:

2

Строго говоря, это не просто обработчик прерываний, однако в данный момент не будем углубляться в детали, поэтому далее обработчик прерываний будет именоваться просто прерыванием.

22

Компания Microsoft указывает на тот факт, что согласование функций, доступных в новой версии Windows, осуществляется на основе множества факторов, поэтому наличие в ней тех или иных возможностей не гарантируется. Оптимальный вариант заключается в изучении функций операционной системы только после выпуска ее окончательной версии.

23

Не зная подробностей реализации, можно предположить, что этим будет заниматься один из компонентов ядра. Это не несет в себе угрозы безопасности, так как философия Windows заключается в доверии программному обеспечению, работающему на уровне ядра, и в ограничении возможностей по установке программного обеспечения для данного режима. Таким образом, администратор может использовать только проверенное и заведомо надежное программное обеспечение.