솔라리스 ZFS 환경에서의 NFS 퍼포먼스 관리

출처 : http://blog.sdnkorea.com/

썬 마이크로시스템즈가 스토리지 제품군에 포함한 솔라리스의 제타 파일 시스템(ZFS) 은 파일시스템이 export 되는 방법 혹은 원격 클라이언트들에게 share 되는 방법에서 NFS 의 퍼포먼스 문제를 노출 하였습니다. 참고로 이 글에서는 export 와 share 는 클라이언트가 그들의 로컬 파일 시스템에 마운트 할 수 있는 경로를 의미 합니다.

다른 퍼포먼스 이슈들과 마찬가지로 이 문제의 원인은 서비스 확장시에 발생합니다: 솔라리스 ZFS 는 유저가 적게는 한두개에서 많게는 수천개 까지의 export 가 가능하도록 합니다. 과거에 썬 NFS 팀의 해결책은 export 파일 시스템에 접근하는 클라이언트의 숫자 증가에 대비해서 인증 캐시를 추가하는 것이였습니다. ZFS 가 노출한 문제를 완화시키기 위하여 export 를 위한 또 다른 캐시가 추가 되었습니다. 그러나 팀은 share 자체에 대한 비용 또한 줄여야 했습니다.

확장성 문제는 20년 전 부터 지금까지 NFS 박스의 배치에 대한 방법론으로 정의되어 왔습니다. 예전에는 서버에 보통 수십개의 파일 시스템과 클라이언트들이 존재했었습니다. 클라이언트 인증 비용은 무시할 수 있었습니다. 또한 클라이언트들이 같은 네트워크 세그먼트에 있었고 파일 서버이면서 동시에 네임 서버 역활을 하기도 했었습니다. 오직 소수의 파일 시스템과 export 하위 노드들은 export 하지 않는 제약등으로 인해서 머신들은 export 를 메모리에 빠르게 로드할 수 있었습니다.

그러나 대규모의 인트라넷, automounter, 컴퓨팅 팜, 솔라리스 ZFS 를 이용한 NFS export 의 증가들은 이러한 초창기의 가정들을 바꾸어 왔습니다. 이 글은 이러한 어려움들에 대한 소개와 현재 환경의 요구조건에 맞는 변화에 대해 설명 합니다.

참고: 이 글은 오픈솔라리스 버전의 멘 페이지를 참고 합니다. 여러분은 오픈솔라리스 멘 페이지를 tar 포맷 형식으로 다운 받으실 수 있습니다.

대규모의 인트라넷

첫번째 변화는 대규모 인트라넷의 개발 입니다. 빌딩의 각 층마다 각각의 서브넷과 서로다른 비지니스 부서가 있는 -- 예를들어 마케팅 부서는 2층에 있고 엔지니어링 부서는 5층에 있는 모델을 생각해 봅시다. 그 다음에 이 것을 여러개의 빌딩으로 확대해 봅시다. 결과적으로 원격 접근은 많은 서브넷 세그먼트들을 거쳐야 합니다; 네임 서비스가 다운 되거나 죽었다고 생각될 정도로 느린 경우도 있을 수 있습니다; 그리고 관리자가 몇몇 호스트들의 서버 접근 금지를 원할 수도 있습니다.

그러므로 export 를 아래와 같은 방법에서:

share -F nfs -d "home dirs" /export/home

아래와 같은 방법으로 변경합니다:

share -F nfs -o rw=engineering -d "home dirs" /export/home

첫번째 방법은 접근 권한을 결정하기 위해 네임 서버에 문의할 필요가 없습니다: 모든 호스트들은 기본적으로 rw 접근이 허용 됩니다. 그러나 두번째 방법에서는 신뢰 접근(privileged access) 방법을 사용함으로써 오직 mount 요청에만 접근 권한을 확인합니다. 만약 클라이언트가 접근 권한을 가지고 있다면 export 포인트의 루트 파일 핸들을 얻어 옵니다. 그런 다음 NFS 프로토콜 요청은 유효한 파일 핸들을 가지고 있기 때문에 인증되었다고 신뢰 됩니다.

퍼포먼스 측면에서 볼때 이것은 큰 성과 입니다: mount 요청은 NFS 요청에 비해 자주 이루어지지 않기 때문입니다. 그러나 보안 측면에서 볼때 이것은 큰 손실 입니다: 네트워크 트래픽을 가로채고 파일 핸들을 속이기가 쉽기 때문입니다. 유효한 파일 핸들을 얻은 다음부터는 그 share 에 대한 접근 권한을 가지게 됩니다.

이 문제에 대한 해결책을 제시하기 전에 여러분 자신에게 먼저 물어보시기 바랍니다; 왜 네임 서비스 호출이 잘못됐을까요? 그에 대한 대답은 네트워크로의 통신과 디스크로의 통신간의 차이 때문입니다. 진짜 문제는 네트워크 문제 때문에 혹은 서버가 다운되서 네임 서버에 접근하지 못했을때 발생합니다. 만약 모든 NFS 요청이 20초씩 걸린다면 관리자가 export 에서 호스트 제약사항 제거를 시작하기 전까지 얼마의 시간이 걸릴까요? 결국 종합해 보면 호스트 접근 목록에 각 항목들마다 네임서버로의 요청이 약 20초씩 걸리게 될 것입니다.

인증 캐시

디스크와의 비교가 해답을 줄 수 있습니다: 마운트 데몬 mountd(1M) 는 주어진 호스트가 주어진 export 에 접근이 가능한지 불가능한지를 판단해주는 캐시가 필요 합니다. 1995년과 1996년에 Brent Callaghan 은 Connectathon 에서 이러한 이슈를 해결하기 위한 작업에 대해서 발표한 적이 있습니다. mount 요청이 들어 오면 인증 캐시가 클라이언트의 접근 권한을 체크 합니다. 캐시에 해당 항목이 존재하면 결과 퍼미션을 리턴해 줍니다. 캐시에 해당 항목이 존재하지 않으면 호스트 이름과 네트워크그룹을 해석하기 위해 네임 버서를 체크 합니다.

그러나 오직 mountd 요청만을 체크하는 것은 충분하지 않습니다. 첫째로 서버는 재부팅 될 수 있고 share 에 접근하는 클라이언트들의 현존하는 퍼미션들을 날려버릴 수 있습니다. 둘째로 여전히 NFS 요청을 속이는 것이 가능합니다. 해결책은 모든 NFS 요청마다 인증하는 것입니다. 응답시간을 줄이기 위해서는 인증 캐시를 생성하는 것과 동일한 알고리즘을 따라야 합니다. 주의할 점으로는 클라이언트들은 어떻게든 mountd 요청을 포기하도록 디자인 되어야 한다는 것입니다. 일반적으로 이러한 요청은 UDP 입니다. 그러나 NFS 요청에 대한 빠른 응답을 엄격하게 요구 합니다.

1996년 NFS Client Authentication (PDF) 프리젠테이션에서 Brent 는 인증 캐시와 네임서버 트래픽에 행동 예측에 대한 대한 두가지 그래프를 제시했습니다. 이러한 그래프들은 실제 데이타에 기반하고 있지 않습니다. 그러므로 아무런 고려 없이 이러한 그래프를 따르는 것은 퍼포먼스에 대한 혼동을 유발할 수 있습니다. 그림 1은 인증 캐시 증가에 대한 그래프를 보여 줍니다.

그림 1: 인증 캐시 증가율

처음에 여러분은 캐시에는 어떠한 제한도 없다고 생각하실 수 있습니다. 그러나 Brent 는 "Reclaim"(회수) 에 대해 명쾌하게 설명 했는데 이것은 메모리 메니저의 메모리 회수 요청이나 혹은 데이타가 유실되는 것을 의미 합니다. 그래프의 이러한 지점들에서 서버는 캐시의 항목들을 삭제 합니다.

이제 Brent 의 프리젠테이션에서 네임 서버에 대한 트레픽을 나타내는 그림 2를 살펴 보겠습니다.

그림 2: 인증 네임 서비스에 대한 트래픽

그림에서 보면 캐시가 채워질수록 트래픽이 줄어듦을 알 수 있습니다.

발생할 수 있는 퍼포먼스 이슈들은 다음과 같은 질문과 연관이 있습니다:

• 캐시는 얼마나 커질 수 있을까?
• 네임 서버에서 요청이 응답되는 시간이 얼마나 걸릴까?
• 재부팅의 경우엔 캐시를 다시 채우는데 얼마나 걸릴까?

이러한 질문들은 새로운 것이 아니지만 다시 한번 말하자면, 1996년에 가능한 NFS 클라이언트 배치에서는 이러한 항목들을 무시해도 괜찮았습니다. 퍼포먼스는 만족할 수준이였습니다.

Automounter

비지니스 공간이 늘어나는것을 제외하고 퍼포먼스에 영향을 줄 수 있는 두번째 요소는 automounter 의 적용입니다. automounter 는 클라이언트에서 자동으로 그리고 암시적으로 export 를 마운트 하는 서비스로써 관리자가 수동적이고 명시적으로 마운트 하는 것과는 정반대 입니다. automount 의 가장 간단한 사용법은 NFS 서버에 사용가능한 모든 export 의 목록을 요청 하는 것입니다. 이것은 실제로 mountd 프로토콜의 하나의 RPC 호출이고 기본적으로 showmount -e. 의 코어 알고리즘 입니다. 문제는 대부분의 서버들이 이러한 목록을 생성하는대에 최적화 되지 않았다는 것입니다. 다시말해서 mountd RPC 호출은 희귀하고 솔라리스의 디자이너는 메인메모리를 소모하는 것 대신에 데이타를 디스크에 저장하는 것을 택했었습니다. 여러분은 이 글의 이후 섹션에서 좀 더 자세히 알 수 있을 것입니다.

automounter 의 또다른 알고리즘은 서버로 부터 모든 것을 마운트 하는 것입니다. 이것은 클라이언트 측면에서 영리한 숏컷(shortcut) 임이 드러 났습니다. 만약 어플리케이션이 하나의 서버에 하나의 share 에 접근하고자 한다면 이것은 다른 share 들을 검색할 것입니다.

소수의 share, 짧은 호스트 접근 목록, 그리고 적은 수의 클라이언트 환경에서 이것은 퍼포먼스에 영향을 주지 않습니다. 그러나 이중에 하나라도 증가하기 시작하면 이러한 접근은 심각한 병목현상을 유발 합니다. 그리고 만약 셋 모두 증가하면 이것은 어플리케이션의 퍼포먼스를 저하 시킵니다.

여러분은 접근 목록의 호스트 숫자 증가가 어떻게 문제가 되는지 궁금해 할 것입니다. 그 이유는 목록의 각 항목은 잠재적으로 네임 서버로의 호출을 의미하기 때문입니다. 그리고 만약 NFS 서버가 네임 서버의 결과를 캐싱하지 않고, 넷그룹 확장은 캐시하지 않거나 혹은 네임 서버가 아니라면 각 호스트는 네트워크 상으로의 호출을 유발합니다. 여러분의 네임 캐시 데몬의 견고함 (nscd(1M)) 은 여러분의 mountd(1M) 과 NFS 데몬 (nfsd(1M)) 에 퍼포먼스와 견고함에 크게 영향을 미칩니다.

컴퓨팅 팜

확장성 이슈의 세번째 요인은 점점 증가하고 있는 대규모의 클라이언트 팜에 대한 관심과 배치 때문입니다. 회로 레이아웃, 시뮬레이션, 이미지 렌더링 등은 모두 일반적인 문제의 해결을 위해서 다수의 클라이언트들을 클러스터링 하는 형식의 엔터프라이즈 아키텍쳐를 가지고 있습니다. 그리고 이러한 솔루션에서 NFS 는 중간, 혹은 최종 결과를 저장하는데 사용 됩니다. 클라이언트에는 어떠한 저장장치도 존재하지 않을 수 있습니다; 클러스터는 로컬 스토리지 사용이 허용되지 않을 수도 있고; 혹은 정기적인 어카이브 백업을 포함한 클라이언트의 스토리지를 신뢰히지 못할 수도 있습니다. 기업들은 현재 -- 혹은 예상으로 -- 2만개 이상의 클라이언트를 이러한 컴퓨팅 팜에 가지고 있습니다.

이제 문제는 캐싱되어야 하는 클라리언트의 숫자 뿐만 아니라 임시적인 동기화도 포함하게 됩니다. 작업이 사직되면 512개의 노드가 컴포넌트를 처리하도록 선택 됩니다. 이 시점에서 모든 작업들은 컨트롤 파일을 열것이고 툴을 로드하고 작업을 시작할 것입니다. 각 NFS 서버는 캐시 미스를 처리할때 마다 네임 서버에 엄청난 부하를 가져올 것입니다. 그리고 여러분이 이전에 보았듯이 캐시 사이즈와 메모리 청소 알고리즘에 따라 인증 캐시와 ncsd 항목들은 회수(reclaim)될 수도 있습니다.

연산작업 후에 모든 노드들은 각각 결과치를 저장할 것입니다. 그들은 각각 고유의 데이타 파일을 가지고 있을 수도 있습니다. 그러나 대부분의 경우에는 하나의 파일 서버의 공통 share 를 사용할 것입니다. 이 시점에서 캐시 미스가 다시 일어날 수도 있습니다. 이 하나의 작업이 클러스터내의 다른 노드들에서도 벌어진다고 하면 캐시 미스의 결과에 따른 엄청난 횟수의 캐시 항목 회수와 네임 서버 검색은 아주 쉽게 상상할 수 있을 것입니다.

고려해야할 또 다른 요인은 이러한 컴퓨팅 팜이 여러 나라 혹은 대륙에 걸쳐서 분산되어 있을 수 있다는 것입니다. 만약 회사의 한 부서가 추가적인 리소스를 필요로 한다면 다른 사이트에서 이것을 빌려 올 수 있습니다. 그리고 NFS mount들 은 WAN 상에서 존재할 것입니다. 아주 최소한의 쓰기 혹은 읽기 작업도 조심하지 않으면 몇번의 접근 체크 작업이 네임 서버 요청을 WAN 을 통과하도록 유발할 수 있습니다. 네임 서버 요청 작업이 증가할 수록 캐시 미스에 대한 NFS 의 응답 시간도 증가 합니다. 결국 클라이언트가 동일한 요청을 다시보내도록 할 수 있고 이것이 캐시 미스를 유발하고 네임 서버와의 통신을 재시작 시킬 수 있습니다.

솔라리스ZFS 와 NFS export 의 증가

인증 캐시는 솔라리스에 10년 이상 존재해 왔으며 썬은 부팅시에 share 들을 메모리에 올리거나 컴퓨팅 팜에서의 캐시 미스에 대해 불평 받은 적이 없습니다. 분명 확장성 이슈가 존재 할때 캐시는 큰 도움을 줍니다. 그러나 이제 유저들은 부트 타임에 대해 불평을 하기 시작했습니다. 무엇이 변화되었을까요? 답은 바로 썬이 오픈솔라리스와 솔라리스10 부터 솔라리스 ZFS 를 적재하기 시작했기 때문입니다.

왜 이것이 문제 일까요? 솔라리스는 export 의 하위 노드 까지 공유 되는 것을 금지하는 속성을 가지고 있습니다. 그러므로 다수의 share 를 가지기 위해서 사용자는 다수의 파일 시스템 혹은 다수의 상위레벨 디렉토리들이 필요 합니다. 여러분은 루트 파일 시스템을 공유 하거나 혹은 디렉토리 구조에 따라 export 를 조직할 수 있습니다. 무슨 이유에서든지 간에 이러한 접근은 환영받지 못합니다. 그리고 서버들이 일반적으로 소수의 파일 시스템을 가지고 있기 때문에 share 의 전체 갯수는 매우 작습니다.

솔라리스ZFS 의 배치에서 ZFS 스토리지 풀은 공유되지 않습니다. 그러나 개별 ZFS 데이타 셋은 공유가 가능합니다. 그리고 ZFS 를 테스트하는 가장 간단한 방법은 파일 서버의 홈 디렉토리로 사용하는 것입니다. 썬 엔지니어링 팀은 한 회사의 프로덕션 환경 파일 서버에서 이것을 해본 경험이 있습니다. 솔라리스 ZFS 가 파일 서버에 인스톨되기 전까지 그 서버는 약 12 개의 export 를 가지고 있었습니다. 홈디렉토리가 ZFS 로 마이그레이션 되기 한주 전에 서버는 약 300 개의 export 를 가지고 있었습니다. 마이그레이션 바로 이후에는 약 1300 개의 export 를 가지게 되었습니다. 현재는 약 1500 개의 export 를 가지고 있습니다.

그리고 썬 ZFS 팀은 부트 타임에 share 로딩에서 심각한 영향이 있음을 발견하기 시작했습니다. 이전에 언급한대로 초기 디자인은 약 10 개의 export 를 다루도록 만들어졌었습니다. -- 10년 전에 디자인된 것이였지만 -- 이것은 1500 export 에서 확장이 잘 되지 않았습니다. 또한 썬은 15,000 export 를 가지게 될 고객의 리포트도 받았습니다.

다음 섹션은 파일 서버에서 무슨 일이 벌어지고 있는지 상세히 분석하고 썬 ZFS 팀이 share 의 로딩 문제를 해결하기 위해서 했던 수정 작업들에 대해 설명합니다. 이 수정 작업에는 인증 체크 시의 캐시 미스 저하에 대한 긍정적인 영향을 포함 하고 있습니다.

커널 내의 Sharetab

큰 이슈는 바로 /etc/dfs/sharetab 파일로 디스크에 존재하는 sharetab(4) 의 내용이었습니다. 커널은 export 의 리스트를 메모리에 가지고 있었습니다. 그러나 옵션은 디스크에 존재했습니다. 그러므로 매번 호스트 접근 리스트가 체크될때 마다 mountd 는 /etc/dfs/sharetab 을 로딩하고 요청에 맞는 경로를 찾을때 까지 모든 항목을 처리하고 그 이후에 옵션을 처리 했습니다. 여러분이 한번 512 개의 노드가 동시에 작업을 시작하고, automounter 가 다수의 share 를 마운트 한다고 상상해 봅시다. 비록 sharetab 파일이 기본적으로 메모리에 페이지인 되더라도 이러한 과정은 여전히 고통 스럽습니다.

솔라리스 ZFS 에 의한 영향을 줄이기 위한 가장 첫번째 시도는mountd 내의 sharetab 에 대한 userland 캐시 였습니다. 왜냐하면 /etc/dfs/sharetab 은 읽기-전용 이어야 했고 -- 사실 실제로는 아니였음 -- 커널은 새로운 share 를 추가하지 않았기 때문에 이것은 해볼만한 임시방편이였습니다. 그러나 이것이 인증 캐시 미스의 경우엔 도움이 되었지만 부트 타임에 파일 시스템들을 공유하는데에는 크게 도움이 되지 못했습니다.

여러분이 이 과정을 좀 더 자세히 살펴 보면, /etc/dfs/dfstab 의 각 항목은 순차적으로 처리 되고 /etc/dfs/sharetab 에 순차적으로 추가되기 때문입니다. 솔라리스 ZFS 의 추가, 그리고 이러한 공유 옵션이 dfstab(4) 에 존재하지 않음으로써, 여러분은 ZFS 데이타 셋을 전부 순회해 가면서 export 를 해야 하는 항목을 찾아야 합니다.

간단하게 요약해 보면:

1. sharetab 파일 열기.
2. 다른 어플리케이션이 쓰지 못하도록 이 파일을 잠금.
3. dfstab 파일 열기..
   1. 각각의 share 처리하기.
   2. 결과를 sharetab 파일에 쓰기.
4. dfstab 파일 닫기.
5. 각각의 ZFS 공유 데이타 셋을 순회.
   1. 각각의 share 처리하기.
   2. 결과를 sharetab 파일에 쓰기.
6. sharetab파일 닫기.

위 단계는 실제로 벌어지는 작업들 보다는 훨씬 빠를 것입니다. share 를 쓰는 작업은 자주 발생하는 이벤트는 아니고 또한 시스템이 부팅 된뒤 한참 후에 share(1M) 커맨드에 의해서 발생할 수도 있기 때문입니다. 그리고 좋은 코딩 테크닉은 공통 코드를 재사용 하는 것입니다.

알고리즘이 실제로 각각의 share 를 처리하는 방법은 다음과 같았습니다:

1. dfstab 파일 열기.
   1. 각각의 share 처리하기.
   2. sharetab 파일 열기.
   3. 다른 어플리케이션이 쓰지 못하도록 이 파일을 잠금.
   4. 파일내에 share 가 이미 존재 하고 있는지 검색.
      1. 만약 그렇다면 구버전을 덮어 씀.
      2. 그렇지 않다면 파일의 제일 끝에 share 를 추가.
   5. sharetab 파일 닫기.
2. dfstab 파일 닫기.
3. 각각의 ZFS 공유 데이타 셋을 순회.
   1. 각각의 share 처리하기.
   2. sharetab 파일 열기.
   3. 다른 어플리케이션이 쓰지 못하도록 이 파일을 잠금.
   4. 파일내에 share 가 이미 존재 하고 있는지 검색.
      1. 만약 그렇다면 구버전을 덮어 씀.
      2. 그렇지 않다면 파일의 제일 끝에 share 를 추가

이 작업이 15,000 번 반복되서 여러분의 시스템이 모든 share 들이 로딩될때 까지 NFS 접근이 불가능한 것을 상상해 보시기 바랍니다. 썬 ZFS 팀은 이 시나리오를 벤치마크 했었고 포기해야 했습니다. 덧붙이자면 이글의 마지막 섹션에서 로딩 타임에 대한 숫자들을 보여드릴 것입니다.

ZFS 팀은 이 이슈를 sharetab 을 커널에 저장함으로써 해결했었습니다. 그들은 sharetab 을 그곳에 저장하고 userland 에 저장하지 않았습니다. 왜냐하면 userland 프로그램이 꺼지거나 죽을 가능성이 있기 때문입니다. 또한 범용 sharetab 을 가지고 있는 것이 프로토콜에 얽매이거나 연관 데몬을 가지고 있는 것 보다 훨씬 낳은 디자인이기 때문입니다.

썬 ZFS 팀이 두번째로 선택한 디자인은 sharetab 을 /etc/dfs/sharetab 을 통해서 접근 가능하도록 하는 것이었습니다. 그들은 이 경로에 마운트 되는 새로운 파일 시스템을 만들려고 했었습니다. 이 파일이 읽혀지면 파일의 내용이 곧바로 커널로 읽어 들여 집니다. 추가적으로 팀은 이제 sharetab 을 vi(1). 같은 어플리케이션에 수정이 되지 않도록 강제할 수 있습니다. 그러나 다른 프로세스들이 여전히 파일을 읽을 수 있고 그러므로 변경사항은 이 파일이 변경되었는지 모니터링하고 있는 써드 파티 어플리케이션에 영향을 주지 않을 수 있습니다.

sharetab 을 커널에 위치시킴으로써 팀은 syscall 이 sharemgr(1M) 로 하여금 share 를 추가하거나 삭제할 수 있도록 할 수 있었습니다. 이 글의 이후 섹션에서는 sharemgr(1M) 에 대해 더 자세히 알아볼 것입니다. 새로운 알고리즘은 다음과 같습니다:

1. dfstab 파일 열기.
   1. 각각의 share 처리하기.
   2. 시스템 콜을 이용하여 share 를 커널로 전송하기.
      1. share 경로를 해싱하여 링크드 리스트 얻기.
      2. 복사본을 검색한 후에 삭제하기.
      3. share 를 리스트의 제일 끝에 추가하기.
2. dfstab 파일 닫기.
3. 각각의 ZFS 공유 데이타 셋을 순회.
   1. 각각의 share 처리하기.
   2. 시스템 콜을 이용하여 share 를 커널로 전송하기.
      1. share 경로를 해싱하여 링크드 리스트 얻기.
      2. 복사본을 검색한 후에 삭제하기.
      3. share 를 리스트의 제일 끝에 추가하기.

syscall 의 비용은 sharetab 을 열고 쓰기 락을 얻고, 디스크에서 읽고, 선형 검색을 하고, 디스크에 쓰고 파일을 닫는 것 보다 훨씬 저렴합니다. 절약한 비용은 이 글의 마지막 섹션에서 보여 드릴 것입니다.

Share Manager

썬 ZFS 팀은 또한 share 들을 프로토콜에 관계 없이 커맨드라인 인터페이스(CLI) 를 이용해서 관리 할 수 있기를 원했습니다. 그들은 관리를 스크립트화 하고 또한 이러한 솔루션을 플러그-인 모듈을 통해 가능하게 되기를 원했습니다. 팀은 이 모든 것을 위해 sharemgr(1M) 를 소개했습니다. Connectathon 의 또 다른 프리젠테이션 The Management of Shares (PDF) 에서는 sharemgr 커맨드의 훌륭한 소개를 제공 합니다.

그러나 팀은 또한 share 를 로딩하는데에 있어서 병렬화가 되기를 원했습니다. 기억하시는대로 기본적인 알고리즘은 순차적입니다. 왜냐하면 여러분은 dfstab(4) 을 로딩하거나 솔라리스 ZFS 데이타 셋을 순회하기 때문입니다. sharemgr 는 share 그룹을 소개 했는데 이것은 share 의 명명된 집합으로써 각각은 솔라리스 관리 설비(SMF) 의 서비스 인스턴스와 연관 됩니다. 각각의 공유 그룹은 이제 고유의 쓰레드에 의해 처리될 수 있고 그러므로 그들은 병렬로 로딩될 수 있습니다. 덧붙여서 sharemgr 는 인-커널 sharetab 이전 부터 제공되었으므로 공유 그룹은 병렬로 실행되지 않을 수 있습니다. 왜냐하면 sharetab(1M) 의 쓰기 락이 병목현상이 될 수 있기 때문입니다.

sharemgr 는 또한 몇가지 이슈들을 완화 시켰습니다. 예를 들어 unshareall(1M) 스크립트는 sharetab(1M) 를 순회하여 share(1M) 를 호출하여 share 들을 삭제 하는데에 사용 됩니다. sharemgr 의 추가로 인해 sharetab 을 순회하고 각각의 share 마다 호출 하는 작업들이 제거 되었습니다. 대신 sharemgr 에 단일 호출로 가능 합니다.

sharemgr 에 대한 단일 호출은 또한 솔라리스 ZFS 코드의 export 를 공유 하거나 공유 해제 하는 방법에도 적용되었습니다. ZFS 데이타 셋을 순회 하는 것 대신에 각각마다 popen(3C) 함수를 호출해서 share(1M) 를 호출 하는 것 대신에 sharemgr(1M) 가 한번 호출 됩니다. popen 이 너무 느린 가장 큰 이유는 각각의 share 와 unshare 작업마다 대용량의 설정 데이타를 각각의 share 에 필요한 데이타 까지 같이 가져와야 했기 때문입니다.

두번째 퍼포먼스 향상은 sharemgr 라이브러리 인터페이스를 zfs(1M) 커맨드내에서 이용하는 것으로 부터 얻어 졌습니다. 이것은 ZFS 데이타셋의 sharenfs 프로퍼티를 설정한 후부터 share 를 활성화 하는데에 사용 되는 popen 호출을 제거 하였습니다.

몇가지 실제 데이타


sharemgr 와 인-커널 sharetab 변경이 솔라리스 ZFS share 의 로딩과 언로딩시에 어떻게 영향을 주었을까요? 썬 ZFS 팀은 share 의 갯수에 따른 몇가지 테스트를 진행했고 시, 분, 초 단위의 결과를 얻었습니다. 표 1 은 결과를 H:MM:SS 형태로 보여주고 있습니다. 팀은 zfs set sharenfs=on 를 이용해서 "On" 테스트를 수행 했고 zfs set sharenfs=off 를 이용해서 "Off" 테스트를 진행함으로써 ZFS 프로퍼티 상속을 통해 share 가 활성화 또는 비활성화 되는 것에 따른 영향을 조사 하였습니다. 퍼포먼스의 향상은 popen 호출의 제거를 나타 냅니다.

표 1:

 

접근	100 On	100 Off	2900 On	2900 Off	5000 On	5000 Off	15,150 On	15,150 Off
sharemgr 향상 이전	0:07:35	0:12:23	> 1 주	> 1 주	> 1 주	> 1 주	> 1 주	> 1 주
sharemgr 향상 이후	0:00:07	0:00:13	0:02:55	0:05:40	0:08:41	0:33:24	1:06:36	2:35:36
sharemgr 와 인-커널 sharetab 사용	0:00:0.7	0:00:0.4	0:00:54	0:03:39	0:02:37	0:12:08	0:19:40	2:12:14

 

기본 케이스에서 썬 ZFS 팀은 일주일 간에 의 처리 시간이 지난후에 100 개이상의 share 에 대한 테스트를 포기하였습니다. 테스트는 오직 2900 개의 케이스에서만 완료 되었고 이후의 설정으로는 테스트를 시도해 보지 않았습니다. 여러분은 sharemgr 와 인-커널 sharetab 접근을 이용해서 share 의 로딩과 언로딩 시에 엄청난 퍼포먼스 향상을 보실 수 있습니다. 팀은 특히 로딩 케이스에 주목했는데 share 를 활성화 했을때에 주목했습니다. 왜냐하면 이것이 바로 NFS 서버의 병목현상을 유발하기 때문입니다. 비록 캐시의 검색 미스를 확인해 볼 수도 있었지만 여전히 향상효과를 보았을 것이라고 생각하고 넘어 갔습니다. 모든 경우에 share 의 시작 혹은 종료는 순차적으로 진행 되었습니다.

아직 까지 더 향상할 곳이 남아 있습니다. 흥미로운 테스트는 15,000 개 이상의 share 를 로드하고 하나의 share 가 로딩 되고 언로딩 되는데 얼마나 시간이 걸리는지를 체크하는 것일 것입니다. Doug McCallum 이 그의 블로그 글 Recent Performance Improvement in ZFS Handling of Shares 에서 적었듯이 이 것은 NFS 와 솔라리스 ZFS 에 대해 배우길 원하는 사람들에게 훌륭한 오픈솔라리스 프로젝트 가 될 것입니다.

이 글은 확장성이 어떻게 퍼포먼스에 영향을 미치는지에 대한 흥미로운 점들을 소개하였고 썬 ZFS 팀이 어떻게 문제 해결에 대해 접근했는지에 대한 소개도 제공해 드렸습니다.

참고자료

Multiple Flavors per Export (PDF), Brent Callaghan, Connectathon 1995, Mar. 13, 1995
NFS Client Authentication (PDF), Brent Callaghan, Connectathon 1996, Feb. 27, 1996
Scaling NFS Services (PDF), Tom Haynes, Connectathon 2006, Mar. 2, 2006
The Management of Shares (PDF), Tom Haynes and Doug McCallum, Connectathon 2007, Feb. 5, 2007
Recent Performance Improvement in ZFS Handling of Shares, Doug McCallum's Share Manager Weblog, May 8, 2007
Download: OpenSolaris OS man pages in tar format

저자에 관하여

Tom Haynes 는 썬 마이크로시스템즈의 NFS 개발자이고 export 의 관리에 관한 확장성 이슈에 관심이 많습니다.

Doug McCallum 은 썬 마이크로시스템즈의 NFS 개발자로 파일 공유에 대한 관리 이슈에 관심이 많습니다.


이 글의 영문 원본은
The Management of NFS Performance With Solaris ZFS
에서 보실 수 있습니다.

데이터 관리/Solaris ZFS

1. 솔라리스 10은 현재 데이터 관리 요건을 처리하기 위해 어떤 기능을 제공하나요?

   솔 라리스 10 운영체제는 현재 NFS, UFS(UNIX file system), Solaris Volume Manager 소프트웨어 등의 핵심적인 데이터 관리 기술을 제공하고 있습니다. 앞으로 업데이트될 솔라리스 10에는 Solaris ZFS(zettabyte file system)를 포함시킬 예정입니다.

   • 썬이 개발하고 도입한 NFS(Network File System)은 컴퓨터간의 파일 공유를 위한 업계 최고의 표준이라 할 수 있으며, 솔라리스 10에 포함된 NFS 소프트웨어 v4는 전통적인 파일 액세스에 강력한 보안 기능을 추가하여 인터넷 액세스 및 성능을 향상시키고 플랫폼간의 상호운용성을 강화했습니다.
   • UFS(UNIX File System)은 썬이 범용 솔라리스 소프트웨어 설치를 위해 선택한 통합 파일 시스템으로서 다양한 애플리케이션에 적합하며 개별 프로세스에 의해 무작위로 액세스되는 작고 cacheable한 파일들을 처리하도록 구성되어 있습니다. UFS는 일반적으로 소프트웨어 개발이나 네트워크 서비스와 같은 작업부하를 처리하는데 사용됩니다.
   • Solaris Volume Manager 소프트웨어는 엔터프라이즈급 배치에 적합한 견고한 디스크 및 스토리지 관리 솔루션입니다. 이 솔라리스 기술은 장치에 장애가 발생한 경우에도 지속적인 데이터 액세스를 제공할 수 있는 리던던시 및 페일오버 기능을 통해 스토리지 요소들을 볼륨으로 풀(pool)하여 이를 애플리케이션에 할당하는 데 이용될 수 있습니다. 사용하기 쉬운 인터페이스를 갖추고 있는 이 소프트웨어는 스토리지 관리를 크게 간소화하고 다수의 오퍼레이션-볼륨을 복구하거나 파일 시스템의 크기를 확대하는 등-을 온라인으로 처리하여 값비싼 다운타임의 필요성을 최소화시켜줍니다.
   • 최신의 128비트 파일 시스템인 Solaris ZFS는 자가 치유(solf-healing), 자가 관리(self-managing) 등의 파일 관리 기능을 제공하는 동시에 데이터 손상도 막아줍니다.
2. Solaris ZFS란 무엇이고, 또 언제부터 이용이 가능한가요?

   Solaris ZFS는 솔라리스 10 릴리즈에 포함된 새로운 파일 서비스의 일종으로, 범용 호스트 기반 파일 시스템의 현대적 니즈를 충족하도록 디자인된 썬의 차세대 파일 스토리지 솔루션입니다. Solaris ZFS는 솔라리스 10 업데이트 릴리즈에 포함될 예정입니다.

3. Solaris ZFS가 UFS, SVM(Storage Virtualization Manager), 또는 썬 마이크로시스템즈가 제공하는 Sun StorEdge QFS 및 Sun StorEdge SAM-FS 소프트웨어 제품을 대체하게 되나요?

   Solaris ZFS는 UFS와 SVM 소프트웨어를 대체하도록 디자인되었습니다. 이 Solaris ZFS는 현재의 UFS 및 SVM 제품에 추가로 포함될 예정이며 썬이 제공하는 Sun StorEdge QFS 및 Sun StorEdge SAM-FS 제품 오퍼링을 보완해주는 역할을 할 것입니다.

4. Solaris ZFS의 주요 이점은 무엇인가요?

   Solaris ZFS의 주요 이점은 다음과 같습니다.:

   • 관리의 용이성: 관리 모델 대부분이 자동화되므로 사용하기가 매우 용이합니다.
   • 보안 및 무결성: 항시 데이터의 일관성이 유지되며, 데이터는 64비트 체크섬(checksum)에 의해 보호됩니다.
   • 확장성: Solaris ZFS는 현재의 32비트 및 64비트 파일 시스템보다 160억 배 더 큰 용량을 제공하는 128비트 파일 시스템입니다.
5. Solaris ZFS는 볼륨 매니저를 필요로 하나요?

   아 닙니다. 오늘날 대부분의 파일 시스템의 경우, 하나의 디스크 또는 볼륨만 처리가 가능하기 때문에 볼륨 매니저를 필요로 합니다. 파일 시스템과 볼륨 매니저 간의 인터페이스 때문에 파일 시스템을 늘리고 줄이거나, 공간을 공유하거나, 라이브 데이터를 마이그레이트하기가 힘들어집니다. 반면에 Solaris ZFS는 별도의 볼륨 매니저가 필요 없도록 디자인되었으며, 대신 복수의 파일 시스템이 공유하는 하나의 스토리지 풀 안에 여러 개의 디스크를 담을 수 있습니다. 이렇게 하면 스토리지 풀을 효율적으로 사용할 수 있는데, 예를 들어 풀 내의 파일 시스템을 늘리거나 줄이지 않고도 파일 시스템 간에 획기적으로 공간이 공유되고 모든 파일 시스템이 풀의 최대 쓰루풋을 활용할 수 있게 됩니다.

6. Solaris ZFS에 대한 관리용이성은 어떤가요?

   Solaris ZFS로 스토리지를 관리하기란 너무나도 쉽습니다. Solaris ZFS의 강력한 디자인은 수많은 복잡한 스토리지 관리 개념의 틀을 완전히 깨버립니다. 실례로, 스토리지 풀 내의 공간이 풀의 파일 시스템에 획기적으로 할당되므로 스토리지를 슬라이스, 볼륨, 파일 시스템 등으로 정적 분할할 필요가 없습니다. Solaris ZFS의 on-disk 구조는 항시 일관성을 유지하므로, 비정상적인 종료 시에도 파일 시스템 검사가 필요치 않습니다(또한 파일 시스템의 일관성을 유지하기 위해 로그를 플레이하지 않아도 됩니다). Solaris ZFS에 대한 명령어 라인 인터페이스는 관리자가 각자의 의도를 직접적으로 표현할 수 있도록 해주므로 암호화된 명령어를 외우거나 찾아볼 필요가 없습니다.

7. Solaris ZFS는 얼마나 신뢰할 수 있나요?

   Solaris ZFS는 copy-on-write 파일 시스템이며, 따라서 Solaris ZFS의 on-disk 구조는 항상 일관성을 유지하게 됩니다. 시스템이 비정상적으로 종료되더라도 재부팅 시에 Solaris ZFS의 일관성을 유지하기 위한 복구 조치(가령 fsck 실행)도 필요치 않습니다. 모든 오퍼레이션은 트랜잭셔널하므로 관련된 변경사항은 전적으로 성공하거나 실패하게 되며, 모든 데이터는 64비트 체크섬에 의해 보호됩니다. 또한, 데이터가 읽히면 애플리케이션이 기록한 데이터를 확실하게 돌려받을 수 있도록 체크섬 확인 작업이 수행됩니다. 이 외에도 미러된(mirrored) 풀에서 체크섬 오류가 탐지되면 미러의 다른 쪽에서 정상 데이터를 읽어들이고 손상된 데이터는 수정됩니다.

8. Solaris ZFS가 지원하는 스토리지 규모는 얼마나 되나요?

   Solaris ZFS는 128비트 주소 공간을 사용합니다. 이는 현재 UFS에서 지원되는 것보다 160억 배 이상 큰 파일 시스템을 지원할 수 있음을 의미합니다.

9. Solaris ZFS를 활용하려면 애플리케이션을 바꾸어야 하나요?

   Solaris ZFS는 POSIX(Portable Operating System Interface) 파일 시스템 인터페이스를 지원하므로 애플리케이션을 변경할 필요가 없습니다.

10. Solaris ZFS는 Sun Cluster 소프트웨어와 호환이 되나요?

    그 렇습니다. 물론 처음부터 글로벌 파일 시스템이었던 것은 아니지만, Solaris ZFS는 클러스터 내의 모든 노드 상에서 로컬 파일 시스템으로 작동하게 됩니다. 즉, Solaris ZFS를 실행할 것인지 Sun Cluster 소프트웨어를 실행할 것인지 고민할 필요가 없는 것입니다.

11. Sun Cluster 소프트웨어와 솔라리스 10 운영체제에 관해 더 자세히 알고 싶습니다.

    Sun Cluster 제품 사이트를 방문하시면 자세한 내용을 살펴보실 수 있습니다.

12. Solaris ZFS는 새로운 DTrace 기능과 호환이 되나요?

    그렇습니다. Dtrace와 Solaris ZFS는 완벽하게 호환이 됩니다. 솔라리스 개발자는 DTrace를 디버깅 툴로 사용할 수도 있고 성능 향상을 위한 보조물로 사용할 수도 있습니다.

13. Solaris ZFS는 솔라리스 9 릴리즈 또는 Linux 같은 다른 운영체제에 포팅이 되나요?

    현재로서는 Solaris ZFS를 초기 버전의 솔라리스나 다른 운영체제로 포팅할 계획이 없습니다.