OpenStack Cloud Block Storage in Archimate – Part 5

Previous

This blog on Openstack modelled using Archimate follows on from the previous Blog on OpenStack Cloud Compute in Archimate – Part 4.

Cinder = Block Storage

Cinder is a Block Storage service for OpenStack.

Mission: To implement services and libraries to provide on demand, self-service access to Block Storage resources. Provide Software Defined Block Storage via abstraction and automation on top of various traditional back-end block storage devices.

The block storage system manages the creation, attaching and detaching of the block devices to servers. Block storage volumes are fully integrated into OpenStack Compute and the Dashboard allowing for cloud users to manage their own storage needs. In addition to local Linux server storage, it can use storage platforms including Ceph, CloudByte, Coraid, EMC (VMAX and VNX), GlusterFS, IBM Storage (Storwize family, SAN Volume Controller, XIV Storage System, and GPFS), Linux LIO, NetApp, Nexenta, Scality, SolidFire and HP (StoreVirtual and StoreServ 3Par families).

Cinder = Block Storage Structural Logical Architecture

Cinder virtualizes the management of block storage devices in software. Cinder provides end users with a self-service REST or CLI API to request and consume those resources without requiring any knowledge of where their storage is actually deployed or on what type of device. This is done through the use of either a reference implementation (LVM) or plugin drivers for other storage.

Cinder uses a sql-based central database that is shared by all Cinder services in the system. The amount and depth of the data fits into a sql database quite well. For small deployments this seems like an optimal solution. For larger deployments, and especially if security is a concern, cinder will be moving towards multiple data stores with some kind of aggregation system.

The Auth Manager component responsible for users/projects/and roles. Can back-end to DB or LDAP. This is not a separate binary, but rather a python class that is used by most components in the system.

The scheduler: decides which host gets each volume.

A volume: manages dynamically attachable block devices. There can be many of these of different types each of which has a specific driver.

Cinder = Block Storage Behavioural Services Architecture

These are the REST & CLI Services offered by Cinder for Block Storage. For each Service below there are one or many sub-services or commands that can be found here: https://developer.openstack.org/api-ref/block-storage/v3

Next

The next blog in the series is OpenStack Cloud Images in Archimate – Part 6.

OpenStack Cloud Compute in Archimate – Part 4

Previous

This blog on Openstack modelled using Archimate follows on from the previous Blog on OpenStack Cloud Networking in Archimate – Part 3.

Nova = Compute

Mission: To implement services and associated libraries to provide massively scalable, on demand, self-service access to compute resources, including bare metal, virtual machines, and containers.

Nova = Compute Structural Logical Architecture

Nova Application Collaboration is comprised of multiple server processes, each performing different functions. The user-facing interface is a REST API, while internally Nova components communicate via an RPC message passing mechanism called the Conductor Component.

The API servers process REST requests, which typically involve database reads/writes, optionally sending RPC messages to other Nova services, and generating responses to the REST calls. RPC messaging is done via the oslo.messaging library, an abstraction on top of message queues. Most of the major nova components can be run on multiple servers, and have a manager that is listening for RPC messages. The one major exception is nova-compute, where a single process runs on the hypervisor it is managing (except when using the VMware or Ironic drivers).

Nova also uses a central database that is (logically) shared between all components.

Nova = Compute Behavioural Services Architecture

These are the REST & CLI Services offered by Nova for Compute. For each Service below there are one or many sub-services or commands that can be found here: https://developer.openstack.org/api-ref/compute (We also chose not to show all the many Deprecated services)

Next

The next blog in the series is OpenStack Cloud Block Storage in Archimate – Part 5.

OpenStack Cloud Networking in Archimate – Part 3

Previous

This blog on Openstack modelled using Archimate follows on from the previous Blog on OpenStack Cloud Dashboard in Archimate – Part 2.

Neutron = Networking

Mission: To implement services and associated libraries to provide on-demand, scalable, and technology-agnostic network abstraction.

Openstack Neutron offers Network-as-a-Service via REST API’s. It implements Virtual VLAN Networks with Level 2 isolation. It also implements Virtual ports where devices can connect to the virtual network. Neutron implements a pluggable back-end to abstract the API away from different technology choices (e.g. Open vSwitch, Cisco UCS/Nexus). Offers virtual switches, bridges, L3 routing, floating IPs, NAT, DHCP, VPN and Load Balancing.

Implements Software-Defined networking which is the physical separation of network control plane from the forwarding plane using the OpenFlow protocol to control several devices. Uses either Command Line Interface (CLI) or Horizon as a GUI to configure the networking.

Neutron = Networking Structural Logical Architecture

The structural architecture of Neutron is shown in the diagram below. Please note however that even though this all looks like it resides on one single node, components can be split out across multiple Compute Nodes, Controller nodes and Network Nodes.

These are the REST & CLI Services offered by Neutron. For each Service below there are one or many sub-services or commands that can be found here: https://developer.openstack.org/api-ref/networking/v2/index.html

Next

The next blog in the series is OpenStack Cloud Compute in Archimate – Part 4.

OpenStack Cloud Dashboard in Archimate – Part 2

Previous

This blog on Openstack modelled using Archimate follows on from Openstack Cloud in Archimate – Part 1.

Horizon = Dashboard Functionality

Mission: Horizon is the canonical implementation of OpenStack’s dashboard, which is extensible and provides a web based user interface to OpenStack services.

Horizon = Dashboard Structural Logical Architecture

• Is “stateless” — doesn’t require a database.
• Delegates error handling to the back-end.
• Doesn’t support all the API functions exposed by the other Openstack Applications.
• Can use memcached or database to store sessions.
• Gets updated via API polling.
• Uses Django Project, which is a high-level Python Web framework that encourages rapid development and clean, pragmatic design. See more detail on Django here: https://www.slideshare.net/balakumarp/django-framework
• It can be extended.

As mentioned in Part 1., the Openstack Cloud can be managed via a command line interface (CLI). This Dashboard makes is a lot easier to facilitate simple queries and changes, but does not support all the ever evolving services served by all the relevant Applications. To get all the functionality, one would need to connect to the CLI manually or REST services using the API programmatically.

Horizon = Dashboard Behavioural Services Architecture

Horizon does not offer or provide any of its own services, it simply consumes all the services from the other applications. Since in latest blogs we will show all Services offered by each application, nothing will be modelled here.

Next

This next blog in the series is OpenStack Cloud Networking in Archimate – Part 3.

OpenStack Cloud in Archimate – Part 1

Previous

This blog on Openstack modelled using Archimate follows on from the previous Blog on Hosting and Cloud software delivery modelled in Archimate.

Introduction

One of the first things that struck me about the OpenStack cloud software was its naming of elements by the Project names they were/are developed under, which makes it a bit harder to learn, because you not only have to learn the name but also mentally map it to the functionality it provides. So one of the reasons for this blog was to model OpenStack, both to help me learn and understand it but also share the models at the same time.

The second thing that struck me was how well it conforms to the Microservices architectural style, with smallish isolated Applications that are independent and have an API to integrate into the broader context.

Thirdly I wanted to build up an Open Architecture Model using Archimate version 3.0, that would help others in Architecting Cloud Solutions. At the end of the ten part series I will publish this model for download.

This information has been pieced together from information available off openstack.org and google searches. This blog has been written around the Openstack Ocata release from Feb 2017. In other words, it could be wrong in places, because of modelling older versions, etc. If you spot items that are simply wrong and thereby misleading, please contact me and I’ll try and fix the model.

OpenStack Core Services

Openstack Cloud has core application collaborations that offer application services defined as:

• Neutron [Networking] Services
• Nova [Compute] Services
• Glance [Image] Services
• Cinder [Block Storage] Services
• Swift [Object Storage] Services
• Keystone [Identity] Services

Not included in the core list of application collaborations, but core if you don’t want to do command line interface (CLI) interaction and configuration of your cloud is:

• Horizon [Dashboard] – Web GUI for defining and configuring the Core elements

Also – two optional more recent application collaborations as shown in the diagram below

• Heat [Orchestration] Services – Automates provisioning of Compute, Images, Networks & Storage
• Ceilometer [Telemetry / Metering] Services – meters the usage of most core components

The diagram below is not in Archimate, but was one of the simplest clearest models I found to explain the concept at a high level.

There are other optional application collaborations such as Ironic (bare metal service), Fuel (deployment service), Octavia (load balancing service), Trove (database Service), Sahara (Data processing), etc. In fact there are many (+/- 50 odd) optional application collaboration projects.

Core Application Architecture showing behaviour

In Archimate the high level Architectural view would look like the diagram below. Most Openstack core Applications expose behaviour via Application Services through an Application Programming Interface (API) realised by Application Functions, implemented as lower level Application Components and grouped by one Application Collaboration. You will see this coming out in the models in later blogs.

Each Application is built as a project under the project names as described below, and it follows a microservices style architecture. Virtually all Application Functions offer an API that exposes both CLI commands and set of REST based services, so they can be accessed manually as commands or manipulated programmatically for automation. The Dashboard then cleverly uses these same services to offer a User Interface via a Web portal from which to control your cloud configuration.

We will explore each Application Collaboration shown in the white dotted line packages above. We will explore each applications Logical Structured Architecture and the Behavioural Service Architecture in subsequent blogs.

Next

The next blog in the series is OpenStack Cloud Dashboard in Archimate – Part 2.