Welcome to the OpenStack Services module. By the end of this module, you should be able to describe OpenStack and its services. Cloud management tools build and manage cloud infrastructure through services, providing a shared pool of compute, storage, and network solutions with automation, resiliency, and security controls. OpenStack is an open-source cloud management system that controls large pools of compute, storage, and networking resources by managing and provisioning them through APIs. It creates both public and private clouds. It also provides additional components for orchestration, fault management, and service management. Resources can be deployed using built-in tools such as OpenStack SDK and Horizon Web UI, or through third-party services such as Kubernetes. It integrates with software_defined networking (or SDN) controllers for centralized management and programability of OpenStack networking. OpenStack is made of services that can be plugged into by different components. The diagram displayed depicts the OpenStack services as listed on the OpenStack website. You can access this website from the Reference Links document. Nova service provisions compute instances such as virtual machines and bare metal servers and has limited support for containers. It runs as a set of daemons on Linux servers and requires Keystone, Glance, Neutron, and Placement services for basic functions. Multiple hypervisors are supported such as kernel- based virtual machine (or KVM), Hyper-V, and vSphere. The components of Nova architecture are: DB— it is the SQL database for data storage. API—it is the component that receives HTTP requests, converts commands, and communicates with other components through the oslo.messaging queue or HTTP. Scheduler—it determines which host gets each instance. Network—it manages IP forwarding, bridges, and VLANs. Compute—it manages communication with hypervisor and virtual machines. Conductor—it handles requests that need coordination (build or resize) acts as a database proxy, or handles object conversions. A parallel service for containers is the Zun service which provides OpenStack API for creating and managing containers and requires Keystone, Neutron, and Kuryr services for basic functions. Neutron provides network connectivity as a service between interface devices managed by other OpenStack services. It implements the OpenStack networking API and requires Keystone service for basic functions. The OpenStack networking components are: Neutron server and Neutron plug-in— This service runs on the network node to service the networking API and its extensions. It also enforces the network model and IP addressing of each port. The Neutron server requires indirect access to a persistent database. This is accomplished through plug-ins which communicate with the database using the Advanced Message Queuing Protocol (or AMQP). Plug-in agent or Neutron agent— It runs on each compute node to manage the local virtual switch (or vSwitch) configuration. The plug-in that you use determines which agents run. This service requires message queue access and depends on the plug-in used. DHCP agent or Neutron DHCP agent— It provides Dynamic Host Configuration Protocol (or DHCP) services to tenant networks. This agent is the same across all plug-ins and maintains DHCP configuration. The Neutron DHCP agent requires message queue access. It is an optional service depending on the plug-in. L3 agent or Neutron L3 agent— It provides Layer 3 (or L3) or Network Address Translation (or NAT) forwarding for external network access of virtual machines on tenant networks. It requires message queue access. It is an optional service depending on plug-in. Network provider services or SDN server or services— They provide additional networking services to tenant networks. These SDN services may interact with Neutron server, Neutron plug-in, and plug-in agents through communication channels such as Representational State Transfer (or REST APIs). Neutron has two kinds of plug-ins. Core plug-ins— They implement the core API of the Neutron, which comprises networking building blocks such as port, subnet, and network. Service plugins— They implement the Neutron API extensions, such as L3 router and Layer 4 through Layer 7 (or L4 to L7) services, such as firewall as a service, load balancer as a service, and VPN as a service. Cinder is the Block Storage service for OpenStack. It virtualizes the management of block storage devices and abstracts actual storage deployment and device type. It requires Keystone service for basic functions. Cinder provides snapshot management and volume cloning capabilities. Cinder components include: DB—It is the SQL database used for data storage. This is used by all components. Note that the links are not shown here. Web dashboard— it is the potential external component that communicates with the API. API—it is the component that receives HTTP requests, converts commands, and communicates with other components through the queue or HTTP. Auth Manager— It is the component responsible for users, projects, and roles. It can be the backend to DB or Lightweight Directory Access Protocol (or LDAP). This is not a separate binary but rather a Python class that is used by most components in the system. Scheduler—it determines which host gets each volume. Volume—it manages dynamically attachable block devices. Backup—it manages backups of block storage devices. Swift is a highly available distributed and consistent object or blob store. It stores data efficiently, safely, and cheaply. It is ideal for storing unstructured data such as backups, video, pictures, and user-generated data. The Swift proxy server ties the rest of the Swift architecture. The Ironic bare-metal service provisions bare-metal servers by managing hardware through remote management protocols. It integrates with Keystone, Nova, Neutron, Glance, and Swift services. A user's request to boot an instance is passed to the compute service through the compute API and the compute scheduler. The compute service uses the Ironic virt driver to hand over this request to the bare-metal service where the request passes from the bare-metal API, to the Conductor, and then to a driver to successfully provision a physical server for the user. Keystone service provides API client authentication, service discovery, and distributed multitenant authorization. It implements OpenStack's identity API and supports LDAP, OAuth, OpenID Connect, Security Assertion Markup Language (or SAML) and SQL. It provides services to all OpenStack services for their basic functioning. The services include: Identity— The Identity service provides auth credential validation and data about users and groups. Resource— The Resource service provides data about projects and domains. Assignment— The Assignment service provides data about roles and role assignments. Token— The Token service validates and manages tokens used for authenticating requests once a user's credentials have already been verified. Catalog— The Catalog service provides an endpoint registry used for endpoint discovery. Policy— The Policy service provides a rule-based authorization engine and the associated rule management interface. The example displayed illustrates how the Token service works. Glance provides image services including discovering, registering, and retrieving virtual machine images. It uses RESTful API to query virtual machine image metadata and the retrieval of the actual image. Glance images are stored across multiple storage types and file systems. It requires Keystone service for basic functions. The components present in the Glance architecture are: A client— it could be any application that makes use of a Glance server. Rest API—Glance functionalities are exposed through REST. Database Abstraction Layer (or DAL)— It is an API that unifies the communication between Glance and databases. Glance Domain Controller— It is the middleware that implements the main Glance functionalities such as authorization, notifications, policies, and database connections. Glance Store— It is used to organize interactions between Glance and various data stores. Heat orchestrates the infrastructure resources for a cloud application based on templates as text files that can be treated like code. It also provides auto-scaling services and requires Keystone service for basic functions. Heat service components include: Heat template— It is a YAML Ain't Markup Language (or YAML) file that defines resources. Heat API component— An OpenStack native REST API that processes API requests by sending them to the heat engine over remote procedure call (or RPC). Heat engine—orchestrates the launching of templates and provides events back to the API consumer. Ceilometer is a service to efficiently collect, normalize, and transform data produced by OpenStack services. Data collected provides different views and telemetry use cases, such as billing, monitoring, and troubleshooting. Ceilometer offers two core services: Polling agent— It is a daemon designed to pull OpenStack services and build meters. Notification agent— It is a daemon designed to listen to notifications on message queue, convert them to Events and Samples, and apply pipeline actions. Horizon is a canonical implementation of OpenStack's dashboard that provides a Web-based interface to OpenStack services. It has out-of-the-box support for all OpenStack projects. It is extensible, manageable, consistent, stable, and usable. OpenStack client (or OSC), is a CLI for all OpenStack services with a uniform set and format. It contains a command set for Compute, Identity, Image, Object Storage, and Block Storage APIs in a single shell. OpenStack SDK is a multicloud-aware Python SDK for OpenStack REST API. Ceph Storage is an open-source software that provides block, object, and file storage. It integrates with OpenStack services. Ceph storage uses standard servers and disks, scaled-out architecture, Reliable Automatic Distributed Object Store (or RADOS), LIBRADOS to access RADOS. The relationship map between various OpenStack services is displayed. Note that only the key services have been listed for simplicity. The minimal production architecture for OpenStack deployment is displayed. Controller node runs the identity service, image service, placement service, management portions of computer networking, various networking plug-ins and agents instead of a dedicated network node, and the dashboard. It also includes the SQL database, message queue, and Network Time Protocol (or NTP) services. It needs a minimum of two network interfaces. Compute node runs the hypervisor for compute instances, which by default is KVM. Compute node also runs the networking agent that connects instances to virtual networks and provides firewall services using security groups. Typically, more than one compute nodes are deployed. Each node requires a minimum of two network interfaces. Block Storage node contains the disks that the Block Storage and File System services provision for instances. This component can also reside on the Controller node. Production environments implement a separate storage network to increase performance and security. Object Storage node contains the disks that the Object Storage service uses for storing accounts, containers, and objects.