Manage OpenStack deployments with Red Hat’s Platform Director

0
156

Red Hat fills a much-needed hole in OpenStack deployments with its Platform Director. The software-based tool helps…

“;
}
});

/**
* remove unnecessary class from ul
*/
$(“#inlineregform”).find( “ul” ).removeClass(“default-list”);

/**
* Replace “errorMessageInput” class with “sign-up-error-msg” class
*/
function renameErrorMsgClass() {
$(“.errorMessageInput”).each(function() {
if ($(this).hasClass(“hidden”)) {
$(this).removeClass(“errorMessageInput hidden”).addClass(“sign-up-error-msg hidden”);
} else {
$(this).removeClass(“errorMessageInput”).addClass(“sign-up-error-msg”);
}
});
}

/**
* when validation function is called, replace “errorMessageInput” with “sign-up-error-msg”
* before return
*/
function validateThis(v, form) {
var validateReturn = urValidation.validate(v, form);
renameErrorMsgClass();
return validateReturn;
}

/**
* DoC pop-up window js – included in moScripts.js which is not included in responsive page
*/
$(“#inlineRegistration”).on(“click”,”a.consentWindow”, function(e) {
window.open(this.href, “Consent”, “width=500,height=600,scrollbars=1”);
e.preventDefault();
});

take away the guesswork and reduces the errors associated with private cloud deployment — issues that have plagued the early evolution of OpenStack and stalled production use of the platform.

Platform Director — which is part of the Red Hat OpenStack Platform 7 and subsequent releases — covers everything from planning, through deployment, to ongoing operations with updates and scaling.

The tool is based on what’s called OpenStack-on-OpenStack — or TripleO. This is a deployment model that consists of a dedicated OpenStack management layer, running on a single machine, that admins use to manage and monitor a user-facing OpenStack cloud. The benefit of TripleO is that it allows organizations to build a general-purpose OpenStack deployment on top of a simpler, single-purpose deployment that is already operational. This eases migration from the sandbox version.

With TripleO, admins deploy a management node as the bootstrap OpenStack cloud — also known as the undercloud. Admins build the production OpenStack cloud — called the overcloud — based on this management node. They can either use command-line utilities or a web-based graphical user interface to access Platform Director application program interfaces (APIs).



K Rain Leander, a Red Hat software
developer, explains what TripleO is and
how to create an undercloud.

The undercloud interacts with bare metal using Ironic, the OpenStack bare-metal provisioning service, for PXE boot. This requires a large set of supported drivers to ensure the hardware is compatible with Ironic, but Red Hat has covered most of the drivers for you.

Get started with Red Hat OpenStack Platform Director

Platform Director inspects the hardware and automatically assigns roles depending on node resources and performance. This is a huge improvement over the previous, manual approach to validate nodes and assign roles to them, and is a key feature for large OpenStack deployments.

Platform Director has a set of validation tools that verify any user templates, including network files. Admins also use these tools for updates and scaling. When the overcloud is deployed, there is another tool set called Tempest that can automatically validate and test it.

A set of OpenStack Heat templates in Platform Director offers best practices for a robust, high-availability cluster. The templates contain the experience of developers and users and provide valuable how-to information for OpenStack deployments. For instance, they’re sophisticated enough to determine if you need SSL endpoints for encrypted communication.

Manage an OpenStack lifecycle using Platform Director

The first stage of OpenStack deployment is planning. Platform Director has configuration files that define networking and storage topologies, operating parameters for OpenStack modules, plug-in integration and other setup details for the selected configuration. The tool then validates the hardware to ensure it’s ready to go.

Next is the deployment stage. This is where most of the Platform Director functionality occurs. The tool validates the selected configuration, then orchestrates the OpenStack deployment from beginning to end, handling hardware and software setup, then configuring OpenStack itself for optimum performance.

Once a production version is running, Platform Director facilitates software upgrades, including minor security updates and major release for OpenStack deployments. To handle cluster scaling, the tool monitors node and network health, and adds or removes nodes from the topology. It can also change configuration parameters.

Perform OpenStack updates with Platform Director

Platform Director provides a way to update OpenStack software in a synchronous manner across the cluster. Each release of Platform Director supports management for one previous, major release to safely allow for upgrades. It is possible to use alternatives to maintain the cluster software, but this nullifies many of Platform Director’s benefits. Third-party tools can access Platform Director’s APIs, however, so extending the tool set is feasible.

Coupled with OpenStack Nova compute, Platform Director detects any new nodes and automates their deployment, as well as installation and health-checking. This allows admins to add different node models as their OpenStack deployments evolve over time.

Automation, along with policy- and template-driven control of the scaling process, makes large clusters easier to deploy and reduces errors. Since Platform Director applies its validation tools to the new nodes and the subsequent deployed stack, quality and consistency of installation is generally high.

OpenStack release cycle updates
OpenStack release cycles

Upgrade to a new OpenStack release

With each major OpenStack release, the platform’s inter-module APIs usually change. This requires a synchronized process to update all nodes together. It’s also essential to validate all the nodes after an update to identify any that escaped the update process and, as a result, are down-level from the cluster.

Minor OpenStack release changes shouldn’t alter APIs, but make sure to keep the cluster nodes at the same release level even with minor releases. The validation tools in Platform Director can check that the upgrade is fully implemented, and validate the configuration scripts that control OpenStack operation on each node.

Complete all node addition and removal actions prior to a major OpenStack release update. This will ensure consistency on the new nodes, and allow you to test the cluster in working mode prior to an update.

Next Steps

Ocata release addresses OpenStack scalability issues

Solve OpenStack management troubles

Customize the OpenStack Horizon dashboard




Source link

LEAVE A REPLY