Простой и эффективный подход к мониторингу сети

Cloud Server | Amber | Комментировать запись

Облачные провайдеры уделяют большое внимание проектированию и реализации инфраструктуры и сервисов, которые были бы ошибкоустойчивыми и высокодоступными одновременно. Хороший провайдер обеспечивает качественный мониторинг, чтобы предвидеть ошибки и минимизировать их влияние на потребителей.

Читайте также: Оптимизация облачной инфраструктуры в 2023

Те же принципы лежат в основе мониторинга сетевой инфраструктуры сервера. Простота — это основной принцип проектирования, к которому нужно относиться серьезно, особенно при изучении состояния сетевой инфраструктуры, которая, как известно, является сложной и многомерной.

В этой статье мы расскажем, как с помощью простого и эффективного подхода получить информацию о состоянии сети, которая позволит мониторить каждый сервер в режиме реального времени.

Основная идея

Для разработки более масштабируемой и управляемой архитектуры необходимо иметь надежную стратегию мониторинга состояния глобальной сети. Однако, мониторинг топологий уровня 2, особенно крупных, является сложной задачей. Сегодня многие облачные провайдеры совершенствуют свои центры обработки данных, что позволяет перейти к сети 3-го уровня и упрощает отслеживание прохождения пакетов через физические и виртуальные каналы.

Несмотря на это, мониторинг состояния сети на различных уровнях стека ISO/OSI, включая прикладные протоколы и распределенные конечные точки, остается сложной задачей. Есть много компаний, которые предоставляют решения для мониторинга сетей разных масштабов, в том числе для облачных провайдеров. Тем не менее, облачные провайдеры сталкиваются с дополнительными проблемами, такими как масштабирование и уровень настройки систем, используемых для достижения масштаба.

Некоторые провайдеры уже применяют подобные средства, но для достижения высокой точности важным фактором остается стоимость приобретения и эксплуатации мониторингового решения. Провайдеры облачных услуг имеют преимущество в том, что они хорошо знают свою сеть, так как они ответственны за ее развертывание, обслуживание аппаратного и программного обеспечения, а также автоматизацию, необходимую для связи с серверами.

Чтобы понять, что мы имеем в виду, давайте рассмотрим облачную сеть так, как мы ее видим. При доставке пакетов в облачной сети может возникнуть множество проблем, так как каждый этап зависит от другого, а это только усложняет ситуацию.

В процессе подключения серверов к сети через внешний адрес (IPv4, IPv6 или зарезервированный IP) пакеты проходят через ряд стеков, включая стек виртуализации сервера, сетевой стек ОС сервера и т.д. Поскольку пакеты проходят через сеть третьего уровня, необходимо принятие решений о маршрутизации на каждом этапе, требующее предварительной настройки плоскости пересылки.

Провайдеры, которые эффективно внедряют точки инструментирования на каждом этапе и объединяют данные в краткую форму, смогут обеспечить клиентам желаемый уровень сервиса в облачной инфраструктуре. Однако, это должно происходить без дополнительных расходов и прерывания инструментального пути.

Путь к решению

Давайте сделаем шаг назад и попытаемся определить, что мы подразумеваем под состоянием сети. Углубляясь в этот раздел, вы можете заметить, что в нем много математики: пусть это вас не пугает! Мы попытались разбить проблему на более мелкие и легко решаемые задачи, о которых проще говорить.

Надежность и доступность

Согласно ANSI Standard Glossary of Software Engineering Terminology, надежность — это способность системы или компонента выполнять свои функции в заданных условиях в течение определенного периода времени. Доступность определяется как степень работоспособности системы или компонента в тот момент, когда это необходимо.

Хотя оба показателя могут быть выражены в виде функции вероятности, разница между ними заключается в том, что надежность учитывает аспект спецификации, а доступность — нет. Другими словами, можно сказать, что:

Надежная система доступна, но доступная система не обязательно надежна.

Теперь, если мы рассмотрим эти определения в контексте сетевых технологий и в частности облачных сетей, мы можем сказать, что для измерения надежности сети может потребоваться спецификация того, что мы считаем правильными условиями, при котором сеть считается надежной. Поскольку это подразумевает аспект производительности (задержка, пропускная способность и джиттер), это гораздо более серьезная проблема и ее лучше оставить для другой статьи.

Значения доступности

Поскольку сначала мы сосредоточились на измерении доступности сети, мы знаем, что доступность обычно определяется как вероятность того, что функция статуса X(t) равна 1 в момент времени t > 0:

Оценка “the system functions at time t” — это результат выполнения ряда конечных и детерминированных шагов, выполненных на наблюдаемой системе в момент времени t. Функция статуса X(t) является булевой, ее можно легко вычислить. Однако в облачной вселенной измерение такой функции статуса может быть сложным из-за специфических особенностей сетевых технологий и производительности, поэтому эту проблему следует тщательно изучить. В абстрактных терминах одна попытка определения такой функции статуса может выглядеть следующим образом:

— это подсистема, на которую можно разбить всю вселенную облачных сетей. Но что именно означает приведенная выше формула?

Далее мы подробно рассмотрим ее значение.

Высокая доступность простыми словами

Функция состояния X — это комбинация функций статуса для каждого из элементов , которые составляют вселенную облачных сетей.

Эта производная формула может быть более или менее точной в зависимости от того, насколько много независимых элементов облачной сети известны и могут быть вычислены эффективно в режиме, близком к реальному времени. Например, если сосредоточиться на сетевом подключении сервера, мы рассматриваем несколько функций статуса, которые мы хотим реализовать:

• () = Software Networking, а именно активное наличие правил OpenFlow (Open vSwitch — это базовый компонент с открытым исходным кодом, который используют провайдеры), которые являются результатом комбинации сервисов, направленных на обеспечение подключения к публичному интерфейсу сервера, а также работы сервисов-демонов, участвующих в обработке правил потока. Например, это могут быть потоки, которые позволяют использовать все случаи, связанные с общедоступными сетями, а именно: подключение v4, v6 и FLIP (опционально), а также все сервисы уровня доступа, которые делают подключение v4 и v6 функциональным: DHCP, ARP, NDP, ICMP или доступ к метаданным. Если функция статуса равна 0, то никакие данные не смогут правильно проходить через сетевой стек операционной системы сервера.
• () = Hypervisor vSwitch; datapath работает, то есть модуль ядра vSwitch действительно передает пакеты в пользовательское пространство и обратно. Для этого может потребоваться периодическая проверка, чтобы известный трафик обрабатывался правильно (например, ARP, NDP, DHCP, ICMP и т. д.).
• () = Hypervisor OS networking stack; гипервизор подключен к сетевой структуре: для центров обработки данных с поддержкой уровня 3 это означает, что HV-as-a-router доступен для обоих семейств протоколов IPv4 и IPv6 в соответствующих VLAN центра обработки данных.
• () = Host Route advertisement; наличие объявлений маршрута хоста для сервера в RIB (информационной базе маршрутизации) региона, с указанием next-hop на гипервизор, на котором запущен сервер, подразумевает, что пакеты будут направляться на HV (исключая другие сетевые ошибки/недоработки).

Рассмотрев способы измерения, записи и экспорта телеметрических данных, связанных с каждой из этих функций, некоторые облачные провайдеры смогли преобразовать их в простой индикатор, который со временем отображает уровень доступности, с которым сталкивается каждый клиентский сервер. На приведенном ниже скриншоте показана доступность сети для внешнего пути IPv4 реального сервера клиента, который был некоторое время в простое из-за неудачного обновления программного обеспечения на гипервизорах. После переноса сервера его сетевая доступность была быстро восстановлена. Внедренное решение для мониторинга смогло поймать сбой в самом начале и практически в режиме реального времени предоставить службе поддержки данные для оценки и устранения сбоя.

Этот инструмент на базе стандартных и открытых технологий не только помогает службе поддержки улучшить видимость во время сбоев, но и позволяет компании раскрыть потенциал данных, которые могут быть проанализированы по регионам, гипервизорам, серверам и глобально.

Подводим итоги

Предложенный подход можно рассматривать как попытку факторизации сложной проблемы доступности сети в облаке: вместо рассмотрения сети в целом он разбивает элементы, влияющие на доступность сети, на более мелкие и понятные проблемы, которые решаются индивидуально. У такого подхода есть ряд положительных последствий: он снизил нагрузку на инженеров, предоставляя при этом минимально жизнеспособное решение; он проводит итерации через последовательные уровни уточнения; он справляется с масштабом, в котором работает инфраструктура; а главное — он сразу приносит пользу клиентам!