Skip to content
Agile Enterprise Architecture
  • Home
  • Services
    • Remote Services
      • Looking for EA modelling?
      • Why Arch-as-a-Service?
      • Modelling-as-a-Service
      • Assess Arch Maturity Free
      • Arch Modelling Notations
        • Archimate model types
        • Quadrant model types
        • Canvas model types
        • UML model types
        • BPMN Model types
        • DMN Model types
        • ERD Model types
        • Structured Info types
        • Cisco model types
      • Arch Modelling tools
    • Consultancy Services
      • Digital Integration Services
      • Business Architecture
      • Health check services
        • Arch Risk Assessment
        • Arch Governance checkup
        • Arch Models health check
        • Arch Content health check
    • Cloud Hosting services
      • EA SaaS – Orbus iServer
      • EA SaaS – EVA Netmodeler
      • EA SaaS – Dragon1
      • Meta-Model Structuring
  • Blogs
  • About
    • Our AgileEA Business Model
    • Our AgileEA Principles
      • Open & Transparent
      • Value for money
      • Keep it simple
      • Love what we do
      • Efficient & effective
    • Location

Blogs

Cloud Openstack

OpenStack Cloud Object Storage in Archimate – Part 7

  • 2017-04-282018-05-08
  • by Charles

Previous

This blog on Openstack modelled using Archimate follows on from the previous Blog on OpenStack Cloud Images in Archimate – Part 6

Swift = Object Storage

The OpenStack Object Store project, known as Swift, offers cloud storage software so that you can store and retrieve lots of data with a simple API. It’s built for scale and optimized for durability, availability, and concurrency across the entire data set. Swift is ideal for storing unstructured data that can grow without bound.

Swift is a highly available, distributed, eventually consistent object/blob store. Organizations can use Swift to store lots of data efficiently, safely, and cheaply. It’s built for scale and optimized for durability, availability, and concurrency across the entire data set. Swift is ideal for storing unstructured data that can grow without bound.

Swift - Object Storage Architectural Motivation

Swift = Object Storage Structural Logical Architecture

The Object Storage system organizes data in a hierarchy, as follows:

  • Account. Represents the top-level of the hierarchy.  Your service provider creates your account and you own all resources in that account. The account defines a namespace for containers. A container might have the same name in two different accounts. In the OpenStack environment, account is synonymous with a project or tenant.
  • Container. Defines a namespace for objects. An object with the same name in two different containers represents two different objects. You can create any number of containers within an account. In addition to containing objects, you can also use the container to control access to objects by using an access control list (ACL). You cannot store an ACL with individual objects. In addition, you configure and control many other features, such as object versioning, at the container level. You can bulk-delete up to 10,000 containers in a single request. You can set a storage policy on a container with predefined names and definitions from your cloud provider.
  • Object. Stores data content, such as documents, images, and so on. You can also store custom metadata with an object.

Swift - Object Storage Structural Logical Architecture

Swift = Object Storage Behavioural Services Architecture

These are the REST & CLI Services offered by Swift for Object 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/object-storage/index.html 

Swift - Object Storage Behavioural Services Architecture

Next

The next blog in the series is OpenStack Cloud Identity in Archimate – Part 8

 

Cloud Openstack

OpenStack Cloud Images in Archimate – Part 6

  • 2017-04-282018-05-08
  • by Charles

Previous

This blog on Openstack modelled using Archimate follows on from the previous Blog on OpenStack Cloud Block Storage in Archimate – Part 5.

Glance = Images

Mission: The Image service (glance) provides a service where users can upload and discover data assets that are meant to be used with other services. This currently includes images and metadata definitions.

What is a virtual machine image? A virtual machine image is a single file which contains a virtual disk that has a bootable operating system installed on it. Virtual machine images come in different formats: Raw, AKI, AMI, ARI, ISO, OVF, QCOW2, UEC Tarball, VDI, VHD, VHDX, VMDK.

Glance image services include discovering, registering, retrieving and format converting virtual machine (VM) images. Glance has a RESTful API that allows querying of VM image metadata as well as retrieval of the actual image.

Glance = Images Storage Architectural Goals

Glance = Images Structural Logical Architecture

Glance image services include discovering, registering, and retrieving virtual machine images. Glance has a RESTful API that allows querying of VM image metadata as well as retrieval of the actual image. VM images made available through Glance can be stored in a variety of locations from simple filesystems to object-storage systems like the OpenStack Swift project.

Glance = Images Structural Logical Architecture

Glance = Images Behavioural Services Architecture

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

Glance = Images Behavioural Services Architecture

Next

The next blog in the series is OpenStack Cloud Object Storage in Archimate – Part 7

Cloud Openstack

OpenStack Cloud Block Storage in Archimate – Part 5

  • 2017-04-272018-05-08
  • by Charles

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.

Cinder - Block Storage Architectural Goals

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 Structural Logical Architecture

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

Cinder = Block Storage Behavioural Services Architecture

Next

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

Cloud Openstack

OpenStack Cloud Compute in Archimate – Part 4

  • 2017-04-272018-05-08
  • by Charles

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 Architectural Goals

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 Structural Logical Architecture

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)

Nova = Compute Behavioural Services Architecturewidth=

Next

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

Cloud Openstack

OpenStack Cloud Networking in Archimate – Part 3

  • 2017-04-272018-05-08
  • by Charles

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.

Neutron = Networking Architectural Goals

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.

Neutron = Networking Structural Logical Architecture

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

Neutron = Networking Architectural Services offered

Next

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

Posts navigation

1 2 3 4 … 9

Categories

Tags

Agile AgileEA-Process archimate architecture practice business-arch Business Uses cases Capabilities cloud culture Data Architecture Enterprise Architecture health checks IoT maturity openstack Requirements Services strategy System Use Cases techical debt train44ir Use Cases Values visual models

Recent Posts

  • Announcing Our Train44Ir.org charity 2020-04-24
  • Data Fabric Framework – Archimate 3.0 model 2018-05-10
  • OpenStack Cloud Metering in Archimate – Part 10 2017-04-28
  • OpenStack Cloud Orchestration in Archimate – Part 9 2017-04-28
  • OpenStack Cloud Identity in Archimate – Part 8 2017-04-28
  • OpenStack Cloud Object Storage in Archimate – Part 7 2017-04-28
  • OpenStack Cloud Images in Archimate – Part 6 2017-04-28
  • OpenStack Cloud Block Storage in Archimate – Part 5 2017-04-27
  • OpenStack Cloud Compute in Archimate – Part 4 2017-04-27
  • OpenStack Cloud Networking in Archimate – Part 3 2017-04-27
  • OpenStack Cloud Dashboard in Archimate – Part 2 2017-04-27
  • OpenStack Cloud in Archimate – Part 1 2017-04-27
  • Hosting and Cloud Software Delivery modelled in Archimate 2017-04-19
  • Why do Architecture Maturity Assessments regularly? 2017-03-22
  • Archimate 3.0 introductory basics videos 2017-02-28
  • Example Services and Capabilities with Meta-Model 2014-11-09
  • Why a CV in Archmate? 2014-07-14
  • Charles Edwards Archimate CV 2014-07-10
  • EA Conference 2009 – Agile EA: A Step change is required 2009-06-13
  • Who should own Enterprise Architecture? 2009-03-28

Previous Posts

Our Twitter Feed

My Tweets

Recent Comments

    Translate site

    Tag Cloud

    Agile AgileEA-Process archimate architecture practice business-arch Business Uses cases Capabilities cloud culture Data Architecture Enterprise Architecture health checks IoT maturity openstack Requirements Services strategy System Use Cases techical debt train44ir Use Cases Values visual models

    Blogs about

    AgileEA Process Blogs Charity Cloud Openstack Enterprise Architecture Health checks Information & Data Modelling Strategy Technical Debt Thoughts Use Cases
    Copyright: Time 2 Talk CC T/A AgileEa.com, 2006 - 2023.
    Theme by Colorlib Powered by WordPress
    Agile Enterprise Architecture
    Proudly powered by WordPress Theme: Shapely.
     

    Loading Comments...
     

    You must be logged in to post a comment.