Продолжаем наш практический обзор. Памятуя о предыдущей части, напомню, что успешное прохождение теста правила Web-публикации не означает автоматически, что все хорошо (а то задают уже вопросы). Тест может быть удачным, а правило работать при этом не будет. В частности, проверяется не успешность аутентификации, а совпадают ли методы аутентификации, сконфигурированные на IIS и в listener на ISA.
Теперь к фичам, которые еще не освещены независмой прессой мной.
Пряник #3: Traffic Simulator.
Все очень просто. Вводите откуда идет трафик. Вводите куда идет трафик. Жмете Start и получаете правило, которое разрешает или запрещает данный трафик. Великолепная вещь. Просто супер. Проверяет четыре типа трафика:
- Web Access
- Non Web Access
- Web Publishing
- Server Publishing
Без комментариев, в общем-то - все понятно и так. Выглядеть может вот так:
Или вот так ![clip_image002[5]](http://lh5.ggpht.com/KomatoZo/SJsR484aOjI/AAAAAAAAAEg/o4dGW3rVgig/s1600-h/clip_image002%5B5%5D%5B2%5D.jpg)
В общем, пользоваться не напользоваться. Однако тоже не панацея, хотя и здорово облегчает жизнь. Не панацея, потому что может ошибаться в различных ситуациях. Например, не определяет ситуации, в которых трафик будет заблокирован фильтром приложения. Напарывался уже, рекомендую быть внимательным =)
Пряник #4: Diagnostic Logging
![clip_image002[7]](http://lh4.ggpht.com/KomatoZo/SJsR6mY6efI/AAAAAAAAAEo/M0YX3UxaH5c/s1600-h/clip_image002%5B7%5D%5B3%5D.jpg)
Одна из немногих фич нового SP, которые я самолично пока не попробовал - просто не было повода. Но для глубокого траблшутинга должно быть очень не плохо. полная информация обо всем, что происходило с пакетами внутри ISA. Очень информативно и, как мне кажется, может быть весьма полезным.
Остальные пряники больше касаются внутренних изменений. О них в следующем выпуске. =)
11 комментариев:
Diagnostic Logging тоже не стоит переоценивать. Он хорошо объясняет, почему всё работает так, как надо =). Т.е. какое именно правило применяется и почему. Но практически бесполезен, когда что-то идёт не так, как задумано. У меня был случай, когда пакеты не проходили, хотя по всем соображениям должны были. Справедливости ради надо сказать, что конфигурация была совершенно неподдерживаемая — иса стоит на хосте, где установлен VMware Server (да и то не последней версии), и проблемы возникали только у тех виртуалок, которые находятся на этом же хосте. У других клиентов в этой сети никаких затруднений не было. Так вот, в этом случае от Diagnostic Logging толку не было никакого. Максимум, что можно было понять — это доходит ли пакет до самой исы, или нет. Но для этого и обычного журналирования, не Diagnostic, было бы достаточно.
ЗЫ. Кстати, сам по себе DL — это не новая фича. Он был, кажется, ещё с ISA 2006 RTM. Или появился в Supportability Update, не помню точно. Просто для чтения логов приходилось использовать отдельную утилиту, которая кстати базируется на Log Parser и просто оборачивает его для того, чтобы синтаксис командной строки был более понятным и «заточенным» именно под ISA DL. А теперь, в SP1, читалку DL встроили в саму консоль.
Спасибо за комментарий, Артем. Просто еще не юзал эту утилиту, потому не наступал на грабли - теперь буду в курсе. Серебрянной пули по-любому не будет, но, может, это будет хоть как-то полезно =)
Насчет того, что оно было в Supportability Pack я в курсе, но тут удобнее уже, да и другие фичи откровенно радуют =)
Ну, основываясь на своём опыте я вижу одну большую пользу от DL. Глядя на то, как обрабатываются правила, должно быть намного проще понять, как работает иса. Вспоминая себя лет пять назад, понять логику исы «методом тыка» было непросто. Мне кажется, что DL будет здесь хорошей помощью.
ну и, соответственно, если есть проблема где-то в правилах, а не в конфигурации (как было в моём примере), то от DL действительно может быть много пользы.
Гут, учту. =)
Кстати, а я в SP1 не нашёл для себя практически ничего особо полезного. Да, много интересного, но ничего такого, что принципиально изменило бы мою работу или сделало её удобнее. На мой взгляд, самое значительное измение было реализовано в том же Supportability Update. Я говорю об улучшениях просмотрщика логов (обычных, не Diagnostic). Когда появились выделения цветом и возможность забивать в фильтр сразу несколько значений. Вот это был прорыв. Вторая по значимости фича — Multicast NLB. Это даже ещё круче, но уже с точки зрения архитектуры, а не удобства. Иногда пишут, что эта функция появилась в SP1, но это не так. Она стала доступна с одним из промежуточных обновлений между SU и SP1. Причём с SP1 она никак не изменилась (хотя я где-то встречал упоминание, что в SP1 её тоже должны были встроить в GUI. Не встроили или я не нашёл?).
Я напишу еще про архитектурные улучшения. Мы их используем практически все. Потому для меня SP1 стал событием.
Повторюсь: по отдельности каждая фича ничего особенного: или небольшое улучшение или просто фичулечка, которую не все могут и использовать или полезность которой ограничена. Но в сумме я такого насыщенного SP уже давно не помню. Может, так сложилось только для меня, но я же про свои ощущения и пишу =)
Ну что господа могу сказать про Sp1,стабильности в работе ощутимой не заметил,хотя меньше стало отваливать NLB чему я несказанно рад.Очень удобный логгер согласен,и на этом все!! Стоило ли называть это SP1.
Вы просто не все то используете, что я еще не осветил, видимо. =)
Я скоро допишу.
Жду с нетерпением!!=))Да и еще вопрос преклодного ипользовани CARP,возможно кто нибуть его юзает??!! И если не затруднит господа обьясните на пальцах для чего он нужен.Читак кучу мануалов,но досих пор так и непонял его назначения.Второе если ктонить из вас использует ISA в кластере поделитесь опытом администрирования,а в часности излечения постоянного отваливания сее сервиса!!
Про CARP - внес в WishList - следите за обновлениями.
Про отваливания сервиса хотелось бы поподробнее, лучше даже в почту:
komatozo{AT}Gmail{Dot}Com
Отправить комментарий