извините за задержку между обновлениями, сезон пыльцы сильно ударил по мне, и я случайно пропустил один из них, находясь под погодой.
Тайна несогласия с выставлением счетов
В течение последних нескольких недель я работал над выяснением того, почему суммы выставления счетов на производственных маршрутизаторах в конечном итоге всегда расходятся.
Все маршрутизаторы договорятся о том, кто кому сколько должен платить в течение нескольких дней, может быть, недели. Тогда дело начало бы дрейфовать.
Маршрутизаторы на каждой стороне соединения могли договориться о том, сколько было заплачено, но расходиться во мнениях относительно правильной суммы.
Очевидно, что это не могла быть простая логическая ошибка. Контролируемое тестирование упрямо давало отличные результаты, даже если оно выполнялось в течение нескольких дней подряд.
Я рассмотрел и исследовал возможность того, что потеря пакетов приводит к смещению счетов в производственной среде. Но это никогда не подтверждалось данными.
После нескольких недель поиска глупых ошибок мне пришлось признать, что проблема, которую я видел, может быть более фундаментальной. В конце концов, это была другая ошибка, которая поставила меня на правильный путь.
В четверг 18-го, около 18:00, все в нашей тестовой сети только возвращались домой с работы, а использование Интернета было на пике за пределами выходных.
Все, казалось, шло гладко, когда системная задержка на шлюзе внезапно начала резко увеличиваться. Видно здесь в системе мониторинга, которую мы используем для нашей инфраструктуры.
Сначала совсем чуть-чуть, а потом через 30 минут стал бесконтрольно подниматься.
DNS-сервер Google 8.8.8.8 вел себя странно в районе Портленда. Сервер будет принимать соединения, но после открытия они будут зависать.
Будучи многосетевым, основная служба 8.8.8.8 предоставляется не одним сервером, а сетью различных машин по всей стране. 8.8.4.4, резервный сервер, похоже, в этот период работал нормально.
После того, как инцидент был исчерпан, система самостоятельно восстановилась в течение 20 минут или около того. Вскрытие было выполнено с исправлением одной строки.
Эта проблема заставила меня задуматься об относительности времени на маршрутизаторах. Наш алгоритм выставления счетов исходил из предположения, что все производят расчеты счетов каждые 5 секунд. Что произойдет, если это не так?
Могут ли небольшие сбои в частоте дискретизации быть причиной нашего расхождения?
Быстрый сбор данных показал, что 1-секундная (20%) дисперсия средней частоты дискретизации не только имела место, но и была почти универсальной.
Нарушение правил
Суть проблемы заключалась в том, что биллинг Althea сравнивал две кривые.
Одной из них была плоская линия, скидка на «пропускную способность уровня бесплатного пользования», другая — выборочная кривая, например, график под каждым маршрутизатором будет отображать другую кривую в зависимости от того, когда и как часто он производил выборку.
Поскольку скидка уровня бесплатного пользования работала как «скидка в секунду» на использованные байты, она связывает уплаченную сумму с точностью механизма выборки.
Со временем эти различия будут суммироваться, поскольку различные маршрутизаторы в поле будут подвергаться различным входным данным.
Такого рода проблема является фундаментальной теорией выборки, нам нужно выбрать по крайней мере скорость Найквиста , чтобы получить точную кривую.
Мы не можем производить выборку так быстро, и мы не можем гарантировать, что согласованное более медленное расписание будет соблюдаться всеми маршрутизаторами.
Если пользователь решит, что ему нужно начать потоковую передачу 4k Netflix, операционная система приостановит выставление счетов, чтобы справиться с всплеском трафика. Наш процесс выставления счетов ничего не может (или не должен) сделать, чтобы остановить это.
К счастью, есть довольно простое решение, чтобы предотвратить возникновение проблем из-за частоты дискретизации, нам нужно избегать использования каких-либо метрик, деноминированных по времени, при выставлении счетов.
Используемые байты — это просто скалярная метрика, которая будет считаться одинаковой при выборке один раз в день или один раз в микросекунду.
К сожалению, это означает, что скидка на оплату уровня бесплатного пользования должна была уйти.
Что это значит для пользователей?
С точки зрения сети бесплатный уровень остается. Ретрансляторы обеспечивают скорость 1 Мбит/с без каких-либо сборов или условий, поэтому пользователи всегда могут приобретать и вносить больше денег для оплаты полосы пропускания. Это имеет смысл для сети и имеет смысл для реле.
Мы скорректировали цены в наших тестовых сетях, чтобы гарантировать минимальное влияние этого изменения на счета пользователей при нормальной работе.
Пользователь, решивший не платить за свой интернет, теоретически может использовать пару долларов в месяц за пропускную способность своего восходящего канала. Раньше это было бы обнулено скидкой бесплатного уровня, но теперь она должна исходить из доходов вышестоящего ретранслятора.
Это на самом деле не проблема в наших нынешних сетях, так как никто не работает в пустом состоянии очень долго.
Но в течение нескольких месяцев или даже года общий объем «украденной» пропускной способности достаточно значителен, и нам придется выяснить, как по времени использовать пропускную способность «бесплатного уровня».
Что нового в бета-версии 4?
- Изменения в правилах выставления счетов для предотвращения расхождений в течение длительного периода времени
- Конечные точки отдельных настроек Wi-Fi заменены одной, чтобы сделать настройку Wi-Fi при подключении к Wi-Fi более плавной.
- Добавлены упрощенные дао-платежи (просто платит в мультиподпись)
- Исправлена ошибка, из-за которой в некоторых случаях распределение портов повторялось навсегда.
- Исправлена ошибка, из-за которой отображение цены в Babel переполнялось.
- Исправлена ошибка, из-за которой шлюзы зависали, если DNS-сервер работал некорректно.
- Исправлена ошибка, из-за которой через 15 минут после переключения порта все остальные порты сетки переставали работать.
- Babel теперь учитывает RTT различных путей.