clara | Hi | 09:49 |
---|---|---|
clara | Considering controllers and computes, does it mean the control panel is completely apart from the data plane in an OpenStack cluster? | 09:50 |
clara | As a following question, what happens for instances and north-south traffics if we lose all controllers for hours? | 09:51 |
clara | jamesdenton_: I recall that a few months ago you mentioned a conversation with the OVN team that they recommended keeping the network nodes separate from the controller nodes. Is this my memory correct? | 12:18 |
clara | Now, what is your opinion on whether the network nodes be the same as the controller nodes or be separate? | 12:20 |
jrosser | clara: you can split it however you like | 12:24 |
jrosser | the most common deployment is to have the network nodes and controllers be the same hosts | 12:24 |
jrosser | but that is totally defined by how you set up your OSA inventory | 12:25 |
clara | I'm looking for the best practices; I mean I want to follow your experience and knowledge instead of relying on architecting it by myself | 12:25 |
jrosser | well personally inhVe separate network nodes | 12:25 |
jrosser | argh | 12:26 |
jrosser | separate | 12:26 |
jrosser | but that’s for a lot of reasons | 12:26 |
jrosser | to be able to scale them independently, to have the minimum surface area with external internet connectivity, to reduce the number of things being touched when doing operating system upgrades etc etc | 12:27 |
jrosser | but doing it like that does require more hardware and a switch ports and cost, so ultimately depends what your priority is | 12:28 |
clara | Would it be simple/possible to separate them later if I put controller stuff and network on the same nodes? | 12:29 |
clara | you don't recommend VMs as hosts for controllers and network nodes, do you? | 12:30 |
jrosser | on some other platform like VMware or proxmox? | 12:30 |
clara | yes, on proxmox | 12:31 |
jrosser | really the only time we see that is when people use vm like that for test environments | 12:31 |
jrosser | and even then it causes mountains of trouble | 12:31 |
jrosser | typically, you have to really understand both proxmox and openstack networking in some depth to be able to put one inside the other | 12:32 |
jrosser | it can be done, but I’d call it “advanced” use | 12:35 |
jrosser | a bunch of this kind of depends on the environment too, if the public network is external internet the you have a different set of risk to mitigate vs some internal trusted network | 12:36 |
jrosser | and that in turn leads to architectural decisions | 12:36 |
clara | jrosser: Thanks | 13:04 |
clara | If all the controller nodes go down, will this affect the connectivity of the instances on the computes to the Internet? | 13:05 |
clara | My answer is that there should be no problem for instances because I expect the data plane and the control plane to work independently. | 13:05 |
jrosser | clara: if you col-locate the network nodes for Linux bridge or OVS, or if with OVN you make the controllers be gateway nodes rather than the computes, then yes you will have connectivity trouble if all controllers go down | 13:41 |
jrosser | and that’s another thing to look into, what you can make be a gateway node for OVN as that is potentially quite different to all north/south traffic having to go via dedicated network nodes | 13:43 |
clara | jrosser: Then implementing DVR does not have any role here? You mean in case of OVN stack, by gateways on computes without DVR, the external network does not affected, right? What about the traffic from VM1 on compute1 to the VM2 on the other compue? | 13:45 |
jrosser | well DVR is maybe not the right term | 13:46 |
jrosser | that has specific meaning for OVS | 13:46 |
jrosser | you can have a distributed gateway in OVN | 13:46 |
clara | I'm asking that question to see if I setup infra with single controller, what are the risks | 13:48 |
jrosser | putting the network aside you should be concerned about how you maintain uptime of the openstack api | 13:49 |
jrosser | and how you deal with some catastrophic failure of the infra node for the database contents | 13:50 |
jrosser | from a longer term perspective it’s very handy to be able to completely clear out and reinstall an infra node, particularly at the time you want to do an operating system upgrade, or perhaps recover from totally failed disks | 13:55 |
jrosser | a single infra node is really only ok if you’re happy to lose absolutely everything in some disaster | 13:55 |
clara | +1 | 14:27 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!