Когда клиенту предоставляется исключающая oplock, он может буферизи-ровать блокированную информацию, выполнять опережающее чтение и записывать данные на клиентской стороне общения, так как знает, что к файлу не будет других средств доступа. Это происходит следующим образом. Редиректор на клиенте открывает файл, запрашивая для клиента oplock. Если файл открыт кем-то другим, клиенту отказывают в oplock, и на локальном клиенте никакой локальной буферизации выполняться не может. Это означает также, что на файле не может выполняться никакого опережающего чтения, если только редиректор не знает, что он имеет блокированный диапазон опережающего чтения. Если сервер предоставляет исключающую oplock, клиент может выполнить некоторую оптимизацию для файла, например блокирование буферизации, чтение и запись данных.
Как можно видеть, когда клиент А открывает файл, он может запросить исключительную блокировку оріоскв. Если больше никто не открыл этот файл на сервере, то оріоск предоставляется клиенту А. Если в некоторый момент в будущем другой клиент, например клиент В, запрашивает открытие того же самого файла, то серверу необходимо, чтобы клиент А прервал свою блокировку оріоск. Прерывание оріоск включает отправку клиентом А на сервер любых данных для записи или блокировки, которые он буфери-зировал, и затем уведомление сервера, что подтверждается отмена блокировки. Это синхронизирующее сообщение информирует сервер, что теперь допустимо разрешить клиенту В завершить открытие файла.
Клиент А должен также стереть все буферы опережающего чтения, которые он имел для файла.
Пакетная блокировка орlоск используются там, где обычные программы на клиенте ведут себя таким образом, что объем сетевого трафика растет выше приемлемого уровня для предоставляемой программой функциональности.
Например, командный процессор выполняет команды из командной процедуры, делая следующие шаги:
• Открывает командную процедуру
• Ищет "следующую строку" в файле
• Считывает строку из файла
• Закрывает файл
• Выполняет команду
Этот процесс повторяется для каждой команды, выполняемой из файла командной процедуры. Очевидно, что это приводит к обработке множества файлов, создавая тем самым сетевой трафик, который можно было бы сократить, если бы программа просто оставляла файл открытым, считывала строку, выполняла команду и затем считывала новую строку.
Пакетное блокирование действует именно так, позволяя клиентам пропускать излишние запросы открытия и закрытия. Когда командный процессор запрашивает следующую строку в файле, клиент либо запрашивает сервер, либо уже имеет эти данные в кэше опережающего чтения. В любом случае объем сетевого трафика клиента существенно сокращается.
Если сервер получает запрос для переименования или удаления файла, который имеет пакетную блокировку ор1оск, он информирует клиента, что необходимо удалить ор1оск. Клиент затем переходит в режим открыть и закрыть, описанный ранее.
Клиент А открывает файл и запрашивает орlоск. Если никто не открывал этот файл на сервере, то клиенту А предоставляется ор1оск. В приведенном выше случае клиент А сохраняет файл открытым для своей вызывающей программы для нескольких операций открыть/закрыть. Данные могут читаться для вызывающей программы с опережением; может также использоваться и другая оптимизация, например буферизированная блокировка.
Однако когда другой клиент запрашивает на сервере операцию открытия, переименования или удаления файла, клиент А должен очистить свои буферизированные данные и синхронизироваться с сервером. В большинстве случаев это включает закрытие файла при условии, что вызывающая программа клиента А считает, что она закрыла файл. Когда файл закрыт, может быть завершен запрос клиента В на открытие.
Блокировки Level П oplock позволяют нескольким клиентам иметь открытым один файл при условии, что ни один клиент не выполняет операций записи в файл. Это важно для сред со старыми машинами. Большинство открытий в режиме совместимости этих клиентов отображается в запрос открытия для совместно используемого доступа к файлу для чтения/записи. Однако помните, что это может также отменять блокировки oplock для других клиентов, даже если ни один из клиентов в действительности не намерен писать в файл.
Последовательность действий почти такая же, как у исключающей блокировки oplock. Основное различие состоит в том, что сервер информирует клиента, что он должен прекратить блокировку Level II oplock, когда никто не пишет в файл. То есть клиент А, например, может открыть файл для желательного доступа READ и общего доступа READ/WRITE. Это означает, что клиент А не будет выполнять никаких записей в файл.
Когда клиент В открывает файл, сервер должен синхронизироваться с клиентом А, если последний имеет какие-либо буферизованные блокировки Когда он синхронизируется, запрос клиента В на открытие может быть завершен. Клиент В, однако, информируется, что он имеет Level II oplock, а не исключающую блокировку oplock для файла.
В этом случае ни один клиент с блокировкой level П oplock на файле не сможет буферизировать какую-либо информацию блокирования на локальной клиентской машине. Это позволяет серверу гарантировать, что если выполняется какая-либо операция записи, то ему необходимо только уведомить клиентов level II, что блокировка должна быть прервана, без необходимости синхронизации всех аксессоров (средств доступа) файла.
Level II oplock может быть ПРЕРВАНА В НИКУДА (BROKEN ТО NONE), означая, что некоторый клиент, открывший файл, выполнил теперь операцию записи в файл. Так как ни один клиент level II не может создать ситуацию блокирования буфера, то информация на сервере остается в согласованном состоянии. Записывающий клиент, например, не сможет записать в заблокированный диапазон по определению. Однако данные опережающего чтения могут буферизироваться на клиентской машине, снижая тем самым объем сетевого трафика, требуемого файлу. Когда прерывается блокировка level II oplock, буферизирующий клиент должен очистить свои буферы и прекратить выполнение всех операций на файле через сеть. Никакого ответа на прерывание oplock от клиента не ожидается, когда сервер прерывает его из LEVEL II в NONE.
Раньше при возникновении проблемы с сетью, часто приходилось гадать, что же вызвало неполадки. Позже появились специализированные устройства, которые были дорогими, трудными для управления и понимания. Теперь имеется сетевой монитор, который является программным инструментом анализа компании Microsoft. Существуют две версии этой программы: сокращенная, поставляемая с серверными операционными системами, и полная, которая поставляется с сервером управления системами. Microsoft Network Monitor Lite способен перехватывать трафик, предназначенный только для машины, выполняющей программу. Полная версия переводит сетевой адаптер в "режим, не делающий различия" — т.е. он перехватывает трафик, направленный на компьютер, выполняющий Microsoft Nerwork Monitor, а также трафик, предназначенный для других устройств.
Network Monitor 2.0 поставляется вместе с Windows 2000 в версии Lite, а полная версия поставляется вместе с Windows NT 4.0 и SMS 2.0. Network Monitor 1.2. поставляется вместе с Windows NT 4.0 и SMS 1.2. В действительности существует лишь Небольшое различие между версиями продукта 2.0 и 1.2, так как функционально они одинаковы. Мы укажем различия, но большая часть рассматриваемого материала применима к любой версии продукта.
Microsoft Network Monitor копирует кадры в буфер перехвата, который является областью памяти с изменяемым размером. По умолчанию этот буфер перехвата равен одному мегабайту, но это легко изменить. Однако в связи с этим зависимым от памяти буфером перехвата сетевой монитор может перехватить лишь столько информации, сколько может поместиться в доступной памяти. Когда буфер будет заполнен, он начнет отбрасывать пакеты, и поэтому можно пропустить разыскиваемую информацию. Кроме того, сетевой монитор имеет склонность блокировать и связывать большую часть ресурсов процессора, когда ему разрешается выполняться в течение продолжительных периодов после полного заполнения буфера. К счастью, легко прекратить его работу с помощью Task Manager, но тогда теряется весь перехваченный файл. Мы узнаем некоторые приемы решения этой проблемы при рассмотрении необслуживаемого мониторинга сети. Потеря файла обычно не является проблемой, так как можно выбрать, какую часть кадра необходимо увидеть, создавая фильтр перехвата. Фильтр перехвата (который в определенном смысле похож на запрос к базе данных) позволяет перехватывать только определенные адреса или типы кадров. Мы поговорим об этом в разделе о перехвате данных.
Так как Microsoft Nerwork Monitor легкодоступный, очень мощный инструмент, способный перехватывать данные из сети, необходимо позаботиться о системе безопасности. Как мы видели в других главах, обладая определенными навыками, из сети можно получить очень важную информацию. Microsoft Nerwork Monitor может быть прекрасным инструментом для поиска неисправностей, но также может представлять существенную опасность, оказавшись в недобросовестных руках. Есть несколько способов защиты сети от неавторизованного использования этого инструмента. Мы-поговорим об этом позже, в разделе о безопасности сетевого монитора.
Microsoft Network Monitor не устанавливается по умолчанию. Чтобы установить его, перейдите к вкладке служб сетевого апплета в панели управления и выберите добавить (add) инструменты сетевого монитора и агент. (ПРИМЕЧАНИЕ. Не забудьте выбрать инструменты сетевого монитора и агента, а не просто агента сетевого монитора, который представлен в списке ниже и не включает программу Microsoft Network Monitor.) Установка версий SMS использует отдельную программу Setup.exe, находящуюся в каталоге NMEXR на сайте издательства "ЛОРИ".
При запуске Systems Management Server Network Monitor версии 2.0 (V5.00646) можно подумать, что встретился со старым другом. Это полная версия Windows 2000 Network Monitor. Интерфейс практически такой же, и большинство утилит работает так же. Однако некоторые вещи изменились и появились новые свойства.
Новые свойства
Программы-эксперты — шесть экспертов, поставляемых вместе с Network Monitor 2.0, перечислены ниже.
• Эксперт среднего времени ответа сервера вычисляет среднее время, которое требуется серверу для ответа на запрос пользователя данных. Он может использовать SMB, специальные порты TCP или специальные сокеты IPX для получения этих чисел, выраженных в секундах.
• Распределение свойств вычисляет статистики кадров для определенного свойства, найденного в кадрах перехваченных данных. Эти свойства могут быть весьма специальными, такими как прием HTTP.
• Утилита объединения протоколов рекомбинирует данные транзакции которые были посланы по сети в множестве кадров. Этот эксперт может собрать все фрагменты вместе на основе информации, которая содержится в кадрах.
• Эксперт распределения протоколов проверяет перехваченные данные и предоставляет статистики о пакетах почти таким же образом, как мастер распределения протоколов в продукте 1.2.
• Эксперт пересылки TCP находит кадры TCP, которые были переслан на один и тот же компьютер. Это полезно при выявлении проблемнь компьютеров.
• Эксперт верхних пользователей находит верхних отправителей и получателей данных в файле перехвата, проверяя адреса источника и места назначения, содержащиеся в кадрах.
SMS 2.0 Platform Software Development Kit (SDK) позволяет разработать своих собственных экспертов, их можно также купить у независимых поставщиков. Эксперты запускаются из меню tools expert при работе в режиме показа. Как можно видеть на рис., эксперт среднего времени ответа сервера может быстро выделить проблему со временем ответа сети. На рисунке сервер 11.0.0.206 имеет среднее время ответа 2.378751 секунд, в то время как все остальные места назначения имеют времена ответа в долях секунды. Чтобы еще больше ухудшить ситуацию, этот медленный сервер используют десять пользователей. Раньше этот процесс превращался в десяток телефонных вызовов (что затрудняло выявление и исправление проблемы). Но теперь, когда благодаря мониторингу и анализу наши действия носят профилактический характер, можно решить проблему без всяких телефонных звонков. Пользователь только после решения проблемы заметит, что сервер стал видимо работать быстрее.
Эксперт пересылки TCP на рис. сообщает, что на самом деле существует несколько пересылок, но ни одна из них не идет на машину или из машины с длинным временем ответа. Так как это происходит не на коммутируемой магистрали, то пересылки могут быть вызваны сетевой перегрузкой, указывающей на возможную причину некоторых задержек.
Утилита объединения протоколов сообщает нам, что в перехваченных данных не существует фрагментированных пакетов, поэтому эта возможная причина может быть отброшена.
Рассматривая эксперт верхних пользователей, мы видим, что пять из десяти верхних пользователей соединены с сервером 11.0.0.206, и наш эксперт протоколов также говорит, что существует большое число соединений RPC с одной и той же машиной. Мы исследуем этот вопрос и находим, что 11.0.0.206 является более старой машиной, находится на 10-мегабитном сегменте Ethernet и даже не имеет в себе платы PCI Ethernet. Очевидно, что мы обнаружили причину слабой производительности. Пользователи не жаловались на нее раньше, потому что "она всегда медленная" и они "научились с этим жить". Замена старой платы на 100-мегабитную плату PCI решает эту проблему достаточно просто.
Как можно видеть на рис, эксперты записывают свою работу в окне статуса экспертов. Мониторинг этого окна удержит вас от попытки выполнить две программы-эксперта в одно время (что породит сообщение об ошибке). Это важно помнить, так как выполнение эксперта на большом файле перехвата может потребовать много времени на медленной машине, а окно статуса эксперта является единственным местом, которое позволит узнать, что компьютер не заблокирован. В это время можно заметить, что использование центрального процессора доходит до 100%, поэтому не надо выполнять экспертов на производственных серверах, так как это вызовет жалобы сообщества пользователей.
