First, letwe's take a ll look at the configuration type of bsr and explain the necessary components according to the configuration.

Configuration type

bsr provides a flexible way to replicate your company's critical data in a variety of ways.

1:1 Mirror

As a general mirroring configuration method for redundancy within the local network, the synchronous configuration is common for protocols, but there is no restriction on protocol settings.

1:N Mirror

This is a configuration in which a 1:1 mirror is extended to N nodes with N node replication configuration within the local network. Synchronous configuration is general, but there are no restrictions on protocol settings.

1:1 DR

Asynchronous protocol should be used as a disaster recovery(DR) replication configuration over the WAN area, and the transmission buffer and congestion mode must be set. WAN replication can maximize replication performance by linking with a replication accelerator (DRX).

1:N Mirror & DR

It is a mixed configuration of mirroring configuration of local network and remote disaster recovery replication of WAN. Local mirror is synchronous and WAN remote replication is asynchronous. For WAN replication, it is necessary to set the transmission buffer and congestion mode, and it is recommended to interwork the replication accelerator (DRX).

Shared-Disk DR

This is a method of replicating through the WAN by configuring the shared disk of the main operation site as the source and configuring the target as a disaster recovery node. The 2 nodes accessing the shared disk of the main site are configured as Active-Standby to configure the DR node as the 2nd Standby node. The Active-Standby node sets the same virtual IP address (VIP) to perform mutually exclusive operations for resource up, and the DR-side node receives data from the Active or Standby node in association with the primary site through this VIP.

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

N:1 Mirror

This is a method of configuring the target node of resources located in different source nodes into one node. In terms of individual resources, it is a 1:1 mirror configuration, but is defined as an N:1 mirror in terms of overall topology operation.

Local Migration

This configuration replicates the local source volume to the local target volume through multi-resource configuration within the local. Used for live migration.

Configuration component

In order to establish replication, the source and target nodes, the volume to be replicated on nodes, and the network for the communication channel between the nodes(hosts) must be configured. In addition, these components are described in a configuration file as a resource unit to define a replication cluster.

Node

Basically, an operation node and a standby node must be prepared, and the standby node can operate as N nodes. At least two nodes are required for replication.

Volume

Data volume

Storage units of the same size must be prepared on all cluster nodes. If configuring a volume of a different size, the minimum target node's volume size must be larger than the source node's volume size.

The volume must be formatted with an appropriate file system according to the operating system, and uses file systems such as NTFS/ReFS and ext/xfs provided by Windows and Linux. Depending on the partitioning method, the volume can be a logical drive or device of MBR, GPT, or extended partition, and can be configured to include all dynamic disks in RAID format such as span, stripe, and mirror. If the volume is already formatted and contains important data, you can use the existing volume as it is without needing to format the volume, obviously.

Meta Volume

bsr keeps additional information necessary to operate replication in a separate non-volatile storage space and simultaneously writes and reads this data during replication. This additional information is called meta data, and the storage volume that records it is called meta volume. The meta volume must be prepared to correspond 1: 1 to the replication volume, and the size requires about 33MB of space per 1TB based on 1 node replication. For example, for a 1: 2 replication, 3TB replication volume, you need a meta volume with size of 2 * 3 * 33MB = 198MB.

Meta data is classified into internal meta if it is on the same disk device as the replica volume, or external meta if metadata is located on an external disk other than the replica volume.

The internal meta has the advantage of not having to prepare a separate disk device, but in terms of performance, the external meta method of performing I / O to different disks is more advantageous. Internal meta is described by the internal keyword in the configuration file as shown in the following example, where bsr partitions the replication volume at initialization time and automatically generates metadata within the delimited meta area. The internal keyword is provided only in the Linux environment.

...

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.

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.

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.

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

The external meta disk can specify the device to be used as the meta disk in the configuration file in several ways, depending on the operating system, as the mount point in Windows, and as the device name of the disk device in Linux. In addition, bsr supports meta-volumes for virtual disk devices, so virtual volumes can be used as meta volumes even if there is no separate physical disk device. Virtual volume device must be prepared separately as VHD on Windows and Loop device on Linux and can be used in the same way as an external meta disk.

The following is an example of configuration for an external metadisk.

Network

A dedicated line, back-to-back connection, and Gigabit Ethernet connection are the most reasonable options, but when replicating beyond a switch device, performance issues such as throughput and latency at the router must be considered.

The resources of bsr usually use the TCP listening port of 7788 or higher, and each resource must set the port differently and allow the port set by the resource in the local firewall. Of course, it must be configured to prevent other applications from using the TCP port of bsr.

The following is an example of network-related settings.

• bsr hosts use dedicated network interface eth1 and assign IP addresses to 10.1.1.31 and 10.1.1.32.

• bsr normally uses TCP ports 7788 to 7799.

• Enable both inbound and outbound ports between hosts in the local firewall.

Create Resource

Resource creation is the process of describing the components mentioned above in the configuration file. In other words, node (host) information, volume, and connection information can be described in the configuration file through keywords that match attributes within a designated area (section).

All configuration files of bsr are located in the etc directory under the installation path, and the bsr commands load the configuration files by default. First, create bsr.conf in the etc directory. The general contents of the bsr.conf file are as follows.

First, by convention, the global and common sections of bsr are described in the /etc/bsr.d/global_common.conf file. Also, by including all .res files, you can separate and manage configuration files for each resource.

The properties are described based on several promised zones, which are called sections. The section is the top-level section, and there are Global, Common, and Resource sections, and each section has sub-sections. Only the main sections and some basic properties are described here. For more information about the configuration file, refer to the configuration file in the appendix.

Global section

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

The configurations included in this section are options related to the user interface, such as command line timeout or ip validation.

Common section

This section provides settings that can be set as properties common to all resources and is usually written in /etc/bsr.d/global_common.conf. Of course, you can also define each attribute option for each resource individually.

The <Common> section is not required, but it is recommended if you are using more than one resource. Otherwise, it can be complicated by the options that are reused. For example, if you set <net> {protocol C;} in the <Common> section, all resources inherit this option unless a separate option is specified.

Resource section

One resource configuration file name is usually created in /etc/bsr.d/<resource>.res. The resource name used here must be specified in the resource file. Naming names are randomly identifiable, but must be in US-ASCII format and must not contain spaces. Also, every resource configuration must have at least two <host> subsections. All other configuration settings are inherited from the Common section or set as the default for bsr. Options with values common to both hosts can be specified at once in the parent <resource> section of <host>, which can be simplified by describing them as in the following example.

...

resource r0 {
  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;
  }
}

Configuration examples

Simple configuration

The following is an example of a Windows bsr configuration file configured with minimal settings.

/etc/bsr.d/global_common.conf

...

global {
}
common {
  net { 
    protocol C;
  }
}

/etc/bsr.d/r0.res

...

resource r0 {
  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;
  }
  
}

1:2 Mesh

Here is an example of a 1: 2 mirror configuration. Specifies to establish all connections between 3 nodes through the connection-mesh section.

...

resource r0 {
	device	e minor 2;
	disk	e;
	meta-disk f;

	on store1 {
		address   10.1.10.1:7100;
		node-id   0;
	}
	on store2 {
		address   10.1.10.2:7100;
		node-id   1;
	}
	on store3 {
		address   10.1.10.3:7100;
		node-id   2;
	}
	
	connection-mesh {
		hosts     store1 store2 store3;
  	}
}

1: 2 individual connection configuration

This is an example of a 1: 2 mirror configuration, and you can set properties according to the connection individually.

...

resource r0 {

	volume 0 {
		device    e  minor 2;
		disk      e;
		meta-disk f;
	}

  	on store1 {
		node-id   0;
  	}

  	on store2 {
		node-id   1;
  	}
  	on store3 {
		node-id   2;
  	}


	connection {
		host store1 address 10.10.0.245:7789;
		host store2 address 10.10.0.252:7789;
	}
	connection {
		host store2 address 10.10.0.252:7789;
		host store3 address 10.10.0.247:7789;
	}
	connection {
		host store1 address 10.10.0.251:7789;
		host store3 address 10.10.0.247:7789;
	}
}

floating peer

You can configure based on IP address without specifying a host name.

...

resource r0 {

	floating 200.200.200.6:7788 {
		device	d minor 1;
		disk	d;
		meta-disk	n;
		node-id  0;
	}

	floating 200.200.200.7:7788 {
		device	d minor 1;
		disk	d;
		meta-disk	n;
		node-id  1;
	}
}

...

resource r0 {

	floating 10.10.0.251:7788 {
		device	e minor 2;
		disk	e;
		meta-disk	f;
		node-id  0;
	}

	floating 10.10.0.252:7788 {
		device	e minor 2;
		disk	e;
		meta-disk	f;
		node-id  1;
	}
	floating 10.10.0.253:7788 {
		device	e minor 2;
		disk	e;
		meta-disk	f;
		node-id  2;
	}


	
	connection {
		address 10.10.0.251:7788;
		address 10.10.0.252:7788;
	}
	connection {
		address 10.10.0.251:7788;
		address 10.10.0.253:7788;
	}
	connection {
		address 10.10.0.252:7788;
		address 10.10.0.253:7788;
	}
	

}

2:1 configuration

In the source node store1, specify the target node as store3.

...

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.

resource r0 {
    //net { 
    //  protocol C;
    //}

	device	e minor 2;
	disk	e;
	meta-disk f;

	on store1 {
		address   10.1.10.1:7100;
		node-id   0;
	}
	on store2 {
		address   10.1.10.2:7100;
		node-id   1;
	}
	on store3 {
		address   10.1.10.3:7100;
		node-id   2;
	}
	
	connection-mesh {
		hosts     store1 store2 store3;
  	}
}

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.

resource r0 {
  net { 
    protocol A;
    sndbuf-size 1G;
    on-congestion pull-ahead;
    congestion-fill 900M;
  }
  
  on main_server {  
    disk      d;
    address   10.1.1.31:7789;
    meta-disk f;
    node-id 0;  
  }
  
  on dr_server {  
    disk      d;
    address   10.1.1.32:7789;
    meta-disk f;
    node-id 1;
  }
  
}

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.

resource r0 {

	volume 0 {
		device    e  minor 2;
		disk      e;
		meta-disk f;
	}

  	on store1 {
		node-id   1; // Active
  	}

  	on store2 {
		node-id   2; // Standby
  	}
  	on store3 {
		node-id   3; // DR
  	}


	connection {
		net {
			protocol c; 
		}
		host store1 address 10.10.0.240:7789; // Active
		host store2 address 10.10.0.241:7789; // Standby
	}
	connection {
		net {
			protocol A;
		    sndbuf-size 1G;
            on-congestion pull-ahead;
            congestion-fill 900M;
		}
		host store2 address 10.10.0.241:7789; // Standby
		host store3 address 20.20.0.253:7789; // DR
	}
	connection { 
		net {
			protocol A;
		    sndbuf-size 1G;
            on-congestion pull-ahead;
            congestion-fill 900M;
		}
		host store1 address 10.10.0.240:7789; // Active
		host store3 address 20.20.0.253:7789; // DR
	}
}

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.

resource r0{
    net{
        protocol A;
        verify-alg crc32;
        sndbuf-size 1G; # max buffer size is 1 / 8 of physical ram
        on-congestion pull-ahead;
        congestion-fill 950M;
    }
    
    floating 10.20.210.4:7788 {                                                // Use VIP
        options {
            svc-autostart no;                                                  // Applies to Active,Standby between SDR configurations Required options, resource auto-start no
        }

        device e minor 2;
        disk e;
        meta-disk "\\\\?\\Volume{d4006597-e3d1-4685-a91b-b23a669499f4}\\";     // Storage (RAW) volumes that are concurrently accessible on both servers
        node-id 0;
    }
    
    floating 10.20.210.3:7788 {                                                // DR IP
        options {
            svc-autostart yes;                                                 // DR between SDR configurations can resource auto-start yes
        }

        device e minor 2;
        disk e;
        meta-disk "\\\\?\\Volume{58f21aac-2b90-464e-9cea-42a25846fd56}\\";     // Internal or storage (RAW) volumes
        node-id 1;
    }
}

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.

resource r0 {
	device    e  minor 2;
	disk      e;
	meta-disk f;

  	on store1 {
		node-id   0;
  	}

  	on store3 {
		node-id   2;
  	}

	connection {
		host store1 address 10.10.0.245:7789;
		host store3 address 10.10.0.247:7789;
	}
}

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.

resource r1 {
	device    e  minor 2;
	disk      e;
	meta-disk f;

  	on store2 {
		node-id   1;
  	}

  	on store3 {
		node-id   2;
  	}

	connection {
		host store2 address 10.10.0.246:7790;
		host store3 address 10.10.0.247:7790;
	}
}

Target node store3 accepts configurations from both store1 and store2.

resource r0 {
	device    e  minor 2;
	disk      e;
	meta-disk f;

  	on store1 {
		node-id   0;
  	}

  	on store3 {
		node-id   2;
  	}

	connection {
		host store1 address 10.10.0.245:7789;
		host store3 address 10.10.0.247:7789;
	}
}


resource r1 {
	device    g  minor 4;
	disk      g;
	meta-disk h;

  	on store2 {
		node-id   

1;
  	}

  	on store3 {
		node-id   2;
  	}

	connection {
		host 

store2 address 10.10.0.

246:

7790;
		host store3 address 10.10.0.247:

7790;
	}
}

In the source node store2, the target node is specified as store3, and the above configured store1 and store2 are N: 1 configurations that specify store3 as the target.

Floating Peer config.

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

resource r0 {

	floating 200.200.200.6:7788 {
		device	d minor 1;
		disk	d;
		meta-disk	n;
		node-id  0;
	}

	floating 200.200.200.7:7788 {
		device	d minor 1;
		disk	d;
		meta-disk	n;
		node-id  

...

1;

...

	}

...

}

resource r0 {

...

...

Target node store3 accepts both store1 and store2 configurations.

...

	floating 10.10.0.251:7788 {
		device	e minor 2;
		disk

...

	e;
		meta-disk

...

	f;

...

...

...

node-id  

...

0;
	}

	

...

floating 10.10.0.252:7788 {
		device	e minor 2;
		disk	e;
		meta-disk	f;
		node-id  

...

1;

...

	}

...

	floating 10.10.0.

...

253:

...

7788 {
		device	e minor 2;
		disk	e;
		meta-disk	f;
		node-id  2;
	}


	
	connection {
		address 10.10.0.251:7788;
		address 10.10.0.252:7788;
	}
	connection {
		address 10.10.0.251:7788;
		address 10.10.0.253:7788;
	}
	connection {
		

...

address 10.10.0.252:7788;
		address 10.10.0.

...

253:

...

The following describes precautions for each platform.

Windows

volume

• Replication volumes must be online (mounted) and have letter assigned.

• The metadisk volume must be specified as a letter or GUID, and must be prepared in RAW format. Formatting with a specific file system (eg NTFS) causes initialization errors due to permission issues at the time of meta volume initialization.

• Disk volume size

  • The size of the volume must be the same or larger than the size of the target node volume.

  • Here, the size of the volume means the size of the partition, not the size of the file system after formatting, and partition size can be obtained from the powershell command line as follows.

7788;
	}
	

}

Mixed Config.

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

resource r0 {

	floating-on-linux 200.200.200.6:7788 {
        disk     /dev/sdb1;
		device    /dev/bsr0;
		meta-disk  internal;
		node-id  0;
	}

	floating-on-windows 200.200.200.7:7788 {
		device	d minor 1;
		disk	d;
		meta-disk	n;
		node-id  1;
	}
}

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 host name hostname must be specified described in the configuration file host section of the configuration file (except for the floating peer methodmethods).

• The A node-id entry should must be described in the configuration file host section of the configuration file.

...

Connection

• You must add a local firewall exception policy for the mirroring addresses address and portsport.

• The network address set on the NIC should must be described as the IP address in the net section.

Linux

...