第2章 個別 heat スタックのデプロイメントの設計


個別の heat スタック内でデプロイメントを分割するには、まずコントロールプレーンと共に単一のオーバークラウドをデプロイする必要があります。その後、分散コンピュートノード (DCN) サイト向けに個別のスタックを作成することができます。以下の例は、異なるノード種別の個別スタックを示しています。

  • コントローラーノード: central (例) という名前の個別 heat スタックにより、コントローラーをデプロイします。DCN サイト向けの新規 heat スタックを作成する場合は、central スタックからのデータを使用してスタックを作成する必要があります。コントローラーノードは、あらゆるインスタンス管理タスクに利用できなければなりません。
  • DCN サイト: dcn0dcn1 など、一意の名前が付けられた個別の heat スタックを設定することができます。DHCP リレーを使用して、プロビジョニングネットワークをリモートサイトに拡張します。
注記

管理を簡素化するには、各スタックに個別のアベイラビリティーゾーン (AZ) を作成します。

注記

スパイン/リーフ型ネットワークを使用する場合には、特定の形式を使用して Storage および StorageMgmt ネットワークを定義する必要があります。Storage および StorageMgmt ネットワークをオーバーライド値として定義し、値を一重引用符で囲みます。以下の例では、ストレージネットワーク(public_network) はカンマで区切られた 2 つのサブネットにまたがり、一重引用符で囲まれています。

Copy to Clipboard Toggle word wrap
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 ファイルは、スタックが使用するネットワークリソースを定義します。

Copy to Clipboard Toggle word wrap
- 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'

新規スタックが既存のネットワークリソースを管理しないように、以下のシーケンスを使用します。

手順

  1. ManageNetworks: true と設定するか未設定のままにして、中央スタックをデプロイします。
  2. 追加のスタックをデプロイします。

新規ネットワークリソースを追加する場合、たとえばスパイン/リーフ型デプロイメントに新しいリーフを追加する場合は、新たな network_data.yaml で中央スタックを更新する必要があります。これは、中央スタックが引き続きネットワークリソースを所有および管理するためです。中央スタックでネットワークリソースが利用可能になったら、それらを使用するように追加のスタックをデプロイすることができます。

2.1.2. UUID を使用したネットワークリソースの再利用

スタック間でのネットワークの再利用をより厳密に制御する必要がある場合は、network_data.yaml ファイルでリソース (ネットワーク、サブネット、セグメント、仮想 IP 等) の external_resource_* フィールドを使用することができます。これらのリソースは外部管理と識別され、heat はそれらのリソースに関する作成、更新、または削除を一切行いません。

network_data.yaml ファイルに、必要な各ネットワーク定義のエントリーを追加します。これで、リソースを別のスタックでのデプロイメントに利用できるようになります。

Copy to Clipboard Toggle word wrap
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 ネットワークを別のスタックで再利用します。

手順

  1. 関連するネットワークリソースの UUID を把握します。

    Copy to Clipboard Toggle word wrap
    $ 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
  2. 上記のコマンドの出力に表示される値を保存し、それらを別のスタックの network_data.yaml ファイルの internal_api ネットワークのネットワーク定義に追加します。

    Copy to Clipboard Toggle word wrap
    - 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
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat, Inc.