Support for Arbitrary Applications

Storage Replica works at the block level and can therefore support arbitrary applications and filesystems. It offers two replication modes: synchronous and asynchronous. In synchronous mode, it can also be used within a failover cluster, where it supports the ability to distribute the servers in a cluster across separate data centers ("stretch cluster") without needing a replicated SAN.

Synchronous replication works on the principle that an application wants to store data and send the request to the operating system (Figure  3: step  1). Storage Replica stores the change in a separate, fast log area and sends the request to the second server at the same time (step  2). This server also backs up the transaction in its log (step  3) and sends a success message to the first server (step  4). It is only now that the application receives confirmation that all data has been stored (step  5). The servers delay actual access to the physical data areas of the storage system (step  6), thus optimizing overall speed.

Figure 3: Synchronous replication: Storage Replica can replicate data blocks. The transfer takes place before the application receives confirmation of the storage process.

According to Microsoft, this synchronous replication process rules out data loss. If one of the servers fails, the application does not receive a success message for the save operation. Although this means that the application hits an error condition, it also means that it will not lose any data because the application did not receive confirmation. After repairing the system (or after switching to non-redundant operation with the remaining servers) all confirmed data are again available  – either directly in the data area or in the storage logs.

Obviously, you need a high-speed network between the two storage servers that matches the speed of a storage system. The application needs to wait every time you save data until both servers have reported success. The recommendation is to use redundant 10GB networks or an even faster connection.

In asynchronous replication mode, the application does not have to wait for the network. Here, only the first server stores the data in its log (Figure  4: step  2) and then immediately acknowledges (step  3). It then transfers the blocks to the second server (step  4). In this mode, the application runs faster because it avoids latencies. However, data loss cannot be ruled out in case of server errors; after all, the system does not ensure that all data really has been replicated before confirming. Asynchronous replication is thus suitable especially for disaster recovery scenarios with applications that can tolerate minor data loss during recovery. Be aware, however, that data replication does not replace a backup because any change  – even any data deletion – is applied consistently to both systems.

Figure 4: Asynchronous replication: In asynchronous mode, Storage Replica confirms the save operation once the data has reached the first server. It then transfers the data to the second system.

Setting up this kind of storage replication process is not trivial and can only be implemented via PowerShell  – at least in the Technical Preview. For testing purposes, Microsoft offers a comprehensive guide  [3], which you can follow step by step.

New in the Network Environment

The other new features in Windows Server relate to Terminal Server (or to be more precise, Remote Desktop Services) and networking capabilities. Terminal Services has just two fairly minor changes for special situations. For example, Windows Terminal Server supports the OpenGL and OpenCL protocols and can therefore run more demanding graphics applications over the RDP protocol.

Microsoft additionally has integrated a product into the Remote Desktop Services that was previously available separately. The Multipoint Services particularly target educational institutions and allow study groups to be supported with a single server. Thus, it's possible to connect multiple monitors, keyboards, and mice to the same computer and still provide each student with their own environment. The system keeps applications, data, and user profiles separate for each user.

In a second mode, the services work more like a traditional terminal server. Here, users have their own computers (iPads and the like are also supported) and use their own sessions on the server via RDP. The group leader, however, can take over control and share his or her own screen like a central blackboard. Likewise, the results of one user project can be shared on the screens of the other users.

Control of Complex Networks

The new Network Controller provides a new control center for complex networks. It positions itself as an intermediary between network devices, such as switches, routers, or virtual networks, and a network management system such as Microsoft's System Center Operations Manager (SCOM). On one hand, the network controller collects device status data and forwards the data for evaluation. On the other hand, it receives commands from the management system and distributes these to the devices. This can never be a standalone function; a separate control software is always required.

Even the Windows DNS server will be smarter in the next release. In the future, it will be managed via DNS Policies and be able to send different responses to clients in a rules-based way. For example, different host addresses can be used for internal and external clients, or the DNS data can vary depending on time of day. Other DNS servers have provided such functions for some time.

In addition to the described major changes, the Windows Server Technical Preview comes with many minor changes. These include a preinstalled malware scanner based on Windows Defender. Environments that do not allow third-party software to be installed on servers thus no longer need to do completely without antivirus. The PowerShell 5.0 scripting environment has been extended to include advanced programming features, such as class bases or improved remote access.