이 장에서는 AFS 서버 시스템을 관리하는 방법을 설명합니다. 또한 다음의 구성 정보와 관리 타스크에 대해서도 설명합니다.
새 서버 시스템을 설치하고 구성하는 방법을 보려면 AFS 빠른 시작을 참조하십시오.
서버가 프로세스 자체를 관리하는 방법을 알려면 서버 프로세스 모니터 및 제어를 참조하십시오.
볼륨을 관리하는 방법을 알려면 볼륨 관리를 참조하십시오.
이 장에서는 지정된 명령을 사용하여 다음 타스크를 수행하는 방법을 설명합니다.
| 새 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 디렉토리는 시스템(CPU 및 운영 체제) 유형에 적절한 AFS 서버 프로세스 및 명령 집합 2진 파일을 저장합니다. 프로세스에 서버 부분과 클라이언트 부분이 모두 있는 경우(갱신 서버의 경우와 유사) 또는 별도의 구성요소를 가지는 경우(fs 프로세스의 경우와 유사) 각 구성요소는 별도의 파일에 위치합니다.
예측 가능한 시스템 성능을 보장하기 위해 모든 파일 서버 시스템은 주어진 프로세스의 동일한 AFS 빌드 버전을 실행해야 합니다. 일관성을 유지하기 위해 2진 분산 시스템에서 설명하는 것처럼 갱신 서버 프로세스를 사용하여 각 시스템 유형의 2진 분산 시스템으로부터 2진 파일을 분배하십시오.
시스템에서 능동적으로 프로세스를 실행하지 않는 경우에도 /usr/afs/bin 디렉토리에 모든 프로세스에 대한 2진 파일을 보관하는 것이 좋습니다. 이렇게 하면 시스템을 재구성하는 프로세스가 단순해 집니다(예를 들어 기존 파일 서버 시스템에 데이터베이스 서버 기능을 추가). 이와 마찬가지로 서버 시스템에서 작업하는 동안 명령을 자주 실행하지 않는 경우에도 디렉토리에 명령 집합 2진 파일을 보관하는 것이 바람직합니다. 이렇게 하면 서버 및 시스템으로부터의 복구 작업 중에 명령을 실행할 수 있습니다.
다음은 AFS 서버 프로세스 또는 명령 집합과 직접 관련되어 있는 /usr/afs/bin 디렉토리의 2진 파일을 나열합니다. 다른 2진 파일(예: klog 명령 관련)은 특정 파일 서버 시스템의 디스크나 AFS 분산의 해당 디렉토리에 나타날 수 있습니다.
모든 파일 서버 시스템의 로컬 디스크에 있는 디렉토리 /usr/afs/etc에는 구성 파일이 ASCII 및 시스템 독립 2진 형식으로 포함되어 있습니다. 셀 전체에서 AFS 성능을 예측할 수 있으려면 다음과 같이 모든 서버 시스템이 각 구성 파일의 동일한 버전을 포함해야 합니다.
긴급한 상황에 대한 다른 지침이 있는 경우를 제외하고 /usr/afs/etc 디렉토리의 파일을 직접 편집하지 마십시오. 일반적인 상황에서는 적절한 bos 명령을 사용하여 파일을 변경하십시오. 다음 목록에는 명령어(instruction)로의 포인터가 들어 있습니다.
이 디렉토리의 파일에는 다음이 포함됩니다.
서버 CellServDB 파일은 클라이언트 시스템의 /usr/vice/etc 디렉토리에 있는 CellServDB 파일과 같지 않습니다. 클라이언트 버전 파일은 클라이언트 시스템에서 액세스할 수 있도록 사용자가 선택한 모든 AFS 셀에 대한 데이터베이스 서버 시스템을 나열합니다. 서버 CellServDB 파일은 서버 프로세스가 다른 셀의 프로세스에는 접속하지 않으므로 로컬 셀의 데이터베이스 서버 시스템만 나열합니다.
이 파일의 유지 관리에 대한 지침을 보려면 서버 CellServDB 파일 유지를 참조하십시오.
이 파일의 유지 관리에 대한 지침을 보려면 서버 암호화 키 관리를 참조하십시오.
이 파일을 변경하는 것은 셀의 이름을 변경하는 작업의 한 단계에 불과하다는 점을 알아 두십시오. 자세한 설명을 보려면 셀 이름 선택을 참조하십시오.
디렉토리 /usr/afs/local에는 셀의 각 파일 서버 시스템에 대해 각기 다른 구성 파일이 들어 있습니다. 따라서 /usr/afs/bin 및 /usr/afs/etc 디렉토리에 있는 파일과 같이 중앙 소스로부터 자동으로 갱신되지 않습니다. 가장 중요한 파일은 BosConfig 파일로 이 파일은 해당 시스템에서 실행된 서버 프로세스를 정의합니다.
/usr/afs/etc의 일반 구성 파일처럼 이들 파일은 직접 편집하면 안됩니다. 적절한 위치에서 bos 명령 집합의 명령을 사용하십시오. 일부 파일은 절대 변경할 필요가 없습니다.
이 디렉토리의 파일에는 다음이 포함됩니다.
파일 서버 시스템의 설치 중에 서버 프로세스를 작성할 때 관련 항목은 이 파일에 자동으로 정의됩니다. AFS 빠른 시작에서는 사용할 bos 명령을 대략적으로 설명합니다. 파일에 대한 자세한 설명과 bos 집합의 명령을 사용하여 파일을 편집하여 프로세스 상태를 제어하는 방법에 대해서는 서버 프로세스 모니터 및 제어를 참조하십시오.
이 파일은 초기 bosserver 프로세스를 -noauth 플래그와 함께 시작하거나 bos setauth 명령을 실행하여 인증 요구조건을 해제할 때 자동으로 작성됩니다. bos setauth 명령을 사용하여 인증을 사용 가능하게 할 때 BOS 서버가 이 파일을 제거합니다. 자세한 내용은 인증 관리 및 권한 부여 요구조건을 참조하십시오
이 파일을 직접 작성하거나 제거하지 마십시오. BOS 서버는 자동으로 작성되거나 제거됩니다. 필요하면 bos salvage 명령을 사용하여 볼륨이나 파티션을 구조할 수 있습니다. 볼륨 구조를 참조하십시오.
디렉토리 /usr/afs/db에는 셀의 복제된 네 개의 데이터베이스인 인증 데이터베이스, 백업 데이터베이스, 보호 데이터베이스 및 VLDB(Location Database)와 관련된 두 가지 유형의 파일이 들어 있습니다.
각 데이터베이스 서버 프로세스(인증, 백업, 보호 또는 VL 서버)는 자체의 데이터베이스와 로그 파일을 유지합니다. 데이터베이스 파일은 2진 형식이므로 항상 kas 집합(인증 데이터베이스 관련), backup 집합(백업 데이터베이스 관련), pts 집합(보호 데이터베이스 관련) 또는 vos 집합(VLDB 관련)으로부터 명령을 사용하여 이들을 액세스하거나 변경해야 합니다.
셀에서 둘 이상의 데이터베이스 서버 시스템이 실행되는 경우 각 데이터베이스 서버 프로세스는 시스템의 하드 디스크에 자체의 데이터베이스 사본을 보관합니다. 그러나 주어진 데이터베이스의 모든 사본이 동일해야 합니다. 이들 사본을 동기화하기 위해 데이터베이스 서버 프로세스는 AFS 관리 데이터베이스 복제에서 설명하는 것처럼 AFS의 분산 데이터베이스 기술인 Ubik를 사용합니다.
여기에 나열된 파일은 데이터베이스 서버 시스템의 이 디렉토리에만 나타납니다. 비 데이터베이스 서버 시스템에서는 이 디렉토리가 비어 있습니다.
/usr/afs/logs 디렉토리에는 다양한 서버 프로세스의 로그 파일이 들어 있습니다. 이 파일은 표준 작업 중에 발생하는 중요한 이벤트를 상세히 설명합니다. 예를 들어 볼륨 서버는 VolserLog 파일에 볼륨 이동을 기록할 수 있습니다. 이벤트는 완료시 기록되므로 서버 프로세스는 /usr/afs/db 디렉토리의 작업과 달리 실패한 작업을 재구성하기 위해 이 파일을 사용하지 않습니다.
로그 파일의 정보는 프로세스 실패 및 다른 문제점을 평가할 때 매우 유용할 수 있습니다. 예를 들어 볼륨을 액세스하려고 할 때 제한시간 메시지를 수신할 경우 FileLog 파일에서 파일 서버가 해당 볼륨을 사용할 수 없음을 보여 주는 설명을 볼 수 있습니다. 원격에서 로그 파일을 검토하려면 서버 프로세스 로그 파일 표시의 설명대로 bos getlog 명령을 사용하십시오.
이 디렉토리에는 BOS 서버에 의해 모니터되는 프로세스가 중단될 경우 생성되는 코어 이미지 파일도 들어 있습니다. BOS 서버는 표준 core 이름에 확장자를 추가하여 프로세스가 생성한 코어 파일을 나타냅니다(예를 들면 보호 서버에서 생성한 코어 파일을 core.ptserver라고 명명). BOS 서버는 두 프로세스가 거의 동시에 실패할 경우 올바른 확장자를 지정할 수 없으므로 올바른지 보장할 수 없습니다.
이 디렉토리는 다음 파일을 포함합니다.
| 주: | 로그 파일이 관리할 수 없을 만큼 커지지 않게 하려면 서버 프로세스, 특히 데이터베이스 서버 프로세스를 주기적으로 재시작하십시오. 프로세스가 재시작되지 않게 하려면 UNIX rm 명령을 사용하여 프로세스가 실행될 때 파일을 제거하십시오. 이 파일은 자동으로 재작성됩니다. |
AFS 볼륨을 포함하는 파티션은 시스템의 루트( / ) 디렉토리의 하위 디렉토리(/usr 디렉토리 아래는 아님)에 마운트되어야 합니다. 파일 서버 시스템의 파일 시스템 레지스트리 파일(/etc/fstab 또는 동급)은 디렉토리 이름과 파티션의 장치 이름을 제대로 맵핑해야 합니다. 디렉토리 이름은 양식 /vicepindex를 가지며 여기서 각 index는 하나 또는 둘의 소문자로 구성됩니다. 일반적으로 시스템의 첫째 AFS 파티션은 /vicepa에, 둘째 파티션은 /vicepb에 마운트되며 이와 같은 방식으로 계속 진행됩니다. 26개보다 많은 수의 파티션이 있으면 /vicepaa, /vicepab 등과 같이 계속됩니다. AFS 릴리스 노트에서는 서버 시스템당 지원되는 파티션의 수를 지정합니다.
AFS 파티션에 비 AFS 파일을 저장하지 않도록 하십시오. 파일 서버 및 볼륨 서버는 파티션의 모든 공간을 사용할 수 있습니다.
/vicep 디렉토리에는 다음의 두 가지 유형의 파일이 들어 있습니다.
| 주: | 대부분의 시스템 유형에서 AFS 파일 서버 시스템에서 운영 체제에 기본적으로 제공되는 표준 fsck 프로그램을 절대 실행하지 마십시오. 이 프로그램은 AFS 볼륨 형식을 인식하지 못하므로 서버 파티션에서 모든 AFS 볼륨 데이터를 제거합니다. |
둘 이상의 서버 시스템이 있는 셀에서 모든 서버 시스템이 정확히 동일한 기능을 수행해야 하는 것은 아닙니다. 실행되는 서버 프로세스에 따라 시스템이 가정할 수 있는 가능한 네 가지 역할이 있습니다. 하나의 시스템은 적절한 모든 프로세스를 실행하여 둘 이상의 역할을 가정할 수 있습니다. 다음 목록은 네 가지 역할을 요약해서 설명하며 이 역할에 대해서는 다음 절에서 좀더 상세히 설명합니다.
셀에 단일 서버 시스템이 있는 경우 단순 파일 서버 및 데이터베이스 서버 역할을 가정합니다. AFS 빠른 시작의 지시에 따르면 사용자는 시스템을 시스템 제어 시스템 2진 분산 시스템으로 구성하게 되지만 사용자가 다른 서버 시스템을 설치할 때까지 시스템에서 실제로 이러한 기능을 수행하지는 않습니다.
모든 프로세스가 실행되지 않는 경우에도 /usr/afs/bin 디렉토리에 모든 AFS 서버 프로세스에 대한 2진 파일을 보관하는 것이 좋습니다. 그런 다음 단순히 역할을 정의하는 프로세스를 시작하거나 정지하여 시스템이 가정하는 역할을 변경할 수 있습니다.
단순 파일 서버 시스템은 클라이언트 시스템에 AFS 파일을 저장 및 전달하고, 프로세스 상태를 모니터하고, 셀의 2진 분산 및 시스템 제어 시스템으로부터 2진 및 구성 파일을 선택하는 서버 프로세스만 실행합니다.
일반적으로 네 대 이상의 서버 시스템이 있는 셀에서만 단순 파일 서버 시스템을 실행할 필요가 있습니다. 세 대 이하의 시스템이 있는 셀에서는 모든 서버 시스템이 보통 데이터베이스 서버 시스템이 됩니다(관리 데이터베이스를 복제하여 이점을 얻을 수 있음). 데이터베이스 서버 시스템을 참조하십시오.
다음 프로세스는 단순 파일 서버 시스템에서 실행됩니다.
데이터베이스 서버 시스템은 각각 인증 데이터베이스, 백업 데이터베이스, 보호 데이터베이스 및 VLDB(Location Database)를 유지하는 인증 서버, 백업 서버, 보호 서버 및 볼륨 위치(VL) 서버의 AFS 복제 관리 데이터베이스를 유지하는 네 가지 프로세스를 실행합니다. 이들 서버 프로세스 및 그 데이터베이스의 기능을 살펴보려면 AFS 서버 프로세스 및 캐쉬 관리 프로그램을 참조하십시오.
셀에 두 대 이상의 서버 시스템이 있는 경우 둘 이상의 데이터베이스 서버 시스템을 실행하는 것이 가장 좋으나 네 대 이상의 시스템은 거의 필요하지 않습니다. 이러한 방식으로 데이터베이스를 복제하면 사용 효율 및 정보의 신뢰성 증가와 같이 볼륨을 복제하는 것과 동일한 이점을 얻을 수 있습니다. 한 데이터베이스 서버 시스템이나 프로세스가 기능을 중단해도 해당 데이터베이스의 정보를 계속 사용할 수 있습니다. 데이터베이스 정보 요청에 따른 작업 부하는 여러 시스템에 분산되므로 한 시스템이 과부하되는 일이 없습니다.
그러나 복제된 데이터베이스는 복제된 볼륨과는 달리 자주 변경됩니다. 일관된 시스템 성능을 발휘하기 위해서는 모든 사본의 데이터베이스가 항상 동일해야 하므로 사본 중 일부만 변경 내용을 기록할 수 있습니다. 데이터베이스 사본을 동기화하기 위해 데이터베이스 서버 프로세스는 AFS의 분산 데이터베이스 기술인 Ubik를 사용합니다. AFS 관리 데이터베이스 복제를 참조하십시오.
셀에 있는 모든 서버 시스템의 AFS 서버 프로세스가 어떤 시스템이 데이터베이스 서버 시스템인지 인식하는 것은 중요합니다. 데이터베이스 서버 프로세스는 특히 데이터베이스 사본을 통합하기 위해 피어와 계속적으로 접속을 유지해야 합니다. 다른 서버 프로세스는 종종 데이터베이스의 정보를 필요로 합니다. 모든 파일 서버 시스템은 로컬 /usr/afs/etc/CellServDB 파일에 셀의 데이터베이스 서버 시스템 목록을 유지합니다. 미국판 AFS를 사용하는 셀은 시스템 제어 시스템을 사용하여 이 파일을 분배할 수 있습니다 (시스템 제어 시스템 참고).
다음 프로세스는 데이터베이스 서버 시스템을 정의합니다.
데이터베이스 서버 시스템은 단순 파일 서버 시스템에 나열된 것처럼 단순 파일 서버 시스템을 정의하는 프로세스도 실행할 수 있습니다. 하나의 데이터베이스 서버 시스템은 셀의 시스템 제어 시스템으로 작동할 수 있으며 다른 데이터베이스 서버 시스템은 시스템 유형에 대한 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) 프로세스의 클라이언트 부분을 변경해야 합니다.
다음 프로세스는 시스템 제어 시스템을 정의합니다.
시스템 제어 시스템은 단순 파일 서버 시스템에 나열된 것처럼 단순 파일 서버 시스템을 정의하는 프로세스도 실행할 수 있습니다. 이 기계는 데이터베이스 서버 시스템으로 작동하며 일반적으로 해당 시스템 유형에 대한 2진 분산 시스템으로 작동합니다. 단일 upserver 프로세스는 구성 파일과 2진 파일을 모두 분배할 수 있습니다. 데이터베이스 서버 시스템 및 2진 분산 시스템을 참조하십시오.
% bos listhosts <machine name>
출력 결과에 나열된 시스템은 셀의 데이터베이스 서버 시스템입니다. 자세한 지침과 예제 출력 결과를 보려면 셀의 데이터베이스 서버 시스템을 표시하려면을 참조하십시오.
% 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.
% bos status <machine name> upserver upclientbin upclientetc -long
화면에 표시되는 출력은 단순 파일 서버 시스템, 시스템 제어 시스템 또는 2진 분산 시스템 등과 같이 사용자가 접속하고 있는 시스템에 따라 달라집니다. bos status 명령으로부터 출력 해석을 참조하십시오.
% bos status <machine name> upserver upclientbin upclientetc -long
화면에 표시되는 출력은 단순 파일 서버 시스템, 시스템 제어 시스템 또는 2진 분산 시스템 등과 같이 사용자가 접속하고 있는 시스템에 따라 달라집니다. 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진 분산 시스템에 대해 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는 Ubik라는 유틸리티 라이브러리를 사용합니다. 각 데이터베이스 서버 프로세스는 연관된 경량급 Ubik 프로세스를 사용하고 클라이언트측 프로그램은 데이터베이스를 읽고 변경하기 위한 요청을 제출할 때 Ubik의 클라이언트측 서브루틴을 호출합니다.
Ubik는 적절한 Ubik 작업을 위한 셀 구성에서 자세히 설명하는 것처럼 최소의 관리자 개입으로도 작동될 수 있도록 고안되었으나 몇 가지 구성 요구조건이 적용됩니다. 다음에 나오는 Ubik 작업에 대한 간단한 개요는 이러한 요구조건을 이해하는 데 도움이 될 것입니다. 자세한 정보를 보려면 Ubik가 자동으로 작동되는 방식을 참조하십시오.
Ubik는 AFS 관리 데이터베이스에 대해 수행된 변경사항을 가능한 빨리 모든 사본으로 분배하도록 고안되었습니다. 동기화 사이트인 하나의 데이터베이스 사본만 클라이언트의 변경 요청을 승인합니다. 여기에서 실행되는 가벼운 Ubik 프로세스는 Ubik 조정자입니다. 최대 사용 효율을 유지하기 위해 각 데이터베이스에 대해 별도의 Ubik 조정자가 있으며 네 개의 각 데이터베이스에 대한 동기화 사이트는 다른 시스템에 위치할 수 있습니다. 데이터베이스의 동기화 사이트는 프로세스, 시스템 또는 네트워크 작동 중지가 발생할 때 다른 시스템으로 이동될 수 있습니다.
데이터베이스의 다른 사본 및 이들을 유지하는 Ubik 프로세스를 보조라고 합니다. 보조 사이트는 동기화 사이트를 제외하고 클라이언트측 프로그램으로부터의 직접적인 데이터베이스 변경을 승인하지 않습니다.
Ubik 조정자는 데이터베이스 사본에 변경 사항을 기록한 후에 즉시 변경 사항을 보조 사이트로 보냅니다. 짧은 분배 기간 동안 클라이언트는 데이터베이스 사본을 액세스할 수 없으며 읽는 것도 불가능합니다. 조정자가 대부분의 보조 사이트에 도달할 수 없으면 분배를 멈추고 시도된 변경이 실패했다는 사실을 클라이언트에게 알립니다.
분배 실패를 피하기 위해 Ubik 프로세스는 시간 소인 메시지를 교환하여 일정한 접속 상태를 유지합니다. 대부분의 보조 사이트가 조정자의 메시지에 응답하기만 하면 조정자와 동기화되는 사이트 쿼럼이 존재하게 됩니다. 프로세스, 시스템 또는 네트워크 작동 중지로 인해 쿼럼이 깨지면 Ubik 프로세스는 가능한 가장 높은 사이트 수 중에서 새로운 쿼럼을 설정하기 위해 새로운 조정자를 선택하려고 합니다. 융통성 있는 조정자를 통한 사용 효율 증대를 참조하십시오.
이 절에서는 적절한 Ubik 작업을 유지할 수 있도록 셀을 구성하는 방법을 설명합니다.
CellServDB 파일에 나열되어 있는 모든 데이터베이스 서버 시스템을 제외하고 Ubik의 클라이언트 및 서버 부분은 모든 데이터베이스 서버 프로세스를 실행하고 있습니다. 일부 데이터베이스 서버 프로세스만 한 시스템에서 실행되고 있음을 나타내기 위한 메카니즘은 없습니다.
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 프로세스는 가벼우므로 UNIX ps 명령에 의해 생성된 것과 같은 프로세스 목록에 나타나지 않습니다. 데이터베이스를 읽고 변경해야 하는 클라이언트측 프로그램은 별도의 가벼운 프로세스를 실행하지 않고 Ubik 라이브러리의 클라이언트 부분에서 직접 서브루틴을 호출합니다. 이러한 프로그램의 예로 klog 명령과 pts 집합의 명령을 들 수 있습니다.
조정자는 데이터베이스에 대한 변경 사항을 기록할 때 데이터베이스의 버전 번호를 점층적으로 늘립니다. 버전 번호를 사용하면 조정자는 사이트가 가장 최근 버전인지 여부를 쉽게 결정할 수 있습니다. 이 버전 번호는 새 조정자를 선택한 다음에 또는 작동 중지 이후 통신이 복원될 때 정상 작동으로 되돌아가는 속도를 줄여 줍니다. 왜냐하면 어떤 사이트가 가장 현재의 데이터베이스를 가지고 있는지와 어떤 사이트를 갱신해야 하는지를 쉽게 알 수 있기 때문입니다.
데이터 사용 효율을 높이기 위해 데이터베이스를 복제한다는 것은 모든 데이터베이스 사본이 동일하지 않을 경우에는 무의미합니다. 클라이언트가 어떤 데이터베이스 사본을 액세스하는가에 따라 다른 정보를 얻게 된다면 일관되지 못한 성능 결과가 나타날 수 있습니다. 앞서 설명한 것처럼 Ubik 사이트는 시간 소인이 찍힌 메시지를 교환함으로써 피어의 상태를 계속 추적합니다. 자세한 설명을 보려면 Ubik에서 시간 소인이 찍힌 메시지를 사용하는 방법을 참조하십시오.
예를 들어 세 대의 데이터베이스 서버 시스템을 가지는 셀에서 하나의 네트워크 파티션이 조정자로부터 두 개의 보조 사이트를 분리한다고 가정해 봅시다. 이 조정자는 더 이상 CellServDB 파일에 나열되어 있는 대부분의 사이트와 접속되어 있지 않으므로 작동을 멈춥니다. 파티션의 다른 쪽에 있는 두 사이트는 새 조정자를 선택할 수 있으며 클라이언트로부터 데이터베이스 변경 사항을 승인할 수 있습니다. 이 조정자가 이러한 방식으로 작동하지 않으면 네트워크 파티션이 복구될 때까지 데이터베이스는 읽기 전용이어야 합니다. 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 변경사항은 가장 많이 발생하며 사용자가 그룹을 추가 또는 삭제하고 그룹 멤버쉽을 변경할 때, 사용자 및 다른 관리자가 볼륨을 작성하거나 이동할 때 발생합니다. 변경사항의 수와 빈도는 백업 데이터베이스에서 가장 크며 매일 백업을 수행하는 경우 특히 더 그렇습니다.
손실된 변경사항을 얼마나 쉽게 다시 캡처할 수 있는가는 데이터베이스마다 다릅니다.
데이터베이스 간의 이러한 차이점은 백업 데이터베이스에 대해서는 몇 일이나 주 간격으로, 인증 데이터베이스의 경우 몇 주 간격으로 백업하는 것과 같이 다른 빈도로 데이터베이스를 백업하는 것을 유도합니다. 한편 테이프 소비가 별로 큰 문제가 되지 않는 경우에 특히 모든 데이터베이스를 동시에 백업하는 것이(그리고 자주) 논리적 견지에서 더 간단할 수 있습니다. 또한 오래 동안 데이터베이스의 백업 사본을 보관하는 것은 별로 필요한 일이 아닙니다. 따라서 자주 테이프를 재생할 수 있습니다.
-instance 인수에 대해 하나 이상의 데이터베이스 서버 프로세스 이름(백업 서버의 경우 buserver, 인증 서버의 경우 kaserver, 보호 서버의 경우 ptserver, 볼륨 위치 서버의 경우 vlserver)을 지정하십시오. 로컬 수퍼유저 root로 로그인했으므로 -localauth 플래그를 포함시키십시오. 그러나 관리 토큰을 반드시 가져야할 필요는 없습니다.
# bos shutdown <machine name> -instance <instances>+ -localauth [-wait]
0다음 명령 시퀀스는 /usr/afs/db 디렉토리의 완전한 내용을 백업합니다.
# cd /usr/afs/db # tar cvf tape_device .
개별 데이터베이스 파일을 백업하려면 위의 tar 명령에서 다음과 같이 마침표를 파일 이름을 바꾸십시오.
# bos start <machine name> -instance <server process name>+ -localauth
-instance 인수에 대해 하나 이상의 데이터베이스 서버 프로세스 이름(백업 서버의 경우 buserver, 인증 서버의 경우 kaserver, 보호 서버의 경우 ptserver, 볼륨 위치 서버의 경우 vlserver)을 지정하십시오. 로컬 수퍼유저 root로 로그인했으므로 -localauth 플래그를 포함시키십시오. 그러나 관리 토큰을 반드시 가져야할 필요는 없습니다.
# bos shutdown <machine name> -instance <instances>+ -localauth [-wait]
# 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
# cd /usr/afs/db # tar xvf tape_device database_file
여기서 database_file은 다음 중 하나입니다.
# bos start <machine name> -instance <server process name>+ -localauth
이 절에서는 파일 서버 시스템에 새 서버 프로세스 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진 파일을 설치 및 설치 해제하는 방법을 설명합니다.
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에서 명령 참조 페이지를 참조하십시오.
% bos listusers <machine name>
% bos install <machine name> <files to install>+
여기서
fs 프로세스를 제외한 각 AFS 서버 프로세스는 단일 2진 파일을 사용합니다. fs 프로세스는 fileserver, volserver 및 salvager의 세 가지 2진 파일을 사용합니다. 한 구성요소의 새 버전을 설치할 경우 만드시 위의 세 가지 파일을 바꾸어야 함을 의미하지는 않습니다.
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진 분산 시스템에 대해 다음에서 설명하는 bos uninstall 명령을 실행하십시오.
bos uninstall 명령을 사용할 때 BOS 서버는 2진 파일의 현재 버전을 버리고 확장자를 제거하여 파일의 .BAK 버전을 생성합니다. 이 서버는 현재의 .OLD 버전을 .BAK 버전으로 이름 변경합니다.
현재 .BAK 버전이 없는 경우 bos uninstall 명령은 실패하고 오류 메시지를 생성합니다. .OLD 버전이 아직도 있으면 bos uninstall 명령을 다시 실행하기 전에 mv 명령을 실행하여 .BAK로 이름 변경하십시오.
새 2진 파일을 설치할 때처럼 서버 프로세스는 복원된 버전을 즉시 사용하지 않습니다. 현재 2진 파일이 작동되지 않으므로 사용자가 파일을 복원했다고 가정할 수 있으므로 다음 지침에 따라 적절한 프로세스를 재시작해야 합니다.
% bos listusers <machine name>
% bos uninstall <machine name> <files to uninstall>+
여기서
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>+
/usr/afs/bin 디렉토리에서 2진 파일의 세 가지 버전인 현재 버전, .BAK 및 .OLD 버전에 대한 컴파일 날짜를 확인할 수 있습니다. 이것은 서버 프로세스를 재시작하여 새 2진 파일을 사용하기 전에 2진 분산 시스템으로부터 파일 서버 시스템으로 새 2진 파일이 복사되었는지 확인하는 데 유용한 방법입니다.
/usr/afs/bin 이외의 디렉토리에서 2진 파일에 대한 날짜를 확인하려면 -dir 인수를 추가하십시오. AFS Administration Reference를 참조하십시오.
% bos getdate <machine name> <files to check>+
여기서
새 2진 파일을 사용하는 프로세스가 오래 동안 문제 없이 실행된 경우 /usr/afs/bin 디렉토리에서 .BAK 및 .OLD 버전을 제거하여 파일 서버 시스템의 로컬 디스크에 있는 클러터를 줄이고 공간을 확보해도 안전합니다.
bos prune 명령 플래그를 사용하여 다음 유형의 파일을 제거할 수 있습니다.
% bos listusers <machine name>
% bos prune <machine name> [-bak] [-old] [-core] [-all]
여기서
서버 시스템과 셀 전체에서 일관된 성능을 유지하기 위해 모든 서버 프로세스가 동일한 AFS 분산으로부터 제공되는 것이 가장 좋습니다. 모든 AFS 2진 파일에는 그 버전이나 빌드 레벨을 지정하는 ASCII 문자열이 포함되어 있습니다. 이를 표시하려면 strings 및 grep 명령을 사용하십시오. 이들 명령은 대부분의 UNIX 분산 제품에 포함되어 있습니다.
% which binary_file /bin_dir_path/binary_file % cd bin_dir_path
% strings ./binary_file | grep Base
출력은 다음과 같은 형식으로 AFS 빌드 레벨을 보고합니다.
@(#)Base configuration afsversion build_level
예를 들어 다음 문자열은 2진 파일이 AFS 3.6 빌드 3.0의 파일임을 나타냅니다.
@(#)Base configuration afs3.6 3.0
모든 파일 서버 시스템은 로컬 디스크의 로컬 디스크 파일 /usr/afs/etc/CellServDB에 홈 셀의 데이터베이스 서버 시스템 목록을 유지합니다. 데이터베이스 서버 프로세스와 비 데이터베이스 서버 프로세스 모두 다음과 같이 이 파일을 확인합니다.
AFS 관리 데이터베이스 복제에서 자세히 설명하는 것처럼 데이터베이스 서버 프로세스는 Ubik 유틸리티를 사용하여 유지하는 데이터베이스의 정보를 동기화합니다. 각 데이터베이스에 대한 동기화 사이트에 있는 Ubik 조정자는 데이터베이스의 단일 읽기/쓰기 사본을 유지하고 필요에 따라 변경사항을 보조 사이트로 분배합니다. 또한 조정자로 남아 있기 위해 과반수의 보조 사이트와 접속을 유지해야 하며 CellServDB 파일을 참고하여 피어의 수와 이들이 실행되고 있는 시스템을 확인합니다.
조정자가 과반수 피어와 연결이 끊기면 과반수 표결에 의해 새 조정자를 선택합니다. 조정자 선택 중에 모든 Ubik 프로세스는 CellServDB 파일을 참고하여 득표를 전송할 위치와 과반수를 이루기 위해 필요한 표 수를 알게 됩니다.
CellServDB 파일의 정보가 누락되었거나 잘못되었을 경우 발생하는 결과는 다음과 같습니다.
좀더 경미한 결과는 비 데이터베이스 서버 프로세스가 시스템의 데이터베이스 서버 프로세스에 접속하려고 하는 것입니다. 이 경우 프로세스가 실행되지 않게 되므로 제한시간 지연이 발생합니다.
서버 시스템의 /usr/afs/etc/CellServDB 파일은 클라이언트 시스템의 /usr/vice/etc/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을 유지하는 것입니다. 자세한 설명을 보려면 세 번째 레벨을 참조하십시오.
% bos listhosts <machine name> [<cell 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 파일을 나타내십시오.
% bos listusers <machine name>
% bos addhost <machine name> <host name>+
여기서
중요: 모든 데이터베이스 서버 시스템에서 연속으로 다음 명령을 빠르게 반복하십시오.
% bos restart <machine name> buserver kaserver ptserver vlserver
셀 서버 CellServDB 파일의 중앙 사본을 일반적인 위치(/afs/cell_name/service/etc/CellServDB.local)에 유지 관리하려면 변경 내용을 반영하도록 파일을 편집하십시오.
% bos listusers <machine name>
% bos removehost <machine name> <host name>+
여기서
중요: 모든 데이터베이스 서버 시스템에서 연속으로 다음 명령을 빠르게 반복하십시오.
% bos restart <machine name> buserver kaserver ptserver vlserver
셀 서버 CellServDB 파일의 중앙 사본을 일반적인 위치(/afs/cell_name/service/etc/CellServDB.local)에 유지 관리하려면 변경 내용을 반영하도록 파일을 편집하십시오.
이 절에서는 권한 확인 및 클라이언트와의 상호 인증을 통해 AFS 서버 프로세스가 적절한 권한이 있는 사용자만 권한 있는 명령을 수행하도록 보장하는 방법을 설명합니다. 또한 시스템 기준이나 셀 기준으로 권한 확인 요구조건을 제어하는 방법과 명령을 실행할 때 상호 인증을 무시하는 방법에 대해서도 설명합니다.
많은 AFS 명령은 명령에 의해 호출된 AFS 서버 프로세스가 적절한 권한을 가진 사용자에 대해서만 해당 명령을 수행한다는 측면에서 권한이 부여됩니다. 서버 프로세스는 다음의 두 가지 검사를 수행하여 사용자가 적절한 권한을 가지는지 확인합니다.
여러 가지 개별 명령을 사용하면 상호 인증을 시도하지 않고 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 서버는 이 파일을 제거합니다.
% bos listusers <machine name>
% bos setauth <machine name> off
여기서
% bos setauth <machine name> on
몇몇 서버 프로세스를 사용하면 사용자(단지 시스템 관리자가 아님)가 명령을 실행할 때 상호 인증을 사용할 수 없게 됩니다. 이 서버 프로세스는 명령 실행자를 인증되지 않은 사용자 anonymous로 취급합니다.
상호 인증을 방지하기 위한 기능은 긴급 상황(예: 서버 암호화 키 비상사태 처리에서 설명하는 키 긴급 상황)에서 사용할 수 있도록 제공됩니다. 정상 상황에서 권한 확인은 설정되어 있고 이 기능을 사용할 수 없게 만들면 인증이 금지됩니다. 이 경우 서버 프로세스는 사용자 anonymous에 대해 권한 있는 명령을 수행하는 것을 거부합니다.
권한 확인 기능이 해제되어 있을 때는 인증을 방지하는 것이 유용할 수 있습니다. 인증을 시도하는 행동은 키 긴급 상황에서 나타나는 것처럼 서버가 특정 암호화 키를 이해할 수 없을 때 문제를 유발할 수 있습니다.
여러 명령에서 사용할 수 있는 -noauth 플래그를 제공하십시오. 명령이 해당 플래그를 수용하는지 확인하려면 help 명령을 실행하거나 AFS Administration Reference의 명령 참조 페이지를 참조하십시오. (참조 페이지에서도 각 명령의 플래그에 대해 허용되는 가장 짧은 축약형을 지정합니다.) 명령 집합의 apropos 및 help 명령은 플래그를 허용하지 않습니다.
kas interactive 명령의 -noauth 플래그를 포함시켜 대화식 세션 중에 실행된 모든 kas 명령에 대해 상호 인증을 무시할 수 있습니다. 인증된 ID를 사용하여 대화식 모드에 이미 들어간 경우 (kas) noauthentication 명령을 실행하여 anonymous ID인 것으로 가정하십시오.
이것은 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 &
% su root Password: root_password
# vos listpart <machine name> -localauth
여기서
# mkdir /vicepx[x]
# bos shutdown <machine name> -localauth [-wait]
# bos restart <machine name> fs -localauth
# bos status <machine name>
% bos listusers <machine name>
% vos listvol <machine name> [<partition name>]
% vos move <volume name or ID> \
<machine name on source> <partition name on source> \
<machine name on destination> <partition name on destination>
% su root Password: root_password
# cd / # umount /dev/<partition_block_device_name>
# rmdir /vicepxx
# bos shutdown <machine name> -localauth [-wait]
# bos restart <machine name> fs -localauth
# bos status <machine name>
다중홈 파일 서버 시스템에 대한 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 주소와 서버 항목을 변경하려면 다음 지침을 따르십시오.
% su root Password: root_password
% su root Password: root_password
% vos listaddrs
여기서 lista는 허용되는 listaddrs의 가장 짧은 축약형입니다.
출력은 자체의 각 행에 VLDB로부터의 모든 서버 항목을 표시합니다. 파일 서버 시스템이 다중홈 형식이면 그 등록된 모든 주소가 해당 행에 나타납니다. 첫 번째 항목은 vos examine 및 vos listvldb 명령의 출력에 볼륨의 사이트로 보고되는 것입니다.
VLDB 서버 항목은 IP 주소를 기록하고, 명령 인터프리터는 로컬 이름 서비스(도메인 이름 서비스나 로컬 호스트 테이블과 같은 프로세스)에서 이 IP 주소를 표시하기 전에 호스트 이름으로 변환하도록 합니다. IP 주소가 출력에 나타나면 변환할 수 없습니다.
항목이 존재한다고 해서 시스템이 파일 서버 시스템으로 계속 작동한다는 것을 의미하지는 않습니다. 이전 서버 항목을 제거하려면 다음 지침을 참조하십시오.
% bos listusers <machine name>
% vos changeaddr <original IP address> -remove
여기서
% bos listusers <machine name>
% bos shutdown <machine name>
% bos restart <machine name> -all
동시에 셀의 다른 모든 데이터베이스 서버 시스템에 대해 bos restart 명령을 실행하여 데이터베이스 서버 프로세스(인증, 백업, 보호 및 볼륨 위치 서버)만 재시작하십시오. 이들 명령을 빠르게 연속해서 실행하여 모든 데이터베이스 서버 프로세스가 쿼럼 선택에 참여하게 하십시오.
% bos restart <machine name> kaserver buserver ptserver vlserver
셀의 모든 데이터베이스 서버 시스템에서 IP 주소를 변경하는 경우 셀의 모든 파일 서버 시스템에 대해서 bos restart 명령을 실행하여 fs 프로세스를 재시작해야 합니다.
% bos restart <machine name> fs
콘솔에 적절한 명령을 입력하거나 원격 시스템에서 bos exec 명령을 실행하여 서버 시스템을 재부팅할 수 있습니다. 원격 재부팅은 사용자가 현재 위치를 떠날 필요가 없어서 좀더 편리할 수 있으나 콘솔에서 재부트 과정을 추적할 수 없습니다. 원격 재부팅은 서버 시스템의 운영 체제가 로컬 수퍼유저 루트로서 bos exec 명령을 실행하는 BOS 서버를 인식하기 때문에 가능합니다.
서버 시스템을 재부팅하는 것은 일부 셀에서는 루틴 유지보수의 일부이며 AFS 설명서에는 몇몇 지침이 하나의 단계 형태로 포함되어 있습니다. 이것은 AFS 관련 문제점에서 복구하기 위한 표준 방법으로 간주되지는 않으며 시스템이 응답하지 않으며 사용자가 다른 모든 옵션을 시도했을 때 사용할 수 있는 마지막 방법입니다.
재부팅을 수행하면 서비스 작동 중단 상태가 발생합니다. 시스템이 볼륨을 저장하는 경우 재부트가 완료되고 파일 서버가 볼륨에 다시 접속해야만 해당 볼륨을 액세스할 수 있습니다. 시스템이 데이터베이스 서버 시스템이면 각 데이터베이스 서버 프로세스에 대한 동기화 사이트의 재선택 중에 데이터베이스의 정보를 사용할 수 없습니다. VL 서버 작동 중단은 캐쉬 관리 프로그램이 AFS 데이터를 페치하기 위해 VLDB를 액세스할 수 있어야 하므로 가장 심각한 영향을 가져옵니다.
일반적으로 서버 시스템의 AFS 초기설정 파일에는 각 재부트 후에 BOS 서버를 재시작하기 위한 다음 명령이 들어 있습니다. 이 명령은 로컬 /usr/afs/local/BosConfig 파일에 나열된 다른 AFS 서버 프로세스를 시작합니다. 이들 지침은 초기설정 파일에 이 명령이 들어 있다고 가정합니다.
/usr/afs/bin/bosserver &
% su root Password: root_password
# bos shutdown <machine name> -localauth [-wait]
# shutdown
% bos listusers <machine name>
% bos shutdown <machine name> [-wait]
% bos exec <machine name> reboot_command
여기서