Настройка параметров производительности контейнеров Windows Server
Введение
Начиная с версии Windows Server 2022 доступны два типа контейнеров: контейнеры Windows Server и контейнеры Hyper-V. Каждый тип поддерживает номера SKU 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 системные и двоичные файлы используются совместно в меньшей степени), увеличивая общий объем хранилища и памяти. Кроме того, применение некоторых режимов использования сети, операций ввода-вывода для хранилища и ЦП может быть сопряжено с дополнительными издержками.
Server Core и Nano Server
Контейнеры Windows Server и Hyper-V поддерживают Server Core. Узнайте больше о вариантах основного образа контейнера.
Nano Server: это удаленно управляемая серверная ОС, оптимизированная для частных облаков и центров обработки данных. Этот вариант аналогичен Windows Server в режиме основных серверных компонентов, однако значительно меньше по размеру, не имеет функций локального входа и поддерживает только 64-разрядные приложения, средства и агенты. В сравнении с Windows Server она занимает гораздо меньше места на диске, намного быстрее запускается и требует на порядок меньше обновлений и перезапусков. При этом сам перезапуск выполняется гораздо быстрее.
Время запуска контейнера
Время запуска контейнера — важнейшая метрика во многих ситуациях, когда использование контейнеров является неоспоримым преимуществом. Крайне важно понимать, как ускорить запуск контейнера. Ниже описаны некоторые компромиссные решения.
Первый вход в систему
Корпорация Майкрософт предоставляет базовый образ для Nano Server и Server Core. Базовый образ для Server Core оптимизирован путем устранения издержек при запуске, связанных с первым входом в систему (запуск при первом включении компьютера). Для базового образа Nano Server такая оптимизация не применялась. Но эти издержки можно устранить и в образах на основе Nano Server, зафиксировав хотя бы один слой в образе контейнера. В этом случае при последующих запусках контейнера из образа не будет использоваться столько ресурсов, как при первом запуске.
Расположение области для временных файлов
По умолчанию контейнеры используют область на системном диске узла контейнера для хранения временных файлов во время существования запущенного контейнера. Эта область выполняет роль системного диска контейнера, поэтому к ней обращаются очень многие операции записи и чтения в контейнере. Если система узла использует системный диск на вращающемся магнитом носителе (HDD), но располагает и более быстрым носителем для хранения данных (быстрый HDD или любой SSD), вы можете переместить область для временных файлов на другой диск. Для этого примените команду dockerd –g. Эта команда имеет глобальный охват, влияя на все запущенные в системе контейнеры.
Вложенные контейнеры Hyper-V
В Hyper-V для Windows Server 2022 предлагается поддержка вложенных гипервизоров. Теперь можно запустить виртуальную машину внутри другой виртуальной машины. Это позволяет реализовать множество полезных сценариев, но одновременно и усиливает влияние гипервизоров на производительность, ведь на физическом узле работает сразу два уровня гипервизоров.
Для контейнеров это важно, когда контейнер Hyper-V работает внутри виртуальной машины. Контейнер Hyper-V обеспечивает изоляцию на уровне гипервизора между собой и узлом контейнера, а узел контейнера представляет собой виртуальную машину на основе Hyper-V. Поэтому наблюдается снижение производительности, связанное с временем запуска контейнера, операциями ввода-вывода хранилища и сети, пропускной способностью сети и производительностью ЦП.
Хранилище
Подключенные тома данных
Контейнеры позволяют использовать системный диск узла контейнера для размещения области временных файлов контейнера. Но срок жизни файлов в этой области совпадает со сроком жизни контейнера. Это означает, что область временных файлов и все данные в ней очищаются при остановке контейнера.
Но во многих сценариях требуется сохранять данные независимо от времени существования контейнера. Для таких ситуаций мы реализовали возможность подключения к контейнеру томов данных из узла контейнера. Для контейнеров Windows Server использование подключенных томов данных незначительно влияет на операции ввода-вывода (производительность соответствует внутренним показателям). Но при подключении томов данных к контейнерам Hyper-V в этом режиме наблюдается некоторое снижение производительности. Более того, это влияние усиливается при работе контейнеров Hyper-V внутри виртуальных машин.
Область временных файлов
Контейнеры Windows Server и контейнеры Hyper-V предоставляют динамический виртуальный жесткий диск объемом 20 ГБ в качестве области временных файлов контейнера по умолчанию. В контейнерах обоих типов часть этой области занимает ОС контейнера, и это справедливо для каждого запущенного контейнера. Поэтому важно помнить, что каждый запущенный контейнер занимает часть физического хранилища и в зависимости от рабочей нагрузки может использовать для записи до 20 ГБ. Это следует учитывать при планировании конфигураций хранилища для сервера.
Сеть
Контейнеры Windows Server и контейнеры Hyper-V предоставляют различные сетевые режимы, позволяя выбрать наиболее подходящий для разных сетевых конфигураций. Каждый из этих режимов оказывает определенное влияние на производительность.
Преобразование сетевых адресов Windows (WinNAT)
Каждый контейнер получает IP-адрес из внутреннего частного IP-префикса (например, 172.16.0.0/12). Поддерживается перенаправление и сопоставление портов с узла контейнера на конечные точки контейнеров. При первом запуске dockerd подсистема Docker создает сеть NAT.
Из этих трех режимов конфигурация NAT больше других влияет на операции сетевого ввода-вывода, но требует меньшего объема настроек.
Контейнеры Windows Server используют виртуальную карту узла для подключения к виртуальному коммутатору. Контейнеры Hyper-V используют искусственный сетевой адаптер виртуальной машины (не предоставляемый служебной виртуальной машине) для подключения к виртуальному коммутатору. Когда контейнеры обмениваются данными с внешней сетью, пакеты направляются через WinNAT с применением преобразования адресов, что влечет за собой дополнительные издержки.
Прозрачный режим
Каждая конечная точка контейнера подключена напрямую к физической сети. IP-адреса из физической сети могут назначаться статически или динамически с помощью внешнего DHCP-сервера.
Прозрачный режим наиболее экономичен с точки зрения сетевого ввода-вывода, так как внешние пакеты передаются напрямую на виртуальный сетевой адаптер контейнера, предоставляя прямой доступ к внешней сети.
Мост L2
Каждая конечная точка контейнера будет находиться в той же IP-подсети, что и узел контейнера. IP-адреса должны быть назначены статически из того же префикса, что и узел контейнера. Все конечные точки контейнера на узле будут иметь один и тот же MAC-адрес из-за преобразования адресов уровня 2.
Режим моста второго уровня обеспечивает более высокую производительность, чем режим WinNAT, так как он предоставляет прямой доступ к внешней сети. При этом его производительность ниже по сравнению с прозрачным режимом, так как выполняется преобразование MAC-адресов.