Home > Cloud Computing > What You Can Learn from IBM Research on Designing Private Cloud

What You Can Learn from IBM Research on Designing Private Cloud

November 16th, 2010 Leave a comment Go to comments

IBM Researcher Kyung Ryu presented a private cloud RC2 at LISA 2010 conference. As a typical IBM project, the presentation has 20+ co-authors. The following is based on my notes taken from the session, therefore may contain my misunderstandings.

Having an internal cloud is not a big deal these days. You can find several products from the market. What is truly unique and challenging for RC2 is that it supports very different virtualization platforms from X86 based hypervisors on X-series servers, to IBM PowerVM on P-series, to the mainframe based native virtualization on Z-series. Therefore RC2 is really a hybrid private cloud.

Time to learn how to "Google" and manage your VMware and clouds in a fast and secure


The talk focused on system architecture with several diagrams. I cannot reproduce these diagrams but would list the key components of the system:

  1. Cloud Dispatcher. As its name suggests, it takes requests from the front end and dispatches them to related servers at backend. It maintains two queues: one for synchronous processing and the other for asynchronous processing. The latter is needed for these requests that take long time, for example, creating a new virtual machine.
    The dispatcher also serves as gate keeper. Based on the capacity, it can admit or reject the requests. As a limit, the system can only handle about 256 concurrent virtual machine creations, which is good enough unless you are a service provider.
  2. Image Manager. It manages the virtual machine image repository. It exposes REST APIs for operations like checkin / checkout / publish / list / deprecate / unpublish / add, etc. These APIs can be called by Instance Manager.
    The image manger leverages mirage image library which maintains parent/child relationship of different images. The library may have been open sourced according to Dr. Ryu.
  3. Instance Manager. It creates new instances upon requests. The detailed steps include:
    1. Reserve system resources, such as host and IP address
    2. Register with TPM (Tivoli Provisioning Manager?)
    3. Clone virtual machine image
    4. Copy SSH keys and fix up image
    5. Setup actuator engine for first booting
    6. Register VM with hypervisor
    7. Start VM
    8. Wait while pinging the VM
    9. Report back
  4. Security Manager. It manages security aspect of the RC2.
  5. User Manager. It manages users and authentications.
  6. Chargeback. It listens event manager for events like VM start, VM destroy, etc. Based on these events, it uses BIRT report engine to generate reports. By applying chargeback with blue dollar (IBM internal currency), they observed a sudden drop (more than half) of VM instances overnight.

These components communicate with each other with REST APIs. The hypervisor differences are isolated so that they can support new hypervisors without big changes.

Besides these computing components, RC2 also has SAN storages for storing both virtual machine images, and virtual machine instances.

Besides the architecture, Dr. Ryu shared an interesting story regarding image conversion. The VM images were mostly XEN based in the beginning. After XenSource was sold to Citrix, they converted 600+ images to KVM format. The process went smoothly due to the mirage image library.

The RC2 has not only served folks at IBM Research but also others from other divisions. It has reached production quality. Next step? I think IBM should open source RC2 and claim its leadership position in cloud computing. What do you think?

  1. No comments yet.
  1. No trackbacks yet.