ワークグループ エンジンの詳細
このトピックでは、ワークグループ エンジンを最大限に活用する方法について説明します。
ネットワーク
サーバーおよびワークグループ製品には同一のネットワーク コンポーネントが含まれています。したがって、ワークグループ エンジンを Zen サーバー エンジンにアップグレードすることが可能です。クライアント側のリクエスターはいずれのタイプのエンジンにも接続することができます。
クライアント側の MicroKernel ルーターは、完全に確立されたアルゴリズムに従ってファイルのゲートウェイ オーナーシップを見つけます。
クライアント側のルーターが最初に試みることは、データと同じコンピューター上のエンジンに接続することです。このため、データが存在する場所でエンジンが実行されていることは常に非常に効果的です。
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 ファイルのデフォルトの場所については、
ファイルはどこにインストールされますか?を参照してください。
ゲートウェイ トポロジを実行している場合
データが存在する場所でエンジンを実行できない場合、最初の接続の待ち時間はより重要な問題になります。試してみることがいくつかあります。
1. クライアントの設定で[サポート プロトコル]を減らし、ネットワークで使用されていないプロトコルの使用が試みられないようにします。
2. ゲートウェイ一貫性保持を使用します。ゲートウェイ一貫性保持はクライアントの設定で、ゲートウェイ環境で最初の接続を確立するときの待ち時間をほとんどなくすことができます。[ゲートウェイ一貫性保持]がオンに設定されていると、クライアント ルーターがエンジンの実行されていないコンピューター名をレジストリに書き込むようにします。接続に失敗すると、ルーターはこのサーバー名を実行中のみ保存するのではなく、レジストリに保存します。次回アプリケーションが起動したとき、データのある場所のエンジンへの接続は試行されません。直ちに現在のゲートウェイを決定する次の段階に進みます。
この設定は ZenCC で切り替えることができます。ZenCC の Zen エクスプローラーで[ローカル クライアント]ノードを展開し、[MicroKernel ルーター]を右クリックします。[プロパティ]をクリックし、[アクセス]を選択します。[ゲートウェイ一貫性保持]オプションをクリックしてオンに設定し(チェック マークは、その設定が「オン」であることを表します)、[OK]をクリックします。
メモ: この機能はトポロジを固定するため、デフォルトではオフになっています。データが存在する場所にサーバー エンジンまたはワークグループ エンジンを追加した場合、この設定をオンにした各クライアントでオフに戻す必要があります。この設定をオフに戻すと、エンジンが実行されていないコンピューターのレジストリを消去するので、その後すぐにオンにすると新しいトポロジに基づいた新しいリストが生成されます。
ステータス コード 116
ステータス 116 は MicroKernel のステータス コードで、ゲートウェイとして動作する別の MicroKernel エンジンによってファイルが使用されていることを示します。アプリケーションがステータス コード 116 を受け取った場合、MicroKernel ルーターはロケーター ファイルを読むことができたけれどもゲートウェイ コンピューター上で実行されているエンジンと交信できなかったことを示します。
最初にしなければならないことは、ゲートウェイがどれかを見極めることです。この作業は Gateway Locator ツールを使用して行うことができます。
次に Zen System Analyzer(ZenSA)ネットワーク テストを使用してそのコンピューターに接続してみます。ZenSA は問題を分離するための役に立つ情報を提供します。
これが起こる 1 つの状況は、2 つのコンピューターがルーターで分けられていて、両方ともファイル サーバーを見ることができるが、互いを見ることができない場合です。
リダイレクト ロケーター ファイルの作成
ゲートウェイ エンジン操作のこの機能は、複数ディレクトリのデータベースのトランザクション アトミシティを保証し、また複数のデータ ディレクトリにわたるゲートウェイ エンジンの名前の変更を容易にします。
Zen クライアントがリモート データ ファイルにアクセスする際に次の方法を使用することを思い出してください。
1. データ ファイルと同一のコンピューター上でデータベース エンジンに接続を試みます。
2. 次に、そのリモート マシンでデータベース エンジンが使用可能でない場合、ローカル エンジンを使用してリモート ディレクトリのオーナーシップをとり、ロケーター ファイルを作成します。ゲートウェイ ロケーター ファイルが既に存在する場合、ローカル エンジンは使用されません。
3. 3 番目に、指定されたゲートウェイ エンジンを使用することを試みます。
ゲートウェイ設定は、データ ファイルが存在するコンピューター上に使用可能なデータベース エンジンがない場合にのみ有効になることを覚えておいてください。
この機能により、同一ボリューム上の複数ディレクトリのデータベースのトランザクションの一貫性を保持しながら動的(変動)ゲートウェイ エンジンを使用することができます。この利点は、別のゲートウェイ ロケーター ファイルを指示する新しいゲートウェイ ロケーター ファイルによってもたらされました。新しいタイプはリダイレクト ロケーター ファイルと呼びます。ディレクトリ D のロケーター ファイルを指示するリダイレクト ロケーター ファイルをディレクトリ A、B、C に持つことにより、ディレクトリ D のロケーター ファイルが指定するゲートウェイ エンジンが、ほかのディレクトリにあるデータ ファイルのサービスも確実に提供することができるようになります。
ディレクトリ D のロケーター ファイルが固定ゲートウェイを指定しているか、これらのファイルを最初に開いたエンジンによって動的に作成されるかにかかわらず、このアーキテクチャは指定されたすべてのディレクトリが必ず同一のゲートウェイ エンジンを使用します。同様に、いくつかのディレクトリの固定ゲートウェイを変更しようとする場合、リダイレクト ロケーター ファイルを使用すると、すべてのロケーター ファイルではなく、たった 1 つのロケーター ファイルを変更するだけで済みます。したがって、一定のハード ドライブ上のすべてのデータ ファイルが固定ゲートウェイを指定しているといないにかかわらず、同一ゲートウェイ エンジンを使用するように指定することができます。
リダイレクト ロケーター ファイルの要件
リダイレクト ロケーター ファイルの最初の行は "=>" で始め、その後に必ず同一ドライブ上にある別のロケーター ファイルのパスを指定する必要があります。パス名にはスラッシュおよび円記号の任意の組み合わせを使用することができます。スラッシュはすべてローカル オペレーティング システムの使用するタイプの区切り文字に変換されます。
スラッシュで終わるパスを指定した場合、データベース エンジンはパスの最後にデフォルトのロケーター ファイル名(~PVSW~.LOC)を追加します。指定したパスがスラッシュで終わっていない場合、データベース エンジンはパスにファイル名が含まれているものと見なします。
次の表は、リダイレクト ロケーター ファイルのパスの指定方法の一覧です。
これらのロケーター ファイルに複数レベルのリダイレクトを割り当てることができます。たとえば、最初のロケーター ファイルが 2 番目のロケーター ファイルを指示し、2 番目のロケーター ファイルが 3 番目のロケーター ファイルを指示するという具合です。各ワークグループ エンジンはそれぞれのロケーター ファイルを順に開き、実際のゲートウェイ名を探します。"=>" で始まらないロケーター ファイルを見つけると検索は中止されます。エンジンはこのロケーター ファイルがゲートウェイ エンジンを指定しているものと見なします。
リダイレクト ロケーター ファイルの作成
ほかのロケーター ファイルと同様、リダイレクト ロケーター ファイルは普通のテキスト ファイルです。リダイレクト ロケーター ファイルは手作業でもプログラムからでも作成することができます。リダイレクト ロケーター ファイルには読み取り専用フラグを設定しておかないと、そのディレクトリにあるデータ ファイルに最初にアクセスを試みたエンジンによって上書きされてしまいます。
リダイレクト ロケーター ファイルを作成するには
1. テキスト エディターを開き、新規テキスト ファイルを作成します。
2. 完了時にファイルをどこに保存するかを決定します。別のロケーター ファイルにリダイレクトしようとするデータ ファイルと同じディレクトリにファイルを保存します。
たとえば、C:\data にあるデータ ファイルが、確実にほかのデータ ファイルと同じゲートウェイ エンジンによってアクセスされるようにするには、C:\data を忘れないようにしておきます。
3. => と次のロケーター ファイルのパス名を入力します。前の手順の例で続けると、C:\data にある現在のデータ ファイルが、C:\moredata にあるロケーター ファイルで指定されたゲートウェイ エンジンに属するようにしたい場合、次のように入力します。
=>..\moredata\ (推奨)または
=>\moredata\ (推奨しません)
最初のケースでは現在のディレクトリからの相対パスを指定しています。2 番目のケースは現在のドライブからの絶対パスを指定しています。この例の場合では、両方とも同じ目的のディレクトリを解決することができます。
メモ: リダイレクト ロケーター ファイルでは相対パス( .\ または ..\ で始まる)を使用すること、また、同じデータにアクセスするすべてのワークステーションで同じ共有名を使用することを強くお勧めします。この 2 つの忠告に従えば、割り当てられたドライブでのネットワーク パス名の解決で起こるエラーを防ぐことができます。
4. ゲートウェイ エンジンを構成したいデータ ファイル ディレクトリに ~PVSW~.LOC という名前でファイルを保存します。
5. テキスト エディターを閉じます。
6. このテキスト ファイルに読み取り専用フラグを設定します。
ファイルを読み取り専用にするには、Windows エクスプローラーでファイル アイコンを右クリックして[プロパティ]ダイアログ ボックスを使用するか、プロンプトまたはプログラムで ATTRIB コマンドを使用します。
attrib +r ~pvsw~.loc
固定ゲートウェイで多数のデータ ディレクトリの同期をとるには
1. 手作業または Gateway Locator プログラムを使用して、リダイレクトしない読み取り専用の(固定)ロケーター ファイルを作成します。ゲートウェイとして使用するワークグループ エンジンを指定する必要があります。
たとえば、ロケーター ファイルに workgroup1 というコンピューター名をゲートウェイ エンジンとして指定し、ファイルが C:\data\db1 にあるとします。
2. 前の手順で指定したゲートウェイ エンジンを使用しようとする、その他のデータ ディレクトリごとに、リダイレクト ロケーター ファイルを作成する必要があります。各リダイレクト ロケーター ファイルは前の手順で作成したファイルを示す必要があります。
前の例でいうと、C:\data\db2 および C:\data\db3 にあるリダイレクト ロケーター ファイルは次のテキストを含みます。
=>..\db1\
これにより、このファイルを読み取ったエンジンはすべて相対パスに従って、指定された C:\data\db1 で別のロケーター ファイルを検索します。この場合、指定したディレクトリには workgroup1 をゲートウェイ コンピューターとして挙げているロケーター ファイルがあります。
動的ゲートウェイで多数のデータ ディレクトリの同期をとるには
1. 上記の手順に従いますが、手順 1 でロケーター ファイルが固定的に割り当てられないように書き込み可能にするだけです。
この場合、リダイレクト階層内にあるデータ ファイルにどのエンジンもアクセスしていなければ、目的のディレクトリにはロケーター ファイルがないということを覚えておいてください。この状態は正常です。動的ロケーター ファイルはエンジンの最初のデータ アクセスによって各セッションに作成され、最後のユーザー セッションが終了したときに削除されます。ロケーター ファイルが存在しないデータ ディレクトリを示すリダイレクト ロケーター ファイルを持つことは問題ありません。この場合、データ ファイルを最初に開いたエンジンがロケーター ファイルを作成します。
例
次の図に示したロケーター ファイルの例を使用すると、左側のリダイレクト ロケーター ファイルはデータベース エンジンに 1 つ上のディレクトリに行き、そのサブディレクトリの newdir でデフォルト名(~PVSW~.LOC)を持つ別のロケーター ファイルを探すように指示しています。今度は、このロケーター ファイルが ntserver1 という名前のコンピューター上にあるワークグループ エンジンがゲートウェイ エンジンであることを指定します。その結果、mydir ディレクトリにあるデータ ファイルにアクセスするために、ntserver1 にあるデータベース エンジンが使用されます。
![](../advops/images/advgway.png)