Ajustando o desempenho dos contêineres do Windows Server

Introduction

A partir do Windows Server 2022, dois tipos de contêineres estão disponíveis: Contêineres do Windows Server e Contêineres do Hyper-V. Cada tipo de contêiner suporta o Server Core ou o Nano Server SKU do Windows Server 2022.

Essas configurações têm diferentes implicações de desempenho, que detalhamos abaixo para ajudá-lo a entender o que é certo para seus cenários. Além disso, detalhamos as configurações que afetam o desempenho e descrevemos as compensações com cada uma dessas opções.

Contêiner do Windows Server e contêineres Hyper-V

O Contêiner do Windows Server e os contêineres Hyper-V oferecem muitos dos mesmos benefícios de portabilidade e consistência, mas diferem em termos de isolamento, garantias e características de desempenho.

Os Contêineres do Windows Server fornecem isolamento de aplicativos por meio da tecnologia de isolamento de processos e namespaces. Um contêiner do Windows Server compartilha um kernel com o host do contêiner e todos os contêineres em execução no host.

Hyper-V Contêineres expandem o isolamento fornecido pelos Contêineres do Windows Server executando cada contêiner em uma máquina virtual altamente otimizada. Nessa configuração, o kernel do host do contêiner não é compartilhado com os contêineres Hyper-V.

O isolamento extra fornecido por Hyper-V contêineres é alcançado em grande parte por uma camada de isolamento do hipervisor entre o contêiner e o host do contêiner. Isso afeta a densidade do contêiner, pois, ao contrário dos contêineres do Windows Server, menos compartilhamento de arquivos do sistema e binários pode ocorrer, resultando em um armazenamento geral maior e espaço de memória. Além disso, espera-se uma sobrecarga adicional em alguns caminhos de rede, de E/S de armazenamento e de CPU.

Nano Server e Server Core

Os Contêineres do Windows Server e os Contêineres do Hyper-V oferecem suporte para o Server Core, saiba mais sobre as opções de imagem base do contêiner.

Nano Server é um sistema operacional de servidor administrado remotamente otimizado para nuvens privadas e datacenters. É semelhante ao Windows Server no modo Server Core, mas significativamente menor, não tem capacidade de logon local e suporta apenas aplicativos, ferramentas e agentes de 64 bits. Ele ocupa muito menos espaço em disco, configura significativamente mais rápido e requer muito menos atualizações e reinicializações do que o Windows Server. Quando ele reinicia, ele reinicia muito mais rápido.

Tempo do contentor Start-Up

O tempo de inicialização do contêiner é uma métrica chave em muitos dos cenários em que os contêineres oferecem o maior benefício. Como tal, entender como otimizar melhor o tempo de inicialização do contêiner é fundamental. Abaixo estão algumas compensações de ajuste para entender para alcançar um melhor tempo de arranque.

Primeiro Logon

A Microsoft envia uma imagem base para o Nano Server e o Server Core. A imagem base fornecida para o Server Core foi otimizada removendo a sobrecarga de tempo de inicialização associada ao primeiro logon (OOBE). Este não é o caso da imagem base do Nano Server. No entanto, esse custo pode ser removido das imagens baseadas no Nano Server ao integrar pelo menos uma camada dentro da imagem de contêiner. O contêiner subsequente iniciado a partir da imagem não incorrerá no primeiro custo de logon.

Localização do Scratch Space

Os contentores, por defeito, usam um espaço de trabalho temporário no disco do sistema do host do contentor para armazenamento durante a duração do contentor em execução. Isso serve como a unidade do sistema do contentor e, como tal, muitas das escritas e leituras realizadas durante a operação do contentor seguem esse caminho. Para sistemas anfitriões onde a unidade do sistema existe em mídia magnética de disco giratório (HDDs), mas mídias de armazenamento mais rápidas estão disponíveis (HDDs mais rápidos ou SSDs), é possível mover o espaço temporário do contêiner para uma unidade diferente. Isso é conseguido usando o comando dockerd –g. Esse comando é global e afetará todos os contêineres em execução no sistema.

Contêineres Hyper-V aninhados

Hyper-V para Windows Server 2022 oferece suporte a hipervisor aninhado. Ou seja, a capacidade de executar uma máquina virtual de dentro de uma máquina virtual. Isso abre muitos cenários úteis, mas também exagera algum impacto no desempenho que o hipervisor incorre, pois há dois níveis de hipervisores em execução acima do host físico.

Para contêineres, isso tem um impacto ao executar um contêiner Hyper-V dentro de uma máquina virtual. Como um container Hyper-V oferece isolamento por meio de uma camada de hipervisor entre si e o host de container, quando o host de container é uma máquina virtual baseada em Hyper-V, existe uma sobrecarga de performance associada em termos de tempo de inicialização do container, E/S de armazenamento, E/S de rede, taxa de transferência e CPU.

Armazenamento

Volumes de dados montados

Os contentores oferecem a capacidade de usar a unidade do sistema host do contentor para o espaço temporário do contentor. No entanto, o espaço de risco do recipiente tem uma vida útil igual à do recipiente. Ou seja, quando o contentor é parado, o espaço temporário e todos os dados associados se desvanecem.

No entanto, há muitos cenários em que é desejável que os dados persistam independentemente do tempo de vida do contêiner. Nesses casos, oferecemos suporte à montagem de volumes de dados do host do contêiner para o contêiner. Para contentores do Windows Server, existe uma sobrecarga insignificante no caminho de I/O associada a volumes de dados montados (com desempenho quase nativo). No entanto, ao montar volumes de dados em contêineres Hyper-V, há alguma degradação do desempenho de E/S nesse caminho. Além disso, esse impacto é exagerado ao executar contêineres Hyper-V dentro de máquinas virtuais.

Espaço Scratch

Os contentores do Windows Server e os contentores Hyper-V fornecem um VHD dinâmico de 20 GB para o espaço de scratch do contentor por padrão. Para ambos os tipos de contêiner, o sistema operacional do contêiner ocupa uma parte desse espaço, e isso é verdadeiro para cada contêiner iniciado. Assim, é importante lembrar que cada contêiner iniciado tem algum impacto no armazenamento e, dependendo da carga de trabalho, pode gravar até 20 GB da mídia de armazenamento de backup. As configurações de armazenamento do servidor devem ser projetadas com isso em mente.

Rede

Os contêineres do Windows Server e os contêineres do Hyper-V oferecem vários modos de rede para melhor atender às necessidades de diferentes configurações de rede. Cada uma destas opções apresenta as suas próprias características de desempenho.

Conversão de endereços de rede do Windows (WinNAT)

Cada contêiner receberá um endereço IP de um prefixo IP interno e privado (por exemplo, 172.16.0.0/12). Há suporte para encaminhamento/mapeamento de portas do host do contêiner para os pontos de extremidade do contêiner. O Docker cria uma rede NAT por padrão quando o dockerd é executado pela primeira vez.

Desses três modos, a configuração NAT é o caminho de E/S de rede mais caro, mas tem a menor quantidade de configuração necessária.

Os contêineres do Windows Server usam uma vNIC de host para se conectar ao comutador virtual. Hyper-V Os contêineres usam uma NIC de VM sintética (não exposta à VM do utilitário) para se conectar ao comutador virtual. Quando os contêineres estão se comunicando com a rede externa, os pacotes são roteados através do WinNAT com traduções de endereços aplicadas, o que incorre em alguma sobrecarga.

Transparent

Cada ponto de extremidade de contêiner é conectado diretamente à rede física. Os endereços IP da rede física podem ser atribuídos estática ou dinamicamente usando um servidor DHCP externo.

O modo transparente é o menos dispendioso em termos do caminho de E/S da rede, e os pacotes externos são passados diretamente para a NIC virtual do contêiner, dando acesso direto à rede externa.

Ponte L2

Cada ponto de extremidade de contêiner estará na mesma sub-rede IP que o host do contêiner. Os endereços IP devem ser atribuídos estaticamente a partir do mesmo prefixo que o host do contêiner. Todos os pontos de extremidade de contêiner no host terão o mesmo endereço MAC devido à conversão de endereços de camada 2.

O modo de ponte L2 é mais eficiente do que o modo WinNAT, pois fornece acesso direto à rede externa, mas menos eficiente do que o modo transparente, pois também introduz a conversão de endereços MAC.