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

Введение Introduction

Windows Server 2016 — это первая версия ОС Windows со встроенной поддержкой технологии контейнеров. Windows Server 2016 is the first version of Windows to ship support for container technology built in to the OS. В Windows Server 2016 доступны два типа контейнеров: контейнеры Windows Server и контейнеры Hyper-V. In Server 2016, two types of containers are available: Windows Server Containers and Hyper-V Containers. Каждый тип поддерживает номера SKU Server Core и или Nano Server Windows Server 2016. Each container type supports either the Server Core or Nano Server SKU of Windows Server 2016.

Эти конфигурации по-разному влияют на производительность. Мы подробно рассмотрим их, чтобы вы могли выбрать подходящий вариант для своих сценариев. These configurations have different performance implications which we detail below to help you understand which is right for your scenarios. Кроме того, мы подробно опишем конфигурации, влияющие на производительность, и компромиссные решения с использованием каждого из этих вариантов. In addition, we detail performance impacting configurations, and describe the tradeoffs with each of those options.

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

Контейнер Windows Server и контейнеры Hyper-V предоставляют сходные возможности, предоставляющие сходные возможности переносимости и согласованности. Но они отличаются в контексте гарантий изоляции и показателей производительности. Windows Server Container and Hyper-V containers offer many of the same portability and consistency benefits but differ in terms of their isolation guarantees and performance characteristsics.

Контейнеры Windows Server обеспечивают изоляцию приложений используя соответствующую технологию в отношении процессов и пространств имен. Windows Server Containers provide application isolation through process and namespace isolation technology. Контейнер Windows Server использует ядро совместно с узлом контейнера и всеми остальными контейнерами на этом узле. A Windows Server container shares a kernel with the container host and all containers running on the host.

Контейнеры Hyper-V расширяют возможности изоляции, предоставляемые контейнерами Windows Server, ведь каждый контейнер запускается в высокооптимизированной виртуальной машине. Hyper-V Containers expand on the isolation provided by Windows Server Containers by running each container in a highly optimized virtual machine. В этой конфигурации ядро узла контейнера не используется совместно с контейнерами Hyper-V. In this configuration the kernel of the container host is not shared with the Hyper-V Containers.

Дополнительная изоляция, предоставляемая контейнерами Hyper-V, во многом достигается благодаря предоставляемому гипервизором уровню изоляции между контейнером и узлом контейнера. The additional isolation provided by Hyper-V containers is achieved in large part by a hypervisor layer of isolation between the container and the container host. Это влияет на плотность контейнеров (в отличие от контейнеров Windows Server системные и двоичные файлы используются совместно в меньшей степени), увеличивая общий объем хранилища и памяти. This affects container density as, unlike Windows Server Containers, less sharing of system files and binaries can occur, resulting in an overall larger storage and memory footprint. Кроме того, использование некоторых режимов использования сети, операций ввода-вывода для хранилища и ЦП может быть сопряжено с дополнительными издержками. In addition there is the expected additional overhead in some network, storage io, and CPU paths.

Server Core и Nano Server Nano Server and Server Core

Контейнеры Windows Server и контейнеры Hyper-V поддерживают Server Core, а для нового режима установки, доступного в Windows Server 2016, еще и Nano Server. Windows Server Containers and Hyper-V containers offer support for Server Core and for a new installation option available in Windows Server 2016 : Nano Server.

Nano Server: это удаленно управляемая серверная ОС, оптимизированная для частных облаков и центров обработки данных. Nano Server is a remotely administered server operating system optimized for private clouds and datacenters. Этот вариант аналогичен Windows Server в режиме основных серверных компонентов, однако значительно меньше по размеру, не имеет функций локального входа и поддерживает только 64-разрядные приложения, средства и агенты. It is similar to Windows Server in Server Core mode, but significantly smaller, has no local logon capability, and only supports 64-bit applications, tools, and agents. Он занимает гораздо меньше места на диске и запускается быстрее. It takes up far less disk space and starts faster.

Время запуска контейнера Container Start Up Time

Время запуска контейнера является важнейшей метрикой во многих ситуациях, когда использование контейнеров является неоспоримым преимуществом. Container start up time is a key metric in many of the scenarios that containers offer the greatest benefit. Крайне важно понимать, как можно ускорить запуск контейнера, As such, understanding how to best optimize for container start up time is critical. поэтому ниже описаны некоторые компромиссные решения. Below are some tuning trade-offs to understand to achieve improved start up time.

Первый вход в систему First Logon

Корпорация Майкрософт предоставляет базовый образ для Nano Server и Server Core. Microsoft ships a base image for both Nano Server and Server Core. Базовый образ для Server Core оптимизирован путем устранения издержек при запуске, связанных с первым входом в систему (запуск при первом включении компьютера). The base image which ships for Server Core has been optimized by removing the start-up time overhead associated with first logon (OOBE). Для базового образа Nano Server такая оптимизация не применялась. This is not the case with Nano Server base image. Но эти издержки можно устранить и в образах на основе Nano Server, зафиксировав хотя бы один слой в образе контейнера. However, this cost can be removed from Nano Server based images by committing at least one layer to the container image. В этом случае при последующих запусках контейнера из образа не будет использоваться столько ресурсов, как при первом запуске. Subsequent container starts from the image will not incur the first logon cost.

Расположение области для временных файлов Scratch Space Location

По умолчанию контейнеры используют область на системном диске узла контейнера для хранения временных файлов во время существования запущенного контейнера. Containers, by default, use a temporary scratch space on the container host’s system drive media for storage during the lifetime of the running container. Эта область выполняет роль системного диска контейнера, поэтому к ней обращаются очень многие операции записи и чтения в контейнере. This serves as the container’s system drive, and as such many of the writes and reads done in container operation follow this path. Если система узла использует системный диск на вращающемся магнитом носителе (HDD), но располагает и более быстрым носителем для хранения данных (быстрый HDD или любой SSD), вы можете переместить область для временных файлов на другой диск. For host systems where the system drive exists on spinning disk magnetic media (HDDs) but faster storage media is available (faster HDDs or SSDs), it is possible to move the container scratch space to a different drive. Для этого примените команду dockerd –g. This is achieved by using the dockerd –g command. Эта команда имеет глобальный охват, влияя на все запущенные в системе контейнеры. This command is global, and will affect all containers running on the system.

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

В Hyper-V для Windows Server 2016 добавлена поддержка вложенных гипервизоров. Hyper-V for Windows Server 2016 introduces nested hypervisor support. Теперь вы можете запустить виртуальную машину внутри другой виртуальной машины. That is, it is now possible to run a virtual machine from within a virtual machine. Это позволяет реализовать множество полезных сценариев, но одновременно и усиливает влияние гипервизоров на производительность, ведь на физическом узле работает сразу два уровня гипервизоров. This opens up many useful scenarios but also exaggerates some performance impact that the hypervisor incurs, as there are two level of hypervisors running above the physical host.

Для контейнеров это важно, когда контейнер Hyper-V работает внутри виртуальной машины. For containers, this has an impact when running a Hyper-V container inside a virtual machine. Контейнер Hyper-V обеспечивает изоляцию на уровне гипервизора между собой и узлом контейнера, а узел контейнера представляет собой виртуальную машину на основе Hyper-V. Поэтому наблюдается снижение производительности, связанное с временем запуска контейнера, операциями ввода-вывода хранилища и сети, пропускной способностью сети и производительностью ЦП. Since a Hyper-V Container offers isolation through a hypervisor layer between itself and the container host, when the container host is a Hyper-V based virtual machine, there is performance overhead associated in terms of container start-up time, storage io, network io and throughput, and CPU.

Хранение Storage

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

Контейнеры позволяют использовать системный диск узла контейнера для размещения области временных файлов контейнера. Containers offer the ability to use the container host system drive for the container scratch space. Но срок жизни файлов в этой области совпадает со сроком жизни контейнера. However, the container scratch space has a life span equal to that of the container. Это означает, что область временных файлов и все данные в ней очищаются при остановке контейнера. That is, when the container is stopped, the scratch space and all associated data goes away.

Но во многих сценариях требуется сохранять данные независимо от времени существования контейнера. However, there are many scenarios in which having data persist independent of container lifetime is desired. Для таких ситуаций мы реализовали возможность подключения к контейнеру томов данных из узла контейнера. In these cases, we support mounting data volumes from the container host into the container. Для контейнеров Windows Server использование подключенных томов данных незначительно влияет на операции ввода-вывода (производительность соответствует внутренним показателям). For Windows Server Containers, there is negligible IO path overhead associated with mounted data volumes (near native performance). Но при подключении томов данных к контейнерам Hyper-V в этом режиме наблюдается некоторое снижение производительности. However, when mounting data volumes into Hyper-V containers, there is some IO performance degradation in that path. Более того, это влияние усиливается при работе контейнеров Hyper-V внутри виртуальных машин. In addition, this impact is exaggerated when running Hyper-V containers inside of virtual machines.

Область временных файлов Scratch Space

Контейнеры Windows Server и контейнеры Hyper-V предоставляют динамический виртуальный жесткий диск объемом 20 ГБ в качестве области временных файлов контейнера по умолчанию. Both Windows Server Containers and Hyper-V containers provide a 20GB dynamic VHD for the container scratch space by default. В контейнерах обоих типов часть этой области занимает ОС контейнера, и это справедливо для каждого запущенного контейнера. For both container types, the container OS takes up a portion of that space, and this is true for every container started. Поэтому важно помнить, что каждый запущенный контейнер занимает часть физического хранилища и в зависимости от рабочей нагрузки может использовать для записи до 20 ГБ. Thus it is important to remember that every container started has some storage impact, and depending on the workload can write up to 20GB of the backing storage media. Это следует учитывать при планировании конфигураций хранилища для сервера. Server storage configurations should be designed with this in mind. (Можно ли настроить размер области временных файлов?) (can we configure scratch size)

сеть; Networking

Контейнеры Windows Server и контейнеры Hyper-V предоставляют несколько разных сетевых режимов, позволяя выбрать наиболее подходящий для разных сетевых конфигураций. Windows Server Containers and Hyper-V containers offer a variety of networking modes to best suit the needs of differing networking configurations. Каждый из этих режимов оказывает определенное влияние на производительность. Each of these options present their own performance characteristics.

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

Каждый контейнер получает IP-адрес из внутреннего частного пространства IP-адресов (например, 172.16.0.0/12). Each container will receive an IP address from an internal, private IP prefix (e.g. 172.16.0.0/12). Перенаправление и сопоставление портов из узла контейнера в конечные точки контейнера поддерживается. Port forwarding / mapping from the container host to container endpoints is supported. При первом запуске dockerd подсистема Docker создает сеть NAT. Docker creates a NAT network by default when the dockerd first runs.

Из этих трех режимов конфигурация NAT больше других влияет на операции сетевого ввода-вывода, но требует меньшего объема настроек. Of these three modes, the NAT configuration is the most expensive network IO path, but has the least amount of configuration needed.

Для подключения к виртуальному коммутатору контейнеры Windows Server используют виртуальный сетевой адаптер узла. Windows Server containers use a Host vNIC to attach to the virtual switch. Для подключения к виртуальному коммутатору контейнеры Hyper-V используют сетевой адаптер синтетической виртуальной машины (не предоставляется служебной виртуальной машине). Hyper-V Containers use a Synthetic VM NIC (not exposed to the Utility VM) to attach to the virtual switch. Когда контейнеры обмениваются данными с внешней сетью, пакеты направляются через WinNAT с применением преобразования адресов, что влечет за собой дополнительные издержки. When containers are communicating with the external network, packets are routed through WinNAT with address translations applied, which incurs some overhead.

Прозрачный режим Transparent

Каждая конечная точка контейнера подключена напрямую к физической сети. Each container endpoint is directly connected to the physical network. IP-адреса из физической сети могут назначаться статически или динамически с помощью внешнего DHCP-сервера. IP addresses from the physical network can be assigned statically or dynamically using an external DHCP server.

Прозрачный режим наиболее экономичен с точки зрения сетевого ввода-вывода, так как внешние пакеты передаются напрямую на виртуальный сетевой адаптер контейнера, предоставляя прямой доступ к внешней сети. Transparent mode is the least expensive in terms of the network IO path, and external packets are directly passed through to the container virtual NIC giving direct access to the external network.

Мост второго уровня L2 Bridge

Каждая конечная точка контейнера будет находиться в той же IP-подсети, что и узел контейнера. Each container endpoint will be in the same IP subnet as the container host. IP-адреса должны назначаться статически из того же префикса, что и узел контейнера. The IP addresses must be assigned statically from the same prefix as the container host. Все конечные точки контейнера на узле будут иметь одинаковый MAC-адрес из-за преобразования адресов второго уровня. All container endpoints on the host will have the same MAC address due to Layer-2 address translation.

Режим моста второго уровня обеспечивает более высокую производительность, чем режим WinNAT, так как он предоставляет прямой доступ к внешней сети. При этом его производительность ниже по сравнению с прозрачным режимом, так как выполняется преобразование MAC-адресов. L2 Bridge Mode is more performant than WinNAT mode as it provides direct access to the external network, but less performant than Transparent mode as it also introduces MAC address translation.