Getting Started with Nano Server: Automate multiple VMs and transform your datacenter

Microsoft is always listening to customer's feedback, and one constant feedback was server reboots are impacting my business, because, when you reboot a server, you need to plan ahead of time and schedule a maintenance window in order to avoid downtime. The next piece of feedback was, why do I have to reboot a server because of a patch to a certain component that I never use on my server? And if a reboot is required, the systems need to be back in service as soon as possible. The constant feedback was, we just want the components needed to accomplish our goals and nothing more.

The size of server images have increased over time; large server images take a long time to deploy and configure, especially when you work with virtual machines.

Storing and maintaining virtual machine templates requires too much disk space, when it comes to mobility by moving virtual machines around using live migration. Thus, it will require a lot of network bandwidth as well.

With full blown server images, the infrastructure requires too many resources; if the operating system consumes fewer resources, you can increase virtual machines' density, and with higher VM density, you can lower the cost and increase efficiency in your environment.

IT security is no longer just about protecting your computers and minimizing potential downtime and lost productivity. It's about protecting your valuable business data, your customers' personal details, and your company's reputation. We saw the headlines in the last couple of years about online attacks and credit card numbers being stolen. There was a 40% increase in the number of large companies targeted by cyber-attacks in 2014, as criminals hijack infrastructures and attack from within, according to the largest cybersecurity companies research; a cyberattack has even caused confirmed physical damage for the second time ever. As an example, a hacker was able to remotely control a vehicle and shut it down. Security has become a number one priority in every firm today.

We can no longer afford the security risks of the install everything, everywhere approach.

Basically, having a large server installation that has a lot of things installed, that you don't necessarily really need, opens you up to more of these attacks. The less you have installed on your server, the less ports you have to open. This in turn reduces the ways a hacker can try to attack your systems. So that's really sort of the area that Microsoft took the lead on and created the genesis of Nano Server.

The big change occurred in Windows Server 2008 and Microsoft introduced Windows Server Core as an installation option. This was really the first step toward having to deploy less on your servers, have less that you have to patch and reboot, and have fewer components that you don't necessary need on your servers. What I mean by the installation option is, when you first start installing the operating system, you have the option to choose between Server Core or Server with Desktop Experience installation.

Once you deploy Server Core or Server with Desktop Experience, then you can start adding roles and features that you want to run on top as shown in Figure 1, small boxes on top.

For Windows Server 2008 and Windows Server 2008 R2, the choice between Server Core and a full installation had to be made at installation time and couldn't be changed without reinstalling the OS:

Figure 1: Windows NT - Windows Server 2012 R2 journey (image source: Microsoft)

However, with Windows Server 2012 and 2012 R2, Microsoft has offered the installation options in a way that you can start by deploying Server Core. Then there is a package that you can add to move up to Full Server or you can install a Full Server and then remove the server graphic shell and Graphical Management Tools and Infrastructure and convert back down to Server Core is as showing in Figure 2. In other words, the graphical shell and the management infrastructure are features that can be added and removed at any time, requiring only a reboot, making it easy to switch between the Server Core and Full Server with GUI. Microsoft also introduced the minimal Server interface so you can actually uninstall Internet Explorer and Explore.exe and have just Microsoft Management Console ( MMC) and Server Manager, which results in less patching. The Minimal Server Interface has fewer benefits than Server Core but it does provide a nice middle-ground versus Server with Desktop Experience:

Figure 2: Removing the graphical management tools in Windows Server 2012 R2

Now moving to the cloud journey with Microsoft Azure, a large server installation that has a lot of things installed, requires patching, and reboots which interrupt service delivery. Azure doesn't use live migration and doesn't use failover clustering. When they have to take down a host in an Azure data center, it does require the virtual machine to be taken down and restarted as well. So, with a large number of servers and large OS resource consumption, it generates a lot of Cost of goods sold (COGS) for them. COGS are the direct costs attributable to the production of the services sold by Microsoft Azure. Thus, by provisioning, large host images compete for the network resources. As mentioned in the Business impact section earlier in this chapter, deploying all those hosts and then re-imaging all of them when a new patch comes out, requires a lot of network bandwidth. Many service providers (not only Microsoft Azure) are over provisioning their network so that they can have enough capacity for live migration or for re-provisioning servers.

Back in October 2014, Microsoft released the first version of their Cloud-in-box solution called Cloud Platform System (CPS) which is running on top of Windows Server Core, System Center, and Windows Azure Pack. To build a CPS system, requires a lot of time; installing all that software takes a lot of time and patching impacts the network allocation. Since a CPS system is an on-premises solution, it does use live migration for the virtual machines. So, with fully loaded CPS 4 racks, configuration would support up to 8,000 virtual machines. So, if each VM is configured with 2 GB of RAM, then you need 16 TB to live migrate over all the networks. Thus, we conclude that you need to have enough capacity to handle that network traffic instead of using it for the business itself. I am not saying that the configuration isn't optimized in CPS in a live migration sense, but they are using live migration over Server Message Block (SMB) protocol directly to offload the network traffic to Remote Direct Memory Access (RDMA) NICs, which is really fast. However, it still takes time to migrate 16 TB of information, and as mentioned earlier, server reboots result in service disruption. The reboot for the compute Hyper-V host in CPS takes around 2 minutes, and the storage host takes around 5 minutes to complete.

Microsoft determined from both Azure and building up the CPS solution that they need a server configuration which is optimized for the cloud and also something that will benefit all their customers, whether you are deploying a cloud configuration in your data center or you are using just Windows Server as your virtualization platform or leveraging the public cloud that's running on top of Windows Server.

The next step in the journey is Nano Server, a new headless, 64-bit only, deployment option for Windows Server, as you can see in Figure 3. It's a little different from Windows Server 2012 R2 in Figure 1. Nano Servers start following the Server Core pattern as a separate installation option. Therefore you can install Nano Server and then there is sub-set of roles and features that you can add on top. The installation options that we have in Windows Server 2016 are Nano Server, Server Core, and Server with a Desktop Experience. Microsoft made a significant change in Windows Server 2016 where you cannot move between different installation options anymore as in Windows Server 2012 R2, just because of some of the changes they had to make in order to implement Nano Server and Server with a Desktop Experience:

Figure 3: Nano Server journey (image source: Microsoft)

Nano Server is deep refactoring initially focused on the CloudOS infrastructure. With Nano Server, you can deploy Hyper-V hosts as a compute platform. You can deploy a scale-out file server as storage nodes and clusters, so that you can do clustered storage servers or clustered Hyper-V hosts and do live migration across nodes. The Nano Server team is continuously working on supporting born-in-the cloud applications; those applications were written with cloud patterns which allow you to run on top of Nano Server. Nano Server can be installed on your physical machines, or it can be installed as a guest virtual machine, and it will also serve as the base OS for Hyper-V containers. Please refer to Chapter 8, Running Windows Server Containers and Hyper-V Containers on Nano Server, for more details about Windows Server containers and Hyper-V containers running on top of Nano Server.

Nano Server is a separate installation option. It's a self-contained operating system that has everything you need. The major difference between Nano Server and Server Core is that none of the roles or features are available in the image same as we get in Server Core and Full Server. The side by side store is when you go to add or install additional roles and features with Windows Server; it never prompts you for the media, as the binary data that is required already exists on your hard disk within the OS. However, in Nano Server, all the infrastructure roles (Hyper-V, storage, clustering, DNS, IIS, and so on) live in a series of separate packages, so you have to add them to the image. In this case, your base Nano Server image will always stay very small. As you start adding roles and features to Nano Server, each role becomes an additional package, as the Hyper-V role for example which only requires the Nano Server base OS, so it will always be small and tight. If you are adding another role that requires a 500 MB file, that will be another 500 MB file to be added to the Nano Server image as a separate package. Nano Server has full driver support, so any driver that works for Windows Server 2016, will work with Nano Server as well.

As of the first release of Nano Server 2016, these are the key roles and features supported to run on Nano Server:

Without a GUI, it's not easy to carry out the daily management and maintenance of Nano Server. In fact, all the existing graphical tools, such as Hyper-V Manager, failover cluster manager, Server Manager, registry editor, file explorer, disk and device manager, server configuration, computer management, users and groups are compatible to manage Nano Server remotely.

The Nano Server deployment option of Windows comes with full PowerShell remoting support. The purpose of the core PowerShell engine is to manage Nano Server instances at scale. PowerShell remoting includes WMI, Windows Server cmdlets (network, storage, Hyper-V, and so on.), PowerShell Desired State Configuration (DSC), remote file transfer, remote script authoring, and debugging. PowerShell relies on the .NET Framework; as you may have noticed Nano Server is a small and tiny OS and only has the Core Common Language Runtime (CLR). The Core CLR is a tiny subset of the .NET Framework; the PowerShell team went ahead and refactored PowerShell to run on Core CLR, which was a huge effort. The good news is that PowerShell users probably will not miss the most important features. It has full language compatibility and supports PowerShell remoting, so you can use the most popular remote commands, such as Invoke-Command, New-PSSession, Enter-PSSession, and so on.

The PowerShell Core is available in every image of Nano Server; it's not an optional package. Each Nano Server image contains, by default, Core CLR that takes up 45 MB of space; PowerShell itself takes about 8 MB of space, and there is 2 MB available for two built-in modules. Remoting is turned on by default, so a Nano Server installation will be always ready to be remoted into and be managed remotely.

The numbers shown in Figure 4 are based on analysis done by Microsoft for all Windows patches that were released in 2014. These numbers fall under three categories as the following:

If you had Nano Server installation options available in 2014, Nano Server had nine important bulletins versus Server Core which had 23 and Server with Desktop Experience that had 26. The interesting one is critical bulletins; Nano Server had two versus Server Core that had eight and Server with Desktop Experience 23. The critical bulletin is a security fix for something that Microsoft has found that people are trying to exploit. This is rated as critical and must be deployed as quickly as possible. So, for the entire year, Nano Server had only two of those critical updates. However, the important bulletins help in overall quality of the system. For Nano Server, there were three reboots required for the entire year, Microsoft is working hard to bring the reboot number from three to only two; Server Core had six and Server with Desktop Experience had 11. Thus for 11 months, you had to reboot your servers because of patches that were applicable to them, whereas for Nano Server, you had to reboot only thrice. Here you can see the uptime benefits of deploying Nano Server:

Figure 4: Nano Server servicing improvements (image source: Microsoft)

Now moving to the security improvements, we are comparing Nano Server with Server Core. As shown in Figure 5 for drivers loaded, we have 73 for Nano and Server Core has 98, Microsoft did not change a lot in the driver's space. However, for services running, they made some significant improvements. In this area, Nano Server had 28 services running versus Server Core which had 47, little less than half. As for ports open, Nano Server was almost a third less compared to Server Core; Nano Server had 12 versus Server Core which had 30. This is the exposure on your network in ways that things can be attacked; vulnerability might be exposed in your systems. The drivers loaded are the hardware drivers and the drivers loaded by the system:

Figure 5: Nano Server security improvements (image source: Microsoft)

As for the resource utilization side, the process count, as shown in Figure 6, Nano Server had 21 versus Server Core that had 26; there has not been too much work done in this area. The boot I/O is a good change here where Nano Server has 108 MB versus Server Core's 306 MB, so 198 MB less of things loading during the boot process and I/O on the disk, that helps speed-up the boot time. Considering the kernel memory in use, Nano Server had 61 MB versus Server Core that had 139 MB, so more resources are available for other things running on your servers:

Figure 6: Nano Server resource utilization improvements (image source: Microsoft)

Finally, the deployment improvements are shown in Figure 7. For setup time, Nano Server takes just 35 seconds compared with almost 5 minutes for Server Core. This is a huge improvement here. You will see where these 35 seconds came from in Chapter 3, Deploying Nano Server in a Virtual Machine and on Physical Hardware. You don't have to actually use Windows setup. Basically, you copy an image that you already created an unattended file for; that 35 seconds setup includes the time to create the unattended file. As for physical deployment using commodity hardware 100 MB switch with Windows Deployment Server (WDS) and PXE boot, Nano Server was fully provisioned in 3 minutes, whereas Server Core using the exact same configuration just switching to a Server Core image was 19 minutes. This is quite an improvement. The setup time is a one-time operation typically; the reboot time took only 15 seconds using the same hardware with spindle disks. The reboot times might vary based on your hardware especially with SSDs. This is quite impressive.

For the disk footprint, Nano Server is 460 MB; that's why it can boot and deploy so quickly, whereas Server Core is almost 5.42 GB. This is assuming you did not add any extra packages; as an example, with the Hyper-V (compute) package, the image will be under 460 MB, because Hyper-V is such a small footprint of hypervisor.

As for VHD size, there is a little bit of overhead here. When you are running in a virtual machine, as you can see, Windows Server Core went up from almost 5.42 GB to a little over 6 GB, and Nano Server goes from 460 MB to 480 MB:

Figure 7: Nano Server deployment improvements (image source: Microsoft)