Mesh-сети

Абонентский IP логический адрес пользователя в сети. В малых сетях обычно используются статические адреса, прописанные вручную, а в более массовых автоматическое назначение через DHCP. За каждый сегмент локальной или глобальной сети отвечает некое лицо или организация, в чьи обязанности входит управление маршрутизацией и контроль IP-адресов.

В большинстве случаев произвольная смена адреса, выданного администратором, не несет абоненту практической пользы, т.к. может отсечь его от сети. Более опытный пользователь знает про коллизию адресов и может этим злоупотребить: назначить своему устройству уже занятый адрес, тем самым лишив изначального хозяина IP-адреса возможности использовать сеть. В обычных сетях за подобным хулиганством бдит администратор, а что происходит в масштабируемых сетях с автоматической маршрутизацией, где контроль за пользователями вовсе отсутствует? Разберем решение этой задачи в Yggdrasil Network масштабируемой меш-сети с оконечным шифрованием и IPv6-маршрутизацией.

Никакого мошенничества

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

Первый байт 02 адреса IPv6-Yggdrasil является константой, а дальше интереснее: от публичного ключа x25519 берется хеш SHA512, количество лидирующих единиц которого, т.е. битов, установленных в ненулевом состоянии, образует второй байт.

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

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

Почва для размышлений

Хеш SHA512 составляет 64 байта, в том время как адрес IPv6 даже с учетом константы 02 всего лишь 16 байт, а изначальный ключ x25519 32 байта.

Некоторые пользователи сомневаются в практической пользе такого решения и считают, что вполне реально найти ключи с коллизией адресов, т.к. массив данных ключа увеличивается вдвое, а затем от него берется лишь небольшая часть (примерно 1/5), которая образует IPv6. При всем желании, модель угрозы нахождения разных ключей с одинаковым адресом не была подтверждена практически, что говорит о сложно исчислимом количестве вариаций адресов даже при таком на первый взгляд необычном подходе к их образованию.

Разработчики Yggdrasil постарались усложнить подбор адресов. Первые непрерывно идущие единичные биты создают дополнительный фактор уникальности адреса. Вероятность подобрать последовательность из последних 14 байт IPv6 кажется весьма реалистичной, однако общий успех менее вероятен, т.к. напрямую зависит от количества лидирующих единиц в хеше 2-го байта. Отсюда выходит понятие высокого адреса адреса с большим значением во втором байте и, следовательно, с более обширным использованием 64-байтного массива от SHA512. Исходя из этого, имеет смысл майнить высокие адреса для серьезных проектов.

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

На текущий момент есть большое разнообразие обратных прокси серверов. Я перечислю только парочку из них.

• Nginx

• Envoy

• HAProxy

• Traefik

Также у каждого уважающего себя клауд провайдера есть свой прокси сервер.

• AWS Elastic LoadBalancer

• Google Cloud Load Balancer

• DigitalOcean Load Balancer

• Azure load balancer

Дадим определение слову обратный прокси-сервер.

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

И картинку прилепим для наглядности.

Какую проблему решают прокси сервера?

Акт первый

У нас есть веб-сайт, который не поддерживает HTTPS(т.к. общение по TLS/SSL не программировали). Сказать девелоперам запилить это - легко, а вот самим девелоперам может быть напряжно с реализацией. Если у нас приложение монолит - нам нужно внести изменения в этот, чаще всего не поворотливый агрегат, и доставить это на продакшн, если у нас легкие микросервисы, каждый надо посетить, в каждый надо внести небольшие правки + опять таки всё это доставить.

Как решаем проблему? Берем ничем не занятого SysOps/DevOps, говорим, что нам нужен https. Какой-тоOps ставит нам прокси сервер настраивает его на приём HTTPS трафика + SSL termination. Задача решена, цена решения: 1 Какой-тоOps.

Акт второй

Да осталось у нас то самое приложение, да сделали инженеры его чтобы оно могло масштабироваться горизонтально, да подняли аж две копии приложения. Супер! Как настроить так, чтобы трафик равномерно на оба поступал?

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

В итоге: двух зайцев, так сказать.

Акт третий

Взломали нас "хакеры", беда. Дать такому повториться - ну никак нельзя.

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

Чтож, и это проблему поможет нам прокси сервер решить, на него "вещаем" все эти настройки и никакие "хакеры" нашу мега-сесурити не обойдут. Главное настроить правильно, чтобы CEO при демках за хакера не посчитало.

Акт четвертый

Так-так, HTTPS - есть, балансировщик - есть, защита от хакеров - есть, казалось бы, сиди и чиль себе перед телеком, но снова что-то не так. Запросы по сети гуляют долго, пару десятков вообще не вернулись, клиенты в панике.

Анализируем проблему, ага, к гадалке - у нас огромный "пэйлоад в запросах" и парочка "популярных" конечных точек (пользователи любят часть сервиса и активно ей пользуются).

Чтож, лепим на уровне нашего прокси сервер сжатие запроса и кэшируем на нём ответы серверов приложения. Это что получается? Опять двух зайцев? Так точно!

Теперь запросы на холодную возвращаются быстрее некуда, а с кэшом, так и подавно.

Акт пятый

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

Новых функций в продакшн страдает доставка что если?

A/B тестирование можно настроить с прокси сервера помощью, что лучше может быть, чем отказ системы полный при багах в новом релизе? Правильно, у части пользователей только отказ.

После внедрения этой фичи, репутация вашего приложения не будет страдать так сильно, как страдала до внедрения A/B тестирования, т.к. негативные комментарии будут писаться только узким кругом "счастливчиков".

Суммируем выше сказанное

Функции которые предоставляют прокси-сервера:

• Поддержка SSL/TLS трафика

• SSL/TLS termination

• Балансировка нагрузки

• Проверка жизнеспособности целевых серверов

• Сжатие содержимого

• Кэширование запросов

• Файрвол/DDoS-защита

• A/B тестирование

Итого, добавляя в ваше приложение прокси сервер, ваша жизнь станет простой и понятной, вы познаете Дзен, начнёте больше общаться с близкими, наладится пищеварение и ...

Добрый день,

Меня зовут Алексей Бабушкин. Я СЕО независимого дизайн хауса электроники Hi-tech nation. Мы занимаемся контрактной разработкой продуктов в области интернета вещей. В свободное от работы время пилим свои решения с использованием беспроводной передачи данных и тестируем продуктовые гипотезы. Так родилась концепция независимой инфраструктуры для IIoT систем на основе mesh сети, которой я хочу с вами поделиться.

Начнём с теории

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

Типовая архитектура таких систем состоит из следующих 3-х уровней:

- оконечные периферийные устройства (датчики, контроллеры, исполнительные устройства и пр.). Этот уровень отвечает за сбор информации с устройств и за приведение её к стандартному виду, фильтрацию и локальное хранение;

- сетевые шлюзы (роутеры, gateway станции и пр.). Они создают инфраструктуру для управления и обмена данными между устройствами посредством проводных или беспроводных протоколов (RS-485, Modbus, CAN, BLE, Wi-Fi, ZigBee, LoRa, и пр.). На этом уровне происходит предварительная обработка информации, выстраивается коммуникация с верхнем уровнем и предоставляется возможность настройки и управления через веб-приложения;

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

Теперь немного глубже

На старте формирования нашей концепции мы решили проанализировать все три уровня и выделить их слабые стороны.

На первом уровне главной головной болью является вопрос нахождения баланса между вычислительными возможностями оконечных устройств, их роли в работе всей системы и энергопотреблением. Современные сложные IIoT системы требуют большей автономности работы (в отрыве от сервера), быстрой реакции на команды (в части исполнительных устройств), дополнительной обработки информации, принятия решений на местах и простоты установки и настройки (желательно по принципу plug and play). При этом никто не отменял запрос на более низкую цену из-за большого количества подключенных устройств.

Слабые стороны второго уровня связаны, в первую очередь, с набирающим обороты переходом на беспроводную передачу данных. Радиоэфир становится все более перегруженным, поскольку большинство нелицензированных беспроводных технологий основаны на частоте 2,4 ГГц. Вскоре это станет одним из самых ограниченных ресурсов. Также стоит отметить неблагоприятную среду, в условиях реально работающих промышленных объектов, в которой приходится функционировать IIoT (большое количество металлоконструкций, высокочастотные помехи от работы производственного оборудования, Wi-Fi сети и пр.). Все эти факторы в совокупности могут привести к снижению качества работы IIoT системы или даже к полной остановке её работы. Чтобы избежать проблем со связью в будущем, современные беспроводные решения должны уметь сосуществовать с другими беспроводными технологиями, поддерживать динамическую смену каналов и работать на других частотах, например, 433 или 868 МГц.

Что касается непосредственно сетевых шлюзов, то сегодня многие производители устанавливают в свое оборудование, например, в те же роутеры или gateway-станции, как можно более высокопроизводительное "железо". Делается это не для улучшения качество сигнала, а чтобы предоставить пользователю, дополнительный функционал управления, со сложными графическими интерфейсами, выводом статистики и т.д. В первую очередь они делают это для того, чтобы оправдать завышенную стоимость новинок. Во вторую с целью улучшения пользовательского опыта при взаимодействии с продуктом. Понятно, что подобные действия продиктованы бизнесом. Возникает вопрос: зачем такое удорожание конечному пользователю. Такой подход противоречит основному принципу концепции промышленного интернета вещей, который гласит: стоимость решения не должна превышать ценность, которую пользователь получает в результате внедрения. Соответственно в интересах пользователей себестоимость отдельных компонентов должна не увеличиваться, а наоборот снижаться, как и стоимость обслуживания.

Слабые стороны третьего уровня связаны в первую очередь с недостатками облачных решений. К таким можно отнести вопросы безопасности. Согласно исследованию Crowd Research, проведенному в 2019 году, около 90% специалистов по кибербезопасности обеспокоены безопасностью используемых облачных сервисов. В некоторых отраслях (например, оборонно-промышленный комплекс) службы безопасности на основе внутренних нормативных актов ограничивают передачу данных за периметр предприятия, что исключает возможность использования облачных решений в принципе. Ещё одним недостатком облачных сервисов считают большую степень зависимости от поставщиков услуг (так называемый vendor lock-in), которые помимо предоставления сервисов и инфраструктуры, потенциально получают неконтролируемое влияние на рынок и клиентов. Так же сюда можно отнести высокую стоимость предоставления подобного рода услуг.

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

Так исторически сложилось

Все периферийные устройства мы, как правило, разрабатываем на основе микроконтроллера ESP32 разработанного компанией Espressif Systems. На наш взгляд, сегодня это один из лучших вариантов с точки зрения цена/качество/производительность на рынке. За вполне приемлемую цену мы получаем два ядра, аппаратные блоки шифрования, интегрированныеWi-FiиBluetooth модули, практически все периферийные интерфейсы и встроенный сопроцессор, на котором, посредством программирования на Assembler, можно весьма эффективно решать различные фоновые задачи в режиме ультранизкого потребления. Пришлось, конечно, практически полностью переписать китайский SDK, но сейчас не об этом.

Mesh

Беспроводную передачу данных мы решили строить на основе разработанной нашими инженерами mesh-cети. Q-mesh это сетевой протокол, построенный поверх протоколов IEEE 802.11n, IEEE 802.11lr и Bluetooth, позволяющий объединять многочисленные устройства, распределенные по большой площади как внутри, так и снаружи помещения в единую беспроводную локальную сеть. Сеть работает на частотах 2.4 ГГц и 868 МГц или 433 МГц. Частота 2.4 ГГц используется как основная, а частота 868 МГц или 433 МГц как дополнительная, для повышения надёжности, а также для маршрутизации между удаленными сегментами сети.

Наше решение отличается от аналогичных беспроводных решений тем, что не требует применения выделенной gateway станции. Любое из оконечных устройств, имеющих гарантированное питание, может полноценно взять на себя её функции. Выбор такого устройства происходит автоматически. Как правило, им становится то, у которого лучше условия обмена информацией. Например, самый низкий уровень помех, наибольшее число доступных устройств и т.д. Если устройство, выступающее в роли ведущего, по каким-либо причинам выходит из строя, то в течение нескольких секунд будет назначено другое. Замена происходит незаметно для пользователя.

Как мы храним данные

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

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

В процессе работы такой системы может генерироваться значительный объем данных. Для их хранения, обработки и маршрутизации в системе предусмотрены сервера, построенные на микро сервисной архитектуре, которая позволяет распределять нагрузки. Это делает систему более устойчивой и надежной. Сервера обеспечивают передачу данных между удаленными ячейками mesh-сети, синхронизируют данные между собой и обновляют данные у пользователей в реальном времени. Устройства и пользователи подключаются к системе через веб-сокеты, что обеспечивает быстрый отклик устройств на команды и быстрое предоставление свежих данных пользователям.

Автономное питание

Все вычисления осуществляются внутри системы распределенным способом, в зависимости от источника питания. Что имеется в виду? Если одному из устройств с автономным питанием необходимо произвести сложные и энергозатратные вычисления, то система перенаправит эту задачу ближайшему устройству, имеющему постоянное сетевое питание. Такой подход обеспечивает приемлемый срок автономной работы для устройств с автономным питанием и ускоряет процесс принятия решения.

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

Передача данных

В отличие от традиционных сетей, например, Wi-Fi, Q-mesh поддерживает динамический выбор канала, основываясь на информации о загрузке каналов, интенсивности и спектре помех. Это способствует более устойчивой работе системы в условиях загруженного радиоэфира.

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

Скорость передачи данных в диапазоне 2.4 ГГц составляет от 0.25 до 112 Мбит/сек, а время задержки передачи от точки к точке от 5 до 50 миллисекунд. Скорость передачи данных в диапазоне 868 МГц составляет 1 Мбит/сек. Передача данных в диапазоне 433 МГц происходит на скорости 0.25 Мбит/сек.

Безопасность сети обеспечивается применением современных алгоритмов шифрования (AES с длиной ключа 192 или 256 бит) с использованием аппаратной поддержки. Трафик туннелируется между сервером и устройством или между парой устройств и шифруется отдельным ключом.Ключ генерируется из шума радиоэфира.

Управление и настройка

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

Управление и настройка такой системы происходит через веб-интерфейс, который может раздавать любое из устройств системы выполняющего роль сетевого шлюза (gateway станции). Учитывая ограниченные вычислительные возможности периферийных устройств, поддержку веб-интерфейса они отдают в виде скрипта на сторону браузера смартфона, ПК или планшета, которые, располагают куда большей производительностью. Так как это происходит только в момент, когда пользователь взаимодействует с системой, то нагрузки на принимающую сторону не значительны. В свою очередь, для того, чтобы устройство проснулось и передало необходимые данные дальше, ему также не нужны большие вычислительные ресурсы. Поэтому мы можем использовать более дешевые и менее производительные микроконтроллеры, создавая для пользователя дополнительную ценность. В дополнение к этому, решения для браузеров легко интегрировать, так как они работают практически с любой ОС: Linux, Mac, Android и т.п. Таким образом, на том же ESP32 с 256 Кбайт оперативной памяти, мы можем запускать веб-приложения практически, любой сложности и с любой графикой, производить сложные вычисления на стороне веб-приложения с приемлемой скоростью отображения. Это возможно потому, что основная обработка происходит на стороне значительно более производительного оборудования и, поэтому, запас вычислительных ресурсов у нас практически безграничный.

Резюме

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

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

В этом посте мы собрали советы и рекомендации, которые стоит изучить, прежде чем переносить свои приложения в сервисную сетку OpenShift Service Mesh (OSSM). Если вы никогда не сталкивались с сервисными сетками Service Mesh, то для начала можно глянуть страницу OSSM на сайте Red Hat и почитать о том, как система Istio реализована на платформе OpenShift.

Начав изучать Istio, вы скорее всего столкнетесь с приложением bookinfo, которое почти повсеместно используется в качеств наглядного пособия, или же с более продвинутым вариантом в виде приложения Travel Agency. Разбирая эти и другие примеры, вы сможете лучшее понять, как устроена mesh-сетка, и затем уже переносить в нее свои приложения

Сначала о главном

Начать стоит с официальная документация OpenShift Service Mesh 2.0 (OSSM), в ней можно найти массу полезных материалов, в том числе:

• Описание различий между OSSM и родительским СПО-проектом Istio.

• Описание, как установить OSSMи

• Протестировать ее с помощью приложения-примера bookinfo.

• Istiov1.6(архив версий).

• Kialiv1.24(архив версий).

• Jaeger1.20.

Когда дойдет до интеграции вашего приложения в mesh-сетку, надо будет копнуть поглубже и заглянуть в документацию по Istio. Также стоит ознакомиться с release notes соответствующих версий компонентов, входящих Red Hat OSSM.

Если еще не сделали это, то протестируйте свою mesh-сетку с помощью приложения-примера Bookinfo. Если все пройдет нормально, то в нее уже можно будет добавлять ваше приложение.

Первое, что надо сделать при добавлении в mesh-сетку своего приложения убедиться, что sidecarы проксей Envoy правильно внедрены в podы вашего приложения. В OSSM такое внедрение делается довольно просто и хорошо описывается в документации.

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

Выбор протоколов

Важно четко понимать, как Istio определяет, какие протоколы использует ваше приложение. Для этого изучите все, что связано с Protocol Selection и app and version labelsв разделе документации Pods and Services.

В противном случае скорее всего произойдет следующий казус. Допустим, вы внедряете в свое приложение sidecarы проксей Istio, загружаете его тестовым трафиком и идёте смотреть граф Kiali. И видите там совсем не то, что ожидали (рис. ниже). Почему? Потому что Kiali и Istio не смогли правильно определить, какие протоколы используют наши сервисы, и отобразили соединения между ними как TCP, а не HTTP.

Istio должен точно знать, какой протокол используется. Если Istio не может определить протокол автоматически, то трактует трафик как обычный (plain) TCP. Если у вас какие-то другие протоколы, их надо вручную прописать в определениях служб Kubernetes Service вашего приложения. Подробнее об этом написано в документации, раздел Protocol Selection.

Чтобы вручную задать, какой протокол использует ваш сервис, надо соответствующим образом настроить объекты Kubernetes Service. В нашем случае в них по умолчанию отсутствовало значение параметра spec -> ports -> name. Если прописать "name: http" для сервисов A, B и C, то граф отобразит эти соединения как HTTP.

Kiali

Kiali это отличный инструмент для того, чтобы начать работать с OpenShift Service Mesh. Можно даже сказать, что именно на нем и надо сосредоточиться, когда вы начинаете работать с mesh-сеткой.

Kiali визуализирует метрики, генерируемые Istio, и помогает понять, что происходит в mesh-сетке. В качестве одной из первоочередных задач мы настоятельно рекомендуем изучить документацию Kiali.

Kiali не только пригодится для визуализации вашего приложения, но и поможет с созданием, проверкой и управлением конфигурациями mesh-сетки. Поначалу изучение конфигураций Istio может быть делом сложным, и Kiali тут сильно поможет.

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

• Функции настройки и валидации

• Мастера настройки и верификация настроек

• Автоматическое внедрение sidecarов

• Функции корреляции в Kiali

Другая важная вещь умение маркировать сервисы приложения с помощью меток (label). Istio, а следовательно и Kiali, требует, чтобы маркировка велась строго определенным образом, который поначалу отнюдь не кажется очевидным, особенно когда весь ваш опыт исчерпывается работой с приложением-примером Bookinfo, где все метки уже есть и всё прекрасно работает из коробки.

Развертывания с использованием меток app и version это важно, поскольку они добавляет контекстную информацию к метрикам и телеметрии, которые собираются Istio и затем используются в Kiali и Jaeger.

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

Еще одна полезная вещь в Kiali это то, что она может провести проверку вашей mesh-сетки, что особенно полезно, когда вы сами создаете конфигурации.

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

Jaeger-выборки

При первоначальном тестировании своего приложения в mesh-сетке вам, скорее всего, захочется, чтобы частота трассировки была больше 50%, желательно, 100%, чтобы отслеживать все тестовые запросы, проходящие через приложение. В этом случае Jaeger и Kiali быстрее наберут необходимые данные, а вам не придется долго ждать обновления информации.

Иначе говоря, нам надо, чтобы sample rate был равен 100% (тут есть соответствие: 10000 = 100%).

Для этого надо подредактировать объект ServiceMeshControlPlane (обычно называется basic-install) в вашем проекте Control Plane (обычно istio-system) и добавить или изменить там следующее значение:

spec: tracing:  sampling: 10000 # 100%

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

Распространение заголовков контекста трассировки

Jaeger помогает убрать одну из проблем, которая возникает при переходе на микросервисную архитектуру, но для этого все сервисы вашего приложения должны правильно распространять заголовки трассировки (trace headers).

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

Обратите внимание, что в OSSM spanы (единицы работы) автоматически генерируются средствами Istio, а вот трассы нет. Поэтому чтобы распределенные трассы (distributed traces) были полностью просматриваемыми, разработчик должен изменить код так, чтобы любые существующие trace-заголовки правильно копировались при передаче запроса между сервисами. К счастью, вы не обязаны сами генерировать эти заголовки. Если изначально их нет, то они будут автоматически сгенерированы и добавлены первым Envoy-прокси, который встретится на пути запроса (обычно это прокси на ingress-шлюзе).

Вот список заголовков для распространения:

• x-request-id

• x-b3-traceid

• x-b3-spanid

• x-b3-parentspanid

• x-b3-sampled

• x-b3-flags

• x-ot-span-context

Распространение заголовков может выполняться вручную или с использованием клиентских библиотек Jaeger, реализующих OpenTracing API.

Вот как делается ручное распространение trace-контекста на Java:

HttpHeaders upstreamHttpHeaders = new HttpHeaders();if (downstreamHttpHeaders.getHeader(headerName: "x-request-id") != null)   upstreamHttpHeaders.set("x-request-id", downstreamHttpHeaders.getHeader( headerName: "x-request-id"));

Примечание: это надо повторить для всех заголовков из списка выше.

Мастера Kiali и редактор YAML

Проверки

Ручная настройка yaml-манифестов дело утомительное, особенно если значения в одном yaml должны совпадать со значениями в другом, а еще ведь есть жесткие правила отступов. К счастью, в Kiali есть отличная функция, которая поможет при создании и проверке конфигураций.

Создание Istio-ресурсов с помощью Kiali-мастеров

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

YAML-редактор

Kiali имеет собственный редактор YAML для просмотра и редактирования конфигурационных ресурсов Istio напрямую, который также выявляет некорректные конфигурации.

Часто бывает так, что граф Kiali вдруг выявляет в вашем приложении неизвестные ранее (в том числе и разработчикам) коммуникационные пути. Другими словами, Kiali помогает найти и выявить все существующие пути во время тестирования вашего приложения. Это, конечно, полезно, но иногда может и раздражать. В этом случае их можно просто не отображать на графе, введя "node=unknown" в поле ввода над графом Kiali.

Уберите из кода шифрование коммуникаций

Если вы уже защитили соединения между своими сервисами и/или (скорее всего) используете TLS для внешних соединений, то при переводе приложения в mesh-сетку их надо будет в обязательном порядке выключить и переключиться на чистый HTTP без шифрования. А всем шифрованием теперь займутся Envoy-прокси.

Если ваши сервисы будут связываться с внешними сервисами по TLS, то Istio не сможет инспектировать трафик и Kiali будет отображать эти соединения только как TCP.

В общем, используйте для взаимодействия сервисов только HTTP, но не HTTPS.

Также про внешние сервисы надо поставить в известность и вашу mesh-сетку (см. ниже Настройка внешних сервисов).

Упростите код

Самое время пересмотреть код вашего приложения и убрать из него лишнее.

Одно из преимуществ Service Mesh состоит в том, что реализацию многих вещей по сервисам можно убрать из приложения и отдать на откуп платформе, что помогает разработчикам сосредоточиться на бизнес-логике и упростить код. Например, можно рассмотреть следующие доработки:

• Как сказано выше, убрать HTTPS-шифрование.

• Убрать всю логику обработки таймаутов и повторных попыток.

• Убрать все ставшие ненужными библиотеки.

• Помните, что mesh-сетка увеличивает количество пулов подключений. Если раньше два сервиса связывались напрямую, то теперь у каждого из них есть свой прокси-посредник. То есть фактически вместо одного пула подключений появляются три:

  1. От вашего первого сервиса к локальному для него sidecarу Envoy (расположены в одном и том же podе).

  2. От этого sidecarа к другому sidecarу Envoy, который обслуживает второй сервис и расположен в одном podе с этим сервисом.

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

Еще один плюс оптимизации кода это возможность уменьшить размер сервисов и (возможно) поднять их производительность, убрав из них те вещи, которые теперь реализуются на уровне mesh-сетки.

Объекты Service

Убедитесь, что все сервисы вашего приложения взаимодействуют друг с другом через имена объектов Kubernetes Service, а не через OpenShift Routes.

Просто проверьте, вдруг ваши разработчики используют OpenShift Routes (конечные точки ingress на кластере) для организации коммуникаций между сервисами в пределах одного кластера. Если эти сервисы должны входить в одну и ту же mesh-сетку, то разработчиков надо заставить поменять конфигурации/манифесты своих приложений, чтобы вместо конечных точек OpenShift Route использовались имена объектов Kubernetes Service.

Функции аварийного переключения (fallback)

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

Настройка внешних сервисов

Envoy-прокси могут работать не только внутри кластера, но и отправлять трафик за его пределы, если зарегистрировать внешние сервисы в mesh-сетке.

Скорее всего, ваше приложение общается с сервисами за пределами mesh-сетки. Поскольку это внешние по отношению mesh-сетке сервисы, то толку от нее здесь не будет, да? А вот и нет. Эти внешние сервисы можно прописать в Service Mesh и использовать часть её функций и для них.

Подробнее и с примерами можно почитать об этом в документации OSSM. Есть и подробный разбор, как визуализировать внешний трафик Istio в Kiali, и как использовать TLS originationдля зашифрованного egress-трафика.

Вот некоторые из функций Istio, которые можно использовать при работе с внешними сервисами:

1. Шифрование (и простое, и Mutual TLS).

2. Таймауты и повторы.

3. Circuit breakerы.

4. Маршрутизация трафика.

Заключение

С OpenShift Service Mesh вы можете лучше понять, как устроена ваша mesh-сетка, сделать ее более просматриваемой, что, в свою очередь, помогает поднять общий уровень сложности микросервисной архитектуры. Бонусом идет возможность реализовать больше функций и возможностей на уровне самой платформе OpenShift, а не кодировать их на уровне отдельных приложений, что облегчает жизнь разработчикам. Еще один плюс реализация вещей, которые раньше казались неподъемными, например, канареечное развертывание, A/B-тестирование и т.п. Кроме того, вы получаете целостный подход к управлению микросервисными приложениями на всех своих кластерах OpenShift, что хорошо с точки зрения преемственности людей и непрерывности процессов. В конечном итоге, это поможет перейти от монолитных приложений к распределенной микросервисной архитектуре и работать в большей степени на уровне конфигураций, чем кода.

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

Общее представление о топологии

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

Как видно на иллюстрации, самой уязвимой является топология звезда, она же является самой распространенной в быту из-за простоты организации. За примером далеко ходить не нужно: наверняка у вас дома или в офисе стоит единственный коммутатор или роутер, через который все компьютеры объединяются в одну локальную сеть. Если связующее устройство будет отключено, все абоненты останутся без связи. Топологию дерево можно считать логическим продолжением звезды: представьте здание, где на каждом этаже стоит отдельный коммутатор, к которому подключаются расположенные на нем офисы. Благодаря связи коммутаторов между собой, офисы с разных этажей могут общаться. Если коммутатор на втором этаже сломается, офисы на других этажах смогут по-прежнему взаимодействовать между собой, однако связь первого этажа с остальными будет потеряна.

Mesh или ячеистая топология сетевая архитектура, в рамках которой все участники сети являются равноправными и выступают одновременно клиентом и маршрутизатором для других участников. Главное преимущество меша заключается в высокой отказоустойчивости, а минус в сложности практической реализации. Ячеистая топология широко применяется уже десятки лет, во-первых, военными, во-вторых, крупным бизнесом. Она подразумевает сложное проектирование с учётом всех возможных условий и нередко сопряжена с технологиями радио, т.к. радио незаменимый помощник в организации связи в полевых условиях.

Модель передачи данных по сети

В детстве, смотря телевизор, многие задавались вопросом о магии, которая позволяет по тонкому коаксиальному кабелю передавать звук и картинку. Теперь вопросов стало еще больше, потому что вся мировая паутина каким-то образом передается без проводов прямиком в маленькую коробочку, именуемую смартфоном.

Всем знакомо понятие IP-адреса логического адреса абонента для маршрутизации его входящей и исходящей информации по сети. Не вдаваясь в технические подробности стека TCP/IP, где IP это вовсе легко запоминающийся Internet Protocol, нужно различать два основных вида IP-адресов:

1. IPv4 четырехбайтные адреса с записью в десятичной системе счисления и разделением байтов через точку в виде 192.168.1.10. IPv4 привычен для глаза и прост в восприятии, однако имеет малое адресное пространство примерно в четыре миллиарда вариаций. Меньше, чем население Земли: выдать каждому человеку по уникальному адресу не получится, не говоря уже про интернет вещей.

2. IPv6 шестнадцатибайтные адреса, записываемые в шестнадцатеричной системе счисления с разделением каждых двух байтов двоеточиями. Выглядит примерно так: fe80:2a30:6b30:c26d:3d39:3ce4:218:6376. Сложноват для восприятия и запоминания, однако имеет безграничное для человеческого воображения количество возможных адресов. Адресного пространства IPv6 хватит на много планет с учетом, что у каждого жителя будет по три кофеварки, имеющих уникальный адрес.

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

Чтобы приблизиться к представлению передачи цифровой, т.е. бинарной информации, состоящей из битов нулей и единиц, понадобится базовое понимание модели сетевого взаимодействия Open Systems Interconnection (или просто: OSI). Подробную справку при желании вы найдете в два клика, поэтому не стану переписывать учебник. Знайте: от электрического импульса в проводе до отображения картинки в браузере задействуется несколько логических уровней, и чем ниже уровень, тем меньше энергозатрат на стороне клиента. Пока сигнал идет по проводу, компьютер с ним никак не связан. Затем сигнал достигает сетевой карты устройства и начинается его низкоуровневая обработка силами самой сетевой платы. После этого информация передается непосредственно в операционную систему, и ее логическая обработка ложится на основные ресурсы компьютера. Высшая точка этой цепи клиентское приложение, например, браузер, и картинка в нем. Итого электрический импульс преобразуется в биты, затем эти биты образуют пакеты, отправляются в браузер и собираются в картинку на мониторе пользователя.

Классическая сеть

Почти любая современная телекоммуникационная сеть подразумевает наличие администратора пользователя, наделенного полномочиями и ответственностью. Админ налаживает связность, подключает новых абонентов, а также в праве цензурировать и всячески ограничивать подконтрольный ему сегмент сети. Это правило применимо как для локальных сетей, так и для глобальной сети интернет. В случае с интернетом мы прибегаем к услугам провайдеров, которые подключают нас к своей сети. В свою очередь, малые провайдеры пользуются услугами магистральных провайдеров; тех, кто объединяет своим кабелем страны и континенты. Чем серьезнее уровень сети, тем большее количество человек ее обслуживает. Помимо физического соединения разных компьютеров проводами, проводится колоссальная работа по логической настройке сети маршрутизации. Благодаря ей наши запросы на другой континент улетают за несколько десятков миллисекунд, потому что каждый вышестоящий маршрутизатор знает кому необходимо передать пакет дальше. Без настройки маршрутизации и человека, который её настроит, не обойдется даже крошечная локальная сеть на несколько кабинетов!

В современной парадигме глобальной сети прижилась централизованность, т.е. подконтрольность критической инфраструктуры определенному кругу лиц: государственным и коммерческим структурам. Одни в праве устанавливать цены, другие вовсе лишить нас связи с миром. И все они имеют власть мониторить и регулировать активность пользователей. Кажется, что от этого никуда не деться.

Yggdrasil

Бывало ли, что ваш домашний роутер выходил из строя, и все домочадцы оставались без выхода в сеть? Представьте, как было бы хорошо, если роутер не был бутылочным горлышком, и в случае его отказа все участники домашней сети могли выйти в интернет через умный телевизор, соседские беспроводные сети и в конце концов через ваш смартфон, и всё это без какой-либо дополнительной конфигурации после поломки роутера!

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

Для организации локальной сети на предприятии, настройки VPN для удаленных сотрудников, даже для малой сети из трёх компьютеров требуется тот или иной уровень грамотности и соответствующий специалист. А что, если существует решение, допускающее нулевую конфигурацию на стороне обычного пользователя, при этом позволяющее объединять или разделять локальные сети с полным сохранением маршрутизации (с физически доступными узлами)?

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

Адресация в Yggdrasil

Yggdrasil использует адресацию IPv6 с маской сети 200::/7. Адреса из этой подсети не применяются в интернете, поэтому коллизий не возникает. Каждый пользователь также имеет свою подсеть 300::/64, что позволяет назначать на сетевые интерфейсы более короткие адреса, выдавать адреса из этой подсети локальным пользователям дома, а также использовать их для хостинга нескольких ресурсов на разных адресах (например, сайты, все из которых используют порт 80). Короткий адрес автоматически маршрутизируется на полный адрес из подсети 200::/7, первые 64 бита которого совпадают. Например, адрес [324:9de3:fea4:f6ac::ace] маршрутизируется на узел с полным адресом [224:9de3:fea4:f6ac:6d7c:68f5:6c8e:f9a9]. Адреса из дополнительной подсети пользователя легко распознать по первой тройке в адресе, т.к. в полных адресах всегда используется двойка.

Адрес пользователя генерируются при первом запуске программного клиента сети. Чтобы исключить возможность присвоения чужого адреса, адрес IPv6 в Yggdrasil непосредственно образуется от ключа шифрования. Соединение не будет установлено, если ключ шифрования не соответствует IPv6-адресу. Т.к. подобрать или своровать чужой ключ весьма нетривиальная задача, можно заключить, что адреса в Yggdrasil устойчивы перед злонамеренными попытками помех их использования. Подробнее про криптографическое образование адресов IPv6 в Yggdrasil читайте в статье: http://personeltest.ru/aways/habr.com/ru/post/546034/.

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

Построение общего дерева координат в Yggdrasil

В традиционных сетях, где происходит осмысленное распределение выделенных адресов, логику маршрутизации настраивают многочисленные администраторы, а как работать сети без админа, когда в ней тысячи узлов по всему миру? Название Иггдрасиль происходит от одноимённого дерева в Скандинавской мифологии, которое объединяет миры. Имя для сети подобрано не случайно, т.к. маршрутизация в ней имеет древовидную структуру.

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

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

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

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

Опыт и теория использования Yggdrasil в продакшене

Первый релиз на GitHub датируется 17 февраля 2018 года. Однако по сей день Yggdrasil позиционируется, как сырой продукт, бэта, и не рекомендуется к использованию в серьезных проектах.

Многие угрозы нестабильности сети актуальны только при подключении к глобальному сегменту сети, где многое из происходящего от нас никак не зависит. В случае бизнес-решений, есть случаи успешного подключения через Yggdrasil удаленных сотрудников, например, бухгалтеров. Такие сети организуются изолированно, поэтому не подвержены сетевому шторму: на сервере, подконтрольном штатному сисадмину, организуется публичный пир, к которому в оверлейном режиме (т.е. через интернет) подключаются все сотрудники. Получается легко масштабируемая сеть вроде VPN с внутренним IPv6. Также Yggdrasil может использоваться для проброса локальных сетей IPv4 соответствующие параметры имеются в файле конфигурации.

В Yggdrasil есть встроенные средства ограничения доступа к сетевому интерфейсу операционной системы с допуском только доверенного списка ключей, которые указываются в конфигурационном файле. Таким образом подключиться к TUN-интерфейсу машины смогут только вручную добавленные пользователи. Недоверенные участники сети не смогут даже пинговать такой IPv6-Yggdrasil, при этом транзитный трафик на узле никак не пострадает.

Также с версии 0.3.15 Yggdrasil позволяет не просто блокировать или разрешать какие-то адреса, а указывать ключи шифрования и подписи при настройке подключения к публичному пиру. В случае централизованного подключения сотрудников организации к некоему публичному пиру, этот параметр как никогда уместен, т.к. за счет прямой манипуляции с ключами страхует от теоретической атаки в виде спуфинга адреса IPv6.

Технические замечания

Yggdrasil работает на весьма высоком сетевом уровне (L3), образуя свои туннели поверх обычного TCP/IP. Вся обработка внутрисетевого трафика требует вычислительных ресурсов операционной системы. В первую очередь это связано с криптографией: прежде, чем передать информацию на виртуальный сетевой интерфейс, который будет воспринят операционной системой наравне с обычным трафиком, в службе Yggdrasil производятся криптографические операции. При большом проходящем трафике на слабом железе могут возникать тормоза.

Для работы в локальной сети, т.е. автоматического обнаружения пиров, необходимо включить IPv6 на реальных сетевых интерфейсах компьютера. В случае систем без поддержки IPv6 (например, Windows XP), подключение к Yggdrasil возможно только посредством указания IPv4-адреса публичного пира (адрес может быть локальный).

Сеть масштабируется автоматически: если один из пользователей изолированного сегмента сети пропишет у себя общедоступный публичный пир, весь сегмент окажется частью глобальной сети Yggdrasil.

Начало использования

Подробные инструкции, список публичных пиров, а также список известных внутрисетевых сервисов доступен на официальной странице проекта: https://yggdrasil-network.github.io/. Клиент сети является кроссплатформенным. На момент публикации поддерживаются все распространенные ОС: Windows, Linux, MacOS, IOS и Android.

Yggdrasil будет интересен как сетевым энтузиастам и администраторам, так и подрастающему поколению, например, для игры в Minecraft в псевдо локальной сети (как замена Hamachi).

Постскриптум

В начале 2010-ых годов слово "криптовалюта" было почти неизвестно: где-то звучало на уровне фантастики, а где-то, как бред. Лишь небольшая группа людей понимала о чем речь и еще меньшая вникала в суть и начинала активно знакомиться с биткойном. Теперь всяческих криптовалют навалом и поезд хайпа уже тронулся, а запрыгнуть в последний вагон занятие непростое и недешевое. Однако услышав про меш-сети вы с приятным удовлетворением поймете, что эта электричка без вас не уехала.

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

Зачем это нужно и кому?

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

Теперь рассмотрим ситуацию когда у вас нет инфраструктуры, а нужно гонять большие объемы данных "на лету". В первую очередь, это требуется военным, т.к. современный солдат обвешан колоссальным количеством сенсоров и включен в единую автоматизированную систему управления боем BMS. Здесь он должен быть всегда онлайн, всегда виден своему командованию и иметь возможность взаимодействовать с другими такими же как он, а в перспективе даже с роботизированными платформами на земле, воде, в воздухе (в космосе - ?), а это и передача видео, файлов, телеметрии, карт и всего другого, вне зависимости от доступной инфраструктуры. Такой себе закрытый Интернет. Вот этот сегмент как раз и закрывают такие радиостанции.

Другим потенциальным "клиентом" таких систем являются спасатели. По информации из СМИ, американские компании TrellisWare Technologies и Persisten Systems активно продвигают свои MANET радиостанций в Федеральное агентство по чрезвычайным ситуациям FEMA для решения задач эффективного управления командами спасателей, поиска людей на больших площадях и т.д. Вполне логичное решение, с учетом того, сколько ущерба инфраструктуре США приносят природные катаклизмы, а время самый дорогой ресурс для спасателя.

Архитектура

Внутренняя архитектура таких девайсов ничем не уступает самым современным смартфонам, а в некоторых аспектах, таких как например диапазон рабочих частот или требования по надежности, значительно превосходит их. Единственное в чем они уступают смартфонам - это внешний вид, в стиле "защищенный кирпич", что обусловлено требованиями стандартов MIL-STD и IEC, предъявляемых к таким устройствам. Но это ерунда - главное, чтобы работало!

Следующим важным фактором является богатая периферия. И это неудивительно, ведь это не рации "walkie-talkie" с одной кнопкой для голоса. Все данные передаются как IP пакеты, для того чтобы максимально быстро и просто подключить клиентское оборудование, в том числе кнопки РТТ для голосовых сеансов. Следовательно, нужно иметь максимум из распространенных интерфейсов и работать как маршрутизатор. Чем по сути эти девайсы и являются.

Любопытно отметить, что практически все производители подобных систем, отказались от экранов. Поскольку подключаемое клиентское оборудование - смартфоны, планшеты, компьютеры - уже имеют экраны, то зачем дублировать функционал. К тому же, вставить нормальный экран в столь компактное решение, а тем более защитить его от механических воздействий и климата (-40...+55 С) по MIL-STD, очень сложно и дорого.

Наконец, батарея. Здесь все упирается в понятие SWaP, т.е. размер, вес и потребление устройства. Как вы понимаете, эти радиостанции практически постоянно в эфире, причем не столько как генераторы трафика от своих периферийных устройств (планшетов, смартфонов и т.д.), но в основном как ретрансляторы трафика других абонентов. И это должно длится сутками! Поэтому требования к батареям предъявляются чрезвычайно высокие. Это не только ёмкость, но и работа при глубоком минусе, до -40 градусов по Цельсию. В итоге, дешевыми такие батарейки точно не назовешь.

Радиочасть

Здесь можно выразиться одной фразой - "чем шире, тем лучше". С повсеместным распространением интегральных SDR трансиверов с цифровой обработкой сигналов в этом сегменте произошла самая настоящая революция. Большие скорости передачи требуют больше полосы, а традиционные радиочастотные цепи, не могут обеспечить более широких полос частот и схем цифровой модуляции без значительного потребления энергии и увеличения в размере и весе. Таким образом, революцией в дизайне MANET радиостанций с малым форм-фактором стали встроенные SDR приемопередатчики, уменьшающие размер и потребление несколькими способами.

Во-первых, радиочастотные и аналоговые устройства могут быть переведены в цифровую область - например, радиочастотные фильтры могут стать цифровыми фильтрами. Цифровые реализации этих блоков более эффективны и лучше программируемы, чем их РЧ аналоги. Во-вторых, цепи на дискретных элементах часто представляют собой гетеродинные архитектуры, которые требуют нескольких уровней преобразования частоты, фильтрации, усиления и цифровой обработки. Интегрированные трансиверы могут использовать архитектуру с нулевой промежуточной частотой (ZIF), которая резко сокращает количество требуемых компонентов в сигнальной цепи, в частности, требуемых этапов фильтрации и усиления. Удаление этих ступеней уменьшает как размер, так и потребляемую мощность [1].

К слову, широкополосные SDR трансиверы требуют соответствующих усилителей. На помощь пришел нитрид галлия (GaN). Транзисторы на этом соединении способны обеспечить необходимую широкополосность и мощность. Такие компании, как Qorvo, Ampleon, Cree в полной мере отвечают всем самым современным требованиям производителей усилителей для SDR, в то время когда основные игроки этого рынка стараются уходить на вверх на гигагерцы. Хотя в последнее время много внимания уделяется когнитивному радио и переиспользованию спектра внизу, на УКВ, перекрывая весь диапазон частот в одном устройстве.

Софт

Поскольку классическая радиотехника закончилась (см. выше), теперь все упирается в софт, а точнее в "форму волны" - waveform. Вот тут и развернулась основная борьба между производителями таких девайсов.

Большинство из них используют технологию MIMO и активно наращивают количество апертур, что в связке с цифровым диаграммообразованием открывает невероятные возможности. Помните 5G? Как там собираются достигать гигабитных скоростей и большой емкости сети? Точно таким же образом - цифровой диаграммой и обработкой сигналов, когда на каждого абонента формируется отдельный луч и с адаптивной модуляцией. Примерно такая же логика и тут.

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

Другим любопытным трендом является управление сетями MANET через SDN. Как и в случае в 5G и MIMO, основным преимуществом SDN для таких радиостанций становится гибкий механизм управления параметрами сети. Причем не только физическим уровнем (адаптивная модуляция, когнитивное радио), но и канальным, и сетевым. Это особенно актуально в случае больших сетей с множеством абонентов, где параметры каналов, требования по задержке, BER, PER, полосе могут меняться динамически от абонента к абоненту. А добавьте сюда аспект безопасности, распределение доступа, управление спектром и т.д. Как этим всем управлять? В данном случае SDN подходит как нельзя лучше. Однако, и тут есть масса чисто научных проблем и организации типа DARPA туда копают очень активно.

Итого, все вышеозначенное реализуется в софте на ПЛИС/DSP и взаимодействует с SDR трансиверами и ОС (например, Linux). Таким образом, у каждого вендора есть свой уникальный waveform - комбинация модуляции, кодирования, фильтрации, управления диаграммой - реализованная как специализированная прошивка для радиостанции.

Перспективы

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

e

Резюме: персональный, децентрализованный Интернет все больше набирает популярности). А какие перспективы у MANET радиостанций видите вы?

[1] - https://militaryembedded.com/comms/rf-and-microwave/next-generation-military-communications-challenges