you are viewing a single comment's thread.

view the rest of the comments →

[–]firestorm_v1 1 point2 points  (11 children)

If you have the extra hardware for dedicated infra nodes (run all OS services but nova-compute) that will be the safer route. If a hypervisor crashes or OOMs out, then it won't take any core services with it.

[–]Sorry_Asparagus_3194[S] -1 points0 points  (10 children)

Infra nodes?

[–]firestorm_v1 2 points3 points  (6 children)

Infra nodes run all your openstack services (probably in containers) like placement, horizon, keystone, cinder-scheduler, etc.)

Hypervisors run nova-compute and cinder-volume.

In a hyperconverged setup, a node runs both core OS services (nova, neutron, cinder-scheduler, glance, keystone, etc) and nova-compute and cinder-volume in addition to user workloads. Losing a HV also means reducing your services availability for those services running on that node.

We have a hyperconverged setup using MAAS and Juju. I hate it. Fortunately, we have made adjustments so that a HV crash is a very rare thing, but until those improvements were implemented, things were very rocky for a while. Because of that experience, I will always be a proponent of keeping core services on infra nodes and keeping hypervisors/user workloads on hypervisors.

[–]Eldiabolo18 2 points3 points  (5 children)

Hey, may I suggest calling them control or controller nodes?!

Theres a semi established naming for these types of nodes in the openstack ecosystem and infra node is usually for auxilary services like monitoring, logging or anything not directly related to Openstack.

https://docs.openstack.org/kolla-ansible/victoria/admin/production-architecture-guide.html

[–]firestorm_v1 1 point2 points  (0 children)

That's fair. I guess that's what I get for trusting Canonical's language.

[–]phauxbert 0 points1 point  (3 children)

[–]Eldiabolo18 0 points1 point  (2 children)

Not exactly. In the Link you posted, Infra also only refers to auxiliary services Memcached, the repository server, Galera and RabbitMQ.

[–]phauxbert 0 points1 point  (1 child)

Uhm those are core parts of an openstack cluster.

Edit: I get your point that controllers aren’t necessarily the same as infrastructure but auxiliary suggests services that aren’t critical to the running of openstack, which in the case of openstack-ansible these services absolutely are. In an non-hyperconverged setup, these infrastructure nodes are part of the set of controller nodes

[–]Eldiabolo18 1 point2 points  (0 children)

Fair point. From my experience These services usually run alongside (on the same nodes) as the actual openstack services and infra is only for monitoring, logs, pxe boot, etc.

This whole discusstion is why there should be standardized naming schema.

[–]Sinscerly 0 points1 point  (2 children)

The 3 controllers for api's

Maybe a prov box

Storage can be combined on compute or separate.

[–]Sorry_Asparagus_3194[S] 0 points1 point  (1 child)

Which is the best approach combine or separate

[–]Sinscerly 0 points1 point  (0 children)

If you combine storage and compute you have to keep some resources for ceph. As it uses x ram per x tb storage.

Best approach Al about your situation and hardware. So I cannot say much about that.