Table of Contents |
---|
Configuration Type
FSR typically supports the following configuration types:
1:1
1:1 replication configuration for source and target nodes.
Inc drawio | ||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
1:N
1: N replication configuration that simultaneously replicates one source node to multiple target nodes.
Inc drawio | ||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
N:1
N:1 replication method with multiple nodes as source and one node as target.
Inc drawio | ||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Local Replication
This is a way to specify the source and target of replication to one node. It is used to do local backup or local migration without separate target node.
Inc drawio | ||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Shared Volume Replication
A configuration in which one source data is shared by two (active-standby) nodes and replicates this source data to a third target node. This approach is used when a SAN-like storage shared volume is shared by two nodes simultaneously and replicated to DR in real time.
Inc drawio | ||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Periodic synchronization
This is a configuration method for volumes that only perform periodic synchronization. It does not perform real-time replication. In particular, volumes that cannot perform real-time replication, such as remote NAS shared volumes, can be backed up periodically using this method.
The target can be DAS or NAS, but in the case of NAS targets, FSR cannot be installed on the NAS, so it must be ensured that no writes occur to the target resource (to maintain consistency).
Inc drawio | ||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
However, be sure to specify synchronization for NFS shared volumes as a source only, and not as a synchronization target. Because NFS shared volumes are written to by multiple clients, you cannot control the FSR engine as a single synchronization target. For more information on this, see Periodic synchronization in the appendix.
Info |
---|
Replication to an NFS shared volume is technically impossible to track every change to the data being replicated in real time because, due to the nature of network shares, you cannot control every random client host that accesses the shared volume. |
Configuration File
The configuration file is a json format text file that describes the configuration type and attributes of the replication. It is described as a system configuration file and a resource configuration file. The system configuration file specifies node global paths necessary for FSR operation, and the resource configuration file describes the specifics of replication such as ip address, replication target, and handler. Basically, the configuration file should be created by hand. If you want to change the properties of a running resource, modify the configuration file and apply it by executing adjust command using CLI or REST-API.
The FSR engine prepares replication services by interpreting configuration files at resource startup and initializing node-to-node connections and replication target paths according to the configuration.
For details on the configuration file format, refer to Attributes.
System Config.
The system configuration file is a config.json file. If you do not specify a separate path, it is located in the path in %FSR_HOME%/conf/config.json.
After modifying the configuration file, run the program again or run the following update command.
fsradm config adjust
Resource Config.
The file format of the resource file is '*.res' and the path is specified in the 'options/resource_path' entry in the system configuration file.
The default value of resource_path is the current location ('.') and based on the location of the system configuration file, the default location is the same as the location of the config.json file.
The following is an example of a resource configuration file.
Code Block | ||||
---|---|---|---|---|
| ||||
{
"id": "r0",
"description": "test resource",
"auto_start": true,
"nodes": [
{
"name": "node1-hostname",
"urls": {
"repl": "10.20.200.75:9810",
"sync": "10.20.200.75:9811"
},
"directories": [
{
"path": "G:/test/r0",
"exclude_patterns": [
]
}
]
},
{
"name": "node2-hostname",
"urls": {
"repl": "10.20.200.76:9810",
"sync": "10.20.200.76:9811"
},
"directories": [
{
"path": "G:/test/r0",
"exclude_patterns": [
]
}
]
}
],
"connections": [
{
"node1": {
"name": "node1-hostname"
},
"node2": {
"name": "node2-hostname"
},
"buffer": {
"size": 1024
},
"network": {
"ping_interval": 10,
"compress": false,
"tls": false,
"limit": 0
}
}
],
"options": {
"exclude_patterns": [
]
}
} |
Info |
---|
The configuration file of an FSR is described in the json format, which describes one attribute as a key and value pair according to the json format. Depending on the type of property, it can be described in the form of object and array, with the object separated by braces and the array separated by square brackets. In addition, objects and arrays can be described in a mixture. |
Basic Config.
- Describes an ID to identify a resource.
- The replication target nodes are described in an array format in the nodes item. Describe the hostname, ip address: port in the node entry. You can also describe the name entry by IP address without describing hostname.
- The replication target is described as directories and files in the directories item. If necessary, provide additional exclusion patterns.
Connection Config.
Unless otherwise noted in the connections entry, all replicated nodes individually establish TCP connections. This is called a mesh network. In a mesh network, duplicate connections for n nodes are created by n * (n-1) / 2.
If you need to limit the replication connection or describe the connection information according to the operating situation, additionally describe the “connections” item. connections describes an individual connection as an array.
Each connection is a connection to two nodes and is described in the fixed items of node1 and node2. The node1.name and node2.name entries describe the same name as described in the node entry above so that the node entries match the connections.node1 and connections.node2 entries.
In the normal case, the network is replicated by configuring a mesh network instead of configuring individual connections.
Exclusion Pattern
Files that need to be excluded from the replication target can be excluded from the replication target through the exclusion pattern. Exclusion patterns can easily be described using wildcard (*,!) Symbols.
Buffer Config.
In asynchronous replication, real-time I/O changes are accumulated in the buffer and reflected in the target sequentially so that the target data can be kept up to date as long as buffering continues. Therefore, configuring a buffer is the most important aspect of FSR configuration. Before starting resources, the buffer capacity must be configured according to the operating environment.
The buffers are provided as kernel memory buffers that are fixedly allocated to the kernel (nonpaged pool) and file buffers that are allocated as files. Since the available kernel memory of the system is limited, it is necessary to estimate the memory buffer according to the memory situation of the system, and if the memory buffer space is insufficient, additional file buffers can be used. FSR takes priority of the memory buffer and switches to file buffering when the memory buffer is used up. If both buffers overflow, the buffering stops and the buffered data is discarded and moved to the resynchronization phase. Therefore, it is necessary to reserve as much buffering space as possible so that replication status remains.
In addition, these two types of buffers perform I/O to memory and files, so there is a fundamental difference in performance. In situations where the local system has a high I/O load, operating with more memory buffers is advantageous for performance.
Because buffers operate on a per-connection basis, for 1:N replication, you must separately specify as many as the number of connections.
Memory Buffer
Memory allocated by the kernel is limited in its available capacity. Allocating too much for the system's usable capacity can affect system performance and should be allocated at an appropriate level.
You can allocate up to several tens of gigabytes, and usually assign several gigabytes.
File Buffer
The file buffer can be allocated as much space as the space on the disk where the file buffer is located. Up to several tens of Tera Bytes can be allocated and can operate at large capacity, typically tens of gigabytes. If a file buffer is configured as a path of the system volume, it is recommended to operate as a separate disk path because file buffer read/write I/O can affect the overall system performance.
Configure DRX integration
To configure DRX integration for building a DR site, see Configuring file replication.