...
Supports Windows 2012 or higher, Linux CentOS 6.4, Ubuntu 16.04 LTS or higher x64 environment.
File systems
블럭복제 솔루션은 통상 파일시스템의 유형에 관계없이 동작합니다. 하지만 최근 복제 볼륨의 용량이 대용량화(수십~수백 테라바이트) 되어가고 있는 추세이고 그에 따라 복제 볼륨을 초기 동기화 하는데 소요되는 시간이 상당히 증가하고 있습니다. 많게는 수일에서 수십일이 소요되기도 합니다. 이것은 볼륨을 초기동기화 하는데 전체 디스크 볼륨을 대상으로 하기 때문입니다. 1 Gbps 네트워크 대역폭에서 볼륨의 용량이 10 테라바이트 일 경우 전체 동기화를 완료 하려면 아무리 빨라도 최소한 27 시간 이상, 100 TB 라면 열흘 이상 소요 됩니다.
우리는 이러한 과도한 동기화 소요 시간 문제를 해결하기 위해 빠른 동기화( 이하 FastSync)를 구현하였습니다. FastSync 는 복제 볼륨의 파일시스템에서 사용하고 있는 영역에 대해서만 동기화 하는 기능으로서 초기 동기화 소요시간을 비약적으로 개선하였습니다. 예를 들어 100TB 용량의 볼륨에서 실제 10GB 만 사용하고 있다면 1Gbps 대역에서 FastSync는 1분 내에 동기화를 완료 합니다. 다만 파일시스템의 특성을 사용하여 개발된 기능인 만큼 파일시스템 유형에 의존적으로 동작하고 그에 따라 파일시스템 유형에 대한 지원 명세를 갖게 되었습니다.
bsr 은 Windows 에서 일반적으로 사용하는 NTFS, ReFS 파일시스템을 지원하며 리눅스의 Ext 계열 파일시스템(ext3 이상), xfs 파일시스템을 지원합니다. 이 파일시스템들은 일반 사용자들이 가장 많이 사용하는 파일시스템 유형으로 이 이외의 파일시스템들에 대해서도 점차적으로 지원해 갈 계획입니다.
다만 bsr 의 FastSync에서 지원하지 않는 유형의 파일시스템들에 대해서 복제를 구성할 수 없는 것은 아닙니다. 단지 FastSync 를 사용할 수 없을 뿐 기존의 전체 동기화 방식으로 동작하므로 호환에 문제가 되지는 않습니다.
CPU
최소 2GHz, 4 core 이상, x64 호환 프로세서에서 구성할 것을 권장합니다. 이 보다 낮은 사양의 프로세서 환경에서도 동작하는데 문제는 없으나 시스템의 I/O 성능을 고려하면 되도록 구성 머신의 사양을 높게 확보할 필요가 있습니다.
메모리
대상 시스템의 물리적 메모리는 최소 4GB가 요구되고 비동기 복제를 위해 송신버퍼를 위한 메모리는 별도로 산정되어야 합니다. 송신버퍼용 메모리는 최소 20MB ~ 100MB 수준의 메모리 용량이 요구됩니다.
다만 복제 성능을 높이기 위해선 되도록 많은 물리적 메모리 자원을 확보하여 구성하는 것이 바람직 합니다.
| Info |
|---|
최근 가상화 환경에서 VM 을 통한 복제 구성이 보편화 되어 가고 있습니다. 이런 환경의 특징은 개별 VM에게 할당된 CPU 나 메모리 자원 상황이 넉넉하게 할당되지는 않는 다는 점 입니다. 예를 들어 개별 VM이 2core, 2~4GB 메모리로 구성될 경우 bsr 의 최소 구성사양에 충족되지 못하게 됩니다. 이렇게 저사양의 VM 으로 복제 환경이 구성될 경우 복제를 처리하는 bsr 엔진 쓰레드들 간의 문맥 전환 지연이 발생될 수 있으며 복제 양 노드 간의 네트워크 keep alive(ping) 지연이 빈번하게 발생될 가능성이 있습니다. 이런 환경에서 bsr 이 동작하게 되더라도 기본적인 동작에는 문제가 없지만, I/O 부하가 높아지거나 시스템의 HW 계층의 인터럽트 발생빈도가 높아질 경우 VM 전반의 성능이 하락되고 그에 따라 bsr 도 동작에 영향을 받게 됩니다. 이런 문제는 시스템 구성 자원을 넉넉하게 확보하는 방법 이외에는 특별한 해결책이 없습니다. |
디스크
기본 설치 공간
bsr 의 바이너리 실행 모듈들을 모두 설치하는데 약 200MB 정도가 필요하고 bsr의 로그를 저장하기 위해 1GB 가 요구되어 약 2GB 의 디스크 설치 공간을 필요로 합니다.
메타디스크
복제 볼륨의 용량에 따라 필요한 메타디스크의 용량을 산정해야 합니다. 복제 볼륨 1TB 당 약 33MB 의 메타디스크 공간을 필요로 하고 보다 정확한 크기는 메타데이터 크기 추정의 내용을 참고합니다.
네트워크
...
OS | CPU Architecture |
|---|---|
Windows 2012 or higher | x64 |
RHEL / CentOS 6.4 ~ 8.4 | x64 |
RHEL / Rocky 8.5 or higher | x64 |
Ubuntu 16 LTS or higher | x64 |
ProLinux 7 or higher | x64 |
File systems
Block replication solutions usually work regardless of the type of file system. However, bsr has a specification for supported file systems, as it implements fast synchronization that only synchronizes to the areas used by the file system.
Recently, the capacity of the replication volume has been increasing in capacity (several tens to hundreds of terabytes), and accordingly, the time required to initially synchronize the replication volume is increasing significantly. In many cases, it may take days to dozens of days. This is because the volume is initially synchronized because it targets the entire disk volume. If the volume is 10 terabytes in 1 Gbps network bandwidth, it will take at least 27 hours at least as fast as possible to complete the entire synchronization, and over 10 days if 100 TB.
We have implemented Fast Sync (FastSync) to solve this excessive sync time issue. FastSync is a function that synchronizes only the area used in the file system of the replication volume, dramatically improving the initial synchronization time. For example, if you are using only 10 GB of actual volume at 100 TB capacity, FastSync will complete synchronization within 1 minute in the 1 Gbps band. However, since it is a function developed using the characteristics of a file system, it depends on the file system type and has a support specification for the file system type accordingly.
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.
For 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 system typically starts paging virtual memory when memory usage exceeds 70%, depending on kernel settings. Because paging degrades system I/O performance, it is beneficial for replication to be configured to always have at least 30% free physical memory so that paging is suppressed.
The memory used by BSR is primarily required for buffering purposes and is determined by the maximum write request value (max-req-write-count) in the BSR settings and the size of the transmit buffer. Below is an example for a Windows environment.
For synchronous without a send buffer
At the default setting for write requests (10k), use a maximum of 1.5GB per resource.
At the write request maximum setting (100,000), use a maximum of 3 GB 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 a server with 64 GB of physical memory, approximately 20 GB (30%) of memory free space is required, and of the memory space used, a maximum of 2.5 GB per 1 resource is required for asynchronous by default.
If you don't have that 30% free memory, you'll have to accept a degradation in basic I/O performance due to paging.
The 3 to 4 GB NP memory usage per resource required by replication should be kept free, otherwise you will run out of memory, which can lead to failure.
Transmit buffer size
The size of the transmit (TX) buffer on the local side is ideally set to a number that allows for the free transfer of locally generated I/O data to the remote side. It is found by the following equation
Maximum size of transmit band per time (s) * Transmit timeout time (s)
For example, for a 1 Gbps band, you can get (about 100 MB/s * 5 s) = 500 MB, and you can set a buffer of 500 MB to 1 GB.
If you need to consider the variable bandwidth of the WAN segment, you can add more capacity to the above size plus the time (s) to tolerate the WAN bottleneck delay, or buffer it with a proxy (DRX). Typically, WAN leg buffering is specified at 5 to 10 times the TX buffer.
| 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 |
|---|
Recently, replication configurations through VMs are becoming more common in virtualization environments, but there are cases where the CPU or memory resources allocated to individual VMs are not sufficient. For example, if an individual VM is configured with 1 core CPU and 1~2GB memory, it will not meet the minimum configuration specifications of bsr. When a replication environment is configured with low-end VMs, performance delays due to frequent CPU context switching, and thus inter-node communication (keep alive) delays, become frequent. Operating replication on VMs in this environment has severe limitations. There is no solution to this problem other than freeing up system resources. |
Disk
Basic installation space
It requires about 200MB to install all the binary execution modules of bsr, and 1GB is required to store the log of bsr, which requires about 2GB of disk installation space.
Mirror disks
Theoretically, the capacity of a BSR's mirror disk is unlimited, but the actual disk capacity is limited to 10 TB. At higher capacity, the meta-area corresponding to the mirror disk capacity grows along with it, and the operation (Attach) that needs to process the entire meta-disk becomes time-consuming and impedes operations.
| Info |
|---|
Multi-volume Storage corresponding to one service task is often composed of multiple volumes. In this case, it is necessary to treat these volumes as one resource. In this way, operating multiple volumes by tying them to one resource is called a multi-volume configuration. When operating resources as multiple volumes, the data processing buffer queue is operated as a single queue, thereby serializing the service's write I/O order to the disk volume to ensure service consistency. There is no limit to the number of multiple volumes (maximum 65535), but in reality, as the number of volumes increases, the queue buffer delay may become severe and difficult to control. It is realistic to configure no more than 4 to 5 volumes in a 10G network. |
Meta Disk
Depending on the capacity of the replication volume, you need to estimate the capacity of the metadisk. It requires about 33MB of meta disk space per 1TB of the replication volume, and for more accurate size, see Metadata Size Estimation.
Network
throughput
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.
ports
The mirroring ports for replication (specified in the configuration file) must be open. On Windows, additionally TCP loopback ports 5678, 5679 must be open for control.
Storage provisioning
It is only supported for the THICK provisioning method of storage provisioning. Thin provisioning environments with disk space reclamation are not compatible with BSR.
| Info |
|---|
Disk space reclamation in THIN provisioning can cause data inconsistency issues in certain situations. To use a THIN environment, you must disable space reclamation. |