プラネット、リージョン、Pod、組織、環境、仮想ホストについて

Edge for Private Cloud v. 4.17.01

Edge Private Cloud のオンプレミス環境、すなわち Edge インスタンスは、一連のサーバーノードにインストールされた Edge コンポーネントから構成されます。次の図に、Edge インスタンスを構成するプラネット、リージョン、ポッド、組織、環境、仮想ホストの関係を示します。

次の表に、これらの関係を示します。

	以下を含む	関連付け	デフォルト
プラネット	1 つ以上のリージョン		なし
リージョン	1 つ以上の Pod		「dc-1」
ポッド	1 つ以上の Edge コンポーネント		"central" "gateway" "analytics"
組織	1 つ以上の環境	Message Processor を含む 1 つ以上の Pod と、組織管理者として機能するユーザー	なし
環境	1 つ以上の仮想ホスト	親組織に関連付けられたポッドに含まれる 1 つ以上の Message Processor	なし
仮想ホスト	1 つ以上のホスト エイリアス		なし

惑星について

「惑星」は Edge のハードウェアとソフトウェア環境全体を表し、 1 つ以上のリージョンにとどめますEdge では、惑星とはリージョンの論理グループです。 Edge をインストールする際に、惑星を明示的に作成または構成することもできます。

リージョンについて

「リージョン」は、1 つ以上のポッドのグループです。デフォルトでは、Edge をインストールすると、 「dc-1」という名前の単一のリージョンが作成されます次のテーブルのように、3 つの Pod が含まれます。 表示されます。

リージョン	リージョン内の Pod
"dc-1"	"gateway"、"central"、"analytics"

次の図は、デフォルトのリージョンを表しています。

この図では、ロードバランサがトラフィックを "gateway" ポッドに転送しています。"gateway" ポッドには、API リクエストを処理する Edge Router と Message Processor が存在します。ただし、 複数のデータセンターを定義する場合、追加のリージョンを作成する必要はありません。

複雑な環境では、2 つ以上のリージョンを作成できます。Google Cloud で マシンを地理的に整理することで、ネットワーク移行時間を最小限に抑えられます。イン このシナリオでは、データセンターに地理的に「近い」場所に API エンドポイントをホストします。 コンシューマとして活用できます

Edge では、各リージョンをデータセンターと呼びます。あるデータセンターは、 米国東部はマサチューセッツ州ボストンから到着したリクエストを処理できます。 シンガポールは、アジアのデバイスやコンピュータからのリクエストを処理できます。

たとえば、次の画像は、2 つのデータセンターに対応する 2 つのリージョンを示しています。

Pod について

ポッドとは、1 つ以上の Edge コンポーネントと Cassandra データストアのグループです。各種 Edge コンポーネントは同じノードにインストールすることもできますが、別々のノードにインストールするのが一般的です。Cassandra データストアは、Pod 内の Edge コンポーネントによって使用されるデータ リポジトリです。

デフォルトでは、Edge をインストールすると、インストーラが 3 つの Pod を作成し、 次の Edge コンポーネントと Cassandra データストアを各 Pod にアタッチします。

ポッド	Edge コンポーネント	Cassandra データストア
"gateway"	Router、Message Processor	cache-datastore counter-datastore dc-datastore	keyvaluemap-datastore kms-datastore
"central"	Management Server、Zookeeper、LDAP、UI、Qpid	application-datastore apimodel-datastore audit-datastore auth-datastore	identityzone-datastore edgenotification-datastore management-server scheduler-datastore user-settings-datastore
「分析」	Postgres	analytics-datastore	reportcrud-datastore

"gateway" ポッドの Edge コンポーネントと Cassandra データストアは API の処理に必要です。API リクエストを処理するには、これらのコンポーネントとデータストアが稼働している必要があります。"central" ポッドと "analytics" ポッドのコンポーネントとデータストアは API の処理に必要ではありませんが、Edge に追加機能を提供しています。

次の図は、各 Pod のコンポーネントを示しています。

デフォルトで作成される 3 つのポッド以外に、Message Processor と Router のポッドを作成することもできます。また、既存のポッドに Edge コンポーネントを追加することもできます。たとえば、増加したトラフィックの負荷を処理するために、"gateway" ポッドに Router と Message Processor を追加できます。

"gateway" ポッドには Edge Router と Message Processor が含まれています。Router は、同じポッドの Message Processor にのみメッセージを送信します。別のポッドの Message Processor にメッセージを送信することはありません。

各ポッドのインストールの最後に次の API 呼び出しを使用して、サーバーの登録情報を確認できます。これは便利なモニタリング ツールです。

curl -u adminEmail:pword http://<ms_IP>:8080/v1/servers?pod=podName

ここで、ms_IP は Management Server の IP アドレスまたは DNS 名で、podName は次のいずれかです。

• gateway
• central
• アナリティクス

たとえば "gateway" にはpod:

> curl -u adminEmail:pword http://<ms_IP>:8080/v1/servers?pod=gateway

出力は次のようになります。

[ {
  "externalHostName" : "localhost",
  "externalIP" : "192.168.1.11",
  "internalHostName" : "localhost",
  "internalIP" : "192.168.1.11",
  "isUp" : true,
  "pod" : "gateway",
  "reachable" : true,
  "region" : "dc-1",
  "tags" : {
    "property" : [ {
      "name" : "jmx.rmi.port",
      "value" : "1101"
    }, ... ]
  },
  "type" : [ "message-processor" ],
  "uUID" : "276bc250-7dd0-46a5-a583-fd11eba786f8"
}, 
{
  "internalIP" : "192.168.1.11",
  "isUp" : true,
  "pod" : "gateway",
  "reachable" : true,
  "region" : "dc-1",
  "tags" : {
    "property" : [ ]
  },
  "type" : [ "dc-datastore", "management-server", "cache-datastore", "keyvaluemap-datastore", "counter-datastore", "kms-datastore" ],
  "uUID" : "13cee956-d3a7-4577-8f0f-1694564179e4"
}, 
{
  "externalHostName" : "localhost",
  "externalIP" : "192.168.1.11",
  "internalHostName" : "localhost",
  "internalIP" : "192.168.1.11",
  "isUp" : true,
  "pod" : "gateway",
  "reachable" : true,
  "region" : "dc-1",
  "tags" : {
    "property" : [ {
      "name" : "jmx.rmi.port",
      "value" : "1100"
    }, ... ]
  },
  "type" : [ "router" ],
  "uUID" : "de8a0200-e405-43a3-a5f9-eabafdd990e2"
} ]

type 属性は、コンポーネントのタイプを示します。ここには Cassandra が Pod に登録されているデータストアの数を表します。Cassandra ノードが "gateway" ポッドにインストールされている場合、すべてのポッドで登録されている Cassandra データストアが表示されます。

組織について

組織は、Apigee アカウント内のすべてのオブジェクトのコンテナです。次のものが含まれます。 API、API プロダクト、アプリ、デベロッパー。組織は 1 つ以上のポッドに関連付けられ、各ポッドには 1 つ以上の Message Processor が含まれます。

デフォルトでは、Edge Private Cloud のオンプレミス環境に組織は存在しません。組織を作成する際は、次の 2 つの情報を指定します。

1. 組織管理者の役割を担うユーザー。その後、ユーザーは 各ユーザーを組織に追加し、各ユーザーの役割を設定します。
2. "gateway" ポッド。Message Processor を含むポッドです。

組織には 1 つ以上の環境を含めることができます。Edge のデフォルトのインストール手順 「test」という 2 つの環境を作成するように求められます。作成します必要であれば、さらに多くの環境（"staging"、"experiments" など）を作成できます。

組織は、一部の Apigee 機能のスコープになります。たとえば、Key-Value マップ（KVM）データは組織レベルで使用できますが、これはすべての環境から利用できることを意味します。その他の機能、 スコープは特定の環境をスコープとしますApigee の分析データは 組織と環境の組み合わせです。

以下に、組織の主要オブジェクトを示します。 環境に明確に定義されているものは

環境について

「環境」は、組織内の API プロキシのランタイム実行コンテキストです。環境にアクセスできるようにするには、その環境に API プロキシをデプロイする必要があります。ある特定の API プロキシを、単一の環境または複数の環境にデプロイできます。

1 つの組織に複数の環境を含めることが可能です。たとえば、「dev」というフォルダを 「test」、「prod」1 つです

環境を作成するときに、環境を 1 つ以上の Message Processor に関連付けます。環境は、API プロキシが実行される一連の Message Processor のグループと考えることもできます。毎 複数の Message Processor を同じ Message Processor に関連付けることも、異なる Message Processor に関連付けることもできます。

環境を作成するには、次の 2 つの情報を指定します。

1. 環境を含む組織。
2. 環境に対する API プロキシ リクエストを処理する Message Processor。これらの Message Processor は、環境の親組織に関連付けられたポッドに存在する必要があります。
   デフォルトでは、環境を作成するときに Edge が環境内の使用可能なすべての Message Processor を関連付けます。 「ゲートウェイ」Pod が作成されます。または、サービス アカウントのサブセットを Message Processor ごとにリクエストを処理するようにできます。 必要があります。

Message Processor は複数の環境に関連付けることができます。たとえば、Edge のインストール環境に 2 つの Message Processor（A と B）が存在し、次に、プロジェクトに 3 つの環境を organization: "dev", "test", and "prod":

• "dev" 環境では、大量のトラフィックが発生することはないため、Message Processor A を関連付けます。
• "test" 環境では、大量のトラフィックの発生する可能性が低いため、Message Processor B に関連付けます。
• "prod" 環境では、Message Processor A と B の両方を関連付け、本番環境レベルのトラフィック量を処理できるようにします。

環境に割り当てられた Message Processor は、すべて同じ Pod に属するものでも、別の Pod のものでもかまいません。 複数のリージョンとデータセンターにまたがっています。たとえば、組織内で環境をグローバルに定義し、3 つの異なるリージョン（米国、日本、ドイツ）の Message Processor が含まれるとします。

API プロキシをグローバル環境にデプロイすると、API プロキシは 3 つのデータセンターのすべての Message Processor で実行されます。いずれか 1 つの Router に到着した API トラフィック そのデータセンター内の Message Processor にのみ転送されます。これは、ルーターによって 同じ Pod 内の Message Processor にのみトラフィックを転送します。

仮想ホストについて

「仮想ホスト」では、API プロキシを公開するための Edge Router のポートが定義されます。さらに、拡張機能により、アプリが API プロキシへのアクセスに使用する URL も定義されます。環境ごとに 1 つ以上の仮想ホストを定義する必要があります。

仮想ホストで指定したポート番号は Router ノードで開いている必要があります。Google Chat では 次の URL にリクエストを発行して API プロキシにアクセスします。

http://<routerIP>:<port>/{proxy-base-path}/{resource-name}
https://<routerIP>:<port>/{proxy-base-path}/{resource-name}

ここで

• http または https: 仮想ホストが次のように構成されている場合 TLS/SSL をサポートしているため、HTTPS を使用してください。仮想ホストが TLS/SSL をサポートしていない場合は、HTTP を使用します。
• <routerIP>:<port> は IP 仮想ホストのアドレスとポート番号を指定します。
• {proxy-base-path} と {resource-name} は、API プロキシの作成時に定義されます。

通常、IP アドレスとポート番号を使用して API をお客様に公開することはありません。 代わりに、Router とポートの DNS エントリを定義します。例:

http://myAPI.myCo.com/{proxy-base-path}/{resource-name}
https://myAPI.myCo.com/{proxy-base-path}/{resource-name}

また、DNS のドメイン名と一致するホスト エイリアスを仮想ホストに作成することも必要です。 あります。上記の例では、ホスト エイリアス myAPI.myCo.com を指定します。 DNS エントリがない場合は、ホスト エイリアスを Router の IP アドレスとポート <routerIP>:port の形式で指定します。

詳細については、http://apigee.com/docs/api-services/content/virtual-hosts をご覧ください。

最初の組織、環境、仮想ホストの作成

通常、Edge のインストール プロセスが完了した後に最初に行うのは、「オンボーディング」プロセスで組織、環境、仮想ホストを作成することです。目的 Edge Management Server ノードで次のコマンドを実行します。

/opt/apigee/apigee-service/bin/apigee-service apigee-provision setup-org -f configFile

このコマンドは、ユーザー、組織、環境、サービス アカウントを定義する構成ファイルを入力として 構成されます。

たとえば、以下を作成します。

• 組織管理者として機能することを選択したユーザー
• example という名前の組織
• すべての Message に関連付けられている prod という名前の組織内の環境。 「ゲートウェイ」のプロセッサチーム
• ポート 9001 で HTTP アクセスを許可する、default という名前の（環境内の）仮想ホスト
• 仮想ホストのホスト エイリアス

このスクリプトの実行後、次の形式の URL を使用して API にアクセスできます。

http://<router-ip>:9001/{proxy-base-path}/{resource-name}

組織、環境、仮想ホストはいくつでも追加できます。

オンボーディングの詳細については、 できます。