Процессор intel core dns: Корпус для ПК LIAN LI O11D Mini-W White G99.O11DMI-W.R0

Сравнительный анализ надежности DNS в многоядерных системах

Введение

В рамках продолжающегося исследования производительности DNS-сервера мы хотели установить базовый показатель абсолютной максимальной пропускной способности, которая может быть достигнута с использованием стандартных API. С этой целью мы разработали крошечный DNS-сервер, который ничего не делает, кроме эха, возвращающего полученный пакет клиенту, хотя и с перевернутым битом «QR», чтобы указать, что пакет является ответом, а не запросом.

Эхо-сервер DNS позволяет пользователю указать, сколько раз он должен разветвляться на отдельные процессы и сколько потоков (если есть) запускать в каждом процессе. Он также поддерживает ряд моделей ввода-вывода, включая стандартный «блокирующий» ввод-вывод и неблокирующий ввод-вывод с использованием явных poll(2) или select(2) вызовов или через libevent . Для многоядерных систем он также поддерживает привязку процессов или потоков к определенному ядру ЦП.

У нас есть тестовая установка, состоящая из сервера с двумя четырехъядерными процессорами Intel Xeon X5355 с тактовой частотой 2,66 ГГц и клиентской машины с двумя четырехъядерными процессорами Intel Xeon X5365 с тактовой частотой 3,0 ГГц. Машины подключены через коммутатор 10 Гбит/с с использованием сетевых карт на базе Intel 82599ES. Обе машины работают под управлением Fedora Server 21 с ядром 3.19..7-200, а генератором запросов является Nominum dnsperf 2.0.0 , упакованный Fedora и использующий прилагаемый образец файла запроса.

Ненастроенные тесты

На следующем графике показаны средняя, ​​минимальная и максимальная пропускная способность, полученные для различного количества серверных процессов, работающих с блокирующей моделью ввода-вывода. Каждая точка данных является результатом десяти 30-секундных запусков dnsperf с использованием параметров командной строки по умолчанию. Была выполнена минимальная настройка буферов чтения/записи UDP как на клиенте, так и на сервере с помощью sysctl переменные net. core.rmem и net.core.wmem оба имеют максимальное значение и значение по умолчанию 16 МБ каждая.

В целом пропускная способность относительно постоянна по всем трем параметрам, хотя объяснение внезапного падения при параллельной работе 7 или 8 серверных процессов не сразу очевидно. В противном случае плоская цифра пропускной способности наводит на мысль, что сам клиент ограничивает производительность. Также следует отметить, что вариативность результатов весьма значительна — результаты отнюдь не детерминированы.

Настройка на стороне клиента

Чтобы исключить эффекты на стороне клиента при тестировании, были опробованы различные настройки dnsperf, в конечном итоге эмпирически остановившись на явно оптимальных настройках -c 8 , чтобы dnsperf действовал как несколько клиентов, и -q 500 , чтобы разрешить максимум 500 невыполненных запросов. По умолчанию -c 1 -q 100 . Было также установлено, что использование taskset для ограничения dnsperf на использование только одного из двух клиентских процессоров было более оптимальным. Причина последнего остается невыясненной.

Для двух или трех одновременных серверных процессов существенно увеличивается как средняя, ​​так и максимальная пропускная способность (последняя на 45% до 348 тыс. запросов в секунду с предыдущего максимума в 239 тыс. запросов в секунду). Однако для некоторых тестов изменчивость еще больше увеличилась, чем раньше. Следует также отметить, что увеличение максимальной пропускной способности еще больше подтверждает теорию о том, что ненастроенные dnsperf параметры, использованные для создания первого графика, сами по себе ограничивали максимальную пропускную способность системы в целом.

Чтобы объяснить увеличение переменной, необходимо глубже изучить архитектуру сетевой карты. Сетевые адаптеры 82599ES автоматически настраиваются с восемью отдельными очередями TxRx, каждая со своим собственным номером прерывания (или «IRQ»). В Linux связь каждой очереди TxRx с ядрами ЦП автоматически обрабатывается службой irqbalance , и по умолчанию она последовательно назначает каждую очередь TxRx одному ядру ЦП.

Количество IRQ, которые были обработаны для каждой комбинации очереди TxRx и ядра ЦП, можно просмотреть в /proc/interrupts . С каждым 30-секундным запуском dnsperf счетчики начинают увеличиваться, но в обработке сетевого трафика участвуют не более 3 отдельных очередей и, следовательно, только 3 ядра ЦП.

Во время каждого запуска dnsperf назначения очередей меняются, как и ядра ЦП, выделяемые самому эхо-серверу DNS. В результате лишь изредка возникает в высшей степени оптимальная (или крайне неоптимальная) комбинация очередей и ядер. Более низкая производительность при использовании 4+ серверных процессов требует дальнейшего изучения, как и очевидный предел использования только 3 очередей. 8259Карты 9ES позволяют выполнять более точную балансировку «по потоку» входящего трафика в очередях TxRx, и это можно будет рассмотреть в более позднем исследовании.

Настройка на стороне сервера

Для дальнейшего устранения изменчивости тестов служба irqbalance была отключена, а каждая очередь TxRx была привязана к ядру ЦП 7 путем выполнения следующей команды для каждого номера IRQ, связанного с каждой очередью TxRx:

 # echo 80 > /proc/sys/27/smp_affinity
…
# эхо 80 > /proc/sys/34/smp_affinity
 

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

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

Итак, давайте посмотрим, что произойдет, если мы явно используем только один серверный процесс, а также явно блокируем его для каждого ядра ЦП по очереди:

Теперь все становится действительно интересным! Мы видим одинаковые результаты (более или менее) для ядер 0, 2, 4 и 6; более низкие, но равные результаты для ядер 1 и 3; очень высокий результат (хотя и не самый высокий из виденных) для ядра 5; а затем на втором месте находится ядро ​​​​7 (тот, который также обрабатывает прерывания NIC).

Поскольку ядро ​​7 является последним ядром второго ЦП, а ядра 0, 2, 4 и 6 находятся на другом ЦП, неудивительно, что на этих ядрах не наблюдается никакой разницы.

Что, пожалуй, более удивительно, так это то, что ядра 1, 3 и 5 не дают одинаковых результатов. Ответ заключается в конкретной используемой архитектуре процессора. Хотя X5355 описывается как четырехъядерный процессор, на самом деле это два двухъядерных кристалла в одном корпусе. Каждая пара ядер совместно использует кэш-память уровня 2 объемом 4 МБ, и между двумя парами ядер нет общего кэша, как показано на этой диаграмме, созданной lstopo программа:

Поскольку весь сетевой трафик обрабатывается ядром 7 (PU P#7 на приведенной выше диаграмме), наиболее оптимальная (одноядерная) производительность достигается при принудительной обработке DNS «ближайшим» ядром ЦП. эхо-сервер. Позволив ядру 7 выполнять все , работа будет менее эффективной.

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

Возвращаясь к более раннему наблюдению, что некоторая комбинация двух ядер является оптимальной, были проведены дополнительные тесты, чтобы точно определить, какая именно комбинация, как показано ниже: как на том же ядре, что и обрабатывающее сетевой трафик, так и на другом ядре из того же кристалла, который использует один и тот же кэш L2. Эта конкретная комбинация достигла скорости более 390 тыс. кадров в секунду, что примерно на 45–65% выше, чем результаты, полученные для большинства других комбинаций.

Считается, что комбинация ядер 1 и 5 намного лучше, чем комбинация ядер 1 и 3, просто потому, что ядро ​​5 уже имеет доступ к хранилищу пакетных данных в своем общем кэше с ядром 7. Для тех, кто интересуется комбинацией ядер 3. и 5 его результаты были такими же, как и для ядер 1 и 5, как и ожидалось, исходя из архитектуры ЦП.

Для полноты картины были проведены тесты на различных комбинациях трех-четырех ядер. Комбинации ядра 1 или 3, работающие вместе с ядрами 5 и 7, имели примерно ту же скорость, что и ядра 5 и 7 сами по себе. Комбинация четырех процессов с ядрами 1, 3, 5 и 7 была значительно медленнее, как и различные другие специальные комбинации четырех или более процессов, разделенных между двумя процессорами.

Заключение

Тестирование производительности — черная магия. Это сильно зависит от многих переменных, включая архитектуру ЦП, возможности сетевой карты, поведение прерываний и привязку ядер ЦП.

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

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

Мы планируем включить уроки, полученные выше, в наш набор внутренних регрессионных тестов производительности BIND, что придаст нам большую уверенность в результатах наших собственных тестов.

Автомасштабирование службы DNS в кластере

На этой странице показано, как включить и настроить автомасштабирование службы DNS в кластере.
ваш кластер Kubernetes.

Прежде чем начать

• У вас должен быть кластер Kubernetes, а инструмент командной строки kubectl должен
  быть настроен для связи с вашим кластером. Рекомендуется запускать это руководство в кластере по крайней мере с двумя узлами, которые не действуют как узлы плоскости управления. Если у вас еще нет
  кластер, вы можете создать его, используя
  миникуб
  или вы можете использовать одну из этих игровых площадок Kubernetes:

  • Killercoda
  • Play with Kubernetes

  Чтобы проверить версию, введите kubectl version .

• В этом руководстве предполагается, что ваши узлы используют архитектуру ЦП AMD64 или Intel 64.

• Убедитесь, что Kubernetes DNS включен.

Определите, включено ли уже горизонтальное автомасштабирование DNS

Список развертываний
в вашем кластере в пространстве имен kube-system:

 kubectl get deploy --namespace=kube-system
 

Вывод аналогичен следующему:

 ИМЯ ГОТОВО АКТУАЛЬНО ДОСТУПНО ВОЗРАСТ
...
DNS-автомасштабирование 1/1 1 1 ...
...
 

Если вы видите «dns-autoscaler» в выходных данных, горизонтальное автомасштабирование DNS
уже включен, и вы можете перейти к
Настройка параметров автомасштабирования.

Получите имя развертывания DNS

Перечислите развертывания DNS в вашем кластере в пространстве имен kube-system:

 kubectl get deployment -l k8s-app=kube-dns --namespace=kube-system
 

Вывод аналогичен следующему:

 ИМЯ ГОТОВО АКТУАЛЬНО ДОСТУПНО ВОЗРАСТ
. ..
сердцевина 2/2 2 2 ...
...
 

Если вы не видите развертывание для служб DNS, вы также можете найти его по имени:

 kubectl get deploy --namespace=kube-system
 

и найдите развертывание с именем coredns или kube-dns .

Цель масштабирования:

 Развертывание/
 

, где — это имя вашего развертывания DNS. Например, если
имя вашего развертывания для DNS — coredns, ваша цель масштабирования — Deployment/coredns.

Примечание. CoreDNS — это служба DNS по умолчанию для Kubernetes. CoreDNS устанавливает метку
k8s-app=kube-dns , чтобы он мог работать в кластерах, которые изначально использовались
куб-dns.

Включить горизонтальное автомасштабирование DNS

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

Создайте файл с именем dns-horizontal-autoscaler.yaml со следующим содержимым:

admin/dns/dns-horizontal-autoscaler.yaml

 Тип: ServiceAccount
апиВерсия: v1
метаданные:
  имя: kube-dns-autoscaler
  пространство имен: kube-система
---
вид: Кластерроле
apiVersion: rbac.authorization.k8s.io/v1
метаданные:
  имя: система: kube-dns-autoscaler
правила:
  - группы API: [""]
    ресурсы: ["узлы"]
    глаголы: ["список", "смотреть"]
  - группы API: [""]
    ресурсы: ["контроллеры репликации/масштаб"]
    глаголы: ["получить", "обновить"]
  - apiGroups: ["приложения"]
    ресурсы: ["развертывания/масштаб", "наборы реплик/масштаб"]
    глаголы: ["получить", "обновить"]
# Удалите правило configmaps после устранения следующей проблемы:
# kubernetes-incubator/cluster-proportional-autoscaler#16
  - группы API: [""]
    ресурсы: ["configmaps"]
    глаголы: ["получить", "создать"]
---
вид: Кластерролебиндинг
apiVersion: rbac. authorization.k8s.io/v1
метаданные:
  имя: система: kube-dns-autoscaler
предметы:
  - вид: ServiceAccount
    имя: kube-dns-autoscaler
    пространство имен: kube-система
РольСсылка:
  вид: Кластерроле
  имя: система: kube-dns-autoscaler
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: приложения/v1
вид: развертывание
метаданные:
  имя: kube-dns-autoscaler
  пространство имен: kube-система
  этикетки:
    k8s-приложение: kube-dns-autoscaler
    kubernetes.io/cluster-service: «правда»
спецификация:
  селектор:
    метки соответствия:
      k8s-приложение: kube-dns-autoscaler
  шаблон:
    метаданные:
      этикетки:
        k8s-приложение: kube-dns-autoscaler
    спецификация:
      priorityClassName: системный-кластер-критический
      безопасностьКонтекст:
        seccompПрофиль:
          тип: RuntimeDefault
        дополнительные группы: [ 65534 ]
        фсГрупп: 65534
      селектор узла:
        kubernetes.io/ОС: линукс
      контейнеры:
      - название: автомасштабирование
        изображение: реестр. k8s.io/cpa/cluster-proportional-autoscaler:1.8.4
        Ресурсы:
            Запросы:
                процессор: "20м"
                память: "10Ми"
        команда:
          - /cluster-пропорционально-автомасштабирование
          --namespace=kube-система
          --configmap=kube-dns-автомасштабирование
          # Должен поддерживать синхронизацию цели с cluster/addons/dns/kube-dns.yaml.base
          --target=
          # Когда кластер использует большие узлы (с большим количеством ядер), «coresPerReplica» должен доминировать.
          # При использовании небольших узлов "nodesPerReplica" должен доминировать.
          --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"preventSinglePointFailure":true,"includeUnschedulableNodes":true}}
          --logtostderr=истина
          --v=2
      допуски:
      - ключ: "CriticalAddonsOnly"
        оператор: "Существует"
      serviceAccountName: kube-dns-autoscaler
 

В файле замените на целевое значение масштаба.

Перейдите в каталог, содержащий файл конфигурации, и введите этот
команда для создания развертывания:

 kubectl apply -f dns-horizontal-autoscaler.yaml
 

Вывод успешной команды:

 deploy.apps/dns-autoscaler created
 

Горизонтальное автомасштабирование DNS теперь включено.

Настройте параметры автомасштабирования DNS

Убедитесь, что ConfigMap dns-autoscaler существует:

 kubectl получить configmap --namespace=kube-система
 

Вывод аналогичен этому:

 ИМЯ ДАННЫЕ ВОЗРАСТ
...
DNS-автомасштабатор 1 ...
...
 

Изменить данные в ConfigMap:

 kubectl edit configmap dns-autoscaler --namespace=kube-system
 

Найдите эту строку:

 linear: '{"coresPerReplica":256,"min":1,"nodesPerReplica":16}'
 

Измените поля в соответствии с вашими потребностями. Поле «мин» указывает
минимальное количество бэкендов DNS. Фактическое количество бэкэндов
рассчитано по этому уравнению:

 реплик = max(ceil(ядра × 1/coresPerReplica), ceil(узлы × 1/nodesPerReplica))
 

Обратите внимание, что значения coresPerReplica и nodesPerReplica равны
плавает.

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

Существуют и другие поддерживаемые шаблоны масштабирования. Подробнее см.
кластерно-пропорциональное автомасштабирование.

Отключить горизонтальное автомасштабирование DNS

Существует несколько вариантов настройки горизонтального автомасштабирования DNS. Какой вариант
использование зависит от различных условий.

Вариант 1. Уменьшите развертывание dns-autoscaler до 0 реплик

Этот вариант подходит для всех ситуаций. Введите эту команду:

 развертывание масштаба kubectl --replicas=0 dns-autoscaler --namespace=kube-system
 

Результат:

 Deployment. apps/dns-autoscaler масштабируется
 

Убедитесь, что количество реплик равно нулю:

 kubectl get rs --namespace=kube-system
 

Выходные данные отображают 0 в столбцах ЖЕЛАЕМЫЙ и ТЕКУЩИЙ:

 НАЗВАНИЕ ЖЕЛАЕМЫЙ ТЕКУЩИЙ ВОЗРАСТ ГОТОВНОСТИ
...
DNS-автомасштабирование-6b59789fc8 0 0 0 ...
...
 

Вариант 2. Удалить развертывание dns-autoscaler

Этот вариант работает, если dns-autoscaler находится под вашим собственным контролем, что означает
никто не будет воссоздавать это :

 kubectl удалить развертывание dns-autoscaler --namespace=kube-system
 

Вывод:

 deployment.apps "dns-autoscaler" удален
 

Вариант 3: удалить файл манифеста dns-autoscaler с главного узла

Этот вариант работает, если dns-autoscaler находится под управлением (устарело)
менеджер аддонов,
и у вас есть доступ на запись к главному узлу.

Войдите на главный узел и удалите соответствующий файл манифеста.
Общий путь для этого dns-autoscaler:

 /etc/kubernetes/addons/dns-horizontal-autoscaler/dns-horizontal-autoscaler.yaml
 

После удаления файла манифеста Менеджер надстроек удалит
Развертывание dns-autoscaler.

Понимание того, как работает горизонтальное автоматическое масштабирование DNS

• Приложение кластерного пропорционального автоматического масштабирования развертывается отдельно от
  службу DNS.

• Модуль автомасштабирования запускает клиент, который опрашивает сервер API Kubernetes для
  количество узлов и ядер в кластере.

• Требуемое количество реплик рассчитывается и применяется к серверам DNS на основе
  текущие планируемые узлы и ядра и заданные параметры масштабирования.

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