OpenAFS-Gentoo-HOWTO

OpenAFS-Gentoo-HOWTO

OpenAFS와 관련된 본 문서의 정의

분산 네트워크 파일 시스템인 Andrew File System 의 Implementation 중 OpenAFS 의 설치, 운용에 대한 전반적인 매뉴얼. 이 매뉴얼에서는 GentooLinux 배포판 기준으로, OpenAFS 를 운용하는데 고통없는 가이드를 목적으로 하고 있다.

사이트 :: http://www.openafs.org

이 문서에 대하여

버전 0.23

갱신일 :: 2006년 11월 21일

옮긴일 :: 2013년 3월 17일

저작자 2006 (C) 신종훈 (LunA_J`etch, email : luna.jetch_at_gmail_dot_com)

이 매뉴얼은 Creative Commons ShareAlike-2.5 라이센스에 의한 보호를 받습니다. OpenAFS 는 IBM Public License의 보호를 받습니다.

서버를 구성하기 전에 알아야 할 사항들

대강의 추상적인 서비스 구조는 다음과 같다:

OpenAFS의 추상적인 구조

서비스 하는 측면에서는, 다수의 Replica 를 구성하여 백업/분산의 용도로 확장하기 좋다.

클라이언트 측면에서는, 다수의 볼륨을 일일이 마운트 해 줄 필요 없이, 셀(Cell) 설정 만으로 서버사이드에서 정한 대로 연결된 다수의 물리적 스토리지를 사용할 수 있다.

Cell 은 네트워크 내 구성된 AFS 서비스를 한번에 묶는 이름의 의미로 사용되며, AFS가 인식하는 실제 물리적 파일시스템 공간을 파티션(partition), AFS에서 서비스를 할 때 사용되는 논리적인 파일시스템 공간을 볼륨(Volume) 이라고 부른다.

이 매뉴얼에서 언급하는 시스템 환경에 대하여

OpenAFS 서버를 구성하기 전에, 자신의 네트웍 환경과, 설치할 서버들, 그리고 사용할 클라이언트의 수 등을 고려하여 서버를 구성해야 하는 것은 당연한 일이다.

이 예제에서 보여주는 환경은 다음과 같다:

* afsdisk1 컴퓨터 : OpenAFS 메인 DB 서버 인스턴스 + 파일 서버 인스턴스
* afsdisk2 컴퓨터 : OpenAFS 파일 서버 인스턴스
* 100명 이하의 클라이언트 인스턴스

다수의 사용자를 관리해야 하는 입장이라면, 이 매뉴얼에서 사용하는 OpenAFS 기본 인증 서버(kaserver) 대신 Kerberos v5 + openssl + 계정 정보를 담은 백엔드(ldap, radius 등) 로 인증 서버를 구축할 것을 권장한다.

구축할 수 있는 서버 인스턴스들에 대하여

구축할 수 있는 서버 인스턴스들의 목록은 다음과 같다:

인스턴스	사용 용도
kaserver	인증 데이터베이스를 관리하기 위한 인증 서버. kerberos v5 기준에 만족하는 인증서버를 총칭하는 인스턴스 명.
buserver	백업 데이터베이스를 관리하기 위한 백업 서버의 인스턴스 명.
ptserver	프로텍션(Protection) 데이터베이스를 위한 프로텍션 서버.
vlserver	VLDB(볼륨 위치 데이터베이스 : Volume Location Database)를 관리 하기 위한 볼륨 위치 서버(VLS). 각 셀을 구성하는 볼륨의 위치를 기억하고 관리하는, 대단히 중요한 구성품이다.
upserver	업데이트 서버. 서버의 설정/바이너리들을 다른 업데이트 클라이언트들에게 전파하는 역할을 한다.
fs	파일서버. 하나의 파일서버 인스턴스는 Fileserver (파일 서버), Volserver (볼륨서버), Salvager 로 구성된다.
upclientetc	클라이언트 부분의 업데이트 서버. 서버의 설정을 받아오는 인스턴스를 의미한다.
upclientbin	클라이언트 부분의 업데이트 서버. 서버의 AFS 관련 바이너리를 받아오는 인스턴스를 총칭.
runntp	ntp 클라이언트에 해당하는 서버. ntp 서버로 부터 시간정보를 받아와 동기화하는 인스턴스.
구축할 수 있는 서버 인스턴스들의 목록

이것을 보고 생각해야 할 것은, 시스템의 구성에 따라 그 역할을 분산시킬 수 있기 때문이다.

하나의 OpenAFS 메인 서버는 최소한 인증(kaserver) / 백업(buserver) / 프로텍션(ptserver) / VLDB(vlserver) / (서버 부분의) 업데이트 서버(upserver) 에 대한 인스턴스를 가지고 있어야 하며, 메인 서버와 맞물려 스토리지를 제공하는 파일 서버의 경우 클라이언트 부분의 업데이트 서버(upclientetc) / 서버 부분의 업데이트 서버(upserver) / 파일 서버(fs) 인스턴스를 가져야 최소한의 동작 보증을 할 수 있다.

좀 더 네트웍/시스템 환경의 분산을 고려한다면 데이터베이스 서버를 Replication 하는 방식으로 여러대로 분산 시킬 수도 있다. 스토리지 역시 서버 레벨에서의 Replication을 제공하기 때문에 분산의 혜택을 받을 수 있는 것들 중 하나이다.

충분히 고려한 후 서비스를 구성하여도 늦지 않다. 최소한, 고려하지 않고 변경에 따른 소요비용을 고려한다면 더욱 그러할 것이다.

OpenAFS Database Server 구성 (최초구성)

이 단락에서는 OpenAFS 서비스를 위한 메인 데이터베이스를 설치하고, 셀을 생성하고, 사용자 계정을 생성하는 부분을 언급할 것이다.

미리 준비해야 할 것들

OpenAFS를 설치, 운용할 서버가 필요함은 말할 것도 없다. OpenAFS를 사용하기 위해서는, 되도록 bind(named)를 사용하여 FQDN을 만족시켜 줄 필요가 있다. 현재 시스템이 참조하는 네임서버를 구성하던지 해서, hostname.domain.name 을 만족시켜야 할 것이다.

여기서는 첫번째 서버를 afsdisk1.testbed.org 라고 칭하게 될 것이다.

(두번째 서버는 afsdisk2.testbed.org 가 될 것이다)

Kerberos + openssl 을 사용할 수 있다. 다만, 이 매뉴얼에서는 언급하지 않을 것이다. 필요시 OpenAFS 공식 문서를 참조하기 바란다.

또한, 여러대의 AFS 서버 풀을 구성하려면, (최소한) 동등 셀은 같은 시간으로 동기화되어 있어야 한다. 이를 위해, 한대의 ntp 서버를 구성할 것을 권장한다.

OpenAFS 설치

먼저, OpenAFS를 설치해야 한다.

root@afsdisk1 # emerge net-fs/openafs

위의 명령을 내리면, openafs-kernel 과 openafs 패키지가 설치 될 것이다. 위의 명령어를 통해 커널 모듈과 바이너리가 정상적으로 빌드될 것이다. 테스트를 해보자면,2.6.18 최신 커널에서도 무리없이 컴파일이 될 것이다.

공식 문서가 설치되길 원한다면, emerge app-doc/afsdoc 을 설치하면 된다.

설치되는 장소는 OpenAFS가 Transarc 에서 IBM으로, 그리고 공개 되었을 때 변경되었다: 대강의 구조는 아래의 표를 참조하길 바란다:

디렉토리	사용용도	Transarc	기본형태	Gentoo
viceetcdir	클라이언트 설정	/usr/vice/etc	$(sysconfdir)/openafs	/etc/openafs
unnamed	클라이언트 바이너리	unspecified	$(bindir)	/usr/bin
afsconfdir	서버 설정	/usr/afs/etc	$(sysconfdir)/openafs/server	/etc/openafs/server
afssrvdir	내부 서버 바이너리	/usr/afs/bin (servers)	$(libexecdir)/openafs	/usr/libexec/openafs
afslocaldir	서버 상태	/usr/afs/local	$(localstatedir)/openafs	/var/lib/openafs
afsdbdir	인증/서버리스트 등의 DB	/usr/afs/db	$(localstatedir)/openafs/db	/var/lib/openafs/db
afslogdir	로그	/usr/afs/logs	$(localstatedir)/openafs/logs	/var/lib/openafs/logs
afsbosconfig	Overseer 설정	$(afslocaldir)/BosConfig	$(afsconfdir)/BosConfig	/etc/openafs/BosConfig
설치 장소에 대한 내용

net-fs/openafs-legacy 를 설치하면, Transarc 디렉토리 형태로 소프트 링크를 만들어준다.

BOS (Basic Over Seer) Server 초기 구동

최초 설치의 경우 설정 디렉토리(/etc/openafs)를 보면 {{{CellServDB}}} 파일과 {{{ThisCell}}} 파일이 있는데, 이 파일을 들여다보면 잘못된(?) 초기화 내용을 담고 있다. 초기화를 위해, 가차없이 삭제하자.

root@afsdisk1 # rm -f /etc/openafs/CellServDB
root@afsdisk1 # rm -f /etc/openafs/ThisCell

ps. 기존에 afs를 설정한적이 있다면 /etc/openafs/BosConfig 파일도 삭제하도록한다.

이제, bosserver를 다음 명령을 통해 초기화하자:

root@afsdisk1 # bosserver -noauth &&

-noauth 옵션은 당신이 현재 admin 권한이 충분히 설정되어 있지 않기 때문에, 인증 절차를 무시하고 접근하기 위해 사용하는 것이다. 보안상으로 위험하므로, 습관상 -noauth를 붙여 유지보수를 하지 않도록 해야 할 것이다.

위의 명령을 수행하면 /etc/openafs/server 디렉토리안에 이전의 {{{CellServDB}}} 파일과 {{{ThisCell}}} 파일이 생성되고, /etc/openafs 에 그 파일들에 소프트 링크가 걸려있을 것이다.

Cell 이름 생성

물리적/논리적으로 분산되어 있는 Storage Pool 을 엮어주기 위해, 구간을 정하는 일을 해야 한다. OpenAFS 에서는 동일 Cell 이름으로 스토리지 풀을 구별한다. 이 매뉴얼에서는, powercell 을 사용할 것이다. :p 이 Cell 이름이 클라이언트가 마운트 해야 할 이름이기 때문에, 되도록이면 짧게 짓는 것이 좋을 것이다.

Cell 이름은 대문자를 포함하지 않는 조건과 함께 영문/숫자 64자로 제한되어 있다. 절대 대문자로 셀 이름을 정하지 말것.

Cell 이름은 bos setcellname 명령어를 통해 구성할 수 있다. 용법은 아래와 같다:

용법 :

# bos setcellname <servername> <cell name> -noauth

아래와 같이, afsdisk1.testbed.org에 powercell 이라는 셀 이름을 정해준다.

root@afsdisk1 # bos setcellname afsdisk1.testbed.org powercell -noauth

데이터베이스 서버의 시작 및 구성

다음에 해 줄 일은, bos create 명령어를 사용, {{{/etc/openafs/BosConfig}}} 설정 파일에 데이터베이스 서버 프로세스들을 위한 설정을 추가해주고, 서버를 실행하는 일이다. 아래의 4개 프로세스를 띄우는데, 이는 셀에 포함되는 스토리지 서버에 설정되는 것이 아니라, 단일 셀을 구성하는 데이터베이스 서버 머신에만 있으면 되는 사항이다.

실행 파일	사용 용도
kaserver	인증 데이터베이스를 관리하기 위한 인증 서버다. 이는 Kerberos 5 인증 서버로 대체 가능하고, 기존에 Kerberos 인증 환경이 구축되어 있지 않다면 이를 사용하면 된다. (무리해서 Kerberos 를 구성할 필요가 없다는 뜻)
buserver	백업 데이터베이스를 관리하기 위한 백업 서버.
ptserver	프로텍션(Protection) 데이터베이스를 위한 프로텍션 서버.
vlserver	VLDB(볼륨 위치 데이터베이스 : Volume Location Database)를 관리 하기 위한 볼륨 위치 서버(VLS). 각 셀을 구성하는 볼륨의 위치를 기억하고 관리하는, 대단히 중요한 구성품이다.
실행파일 및 사용용도

위의 서버들을 구성하는 설정값을 갖추고 실행하기 위해, 다음의 용법을 사용해 설정한다:

AttentionIcon

1. bos create <{{{server name}}}> <{{{XXserver}}}> simple <{{{XXserver의 위치}}}> -cell <{{{cell name}}}> -noauth

각 서버 프로세스의 위치는 afssrvdir (1.2 절의 디렉토리 목록표를 참조할것), 즉 /usr/libexec/openafs 디렉토리에 있다.

각 데이터베이스 서버 구성 및 실행

위의 용법을 토대로, 위의 4가지 실행파일을 다 등록/실행하기 위해, 아래와 같이 실행하였다:

root@afsdisk1 # bos create afsdisk1.testbed.org kaserver simple \
 /usr/libexec/openafs/kaserver -cell powercell -noauth
root@afsdisk1 # bos create afsdisk1.testbed.org buserver simple \
 /usr/libexec/openafs/buserver -cell powercell -noauth
root@afsdisk1 # bos create afsdisk1.testbed.org ptserver simple \
 /usr/libexec/openafs/ptserver -cell powercell -noauth
root@afsdisk1 # bos create afsdisk1.testbed.org vlserver simple \
 /usr/libexec/openafs/vlserver -cell powercell -noauth

최초 구성을 이미 한 상태라면, 상단의 create 대신 start를 넣으면 각 서버를 띄울 수 있다.

각 데이터베이스 서버 동작 확인

위의 설정으로 4개의 서버를 등록한 후, bos status 명령으로 현재 상태를 볼 수 있다. 다음의 명령을 통해 상태를 알아보자: 정상적이라면 아래처럼 메시지가 뜰 것이다.

root@afsdisk1 # bos status afsdisk1.testbed.org -noauth
Instance kaserver, currently running normally.
Instance buserver, currently running normally.
Instance ptserver, currently running normally.
Instance vlserver, currently running normally.

AFS 보안 메커니즘 초기화를 위한 (최초) 사용자 계정 생성

Cell 보안 메커니즘을 초기화하기 위해, 2개의 설정 엔트리를 인증 데이터베이스에 추가해야 한다. 하나는 메인 관리자 계정(admin)을 생성하는 것이고, 다른 하나는 AFS 프로세스를 위한, afs 라는 계정을 생성하는 것이다.

afs 계정은 시스템 구성을 위해 반드시 생성해야 한다.

kas 를 사용한 사용자 계정 생성

이를 위해 kas 라는 사용자 명령행 툴을 사용한다. 최초 실행 용법은 아래와 같다:

# kas -cell <{{{cell name}}}> -noauth

목표 달성을 위해, 상단의 용법을 토대로 kas 를 실행하자:

root@afsdisk1 # kas -cell powercell -noauth

위의 명령을 실행하면, ka> 라는 프롬프트가 뜨게 될 것이다. create 명령을 사용하여 사용자 엔트리를 생성하고, examine 을 사용하여 생성된 엔트리를 검사한다. setfields 명령을 사용하여, admin 계정이 관리자임을 인식시키면 된다. 이제 아래와 같이 실행하도록 하자:

ka> create afs
initial_password:
Verifying, please re-enter initial_password:
ka> create admin
initial_password:
Verifying, please re-enter initial_password:
ka> examine afs

User data for afs
key (0) cksum is 2651715259, last cpw: Mon Jun  4 20:49:30 2001
password will never expire.
An unlimited number of unsuccessful authentications is permitted.
entry never expires.  Max ticket lifetime 100.00 hours.
last mod on Mon Jun  4 20:49:30 2001 by <none>
permit password reuse
ka> setfields admin -flags admin
ka> examine admin

User data for admin (ADMIN)
key (0) cksum is 2651715259, last cpw: Mon Jun  4 20:49:59 2001
password will never expire.
An unlimited number of unsuccessful authentications is permitted.
entry never expires.  Max ticket lifetime 25.00 hours.
last mod on Mon Jun  4 20:51:10 2001 by <none>
permit password reuse
ka>

생성한 사용자를 사용자 리스트에 추가하는 방법

위 구간을 수행, kas를 통해 사용자 계정을 생성하였지만 계정을 사용자 리스트에 따로 추가해야 한다. admin 계정을 사용자 리스트({{{/etc/openafs/server/UserList}}})에 추가하도록 하자. 용법과 사용예는 아래와 같다:

용법:

# bos adduser <'''server name'''> <'''account name'''> -cell <'''cell name'''> -noauth

위의 용법을 기초로 아래의 명령을 수행, admin 계정을 사용자 리스트에 추가했다:

root@afsdisk1 # bos adduser afsdisk1.testbed.org admin -cell powercell -noauth

(admin 이외에도) 생성된 사용자는, 완전한 동작을 위해 ptserver에 마찬가지로 등록이 되어야 할 것이다.

AFS 서버 암호화 키를 생성하기

이제 AFS 서버의 암호화를 위한 키를 생성해야 한다. bos addkey 명령을 사용하여, 이 목적을 달성할 수 있다. 사용법은 다음과 같다:

# bos addkey <'''server name'''> -kvno 0 -cell <'''cell name'''> -noauth

위의 용법대로 실행 할 경우, 암호 키를 집어넣으라고 하는데, 이 키의 값은 자신이 afs 계정을 생성할 때 사용한 키와 동일하게 넣어야 한다.

(ptserver) 프로텍션 데이터베이스에 admin 계정 연결하기

pts createuser 명령어를 사용해서, 프로텍션 데이터베이스에 admin 사용자를 위한 엔트리를 생성해야 한다.

기본적으로, 프로텍션 서버는 AFS UID(사용자 ID) 1을 관리자로 할당하는데, 이는 이제까지 생성한 기록상 첫번째 유저가 admin 이기 때문이다. 필요할 경우, -id 옵션을 사용해 조정할 수 있다. 문제는, UNIX 상에서의 실제 admin 유저의 UID를 필요로 한다는 것인데, 이를 위해서는 어쩔 수 없이(?) admin 계정을 만들어줘야 할 것이다. (혹은 기존의 bin 계정 - 즉 시스템의 UID가 1인 계정으로 AFS에 기록이 되는것을 보던지.) 이 admin 계정을 만들어 UID를 알아낸 후, -id 옵션을 붙여 UID를 매핑시켜주는데, admin 계정이나 기타 afs에서 사용할 계정이 반드시 로그인 되어야 할 필요는 없다는 뜻이다. (/bin/false 를 셸로 지정해도 된다는 뜻이다.)

사용법은 아래와 같다:

# pts createuser -name admin -cell <'''cell name'''> [-id <'''AFS UID'''>] -noauth

위의 용법을 토대로, 아래의 명령어를 수행했다: 계정 생성후, admin의 UID가 1002번이라면, -id 1002 를 붙여주는 것이다.

root@afsdisk1 # pts createuser -name admin -id 1002 -cell powercell -noauth

이제 이 사용자가 system:administrators 그룹에 포함될 수 있도록, pts adduser 명령을 사용하여 그룹에 포함시키고, pts membership 명령을 통해 확인하도록 하자. 아래의 예를 알아서 적절하게 고쳐가면서 사용하자.

root@afsdisk1 # pts adduser admin system:administrators -cell powercell -noauth
root@afsdisk1 # pts membership admin -cell powercell -noauth
Groups admin (id: 1002) is a member of:
system:administrators

AFS 서버 재시작

이제 상단의 설정이 끝났으면, 이제 까지 띄운 AFS의 모든 서버를 재시작 하도록 하자.

서버의 재시작을 위한 용법은 아래와 같다:

# bos restart <'''server name'''> -all -cell <'''cell name'''> -noauth

위의 용법대로, 아래와 같이 실행하여 AFS 서버를 재시작 하자:

root@afsdisk1 # bos restart afsdisk1.testbed.org -all -cell powercell -noauth

fs 인스턴스 : 파일 서버, 볼륨 서버, 그리고 Salvager 프로세스의 구동

이 단락은 실제로 서비스를 위한 스토리지가 담긴 물리적 서버에서 추가되어야 하는 인스턴스 이다. 이는 원래 메인 서버에 필수적인 요소가 아니지만, 대부분이 데이터베이스 서버와 파일 서버가 같은 물리적 서버에서 작동하게 만드는 것이 보통이므로, 순차적인 구성을 보여주기 위해서 Database 서버 구성 목록에 포함시킨것이다.

이제 bos create 명령을 다시 사용하여, 파일서버, 볼륨 서버, 그리고 Salvager를 등록하고, 구동해야 한다. 이들 3개의 프로세스는 다른 서버 프로세스와 마찬가지로 /usr/libexec/openafs 내에 있고, 각각 fileserver, volserver, salvager 라는 이름을 갖는다.

추가하는 방법은, 아래의 용법과 같다:

# bos create <'''server name'''> fs fs <'''파일서버 프로세스명'''> <'''볼륨서버 프로세스명'''> <'''salvager 프로세스명'''> -cell <'''cell name'''> -noauth

위의 용법을 토대로, 아래의 명령문을 실행하면 된다:

root@afsdisk1 # bos create afsdisk1.ucsoft.org fs fs \
 /usr/libexec/openafs/fileserver /usr/libexec/openafs/volserver \
 /usr/libexec/openafs/salvager -cell powercell -noauth

OpenAFS 서버 프로세스에 대한 세부 상태 확인

이제까지의 과정으로 모든 서버 프로세스를 구성하였으면, 그 프로세스가 잘 떠 있는지 다음의 용법으로 확인 할 수 있다: 역시 마찬가지로 bos status 명령을 사용한다.

# bos status <server name> -long -noauth

위의 용법을 사용하여, 실행하면 다음과 같은 화면이 나온다:

root@afsdisk1 # bos status afsdisk1.testbed.org -long -noauth
Instance kaserver, (type is simple) currently running normally.
    Process last started at Sun Nov 19 00:55:34 2006 (14 proc starts)
    Last exit at Sun Nov 19 00:52:08 2006
    Command 1 is '/usr/libexec/openafs/kaserver'

Instance buserver, (type is simple) currently running normally.
    Process last started at Sun Nov 19 00:56:08 2006 (14 proc starts)
    Last exit at Sun Nov 19 00:52:08 2006
    Command 1 is '/usr/libexec/openafs/buserver'

Instance ptserver, (type is simple) currently running normally.
    Process last started at Sun Nov 19 00:56:11 2006 (14 proc starts)
    Last exit at Sun Nov 19 00:52:08 2006
    Command 1 is '/usr/libexec/openafs/ptserver'

Instance vlserver, (type is simple) currently running normally.
    Process last started at Sun Nov 19 00:56:17 2006 (14 proc starts)
    Last exit at Sun Nov 19 00:52:08 2006
    Command 1 is '/usr/libexec/openafs/vlserver'

Instance fs, (type is fs) currently running normally.
    Auxiliary status is: file server running.
    Process last started at Sun Nov 19 00:55:34 2006 (4 proc starts)
    Last exit at Sun Nov 19 00:55:34 2006
    Command 1 is '/usr/libexec/openafs/fileserver'
    Command 2 is '/usr/libexec/openafs/volserver'
    Command 3 is '/usr/libexec/openafs/salvager'

에러 발생으로 인한 종료의 경우, 종료시의 리턴값이 같이 나타나게 될 것이다.

Fileserver 의 UDP 리스닝 인터페이스 설정

afslocaldir (/var/lib/openafs) 에서 {{{NetInfo}}} 파일을 생성하는 것으로, 현재 서버 시스템의 네트웍 인터페이스가 여러개일 때는 이들을 등록해줘야 한다.

/var/lib/openafs 디렉토리로 이동, {{{NetInfo}}} 라는 이름으로 텍스트 파일을 작성한다.

입력 방식은 IP를 넣어주는데, 다음과 같이 한다:

192.168.0.21
127.0.0.1

그런 다음, bos restart 명령을 사용, Fileserver를 재시작 하도록 한다.

이제 무엇을 해야 하나?

지금까지의 내용은 OpenAFS를 사용하기 위해, 최초로 서버를 구성하는 것에 대해서 다루었다. 서버를 구성했으면, 앞으로는 그 서버가 서비스할 셀을 제공하는 실제 스토리지 공간과 연결시켜줘야 하는 작업이 될 것이다. 그 작업을 위해, 다음 장인 OpenAFS Cell Volume 구성을 살펴보기 바란다.

OpenAFS Cell Volume 구성

OpenAFS 서버를 구성하기 위한 두번째, 셀의 구성품인 볼륨(Volume)을 생성/추가하는 단락이다. 위의 단락을 통해 이제까지 볼륨을 담을 수 있는 큰 상자를 만들었다면, 이제 큰 상자안에 담길 그릇들을 넣을 차례이다.

Cell Volume 들을 처음 구성한다면, 다음 두가지를 기억하라. 첫번째는 최소한의 구동을 위해 root.afs 와 root.cell 이 반드시 필요하다는 사실을 기억해야 한다. 두번째는 다른 시스템에 단순 파일 서버를 구성하기 위해, 앞에서 해왔던 데이터베이스까지 다른 시스템에 구축할 필요는 없다는 사실이다. 반드시 기억해두고, 구성에 임해야 할 것이다.

디스크 준비

서비스를 할 디스크를 파티션을 쪼개던지, 물리 디스크를 한 파티션에 잡던지, 어떻게 하든 여분의 빈 파티션이 필요하다: AFS는 추가적인 디스크 캐싱을 하기 때문에, 파일 시스템은 ext2, 혹은 ext3을 사용할 것을 권장한다. 다른 파티션은 지원하지 않을 뿐 더러, 위험하기까지 하다. (reiserfs 의 경우, 에러 메시지를 출력하며 당신에게 경고를 할 것이다)

Transarc / 구 버전의 OpenAFS 는 분리된 ext2 파티션에 디스크 캐싱을 위한 공간을 필요로 했다. 이 사항 역시 지금은 바뀌었고, 지금은 /etc/openafs/cacheinfo 에 캐싱된 용량 상태를 저장한다.

SGI XFS를 쓰고 싶다면, 또다른 AFS 구현체인 arla (http://www.stacken.kth.se/project/arla/) 를 사용할 것을 권장한다.

여기서는, /dev/hda4 에 ext3으로 구성을 할 것이다.

준비가 되었으면, 루트 디렉토리에 vicepX 디렉토리를 만들어야 한다. (X 위치에는 선호하는 값을 넣는다. a를 넣든 b를 넣든, 영문 소문자로 넣는다. 여기서는 vicepa 로 설정하겠다.)

경험상 X 위치에 숫자가 들어가거나 하면 인식하지 못하는 문제가 생긴다.

root@afsdisk1 # mkdir /vicepa

이제 /etc/fstab 에 위 디렉토리로 파티션을 마운트하게 해 줘야 한다. /etc/fstab을 열고 아래의 줄을 추가해 줄 것이다: 아래의 내용을, 원하는 설정으로 고쳐서 사용하도록 하자.

 fstab
/dev/hda4               /vicepa        ext3            defaults        0 2

이제, /etc/fstab에 설정해준 대로, 마운트를 하도록 하자. 아래의 명령을 내리면, /dev/hda4 는 /vicepa 디렉토리에 마운트 될 것이다.

root@afsdisk1 # mount -a

(최초 구성시) 볼륨 서버 데이터베이스에 볼륨 생성하기

이 부분은 첫번째 AFS 서버를 구성할 때 사용하는, root.afs 라는 첫번째 AFS 볼륨을 생성하는 부분이다.

사용법은 아래와 같다:

# vos create <server name> <partition name> root.afs -cell <cell name> -noauth

파티션 이름은, 실제 디바이스 파일 대신 앞에서 언급했던 파티션 이름을 사용해야 한다. (/vicepX)

앞에서 /vicepa 로 생성한 것과 위의 용법을 토대로, 다음을 실행한다:

root@afsdisk1 # vos create afsdisk1.testbed.org /vicepa root.afs -cell powercell -noauth
Volume 536870912 created on partition /vicepa of afsdisk1.testbed.org

정상적으로 실행 될 경우, 해당 볼륨의 크기가 메시지에 포함될 것이다.

'partition /vicep01 does not exist on the server' 라는 메시지가 나오면, 해당 파티션을 마운트 하고, bos restart 명령으로 서버를 재시작 한 후 재시도를 하면 된다.

서버 부분에서의 Update 서버 구성

셀에 포함된 다른 머신들에게 이들 디렉토리의 내용을 배포하기 위해, (서버 레벨에서의) Update 서버 (upserver 프로세스)를 시작해야 한다. 이들은 당신이 다른 서버 머신에서, 추가로 클라이언트 레벨의 Update Server를 구성할 때 활성화 된다.

용법은 아래와 같다:

# bos create <server name> upserver simple "/usr/libexec/openafs/upserver \
-crypt /etc/openafs/server -clear /usr/libexec/openafs" -cell <cell name> -noauth

위의 용법을 토대로, 서버레벨에서의 Update 서버를 구성하자:

root@afsdisk1 # bos create afsdisk1.testbed.org upserver simple \ 
"/usr/libexec/openafs/upserver -crypt /etc/openafs/server -clear /usr/libexec/openafs" \
-cell powercell -noauth

클라이언트 부분의 Update 서버 구성

이 부분을 접하면 이상하게 생각할 사항이, "왜 셀 볼륨만 있는 파일서버를 구성하는데 클라이언트 부분의 Update 서버가 필요한거지?" 가 될 것이다. 이 질문에 대한 대답은, "단순 파일서버 역시 메인 OpenAFS 서버로부터 설정들을 받아와야 하니까" 가 될 것이다. 따라서, OpenAFS 메인 서버 내에 만 파일 서비스를 추가하고 싶다면, 이 구간을 지나쳐도 될 것이다.

클라이언트 부분의 Update 서버는 2개로 나뉘어진다. 하나는 OpenAFS (Database) 서버로 부터 시스템 설정 사항을 받아오고(즉, /etc/openafs/server 설정을 배포하는 서버로 부터 설정을 받아오는), 동기화 하는 upclientetc 와, 바이너리 서버로부터 AFS 관련 바이너리를 동기화하는 upclientbin 이 있다. Thin Client 의 구성이 아니라면, 기본적으로는 upclientetc 만 설정하면 된다.

단순 셀 볼륨 파일 서버는 이 upclientetc 와 함께, 서버 부분에서의 Update 서버 (즉, upserver) 두가지를 필요로 한다.

upclientetc 를 구성하는 용법은 다음과 같다:

 # ./bos create  <'''machine name'''> upclientetc simple  \ 
     "/usr/afs/bin/upclient <'''system control machine'''> [-t  <time>]  /usr/afs/etc" \
     -cell  <cell name>  -noauth

이 용법은 근거로, upclientetc를 구성해보자: OpenAFS 인증/백업/프로텍션/VLDB 가 구성된 데이터베이스 서버의 위치가 afsdisk1.testbed.org 일때, 단순 파일 서버의 역할만 하는 afsdisk2를 추가시켜주기 위해서는, 다음과 같이 명령을 실행하여 upclientetc를 구성할 것이다.

root@afsdisk2 # bos create afsdisk2.testbed.org upclientetc simple \
 "/usr/libexec/openafs/upclient afsdisk1.testbed.org /etc/openafs/server" \
 -cell powercell -noauth

Deprecated: AFS 가 제대로 작동하기 위한 시간 동기화 구성

이 단락 대신에, ntpclient + cron를 사용해 시간을 주기적으로 동기화를 하면 된다. GentooLinux 배포본의 openafs는 이 runntp가 들어가있지 않다.

먼저, 이를 진행하기 전에 ntpd 서버가 구동중이어야 한다. (앞의 장에서 필요하다고 언급했던 것 처럼) 아니면, 최소한 외부의 ntp 서버 주소를 알고 있어야 할 것이다.

이 단락에서는 runntp 프로세스를 등록해, 서버간 시간을 동기화 하는 것에 대해 언급할 것이다:

다음의 용법을 사용하여 runntp 프로세스를 등록한다:

 # bos create <'''machine name'''> runntp simple "runntp <'''ntp 서버 주소'''>+" -cell <'''cell name'''> -noauth

외부 ntp 서버가 없이, 로컬 시스템의 시간을 사용하려면, runntp 가 들어가는 부분에 ntp 서버 주소 대신 -localclock 옵션을 넣어주도록 한다. 만약 외부 ntp 서버 접근에 딜레이나 중단이 자주 있을 꺼라 판단하면, -localclock 옵션 뒤에 해당 ntp 서버 주소를 넣으면 된다.

위의 용법과 주의사항을 근거로 아래의 명령을 실행하도록 하자.

root@afsdisk1 # bos create afsdisk1.testbed.org runntp simple \
 "runntp afsdisk1.testbed.org" -cell powercell -noauth

실제 사용하게 될 루트 볼륨 구성하기

처음 AFS 서버를 구성하여, root.afs 를 생성한 경우에도 실제 사용할 루트 볼륨은 구성해야 한다. (구성하지 않고, root.afs만 구성되어 있다면, 클라이언트 사이드에서 접속한 후에 디렉토리를 접근할 경우 "접근할 장치가 없음" 이라는 메시지를 보게 될 것이다)

용법은 아래와 같다:

# vos create <'''server name'''><'''partition name'''> root.cell

위의 용법을 근거로, root.cell 볼륨을 생성하도록 하자.

root@afsdisk1 # vos create afsdisk1.testbed.org /vicepa root.cell

fs 명령어를 사용, 디스크 쿼터 할당하기

위의 단계까지 잘 진행되었다면, 이 상태에서도 클라이언트가 OpenAFS 를 탐지하고 (인증을 받기 전) 마운트 상태까지 만들어 줄 것이다.

문제는 클라이언트가 kaserver 인증을 받고 난 다음에, 조금 큰 파일을 올리려고 하다보면 얄짤 없이 디스크에 남은 공간이 없다고 하게 될 것이다. 이럴 경우를 위해, 최대 쿼터를 할당해야 한다. 단위는 {{{KByte}}}로 넣으면 된다. 아래의 예제는 /afs/powercell에 20{{{Gbyte}}}로 할당한 것이다.

root@afsdisk1 # fs setquota /afs/powercell -max 20000000

fs mkmount 를 사용하여 위의 afs 파일시스템을 마운트 하던지, 아니면 클라이언트를 띄운 후 admin 계정에 접속해서 저 메시지를 날려야 할 것이다. 자세한 것은 OpenAFS Client 구성 부분을 참조하길 바란다.

OpenAFS Client 구성

위의 과정을 통해 구성한 서버와 셀 볼륨을 활용하기 위해서는 당연히 클라이언트가 필요하다. 이 단락에서는, 클라이언트를 설정하는 방법에 대해 언급할 것이다.

먼저, 클라이언트를 구성하기 위해서는 당연히, net-fs/openafs 패키지가 필요하다. 주저없이 입력하라:

root@hostname # emerge net-fs/openafs

Client 설정파일 변경

먼저, /etc/openafs 디렉토리의 {{{CellServDB}}} 와 {{{ThisCell}}} 파일을 수정해야 한다. 수정하는 방법은, 서버의 IP와 Cell name을 가르키게 해야 하는데, 서버에 구성되어 있는 위 두개 파일을 참조해서 설정해야 한다.

먼저, {{{/etc/openafs/CellServDB}}} 파일을 잡는다. 이때 주의할 점은, # 뒤에 붙는 값이 절대 주석처리가 아니라는 사실이다. 반드시 >Cellname 이후에는 #Cell name 이라고 써줘야 한다. 그 아랫줄에는 IP를 기입하고, 다시 이후에 #hostname(.domain.name) 을 기입해줘야 한다는 사실이다.

>powercell     #Cell name
192.168.0.21   #afsdisk1

띄워져 있는 공간은 Tab을 넣는 것이 아니라, 스페이스 공백을 넣어야 한다. Tab을 사용할 경우, 잘못 인식한다.

다음은 {{{/etc/openafs/ThisCell}}} 파일을 수정한다. 이 파일에는 단순히 포함하는 셀 명을 기입하면 된다.

powercell

클라이언트 기준에서의 캐시 설정

클라이언트에서도 AFS 캐시를 위해 로컬의 일정 부분에 캐싱을 하게 된다. 그 위치정보는 {{{/etc/openafs/cacheinfo}}} 에 저장되며, 기본값으로 {{{/var/cache/openafs}}} 아래 캐시가 저장되도록 되어 있다. 대강의 내용은 아래와 같다:

/afs:/var/cache/openafs:200000

기본값은 {{{200MByte}}} 로, /afs 에 마운트되는 AFS 파일시스템을 위해 /var/cache/openafs 에 캐시를 구성하겠다고 되어 있다.

권장 값은 {{{2GByte}}}로 잡는것이 좋다. 파일 억세스 속도가 느리다고 생각하면, 캐시를 크게 잡고, 그런 다음 /etc/conf.d/openafs-client 의 옵션에 chunksize를 조정하는 옵션을 붙여줘야 한다.

현재 시스템이 Reiserfs나 SGI xfs 파일시스템을 쓰고 있다면, 불행하게도 이들 캐시를 위해 ext2/ext3 파티션을 할당해줘야 한다. xfs 같은 경우 파일시스템을 줄이는(shrink)것이 불가능 하므로, 이런 경우에는 ext2 이미지를 생성, loopback 마운트를 하여 사용하는 수 밖에 없다.

이미 ext2/ext3 파일 시스템을 사용하고 있다면, 아래의 내용은 더 이상 살펴볼 필요가 없다.

먼저, dd를 사용해서 일정 공간을 확보하도록 하자.

root@hostname # dd if=/dev/zero of=/ext2part4afs.img bs=1024M count=2

위의 명령어를 사용해서 2GB의 zero-filled 된 파일을 확보하면, mkfs를 사용해서 ext2 이미지를 생성하자:

root@hostname # mkfs.ext2 /ext2part4afs.img

디바이스 파일이 아니라고 하면, 상큼하게 무시하고 계속 진행하면 된다.

여하간, 다 만들어지면 이제 /etc/fstab 파일과, 캐시가 들어갈 디렉토리를 확보하도록 하자. 이미 /var/cache/openafs 디렉토리가 있을 테지만, 해당 디렉토리가 비어있도록 해야 한다.

/etc/fstab 파일에 다음의 내용을 추가한다.

 fstab
# AFS cache 를 위한 설정.
/ext2part4afs.img      /var/cache/openafs  ext2  loop,defaults 0 0

설정이 끝나면, mount -a 를 실행하여 해당 이미지를 loopback mount 하자.

이제, /etc/openafs/cacheinfo 파일을 수정하자. ext2 파티션으로 바뀐 이미지는 실제 2GB 보다 작을 것이므로, 마운트 된 파일시스템의 용량을 확인하고 적절하게 넣어주자.

/afs:/var/cache/openafs:1800000

마운트가 끝나고 캐시를 넣을 공간을 확보하더라도, 반응속도등이 현저하게 떨어지는 문제가 있다. 이를 위해서 chunksize를 높게 잡아줘야 하는데, 이 값은 2^n 으로 증가시킬 수 있다. (옵션 입력값이 n이다)

/etc/init.d/openafs-client의 세부사항을 보면, 현재의 캐시 크기에 맞춰서 옵션이 달라지도록 설계되어있음을 알 수 있다: 따라서, /etc/conf.d/openafs-client 파일을 열면, 자신의 캐시 사이즈에 맞는 변수를 찾아 고쳐줘야 할 것이다. (귀찮다면 모든 변수에 지정해도 된다.)

구조상, 캐시사이즈에 따른 변수 채택은 다음과 같이 이루어진다:

128MB > 캐시사이즈 ==> $SMALL
512MB > 캐시사이즈 ==> $MEDIUM
1GB > 캐시사이즈 ==> $LARGE
2GB > 캐시사이즈 ==> $XLARGE
2GB < 캐시사이즈 ==> $XXLARGE

/etc/conf.d/openafs-client 파일의 마지막을 보면,

 config
OPTIONS="AUTOMATIC"

이라고 되어 있는데, 자신이 원하는 설정을 강제로 선택하게 하고 싶을 경우에는, SMALL / MEDIUM / LARGE / XLARGE / XXLARGE 등으로 잡아 놓을 수 있다.

중요한것은, chunksize를 지정해줘야 한다는 것인데, 이것의 기본값은 0이다. 값은 2^n 으로 계산하며, 캐시 사이즈 1GB~2GB 기준에 2^18 = 256 Kilobyte, 즉 -chunksize 18 로 잡아주는 것이 좋다.

위의 설정으로는 $XLARGE가 선택될 것이므로, (대충 1.8GB 캐시) XLARGE 쪽의 변수 맨 끝에, -chunksize 18 을 추가해주자:

 config
XLARGE="-fakestat -stat 3600 -dcache 3600 -daemons 5 -volumes 196 -files 50000 -chunksize 18"

이 정도만 해도, AFS에 연결하고 파일을 직접 접근하고 동영상을 재생해도, 무리가 없을 것이다.

openafs-client 서비스 시작

위의 설정이 끝나고, 캐시를 사용하는데 아무런 문제가 없으면, openafs-client 서비스를 시작해야 한다. 다음을 입력하여, openafs-client 서비스를 실행한다. 이것을 실행하면, 자동적으로 AFS 커널 모듈이 적재되고, /afs/cellname 이 생성될 것이다.

root # /etc/init.d/openafs-client start

매번 시작시때 자동 적용을 하고 싶을 경우에는, 'rc-update add openafs-client default' 명령을 수행하면 된다.

kaserver를 통해 로그인하는 방법

서비스가 시작해도, 막상 접근하면 퍼미션이 없다고 할 것이다. 이제는 klog 프로그램을 통해 kaserver의 인증을 거쳐 토큰을 받아내야 한다. 위의 설정이 잘 되고 서비스가 잘 시작되었다면, 사용법은 간단하다:

username@hostname > klog <AFS 사용자 명>

정상적으로 인증이 되면, 그냥 아무말 없이 다시 프롬프트가 떨어질 것이다. 이제까지 admin 계정만 생성했었다면, AFS 사용자 명에 admin을 입력하면 될 것이다. 패스워드는 마찬가지로, 자신이 입력했던 패스워드를 사용하면 된다.

자, 이제 /afs/cellname 에 접근해 보자. 접근이 잘 된다면, OK다.

팁 / 관리 / 문제 해결

(선택사항) *NIX 시스템 로그인으로 AFS Login 이 동시에 가능하게

선택사항이라고 하는 것은, klog 를 사용해서 로그인을 언제든지 할 수 있기 때문이다. 이 작업을 위해서는 계정의 UID 와 프로텍션 서버(ptserver)에 계정 생성시 들어가는 UID를 맞춰줘야 하는 귀찮은 작업이다.

AFS는 PAM과 연동을 할 수 있게 해준다. 이제부터 그 절차를 설명해 나갈 것이다:

/lib/security 디렉토리에는 pam 관련 라이브러리들이 들어있다. openafs 를 설치하면, 이 디렉토리에 pam_afs.so.1 과 pam_afs.krb.so.1 파일이 추가될 것이다.

우리가 수정해야 할 파일은 login 시 참조하는 /etc/pam.d/system-auth 와, su 등으로 권한을 이동할 때 참조하는 /etc/pam.d/su 등이 있다.

/etc/pam.d/system-auth 를 다음과 같이 수정한다:

 pam.d
#%PAM-1.0

auth       required     pam_env.so
auth       sufficient   pam_unix.so try_first_pass likeauth nullok
# AFS를 위해 추가한 부분은 아랫줄이다.
auth       sufficient   pam_afs.so.1 use_first_pass ignore_root
auth       required     pam_deny.so

account    required     pam_unix.so

password   required     pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 try_first_pass retry=3
password   sufficient   pam_unix.so try_first_pass use_authtok nullok md5 shadow
password   required     pam_deny.so

session    required     pam_limits.so
session    required     pam_unix.so

/etc/pam.d/su 의 내용을 아래와 같이 변경한다. (주석은 모두 삭제되었다. 적절하게 수정하자):

pam.d
#%PAM-1.0

# AFS를 위해 추가된 부분은 바로 아랫줄이다.
auth       sufficient   pam_afs.so.1 ignore_uid 100
auth       sufficient   pam_rootok.so
auth       required     pam_wheel.so use_uid
auth       include              system-auth
account    include              system-auth
password   include              system-auth
session    include              system-auth
session    required     pam_env.so
session    optional             pam_xauth.so

AFS의 계정 권한 (ACL) 변경

system:administrators 권한에서나, 혹은 ACL 변경 권한이 있는 계정으로, fs setacl 명령을 사용하여 변경하면 된다.

fs setacl의 용법은 다음과 같다: 추가적인 옵션은, fs help setacl로 확인하기 바란다.

fs setacl -dir <'''directory'''>+ -acl <'''access list entries'''>+ {{{[-clear] [-negative] [-id] [-if]}}}

디렉토리는 마운트 포인트내 디렉토리(예: /afs/powercell)를 넣고, acl에는 다음과 같은 값을 넣을 수 있다:

flag	의미
i	삽입(insert) 권한. 디렉토리에 파일을 추가하거나, 복사, 생성, 새 디렉토리 생성 여부가 포함된다. 새로만든 디렉토리에까지 앞의 권한이 확장되지는 않는다.
d	삭제(delete) 권한. 파일을 삭제, 혹은 이름을 바꾸거나, (i권한도 가지고있다는 전제하에)옮길 수 있다.
a	관리(administer) 권한. 각 파일/디렉토리의 권한 변경이 가능하다. system:administrators 그룹에 속한 사용자는 기본적으로 가지는 권한이다.
r	읽기(read) 권한. ls -l 등으로 보여지는 파일들을 검색하고, 내용을 읽을 수 있다.
w	쓰기(write) 권한. 해당 파일의 내용이나 chmod 같은 UNIX 퍼미션 비트등을 조절할 수 있다.
k	잠금(lock) 권한. 디렉토리/파일을 잠글 수 있게 하는 권한.
ACL에서 적용가능한 값과 의미

AFS는 추가적으로 정의되지 않은 사용자 권한 비트를 쓸 수 있게 해준다: 대문자 A, B, C, D, E, F, G, H - 총 8개 - 를 사용할 수 있다. AFS 기반의 프로그램을 개발할 때, 이들 flag에 대해 의미를 부여하고, 그에 따른 액션을 사용할 수 있게 해준다.

-clear 옵션은 ACL 리스트를 비워주는 옵션이고, -negative는 현재 할당된 권한의 반대로 플래그를 변화시켜준다. -id/-if 는 각각 디렉토리/파일에 대한 초기 권한 할당을 하는 옵션이다.

볼륨 서버에 포함된 볼륨 리스트를 동기화하기

vos 명령행 도구는 볼륨 서버 / 볼륨 위치 데이터베이스에 관련된 작업을 하는 도구이다. 이를 이용하여, 같은 셀 내의 볼륨들에 대한 생성/삭제/리스트 동기화 등등을 할 수 있다. 이 단락에서 언급할 내용은, 각 서버에 잡혀있는 볼륨 리스트를 동기화 (sync VLDB) 하고, 볼륨 서버 동기화 (sync Server) 를 가능하게 하는 것이다.

VLDB/볼륨 서버 동기화는 다음과 같이 할 수 있다: 위의 것이 VLDB 동기화, 아래의 줄이 서버 동기화이다.

# vos syncvldb <'''server name'''> -cell <'''cell name'''> -localauth 또는 -noauth (현재 인증설정에 의존)
# vos syncserv <'''server name'''> -cell <'''cell name'''> -localauth 또는 -noauth

참고로, 현재 vldb의 리스트는 다음과 같이 확인할 수 있다:

# vos listvldb

클라이언트에서 실행하면, 현재 셀의 모든 볼륨에 대한 리스트를 볼 수 있을 것이다.

볼륨의 남은 공간 보기

볼륨의 남은 공간은, 다음의 명령을 통해 알 수 있다:

# fs diskfree

현재 Quota의 값이라던지, 다른 세부사항을 볼 때는 fs examine을 사용하면 된다. 마운트 포인트에 대한 모든 사항을, fs 명령어로 확인할 수 있기 때문에, fs help 를 사용하여 쓸 수 있는 명령어를 알아두는 것이 좋을 것이다.

너무 느리다 : 캐시 설정 이후에도, 파일을 가져오거나 리스팅에 지연(delay) 발생시

klog 인증시의 지연(delay)

klog로 접속하는데 딜레이가 생긴다면, 일단 설정을 먼저 확인해보라. {{{/etc/openafs/CellServDB}}}가 접속 장애의 첫번째 이유가 될 수 있고, 그 다음은 서버의 인스턴스가 전부 작동하는지 bos status 명령으로 확인해보길 바란다. 단순히 init.d 스크립트로 구동했을 때, 모든 인스턴스 역시 실행될 거라는 보장은 아무도 못한다. (init.d의 구동 스크립트 는 bos 서버가 잘 뜨는지만 확인할 수 있을 뿐이다)

VLDB 리스팅시의 지연

Kerberos 인증에는 아무런 문제가 없었으나, vos listvldb 를 통해 현재 클라이언트가 인식한 VLDB 의 구조를 가져오는데 지연이 발생할 수 있다. 이 문제는 대부분 네임 서버를 통해 질의, 해당 OpenAFS 볼륨 서버/파일 서버로 접근할 때 발생한다. /etc/resolv.conf 가 네임서버를 정확하게 가르키고 있는지, 혹시 hostname 만으로 찾는다면 동등 domainname 을 자동으로 넣는지 등을 확인해 봐야 할 것이다. 필요하면, NSCD(Name Server Caching Daemon)을 재시작 하거나 시동시 자동으로 등록되게끔 하는 방법도 추가할 수 있다.

그래도 접속/파일 접근/전송이 느리다면

1. 방화벽 문제를 의심한다.
   OpenAFS 서버는 최소 7000~7010 까지의 UDP를 필수적으로 요구한다. 클라이언트 역시 7000~7010 UDP 포트를 열어두기를 권장한다.
2. 동등 네트워크에 존재하는지 (동일 클래스인지) 검사해보라.
   사무실에서 구성할 경우, 무선 네트웍/DHCP 접속자는 200번대 이후로 IP를 발급했는데, DHCP 접속자가 유달리 접속/전송 속도가 느렸던 문제를 경험하였다.
3. {{{/etc/openafs/CellServDB}}} 파일의 설정을 의심해보라.
   뒤의 주석이라고 생각될 만한 #Cell name 이나 #hostname.domain.name 역시 설정 파일에 들어가야할 내용이다. 없을 경우, 접속 속도나 전송에 지연현상을 겪었다. 그리고, 이 파일에는 셀에 포함된 모든 파일 서버까지 목록에 들어가는 것이 아니라, OpenAFS 데이터베이스 서버의 위치만 들어가야 한다. VLDB 서버가 없는 단일 파일서버가 이 목록에 포함되어 있을 경우, 역시 지연현상이 생길 수 있다.

AFS 벤치마크에 대하여

구성된 AFS 의 성능을 검사하기 위해, 여러가지 툴을 사용할 수 있다: 권장하는 것들로는 다음과 같은 것이 있다.

• Andrew Benchmark 가 있다.
• bonnie++ 을 사용하는 방법도 있다.
• 이것도 저것도 귀찮다면 dd 를 사용하라. 읽기 때는 /dev/null 로 보내고, 쓸 때는 /dev/zero 에서 가져오라. 이 때, 동등 파일을 여러번 실시하게 되면, afsd가 캐시를 이용하게 되어 테스트 결과가 혼란스럽게 나올 것이다. 정상적인 표본은, 절대 현재 네트워크의 한계속도를 뛰어넘을 수 없다.
• 지속적으로 가져올 수 있는지, 혹은 접근 반응등을 살펴보고 싶다면 AFS를 마운트 후 mplayer 와 같은 미디어 플레이어로 재생 능력을 테스트해보길 권장한다. bonnie++ 과 dd로는 알 수 없는 사항들을 몸소 느낄 수 있을것이다. 이 때도 역시, 캐시로 인해 정확한 판단이 불가능 할 수 있으므로, 파일을 먼저 AFS로 전송 후 AFS 클라이언트를 중지, 이후 캐시를 지우고 openafs-client 를 재시작하여 테스트 할 것을 권장한다.

JAFS (Java API for AFS) 에 대하여

기본적으로 GentooLinux 에서나, 다른 배포판에서나 Java API (JNI로 만들어진) 패키지를 따로 찾을 수가 없다는 것이다. 하지만 존재한다: 소스를 풀어보고, ./configure 를 실행하라. 그리고, make jafs 를 하면 jafs 라이브러리가 생성될 것이다.

이때, 되도록이면 openafs를 emerge 할 때 갖가지 configure 설정을 그대로 유지하도록 하라. 그냥 ./configure 로 openafs를 구성하면, 각 배포판에서의 sysconfdir 같은 옵션으로 인해 openafs의 설정파일 위치가 다르기 때문에 토큰을 받아오는 가장 기본적인 API 사용도 불가능하게 될 수 있다. (Cell Database를 못찾는다던지...)

참고할만한, 그리고 이 문서를 작성하는데 도움을 준 문서들

• OpenAFS 공식 Document
• AFS Frequently Asked Questions
• ACM@UUIC Wiki : Setting up your computer as an afs clients
• Captains Universe : OpenAFS on Solaris 9 x86