付録 A 多重ホストデータを配置するためのシンボリックリンクの使用

この付録では、データサービスのコードを変更しないようにするために、シンボリックリンクを使用する方法について説明します。

第 1 章「データサービス API」において、既存のデータサービスの中には、そのデータファイルへのパス名が固定されているものもあり、固定されたパス名を変更する機構はないと説明しました。データサービスのコードを変更せずに、シンボリックリンクを使用できる場合もあります。

たとえば、データサービスがそのデータファイルに固定されたパス名 /etc/mydatafile を指定したと仮定します。このパスは、論理ホストのファイルシステムの 1 つにあるファイルを指す値を持つシンボリックリンクに変更できます。たとえば、/hahost1/A1/myservicename/mydatafile へのリンクに変更できます。

シンボリックリンクの使用には、潜在的な問題があります。つまり、データファイルの名前を内容とともに変更するデータサービス (あるいは、その管理手順の 1 つ) もあります。たとえば、データサービスが更新を実行するとき、まず、新しい一時ファイル /etc/mydatafile.new を作成すると仮定します。次に、このデータベースは rename(2) システムコール (あるいは、mv(1) プログラム) を使用し、この一時ファイルの名前を実際のファイルの名前に変更します。

rename("/etc/mydatafile.new", "/etc/mydatafile");

一時ファイルを作成し、その名前を実際のファイルの名前に変更するという一連の手順により、データサービスは、そのデータファイルの内容が常に適切であるようにしています。

rename(2) の操作はシンボリックリンクを破壊します。このため、/etc/mydatafile という名前は通常ファイルとなり、論理ホストのデュアルポート形式のファイルシステムの中ではなく、/etc ディレクトリと同じファイルシステムの中に存在することになります。/etc ファイルシステムは各ホスト専用であるため、テイクオーバーまたはスイッチオーバー後はデータが利用できなくなります。

このような状況の根本的な問題は、既存のデータサービスがシンボリックリンクに気が付かない、つまり、シンボリックリンクを考慮するように作成されていないことです。シンボリックリンクを使用し、データアクセスを論理ホストのファイルシステムにリダイレクトするには、データサービス実装がシンボリックリンクを消去しないように動作しなければなりません。したがって、シンボリックリンクは、論理ホストのファイルシステムへのデータの配置に関する問題をすべて解決できるわけではありません。