По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Системные администраторы и девопсы теперь могут использовать сетевые ресурсы, хранилища, виртуальные машины, ERP, системные программные обеспечения и приложения большинства публичных или частных облачных платформ или гибридных сред. Переход организаций к облачной среде может быть мотивирован высокой доступностью, выгодной ценой и возможностью оптимизации в реальном времени, которая возможна только в облачной среде. Но, наряду с многочисленными преимуществами, возникает необходимость мониторинга инфраструктуры и приложений, работающих в облаке. Эта статья прольет свет на мониторинг облачных платформ и предоставит вам информацию об инструментах, которые облегчат вам, как Cloud разработчику, мониторинг инфраструктуры и приложений. Мониторинг инфраструктуры и приложений Мониторинг инфраструктуры и приложений - это просто стратегия управления. Стратегия управления включает любой рабочий процесс, который оценивает вычислительные ресурсы и приложения, чтобы получить представление о производительности, работоспособности и доступности служб, работающих в любой инфраструктуре. Таким образом, мониторинг облачных сред включает наблюдение за показателями производительности веб-серверов, приложений, серверов хранения, виртуальных облачных сетей, виртуальных машин и любых других служб, работающих в облачной среде. Рассмотрим некоторые преимущества мониторинга в облаке. Учет потребления облачных ресурсов Мониторинг как услуга в облаке помогает организациям увидеть текущие ресурсы и связанные с ними затраты с помощью тэгов. Затем администраторы могут использовать данные о ресурсах для определения приоритетов и масштабирования ресурсов на основе затрат и спроса. Оптимизация производительности На основе результатов системных оповещений, событий и триггеров, настроенных для отслеживания ресурсов инфраструктуры, девопсы могут выполнять настройку ресурсов, например, балансировку нагрузки, для оптимальной работы инфраструктуры. Гарантированная безопасность системы Мониторинг пользователей в реальном времени, мониторинг входящего и исходящего трафика и частые тесты, выполняемые на конечных точках API, служат моделями безопасности для облачной инфраструктуры/приложений. Видимость означает, что любая аномалия в системе может быть легко выявлена до эскалации. Популярные средства мониторинга для разработчиков облачных сред Ниже приведены некоторые из наиболее используемых инструментов мониторинга облачных вычислений, доступных для сисадминов и девопсов. 1. CloudWatch CloudWatch, созданный Amazon, представляет собой средство наблюдения и мониторинга, предоставляющее данные/информацию о производительности системы, работе приложений и состоянии облачной инфраструктуры. Amazon CloudWatch - это инструмент для групп DevOps, инженеров по надежности сайтов и разработчиков облачных решений. Разработчики могут начать работу с CloudWatch бесплатно с помощью бесплатного тарифа. Приложения и инфраструктурные ресурсы, работающие в Amazon Cloud, генерируют рабочие данные в виде журналов, метрик и событий. Поэтому разработчики могут использовать CloudWatch для сбора и мониторинга метрик и данных журналов для измерения производительности приложений и обнаружения любых изменений инфраструктуры. CloudWatch обеспечивает отличный контроль над облачной инфраструктурой за счет упреждающего поиска и устранения неисправностей, оптимизации ресурсов, анализа журналов и сокращения среднего времени разрешения проблем. (MTTR) CloudWatch позволяет отслеживать контейнеры, экземпляры ECS, Amazon EKS и все экземпляры приложений, работающие в облачных средах. 2. Dynatrace Dynatrace - интеллектуальная платформа, обеспечивающая выполнение требований консолидации мониторинга. Инструмент основан на искусственном интеллекте и обеспечивает автоматизированное и интеллектуальное наблюдение за всей облачной инфраструктурой и приложениями. Dynatrace - инструмент мониторинга на основе агентов. OneAgent, устанавливаемый и интеллектуальный агент, который автоматизирует общесистемный мониторинг. OneAgent собирает метрики на всех уровнях стека приложений. Для мониторинга инфраструктуры OneAgent может собирать метрики из безсеверных инфраструктур, контейнеров, модулей, виртуальных компьютеров и даже облачных баз данных и многого другого. Dynatrace использует PurePath для визуализации мобильных и веб приложений на уровне кода. В результате разработчики получают представление о доступности и производительности внешних и внутренних транзакций, выполняемых в любой облачной среде. Кроме того, инструмент не только обеспечивает трассировку, метрики и данные журнала только для локальных сред. Она позволяет интегрировать несколько облачных технологий и расширить сторонние инструменты для обеспечения бесконтактного мониторинга приложений, работающих в облачных средах. Кроме того, разработчики могут использовать API Dynatrace для внедрения собранных метрик в средства отчетности и анализа сторонних производителей для более интуитивных системных отчетов. Для начала работы с Dynatrace, можно подписаться на бесплатную пробную версию и развернуть инструмент в своей среде для мониторинга всего стека. 3. DataDog Подключение Datadog к классической или облачной инфраструктуре обеспечивает детальную видимость производительности инфраструктуры и приложений. Все это можно просмотреть исчерпывающим образом: от хостов в сети до экземпляров контейнеров и даже активных процессов, выполняемых на любой инфраструктуре. Этот инструмент мониторинга имеет встроенные функции, как агент Datadog, монитор производительности приложений Datadog, диспетчер журналов Datadog и профилировщик Continuous. Встроенные инструменты отвечают за сбор метрик системы и обнаружение любых изменений в системе. Затем разработчики могут просмотреть и анализировать собранные показатели производительности с помощью гибких панелей мониторинга. Созданные панели мониторинга представляют тенденции в метриках. Например, можно просмотреть частоту ошибок облачных приложений, задержки в сетевых конечных точках, а также обслуживаемые или неуспешные запросы HTTPS. Следовательно, администраторы и разработчики облачных служб могут создавать сводки показателей на панели мониторинга для любого периода. Datadog обеспечивает интеграцию на основе агентов, аутентификации и библиотек для обеспечения унифицированного системного мониторинга в случаях распространения систем и приложений. Самой крутой особенностью Datadog является удобство, которое он дает разработчикам для выполнения синтетического мониторинга производительности приложений с помощью синтетических тестов. Синтетические тесты - это моделируемые запросы, имитирующие работу клиента с веб-службой и API для обеспечения сквозной видимости приложений. 4. Prometheus Prometheus - отличный инструмент мониторинга и оповещения с открытым исходным кодом для облачных, гибридных и готовых систем. Этот инструмент агрегирует системные метрики как данные временных рядов, многомерную модель данных, которая идентифицируется парами «имя метрики» и «ключ-значение». Например, HTTP запрос как имя метрики (ключ) и соответствующее общее количество этих запросов как значение. Prometheus работает с автономным единственным сервером Prometheus, который удаляет метрики из нескольких источников данных и сохраняет их как данные временных рядов. Кроме того, средство имеет такие платформы визуализации, как Grafana, Consoles и Expression. Для системных оповещений Prometheus использует диспетчер оповещений для гибкой отправки уведомлений и управления ими с помощью сообщений электронной почты, систем по вызову и платформ чатов, таких как Slack, где разработчики могут своевременно реагировать на возникающие системные проблемы. 5. MetricFire MetricFire - это набор инструментов с открытым исходным кодом, которые помогают системным администраторам собирать, хранить и визуализировать метрики облачной инфраструктуры. Метрики играют важную роль в определении нагрузки, надежности системы и необходимости оптимизации ресурсов. Инструмент мониторинга содержит три инструмента с открытым исходным кодом - Graphite, Prometheus и Grafana - все они работают совместно, чтобы облегчить мониторинг. Graphite, например, обрабатывает сбор метрик с помощью агента Hosted Graphite, который включает службы сбора, такие как diamond. Diamond, демон python, собирает метрики ЦП, показатели использования дисков, сетевых операций ввода-вывода, метрики веб-приложений и многое другое. Затем разработчики могут просматривать метрики в расширенных по функциям панелях мониторинга Grafana или Graphite. С помощью панелей мониторинга разработчики могут наблюдать метрики из нескольких источников, таких как Graphite, Prometheus и другого программное обеспечение для мониторинга облачных инфраструктур. Панели мониторинга Grafana отличаются высокой настраиваемостью и могут быть преобразованы в соответствии с большинством требований к визуализации. Разработчики также могут создавать сложные графики и диаграммы с несколькими метриками и трассировками для предоставления окончательных отчетов о работе систем. Благодаря размещенным инструментам разработчики могут сразу понять системные данные без необходимости установки нескольких сторонних инструментов. Заключение Итак, мы рассмотрели, что такое мониторинг облачной инфраструктуры и приложений, изучили некоторые преимущества мониторинга. Приведенные в данной статье инструменты благодаря своей гибкости и функционалу, облегчат мониторинг всей инфраструктуры. Можно развернуть и попробовать бесплатные пробные версии и выбрать подходящий под конкретные нужды.
img
Первоначально BGP был разработан как протокол Внешнего шлюза (Exterior Gateway Protocol - EGP), что означает, что он предназначался для подключения сетей или автономных систем (AS), а не устройств. Если BGP является EGP, это должно означать, что другие протоколы маршрутизации, такие как RIP, EIGRP, OSPF и IS-IS, должны быть протоколами внутренних шлюзов (Interior Gateway Protocols- IGP). Четкое определение внутренних и внешних шлюзов оказалось полезным при проектировании и эксплуатации крупномасштабных сетей. BGP является уникальным среди широко распространенных протоколов в том, что касается расчета пути без петель. Существует три широко используемых протокола векторов расстояний (Spanning Tree, RIP и EIGRP). Существует два широко используемых протокола состояния канала связи (OSPF и IS-IS). И есть еще много примеров этих двух типов протоколов, разработанных и внедренных в то, что можно было бы считать нишевыми рынками. BGP, однако, является единственным широко развернутым протоколом вектора пути. Каковы наиболее важные цели EGP? Первый - это, очевидно, выбор путей без петель, но это явно не означает кратчайшего пути. Причина, по которой кратчайший путь не так важен в EGP, как в IGP, заключается в том, что EGP используются для соединения объектов, таких как поставщики услуг, поставщики контента и корпоративные сети. Подключение сетей на этом уровне означает сосредоточение внимания на политике, а не на эффективности - с точки зрения сложности, повышение состояния с помощью механизмов политики при одновременном снижении общей оптимизации сети с точки зрения передачи чистого трафика. BGP-пиринг BGP не обеспечивает надежной передачи информации. Вместо этого BGP полагается на TCP для передачи информации между одноранговыми узлами BGP. Использование TCP гарантирует: Обнаружение MTU обрабатывается даже для соединений, пересекающих несколько переходов (или маршрутизаторов). Управление потоком осуществляется базовым транспортом, поэтому BGP не нуждается в непосредственном управлении потоком (хотя большинство реализаций BGP действительно взаимодействуют со стеком TCP на локальном хосте, чтобы повысить пропускную способность, в частности, для BGP). Двусторонняя связь между одноранговыми узлами обеспечивается трехсторонним рукопожатием, реализованным в TCP. Несмотря на то, что BGP полагается на базовое TCP-соединение для многих функций, которые плоскости управления должны решать при построении смежности, по-прежнему существует ряд функций, которые TCP не может предоставить. Следовательно, необходимо более подробно рассмотреть процесс пиринга BGP. Рисунок 1 позволяет изучить этот процесс. Сеанс пиринга BGP начинается в состоянии ожидания (idle state). A отправляет TCP open на порт 179. B отвечает на временный порт (ephemeral port) на A. После завершения трехстороннего подтверждения TCP (сеанс TCP успешен), BGP перемещает состояние пиринга для подключения. Если пиринговый сеанс формируется через какой-либо тип фильтрации на основе состояния, такой как брандмауэр, важно, чтобы открытое TCP-сообщение передавалось «изнутри» фильтрующего устройства. В случае сбоя TCP-соединения состояние пиринга BGP переводится в активное. A отправляет BGP open в B и переводит B в состояние opensent. В этот момент A ожидает от B отправки сообщения keepalive. Если B не отправляет сообщение keepalive в течение определенного периода, A вернет сеанс обратно в состояние ожидания (idle state). Открытое сообщение содержит ряд параметров, например, какие семейства адресов поддерживают два спикера BGP и hold timer. Это называется согласованием возможностей. Самый низкий (минимальный) hold timer из двух объявленных выбирается в качестве hold timer для однорангового сеанса. Когда B отправляет A сообщение keepalive, A переводит B в состояние openconfirm. На этом этапе A отправит B сообщение keepalive для проверки соединения. Когда A и B получают сообщения поддержки активности друг друга, пиринговый сеанс переходит в established state. Два узла BGP обмениваются маршрутами, поэтому их таблицы обновлены. A и B обмениваются только своими лучшими путями, если какая-либо форма многонаправленного распространения BGP не поддерживается и не настроена на двух спикерах. Чтобы уведомить A, что он завершил отправку всей своей локальной таблицы, B отправляет A сигнал End of Table (EOT) или End of RIB (EOR). Существует два типа пиринговых отношений BGP: одноранговые узлы BGP в одной и той же автономной системе (AS, что обычно означает набор маршрутизаторов в одном административном домене, хотя это довольно общее определение) называются внутренними одноранговыми узлами BGP (internal BGP - iBGP) и Одноранговые узлы BGP между автономными системами называются внешними (или внешними - exterior) узлами BGP (eBGP). Хотя два типа пиринговых отношений BGP построены одинаково, у них разные правила объявления. Процесс выбора оптимального пути BGP Поскольку BGP предназначен для соединения автономных систем, алгоритм наилучшего пути ориентирован в первую очередь на политику, а не на отсутствие петель. Фактически, если вы изучите какое-либо стандартное объяснение процесса наилучшего пути BGP, то, является ли конкретный путь свободным от петель, вообще не будет учитываться в процессе принятия решения. Как же тогда BGP определяет, что конкретный узел объявляет маршрут без петель? Рисунок 2 демонстрирует это. На рисунке 2 каждый маршрутизатор находится в отдельной AS, поэтому каждая пара спикеров BGP будет формировать сеанс пиринга eBGP. A, который подключен к 2001: db8: 3e8: 100 :: / 64, объявляет этот маршрут к B и C. Объявления маршрута BGP несут ряд атрибутов, одним из которых является путь AS. Перед тем, как A объявит 100 :: / 64 для B, он добавляет свой номер AS в атрибут AS Path. B получает маршрут и объявляет его D. Перед объявлением маршрута к D он добавляет AS65001 к AS Path. Тогда путь AS, прослеживающийся от A до C, на каждом шаге выглядит примерно так: Получено B: [AS65000] Получено C: [AS65000, AS65001] Получено D: [AS65000, AS65001, AS65003] Когда D получил маршрут от B, он анонсирует его обратно в C (в BGP нет split horizon). Предположим, что C, в свою очередь, объявляет обратный маршрут к A по какой-то причине (в этой ситуации это не так, потому что путь через A был бы лучшим путем к месту назначения, а просто для демонстрации предотвращения петель), A будет проверять AS Path и обнаружение его локальной AS находится в AS Path. Это явно петля, поэтому A просто игнорирует маршрут. Поскольку этот маршрут игнорируется, он никогда не помещается в таблицу топологии BGP. Следовательно, с использованием процесса наилучшего пути BGP сравниваются только маршруты без петель. В большинстве реализаций процесс наилучшего пути BGP состоит из 13 шагов (первый шаг реализуется не всегда, так как это локальное решение со стороны узла BGP): Выбирается маршрут с наибольшим весом. Некоторые реализации не используют вес маршрута. Выбирается маршрут с наивысшим местным предпочтением (local preference- LOCAL PREF). Local preference собой политику выхода локальной AS - какую точку выхода из доступных точек выхода предпочел бы владелец этой AS, как и узел BGP. Предпочитайте маршрут с локальным происхождением, то есть на этом узле BGP. Этот шаг редко используется в процессе принятия решения. Предпочитайте путь с самым коротким AS Path. Этот шаг предназначен для выбора наиболее эффективного пути через объединенную сеть, выбора пути, который будет проходить через наименьшее количество автономных систем для достижения пункта назначения. Операторы часто добавляют записи AS Path, чтобы повлиять на этот шаг в процессе принятия решения. Предпочитайте путь с наименьшим значением координат. Маршруты, которые перераспределяются из IGP, предпочтительнее маршрутов с неизвестным происхождением. Этот шаг редко оказывает какое - либо влияние на процесс принятия решений. Предпочитайте путь с самым низким multiexit discriminator (MED). MED представляет входную политику удаленной AS. Таким образом, MED сравнивается только в том случае, если от одной и той же соседней AS было получено несколько маршрутов. Если один и тот же маршрут получен от двух разных соседних автономных систем, MED игнорируется. Предпочитайте маршруты eBGP маршрутам iBGP. Предпочитайте маршрут с наименьшей стоимостью IGP до следующего перехода. Если политика локального выхода не задана (в форме локального предпочтения), и соседняя AS не установила политику входа (в форме MED), то путь с ближайшим выходом из локального маршрутизатора выбирается как точка выхода. Определите, следует ли устанавливать несколько путей в таблице маршрутизации (настроена некоторая форма multipath). При сравнении двух внешних маршрутов (полученных от однорангового узла eBGP) предпочтите самый старый маршрут или маршрут, изученный первым. Это правило предотвращает отток маршрутов только потому, что маршруты обновляются. Предпочитайте маршрут, полученный от однорангового узла с наименьшим идентификатором маршрутизатора. Это просто средство разрешения конфликтов для предотвращения оттока в таблице маршрутизации. Предпочитайте маршрут с наименьшей длиной кластера. Предпочитайте маршрут, полученный от однорангового узла с наименьшим адресом пиринга. Это, опять же, просто тай-брейк, выбранный произвольно, чтобы предотвратить ненужные связи и вызвать отток в таблице маршрутизации, и обычно используется, когда два одноранговых узла BGP соединены по двум параллельным каналам. Хотя это кажется долгим процессом, почти каждое решение наилучшего пути в BGP сводится к четырем факторам: локальному предпочтению (local preference), MED, длине AS Path и стоимости IGP. Правила объявления BGP BGP имеет два простых правила для определения того, где объявлять маршрут: Объявляйте лучший путь к каждому пункту назначения каждому узлу eBGP. Объявляйте лучший путь, полученный от однорангового узла eBGP, для каждого однорангового узла iBGP. Еще один способ сформулировать эти два правила: никогда не объявлять маршрут, полученный от iBGP, другому узлу iBGP. Рассмотрим рисунок 3. На рисунке 3 A и B - это одноранговые узлы eBGP, а B и C, а также C и D - одноранговые узлы iBGP. Предположим, A объявляет 2001: db8: 3e8: 100 :: / 64 для B. Поскольку B получил это объявление маршрута от однорангового узла eBGP, он объявит 100 :: / 64 на C, который является одноранговым узлом iBGP. C, изучив этот маршрут, не будет объявлять маршрут к D, поскольку C получил маршрут от однорангового узла iBGP, а D также является одноранговым узлом iBGP. Таким образом, на этом рисунке D не узнает о 100 :: / 64. Это не очень полезно в реальном мире, однако ограничение присутствует не просто так. Рассмотрим, как BGP предотвращает образование петель маршрутизации - передавая список автономных систем, через которые прошел маршрут, в самом объявлении маршрута. При объявлении маршрута от одного спикера iBGP к другому AS Path не изменяется. Если узлы iBGP объявляют маршруты, полученные от одноранговых узлов iBGP, одноранговым узлам iBGP, петли маршрутизации могут быть легко сформированы. Одним из решений этой проблемы является простое построение многоуровневых пиринговых отношений между B и D (помните, что BGP работает поверх TCP. Пока существует IP-соединение между двумя узлами BGP, они могут построить пиринговые отношения). Предположим, что B строит пиринговые отношения с D через C, и ни B, ни D не строят пиринговые отношения с C. Что произойдет, когда трафик переключается на 100 :: / 64 посредством D на C? Что будет с пакетами в этом потоке на C? У C не будет маршрута к 100 :: / 64, поэтому он сбросит трафик. Это может быть решено несколькими способами - например, B и D могут туннелировать трафик через C, поэтому C не обязательно должен иметь доступность к внешнему пункту назначения. BGP также можно настроить для перераспределения маршрутов в любой основной запущенный IGP (это плохо - не делайте этого). Для решения этой проблемы были стандартизированы рефлекторы маршрутов BGP. Рисунок 4 иллюстрирует работу отражателей маршрута. На рисунке 4 E сконфигурирован как рефлектор маршрута. B, C и D настроены как клиенты рефлектора маршрутов (в частности, как клиенты E). A объявляет маршрут 2001: db8: 3e8: 100 :: / 64 к B. B объявляет этот маршрут E, потому что он был получен от однорангового узла eBGP, а E является одноранговым узлом iBGP. E добавляет новый атрибут к маршруту, список кластеров, который указывает путь обновления в AS через кластеры отражателя маршрута. Затем E объявит маршрут каждому из своих клиентов. Предотвращение зацикливания в этом случае обрабатывается списком кластеров. Подведение итогов о BGP Хотя изначально BGP был разработан для соединения автономных систем, его использование распространилось на центры обработки данных, передачу информации о виртуальных частных сетях. Фактически, использование BGP практически безгранично. Постепенно BGP превратился в очень сложный протокол. BGP можно описать как: Проактивный протокол, который узнает о достижимых местах назначения через конфигурацию, локальную информацию и другие протоколы. Протокол вектора пути, который объявляет только лучший путь к каждому соседу и не предотвращает образование петель в автономной системе (если не развернуты рефлекторы маршрута или какая-либо дополнительная функция) Выбор путей без петель путем изучения пути, по которому может быть достигнут пункт назначения Проверка двустороннего подключения и MTU за счет использования TCP в качестве основы для передачи информации.
img
В предыдущей статье мы рассказали, как включить дополнительные функции в OpenScape Voice. Сейчас мы расскажем о том, как создать Call Pickup группы (группы перехвата). /p> Прежде всего, разберемся, что такое Call Pickup группа и для чего она нужна. Она представляет собой несколько телефонных номеров, объединенных в одну группу, внутри которой пользователи могут “перехватывать” звонки друг друга. Другими словами, можно принять звонок, приходящий на другой телефон, состоящий в группе. В одной группе может находиться до 64 абонентов. Сам абонент может находиться только в одной группе перехвата. Создание Call Pickup группы Для начала нужно создать саму группу перехвата. Для этого в Common Management Portal перейдем в раздел Configuration → OpenScape Voice → Business Group → Teams → Call Pickup Groups и нажмем на кнопку Add. Там во вкладке General в поле Group Number указываем номер группы, который будет использоваться в системе. Во вкладке Members нажимаем на Add и там указываем номер телефона, который необходимо добавить в группу. Если телефон уже находится в другой группе, то он будет удален из нее и добавится в новую. Внизу отображается список номеров, состоящих в группе. После того как все абоненты добавлены нажимаем Save и сохраняем настроенную группу. Также добавлять абонента в группу можно в разделе Configuration → OpenScape Voice → Business Group → Members → Subscribers , найдя необходимый номер и перейдя во вкладку Groups. В поле Call Pickup Group ID нужно указать номер группы и нажать Save. Настройка сервисного кода в системе (Prefix Access Code) Для настройки сервисного кода для группы перехвата перейдем в раздел Configuration → OpenScape Voice → Business Group → Translations → Prefix Access Codes и нажмем Add для добавления нового кода. В поле Prefix Access Code вводим код, который будет использоваться для групп перехвата, а в поле Digit Position указываем его длину, чтобы он впоследствии удалялся. Ниже в поле Destination Name из списка выбираем функцию Call Pickup Orig, нажимаем OK и Save. Настройка Call Pickup группы на телефонах Openscape Заходим на веб-интерфейс телефона и переходим во вкладку Administrator → System → Features → Addressing и в поле Group Pickup URI указываем код группы перехвата, который создали ранее. Нажимаем Submit и переходим во вкладку Configuration. Тут необходимо выбрать тип уведомлений, который будет применяться. Group Pickup Tone allowed включает короткий тоновый сигнал, при звонке в группу. При Group Pickup as ringer будет проигрываться стандартный сигнал вызова. Настройка визуальной индикации в пункте Group Pickup visual alert имеет несколько опций: Prompt → индикация на дисплее, перехват при поднятии трубки, Notify - индикация на дисплее, перехват при нажатии кнопки ОК, FPK Only → индикация на программируемой клавише, перехват при нажатии на нее.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59