По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Метрические веса TOS K1 K2 K3 K4 K5, выданные командой в режиме конфигурации маршрутизатора EIGRP, может быть использована для установки K-значений, используемых EIGRP в своем расчете. Параметр TOS был предназначен для использования маркировки качества обслуживания (где TOS обозначает тип служебного байта в заголовке IPv4). Однако параметр TOS должен быть равен 0. На самом деле, если вы введете число в диапазоне 1 - 8 и вернетесь назад, чтобы изучить свою текущую конфигурацию, вы обнаружите, что Cisco IOS изменила это значение на 0. Пять оставшихся параметров в команде metric weights - это пять K-значений, каждое из которых может быть задано числом в диапазоне от 0 до 255. Предыдущие статьи из цикла про EIGRP: Часть 1. Понимание EIGRP: обзор, базовая конфигурация и проверка Часть 2. Про соседство и метрики EIGRP Следующие статьи из цикла: Часть 3. Конвергенция EIGRP – настройка таймеров Часть 4. Пассивные интерфейсы в EIGRP Часть 5. Настройка статического соседства в EIGRP Часть 6. EIGRP: идентификатор роутера и требования к соседству Например, представьте, что в нашем проекте мы обеспокоены тем, что нагрузка на наши линии может быть высокой в разы, и мы хотим, чтобы EIGRP учитывал уровень насыщения линии при расчете наилучшего пути. Изучая полную формулу расчета метрики EIGRP, мы замечаем, что наличие ненулевого значения для K2 приведет к тому, что EIGRP будет учитывать нагрузку. Поэтому мы решили установить K2 равным 1, в дополнение к K1 и K3, которые уже установлены в 1 по умолчанию. Значения К4 и К5 сохранится на уровне 0. В приведенном ниже примере показано, как можно настроить такой набор K-значений. OFF1#conf term Enter configuration commands, one per line. End with CNTL/Z . OFF1(config)#router eigrp 1 OFF1(config-router)#metric weights 0 1 1 1 0 0 OFF1(config-router)#end Первый 0 в команде metric weights 0 1 1 1 0 0, показанной в приведенном выше примере, задает значение TOS равное 0. Следующие пять чисел задают наши пять K-значений: K1 = 1, K2 = 1, K3 = 1, K4 = 0, K5 = 0. Этот набор K-значений теперь будет учитывать не только пропускную способность и задержку, но и нагрузку при выполнении расчета метрики. Однако есть проблема. Обратите внимание на сообщения консоли, появляющиеся после нашей конфигурации. Оба наших соседства были разрушены, потому что маршрутизатор OFF1 теперь имеет другие K-значения, чем маршрутизаторы OFF2 и OFF3. Напомним, что соседи EIGRP должны иметь соответствующие K-значения, а это означает, что при изменении K-значений на одном EIGRP-спикер маршрутизаторе, вам нужен идентичный набор K-значений на каждом из его соседей EIGRP. Как только вы настроите соответствующие K-значения на этих соседях, то каждый из этих соседей должен соответствовать K-значениям. Как вы можете видеть, в большой топологии может возникнуть значительная административная нагрузка, связанная с манипуляцией K-значением. Преемник и возможные маршруты преемников Одна из причин, по которой EIGRP быстро восстанавливает соединения в случае сбоя маршрута, заключается в том, что EIGRP часто имеет резервный маршрут, готовый взять на себя управление, если основной маршрут уходит в down. Чтобы убедиться, что резервный маршрут не зависит от основного маршрута, EIGRP тщательно проверяет резервный маршрут, убедившись, что он соответствует условию осуществимости EIGRP. В частности, условие осуществимости гласит: Маршрут EIGRP является возможным маршрутом-преемником, если его сообщенное расстояние (RD) от нашего соседа меньше возможного расстояния (FD) маршрута-преемника. Например, рассмотрим топологию, показанную на следующем рисунке, и соответствующую конфигурацию, приведенную ниже. Обратите внимание, что сеть 10.1.1.8/30 (между маршрутизаторами OFF2 и OFF3) доступна из OFF1 через OFF2 или через OFF3. Если маршрутизатор OFF1 использует маршрут через OFF2, он пересекает канал связи 1 Гбит/с, чтобы достичь целевой сети. Однако маршрут через OFF3 заставляет трафик пересекать более медленное соединение со скоростью 100 Мбит/с. Поскольку EIGRP учитывает пропускную способность и задержку по умолчанию, мы видим, что предпочтительный маршрут проходит через маршрутизатор OFF2. Однако, что делать, если связь между маршрутизаторами OFF1 и OFF2 обрывается? Есть ли возможный преемственный маршрут, который может почти сразу заработать? Опять же, мы видим, что маршрутизатор OFF1 будет использовать возможный маршрут преемника через маршрутизатор OFF3. Однако, прежде чем мы убедимся в этом, мы должны подтвердить, что путь через OFF3 соответствует условию осуществимости. Возможное условие преемника выполнено на маршрутизаторе OFF1 Просто в силу того, что маршрут через маршрутизатор OFF3 (то есть через 10.1.1.6) появляется в выходных данных команды show ip eigrp topology, выполненной на маршрутизаторе OFF1, мы делаем вывод, что путь через OFF3 действительно является возможным маршрутом-преемником. Однако давайте рассмотрим выходные данные немного более внимательно, чтобы определить, почему это возможный маршрут-преемник. Во-первых, рассмотрим запись из выходных данных в приведенном выше примере, идентифицирующую последующий маршрут (то есть предпочтительный маршрут): via 10.1.1.2 (3072/2816), GigabitEthernet0/1 Часть выходных данных via 10.1.1.2 говорит, что этот маршрут указывает на адрес следующего прыжка 10.1.1.2, который является маршрутизатором OFF2. На интерфейсе GigabitEthernet0/1 часть выходных данных указывает, что мы выходим из маршрутизатора OFF1 через интерфейс Gig0/1 (то есть выходной интерфейс). Теперь давайте рассмотрим эти два числа в скобках: (3072/2816). Стоимость 2816 называется зафиксированная дистанция (reported distance (RD). В некоторых литературных источниках это значение также называется advertised distance (AD). Эти термины, синонимы, относятся к метрике EIGRP, сообщенной (или объявленной) нашим соседом по EIGRP. В данном случае значение 2816 говорит нам, что метрика маршрутизатора OFF2 (то есть расстояние) до cети 10.1.1.8/30 равна 2816. Значение 3072 на выходе - это допустимое расстояние маршрутизатора OFF1 (FD). FD вычисляется путем добавления RD нашего соседа к метрике, необходимой для достижения нашего соседа. Поэтому, если мы добавим метрику EIGRP между маршрутизаторами OFF1 и OFF2 к RD маршрутизатора OFF2, мы получим FD (то есть общее расстояние), необходимое для того, чтобы OFF1 добрался до 10.1.1.8/30 через маршрутизатор OFF2. Кстати, причина, по которой маршрутизатор OFF1 определяет наилучший путь к сети 10.1.1.8/30, - это via via router OFF2 (то есть 10.1.1.2) В отличие от маршрутизатора OFF3 (то есть 10.1.1.6), потому что FD пути через OFF1 (3072) меньше, чем FD пути через OFF2 (28,416). Далее рассмотрим запись для возможного последующего маршрута из приведенного выше примера: via 10.1.1.6 (28416/2816), GigabitEthernet0/2 Часть выходных данных via 10.1.1.6 говорит, что этот маршрут указывает на адрес следующего прыжка 10.1.1.6, который является маршрутизатором OFF3. На интерфейсе GigabitEthernet0/2 часть результатов показывает, что мы выходим из маршрутизатора OFF1 через интерфейс Gig0/2. Эта запись имеет FD 28 416 и RD 2816. Однако прежде, чем EIGRP просто слепо сочтет этот резервный путь возможным преемником, он проверяет маршрут на соответствие условию осуществимости. В частности, процесс EIGRP на маршрутизаторе OFF1 запрашивает, является ли RD от маршрутизатора OFF3 меньше, чем FD последующего маршрута. В этом случае RD от маршрутизатора OFF3 составляет 2816, что действительно меньше, чем FD преемника 3072. Поэтому маршрут через маршрутизатор OFF3 считается возможным преемником маршрута. Чтобы утвердить эту важную концепцию, рассмотрим топологию, показанную ниже. Процесс EIGRP на маршрутизаторе OFF1 изучил три пути для достижения сети 10.1.1.0/24. Однако далее EIGRP должен определить, какой из этих путей является маршрутом-преемником, какие (если таковые имеются) пути являются возможными маршрутами-преемниками, а какие (если таковые имеются) пути не являются ни преемником, ни возможным маршрутом-преемником. Результаты расчетов EIGRP приведены в таблице ниже. Примеры расчетов Feasible Successor Используя приведенную выше таблицу в качестве рассмотрения, сначала рассмотрим путь маршрутизатора OFF1 к сети 10.1.1.0/24 через маршрутизатор OFF2. С точки зрения маршрутизатора OFF2, расстояние до сети 10.1.1.0/24 - это расстояние от OFF2 до OFF5 (которое равно 5000) плюс расстояние от OFF5 до сети 10.1.1.0/24 (которое равно 1000). Это дает нам в общей сложности 6000 для расстояния от маршрутизатора OFF2 до сети 10.1.1.0/24. Это расстояние, которое маршрутизатор OFF2 сообщает маршрутизатору OFF1. Таким образом, маршрутизатор OFF1 видит RD 6000 от маршрутизатора OFF2. Маршрутизатор OFF1, затем добавляет расстояние между собой и маршрутизатором OFF2 (который равен 10 000) к RD от OFF2 (который равен 6000), чтобы определить его FD для достижения сети 10.1.1.0/24 составляет 16 000 (то есть 10 000 + 6000 = 16 000). Процесс EIGRP на маршрутизаторе OFF1 выполняет аналогичные вычисления для путей к сети 10.1.1.0/24 через маршрутизаторы OFF3 и OFF4. Ниже приведены расчеты, которые привели к значениям, приведенным в таблице. Затем маршрутизатор OFF1 проверяет результаты этих вычислений и определяет, что кратчайшее расстояние до сети 10.1.1.0/24 проходит через маршрутизатор OFF2, поскольку путь через OFF2 имеет самый низкий FD (16 000). Этот путь, определяемый как кратчайший, считается следующим маршрутом. Затем маршрутизатор OFF1 пытается определить, соответствует ли любой из других маршрутов условию выполнимости EIGRP. В частности, маршрутизатор OFF1 проверяет, чтобы увидеть, что RD от маршрутизаторов OFF3 или OFF4 меньше, чем FD последующего маршрута. В случае OFF3 его RD в 11 000 действительно меньше, чем FD последующего маршрута (который составляет 16 000). Таким образом, путь к сети 10.1.1.0 /24 через OFF3 квалифицируется как возможный маршрут-преемник. Однако маршрут через OFF4 не подходит, потому что RD OFF4 из 18 000 больше, чем 16 000 (FD последующего маршрута). В результате путь к сети 10.1.1.0/24 через маршрутизатор OFF4 не считается возможным маршрутом-преемником. Мы изучили K - значения, теперь почитайте про конвергенцию EIGRP и настройку таймеров
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
The HyperText Transfer Protocol, или HTTP, это самый распространенный в мире протокол уровня приложений модели OSI на сегодняшний день. Протокол HTTP образует пространство, которое большинство людей называют сетью Интернет. Основной задачей протокола HTTP является извлечение HTML (HyperText Markup Language) или любых других документов с WEB – сайтов через сеть Интернет. Каждый раз, когда вы открываете интернет - браузер, в дело вступает протокол HTTP, оперируя поверх стека протоколов TCP/IP. Протокол HTTP был впервые выпущен на свет вначале 1990 года и имел три версии: HTTP/0.9: Простейшая реализация протокола, позволяющая только получать WEB – страницы HTTP/1.0: Даная версия обнародована Инженерным советом Интернета (Internet Engineering Task Force, IETF) в рамках RFC 1945 в 1996 году. В данной версии было добавлено большое количество дополнительных полей, именуемых заголовками в этой спецификации. Эта версия протокола расширяла взаимодействие между клиентом и сервером. HTTP/1.1: Версия 1.1 определена в RFC 2068 советом IETF как доработанная и улучшенная версия протокола HTTP поверх спецификации 1.0. Одним из самых заметных улучшений версии 1.1 по сравнению с 1.0 стало внедрений методов постоянных TCP сессий, возможность отправки нескольких HTTP запросов одновременно, не дожидаясь ответа сервера (повышение скорости работы) и реализация алгоритма кэширования. На сегодняшний день, большинство современных интернет – браузеров поддерживают обе версии 1.0 и 1.1 протокола HTTP. Важно отметить, что современные браузеры обеспечивают полную совместимость данных версий, то есть при условии отправки запрос версии 1.0 и получения ответа 1.1, данные будут успешно обработаны. Получение веб страницы по HTTP Рассмотрим процесс получения WEB – страницы обычным интернет браузером с сервера. Любая HTML страница содержит в себе множество объектов, тэгов и изображений. В целом, HTML можно рассматривать как структуру страницы, в которой все объекты расставлены на свои места. В свою очередь, интернет – браузер получает инструкции в рамках этого HTML документа, откуда брать шрифты, цвета, фон и прочие элементы оформления страницы. Порядок таков: Клиент (браузер) отправляет запрос на WEB – сервер для запрашиваемой страницы. Сервер анализирует запрос и отправляет HTML код необходимый для формирования страницы. Клиент начинает анализировать полученный документ и формировать WEB – страницу. Клиент в последующих запросах будет формировать изображения, видео или любую другую форму внутренних объектов из источников WEB – сервера. Когда все элементы страницы получены, клиент (интернет браузер) отобразит запрошенную WEB – страницу. Порядок и время работы зависят от версии протокола (1.0 или 1.1). HTTP запросы Протокол HTTP (HyperText Transfer Protocol) позволяет не только получать HTML документы с Web – серверов, но и передавать информацию от клиента к серверу. Заголовки запросов в протокол HTTP версий 1.0 и 1.1 указаны в таблице ниже: Запрос Описание HTTP/1.0 HTTP/1.1 GET Это запрос почти аналогичен запросу GET. Отличие в том, что сервер не должен возвращать в ответ содержание HTML, а только HTTP заголовок. Да Да HEAD Это запрос почти аналогичен запросу GET. Отличие в том, что сервер не должен возвращать в ответ содержание HTML, а только HTTP заголовок. Да Да HEAD Это запрос почти аналогичен запросу GET. Отличие в том, что сервер не должен возвращать в ответ содержание HTML, а только HTTP заголовок. Да Да POST Позволяет клиенту отправлять информацию в сторону сервера, например через различные встроенные в сайт формы Да Да PUT Позволяет клиенту добавить файл в определенную директорию сервера. Нет Да DELETE Позволяет клиенту удалить файл указанный в рамках запроса. Нет Да TRACE Позволяет клиенту отслеживать свой запрос к серверу. Нет Да OPTIONS Позволяет клиенту определять параметры взаимодействия с сервером. Нет Да В стандартном понимании Web – сайта, запросы GET и POST являются наиболее часто используемыми. Метода GET используется клиентом для получения каждого отдельного объекта страницы, в то время как POST зачастую используется в интернет магазинах, где необходимо отправить информацию в строну сервера. Что такое URL? Uniform Resource Locator (URL) одна из самых важных составляющих любого GET запроса, который состоит из хоста, на котором находится сайт, схемы обращения (сетевой протокол) и полного пути к HTML файлу. Опционально, URL может содержать в себе информацию о номере TCP порта и определенной точки на странице. Ниже приведен типичный пример URL:
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59