Red Hat OpenStack Platform Architecture

Red Hat OpenStack Platform, IaaS cloud is implemented as a collection of interacting services that control compute storage and networking resources. The cloud can be managed with a web-based dashboard or command-line clients that allow administrators to control provision and automate OpenStack resources. OpenStack also has an extensive API that is available to all cloud users. OpenStack depends on the underlying Linux on which it runs. Red Hat OpenStack Platform is written in python and tightly integrated with Red Had Enterprise Linux.

OpenStack Components

Block Storage (Cinder)

• Enables block storage in instances (persistent, ephemeral, or both)
• Relies on plug-in and driver architecture:
• Red Hat Ceph Storage
• IBM Storage
• HP 3PAR StoreServ
• EMC
• Comprehensive list of storage integrations

Image Storage (Glance)

• Stores and retrieves disk images and templates
• Supports many image formats — e.g., QCOW2, VMDK, AMI, OVF
• Offers back-end image storage options such as Swift and Red Hat Ceph® Storage

Object Storage (Swift)

• Stores and retrieves arbitrary unstructured data
• Offers object-based interface through RESTful HTTP-based API
• Tolerates faults through replication, self-healing, load-balancing capabilities
• Supports commodity compute and storage solutions

Networking (Neutron)

• Enables networking among running instances
• Provides API for defining, configuring, using networks
• Relies on plug-in architecture for network implementation
• OVN: Open vSwitch-based SDN solution for supplying network services to instances
• Default on Red Hat OpenStack Platform 16 and 15
• Default on previous versions: OVS/ML2
• Integration with third-party vendors:
• Cisco, VMware NSX, Arista, Nuage, Juniper, etc.
• Comprehensive list of networking integrations

Bare-Metal Provisioning (Ironic)

• Originated from Nova’s bare-metal driver
• Integrates with Red Hat OpenStack Platform services
• Makes physical servers as easy to provision as virtual machines in the cloud
• With plug-ins, functions as bare-metal hypervisor API
• Default: Turns machines on or off with PXE and IPMI
• Supports vendor-specific plug-ins

Dashboard (Horizon)

• Web-based self-service portal
• Sits on top of other OpenStack components through APIs
• Features a subset of underlying capabilities:
• Create instances
• Configure networks
• Attach block storage
• Contains administrative extension for basic tasks — e.g., create users and projects

Telemetry (Ceilometer)

• Acts as a central repository for metering and monitoring data
• Primarily for resource chargebacks
• Consumes data from other components through agents
• Employs extensible architecture
• Works with Orchestration service to invoke auto-scale processes

Shared File System (Manila)

• Provides shared file systems that Compute instances can use
• Basic resources offered:
• Shares
• Snapshots
• Share networks

Orchestration (Heat)

• Facilitates defining and importing application stacks composed of various resources
• Creates stacks defined by a text file using descriptive language and provided templates
• Manages automated orchestration of resources and dependencies
• Supports dynamic scaling of applications according to configurable metrics

Key Manager (Barbican)

• Provides secure storage, provisioning, management of secret data
• Data includes keying material such as symmetric keys, asymmetric keys, certificates, raw binary data
• Examples:
• Encryption keys for project’s encrypted Cinder volumes
• Signing keys for project’s Glance images
• Barbican has multiple pluggable back-ends
• Can communicate with software- and hardware-based security modules using PKCS#11 or KMIP

Load Balancing (Octavia)

• Open source, operator-scale load-balancing solution designed to work with OpenStack
• Born out of Neutron LBaaS project
• Starting with OpenStack Liberty release (RHOSP 8), Octavia became reference implementation for Neutron LBaaS version 2
• Uses a set of instances on Compute node called amphorae
• Communicates with amphorae over load-balancing management network (lb-mgmt-net)

Deployment and Management (TripleO/Director)

• Install, upgrade, operate OpenStack clouds on top of OpenStack cloud facilities
• Manages life cycles, expedites releases, increases transparency of operations
• Concept of undercloud that installs overcloud on production Red Hat OpenStack Platform infrastructures
• High availability through installer by minimizing or avoiding complex or inconsistent manual configuration steps

Component Relationships

How do the OpenStack components interact?

Horizon can be considered component one if a user starts the process from it. After a user asks to deploy an instance a requested sent to keystone component two. After keystone validates the user credentials, glance component six provides the right image for provisioning the instance.
That images loaded into an instance by nova component five, which asks neutron component three to provide the requested networking.
Nova also asked cinder component four, to provide any persistent volumes, volume backups, shared storage, and swift objects storage component seven.
If orchestration is used heat component nine performs any needed customization of the instance. Ceilometer component eight monitors the system components and provides cloud usage data. Depending on the configuration heat may initiate various operations based on
data collected by ceilometer. The process then loops back to horizon where the user interacts with the instances.

Common Ports

See other content

References :

• https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html-single/quick_start_guide/index#prerequisites
• https://egallen.com/openstack-15-standalone/

#RHEL8 #RedHat #OpenStack #RedHatOpenStackPlatform #StayHealth