По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Новое в IPv6-это автоконфигурация, которая является почти "мини-DHCP" - сервером, и некоторые протоколы были удалены или изменены. Точно так же, как IPv4, хосты, настроенные на IPv6, должны узнать MAC-адрес других устройств, но мы больше не используем ARP, он был заменен протоколом под названием NDP (Neighbour Discovery Protocol).
Теоретические основы
Помимо изучения MAC-адресов, NDP используется для решения ряда задач:
Router Discovery (обнаружение маршрутизаторов): NDP используется для изучения всех доступных маршрутизаторов IPv6 в подсети.
Обнаружение MAC-адресов: после того, как хост выполнил проверку DAD и использует IPv6 адрес он должен будет обнаружить MAC адреса хостов с которыми он хочет общаться.
DAD (обнаружение дубликатов адресов): каждый хост IPv6 будет ждать, чтобы использовать свой адрес, если только он не знает, что ни одно другое устройство не использует тот же адрес. Этот процесс называется DAD, и NDP делает это за нас.
SLAAC: NDP используется, чтобы узнать, какой адрес и длину префикса должен использовать хост.
Мы рассмотрим все задачи, чтобы увидеть, как они работают. Начнем с обнаружения маршрутизатора. Когда хост настроен на IPv6, он автоматически обнаруживает маршрутизаторы в подсети.
Хост IPv6 может использовать NDP для обнаружения всех маршрутизаторов в подсети, которые могут использоваться в качестве шлюза по умолчанию. В принципе, хост отправляет сообщение с запросом, есть ли там какие-либо маршрутизаторы, и маршрутизаторы ответят. Используются два сообщения:
RS (Router Solicitation), который отправляется на "все маршрутизаторы ipv6" FF02::2 multicast адрес.
RA (Router Advertisement) отправляется маршрутизатором и включает в себя его link-local IPv6 адрес.
Когда хост отправляет запрос маршрутизатору, маршрутизатор будет отвечать на одноадресный адрес хоста. Маршрутизаторы также будут периодически отправлять рекламные объявления маршрутизаторов для всех заинтересованных сторон, они будут использовать для этого адрес FF02:: 1 "все узлы".
Большинство маршрутизаторов также будут иметь global unicast адрес, настроенный на интерфейсе, в этом случае хосты будут узнавать не только о link-local адресе, но и о префиксе, который используется в подсети.
Этот префикс можно использовать для SLAAC. NPD также используется в качестве замены ARP. Для этого он использует два вида сообщений:
NS (Neighbor Solicitation)
NA (Neighbor Advertisement)
Запрос соседа работает аналогично запросу ARP, он запрашивает определенный хост для своего MAC-адреса, и объявление соседа похоже на ответ ARP, поскольку оно используется для отправки MAC-адреса. В основном это выглядит так:
Всякий раз, когда хост посылает запрос соседу, он сначала проверяет свой кэш, чтобы узнать, знает ли он уже MAC-адрес устройства, которое он ищет. Если его там нет, он пошлет соседу запрос. Эти соседние запрашивающие сообщения используют solicited-node multicast адрес запрашиваемого узла.
Помимо обнаружения MAC-адресов, сообщения NS и NA также используются для обнаружения дубликатов IPv6-адресов. Прежде чем устройство IPv6 использует одноадресный адрес, оно выполнит DAD (обнаружение дубликатов адресов), чтобы проверить, не использует ли кто-то другой тот же IPv6-адрес. Если адрес используется, хост не будет его использовать. Вот как это выглядит:
Host1 был настроен с IPv6-адресом 2001:1:1:1::2, который уже используется Host2. Он будет посылать запрос соседства, но поскольку host2 имеет тот же IPv6-адрес, он ответит объявлением соседа. Host1 теперь знает, что это дубликат IPv6-адреса. Эта проверка выполняется для всех одноадресных адресов, включая link-local адреса. Это происходит, когда вы настраиваете их и каждый раз, когда интерфейс находится в состоянии "up".
Последний NPD, который мы рассмотрим, - это SLAAC, которая позволяет хостам автоматически настраивать свой IPv6-адрес. Для IPv4 мы всегда использовали DHCP для автоматического назначения IP-адреса, шлюза по умолчанию и DNS-сервера нашим хостам, и эта опция все еще доступна для IPv6 (мы рассмотрим ее ниже).
DHCP прекрасная "вещь", но недостатком является то, что вам нужно установить DHCP-сервер, настроить пул с диапазонами адресов, шлюзами по умолчанию и DNS-серверами.
Когда мы используем SLAAC, наши хосты не получают IPv6-адрес от центрального сервера, но он узнает префикс, используемый в подсети, а затем создает свой собственный идентификатор интерфейса для создания уникального IPv6-адреса. Вот как работает SLAAC:
Хост сначала узнает о префиксе с помощью сообщений NDS RS RA.
Хост принимает префикс и создает идентификатор интерфейса, чтобы создать уникальный IPv6-адрес.
Хост выполняет DAD, чтобы убедиться, что IPv6-адрес не используется никем другим.
Маршрутизаторы Cisco будут использовать EUI-64 для создания идентификатора интерфейса, но некоторые операционные системы будут использовать случайное значение. Благодаря SLAAC хост будет иметь IPv6-адрес и шлюз, но один элемент все еще отсутствует...DNS-сервер. SLAAC не может помочь нам с поиском DNS-сервера, поэтому для этого шага нам все еще требуется DHCP.
DHCP для IPv6 называется DHCPv6 и поставляется в двух формах:
Stateful
Stateless
Мы рассмотрим DHCPv6 чуть позже, но для SLAAC нам нужно понять, что такое stateless DHCPv6. Обычно DHCP-сервер отслеживает IP-адреса, которые были арендованы клиентами, другими словами, он должен сохранять "состояние" того, какие IP-адреса были арендованы и когда они истекают.
Сервер stateless DHCPv6 не отслеживает ничего для клиентов. Он имеет простую конфигурацию с IPv6-адресами нескольких DNS-серверов. Когда хост IPv6 запрашивает у сервера DHCPv6 IPv6-адрес DNS-сервера, он выдает этот адрес, и все.
Поэтому, когда вы используете SLAAC, вам все еще нужен stateless DHCPv6, чтобы узнать о DNS-серверах.
Теперь вы узнали все задачи, которые NPD выполняет для нас:
Router Discovery
MAC Address Discovery
Duplicate Address Detection
Stateless Address Autoconfiguration
Настройка на Cisco
Давайте посмотрим на NPD на некоторых маршрутизаторах, чтобы увидеть, как он работает в реальности. Будет использоваться следующая топология для демонстрации:
Будем использовать OFF1 в качестве хоста, который будет автоматически настраиваться с помощью SLAAC и OFF2 в качестве маршрутизатора. 2001:2:3:4//64 это префикс, который мы будем использовать. Давайте сначала настроим OFF2:
OFF2(config)#ipv6 unicast-routing
Прежде чем OFF2 будет действовать как маршрутизатор, нам нужно убедиться, что включена одноадресная маршрутизация IPv6. Теперь давайте настроим IPv6 адрес на интерфейсе:
OFF2(config)#interface fa0/0
OFF2(config-if)#no shutdown
OFF2(config-if)#ipv6 address 2001:2:3:4::1/64
Перед настройкой OFF1 мы включим отладку NPD на обоих маршрутизаторах, чтобы могли видеть различные сообщения:
OFF1#debug ipv6 nd
ICMP Neighbor Discovery events debugging is on
OFF2#debug ipv6 nd
ICMP Neighbor Discovery events debugging is on
Команда debug ipv6 nd очень полезна, так как она будет показывать различные сообщения, которые использует NPD.
Давайте теперь настроим OFF1:
OFF1(config)#interface fa0/0
OFF1(config-if)#no shutdown
OFF1(config-if)#ipv6 address autoconfig
OFF1 будет настроен для использования SLAAC с командой ipv6 address autoconfig. При включенной отладке вы увидите на своей консоли следующие элементы:
OFF1#
ICMPv6-ND: Sending NS for FE80::C000:6FF:FE7C:0 on FastEthernet0/0
ICMPv6-ND: DAD: FE80::C000:6FF:FE7C:0 is unique.
Он посылает NS для своего собственного IPv6-адреса, и когда никто не отвечает, он понимает, что это единственный хост, использующий этот адрес. Вы также можете видеть, что OFF1 отправляет объявление соседства в сторону OFF2:
OFF1#
ICMPv6-ND: Sending NA for FE80::C000:6FF:FE7C:0 on FastEthernet0/0
OFF2#
ICMPv6-ND: Received NA for FE80::C000:6FF:FE7C:0 on FastEthernet0/0 from FE80::C000:6FF:FE7C:0
Мы можем просмотреть базу данных с информацией L2 и L3 следующим образом:
OFF2#show ipv6 neighbors
IPv6 Address Age Link-layer Addr State
Interface
FE80::C000:6FF:FE7C:0 21 c200.067c.0000 STALE Fa0/0
show ipv6 neighbors покажет вам IPv6-адреса и MAC-адреса. OFF1 также отправит запрос маршрутизатора, а OFF2 в ответ отправит объявление маршрутизатора:
OFF1#
ICMPv6-ND: Sending RS on FastEthernet0/0
OFF2#
ICMPv6-ND: Received RS on FastEthernet0/0 from FE80::C000:6FF:FE7C:0
ICMPv6-ND: Sending solicited RA on FastEthernet0/0
ICMPv6-ND: Sending RA from FE80::C001:6FF:FE7C:0 to FF02::1 on FastEthernet0/0
ICMPv6-ND: MTU = 1500
ICMPv6-ND: prefix = 2001:2:3:4::/64 onlink autoconfig
ICMPv6-ND: 2592000/604800 (valid/preferred)
OFF1#
ICMPv6-ND: Received RA from FE80::C001:6FF:FE7C:0 on FastEthernet0/0
ICMPv6-ND: Selected new default router FE80::C001:6FF:FE7C:0 on FastEthernet0/0
Если вы хотите увидеть все маршрутизаторы, о которых знает ваш хост, вы можете использовать следующую команду:
OFF1#show ipv6 routers
Router FE80::C001:6FF:FE7C:0 on FastEthernet0/0, last update 0 min
Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500
HomeAgentFlag=0, Preference=Medium
Reachable time 0 msec, Retransmit time 0 msec
Prefix 2001:2:3:4::/64 onlink autoconfig
Valid lifetime 2592000, preferred lifetime 604800
Поскольку OFF1 настроен для SLAAC он будет использовать префикс в объявлении маршрутизатора для настройки самого себя:
OFF1#
ICMPv6-ND: Prefix Information change for 2001:2:3:4::/64, 0x0 - 0xE0
ICMPv6-ND: Adding prefix 2001:2:3:4::/64 to FastEthernet0/0
ICMPv6-ND: Sending NS for 2001:2:3:4:C000:6FF:FE7C:0 on FastEthernet0/0
ICMPv6-ND: Autoconfiguring 2001:2:3:4:C000:6FF:FE7C:0 on FastEthernet0/0
ICMPv6-ND: DAD: 2001:2:3:4:C000:6FF:FE7C:0 is unique.
Он будет использовать префикс и автоматически настраивать IPv6-адрес. Прежде чем он использует адрес, он будет использовать DAD, чтобы убедиться, что адрес уникален. Давайте посмотрим IPv6-адрес:
OFF1#show ipv6 int brief
FastEthernet0/0 [up/up]
FE80::C000:6FF:FE7C:0
2001:2:3:4:C000:6FF:FE7C:0
Как вы видите, OFF1 использовал 2001:2:3:4::/64 префикс для настройки самого себя.
Это вся информация о NPD для вас сейчас, давайте продолжим изучение материала обратив подробное внимание на DHCPv6! Статусный DHCPv6 работает аналогично DHCP для IPv4. Мы все еще используем его для предоставления адресов, шлюзов по умолчанию, DNS-серверов и некоторых других опций клиентам, но одним из ключевых отличий являются сообщения, которые мы теперь используем.
DHCP для IPv4 использует сообщения Discover, Offer, Request и ACK. DHCPv6 использует Solicit, Advertise, Request и Reply message.
Время получения сообщения, похожие на сообщения обнаружения. Хост будет использовать это сообщение, когда он ищет IPv6-адрес сервера DHCPv6. Сообщение advertise используется для предоставления хосту IPv6-адреса, шлюза по умолчанию и DNS-сервера. Сообщение запроса используется хостом, чтобы спросить, можно ли использовать эту информацию, и ACK отправляется сервером для подтверждения этого.
Аналогично, как и для DHCP IPv4, когда ваш DHCP-сервер не находится в той же подсети, вам потребуется DHCP relay для пересылки сообщений DHCP на центральный DHCP-сервер.
В этой статье описывается конфигурация, необходимая на маршрутизаторе Cisco для получения сведений о системе доменных имен (DNS) от поставщика услуг и передачи их внутренним пользователям с помощью DHCP. Протокол DNS используется для разрешения полного доменного имени (FQDN) на его соответствующий IP-адрес.
Получение DNS IP адреса от провайдера с помощью PPP
В большинстве корпоративных сетей, где локальный DNS-сервер недоступен, клиенты должны использовать службу DNS, предоставляемую провайдером, или настроить общедоступный DNS-сервер в свободном доступе.
Рис. 1.1 DNS IP-адрес от провайдера с использованием PPP
Настройка локального DHCP-сервера на маршрутизаторе Cisco
Выполните настройку основных параметров DHCP на маршрутизаторе Cisco и включите его для того, чтобы он действовал как DHCP-сервер для локальной сети.
Во-первых, включите службу DHCP на маршрутизаторе Cisco.
R1(config)#service dhcp
Затем создайте пул DHCP, определяющий сетевую подсеть, которая будет передана в аренду DHCP-клиентам в локальной сети.
ip dhcp pool LAN_MY
network 192.168.1.0 255.255.255.0
default-router 192.168.1.1
dns-server 192.168.1.1
Здесь пул DHCP был назван как LAN_MY.
Оператор network задает подсеть и маску пула адресов DHCP
default-router указывает IP-адрес маршрутизатора по умолчанию для DHCP-клиента. Это должен быть IP-адрес в той же подсети, что и клиент
DNS-сервер задает IP-адрес DNS-сервера, который доступен для DHCP-клиента
Включите DNS-сервер на маршрутизаторе Cisco
В режиме глобальной конфигурации включите службу DNS на маршрутизаторе.
R1(config)#ip dns server
Конфигурация для ретрансляции публичной службы DNS от провайдера через PPP
Для того, чтобы получить Public DNS от провайдера, необходимо настроить ppp ipcp dns request на Dialer интерфейсе.
R1(config)#interface dialer 1
R1(config-if)#ppp ipcp dns request
Когда все вышеперечисленные конфигурации будут выполнены:
Команда ppp ipcp dns request сначала помогает получить информацию о публичном DNS-сервере от провайдера через ipcp-фазу согласования PPP.
Затем команда ip dns server позволяет маршрутизатору начать действовать в качестве самого DNS-сервера. Однако маршрутизатор в конечном итоге использует Public DNS service от провайдера для разрешения доменных имен
Кроме того, когда локальный DHCP-сервер раздаст IP-адреса клиентам, он будет представлять себя как DNS-сервер. Все входящие запросы разрешения DNS от клиентов будут обрабатываться маршрутизатором с использованием Public DNS
Проверка
Шаг 1: Запустите debug ppp negotiation и внимательно прочитайте информацию о IPCP, чтобы проверить, предоставляется ли информация о DNS-сервере провайдером.
Шаг 2: выполните команду show ppp interface virtual-access, чтобы узнать о различных параметрах, успешно согласованных во время настройки PPP.
R1# show ppp interface virtual-access 3
Системные администраторы и девопсы теперь могут использовать сетевые ресурсы, хранилища, виртуальные машины, 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 отличаются высокой настраиваемостью и могут быть преобразованы в соответствии с большинством требований к визуализации. Разработчики также могут создавать сложные графики и диаграммы с несколькими метриками и трассировками для предоставления окончательных отчетов о работе систем.
Благодаря размещенным инструментам разработчики могут сразу понять системные данные без необходимости установки нескольких сторонних инструментов.
Заключение
Итак, мы рассмотрели, что такое мониторинг облачной инфраструктуры и приложений, изучили некоторые преимущества мониторинга.
Приведенные в данной статье инструменты благодаря своей гибкости и функционалу, облегчат мониторинг всей инфраструктуры. Можно развернуть и попробовать бесплатные пробные версии и выбрать подходящий под конкретные нужды.