Windows Server Technical Preview – My Favourite Features – Part 1

Microsoft released the first Technical Preview of Windows 10 to much acclaim back in October. There have been three releases so far and we currently sit on the ‘last release of the Calendar year’ – Build 9879.

The Technical Preview is intended primarily for the enterprise to evaluate the changes and inform the development of new and evolved features of the client operating system. This is a brave and intelligent step. Most followers of Windows in an enterprise will know that Microsoft traditionally release their Client and Server platforms in pairs. XP/ 2003, Vista/2008, Win 7/ 2008R2, Win 8/2012 and most recently Win8.1/2012R2.

The dramatic changes inside Microsoft have not led to a change in this pattern and there is a new server platform being developed alongside Windows 10, this Server is as yet un-named but is also in Technical Preview.

If you have an MSDN subscription you can find it there in both ISO and VHD formats (the new Hyper V server is there too). If you do not subscribe then you can find it here. The new Remote Server Administration Tools for Windows 10 Technical Preview have also been released to allow you to remotely manage your new server from your new client. The RSAT can be found here. They are available in 32bit and 64bit flavours.

For anyone interested in the Server Technical Preview, just about everything you could want to know can be accessed from this blog site. This is Jose Barreto’s blog, Jose is a member of the File Server team within Microsoft and has put together this invaluable survival guide. As you might imagine, it is Storage focussed but does cover most other areas too.

There is one final way you can have a look at and run the Server Technical Preview and that is as a Virtual machine in Microsoft Azure. If you do not have an Azure subscription, again this is part of your MSDN benefit. (MSDN is sounding more and more like good value). Otherwise you can sign up for a cost free trial, here

azpreview1

Windows Server 2012 was a huge leap in performance and function for the Windows Server family and despite the familiar look and feel to the new server and most of its tools, there have been significant new features and improvements to old one. BUT please remember when looking at and playing with this new server operating system.

THIS IS A TECHNICAL PREVIEW – do not use it in production, do not rely on it for any tasks you cannot afford to lose. Having said that I have found it stable and reliable (as with the Windows 10 client. The difference being I use the Windows 10 client on my main work machine and just about all other machines I use – a couple of exceptions) Whereas the server version is very definitely a test rig setup for me at present.

So, what is new and of those new things, what are my favourite features and why. This is the first post in a series examining major new functionality in the Technical Preview.

In Server 2012 one of the big five features for me was Hyper-V Replica. The first new feature of the Technical Preview I want to describe is called Storage Replica.

To quote the TechNet site, Storage Replica (SR) is a new feature that enables storage-agnostic, block-level, synchronous replication between servers for disaster recovery, as well as stretching of a failover cluster for high availability. Synchronous replication enables mirroring of data in physical sites with crash-consistent volumes ensuring zero data loss at the file system level. Asynchronous replication allows site extension beyond metropolitan ranges with the possibility of data loss.

Ok that sounds a.) A lot of technical stuff and b.) Pretty exciting and revolutionary for an out of the box no cost inclusion in a server operating system. So what exactly does it do and how does it do it.

Well, Server 2012 introduced the next version of SMB (SMB 3.0) this allowed a vast number of performance and reliability improvements with file servers and storage as well as normal communications using the SMB protocol.

In short the feature allows an All-Microsoft DR solution for both planned and unplanned outages of your mission-critical tasks. It also allows you to stretch your clusters to a Metropolitan scale.

What is it NOT?

  • Hyper-V Replica
  • DFSR
  • SQLAlwaysOn
  • Backup

Many people use DFSR as a Disaster Recovery Solution, it is not suited to this but can be used. Storage Replica is true DR replication in either synchronous or asynchronous fashion

Microsoft have implemented synchronous replication in a different fashion to most others providers, it does not rely on snapshot technology but continuously replicates instead. This does lead to a lower RPO (Recovery point objective – meaning less data could be lost) but it also means that SR relies on the applications to provide consistency guarantees rather than snapshots. SR does guarantee consistency in all of its replication modes.

There is a step-by-step guide available here, but I have included some other notes below for those who don’t want to read it all now (all 38 pages of it). (Images are taken from that guide and live screenshots too)

The Technical Preview does not currently allow cluster to cluster replication.

ss

 

 

 

 

sc1

 

 

 

 

 

Storage replica is capable of BOTH synchronous and asynchronous replication as shown below. And anyone who knows anything about replication knows that to do this there must be some significant hardware and networking requirements.

synch1
asynch1

So what are the pre-requisites to be able to use Storage Replica in a stretch cluster?

The diagram below represents such a stretch cluster.

sc2

 

 

 

 

 

There must be a Windows Active Directory (not necessary to host this on Technical preview)

Four servers running Technical Preview all must be able to run Hyper-V have a minimum of 4 cores and 8GB RAM. (Note Physical servers are needed for this scenario, you can use VM’s to test Server to Server but not a stretch cluster with Hyper-V).

There needs to be two sets of shared storage each one available to one pair of servers.

Each server MUST have at least one 10GB Ethernet connection.

Ports open for ICMP, SMB (445) and WS-Man (5985) in both directions between all 4 Servers

The test network MUST have at LEAST 8Gbps throughput and importantly round trip latency of less than or equal to 5ms. (This is done using 1472 byte ICMP packets for at least 5 minutes, you can measure that with the simple ping command below)

ping1

Finally Membership in the built-in Administrators group on all server nodes is required.

This is no small list of needs.

The step by step guide uses two ways of demonstrating the set up. And is a total of 38 pages long.

All scenarios are achievable using PowerShell 5.0 as available in the Technical Preview. Once the cluster is built it requires just a single command to build the stretch cluster.

pshell1

You could of course choose to do it in stages using the New-SRGroup and New-SRPartnership CmdLets.

If, like me you do not have the hardware resources lying around to build such a test rig you may want to try and test the server to server replica instead.

This requires,

Windows Server Active Directory domain (does not need to run Windows Server Technical Preview).

Two servers with Windows Server Technical Preview installed. Each server should be capable of running Hyper-V, have at least 4 cores, and have at least 4GB of RAM. (Physical or VM is ok for this scenario)

Two sets of storage. The storage should contain a mix of HDD and SSD media.

(Note USB and System Drives are not eligible for SR and no disk that contains a Windows page file can be used either)

At least one 10GbE connection on each file server.

The test network MUST have at LEAST 8Gbps throughput and importantly round trip latency of less than or equal to 5ms. (This is done using 1472 byte ICMP packets for at least 5 minutes, you can measure that with the simple ping command below)

ping1

Ports open for ICMP, SMB (445) and WS-Man (5985) in both directions between both Servers.

Membership in the built-in Administrators group on all server nodes.

NOTE – the PowerShell CmdLets for the Server to Server scenario work remotely and locally, but only for the creation of the Replica, not to remove or amend using Remove or Set CmdLets (make sure you run these CmdLets locally ON the server that you are targeting for the Group and Partnership tasks).

I do urge you to go off and read more about this solution and test it if you can but remember things are not yet fully baked and will change with each release AND do not use them in Production yet. Read the guide for known issues as well, there are a few.

Finally – why do I love this feature – NO one likes to think of a disaster but if you don’t plan for it, when it does happen it truly will be a disaster in every respect. This allows a much cheaper but effective way of maintaining a current accurate replica of data either on a separate server or on a separate site within a stretch cluster.

Still pricey on hardware and networking, BUT much cheaper than a full hot site DR centre with old style full synchronous replication.

Watch this space for more Server Technical Preview hot features.

Comments are closed.