Category Archives: Windows Server

Disaster Recovery Solutions: Storage Replica vs DFS Replication

Microsoft Storage Replica is a technology introduced starting with Windows Server 2016 which among the main usage scenarios involves volume replication, synchronously or asynchronously, between servers or clusters, for disaster recovery purposes. Nowadays, several Microsoft customers continue to use DFS Replication (DFS-r) as a Disaster Recovery solution for unstructured data such as home folders and departmental shares. The question many are asking is whether the recent Storage Replica technology really takes the place of the well-established DFS-r mechanism. In this article the characteristics of the two solutions will be explored in order to clarify when it is convenient to use Storage Replica and when DFS Replication (DFS-r).

DFS Replication (DFS-r)

DFS Replication is a solution that can be activated through a role in Windows Server that allows you to replicate folders on different servers and geographic sites. The solution is based on an efficient replication engine, that contemplates the presence of more masters, which can be used to keep folders synchronized between different servers, even through network connections with limited bandwidth. DFS-r uses a compression algorithm known as Remote Differential Compression (RDC), able to detect changes in a file and replicate only the changed blocks instead of the entire file. DFS-r has long since replaced the File Replication Service (FRS) and it is also used for Active Directory Domain Services SYSVOL folder replication (AD DS) in domains where the functional level is at least Windows Server 2008.

The activation of DFS-r involves the creation of replication groups that contain the files and folders to be replicated:

Figure 1 – DFS-r Replication Process

For more information about the DFS Replication service (DFS-r) you can see the related Microsoft documentation.

Storage Replica

Storage Replica is a technology introduced from Windows Server 2016 and it allows the replication of volumes between servers or clusters for Disaster Recovery purposes.

Figure 2 – Server-to-server and Cluster-to-cluster storage replication scenarios

This technology also allows you to create stretch failover cluster with nodes spread over two different site, keeping storage in sync.

Figure 3 – Stretch clustered storage replication scenarios

In Windows Server 2016 the ability to use storage replication is only available if you use the Datacenter Edition of the operating system, while in Windows Server 2019 there is the possibility to activate Storage Replica also by adopting the Standard Edition, but with the following limitations:

  • You can replicate a single volume instead of an unlimited number of volumes.
  • The maximum size of the replicated volume should not exceed 2 TB.

For more information on Storage Replica, please consult the related Microsoft documentation.

Comparison of the solutions

The DFS-r solution is particularly effective in environments with limited network bandwidth and where it is necessary to replicate content on different nodes for which a limited number of changes are expected. However, DFS-r has significant limitations as a data replication solution, including:

  • Cannot replicate files in use or open.
  • It does not have a synchronous replication mechanism.
  • The latency for asynchronous replication can be of considerable duration (minutes, hours or even days).
  • It is based on a database that may require costly consistency checks as a result of any system outages.
  • The burden of environmental management is high.

The Storage Replica solution does not have the limitations listed above, but it is good to take into consideration the following aspects that differentiate it from the DFS-r solution and that in some scenarios could be considered as critical elements:

  • Replication occurs at the volume level and only one-to-one replication between volumes is allowed. However, it is possible to replicate different volumes between multiple servers.
  • Allows you to replicate synchronously or asynchronously, but it is not designed for low-bandwidth, high-latency networks.
  • Users are not allowed to access protected data on the target server while replication is in progress.
    • To validate the effectiveness of the replication process, it is still possible to carry out a Failover Test, which allows you to mount a writable snapshot of the replicated storage. To perform this operation, for testing purposes or backup, you must have a volume, not involved in replication, on the destination server. The Failover Test has no impact on the replication process, which will continue to ensure the protection of the data and the changes to the snapshot will remain circumscribed to the test volume.

How to replace DFS Replication (DFS-r) with Storage Replica?

If the characteristics of Storage Replica are not considered blocking, this latest technology can be adopted to replace the DFS Replication solution (DFS-r). The high-level process involves the following steps:

  • Install new systems at least Windows Server 2016, paying attention to evaluate the limits imposed by the Standard Edition, and configure storage. To learn more about improvements in Storage Replication with Windows Server 2019 you can consult this article.
  • Migrate the data that you want to replicate to one or more volumes of data (for example through Robocopy).
  • Enable Storage Replica replication and complete initial synchronization.
  • We recommend enabling snapshots through Volume Shadow Copies, in particular in the case of asynchronous replication. Snapshots are also replicated along with the files. In case of emergency, this will allow you to restore files from snapshots on the target server that may have only been partially replicated asynchronously.
  • Share the data on the source server and make it accessible through a DFS namespace. This aspect is important to ensure that users can still access the data when the server name changes during the activation of the Disaster Recovery plan. On the replication target server (DR site) you can create shares (not accessible during normal operations). The server on the DR site can be added to the DFS Namespaces keeping the target folders disabled.

If disaster recovery scenario needs to be activated, using the storage replica solution, you should do the following:

  • Make the server located on the DR site primary, so that it can show replicated volumes to users.
  • In case of synchronous replication, no data recovery will be required, unless during the loss of the origin server the user was using an application that wrote data without transaction protection.
  • In case of asynchronous replication, you may need to mount a snapshot to ensure application-wide data consistency.
  • Enable the target folders in DFS Namespaces to allow users to access their data.

Conclusions

Microsoft is continuing to make major investments in storage and Storage Replica is the tangible result that allows customers to adopt an effective and performing storage replication solution. In the Disaster Recovery field, there are several scenarios where Storage Replica can replace the DFS Replication service (DFS-r), however you should carefully evaluate the characteristics of both solutions to choose the one that best suits your usage scenario.

How to address the end of lifecycle for Windows Server 2008\2008 R2

The end of Microsoft support for Windows Server 2008 and Windows Server 2008 R2 is imminent and planned for 14 January 2020. As of this date, Microsoft will no longer release free security updates for these platforms in an on-premises environment. Unfortunately, there are still many systems in production that adopt these operating system versions. This article discusses the approaches you can take to address this situation, avoiding exposing your infrastructure to security issues caused by the unavailability of the necessary updates.

The end of the extended support for these platforms implies that Microsoft, unless certain actions are taken, will no longer release its security updates. Under these conditions the exposure to security attacks is considerable and would result in the state of non-compliance with respect to specific regulations, such as the General Data Protection Regulation (GDPR). This condition, certainly not very pleasant for those who find themselves to face it now, given the limited time, it can also be seen as an important opportunity for renewal and innovation of the infrastructure.

To continue receiving security updates for Windows Server 20082008 R2 hosted on on-premises environment, the only possibility is to join to the program Extended Security Update (ESU). The fee program is only available for customers in Software Assurance and ensures the provision of Security Update classified as "critical" and "important" for a further three years, from 14 January 2020.

If the ESU program is not appropriate to their needs you can be assessed two totally different upgrade paths.

Upgrade on-premises

This path provides for the transition to a new version of Windows Server environment on-premises. The advice in this case is to approach at least Windows Server 2016 and not to proceed, whenever possible, with upgrade in place of the operating system, but to manage migration in side-by-side. This method usually requires the involvement of the application provider, to ensure software compatibility with the new version of the operating system. Since the software is not recent, often it require the adoption of updated versions of the same, which may comprise architecture adjustment and an in-depth phase of testing for the new release . By adopting this upgrade process, the time and effort are considerable, but the result you get is critical to complying with the technological renewal.

Migrating to Azure

Migrating Windows Server Systems 2008 and Windows Server 2008 R2 on-premises in Azure environment will continue to receive security updates for another three years, classified as critical and important, without having to join the ESU program. This scenario is not only useful to ensure compliance with its systems, but it opens the way towards hybrid architectures where you can get the cloud advantages. In this regard, Microsoft offers a great solution that can provide a large set of tools needed to best deal with the most common migration scenarios: Azure Migrate,  that structure the migration process in different phase (discovery, assessment, and migration). This approach may be more immediate than upgrading systems and gives you more time to deal with software renewal. In this regard, the cloud allows you to have excellent flexibility and agility in testing applications in parallel environments. Before starting the migration path towards Azure is fundamental to structure the hybrid networking environment in a timely manner and evaluate the iterations with the other infrastructure components, to see whether the application can also work well in the cloud.

Regardless of the upgrade path you decide to take the advice is to make a detailed assessment, so you can categorize workloads by type, criticality, complexity and risk. In this way it is possible to prioritize, and proceed with a structured migration plan.

Conclusions

For all those who, inside their own datacenter have Windows Server 2008 or Windows Server 2008 R2 is appropriate to manage the condition that Microsoft will not release more security updates, free of charge, exposing systems to potential security issues. At the same time there are various possibilities offered by Microsoft to address this situation in the best possible ways. The migration path to Azure is definitely a very interesting option to start the journey to expand your datacenter into the Microsoft public cloud.