По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Протокол связующего дерева (STP) был первоначально разработан Radia Perlman и впервые описан в 1985 году в Алгоритме распределенного вычисления связующего дерева в расширенной локальной сети.
1 STP уникален в списке рассматриваемых здесь плоскостей управления, поскольку изначально был разработан для поддержки коммутации, а не маршрутизации. Другими словами, STP был разработан для поддержки переадресации пакетов без времени жизни (TTL) и без подкачки заголовка per hop коммутационным устройством. Пакеты, коммутируемые на основе STP, передаются по сети без изменений.
Построение дерева без петель
Процесс построения дерева без петель выглядит следующим образом:
Каждое устройство переводит все порты в заблокированный режим, чтобы ни один порт не пересылал трафик, и начинает объявлять блоки данных протокола моста (Bridge Protocol Data Units -BPDU) для каждого порта. Этот BPDU содержит:
Идентификатор объявленного устройства, который является приоритетным в сочетании с локальным интерфейсом Media Access Control (MAC) адресом.
Идентификатор корневого моста-кандидата. Это мост с самым низким идентификатором, о котором знает локальное устройство. Если каждое устройство в сети запускается в один и тот же момент, то каждое устройство будет объявлять себя как корневой мост-кандидат, пока не узнает о других мостах с более низким идентификатором моста.
При получении BPDU на интерфейсе идентификатор корневого моста, содержащийся в BPDU, сравнивается с локально сохраненным наименьшим идентификатором корневого моста. Если идентификатор корневого моста, содержащийся в BPDU, меньше, то локально сохраненный идентификатор корневого моста заменяется вновь обнаруженным мостом с более низким идентификатором.
После нескольких раундов объявлений каждый мост должен был обнаружить мост с наименьшим идентификатором моста в сети и объявить этот мост корневым.
Это должно происходить, пока все порты на всех устройствах все еще заблокированы (не пересылают трафик).
Чтобы убедиться, что это действительно произойдет, пока все порты все еще заблокированы, таймер устанавливается на достаточно длительное время, позволяющий выбрать корневой мост.
После выбора корневого моста определяется кратчайший путь к корневому мосту.
Каждый BPDU также содержит метрику для достижения корневого моста. Этой метрикой может быть количество переходов, но стоимость каждого перехода также может варьироваться в зависимости от административных переменных, таких как пропускная способность канала.
Каждое устройство определяет порт, через который оно имеет самый дешевый путь к корневому мосту. Он отмечен как корневой порт.
Если существует более одного пути к корневому мосту с одинаковой стоимостью, используется прерыватель связи. Обычно это идентификатор порта.
Для любого звена, по которому соединены два моста:
Мост с наименьшей стоимостью пути к корневому мосту выбирается для пересылки трафика от канала к корневому мосту.
Порт, соединяющий выбранный сервер пересылки с каналом, помечается как назначенный порт.
Порты, отмеченные как корневые или как назначенные порты, могут пересылать трафик.
Результатом этого процесса является единое дерево, по которому доступны все пункты назначения в сети. На рисунке 1 показано, как STP работает в реальной топологии.
Предположим, что все устройства на рисунке 1 были включены в один и тот же момент. Существует ряд возможных вариаций времени, но процесс построения набора безцикловых путей через сеть будет выглядеть, с точки зрения F, примерно так:
Выберите корневой мост:
F объявляет BPDU E и D с идентификатором и корневым мостом кандидата 32768.0200.0000.6666.
D (при условии, что D не получил никаких BPDU) объявляет BDPU с идентификатором и корневым мостом кандидата 28672.0200.0000.4444.
E (при условии, что E не получил никаких BPDU) объявляет BPDU с идентификатором и корневым мостом-кандидатом 32768.0200.0000.5555.
На этом этапе F выберет D в качестве корневого моста и начнет объявлять BPDU со своим локальным идентификатором и корневым мостом-кандидатом, установленным на идентификатор D.
В какой-то момент D и E получат BPDU от C, имеющего идентификатор нижнего моста (24576.0200.0000.3333). Получив этот BPDU, они оба установят свой ID корневого моста кандидата на ID C и отправят новые BPDU в F.
Получив эти новые BPDU, F отметит, что новый идентификатор корневого моста кандидата ниже, чем его предыдущий идентификатор корневого моста кандидата, и затем выберет C в качестве корневого моста.
После нескольких циклов BDPU все мосты в сети выберут C в качестве корневого моста.
Отметьте корневые порты, найдя кратчайший путь к корню:
Предположим, что каждая линия связи стоит 1.
D получит BDPU от C с локальным идентификатором и идентификатором корневого моста 24576.0200.0000.3333 и стоимостью 0.
D добавит стоимость достижения C, одного перехода, объявляя, что он может достичь корневого моста со стоимостью от 1 до F.
E получит BDPU от C с локальным идентификатором и идентификатором корневого моста 24576.0200.0000.3333 и стоимостью 0.
E добавит стоимость достижения C, одного перехода, объявляя, что он может достичь корневого моста со стоимостью от 1 до F.
F теперь имеет два объявления о корневом мосте с равной стоимостью. Он должен разорвать связь между этими двумя доступными путями. Для этого F проверяет идентификаторы объявленных мостов. Идентификатор моста D меньше, чем E, поэтому F будет отмечать свой порт, направленный к D, как корневой порт.
Маркировка назначенных портов на каждом канале:
Единственный другой порт F направлен в сторону E. Должен ли быть заблокирован этот порт?
Чтобы определить это, F сравнивает свой локальный идентификатор моста с идентификатором моста E. Приоритеты одинаковы, поэтому для принятия решения необходимо сравнить адреса локальных портов. Локальный идентификатор F заканчивается на 6666, а у E - на 5555, поэтому E меньше.
F не отмечает интерфейс к E как назначенный порт; вместо этого он отмечает этот порт как заблокированный.
E выполняет то же сравнение и отмечает свой порт в направлении F как назначенный порт.
D сравнивает свою стоимость по отношению к корню со стоимостью F по отношению к корню.
Стоимость D ниже, поэтому он пометит свой порт в направлении D как назначенный порт.
На рисунке 2 показаны заблокированные, назначенные и корневые порты после завершения этих вычислений.
Порты на рисунке 2 помечены как bp для заблокированного порта, rp для корневого порта и dp для назначенного порта. Результатом процесса является дерево, которое может достигать любого сегмента сети, и, следовательно, хостов, подключенных к любому сегменту в сети. Один интересный момент, связанный с STP, заключается в том, что в результате получается единое дерево по всей топологии, закрепленное на корневом мосту. Если какой-либо хост, подключенный к E, отправляет пакет на хост, подключенный к B или F, пакет должен проходить через C, корневой мост, потому что один из двух портов на каналах [F, E] и [E, B] является заблокирован. Это не самое эффективное использование полосы пропускания, но оно предотвращает зацикливание пакетов во время нормальной пересылки.
Как обрабатывается обнаружение соседей в STP? Обнаружение соседей вообще не рассматривается с точки зрения надежной передачи информации по сети. Каждое устройство в сети строит свои собственные BPDU. Эти BPDU не проходят через какое-либо устройство, поэтому нет необходимости в сквозной надежной транспортировке в плоскости управления. Однако обнаружение соседей используется для выбора корневого моста и построения дерева без циклов по всей топологии с использованием BPDU. А как насчет отброшенных и потерянных пакетов? Любое устройство, на котором запущен протокол STP, периодически повторно передает свои BPDU по каждому каналу (в соответствии с таймером повторной передачи). Устройству, на котором запущен протокол STP, требуется несколько отброшенных пакетов (согласно таймеру отключения), чтобы предположить, что его соседи вышли из строя, и, следовательно, перезапустить вычисление состояний корневого моста и порта. В STP нет двусторонней проверки подключения ни для каждого соседа, ни на всем пути. Также не существует какой-либо проверки maximum Transmission Unit (MTU). STP изучает топологию, комбинируя BPDU с информацией о локальных каналах для каждого узла. Однако в сети нет ни одного узла с таблицей, описывающей всю топологию.
Изучение доступных пунктов назначения
Как STP разрешает пересылку? В частности, как устройства, на которых запущен протокол STP, узнают о доступных местах назначения? Рассмотрим рисунок 3.
На рис. 3 показано состояние сети с вычисленным связующим деревом и каждым портом, отмеченным как назначенный или корневой порт. В этой топологии нет заблокированных портов, потому что нет петель. Предположим, B, C и D не имеют информации о подключенных устройствах; A отправляет пакет в сторону E. Что происходит в этот момент?
A передает пакет по каналу [A, B]. Поскольку B имеет назначенный порт на этом канале, он примет пакет (коммутаторы принимают все пакеты на назначенных портах) и проверит адреса источника и назначения.
B может определить, что A доступен через этот назначенный порт, потому что он получил пакет от A на этом порту. Исходя из этого, B вставит MAC-адрес A как достижимый в свою таблицу пересылки через свой интерфейс на канале [A, B].
B не имеет информации о E, поэтому он будет рассылать этот пакет через каждый из своих незаблокированных портов. В этом случае единственный другой порт B - это его корневой порт, поэтому B пересылает этот пакет в C. Это лавинная рассылка называется Broadcast, Unknown, и Multicast (BUM) трафиком. BUM-трафик - это то, чем должна каким-то образом управлять каждая плоскость управления, которая изучает пункты назначения в процессе пересылки.
Когда C получает этот пакет, он проверяет адрес источника и обнаруживает, что A доступен через назначенный порт, подключенный к [B, C]. Он вставит эту информацию в свою локальную таблицу пересылки.
У C также нет информации о том, где E находится в сети, поэтому он просто лавинно рассылает пакет по всем незаблокированным портам. В этом случае единственный другой порт C - это канал [C, D].
D повторяет тот же процесс, которому следовали B и C, узнавая, что A доступен через его корневой порт по каналу [C, D], и лавинно направляет пакет по каналу [D, E].
Когда E получает пакет, он обрабатывает информацию и отправляет ответ обратно A.
Когда D получает этот ответный пакет от E, он проверяет адрес источника и обнаруживает, что E доступен через назначенный ему порт по каналу [D, E]. D действительно знает обратный путь к A, поскольку он обнаружил эту информацию при обработке первого пакета в потоке, идущем от A к E. Он будет искать A в своей таблице пересылки и передавать пакет по каналу [C, D].
C и B будут повторять процесс, который D и C использовали для определения местоположения E и перенаправления обратного трафика обратно в A.
Таким образом, узнавая адрес источника по входящим пакетам, а также путем лавинной рассылки или пересылки пакетов по исходящим каналам, каждое устройство в сети может узнать о каждом достижимом месте назначения. Поскольку протокол STP основан на изучении доступных адресатов в ответ на пакеты, передаваемые по сети, его классифицируют как реактивную плоскость управления. Обратите внимание, что этот процесс обучения происходит на уровне хоста; подсети и IP-адреса не изучаются, а скорее изучается физический адрес интерфейса хоста. Если один хост имеет два физических интерфейса на одном и том же канале, он будет отображаться как два разных хоста для плоскости управления STP.
Как удаляется информация из таблиц пересылки на каждом устройстве? Через процесс тайм-аута. Если запись пересылки не была использована в определенное время (таймер удержания), она удаляется из таблицы. Следовательно, STP полагается на кэшированную информацию пересылки.
Подведение итогов о протоколе связующего дерева
STP явно не является ни протоколом состояния канала, ни протоколом вектора пути. Это протокол вектора расстояния? Любая путаница в том, как классифицировать протокол, проистекает из первоначального выбора корневого моста перед вычислением кратчайших путей. Удалив этот первый шаг, проще классифицировать STP как протокол вектора расстояния, используя распределенную форму алгоритма Беллмана-Форда для расчета путей без петель по топологии. Что нужно сделать с первоначальным расчетом корневого моста? Эта часть процесса гарантирует, что во всей сети будет только одно дерево кратчайшего пути. Таким образом, STP можно классифицировать как протокол вектора расстояния, который использует алгоритм Беллмана-Форда для вычисления единого набора кратчайших путей для всех пунктов назначения во всей сети. Другими словами, STP вычисляет дерево кратчайшего пути по топологии, а не по адресатам.
Почему так важно, чтобы одно дерево вычислялось по всей сети? Это связано со способом, которым STP изучает информацию о доступности: STP - это реактивная плоскость управления, изучающая достижимость в ответ на фактические пакеты, проходящие через сеть. Если бы каждое устройство построило отдельное дерево с корнями в самом себе, этот реактивный процесс привел бы к несогласованному представлению топологии сети и, следовательно, к петлям пересылки.
STP и широковещательные штормы
Широковещательные рассылки - важная часть обнаружения служб в большинстве приложений. Например, как показано на рисунке 4, как A может обнаружить присутствие определенной службы на F?
Самое простое, что может сделать A в этой ситуации, - это отправить какой-то пакет, который будет доставлен на каждый хост, подключенный к сети, и дождаться ответа от хоста, на котором запущена данная служба. Таким образом, A отправляет широковещательную рассылку с вопросом о конкретной услуге или устройстве. Как B, C, D и E должны относиться к этой трансляции? Поскольку широковещательная рассылка не является «обучаемым» адресом (широковещательную рассылку должно принимать каждое устройство в каждом сегменте), лучше всего для коммутаторов пересылать пакет на каждый неблокированный порт.
Что произойдет, если А выполнит много рассылок? Что произойдет, если хост отправит достаточно широковещательных рассылок, чтобы отбросить BPDU? В этом случае сам STP запутается и, скорее всего, создаст цикл пересылки в топологии. Такой цикл пересылки будет, конечно, пересылать широковещательные пакеты постоянно, так как нет TTL для отбрасывания пакетов после того, как они пересекли сеть определенное количество раз. Каждая рассылка, передаваемая A, в этой ситуации останется в сети навсегда, петляя, возможно, между коммутаторами B, C, D и E. И каждая рассылка, добавленная к нагрузке сети, конечно же, предотвратит успешную передачу или прием BPDU, предотвращая схождение STP.
Следовательно, трафик в сети препятствует сходимости STP, а отсутствие сходимости увеличивает нагрузку трафика на саму сеть – возникает положительный цикл обратной связи, который вызывает хаос во всей сети. Эти события называются широковещательными штормами и достаточно распространены в сетях на основе STP, чтобы заставить мудрых проектировщиков и операторов сети ограничивать область действия любого домена STP. Существование широковещательных штормов также привело к ряду модификаций работы STP, таких как простая замена базового протокола плоскостью управления истинным состоянием канала.
Многомерные системы управления данными (МСУБД) объединяют несколько систем баз данных в одну. Вместо работы с несколькими моделями и поиска возможностей для их объединения, МСУБД предлагает общий механизм для различных типов данных.
В данной статье приводится подробный обзор многомерных баз данных.
Что такое многомерные базы данных?
Многомерная база данных (Multi-Model Database) – это система управления, которая сочетает несколько типов БД в одну серверную систему. Большинство СУБД поддерживает одну модель БД, а в МСУБД можно хранить, запрашивать и индексировать данные из нескольких моделей.
Важное преимущество многомерных БД заключается в многоязычной сохранности, когда не нужно искать способы для объединения различных моделей. Гибкий подход позволяет хранить данные разными способами. В результате вы получаете:
Гибкое и динамичное программирование
Снижение избыточности данных
Например, изучать взаимосвязи между точками данных или создавать систему рекомендаций гораздо проще с помощью графовых БД, а реляционные БД лучше подходят для определения связи между столбцами данных.
Ключевая функция МСУБД заключается в ее способности преобразовывать данные из одного формата в другой. К примеру, данные в формате JSON быстро преобразуются в XML. Преобразование форматов данных обеспечивает дополнительную гибкость и упрощает соответствие определенным требованиям проекта.
Примеры использования МСУБД
Варианты использования СУБД позволяют лучше понять принципы работы данной модели. Анализируя практические примеры, вам становится ясно, как несколько моделей работают в единой системе.
Хранение и управление несколькими источниками данных
Классическая IT-система использует различные источники данных. Информация не всегда хранится в том же формате или в той же базе данных. Несколько форматов складываются в сложную систему – трудную для поддержания и поиска данных.
Хранение данных в МСУБД облегчает администрирование систем. Все находится в одной базе, поэтому на хранение и управление данными из разных источников тратится меньше времени.
Расширение возможностей модели
Многомерные базы данных предлагают расширения для моделей. Особенности одних моделей перекрывают недочеты других.
Например, очень просто запрашивать данные в JSON-формате через SQL-запросы. Нет необходимости корректировать исходный источник данных. Расширяемость сокращает время обработки данных и устраняет необходимость в ETL-системах (извлечение, преобразование, загрузка).
Гибридные среды данных
Классическая среда данных разграничивает операционные данные от аналитических. Данные для анализа необходимо преобразовать и хранить отдельно от операционных.
Происходит задвоение, и качество данных снижается. Разделенное пространство повышает затраты на техническое обслуживание. Всем базам данных необходимо администрирование и управление резервным копированием.
Многомерная БД использует гибридный подход к хранению данных. Унифицированные узлы, в которых хранятся транзакционные данные и из которых извлекаются аналитические, намного проще поддерживать.
Централизация данных
У данных в организации есть определенные ограничения. Такие ограничения нужны, но они усложняют работу с информацией внутри компании.
Многомерные БД хранят данные в формате as-is («как есть»), поэтому никакие преобразования не нужны. Централизация данных дает ценную информацию о существующих данных и предлагает возможности для создания новых вариантов использования.
Поиск больших данных
Hadoop отлично справляется с обработкой больших объемов данных в разных моделях. Основная причина – скорость получения, обработки и хранения данных. Единственное, чего не хватает Hadoop, – это эффективного механизма поиска.
Если взять вычислительные мощности Hadoop и объединить их с возможностями поиска по многомерной БД, то получится функциональная система. Процесс работы становится масштабируемым и удобным для выполнения задач над большими данными.
Плюсы и минусы многомерной базы данных
В многомерных базах данных есть свои плюсы и минусы. В таблице ниже перечислены ключевые пункты:
Плюсы
Минусы
Постоянство данных
Сложность
Динамичность
Все еще в стадии разработки
ACID-совместимость
Не хватает методов моделирования
Подходят для сложных проектов
Не подходят для простых проектов
Такая модель подходит для корпоративных настроек с множеством данных. Разные секторы пользуются данными для разных задач. Но детализированной и уже настроенной структуре многоязычной сохранности может не хватать возможностей многомерной системы.
Плюсы
Преимущества многомерных баз данных:
согласованность данных между моделями за счет единой серверной системы
динамичная среда с использованием различных типов данных на одной платформе
отказоустойчивость, из-за ACID-совместимости
подходят для сложных проектов с множественным представлением данных
Минусы
Недочеты многомерных баз данных:
сложность МСУБД, из-за чего с ними трудно работать
модель БД все еще развивается и не имеет окончательной формы
ограниченная доступность различных методов моделирования
не подходит для более простых проектов или систем
Какие многомерные базы данных считаются самыми лучшими?
На рынке представлено огромное множество многомерных типов БД. Их самой примечательной особенностью является поддержка нескольких моделей на одном сервере.
Некоторые БД накладывают несколько моделей на сервер через компоненты. Но такие типы БД не считаются подлинными многомерными базами.
Еще одно важное отличие – доступные методы моделирования. Этот аспект крайне важен для того, чтобы получать максимальную пользу от доступных данных.
MarkLogic Server
MarkLogic Server – это многомерная нереляционная база данных. Она появилась как хранилище XLM, а затем была доработана для хранения различных моделей:
документной
графовой
текстовой
пространственной
типа «ключ – значение»
реляционной
Это универсальная, эффективная и безопасная база данных. Возможности сервера MarkLogic:
Безопасность и управление. Интегрированное управление безопасностью данных и пользователей.
ACID-совместимость. Обеспечивает строгую согласованность данных.
Расширенный поиск. Доступ к данным обеспечивает встроенная поисковая система с семантическим поиском.
Разноплановая аналитика. Вам доступны настраиваемые инструменты для аналитики и бизнес-аналитики.
Встроенное машинное обучение. Интеллектуальное автоматизированное курирование данных с помощью встроенных алгоритмов машинного обучения обеспечивает более быстрый доступ к данным.
Отказоустойчивость. Mark Logic предлагает высокую доступность и систему аварийного восстановления, помогающую избегать любого рода сбоев.
Поддержка гибридного облака. База данных позволяет самостоятельно управлять развертыванием с помощью гибридных облачных решений.
ArangoDB
ArangoDB – это нативная многомерная система управления базами данных. Она поддерживает следующие форматы данных:
документные
графовые
«ключ-значение»
База данных извлекает и изменяет данные с помощью унифицированного языка запросов AQL. К другим важным особенностям относятся:
Расширенные соединения. Позволяет соединять данные с помощью гибких запросов, что снижает их избыточность.
Транзакции. Выполнение запросов к нескольким документам с доступной изоляцией и согласованностью транзакций.
Сегментирование. Синхронная репликация путем сегментирования позволяет снижать внутреннюю кластерную связь, повышая при этом производительность и скорость соединения.
Репликация. Репликация обеспечивает распределенную БД в пределах одного центра обработки данных.
Многопоточность. Благодаря многопоточности, БД может использовать несколько ядер.
OrientDB
OrientDB – это многомерная нереляционная база данных с открытым кодом, написанная на Java. Эта БД поддерживает следующие модели:
документную
графовую
тип «ключ-значение»
объектную
пространственную
OrientDB первая ввела несколько моделей на уровне ядра. Эта база данных поставляется с рядом уникальных функций, к которым относятся:
Поддержка SQL. БД поддерживает SQL-запросы, благодаря чему программистам легче переключиться с реляционных моделей на OrientDB.
ACID-совместимость. База данных полностью транзакционна; таким способом достигается ее надежность.
Распределенная. Полная поддержка репликации с множеством master на разных выделенных серверах.
Портативная. Позволяет быстро импортировать реляционные базы данных.
Заключение
Существует великое множество методов моделирования баз данных, и в каждом решении можно найти свои плюсы и минусы. Многомерные БД стремятся объединить различные базы данных в единую серверную систему, благодаря чему при разрастании системы ее сложность и потребление ресурсов не увеличиваются.
Одной из основных составляющих IP – PBX на базе Asterisk являются SIP – транки в сторону провайдера и оконечные телефонные аппараты, или как их принято называть «пиры» (peers). Сегодня мы расскажем о способе автоматизации мониторинга состояния транков и пиров, с отправлением на почту системного администратора.
Мониторинг пиров
Итак, начнем с мониторинга состояния пиров. Для этого мы напишем небольшой bash – скрипт. Предположим, что у нас есть 3 площадки, А, B и C. АТС Asterisk находится на площадке A. Предварительно, перед началом работы, создадим 2 файлы: первый – для логов нашего скрипта, а второй, будет служебным, и будет использоваться только в рамках исполнения скрипта. Внутри каждого скрипта, мы будем писать комментарии к каждой из его строк.
Скачать скрипт мониторинга пиров вы можете по ссылке ниже:
Скачать скрипт мониторинга пиров
[root@asteriskpbx]# touch /home/admin/log_mail.txt
[root@asteriskpbx]# touch /home/admin/message.txt
Далее, создаем переменные для нашего скрипта:
#!/bin/sh
LOGSIZE=`ls -l /home/admin/log_mail.txt | awk '{ print $5 }'` //проверяем размер файла с логами
problempeers=`/usr/sbin/asterisk -rx 'sip show peers' | grep UNKNOWN` //выводим командой 'sip show peers' через консоль Asterisk, и затем, с помощью команды grep UNKNOWN фильтруем пиры, чтобы отобразить только те, состояние которых является UNKNOWN
GWB=`ping -c4 11.22.33.44 | grep 'received' | awk -F',' '{ print $2}' | awk '{ print $1}'` //по протоколу ICMP, пингуем IP – адрес шлюза на удаленной площадке четырьмя пакетами. Если все ОК, и шлюз доступен, до значение переменной будет равно 4. В противном случае, оно будет равно 0.
GWC=`ping -c4 44.33.22.11 | grep 'received' | awk -F',' '{ print $2}' | awk '{ print $1}'` //аналогичным образом пингуем шлюз на площадке C
ResultB="" //служебная переменная
ResultC="" //служебная переменная
FILENAME=/home/admin/message.txt //записываем в переменную путь к лог- файлам
LOGFILE=/home/admin/log_mail.txt
DATE="`date +%d.%m.%Y" "%H:%M:%S`" //выводим текущую дату и время в формате дд.мм.гггг чч:мм:сс
echo "$problempeers" > /home/admin/message.txt //записываем содержимое переменной problempeers в служебный файл. В этой переменной содержится результат вывода команды по статусу пиров.
FILESIZE=$(stat -c%s "$FILENAME") //проверяем размер служебного файла message.txt. Если в нем есть какая-либо информация, значит есть проблемы с пирами (имеются в статусе UNKNOWN), если он пустой, то все ОК.
На этом этапе, мы сформировали все необходимые переменные и у нас имеются все необходимые для формирования письма (если надо) на email системному администратору. Перейдем к исполнительной части скрипта:
if [ $GWB -eq 0 ]; then //если число ответов шлюза на площадке B на пинг равно 0, то запускаем процесс формирования письма
ResultB ="на площадке B НЕ ДОСТУПЕН!" //формируем часть текста. Мы ее включим в заголовок письма
else
ResultB ="" //если все таки шлюз ответил на пинг, то оставляем переменную пустой
fi
if [ $GWС -eq 0 ]; then //если число ответов шлюза на площадке С на пинг равно 0, то запускаем процесс формирования письма
ResultС="на площадке С НЕ ДОСТУПЕН!" //по аналогии. Указываем в заголовок, что роутер C недоступен
else
ResultС ="" //если все ОК, то оставляем переменную пустой
fi
if [ $FILESIZE -ne 1 ]; then //если наш служебный файл message.txt не пустой, то проверяем следующее условие
if [ $GWB -eq 0 ] || [ $GWC -eq 0 ]; then //если хотябы один из роутеров недоступен по пинг, то переходим к следующему пункту скрипта
echo "$problempeers"| mailx -s "Проблемы с SIP пирами | Роутер $ResultB $ResultC!" -r "info@merionet.ru" youremail@some.ru </home/admin/message.txt && //отправляем на почту письмо, где указываем, что у нас есть проблемы с пирами, и, если какой-то из роутеров не доступен, указываем это. В теле письма мы отправляем вывод недоступных пиров.
echo "FAIL :: $DATE :: Some problems with phones" >> "$LOGFILE" //параллельно с отправкой письма, записываем в лог файл запись, что у нас есть проблемы с пирами (в вывод так же можно добавить с какими именно)
else
echo "$problempeers"| mailx -s "Проблемы с SIP пирами | Роутеры ДОСТУПНЫ!" -r "info@merionet.ru" youremail@some.ru < /home/admin/message.txt && //если оба наших роутера доступны, то мы просто формируем письмо, в котором указываем перечень недоступных пиров.
echo "FAIL :: $DATE :: Some problems with phones" >> "$LOGFILE" //аналогично вносим запись в лог – файл.
fi
else
echo "OK :: $DATE :: all phones are OK" >> "$LOGFILE" //если служебный файл пустой, то мы вносим запись в лог – файл что все хорошо и проверка успешно прошла.
fi
if [ $LOGSIZE -ge 150000 ]; then //елси размер нашего лог – файла больше или равен 150 КБ, то мы очищаем этого (можете подкрутить эту величину, как вам угодно.)
cat /dev/null > /home/admin/log_mail.txt
fi
cat /dev/null > /home/admin/message.txt //на выходе чисти служебный файл message.txt, для последующего использования
Теперь давайте проверим, что приходит нам на почту в случае, если несколько пиров стали недоступны, но все роутеры доступны:
Мониторинг транков
Отлично, перейдем к формированию скрипта по мониторингу транков. Здесь все несколько проще, и мы просто будем сравнивать общее количество транков, и количество зарегистрированных транков:
Скачать сам скрипт можете ниже:
Скачать скрипт мониторинга транков
#!/bin/bash
ALLTRUNKSMINIMUM="`/usr/sbin/asterisk -rx "sip show registry"`" //выводим регистрации по протоколу SIP
ALLTRUNKS=`echo "$ALLTRUNKSMINIMUM" |grep "SIP registrations" |awk '{print $1}'` //численное обозначение всех имеющихся транков
REGTRUNKS=`/usr/sbin/asterisk -rx "sip show registry" |grep Registered |wc -l` //численное обозначение всех зарегистрированных транков
DATE="`date +%d.%m.%Y" "%H:%M:%S`" //формируем текущую дату, для логов
LOGFILE=/home/admin/log_mail.txt //для лог – файла, указываем тот же файл, что и для скрипта по мониторингу пиров
if [ "$REGTRUNKS" -lt "$ALLTRUNKS" ]; then //если число зарегистрированных транков меньше чем число всех транков
sleep 5 //ждем 5 секунд
echo `/usr/sbin/asterisk -rx "sip reload"` \ перезагружаем модуль SIP, в целях перерегистрации. Эта команда автоматически перерегистрирует транк на оборудовании провайдера, после чего, он, зачастую, начинает работать.
sleep 5 //ждем еще 5 секунд
VAR=`/usr/sbin/asterisk -rx "sip show registry"` //после перезагрузки SIP модуля, снова смотрим SIP –регистрации. Если данная команда не дала своих результатов, то в переменной VAR будет записаны не работающие транки. Если она помогла, то на email админу придет рабочий вывод всех зарегистрированных транков. Это весьма удобно.
echo "$VAR"| mailx -s "Мониторинг транков" -r "info@merionet.ru" youremail@some.ru // отправляем письмо на почту системного администратора, с выводом SIP регистраций после перезагрузки модуля
else
echo "OK :: $DATE :: all trunks are OK" >> "$LOGFILE" //если число зарегистрированных транков, равно общему числу, то записываем в лога файл соответствующую запись.
fi
Теперь, когда мы автоматизировали процессы мониторинга состояния на Asterisk, сделаем выполнение этих скриптов регулярным. Сохраним наши скрипты в формате .sh, можно сделать это, например, в Notepad ++. Сделаем выполнение мониторинг транков раз в 2 минуты, а выполнение мониторинга пиров раз в 10 минут. Перед загрузкой скриптов на сервер, дадим им необходимые права и, что очень важно, преобразуем скрипт в Linux формат:
[root@asteriskpbx]# dos2unix peer.sh //преобразуем скрипт для мониторинга пиров
[root@asteriskpbx]# dos2unix trunk.sh //преобразуем скрипт для мониторинга транков
[root@asteriskpbx]# chmod 777 peer.sh //дадим необходимые права обоим скриптам
[root@asteriskpbx]# chmod 777 trunk.sh
[root@asteriskpbx]# crontab -e
В открывшемся cron, задаем задачи для выполнения наших скриптов:
*/10 * * * * /bin/bash /home/peer.sh >/dev/null //исполнять файл раз в 10 минут
*/2 * * * * /bin/bash /home/trunk.sh >/dev/null //исполнять файл раз в 2 минуты
Вот и все. Теперь мы имеет достаточно простой, но порой очень нужный и эффективный мониторинг состояния транков и пиров на нашем Asterisk