☰

1 つの物理ノードを持つ仮想 OpenStack デプロイメント (Juju/MAAS) のアーキテクチャ

tag-icon • tag-icon juju maas openstack ceph
1 つの物理ノードを持つ仮想 OpenStack デプロイメント (Juju/MAAS) のアーキテクチャ

OpenStacks の HA/FT 機能 (最も重要なのはライブ マイグレーションとストレージ レプリケーション) のいくつかをデモしたいと思います。そのために、32 GB RAM と 4 コア (8 スレッド) の Xeon e3v2 を搭載したマシンを用意しました。これまで、MAAS と Juju を稼働させることに成功しましたが、安全に展開できる仮想ノードの数 (および CPU / RAM オーバーコミット比。ただし、物理 CPU は 1 vcpu マシンでオーバーコミットをかなりうまく処理できるとどこかで読んだことがあります) については確信がありません。

現在、MAAS を実行する VM は 1 つの vCPU と 8 GB の RAM を使用しており、Juju はホスト上で実行されています。そのため、リソースをオーバーコミットすることなく、7 つの vCPU と 24 GB の RAM が残ります。私が思いついたのは次のようになります。

  • 1 つのコントローラー ノード: 2 つの vCPU、4 GB RAM - RabbitMQ、mysql、keystone、dashboard、cinder、nova-cloud-controller、lxc コンテナー内の Glance
  • 2 つの Ceph ノード: それぞれ 1 つの vCPU、4 GB の RAM - ceph
  • 2 つのコンピューティング ノード: それぞれ 2 つの vCPU、8 GB RAM - nova-compute
  • 1 ネットワーク ノード: 1 vCPU、2 GB RAM - quantum-gateway
  • MAASホスト: 1 vCPU、8GB RAM

これにより、合計 38 GB の RAM と 10 個の vCPU になるため、少しオーバーコミットしていることになります。

私の本当の質問は、もっと良いアーキテクチャを思いついた人がいるかどうかです。私は本当に OpenStack (または一般的なクラウド) のいくつかの機能を紹介するつもりです。

答え1

私も同様の設定をしていますが、あなたの構成に次の提案をさせてください:

  • MAAS に割り当てられる RAM の量を減らします。約 2GB で十分です。
  • 別の Ceph ノードを追加します。これにより、Ceph を使用していて 1 つのノードがダウンした場合の回復力を実証するのに役立ちます。
  • CPU のオーバーコミットはそれほど悪くありませんが、メモリのオーバーコミットは避けてください。システムがスワップを開始し、すべてが使用できないパフォーマンスになるからです。
  • あなたが言及していないのは、あなたが持っているディスクです。これは私にとって大きなボトルネックです。私は btrfs (raid0) を備えた 2 x 7200 RPM ディスクを持っていますが、juju が展開されている間は十分ではありません。
  • また、juju-deployer を使用して、デプロイに使用するコマンド ライン、具体的にはタイムアウト修飾子と、各「juju deploy」呼び出し間の遅延である「-s」を調整することもできます。

これが役に立つことを願っています。

フェリペ、

答え2

まだ動いているなら捨ててLXDを使うことをお勧めします。問題はないはずです。これを展開するMaaSを使用せず、ローカルLXDをローカル制御してJujuを実行するだけここで説明されているとおりです。 お使いのマシンは、それほど苦労せずにこれを実行できるはずです。これを実証するために MaaS が必要な場合 (これは本当に素晴らしいことです。Canonical が近くで開催する Openstack ロードショーをチェックしてみてください...)、状況は少し複雑になります。

この参考文献は3台のマシンで設定するただし、本当に必要な場合は、Juju と MaaS を同じ別のマシンに展開することもできます。2 台目のマシンで MaaS と JuJu を LXD で実行し、ブリッジをラボ LAN に接続して PXE トラフィックを通過できる場合は、2 台のマシンのコンテナーですべてを実行できるはずです。私は、ラップトップ上の VMWare Fusion VM で同様のことを実行しようとしています。内部ネットワークを Thunderbolt NIC にブリッジして、MaaS マシンと Juju マシンが Raspberry Pi と NUC デバイスをオーケストレーションできるようにしています。

答え3

私は OpenStack オーケストレーションに juju を使用した経験はありませんが、Ceph と OpenStack の経験から、デモ目的では 2GB のマシンで問題なく Ceph を実行でき、maas ホストも 8GB ではなく 6GB で構成できると思います。

juju では同じ VM 内で異なるロールを組み合わせることができるかどうかはわかりませんが、私たちの (juju 以外の) 展開では、コントローラー ロールとネットワーク ロールを同じ VM 上で組み合わせています (コンテナーは使用していません)。

答え4

小規模なクラスタ、特にテストラボタイプのクラスタで物理ノードを使用する場合、典型的なショートカットの1つは、cephノードをコンピューティングノードと組み合わせることです。このceph-0.48時代のセットを参照してください。Debian の手順、またはより現代的なproxmox VE のラボ構成。

あなたが提供した数値と、他の回答にある ram-decreases と triple-ceph の提案を使用すると、おそらく次のようになります。

  1. 3vCpu + 8gb == RabbitMQ/keystone/glance/etc + cephMon1/Osd1
  2. 2vCpu + 10gb == novaComp2/Net2/Vol2 + cephMon2/Osd2/Httpd2/Rgw2
  3. 2vCpu + 10gb == novaComp3/Net3 + cephMon3/Osd3
  4. 1vCPU + 2GB == novaQuantum4
  5. 1vCPU + 3GB == MAAS_host5

現在、私自身もこの種の 1 ノード構成に取り組んでいますが、利用できる RAM が少なく、割り当てられるディスクは 4 つだけです (cephOsd は複数のディスクを使用する方が適しています)。このスキームを自分で試していないため、上記の数値が適切なパフォーマンスで機能するかどうかは確認できませんが、ある程度直交するノードをマージして vCpu と ram を節約するという基本的な考え方は、目的を達成するのに十分な牽引力となる可能性があります。

ps また、1つの物理ノードでOpenStackを実行するための準公式ヘルプドキュメントも参照してください。1つVM、および専用ボックス上のより関連性の高い OpenStack チュートリアル (devstack.org)

関連情報