Windows Server 1709: What’s New

Windows Server

Il 17 ottobre è stata rilasciata una nuova release di Windows Server, conosciuta inizialmente come RS3 (Red Stone 3), in contemporanea con l’uscita della nuova build di Windows 10. Ecco cosa c’è di nuovo in questa nuova build e soprattutto come cambia l’approccio di Microsoft nei confronti del mondo server.

Naming

Contrariamente a quanto si legge erroneamente su alcuni siti web, la nuova build di Windows Server si chiama semplicemente Windows Server con l’aggiunta della versione della build, quindi, per questa versione, si tratta di Windows Server version 1709 (e non Windows Server 2016 1709). Windows Server 2016 rimane la build classificata LTSC e l’unica disponibile tramite i canali OEM e retail.

Semi-Annual Channel

Al pari di Windows 10, che vede il rilascio di una nuova build ogni 6 mesi, anche Windows Server si adatta allo stesso modello di business con però diverse differenze. L’obiettivo è molto semplice: offrire un sistema operativo che segua l’esigenze del mercato e che non obblighi le aziende ad aspettare 3 anni; inoltre Microsoft Azure è basato su tecnologia Windows Server e quindi è necessario avere una piattaforma che evolva rapidamente, senza dover fare il doppio degli sforzi. La figura 1 mostra le novità relative alla SAC, da notare che il prodotto è disponibile solo tramite Software Assurance, che non esiste interfaccia grafica e che il supporto è garantito solo per 18 mesi dalla data di rilascio.

Figura 1 – SAC

Windows Server 2016, come detto in precedenza, è la build attualmente classificata come Long Term, ovvero la build che offre un’interfaccia grafica completa ma soprattutto il supporto per 5 anni + 5 anni (estesi) con l’opzione di avere altri 6 anni con il pacchetto Premium Assurance (disponibile per Windows Server e SQL Server).

La figura 2 mostra la roadmap stimata per il rilascio delle prossime release e non ci vuole molto per intuire che la next build LTSC sarà rilasciata ad ottobre 2018 (il nome potrebbe essere Windows Server 2019).

Figura 2 – Roadmap

Lo Scopo della 1709

Se qualcuno pensa che Windows Server 1709 sia per tutti, si sbaglia. Microsoft è stata molto chiara su qual è lo scopo primario di questa nuova build, ovvero i container e quindi Docker. Pensare di adottare la 1709 per altri scopi è molto forzato, anche perchè, come vedremo tra poco, sono state fatte delle limitazioni volute su alcune feature.

Questa cosa è avvalorata dal fatto che System Center, che anch’esso seguirà il ciclo del Semi-Annual Channel, non è stato rilasciato al pubblico ma lo sarà in concomitanza con la 1803.

Upgrade In-Place?

Avete una macchina con IIS a bordo e volete fare l’upgrade alla 1709? No way! L’upgrade in-place non è previsto e tanto meno supportato, l’unico modo per avere la build è un’installazione da zero. Questo anche perchè il nuovo sistema operativo è solo Server Core e quindi la gestione può avvenire solo via cmd o PowerShell.

No Storage Spaces Direct

Tra i tagli di feature fatti, troviamo quello dello Storage Spaces Direct (S2D) che nella 1709 è stato disabilitato a livello di codice; nel caso vogliate provare ad attivarlo, riceverete un errore di tipo “The requested operation is not supported“; inoltre non è possibile aggiungere un nodo basato su 1709 all’interno di un’infrastruttura S2D. Insomma, se avete questo tipo di esigenza rimane d’obbligo usare Windows Server 2016. Anche in ottica Hyperconverged, la 1709 non è utilizzabile e quindi bisogna rimanere su Windows Server 2016.

Storage Spaces Direct sarà riportato in pista con la RS4, prevista per marzo del 2018.

Bye Bye Nano Server

Un altro degli “addii” che la nuova build di Windows Server ha portato in dote, è la ricalibrazione di Nano Server. Inizialmente la SKU era stata pensata per ambienti di virtualizzazione e per il mondo container, grazie ad un footprint veramente basso ed una velocità di deployment incredibile. Pare che il pubblico non abbia molto gradito questa versione di Windows e quindi Microsoft ha deciso di eliminare la SKU Nano Server per il mondo Hyper-V e renderla disponibile solo come container Docker.

Il risultato di questa ottimizzazione si traduce in una riduzione di peso dei bit, che passa dal precedente 1GB, di Windows Server 2016, ai 200MB di Windows Server v1709. Qualora abbiate implementato Nano Server in produzione, magari come File Server, iniziate a valutare la migrazione sapendo già che non è previsto un upgrade a versione più evolute.

Windows Subsystem for Linux

Come già trattato in questo precedente articolo (Windows Server RS3: Configurare Windows Subsystem for Linux), anche Windows Server ha la possibilità di utilizzare il kernel Linux e questo apre scenari incredibili di modularità ma soprattutto di flessibilità, dati dall’avere un solo sistema operativo di base con filosofie diverse al suo interno.

Docker Power!

Docker è il punto cardine della 1709, tutto è stato fatto in funzione di Docker e quindi è normale che gli investimenti più grandi riguardano quest’area, tra cui troviamo:

  • Supporto ai container Linux (vale già il prezzo del biglietto)
  • Supporto ai volumi su share SMB
  • Supporto ai Routing Mesh (ottimo per chi lavora in ambienti di Swarm)
  • Supporto ai Named pipes
  • Supporto a Kubernetes
  • Ottimizzazione delle immagini Nano Server e Windows Server Core

Di Docker avremo modo di trattare meglio l’argomento, spezzando alcuni punti con articoli dedicati.

Hyper-V Improvements

Anche Hyper-V riceve alcune nuove funzionalità, tra cui:

  • Supporto alle Shielded VM anche per Linux
  • Introduzione alla Virtualized Persistent Memory (vPMEM)
  • Introduzione alla Virtual Network Encryption – per creare un canale di comunicazione tra le varie VM, attraverso il Datagram Transport Layer Security

Virtualized Persistent Memory

La Persistent Memory è una tecnologia di nuova generazione che si basa su NVDIMM-N, presenti solo sui server di nuova generazione, che permette di avere una tecnologia Storage Class Memory al fine di ottenere performance incredibilmente elevate, mirate a workload che fanno un uso intensivo di risorse. La logica dietro alle NVDIMM-N è quella di avere banchi di memoria che però non sono volatili e che sono collegate direttamente al bus della scheda madre, cosa che salta tutti i colli i bottiglia. I tempi di accesso si aggirano attorno ai 150 nano secondi (un disco NVMe si attesa attorno ai 60000 ns). La Persistent Memory è compatibile con Windows Server 2016, RHEL 7.3 e prossimamente con VMware.

In Hyper-V, all’interno di Windows Server 1709, la funzionalità è stata estesa anche alle virtual machine (da qui il nome Virtualized Persistent Memory) e quindi abbiamo la possibilità di demandare questa potenza alla nostra VM, tramite un file .vhdpmem che si trova all’interno dell’host di virtualizzazione. Ovviamente questa tecnologia ha una serie di limiti, come il fatto che non è possibile fare la migrazione della VM, non è supportata in Windows Server 2016, non è possibile fare Snapshot e che la gestione è possibile solo tramite PowerShell.

Data Deduplication

Una feature mancante in Windows Server 2016, relativamente a ReFS, era il supporto della Data Deduplication, cosa che obbligava le aziende a ripiegare su NTFS per ottimizzare lo spazio dei dischi (specie in ambito di File Server). La v1709 offre la possibilità di usare volumi formattati in ReFS e di sfruttare anche le potenzialità della Data Deduplication.

Management

Non ha niente a che vedere con la 1709 ma uno degli obiettivi di Microsoft è quello di rimpiazzare tutte le varie console di gestione sparse all’interno di Windows Server, alcune di queste molto obsolete come UI. La risposta al problema è chiamata Project Honolulu (Arriva Honolulu: la nuova era del Server Management), ovvero la nuova console basata su HTML5 che permette di gestione buona parte dei ruoli e servizi dei nostri server, grazie ad un’interfaccia molto pulita e ben strutturata.

Conclusioni

Come abbiamo visto, il prodotto è sì un’evoluzione di Windows Server 2016 ma si rivolge ad un mercato ben preciso e quindi per ora la necessità di fare un’upgrade è veramente limitato….a meno che non abbiate iniziato a lavorare in ambito Docker e non vogliate sfruttare la possibilità di far convergere il mondo Windows e quello Linux in un solo sistema operativo.