Jump to: navigation, search

Difference between revisions of "Mogan"

(OpenStack Bare Metal Computing)
Line 1: Line 1:
= OpenStack Bare Metal Computing =
+
= OpenStack Bare Metal Compute =
 +
 
 +
Without Twists and Turns, Mogan, for Bare Metal Compute As A Service
  
 
== Why Mogan? ==
 
== Why Mogan? ==
Line 15: Line 17:
 
Mogan, from the get go is all about Bare Metal provisioning in all its richness, no twists and turns, for an elegant sculpture. The Mogan API allows you to both provision bare metal and compose bare metal through integration with OpenStack Valence that leverages the Redfish API to compose nodes using disaggregated resources.
 
Mogan, from the get go is all about Bare Metal provisioning in all its richness, no twists and turns, for an elegant sculpture. The Mogan API allows you to both provision bare metal and compose bare metal through integration with OpenStack Valence that leverages the Redfish API to compose nodes using disaggregated resources.
  
=== Architecture ===
+
The figure below describes how Mogan interact with other OpenStack services to manage bare metal servers.
 +
 
 +
[[File:Mogan-workflow.png|700px|mogan detailed workflow]]
 +
 
 +
== Architecture ==
  
==== Services ====
+
=== Services ===
 
* '''mogan-api''': Provides an OpenStack native REST API that processes API requests by sending them to the mogan-engine over RPC.
 
* '''mogan-api''': Provides an OpenStack native REST API that processes API requests by sending them to the mogan-engine over RPC.
 
* '''mogan-engine''': Interacts with other OpenStack services (like cinder, neutron, glance, etc) through REST API. It transforms and dispatches the user request to drivers to provision bare metal instances.
 
* '''mogan-engine''': Interacts with other OpenStack services (like cinder, neutron, glance, etc) through REST API. It transforms and dispatches the user request to drivers to provision bare metal instances.
 
* '''mogan-scheduler''': The scheduler service to help select nodes according to users' request, which will integrate with Placement service.
 
* '''mogan-scheduler''': The scheduler service to help select nodes according to users' request, which will integrate with Placement service.
  
==== Drivers ====
+
=== Drivers ===
 
Mogan has an abstraction layer for bare metal provisioning drivers. This is what allows you to choose which hypervisor to use for your Mogan deployment.  
 
Mogan has an abstraction layer for bare metal provisioning drivers. This is what allows you to choose which hypervisor to use for your Mogan deployment.  
 
Ironic is the default driver and the main driver we supported, but it's possible to add more provision tools support like maas, cloudboot, etc.
 
Ironic is the default driver and the main driver we supported, but it's possible to add more provision tools support like maas, cloudboot, etc.
Line 28: Line 34:
 
[[File:Mogan-architecture.png|700px|architecture]]
 
[[File:Mogan-architecture.png|700px|architecture]]
  
==== Scheduler ====
+
=== Scheduler ===
  
 
The Placement service is intended to enable more effective accounting of resources and better scheduling of various entities in the cloud. Mogan already migrated resources tracking to Placement service, that makes each ironic node a "resource provider", which has a custom resource class that reference the flavor, in short saying that the flavor requires exactly one thing from that resource class. Nova also has a plan for scheduling ironic resources like this way, but as the flavor contains many virtual machines related stuff, the process is slow.
 
The Placement service is intended to enable more effective accounting of resources and better scheduling of various entities in the cloud. Mogan already migrated resources tracking to Placement service, that makes each ironic node a "resource provider", which has a custom resource class that reference the flavor, in short saying that the flavor requires exactly one thing from that resource class. Nova also has a plan for scheduling ironic resources like this way, but as the flavor contains many virtual machines related stuff, the process is slow.
Line 60: Line 66:
 
         Intel(R) Xeon(R) E5620 2.40GHz 16 cores, 8GB RAM 4*TB SSD, 4*10Gbps Ethernet
 
         Intel(R) Xeon(R) E5620 2.40GHz 16 cores, 8GB RAM 4*TB SSD, 4*10Gbps Ethernet
  
 
===== Mogan and Placement interactions =====
 
  
 
The figure below describes how Mogan interact with Placement service.
 
The figure below describes how Mogan interact with Placement service.
Line 80: Line 84:
 
Mogan Server Groups, make sure servers are on the same or different *affinity zone*, which is quite like nova's server groups, but nova only support *host* based affinity or anti-affinity.
 
Mogan Server Groups, make sure servers are on the same or different *affinity zone*, which is quite like nova's server groups, but nova only support *host* based affinity or anti-affinity.
 
We plan to add a special aggregate metadata key *affinity zone* in Mogan. You may define it as failure domains (e.g., by power circuit, rack, room, etc), or whatever you want to make affinity and anti-affnity happen in such groups. More details can be found on Mogan docs after Pike.
 
We plan to add a special aggregate metadata key *affinity zone* in Mogan. You may define it as failure domains (e.g., by power circuit, rack, room, etc), or whatever you want to make affinity and anti-affnity happen in such groups. More details can be found on Mogan docs after Pike.
 
=== Interaction Details ===
 
 
The figure below describes how Mogan interact with other OpenStack services to manage bare metal servers.
 
 
[[File:Mogan-workflow.png|700px|mogan detailed workflow]]
 
  
 
=== RSD Integration ===
 
=== RSD Integration ===

Revision as of 09:28, 22 July 2017

OpenStack Bare Metal Compute

Without Twists and Turns, Mogan, for Bare Metal Compute As A Service

Why Mogan?

OpenStack Nova supports provisioning of virtual machines (VMs), bare metal and containers. True, BUT, Nova design started off as a virtual machine scheduler, with features specific to this use case. Nova enhancements to unify requesting any compute instance, be it VM, container or Bare Metal, while wonderful, unfortunately is convoluted at best, requiring the user to execute additional steps. Further, it does not yet support the more advanced requirements of bare metal provisioning such as storage and network configuration.

  • All Ironic nodes are associated with a single host aggregate in Nova, because of the notion that a compute *service* is equal to the compute *node*.
  • No affinity/anti-affinity support for bare metals in Nova, as it's based on *host*.
  • No specific APIs for bare metals like RAID configuration, Advanced partitioning at deploy time, Firmware management, etc.

nova-mogan

What is Mogan?

Mogan, from the get go is all about Bare Metal provisioning in all its richness, no twists and turns, for an elegant sculpture. The Mogan API allows you to both provision bare metal and compose bare metal through integration with OpenStack Valence that leverages the Redfish API to compose nodes using disaggregated resources.

The figure below describes how Mogan interact with other OpenStack services to manage bare metal servers.

mogan detailed workflow

Architecture

Services

  • mogan-api: Provides an OpenStack native REST API that processes API requests by sending them to the mogan-engine over RPC.
  • mogan-engine: Interacts with other OpenStack services (like cinder, neutron, glance, etc) through REST API. It transforms and dispatches the user request to drivers to provision bare metal instances.
  • mogan-scheduler: The scheduler service to help select nodes according to users' request, which will integrate with Placement service.

Drivers

Mogan has an abstraction layer for bare metal provisioning drivers. This is what allows you to choose which hypervisor to use for your Mogan deployment. Ironic is the default driver and the main driver we supported, but it's possible to add more provision tools support like maas, cloudboot, etc.

architecture

Scheduler

The Placement service is intended to enable more effective accounting of resources and better scheduling of various entities in the cloud. Mogan already migrated resources tracking to Placement service, that makes each ironic node a "resource provider", which has a custom resource class that reference the flavor, in short saying that the flavor requires exactly one thing from that resource class. Nova also has a plan for scheduling ironic resources like this way, but as the flavor contains many virtual machines related stuff, the process is slow.

The resource tracking model is as the following

   resource classes:               CUSTOM_GOLD                    CUSTOM_SILVER
                                   /         \                          |
   resource providers: baremetal_node1     baremetal_node2       baremetal_node2
                              |                   |                     |
   inventories:       {'CUSTOM_GOLD': 1}   {'CUSTOM_GOLD': 1}  {'CUSTOM_SILVER': 1}

However, A parent->child relationship would be more appropriate here to handle NIC/DISK resources on a node. When Placement Nested Resource Providers landed, we will consider to change the tracking model.

Operators may define flavors like this

 - baremetal-gold
     resources:
       baremeal_gold: 1
     resource_traits:
       baremetal_gold: row1rack6
     description:
       Intel(R) Xeon(R) E5620 2.40GHz 16 cores, 8GB RAM, 4*TB SSD, 4*10Gbps Ethernet
   - baremetal-RSD-gold
     resources:
       valence-gold-flavor: 1
     resource_traits:
       valence-gold-flavor: PodM1
     description:
       Intel(R) Xeon(R) E5620 2.40GHz 16 cores, 8GB RAM 4*TB SSD, 4*10Gbps Ethernet


The figure below describes how Mogan interact with Placement service.

placement

Node Aggregates

Node aggregate allows the partition of baremetal nodes into logical groups for server distribution. which is quite like Nova host aggregate, but we are based on baremetal nodes.

The figure below describes how we match flavors with aggregates and interact with Placement service.

aggregate


Server Groups

Mogan Server Groups, make sure servers are on the same or different *affinity zone*, which is quite like nova's server groups, but nova only support *host* based affinity or anti-affinity. We plan to add a special aggregate metadata key *affinity zone* in Mogan. You may define it as failure domains (e.g., by power circuit, rack, room, etc), or whatever you want to make affinity and anti-affnity happen in such groups. More details can be found on Mogan docs after Pike.

RSD Integration

Rack Scale Design (RSD) implementations represent the next generation of Software Defined Infrastructure that can be dynamically provisioned across compute, network and storage resources.The fundamental premise for an RSA-based solution is the customers’ ability to “right-size” their end-to-end infrastructure needs according to anticipated workload performance and capacity requirements, across pooled resources.

VALENCE[1] is a controller for pooled and composable resources which adhere to DMTF[2] Redfish[3] with hardware management requests. That includes provisioning and management of RSD components and underlay features.

mogan RSD


Mogan Mission Statement

1. To implement services which focus on the management of bare metal computing resources.

2. To promote the speed of bare metal development in OpenStack.

Use Cases

1. A cloud provider wants to deliver vm and bare metal services separately with different capabilities instead of just one service including both vms and bare metals.

2. An enterprise user wants to leverage their already deployed provision tools(instead of Ironic) to provide bare metal cloud by adding a driver to Mogan.

3. An enterprise user wants to manage the RSD(Rack Scale Design) and general hardware in a unified manner.

4. An enterprise user wants more bare metal specific capabilities like Hard Drive, Nics Bond, Firmware, etc management.

Projects

mogan

Source code https://github.com/openstack/mogan
Bug tracker https://bugs.launchpad.net/mogan
Feature tracker https://blueprints.launchpad.net/mogan
Weekly meetings https://wiki.openstack.org/wiki/Meetings/Mogan

python-moganclient

Source code https://github.com/openstack/python-moganclient
Bug tracker https://bugs.launchpad.net/python-moganclient
Feature tracker https://blueprints.launchpad.net/python-moganclient

mogan-ui

Source code https://github.com/openstack/mogan-ui
Bug tracker https://bugs.launchpad.net/mogan-ui
Feature tracker https://blueprints.launchpad.net/mogan-ui

IRC

Discussion of the project also takes place in #openstack-mogan on irc.freenode.net. This is a great place to jump in and start your mogan adventure.

Developers

Guidelines for developers can be found here: https://wiki.openstack.org/wiki/Ironic/Developer_guidelines Please note that for any non-trivial change that is not a fix for a particular bug, you have to go through the specs review process

For more information please refer to our dev-quickstart doc Mogan devref

FAQ

1) What's the relationship between Mogan and Nova?

Compared with Nova, Mogan is dedicated for bare metals, it's more lightweight and with more baremetal specific features which VM users don't need. Nova provides a unified manner for all compute resources management.

2) Does Mogan compete with Nova?

We do not intend to compete with Nova. Nova focuses on VM management and provides many advanced features like live migrating, availability zone, host aggregates, etc. The ironic driver allows to manage baremetals via Nova's API (which is unified for VMs, baremetals, and containers, but in fact, it's customized for VMs). Baremetal instance in Nova seems like a special VM which ocuppies all resources of the compute node, While Mogan is designed specifically for baremetals, it makes real baremetal support for OpenStack with multiple baremetal hypervisors like ironic, maas, cloudboot, etc.

3) What's the relationship with Mogan and Ironic?

Ironic is integrated into Mogan as a driver, which will be used to deploy(part of provisioning) baremetal node. And also Mogan leverage Ironic API to manage node’s lifecycle.

4) What's the relationship with Mogan and Valence?

Valence is a RSD controller for pooled and composable resources, it provide compose API for pooled resource, and also Redfish endpoint to control composed node. Mogan will contact with RSD through Valence to compose resouces then enroll the composed node to ironic and provision the node like generic nodes.

References

[1] https://wiki.openstack.org/wiki/Valence

[2] https://www.dmtf.org/standards/redfish

[3] https://www.dmtf.org/