Смотрите предыдущую ссылку:Наггетс.Талант/пост/686596… 

Смешанная конструкция системы

На основе Kubernetes мы внедрили гибридную онлайн-/офлайн-систему для бизнеса, следуя следующим принципам проектирования:

• Динамическое планирование: реализуйте динамическое планирование автономных сервисов в соответствии с реальной нагрузкой узлов.
• Динамическое распределение ресурсов и изоляция: в соответствии с нагрузкой онлайн-бизнеса динамически настраивается количество ресурсов, выделенных для оффлайн-бизнеса, реализация политики динамической изоляции ресурсов, уменьшение или даже устранение помех между каждой производительностью.
• Плагин: не вносите в k8s никаких навязчивых изменений внутри дерева, все компоненты должны разрабатываться на основе механизма расширения k8s, а сама система колокейшн обладает высокой масштабируемостью.
• Своевременное реагирование: когда использование ресурсов совместно расположенных узлов слишком велико или оказывает влияние на онлайн-сервисы, он может вовремя обнаружить и исключить автономные сервисы, чтобы обеспечить SLA онлайн-сервисов.
• Эксплуатация и обслуживание и наблюдаемость: удобство для пользователей и персонала по эксплуатации и техническому обслуживанию, низкая стоимость доступа и низкая стоимость использования image
  

Рис. 6 Архитектура системы

Resource Reclaim

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

Мы настроили совместное размещение/процессор расширенных ресурсов и совместное размещение/память (соответствующие собственному процессору и памяти соответственно) для представления вышеуказанных восстановленных ресурсов и реализации динамического планирования автономных задач.

Рис. 7. Восстановление ресурсов

Если загрузка ЦП онлайн-службы на узле высока, ресурсы, которые мы выделяем автономной службе, будут уменьшены; если загрузка ЦП онлайн-службы низкая, мы можем выделить больше ресурсов для автономной службы.

Динамическое планирование

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

Динамическое выделение ресурсов и динамическая изоляция ресурсов

Компания Google много лет назад вложила много человеческих и материальных ресурсов в область управления ресурсами центров обработки данных. Из-за ограничений аппаратного обеспечения в плане изоляции производительности Google провел большую трансформацию на уровне программного обеспечения и первым предложил ряд технологий изоляции ресурсов, включая контрольные группы, контейнеры и т. д. (многие функции ядра запускаются). по бизнес-требованиям, а не из воздуха придумали). Наша изоляция производительности для онлайн/оффлайн сервисов также в основном достигается с помощью контрольных групп.

Диспетчер cgroup kubelet не имеет точек расширения, и непосредственное изменение кода kubelet приведет к относительно большим затратам на последующие обновления эксплуатации и обслуживания, поэтому мы разработали отдельный агент zeus-isolation-agent для запуска на каждом совместно расположенном узле. cgroups для реализации изоляции бизнес-ресурсов онлайн/офлайн.

Рис. 8. Изоляция ресурсов офлайн-сервиса

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

Перепланирование офлайн-сервиса

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

Перепланирование офлайн-задач имеет следующие преимущества:

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

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

Приземленные результаты

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

Взяв, к примеру, Netease Media, медиа смешивали службу транскодирования видео как автономную службу с машиной онлайн-службы, и загрузка ЦП увеличилась с 6%-15% до примерно 55% после микширования.

Во-первых, давайте взглянем на характеристики сервисов транскодирования видео:

• Интенсивная нагрузка на ЦП, большое количество дисков для чтения и записи сохраняют временные данные и определенное количество сетевых операций ввода-вывода.
• Долгоиграющий pod, вместо run-to-complete pod, он будет непрерывно брать видео задачи из очереди на перекодирование, а если задач нет, то будет бездействовать и продолжать работать
• Транскодирование одного видео занимает секунды, поэтому изменение расписания оказывает минимальное влияние.

redis+транскодирование видео

Служба Redis — это онлайн-служба, чувствительная к задержке. У нее высокие требования к SLO, но низкая загрузка ЦП. Поэтому мы пытаемся объединить службу транскодирования видео с выделенным узлом Redis. Давайте посмотрим на эти две в / Эффект выхода из бизнес-микс.

Рис. 9. Использование ЦП до и после совместного размещения узлов Redis

Как видно из рисунка 9, загрузка ЦП узлов Redis составляет около 8% до совместного размещения и достигает 30–35% после совместного размещения, при этом коэффициент использования значительно повышается.

Затем давайте взглянем на сравнение в реальном времени операций SET/GET в Redis до и после микширования.

Рисунок 10 Среднее время отклика Redis Получить операции

Таблица 3 Среднее время отклика операций Redis GET

Из рисунка 10 и таблицы 3 видно, что RT операции GET практически не меняется до и после совместного размещения.

Рис. 11 Среднее время отклика операций Redis SET

Таблица 4 Среднее время отклика операции Redis SET

Из рисунка 11 и таблицы 4 видно, что RT работы SET до и после совместного размещения в основном не изменяется.

Рекомендация по рекламе + транскодирование видео

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

Рис. 12. Сравнение загрузки ЦП узлов до и после совместного размещения

Как видно из рисунка 12, коэффициент использования ЦП находился в пределах 10-20% до совместного размещения, а коэффициент использования ЦП оставался на уровне около 55% в течение длительного времени после совместного размещения, и коэффициент использования значительно увеличился. .

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

Рис. 13. Время обработки запроса службы рекомендаций по рекламе

Из рисунка 13 видно, что индекс производительности ядра до и после совместного размещения не имеет затухания и ухудшения.Среднее время до совместного размещения составляет 6,59 мс, а среднее время восстановления после совместного размещения составляет 6,65 мс. :

Таблица 5. Средние показатели RT до и после совместного размещения службы рекомендаций по рекламе

Резюме и перспективы

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

использованная литература

[1] The Datacenter as a Computer
[2] Overall Data Center Costs
[3] Анализ текущего состояния затрат и использования центров обработки данных.
[4] Quasar: resource-efficient and QoS-aware cluster management
[5] Говоря об исследовании системы смешанных отделов
[6] PerfIso: Performance Isolation for Commercial Latency-Sensitive Services
[7] Borg: the Next Generation
[8] Autopilot: workload auto scaling at Google
[9] Improving Resource Efficiency in Cloud Computing

Смотрите друзей здесь, если вам понравилась эта статья, не забудьте переслать, добавить в закладки и оставить сообщение для взаимодействия!

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

Если у вас есть какие-либо вопросы по статье, пожалуйста, свяжитесь со мной в области сообщений~