Особенности применения протокола GLBP в мультисервисных ЛВС
Протокол GLBP является одним из немногих протоколов резервирования, которые способны обеспечивать управляемое динамическое распределение нагрузки между компонентами резервирующей группы, и, безусловно, может быть рекомендован к применению в современных мультисервисных ЛВС.
Также вам может показаться, что такая тема как http://androidis.ru/applications/shopping/1161-barcode_scanner.html никак не связана и даже не тематична. Хотя, может быть и связана. В любом случае все-таки зайдите на сайт androidis.ru. Тема сканер штрих кода для android там представлена весьма широко. На том сайте можно узнать много интересного на тему сканер штрих кода для android. Что означает вообще тема сканер штрих кода для android, где найти сканер штрих кода для android - про это написано на сайте androidis.ru. Это очень важная для многих людей тема - сканер штрих кода для android. Спасибо сайту androidis.ru за информацию на тему сканер штрих кода для android.
К факторам, ограничивающим возможность внедрения протокола GLBP в мультисервисные ЛВС, в первую очередь следует отнести:
отсутствие промышленного стандарта или открытой спецификации протокола;
отсутствие поддержки этого протокола производителями системного программного обеспечения.
Таким образом, наиболее оправданным при построении мультисервисной ЛВС следует считать использование протокола GLBP для динамического резервирования магистральных маршрутизирующих коммутаторов.
Протокол CARP
Протокол CARP (Common Address Redundancy Protocol) предназначен для обеспечения динамического резервирования серверов и шлюзов, которые работают под управлением операционных систем, развиваемых в рамках проекта OpenBSD.
Хотя протокол CARP имеет некоторые черты, которые делают его похожим на HSRP или VRRP, он является самостоятельным протоколом и обеспечивает возможность реализации дополнительных функций.
Так же, как и протоколы HSRP и VRRP, протокол CARP используется для взаимодействия компонентов резервирующей группы.
Каждая резервирующая группа представляется протоколом CARP в виде виртуального интерфейса сагрХ, где X = 0, 1, ... п — номер интерфейса. Этому интерфейсу присваиваются номер виртуального узла vhid, IP-адрес, приоритет и значения других необходимых параметров.
Основные особенности протокола CARP
В качестве главного отличия от предшествующих протоколов динамического резервирования создатели протокола CARP отмечают развитую систему аутентификации компонентов резервирующей группы. Однако целесообразность наличия такой системы у протокола подобного рода не кажется бесспорной. Действительно, для успешного применения протокола динамического резервирования необходимо, чтобы все компоненты резервирующей группы находились в пределах одного сегмента ЛВС. Поэтому сообщения, которыми обмениваются компоненты резервирующей группы, не могут ни уходить за пределы этого сегмента, ни приходить из-за его пределов. Если к тому же принять во внимание то, что резервируемое оборудование подключается, как правило, к центральному, наиболее защищенному сегменту ЛВС, то становится понятно, почему разработчики протокола VRRP отказались от использования аутентификации во второй версии протокола.
Еще одним полезным отличием CARP от протоколов HSRP и VRRP является наличие функции распределения нагрузки между компонентами резервирующей группы. Впрочем, в отличие от схемы, использованной в протоколе GLBP, это распределение выполняется по достаточно упрощенным правилам и принципиально не может обеспечить реального выравнивания нагрузок.
Для реализации такого распределения, например, в резервирующей группе, состоящей из двух серверов А и В, предлагается создать на каждом из них по два виртуальных узла (1 и 2) с одним и тем же IP-адресом. Приоритеты серверов при этом следует установить таким образом, чтобы сервер А, например, выполнял функцию активного сервера для узла 1, а сервер В выполнял функцию активного сервера для узла 2. После включения функции выравнивания па обоих серверах (net.inet.carp.arpbalance = 1), они будут выполнять анализ адреса источника поступающих ARP-запросов с тем, чтобы определить номер виртуального узла, который будет его обрабатывать. Поскольку каждому из виртуальных узлов соответствует только один реальный сервер, часть запросов при этом будет обработана на сервере А, а оставшиеся запросы — на сервере В. При отказе одного из серверов, например А, оба виртуальных узла на оставшемся сервере В перейдут в активное состояние, и при продолжении действия функции выравнивания все последующие запросы будут обрабатываться именно на этом сервере.
Полезной функцией протокола CARP является автоматическая трассировка состояния физических интерфейсов сервера. При аварии на таком интерфейсе приоритеты на всех виртуальных интерфейсах сагрХ данного сервера устанавливаются равными 240.
Опубликовал katy
June 14 2015 16:57:56 ·
0 Комментариев ·
2637 Прочтений ·
• Не нашли ответ на свой вопрос? Тогда задайте вопрос в комментариях или на форуме! •
Комментарии
Нет комментариев.
Добавить комментарий
Рейтинги
Рейтинг доступен только для пользователей.
Пожалуйста, залогиньтесь или зарегистрируйтесь для голосования.
Нет данных для оценки.
Гость
Вы не зарегистрированны? Нажмите здесь для регистрации.
Главная
Каталог файлов
