Difference between revisions of "Murano"
m (→Integration with Heat) |
m (Small improvements) |
||
| Line 1: | Line 1: | ||
== Project Background == | == Project Background == | ||
| − | Enterprise customers frequently use Windows based | + | 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. |
| − | Configuration of the Windows | ||
| − | Currently several open source solutions exists that can help to partially solve automation of Windows environment provisioning. In the world of OpenStack there is | + | 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 | + | 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 | + | 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 lack of UI functionality | + | Another potential problem is the lack of UI functionality enabling creation and configuration of an environment without writing a script. |
==Proposal== | ==Proposal== | ||
| − | Mirantis | + | 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: | The service will address following use cases: | ||
| Line 20: | Line 19: | ||
The solution will provide higher level of abstraction for manipulation Windows Environments. Key concepts are: | The solution will provide higher level of abstraction for manipulation Windows Environments. Key concepts are: | ||
| − | * Windows Service - | + | * Windows Service - a service such as Active Directory, MSSQL, or IIS, which usually consists of multiple virtual machines and has multiple dependencies. |
| − | * Windows Environment - | + | * 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. | * Windows VM instance - a VM which hosts a Windows Service. A Windows Service might be deployed over several Windows VM instances. | ||
| Line 41: | Line 40: | ||
=== REST API === | === 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 | + | This component is responsible for translating API function parameters to Object Model attributes and propagating the deployment status from the Orchestration Engine. |
===Object Model=== | ===Object Model=== | ||
| Line 49: | Line 48: | ||
===Orchestration Engine=== | ===Orchestration Engine=== | ||
| − | This is | + | 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== | ==Integration with Heat== | ||
| − | Heat is | + | 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 | + | |
| + | 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 on OpenStack== | ||
| − | Windows works on KVM pretty smoothly | + | 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 Grizzly release | + | |
| − | Hyper-V also supports | + | 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 over 6% fewer transactions per second compared to the same workload running on a similarly configured physical server. |
| + | Also, unlike the current OpenStack, Hyper-V also natively supports Windows Clusters. | ||
==Roadmap== | ==Roadmap== | ||
Revision as of 15:40, 30 April 2013
Contents
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:
- Native to OpenStack
- Introduces abstraction level for Windows Environments
- Supports Availability Zones and Disaster Recovery scenarios
- 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 WinDC features;
- Keystone - authenticates users and provides security token that is used to work with the OpenStack, hence limiting user abilities in WinDC by his OpenStack privileges;
- Heat - is used to provision VMs and other OpenSack resources for Windows Environment;
- Glance - Windows Server VM images are stored there, each image containing an installed OS and a set of scripts
- Quantum - provides network configuration API
- Agent - an agent software which communicates with Orchestration Engine and executes tasks on VMs
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 over 6% fewer transactions per second compared to the same workload running on a similarly configured physical server. 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
- Project Info: https://wiki.openstack.org/wiki/Murano | http://murano.mirantis.com/index.html
- Installation Guide: http://murano.mirantis.com/content/ch05.html
- Sources:
- https://github.com/stackforge/murano-api
- https://github.com/stackforge/murano-agent
- https://github.com/stackforge/murano-docs
- https://github.com/stackforge/murano-deployment
- https://github.com/stackforge/murano-tests
- https://github.com/stackforge/murano-conductor
- https://github.com/stackforge/murano-dashboard
- https://github.com/stackforge/python-muranoclient
- Launchpad project: https://launchpad.net/murano
