개요

FSR(File Sync Replicator)은 커널 레벨 파일 I/O 캡처 필터, 유저 모드 복제/동기화 Syncer 엔진, 그리고 이를 제어·운영·감시하는 관리 도구로 구성되는 파일 레벨 복제 구조를 갖추고 있습니다. 이러한 계층적 구조는 실시간 복제와 주기적 기반 동기화를 동시에 지원하며, 정합성 검사, NFS 영역 처리 등 다양한 파일 관리 시나리오에서 유연하게 동작합니다.

파일 필터

구조의 핵심은 파일 필터 드라이버 계층입니다.
Windows에서는 Filesystem Minifilter, Linux에서는 stackable filesystem filter driver를 사용하여 파일 열기, 쓰기, 삭제, 메타데이터 변경 등 주요 파일 I/O를 커널 레벨에서 포착합니다. 수집된 변경 정보는 공유 메모리를 통해 상위 복제 엔진으로 전달되며, 복제 제외 필터와 파일락 정책과도 연동되어 데이터셋 단위로 정교하게 동작합니다.

유저 모드의 복제 엔진은 단방향 비동기 복제를 기본으로 하며, 캡처된 변경을 1차 메모리 버퍼와 2차 파일 버퍼에 적절히 저장하면서 타깃으로 전송합니다. 네트워크 대역보다 변경량이 많을 경우에는 버퍼링을 통해 변화량을 흡수하며, 버퍼 임계치를 초과하면 안전한 데이터 보호를 위해 버퍼 내용을 폐기하고 재동기화를 유도합니다. 이러한 구조는 타깃 데이터의 정합성을 유지하는 데 최적화되어 있습니다.

복제 엔진은 파일, 디렉터리, 권한, 보안 속성, 타임스탬프 등 주요 메타데이터를 함께 복제하여 장애 발생 시 Standby 노드를 즉시 승격하거나 페일백하는 과정에서도 일관성을 유지합니다.

동기화 엔진

FSR의 동기화 엔진(Syncer)은 커널 파일 필터가 캡처한 변경 분 복제 데이터를 상위 계층에서 수신·큐잉·전송하고, 여기에 초기/주기/비교 동기화 로직을 결합하여 처리하는 응용 엔진입니다.
실시간 복제 스트림 처리와 전체·증분·비교 동기화를 하나의 엔진에서 통합 제어함으로써, 다양한 환경에서 소스와 타깃 간 데이터 정합성을 유지하도록 설계되었습니다.

Syncer의 주요 역할

• 초기 동기화(Initial Full Sync)
  실시간 복제 시작 전에 전체 데이터를 대상으로 초기 동기화를 수행하여, 커널 파일 필터로부터 전달되는 변경 분이 적용되기 전에 소스와 타깃 간 기준 데이터 일치 상태를 확보합니다.

• 주기적 동기화 수행
  설정된 동기화 주기에 따라 정기적으로 동기화를 실행합니다.

• 증분/차이 기반 정합성 검증
  파일 크기, 수정 시간, 메타데이터 비교 등 증분/차이 기반 비교 기능을 제공하며, 필요 시 해시 검증과 연계하여 상태를 점검합니다.
  이를 통해 커널 파일 필터 기반 실시간 복제 경로와 동기화 엔진이 처리한 결과가 일관된지 확인하고, 차이가 있을 경우 재동기화 대상으로 지정할 수 있습니다.

• NFS 공유 파일 동기화
  실시간 I/O 후킹이 기술적으로 불가능한 NFS 공유, 외부 NAS 등 환경에 대해서는 Syncer가 파일 스캔·비교·복사를 통해 동기화를 수행합니다.
  이때도 복제 대상 정의, 제외 필터 정책을 그대로 활용하여, 실시간 복제와 유사한 수준의 데이터 범위 제어를 제공합니다.

Syncer의 기술적 특징

• 전체/증분/비교 모드 지원 및 열린/잠긴 파일 처리 옵션
  Syncer는 전체(Full), 증분(Incremental), 비교(Compare) 모드를 지원하며,

  • 열린 파일, 잠긴 파일을 동기화에 포함할지 여부,

  • 일관성 확보를 위한 재시도/스냅샷 연계 전략
    등을 옵션으로 제공하여 다양한 애플리케이션 환경에 대응합니다.

• 콜백 연동을 통한 HA/사용자 스크립트 연계
  동기화 시작·종료·중지 시점에는 콜백 핸들러를 호출하여 HA 스크립트 또는 사용자 프로그램과 연동할 수 있습니다.
  이를 통해 동기화 전후에 서비스 중지/재시작, 애플리케이션 플러시, 모니터링 알림 등 운영 절차를 자동화할 수 있습니다.

• 실시간 복제와의 연동 동작
  동기화 요청이 발생하면 Syncer가 우선적으로 동작하여 해당 시점 기준의 기준선을 정리하고, 이후에는 커널 파일 필터에서 전달되는 실시간 복제 데이터와 병행하여 동작합니다.
  즉, 동기화 엔진은

  • 커널 파일 필터로부터 수신한 실시간 변경 스트림을 처리하는 복제 경로와

  • 전체/증분/비교 동기화를 수행하는 배경 작업 경로를
    하나의 응용 엔진에서 통합 제어함으로써, 복제와 동기화가 서로 충돌하지 않고 보완적으로 동작하도록 조정합니다.

구성/제어

FSR은 리소스(Resource) 개념을 통해 복제·동기화 대상을 정의합니다.
구성 파일에는 소스/타깃 경로, 포함·제외 정책, 전역 데이터셋 설정, 노드 연결 정보 등이 포함되며, 소스와 타깃이 동일한 구성을 공유하도록 설계되어 있습니다.

운영자는 CLI, REST-API를 통해 다음 기능을 제어할 수 있습니다.

• 복제/동기화 시작, 중지, 일시중지, 재개

• 리소스 승격·강등(Active/Standby 전환)

• 대역폭 제한 및 시간대별 전송 정책

• 암호화 전송 설정

• 타깃 파일 보호(PID 기반 차단/허용)

• 구성 파일 검증 및 오류 방지

모니터링·통계·감시

FSR은 엔진 동작 상태와 성능을 실시간으로 모니터링할 수 있는 기능을 제공합니다.

• 리소스 역할, 연결 상태, 송·수신량, 시작 시각 등 상태 조회 기능을 제공합니다.

• 버퍼 사용률, 커널 캐시 사용률, 오버플로 횟수 등 성능 지표를 제공합니다.

• 네트워크 대역 분석 및 시뮬레이션 기능을 통해 용량 산정과 운영 정책 수립에 도움을 줍니다.

• 오류·경고·정보 메시지를 텍스트 파일로 기록하며, 로그 파일은 롤링 방식으로 관리됩니다.

• 상태 변경, 구성 변경, 제어 명령 등의 이벤트는 통지 기능을 통해 외부 시스템과 연동됩니다.

이 계층은 장애 분석, 리소스 최적화, 운영 자동화에 필수적인 구성 요소입니다.

설치·관리 및 외부 연동 계층

FSR은 복제 콘솔, MCCS, MDRM, DRX 등과 연동될 수 있도록 설계되어 있으며, CLI/REST-API를 통해 외부 서비스와의 통합 운영을 지원합니다.

주요 기능

동기화

FSR은 데이터 복제를 수행하기에 앞서, 소스 노드에 존재하는 전체 데이터를 타깃 노드로 한 번 완전히 복사하여 양측의 데이터 상태를 일치시키는 과정을 수행합니다. 이 과정을 동기화라고 합니다.

초기 동기화 시에는 대상 데이터셋 전체를 대상으로 동기화를 수행하여, 소스와 타깃 데이터가 완전히 동일한 상태가 되도록 합니다. 초기 동기화가 한 번 정상적으로 완료된 이후에는, 동일한 데이터셋에 대해 다시 전체 동기화를 수행하기보다는, 소스 노드에서 변경된 부분만을 추적하여 해당 변경분에 대해서만 부분 동기화(재동기화)를 수행함으로써 보다 효율적으로 동기화를 진행합니다.

부분 동기화는 다음과 같은 상황에서 자동으로 수행됩니다.

• 복제 수행 중 복제 네트워크 연결이 일시적으로 단절되었다가 재연결되는 경우

• 소스 또는 타깃 노드가 중단(reboot, 장애)된 뒤 재가동되어 복제 세션이 다시 연결되는 경우

• 일시적인 네트워크·시스템 장애 등으로 복제가 중단되었다가, 복제 상태가 “정상”으로 복귀하는 시점

즉, 초기 동기화가 완료된 이후에는, FSR이 내부적으로 변경 이력과 동기화 상태를 관리하면서 동기화가 필요하다고 판단되는 시점마다 자동으로 부분 동기화를 수행합니다. 관리자는 별도의 개입 없이도, 네트워크나 노드 상태가 정상으로 복귀되면 자동으로 재동기화가 진행된다는 점을 전제로 운영할 수 있습니다.

한편, 동기화는 자동 동기화뿐 아니라 사용자에 의한 수동 제어도 가능합니다. 관리자는 다음과 같은 방식으로 동기화를 직접 제어할 수 있습니다.

• 관리 콘솔 또는 CLI를 통해 특정 데이터셋에 대해 즉시 동기화를 수행하도록 명령

• 동기화 주기를 정책으로 설정하여, 특정 시간 간격 또는 특정 시간대(예: 야간, 비업무 시간)에 맞춰 정기적으로 동기화 수행

• 계획된 점검, DR 리허설, 데이터 마이그레이션 등과 같이 명시적으로 동기화 상태를 맞춰야 하는 시점에 수동 동기화 실행

이와 같이 FSR의 동기화 기능은

1. 초기 전체 동기화로 기준 상태를 맞춘 뒤,

2. 변경분 기반의 부분 동기화로 효율성을 확보하고,

3. 자동·수동 제어를 모두 지원하여 운영 편의성과 일관된 데이터 정합성을 동시에 제공하도록 지원합니다.

복제

데이터의 변경 분을 소스에서 타깃으로 실시간 반영하는 동작을 복제라고 합니다. 소스 데이터는 동기화가 진행 중인 상태에서도 계속 변경될 수 있으며, 이러한 변경은 동기화와는 별도로 복제 경로를 통해 실시간 전송됩니다. 즉, 동기화와 복제는 서로 독립된 경로와 로직으로 처리되며, FSR은 두 기능을 명확히 구분하여 동작합니다.

동기화와 복제 동작의 구분

• 동기화(Synchronization)

  • 초기 전체 동기화 및 재동기화가 있습니다.

  • 전체 동기화 대상을 디렉터리 단위로 목록화하고, 전용 동기화 작업자(worker)가 이 목록을 기반으로 파일/디렉터리를 순차적으로 처리합니다.

  • 주로 “기준선(Baseline)을 맞추는 작업”에 해당하며, 누락된 파일 복사, 사이즈/해시 비교를 통한 재전송, 삭제/이동 반영 등 파일 시스템 단위의 정합성 확보에 중점을 둡니다.

  • 동기화 중에도 애플리케이션은 계속 파일을 쓰기 때문에, 최신 변경 분은 복제 경로를 통해 별도로 타깃에 반영됩니다.

• 복제(Replication)

  • 애플리케이션이 파일에 쓰기(write) 연산을 수행할 때 발생하는 변경 분을, 해당 쓰기 I/O 문맥에서 가능한 한 지연 없이 타깃으로 전송·반영합니다.

  • 파일 시스템 상의 쓰기 경로에 표준필터 또는 훅(hook)으로 결합하여, 변경된 블록 또는 레코드를 캡처하고 이를 복제 버퍼로 복사한 뒤 네트워크를 통해 타깃 노드로 전송합니다.

  • “실시간 변경 반영”에 초점이 맞춰져 있으며, 쓰기 순서(Write Ordering) 보장, 장애 시 복구 지점(RPO) 최소화 등에 중요한 역할을 합니다.

두 기능 모두 “소스에서 타깃으로 데이터를 반영한다”는 점에서는 유사하지만,

• 동기화: 기준 상태를 맞추기 위한 배치(Background) 작업

• 복제: 실시간 변경을 반영하는 Online I/O 경로의 작업
  이라는 점에서 실질적으로는 완전히 다른 역할을 담당합니다. 따라서 FSR은 내부 설계 및 설정 항목에서 동기화와 복제를 분리하여 관리합니다.

복제 방식: 동기(Synchronous) vs 비동기(Asynchronous)

복제는 소스 쓰기 I/O를 어떻게 처리하느냐에 따라 동기 방식과 비동기 방식으로 구분됩니다.

1) 동기 복제(Synchronous Replication)

• 소스 노드에서 발생한 하나의 디스크 쓰기 I/O를,

  1. 로컬 디스크에 기록하고

  2. 타깃 노드의 디스크에도 기록이 완료되었음을 확인한 후

  3. 비로소 애플리케이션에 쓰기 완료를 반환하는 방식입니다.

• 이 방식은 소스와 타깃의 쓰기 성공 여부가 항상 함께 움직이므로, 타깃 데이터 정합성을 거의 완전히 보장할 수 있습니다(RPO ≒ 0에 가까운 구조).

• 다만, 쓰기 경로에 네트워크 왕복 지연(RTT) + 타깃 디스크 지연이 포함되기 때문에,

  • 타깃 노드의 응답 성능이 떨어지거나,

  • 네트워크 지연이 증가하는 경우
    로컬 I/O 지연 시간이 직접 증가하게 됩니다.

• 이로 인해, 지연에 민감한 트랜잭션 서비스나 고성능 OLTP 시스템을 동기 방식으로 구성할 경우 성능적인 제약과 튜닝 부담이 상당히 커질 수 있습니다.

2) 비동기 복제(Asynchronous Replication)

• 비동기 방식에서는 디스크 쓰기 I/O가 로컬 디스크에 반영되고, 복제 데이터가 내부 전송 버퍼에 안전하게 복사된 시점을 복제 완료로 간주합니다.

• 즉, 로컬 쓰기 I/O 완료 여부만을 기준으로 애플리케이션에 응답을 반환하며, 타깃 노드에 대한 전송 및 기록은 뒤에서 비동기적으로 처리됩니다.

• 이 방식은 네트워크 지연 및 타깃 디스크 성능이 소스의 로컬 I/O 지연에 직접적인 영향을 주지 않기 때문에,

  • 소스 애플리케이션 입장에서 높은 처리량과 낮은 지연 시간을 유지할 수 있습니다.

• 다만, 소스 노드에 갑작스러운 장애가 발생할 경우

  • 이미 로컬에 반영되었지만

  • 아직 타깃으로 전송·적용되지 못한 일부 데이터는 손실될 수 있습니다.

• 따라서 비동기 방식은 RPO(복구 시점 목표)가 0은 아니며, 네트워크 상태와 버퍼링 정책에 따라 “몇 초~수십 초 단위”의 지연을 허용하는 구조라고 볼 수 있습니다.

FSR은 기본적으로 비동기 방식 복제를 채택하여, 일반적인 파일 서버·업무 서버 환경에서 로컬 I/O에 대한 영향을 최소화하면서도 안정적인 복제 성능을 제공하도록 설계합니다.

비동기 복제의 버퍼링 구조와 설정

비동기 복제에서 핵심은 버퍼링 전략입니다. FSR은 로컬 I/O 지연을 줄이고, 네트워크 변동에도 안정적으로 동작하기 위해 내부적으로 다음과 같은 버퍼를 사용합니다.

• 메모리 버퍼 (Memory Buffer)

  • 쓰기 I/O 발생 시, 변경 데이터를 가장 먼저 수용하는 1차 버퍼입니다.

  • 매우 빠른 속도로 데이터를 수용할 수 있으나, 시스템 메모리 사용량에 직접적인 영향을 미칩니다.

  • 버퍼가 충분히 크면 순간적인 쓰기 폭주나 네트워크 지연이 있어도 데이터를 흡수할 수 있지만, 너무 크게 설정하면 다른 프로세스와의 메모리 경쟁을 유발할 수 있습니다.

• 파일 버퍼 (File/Spill Buffer)

  • 메모리 버퍼 여유가 부족해지는 경우, 디스크 상의 임시 파일 영역을 활용하여 복제 데이터를 저장합니다.

  • 메모리 버퍼보다 접근 속도는 느리지만, 상대적으로 큰 용량의 버퍼링 공간을 가질 수 있어 장시간 네트워크 장애나 타깃 노드 정체 상황에서도 복제 데이터를 보존할 수 있습니다.

  • 이 영역은 디스크 용량과 I/O 성능에 의존하므로, 충분한 용량 확보와 I/O 성능 검토가 필요합니다.

버퍼 크기 및 정책은 운영 환경에 맞게 조정해야 합니다.

• 시스템 가용 메모리, 디스크 용량, 네트워크 품질(RTT·대역폭), 예상 변경량(초당/분당 변경 데이터 규모)을 고려하여 적정 버퍼 크기를 설정해야 합니다.

• 버퍼가 너무 작으면

  • 네트워크 지연이나 타깃 측 처리 정체 발생 시 버퍼가 빠르게 포화되고,

  • 이 경우 FSR은 로컬 I/O에 **역압(Backpressure)**을 가하거나, 복제 지연이 급격히 증가하여 RPO가 커지는 문제가 발생할 수 있습니다.

• 버퍼를 충분히 확보해 두면

  • 일시적인 네트워크 장애나 타깃 노드 점검 동안에도 변경 데이터를 안전하게 쌓아두었다가

  • 네트워크가 복구되는 즉시 누적된 변경 분을 빠르게 전송하여 백로그를 해소할 수 있습니다.

요약

• 동기화는 전체/부분 기준선 맞추기용 배치 작업, 복제는 실시간 변경 반영으로 역할이 명확히 구분됩니다.

• 복제는 동기/비동기 방식으로 나뉘며,

  • 동기는 타깃 정합성을 극대화하는 대신, 지연·성능 비용이 크고

  • 비동기는 높은 성능과 낮은 지연을 제공하는 대신, 제한적인 RPO를 허용합니다.

• FSR은 기본적으로 비동기 복제 + 메모리/파일 버퍼링 구조를 사용하여,

  • 로컬 I/O 영향 최소화,

  • 일시적인 네트워크·타깃 정체에 대한 내성을 확보하도록 설계됩니다.

• 버퍼 크기와 정책은 시스템 자원 및 서비스 특성을 고려하여 조정해야 하며, 이는 복제 성능과 RPO에 직접적인 영향을 미치므로 운영 시 중요한 튜닝 포인트가 됩니다.

정합성 검증

정합성 검증은 소스 노드와 타깃 노드에 존재하는 복제 대상 파일 집합(파일 SET)에 대해, 파일 단위의 해시(Hash) 요약값을 생성하고 이를 목록화한 뒤 양측 목록을 실시간으로 비교하는 기능입니다. 각 파일에 대해 동일한 경로·크기·해시 값이 일치하는지를 확인함으로써, 두 노드 간에 데이터가 논리적으로 동일한 상태인지 여부를 판단합니다.

정합성 검증을 수행하면 다음과 같은 차이를 식별할 수 있습니다.

• 소스에는 존재하지만 타깃에는 존재하지 않는 파일

• 타깃에는 존재하지만 소스에는 존재하지 않는 파일

• 경로는 동일하지만 파일 크기가 다른 경우

• 크기는 같지만 해시 값이 달라, 내용이 변경된 것으로 판단되는 경우

이와 같은 비교 결과에 차이가 발견되면, FSR은 해당 파일 또는 디렉터리를 목록화하여 관리자가 인지할 수 있도록 알리고, 필요 시 재동기화 대상으로 지정하여 차이점을 해소할 수 있습니다. 재동기화는 차이가 있는 파일만을 선별적으로 다시 전송함으로써, 전체 동기화를 수행하는 것보다 적은 부담으로 정합성을 회복할 수 있습니다.

FSR은 정상적인 복제 운영 상태에서는 별도의 정합성 검증을 지속적으로 수행할 필요가 없습니다. 복제 엔진이 쓰기 변경 분을 실시간으로 처리하면서 소스와 타깃의 상태를 일치시키기 때문입니다. 다만, 다음과 같은 상황에서는 정합성 검증 기능이 매우 유용하게 사용될 수 있습니다.

• 타깃 측 파일 잠금이 일시적으로 해제되어, 운영 절차 밖에서 파일이 수정·삭제·추가되었을 가능성이 있는 경우

• 스토리지 장애, 파일 시스템 오류 등으로 인해 데이터 손상 가능성을 점검해야 하는 경우

• DR 훈련 이후, 원복(페일백) 과정에서 소스·타깃 간 데이터가 완전히 동일한지 검증하고 싶은 경우

• 이관/마이그레이션 작업 직후, “이전된 데이터가 손실 없이 그대로 존재하는지”를 확인하고 싶은 경우

• 보안 또는 컴플라이언스 측면에서, 타깃 데이터가 임의 조작 없이 원본과 동일하게 유지되고 있는지 정기적으로 감사하고자 하는 경우

정합성 검증은 파일 전체를 스캔하고 해시를 계산하는 작업 특성상 디스크 I/O와 CPU를 추가로 사용하게 됩니다. 따라서 대용량 데이터셋에 대해 빈번하게 실행할 경우, 서비스에 부하를 줄 수 있습니다. 이를 완화하기 위해 다음과 같은 운영 방식을 권장할 수 있습니다.

• 업무 비중이 낮은 야간/비업무 시간대에 주기적으로 정합성 검증을 수행

• 전체 대상이 아닌 특정 중요 디렉터리 또는 중요 서비스 데이터셋만 선별적으로 검증

• 파일의 변경 시간(mtime)·크기 등을 먼저 비교하고, 필요 시에만 해시 계산을 수행하는 방식으로 부하를 줄이는 정책 적용

이처럼 FSR의 정합성 검증 기능은 평상시 상시로 사용하는 기능이라기보다는,

• 데이터 이탈 여부를 확인하는 진단·감사 도구이자

• 의도되지 않은 변경을 추적하고, 필요한 경우 재동기화로 복구할 수 있게 해주는 보조 기능으로 이해할 수 있습니다.

스플릿브레인 감지

복제 운영 중 예기치 않은 장애나 구성 오류가 발생하면, 소스 측 데이터를 보호하기 위한 추가적인 안전장치가 필요합니다. 그 중 대표적인 위험 상황이 바로 **스플릿 브레인(split-brain)**입니다. 스플릿 브레인은 복제 네트워크가 단절된 상태에서 양쪽 노드가 서로를 보지 못한 채 동시에 Primary 역할을 수행하여, 서로 다른 방향으로 독립적인 쓰기 작업을 이어가는 상황을 의미합니다. 이 경우 연결이 다시 복구되었을 때, 어느 쪽 데이터가 기준이 되어야 하는지 판단하기 어려워지며, 잘못 처리할 경우 데이터 유실 또는 침묵적인 데이터 손상이 발생할 수 있습니다.

FSR 환경에서도, 연결 단절 이후 특정 시점에 두 노드가 모두 Primary(2 Primary)로 운영되는 잠재적 위험이 존재할 수 있습니다. 예를 들어,

• 네트워크 분리(Partition)로 서로를 장애로 오인하여 양쪽 모두 승격된 경우

• 클러스터/장애 조치(HA) 시스템 설정 오류로, 동시에 두 노드가 서비스 역할을 수행하도록 잘못 동작한 경우

• 운영자가 수동으로 역할을 변경하는 과정에서 절차 미준수로 인해 양쪽 노드가 모두 쓰기 가능 상태가 된 경우

와 같은 상황이 대표적입니다.

스플릿 브레인 감지 기능은 이러한 상태를 자동으로 감지하여, 복제를 계속 진행하면 데이터가 더 심각하게 꼬일 수 있다고 판단되는 경우 복제 흐름을 즉시 차단하는 역할을 합니다. 구체적으로는, 연결 재개 시점에 다음과 같은 정보를 바탕으로 스플릿 브레인 여부를 판단합니다.

• 양쪽 노드의 역할 정보(Primary/Secondary) 및 상태 이력

• 세션/세대 정보(Generation, Epoch 등)와 마지막으로 일치했던 동기화 시점

• 변경 이력 메타데이터를 기준으로, 두 노드가 서로 다른 쓰기 분기를 따라간 정황

스플릿 브레인으로 판단되면 FSR은 다음과 같은 조치를 취합니다.

1. 복제 세션을 자동 차단하여, 어느 한쪽 데이터가 다른 쪽 데이터를 무작정 덮어쓰지 못하도록 방지합니다.

2. 관리자에게 이벤트/알람을 발생시켜, 현재 상태가 스플릿 브레인 상황임을 명확히 인지할 수 있게 합니다.

3. 이후에는 관리자가

   • 기준이 될 노드를 선택하고(어느 쪽 데이터를 살릴 것인지 결정),

   • 선택된 기준 노드를 기준으로 반대편 노드를 재동기화하거나,

   • 필요 시 특정 디렉터리·파일 단위로 데이터를 분리·보존하는 등의 후속 조치를 수행할 수 있도록 유도합니다.

중요한 점은, 스플릿 브레인 감지 기능이 “이미 발생한 데이터 분기 자체를 막는 것”이 아니라, 그 상태를 빠르게 인지하여 추가적인 손상을 막고 안전하게 복구 절차로 넘기는 역할을 한다는 점입니다. 감지 기능이 없다면, 두 Primary 중 한쪽 데이터를 다른 한쪽이 무의식적으로 덮어써버려, 사후에 문제를 인지하더라도 원본을 되살리기 어려운 상황이 발생할 수 있습니다.

따라서 스플릿 브레인 감지는 복제 시스템에서 데이터 정합성과 신뢰성을 확보하기 위한 마지막 안전장치에 해당하며, 클러스터/HA 솔루션의 쿼럼·펜싱(fencing) 기능과 함께 복합적으로 고려되어야 합니다. 구체적인 탐지 조건, 로그 예시, 복구 절차 등은 문제 해결 절의 “스플릿 브레인” 항목을 참고하여 상세하게 확인할 수 있습니다.

스냅샷

복제 운영 중 장애로 인해 페일오버에 실패하거나, 랜섬웨어·악성코드 감염 등 보안 이슈로 인해 복제 타깃으로 직접 복구할 수 없는 상황이 발생할 수 있습니다. 또한 애플리케이션 오류나 운영자의 실수로 중요한 데이터가 논리적으로 손상되는 경우에도, 단순히 “최신 상태”로의 페일오버만으로는 문제가 해결되지 않을 수 있습니다. 이러한 상황에 대비하기 위해서는 주기적인 백업과 더불어 특정 시점으로의 복구(Point-in-Time Recovery) 수단을 확보하는 것이 중요합니다.

FSR은 스냅샷 기능을 통해 이러한 시점 복구를 지원합니다. 스냅샷은 스냅샷 생성 시점의 데이터 상태를 논리적으로 고정하여 보존하고, 이후 필요 시 해당 시점으로 되돌릴 수 있는 복구 지점을 제공합니다. 이를 통해 다음과 같은 시나리오에서 유용하게 활용할 수 있습니다.

• 페일오버 실패 후, 장애 발생 직전 시점으로의 롤백 복구

• 랜섬웨어·말웨어 감염이 의심되는 시점 이전의 “정상 시점”으로 복구

• 대규모 애플리케이션 배포·스키마 변경 등 위험도가 높은 작업 전, 안전한 복귀 지점 확보

• DR 훈련 후 원복(페일백) 과정에서 기준이 되는 특정 시점을 명확히 고정해 두고자 할 때

FSR은 스냅샷과 관련된 다음과 같은 인터페이스를 제공합니다.

• 스냅샷 생성:

  • 관리자는 콘솔 또는 CLI를 통해 복제 대상 볼륨/데이터셋에 대해 스냅샷을 생성할 수 있습니다.

  • 운영 정책에 따라 수동 생성뿐만 아니라, 일정 주기로 자동 스냅샷을 생성하도록 스케줄링할 수 있습니다.

• 스냅샷 관리:

  • 생성된 스냅샷 목록을 조회하고, 각 스냅샷의 생성 시각, 대상, 설명(주석) 등을 확인할 수 있습니다.

  • 더 이상 필요하지 않은 스냅샷은 선택적으로 삭제하여 스토리지 사용량을 회수할 수 있습니다.

  • 중요도가 높은 스냅샷은 보호(삭제 방지) 속성 등을 통해 임의 삭제를 방지하도록 운영할 수 있습니다(제품 설정에 따라 지원 범위 차이 가능).

• 스냅샷 스토리지 공간 조정:

  • 스냅샷은 일반적으로 변경분(델타)만을 저장하는 방식으로 구현되며, 데이터 변경량이 많을수록 스냅샷이 사용하는 공간도 증가합니다.

  • FSR은 스냅샷 전용 스토리지 용량을 설정하거나, 스냅샷 보존 개수·보존 기간에 대한 정책을 지정함으로써, 스냅샷으로 인한 스토리지 사용량을 관리할 수 있도록 인터페이스를 제공합니다.

  • 스냅샷 영역이 한도에 도달하는 경우 경고를 발생시키거나, 오래된 스냅샷부터 자동 정리하는 정책을 통해 스토리지 고갈을 예방할 수 있습니다.

• 스냅샷 복구(시점 복구):

  • 필요 시 특정 스냅샷을 선택하여 해당 시점의 데이터 상태로 복구를 수행할 수 있습니다.

  • 복구 방식은 환경에 따라 전체 볼륨을 해당 시점으로 롤백하는 방식, 별도 복구용 볼륨을 생성하는 방식 등으로 구성할 수 있습니다.

  • 복구 시에는 현재 데이터와의 차이, 서비스 영향 범위 등을 고려하여 사전 검토 후 적용하는 것이 권장됩니다.

스냅샷은 전통적인 백업을 대체하는 기능이 아니라, 백업을 보완하는 단기·근접 복구 수단으로 이해하는 것이 적절합니다. 백업은 장기 보존과 재해 수준의 장애에 대한 보호를 제공하고, 스냅샷은 상대적으로 짧은 기간 동안의 세밀한 시점 복구와 빠른 롤백에 강점을 갖습니다. 두 기능을 함께 운용함으로써 RPO(복구 시점 목표)와 RTO(복구 시간 목표)를 균형 있게 충족할 수 있습니다.

FSR은 이와 같은 스냅샷 생성, 관리, 복구, 스토리지 공간 조정을 포함하여 스냅샷 시점 복구와 관련된 일체의 인터페이스를 제공합니다. 스냅샷 동작 방식, 구성 방법, 운영 시 주의 사항 등에 대한 자세한 내용은 스냅샷 – FSR 1.2 절을 참고하시기 바랍니다.

용어

노드(Node)

네트워크에 연결된 장치를 통칭하는 용어입니다. 이 중 네트워크 주소(IP)가 할당되어 직접 통신이 가능한 장치를 보통 호스트(Host)라고 합니다.
실제 운영 환경에서는 노드와 호스트를 엄격히 구분하지 않고 사용하는 경우가 많으며, 본 매뉴얼에서도 특별한 언급이 없는 한 노드 = 호스트와 동등한 의미로 사용합니다.

FSR 관점에서 노드는 다음과 같은 특징을 갖습니다.

• 복제 프로세스(FSR 서비스)가 구동되는 단위

• 복제 리소스에서 Primary/Secondary 역할을 부여받는 단위

• 장애·페일오버·스플릿 브레인 등 복제 상태를 판단하는 기본 단위

클러스터(Cluster)

클러스터는 특정 목적을 위해 구성된 컴퓨터 노드들의 집합을 의미합니다. 본 매뉴얼에서 언급하는 클러스터는 일반적인 HA/컴퓨팅 클러스터가 아닌, 복제를 수행하기 위한 복제 클러스터를 지칭합니다.

• 복제 클러스터는 하나 이상의 소스 노드, 타깃 노드로 구성됩니다.

• 클러스터 내에서 각 노드는 Primary/Secondary와 같은 역할(Role)을 가집니다.

• FSR에서는 이러한 복제 클러스터를 리소스(Resource) 단위로 표현하며, 리소스 구성에 따라 클러스터의 구조와 동작이 결정됩니다.

필요에 따라 FSR 리소스는 단일 노드쌍(1:1)뿐만 아니라, 다수 노드가 참여하는 복잡한 클러스터 구조로 확장할 수 있습니다.

리소스(Resource)

리소스는 복제 리소스, 즉 복제 서비스를 제공하는 하나의 논리적 단위를 의미합니다.
하나의 리소스는 대체로 다음 요소로 구성됩니다.

• 노드(Node) 정보: 참여하는 소스·타깃 노드 목록 및 역할 정보

• 연결(Connection) 정보: 노드 간 복제 연결(엔드포인트, 포트, 프로토콜 등)

• 복제 대상 파일셋(File Set): 어떤 경로(디렉터리/파일)를 복제할지에 대한 정의 및 제외 정책

FSR에서는 리소스를 구성 파일(예: YAML/JSON 등 설정 파일)로 표현합니다. FSR 프로세스는 이 구성 파일을 읽어 복제 환경 및 설정을 해석하고, 해당 리소스를 기반으로 동기화·복제·정합성 검증 등의 작업을 수행합니다.

운영자는 리소스 단위로 복제 시작/중지, 상태 조회, 스냅샷, 정합성 검증 등의 관리 작업을 수행하게 됩니다.

Primary

복제 상의 원본 데이터가 존재하는 노드를 소스 노드(Source Node) 또는 간단히 소스(Source)라고 하며, 복제 클러스터 내에서 Primary 역할(Role)을 가집니다.

• Primary 노드는 복제와 동기화의 기본 기준점이 됩니다.

• 일반적인 운영에서는 Primary 노드에서 발생하는 쓰기 변경이 Secondary(타깃) 노드로 전파됩니다.

• 페일오버나 롤스왑(Role-Switch) 시에는 Secondary가 Primary로 승격될 수 있으며, 이 경우 복제 방향이 반전되거나 재구성됩니다.

Secondary

복제 상에서 원본 데이터 또는 실시간 변경 분 데이터를 수신하여 사본을 유지하는 노드를 타깃 노드(Target Node) 또는 타깃(Target)이라고 합니다. 이 노드는 복제 클러스터 내에서 **Secondary 역할(Role)**을 가집니다.

• Secondary 노드는 Primary에서 전달되는 변경 데이터를 반영하여, 가능한 한 동일한 상태의 복제본을 유지합니다.

• 장애 상황(Primary 장애, 네트워크 단절 후 복구 등)에서 Secondary는 페일오버 대상이 되며, 필요 시 Primary로 승격될 수 있습니다.

• 일부 토폴로지에서는 하나의 Secondary가 여러 리소스에 참여하거나, 다수 Primary로부터 데이터를 수신하는 구조도 구성할 수 있습니다(제품 지원 범위 내).

복제 대상

복제 대상은 리소스 내의 구성 요소로서, 복제가 수행되는 단위를 의미합니다. 파일 기반 복제에서는 다음과 같이 정의합니다.

• 복제 대상은 파일 또는 디렉터리 경로로 기술합니다.

• 각 복제 대상에는 제외 필터(Exclude Filter)를 설정할 수 있습니다.

  • 제외 필터는 복제 대상 경로 아래에 존재하지만, 복제하지 않을 파일·디렉터리를 지정하기 위한 정책입니다.

  • 와일드카드 패턴 또는 정규식 기반으로 기술하여, 특정 확장자, 임시 파일, 캐시 디렉터리 등을 손쉽게 제외할 수 있습니다.

복제 대상 정의를 통해, 운영자는 어떤 데이터는 반드시 복제해야 하고, 어떤 데이터는 복제하지 않아도 되는지를 세밀하게 제어할 수 있습니다. 이는 네트워크·스토리지 리소스를 효율적으로 사용하고, 불필요한 데이터 동기화를 줄이는 데 중요한 역할을 합니다.

정합성(Consistency)

정합성은 복제 데이터 정합성을 의미하며, 소스와 타깃의 데이터가 논리적으로 일치하는 상태를 말합니다.

• 파일 복제에서는 일반적으로 바이트 수준(Byte-level)의 데이터 정합성을 기준으로 합니다.

• 경로·파일명·파일 크기뿐만 아니라, 해시 값(Checksum)까지 동일한 경우를 “정합성이 확보된 상태”로 간주할 수 있습니다.

• FSR의 정합성 검증 기능은 이러한 기준에 따라 소스·타깃 간 차이를 탐지하고, 필요한 경우 재동기화를 통해 정합성을 회복할 수 있도록 지원합니다.

정합성은 복제 시스템의 핵심 품질 지표 중 하나이며, DR 환경에서는 RPO/RTO와 함께 반드시 고려해야 할 요소입니다.

스플릿 브레인(Split-Brain)

복제 클러스터 내에서 특정 시점에 2개 이상의 노드가 동시에 Primary 역할을 가지는 상태를 스플릿 브레인(Split-Brain)이라고 합니다. 이 상태에서는 각 노드가 서로 다른 방향으로 데이터를 변경·저장할 수 있으므로, 잠재적인 데이터 유실 및 데이터 불일치가 발생할 수 있습니다.

스플릿 브레인이 발생하면:

• 어떤 노드를 기준 데이터로 삼을지 결정해야 하고

• 나머지 Primary였던 노드는 “희생 노드”로 간주하여 그동안의 변경 내용을 폐기하거나 별도로 보관해야 합니다.

사용자는 스플릿 브레인 해결 절차를 통해:

1. 기준 노드(살릴 데이터를 가진 노드)를 선택하고

2. 희생 노드를 재동기화 또는 초기화한 뒤

3. 복제 리소스를 다시 정합성이 있는 상태로 정상화합니다.

FSR은 내부적으로 RID, 세션 정보 등을 이용하여 스플릿 브레인 상황을 감지하고, 자동으로 복제를 차단하는 스플릿 브레인 감지 기능을 제공합니다.

RID (Revision Identifier)

FSR은 복제 대상 파일셋 내 각 파일의 상태를 표현하기 위해, ULID 기반의 고유 번호를 유지·관리합니다. 이 값을 RID(Revision Identifier)라고 합니다.

RID는 다음과 같은 용도로 사용됩니다.

• 파일 또는 파일셋의 Revision(세대/버전) 상태를 추적

• 소스·타깃 간 RID 비교를 통해

  • 어느 쪽이 더 최신인지,

  • 어떤 방향으로 동기화를 수행해야 하는지(동기화 방향 결정) 판단

• 양 노드의 RID가 서로 다른 분기(Revision Branch)를 따라간 경우를 탐지하여, 스플릿 브레인 여부를 식별

즉, RID는 FSR 내부에서 정합성·동기화 방향·스플릿 브레인 감지를 위해 활용되는 핵심 메타데이터이며, 사용자는 이 값을 직접 수정하지 않고 상태 조회 및 문제 해결 과정에서 참고 정보로 활용하게 됩니다.

토폴로지(Topology)

토폴로지는 FSR 복제 환경에서 노드들 간 연결 구조(구성 방식)를 의미합니다. FSR은 복제 구성 환경에 따라 여러 형태의 토폴로지를 지원하며, 대표적으로 다음과 같은 유형이 있습니다.

• 메쉬(mesh)형 토폴로지