この章では、AFS サーバー・マシンの管理方法について説明します。この章では、以下の構成情報と管理用タスクについて説明します。
新規サーバー・マシンのインストールと構成の方法を確認するには、 AFS インストールの手引き を参照してください。
サーバー・プロセスそのものを管理する方法を確認するには、 サーバー・プロセスの監視および制御 を参照してください。
ボリュームの管理方法を確認するには、 ボリュームの管理 を参照してください。
本章では、指示されたコマンドを使用した以下のタスクの実行方法を説明します。
新規バイナリーのインストール | bos install |
チェックと再始動時のバイナリーの検査 | bos getrestart |
バイナリーの検査と再始動の時刻の設定 | bos setrestart |
バイナリー・ファイルのコンパイル日付の検査 | bos getdate |
新規バイナリーを使用するプロセスの再始動 | bos restart |
バイナリーの古いバージョンへの復帰 | 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 ディレクトリーのサブディレクトリーに常駐しなければなりません。これらのファイルには、バイナリー・ファイル、構成ファイル、管理用データベース・ファイル (データベース・サーバー・マシン上の)、ログ・ファイル、およびボリューム・ヘッダー・ファイルが含まれます。
Windows ユーザー向けの注: この文書で説明されているファイルには、 Windows オペレーティング・システムの稼働するマシン上にはないものがあります。また Windows では、パス名を区切るのに ( / ) の代わりに円記号 ( \ ) を使用します。
/usr/afs/bin ディレクトリーには、マシンのシステム (CPU またはオペレーティング・システム) タイプに適した AFS サーバー・プロセスとコマンドの組のバイナリーが保管されます。プロセスにサーバー部分とクライアント部分がある場合 (更新サーバーを使った場合)、あるいは、別のコンポーネントがある場合 (fs プロセスを使った場合) には、それぞれのコンポーネントは別々のファイルに常駐します。
予測可能なシステム・パフォーマンスを保証するには、すべてのファイル・サーバー・マシンは、所定のプロセスの同じ AFS 作成バージョンを実行しなければなりません。整合性を簡単に保守するには、更新サーバー・プロセスを使用して、それぞれのシステム・タイプのバイナリー配布マシン から、バイナリーを配布します。詳しくは、バイナリー配布マシン を参照してください。
たとえ、そのプロセスをマシン上で実際に実行しなくても、すべてのプロセスのバイナリーを /usr/afs/bin ディレクトリーに保持するとよいでしょう。バイナリーは、マシンの構成のプロセス (たとえば、データベース・サーバー機能を既存のファイル・サーバー・マシンに追加すること) を単純化します。同様に、たとえサーバー・マシンでの作業中に頻繁にコマンドを発行しなくても、ディレクトリーにコマンドの組のバイナリーを保持するのもよいことです。コマンドの組のバイナリーを使用すると、ユーザーは、サーバーとマシンの停止から回復中にコマンドを発行することができます。
以下は、AFS サーバー・プロセスまたはコマンドの組に直接関連する /usr/afs/bin ディレクトリーにあるバイナリー・ファイルのリストです。ほかのバイナリー (たとえば、klog コマンド用) は、特定のファイル・サーバー・マシンのディスクまたは AFS 配布にあるこのディレクトリーに表示されます。
あらゆるファイル・サーバー・マシンのローカル・ディスクにあるディレクトリー /usr/afs/etc には、 ASCII とマシンから独立したバイナリー形式の構成ファイルが含まれます。セル全体の予測可能な AFS パフォーマンスのためには、すべてのサーバー・マシンのバージョンは、それぞれの構成ファイルと同じでなければなりません。
緊急事態に対処するための指示によって送信される場合を除いて、 /usr/afs/etc ディレクトリーにあるどのようなファイルも直接編集してはいけません。通常の環境では、適切な bos コマンドを使用してファイルを変更します。以下のリストには、指示を指すポインターが組み込まれます。
このディレクトリーのファイルには、以下が組み込まれます。
サーバー CellServDB ファイルは、クライアント・マシンの /usr/vice/etc ディレクトリーに保管される CellServDB ファイルとは異なります。クライアント・バージョンは、ユーザーがクライアント・マシンからアクセスできるように選択した、あらゆる AFS セルのデータベース・サーバー・マシンのリストを作成します。サーバー CellServDB ファイルは、ローカル・セルだけのデータベース・サーバーのリストを作成します。それは、サーバー・プロセスがほかのセルのプロセスと更新することはないからです。
このファイルの保守については、サーバー CellServDB ファイルの保守 を参照してください。
このファイルの保守については、サーバー暗号化鍵の管理 を参照してください。
このファイルを変更することは、セルの名前を変更する 1 つのステップにしかすぎません。説明は、セル名の選択 を参照してください。
ディレクトリー /usr/afs/localには、セルにあるそれぞれのファイル・サーバー・マシンごとに異なる構成ファイルが含まれます。したがって、それらの構成ファイルは、/usr/afs/bin および /usr/afs/etc ディレクトリーにあるファイルのように、中央ソースから自動的に更新されることはありません。最も重要なファイルは、BosConfig ファイルです。このファイルはそのマシンで実行するサーバー・プロセスを定義します。
/usr/afs/etc にある共通構成ファイルと同じように、これらのファイルを直接編集してはいけません。適切な場合は、 bos コマンドの組のコマンドを使用します。更新する必要がないファイルもあります。
このディレクトリーに含まれるファイルは、以下のとおりです。
ファイル・サーバー・マシンのインストール中に、サーバー・プロセスを作成するときに、それらのプロセスの項目は、このファイル内で自動的に定義されます。AFS インストールの手引き では、使用する bos コマンドについて、簡単に説明します。ファイルの詳細な説明と、 bos の組のコマンドでファイルを編集してプロセスの状況を制御するための指示については、 サーバー・プロセスの監視および制御 を参照してください。
このファイルは、 -noauth フラグをもつ初期 bosserver プロセスを開始するか、あるいは、bos setauth コマンドを発行して認証要件をオフにするときに、自動的に作成されます。bos setauth コマンドを使用して認証をオンにすると、 BOS サーバーはこのファイルを除去します。詳細については、認証と許可の要件の管理 を参照してください。
このファイルをユーザー自身が作成したり、または除去してはいけません。 BOS サーバーが自動的に行います。必要な場合は、bos salvage コマンドを使って、ボリュームまたはパーティションを回収することができます。ボリュームのサルベージ を参照してください。
ディレクトリー /usr/afs/db には、認証データベース、バックアップ・データベース、保護データベース、およびボリューム・ロケーション・データベース (VLDB) という、セル内の 4 つの複写されたデータベースに関連した以下の 2 つのタイプのファイルが含まれています。
それぞれのデータベース・プロセス (認証、バックアップ、保護、または VL サーバー) が、そのプロセス専用のデータベース・ファイルとログ・ファイルを保持しています。データベース・ファイルはバイナリー形式です。したがって、データベース・ファイルにアクセスする場合またはデータベース・ファイルを更新する場合は、いつでも、 kas の組 (認証データベースの場合)、 backup の組 (バックアップ・データベースの場合)、 pts の組 (保護データベースの場合)、または vos の組 (VLDB の場合) を使用しなければなりません。
セルで 複数のデータベース・サーバー・マシンを実行する場合には、それぞれのデータベース・サーバー・プロセスは、そのデータベースの独自のコピーを、マシンのハード・ディスクに保持します。ただし、所定のデータベースのすべてのコピーが同じであることが重要です。それらのコピーを同期するためには、 AFS 管理データベースの複写 で説明したように、データベース・サーバー・プロセスには、 AFS の分散データベース・テクノロジー、Ubik が必要です。
ここにリストされているファイルは、データベース・サーバー・マシンでだけこのディレクトリーに表示されます。データベース・サーバー・マシン以外のマシンのディレクトリーは、空です。
/usr/afs/logs ディレクトリーには、さまざまなサーバー・プロセスのログ・ファイルが含まれます。このファイルで通常のオペレーション中に発生する興味深いイベントについて詳しく説明します。たとえば、ボリューム・サーバーでは、ボリュームの移動を VolserLog ファイルに記録することができます。イベントは完了時に記録されます。そのため、サーバー・プロセスでは、これらのファイルを使用しないで、失敗したオペレーションを再構成します。これは /usr/afs/db ディレクトリーにあるログ・ファイルとは異なります。
ログ・ファイル内の情報は、プロセスの障害およびその他の問題を評価するのに非常に役立ちます。たとえば、ボリュームにアクセスしようとしてタイムアウト・メッセージを受け取った場合は、 FileLog ファイルを調べると、ファイル・サーバーがボリュームを付加できなかったことを示す説明が見つかる可能性があります。ログ・ファイルをリモートで調べるには、サーバー・プロセス・ログ・ファイル表示する で説明しているように、bos getlog コマンドを使用します。
このディレクトリーには、 BOS サーバーでプロセスをモニターする場合に生成される、コア・イメージ・ファイルも含まれます。BOS サーバーは、標準 core 名に拡張子を追加して、コア・ファイルを生成したプロセスを示そうとします (たとえば、保護サーバーによって生成されたコア・ファイルは、 core.ptserver という名前になります)。2 つのプロセスがほぼ同時に失敗すると、 BOS サーバーは正しい拡張子を割り当てることができない場合があります。
このディレクトリーには、以下のファイルが組み込まれます。
注: | ログ・ファイルが大きくなりすぎて管理不能になることを防ぐには、定期的にサーバー・プロセス (特にデータベース・サーバー・プロセス) を再始動します。プロセスの再始動を避けるには、UNIX の rm コマンドを使って、プロセスが実行されたらログ・ファイルを削除します。ログ・ファイルは自動的に再作成されます。 |
AFS ボリュームを収容するパーティションは、マシンのルート ( / ) ディレクトリー (たとえば /usr ディレクトリーの下ではなく) のサブディレクトリーに取り付けなければなりません。ファイル・サーバー・マシンのファイル・システム登録ファイル (/etc/fstab または同等のファイル) は、ディレクトリー名とパーティションの装置名を正しくマップしなければなりません。ディレクトリーには、 /vicepindex の形式 (それぞれの index は 1 または 2 文字の小文字) の名前が付きます。規則では、マシン上の最初の AFS パーティションは /vicepa に、 2 番目のパーティションは /vicepb に、というように取り付けます。パーティションの数が 26 より多い場合は、 /vicepaa、/vicepab というように続けます。AFS Release Notes では、サポートされているサーバー・マシンあたりのパーティション数を指定しています。
非 AFS ファイルを AFS パーティションに保管しないでください。ファイル・サーバーおよびボリューム・サーバーは、パーティション上のすべてのスペースが使用可能であると予期します。
/vicep ディレクトリーには、以下の 2 つのタイプのファイルが含まれます。
注: | ほとんどのシステム・タイプにおいては、オペレーティング・システムに提供されている標準の fsck プログラムは、 AFS ファイル・サーバー・マシンでは決して実行してください。標準の fsck プログラムは、 AFS ボリューム・データの形式を認識できないため、サーバー・パーティションからすべての AFS ボリューム・データを削除します。 |
複数のサーバー・マシンがあるセルでは、すべてのサーバー・マシンがまったく同じ機能を実行しなければならないわけではありません。実行しているサーバー・プロセスを判別して、マシンに想定できる可能な役割 が 4 つあります。すべての関連したプロセスを実行することによって、マシンには複数の役割を想定することができます。以下のリストでは 4 つの役割を要約しますが、それらについては、以降の機能グループでより完全に説明します。
セルにあるサーバー・マシンが 1 つだけの場合は、シンプル・ファイル・サーバーとデータベース・サーバーの役割を想定しています。 AFS インストールの手引き にある説明によっても、そのシステム・タイプに応じたシステム制御マシンとバイナリー配布マシンとして、サーバー・マシンを構成することができますが、サーバー・マシンがこれらの機能を実際に実行するのは、ユーザーが別のサーバー・マシンをインストールしてからです。
たとえ、すべてのプロセスが実行されていなくても、すべての AFS サーバー・プロセスのバイナリーを /usr/afs/bin ディレクトリーに保持するのは最もよいことです。次に、その役割を定義するプロセスを開始するかまたは停止するだけで、マシンに想定される役割を変更することができます。
シンプル・ファイル・サーバー・マシン が実行するのは、 AFS ファイルをクライアント・マシンに保管または送達し、プロセスの状態をモニターし、セルのバイナリー配布マシンとシステム制御マシンから、バイナリー・ファイルと構成ファイルをピックアップするサーバー・プロセスだけです。
一般的に、3 つより多いサーバー・マシンをもつセルだけが、シンプル・ファイル・サーバー・マシンを実行する必要があります。3 つ以下のマシンをもつセルでは、そのすべてのマシンはほとんどの場合データベース・サーバー・マシンです (管理用データベースの複写から利益を得るため)。 データベース・サーバー・マシン を参照してください。
以下のプロセスは、シンプル・ファイル・サーバー・マシンで実行されます。
データベース・サーバー・マシン は、 AFS の複写された管理用データベースを保守する 4 つのプロセスを実行します。この 4 つのプロセスとは、認証サーバー、バックアップ・サーバー、保護サーバー、および ボリューム・ロケーション (VL) サーバーで、認証データベース、バックアップ・データベース、保護データベース、およびボリューム・ロケーション・データベース (VLDB) をそれぞれ保守します。これらのサーバー・プロセスとそれらのデータベースの機能を見直すには、 AFS サーバー・プロセスとキャッシュ・マネージャー を参照してください。
セルに複数のサーバー・マシンがある場合には、複数のデータベース・サーバー・マシンを実行するのはよいことですが、3 つより多くが必要になることはめったにありません。データベースをこの方法で複写すると、情報の可用性と信頼性が増大するという、ボリュームを複写するのと同じ利益が生じます。1 つのデータベース・サーバー・マシンまたはプロセスが終わっても、データベース内の情報は、まだほかのデータベース・サーバー・マシンまたはプロセスから使用可能です。データベース情報に対する要求のロードが複数のマシンに分散し、いずれのマシンも過負荷になることがないようにします。
ただし、複写されたボリュームと異なり、複写されたデータベースは頻繁に変更されます。一貫したシステム・パフォーマンスを得るためには、データベースのすべてのコピーがいつでも同一である必要があります。したがって、コピーの一部にだけ変更を記録することはできません。データベースのコピーを同期化するために、データベース・サーバー・プロセスでは、 AFS の分散データベース・テクノロジーである Ubik を使用します。 AFS 管理データベースの複写 を参照してください。
セルにあるあらゆるサーバー・マシンの AFS サーバー・プロセスが、どのマシンがデータベース・サーバー・マシンであるかを知っていることは重要です。特に、データベース・サーバー・プロセスでは、データベースのコピーを調整するために、対等機能との一定の接点を保守しなければなりません。ほかのサーバー・プロセスでは、データベースからの情報を必要とすることがよくあります。あらゆるサーバー・マシンでは、そのセルのデータベース・サーバー・マシンのリストを、ローカルの /usr/afs/etc/CellServDB ファイルに保持します。米国版の AFS を使用するセルでは、システム制御マシンを使用して、このファイルを配布することができます (システム制御マシン を参照)。
以下のプロセスは、定義・サーバー・マシンを定義します。
データベース・サーバー・マシンは、シンプル・ファイル・サーバー・マシン にリストされるような、シンプル・ファイル・サーバーを定義するプロセスも実行することができます。1 つのデータベース・サーバー・マシンは、セルのシステム制御マシンとしての機能を果たし、データベース・サーバー・マシンのどれかは、そのシステム・タイプのバイナリー配布マシンとして機能を果たすことができます。 システム制御マシン および バイナリー配布マシン を参照してください。
バイナリー配布マシン では、 AFS プロセスとコマンドの組のバイナリー・ファイルを、そのシステム・タイプのほかのすべてのサーバー・マシンに保管したり配布します。それぞれのファイル・サーバー・マシンでは、 AFS サーバー・プロセス・バイナリーの独自のコピーをローカル・ディスクに、規則では、/usr/afs/bin ディレクトリーに保持します。ただし、一貫したシステム・パフォーマンスのためには、すべてのサーバー・マシンで同じバージョン (作成レベル) のプロセスを実行しなければなりません。バイナリーの作成レベルを調べるための指示については、 バイナリー・ファイルの作成レベルの表示 を参照してください。バイナリーの整合性を保持する最も簡単な方法は、それぞれのシステム・タイプのバイナリー配布マシンを使って、バイナリーをそのシステム・タイプのマシンに配布することです。
バイナリー配布マシンを定義するプロセスは、更新サーバーのサーバー部分 (upserver プロセス) です。更新サーバーのクライアント部分 (upclientbin プロセス) は、そのシステム・タイプのほかのサーバー・マシンで実行され、バイナリー配布マシンを参照します。
通常、バイナリー配布マシンは、 シンプル・ファイル・サーバー・マシン にリストされるような簡単なファイル・サーバー・マシンを定義するプロセスも実行します。 1 つのバイナリー配布マシンはセルのシステム制御マシンとしての機能を果たし、任意のバイナリー配布マシンはデータベース・サーバー・マシンとしての機能を果たします。システム制御マシンおよび データベース・サーバー・マシンを参照してください。
米国版の AFS を実行するセルでは、 システム制御マシン では、セル内のすべてのサーバー・マシンが共有するシステム構成ファイルを保管し配布します。それぞれのファイル・サーバー・マシンでは、構成ファイルの独自のコピーをローカル・ディスクに、規則では /usr/afs/etc ディレクトリーに保持します。ただし、一貫したシステム・パフォーマンスのためには、すべてのサーバー・マシンで同じファイルを使用しなければなりません。ファイルの整合性を保持する最も簡単な方法は、システム制御マシンを使ってファイルを配布することです。本書の説明で指図されるときには、システム制御マシンに保管されるコピーだけを変更します。米国版の AFS は、米国政府の規制により決められた、米国とカナダにあるセル、およびほかの各国の選ばれた機関に使用可能です。
AFS の国際版を実行するセルでは、システム構成ファイルを配布するために、システム制御マシンを使用しません。このファイルの一部には、暗号化しないでネットワークを渡すには重要過ぎる情報が含まれ、米国政府の規制により、必要な暗号化ルーチンを更新サーバーが使用する形式でエクスポートすることは禁じられています。代わりに、それぞれのファイル・サーバー・マシンで個別に、構成ファイルを更新しなければなりません。ファイルを更新するために使用する bos コマンドは、暗号化ルーチンのエクスポート可能な形式を使用して情報を暗号化します。
/usr/afs/etc ディレクトリーに保管される構成ファイルのリストについては、 /usr/afs/etc ディレクトリーにある共通構成ファイル を参照してください。
AFS インストールの手引き では、システム制御マシンとして、セルの最初のサーバー・マシンを構成します。希望する場合には、後にユーザーがインストールする別のマシンに、その役割を再割り当てすることができますが、ほかのすべてのサーバー・マシンで実行している更新サーバーのクライアント部分を (upclientetc プロセス) を変更して、新規システム制御マシンに当てはめなければなりません。
以下のプロセスは、システム制御マシンを定義します。
システム制御マシンでは、シンプル・ファイル・サーバー・マシン にリストされるような、シンプル・ファイル・サーバー・マシンを定義するプロセスも実行できます。また、このマシンはデータベース・サーバー・マシンとしての機能も果たすことができ、規則では、そのシステム・タイプのバイナリー配布マシンとしての機能を果たします。単一の upserver プロセスでは、構成ファイルとバイナリー・ファイルの両方を配布することができます。 データベース・サーバー・マシン および バイナリー配布マシン を参照してください。
% 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
表示される出力は、ユーザーが交信したマシン、すなわち、シンプル・ファイル・サーバー・マシン、システム制御マシン、またはバイナリー配布マシンによって異なります。bos status コマンドの出力の解釈 を参照してください。
% bos status <machine name> upserver upclientbin upclientetc -long
表示される出力は、ユーザーが交信したマシン、すなわち、シンプル・ファイル・サーバー・マシン、システム制御マシン、またはバイナリー配布マシンによって異なります。bos status コマンドの出力の解釈 を参照してください。
bos status コマンドの出力の解釈は、単純なファイル・サーバー・マシンでは最も簡単です。upserver プロセスがないため、出力には以下のメッセージが含まれます。
bos: failed to get instance info for 'upserver' (no such entity)
単純なファイル・サーバー・マシンは upclientbin プロセスを実行するので、出力には次のようなメッセージが含まれます。これは、fs7.abc.com がこのシステム・タイプのバイナリー配布マシンであることを示しています。
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 インストールの手引き で推奨されているデフォルトの構成を使用している場合、システム制御マシンはそのシステム・タイプのバイナリー配布マシンでもあり、単一の upserver プロセスが両方の種類の更新を配布します。その場合には、出力には次のメッセージが含まれます。
bos: failed to get instance info for 'upclientbin' (no such entity) bos: failed to get instance info for 'upclientetc' (no such entity)
システム制御マシンがバイナリー配布マシンでない場合には、出力には upclientetc プロセスに関するエラー・メッセージが含まれ、 upclientbin プロセスの完全なリストは含まれません (この場合、マシン fs5.abc.com がバイナリー配布マシンとして参照されます)。
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)
バイナリー配布マシンに 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 と呼ばれるユーティリティーのライブラリーを使用します。各データベース・サーバーのプロセスは、関連した lightweight Ubik プロセスとして実行され、クライアント側のプログラムは、Ubik のクライアント側のサブルーチンを呼び出して、データベースの読み取りや変更要求を実行以来します。
Ubik は、管理者の操作を最小にとどめて機能するよう設計されていますが、 Ubik の適切なオペレーションのためのセル構成 に示すようにいくつかの構成要件があります。以下の Ubik のオペレーションの概要は、この要件を理解するための手助けとなるでしょう。詳細については、Ubik の自動オペレーション を参照してください。
Ubik は、AFS 管理データベースで行われた変更をすべてのコピーにできるだけすぐに配布することを目的としています。クライアントからの変更要求を受け入れる唯一のデータベース・コピーが 同期サイト であり、ここで実行される lightweight Ubik プロセスのことを Ubik コーディネーター といいます。最低限の可用性を保持するため、各データベースごとに別個の Ubik コーディネーターが存在し、 4 つのデータベースごとに別のマシンに同期サイトを置くことができます。データベースの同期サイトもまた、プロセス、マシン、またはネットワークの障害に応じて、マシン間を移動することができます。
データベースのその他のコピー、およびこれを保守するための Ubik プロセスは、 2 次 と名付けられます。2 次サイトは、クライアント側プログラムから直接変更を受け入れることはなく、同期サイトからのみ受け入れます。
Ubik コーディネーターは、データベースのコピーに変更を記録すると、即時に変更を 2 次サイトに送ります。短い配布期間中は、たとえ読み取り用であっても、クライアントはデータベースのコピーにアクセスできません。コーディネーターが 2 次サイトの多数に到達することができない場合には、そのコピーを打ち切り、変更の試行が失敗したことをクライアントに通知します。
配布上の障害を避けるため、Ubik プロセスはタイム・スタンプのあるメッセージを交換して、常時交信をするようにします。 2 次サイトの多数がコーディネーターのメッセージに応答する限りは、コーディネーターと同期したサイトの 定数 が存在するものとされます。プロセス、マシン、またはネットワークの障害により定数が割れる場合には、 Ubik プロセスは新しくコーディネーターを選び出し、できる限り多くのサイト間で定数を確立するようにします。 柔軟なコーディネーターによる可用性の向上 を参照してください。
このセクションでは、適切な Ubik のオペレーションのためのセルの構成方法を説明します。
Ubik のクライアント部分とサーバー部分のどちらも、 CellServDB ファイルにリストされるすべてのデータベース・サーバー・マシンが、すべてのデータベース・サーバー・プロセスを実行していることを求めます。あるマシンで実行されている特定のデータベース・サーバー・プロセスを示すメカニズムはありません。
Ubik は /usr/afs/etc/CellServDB ファイルを参照して、定数の確立、保守に使用するサイトを判別します。情報が正しくないと、データベースの同期がとれない、またはマシンの複数のサブグループからそれぞれコーディネーターが選ばれる結果となります。これは、各マシンの Ubik プロセスが、定数に加わるマシンの判別に一致した結果を出さないためです。
米国版の AFS を稼働しており、更新サーバーを使用する場合は、システム制御マシン (コピーをその他すべてのサーバー・マシンに配布する) 上に /usr/afs/etc/CellServDB ファイルを置くのが最も簡単な方法です。 AFS インストールの手引き では、更新サーバーの構成方法を説明しています。インターナショナル版の AFS を稼働する場合、各マシン上でファイルを個別に更新しなくてはなりません。
ファイルを更新するのは、データベース・サーバー・マシンの構成時または使用中止する場合です。手動でファイルを編集するのではなく、適切な bos コマンドを使用します。説明については、 サーバー CellServDB ファイルの保守 を参照してください データ ベース・サーバー・マシンのインストールまたは使用の中止に関する AFS インストールの手引き の説明のように、プロセスの停止と開始に関する サーバー・プロセスの監視および制御 の説明は、適切な環境で CellServDB ファイルを忘れずに更新するようユーザーに注意しています。
(データベースの保守を行わないクライアント・プロセスをサーバー・プロセスもまた、適切なオペレーションを行うため CellServDB ファイルを使用しますが、この場合、Ubik のオペレーションには影響はありません。 サーバー CellServDB ファイルの保守 および データベース・サーバー・マシンの情報を保持する を参照してください。)
AFS インストールの手引き に指定されている通常の構成では、 runntp プロセスを実行して、すべての AFS サーバー・マシン上のローカル Network Time Protocol Daemon (NTPD) を監視します。システム上の NTPD は、セル外の信用できるソースとマシンのクロックを同期するよう制御し、他のサーバー・マシンの NTPD に時刻を同報通信します。必要であれば、異なる時刻同期プロトコルを実行することができます。
Ubik はデータベース・サイトのタイム・スタンプがあるメッセージを交換して常時交信をするため、クロックを同期させておくことは重要です。ネットワーク環境においては、メッセージが即時に宛先に到達すると考えるのは安全な前提ではないので、メッセージのタイム・スタンプは重要です。 Ubik は、着信メッセージと現在の時刻を比較します。差が大きすぎる場合は、障害により Ubik サイト間ので信頼性のある通信が行われず、これによりデータベースが同期されなかった可能性があります。Ubik はメッセージを無効とみなし、この場合異なるコーディネーターを選ぶよう指示が出されることがあります。
実際に通信が中断したことによりタイム・スタンプを持つメッセージの有効期限が切れた場合、新規のコーディネーターを選ぶのは適当といえますが、送信側と受信側の時刻が異なるという理由だけでメッセージの有効期限が切れたと思われる場合には妥当ではありません。クロックの同期がとれていないことにより Ubik オペレーションが不安定となる場合の例については、 Ubik におけるタイム・スタンプ・メッセージの使用 を参照してください。
以下の Ubik 機能は、保守要件を最低限にするために役に立ちます。
それぞれのデータベース・サーバー・プロセスは、 Ubik ライブラリーのサーバー部分を呼び出すため lightweight プロセスを実行します。この lightweight プロセスを Ubik として参照するのが一般的です。これは lightweight プロセスであるため、 Ubik プロセスは、UNIX ps コマンドなどで生成されるプロセス・リストには現れません。データベースを読み取りおよび変更する必要のあるクライアント側プログラムは、別個の lightweight プロセスを実行するのではなく、Ubik ライブラリーのクライアント部分にあるサブルーチンを直接呼び出します。このようなプログラムには、klog コマンドや、pts 組のコマンドがあります。
コーディネーターがデータベースに変更を記録する際、データベースのバージョン番号が増分で更新されます。バージョン番号によって、サイトが最新のバージョンを入手しているかいないかを決定するのが簡単になります。バージョン番号を使用することにより、新規コーディネーターの選出後、または通信が停止後に復元された場合の通常復帰機能が高速化されます。これは、最新のデータベースを所有するサイトおよび更新の必要があるサイトの判別が容易になるためです。
データベースの複写によるデータ使用可能性の向上は、すべてのデータベース・コピーが同じでないと意味がありません。クライアントがアクセスするデータベースのコピーに応じて異なる情報を受け取ると、パフォーマンスに矛盾が生じます。先に説明したとおり、Ubik サイトはタイム・スタンプを持つメッセージを交換してピアの状況をトラックします。詳細については、 Ubik におけるタイム・スタンプ・メッセージの使用 を参照してください。
たとえば、3 つのデータベース・サーバー・マシンを持つセルにおいて、ネットワーク・パーティションがコーディネーターから 2 つの 2 次サイトを分離したとします。コーディネーターは、 CellServDB ファイルにリストされている多数のサイトとは交信できないため、終了します。パーティションの別サイドの 2 つのサイトは、そのサイト間で新しいコーディネーターを選出し、クライアントからのデータベースの変更を受け入れることができます。このようにしてコーディネーターを移動できないとすると、ネットワーク・パーティションが回復するまでデータベースは読み取り専用となってしまいます。 Ubik による選出方法の詳細については、 柔軟なコーディネーターによる可用性の向上 を参照してください。
Ubik は、同期サイトと 2 次サイト間で常時交信を行うことにより、データベースのコピーを同期します。 Ubik コーディネーターは、各 2 次サイトに対しタイム・スタンプ付きの 保証 メッセージを頻繁に送信します。 2 次サイトはメッセージを受信すると、コーディネーターと通信状態にあるものとみなします。 2 次サイトは、時間 T (通常はコーディネーターのメッセージ送信後から 60 秒) の間は、データベースのコピーが有効であると判断します。これに対して、 2 次サイトは特定時間 X (通常はそれ以降の 120 秒) の間はコーディネーターを有効と認める、 賛否表示 メッセージを戻します。
コーディネーターは、T 秒ごとより頻繁に保証メッセージを送信します。したがって、有効期限はオーバーラップします。ネットワーク・パーティションやその他の障害によって実際に通信が停止することがなければ、満了することはありません。保証期限が切れた場合、 2 次サイトのデータベース・コピーは、現行ではなくなります。この場合でも、データベース・サーバーはクライアント要求へのサービスを継続します。セル全体が機能するためには、2 次サイトの配布する情報の期限が切れた場合でも、アクセス可能とされている方がよいものと考えられます。いずれにせよ AFS 管理データベースの大部分はそう頻繁に変更されることはなく、データベースがアクセス不能になることにより、コピーにアクセスしたクライアントに対してタイムアウトが生じることになります。
先の説明のとおり、Ubik がタイム・スタンプ付きのメッセージを使用する上では、データベース・サーバー・マシンのクロックを同期させることが重要です。どちらのクロックが先に進んでいるかにより、ずれたクロックが通常の Ubik 機能の妨げとなる場合が 2 つ考えられます。
たとえば、Ubik コーディネーターのクロックが 2 次サイトより進んでいるとします (コーディネーターのクロックが 9:35:30、2 次サイトのクロックが 9:31:30)。 2 次サイトが、コーディネーターが 9:33:30 まで有効であると認める賛否表示メッセージを送るとします。これは、2 次サイトのクロックでは 2 分先の時刻ですが、コーディネーターからは既に過去です。コーディネーターは、コーディネーターのままでいることはもう支持されていないと推断し、新規のコーディネーターを選出するよう強制します。選出には 3 分ほどかかり、その間データベースのコピーは変更を受け入れません。
これとは逆に、2 次サイトのクロック (14:50:00) が、コーディネーター (14:46:30) より進んでいる場合があります。コーディネーターが 14:47:30 までの保証メッセージを送信した場合、これは 2 次サイトでは期限切れとなります。 2 次サイトは、コーディネーターとの交信が不可能であるとみなし、コーディネーターへの賛否表示を停止し、自身をコーディネーターに選出しようとします。これは、実際にコーディネーターに障害のあった場合には適切な処置ですが、実際に障害がない場合には適切とはいえません。
新規コーディネーターとして選出されようとする単一の 2 次サイトの試みは、ほかのサイトのパフォーマンスには影響しません。2 次サイトのクロックがコーディネーターと同じである限り、他の 2 次サイトからの賛否表示要求を無視し、現行のコーディネーターへの賛否表示を継続します。ただしコーディネーターよりクロックが進んだクロックの 2 次サイトが多くなれば、たとえ現行のコーディネーターが実際に申し分のない作業を行っていても、新規コーディネーターの選出を強制することができます。
Ubik は、コーディネーターの選出が必要となる際に、タイム・スタンプ付きのメッセージを使用します。これはデータベース・コピーの同期をとる場合と同様です。コーディネーターがサイトの過半数から投票メッセージを受け取ると (コーディネーターは暗黙的に自らに投票します)、データベースの変更の配布が正常に行われているとされ、コーディネーターの役割を継続することができます。過半数とは、奇数のサイトがある場合にすべてのデータベース・サイトの 50 % を上回る数のことです。偶数のサイトがある場合は、最下位の IP アドレスを持つサイトに特別な決定権があります。コーディネーターは、十分な票数を獲得できないとその役割を終了し、 Ubik サイトは新規コーディネーターを選出します。このようなことは、コーディネーターが実際に過半数の賛否表示の受信に失敗したり停止する場合を除いて、自然に発生することはありません。2 次サイトには、既存のコーディネーターに対する投票を続行するための組み込まれたバイアスがあり、不適当な選出を回避します。
新規コーディネーターは、多数決によって選出されます。Ubik サブプロセスには、最下位の IP アドレスをもつサイトに投票するためのバイアスがあり、すべてのサイトが賛否表示を自身で受けようと競合した場合よりも速く、必要な過半数を集めるのに役立ちます。選出中 (通常、3 分も続きません)、クライアントはデータベースからの情報を読み取ることはできますが、変更を加えることはできません。
Ubik の選出手続きでは、各データベース・サーバー・プロセスのコーディネーターを異なるマシンに置くことができます。たとえば、4 つすべてのプロセスの Ubik コーディネーターがマシン A で開始し、マシン A の保護サーバーに何らかの理由で障害が発生した場合は、別のサイト (たとえばマシン B) を新規の保護データベース Ubik コーディネーターとして選出しなければなりません。マシン A の保護サーバーが再び動作を開始した後も、マシン B は保護サーバーのコーディネーターのままです。保護サーバーの障害は、認証、バックアップ、および VL サーバーに影響を及ぼしません。したがって、それらのコーディネーターはマシン A に残存しています。
AFS 管理用データベースには、セル内の AFS のオペレーションにとって重要な情報が保管されます。データベース・サーバー・マシンのハードウェア障害またはその他の問題によってデータベースが破壊された場合は、すべての情報を最初から再作成することは通常、困難で時間がかかります。データを消失から保護するには、管理用データベースを磁気テープなどの永久媒体に定期的にバックアップします。推奨される方法は、UNIX の tar コマンドのような標準のローカル・ディスク・バックアップ・ユーティリティーを使う方法です。
データベースをバックアップする頻度を決めるときは、バックアップ・コピーからデータベースを復元することが必要になった場合に、手作業で再作成してもかまわないデータの量を検討します。ほとんどのセルでは、データベースによって、変更の頻度と程度はかなり異なります。認証データベースに対する変更は、おそらく最も頻度が少なく、ほとんどがユーザー・パスワードの変更です。保護データベースおよび VLDB の変更がおそらく最も頻度が高くなります。その変更とは、ユーザーによるグループの追加または削除やグループ・メンバーシップの変更、および管理者によるボリュームの作成または移動です。変更の数と頻度は、おそらく保護データベースで最大になります。バックアップを毎日行う場合は特にそうです。
また、消失した変更の回復がどれだけ容易かも、データベースによって異なります。
データベース間のこれらの相違は、異なる頻度 (バックアップ・データベースについては数日おきから毎週、認証データベースについては 2 〜 3 週間ごとの範囲) でデータベースをバックアップすることを提示しています。一方、配備上の観点からは、特に磁気テープの消費がそれほど問題にならない場合は、すべてのデータベースを同時に (同じ頻度で) バックアップすれば、おそらくもっと単純です。また、一般にデータベースのコピーを長期間残しておく必要はないので、磁気テープは短期間で再利用できます。
-instance 引き数には、 1 つまたは複数のデータベース・サーバー・プロセスの名前を指定します (バックアップ・サーバー buserver、認証サーバー kaserver、保護サーバー ptserver、またはボリューム・ロケーション・サーバー vlserver)。ローカル・スーパーユーザー root としてログインするので -localauth フラグを付けますが、管理トークンは必ずしも必要ではありません。
# bos shutdown <machine name> -instance <instances>+ -localauth [-wait]
以下のコマンド・シーケンスは、/usr/afs/db ディレクトリーの完全なコンテンツをバックアップします。
# cd /usr/afs/db # tar cvf tape_device .
個々のデータベース・ファイルをバックアップするには、上に示した tar コマンドで、期間をファイルの名前に置換します。
# bos start <machine name> -instance <server process name>+ -localauth
-instance 引き数には、 1 つまたは複数のデータベース・サーバー・プロセスの名前を指定します (バックアップ・サーバー 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
この機能グループでは、ファイル・サーバー・マシンに新規サーバー・プロセス・バイナリーをインストールする方法、現行バージョンが適切に作動していない場合に前のバージョンに復帰する方法、および、AFS ボリュームを収容する新規のディスクをファイル・サーバー・マシンにインストールする方法について説明します。
サーバー・プロセスのバイナリーを置き換えるための最もよくある理由は、 AFS を新規のバージョンにアップグレードすることです。一般に、更新されたソフトウェアにはインストールの説明が付いていますが、この章は追加の解説書となります。
各 AFS サーバー・マシンは、規則では /usr/afs/bin と呼ばれるローカル・ディスク・ディレクトリーに、サーバー・プロセス・バイナリーを保管しなければなりません。予測可能なシステム・パフォーマンスのためには、すべてのサーバー・マシンで、同じ作成レベルまたは少なくとも同じバージョンのサーバー・ソフトウェアを実行することが最適です。AFS 作成レベルを調べるための指示については、バイナリー・ファイルの作成レベルの表示 を参照してください。
更新サーバーを使用すると、一貫したバージョンのソフトウェアをすべてのサーバー・マシンに容易に配布できます。システム・タイプごとに 1 つのサーバー・マシンをバイナリー配布マシン として指定します。そのためには、更新サーバーのサーバー部分 (upserver プロセス) をそのマシン上で実行します。そのシステム・タイプの、その他すべてのサーバー・マシンは、更新サーバーのクライアント部分 (upclientbin プロセス) を実行して、更新されたソフトウェアをバイナリー配布マシンから検索します。AFS インストールの手引き では、適切なプロセスをインストールする方法について説明しています。バイナリー配布マシンに関する詳細については、 バイナリー配布マシン を参照してください。
更新サーバーを使用する場合は、新規バイナリーをバイナリー配布マシンだけにインストールします。 upclientbin プロセスを実行しているマシンにバイナリーを直接インストールすると、プロセスがローカルの /usr/afs/bin ディレクトリーのコンテンツと、システム制御マシンのコンテンツを次回に比較したとき (デフォルトでは 5 分以内) に、バイナリーは上書きされます。
以下の指示は、bos の組の適切なコマンドを使用して、サーバー・バイナリーをインストールおよびアンインストールする方法について説明しています。
AFS サーバー・プロセスが /usr/afs/bin ディレクトリーにインストールされた直後に、自動的に新規プロセスのバイナリー・ファイルに切り替わることはありません。プロセスは、次に再始動されるまで、前のバージョンのバイナリー・ファイルを使用し続けます。デフォルトは、/usr/afs/local/BosConfig ファイルで指定されているように、 BOS サーバーは、新規バイナリー・ファイルが存在するプロセスを毎日午前 5 時に再始動します。このバイナリー再始動時刻 を表示または変更するには、 BOS サーバーの再始動時を設定する の説明に従って、 bos getrestart コマンドと bos setrestart コマンドを使用します。
以下の説明にあるように、bos restart コマンドを発行することによって、ファイル・サーバー・マシンに、新規サーバー・プロセス・バイナリーを使って開始するように強制することができます。
新規コマンドの組のバイナリーをインストールするときは、プロセスを再始動する必要はありません。組のコマンドを次回発行したときは、新規バイナリーが自動的に呼び出されます。
bos install コマンドを使用すると、BOS サーバーは、自動的に現行バージョンのバイナリー・ファイルの名前に .BAK 拡張子を付けて保管します。現行の .BAK バージョンがある場合、それは .OLD バージョンに名前変更されます (.OLD バージョンがまだない場合)。現行の .OLD バージョンがある場合には、現行の .BAK バージョンがそれを置き換えるためには、 .BAK バージョンは少なくとも 7 日前のものでなければなりません。
AFS バイナリーは、/usr/afs/bin ディレクトリーに保管するのが最適です。これは、BOS サーバーが新規バイナリーの有無を自動的に検査する唯一のディレクトリーだからです。ただし、bos install コマンドの -dir 引き数を使って、サーバー・マシンのローカル・ディスク上のほかのディレクトリーに非 AFS バイナリーをインストールすることができます。詳細については、 AFS Administration Reference にあるコマンドの解説ページを参照してください。
% bos listusers <machine name>
% bos install <machine name> <files to install>+
ここで、
fs プロセス以外の各 AFS サーバー・プロセスは、単一のバイナリー・ファイルを使用します。 fs プロセスは、3 つのバイナリー・ファイルを使用します。 fileserver、volserver、および salvager です。1 つのコンポーネントの新規バージョンをインストールすることは、必然的に、 3 つすべてを置き換える必要があることを意味するわけではありません。
AFS クライアント・マシンで作業している場合には、サーバー・プロセスを再始動する前に、 bos コマンドの組のバイナリーがローカル・ディスク上にあるかどうかを検証する。通例の構成では、 bos コマンドのバイナリーを収容するクライアント・マシンの /usr/afsws/bin ディレクトリーは、 AFS へのシンボリック・リンクであり、それによってローカル・ディスク・スペースが節約されます。ただし、特定のプロセス (特に、データベース・サーバー・プロセス) を再始動すると、再始動中に問題が発生した場合は特に、AFS ファイル・スペースがアクセス不能になる可能性があります。その場合も、bos バイナリーのローカル・コピーがあれば、プロセスのバイナリーをアンインストールまたは再インストールしたり、プロセスを再始動することができます。 cp コマンドを使って、 bos コマンドのバイナリーを /usr/afsws/bin ディレクトリーから /tmp などのローカル・ディレクトリーにコピーします。
プロセスを再始動すると、サービスの停止の原因になります。可能であれば、システムの使用率が低い時間帯に実行するのが最善です。
% bos restart <machine name> <instances>+
まれな例では、新規バイナリーをインストールすると、直前のバージョンに復帰する必要があるほど重大な問題を引き起こすこともあります。バイナリーをインストールする場合と同様に、一貫したシステム・パフォーマンスのためには、すべてのサーバー・マシンを同じバージョンに戻さなければなりません。ここで説明する bos uninstall コマンドを、各バイナリー配布マシンで発行します。
bos uninstall コマンドを使用すると、BOS サーバーは、現行バージョンのバイナリー・ファイルを破棄し、.BAK バージョンのファイルを、拡張子を除去してプロモートします。現行の .OLD バージョンがあれば、.BAK に名前を変更します。
現行の .BAK バージョンがない場合には、 bos uninstall コマンドのオペレーションは失敗し、エラー・メッセージが生成されます。 .OLD バージョンがまだ存在している場合は、mv コマンドを発行して、名前を .BAK に変更してから、bos uninstall コマンドを発行します。
新規バイナリーをインストールしたときと同じように、サーバー・プロセスが復帰したバージョンを使って即時に開始することはありません。現行バイナリーが機能しないために復帰している場合は、以下の指示に従って関係のあるプロセスを再始動します。
% bos listusers <machine name>
% bos uninstall <machine name> <files to uninstall>+
ここで、
AFS クライアント・マシンで作業している場合には、サーバー・プロセスを再始動する前に、 bos コマンドの組のバイナリーがローカル・ディスク上にあるかどうかを検証する。通例の構成では、 bos コマンドのバイナリーを収容するクライアント・マシンの /usr/afsws/bin ディレクトリーは、 AFS へのシンボリック・リンクであり、それによってローカル・ディスク・スペースが節約されます。ただし、特定のプロセス (特に、データベース・サーバー・プロセス) を再始動すると、再始動中に問題が発生した場合は特に、AFS ファイル・スペースがアクセス不能になる可能性があります。その場合も、bos バイナリーのローカル・コピーがあれば、プロセスのバイナリーをアンインストールまたは再インストールしたり、プロセスを再始動することができます。 cp コマンドを使って、 bos コマンドのバイナリーを /usr/afsws/bin ディレクトリーから /tmp などのローカル・ディレクトリーにコピーします。
% bos restart <machine name> <instances>+
/usr/afs/bin ディレクトリーにあるバイナリー・ファイルの 3 つのバージョン (現行、 .BAK および .OLD バージョン) すべての、コンパイル日付を検査することができます。これは、サーバー・プロセスを再始動して新規バイナリーを使用する前に、そのバイナリー配布マシンからファイル・サーバー・マシンに、新規バイナリーがコピーされたかどうかを検証する際に役立ちます。
/usr/afs/bin 以外のディレクトリーにあるバイナリーの日付を検査するには、-dir 引き数を追加します。 AFS Administration Reference を参照してください。
% bos getdate <machine name> <files to check>+
ここで、
新規バイナリーをもつプロセスが、何日も問題なく実行されている場合は、一般に .BAK および .OLD バージョンを /usr/afs/bin ディレクトリーから除去しても安全です。それによって、クラッターを削減し、ファイル・サーバー・マシンのローカル・ディスクのスペースを解放することができます。
bos prune コマンドのフラグを使用して、以下のタイプのファイルを除去することができます。
% bos listusers <machine name>
% bos prune <machine name> [-bak] [-old] [-core] [-all]
ここで、
サーバー・マシンおよびセル全体の最も一貫したパフォーマンスのためには、すべてのサーバー・プロセスが同じ AFS 配布から検索されるのが最適です。すべての AFS バイナリーには、そのバージョンまたは作成レベル を指定する ASCII 文字列が含まれています。それを表示するには、ほとんどの UNIX 配布に含まれている strings コマンドおよび grep コマンドを使用します。
% which binary_file /bin_dir_path/binary_file % cd bin_dir_path
% strings ./binary_file | grep Base
以下の形式で AFS ビルド・レベルが出力されます。
@(#)Base configuration afsversion build_level
たとえば、次の文字列は、AFS 3.6 build 3.0 のバイナリーであることを示しています。
@(#)Base configuration afs3.6 3.0
あらゆるサーバー・マシンでは、そのホーム・セルのデータベース・サーバー・マシンのリストを、ローカル・ディスクにあるローカル・ディスク・ファイル /usr/afs/etc/CellServDB で保守します。データベース・サーバー・プロセスおよびデータベース以外のサーバー・プロセスのどちらも、ファイルを調べます。
AFS 管理データベースの複写 で詳細に説明したように、データベース・サーバー・プロセスは Ubik ユーティリティーを使用して、保守するデータベース内の情報を同期化します。同期化サイトの Ubik コーディネーターは、データベースの単一の読み取り / 書き込みコピーを保守し、必要に応じて、変更を 2 次サイトに配布します。同期サイトのコーディネーターは、過半数の 2 次サイトとの交信を保守し、コーディネーターのままでいなければなりません。また、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 にファイルのコピーを保守することです。詳しくは、3 番目のレベル を参照してください。
% bos listhosts <machine name> [<cell name>]
ここで、
出力には、指定されたサーバー・マシンの CellServDB ファイルに表示される順序で、マシンをリストします。出力では、以下の例のように、それぞれのマシンに 1 つの Host インデックス番号を割り当てます。そのインデックスとマシンの IP アドレス、名前、または Ubik コーディネーターまたは 2 次サイトとしての役割との間に、暗黙の関係はありません。
% 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 アドレスを表示するには、ローカル・スーパーユーザー rootとして、サーバー・マシンにログインし、テキスト・エディターを使用するか、あるいは、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 サーバー・プロセスが、適切な許可ユーザーに対してだけ、特権を実行するという特権が付いています。サーバー・プロセスは、以下の 2 つのテストを実行して、適切に許可されているかどうかを決定します。
多くの個々のコマンドを使用すると、相互に認証しようとしなくても、anonymous の識別を想定することによって、認証テストをう回することができます。ただし、コマンドが特権で、サーバー・プロセスがまだ認証テストを実行している場合には、これは役に立たないことに注意してください。なぜなら、このような場合には、プロセスでは、特権コマンドを anonymous ユーザーに対して実行することを拒否するからです。
注: | anonymous ユーザー、または system:anyuser グループを特権リストに入れないでください。許可検査が無意味になります。
bos setauth コマンドを使用して、サーバー・マシンのサーバー・プロセスで、許可を検査するかどうかを制御することができます。ほかのサーバー・マシンは影響を受けません。許可検査をオフにすることはセキュリティー上非常に危険であることに留意してください。なぜなら、そのマシンのサーバー・プロセスは、どんなユーザーのためのどんなアクションでも実行するからです。 |
許可検査を使用不可にすることは、セキュリティー上の重大な欠陥となります。なぜなら、anonymous ユーザーであっても、ファイル・サーバー・マシンの AFS サーバー・プロセスは、任意のユーザーのどんなアクションでも実行するからです。
許可検査を使用不可にすることが一般的なのは、ユーザーが新規ファイル・サーバー・マシンをインストールしているときだけです (AFS インストールの手引き を参照してください)。これが必要となるのは、すべての必要なセキュリティー機構の構成を、通常これを使用する他のアクションを実行する前に行うことは不可能なためです。最高の安全のためには、インストールしているマシンのコンソールで作業した後すぐに、許可検査をオンにします。
通常のオペレーション中に、許可検査を使用不可にする唯一の理由は、サーバー暗号化鍵を使ってエラーが発生した場合に、サーバーがユーザーを正しく認証できないままにしておくことです。鍵関連の緊急事態の処理に関する説明については、 サーバー暗号化鍵の緊急事態の取り扱い を参照してください。
許可検査をそれぞれのファイル・サーバー・マシンで別々に制御します。 1 つのマシンで許可検査をオンにするかまたはオフにすることは、ほかのマシンには影響を及ぼしません。一般的に、クライアント・マシンはサーバー・プロセスを無作為に選択するため、すべてのマシンの要件を同じにしなければ、ある特定のコマンドに功を奏する許可検査の条件を予測することは困難です。許可検査をセル全体に対してオン / オフにするには、適切なコマンドをあらゆるファイル・サーバー・マシンで繰り返さなければなりません。
サーバー・プロセスは、そのローカル・ディスクにあるディレクトリー /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 コマンドでは、相互認証をう回することができます。認証済みの識別を使って、すでに対話モードを入力した場合には、 (kas) noauthentication コマンドを発行し、 anonymous 識別を想定します。
これは、fs コマンドを発行する前に、 unlog コマンドを発行して、ユーザーのトークンを破棄しない限り不可能です。
既存のファイル・サーバー・マシンにディスクを追加するだけで、 AFS はユーザーのセルに記憶域を簡単に追加することができます。この機能グループでは、 AFS ボリュームを保管するために使用するディスクをインストールする方法、または除去する方法について説明します。 (AFS インストールの手引き で説明したように、記憶域を追加する別の方法は、追加のサーバー・マシンをインストールすることです。)
ディスクの追加と除去のどちらも、少なくても短時間のファイル・システムの停止の原因になります。それは、サーバー区分の新規のセットを認識させるために、 fs プロセスを再始動しなければならないからです。オペレーティング・システムには、ディスクを追加または除去する前に、マシンを止める必要があるものがあります。このような場合には、まず、すべての AFS サーバー・プロセスを終了しなければなりません。ほかのすべての点では、ディスクの追加または除去の AFS が関連した局面は、複雑ではありません。したがって、停止の期間は、主として、ディスクそのものをインストールまたは除去するのに要する時間によって異なります。
新規のディスクのインストールに関する以下の説明では、そのディスクに AFS ボリュームを収容する準備が完全に済んでいます。 vos create コマンドを使用して新規ボリュームを作成するか、あるいは、vos move コマンドを使用して、ほかの区分から既存のボリュームを移動することができます。説明については、 読み取り / 書き込みボリュームの作成 および ボリュームの移動 を参照してください。ディスクの除去に関する指示は、基本的には、インストールの指示の逆ですが、データの損失を保護する特別なステップが組み込まれます。
サーバー・マシンには、256 の AFS サーバー区分を収容することができます。ディレクトリーに取り付けられたそれぞれの区分には、/vicepindex (index は 1 または 2 文字の小文字) 形式の名前が付きます。規則では、マシン上の最初の区分は /vicepa に、 2 番目の区分は /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) の サーバー項目 に登録します。 sysid ファイルおよびサーバー項目は、同じ固有番号により識別され、これにより両者間の関連が作成されます。
キャッシュ・マネージャーがボリューム・ロケーション情報を要求すると、ボリューム・ロケーション (VL) サーバーは、ボリュームを含む各サーバー・マシンに対して登録されているインターフェースをすべて戻します。これにより、キャッシュ・マネージャーがマルチホーム・ファイル・サーバー・マシンに保管された AFS データにアクセスする際、複数アドレスを使用することができます。
ファイル・サーバーが VLDB サーバー項目にどのインターフェースを登録するか制御するのであれば、ローカル /usr/afs/local ディレクトリーに NetInfo および NetRestrict の 2 つのファイルを作成することにより制御が可能です。ファイル・サーバーは再始動するたびに NetInfo ファイルがこれが存在する場合にこれを読み取り、ローカル・マシンのインターフェースのリストを作成します。ファイルを作成しない場合には、ファイル・サーバーはオペレーティング・システムによって構成されたネットワーク・インターフェースのリストを使用します。その上でファイル・サーバーは、NetRestrict ファイルがある場合には、そのリストのアドレスを削除します。ファイル・サーバーは、sysid ファイルに結果リストを記録し、これと同じ固有 ID を持つ VLDB サーバー項目にインターフェースを登録します。
データベース・サーバー・マシンにおいては、NetInfo および NetRestrict ファイルはまた、他のデータベース・サーバー・マシンで実行されているデータベース・サーバー・プロセスと通信する際に Ubik データベース同期ライブラリーが使用するインターフェースを決定します。
各サーバー項目には、最大数の IP アドレスが存在します (AFS Release Notesを参照)。マルチホーム・ファイル・サーバー・マシンのインターフェースがこの最大数より多ければ、 AFS は超過分を無視します。このようなマシンについては、NetInfo および NetRestrict ファイルを使用して、どのインターフェースを登録するか制御するとよいでしょう。
何らかの理由により sysid ファイルがなくなった場合には、ファイル・サーバーは新規の固有 ID の新規ファイルを作成します。ファイル・サーバーが新規ファイルの内容を登録する際、ボリューム・ロケーション (VL) サーバーは通常、新規ファイルが既存のサーバー項目に対応することを自動的に認識し、既存のサーバー項目を新規ファイル内容および ID で上書きします。ただし、sysid ファイルを削除しなくて済むのであれば、削除しない方がよいでしょう。
同様に、ファイル・サーバー・マシン間で sysid ファイルをコピーしないでください。新規のファイル・サーバー・マシンをインストールする作業の一部として、既存のマシンの /usr/afs ディレクトリーの内容を普通にコピーするのであれば、新規マシンの /usr/afs/local ディレクトリーから sysid ファイルを削除してからファイル・サーバーを開始するようにしてください。
既存のサーバー項目を新規 sysid ファイルの内容および ID で上書きしてよいか VL サーバーが判別できない場合があります。VL サーバーはこの場合、ファイル・サーバーがインターフェースを登録できないようにし、ファイル・サーバーは開始できません。これはたとえば、新規 sysid ファイルに、現在別々のサーバー項目に登録されている 2 つのインターフェースが含まれる場合に起こります。このような場合、VL サーバー・マシンの /usr/afs/log/VLLog ファイルおよびファイル・サーバー・マシンの /usr/afs/log/FileLog ファイルにあるエラー・メッセージが、vos changeaddr コマンドを使用して問題を解決する必要があることを示します。指示および支援については、AFS プロダクト・サポート・グループにご連絡ください。
このようにまれな場合を除き、vos changeaddr コマンドの適切な使用法としては、ファイル・サーバー・マシンをサービスから削除する場合に VLDB サーバー項目を完全に削除する場合があります。VLDB は、最大数のサーバー項目を含むことができます (AFS Release Notesを参照)。使用されない項目を削除することにより、新規サーバー・マシンに必要なサーバー項目を割り当てることができます。以下の説明を参照してください。
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 アドレスが表示される場合は、これを変換することができないためです。
項目が存在する場合でも、これは必ずしもマシンが活動状態のファイル・サーバー・マシンであるとは限りません。使用されないサーバー項目を削除するには、以下の説明を参照してください。
% 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 サーバーを認識しているため、リモートのリブートは可能です。 BOS サーバーは、ローカル・スーパーユーザーrootとして、 bos exec コマンドを実行します。
サーバー・マシンをリブートすることは、いくつかのセルのルーチン保守の一部で、 AFS の資料の指示には、1 つのステップとして組み込まれています。リブートは、 AFS が関連した問題から回復するための標準メソッドであることを意図したものではないのは確かですが、マシンの反応が鈍いときや、ほかのすべての理にかなったオプションを試行したときの、唯一の最後の手段です。
リブートは、サービスの停止の原因になります。マシンにボリュームが保管されている場合には、リブートが完了し、ファイル・サーバーが再接続されるまで、そのすべてのボリュームにはアクセスできなくなります。そのマシンがデータベース・サーバー・マシンである場合には、それぞれのデータベース・サーバー・プロセスごとに同期化サイトを再選出している間は、そのデータベースからの情報は使用できなくなります。一般的には、VL サーバーの停止は、最大の影響を及ぼします。それは、キャッシュ・マネージャーが AFS データを取り出すためには、 VLDB にアクセスできなければならないからです。
規則では、サーバー・マシンの AFS 初期設定ファイルには、それぞれがリブートした後に、 BOS サーバーを再始動するための以下のコマンドが組み込まれています。 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
ここで、