Jump to: navigation, search

Difference between revisions of "Murano"

m
m (Moved Roadmap to new page)
Line 54: Line 54:
  
 
==Roadmap==
 
==Roadmap==
===Phase 1 Initial Version (Release date: May 30th)===
+
'''Please refer to [[Mirano/Roadmap]] for details.'''
* Core Services: REST API, Orchestration Engine
 
* Horizon dashboard extension as plugin
 
* Integration with Heat
 
* Support single Data Center (no Disaster Recovery)
 
* Support the following Windows Services:
 
** Active Directory -  Single Domain with multiple  domain controllers
 
** IIS Server - single instance of IIS Server
 
** IIS Cluster - multiple IIS instances  with Load Balancing
 
** ASP.NET Application Service - ASP.NET application installed on top of IIS
 
 
 
===Phase 2 - Stable Release (3 month)===
 
* Stabilize Core Services (bug fixing)
 
* Support API, UI extensibility
 
* UI design
 
* Workflow and recipes repository
 
* Data transfer between service instances
 
* Basic Service monitoring
 
* Additional Services:
 
** MS SQL  -  single instance of Microsoft SQL Server or Pair of SQL Servers with DB mirroring
 
 
 
===Phase 3===
 
* Add more services
 
* Services Dependencies support
 
* Extended health monitoring
 
* Agent extensibility (allow 3rd party configuration tools)
 
* Basic Self-healing (actions on monitoring events)
 
* Additional Services
 
 
 
===Phase 4===
 
* Availability Zones support
 
* Auto-scaling for Windows services
 
* Security improvements
 
  
 
==Hot To Contribute==
 
==Hot To Contribute==

Revision as of 07:05, 29 April 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 efforts from the administrators. Windows setup consists of numerous services which might be tightly coupled to each other. Windows services installation might be automated pretty straightforward but service configuration itself might be a hard to automate because it requires to have well designed Windows Architecture and deep knowledge in Windows Services configuration.

Currently there are several projects that aim to solve the same problems. In the world of OpenStack there is a Heat project that is similar to Amazon Cloud Formation. Heat is an excellent tool for managing OpenStack cloud resources like VM instances, security groups etc. It allows defining all cloud resources in a single JSON template and later maintain all the resources by editing that template. Although declarative template approach suites well for OpenStack resources it quickly turns to be too complex when it comes to application management. The reason is that services running on the VMs are not controlled by OpenStack. The only way for Heat to do something on a VM is an init script. A 3-rd party tool can be used for doing a software configuration.

There are configuration management tools like Chef or Puppet that can be used for that purpose. These tools are flexible but require to have a special knowledge in scripting and require efforts to manually script or modify cookbooks for the specific environment configuration. This fits well when an environment is stable 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. Windows services may require coordinated multi-step configuration changes among several machines. That might be hard to achieve on a large scale deployment without external orchestration. In addition to what was presented above, script based tools like Chef and Puppet do not come with UI which would allow to build an environment without writing or uploading a script.

Proposal

Mirantis propose to introduce a new service which will allow non-experienced user to deploy reliable Windows based environment in “push-the-button” manner. The key goal is to provide UI and API which will allow to deploy and operate Windows Environments on the Windows Services abstraction level. The Service should be able to orchestrate complex circular dependent cases in order to setup complex Windows Environment with many 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 - is a service like Active Directory, MS SQL, IIS which usually consist of multiple virtual machines and has multiple dependencies.
  • Windows Environment - is a logical unity for all services and represents a classical Windows Datacenter

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 GUI with ability to use all of Murano features;
  • Keystone - authenticates users and provides security token that is used to work with the OpenStack, hence limiting user abilities in Murano by his OpenStack privileges;
  • Heat - is used to provision VMs and other OpenStack resources for Windows Environment;
  • Glance - Windows Server VM images are stored there, each image containing an installed OS and a set of scripts
  • Agent - an agent software which communicates with Orchestration Engine and executes tasks on VMs

Murano architecture diagram.png


REST API

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

Object Model

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

Orchestration Engine

This is a core component which evaluates the Object Model change and creates a plan for implementing these changes on the instances or in the cloud. This component will support extensions via plug-ins. Plugin can add a new service 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 an cloud resource management engine, which allows you to manipulate with resources that represents OpenStack entities (Security Groups, Instances, Floating IPs, Volumes, etc.) and some custom entities like AutoScaling group from a single point of control. Bacause OpenStack resource provisioning is one of the step required for environment deployment it was decided to use Heat for that purpose. Using Heat allows us to define all the OpenStack resources in a single document that would be easy to maintain and would not require resorting to a lots of different OpenStack APIs while keeping the software configuration aside from it.

Windows on OpenStack

Windows works on KVM pretty smoothly. RedHat created an open-source VirtIO drivers for Windows that allow to work with KVM exposed devices efficiently. In Grizzly release a Microsoft’s hypervisor Hyper-V will be supported. Hyper-V virtual switch will be also supported as a Quantum plug-in. From the performance viewpoint, Hyper-V Server 2012 shows very small difference from physical machine. OLTP workload running on a 75,000 customer database deployed in a Hyper-V virtual machine processed just over 6% fewer transactions per second compared to the same workload running on a similarly configured physical server. Hyper-V also supports natively Windows Clusters in contrary to the current OpenStack implementation.

Roadmap

Please refer to Mirano/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