Architecture

Architecture

Official OpenStack Project Teams, produce the various deliverables of the OpenStack family (or help other teams achieve that mission). All official OpenStack project teams are under the OpenStack Technical Committee oversight. OpenStack Project Teams

Architecture :: Components High Level

  • Control (Node)

    • Application Programming Interfaces (API) services

    • Web Interface

    • Database (Separate Node)

      • MySQL

      • MariaDB

      • PostgreSQL

    • Message Bus (Separate Node)

      • RabbitMQ

      • Qpid

      • ActiveMQ

  • Network

    • Networking Service Agents

      • LinuxBridge

      • OpenVSwitch

  • Compute

    • Virtualization Hypervisor

Architecture :: Components Low level

  • Dashboard

    • Web Interface

    • Horizon

      • Framework

  • Identity Service

    • Keystone

      • Tenants (a grouping of objects), Users, and Roles

        • Objects: Users, instances, and networks

      • Catalog of Services and Endpoints

  • Image Service

  • Networking

    • Neutron

      • Software Defined Networking

      • Networking as a Service (NaaS)

      • Modular Layer 2 Plugin

      • Multiple Topologies

        • Local

        • Flat

        • VLAN

        • GRE

        • VXLAN

      • Uses Open vSwitch: virtual managed switch

        • Vendor Plugins Physical Managed Switch

  • Compute

    • Key pair and a security group required before instancing

    • Nova

      • Multi-Hypervisor Support

        • KVM

        • Xen

        • vShpere

        • Hyper-V

  • Storage

    • Object Storage

      • Swift (http / https)

        • Architecture

          • Proxy Server

          • Storage Server

            • Disk, Distribution

            • Replication, 3 Copies

        • Process

          • Account

          • Container

          • Filename Object

    • Block Storage

      • Cinder

        • Volumes and Snapshots

        • Similar to AWS Elastic Block Storage

        • Survive the termination of an instance

        • Logical Volume Manager (LVM), GlusterFS, Ceph, Others

  • Telemetry

    • Ceilometer

      • General-Purpose Telemetry System

      • Resource Measurements, Monitor

      • Meter > Sample > Statistic || Alarms

  • Orchestration

    • Heat

      • Managing the entire lifecycle of infrastructure and applications

      • Coordinate launching the instances, passing configuration data, and executing simple post-boot configuration

      • Template: what will be launched

      • AWS CloudFormation templates and language

  • Bare Metal

    • Ironic

Architecture :: Sample Architectures

  • Packt Publishing: OpenStack Essentials

    • Control Node

      • eth0 192.168.123.0/24 Private

      • eth1 192.168.122.0/24 Public

    • Network Node

      • eth0 192.168.123.0/24 Private

      • eth1 192.168.122.0/24 Public

    • Compute Node

      • eth0 192.168.123.0/24 Private

      • eth1 192.168.122.0/24 Public

Architecture :: Walter Bentley wbentley15

RSVP required. So the concept and capability of running multiple OpenStack cloud regions is not a new one. With that said have you actually seen it done? How can this strategy be used to replace a disaster recovery design? What are the components you need to accomplish this design model and have it scale if needed? This workshop will walk attendees thru a few use cases of setting up an Active-Active cloud region and then physically demonstrate how to accomplish this design with attendee parti.

PreviousOpenStackNextDocumentation

Last updated