...
bsr supports NTFS and ReFS file systems commonly used in Windows, and Ext-like file systems (ext3 or higher) and xfs file systems in Linux. These file systems are the types of file systems most commonly used by general users, and we plan to gradually support other file systems.
Even so, it is not possible to configure replication for file systems that are not supported by bsr's FastSync. You can't just use FastSync, and it works with the existing full sync method, so there is no compatibility problemFor types of filesystems not supported by FastSync, it behaves as a traditional full sync.
CPU
It is recommended to configure at least 2GHz, 4 core or higher, x64 compatible processor. There is no problem in operating in a processor environment with a lower specification, but considering the I / O performance of the system, it is necessary to secure the specification of the configuration machine as high as possible.
Memory
The physical memory of the target system requires at least 4 GB, and the memory for the send buffer must be calculated separately for asynchronous replication. Memory for the send buffer requires a minimum memory capacity of 20MB to 100MB.
However, in order to improve replication performance, it is desirable to secure and configure as many physical memory resources as possible.
...
Systems typically start paging virtual memory when memory usage exceeds 70%, depending on kernel settings, and paging behavior degrades system I/O performance. To prevent replication from operating on poorly performing systems, it is in replication's best interest to always have at least 30% free physical memory so that paging is suppressed.
The memory used by BSR is based on non-paged physical memory, and on Windows, the maximum memory usage is determined by the maximum write request value (max-req-write-count) in the BSR settings and the size of the transmit buffer.
For synchronous without a send buffer
At the default setting for write requests (10k), use a maximum of 1.5 GB per resource.
At the maximum write requests setting (100k), use a maximum of 3GB per resource.
For asynchronous with a 1GB send buffer setting, use a maximum of 3GB per resource in the
Use a maximum of 2.5 GB per 1 resource at the write request default setting.
Use a maximum of 4 GB per resource at the Write Request Max setting.
For example, a server with 64 GB of physical memory requires approximately 20 GB (30%) of memory free, and of the memory space used, BSR requires a maximum of 2.5 GB of memory space per 1 resource in the Async preference.
If you don't have 30% free memory, you'll have to live with basic I/O performance degradation due to paging. However, the 3-4 GB NP memory usage per resource required by replication must be kept free, or it can lead to failures due to insufficient memory resources.
| Info |
|---|
When paging occurs can vary depending on your system's memory capacity, platform, and OS version. The 70% figure described above is typical and should be understood in the context of your environment. BSR memory usage on Linux is similar or less than on Windows. It uses a bit more memory on Windows due to some differences in the replication architecture. |
| Info |
|---|
Replication configurations with VMs are becoming increasingly common in virtualized environments. A characteristic of these environments is that the CPU or memory resources allocated to individual VMs are not always sufficient. For example, if an individual VM is configured with 2core, 2 to 2 cores and 2-4 GB of memory, it may not meet the minimum configuration of bsr will not be metspecifications for bsr. When a replication environment is configured with a such low-spec VM, there may be a context switching delay between bsr engine threads that process replication, and a network keep alive (ping) delay between both nodes of replication may occur frequently. Even if bsr operates in such an environment, there is no problem in basic operation, but if VMs, it is more likely to experience frequent performance delays inside the bsr engine and network communication (keep alive) delays between nodes. While there is no problem with the basic behavior, as the I/O load increases or the frequency of occurrence of interrupts in the HW layer of the system increases, the overall performance of the VM decreasesas a whole will decrease, and bsr also affects the operation accordingly. .There is no special solution to this problem other than to free up will be affected accordingly. The bottom line is that building a replication environment on low-specification VMs has limitations. There's not much you can do about it except to make sure you have plenty of system configuration resources. |
...
In a recent corporate environment, mirroring on a local network is generally configured with a bandwidth of 1 Gbps to 10 Gbps, and a remote replication environment (Disaster Recovery) for DR (Disaster Recovery) is generally operated with a lower bandwidth. That is, it is applied to a wide range of network environments from very low bandwidth (10 ~ 100Mbps) to high bandwidth. However, because replication in a low-band network environment is bound to affect replication performance due to bandwidth limitations, consider such as linking replication accelerators for performance improvement.
Storage provisioning
Of the storage provisioning methods on the virtualisation platform, only thick provisioning is supported. For thin provisioning, the disk space reclamation feature is incompatible with block replication operationsIt is only supported for the THICK provisioning method of storage provisioning. Thin provisioning environments with disk space reclamation are not compatible with BSR.
| Info |
|---|
In a THIN provisioning environment, disk space reclamation causes data inconsistency issues under certain circumstances, and care should be taken to avoid installing or operating in thin environments. |
...