DRBD® has been a long-standing and proven solution for creating high-availability (HA) storage. LINSTOR®, the LINBIT®-developed software-defined storage (SDS) solution, is a relatively newer offering. You can use LINSTOR to make managing storage easier, and it pairs seamlessly with DRBD behind the scenes. LINSTOR also integrates with many platforms such as Kubernetes, CloudStack, Docker, OpenNebula, Proxmox VE, and more, allowing you to bring HA storage to these platforms easily and flexibly.
LINSTOR can shine when you have a large number of DRBD resources to manage. By using LINSTOR, you no longer need to manually edit and manage DRBD resource configuration files. For example, you can create, modify, and otherwise manage your DRBD resources by entering LINSTOR commands. LINSTOR will take care of the DRBD resource configuration files and give you consistency across your storage cluster. This also has the benefit of eliminating potential user entry errors related to configuration files.
While LINSTOR-managed DRBD resources can coexist with DRBD resources that you created manually, it might make sense to migrate your existing DRBD resources to be under LINSTOR control. If you are an existing DRBD user who wants to start using LINSTOR, you do not need to abandon your existing DRBD resources.
When you migrate DRBD resources to LINSTOR, there are some settings that must be carefully adjusted to match the resource’s existing DRBD configuration. This article will guide you through the process of migrating existing DRBD resources to LINSTOR.
To follow the instructions in this article, you will need to have installed LINSTOR in your cluster. If you need help installing LINSTOR, you can download a LINBIT produced quick-start guide, or refer to installation instructions within the LINSTOR User’s Guide.
âť— IMPORTANT: When migrating existing DRBD resources to LINSTOR, there are special cases, such as existing resources backed by different storage pools on different nodes, or resources that use external metadata. These special cases might require additional steps for a successful migration. This article describes the migration of an existing DRBD resource with a rather typical configuration. If you have questions about migrating DRBD resources in your particular deployment, you can contact the experts at LINBIT.
⚠️ WARNING: The outcome of following the instructions in this article will migrate an existing DRBD resource to LINSTOR and associate the resource with the default LINSTOR resource group,
DfltRscGrp. Unless you have modified the properties of the default resource group, it will have an automatic placement count of two (2). This means LINSTOR will try to maintain a diskful resource deployment on two nodes in your cluster. This is fine for the example migration shown in the article. However, if your migration has different placement count needs, or you need to constrain your resource placement in other ways, refer to details about automatically placing LINSTOR resources in the LINSTOR User’s Guide.
An Overview of the Deployment
This article uses an example two-node setup having the following characteristics:
| Hostname | Node ID | Peer Slots | DRBD Resource Name | Volume # | Minor # | DRBD Device Name | Logical Volume Size | TCP/IP Port |
|---|---|---|---|---|---|---|---|---|
node-0 | 4 | 4 | legacy-res | 10 | 9100 | /dev/drbd9100 | 1340 MiB | 15500 |
node-1 | 8 | 4 | legacy-res | 10 | 9100 | /dev/drbd9100 | 1340 MiB | 15500 |
Additionally, the DRBD metadata type for the example DRBD resource is internal. Although the information is not needed to follow the instructions, if it helps to further imagine this example setup, the DRBD resource is backed by an LVM logical volume, /dev/datastore/legacy-res. The instructions in this guide also assume that on each node, there is a LINSTOR storage pool named fatpool that is backed by an LVM thick-provisioned logical volume with enough available storage space to accommodate the DRBD resource.
Creating a LINSTOR Resource Definition for the Existing DRBD Resource
To prepare for migrating an existing DRBD resource into LINSTOR, you first need to create a LINSTOR resource definition. If you are new to LINSTOR and want some background about LINSTOR concepts, LINSTOR objects (such as resource definitions), and how LINSTOR works, you can refer to details in the LINSTOR User’s Guide. When you create a LINSTOR resource definition to accommodate migrating your existing DRBD resource, you might need to pay attention to the naming of your resource definition. This is because LINSTOR’s naming rules are more strict than DRBD’s naming rules1.
If you do not specify a port number when you create a resource definition, LINSTOR can automatically assign the TCP/IP port number that LINSTOR will use for DRBD replication traffic associated with the resource. An automatically assigned port number will be different from what the existing DRBD resource uses, and there will be a short disconnect and reconnect cycle during the migration. If this might create problems, you can specify the port number that LINSTOR should use and set it to the same port number that the existing DRBD resource uses. This is shown in the example command below.
linstor resource-definition create legacy-res -p 15500
Adjusting the DRBD Peer Slots Count for the LINSTOR Resource Definition
If LINSTOR needs to create additional resources, or has to re-create DRBD metadata, the current peer count used by the resource’s volumes can be important. This is because the peer count has a direct influence on the net size of the DRBD device that is created.
If the peer count of a DRBD volume is unknown, you can get this information from a DRBD metadata dump. You can display a DRBD metadata dump by entering the drbdadm dump-md command. Before entering this command, the DRBD resource volume must be detached, or the resource must be stopped. Normally dumping the DRBD metadata also requires entering a drbdadm apply-al command first.
After you have the peer slot count number of the existing DRBD resource, you can use it to set a corresponding property on the LINSTOR resource definition by entering the following command:
linstor resource-definition set-property legacy-res PeerSlotsNewResource 4
Creating a LINSTOR Volume Definition
After creating a LINSTOR resource definition, you can next create a LINSTOR volume definition. Creating a LINSTOR volume definition typically involves specifying the size of the back-end storage device for LINSTOR to use. In this article, the back-end storage device is an LVM logical volume named legacy-res. When an LVM logical volume is the back-end storage, DRBD will use for storage whatever space is left after first creating the DRBD metadata associated with the DRBD resource. A LINSTOR volume definition should therefore use the net size of a DRBD volume.
To calculate the correct size to use for the LINSTOR volume definition, you can query the net size of the DRBD device using the blockdev utility:
blockdev –getsize64 /dev/drbd9100
Internally, LINSTOR stores volume sizes in KiB. The value that the blockdev utility reports is in bytes, so you will have to divide the blockdev reported size by 1024. There should be no remainder (modulo-division by 1024 should be zero), unless you are dealing with a special case that might require additional steps to migrate successfully.
For an example, this article assumes that a 1,340 MiB logical volume with DRBD metadata with a peer count of four will result in a net size of 1,371,956 KiB. This is the value that you would use when creating the volume definition in LINSTOR.
You should also specify the volume number (10) and the minor number (9100), unless you want LINSTOR to allocate new numbers automatically. If you allow LINSTOR to automatically allocate new numbers, you would typically need to reconfigure any application or file system entries that are using the existing DRBD resource so that they reference the LINSTOR allocated numbers.
linstor volume-definition create legacy-res -n 10 -m 9100 1371956KiB
If, for some reason, the backing storage volume is significantly larger than what would be needed to fit the net size reported by the DRBD volume, then there is an additional property, AllowLargerVolumeSize, that you can set on the volume definition:
linstor volume-definition set-property legacy-res 10 AllowLargerVolumeSize true
You do not normally need to set this property. However, you should set it if the LINSTOR satellite reports an error regarding the backing storage volume’s size being larger than expected.
Setting the Name of the Manually Created Backing Storage Volume
LINSTOR normally generates the name for the backing storage volume, but you can override the name of that volume by setting a property, OverrideVlmId, on the volume definition if the backing storage volume name is the same on each node.
linstor volume-definition set-property legacy-res 10 OverrideVlmId legacy-res
Creating Resources from the Resource Definition
After creating a LINSTOR resource definition and volume definition, you can next create a LINSTOR resource on each of your nodes to finish the migration.
When you create a LINSTOR resource on each node, the resource’s DRBD node id must match the node id that the existing DRBD resource uses on that node. You can look up the node-id value in the existing DRBD resource configuration file, /etc/drbd.d/legacy-res.
Before you can take the final step of creating LINSTOR resources from the resource definition that you created earlier, you need to move the existing DRBD resource configuration file. If you do not move the resource configuration file, drbdadm will complain about duplicate definitions.
mv /etc/drbd.d/legacy-res.res{,.disabled}
It is a good idea to stop the LINSTOR satellite service running on each node before creating the resources, otherwise the DRBD resource will disconnect from other nodes as the first resource is created, and will then reconnect as the other resources (on other nodes) are added. You can stop the LINSTOR satellite service by entering the following command on each node:
systemctl stop linstor-satellite.service
By creating the resources first and starting the LINSTOR satellite service after all resources have been created, the satellites will immediately configure all connections. By doing this, you can avoid a disconnect and reconnect cycle.
linstor resource create --async --node-id 4 -s fatpool node-0 legacy-res
linstor resource create --async --node-id 8 -s fatpool node-1 legacy-res
đź“ť NOTE: Because the LINSTOR satellite service is stopped on each node, the preceding commands use the
--asyncargument to avoid having the LINSTOR client wait for each resource to be created.
Finally, after creating the LINSTOR resources, you can restart the LINSTOR satellite service on each node by entering the following command:
systemctl start linstor-satellite.service
This completes the migration process. After finishing the migration steps, LINSTOR can manage the existing DRBD resource just as if it was created by LINSTOR. You can enter a linstor resource list command to show information about your LINSTOR resources and say goodbye to manually editing the resource’s .res configuration again.
1: The following regular expression describes LINSTOR’s resource definition naming syntax: [_A-Za-z][-_A-Za-z0-9]{1,47}. Furthermore, you cannot use the reserved words all or proxy for the name of a LINSTOR resource definition.
