1.4. GFS2 노드 잠금 기능


GFS2 파일 시스템에서 최상의 성능을 얻기 위해서는 이의 동작에 대한 기본적인 이론을 이해하고 있는 것이 매우 중요합니다. 단일 노드 파일 시스템은 캐시와 함께 구현되며 요청되는 데이터를 자주 사용하는 경우 디스크 액세스의 대기 시간을 없애는 것을 목적으로 하고 있습니다. Linux에서 페이지 캐시 (및 버퍼 캐시)는 이러한 캐싱 기능을 제공합니다.
GFS2와 함께 각 노드에는 온디스크 데이터의 일부가 들어있는 자체적 페이지 캐시가 있습니다. GFS2는 glocks (gee-locks라고 발음함)라는 잠금 메커니즘을 사용하여 노드 사이의 캐시의 무결성을 관리합니다. glock 서브시스템은 기본 통신 계층으로 DLM (distributed lock manager)를 사용하여 구현되는 캐시 관리 기능을 제공합니다.
glocks는 inode 기반 캐시에 대해 보호되므로 inode 당 하나의 잠금 기능은 캐싱 계층을 제어하는데 사용됩니다. glock이 공유 모드 (DLM 잠금 모드: PR)에서 부여되면 glock 하의 데이터는 동시에 하나 이상의 노드에서 캐시될 수 있으므로 모든 노드가 데이터에 로컬로 액세스할 수 있게 됩니다.
glock이 전용 모드 (DLM 잠금 모드: EX)에서 부여되면 단일 노드만이 glock 하에 있는 데이터를 캐시할 수 있습니다. 이러한 모드는 데이터를 수정하는 모든 작업에 사용됩니다. (write 시스템 호출 등)
다른 노드가 즉시 부여될 수 없는 glock을 요청할 경우, DLM은 노드 또는 새로운 요청을 차단하는 glock을 현재 보유하고 있는 노드에 메세지를 보내 잠금을 드롭하도록 지시합니다. glock을 드롭하는 과정은 오랜 시간이 걸릴 수 있습니다 (대부분의 파일 시스템 작업 기준에 의해). 공유 glock을 드롭하는 경우 캐시된 데이터의 양에 비례하며 비교적 신속한 무효화된 캐시만을 필요로 합니다.
전용 glock을 드롭하려면 로그 플러시 후, 변경된 데이터를 디스크에 쓰는 작업이 필요하며, 이후에 공유 glock 별로 무효화 작업을 합니다.
단일 노드 파일 시스템의 캐시는 하나이지만 GFS2는 각 노드에 캐시가 따로 있는 것이 단일 노드 파일 시스템과 GFS2의 다른점입니다. 두 경우 모두 캐시된 데이터로의 액세스 대기 시간에 대한 크기의 정도가 비슷하지만 캐시되지 않은 데이터로의 액세스 대기 시간에 대해서는 다른 노드가 동일한 데이터를 캐시할 경우 GFS2 에서 훨씬 길어집니다.

참고

GFS2 캐싱 기능을 구현하는 방법은 다음과 같은 경우에 최상의 성능을 얻습니다:
  • inode가 모든 노드에 걸쳐 읽기 전용으로 사용되는 경우
  • inode가 단일 노드에서만 쓰기 또는 수정되는 경우
파일 작성 및 삭제 시 디렉토에 항목을 삽입하고나 제거하는 것은 디렉토리 inode에 쓰기로 계산되므로 주의하십시오.
규칙을 깨는 것은 극히 드물지만 이러한 규칙을 깨는 것이 가능합니다. 너무 자주 규칙을 무시할 경우 성능에 심각한 영향을 미칠 수 있습니다.
읽기/쓰기 맵핑으로 GFS2에 있는 파일을 mmap() 하고 있지만 읽기 전용으로할 경우, 이는 읽기로만 계산됩니다. GFS에서는 쓰기로 계산되기 때문에 mmap() I/O를 사용하는 경우 GFS2가 더 확장성이 높아집니다.
noatime mount 매개 변수를 설정하지 않은 경우, 파일의 타임 스탬프를 업데이트하기 위해 읽기도 기입됩니다. 모든 GFS2 사용자는 atime에 대해 특정 요구 사항이 없는 한 noatime으로 마운트하는 것이 좋습니다.

1.4.1. GFS2로 성능 조정

성능 향상을 위해 문제를 일으키는 응용 프로그램은 데이터를 저장하는 방법을 변경할 수 있습니다.
문제를 일으키는 응용 프로그램의 전형적인 예는 이메일 서버입니다. 이는 일반적으로 각 사용자에 대한 파일이 들어있는 스풀 디렉토리 (mbox) 또는 각 메세지에 대한 파일이 들어있는 각 사용자의 디렉토리 (maildir)로 구성되어 있습니다. IMAP를 통해 요청이 도착하면 특정 노드에 대한 동질 관계를 각 사용자에게 제공하는 이상적인 구성입니다. 이러한 방식에서 이메일 메세지 보기 및 삭제 요청은 하나의 노드에 있는 캐시에서 제공되는 경향이 있습니다. 노드에 장애가 발생했을 경우 다른 노드에서 세션을 다시 시작할 수 있습니다.
메일이 SMTP를 통해 도착한 경우에도 기본값으로 특정 사용자의 메일이 특정 노드에 전달되도록 노드를 개별적으로 설정할 수 있습니다. 기본 노드가 설정되어 있지 않은 경우, 메세지는 수신 노드에 의해 사용자의 메일 스풀에 직접 저장될 수 있습니다. 이는 일반적인 경우 하나의 노드에 캐시된 특정 파일 모음을 보관하기 위한 것으로 노드 장애 발생 시 직접 액세스를 허용하기 위함입니다.
이 설정은 GFS2의 페이지 캐시를 최대한 활용하여 imap 또는 smtp 응용 프로그램 중 하나에 장애를 투명하게 할 수 있습니다.
백업 또한 까다로운 부분 중 하나입니다. 가능하다면 특정 inode 집합을 캐싱하고 있는 노드에서 작업중인 각 노드 집합을 직접 백업하는 것이 좋습니다. 일정 시점에 실행하는 백업 스크립트가 있고 GFS2에서 실행되고 있는 응용 프로그램의 응답 시간의 증가와 일치할 경우, 페이지 캐시가 클러스터에 의해 효율적으로 사용되고 있지 않을 가능성이 높습니다.
백업을 수행하기 위해 응용 프로그램을 중지할 수 있는 경우에는 문제가 없지만, 백업이 하나의 노드에서만 실행되는 경우 백업이 완료되면 파일 시스템의 대부분이 노드에 캐시되며 다른 노드에서의 차후 액세스 성능이 저하됩니다. 이는 다음과 같은 명령을 사용하여 백업 완료 후 백업 노드에 VFS 페이지 캐시를 드롭하여 어느정도 완화될 수 있습니다.
echo -n 3 >/proc/sys/vm/drop_caches
하지만 각 노드에서 작동 중인 집합이 클러스터에 걸쳐 대부분 읽기 전용으로 공유되거나 단일 노드에서널리 사용되도록 항상 주의하는 것이 적합한 솔루션입니다.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.