Red Hat Enterprise Linux 9부터 GFS2 파일 시스템은 형식 버전 1802로 생성됩니다.

형식 버전 1802는 다음 기능을 활성화합니다.

새 형식 버전으로 생성된 파일 시스템은 이전 RHEL 버전에서 마운트할 수 없으며 fsck.gfs2 유틸리티의 이전 버전은 확인할 수 없습니다.

사용자는 -o format=1801 옵션과 함께 mkfs.gfs2 명령을 실행하여 이전 형식 버전으로 파일 시스템을 생성할 수 있습니다.

사용자는 마운트 해제된 파일 시스템에서 tunegfs2 -r 1802 장치를 실행하는 이전 파일 시스템의 형식 버전을 업그레이드할 수 있습니다. 형식 버전을 다운그레이드할 수 없습니다.

GFS2 파일 시스템을 설치하고 구성하기 전에 계획해야 하는 여러 가지 주요 GFS2 매개 변수가 있습니다.

Red Hat이 GFS2 파일 시스템을 실행하는 클러스터에 대해 지원을 받으려면 Red Hat의 지원 정책을 고려해야 합니다.

GFS2 파일 시스템을 포맷하여 성능을 최적화하려면 다음 권장 사항을 고려해야 합니다.

파일 시스템 크기: 작은 Is better

GFS2는 64비트 아키텍처를 기반으로 하며, 이 아키텍처는 이론적으로 8 EB 파일 시스템을 수용할 수 있습니다. 그러나 64비트 하드웨어에 대해 지원되는 현재 GFS2 파일 시스템의 최대 크기는 100TB입니다.

대규모 파일 시스템을 사용할 수 있지만 이러한 파일 시스템을 사용하지 않는 것이 좋습니다. 대부분의 경우 GFS2에서 사용하는 것이 작아집니다. 10TB 파일 시스템을 1TB 이상의 파일 시스템을 사용하는 것이 좋습니다.

GFS2 파일 시스템을 작게 유지해야 하는 몇 가지 이유가 있습니다.

또한 유지 관리를 위해 리소스 그룹 수가 적으면 성능이 향상됩니다.

물론 GFS2 파일 시스템을 너무 작게 만드는 경우 공간이 부족하여 고유한 결과가 발생할 수 있습니다. 크기를 결정하기 전에 자신의 사용 사례를 고려해야 합니다.

블록 크기: 기본 (4K) 블록은 Preferred입니다.

mkfs.gfs2 명령은 장치 토폴로지에 따라 최적의 블록 크기를 추정하려고 합니다. 일반적으로 4K 블록은 Red Hat Enterprise Linux의 기본 페이지 크기(메모리)이기 때문에 기본 블록 크기입니다. 다른 파일 시스템과 달리, GFS2는 4K 커널 버퍼를 사용하여 대부분의 작업을 수행합니다. 블록 크기가 4K인 경우 커널은 버퍼를 조작하기 위해 작업을 적게 수행해야 합니다.

성능이 가장 높은 기본 블록 크기를 사용하는 것이 좋습니다. 많은 매우 작은 파일을 효율적으로 저장해야하는 경우에만 다른 블록 크기를 사용해야 할 수도 있습니다.

비트맵 크기: 기본값(128MB)은 일반적으로 Optimal입니다.

mkfs.gfs2 명령을 실행하여 GFS2 파일 시스템을 생성할 때 저널 크기를 지정할 수 있습니다. 크기를 지정하지 않으면 기본적으로 대부분의 애플리케이션에 최적이어야 하는 128MB가 설정됩니다.

일부 시스템 관리자는 128MB가 과도한 것으로 간주하고 저널 크기를 최소 8MB 또는 더 보수적으로 32MB로 줄일 수 있습니다. 이 경우 효과가 있을 수 있지만 성능에 심각한 영향을 미칠 수 있습니다. 많은 저널링 파일 시스템과 마찬가지로, GFS2가 메타데이터를 쓸 때마다 메타데이터가 저널에 커밋됩니다. 이렇게 하면 시스템이 충돌하거나 전원이 끊어지면 저널이 마운트 시 자동으로 재생될 때 모든 메타데이터를 복구할 수 있습니다. 그러나 8MB의 저널을 채우기 위해 파일 시스템 활동이 많이 필요하지 않으며, 저널이 가득 차면 GFS2가 스토리지에 쓰기를 기다려야 하기 때문에 성능이 느려집니다.

일반적으로 기본 저널 크기 128MB를 사용하는 것이 좋습니다. 파일 시스템이 매우 작은 경우(예: 5GB) 128MB의 저널이 비현실될 수 있습니다. 더 큰 파일 시스템이 있고 공간을 절약할 수 있는 경우 256MB의 저널을 사용하면 성능이 향상될 수 있습니다.

리소스 그룹의 크기 및 수

mkfs.gfs2 명령을 사용하여 GFS2 파일 시스템을 생성하면 스토리지를 리소스 그룹이라는 균일 슬라이스로 나눕니다. 최적의 리소스 그룹 크기(32MB에서 2GB까지) 추정하려고 시도합니다. mkfs.gfs2 명령의 -r 옵션을 사용하여 기본값을 재정의할 수 있습니다.

최적의 리소스 그룹 크기는 파일 시스템을 사용하는 방법에 따라 다릅니다. 얼마나 넓을 지, 그리고 그것이 심하게 분할되는지 여부를 고려하십시오.

최적의 성능을 얻으려면 다양한 리소스 그룹 크기를 실험해야 합니다. GFS2를 전체 프로덕션에 배포하기 전에 테스트 클러스터를 테스트하는 것이 좋습니다.

파일 시스템에 너무 많은 리소스 그룹이 있는 경우 블록 할당이 너무 작으면 사용 가능한 블록을 위해 수십만 개의 리소스 그룹을 검색하는 데 너무 많은 시간이 낭비될 수 있습니다. 파일 시스템이 가득 차면 검색될 리소스 그룹이 많을수록 모두 클러스터 전체의 잠금이 필요합니다. 이로 인해 성능이 저하됩니다.

그러나 파일 시스템에 리소스 그룹이 너무 적으면 블록 할당이 너무 크면 동일한 리소스 그룹 잠금에 대해 블록 할당이 더 자주 제한될 수 있으므로 성능에도 영향을 미칠 수 있습니다. 예를 들어, 2GB의 리소스 그룹 5개로 구성된 10GB 파일 시스템이 있는 경우 동일한 파일 시스템이 32MB의 리소스 그룹 320으로 인한 경우 클러스터의 노드가 5개 리소스 그룹보다 더 자주 충돌합니다. 모든 블록 할당이 사용 가능한 블록 블록으로 하나를 찾기 전에 여러 리소스 그룹을 찾아야 할 수 있으므로 파일 시스템이 거의 가득하면 문제가 발생합니다. GFS2에서는 다음 두 가지 방법으로 이 문제를 해결하려고 합니다.

가장 안 좋은 시나리오는 모든 노드가 파일을 생성하는 중앙 디렉터리가 있는 경우입니다. 모든 노드가 동일한 리소스 그룹을 잠그기 위해 지속적으로 충돌할 것이기 때문입니다.

시스템에 포함할 노드 수를 결정할 때 고가용성과 성능 사이에 절충이 있습니다. 노드 수가 점점 많아지면 워크로드를 확장하기가 점점 어려워지고 있습니다. 따라서 Red Hat은 16개 이상의 클러스터 파일 시스템 배포에는 GFS2 사용을 지원하지 않습니다.

클러스터 파일 시스템을 배포하는 것은 단일 노드 배포를 위한 "디드랍"이 아닙니다. Red Hat은 시스템을 테스트하고 필요한 성능 수준에서 작동하는지 확인하기 위해 새로운 설치 시 약 8-12주 간의 테스트 기간을 허용할 것을 권장합니다. 이 기간 동안 모든 성능 또는 기능 문제가 발생할 수 있으며 모든 쿼리는 Red Hat 지원 팀에 문의해야 합니다.

클러스터 배포를 고려하는 고객은 나중에 가능한 지원 문제를 방지하기 위해 배포 전에 Red Hat 지원팀에서 구성을 검토할 것을 권장합니다.

GFS2 파일 시스템을 배포할 때 다음 하드웨어 고려 사항을 고려하십시오.

각 파일 inode 및 디렉터리 inode에는 3개의 타임스탬프와 연관된 세 개의 타임스탬프가 있습니다.

시간 업데이트가 GFS2 및 기타 Linux 파일 시스템에서 기본적으로 활성화되어 있는 경우 파일을 읽을 때마다 inode를 업데이트해야 합니다.

애플리케이션이 제공하는 정보를 사용하는 애플리케이션이 많지 않으므로 이러한 업데이트에 는 불필요한 쓰기 트래픽 및 파일 잠금 트래픽이 많이 필요할 수 있습니다. 이 트래픽은 성능을 저하시킬 수 있으므로 시간 업데이트 빈도를 끄거나 줄이는 것이 좋습니다.

시간 업데이트의 영향을 줄이는 다음 방법을 사용할 수 있습니다.

noatime Linux 마운트 옵션으로 GFS2 파일 시스템을 마운트하려면 다음 명령을 사용합니다.

mount BlockDevice MountPoint -o noatime

이 예에서 GFS2 파일 시스템은 /dev/vg01/lvol0 에 있으며 시간 업데이트가 꺼진 경우 /mygfs2 디렉토리에 마운트됩니다.

# mount /dev/vg01/lvol0 /mygfs2 -o noatime

모든 Linux 파일 시스템과 마찬가지로 GFS2는 VFS(가상 파일 시스템)라는 계층 위에 있습니다. Multus는 대부분의 워크로드에 대한 캐시 설정에 적합한 기본값을 제공하며 대부분의 경우 변경할 필요가 없습니다. 그러나 제대로 실행되지 않는 워크로드(예: 캐시가 너무 크거나 작은 경우) sysctl(8) 명령을 사용하여 /proc/sys/vm 디렉터리의 sysctl 파일 값을 조정하여 성능을 향상시킬 수 있습니다. 이러한 파일에 대한 문서는 커널 소스 트리 Documentation/sysctl/vm.txt 에서 확인할 수 있습니다.

예를 들어, 더러운_background_ratio 및 vfs_cache_pressure 의 값은 상황에 따라 조정할 수 있습니다. 현재 값을 가져오려면 다음 명령을 사용합니다.

# sysctl -n vm.dirty_background_ratio
# sysctl -n vm.vfs_cache_pressure

다음 명령은 값을 조정합니다.

# sysctl -w vm.dirty_background_ratio=20
# sysctl -w vm.vfs_cache_pressure=500

/etc/sysctl.conf 파일을 편집하여 이러한 매개변수의 값을 영구적으로 변경할 수 있습니다.

사용 사례에 맞는 최적의 값을 찾으려면 전체 프로덕션에 배포하기 전에 다양한 vGPU 옵션을 조사하고 테스트 클러스터에서 실험하십시오.

GFS2에서 SELinux(Security Enhanced Linux)를 사용하면 약간의 성능 저하가 발생합니다. 이러한 오버헤드를 방지하기 위해 SELinux가 강제 모드인 시스템에서도 GFS2와 함께 SELinux를 사용하지 않도록 선택할 수 있습니다. GFS2 파일 시스템을 마운트할 때 SELinux가 mount(8) 도움말 페이지에 설명된 컨텍스트 옵션 중 하나를 사용하여 각 파일 시스템 오브젝트에서 weekly label 요소를 읽으려고 시도하지 않도록 할 수 있습니다. SELinux는 파일 시스템의 모든 콘텐츠가 컨텍스트 마운트 옵션에 제공된 weekly label 요소로 레이블이 지정되었다고 가정합니다. 이는 또한 euro label 요소를 포함할 수 있는 확장 속성 블록의 다른 디스크 읽기를 방지할 수 있으므로 처리 속도를 향상시킵니다.

예를 들어 SELinux가 강제 모드로 설정된 시스템에서 다음 mount 명령을 사용하여 파일 시스템에 Apache 콘텐츠를 포함할 경우 GFS2 파일 시스템을 마운트할 수 있습니다. 이 레이블은 전체 파일 시스템에 적용되며 메모리에 남아 있으며 디스크에 기록되지 않습니다.

# mount -t gfs2 -o context=system_u:object_r:httpd_sys_content_t:s0 /dev/mapper/xyz/mnt/gfs2

파일 시스템에 Apache 콘텐츠가 포함될지 확실하지 않은 경우 public_content_rw_t 또는 public_content_t 레이블을 사용하거나 새 레이블을 완전히 정의하고 관련 정책을 정의할 수 있습니다.

Pacemaker 클러스터에서는 항상 Pacemaker를 사용하여 GFS2 파일 시스템을 관리해야 합니다. GFS2 파일 시스템 리소스를 생성할 때 마운트 옵션을 지정할 수 있습니다.

GFS2 잠금 하위 시스템의 복잡성과 클러스터형 특성의 추가 복잡성으로 인해 GFS2를 통해 NFS를 설정하는 데 많은 예방 조치가 필요합니다.

잠금 고려 사항 외에도 GFS2 파일 시스템에서 NFS 서비스를 구성할 때 다음 사항을 고려해야 합니다.

RuntimeClass와 함께 GFS2 파일 시스템에서 제공하는 Samba(SMB 또는 Windows) 파일을 사용하여 활성/활성 구성을 사용할 수 있습니다.

Samba 외부에서 Samba 공유의 데이터에 동시 액세스할 수 없습니다. 현재 Samba 파일 제공 속도가 느릴 때 GFS2 클러스터 리스가 지원되지 않습니다. Samba 지원 정책에 대한 자세한 내용은 RHEL 탄력적 스토리지 지원 정책 - ctdb 일반 정책 및 RHEL 복구 스토리지 지원 정책 - 기타 프로토콜을 통해 gfs2 콘텐츠 내보내기 를 참조하십시오.

가상 머신과 함께 GFS2 파일 시스템을 사용할 때 캐시를 강제로 사용하려면 각 노드의 VM 스토리지 설정을 올바르게 구성해야 합니다. 예를 들어 libvirt 도메인에 cache 및 io 에 대한 이러한 설정을 포함하여 GFS2가 예상대로 작동하도록 허용해야 합니다.

<driver name='qemu' type='raw' cache='none' io='native'/>

또는 device 요소 내에서 공유 가능한 속성을 구성할 수 있습니다. 이는 해당 장치를 도메인 간에 공유할 것으로 예상됩니다(하이퍼바이저와 OS가 이를 지원하는 경우). shareable 을 사용하는 경우 해당 장치에 cache='no' 를 사용해야 합니다.

데이터만 작성하는 애플리케이션에서는 일반적으로 블록 할당 방법이나 위치를 상관하지 않지만 블록 할당이 작동하는 방식에 대한 일부 지식이 성능을 최적화하는 데 도움이 될 수 있습니다.

mkfs.gfs2 명령을 사용하여 GFS2 파일 시스템을 생성합니다. 파일 시스템은 활성화된 LVM 볼륨에 생성됩니다.

mkfs.gfs2 -p lock_dlm -t ClusterName:FSName -j NumberJournals BlockDevice

mkfs -t gfs2 -p lock_dlm -t ClusterName:FSName -j NumberJournals BlockDevice

# mkfs.gfs2 -p lock_dlm -t alpha:mydata1 -j 8 /dev/vg01/lvol0
# mkfs.gfs2 -p lock_dlm -t alpha:mydata2 -j 8 /dev/vg01/lvol1

GFS2 파일 시스템을 마운트하려면 파일 시스템이 있어야 하며, 파일 시스템이 존재하는 볼륨을 활성화해야 하며 지원 클러스터링 및 잠금 시스템을 시작해야 합니다. 이러한 요구 사항이 충족되면 모든 Linux 파일 시스템과 마찬가지로 GFS2 파일 시스템을 마운트할 수 있습니다.

파일 ACL을 조작하려면 -o acl 마운트 옵션을 사용하여 파일 시스템을 마운트해야 합니다. -o acl 마운트 옵션 없이 파일 시스템을 마운트하면 사용자는 ACL( getfacl)을 볼 수 있지만 setfacl을 사용하여 설정할 수는 없습니다.

# mount /dev/vg01/lvol0 /mygfs2

mount BlockDevice MountPoint -o option

umount MountPoint

파일 시스템의 크기에 관계없이 긴급한 경우 GFS2 파일 시스템을 정기적으로 백업해야 합니다. 많은 시스템 관리자는 RAID, 다중 경로, 미러링, 스냅샷 및 기타 형태의 중복성에 의해 보호되고 있기 때문에 안전하게 보호된다고 생각하지만, 충분히 안전한 것은 없습니다.

노드 또는 노드 세트를 백업하는 프로세스에서 일반적으로 전체 파일 시스템을 순서대로 읽는 작업이므로 백업을 생성하는 것이 문제가 될 수 있습니다. 단일 노드에서 이 작업을 수행하면 클러스터의 다른 노드가 잠금을 요청할 때까지 해당 노드는 캐시의 모든 정보를 유지합니다. 클러스터가 작동하는 동안 이러한 유형의 백업 프로그램을 실행하면 성능에 부정적인 영향을 미칩니다.

백업이 완료되면 캐시를 삭제하면 클러스터 잠금 및 캐시의 소유권을 얻기 위해 다른 노드에 필요한 시간이 줄어듭니다. 그러나 다른 노드에서 백업 프로세스가 시작되기 전에 캐싱된 데이터 캐싱이 중지되므로 이 방법은 여전히 적합하지 않습니다. 백업이 완료된 후 다음 명령을 사용하여 캐시를 삭제할 수 있습니다.

echo -n 3 > /proc/sys/vm/drop_caches

클러스터의 각 노드가 자체 파일을 백업하여 작업이 노드 간에 분할되도록 하는 것이 더 빠릅니다. 노드별 디렉터리에서 rsync 명령을 사용하는 스크립트로 이 작업을 수행할 수 있습니다.

Red Hat은 SAN에서 하드웨어 스냅샷을 작성하여 다른 시스템에 스냅샷을 제공하고 여기에서 지원하는 것이 좋습니다. 백업 시스템은 -o lockproto=lock_nolock 을 사용하여 스냅샷을 마운트해야 합니다. 그러나 Red Hat은 프로덕션 환경에서 polkit2를 단일 노드 파일 시스템으로 사용하는 것을 지원하지 않습니다. 최소 클러스터 크기에 설명된 대로 이 옵션은 백업 또는 보조 사이트 재해 복구 노드에만 사용해야 합니다. 이 옵션을 사용하는 경우 한 번에 하나의 시스템에서만 Cryostat2 파일 시스템을 사용하고 있는지 확인해야 합니다.

dmsetup suspend 명령을 사용하여 파일 시스템에 쓰기 활동을 일시 중단할 수 있습니다. 쓰기 활동을 일시 중지하면 하드웨어 기반 장치 스냅샷을 사용하여 파일 시스템을 일관된 상태로 캡처할 수 있습니다. dmsetup resume 명령은 중지를 종료합니다.

GFS2 파일 시스템의 활동을 일시 중단하는 명령 형식은 다음과 같습니다.

dmsetup suspend MountPoint

이 예제에서는 파일 시스템 /mygfs2 에 대한 쓰기를 일시 중지합니다.

# dmsetup suspend /mygfs2

GFS2 파일 시스템에서 작업 중단을 종료할 명령의 형식은 다음과 같습니다.

dmsetup resume MountPoint

이 예제는 파일 시스템 /mygfs2 에 대한 쓰기 중단을 종료합니다.

# dmsetup resume /mygfs2

gfs2_grow 명령은 파일 시스템이 있는 장치가 확장된 후 GFS2 파일 시스템을 확장하는 데 사용됩니다. 기존 GFS2 파일 시스템에서 gfs2_grow 명령을 실행하면 파일 시스템의 현재 끝과 새로 초기화된 GFS2 파일 시스템 확장자로 장치 종료 사이에 모든 여유 공간이 채워집니다. 클러스터의 모든 노드는 추가된 추가 스토리지 공간을 사용할 수 있습니다.

마운트된 파일 시스템에서 gfs2_grow 명령을 실행해야 합니다. 다음 절차에서는 /mnt/gfs2 의 마운트 지점인 shared_vg/shared_lv1 에 마운트된 클러스터의 GFS2 파일 시스템의 크기를 늘립니다.

GFS2에는 파일 시스템을 마운트해야 하는 클러스터의 각 노드에 대해 저널이 1개 있어야 합니다. 클러스터에 노드를 추가하는 경우 gfs2_jadd 명령을 사용하여 GFS2 파일 시스템에 저널을 추가할 수 있습니다. 기본 논리 볼륨을 확장하지 않고 언제든지 GFS2 파일 시스템에 저널을 동적으로 추가할 수 있습니다. gfs2_jadd 명령은 마운트된 파일 시스템에서 실행해야 하지만 클러스터의 하나의 노드에서만 실행해야 합니다. 다른 모든 노드는 확장이 발생했음을 인식합니다.

GFS2 파일 시스템에 저널을 추가하기 전에 다음 예와 같이 현재 gfs2_edit -p jindex 명령을 사용하여 현재 GFS2 파일 시스템에 포함된 저널 수를 확인할 수 있습니다.

# gfs2_edit -p jindex /dev/sasdrives/scratch|grep journal
   3/3 [fc7745eb] 4/25 (0x4/0x19): File    journal0
   4/4 [8b70757d] 5/32859 (0x5/0x805b): File    journal1
   5/5 [127924c7] 6/65701 (0x6/0x100a5): File    journal2

GFS2 파일 시스템에 저널을 추가하는 기본 명령의 형식은 다음과 같습니다.

gfs2_jadd -j Number MountPoint

이 예에서는 /mygfs2 디렉터리의 파일 시스템에 하나의 저널이 추가됩니다.

# gfs2_jadd -j 1 /mygfs2

GFS2 파일 시스템에 대한 디스크 할당량을 구현하려면 수행해야 하는 세 가지 단계가 있습니다.

디스크 할당량을 구현하기 위한 단계는 다음과 같습니다.

이러한 각 단계에 대해서는 다음 섹션에서 자세히 설명합니다.

# pcs resource create gfs2mount Filesystem options="quota=on" device=BLOCKDEVICE directory=MOUNTPOINT fstype=gfs2 clone

# quotacheck -ug /home

# edquota username

Disk quotas for user testuser (uid 501):
Filesystem                blocks     soft     hard    inodes   soft   hard
/dev/VolGroup00/LogVol02  440436        0        0

Disk quotas for user testuser (uid 501):
Filesystem                blocks     soft     hard    inodes   soft   hard
/dev/VolGroup00/LogVol02  440436   500000   550000

# quota testuser

# edquota -g devel

Disk quotas for group devel (gid 505):
Filesystem                blocks    soft     hard    inodes   soft   hard
/dev/VolGroup00/LogVol02  440400       0        0

$ quota -g devel

할당량을 구현하는 경우, 주로 할당량을 초과하는지 확인하고 할당량이 올바른지 확인하기 위해 몇 가지 유지보수가 필요합니다.

사용자가 할당량을 반복적으로 초과하거나 소프트 제한에 일관되게 도달하는 경우 시스템 관리자는 사용자 유형 및 디스크 공간이 작업에 미치는 영향에 따라 몇 가지 선택을 할 수 있습니다. 관리자는 사용자가 디스크 공간을 적게 사용하는 방법을 결정하거나 사용자의 디스크 할당량을 늘리는 데 도움이 될 수 있습니다.

repquota 유틸리티를 실행하여 디스크 사용량 보고서를 생성할 수 있습니다. 예를 들어, repquota /home 명령은 다음 출력을 생성합니다.

*** Report for user quotas on device /dev/mapper/VolGroup00-LogVol02
Block grace time: 7days; Inode grace time: 7days
			Block limits			File limits
User		used	soft	hard	grace	used	soft	hard	grace
----------------------------------------------------------------------
root      --      36       0       0              4     0     0
kristin   --     540       0       0            125     0     0
testuser  --  440400  500000  550000          37418     0     0

모든(옵션 -a) 할당량 지원 파일 시스템에 대한 디스크 사용량 보고서를 보려면 명령을 사용합니다.

# repquota -a

각 사용자가 블록 제한을 초과했는지 여부를 확인하는 빠른 방법입니다. 블록 소프트 제한을 초과하면 출력에 + 가 첫 번째 - 대신 표시됩니다. 두 번째 - 는 inode 제한을 나타내지만, GFS2 파일 시스템은 inode 제한을 지원하지 않으므로 문자가 - 로 유지됩니다. GFS2 파일 시스템은 유예 기간을 지원하지 않으므로 grace 열은 빈 상태로 유지됩니다.

기본 파일 시스템에 관계없이 NFS에서는 repquota 명령이 지원되지 않습니다.

할당량을 비활성화한 상태로 실행 중인 경우 quotacheck 명령을 실행하여 할당량 파일을 생성, 확인 및 복구해야 합니다. 또한 시스템 충돌 후 파일 시스템을 완전히 마운트 해제하지 않을 수 있으므로 할당량 파일이 정확하지 않다고 생각되면 quotacheck 명령을 실행할 수 있습니다.

quotacheck 명령에 대한 자세한 내용은 quotacheck(8) 매뉴얼 페이지를 참조하십시오.

GFS2는 모든 할당량 정보를 디스크의 자체 내부 파일에 저장합니다. GFS2 노드는 모든 파일 시스템 쓰기에 대해 이 할당량 파일을 업데이트하지 않습니다. 대신 기본적으로 60초마다 할당량 파일을 업데이트합니다. 이는 할당량 파일에 쓰는 노드 간 경합을 방지하기 위해 필요합니다. 이로 인해 성능이 저하됩니다.

사용자 또는 그룹이 할당량 제한에 접근하므로, GFS2는 할당량 파일 업데이트 간의 시간을 동적으로 줄여 제한이 초과되지 않도록 합니다. 할당량 동기화 사이의 정상적인 시간 기간은 조정 가능한 매개변수인 quota_quantum 입니다. 마운트 옵션을 지정하는 GFS2 파일 시스템 마운트의 "GFS2-Specific Mount Options" 테이블에 설명된 대로 quota_quantum= 마운트 옵션을 사용하여 이 값을 60초의 기본값에서 변경할 수 있습니다.

quota_quantum 매개 변수는 각 노드에 설정되어야 하며 파일 시스템이 마운트될 때마다 설정해야 합니다. quota_quantum 매개변수는 마운트 해제 시 지속되지 않습니다. mount -o reinstall 를 사용하여 quota_quantum 값을 업데이트할 수 있습니다.

quotasync 명령을 사용하여 노드의 할당량 정보를 GFS2에서 수행하는 자동 업데이트 간의 디스크상의 할당량 파일과 동기화할 수 있습니다. 사용량 동기화 할당량 정보

quotasync [-ug] -a|mountpoint...

quota-quantum 마운트 옵션을 지정하여 동기화 간 시간을 조정할 수 있습니다.

# mount -o quota_quantum=secs,remount BlockDevice MountPoint

다음 예제에서는 파일 시스템 /mnt/mygfs2 의 노드에서 실행된 노드에서 캐시된 모든 더티 할당량을 동기화합니다.

# quotasync -ug /mnt/mygfs2

다음 예제에서는 논리 볼륨 /dev/volgroup/logical_volume 에서 해당 파일 시스템을 다시 마운트할 때 파일 시스템 /mnt/mygfs2 의 경우 일반 quota-file이 1시간(3600초)로 업데이트합니다.

# mount -o quota_quantum=3600,remount /dev/volgroup/logical_volume /mnt/mygfs2

fsck.gfs2 명령을 실행하려면 운영 체제 및 커널에 사용된 메모리 이상으로 위의 시스템 메모리가 필요할 수 있습니다. 특히 대규모 파일 시스템에는 이 명령을 실행하기 위해 추가 메모리가 필요할 수 있습니다.

다음 표는 1TB, 10TB, 100TB의 블록 크기가 4K인 GFS2 파일 시스템에서 fsck.gfs2 파일 시스템을 실행하는 데 필요할 수 있는 대략적인 메모리 값을 보여줍니다.

파일 시스템의 더 작은 블록 크기는 더 많은 양의 메모리가 필요합니다. 예를 들어 블록 크기가 1K인 GFS2 파일 시스템에는 이 표에 표시된 메모리 양이 4배가 필요합니다.

GFS2 파일 시스템을 복구하기 위한 fsck.gfs2 명령의 형식은 다음과 같습니다.

fsck.gfs2 -y BlockDevice

이 예에서는 블록 장치 /dev/testvg/testlv 에 상주하는 GFS2 파일 시스템이 복구됩니다. 복구에 대한 모든 쿼리는 자동으로 yes 로 답변됩니다.

# fsck.gfs2 -y /dev/testvg/testlv
Initializing fsck
Validating Resource Group index.
Level 1 RG check.
(level 1 passed)
Clearing journals (this may take a while)...
Journals cleared.
Starting pass1
Pass1 complete
Starting pass1b
Pass1b complete
Starting pass1c
Pass1c complete
Starting pass2
Pass2 complete
Starting pass3
Pass3 complete
Starting pass4
Pass4 complete
Starting pass5
Pass5 complete
Writing changes to disk
fsck.gfs2 complete

Red Hat Enterprise Linux에서 GFS2에 대한 조각 모음 툴은 없지만, filefrag 툴과 식별하여 개별 파일을 조각 모음하고, 임시 파일로 복사한 다음, 임시 파일로 복사하고, 원본을 교체하도록 임시 파일의 이름을 바꾸면 개별 파일을 조각 모음할 수 있습니다.

GFS2 파일 시스템에서 최상의 성능을 얻으려면 작업의 기본 이론을 이해하는 것이 중요합니다. 단일 노드 파일 시스템은 캐시와 함께 구현되며, 자주 요청된 데이터를 사용할 때 디스크 액세스 대기 시간을 제거할 수 있습니다. Linux에서 페이지 캐시(및 이전에 버퍼 캐시)는 이 캐싱 기능을 제공합니다.

GFS2에서 각 노드에는 디스크의 일부 데이터가 포함될 수 있는 자체 페이지 캐시가 있습니다. GFS2에서는 glocks (pronounced gee-locks)라는 잠금 메커니즘을 사용하여 노드 간 캐시의 무결성을 유지합니다. glock 하위 시스템은 DLM( Distributed Lock Manager )을 기본 통신 계층으로 사용하여 구현된 캐시 관리 기능을 제공합니다.

glocks는 노드별로 캐시 보호를 제공하므로 캐싱 계층을 제어하는 데 사용되는 inode당 하나의 잠금이 있습니다. 공유 모드(DLM 잠금 모드)에서 해당 glock이 부여된 경우: 그런 다음 해당 glock 아래의 데이터는 동시에 하나 이상의 노드에 캐시되므로 모든 노드가 데이터에 대한 로컬 액세스 권한을 가질 수 있습니다.

glock이 전용 모드 (DLM 잠금 모드)로 부여 된 경우: 그런 다음 단일 노드만 해당 glock 아래에 데이터를 캐시할 수 있습니다. 이 모드는 데이터를 수정하는 모든 작업에서 사용합니다(예: 쓰기 시스템 호출).

다른 노드에서 즉시 부여할 수 없는 glock을 요청하면 DLM은 현재 새 요청을 차단하여 잠금을 삭제하도록 요청하는 노드 또는 노드에 메시지를 보냅니다. glock을 삭제하는 것은 (대부분의 파일 시스템 작업의 기준에 따라) 긴 프로세스가 될 수 있습니다. 공유 glock을 삭제하려면 캐시를 무효화해야 하며, 이는 상대적으로 빠르고 캐시된 데이터의 양에 비례합니다.

배타적인 glock을 삭제하려면 로그 플러시가 필요하고 변경된 데이터를 디스크에 다시 작성한 다음 공유 glock에 따라 무효화가 발생합니다.

단일 노드 파일 시스템과 GFS2의 차이점은 단일 노드 파일 시스템에 단일 캐시가 있고 GFS2에는 각 노드에 별도의 캐시가 있다는 것입니다. 두 경우 모두 캐시된 데이터에 액세스하기 위한 대기 시간은 유사한 수준의 크기이지만 캐시되지 않은 데이터에 액세스하기 위한 대기 시간은 다른 노드가 이전에 동일한 데이터를 캐시한 경우 GFS2에서 훨씬 더 큽니다.

읽기(buffered ), stat 및 read dir 과 같은 작업에는 공유 glock만 필요합니다. 쓰기 (buffered), EgressIP ,rmdir, unlink 와 같은 작업에는 배타적 glock이 필요합니다. 직접 I/O 읽기/쓰기 작업에서는 할당이 없는 경우 지연된 glock 또는 쓰기에 할당이 필요한 경우 독점 glock(즉, 파일 확장 또는 누락)이 필요합니다.

이 경우 다음과 같은 두 가지 주요 성능 고려 사항이 있습니다. 첫 번째 읽기 전용 작업은 모든 노드에서 독립적으로 실행될 수 있으므로 클러스터에서 매우 잘 병렬화됩니다. 두 번째, 배타적인 glock을 필요로 하는 작업에서는 동일한 inode에 대한 액세스를 위해 여러 노드가 제한되는 경우 성능을 줄일 수 있습니다. 따라서 각 노드에서 작업 세트를 고려하는 경우, 예를 들어 GFS2 파일 시스템 백업에 설명된 대로 파일 시스템 백업을 수행하는 경우와 같이 GFS2 파일 시스템 성능에 중요한 요소가 있습니다.

이로 인해 가능한 경우 애플리케이션이 이를 허용하는 noatime 또는 nodiratime 마운트 옵션을 최대한 사용하여 noatime 또는 nodiratime 마운트 옵션을 사용하는 것이 좋습니다. 이 경우 atime timestamp를 업데이트하기 위해 배타적 잠금이 필요하지 않습니다.

working set 또는 캐싱 효율성에 대한 우려가 있는 사용자를 위해 GFS2 파일 시스템의 성능을 모니터링할 수 있는 툴을 제공합니다. Performance Co-octets 및 GFS2 추적 지점.

Posix locking를 사용할 때는 다음을 고려해야 합니다.

일반적으로 어려운 애플리케이션이 상당한 성능 이점을 얻기 위해 데이터를 저장하는 방법을 변경할 수 있습니다.

어려운 애플리케이션의 일반적인 예는 이메일 서버입니다. 각 사용자(mbox ) 또는 각 사용자에 대한 파일이 포함된 spool 디렉터리에 각 메시지에 대한 파일이 포함된 디렉터리(maildir)와 함께 배치되는 경우가 많습니다. commands를 통해 요청이 도착하면 각 사용자에게 특정 노드에 선호도를 부여하기 위한 최적의 배열이 있습니다. 이렇게 하면 이메일 메시지를 보고 삭제하라는 요청이 하나의 노드의 캐시에서 제공되는 경향이 있습니다. 해당 노드가 실패하면 다른 노드에서 세션을 다시 시작할 수 있습니다.

메일이 SMTP를 통해 도착하면 기본적으로 특정 사용자의 이메일을 특정 노드에 전달할 수 있도록 개별 노드를 다시 설정할 수 있습니다. 기본 노드가 작동하지 않으면 수신 노드에서 사용자의 메일 스풀에 메시지를 직접 저장할 수 있습니다. 이 설계는 일반적인 사례에서 하나의 노드에 캐시된 특정 파일 집합을 유지하기 위한 것으로, 노드 장애 발생 시 직접 액세스가 허용됩니다.

이 설정을 사용하면 GFS2의 페이지 캐시를 최대한 활용할 수 있으며 redfish 또는 ProfileBundle 에도 관계없이 애플리케이션에 대한 실패를 투명하게 수 행할 수 있습니다.

백업은 종종 또 다른 어려운 영역입니다. 다시 말해, 가능한 경우 특정 inode 집합을 캐싱하는 노드에서 직접 각 노드의 작업 세트를 백업하는 것이 좋습니다. 일반 시점에 실행되는 백업 스크립트가 있고, 이 경우 GFS2에서 실행되는 애플리케이션의 응답 시간에 급증하는 것처럼 보이는 백업 스크립트가 있는 경우 클러스터가 페이지 캐시를 가장 효율적으로 사용하지 못할 가능성이 높습니다.

분명히 백업을 수행하기 위해 응용 프로그램을 중지 할 수있는 위치에있는 경우 이것은 문제가되지 않습니다. 반면 백업이 한 노드에서만 실행되는 경우 파일 시스템의 많은 부분을 완료한 후 다른 노드의 후속 액세스로 성능 저하가 발생합니다. 다음 명령을 사용하여 백업이 완료된 후 백업 노드에서 vGPU 페이지 캐시를 삭제하여 일정 범위까지 완화할 수 있습니다.

echo -n 3 >/proc/sys/vm/drop_caches

그러나 이 방법은 각 노드에서 작업 집합이 주로 클러스터 전체에서 읽기 전용인지 또는 단일 노드에서 대부분 액세스할 수 있도록 주의를 기울이는 것이 좋지 않습니다.

GFS2 캐싱을 비효율적으로 사용하기 때문에 클러스터 성능이 저하되는 경우 대규모 I/O 대기 시간이 증가할 수 있습니다. GFS2의 잠금 덤프 정보를 사용하여 문제의 원인을 확인할 수 있습니다.

debugfs 가 /sys/kernel/debug/ 에 마운트되었다고 가정하면 debug2 잠금 덤프 정보를 debugfs 파일에서 수집할 수 있습니다.

/sys/kernel/debug/gfs2/fsname/glocks

파일의 내용은 일련의 행입니다. G:로 시작하는 각 줄은 하나의 glock을 나타내며, 다음 줄은 파일에서 바로 glock과 관련된 정보 항목을 하나의 공백으로 나타냅니다.

debugfs 파일을 사용하는 가장 좋은 방법은 cat 명령을 사용하여 파일의 전체 콘텐츠 복사본을 사용하는 것입니다(애플리케이션에 많은 RAM과 캐시된 inode가 있는 경우 시간이 오래 걸릴 수 있음) 애플리케이션에서 문제가 발생하는 동안 나중에 결과 데이터를 확인하는 것입니다.

H: (holders)로 시작하는 debugfs 파일의 행은 부여되거나 부여 대기 중인 잠금 요청을 나타냅니다. holders line f:의 flags 필드는 다음을 보여줍니다. 'W' 플래그는 대기 요청을 나타냅니다. 'H' 플래그는 부여된 요청을 나타냅니다. 많은 수의 대기 요청이 있는 glock은 특정 경합이 발생하는 것일 수 있습니다.

다음 표에서는 glock 플래그와 glock 홀더 플래그의 의미를 보여줍니다.

문제를 일으키는 glock을 확인한 다음, 다음 단계는 관련 inode를 찾는 것입니다. glock 번호 (n: 라인)는 이를 나타냅니다. 이는 형식/번호 이며 유형이 2인 경우 glock은 inode glock이고 숫자는 inode 번호입니다. inode를 추적하려면 find -inum 번호를 실행합니다. 여기서 number 는 glocks 파일의 16진수 형식에서 변환된 inode 번호입니다.

다음 표에서는 다른 glock 유형의 의미를 보여줍니다.

확인된 glock이 다른 유형인 경우 3:(리소스 그룹) 유형일 가능성이 높습니다. 일반 부하에서 다른 유형의 glock 대기 중인 상당한 프로세스 수가 표시되면 이를 Red Hat 지원에 보고합니다.

리소스 그룹 잠금에 대기 중인 대기 요청이 여러 개 표시되면 이에 대한 여러 가지 이유가 있을 수 있습니다. 하나는 파일 시스템의 리소스 그룹 수와 비교하여 많은 수의 노드가 있다는 것입니다. 또 다른 하나는 파일 시스템이 매우 완전할 수 있다는 것입니다 (중대적으로, 자유 블록을 더 긴 검색 등). 두 경우의 상황은 더 많은 스토리지를 추가하고 gfs2_grow 명령을 사용하여 파일 시스템을 확장하여 개선할 수 있습니다.

일반적으로 GFS2는 저널에 대한 메타데이터만 씁니다. 이후 파일 콘텐츠는 파일 시스템 버퍼를 플러시하는 커널의 주기적 동기화에 의해 디스크에 기록됩니다. fsync() 호출을 사용하면 파일의 데이터가 디스크에 즉시 기록됩니다. 호출은 디스크가 모든 데이터가 안전하게 기록된다고 보고할 때 반환됩니다.

데이터 저널링은 파일 데이터가 메타데이터 외에도 저널에 기록되기 때문에 매우 작은 파일에 대해 fsync() 시간을 줄 수 있습니다. 이렇게 하면 파일 크기가 증가함에 따라 빠르게 줄어듭니다. 중간 및 큰 파일에 쓰기가 훨씬 느려지고 데이터 저널링이 켜집니다.

fsync() 를 사용하여 파일 데이터를 동기화하는 애플리케이션은 데이터 저널링을 사용하여 성능이 향상될 수 있습니다. 플래그 지정된 디렉토리(및 해당 하위 디렉토리)에서 생성된 모든 GFS2 파일에 대해 데이터 저널링을 자동으로 활성화할 수 있습니다. 길이가 0인 기존 파일은 데이터 저널링을 켜거나 해제할 수도 있습니다.

디렉토리에서 데이터 저널링을 활성화하면 디렉토리를 "herit jdata"로 설정합니다. 그러면 해당 디렉토리에서 생성되는 모든 파일과 디렉터리가 저널되어 있습니다. chattr 명령을 사용하여 파일에서 데이터 저널링을 활성화하고 비활성화할 수 있습니다.

다음 명령은 /mnt/gfs2/gfs2_dir/newfile 파일에서 데이터 저널링을 활성화한 다음 플래그가 올바르게 설정되었는지 확인합니다.

# chattr +j /mnt/gfs2/gfs2_dir/newfile
# lsattr /mnt/gfs2/gfs2_dir
---------j--- /mnt/gfs2/gfs2_dir/newfile

다음 명령은 /mnt/gfs2/gfs2_dir/newfile 파일에서 저널링 데이터를 비활성화한 다음 플래그가 올바르게 설정되었는지 확인합니다.

# chattr -j /mnt/gfs2/gfs2_dir/newfile
# lsattr /mnt/gfs2/gfs2_dir
------------- /mnt/gfs2/gfs2_dir/newfile

또한 chattr 명령을 사용하여 디렉토리에 j 플래그를 설정할 수도 있습니다. 디렉토리에 이 플래그를 설정하면 해당 디렉토리에서 이후에 생성되는 모든 파일과 디렉터리가 저널됩니다. 다음 명령 세트는 gfs2_dir 디렉터리에 j 플래그를 설정한 다음 플래그가 올바르게 설정되었는지 확인합니다. 이 후 명령은 /mnt/gfs2/gfs2_dir 디렉터리에 newfile 이라는 새 파일을 생성한 다음 j 플래그가 파일에 설정되어 있는지 확인합니다. j 플래그가 디렉터리에 설정된 경우 newfile 에도 저널링이 활성화되어야 합니다.

# chattr -j /mnt/gfs2/gfs2_dir
# lsattr /mnt/gfs2
---------j--- /mnt/gfs2/gfs2_dir
# touch /mnt/gfs2/gfs2_dir/newfile
# lsattr /mnt/gfs2/gfs2_dir
---------j--- /mnt/gfs2/gfs2_dir/newfile

GFS2 인출 기능은 보안 취약점이 있는 하드웨어 또는 커널 소프트웨어로 인한 파일 시스템의 파일 시스템 손상을 방지할 수 있는 GFS2 파일 시스템의 데이터 무결성 기능입니다. 지정된 클러스터 노드에서 GFS2 파일 시스템을 사용하는 동안 GFS2 커널 모듈이 불일치를 감지하면 파일 시스템에서 인출하여 마운트 해제 및 다시 마운트할 때까지 해당 노드에서 사용할 수 없게 됩니다(또는 문제가 재부팅됨을 감지하는 시스템이 재부팅됨). 마운트된 다른 모든 GFS2 파일 시스템은 해당 노드에서 완전히 작동하는 상태로 유지됩니다. ( GFS2 인출 기능은 커널 패닉보다 덜 심각하여 노드를 펜싱할 수 있습니다.)

GFS2 인출을 유발할 수 있는 불일치의 주요 범주는 다음과 같습니다.

GFS2 인출으로 인한 불일치의 예로는 파일의 inode에 대한 잘못된 블록 수가 있습니다. GFS2가 파일을 삭제하면 해당 파일에서 참조하는 모든 데이터 및 메타데이터 블록이 체계적으로 제거됩니다. 완료되면 inode의 블록 수를 확인합니다. inode 블록 수가 파일에 사용된 실제 블록과 일치하지 않기 때문에 블록 수가 1이 아닌 경우(즉, 파일 시스템 불일치를 나타내는) 파일 시스템 불일치를 나타내는 경우 블록 수가 파일에 사용된 실제 블록과 일치하지 않기 때문입니다. 대부분의 경우 이 문제는 결함이 있는 하드웨어(주요 메모리, 마더보드, HBA, 디스크 드라이브, 케이블 등)로 인해 발생할 수 있습니다. 커널 버그로 인한 것일 수도 있습니다(다른 커널 모듈에서 실수로 GFS2 메모리를 덮어쓰거나, 실제 파일 시스템 손상( GFS2 버그에 의해 사용됨)이 발생할 수 있습니다.

대부분의 경우 인출된 GFS2 파일 시스템에서 복구하는 가장 좋은 방법은 노드를 재부팅하거나 펜싱하는 것입니다. 제거된 GFS2 파일 시스템으로 서비스를 클러스터의 다른 노드로 재배치할 수 있습니다. 서비스가 재배치된 후 노드를 재부팅하거나 이 명령을 사용하여 펜싱을 강제 수행할 수 있습니다.

pcs stonith fence node

인출으로 인한 일관성 문제로 인해 시스템이 중단될 수 있으므로 파일 시스템 서비스를 중지하지 못할 수 있습니다.

재마운트 후에도 문제가 지속되면 파일 시스템 서비스를 중지하여 클러스터의 모든 노드에서 파일 시스템을 마운트 해제한 다음, 다음 절차에 따라 서비스를 다시 시작하기 전에 fsck.gfs2 명령으로 파일 시스템 검사를 수행해야 합니다.

파일 시스템 서비스에 지정된 -o errors=panic 옵션으로 파일 시스템을 마운트하여 GFS2 인출 기능을 재정의할 수 있습니다.

# pcs resource update mydata_fs “options=noatime,errors=panic”

이 옵션을 지정하면 일반적으로 오류가 발생하면 시스템이 대신 커널 패닉을 강제로 제거하도록 합니다. 이렇게 하면 노드 통신이 중지되어 노드가 펜싱됩니다. 이는 모니터링 또는 개입없이 오랜 기간 동안 자동으로 남아 있는 클러스터에 특히 유용합니다.

내부적으로, 모든 추가 파일 시스템 작업에서 I/O 오류가 발생하도록 잠금 프로토콜을 분리하여 GFS2 인출 기능이 작동합니다. 결과적으로 인출이 발생하면 시스템 로그에 보고된 장치 매퍼 장치의 여러 I/O 오류를 확인하는 것이 일반적입니다.

GFS2 파일 시스템이 중단되고 명령을 반환하지 않지만 특정 노드를 재부팅하면 시스템이 정상적으로 반환되면 잠금 문제 또는 버그가 손상될 수 있습니다. 이 문제가 발생할 경우 문제 해결을 위해 GFS2 데이터 수집에 설명된 대로 이러한 문제가 발생한 경우 Red Hat Support를 사용하여 지원 티켓을 열고 문제를 해결합니다.

GFS2 파일 시스템이 중단되고 명령을 실행하지 않는 경우 사용하기 전에 클러스터의 모든 노드를 재부팅해야 다음 문제가 있는지 확인하십시오.

클러스터에 새 노드를 추가하고 해당 노드에 GFS2 파일 시스템을 마운트할 수 없는 경우, GFS2 파일 시스템에 액세스하려는 노드보다 GFS2 파일 시스템에 저널이 적을 수 있습니다. 파일 시스템을 마운트하려는 GFS2 호스트당 저널이 있어야 합니다(스펙터 마운트 옵션으로 마운트된 GFS2 파일 시스템을 제외하고 저널이 필요하지 않으므로). GFS2 파일 시스템에 저널 추가에 설명된 대로 gfs2_jadd 명령을 사용하여 GFS2 파일 시스템에 저널을 추가할 수 있습니다.

GFS2 파일 시스템이 비어 있는 경우 df 명령은 사용 중인 공간이 있음을 표시합니다. journal2 파일 시스템 저널은 디스크의 공간( journals * 저널 크기)을 사용하기 때문입니다. 저널 수가 많은 저널이 지정되거나 많은 저널 크기를 지정한 Cryostat2 파일 시스템을 생성한 후 df 명령을 실행할 때 이미 사용 중인 저널 수( journals * 저널 크기)가 표시됩니다. 많은 수의 저널 또는 대규모 저널을 지정하지 않은 경우에도 소규모 GFS2 파일 시스템(1GB 이하의 경우)은 기본 GFS2 저널 크기와 함께 사용되는 것처럼 많은 공간을 표시합니다.

GFS2 파일 시스템이 중단되고 이에 대해 실행된 명령을 반환하지 않고 Red Hat 지원을 통해 티켓을 열어야 한다는 것을 발견하면 먼저 다음 데이터를 수집해야 합니다.

해당 데이터를 수집한 후 Red Hat 지원팀으로 티켓을 열고 수집한 데이터를 제공할 수 있습니다.

다음 절차에 따라 Alertmanager2 파일 시스템을 포함하는 Pacemaker 클러스터를 설정할 수 있습니다. 이 예제에서는 2-노드 클러스터의 논리 볼륨 3개에 status2 파일 시스템을 생성합니다.

Pacemaker 클러스터를 생성하고 클러스터의 펜싱 구성에 대한 자세한 내용은 Pacemaker를 사용하여 Red Hat High-Availability 클러스터 생성을 참조하십시오.

다음 절차에 따라 LUKS 암호화된 VMDK2 파일 시스템을 포함하는 Pacemaker 클러스터를 생성할 수 있습니다. 이 예에서는 논리 볼륨에 하나의 VMDK2 파일 시스템을 생성하고 파일 시스템을 암호화합니다. 암호화된 FlexVolume2 파일 시스템은 LUKS 암호화를 지원하는 crypt 리소스 에이전트를 사용하여 지원됩니다.

이 절차에는 세 가지 부분이 있습니다.

[root@z1 ~]# lvs
  LV         VG          Attr       LSize
  shared_lv1 shared_vg1  -wi-a----- 5.00g

[root@z2 ~]# lvs
  LV         VG          Attr       LSize
  shared_lv1 shared_vg1  -wi-a----- 5.00g

[root@z1 ~]# ls -l /dev/mapper/
...
lrwxrwxrwx 1 root root 7 Mar 4 09:52 luks_lv1 -> ../dm-3
...

현재 세 가지 유형의 GFS2 추적 지점이 있습니다. glock (prounced "gee-lock") tracepoints, bmap tracepoints 및 log tracepoints. 이는 실행 중인 Cryostat2 파일 시스템을 모니터링하는 데 사용할 수 있습니다. 추적 지점은 중단 또는 성능 문제와 같은 문제를 재현할 수 있으므로 문제가 있는 작업 중에 tracepoint 출력을 얻을 수 있는 경우 특히 유용합니다. GFS2에서 glock은 기본 캐시 제어 메커니즘이며, GFS2 코어의 성능을 이해하는 데 핵심입니다. bmap (block map) 추적 포인트는 발생할 때 블록 할당 및 블록 매핑 ( on-disk 메타데이터 트리에 이미 할당된 블록의 조회)을 모니터링하고 액세스의 지역성에 관한 문제를 확인하는 데 사용할 수 있습니다. 로그 추적점은 저널에 작성 및 릴리스되는 데이터를 추적하며, Cryostat2의 해당 부분에 대한 유용한 정보를 제공할 수 있습니다.

추적 지점은 가능한 한 일반적이 되도록 설계되었습니다. 이는 Red Hat Enterprise Linux 9 과정에서 API를 변경할 필요가 없음을 의미합니다. 반면 이 인터페이스의 사용자는 이는 일반 Red Hat Enterprise Linux 9 API 세트의 일부가 아닌 디버깅 인터페이스임을 알고 있어야 합니다. 따라서 Red Hat은 Cryostat2 추적 지점의 변경이 발생하지 않을 것을 보장하지 않습니다.

추적 지점은 Red Hat Enterprise Linux의 일반적인 기능이며, 해당 범위는 GFS2를 벗어납니다. 특히 blktrace 인프라를 구현하는 데 사용되며 blktrace 추적 포인트를 사용하면 시스템 성능에 대한 전체 정보를 얻을 수 있습니다. 추적 포인트가 작동하는 수준으로 인해 매우 짧은 기간 내에 대량의 데이터를 생성할 수 있습니다. 활성화될 때 시스템에 최소 부하를 배치하도록 설계되었지만 효과가 있다는 것은 불가피합니다. 다양한 방법으로 이벤트를 필터링하면 데이터 양을 줄이고 특정 상황을 이해하는 데 유용한 정보만 얻는 데 집중할 수 있습니다.

tracepoints는 /sys/kernel/debug/debug 디렉토리의 표준 위치에 debugfs 가 마운트되었다고 가정하고 /sys/kernel/debug / 디렉토리에서 찾을 수 있습니다. events 하위 디렉터리에는 지정할 수 있는 모든 추적 이벤트가 포함되어 있으며 gfs2 모듈이 로드되면 각 GFS2 이벤트에 대해 gfs2 하위 디렉터리가 포함된 gfs2 하위 디렉터리가 있습니다. /sys/kernel/debug/tracing/gfs2 디렉터리의 내용은 다음과 유사합니다.

[root@chywoon gfs2]# ls
enable            gfs2_bmap       gfs2_glock_queue         gfs2_log_flush
filter            gfs2_demote_rq  gfs2_glock_state_change  gfs2_pin
gfs2_block_alloc  gfs2_glock_put  gfs2_log_blocks          gfs2_promote

모든 GFS2 추적 지점을 활성화하려면 다음 명령을 입력합니다.

[root@chywoon gfs2]# echo -n 1 >/sys/kernel/debug/tracing/events/gfs2/enable

특정 추적 지점을 활성화하기 위해 개별 이벤트 하위 디렉터리에는 enable 파일이 있습니다. 동일한 필터 파일에서 각 이벤트 또는 이벤트 세트에 대한 이벤트 필터를 설정하는 데 사용할 수 있습니다. 개별 이벤트의 의미는 아래에서 자세히 설명합니다.

추적 지점의 출력은 ASCII 또는 바이너리 형식으로 사용할 수 있습니다. 이 부록은 현재 바이너리 인터페이스를 다루지 않습니다. ASCII 인터페이스는 두 가지 방법으로 사용할 수 있습니다. 링 버퍼의 현재 콘텐츠를 나열하려면 다음 명령을 입력합니다.

[root@chywoon gfs2]# cat /sys/kernel/debug/tracing/trace

이 인터페이스는 일정 기간 동안 장기 실행 프로세스를 사용하고 일부 이벤트 후 버퍼에서 최신 캡처된 정보를 다시 확인하려는 경우에 유용합니다. 대체 인터페이스 /sys/kernel/debug/tracing/trace_pipe 는 모든 출력이 필요할 때 사용할 수 있습니다. 이벤트가 발생하면 이 파일에서 읽습니다. 이 인터페이스를 통해 사용 가능한 기록 정보는 없습니다. 출력 형식은 두 인터페이스에서 모두 동일하며 이 부록의 이후 섹션에 있는 각 GFS2 이벤트에 대해 설명되어 있습니다.

trace-cmd 라는 유틸리티는 tracepoint 데이터를 읽는 데 사용할 수 있습니다. 이 유틸리티에 대한 자세한 내용은 http://lwn.net/Articles/341902/ 을 참조하십시오. trace-cmd 유틸리티를 사용하면 strace 유틸리티와 유사한 방식으로 사용할 수 있습니다. 예를 들어 다양한 소스에서 추적 데이터를 수집하는 동안 명령을 실행할 수 있습니다.

GFS2를 이해하기 위한 가장 중요한 개념과 다른 파일 시스템과 별도로 설정하는 개념은 glocks 개념입니다. 소스 코드 측면에서 glock은 DLM을 결합하고 단일 상태 시스템으로 캐싱하는 데이터 구조입니다. 각 glock은 단일 DLM 잠금과 1:1 관계가 있으며 해당 잠금 상태에 대한 캐싱을 제공하므로 파일 시스템의 단일 노드에서 수행되는 반복적인 작업이 DLM을 반복적으로 호출할 필요가 없으므로 불필요한 네트워크 트래픽을 방지할 수 있습니다. 두 가지 광범위한 범주의 glock이 있습니다. 캐시 메타데이터와 그렇지 않은 항목은 무엇입니까. inode glocks 및 리소스 그룹 모두 캐시 메타데이터, 기타 유형의 glocks는 캐시 메타데이터를 캐시하지 않습니다. inode glock은 메타데이터 외에 데이터 캐싱에도 포함되어 있으며 모든 glocks의 가장 복잡한 논리가 있습니다.

glock은 잠금 해제될 때까지(다른 노드의 요청 또는 VM 요청 시) 로컬 사용자가 없을 때까지 메모리에 유지됩니다. 그 시점에서 그들은 glock 해시 테이블에서 제거되고 해제됩니다. glock이 생성되면 DLM 잠금과 즉시 glock과 연결되지 않습니다. DLM 잠금은 DLM에 대한 첫 번째 요청 시 glock과 연결되며 이 요청이 성공하면 glock에 'I'(initial) 플래그가 설정됩니다. glock debugfs 인터페이스의 "Glock Flags" 테이블에는 다른 glock 플래그의 의미가 표시됩니다. DLM이 glock과 연결되면 glock을 해제할 때까지 DLM 잠금은 항상 NL (ECDHE) 잠금 모드를 유지합니다. 잠금 해제로 DLM 잠금을 해제하는 것은 항상 glock의 수명 중 마지막 작업입니다.

각 glock은 그에 연결된 여러 "보유자"를 가질 수 있으며, 각각은 상위 계층에서 하나의 잠금 요청을 나타냅니다. 코드의 중요한 섹션을 보호하기 위해 GFS2 큐와 관련된 시스템 호출 및 glock 소유자와 관련된 시스템 호출.

glock 상태 시스템은 작업 큐를 기반으로 합니다. 성능상의 이유로 tasklet이 더 바람직할 수 있지만, 현재 구현에서는 I/O를 해당 컨텍스트에서 제출하여 사용을 금지해야 합니다.

다음 표는 각 glock 모드에서 캐시될 수 있는 상태와 해당 캐시된 상태가 더러워질 수 있는지 여부를 보여줍니다. 이는 리소스 그룹 잠금에 대한 데이터 구성 요소가 없지만 메타데이터만 있지만 inode 및 리소스 그룹 잠금 모두에 적용됩니다.

glock debugfs 인터페이스를 사용하면 glock과 홀더의 내부 상태를 시각화할 수 있으며 경우에 따라 잠긴 객체에 대한 몇 가지 요약 세부 정보도 포함되어 있습니다. 파일의 각 줄은 들여쓰기 없이 G를 시작하거나(G: glock 자체 참조) 또는 다른 문자로 시작하여 단일 공백으로 들여쓰고, 파일 위의 glock과 연결된 구조를 나타냅니다(H: is a holder, I: an inode, and R: a resource group). 다음은 이 파일의 내용은 다음과 같습니다.

G:  s:SH n:5/75320 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:EX n:3/258028 f:yI t:EX d:EX/0 a:3 r:4
 H: s:EX f:tH e:0 p:4466 [postmark] gfs2_inplace_reserve_i+0x177/0x780 [gfs2]
 R: n:258028 f:05 b:22256/22256 i:16800
G:  s:EX n:2/219916 f:yfI t:EX d:EX/0 a:0 r:3
 I: n:75661/219916 t:8 f:0x10 d:0x00000000 s:7522/7522
G:  s:SH n:5/127205 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:EX n:2/50382 f:yfI t:EX d:EX/0 a:0 r:2
G:  s:SH n:5/302519 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:SH n:5/313874 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:SH n:5/271916 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:SH n:5/312732 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]

위의 예는 단일 노드 GFS2 파일 시스템에서 postmark 벤치마크를 실행하는 동안 cat /sys/kernel/gfs2/unity:myfs/glocks >my.lock 명령으로 생성된 일련의 발췌 (18MB 파일에서)입니다. 그림의 glocks는 glock dumps의 더 흥미로운 기능을 표시하기 위해 선택되었습니다.

glock 상태는 EX (exclusive), DF (deferred), SH (shared) 또는 UN (unlocked)입니다. 이러한 상태는 DLM null 잠금 상태를 나타내는 UN을 제외하고 DLM 잠금 모드와 직접 대응하거나, GFS2가 DLM 잠금을 유지하지 않습니다(위에 설명된 대로 I 플래그에 따라 다름). glock의 s: 필드는 잠금의 현재 상태를 나타내고 홀더의 동일한 필드는 요청된 모드를 나타냅니다. 잠금이 부여된 경우 홀더는 H 비트가 플래그 (f: 필드)에 설정됩니다. 그렇지 않으면 W wait 비트가 설정됩니다.

n: 필드(number)는 각 항목과 관련된 번호를 나타냅니다. glocks의 경우, 즉 유형 번호이며 위의 예에서 첫 번째 glock은 n:5/7532mtls이며, inode 75320과 관련된 iopen glock을 나타냅니다. inode와 iopen glocks의 경우 glock 번호는 항상 inode의 디스크 블록 번호와 동일합니다.

소유자와 glock 모두에 대한 모든 플래그의 전체 목록은 아래의 "Glock Flags" 테이블 및 Glock 보유자 의 "Glock Holder 플래그" 테이블에 설정됩니다. 잠금 값 블록의 내용은 현재 glock debugfs 인터페이스를 통해 사용할 수 없습니다. 다음 표에서는 다른 glock 유형의 의미를 보여줍니다.

가장 중요한 glock 플래그 중 하나는 l (locked) 플래그입니다. 이는 상태 변경을 수행해야 할 때 glock 상태에 대한 액세스를 중재하는 데 사용되는 비트 잠금입니다. 상태 시스템이 DLM을 통해 원격 잠금 요청을 보내려는 경우 설정되고 전체 작업이 수행된 경우에만 삭제됩니다. 경우에 따라 여러 번 발생하는 다양한 무효화로 두 개 이상의 잠금 요청이 전송됨을 의미할 수 있습니다.

다음 표는 다른 glock 플래그의 의미를 보여줍니다.

로컬 노드에서 보유 중인 것과 충돌하는 모드에서 잠금을 가져오려는 노드에서 원격 콜백을 수신하면 두 플래그 D(demote) 또는 d(demote pending) 중 하나 또는 기타와 충돌합니다. 특정 잠금에 경합이 있을 때 배지 상태를 방지하기 위해 각 잠금에는 최소 대기 시간이 할당됩니다. 최소 보류 시간에 대한 잠금이 없는 노드는 간격이 만료될 때까지 해당 잠금을 유지할 수 있습니다.

시간 간격이 만료된 경우 D(demote) 플래그가 설정되고 필요한 상태가 기록됩니다. 이 경우 다음에 홀더 큐에 잠금이 부여되지 않으면 잠금이 차단됩니다. 시간 간격이 만료되지 않은 경우 d(demote pending) 플래그가 대신 설정됩니다. 또한 최소 대기 시간이 만료되면 d(데류 중 보류 중)를 지우도록 상태 시스템을 예약하고 D(demote)를 설정합니다.

glock에 DLM 잠금이 할당되면 I(initial) 플래그가 설정됩니다. 이는 glock이 처음 사용되고, I 플래그는 glock이 최종적으로 해제될 때까지( DLM 잠금을 잠금 해제) 때까지 설정된 상태로 유지됩니다.

다음 표는 다른 glock 홀더 플래그의 의미를 보여줍니다.

앞서 언급한 대로 가장 중요한 홀더 플래그는 H(소유자)와 W(wait)입니다. 이는 각각 부여된 잠금 요청 및 대기 중인 잠금 요청을 설정되었기 때문입니다. 목록에 있는 홀더의 순서가 중요합니다. 부여된 소유자가 있는 경우, 해당 소유자는 항상 큐의 헤드에 있고 그 후에는 대기 중인 소유자입니다.

지정된 홀더가 없는 경우 목록의 첫 번째 소유자는 다음 상태 변경을 트리거하는 대상이 됩니다. demote 요청은 파일 시스템의 요청보다 항상 우선 순위가 높기 때문에 항상 요청된 상태를 직접 변경할 수는 없습니다.

glock 하위 시스템은 두 가지 종류의 "try" 잠금을 지원합니다. 이는 정상적인 순서(적용 백오프 및 재시도)를 생략하는 것을 허용하고 다른 노드에서 리소스를 사용하지 않도록 하는 데 사용할 수 있기 때문에 둘 다 유용합니다. 일반적인 T (try) 잠금은 이름이 나타내는 것입니다; 특별한 작업을 수행하지 않는 "try" 잠금입니다. 반면, T (try 1CB) 잠금은 DLM이 현재 호환되지 않는 잠금 홀더에 단일 콜백을 보내는 것을 제외하고는 t 잠금과 동일합니다. T (try 1CB) 잠금의 한 가지 사용에는 iopen 잠금이 있으며, inode의 i_nlink 수가 0일 때 노드 간에 중재되는 데 사용되는 iopen 잠금이 있으며, inode를 재배치할 노드를 결정합니다. iopen glock은 일반적으로 공유 상태에 있지만 i_nlink 수가 0이 되고 →evict_inode()가 호출되면 T (try 1CB수행)가 설정된 배타적 잠금을 요청합니다. 잠금이 부여된 경우 inode 할당을 계속 해제합니다. 잠금이 부여되지 않으면 노드 (s)가 D (demote) 플래그를 사용하여 glock을 표시하는 것을 방지했습니다.이 플래그 (demote) 플래그. →drop_inode() 시간에 체크되어 거래 위치를 잊혀지지 않도록 합니다.

즉, 링크 수가 0개 있지만 열려 있는 inode는 최종 닫기()가 발생하는 노드에서 할당 해제됩니다. 또한 inode의 링크 수와 동시에 inode가 0으로 감소하고, inode는 제로 링크 수가 없는 특수 상태에 있지만 리소스 그룹 rootfs에서 여전히 사용 중인 것으로 표시됩니다. 이 함수는 ext3 파일 system3의 고립 목록과 같은 함수를 통해 비트맵의 이후 리더는 회수될 가능성이 있는 공간이 있음을 알 수 있고 회수를 시도합니다.

또한 추적 지점은 blktrace 출력과 디스크상의 레이아웃에 대한 정보와 결합하여 캐시 컨트롤의 정확성을 확인할 수 있도록 설계되었습니다. 그런 다음 주어진 I/O가 올바른 잠금에 따라 발행 및 완료되었는지, 그리고 아무런 경쟁이 없는지 확인할 수 있습니다.

gfs2_glock_state_change tracepoint는 이해해야 할 가장 중요한 요소입니다. 이 명령은 gfs2_glock_put 로 끝나는 최종 데모를 통해 초기 생성 시 glock의 모든 상태 변경을 추적하고 최종 NL으로 전환하여 전환을 잠금 해제할 수 있습니다. l (locked) 플래그는 항상 상태 변경이 발생하기 전에 설정되며 완료된 후 지워지지 않습니다. 상태 변경 중에 부여 된 소유자 (H glock holder 플래그)는 없습니다. 대기 중인 홀더가 있는 경우 항상 W (waiting) 상태가 됩니다. 상태 변경이 완료되면 l glock 플래그가 지워지기 전에 최종 작업인 홀더가 부여될 수 있습니다.

gfs2_demote_rq tracepoint는 로컬 및 원격 둘 다 데모 요청을 추적합니다. 노드에 충분한 메모리가 있다고 가정하면 로컬 데모 요청이 거의 표시되지 않으며 대부분의 경우 umount 또는 메모리 회수에 의해 생성됩니다. 원격 데모 요청 수는 특정 inode 또는 리소스 그룹의 노드 간 경합 측정입니다.

gfs2_glock_lock_time 추적 포인트는 DLM에 대한 요청에서 가져온 시간에 대한 정보를 제공합니다. 차단 (b) 플래그는이 추적 포인트와 함께 사용하기 위해 특별히 glock에 도입되었습니다.

홀더에 잠금이 부여되면 gfs2_promote 가 호출되면 상태 변경의 최종 단계 또는 glock 상태에 이미 적합한 모드의 잠금을 캐싱하여 즉시 부여할 수 있는 잠금이 요청될 수 있습니다. 소유자가 이 glock에 대해 부여해야 하는 첫 번째 플래그인 경우 해당 홀더에 f(first) 플래그가 설정됩니다. 이는 현재 리소스 그룹에서만 사용됩니다.

블록 매핑은 모든 파일 시스템에 중심적인 작업입니다. GFS2는 블록당 두 비트가 있는 기존의 비트 기반 시스템을 사용합니다. 이 하위 시스템의 추적 지점의 주요 목적은 블록을 할당 및 매핑하는 데 걸리는 시간을 모니터링할 수 있도록 하는 것입니다.

gfs2_bmap tracepoint는 각 bmap 작업에 대해 두 번 호출됩니다. bmap 요청을 표시하기 시작할 때 한 번 결과를 표시합니다. 이렇게 하면 요청과 결과를 함께 일치시키고 파일 시스템의 다양한 부분에 있는 블록을 매핑하는 데 걸리는 시간을 측정하거나 다른 파일 오프셋 또는 다른 파일도 측정할 수 있습니다. 또한 반환되는 평균 범위 크기가 요청되는 항목과 비교하여 확인할 수 있습니다.

gfs2_rs 추적 추적 블록 예약은 블록 할당기에서 생성, 사용 및 삭제됩니다.

할당된 블록을 추적하기 위해 gfs2_block_alloc 은 할당 시뿐만 아니라 블록을 해제하는 경우에도 호출됩니다. 할당은 모두 블록이 의도한 inode에 따라 참조되므로, 라이브 파일 시스템에서 어떤 물리 블록이 속하는지 추적할 수 있습니다. 이는 blktrace 와 결합할 때 특히 유용하며, 이는 이 추적점에서 얻은 매핑을 사용하여 관련 inode로 다시 참조할 수 있는 문제가 있는 I/O 패턴을 표시합니다.

직접 I/O(iomap)는 디스크와 사용자의 버퍼 간에 직접 파일 데이터 전송을 수행할 수 있는 대체 캐시 정책입니다. 이로 인해 캐시 적중률이 낮을 경우 이점이 있습니다. gfs2_iomap_start 및 gfs2_iomap_end tracepoints는 이러한 작업을 추적하며, 작업 유형과 함께 Direct I/O 파일 시스템인 Direct I/O를 사용하여 매핑을 추적할 수 있습니다.

이 하위 시스템의 tracepoints는 저널(gfs2_pin)에 추가되거나 제거되는 블록을 추적하고, 트랜잭션을 로그로 커밋하는 데 걸린 시간(gfs2_log_flush)을 추적합니다. 이 기능은 저널된 성능 문제를 디버깅하려고 할 때 매우 유용할 수 있습니다.

gfs2_log_blocks tracepoint는 로그에서 예약된 블록을 추적하여 워크로드에 대한 로그가 너무 작은지 여부를 표시하는 데 도움이 됩니다.

gfs2_ail_flush tracepoint는 gfs2_log_flush 추적 지점에서 AIL 목록의 시작 및 종료를 추적할 수 있습니다. AIL 목록에는 로그를 통과했지만 아직 다시 작성되지 않은 버퍼가 포함되어 있으며, 파일 시스템에서 사용하기 위해 더 많은 로그 공간을 해제하거나 프로세스에서 동기화 또는 fsync 를 요청할 때 정기적으로 플러시됩니다.

GFS2는 파일 시스템 내에서 발생하는 상황을 추적하는 데 도움이 되는 통계를 유지 관리합니다. 이를 통해 성능 문제를 해결할 수 있습니다.

GFS2는 다음 두 카운터를 유지 관리합니다.

또한 GFS2는 세 개의 평균/변수 쌍을 유지합니다. mean/variance 쌍은 기하급수적인 추정치이며 사용된 알고리즘은 네트워크 코드에서 왕복 시간을 계산하는 데 사용됩니다.

GFS2에서 유지 관리되는 평균 및 분산 쌍은 확장되지 않지만 정수 나노초 단위로 구성되어 있습니다.

차단되지 않은 요청은 DLM 잠금의 상태가 무엇이든 즉시 완료되는 요청입니다. 현재 (a) 현재 잠금 상태가 배타적인 경우(b) 요청된 상태가 null이거나 잠금 해제되거나 (c) "try lock" 플래그가 설정됨을 의미합니다. 차단 요청은 다른 모든 잠금 요청을 처리합니다.

recordsTT에 더 많은 시간이 더 나은 반면, RTT에 더 작은 시간은 더 좋습니다.

통계는 두 개의 sysfs 파일에 유지됩니다.

tracepoints 및 GFS2 glocks 파일에 대한 자세한 내용은 다음 리소스를 참조하십시오.

올바르게 작동하기 위해 GFS2 PMDA를 사용하려면 debugfs 파일 시스템이 마운트되어야 합니다. debugfs 파일 시스템이 마운트되지 않은 경우 GFS2 PMDA를 설치하기 전에 다음 명령을 실행합니다.

# mkdir /sys/kernel/debug
# mount -t debugfs none /sys/kernel/debug

GFS2 PMDA는 기본 설치의 일부로 활성화되어 있지 않습니다. PCP를 통한 GFS2 메트릭 모니터링을 사용하려면 설치 후 활성화해야 합니다.

다음 명령을 실행하여 PCP를 설치하고 GFS2 PMDA를 활성화합니다. PMDA 설치 스크립트는 root로 실행해야 합니다.

# dnf install pcp pcp-pmda-gfs2
# cd /var/lib/pcp/pmdas/gfs2
# ./Install
Updating the Performance Metrics Name Space (PMNS) ...
Terminate PMDA if already installed ...
Updating the PMCD control file, and notifying PMCD ...
Check gfs2 metrics have appeared ... 346 metrics and 255 values

pminfo 툴은 사용 가능한 성능 지표에 대한 정보를 표시합니다. 다음 예제에서는 이 툴을 사용하여 표시할 수 있는 다양한 GFS2 지표를 보여줍니다.

# pminfo -f gfs2.glocks

gfs2.glocks.total
    inst [0 or "afc_cluster:data"] value 43680
    inst [1 or "afc_cluster:bin"] value 2091

gfs2.glocks.shared
    inst [0 or "afc_cluster:data"] value 25
    inst [1 or "afc_cluster:bin"] value 25

gfs2.glocks.unlocked
    inst [0 or "afc_cluster:data"] value 43652
    inst [1 or "afc_cluster:bin"] value 2063

gfs2.glocks.deferred
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

gfs2.glocks.exclusive
    inst [0 or "afc_cluster:data"] value 3
    inst [1 or "afc_cluster:bin"] value 3

# pminfo -f gfs2.glstats

gfs2.glstats.total
    inst [0 or "afc_cluster:data"] value 43680
    inst [1 or "afc_cluster:bin"] value 2091

gfs2.glstats.trans
    inst [0 or "afc_cluster:data"] value 3
    inst [1 or "afc_cluster:bin"] value 3

gfs2.glstats.inode
    inst [0 or "afc_cluster:data"] value 17
    inst [1 or "afc_cluster:bin"] value 17

gfs2.glstats.rgrp
    inst [0 or "afc_cluster:data"] value 43642
    inst [1 or "afc_cluster:bin"] value 2053

gfs2.glstats.meta
    inst [0 or "afc_cluster:data"] value 1
    inst [1 or "afc_cluster:bin"] value 1

gfs2.glstats.iopen
    inst [0 or "afc_cluster:data"] value 16
    inst [1 or "afc_cluster:bin"] value 16

gfs2.glstats.flock
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

gfs2.glstats.quota
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

gfs2.glstats.journal
    inst [0 or "afc_cluster:data"] value 1
    inst [1 or "afc_cluster:bin"] value 1

# pminfo -f gfs2.holders.flags.wait

gfs2.holders.flags.wait
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

# pmstore gfs2.control.tracepoints.all 1
gfs2.control.tracepoints.all old value=0 new value=1

# pminfo -f gfs2.latency.grant.all gfs2.latency.demote.all

gfs2.latency.grant.all
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

gfs2.latency.demote.all
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

# pminfo -f gfs2.latency.grant.all gfs2.latency.demote.all

gfs2.tracepoints.promote.other.null_lock
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.concurrent_read
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.concurrent_write
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.protected_read
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.protected_write
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.exclusive
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

# pminfo -f gfs2.tracepoints.demote_rq.requested

gfs2.tracepoints.demote_rq.requested.remote
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.demote_rq.requested.local
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

# pminfo -f gfs2.tracepoints.log_flush.total]

gfs2.tracepoints.log_flush.total
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

다음 표는 GFS2 파일 시스템의 pcp-pmda-gfs2 패키지에서 제공하는 전체 성능 지표 목록을 설명합니다.

다음 절차에서는 Red Hat Enterprise Linux에서 통계를 수집하기 위해 최소 PCP 설정을 설치하는 방법에 대해 간단히 설명합니다. 이 설정에는 추가 분석을 위해 데이터를 수집하는 데 필요한 프로덕션 시스템에 최소 패키지 수를 추가해야 합니다.

pmlogger 출력의 tar.gz 아카이브는 추가 PCP 툴을 사용하여 분석할 수 있으며 다른 성능 정보 소스와 비교할 수 있습니다.