A causa della pesantezza dei sistemi Windows, negli ambienti VPS dominano le leggere distribuzioni Linux: Mint, Colibri OS, Debian o Ubuntu, prive di un ambiente desktop pesante e superfluo per i nostri compiti. Come si suol dire, solo console, solo hardcore! E in effetti, non è affatto un'esagerazione: lo stesso Debian si avvia con 256 MB di RAM e un core a 1 GHz, praticamente su qualsiasi "ceppo". Per un utilizzo confortevole servono almeno 512 MB e un processore un po' più veloce. Ma cosa direste se vi dicessimo che è possibile fare qualcosa di simile su VPS con Windows? Che non è necessario installare il pesante Windows Server, che richiede da tre a quattro giga di RAM e almeno un paio di core a 1,4 GHz? Basta usare Windows Server Core – eliminando l'interfaccia grafica e parte dei servizi. Di come farlo, parleremo nell'articolo.
Chi è questo Windows Server Core?
Non ci sono informazioni chiare su cosa sia Windows (server) Core, nemmeno sul sito ufficiale di Microsoft; anzi, è tutto così complicato che non si capisce subito. Tuttavia, le prime menzioni risalgono all'epoca di Windows Server 2008. Fondamentalmente, Windows Core è il nucleo operativo di Windows Server (sorpresa!), 'snellito' del proprio GUI e di circa la metà dei servizi accessori.
La caratteristica principale di Windows Core è la sua bassa esigenza hardware e la gestione completamente tramite console tramite PowerShell.
Se vai sul sito di Microsoft e controlli i requisiti tecnici, per avviare Windows Server 2016/2019 avrai bisogno di almeno 2 gigabyte di RAM e di un minimo di un core a una velocità di 1,4 GHz. Ma tutti noi sappiamo che con tale configurazione possiamo aspettarci solo l'avvio del sistema e non una fruizione confortevole del nostro OS. Proprio per questo motivo, per l'uso di Windows Server si tende a riservare più memoria e almeno 2 core/4 thread del processore, se non si fornisce addirittura una costosa macchina fisica con qualche Xeon, invece di una cheap virtual machine.
Il nucleo del sistema server richiede solo 512 MB di memoria, e le risorse della CPU, che venivano allocate dal GUI solo per essere visualizzate sullo schermo e mantenere attivi i suoi numerosi servizi, possono essere utilizzate per qualcosa di più utile.
Ecco un confronto tra i servizi supportati di default da Windows Core e la versione completa di Windows Server, disponibile sul sito ufficiale di Microsoft:
applicazione
server core
server conesperienza desktop
Prompt dei comandi
disponibile
disponibile
Windows PowerShell/ Microsoft .NET
disponibile
disponibile
Perfmon.exe
non disponibile
disponibile
Windbg (GUI)
supportato
disponibile
Resmon.exe
non disponibile
disponibile
Regedit
disponibile
disponibile
Fsutil.exe
disponibile
disponibile
Disksnapshot.exe
non disponibile
disponibile
Diskpart.exe
disponibile
disponibile
Diskmgmt.msc
non disponibile
disponibile
Devmgmt.msc
non disponibile
disponibile
Server Manager
non disponibile
disponibile
Mmc.exe
non disponibile
disponibile
Eventvwr
non disponibile
disponibile
Wevtutil (Query eventi)
disponibile
disponibile
Services.msc
non disponibile
disponibile
Pannello di controllo
non disponibile
disponibile
Windows Update (GUI)
non disponibile
disponibile
Esplora file di Windows
non disponibile
disponibile
Barra delle applicazioni
non disponibile
disponibile
Notifiche della barra delle applicazioni
non disponibile
disponibile
Taskmgr
disponibile
disponibile
Internet Explorer o Edge
non disponibile
disponibile
Sistema di aiuto integrato
non disponibile
disponibile
Shell di Windows 10
non disponibile
disponibile
Windows Media Player
non disponibile
disponibile
PowerShell
disponibile
disponibile
PowerShell ISE
non disponibile
disponibile
PowerShell IME
disponibile
disponibile
Mstsc.exe
non disponibile
disponibile
Servizi desktop remoto
disponibile
disponibile
Hyper-V Manager
non disponibile
disponibile
Come si può notare, da Windows Core sono stati rimossi molti componenti. Sono stati eliminati i servizi e i processi legati al GUI del sistema, nonché tutta una serie di 'rifiuti' che sicuramente non serviranno sulla nostra VM console, come Windows Media Player.
Quasi come Linux, ma non lo è
Windows Server Core è spesso paragonato ai sistemi Linux, ma in realtà non è del tutto corretto. Sì, questi sistemi sono simili in termini di ridotto consumo di risorse grazie all'assenza di GUI e a molteplici servizi secondari, ma per quanto riguarda l'uso e alcuni approcci alla configurazione, si tratta comunque di Windows e non di un sistema Unix.
Il più semplice esempio è che, con una compilazione manuale del kernel Linux e l'installazione successiva di pacchetti e servizi, anche la distribuzione Linux più leggera può diventare qualcosa di pesante e simile a un coltellino svizzero (qui ci verrebbe voglia di fare una battuta su Python e di inserire un'immagine della serie «If Programming Languages Were Weapons», ma non lo faremo). In Windows Core questa libertà è notevolmente ridotta, poiché abbiamo a che fare con un prodotto Microsoft.
Windows Server Core viene fornito già come un'installazione preconfigurata, la cui configurazione predefinita può essere valutata dalla tabella sopra. Se hai bisogno di qualcosa dall'elenco non supportato, dovrai aggiungere i componenti mancanti tramite la console online. Tuttavia, non dimenticare la funzionalità Feature on demand e la possibilità di scaricare i componenti come file CAB, che possono poi essere aggiunti all'installazione prima della configurazione. Ma questo scenario non funziona se ti accorgi di aver bisogno di uno dei servizi rimossi mentre sei già in fase operativa.
Ma ciò che distingue favorevolmente la versione Core dalla versione completa è la possibilità di aggiornare il sistema e aggiungere servizi senza interrompere il funzionamento. Windows Core supporta l'installazione di pacchetti "a caldo", senza riavvio. Come conseguenza, in base all'osservazione pratica: una macchina che esegue Windows Core richiede di essere riavviata circa 6 volte meno frequentemente rispetto a quella che esegue Windows Server, cioè una volta ogni sei mesi invece di una volta al mese.
Un vantaggio per gli amministratori è che se il sistema viene utilizzato come previsto - tramite console, senza RDP - e non si trasforma in un secondo Windows Server, diventa estremamente sicuro rispetto alla versione completa. Infatti, la maggior parte delle vulnerabilità di Windows Server riguarda proprio RDP e le azioni degli utenti che, attraverso questo protocollo, compiono operazioni che non dovrebbero. È un po' come nella storia di Henry Ford e la sua opinione sul colore delle automobili: «Qualsiasi cliente può avere un'auto verniciata di qualsiasi colore desideri, purché sia nera». Allo stesso modo, con il sistema: l'utente può interagire con il sistema in qualsiasi modo, purché lo faccia tramite console.
Installazione e gestione di Windows Server 2019 Core
In precedenza abbiamo menzionato che Windows Core è, di fatto, Windows Server senza l'interfaccia grafica. Quindi, è possibile utilizzare quasi qualsiasi versione di Windows Server come versione core, rifiutando così l'interfaccia grafica. Per i prodotti della famiglia Windows Server 2019, 3 delle 4 build server sono disponibili in modalità core: la modalità core è accessibile per Windows Server 2019 Standard Edition, Windows Server 2019 Datacenter e Hyper-V Server 2019, pertanto l'unica esclusa da questo elenco è Windows Server 2019 Essentials.
Non è necessario cercare particolarmente il pacchetto di installazione di Windows Server Core. Nella normale installazione di Microsoft, la versione core è proposta praticamente di default, mentre la versione con GUI deve essere selezionata manualmente:
In realtà, ci sono più opzioni per la gestione del sistema rispetto a quella menzionata di PowerShell, che è quella proposta dal produttore per impostazione predefinita. È possibile gestire una macchina virtuale su Windows Server Core in almeno cinque modi diversi:
- PowerShell Remoto;
- Strumenti di Amministrazione Remota del Server (RSAT);
- Windows Admin Center;
- Sconfig;
- Server Manager.
Le prime tre opzioni sono di particolare interesse: PowerShell standard, RSAT e Windows Admin Center. Tuttavia, è importante comprendere che, ottenendo i vantaggi di uno degli strumenti, ci troviamo anche di fronte ai limiti che comporta.
Non discuteremo le funzionalità della console, PowerShell è PowerShell, con i suoi evidenti pro e contro. Ma con RSAT e WAC la situazione è un po' più complessa.
WAC fornisce accesso a controlli di sistema fondamentali, come la modifica del registro e la gestione di dischi e dispositivi. RSAT, nel primo caso, funziona solo in modalità di visualizzazione e non consentirà di apportare modifiche, mentre per gestire dischi e dispositivi fisici, gli strumenti di amministrazione remota dei server necessitano di un'interfaccia GUI, che non si applica nel nostro caso. In generale, RSAT non può gestire file e, di conseguenza, aggiornamenti, installazione/rimozione di programmi o la modifica del registro.
▍Gestione del sistema
WAC
RSAT
Gestione dei componenti
Sì
Sì
Editor del registro
Sì
No
Gestione della rete
Sì
Sì
Visualizzazione eventi
Sì
Sì
Cartelle condivise
Sì
Sì
Gestione dischi
Sì
Solo per server con GUI
Pianificatore attività
Sì
Sì
Gestione dei dispositivi
Sì
Solo per server con GUI
Gestione file
Sì
No
Gestione utenti
Sì
Sì
Gestione gruppi
Sì
Sì
Gestione certificati
Sì
Sì
Aggiornamenti
Sì
No
Rimozione programmi
Sì
No
Monitor di sistema
Sì
Sì
D'altra parte, RSAT ci offre un controllo completo sui ruoli della macchina, mentre Windows Admin Center non può fare letteralmente nulla in questo ambito. Ecco un confronto delle funzionalità di RSAT e WAC in questo aspetto, per chiarezza:
▍Gestione ruoli
WAC
RSAT
Advanced Thread Protection
ANTEPRIMA
No
Windows Defender
ANTEPRIMA
Sì
Container
ANTEPRIMA
Sì
AD Administrative Center
ANTEPRIMA
Sì
AD Domain and Trusts
No
Sì
AD sites and services
No
Sì
DHCP
ANTEPRIMA
Sì
DNS
ANTEPRIMA
Sì
Gestore DFS
No
Sì
Gestore GPO
No
Sì
Gestore IIS
No
Sì
Quindi è già evidente che rinunciare a GUI e PowerShell a favore di altri elementi di controllo non permetterà di utilizzare un singolo strumento: per una gestione completa su tutti i fronti avremo bisogno almeno di un'accoppiata di RSAT e WAC.
È importante ricordare che l'utilizzo di WAC comporterà un consumo di 150-180 megabyte di RAM. Windows Admin Center, quando si collega, crea 3-4 sessioni sul lato server, che non vengono terminate nemmeno quando lo strumento viene disconnesso dalla macchina virtuale. Inoltre, WAC non funziona con le versioni obsolete di PowerShell, quindi avrete bisogno almeno di PowerShell 5.0. Tutto questo contrasta con la nostra filosofia di severa economia delle risorse, ma per il comfort bisogna pagare. Nel nostro caso, si tratta di memoria RAM.
Un'altra opzione per gestire Server Core è l'installazione di GUI tramite strumenti di terze parti, per evitare di portare con sé le tonnellate di spazzatura che vengono incluse in un'installazione completa con interfaccia.
In questo caso abbiamo due opzioni: installare il sistema originale di Explorer oppure utilizzare Explorer++. Come alternativa all'ultimo, qualsiasi gestore di file va bene: Total Commander, FAR Manager, Double Commander e così via. Quest'ultimo è preferibile se per voi è fondamentale risparmiare memoria RAM. Potete aggiungere Explorer++ o qualsiasi altro gestore di file creando una cartella di rete e avviando tramite console o pianificatore.
L'installazione di un Explorer completo ci darà più opportunità per quanto riguarda il lavoro con software dotato di UI. Per fare ciò, alla funzione Server Core App Compatibility Feature on Demand (FOD) che restituirà al sistema MMC, Eventvwr, PerfMon, Resmon, Explorer.exe e persino Powershell ISE. Tuttavia, questo avrà un costo, come nel caso di WAC: perderemo permanentemente circa 150-200 megabyte di memoria RAM, che verrà sprecata da explorer.exe e altri servizi. Anche se non ci sono utenti attivi sulla macchina.
Ecco come appare il consumo di memoria del sistema su macchine con il pacchetto originale di Explorer e senza di esso.
Qui sorge una domanda legittima: a cosa servono tutte queste manovre con PowerShell, FOD, e i gestori di file, se ogni passo a sinistra o a destra porta a un aumento del consumo di memoria? Perché affollarsi di strumenti e spostarsi da una parte all'altra per garantire un'esperienza di lavoro confortevole su Windows Server Core, quando si può semplicemente installare Windows Server 2016/2019 e vivere come una persona normale?
Ci sono diverse ragioni per utilizzare Server Core. La prima: un consumo di memoria quasi dimezzato. Se ricordi, questa condizione era alla base del nostro articolo sin dall'inizio. Ecco un confronto del consumo di memoria di Windows Server 2019, confronta con gli screenshot qui sopra:
E così, 1146 MB di memoria consumata invece di 655 MB su Core.
Se si presume che WAC non ti serva e utilizzerai Explorer++ invece dell'originale Explorer, allora tu guadagnerai comunque quasi mezzo ettaro su ogni macchina virtuale che utilizza Windows Server. Se c'è solo una macchina virtuale, l'incremento è insignificante, ma se ce ne sono cinque? Qui la presenza di un'interfaccia grafica diventa rilevante, soprattutto se non ti serve.
In secondo luogo, qualsiasi tentativo di manovra attorno a Windows Server Core non risolverà il problema principale dell'operatività di Windows Server: RDP e la sua sicurezza (o meglio, la totale assenza di essa). Windows Core, anche con la patch di FOD, RSAT e WAC, rimane un server senza RDP, quindi non è vulnerabile al 95% degli attacchi esistenti.
In sintesi
In generale, Windows Core è solo leggermente "più pesante" rispetto a qualsiasi distribuzione Linux stock, ma molto più funzionale. Se hai bisogno di liberare risorse e sei disposto a lavorare con la console, WAC e RSAT, utilizzando gestori di file al posto di un'interfaccia grafica completa, vale la pena considerare Core. Inoltre, con essa puoi risparmiare sui costi di una Windows completa e investire i soldi risparmiati nell'upgrade della tua , aggiungendo, ad esempio, RAM. Per comodità, abbiamo aggiunto Windows Server Core al nostro .
Fonte: habr.com
