구성 환경

bsr 은 기본적으로 물리 시스템 및 가상 시스템(VM), 하이퍼 컨버지드 인프라(HCI) 환경 등 구성 환경의 제약이 없으며 로컬 네트워크와 WAN 구간 원격 네트워크 환경 등 어떤 네트워크 환경에서도 유연하게 구성할 수 있습니다.

사양

다음은 BSR이 지원하는 플랫폼과 대상 시스템의 물리적 요구사양 입니다.

플랫폼

Windows 2012 이상, Linux CentOS 6.4 이상, Ubuntu 16.04 LTS 이상, ProLinux 7 이상, Rocky 8.5 이상 x64 환경을 지원합니다.

파일시스템

블럭복제 솔루션은 기본적으로 파일시스템의 유형에 관계없이 동작하지만 bsr 은 파일시스템에서 사용하는 영역에 대해서만 동기화 하는 빠른 동기화를 구현함에 따라 지원 파일 시스템에 대한 명세를 가집니다.

최근 복제 볼륨의 용량이 대용량화(수십~수백 테라바이트) 되어가고 있는 추세이고 그에 따라 복제 볼륨을 초기 동기화 하는데 상당히 많은 시간이 소요되고 있습니다. 많게는 수일에서 수십일이 걸리기도 합니다. 이것은 볼륨을 초기동기화 하는데 전체 디스크 볼륨을 대상으로 하기 때문입니다. 1 Gbps 네트워크 대역폭에서 볼륨의 용량이 10 테라바이트 일 경우 전체 동기화를 완료 하려면 아무리 빨라도 최소한 27 시간 이상, 100 TB 라면 열흘 이상 소요 됩니다.

우리는 이러한 초기 동기화가 오래 걸리는 문제를 해결하기 위해 빠른 동기화(이하 FastSync)를 구현하였습니다. FastSync 는 복제 볼륨의 파일시스템에서 사용하고 있는 영역에 대해서만 동기화 하는 기능으로서 초기 동기화 소요시간을 비약적으로 개선하였습니다. 예를 들어 100TB 용량의 볼륨에서 실제 10GB 만 사용하고 있다면 1Gbps 대역에서 FastSync는 1분 내에 동기화를 완료 합니다.

다만 FastSync는 파일시스템의 특성을 사용하기 때문에 파일시스템 유형에 의존적이며 따라서 다음의 파일시스템에 대해서만 동작하도록 제한되어 있습니다.

Windows 의 NTFS, ReFS
Linux의 Ext 계열 파일시스템(ext3 이상), xfs

위 파일 시스템들은 가장 많이 사용하는 파일시스템 유형으로서 향후 다른 파일시스템들에 대해서도 지원을 확장해 갈 예정입니다. FastSync에서 지원하지 않는 유형의 파일시스템들에 대해서는 기존의 전체 동기화 방식으로 동작합니다.

CPU

최소 2GHz, 4 core 이상, x64 호환 프로세서에서 구성할 것을 권장합니다. BSR 복제 엔진은 전용 쓰레드에 의해 실시간 I/O를 처리하므로 I/O Latency 를 좋게 하려면 이 처리를 뒷받침할 유휴 CPU 코어가 상시 준비되어 있어야 성능에 좋습니다.

메모리

시스템은 커널 설정에 따라 다르지만 통상 메모리 사용량이 70% 를 넘을 때 가상메모리 페이징을 시작합니다. 페이징이 동작하면 시스템 I/O 성능의 저하가 발생하므로 상시 30% 이상의 물리메모리 여유 공간을 확보하여 페이징 발생이 억제되도록 구성하는 게 복제에 유리합니다.
BSR 에서 사용하는 메모리는 주로 버퍼링 용도로 필요하고, BSR 설정의 최대 쓰기 요청값(max-req-write-count)과 송신버퍼의 크기에 따라 결정됩니다. 아래는 Windows 환경의 예시입니다.
- 송신버퍼 없는 동기방식의 경우는
  - 쓰기 요청 기본 설정(1만)에서 1리소스 당 최대 1.5GB를 사용합니다.
  - 쓰기 요청 최대 설정(10만)에서 1리소스 당 최대 3GB를 사용합니다.
- 송신버퍼 1GB 설정에서 비동기 방식의 경우는
  - 쓰기 요청 기본 설정에서 1리소스 당 최대 2.5GB를 사용합니다.
  - 쓰기 요청 최대 설정에서 1리소스 당 최대 4GB를 사용합니다.

64GB의 물리메모리를 가진 서버의 경우 약 20GB(30%)의 메모리 여유공간이 필요하며 사용된 메모리 공간 중 비동기방식 기본설정에서 1 리소스당 최대 2.5GB의 메모리 공간이 요구됩니다.

만약 30% 수준의 메모리 여유공간 확보가 불가한 상황이라면 페이징 발생에 따른 기본적인 I/O의 성능저하는 감수해야 합니다.
복제에서 필요로 하는 1 리소스 당 3~4GB NP 메모리 사용량은 여유공간으로 유지시켜 주어야 합니다. 그렇지 않을 경우 메모리가 부족해져서 장애로 이어질 수 있습니다.

송신버퍼 크기

로컬의 송신(TX) 버퍼의 크기는 (시간 당 전송대역의 최대 크기 * 전송 타임아웃) 의 공식으로 구합니다. 1Gbps 대역의 경우 (약 100MB/s * 5s) = 500MB 가 되므로 여유 있게 500MB ~ 1GB 정도로 설정하면 됩니다.

페이징이 발생하는 시점은 시스템의 메모리 용량, 플랫폼, OS 버전에 따라 달라질 수 있습니다. 위에서 설명한 70%는 통상의 수치이므로 환경에 맞게 이해할 필요가 있습니다.
리눅스에서의 BSR 메모리 사용량은 윈도우즈에 비해 비슷하거나 덜 사용합니다. 복제 아키텍처에서 다소 차이가 있어서 윈도우즈에서 메모리를 좀 더 사용합니다.

최근 가상화 환경에서 VM 을 통한 복제 구성이 보편화 되어 가고 있습니다. 이런 환경의 특징은 개별 VM에 할당된 CPU 나 메모리 자원이 충분하게 할당 되지는 않는 다는 점 입니다. 예를 들어 개별 VM이 2core, 2~4GB 메모리로 구성될 경우 bsr 의 최소 구성사양에 충족되지 못할 수 있습니다. 이렇게 저사양의 VM 으로 복제 환경이 구성될 경우 bsr 엔진 내부의 성능 지연과 노드 간의 네트워크 통신(keep alive) 지연이 빈번하게 발생될 가능성이 높아집니다. 기본적인 동작에는 문제가 없지만 I/O 부하가 커지거나 시스템의 HW 계층의 인터럽트 발생빈도가 높아지게 되면 VM 전반의 성능이 하락되고 그에 따라 bsr 도 동작에 영향을 받게 됩니다. 결론적으로 저 사양의 VM 에서 복제 환경을 구축하는 것에는 제약이 따른다는 것 입니다.

이 문제에 대응할 방법은 시스템 구성 자원을 넉넉하게 확보하는 방법 이외에는 별다른 해결책이 없습니다.

디스크

기본 설치 공간

bsr 의 바이너리 실행 모듈들을 모두 설치하는데 약 200MB 정도가 필요하고 bsr의 로그를 저장하기 위해 1GB 가 요구되어 약 2GB 의 디스크 설치 공간을 필요로 합니다.

복제 디스크

이론적으로 bsr 의 복제 디스크의 용량은 제한이 없으나 우리가 실제 검증한 복제 볼륨의 크기는 40TB 입니다. 최대 복제 볼륨의 크기를 40TB 로 제한합니다.

메타 디스크

복제 볼륨의 용량에 따라 필요한 메타디스크의 용량을 산정해야 합니다. 복제 볼륨 1TB 당 약 33MB 의 메타디스크 공간을 필요로 하고 보다 정확한 크기는 메타데이터 크기 추정의 내용을 참고합니다.

네트워크

최근의 기업환경에서 로컬 네트워크에서의 미러링은 1 Gbps 에서 10 Gbps 대역폭까지 구성하는게 보편적이며 DR(Disaster Recovery)을 위한 원격 복제 환경(WAN 환경 복제)은 이보다 낮은 대역폭으로 운영되는게 일반적입니다. 즉 아주 낮은 대역폭(10~100Mbps)에서 부터 높은 대역폭에 이르기 까지 광범위한 네트워크 환경에 대해 적용됩니다. 단, 저대역 네트워크 환경에서는 대역폭의 한계를 극복하기 위한 복제 가속기의 연동을 고려해야 봐야 합니다.

스토리지 프로비저닝

스토리지 프로비저닝 방식 중 thick 프로비저닝 방식에 대해서만 지원합니다. 디스크 공간 회수 기능이 동작하는 thin 프로비저닝 환경은 bsr 과 호환하지 않습니다.

thin 프로비저닝의 디스크 공간 회수가 특정 상황에서 데이터 정합성 불일치 문제를 야기 시킬 수 있습니다. thin 환경을 사용하려면 공간회수 기능을 비활성화해야 합니다.