WinDRBD is based on the original DRBD source code. However, there are some differences because the architecture of Windows NT differs significantly from the Linux architecture.
There are two types of differences between WinDRBD® and the Linux DRBD® version:- Differences that are imposed by system architecture. These differences will most likely remain in the WinDRBD kernel driver.
- Differences because of unimplemented features. These differences will be addressed in future versions of WinDRBD.
How Highly Available Data is Presented
Under Linux, DRBD volumes can be accessed as standard Linux block devices (`/dev/drbdN`, where `N` is the device minor number). Under Windows the block device interface has several limitations which cause some applications not to work properly on top of a WinDRBD volume. Most notably newer versions of the Microsoft SQL server would not run on top of a WinDRBD volume when it was a block device.
The WinDRBD device layer therefore presents WinDRBD volumes as SCSI disks to the system. This causes the Windows Plug and Play manager to stack several Microsoft drivers (the `disk.sys` and `partmgr.sys` drivers, among others, depending on the Windows version) over the WinDRBD driver, thereby implementing all necessary application programming interfaces (APIs) that applications need (including undocumented interfaces).
This implies that there is a partition table on the WinDRBD disk. For new WinDRBD disks these have to be created right after the device is set up. This can be done by using some PowerShell commands, for example, or by using the Disk Management utility (Windows Meta Key + R, `diskmgmt.msc`, <Enter>) in the Control Panel. To learn how to set up a WinDRBD disk with PowerShell, please read this knowledge base article.
No Disk When Secondary
Under Windows there is no such thing as the `mount(2)` system call. What Microsoft calls mounting is essentially assigning a drive letter to a Windows Volume, thereby making it accessible to applications (internally a symbolic link is created). Windows accesses disks without a defined procedure of opening and closing the device (including offline disks). Since data on DRBD resources that are secondary can change when the primary peer writes to it, these accesses may read invalid or outdated data.
We therefore decided to create a WinDRBD disk dynamically when a resource is promoted to primary (all DRBD volumes of the resource). Therefore to access the data in read/write mode you have to first run:
drbdadm primary myresWhen you have the Disk Management utility or the Device Manager (`devmgmt.msc`) open you will see the WinDRBD disks appear (and disappear on `drbdadm` secondary) in the GUI (you might have to refresh the view).
No Auto Promote or Demote
Since there is no device when a resource is secondary, there is consequently also no auto promote (and demote) feature as implemented in the DRBD 9 Linux driver. This is because on WinDRBD, there is no device to access the data as long a resource is secondary.
Auto promote makes sense on systems where there is a defined interface for opening the device (such as on Linux systems). When promoting is possible, that is, when no other peers are currently primary, the DRBD driver on Linux promotes a resource to primary when, for example, the containing file system is mounted.
File Systems on Backing Devices are Hidden
To prevent data corruption, WinDRBD hides file systems on backing devices from the Windows system. Again, this happens to prevent Windows from accessing (most notably writing to) the file system without WinDRBD knowing about it. If Windows were to write to the lower level device, there would instantly be a split-brain situation that would cause data corruption.
How WinDRBD Hides the File System on Backing Devices
WinDRBD hides the file system by altering the file system signature in the boot sector. The file system signature is a 4-byte string starting at offset 3 of the boot sector. For example, if there is an NTFS file system, the string "NTFS" is in the boot sector. WinDRBD replaces this string by "DRBD". This is done when the resource is brought up for the first time, or more precisely in the process of attaching the backing disk. Once this is done, the backing device, not to be confused with the WinDRBD disk device created on drbdadm primary, will show up as `RAW` in partition manager.
The actual change of the file system signature is not done by the WinDRBD driver. Instead the `windrbd.exe` command line utility does this. On `drbdadm up` and `drbdadm attach` this utility is automatically called for all volumes of the resource. In rare cases, you can run the utility manually, either to check the file system state or to restore the file system's signature in the boot sector to access the data again without routing it through WinDRBD. The commands to do this are (replace `X` with the drive letter of your backing device):
windrbd hide-filesystem X:
windrbd show-filesystem X:
windrbd filesystem-state X:
Virtual Partition Tables
Since WinDRBD 1.1.4, it is possible to make existing Windows partitions highly available while maintaining compatibility with Windows applications. This is done by the WinDRBD driver by presenting a GPT partition table before and after the backing device. Windows will treat the WinDRBD device as a regular disk with one data partition on it and again stack the drivers for compatibility over the WinDRBD driver.
WinDRBD's implementation is smart enough to detect file systems on the backing device and to correctly generate the GPT partition table. Drive letters can be assigned to the data partition with standard Windows tools. The GUIDs in the partition table that identify the disk in Windows are generated from unique serial numbers in the file system's boot sector. Now WinDRBD supports this for NTFS and ReFS, other file systems will follow upon request. If a file system is currently not supported, WinDRBD will generate a random GUID which will cause Windows to treat the disk as a new disk (Offline and Read Only) each time the resource is promoted to primary.
Specifying Backing Devices in DRBD Configuration Files
There is a subtle difference in the syntax of the `disk` and `meta-disk` clauses in a DRBD configuration file. Since there is no such thing as a `/dev` directory in the Windows file system, you can either specify backing devices by drive letter or by volume GUID, in a DRBD configuration file. Examples are:
disk "E:";You can find the volume GUID using the Windows `mountvol` utility. Besides this minor difference, there are no differences between Linux and Windows in the DRBD configuration file syntax. The configuration files can be found in the WinDRBD system root directory which defaults to `C:\WinDRBD`. So, assuming that you haven't changed the system root directory at install time, the directory for the WinDRBD `*.res` configuration files is:
meta-disk "3e56b893-10bf-11e8-aedd-0800274289ab";
C:\WinDRBD\etc\drbd.d
Installing WinDRBD
Since there is no package management system similar to those from Linux distributions, such as DEB or RPM, we implemented an Inno Setup based installer that comes as a self-extracting EXE file. You can download these installers from the LINBIT® website's downloads page. To install WinDRBD, just download and then run the EXE file.
Automating the WinDRBD Installation Process
To learn how to automate the WinDRBD installation process, refer to this knowledge base article. The installer includes complete uninstall and upgrade support. It is usually not necessary to restart Windows when updating the WinDRBD driver.
How the WinDRBD Installation Process Works
The installer first brings all WinDRBD resources down, shuts down WinDRBD related services (such as the logger service or LINSTOR® Satellite for Windows), and then unloads the driver. After that, it installs the new driver and restarts the services that were running before. It does not restart the WinDRBD resources. However, if you are using LINSTOR For Windows, the LINSTOR Satellite service will do that (for resources that were created by LINSTOR).
Unimplemented but Planned Features
Although WinDRBD is in a 1.X stable release state and therefore ready to be used in production environments, there are some features that the Linux DRBD release supports that at the time of this writing (February 2023, WinDRBD 1.1.6) are not yet supported by WinDRBD. Here is an incomplete list of those missing features:
- Now, no "real" cryptographic algorithms are supported for `verify-alg`and `cram-hmac-alg`. Only `crc32c` is supported. WinDRBD resources will fail to start if you specify anything besides `crc32c` as a cipher in the WinDRBD configuration file.
- No TRIM or DISCARD support: Especially SSDs and NVRAMs, but also thin-provisioned storage, benefit from this feature. It is a mechanism for an application to tell the storage driver that portions of data are not needed any more and can be discarded. Essentially it is an optimization for SSDs and NVRAMs. At the moment, WinDRBD does not support these special requests.
- Remote booting: While it is possible to boot from a WinDRBD disk remotely, setting this up is very complex and time consuming. Also there are other limitations (such as missing recovery from network outages) which currently make it not advisable to use WinDRBD for running Windows from a remote disk.
- DRBD version: Currently, WinDRBD is based on the 9.0 branch of DRBD. Due to various software engineering related topics this cannot be upgraded easily to 9.1 or even 9.2.
Contacting LINBIT About WinDRBD Questions or Features
If you have any questions about features in WinDRBD please reach out to
LINBIT®, either by using the contact us web form on the LINBIT
website, by sending an email to sales@linbit.com, or by joining the `linbit-community`
workspace on Slack. Or click on the chat icon on the LINBIT website to ask us questions about products or support options.
Written by JT, 02/17/2023.
Reviewed by MAT, 02/22/2023.