After completing this section, you should be able to describe the purpose, resources, and terminology of the Red Hat OpenStack Platform core services.
Red Hat OpenStack Platform is implemented as a collection of interacting services that control compute, storage, and networking resources. The following diagram provides a high-level overview of the OpenStack core services.
The following services are covered in this course:
The Block Storage service manages storage volumes for virtual machines. This includes both ephemeral and persistent block storage for instances running in the Compute service. You can take snapshots for backing up data, either for restoring data or to create new block storage volumes.
The Image service acts as a registry for virtual machine images, allowing users to copy server images for immediate storage. These images can be used as templates when setting up new instances.
The Orchestration service orchestrates multiple composite cloud applications using the Amazon Web Services (AWS) CloudFormation template format, through both a Representational State Transfer (REST) API and a CloudFormation-compatible Query API.
The Dashboard is a browser-based interface for managing OpenStack services, providing a graphical interface for launching instances, managing networking, and setting access controls.
The Bare Metal Provisioning service enables you to provision physical hardware as opposed to virtual machines. It provides several drivers, such as PXE and IPMI, to cover a wide range of hardware. It also supports vendor-specific drivers.
The Identity service provides authentication and authorization to all OpenStack services. This service is responsible for creating and managing users, domains, roles, and projects. This service provides a central catalog of other services and associated endpoints available in an OpenStack cloud. It supports multiple forms of authentication, including user name and password, token-based, and Amazon Web Services (AWS) logins. The Identity service acts as a single sign-on (SSO) authentication service for users and components.
A domain defines the administrative boundaries of Identity service entities. A domain consists of one or more projects, users, and groups. In a multitenant cloud, you can set up multiple identity providers and associate each one with a separate domain. You cannot share resources across domains. Neither can you move resources from one domain to another; you need to recreate them in the new domain.
The OpenStack Networking service is a software-defined networking (SDN) service that helps to create networks, subnets, routers, and floating IP addresses. Users can create and attach interface devices to instances and routers. Administrators can define a gateway for a router to allow external access. OpenStack networking ships with plug-ins and agents for Cisco virtual and physical switches, Open vSwitch, OVN, and others. The common agents are L3 and DHCP (which provides DHCP IP addresses to instances). OpenStack networking enables projects to create advanced virtual network topologies including entities such as firewalls, load balancers, and virtual private networks (VPNs).
The Compute service manages instances (virtual machines) running on nodes, providing virtual machines on demand. It is a distributed service and interacts with the Identity service for authentication, the Image service for images, and the Dashboard. The Compute service is designed to scale out horizontally on standard hardware, downloading images to launch instances as required. The Compute service uses libvirtd, qemu, and kvm for the hypervisor.
The Object Store provides object storage that allows users to store and retrieve files. The Object Store architecture is distributed to allow for horizontal scaling and to provide redundancy.
One use case for the Object Store is that it can act as a storage back end for images. This allows OpenStack to replicate images and snapshots across the Object Store infrastructure. This solution is useful as a backup, because it can store the images and instances on different physical servers.
The Placement service tracks cloud resource inventories and usage to help other services effectively manage and allocate their resources.
Not all of the following additional services are covered in this course, but they are all supported by Red Hat:
Red Hat Ceph Storage is a distributed data object store designed to provide excellent performance, reliability, and scalability. It integrates with OpenStack services such as the Compute Service, Block Storage, Shared file systems, the Image service, the Identity service, and the Object store to give more flexibility storing images and volumes and when operating at scale.
The service provides production-ready containers and deployment tools for operating OpenStack clouds that are scalable, reliable, and upgradable.
The Shared file systems service is a file share as a service. It uses the NFS and CIFS protocols for sharing file systems. It can be configured to run on a single-node back end or across multiple nodes.
This service was designed to create a stand-alone load-balancing component, to replace the original networking server (Neutron) LBaaS project which was based on HAProxy. The new service delivers load balancing services managed as virtual machines, containers, or bare-metal servers (collectively known as amphorae) which are spun up on demand, providing stronger horizontal scaling.
The Deployment service code handles installing, upgrading, and operating OpenStack clouds using OpenStack's own services as the foundation. It uses Compute, Networking, and Orchestration services, and other orchestration tools, such as Puppet and Ansible, to automate fleet management, including scaling out and scaling back at data center scale.
A typical OpenStack installation consists of many internal services running on multiple machines. These services have traditionally been Linux system services, which can be difficult to deploy, maintain, and operate as redundant, load-balanced, resilient services. The introduction of containers in the Infrastructure-as-a-Service (IaaS) level improved deployment, maintenance, and operation of those services.
Gathering accurate information quickly for OpenStack services is key to maintaining a stable and productive environment.
OpenStack implements each of its service as a collection of containers running on the servers. OpenStack now uses Podman as its container implementation, and administrators use the podman and systemctl commands to manage and monitor the running containers.
Red Hat OpenStack Platform still provides the openstack-status and the openstack-service commands in an OpenStack developer tools repository but no longer provides support for these unmaintained commands. Now that virtually all OpenStack services are containerized, services must be managed with container system tools instead.
The podman ps command lists the running containers on the local node.
[root@controller ~]# podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f83f156d3643 director.ctlplane.localdomain:8787/rhosp-rhel8/openstack-manila-share:16.0-95 /bin/bash /usr/lo... 4 hours ago Up 4 hours ago openstack-manila-share-podman-0
eb4d6e36a91b director.ctlplane.localdomain:8787/rhosp-rhel8/openstack-redis:16.0-98 /bin/bash /usr/lo... 4 hours ago Up 4 hours ago redis-bundle-podman-0
099ea36b35ee director.ctlplane.localdomain:8787/rhosp-rhel8/openstack-ovn-northd:16.0-95 /bin/bash /usr/lo... 4 hours ago Up 4 hours ago ovn-dbs-bundle-podman-0
459800071ff2 director.ctlplane.localdomain:8787/rhosp-rhel8/openstack-haproxy:16.0-101 /bin/bash /usr/lo... 4 hours ago Up 4 hours ago haproxy-bundle-podman-0
51cbabf23118 director.ctlplane.localdomain:8787/rhosp-rhel8/openstack-mariadb:16.0-101 /bin/bash /usr/lo... 4 hours ago Up 4 hours ago galera-bundle-podman-0
9b93b9da46f6 director.ctlplane.localdomain:8787/rhosp-rhel8/openstack-rabbitmq:16.0-101 /bin/bash /usr/lo... 4 hours ago Up 4 hours ago rabbitmq-bundle-podman-0
ffbaa43d0347 director.ctlplane.localdomain:8787/rhosp-rhel8/openstack-cinder-volume:16.0-90 /bin/bash /usr/lo... 4 hours ago Up 4 hours ago openstack-cinder-volume-podman-0
01f56ff6dc53 director.ctlplane.localdomain:8787/rhceph/rhceph-4-rhel8:4-20 4 hours ago Up 4 hours ago ceph-mds-controller0
3c0649395ab6 director.ctlplane.localdomain:8787/rhceph/rhceph-4-rhel8:4-20 4 hours ago Up 4 hours ago ceph-mon-controller0
7fa038b3592d director.ctlplane.localdomain:8787/rhosp-rhel8/openstack-octavia-worker:16.0-94 kolla_start 12 days ago Up 4 hours ago octavia_worker
...output omitted...Note that the podman command only displays results to the root user.
For better readability, you can select the columns to display with the --format option and use the grep command to limit the output to a specific service. The following example only displays the container names for the Compute service.
[root@controller ~]# podman ps --format="{{.Names}}" | grep nova
nova_api_cron
nova_metadata
nova_api
nova_vnc_proxy
nova_scheduler
nova_conductorThe argument provided with the --format option is a JSON or Go template. Valid placeholders are documented in the podman-ps(1) man page.
Typically, an OpenStack service has several component containers associated with it. The previous output shows that the Compute Service has an API container, nova_api, to manage the API requests, plus additional components including a scheduler and a metadata server.
These internal components communicate with each other through a message queue provided by the RabbitMQ software. Additionally, a Galera MySQL database server persistently stores the data for the OpenStack services. OpenStack also uses containers for all of these support services.
[root@controller ~]# podman ps --format="{{.Names}}" | grep -e rabbitmq -e galera
galera-bundle-podman-0
rabbitmq-bundle-podman-0The podman ps command only displays the running containers. To list the failed and stopped containers, you can use the --all (or -a) option.
[root@controller ~]# podman ps -a --format="table {{.Names}} {{.Status}}"
Names Status
openstack-manila-share-podman-0 Up 5 hours ago
redis-bundle-podman-0 Up 5 hours ago
ovn-dbs-bundle-podman-0 Up 5 hours ago
haproxy-bundle-podman-0 Up 5 hours ago
galera-bundle-podman-0 Up 5 hours ago
rabbitmq-bundle-podman-0 Up 5 hours ago
openstack-cinder-volume-podman-0 Up 5 hours ago
ceph-mds-controller0 Up 5 hours ago
ceph-mon-controller0 Up 5 hours ago
octavia_worker Up 5 hours ago
octavia_housekeeping Up 5 hours ago
octavia_health_manager Up 5 hours ago
manila_share_init_bundle Exited (0) 12 days ago
cinder_volume_init_bundle Exited (0) 12 days ago
manila_share_restart_bundle Exited (0) 12 days ago
...output omitted...Podman does not have a daemon to ensure containers are started, so it uses systemd services to manage each container. The service names all follow the format tripleo_. Many OpenStack services also have a service to monitor the container, with the name in the format service-name.servicetripleo_:service-name_healthcheck.service
tripleo_placement_api.service loaded active running placement_api container tripleo_placement_api_healthcheck.service loaded inactive dead placement_api healthcheck
Further information is available in the Components section of the Product Guide for Red Hat OpenStack Platform at https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html-single/product_guide/index
Further information is available in the Starting with Containers section of the Building, Running, and Managing Containers guide for Red Hat Enterprise Linux 8 at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/building_running_and_managing_containers/index