Азбука локальной сети
О локальных сетях сказано очень много, однако за этим скучным заголовком я попытаюсь поговорить о проблемах, которые хорошо знакомы специалистам, чья работа хоть как-то сопричастна вопросам проектирования либо эксплуатации ЛВС. Мне приходилось достаточно продолжительное время работать как в государственных, так и в частных учреждениях и в качестве проектировщика — исполнителя проектов ЛВС, и в составе служб эксплуатации и сопровождения. Поэтому мне хорошо знакомы проблемы ЛВС как на стороне заказчика, так и на стороне исполнителя. Сегодня сети — это привычный атрибут любого предприятия. Сетевые технологии отработаны, и большинство проблем возникает не столько в технической части, сколько в организационных вопросах. Сеть будет хорошо работать, если она хорошо спланирована и адекватна той совокупности задач, которые подразделение решает средствами ЛВС. Эта азбука, которая очень редко соответствует действительности, особенно на государственных предприятиях, где проблемы высококвалифицированных кадров в области информационных технологий, особо актуальна. Все, о чем пойдет речь дальше — весьма простые и очевидные вещи, но, как показывает практика, причины проблем при проектировании и эксплуатации сетей весьма часто ищутся где угодно, только не там, где они есть.
Топология и оборудование
Сеть начинается с проекта и концепции топологии. Существуют различные мнения о том, как разводить сеть. Одно бесспорно: еще на этапе проектирования может быть заложена основа будущих проблем. При построении ЛВС на характер разводки влияют различные критерии: доступная стоимость проекта, технические характеристики, объемы и направления информационных потоков, расположение рабочих помещений. В числе названных последняя в наибольшей степени определяет топологию. Небольшая сеть с компактным расположением помещений в пределах одного этажа может быть разведена через единственный коммутатор вблизи сервера. Если помещения удалены и, тем более, расположены на разных этажах, туда же должны "уйти" и коммутаторы. Мне много раз доводилось наблюдать разводку "в одну точку" многоэтажного здания, еще хуже, если эта точка представляет собой несколько коммутаторов, включенных в каскад. Еще хуже, если сервер сильно удален от центральной части здания. Сторонники разводки "чистая звезда" не без оснований могут возражать: это делается для повышения производительности. Как показывает практика, такая сеть будет иметь высокую производительность только на момент ввода в эксплуатацию. Рост предприятия, структурные изменения, в конце концов, простые перемещения персонала требуют установки клиентских компьютеров на новых местах. В результате очень быстро удаленные помещения "обрастают" вторыми каскадами коммутаторов. В этом нет ничего страшного. Я сторонник второго каскада в сети. Плохо то, что в этом случае получаем сеть с неравномерным делением пропускной способности. Если в нашей сети, например, 24 пользователя, и возле одного клиента появляются два новых соседа с новым коммутатором, то относительную пропускную способность на аппаратном уровне для этих трех можно определить как 1/3 от 1/24 против 1/24 до появления каскада (т.е. сокращение в 3 раза). В такой ситуации более равномерное перераспределение пропускной способности будет иметь двухкаскадная сеть, представленная на рис. 1. Например, при добавлении четвертого пользователя в группу первой магистрали изменение составит 1/4 от 1/4 против прежнего отношения 1/3 от 1/4. Мне не нравится слово "панацея". В каждом конкретном случае топология должна проектироваться под заказчика персонально, но представленная структура может быть рекомендована как основа для очень большого количества предприятий.
Однако вернемся к разводке "в одну точку". Еще один недостаток такой сети — при установке каскадов возле сервера лишение коммутатора функции репитера. Если коммутаторы установлены по схеме рис. 1, то свитч второго каскада работает как усилитель, и отсчет допустимо удаленного клиента ведется уже не от сервера, а от этого коммутатора. Для крупного здания 200 м — не длина. С другой стороны, даже если мы не выходим за допустимую удаленность, то 50 метров до коммутатора лучше, чем 150. Когда установки двух или трех коммутаторов в одной точке не избежать, желательно не включать их в каскад, а завести на отдельные сетевые адаптеры сервера. Несомненное достоинство представленной на рис. 1 структуры заключается в том, что в данном случае существенно сокращается общая длина проводки, а установка любой сетевой розетки выполняется с помощью короткого кабеля до ближайшего коммутатора. Количество розеток несложно выбрать не столько из расчета необходимых рабочих мест, сколько из расчета максимально возможного количества компьютеров в помещениях, причем с существенным запасом. При этом надолго решается задача добавления либо перестановки компьютеров в помещениях в процессе эксплуатации сети. Такой компьютер просто подключается к ближайшей свободной розетке. Обсуждая топологию, акцент сделан на сравнении представленного двухкаскадного варианта и "чистой звезды". Существует и другая крайность — бессистемное и необузданное каскадирование коммутаторов. Такие сети в серьезных организациях встречаются редко. Мнение о том, что подобных структур следует избегать, споров не вызывает. Многокаскадные структуры можно встретить, пожалуй, только в домашних сетях, где это не столько планируется, сколько является вынужденным, если не единственно возможным, способом соединить компьютеры.
Производительность сети
В любой сети по мере роста числа пользователей и количества сетевых приложений рано или поздно возникает проблема быстродействия. Я был бы не прав, если бы сказал, что представленная структура более производительна, чем структура "чистая звезда". Однокаскадная сеть действительно будет работать быстрее, но в крупном учреждении только первое, и весьма непродолжительное, время. Забегая вперед, можно сказать: если исчерпаны все возможности повышения производительности, то представленную двухкаскадную структуру легко превратить в оптоволоконную, установив на концах магистралей первого каскада пары конверторов Ethernet-ВОЛС, и заменить витую пару на оптоволоконные линии. В этом случае можно получить гарантированную скорость 1 Гб/с в каждой магистрали и разделенную скорость обмена 100 Мб/с во втором каскаде. Конвертеры выпускаются достаточно давно и стоят сегодня относительно недорого. Аналогичную модернизацию можно выполнить заменив коммутаторы на оптические — правда, это обойдется значительно дороже. В обоих случаях сохраняется большая часть старой разводки, т.е. весь второй каскад. Однокаскадная сеть будущего развития не имеет. Я не представляю, как безболезненно перейти на волоконный вариант ЛВС, когда от каждого компьютера к серверу полноводным потоком стекает водопад витой пары, который с трудом защелкивается в короб максимально возможного сечения. Однако для начала можно отложить радикальные решения и, пока сеть разведена витой парой, попытаться хотя бы на время решить проблемы малыми усилиями. Рано или поздно перегрузка в сети появится, если предприятие имеет хотя бы намек на развитие. Первое, на что следует обратить внимание, — аппаратная часть сети. При построении ЛВС весьма популярно использовать недорогие коммутаторы. Такая экономия оправдана. Нет смысла приобретать сразу дорогое оборудование, если вы точно уверены, что сеть достаточно долго будет недогружена. Важно вовремя заменить их на Cisco, 3COM либо аналогичные по функциональным возможностям. Желательно, чтобы коммутатор поддерживал обмен данными одновременно в нескольких парных направлениях и для перспективы (появления новых сетевых сегментов) позволял маршрутизировать IP-пакеты, разгружая тем самым сервер. В первую очередь, это касается коммутатора первого каскада. Для сети здания средней этажности замены коммутатора первого каскада бывает достаточно. Дешевые коммутаторы можно перенести во второй каскад либо в резерв. Конфигурация самого сервера тоже не в последнюю очередь влияет на скорость работы сети. Если в ЛВС небольших предприятий сервер может отсутствовать вовсе либо его роль может выполнять персональный компьютер типовой клиентской конфигурации, то серьезный набор сетевого ПО и большой штат персонала, безусловно, потребует установки серверного варианта компьютера. При его приобретении стоит обращать внимание не только на объем винчестера и памяти, но и на их быстродействие. Небольшое дополнение: не стоит устанавливать на сервер RAID-контроллер PCI. Лучше отдать предпочтение встроенному RAID-контроллеру, поскольку его быстродействие не ограничено пропускной способностью PCI-шины. Винчестеры стоят не так дорого, чтобы жалеть их для организации "зеркала". Причем именно зеркального RAID-набора. Мне не нравятся все виды чередования. Это скорость, принесенная в жертву надежности. Независимо от мощности сервера, возможно, указанных рекомендаций будет недостаточно для приемлемой производительности сети. В качестве еще одного варианта для ускорения работы можно посоветовать установку второго либо третьего сетевого домена. Везде существуют отделы, например, бухгалтерия, с традиционно повышенной нагрузкой на сервер. Установка дополнительного домена позволит равномерно распределить нагрузку между пользователями по сетевому трафику и объему вычислений для сетевых приложений.
Сетевое ПО — это отдельный разговор. Установкой многочисленных сетевых приложений очень быстро можно исчерпать ресурсы сервера. Причем на производительности сети может отрицательно сказываться не только количество установленных программ, но и их характер. До сих пор можно встретить программистов, которые ведут разработки по технологии простого открытия общего доступа к базам данных из малопроизводительной среды программирования либо, что еще хуже, используют файловый сервер в качестве сервера приложений (исполняемые модули на сервере и только пиктограмма на рабочем столе клиентского компьютера). Для таких программ необходим сервер базы данных, а программное обеспечение должно проектироваться с учетом минимизации сетевого трафика. Помимо программного обеспечения, на любом файловом сервере накапливаются рабочие файлы пользователей, и, если не принимать никаких мер, этот процесс рискует выйти из-под контроля. Информация такого рода не сильно влияет на производительность, но порядок в мыслях должен находить свое продолжение и как порядок на винчестере.
Сетевая политика
Менеджер пользователей сервера содержит очень много опций и выключателей. Microsoft создал этот инструмент администрирования вовсе не для того, чтобы накладывать на работу сетевых клиентов все мыслимые ограничения. Тем не менее, такой подход встречается очень часто. Конечно, администратор сети может найти вполне благовидное объяснение (ограничения распространения вирусов, защита персонала от собственных ошибочных действий), запретить все, что только можно, и чувствовать себя весьма комфортно, не сильно перетруждаясь текущей работой. Однако сеть создается в первую очередь для пользователей. Мне много раз доводилось наблюдать сетевую политику ограничений на грани паранойи. Проще говоря, это тот случай, когда прокладывается проводка, устанавливается сервер, но запустить сеть забывают. Безусловно, бывают особые случаи: закрытые предприятия, учреждения банковской сферы и т.п., где повышенные меры безопасности логичны. Однако чаще всего сетевая политика организации должна быть более мягкой. Наиболее оптимальным решением можно считать ситуацию, когда каждый пользователь сам выбирает состав и способ доступа к собственным ресурсам. Если работа сотрудников имеет разнородный вид, пользователей разумно разбить на группы и продумать сетевую политику в каждой группе. Способ организации общих ресурсов — весьма болезненный вопрос, потому дать однозначные советы трудно.
В завершение последнее пожелание. Качество работы сети в значительной степени зависит от качества проекта и его реализации, опыта администратора, объемов финансирования работ по сопровождению ЛВС. Весьма расхожее среди руководителей заблуждение — сеть установили, и можно прекратить ее дальнейшее финансирование. Сеть требует постоянного обновления, и чем чаще ее модернизируют, тем эффективнее отдача от персонала, который ее эксплуатирует.
Продолжение следует.
Сергей Андросенков, ses@minsktrans.by
Топология и оборудование
Сеть начинается с проекта и концепции топологии. Существуют различные мнения о том, как разводить сеть. Одно бесспорно: еще на этапе проектирования может быть заложена основа будущих проблем. При построении ЛВС на характер разводки влияют различные критерии: доступная стоимость проекта, технические характеристики, объемы и направления информационных потоков, расположение рабочих помещений. В числе названных последняя в наибольшей степени определяет топологию. Небольшая сеть с компактным расположением помещений в пределах одного этажа может быть разведена через единственный коммутатор вблизи сервера. Если помещения удалены и, тем более, расположены на разных этажах, туда же должны "уйти" и коммутаторы. Мне много раз доводилось наблюдать разводку "в одну точку" многоэтажного здания, еще хуже, если эта точка представляет собой несколько коммутаторов, включенных в каскад. Еще хуже, если сервер сильно удален от центральной части здания. Сторонники разводки "чистая звезда" не без оснований могут возражать: это делается для повышения производительности. Как показывает практика, такая сеть будет иметь высокую производительность только на момент ввода в эксплуатацию. Рост предприятия, структурные изменения, в конце концов, простые перемещения персонала требуют установки клиентских компьютеров на новых местах. В результате очень быстро удаленные помещения "обрастают" вторыми каскадами коммутаторов. В этом нет ничего страшного. Я сторонник второго каскада в сети. Плохо то, что в этом случае получаем сеть с неравномерным делением пропускной способности. Если в нашей сети, например, 24 пользователя, и возле одного клиента появляются два новых соседа с новым коммутатором, то относительную пропускную способность на аппаратном уровне для этих трех можно определить как 1/3 от 1/24 против 1/24 до появления каскада (т.е. сокращение в 3 раза). В такой ситуации более равномерное перераспределение пропускной способности будет иметь двухкаскадная сеть, представленная на рис. 1. Например, при добавлении четвертого пользователя в группу первой магистрали изменение составит 1/4 от 1/4 против прежнего отношения 1/3 от 1/4. Мне не нравится слово "панацея". В каждом конкретном случае топология должна проектироваться под заказчика персонально, но представленная структура может быть рекомендована как основа для очень большого количества предприятий.
Производительность сети
В любой сети по мере роста числа пользователей и количества сетевых приложений рано или поздно возникает проблема быстродействия. Я был бы не прав, если бы сказал, что представленная структура более производительна, чем структура "чистая звезда". Однокаскадная сеть действительно будет работать быстрее, но в крупном учреждении только первое, и весьма непродолжительное, время. Забегая вперед, можно сказать: если исчерпаны все возможности повышения производительности, то представленную двухкаскадную структуру легко превратить в оптоволоконную, установив на концах магистралей первого каскада пары конверторов Ethernet-ВОЛС, и заменить витую пару на оптоволоконные линии. В этом случае можно получить гарантированную скорость 1 Гб/с в каждой магистрали и разделенную скорость обмена 100 Мб/с во втором каскаде. Конвертеры выпускаются достаточно давно и стоят сегодня относительно недорого. Аналогичную модернизацию можно выполнить заменив коммутаторы на оптические — правда, это обойдется значительно дороже. В обоих случаях сохраняется большая часть старой разводки, т.е. весь второй каскад. Однокаскадная сеть будущего развития не имеет. Я не представляю, как безболезненно перейти на волоконный вариант ЛВС, когда от каждого компьютера к серверу полноводным потоком стекает водопад витой пары, который с трудом защелкивается в короб максимально возможного сечения. Однако для начала можно отложить радикальные решения и, пока сеть разведена витой парой, попытаться хотя бы на время решить проблемы малыми усилиями. Рано или поздно перегрузка в сети появится, если предприятие имеет хотя бы намек на развитие. Первое, на что следует обратить внимание, — аппаратная часть сети. При построении ЛВС весьма популярно использовать недорогие коммутаторы. Такая экономия оправдана. Нет смысла приобретать сразу дорогое оборудование, если вы точно уверены, что сеть достаточно долго будет недогружена. Важно вовремя заменить их на Cisco, 3COM либо аналогичные по функциональным возможностям. Желательно, чтобы коммутатор поддерживал обмен данными одновременно в нескольких парных направлениях и для перспективы (появления новых сетевых сегментов) позволял маршрутизировать IP-пакеты, разгружая тем самым сервер. В первую очередь, это касается коммутатора первого каскада. Для сети здания средней этажности замены коммутатора первого каскада бывает достаточно. Дешевые коммутаторы можно перенести во второй каскад либо в резерв. Конфигурация самого сервера тоже не в последнюю очередь влияет на скорость работы сети. Если в ЛВС небольших предприятий сервер может отсутствовать вовсе либо его роль может выполнять персональный компьютер типовой клиентской конфигурации, то серьезный набор сетевого ПО и большой штат персонала, безусловно, потребует установки серверного варианта компьютера. При его приобретении стоит обращать внимание не только на объем винчестера и памяти, но и на их быстродействие. Небольшое дополнение: не стоит устанавливать на сервер RAID-контроллер PCI. Лучше отдать предпочтение встроенному RAID-контроллеру, поскольку его быстродействие не ограничено пропускной способностью PCI-шины. Винчестеры стоят не так дорого, чтобы жалеть их для организации "зеркала". Причем именно зеркального RAID-набора. Мне не нравятся все виды чередования. Это скорость, принесенная в жертву надежности. Независимо от мощности сервера, возможно, указанных рекомендаций будет недостаточно для приемлемой производительности сети. В качестве еще одного варианта для ускорения работы можно посоветовать установку второго либо третьего сетевого домена. Везде существуют отделы, например, бухгалтерия, с традиционно повышенной нагрузкой на сервер. Установка дополнительного домена позволит равномерно распределить нагрузку между пользователями по сетевому трафику и объему вычислений для сетевых приложений.
Сетевое ПО — это отдельный разговор. Установкой многочисленных сетевых приложений очень быстро можно исчерпать ресурсы сервера. Причем на производительности сети может отрицательно сказываться не только количество установленных программ, но и их характер. До сих пор можно встретить программистов, которые ведут разработки по технологии простого открытия общего доступа к базам данных из малопроизводительной среды программирования либо, что еще хуже, используют файловый сервер в качестве сервера приложений (исполняемые модули на сервере и только пиктограмма на рабочем столе клиентского компьютера). Для таких программ необходим сервер базы данных, а программное обеспечение должно проектироваться с учетом минимизации сетевого трафика. Помимо программного обеспечения, на любом файловом сервере накапливаются рабочие файлы пользователей, и, если не принимать никаких мер, этот процесс рискует выйти из-под контроля. Информация такого рода не сильно влияет на производительность, но порядок в мыслях должен находить свое продолжение и как порядок на винчестере.
Сетевая политика
Менеджер пользователей сервера содержит очень много опций и выключателей. Microsoft создал этот инструмент администрирования вовсе не для того, чтобы накладывать на работу сетевых клиентов все мыслимые ограничения. Тем не менее, такой подход встречается очень часто. Конечно, администратор сети может найти вполне благовидное объяснение (ограничения распространения вирусов, защита персонала от собственных ошибочных действий), запретить все, что только можно, и чувствовать себя весьма комфортно, не сильно перетруждаясь текущей работой. Однако сеть создается в первую очередь для пользователей. Мне много раз доводилось наблюдать сетевую политику ограничений на грани паранойи. Проще говоря, это тот случай, когда прокладывается проводка, устанавливается сервер, но запустить сеть забывают. Безусловно, бывают особые случаи: закрытые предприятия, учреждения банковской сферы и т.п., где повышенные меры безопасности логичны. Однако чаще всего сетевая политика организации должна быть более мягкой. Наиболее оптимальным решением можно считать ситуацию, когда каждый пользователь сам выбирает состав и способ доступа к собственным ресурсам. Если работа сотрудников имеет разнородный вид, пользователей разумно разбить на группы и продумать сетевую политику в каждой группе. Способ организации общих ресурсов — весьма болезненный вопрос, потому дать однозначные советы трудно.
В завершение последнее пожелание. Качество работы сети в значительной степени зависит от качества проекта и его реализации, опыта администратора, объемов финансирования работ по сопровождению ЛВС. Весьма расхожее среди руководителей заблуждение — сеть установили, и можно прекратить ее дальнейшее финансирование. Сеть требует постоянного обновления, и чем чаще ее модернизируют, тем эффективнее отдача от персонала, который ее эксплуатирует.
Продолжение следует.
Сергей Андросенков, ses@minsktrans.by
Компьютерная газета. Статья была опубликована в номере 15 за 2006 год в рубрике сети
