Using Activation keys in CloudForms System Engine

by Forrest Taylor (Red Hat)

Corresponding Curriculum: Content is extracted from the all-new Deploying Systems in Cloud Environments (CL260) course

Activation keys automate client repo subscriptions when registering to Red Hat CloudForms System Engine. Activation keys can define subscriptions and the default environment for a system. To manage activation keys, log in to System Engine and hover over the “Systems” tab, and choose the “Activation Key” sub-tab. Click the “+ New Key” link and enter the name and environment, then click the “Save” button.

Continue reading “Using Activation keys in CloudForms System Engine”

What is CloudForms?

by Vinny Valdez (Red Hat)

The following is an excerpt of a post originally published on June 29, 2012, on Vinny’s Tech Garage.

I’m really excited about CloudForms. In my recorded demo at Summit, I showed a RHEL 2-node active/passive cluster with GFS off an iSCSI target. Then I moved all the underlying CloudForms Cloud Engine components to shared storage. I was able to launch instances, fail over Cloud Engine, and see the correct status. After managing the instances, fail back, and all was good. All of this works because the RHEL HA cluster stops the databases and other services first, moves the floating ip over, then starts the services on the active node. This was a very basic deployment, much more could be explored with clustered PostgreSQL and sharded Mongo.

Continue reading “What is CloudForms?”

Tip/Trick of the Month: Using Highly Available Clusters with Red Hat Messaging

by Bruce Wolfe (Red Hat)

Red Hat Messaging (RHM) is built on top of the AMQP wire-level protocol, and is designed to be inherently reliable. However, if you have the resources, you can make your messaging application more robust with the addition of High Availability (HA) Clustering.

To set up a simple cluster you will need to edit three files, and populate the same values across each RHM broker and/or RHEL host instance:

/etc/corosync/corosync.conf

In the totem section add the network bind address (bindnetaddr), multicast address (mcastaddr), and multicast port (mcastport). For example, respectively: 192.168.10.0, 224.0.0.10, 5430

/etc/corosync/uidgid.d/qpidd

Continue reading “Tip/Trick of the Month: Using Highly Available Clusters with Red Hat Messaging”

Tip/Trick of the Month: Monitoring Drift Compliance with JON

by Rich Raposa (Red Hat)

Drift is the unplanned or unintended changes that occur on a resource’s configuration. System administrators need the ability to track drift in their data centers to improve availability and reliability of their platforms, servers and applications.

Drift monitoring is a new feature in the latest version of the JBoss Operations Network 3.0 (JON). You can define a drift detection definition on the Drift page of a resource. Click the New button, assign your drift definition a name, a base directory, then select the files and/or folders to be monitored for drift. Wait a few minutes and JON will take the initial snapshot (snapshot 0) of your monitored files. Each time drift is detected, JON takes a new snapshot of the monitored files. Each snapshot has a number, and snapshots can be viewed in an intuitive, new view known as the snapshot carousel by double-clicking on the drift definition from the Drift page of the resource.

Continue reading “Tip/Trick of the Month: Monitoring Drift Compliance with JON”

Tuning Your System With Tuned

by Wander Boessenkool (Red Hat)

Tuning systems can be a time consuming art. Not only does it involve extensive profiling of your systems, as well as continuous monitoring, but keeping tuning setting applied continuously can be quite a chore as well. Especially if the tuning needs of your systems change throughout the day.

Imagine a database system that is used to process orders from customers. In this specific system orders come in in bulk between 08:00 and 18:00, but the other 14 hours in a day and during the weekends the machine is mostly idling. We could tune this system for power efficiency, so as not to waste to much energy during the 118 hours a week it is doing almost nothing, or we could tune it for peak performance during the 50 hours a week the system is heavily utilized.

With a traditional setup switching between those two extremes would be either very cumbersome, with an administrator having to make those changes by hand, or it would require extensive scripting and testing to automate.

Continue reading “Tuning Your System With Tuned”