Since the release of Windows Server 2016 there are now two “tracks” of Windows Server: the Semi-Annual Channel (SAC), which puts out two releases a year (Server Core with no GUI) and the Long-Term Servicing Channel (LTSC), which will come out every two to three years, just like Windows Server has for many years. When will it be released? Today 🙂
You need to have Software Assurance to use SAC releases, and they’re only supported for 18 months, whereas the LTSC releases will have the normal five years mainstream support (new features and bug fixes), followed by five years extended support (bug fixes only).
Windows Admin Center
First of all, Windows Server is complete without mentioning the free, Web-based Windows Admin Center (WAC), formerly known as “Project Honolulu.” It’s going to be the GUI for managing Windows Server, including Hyper-V servers, clusters, Storage Spaces Direct, and HCI clusters.
Speaking of clusters, most businesses I speak to tend to keep the number of nodes in their clusters relatively low ( eight, and 12 nodes), even though the max number of nodes is 64, and instead have more clusters. Each of these clusters is totally separate but that’s going to change in Windows Server 2019. You’ll be able to group several clusters together (Hyper-V, Storage, and even Hyper-Converged), with a Master cluster resource running on one cluster, coordinating with a Cluster Set Worker in each cluster. You’ll be able to Live Migrate VMs from one cluster to another. I can see this being useful for scaling out Azure Stack (currently limited to 12 nodes) and for bringing the concept of the Software-Defined Datacenter (SDDC) closer to reality.
Another minor but potentially vital detail is using a file share witness stored in DFS. This isn’t supported. Imagine a six-node cluster with three nodes in a separate building with a file share witness as the tiebreaker for the quorum. You could end up in a situation where the network connection between the two buildings is severed and the three nodes on one side keep the cluster service (and thus the VMs) running because they can talk to the file share witness. But the other side has a DFS replicated copy of the same file share witness, so they, too, decide to keep the cluster service running (as they also have a majority of votes) and both sides could potentially be writing to back-end storage simultaneously, leading to serious data corruption. In Windows Server 2019 if you try to store a file share witness in DFS you’ll get an error message and if it’s added to DFS replication at some point in time later, it’ll stop working. You can also create a file share witness that doesn’t use an AD account for scenarios where a DC isn’t available (DMZ), or in a workgroup/cross-domain cluster.
Storage Replica & Migration
In Windows Server 2016 (Datacenter only) we finally got the missing puzzle piece in Microsoft’s assault on SANs – Storage Replica (SR). In Windows Server 2019 Standard we’re getting SR “Lite“: a single volume per server (unlimited in Datacenter), a single partnership per volume (unlimited in Datacenter) and up to 2TB volumes (unlimited in Datacenters).
Hyper-V Replica is a different technology than SR. For instance, you could create a stretched Hyper-V cluster with SR as the transport mechanism for the underlying storage between the two locations and then use Hyper-V Replica for DR, replicating VMs to a third location or to Azure.
Storage Migration Service is coming in Windows Server 2019. Intended to solve the problem of migrating from older versions of Windows Server to 2019 or Azure, it’s not directly related to Hyper-V, although you can, of course, use it from within VMs or to migrate data to Azure Stack.
Data Deduplication is now available for Storage Spaces Direct (S2D) with the ReFS file system so you could be looking at saving up to 50 percent of disk space. Speaking of S2D, Microsoft now supports Persistent Memory (aka Storage Class Memory) which is essentially battery-backed DDR memory sticks, leading to storage with incredibly low latency. Also new is performance history for S2D, where you can get a history of performance across drives, NICs, servers, VMs, vhd/vhdx files, volumes, and the overall cluster. You can either use PowerShell or Windows Admin Center to access the data.
But the coolest feature yet is the ability to run Linux containers on Windows Server. Remember that in Windows (unlike Linux) we have two flavors of containers, Windows Containers, and Hyper-V Containers. For a developer, they work exactly the same and it’s a deployment choice (develop on normal containers and deploy in production in Hyper-V containers). The Hyper-V flavor gives you the security isolation of a VM although they’re much smaller than a “real” VM.
Now, there’s still plenty to do, it’s time again to wipe the dust from old servers (i have 2 of 2008 edition) to finally make myself do this long-awaited update and migration I’ve been avoiding for many months.