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.

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

리소스 작성은 위에서 언급한 구성요소들을 구성파일에 기술하는 과정입니다. 즉, 노드(호스트) 정보와 볼륨, 연결 정보를 정해진 구역(섹션)내에서 속성에 맞는 키워드들을 통해 구성파일에 기술하면 됩니다.

bsr의 모든 구성 파일은 설치경로의 하위 etc 디렉터리에 위치합니다. 그리고 bsr 명령어들은 모두 내부적으로 %BSR_PATH%의 etc 경로에서 구성파일을 로드합니다. 먼저 etc 디렉터리에서 bsr.conf를 생성합니다. bsr.conf 파일의 일반적인 내용은 아래와 같습니다.

우선 관례적으로 bsr의 전역(global), 공통(common) 섹션을 기술하는 설정파일을 /etc/bsr.d/global_common.conf 파일로 지정합니다. 그리고 모든 .res 파일들을 포함하도록 하여 리소스 별로 구성파일을 분리해서 관리할 수 있도록 합니다.

몇 가지 약속된 구역을 기준으로 속성을 기술하는데 이 구역을 섹션이라고 합니다. 섹션은 최상위 구역으로 Global, Common, Resource 섹션이 있으며, 각 섹션내에서 속셩 별 하위 섹션들이 있습니다. 여기서는 주요한 섹션과 일부 기본적인 속성에 대해서만 설명합니다. 구성파일과 관련한 자세한 내용은 부록의 구성파일을 참고하세요.

Global 섹션

이 섹션은 전역적으로 한번 만 사용 할 수 있으며, 일반적으로 /etc/bsr.d/global_common.conf 파일 안에 있습니다. 단일 파일로 구성한다면 구성 파일의 맨 상단에 작성하면 됩니다.

이 섹션에 포함되는 구성은 명령어 타임아웃, ip 유효성 검사 등 사용자 인터페이스와 관련 있는 옵션들입니다.

Common 섹션

이 섹션에서는 모든 리소스에 공통적인 속성으로 설정할 수 있는 설정값을 제공하며 보통 /etc/bsr.d/global_common.conf 에서 작성합니다. 물론 리소스 개별적으로 각각의 속성 옵션을 정의 할 수도 있습니다.

<Common> 섹션이 반드시 있어야 되는건 아니지만, 둘 이상의 리소스를 사용하는 경우에는 꼭 사용할 것을 권장합니다. 그렇지 않으면, 재사용되는 옵션들에 의해 복잡해질 수 있습니다. 예를들어, <Common> 섹션에서 <net> {protocal C;}를 설정할 경우 모든 리소스는 별도의 옵션이 지정되지 않는 한 이 옵션을 상속합니다.

Resource 섹션

한 개의 리소스 구성 파일명은 보통 /etc/bsr.d/<resource>.res 형태로 생성합니다. 여기서 사용된 리소스 이름은 리소스파일 내에서 명시해야 합니다. 이름을 정하는 것은 임의로 식별 가능하게 명명하지만 US-ASCII 형식이어야 하며 공백문자를 포함해선 안됩니다. 또한 모든 리소스 구성에는 <host> 하위 섹션이 두 개 이상 있어야 합니다. 다른 모든 구성 설정은 Common 섹션으로부터 상속되거나 bsr의 기본값으로 설정됩니다. 양쪽 호스트에 공통적인 값을 가진 옵션은 <host>의 상위 <resource> 섹션 부분에서 한 번에 바로 지정해도 되는데 다음 예제처럼 기술하여 간소화 시킬 수 있습니다.

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;
  }
}

구성 예제

단순 구성

다음의 예는 최소한의 설정으로 구성하는 Windows bsr 구성파일 예시 입니다.

/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

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 개별 연결 구성

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 구성

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 복제 구성

store1necessary 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

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;
	}
}

store2

resource r1 {
	device    

g  minor 

4;
	disk      

g;
	meta-disk 

h;

  	on store2 {
		node-

store3

id   1;
  	}

  	on store3 {
		node-id   2;
  	}

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

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 {

	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;
	

...

Windows

볼륨

• 복제 볼륨은 온라인(마운트)된 상태로 레터가 할당되어 있어야 합니다.

• 메타디스크 볼륨은 레터 또는 GUID로 지정되어 있어야 하며, RAW 포맷 상태로 준비해야 합니다. 특정 파일 시스템(예: NTFS)으로 포맷할 경우 메타 볼륨 초기화 시점에 권한 문제로 인한 초기화 오류가 발생합니다.

• 디스크 볼륨 크기

  • 볼륨의 크기는 반드시 소스 노드 볼륨의 크기보다 타깃 노드 볼륨의 크기가 같거나 커야 합니다.

  • 여기서 볼륨의 크기는 포맷한 이후의 파일시스템의 크기가 아닌 파티션의 크기를 의미하며 다음과 같이 powershell 명령라인에서 구할 수 있습니다.

	address 10.10.0.253: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

노드

• 구성파일 host 섹션에 호스트 이름을 기술해야 합니다.(floating peer 방식은 예외)

• 구성파일 host 섹션에 node-id 항목이 기술되어 있어야 합니다.

네트워크

• 미러링 주소와 포트에 대한 로컬 방화벽 예외정책을 추가해야 합니다.

• NIC 에 설정된 네트워크 주소가 net 섹션의 IP 주소로 기술되어야 합니다.

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.

Linux