All posts for the month May, 2012




Snooze is an open-source scalable, autonomic, and energy-efficient virtual machine (VM) management framework for private clouds. It allows users to build compute infrastructures from virtualized resources and manage a large number of VMs. Snooze is one of the core results of Eugen Feller PhD thesis under the supervision of Dr. Christine Morin at the INRIA MYRIADS project-team. The prototype is now used within the MYRIADS project-team in various cloud computing research activities.

 For scalability Snooze employs a self-organizing hierarchical architecture and performs distributed VM management. Particularly, VM management is achieved by multiple managers, with each manager being in charge of a subset of nodes. In addition, fault tolerance is provided at all levels of the hierarchy. Finally, VM monitoring and live migration is integrated into the framework and a generic VM scheduler exists to facilitate the development of advanced VM placement algorithms. Last but not least once idle, servers are automatically transitioned into the system administrator specified power-state (e.g. suspend) to save energy. To facilitate idle times Snooze integrates dynamic VM relocation and consolidation.
In summary, Snnoze has the following features:
  • Self-configuration
  • Self-Healing
  • Overload and Underload detection
  • Relocation and Consolidation
  • Power Management
  • Live Migration
  • Generic Scheduler
  • Open Source

For more information, please visit the official web page here

OAuth 2.0 Protocol

With the increasing use of distributed web services and cloud computing, third-party applications require access to server-hosted resources. These resources are usually protected and require authentication using the resource owner’s credentials (typically a username and password).

In the traditional client-server authentication model, the client accesses a protected resource on the server by authenticating with the server using the resource owner’s credentials. In order to provide third-party applications access to protected resources, the resource owner shares its credentials with the third-party. This creates several problems and limitations:

  •  Third-party applications are required to store the resource-owner’s credentials for future use, typically a password in clear-


  •  Servers are required to support password (symmetric) authentication, despite the security weaknesses created by


  •  Third-party applications gain overly broad access to the resource-owner’s protected resources, leaving resource owners without any ability to restrict access to a limited subset of resources, to limit access duration, or to limit access to the methods supported by these resources.
  •  Resource owners cannot revoke access to an individual third-party without revoking access to all third-parties, and must do so by changing their password.

 OAuth address these issues by separating the role of the client from that of the resource owner. In OAuth, the client (which is usually not the resource owner, but is acting on the resource owner’s behalf) requests access to resources controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner.

 Instead of using the resource owner’s credentials to access protected resources, clients obtain an access token (a string which denotes a specific scope, duration, and other attributes).

 Please see the original IETF Internet Draft to get more information.

Kato: A Java API for Post-Mortem JVM Diagnostics

Apache KATO is intended to be a Java API for standardising how and what can be retrieved from the contents of post-mortem artefacts — typically process and JVM dumps. Project Kato is intended to be the place where the Specification, Reference implementation (RI) and Technology Compatibility Kit (TCK) are openly created.

Post-mortem versus Live Monitoring: It’s worth noting that the term “post mortem” is used loosely. It does not just imply dead JVMs and applications; JSR 326 also covers living, breathing applications where the dump artefacts are deliberately produced as part of live monitoring activity. Live monitoring generally means tracing, profiling, debugging, or even bytecode monitoring and diagnosis by agents via the java.lang.instrument API . It can also mean analysis of dumps to look for trends and gather statistics. The live-monitoring diagnostic space is well served except for this last area, which is where JSR 326 can help.

 There are many good ways to understand and diagnose problems while they happen, but few credible or pervasive tools exist for helping resolve problems when all has gone suddenly and horribly wrong. Outside of “live monitoring” there is no standard way to provide diagnostics information, and hence no standard tools. Each tool writer has to figure out how to access the data individually and specifically for each JVM vendor and operating system. This sparsity of tools has meant that users have limited options in diagnosing their own problems, especially unexpected or intermittent failures. Consequently these users turn to the providers of their software to work out what is happening. Application, middleware, and JVM vendors are spending increasing time supporting customers in problem diagnosis. Emerging trends indicate that this is going to get worse.

See the official web page, for more information, Apache Kato.

Apache Mesos

Apache Mesos is a cluster manager that provides efficient resource isolation and sharing across distributed applications, or frameworks. It can run Hadoop,MPIHypertableSpark (a new framework for low-latency interactive and iterative jobs), and other applications. Mesos is open source in the Apache Incubator.

Mesos block diagram

You can use Mesos to:

  • Run Hadoop, MPI, Spark, and other frameworks on a dynamically shared pool of nodes.
  • Run multiple instances of Hadoop on the same cluster to isolate production and experimental jobs, or even multiple versions of Hadoop.
  • Run long-lived services (e.g. Hypertable and HBase) on the same nodes as batch applications and share resources between them.
  • Build new cluster computing frameworks without reinventing low-level facilities for farming out tasks, and have them coexist with existing ones.


  • Fault-tolerant replicated master using ZooKeeper.
  • Scalability to 10,000s of nodes using fast, event-driven C++ implementation.
  • Isolation between tasks with Linux Containers.
  • Multi-resource scheduling (memory and CPU aware).
  • Efficient application-controlled scheduling mechanism (resource offers) that lets frameworks achieve their own placement goals (e.g. data locality).
  • Java, Python and C++ APIs for developing new parallel applications.
  • Web UI for viewing cluster state.

Please, see the following tutorials which explain Apache Mesos in detail.