Unit 1

Introduction to OpenStack
Architecture and Component Overview
OpenStack is an open-source cloud computing platform that enables the creation, management, and
operation of cloud environments, offering services similar to those provided by public cloud providers like
AWS, Microsoft Azure, or Google Cloud. It supports Infrastructure-as-a-Service (IaaS), allowing users to
manage and provision computing, storage, and networking resources in a virtualized environment.

Key Features of OpenStack

1. Open-Source
o Free to use, modify, and distribute. It has a large and active global community.
2. Modularity
o Composed of independent but interrelated components (services) that can be deployed
together or separately depending on user needs.
3. Flexibility
o Supports private, public, and hybrid cloud models.
4. Scalability
o Can handle small-scale to large-scale deployments, scaling resources up or down based on
demand.
5. Interoperability
o Compatible with a wide range of hardware and software environments.
6. Automation
o Automates resource provisioning, deployment, and scaling, reducing manual effort.

Core components of OpenStack

1. Keystone (Identity Service)

2. Nova (Compute Service)

3. Neutron (Networking service)

4. Glance (Image Service)

5. Cinder (block Storage Service)

6. Swift (Object Storage Service)

7. Horizon (Dashboard)

8. Heat (Orchestration Service)

9. Ceilometers (Telemetry Service)

Benefits of Using OpenStack

 Cost-Effective: No licensing fees.

 Customizable: Tailored to meet specific organizational needs.
 Vendor Neutral: Works with a variety of hardware and hypervisors.
  Community Support: Backed by a large, collaborative global community.

Use Cases of OpenStack

1. Private Cloud Deployment: Organizations can use OpenStack to build private clouds for better
control over data and resources.
2. Development and Testing Environments: Ideal for creating isolated environments for developers.
3. High-Performance Computing (HPC): Supports large-scale compute-intensive tasks.
4. Hybrid Cloud: Combines private OpenStack clouds with public clouds for seamless operations.

OpenStack Architecture and Component Overview

OpenStack follows a modular architecture comprising (include) various services, each designed to handle
specific functions such as compute, storage, networking, and orchestration. These services work together to
create a complete cloud environment that supports Infrastructure-as-a-Service (IaaS).

High-Level OpenStack Architecture

1. Core Components
o These handle primary cloud operations such as provisioning, networking, and storage.
2. Supportive Components
o Services that provide additional functionalities like orchestration, monitoring, and
authentication.
3. Users/Clients
o Interact with OpenStack via the dashboard, command-line interface (CLI), or APIs.

Browser Program

Horizon Rest API

………………………………………………………………………………………………………………………………………………………
Network

Neutron
………………………………………………………………………………………………………………………………………………………
Ceilometer

….. Linux
VM
windos
Keystone

Nova Glance
heat

……………………………………………………………………………………………………………………………………...………………
………… Storage
Cinder

Swift
Core Components of OpenStack

1. Keystone (Identity Service)

 Manages authentication and authorization for users and services.

 Provides a central directory of users mapped to the services they can access.

Key Features:

 Multi-tenant support.
 Service catalog for endpoint discovery.

2. Nova (Compute Service)

 Handles provisioning and management of virtual machine instances.

 Works with hypervisors like KVM, VMware, or XenServer.

Key Features:

 Manages VM lifecycle: creation, resizing, and termination.

 Supports different instance types (flavors).

3. Neutron (Networking Service)

 Manages network connectivity for instances.

 Provides APIs to define and manage networks, subnets, and routers.

Key Features:

 Configures virtual networks.

 Supports load balancing, firewalls, and VPNs.

4. Glance (Image Service)

 Stores and retrieves disk images used to launch instances.

 Acts as a catalog for available VM images.

Key Features:

 Supports multiple image formats (e.g., RAW, VHD, ISO).

 Allows image sharing between users.

5. Cinder (Block Storage Service)

 Provides persistent block storage to instances.

 Allows attaching/detaching volumes dynamically.

Key Features:

 Offers high-performance storage options.

 Snapshots for backups.

6. Swift (Object Storage Service)

 Manages unstructured data (e.g., files, media) as objects.

  Ensures data replication for redundancy.

Key Features:

 Scalable to petabytes of data.

 Provides storage accessible via HTTP.

7. Horizon (Dashboard)

 A web-based user interface for managing OpenStack services.

Key Features:

 Intuitive interface for non-technical users.

 Supports role-based access control.

8. Heat (Orchestration Service)

 Automates the deployment of resources using templates.

Key Features:

 AWS CloudFormation-compatible templates.

 Supports multi-tier application stacks.

9. Ceilometer (Telemetry Service)

 Monitors and collects data on resource usage.

Key Features:

 Provides data for billing and performance monitoring.

 Integrates with monitoring tools.

RDO Installation
What is RDO?

RDO is a community-supported distribution of OpenStack that is designed to provide an easy way for
users to deploy and manage OpenStack on their own hardware. It is essentially a free and open-source
version of OpenStack, designed to be installed using the RDO packstack installer, making it easier to set up
OpenStack environments on your machines.

Key Points about RDO:

1. OpenStack Distribution:
o RDO is based on Red Hat OpenStack Platform and is supported by Red Hat and CentOS (and other
RHEL-based distributions like Fedora).
 o It aims to be a simple and flexible way for developers and enthusiasts to experiment with
OpenStack, particularly for those who want to test and deploy OpenStack in a production-like
environment without the cost of a full enterprise solution.
2. Installation with Packstack:
o RDO simplifies the OpenStack installation process through Packstack—an installer that uses Puppet
modules to automate the configuration and setup of OpenStack services.
o Packstack can deploy a multi-node OpenStack environment, or even a single-node environment for
testing and development.
3. Supported by the Community:
o RDO is supported by a community of developers, users, and contributors, including contributors
from Red Hat, CentOS, and Fedora.
o It provides support for various OpenStack services such as Nova (compute), Neutron (networking),
Cinder (storage), Keystone (identity), and others.
4. Ecosystem Compatibility:
o RDO works well with CentOS, Fedora, and Red Hat Enterprise Linux (RHEL). It also allows you to
integrate other tools and services from the Red Hat ecosystem for enterprise-level management and
orchestration.

Identity Management
What is Keystone?

Keystone is the identity service in OpenStack that provides authentication, authorization, and service
discovery. It ensures secure access to OpenStack resources by managing users, roles, projects, and
services.

Key Functions of Keystone

User Authentication – Verifies users before granting access.

Authorization – Controls what users can do in OpenStack.
Service Catalog – Provides a list of available OpenStack services.
Token Management – Issues and validates access tokens.
Multi-Tenant Support – Manages multiple users and projects.

Keystone Architecture

Keystone consists of:

1. Identity Backend – Stores users, groups, and roles (SQL, LDAP).
2. Token Service – Issues temporary tokens for authentication.
3. Policy Service – Defines access rules for OpenStack services.
4. Catalog Service – Lists available OpenStack services and their endpoints.

How Keystone Works

1. User sends login request (username + password).

2. Keystone verifies credentials and issues a token.
3. User presents token to access OpenStack services.
4. Keystone validates the token and grants access.

Types of Authentication in Keystone

Auth Type Description
 Auth Type Description

Password Authentication User provides username + password.

Token-based Authentication User receives a token after login.

OAuth Authentication External authentication system.

Kerberos Authentication Secure authentication using Kerberos.

Unit 2
OpenStack Management
Image Management
Glance in OpenStack (Image Management)

What is Glance?

Glance is the image management service in OpenStack that allows users to store, discover, and retrieve
virtual machine (VM) images. It provides a centralized repository for disk images that instances (VMs) can
boot from.

Why is Glance Important?

✔Stores VM disk images.

✔Provides a registry for images.
✔Supports multiple formats (QCOW2, RAW, VMDK, VDI, etc.).
✔Enables image sharing between tenants.
✔Works with different storage backends (Swift, Ceph, NFS).

Key Features of Glance

1. Stores and Serves Images – Provides a repository for VM images.

2. Supports Multiple Formats – QCOW2, RAW, VMDK, VHD, etc.
3. Image Metadata Management – Helps categorize images with properties.
4. Public and Private Images – Users can control image visibility.
5. Integration with Storage Backends – Works with Swift, Ceph, NFS, etc.

How Glance Works?

1. Users Upload Images – Using CLI or Horizon Dashboard.

2. Glance Stores Metadata – In a database (MySQL, PostgreSQL).
3. Images are Stored – In a backend like Swift, Ceph, or local storage.
4. Instances Boot from Images – Nova retrieves the image from Glance.
Glance Architecture

Glance consists of two main components:

1. Glance API

 Provides a RESTful API for image upload, retrieval, and management.

 Handles requests from users or other OpenStack services.

2. Glance Registry

 Stores image metadata such as name, size, format, and checksum.

 Ensures efficient searching and filtering of images.

Glance as a Registry of Images in OpenStack

What is an Image Registry?

A registry is a centralized system that stores and manages virtual machine (VM) images, allowing users to list,
retrieve, and distribute images efficiently. In OpenStack, Glance acts as the image registry, keeping track of available
VM images and their metadata.

How Glance Works as an Image Registry

1. Stores Image Metadata – Keeps details like image name, format, size, OS type, and architecture.
2. Manages Image Versions – Supports updates and different versions of the same image.
3. Controls Image Access – Allows public, private, and shared images for security.
4. Supports Multiple Image Formats – QCOW2, RAW, VMDK, VHD, etc.
5. Distributes Images to Compute Nodes – Nova retrieves images from Glance when launching instances

Key Metadata Fields in Glance

When an image is stored in Glance, it maintains metadata such as:

Metadata Field Description

id Unique identifier of the image

name Name of the image (e.g., Ubuntu-20.04)

disk_format Image format (qcow2, raw, vmdk, etc.)

container_format Bare, ami, docker, etc.

size Size of the image in bytes

visibility Public or private

status Current state (queued, active, deleted)

Network Management

Neutron in OpenStack

Neutron is the networking service in OpenStack that provides networking-as-a-service (NaaS) for cloud
instances. It allows users to create and manage networks, subnets, routers, and security groups dynamically.

allowing users to create, manage, and control networking resources such as networks, subnets, routers,
firewalls, and load balancers for virtual machines (VMs).

Why is Neutron Important?

 Provides network isolation for tenants.

 Supports SDN (Software-Defined Networking) integration.
 Allows floating IPs for external access.
 Manages virtual and physical network interfaces.

Key Features of Neutron:

✔Self-service networking: Users can create virtual networks, routers, and security groups.
✔Multiple network types: Supports VLAN, VXLAN, GRE, and Flat networks.
✔Floating IPs: Allows external access to VMs.
✔Security groups: Acts as a firewall to control incoming/outgoing traffic.
✔Load balancing (LBaaS): Distributes traffic across multiple instances.
✔Firewall (FWaaS) & VPN (VPNaaS): Provides network security and VPN connectivity.

Neutron Network Types

Network Type Description

Flat Single network shared among all tenants.

VLAN Uses VLAN tags to separate networks.

VXLAN Encapsulates traffic for large-scale deployments.

GRE Uses tunnels for isolated tenant networks.

Core Networking Resources in Neutron

1. Networks – Virtual Layer 2 (L2) networks for VMs.

2. Subnets – Defines an IP address range for a network.
3. Routers – Connects different networks and enables external connectivity.
4. Floating IPs – Provides public IPs for external access.
 5. Security Groups – Acts as a firewall for VMs.
6. Load Balancing (LBaaS) – Distributes traffic among multiple instances.
7. Firewalls (FWaaS) & VPN (VPNaaS) – Provides network security and VPN tunneling.

Neutron Networking Concepts

1. Networks

 Virtual networks that connect VMs.

 Can be Private (Internal) or Public (External).

2. Subnets

 Defines IP address range within a network.

 Example: 192.168.1.0/24

3. Routers

 Connect private networks to external networks (Internet).

 Performs NAT (Network Address Translation).

4. Floating IPs

 Assigns a public IP to a VM, making it accessible from the Internet.

5. Security Groups

 Acts as a firewall to allow/deny traffic to instances.

 Example: Allow only SSH (port 22) and HTTP (port 80).

6. Ports

 Logical points of connectivity for VMs, routers, and other services.

7. Load Balancer as a Service (LBaaS)

 Distributes traffic across multiple instances for high availability.

8. Firewall as a Service (FWaaS)

 Implements network security policies at the perimeter.

9. VPN as a Service (VPNaaS)

 Enables secure encrypted communication between networks.

Neutron Architecture

Neutron consists of several components:

1. Neutron Server (neutron-server)

 Main service that manages API requests for networking.

  Communicates with Neutron agents on compute and network nodes.

2. Neutron Plugins

 Different backends for implementing network functions (e.g., Open vSwitch, LinuxBridge, SDN controllers).

3. Neutron Agents (Networking Components)

 L3 Agent: Handles routing, NAT, and Floating IPs.

 DHCP Agent: Provides IP address allocation.
 L2 Agent: Connects virtual machines to the network using Open vSwitch or LinuxBridge.
 Metadata Agent: Passes metadata to instances for configuration.

Network Fabric in OpenStack Neutron

What is Network Fabric?

A network fabric is the underlying architecture that interconnects all network devices and resources within a data
center. In OpenStack Neutron, the network fabric refers to the virtual and physical network topology that connects
compute instances, storage systems, and external networks.

Components of Network Fabric in OpenStack

Component Function

Tenant Networks Virtual networks created by users (VXLAN, VLAN, GRE).

Provider Networks Physical networks managed by administrators.

Routers Enable Layer 3 (L3) connectivity between networks.

Floating IPs Assign public IPs to private instances.

Security Groups Act as virtual firewalls.

Load Balancer (LBaaS) Distributes traffic among multiple instances.

Network Types in OpenStack Fabric

Network Type Description

Flat Network No VLANs, all instances share the same network.

VLAN Network Uses VLAN IDs for isolation between tenants.

VXLAN/GRE Network Encapsulates traffic over Layer 3 for large-scale deployments.

External Network Connects OpenStack to the public internet.

How Neutron Manages Network Fabric

✔ Encapsulates tenant traffic using VXLAN, GRE, or VLAN.

✔ Uses virtual routers for Layer 3 (L3) connectivity.
✔ Provides DHCP and IP address management.
✔ Implements security via firewalls and security groups.
✔ Integrates with SDN controllers for network automation.

Instance Management

What is Nova?

Nova is the compute service in OpenStack that manages virtual machines (instances). It provides APIs for launching,
scheduling, and managing instances, ensuring that compute resources (CPU, RAM, disk) are allocated efficiently.

Flavors define the hardware specifications for VMs. Each flavor includes:
vCPUs – Number of virtual CPUs
RAM – Memory allocation
Disk Space – Root and ephemeral disk size
Swap Space – Optional extra memory

Features of Nova

✔ Manages virtual machines (instances)

✔ Supports multiple hypervisors (KVM, QEMU, Xen, VMware)
✔ Handles instance scheduling and placement
✔ Manages CPU, RAM, and disk allocation
✔ Supports live migration of VMs
✔ Provides APIs for instance management

Nova Architecture Components

Component Description

nova-api Handles API requests from users.

nova-scheduler Decides where new VMs will be created based on resources.

nova-conductor Manages database interactions and communication.

nova-compute Talks to the hypervisor and manages VM lifecycle.

nova-network (Deprecated) Previously handled networking, now replaced by Neutron.

nova-console Provides access to VM consoles (VNC, RDP, or SPICE).

Instance Lifecycle

State Description
Active The instance is running.
Shutoff The instance is stopped.
Paused The instance is temporarily halted.
Suspended The instance is saved to disk and stopped.
Rescued The instance is in recovery mode.
Shelved The instance is removed from the hypervisor but preserved.

Managing Flavors in OpenStack (Nova)

What are Flavors?

Flavors define the compute resources (CPU, RAM, Disk) assigned to virtual machines (VMs) in OpenStack. They act
like instance types in AWS (e.g., t2.micro) or machine sizes in Azure (e.g., Standard_B2s).

Flavors ensure efficient resource allocation for different workload needs.

Key Attributes of a Flavor

Attribute Description

ID Unique identifier for the flavor.

Name Human-readable name for the flavor.

vCPUs Number of virtual CPUs assigned to the VM.

RAM (MB) Memory allocated to the VM.

Disk (GB) Root disk space assigned.

Ephemeral Disk Temporary storage (deleted when instance shuts down).

Swap (MB) Extra swap space for the instance.

RXTX Factor Adjusts network bandwidth.

Managing Key Pairs in OpenStack

What are Key Pairs?

Key pairs in OpenStack are SSH keys used to securely access instances (VMs). Instead of using passwords, key pairs
allow authentication using public-private key cryptography.

Why use Key Pairs?

  Secure access to OpenStack instances
 Eliminates password-based authentication
 Ensures only authorized users can access instances

Launching an Instance in OpenStack

In OpenStack, an instance refers to a virtual machine (VM) running in the cloud. The process of launching an instance
involves selecting an image, flavor, key pair, network, and security group to create a virtual machine.

Steps to Launch an Instance in OpenStack

An image (Ubuntu, CentOS, etc.)

A flavor (CPU/RAM/Disk configuration)
A key pair (for SSH access)
A network (so the instance can communicate)
A security group (to control access via firewall rules)

Unit 3
OpenStack Storage
Block Storage

Cinder in OpenStack

Cinder is the block storage service in OpenStack, designed to provide persistent storage to virtual machines (VMs)
and other cloud services. It enables users to create, attach, detach, and manage block storage volumes
independently from instances, similar to Amazon Elastic Block Store (EBS).

1. Key Features of Cinder

1. Persistent Storage – Volumes remain even after instances are terminated.

2. Multiple Storage Backends – Supports LVM, Ceph, NetApp, and more.
3. Snapshots & Backups – Allows point-in-time copies of volumes.
4. Multi-Tenant Support – Ensures data isolation for different projects.
5. QoS (Quality of Service) – Controls storage performance.
6. Volume Encryption – Provides security for stored data.
7. Replication – Ensures high availability and disaster recovery.

2. Cinder Architecture

Cinder consists of several components that work together to provide block storage:
(a) Cinder API

 Handles user requests (Create, Attach, Delete Volumes).

 Communicates with the Cinder Scheduler and Cinder Volume Service.

(b) Cinder Scheduler

 Selects the best storage backend based on policies and availability.

(c) Cinder Volume Service

 Manages storage backend operations (LVM, Ceph, etc.).

 Creates, attaches, detaches, and deletes volumes.

(d) Cinder Backup Service

 Creates backups of volumes to external storage (Swift, NFS).

Cinder Architecture Components

Component Description

Cinder API Handles storage-related API requests from users.

Cinder Scheduler Selects the best storage backend for volume creation.

Cinder Volume Manages the actual storage backends (LVM, Ceph, etc.).

Cinder Backup Creates backups of storage volumes.

Cinder Database Stores metadata about volumes, backups, and snapshots.

3. Cinder Workflow (Volume Lifecycle)

1. Create a volume
2. Attach the volume to a VM
3. Use the volume in the VM (Format, Mount, Store Data)
4. Detach the volume
5. Delete the volume (optional)

Managing Cinder in OpenStack

Cinder is the Block Storage Service in OpenStack, used to manage persistent storage volumes for instances. It
provides block-level storage, similar to traditional hard drives, allowing instances to store and retrieve data.

Key Features of Cinder

1. Persistent storage independent of the instance

 2. Snapshots and backups for disaster recovery
3. Supports different storage backends (LVM, Ceph, NFS, etc.)
4. Volume resizing, migration, and encryption
5. Multi-tenant support

Telemetry

Ceilometer in OpenStack: Telemetry Service

Ceilometer is the Telemetry Service in OpenStack. It collects and provides data on resource usage for billing,
monitoring, and performance analysis. Ceilometer works closely with Gnocchi (for metric storage) and Aodh (for
alarming).

Key Features of Ceilometer

1. Collects CPU, RAM, Disk, and Network usage statistics

2. Supports multi-tenant billing and chargeback
3. Works with Gnocchi (metrics storage) and Aodh (alarms)
4. Monitors OpenStack services like Nova, Cinder, Neutron
5. Generates alerts and notifications for specific conditions

Components of Ceilometer

1. Pollsters – Collect data at regular intervals

2. Notification Agents – Listen for events from OpenStack services
3. Pipelines – Define how data is processed and stored
4. Publishers – Send data to storage backends (Gnocchi, MongoDB, etc.)
5. Alarms – Trigger alerts based on resource thresholds
6. Resource Usage Tracking – Collects data on CPU, disk, memory, and network usage.
7. Billing and Chargeback – Provides data for usage-based billing
8. Event Monitoring – Captures system events for troubleshooting
9. Threshold-Based Alarming – Works with Aodh to trigger alarms when thresholds are exceeded
10. Scalable Data Processing – Integrates with Gnocchi for efficient metric storage

Collecting Telemetry Data

Ceilometer collects data using two methods:

 Polling: Actively fetches data from OpenStack services

 Event Listening: Receives notifications from OpenStack components

Understanding Ceilometer Terms

Term Description

Meters Track resource usage (e.g., CPU time, network traffic)

Samples Individual data points recorded over time

 Term Description

Statistics Aggregated data (average, min, max, sum)

Pipelines Define how data is processed and stored

Alarms Notify admins when thresholds are exceeded

How Ceilometer Works?

1. Collects telemetry data from OpenStack services (Nova, Cinder, Neutron, etc.)
2. Processes the data through pipelines and stores it in databases (MongoDB, Gnocchi)
3. Generates reports for metering, monitoring, and billing
4. Triggers alarms when predefined thresholds are exceeded

Ceilometer Key Concepts in Simple Words

Ceilometer helps in tracking and measuring resource usage in OpenStack. To do this, it uses different
components. Let's understand them one by one:

1. Data Store

 A database where Ceilometer stores all collected data (e.g., CPU usage, disk space).
 Commonly uses Gnocchi, MongoDB, or InfluxDB to store and retrieve data.

2. Configuration Terms

 These are settings that define how Ceilometer works, such as what data to collect, how often, and
where to store it.

3. Pipelines

 A data flow system that tells Ceilometer how to process and send collected data (e.g., storing in a
database or sending it for billing).
 Example: CPU usage data can be sent to both a monitoring system and a billing system.

4. Meters

 Think of these as measuring tools that track different resources like CPU, RAM, disk, and
network usage.
 Example: A meter for CPU will track how much CPU is being used over time.

5. Samples

 Snapshots of data collected at a specific time.

 Example: A sample might record that a virtual machine used 40% CPU at 2:00 PM.

6. Statistics

 Summarized data based on multiple samples (e.g., average CPU usage over 1 hour).
 Helps in analyzing trends and predicting future needs.

7. Alarms
  Triggers an alert or action when a resource crosses a set limit.
 Example: If CPU usage goes above 90%, an alarm can automatically scale resources or notify the
admin.

8. Graphing the Data

 Visualizing the collected data using graphs and charts to understand trends, peaks, and patterns.
 Example: A graph can show how memory usage has increased over a week.

Unit 4
Openstack Automation && Scaling Horizontally

OpenstackAutomation
What is Heat in OpenStack?

Heat is the orchestration service in OpenStack. It helps you automate the creation and management of cloud
resources (like virtual machines, storage, networks) using template files.

You can think of Heat as a robot cloud engineer 🛠️. You give it a blueprint (called a template), and it builds your
entire cloud environment based on that.

It allows users to define the entire cloud infrastructure in a single file (called a template) and then deploy
everything together as one stack.

Heat is the brain of OpenStack that reads a template and builds your cloud setup automatically, just like following a
recipe to make a complete meal.

Key Features:

 Uses HOT (Heat Orchestration Template) files (written in YAML).

 Helps in Infrastructure as Code (IaC).
 Supports scaling and auto-healing.
 Can manage dependencies between resources.
 Compatible with AWS CloudFormation-style templates.

Key Points About Heat

Feature Description
Service Name heat
What it does Automates the deployment and management of OpenStack resources
Uses Templates (written in YAML or JSON) to define infrastructure
Template Format HOT (Heat Orchestration Template) or AWS CloudFormation-style
Built For Developers, system admins, DevOps engineers to build repeatable setups
Scaling Horizontally
What does “Off-the-Shelf Hardware” mean?

Off-the-shelf hardware refers to standard, commonly available servers — not expensive or specialized equipment.
Think of regular servers from Dell, HP, or even custom PC builds with decent processors, RAM, and storage.

 Cost-effective
 Easily replaceable
 Good for scaling horizontally

Why is this important for OpenStack?

OpenStack is designed to run in commodity environments, meaning:

 You don’t need high-end machines

 You can add more low-cost machines to scale up
 It supports horizontal scaling: just add more nodes!

Key Steps to Build OpenStack on Off-the-Shelf Hardware:

1. Prepare the Hardware

 2–3 standard servers (8 GB+ RAM, 2+ CPUs, 100 GB+ disk)

 Install RHEL/CentOS/Ubuntu on each node

2. Install and Configure OpenStack

 Use RDO Packstack (easy for beginners)

 Or use DevStack (for testing)
 Advanced: Manual setup for each component (Nova, Neutron, etc.)

3. Node Roles

 Controller Node: Handles APIs, scheduling, and dashboards

 Compute Nodes: Run virtual machines
 Storage Node (optional): Handles Cinder/Swift volumes

4. Networking

 Ensure all nodes can talk to each other

 Configure Neutron for managing internal/external networks

Benefits of This Approach

Benefit Description

Cost-effective Use cheaper machines

Easy to scale Add more nodes when needed

Flexibility Replace nodes easily if one fails

 Benefit Description

Open-source freedom No vendor lock-in

1. Scaling Compute Nodes

Definition:
This means adding more servers (called compute nodes) to your cloud so you can run more virtual machines
(VMs).

Explanation:
Imagine your computer is full, and you can't run any more programs. So, you bring in a second computer to
share the load. That’s what scaling compute nodes is in cloud — adding more machines to run more VMs.

2. Installing More Control and Networking

Definition:
Adding more controller and network nodes to handle more requests, services, and users.

Explanation:
If too many people are using your cloud at the same time, one controller (main manager) can't handle all. So,
you install another controller and network manager to split the load. It's like hiring more managers in a busy
company.

3. Scaling Control and Network Services

Definition:
This means running multiple copies of important services like Keystone, Glance, Neutron on different
servers to make them faster and more reliable.

Explanation:
If one service gets busy or crashes, others are still running. It’s like having 3 customer service agents instead
of 1 — better performance and no single point of failure.

4. Load-Balancing Keystone

Definition:
It means distributing the user login/authentication requests across multiple Keystone servers.

Explanation:
If everyone logs in at the same time and there's only one gate (Keystone), it becomes slow. Load balancing
is like opening 3 gates and dividing the crowd, so login is faster and more secure.

5. Additional Keystone Tuning

Definition:
Adjusting Keystone settings for better speed, security, and performance.

Explanation:
You can make Keystone faster and more secure by tweaking its settings — like setting token expiry time,
caching, number of worker processes, etc.

6. Glance Load Balancing

Definition:
Distributing image upload/download requests across multiple Glance servers.

Explanation:
Glance handles VM disk images. When lots of users are downloading or uploading images, you need more
Glance servers and a load balancer to share the load. This keeps image access smooth and quick.

7. Scaling Other Services

Definition:
It means increasing the capacity of other OpenStack services like Cinder, Neutron, Swift, etc., by adding
more servers.

Explanation:
Like compute and control services, storage and networking also need scaling when users increase. You scale
them by deploying more nodes of those services.

8. High Availability (HA)

Definition:
Making sure your cloud services are always running — even if a server crashes.

Explanation:
You set up multiple copies of services. If one fails, another takes over. So, users don’t face downtime. It’s
like having backup generators in case electricity goes off.

9. Highly Available Database and Message Bus

Definition:
Running your database (like MariaDB) and message system (like RabbitMQ) in HA mode — with
multiple nodes and failover options.

Explanation:
These are the heart of OpenStack. If they stop, everything stops. So, you run 2-3 copies of them, use
clustering and automatic failover, to make sure OpenStack keeps working smoothly.
 Unit 5
Openstack Monitoring and Troubleshooting Monitoring
Openstack Monitoring

Monitoring Defined (in OpenStack)

Monitoring in OpenStack refers to the process of continuously observing the health, performance, and
availability of cloud services and infrastructure components. The goal is to ensure everything in the
OpenStack environment (like Nova, Neutron, Glance, etc.) is running smoothly, and any failures or issues
are detected early.

OR

Monitoring is the process of continuously checking the health, performance, and resource usage of
OpenStack services to ensure the cloud environment runs smoothly.

Why is Monitoring Important in OpenStack?

 Detect failures (e.g., a compute node goes down)

 Track usage (e.g., how many instances are running)
 Ensure services (Keystone, Nova, Neutron) are online
 Help in troubleshooting issues faster
 Collect performance metrics (CPU, RAM, disk usage)
 Support auto-scaling and alerting

We are monitoring this services

Component What to Monitor
Nova VM uptime, hypervisor health
Neutron Network agents (L3, DHCP), connectivity
Keystone Authentication failures
Glance Image upload/download status
Cinder Block storage availability
Swift Object storage health
Ceilometer Data collection services

Tools Used for Monitoring:

 Nagios – Most common in RDO-based installations

 Zabbix, Prometheus + Grafana – Modern alternatives
 Ceilometer – OpenStack's native telemetry service
 Logging Tools – journalctl, tail, ELK stack

Installing Nagios in OpenStack (or Any Linux Server)

Nagios is one of the most popular open-source monitoring tools. In an OpenStack environment, Nagios is
commonly used to monitor the health of cloud components and infrastructure.
Step-by-Step: Installing Nagios.

1. Install Required Packages

sudo yum install httpd php gcc glibc glibc-common gd gd-devel make net-snmp -y

2. Create a Nagios User & Group

sudo useradd nagios

sudo groupadd nagcmd

sudo usermod -a -G nagcmd nagios

sudo usermod -a -G nagcmd apache

3. Download & Extract Nagios Core

cd /tmp

curl -L -O https://assets.nagios.com/downloads/nagioscore/releases/nagios-
4.4.6.tar.gz

tar -zxvf nagios-4.4.6.tar.gz

cd nagios-4.4.6

4. Compile and Install

./configure --with-command-group=nagcmd

make all

sudo make install

sudo make install-init

sudo make install-config

sudo make install-commandmode

5. Install Web Interface

sudo make install-webconf

sudo htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

6. Start Apache and Nagios

sudo systemctl start httpd

sudo systemctl enable httpd

sudo systemctl start nagios

sudo systemctl enable nagios

Accessing Nagios

http://<your_server_ip>/nagios
Adding Nagios Host Checks

A host check in Nagios means checking if a machine (host) — like a server or OpenStack node — is
reachable (UP) or not (DOWN).

Steps to Add a Host Check

1. Open the hosts config file

sudo nano /usr/local/nagios/etc/objects/hosts.cfg

2. Add a new host block

define host {

use linux-server

host_name openstack-node1

alias OpenStack Compute Node

address 192.168.1.50

max_check_attempts 5

check_period 24x7

notification_interval 30

notification_period 24x7

3. Link this file in nagios.cfg

sudo nano /usr/local/nagios/etc/nagios.cfg

or
cfg_file=/usr/local/nagios/etc/objects/hosts.cfg

4. Check config and restart Nagios

sudo /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

sudo systemctl restart nagios

Nagios commands

Daily-Use Nagios Terminal Commands (Short & Sweet)

Command What It Does

systemctl start nagios Starts the Nagios service.
systemctl stop nagios Stops the Nagios service.
systemctl restart nagios Restarts Nagios (use after changes).
systemctl status nagios
Shows current status of the Nagios
service.
 Command What It Does
nagios -v /path/to/nagios.cfg Validates the Nagios config for errors.
tail -f /usr/local/nagios/var/nagios.log
Shows live logs of Nagios (useful for
debugging).
htpasswd /usr/local/nagios/etc/htpasswd.users
nagiosadmin Updates Nagios web login password.
ls /usr/local/nagios/libexec/ Lists available Nagios plugins.

Monitoring Methods (In Short & Simple Words)

Method What It Means

Nagios actively checks services (like pinging a server or
Active Monitoring
checking a port).
Other tools or scripts send results to Nagios without it checking
Passive Monitoring
by itself.
SNMP (Simple Network Management
Used to monitor network devices like routers/switches.
Protocol)
Tracks logs (like /var/log/messages) for errors or
Log Monitoring
important events.
Resource Monitoring Monitors CPU, memory, disk usage, etc. of servers and VMs.
Checks if services like HTTP, SSH, MySQL are running
Service Monitoring
properly.
Alerting Sends emails/SMS/notifications when something goes wrong.

Non-OpenStack Service Checks

These are general services your cloud server needs, not directly part of OpenStack, but essential for
system health.

Example Services What You Monitor

SSH, Apache, MySQL, NTP Are they running, slow, or crashed?
Disk, Memory, CPU Are resources overloaded?
Host Pings Is the server online?

Why? Even if OpenStack is perfect, if your SSH or Apache server dies, users can’t access anything!

Monitoring Control Services

These are OpenStack core services that control authentication, image registry, orchestration, etc.

Service What to Monitor

Keystone Can users authenticate? Login failures?
Glance Are images accessible? Is image upload OK?
Heat Is orchestration working? Are templates deployed?

Goal: Make sure the main "brain" of OpenStack is healthy.

Monitoring Network Services
Focuses on Neutron, the networking part of OpenStack.

Network Elements What to Monitor

Neutron agents Are they running? Errors in logs?
DHCP/L3/L2 Are IPs assigned? Are routers alive?
Network traffic Any packet loss or slow connections?

Goal: Users and VMs need working networks to talk to each other.

Monitoring Compute Services

Focuses on Nova, which runs virtual machines.

Compute Elements What to Monitor

Nova compute Are VMs launching/stopping properly?
Hypervisor CPU/RAM overload? Disk I/O issues?
Instances Are they reachable? Are they crashing?

Goal: VMs should run smoothly without crashes or lag.

Troubleshooting Monitoring
The debug command line option

What is the --debug option in OpenStack?

The --debug flag is used in OpenStack CLI commands to show detailed internal processes, like:

 API requests/responses
 Token information
 HTTP calls
 Errors or warnings
 Detailed logs of what's happening in the background

Why Use --debug?

Situation Why it helps

Shows where and why it's

Command failing unexpectedly
failing

Shows exact API request

API not responding
being made

Helps trace token, headers,

Troubleshooting authentication or service issues
endpoints

--debug Command-Line Option (Short Definition):

The --debug option in OpenStack CLI shows detailed logs and internal processing of the command,
including API calls, tokens, headers, and responses.
It helps in troubleshooting errors and understanding how OpenStack services interact.

Example:
openstack --debug server list

This will show extra information useful for debugging.

Tail the Server Logs

Tailing logs means viewing the latest lines of a log file in real-time. It helps you monitor what’s
happening on the server as it happens — super useful for debugging OpenStack services like Nova,
Keystone, etc.

Command Used:
tail -f /var/log/nova/nova-api.log

 tail: Shows the last part of a file

 -f: Follows the log in real-time (like a live stream)

Example (Per Service):

Service Log File

Nova (Compute) /var/log/nova/nova-api.log
Keystone (Auth) /var/log/keystone/keystone.log
Neutron (Network) /var/log/neutron/neutron-server.log
Glance (Images) /var/log/glance/api.log

Troubleshooting Keystone and Authentication

Keystone handles:

 User authentication
 Service authentication
 Token generation
 Endpoint management

When something goes wrong with login, access, or tokens — Keystone is where you look!

Common Issues & Fixes

1. Authentication Failures

 Error: The request you have made requires authentication.

 Cause: Invalid credentials or missing token.
 Fix:
o Check your environment variables:
 echo $OS_USERNAME
echo $OS_PASSWORD
echo $OS_AUTH_URL

o Re-source your OpenStack RC file:

source admin-openrc.sh

2. Token Errors

 Error: The token is invalid or expired

 Fix:
o Clear old tokens:

openstack token issue

o Restart Keystone if needed:

systemctl restart httpd

3. Invalid Endpoint

 Error: Endpoint not found

 Fix:
o Verify endpoint list:

openstack endpoint list

o Ensure Keystone is registered with correct URLs.

Logs to Check

 Keystone Logs:

tail -f /var/log/keystone/keystone.log

 Look for: 401 Unauthorized, Token expired, Invalid user, etc.

Task Command
Show Keystone users openstack user list
Show services openstack service list
Check tokens openstack token issue

Troubleshooting Glance image management

Glance handles:

 Uploading and storing disk images (VM images)

 Serving images to Nova for launching instances
  Acting as an image registry

When image upload, download, or usage fails — Glance is the place to troubleshoot!

Common Glance Issues and How to Fix Them

1. Image Fails to Upload

Error: HTTP 500 Internal Server Error or Image upload failed

 Cause: Wrong permissions, storage backend not working.

 Fix:

openstack image create "test-img" --file cirros.img --disk-format qcow2 --

container-format bare --public

Check:

o Image file path is correct.

o glance-api and glance-registry services are active:

systemctl status openstack-glance-api

2. Image Doesn’t Appear in Dashboard or CLI

 Cause: Database sync problem or service not registered.

 Fix:
o Verify Glance is registered:

openstack service list | grep image

o Check image list:

openstack image list

o Restart Glance if needed:

systemctl restart openstack-glance-api

3. Image Download Fails

Error: Could not download image.

 Fix:
o Check file permissions on /var/lib/glance/images/
o Check Glance log for path errors or read permission issues.

4. Permission or Auth Issues

  Error: Unauthorized to perform image action
 Fix:
o Make sure you have admin or appropriate role in the project.
o Check token:

openstack token issue

Logs to Monitor

Check these when debugging:

tail -f /var/log/glance/api.log
tail -f /var/log/glance/registry.log

Important Glance CLI Commands

Task Command

List images openstack image list

Upload image openstack image create
Show image info openstack image show IMAGE_ID
Delete image openstack image delete IMAGE_ID

Troubleshooting Neutron networking

Neutron is the OpenStack service that:

 Manages networks, subnets, and routers

 Assigns IP addresses to instances
 Handles security groups and firewall rules
 Manages VLAN, VXLAN, GRE, etc.

If VMs can’t ping each other, get no IP, or don’t connect to the internet → Neutron is the place to check!

Common Neutron Issues & Fixes

1. Instance not getting an IP (DHCP Issue)

Possible Causes:

 DHCP agent not working

 No subnet assigned

Fix Steps:

openstack subnet list

openstack port list --device-id <instance_id>
Check DHCP agent:

openstack network agent list

systemctl status neutron-dhcp-agent

Restart if needed:

systemctl restart neutron-dhcp-agent

2. Instances can't ping each other (Internal Network Issue)

Possible Causes:

 Security groups blocking ICMP

 Incorrect subnet/router
 OVS misconfigured

Fix Steps:

 Check security group rules:

openstack security group rule list

 Allow ICMP:

openstack security group rule create --proto icmp default

3. No Internet Access (Floating IP or Router Issue)

Possible Causes:

 No router or wrong gateway

 Floating IP not associated

Fix Steps:

openstack router list

openstack router show <router_id>
openstack floating ip list

Make sure router has external gateway and the interface is added.

4. Neutron Agent Down

Symptoms: Status = xxx in openstack network agent list

Fix Steps:

openstack network agent list

systemctl status neutron-linuxbridge-agent
systemctl restart neutron-linuxbridge-agent
Or for OVS:

systemctl restart neutron-openvswitch-agent

Logs to Tail When Troubleshooting

tail -f /var/log/neutron/neutron-server.log
tail -f /var/log/neutron/linuxbridge-agent.log
tail -f /var/log/neutron/dhcp-agent.log
tail -f /var/log/neutron/l3-agent.log

CLI Command Toolbox

Purpose Command

List networks openstack network list

Check subnets openstack subnet list

Show ports openstack port list

View agents openstack network agent list

Assign floating IP openstack floating ip create

Troubleshooting Nova launching instances

Nova = Compute service

Its job:

 Launch VMs
 Manage hypervisors (like KVM, QEMU)
 Interact with Glance (images), Neutron (networking), and Cinder (volumes)

Common Problems When Launching VMs (and Fixes)

1. Instance stuck in "BUILD" state

Causes:

 Nova-compute is down
 Scheduler can’t find a host
 Resource shortage (CPU, RAM, disk)

Fix:

openstack compute service list

systemctl status openstack-nova-compute
  Restart the service:

systemctl restart openstack-nova-compute

Check scheduler logs:

tail -f /var/log/nova/nova-scheduler.log

2. Instance fails with error: "No valid host found"

Causes:

 No compute node has enough resources

 Filters or configuration errors in nova-scheduler

Fix:

 Check if filters are blocking:

grep scheduler /etc/nova/nova.conf

 Use:

nova-status upgrade check

View the error:

openstack server show <instance-id>

3. Failed to spawn instance

Causes:

 Image issue (from Glance)

 Incorrect virtualization settings
 Libvirt or KVM issue

Fix:

tail -f /var/log/nova/nova-compute.log

 Look for "No such image", or "Failed to spawn"

 Ensure virtualization is enabled in BIOS/UEFI
 Check hypervisor:

virsh list --all

4. VM has no networking

 Cause:
 Neutron misconfiguration
 Port not created or bound
 Fix:

 Check Neutron ports:

openstack port list --device-id <instance_id>

 Check security groups:

openstack security group rule list

5. Instance goes into ERROR state

Fix:

openstack server show <instance-id>

openstack server delete <instance-id>

Logs You MUST Know for Troubleshooting

File Description

/var/log/nova/nova-compute.log Errors during VM creation

/var/log/nova/nova-scheduler.log Scheduling problems

/var/log/nova/nova-api.log API-related issues

/var/log/libvirt/libvirtd.log Hypervisor issues

Use:

tail -f /var/log/nova/nova-compute.log