По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Виртуализация часто применяется для поиска более простого способа решения некоторых проблем, отмеченных в начальных статьях этой темы, таких как разделение трафика. Как и все в мире сетевой инженерии, здесь есть компромиссы. На самом деле, если вы не нашли компромисс, вы плохо искали. В этом разделе будут рассмотрены некоторые (хотя, конечно, не все) различные компромиссы сложности в области виртуализации сети. Основой этого обсуждения будет триада компромиссов сложности:
Состояние: количество состояний и скорость, с которой изменяется состояние в сети (особенно в плоскости управления).
Оптимизация: оптимальное использование сетевых ресурсов, включая такие вещи, как трафик, следующий по кратчайшему пути через сеть.
Поверхность: количество слоев, глубина их взаимодействия и широта взаимодействия.
Поверхности взаимодействия и группы связей общих рисков
Каждая система виртуализации, когда-либо задуманная, реализованная и развернутая, создает в некотором роде общий риск. Например, рассмотрим одну линию, по которой передается несколько виртуальных каналов, каждый из которых передает трафик. Должно быть очевидным (на самом деле тривиальным) наблюдение, что в случае отказа одного физического канала произойдет сбой всех виртуальных каналов. Конечно, вы можете просто перенаправить виртуальные каналы на другой физический канал. Правильно? Может быть, а может и нет. Рисунок 1 иллюстрирует это.
С точки зрения A и D, есть две линии, доступные через B и C, каждая из которых обеспечивает независимое соединение между хостом и сервером. В действительности, однако, и провайдер 1, и провайдер 2 приобрели виртуальные каналы через единственное соединение у провайдера 3. Когда единственное соединение в сети провайдера 3 выходит из строя, трафик может быть перенаправлен с основного пути через провайдера 1 на путь через провайдера. 2, но поскольку оба канала используют одну и ту же физическую инфраструктуру, ни одна из них не сможет передавать трафик.
Говорят, что эти два звена в этой ситуации разделяют одну общую судьбу, потому что они являются частью Shared Risk Link Group (SRLG). Можно найти и обойти SRLG или ситуации с shared fate, но это усложняет плоскость управления и/или управление сетью. Например, невозможно обнаружить эти shared fate без ручного тестирования различных ситуаций отказа на физическом уровне или изучения сетевых карт, чтобы найти места, где несколько виртуальных каналов проходят по одному и тому же физическому каналу. В ситуации, описанной на рисунке 1, найти ситуацию с shared fate было бы почти невозможно, поскольку ни один из провайдеров, скорее всего, не скажет вам, что использует линию от второго провайдера, показанного на рисунке как провайдер 3, для предоставления услуг.
Как только эти ситуации с shared fate обнаружены, необходимо предпринять некоторые действия, чтобы избежать серьезного сбоя в работе сети. Обычно для этого требуется либо вводить информацию в процесс проектирования, либо усложнять дизайн, либо вводить информацию в плоскость управления (см. RFC8001 в качестве примера типа сигнализации, необходимой для управления группами SRLG в плоскости управления, спроектированной трафиком). По сути, проблема сводится к следующему набору утверждений:
Виртуализация - это форма абстракции.
Абстракция удаляет информацию о состоянии сети с целью снижения сложности или предоставления услуг за счет реализации политики.
Любое нетривиальное сокращение информации о состоянии сети так или иначе снизит оптимальное использование ресурсов.
Единственным противодействием конечному состоянию из этих трех, является протекание информации через абстракцию, поэтому можно восстановить оптимальное использование ресурсов - в этом случае отказ одного канала не вызывает полного отказа потока трафика через сеть. Единственное решение, таким образом, - сделать абстракцию сквозной абстракцией, что снизит эффективность абстракции при контроле области действия состояния и реализации политики.
Поверхности взаимодействия и наложенные плоскости управления
В сетевой инженерии принято накладывать друг на друга два протокола маршрутизации или две плоскости управления. Хотя это не часто рассматривается как форма виртуализации, на самом деле это просто разделение состояния между двумя различными плоскостями управления для контроля количества состояний и скорости изменения состояний, чтобы уменьшить сложность обеих плоскостей управления. Это также часто встречается при запуске виртуальных наложений в сети, поскольку между головным и хвостовым узлами туннеля будет существовать нижележащая плоскость управления, обеспечивающая достижимость, и плоскость управления наложением, обеспечивающая достижимость в виртуальной топологии. Две наложенные друг на друга плоскости управления будут взаимодействовать иногда неожиданным образом. Для иллюстрации используется рисунок 2.
На рисунке 2:
Каждый маршрутизатор в сети, включая B, C, D и E, использует две плоскости управления (или, если это проще, протоколы маршрутизации, отсюда протокол 1 и протокол 2 на рисунке).
Протокол 1 (оверлей) зависит от протокола 2 (базовый) для обеспечения доступности между маршрутизаторами, на которых работает протокол 1.
Протокол 2 не содержит информации о подключенных устройствах, таких как A и F; вся эта информация передается в протоколе 1.
Протокол 1 требует гораздо больше времени для схождения, чем протокол 2.
Более простой путь от B к E проходит через C, а не через D.
Учитывая этот набор протоколов, предположим, что C на рисунке 2 удален из сети, двум управляющим плоскостям разрешено сходиться, а затем C снова подключается к сети. Каков будет результат? Произойдет следующее:
После удаления C сеть снова объединится с двумя путями в локальной таблице маршрутизации в B:
F доступен через E.
E доступен через D.
После повторного подключения C к сети протокол 2 быстро сойдется.
После повторной конвергенции протокола 2 лучший путь к E с точки зрения B будет через C.
Следовательно, у B теперь будет два маршрута в локальной таблице маршрутизации:
F доступен через E.
E достижимо через C.
B перейдет на новую информацию о маршрутизации и, следовательно, будет отправлять трафик к F через C до того, как протокол 1 сойдется, и, следовательно, до того, как C узнает о наилучшем пути к F.
С момента, когда B начинает пересылку трафика, предназначенного для F в C, и момента, когда протокол 1 сойдется, трафик, предназначенный для F, будет отброшен.
Это довольно простой пример неожиданного взаимодействия наложенных протоколов. Чтобы решить эту проблему, вам необходимо ввести информацию о состоянии конвергенции протокола 1 в протокол 2, или вы должны каким-то образом заставить два протокола сходиться одновременно. В любом случае вы по существу добавляете состояние обратно в два протокола, чтобы учесть их разницу во времени конвергенции, а также создавая поверхность взаимодействия между протоколами.
Примечание: Этот пример описывает фактическое взаимодействие конвергенции между IS-IS и BGP, или протоколом Open Shortest Path First (OSPF) и BGP. Чтобы решить эту проблему, более быстрый протокол настроен на ожидание, пока BGP не сойдется, прежде чем устанавливать какие-либо маршруты в локальной таблице маршрутизации.
Сегодня хотим предложить крутой функционал, который тебе захочется установить на своей IP – АТС Asterisk прямо сейчас! Речь пойдет про отправку записи разговора на адрес электронной почты со всеми причитающимися метаданными звонка. Работает это примерно вот так: ваш сотрудник поговорил по телефону, положил трубку, после чего, ответственному по электронной почте приходит письмо с записью разговора, датой и временем звонка, а также номерами А и Б.
Настроить эту «фичу» очень легко. Приступаем к настройке.
Bash скрипт для Asterisk
Сам по себе скрипт написан на bash. Скрипт будет инициироваться сразу после окончания звонка и в него будут переданы нужные для работы переменные. Но об этом чуть позже:
#!/bin/bash
dt=$(date '+%m/%d/%Y %r');
echo -e "Привет! Появилась новая запись разговоров на нашем сервере Asterisk
Звонок был совершен $dt
Нам позвонил этот номер - $5
Вызов принял - $7
Запись разговора во вложении
" | mail -a /var/spool/asterisk/monitor/$1/$2/$3/$6 -s "Новая запись разговоров" info@merionet.ru
Пробежимся по переменным, которые будут относится к звонку и будут передаваться (все кроме $dt) с Asterisk:
$1 - год звонка;
$2 - месяц звонка;
$3 - день звонка;
$4 - дата и время в формате строки;
$5 - источник звонка (звонящий);
$6 - имя файла аудио – записи разговора;
$7 - куда был совершен вызов;
$dt - генерируем дату звонка;
Переходим в консоль сервера Asterisk. Первым делом создаем файл с расширением .sh в него мы поместим наш скрипт:
touch /var/lib/asterisk/bin/rectoemail.sh
Даем файлу нужные права и разрешения:
chown asterisk:asterisk rectoemail.sh
chmod 774 rectoemail.sh
Теперь открываем сам файл скрипта для редактирования:
vim /var/lib/asterisk/bin/rectoemail.sh
И добавляем скрипт в файл. Для того, чтобы сделать это, скопируйте скрипт из статьи. В режиме редактирования через vim нажмите «o» на клавиатуре, затем нажмите правую кнопку мыши – скрипт будет добавлен в файл. После этого, нажмите Esc на клавиатуре и комбинацию :x! + Enter для сохранения изменений. Готово.
Доработка в FreePBX
Теперь нужно поставить наш скрипт на автоматический запуск. Переходим в раздел Settings → Advanced Settings. Убеждаемся, что параметры Display Readonly Settings и Override Readonly Settings установлены в значение Yes.
Теперь находим параметр Post Call Recording Script и добавляем в его поле следующую строчку:
bash /var/lib/asterisk/bin/rectoemail.sh ^{YEAR} ^{MONTH} ^{DAY} ^{TIMESTR} ^{FROMEXTEN} ^{CALLFILENAME}.^{MIXMON_FORMAT} ^{ARG3}
Готово. Сохраняем настройки и переходим к тестам:
Активное сетевое оборудование, должно обеспечивать долгосрочное и бесперебойное функционирование корпоративной сети. Своевременное выявление и устранение неисправностей является залогом успешной и эффективной работы компании. Именно поэтому очень важно уделить особое внимание системе мониторинга, которая бы отслеживала состояние активного оборудования и уведомляла об отклонении от нормальных показателей системного администратора по SMS, e-mail или другим средствам оповещения.
Система мониторинга – это совокупность технических средств, осуществляющих постоянное наблюдение и сбор информации в локальной вычислительной сети на основе анализа статистических данных с целью выявления неисправных или некорректно работающих узлов и оповещения ответственных лиц. Функционал современных систем мониторинга позволяет отслеживать состояние таких сервисов как например:
1) Доступность хоста
Путем периодической отправки запросов ICMP Echo-Request на адрес сетевого устройства
2) Доступность веб-сервера
Путем отправки HTTP запроса на получение страницы
3) Доступность почтовых сервисов
Путем периодической отправки диагностических SMTP сообщений
Кроме того, можно производить замер времени отклика данных сервисов.
Периодические проверки такого рода позволяют быстро определить на каком уровне возникла проблема и незамедлительно приступить к её устранению.
Система мониторинга сети
На приведенном выше рисунке показан простейший пример реализации системы мониторинга, контролирующей всего четыре устройства. В реальных же условиях парк активного оборудования может иметь куда больше узлов. Для осуществления грамотного мониторинга проводят объединение разных типов узлов в группы, например группа веб-серверов или группа маршрутизаторов. Такого рода разделение помогает систематизировать статистическую информацию и облегчает процесс наблюдения.
Большинство систем мониторинга позволяют автоматизировать проверку устройств по SNMP и осуществлять диагностику с помощью различных плагинов (в том числе созданных вручную).
Протокол SNMP (Simple Network Management Protocol) - был создан специально для нужд мониторинга сетевого оборудования. Все активные устройства L2 и L3 содержат так называемую Базу информации управления MIB (Management Information Base), в которой находятся основные параметры состояния оборудования. Например, загрузка CPU, статус интерфейсов, объем свободного места и др. Каждой такой записи соответствует уникальный идентификатор OID(Oject IDentifier). Имея нужный идентификатор, можно получить информацию об интересующем параметре по протоколу SNMP. Современные системы мониторинга позволяют автоматизировать данный процесс. Система, по протоколу SNMP, подключается к устройству, опрашивает его по интересующему OID, получает значение параметра и сравнивает его с заданным. Если обнаруживается несоответствие двух данных значений, то системы мониторинга реагирует и запускает процесс оповещения.
Перед непосредственным внедрением системы мониторинга, необходимо провести обследование ЛВС, результатом которого должен стать перечень наблюдаемого оборудования, параметров и утвержденный алгоритм эскалации событий мониторинга. На основе анализа сетевой инфраструктуры заказчика формируются первые решения определяющие архитектуру будущей системы мониторинга.
На следующем этапе осуществляется составление спецификаций и пакета проектной документации, с учетом пожеланий заказчика.
Далее обычно следует внедрение разработанного решения на отдельном сегменте сети с ограниченным числом наблюдаемых узлов, с целью тестирования и отладки функционала предложенного решения.
Заключительным этапом является масштабирование системы мониторинга, то есть расширение объема наблюдаемой ИТ-инфраструктуры до необходимого заказчику.
Внедрение системы мониторинга – это важный шаг на пути к полной автоматизации ИТ-инфраструктуры, который ведет к повышению эффективности ее использования. Специалисты нашей компании не раз разрабатывали решения, которые оправдывают ожидания заказчиков и надёжно работают вот уже несколько лет.