Jump to: navigation, search

Difference between revisions of "Murano"

(More info)
m (More info)
Line 75: Line 75:
 
* Installation Guide: http://murano.mirantis.com/content/ch05.html
 
* Installation Guide: http://murano.mirantis.com/content/ch05.html
 
* Sources:  
 
* Sources:  
**https://github.com/Mirantis/murano-agent
+
**https://github.com/stackforge/murano-agent
**https://github.com/Mirantis/murano-agent
+
**https://github.com/stackforge/murano-agent
**https://github.com/Mirantis/murano-docs
+
**https://github.com/stackforge/murano-docs
**https://github.com/Mirantis/murano-deployment
+
**https://github.com/stackforge/murano-deployment
**https://github.com/Mirantis/murano-tests
+
**https://github.com/stackforge/murano-tests
**https://github.com/Mirantis/murano-conductor
+
**https://github.com/stackforge/murano-conductor
**https://github.com/Mirantis/murano-dashboard
+
**https://github.com/stackforge/murano-dashboard
**https://github.com/Mirantis/python-muranoclient
+
**https://github.com/stackforge/python-muranoclient
 
* Launchpad project: https://launchpad.net/murano
 
* Launchpad project: https://launchpad.net/murano

Revision as of 12:05, 17 May 2013

Project Background

Enterprise customers frequently use Windows-based environments for their internal and external products. Configuration of the Windows environment is a complex task which usually requires a lot of effort from administrators. Windows setup consists of numerous services which might be tightly coupled to each other. While the automated installation of Windows services can be fairly straightforward, service configuration can be hard to automate because it requires a well-designed Windows architecture and deep knowledge of Windows services configuration.

Currently several open source solutions exists that can help to partially solve automation of Windows environment provisioning. In the world of OpenStack there is the Heat project, which is similar to Amazon Cloud Formation. Heat is an excellent tool for managing OpenStack cloud resources such as VM instances, security groups, and so on. It allows you to define all cloud resources in a single JSON template, then later maintain all of those resources by editing that template. Although the declarative template approach is well suited to OpenStack resources, it quickly becomes complex when it comes to application management.

Another option is a tool such as Chef or Puppet. These tools are flexible, but require you to have a deep knowledge of scripting and require a significant amount of effort to manually script or modify cookbooks for your specific environment configuration. This is manageable in a stable environment, but it becomes time-consuming and involves manual script coding when one needs to deploy various environments with rapidly changing configurations. Also Chef and Puppet require additional infrastructure to support them.

The biggest problem for both approaches above is in supporting multi-step configuration of services with circular dependencies required for correct configuration of Windows services. This can be solved by using external orchestration.

Another potential problem is the lack of UI functionality enabling creation and configuration of an environment without writing a script.

Proposal

Mirantis proposes to introduce a new service which will allow a non-experienced user to deploy reliable Windows based environments in a “push-the-button” manner. The key goal is to provide a UI and API enabling the deployment and operation of Windows Environments at the Windows Services abstraction level. The service should be able to orchestrate complex circular dependent cases in order to set up a complex Windows Environment with multiple dependant services.

The service will address following use cases:

  • Self-provisioning of predefined Windows services with their dependencies
  • Automation of administrative tasks during data center roll-out
  • Custom windows application as a windows service

The solution will provide higher level of abstraction for manipulation Windows Environments. Key concepts are:

  • Windows Service - a service such as Active Directory, MSSQL, or IIS, which usually consists of multiple virtual machines and has multiple dependencies.
  • Windows Environment - a logical unit for all Services and represents a classical Windows Datacenter
  • Windows VM instance - a VM which hosts a Windows Service. A Windows Service might be deployed over several Windows VM instances.

The Key Features of the Service are the following:

  1. Native to OpenStack
  2. Introduces abstraction level for Windows Environments
  3. Supports Availability Zones and Disaster Recovery scenarios
  4. Uses native Windows features for HA solutions

Architecture Details

The Murano Service communicates with the following OpenStack components:

  • Horizon - provides a GUI with ability to use all Murano features;
  • Keystone - authenticates users and provides the security token that is used to work with OpenStack, hence limiting the user abilities in Murano based on OpenStack privileges;
  • Heat - is used to provision VMs and other OpenStack resources for Windows Environments;
  • Glance - stores Windows Server VM images, with each image containing an installed OS and a set of scripts
  • Quantum - provides the network configuration API
  • Agent - provides agent functionality to communicate with the Orchestration Engine and executes tasks on VMs

Murano architecture diagram.png

REST API

Murano exposes a service endpoint for communication with a client. It exposes API functions to manipulate objects such as environment and service.

This component is responsible for translating API function parameters to Object Model attributes and propagating the deployment status from the Orchestration Engine.

Object Model

An internal representation of Windows Services and Environments. All attributes and entities are described in API specification.

Orchestration Engine

This is the core component which evaluates Object Model changes and creates a plan for implementing these changes on the instances or in the cloud. This component will support extensions via plug-ins. Plugins can add new services and extend existing services for integration. Currently there are two services which are already implemented as plugins. They are Active Directory and IIS Service.

Integration with Heat

Heat is a cloud resource management engine that allows you to manipulate resources that represent OpenStack entities (Security Groups, Instances, Floating IPs, Volumes, etc.) and some entities such as AutoScaling groups from a single point of control.

OpenStack resource provisioning is one of the steps required for environment deployment and Heat will be used for that purpose. Heat allows you to define all OpenStack resources in a single document that will be easy to maintain and will not require resorting to multiple OpenStack APIs while keeping the software configuration separate.

Windows on OpenStack

Windows works on KVM pretty smoothly, and with the RedHat-created open-source VirtIO drivers for Windows, it’s possible to work efficiently with KVM exposed devices.

In OpenStack’s Grizzly release, Microsoft’s hypervisor Hyper-V will be supported. The Hyper-V virtual switch will be also supported as a Quantum plug-in. From the performance viewpoint, Hyper-V Server 2012 compares very favorably with bare metal, processing just fewer transactions per second compared to the same workload running on a similarly configured physical server. (Microsoft SQL OLTP Performance)(Microsoft Server & Cloud Blog) Also, unlike the current OpenStack, Hyper-V also natively supports Windows Clusters.

Roadmap

Please refer to Murano/Roadmap for details.

Hot To Contribute

If you would like to ask some questions or make proposals, feel free to reach us on #murano irc channel at FreeNode. Typically somebody from our team will be online at irc from 6:00 to 20:00 UTC. You can also contact Murano community directly by murano@lists.launchpad.net (please, note that your email address should be registered in launchpad, otherwise your mail will be ignored by mailing system).

We’re going to hold public weekly meetings on Mondays at 18:00 UTC on #openstack-meeting-alt irc channel. Refer to Meetings.

If you want to contribute either to docs or to code, simply send us change request via review.openstack.org. You can file bugs and register blueprints at Murano launchpad page.

More info