о насотзывыпубликациипартнерствовакансии

к выбору публикации

Кто виноват и что делать, чтобы не было проблем с локальной сетью Сергей Юдицкий

Четырнадцатое июня, пятница. В банке аврал. Оборот денежной массы в несколько раз превысил обычный. У стойки операционистов длинная очередь. Руководство требует отчета о состоянии балансовых счетов, размещенных и привлеченных средств. Идет подготовка отчетной документации. И тут локальная сеть банка, которая до этого полгода работала нормально, внезапно начинает давать сбои или работать недопустимо медленно. Рабочие станции периодически "замирают" или самопроизвольно отключаются от сети, иногда "зависают". Информация, хранящаяся на файл-сервере, бесследно исчезает или искажается. Прикладная программа выдает трудно объяснимые сообщения, например, что невозможно открыть какой-то каталог или истекло какое-то время ожидания. Создается впечатление, что сеть тихо "умирает". Грустная картина, не правда ли?

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

Администратор локальной сети обычно утверждает, что причина плохой работы сети в ошибках прикладного ПО. При этом в доказательство своей правоты он приводит примеры другого ПО, при работе которого никаких сбоев не наблюдается.

По роду занятий мне часто приходится выступать арбитром в такого рода спорах. Мой опыт показывает, что в большинстве случаев "виноваты" обе стороны. Сам факт такого спора означает, что ни одна из сторон не знает, как выявить причину неадекватного поведения сети и как ее устранить.

Отсутствие средств и методики диагностики у администратора сети означает, что он не контролирует ее состояние. При этом изменение режима эксплуатации сети, связанное с внедрением нового ПО, может приводить к появлению нарушений, которые до этого не возникали или проявлялись редко.

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

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

Диагностика локальных сетей

Диагностика локальной сети -- это комплекс мероприятий, который включает в себя несколько видов тестирования:

-	тестирование кабельного хозяйства;
-	выявление скрытых дефектов оборудования и системного ПО;
-	оценка качества архитектурного решения сети, т. е. определение ее пропускной способности и узких мест, степени сбалансированности ее различных компонентов по нагрузке и т. п.

Часто под диагностикой сети понимается только тестирование кабельного хозяйства: измерение физических характеристик линий связи. Это неверно. Тестирование кабельного хозяйства является безусловно важной составляющей диагностики, но отнюдь не единственной и не самой сложной. Есть много специальных приборов: кабельных анализаторов или кабельных сканеров, которые сильно упрощают ее решение.

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

Реакция пользователей и администраторов сетей на эти дефекты часто неадекватна. Не раз я был свидетелем того, как в случае "зависаний" оборудования администратор сети принимал решение о полной его замене, хотя достаточно было заменить только версию драйвера сетевой карты.

Существуют два основных подхода к выявлению скрытых дефектов и оценке качества архитектуры локальной сети: пассивная диагностика и стрессовое тестирование.

Метод пассивной диагностики состоит в постоянном (во всяком случае, длительном) наблюдении за состоянием сети и регистрации изменений в ее поведении. Он основан на использовании специальных средств пассивного наблюдения за работой сети: анализаторов протоколов (типа LANAlyzer for Windows фирмы Novell) или программ на основе протокола SNMP (типа OpenView фирмы HP или SNIFFER фирмы Network General). Этот метод получил очень широкое распространение, и сегодня уже сущестуют диагностические средства, содержащие встроенную экспертную систему, которая упрощает процесс диагностики.

Метод стрессового тестирования состоит в создании в сети большой нагрузки и проверке ее работоспособности в этих экстремальных условиях. Примером диагностической программы, в которой реализован метод стрессового тестирования, является программа FTest фирмы ПРОЛАН.

Метод стрессового тестирования дополняет метод пассивной диагностики. Он позволяет проверить сеть в экстремальных условиях эксплуатации и построить "систему координат", облегчающую интерпретацию данных, полученных в результате пассивной диагностики.

Обычно метод стрессового тестирования используется на этапе пуско-наладки сети и после существенных модификаций ее архитектуры или топологии. Метод пассивной диагностики целесообразно использовать в процессе эксплуатации сети после уже проведенного стрессового тестирования.

В чем корень зла?

За последние годы мы провели диагностику большого числа локальных сетей. В основном это были сети Ethernet c числом пользователей от 50 до 400. Наши исследования позволили выделить несколько типовых причин, приводящих к неадекватному поведению локальных сетей.

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

Одной из наиболее распространенных причин плохой работы локальной сети является стихийное развитие ее кабельного хозяйства из-за отсутствия стратегии ее расширения.

Часто локальная сеть создается в условиях жесткой экономии средств, что сказывается на принимаемых технических решениях. Пока сеть невелика и пользуется ею не больше 30--40 человек, она работает без сбоев. По мере развития банка постепенно расширяется и локальная сеть. Пользователи переезжают из одного помещения в другое, и локальная сеть охватывает все большее число помещений. При некотором критическом числе станций в сети появляются сбои. Техническое решение, которое было приемлемо для малой сети, становится тормозом ее развития или причиной сбоев.

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

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

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

Еще несколько лет назад приобретать сетевое оборудование под прикладную задачу казалось абсурдом: а что делать, когда прикладная задача изменится?

Сегодня стоимость прикладного ПО не только соизмерима со стоимостью сетевого оборудования, но часто существенно больше последней. Абсурдом становится приобретение оборудования без учета специфики прикладного ПО.

Учет специфики прикладного ПО не следует понимать слишком буквально. Он вовсе не означает, что никакое другое ПО работать в сети не сможет. Учет специфики прикладного ПО нужен при выборе требований к пропускной способности, которым должны удовлетворять как архитектура сети, так и сетевое оборудование. Прежде всего следует оценить необходимый минимум пропускной способности. Будет ли эта минимальная пропускная способность достаточной и какой запас по пропускной способности должен быть заложен в проекте, -- это уже вопрос стратегии и финансовых возможностей пользователя.

Учет специфики эксплуатируемого в сети прикладного ПО -- это длительный и дорогостоящий процесс. Он требует не только высокого профессионализма системного интегратора, но и специальных диагностических средств.

Основная сложность состоит в том, что пользователь, как правило, не имеет достаточных специальных знаний, чтобы самостоятельно выработать и изложить требования к сети. Это должен сделать профессиональный системный интегратор. Однако, поскольку процесс выработки требований к сети сложен и дорог, пользователь редко готов оплачивать эту работу. Ему психологически проще купить дорогое оборудование. Не спешат браться за такие работы и системные интеграторы: им выгоднее продать дорогое оборудование.

В итоге в проигрыше оказывается пользователь. В лучшем случае он только сильно переплачивает за оборудование, приобретая избыточную пропускную способность или функции оборудования, которые реально ему не нужны. Через год-два, когда дополнительная пропускная способность ему понадобится, аналогичное оборудование будет стоить существенно дешевле.

В худшем для себя случае пользователь будет вынужден заменить оборудование или смириться с медленной работой прикладных программ. Скупой платит дважды.

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

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

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

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

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

Очень много проблем в локальных сетях связано с плохим качеством кабельной системы питания компьютеров и сетевого оборудования. Особенно сильно качество кабельной системы питания сказывается на работе сетей, построенных на коаксиальных кабелях.

Если проблемы, связанные с плохим качеством питающего напряжения, очевидны и решаются установкой источников бесперебойного питания (ИБП), то проблемы, связанные с кабельной системой питания, не столь очевидны.

Наиболее типичными дефектами кабельной системы электропитания являются: отсутствие общего единого контура заземления, отсутствие выделенной системы электроснабжения для компьютеров, подключенных к локальной сети, "решетчатая", а не радиальная топология проводов заземления (т. е. наличие множества точек заземления) и др. Настоящим бедствием для локальной сети может быть массовое использование не приспособленных для работы в локальной сети ограничителей напряжения.

Ситуация осложняется тем, что Правила Устройства Электроустановок (ПУЭ) и Строительные Нормы и Правила (СНиП), регламентирующие правила построения кабельных систем электроснабжения, не учитывают требований к этим системам, налагаемых локальными сетями. Поскольку сети питания часто проектируются организациями, руководствующимися в своей деятельности только ПУЭ и СНиП, проблемы закладываются уже на этапе разработки проекта здания.

Часто большое число сбоев и плохая работа оборудования связаны с наличием статического электричества в помещениях. Основным источником статического электричества в офисах являются ковровые покрытия (ковролин). Проходя по такому покрытию, человек накапливает на себе большой электрический заряд, который затем разряжается на клавиатуру компьютера. В результате клавиатура перестает реагировать на нажатие клавиш и создается иллюзия, что компьютер "зависает".

Решение проблемы может быть в использовании специальных антистатических ковровых покрытий, увлажнении воздуха или применении специальных заземленных ковриков или пластин.

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

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

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

Заключение

Пользователи! Требуйте от системного интегратора обоснования предлагаемых вам технических решений. В противном случае вы можете получить сеть, которая будет не вполне отвечать вашим ожиданиям. После установки сети проведите ее серьезную проверку. Приобретение качественного оборудования и ПО еще не означает, что в комплексе они будут работать так, как вам бы хотелось.

наверх