Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Полезные привычки, или Как избежать ночных кошмаров

Брюс Робертсон

Воспитать в себе полезные привычки, как-то: посещение клуба здоровья, правильное питание, ограничение времени, проводимого у телевизора, или пристегивание ремней безопасности — очень непросто. Но, если уж они войдут в силу и станут «второй натурой», вам больше не потребуется упорства для их поддержания.

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

Учитывайте влияние приложений на сетевую инфраструктуру

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

К сожалению, это часто делается лишь после того, как выяснится, что базовое приложение требует установки стека TCP/IP на каждой настольной системе, а в распределенной сети необходимы серьезные преобразования, чтобы повысить ее производительность. Более того, разработчики приложений часто совсем не задумываются о проблемах распределенных сетей и программируют только в расчете на скорости ЛВС.

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

Лучше один раз увидеть...

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

Мы рекомендуем предоставить разработчикам возможность увидеть собственными глазами, во что выливается их безответственность при создании приложений для реальной сети. Организуйте испытательную лабораторию. Подготовьте комплект принятых у вас корпоративных приложений для их тестирования на предполагаемых локальных и территориальных сетях. Основная цель — выработать стандарт для испытания новых приложений, с тем чтобы определить их влияние на работу всей информационной системы. Смоделируйте в тестовой сети, насколько это возможно, все основные типы сетевых связей, используемых в вашей организации. В случае применения у вас канала Frame Relay, включите и такой участок — не ограничивайтесь тестированием только в пределах соединений маршрутизаторов с одинаковыми портами. Установите дополнительные средства поддержки сетевых программ, такие, как сервер приложений WinFrame фирмы Citrix Systems. Проделав все это, предоставьте своим разработчикам возможность испытывать свои программы в условиях, максимально приближенных к реальной сети.

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

Например, вы были бы изрядно удивлены, если бы обнаружили, насколько различаются между собой способы сетевого взаимодействия модулей внутри таких прикладных индустриальных систем, как SAP R/3, PeopleSoft и Baan. В первой используется высокопроизводительный механизм RPC (Remote Procedure Call) собственной разработки, во второй — достаточно ресурсоемкое связующее ПО, а в третьей — протокол, аналогичный X Windows. Понимание принципов функционирования приложения позволяет специалистам по развитию инфраструктуры лучше предсказывать их влияние на загрузку сети и возможные задержки. В самом деле, на рынке стали появляться специализированные средства управления, ориентированные на мониторинг сетевого трафика, и модули планирования для основных приложений наподобие SAP R/3 и Lotus Notes.

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

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

«Уход» за приложениями

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

Программные средства управления, такие, как EcoSCOPE фирмы Compuware и NetMaker/SA фирмы Make Systems, ориентированы на мониторинг трафика наиболее распространенных приложений. Контроль за внедрением последних в реальной сети на всем множестве представленных конфигураций, которые просто не могут быть смоделированы в лабораторных условиях, позволяет проверить сделанные ранее выводы. Подобные системы помогают выявлять причину неоправданно медленной работы приложений: то ли на них влияют другие приложения, то ли это связано с сетевыми задержками, или же проблема заключается в самом приложении. Однако нельзя забывать и про более общие средства мониторинга, такие, как Sniffer: их помощь понадобится вам на протяжении всего периода внедрения и эксплуатации новых приложений. Кроме того, на изучение специализированных продуктов требуется время, в течение которого систему все равно нужно как-то поддерживать.

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

Мы убедились, что для практических целей в организации гораздо интереснее отслеживать не просто сетевой трафик, а нагрузку конкретного приложения на канал, например распределенной сети. Одна компания показала мне круговую диаграмму статистики загрузки распределенной сети, 75% трафика в которой составляла эмуляция терминала офисного пакета All-in-One фирмы Digital Equipment. Переход к клиент-серверной архитектуре обмена сообщениями поможет значительно разгрузить каналы распределенной сети (хотя, конечно, большие почтовые сообщения в итоге могут вновь изрядно «забить» медленную сеть).

Инструменты мониторинга становятся неотъемлемым атрибутом информационной системы. Некоторые программисты даже встраивают средства измерения производительности непосредственно в приложения для оповещения центральной консоли об аварийном состоянии. Вообще говоря, такими возможностями, хотя бы в ограниченном виде, должны обладать все современные приложения.

На рынке стали появляться такие продукты, как IPath фирмы Structured Internetworks или PacketShaper фирмы Packeteer. Они позволяют контролировать трафик путем предотвращения неожиданных всплесков сетевой активности приложений, обеспечивающих доступ к службе Web, передачу файлов, печать или электронную почту. Иногда производители программ встраивают ограничители трафика непосредственно в свои продукты. Так, почтовый агент (Mail Transfer Agent — MTA) из пакета Exchange фирмы Microsoft способен ограничить свой трафик до 56 Кбит/с, даже если он работает через канал T1. Это позволяет высвобождать необходимую полосу пропускания для критически важных приложений, несмотря на то, что гарантированное качество обслуживание еще недоступно для вашей IP-сети. Таким образом, ваша сеть по своей предсказуемости приблизится к технологии SNA.

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





  
1 '1998
СОДЕРЖАНИЕ

колонка редактора

• Главные мысли о старом

локальные сети

• Коммутаторы и сетевые адаптеры Gigabit Ethernet

• Медные провода "протянут" до XXI века

• "5–4–3" — формула успеха

• Краткий англо-русский толковый словарь терминов СКС

• Нахождение отказов в высокопроизводительных ЛВС

корпоративные сети

• Предприятие как единый объект автоматизации. Размышления на тему

• Теряет ли АТМ свою привлекательность?

• Полезные привычки, или Как избежать ночных кошмаров

• Исследование схем тиражирования в распределенных БД

системы учрежденческой связи

• CTI: подружились компьютер с телефоном

• Учрежденческий радиопейджинг: связь внутри предприятий

услуги сетей связи

• Устройства доступа к Frame Relay

• Передача голоса по сетям АТМ (часть I)

• Телевидение: от эфирного к кабельному и далее...

интернет и интрасети

• Реализация push-технологии: JavaScript против CDF

• Факсимильная связь через Интернет

• Что могут ISP?

защита данных

• Иерархические системы хранения данных

• Исповедь взломщика-консультанта

новые продукты

• Коммутатор NH2024 фирмы NBase, Диагностический прибор для линий xDSL, Стековая система удаленного доступа фирмы 3Com, Шлюз BayStack Instant Internet II, Маршрутизирующие коммутаторы: гонка со скоростью, Coral SL — малая система с большими возможностями

бизнес

• Продолжая лучшие традиции (интервью президента АО "Информсвязь" М. Б. Купермана)

• Внимание: РИФ!

только на сервере

• Организация множественного доступа в Интернет

• xDLS-модем ASMi-50 фирмы RAD data communications



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх