Настройка производительности контейнеров Windows Server

Introduction

Начиная с Windows Server 2022, доступны два типа контейнеров: контейнеры Windows Server и контейнеры Hyper-V. Каждый тип контейнера поддерживает либо версию Server Core, либо Nano Server Windows Server 2022.

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

Контейнеры Windows Server и контейнеры Hyper-V

Контейнеры Windows Server и Hyper-V предлагают множество одинаковых преимуществ в плане переносимости и согласованности, но различаются с точки зрения гарантий изоляции и характеристик производительности.

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

Hyper-V контейнеры расширяют изоляцию, предоставляемую контейнерами Windows Server, запустив каждый контейнер в высокооптимизируемой виртуальной машине. В этой конфигурации ядро хоста контейнера не используется совместно с контейнерами Hyper-V.

Дополнительная изоляция, предоставляемая контейнерами Hyper-V, в значительной степени достигается за счет уровня изоляции гипервизора, который находится между контейнером и узлом контейнера. Это влияет на плотность контейнеров, так как в отличие от контейнеров Windows Server, меньше обмена системными файлами и двоичными файлами может произойти, что приводит к более большому объему хранилища и памяти. Кроме того, ожидается дополнительная нагрузка в некоторых сетях, путях ввода-вывода хранилища и ЦП.

Nano Server и Server Core

Контейнеры Windows Server и контейнеры Hyper-V поддерживают Server Core, узнайте больше о параметрах базового образа контейнера.

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

Время Start-Up контейнера

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

Первый вход

Корпорация Майкрософт поставляет базовый образ для Nano Server и Server Core. Базовый образ, который поставляется для Server Core, оптимизирован путем устранения временных затрат, связанных с первым входом в систему (OOBE). Это не так с базовым образом Nano Server. ** Однако эти затраты можно исключить из образов на основе Nano Server, за счёт фиксации хотя бы одного слоя в контейнерный образ. Последующий контейнер начинается с образа, не будет нести первую стоимость входа.

Местоположение временной области памяти

Контейнеры по умолчанию используют временное место на системном диске узла контейнера для хранения в течение времени существования запущенного контейнера. Это служит системным диском контейнера, и поэтому многие операции записи и чтения, выполняемые в контейнере, проходят по этому пути. Для хост-систем, где системный диск установлен на магнитных носителях с вращающимися дисками (HDD), но доступны более быстрые устройства хранения данных (более быстрые HDD или SSD), возможно перенести временное пространство контейнера на другой диск. Это достигается с помощью команды dockerd –g. Эта команда является глобальной и повлияет на все контейнеры, работающие в системе.

Вложенные контейнеры Hyper-V

Hyper-V для Windows Server 2022 поддерживает вложенную поддержку гипервизора. То есть возможность запуска виртуальной машины из виртуальной машины. Это открывает множество полезных сценариев, но также преувеличивает некоторое влияние на производительность, которое оказывает гипервизор, так как два уровня гипервизоров работают на физическом узле.

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

Storage

Подключенные тома данных

Контейнеры предлагают возможность использовать диск системы узла контейнера для временного пространства контейнера. Однако временное пространство контейнера имеет срок жизни, эквивалентный сроку жизни контейнера. То есть, когда контейнер останавливается, временное пространство и все связанные данные удаляются.

Однако существует множество сценариев, в которых требуется сохранение данных независимо от времени существования контейнера. В таких случаях мы поддерживаем подключение томов данных с хоста контейнера в контейнер. Для контейнеров Windows Server незначительные затраты на путь ввода-вывода, связанные с подключенными томами данных (производительность близкая к нативной). Однако при подключении объемов данных к контейнерам Hyper-V на этом маршруте происходит некоторое снижение производительности ввода-вывода. Кроме того, влияние усиливается при запуске контейнеров Hyper-V внутри виртуальных машин.

Пространство с нуля

Контейнеры Windows Server и контейнеры Hyper-V по умолчанию обеспечивают динамический виртуальный жесткий диск объемом 20 ГБ для временного пространства контейнера. Для обоих типов контейнеров ОС контейнера занимает часть этого пространства, и это верно для каждого запущенного контейнера. Поэтому важно помнить, что каждый запущенный контейнер имеет некоторое влияние на хранилище, и в зависимости от рабочей нагрузки может записывать до 20 ГБ резервного носителя хранилища. Конфигурации хранилища сервера должны быть разработаны с учетом этого.

Networking

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

Преобразование сетевых адресов Windows (WinNAT)

Каждый контейнер получит IP-адрес из внутреннего префикса частной IP-адресации (например, 172.16.0.0/12). Поддерживается перенаправление и сопоставление портов с узла контейнера на конечные точки контейнеров. Docker создает сеть NAT по умолчанию при первом запуске dockerd.

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

Контейнеры Windows Server используют виртуальный сетевой интерфейс узла для подключения к виртуальному коммутатору. Hyper-V контейнеры используют синтетический сетевой адаптер ВМ (не виден служебной виртуальной машине) для подключения к виртуальному коммутатору. При взаимодействии контейнеров с внешней сетью пакеты направляются через WinNAT с примененными преобразованиями адресов, что приводит к некоторым издержкам.

Transparent

Каждая конечная точка контейнера напрямую подключена к физической сети. IP-адреса из физической сети можно назначать статически или динамически с помощью внешнего DHCP-сервера.

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

Мост L2

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

Режим моста L2 является более производительным, чем режим WinNAT, так как он предоставляет прямой доступ к внешней сети, но менее производительно, чем прозрачный режим, так как он также вводит преобразование MAC-адресов.