Cloud Computing

Module 1
Overview of OpenStack
Cloud computing is a way of accessing compute and storage systems without actually owning
and doing active management of the resources.

In today’s world, compute, and storage demands are very dynamic hence purchasing,
maintaining and upgrading systems could be a huge investment of time and money.

Companies like AWS (Amazon Web Services), Microsoft Azure,

Google Cloud Platform (GCP) provide compute and storage servers on-demand and charge for
what you use.

It has proven to be extremely useful for startups where compute resources can vary largely over
time.

Cloud Computing can be classified in terms of the following models:

1. Service Models
2. Deployment Models
Service models
1. SaaS (Software as a Service)

In the SaaS-based model, the cloud service provider; the user only needs to upload and download data.
Maintenance, downtime, upgradation, security are all taken care of by the service provider.

2. PaaS (Platform as a Service)

In PaaS user manages applications along with data. Lot of times, the user wants to launch and maintain their
own applications over the cloud, which is where PaaS comes into the picture. The service provider meets all the
Hardware, Networking, O/S needs. The user can use any programming language of choice. PaaS services are
cheaper compared to SaaS.

3. IaaS (Infrastructure as a Service)

In IaaS based service hardware, the vendor provides virtualisation and networking services while the user takes
care of OS, applications, and data.
Deployment models
1. Public Cloud

● Service Provider makes resources such as Compute, storage, and applications available to the general public over the
internet.
● Any user can log in and use these services.
● You pay for the number of resources you use.
● Users have lesser control over their data.

2. Private Cloud

● The vendor offers hosted services to fewer users with firewall security.
● The private cloud minimizes security issues.
● It provides greater control over the data.
● Typically used by organizations with a focus on data security.

3. Hybrid Cloud

● Hybrid cloud computing, as the name implies, uses a combination of private and public cloud services. Certain services
are hosted with private cloud while others with the public cloud.
● With a hybrid cloud service, enterprises can keep crucial data into private space and other data into public space, thus
leveraging the best of both worlds.
OpenStack - The new data center
paradigm
● A remarkable orchestration solution, which falls into the private
cloud category, has brought thousands of enterprises to the next era
of data center generation: OpenStack.

● The influence of OpenStack was felt by many big cloud enterprises

such as VMware, Cisco, Juniper, IBM, Red Hat, Rackspace, PayPal,
and eBay
Introducing the OpenStack logical
architecture
Introducing the OpenStack logical architecture.
• Most OpenStack services are developed in Python
• All OpenStack services provide REST APIs.
• The components of a service communicate with each other over the
message queue.
Keystone - Identity management
• Core component and provides an identity service
comprising authentication and authorization of tenants in
OpenStack.

• Username/password and token/authentication-based

systems.

• It is possible to integrate it with an existing backend such

as the Lightweight Directory Access Protocol (LDAP) and
the Pluggable Authentication Module (PAM).
• The federation identity solution becomes more stable within the
• A service catalog as a registry of all the OpenStack OpenStack Juno release,which engages Keystone as a Service
services. Provider (SP), and uses and consumes from a trusted Provider of
Identity (IdP), user identity information in SAML assertions, or
OpenID Connect claims. An IdP can be backed by LDAP, Active
Directory, or SQL.
Swift - object storage
● One of the storage services available to OpenStack users.
● It provides an object-based storage service and is accessible through REST APIs.
● To store the data, the Object-Store splits it into smaller chunks and stores it in separate containers.

Benefits

● It has no central brain, and indicates no Single Point Of Failure (SPOF) It is curative, and indicates auto-recovery in
the case of failure
● It is highly scalable for large petabytes of storage access by scaling horizontally It has a better performance, which is
achieved by spreading the load over the storage nodes
● It has inexpensive hardware that can be used for redundant storage clusters
Cinder - block storage
• Persistent block storage is available by using the Cinder service.
• Its main capability is to provide block-level storage to the virtual machine. Cinder provides raw volumes
that can be used as hard disks in virtual machines.

Features:

• Volume management

• Snapshot management

• Attaching or detaching volumes from instances

• Cloning volumes

• Creating volumes from snapshots

• Copy of images to volumes and vice versa

Manila - File share
• A file-share-based storage service.

• It provides storage as a remote file system. In operation, it resembles the Network File System
(NFS) or SAMBA storage service that we are used on Linux while, in contrast to Cinder, it
resembles the Storage Area Network (SAN) service. In fact, NFS and SAMBA or the Common
Internet File System (CIFS) are supported as backend drivers to the Manila service.

• The Manila service provides the orchestration of shares on the share servers.
Glance - Image registry
● The Glance service provides a registry of images and metadata that the OpenStack user can launch as a virtual machine.
Various image formats are supported and can be used based on the choice of hypervisor

● Swift is a storage system, whereas Glance is an image registry. The difference between the two is that Glance is a service
that keeps track of virtual machine images and metadata associated with the images. Metadata can be information such as
a kernel, disk images, disk format, and so on. Glance makes this information available to OpenStack users over REST
APIs. Glance can use a variety of backends for storing images.

● The goal of Glance is to focus on advanced ways to store and query image information via the Image Service API.
Nova-Compute service
• Nova provides the compute service in OpenStack and manages virtual machines in
response to service requests made by OpenStack users.

Components:

1. nova api
2. nova-compute
3. nova-network
4. nova-scheduler
5. nova-conductor
Nova-compute components

1. nova api 3. nova-network

● Accepts and responds to the end user and ● Accepts networking tasks from the queue and
perform task to manipulate the network
computes API calls, It initiates most
orchestrating activities 4. nova-scheduler

● Determines where it should run (specifically which

compute host it should run on)
1. nova-compute 5. nova-conductor
● It is a worker daemon that creates and
● The nova-conductor service provides database
terminates VM instances via the access to compute nodes. The idea behind this
hypervisor's APIs service is to prevent direct database access from the
compute nodes, thus enhancing database security in
case one of the compute nodes gets compromised.
Neutron - Networking services
• Provides Network as a Service (NaaS) capability between interface
devices that are managed by OpenStack services such as Nova.

• There are various characteristics

❑ It allows users to create their own networks
❑ Pluggable backend architecture
❑It provides extensions to allow additional network services to be
integrated
Neutron core services
● Ports: Ports in Neutron refer to the virtual switch connections. These connections are where instances and
network services are attached to networks. When attached to subnets, the defined MAC and IP addresses
of the interfaces are plugged into them.

● Networks: Neutron defines networks as isolated Layer 2 network segments. Operators will see networks
as logical switches that are implemented by the Linux bridging tools, Open vSwitch, or some other
virtual switch software. Unlike physical networks, either the operators or users in OpenStack can define
this.

● Subnet: Subnets in Neutron represent a block of IP addresses associated with a network. IP addresses
from this block are allocated to the ports.
Neuron additional services
Routers: Routers provide gateways between various networks.

Private IPs: Neutron defines two types of networks. They are as follows:
● Tenant networks: Tenant networks use private IP addresses. Private IP addresses are visible within the instance
and this allows the tenant's instances to communicate while maintaining isolation from the other tenant's traffic.
Private IP addresses are not visible to the Internet.

● External networks: External networks are visible and routable from the Internet. They must use routable subnet
blocks.

● Floating IPs: A floating IP is an IP address allocated on an external network that Neutron maps to the private IP of
an instance. Floating IP addresses are assigned to an instance so that they can connect to external networks and
access the Internet. Neutron achieves the mapping of floating IPs to the private IP of the instance by using
Network Address Translation (NAT).
The Neutron architecture
Three main components:

1. Neutron server: It accepts API requests and routes them to the appropriate Neutron plugin
for action.

2. Neutron plugins: They perform the actual work for the orchestration of backend devices such
as the plugging in or unplugging ports, creating networks and subnets, or IP addressing.

3. Neutron agents: Neutron agents run on the compute and network nodes. The agents receive
commands from the plugins on the Neutron server and bring the changes into effect on the
individual compute or network nodes. Different types of Neutron agents implement different
functionality.

Neutron is a service that manages network connectivity between the OpenStack instances. It ensures that the
network will not be turned into a bottleneck or limiting factor in a cloud deployment and gives users real self-
service, even over their network configurations.
Gathering pieces and building a picture
1. Authentication is the first action performed. This is where Keystone comes into the picture. Keystone authenticates the user
based on credentials such as the username and password.
2. The service catalog is then provided by Keystone. This contains information about the OpenStack services and the API
endpoints.
3. You can use the Openstack CLI to get the catalog:

$ openstack catalog list

4. Typically, once authenticated, you can talk to an API node.

Starting with the identity service, the following steps summarize briefly the provisioning workflow based on API calls in
OpenStack:
● Calling the identity service for authentication Generating a token to be used for subsequent calls
● Contacting the image service to list and retrieve a base image Processing the request to the compute service API
● Processing compute service calls to determine security groups and keys Calling the network service API to determine
available networks Choosing the hypervisor node by the compute scheduler service Calling the block storage service
API to allocate volume to the instance
● Spinning up the instance in the hypervisor via the compute service API call Calling the network service API to allocate network
resources to the instance
A sample architecture setup
OpenStack deployment

Three phases of design:

1. Conceptual model
2. Logical model
3. Physical design.
1.Conceptual model

We are following an incremental design approach, within which we

should exploit the flexibility of the OpenStack architecture.
2. Logical model
In this section we will look at the deployment
architecture of OpenStack. We will start by identifying
nodes to run an OpenStack service: the cloud controller,
network nodes, and the compute node.

This includes several essential solutions for a highly-

scalable and redundant OpenStack environment such
as virtual IP (VIP), HAProxy, and Pacemaker.

Compute nodes are relatively simple as they are

intended just to run the virtual machine's workload. In
order to manage the VMs, the nova-compute service
can be assigned for each compute node.
Logical networking design
OpenStack allows a wide ranging of configurations that variation, and tunneled networks such as GRE,
VXLAN, and so on, with Neutron are not intuitively obvious from their appearance to be able to be
implemented without fetching their use case in our design.

A major advantage of Neutron compared to nova-network, which is the virtualization of

Layers 2 and 3 of the OSI network model.
3. Physical model design
Estimating hardware capabilities
Since the architecture is being designed to scale horizontally, we can add more
servers to the setup. We will start by using commodity class, cost-effective
hardware.

In order to expect our infrastructure economy, it would be great to make some basic
hardware calculations for the first estimation of our exact requirements.
Considering the possibility of experiencing contentions for resources such as CPU,
RAM, network, and disk, you cannot wait for a particular physical component to
fail before you take corrective action, which might be more complicated.
CPU calculations
● The formula for calculating the total number of CPU cores is as follows:
(number of VMs x number of GHz per VM) / number of GHz per core

● The formula for calculating the number of core CPU sockets is as follows:

Total number of sockets / number of sockets per server

● The formula for calculating the number of socket servers is as follows:

Total number of sockets / Number of sockets per server

● The number of virtual machines per server with eight dual socket servers is calculated as follows:
Number of virtual machines / number of servers
Memory calculations
● Considering the number of sticks supported by your server, you will need around 256 GB installed.
Therefore, the total number of RAM sticks installed can be calculated in the following way:
Total available RAM / MAX Available RAM-Stick size

Network calculations
Let's have a look at the following assumptions:

● 200 Mbits/second is needed per VM

● Minimum network latency

By using a 10GB link for each server

10,000 Mbits/second / 25VMs = 400 Mbits/second
Storage calculations
Considering the previous example, you need to plan for an initial storage capacity per server that will
serve 25 VMs each.
A simple calculation, assuming 100 GB ephemeral storage per VM, will require a space of

25*100 = 2.5 TB of local storage on each compute node.

You can assign 250 GB of persistent storage per VM to have 25*250 = 5 TB of persistent storage per
compute node.

Most probably, you have an idea about the replication of object storage in OpenStack, which implies the
usage of three times the required space for replication.
In other words, if you are planning for X TB for object storage, your storage requirement will be 3X.