| Table of Contents |
|---|
구성 환경
bsr 은 기본적으로 물리 시스템 및 가상 시스템(VM), 하이퍼 컨버지드 인프라(HCI) 환경 등 구성 환경의 환경에 제약이 없으며 로컬 네트워크와 WAN 구간 원격 네트워크 환경 등 어떤 네트워크 환경에서도 유연하게 구성할 수 있습니다.
...
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는 다음의 파일시스템에 대해서만 동작하도록 구현하였습니다FastSync 는 파일시스템 의존적 구현으로 다음의 파일 시스템에서 지원합니다. 그 이외의 파일 시스템들에 대해서는 전체 볼륨에 대해 동기화 합니다.
Windows 의 NTFS, ReFS
Linux의 Ext 계열 파일시스템(ext3 이상)Ext3, Ext4, xfs
그 이외의 파일시스템들에 대해서는 기존의 전체 동기화 방식으로 동작합니다.
CPU
최소 2GHz, 4 core 이상, x64 호환 프로세서에서 구성할 것을 권장합니다. 복제는 실시간 I/O 문맥에서 처리하므로 Latency 가 좋으려면 유휴 CPU 코어 자원에 상시 여유가 있어야 합니다.
...
시스템은 커널 설정에 따라 다르지만 통상 메모리 사용량이 70~80% 를 넘을 때 가상메모리 페이징을 시작합니다. 페이징이 동작하면 시스템 I/O 성능의 저하가 발생하므로 20~30% 이상의 물리메모리 여유 공간을 확보하여 페이징 발생이 억제되도록 구성하는 게 서버를 운영하는게 복제에 유리합니다.
| Info |
|---|
페이징이 발생하는 시점은 시스템의 메모리 용량, 플랫폼, 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 데이터를 원격으로 전송하는데 따르는 지연을 완충하는 용도로 사용합니다. 이상적으로는 다음의 수식을 통해 산출한 크기로 지정합니다.
...
| Info |
|---|
최근 가상화 환경에서 VM 을 통한 복제 구성이 보편화 되어 가고 있는데, 개별 VM에 할당된 CPU 나 메모리 자원이 넉넉하지 않은 경우가 있습니다. 예를 들어, 개별 VM이 cpu 1core, 1~2GB 메모리로 구성될 경우 bsr 의 최소 구성사양에 충족되지 못합니다. 저사양 VM 으로 복제 환경이 구성되면 빈번한 cpu 문맥 전환의 성능 지연, 그에 따라 노드 간 통신(keep alive) 지연이 빈번해 집니다. 이런 환경의 VM에서 복제를 운영하는 것은 제약이 심합니다. 이 문제를 다루려면 해결하려면 시스템 자원을 넉넉하게 확보하는 것 이외에는 별다른 해결책은 방법은 없습니다. |
디스크
설치 공간
bsr 에서 사용하는 디스크 공간은 다음과 같습니다.
...
이론적으로 bsr 의 복제 디스크의 용량은 제한이 없으나 실 사용 디스크 용량은 10TB 까지로 한정합니다. 그 이상의 용량에선 복제 디스크 용량에 대응하는 메타 영역이 늘어나고 메타 용량이 커질 수록 이에 대응되는 메타디스크 크기도 증가하여 메타 전반을 처리해야 하는 동작(Attach)에 시간이 많이 소요되므로 소요됩니다. 이는 리소스 기동(up)에 상당한 시간을 소모할 수 있습니다. 그러므로 최대 볼륨을 10TB 로 한정하고 용량이 그 시간이 소요될 수 있다는 것을 암시합니다. 볼륨이 10TB 이상일 경우에는 파티션 분할을 통해 조정하는게 좋습니다볼륨 크기를 조정할 것을 권장합니다.
| Info |
|---|
다중볼륨 하나의 서비스 업무에 대응하는 저장소가 여러 볼륨으로 분리되어 구성되는 경우가 많은데, 이런 경우 이 볼륨들을 하나의 리소스로 취급해줄 필요가 있습니다. 이처럼 하나의 리소스에 다수의 볼륨을 묶어서 운영하는 것을 다중볼륨 구성이라고 합니다. 리소스를 다중볼륨으로 운영할 경우 데이터 처리 버퍼 큐가 단일 큐로 운영 됨으로써 서비스의 쓰기 I/O 순서를 디스크 볼륨으로 직렬화하여 서비스 측면의 정합성을 보장하게 합니다. 다중볼륨의 개수는 이론적으로는 제한이 없지만(최대 65535) 현실적으로는 볼륨 개수가 너무 많아 지면 버퍼 큐의 큐 버퍼의 지연이 심해져서 심해서 제어하기 어려울 수 있습니다. 1Gbps 10G 망에서 3개 4~5개 볼륨 이하로 구성하는 것이 적절합니다현실적입니다. |
메타 디스크
복제 볼륨의 용량에 따라 필요한 메타디스크의 용량을 산정해야 합니다. 복제 볼륨 1TB 당 약 33MB 의 메타디스크 공간을 필요로 하고 보다 정확한 크기는 메타데이터 크기 추정의 내용을 참고합니다.
네트워크
대역폭
최근의 기업환경에서 로컬 네트워크에서의 미러링은 1 Gbps 에서 10 Gbps 대역폭까지 구성하는게 보편적이며 DR(Disaster Recovery)을 위한 원격 복제 환경(WAN 환경 복제)은 이보다 낮은 대역폭으로 운영되는게 일반적입니다. 즉 아주 낮은 대역폭(10~100Mbps)에서 부터 높은 대역폭에 이르기 까지 광범위한 네트워크 환경에 대해 적용됩니다. 단, 저대역 네트워크 환경에서는 대역폭의 한계를 극복하기 위한 복제 가속기의 연동을 고려해야 봐야 합니다.
포트
복제를 위한 미러링 포트(구성파일에서 지정함)가 열려있어야 합니다. 그리고 Windows 에선 제어용 TCP 루프백 5678, 5679 포트가 추가로 열려있어야 합니다.
스토리지 프로비저닝
스토리지 프로비저닝 방식 중 thick 프로비저닝 방식에 대해서만 지원합니다. 디스크 공간 회수 기능이 동작하는 thin 프로비저닝 환경은 bsr 과 호환하지 않습니다.
| Warning |
|---|
thin 프로비저닝의 디스크 공간 회수가 특정 상황에서 데이터 정합성 불일치 문제를 야기 시킬 수 있습니다. thin 환경을 환경에서 사용하려면 공간회수 기능을 비활성화해야 합니다. |
...