수안이의 컴퓨터 연구실

데이터 문제에 대한 차세대 NFS 계열 파일 시스템 대안
난이도 : 초급


Frank Pohlmann
U.K. Technical 편집자 및 개발자, LinuxUser and Developer
2005년 5 월 17 일

분산 파일 시스템은 최근까지 많은 이슈는 없었다. 이를 사용하는 것이 대개는 기업과 교육 네트워크이기 때문이다. 시스템이 오픈 소스 파일 시스템 퍼즐에 어떻게 맞는지는 개념상으로 언제나 명확한 것은 아니다. Open Andrew File System (OpenAFS)은 Network File System (NFS)의 성숙한 대안이다.
사용자들은 파일 시스템의 개념을 두 가지 방식으로 이해한다. 첫 번째는 파일과, 그 파일을 포함하고 있는 디렉토리, 그리고 디렉토리 구조를 보유한 파티션으로 구성하는 방식이다. 그리고 두 번째는, 파일 시스템은 파일들이 미가공 금속으로 조직화 또는 매핑되는 방식이다. 원래는 가상 파일 시스템(VFS) 레이어와 실제 메모리 관리 루틴 처럼 중간에 존재하는 레이어이지만 사용자가 접근할 수 있는 구조화된 정보를 관리하는 것과 관련해서는 파워 유저가 파일 시스템 내부를 들여다 보고 커널의 후미진 곳 까지 파악하도록 하는 것이 이치에 맞는다.

메탈은 RAM 또는 하드 디스크로 구성되지만, 어떤 경우에는 파일 시스템 데이터 구조는 하드웨어 제조자들이 만든 섹터와 바이트로 구성된다. 보다 원시적인 경우는, 사용자들이 스스로 개념상 이를 쪼갤 수도 있다. 큰 사이즈의 파일에 액세스 할 때 속도를 높일 수 있는 툴도 있다. 또한 디렉토리와 파일을 재구성할 수 있는 툴도 있는데 이 툴들은 비트, 바이트, 섹터로부터 안전하다.

파일 시스템 개념
이러한 개념적 정의의 고전적인 경우는 FreeBSD—유닉스의 BSD—가 UNIX File System V2 (UFS2)를 사용하여 디스크 상의 데이터를 구성하고, Flash File System (FFS)을 사용하여 파일을 디렉토리로 구성하고 디렉토리 액세스를 최적화하던 방식이다. 리눅스는 원래 두개 이상의 파일 시스템 보다 더 많은 것을 허용하기 때문에 약간 다르게 작동한다. 따라서 VFS 레이어에서는 리눅스 사용자가 리눅스가 메모리를 관리하는 방식에 구애 받지 않고 새로운 파일 시스템 지원을 추가할 수 있다.

정적 그리고 저널 파일 시스템에 대서 나중에 이야기 할 때, 영속성과 더 나아가서 파일 시스템 콘텐츠의 보안에 대해 강조할 것이다. BSD UNIX 관점에서 보면 정적 저널 파일 시스템들은 UNIX File System (UFS)이 파일을 구성하고 보안화 하는 방식과 관련이 있다. 비록 리눅스 파일 시스템들이 Journal File System (JFS), 차세대 파일 시스템 (XFS), 초기 ReiserFS들을 사용할 수 있을 때부터 저널 파일 시스템들을 포함하긴 했지만 기술적 저널리즘 이나 기업 공공성이 빛을 발하지 않은 또 다른 영역은 분산 파일 시스템이다.

NFS에서 내가 배운 것
대규모의 사용자들에게 TCP 또는 User Datagram Protocol (UDP)을 통해 사용할 수 있는 네트워크 중심의 파일 시스템 레이어를 만드는 것은 신중하지 못한 것처럼 보인다. pre-V3 NFS 관련 공포 시나리오는 10명 남짓의 사용자들로 네트워크를 관리하는 많은 관리자들을 고생시킨다. 게다가 매우 빠른 마더보드 아키텍쳐로 지원되는 다중 프로세서 아키텍쳐의 출현은 분산 파일 시스템 문제를 우선순위 밖으로 밀어낸다. 속도는 지능적으로 구현된 분산 시스템들이 아닌 하드웨어로 보장된다. 분산 파일 시스템들이 기저의 파일 시스템 구현- ext2, ext3, ReiserFS 파일 시스템 드라이버-들에 의존한다면 분산 파일 시스템들은 큰 대학 네트워크와 과학 또는 기업 네트워크로 제한될 것이다.

그렇다면 분산 파일 시스템은 우리가 언급했던 두 개 중 상단에 있는 제 3의 레이어인가? 현대 네트워킹의 큰 문제 중 하나는 이종의 네트워크를 결합해야 한다는 점이다. (Samba가 대표적인 예이다.) 하지만 파일 시스템 퍼즐에 세 개의 주요한 플레이어가 있다는 것을 이해해야 한다: Microsoft® Windows® 파일 시스템 군 (FAT16, FAT32, NTFS 파일 시스템); Apple Mac OS X (HFS+); 그리고 원시 리눅스 저널 파일 시스템(대게ReiserFS와 ext3). Samba는 Windows와 리눅스 파일 시스템의 협업을 돕지만 모든 주요 파일 시스템에 접근하여 관리할 수 있다는 것을 의미하지는 않는다.

어떤 사람들은 NFS V4를 이 문제를 해결 때 시도하지만 NFS V4를 다루는 Request for Comments (RFC) 3530은 아직 2년 밖에 되지 않았고, 2.6 커널용 NFS V4도 너무 어리기 때문에 제품 서버에 쓸 것을 권하기가 망설여진다. Fedora cores 2와 3은 NFS V4 패치와 NFS V4 유틸리티를 제공한다. 이것은 NFS가 더 많은 포트를 열고 사용자들에게 반출된 각 네임스페이스에 개별 클라이언트를 설정하는 것으로 네트워크 관리자들을 애를 먹인 이후로 개발자가 만들어 낸 현상이다. RFC 3530은 대부분 보안 문제만 언급한다. 아직도 NFS 디렉토리는 개별적으로 마운트되어야 한다. 통합 sign-on과 Kerberos를 사용하여 보안화 할 수 있지만 손질이 필요하다.

OpenAFS 논거
OpenAFS는 소프트웨어의 설치와 관리 고통을 제거한다. OpenAFS는 다른 파일 시스템들 끼리 효율적으로 협업하도록 돕는다. 비록 유닉스용 원래의 메타포와 이것의 매력적인 후계자 Plan 9는 파일이었지만 현대의 네트워크로 된 파일 시스템들을 완전히 다시 만들기 보다는 또 다른 분산 파일 시스템 레이어가 추가되었어야 했다.

카네기 멜론 대학교 프로그래머들은 1983년에 AFS를 개발했다. 그 뒤 바로, 이 대학은 Transarc라는 회사를 설립하여 AFS 기반 서비스를 팔았다. IBM은 1998년에 Transarc를 인수하여 AFS를 OpenAFS란 이름으로 오픈 소스 제품으로서 사용할 수 있도록 했다. 하지만 OpenAFS가 Coda와 Arla 같은 다른 분산 파일 시스템들을 만들어냈기 때문에 무용담은 여기가 끝이 아니다. OS 클라이언트들이 존재했고 문서도 충분하다. Gentoo.org는 OpenAFS에 노력을 기울여 리눅스 사용자들도 접근할 수 있도록 했다. 다른 조직들은 여전히 분산 파일 시스템이 필요할 때 NFS를 거론한다.

OpenAFS 아키텍쳐
OpenAFS는 셀로 알려진 파일 서버 그룹 주위에 조직된다. 각 서버의 아이디는 보통 파일 시스템 뒤에 숨겨진다. AFS 클라이언트의 형태로 로그인하는 사용자들은 어떤 서버에서 작업하고 있는지 말할 수 없다. 사용자 관점에서 보면 인식 가능한 유닉스 파일 시스템으로 하나의 시스템 상에서 작업하는 것이기 때문이다. 파일 시스템 콘텐트는 셀을 통해 복제되어 하드 디스크가 오류가 생긴다고 해서 OpenAFS의 클라이언트 작업에 지장을 주지 않는다. OpenAFS는 1 GB 정도의 클라이언트 캐싱 장치를 통해 자주 사용되는 파일에 접근할 수 있어야 한다. 이것 역시 완전히 보안화 된 Kerberos 기반 시스템으로서 작동한다. 이는 액세스 제어 리스트(ACL)을 사용하여 보통의 리눅스 및 유닉스 보안 모델 기반이 아닌 정교한 액세스를 가능하게 만든다.

기저 파일 시스템으로 ext2를 실행하는 OpenAFS의 일부가 되는 캐시 매니저를 제외하고 OpenAFS의 기본적인 구조는 요즘의 NFS 구현을 닮았다. 기본 아키텍쳐는 전혀 같아 보이지 않는다. NFS를 더 선호하는 사람들에겐 OpenAFS 장치를 활용하는 것이 더 좋지만 소위 NFS/AFS 트랜슬레이터를 사용할 수 있다. OpenAFS 클라이언트 머신이 NFS 서버 머신으로 설정되는 한 두 파일 시스템의 장점을 활용할 수 있어야 한다.

OpenAFS 방식
NFS는 위치 독립적이고 로컬 디렉토리들을 원격 파일 시스템 위치로 매핑한다. OpenAFS는 사용자들에게 파일 위치를 숨긴다. 모든 소스 파일들은 다양한 복제된 파일 서버 위치에 읽기-쓰기 카피로 저장되기 때문에 복제된 카피를 동시에 갖게 된다. Ubik이라고 하는 기술을 통해 이것이 가능하다. 동부 유럽과 유비쿼터스에서 사용한다. Ubik 프로세스는 AFS 파일 시스템 상에서 파일, 디렉토리, 볼륨을 동시에 관리하지만 세 개 이상의 파일 서버를 가진 시스템들이 효과를 볼 수 있다. 시스템 관리자는 여러 AFS 셀들을 그룹핑할 수 있다. 오래된 AFS는 OpenAFS 파일 시스템에 보관된다. 관리자는 AFS 셀의 양과 셀이 저장할 수 있는 한계와 그 사이트 내에 AFS 셀에서 사용할 수 있는 파일들을 결정해야 한다.

파티션, 볼륨, 디렉토리
AFS 관리자들은 셀을 볼륨으로 나눈다. 볼륨은 하드 디스크 파티션으로 확장가능하지만 대부분의 관리자들은 한 개의 볼륨으로 전체 파티션을 채우지는 않는다. AFS 볼륨은 실제로 Volume Manager 라고 하는 유닉스 유형의 프로세스로 관리된다. 유닉스 파일 시스템 디렉토리와 비슷한 방식으로 볼륨을 마운트 할 수 있다. 하지만 AFS 볼륨을 파일 서버에서 파일 서버로 옮길 수 있다. 하지만 유닉스 디렉토리는 파티션에서 파티션으로 물리적 이동이 불가능하다. AFS는 Volume Location Manager를 통해 볼륨과 디렉토리 위치를 자동으로 트래킹하고 복제된 볼륨과 파일을 계속 트래킹한다. 따라서 사용자는 파일 서버가 예상치 못하게 작동을 멈출 때 걱정하지 않아도 된다. AFS가 사용자를 다른 파일 서버 머신 상의 복제된 볼륨으로 변환하기 때문이다. 사용자는 이를 인식하지 못한다.

사용자들은 AFS 서버상에 위치한 파일에 대해 절대 작업하지 않는다. 클라이언트 측 캐시 매니저에 의해 파일 서버에 붙은 파일에 대해 작업한다. Cache Manager는 클라이언트 운영 체계 커널에 살아있는 재미있는 동물이다. 리눅스의 경우 패치가 커널에 추가된다. (2.4 커널에서 Cache Manager를 실행할 수 있다.)

Cache Manager
Cache Manager는 로컬 애플리케이션의 요청에 응답하여 AFS 파일 시스템을 통해 파일을 붙일 수 있다. 물론 파일이 종종 바꾸게 되는 소스 파일 이라면 여러 복제된 버전으로 존재하는 것은 이상적이지 못하다. 사용자는 빈번히 요청되는 소스 파일을 자주 변경할 수 있기 때문에 두 가지의 문제가 생긴다: 첫째, 파일은 클라이언트 캐시와 여러 파일 서버 머신 상의 여러 복제된 볼륨에 저장된다; 둘째, Cache Manager는 모든 볼륨을 업데이트 해야 한다. 파일 서버 프로세스는 콜백을 붙여 파일을 클라이언트 캐시로 보내서 시스템이 어딘가에서 일어난 모든 변경들을 처리할 수 있도록 한다. 사용자가 어딘가에서 캐시 된 복제된 파일에 변경을 추가하면 원래 파일 서버는 콜백을 활성화하고 원래 캐시 된 버전에 업데이트가 필요함을 상기시킨다.

분산 버전의 제어 시스템은 이러한 고전적인 문제에 직면해 있지만 중요한 차이가 있다: 분산 버전 제어 시스템은 연결이 해제될 때 완벽히 작동하지만 AFS는 파일 시스템의 일부를 잘라낼 수 없다. 개별 AFS 섹션은 원래 파일 시스템과 재연결 할 수 없다. 파일 서버는 오류가 여전히 실행중인 AFS 파일 서버로 다시 연결되도록 처리하지만 잘려나간 후에 로컬에서 보유하고 잇는 새로운 변경을 추가할 수 없다.

OpenAFS 대안
AFS는 새로운 파일 시스템에 대한 여러 시도의 출발점이다. 원래의 분산 파일 시스템 아키텍쳐에서 배운 교훈들을 두 개의 시스템들이 결합했다: Coda와 스웨덴의 오픈 소스 자원자들의 노력의 산물인, Arla 이다.

Coda 파일 시스템은 원래 AFS를 향상하려는 첫 번째 시도였다. 1987년에 카네기 멜론 대학에서 개발자들은 AFS를 Coda로 발전시켜 V2.0까지 이르렀다. 1980년대 후반과 90년대 초에 Coda 파일 시스템은 Venus라고 하는 다른 캐시 매니저를 선보였다. Coda의 기본적인 기능은 AFS와 비슷한 반면 Venus는 클라이언트가 분산 파일 시스템에서 연결이 끊어져도 Coda를 실행하는 크라이언트를 위해 계속 작동할 수 있다. Venus는 AFS Cache Manager와 같은 기능을 갖고 있다. 커널 내에 VFS에서 파일 시스템 작업을 가져온다.

Coda 서버들과 Venus 캐시 매니저들간 연결 해제가 네트워크 기능에 결정적인 것은 아니다. 랩톱 클라이언트는 중앙 서버에서 멀리 떨어져 작업할 수 있어야 한다. 따라서 Venus는 클라이언트 변경 로그에 모든 업데이트들을 저장한다. 캐시 매니저가 중앙 서버로 재연결 될 때 시스템은 클라이언트 변경 로그를 재통합하면서 모든 파일 시스템 업데이트들을 클라이언트가 사용할 수 있다.

연결 해제는 또 다른 문제를 만들 수 있지만 Venus 캐시 매니저는 분산된 파일 시스템들이, 연결된 상태로 실행되는 복잡한 네트워크들 보다 훨씬 더 많이 확장될 수 있음을 나타내고 있다.

프로그래머들은 1993년 이후 OpenAFS의 GPLed 구현을 제공하는 스웨덴 프로젝트인 Arla를 개발해왔다. 사실 대부분의 개발과 포트는 1997년 이후에 이루어졌다. XFS 파일 시스템이 Arla가 실행되는 모든 운영 체계에서 작동해야 한다는 것을 제외하고는 Arla는 OpenAFS를 아주 잘 모방했다. Arla는 V0.39까지 나왔고 OpenAFS처럼 모든 BSD에서 실행된다. kernel V2.0x과 Sun Solaris 이후 상당량의 리눅스 커널이다. Arla는 원래 AFS 코드에는 없었던 AFS의 기능을 부분적으로 구현한다. 연결 해제 작동이 바로 그것이다. 하지만 갈 길은 멀고 개발자들은 테스팅도 끝마치지 못했다.

GPLed InterMezzo 같은 기타 AFS 유형의 파일 시스템들도 사용 가능하다. 하지만 이것은 AFS 명령행 문법 또는 아키텍쳐를 복제하지 않았다. 오픈 소스 분산 파일 시스템의 세계는 매우 활동적이고 다른 분산 파일 시스템은 모바일 컴퓨팅에서 실행할 애플리케이션을 모색하고 있다.

http://www-128.ibm.com/developerworks/k ··· dex.html