환경
- SungEun Kim
구성 환경
bsr 은 물리 시스템 및 가상 시스템(VM), 하이퍼 컨버지드 인프라(HCI) 등 구성 환경에 제약이 없으며 로컬 네트워크와 WAN 네트워크 등 어떤 네트워크 환경에서도 유연하게 구성할 수 있습니다.
사양
다음은 BSR이 지원하는 플랫폼과 대상 시스템의 물리적 요구사양 입니다.
플랫폼
OS | CPU Architecture |
|---|---|
Windows 2012 이상 | x64 |
RHEL / CentOS 6.4 ~ 8.4 | x64 |
RHEL / Rocky 8.5 이상 | x64 |
Ubuntu 16 LTS 이상 | x64 |
ProLinux 7 이상 | x64 |
파일시스템
최근 복제 볼륨의 용량이 대용량화(수십~수백 테라바이트) 되어가고 있는 추세이고 그에 따라 복제 볼륨을 초기 동기화 하는데 상당히 많은 시간이 소요됩니다. 전체 볼륨 영역을 대상으로 초기동기화를 할 경우 많게는 수일에서 수십일이 걸리기도 합니다. 예를 들어, 1 Gbps 네트워크 대역폭에서 볼륨의 용량이 10 테라바이트 일 경우 전체 동기화를 완료 하려면 최소한 27 시간 이상, 100 TB 라면 열흘 이상 소요 됩니다.
우리는 이러한 초기 동기화가 오래 걸리는 문제를 해결하기 위해 빠른 동기화(이하 FastSync)를 구현하였습니다. FastSync 는 볼륨의 파일시스템에서 사용하는 영역에 대해서만 동기화 함으로써 초기 동기화 소요시간을 비약적으로 단축하는 기능입니다. 100TB 용량의 볼륨에서 실제 10GB 만 사용하고 있다면 1Gbps 대역에서 FastSync는 1분 내에 동기화를 완료 합니다.
FastSync 는 파일시스템 의존적 구현으로 다음의 파일 시스템에서 지원합니다. 그 이외의 파일 시스템들에 대해서는 전체 볼륨에 대해 동기화 합니다.
Windows 의 NTFS, ReFS
Linux의 Ext3, Ext4, xfs
CPU
최소 2GHz, 4 core 이상, x64 호환 프로세서에서 구성할 것을 권장합니다. 복제는 실시간 I/O 문맥에서 처리하므로 Latency 가 좋으려면 유휴 CPU 코어 자원에 상시 여유가 있어야 합니다.
메모리
시스템은 ��널 설정에 따라 다르지만 통상 메모리 사용량이 70~80% 를 넘을 때 가상메모리 페이징을 시작합니다. 페이징이 동작하면 시스템 I/O 성능의 저하가 발생하므로 20~30% 이상의 물리메모리 여유 공간을 확보하여 페이징 발생이 억제되도록 서버를 운영하는게 복제에 유리합니다.
페이징이 발생하는 시점은 시스템의 메모리 용량, 플랫폼, OS 버전에 따라 달라질 수 있습니다. 위에서 설명한 70~80%는 통상의 수치이므로 사용자 환경에 맞게 이해할 필요가 있습니다.
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) 버퍼는 로컬에서 발생한 I/O 데이터를 원격으로 전송하는데 따르는 지연을 완충하는 용도로 사용합니다. 이상적으로는 다음의 수식을 통해 산출한 크기로 지정합니다.
시간(s) 당 전송대역 최대 크기 * 전송 타임아웃 시간(s)
예를 들어, 1Gbps 대역의 경우 (약 100MB/s * 5s) = 500MB 로 구할 수 있으며 500MB ~ 1GB 로 여유 있게 설정하면 됩니다.
만약, WAN 구간의 변동대역을 추가로 고려해야 한다면 위 크기에 더해 WAN 병목 지연을 견뎌줄 시간(s)에 맞게 추가 용량을 더 증설하거나 프록시(DRX) 연동으로 버퍼링하면 됩니다. 보통, WAN 구간 버퍼링은 송신버퍼의 5 ~ 10 배 수준으로 지정됩니다.
최근 가상화 환경에서 VM 을 통한 복제 구성이 보편화 되어 가고 있는데, 개별 VM에 할당된 CPU 나 메모리 자원이 넉넉하지 않은 경우가 있습니다. 예를 들어, 개별 VM이 cpu 1core, 1~2GB 메모리로 구성될 경우 bsr 의 최소 구성사양에 충족되지 못합니다. 저사양 VM 으로 복제 환경이 구성되면 cpu 문맥 전환의 성능 지연, 그에 따라 노드 간 통신(keep alive) 지연이 빈번해 집니다. 이런 환경의 VM에서 복제를 운영하는 것은 제약이 심합니다. 이 문제를 해결하려면 시스템 자원을 넉넉하게 확보하는 것 이외에는 별다른 방법은 없습니다.
디스크
설치 공간
bsr 에서 사용하는 디스크 공간은 다음과 같습니다.
바이너리 실행 모듈들을 설치하는데 약 200MB 가 필요합니다.
bsr의 CLI 및 커널로그를 저장하기 위해 약 1GB가 필요합니다.
bsr의 성능로그를 기록하는데 리소스 볼륨당 약 2GB 가 필요합니다.
디스크 여유 공간에 맞게 로그 용량을 조정하려면 bsrcon 의 maxlogfile_cnt, climaxlogfile_cnt 옵션, bsrmon /set 을 통해 변경할 수 있습니다.
복제 디스크
이론적으로 bsr 의 복제 디스크의 용량은 제한이 없으나 실 사용 디스크 용량은 10TB 까지로 한정합니다. 복제 디스크 용량이 커질 수록 이에 대응되는 메타디스크 크기도 증가하여 메타 전반을 처리해야 하는 동작(Attach)에 시간이 많이 소요됩니다. 이는 리소스 기동(up)에 상당한 시간이 소요될 수 있다는 것을 암시합니다. 볼륨이 10TB 이상일 경우에는 파티션 분할을 통해 볼륨 크기를 조정할 것을 권장합니다.
다중볼륨
하나의 서비스 업무에 대응하는 저장소가 여러 볼륨으로 분리되어 구성되는 경우가 많은데, 이런 경우 이 볼륨들을 하나의 리소스로 취급해줄 필요가 있습니다. 이처럼 하나의 리소스에 다수의 볼륨을 묶어서 운영하는 것을 다중볼륨 구성이라고 합니다. 리소스를 다중볼륨으로 운영할 경우 데이터 처리 버퍼 큐가 단일 큐로 운영 됨으로써 서비스의 쓰기 I/O 순서를 디스크 볼륨으로 직렬화하여 서비스 측면의 정합성을 보장하게 합니다.
다중볼륨의 개수는 제한이 없지만(최대 65535) ���실적으로는 볼륨 개수가 많아 지면 큐 버퍼의 지연이 심해서 제어하기 어려울 수 있습니다. 10G 망에서 4~5개 볼륨 이하로 구성하는 것이 현실적입니다.
메타 디스크
복제 볼륨의 용량에 따라 필요한 메타디스크의 용량을 산정해야 합니다. 복제 볼륨 1TB 당 약 33MB 의 메타디스크 공간을 필요로 하고 보다 정확한 크기는 메타데이터 크기 추정의 내용을 참고합니다.
네트워크
대역폭
최근의 기업환경에서 로컬 네트워크에서의 미러링은 1 Gbps 에서 10 Gbps 대역폭까지 구성하는게 보편적이며 DR(Disaster Recovery)을 위한 원격 복제 환경(WAN 환경 복제)은 이보다 낮은 대역폭으로 운영되는게 일반적입니다. 즉 아주 낮은 대역폭(10~100Mbps)에서 부터 높은 대역폭에 이르기 까지 광범위한 네트워크 환경에 대해 적용됩니다. 단, 저대역 네트워크 환경에서는 대역폭의 한계를 극복하기 위한 복제 가속기의 연동을 고려해야 봐야 합니다.
포트
복제를 위한 미러링 포트(구성파일에서 지정함)가 열려있어야 합니다. 그리고 Windows 에선 제어용 TCP 루프백 5678, 5679 포트가 추가로 열려있어야 합니다.
스토리지 프로비저닝
스토리지 프로비저닝 방식 중 thick 프로비저닝 방식에 대해서만 지원합니다. 디스크 공간 회수 기능이 동작하는 thin 프로비저닝 환경은 bsr 과 호환하지 않습니다.