Адрес маршрутизатора (gateway address)
Это адрес компьютера, который является «шлюзом» во внешний мир (т. е. к компьютерам вне локальной сети). Принято проектировать сети так, чтобы адрес маршрутизатора получался из IP-адреса компьютера заменой последних групп цифр на .1. Например, если IP-адрес компьютера равняется 128.253.154.32, то адрес маршрутизатора может иметь значение 128.253.154.1. Эта рекомендация не является обязательной, так всю правду обычно знает только системный администратор.
Маршрутизаторов может быть несколько. В действительности маршрутизатор ═ — это компьютер, который находится в двух различных сетях (т. е. имеет IP-адреса в различных подсетях). Маршрутизатор занимается тем, что пересылает пакеты сообщений между этими двумя сетями. Многие сети имеют единственный шлюз во «внешний мир» (который представляет собой непосредственно примыкающую сеть). Однако в некоторых случаях к локальной сети примыкает несколько других сетей, и для каждой из них имеется свой маршрутизатор.
Если используется только заглушка, адрес маршрутизатора отсутствует. То же верно и в случае, когда локальная сеть изолирована от всех остальных.
Адрес сервера имён (name server address)
Для большинства компьютеров в сети имеется сервер, который преобразует имя компьютера в IP-адрес (Domain Name Server, сокращённо DNS). Сервер устанавливает соответствие доменного имени, отражающего административную принадлежность компьютера, и IP-адреса, отражающего место компьютера в сети Интернет. Любое обращение по сети с использованием доменного имени требует преобразования его в IP-адрес (возможно, при помощи сервера). Адрес этого сервера должен сообщить администратор сети или провайдер, предоставляющий доступ в Интернет.
|
|
|
Такой сервер можно также запустить на собственном компьютере (программа называется named); в этом случае адрес сервера имён в сети равняется 127.0.0.1. Кроме тех случаев, когда абсолютно необходимо иметь собственный сервер имён, лучше воспользоваться тем, который имеется (если имеется).
Построение компьютерных сетей вызвало необходимость управления (администрирования) ими и созданными на их основе компьютерными вычислительными и информационными системами. В результате появилось системное администрирование.
Системное администрирование
Основной целью системного администрирования является приведение сети в соответствие с целями и задачами, для которых она предназначена. Достигается эта цель путём управления сетью, позволяющего минимизировать затраты времени и ресурсов, направляемых на управление системой, и в тоже время максимизировать доступность, производительность и продуктивность системы.
|
|
|
История системного администрирования насчитывает несколько десятилетий. Задачи управления вычислительными комплексами (системами) возникли сразу после появления самих этих комплексов. Доминировавшая до конца 1980-х годов централизованная вычислительная модель типа “мэйнфрейм–терминалы” непосредственно проецировалась на архитектуру средств администрирования, которую относят к категории системного. Такое решение означало существование единого образа вычислительной среды. В подобных средствах администрирования задачи управления сводились к контролю за функционированием отдельных компонентов, причём во многих случаях он заключался просто в сборе данных о ресурсах вместо действительного управления их работой. Такой тип управления нельзя отнести к сетевому администрированию в строгом смысле этого слова.
В начале 1990-х годов широкое распространение распределённых архитектур “клиент-сервер” вызвало перемены в управлении информационными системами, сменившими безраздельное господство хост-компьютеров. Вместо однородной среды администраторам пришлось иметь дело с многообразием ресурсов, включая компьютерные и программные платформы, а также сетевое оборудование. Такое положение потребовало решения новых административных задач: учёта распределённых ресурсов, электронного распространения ПО и контроля лицензий, анализа трафика и управления пропускной способностью сети, перераспределения серверной нагрузки, отслеживания состояния отдельных настольных систем и другое, отсутствовавших в классической централизованной модели. В эту среду не переносились приложения администрирования, функционировавшие на мэйнфреймах, и производителям пришлось создавать новое управляющее ПО. Всё это способствовало появлению сетевого администрирования.
|
|
|
Сетевое администрирование
Сетевое администрирование (Network Management) возникает, когда у администратора сети появляется потребность и возможность оперировать единым представлением сети, как правило, это относится к сетям со сложной архитектурой. При этом осуществляется переход от управления функционированием отдельных устройств к анализу трафика в отдельных участках сети, управлению её логической конфигурацией и конкретными рабочими параметрами, причём все эти операции целесообразно выполнять с одной управляющей консоли. Задачи, решаемые в данной области, разбиваются на две группы:
|
|
|
1. Контроль за работой сетевого оборудования,
2. Управление функционированием сети в целом.
Конечной целью управления сетью является достижение параметров функционирования ИС, соответствующих потребностям пользователей. Пользователи оценивают работу ИС не по характеристикам сетевого трафика, применяемым протоколам, времени отклика серверов на запросы определённого типа и особенностям выполняемых сценариев управления, а по поведению приложений, ежедневно запускаемых на их настольных компьютерах.
Общая тенденция в мире сетевого и системного администрирования – перенос акцентов с контроля за отдельными ресурсами или их группами, с управления рабочими характеристиками ИС на максимальное удовлетворение запросов конечных потребителей информационных технологий способствовала появлению концепции динамического администрирования.
Такой подход предполагает, прежде всего, наличие средств анализа поведения пользователей, в ходе которого выявляют их предпочтения и проблемы, возникающие в повседневной работе. Результаты, полученные на этом этапе, должны послужить отправной точкой для активного управления взаимодействием между основными объектами администрирования – пользователями, приложениями и сетью. Эти факторы дают основание полагать, что на смену сетевому и системному администрированию придёт управление приложениями и качеством сервиса, независящее от используемых вычислительных платформ или сетей.
Эволюция концепций администрирования коснулась не только архитектуры систем. Новые проблемы, возникшие в распределённых средах, привели к тому, что на некоторое время сетевое управление стали рассматривать как главную заботу администраторов ИС. Ситуация изменилась когда число распределённых приложений и баз данных, функционирующих в сети, превысило пороговое значение. При этом возросла роль системного администрирования, и неизбежным оказался процесс интеграции системного и сетевого администрирования.
2.1 Обеспечение организации администрирования ЛВС.
2.2 Меры по устранению возможных сбоев при работе сети.
Сбои в работе сети могут быть вызваны теми же самыми причинами, которые препятствуют установлению соединения (они перечислены в предыдущей статье). Действия, описанные далее, подразумевают, что соединение работало корректно до того, как возникла проблема, и уже были предприняты следующие меры и установлены следующие факты:
· выполнена холодная перезагрузка проблемной рабочей станции (горячая перезагрузка не обнуляет состояние адаптерных карт). То же касается применения всех необходимых программных исправлений, если они были загружены, но не установлены. Кроме того, некоторым устройствам Plug-n-Play для полной установки требуется двукратная, а то и трехкратная перезагрузка;
· сбои в аппаратной части отсутствуют;
· сетевые кабели правильно подключены и функционируют должным образом;
· сетевая карта не отключена, в подсети назначаются нужные динамические (посредством DHCP) или статические адреса. Отчеты операционной системы о состоянии сетевой карты не содержат аномальных значений, в частности, число отправленных и полученных пакетов отлично от нуля (если хоть одно из этих значений нулевое, значит, надо разобраться, в чем причина);
· в последнее время ни на самой рабочей станции, ни на сервере не производилось никаких изменений в службах, конфигурации, программном или аппаратном обеспечении;
· возможные проблемы с распределением памяти на рабочей станции и конфликты программного обеспечения исключены. Для проверки следует загрузить лишь то программное обеспечение, которое необходимо для работы тестируемого приложения в сети, и временно — до завершения теста — отключить антивирусную систему и программное обеспечение безопасности;
· никакие приложения на пользовательской рабочей станции не потребляют чрезмерно ресурсы микропроцессора и не затормаживают работу компьютера настолько, что за это время происходит сброс счетчиков соединения. Подобными свойствами могут обладать вирусы.
Причиной разрыва соединения может быть логическая или физическая потеря связи. Это происходит при сбое в кабельном сегменте, либо затрудненном доступе к сетевому коммутатору, мосту, маршрутизатору или глобальной сети. Протоколы верхнего уровня используют разнообразные таймеры — счетчики, которые по истечении заданного времени разрывают логическое соединение рабочей станции, если отклик от нее не получен. Таким образом, когда пакеты теряются на пути через коммутатор, мост, маршрутизатор или соединение глобальной сети, соединение с соответствующим сервером или службой будет утрачено, несмотря на то, что в коллизионном и широковещательном домене все работает без нареканий.
Прежде всего определите, относится ли проблема только к данной рабочей станции, затрагивает небольшую группу компьютеров (коллизионный домен, включающий конкретный порт сетевого коммутатора) либо охватывает множество рабочих станций (тогда проблема касается широковещательного домена или даже затрагивает взаимосвязанные сети). Опрос соседних пользователей позволит узнать, не сталкивались ли они с похожими трудностями. Не мешает поинтересоваться, наблюдается ли проблема в какое-то определенное время дня, возникла ли после какого-либо запроса или проявилась по окончании каких-либо работ, которые внешне никак с ней не связаны.
Сбои в коллизионном домене затрагивают локальную среду и препятствуют связи с ближайшим устройством второго или третьего уровня, с локальным сервером или службой, к которым пользователь пытается обратиться. Возможны следующие причины:
· некачественные кабели;
· пограничное состояние или некорректная работа сетевой карты рабочей станции либо порта в сетевом коммутаторе или концентраторе;
· ошибки или чрезмерный трафик в локальном коллизионном домене;
· несоответствие настроек дуплексного режима передачи;
· шум от электрического оборудования и других внешних источников.
Многие сбои в коллизионном домене, из-за которых теряется соединение с сетью, можно идентифицировать, если вместо рабочей станции подключить к сети тестер. Подсоединившись к тому же кабельному сегменту, который обычно задействует пользователь, попробуйте войти в сеть и обратиться к соответствующему серверу или службе. Затем подключите рабочую станцию транзитом через тестер и оставьте прибор для мониторинга состояния соединения. Еще лучше установить анализатор протоколов для сбора трафика и сетевой статистики. Проинструктируйте пользователя, какие показатели тестера он должен зафиксировать сразу же после очередного сбоя и как остановить сбор трафика и сохранить уже собранную информацию для последующего анализа.
Многие пользователи имеют и проводную, и беспроводную сетевые карты, причем нередко активированы обе. Если персональный компьютер пытается использовать беспроводную карту вместо проводного соединения, то необходимо разбираться с конкретным местоположением рабочей станции, а порой даже с ее ориентацией в пространстве. Во многих беспроводных сетях есть слепые зоны, зачастую они очень небольшие, поэтому перемещение компьютера буквально на десять сантиметров или небольшой поворот его в ту или иную сторону позволяет успешно восстановить беспроводное соединение. Препятствием для сигнала могут стать даже люди, столпившиеся вокруг компьютера.
Потенциальными проблемами в широковещательном домене следует заняться только после того, как установлено надежное соединение на уровне MAC. Типичный пример такого сбоя — невозможность создать стабильное логическое подключение через мост. К разрыву связи станции с серверами и маршрутизаторами в том же широковещательном домене могут приводить и проблемы на сетевом уровне:
· плохо работающий или неисправный порт для каскадирования (uplink port), находящийся в любом месте маршрута. Как правило, это следствие использования плохого кабеля;
· проблемы со связующим деревом в сети — возможно, также из-за плохого кабеля;
· широковещательный шторм или чрезмерный трафик другого типа в широковещательном домене (причем вовсе не обязательно, что этот трафик наблюдается на локальном порту);
· несоответствия в настройках дуплексного режима на каком-то участке маршрута;
· дублирующиеся IP-адреса;
· некорректное объявление маршрутов рабочей станцией или сервером.
Отправка повторяющихся запросов Ping на локальный маршрутизатор позволяет выявить потерю пакетов в широковещательном домене. С помощью системы управления сетью опросите сетевые устройства, находящиеся по пути от пользователя до маршрутизатора, сервера или службы. Обратите внимание на ошибки или высокий уровень загруженности, особенно если они отмечаются в тот момент, когда соединение оказывается разорвано. Подключите рабочую станцию к сети и воспользуйтесь анализатором протоколов для мониторинга сетевого трафика и/или сбора пакетов от проблемного сервера или службы для последующего анализа. Если проблема то появляется, то исчезает, оставьте анализатор протоколов для сбора трафика за определенный период времени. Научите пользователя, как остановить сбор данных — он должен сделать это сразу же, как только случится сбой. Довольно часто такие проблемы имеют нерегулярный характер, поэтому без привлечения пользователя к процессу диагностирования не обойтись. Он должен либо немедленно позвать специалиста, либо самостоятельно собрать данные о том, что происходило перед сбоем.
Проблемы во взаимосвязанных сетях следует диагностировать после того, как установлено надежное соединение с маршрутизатором, ведущим за пределы широковещательного домена. Обеспечить надежный доступ к серверам и службам Internet сложнее, чем добиться надежного соединения с серверами и службами в сопредельных локальных сетях, поскольку провайдер услуг Internet мог подвергнуться атакам с целью вызвать отказ в обслуживании и другие неприятности, контролировать и выявить которые пользователи не смогут. К ним относятся:
· неустойчивая маршрутизация вследствие пограничного состояния порта или канала на каком-то участке за пределами широковещательного домена. Возможная причина — плохой кабель;
· чрезмерный трафик для низкоскоростного локального или глобального канала. Возможно, трафик отвергается, либо буфер переполнен;
· время отклика на запросы Ping и функции Trace Route варьируется;
· сервер или служба испытывают перегрузку.
Отправка запросов Ping и Trace Route позволяют найти узел, с которого следует начать диагностирование проблемы потери сетевого соединения. Если симптомы то появляются, то исчезают или их трудно уловить, необходимо запустить тесты на непрерывное выполнение. При выявлении подозрительного удаленного узла процесс диагностирования можно ускорить, воспользовавшись системой управления сетью, чтобы опросить соответствующее сетевое устройство, а также устройство, ему предшествующее. Либо то, либо другое покажет ошибки определенного типа или чрезмерный уровень загруженности.
Для проверки производительности по маршруту от пользователя до сервера или службы надо выполнить тестирование пропускной способности. В это время следует вести мониторинг маршрута с помощью системы управления сетью, чтобы выяснить, нет ли ошибок. Практически всегда установление надежного сквозного соединения на сетевом уровне полностью устраняет проблему с утратой сетевого подключения. В ходе диагностики не забывайте тестировать коллизионный и широковещательный домены каждый раз, когда вы перемещаетесь на новое место — это позволит сузить зону поисков.
Если сквозное соединение на сетевом уровне установлено надежно, а проблема не исчезла, то остается только установить анализатор протоколов для сбора трафика. Научите пользователя останавливать сбор трафика — он должен сделать это сразу же, как только проявится сбой. Если сервер или служба работают с перегрузкой, на рабочей станции пользователя по какой-то причине расходуются значительные ресурсы микропроцессора или происходит разрыв соединения, то трассировочный файл, созданный анализатором протоколов, покажет, с какого конца соединения следует начинать поиск.
Дата добавления: 2015-12-19; просмотров: 10; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!