Пакетная блокировка ор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.
Выделенный IP-адрес должен обновляться до истечения срока своей службы. Как можно видеть в распечатке выше, когда выделенный адрес подтверждается, одновременно задается время обновления. Процесс обновления требует только двух кадров: запроса DHCP и последующего АСК.
Клиент DHCP будет запрашивать обновление дважды — при запуске и при истечение половины выделенного времени. В каждом из этих случаев, если запрос успешен, он будет использовать только два кадра. Эти два кадра выглядят точно так же, как кадры запроса и подтверждения, показанные в предыдущем разделе. Единственное различие состоит в том, что при запросе во время истечения половины выделенного времени это будет направленная дейтаграмма, а не широковещательное сообщение, как в случае обновления при запуске.
Эти два кадра имеют размер всего 684 байта и требуют только 100 миллисекунд для завершения. Если клиентской машине DHCP не удалось получить обновление после двух попыток, она будет ждать до следующего периода обновления. Если срок выделенного адреса истекает, то машина возвращается к описанному ранее процессу из четырех кадров, как если бы она пыталась получить адрес в первый раз.
Оптимизация трафика DHCP В действительности трафик DHCP имеет минимальное влияние на объем создаваемого сетевого трафика. Существуют только шесть случаев, когда трафик будет присутствовать вообще. Они перечислены ниже:
• Клиенту DHCP требуется адрес в первый раз — четыре кадра.
• Автоматическое обновление при истечении половины выделенного времени — два кадра.
• Перезапуск клиентской машины DHCP — два кадра.
• Машина перемещается в новую подсеть. Это будет создавать два кадра обновления, которые получат отрицательное подтверждение, затем четыре кадра для получения адреса — всего шесть кадров.
• Замена NIC на машине — четыре кадра.
• Адрес IP освобождается или обновляется вручную, с помощью либо ipconfig, либо winipcfg.
Одним из основных способов сокращения объема трафика DHCP является настройка длительности времени выделения. Это делается менеджером DHCP, как показано на рис. Если длительность выделения адреса изменяется с используемых по умолчанию трех дней до тридцати дней, то сокращение трафика может быть существенным — 13684 байта на каждую машину. Такое изменение имеет смысл, когда область адресов значительно больше, чем число хостов, которые необходимо адресовать. Если это не так, то придется либо использовать длительность выделения по умолчанию, либо сделать длительность еще короче. Другой сценарий при настройке длительности выделения номера может возникать в ситуации, когда существует большое количество переносных компьютеров, которые соединяются с сетью на регулярной основе. Если пользователи не обучены освобождать свои IP-адреса при выходе из сети, они могут получать несколько адресов, требуя тем самым большего пространства адресов, чем необходимо.
Использование LMHOSTS Начнем этот раздел с обсуждения двух способов, с помощью которых рабочая станция находит машину регистрации — с помощью широковещания и с помощью WINS. Существует и третий способ: использование файла lmhosts. Обратимся к этому файлу.
Используя запись #PRE, мы приказываем машине сделать предварительную загрузку записи в кэш имен NetBIOS. Она будет найдена, когда мы введем nbtstat -с, как показано на рис. Задав #DOM с именем домена, мы сообщаем машине, что это контроллер домена, и поэтому получаем дополнительные записи, такие как <1С>, также показанные на рис.
Используя файл LMHOSTS, мы ускоряем процесс регистрации, не выполняя при этом ни широковещательного запроса, ни запроса WINS, и, кроме того, сокращаем сетевой трафик. Стандартная проблема с реализацией LMHOSTS состоит в размещении его на всех клиентских машинах. Выход простой: поместите LMHOSTS в сценарий регистрации, и он сам скомпонуется на клиентские машины. На машине WIN NT он помещается в каталоге \\system32\drivers\etc. На машине Windows 9.x он помещается в каталог \\windows.
Нужно ли иметь больше контроллеров доменов? Обычно процесс регистрации происходит между 8 и 9 часами утра. Сколько реально необходимо иметь серверов регистрации? Помните, что добавление дополнительных резервных контроллеров доменов увеличивает сетевой трафик, как мы увидим в следующей главе. Это означает, что было бы плохой идеей сделать каждый сервер в сети резервным контроллером домена (что встречается достаточно часто).
Используя очень консервативную оценку, один контроллер домена может легко управлять 2000 пользователей. Если вернуться к нашему окну регистрации, можно видеть, что в течение одного часа (3600 секунд), происходит в среднем меньше двух регистрации в секунду (если запросы регистрации распределены равномерно). Что делать в такой ситуации? Прежде всего, необходимо использовать монитор производительности для создания протокола утренней деятельности по регистрации. Как можно видеть на рис. лучшим способом это сделать является создание протокола (log) монитора производительности и протокола использования памяти, процессора и серверного объекта. Для этого надо перейти во view\log и выбрать соответствующие режимы. В меню режимов выбирается тип протокола (log), а затем вводится имя протокола. Можно использовать, например, logon.log или добавить дату. Выберите хорошее место для размещения протокола (не в корне), интервал обновления и нажмите save (сохранить). Теперь необходимо добавить некоторые показатели, нажимая кнопку "плюс", как показано на рис.
Когда показатели будут добавлены, необходимо вернуться в меню режимов, выбрать тип протокола (log) и запустить протокол, как показано на рис. Это будет достаточно большой протокол, так как записи в нем появляются каждую секунду.
Если после создания протокола будут замечены периоды, когда происходит множество попыток регистрации в секунду, необходимо сделать несколько дополнительных изменений.
Когда создается контроллер домена, служба сервера оптимизирована для совместного использования файлов и принтеров. Это хорошо для серверов файлов и печати, но создает не оптимальную производительность для серверов регистрации. Чтобы изменить это, обратимся к сетевому апплету в панели управления (или сделаем щелчок правой кнопкой мыши по пиктограмме сети на рабочем столе), выберем сервер из закладок служб и щелкнем мышью по свойствам. Как можно видеть на рис, мы хотим выбрать максимальную производительность для сетевых приложений. Затем нажмем ОК. Примечание. Необходимо перезагрузить машину, чтобы получить какой-то эффект. Делая такие изменения, контроллер домена может утроить число одновременных регистрации — от шести до почти 20 регистрации в секунду.
Размещение сервера регистрации Когда речь идет о регистрации, чем ближе пользователь находится к контроллеру домена, тем лучше. Когда имеется удаленный сайт, не обязательно бездумно помещать BDC на другой стороне медленного соединения и надеяться на лучшее. Существуют также и другие ситуации. Должно быть рассмотрено влияние трафика WAN в связи с синхронизацией служб каталогов. В дополнение к этому, что произойдет, если линия WAN будет выключена, и службы каталогов устареют? Это только часть вопросов, которые должны быть рассмотрены до реализации. Дополнительно, скорее всего, понадобится реализовать WINS и DHCP и сконфигурировать для них репликацию, чтобы сократить этот вид трафика. Мы поговорим об этом в следующей главе, а сейчас, вероятно, лучше всего поместить BDC на другой стороне медленного соединения WAN, но это должна быть хорошо продуманная реализация.
Я ненавижу просмотр. Как правило, это долгий и утомительный процесс, а если и есть на свете что-то еще более отвратительное, чем неправильно работающий компьютер, то это медленный компьютер. Несколько часов сидеть и наблюдать за тем, как на экране вспыхивают цифры... волей-неволей задумаешься о том, можно ли как-то рационализировать этот процесс.
Если просмотр не оптимизирован, то программа просмотра создает дополнительный трафик всякий раз, когда кто-то регистрируется в сети.
