# 관리 안내서

# 서버 시스템 관리

이 장에서는 AFS 서버 시스템을 관리하는 방법을 설명합니다. 또한 다음의 구성 정보와 관리 타스크에 대해서도 설명합니다.

- 모든 서버 시스템의 로컬 디스크에 있는 /usr/afs 디렉토리의 하위 디렉토리에 위치해야 하는 2진 및 구성 파일. 서버 시스템의 로컬 디스크 파일을 참조하십시오.
- AFS 서버 시스템이 수행할 수 있는 다양한 역할 또는 기능 및 어떤 시스템이 역할을 수행하고 있는지 확인하는 방법. 파일 서버 시스템의 네 가지 역할을 참조하십시오.
- 데이터베이스 서버 시스템 유지 방법. 데이터베이스 서버 시스템 관리를 참조하십시오.
- /usr/afs/etc/CellServDB 파일에 데이터베이스 서버 시스템 목록을 유지하는 방법. 서버 CellServDB 파일 유지를 참조하십시오.
- 서버 시스템에 대한 권한 확인을 제어하는 방법. 인증 관리 및 권한 부여 요구조건을 참조하십시오.
- 파일 서버 시스템에 새 디스크나 파티션을 설치하는 방법. 디스크 및 파티션 추가 또는 제거를 참조하십시오.
- 서버 시스템의 IP 주소를 변경하고 VLDB 서버 항목을 관리하는 방법. 서버 IP 주소 및 VLDB 서버 항목 관리를 참조하십시오.
- 파일 서버 시스템을 재부팅하는 방법. 서버 시스템 재부팅을 참조하십시오.

새 서버 시스템을 설치하고 구성하는 방법을 보려면 AFS 빠른 시작을 참조하십시오.

서버가 프로세스 자체를 관리하는 방법을 알려면 서버 프로세스 모니터 및 제어를 참조하십시오.

볼륨을 관리하는 방법을 알려면 볼륨 관리를 참조하십시오.

## 명령어(instruction) 요약

이 장에서는 지정된 명령을 사용하여 다음 타스크를 수행하는 방법을 설명합니다.

새 2진 파일 설치 | bos install
2진 파일 확인 후 재시작 시간 검토 | bos getrestart
2진 파일 확인 후 재시작 시간 설정 | bos setrestart
2진 파일에 대한 컴파일 날짜 검토 | bos getdate
새 2진 파일을 사용하기 위한 프로세스 재시작 | bos restart
이전 버전의 2진 파일로 복귀 | bos uninstall
이전 .BAK 및 .OLD 버전 제거 | bos prune
파일 서버 시스템의 파티션 나열 | vos listpart
AFS 서버 프로세스 종료 | bos shutdown
파티션의 볼륨 나열 | vos listvldb
읽기/쓰기 볼륨 이동 | vos move
셀의 데이터베이스 서버 시스템 나열 | bos listhosts
CellServDB 파일에 데이터베이스 서버 시스템 추가 | bos addhost
서버 CellServDB 파일에서 데이터베이스 서버 시스템 제거 | bos removehost
권한 확인 요구조건 설정 | bos setauth
bos, pts 및 vos 명령에 대한 인증 방지 | -noauth 플래그 포함
kas 명령에 대한 인증 방지 | 일부 명령에 -noauth 플래그 포함 또는 대화식 모드에서 noauthentication 실행
모든 VLDB 서버 항목 표시 | vos listaddrs
VLDB 서버 항목 제거 | vos changeaddr
원격에서 서버 시스템 원격 재부트 | bos exec reboot_command

## 서버 시스템의 로컬 디스크 파일

일부 유형의 파일은 AFS 서버 시스템의 로컬 디스크에 있는 /usr/afs 디렉토리의 하위 디렉토리에 위치해야 합니다. 여기에는 2진 파일, 구성 파일, 관리 데이터베이스 파일(데이터베이스 서버 시스템에 있는), 로그 파일 및 볼륨 헤더 파일이 포함됩니다.

Windows 사용자를 위한 주의사항: 이 문서에서 설명하는 일부 파일은 Windows 운영 체제가 실행되는 시스템에는 없을 수 있습니다. 또한 Windows에서는 경로 이름의 요소를 분리하기 위해 역슬래쉬( \ )를 슬래쉬( / ) 대신 사용합니다.

### /usr/afs/bin 디렉토리의 2진 파일

/usr/afs/bin 디렉토리는 시스템(CPU 및 운영 체제) 유형에 적절한 AFS 서버 프로세스 및 명령 집합 2진 파일을 저장합니다. 프로세스에 서버 부분과 클라이언트 부분이 모두 있는 경우(갱신 서버의 경우와 유사) 또는 별도의 구성요소를 가지는 경우(fs 프로세스의 경우와 유사) 각 구성요소는 별도의 파일에 위치합니다.

예측 가능한 시스템 성능을 보장하기 위해 모든 파일 서버 시스템은 주어진 프로세스의 동일한 AFS 빌드 버전을 실행해야 합니다. 일관성을 유지하기 위해 2진 분산 시스템에서 설명하는 것처럼 갱신 서버 프로세스를 사용하여 각 시스템 유형의 2진 분산 시스템으로부터 2진 파일을 분배하십시오.

시스템에서 능동적으로 프로세스를 실행하지 않는 경우에도 /usr/afs/bin 디렉토리에 모든 프로세스에 대한 2진 파일을 보관하는 것이 좋습니다. 이렇게 하면 시스템을 재구성하는 프로세스가 단순해 집니다(예를 들어 기존 파일 서버 시스템에 데이터베이스 서버 기능을 추가). 이와 마찬가지로 서버 시스템에서 작업하는 동안 명령을 자주 실행하지 않는 경우에도 디렉토리에 명령 집합 2진 파일을 보관하는 것이 바람직합니다. 이렇게 하면 서버 및 시스템으로부터의 복구 작업 중에 명령을 실행할 수 있습니다.

다음은 AFS 서버 프로세스 또는 명령 집합과 직접 관련되어 있는 /usr/afs/bin 디렉토리의 2진 파일을 나열합니다. 다른 2진 파일(예: klog 명령 관련)은 특정 파일 서버 시스템의 디스크나 AFS 분산의 해당 디렉토리에 나타날 수 있습니다.

backup
  AFS 백업 시스템에 대한 명령 집합 (백업 서버에 대한 2진 파일은 buserver임).

bos
  기본 OverSeer(BOS) 서버와의 통신을 위한 명령 집합(BOS 서버에 대한 2진 파일은 bosserver임).

bosserver
  기본 OverSeer (BOS) 서버 프로세스에 대한 2진 파일.

buserver
  백업 서버 프로세스에 대한 2진 파일.

fileserver
  fs 프로세스의 파일 서버 구성요소에 대한 2진 파일.

kas
  인증 서버와의 통신을 위한 명령 집합(인증 서버에 대한 2진 파일은 kaserver임).

kaserver
  인증 서버 프로세스에 대한 2진 파일.

ntpd
  NTPD(Network Time Protocol Daemon)에 대한 2진 파일. AFS는 이 2진 파일을 재분배하고 runntp 프로그램을 사용하여 NTPD 프로세스를 구성하고 초기화합니다.

ntpdc
  ntpd 프로그램과 함께 제공되는 디버깅 유틸리티.

pts
  보호 서버 프로세스와의 통신을 위한 명령 집합(보호 서버에 대한 2진 파일은 ptserver임).

ptserver
  보호 서버 프로세스에 대한 2진 파일.

runntp
  AFS에서 사용할 수 있도록 가장 적절하게 NTPD를 구성하는 데 사용되는 프로그램에 대한 2진 파일.

salvager
  fs 프로세스의 구조 프로그램 구성요소에 대한 2진 파일.

udebug
  AFS의 분산 데이터베이스 기술인 Ubik의 상태를 보고하는 프로그램에 대한 2진 파일.

upclient
  갱신 서버 프로세스의 클라이언트 부분에 대한 2진 파일.

upserver
  갱신 서버 프로세스의 서버 부분에 대한 2진 파일.

vlserver
  볼륨 위치(VL) 서버 프로세스에 대한 2진 파일.

volserver
  fs 프로세스의 볼륨 서버 구성요소에 대한 2진 파일.

vos
  볼륨 및 VL 서버 프로세스와의 통신을 위한 명령 집합(서버에 대한 2진 파일은 각각 volserver와 vlserver임).

### /usr/afs/etc 디렉토리의 일반 구성 파일

모든 파일 서버 시스템의 로컬 디스크에 있는 디렉토리 /usr/afs/etc에는 구성 파일이 ASCII 및 시스템 독립 2진 형식으로 포함되어 있습니다. 셀 전체에서 AFS 성능을 예측할 수 있으려면 다음과 같이 모든 서버 시스템이 각 구성 파일의 동일한 버전을 포함해야 합니다.

- 미국판 AFS가 실행되는 셀은 보통 갱신 서버를 사용하여 셀의 시스템 제어 시스템으로부터 각 파일의 공통 버전을 다른 서버 시스템으로 분배합니다. (시스템 제어 시스템에 대하여 자세히 알고 싶으면 시스템 제어 시스템을 참조하십시오.) 시스템 제어 시스템에서 갱신 서버의 서버 부분을 실행하고 다른 모든 서버 시스템에서 클라이언트 부분을 실행하십시오. 긴급한 상황에 대한 다른 지침이 있는 경우를 제외하고 시스템 제어 시스템에서만 파일을 갱신하십시오.
- 각국 언어판 AFS가 실행되는 셀은 갱신 서버를 사용하여 /usr/afs/etc 디렉토리의 내용을 분배하면 안됩니다. 미국 정부의 규정에 의해 이 디렉토리의 파일이 네트워크를 통과할 때 이들 파일을 보호하기 위해 AFS에서 사용하는 데이터 암호화 루틴을 각국 언어판 AFS의 갱신 서버에서는 사용할 수 없습니다. 대신 각 서버 시스템에서 개별적으로 파일을 갱신하고 주의해서 각 시스템에 대해 동일한 bos 명령을 정확히 실행해야 합니다. 이 필수 데이터 암호화 루틴은 bos 명령에 대해 사용할 수 있으므로 bos 명령이 실행되는 시스템에서 서버 시스템까지 네트워크를 통해 정보가 전달될 때 안전하게 전달됩니다.

긴급한 상황에 대한 다른 지침이 있는 경우를 제외하고 /usr/afs/etc 디렉토리의 파일을 직접 편집하지 마십시오. 일반적인 상황에서는 적절한 bos 명령을 사용하여 파일을 변경하십시오. 다음 목록에는 명령어(instruction)로의 포인터가 들어 있습니다.

이 디렉토리의 파일에는 다음이 포함됩니다.

CellServDB
  인증, 백업, 보호 및 VL 서버 프로세스가 실행되는 셀의 데이터베이스 서버 시스템을 명명하는 ASCII 파일. 셀의 첫 번째 서버 시스템을 설치할 때 bos setcellname 명령을 실행하여 이 파일의 초기 버전을 작성하십시오. 셀의 데이터베이스 서버 시스템의 ID를 변경할 때 이 파일을 갱신하는 것이 매우 중요합니다.

  서버 CellServDB 파일은 클라이언트 시스템의 /usr/vice/etc 디렉토리에 있는 CellServDB 파일과 같지 않습니다. 클라이언트 버전 파일은 클라이언트 시스템에서 액세스할 수 있도록 사용자가 선택한 모든 AFS 셀에 대한 데이터베이스 서버 시스템을 나열합니다. 서버 CellServDB 파일은 서버 프로세스가 다른 셀의 프로세스에는 접속하지 않으므로 로컬 셀의 데이터베이스 서버 시스템만 나열합니다.

  이 파일의 유지 관리에 대한 지침을 보려면 서버 CellServDB 파일 유지를 참조하십시오.

KeyFile
  AFS 서버 프로세스가 티켓의 암호화 및 암호 해독에 하용하는 서버 암호화 키를 나열하는 시스템 독립, 2진 형식 파일. 이 파일의 정보는 셀에서의 보안 통신의 토대가 되므로 상당히 중요합니다. 이 파일은 권한 있는 사용자만 읽거나 변경할 수 있도록 특수하게 보호됩니다.

  이 파일의 유지 관리에 대한 지침을 보려면 서버 암호화 키 관리를 참조하십시오.

ThisCell
  셀의 완전한 인터넷 도메인 형식 이름(예: `abc.com`)을 정의하는 단일 행으로 구성된 ASCII 파일. AFS 빠른 시작에서 지시하는 것처럼 셀의 첫 번째 파일 서버 시스템의 설치 중에 bos setcellname 명령을 사용하여 이 파일을 작성하십시오.

  이 파일을 변경하는 것은 셀의 이름을 변경하는 작업의 한 단계에 불과하다는 점을 알아 두십시오. 자세한 설명을 보려면 셀 이름 선택을 참조하십시오.

UserList
  권한 있는 bos, vos 및 backup 명령을 나열할 권한이 있는 시스템 관리자의 사용자 이름을 나열하는 ASCII 파일. 이 파일의 유지 관리에 대한 지침을 보려면 UserList 파일 관리를 참조하십시오.

### /usr/afs/local 디렉토리의 로컬 구성 파일

디렉토리 /usr/afs/local에는 셀의 각 파일 서버 시스템에 대해 각기 다른 구성 파일이 들어 있습니다. 따라서 /usr/afs/bin 및 /usr/afs/etc 디렉토리에 있는 파일과 같이 중앙 소스로부터 자동으로 갱신되지 않습니다. 가장 중요한 파일은 BosConfig 파일로 이 파일은 해당 시스템에서 실행된 서버 프로세스를 정의합니다.

/usr/afs/etc의 일반 구성 파일처럼 이들 파일은 직접 편집하면 안됩니다. 적절한 위치에서 bos 명령 집합의 명령을 사용하십시오. 일부 파일은 절대 변경할 필요가 없습니다.

이 디렉토리의 파일에는 다음이 포함됩니다.

BosConfig
  이 파일은 BOS 서버가 모니터하는 프로세스와 프로세스가 실패할 경우 수행할 작업을 정의하여 서버 시스템에서 실행할 서버 프로세스를 나열합니다. 또한 BOS 서버가 유지 목적으로 자동으로 프로세스를 재시작하는 시간을 정의합니다.

  파일 서버 시스템의 설치 중에 서버 프로세스를 작성할 때 관련 항목은 이 파일에 자동으로 정의됩니다. AFS 빠른 시작에서는 사용할 bos 명령을 대략적으로 설명합니다. 파일에 대한 자세한 설명과 bos 집합의 명령을 사용하여 파일을 편집하여 프로세스 상태를 제어하는 방법에 대해서는 서버 프로세스 모니터 및 제어를 참조하십시오.

NetInfo
  이 선택적 ASCII 파일은 서버 시스템에 있는 하나 이상의 네트워크 인터페이스 주소를 나열합니다. 파일 서버가 초기화될 때 이 파일이 존재한 경우 파일 서버는 VLDB(Location Database) 서버 항목에 등록한 인터페이스 목록의 기반으로서 이 파일을 사용합니다. 서버 IP 주소 및 VLDB 서버 항목 관리를 참조하십시오.

NetRestrict
  이 선택적 ASCII 파일은 하나 이상의 네트워크 인터페이스 주소를 나열합니다. 파일 서버가 초기화될 때 이 파일이 존재한 경우 파일 서버는 VLDB 서버 항목에 등록한 인터페이스 목록에서 지정된 주소를 제거합니다. 서버 IP 주소 및 VLDB 서버 항목 관리를 참조하십시오.

NoAuth
  이 크기가 0인 파일은 시스템에서 실행되는 모든 AFS 서버 프로세스에게 권한 확인을 수행하지 않도록 지시합니다. 따라서 anonymous 사용자인 경우에도 사용자를 위해 어떠한 작업도 수행하지 않습니다. 이와 같은 비보안 상태는 시스템 설치 중과 같이 드문 경우에만 유용합니다.

  이 파일은 초기 bosserver 프로세스를 -noauth 플래그와 함께 시작하거나 bos setauth 명령을 실행하여 인증 요구조건을 해제할 때 자동으로 작성됩니다. bos setauth 명령을 사용하여 인증을 사용 가능하게 할 때 BOS 서버가 이 파일을 제거합니다. 자세한 내용은 인증 관리 및 권한 부여 요구조건을 참조하십시오

SALVAGE.fs
  이 크기가 0인 파일은 BOS 서버가 fs 프로세스의 파일 서버 구성요소의 작동 중지 상태를 처리하는 방법을 제어합니다. BOS 서버는 fs 프로세스를 시작하거나 재시작할 때마다 이 파일을 작성합니다. 파일 서버가 작동 중지되었을 때 이 파일이 존재하면 BOS 서버는 파일 서버 및 볼륨 서버를 다시 시작하기 전에 구조 프로그램을 실행합니다. 파일 서버가 정상적으로 종료되면 BOS 서버는 구조 프로그램이 실행되지 않도록 이 파일을 제거합니다.

  이 파일을 직접 작성하거나 제거하지 마십시오. BOS 서버는 자동으로 작성되거나 제거됩니다. 필요하면 bos salvage 명령을 사용하여 볼륨이나 파티션을 구조할 수 있습니다. 볼륨 구조를 참조하십시오.

salvage.lock
  이 파일은 한 번에 하나의 구조 프로그램만 파일 서버에서 실행되게 합니다(단일 프로세스에서 복수의 하위 프로세스로 분기되어 동시에 여러 파티션을 구조할 수 있습니다). 구조 프로그램은 초기화될 때 (BOS 서버에 의해 호출되거나 bos salvage 명령의 실행으로 인해) 이 크기가 0인 파일을 작성하고 flock 시스템 호출을 실행합니다. 또한 구조 작업이 끝나면 이 파일을 제거합니다. 구조 프로그램은 실행되기 위해 이 파일을 잠궈야 하므로 한 번에 하나의 구조 프로그램만 실행될 수 있습니다.

sysid
  이 파일은 파일 서버(fileserver 프로세스)가 VLDB 서버 항목에 등록하는 네트워크 인터페이스 주소를 기록합니다. 캐쉬 관리 프로그램이 볼륨 위치 정보를 요청할 때 볼륨 위치(VL) 서버는 해당 볼륨을 포함하는 각 서버 시스템에 대해 등록된 모든 인터페이스를 제공합니다. 이를 통해 캐쉬 관리 프로그램은 다중 홈 파일 서버 시스템에 저장된 AFS 데이터를 액세스할 때 복수의 주소를 활용할 수 있습니다. 자세한 정보를 보려면 서버 IP 주소 및 VLDB 서버 항목 관리를 참조하십시오.

### /usr/afs/db 디렉토리의 복제된 데이터베이스 파일

디렉토리 /usr/afs/db에는 셀의 복제된 네 개의 데이터베이스인 인증 데이터베이스, 백업 데이터베이스, 보호 데이터베이스 및 VLDB(Location Database)와 관련된 두 가지 유형의 파일이 들어 있습니다.

- 각 데이터베이스에 들어 있는 .DB0 확장자를 가진 파일.
- .DBSYS1 확장자를 가진 각 데이터베이스에 대한 로그 파일. 데이터베이스 서버 프로세스는 각 데이터베이스 작업을 수행하기 전에 이 파일에 데이터베이스 작업을 기록합니다. 작업이 중단되면 프로세스는 이 파일을 확인하여 작업을 끝내는 방법을 알아냅니다.

각 데이터베이스 서버 프로세스(인증, 백업, 보호 또는 VL 서버)는 자체의 데이터베이스와 로그 파일을 유지합니다. 데이터베이스 파일은 2진 형식이므로 항상 kas 집합(인증 데이터베이스 관련), backup 집합(백업 데이터베이스 관련), pts 집합(보호 데이터베이스 관련) 또는 vos 집합(VLDB 관련)으로부터 명령을 사용하여 이들을 액세스하거나 변경해야 합니다.

셀에서 둘 이상의 데이터베이스 서버 시스템이 실행되는 경우 각 데이터베이스 서버 프로세스는 시스템의 하드 디스크에 자체의 데이터베이스 사본을 보관합니다. 그러나 주어진 데이터베이스의 모든 사본이 동일해야 합니다. 이들 사본을 동기화하기 위해 데이터베이스 서버 프로세스는 AFS 관리 데이터베이스 복제에서 설명하는 것처럼 AFS의 분산 데이터베이스 기술인 Ubik를 사용합니다.

여기에 나열된 파일은 데이터베이스 서버 시스템의 이 디렉토리에만 나타납니다. 비 데이터베이스 서버 시스템에서는 이 디렉토리가 비어 있습니다.

bdb.DB0
  백업 데이터베이스 파일.

bdb.DBSYS1
  백업 데이터베이스 로그 파일.

kaserver.DB0
  인증 데이터베이스 파일.

kaserver.DBSYS1
  인증 데이터베이스 로그 파일.

prdb.DB0
  보호 데이터베이스 파일.

prdb.DBSYS1
  보호 데이터베이스 로그 파일.

vldb.DB0
  볼륨 위치 데이터베이스 파일.

vldb.DBSYS1
  볼륨 위치 데이터베이스 로그 파일.

### /usr/afs/logs 디렉토리의 로그 파일

/usr/afs/logs 디렉토리에는 다양한 서버 프로세스의 로그 파일이 들어 있습니다. 이 파일은 표준 작업 중에 발생하는 중요한 이벤트를 상세히 설명합니다. 예를 들어 볼륨 서버는 VolserLog 파일에 볼륨 이동을 기록할 수 있습니다. 이벤트는 완료시 기록되므로 서버 프로세스는 /usr/afs/db 디렉토리의 작업과 달리 실패한 작업을 재구성하기 위해 이 파일을 사용하지 않습니다.

로그 파일의 정보는 프로세스 실패 및 다른 문제점을 평가할 때 매우 유용할 수 있습니다. 예를 들어 볼륨을 액세스하려고 할 때 제한시간 메시지를 수신할 경우 FileLog 파일에서 파일 서버가 해당 볼륨을 사용할 수 없음을 보여 주는 설명을 볼 수 있습니다. 원격에서 로그 파일을 검토하려면 서버 프로세스 로그 파일 표시의 설명대로 bos getlog 명령을 사용하십시오.

이 디렉토리에는 BOS 서버에 의해 모니터되는 프로세스가 중단될 경우 생성되는 코어 이미지 파일도 들어 있습니다. BOS 서버는 표준 core 이름에 확장자를 추가하여 프로세스가 생성한 코어 파일을 나타냅니다(예를 들면 보호 서버에서 생성한 코어 파일을 core.ptserver라고 명명). BOS 서버는 두 프로세스가 거의 동시에 실패할 경우 올바른 확장자를 지정할 수 없으므로 올바른지 보장할 수 없습니다.

이 디렉토리는 다음 파일을 포함합니다.

AuthLog
  인증 서버의 로그 파일.

BackupLog
  백업 서버의 로그 파일.

BosLog
  BOS 서버의 로그 파일.

FileLog
  파일 서버의 로그 파일.

SalvageLog
  구조 프로그램의 로그 파일.

VLLog
  볼륨 위치(VL) 서버의 로그 파일.

VolserLog
  볼륨 서버의 로그 파일.

core.process
  있는 경우 중단된 시스템에서 AFS 서버 프로세스(process라고 명명된 프로세스)로서 생성된 코어 이미지 파일.

주: | 로그 파일이 관리할 수 없을 만큼 커지지 않게 하려면 서버 프로세스, 특히 데이터베이스 서버 프로세스를 주기적으로 재시작하십시오. 프로세스가 재시작되지 않게 하려면 UNIX rm 명령을 사용하여 프로세스가 실행될 때 파일을 제거하십시오. 이 파일은 자동으로 재작성됩니다.

### 서버 파티션의 볼륨 헤더

AFS 볼륨을 포함하는 파티션은 시스템의 루트( / ) 디렉토리의 하위 디렉토리(/usr 디렉토리 아래는 아님)에 마운트되어야 합니다. 파일 서버 시스템의 파일 시스템 레지스트리 파일(/etc/fstab 또는 동급)은 디렉토리 이름과 파티션의 장치 이름을 제대로 맵핑해야 합니다. 디렉토리 이름은 양식 /vicepindex를 가지며 여기서 각 index는 하나 또는 둘의 소문자로 구성됩니다. 일반적으로 시스템의 첫째 AFS 파티션은 /vicepa에, 둘째 파티션은 /vicepb에 마운트되며 이와 같은 방식으로 계속 진행됩니다. 26개보다 많은 수의 파티션이 있으면 /vicepaa, /vicepab 등과 같이 계속됩니다. AFS 릴리스 노트에서는 서버 시스템당 지원되는 파티션의 수를 지정합니다.

AFS 파티션에 비 AFS 파일을 저장하지 않도록 하십시오. 파일 서버 및 볼륨 서버는 파티션의 모든 공간을 사용할 수 있습니다.

/vicep 디렉토리에는 다음의 두 가지 유형의 파일이 들어 있습니다.

Vvol_ID.vol
  이러한 파일은 볼륨 헤더입니다. vol_ID는 vos examine, vos listvldb 및 vos listvol 명령으로부터 출력에 표시되는 볼륨 ID 번호에 해당합니다.

FORCESALVAGE
  이 크기가 0인 파일은 구조 프로그램이 전체 파티션을 복원하도록 트리거합니다. fsck 프로그램의 AFS 수정 버전은 손상을 발견한 경우 이 파일을 작성합니다.

주: | 대부분의 시스템 유형에서 AFS 파일 서버 시스템에서 운영 체제에 기본적으로 제공되는 표준 fsck 프로그램을 절대 실행하지 마십시오. 이 프로그램은 AFS 볼륨 형식을 인식하지 못하므로 서버 파티션에서 모든 AFS 볼륨 데이터를 제거합니다.

## 파일 서버 시스템의 네 가지 역할

둘 이상의 서버 시스템이 있는 셀에서 모든 서버 시스템이 정확히 동일한 기능을 수행해야 하는 것은 아닙니다. 실행되는 서버 프로세스에 따라 시스템이 가정할 수 있는 가능한 네 가지 역할이 있습니다. 하나의 시스템은 적절한 모든 프로세스를 실행하여 둘 이상의 역할을 가정할 수 있습니다. 다음 목록은 네 가지 역할을 요약해서 설명하며 이 역할에 대해서는 다음 절에서 좀더 상세히 설명합니다.

- 단순 파일 서버 시스템은 AFS 파일을 클라이언트 시스템에 저장하고 전달하는 프로세스만 실행합니다. 필요한 만큼의 단순 파일 서버 시스템을 실행하여 셀의 성능 및 디스크 공간 요구조건을 충족할 수 있습니다.
- 데이터베이스 서버 시스템은 AFS의 복제 관리 데이터베이스를 유지하는 네 가지 인증, 백업, 보호 및 볼륨 위치(VL) 서버 프로세스를 실행합니다.
- 2진 분산 시스템은 시스템 유형에 대한 AFS 서버 2진 값을 해당 시스템 유형을 가진 다른 모든 서버 시스템에 분배합니다.
- 단일 시스템 제어 시스템은 미국판 AFS가 실행되는 셀의 다른 모든 서버 시스템에 일반적인 서버 구성 파일을 분배합니다(각국 언어판 AFS를 사용하는 셀은 이 목적을 위해 시스템 제어 기계을 사용할 필요가 없음). 이 시스템은 일반적으로 셀의 시간 동기화 소스로 기능하여 셀 외부의 시간 소스에 따라 시계를 조정합니다.

셀에 단일 서버 시스템이 있는 경우 단순 파일 서버 및 데이터베이스 서버 역할을 가정합니다. AFS 빠른 시작의 지시에 따르면 사용자는 시스템을 시스템 제어 시스템 2진 분산 시스템으로 구성하게 되지만 사용자가 다른 서버 시스템을 설치할 때까지 시스템에서 실제로 이러한 기능을 수행하지는 않습니다.

모든 프로세스가 실행되지 않는 경우에도 /usr/afs/bin 디렉토리에 모든 AFS 서버 프로세스에 대한 2진 파일을 보관하는 것이 좋습니다. 그런 다음 단순히 역할을 정의하는 프로세스를 시작하거나 정지하여 시스템이 가정하는 역할을 변경할 수 있습니다.

### 단순 파일 서버 시스템

단순 파일 서버 시스템은 클라이언트 시스템에 AFS 파일을 저장 및 전달하고, 프로세스 상태를 모니터하고, 셀의 2진 분산 및 시스템 제어 시스템으로부터 2진 및 구성 파일을 선택하는 서버 프로세스만 실행합니다.

일반적으로 네 대 이상의 서버 시스템이 있는 셀에서만 단순 파일 서버 시스템을 실행할 필요가 있습니다. 세 대 이하의 시스템이 있는 셀에서는 모든 서버 시스템이 보통 데이터베이스 서버 시스템이 됩니다(관리 데이터베이스를 복제하여 이점을 얻을 수 있음). 데이터베이스 서버 시스템을 참조하십시오.

다음 프로세스는 단순 파일 서버 시스템에서 실행됩니다.

- BOS 서버(bosserver 프로세스)
- fs 프로세스: 파일 서버, 볼륨 서버 및 구조 프로그램 프로세스를 조합하여 이들이 볼륨의 데이터에 대한 작업을 통합하고 동일한 데이터에 대해 수행되는 복수의 동시 작업으로부터 발생할 수 있는 불일치를 피할 수 있게 합니다.
- NTP 조정자(runntp 프로세스): 시스템의 시계가 셀의 다른 서버 시스템의 시계와 동기화 상태를 유지하는 데 도움을 줍니다.
- AFS 시스템 유형의 2진 분산 시스템으로부터 2진 파일을 선택하는 갱신 서버의 클라이언트 부분(upclientbin 프로세스)
- 미국판 AFS가 실행되는 셀의 시스템 제어 시스템으로부터 일반 구성 파일을 선택하는 갱신 서버의 클라이언트 부분(upclientetc 프로세스)

### 데이터베이스 서버 시스템

데이터베이스 서버 시스템은 각각 인증 데이터베이스, 백업 데이터베이스, 보호 데이터베이스 및 VLDB(Location Database)를 유지하는 인증 서버, 백업 서버, 보호 서버 및 볼륨 위치(VL) 서버의 AFS 복제 관리 데이터베이스를 유지하는 네 가지 프로세스를 실행합니다. 이들 서버 프로세스 및 그 데이터베이스의 기능을 살펴보려면 AFS 서버 프로세스 및 캐쉬 관리 프로그램을 참조하십시오.

셀에 두 대 이상의 서버 시스템이 있는 경우 둘 이상의 데이터베이스 서버 시스템을 실행하는 것이 가장 좋으나 네 대 이상의 시스템은 거의 필요하지 않습니다. 이러한 방식으로 데이터베이스를 복제하면 사용 효율 및 정보의 신뢰성 증가와 같이 볼륨을 복제하는 것과 동일한 이점을 얻을 수 있습니다. 한 데이터베이스 서버 시스템이나 프로세스가 기능을 중단해도 해당 데이터베이스의 정보를 계속 사용할 수 있습니다. 데이터베이스 정보 요청에 따른 작업 부하는 여러 시스템에 분산되므로 한 시스템이 과부하되는 일이 없습니다.

그러나 복제된 데이터베이스는 복제된 볼륨과는 달리 자주 변경됩니다. 일관된 시스템 성능을 발휘하기 위해서는 모든 사본의 데이터베이스가 항상 동일해야 하므로 사본 중 일부만 변경 내용을 기록할 수 있습니다. 데이터베이스 사본을 동기화하기 위해 데이터베이스 서버 프로세스는 AFS의 분산 데이터베이스 기술인 Ubik를 사용합니다. AFS 관리 데이터베이스 복제를 참조하십시오.

셀에 있는 모든 서버 시스템의 AFS 서버 프로세스가 어떤 시스템이 데이터베이스 서버 시스템인지 인식하는 것은 중요합니다. 데이터베이스 서버 프로세스는 특히 데이터베이스 사본을 통합하기 위해 피어와 계속적으로 접속을 유지해야 합니다. 다른 서버 프로세스는 종종 데이터베이스의 정보를 필요로 합니다. 모든 파일 서버 시스템은 로컬 /usr/afs/etc/CellServDB 파일에 셀의 데이터베이스 서버 시스템 목록을 유지합니다. 미국판 AFS를 사용하는 셀은 시스템 제어 시스템을 사용하여 이 파일을 분배할 수 있습니다 (시스템 제어 시스템 참고).

다음 프로세스는 데이터베이스 서버 시스템을 정의합니다.

- 인증 서버 (kaserver 프로세스)
- 백업 서버 (buserver 프로세스)
- 보호 서버 (ptserver 프로세스)
- VL 서버 (vlserver 프로세스)

데이터베이스 서버 시스템은 단순 파일 서버 시스템에 나열된 것처럼 단순 파일 서버 시스템을 정의하는 프로세스도 실행할 수 있습니다. 하나의 데이터베이스 서버 시스템은 셀의 시스템 제어 시스템으로 작동할 수 있으며 다른 데이터베이스 서버 시스템은 시스템 유형에 대한 2진 분산 시스템으로 작동할 수 있습니다. 시스템 제어 시스템 및 2진 분산 시스템을 참조하십시오.

### 2진 분산 시스템

2진 분산 시스템은 AFS 프로세스 및 명령 집합에 대한 2진 파일을 저장하고 해당 시스템 유형의 다른 모든 서버 시스템에 분배합니다. 각 파일 서버 시스템은 보통 로컬 디스크의 /usr/afs/bin 디렉토리에 AFS 서버 프로세스 2진 파일의 사본을 보관합니다. 그러나 일관된 시스템 성능을 위해 모든 서버 시스템은 동일한 버전(빌드 레벨)의 프로세스를 실행해야 합니다. 2진 파일 빌드 레벨 검사 지침을 보려면 2진 파일의 빌드 레벨 표시를 참조하십시오. 2진 파일을 일관된 상태로 보관하는 가장 쉬운 방법은 각 시스템 유형의 2진 분산 시스템이 이들 파일을 시스템 유형 피어에 분배하게 하는 것입니다.

2진 분산 시스템을 정의하는 프로세스는 갱신 서버의 서버 부분입니다(upserver 프로세스). 갱신 서버의 클라이언트 부분(upclientbin 프로세스)은 해당 시스템 유형을 가진 다른 서버 시스템에서 실행되고 2진 분산 시스템을 참조합니다.

2진 분산 시스템은 보통 단순 파일 서버 시스템에 나열된 것처럼 단순 파일 서버 시스템을 정의하는 프로세스도 실행할 수 있습니다. 하나의 2진 분산 시스템은 셀의 시스템 제어 시스템으로 작동할 수 있으며 다른 2진 분산 시스템은 데이터베이스 서버 시스템으로 작동할 수 있습니다. 시스템 제어 시스템 및 데이터베이스 서버 시스템을 참조하십시오.

### 시스템 제어 시스템

미국판 AFS를 실행하는 셀에서 시스템 제어 시스템은 셀의 모든 서버 시스템에서 공유하는 시스템 구성 파일을 저장하고 분배합니다. 각 파일 서버 시스템은 보통 로컬 디스크의 /usr/afs/etc 디렉토리에 구성 파일 사본을 보관합니다. 그러나 일관된 시스템 성능을 위해 모든 서버 시스템은 동일한 파일을 사용해야 합니다. 이들 파일을 일관된 상태로 유지하는 가장 쉬운 방법은 시스템 제어 시스템이 이들 파일을 분배하게 하는 것입니다. 이 문서의 지침에 따라 시스템 제어 시스템에 저장된 사본만 변경하도록 하십시오. 미국판 AFS는 미국 및 캐나다의 셀과 미국 정부 규정에 따라 다른 국가의 선택된 기관에서 사용할 수 있습니다.

각국 언어판 AFS가 실행되는 셀은 시스템 구성 파일을 분배하기 위해 시스템 제어 시스템을 사용하지 않습니다. 일부 파일은 너무 중요한 정보가 담겨 있어서 암호화되지 않은 상태에서 네트워크로 전달될 수 없으며 미국 정부 법규에 따라 갱신 서버가 사용하는 양식으로 필요한 암호화 루틴의 해외 반출이 금지되어 있습니다. 대신 개별적으로 각 파일 서버 시스템의 구성 파일을 갱신해야 합니다. 구성 파일을 갱신하는 데 사용하는 bos 명령은 해외 반출이 가능한 형태의 암호화 루틴을 사용하여 정보를 암호화합니다.

/usr/afs/etc 디렉토리에 저장된 구성 파일 목록을 보려면 /usr/afs/etc 디렉토리의 일반 구성 파일을 참조하십시오.

AFS 빠른 시작에서는 시스템 구성 기계로서 셀의 첫째 서버 시스템을 구성합니다. 원하는 경우 나중에 설치하는 다른 시스템으로 그 역할을 재지정할 수 있으나 이 경우 새로운 시스템 제어 시스템을 참조하도록 다른 모든 서버 시스템에서 실행되는 갱신 서버 (upclientetc) 프로세스의 클라이언트 부분을 변경해야 합니다.

다음 프로세스는 시스템 제어 시스템을 정의합니다.

- 미국판 AFS를 사용하는 셀에서 갱신 서버(upserver) 프로세스의 서버 부분. 갱신 서버의 클라이언트 부분(upclientetc 프로세스)은 다른 서버 시스템에서 실행되며 해당 시스템 제어 시스템을 참조합니다.
- 셀에서 NTPD를 사용하여 시계를 동기화하는 경우 셀 외부의 시간 소스를 가리키는 NTP 조정자(runntp 프로세스). 다른 시스템의 runntp 프로세스는 기본 시간 소스로서 시스템 제어 시스템을 참조합니다.

시스템 제어 시스템은 단순 파일 서버 시스템에 나열된 것처럼 단순 파일 서버 시스템을 정의하는 프로세스도 실행할 수 있습니다. 이 기계는 데이터베이스 서버 시스템으로 작동하며 일반적으로 해당 시스템 유형에 대한 2진 분산 시스템으로 작동합니다. 단일 upserver 프로세스는 구성 파일과 2진 파일을 모두 분배할 수 있습니다. 데이터베이스 서버 시스템 및 2진 분산 시스템을 참조하십시오.

### 데이터베이스 서버 시스템을 찾으려면

1. bos listhosts 명령을 실행합니다.

          %
       bos listhosts <machine name>

   출력 결과에 나열된 시스템은 셀의 데이터베이스 서버 시스템입니다. 자세한 지침과 예제 출력 결과를 보려면 셀의 데이터베이스 서버 시스템을 표시하려면을 참조하십시오.

2. (선택적) bos status 명령을 실행하여 bos listhosts 명령의 출력에 나열된 시스템이 해당 시스템을 데이터베이스 서버 시스템으로 정의하는 프로세스를 실제로 실행하고 있는지 확인합니다. 자세한 설명을 보려면 프로세스 상태와 BosConfig 파일의 정보 표시하기를 참조하십시오.

          % bos status <machine name>
       buserver kaserver ptserver vlserver

   지정된 시스템이 데이터베이스 서버 시스템이면 bos status 명령의 출력 결과에는 다음 행이 포함됩니다.

          Instance buserver, currently running normally.
          Instance kaserver, currently running normally.
          Instance ptserver, currently running normally.
          Instance vlserver, currently running normally.

### 시스템 제어 시스템을 찾으려면

1. 서버 시스템에 대해 bos status 명령을 실행합니다. 프로세스 상태와 BosConfig 파일의 정보 표시하기에 나타난 지시를 따르십시오.

          % bos status <machine name> upserver upclientbin upclientetc -long

   화면에 표시되는 출력은 단순 파일 서버 시스템, 시스템 제어 시스템 또는 2진 분산 시스템 등과 같이 사용자가 접속하고 있는 시스템에 따라 달라집니다. bos status 명령으로부터 출력 해석을 참조하십시오.

### 시스템 유형에 대한 2진 분산 시스템을 찾으려면

1. 확인 중인 시스템 유형의 파일 서버 시스템에 대해 bos status 명령을 실행합니다. (기계의 시스템 유형을 확인하려면 시스템 유형 이름 표시 및 설정에서 설명하는 것처럼 fs sysname 또는 sys 명령을 실행합니다.) bos status 명령에 대한 자세한 설명은 프로세스 상태와 BosConfig 파일의 정보 표시하기에 나와 있습니다.

          % bos status <machine name>
       upserver upclientbin upclientetc -long

   화면에 표시되는 출력은 단순 파일 서버 시스템, 시스템 제어 시스템 또는 2진 분산 시스템 등과 같이 사용자가 접속하고 있는 시스템에 따라 달라집니다. bos status 명령으로부터 출력 해석을 참조하십시오.

### bos status 명령으로부터 출력 해석

bos status 명령의 출력을 해석하는 것은 단순 파일 서버 시스템에서 가장 간단한 작업입니다. upserver 프로세스가 없으므로 출력에는 다음 메시지가 포함됩니다.

       bos: failed to get instance info for 'upserver' (no such entity)

단순 파일 서버 시스템은 upclientbin 프로세스를 실행하므로 출력에는 다음과 같은 메시지가 포함됩니다. 이것은 fs7.abc.com이 해당 시스템 유형에 대한 2진 분산 시스템임을 나타냅니다.

       Instance upclientbin, (type is simple) currently running normally.
       Process last started at Wed Mar 10  23:37:09 1999 (1 proc start)
       Command 1 is '/usr/afs/bin/upclient fs7.abc.com -t 60 /usr/afs/bin'

미국판 AFS를 실행하는 경우 단순 파일 서버 시스템은 upclientetc 프로세스를 실행하므로 출력에는 다음과 같은 메시지가 포함됩니다. 이것은 fs1.abc.com이 시스템 제어 시스템임을 나타냅니다.

       Instance upclientetc, (type is simple) currently running normally.
       Process last started at Mon Mar 22  05:23:49 1999 (1 proc start)
       Command 1 is '/usr/afs/bin/upclient fs1.abc.com -t 60 /usr/afs/etc'

#### 시스템 제어 시스템의 출력

미국판 AFS를 실행하고 있으며 시스템 제어 시스템에 대해 bos status 명령을 실행한 경우 출력에는 다음과 유사한 upserver 프로세스에 대한 항목이 포함됩니다.

    Instance upserver, (type is simple) currently running normally.
       Process last started at Mon Mar 22 05:23:54 1999 (1 proc start)
       Command 1 is '/usr/afs/bin/upserver'

AFS 빠른 시작에서 권장하는 기본 구성을 사용하는 경우 시스템 제어 시스템 역시 시스템 유형에 대한 2진 분산 시스템이 되고 단일 upserver 프로세스가 두 가지 유형의 갱신 내용을 모두 분배합니다. 이 경우 출력에는 다음 메시지가 포함됩니다.

       bos: failed to get instance info for 'upclientbin' (no such entity)
       bos: failed to get instance info for 'upclientetc' (no such entity)

시스템 제어 시스템이 2진 분산 시스템이 아닌 경우 출력에는 upclientetc 프로세스에 대한 오류 메시지가 포함되지만 upclientbin 프로세스에 대해서는 완전한 목록이 포함됩니다(이 경우 시스템 fs5.abc.com을 2진 분산 시스템으로 참조함).

       Instance upclientbin, (type is simple) currently running normally.
       Process last started at Mon Mar 22  05:23:49 1999 (1 proc start)
       Command 1 is '/usr/afs/bin/upclient fs5.abc.com -t 60 /usr/afs/bin'
       bos: failed to get instance info for 'upclientetc' (no such entity)

#### 2진 분산 시스템의 출력

2진 분산 시스템에 대해 bos status 명령을 실행한 경우 출력에는 다음과 유사한 upserver 프로세스에 대한 항목이 포함되며 upclientbin 프로세스에 대한 오류 메시지가 포함됩니다.

    Instance upserver, (type is simple) currently running normally.
       Process last started at Mon Apr 5 05:23:54 1999 (1 proc start)
       Command 1 is '/usr/afs/bin/upserver'
       bos: failed to get instance info for 'upclientbin' (no such entity)

이 시스템이 우연히 시스템 제어 시스템이 되지 않는 한 다음과 같은 메시지는 시스템 제어 시스템을 참조합니다(이 경우 fs3.abc.com).

       Instance upclientetc, (type is simple) currently running normally.
       Process last started at Mon Apr 5 05:23:49 1999 (1 proc start)
       Command 1 is '/usr/afs/bin/upclient fs3.abc.com -t 60 /usr/afs/etc'

## 데이터베이스 서버 시스템 관리

이 절에서는 데이터베이스 서버 시스템을 관리하는 방법을 설명합니다. 설치 지침에 대해서는 AFS 빠른 시작을 참조하십시오.

### AFS 관리 데이터베이스 복제

AFS 관리 데이터베이스 복제에서 설명하는 것처럼 AFS 관리 데이터베이스(인증, 백업, 보호 및 볼륨 위치 데이터베이스)를 복제할 경우 몇 가지 이점이 있습니다. 셀이 올바르게 기능하기 위해서는 각 데이터베이스 사본이 항상 동일해야 합니다. 데이터베이스를 동기 상태로 유지하기 위해 AFS는 Ubik라는 유틸리티 라이브러리를 사용합니다. 각 데이터베이스 서버 프로세스는 연관된 경량급 Ubik 프로세스를 사용하고 클라이언트측 프로그램은 데이터베이스를 읽고 변경하기 위한 요청을 제출할 때 Ubik의 클라이언트측 서브루틴을 호출합니다.

Ubik는 적절한 Ubik 작업을 위한 셀 구성에서 자세히 설명하는 것처럼 최소의 관리자 개입으로도 작동될 수 있도록 고안되었으나 몇 가지 구성 요구조건이 적용됩니다. 다음에 나오는 Ubik 작업에 대한 간단한 개요는 이러한 요구조건을 이해하는 데 도움이 될 것입니다. 자세한 정보를 보려면 Ubik가 자동으로 작동되는 방식을 참조하십시오.

Ubik는 AFS 관리 데이터베이스에 대해 수행된 변경사항을 가능한 빨리 모든 사본으로 분배하도록 고안되었습니다. 동기화 사이트인 하나의 데이터베이스 사본만 클라이언트의 변경 요청을 승인합니다. 여기에서 실행되는 가벼운 Ubik 프로세스는 Ubik 조정자입니다. 최대 사용 효율을 유지하기 위해 각 데이터베이스에 대해 별도의 Ubik 조정자가 있으며 네 개의 각 데이터베이스에 대한 동기화 사이트는 다른 시스템에 위치할 수 있습니다. 데이터베이스의 동기화 사이트는 프로세스, 시스템 또는 네트워크 작동 중지가 발생할 때 다른 시스템으로 이동될 수 있습니다.

데이터베이스의 다른 사본 및 이들을 유지하는 Ubik 프로세스를 보조라고 합니다. 보조 사이트는 동기화 사이트를 제외하고 클라이언트측 프로그램으로부터의 직접적인 데이터베이스 변경을 승인하지 않습니다.

Ubik 조정자는 데이터베이스 사본에 변경 사항을 기록한 후에 즉시 변경 사항을 보조 사이트로 보냅니다. 짧은 분배 기간 동안 클라이언트는 데이터베이스 사본을 액세스할 수 없으며 읽는 것도 불가능합니다. 조정자가 대부분의 보조 사이트에 도달할 수 없으면 분배를 멈추고 시도된 변경이 실패했다는 사실을 클라이언트에게 알립니다.

분배 실패를 피하기 위해 Ubik 프로세스는 시간 소인 메시지를 교환하여 일정한 접속 상태를 유지합니다. 대부분의 보조 사이트가 조정자의 메시지에 응답하기만 하면 조정자와 동기화되는 사이트 쿼럼이 존재하게 됩니다. 프로세스, 시스템 또는 네트워크 작동 중지로 인해 쿼럼이 깨지면 Ubik 프로세스는 가능한 가장 높은 사이트 수 중에서 새로운 쿼럼을 설정하기 위해 새로운 조정자를 선택하려고 합니다. 융통성 있는 조정자를 통한 사용 효율 증대를 참조하십시오.

#### 적절한 Ubik 작업을 위한 셀 구성

이 절에서는 적절한 Ubik 작업을 유지할 수 있도록 셀을 구성하는 방법을 설명합니다.

- 모든 데이터베이스 서버 시스템에서 네 가지 데이터베이스 서버 프로세스인 인증 서버, 백업 서버, 보호 서버 및 VL 서버 프로세스를 모두 실행하십시오.

  CellServDB 파일에 나열되어 있는 모든 데이터베이스 서버 시스템을 제외하고 Ubik의 클라이언트 및 서버 부분은 모든 데이터베이스 서버 프로세스를 실행하고 있습니다. 일부 데이터베이스 서버 프로세스만 한 시스템에서 실행되고 있음을 나타내기 위한 메카니즘은 없습니다.

- /usr/afs/etc/CellServDB 파일에 항상 올바른 정보를 유지하십시오.

  Ubik는 /usr/afs/etc/CellServDB 파일을 확인하여 쿼럼을 설정 및 유지할 사이트를 결정합니다. 정보가 잘못되면 다양한 시스템의 Ubik 프로세스가 어떤 시스템이 쿼럼에 참여해야 하는지 지정하지 못하므로 여러 시스템 하위 그룹 각각에서 동기화되지 못한 데이터베이스가 존재하거나 조정자가 선택될 수 있습니다.

  미국판 AFS를 실행하고 있으며 갱신 서버를 사용하는 경우 사본을 다른 모든 시스템으로 분배하는 시스템 제어 시스템에 /usr/afs/etc/CellServDB 파일을 유지하는 것이 가장 쉽습니다. AFS 빠른 시작에서는 갱신 서버를 구성하는 방법을 설명합니다. 각국 언어판 AFS를 실행하는 경우 각 시스템에서 개별적으로 파일을 갱신해야 합니다.

  파일을 변경하는 유일한 경우는 데이터베이스 서버 시스템을 구성하거나 중단할 때입니다. 파일을 직접 편집하지 말고 적절한 bos 명령을 사용하십시오. 지침을 보려면 서버 CellServDB 파일 유지를 참조하십시오. 프로세스 정지 및 시작에 대해 서버 프로세스 모니터 및 제어에서 제공하는 지침에 따르면 데이터베이스 서버 시스템의 설치 및 중단에 대한 AFS 빠른 시작의 지침에서처럼 적절한 경우에 CellServDB 파일을 변경하도록 권장합니다.

  (데이터베이스를 유지하지 않는 클라이언트 및 서버 프로세스는 적절한 조작을 위해 CellServDB 파일에 있는 올바른 정보를 사용하지만 이 정보의 사용이 Ubik의 조작에 영향을 미치지는 않습니다. 서버 CellServDB 파일 유지 및 데이터베이스 서버 시스템 정보 유지를 참조하십시오.)

- 셀의 모든 시스템, 특히 데이터베이스 서버 시스템에서 시계를 동기화 상태로 유지하십시오.

  AFS 빠른 시작에 지정된 일반 구성에서 runntp 프로세스를 실행하여 모든 AFS 서버 시스템의 로컬 NTPD(Network Time Protocol Daemon)을 감독하십시오. 시스템 제어 시스템의 NTPD는 그 시계를 셀 외부의 신뢰할만한 소스와 동기화하고 이 시간을 다른 서버 시스템의 NTPD에게 브로드캐스트합니다. 원하는 경우 다른 시간 동기화 프로토콜을 실행하도록 선택할 수 있습니다.

  시계를 동기화 상태로 유지하는 일은 데이터베이스 사이트의 Ubik 프로세스가 계속적인 접속을 유지하기 위해 교환하는 메시지에 시간 소인을 찍기 때문에 중요합니다. 메시지에 시간 소인을 찍는 일은 네트워크로 연결된 환경에서 메시지가 즉시 목적지에 도달할 것으로 가정하기 어려우므로 필요한 일입니다. Ubik는 수신 메시지의 시간 소인을 현재 시간과 비교합니다. 차이가 너무 크면 작동 중지가 발생하여 Ubik 사이트 간의 신뢰성 있는 통신을 막음으로써 동기화되지 못한 데이터베이스 상태가 발생할 수 있습니다. Ubik는 메시지가 유효하지 않은 것으로 간주하며 다른 조정자를 선택하도록 Ubik에 영향을 미칠 수 있습니다.

  새 조정자를 선택하는 일은 시간 소인이 찍힌 메시지가 통신의 실제 중단으로 인해 만기될 경우에는 적절하지만 송신자와 수신자가 동일한 시간을 공유하지 않는 이유만으로 메시지가 만기된 것으로 나타날 경우에는 적절하지 않습니다. 동기화되지 못한 시계가 Ubik 조작을 불안정하게 만들 수 있는 경우에 대한 자세한 예제를 보려면 Ubik에서 시간 소인이 찍힌 메시지를 사용하는 방법을 참조하십시오.

#### Ubik가 자동으로 작동되는 방식

다음 Ubik 기능은 유지 요구조건을 최소로 유지하는 데 도움을 줍니다.

- Ubik의 서버 및 클라이언트 부분이 자동으로 작동합니다.

  각 데이터베이스 서버는 Ubik 라이브러리의 서버 부분을 호출하는 가벼운 프로세스를 실행합니다. 이 가벼운 프로세스 자체를 Ubik로 참조하는 것이 일반적입니다. Ubik 프로세스는 가벼우므로 UNIX ps 명령에 의해 생성된 것과 같은 프로세스 목록에 나타나지 않습니다. 데이터베이스를 읽고 변경해야 하는 클라이언트측 프로그램은 별도의 가벼운 프로세스를 실행하지 않고 Ubik 라이브러리의 클라이언트 부분에서 직접 서브루틴을 호출합니다. 이러한 프로그램의 예로 klog 명령과 pts 집합의 명령을 들 수 있습니다.

- Ubik는 데이터베이스 버전 번호를 추적합니다.

  조정자는 데이터베이스에 대한 변경 사항을 기록할 때 데이터베이스의 버전 번호를 점층적으로 늘립니다. 버전 번호를 사용하면 조정자는 사이트가 가장 최근 버전인지 여부를 쉽게 결정할 수 있습니다. 이 버전 번호는 새 조정자를 선택한 다음에 또는 작동 중지 이후 통신이 복원될 때 정상 작동으로 되돌아가는 속도를 줄여 줍니다. 왜냐하면 어떤 사이트가 가장 현재의 데이터베이스를 가지고 있는지와 어떤 사이트를 갱신해야 하는지를 쉽게 알 수 있기 때문입니다.

- Ubik에서 시간 소인이 찍힌 메시지를 사용한다는 사실은 데이터베이스 사본들이 정상 작동 중이 항상 동기화될 수 있음을 의미합니다.

  데이터 사용 효율을 높이기 위해 데이터베이스를 복제한다는 것은 모든 데이터베이스 사본이 동일하지 않을 경우에는 무의미합니다. 클라이언트가 어떤 데이터베이스 사본을 액세스하는가에 따라 다른 정보를 얻게 된다면 일관되지 못한 성능 결과가 나타날 수 있습니다. 앞서 설명한 것처럼 Ubik 사이트는 시간 소인이 찍힌 메시지를 교환함으로써 피어의 상태를 계속 추적합니다. 자세한 설명을 보려면 Ubik에서 시간 소인이 찍힌 메시지를 사용하는 방법을 참조하십시오.

- 조정자를 이동할 수 있는 능력이 있으면 데이터베이스 사용 효율이 극대화됩니다.

  예를 들어 세 대의 데이터베이스 서버 시스템을 가지는 셀에서 하나의 네트워크 파티션이 조정자로부터 두 개의 보조 사이트를 분리한다고 가정해 봅시다. 이 조정자는 더 이상 CellServDB 파일에 나열되어 있는 대부분의 사이트와 접속되어 있지 않으므로 작동을 멈춥니다. 파티션의 다른 쪽에 있는 두 사이트는 새 조정자를 선택할 수 있으며 클라이언트로부터 데이터베이스 변경 사항을 승인할 수 있습니다. 이 조정자가 이러한 방식으로 작동하지 않으면 네트워크 파티션이 복구될 때까지 데이터베이스는 읽기 전용이어야 합니다. Ubik 선택 절차에 대한 자세한 설명을 보려면 융통성 있는 조정자를 통한 사용 효율 증대를 참조하십시오.

##### Ubik에서 시간 소인이 찍힌 메시지를 사용하는 방법

Ubik는 동기화 사이트 및 보조 사이트 간의 일관된 접속을 유지함으로써 데이터베이스 사본을 동기화합니다. Ubik 조정자는 각 보조 사이트로 시간 소인이 찍힌 보장 메시지를 자주 전송합니다. 보조 사이트는 이 메시지를 받으면 자신이 조정자에게 접속되어 있다는 결론을 내리게 됩니다. 이 사이트는 조정자가 메시지를 전송한 시간으로부터 보통 60초에 해당하는 시간 T가 될 때까지 자신의 데이터베이스 사본을 유효한 것으로 간주합니다. 보조 사이트는 응답으로 보통 120초가 경과된 특정 시간 X가 될 때까지 해당 조정자를 유효한 것으로 인정하는 지지 메시지를 반환합니다.

조정자는 만기 기간이 부분적으로 겹쳐지도록 T 초 간격보다 더 자주 보장 메시지를 전송합니다. 네트워크 파티션이나 다른 작동 중지가 실제로 통신을 중단시키지 않는 한 만기가 발생할 위험은 없습니다. 보장 메시지가 만기될 경우 보조 사이트의 데이터베이스 사본이 반드시 현재 상태인 것은 아닙니다. 그러나 데이터베이스 서버는 계속 클라이언트 요청을 처리합니다. 보조 사이트가 분배하고 있는 정보가 이전 날짜의 정보일 수 있다고 해도 보조 사이트가 계속 액세스 가능 상태를 유지하는 것은 전반적인 셀 기능에 있어서 바람직한 것으로 간주됩니다. 대부분의 AFS 관리 데이터베이스는 사본을 자주 변경하지 않으며 어떤 경우에는 데이터베이스를 액세스할 수 없게 만들 경우 해당 사본을 액세스하게 되는 클라이언트에 제한시간이 적용됩니다.

앞서 언급된 것처럼 Ubik에서 시간 소인이 찍힌 메시지를 사용하는 것은 데이터베이스 서버 시스템의 시계를 동기화하는 작업을 매우 중요하게 만들어 줍니다. 어떤 시계가 다른 시계보다 앞서가고 있는가에 따라 시간이 틀린 시계가 정상적인 Ubik 기능을 어떻게 중단할 수 있는가에 대한 두 가지 설명이 있습니다.

예를 들어 Ubik의 조정자 시계가 보조 사이트의 시계보다 앞서가는 경우, 즉, 조정자의 시계가 9:35:30을 가리키고 보조 사이트의 시계가 9:31:30을 가리킨다고 합시다. 보조 사이트는 9:33:30이 될 때까지 조정자를 유효한 것으로 인정하는 지지 메시지를 보냅니다. 이것은 보조 사이트의 시계에 따르면 2분이 앞선 것이지만 조정자의 관점에서 보면 이미 과거의 시간인 것입니다. 조정자는 더 이상 조정자로 남아 있을 자격이 없다고 결론짓고 새 조정자의 선택을 강제로 실행합니다. 조정자 선택은 데이터베이스 사본이 변경사항을 수용하지 않는 시간인 약 3분 동안 수행됩니다.

그 반대의 가능성은 보조 사이트의 시계(14:50:00)가 조정자의 시계(14:46:30)보다 앞서가는 것입니다. 조정자는 (14:47:30이 될 때까지) 보장 메시지를 전송할 때 보조 사이트의 시계에 따르면 이미 만기된 것입니다. 보조 사이트는 조정자로부터 접속이 끊어졌다고 믿고 조정자를 위해 지지 메시지 전송을 중지하고 스스로 조정자로 선택되려고 시도합니다. 이것은 조정자에 실제로 문제가 발생했을 때는 적절하지만 실제적인 작동 중지가 발생하지 않은 경우에는 부적절합니다.

단일 보조 사이트가 새 조정자로 선택되려는 시도는 보통 다른 사이트의 성능에는 영향을 미치지 않습니다. 그 시계가 조정자의 시계와 일치하는 한 보조 사이트들은 다른 보조 사이트의 지지 요청을 무시하고 현재 조정자에 대한 지지를 계속합니다. 그러나 보조 사이트의 시계가 조정자의 시계보다 앞서가는 경우 현재 조정자가 실제로는 잘 작동되고 있다고 해도 새 조정자의 선택을 강제로 수행할 수 있습니다.

##### 융통성 있는 조정자를 통한 사용 효율 증대

Ubik는 시간 소인이 찍힌 메시지를 사용하여 데이터베이스 사본을 동기화 상태로 유지할 뿐 아니라 조정자 선택이 필요할 때를 결정합니다. 조정자가 사이트 과반수(내재적으로 자신을 지지)로부터 지지 메시지를 받는 한 데이터베이스 변경사항을 분배하고 있으므로 계속 조정자로 남아 있는 것이 적절합니다. 대다수는 홀수 개의 사이트가 있을 때 모든 데이터베이스 사이트의 50%가 넘는 수를 나타냅니다. 짝수 개의 사이트가 있는 경우 가장 낮은 인터넷 주소를 가진 사이트는 필요할 때 동수 득표 상태를 깨뜨리기 위한 추가 표를 가지고 있습니다. 조정자가 충분한 득표를 얻지 못할 경우 조정자 역할을 그만두고 Ubik는 새 조정자를 선택하게 됩니다. 이것은 저절로 발생하는 것이 아니며 조정자에 실제로 장애가 발생하거나 다수 득표를 얻지 못할 경우에만 발생합니다. 보조 사이트는 기존 조정자를 계속 지지하는 기본적인 특성을 가지고 있으므로 기간이 되지 않은 조정자 선택을 막을 수 있습니다.

새 조정자의 선택은 과반수 득표에 의한 것입니다. Ubik 서브프로세스는 가장 낮은 인터넷 주소를 가진 사이트를 지지하는 경향이 있으므로 모든 사이트가 지지를 받기 위해 경쟁하는 경우보다 필요한 과반수를 더 빠르게 얻을 수 있게 도움을 줍니다. 조정자 선택 중에(보통 3분보다 적은 시간 동안) 클라이언트는 데이터베이스에서 정보를 읽을 수 있으나 변경을 수행할 수 없습니다.

Ubik의 선택 절차에 따르면 각 데이터베이스 서버 프로세스의 조정자는 다른 시스템에 위치할 수 있습니다. 예를 들어 네 개의 프로세스에 대한 Ubik 조정자는 시스템 A에서 시작되었고 몇 가지 이유로 인해 시스템 A의 보호 서버가 작동 중단된 경우 새로운 보호 서버 Ubik 조정자로 다른 사이트(즉 시스템 B)가 선택될 수 있습니다. 시스템 B는 시스템 A의 보호 서버가 다시 작동을 시작하는 경우에도 보호 데이터베이스에 대한 조정자 역할을 계속 수행합니다. 이 보호 서버의 장애는 인증, 백업 또는 VL 서버에는 영향을 미치지 않으므로 그 조정자는 계속 A에 남아 있습니다.

### 관리 데이터베이스 백업 및 복원

AFS 관리 데이터베이스는 셀의 AFS 작동에 중요한 정보를 저장합니다. 데이터베이스가 데이터베이스 서버 시스템의 하드웨어 장애나 다른 문제로 인해 손상되는 경우 스크래치로부터 모든 정보를 재작성하는 일은 어려우며 시간이 많이 드는 일일 것입니다. 데이터 손실이 발생하지 않게 하려면 테이프와 같은 영구 매체에 정기적으로 관리 데이터베이스를 백업하십시오. 권장되는 방법은 UNIX tar 명령과 같은 표준 로컬 디스크 백업 유틸리티를 사용하는 것입니다.

데이터베이스를 백업하는 빈도를 결정할 때 백업 사본으로부터 데이터베이스를 복원해야 할 경우 직접 재작성하려는 데이터 양을 고려해야 합니다. 대부분의 셀에서 데이터베이스들은 변경되는 빈도와 양 측면에서 상당히 다릅니다. 인증 데이터베이스에 대한 변경사항은 가장 덜 자주 발생하며 그 내용은 변경된 사용자 암호가 대부분입니다. 보호 데이터베이스와 VLDB 변경사항은 가장 많이 발생하며 사용자가 그룹을 추가 또는 삭제하고 그룹 멤버쉽을 변경할 때, 사용자 및 다른 관리자가 볼륨을 작성하거나 이동할 때 발생합니다. 변경사항의 수와 빈도는 백업 데이터베이스에서 가장 크며 매일 백업을 수행하는 경우 특히 더 그렇습니다.

손실된 변경사항을 얼마나 쉽게 다시 캡처할 수 있는가는 데이터베이스마다 다릅니다.

- 일반 사용자가 셀에서 인증 데이터베이스와 보호 데이터베이스의 많은 부분을 변경하는 경우 이들을 복구하기 위해서는 많은 탐색 작업이 필요하고 사용자를 인터뷰해야 하며 이들이 언제 어떤 내용을 변경했는지 기억할 수 있다고 가정해야 합니다.
- VLDB에 대한 손실된 변경사항을 복구하는 일은 vos syncserv 및 vos syncvldb 명령을 사용하여 VLDB와 서버 시스템의 실제 볼륨 상태 간의 불일치 상태를 수정할 수 있으므로 좀더 쉽습니다. 그러나 이들 명령은 실행하는 데 많은 시간이 소요될 수 있습니다.
- 백업 데이터베이스의 구성 정보(테이프 조정자 포트 오프셋, 볼륨 집합 및 항목, 덤프 계층 등)는 그렇게 자주 변경되지 않으며 변경되는 경우에도 최근 변경 내용을 복구하는 것은 그렇게 어렵지 않습니다. 이와는 대조적으로 덤프 조작으로부터 발생하는 많은 수의 새 덤프 레코드가 있을 수 있습니다. backup scantape 명령에 대해 -dbadd 인수를 사용하여 이들 레코드를 복구할 수 있으며 백업 테이프 자체로부터 정보를 읽을 수 있습니다. 그러나 셀에서 백업하는 데이터 양과 추가하는 덤프 수에 따라 이 작업을 수행하는 데는 시간이 오래 소요되며 테이프를 많이 변경해야 합니다. 또한 backup scantape 명령을 사용할 때는 여러 가지 제한이 적용됩니다. 가장 기본적인 것은 데이터베이스에 있는 기존의 덤프 레코드가 스캔하고 있는 테이프의 덤프와 동일한 덤프 ID 번호를 가지고 있다는 사실이 발견될 때 데이터베이스 서버가 중단된다는 것입니다. 스캔 조작을 계속 수행하려면 데이터베이스에서 기존의 레코드를 찾아 제거해야 합니다. 자세한 설명을 보려면 AFS Administration Reference에서 backup scantape 명령을 참조하십시오.

데이터베이스 간의 이러한 차이점은 백업 데이터베이스에 대해서는 몇 일이나 주 간격으로, 인증 데이터베이스의 경우 몇 주 간격으로 백업하는 것과 같이 다른 빈도로 데이터베이스를 백업하는 것을 유도합니다. 한편 테이프 소비가 별로 큰 문제가 되지 않는 경우에 특히 모든 데이터베이스를 동시에 백업하는 것이(그리고 자주) 논리적 견지에서 더 간단할 수 있습니다. 또한 오래 동안 데이터베이스의 백업 사본을 보관하는 것은 별로 필요한 일이 아닙니다. 따라서 자주 테이프를 재생할 수 있습니다.

### 관리 데이터베이스를 백업하려면

1. 동기화 사이트가 아닌 데이터베이스 서버 시스템에서 로컬 수퍼유저 루트로 로그인하십시오. 가장 높은 IP 주소를 가진 시스템이 동기화 사이트로 선택될 가능성이 가장 적으므로 가장 바람직합니다.
2. bos shutdown 명령을 실행하여 논리 시스템에서 적절한 서버 프로세스를 종료하십시오. 명령에 대한 자세한 설명을 보려면 프로세스를 일시적으로 정지하려면을 참조하십시오.

   -instance 인수에 대해 하나 이상의 데이터베이스 서버 프로세스 이름(백업 서버의 경우 buserver, 인증 서버의 경우 kaserver, 보호 서버의 경우 ptserver, 볼륨 위치 서버의 경우 vlserver)을 지정하십시오. 로컬 수퍼유저 root로 로그인했으므로 -localauth 플래그를 포함시키십시오. 그러나 관리 토큰을 반드시 가져야할 필요는 없습니다.

          # bos shutdown <machine name> -instance <instances>+ -localauth [-wait]

3. UNIX tar 명령과 같은 로컬 디스크 백업 유틸리티를 사용하여 하나 이상의 데이터베이스 파일을 테이프로 전송하십시오. 로컬 데이터베이스 서버 시스템에 부착된 테이프 장치가 없으면 원격 복사 명령을 사용하여 이 파일을 테이프 장치가 있는 시스템으로 전송한 다음 그 시스템에서 tar 명령을 사용하십시오.

   0다음 명령 시퀀스는 /usr/afs/db 디렉토리의 완전한 내용을 백업합니다.

          # cd /usr/afs/db
          # tar cvf  tape_device  .

   개별 데이터베이스 파일을 백업하려면 위의 tar 명령에서 다음과 같이 마침표를 파일 이름을 바꾸십시오.

   - 백업 데이터베이스의 경우 bdb.DB0
   - 인증 데이터베이스의 경우 kaserver.DB0
   - 보호 데이터베이스의 경우 prdb.DB0
   - VLDB의 경우 vldb.DB0
4. bos start 명령을 실행하여 로컬 시스템에서 서버 프로세스를 재시작하십시오. 명령에 대한 자세한 설명을 보려면 상태 플래그를 Run으로 변경하여 프로세스를 시작하려면을 참조하십시오. -instance 인수에 대해 단계 2에서처럼 동일한 값을 제공하고 동일한 이유에 대해 -localauth 플래그를 제공하십시오.

          # bos start <machine name> -instance <server process name>+ -localauth

### 관리 데이터베이스를 복원하려면

1. 셀의 각 데이터베이스 서버 시스템에서 로컬 수퍼유저 루트로 로그인하십시오.
2. 시스템 중 하나에서 작업할 경우 각 데이터베이스 서버 시스템에 대해 한번씩 bos shutdown 명령을 실행하여 모든 시스템의 해당 서버 프로세스를 종료하십시오. 명령에 대한 자세한 설명을 보려면 프로세스를 일시적으로 정지하려면을 참조하십시오.

   -instance 인수에 대해 하나 이상의 데이터베이스 서버 프로세스 이름(백업 서버의 경우 buserver, 인증 서버의 경우 kaserver, 보호 서버의 경우 ptserver, 볼륨 위치 서버의 경우 vlserver)을 지정하십시오. 로컬 수퍼유저 root로 로그인했으므로 -localauth 플래그를 포함시키십시오. 그러나 관리 토큰을 반드시 가져야할 필요는 없습니다.

          # bos shutdown <machine name> -instance
       <instances>+ -localauth [-wait]

3. 각각에 대해 다음 명령을 실행하여 각 데이터베이스 서버 시스템에서 데이터베이스를 제거하십시오.

          # cd /usr/afs/db

   백업 데이터베이스의 경우:

          # rm bdb.DB0
          # rm bdb.DBSYS1

   인증 데이터베이스의 경우:

          # rm kaserver.DB0
          # rm kaserver.DBSYS1

   보호 데이터베이스의 경우:

          # rm prdb.DB0
          # rm prdb.DBSYS1

   VLDB의 경우:

          # rm vldb.DB0
          # rm vldb.DBSYS1

4. 데이터베이스를 백업하는 데 사용한 로컬 디스크 백업 유틸리티를 사용하면 가장 최근에 백업한 데이터베이스 버전이 가장 낮은 IP 주소를 가진 데이터베이스 서버 시스템의 해당 파일로 복사됩니다. 다음은 동기화 사이트에 부착된 테이프 장치가 있을 경우 적절한 tar 명령입니다.

          # cd /usr/afs/db
          # tar xvf tape_device  database_file

   여기서 database_file은 다음 중 하나입니다.

   - 백업 데이터베이스의 경우 bdb.DB0
   - 인증 데이터베이스의 경우 kaserver.DB0
   - 보호 데이터베이스의 경우 prdb.DB0
   - VLDB의 경우 vldb.DB0
5. 시스템 중 하나에서 작업하는 경우 bos start 명령을 실행하여 데이터베이스 서버 각각에 대해 차례로 서버 프로세스를 재시작하십시오. 가장 낮은 IP 주소를 가진 시스템에서 시작하십시오. 이 시스템이 백업 데이터베이스에 대한 동기화 사이트가 됩니다. 이 명령을 반복하여 다른 데이터베이스 서버 시스템에서 프로세스를 재시작하기 전에 스스로 동기화 사이트로 설정될 때까지 기다리십시오. 명령에 대한 자세한 설명을 보려면 상태 플래그를 Run으로 변경하여 프로세스를 시작하려면을 참조하십시오. -instance 인수에 대해 단계 2에서처럼 동일한 값을 제공하고 동일한 이유에 대해 -localauth 플래그를 제공하십시오.

          #
       bos start <machine name> -instance  <server process name>+  -localauth

6. 데이터베이스가 백업한 이후로 변경되었으면 지정된 절에서 설명하는 지침에 따라 적절한 명령을 실행하여 복원된 데이터베이스에 정보를 재작성하십시오. pts 명령을 실행하는 경우 먼저 관리 토큰을 얻어야 합니다. backup 및 vos 명령은 사용자가 로컬 수퍼유저 루트로 로그인한 경우 -localauth 플래그를 승인하므로 관리 토큰이 필요하지 않습니다. 인증 서버는 항상 별도의 인증을 수행하므로 kas 명령을 실행할 때는 -admin 인수만 포함시키면 됩니다.
   - 백업 데이터베이스에서 볼륨 집합 및 볼륨 항목을 정의하거나 제거하려면 볼륨 세트와 볼륨 항목의 정의 및 표시를 참조하십시오.
   - 백업 데이터베이스에서 덤프 계층을 편집하려면 덤프 계층 정의 및 표시를 참조하십시오.
   - 백업 데이터베이스에서 테이프 조정자 포트 오프셋 항목을 정의하거나 제거하려면 테이프 조정자 시스템 및 테이프 장치 구성을 참조하십시오.
   - 백업 데이터베이스에서 덤프 레코드를 복원하려면 테이프 내용 검색하기를 참조하십시오.
   - 사용자에 대한 인증 데이터베이스 항목이나 암호 변경사항을 재작성하려면 사용자 계정 관리의 해당 절을 참조하십시오.
   - 보호 데이터베이스 항목 또는 그룹 멤버쉽 정보를 재작성하려면 보호 데이터베이스 관리의 해당 절을 참조하십시오.
   - 볼륨 헤더와 VLDB를 동기화하려면 VLDB 및 볼륨 헤더 동기화를 참조하십시오.

## 서버 프로세스 소프트웨어 설치

이 절에서는 파일 서버 시스템에 새 서버 프로세스 2진 파일을 설치하는 방법, 현재 버전이 제대로 작동하는 경우 이전 버전으로 복귀하는 방법 및 새 디스크를 설치하여 파일 서버 시스템에 AFS 볼륨을 배치하는 방법을 설명합니다.

서버 프로세스의 2진 파일을 바꾸는 가장 흔한 이유는 AFS를 새 버전으로 업그레이드하기 위한 것입니다. 보통 설치 설명서에는 업데이트된 소프트웨어에 대해서도 설명하지만 이 장에서는 추가 참조 사항만 제공합니다.

각 AFS 서버 시스템은 일반적으로 /usr/afs/bin이라는 로컬 디스크 디렉토리에 서버 프로세스 2진 파일을 저장해야 합니다. 적절한 시스템 성능을 위해 모든 서버 시스템에서 동일한 빌드 레벨 또는 적어도 동일한 버전의 서버 소프트웨어가 실행되는 것이 좋습니다. AFS 빌드 레벨을 확인하는 방법에 대해서는 2진 파일의 빌드 레벨 표시를 참조하십시오.

갱신 서버는 모든 서버 시스템에 동일한 버전의 소프트웨어를 쉽게 분배할 수 있게 해 줍니다. 갱신 서버의 서버 부분(upserver 프로세스)을 실행하여 각 시스템 유형을 가진 하나의 서버 시스템을 2진 분산 시스템으로 지정해야 합니다. 해당 시스템 유형을 가진 다른 모든 서버 시스템은 갱신 서버의 클라이언트 부분(upclientbin 프로세스)을 실행하여 2진 분산 시스템에서 갱신된 소프트웨어를 검색합니다. AFS 빠른 시작에서는 해당 프로세스를 설치하는 방법을 설명합니다. 2진 분산 시스템에 대한 자세한 정보를 보려면 2진 분산 시스템을 참조하십시오.

갱신 서버를 사용할 경우 2진 분산 시스템에만 새 2진 파일을 설치해야 합니다. upclientbin 프로세스가 실행되고 있는 시스템에 직접 2진 파일을 설치하면 이들 파일은 프로세스가 로컬 /usr/afs/bin 디렉토리의 내용을 시스템 제어 시스템의 내용과 비교하는 다음 번에 덮어써지며 이 때 걸리는 시간은 보통 5분입니다.

다음 지침은 bos 집합의 해당 명령을 사용하여 서버 2진 파일을 설치 및 설치 해제하는 방법을 설명합니다.

### 새 2진 파일 설치

AFS 서버 프로세스는 새 프로세스 2진 파일이 /usr/afs/bin 디렉토리에 설치되자마다 이 파일로 자동으로 전환되지는 않습니다. 프로세스는 다음에 재시작될 때까지 계속 이전 버전의 2진 파일을 사용합니다. 기본적으로 BOS 서버는 /usr/afs/local/BosConfig 파일에 지정된 것처럼 매일 오전 5시에 새 2진 파일이 있는 프로세스를 재시작합니다. 이 2진 파일 재시작 시간을 표시하거나 변경하려면 BOS 서버의 재시작 시간 설정에서 설명하는 것처럼 bos getrestart 및 bos setrestart 명령을 사용하십시오.

다음 지침에 따라 bos restart 명령을 실행하여 즉시 서버 시스템이 강제로 새로운 서버 프로세스 2진 파일을 사용하게 할 수 있습니다.

새 명령 집합 2진 파일을 설치할 때 프로세스를 재시작할 필요는 없습니다. 새 2진 파일은 집합으로부터 명령이 실행되는 다음 번에 자동으로 호출됩니다.

bos install 명령을 사용할 때 BOS 서버는 파일 이름에 .BAK 확장자를 추가하여 현재 버전의 2진 파일을 자동으로 저장합니다. 이 서버는 아직 OLD 버전이 없는 경우 현재의 .BAK 버전을 .OLD 버전으로 이름 변경합니다. 현재의 .OLD 버전이 있는 경우 .BAK 버전은 적어도 7일 이상 경과한 버전이어야만 이전 버전을 대체할 수 있습니다.

/usr/afs/bin 디렉토리에 AFS 2진 파일을 저장하는 것이 가장 좋습니다. 왜냐하면 이 디렉토리는 BOS 서버가 새 2진 파일이 있는지 자동으로 검사하는 디렉토리이기 때문입니다. 그러나 bos install 명령의 -dir 인수를 사용하여 비 AFS 2진 파일을 서버 시스템의 로컬 디스크에 있는 다른 디렉토리에 설치할 수 있습니다. 자세한 정보는 AFS Administration Reference에서 명령 참조 페이지를 참조하십시오.

### 새 서버 2진 파일을 설치하려면

1. 사용자가 /usr/afs/etc/UserList 파일에 나열되어 있는지 확인하십시오. 필요하면 UserList 파일에서 사용자를 표시하려면에서 자세히 설명되어 있는 bos listusers 명령을 실행하십시오.

          % bos listusers <machine name>

2. 2진 파일을 설치하고 있는 원본 디렉토리에서 해당 2진 파일을 사용할 수 있는지 확인하십시오. 시스템이 AFS 클라이언트이기도 한 경우 AFS의 중앙 디렉토리에서 해당 2진 파일을 검색할 수 있습니다. 그렇지 않은 경우 AFS 분산 매체, 이전에 2진 파일을 설치한 로컬 디스크 디렉토리 또는 ftp 명령과 같은 전송 유틸리티를 사용하는 로컬 시스템으로부터 직접 2진 파일을 구할 수 있습니다.
3. 2진 분산 시스템에 대해 bos install 명령을 실행하십시오(해당 역할을 어떤 시스템에서 수행하고 있는지 잊은 경우 시스템 유형에 대한 2진 분산 시스템을 찾으려면을 참조하십시오).

          % bos install <machine name> <files to install>+

   여기서

   i
     허용되는 install의 가장 짧은 축약형입니다.

   machine name
     2진 분산 시스템을 명명합니다.

   files to install
     로컬 /usr/afs/bin 디렉토리에 설치할 각 2진 파일을 명명합니다. 부분 경로 이름은 현재 작업 디렉토리에 상대적으로 해석됩니다. 각 경로 이름의 마지막 요소(파일 이름 자체)는 서버 프로세스에 대해 bosserver 또는 volserver, 명령에 대해 bos 또는 vos와 같이 대체 중인 파일의 이름에 해당합니다.

     fs 프로세스를 제외한 각 AFS 서버 프로세스는 단일 2진 파일을 사용합니다. fs 프로세스는 fileserver, volserver 및 salvager의 세 가지 2진 파일을 사용합니다. 한 구성요소의 새 버전을 설치할 경우 만드시 위의 세 가지 파일을 바꾸어야 함을 의미하지는 않습니다.

4. 각 2진 분산 시스템에 대해 단계 3을 반복하십시오.
5. (선택적) 새 2진 파일을 즉시 사용하기 위한 프로세스를 재시작하려면 upclientbin 프로세스가 2진 분산 시스템으로부터 이들 2진 파일을 검색할 때까지 기다리십시오. 2진 버전 날짜 표시에서 설명하는 것처럼 bos getdate 명령을 사용하여 2진 파일의 시간 소인을 확인할 수 있습니다. 각 서버 시스템에서 2진 파일을 사용할 수 있을 때 bos restart 명령을 실행하십시오. 자세한 지침은 프로세스를 정지한 후 즉시 재시작하기를 참조하십시오.

   AFS 클라이언트 시스템에서 작업하는 경우 서버 프로세스를 재시작하기 전에 로컬 디스크에서 bos 명령 집합 2진 파일 사본을 보유하도록 유의해야 합니다. 일반적인 구성에서는 클라이언트 시스템에서 bos 명령 2진 파일을 포함하는 /usr/afsws/bin 디렉토리가 로컬 디스크 공간을 보유하는 AFS로의 기호 연결에 해당합니다. 그러나 특정 프로세스(특히 데이터베이스 서버 프로세스)를 재시작하면 재시작 중에 문제가 발생하는 경우에 특히 AFS 파일 공간을 액세스할 수 없게 만들 수 있습니다. bos 2진 파일의 로컬 사본을 가지고 있으면 이러한 경우에도 프로세스 2진 파일을 설치 해제 또는 재설치하거나 프로세스를 재시작할 수 있습니다. cp 명령을 사용하여 bos 명령 2진 파일을 /usr/afsws/bin 디렉토리에서 /tmp와 같은 로컬 디렉토리로 복사하십시오.

   프로세스를 재시작하면 서비스 작동 중단 상태가 발생합니다. 가능한한 시스템 사용도가 낮을 때 재시작하는 것이 바람직합니다.

          % bos restart <machine name> <instances>+

### 이전 버전의 2진 파일로 복원

드문 경우지만 새 2진 파일을 설치할 경우 이전 버전으로 복원해야 할만큼 심각한 문제가 발생할 수 있습니다. 2진 파일을 설치할 때처럼 일관된 시스템 성능을 위해서는 모든 서버 시스템을 동일한 버전으로 복원해야 합니다. 각 2진 분산 시스템에 대해 다음에서 설명하는 bos uninstall 명령을 실행하십시오.

bos uninstall 명령을 사용할 때 BOS 서버는 2진 파일의 현재 버전을 버리고 확장자를 제거하여 파일의 .BAK 버전을 생성합니다. 이 서버는 현재의 .OLD 버전을 .BAK 버전으로 이름 변경합니다.

현재 .BAK 버전이 없는 경우 bos uninstall 명령은 실패하고 오류 메시지를 생성합니다. .OLD 버전이 아직도 있으면 bos uninstall 명령을 다시 실행하기 전에 mv 명령을 실행하여 .BAK로 이름 변경하십시오.

새 2진 파일을 설치할 때처럼 서버 프로세스는 복원된 버전을 즉시 사용하지 않습니다. 현재 2진 파일이 작동되지 않으므로 사용자가 파일을 복원했다고 가정할 수 있으므로 다음 지침에 따라 적절한 프로세스를 재시작해야 합니다.

### 이전 버전의 2진 파일로 복원하려면

1. 사용자가 /usr/afs/etc/UserList 파일에 나열되어 있는지 확인하십시오. 필요하면 UserList 파일에서 사용자를 표시하려면에서 자세히 설명되어 있는 bos listusers 명령을 실행하십시오.

          % bos listusers <machine name>

2. 각 해당 2진 파일의 .BAK 버전이 각 2진 분산 시스템의 /usr/afs/bin 디렉토리에서 사용 가능한지 확인하십시오. 필요하면 2진 버전 날짜 표시에서 설명하는 것처럼 bos getdate 명령을 사용할 수 있습니다. 필요하면 .OLD 버전을 .BAK로 이름 변경하십시오.
3. 2진 분산 시스템에 대해 bos uninstall 명령을 실행하십시오. (해당 역할을 어떤 시스템에서 수행하고 있는지 잊은 경우 시스템 유형에 대한 2진 분산 시스템을 찾으려면을 참조하십시오.)

          % bos uninstall <machine name> <files to uninstall>+

   여기서

   u
     허용되는 uninstall의 가장 짧은 축약형입니다.

   machine name
     2진 분산 시스템을 명명합니다.

   files to uninstall
     /usr/afs/bin 디렉토리의 각 2진 파일을 명명하여 .BAK 버전을 대체합니다. /usr/afs/bin 디렉토리가 이미 가정되므로 파일 이름만 사용해도 충분합니다.
4. 각 2진 분산 시스템에 대해 단계 3을 반복하십시오.
5. 각 서버 시스템의 upclientbin 프로세스가 2진 분산 시스템으로부터 복원된 파일 버전을 검색할 때까지 기다리십시오. 2진 버전 날짜 표시에서 설명하는 것처럼 bos getdate 명령을 사용하여 2진 파일의 시간 소인을 확인할 수 있습니다. 각 서버 시스템에서 2진 파일을 사용할 수 있을 때 bos restart 명령을 실행하십시오. 자세한 지침은 프로세스를 정지한 후 즉시 재시작하기를 참조하십시오.

   AFS 클라이언트 시스템에서 작업하는 경우 서버 프로세스를 재시작하기 전에 로컬 디스크에서 bos 명령 집합 2진 파일 사본을 보유하도록 유의해야 합니다. 일반적인 구성에서는 클라이언트 시스템에서 bos 명령 2진 파일을 포함하는 /usr/afsws/bin 디렉토리가 로컬 디스크 공간을 보유하는 AFS로의 기호 연결에 해당합니다. 그러나 특정 프로세스(특히 데이터베이스 서버 프로세스)를 재시작하면 재시작 중에 문제가 발생하는 경우에 특히 AFS 파일 공간을 액세스할 수 없게 만들 수 있습니다. bos 2진 파일의 로컬 사본을 가지고 있으면 이러한 경우에도 프로세스 2진 파일을 설치 해제 또는 재설치하거나 프로세스를 재시작할 수 있습니다. cp 명령을 사용하여 bos 명령 2진 파일을 /usr/afsws/bin 디렉토리에서 /tmp와 같은 로컬 디렉토리로 복사하십시오.

          %
       bos restart <machine name> <instances>+

### 2진 버전 날짜 표시

/usr/afs/bin 디렉토리에서 2진 파일의 세 가지 버전인 현재 버전, .BAK 및 .OLD 버전에 대한 컴파일 날짜를 확인할 수 있습니다. 이것은 서버 프로세스를 재시작하여 새 2진 파일을 사용하기 전에 2진 분산 시스템으로부터 파일 서버 시스템으로 새 2진 파일이 복사되었는지 확인하는 데 유용한 방법입니다.

/usr/afs/bin 이외의 디렉토리에서 2진 파일에 대한 날짜를 확인하려면 -dir 인수를 추가하십시오. AFS Administration Reference를 참조하십시오.

### 2진 파일 버전 날짜를 표시하려면

1. bos getdate 명령을 실행하십시오.

          %
       bos getdate <machine name> <files to check>+

   여기서

   getd
     허용되는 getdate의 가장 짧은 축약형입니다.

   machine name
     2진 파일 날짜를 표시할 파일 서버 시스템의 이름.

   files to check
     표시할 각 2진 파일을 명명합니다.

### 이전 2진 파일 제거

새 2진 파일을 사용하는 프로세스가 오래 동안 문제 없이 실행된 경우 /usr/afs/bin 디렉토리에서 .BAK 및 .OLD 버전을 제거하여 파일 서버 시스템의 로컬 디스크에 있는 클러터를 줄이고 공간을 확보해도 안전합니다.

bos prune 명령 플래그를 사용하여 다음 유형의 파일을 제거할 수 있습니다.

- /usr/afs/bin 디렉토리에서 .BAK 확장자가 있는 파일을 제거하려면 -bak 플래그를 사용하십시오.
- /usr/afs/bin 디렉토리에서 .OLD 확장자가 있는 파일을 제거하려면 -old 플래그를 사용하십시오.
- /usr/afs/logs 디렉토리에서 임의의 확장자를 가진 core 파일을 제거하려면 -core 플래그를 사용하십시오.
- 세 가지 유형의 파일을 모두 제거하려면 -all 플래그를 사용하십시오.

### 이전 2진 파일을 제거하려면

1. 사용자가 /usr/afs/etc/UserList 파일에 나열되어 있는지 확인하십시오. 필요하면 UserList 파일에서 사용자를 표시하려면에서 자세히 설명되어 있는 bos listusers 명령을 실행하십시오.

          % bos listusers <machine name>

2. 하나 이상의 플래그를 사용하여 bos prune 명령을 실행하십시오.

          % bos prune <machine name> [-bak] [-old] [-core] [-all]

   여기서

   p
     허용되는 prune의 가장 짧은 축약형입니다.

   machine name
     이전 파일을 제거할 파일 서버 시스템을 명명합니다.

   -bak
     .BAK 확장자를 가진 모든 파일을 /usr/afs/bin 디렉토리에서 제거합니다. 이 플래그를 -all 플래그와 함께 사용하지 마십시오.

   -old
     OLD 확장자를 가진 모든 파일을 /usr/afs/bin 디렉토리에서 제거합니다. 이 플래그를 -all 플래그와 함께 사용하지 마십시오.

   -core
     /usr/afs/logs 디렉토리에서 모든 코어 파일을 제거합니다. 이 플래그를 -all 플래그와 함께 사용하지 마십시오.

   -all
     세 플래그의 효과를 통합해서 제공합니다. 이 플래그를 다른 세 플래그와 함께 사용하지 마십시오.

### 2진 파일의 빌드 레벨 표시

서버 시스템과 셀 전체에서 일관된 성능을 유지하기 위해 모든 서버 프로세스가 동일한 AFS 분산으로부터 제공되는 것이 가장 좋습니다. 모든 AFS 2진 파일에는 그 버전이나 빌드 레벨을 지정하는 ASCII 문자열이 포함되어 있습니다. 이를 표시하려면 strings 및 grep 명령을 사용하십시오. 이들 명령은 대부분의 UNIX 분산 제품에 포함되어 있습니다.

### AFS 2진 파일의 빌드 레벨을 표시하려면

1. 2진 파일이 들어 있는 디렉토리로 변경하십시오. 2진 파일의 위치를 정확히 모르면 which 명령을 실행하십시오.

          % which binary_file
          /bin_dir_path/binary_file
          % cd bin_dir_path

2. strings 명령을 실행하여 2진 파일로부터 모든 ASCII 문자열을 추출하십시오. 출력을 grep 명령으로 파이프하여 적절한 행을 찾으십시오.

          % strings ./binary_file | grep Base

   출력은 다음과 같은 형식으로 AFS 빌드 레벨을 보고합니다.

          @(#)Base configuration afsversion  build_level

   예를 들어 다음 문자열은 2진 파일이 AFS 3.6 빌드 3.0의 파일임을 나타냅니다.

          @(#)Base configuration afs3.6 3.0

## 서버 CellServDB 파일 유지

모든 파일 서버 시스템은 로컬 디스크의 로컬 디스크 파일 /usr/afs/etc/CellServDB에 홈 셀의 데이터베이스 서버 시스템 목록을 유지합니다. 데이터베이스 서버 프로세스와 비 데이터베이스 서버 프로세스 모두 다음과 같이 이 파일을 확인합니다.

- 데이터베이스 서버 프로세스(인증, 백업, 보호 및 볼륨 위치 서버)는 동기화된 관리 데이터베이스 복사본을 유지하기 위해 피어와 계속 접속합니다.

  AFS 관리 데이터베이스 복제에서 자세히 설명하는 것처럼 데이터베이스 서버 프로세스는 Ubik 유틸리티를 사용하여 유지하는 데이터베이스의 정보를 동기화합니다. 각 데이터베이스에 대한 동기화 사이트에 있는 Ubik 조정자는 데이터베이스의 단일 읽기/쓰기 사본을 유지하고 필요에 따라 변경사항을 보조 사이트로 분배합니다. 또한 조정자로 남아 있기 위해 과반수의 보조 사이트와 접속을 유지해야 하며 CellServDB 파일을 참고하여 피어의 수와 이들이 실행되고 있는 시스템을 확인합니다.

  조정자가 과반수 피어와 연결이 끊기면 과반수 표결에 의해 새 조정자를 선택합니다. 조정자 선택 중에 모든 Ubik 프로세스는 CellServDB 파일을 참고하여 득표를 전송할 위치와 과반수를 이루기 위해 필요한 표 수를 알게 됩니다.

- 비 데이터베이스 서버 프로세스는 데이터베이스의 정보를 검색하기 위해 데이터베이스 서버 프로세스가 실행되고 있는 시스템을 알아야 합니다. 예를 들어 사용자가 AFS 파일을 처음으로 액세스할 때 이 파일이 들어 있는 파일 서버는 보호 서버에 접속하여 사용자의 그룹 멤버쉽 목록을 구합니다. (이 목록을 현재 보호 서브그룹이나 CPS라고 합니다.) 파일 서버는 CPS를 사용하여 파일을 보호하는 액세스 제어 목록(ACL)이 사용자에게 필요한 권한을 부여하는지 확인합니다. (자세한 정보를 보려면 보호 데이터베이스 정보를 참조하십시오.)

CellServDB 파일의 정보가 누락되었거나 잘못되었을 경우 발생하는 결과는 다음과 같습니다.

- 파일이 시스템을 나열하지 않으면 데이터베이스 서버 프로세스가 실행되고 있는 경우에도 이 시스템은 데이터베이스 서버 시스템이 아닙니다. Ubik 조정자는 이 시스템에 데이터베이스 갱신 사항을 전송하거나 과반수에 포함시키지 않습니다. 이 시스템은 Ubik 선택에 참여하지 않으므로 접속하게 되는 (그 /usr/vice/etc/CellServDB 파일에서 시스템을 나열하는 경우 접속할 수 있음) 클라이언트 시스템으로 데이터베이스 정보를 분배하는 것을 거부합니다. 클라이언트 시스템의 사용자는 올바르게 기능하는 데이터베이스 서버 시스템을 접속하기 위해 제한시간 동안 기다려야 합니다.
- 파일이 데이터베이스 서버 프로세스를 실행하지 않는 시스템을 나열하는 경우 결과는 심각해질 수 있습니다. Ubik 조정자는 이 시스템에 데이터베이스 갱신 사항을 전송할 수 없으나 이 시스템을 과반수에 포함시킵니다. 유효한 보조 사이트가 작동 중단되어 조정자에게 득표를 전송하는 것을 중단할 경우 조정자가 더 이상 필요로 하는 과반수를 얻지 못하는 상황이 발생할 수 있습니다. 새 조정자의 선택 결과는 데이터베이스의 정보가 사용 불가능해지는 동안 서비스 작동 중단을 초래합니다. 더욱이 잘못 나열된 사이트에서 득표 수가 부족하게 될 경우 다른 사이트들이 사이트 과반수가 새 조정자에게 득표하지 않았다고 믿게 되므로 조정자 선택을 혼란스럽게 할 수 있습니다.

  좀더 경미한 결과는 비 데이터베이스 서버 프로세스가 시스템의 데이터베이스 서버 프로세스에 접속하려고 하는 것입니다. 이 경우 프로세스가 실행되지 않게 되므로 제한시간 지연이 발생합니다.

서버 시스템의 /usr/afs/etc/CellServDB 파일은 클라이언트 시스템의 /usr/vice/etc/CellServDB 파일과 같지 않다는 점을 알아 두십시오. 클라이언트 버전에는 로컬 셀 뿐 아니라 외부 셀에 대한 항목도 들어 있습니다. 그러나 셀의 데이터베이스 서버 시스템을 변경할 때마다 두 버전의 파일을 모두 갱신하는 것이 중요합니다. 클라이언트이기도 한 서버 시스템은 두 파일을 모두 필요로 하므로 사용자가 두 파일을 모두 갱신해야 합니다. 클라이언트 버전의 CellServDB 파일 유지에 대한 자세한 정보를 보려면 데이터베이스 서버 시스템 정보 유지를 참조하십시오.

### 서버 CellServDB 파일 분배

/usr/afs/etc/CellServDB 파일의 잘못된 정보로 인한 부정적 결과를 피하려면 데이터베이스 서버 시스템을 추가하거나 제거할 때마다 셀의 모든 서버 시스템에서 해당 파일을 갱신해야 합니다. AFS 빠른 시작에서는 데이터베이스 서버 시스템의 설치 또는 제거와 컨텍스트에서 CellServDB 파일 갱신에 대한 자세한 지침을 제공합니다. 이 절에서는 서버 시스템에 이 파일을 분배하는 방법과 사용자가 AFS 전역 이름 공간에 참여할 경우 다른 셀이 변경사항을 인식하도록 하는 방법을 설명합니다.

미국판 AFS를 사용하는 경우 갱신 서버를 사용하여 셀의 시스템 제어 시스템에 저장된 서버 CellServDB 파일의 중앙 사본을 분배하십시오. 각국 언어판 AFS를 사용하는 경우 대신 각 서버 시스템에서 개별적으로 해당 파일을 변경하십시오. 시스템 제어 시스템에 대한 설명과 각국 언어의 셀에서 /usr/afs/etc 디렉토리의 파일에 대해 이 시스템을 사용하면 안되는 이유에 대한 자세한 정보를 보려면 시스템 제어 시스템을 참조하십시오. 미국판 AFS를 사용할 때 갱신 서버를 구성하는 방법에 대한 지침을 보려면 AFS 빠른 시작을 참조하십시오.

오류를 발생할 수 있는 형식 오류를 피하려면 항상 파일을 직접 편집하지 말고 bos addhost 및 bos removehost 명령을 사용하십시오. 시스템에서 실행중인 데이터베이스 서버 프로세스를 재시작해서 새로운 데이터베이스 서버 시스템 집합 내의 조정자 선택을 초기화할 수도 있습니다. 이 단계는 CellServDB 파일에 데이터베이스 서버 시스템을 추가하려면 및 CellServDB 파일에서 데이터베이스 서버 시스템을 제거하려면에 제시되는 지침에 포함되어 있습니다. 파일 내용을 표시하는 것에 대한 지침을 보려면 셀의 데이터베이스 서버 시스템을 표시하려면을 참조하십시오.

외부 사용자가 AFS 전역 이름 공간의 일부로서 사용자의 셀을 액세스할 수 있게 한 경우 사용자 셀의 데이터베이스 서버 시스템을 변경할 때 다른 셀에도 알려야 합니다. AFS 지원 그룹은 AFS 이름 공간에 참여하는 모든 셀을 나열하는 CellServDB 파일을 유지하며 사용자의 요청이 있을 때 셀의 항목을 변경할 수 있습니다. 자세한 정보를 보려면 사용자의 셀을 다른 셀에서 볼 수 있게 만들기를 참조하십시오.

사용자 셀의 데이터베이스 서버 시스템을 알리는 또 다른 방법은 AFS 파일 공간의 일반적 위치에 파일 사본 /afs/cell_name/service/etc/CellServDB.local을 유지하는 것입니다. 자세한 설명을 보려면 세 번째 레벨을 참조하십시오.

### 셀의 데이터베이스 서버 시스템을 표시하려면

1. bos listhosts 명령을 실행합니다. 파일을 제대로 유지 관리한 경우 출력은 모든 서버 시스템에서 동일하게 나타나지만 machine name 인수를 사용하면 다양한 시스템을 확인할 수 있습니다.

          % bos listhosts <machine name> [<cell name>]

   여기서

   listh
     허용되는 listhosts의 가장 짧은 축약형입니다.

   machine name
     /usr/afs/etc/CellServDB 파일을 표시할 서버 시스템을 지정합니다.

   cell name
     외부 셀의 완전한 인터넷 도메인 이름을 지정합니다. machine name 인수로 제공할 셀에 있는 적어도 하나 이상의 서버 시스템 이름을 이미 알고 있어야 합니다.

출력은 지정된 서버 시스템의 CellServDB 파일에 나타난 순서대로 시스템을 나열합니다. 또한 다음 예에서처럼 각 시스템에 `Host` 색인 번호를 지정합니다. 색인과 시스템의 IP 주소, 이름 또는 Ubik 조정자나 보조 사이트로서의 역할 간의 내재된 관계는 없습니다.

       % bos listhosts fs1.abc.com
       Cell name is abc.com
           Host 1 is fs1.abc.com
           Host 2 is fs7.abc.com
           Host 3 is fs4.abc.com

출력은 명명 서비스(예: 도메인 이름 서비스 또는 로컬 호스트 테이블)가 제대로 기능하는 한 IP 주소 대신 이름별로 시스템을 나열합니다. IP 주소를 표시하려면 로컬 수퍼유저 루트로 서버 시스템에 로그인하고 문서 편집기를 사용하거나 cat과 같은 명령을 표시하여 /usr/afs/etc/CellServDB 파일을 나타내십시오.

### CellServDB 파일에 데이터베이스 서버 시스템을 추가하려면

1. 사용자가 /usr/afs/etc/UserList 파일에 나열되어 있는지 확인하십시오. 필요하면 UserList 파일에서 사용자를 표시하려면에서 자세히 설명되어 있는 bos listusers 명령을 실행하십시오.

          % bos listusers <machine name>

2. bos addhost 명령을 실행하여 새로운 각 데이터베이스 서버 시스템을 CellServDB 파일에 추가하십시오. 미국판 AFS를 사용하는 경우 시스템 제어 시스템을 machine name으로 지정하십시오. (어떤 시스템이 시스템 제어 시스템인지 잊은 경우 시스템 제어 시스템의 출력을 참조하십시오.) 각국 언어판 AFS를 사용하는 경우 machine name을 해당 이름으로 바꾸고 셀의 각 서버 시스템에 대해 이 명령을 차례로 반복하십시오.

          % bos addhost  <machine name>  <host name>+

   여기서

   addh
     허용되는 addhost의 가장 짧은 축약형입니다.

   machine name
     미국판 AFS를 사용하는 경우 시스템 제어 시스템을 명명합니다. 각국 언어판 AFS를 사용하는 경우 각 서버 시스템을 차례대로 명명합니다.

   host name
     CellServDB 파일에 추가할 각 데이터베이스 서버 시스템의 완전히 규정된 호스트 이름을 지정합니다 (예: fs4.abc.com). BOS 서버는 gethostbyname( ) 루틴을 사용하여 각 시스템의 IP 주소를 얻고 이름과 주소를 자동으로 기록합니다.
3. 모든 데이터베이스 서버 시스템에서 인증 서버, 백업 서버, VL 서버를 재시작하여 새로운 시스템 집합이 새로운 Ubik 조정자에 포함되게 하십시오. 이 명령어는 프로세스에 대해 일반적인 이름을 사용합니다. 다른 프로세스 이름을 사용하는 경우 적절히 대체하십시오. 자세한 구문을 보려면 프로세스를 정지한 후 즉시 재시작하기를 참조하십시오.

   중요: 모든 데이터베이스 서버 시스템에서 연속으로 다음 명령을 빠르게 반복하십시오.

          % bos restart <machine name> buserver kaserver ptserver vlserver

4. 셀의 각 클라이언트 시스템에서 /usr/vice/etc/CellServDB 파일을 편집합니다. 지침을 보려면 데이터베이스 서버 시스템 정보 유지를 참조하십시오.
5. AFS 전역 이름 공간에 참여하는 경우 셀의 지정된 사이트 접속 지점 중 하나가 AFS 제품 지원부와 함께 사용자가 수행한 변경사항을 등록하게 하십시오.

   셀 서버 CellServDB 파일의 중앙 사본을 일반적인 위치(/afs/cell_name/service/etc/CellServDB.local)에 유지 관리하려면 변경 내용을 반영하도록 파일을 편집하십시오.

### CellServDB 파일에서 데이터베이스 서버 시스템을 제거하려면

1. 사용자가 /usr/afs/etc/UserList 파일에 나열되어 있는지 확인하십시오. 필요하면 UserList 파일에서 사용자를 표시하려면에서 자세히 설명되어 있는 bos listusers 명령을 실행하십시오.

          % bos listusers <machine name>

2. bos removehost 명령을 실행하여 CellServDB 파일에서 각 데이터베이스 서버 시스템을 제거하십시오. 미국판 AFS를 사용하는 경우 시스템 제어 시스템을 machine name으로 지정하십시오. (어떤 시스템이 시스템 제어 시스템인지 잊은 경우 시스템 제어 시스템의 출력을 참조하십시오.) 각국 언어판 AFS를 사용하는 경우 machine name을 해당 이름으로 바꾸고 셀의 각 서버 시스템에 대해 이 명령을 차례로 반복하십시오.

          % bos removehost <machine name>  <host name>+

   여기서

   removeh
     허용되는 removehost의 가장 짧은 축약형입니다.

   machine name
     미국판 AFS를 사용하는 경우 시스템 제어 시스템을 명명합니다. 각국 언어판 AFS를 사용하는 경우 각 서버 시스템을 차례대로 명명합니다.

   host name
     CellServDB 파일에서 제거할 각 데이터베이스 서버 시스템의 완전히 규정된 호스트 이름을 지정합니다 (예: fs4.abc.com).
3. 모든 데이터베이스 서버 시스템에서 인증 서버, 백업 서버, VL 서버를 재시작하여 새로운 시스템 집합이 새로운 Ubik 조정자에 포함되게 하십시오. 이 명령어는 프로세스에 대해 일반적인 이름을 사용합니다. 다른 프로세스 이름을 사용하는 경우 적절히 대체하십시오. 자세한 구문을 보려면 프로세스를 정지한 후 즉시 재시작하기를 참조하십시오.

   중요: 모든 데이터베이스 서버 시스템에서 연속으로 다음 명령을 빠르게 반복하십시오.

          % bos restart <machine name> buserver kaserver ptserver vlserver

4. 셀의 각 클라이언트 시스템에서 /usr/vice/etc/CellServDB 파일을 편집합니다. 지침을 보려면 데이터베이스 서버 시스템 정보 유지를 참조하십시오.
5. AFS 전역 이름 공간에 참여하는 경우 셀의 지정된 사이트 접속 지점 중 하나가 AFS 제품 지원부와 함께 사용자가 수행한 변경사항을 등록하게 하십시오.

   셀 서버 CellServDB 파일의 중앙 사본을 일반적인 위치(/afs/cell_name/service/etc/CellServDB.local)에 유지 관리하려면 변경 내용을 반영하도록 파일을 편집하십시오.

## 인증 관리 및 권한 부여 요구조건

이 절에서는 권한 확인 및 클라이언트와의 상호 인증을 통해 AFS 서버 프로세스가 적절한 권한이 있는 사용자만 권한 있는 명령을 수행하도록 보장하는 방법을 설명합니다. 또한 시스템 기준이나 셀 기준으로 권한 확인 요구조건을 제어하는 방법과 명령을 실행할 때 상호 인증을 무시하는 방법에 대해서도 설명합니다.

### 인증 대 권한 부여

많은 AFS 명령은 명령에 의해 호출된 AFS 서버 프로세스가 적절한 권한을 가진 사용자에 대해서만 해당 명령을 수행한다는 측면에서 권한이 부여됩니다. 서버 프로세스는 다음의 두 가지 검사를 수행하여 사용자가 적절한 권한을 가지는지 확인합니다.

- 인증 검사에서, 서버 프로세스는 명령 인터프리터, 캐쉬 관리 프로그램 또는 사용자나 응용 프로그램 대신 작동하는 다른 클라이언트 프로세스를 상호 인증합니다. 이 검사는 목적은 누가 명령을 실행하고 있는지 확인하는 것입니다. 서버 프로세스는 서버 티켓과 실행자 토큰의 다른 구성요소를 검토하여 실행자가 실제로 요청된 사람인지 확인합니다. (둘째로 클라이언트 프로세스에서 서버 프로세스가 진짜인지 확인할 수 있게 합니다.) 실행자가 토큰이 없거나 다른 이유로 검사가 실패하면 서버 프로세스는 완전히 권한 없는 사용자를 나타내는 anonymous ID를 해당 사용자에게 지정합니다. 상호 인증에 대한 자세한 설명을 보려면 상호 인증에 대한 상세한 설명을 참조하십시오.

  여러 가지 개별 명령을 사용하면 상호 인증을 시도하지 않고 anonymous ID를 가정하여 인증 검사를 무시할 수 있습니다. 그러나 명령이 권한이 부여된 것이고 서버 프로세스가 여전히 권한 검사를 수행하고 있는 경우 프로세스가 anonymous 사용자에 대해 권한 있는 명령을 실행하는 것을 거부하므로 이러한 조치는 별 효과가 없습니다.

- 권한 검사에서 서버 프로세스는 권한 있는 사용자의 목록을 확인하여 실행자가 명령을 사용할 권한을 가지는지 결정합니다. 이 검사는 목적은 실행자에게 허용된 작업 범위를 알아내는 것입니다. 다른 서버 프로세스는 관리 특권 관리에서 설명하는 것처럼 다른 사용자 목록을 참고합니다. 서버 프로세스는 권한 없는 실행자에 대해서는 권한 있는 명령을 실행하는 것을 거부합니다. 명령에 적용되는 권한 요구조건이 없는 경우 서버 프로세스는 이 단계를 건너뛰고 즉시 실행됩니다.

  주: | anonymous 사용자를 권한 목록의 system:anyuser 그룹에 두지 마십시오. 이렇게 하면 권한 확인의 의미가 없어집니다. bos setauth 명령을 사용하면 서버 시스템의 서버 프로세스에 대한 권한 확인 여부를 제어할 수 있습니다. 다른 서버 시스템은 이 명령의 영향을 받지 않습니다. 권한 확인 기능을 해제하면 해당 시스템의 서버 프로세스가 임의의 사용자에게 어떠한 조치도 수행할 수 있으므로 심각한 보안 위험을 초래하게 됩니다.

### 서버 시스템의 권한 확인 제어

권한 확인 기능을 사용 불가능하게 하면 파일 서버 시스템의 AFS 서버 프로세스가 임의의 사용자, 심지어 anonymous 사용자에게까지 모든 조치를 수행할 수 있음을 의미하므로 심각한 보안 위험을 초래합니다.

권한 확인 기능을 해제하는 것이 일반적인 것으로 간주되는 유일한 경우는 새 파일 서버 시스템을 설치할 때입니다(AFS 빠른 시작 참고). 필요한 보안 메카니즘을 활용하는 다른 조치를 수행하기 전에 이러한 모든 메카니즘을 구성하는 것이 불가능하기 때문에 권한 확인 기능을 해제하는 것이 필요할 수 있습니다. 최대의 보안을 유지하기 위해서는 설치 중에 시스템의 콘솔에서 작업하고 가능한 한 빨리 권한 확인 기능을 사용 가능하게 하십시오.

정상 작동 중에 권한 확인 기능을 사용 불가능하게 하는 유일한 이유는 서버 암호화 키에 오류가 발생하여 서버가 사용자를 제대로 인증하지 못하는 경우입니다. 키 관련 긴급 상황을 처리하기 위한 지침에 대해서는 서버 암호화 키 비상사태 처리를 참조하십시오.

각 파일 서버 시스템에 대한 권한 확인을 별도로 제어할 수 있습니다. 즉 한 시스템의 권한 확인을 설정하거나 해제하는 것이 다른 시스템에 영향을 미치지 않습니다. 클라이언트 시스템이 무작위로 서버 프로세스를 선택하므로 사용자가 모든 시스템에서 동일하게 요구조건을 지정하지 않는 한 주어진 명령에 대해 적용되는 권한 확인 조건을 예측하기는 어렵습니다. 전체 셀에 대해 권한 확인을 설정하거나 해제하려면 모든 파일 서버 시스템에 대해 해당 명령을 반복해서 사용해야 합니다.

서버 프로세스는 로컬 디스크의 /usr/afs/local 디렉토리를 계속 모니터하여 권한을 확인해야 하는지 결정합니다. NoAuth라는 파일이 이 디렉토리에 나타나면 서버는 권한을 확인하지 않습니다. 이 파일이 나타나지 않으면(일반적인 경우) 권한 확인을 수행합니다.

BOS 서버를 통해 NoAuth 파일 존재를 제어할 수 있습니다. bos setauth 명령을 사용하여 권한 확인 기능을 사용 불가능하게 한 경우(또는 설치 중에 BOS 서버를 시작하는 명령에 대해 -noauth 플래그를 사용하여) BOS 서버는 길이가 0인 NoAuth 파일을 작성합니다. 권한 확인을 다시 사용 가능하게 하면 BOS 서버는 이 파일을 제거합니다.

### 서버 시스템의 권한 확인을 사용 불가능하게 하려면

1. 사용자가 /usr/afs/etc/UserList 파일에 나열되어 있는지 확인하십시오. 필요하면 UserList 파일에서 사용자를 표시하려면에서 자세히 설명되어 있는 bos listusers 명령을 실행하십시오.

          % bos listusers <machine name>

2. bos setauth 명령을 실행하여 권한 확인 기능을 사용 불가능하십시오.

          % bos setauth <machine name> off

   여기서

   seta
     허용되는 setauth의 가장 짧은 축약형입니다.

   machine name
     서버 프로세스가 권한을 확인하지 않는 파일 서버 시스템을 지정합니다.

### 서버 시스템의 권한 확인을 사용 가능하게 하려면

1. 권한 확인을 다시 사용 가능하게 하십시오(시스템이 현재 권한을 확인하고 있지 않으므로 필요한 권한은 없습니다). 자세한 구문 정보에 대해서는 이전 절을 참조하십시오.

          % bos setauth <machine name> on

### 개별 명령에 대한 상호 인증 무시

몇몇 서버 프로세스를 사용하면 사용자(단지 시스템 관리자가 아님)가 명령을 실행할 때 상호 인증을 사용할 수 없게 됩니다. 이 서버 프로세스는 명령 실행자를 인증되지 않은 사용자 anonymous로 취급합니다.

상호 인증을 방지하기 위한 기능은 긴급 상황(예: 서버 암호화 키 비상사태 처리에서 설명하는 키 긴급 상황)에서 사용할 수 있도록 제공됩니다. 정상 상황에서 권한 확인은 설정되어 있고 이 기능을 사용할 수 없게 만들면 인증이 금지됩니다. 이 경우 서버 프로세스는 사용자 anonymous에 대해 권한 있는 명령을 수행하는 것을 거부합니다.

권한 확인 기능이 해제되어 있을 때는 인증을 방지하는 것이 유용할 수 있습니다. 인증을 시도하는 행동은 키 긴급 상황에서 나타나는 것처럼 서버가 특정 암호화 키를 이해할 수 없을 때 문제를 유발할 수 있습니다.

### bos, kas, pts 및 vos 명령에 대한 상호 인증을 무시하려면

여러 명령에서 사용할 수 있는 -noauth 플래그를 제공하십시오. 명령이 해당 플래그를 수용하는지 확인하려면 help 명령을 실행하거나 AFS Administration Reference의 명령 참조 페이지를 참조하십시오. (참조 페이지에서도 각 명령의 플래그에 대해 허용되는 가장 짧은 축약형을 지정합니다.) 명령 집합의 apropos 및 help 명령은 플래그를 허용하지 않습니다.

kas interactive 명령의 -noauth 플래그를 포함시켜 대화식 세션 중에 실행된 모든 kas 명령에 대해 상호 인증을 무시할 수 있습니다. 인증된 ID를 사용하여 대화식 모드에 이미 들어간 경우 (kas) noauthentication 명령을 실행하여 anonymous ID인 것으로 가정하십시오.

### fs 명령에 대한 상호 인증을 무시하려면

이것은 fs 명령을 실행하기 전에 unlog 명령을 실행하여 사용자의 토큰을 버리는 경우를 제외하고 사용할 수 없습니다.

## 디스크 및 파티션 추가 또는 제거

AFS는 디스크를 기존의 파일 서버 시스템에 추가함으로써 셀에 기억영역을 상당히 쉽게 추가할 수 있게 해 줍니다. 이 절에서는 AFS 볼륨을 저장하는데 사용되는 디스크를 설치 또는 제거하는 방법을 설명합니다. (기억영역 공간을 추가하는 또 다른 방법은 AFS 빠른 시작에서 설명하는 것처럼 추가 서버 시스템을 설치하는 것입니다.)

디스크를 추가하고 제거하는 작업은 모두 fs 프로세스를 재시작하여 파일 시스템이 새로운 서버 파티션 집합을 인식하게 해야 하므로 파일 시스템 작동 중단 상태를 유발합니다. 일부 운영 체제에서는 사용자가 디스크를 추가 또는 제거하기 전에 시스템을 종료하도록 요구하며 이 경우 모든 AFS 서버 프로세스를 맨 먼저 종료해야 합니다. 그렇지 않은 경우 디스크 추가 또는 제거의 AFS 관련 부분은 복잡하지 않으므로 시스템 작동 중단이 지속되는 기간은 디스크 자체를 설치하거나 제거하는데 소요되는 시간에 가장 많이 좌우됩니다.

새 디스크 설치를 위한 다음 지침은 새 디스크를 AFS 볼륨을 저장할 수 있는 상태로 완전하게 준비합니다. 그런 다음 사용자는 vos create 명령을 사용하여 새 볼륨을 작성하거나 vos move 명령을 사용하여 다른 파티션에서 기존 볼륨을 이동할 수 있습니다. 지침을 보려면 읽기/쓰기 볼륨 작성 및 볼륨 이동을 참조하십시오. 디스크 제거 지침은 기본적으로 설치 지침의 역순으로 진행되지만 데이터 손실을 보호하기 위한 추가 단계가 포함됩니다.

하나의 서버 시스템은 256개의 AFS 서버 파티션을 저장할 수 있으며 각각은 양식 /vicepindex의 이름을 가진 디렉토리에 마운트됩니다. 여기서 index는 하나 이상의 소문자입니다. 일반적으로 시스템의 첫째 파티션을 /vicepa에, 둘째 파티션은 /vicepb에, 26번째 파티션은 /vicepz에 마운트되며 이러한 방식으로 계속됩니다. 추가 파티션은 /vicepaa에서 /vicepaz까지 마운트되고 /vicepiv까지 계속됩니다. 문자를 연속적으로 사용할 필요는 없으나 이렇게 하는 것이 훨씬 쉽습니다.

각 /vicep 디렉토리를 다른 디렉토리의 하위 디렉토리로가 아니라 로컬 파일 시스템의 루트 디렉토리(/ ) 아래에 직접 마운트하십시오. 예를 들면 /usr/vicepa는 허용되는 위치가 아닙니다. 또한 이 디렉토리를 파일 서버 시스템의 파일 시스템 레지스트리 파일(/etc/fstab 또는 동급)에 있는 파티션의 장치 이름에 맵핑해야 합니다.

이들 지침은 시스템의 AFS 초기설정 파일에 다음 명령이 포함되어 있어 각 재부트 후에 BOS 서버를 재시작한다고 가정합니다. BOS 서버는 로컬 /usr/afs/local/BosConfig 파일에 나열되어 있는 다른 AFS 서버 프로세스를 시작합니다. bosserver 명령의 선택적 인수에 대한 설명을 보려면 AFS Administration Reference에서 해당 참조 페이지를 참조하십시오.

    /usr/afs/bin/bosserver &

### AFS 볼륨을 저장할 새 디스크를 추가 및 마운트하려면

1. 시스템에서 로컬 수퍼유저 루트가 아닌 경우 su 명령을 실행하여 이러한 권한을 얻으십시오.

          % su root
          Password: root_password

2. 새 디스크를 나눌 AFS 파티션의 수와 이들을 마운트할 디렉토리의 이름을 결정하십시오(이 절의 소개 부분에서 명명 규칙 참고). 시스템에 있는 기존의 서버 파티션의 이름을 표시하려면 vos listpart 명령을 실행하십시오. 로컬 수퍼유저 root로 로그인했으므로 -localauth 플래그를 포함시키십시오. 그러나 관리 토큰을 반드시 가져야할 필요는 없습니다.

          # vos listpart <machine name> -localauth

   여기서

   listp
     허용되는 listpart의 가장 짧은 축약형입니다.

   machine name
     로컬 파일 서버 시스템을 명명합니다.

   -localauth
     로컬 /usr/afs/etc/KeyFile 파일의 키를 사용하여 서버 티켓을 구성합니다. bos 명령 인터프리터는 이 티켓을 상호 인증 중에 BOS 서버에 제시합니다.
3. 파티션을 마운트할 각 디렉토리를 작성하십시오.

          # mkdir /vicepx[x]

4. 문서 편집기를 사용하여 시스템의 파일 시스템 레지스트리 파일(/etc/fstab 또는 동급)에 새로운 각 디스크 파티션에 대한 항목을 작성하고 그 장치 이름을 이전 단계에서 작성한 디렉토리에 맵핑하십시오. 파일의 기존 항목을 참조하여 적절한 형식을 확인하십시오. 이 형식은 운영 체제마다 다릅니다.
5. 운영 체제에서 사용자가 새 디스크를 설치하기 위해 시스템을 종료하도록 요구하면 bos shutdown 명령을 실행하여 BOS 서버(이 서버는 사용자가 시스템을 종료할 때 안전하게 종료됨)를 제외한 모든 AFS 서버 프로세스를 종료하십시오. 로컬 수퍼유저 root로 로그인했으므로 -localauth 플래그를 포함시키십시오. 그러나 관리 토큰을 반드시 가져야할 필요는 없습니다. 명령에 대한 자세한 설명을 보려면 프로세스를 일시적으로 정지하려면을 참조하십시오.

          # bos shutdown <machine name>
       -localauth [-wait]

6. 필요하면 시스템을 종료하십시오. 디스크 및 운영 체제 공급 업체가 제공하는 지침에 따라 새 디스크를 설치하고 포맷하십시오. 필요하면 디스크 파티션 테이블을 편집하여 단계 4에서 사용자가 수행한 파일 시스템 레지스트리 파일 변경사항을 적용하십시오. 지침에 대해서는 운영 체제 설명서를 참조하십시오.
7. 단계 6에서 시스템을 종료한 경우 다시 켜십시오. 그렇지 않으면 bos restart 명령을 실행하여 fs 프로세스를 재시작하여 강제로 새로운 서버 파티션 집합을 인식하게 하십시오. 로컬 수퍼유저 root로 로그인했으므로 -localauth 플래그를 포함시키십시오. 그러나 관리 토큰을 반드시 가져야할 필요는 없습니다. bos restart 명령에 대한 자세한 설명을 보려면 프로세스를 정지한 후 즉시 재시작하기를 참조하십시오.

          # bos restart <machine name>
       fs -localauth

8. bos status 명령을 실행하여 모든 서버 프로세스가 제대로 실행되고 있는지 확인하십시오. 자세한 지침을 보려면 프로세스 상태와 BosConfig 파일의 정보 표시하기를 참조하십시오.

          # bos status <machine name>

### AFS 볼륨을 저장하는 디스크를 언마운트 및 제거하려면

1. 사용자가 /usr/afs/etc/UserList 파일에 나열되어 있는지 확인하십시오. 필요하면 UserList 파일에서 사용자를 표시하려면에서 자세히 설명되어 있는 bos listusers 명령을 실행하십시오.

          % bos listusers <machine name>

2. vos listvol 명령을 실행하여 볼륨을 제거하거나 다른 파티션으로 옮기기 위해 제거하려는 각 디스크의 각 파티션에 있는 볼륨을 나열하십시오. 지침을 보려면 볼륨 헤더 표시를 참조하십시오.

          % vos listvol <machine name> [<partition name>]

3. 파일 시스템에 보류하려는 볼륨을 다른 파티션으로 옮기십시오. 읽기/쓰기 볼륨만 옮길 수 있습니다. 자세한 지침과 읽기 전용 및 백업 볼륨의 이동에 대한 지침을 보려면 볼륨 이동을 참조하십시오.

          % vos move  <volume name or ID>  \
               <machine name on source> <partition name on source>  \
               <machine name on destination> <partition name on destination>

4. (선택적) 보유하지 않으려는 볼륨이 있으면 vos dump 명령이나 AFS 백업 시스템을 사용하여 이들을 백업하십시오. 각각 볼륨 덤프 및 복원 또는 데이터 백업을 참조하십시오.
5. 시스템에서 로컬 수퍼유저 루트가 아닌 경우 su 명령을 실행하여 이러한 권한을 얻으십시오.

          % su root
          Password: root_password

6. umount 명령을 제거할 디스크의 각 파티션에 대해 반복하여 실행하십시오.

          # cd /
          # umount /dev/<partition_block_device_name>

7. 문서 편집기를 사용하여 시스템의 파일 시스템 레지스트리 파일(/etc/fstab 또는 동급)에서 각 파티션의 항목을 제거하거나 주석 처리하십시오.
8. 각 파티션과 연관된 /vicep 디렉토리를 제거하십시오.

          # rmdir /vicepxx

9. 운영 체제에서 사용자가 새 디스크를 제거하기 위해 시스템을 종료하도록 요구하면 bos shutdown 명령을 실행하여 BOS 서버(이 서버는 사용자가 시스템을 종료할 때 안전하게 종료됨)를 제외한 모든 AFS 서버 프로세스를 종료하십시오. 로컬 수퍼유저 root로 로그인했으므로 -localauth 플래그를 포함시키십시오. 그러나 관리 토큰을 반드시 가져야할 필요는 없습니다. 명령에 대한 자세한 설명을 보려면 프로세스를 일시적으로 정지하려면을 참조하십시오.

          # bos shutdown <machine name> -localauth [-wait]

10. 필요하면 시스템을 종료하십시오. 디스크 및 운영 체제 공급 업체가 제공하는 지침에 따라 새 디스크를 제거하십시오. 필요하면 디스크 파티션 테이블을 편집하여 단계 7에서 사용자가 수행한 파일 시스템 레지스트리 파일 변경사항을 적용하십시오
11. 단계 10에서 시스템을 종료한 경우 다시 켜십시오. 그렇지 않으면 bos restart 명령을 실행하여 fs 프로세스를 재시작하여 강제로 새로운 서버 파티션 집합을 인식하게 하십시오. 로컬 수퍼유저 root로 로그인했으므로 -localauth 플래그를 포함시키십시오. 그러나 관리 토큰을 반드시 가져야할 필요는 없습니다. bos restart 명령에 대한 자세한 설명을 보려면 프로세스를 정지한 후 즉시 재시작하기를 참조하십시오.

           # bos restart <machine name>
        fs -localauth

12. bos status 명령을 실행하여 모든 서버 프로세스가 제대로 실행되고 있는지 확인하십시오. 자세한 지침을 보려면 프로세스 상태와 BosConfig 파일의 정보 표시하기를 참조하십시오.

           # bos status <machine name>

## 서버 IP 주소 및 VLDB 서버 항목 관리

다중홈 파일 서버 시스템에 대한 AFS 지원은 상당히 자동적입니다. 파일 서버 프로세스는 파일 서버 시스템의 네트워크 인터페이스의 IP 주소를 로컬 /usr/afs/local/sysid 파일에 기록하고 이들을 VLDB(Volume ocation Database)의 서버 항목에 등록합니다. sysid 파일 및 서버 항목은 동일한 고유 번호에 의해 식별되며 이 번호는 이들 사이에 연관을 생성합니다.

캐쉬 관리 프로그램이 볼륨 위치 정보를 요청할 때 볼륨 위치(VL) 서버는 해당 볼륨을 포함하는 각 서버 시스템에 대해 등록된 모든 인터페이스를 제공합니다. 이를 통해 캐쉬 관리 프로그램은 다중홈 파일 서버 시스템에 저장된 AFS 데이터를 액세스할 때 복수의 주소를 활용할 수 있습니다.

원하는 경우 로컬 /usr/afs/local 디렉토리에 두 파일 NetInfo와 NetRestrict를 작성하여 파일 서버가 VLDB 서버 항목에 등록하는 인터페이스를 제어할 수 있습니다. 파일 서버는 재시작될 때마다 NetInfo 파일이 있는 경우 이 파일을 읽고 로컬 시스템의 인터페이스 목록을 작성합니다. 사용자가 이 파일을 작성하지 않으면 파일 서버는 운영 체제에서 구성된 네트워크 인터페이스 목록을 사용합니다. 그런 다음 NetRestrict 파일에 있는 경우 이 파일에 나타난 주소를 목록에서 제거합니다. 파일 서버는 sysid 파일에 결과 목록을 기록하고 동일한 고유 ID를 가진 VLDB 서버 항목에 인터페이스를 등록합니다.

데이터베이스 서버 시스템에서 NetInfo 및 NetRestrict 파일은 Ubik 데이터베이스 동기화 라이브러리가 다른 데이터베이스 서버 시스템에서 실행되는 데이터베이스 서버 프로세스와 통신할 때 사용하는 인터페이스를 결정합니다.

AFS 릴리스 노트에서 설명하는 것처럼 각 서버 항목에는 최대 IP 주소 수가 있습니다. 다중홈 파일 서버 시스템이 이 최대 수보다 더 많은 인터페이스를 가지는 경우 AFS는 초과되는 인터페이스를 그냥 무시합니다. 이러한 시스템은 NetInfo 및 NetRestrict 파일을 사용하여 등록된 인터페이스를 제어하는 것이 좋습니다.

몇몇 이유로 인해 sysid 파일이 더 이상 존재하지 않으면 파일 서버는 새로운 고유 ID를 가진 새 파일을 작성합니다. 파일 서버가 새 파일의 내용을 등록할 때 볼륨 위치(VL) 서버는 새 파일이 기존의 서버 항목과 일치한다는 사실을 자동적으로 인식하고 기존 서버 항목을 새 파일 내용 및 ID로 덮어씁니다. 그러나 가능하면 sysid 파일을 제거하지 않는 것이 좋습니다.

이와 마찬가지로 sysid 파일을 한 파일 서버 시스템에서 다른 파일 서버 시스템으로 복사하는 것은 중요하지 않습니다. 일반적으로 /usr/afs 디렉토리의 내용을 기존 시스템으로부터 새 파일 서버 시스템 설치의 일부로서 복사하는 경우 파일 서버를 시작하기 전에 sysid 파일을 새 시스템의 /usr/afs/local 디렉토리에서 제거해야 합니다.

VL 서버가 기존의 서버 항목을 새 sysid 파일의 내용 및 ID로 대체되는 것이 적절한지 결정할 수 없는 특수한 경우가 있습니다. 이 경우 서버는 파일 서버가 인터페이스를 등록하는 것을 허용하지 않으므로 파일 서버가 시작되지 못하게 됩니다. 예를 들어 새 sysid 파일에 현재 별도의 서버 항목에 의해 등록되어 있는 두 개의 인터페이스가 포함되어 있는 경우 이러한 상황이 발생할 수 있습니다. 이러한 경우에 VL 서버 시스템의 /usr/afs/log/VLLog 파일과 파일 서버 시스템의 /usr/afs/log/FileLog 파일에 있는 오류 메시지는 사용자가 vos changeaddr 명령을 사용하여 이 문제점을 해결해야 한다고 알려 줍니다. 지침 및 도움을 얻으려면 AFS 제품 지원부에 문의하십시오.

이러한 드문 오류 경우를 제외하고 vos changeaddr 명령을 사용하는 것이 적절한 유일한 경우는 서비스에서 파일 서버 시스템을 제거할 때 VLDB 서버 항목을 완전히 제거할 때입니다. VLDB는 AFS 릴리스 노트에서 지정하는 것처럼 최대 수의 서버 항목을 수용할 수 있습니다. 이전 항목을 제거하면 필요할 때 새 파일 서버 시스템에 서버 항목을 할당할 수 있게 됩니다. 다음에 나오는 지침을 참조하십시오.

VLDB 서버 항목에 등록된 인터페이스 목록을 변경하는 데는 vos changeaddr 명령을 사용하지 마십시오. 파일 서버 시스템의 IP 주소와 서버 항목을 변경하려면 다음 지침을 따르십시오.

### 서버 NetInfo 파일을 작성하거나 편집하려면

1. 시스템에서 로컬 수퍼유저 루트가 아닌 경우 su 명령을 실행하여 이러한 권한을 얻으십시오.

          % su root
          Password: root_password

2. 문서 편집기를 사용하여 /usr/afs/local/NetInfo 파일을 여십시오. IP 주소를 점분리 십진 형식(예: `192.12.107.33`)으로 각 행에 추가하십시오. 향목의 순서는 중요하지 않습니다.
3. 파일 서버가 수정된 목록을 사용하여 즉시 시작되게 하려면 bos restart 명령을 사용하여 fs 프로세스를 재시작하십시오. 지침을 보려면 프로세스를 정지한 후 즉시 재시작하기를 참고하십시오

### 서버 NetRestrict 파일을 작성하거나 편집하려면

1. 시스템에서 로컬 수퍼유저 루트가 아닌 경우 su 명령을 실행하여 이러한 권한을 얻으십시오.

          % su root
          Password: root_password

2. 문서 편집기를 사용하여 /usr/afs/local/NetRestrict 파일을 여십시오. IP 주소를 점분리 십진 형식으로 각 행에 추가하십시오. 주소의 순서는 중요하지 않습니다. 값 255를 해당 필드의 가능한 모든 주소를 나타내는 와일드 카드로 사용하십시오. 예를 들어 항목 `192.12.105.255`는 캐쉬 관리 프로그램이 192.12.105 서브넷에 어떠한 주소도 등록하지 않음을 나타냅니다.
3. 파일 서버가 수정된 목록을 사용하여 즉시 시작되게 하려면 bos restart 명령을 사용하여 fs 프로세스를 재시작하십시오. 지침을 보려면 프로세스를 정지한 후 즉시 재시작하기를 참고하십시오

### VLDB에서 모든 서버 항목을 표시하려면

1. vos listaddrs 명령을 실행하여 VLDB로부터 모든 서버 항목을 표시하십시오.

          % vos listaddrs

   여기서 lista는 허용되는 listaddrs의 가장 짧은 축약형입니다.

   출력은 자체의 각 행에 VLDB로부터의 모든 서버 항목을 표시합니다. 파일 서버 시스템이 다중홈 형식이면 그 등록된 모든 주소가 해당 행에 나타납니다. 첫 번째 항목은 vos examine 및 vos listvldb 명령의 출력에 볼륨의 사이트로 보고되는 것입니다.

   VLDB 서버 항목은 IP 주소를 기록하고, 명령 인터프리터는 로컬 이름 서비스(도메인 이름 서비스나 로컬 호스트 테이블과 같은 프로세스)에서 이 IP 주소를 표시하기 전에 호스트 이름으로 변환하도록 합니다. IP 주소가 출력에 나타나면 변환할 수 없습니다.

   항목이 존재한다고 해서 시스템이 파일 서버 시스템으로 계속 작동한다는 것을 의미하지는 않습니다. 이전 서버 항목을 제거하려면 다음 지침을 참조하십시오.

### VLDB에서 이전 서버 항목을 제거하려면

1. 사용자가 /usr/afs/etc/UserList 파일에 나열되어 있는지 확인하십시오. 필요하면 UserList 파일에서 사용자를 표시하려면에서 자세히 설명되어 있는 bos listusers 명령을 실행하십시오.

          % bos listusers <machine name>

2. vos changeaddr 명령을 실행하여 VLDB에서 서버 항목을 제거하십시오.

          % vos changeaddr <original IP address> -remove

   여기서

   ch
     허용되는 changeaddr의 가장 짧은 축약형입니다.

   original IP address
     현재 VLDB의 파일 서버 시스템에 대해 등록되어 있는 IP 주소 중 하나를 지정합니다. 식별을 위해 다중홈 파일 서버 시스템의 주소가 사용될 수 있습니다.

   -remove
     서버 항목을 제거합니다.

### 서버 시스템의 IP 주소를 변경하려면

1. 사용자가 /usr/afs/etc/UserList 파일에 나열되어 있는지 확인하십시오. 필요하면 UserList 파일에서 사용자를 표시하려면에서 자세히 설명되어 있는 bos listusers 명령을 실행하십시오.

          % bos listusers <machine name>

2. 시스템이 시스템 제어 시스템이나 2진 분산 시스템이고 사용자가 호스트 이름을 변경하는 경우 새 호스트 이름을 참조하도록 다른 서버 시스템의 모든 해당 upclient 프로세스를 재정의하십시오. 프로세스 작성 및 제거의 지침에 따라 bos delete 및 bos create 명령을 사용하십시오.
3. 시스템이 데이터베이스 서버 시스템인 경우 셀의 모든 서버 시스템에 있는 /usr/afs/etc/CellServDB 파일에서 해당 항목을 편집하여 새 IP 주소 중 하나를 나열하게 하십시오. 미국판 AFS를 사용하는 경우 시스템 제어 시스템에서 이 파일을 편집하고 갱신 서버가 변경된 파일을 모든 서버 시스템에 분배할 때까지 요구되는 시간을 (기본적으로 5분) 기다릴 수 있습니다.
4. 시스템이 데이터베이스 서버 시스템인 경우 bos shutdown 명령을 실행하여 모든 서버 프로세스를 중지하십시오. 시스템이 파일 서버이기도 한 경우 이 서버의 볼륨은 이 시간 동안 액세스할 수 없습니다. 명령에 대한 자세한 설명을 보려면 프로세스를 일시적으로 정지하려면을 참조하십시오.

          % bos shutdown <machine name>

5. 운영 체제에서 제공하는 유틸리티를 사용하여 시스템의 하나 이상의 IP 주소를 변경하십시오.
6. 적절한 경우 /usr/afs/local/NetInfo 파일이나 /usr/afs/local/NetRestrict 파일 또는 둘 다를 편집하여 변경된 주소를 반영하게 하십시오. 관련 지침은 이 절의 앞 부분을 참조하십시오.
7. 시스템이 데이터베이스 서버 시스템인 경우 bos restart 명령을 실행하여 시스템의 모든 서버 프로세스를 재시작하십시오. bos restart 명령에 대한 자세한 설명을 보려면 프로세스를 정지한 후 즉시 재시작하기를 참조하십시오.

          % bos restart <machine name> -all

   동시에 셀의 다른 모든 데이터베이스 서버 시스템에 대해 bos restart 명령을 실행하여 데이터베이스 서버 프로세스(인증, 백업, 보호 및 볼륨 위치 서버)만 재시작하십시오. 이들 명령을 빠르게 연속해서 실행하여 모든 데이터베이스 서버 프로세스가 쿼럼 선택에 참여하게 하십시오.

          % bos restart <machine name> kaserver buserver ptserver vlserver

   셀의 모든 데이터베이스 서버 시스템에서 IP 주소를 변경하는 경우 셀의 모든 파일 서버 시스템에 대해서 bos restart 명령을 실행하여 fs 프로세스를 재시작해야 합니다.

8. 시스템이 데이터베이스 서버 시스템이 아닌 경우 bos restart 명령을 실행하여 fs 프로세스를 재시작하십시오(시스템이 데이터베이스 서버인 경우 이전 단계에서 이미 이 프로세스를 재시작했습니다). 파일 서버는 새로운 인터페이스 목록을 자동으로 컴파일하고, 이를 /usr/afs/local/sysid 파일에 기록하고, VLDB 서버 항목에 등록합니다.

          % bos restart <machine name> fs

9. 시스템이 데이터베이스 서버 시스템인 경우 셀의 모든 클라이언트 시스템에 잇는 /usr/vice/etc/CellServDB 파일에서 해당 항목을 편집하여 새 IP 주소 중 하나를 나열하게 하십시오. 데이터베이스 서버 시스템 정보 유지의 지침을 따르십시오.
10. 시스템의 이전 IP 주소에 대한 시스템 항목이 보호 데이터베이스에 있는 경우 pts rename 명령을 사용하여 이를 새 주소로 변경하십시오. 지침을 보려면 보호 데이터베이스 항목의 이름 변경을 참고하십시오

## 서버 시스템 재부팅

콘솔에 적절한 명령을 입력하거나 원격 시스템에서 bos exec 명령을 실행하여 서버 시스템을 재부팅할 수 있습니다. 원격 재부팅은 사용자가 현재 위치를 떠날 필요가 없어서 좀더 편리할 수 있으나 콘솔에서 재부트 과정을 추적할 수 없습니다. 원격 재부팅은 서버 시스템의 운영 체제가 로컬 수퍼유저 루트로서 bos exec 명령을 실행하는 BOS 서버를 인식하기 때문에 가능합니다.

서버 시스템을 재부팅하는 것은 일부 셀에서는 루틴 유지보수의 일부이며 AFS 설명서에는 몇몇 지침이 하나의 단계 형태로 포함되어 있습니다. 이것은 AFS 관련 문제점에서 복구하기 위한 표준 방법으로 간주되지는 않으며 시스템이 응답하지 않으며 사용자가 다른 모든 옵션을 시도했을 때 사용할 수 있는 마지막 방법입니다.

재부팅을 수행하면 서비스 작동 중단 상태가 발생합니다. 시스템이 볼륨을 저장하는 경우 재부트가 완료되고 파일 서버가 볼륨에 다시 접속해야만 해당 볼륨을 액세스할 수 있습니다. 시스템이 데이터베이스 서버 시스템이면 각 데이터베이스 서버 프로세스에 대한 동기화 사이트의 재선택 중에 데이터베이스의 정보를 사용할 수 없습니다. VL 서버 작동 중단은 캐쉬 관리 프로그램이 AFS 데이터를 페치하기 위해 VLDB를 액세스할 수 있어야 하므로 가장 심각한 영향을 가져옵니다.

일반적으로 서버 시스템의 AFS 초기설정 파일에는 각 재부트 후에 BOS 서버를 재시작하기 위한 다음 명령이 들어 있습니다. 이 명령은 로컬 /usr/afs/local/BosConfig 파일에 나열된 다른 AFS 서버 프로세스를 시작합니다. 이들 지침은 초기설정 파일에 이 명령이 들어 있다고 가정합니다.

    /usr/afs/bin/bosserver &

### 콘솔에서 파일 서버 시스템을 재부팅하는 방법

1. 시스템에서 로컬 수퍼유저 루트가 아닌 경우 su 명령을 실행하여 이러한 권한을 얻으십시오.

          % su root
          Password: root_password

2. bos shutdown 명령을 실행하여 사용자가 시스템을 재부트할 때 안전하게 종료되는 BOS 서버를 제외한 모든 AFS 서버 프로세스를 종료하십시오. 로컬 수퍼유저 root로 로그인했으므로 -localauth 플래그를 포함시키십시오. 그러나 관리 토큰을 반드시 가져야할 필요는 없습니다. 명령에 대한 자세한 설명을 보려면 프로세스를 일시적으로 정지하려면을 참조하십시오.

          # bos shutdown <machine name> -localauth [-wait]

3. 시스템을 재부트하십시오. 많은 시스템 유형에서 적절한 명령은 shutdown이지만 적절한 옵션을 달라질 수 있습니다. UNIX 관리자 안내서를 참조하십시오.

           # shutdown

### 파일 서버 시스템을 원격에서 재부팅하는 방법

1. 재부팅하고 있는 시스템의 /usr/afs/etc/UserList 파일에 사용자가 나열되어 있는지 확인하십시오. 필요하면 UserList 파일에서 사용자를 표시하려면에서 자세히 설명되어 있는 bos listusers 명령을 실행하십시오.

          % bos listusers <machine name>

2. bos shutdown 명령을 실행하여 사용자가 시스템을 종료할 때 안전하게 종료되는 BOS 서버를 제외한 AFS 서버 프로세스를 중지하십시오. 명령에 대한 자세한 설명을 보려면 프로세스를 일시적으로 정지하려면을 참조하십시오.

          % bos shutdown <machine name>
       [-wait]

3. bos exec 명령을 실행하여 시스템을 원격에서 재부팅하십시오.

          % bos exec <machine name> reboot_command

   여기서

   machine name
     재부팅할 파일 서버 시스템을 명명합니다.

   reboot_command
     시스템의 운영 체제에 대한 재부팅 명령입니다. shutdown 명령은 많은 시스템 유형에 대해 적절하지만 운영 체제 설명서를 참조하십시오.

[ 페이지의 맨 위 | 이전 페이지 | 다음 페이지 | 목차 | 색인 ]

© IBM Corporation 2000. All Rights Reserved