| Каталог документации / Раздел "Операционные системы, Разное" / Оглавление документа |
| |
|
Даже в самом простом случае сети с двумя узлами, существует много аппаратуры и параметров программного обеспечения, взаимосвязь между которыми может значительно влиять на эффективность работы сети. Обычно, подход к такой сложной проблеме должен начинаться с декомпозиции общей проблемы на более мелкие части и так далее, до нахождения первоисточников проблемы и затем уж выполняется систематический и логический план удаления возможных причин, пока не будет достигнуто её решение.
Так с чего же начать? Квалифицированный сетевой аналитик всегда начинает с полного понимания текущей сетевой среды. Вообще, этот подход подразумевает документирование сетевой топологии, прикладных программ и используемых протоколов.
Если сетевая конфигурация неизвестна, используйте команду ping -R hostname и/или команды traceroute. Опция - R команды ping допускает использование возможности записи маршрута IP. Отрицательный результат выполнения ping означает, что не работает или узел или сеть. Для того, чтобы узнать, что именно не работает, требуется воспользоваться другими средствами. Команда ping также не дает информации о состоянии узла-адресата. Команда traceroute, аналогично выводит маршрут, который пакеты IP берут на сетевом узле, но накапливает информацию немного по-другому.
Команда traceroute использует два способа прослеживая передачу информации до адресата: маленькое значение ttl (время жизни) и отказавший номер порта.
Traceroute запускает пакеты UDP с маленькими значениями ttl, чтобы обнаружить промежуточные маршрутизаторы. Команда traceroute была создана для сетевого тестирования, измерения и управления. Вы должны использовать её прежде всего для обнаружения неисправности вручную. Из-за нагрузки, которую она налагает на сеть, вы не должны использовать команду traceroute в течение нормальных операций или из автоматизированных сценариев.
При нормально работающей сети задокументируйте параметры, выдаваемые вам вышеуказанными командами. Это позволит вам сравнить с ними изменение параметров сети, возникшие при добавлении новой аппаратуры или программ.
Чтобы создания полного обзора эффективности и конфигурационной информации сети, используйте пакет PerfPMR. Чтобы получать наиболее полные данные о сети вы должны выполнить команду perfpmr 3600 в тот час, когда нагрузка на сеть является максимальной. Выходные файлы этой команды появятся в каталоге /var/perf/tmp.
Если возможно, установите, что является "нормалью" для вашей сети, контролируя трафик в течение нескольких месяцев.
Ограничивают производительность TCP/IP в AIX обычно следующие факторы:
· недостаточное относительное
быстродействие аппаратных средств;
· количество циклов CPU, необходимых для
выполнения данной части кода ;
· размер пакетов передаваемых данных ;
· производительность, с которой данные
кэшируются в клиентской памяти,
промежуточном звене и системах сервера;
· качество кода пользователей, который
обращается к подсистеме локальной
вычислительной сети.
Таким образом, вы должны понять, как каждый из этих факторов способствует недостаточной сетевой эффективности.
Все узлы, присоединенные к локальной вычислительной сети совместно используют общий канал передачи. Поэтому сети с большим количеством серверов и сотнями рабочих станций, передача мультимедийных данных и т.п. могут совершенно загрузить канал передачи данных.
Настройка эффективности работы CPU является предметом особого рассмотрения и в этой книге не приводится.
Размер пакета данных также играет большую роль в ограничении эффективности сети. Обычное рассуждение приводит нас к выводу, что большие пакеты лучше, так как уменьшается количество передаваемой служебной информации (адрес и т.п.) и снижается нагрузка узлов. Это верно до той степени величины пакетов, которая не вызывает фрагментацию, так как фрагментация пакетов может представлять уже другую проблему.
При недостаточной памяти клиента для кэширования получаемых данных, некоторые данные могут быть пропущены. При постоянном заторе происходит эффект "пинг-понга", когда передающий узел всё время пытается передать пакеты принимающему узлу, а тот отбрасывает их обратно.
Для контроля и настройки современных гетерогенных сетей администраторы должны иметь соответствующие инструментальные средства.
Сетевые диагностические инструментальные средства можно разделить на две категории: на те, которые сообщают вам, что происходит и на те, которые, позволяют некоторым образом прореагировать на то, что происходит.
Для сетей Ethernet, вероятно, наиболее полезный инструмент - тестер (TDR). TDR присоединяется к сети вместо одного из терминаторов. Затем тестер испускает сигнал известной мощности и формата и измеряет ответ. Каждый тип сетевой неисправности дает специфический тип ответа на TDR. Вы должны ознакомиться с документацией на тестер, чтобы интерпретировать эти ответы. Вы должны правильно установить параметры TDR для разных типов кабелей.
Вы можете использовать команду ifconfig, чтобы проверить состояние физического сетевого интерфейса (является ли он работоспособным и готовым получать пакеты, правильно ли вы его сконфигурировали, текущий адрес Internet).
Команда tokstat отображает статистику, определенного драйвера устройства Token-Ring.
Команда Packet InterNet Groper (ping) посылает дейтаграмму ECHO_REQUEST протокола ICMP (не требует наличия серверных процессов на зондируемом узле) на конкретный узел, чтобы определить является ли этот узел доступным. Часть ответа, которую вы получаете от ping - это время передачи дейтаграммы туда и обратно.
Изменяя количество данных и выдавая ping на промежуточные узлы, вы можете получать информацию о том, какие узлы включены и работают. В выполнении команды ping участвуют система маршрутизации, схемы разрешения адресов и сетевые шлюзы, поэтому для достижения успешного результата этой команды сеть должна быть в более или менее работоспособном состоянии. Если ответа от узла нет, вы можете быть совершенно уверены, что более сложные средства тем более не работают.
Вы можете использовать команду traceroute, чтобы выявлять последовательность шлюзов, через которые проходят пакеты для достижения определенного узла.
Вы должны использовать команду iptrace всякий раз, когда вы должны рассмотреть пакеты, которые машина посылает и получает. Но следует учитывать следующее: эта команда захватывает все передаваемые и получаемые пакеты на сетевом уровне в соответствии набору фильтров в команде iptrace. Так как эта команда является пользовательским процессом она должна конкурировать с другими процессами за CPU. Следовательно, на сильно загруженной машине, iptrace может не захватывать все пакеты. И так как iptrace отслеживает пакеты на сетевом уровне, то нет никаких доказательств того, что пакет попал в кабель, так как прежде пакет должен пройти через драйвер и адаптер, чтобы добраться до кабеля.
В случаях, когда все же неясно, что приводит к заторам в сети, вы должны использовать специализированный сетевой анализатор.
Команда tcpdump следит за трафиком в сети и регистрирует заголовки пакета, которые соответствуют булеву выражению, задаваемому пользователем. Если никаких параметров не задано, команда будет отслеживать все пакеты в сети.
Команда netstat возвращает набор статистики относительно состояния сети. Команда netstat - хороший инструмент, чтобы помочь определить размещение проблемы.
Как только проблема изолирована, вы можете использовать более сложные инструментальные средства, чтобы продолжить её решение. Например, вы могли бы использовать команды netstat -i и netstat -v, чтобы определить, имеется ли проблема с конкретным аппаратным интерфейсом и затем выполнить диагностику, чтобы ещё более изолировать проблему.
Или, если команда netstat -s показывает, что существуют ошибки протокола, вы могли бы затем использовать команду iptrace для детализированного анализа.
Этот инструмент контролирует и выдаёт статистику сетевого ввода-вывода и связанного с обслуживанием сети использования CPU.
Команда netpmon покажет трафик узла на канальном, сетевом и транспортном уровнях (протоколы TCP и UDP). Эта команда может также обнаружить трафик в другие сети и отображать сетевую статистику трафика сортируя информацию по узлам.
При специфических проблемах для изучения содержания пакетов данных в сети вы можете использовать анализатор протокола. Анализатор протокола фиксирует полную структуру сетевых данных, без связи с используемыми протоколами или с сетевой операционной системой. Он обрабатывает структуру как необработанные данные.
Доступны несколько коммерческих пакетов. Они будут фиксировать структуру данных и декодировать их согласно типа протокола, показывая информацию управления в соответствующих уровнях модели OSI.
Анализатор протокола - очень ценный инструмент, но требует неплохого знания сетевых протоколов.
Вы также должны знать, что термин "сетевой анализатор" может означать различные вещи у разных продавцов. Некоторые продавцы могут полагать, что сетевой монитор будет называться сетевым анализатором. Мониторы фиксируют информацию о трафике, типа количество переданных фреймов в секунду или число фреймов, которые содержат ошибки. Эти устройства не являются истинными анализаторами, так как они неспособны декодировать информацию протокола более высокого уровня, которую содержит переданный фрейм.
Ранее было невозможно получить сводное представление обо всех системах и сетевой эффективности в сложной и распределенной среде. IBM SystemView for AIX Performance Reporter (Performance Reporter) устраняет эту проблему обеспечивая эффективные, информативные отчеты основанные на данных, сгенерированных из встроенной базы данных. Этот инструмент позволяет часто обнаруживать возможные проблемы до их возникновения.
Данные, собранные Performance Reporter помогут вам узнать то, какие пользователи используют какие ресурсы и проанализировать узкие места и другие проблемы производительности.
Вы можете собрать информацию о производительности с узлов под управлением AIX, Sun Solaris, и HP-UX. Вы можете легко использовать данные из базы данных Performance Reporter в других прикладных программах. Модель данных хорошо зарегистрирована и просто изменяется.
Performance Reporter поддерживает СУБД DB2/6000 и Oracle.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |