複数のプロジェクトで共通となる 監視サーバ や 踏み台サーバなどを、1つのプロジェクトにまとめたい、といった要求事項に
対応するパターンです。
K5では、契約内で利用する仮想リソース、グループ、およびユーザーを、プロジェクトという単位で分割して管理します。
プロジェクトは、利用者の目的に応じて使い分けることができます。
このパターンでは、複数のプロジェクトをプロジェクト間接続で接続し、1つのプロジェクトに配備された踏み台サーバや
監視サーバなどの共通サービスを、複数のプロジェクトから利用する例を記載します。
以下では、イメージ図の中央のプロジェクトA『共通プロジェクト』 の踏み台サーバからプロジェクトB/C『業務プロジェクト』 の
仮想サーバにログインしてメンテナンス作業をできるようにしたり、『共通プロジェクト』 の監視サーバで『業務プロジェクト』 の
仮想サーバを監視したりする例を記載しています。
このように、プロジェクト間接続を用いると、複数のプロジェクトでサービスを共通化することが可能です。
実装サンプルでは、上記の構成から、接続元のプロジェクトA『共通プロジェクト』 から 接続先のプロジェクトB『業務プロジェクト』 に
プロジェクト間接続させる手順を記載します。
(1) 接続先の業務プロジェクトのネットワーク環境作成
(a) 外部ネットワーク接続用環境の作成
接続先の業務プロジェクトのネットワーク環境を作成します。
まず、外部ネットワークを接続する内部ネットワークを作成します。
作業については、インターネット接続パターン の ネットワークの作成 や、
複数ルータ外部接続パターン を参照してください。
(b) プロジェクト間接続用環境の作成
接続先の業務プロジェクトに、接続元の共通プロジェクトから接続するための仮想ルータを配備します。
作業については、インターネット接続パターン の ネットワークの作成 や、複数ルータ外部接続パターン を参照してください。
【参考:APIでの仮想ルータ作成とインタフェース追加】
なお、上記の仮想ルータ作成とインタフェース追加は、ポータルでの作業を前提として記載していますが、APIでも作業可能です。
APIの場合は、仮想ルータがサブネット上で1つ目かそれ以降かにより、以下のように作業内容が変わります。
(2) プロジェクト間接続
仮想ルータを用いて、同一ドメイン内で異なるプロジェクトを接続します。
(3) ファイアーウォール/セキュリティグループ設定
仮想サーバ等を配備する前に、ファイアーウォールやセキュリティグループの設定を行ってください。
設定に際しては、以下のデザインパターンをご覧ください。
デザインパターン名称 | 説明 |
---|---|
セキュリティグループ活用 | セキュリティグループ のみでアクセス制御するパターンです。 |
セキュリティグループ/ ファイアーウォール併用 | セキュリティグループ と ファイアーウォール を組み合わせたパターンです。 |
機能別セキュリティグループ | 機能別にアクセス制限をかけるパターンです。 |
(4) 仮想サーバ作成
Webサーバ等の仮想サーバを適宜作成します。
作成後、踏み台サーバからログインできるようになります。
(1) ポート作成
以下のAPIに、設定項目(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" 等 |
(2) 業務プロジェクト(接続先) の仮想ルータに 共通プロジェクト(接続元) のポートを割り当て
以下のAPIに、設定項目(json)を設定して、接続先の業務プロジェクト で実行してください。
項目 | 設定値 | 内容 |
---|---|---|
$ROUTER_ID | (生成されたID) | 接続先の業務プロジェクトの仮想ルータID |
$PORT_ID | (生成されたID) | 接続元の共通プロジェクトで生成されたポートID |
(3) 共通プロジェクト(接続元) のサブネットに 業務プロジェクト(接続先) のサブネットへのルーティングを設定
以下のAPIに、設定項目(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を経由、 となります。 |
(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" | 仮想サーバ内のネットワークインタフェース名称 |
(1) 仮想ルータを作成後、サブネットをアタッチ
仮想ルータを作成し、仮想ルータにサブネットをアタッチします。
サブネットに対して1つ目の仮想ルータの場合の手順です。
(1-a) 仮想ルータを作成
項目 | 設定値 | 内容 |
---|---|---|
$PROJECT_ID | (生成されたID) | 仮想ルータを作成するプロジェクトのID |
$ROUTER_NAME | "router-021" | 仮想ルータ名称 |
$AZ | "jp-east-1b" | "jp-east-1a"、"jp-east-1b" 等 |
(1-b) 仮想ルータをサブネットにアタッチ
項目 | 設定値 | 内容 |
---|---|---|
$ROUTER_ID | (生成されたID) | 作成した仮想ルータのID |
$SUBNET_ID | (生成されたID) | 仮想ルータをアタッチするサブネットID |
(2) 仮想ルータを作成後、サブネット上にポートを作成して、ポートをアタッチ
仮想ルータを作成し、サブネット上にポートを作成し、仮想ルータにポートをアタッチします。
サブネットに対して2つ目以降の仮想ルータの場合の手順です。
(2-a) 仮想ルータを作成
→手順は (1-a) と同じです。
(2-b) 仮想ルータにアタッチするポートを作成
項目 | 設定値 | 内容 |
---|---|---|
$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" 等 |
(2-c) 仮想ルータにポートをアタッチ
項目 | 設定値 | 内容 |
---|---|---|
$ROUTER_ID | (生成されたID) | 作成した仮想ルータのID |
$PORT_ID | (生成されたID) | 作成したポートのID |
本パターンを利用して、ネットワークを共通化した場合のメリット・効果は以下の通りです。
以下の図で、右の 非推奨構成例 の図の内部ネットワークには、仮想ルータが1つも接続されていません。
仮想ルータは、仮想サーバが起動時に 169.254.169.254 にアクセスする際に必要ですので、ネットワークに最低限1つは必要です。
右の図のようなシステム構成は、現状ではプロジェクト間接続でも仮想サーバ起動時の 169.254.169.254 のアクセスは可能ですが、
今後の OpenStack のバージョンアップの影響でアクセスできなくなる可能性もあります。
基本的には、非推奨構成例 のように、仮想ルータが自プロジェクト内に1つもない構成例は、採用しないようお願いいたします。
■推奨構成例
■非推奨構成例
プロジェクト間接続では、以下の図のように、接続元と接続先のどちらのプロジェクトのルータでもプロジェクト間接続の設定は可能です。
プロジェクト間接続を設定するルータの配備先による特徴を考慮して、システム構成を検討してください。
■接続先の業務プロジェクトに仮想ルータを配備する例
■接続元の共通プロジェクトに仮想ルータを配備する例
■プロジェクト間接続を設定するルータの配備先による特徴
ルータ 配備先 | 設定する ルータ数 | 接続時の操作 | 接続時の影響 | 備考 |
---|---|---|---|---|
業務プロジェクト | プロジェクト分 | 業務プロジェクト側のルータに 共通プロジェクトのポートを設定 | プロジェクト間接続の設定の際に、共通プロジェクト(踏み台サーバ)側 でルータの設定変更を行わないため、既存の設定に影響を与えにくい | 仮想ルータがプロジェクト内で内部ネットワークに接続されるため、外部ネットワークへの接続用の仮想ルータがなくてもよい |
共通プロジェクト | 1台 | 共通プロジェクト側のルータに 業務プロジェクトのポートを設定 | プロジェクト間接続の設定の都度、必ず共通プロジェクト側ルータの設定変更が必要となるため、設定ミスが発生した場合の影響範囲が大きい | 仮想ルータがプロジェクト内に配備されないため、外部ネットワークへの接続用の仮想ルータなど、少なくとも仮想ルータが別途1台は内部ネットワーク上に必要 |
※いずれの場合も、接続するネットワーク同士で、ルーティングの設定追加は必要です。
以下の要件がある場合は、共通プロジェクト(踏み台サーバ)側 ではなく、業務プロジェクトのルータでプロジェクト間接続の設定を行う方式を推奨します。