TimesTen Scaleoutのアーキテクチャ

1人のOSユーザーがグリッドを作成および管理します。このユーザーはインスタンス管理者と呼ばれます。『Oracle TimesTen In-Memory Databaseインストレーション、移行およびアップグレード・ガイド』インスタンス管理者を参照してください。TimesTen Scaleoutでは、インスタンス管理者は次のことができます。
  • K-safetyの使用によってグリッドでデータのコピーを1つ以上作成するかどうかを構成します。

  • グリッドの管理に使用する1つまたは2つの管理インスタンスを作成します。

  • データを格納および管理する複数のデータ・インスタンスを作成します。

  • 任意の時点で操作可能なデータ・インスタンスを追跡するメンバーシップ・サービスを設定します。メンバーシップ・サービスは3つ以上のメンバーシップ・サーバーで構成されます。

  • 1つ以上のデータベースを作成します。

  • データベースのバックアップを格納する1つ以上のリポジトリを作成します。

データベースは複数の要素で構成され、各要素にそのデータベースのデータの一部が格納されます。各データ・インスタンスに各データベースの1つの要素が含まれます。グリッドに複数のデータベースを作成した場合、各データ・インスタンスに複数の要素(各データベースから1つ)が含まれます。

作成するデータベースごとに、データ分散に含める要素を決定します。通常、すべての要素を含めますが、新規データ・インスタンスをオンラインにした場合、これらの新規データ・インスタンスの要素をいつからデータベース操作に含めるかを決定します。データベース操作に要素を含めるには、データベースの分散マップに要素を明示的に追加する必要があります。同様に、グリッドからデータ・インスタンスを削除するには、分散マップから要素を削除する必要があります(これにより、要素はデータベース操作に含まれなくなります)。

要素を分散マップに含めると、データベースの各要素は自動的にレプリカ・セットに配置されます。各レプリカ・セットには、K-safetyに設定された値と同じ数の要素が含まれます。同じレプリカ・セット内の要素は、同じデータを保持します。

次の各トピックでは、これらのコンポーネントとグリッド内でのその役割について詳しく説明します。

インスタンス

グリッドでは、インスタンスを使用してデータの1つ以上のコピーを管理、追加および分散します。インスタンスは、TimesTenソフトウェアの実行中のコピーです。ホストにインスタンスを作成する場合は、TimesTenインストールに関連付けます。インストールは、単一のインスタンスで使用するか、複数のインスタンスで共有できます。各インスタンスは、通常、最大のデータ可用性を提供するため、および1つのホストに障害が発生した場合のデータ損失に対する予防手段として、それ固有のホストに存在します。

各インスタンスには、関連付けられているインスタンス管理者(インスタンスの作成者)およびインスタンス・ホームがあります。インスタンス・ホームは、ホスト上の場所です。同じインスタンス管理者が、グリッド内のすべてのインスタンスを管理します。

TimesTen Scaleoutは、次の2タイプのインスタンスをサポートしています。

管理インスタンス

管理インスタンスはグリッドを制御し、グリッドの中央構成であるモデルを維持します。管理者がグリッドを簡単に管理できるように、すべての管理アクティビティは、ttGridAdminユーティリティを使用して、単一の管理インスタンスを介して実行するようになっています。

ノート:

モデルの詳細は、「グリッドの中央構成」を参照してください。

TimesTen Scaleoutでは2つの管理インスタンスを作成できるため、高可用性を実現し、単一の管理インスタンスの障害によってグリッド管理が妨げられることを回避できます。本番環境のベスト・プラクティスとして、2つの管理インスタンスを作成することを検討してください。作成後、TimesTen Scaleoutは両方の管理インスタンスをアクティブ・スタンバイ構成で構成します。すべての管理操作は、必ずアクティブ管理インスタンスを使用して実行します。スタンバイ管理インスタンスは、アクティブ管理インスタンスの障害に対する保護対策としてのみ存在します。

図1-3に示すように2つの管理インスタンスを作成する場合、アクティブ管理インスタンスで使用されるすべての情報はスタンバイ管理インスタンスに自動的にレプリケートされます。つまり、アクティブ管理インスタンスに障害が発生した場合は、スタンバイ管理インスタンスを新しいアクティブ管理インスタンスに昇格させ、これを使用してグリッドの管理を続行できます。

ノート:

TimesTen Scaleoutで管理インスタンスの情報がどのようにレプリケートされるかの詳細は、「管理インスタンスのフェイルオーバーの管理」を参照してください。

図1-3 管理者がグリッドの管理に使用する管理インスタンス

図1-3の説明が続きます
「図1-3 管理者がグリッドの管理に使用する管理インスタンス」の説明

次のことを考慮してください。

  • スタンバイ管理インスタンスなしで単一の管理インスタンスからグリッドを管理できます。ただし、これは本番環境ではお薦めしません。

  • 両方の管理インスタンスに障害が発生した場合、グリッド内のデータベースは動作を継続します。少なくとも1つの管理インスタンスを再起動するまで、一部の管理操作は行えません。

データ・インスタンス

データ・インスタンスはグリッド内のデータベースごとに1つの要素を格納します。データ・インスタンスは、SQL文およびPL/SQLブロックを実行します。グリッドは各データベース内のデータをデータ・インスタンス間で分散します。図1-4に示すように、すべてのデータ・インスタンスはアクティブ管理インスタンスで管理します。

図1-4 複数のデータ・インスタンスのグリッドを管理する管理インスタンス

図1-4の説明が続きます
「図1-4 複数のデータ・インスタンスのグリッドを管理する管理インスタンス」の説明

インストール

インスタンスを操作するには、TimesTenディストリビューションのインストールが必要です。インストールは読取り専用であり、ローカルで使用することも、複数のインスタンスで共有することもできます。管理インスタンスのホストとして定義されているシステム上の指定した場所にTimesTenディストリビューションを抽出することによって、初期管理インスタンスのインストールを作成します。TimesTen Scaleoutは、グリッド内の他のホストで後続のインストールをローカルに作成し、それらのホストで実行されるインスタンスに新規インストールを関連付けることができます。同じホスト上で実行されるすべてのインスタンスは同じインストールを共有できます。

インストールに複数のホストがアクセスできるかぎり、そのインストールはそれらのホストのインスタンスで共有できます。ただし、NFSなどの共有ファイル・サーバーのインストールを個別のホスト上の複数のインスタンス間で共有する場合、可用性が低下する可能性があります。共有ネットワーク・ストレージまたはすべてのホストをNFSサーバーに接続するネットワークに障害が発生したり、パフォーマンスの問題が発生した場合、そのインストールを共有するすべてのインスタンスが影響を受けます。そのため、共有ファイル・サーバーのインストールをインスタンス間で共有することは開発環境の有効なオプションですが、本番環境に適切かどうかを評価してください。

K-Safety

グリッド内の各データベースのデータのコピーを1つまたは複数作成するようにグリッドを構成します。TimesTen ScaleoutはK-safety (k)の実装を使用して、データの1つまたは複数のコピーを管理します。データのコピー数は、グリッドの作成時にkに設定した値で指定されます。

グリッドでデータのコピーを2つ以上作成し別々のホストに配置することを指定した場合、データの可用性とフォルト・トレランスが向上します。

  • k1に設定した場合、TimesTen Scaleoutはデータの単一のコピーを保存します(本番環境にはお薦めしません)。

    k1に設定した場合は、1つ以上の要素が失敗した場合に次のことが発生する可能性があります。

    • 要素に含まれるすべてのデータは、要素がリカバリするまで使用できません。

    • 要素がリカバリされない場合、要素に含まれているデータは失われます。

    データのコピーが1つのみの場合にも、容量およびデータのアクセシビリティを向上させるためにデータは別の要素に分散されます。

  • k2(以上)に設定した場合、TimesTen Scaleoutはデータのコピーをk個保存します。データのコピーが複数ある場合、グリッドは複数の障害を許容できます。

    ある要素で障害が発生した場合は、そのデータの別のコピーにアクセスして、リクエストされたデータを提供します。K-safetyにより、データのコピーのいずれかが使用可能であれば、データの可用性が実現します。可能な場合は、最大のデータの安全を確保するため、データの各コピーを異なる物理ハードウェアに配置します。

次の各トピックでは、複数のコピーを管理および編成する方法について説明します。

レプリカ・セットの理解

データベースの各要素は、kの値に応じてレプリカ・セットに自動的に配置されます。

  • k1に設定した場合、各レプリカ・セットには1つの要素が含まれます。

  • k2(以上)に設定した場合、各レプリカ・セットにはk個の要素が含まれます(ここで、各要素はそのレプリカ・セット内の他の要素の正確なコピーです)。

このため、各レプリカ・セットにはkに設定された値と同じ数の要素が含まれます。

k2(以上)に設定した場合、レプリカ・セット内のすべての要素で常にデータの一貫性を保つために、1つの要素内のデータに加えられた変更は、レプリカ・セット内の他の要素にも加えられます。TimesTen Scaleoutの透過性機能により、リクエストされたデータがその要素に含まれていない場合や、リクエストされたデータが複数のレプリカ・セットにまたがる場合でも、任意の要素でトランザクションを開始できます。要素に障害が発生した場合は、レプリカ・セット内の他のいずれかの要素にアクセスして、リクエストされたデータを提供します。各レプリカ・セット内の1つの要素が機能しているかぎり、データベース内のすべてのデータを使用できます。

データ領域の理解

各データベースは要素のセットで構成され、各要素にそのデータベースのデータの一部が格納されます。グリッドは各データベースの要素をデータ領域に編成します。

各データベースは、1つまたは2つのデータ領域で構成されます。k2(以上)に設定した場合、各レプリカ・セット内の要素は別々のデータ領域に割り当てられます。

図1-5に、データの3つのコピーがどのように3つのデータ領域内で編成されるかを示します。ここで、各データ領域には、データベースのデータの1つのコピーを構成する要素が含まれています。2つのレプリカ・セットがあり、各レプリカ・セットの要素は別のデータ領域に割り当てられています。このため、データ領域1にある各要素は、データ領域2および3にあるそのレプリカと同じになります。

図1-5 それぞれ固有のデータ領域にある3つのコピー

図1-5の説明が続きます
「図1-5 それぞれ固有のデータ領域にある3つのコピー」の説明

ニーズが拡大または減少するにつれて、レプリカ・セットをグリッドに追加または削除できます。データ・インスタンスを追加すると、グリッドに各データベースの要素が自動的に作成されます。ただし、データ・インスタンスを追加または削除した場合、データは自動的に再分散されません。レプリカ・セットに要素を割り当て、各データ領域のすべての要素にデータを再分散する適切なタイミングを決定します。

データ領域グループへのホストの割当て

グリッドの物理組織を表すデータ領域グループにホストを割り当てることによって、データを物理的に配置する方法を決定します。「データ領域の理解」で説明したように、データのコピーはデータ領域に論理的に編成されます。各データ領域は個別の物理リソースを使用する必要があります。共有物理リソースには、類似のラック、同じ電源または同じ記憶域を含めることができます。1つのレプリカ・セット内のすべての要素が物理コンポーネントを共有するホストに格納されている場合、その共有物理コンポーネントに障害が発生した場合、そのレプリカ・セットに格納されているデータは使用できなくなることに注意してください。

TimesTen Scaleoutでは、データ・インスタンスを実行するすべてのホストをデータ領域グループに割り当てる必要があります。K-safetyを使用する場合、データのk個のコピーおよび(1からkの番号が付けられた)同じ数のデータ領域グループが存在します。同じ物理リソースを共有するホストは同じデータ領域グループに割り当てる必要があります。同じデータ領域グループに割り当てられたホスト上で実行されるデータ・インスタンスの要素は、同じデータ領域にあります。各データ領域には、データベース内のすべてのデータの完全コピーが含まれています。

1つのデータ領域グループ内のホストが別のデータ領域グループ内のホストとリソースを物理的に共有しないようにする場合、別のデータ領域グループ内のホストに同時に障害が発生する可能性が低くなります。このシナリオでは、単一のハードウェア障害によって複数のホストが停止した場合にも、データベース内のすべてのデータが使用可能である可能性が高くなります。たとえば、1つのデータ領域グループ内のすべてのホストを、別のデータ領域グループ内のホストの電源と別の電源に接続するようにできます。その場合は、1つのプラグを抜いても、1つのレプリカ・セット内のすべてのホストの電源が切断されてデータを使用できなくなることはありません。

図1-6に、k3に設定して構成され、3つのデータ領域グループが含まれるグリッドを示します。3つのラックがあり、それぞれに、独立した電源と2つのホストが備わっています。2つのホストは各データ領域グループに割り当てられています。TimesTen Scaleoutは、各レプリカ・セット内の1つの要素が各データ領域グループに含まれるようなレプリカ・セットを作成します。

図1-6 データ領域グループに編成されたホスト

図1-6の説明が続きます
「図1-6 データ領域グループに編成されたホスト」の説明

ホストをデータ領域グループに割り当てるプロセスには、データ領域をサポートするホストを物理的に分離する方法の決定が含まれます。

データ分散

グリッド内に1つ以上のデータベースを作成できます。各データベースは独立し、個別のユーザー、スキーマ、表、永続性およびデータ分散を保有します。TimesTen Scaleoutは、定義された分散マップおよび各表の分散スキームに従ってデータの分散を管理します。

データベースの分散マップの定義

任意のデータベースの要素とレプリカ・セットの最大数を指定する、グリッドのデータ・インスタンスの数を決定します。各データ・インスタンスは、グリッド内の各データベースの1つの要素をホストします。そのため、グリッド内のデータ・インスタンスは1つ以上のデータベースを同時に管理できます。グリッドに複数のデータベースを作成した場合、各データ・インスタンスに複数の要素(各データベースから1つの要素)が含まれます。

各データベースは複数のレプリカのセットで構成され、各レプリカ・セットにそのデータベースのデータの一部が格納されます。使用可能なデータ・インスタンスのどの要素にデータベースのデータを格納するかを分散マップで定義します。分散マップが定義され適用された後、TimesTen Scaleoutが各要素をレプリカ・セットに自動的に割り当て、データを対応するレプリカ・セットに分散すると、各要素は別のレプリカ・セットの他の要素と通信し、単一のデータベース・イメージを提供します。データが分散される方法の詳細は、表の分散スキームに基づいてデータベースの表ごとに異なる場合があります。

ノート:

TimesTen Scaleoutでは、ttGridAdminユーティリティによって管理されるパーティション表に、分散マップの構成、またはすべてのデータ・インスタンスがどのように相互に関連付けられているかが格納されます。

各データベースのデータを管理および格納するデータ・インスタンスの要素を分散マップに追加した後、データを結果のレプリカ・セットに分散することを明示的に要求できます。

ビジネスのニーズが変化するにつれて、グリッド内のレプリカ・セットの数を増やすことでデータベースの容量を増やすことができます。これを実現するには、次の手順を実行します。

  1. グリッドに新しいホストを追加します。追加するホストの数は、追加するレプリカ・セットの数およびK-safetyの値に比例する必要があります。たとえば、k3に設定してあり、グリッド内のデータベースに別のレプリカ・セットを追加する場合は、使用可能な3つのデータ領域グループのそれぞれにホストを1つ追加する必要があります。

  2. 各新規ホストにデータ・インスタンスをサポートするインストールを作成します。

  3. 各新規ホストにデータ・インスタンスを作成します。

  4. 容量を増加する各データベースの分散マップに新規データ・インスタンスの要素を追加します。TimesTen Scaleoutにより、適切な新規レプリカ・セットが自動的に作成されます。

  5. すべてのレプリカ・セットにデータを再分散します。

    グリッドに新規データ・インスタンスを追加したり、既存のデータ・インスタンスを削除した場合、グリッドはデータベースに格納されているデータをそれらの新規または残りのデータ・インスタンスのレプリカ・セットに自動的に再分散しません。かわりに、既存のデータ・インスタンスにデータを再分散する適切なタイミングをユーザーが決定します。再分散は、稼働中のデータベースに悪影響を与えることがあります。影響を最小限に抑えるために、小さい増分で再分散する必要があります。ユーザーが保有するデータ・インスタンスの数が多いほど、1つのレプリカ・セットを漸増的に追加または削除する影響は小さくなります。

データ・インスタンスを同じデータ領域グループ内の新規データ・インスタンスに置換する必要がある場合は、この処理ですべてのデータを再分散する必要はありません。

容量を減らすには、レプリカ・セットを管理するデータインスタンスを分散マップから削除し、グリッド内の残りのデータのインスタンスにデータを再分散します。

表の分散スキームの定義

TimesTen Scaleoutはレプリカ・セットにデータベース内のデータを分散します。データベース内のすべての表は各レプリカ・セットに存在します。データベース内の各表の分散スキームはCREATE TABLE文で定義します。分散スキームでは、表の行をグリッド間で分散する方法を説明します。

データを分散する方法は、表の作成時に指定する次のいずれかの分散スキームで定義します。

  • ハッシュ: データは、主キーのハッシュ、またはユーザーが指定した複数の列の複合に基づいて分散されます。指定された行がグリッドによって選択されたレプリカ・セットに含まれます。行はレプリカ・セット間で均一に分散されます。これは、大部分の表に適しているため、デフォルトの方法です。

    図1-7に、ハッシュ分散スキームを使用した表terry.customersの例を示します。各要素は異なるレプリカ・セットに属します。

    図1-7 ハッシュ分散を使用した表

    図1-7の説明が続きます
    「図1-7 ハッシュ分散を使用した表」の説明
  • 参照: 外部キーによって識別された親表の場所に基づいて子表のデータを分散します。つまり、子表の指定した行が親表と同じレプリカ・セットに存在します。この分散スキームは、1つのレプリカ・セット内の関連データを分散することで、結合のパフォーマンスを最適化します。多くの場合、親表と子表は問合せで同時に参照されるため、この分散スキームは1つの親表の論理的な子である表に適しています。

    図1-8に、親表customersへの参照分散スキームを使用した子表accountsの例を示します。各要素は異なるレプリカ・セットに属します。

    図1-8 参照分散を使用した表

    図1-8の説明が続きます
    「図1-8 参照分散を使用した表」の説明
  • 複製: データの完全な同一コピーをデータベースのすべての要素に分散します。つまり、すべての行は各要素に存在します。この分散スキームは、各データ・インスタンスに同一データを格納することで、読取りのパフォーマンスを最適化します。この分散スキームは、比較的小さい、頻繁に読み取られる、変更頻度の低い表に適しています。

    図1-9に、複製分散スキームを使用した表account_typeの例を示します。各要素は異なるレプリカ・セットに属します。

    図1-9 複製分散を使用した表

    図1-9の説明が続きます
    「図1-9 複製分散を使用した表」の説明

バックアップ

TimesTen Scaleoutでは、グリッドにデータベースのバックアップを作成して、同じグリッドまたは類似したトポロジを持つ別のグリッドにリストアできます。TimesTen Scaleoutでは、異なるトポロジを持つグリッドにデータベースをエクスポートすることもできます。リポジトリをデータベースのバックアップ、エクスポートおよびログ・ファイルのコレクションの場所として定義します。複数のグリッドで同じリポジトリを使用できます。

内部および外部ネットワーク

ほとんどの本番環境で、TimesTen Scaleoutには1つのプライベート内部ネットワークと1つ以上の外部ネットワークが必要です。

  • 内部ネットワーク: グリッド内のインスタンスは、TCPプロトコルを使用して単一の内部ネットワーク経由で相互に通信します。さらに、インスタンスはこのネットワークを介してメンバーシップ・サーバーと通信します。メンバーシップ・サーバー間は、このネットワークを使用して通信します。

  • 外部ネットワーク: アプリケーションは外部ネットワークを使用してデータ・インスタンスに接続してデータベースにアクセスします。アプリケーションには、管理インスタンスまたはメンバーシップ・サーバーへの外部ネットワーク・アクセスは必要ありません。

「ネットワーク要件」を参照してください。