第1章 エッジサイトへの分散コンピュートノードのデプロイ

それぞれのエッジサイトを独立したアベイラビリティーゾーン (AZ) として設定する必要があります。この AZ にインスタンスをデプロイする場合、リモートのコンピュートノード上で実行されることになります。また、中央サイトも、デフォルトの AZ ではなく特定の AZ (または複数の AZ) 内に含まれている必要があります。アベイラビリティーゾーン間のライブマイグレーションはサポートされていません。

DCN のデプロイメントを設計する場合には、冗長性を検討する必要があります。DNC では、地理的に異なるさまざまな場所でコンピュートノードをホストすることができます。これらのリモートサイトのどこかで発生する障害に対して耐性を持たせるには、ホストに複数の冗長パスを設定することを検討してください。物理ノードについては、物理接続に冗長性を持たせることを検討してください。

DCN のデプロイメントには、ルーティング対応 L3 ネットワークが推奨されます。

エッジロケーションではプロバイダーネットワークだけを使用することを推奨します。したがって、config-drive または IPv6 SLAAC の使用を検討してください。あるいは、cloud-init と共にその他の設定メカニズムを使用します。Config-drive はメタデータ API サーバーとして機能し、BMC コントローラーの仮想メディア機能を使用することができます。このため、エッジサイトの仮想マシンインスタンスが IP アドレスを取得するのに、Neutron Metadata/DHCP エージェントまたは DHCP リレーは必要ありません。ただし、仮想マシンのデプロイメント時に、リモートサイトと中央サイト間の WAN が動作状態でなければなりません。なおデプロイメント後は、仮想マシンは中央サイトとのネットワーク接続がなくても独立して動作することができます。

DCN は、ローカルの一時ストレージを使用する Compute サービスに限り利用することが可能です。データの可用性、局所性の認識、および複製手段について検討しながらエッジクラウドアプリケーションを設計してください。

本項では、特定の障害が及ぼし得る影響について説明します。これらのリスクを軽減するために、高可用性が推奨されます。この点についても言及します。

本項では、DCN 用にアンダークラウドを設定するのに必要な手順について説明します。

$ source ~/stackrc
$ openstack role add --user admin --project service ResellerAdmin
$ openstack --os-project-name service object store account set --property Temp-URL-Key=$(uuidgen | sha1sum | awk '{print $1}')

{
   "nodes":[
       {
           "mac":[
               "bb:bb:bb:bb:bb:bb"
           ],
           "name":"node01",
           "cpu":"4",
           "memory":"6144",
           "disk":"40",
           "arch":"x86_64",
           "pm_type":"ipmi",
           "pm_user":"admin",
           "pm_password":"p@55w0rd!",
           "pm_addr":"192.168.24.205",
           “deploy_interface”: “direct”
       },
       {
           "mac":[
               "cc:cc:cc:cc:cc:cc"
           ],
           "name":"node02",
           "cpu":"4",
           "memory":"6144",
           "disk":"40",
           "arch":"x86_64",
           "pm_type":"ipmi",
           "pm_user":"admin",
           "pm_password":"p@55w0rd!",
           "pm_addr":"192.168.24.206"
           “deploy_interface”: “direct”
       }
   ]
}

$ openstack baremetal node set --deploy-interface direct 4b64a750-afe3-4236-88d1-7bb88c962666

エッジサイトでの DCN デプロイメントでサポートされるのは、/usr/share/openstack-tripleo-heat-templates/roles/Compute.yaml で定義されるデフォルトの Compute ロールだけです。ただし、ロールをコピーして名前を変更し、エッジサイトで異なるソフトウェア設定を許可することは可能です。

以下の例で、2 つの異なるロールが 2 つの個別の AZ に同じサービスのセットを使用する設定方法を説明します。

##############################################################################
# Role: ComputeAZ1
##############################################################################
- name: ComputeAZ1
 description: |
  Basic Compute Node role for AZ1
 CountDefault: 1
 networks:
  - InternalApi1
  - Tenant1
  - Storage1
 HostnameFormatDefault: '%stackname%-compute-az1-%index%'
 RoleParametersDefault:
  TunedProfileName: "virtual-host"
 disable_upgrade_deployment: True
 ServicesDefault:
  - OS::TripleO::Services::Aide
  - OS::TripleO::Services::AuditD
  - OS::TripleO::Services::CACerts
  - OS::TripleO::Services::CephClient
  - OS::TripleO::Services::CephExternal
  - OS::TripleO::Services::CertmongerUser
  - OS::TripleO::Services::Collectd
  - OS::TripleO::Services::ComputeCeilometerAgent
  - OS::TripleO::Services::ComputeNeutronCorePlugin
  - OS::TripleO::Services::ComputeNeutronL3Agent
  - OS::TripleO::Services::ComputeNeutronMetadataAgent
  - OS::TripleO::Services::ComputeNeutronOvsAgent
  - OS::TripleO::Services::Docker
  - OS::TripleO::Services::Fluentd
  - OS::TripleO::Services::Ipsec
  - OS::TripleO::Services::Iscsid
  - OS::TripleO::Services::Kernel
  - OS::TripleO::Services::LoginDefs
  - OS::TripleO::Services::MySQLClient
  - OS::TripleO::Services::NeutronBgpVpnBagpipe
  - OS::TripleO::Services::NeutronLinuxbridgeAgent
  - OS::TripleO::Services::NeutronVppAgent
  - OS::TripleO::Services::NovaCompute
  - OS::TripleO::Services::NovaLibvirt
  - OS::TripleO::Services::NovaMigrationTarget
  - OS::TripleO::Services::Ntp
  - OS::TripleO::Services::ContainersLogrotateCrond
  - OS::TripleO::Services::OpenDaylightOvs
  - OS::TripleO::Services::Rhsm
  - OS::TripleO::Services::RsyslogSidecar
  - OS::TripleO::Services::Securetty
  - OS::TripleO::Services::SensuClient
  - OS::TripleO::Services::SkydiveAgent
  - OS::TripleO::Services::Snmp
  - OS::TripleO::Services::Sshd
  - OS::TripleO::Services::Timezone
  - OS::TripleO::Services::TripleoFirewall
  - OS::TripleO::Services::TripleoPackages
  - OS::TripleO::Services::Tuned
  - OS::TripleO::Services::Vpp
  - OS::TripleO::Services::OVNController
  - OS::TripleO::Services::OVNMetadataAgent
  - OS::TripleO::Services::Ptp
##############################################################################
# Role: ComputeAZ2
##############################################################################
- name: ComputeAZ2
 description: |
  Basic Compute Node role for AZ2
 CountDefault: 1
 networks:
  - InternalApi2
  - Tenant2
  - Storage2
 HostnameFormatDefault: '%stackname%-compute-az2-%index%'
 RoleParametersDefault:
  TunedProfileName: "virtual-host"
 disable_upgrade_deployment: True
 ServicesDefault:
  - OS::TripleO::Services::Aide
  - OS::TripleO::Services::AuditD
  - OS::TripleO::Services::CACerts
  - OS::TripleO::Services::CephClient
  - OS::TripleO::Services::CephExternal
  - OS::TripleO::Services::CertmongerUser
  - OS::TripleO::Services::Collectd
  - OS::TripleO::Services::ComputeCeilometerAgent
  - OS::TripleO::Services::ComputeNeutronCorePlugin
  - OS::TripleO::Services::ComputeNeutronL3Agent
  - OS::TripleO::Services::ComputeNeutronMetadataAgent
  - OS::TripleO::Services::ComputeNeutronOvsAgent
  - OS::TripleO::Services::Docker
  - OS::TripleO::Services::Fluentd
  - OS::TripleO::Services::Ipsec
  - OS::TripleO::Services::Iscsid
  - OS::TripleO::Services::Kernel
  - OS::TripleO::Services::LoginDefs
  - OS::TripleO::Services::MySQLClient
  - OS::TripleO::Services::NeutronBgpVpnBagpipe
  - OS::TripleO::Services::NeutronLinuxbridgeAgent
  - OS::TripleO::Services::NeutronVppAgent
  - OS::TripleO::Services::NovaCompute
  - OS::TripleO::Services::NovaLibvirt
  - OS::TripleO::Services::NovaMigrationTarget
  - OS::TripleO::Services::Ntp
  - OS::TripleO::Services::ContainersLogrotateCrond
  - OS::TripleO::Services::OpenDaylightOvs
  - OS::TripleO::Services::Rhsm
  - OS::TripleO::Services::RsyslogSidecar
  - OS::TripleO::Services::Securetty
  - OS::TripleO::Services::SensuClient
  - OS::TripleO::Services::SkydiveAgent
  - OS::TripleO::Services::Snmp
  - OS::TripleO::Services::Sshd
  - OS::TripleO::Services::Timezone
  - OS::TripleO::Services::TripleoFirewall
  - OS::TripleO::Services::TripleoPackages
  - OS::TripleO::Services::Tuned
  - OS::TripleO::Services::Vpp
  - OS::TripleO::Services::OVNController
  - OS::TripleO::Services::OVNMetadataAgent
  - OS::TripleO::Services::Ptp

名前の異なるロールに同じサービスのセットが設定されている点に注意してください。RoleParameters パラメーターを使用して、個別にサービスパラメーターを設定することができます。以下に例を示します。

parameter_defaults:
 RoleParameters:
   ComputeAZ1:
     NovaReservedHostMemory: 4096
   ComputeAZ2:
     NovaReservedHostMemory: 2048

上記の例では、ComputeAZ1 ロールでデプロイされるノードの NovaReservedHostMemory には 4096 が設定されています。また、ComputeAZ2 ロールでデプロイされるノードの NovaReservedHostMemory には 2048 が設定されています。

ノードを AZ にデプロイするには、物理ノードを新しいロールにタグ付けしてプロビジョニングネットワークにブートアップする一般的なプロビジョニング手順に従います。director のデプロイメントに関する詳しい情報は、『director のインストールと使用方法』を参照してください。

エッジサイトでの DCN デプロイメントは、レイテンシーが 100 ms 以上になると大きな影響を受けます。したがって、これらのネットワーク接続に対して監視を行い、レイテンシーのしきい値に達した場合には警告を発行する必要があります。

BAU 運用のために、ローカルのコンピュートノードを管理するのと同じように DCN ノードを管理することができます。たとえば、更新の適用方法に関しては、DCN と標準のコンピュートノードで違いはありません。更新を適用するノードを管理することができます。つまり、すべてのコンピュートノードを一括して更新するのではなく、サイトごとにノードを更新することができます。

たとえば、openstack overcloud update run の --nodes パラメーターを使用して、コンピュートノードのリストに従い、またはロールごとに更新を実施することができます。それぞれのリモートサイトは固有のロールを持つので、サイトごとにマイナーアップデートを実施したり、更新を特定のノードに限定したりすることができます。詳細は、『Red Hat OpenStack Platform の最新状態の維持』の「全コンピュートノードの更新」を参照してください。

$ openstack overcloud update run --nodes Controller0

オーバークラウドに追加することのできるノードの数は、アンダークラウドが管理することのできるノードの数に制限されます。オーバークラウドデプロイメントのノード数が増えると、管理すべきリソースの数も増えます。

1 つのデプロイメントのノード数は、300 を超えないことを推奨します。この数字は、ハードウェアのサイズ、オーバークラウドの設定、およびその他の要素に強く依存します。物理ハードウェアを使用した過去のテストでは、1 つのアンダークラウドでノード数の合計が 150 のオーバークラウドをデプロイできることが示されています。よりノード数の多いデプロイメントも正常に機能する可能性はありますが、テストされてはいません。現在実施中のテストの結果が評価されるにつれ、この推奨値が上がる可能性がある点に留意してください。

デプロイメントの完了に必要な時間は、さまざまな要素により変動します。これにはアンダークラウドのリソース、ネットワークの帯域幅、およびノードのブートに要する時間が含まれます。ただし、デプロイメント時間に最も大きな影響を及ぼす要素の 1 つは、デプロイメント中のノード数です。

Red Hat OpenStack Platform 13 において DCN アーキテクチャーをデプロイする際には、アンダークラウドが管理するすべてのノードを同じスタックにデプロイする必要があります。これは、アンダークラウドが 1 つのオーバークラウドスタックしかデプロイすることができないためです。追加のオーバークラウドスタックまたはデプロイメントが必要な場合には、デプロイメントごとに独立したアンダークラウドを使用する必要があります。複数のデプロイメントで複数のアンダークラウドを使用する場合には、デプロイメントは独立したクラウドとみなされ、デプロイメント間での運用上の連携はありません。

すべてのノードが 1 つのスタックにデプロイされるので、いずれかのノードで何らかのデプロイメントの問題が発生すると、デプロイメント全体が停止して失敗し、異常として報告されます。デプロイメントのノード数が増えると、デプロイメント中に新たな問題が発生する可能性が高まります。これらの問題を解消しないと、デプロイメントを続行することはできません。これらの問題に対処するには、問題を修正するか、影響を受けるノードをまとめてデプロイメントから削除します。問題が解決したら、デプロイメントを実行し直します。

デプロイメント中断のリスクを軽減するには、段階的にデプロイメントを実行します。コントロールプレーンサービス (特にコントローラー) のノードおよび少数のコンピュートノードからデプロイメントを始めます。初期デプロイメントが正常に完了したら、コンピュートノードの数を増やして適切なサイズのバッチを追加することができます (10 台、20 台…)。それぞれのスケールアップ試行時に追加するバッチのサイズは、環境的な要素ならびにハードウェアおよびネットワーク内に問題が存在する可能性の大小により異なります。

エッジサイトの DCN が予想に反する挙動を示す場合には、ネットワークレイテンシーを確認してください。高いレイテンシーが、DCN の予期せぬ挙動となって現れる場合があります (レイテンシーの高さによる)。たとえば、当初はネットワーク障害と思われていた事象が、実際には高いレイテンシーの結果だったというケースがあります。

ノードのデプロイメントが Connection timed out および No bootable device エラーにより失敗する場合には、ノードが iscsi ではなく direct デプロイを使用するように設定されていることを確認してください。詳細は、「デプロイインターフェースを使用するノードの設定」を参照してください。