2. Искусство диагностики локальных сетей


Стихийное развитие кабельного хозяйства сети

Одной из наиболее распространенных причин плохой работы локальной сети является стихийное развитие ее кабельного хозяйства из-за отсутствия стратегии ее расширения. Часто локальная сеть создается в условиях жесткой экономии средств, что сказывается на принимаемых технических решениях. Пока сеть невелика и пользуется ею не больше 30-40 человек, она работает без сбоев. По мере развития она постепенно расширяется. Пользователи переезжают из одного помещения в другое, и локальная сеть охватывает все большее число помещений. При некотором критическом числе станций в сети появляются сбои. Техническое решение, которое было приемлемо для малой сети, становится тормозом ее развития или причиной сбоев. Примером такого "экономного" решения может быть использование коаксиального кабеля в качестве передаточной среды. Администраторы сетей, построенных на базе коаксиальных кабелей, практически становятся заложниками однажды принятого решения. Модернизация такой сети требует практически построения ее заново. Провести подобную модернизацию без остановки работы сети - задача не из легких. Следовательно, чем раньше будет принято решение о модернизации такой сети, тем менее болезненно она пройдет. Альтернативой стихийному развитию должно быть построение кабельного хозяйства сети в соответствии с международными стандартами EIA/TIA 568, 569, 570, 606, 607, TSB 36, TSB 40, TSB 67. Эти стандарты представляют собой описание правил построения такой кабельной системы, которая не зависела бы от используемого сетевого оборудования, перемещения пользователей по зданию и т. п. Соблюдение этих стандартов при создании и эксплуатации сети позволяет в течение 10-15 лет избежать серьезных проблем с кабельным хозяйством.

Выбор архитектурного решения сети и активного сетевого оборудования без учета специфики эксплуатируемого в сети прикладного ПО

Еще несколько лет назад приобретать сетевое оборудование под прикладную задачу казалось абсурдом: а что делать, когда прикладная задача изменится? Сегодня стоимость прикладного ПО не только соизмерима со стоимостью сетевого оборудования, но часто существенно больше последней. Абсурдом становится приобретение оборудования без учета специфики прикладного ПО. Учет специфики прикладного ПО не следует понимать слишком буквально. Он вовсе не означает, что никакое другое ПО работать в сети не сможет. Учет специфики прикладного ПО нужен при выборе требований к пропускной способности, которым должны удовлетворять как архитектура сети, так и сетевое оборудование. Прежде всего следует оценить необходимый минимум пропускной способности. Будет ли эта минимальная пропускная способность достаточной и какой запас по пропускной способности должен быть заложен в проекте, - это уже вопрос стратегии и финансовых возможностей пользователя. Учет специфики эксплуатируемого в сети прикладного ПО - это длительный и дорогостоящий процесс. Он требует не только высокого профессионализма системного интегратора, но и специальных диагностических средств. Основная сложность состоит в том, что пользователь, как правило, не имеет достаточных специальных знаний, чтобы самостоятельно выработать и изложить требования к сети. Это должен сделать профессиональный системный интегратор. Однако, поскольку процесс выработки требований к сети сложен и дорог, пользователь редко готов оплачивать эту работу. Ему психологически проще купить дорогое оборудование. Не спешат браться за такие работы и системные интеграторы: им выгоднее продать дорогое оборудование. В итоге в проигрыше оказывается пользователь. В лучшем случае он только сильно переплачивает за оборудование, приобретая избыточную пропускную способность или функции оборудования, которые реально ему не нужны. Через год-два, когда дополнительная пропускная способность ему понадобится, аналогичное оборудование будет стоить существенно дешевле. В худшем для себя случае пользователь будет вынужден заменить оборудование или смириться с медленной работой прикладных программ. Скупой платит дважды.

Ввод сети в эксплуатацию без тестирования и отсутствие средств диагностики при ее эксплуатации

Очень многих проблем в сети можно избежать, если качественно провести тестирование сети на этапе ее приемки у системного интегратора. Прежде всего это относится к сертификации кабельного хозяйства на соответствие стандартам и тестированию сетевого оборудования на наличие скрытых дефектов. Правилом хорошего тона для системного интегратора является не только проведение тестирования, но и внесения его данных в паспорт сети, предоставляемый пользователю. Лучше всего проводить тестирование "стрессовым" методом. На практике тестирование сети на этапе приемки проводится очень редко. В результате пользователь может получить сеть со скрытыми дефектами. Скрытые дефекты редко проявляются сразу после начала эксплуатации сети, так как на начальных этапах нагрузка в сети мала. Дефект может проявиться значительно позже, создав у пользователя впечатление, что он явился следствием каких-то модификаций в сети. О средствах сетевой диагностики говорится много, и в их необходимости, как правило, никого убеждать не надо. Однако многие администраторы сетей из-за недостатка опыта испытывают сложности с интерпретацией диагностических данных и могут неправильно определить причину замедления работы сети. Следствием этого могут быть неправильные действия по ее модификации.

Плохое качество кабельной системы питания компьютеров, включенных в локальную сеть, статическое электричество

Очень много проблем в локальных сетях связано с плохим качеством кабельной системы питания компьютеров и сетевого оборудования. Особенно сильно качество кабельной системы питания сказывается на работе сетей, построенных на коаксиальных кабелях. Если проблемы, связанные с плохим качеством питающего напряжения, очевидны и решаются установкой источников бесперебойного питания (ИБП), то проблемы, связанные с кабельной системой питания, не столь очевидны. Наиболее типичными дефектами кабельной системы электропитания являются: отсутствие общего единого контура заземления, отсутствие выделенной системы электроснабжения для компьютеров, подключенных к локальной сети, "решетчатая", а не радиальная топология проводов заземления (т. е. наличие множества точек заземления) и др. Настоящим бедствием для локальной сети может быть массовое использование не приспособленных для работы в локальной сети ограничителей напряжения. Ситуация осложняется тем, что Правила Устройства Электроустановок (ПУЭ) и Строительные Нормы и Правила (СНиП), регламентирующие правила построения кабельных систем электроснабжения, не учитывают требований к этим системам, налагаемых локальными сетями. Поскольку сети питания часто проектируются организациями, руководствующимися в своей деятельности только ПУЭ и СНиП, проблемы закладываются уже на этапе разработки проекта здания. Часто большое число сбоев и плохая работа оборудования связаны с наличием статического электричества в помещениях. Основным источником статического электричества в офисах являются ковровые покрытия (ковролин). Проходя по такому покрытию, человек накапливает на себе большой электрический заряд, который затем разряжается на клавиатуру компьютера. В результате клавиатура перестает реагировать на нажатие клавиш и создается иллюзия, что компьютер "зависает". Решение проблемы может быть в использовании специальных антистатических ковровых покрытий, увлажнении воздуха или применении специальных заземленных ковриков или пластин.

В сети используется недостаточно отлаженное прикладное ПО

Отечественные разработчики прикладного ПО в пылу конкурентной борьбы основное внимание уделяют функциональным свойствам разрабатываемого ими ПО. При этом вопросы корректной работы ПО в различных сетевых конфигурациях отходят на второй план, тем более, что разработчики часто не имеют возможности протестировать работоспособность ПО в сложных сетевых конфигурациях. Они молчаливо исходят из того, что, если прикладное ПО корректно работает на 10--15 компьютерах в их офисе, то оно будет работать корректно и при любой другой сетевой конфигурации. Практика показывает, что это не так. Хорошим признаком того, что фирма - разработчик прикладного ПО проводила тестирование собственного ПО в различных сетевых конфигурациях, является наличие в эксплуатационной документации рекомендаций по настройке параметров ПО для работы в различных сетевых конфигурациях или требований, которым должна удовлетворять локальная сеть. Если же таких рекомендаций или требований не приводится, велика вероятность того, что фирма-разработчик не проводила серьезного тестирования своего ПО.
Назад Содержание Вперед