Rps video open success что это значит
Перейти к содержимому

Rps video open success что это значит

  • автор:

Rps video open success что это значит

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

Ваша корзина пуста

Всего: 0
Заказать
  • ЧаВо (FAQ)
  • Эволюция облака: внедрение DSS. Удаленное видеонаблюдение через интернет

Эволюция облака: внедрение DSS. Удаленное видеонаблюдение через интернет
14 декабря 2018, 09:13
52 просмотра

Для удаленного просмотра видео, например, с видеорегистратора у вас дома, достаточно подключить это устройство к интернету. Взять полученный от провайдера IP-адрес. И подключаться к устройству с любой точки планеты по IP-адресу. На первый взгляд, удаленное видеонаблюдение через интернет организовать своими руками не сложно.

Удаленное видеонаблюдение через интернет/Удаленное видеонаблюдение через интернет

Стоп. Но такие идеальные условия давно в прошлом. Провайдер больше не выдает публичные IP-адреса. А если и выдает, то за отдельные деньги. И с каждым годом цена за аренду статического адреса растет. Сегодня удаленное видеонаблюдение реализуется с помощью «облачных технологий». О том, как подключить камеру и регистратор через облако к ПК и к мобильному телефону. О технологии DSS.

Почему так произошло? Основной протокол интернета IPv4 имеет в своем распоряжении 4,22 миллиарда адресов и случилось то что в 2011 году эти адреса закончились. Но количество пользователей растет, раньше в интернет мог выйти только компьютер. А сейчас? Для выхода из сложившейся ситуации основная часть пользователей интернета были подключены на так называемые NAT-сервера. Этот сервер имеет снаружи нормальный публичный адрес, к нему подключены абоненты, которые имеют уже не «белый», а «серый» IP-адреса. Абонент свободно может получить доступ к ресурсам интернета имея 2серый»-IP, но вот получить доступ со стороны сети интернет к абоненту уже проблема. Адрес абонента мы уже не видим.

Ведь есть IPv6 который избавляет от этой проблемы — нехватка адресов. Но в повседневной жизни этот протокол не прижился. Он существует, но многими провайдерами не поддерживается и на данный момент не популярен. Кто нибудь знает IPv6 адрес своего компьютера? Думаю, нет. Мы можем назвать что-то типа 192.168.1.2 который благозвучней его IPv6 версии: 2002:c0a8:0102:0:0:0:0:0. [а еще IPv6 может помочь обойти запреты Роскомнадзора, от того мы его в ближайшее время не увидим]. И заметьте мы назвали адрес в локальной сети, это означает что выше нас находится какое-то устройство (например, WiFi маршрутизатор) которое раздает интернет. И этих устройств «выше2 в реальной жизни очень много. От того просто так нельзя по IP-адресу подключится к вашему видеорегистратору дома. И это только малый пример, в жизни может быть все еще сложнее.

Для обхода данного ограничения (невозможности прямого соединения) и упрощения процесса подключения была разработана целая сеть, состоявшая из серверов — так называемый «облачный сервис». Данные сервера имеют множество механизмов для подключения вашего оборудования к вам (вашему смартфону, пример). Вам не нужно думать, как можно получить удаленный доступ к вашему оборудованию. За вас уже все будет сделано, лишь необходим идентификатор сервиса (CloudID), а также учетная запись от оборудования — логин/пароль.

Что из себя представляет «облако»?

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

Удаленный доступ к видеонаблюдению через интернет

Как работает удаленное видеонаблюдение через интернет

Начнем с описания серверов:

WEB — это сервер отвечающий за обычный WEB-интерфейс системы, то есть доступ к своему аккаунту как к обычному сайту.

P2P (Peer-to-peer) — сервер установки прямого соединения. Используется в первую очередь для попытки прямого соединения. [Самая маленькая нагрузка на сервера сервиса]

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

RPS (Reliable Proxy Service) — сервис проксирования. Применяется в тяжелых условиях, когда нет возможности связаться с сервером перенаправления трафика. В этом случае используется цепочка серверов которые пропускают трафик через себя.

Для просмотра будет доступен только второй поток.

Давайте разберемся в работе этой системы на живом примере.

P2P сервер

Первый пример: Вы со смартфоном на руках, во дворе дома установлена камера Polyvision. Камера подключена к маршрутизатору. Маршрутизатор имеет статический или «белый» интернет-адрес. Вами были прокинуты порты «мультимедиа» и RTSP наружу — в глобальную сеть. Или это произошло автоматически благодаря технологии UPnP (Universal Plug and Play) — автоматическая настройка сети. Такие условия позволяют подключаться напрямую к камере, минуя дополнительные сервисы. В таком случае технология P2P даст команду на прямое соединение, чтобы осуществить удаленный просмотр камер видеонаблюдения через интернет. Участие облачного сервиса в этом случае минимальны, они лишь сводятся к тому, чтобы установить соединение.

Удаленный просмотр камер видеонаблюдения через интернет

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

Новая технология — DSS

Развитие технологий дало еще один вид систем для данной задачи. DSS (Darwin Streaming Server) — сервер вещания разработанный компанией Apple.

Поддержка облачной технологии dss

Применение DSS позволяет заменить сервер перенаправления на сервер по своим свойствам и отказоустойчивости похожий на сервера YouTube. В этом случае поток кэшируется (накапливается на стороне сервера), что минимизирует задержки и благодаря автоматической подстройке потока качество получаемой картинки с источника будет высокой. Технология дает выигрыш даже при прямом соединении посредством сети интернет, но с неустойчивой связью. Данная технология выводит облачный сервис на новый уровень, потому мы назвали ее — «Облако 2.0».

Задействуем DSS

Для включения поддержки DSS в IP-устройствах Polyvision необходимо обновить прошивку. На сайте нашей компании в карточке товара вы найдете прошивку и инструкцию по обновлению. После обновления технология подключения станет доступна и будет приоритетна при удаленном подключении через облачный сервис. Программное обеспечение для мобильных устройств на базе Android и iOS уже поддерживает DSS, не забудьте обновиться.

Как видите, удаленное видеонаблюдение через интернет устроено просто. Устройства безопасности от нашей компании — Polyvision, поддерживают множество технологий, которые постоянно развиваются.

Форум по системам видеонаблюдения и безопасности.

Форум по системам видеонаблюдения, безопасности, пожарным и охранным сигнализациям, контролю доступа.

SD в HD при просмотре видео с камер из приложения XMEye

Все вопросы по IP камерам, IP серверам и по программному обеспечению для IP видеонаблюдения.
12 сообщений • Страница 1 из 1
Mr.Zhur Новичок Сообщения: 11 Зарегистрирован: 05 июл 2019, 19:53

SD в HD при просмотре видео с камер из приложения XMEye

Сообщение Mr.Zhur » 05 июл 2019, 20:25

Перестал работать режим переключения из SD в HD при просмотре видео с камер из приложения XMEye. При переключении ничего не меняется, режим SD всё время. Подскажите, пожалуйста, как с этим бороться?

kROOT Специалист Сообщения: 13356 Зарегистрирован: 02 сен 2013, 14:25 Откуда: youcam.pro Контактная информация:

Re: SD в HD при просмотре видео с камер из приложения XMEye

Сообщение kROOT » 05 июл 2019, 22:47

Это от облака зависит, возможно от его загрузки. Сейчас проверил пару камер в разных местах, у меня переключается на ХД. А например с компа в CMS через ИД облака камеры всегда показываются онлайн только доппоток.

Mr.Zhur Новичок Сообщения: 11 Зарегистрирован: 05 июл 2019, 19:53

Re: SD в HD при просмотре видео с камер из приложения XMEye

Сообщение Mr.Zhur » 06 июл 2019, 11:57

kROOT писал(а): Это от облака зависит, возможно от его загрузки. Сейчас проверил пару камер в разных местах, у меня переключается на ХД. А например с компа в CMS через ИД облака камеры всегда показываются онлайн только доппоток.

У меня обычные IP камеры, как и у всех с поддержкой P2Pby cloud xmeye.net или приложение XMEye. В один момент переключение перестало работать и теперь ни разу не включалось.

kROOT Специалист Сообщения: 13356 Зарегистрирован: 02 сен 2013, 14:25 Откуда: youcam.pro Контактная информация:

Re: SD в HD при просмотре видео с камер из приложения XMEye

Сообщение kROOT » 06 июл 2019, 13:10

может приложение обновить, а за одно и прошивки на камерах, последние годы много что поменялось.
installer Новичок Сообщения: 41 Зарегистрирован: 13 июн 2018, 10:21 Откуда: Беларусь

Re: SD в HD при просмотре видео с камер из приложения XMEye

Сообщение installer » 06 июл 2019, 20:23

Тоже самое было сегодня днем SD и HD картинка была одинаковой,а сейчас SD в HD переключает.
Mr.Zhur Новичок Сообщения: 11 Зарегистрирован: 05 июл 2019, 19:53

Re: SD в HD при просмотре видео с камер из приложения XMEye

Сообщение Mr.Zhur » 06 июл 2019, 21:03

kROOT писал(а): может приложение обновить, а за одно и прошивки на камерах, последние годы много что поменялось.

Эх, пытался прошить одну камеру. В итоге она теперь не работает, хотя всё делал по инструкции. К чёрту всё это.

kROOT Специалист Сообщения: 13356 Зарегистрирован: 02 сен 2013, 14:25 Откуда: youcam.pro Контактная информация:

Re: SD в HD при просмотре видео с камер из приложения XMEye

Сообщение kROOT » 07 июл 2019, 00:55

Значит путь в раздел по восстановлению.
AlienP666 Специалист Сообщения: 3331 Зарегистрирован: 01 апр 2016, 15:08

Re: SD в HD при просмотре видео с камер из приложения XMEye

Сообщение AlienP666 » 08 июл 2019, 06:59

Mr.Zhur писал(а): Перестал работать режим переключения из SD в HD при просмотре видео с камер из приложения XMEye. При переключении ничего не меняется, режим SD всё время. Подскажите, пожалуйста, как с этим бороться?

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

Mr.Zhur Новичок Сообщения: 11 Зарегистрирован: 05 июл 2019, 19:53

Re: SD в HD при просмотре видео с камер из приложения XMEye

Сообщение Mr.Zhur » 11 июл 2019, 21:21

AlienP666 писал(а):

Mr.Zhur писал(а): Перестал работать режим переключения из SD в HD при просмотре видео с камер из приложения XMEye. При переключении ничего не меняется, режим SD всё время. Подскажите, пожалуйста, как с этим бороться?

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

Спасибо, как раз занялся этим. Пока что неудачно прошил одну камеру. Скоро заберу её и буду ломать голову по восстановлению прошивки (раньше этим не занимался).

AlienP666 Специалист Сообщения: 3331 Зарегистрирован: 01 апр 2016, 15:08

Re: SD в HD при просмотре видео с камер из приложения XMEye

Сообщение AlienP666 » 12 июл 2019, 06:20

Mr.Zhur Новичок Сообщения: 11 Зарегистрирован: 05 июл 2019, 19:53

Re: SD в HD при просмотре видео с камер из приложения XMEye

Сообщение Mr.Zhur » 14 июл 2019, 15:07

AlienP666 писал(а):

Mr.Zhur писал(а): Перестал работать режим переключения из SD в HD при просмотре видео с камер из приложения XMEye. При переключении ничего не меняется, режим SD всё время. Подскажите, пожалуйста, как с этим бороться?

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

Странно, все камеры, которые приходят с Китая, с прошивками 2014-2018 годов. По идее мало у каких будут новейшие прошивки. Почему у всех такой проблемы с HD и SD нет, сразу обновляют прошивку?
В CMS есть функция автоматической прошивки, не видел ни разу чтобы камера сама нашла нужную прошивку и прошилась.

kROOT Специалист Сообщения: 13356 Зарегистрирован: 02 сен 2013, 14:25 Откуда: youcam.pro Контактная информация:

Тонкая настройка балансировки нагрузки

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

Маленький минутрый пик в 84 RPS «пятисоток» — это пять тысяч ошибок, которые получили реальные пользователи. Это много и это очень важно. Необходимо искать причины, проводить работу над ошибками и стараться впредь не допускать подобных ситуаций.

Николай Сивко (NikolaySivko) в своем докладе на RootConf 2018 рассказал о тонких и пока не очень популярных аспектах балансировки нагрузки:

  • когда повторять запрос (retries);
  • как выбрать значения для таймаутов;
  • как не убить нижележащие серверы в момент аварии/перегрузки;
  • нужны ли health checks;
  • как обрабатывать «мерцающие» проблемы.

О спикере: Николай Сивко сооснователь okmeter.io. Работал системным администратором и руководителем группы администраторов. Руководил эксплуатацией в hh.ru. Основал сервис мониторинга okmeter.io. В рамках этого доклада опыт разработки мониторинга является основным источником кейсов.

Про что будем говорить?

В этой статье речь пойдет про веб-проекты. Ниже пример живого продакшена: на графике показаны запросы в секунду на некий веб-сервис.

Когда я рассказываю про балансировку, многие воспринимают это, как «нам надо распределить нагрузку между серверами — чем точнее, тем лучше».

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

Маленький пик на графике — это «пятисотки», которые сервер возвращал в течение минуты, а потом перестал. С точки зрения бизнеса, например интернет-магазина, этот маленький пик в 84 RPS «пятисоток» — это 5040 ошибок реальным пользователям. Одни что-то не нашли в вашем каталоге, другие не смогли положить товар в корзину. И это очень важно. Пусть на графике этот пик выглядит не очень масштабным, но в реальных пользователях это много.

Как правило такие пики есть у всех, и админы не всегда на них реагируют. Очень часто, когда бизнес спрашивает, что это было, ему отвечают:

  • «Это кратковременный всплеск!»
  • «Это просто релиз катился».
  • «Сервер умер, но уже все в порядке».
  • «Вася переключал сеть одного из бэкендов».

«Тонкая» настройка

Я назвал доклад «Тонкаянастройка» (англ. Fine tuning), потому что я подумал, что не все добираются до этой задачи, а стоило бы. Почему не добираются?

  • До этой задачи не все добираются, потому что, когда все работает, она не видна. Это очень важно при проблемах. Факапы случаются не каждый день, а такая маленькая проблемка требует очень серьезных усилий для того, чтобы ее разрешить.
  • Нужно много думать. Очень часто админ — тот человек, который настраивает балансировку — не в состоянии самостоятельно решить эту проблемы. Дальше мы посмотрим, почему.
  • Цепляет нижележащие уровни. Эта задача очень тесно связана с разработкой, с принятием решений, которые затрагивают ваш продукт и ваших пользователей.
  • Мир меняется, становится более динамичным, появляется много релизов. Говорят, что теперь правильно релизиться 100 раз в день, а релиз — это будущий факап с вероятностью 50 на 50 (прямо как вероятность встретить динозавра)
  • С точки зрения технологий тоже все очень динамично. Появился Kubernetes и другие оркестраторы. Нет старого доброго deployment, когда один бэкенд на каком-то IP выключается, накатывается обновление, и сервис поднимается. Сейчас в процессе rollout в k8s полностью меняется список IP апстримов.
  • Микросервисы: теперь все общаются по сети, а значит, нужно делать это надежно. Балансировка играет немаловажную роль.

Тестовый стенд

Начнем с простых очевидных кейсов. Для наглядности я буду использовать тестовый стенд. Это Golang-приложение, которое отдает http-200, или его можно переключить в режим «отдавай http-503».

Запускаем 3 инстанса:

  • 127.0.0.1:20001
  • 127.0.0.1:20002
  • 127.0.0.1:20003

Nginx из коробки:

upstream backends < server 127.0.0.1:20001; server 127.0.0.1:20002; server 127.0.0.1:20003; >server < listen 127.0.0.1:30000; location / < proxy_pass http://backends; >> 

Примитивный сценарий

В какой-то момент включаем один из бэкендов в режим отдавать 503, и получаем ровно треть ошибок.

Понятно, что из коробки ничего не работает: nginx из коробки не делает retry, если получили с сервера любой ответ.

Nginx default: proxy_next_upstream error timeout; 

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

Соответственно, нам нужны retries — повторные попытки, и мы начинаем о них говорить.

Retries

Нужно найти компромисс между:

  • Пользовательский запрос — святое, расшибись, но ответь. Мы хотим любой ценой ответить пользователю, пользователь — самое важное.
  • Лучше ответить ошибкой, чем перегруз серверов.
  • Целостность данных (при неидемпотентных запросах), то есть нельзя повторять определенные типы запросов.

Я разделил неудачные попытки на 3 категории:

1. Transport error
Для HTTP транспортом являются TCP, и, как правило, здесь мы говорим об ошибках установки соединения и о таймаутах установки соединения. В своем докладе я буду упоминать 3 распространенных балансировщика (про Envoy поговорим чуть дальше):

  • nginx: errors + timeout (proxy_connect_timeout);
  • HAProxy: timeout connect;
  • Envoy: connect-failure + refused-stream.

2. Request timeout:
Допустим, что мы отправили запрос на сервер, успешно с ним соединились, но ответ нам не приходит, мы его подождали и понимаем, что дальше ждать уже нет никакого смысла. Это называется request timeout:

  • У nginx есть: timeout (prox_send_timeout* + proxy_read_timeout*);
  • У HAProxyOOPS 🙁 — его в принципе нет. Многие не знают, что HAProxy, если успешно установил соединение, никогда не будет пробовать повторно послать запрос.
  • Envoy все умеет: timeout || per_try_timeout.

Таймауты

Поговорим теперь подробно про таймауты, мне кажется, что стоит уделить этому внимание. Дальше не будет rocket science — это просто структурированная информация про то, что вообще бывает, и как к этому относится.

Connect timeout

Connect timeout — это время на установку соединения. Это характеристика вашей сети и вашего конкретного сервера, и не зависит от запроса. Обычно, значение по умолчанию для сonnect timeout устанавливает небольшим. Во всех прокси дефолтовое значение достаточно велико, и это неправильно — должно быть единицы, иногда десятки миллисекунд (если мы говорим о сети в пределах одного ДЦ).

Если вы хотите проблемные сервера определять чуть быстрее, чем эти единицы-десятки миллисекунд, вы можете регулировать нагрузку на бэкенд путем установки небольшого backlog на прием TCP-соединений. В таком случае вы можете, когда backlog приложения заполнится, сказать Linux, чтобы он сделал reset на переполнение backlog. Тогда вы будете иметь возможность отстрелить «плохой» перегруженный бэкенд чуть раньше, чем connect timeout:

fail fast: listen backlog + net.ipv4.tcp_abort_on_overflow
Request timeout

Request timeout — это характеристика не сети, а характеристика группы запросов (handler). Есть разные запросы — они разные по тяжести, у них внутри совершенно разная логика, им нужно обращаться к совершенно разным хранилищам.

У nginx, как такового, нет таймаута на весь запрос. У него есть:

  • proxy_send_timeout: время между двумя успешными операциями записи write();
  • proxy_read_timeout: время между двумя успешными операциями чтения read().

У Envoy все есть: timeout || per_try_timeout.

Выбираем request timeout

Теперь самое важное, на мой взгляд — какой поставить request_timeout. Мы исходим из того, сколько допустимо ждать пользователю — это некий максимум. Понятно, что пользователь не будет ждать дольше 10 с, поэтому надо ответить ему быстрее.

  • Если мы хотим обработать отказ одного единственного сервера, то таймаут должен быть меньше максимального допустимого времени ожидания: request_timeout < max.
  • Если вы хотите иметь 2 гарантированные попытки отправки запроса на два разных бэкенда, то таймаут на одну попытку равен половине этого допустимого интервала: per_try_timeout = 0.5 * max.
  • Есть также промежуточный вариант — 2 оптимистичные попытки на случай если первый бэкенд «притупил», но второй при этом ответит быстро: per_try_timeout = k * max (где k > 0.5).

С этим 1% нужно что-то сделать, потому что вся группа запросов должна, например, соответствовать SLA и укладываться в 100 мс. Очень часто в эти моменты перерабатывается приложение:

  • Появляется paging в тех местах, где невозможно за timeout отдать все данные целикомю.
  • Админка/отчеты отделяются в отдельную группу урлов для того, чтобы поднять для них timeout, а да пользовательских запросов, наоборот понизить.
  • Чиним/оптимизируем те запросы, которые не укладываются в наш таймаут.

После этого упрощается процесс мониторинга вашего сервиса с точки зрения пользователя:

  • Если есть ошибки, все плохо, это нужно чинить.
  • Если ошибок нет, мы укладываемся в нужное время ответа, значит все хорошо.

Speculative retries #нифигасечобывает

Мы убедились, что выбрать значение таймаута достаточно сложно. Как известно, чтобы что-то упростить, нужно что-то усложнить:)

Спекулятивный ретрай — повторный запрос на другой сервер, который запускается по какому-то условию, но первый запрос при этом не прерывается. Ответ мы берем от того сервера, который ответил быстрее.

Я не видел этой фичи в известных мне балансерах, но есть отличный пример с Cassandra (rapid read protection):

speculative_retry = N ms | M th percentile

Таким образом вам не надо зажимать таймаут. Вы можете оставить его на приемлемом уровне и в любом случае имеете вторую попытку получить ответ на запрос.

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

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

Согласованность таймаутов — еще один важный аспект. Про request cancellation мы еще поговорим, но в целом, если таймаут на весь пользовательский запрос 100 мс, то нет смысла ставить таймаут на запрос в базу 1 с. Есть системы, которые позволяют это делать динамически: сервис к сервису передает остаток времени, который вы будете ждать ответа на этот запрос. Это сложновато, но, если вам вдруг это понадобится, вы легко найдете, как в том же Envoy это сделать.

Что еще надо знать про retry?

Точка невозврата (V1)

Здесь V1 — это не версия 1. В авиации есть такое понятие — скорость V1. Это скорость, после достижении которой на разгоне по взлетной полосе тормозить нельзя. Надо обязательно взлетать, и потом уже принимать решение о том, что делать дальше.

Такая же точка невозврата есть в балансировщиках нагрузки: когда вы 1 байт ответа передали своему клиенту, никакие ошибки исправить уже нельзя. Если в этот момент бэкенд умирает, никакие retries не помогут. Можно только уменьшить вероятность срабатывания такого сценария, сделать graceful shutdown, то есть сказать своему приложению: «Ты сейчас новые запросы не принимаешь, но старые дорабатывай!», и только потом его гасить.

Если вы контролируете клиент, это какой-нибудь хитрый Ajax или мобильное приложение, оно может попробовать повторить запрос, и тогда вы можете выйти из этой ситуации.

Точка невозврата [Envoy]

В Envoy была такая странная фишка. Есть per_try_timeout — он ограничивает сколько может занимать каждая попытка получить ответ на запрос. Если этот таймаут срабатывал, но бэкенд уже начал отвечать клиенту, то все прерывалось, клиент получал ошибку.

Мой коллега Павел Труханов (tru_pablo) сделал патч, который уже в master Envoy и будет в 1.7. Теперь это работает так, как надо: если ответ начали передавать, сработает только global timeout.

Retries: нужно ограничивать

Retries — это хорошо, но бывают так называемые запросы-убийцы: тяжелые запросы, которые выполняют очень сложную логику, много обращается к базе данных и часто не укладывается в per_try_timeout. Если мы снова и снова посылаем retry, то этим мы убиваем нашу базу. Потому, что в большинстве (99.9%) сервисов баз данных нет request cancellation.

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

Соответственно, retries нужно ограничивать, что позволяют практически все балансировщики (HAProxy мы с данного момента рассматривать перестаем).

Nginx:

  • proxy_next_upstream_timeout (global)
  • proxt_read_timeout** в качестве per_try_timeout
  • proxy_next_upstream_tries
  • timeout (global)
  • per_try_timeout
  • num_retries
Retries: применяем [nginx]

Рассмотрим пример: задаем в nginx 2 попытки retry — соответственно, получив HTTP 503, пробуем послать запрос на сервер еще раз. Потом выключаем два бэкенда.

upstream backends < server 127.0.0.1:20001; server 127.0.0.1:20002; server 127.0.0.1:20003; >server < listen 127.0.0.1:30000; proxy_next_upstream error timeout http_503; proxy_next_upstream_tries 2; location / < proxy_pass http://backends; >> 

Ниже графики нашего тестового стенда. На верхнем графике ошибок не видно, потому что их очень мало. Если оставить только ошибки, видно, что они есть.

Что произошло?

  • proxy_next_upstream_tries = 2.
  • В случае, когда вы первую попытку делаете на «мертвый» сервер, и вторую — на другой «мертвый», то получаете HTTP-503 в случае обеих попыток на «плохие» серверы.
  • Ошибок мало, так как nginx «банит» плохой сервер. То есть если в nginx от бэкенда вернулось сколько-то ошибок, он перестает делать следующие попытки отправить на него запрос. Это регулируется переменной fail_timeout.

Что с этим делать?

Мы можем либо увеличить количество повторных попыток (но тогда возвращаемся к проблеме «запросов-убийц»), либо мы можем уменьшить вероятность попадания запроса на «мертвые» бэкенды. Это можно делать с помощью health checks.

Health checks

Я предлагаю рассматривать health checks как оптимизацию процесса выбора «живого» сервера. Это ни в коем случае не дает никаких гарантий. Соответственно, в ходе выполнения пользовательского запроса мы с большей вероятностью будем попадать только на «живые» серверы. Балансировщик регулярно обращается по определенному URL, сервер ему отвечает: «Я жив и готов».

Health checks: с точки зрения бэкенда

С точки зрения бэкенда можно сделать интересные вещи:

  • Проверить готовность к работе всех нижележащих подсистем, от которых зависит работа бэкенда: установлено нужное количество соединений с базой данных, в пуле есть свободные коннекты и т.д., и т.п.
  • На Health checks URL можно повесить свою логику, если используемый балансировщик не особо интеллектуальный (допустим, вы берете Load Balancer у хостера). Сервер может запоминать, что «за последнюю минуту я отдал столько-то ошибок — наверное, я какой-нибудь „неправильный“ сервер, и последующие 2 минуты я буду отвечать „пятисоткой“ на Health checks. Таким образом сам себя забаню!» Это иногда очень спасает, когда у вас неконтролируемый Load Balancer.
  • Как правило, интервал проверки около секунды, и нужно, чтобы Health check handler не убил ваш сервер. Он должен быть легким.
Health checks: имплементации

Как правило, здесь все у всех всё примерно одинаково:

  • Request;
  • Timeout на него;
  • Interval, через который мы делаем проверки. У навороченных прокси есть jitter, то есть некая рандомизация для того, чтобы все Health checks не приходили на бэкенд одномоментно, и не убивали его.
  • Unhealthy threshold — порог, сколько должно пройти неудачных Health checks, чтобы сервис пометить, как Unhealthy.
  • Healthy threshold — наоборот, сколько удачных попыток должно пройти, чтобы сервер вернуть в строй.
  • Дополнительная логика. Вы можете разбирать Check status + body и пр.

Отмечу особенность Envoy, у него есть Health check panic mode. Когда мы забанили, как «нездоровые», больше, чем N% хостов (допустим, 70%), он считает, что все наши Health checks врут, и все хосты на самом деле живы. В совсем плохом случае это поможет вам не нарваться на ситуацию, когда вы сами себе прострелили ногу, и забанили все серверы. Это способ еще раз подстраховаться.

Собираем все воедино

Обычно для Health checks ставят:

  • Либо nginx+;
  • Либо nginx+что-то еще:)

У нас nginx + Envoy, но, если заморочиться, можно ограничиться только Envoy.

Какой-такой Envoy?

Envoy — это модный молодежный балансировщик нагрузки, изначально разрабатывался в Lyft, написан на С++. Из коробки умеет кучу плюшек по нашей сегодняшней теме. Вы, наверное, видели его, как Service Mesh для Kubernetes. Как правило, Envoy выступает в роли data plane, то есть непосредственно балансирует трафик, а еще есть control plane, который предоставляет информацию о том, между чем надо распределять нагрузку (service discovery и пр.).

Расскажу пару слов о его плюшках.

Чтобы увеличить вероятность успешного ответа при retry при следующей попытке, можно немного поспать и подождать, пока бэкенды придут в себя. Таким образом мы обработаем короткие проблемы на базе данных. У Envoy есть backoff for retries — паузы между повторными попытками. Причем интервал задержки между попытками экспоненциально возрастает. Первый retry происходит через 0-24 ms, второй — через 0-74 ms, и далее для каждой следующей попытки интервал увеличивается, а конкретная задержка выбирается рандомно из этого интервала.

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

Circuit breaker как раз позволяет определить, что мы в таком состоянии, быстро отстрелить ошибку и дать бэкендам «отдышаться».

Circuit breaker (hystrix like libs), оригинал в блоге ebay.

Выше схема Circuit breaker от Hystrix. Hystrix — это Java-библиотека от Netflix, которая призвана реализовывать паттерны отказоустойчивости.

  • «Предохранитель» может находиться в состоянии «закрыто», когда все запросы отправляются на бэкенд и нет никаких ошибок.
  • Когда срабатывает некий fail-порог, то есть произошло сколько-то ошибок, circuit breaker переходит в состояние «Open». Он быстро возвращает ошибку клиенту, и на бэкенд запросы не попадают.
  • Раз в некоторый промежуток времени, все-таки маленькую часть запросов отправляется на бэкенд. Если срабатывает ошибка, то состояние остается «Open». Если все начинает хорошо работать и отвечать, «предохранитель» закрывается, и работа продолжается.

У вас не было retries, что-то взорвалось — пошли retries. Envoy понимает, что больше, чем N — это ненормально, и все запросы надо отстреливать ошибкой.

Circuit breaking [Envoy]

  • Cluster (upstream group) max connections
  • Cluster max pending requests
  • Cluster max requests
  • Cluster max active retries
Circuit breaker: наш опыт

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

А агенты постоянно делают попытки отправить нам данные, они не расстраиваются от того, что мы как-то не так отвечаем, и не уходят.

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

Чтобы справиться с такой проблемой мы зажимали входящий поток записи через nginx limit req. То есть мы говорим, что сейчас мы обрабатываем, допустим, 200 RPS. Когда это все приходило в нормальный режим, мы убирали ограничение, потому что в нормальной ситуации коллектор способен записывать гораздо больше, чем кризисный limit req.

Потом по некоторой причине мы перешли на свой протокол поверх TCP и потеряли плюшки проксирования HTTP (возможность использовать nginx limit req). Да и в любом случае надо было этот участок привести в порядок. Нам больше не хотелось менять limit req руками.

У нас достаточно удобный случай, потому что мы контролируем и клиента, и сервер. Поэтому мы в агенте закодии Circuit breaker, который понимал, что если он получил N ошибок подряд, ему надо поспать, и через какое-то время, причем экспоненциально возрастающее, пытаться заново. Когда все нормализуется, он все метрики доливает, так как у него есть spool на диске.

На сервере мы добавили Circuit breaker код всех обращений во все подсистемы + request cancellation (где возможно). Тем самым, если мы получили N ошибок от Cassandra, N ошибок от Elastic, от базы, от соседнего сервиса — от чего угодно, мы отдаем быстро ошибку и не выполняем дальнейшую логику. Просто отстреливаем ошибку и все — ждем, пока это нормализуется.

На графиках выше видно, что мы не получаем всплеск ошибок при проблемах (условно: серое — это «двухсотки», красное — «пятисотки»). Видно, что в момент проблем из 800 RPS на бэкенд долетело 20-30. Это позволило нашему бэкенду «отдышаться», подняться, и дальше хорошо работать.

Самые сложные ошибки

Самые сложные ошибки — это те, которые неоднозначны.

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

Намного хуже, когда один серверов начинает вести себя непредсказуемо, например, сервер на все запросы отвечает ошибками, а на Health checks — HTTP 200.

Приведу пример из жизни.

У нас есть некий Load Balancer, 3 узла, на каждом из которых приложение и под ним Cassandra. Приложения обращаются ко всем экземплярам Cassandra, и все Cassandra взаимодействуют с соседними, потому что у Cassandra двухуровневая модель координатор и data noda.

Сервер Шредингера — один из них целиком: kernel: NETDEV WATCHDOG: eth0 (ixgbe): transmit queue 3 timed out.

Там произошло следующее: в сетевом драйвере баг (в интеловских драйверах они случаются), и одна из 64 очередей передачи просто перестала отправляться. Соответственно, 1/64 всего трафика теряется. Это может происходить до reboot, это никак не лечится.

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

Cassandra: coordinator -> nodes

У Cassandra, есть те самые спекулятивные ретраи (speculative retries), и эта ситуация отрабатывается очень легко. Есть небольшое повышение latency на 99 перцентиле, но это не фатально и в целом все работает.

App -> cassandra coordinator

Из коробки ничего не работает. Когда приложение стучится в Cassandra и попадает на координатор на «мертвом» сервере, никак это не отрабатывает, получаются ошибки, рост latency и т.д.

На самом деле мы используем gocql — достаточно навороченный cassandra client. Мы просто не использовали все его возможности. Там есть HostSelectionPolicy, в который мы можем подсунуть библиотеку bitly/go-hostpool. Она использует алгоритмы Epsilon greedy для того, чтобы найти и удалить выбросы из списка.

Попытаюсь в двух словах объяснить, как работает алгоритм Epsilon-greedy.

Есть задача о многоруком бандите (multi-armed bandit): вы находитесь в комнате с игровыми автоматами, у вас есть несколько монет, и вы должны за N попыток выиграть как можно больше.

Алгоритм включает две стадии:

  1. Фаза «explore» — когда вы исследуете: 10 монеток тратите на то, чтобы определить, какой автомат лучше.
  2. Фаза «exploit» — остальные монетки опускаются в лучший автомат.

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

Промежуточный итог

Мы добавили «бронебойности» (отказоустойчивости) на уровне приложение—Cassandra и Cassandra coordinator-data. Но если наш балансировщик (nginx, Envoy — какой угодно) шлет запросы на «плохой» Application, который обращаясь к любой Cassandra будет тупить, потому что у него самого сетка нерабочая, мы в любом случае получим проблемы.

В Envoy из коробки есть Outlier detection по:

  • Consecutive http-5xx.
  • Consecutive gateway errors (502,503,504).
  • Success rate.

С другой стороны, чтобы защититься от неконтролируемого взрыва этой «умности», мы имеем max_ejection_percent. Это максимальное количество хостов, которое мы можем посчитать за outlier, в процентах от всех доступных. То есть, если мы забанили 70% хостов —это не считается, всех разбаниваем — короче, амнистия!

Это очень крутая штука отлично работает, при этом она простая и понятная — советую!

ИТОГО

Надеюсь, я убедил вас в том, что надо бороться с подобными кейсами. Я считаю, что бороться с выбросами ошибок и latency определенно стоит для того, чтобы:

  • Делать автодеплойменты, релизиться нужное количество раз в день и т.д.
  • Спать спокойно по ночам, не вскакивать лишний раз по СМС-кам, а проблемные серверы чинить в рабочее время.

Не нужно гнаться за самым навороченным балансировщиком. Для 99% проблем хватает стандартных возможностей nginx/HAProxy/Envoy. Более навороченный proxy понадобится, если вы захотите сделать все абсолютно идеально и убрать микроспайки «пятисоток».

Дело не в конкретном proxy (если это не HAProxy:)), а в том, как вы его настроили.

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

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

Больше любите смотреть доклады, чем читать статьи, заходите на YouTube-канале — там собраны все видео по эксплуатации за последние годы и список все время пополняется.

  • балансировка нагрузки
  • высокая нагрузка
  • высокая производительность
  • nginx
  • envoy
  • haproxy
  • Блог компании Конференции Олега Бунина (Онтико)
  • Блог компании okmeter.io
  • Высокая производительность
  • Системное администрирование
  • Nginx

Установка и использование Linkerd с помощью Kubernetes

Установка и использование Linkerd с помощью Kubernetes

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

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

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

Предварительные требования

  • Кластер Kubernetes 1.12+. В этом обучающем модуле будет использоваться кластер DigitalOcean Kubernetes с тремя узлами, но вы можете создать кластер с помощью другого метода.
  • Инструмент командной строки kubectl , установленный на сервере разработки и настроенный для подключения к вашему кластеру. Дополнительную информацию об установке kubectl можно найти в официальной документации.

Шаг 1 — Развертывание приложения

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

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

Вначале сохраните файл манифеста на локальном компьютере:

Мы используем команду curl для доставки файла и передаем опцию —output , чтобы указать желаемое место сохранения файла. В данном случае мы создаем файл с именем manifest.yaml .

Чтобы лучше понять, что делает этот файл, посмотрите его содержимое с помощью команды cat или откройте его в предпочитаемом редакторе:

Используйте клавишу пробел для прокрутки страниц с директивами. Вы увидите, что manifest.yaml создает пространство имен Kubernetes с именем emojivoto , где будет запускаться все связанное с этим приложением, а также пару развертываний и служб Kubernetes.

Затем примените этот манифест в своем кластере Kubernetes:

Мы снова используем команду kubectl apply с флагом -f , чтобы назначить файл, который мы хотим применить.

Эта команда выводит список всех созданных ресурсов.

Output
namespace/emojivoto created serviceaccount/emoji created serviceaccount/voting created serviceaccount/web created service/emoji-svc created service/voting-svc created service/web-svc created deployment.apps/emoji created deployment.apps/vote-bot created deployment.apps/voting created deployment.apps/web created

Теперь проверьте работу служб.

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

Когда вы увидите, что все поды находятся в состоянии Running (Работает), можете продолжать:

Output
NAME READY STATUS RESTARTS AGE emoji-566954596f-cw75b 1/1 Running 0 24s vote-bot-85c5f5699f-7dw5c 1/1 Running 0 24s voting-756995b6fc-czf8z 1/1 Running 0 24s web-7f7b69d467-2546n 1/1 Running 0 23s

Чтобы увидеть запущенное приложение в браузере, используйте встроенную функцию kubectl для переадресации локальных запросов на удаленный кластер:

Примечание. Если вы запускаете эту команду не с локального компьютера, добавьте флаг —address 0.0.0.0 , чтобы прослушивать все адреса, а не только localhost .

Здесь мы снова используем kubectl в пространствах имен emojivoto , но теперь используем подкоманду port-forward для переадресации всех локальных запросов на порту 8080 службе Kubernetes web-svc на порту 80 . Это удобный способ доступа к приложению без подходящего балансировщика нагрузки.

Откройте адрес http://localhost:8080 , и вы увидите приложение emojivoto.

Тестовое приложение Emojivoto

Нажмите CTRL + C в своем терминале. Мы запустили приложение в кластере и теперь можем установить Linkerd и посмотреть на его работу.

Шаг 2 — Установка Linkerd

Мы запустили приложение и можем переходить к установке Linkerd. Для его установки в кластер Kubernetes нам вначале потребуется интерфейс командной строки Linkerd. Мы будем использовать этот интерфейс командной строки для взаимодействия с Linkerd с вашего локального компьютера. После этого вы можете установить Linkerd в кластер.

Вначале установим интерфейс командной строки с помощью скрипта, предоставленного командой Linkerd:

Здесь мы используем curl для загрузки установочного скрипта и перенаправляем вывод в sh , где скрипт автоматически выполняется. Также можно загрузить интерфейс командной строки напрямую со страницы релизов Linkerd.

Если вы используете скрипт, он установит Linkerd в каталог ~/.linkerd2/bin . Проверьте работу интерфейса командной строки:

Команда выведет примерно следующее:

Output
Client version: stable-2.7.1 Server version: unavailable

Чтобы упростить запуск интерфейса командной строки, добавьте этот каталог в переменную $PATH :

Теперь вы можете напрямую запускать такие команды, как показанная выше:

В заключение установим Linkerd в кластер Kubernetes. Команда linkerd install используется для генерирования всех необходимых манифестов yaml для запуска Linkerd, но эти манифесты не будут использоваться для вашего кластера. Запустите эту команду для проверки ее вывода:

Вы увидите длинный список всех манифестов yaml для ресурсов, которые Linkerd требуется запустить. Чтобы применить эти манифесты на своем кластере, выполните следующую команду:

При запуске команды linkerd install будут выведены все манифесты, которые вы видели ранее. Затем | передает вывод в команду kubectl apply , которая применяет их напрямую.

После запуска этой команды kubectl apply выведет список всех созданных ресурсов.

Чтобы убедиться, что в кластере запущено все необходимое, выполните команду linkerd check :

На кластере будет проведено несколько проверок для подтверждения запуска всех необходимых компонентов:

Output
kubernetes-api -------------- √ can initialize the client √ can query the Kubernetes API [. ] control-plane-version --------------------- √ control plane is up-to-date √ control plane and cli versions match Status check results are √

В заключение запустите эту команду, чтобы открыть встроенную панель управления Linkerd в браузере (помните, что нужно использовать флаг —address 0.0.0.0 , если вы запускаете команду не с локального компьютера):

Панель управления Linkerd

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

В этой команде вы указываете, что хотите посмотреть статистику развертываний в пространстве имен linkerd . Это собственные компоненты Linkerd и, что интересно, вы можете отслеживать их с помощью Linkerd. Вы можете посмотреть такие параметры как количество запросов в секунду (RPS), процент успешных запросов, время задержки и т. д. В столбце Meshed показано, сколько подов было вставлено Linkerd:

Output
NAME MESHED SUCCESS RPS LATENCY_P50 LATENCY_P95 LATENCY_P99 TCP_CONN linkerd-controller 1/1 100.00% 0.4rps 1ms 87ms 98ms 5 linkerd-destination 1/1 100.00% 0.3rps 1ms 2ms 2ms 13 linkerd-grafana 1/1 100.00% 0.3rps 2ms 3ms 3ms 2 linkerd-identity 1/1 100.00% 0.3rps 1ms 2ms 2ms 10 linkerd-prometheus 1/1 100.00% 0.7rps 35ms 155ms 191ms 9 linkerd-proxy-injector 1/1 100.00% 0.3rps 2ms 3ms 3ms 2 linkerd-sp-validator 1/1 100.00% 0.3rps 1ms 5ms 5ms 2 linkerd-tap 1/1 100.00% 0.3rps 1ms 4ms 4ms 6 linkerd-web 1/1 100.00% 0.3rps 1ms 2ms 2ms 2

Теперь попробуйте запустить эту команду в своем пространстве имен emojivoto :

Хотя вы увидите четыре службы, никакие ранее показанные статистические данные не будут доступны для этих развертываний, а в столбце Meshed будет значение 0/1 :

Output
NAME MESHED SUCCESS RPS LATENCY_P50 LATENCY_P95 LATENCY_P99 TCP_CONN emoji 0/1 - - - - - - vote-bot 0/1 - - - - - - voting 0/1 - - - - - - web 0/1 - - - - - -

Такой вывод означает, что вы еще не вставили Linkerd в приложение. Мы сделаем это на следующем шаге.

Шаг 3 — Вставка Linkerd в приложение

Мы запустили Linkerd в нашем кластере и теперь можем вставить его в наше приложение emojivoto .

Linkerd работает через контейнер sidecar в подах Kubernetes. Это означает, что мы вставим контейнер linkerd proxy в каждый выполняемый под . Каждый запрос, отправляемый или принимаемый подами будет проходить через этот компактный прокси-контейнер, который собирает данные о параметрах (процент успешных запросов, количество запросов в секунду, время задержки и т. д.) и принудительно внедряет политики (таймауты, повторы и т. д.).

Вы можете вставить прокси-контейнер Linkerd вручную с помощью следующей команды:

В этой команде мы сначала используем kubectl get для получения всех развертываний Kubernetes в пространстве имен emojivoto , а затем указываем, что хотим получить вывод в формате yaml . Затем мы отправляем вывод в команду linkerd inject . Эта команда считывает файл yaml с запущенными манифестами и добавляет в него прокси-контейнер linkerd для каждого развертывания .

В заключение мы получаем измененный манифест и применяем его к нашему кластеру с помощью команды kubectl apply .

После выполнения этой команды вы увидите сообщение об успешной вставке всех четырех служб emojivoto ( emoji , vote-bot , voting и web ).

Если теперь вы попробуете получить статистику emojivoto , вы увидите, что все развертывания указаны в столбце Meshed, и через несколько секунд вы увидите те же параметры, которые отображались для пространства имен linkerd :

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

Output
NAME MESHED SUCCESS RPS LATENCY_P50 LATENCY_P95 LATENCY_P99 TCP_CONN emoji 1/1 100.00% 1.9rps 1ms 2ms 2ms 2 vote-bot 1/1 - - - - - - voting 1/1 85.96% 0.9rps 1ms 1ms 1ms 2 web 1/1 93.04% 1.9rps 8ms 27ms 29ms 2

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

Теперь посмотрим, как можно передать Linkerd дополнительную информацию о службах для настройки их поведения.

Шаг 4 — Определение профиля службы

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

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

Вот пример манифеста профиля службы:

example-service-profile.yaml

apiVersion: linkerd.io/v1alpha2 kind: ServiceProfile metadata: name: my-service.my-namespace.svc.cluster.local spec: routes: - name: My Route Name isRetryable: true # Define it's safe to retry this route timeout: 100ms # Define a timeout for this route condition: method: GET pathRegex: /my/route/path 

Профиль службы описывает список маршрутов и определяет поведение при запросах, соответствующих заданному условию . В этом примере мы указываем, что каждый запрос GET , отправляемый на путь /my/route/path , будет истекать по таймауту через 100 мс, и что в этом случае возможен повторный запрос.

Создадим профиль для одной из ваших служб. Возьмем в качестве примера службу voting-svc и для начала используем интерфейс командной строки Linkerd для проверки маршрутов, определенных для этой службы:

Здесь мы используем команду linkerd routes для перечисления всех маршрутов службы voting-svc в пространстве имен emojiovoto :

Output
ROUTE SERVICE SUCCESS RPS LATENCY_P50 LATENCY_P95 LATENCY_P99 [DEFAULT] voting-svc 83.05% 1.0rps 1ms 1ms 2ms

Вы увидите только один маршрут, [DEFAULT] . Здесь группируются все запросы до определения профиля службы.

Теперь откройте nano или другой предпочитаемый редактор для создания файла service-profile.yaml :

Добавьте в файл следующее определение профиля службы:

service-profile.yaml

apiVersion: linkerd.io/v1alpha2 kind: ServiceProfile metadata: name: voting-svc.emojivoto.svc.cluster.local namespace: emojivoto spec: routes: - name: VoteDoughnut isRetryable: true timeout: 100ms condition: method: POST pathRegex: /emojivoto.v1.VotingService/VoteDoughnut 

Сохраните файл и закройте редактор.

Здесь мы декларируем профиль службы voting-svc в пространстве имен emojivoto . Мы определили маршрут VoteDoughnut , который будет соответствовать любому запросу POST к /emojivoto.v1. Путь VotingService/VoteDoughnut. Если выполнение запроса, соответствующего этим критериям, займет более 100 мс, Linkerd отменит его, и клиент получит сообщение об ошибке 504 . Также мы указываем Linkerd, что в случае неудачи можно отправить повторный запрос.

Примените этот файл к своему кластеру:

Через несколько секунд снова проверьте маршруты этой службы:

Вы увидите маршрут VoteDoughnut , который мы только что задали:

Output
ROUTE SERVICE SUCCESS RPS LATENCY_P50 LATENCY_P95 LATENCY_P99 VoteDoughnut voting-svc 0.00% 0.2rps 1ms 1ms 1ms [DEFAULT] voting-svc 100.00% 0.8rps 1ms 4ms 4ms

Также вы увидите некоторые статистические показатели, такие как процент успешных запросов, количество запросов в секунду и время задержки для этого конкретного маршрута. Обратите внимание, что конечная точка VoteDoughnut целенаправленно настроена для вывода ошибки, и что она выводит процент успешных запросов 0%, в то время как для маршрута [DEFAULT] выводится значение 100%.

Итак, мы передали Linkerd немного информации о нашей службе, получили статистические данные по маршруту и внедрили политики таймаута и повтора.

Заключение

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

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

Также вы можете познакомиться с Istio, другой сервисной сетью с другим набором функций и другими особенностями.

Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *