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

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

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

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

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


Rambler's Top100

  

Отказы? Никогда!

Питер Морриси

Новые приложения типа IP-телефонии повышают требования к уровню готовности сетей и снижению возможного времени их простоя. Поэтому настало время рассмотреть новые способы обеспечения бесперебойной работы. Резервируя оборудование и каналы связи и используя такие протоколы, как VRRP, IEEE 802.1w и OSPF-ECMP, вы можете избавиться от единых точек отказа в сети. Будучи стандартизированными, указанные протоколы эффективны и в мультивендорной сети, т. е. в сети, построенной на оборудовании разных производителей.

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

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

Начните с магистрали

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

Магистраль сети обычно пропускает большую часть трафика, и выход ее из строя затрагивает большинство пользователей. Если резервный маршрутизатор или коммутатор при какой-то неполадке готов вступить в действие автоматически, то простой системы резко сократится и разрешение проблемы вместо нескольких часов ручной работы займет всего несколько секунд. Схема, при которой применяются идентичные магистральные маршрутизаторы и резервный готов вступить в действие в случае отказа основного, называется схемой HA (от High Availability — высокая готовность). Оборудование следующего уровня — агрегирования трафика — должно быть соединено с каждым из маршрутизаторов (см. рису-нок); дополнительно это обеспечивает определенное резервирование самих соединительных каналов и позволяет устанавливать магистральные маршрутизаторы в географически разных местах.

Подходящие протоколы

Теперь, когда ваша сеть имеет избыточные каналы, надо решить, каким образом сетевые устройства будут выбирать маршруты для передачи пакетов данных и как исключить образование маршрутных петель. Это не новая задача. Методы пересылки трафика по резервным маршрутам предусмотрены и в протоколе остовного дерева (STP, уровень 2), и в протоколах маршрутизации уровня 3 — например, в OSPF. Но протоколу OSPF для изменения маршрутов передачи трафика в случае аварии может потребоваться до 30 с, а протоколу STP — еще больше. В критически важных сетевых инфраструктурах это неприемлемо, особенно для речевых и видеоприложений, исполняемых в режиме реального времени.

Обновленная версия STP — Rapid STP (RSTP) сокращает время сходимости примерно до 1 с. Один из недостатков RSTP (и STP) заключается в том, что в схеме “активного резервирования” в каждый момент времени активным может быть только один резервный канал. Кроме того, при изменении активного маршрута указанными протоколами может потребоваться изменить адрес шлюза по умолчанию, прописанный на клиентах. Чтобы исключить эти проблемы, можно на маршрутизаторах вместе с STP и RSTP запустить и протокол VRRP. При этом для обоих магистральных маршрутизаторов (основного и резервного) используется один адрес — адрес виртуального маршрутизатора — и восстановление после отказа занимает всего около 3 с.

Но, так как протоколы VRRP и RSTP работают независимо, возможна ситуация, что VRRP “назначит” на роль основного устройства (master) один маршрутизатор, а RSTP в качестве предпочтительного выберет маршрут к другому (резервирующему “с точки зрения” VRRP). В худшем случае этот маршрутизатор немедленно перенаправит трафик на обработку основному устройству, что будет означать дополнительный переход (hop).

Есть еще один вариант: в магистральном маршрутизаторе и в коммутаторах уровня агрегирования трафика задействовать протокол OSPF. Он контролирует состояние каналов, и при выходе из строя одного из каналов переключение на другой занимает менее 1 с. Если вы не резервируете коммутаторы на уровне агрегирования, то дополнять OSPF протоколом VRRP не нужно: клиенты в качестве адреса шлюза по умолчанию будут использовать адрес единственного коммутатора уровня агрегирования. Большинство современных OSPF-маршрутизаторов и коммутаторов поддерживают и алгоритм ECMP; это новейшее дополнение к OSPF обеспечивает равномерное распределение нагрузки по двум каналам. В данном случае всегда активны оба канала и, когда отказывает один из них, затрагивается только половина трафика.

Распределение нагрузки означает также, что теоретически в вашем распоряжении находится суммарная пропускная способность обоих каналов. Однако, если оба канала будут заполнены трафиком, вы не обеспечите полноценной избыточности. При отказе одного канала суммарный объем трафика превысит пропускную способность оставшегося канала, и результаты окажутся непредсказуемыми. Эту проблему в какой-то мере можно смягчить посредством механизмов качества обслуживания (QoS): они позволят пересылать наиболее приоритетный трафик и сбрасывать низкоприоритетный. Но с учетом низкой стоимости единицы пропускной способности ЛВС лучше заменить имеющиеся каналы более скоростными и обеспечить полноценную избыточность системы.

Обратим внимание читателей еще на одно слабое место протокола OSPF: хотя в случае отказа одного канала связи OSPF-устройство способно немедленно перенаправить трафик в другой канал, оно не всегда может быстро получить информацию об аварии на маршруте. Предположим, что между магистральным маршрутизатором и коммутатором уровня распределения имеется межсетевой экран или еще один коммутатор. Тогда, если маршрутизатор выходит из строя, состояние канала на коммутаторе уровня распределения не изменится, поскольку напрямую они не соединены. Дальше все зависит от функции “обмен приветствиями” (Hello) OSPF, которая служит для проверки состояния соседних устройств. По умолчанию сообщения Hello посылаются каждые 10 с, и только при отсутствии ответа на четыре таких сообщения подряд устройство OSPF считает, что его сосед вышел из строя.

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

По мере продвижения к периферии сети вы можете ликвидировать еще ряд потенциальных точек отказа. Например, можно соединить каждый из коммутаторов рабочей группы с двумя коммутаторами уровня распределения так, чтобы при отказе одного из них оставался бы резерв. Это означает также, что каждый коммутатор рабочей группы будет иметь два up-link-соединения — по одному с каждым из “вышестоящих” коммутаторов, а, следовательно, сеть приобретает еще большую избыточность.

Существует простой вариант резервирования связи между любыми двумя коммутаторами: применение протокола IEEE 802.3ad, который позволяет объединять несколько физических линий связи в единый виртуальный канал с большей пропускной способностью. Трафик распределяется между линиями связи, и если одна из них выходит из строя, то трафик из нее перенаправляется в оставшиеся.

Недостаток протокола 802.3ad — в том, что он позволяет резервировать связь только между двумя коммутаторами; нельзя, чтобы из одного коммутатора шли два соединения в два других коммутатора. Однако этот протокол можно использовать, когда два соединения из коммутатора идут к двум разным интерфейсным модулям магистрального коммутатора, что обеспечивает дополнительное резервирование на уровне модулей и портов. Некоторые производители предоставляют возможность использовать протокол 802.3ad для связи коммутатора уровня распределения с двумя разными магистральными коммутаторами, которые для “окружающего мира” выглядят как одно устройство.

Лучший опыт

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

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

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





  
13 '2006
СОДЕРЖАНИЕ

бизнес

• Зачем Cisco ребрэндинг

инфраструктура

• Отказы? Никогда!

• Прокладываем курс в море стандартов ИТ

• Построение дискового массива iSCSI

• Средства планирования БЛВС

• Построение и эксплуатация ЦОДов: как избежать ошибок

информационные системы

• Цифровые права на доступ к корпоративным данным

• Управление сервисами «снизу вверх» и «сверху вниз»

кабельные системы

• Оптические разъемы для высокоплотных инсталляций

• PoE Plus и UTP-проводка

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

• На страже границ БЛВС

• Выберите защиту для своих данных


• Калейдоскоп



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