I’m trying to setup a three node mysql-innodb-cluster on a maas-deployment using juju.
The setup process worked flawlessly and the deployment of other charms worked fine. When deploying the cluster I would like to achieve that in separate lxd-container. But that doesn’t work. I get the error:
Did I miss some critical configuration step here?
Can you provide some more info?
Yes of course! Problem appeared with
I didn’t install LXD myself. Just deployed the charm using the command juju deploy -n 3 --to lxd:0,lxd:1,lxd:2 mysql-innodb-cluster . Where do I find the version for the lxd snap juju uses when deploying?
Many thanks in advice!
I have the same problem when deploying Openstack-Charmed.
Charm mysql-innodb-cluster never installs. Despite testing several times, which blocks the full deployment of Openstack.
The error is actually coming from here.
That would tend to indicate that out of 100 random 10.x.x.1/24 subnets, LXD can’t find one that both is not in the routing table and has no detectable hosts.
It is attempting to do this when initialising LXD and setting up the default bridge.
Can you shed any further light on your network set-up?
That’s interesting! Read about this error before and yes. The subnet managed by maas and where the machines live juju is asked to deploy charms on is a 10.0.0.0/8 network.
So how would a solution to that problem look like? Managed to get lxd working on my machine yesterday by manually setting an ip from that network. But I think that’s not the way to go using juju isn’t it?
So declaring a subnet as 10.0.0.0/8 means that you would have a broadcast domain of 16M devices, which is not something that generally works. (Scale testing that I’ve seen in the past said that broadcast domains above 4k or so start to break down heavily as the layer 2 ARP traffic starts to dominate the actual bytes on the wire.)
It would be good to understand why you feel you need to use that as your subnet, as it generally wouldn’t work very well as a real subnet.
You’re absolutely right.
I’m new to whole cloud computing and architecture area and my driving point for using such a big subnet were the following questions:
After discovering maas and the information I had gathered until this point, it seemed to me that the management tasks are abstracted to a higher level, new machines are booted using pxe, get a dynamic ip assigned via DHCP and the mapping is done by the dns maas is providing, as well as the os. So which network range should I use to have the possibility to add as many machines I want in the future? And my answer to that question was: 10.0.0.0/8
Hope that makes my point clear for that choice!
So I wouldn’t be surprised to have a Space that conceptually is 10.0.0.0/8 but would then be carving that into usable subnets like 10.0.1.0/24 for a given rack, room, etc.
The whole point of spaces is to give you a way to logically group subnets, that have physical constraints on how they can be configured, but have a logical identity that is shared.
Okay, thanks that sounds great! So, let’s say you have 3000 machines where openstack gets deployed on. How would you arrange those machines in spaces to take fully advantages of performances and organization? Within the 10.0.1.0/24, you could place round about 250 nodes. But the other ones serve the same purpose. What would your solution look like with spaces in that case?
Typically you would carve out a set of racks that then use a single subnet. So the first rack might be 10.0.0.0/24, and then the second rack would be 10.0.1.0/24 and so on. That limits the broadcast domain for each subnet to just the local machines. However, you would then configure MAAS to treat all of those subnets as the same “space”. And then when deploying with Juju, you would bind a given application to that space. And Juju would know to provision one of the machines from one of the subnets, and configure the applications to use the local subnet for communication.
You would also set up the switch on each rack to route traffic from the local subnet to the other similar subnets.
Sry for the delay.
That sounds amazing, I’ll give it a try asap! One last question about juju in general: let’s say a physical node fails and is needed to be replaced. How is it possible to tell juju to re-deploy the specific model to those replaced node?
So, I updated my current network configuration: the router which is providing internet access manages a 10.0.0.0/24 network.
Within this network the maas region controller is setup. For the first rack, I created a subnet 10.0.1.0/24 and added those one to the distinct rack controller. But now I’ve got the following problem trying to understand this architecture: where does the rack controller get it’s IP address from?
Is the rack controller part of the 10.0.0.0/24 or 10.0.1.0/24 network. Sry for those confusing questions!
I would think the rack controller would participate in the local network (10.0.1.0/24). It also needs a route to the region controller, so depending on your actual networking it may need a second network device in 10.0.0.0/24 or it might be a route defined to the region controller.
These are all probably better asked and answered in the MAAS discourse: https://discourse.maas.io/
