共通サービスパターン#

本構成は東日本／西日本リージョン1・2向けとなります。

要求事項#

複数のプロジェクトで共通となる監視サーバや踏み台サーバなどを、1つのプロジェクトにまとめたい

対応するデザインパターン概要#

このパターンでは、複数のプロジェクトをプロジェクト間接続で接続し、1つのプロジェクトに配備された踏み台サーバや監視サーバなどの共通サービスを、複数のプロジェクトから利用する例を記載します。

FJcloud-Oでは、契約内で利用する仮想リソース、グループ、およびユーザーを、プロジェクトという単位で分割して管理します。
プロジェクトは、利用者の目的に応じて使い分けることができます。

構造 (イメージ図)#

以下では、イメージ図の中央のプロジェクトA『共通プロジェクト』の踏み台サーバからプロジェクトB/C『業務プロジェクト』の仮想サーバにログインしてメンテナンス作業をできるようにしたり、『共通プロジェクト』の監視サーバで『業務プロジェクト』の仮想サーバを監視したりする例を記載しています。

このように、プロジェクト間接続を用いると、複数のプロジェクトでサービスを共通化することが可能です。
実装サンプルでは、上記の構成から、接続元のプロジェクトA『共通プロジェクト』から接続先のプロジェクトB『業務プロジェクト』にプロジェクト間接続させる手順を記載します。

実装サンプル#

1. 作業概要#

(1) 接続先の業務プロジェクトのネットワーク環境作成#

(A) 外部ネットワーク接続用環境の作成#

接続先の業務プロジェクトのネットワーク環境を作成します。
まず、外部ネットワークを接続する内部ネットワークを作成します。

作業については、インターネット接続パターンのネットワークの作成や、複数ルータ外部接続パターンを参照してください。

内部ネットワーク1b作成
外部から接続を受け付ける内部ネットワークを作成します。
ネットワークを作成する際、あわせて、接続元の共通プロジェクトのサブネットへのルーティング情報も、以下の形式で設定します。
- 宛先として、接続元の共通プロジェクトのサブネット(CIDR形式)
- その宛先へ接続するプロジェクト間接続用仮想ルータのIPアドレス
ネットワーク作成時にサブネットにルーティング情報を設定する設定例については、複数ルータ外部接続パターンを参照してください。
外部接続用ルータ作成
ゲートウェイ設定
仮想ルータで、外部ネットワークと接続する際の設定です。
インタフェース追加
仮想ルータで、内部ネットワークと接続する際の設定です。

(B) プロジェクト間接続用環境の作成#

続先の業務プロジェクトに、接続元の共通プロジェクトから接続するための仮想ルータを配備します。

作業については、インターネット接続パターンのネットワークの作成や、複数ルータ外部接続パターンを参照してください。

プロジェクト間接続用仮想ルータ作成
接続元の共通プロジェクトと接続するための仮想ルータを作成します。
インタフェース追加
仮想ルータを作成したら、インタフェース追加で、内部ネットワークを接続します。
インタフェース追加の際には、サブネット作成時にルーティング情報に設定したプロジェクト間接続用仮想ルータのIPアドレス を設定します。

Note

APIでの仮想ルータ作成とインタフェース追加

上記の仮想ルータ作成とインタフェース追加は、IaaSポータルでの作業を前提として記載していますが、APIでも作業可能です。
APIの場合は、仮想ルータがサブネット上で１つ目かそれ以降かにより、以下のように作業内容が変わります。

仮想ルータ作成状況	APIでの作業内容 (参考手順)
サブネットで１つ目の仮想ルータの場合	仮想ルータを作成後、サブネットをアタッチ →手順はこちら
サブネットで２つ目以降の仮想ルータの場合	仮想ルータを作成後、サブネット上にポートを作成して、ポートをアタッチ →手順はこちら

(2) プロジェクト間接続#

仮想ルータを用いて、同一ドメイン内で異なるプロジェクトを接続します。

接続元の共通プロジェクトでポート作成
接続元の共通プロジェクトの内部ネットワーク上に、プロジェクト間接続用の仮想ルータに割り当てるポートを作成します。
ポートには、固定で IPアドレスを割り当てます。
作業手順は、(1) ポート作成を参照してください。
仮想ルータにプロジェクト間接続設定
作成したポートを、接続先の業務プロジェクトの仮想ルータに割り当てます。
作業手順は、(2) 業務プロジェクト(接続先)の仮想ルータに共通プロジェクト(接続元)のポートを割り当てを参照してください。
接続元の共通プロジェクトでルーティング設定
ポートに設定している IPアドレスを、接続先の業務プロジェクトのサブネットへ接続する宛先としてルーティングを設定します。
作業手順は、(3) 共通プロジェクト(接続元)のサブネットに業務プロジェクト(接続先)のサブネットへのルーティングを設定を参照してください。

Note

ルーティング情報は、ルーティング情報を設定した共通プロジェクトのサブネット上の仮想サーバをリブートすると反映されます。
仮想サーバをリブートできない場合は、仮想サーバ内部でルーティング情報を直接手動で設定してください。
作業手順は、(4) 仮想サーバにルーティング情報を設定を参照してください。

(3) ファイアーウォール／セキュリティグループ設定#

仮想サーバ等を配備する前に、ファイアーウォールやセキュリティグループの設定を行ってください。
設定に際しては、以下のデザインパターンをご覧ください。

デザインパターン名称	説明
セキュリティグループ活用	セキュリティグループのみでアクセス制御するパターンです。
セキュリティグループ/ファイアーウォール併用	セキュリティグループとファイアーウォールを組み合わせたパターンです。
機能別セキュリティグループ	機能別にアクセス制限をかけるパターンです。

(4) 仮想サーバ作成#

Webサーバ等の仮想サーバを適宜作成します。
作成後、踏み台サーバからログインできるようになります。

仮想サーバ作成
踏み台サーバからログイン

2. 作業詳細#

(1) ポート作成#

以下のAPIに、設定項目(json)を設定して、接続元の共通プロジェクト で実行してください。

設定項目(json)

項目	設定値例	内容
$PORT_NAME	"pj_conn_port"	ポート名称(任意)
$NETWORK_ID	(生成されたID)	接続元の共通プロジェクトのネットワークID
$SUBNET_ID	(生成されたID)	接続元の共通プロジェクトのサブネットID
$FIXED_IP_ADDRESS	"192.168.0.254"	接続元の共通プロジェクトのサブネット上の任意のIPアドレス
$SG_ID	(生成されたID)	セキュリティグループID
$AZ	"jp-east-1b"	"jp-east-1a"、"jp-east-1b" 等

実行API

curl -s $NETWORK/v2.0/ports -X POST -H "X-Auth-Token: $OS_AUTH_TOKEN" -H "Content-Type: application/json" -d '{"port":{"network_id": "'$NETWORK_ID'", "name": "'$PORT_NAME'", "availability_zone": "'$AZ'", "fixed_ips": [{"subnet_id": "'$SUBNET_ID'", "ip_address": "'$FIXED_IP_ADDRESS'"}], "security_groups": ["'$SG_ID'"] }}' | jq .

(2) 業務プロジェクト(接続先) の仮想ルータに共通プロジェクト(接続元) のポートを割り当て#

以下のAPIに、設定項目(json)を設定して、接続先の業務プロジェクト で実行してください。

設定項目(json)

項目	設定値例	内容
$ROUTER_ID	(生成されたID)	接続先の業務プロジェクトの仮想ルータID
$PORT_ID	(生成されたID)	接続元の共通プロジェクトで生成されたポートID

実行API

curl -s $NETWORK_EX/v2.0/routers/$ROUTER_ID/add_cross_project_router_interface -X PUT -H "X-Auth-Token: $OS_AUTH_TOKEN" -H "Content-Type: application/json" -d '{ "port_id": "'$PORT_ID'" }' |jq.

(3) 共通プロジェクト(接続元) のサブネットに業務プロジェクト(接続先) のサブネットへのルーティングを設定#

以下のAPIに、設定項目(json)を設定して、接続元の共通プロジェクト で実行してください。

設定項目(json)

項目	設定値例	内容
$SUBNET_ID	(生成されたID)	接続元の共通プロジェクトのサブネットID
$HOST_ROUTES	"{\"nexthop\":\"192.168.0.254\",\"destination\":\"192.168.21.0/24\"},\ {\"nexthop\":\"192.168.0.1\",\"destination\":\"0.0.0.0/0\"}"	左記の例では、 192.168.21.0/24 へは192.168.0.254を経由、その他へは192.168.0.1を経由、となります。

実行API

curl -s $NETWORK/v2.0/subnets/$SUBNET_ID -X PUT -H "X-Auth-Token: $OS_AUTH_TOKEN" -H "Content-Type: application/json" -d '{"subnet": { "host_routes": ['$HOST_ROUTES'] }}' | jq .

(4) 仮想サーバにルーティング情報を設定#

仮想サーバは、仮想サーバの起動時にサブネットからルーティング情報を DHCP で取得します。そのため、ルーティング情報を変更した後は、仮想サーバをリブートするのが望ましい運用となります。

プロジェクト間接続の際に、接続元のプロジェクト (本例では共通プロジェクト) 内の仮想サーバが何らかの理由でリブートできない場合は、仮想サーバ内で手動でルーティング情報を設定してください。
Linuxを例にすると、以下のように /sbin/route コマンドを root 権限で実行してください。

設定項目

項目	設定値例	内容
$DESTINATION	"192.168.21.0"	接続先の業務プロジェクトのサブネットのIPアドレス
$NETMASK	"255.255.255.0"	接続先の業務プロジェクトのサブネットのネットマスク
$NEXTHOP	"192.168.0.254"	接続元の共通プロジェクト内の仮想ルータのIPアドレス
$NIC_NAME	"eth0"	仮想サーバ内のネットワークインタフェース名称

実行OSコマンド (Linuxの場合)

sudo su - /sbin/route add -net $DESTINATION netmask $NETMASK gw $NEXTHOP $NIC_NAME

3. 参考手順：APIで仮想ルータ作成とインタフェース追加#

(1) 仮想ルータを作成後、サブネットをアタッチ#

仮想ルータを作成し、仮想ルータにサブネットをアタッチします。
サブネットに対して１つ目の仮想ルータの場合の手順です。

(1-A) 仮想ルータを作成#

設定項目(json)

項目	設定値例	内容
$PROJECT_ID	(生成されたID)	仮想ルータを作成するプロジェクトのID
$ROUTER_NAME	"router-021"	仮想ルータ名称
$AZ	"jp-east-1b"	"jp-east-1a"、"jp-east-1b" 等

実行API

curl -s $NETWORK/v2.0/routers -X POST -H "X-Auth-Token: $OS_AUTH_TOKEN" -H "Content-Type: application/json" -d '{"router": {"name": "'$ROUTER_NAME'", "tenant_id": "'$PROJECT_ID'", "availability_zone": "'$AZ'"}}' | jq .

(1-B) 仮想ルータをサブネットにアタッチ#

設定項目(json)

項目	設定値例	内容
$ROUTER_ID	(生成されたID)	作成した仮想ルータのID
$SUBNET_ID	(生成されたID)	仮想ルータをアタッチするサブネットID

実行API

curl -s $NETWORK/v2.0/routers/$ROUTER_ID/add_router_interface -X PUT -H "X-Auth-Token: $OS_AUTH_TOKEN" -H "Content-Type: application/json" -d '{"subnet_id": "'$SUBNET_ID'" }' | jq .

(2) 仮想ルータを作成後、サブネット上にポートを作成して、ポートをアタッチ#

仮想ルータを作成し、サブネット上にポートを作成し、仮想ルータにポートをアタッチします。
サブネットに対して２つ目以降の仮想ルータの場合の手順です。

(2-A) 仮想ルータを作成#

手順は (1-A) 仮想ルータを作成と同じです。

(2-B) 仮想ルータにアタッチするポートを作成#

設定項目(json)

項目	設定値例	内容
$PORT_NAME	"router_021_port"	ポート名称(任意)
$NETWORK_ID	(生成されたID)	仮想ルータをアタッチするネットワークID
$SUBNET_ID	(生成されたID)	仮想ルータをアタッチするサブネットID
$FIXED_IP_ADDRESS	"192.168.21.253"	ポートに設定するIPアドレス
$SG_ID	(生成されたID)	ポートに設定するセキュリティグループID
$AZ	"jp-east-1b"	"jp-east-1a"、"jp-east-1b" 等

実行API

curl -s $NETWORK/v2.0/ports -X POST -H "X-Auth-Token: $OS_AUTH_TOKEN" -H "Content-Type: application/json" -d '{"port":{"network_id": "'$NETWORK_ID'", "name": "'$PORT_NAME'", "availability_zone": "'$AZ'", "fixed_ips": [{"subnet_id": "'$SUBNET_ID'", "ip_address": "'$FIXED_IP_ADDRESS'"}], "security_groups": ["'$SG_ID'"] }}' | jq .

(2-C) 仮想ルータにポートをアタッチ#

設定項目(json)

項目	設定値例	内容
$ROUTER_ID	(生成されたID)	作成した仮想ルータのID
$PORT_ID	(生成されたID)	作成したポートのID

実行API

curl -s $NETWORK/v2.0/routers/$ROUTER_ID/add_router_interface -X PUT -H "X-Auth-Token: $OS_AUTH_TOKEN" -H "Content-Type: application/json" -d '{"port_id": "'$PORT_ID'" }' | jq .

メリット・効果#

本パターンを利用して、ネットワークを共通化した場合のメリット・効果は以下の通りです。

複数のプロジェクトで共通のサービスを集約することで、構築/運用コストやミドルウェア等のライセンス費用の削減が可能

注意事項#

本パターンは2016年5月時点のFJcloud-O 東日本／西日本リージョン1・2で動作検証しています。
FJcloud-O でのネットワーク構成は非常に自由度が高いため、ファイアーウォールやセキュリティグループにて、通信の制御は必ず行ってください。
セキュリティグループのルールの設定方法で、1プロジェクト内では下記の①②のいずれとも指定可能です。
①送受信先のセキュリティグループ
②送受信先のIPアドレス(CIDR形式)
プロジェクトが異なる場合は、セキュリティグループを共有することができません。
プロジェクトが異なる場合のセキュリティグループのルールは、②送受信先のIPアドレス(CIDR形式) に対して許可するようにしてください。
プロジェクト間接続を用いてサービスを共通化した場合、ファイアーウォールやセキュリティグループのルール数が増大する可能性があります。
機能説明書の制限値に留意しながら、必要最小限のルール数になるように設定してください。
プロジェクト間は、外部ネットワーク接続していない仮想ルータで、同一AZ内にある別プロジェクトを接続できます。
別AZにある別プロジェクトは接続できません。

その他#

1. プロジェクト間接続のアンチパターン#

以下の図で、右の非推奨構成例の図の内部ネットワークには、仮想ルータが１つも接続されていません。
仮想ルータは、仮想サーバが起動時に 169.254.169.254 にアクセスする際に必要ですので、ネットワークに最低限１つは必要です。
右の図のようなシステム構成は、現状ではプロジェクト間接続でも仮想サーバ起動時の 169.254.169.254 のアクセスは可能ですが、今後の OpenStack のバージョンアップの影響でアクセスできなくなる可能性もあります。

基本的には、非推奨構成例のように、仮想ルータが自プロジェクト内に１つもない構成例は、採用しないようお願いいたします。

推薦構成例	非推薦構成例

2. 1つのプロジェクトから複数のプロジェクトに接続する際のルータの配備先について#

プロジェクト間接続では、以下の図のように、接続元と接続先のどちらのプロジェクトのルータでもプロジェクト間接続の設定は可能です。
プロジェクト間接続を設定するルータの配備先による特徴を考慮して、システム構成を検討してください。

接続先の業務プロジェクトに仮想ルータを配備する例	接続元の共通プロジェクトに仮想ルータを配備する例

■プロジェクト間接続を設定するルータの配備先による特徴

ルータ配備先	設定するルータ数	接続時の操作 *1	接続時の影響	備考
業務プロジェクト	プロジェクト分	業務プロジェクト側のルータに共通プロジェクトのポートを設定	プロジェクト間接続の設定の際に、共通プロジェクト(踏み台サーバ)側でルータの設定変更を行わないため、既存の設定に影響を与えにくい	仮想ルータがプロジェクト内で内部ネットワークに接続されるため、外部ネットワークへの接続用の仮想ルータがなくてもよい
共通プロジェクト	1台	共通プロジェクト側のルータに業務プロジェクトのポートを設定	プロジェクト間接続の設定の都度、必ず共通プロジェクト側ルータの設定変更が必要となるため、設定ミスが発生した場合の影響範囲が大きい	仮想ルータがプロジェクト内に配備されないため、外部ネットワークへの接続用の仮想ルータなど、少なくとも仮想ルータが別途１台は内部ネットワーク上に必要

*1 いずれの場合も、接続するネットワーク同士で、ルーティングの設定追加は必要です。

以下の要件がある場合は、共通プロジェクト(踏み台サーバ)側ではなく、業務プロジェクトのルータでプロジェクト間接続の設定を行う方式を推奨します。

プロジェクト単位で管理者や管理部門を分けたい場合
踏み台サーバ側の設定変更を少なくすることで、設定ミスによる他プロジェクトへの影響を抑えられるため