환경

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

플랫폼

Windows 2012 x64 이상, Linux CentOS 6.4, Ubuntu 16.04 LTS x64 이상의 플랫폼에서 동작합니다. 파일시스템은 NTFS, ReFS 와 ext 계열(ext3 이상), xfs 를 지원합니다. (FAT 계열 등 구형 파일시스템은 지원하지 않습니다.)

CPU

최소 2GHz, 4 core 이상 x86/x64 호환 프로세서에서 동작합니다.

메모리

시스템 메모리

시스템의 메모리는 최소 4GB 이상, 물리 메모리 사용량의 최소 30% 이상의 여유 공간을 확보하여 운영할 것을 권장합니다. 통상 운영체제가 메모리 부족에 대응하기 위해 페이징을 가동하는 시점을 물리 메모리 사용량의 70% 이상일 때로 간주합니다. 시스템에서 페이징이 가동되면 시스템 전반적으로 I/O 성능저하가 발생할 수 있으므로 이를 고려해야 합니다.

메모리 버퍼 크기

복제를 위한 메모리 버퍼는 로컬의 I/O 부하를 완충하는 용도로 사용하며 크기는 다음의 식으로 구합니다.

시간(초) 당 전송 최대 대역폭의 크기 * 타임아웃 시간(초)

1Gbps 의 경우, 약 100MB/s * 5s = 500MB 로 구할 수 있고 500MB 보다 좀 더 여유있게 500MB ~ 1GB 수준에서 구성하면 됩니다.

DR 구성을 위해 WAN 구간의 변동 대역을 고려해야 할 경우에는 DRX 연동을 통한 DRX 버퍼링으로 WAN 병목 상황에 대응합니다. DRX 연동을 하지 않을 경우에는 위에서 설명한 메모리 버퍼 크기를 더 확장해서 할당하고(메모리 버퍼의 2~3배), 메모리 공간의 여유가 없다면 파일버퍼로 구성하는 것을 고려합니다.(아래 내용 참고)

단, WAN 구간 복제(DR 구성) 시 메모리 버퍼의 크기가 대역의 크기에 비해 너무 크게 구성될 경우 버퍼에 쌓인 데이터 자체가 병목으로 작용하여 지연이 심화 될 수 있습니다(버퍼 블로트). 크게 구성된 버퍼 크기를 낮추고 적정선으로 조정하는 튜닝이 필요할 수 있습니다.

디스크

설치파일과 엔진 파일, 성능로그 등 기본 설치 시 약 2GB 가 필요합니다.
디버그용 파일로그를 위해 리소스 당 110MB 가 추가로 필요합니다.
파일 버퍼를 구성할 경우 해당 파일 버퍼의 크기 만큼의 디스크 공간이 필요합니다.
백업을 위한 스냅샷을 외부 디스크에서 운영할 경우 데이터 디스크 용량 만큼의 개별 디스크를 준비해야 합니다.
- 스냅샷을 데이터 디스크 내부에서 운영할 경우는 스냅샷을 위한 충분한 여유 디스크 공간을 보장해야 합니다.

파일버퍼

파일버퍼는 일반 파일을 버퍼 용도로 사용할 수 있는 기능입니다. 다만 파일 버퍼를 사용할 경우 기존 로컬 I/O 대비 성능저하가 발생할 수 있습니다. 성능저하를 최소화 하려면 파일버퍼를 위한 전용 디스크 볼륨을 구성하는 것이 좋습니다.

파일버퍼는 사용자의 용도에 맞게 크기를 조정하여 사용할 수 있고, 통상 메모리 버퍼의 5 ~ 10배 수준에서 크기를 설정합니다.

범위

일부 시스템 파일들에 대한 복제는 제외합니다. 이와 관련한 FSR에서 지원하는 구체적인 기능 범위에 대한 설명입니다.

디스크 경로

일반 로컬 디스크의 경로를 복제할 수 있습니다. NFS 와 같은 원격 경로는 복제할 수 없습니다(NFS 경로는 주기적 동기화의 소스 운영만 지원합니다).

파일 유형

다음의 파일 유형 들을 지원합니다.

일반 파일 및 디렉터리
링크 파일
- 소프트 링크
- 하드링크
- 정션, reparse point
스파스 파일
압축 파일
암호화 파일
특수 파일
- NTFS ADS(Alternate Data Stream)
- NTFS TxF(Transaction File)

OS에서 사용하는 시스템 파일들을 복제 대상으로 지정하지 않도록 주의해야 합니다. 시스템 파일들을 복제할 경우 시스템의 I/O 와 복제가 경쟁하는 등 예기치 않은 문제가 유발될 수 있습니다. 시스템 파일, 드라이버 파일, 스왑파일, OS 설치 경로(Windows 경로) 등이 해당됩니다.

링크파일은 다른 경로를 가리키는 파일입니다. 만약 복제 대상 내의 링크 파일이 복제 경로를 벗어난 외부 경로를 가리킬 경우 fsr 은 링크 파일 자체는 복제 하지만 링크가 가리키는 대상은 복제하지 않습니다. 링크파일이 가리키는 경로가 fsr 에 등록된 복제 대상 경로가 아니기 때문입니다. 따라서 링크파일이 가리키는 경로를 복제하고자 한다면 링크가 가리키는 해당 경로를 직접 복제 경로로 등록하여 구성할 것을 권장합니다.
한 파일을 링크한 하드링크들이 복제 경로 내부와 외부에 각각 존재할 수 있습니다. 이 경우 복제 대상이 아닌 외부 경로의 하드링크에 대한 변경점은 fsr에서 추적할 수 없으므로 복제 내부 경로에 위치한 하드링크 관점의 복제가 누락될 수 있습니다. 따라서 복제를 구성함에 있어서 하드링크가 복제 경로 내외부를 가로질러 링크하고 있는지 사전에 파악해야 합니다.

I/O 유형

Windows 와 Linux 에서 지원하는 대부분의 I/O 유형들을 지원합니다.

일반 I/O
- 버퍼 I/O (Buffered I/O, Cached I/O)
- 직접 I/O (Direct I/O, Non-Cached I/O)
메모리맵 I/O
특수 I/O
- linux
  - 비동기 I/O(aio)
  - 벡터 쓰기(writev)
  - splice I/O
  - uring I/O

리눅스의 Splice I/O 는 고속의 데이터 전송을 위해 zero copy 를 구현하는 특수 I/O 입니다. FSR 은 Splice I/O 를 캡쳐하여 복제할 수 있지만 Splice I/O 데이터를 복사하는 시간이 소요되면 결과적으로 오리지널 Splice I/O 대비 성능저하를 가져옵니다. 이는 데이터 복제를 구현하는데 따르는 불가피한 비용으로 Splice I/O 를 사용하는 응용프로그램의 데이터를 복제할 경우 이 점을 감안해야 합니다.

파일 속성

다음의 파일 속성들을 복제 합니다.

파일속성: 읽기전용, 숨김, 시스템, 디렉터리, 아카이브, 스파스, 압축, 암호화
보안속성: 소스파일의 보안식별자(SID, GID/UID) 또는 계정명
시간: 수정시간

위처럼 대부분의 파일 속성에 대해서 복제하지만 시간 속성에 대해선 수정시간만 복제하고 그 이외의 시간에 대해선 복제하지 않습니다. 예를 들어 소스와 타깃의 파일 접근시간은 복제할 수 없습니다.

Windows 의 파일 특성 중 장치 특성(FILE_ATTRIBUTE_DEVICE)과 가상 특성(FILE_ATTRIBUTE_VIRTUAL)은 시스템에 예약된 특성으로 복제에서 제외합니다.
Windows 10 에 추가된 OneDrive 와 관련된 다음의 파일 특성은 복제하지 않습니다.
- FILE_ATTRIBUTE_RECALL_ON_OPEN
- FILE_ATTRIBUTE_PINNED
- FILE_ATTRIBUTE_UNPINNED
- FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS

HA 운영을 위해선 소스와 타깃 시스템에 동일한 보안 계정 상태로 구성하는 것을 원칙으로 합니다. 그러나 소스와 타깃 시스템의 보안 구성상태를 완전히 동일하게 구성하는 것은 현실적으로 어렵고 고객사 보안 정책에 맞지 않을 수도 있습니다. FSR 은 소스와 타깃의 보안 구성상태가 다르더라도 소스 측 파일들의 보안식별자(SID) 기준으로 복제하여 최소한 복제 동작에는 문제가 없도록 합니다. 이 후 타깃에서 복제된 파일에 접근하기 위해선 타깃의 계정과 권한에 대한 조정 등 후속 조치가 따라야 합니다.

운영 방식

Active-Passive 클러스터링 운영을 기본으로 합니다.
프라이머리에서 세컨더리 노드로의 단방향 복제를 지원합니다. 환형 미러링, 이중 프라이머리 모드 등의 운영방식은 지원하지 않습니다.
비동기 방식의 복제를 지원하며 동기방식 복제는 지원하지 않습니다.