第2章 個別 heat スタックのデプロイメントの設計
個別の heat スタック内でデプロイメントを分割するには、まずコントロールプレーンと共に単一のオーバークラウドをデプロイする必要があります。その後、分散コンピュートノード (DCN) サイト向けに個別のスタックを作成することができます。以下の例は、異なるノード種別の個別スタックを示しています。
-
コントローラーノード:
central
(例) という名前の個別 heat スタックにより、コントローラーをデプロイします。DCN サイト向けの新規 heat スタックを作成する場合は、central
スタックからのデータを使用してスタックを作成する必要があります。コントローラーノードは、あらゆるインスタンス管理タスクに利用できなければなりません。 -
DCN サイト:
dcn0
、dcn1
など、一意の名前が付けられた個別の heat スタックを設定することができます。DHCP リレーを使用して、プロビジョニングネットワークをリモートサイトに拡張します。
管理を簡素化するには、各スタックに個別のアベイラビリティーゾーン (AZ) を作成します。
スパイン/リーフ型ネットワークを使用する場合には、特定の形式を使用して Storage
および StorageMgmt
ネットワークを定義する必要があります。Storage
および StorageMgmt
ネットワークをオーバーライド値として定義し、値を一重引用符で囲みます。以下の例では、ストレージネットワーク(public_network
) はカンマで区切られた 2 つのサブネットにまたがり、一重引用符で囲まれています。
CephAnsibleExtraConfig: public_network: '172.23.1.0/24,172.23.2.0/24'
CephAnsibleExtraConfig:
public_network: '172.23.1.0/24,172.23.2.0/24'
2.1. 複数スタックでのネットワークリソースの再利用
複数のスタックが同じネットワークリソース (仮想 IP アドレスやサブネット等) を使用するように設定することができます。ManageNetworks
設定または external_resource_*
フィールドのいずれかを使用して、スタック間でネットワークリソースを複製することができます。
external_resource_*
フィールドを使用している場合は、ManageNetworks
設定を使用しないでください。
スタック間でネットワークを再利用しない場合は、network_data.yaml
で定義される各ネットワークには、デプロイされるすべてのスタックに渡って一意の名前を指定する必要があります。たとえば、スタック間でネットワークを共有する意図がない限り、ネットワーク名 internal_api
をスタック間で再利用することはできません。ネットワークに異なる名前および name_lower
属性 (例: InternalApiCompute0
および internal_api_compute_0
) を設定します。
2.1.1. ManageNetworks を使用したネットワークリソースの再利用
ManageNetworks
設定を使用すると、複数のスタックで同じ network_data.yaml
ファイルを使用することができ、設定はグローバルにすべてのネットワークリソースに適用されます。network_data.yaml
ファイルは、スタックが使用するネットワークリソースを定義します。
- name: StorageBackup vip: true name_lower: storage_backup ip_subnet: '172.21.1.0/24' allocation_pools: [{'start': '171.21.1.4', 'end': '172.21.1.250'}] gateway_ip: '172.21.1.1'
- name: StorageBackup
vip: true
name_lower: storage_backup
ip_subnet: '172.21.1.0/24'
allocation_pools: [{'start': '171.21.1.4', 'end': '172.21.1.250'}]
gateway_ip: '172.21.1.1'
新規スタックが既存のネットワークリソースを管理しないように、以下のシーケンスを使用します。
手順
-
ManageNetworks: true
と設定するか未設定のままにして、中央スタックをデプロイします。 - 追加のスタックをデプロイします。
新規ネットワークリソースを追加する場合、たとえばスパイン/リーフ型デプロイメントに新しいリーフを追加する場合は、新たな network_data.yaml
で中央スタックを更新する必要があります。これは、中央スタックが引き続きネットワークリソースを所有および管理するためです。中央スタックでネットワークリソースが利用可能になったら、それらを使用するように追加のスタックをデプロイすることができます。
2.1.2. UUID を使用したネットワークリソースの再利用
スタック間でのネットワークの再利用をより厳密に制御する必要がある場合は、network_data.yaml
ファイルでリソース (ネットワーク、サブネット、セグメント、仮想 IP 等) の external_resource_*
フィールドを使用することができます。これらのリソースは外部管理と識別され、heat はそれらのリソースに関する作成、更新、または削除を一切行いません。
network_data.yaml
ファイルに、必要な各ネットワーク定義のエントリーを追加します。これで、リソースを別のスタックでのデプロイメントに利用できるようになります。
external_resource_network_id: Existing Network UUID external_resource_subnet_id: Existing Subnet UUID external_resource_segment_id: Existing Segment UUID external_resource_vip_id: Existing VIP UUID
external_resource_network_id: Existing Network UUID
external_resource_subnet_id: Existing Subnet UUID
external_resource_segment_id: Existing Segment UUID
external_resource_vip_id: Existing VIP UUID
以下の例では、コントロールプレーンスタックからの internal_api
ネットワークを別のスタックで再利用します。
手順
関連するネットワークリソースの UUID を把握します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow openstack network show internal_api -c id -f value openstack subnet show internal_api_subnet -c id -f value openstack port show internal_api_virtual_ip -c id -f value
$ openstack network show internal_api -c id -f value $ openstack subnet show internal_api_subnet -c id -f value $ openstack port show internal_api_virtual_ip -c id -f value
上記のコマンドの出力に表示される値を保存し、それらを別のスタックの
network_data.yaml
ファイルのinternal_api
ネットワークのネットワーク定義に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - name: InternalApi external_resource_network_id: 93861871-7814-4dbc-9e6c-7f51496b43af external_resource_subnet_id: c85c8670-51c1-4b17-a580-1cfb4344de27 external_resource_vip_id: 8bb9d96f-72bf-4964-a05c-5d3fed203eb7 name_lower: internal_api vip: true ip_subnet: '172.16.2.0/24' allocation_pools: [{'start': '172.16.2.4', 'end': '172.16.2.250'}] ipv6_subnet: 'fd00:fd00:fd00:2000::/64' ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:2000::10', 'end': 'fd00:fd00:fd00:2000:ffff:ffff:ffff:fffe'}] mtu: 1400
- name: InternalApi external_resource_network_id: 93861871-7814-4dbc-9e6c-7f51496b43af external_resource_subnet_id: c85c8670-51c1-4b17-a580-1cfb4344de27 external_resource_vip_id: 8bb9d96f-72bf-4964-a05c-5d3fed203eb7 name_lower: internal_api vip: true ip_subnet: '172.16.2.0/24' allocation_pools: [{'start': '172.16.2.4', 'end': '172.16.2.250'}] ipv6_subnet: 'fd00:fd00:fd00:2000::/64' ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:2000::10', 'end': 'fd00:fd00:fd00:2000:ffff:ffff:ffff:fffe'}] mtu: 1400