web-dev-qa-db-ja.com

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つのコントローラーノード：2vCPU、4GB RAM-RabbitMQ、mysql、keystone、ダッシュボード、cinder、nova-cloud-controller、lxcコンテナー内のglance

2 Cephノード：1 vCPU、4GB RAMそれぞれ-ceph

2つの計算ノード：2つのvCPU、8 GB RAMそれぞれ-nova-compute

1ネットワークノード：1 vCPU、2 GB RAM-量子ゲートウェイ

さらにMAASホスト：1 vCPU、8 GB RAM

これにより、合計で38 GB RAMおよび10個のvCPUが必要になるため、少しオーバーコミットします。

私の実際の質問は、誰かがより良いアーキテクチャを念頭に置いているかどうかです。私は本当に、OpenStack（またはClouds全般）のいくつかの機能を示す予定です。

jujumaasopenstackvirtualceph
2
hoax

私は同様の設定をしており、あなたの設定に提案させてください：

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

これがお役に立てば幸いです。

フェリペ、

1
Felipe Reyes

まだ実行中の場合はダンプしてLXDを使用することをお勧めします。問題はありません これをデプロイする MaaSなしでローカルLXDのローカル制御でJujuを実行するだけ ここで説明されているように マシンはあまり汗を流さずに実行できるはずです。 MaaSでそれをデモンストレーションする必要がある場合（それは本当に素晴らしいです。近くに来たときにCanonicalが行うOpenstack Roadshowをチェックしてみてください...）少し複雑になります。

このリファレンスは 台のマシンに設定する を示していますが、実際に必要な場合は、こっそりとJujuとMaaSを同じ他のマシンにデプロイできます。 2台目のマシンがLXDの下でMaaSおよびJuJuを実行し、ブリッジがラボLANに接続されていて、PXEトラフィックが通過できる場合、2台のマシンのコンテナーですべて実行できます。私のラップトップ上のVMWare Fusion VMで同様のことを実行しようとしていますが、内部ネットワークをThunderboltにブリッジしましたNIC MaaSおよびJujuマシンがRaspberry PiをオーケストレートできるようにするNUCデバイス。

1
spyderdyne

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

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

0
BostonHiker

小さなクラスター、特にtest-lab-type-stuffで物理ノードを使用する場合、典型的なショートカットの1つは、ceph-nodeをcompute-nodeと結合することです。このceph-0.48時代の debianの手順 のセット、またはこれより新しい proxmox VEのラボ構成 を参照してください。

あなたが提供した数字と、他の答えでのラム減少とトリプルセフの提案を使用すると、おそらく次のようになります：

  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また、devstack.orgで、oneVMを備えた1つの物理ノードでのOpenStackの準公式ヘルプドキュメントと、専用のボックスチュートリアルのより関連性の高いOpenStackも参照してください。

0
guest29385283