Red Hat Training

A Red Hat training course is available for RHEL 8

1.3. GFS2 포맷 고려 사항

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

중요

Red Hat High Availability Add-On의 배포가 고객의 요구 사항을 충족하고 지원을 받을 수 있는지 확인하십시오. 인증 Red Hat 담당자에게 문의하여 배포 전에 구성을 확인하십시오.

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

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

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

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

  • 각 파일 시스템을 백업하는 데 시간이 단축됩니다.
  • fsck.gfs2 명령을 사용하여 파일 시스템을 확인해야 하는 경우 시간이 단축됩니다.
  • fsck.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에서는 다음 두 가지 방법으로 이 문제를 해결하려고 합니다.

  • 먼저 리소스 그룹이 완전히 가득 차면 블록이 해제될 때까지 향후 할당에 대해 이를 확인하지 않도록 합니다. 파일을 삭제하지 않으면 경합이 덜 심각합니다. 그러나 애플리케이션이 지속적으로 블록을 삭제하고 주로 전체 파일 시스템에 새 블록을 할당하는 경우 경합이 매우 높아지고 성능에 심각한 영향을 미칩니다.
  • 두 번째, 기존 파일(예: 추가) 새 블록이 추가된 경우, GFS2에서 파일과 동일한 리소스 그룹에 새 블록을 그룹화하려고 합니다. 이는 성능을 높이기 위해 수행됩니다: 회전 디스크에서는 물리적으로 함께 닫을 때 검색 작업에 시간이 단축됩니다.

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