Tuesday, January 08, 2013

Deploying and managing OpenShift Enterprise PaaS

We did a lot in the cloud computing space last year at Red Hat. We shipped our open hybrid cloud management software, CloudForms. We further ramped up our OpenStack activity with a technology preview. We acquired ManageIQ. We developed integrated cloud solutions based on the full Red Hat product portfolio. 

But that's not all. One of the most exciting announcements of the past year was an on-premise version of Red Hat OpenShift Platform-as-a-Service. We'd been racking up new users and new applications—and expanding the functionality—on the hosted offering. The individual developers and IT departments who tried it out really liked the way they could develop using their choice of languages and frameworks and customize the development environment to meet their needs. Simply put, OpenShift Online (as it's now called) takes a lot of friction out of software development without limiting flexibility.

However, much as some customers appreciated the functionality of the online service, they wouldn't be able to make widespread use of it so long as it was only available in hosted form. To address these requirements, last November Red Hat introduced OpenShift Enterprise, an on-premise version of OpenShift PaaS. (For more background on enterprise PaaS, you can check out this whitepaper.)

Unlike with a hosted service, an on-premise PaaS has to be deployed and managed. To assist with this process, Scott Collier and Steve Reichard on Red Hat's Systems Engineering team have put together a new reference architecture: "Deploying and Managing a Private PaaS with OpenShift Enterprise." The full reference architecture weighs in at almost 150 pages and includes lots of screen shots, configuration file entries, and command line text.* 

openshift-environment

The reference architecture shows how to deploy OpenShift Enterprise in a distributed way that separates domain name services, ActiveMQ, and MongoDB from the OpenShift Enterprise broker host. It also shows how to deploy both PHP and Java applications, enable applications with Jenkins continuous integration services, and use JBoss Developer Studio within an OpenShift Enterprise environment.

The broker is the single point of contact for all application management activities. It manages user logins, DNS, application state, and application orchestration. The broker can be communicated with programatically using a RESTful API or, alternatively, through a Web console, command line tools, or JBoss Developer Studio. ActiveMQ provides the messaging infrastructure for the broker. MongoDB provides the persistent data store. In the case of this reference architecture, the broker components were set up redundantly to provide high availability for OpenShift Enterprise's management system.

The reference architecture shows how to set up a load balancing cluster of OpenShift Enterprise brokers. The Load Balancing Add-on for Red Hat Enterprise Linux provides support for TCP load balancing independent of applications. It is composed of two major components: the Linux Virtual Server (LVS) and the Piranha Configuration Tool, a management tool with a GUI.

OpenShift applications run on nodes. Application multi-tenancy on each node is provided through SELinux and Cgroup restrictions that isolate each application's resources and data. Nodes can be added as required to provide the computing resources required by the applications running on an OpenShift Enterprise installation. The reference architecture demonstrates deploying the node software using the Red Hat Network (RHN) as well as Red Hat's content delivery network (CDN). This includes installing the Marionette Collective (MCollective) server orchestration framework packages on the node. 

Gears are containers with a set of resources that allow users to run applications within a node. Districts define a set of node hosts and the resource definitions they must share in order to allow transparent migration of gears among hosts. They're not required but they're simple to use and any production installation can benefit from them. Districts allow a gear to keep its same ID when moved between any node hosts within the same district. Thus, users' apps will not be disrupted by changes when they are migrated between nodes even if they have hard-coded values. 

There's a wealth of additional detail in the reference architecture but the above should give a high-level taste. 

Increasingly, we see organizations looking to hybrid IT and hybrid cloud as detailed in this Gartner report. The addition of OpenShift Enterprise to our OpenShift Online service brings hybrid to PaaS. You don't need to choose. You can have both.

* The full configuration files are only available to Red Hat customers as part of the value-add of a Red Hat subscription.

Post a Comment