Devido ao consumo elevado de recursos dos sistemas Windows, as distribuições Linux leves dominam os VPS: Mint, Colibri OS, Debian ou Ubuntu, que são livres de um ambiente de desktop pesado e desnecessário para nossas tarefas. Como se costuma dizer, apenas console, apenas hardcode! E na verdade, isso não é uma exagero: o próprio Debian inicia com 256 MB de memória e um núcleo com clock de 1 GHz, ou seja, quase em qualquer 'toco'. Para um funcionamento confortável, são necessários pelo menos 512 MB e um processador um pouco mais rápido. Mas e se dissermos que você pode conseguir algo semelhante em um VPS com Windows? Que não é necessário instalar o pesado Windows Server, que requer de três a quatro gigabytes de memória RAM e pelo menos alguns núcleos com clock de 1,4 GHz? Basta utilizar o Windows Server Core — livrando-se do GUI e de parte dos serviços. É sobre como fazer isso que iremos falar neste artigo.
Quem é esse tal de Windows Server Core?
Não há informações claras sobre o que é o Windows (server) Core nem mesmo no site oficial da Microsoft; para ser mais exato, lá tudo é tão confuso que não dá para entender de imediato, mas as primeiras menções datam da era do Windows Server 2008. Em essência, o Windows Core é o núcleo funcional do Windows Server (surpresa!), 'emagrecedor' pelo tamanho de seu próprio GUI e aproximadamente metade dos serviços secundários.
A principal característica do Windows Core é a baixa exigência de hardware e o gerenciamento completamente via console através do PowerShell.
Se você acessar o site da Microsoft e verificar os requisitos técnicos, para iniciar o Windows Server 2016/2019 você precisará de pelo menos 2 GB de memória RAM e pelo menos um núcleo com clock de 1,4 GHz. Mas todos nós entendemos que com essa configuração podemos esperar apenas o início do sistema, mas certamente não um funcionamento confortável do nosso SO. É exatamente por isso que, normalmente, se allocate mais memória para o Windows Server e pelo menos 2 núcleos/4 threads do processador, se não for possível, fornecendo uma cara máquina física em algum Xeon, em vez de uma barata virtual.
Ainda assim, o próprio núcleo do sistema servidor requer apenas 512 MB de memória, e os recursos da CPU que eram consumidos pelo GUI apenas para serem exibidos na tela e manter seus vários serviços em execução, podem ser usados para algo mais útil.
Aqui está uma comparação dos serviços suportados pelo Windows Core de maneira nativa e o Windows Server completo no site oficial da Microsoft:
application
server core
server comexperiência de desktop
Prompt de comando
disponível
disponível
Windows PowerShell/ Microsoft .NET
disponível
disponível
Perfmon.exe
não disponível
disponível
Windbg (GUI)
suportado
disponível
Resmon.exe
não disponível
disponível
Regedit
disponível
disponível
Fsutil.exe
disponível
disponível
Disksnapshot.exe
não disponível
disponível
Diskpart.exe
disponível
disponível
Diskmgmt.msc
não disponível
disponível
Devmgmt.msc
não disponível
disponível
Gerenciador do Servidor
não disponível
disponível
Mmc.exe
não disponível
disponível
Eventvwr
não disponível
disponível
Wevtutil (Consultas de eventos)
disponível
disponível
Services.msc
não disponível
disponível
Painel de Controle
não disponível
disponível
Windows Update (GUI)
não disponível
disponível
Windows Explorer
não disponível
disponível
Taskbar
não disponível
disponível
Notificações da barra de tarefas
não disponível
disponível
Taskmgr
disponível
disponível
Internet Explorer ou Edge
não disponível
disponível
Sistema de ajuda embutido
não disponível
disponível
Shell do Windows 10
não disponível
disponível
Windows Media Player
não disponível
disponível
PowerShell
disponível
disponível
PowerShell ISE
não disponível
disponível
PowerShell IME
disponível
disponível
Mstsc.exe
não disponível
disponível
Serviços de Área de Trabalho Remota
disponível
disponível
Gerenciador do Hyper-V
não disponível
disponível
Como pode ser visto, do Windows Core foram removidos muitos componentes. Foram eliminados serviços e processos relacionados à interface gráfica, assim como toda a 'tralha' que definitivamente não será necessária em nossa máquina virtual console, como o Windows Media Player.
Quase como o Linux, mas não é.
O Windows Server Core faz com que queiramos compará-lo com distribuições Linux, mas na verdade essa comparação não é totalmente correta. Sim, esses sistemas são semelhantes em termos de consumo reduzido de recursos devido à eliminação de GUI e muitos serviços secundários, mas em termos de uso e algumas abordagens de construção, ainda se trata do Windows, não de um sistema unix.
Um exemplo simples — com uma construção manual do núcleo Linux e instalação subsequente de pacotes e serviços, até mesmo a distribuição Linux mais leve pode ser transformada em algo pesado e parecido com um canivete suíço (aqui é tentador fazer uma piada sobre Python e incluir uma imagem da série 'Se Linguagens de Programação Fossem Armas', mas não o faremos). No Windows Core, essa liberdade é muito menor, pois lidamos com um produto Microsoft.
O Windows Server Core já vem com uma construção pronta, cuja configuração padrão pode ser avaliada na tabela acima. Se você precisar de algo da lista de componentes não suportados, terá que adicionar os elementos faltantes online através do console. No entanto, não podemos esquecer do Feature on demand e a possibilidade de baixar componentes como arquivos CAB, que podem ser adicionados à construção antes da instalação. Mas esse cenário não funciona se você já descobrir durante a operação que falta algum dos serviços removidos.
Mas o que distingue favoravelmente a versão Core da versão completa é a possibilidade de atualizar o sistema e adicionar serviços sem interromper o funcionamento. O Windows Core suporta a instalação de pacotes 'a quente', sem reiniciar. Como resultado, com base em observações práticas: a máquina rodando Windows Core precisa ser reiniciada cerca de 6 vezes menos frequentemente do que uma sob Windows Server, ou seja, uma vez a cada seis meses, em vez de uma vez por mês.
Um bônus agradável para os administradores é que, se o sistema for utilizado como pretendido — via console, sem RDP — e não se tornar um segundo Windows Server, ele se torna extremamente seguro em comparação com a versão completa. Afinal, a maioria das vulnerabilidades do Windows Server ocorre precisamente através do RDP e das ações do usuário que, por meio deste mesmo RDP, realiza ações que não deveriam ser feitas. É algo como a história de Henry Ford e sua relação com a cor do carro: "Qualquer cliente pode ter um carro pintado na cor que quiser, desde que seja preto". Assim também é com o sistema: o usuário pode se comunicar com o sistema de qualquer maneira, contanto que ele faça isso através da console.
Instalação e gerenciamento do Windows Server 2019 Core
Já mencionamos que o Windows Core é, na verdade, o Windows Server sem a camada de interface gráfica. Em outras palavras, você pode utilizar quase qualquer versão do Windows Server como uma versão core, ou seja, abrir mão da interface gráfica. Para os produtos da família Windows Server 2019, 3 das 4 versões de servidor: o modo core está disponível para Windows Server 2019 Standard Edition, Windows Server 2019 Datacenter e Hyper-V Server 2019, o que significa que apenas o Windows Server 2019 Essentials não está incluído nesta lista.
Além disso, o pacote de instalação do Windows Server Core não precisa ser procurado especificamente. Na instalação padrão da Microsoft, a versão core é oferecida literalmente por padrão, enquanto a versão com GUI deve ser selecionada manualmente:
Existem, na verdade, mais opções de gerenciamento do que a única mencionada PowerShell, que é a recomendada pelo fabricante por padrão. Você pode gerenciar uma máquina virtual no Windows Server Core de pelo menos cinco maneiras diferentes:
- PowerShell Remoto;
- Ferramentas de Administração Remota do Servidor (RSAT);
- Windows Admin Center;
- Sconfig;
- Gerenciador de Servidores.
As três primeiras opções são as mais interessantes: PowerShell padrão, RSAT e Windows Admin Center. No entanto, é importante entender que, ao obter as vantagens de uma das ferramentas, também recebemos suas limitações.
Não vamos detalhar as capacidades do console, PowerShell é PowerShell, com seus óbvios prós e contras. Com RSAT e WAC, a situação é um pouco mais complicada.
O WAC fornece acesso a elementos importantes de controle do sistema, como edição do registro e gerenciamento de discos e dispositivos. O RSAT, no primeiro caso, funciona apenas no modo de visualização e não permite realizar nenhuma alteração, enquanto para o gerenciamento de discos e dispositivos físicos, as Ferramentas de Administração Remota do Servidor precisam de uma interface gráfica, que não se aplica ao nosso caso. De maneira geral, o RSAT não pode lidar com arquivos e, consequentemente, atualizações, instalação/desinstalação de programas na edição do registro.
▍Gerenciamento do sistema
WAC
RSAT
Gerenciamento de componentes
Sim
Sim
Editor do registro
Sim
Não
Gerenciamento de rede
Sim
Sim
Visualização de eventos
Sim
Sim
Pastas compartilhadas
Sim
Sim
Gerenciamento de discos
Sim
Apenas para servidores com GUI
Agendador de tarefas
Sim
Sim
Gerenciamento de dispositivos
Sim
Apenas para servidores com GUI
Gerenciamento de Arquivos
Sim
Não
Gerenciamento de usuários
Sim
Sim
Gerenciamento de grupos
Sim
Sim
Gerenciamento de certificados
Sim
Sim
Atualizações
Sim
Não
Desinstalação de programas
Sim
Não
Monitoramento do sistema
Sim
Sim
Por outro lado, o RSAT nos dá controle total sobre os papéis na máquina, enquanto o Windows Admin Center não pode fazer nada nesse aspecto. Aqui está uma comparação das capacidades do RSAT e do WAC nesse aspecto, para visualização:
▍Gerenciamento de papéis
WAC
RSAT
Proteção Avançada contra Ameaças
PRÉ-VISÃO
Não
Windows Defender
PRÉ-VISÃO
Sim
Contêineres
PRÉ-VISÃO
Sim
Centro de Administração do AD
PRÉ-VISÃO
Sim
Domínios AD e Confianças
Não
Sim
Sites e serviços do AD
Não
Sim
DHCP
PRÉ-VISÃO
Sim
DNS
PRÉ-VISÃO
Sim
Gerenciador DFS
Não
Sim
Gerenciador GPO
Não
Sim
Gerenciador IIS
Não
Sim
Isso já mostra que, ao abrir mão da GUI e do PowerShell em favor de outros elementos de controle, não conseguiremos nos desvincular do uso de uma única ferramenta: para uma administração completa em todas as frentes, precisaremos, no mínimo, de uma combinação entre RSAT e WAC.
É importante lembrar que o uso do WAC custará entre 150 e 180 megabytes de memória RAM. O Windows Admin Center, ao se conectar, cria de 3 a 4 sessões no lado do servidor, que não podem ser encerradas mesmo ao desconectar a ferramenta da máquina virtual. Além disso, o WAC não funciona com versões antigas do PowerShell, então você precisará, no mínimo, do PowerShell 5.0. Tudo isso vai contra a nossa paradigma de economia rígida de recursos, mas conforto tem seu preço. No nosso caso — memória RAM.
Outra opção para gerenciar o Server Core é instalar uma GUI por meio de ferramentas de terceiros, evitando trazer as toneladas de lixo que vêm com uma montagem completa junto com a interface.
Neste caso, temos duas opções: instalar o Explorer original no sistema ou usar o Explorer++. Como alternativa ao último, qualquer gerenciador de arquivos serve: Total Commander, FAR Manager, Double Commander e assim por diante. O último é preferível se a economia de memória RAM for crítica para você. Adicionar o Explorer++ ou qualquer outro gerenciador de arquivos pode ser feito criando uma pasta de rede e executando através do console ou agendador.
Instalar um Explorer completo nos dará mais opções em termos de trabalhar com software equipado com UI. Para isso, precisamos ao recurso Server Core App Compatibility Feature on Demand (FOD), que trará de volta ao sistema o MMC, Eventvwr, PerfMon, Resmon, Explorer.exe e até mesmo o Powershell ISE. No entanto, isso terá um custo, assim como no caso do WAC: perderemos irreversivelmente cerca de 150-200 megabytes de RAM, que serão consumidos implacavelmente pelo explorer.exe e outros serviços. Mesmo que não haja um usuário ativo na máquina.
Assim é como o consumo de memória se apresenta em máquinas com o pacote nativo do Explorer e sem ele.
Aqui surge uma pergunta lógica: por que todas essas manobras com PowerShell, FOD, gerenciadores de arquivos, se qualquer passo para os lados resulta em um aumento do consumo de memória? Por que se envolver com uma infinidade de ferramentas e se mover de um lado para o outro para garantir um trabalho confortável no Windows Server Core, quando poderia simplesmente instalar o Windows Server 2016/2019 e viver como um ser humano?
Existem várias razões para usar o Server Core. A primeira: o consumo de memória é quase duas vezes menor. Se você se lembra, essa condição foi a base do nosso artigo desde o começo. Veja para comparação, o consumo de memória do Windows Server 2019, compare com os screenshots um pouco acima:
E aqui estão 1146 MB de memória consumidos em vez de 655 MB no Core.
Se presumirmos que o WAC não será necessário e que você usará o Explorer++ em vez do Explorer original, então você ainda estará ganhando quase meio hectare em cada máquina virtual que roda Windows Server. Se houver apenas uma VM, o ganho é insignificante, mas e se houver cinco? Neste caso, a presença de uma interface gráfica se torna relevante, especialmente se você não precisar dela.
O segundo ponto é que quaisquer tentativas de contornar o Windows Server Core não resolverão o problema principal da operação do Windows Server — RDP e sua segurança (mais precisamente, a total ausência dela). O Windows Core, mesmo com complementos como FOD, RSAT e WAC, ainda é um servidor sem RDP, ou seja, não está sujeito a 95% dos ataques existentes.
No restante
No geral, o Windows Core é apenas um pouco mais 'pesado' do que qualquer distribuição Linux padrão, mas muito mais funcional. Se você precisa liberar recursos e está disposto a trabalhar com o console, WAC e RSAT, e utilizar gerenciadores de arquivos em vez de uma GUI completa, então o Core merece sua atenção. Especialmente porque com ele você não precisará pagar por uma versão completa do Windows, e o dinheiro economizado pode ser investido em upgrades como , adicionando, por exemplo, mais RAM. Para sua conveniência, adicionamos o Windows Server Core ao nosso .
Fonte: habr.com
