System Compleat.

'Parallel File Share'에 해당되는 글 1건

  1. pNFS on Nexenta

pNFS on Nexenta

Techs
( younjin.jeong@gmail.com , 정윤진 )


파일 시스템의 클러스터링에 대해서는 이미 이슈화 된지 몇년이 지난 상태여서 본 내용에 대해서 이미 확인해 보거나 BMT 까지 수행 해 보신 분들도 많으시겠지만, 간략한 소개의 의미 및 nexenta.org 의 관련 내용 번역으로 간략히 포스팅 하고자 한다. pNFS 를 Nexenta 에서 서비스로 사용하는데에는 다소 신중함이 필요 하겠지만, VM 에서 여러대의 Nexenta 를 올려두고 간단히 테스트 하여 성능을 비교하는 재미는 쏠쏠하지 않겠는가.


pNFS 에서의 p 의 의미는, Parallel 이다. 전통적인 NFS v4에서 지원하는 단일 서버 - 클라이언트 서버 간의 Data 와 Meta Data 통신을 구분하여 병렬로 나누어 놓았다고 생각하면 이상적이라 할 수 있겠다.
클러스터 파일 시스템은 굉장히 여러가지 종류가 있고 구현 방법에 따라 설치가능한 패키지들이 있겠지만, 전통적으로 사용되는 NFS 에 대한 병렬 확장은 이미 2005년 경 부터 각 벤더 ( ex. EMC, IBM, NetApp ) 에 의해 연구되어 왔고, 종래에 와서 File 기반 서비스에 대해서는 어느정도 사용 할 만한 규모가 되었다 생각 한다.
물론 Block Level 의 클러스터FS 에 대해서는 여기서는 논외로 하고.

일단 본 포스팅에서 소개하고자 하는 내용은 Nexexta 에서의 pNFS 구현이며, 이 내용은 nexenta.org 의 wiki 내용 중 일부를 번역 한 것이며, 한글을 읽는데 불편함을 느끼시거나 원문을 직접 보고싶은 분들 께서는
http://www.nexenta.org/projects/6/wiki/PNFS?version=37 에서 내용을 참조 하시면 되겠다.

소개 ( 본 내용의 날짜는 2010년 01월 24일에 포스팅 된 wiki 를 근거로 한다 )
병렬 NFS ( pNFS )는 NFS v4.1 표준에 포함된, 클라이언트가 스토리지에 병렬로 직접 엑세스 하는 방법을 다루고 있다.
pNFS 는 오늘날 사용되고 있는 NFS의 확장성 및 성능상의 이슈를 해결하기 위하여 대두된 구조로서, 기본적인 아이디어는 데이터와 메타데이터를 분리하는 것이며, 이는 아래의 그림과 같이 전통적인 NFS 와 pNFS가 어떻게 다른지 설명 될 수 있다. ( 이미지는 pNFS 위키페이지의 것을 성능상의 이유로 본 블로그에 사진으로 첨부한다. )

Traditional NFS




How pNFS works.



차이점을 설명하면,

1. pNFS는 클라이언트들이 데이터 서버에 직접 엑세스가 가능하도록 하고 있다.
2. 데이터는 데이터 서버들 사이에서 분리되어 저장이 가능하다.
3. 데이터에 대한 엑세스는 메타 데이터 서버들을 통해 하위 호환성을 유지한다.

이로 인한 잇점은,

1. 고성능 : 확장 가능한 여러대의 서버로 파일을 분산함으로서 성능 및 확장을 노릴 수 있다.
2. 수평적 확장 :  단일 NFS 를 사용함으로서 발생 할 수 있는 제한에서 자유로울 수 있다.
3. 데이터와 메타데이터의 분리 :  데이터에 대한 변경 ( 생성, 추가, 삭제 기타 등 ) 은 메타데이터 서버에서 유지한다.
4. 전통적 NFS서버의 사용성을 유지한다.
5. 전통적 NFS서버와 같은 방법으로 마운트 할 수 있다.

#mount server:/path /mnt


pNFS on Nexenta

현재 pNFS 의 기능은 on-gate b121 에 기초하고 있으며, 이는 NCP 에서 컴파일/빌드 되었으며, 동작한다.
pNFS 에 관한 보다 많은 정보, 바이너리 및 소스와 컴파일러 셋( sun studio and other tool set )은 다음의 링크에서 다운로드 가능하다.  [pnfs-project] http://hub.opensolaris.org/bin/view/Project+nfsv41/downloads


Nexenta Core 시스템에서의 pNFS 셋업

pNFS 를 위한 3가지의 주요 설정 항목이 있다.  클라이언, 메타데이터 서버 ( MDS ) , 데이터 서버 ( DS )

현재, DS와 MDS는 반드시 별도의 머신에 설치 되어야 한다. 기본적으로 NCP - pNFS 설정을 위해서는 3 개의 머신을 추천한다.  한대는 클라이언트, 한대는 메타데이터 서버, 마지막 한대는 데이터 서버.
지금까지 설명 된 내용을 구동하기 위한 설정은 아래를 참고 한다.


메타 데이터 서버 설정 ( MDS )

공유 path 생성

#share [pathname]


데이터 서버 생성 ( DS)

파일 시스템 공유 설정

#sharemgr create -P nfs p-group
#sharemgr add-share -s /export p-group

NOTE: 본 단계에서 사용하는 파일 시스템은 임시적으로 사용하는 것이다. 데이터 서버는 지정한 파일 시스템을 사용하지 않는다. 데이터 서버의 SMF 서비스 ( svc:/network/dserv:default ) 는 NFS 서버의 SMF 서비스 ( svc:/network/nfs/server:default) 에 의존적이다.  파일 시스템의 공유는 NFS 서버의 서비스가 활성화 되었으며, 구동중임을 보장한다. ( 즉, NFS 서비스가 올라오면 관련된 서비스가 정상 동작함을 의미 한다는 표현 )

데이터 서버는 dservadm 툴을 사용하여 관리되며, 현재 man 페이지는 제공되고 있지 않으나 --help 옵션은 가능하다.

#dservadm --help

MDS 의 주소를 DS에 등록한다.

1. #dservadm addmds [MDS_IP_ADDR]
2. /etc/hosts 파일에 엔트리로 등록

pNFS 데이터셋 생성

#zpool create ppool /dev/dsk/c1t1d0
#zfs create -t pnfsdata ppool/pdata

NOTE:  데이터 서버에는 적어도 1개의 pNFS 데이터셋이 존재해야 한다. 따라서, 여러개의 인스턴스가 데이터 서버에 존재한다면, 인스턴스별로 반드시 1개 이상의 데이터셋을 생성해야 함을 잊지 말자.

dserv 서비스 시작 및 온라인 체크

#dservadm enable
#svcs dserv
    STATE          STIME        FMRI
    online         20:45:24    svc:/network/dserv:default


클라이언트 설정

MDS를 클라이언트로 마운트.

#mount -F nfs -o vers=4 [mds:/path] [mount_point]


현재 기능상의 문제. ( 이 부분의 번역은 다소 오류가 있을 수 있어 원문을 함께 첨부합니다. 오류 없으시길 )

클라이언트로 부터 파일이나 디렉토리가 제거될 때 주요한 병목이 발생하고 있다.
The major bottleneck is the fact that currently even though the files and directories are deleted from the client.. the dataset that is created on the withholding pool does not show any reduction in size.. This mean, only the namespace is being deleted from the client and mds.. Thus over a period of time the data server will run fill up and the only solution is to delete the entire zpool.
이에 대한 내용은 링크를 참조.

http://hub.opensolaris.org/bin/view/Project+nfsv41/
Project gate::
ssh://anon@hg.opensolaris.org/hg/nfsv41/nfs41-gate
Project logistics::
http://hub.opensolaris.org/bin/view/Project+nfsv41/projectlogistics


도움 요청은  IRC.frenoode.net 의 nexenta 채널로.
메일링 리스트는  gnu-sol-discuss@opensolaris.org



조금만 더 살펴보면, 이 pNFS 는 다양한 방법으로 각 스토리지 벤더에서 지원하고 있다. 이중 여기서 소개된 nexenta 의 opensolaris 진영에서도 infiniband 와 같은 고속 통신을 사용하여 pNFS over RDMA 와 같은 방법으로 구현하는 것도 있다.  물론 NetApp 의 OnTAP 에서도 그들의 독자적인 방법으로 기능을 제공한다.

주요한 것은 어떠한 파일 시스템을 사용하던, 이제는 데이터가 페타 또는 그이상의 크기를 필요로 하는 곳이 많아지게 되므로, 이와같은 병렬화된 파일레벨의 공유시스템 및 이를 사용했을때 발생하는 성능상의 이슈를 어떠한 방식의 캐싱으로 풀어나갈 것인가, 어디에 적용해야 할 것인가 등이 주요한 고민으로 작용 할 것 같다.

언제나 고민되는 스토리지다. 

각 벤더의 링크들.
http://www.panasas.com/products/pnfs-resource-center.php
http://www.netapp.com/kr/communities/tech-ontap/pnfs-ko.html
http://www.almaden.ibm.com/storagesystems/projects/pnfs/


( younjin.jeong@gmail.com , 정윤진 )


+ 요것은 초큼 다른 내용이지만, MPI-IO 관련 내용.
http://www.mcs.anl.gov/~thakur/papers/mpi-io-noncontig.pdf