3

I'd like to demonstrate some of OpenStacks HA/FT features (most importantly live migration and storage replication). For that purpose, I have a machine with 32 GB RAM and a Xeon e3v2 with 4 cores (8 threads). So far I've managed to get MAAS and Juju up and running, but I'm not sure about the number of virtual nodes I can safely deploy (and the CPU / RAM overcommit ratio, although I've read somewhere that the physical CPU can handle overcommitting with 1-vcpu-machines pretty well).

Currently, the VM that runs MAAS uses 1 vCPU and 8 GB RAM, Juju runs on the host. That leaves me with 7 vCPUs and 24 GB RAM without overcommiting any resources. What I've come up with is the following:

  • 1 Controller node: 2vCPUs, 4GB RAM - RabbitMQ, mysql, keystone, dashboard, cinder, nova-cloud-controller and glance in lxc containers
  • 2 Ceph nodes: 1 vCPU, 4GB RAM each - ceph
  • 2 Compute nodes: 2 vCPUs, 8GB RAM each - nova-compute
  • 1 Network node: 1 vCPU, 2GB RAM - quantum-gateway
  • Plus the MAAS host: 1 vCPU, 8GB RAM

This would result in a total of 38 GB RAM and 10 vCPUs, so I'm overcommiting a little.

My actual question is if anyone has a better architecture in mind. I really just plan to show some features of OpenStack (or clouds in general).

Zanna
  • 72,312
hoax
  • 33

4 Answers4

2

I have a similar setup, and let me suggest to your configuration:

  • Reduce the amount of RAM assigned to MAAS, around 2GB will be enough.
  • Add another ceph node, this will help you to demonstrate resilience when using ceph and 1 node goes down.
  • Overcommit in CPU isn't that bad, but you don't want to overcommit in memory, because the system will start swapping and everything will get unusable performance.
  • Something you don't mention is the disks you have, this is a huge bottleneck for me, I have 2 x 7200 RPMs disks with btrfs (raid0), but it isn't enough while the juju is deploying.
  • Also you may want to use juju-deployer and tweak the command line you use to deploy, specifically timeout modifiers and '-s' which is a delay between each "juju deploy" call.

I hope this helps.

Felipe,

Felipe Reyes
  • 358
2

I suggest you dump it if its still running and use LXD. You should have no issues deploying this without MaaS and just running Juju with local control of your local LXD as described here. Your machine should be able to run it without sweating too much. If you require MaaS to demonstrate it (It really is pretty awesome. You should try to check out the Openstack Roadshows that Canonical does if one comes nearby...) then it gets a bit more complicated.

This reference demonstrates setting it up on 3 machines, but you can get sneaky and deploy Juju and MaaS to the same other machine if you really need to. If your second machine was running MaaS and JuJu under LXD with the bridge connected to your lab LAN and your PXE traffic could get through you should be able to run it all in containers on two machines. I am attempting to do something similar with VMWare Fusion VMs on my laptop where I have bridged the internal network out to a thunderbolt NIC to allow the MaaS and Juju machines to orchestrate Raspberry Pi and NUC devices.

spyderdyne
  • 715
0

I do not have experience using juju for openstack orchestration, but from experience with ceph and openstack, for demo purposes you can run ceph on 2GB machines w/o problems and I think that the maas host can also be configured with 6GB instead of 8.

I do not know if juju allows you to combine different roles in the same VM, in our (non-juju) deployments we combine the controller and the network roles on the same VM (not using containers).

BostonHiker
  • 627
0

When using physical nodes in a small cluster, especially test-lab-type-stuff, one typical shortcut is to combine the ceph-nodes with your compute-nodes. See this ceph-0.48-era set of instructions for debian, or this more modern lab config for proxmox VE.

Using the numbers you provided, and the suggestions for ram-decreases plus triple-ceph in the other answers, perhaps something like this:

  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

I'm currently working on a one-node config of this nature myself, but have less RAM available, and only four disks to devote (cephOsd is better with multiple disks). I cannot confirm the numbers above will function for you with adequate performance, not having tried this scheme myself, but the core idea of merging somewhat-orthogonal nodes to be parsimonious with vCpu&ram may give you enough traction to get where you want to go.

p.s. See also, semi-official helpdocs for OpenStack in one physical node with one VM, plus the more relevant OpenStack on a dedicated box tutorial, at devstack.org

guest29385283
  • 1