この章では、TimesTen Scaleoutでグリッドを作成および構成する方法について説明します。
グリッドは、1つ以上のデータベースの分散データが含まれている一連の関連インスタンスです。グリッドには、2つのタイプのインスタンスがあります。
管理インスタンスはグリッドを制御し、グリッドの中央構成であるモデルを維持します。グリッドの管理の可用性を実現するために最大2つの管理インスタンスを構成できます。
データ・インスタンスはグリッドによって管理されるすべてのデータベースのデータを格納します。
次の各項では、グリッドを設定するためのタスクについて説明します。
|
ノート: この章では、コマンドラインおよびttGridAdminユーティリティを使用してグリッドを完全に構成するために必要なタスクについて説明しますが、Oracle SQL Developerを使用してグリッドを構成することもできます。詳細は、Oracle SQL Developer Oracle TimesTen In-Memory Databaseサポート・ユーザーズ・ガイドのTimesTen Scaleoutの使用を参照してください。
また、TimesTen Scaleoutには、開発およびテストのために単一のデータベースを含む単純なグリッドを迅速に設定するための |
TimesTen Scaleoutでは、管理インスタンスを使用して、グリッドを構成および管理します。管理インスタンスでは、グリッドにシェイプを付与するオブジェクトの包括的なリストであるモデルが格納および維持されます。
|
重要:
|
グリッドの管理の高可用性を確保するために、TimesTen Scaleoutを使用して、アクティブなスタンバイ構成でスタンバイ管理インスタンスを作成できます。アクティブ管理インスタンスで障害が発生した場合に使用できるスタンバイ管理インスタンスを構成することをお薦めします。1つのみの管理インスタンスに障害が発生した場合、データベースは動作しますが、管理インスタンスがリストアされるまでほとんどの管理操作は使用できません。スタンバイ管理インスタンスを設定するステップは、この章で後述します。
ttInstanceCreateユーティリティは、新規インスタンスを作成します。TimesTen Scaleout管理のインスタンスを有効化する-gridオプションを含めることによって、ttInstanceCreateユーティリティを使用して初期管理インスタンス作成します。このインスタンスからグリッドを作成すると、グリッドに関連付けられている後続のすべてのインスタンスが、ttGridAdminユーティリティを使用して作成されます。グリッド内のすべてのインスタンスは、インスタンス管理者として同じOSユーザー名を共有します。
|
ノート: この項および次のいくつかの項で説明するタスクでは、K-safety (k)が2に設定され、8台のホスト(TimesTenインストールおよび管理インスタンスが含まれるホストが2台、それぞれに3台のホスト(各ホストにTimesTenインストールおよびデータ・インスタンスが含まれる)があるデータ領域グループが2つ)で構成されたグリッドのシナリオを使用します。図4-1に、このシナリオの図を示します。 |
TimesTen 18.1がインストールされているホストで、選択した場所(/gridディレクトリなど)に管理インスタンスを作成します。
% /grid/tt18.1.4.1.0/bin/ttInstanceCreate -name instance1 -location
/grid -grid
Creating instance in /grid/instance1 ...
INFO: Mapping files from the installation to /grid/instance1/install
NOTE: The TimesTen daemon startup/shutdown scripts have not been installed.
The startup script is located here :
'/grid/instance1/startup/tt_instance1'
Run the 'setuproot' script :
/grid/instance1/bin/setuproot -install
This will move the TimesTen startup script into its appropriate location.
The 18.1.4.1 Release Notes are located here :
'/grid/tt18.1.4.1.0/README.html'
使用するシェルに適したttenvスクリプト(ttenv.cshまたはttenv.sh)を使用してinstance1管理インスタンスの環境変数を設定していることを確認します。
sh、bash、zsh、kshなどのBourne型のシェルの場合
$ . /grid/instance1/bin/ttenv.sh
cshまたはtcshシェルの場合
% source /grid/instance1/bin/ttenv.csh
ttInstanceCreateユーティリティの詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのttInstanceCreateを参照してください。
環境変数の詳細は、環境変数を参照してください。
ttGridAdminユーティリティを使用して、グリッドの状態および構成を操作できます。ttGridAdminユーティリティを使用する必要があるすべての操作は、特に指定のないかぎり、インスタンス管理者がアクティブな管理インスタンスから実行する必要があります。このユーティリティを使用して、グリッドの構成およびメンテナンスに関連する、次のようなすべての操作を実行します。
新規グリッドの作成
ホストやインスタンスなどのモデル・オブジェクトの作成および削除
データベースの作成および破棄
ユーザー・データが使用可能なデータ・インスタンス間で分散される方法の定義および変更
データベースの接続属性などのモデル・オブジェクトの属性の変更
グリッドのステータスおよびそのデータベースの問合せ
様々なバージョンのモデルの維持
最新バージョンのモデルに加えた変更の操作グリッドへの適用。
|
ノート: ttGridAdminユーティリティの詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのttGridAdminを参照してください。 |
ttGridAdmin gridCreateコマンドでは、次の操作を実行します。
アクティブ管理インスタンスを起動します。
ユーザー定義の名前でグリッドを作成します。
K-safetyの値で示されている必要な数のデータ領域グループを作成します。
メンバーシップ・サービスのクライアント構成を定義します。メンバーシップ・サービスおよび必要なZooKeeperクライアント構成ファイルの詳細は、第3章「メンバーシップ・サービスの設定」を参照してください。
管理インスタンスとその関連ホストおよびインストールを、モデル・オブジェクトとして最新バージョンのモデルに追加します。
kを2に設定したグリッドを作成します。グリッドの名前(ローカル・システムの内部アドレスまたは内部および外部のアドレス)を指定し、ZooKeeperクライアント構成ファイルを指定します。
% ttGridAdmin gridCreate grid1 -k 2 -internalAddress int-host1 -externalAddress ext-host1.example.com -membershipConfig /tmp/membership.conf Grid grid1 created
grid1グリッドを作成するために、TimesTen Scaleoutはinstance1管理インスタンスを起動します。次に、instance1管理インスタンスがgrid1グリッドおよびそのモデルを作成します。最後に、instance1管理インスタンスがgrid1グリッドのモデルで次の操作を実行します。
モデルでローカル・システムを表すホスト・オブジェクトhost1を作成します。
モデルでローカルTimesTenインストールを表すインストール・オブジェクトinstallation1を作成します。
モデルでインスタンス・オブジェクトinstance1を作成します。
installation1インストールをhost1ホストおよびinstance1インスタンスの両方に関連付けます。
2つのデータ領域グループを作成します(kが2に設定されているため)。
|
重要: この時点から、記載されているタスクでは、モデル・オブジェクトが最新バージョンのモデルに追加され、変更されるだけで、最新バージョンのモデルに対する変更が適用されるまで、このようなモデル・オブジェクトに関連付けられたシステムは変更されません。詳細は、モデルに加えた変更の適用を参照してください。 |
図4-2に、grid1グリッドの作成後のモデルの図を示します。
ttGridAdmin gridCreateコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのグリッドの作成(gridCreate)を参照してください。
TimesTen Scaleoutを使用すると、グリッドの2番目の管理インスタンスを作成できます。グリッドに2つの管理インスタンスが存在する場合、グリッドの構成は、アクティブなスタンバイ構成を使用してアクティブな管理インスタンスからスタンバイ管理インスタンスにレプリケートされます。アクティブな管理インスタンスとスタンバイ管理インスタンスの間のレプリケーションは非同期です。TimesTen Scaleoutで管理インスタンスのアクティブなスタンバイ構成を使用する方法の詳細は、管理インスタンスのフェイルオーバーの管理を参照してください。
TimesTen Scaleoutでは、2番目の管理インスタンスがスタンバイとして自動的に構成されます。グリッドの構成を使用および操作するすべての操作は、ttGridAdminユーティリティを使用してアクティブな管理インスタンスから実行する必要があります。
グリッドで構成するすべての管理インスタンスを別のホストに配置することをお薦めします。これらのホストは、(独立電源、ストレージおよび他のリソースを備えた)異なる障害ドメインにある必要があります。関連付けられているシステムの通信パラメータ(完全修飾ドメインまたはIPアドレス)を指定して、すべてのホストをモデルに手動で追加する必要があります。
ttGridAdmin hostCreateコマンドは、モデル内のホスト・オブジェクトを定義します。このコマンドでは、-likeオプションを使用して、インスタンス(管理またはデータ)を作成し、データ領域グループなど、既存のホストの属性をコピーできます。また、-likeオプションとともに-cascadeオプションを使用して、関連付けられているインストールおよびインスタンスをコピーすることもできます。
アクティブな管理インスタンスhost1.instance1に関連付けられているホストを複製して、スタンバイ管理インスタンスとそれに関連するインストールを作成します。新しいホストの完全修飾ドメイン名またはIPアドレスを識別できることを確認します。
% ttGridAdmin hostCreate -internalAddress int-host2 -externalAddress ext-host2.example.com -like host1 -cascade Host host2 created in Model Installation installation1 created in Model Instance instance1 created in Model
|
ノート:
|
図4-3に、host2ホスト、host2.installation1インストールおよびhost2.instance1管理インスタンスの作成後のgrid1グリッドのモデルの図を示します。
host2ホスト用に作成されたインストールおよび管理インスタンスに割り当てられる名前は、カスケード操作の結果、host1ホストに割り当てられている名前と同じになります。完全修飾名が異なるため、これにより競合が発生することはありません。詳細は、Oracle TimesTen In-Memory Databaseリファレンスのグリッド・オブジェクトとオブジェクトの命名を参照してください。
ttGridAdmin hostCreateコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのホストの作成(hostCreate)を参照してください。
データベースは、まとめて1つのデータベース・イメージを提供する複数のデータ・インスタンス間で分散されます。データ・インスタンスはホスト上にあります。グリッドに含まれる各ホストおよびデータ・インスタンスを作成します。このため、グリッドを設計する場合、作成するホストおよびデータ・インスタンスの数を計算する必要があります。
K-Safety (k)の値に対して定義するデータのコピー数は、グリッドの作成に必要なデータ・インスタンスおよびホストの数の要因となります。kを2に設定してデータの複製コピーを定義する場合は、kを1に設定してデータのコピーが1つ必要な場合よりも2倍の数のデータ・インスタンスおよびホストが必要になります。
|
ノート: 2は、kの値として割り当てることができる最大数です。 |
作成するデータ・インスタンスの数は、次の2つの要因によって異なります。
kの値: kを1に設定した場合、作成するデータ・インスタンスの数は、各データベースに必要な要素の数と等しくなります。kを2に設定した場合、2倍の数のデータ・インスタンスを作成する必要があります。1セットのデータ・インスタンスは、レプリカ・セット内に含まれているデータベースの各コピーを管理します。
データを分散するレプリカ・セットの数: 作成するデータ・インスタンスの数は、すべてのレプリカ・セット内の要素の数によって決定されます。これは、各データ・インスタンスが各データベースの1つの要素を管理するためです。
データベースの1つのコピーを構成するすべての要素が、データ領域内で割り当てられます。データベースの2つのコピー用にkを2に設定した場合、各レプリカ・セットには2つの要素が含まれ、各要素はレプリカ・セット内の他の要素の正確なコピーになります。各データ領域には、各レプリカ・セットのレプリカ要素のいずれか1つが含まれます。
|
ノート: 各データ領域には、論理的に、データベースのデータの完全コピーが含まれます。データのコピーがk個あるため、k個のデータ領域があります。データ・インスタンスは、ホストがデータ領域グループにどのように割り当てられるかに基づいてデータ領域に割り当てられます。 |
データを分散するレプリカ・セットの数を計算するには、次の2つの最大値を決定します。
データベース・サイズとホスト・メモリー・サイズ。各ホストのデータベースのサイズおよびメモリーの量によって、必要なレプリカ・セットの数が決定されます。たとえば、それぞれ512 GBのメモリーでホストする2 TBのデータベースがある場合、すべてのデータを保持するには、少なくとも4のレプリカ・セットが必要です。各ホスト上のすべてのメモリーをデータに使用できないため、5つのホストを必要とする可能性が高くなります。
スループット。データベースが1つのホストのメモリーに収まるくらい小さい場合でも、1つのホストが、アプリケーションに必要な秒当たりのトランザクション数を処理できない場合は、複数のホストにデータを分散する必要があります。
レプリカ・セットの数を決定したら、データ・インスタンスの数を計算できます。
必要なデータ・インスタンスの数を確認する式で、rはレプリカ・セット(各レプリカ・セットに1つまたは2つの要素が含まれている)の数を表し、kはデータのコピー数、その後、各レプリカ・セットの要素の数を示すK-safety値を表します。十分なデータ・インスタンスを作成するには、k * r個のデータ・インスタンスを作成する必要があります。
number of data instances = k * r
たとえば、データベースの2つのコピー用にkを2に設定し、3つのレプリカ・セットにデータベースの各コピーが分散される場合、6つのデータ・インスタンスを作成する必要があります。そのうち3つのデータ・インスタンスにはデータ領域1のレプリカ要素が含まれ、3つのデータ・インスタンスにはデータ領域2のレプリカ要素が含まれます。
データ領域の詳細は、データ領域の理解を参照してください。レプリカ・セットの詳細は、レプリカ・セットの理解を参照してください。
グリッドの本番デプロイメントの物理システムまたは仮想システムの数を計算する場合は、次の点を考慮します。
メンバーシップ・サーバーのホスト。メンバーシップ・サーバーに必要なホストの数の詳細は、メンバーシップ・サービスとしてのApache ZooKeeperの使用方法を参照してください。
管理インスタンスのホスト。管理インスタンスに必要なホストの数の詳細は、スタンバイ管理インスタンスの追加を参照してください。
データ・インスタンスのホスト。この項では、グリッド内のデータ・インスタンスの数をサポートするために必要なホストの数を説明します。
必要なホストの数は、各ホストにインストールするデータ・インスタンスの数によって異なります。次の内容は、データ・インスタンスで説明されています。
データの可用性を最大化し、ホストの1つに障害が発生した場合のデータ損失を防ぐために、各データ・インスタンスは、通常、個別のホストに存在します。ただし、次のような場合は、1つのホストで複数のデータ・インスタンスを実行することもできます。
グリッド内のホストに大量のコンピューティング・リソースが含まれている。
デプロイメント前のより大きなグリッドの実験のために、少数のホストでより大きなグリッド構成をテストする。
次のように、ホストの数を決定します。
ホストごとに1つのデータ・インスタンスをインストールする場合、必要なホストの数は、グリッド内のデータ・インスタンスの数と同じです。たとえば、6つのデータ・インスタンスがある場合は、6つのホストを作成します。
ホストごとに複数のデータ・インスタンスをインストールする場合、必要なホストの数は、各ホストのデータ・インスタンスの数によって異なります。たとえば、8つのデータ・インスタンスがあり、各ホストに2つのデータ・インスタンスをインストールする場合は、4のホストのみが必要です。
データ・インスタンスのホストを作成した後は、データ領域グループに割り当てます。詳細は、データ領域グループへのホストの割当てを参照してください。
データ・インスタンスは、データ領域グループに含まれていないホストでは作成されません。データ領域グループの数は、kに設定された値によって異なります。kが2に設定されている場合は、データ領域グループが2つになります。
データ領域グループへのホストの割当てで説明するように、データ領域グループにホストを追加すると、データの物理的な場所が指定されます。1つのデータ領域グループのホストは、別のデータ領域グループのホストのグループから物理的に分離して、データベースのそれぞれの完全コピーをハードウェア障害から保護する必要があります。
図4-4に、2つのデータ領域グループを含むグリッドの例を示します。データ領域ごとにデータのコピーが1つ含まれています。6つのホストに、kが2に設定されているK-safety環境でデータの2つのコピーをサポートする3つのレプリカ・セットを持つデータ・インスタンスが含まれています。データのコピーが1つ含まれているデータ・インスタンスを含む3つのホストがデータ領域グループ1に割り当てられ、データの2番目のコピーを含むデータ・インスタンスを含む別の3つのホストがデータ領域グループ2に割り当てられています。
各データ領域グループ内のホストの数が等しくなるように、データ領域グループにホストを割り当てます。ただし、各データ領域グループに後でホストを割り当てたり、TimesTen Scaleoutにホストの推奨割当てを依頼できます。
|
ノート: TimesTen Scaleoutでは、ホストがデータ領域グループに割り当てられていない場合、ホストでデータ・インスタンスを作成できません。 |
ttGridAdmin hostCreateコマンドの-dataspacegroupオプションを使用して、ホスト作成の一部としてデータ領域グループにホストを割り当てることができます。データ・インスタンスの追加では、このオプションの例を示します。
後で、ttGridAdmin hostModify -dataspacegroupコマンドを使用してホストを作成し、データ領域グループに割り当てることができます。
複雑な物理トポロジがある場合、ttGridAdmin dataSpaceGroupSuggestコマンドを使用すると、ttGridAdmin dataSpaceGroupSuggestコマンドを使用して、複数のホストのデータ領域グループの割当ての推奨をTimesTen Scaleoutから受け取ることができます。この方法の詳細は、グリッドの物理トポグラフィの説明を参照してください。
データ・インスタンスには、グリッドで定義されている各データベースの要素が含まれています。要素には、1つのデータベースのデータの一部が格納されます。データは、グリッドで定義されているデータ・インスタンスの数と等しい数の要素間で分散される場合があります。
次のタスクを実行して、グリッド内にデータ・インスタンスを作成します。
管理インスタンスに関連付けられたホストと同様に、データベースのデータの一部を格納するために使用するすべてのシステムでは、システムをホスト・モデル・オブジェクトとして手動で追加する必要があります。同様に、システムの通信パラメータ(完全修飾ドメインまたはIPアドレス)を指定する必要があります。各ホストには2つ以上のデータ・インスタンスを含めることができますが、ホストごとに1つのデータ・インスタンスを構成することをお薦めします。
データ・インスタンスを作成するには、ホストをデータ領域グループに関連付ける必要があります。すべてのデータ領域グループは、同じ数のデータ・インスタンスに関連付けられる必要があります。ホストごとに1つのデータ・インスタンスの推奨事項に従っている場合、すべてのデータ領域グループは同じ数のホストに関連付けられる必要があります。
スタンバイ管理インスタンスの追加で説明したように、ttGridAdmin hostCreateコマンドを使用すると、グリッド内にホストが作成されます。ホストの作成時以降に、ホストをデータ領域グループまたは物理グループに関連付けることができます。
|
ノート: 最初にデータ領域グループにホストを関連付けない場合は、すべてのホストを作成した後にTimesTen ScaleoutでttGridAdmin dataSpaceGroupSuggestコマンドを使用して、モデルを分析し、各ホストに関連付けられている物理グループに基づいて、各データ領域グループに関連付けるホストを表示することもできます。詳細は、物理グループを使用した物理トポロジの記述およびデータ領域グループへのホストの割当てを参照してください。 |
データ・インスタンスのホストを作成し、データ領域グループ1に関連付けます。ホストの完全修飾ドメイン名またはIPアドレスを識別できることを確認します。
% ttGridAdmin hostCreate -internalAddress int-host3 -externalAddress ext-host3.example.com -dataSpaceGroup 1 Host host3 created in Model
|
ノート: ホストの名前を指定しない場合、TimesTen Scaleoutでは、リモート・システムのOSホスト名が新しいホストの名前として設定されます。 |
図4-5に、host3ホストの作成後のgrid1グリッドのモデルの図を示します。
ttGridAdmin hostCreateコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのホストの作成(hostCreate)を参照してください。
すべてのホストには、インストールが関連付けられている必要があります。ホストは、インストール・ファイルの独自のコピーを所有するか、Network Attached Storageを使用して1つ以上のホストとインストールを共有できます。共有インストールの場合、共有インストール・ファイルの場所を含むインストール・モデル・オブジェクトがホストに関連付けられている必要があります。
TimesTenインストールの共有方法の詳細は、『Oracle TimesTen In-Memory Databaseインストレーション、移行およびアップグレード・ガイド』のLinux/UNIXでのインストールのコピーに関する項を参照してください。
ttGridAdmin installationCreateコマンドはグリッドにインストールを作成し、ホストに関連付けます。
host3ホストの任意のディレクトリ(/gridディレクトリなど)にインストールを作成します。
% ttGridAdmin installationCreate host3 -location /grid Installation installation1 on Host host3 created in Model
図4-6に、host3ホストでのinstallation1インストールの作成後のgrid1グリッドのモデルの図を示します。
ttGridAdmin installationCreateコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのインストールの作成(installationCreate)を参照してください。
ttGridAdmin instanceCreateコマンドはグリッドにインスタンスを作成し、ホストとインストールに関連付けます。
host3ホストの任意の場所(/gridディレクトリなど)にデータ・インスタンスを作成します。
% ttGridAdmin instanceCreate host3 -location /grid Instance instance1 on Host host3 created in Model
図4-7に、データ・インスタンスの作成後のgrid1グリッドのモデルの図を示します。
ttGridAdmin instanceCreateコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのインスタンスの作成(instanceCreate)を参照してください。
スタンバイ管理インスタンスの追加で説明したように、ttGridAdmin hostCreateコマンドの-likeおよび-cascadeオプションを使用して既存のホストの構成(関連するインストールおよびインスタンスなど)を複製することでインスタンス(管理またはデータ)を作成できます。
-likeオプションは、複製されるホストを識別し、新しいホストを同じ物理グループおよびデータ領域グループに関連付けます。新しいホストに関連付けられている物理グループおよびデータ領域グループを上書きするには、それぞれ-physicalGroupおよび-dataSpaceGroupオプションで異なるパラメータを指定します。
-cascadeオプションは、指定されたホストに関連付けられているインストールおよびデータ・インスタンスの構成を複製します。
host3ホストに定義されている同じ属性およびそれに関連付けられているインストールとデータ・インスタンスに基づいて、データ・インスタンスを5つ作成します。また、3つのホストをデータ領域グループ1ではなくデータ領域グループ2に関連付けます。新しいホストの完全修飾ドメイン名を識別できることを確認します。
% ttGridAdmin hostCreate -internalAddress int-host4 -externalAddress ext-host4.example.com -like host3 -cascade -dataSpaceGroup 2 Host host4 created in Model Installation installation1 created in Model Instance instance1 created in Model % ttGridAdmin hostCreate -internalAddress int-host5 -externalAddress ext-host5.example.com -like host3 -cascade Host host5 created in Model Installation installation1 created in Model Instance instance1 created in Model % ttGridAdmin hostCreate -internalAddress int-host6 -externalAddress ext-host6.example.com -like host4 -cascade Host host6 created in Model Installation installation1 created in Model Instance instance1 created in Model % ttGridAdmin hostCreate -internalAddress int-host7 -externalAddress ext-host7.example.com -like host3 -cascade Host host7 created in Model Installation installation1 created in Model Instance instance1 created in Model % ttGridAdmin hostCreate -internalAddress int-host8 -externalAddress ext-host8.example.com -like host4 -cascade Host host8 created in Model Installation installation1 created in Model Instance instance1 created in Model
|
ノート:
|
図4-8に、host3ホストをhost4、host5、host6、host7、host8、およびそれらに関連するインストールとインスタンスとして複製された後のgrid1グリッドのモデルの図を示します。
ttGridAdmin hostCreateコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのホストの作成(hostCreate)を参照してください。
モデルの最新バージョンでは、現在の構造ではなく、グリッドに必要な構造が記述されます。最新バージョンのモデルに加えた変更は、グリッドの操作構成にすぐには反映されません。最新バージョンのモデルに加えた変更は、グリッドに明示的に適用する必要があります。
管理インスタンスは、モデルの複数のバージョンを格納します。グリッドでは、常に1つのバージョンのみをアクティブにできます。
TimesTen Scaleoutでは、次のようにモデル・バージョンを分類します。
現在のバージョン: モデルの現在のバージョンは、グリッドの操作構成を記述しています。このバージョン以前のすべてのバージョンは、読取り専用です。
最新バージョン: モデルの最新バージョンは変更可能であり、グリッドに適用する必要があります。このバージョンは読取り/書込み可能です。
グリッドを作成すると、version 1モデルが最初のホスト、インストールおよび管理インスタンスの構成とともに最初に移入され、version 1モデルはモデルの最新バージョンとして認識されます。その後のモデルに対する変更は、最新バージョンのモデル(version 1)に追加されます。ttGridAmin modelApplyコマンドを使用して変更を実装すると、今後の変更用に新しい最新バージョンのモデル(version 2)が作成され、以前の最新バージョンのモデル(version 1)が現在のバージョンのモデルになります。
ttGridAdmin modelApplyコマンドを実行するたびに、TimesTen Scaleoutによって次が行われます。
最新バージョンのモデル(version n)が読取り専用になります。
最新バージョンのモデルの書込み可能なコピー(version n+1)が作成されます。
以前にversion nモデルに加えた変更の操作グリッドへの適用が試行されます。
version nモデルが現在のバージョンのモデルとして識別されます。
version n+1モデルが最新バージョンのモデルとして識別されます。
ttGridAdminユーティリティを使用すると、ユーザーは次のようなモデルに関するいくつかの操作を実行できます。
最新バージョンのモデルに加えた変更の適用
モデルの2つのバージョンの比較
モデルのバージョンのJSON形式のフラット・ファイルへのエクスポート
JSON形式のフラット・ファイルの最新バージョンのモデルとしてのインポート
モデルの使用可能なすべてのバージョンのリスト
前のバージョンのモデルは自動的に保存されます。ttGridAdmin gridModifyコマンドを使用すると、日数または保存されるバージョン数、あるいはその両方で古いバージョンのモデルの保存期間を指定できます。デフォルトでは、TimesTen Scaleoutは最新の10個のバージョンを30日間保持します。
モデル操作またはttGridAdmin gridModifyユーティリティの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのモデル操作またはグリッド設定の変更(gridModify)をそれぞれ参照してください。
ttGridAdmin modelApplyコマンドは、最新バージョンのモデルに加えた変更の操作グリッドへの適用を試行します。たとえば、最新バージョンのモデルに新規データ・インスタンスを追加した場合、このコマンドを実行すると、必要なすべての操作が実行され、指定したホストのインスタンスが作成および初期化されます。ttGridAdmin modelApplyコマンドでは、次のような操作が実行されます。
最新バージョンのモデルから削除されたすべてのオブジェクトを特定して削除します。
新規インストールを作成します。
新規インスタンス、データおよび管理を作成します。
すべてのインスタンスの構成ファイルを上書きします。これらのファイルの新しいバージョンには、最新バージョンのモデルで検出された新規エントリが含まれています。
ホスト間のSSH接続を確認します。
|
ノート: 新しいインスタンスをモデルに最近追加したか、インスタンスを管理するホストに必要なパスワードなしSSHアクセスを設定していない場合は、モデルの最新バージョンを適用する前に、インスタンス管理者に必要なパスワードなしSSHアクセスを手動で設定するか、ttGridAdmin gridSshConfigコマンドを使用してください。詳細は、パスワードなしSSHの設定を参照してください。 |
新しいインスタンスを起動します。
grid1グリッドの最新バージョンのモデルに加えたすべての変更を適用します。
% ttGridAdmin modelApply Creating new model version............................................OK Exporting current model (version 1)...................................OK Identifying any changed management instances..........................OK Identifying any deleted objects.......................................OK Verifying installations...............................................OK Verifying instances...................................................OK Creating new instances................................................OK Updating grid state...................................................OK Configuring instance authentication...................................OK Pushing new configuration files to each instance......................OK Making model version 1 current, version 2 writable....................OK Checking ssh connectivity of new instances............................OK Starting new management instance......................................OK Configuring standby management instance...............................OK Starting new data instances...........................................OK ttGridAdmin modelApply complete
前の各項で実行したすべてのタスクの後、ttGridAdmin modelApplyコマンドは、次の操作を実行します。
すべての構成されたホストでインストール・ファイルのコピーを作成します。
関連ホストでスタンバイ管理インスタンスおよびデータ・インスタンスのインスタンス・ホーム・ディレクトリおよびファイルを作成します。
最新バージョンのモデルを読取り専用にし、新しい書込み可能モデルを作成します。
構成されたすべてのホストへのSSH接続を検証します。
スタンバイ管理インスタンスおよびデータ・インスタンスのデーモンを起動します。
アクティブな管理インスタンスおよびスタンバイ管理インスタンスを構成します。
ttGridAdmin modelApplyコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスの最新バージョンのモデルの適用(modelApply)を参照してください。
オプションで、システムが起動または停止するたびに、自動的に起動またはシャットダウンするデータ・インスタンスを構成できます。各インスタンスは、その作成が現在のバージョンのモデルに適用された後にのみ、個別に構成する必要があります。
これを行うには、rootユーザーが-installオプションとともにsetuprootスクリプトを実行する必要があります。このスクリプトは、グリッドのすべてのインスタンスのtimesten_home/binディレクトリにあります。次に例を示します。
host3.instance1データ・インスタンスのホストからの場合:
% /grid/instance1/bin/setuproot -install Would you like to install the TimesTen daemon startup scripts into /etc/init.d? [ yes ]
setuprootスクリプトの使用方法の詳細は、Oracle TimesTen In-Memory Databaseインストレーション、移行およびアップグレード・ガイドのシステム起動時のインスタンスの自動起動を参照してください。
データ領域グループへのホストの割当てで説明されているように、TimesTen Scaleoutでは、データ・インスタンスを含むホストをデータ領域グループに割り当てる必要があります。
|
ノート: データベースのそれぞれの完全コピーをハードウェア障害から保護するために、1つのデータ領域グループのホストで、別のデータ領域グループのホストと物理リソースを共有しないようにしてください。 |
データ・インスタンスの追加に記載されている例では、ttGridAdmin hostCreate -dataSpaceGroupオプションを指定して、ホストの作成中にデータ領域グループにホストを割り当てる方法を示しています。
% ttGridAdmin hostCreate -internalAddress int-host3 -externalAddress ext-host3.example.com -dataSpaceGroup 1 Host host3 created in Model
ただし、物理トポグラフィが複雑になり、データ領域グループへのホストの最適な割当てを決定することが困難である場合は、ttGridAdmin dataSpaceGroupSuggestコマンドを使用して、データ領域グループへのホストの推奨割当てをTimesTen Scaleoutから取得できます。これを実行するには、複数のホストが配置されている場所または同じリソースを使用するホストをTimesTen Scaleoutに通知する必要があります。物理グループとともに各ホストのすべての物理ハードウェアをTimesTen Scaleoutに通知できます。
|
重要: 物理グループを使用して、TimesTen Scaleoutによる割当ての推奨を受け取るには、ホストの作成時にデータ領域グループにホストを割り当てないでください。ホストは、データ領域グループに1回のみ割り当てることができます。 |
物理トポロジには、建物、トランスフォーマ、空調装置、ラック、ファン、ラックの上部のスイッチ、ハイパーバイザ、ストレージ・ファイラ、電源などがあります。たとえば、次の本番環境には次のものが含まれます。
独自のトランスフォーマを持つ2棟の建物。
2棟の建物内の各部屋に5台の空調装置。
各部屋に9個のサーバーのラック。それぞれに複数のホストがあります。
ホストが接続されている18個の電源サージ・プロテクタ。

これらのリソースを共有するホストの最適なデータ領域グループ割当てを決定するかわりに、ホストを物理グループに割り当てて、ホストが配置されている場所と共有している物理リソースを識別できます。これにより、類似した障害の可能性がTimesTen Scaleoutに通知されます。したがって、TimesTen ScaleoutがttGridAdmin dataSpaceGroupSuggestコマンドを使用してデータ領域グループへのホストの割当てを推奨する場合は、個別のデータのコピーを含むホストが物理的に分離されます。
|
ノート: データ領域グループの詳細は、データ領域グループへのホストの割当てを参照してください。ttGridAdmin dataSpaceGroupSuggestコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータ領域グループの割当ての推奨の取得(dataSpaceGroupSuggest)を参照してください。 |
次のようにして、物理トポグラフィを作成および管理します。
ホストを物理グループに割り当てて物理トポロジを示すことはオプションであり、TimesTen Scaleoutによってホストをデータ領域グループに割り当てる場合にのみ必要となります。
この項の例では、この章で使用される例と同じホスト構成を使用して、物理グループにホストを割り当てます。どのホストをどのデータ領域グループに割り当てるかを簡単に特定できるため、本番では、この小規模な例の物理グループは使用しません。
次のように想定します。
ホスト3、4および5は、空調装置を共有します。
ホスト3、4および5は、同じラックに配置されます。
ホスト3および4は、電源を共有します。
ホスト5には専用の電源があります。
ホスト6、7および8は、空調装置を共有します。
ホスト6、7および8は、同じラックに配置されます。
ホスト6および7は、電源を共有します。
ホスト8には専用の電源があります。
どの物理リソースにどのホストが接続されているかを識別するには、次の手順を実行します。
物理グループを定義します。物理グループは、共有物理リソースであることを示すためにホストをグループ化するコンテナ・オブジェクトです。これにより、TimesTen Scaleoutは、物理的な側面を共有しないホストとデータの別のコピーを分離します。
ttGridAdmin hostCreateコマンドを使用してホストを作成する際、またはttGridAdmin hostModifyコマンドを使用してホストを変更する際に、ホストを物理グループに割り当てます。
必要に応じてホストを1つ以上の物理グループに割り当てることができます。類似したラックに割り当てられ、電源を共有している場合は、これらの物理グループの両方にホストを割り当てることができます。
これらのttGridAdminコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのホストの作成(hostCreate)およびホストの変更(hostModify)を参照してください。
例4-1 2つの別個のラックに物理的に配置されているホストの例
この例では、物理グループを作成して、共有リソースをモデル化し、物理グループにホストを割り当てる方法を示しています。
物理グループを定義します。ttGridAdmin physicalCreateコマンドを使用して、次を作成します。
rack1とrack2。ラボの物理ラックをモデル化します。
aircond1とaircond2。空調装置をモデル化します。
power1、power2、power3およびpower4。電源サージ・プロテクタをモデル化します。
ホストを物理グループに割り当てます。ttGridAdmin hostModifyで-physicalgroupオプションを使用して、各共有物理リソースにホストを割り当てます。
host3、host4およびhost5はrack1にあります。
host3、host4およびhost5はaircond1を共有します。
host3とhost4はpower1を共有します。
host5には、独自のpower2があります。
host6、host7およびhost8はrack2にあります。
host6、host7およびhost8はaircond2を共有します。
host6とhost7はpower3を共有します。
host8には、独自のpower4があります。
|
ノート: ttGridAdmin hostModifyコマンドの-physicalgroupオプションを実行する前にホストがすでに物理グループに関連付けられている場合、それらの物理グループが削除され、ホストに関連付けられている物理グループのみが現在のコマンド行で指定されます。
ただし、 |
% ttGridAdmin physicalCreate rack1 PhysicalGroup rack1 created. % ttGridAdmin physicalCreate rack2 PhysicalGroup rack2 created. % ttGridAdmin physicalCreate aircond1 PhysicalGroup aircond1 created. % ttGridAdmin physicalCreate aircond2 PhysicalGroup aircond2 created. % ttGridAdmin physicalCreate power1 PhysicalGroup power1 created. % ttGridAdmin physicalCreate power2 PhysicalGroup power2 created. % ttGridAdmin physicalCreate power3 PhysicalGroup power3 created. % ttGridAdmin physicalCreate power4 PhysicalGroup power4 created. % ttGridAdmin hostModify host3 -physicalgroup rack1 aircond1 power1 Host host3 modified in Model % ttGridAdmin hostModify host4 -physicalgroup rack1 aircond1 power1 Host host4 modified in Model % ttGridAdmin hostModify host5 -physicalgroup rack1 aircond1 power2 Host host5 modified in Model % ttGridAdmin hostModify host6 -physicalgroup rack2 aircond2 power3 Host host6 modified in Model % ttGridAdmin hostModify host7 -physicalgroup rack2 aircond2 power3 Host host7 modified in Model % ttGridAdmin hostModify host8 -physicalgroup rack2 aircond2 power4 Host host8 modified in Model
|
ノート: ttGridAdmin modelExportコマンドを使用すると、物理グループに割り当てられているホストが表示されます。 |
ホストの物理的な編成方法の物理的な記述を削除する場合は、ttGridAdmin hostModifyコマンドで-nophysicalgroupオプションを使用します。host3ホストは当初物理グループrack1、aircond1およびpower1に関連付けられていました。次のコマンドを実行すると、host3は物理グループに割り当てられません。
% ttGridAdmin hostModify host3 -nophysicalgroup Host host3 modified in Model
ホストが割り当てられていない場合にのみ、物理グループを削除できます。次では、割り当てられているhost1およびhost2ホストを削除した後に、rack1物理グループを削除します。
% ttGridAdmin hostModify host3 -nophysicalgroup Host host3 modified in Model % ttGridAdmin hostModify host4 -nophysicalgroup Host host4 modified in Model % ttGridAdmin hostModify host5 -nophysicalgroup Host host5 modified in Model % ttGridAdmin physicalDelete rack1 PhysicalGroup rack1 deleted.
ttGridAdmin dataSpaceGroupSuggestコマンドを使用して、ホストの現在の物理グループへの割当てに基づいて、別のデータ領域グループへのホストの割当てを提示できます。提示された割当てを受け入れることも、独自の割当てを指定することもできます。
ttGridAdmin dataSpaceGroupSuggestコマンドは、データのコピーが1つ含まれるホストがそのデータのコピーを含むホストとリソースを共有しないようにホストを割り当てる推奨方法を示します。ttGridAdminコマンドがホストをデータ領域グループに割り当てた後に、その割当てを変更することはできません。
ttGridAdmin dataSpaceGroupSuggestコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータ領域グループの割当ての推奨の取得(dataSpaceGroupSuggest)を参照してください。
例4-2 TimesTen Scaleoutによるホストのデータ領域への割当ての要求
この例では、推奨事項をrecommendations.shファイルに書き込むttGridAdmin dataSpaceGroupSuggestコマンドを示しています。このファイルには推奨されるデータ領域グループにホストを割り当てるために必要となるttGridAdmin hostModifyコマンドが含まれているため、実行できます。
% ttGridAdmin dataSpaceGroupSuggest /tmp/recommendations.sh % more /tmp/recommendations.sh #!/bin/sh # Recommendations generated by ttGridAdmin -dataSpaceGroupSuggest TIMESTEN_HOME=/grid/instance1 export TIMESTEN_HOME . $TIMESTEN_HOME/bin/ttenv.sh > /dev/null 2>/dev/null # Number of possibilities evaluated: 126 # # Number of usable possibilities found: 10 # (A 'usable' possibility is one that is compatible with pre-existing # assignments of Hosts to DataSpaceGroups) # # Number of 'ideal' possibilities found: 1 # (An 'ideal' possibility is one where no PhysicalGroups span multiple # DataSpaceGroups) # # Possibilities evaluated (best 10 displayed): # ... # # This script, if executed, would implement the only 'ideal' configuration found. # Even though this recommendation was 'ideal', you should carefully evaluate it # prior to running this script. # Host host1 is already in DataSpaceGroup 1 ttGridAdmin hostModify host3 -dataSpaceGroup 2 ttGridAdmin hostModify host4 -dataSpaceGroup 2 ttGridAdmin hostModify host5 -dataSpaceGroup 2 ttGridAdmin hostModify host6 -dataSpaceGroup 1 ttGridAdmin hostModify host7 -dataSpaceGroup 1 ttGridAdmin hostModify host8 -dataSpaceGroup 1
これらの推奨事項を受け入れる場合は、指定されたシェル・スクリプト(例ではrecommendations.sh)を実行します。実行後に、すべてのホストが指定されているデータ領域グループに割り当てられます。
% sh /tmp/recommendations.sh Host host3 modified in Model Host host4 modified in Model Host host5 modified in Model Host host6 modified in Model Host host7 modified in Model Host host8 modified in Model