Русский
Русский
English
Статистика
Реклама

Резервирование

Повышение надежности контроллера умного дома на Majordomo (MQTT)

27.02.2021 02:05:07 | Автор: admin

Итак, мой умный дом готов, слушается голоса, управляет климатом, зарядкой аккумулятора на даче.

Более того, умные устройства стоят теперь как на даче, так и дома, в городе. Причем из-за особенностей совместимости экосистем с Яндексом часть устройств дома (RGB ленты) управляются через сервер на Majordomo (дача).

И вот тут возникает ряд логичных вопросов:

где должен стоять сервер дома или на даче?

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

Как не грузить GSM канал до дачи передачей графиков в HTML верстке сайта?

Легко догадаться, что ответом является резервирование:

1. Серверы должны быть и там и там

2. Серверы должны уметь управлять всеми устройствами

3. Серверы должны иметь полный набор данных

Так как датчики общаются с сервером в основном через протокол MQTT, MQTT брокер так же становится точкой отказа.

Резервирование сервера

Начнем с MQTT брокера. Если не считать таких сообщений, как LWT (последняя воля устройства) и Retain (хранимых на сервере), большинство сообщений передаются одномоментно и только тем, кто в данный момент подключен к брокеру. То есть "отправил - забыл".

К счастью, в последних версиях mosquitto сервера есть режим бриджа вы просто задаете адрес второго брокера и топики, которые нужно дублировать, направления дублирования. В моем случае вполне пригодился вариант копировать все в обе стороны. Вот как это делается в raspbian/armbian добавляем в /etc/mosquito/mosquito.conf:

#connection bridge-01connection bridge-01address mqtt.mydomain.ru:1883topic # out 0topic # in 0

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

Дальше, сами серверы Majordomo. Я сделал второй сервер на базе Orange pi one plus (1Gb RAM) стоит в 2 раза дешевле Raspberry Pi4, для вспомогательного сервера - то, что надо. Но серверы должны уметь делать одно и то же, но не делать этого одновременно (в большинстве случаев это не страшно, ну поступит 2 команды на включение зарядника не страшно, но некоторые вещи лучше дважды не делать, например, не поворачивать солнечные панели по часам).

Так как для корректной работы с датчиками и исполнительными устройствами я использую MQTT, логично отслеживать работоспособность удаленного сервера через тот же MQTT. Для этого я создал отдельный класс, в котором есть 2 статуса (для отображения) и 2 времени для локального сервера и для удаленного, а также адрес активного брокера и собственный адрес сервера. Раз в 10 секунд выполняется проверка системного цикла MQTT время последнего запуска (ThisComputer.cycle_mqttRun). Это время сравнивается с текущим (time()). Если прошло больше 10 секунд паникуем, то есть понимаем, что локальный сервер не дружит с MQTT брокером и показываем это в интерфейсе. Так же сравниваем время последнего запуска MQTT цикла на удаленном сервере (приходит через MQTT). Если прошло больше 20 секунд, а локальный цикл в порядке понимаем, что удаленный сервер больше не управляет устройствами. Проверяем еще один параметр, передаваемый через MQTT имя активного брокера. Если это не локальный, то надо переключать на себя:

$val=getGlobal("ThisComputer.cycle_mqttRun");$locval=time()-$val;$this->setProperty("LocValue",$val);$this->setProperty("LocDeltaT",$locval);if($locval>10)$locstate=1;else$locstate=0;$tmp=$this->getProperty("Status");if(is_null($tmp))$tmp=10;if($tmp!=$locstate)$this->setProperty("Status",$locstate);$remval=time()-$this->getProperty("RemValue");$newstate=($remval<20)?0:1;$this->setProperty("RemStatus",$newstate);$ot = $this->object_title;$currBroker=$this->getProperty("MQTT_broker");$sA=$this->getProperty("selfAddress");if($sA!=$currBroker)$this->setProperty("isController",0);setTimeOut($ot . "_checkCycle",'callMethod("'.$ot.'.checkCycle");',10);if((!$locstate&&($newstate||($this->getProperty("LinkedRoom")=="Energoblok")))&&($sA!=$currBroker))// remote failed local good or local is good and is not local server{debMes('Switch to '.$this->getProperty("selfAddress"),0);$cnt=0;for($i=40;$i<90;$i++){if(ping('192.168.3.'.number_format($i,0)))    {getURL('http://192.168.3.'.number_format($i,0).'/cm?cmnd=MqttHost%20'.$this->getProperty("selfAddress"));debMEs('http://192.168.3.'.number_format($i,0).' is online',0);$cnt++;$this->setProperty("LocValue",time());}}if($cnt>10){$this->setProperty("MQTT_broker",$this->getProperty("selfAddress"));$this->setProperty("isController",1);}}
Вот такой виджет, пока корявенько, зато информативноВот такой виджет, пока корявенько, зато информативно

У меня Tasmota устройства (IP в диапазоне c 192.168.3.40 по 192.168.3.90), им можно передать обычным URL запросом новый адрес MQTT сервера. Вот только запросы надо посылать синхронные, а главное не забывать между ними обновлять MQTT свойство для удаленного сервера. Иначе получится замкнутый цикл начали переключаться, больше 10 секунд не сообщаем удаленному серверу, что мы живы. Тот начинает переключение на себя и тоже замирает. Не делайте так :)

Повышаем надежность самого сервера

Операционная система и БД хранятся на карте памяти. Есть карты класса А1 и даже А2, но через год постоянной нагрузки такая карта с большой вероятностью загнется. Кроме того, штатный код пишет в базу кучу ненужного, а каждое чтение/запись свойства любого объекта это обращение к БД. У меня было порядка 1200 обращений к БД в секунду.

Карту можно спасти, если базу держать в оперативной памяти. К счастью, разработчики Majordomo сделали прошивку для Raspberry сразу с опцией БД в памяти, а для прочих платформ есть скрипт для переноса БД в память (но памяти должно быть не менее 1Гб, на orange pi zero c 512Мб у меня не взлетело - база весит порядка 300Мб и столько же надо дополнительно для дампов бэкапов). Да, теперь в любой момент просто так перезагружать систему нельзя, нужно выполнить скриптик, иначе данные за последние полчаса потеряются (но база всегда бэкапится в рабочем состоянии!). Зато скорость работы БД и долговечность карты памяти просто великолепны.

Остался последний штрих снизить нагрузку на БД, убрав лишние запросы. Решение простое:

  • Обновиться до последней версии (буквально пару недель назад обновили интерфейс, убрав лишние обращения к БД и переписав на java скрипты)

  • Обращаться к локальным или глобальным свойствам только один раз и использовать переменные в памяти (смотрите на пример кода цикла проверки getProperty\setProperty там использованы только по одному разу).

Еще пример оптимизации скриптов чтобы и обращений лишних не было, и чтобы срабатывала автоматическая зависимость от переменной, например:

if((($temp2Floor=getGlobal("sTemp2Floor.value"))<'21')&&gg("remote_mqtt_updated.isController")) // if remote failed{if ($temp2Floor < '21' && !getGlobal("rConserveSW.status") && timeBetween('2:00', '8:00')) { if (!getGlobal("rDieselHome.status")) { callMethod("rDieselHome.turnOn"); }} else if ($temp2Floor > '23') { if (getGlobal("rDieselHome.status")) { callMethod("rDieselHome.turnOff"); }}}

Обратите внимание, что в первом условии есть ветка проверки, этот ли сервер управляет устройствами в настоящий момент (gg("remote_mqtt_updated.isController")). remote_mqtt_updated это объект контроля работы серверов.

Теперь у меня число обращений к БД порядка 380 в секунду, что гораздо лучше по сравнению с начальным значением в 1200.

Итог

Вот так, добавив сервер за 2500 рублей, получил полное резервирование брокера сообщений, сервера управления устройствами (логики) и можно получать графики с актуальными данными с домашнего сервера, не нагружая сервер, работающий через GSM модем.

Подробнее..

Дата-центры высшего уровня отвечаем на часто задаваемые вопросы про Tier IV

06.08.2020 12:10:31 | Автор: admin
Неделю назад мы рассказали о планах строительства нового дата-центра Tier IV и сразу получили несколько вопросов про этот уровень в классификации Uptime Institute. Из обсуждений в чатах получился полноценный FAQ. Так что сегодня развею самые живучие слухи про Tier IV и немного расскажу, какие требования Uptime Institute мы учитываем в проекте нового дата-центра.



Что значит максимально возможный уровень, придумали что-то новенькое?

Стандартам от Uptime Institute уже больше 25 лет. Столько времени существует система классификации Tier.

Сертификация дата-центров на уровни Tier проходит по нескольким программам:
  • Сертификация проектной документации (Design Documents) аудиторы проверяют пакет проектных документов по основным инженерным системам: кондиционирование, энергоснабжение. Также изучают документы по смежным системам, например, топливоснабжению.
  • Сертификация построенного ЦОД (Constructed Facility) здесь смотрят на соответствие построенного дата-центра сертифицированному проекту и проверяют инженерные системы при полной проектной нагрузке. Когда клиентского ИТ-оборудования еще нет, нагрузку имитируем тепловыми пушками.
    Этот уровень сдают только после Design.
  • Сертификация эксплуатационной устойчивости (Operational Sustainability) тут идет комплексная оценка эксплуатационных практик. Как именно это происходит, мы уже подробно рассказывали.
    Для сертификации по этой программе нужно сначала сдать Design и Facility.

Еще есть программа Management&Operations для проверки эксплуатации. Но это несертификация, а аудит дата-центра, так что подробно останавливаться не будем.

Уровень дата-центра закладывается еще на этапе концепции и проектирования. Поэтому мы начинаем готовиться к сертификации на Tier IV на этапе проектирования здания, еще до проектирования инженерных систем.

Почему мы так много говорим про стандарты Tier?

Система Tier содержит список требований к дата-центрам разных уровней. Но там нет конкретных объяснений, как это сделать, только требования к надежности инфраструктуры. Uptime Institute пишет:
стандарты Tiers приветствуют инновационные инженерные решения и признают, что все центры обработки данных непохожи друг на друга

А значит, есть несколько вариантов, как соблюсти требования.

Мы в DataLine занимаемся практической стороной: честно смотрим на лучшие европейские ЦОДы, берем лучшие практики, с осторожностью пробуем новое и применяем это в проектировании своих дата-центров. Делимся опытом, в том числе в наших Университетах.

Вот такой опыт сертификации по стандартам Uptime Institute у нас накопился:
  • 2014 год прошли аудит Management&Operations.
  • 2015 год дата-центр NORD-4 получил сертификат Design.
  • 2016 год сертифицировали NORD-4 на Facility.
  • 2018 год у NORD-4 появился сертификат Operational Sustainability.
  • 2020 год NORD-4 подтвердил сертификат Operational Sustainability.

Что дальше:
  • 2020 год совместно с Ростелеком-ЦОД начали строительство дата-центра в Остаповском проезде и его подготовку к сертификации на Tier IV.
  • 2020 год во втором полугодии планируем сдать в Uptime Institute проект NORD-5.
  • 2021 год планируем сертифицировать NORD-5 на Tier III по программе Facility.

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

В чем основное отличие уровней?

Я уже немного рассказывал про схемы резервирования, характерные для разных Tier.

Посмотрим на сравнительную таблицу в стандарте:


Вот так уровни отличаются по минимальному числу активных компонентов, поддерживающих нагрузку (их обозначают той самой буквой N):
  • Tier I используется N минимальное количество оборудования для работы ЦОД, то есть резерва нет.
  • Tier II инженерное оборудование резервируется по схеме N+1.
  • Tier III по схеме N+1 резервируется инженерное оборудование и пути дистрибуции: кабели питания, трассы, трубопроводы.
  • Tier IV если случается единичный отказ любого оборудования, все равно остается N активных компонентов.

Но дело не только в энках, особенно в случае с Tier IV. Главное отличие Tier IV это единственный уровень с отказоустойчивостью. Он так и называется: Fault tolerant infrastructure. Также для него обязательны секционирование (или компартментализация, очень уж мне нравится это слово) и непрерывное охлаждение. Ниже посмотрим, что это значит.

Tier IV отличается от Tier III схемой резервирования оборудования 2(N+1)?

Как мы видим, никакая конкретная схема резервирования для Tier IV не указана. Как добиться N после любого отказа, каждый ЦОД решает сам. Раньше многие понимали требования Tier IV слишком буквально и предлагали сложные схемы наподобие 2N+1 или 2(N+1), чтобы уж наверняка избежать отказов. Но на практике это не обязательно.

Что такое отказоустойчивость в Tier IV? Чем отличается от Tier III?

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

Что такое непрерывное охлаждение в Tier IV?

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

В Tier IV за этим следят гораздо жестче. Уже на этапе проектирования нужно обязательно предоставить расчеты скорости повышения температуры и доказать, что даже теоретически в машзале не станет жарче.

Что значит в Tier IV системы не только зарезервированы, но и защищены от физического воздействия? В чем отличие от Tier III?

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

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

А если случится пожар?

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

А если упадет метеорит?

Наша страна настолько сурова, что иногда случается и такое. Но все-таки ЦОД не военный объект, чтобы защищаться от подобных аварий. Очень жаль, но система Tier не рассматривает защиту от всемирного потопа, вторжения инопланетян или захвата власти рептилоидами.

Tier IV это в 2 раза дороже?

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

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

Перевод RED Улучшение качества звука с помощью резервирования

04.09.2020 14:06:16 | Автор: admin

Еще в апреле 2020 года Citizenlab сообщил о довольно слабом шифровании Zoom и заявил, что Zoom использует аудиокодек SILK. К сожалению, статья не содержала исходных данных, чтобы это подтвердить и дать мне возможность обращаться к ней в дальнейшем. Однако благодаря Натали Сильванович из Google Project Zero и инструменту трассировки Frida я смог получить дамп некоторых необработанных кадров SILK. Их анализ вдохновил меня взглянуть на то, как WebRTC обрабатывает звук. Что касается восприятия качества вызова в целом, больше всего на него влияет качество звука, поскольку мы склонны замечать даже небольшие сбои. Всего десяти секунд анализа было достаточно, чтобы отправиться в настоящее приключение на поиски возможных улучшений качества звука, обеспечиваемых WebRTC.

Я имел дело с нативным клиентом Zoom еще в 2017 году (до поста DataChannel) и обратил внимание, что его аудиопакеты иногда были очень большими в сравнении с пакетами решений на базе WebRTC:

На приведенном выше графике показано количество пакетов с определенной длиной полезной нагрузки UDP. Пакеты длиной от 150 до 300 байт необычное явление, если сравнивать с типичным вызовом WebRTC. Они намного длиннее, чем пакеты, которые мы обычно получаем от Opus. Мы заподозрили наличие упреждающего контроля ошибок (FEC) или резервирования, но без доступа к незашифрованным кадрам было трудно сделать еще какие-то выводы или что-то предпринять.

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

packet 7:e9e4ab17ad8b9b5176b1659995972ac9b63737f8aa4d83ffc3073d3037b452fe6e1ee5e6e68e6bcd73adbd59d3d31ea5fdda955cbb7fpacket 8: e790ba4908639115e02b457676ea75bfe50727bb1c44144d37f74756f90e1ab926ef930a3ffc36c6a8e773a780202af790acfbd6a4dff79698ea2d96365271c3dff86ce6396203453951f00065ec7d26a03420496fpacket 9:e93997d503c0601e918d1445e5e985d2f57736614e7f1201711760e4772b020212dc854000ac6a80fb9a5538741ddd2b5159070ebbf79d5d83363be59f10efe790ba4908639115e02b457676ea75bfe50727bb1c44144d37f74756f90e1ab926ef930a3ffc36c6a8e773a780202af790acfbd6a4dff79698ea2d96365271c3dff86ce6396203453951f00065ec7d26a03420496fe9e4ab17ad8b9b5176b1659995972ac9b63737f8aa4d83ffc3073d3037b452fe6e1ee5e6e68e6bcd73adbd59d3d31ea5fdda955cbaef

Пакет 9 содержит два предыдущих пакета, пакет 8 1 предыдущий пакет. Такая избыточность вызвана использованием формата LBRR Low Bit-Rate Redundancy, как показало глубокое изучение декодера SILK (который можно найти в интернет-проекте, представленном командой Skype или в репозитории GitHub):


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

Opus FEC


Как добиться того же с помощью WebRTC? Следующим очевидным шагом было рассмотрение Opus FEC.

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

В Opus контроль ошибок не просто добавляется после исходного аудиокадра, он предшествует ему и кодируется в потоке битов. Мы пробовали экспериментировать с добавлением нашего собственного контроля ошибок с помощью Insertable Streams API, но это требовало полного перекодирования для вставки информации в битовый поток перед фактическим пакетом.


Хотя усилия и не увенчались успехом, они позволили собрать некоторые статистические данные о влиянии LBRR, которые продемонстрированы на рисунке выше. LBRR использует битрейт до 10 кбит/с (или две трети скорости передачи данных) при больших потерях пакетов. Репозиторий доступен по ссылке. Данная статистика не отображается при вызове WebRTC getStats() API, поэтому результаты оказались весьма занимательными.

Помимо проблемы с необходимостью перекодировки, Opus FEC в WebRTC, как выяснилось, настроен несколько бесполезно:

  • Он активируется только при потере пакетов, а мы хотели бы, чтобы резервная информация хранилась и до возникновения каких-либо проблем. Ребята из Slack писали об этом еще в 2016 году. Это означает, что мы не можем включить его по умолчанию и защитить себя от случайных нерегулярных потерь.
  • Объем прямого исправления ошибок ограничен 25%. Выше этого значения оно неэффективно.
  • Битрейт для FEC вычитается из целевого максимального битрейта (см. здесь).

Вычитание битрейта FEC из целевого максимального битрейта совершенно не имеет смысла FEC активно снижает битрейт основного потока. Поток с более низким битрейтом обычно приводит к снижению качества. Если нет потери пакетов, которую можно исправить с помощью FEC, то FEC только ухудшит качество, а не улучшит его. Почему так происходит? Основная теория состоит в том, что одной из причин потери пакетов является перегрузка. Если вы столкнулись с перегрузкой, вы не захотите отправлять больше данных, потому что это только усугубит проблему. Однако, как описывает Эмиль Ивов в своем замечательном выступлении на KrankyGeek от 2017 года, перегрузка не всегда является причиной потери пакетов. Кроме того, этот подход также игнорирует любые сопутствующие видеопотоки. Стратегия FEC на основе перегрузок для аудио Opus не имеет особого смысла, когда вы отправляете сотни килобит видео вместе с относительно небольшим потоком Opus со скоростью 50 кбит/с. Возможно, в будущем мы увидим какие-то изменения в libopus, а пока хотелось бы попробовать отключить его, ведь в настоящее время он включен в WebRTC по умолчанию.

Делаем вывод, что это не работает

RED


Если нам нужно реальное резервирование, у RTP есть решение под названием RTP Payload for Redundant Audio Data, или RED. Оно довольно старое, RFC 2198 был написан в 1997 году. Решение позволяет помещать несколько полезных нагрузок RTP с различными временными метками в один и тот же RTP пакет при относительно небольших затратах.

Использование RED для помещения одного или двух резервных аудиокадров в каждый пакет дало бы гораздо большую устойчивость к потере пакетов, чем Opus FEC. Но это возможно лишь путем удвоения или утроения битрейта аудио с 30 кбит/с до 60 или 90 кбит/с (с дополнительными 10 кбит/с для заголовка). Хотя по сравнению с более чем 1 мегабитом видеоданных в секунду это не так уж плохо.

Библиотека WebRTC включала в себя второй кодер и декодер для RED, что теперь стало излишним! Несмотря на попытки удалить неиспользуемый audio-RED-code, мне удалось применить этот кодер, прилагая относительно небольшие усилия. Полная история решения есть в системе отслеживания багов WebRTC.

И оно доступно в виде пробной версии, включаемой при запуске Chrome со следующими флагами:
--force-fieldtrials=WebRTC-Audio-Red-For-Opus/Enabled/

Затем RED может быть включен через SDP согласование; он отобразится следующим образом:
a=rtpmap:someid red/48000/2

По умолчанию он не включен, поскольку есть среды, где использование дополнительной пропускной способности не очень хорошая идея. Чтобы использовать RED, измените порядок следования кодеков так, чтобы он был перед кодеком Opus. Это можно сделать, используя API RTCRtpTransceiver.setCodecPreferences, как показано здесь. Очевидно, что другой альтернативой является изменение SDP вручную. Формат SDP также мог бы обеспечить способ настройки максимального уровня резервирования, но семантика предложение-ответ в RFC 2198 была не до конца ясна, поэтому я решил отложить это на время.

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


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



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

Это все еще немного отличается от того, что делает Zoom, где мы наблюдали частичное резервирование. Давайте повторим график длины пакетов Zoom, приведенный ранее, чтобы посмотреть на них в сравнении:

Добавление поддержки обнаружения голосовой активности (VAD)


Opus FEC отправляет резервные данные только в том случае, если в пакете присутствует голосовая активность. То же самое должно быть применено и к реализации RED. Для этого кодировщик Opus должен быть изменён для отображения корректной информации о VAD, которая определяется на уровне SILK. При такой настройке битрейт достигает 60 кбит/с только при наличии речи (в сравнении с постоянными 60+ кбит/с):


и спектр становится больше похож на то, что мы видели у Zoom:


Изменение, позволяющее этого достичь, еще не появилось.

Поиск правильного расстояния


Расстояние это количество резервных пакетов, то есть количество предыдущих пакетов в текущем. В процессе работы над поиском правильного расстояния мы обнаружили, что если RED с расстоянием 1 это круто, то RED с расстоянием 2 еще круче. Наша лабораторная оценка моделировала случайную потерю пакетов = 60%. В этой среде Opus + RED воспроизводил отличный звук, в то время как Opus без RED показывал себя сильно хуже. WebRTC getStats() API дает очень полезную возможность измерить это, сравнивая процент скрытых сэмплов, получаемый путем деления concealedSamples на totalSamplesReceived.

На странице аудиосэмплов эти данные легко получить с помощью данного фрагмента кода JavaScript, вставленного в консоль:
(await pc2.getReceivers()[0].getStats()).forEach(report => {  if(report.type === "track") console.log(report.concealmentEvents, report.concealedSamples, report.totalSamplesReceived, report.concealedSamples / report.totalSamplesReceived)})

Я провел пару тестов с потерей пакетов, используя не очень известный, но очень полезный флаг WebRTCFakeNetworkReceiveLossPercent:
--force-fieldtrials=WebRTC-Audio-Red-For-Opus/Enabled/WebRTCFakeNetworkReceiveLossPercent/20/

При 20% потерях пакетов и включенном по умолчанию FEC не было большой разницы в качестве звука, но была небольшая разница в метрике:
сценарий процент потерь
без red 18%
без red, FEC отключен 20%
red с расстоянием 1 4%
red с расстоянием 2 0.7%

Без RED или FEC метрика почти совпадает с запрошенной потерей пакетов. Есть эффект от FEC, но он невелик.

Без RED при потере 60% качество звука стало довольно плохим, немного металлическим, а слова трудными для понимания:
сценарий процент потерь
без red 60%
red с расстоянием 1 32%
red с расстоянием 2 18%

Были некоторые слышимые артефакты при RED с расстоянием = 1, но почти идеальный звук с расстоянием 2 (что является количеством избыточности, которое используется в настоящее время).
Есть ощущение, что человеческий мозг может выдержать какой-то определенный уровень тишины, возникающей нерегулярно. (А Google Duo, судя по всему, использует алгоритм машинного обучения, чтобы чем-то тишину заполнить).

Измерение производительности в реальном мире


Мы надеемся, что включение RED в Opus улучшит качество звука, хотя в отдельных случаях может сделать и хуже. Эмиль Ивов вызвался провести пару тестов прослушивания по методу POLQA-MOS. Это было сделано в прошлом для Opus, так что у нас есть исходные данные для сравнения.
Если первоначальные тесты покажут многообещающий результат, то мы проведем масштабный эксперимент на основной развертке Jitsi Meet, применяя процентные метрики потерь, которые мы использовали выше.

Обратите внимание, что для медиасерверов и SFU включение RED происходит немного сложнее, поскольку серверу может потребоваться управлять RED ретрансляцией для выбора клиентов, как в случае, если не у всех клиентов поддерживаются конференции RED. Также некоторые клиенты могут находиться на канале с ограниченной пропускной способностью, где RED не требуется. Если конечная точка не поддерживает RED, SFU может удалить ненужное кодирование и отправить Opus без обертки. Аналогичным образом он может реализовать сам RED и использовать его при повторной отправке пакетов от конечной точки, передающей Opus, на конечную точку, поддерживающую RED.

Большое спасибо Jitsi/88 Inc за спонсирование этого приключения и ребятам из Google, которые рассмотрели/предоставили фидбек о необходимых изменениях.

А без Натали Сильванович я бы так и застрял, глядя на зашифрованные байты!
Подробнее..

Резервирование СУБД Oracle силами Veritas NetBackup Appliance быть или не быть?

01.12.2020 10:20:26 | Автор: admin
Наладить резервное копирование СУБД Oracle инструментами того же вендора просто. А если попытаться оптимизировать стоимость решения? Тогда возможные ИТ-инструменты стоит придирчиво рассмотреть в действии. Так и получилось: в поиске ответа на запрос заказчика обнаружилось, когда стоит женить Oracle и NBU, а когда лучше это не делать. Делимся опытом тестирования системы резервного копирования Veritas NBU для защиты данных в СУБД Oracle и интересными нюансами процесса настройки.


Один из наших клиентов ритейлер федерального масштаба озаботился резервированием данных в СУБД Oracle. По умолчанию для этого подходит Oracle Zero Data Loss Recovery Appliance (ZDLRA). Но стоит комплекс как круизный ледокол. К тому же ZDLRA не дал бы клиенту контролировать все процессы резервного копирования через единую консоль. Эти соображения заставили искать альтернативы. Одной из них стало устройство Veritas NetBackup Appliance 5240 СРК среднего уровня с хорошей производительностью в стандартных условиях. Оптимизма добавляла и технология Copilot в арсенале Veritas, предназначенная специально для работы с СУБД Oracle.

Прежде чем испытывать Veritas NetBackup Appliance 5240 в живой инфраструктуре, заказчик попросил протестировать его. Мы собрали стенд и проверили решение в боевых условиях. Выводы оказались любопытными.

Плюсы Veritas NBU


Сначала мы оценили, какие уникальные технологии могут ускорить процессы резервного копирования и восстановления. Поскольку речь шла о резервном копировании СУБД Oracle, а в качестве сетевого подключения использовался 10 GbE (никаких Fiber Channel), наиболее полезными оказались следующие инструменты Veritas:

  • Media Server Deduplication Pool (MSDP) дедупликация данных на лету, которая оптимизирует репликацию резервных копий между устройствами и создает синтетические полные резервные копии за время инкрементальных;
  • NetBackup Optimized Duplication устраняет избыточность передаваемых данных за счет передачи только уникальных блоков, которые отсутствуют на принимающем устройстве;
  • NetBackup Copilot сокращает время создания резервных копий СУБД Oracle, используя мгновенные снимки файловой системы устройства NetBackup и интеграцию с менеджером резервного копирования Oracle RMAN.

Больше других надежду в контексте СУБД Oracle дарила технология NetBackup Copilot. В тестировании мы сфокусировались на проверке ее производительности в сравнении с обычными инкрементальными копиями БД.

К тестированию готовы? Да, но нет


Мы развернули тестовый стенд, который включал в себя NetBackup Master Server, NetBackup Media Server и Oracle Linux Server 6.7. NetBackup Appliance (выступал в роли NetBackup Media Server) был подключен к базе данных через два порта 10 GbE, а NetBackup Master Server развернули на виртуальной машине в среде виртуализации VMware vSphere 6.0.

В качестве источника РК использовали физический сервер с установленной ОС Oracle Linux Enterprise 6.7 и СУБД Oracle 19. Чтобы смоделировать работу системы в условиях, близких к требованиям заказчика, объем тестовой базы Oracle мы установили в размере 1 Tб в формате Bigfile. База данных находилась под нагрузкой, а объем изменений в течение 12 часов составлял 50-60% от изначального объема базы.

Итак, поехали! Мы запустили резервное копирование, но уровень производительности оказался удивительно низким 2,32,8 TB/h. По результатам привет из 90-х! В документах по работе Veritas NBU с СУБД Oracle готовых решений для сложившейся ситуации не было. Но сам факт наличия Copilot и хорошая производительность решения на стандартных задачах, как, например, резервное копирование файловых систем, наводили на мысль, что мы упускаем из виду какие-то моменты. Тогда вместе с коллегами из Veritas мы начали поиск тонких настроек NetBackup, которые повысили бы производительность.

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

  • значения Jumbo Frame (размеры фреймов Ethernet, в которых можно передавать данные);
  • политика передачи хэша (xmit_hash_policy), напрямую влияющая на скорость и эффективность резервного копирования;
  • размеры буферов (Number Disk, Size Disk) Veritas Appliance требовалось менять для резервного копирования часто меняющейся БД

Использовать ли Copilot?


Мы возлагали большие надежды на NetBackup Copilot все-таки эта технология изначально создавалась для работы с СУБД и использует Oracle incremental merge, чтобы перейти на схему резервного копирования forever incremental. При работе в режиме Copilot система взаимодействует с менеджером резервного копирования СУБД Oracle RMAN для запуска команд резервного копирования СУБД.

Если разложить процесс резервного копирования с использованием NetBackup Copilot по стадиям, он выглядит так:

  1. на устройстве NetBackup Appliance настраивается устройство хранения резервных копий, доступное серверу СУБД Oracle по протоколу NFS;
  2. после этого настраивается политика резервного копирования в консоли администрирования СРК NetBackup;
  3. сам процесс резервного копирования начинается с создания базовой копии (level-0), после чего выполняются только инкрементальные резервные копии (level-1);
  4. изменения, возникающие с момента создания базовой резервной копии level-0, применяются к образу, который актуализируется на момент создания последней резервной копии level-1;
  5. NetBackup создает мгновенные снимки образа резервной копии на NFS-хранилище устройства (используя функции интегрированного в устройство ПО InfoScale);
  6. каждая резервная копия и мгновенный снимок добавляются в каталог менеджера резервных копий Oracle RMAN и в служебную базу данных NetBackup.

Плюсов у такого решения много. Например, мгновенные снимки файловой системы NFS-хранилища устройства NetBackup Appliance могут автоматически дублироваться (перемещаться) на наиболее эффективный уровень хранения: диск, пул дедупликации, лента, облачное хранилище, или реплицироваться на устройство NetBackup на резервной площадке. Это делается за счет политик управления жизненным циклом (SLP).

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

А если на скорость?


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

В таблице даны сводные результаты создания полной резервной копии с включенной и выключенной дедупликацией на клиенте, включенной и выключенной срезкой Redo logs, в условиях, когда СУБД находится под нагрузкой и без нагрузки.

Type Job Schedule DB Load Client deduplication Redo logs Elapsed Time Speed TB/h
Backup Full Yes Enable Disable 0:14:06 4,4
Backup Full Yes Disable Disable 0:18:22 4,2
Backup Full Yes Enable Enable 0:22:36 4,1
Backup Full Yes Disable Enable 0:30:07 3,6
Backup Full No Enable Disable 0:12:16 4,7
Backup Full No Disable Disable 0:16:45 4,2
Backup Full No Enable Enable 0:16:15 4,3
Backup Full No Disable Enable 0:17:40 3,9

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

Делаем инкрементальные копии


Чтобы оценить производительность в режиме создания инкрементальных резервных копий, мы проводили копирование 2 раза в сутки в 10:00 и 22:00. СУБД находилась под нагрузкой, а дедупликация на клиенте была включена.

Type Job Schedule DB Load Client deduplication Elapsed Time Speed TB/h
Backup Incremental 10:00 Yes Enable 0:10:58 2,2
Backup Incremental 22:00 Yes Enable 0:09:58 2,2
Backup Incremental 10:00 Yes Enable 0:10:03 2,3
Backup Incremental 22:00 Yes Enable 0:09:04 2,2
Backup Incremental 10:00 Yes Enable 0:11:13 2,3
Backup Incremental 22:00 Yes Enable 0:12:01 2,2
Backup Incremental 10:00 Yes Enable 0:12:21 2,3
Backup Incremental 22:00 Yes Enable 0:10:53 2,5
Backup Incremental 10:00 Yes Enable 0:12:03 2,3
Backup Incremental 22:00 Yes Enable 0:12:04 2,2
Backup Incremental 10:00 Yes Enable 0:12:13 2,3
Backup Incremental 22:00 Yes Enable 0:12:01 2,2
Backup Incremental 10:00 Yes Enable 0:12:21 2,3
Backup Incremental 22:00 Yes Enable 0:10:53 2,5

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

Включаем режим Copilot


В режиме Copilot ситуация выглядит иначе. В нашем тесте создание резервной копии происходило каждые 12 часов, а время резервного копирования фиксировалось от момента создания снапшота Oracle до окончания момента записи резервной копии в storage pool на устройстве NBU.

Type DB Load Elapsed Time Megabytes Speed TB/h
Backup Yes 0:36:53 1 294 153 2,6
Backup Yes 0:32:14 1 126 525 2,5
Backup Yes 0:33:34 1 152 365 2,7
Backup Yes 0:31:23 1 123 620 2,6
Backup Yes 0:44:04 1 681 999 2,9

Результаты этого теста оказались средними. Однако стоит учитывать, что синтезирование резервной копии с последующей записью в storage pool происходило в NFS Share. Возможно, частично за низкую производительность отвечают дополнительные ограничения скорости чтения и записи NFS Share. К тому же для более старших моделей NetBackup Appliance существует технология Optimized Share, так что скорость работы в подобном режиме должна быть выше. Мы использовали Veritas Appliance в минимальной конфигурации с одной полкой, тогда как вендор рекомендует применять минимум две полки для режима Copilot.

Таким образом, главным преимуществом использования Copilot остается восстановление последней полной резервной копии без необходимости наката инкрементальных копий. Использование функции Instant Restore для быстрого доступа к СУБД еще в процессе восстановления также является большим плюсом.

Не больше 25% и в пределах 50 Тб


Вернемся к случаю заказчика. Тестирование на синтетической БД оказалось полезным, так как помогло клиенту увидеть все за и против первоначально симпатичного решения. Поиграв с параметрами, мы пришли к выводу, что использовать Veritas NetBackup целесообразно для СУБД размером до 50 Тб, а также при суточных изменениях в БД не более 25%. Поскольку БД розничной сети менялись каждые сутки на 50%, то Veritas NetBackup не стал подходящим решением.

Побочный эффект нашего тестирования оказался ценным. Мы нашли оптимальные режимы для работы Veritas NBU вместе с СУБД Oracle. За счет настройки параметров и выбора режима (классическая копия или Copilot) можно создать достойную и более доступную альтернативу для резервного копирования и восстановления СУБД Oracle при относительно небольшом количестве суточных изменений в БД в десятки Тб. Для тех, кто уже пользуется СРК Veritas, такой выход оптимален. Это использование более доступной по стоимости СРК и управление всем резервным копированием через одну консоль.

Автор: Артем Хмеленко, инженер систем хранения данных Инфосистемы Джет
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru