...
최근 복제 볼륨의 용량이 대용량화(수십~수백 테라바이트) 되어가고 있는 추세이고 그에 따라 복제 볼륨을 초기 동기화 하는데 상당히 많은 시간이 소요되고 있습니다. 전체 볼륨 영역을 대상으로 초기동화를 할 경우 많게는 수일에서 수십일이 걸리기도 합니다. 이것은 볼륨을 초기동기화 하는데 전체 디스크 볼륨을 대상으로 하기 때문입니다. 예를 들어, 1 Gbps 네트워크 대역폭에서 볼륨의 용량이 10 테라바이트 일 경우 전체 동기화를 완료 하려면 아무리 빨라도 최소한 27 시간 이상, 100 TB 라면 열흘 이상 소요 됩니다.
우리는 이러한 초기 동기화가 오래 걸리는 문제를 해결하기 위해 빠른 동기화(이하 FastSync)를 구현하였습니다. FastSync 는 복제 볼륨의 파일시스템에서 사용하고 있는 볼륨의 영역에 대해서만 동기화 하는 기능으로서 함으로써 초기 동기화 소요시간을 비약적으로 개선하였습니다단축하는 기능입니다. 예를 들어 100TB 용량의 볼륨에서 실제 10GB 만 사용하고 있다면 1Gbps 대역에서 FastSync는 1분 내에 동기화를 완료 합니다.
다만 FastSync는 파일시스템의 특성을 사용하기 때문에 파일시스템 유형에 의존적이며 따라서 통해 사용영역을 구하기 때문에 현재 다음의 파일시스템에 대해서만 동작하도록 제한되어 있습니다.
Windows 의 NTFS, ReFS
Linux의 Ext 계열 파일시스템(ext3 이상), xfs
위 파일 시스템들은 가장 많이 사용하는 파일시스템 유형으로서 향후 다른 파일시스템들에 대해서도 지원을 확장해 갈 예정입니다. FastSync에서 지원하지 않는 유형의 파일시스템들에 대해서는 기존의 전체 동기화 방식으로 동작합니다.
...
최소 2GHz, 4 core 이상, x64 호환 프로세서에서 구성할 것을 권장합니다. BSR 복제 엔진은 전용 쓰레드에 의해 실시간 I/O를 처리하므로 I/O Latency 를 좋게 하려면 이 처리를 뒷받침할 유휴 CPU 코어가 상시 준비되어 있어야 성능에 좋습니다좋은 성능을 발휘합니다.
메모리
시스템은 커널 설정에 따라 다르지만 통상 메모리 사용량이 70% 를 넘을 때 가상메모리 페이징을 시작합니다. 페이징이 동작하면 시스템 I/O 성능의 저하가 발생하므로 상시 30% 이상의 물리메모리 여유 공간을 확보하여 페이징 발생이 억제되도록 구성하는 게 복제에 유리합니다.
| Info |
|---|
|
BSR 에서 사용하는 메모리는 주로 버퍼링 용도로 필요하고, BSR 설정의 최대 쓰기 요청값(max-req-write-count)과 송신버퍼의 크기에 따라 결정됩니다. 아래는 Windows 환경의 예시입니다.
송신버퍼 없는 동기방식의 경우는
쓰기 요청 기본 설정(1만)에서 1리소스 당 최대 1.5GB를 사용합니다.
쓰기 요청 최대 설정(10만)에서 1리소스 당 최대 3GB를 사용합니다.
송신버퍼 1GB 설정에서 비동기 방식의 경우는
쓰기 요청 기본 설정에서 1리소스 당 최대 2.5GB를 사용합니다.
쓰기 요청 최대 설정에서 1리소스 당 최대 4GB를 사용합니다.
...
만약, WAN 구간의 변동대역을 추가로 고려해야 한다면 위 크기에 더해 WAN 병목 지연을 견뎌줄 시간(s)에 맞게 추가 용량을 더 증설하거나 프록시(DRX) 연동으로 버퍼링하면 됩니다. 보통, WAN 구간 버퍼링은 송신버퍼의 5 ~ 10 배 수준으로 지정됩니다.Info
페이징이 발생하는 시점은 시스템의 메모리 용량, 플랫폼, OS 버전에 따라 달라질 수 있습니다. 위에서 설명한 70%는 통상의 수치이므로 환경에 맞게 이해할 필요가 있습니다.
| Info |
|---|
최근 가상화 환경에서 VM 을 통한 복제 구성이 보편화 되어 가고 있습니다. 이런 환경의 특징은 개별 VM에 할당된 CPU 나 메모리 자원이 충분하게 할당 되지는 않는 다는 점 입니다. 예를 들어 개별 VM이 2core, 2~4GB 메모리로 구성될 경우 bsr 의 최소 구성사양에 충족되지 못할 수 있습니다. 이렇게 저사양의 VM 으로 복제 환경이 구성될 경우 bsr 엔진 내부의 성능 지연과 노드 간의 네트워크 통신(keep alive) 지연이 빈번하게 발생될 가능성이 높아집니다. 기본적인 동작에는 문제가 없지만 I/O 부하가 커지거나 시스템의 HW 계층의 인터럽트 발생빈도가 높아지게 되면 VM 전반의 성능이 하락되고 그에 따라 bsr 도 동작에 영향을 받게 됩니다. 결론적으로 결론은 저 사양의 VM 에서 복제 환경을 구축하는 것에는 성능적 제약이 따른다는 것 입니다. 이 문제에 대응할 방법은 문제를 다루려면 시스템 구성 자원을 넉넉하게 확보하는 방법 이외에는 별다른 해결책이 해결책은 없습니다. |
디스크
기본 설치 공간
bsr 의 바이너리 실행 모듈들을 모두 설치하는데 약 200MB 정도가 필요하고 bsr의 로그를 저장하기 위해 1GB 가 요구되어 약 2GB 의 디스크 설치 공간을 필요로 합니다.
...
이론적으로 bsr 의 복제 디스크의 용량은 제한이 없으나 실 사용 디스크 용량은 10TB 까지로 한정합니다. 그 이상의 용량에선 복제 디스크 용량에 대응하는 메타 영역이 같이 커져서 늘어나고 메타 디스크 전반을 처리해야 하는 동작(Attach)에 시간이 많이 소요되어 운영에 장애가 됩니다소요되므로 리소스 up 에 상당한 시간을 소모할 수 있습니다. 그러므로 최대 볼륨을 10TB 로 한정하고 용량이 그 이상일 경우에는 파티션 분할을 통해 조정하는게 좋습니다.
| Info |
|---|
다중볼륨 하나의 서비스 업무에 대응하는 저장소가 여러 볼륨으로 분리되어 구성되는 경우가 많은데, 이런 경우 이 볼륨들을 하나의 리소스로 취급해줄 필요가 있습니다. 이 처럼 이처럼 하나의 리소스에 다수의 볼륨을 묶어서 운영하는 것을 다중볼륨 구성이라고 합니다. 리소스를 다중볼륨으로 운영할 경우 데이터 처리 버퍼 큐가 단일 큐로 운영 됨으로써 서비스의 쓰기 I/O 순서를 디스크 볼륨으로 직렬화하여 서비스 측면의 정합성을 보장하게 합니다. 다중볼륨의 개수는 이론적으로는 제한이 없지만 실질적으로는 현실적으로는 볼륨 개수가 너무 많아 지면 버퍼 큐의 지연이 심해져서 제어하기 어려울 수 있습니다. 1Gbps 망에서 3개 볼륨 이하로 구성하는 것이 적절합니다. |
...