* GFS2 파일시스템의 개요

GFS2 파일시스템은 여러 노드에서 동시에 읽기쓰기를 할 수 있는 클러스터 파일시스템이다. 일반 파일시스템과 비슷한 기능을 지원한다. 예를들어 POSIX ACLs, extended attributes, quotas, symbolic links, SElinux 지원 등 모두 지원한다. 동시 접근을 관리하기 위해, GFS2 는 rhel 클러스터 인프라를 사용해 노드를모니터링하고, 펜싱하고, DLM (distributed lock manager) 을 사용해 파일 및 디렉토릭의 잠금을 제어한다.

 

각 클러스터 노드는 gfs2파일시스템을 모니터링하는데에 각각 분리된 journal을 사용한다. 한 노드가 죽으면, 클러스터는 해당 노드를 펜스한다. 그리고 다른 노드중하나에서 해당 journal을  replay 한다. 사용자는 이러한 저널을 파일시스템 생성할때 할당한다. 그러나 또한 사용자는 존재하는 파일시스템에 추가적인 저널을 추가할수 있다. 

 

레드햇은 gfs2파일시스템에 대하여 싱글의 경우, 그리고 16개 이상의 노드를 가진 클러스터의 경우에는 지원하지 않는다. 또한 레드햇은 lvm shared lv에 최상단에파일시스템을 만드는 경우에만 gfs2 를 기술지원한다. 한 노드에 마운트하는 파일시스템을 gfs2로 만들지 말아야 한다. 단독 사용에는 xfs가 더 성능도 좋고 설치와관리도 편하다.

 

순수한 64비트 환경에서, gfs2 파일시스템은 이론적으로 8EiB까지 확장할 수 있다. 그러나, 최대 gfs2 파일시스템 사이즈는 레드햇은 100TiB까지 지원한다. 또한 대부분 설치 환경에서, 큰 사이즈의 gfs2 1개보다 작은 사이즈의 gfs2 여러개가 더 좋다. 큰 사이즈의 gfs2에서, fsck.gfs2 를 수행하면 엄청난 시간을 소요하며 메모리도 많이 먹는다. 또한 이 파일시스템을 리스토어할 때도 많은 시간을 소요한다.

 

레드햇은 gfs2 파일시스템을 Resilient Storage Add-on 의 일부로 제공한다. grfs2는 클러스터 인프라스트럭쳐가 필요하기 때문이다. 따라서 Resilient Storage Add-on 외에 High Availability Add-on 도 필요하다.

 

 

 

* gfs2 구성 전 사전 확인사항

 

요구사항 

High Availability Add-on : resilient storage (gfs2) 는 fence 장치와 함께 작동하기 위해 클러스터 인프라에 의존한다.

lvm 공유 볼륨 그룹과 공유 논리 볼륨 :  레드햇은 LVM 공유 볼륨 그룹의 논리 볼륨 위에 파일 시스템을 배포할 때 GFS2를 지원합니다. 모든 클러스터 노드에서 논리 볼륨을 activate 해야 한다.

시간 프로토콜 : gfs2는 클러스터 노드의 시스템 시간과 동기화가 필요하다. chrony 를 사용할 수 있다.

gfs2-utils RPM 설치 : 아래와 같이 패키지를 설치해야 구성이 가능하다.

 

 

gfs2 구성 시 필요한 정보

 

클러스터 노드 수

gfs2 파일시스템이 동시에 마운트되는 클러스터 노드의 수는 생성해야 하는 journal 개수를 식별해준다. 만약 클러스터에 노드를 추가한다면, 그전에 이미 추가 journal이 준비되어 있어야 한다.

 

클러스터 이름

gfs2파일시스템을 만들때는 클러스터 이름을 명시해야 한다.이 클러스터의 멤버들만이 해당 파일시스템을 마운트할 수 있다.

 

파일시스템 명

각 gfs2 파일시스템은 클러스터 내에서 유니크하게 식별되는 이름을 가진다. 이 이름은 gfs2 파일시스템 생성시 16글자로 제한되는 이름을 만들 수 있다.

 

lvm 공유 논리 볼륨 이름

gfs2 파일시스템을 포맷하고 마운트하는데 LV를 사용한다.

 

 

추가 필요한 설정

글로벌 클러스터 파라미터인 no_quorum_policy를 freeze로 설정해야 한다. 이 파라미터는 쿼럼을 잃었을 때 클러스터가 어떻게 동작할지를 컨트롤한다. 디폴트값인stop는 클러스터가 쿼럼을 잃으면 모든 리소스를 클러스터가 stop 시킨다. 그러나, 정상작동하기 위해 gfs2는 클러스터가 be quorate 인 것을 요구한다. (쿼럼이 있는 상태)

 

따라서 쿼럼을 잃게 되는 경우, 모든 리소스가 stop 되게 되니  GFS2 파일 시스템 리소스를 중지하려고 한다. 그런데 gfs2는 쿼럼이 있어야만 정상작동하므로 이gfs2에 대한 모든 중지 시도가 실패하여 결국 클러스터가 완전히 실패하게 된다. 이를 방지하기 위해 no-qurum-policy를 freeze로 둠으로써, 클러스터는 쿼럼이 회복될 때까지 리소스를 중지시키지 않고 아무 작업도 수행하지 않게 한다.

 

 

 

* gfs 파일시스템 생성하기

모든 전제 조건이 갖추어지면 어느 노드에서나 mkfs.gfs2 명령을 사용하여 GFS2 파일 시스템을 생성할 수 있다. 다음 표에는 mkfs.gfs2에 대한 가장 일반적인 옵션이 나열되어 있다.

 

-t <lock_table_name>

- Locking Table의 이름을 정의한다.

- 이 형식은 "클러스터네임:파일시스템네임" 을 따른다.

- 클러스터네임 : 해당 클러스터네임에 포함된 노드만 파일시스템을 마운트할 수 있다.

- 파일시스템네임 : 파일시스템을 식별하는 유니크한 이름이다. 이 이름길이는 16자 까지로 제한되어있다.

 

-j <저널수>

- 처음 생성시 저널의 개수를 의미한다.

- 사용자는 이후 추가 저널을 넣을 수 있다.

- 각 노드가 접근하는 파일시스템은 동시에 하나의 저널이 필요하다.

- 만약 이 옵션을 생략하면, 디폴트로 한개의 저널이 생성된다.

 

J <저널 크기>

- 각 저널의 크기를 MiB로 표현한다. 최소 사이즈는 8MiB 이고, 최대 사이즈는  1GiB 이다.

- 디폴트로, mkfs.gfs2명령은 파일시스템 사이즈에 기반하여 값을 계산한다.

- 최상의 성능을 위하여, 레드햇은 128MiB 이상을 권고한다.

 

아래 예시는  gfs2파일시스템을 어떻게 만들지 보여준다. 이름은 examplegfs2이다. 또한 examplecluster 에 포함되어있다.  저널사이즈는 128MiB이고, 공유 로지컬볼륨은 /dev/lvmsharedvg/lv1 이다.

 

 

 

* 주의사항

테스트 목적으로, mount 명령으로 , 일반적인 파일시스템들과 동일하게 일시적으로 gfs2를 마운트해볼 수 있다. 하지만 프로덕션 레벨에서는, gfs2 파일시스템을 마운트하기위해서는 꼭 클러스터 리소스로서만 마운트해야한다. 만약 수동으로 gfs2를 마운트하면 (mount 명령어로) 그때는 항상 서버를 끄거나 리스타트하기전에 수동으로 umount 를 해줘야 한다. 그렇지 않으면, 시스템은 종료중에 hang 이 발생한다. 동일한 이유로, 절대로 /etc/fstab에 gfs2 파일시스템을 넣지 말아야 한다.

 

 

 

 

* 클러스터 리소스를 사용하여 GFS2 파일 시스템 마운트하기

GFS2 파일 시스템에 클러스터 파일 시스템 리소스를 사용하면 다른 클러스터 리소스처럼 해당 리소스를 관리하고 제어할 수 있다.  또한 파일 시스템이 정확하고 깔끔하게 마운트 및 마운트 해제되도록 보장한다.

 

GFS2는 LVM 공유 논리 볼륨에 의존하고, 이는 다시 lvmlockd 및 DLM에 의존하므로 이러한 서비스를 관리하기 위한 리소스를 이미 생성했는지 확인해야 한다. 이전에 클러스터 LVM 구성에서 작업한 dlm, lvmlockd 리소스 설정, 공유 LV 리소스 설정, 리소스 실행 순서를 정의하는 Constraint 설정까지 완료한 후에 gfs2 파일시스템을 생성해야 한다. 다음 명령은 /data 마운트 지점에 /dev/lvmsharedvg/lv1 GFS2 파일 시스템을 마운트하는 파일 시스템 리소스를 생성한다.

 

이 명령은 리소스를 LVMshared_group 리소스 그룹에 추가한다. (이 LVMshared_group 리소스에는 이미 LVM-activate 리소스가 있고 클론이 되어있음) LVMshared_group 리소스 그룹을 복제했기 때문에 클러스터는 모든 클러스터 노드에서 파일 시스템을 마운트하고 관리하게 된다.

 

 

 

* gfs2 관리 : 파일시스템에 저널 추가하기

파일시스템이 가진 저널보다 더 많은 노드에 gfs2 파일시스템을 마운트할 수 없다. 파일시스템이 얼마나 많은 저널을 가지고 있는지 찾기 위해, gfs2_edit -p journals 명령을 사용한다. 아래 예시대로는 2개의 저널을 가지고 있는것을 알수 있다.

 

저널을 추가하려면, gfs2_jadd 명령을 사용한다. 

 

-j 옵션을 써서원하는 저널의 개수를 명시한다.

-J 온션은 새로운 저널의 크기를 MiB로 명시한다. (디폴트는 128 이다. 128MiB)

 

사용자는 파일시스템의 장치명이나, 마운트 포인트를 줄 수 있다. 아래 예시는 256 MiB의 저널을 만드는것이다. 이 명령은 한 노드에서만 하면 된다.

 

 

 

* gfs2 관리 :  파일 시스템 확장하기

GFS2는 LVM 공유 논리 볼륨에 추가한 여분의 공간을 활용하여 파일 시스템을 확장 할 수 있다. 레드햇은 확장작업 할 때 꼭 파일시스템 데이터를 백업하기를 권고한다. 또한, gfs2는 축소를 할 수 없다.

 

gfs2_grow 명령을 써서 gfs2 파일시스템을 확장할 수 있다.  파일시스템 장치명이나 마운트포인트를 명시한다. 명령은 이 파일시스템이 마운트되어있는곳 아무데서나 할 수 있다. 아래 예시는 10GiB 로지컬 볼륨을 추가하고, gfs2_grow 로 테스트하고, 실제로 작업한다.

-T 옵션은 테스트 모드를 활성화한다. 이 모드에서는 일반 모든 작업을 진행하나, 실제로 변경을 디스크에 commmit하지만 않는다.

 

 

 

* gfs2 관리 : 파일시스템 복구하기

일반 상황에서, gfs2 파일시스템은 수동 복구가 필요하지 않다. 노드가 죽었을 때, 파일시스템의 무결성을 유지하기 위해서, 클러스터는 노드를 펜스하고, 다른 노드는 그 저널을 리플레이한다. 몇몇 상황에서 , 예를들어 스토리지 장치가 죽었을 경우, 시스템에서 gfs2 파일시스템을 dirty상태 또는 손상된 상태로 둘 수 있다.

 

이 경우 fsck 명령을 사용하여 파일 시스템을 복구할 수 있다. fsck 명령은 GFS2 파일 시스템을 인식하고 fsck.gfs2 명령을 호출하여 실제 검사를 수행한다. fsck.gfs2 명령을 직접 실행할 수도 있다.

 

주의할 것

fsck.gfs2 실행하기 전에, 파일시스템을 모든 클러스터 노드에서 umount 해야 한다. 파일시스템이 리소스로서 클러스터에서 관리되고 있다면, 해당 리소스를 disable하여 모든 노드에서 umount 하게 하도록 하자.

 

아래 예시는 clusterfs를 disable 한다. --wait 옵션은 명령이 작업이 완료될때까지 기다렸다가 결과를 반환하도록 지시한다. 이 예제에서는 명령이 최대 180초 동안 대기한 다음 해당 타이머가 만료(작업이 제대로 안끝나면) 오류를 반환한다.

이후 fsck.gfs2가 완료되면, 다시 해당 리소스를 enable 한다.

 

 

 

* 슈퍼블록을 변경하기

 

gfs2 파일시스템을 다른 클러스터로 옮기거나,  클러스터 이름을 바꾸는경우, 꼭 해당 gfs2 슈퍼블록안에있는 locking table name을 업데이트 해줘야 한다. 또한, gfs2 슈퍼블록에 변경을 가하기 전에, 파일시스템을 모든 클러스터 노드에서 umount 해야한다. 

 

tunegfs2 -l 명령으로 gfs2슈퍼블록을 본다.

tunegfs2 -o locktable=<newname> 명령으로 locking table name을 변경한다.

아래 예시는 이름을 newcluster 로 변경한다.

 

 

 

* 노드 추가하기

노드3개 있는 시스템에서 노드 1개를 추가하여 총 노드 4개가 되도록 한다.

 

현재 있는 파일시스템 마운트 한거 확인

 

널 확인

 

위 결과는 GFS2 파일 시스템에 저널이 3개만 있다는 것을 보여준다. 따라서 네 번째 노드에 해당 파일 시스템을 마운트하려는 경우 추가 저널을 추가해야 한다.

 

저널 추가

 

 

 

* 파일시스템 증설하기

 

현재 용량 확인

 

2기가 늘리는 작업

 늘리기 위해 따로 마운트를 해제하지 않는다. 즉 온라인중에 가능. 다만 I/O가 적을때 하는것이 권장된다.

 

확인

 

 

 

* References

 

mkfs.gfs2(8) and mount(8) fsck.gfs2(8), gfs2_edit(8), gfs2_grow(8), gfs2_jadd(8), and tunegfs2(8) man pages 

 

Knowledgebase: "What are the recommended best practices for mkfs.gfs2?" 

https://access.redhat.com/solutions/2883291

 

For more information, refer to the GFS2 file systems chapter in the Configuring GFS2 file systems guide at 

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_gfs2_file_systems/index#assembly_creating-mounting-gfs2-configuring-gfs2-file-systems

 

For more information, refer to the GFS2 file systems in a cluster chapter in the Configuring and managing high availability clusters guide at 

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_high_availability_clusters/index#assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters

 

Knowledgebase: "What are some examples of GFS & GFS2 workloads that should be avoided?"

https://access.redhat.com/solutions/41223

 

Knowledgebase: "How can Red Hat assist me in assessing the design of my RHEL High Availability or Resilient Storage cluster?" 

레드햇은 고객이 계획한 클러스터 구성이 지원 가능한지를 리뷰하기 위해 Red Hat for an Architectural review와 컨택하는것을 추천한다.

https://access.redhat.com/articles/2359891

 

For more information, refer to the Planning a GFS2 file system deployment chapter in the Configuring GFS2 file systems guide at

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_gfs2_file_systems/index#assembly_planning-gfs2-deployment-configuring-gfs2-file-systems

 

Knowledgebase: "Do I need to make changes to my GFS/GFS2 file systems when renaming the cluster in RHEL?" https://access.redhat.com/solutions/18430

 

For more information, refer to the GFS2 file systems and GFS2 file system repair chapters in the Configuring GFS2 file systems guide at 

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_gfs2_file_systems/index

 

+ Recent posts