C12G has created the new howto OpenNebula with MySQL Cluster for High Availability to give guidance on how to deploy OpenNebula with a database backend configured in HA (High-Availabily) using MySQL Cluster.

This article is part of the new Knowledge Base that is being extended by C12G Labs.

This is the second article covering the functionality provided by the new OpenNebula Zones (oZones) component available in the third major release of OpenNebula. In a previous article, we described its Virtual Data Center (VDC) functionality that is helping many IT organizations make the transition toward the next generation of cloud infrastructures supporting multiple fully-isolated VDCs with advanced multi-tenancy. This article elaborates on its support for building multi-tier cloud architectures consisting of multiple OpenNebula Zones.

What is an OpenNebula Zone?

An OpenNebula Zone (oZone) is a group (“cluster”) of physical hosts under the control a single OpenNebula instance (“OpenNebula cloud”). The new oZones server available in OpenNebula 3.0 offers a single access point and centralized management for multiple oZones, potentially hosted in different geographical locations. A running oZone can be easily added to the oZones server, as long as you have valid administrator credentials in the server, without requiring any changes to the OpenNebula Zone itself.

A new onezone command and oZones GUI help manage and monitor the Zones in each oZones server, providing the ability to show the aggregated resources from multiple zones: templates, images, users, virtual machines, virtual networks and hosts.

A Zone can be further divided into Virtual Data Center (VDCs)  to support organizational isolation with advanced multi-tenancy. A VDC is a fully-isolated virtual infrastructure environment where a group of users, under the control of the VDC administrator, can create and manage compute, storage and networking capacity.

The cloud administrator can create a VDC with the new onevdc command or oZones GUI. The administrator assigns a group of users to a group of physical resources and grants at least one of the users, the VDC administrator, the privileges to manage all virtual resources in the VDC. Users can then access their VDCs using any of the existing OpenNebula interfaces (CLI, SunStone, OCA, or the OCCI and AWS APIs) with the VDC URL endpoint through the oZones server. The mapping of VDCs to the different Zones is transparent to the users and can be dynamically adapted by the cloud administrator for capacity planning.

Examples of Enterprise Use Cases of Federated Cloud Instances

The new functionality for federating OpenNebula cloud instances address many common requirements in enterprise use cases, for example:

  • Complete isolation of users, organizations or workloads in different Zones with different levels of security or high availability
  • Optimal performance with the execution of different workload profiles in different physical clusters with specific architecture and software/hardware execution environments
  • Massive scalability of cloud infrastructures beyond a single cloud instance
  • Multiple site support with centralized management and access to clouds hosted in different data centers to build a geographically distributed cloud

Are You Ready to Try the New OpenNebula Zones?

Through the new oZones component, OpenNebula offers a seamless, dynamic operating environment that enables the bridging of multiple Cloud instances, helping businesses achieve the full flexibility and benefits of cloud computing. OpenNebula 3.0 is a fully open-source technology. You have the software, the guides and our support to deploy your cloud infrastructure with multiple VDC environments.

Here is our newsletter for August 2011, summarizing news from the previous month that you may have missed on our blog and Twitter feed.

Technology

The OpenNebula team released the first beta of OpenNebula 3.0. This third major release brings many new features, such as multi-tenancy, support for Open vSwitch and VLAN tagging (IEEE 802.1Q), an enhanced SunStone portal with usage graphics and cloudwatch-like functionality, and many improvements in VM template management, monitoring and account. Another exciting feature in OpenNebula 3.0 is the support for Virtual Data Centers using OpenNebula zones. OpenNebula zones also offer centralized management of multiple instances of OpenNebula, potentially hosted in different geographical locations.

We also announced the release of new VMWare drivers that are compatible with the new 3.0 release.

Community

Carsten Friedrich wrote a blog post on how to extend OpenNebula’s LDAP authentication module.

The CFEngine project has provided documentation on how to use CFEngine to deploy an OpenNebula private cloud in an automated fashion.

Outreach

Ken Barber, from Puppet Labs, gave a talk in Manchester titled “Controlling your Cloud: Puppetising OpenNebula“.

Florian Feldhaus’s work on OCCI v1.1 support for OpenNebula was presented at the 2011 SNIA Cloud Plugfest

We have a few more outreach events planned for September. If you’ll be at any of these events and would like to meet with a member of the OpenNebula team, don’t hesitate to let us know!

The current ldap_auth module in OpenNebula assumes that the username is the same as the LDAP dn entry. In more complex LDAP installations this is often not the case and LDAP authentication is a bit more complicated:

  • Bind as a dedicated “search LDAP user”.
  • Search the directory tree for the username.
  • Get the DN from the search result.
  • Bind as the DN with the user password.

I modified the current ldap_auth.rb to use this more complex process if the auth.conf file defines “search_filter” (if undefined it will use the original behavior and is thus backwards compatible). If defined, it expects “search_filter” to contain a suitable search string with “@@LOGIN@@” instead of the user name (to be replaced at runtime). E.g. something like: “(&(cn=@@LOGIN@@)(objectClass=user))”

It also expects the following config entries:

  • sec_principal : the DN of the LDAP search user.
  • sec_passwd: The password for the sec_principal.
  • search_base: The base in the LDAP tree from which to search.

Code below (works with OpenNebula 2.0 and 2.2, but not with 3.0 beta):

[ruby]
# ————————————————————————–
# Copyright 2010, C12G Labs S.L., CSIRO
#
# This file is part of OpenNebula Ldap Authentication.
#
# OpenNebula Ldap Authentication is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or the hope
# That it will be useful, but (at your option) any later version.
#
# OpenNebula Ldap Authentication is distributed in WITHOUT ANY WARRANTY; without even
# the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
# PURPOSE. See the GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with OpenNebula Ldap Authentication . If not, see http://www.gnu.org/licenses/
# ————————————————————————–

require ‘rubygems’
require ‘net/ldap’

# Ldap authentication module.

class LdapAuth
def initialize(config)
@config = config
end

def getLdap(user, password)
ldap = Net::LDAP.new
ldap.host = @config[:ldap][:host]
ldap.port = @config[:ldap][:port]
ldap.auth user, password
ldap
end

def getLdapDN(user)
search_filter = @config[:ldap][:search_filter]
if (search_filter.nil?)
return user
end
search_filter = search_filter.gsub("@@LOGIN@@", user)
ldap = getLdap(@config[:ldap][:sec_principal], @config[:ldap][:sec_passwd])
begin
ldap.search( :base => @config[:ldap][:search_base], :attributes => ‘dn’, :filter => search_filter, :return_result => true ) do |entry|
STDERR.puts "Found #{entry.dn}"
return entry.dn
end
rescue Exception => e
STDERR.puts "LDAP search failed: #{e.message}"
end
return nil
end

def auth(user_id, user, password, token)
dn = getLdapDN(user)
if(dn.nil?)
STDERR.puts("User #{user} not found in LDAP")
return false
end
begin
if getLdap(dn, token).bind
STDERR.puts "User #{user} authenticated!"
return true
end
rescue Exception => e
STDERR.puts "User authentication failed for #{entry.dn}: #{e.message}"
return false
end
STDERR.puts "User #{user} could not be authenticated."
return false
end

end
[/ruby]