скорость pps что это
Миллион PPS в секунду — связанность и балансировка
На последней конференции РИТ++ мне посчастливилось стать впервые докладчиком конференции такого масштаба и такой значимости. В этой статье я не просто хочу пересказать всё, о чём я докладывал. Выступать впервые перед такой большой аудиторией для меня было непривычно и я половину забыл рассказать, нервничал немного. Речь пойдет о создании с нуля собственной отказоустойчивой структуры для веб-проектов. Мало кому из системных администраторов дается возможность с нуля запустить в production крупный проект. Мне повезло.
Как я уже написал, я не смог рассказать всё, что планировал со сцены, в этой статье я восполню эти пробелы, да и для того, кто не смог там присутствовать — это будет приятно, видео с конференции так и не дали бесплатно всем. Да и стать пользователем Хабра я хотел давно, вот только не было времени. Майские праздники дали время и силы. Статья будет не столько технической с кучей конфигов и графиков — статья будет принципиальная, все пробелы мелких технических вопросов можно будет восполнить в комментариях.
Ставим задачу: нам нужно организовать на 99,9% отказоустойчивый веб-проект, который не будет зависеть от конкретного дата-центра (ДЦ), иметь двойное резервирование на коммутации в ДЦ, иметь отказоустойчивость на балансировке и очень быстро вводить и выводить Real сервера. При падении одного из ДЦ, второй должен принять весь трафик без дропов и ретрансмитов. Говорить мы будем только о фронт, об отказах, балансировках и немного о деплое такого количества серверов. У всех своя специфика backend.
Проект, которым я занимаюсь очень критичен к даже минутным сбоям. Если просуммировать RPS 400+ топ проектов Рунета: Яндекс, Мейл, Рамблер, Афишу, Авто, и пр., получите наш суммарный RPS. В какой-то момент стало понятно, что если далее держать все яйца в одной корзине (ДЦ), можно очень хорошо и красиво упасть. Если вспомнить пыхи Чубайса по Москве — меня понять можно. Мы начали изучать вопрос разноса фермы серверов на несколько ДЦ. Главный вопрос — не раскидать сервера на несколько ДЦ, не связанных одним и тем-же магистралом, а быстро и незаметно для клиента переключать трафик с одного ДЦ на другой.
Сразу оговорюсь: выбранная нами реализация возможна только при наличии собственной AS минимум с маской /23, официально порезанных в RIPE на 2 сети по /24. Честно говоря я не в курсе, как в настоящий момент, но раньше были проблемы с анонсами на транзите у того-же ТТК сетей менее /24. Мы выбрали в качестве маршрутизаторов в ДЦ Cisco ASR 1001 с соответствующей начинкой и возможностью работать с EXIST-MAP, NON-EXIST-MAP. Рассмотрим пример 2х ДЦ. 2 ASR-а держат туннель просто для того, чтобы знать, что связанность обоих ДЦ жива. Из одного ДЦ мы анонсируем одну сеть класса С, из второго ДЦ — вторую сеть. Как только мы видим из второго ДЦ, что связанность нарушена, мы начинаем с помощью NON-EXIST-MAP анонсировать вторую сеть /24 из первого ДЦ. Желательно ДЦ разнести географически — но это на бюджет и цвет.
Тут важный момент, к которому мы вернемся немного позже: на серверах балансировки и на Real серверах должны быть постоянно одновременно подняты IP адреса из обоих сетей в обоих ДЦ, это важно. При корректной связанности всех ДЦ маршруты руководят, кто отвечает на адреса той или иной сети, поэтому нужен туннель между маршрутизаторами, чтоб голову не унесло. Прошу OpenSource сообщество не пинать ногами — я знаю как это реализовать на quagga с весами префиксов, но проект крупный и есть соответствующие требования. Я просто рассказываю, как это реализовано у нас.
При тестировании смен маршрутов, мы наткнулись на неприятную ситуацию: у многих на доступе стоят Juniper. Сейчас объясню почему неприятную. По-умолчанию смена маршрута анонсируется 1 раз в 3 минуты. Для нас — это потеря сотен гигабайт данных. Мы начали экспериментировать с уменьшением времени анонсов — до 20 секунд было все отлично: анонсы поднимались из разных концов нашей огромной родины отлично и все быстрее, но после уменьшения данного параметра мы потеряли один из ДЦ. Как оказалось у Juniper, который обслуживал один из аплинков менее 20 секунд считается флудом и не возможно уменьшить, это особенности прошивки. Итог: 21 секунда — самый оптимальный параметр.
Так. Всё. Failover для 2х ДЦ мы сделали, протестировали — это работает. Реальное время свичинга маршрутов по России — от 25 до 60 секунд — в зависимости от удалённости и транзита. На этом этапе у нас есть 2 голых ДЦ с маршрутизаторами. Начнём ставить начинку в оба ДЦ.
Резервировние коммутации внутри ДЦ
Тут я буду краток — коммутация внутри ДЦ сделана 2 на 2: 2 физических интерфейса в Bond смотрят на разные коммутаторы в vlan, обслуживающий реальные IP адреса, 2 физических интерфейса в Bond — на разные коммутаторы в vlan, обслуживающий backend. Режим бондинга мы выбрали самый простой mode=1 — на отказ, просто нулевые части бондинга мы разбросали на разные коммутаторы. Вообще, чем проще, тем надёжнее. На каждом сервере, участвующем в фронт и бэк — 4 физических интерфейса. На рисунке показан только фронт. Коммутаторы связаны не только по 10G, но и кабелем резервного питания и подключены к разным UPS. Mode=1 не требует специальной настройки коммутаторов, что упрощает управление всей инфраструктурой.
Собственно особых альтернатив не было, был выбран IPVS в режиме DR (Direct Routing). Как я говорил выше, этот метод балансировки менее затратен. Он лишает прелестей дампа соединений в обе стороны, как в NAT, но требует меньше ресурсов. Любителям notrack скажу — лучше так не делать, если Вам важно сохранить 100% соединений. IPVS — штатный в Centos и не требует особых шаманств при установке. Единственный нюанс с которым мы столкнулись — по-умолчанию IPVS готов принимать 4096 одновременных соединений — это 12 бит.
Чтобы балансировщик был готов принимать миллион соединений этот параметр нужно увеличить до 20 битов. Через options в управлении модулем (modprobe.d) это сделать не удалось — ipvsadm так же упорно твердил, что готов обслуживать 4096 соединений. Пришлось запустить свои ручки в src и пересобрать модуль. Для небольшого проекта это не столь важно, но если Вы обслуживаете сотни тысяч и выше соединений — это критично.
У балансировки есть много методов. Самый простой — RR (Round Robin) — отдавать на Real сервера входящие соединения «по-кругу». Но мы выбрали тип WLC — взвешенная балансировка с контролем соединений. Если мы параметр persistence на балансировщике синхронизируем с keepalive параметром в nginx на Real серверах, то получим гармоничность в соединениях. Просто если, например, persistence на балансировщике будет 90 секунд, а keepalive в nginx на Real — 120, то мы получим следующую ситуацию: балансировщик через 90 секунд отдаст все соединения клиента на другой Real, а старый Real будет ещё держать соединения клиента. Если учитывать, что при 30 секундном keepalive на 10 тысяч ESTABLISHED соединений мы имеем порядка 120 тысяч TIME_WAIT (это совершенно нормально, мы с Игорем Сысоевым считали в кулуарах технофорума мейла), то это достаточно критично.
Теперь по самой технологии балансировки, как это работает: IP адрес, который у нас прописан в DNS для домена мы вещаем на внешний физический интерфейс балансировщика и на алиасы loopback-ов Real серверов. Ниже будет пример конфигурации sysctl Real серверов — там нужно обязательно прикрыть arp аннонсы и, по желанию, source routing, для того, чтобы коммутация не сошла с ума от дублирования IP. Я не буду описывать весь sysctl — он достаточно специфичен для каждого проекта — покажу только параметры, обязательные для именно DR специфики.
Маршрутизация для алиаса loopback-а с реальным IP на Real серверах с маской 255.255.255.255 должна быть прописана на IP маршрутизатора, обслуживающего вашу сеть и аннонсирующий её во вне, иначе запросы-то на балансировку придут, а вот Real не ответит. Некоторые мудрят с iproute2 и VIP таблицами, но это усложняет конфигурацию.
Теперь об отказоустойчивости балансировки и Real. Keepalived был выбран совершенно логично — сами разработчики IPVS рекомендуют использовать его в связке со своим продуктом. Штатная схема — MASTER + SLAVE подойдёт 99% проектам, но нам это не подошло, ибо в настоящий момент в одном ДЦ 5 балансеров, в другом 3. Средняя стоимость лезвия 120-140 тысяч, поэтому решили немного сэкономить. Если внимательно посмотреть в секцию конфигурации keepalived, где описываются группы, то станет понятно, что, если на 2х мастерах задать разные группы, а на 1м slave описать в конфиге обе, то 1 slave будет работать на 2 мастера по схеме: выпал 1 мастер, slave подхватил его IP, если же выпал второй, то и второй IP подхватывается на этот же slave. Минус конечно есть, при вылете обоих мастеров, на slave упадёт двойная нагрузка, но для балансировщика это не сильно критично, в отличии от Real.
И ещё одна маленькая хитрость: в конфиге keepalived предусмотрен CHECK Real серверов. Он может быть простым TCP, может дёргать по HTTP страничку для контроля 200того ответа, но есть MISC_CHECK. Штука удобная и функциональная. Если на Real сервер положить небольшой скрипт, не важно на чём написанный, который будет по Вашей логике вычислять текущий LA и генерить динамический вес Real сервера для балансировщиков, то Вы с помощью параметра MISC_DYNAMIC на балансировщике получите динамическое изменение веса Real-а.
Немного о деплое. Деплой — это автоматизация развёртывания серверов. Если у Вас 2-3-4 сервера, конечно Вы не будете разворачивать автоматизацию, но если у Вас их десятки или сотни, то однозначно стоит, тем более, если сервера сгруппированы одинаковыми задачами.
У меня на фронте всего 2 группы — это балансировщики и Real сервера с nginx, которые собственно и отдают контент пользователю.
Если в конфигурационных файлах требуются уникальные для каждого сервера данные, в salt присутствует шаблонизатор pillar, который умеет генерить на лету уникальные конфиги. Я перед тем, как развернуть всю ферму, начал именно с сервера деплоя, чтобы после окончания формирования фермы серверов быть уверенным, что деплой написан корректно. И Вам так советую.
Это лишь часть доклада. Обязательно выберу время и напишу отдельную статью по методикам тестирования web фермы, «выжимания» максимума из nginx без дропов и ретрансмитов, разницам синтетических и продакшн тестов.
Биты в секунду против пакетов в секунду
В последнее время я проверяю спецификации нескольких моделей коммутаторов у разных поставщиков. Для данного коммутатора вендоры публикуют несколько цифр, которые, по моему мнению, являются мерой емкости /производительности коммутатора:
Несмотря на то, что разные производители используют разные имена для цифр, кажется, что значение всегда одно и то же.
Я хотел бы понять три вещи:
4 ответа
Я просто хочу кратко упомянуть о реальности маркетинговой математики, когда вы рассматриваете листы данных поставщика. Для поставщиков часто бывает, что у вас есть полнодуплексные ссылки, чтобы удвоить скорость bps или pps. Например, Catalyst 6500 от Cisco имеет Supervisor 720. 720 используется, поскольку он продается как имеющий емкость 720 Гбит /с.
Почти каждый поставщик крутит маркетинговые номера, подобные этому, и я выбираю только Cat6500, потому что я очень хорошо знаком с платформой. Это не осуждение Cisco или Cat6500 (к чему у меня действительно есть страсть).
Каково точное значение каждой фигуры? В чем разница между ними?
Когда мне следует сосредоточиться на каждом значении для оценки коммутатора?
Есть время и место для такого анализа, но большинство людей используют лишь небольшую долю их мощности pps /bps для коммутатора, если только это не является верхушкой коммутатора в загруженном центре обработки данных или ключевым переключателем для от среднего до крупного поставщика услуг POP.
В двигателях пересылки (обычно измеряется в pps)
Связи с тканевой /линейной сеткой /линейные ASIC (обычно измеренные в бит /с)
Обычно вам предоставляется пропускная способность в Mbps (М-бит /сек) и Mpps (M-пакеты /сек). Они считаются номерами объединительной платы или пропускной способности коробки. Маркетинговые материалы обычно представляют числа в лучшем свете, который находится в идеальных условиях больших пакетов с длиной 1500 байт. Реалистичная пропускная способность может быть получена в условиях тестирования, которые используют Internet Mix (IMIX) данных, где длина и протокол пакетов различаются.
Чтобы добавить к хорошим ответам, данным @generalnetworkerror и @MikePennington
Но они, особенно pps, также идеализированы на сценарий определения поставщика «типичный», сценарий оказывает гораздо меньшее влияние на коммутационные устройства (Cisco-катализатор, Juniper ex, Force10, Brocade), поскольку они, как правило, работают в устройства ASIC постоянного времени для поиска. И он имеет тенденцию оказывать большее влияние на устройства, подобные маршрутизаторам (Cisco ASR9k, Juniper MX, Alcatel SR), поскольку они, как правило, запускают NPU, который близок к нормальному процессору в дизайне, и для выполнения работы потребуется переменное время.
Эта неотъемлемая функция используется, когда продавцы покупают «проверенные сторонними» тесты, например, Cisco может заплатить Miercom за тестирование Cisco + Juniper, а Juniper может заплатить EANTC за тестирование Cisco + Juniper.
Эти инженеры EANTC и Miercom получают внутреннюю информацию для обеих платформ, и они используют эту внутреннюю информацию, чтобы показать, как одна платформа (оплачивающего клиента) выходит на другую платформу. Потому что они выбирают те тесты, которые нацелены на компромиссы в идеализированном сценарии, выбранном этим поставщиком.
К счастью, редко в коммутаторном устройстве pps или bps станут для вас проблемой, гораздо более вероятно, что вы будете укушены, например, микроразрывом (последствием небольших буферов), даже близко к платформам bps /pps лимиты.
Более типично pps и bps влияют на вас в младших ящиках с процессорами COTS, то есть на программных блоках, таких как Cisco ISR, ветвь Juniper SRX или брандмауэры.
В очень общих и грубых терминах bps измеряет пропускную способность памяти и производительность поиска pps (скорость процессора)
Рассматривая свое обновление, посмотрите, что вы в настоящее время используете. SNMP (Simple Network Management Protocol) может помочь вам в этом. У вас есть возможность для роста, обновив свою среду, чтобы получить пропускную способность менее 50% при текущем использовании сети на новом устройстве и менее чем на 40% использования ЦП.
Ликбез по Power Delivery: что стыдно не знать о стандарте быстрой зарядки
Когда энергия в аккумуляторе мобильного устройства стремительно заканчивается, быстрая зарядка становится настоящим подарком. Впрочем, разнообразие как проприетарных, так и лицензированных стандартов затрудняет определение того, какую именно скорость выйдет получить при использовании конкретных блока питания и кабеля. Конечно, можно ориентироваться только на комплектные аксессуары от производителя гаджета, но обойтись одной зарядкой сегодня — не самая простая задача. Выходом становится Power Delivery — актуальная официальная спецификация быстрой зарядки USB Promoters Group.
Power Delivery (PD) — универсальная спецификация, разработанная как общий стандарт быстрой зарядки, который можно использовать с любыми гаджетами с поддержкой USB-интерфейса. PD существует с 2012 года — примерно с того же момента, когда представили порт USB-C. Новый стандарт зарядки стал заменой для спецификации USB Battery Charging (USB BC), которая дополняла базовые параметры питания USB-порта. На данный момент пользователям и производителям доступна уже третья редакция Power Delivery, которая заточена для эффективной быстрой зарядки.
Что нужно знать про зарядку гаджетов через порты USB
Современные порты USB-С поддерживают несколько стандартных спецификаций зарядки. Более того, производители могут комплектовать их дополнительными проприетарными возможностями.
Для начала важно отметить, что абсолютно все USB-порты поддерживают базовый уровень зарядки от 5 В и 500 мА до 5 В и 900 мА. Да, скорость наполнения энергией в данном случае будет крайне медленной, но это нужно для работы с устаревшими девайсами, а также маломощными гаджетами. Порты USB-С базово можно «разогнать» до 5 В и 1,5 А и даже 15 В и 3 А. Это намного быстрее, но всё ещё достаточно медленно, если говорить про стандарты быстрой зарядки в целом.
Стандарт Power Delivery отличается куда большей скоростью — он может работать даже с мощностью 100 Вт, чего уже будет более чем достаточно и для самых требовательных гаджетов вроде ноутбуков. Важным нюансом работы с PD является безопасность — когда гаджеты используют данный стандарт, они согласовывают необходимую мощность через USB-кабель. Спецификация поддерживает варианты зарядки с напряжением 5 В, 9 В, 15 В и 20 В, чтобы обеспечить мощность от 0,5 до 100 Вт. Новый стандарт программируемого источника питания USB Power Supply (USB PD PPS) также поддерживает определение напряжения, что нужно для более оптимальной зарядки. Если блок питания и гаджет не могут согласовать необходимую скорость зарядки, используется базовая.
💡 Мощность равна произведению напряжения и силы тока.
Сегодня Power Delivery используется для быстрой зарядки смартфонов, ноутбуков и других гаджетов. Google взял стандарт на вооружение для линейки Pixel, Samsung использует его для серии Galaxy S, а Apple — в iPhone и MacBook. Внушительное число других производителей добавляют работу с PD к своим проприетарным технологиям быстрой зарядки.
На данный момент есть три поколения стандарта Power Delivery
На данный момент стандарт Power Delivery находится уже в третьей редакции, которая характеризуется индивидуальным набором особенностей и возможностей. Впрочем, PD отличается обратной совместимостью, поэтому особенно переживать по поводу выбора не стоит.
Первая редакция Power Delivery была заметно более простой, чем современные. Она предлагала шесть фиксированных профилей питания для разных категорий гаджетов: 10 Вт (5 В, 2 А), 18 Вт (12 В, 1,5 А), 36 Вт (12 В, 3 А), 60 Вт (12 В, 5 А), 60 Вт (20 В, 3 А) и 100 Вт (20 В, 5 А). Такое разнообразие по мощности уже можно считать достаточным, но сегодня для огромного зоопарка из девайсов разных форматов требуется ещё большая гибкость.
Во второй и третьей редакциях Power Delivery от набора фиксированных профилей было решено отказаться. Конкретные значения по напряжению в них остаются, но сила тока может меняться в согласованном диапазоне. В итоге получается ещё более универсальный подход к зарядке абсолютно любых гаджетов. От второй третья редакция PD отличается контролем состояния аккумулятора, повышенной безопасностью и возможностью изменения напряжения по мере зарядки.
Подавляющее большинство современных устройств использует вторую и третью редакцию Power Delivery. Для смартфонов типичная мощность зарядки — 18 Вт, для ноутбуков — около 60 Вт. Впрочем, некоторые мобильные устройства всё же настроены на работу с большей скоростью — к примеру, VOOC Flash Charge уже поддерживает мощность свыше 100 Вт.
Как работает программируемый источник питания USB PD PPS
Вторая и третья редакции Power Delivery весьма технологичны, но всё ещё не в полной мере соответствуют требованиям гибкости для действительно быстрой зарядки. Её скорость крайне чувствительна к определённому напряжению, которое должно меняться по мере наполнения аккумулятора энергией. Варианты напряжения 5 В, 9 В, 15 В и 20 В из стандартной спецификации PD далеки от идеала для оптимальной быстрой зарядки.
Одной из особенностей третьей редакции Power Delivery, которую представили в 2018 году, стал программируемый источник питания USB PD PPS. Он отличается заметно большей гибкостью и предлагает шаг напряжения на уровне 20 мВ (0,02 В). Более того, в данном случае необходимое напряжение может быть не только согласовано, но и изменено прямо во время зарядки. Для быстрого наполнения устройства энергией это очень важно.
В первой половине 2021 года USB PD PPS — всё ещё диковинка. Его поддержка реализована всего в нескольких гаджетах и аксессуарах, и это создаёт трудности для потребителей. К примеру, для быстрой зарядки Samsung Galaxy S21 нужен блок питания именно с поддержкой USB PD PPS — только с ним смартфон сможет принимать 25 Вт. При использовании же традиционного стандарта Power Delivery гаджет сможет получить только 18 Вт.
Как быстро гаджеты заряжаются с помощью Power Delivery
Стандарт Power Delivery характеризуется внушительным спектром вариантов итоговой мощности. Более того, его поддерживает масса устройств, которые отличаются, в том числе, и по ёмкости аккумулятора. Поэтому дать чёткий ответ на вопрос подзаголовка достаточно сложно. Впрочем, обычно смартфоны используют мощность 18 Вт и полностью заряжаются примерно за час с лишним. Ноутбуки же с блоками питания на 60 Вт могут получить необходимый объём энергии приблизительно за час или два.
В отличие от ноутбуков, смартфоны, как правило, предпочитают более низкое напряжение (5 или 9 В) и высокую силу тока. К примеру, технология OnePlus даёт возможность разогнаться до 65 Вт при 10 В и 6,5 А, а 40 Вт от Huawei базируются на 10 В и 4 А. Это — проприетарные варианты. Тем не менее они показательны.
Ближайший вариант напряжения в PD — 9 В. При его использовании в рамках стандарта скорость зарядки теоретически может составлять 27 Вт. Но для работы со смартфонами Power Delivery обычно использует более низкую силу тока, которая не дотягивает до 3 А. Поэтому на выходе получается 18–20 Вт — это заметно меньше, чем у протоколов быстрой зарядки, разработанных отдельными производителями гаджетов.
Впрочем, у PD всё же есть перспективы в мире универсальных стандартов быстрой зарядки. При использовании PPS Samsung Galaxy S21 может заряжаться на скорости 25 Вт при напряжении 9,5 В. А в Galaxy Note 10 Plus компании удалось добиться быстрой зарядки с мощностью 45 Вт. Тем не менее нужно понимать, что реализацию настолько большой мощности в Samsung сочли слишком сложной с точки зрения работы аккумуляторов, поэтому кроме перспектив у Power Delivery также хватает и вопросов.
Power Delivery вряд ли будет конкурировать с проприетарными стандартами быстрой зарядки. В своих смартфонах OPPO тизерит поддержку 100 Вт, а Xiaomi уже реализовала 120 Вт. Без существенной переработки у PD нет шансов даже вместе с PPS. Впрочем, если объективно, сегодня даже 40 Вт уже более чем достаточно для действительно быстрой зарядки того же смартфона.
Кроме удобства Power Delivery играет на пользу и экологии
Конечно, высокая скорость зарядки является важной особенностью Power Delivery в целом и PPS в частности. Тем не менее куда важнее универсальность. PD был создан как единый стандарт для питания по USB широкого спектра гаджетов. Он нивелирует необходимость в проприетарных портах и особенных блоках питания.
Прежде всего, это крайне положительно сказывается на простоте подключения и зарядки. Но есть и вторая сторона медали — отсутствие необходимости оснащать каждое новое мобильное устройство отдельным блоком питания. Обилие старых кабелей и других аксессуаров для зарядки, которые остаются на свалках и не так просты в переработке, становится всё большей проблемой. Она также усугубляется ограниченностью драгоценных металлов и других элементов, которые используются на производстве. Power Delivery — это серьёзный ответ на сложный экологический вопрос.
Конечно, производители, которые убирают блоки питания из коробок своих устройств сегодня, пока не особенно радуют пользователей. Последние могут не обладать подходящими аксессуарами, поэтому должны приобретать их отдельно. Но в долгосрочной перспективе ситуация придёт в норму. Каждый из нас не будет заморачиваться, чем именно заряжать свои гаджеты, — по крайней мере, если Power Delivery станет единым решением, которое возьмут на вооружение абсолютно все.
Статья написана на основе материала Android Authority.