Установить Didi Technology как " Звезду ⭐️ "
Получайте обновления статей как можно скорее
гид
eBPF — это революционная технология ядра Linux, которая может безопасно и эффективно расширять возможности ядра и имеет широкий спектр приложений, особенно в области облачной наблюдаемости, которая стала горячей точкой в отрасли. В родной среде Didi Cloud технология eBPF осуществила бизнес-практику и совместное создание внутренних источников.Платформа HuaTuo eBPF быстро приземлилась и добилась первоначальных преимуществ.В настоящее время она поддерживает ключевые облачные компоненты, такие как топология отношений доступа к службам. , безопасность контейнера и безопасность хоста. , диагностика сети, определение первопричины и другие услуги, HuaTuo также является бутик-инкубационным проектом комитета по открытым исходным кодам Didi. Есть надежда, что эта статья предоставит отраслевым разработчикам способ быстро применить технологию eBPF к облачным сценариям и совместно улучшить глубокую наблюдаемость облачных систем.
Эта статья разделена на:
1. Прошлая жизнь технологии BPF
2. Текущая жизнь технологии BPF
3. Болевые точки бизнеса в производственной среде Didi
Тест воспроизведения трафика
Топология доступа к службам
безопасность контейнера
Расположение основной причины ядра
4. Практика платформы Didi HuaTuo eBPF
Строительство платформы
Состав платформы
использование платформы
5. Практика бизнес-посадки Didi
Фон местоположения основной причины ядра
Идеи определения местоположения основной причины ядра
Платформа определения основной причины ядра
6. Перспективы планирования будущего
1 ►
Прошлая жизнь технологии BPF
Пакетный фильтр Беркли BPF Пакетный фильтр Беркли, первоначально разработанный в 1993 году, в статье Стивена Макканна и Ван Якобсона "Пакетный фильтр BSD: новая архитектура для захвата пакетов на уровне пользователя". Его цель — предоставить новый метод эффективной фильтрации сетевых пакетов. Изначально BPF подключен только к сетевому сокету ядра Linux.Когда сокет связан с байт-кодом BPF, байт будет выполняться каждый раз при получении сообщения. Ядро решает, разрешать ли прохождение сетевых пакетов, в соответствии с возвращаемым значением байт-кода BPF.
С точки зрения набора инструкций начальная архитектура BPF относительно проста, с 32-битным аккумулятором A, 32-битным регистром X и массивом памяти размером 16x32 бит. Однако BPF реализует четыре типа инструкций: загрузка, сохранение, переход и операция. BPF изначально не имел JIT-компилятора JIT, и все эти инструкции полностью выполнялись на виртуальной машине с небольшим ядром, хотя производительность полностью задавила другие фильтры сообщений.
BPF также более удобен в использовании, мы можем сгенерировать байт-код BPF через tcpdump, libpcap или bpf_asm и загрузить его в ядро через setsockopt SO_ATTACH_FILTER. Чтобы реализовать фильтрацию пакетов ICMP, как показано ниже, вам нужно только оценить, соответствует ли номер протокола условиям, исходя из величины дрейфа в заголовке пакета L2/L3.
BPF сначала использовался в sk_filter, а затем в сетевых подсистемах, таких как netfilter, seccomp и драйверы команд, но направление приложения по-прежнему связано с обработкой сетевых пакетов.
2 ►
Настоящая жизнь технологии BPF
Основная идея BPF реализует программируемость ядра, то есть добиться эффективного расширения возможностей ядра без изменения исходного кода и перекомпиляции ядра. В 2013 году Алексей Старовойтов модифицировал BPF, добавив новые функции и повысив его производительность. Дальнейшее развитие BPF внесло огромные изменения в ядро, позволив ядру иметь более мощные и программируемые возможности динамических изменений. Эта возможность будет иметь большое значение в различных сценариях приложений, требующих настройки, которые можно использовать для расширения функций или оптимизации производительности. Новая версия получила название eBPF («расширенный BPF»), а предыдущая версия BPF стала называться cBPF («классическая» BPF). В следующих главах BPF относится именно к этой технологии.
Прежде всего, с точки зрения набора инструкций, eBPF — это упрощенный набор инструкций, который поддерживает 10 64-битных регистров общего назначения R0-R9. Среди них регистр R0 используется для возвращаемого значения функции ядра, а регистры R1-R5 используются для передачи параметров функции ядра, что аналогично x86_64 и aarch64. eBPF поддерживает два формата кодирования набора инструкций: 64-битное базовое кодирование и 128-битное кодирование инструкций (кодирование инструкций реализуется путем добавления 64-битного непосредственного значения после базового кодирования). Кроме того, eBPF также обогащает четыре типа наборов инструкций.
Инструкции Just In Time, JIT-компилятор, BPF будут динамически компилироваться в собственные инструкции физической машины с помощью JIT-компилятора ядра, обеспечивая «нулевую» потерю эффективности работы. Эта функция была реализована Эриком Дюмазе в период cBPF и поддерживает только архитектуру x86-64. eBPF снова расширяет компилятор в соответствии с характеристиками его собственных инструкций.Инструкции eBPF могут быть не только объединены JIT в собственные инструкции ЦП физической машины, но также могут быть преобразованы в конкретные инструкции некоторых устройств, таких как некоторые интеллектуальные сетевые карты. Таким образом, такие устройства, как интеллектуальные сетевые карты, можно программировать через eBPF.
Помимо обогащения и расширения уровня инструкций, eBPF также добавляет механизм хранения данных на основе пар ключ-значение, который можно использовать для реализации хранения и обмена данными в пользовательском режиме ядра. eBPF добавил более богатые вспомогательные функции BPF, которые позволяют программам BPF получать доступ к функциям ядра и расширять возможности BPF, сохраняя при этом изоляцию безопасности между программами BPF и ядром.
С расширением функций BPF эта технология больше не ограничивается сетевой подсистемой ядра, но постепенно применяется к динамическому отслеживанию, обнаружению событий, анализу и оптимизации производительности, подсистеме ввода-вывода, планированию процессов, файловой подсистеме и т. д. Сценарии приложений также распространяются от конкретных точек к областям: наблюдаемость, трассировка, безопасность, анализ производительности, анализ первопричин и т. д. В то же время появилось большое количество отличных проектов с открытым исходным кодом, таких как Bcc, Cilium, bpftrace, Falco, Katran и Pixie.
3 ►
Болевые точки бизнеса в производственной среде Didi
В центре обработки данных существует множество базовых сервисов, которые играют важную роль в обеспечении стабильности, эффективности производства, масштабируемости, безопасности и т. д., и при фактическом внедрении эти инфраструктуры сталкиваются с разной степенью сложности.
Тест воспроизведения трафика
Масштабы облачных вычислений становятся все больше и больше, а тип выполняемого бизнеса, бизнес-трафик и масштабы также быстро расширяются Тестирование программного обеспечения также сталкивается с большими проблемами, включая создание тестовой среды, написание и обслуживание тестовых сценариев. Тестирование воспроизведения трафика — совершенно новый метод тестирования. Регрессионное тестирование реализуется путем воспроизведения в автономной тестовой среде.Воспроизведение трафика может полностью воспроизводить сложные сценарии онлайн-доступа к бизнесу, значительно повышая эффективность итераций проекта, ускоряя процесс регрессионного тестирования бизнеса и обеспечивая улучшение качества бизнес-исследований и разработок. Проблемы, с которыми сталкивается проект:
Существует множество языков бизнес-программирования и различных версий базовых библиотек.
Модель бизнес-сети не унифицирована (однопроцессная обработка php, обработка сопрограммы golang, многопоточность/процесс других языков программирования).
Подгонянный под конкретный бизнес, сложно улучшить охват, да и стоимость высока.
Есть чувство бизнеса, и сложно гарантировать стабильность.
Топология доступа к службам
С появлением микросервисной архитектуры количество сервисов увеличивается день ото дня, а зависимости между сервисами становятся все более и более сложными. Наблюдаемость служебной связи имеет большое значение для обеспечения стабильности бизнеса. Он может четко отображать отношения доступа между сервисными интерфейсами, а также бизнес-показатели, такие как производительность, задержка и тайм-аут. Когда проблема возникает в сети, проблемный узел может быть быстро обнаружен в соответствии с отношениями топологии службы. Проблемы, с которыми сталкивается проект:
Существует большое количество типов бизнеса, а стоимость ручной сортировки высока и подвержена ошибкам.
Очень сложно продвигать конкретный SDK, полагаясь на метрики и взаимосвязи вызовов служб в журнале для последовательного подключения, и легко разорвать связь в производственной среде.
безопасность контейнера
В связи с общей тенденцией использования облачных технологий все больше и больше предприятий выбирают именно облачные технологии Контейнеры стали стандартом доставки приложений и единицы доставки вычислительных ресурсов и вспомогательных средств в эпоху облачных технологий. Использование контейнеров становится все более популярным, и вопросы безопасности контейнеров становятся все более и более заметными. У Didi есть полный набор решений для защиты контейнеров, и некоторые из основных проблем решаются с помощью технологии eBPF.
Расположение основной причины ядра
Плотность развертывания контейнеров и коэффициент перепроданности собственной платформы Didi Cloud высоки, и проблемы, вызванные неразумным использованием ресурсов, часто возникают в сценариях виртуализации контейнеров с общим ядром. Традиционные индикаторы ядра ориентированы на базовое, общее и крупнозернистое статистическое обнаружение, в то время как традиционные инструменты позиционирования потребляют больше ресурсов и оказывают большее влияние на производительность. Следовательно, для тщательного определения первопричины ядра необходимо проводить углубленные наблюдения за подсистемами ядра и реализовывать нормализованные наблюдения для решения сложных проблем, таких как всплески, тайм-ауты и сбои, возникающие во время и после события.
4 ►
Практика платформы Didi HuaTuo eBPF
Технология eBPF вполне может решить вышеупомянутые болевые точки языковой зависимости, в то же время сочетание eBPF и технологии динамического отслеживания обеспечивает поддержку реализации ядра глубокого наблюдения. Однако в процессе фактической посадки необходимо ответить на следующие вопросы:
В случае многих потребностей, как быстро удовлетворить эти потребности и повысить эффективность НИОКР для быстрой реализации?
Хотя в настоящее время в отрасли есть случаи внедрения, масштаб относительно невелик.Как реализовать внедрение от точки к области и как обеспечить стабильность хост-машины?
Как единообразно наблюдать и гарантировать потерю производительности стейкинг-поинтов, и как быстро откатить, понизить и остановить лоссы в случае возникновения проблем?
Строительство платформы
Основываясь на вышеизложенных соображениях, мы разработали платформу eBPF.Предприятия могут напрямую использовать общие возможности, предоставляемые платформой, и им нужно сосредоточиться только на реализации собственной логики. Процесс построения платформы направлен на повышение эффективности исследований и разработок, предоставление бизнес-перспектив и обеспечение стабильности и производительности.
Повысить эффективность НИОКР
Первым пользователям нужно позаботиться о том, как разобрать байт-код BPF, как загрузить его в ядро, создать карту KV и прикрепить код определенного раздела к конкретным работающим узлам. Наконец, пользователям также необходимо обратить внимание на то, как получить данные из ядра. Важной функцией платформы является защита основных технических деталей.Похожие функции выше требуют только вызова интерфейсов bpfload и bpfmap.
Обеспечьте перспективу бизнеса
Бизнесы и платформы, бизнес и правила бизнес-релиза разные. Наконец, мы используем байт-код BPF Obj, чтобы отделить логику бизнеса от платформы, и бизнес может вызывать интерфейс платформы в соответствии с требованиями. В то же время платформа должна учитывать стандартизацию и поддержку SEC, определяемую другими компонентами с открытым исходным кодом, чтобы она могла быть совместима с существующим байт-кодом BPF и работать непосредственно на платформе.
Гарантия стабильности
По мере внедрения новой технологии необходимо сосредоточиться на стабильности хоста. Гарантия стабильности в основном устанавливается на уровне ядра, на стороне фреймворка и с точки зрения восприятия бизнеса.
гарантированная производительность
Все коды BPF работают в режиме ядра, поэтому слишком много времени все равно повлияет на систему. Управляемая событиями, общая память, а также производство и потребление кольцевых буферов применяются к этой платформе.
Состав платформы
Управление байт-кодом BPF
Во-первых, это анализ возможностей ELF, включая определение SEC, Map, переменных и структур. Через SEC можно уточнить тип BPF Prog и точку крепления Hook, которая может загружаться автоматически. Через определение карты анализируются ее тип, размер, тип ключа, тип значения и другая информация.
Высокопроизводительная обработка данных
Платформа поддерживает множество типов бизнеса, поэтому гарантии производительности необходимо рассматривать с разных сторон. Во-первых, динамически оцените точку захвата зонда на стороне ядра, чтобы обеспечить механизм предохранителя. Высокопроизводительная передача данных обеспечивается на стороне платформы, а метод производства и потребления Ringbuf снижает задержку.
управление стабильностью
Первоначальная цель дизайна платформы — решать онлайн-проблемы и обеспечивать стабильность бизнеса, поэтому в самой платформе реализованы функции объединения событий и самовосстановления. Когда в хосте BPF обнаружена аномалия, платформа автоматически выгружает bpf, чтобы избежать чрезмерной нагрузки, вызванной текущим BPF. Помимо реализации предохранителя и самовосстановления событий, он также ограничивает системные ресурсы, используемые платформой, такие как процессор и память.
Управление информацией о контейнерах
Реализация этой функции в основном основана на следующих факторах: 1. Все службы, работающие в контейнере, передача параметров и идентификация службы требуют этой информации. 2. Информация о контрольной группе ядра должна быть объединена с информацией о контейнере.
использование платформы
В дополнение к интерфейсу API платформа также предоставляет режим командной строки, так что на платформе может работать аварийный запуск BPF OBJ или отладка OBJ.
Пример кода выглядит следующим образом:
Скомпилировать:
clang -O2 -g -target bpf -c $(NAME).bpf.c -o $(NAME).oЗапуск: Платформа автоматически анализирует структуру, определенную BPF, и выводит ее на стандартный вывод.
5 ►
Практика бизнес-посадки Didi
Многие предприятия в Диди были подключены к платформе HuaTuo eBPF, например, для регрессионного тестирования сервисов, безопасности контейнеров, безопасности хостов, топологии доступа к сервисам, диагностики сети, определения основной причины ядра и т. д. Нижеследующее в основном использует расположение основной причины ядра в качестве примера для объяснения.
Фон местоположения основной причины ядра
В настоящее время снижение затрат и повышение эффективности является темой большинства интернет-компаний.В Didi высокая плотность развертывания контейнеров и коэффициент перепроданности.В этом сценарии трудно избежать влияния на другие предприятия из-за нерационального использования ресурсов. Когда происходит сбой, первая мера - остановить потерю, и контейнер будет дрейфовать, поэтому проблемный участок будет потерян.Проблему трудно воспроизвести в автономном режиме, а стоимость рабочей силы и машин очень высока. Кроме того, случайные сбои, отнимающие много времени и проблемы с тайм-аутом на линии не имеют правил, которым нужно следовать Таким образом, нормальное наблюдение является очень сильным требованием.
Идеи определения местоположения основной причины ядра
В соответствии с тремя столпами наблюдаемости (как показано на рисунке ниже) мы сначала устанавливаем индикаторы наблюдения за глубиной ядра, которые более детализированы и могут отражать состояние работоспособности каждой подсистемы ядра. При установлении этих показателей рациональность и влияние на производительность будут оцениваться с разных сторон, и, наконец, будет реализовано нормальное наблюдение. Во-вторых, реализация, управляемая событиями, получает контекст журнала исключений ядра, и нас интересует сбор ошибок в ненормальном пути, медленном пути и других состояниях ошибок подсистем ядра. События-исключения являются ключом к устранению основной причины проблем ядра. Установив основные базовые возможности, мы можем обобщить, проанализировать и, наконец, дать аналитический отчет по этой информации.
Платформа определения основной причины ядра
Мы разделяем платформу определения основной причины ядра на четыре части:
Сбор данных ядра . Эта часть в основном реализует сбор индикаторов ядра ядра и сбор контекста исключений ядра.
Агрегация данных ядра . Эта часть в основном реализует сводку данных наблюдения ядра и информацию о контейнере/поде и загружает их на устройство хранения.
Слой анализа данных . Эта часть в основном обрабатывает собранные данные и предоставляет услуги анализа.
Слой отображения данных . В основном центр анализа и диагностики, центр наблюдения, центр журнала, отчет об анализе, центр сигнализации и т. Д.
6 ►
Перспективы будущего планирования
Основная технология eBPF была реализована в крупномасштабном и многоуровневом сценарии в собственных сценариях Didi Cloud. В будущем платформа HuaTuo eBPF будет обслуживать больше направлений бизнеса. Сегодня мы ищем подходящую основу для инкубации проектов, создания и обмена с отраслевыми разработчиками. В последние годы, хотя технология eBPF достигла значительного прогресса, ее функции в некоторых сценариях недостаточно совершенны, например, оптимизация производительности, планирование ЦП и т. д., а также углубленное изучение сценариев автономного смешанного развертывания. вас в будущем Обмен обсуждениями.