ワークグループエンジンの詳細

このトピックでは、ワークグループエンジンを最大限に活用する方法について説明します。

•

ネットワーク

•

サーバーとワークグループの技術的な相違

•

ワークグループの問題のトラブルシューティング

•

リダイレクトロケーターファイルの作成

ネットワーク

サーバーおよびワークグループ製品には同一のネットワークコンポーネントが含まれています。したがって、ワークグループエンジンを Zen サーバーエンジンにアップグレードすることが可能です。クライアント側のリクエスターはいずれのタイプのエンジンにも接続することができます。

クライアント側の MicroKernel ルーターは、完全に確立されたアルゴリズムに従ってファイルのゲートウェイオーナーシップを見つけます。

優先順位	手順
1	データファイルと同一のコンピューター上でデータベースエンジンに接続を試みます。
2	ローカルエンジン（クライアントマシン上の）を使用してデータファイルのオープンを試みます。
3	ファイルを所有するゲートウェイエンジンを見つけて接続を試みます。

クライアント側のルーターが最初に試みることは、データと同じコンピューター上のエンジンに接続することです。このため、データが存在する場所でエンジンが実行されていることは常に非常に効果的です。

Zen ネットワークサービスレイヤーは、リモートデータベースエンジンを検索し接続するために多種多様な方法を用いるため、データベースエンジンが実行されていないファイルサーバー上のファイルを最初に開こうとするときに時間がかかることがあります。ゲートウェイ一貫性保持をオンにすると、ルーターがエンジンの位置を特定するのに失敗した各マシンを記憶するので、その後その接続は試行されません。

リモートファイルサーバー上のエンジンに接続できなかった場合、ルーターはローカルエンジンがリモートファイルを開くことを許可します。ローカルエンジンはまず新しいロケーターファイルを作成し、リモートディレクトリのオーナーシップをとることを試みます。既にほかの MicroKernel がそのディレクトリを所有している場合、ローカルエンジンはルーターにステータスコード 116 を返します。

最後に、ルーターはゲートウェイコンピューターを探そうとします。ロケーターファイルを開き、ゲートウェイエンジンの名前を読み取ります。それからエンジンにリクエストを送ります。ルーターは MicroKernel からステータスコード 116 を受け取らなければロケーターファイルを読み取らないことに注意してください。したがって、ゲートウェイ機能を使用するためには、ローカルワークグループエンジンがインストールされている必要があります。ローカルエンジンがないためにローカルエンジンを使用してリモートファイルを開くことに失敗した場合、ルーターはロケーターファイルを読み取らず、ゲートウェイエンジンを見つけることができません。

サーバーとワークグループの技術的な相違

Zen サーバーエンジンとワークグループエンジンにはいくつかの重要な相違点があります。

プラットフォーム

Zen サーバーエンジンは、さまざまなプラットフォーム用の 64 ビット版および 32 ビット版を提供します。ワークグループエンジンの場合は 32 ビット Windows 版のみです。ワークグループエンジンを 64 ビット Windows オペレーティングシステムで実行することはできますが、アドレス領域が 4 GB に制限されているため、一般的に 64 ビットシステムでインストールされる（2 GB を超える）大量のメモリを活用することはできません。ワークグループエンジンを 32 ビットオペレーティングシステムにインストールする場合、アドレス領域の上限は 2 GB です。

ユーザーインターフェイス

Windows の場合、Zen サーバーエンジンは常に Windows のサービスとして実行するようにインストールされます。ワークグループエンジンは、アプリケーションまたはサービスのどちらとしてインストールするかを設定できます。新規インストールの場合、デフォルトでは、サービスとしてインストールされますアプリケーションとして実行するようにインストールした場合は、タスクバーの通知領域にあるアイコンをインターフェイスとして使用します。『Getting Started with Zen』の Workgroup エンジンのセットアップを参照してください。

認証と Btrieve セキュリティポリシー

Zen データベースエンジンは、オペレーティングシステムのユーザー認証に基づいて、オペレーティングシステムにおけるファイルのアクセス許可を適用します。ワークグループエンジンは自身でユーザーの認証を行いません。ワークグループエンジンは、ネットワーク上のシステムに接続することができれば、そのデータにアクセスできます。緩和度の高いワークグループセキュリティは、セキュリティよりも使いやすさを優先する小規模のオフィスを対象としています。

ワークグループエンジン用のオペレーティングシステム認証がないということは、Btrieve の "混合" セキュリティポリシーと "クラシック" セキュリティポリシーが同じであることを意味します。セキュリティポリシーの違いは、Zen サーバーエンジンとワークグループエンジン間の動作の違いです。詳細については、Zen セキュリティを参照してください。

ゲートウェイのサポート

ワークグループエンジンは、ローカル、リモート共にファイルを開いたすべての場所にロケーターファイルを作成することにより、ワークグループエンジンがゲートウェイのオーナーシップを絶えず動的に適合できるようにします。デフォルトで、ワークグループエンジンはほかのコンピューターやネットワークデバイスで認証されるユーザー ID でも実行されます。このため、ワークグループエンジンはゲートウェイ環境での使用に最適です。『Getting Started with Zen』のゲートウェイ構成のセットアップを参照してください。

Zen サーバーエンジンは必ずしもゲートウェイロケーターファイルを作成する、または引き受けるわけではありません。このため、サーバーエンジンをゲートウェイ環境で使用するような設計やテストを行っていません。そのため、ワークグループ環境でワークグループエンジンに代わってサーバーエンジンをゲートウェイとすることはサポートしていません。

非同期 I/O

Windows 版の Zen サーバーは非同期 I/O を使用します。また、データベースページの書き込みの結合は Zen サーバーでのみ行われます。これらの機能によって、I/O の負荷が高いときは、ワークグループエンジンに比べサーバーエンジンが大きなパフォーマンスの利点を得ることができます。

デフォルトの設定

いくつかのデータベース設定（キャッシュサイズやシステムキャッシュなど）のデフォルト値は、Zen サーバーエンジンとワークグループエンジンでそれぞれ異なります。ワークグループエンジン設定用のデフォルト値は、システムリソースの消費をより抑えるよう設定されます。設定リファレンスを参照してください。

ライセンスモデル

Zen Enterprise Server および Zen Workgroup ではユーザーカウントライセンスモデルを使用します。Zen Cloud Server では容量ベースライセンスモデルを使用します。『Zen User's Guide』のライセンスモデルを参照してください。

ワークグループの問題のトラブルシューティング

このセクションでは、ワークグループ環境での問題の解決に役立つヒントを提供します。

最初の接続での待ち時間

最初のファイルオープン要求が発行されるときに何度も遅延が起きるのであれば、次の方法が役に立つかどうか調べてください。

可能であれば、データが存在するシステムでエンジンが実行されるようにしてください。

ファイルオープン要求をどこに送るかを決定するクライアントにとって、データと同じマシン上のエンジンに接続することが最優先事項です。ワークグループエンジンがアプリケーションとして実行されるのを確実にするため、次のコマンドを使用してエンジンのアイコンをスタートアップフォルダーに入れます。

zenengnapp.exe

もう 1 つの方法としては、ワークグループエンジンをサービスとしてインストールします。詳細については、『Getting Started with Zen』を参照してください。また、Zen ファイルのデフォルトの場所については、ファイルはどこにインストールされますか？を参照してください。

ゲートウェイトポロジを実行している場合

データが存在する場所でエンジンを実行できない場合、最初の接続の待ち時間はより重要な問題になります。試してみることがいくつかあります。

クライアントの設定で［サポートプロトコル］を減らし、ネットワークで使用されていないプロトコルの使用が試みられないようにします。

ゲートウェイ一貫性保持を使用します。ゲートウェイ一貫性保持はクライアントの設定で、ゲートウェイ環境で最初の接続を確立するときの待ち時間をほとんどなくすことができます。［ゲートウェイ一貫性保持］がオンに設定されていると、クライアントルーターがエンジンの実行されていないコンピューター名をレジストリに書き込むようにします。接続に失敗すると、ルーターはこのサーバー名を実行中のみ保存するのではなく、レジストリに保存します。次回アプリケーションが起動したとき、データのある場所のエンジンへの接続は試行されません。直ちに現在のゲートウェイを決定する次の段階に進みます。

この設定は ZenCC で切り替えることができます。ZenCC の Zen エクスプローラーで［ローカルクライアント］ノードを展開し、［MicroKernel ルーター］を右クリックします。［プロパティ］をクリックし、［アクセス］を選択します。［ゲートウェイ一貫性保持］オプションをクリックしてオンに設定し（チェックマークは、その設定が「オン」であることを表します）、［OK］をクリックします。

メモ：この機能はトポロジを固定するため、デフォルトではオフになっています。データが存在する場所にサーバーエンジンまたはワークグループエンジンを追加した場合、この設定をオンにした各クライアントでオフに戻す必要があります。この設定をオフに戻すと、エンジンが実行されていないコンピューターのレジストリを消去するので、その後すぐにオンにすると新しいトポロジに基づいた新しいリストが生成されます。

ステータスコード 116

ステータス 116 は MicroKernel のステータスコードで、ゲートウェイとして動作する別の MicroKernel エンジンによってファイルが使用されていることを示します。アプリケーションがステータスコード 116 を受け取った場合、MicroKernel ルーターはロケーターファイルを読むことができたけれどもゲートウェイコンピューター上で実行されているエンジンと交信できなかったことを示します。

最初にしなければならないことは、ゲートウェイがどれかを見極めることです。この作業は Gateway Locator ツールを使用して行うことができます。

次に Zen System Analyzer（ZenSA）ネットワークテストを使用してそのコンピューターに接続してみます。ZenSA は問題を分離するための役に立つ情報を提供します。

これが起こる 1 つの状況は、2 つのコンピューターがルーターで分けられていて、両方ともファイルサーバーを見ることができるが、互いを見ることができない場合です。

リダイレクトロケーターファイルの作成

ゲートウェイエンジン操作のこの機能は、複数ディレクトリのデータベースのトランザクションアトミシティを保証し、また複数のデータディレクトリにわたるゲートウェイエンジンの名前の変更を容易にします。

Zen クライアントがリモートデータファイルにアクセスする際に次の方法を使用することを思い出してください。

データファイルと同一のコンピューター上でデータベースエンジンに接続を試みます。

次に、そのリモートマシンでデータベースエンジンが使用可能でない場合、ローカルエンジンを使用してリモートディレクトリのオーナーシップをとり、ロケーターファイルを作成します。ゲートウェイロケーターファイルが既に存在する場合、ローカルエンジンは使用されません。

3 番目に、指定されたゲートウェイエンジンを使用することを試みます。

ゲートウェイ設定は、データファイルが存在するコンピューター上に使用可能なデータベースエンジンがない場合にのみ有効になることを覚えておいてください。

この機能により、同一ボリューム上の複数ディレクトリのデータベースのトランザクションの一貫性を保持しながら動的（変動）ゲートウェイエンジンを使用することができます。この利点は、別のゲートウェイロケーターファイルを指示する新しいゲートウェイロケーターファイルによってもたらされました。新しいタイプはリダイレクトロケーターファイルと呼びます。ディレクトリ D のロケーターファイルを指示するリダイレクトロケーターファイルをディレクトリ A、B、C に持つことにより、ディレクトリ D のロケーターファイルが指定するゲートウェイエンジンが、ほかのディレクトリにあるデータファイルのサービスも確実に提供することができるようになります。

ディレクトリ D のロケーターファイルが固定ゲートウェイを指定しているか、これらのファイルを最初に開いたエンジンによって動的に作成されるかにかかわらず、このアーキテクチャは指定されたすべてのディレクトリが必ず同一のゲートウェイエンジンを使用します。同様に、いくつかのディレクトリの固定ゲートウェイを変更しようとする場合、リダイレクトロケーターファイルを使用すると、すべてのロケーターファイルではなく、たった 1 つのロケーターファイルを変更するだけで済みます。したがって、一定のハードドライブ上のすべてのデータファイルが固定ゲートウェイを指定しているといないにかかわらず、同一ゲートウェイエンジンを使用するように指定することができます。

リダイレクトロケーターファイルの要件

リダイレクトロケーターファイルの最初の行は "=>" で始め、その後に必ず同一ドライブ上にある別のロケーターファイルのパスを指定する必要があります。パス名にはスラッシュおよび円記号の任意の組み合わせを使用することができます。スラッシュはすべてローカルオペレーティングシステムの使用するタイプの区切り文字に変換されます。

スラッシュで終わるパスを指定した場合、データベースエンジンはパスの最後にデフォルトのロケーターファイル名（~PVSW~.LOC）を追加します。指定したパスがスラッシュで終わっていない場合、データベースエンジンはパスにファイル名が含まれているものと見なします。

次の表は、リダイレクトロケーターファイルのパスの指定方法の一覧です。

パス	意味
=>\path_name	現在のロケーターファイルが格納されているルートドライブからパスを指定します。
=>.\path_name	現在のディレクトリからの相対パスを指定します。
=>..\path_name	現在のディレクトリの親ディレクトリからの相対パスを指定します。

リダイレクトロケーターファイルの作成

ほかのロケーターファイルと同様、リダイレクトロケーターファイルは普通のテキストファイルです。リダイレクトロケーターファイルは手作業でもプログラムからでも作成することができます。リダイレクトロケーターファイルには読み取り専用フラグを設定しておかないと、そのディレクトリにあるデータファイルに最初にアクセスを試みたエンジンによって上書きされてしまいます。

リダイレクトロケーターファイルを作成するには

テキストエディターを開き、新規テキストファイルを作成します。

完了時にファイルをどこに保存するかを決定します。別のロケーターファイルにリダイレクトしようとするデータファイルと同じディレクトリにファイルを保存します。

たとえば、C:\data にあるデータファイルが、確実にほかのデータファイルと同じゲートウェイエンジンによってアクセスされるようにするには、C:\data を忘れないようにしておきます。

=> と次のロケーターファイルのパス名を入力します。前の手順の例で続けると、C:\data にある現在のデータファイルが、C:\moredata にあるロケーターファイルで指定されたゲートウェイエンジンに属するようにしたい場合、次のように入力します。

=>..\moredata\ （推奨）または

=>\moredata\ （推奨しません）

最初のケースでは現在のディレクトリからの相対パスを指定しています。2 番目のケースは現在のドライブからの絶対パスを指定しています。この例の場合では、両方とも同じ目的のディレクトリを解決することができます。

メモ：リダイレクトロケーターファイルでは相対パス（ .\ または ..\ で始まる）を使用すること、また、同じデータにアクセスするすべてのワークステーションで同じ共有名を使用することを強くお勧めします。この 2 つの忠告に従えば、割り当てられたドライブでのネットワークパス名の解決で起こるエラーを防ぐことができます。

ゲートウェイエンジンを構成したいデータファイルディレクトリに ~PVSW~.LOC という名前でファイルを保存します。

テキストエディターを閉じます。

このテキストファイルに読み取り専用フラグを設定します。

ファイルを読み取り専用にするには、Windows エクスプローラーでファイルアイコンを右クリックして［プロパティ］ダイアログボックスを使用するか、プロンプトまたはプログラムで ATTRIB コマンドを使用します。

attrib +r ~pvsw~.loc

固定ゲートウェイで多数のデータディレクトリの同期をとるには

手作業または Gateway Locator プログラムを使用して、リダイレクトしない読み取り専用の（固定）ロケーターファイルを作成します。ゲートウェイとして使用するワークグループエンジンを指定する必要があります。

たとえば、ロケーターファイルに workgroup1 というコンピューター名をゲートウェイエンジンとして指定し、ファイルが C:\data\db1 にあるとします。

前の手順で指定したゲートウェイエンジンを使用しようとする、その他のデータディレクトリごとに、リダイレクトロケーターファイルを作成する必要があります。各リダイレクトロケーターファイルは前の手順で作成したファイルを示す必要があります。

前の例でいうと、C:\data\db2 および C:\data\db3 にあるリダイレクトロケーターファイルは次のテキストを含みます。

=>..\db1\

これにより、このファイルを読み取ったエンジンはすべて相対パスに従って、指定された C:\data\db1 で別のロケーターファイルを検索します。この場合、指定したディレクトリには workgroup1 をゲートウェイコンピューターとして挙げているロケーターファイルがあります。

動的ゲートウェイで多数のデータディレクトリの同期をとるには

上記の手順に従いますが、手順 1 でロケーターファイルが固定的に割り当てられないように書き込み可能にするだけです。

この場合、リダイレクト階層内にあるデータファイルにどのエンジンもアクセスしていなければ、目的のディレクトリにはロケーターファイルがないということを覚えておいてください。この状態は正常です。動的ロケーターファイルはエンジンの最初のデータアクセスによって各セッションに作成され、最後のユーザーセッションが終了したときに削除されます。ロケーターファイルが存在しないデータディレクトリを示すリダイレクトロケーターファイルを持つことは問題ありません。この場合、データファイルを最初に開いたエンジンがロケーターファイルを作成します。

例

次の図に示したロケーターファイルの例を使用すると、左側のリダイレクトロケーターファイルはデータベースエンジンに 1 つ上のディレクトリに行き、そのサブディレクトリの newdir でデフォルト名（~PVSW~.LOC）を持つ別のロケーターファイルを探すように指示しています。今度は、このロケーターファイルが ntserver1 という名前のコンピューター上にあるワークグループエンジンがゲートウェイエンジンであることを指定します。その結果、mydir ディレクトリにあるデータファイルにアクセスするために、ntserver1 にあるデータベースエンジンが使用されます。