1 Components
- 1.1 Node
- 1.2 Volume
  - 1.2.1 Data Volume
  - 1.2.2 Meta Volume
- 1.3 Connection
2 Configuration Files
- 2.1 Global Section
- 2.2 Common Section
- 2.3 Resource Section
  - 2.3.1 disk
  - 2.3.2 device
  - 2.3.3 meta-disk
  - 2.3.4 on host section
    - 2.3.4.1 node-id
    - 2.3.4.2 connection
3 Configuration type
- 3.1 Local Mirror
- 3.2 Local 1:N Mirror
- 3.3 Remote DR(Disaster Recovery)
- 3.4 MDR (Local Mirror & Remote DR)
- 3.5 SDR (Shared Disk & Remote DR)
- 3.6 N:1 Mirror
- 3.7 Floating Peer config.
- 3.8 Mixed Config.
4 Cautions
- 4.1 Windows
  - 4.1.1 Volume
  - 4.1.2 Node
  - 4.1.3 Connection
- 4.2 Linux

First, we'll look at the necessary components of a BSR and explain how it is configured with an example.

Components

To build replication, you need to configure nodes (hosts), volumes to be replicated, and a network for communication channels between replication nodes. You define a replication cluster by describing these components as a single resource unit in a configuration file.

Node

Basically, you need to prepare a production node and a standby node, and the standby node can be operated with N nodes. At least two nodes are required for replication.

Nodes are a distinct term from hosts, but we don't make a strict distinction here; we describe them as hosts only when the distinction is necessary, and otherwise as nodes.

Volume

Data Volume

You must prepare storage devices of the same size on both cluster nodes. When configuring with different sized volumes, at a minimum, the size of the volume on the target node should be larger than the size of the volume on the source node, but it is not recommended to configure volumes with different sizes. (Partition them to make the sizes on both sides match completely)

In BSR, the size of a clone volume is the partition size (in bytes). If the source and target are different in size, even by 1 byte, the replication connection will fail.

Getting Partition Size

In Windows powershell

gwmi -Query "SELECT * from Win32_DiskPartition"

In Linux command line

fdisk -l

Volumes must be formatted with the appropriate filesystem for the operating system and use filesystems such as NTFS/ReFS, ext/xfs, and others provided by Windows and Linux. Volumes can be logical drives or devices in MBR, GPT, or extended partitions, depending on how they are partitioned, and can be configured to include dynamic disks in any RAID format, including spanned, striped, or mirrored. If the volume is already formatted and contains critical data, you can use the existing volume for configuration.

The volume for replication must not have a paging file setting for virtual memory operations. If there is a paging file setting, you cannot perform umount on the volume.
The maximum size of a replication volume supported by bsr is theoretically 1 PB, and volumes larger than 10 TB are typically considered large.

Meta Volume

BSR keeps the additional information needed to operate replication in a separate, non-volatile storage space and performs real-time writing and reading of this data simultaneously during replication. This additional information is called metadata, and the storage volume that writes it is called the meta-volume. Meta-volumes should be sized to have a 1:1 correspondence to the replication volumes, requiring approximately 33 MB of space per 1 TB based on a 1-node replication. For example, a 1:2 replication, 3TB replica volume requires a meta volume sized 2333MB = 198MB.

The meta data is called internal meta if it is located on the same disk device as the replica volume, or external meta if it is located on an external disk other than the replica volume. Internal meta has the advantage of not requiring you to prepare a separate disk device, but performance wise, external meta is slightly better because it performs I/O to different disks. Internal Meta is described by the INTERNAL keyword in the configuration file, as shown in the following example, which causes BSR to partition the replica volume at initialization time and automatically generate metadata within a delimited meta-zone. The INTERNAL keyword is only available in Linux environments.

External meta disks can be specified in the configuration file in several ways, depending on the operating system: as a mount point in Windows, as a device name of a disk device in Linux. BSR supports metavolumes for virtual disk devices, so you can use a virtual volume as a meta volume even if you don't have a separate physical disk device. The virtual volume device must be prepared separately as a VHD in Windows or a Loop device in Linux.

The following is an example of a specification for an external metadisk

Connection

BSR recommends the use of dedicated lines when configuring replicasets, but this is not absolute: dedicated lines, back-to-back connections, and Gigabit Ethernet connections are the most reasonable choices, but when replicating beyond switched equipment, you must consider performance issues such as throughput and latency through routers.

Resources in the bsr typically use TCP listen ports of 7788 or higher, and each resource must have its ports set differently, and the local firewall must allow the ports set by that resource. Of course, you must prevent other applications from using the bsr's TCP ports.

You'll probably end up configuring your connections in the following order

The hosts (bsr-active, bsr-standby) use the dedicated network interface eth1 and assign IP addresses 10.1.1.31 and 10.1.1.32.
TCP ports 7788 through 7799 are used by bsr.
On the local firewall, allow both inbound and outbound ports between the hosts.

Configuration Files

The above-mentioned components are written in configuration files, i.e., node (host) information, volume and connection information are described using keywords that match the attributes within a given zone (section).

All configuration files in BSR are located in a subdirectory of the installation path, etc, and the BSR utilities load them from that path.

First, create bsr.conf in the etc directory. The general contents of a bsr.conf file are shown below.

As a matter of convention, we start by creating a global, common section of BSR in the /etc/bsr.d/global_common.conf file, and we recommend that you include all .res files so that you can separate them by resource.

We describe properties based on a few promised zones, which we call sections. The top-level sections are Global, Common, and Resource, and within each section there are property-specific subsections. This section only describes the major sections and some basic properties. For more information about configuration files, see Configuration Files in the Appendix.

Global Section

This section can only be used once globally, and is typically found inside the /etc/bsr.d/global_common.conf file. If you configure it in a single file, you can write it at the top of the configuration file.

The configuration included in this section are options related to the user interface, such as command timeouts, IP validation, etc.

Common Section

This section provides settings that can be set for properties that are common to all resources and are usually written in /etc/bsr.d/global_common.conf. Of course, you can also define each property option on an individual resource basis.

While it is not mandatory to have a <Common> section, it is recommended that you do if you are using more than one resource, otherwise it can become cluttered with reused options. For example, if you set <net> {protocol C;} in the <Common> section, all resources will inherit this option unless otherwise specified.

Resource Section

A single resource configuration filename is typically created in the form /etc/bsr.d/<resource>.res. The resource name used here must be specified within the resource file. Naming is arbitrary and identifiable, but it must be in US-ASCII format and must not contain space characters. Also, every resource configuration must have at least one <host> subsection. All other configuration settings are inherited from the Common section or set to the default values in the bsr. Options with values common to both hosts can be specified directly in the parent <resource> section of the <host> at once, but can be simplified by stating them as in the following example.

resource r0 {
  device    d minor 1;
  disk      d;
  meta-disk f;
  on alice {
    address   10.1.1.31:7789;
    node-id 0;
  }
  on bob {
    address   10.1.1.32:7789;
    node-id 1;
  }
}

The following attributes are required to be described in the Resources section

disk

Specifies the replication device. Specify as a backing device or volume letter, depending on the platform.

device

Specifies the BSR logical device information. It can be specified directly as a device name, such as /dev/bsr1, or as a minor number, such as minor 1;.

On Windows, only specifying a minor number with a letter is used. On Windows, you can specify a device minor number by using the C drive volume as volume 0 and incrementing the minor number by 1 for each increment of the letter value (D is 1, E is 2, F is 3, ...).

meta-disk

Describes meta-disk information.

on host section

This section describes the host information. node-id and connection information.

node-id

You can specify an arbitrary node ID starting from 0. It is recommended to specify a smaller number for the primary node.

connection

Specify the IP and port information.

Connections can also be described separately using the connection section, as shown below. This is often used in node replication configurations.

resource "r0" {
  device    minor 1;
  disk      "/dev/sda7";
  meta-disk internal;
  on "alice" {
    node-id 0;
  }
  on "bob" {
    node-id 1;
  }
  connection {
    host "alice" address 10.1.1.31:7789;
    host "bob" address 10.1.1.32:7789;
  }
}

For specific descriptions of other sections, subsections, and individual options, see the configuration file contents in the appendix.

Configuration type

BSR provides flexible redundancy for your organization's critical data in a variety of configurations. Configurations that replicate within the local network are commonly referred to as mirror configurations, while those that replicate between remote locations are called disaster recovery (DR) configurations.

Local Mirror

Replication protocols are typically configured synchronously, which is a common way to configure mirroring for redundancy within a local network.

/etc/bsr.d/r0.res

resource r0 {
  net { 
    protocol C;
  }
  
  on alice {  
    disk      d;
    address   10.1.1.31:7789;
    meta-disk f;
    node-id 0;  
  }
  
  on bob {  
    disk      d;
    address   10.1.1.32:7789;
    meta-disk f;
    node-id 1;
  }
  
}

Local 1:N Mirror

An N-node replication configuration within the local network that extends a 1:1 mirror to N nodes. The replication protocol is typically configured as synchronous, but you may want to consider an asynchronous configuration if N-node replication causes performance degradation. The replication protocol defaults to synchronous (C) if omitted from the configuration.

Remote DR(Disaster Recovery)

When configuring disaster recovery replication over a WAN segment, you need to use an asynchronous protocol as the default and set the egress buffer settings for buffering and a mode for when the buffer becomes congested. For more information about congestion mode, see Congestion mode.

You can also maximize replication processing performance when you integrate a replication accelerator (DRX).

MDR (Local Mirror & Remote DR)

A mixed configuration of mirroring on the local network and remote disaster recovery replication across the WAN. The local mirror is synchronous and the WAN remote replication is asynchronous. WAN cross-border replication requires a transmit buffer and congestion mode to be configured, and the use of a replication accelerator (DRX) is recommended.

SDR (Shared Disk & Remote DR)

This method replicates across the WAN by configuring the shared disk of the main production site as the source and the target as a disaster recovery node. The two nodes that access the shared disk at the primary site are configured as Active/Standby, and the DR node is configured as the second standby node. The Active-Standby node is set to the same virtual IP address (VIP) to mutually exclude resource operations between the nodes, and the node on the DR side communicates with this VIP to receive data from the Active/Standby node.

As a WAN disaster recovery configuration, asynchronous protocol operation and replication accelerator (DRX) interworking should be considered.

N:1 Mirror

This is a way of designating one node as the target node for replication of resources located on different nodes. It is a 1:1 mirror configuration in terms of individual resources, but is defined as an N:1 mirror in terms of overall operations.

Specify the target node as store3 on the source node store1.

This is an N:1 configuration in which store1 and store2 configured above with source node store2 and target node store3 are targeted by store3.

Target node store3 accepts configurations from both store1 and store2.

Floating Peer config.

You can configure based on IP address without specifying a hostname.

Mixed Config.

You can configure a mix of Windows and Linux nodes. Use for DR deployments, backups, and more.

Cautions

Windows

Volume

Replica volumes must be online (mounted) and assigned a letter.
Metadisk volumes must be lettered or GUIDed, and must be prepared in RAW format. Formatting with certain file systems (such as NTFS) will result in initialization errors due to permissions issues at meta-volume initialization time.
Disk volume size
- The size of the volume must be the same or larger on the target node volume than the size of the source node volume.
- The size of the volume here refers to the size of the partition, not the size of the filesystem after formatting, and can be obtained from the powershell command line as follows

Node

The hostname must be described in the configuration file host section (except for floating peer methods)
A node-id entry must be described in the configuration file host section.

Connection

You must add a local firewall exception policy for the mirroring address and port.
The network address set on the NIC must be described as the IP address in the net section.