GFS2

컴퓨팅에서 글로벌 파일 시스템 2(, GFS2)는 리눅스 컴퓨터 클러스터를 위한 공유 디스크 파일 시스템이다. 데이터를 클러스터 전체에 분산시키는 분산 파일 시스템과 달리, GFS2는 클러스터의 모든 멤버가 동일한 공유 블록 스토리지에 직접 동시에 접근할 수 있도록 한다. GFS2는 단일 컴퓨터에서 로컬 파일 시스템으로 사용될 수도 있다.

GFS2는 연결 해제 작동 모드가 없으며, 클라이언트나 서버 역할도 없다. GFS2 클러스터의 모든 노드는 피어(peer)로서 작동한다. 클러스터에서 GFS2를 사용하려면 공유 스토리지에 대한 접근을 허용하는 하드웨어와 스토리지 접근을 제어하기 위한 잠금 관리자가 필요하다. 잠금 관리자는 별도의 모듈로 작동한다. 따라서 GFS2는 클러스터 구성을 위해 분산 잠금 관리자(DLM)를 사용하고, 로컬 파일 시스템을 위해 "nolock" 잠금 관리자를 사용할 수 있다. 이전 버전의 GFS는 장애 조치(failover)를 통해 중복성을 구현하는 서버 기반 잠금 관리자인 GULM도 지원한다.

GFS와 GFS2는 자유 소프트웨어이며, GNU 일반 공중 사용 허가서의 약관에 따라 배포된다.

 역사 
GFS의 개발은 1995년에 시작되었으며 원래 미네소타 대학교 교수인 매튜 오키프(Matthew O'Keefe)와 학생들에 의해 개발되었다. 원래 실리콘 그래픽스(SGI)의 IRIX 운영체제용으로 작성되었으나, 오픈 소스 코드가 더 편리한 개발 플랫폼을 제공했기 때문에 1998년에 리눅스 (2.4)로 이식되었다. 1999년 말 또는 2000년 초에 Sistina Software로 넘어갔으며, 그곳에서 한동안 오픈 소스 프로젝트로 유지되었다. 2001년에 Sistina는 GFS를 독점 제품으로 만들기로 결정했다.

개발자들은 GFS의 마지막 공개 릴리스에서 OpenGFS를 분기(fork)한 다음, OpenDLM과 함께 작동할 수 있도록 업데이트를 포함하여 더욱 향상시켰다. 그러나 레드햇이 2003년 12월에 Sistina를 인수하고 2004년 6월 말에 GFS와 많은 클러스터 인프라 구성 요소를 GPL 하에 출시하면서 OpenGFS와 OpenDLM은 중단되었다.

레드햇은 이후 버그 수정 및 안정화에 중점을 둔 추가 개발에 자금을 지원했다. 추가 개발된 GFS2는 GFS에서 파생되었으며 리눅스 2.6.19에서 (GFS와 공유되는) 분산 잠금 관리자와 함께 포함되었다. 레드햇 엔터프라이즈 리눅스 5.2는 평가 목적으로 GFS2를 커널 모듈로 포함했다. 5.3 업데이트와 함께 GFS2는 커널 패키지의 일부가 되었다.

GFS2는 페도라, 레드햇 엔터프라이즈 리눅스 및 관련 CentOS 리눅스 배포판의 일부를 구성한다. 사용자는 레드햇 엔터프라이즈 리눅스 위에서 GFS2를 완전히 지원받으며 실행하기 위해 상업적 지원을 구매할 수 있다. 레드햇 엔터프라이즈 리눅스 8.3부터 GFS2는 공유 스토리지 장치를 사용할 수 있는 클라우드 컴퓨팅 환경에서 지원된다.

다음 목록은 일부 버전 번호와 도입된 주요 기능을 요약한 것이다.

 v1.0 (1996) SGI IRIX 전용
 v3.0 리눅스 이식
 v4 저널링
 v5 중복 잠금 관리자
 v6.1 (2005) 분산 잠금 관리자
 리눅스 2.6.19 - GFS2 및 DLM이 리눅스 커널에 통합됨
 레드햇 엔터프라이즈 리눅스 5.3에서 처음으로 완전히 지원되는 GFS2 출시

 하드웨어 
GFS 및 GFS2의 설계는 스토리지 에어리어 네트워크(SAN)와 같은 환경을 대상으로 한다. 단일 노드 파일 시스템으로 사용하는 것도 가능하지만, 모든 기능을 활용하려면 SAN이 필요하다. 이는 ISCSI, 파이버 채널, ATA 오버 이더넷(AoE), 또는 리눅스에서 여러 노드가 공유하는 블록 장치(예: DRBD 장치)로 나타낼 수 있는 다른 장치의 형태를 취할 수 있다.

분산 잠금 관리자(DLM)는 통신을 위해 IP 기반 네트워크가 필요하다. 이는 일반적으로 이더넷이지만, 다른 많은 가능한 해결책이 있다. SAN 선택에 따라 이를 결합할 수도 있지만, 일반적인 관행은 DLM과 스토리지를 위해 별도의 네트워크를 사용하는 것이다.

GFS는 어떤 형태의 펜싱 메커니즘을 필요로 한다. 이는 GFS/GFS2 자체보다는 클러스터 인프라의 요구 사항이지만, 모든 다중 노드 클러스터에 필요하다. 일반적인 옵션에는 전원 스위치 및 원격 접근 컨트롤러(예: 델 DRAC, IPMI 또는 ILO)가 포함된다. 가상 및 하이퍼바이저 기반 펜싱 메커니즘도 사용할 수 있다. 펜싱은 클러스터가 실패했다고 판단한 노드가 다른 노드가 실패한 노드의 저널을 복구하는 동안 갑자기 다시 작동을 시작하지 못하도록 보장하는 데 사용된다. 또한 복구가 완료되면 선택적으로 실패한 노드를 자동으로 재시작할 수 있다.

 로컬 파일 시스템과의 차이점 
GFS/GFS2 설계자들이 로컬 파일 시스템을 가깝게 모방하는 것을 목표로 했지만, 주의해야 할 몇 가지 차이점이 있다. 이들 중 일부는 클러스터와 관련된 정보 전달을 허용하지 않는 기존 파일 시스템 인터페이스로 인해 발생한다. 일부는 클러스터 방식에서 해당 기능을 효율적으로 구현하기 어려운 점에서 비롯된다. 예를 들어,

 GFS/GFS2에서의 flock() 시스템 호출은 시그널에 의해 중단되지 않는다.
 fcntl() F_GETLK 시스템 호출은 차단 잠금의 PID를 반환한다. 이는 클러스터 파일 시스템이므로, 해당 PID는 파일 시스템을 마운트한 노드 중 임의의 노드에 있는 프로세스를 나타낼 수 있다. 이 인터페이스의 목적은 차단 프로세스에 시그널을 보낼 수 있도록 하는 것이므로, 더 이상 불가능하다.
 임대(Leases)는 lock_dlm(클러스터) 잠금 모듈에서 지원되지 않지만, 로컬 파일 시스템으로 사용될 때는 지원된다.
 Dnotify는 "동일 노드" 기준으로 작동하지만 GFS/GFS2에서의 사용은 권장되지 않는다.
 Inotify도 "동일 노드" 기준으로 작동하며 역시 권장되지 않는다 (단, 향후 지원될 가능성이 있다).
 splice는 GFS2에서만 지원된다.

다른 주요 차이점이자 유사한 클러스터 파일 시스템들이 공유하는 특징은, GFS/GFS2에서 glocks(지-락으로 발음)로 알려진 캐시 제어 메커니즘이 전체 클러스터에 걸쳐 영향을 미친다는 점이다. 파일 시스템의 각 아이노드에는 두 개의 glock이 연결되어 있다. 하나(iopen glock이라 불림)는 어떤 프로세스가 아이노드를 열었는지 추적한다. 다른 하나(inode glock)는 해당 아이노드와 관련된 캐시를 제어한다. glock은 UN(잠금 해제), SH(공유 – 읽기 잠금), DF(지연 – SH와 호환되지 않는 읽기 잠금) 및 EX(독점)의 네 가지 상태를 가진다. 각 모드는 DLM 잠금 모드에 직접 매핑된다.

EX 모드일 때, 아이노드는 데이터와 메타데이터(파일 시스템으로 다시 쓰기를 기다리는 "더티" 상태일 수 있음)를 캐싱할 수 있다. SH 모드에서 아이노드는 데이터와 메타데이터를 캐싱할 수 있지만, 더티 상태여서는 안 된다. DF 모드에서 아이노드는 메타데이터만 캐싱할 수 있으며, 역시 더티 상태여서는 안 된다. DF 모드는 직접 I/O를 위해서만 사용된다. UN 모드에서 아이노드는 어떠한 메타데이터도 캐싱해서는 안 된다.

아이노드의 데이터나 메타데이터를 변경하는 작업들이 서로 방해하지 않도록 하기 위해 EX 잠금이 사용된다. 이는 동일한 디렉토리에서 파일 생성/삭제 및 동일한 파일에 대한 쓰기와 같은 특정 작업이 일반적으로 클러스터의 한 노드로 제한되어야 함을 의미한다. 물론 여러 노드에서 이러한 작업을 수행해도 예상대로 작동하지만, 캐시를 자주 플러시해야 하므로 효율적이지 않다.

GFS/GFS2 성능에 대해 가장 자주 묻는 질문 중 하나는 왜 이메일 서버에서 성능이 저하될 수 있는지에 대한 것이다. 해결책은 메일 스풀을 별도의 디렉토리로 나누고 각 노드가 가능한 한 비공개 디렉토리 세트에 읽고 쓰도록 유지하는 것이다.

 저널링 
GFS와 GFS2는 모두 저널링 파일 시스템이다. GFS2는 ext3와 유사한 저널링 모드 세트를 지원한다. data=writeback 모드에서는 메타데이터만 저널링된다. 이는 GFS에서 지원되는 유일한 모드이지만, 개별 데이터 파일의 크기가 0일 때만 저널링을 켤 수 있다. GFS의 저널링된 파일은 mmap이나 sendfile 시스템 호출을 지원하지 않는 등 여러 제한이 있으며, 일반 파일과 다른 온디스크(on-disk) 형식을 사용한다. 또한 "inherit-journal" 속성이 있는데, 디렉토리에 이 속성이 설정되면 해당 디렉토리 내에 생성된 모든 파일(및 하위 디렉토리)에 저널(또는 inherit-journal) 플래그가 설정된다. 이는 ext3가 지원하는(GFS/GFS2는 지원하지 않는) data=journal 마운트 옵션 대신 사용될 수 있다.

GFS2는 또한 저널 플러시가 완료되기 전에 더티 데이터를 동기화하는 것을 제외하고 data=writeback과 유사한 data=ordered 모드를 지원한다. 이는 아이노드에 추가된 블록의 내용이 메타데이터가 새 크기를 기록하도록 업데이트되기 전에 디스크로 동기화되도록 보장하여, 노드 실패 시 초기화되지 않은 블록이 파일에 나타나는 것을 방지한다. 기본 저널링 모드는 ext3의 기본값과 일치하는 data=ordered이다.

 기준으로 GFS2는 아직 data=journal 모드를 지원하지 않지만, GFS와 달리 일반 파일과 저널링된 파일 모두에 대해 동일한 온디스크 형식을 사용하며, 동일한 저널링 및 inherit-journal 속성을 지원한다. GFS2는 또한 파일이 열려 있지 않은 상태라면 언제든지 저널링 속성을 변경할 수 있도록 제한을 완화했다(이 역시 ext3와 동일함).

성능상의 이유로 GFS와 GFS2의 각 노드는 자체 저널을 가진다. GFS에서 저널은 디스크 익스텐트(extents)이며, GFS2에서 저널은 일반 파일이다. 동시에 파일 시스템을 마운트할 수 있는 노드의 수는 사용 가능한 저널의 수에 의해 제한된다.

 GFS와 비교한 GFS2의 특징 
GFS2는 GFS에 없는 여러 새로운 기능을 추가한다. 이 페이지 오른쪽 상자에 언급되지 않은 기능의 요약은 다음과 같다:

 메타데이터 파일 시스템 (사실상 다른 루트) – 아래 호환성 및 GFS2 메타 파일 시스템 참조
 GFS2 전용 추적 포인트(trace points)는 커널 2.6.32부터 사용 가능
 XFS 스타일의 쿼터(quota) 인터페이스는 커널 2.6.33부터 GFS2에서 사용 가능
 캐싱 ACL은 2.6.33부터 GFS2에서 사용 가능
 GFS2는 씬 프로비저닝(thin provisioning)/SCSI TRIM 요청을 위한 "discard" 요청 생성 지원
 GFS2는 I/O 배리어(barriers)를 지원함 (기본적으로 켜져 있으며, 기본 장치가 이를 지원한다고 가정함. 커널 2.6.33 이상에서 설정 가능)
 FIEMAP ioctl (디스크상의 아이노드 매핑 조회용)
 Splice (시스템 호출) 지원
 저널링된 파일에 대한 mmap/splice 지원 (일반 파일과 동일한 온디스크 형식을 사용하여 가능해짐)
 훨씬 적은 튜닝 매개변수 (설정을 덜 복잡하게 만듦)
 순차 쓰기(Ordered write) 모드 (ext3와 마찬가지로, GFS는 writeback 모드만 가짐)

 호환성 및 GFS2 메타 파일 시스템 
GFS2는 GFS로부터의 업그레이드가 간단한 절차가 되도록 설계되었다. 이를 위해 빅 엔디언 바이트 순서를 포함하여 대부분의 온디스크 구조가 GFS와 동일하게 유지되었다. 그러나 몇 가지 차이점이 있다.

 GFS2에는 프로세스가 시스템 파일에 접근하는 "메타 파일 시스템"이 있다.
 GFS2는 저널링된 파일에 대해 일반 파일과 동일한 온디스크 형식을 사용한다.
 GFS2는 저널을 위해 일반(시스템) 파일을 사용하는 반면, GFS는 특수 익스텐트를 사용한다.
 GFS2에는 몇 가지 다른 "" 시스템 파일이 있다.
 아이노드의 레이아웃이 (매우 약간) 다르다.
 간접 블록(indirect blocks)의 레이아웃이 약간 다르다.

GFS와 GFS2의 저널링 시스템은 서로 호환되지 않는다. 메타데이터를 업데이트하기 위해 파일 시스템 오프라인 상태에서 실행되는 도구()를 통해 업그레이드가 가능하다. GFS 저널의 일부 여유 블록은 업데이트 프로세스 중에 GFS2에 필요한 (매우 작은) 파일을 생성하는 데 사용된다. 대부분의 데이터는 그대로 유지된다.

GFS2 "메타 파일 시스템"은 그 자체로 독립된 파일 시스템이 아니라 메인 파일 시스템의 대체 루트이다. "일반" 파일 시스템처럼 작동하지만 그 내용은 GFS2에서 사용하는 다양한 시스템 파일이며, 일반적으로 사용자가 이를 들여다볼 필요는 없다. GFS2 유틸리티는 배후에서 필요에 따라 메타 파일 시스템을 마운트하고 마운트 해제한다.

 같이 보기 
 파일 시스템 비교
 GPFS, ZFS, VxFS
 러스터
 GlusterFS
 파일 시스템 목록
 OCFS2
 QFS
 SAN 파일 시스템
 펜싱
 Ceph

 각주 

 외부 링크 
 Red Hat Red Hat Enterprise Linux 6 - Global File System 2
 Red Hat Cluster Suite and GFS Documentation Page
 GFS Project Page 
 OpenGFS Project Page (obsolete)
 The GFS2 development git tree
 The GFS2 utilities development git tree

분류:레드햇 소프트웨어